New services and tools designed to help developers create secure software applications continue to emerge. At the same time, a long-recognized training gap has left some large organizations looking to outsiders for help in creating secure code.
But, is it enough?
Not according to experts including eWEEK Technology Editor Peter Coffee and secure code consultant Gary McGraw, both of whom agree that code review—while important—isnt sufficient to ensure secure code. What is needed to create applications that will act as expected despite deliberate or unintentional efforts to get them to act otherwise is an architectural review that designs security into software.
McGraw, chief technology officer of Cigital, in Dulles, Va., and the author of "Software Security: Building Security In" (Addison-Wesley, 2006), sees software bugs falling into two basic categories: implementation, including such classics as a weakness that allows a buffer overflow, and architectural, vulnerabilities that arent found in individual lines of code but are the result of poor design decisions.
eWEEK Labs spoke with IT executives from two large, well-known corporations about how they use outside services to architect security into software applications: MasterCard International and Qualcomm.
Terry Stanley, MasterCards vice president of infrastructure and standards in Purchase, N.Y., said that getting support for secure development is not a problem; the issue is getting it done.
"I have no problem getting executive sign-on [for software security projects]," said Stanley. "I also have no problem getting the budget to do what I want it to do. The developers and manufacturers out there say theyre on board. The problem is getting it done. [Secure development] is not as easy as it sounds."
One of the biggest challenges companies face is a constantly shifting technology landscape that makes it difficult for developers to keep up.
Qualcomm uses nearly 3,000 developers to create the software that runs with the companys chips in mobile phones. The company has used software consulting company Cigital on eight engagements during the last 18 months.
"One of the things we didnt have skills with was automated tools for checking our code," said Greg Rose, vice president of technology at Qualcomm, in San Diego. "So, one of the first things that we did with our secure software service was running automated tools against our code base and discovering potential problems."
At the February RSA Conference, in San Jose, Calif., Coca-Colas director of application security spoke about the need to establish well-defined security goals.
Coca-Cola started almost 18 months ago on its security assurance implementation, according to Mark Mehlberg, director of application security at Coca-Cola. "The first step was to find where we were at [regarding secure software] because that is one of the first questions the executives ask. [The next step,] of course, is establishing goals for this capability coupled with the risk you are trying to get the executives to understand. When you start asking for funding, it becomes a barrier unless youve done this first." Mehlberg made these remarks during a presentation on building secure software at the RSA Conference.
Understanding risk is crucial to architecting secure software. eWEEKs Coffee put it this way: "Security assessment is not about the elimination of risk; it is about the appropriate balance of necessary and useful risk with relevant business benefits. Further, security is an area in which you need a relatively narrow but extremely deep and expensively maintained current knowledge to do the job well."