Business Cases For Your Software Security Initiative

I dealt with the topic of the business case for software security initiatives in the past: you can refer to published articles (ISSA Journal 2006, In-secure Magazine 2008) and presentations(Black Hat in 2006 and OWASP in 2008). Interesting enough, this seems to be still an hot topic: I am often inquired on this by CISOs and CIOs in the past as well in my current ISO work, hence I decided to articulate my answer again with more details with this post.

Building software security into the organization’s software engineering and information security practices can be accomplished by following software security maturity models (e.g. BSIMM or SAMM) as well as by adopting software frameworks to integrate software security activities within the SDLC along with security processes such as information risk management, patch management and security training and awareness.

From the software engineering perspective for example, the assumption is that your organization already measures the costs for fixing software security failures due to known vulnerabilities as well as the cost of fixing the ones resulting from incidents/exploits. Total software security failure costs include both the cost of business impact in exploiting software failures (e.g. cost of a vulnerability exploit that caused harm to the organization such as denial of service) as well as the cost to fixing a known defect due to a security issue found with testing, being a security bug, a design flaw or a mis-configuration.

The problem of the software security metrics is that implies that the organization software and information security practices are matured enough to produce this data so you can correlate this information from risk management, fraud management, vulnerability assessment, software engineering/project management and quality assurance. The availability of such metrics implies that development teams have already started to build software security activities into the SDLC such as source code analysis, penetration testing, threat modeling but also that they have started working together with security teams to measure software security risks and manage them during the different phases of the SDLC.

A pre-requisite for any software security initiative business case is the availability of the organization's information risk data that include risk management, vulnerability metrics as well as software security engineering data such as defect management and patch management.

From information security perspective, the business case for software security need to start from the organization's information risk management data, business impact analysis and correlate application vulnerabilities as critical when these correlate to business impacts. For this reason (i.e. the lack of organization software security data) the business case for software security is one that is hard to make.

Based upon my experience on the topic, that is working both as consultant as well as security technology officer for large software organizations, you can make the business case (or the case for the business) for software security initiative by following the approach outlined herein:
1) Adopt an information risk management perspective, that is using your vulnerability, incident and fraud data for the business case
2) Gather software engineering data and categorize them in terms of when are found, when are fixed, when the fixes are tested and deployed. Correlate this data on how much it costs to fix vulnerabilities at different phases of the SDLC.
3) Gather data on security incidents and fraud because of the application/software being attacked. Quantify in dollar amount how much these security incidents and fraud cost to your organization.
4) Analyze the business case by analyzing/quantifying the following factors:
• Cost vs. benefit: by comparing software failure costs vs. security assumption costs
• Quantitative risk: by comparing cost of mitigation vs. impact of probable loss
• Return of Security Investment (ROSI): by quantifying $$ saving amounts for adoption of software security activities early in the SDLC

Basically the business case for the software security initiative needs the data that the initiative is suppose to provide. In essence this is a chicken vs. egg problem you can only manage what you measure and you need metrics to make the business case for.

So what are the alternatives for the business case in absence of such data ? You need to make assumptions on what are you software engineering costs, estimate the cost of patching and to fix vulnerabilities as well the security costs because of software failing such as for example financial losses that vulnerability exploits might cause, include for example the cost of loosing customer data, money losses because of fraud via the web channel, disruption or denial of service and least and not last intangible reputation loss because of vulnerabilities being publicly disclosed.

The data to produce for the case depends on who the case is made for. If the business case needs to be made for engineering and software development teams for example, you can assume a software engineering perspective. You can refer to public studies that analyze the cost of fixing software defects.

A NIST study on the economic impact of insecure testing for example shows that cost of fixing defects is 100 times more expensive during system testing than coding. You can tailor this data to estimate how much it would cost to your organization fixing vulnerability from quality/defect management perspective. If development teams already started doing vulnerability assessments such as by including web application penetration testing in the SDLC, the vulnerability metrics can also be used and correlated with the cost of fixing them.

If your organization is mostly relying on patching to fix security defects, you can refer to the cost of producing security patches (e.g. hotfixes) to fix vulnerabilities vs. the cost saving of testing and fixing software security defects earlier in the SDLC.

Let's say the cost of engineering, developing, testing and deploying a patch to your vulnerable software/web application is 10,000: it is realistic to estimate using NIST data that the fixing this patch earlier in the SDLC would have cost you 10% of the patching costs and your company 90 % of overall patching costs (e.g. 9,000 $)

Just including patching costs is not conservative enough for a real estimate of total software security failure costs: you need also to include the business impact of exploits such as either the risk of exploiting a known vulnerability or an unknown vulnerability (e.g. Zero Day) such as the ones exploited and do not follow responsible public disclosure causing the organization intangible costs..

Even in absence of a vulnerability exploit it is still important to factor the cost posed by the business impact to the organization caused by the exploit of the vulnerability. In the case of intangible costs for example what is the intangible cost of cross site scripting vulnerability publicly disclosed on XSSEd.com site? How much is the cost of reputation damage to have such vulnerability publicly disclosed? Any public published vulnerability can cause intangible loss to company reputation, the company brand and the franchise and affect customer confidence on the company product and services.
Would intangible costs by themselves justify the existence of a responsible disclosure process to engage security researchers that have found your site vulnerabilities: YES. Would this justify fixing all known vulnerabilities before going into production with a penetration test? YES

But to really factor software failure costs as the business impact of exploiting a vulnerability it is important to correlate attacks with vulnerabilities and the business impact that cause. The recent data from the Web Hacking Incident DB that correlates public information from security incidents with web application attack vectors for example has SQL injection as #1 (19% of all attacks) that includes manual targeted attacks as well as mass SQL injection bots. From the perspective of attack vs. risk prioritization SQL injection vulnerabilities represents the ones that most likely will be exploited to cause harm to your organization and are the ones that would produce high failure costs (e.g. use for break into authentication, upload malware, denial of service, un-authorized access to sensitive data), when mitigated, SQL injection vulnerabilities would provide the most benefit in terms of mitigating business impacts.Since the SQL injection vulnerabilities root cause is coding such as using concatenated SQL statements instead of store procedures or prepared statements, fixing SQL injection vulnerabilities in the code alone would make the case of adopting secure code reviews.

Most organization's directors of technology and security try to sell technologies and new initiatives to high management with the sales pitch of getting the most "Bang For The Buck" BFTB. But the BFTB business case need to answer the basic question: if I spend that much on a security technology or process what is the benefit for security ? In technical terms this means doing a Cost vs Benefit Analysis (CBA). CBA can be used in security to correlate the total cost of security to increased information or software security assurance. Dan Geer covers well this analysis as related to data security in his book "Economics and Strategies of Data Security".

By analogy, in the case of software security, "Bang For The Buck" decision spending need to take into account the total security costs that is all failure costs such as the total cost of failing as business impact as well the total cost of finding, fixing, testing and deploying the security defect. Only then, the total cost of software security (the BUCK) can be compared against the BANG that is the increased level of software security assurance.

The general law for bang for the buck is that you are getting the most bang for the buck when your total costs (cost of failure/data loss/fraud + cost of security/countermeasure) reaches a minimum. As failure costs decrease exponentially, the "anticipation costs" that you take proactively by spending in software security initiatives will increase.

From risk management perspective this means that the total software security costs decrease up to a minimum to raise again as you keep spending on security measures. You will reach an optimal cost vs. benefit where more spending in anticipation cost (e.g. countermeasures) will not provide the most benefit (e.g. spending more in countermeasures then the value of the assets that the countermeasure is supposed to protect)

This optimal spending for anticipation costs (proactive countermeasures) is about 40% of your failure costs (to be exact 37% according to Gordon and Loeb research: The Economics of Information Security Investment).

According to the empirical law of the most bang for the buck applied to software failure costs vs. assumption costs it is therefore fair to assume that you get the most of security by spending 37% of what your software failure costs are.

Assume for example software security failures costs are $ 10 ML it would be reasonable for an organization to spend as much as $ 3.7 ML in acquiring software security tools and technology, develop new software security process as well as in new software security training activities.

Application security failure costs can be also factored as monetized fraud occurring via your web site/channel: a spending of as much as 37% of the fraud costs in securing the web site can be justified according to the most bang for the buck law.

In the case of business impact due to data loss such as identity theft for example, you can factor the overall fraud related to data loss potentially impacting your organization: consider that 14% of all publicly reported data loss incidents occur via the web channel according to the data collected from datalossdb.org.

Assume that according that 2003 FTC data the potential loss per identity theft incident is $ 655 per incident. Assume you are serving via your web site a population of 4 million customers, the potential loss of losing your customer data such as credit card accounts for example would be of $ 2,6 Billion and with probability of identity theft occurrence of 4.6 % (also FTC data) the projected loss for your company could be $ 120 ML for which 14% or $ 16 ML would be the cost of data losses via the web channel alone.

With these assumptions based upon publicly disclosed data losses, a security program (that include both information and application security) that cost as much as $ 16 ML would be justified for a company with a customer base of 4 million on-line customers for example.

A quantitative risk assessment can also be used to determine the extent on which a software security initiative can reduce risk from potential losses. The correlation has to take into account the probability of the event and the loss that the event can cause. This is difficult to quantify in general for software security issues since assumes a cause-effect between vulnerability exploit and financial impact. Nevertheless it can be used for rough estimates.

Assume a web application that delivers banking services for example and that the loss caused by an event such as denial of service impact on-line transactions for 3 million customers with an average of $ 20 per transaction: the loss per single DOS event (SLE) is $ 60 ML.

Assume that the probability that a new SQL injection vulnerability would cause a denial of service is 30% (Annualized Rate of Occurrence) then the Annual Loss Expected (ALE) is $ 1.8 ML. If the cost of the new security countermeasures that will stop the security incident is less than $ 1.8 M than the organization should implement it.

Assume the countermeasure in this case is the total cost of secure code reviews, you need to factor the cost of tools and technologies/APIs (e.g. source code analysis and penetration tools), of the security engineering process (e.g. documentation and metrics) as well of software security training and awareness for developers. The tools and technologies need to include the Total Cost Of ownership that is both the cost of acquiring and maintaining the technology.

Besides cost vs benefit analysis and quantitative risk assessment, the return of security investment (ROSI) can be used to make the software security business case around effectiveness of a software security initiative.

ROSI answers the question if I spend $ 100K in software security initiative do I save more money by fixing defects with a penetration test, secure coding or threat modeling. Again this is where the metrics is essential:making the case with ROSI assumes you already collect SDLC data that show how much it cost to perform software security per each phase, the number of issues being identified at each phase and the how many are fixed at each phase you can make the business case for an activity vs another. Otherwise you can reference public study of ROSI from Kevin Soo Study " for every $ 100,000 spent on software security, $ 21,000 are saved by doing application threat modeling during design, $ 15,000 are saved by doing source code analysis and $ 12,000 are saved when defects are found with penetration tests. Overall the earlier you invest in security the greater the return.