Why Is Software So Insecure?

Software applications lack viable security because, at first, they didn't need it. "I graduated in computer science and learned nothing about security," says Chris Wysopal, technical director at security consultancy @Stake. "Program isolation was your security."

The code-writing trade grew up during an era when only two things mattered: features and deadlines. Get the software to do something, and do it as fast as possible. Cyra Richardson, a developer at Microsoft for 12 years, has written code for most of the company's major pieces of software, including Windows 3.1. "The measure of a great app then was that you did the most with the fewest resources" - memory, lines of code, development hours, she says. So no one built secure applications, but no one asked for them either. Windows 3.1 was "a program made up almost entirely of customers' grassroots demands for features to be delivered as soon as possible", Richardson recalls.

Networking changed all that. It allowed someone to hack away at your software from somewhere else, mostly undetected. But it also meant that more people were using computers, so there was more demand for software. That led to more competition. Software vendors coded frantically - under the insecure pedagogy - to outwit competitors with more features sooner. That led to what one software developer called "featureitis" - inflammation of the features.

Now, features make software do something, but they don't stop it from unwittingly doing something else at the same time. E-mail attachments, for example, are a feature. But e-mail attachments help spread viruses. That is an unintended consequence - and the more features, the more unintended consequences.

As networking spread and featureitis took hold, some systems were compromised. The worst case was in 1988 when a graduate student at Cornell University set off a worm on the ARPAnet that replicated itself to 6000 hosts and brought down the network. At the time, events like that were the exception.

By 1996, the Internet supported 16 million hosts. Application security - or, more specifically, the lack of it - turned exponentially worse. The Internet was a joke in terms of security, easily compromised by dedicated attackers. Teenagers were cracking anything they wanted to: NASA, the Pentagon, the Mexican finance ministry. The odd part is, while the world changed, software development did not. It stuck to its features-deadlines culture despite the security problem.

Even today, the software development methodologies most commonly used still cater to deadlines and features, and not security. "We have a really smart senior business manager here who controls a large chunk of this corporation but hasn't a clue what's necessary for security," says an information security officer at one of the largest financial institutions in the world. "She looks at security as: Â'Will it cost me customers if I do it?' She concludes that requiring complicated, alphanumeric passwords means losing 12 per cent of our customers. So she says no way."

Software development has been able to maintain its old-school, insecure approach because the technology industry adopted a less-than-ideal fix for the problem: security applications, a multibillion-dollar industry's worth of new code to layer on top of programs that remain foundationally insecure. But there's an important subtlety. Security features don't improve application security. They simply guard insecure code and, once bypassed, can allow access to the entire enterprise.

That's triage, not surgery. In other words, the industry has put locks on the doors but not on the loading dock out back. Instead of securing networking protocols, firewalls are thrown up. Instead of building e-mail programs that defeat viruses, antivirus software is slapped on.