07-05-2009 15:30 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 :: Povezani zapisi: 03-11-2010 9:39 Vordel SOAPbox for analyzing Webservices Security Using SOAPbox, you can: Test Web services residing in your internal network, or provided from the Web, or in a cloud environment. SOAP-style and REST-style services and SOAP attachments are supported. Test Web services that require encrypted input. Test Web services (...) - Security Tools / Application Scanner, Connectivity, Configurations checks, SOAPbox security-database 03-09-2010 18:27 Three Steps to a Rational Security Budget Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:
Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets. Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. So applying the flat tax, our Jones Widget's budget look like this IT System IT Budget Initial InfoSec Budget Customer Systems $5M $350k Order management $2M $140k ERP $1M $70kNotice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets. Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA. So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems IT System IT Budget Updated InfoSec Budget Customer Systems $5M $280k Order management $2M $224k ERP $1M $56kThere's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it. 1raindrop 03-09-2010 18:27 Three Steps to a Rational Security Budget Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:
Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets. Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. So applying the flat tax, our Jones Widget's budget look like this IT System IT Budget Initial InfoSec Budget Customer Systems $5M $350k Order management $2M $140k ERP $1M $70kNotice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets. Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA. So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems IT System IT Budget Updated InfoSec Budget Customer Systems $5M $280k Order management $2M $224k ERP $1M $56kThere's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it. 1raindrop 03-10-2010 18:47 Microsoft re-release of KB973811 - attacks on Extended Protection for Authentication, (Wed, Mar 10th) Yesterday Microsoft re-released KB973811 ==http://www.microsoft.com/technet/security/advisory/973811.mspx This relates back to the original KB973917 == http://support.microsoft.com/kb/973917 and advisory MS09-071 ==http://www.microsoft.com/technet/security/bulletin/ms09-071.mspx This affects the Extended Protection for Authentication functions within XP, Vista and Server 2003 ==http://support.microsoft.com/kb/968389 It didn't show up in yesterday's Patch Tuesday review because Microsoft is classifying it as a non-security upgrade. This is confusing to me, because the update actually includes mitigation against a credential forwarding attack, which you might see on an unencrypted, unsigned connection (yes, there's still a lot of that going around ! ) This update affects XP, Vista and Server 2003. Windows 7 and Server 2008 are not affected. Thanks to our readers on letting us know about this one. I'm still puzzled as to why this wasn't on Microsoft's list of security updates ... =============== Rob VandenBrink Metafore =============== ISC |
