A Better Way to Deal With Vulnerabilities
When IT pros start adding up the real costs of addressing security vulnerabilities, they may be in for an unpleasant surprise. It's enough to make them demand better quality software -- or at least, it should be.
Shawn Hernan, member of the technical staff at Carnegie Mellon University Software Engineering Institute (SEI), says vulnerabilities amount to a tax that is costing organizations time and money.
In 2002, 4,129 vulnerabilities were reported to Carnegie Mellon's CERT Coordination Center (CERT/CC) and the group estimates 5,500 more will be found in 2003, Hernan said during a recent presentation at the Institute for Applied Network Security's (the Institute) recent Southeast Network Security Forum in Marietta, Ga. (Press coverage of Institute events is normally forbidden, but since Hernan frequently gives a similar talk, the Institute agreed to make an exception in this case.)
It would take 229 eight-hour work days just to read the descriptions of all those vulnerabilities, figuring an average of 20 minutes apiece. If your organization is affected by just 10% of them, that's 550 vulnerabilities you should patch. Assuming it takes an hour for each patch, ring up another 69 working days spent installing patches. And that's for a single system.
Besides the tax on time that vulnerabilities cause, they also can cost money in terms of compromised servers -- even if the intruder isn't targeting your organization. Hernan told of an underground economy in which intruders trade stolen credit card numbers for information on compromised systems that they can use to launch attacks. That essentially means that every organization has something of value -- servers.
The key to fixing the problem and getting off the patch treadmill is to improve software quality.
"If your security strategy values patch production and response over quality, you're doomed to failure," Hernan said. Buffer overflows, for example, "are a class of problem we just should not accept anymore."
Improving software quality, in turn, requires that organizations "move to the left," meaning they should start thinking about security early in the software development process. "Most security issues are best addressed during the design stage," he said.
To help in that effort, the SEI and CERT/CC have developed the Team Software Process (TSP)-Secure, a set of processes and methods for producing high-quality, secure software that builds on existing TSP principles. SEI offers workshops to educate developers in its TSP-Secure methods, with startling results, according to Hernan.
A group of Microsoft programmers attended a pilot TSP-Secure course and used the process on a product they were developing. Individually, programmers found 50% to 85% of defects at the code review stage. Collectively, however, the team found 95% of defects, Hernan said. When all was said and done, the process predicted only one defect would remain unfound. Oh, and the product was finished ahead of schedule.
"If you take a more disciplined approach to how you build software, you can avoid a lot of these problems early on in the process," he says.
Carnegie Mellons TSP and CERT/CC teams are looking for more early adopters to help them further refine and demonstrate the TSP-Secure method. For more information, see http://www.sei.cmu.edu/tsp/tsp-security.html. Desmond is president of Paul Desmond Editorial Services (www.pdedit.com), an IT publishing firm in Framingham, Mass. He was the founding editor of eSecurityPlanet.com.