Budgeting for Web Application Security

“Budgeting” is a word I’ve been hearing a lot of questions about recently, which is another data point demonstrating that Web application security and software security are increasingly becoming a top of mind issue. The challenge that many security professionals face is justifying the line item expense for upper management. Upper management often asks, “How much do we need to spend?” well before “What do we need to spend it on?” I was talking with Boaz Gelbord (Executive Director of Information Security of Wireless Generation) and several others about this, and they provided keen insight on the subject. I have identified the following approaches to justifying security spending:

1) Risk Mitigation
"If we spend $X on Y, we’ll reduce of risk of loss of $A by B%."

2) Due Diligence
"We must spend $X on Y because it’s an industry best-practice."

3) Incident Response
"We must spend $X on Y so that Z never happens again."

4) Regulatory Compliance
"We must spend $X on Y because PCI-DSS says so."

5) Competitive Advantage
"We must spend $X on Y to make the customer happy."


Risk Mitigation
Risk mitigation is the efficient, forward thinking, and scientific approach to security. Many extremely bright people are pushing this methodology forward, especially through SecurityMetrics.org. I’ve had the pleasure of rubbing shoulders with many of them at Metricon events including Andrew Jaquith, author of Security Metrics: Replacing Fear, Uncertainty, and Doubt, who does a stellar job of walking the reader through this world. The fundamental idea is to find an acceptable balance between the amount of investment and the risk reduction that represents "good enough."

While measuring investment against risk makes sense, it is also extremely difficult to quantify in Web application and software security given our industry’s lack of data. We don’t yet have strong data tying loss to root cause and those compromised closely guard the details. Only recently, through WhiteHat Security and WASC Statistics projects are we getting a wide look at who is exposed to what. Also remember that just because a vulnerability exists, doesn’t mean it’ll get exploited. Possible != Probable. My hope is that this approach continues to mature and becomes a widely accepted reality.


Due Diligence
Due diligence is another approach to security budgeting that considers the ramifications of a data compromise if it occurs. Among other things, upper management will want to assure customers and business partners that they were investing resources into the security program in line with industry standards. At the same time, a budget executive may not approve a larger than average security budget in the event no security incident occurs during the fiscal year. This common scenario prompts the question as Boaz puts it, “What is industry standard for security spending in Web application security or software development?” For example, with regard to IT backend systems, there are studies that suggest 3-10% or higher for security spending out of the total budget. In this context, the "Security needs to be embedded into every part of software development" mantra isn’t helpful.

To the best of my knowledge there has been no formal study or survey on how much organizations are spending or should be spending regarding security in software development (or webappsec specifically). What most organizations typically do is outline the best-practices (architectural reviews, security QA, pen-testing, WAF, etc.) they should be implementing relative to peers. Next, they identify the appropriate solutions and obtain rates from the vendor.


Incident Response
Few things free up security dollars faster than a data compromise that is publicly attributed to the organization. That last part is really important. It is possible for an organization to ignore a general Web server compromise, which they may not even know about. For example, when the bad guys are only interested in using a company's resources to improve the Google Rank of some website (i.e. Al Gore’s Convenient Truth blog). Things get much different though when a revenue-generating website is SQL Injected and begins delivering malware to its visitors which has already affected millions of users. The result is the website gets blacklisted by the search engines and traffic sinks like a rock. Now we are talking real quantifiable losses that get people's attention.

At this point an organization is in triage mode. How do they best remove the malware, get off the blacklists (may take days or weeks), and continue business operations? This is also a good time for a security professional when they are given license to pursue projects that ensure a similar event never happens again. They’ll be given the necessary resources to be proactive. They then have the power to prioritize activities that may fall into the category of Risk Mitigation without having to justify “why.”


Regulatory Compliance
Regulatory compliance is a huge justification lever for security professionals. Compliance pressures enables them to do the things they want/need to and gives them the ammunition to justify their requests. For many security professionals, this is of course a very welcome development. And again as Boaz lays it out, “it is much easier for me to justify costs that are legally mandated instead of pointing to threats that in practice are not very likely to materialize. As a citizen/user it is also a positive development, since without legal requirements I think that the already poor state of software/application security would get even worse.” Still the challenge is that most regulations do not indicate how far organizations must take these measures so the mileage will certainly vary.


Competitive Advantage
Competitive advantages. Every organization needs them, and wants more of them. Security that can be demonstrated or made visible can be used as a competitive advantage. Sure, security adds cost to the goods, but that fact could be capitalized on if the customer assumes a level of risk. As Bruce Schneier says, “you can feel secure even though you're not, and you can be secure even though you don't feel it.” For example, the McAfee Hacker Safe or secured via SSL logos can be seen as one of those things that makes consumers “feel” safer when conducting e-commerce. A firm can also engage with a reputable security firm to get a security assessment that can be shared. Deciding which to go with is directly proportional to the customers level of understanding.


At the end of the day no one can say if any one way is the right way, and that was not my intention, but instead to document the approaches I’ve seen gain a better understanding of what works best for a given environment. In order for Web application security and software security to improve, more dollars need to be allocated, so we must assist the stakeholders in that process as best we can.