eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The term “software security” usually conjures images of aftermarket measures like intrusion detection, anti-virus and firewalls.
Gary McGraw is on a mission to change that.
What developers should be thinking about is writing more secure and reliable code and including basic security measures in their applications, not relying on customers to lock them down once the software is deployed.
And IT managers and CIOs should be using their checkbooks to let vendors know that theyre no longer interested in buying flawed code, McGraw said.
“Its time to do software security. Theres been enough philosophizing and hype. Now everyone knows we have a problem and wants to know what to do about it,” said McGraw, the CTO at Cigital, in Dulles Va., and the author of a new book, aptly titled “Software Security: Building Security In.”
The book is a step-by-step blueprint for developers interested in building more secure code from the ground up and centers on seven “touchpoints” for software security.
The tenets include code review, risk analysis, penetration testing, risk-based security tests, abuse cases, security requirements and security operations.
McGraw is under no illusions that ISVs and in-house developers at other enterprises will be adopting this plan wholesale. Change takes time. But, if nothing else, he hopes development organizations will at least take the minimal steps of using static analysis tools to scan code, and performing risk analysis audits of their applications before they ship.
Perhaps the best-known example of a company getting religion on software security is Microsoft, with its Secure Development Lifecycle process.
The company has developed the process over the course of several years and continues to tweak it as need be. Microsoft also has built its own static analysis tools, PREfix and PREfast.
Oracle has begun using a similar tool, Fortifys Source Code Analysis suite, to audit its code.
But, as McGraw and other experts point out, such tools are only one piece of a much larger puzzle.
Mike Howard, a senior security program manager at Microsoft, and author of “Writing Secure Code,” pointed out in his blog recently that developers must be careful not to place too much faith in code-scanning tools.
“Such tools, often called static analysis tools, such as the tools we have included in Visual Studio 2005, are very useful, but they are no replacement for human intellect,” Howard wrote.
“If a developer does not know how to code securely, or if a designer does not know how to design secure systems, and testers dont know how to validate the security-posture of code, tools will provide little, if any, help.”
“I agree with Mike on that,” McGraw said. “I just dont believe any tool is the be all and end all. Static analysis is not going to fix everything, but you sure as hell ought to be doing it.”
Despite the success that Microsoft and other software companies have had in cleaning up their code before shipping it, McGraw said that the majority of ISVs still havent gotten the message. In fact, development shops in financial services companies and other non-technology organizations are taking the lead on developing secure code.
“Its not the software vendors so much. Its all of the other people who are doing it,” he said. “Qualcomm, Coke. Were making good inroads, but we need developers to get behind this idea.
“It takes market demand [for change to happen]. Consumers for some odd reason think that everything is secure, and when they find out its not, they get [mad],” McGraw said.
“These companies are finding out that people have implicit expectations that software will be secure.”
Many companies in recent years have taken to using penetration testers to attack their applications either after theyve already been deployed or in the predeployment testing phase.
But this kind of test is only as good as the tester and the results only show what vulnerabilities exist at one given point in time. Given the dynamic nature of enterprise networks, the test results are likely out-of-date by the time the CIO gets them.
“Pen testing has devolved into a feel good exercise. The reformed hackers [doing the test] find five problems and maybe tell you about two of them. Its usually incredibly surface-level stuff,” McGraw said.
“The hackers feel good, the customers feel good and the VP feels good because he gets to check off the security box and go home.”
Along with Microsofts Howard, McGraw is part of a small cadre of experts that has been agitating for better software development processes and more education on secure coding practices for developers as a more efficient and effective way of addressing the epidemic of security flaws in commercial software.
But adopting a framework like McGraws or Microsofts takes time, discipline and a commitment from not just the IT organization, but upper management as well.
And, as McGraw is quick to point out, breaking code is far simpler than writing unbreakable code. Or, as Dan Geer said in his foreword to “Software Security”: “I personally prefer Sam Rayburns earthy formulation, viz.: Any jackass can kick down a barn, but it takes a good carpenter to build one.”