Q&A: The quest (and justification) for trustworthy code
- By Mathew Schwartz
- June 21, 2006
Four years ago, Microsoft announced its Trustworthy Computing initiative. The goal: to imbue each of its developers with more security savvy, so applications would be more secure from the get-go, resulting in fewer software vulnerabilities, and improving security worldwide.
When it comes to facilitating more secure applications, Microsoft isn’t alone. Its activities parallel—or have engendered—similar moves by numerous software vendors, as well as awareness levels for companies building their own applications for internal use.
Yet creating more secure applications is a laborious process, as is justifying the related expenditures to senior management. To learn how companies can better facilitate such processes, we talk to Dr. Herbert H. Thompson, the chief security strategist of Wilmington, Mass.-based Security Innovation Inc., an application security services provider.
Have compliance requirements changed companies’ perception of software security?
If this was eight months ago, most audits didn’t touch anything except network defenses—firewalls, IDS (intrusion detection systems). But now, [auditors are] starting to ask software-related questions. Just that fact … has raised awareness of security as a whole in upper management. Once upper management realizes security is kind of interesting and important, then the CIO has a much better case to go to them and say some of our biggest risks in IT are coming from the software we build.
What are companies’ biggest security-related, software-building questions?
For non-software vendors, it’s really, “How can I mitigate risk, and how can I show that I’m actually doing something, to show that I’m mitigating risk?” Some of the biggest risks are coming from software—both the applications I build and choose to buy—as opposed to the network. … Another question is, ‘How do I better judge applications to make more security-savvy buying decisions?’ There’s no equivalent of a Consumer Reports test for software security. … so [there’s a need] to arm folks to ask vendors the hard questions about security.
Are companies properly allocating resources to make applications built in-house more secure?
I’ve been to organizations that have three different firewalls from three different vendors daisy-chained so you go through all three, which is a ridiculous allocation of monetary assets. Because the chances of the [security improvement] delta you get from all three firewalls is ridiculous, for the money spent, versus what if I just trained an influential developer on security. Would that have bought me more in terms of operational security?
So companies need more of a big-picture view?
We need a holistic approach to software security, and it’s not just something that can be bolted on at the end of the process, just through testing, and it’s not just something that can be bolted onto a system through network appliances. …
Is it getting any easier to code applications more securely?
A big change is that building security in [is easier] now. Microsoft Visual Studio 2005, it’s got some source-code analysis stuff in there, a little bit of the PREfast stuff, that Microsoft uses to scan its own code. It’s also got just more to enable the developer to write more securely—more information. Again, a source-code scanning plug-in, support for libraries in a .NET framework that are inherently more secure, secure string in .NET, that sort of thing. Then you’ve got the big push from all these vendors offering security software [scanning tools].
Would the code-scanning tools in Visual Developer be sufficient to help developers write more secure code?
It’s one little thing, but that one little thing can help, certainly, if you’re not doing anything. And some places aren’t doing anything, because they don’t have any idea what they should do … or they can’t justify it up the chain in terms of return on investment (ROI).
Why is it difficult to calculate the ROI of more secure software?
If you talk to a CSO [chief security officer] or a CISO [chief information security officer], they may understand they need more secure software, but they don’t know how to communicate that need in business terms up to their bosses. … Say you’re a CISO or a CTO [chief technology officer] and you spent $500,000 or $1 million on security this year and there were no incidents, and the budget comes up for next year, and you’re in a tough spot because your manager is looking down at you, really doesn’t understand security, but does understand risk. So one of the biggest things we’ve been doing at Security Innovation is when we deliver a service or help people improve their software-delivery process, it’s been not just helping the process, training their people, and helping them add secure-coding baselines into the mix, but also [discussing] how can you record measures of improvement, so you can know if you’re getting better or not. And that’s been a huge challenge in the industry.
How can companies calculate the ROI from lowering the risk of bugs?
[One resource is] AppSIC, the Application Security Industry Consortium, which we formed, but outside of Security Innovation—as a non-profit. It is a collection of security executives from the vendor and business communities. It includes Mary Ann Davidson, CSO of Oracle; Sachar Paulus, CSO of SAP; Scott Charney, vice president of Trustworthy Solutions for Microsoft. … Our [goal] is … [to find] metrics for software security. [So] if I’ve got $100 to spend on a security improvement process for my software, how do I allocate it?
For improving software security, what’s your most recommended expenditure?
Awareness and training for developers: that’s probably going to buy you the most for your dollar. But there’s a point where I spend $100 or $100,000 on that, and [then], if you ask that question again, … it’s [a different answer].
What about evaluating the security of applications you might purchase?
One of the big things I’ve found is that software security isn’t just about the security quality of the application we get; it’s also about security quality of service we get from the vendor. That’s kind of interesting, because unlike a car or something I buy from Ford, I buy the car and take it on the road, but the car doesn’t really change over time. Whereas software does. … So when I need to evaluate a piece of software, one of the biggest questions may be how is my vendor going to help me?
What questions can organizations ask to evaluate if vendors will help?
One question is what does a patch release look like? One of the biggest pains for customers is patching. So how does the vendor provide the patch, what sorts of tools do they give me to disperse the patch, can I get any insight into the destabilization it can cause? When they release a patch and discuss things like the severity of the vulnerability, is there enough information on the vulnerability for me to make a contextual assessment? They rate it as critical, but is it really critical for my network?