Business Cases For Software Security Initaitives

I covered the topic of business cases for software security in the past in published articles (ISSA Journal 2006, In-secure Magazine 2008) as well as in presentations to security conferences (Black Hat in 2006 and OWASP in 2008). When asked how I can make the business case for software security I articulate my answer as by following these basic criteria:

1) Approach the business case from software security risk management perspective
2) Quantify software security failure costs with data that show where security issues are introduced when are tested and the cost to fix them
3) Justify software security expense with cost vs. benefits analysis that is the cost of software security failure costs vs. the benefit of adopting software security
4) Adopt a long term investment strategy: software security activities provide for higher return in the long term

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

A pre-requisite for the software security initiative business case is the availability of the organization risk data that include risk management, vulnerability metrics as well as of software engineering data such as defect management. 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 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, being a security bug, a design flaw or a mis-configuration.

The problem of the security metrics is that implies that the organization software and information security practices have matured enough to have data from risk management, fraud management, vulnerability assessment, software engineering/project management, quality assurance measured and correlated. A metrics that correlates software engineering and information risk management for example, not only implies that development teams have already started adopting security in the SDLC (e.g. by using processes such as MS SDL, OWASP CLASP, Cigital ™TP) but also that they have started working together with security teams to measuring software security risks and manage them through the SDLC.
Basically the business case can be made with 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 software security.
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.
From information security perspective, the business case for software security can be best made using the organization's information risk management data such that show the business impact of application vulnerability exploits to data assets for example.

So what are the alternatives in absence of the organization information risk management data? If the business case needs to be made by engineering and software development teams for example, you can assume a software engineering perspective and refer to public studies that analyze the cost of "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 localize this metrics to how much it would cost to your organization to fix vulnerability from quality/defect management perspective. Assuming your organization had adopted a web application penetration testing process, some vulnerability metrics can also be used and correlated with the cost of fixing them.

If your organization application security and information security practices are reactive rather than proactive, you can refer to the cost of producing security patches (e.g. hotfixes) to fix vulnerabilities. In absence of company data you can make assumptions such as that the cost of engineering, developing, testing and deploying a patch to your vulnerable software/web application is let say $ 10,000: it is realistic to assume that the fixing this patch earlier in the SDLC would have cost you 10% of patching costs and made saving your company 90 % of overall patching costs (e.g. 9,000 $)

But just assume patching costs is not enough for estimating 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 for example SQL injection vulnerabilities represents the ones that most likely will be exploited to cause harm to your organization. Since are the ones that would have high failure cost (e.g. use for break into authentication, upload malware, denial of service, un-authorized access to sensitive data), when mitigated would provide the most benefit in terms of countermeasure to high business impact attacks.Since SQL injection vulnerabilities root cause is coding errors such as using concatenated SQL statements instead of store procedures or prepared statements, fixing SQL injection vulnerabilities alone would make the case of the cost of adopting secure code reviews to identify SQL injection vulnerabilities in the source code.

Most organization's directors of technology make the high pitch on technology as "money for the bang". The question is if I spend that much on a security technology, process what is the benefit in terms for increased security for my organization? In technical terms this means doing a Cost vs Benefit Analysis (CBA) and use the analysis to correlate 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". In the case of software security, to make "money for the bang" decision spending you might need to take into account all failure costs (the is the total cost of failing, to fixing the defect and to maintaining it. The cost of failure can be compared against the "anticipation costs" that are the costs of proactively spending in software security initiatives. Failure costs decrease exponentially as anticipation cost raise, that means as I am spending more on countermeasures I reduce the impact of a failure cost. From risk management perspective this means that the overall software security costs decrease up to a minimum and then raise again when you spend more money in countermeasures than the money you will lose because of software failure. The optimal spending for countermeasures is about 40% of the failure costs and this is a figure that you can take as a reference when deciding how much to spend on a software security tool or technology, a new software security process as well as new training activity.

How this optimal cost in anticipating software security failures can be useful for software security initiatives business case decision making? Assume your organization has fraud data can be correlated to the e-business channel being used for fraud such as web for example: spending as much as 40% of the failure costs in security initiatives would be justified according to cost vs benefits analysis. Let's take for example some public metrics of data losses such as PII such as the one from datalossdb.org. The public disclosed data shows that 14% of incidents occur via the web channel then you can factor the web security failure costs accordingly. In lack of organization data, take into account the possible impact on data losses because of attacks to your e-commerce channels factor this as 14% to factor the impact of exploiting of web application vulnerabilities.

Besides cost vs benefit analysis, a software security business case can be made around effectiveness such as by using the (Return of Security Investment) ROSI analysis. 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 David Soo Study IBM" for every 100K spent on software security, 21K are saved by doing application threat modeling during design, 15 k are saved by doing source code analysis and 12 k are saved when defects are found with penetration tests. Overall the earlier you invest in security the greater the return.


OWASP ::  Feed!



Povezani zapisi:

09-03-2010 8:49

cloudprotection.pandasecurity.com XSS

searchsecuritychannel.techtarget.com XSS

securitycenter.verisign.com XSS

www.m86security.com XSS