The security products industry has created some great defenses for protecting technology that can be walled off from non-trusted outsiders. Firewalls, VPNs and strong authentication are mature technologies that work well to wall off vulnerable software where possible.
But security product defenses fall short when protecting technology that needs to be exposed to non-trusted (or less trusted) outsiders. These are your potential customers, current customers, partners and suppliers. Web applications and e-mail are examples of this type of software and are a major source of security vulnerabilities.
The class of software that can't rely on network defenses needs to take care of its own security. The source of the problem needs to be the source of the solution, the software itself.
Currently the software industry is creating secure software in reactive mode. Every time you download a patch and update your computer to make it more secure, you are downloading a correction to a piece of software your computer runs. The timeline leading up to the correction usually goes like this:
- Vendor ships software with latent security flaw.
- Vulnerability researcher discovers the flaw through manual testing
and reports it to the vendor.
- A maintenance engineer at the vendor reproduces the flaw and tracks down the place in the source code where the original programmer made a coding error.
- The engineer fixes the problem in the source code, builds a patch and runs a regression testing suite to make sure the fix didn't break anything else.
- The vendor issues a patch and notifies customers.
- Attackers develop exploits and compromise vulnerable computers.
- Customer downloads patch, potentially runs his/her own test suite and then deploys the patch on each vulnerable computer.
If there was a way to identify the problem in the source code before the software shipped to customers, large expenses would be saved by both vendors and customers. A NIST study, "The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002," put the cost of fixing a bug in the field at $30,000 vs. $5,000 during coding. That study only takes into account the vendor's cost. A much larger cost is borne by software users: the cost of cleaning up worms, viruses and other intrusions, and keeping systems patched. For minor vulnerabilities customer costs are in the millions. For major worm outbreaks the costs can range into the billions.
Luckily we are not doomed to a costly reactive approach. There is a way to prevent most security flaws during the original production of the software. It's called secure coding. There are well known classes of coding flaws that any programmer can easily learn to identify and avoid. Most of it is just good programming practices such as correctly sizing buffers, checking function return codes, and using platform security and crypto API's properly. Most insecure code is simply sloppy code.
Software customers can save time and money by demanding that their vendors fix flaws up front with secure coding and not subject them to costly and seemingly endless worm and virus remediation and patching regimens.
About the author
Chris Wysopal is VP of R&D at @stake Inc., a digital security consulting firm based in Cambridge, Mass. He is a founding member of the Organization for Internet Safety.
