Security And Market Forces
Gunnar Peterson wrote an excellent post lamenting the lack of market forces in the security space.
I don’t know when we’ll see such market forces affecting companies but do agree they would have a positive impact. Certainly, I get why the security space hasn’t been subject to market forces yet though:
- People haven’t historically been ready to pay for it
- Companies haven’t entered the market with something valuable enough to invest in
First: what people are willing to pay for. Simple question: if a development team has a $10M budget, how much does it, say, spend on quality? 10-40%? OK. How much does it spend on software security?
Second: The security space, at least with respect to Software or Application Security, has indeed moved beyond its purely missionary roots: people know they face a problem. People do not, however, know what to do about it.
Lack of direction hasn’t resulted from the vendors’ failed productization of a tool set or services though. No, it’s resulted from the lack of mature solutions in the space. Penetration testing companies were gobbled up last year but my experience has been that, for the most part, customers haven’t been willing to invest in these tools far beyond their initial purchases and the smallest amount of shepherding.
In fact, most organizations I’m working with have seen either a reduction in reliance on or an outright backlash towards penetration testing. Use of static analysis tools and code review, while on the rise, has not reached ubiquity in response (We’ve yet to see what will happen in a broader context, having only completed what I consider to be the early-adopter phase).
What do we do about it? Partnering more closely with customers has been something I’ve felt very strongly about. Listening more closely to them remains crucial. Even involvement at this level can be tricky to fund at all but the most interested customers.
There’s work to do as vendors too. Because, while we’re through the missionary phase, we’re not through the education phase in security. We must spend more time helping clients understand what attainable next steps look like for them. Moreover, I think we have to work with them to solve some of the problems we’ve avoided: we need to clarify salient next steps ;-)
How are we really going to get enough security knowledge in the hands of developers to change their behavior in a sustainable way? How are we going to scale code analysis so that it has some of depth of expertise, manually applied, but all of the consistency and speed of automation?
Technorati Tags: software security
March 6th, 2008 at 7:01 pm
People can evangelize about static analysis, developer education, and so on all they want, but look at Microsoft’s experience: even vast investments in these techniques provide only marginal improvements. Meanwhile we build systems with direct Firewire connections to DRAM so that everybody can save the hassle of having to acquire liquid nitrogen in order to read each other’s disks.
The problem is we don’t know how to design and architect secure systems of the size and complexity that customers need. And until we learn, they’re going to continue to laugh at our silly efforts to provide unworkable patchwork solutions that are expensive and don’t pay off in the end.
Evangelism is fun, and we security guys are pretty bright, so we have a hard time admitting that sometimes the guy in the room wearing no clothes is us.
March 7th, 2008 at 10:06 am
Tim,
I’ll let the next 12-24 months of ‘history’ show us where static analysis goes. But, I appreciate your more punchy final paragraph. Looking at mine, I was implying the same, and challenging not only those that design systems but also those that help companies deploy security methods to think harder about solutions that wouldn’t be seen as silly.
You and I worked together, once long ago at Cigital. At the time, Cigital’s researcher would have rousing conversations about how to use their own thoughts in concert with research that had come prior to make things better. The good news is that I finally feel surrounded by a critical mass of people 1) aware enough of what’s come before them and 2) in possession of enough mental horsepower to apply it to today’s software technologies.
…better yet, I’m finding some of their “rare gem” types in client organizations!
March 11th, 2008 at 8:36 pm
I can’t come up with a number for how much money I spend on car safety every year. When I buy a car, I pick the safest I can afford, but my choices are limited. I might have to buy new tires, but I can’t quantify how much safety I get per dollar. I think computer security is in the same situation. (Or worse. Cars have federal safety standards, and if someone tried to sell a completely bogus safety add-on, he’d be arrested.)
As a customer, you can’t spend money on computer security. The system vendor has to have spent that money at design time and during implementation. If they underspent, it’s too late to fix it.
The sad truth is that people don’t want to pay for computer security. (Or automobile safety. Read the drunk driving stories in the newspaper.)
I think we *do* know what to do about security. Why are people still writing operting systems in C?
John asks “How are we really going to get enough security knowledge in the hands of developers to change their behavior in a sustainable way?” and the answer is clear: stop rewarding bad behavior.
“Code analysis” is good but cannot be applied to random code written by strangers. It only makes sense as part of a comprehensive theory of how a product will be assured to a desired level.
A long time ago my friend Roger showed me his plan to write a file system. I forget the exact numbers: say six months of coding and six of debugging. I said, “Let me get this straight. You are going to write mixed good code and bugs for six months, and then spend six more taking the bugs out.” Roger said, “Gee, when you put it like that it sounds sort of dumb.”