This was posted to a LinkedIn group I monitor:
Why Does Software Security Keep Falling off your Budget?
I wound up penning such a passionate response that I figured I would copy it here for my reader(s) amusement…
I like the focus on metrics, though I am not sure it gets us any closer to a resolution. How do you measure defects you haven’t discovered yet in code? How do you assess the vulnerability of an application that is not subject to attack by skilled, dedicated, highly motivated crackers? If a truly skilled white hat can get 100x his current income turning to the dark side, then decides to do so while maintaining his white hat persona, how the heck would we know? When she tells us our applications are secure is it because she hasn’t discovered an exploit because there aren’t any (yea, right), discovered an exploit but wants to sell it, or isn’t smart enough to find the exploit? Measuring the absence of something is challenging, proving something is secure without blowing up your budget AND being able to have high confidence in your result is nearly impossible.
And once all is said and done, even with perfect coding (like that will ever happen with us humans churning out the code), there can be design flaws that go undetected. There could even be a ‘perfect’ design, ‘perfectly’ implemented that still becomes insecure because of changing environment. When can the bosses be assured that they can finally stop spending money on securing an application? It is not hard to view us as charlatans that are just out to make a buck spreading FUD since we really can’t say we are doing anything meaningful. Then, to make matters far worse (as if that could be the case), from a business / economics point of view sometimes (often) there is a strong case that security simply doesn’t matter (at least until the company gets sued, but even then they can simply build that cost into the profit margins).
Since perfect security is probably unattainable it is not unreasonable for us to be ignored by management, even (especially) highly educated management. The way I like to characterize infosec is analogous to the hikers being chased by a hungry bear. You don’t have to be faster than the bear, just faster than the slower guy. If your organization has been specifically targeted by a “skilled, dedicated, highly motivated cracker” then there isn’t much you can do about it. However, you can avoid the random hungry bears by doing lots of little, fairly inexpensive things, things to raise the bar to the point where only “skilled, dedicated, highly motivated crackers” can penetrate your system, so the bear will move on to some other organization.
There is a lot of really crappy code written, even by people who know better. I think that security should be presented as a way to make applications with fewer bugs that will embarrass the organization, potentially costing them money through lost customers (or even customer suits). If we could get ourselves inserted into the design phase and have substantial input on the development process (insisting on such silly things like test suites, regression tests, independent (and well compensated) testers, etc.) I think we could have a much greater impact.
To get anyone (who controls money) to care, we are going to have to stop with the FUD and start presenting things from the perspective they care about.