A cautionary security tale

Talk to any CTO or IT manager about his or her top day-to-day concerns, and security is sure to be at the top of the list. When I come into work each morning, I am never surprised to hear of a new worm, virus, Trojan horse, or phisher scam.

I’m obviously not alone: According to Symantec’s latest Internet Security Threat Report, the last half of 2003 saw a fivefold increase in worms and other types of malicious code that attempt to steal personal data from Internet users. Too often, though, we in IT shake our fists at big software companies like Microsoft while we ourselves engage in the kinds of practices that result in self-inflicted security risks to our companies.

I was talking to someone recently who works in IT about a security problem that the developers at his company have been battling. Many months ago, the company was in the market for a technology solution, but there were no vendors with a solution that fit their requirements. They decided to build their own system internally using open source components. Most IT managers have faced this choice at least once before and made the same decision. It’s not necessarily a bad one — it’s often a good one, as long as the project itself is managed well. This particular project had its challenges from the beginning. The project was understaffed, and the schedule was tight and unyielding. A star developer who was not overly fond of documentation carried the weight of the team. Ultimately, the small group of developers completed the system more or less on schedule and was toasted for its heroic efforts. The system had enabled a key strategic business function and was considered a success.

The system ran reasonably well for months as the developers caught their breaths after the grueling project. In the meantime, the documentation-challenged star developer left the company, putting the code in the hands of developers not as familiar with all the nooks and crannies of his code. Suddenly, there was a nasty security incident, followed by more nasty security incidents. The code had been developed so quickly that problems within the system were difficult to diagnose and correct. Logging of the system’s activities was minimal, and the fact that the system was mission-critical and in production only increased the pressure. The same folks in management who praised the speedy launch effort wondered how the system could go so wrong and wanted the security issues fixed — now.

Projects such as this point to a pervasive problem with software development in business: organizational praise for quick (but sloppy) work followed by surprise and frustration when systems ultimately decay into a block of security Swiss cheese. The emphasis on “just making it work” almost always trades expeditiousness for future pain.  Little or no attention is paid to testing against even the most common exploits of crackers.

There are only two ways for IT managers to avoid these kinds of security issues. The first is to insist on more development time so that a system is at least broadly understood by the development team when problems do occur. When the first method doesn’t work and organizational pressure forces a release, the second method should be employed: Clearly warn management in writing to expect security issues and budget resources accordingly.

And if one and two are impossible in your organization, there is actually a third reasonable alternative — look for a better job.