CISO AppSec Guide: Reasons for Investing in Application Security
- 1 Part I: Reasons for Investing in Application Security
- 1.1 Executive Summary
- 1.2 Introduction
- 1.3 Information Security Standards, Policies and Compliance
- 1.4 Risk Management
- 1.4.1 Proactive vs. Reactive Risk Management
- 1.4.2 Asset Centric Risk Management
- 1.4.3 Technical vs. Business Risk Management
- 1.4.4 Risk Management Strategies
- 1.4.5 Threat Analysis and Awareness of Emerging Threats
- 1.4.6 Addressing the Business Concerns after a Security Incident
- 1.4.7 Budgeting of Application Security Measures for Mitigating Risks of Data Breach Incidents
- 1.4.8 Considering Costs and Benefits of Application Security Measures Before Making Investments
- 1.4.9 Analyzing Security Measures as Investments
- 1.4.10 Conclusion
Part I: Reasons for Investing in Application Security
In this digital era public and private organizations serve an increasing number of citizens, customers, and employees through applications. Often these applications provide “highly trusted services” over the internet, including functions that bear high risk for the business. For bank customers, these are feature rich functions that include opening bank accounts, paying bills, applying for loans, transferring funds, trading stocks, and viewing bank statements. These applications are the target of an ever-increasing number of fraudsters and cyber-criminals. Many incidents result in a denial of online access, breach of customer data and online fraud.
Chief Information Security Officers (CISOs) are tasked to enforce application security measures in order to avoid, mitigate and reduce security risks affecting the organization's ability to deliver on its mission. This evolving threat landscape further drives audit, legal and compliance requirements. CISOs must create a business case for investing in an application security program. The business case should be mapped to the security threats on the business and the program services necessary to serve as a countermeasure. Industry security spending benchmarks and quantitative risk calculations provide support to security investment budget requests.
Applications have grown increasingly critical in organizations. Oftentimes delivering critical services with legal and regulatory requirements. For bank customers, these are feature rich functions that allow them to open bank accounts, pay bills, apply for loans, book resources and services, transfer funds, trade stocks, view account information, download bank statements and others. This online experience is convenient for people: it allows them to perform the same financial transactions as being at the branch/office/outlet, but with the added convenience of conducting these transactions remotely from their home computer or mobile phone. At the same time, this convenience for customers comes at a price to the financial organizations involved in developing and maintaining these applications. Online banking and commerce sites for example, have become the target of an increased number of fraudsters and cyber-criminals and victim of security incidents. Several of these incidents resulted in a denial of online access, breaches of customer’s data and online fraud.
In the case of data breach incidents, often these attacks from fraudsters and cyber-criminals involve the exploitation of applications such as SQL injection to compromise the data stored in the application database and cross site scripting to execute malicious code such as malware on the user’s browser. The targets of these attacks are both the data and the application business functions for processing this data. In the case of online banking applications, the data targeted by hacking and malware include personal data of individuals, bank account data, credit and debit card data, online credentials such as passwords and PINs and last but not least, alteration of data in on-line financial transactions such as transfers of money to commit fraud. Verizon’s 2012 data breach investigations report identifies hacking and malware as the most prominent types of attack, yielding stolen passwords and credentials, and thus posing a major threat to any organization that trades online.
To cope with this increase of incidents targeting applications such as denial of services and data breaches often caused by hacking and malware, Chief Information Security Officers (CISOs) have been called by company’s executives such as the Chief Information Officer (CIO), Legal Counsel or Chief Financial Officer (CFO) to build and enforce application security measures to manage application security risks to the organization. For financial organizations for example, the increasing threat to applications such as online banking applications challenges CISOs to enforce additional application security controls an increase the investment in application security to cope with the increasing risk.
Due to the evolving threat landscape and increased pressure from audit, legal and compliance, in the last decade, investments in application security have been a growing proportion of overall information security and information technology budgets. This trend is also captured in applications security surveys such as the 2009 OWASP Security Spending Benchmarks Project Report that for example stated "Despite the economic downturn, over a quarter of respondents expected application security spending to increase in 2009 and 36% expected to remain flat". Furthermore, in the 2013 OWASP CISO Survey, 87% of respondents indicated that application security investment would either increase or remain constant (CONFIRM CISO SURVEY DATA). Nevertheless, making the business case for increasing the budget for application security today remains a challenge because of the recession economy and prioritization of spending for development of new application features and platforms (e.g. mobile devices), initiatives to expand service uptake or profitability, and marketing to attract new customers and retain existing customers.
Ultimately, in today’s recession type of economic climate and in a scenario of slow growth in business investments including the company’s built-in software, it is increasingly important for CISOs to articulate the "business case" for investment in application security. Since it also appears to be a disconnect between organization's perceived threats (application security threats are greatest) yet spending on network and infrastructure security is still much higher, we would like to shed some light on the business impact of data breaches due to application vulnerability exploits and how much these might costs to organizations.
Typically, additional budget allocation for application security includes the development of changes in the application to fix the causes of the incident (e.g. fixing vulnerabilities) as well as rolling out additional security measures such as preventive and detective controls for mitigating risks of hacking and malware and limiting the likelihood and impact of future data breach incidents.
CISOs can build a business case for additional budget for application security today for different reasons; some directly tailored to the specific company risk culture or appetite for risk; others tailored to application security needs. Some of these needs can be identified by the analysis of the results of application security surveys. To assess these needs, readers of this guide are invited to participate to the OWASP CISO Survey so that the contents of this guide can be tailored to the needs of CISOs participating of the survey. The 2013 OWASP CISO Application Security Survey shows an increased perception of risk of application targeted threats and shifts the organization investment from the traditional network security to application security: about 48% of CISOs have seen the investment in application security increasing as part of the company's annual budget, 37% consider it relatively constant and only 15% have seen a decrease (CONFIRM CISO SURVEY DATA).
The budgeting for application security measures might depend on different factors such as compliance with security policies and regulations, operational risks management including the risks due to application vulnerabilities and the response of security incidents involving applications. For the sake of this guide we will focus on the following areas to target application security spending:
- Compliance with security standards, security policies and regulations;
- Identification and remediation of application vulnerabilities;
- Implementation of countermeasures against emerging threats targeting applications.
Nevertheless, assuming the business cases can be made along these goals, CISOs today still have the difficult task to determine “how much” money should the company spend for application security and “where” that is on “which security measures” to spend it. Regarding the how much, often it gets down to how much is needed to invest to satisfy compliance requirements and pass the auditor’s check. When the focus is compliance, the focus is to develop and implement application security standards and map these security requirements to current projects. When the focus is vulnerability risk management, the main goal is to fix high risk vulnerabilities and to reduce the residual risk to an acceptable value for the business. When the focus is to security incident management, the focus is how to investigate and analyzed the suspected security breaches and recommend corrective actions. When the focus is application security awareness, the focus is to institute application security training for the workforce.
For today’s CISO there is an increased focus on making decisions for mitigating risks. Both for mitigating real risks (e.g. incidents, vulnerability exploits) and for mitigating non-compliance risks (e.g. unlawful non-compliance), the question for CISOs is "where" and "how" to prioritize the spending of the application security budget. Often the question is which countermeasure, application security process, activity, security tool yields “more bang for the money” for the organization. Regarding the "where" it comes down to balance correctly different application security and risk domains - to name the most important ones: business governance, security risk management, operational management that includes network security, identity management and access control and incident management. Since as a discipline application security encompasses all these domains, it is important to consider all of them and look at the application security investment from different perspectives.
Information Security Standards, Policies and Compliance
Identifying Standards and Policies in Scope for Compliance
One of the main factors for funding an application security program is compliance with information security standards, policies and regulations mandated by applicable industry standards regulatory bodies. Initially, it is important for the CISO to define what is in scope for compliance and how it affects application security. Depending on the industry sector and the geographical location in which the organization operates, there will be several different types of security requirements that the organization need to comply with. The impact of these requirements is also on the applications that manage and process data whose security falls under the scope of these standards and regulations. The impact on applications consists on performing scheduled risks assessment and to report the status on compliance to the auditors.
Examples of data security and privacy standards that apply to applications in the US include:
- Payment Card Industry (PCI) Data Security Standards (DSS) for organizations whose applications process electronic payments with credit and debit card data
- FFIEC guidelines for US financial organizations whose applications allow clients and consumers to bank online and conduct transactions such as payments and money transfers
- FISMA law for US federal government agencies whose systems and applications need to provide information security for their operations and assets
- HIPAA law for securing privacy of health data whose applications handle patient records in the U.S. healthcare industry
- GLBA law for US financial institutions whose applications collect and store individuals’ personal financial information
- US State Data Breach Disclosure laws for organizations whose applications store and process US state resident Personal Identifiable Information (PII) data when this data is lost or stolen in clear (e.g. un-encrypted)
- FTC privacy rules for organizations whose applications handle private information of consumers in US as well as when operating in EU countries to comply with “Safe Harbor” rules
OWASP provides several projects and guidance for CISOs to help develop and implement policies, standards and guidelines for application security. Please consult the Appendix B: Quick Reference to OWASP Guides & Projects for more information.
Capturing Application Security Requirements
Most of applications that carry out payment transactions such as merchant type of ecommerce type of applications that handle credit cardholder data are required to comply with the Payment Card Industry Data Security Standard PCI-DSS. The requirements for the protection of cardholder data when is stored by the application includes several PCI DSS requirements such as the rendering or encrypting the Primary Account Number (PAN) and the masking the PAN when it is displayed. The PCI-DSS requirement for card authentication data such as PIN, CVC2/CVV2/CIDs is not to store these data at all even in encrypted form after a payment has been authorized. Credit cardholder data also need to be protected with encryption when is transmitted over open networks. These requirements for protection of cardholder personal account numbers and cardholder authentication data motivates the CISO to document internal security requirements to comply with these provisions and to adopt application security measures and assessment to verify that these requirements are met by the applications that are in scope. Besides protection of cardholder data, PCI-DSS has provisions for the development and maintenance of secure systems and applications, for testing security systems and processes and for the testing of applications for common vulnerabilities such as those defined in the OWASP Top Ten.
The need of compliance with the PCI-DSS requirements can be a reason to justify an additional investment in technology and services for application security testing: examples include source code security reviews with SAST (Static Analysis Security Testing) assessment/tools and application security reviews with DAST (Dynamic Analysis Security Testing) assessments. For a merchant that develops and maintains a web application such as an ecommerce web site that handles credit card payments, the main question is to whether allocate budget to application security measures and activities to comply with PCI DSS or to incur in fines (e.g. Up to $ 500,000 when credit cardholder data is lost or stolen. From this perspective, unlawful/noncompliance with a regulation/standard might be treated as another risk by the organization and as any other risk this could be mitigated, transferred or accepted. If risk of being non-compliant is accepted, CISO should considered that the data breach risk because of not implementing basic security controls such as data encryption but also input validation might be much higher than non-compliance. Consider for example the case of TJX Maxx incident. The company was non-compliant with PCI DSS when the breach of 94 Millions of credit card numbers were compromised, yet the non-compliance costs for failing to encrypt or truncate card numbers as well as to identify and mitigate application vulnerabilities such as SQL injection were less of the overall costs incurred by the businesses impacted because of this security incident of at least by a factor of thousand times higher (if not more) than the costs of not compliance with PCI-DSS (several hundredths of millions of US dollars vs. several hundredths of thousands of US dollars).
In the case of the U.S. banking sector, applications that handle sensitive customer information and allow to process financial transactions such as to transfer money between different bank accounts (e.g. wires) are subjected to comply with strong authentication such as multi factor authentication (MFA) requirements in compliance with Federal Financial Institutions Examination Council (FFIEC) guidelines for online authentication (Ref ). From application security perspective this means that FFIEC requirements for authentication of online banking sites can justify budgeting for application security measures to secure design, implement and testing the provision of MFA controls in the application.
For US consumers, privacy is regulated under different laws and regulations depending on the industry sectors. In the US financial sectors, laws that govern consumers privacy include GLBA laws and FTC rules. From GLBA compliance perspective, financial applications need to provide disclosure to application users of which PII is collected, processed and stored and how is shared among the financial institution businesses and affiliates including third parties. From FTC compliance perspective, organizations that store consumer PII need to disclose their due diligence security practices to consumers and can be considered liable when such practices are not followed as in case of breach of consumer’s private information and in clear breach of the license agreements with the consumers. Because privacy laws in US mostly require acknowledging to consumer that the personal data is protected the impact of security is limited to notifications and acknowledgements and “opt out” controls. Exceptions are cases in where privacy controls are implemented as application privacy settings (e.g. as in the case of Facebook) offered to users of the application as “opt in controls “to comply with the FTC Safe Harbor rules.
In general, applications that store and process data that is considered personal and private by country specific privacy laws need to protect such data when is stored or processed. What is considered private information varies country by country. For countries that are part of the European Union (EU) for example, personal data is defined in EU directive 95/46/EC, for the purposes of the directive: Article 2a: "personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;"
For most of the US States, protection of personal identifiable information (PII) is driven by data breach notification laws such as SB1386 where PII is more narrowly defined than in the EU directive as the individual's first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted: (1) Social security number. (2) Driver's license number or State Identification Card number. (3) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account. For purposes of these laws, "personal information" does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.
Applications that process and store data that is considered personal private data by EU privacy laws or PII by US States data breach notification laws, need to implement security controls such as authentication, authorization, encryption, logging and auditing to protect the confidentiality, availability and integrity of this data. These information security requirements are typically part of the information security policy enforced by the organization. These security requirements, indirectly translate in security requirements for applications that store and process data that is either considered confidential or confidential PII. Budgeting application security program for complying with personal and consumer data privacy requirements is justifiable both as internal compliance with information security policy as well as for mitigating the reputation damage to the organization in the case this data is either lost or compromised. In addition to reputation damage, organizations might incur additional regulatory fines and legal costs in because of unlawful and non-compliant with local privacy laws.
Proactive vs. Reactive Risk Management
Proactive risk management consists on focusing on mitigating the risks of threat events before these might possibly occur and negatively impact the organization. Organizations, whose focus is proactive risk management, plan to protect mission critical assets including applications ahead of potential threats targeting them. Proactive risk mitigation activities for applications include focusing on threat intelligence to learn about threat agents, application threat modeling to learn how the application can be protected by attacks from different threat agents, security testing and fixing of potential vulnerabilities in the application as well as in the source code before these are exploited by potential attackers. Pre-requisite for proactive risk management is have an inventory of the mission critical applications with associated risk profiles that allow CISOs to identify the critical digital assets such as data and functions that need to be prioritized and planned for proactive risk mitigation activities. CISOs whose organizations focus on proactive risk mitigation measures have typically adopted a risk mitigation strategy and act upon information from threat intelligence and monitored security events and alerts to raise the bar on acceptable technical and business risks. CISOs whose focus is proactive risk mitigation usually require the roll out of additional countermeasures ahead of new threats and new compliance requirements.
Reactive risk management consists on responding to risk events as they occur to mitigate negative impacts to the organization. Example of reactive risk management activities includes security incident response, security incident investigations and forensics and fraud management. In the case of application security, reactive risk management activities include vulnerability patch management, fixing application vulnerabilities in response of reported security incidents or when these are identified by third parties, performing application risk assessment due to occasional (not planned) requirements to satisfy specific compliance and audit requirements. CISOs whose organizations focus on reactive risk management typically spend more focus more on responding to unplanned risk management events. Often the focus of reactive risk management is "damage containment" to “stop the bleeding” and less focus is dedicated to planning for risk mitigation ahead of potential negative events targeting applications. Typically organizations whose focus is on reactive risk management have their CISOs spending most of their time on incident response and management and remediating application vulnerabilities either ahead of production releases or patching applications that are already released in production. When the prime focus of the CISO function is on reactive risk management, it is important to recognise that reactive risk mitigation even if cannot always be avoided because security incidents happen, it is not cost effective since the cost of remediating issues after these have been either reported or exploited by an attacker is several factors of magnitude higher than identifying and fixing the same by adopting preventive risk mitigation measures.
A proactive risk mitigation approach is preferable to a reactive risk mitigation approach when making the business case for application security. A proactive risk mitigation approach might consist on using the opportunity of a required technology upgrade of a application to introduce new functionality or when an old applications reached end of life and need to migrate to a newer system/platform. Designing new features to applications represents an opportunity for CiSOS to demand upgrade security technology to new standards and implement stronger security measures as well.
Asset Centric Risk Management
CISOs whose information security policies are derived for compliance with information security standards such as ISO 17799/ISO 27001 include asset management as one of the security domains that need to be covered. In the case when these assets include the applications, assets management requires an inventory of the applications that are managed by the organization in order to implement a risk management approach. This inventory includes information of the type of applications, the risk profile for each application, the type of data that is stored and processed, patching requirements and the security assessments such as vulnerability testing that are required. This inventory of applications is also critical to track application security assessments and risk management processes conducted on the application, the vulnerabilities that have been identified and fixed as well as the ones that are still open for remediation. The risk profile that is assigned to each application can also be stored in the application inventory tool: depending on the inherent risk of the application that depends on the classification of the data and the type of functions that the application provides, it is possible to plan for risk management and the prioritization of the mitigation of existing vulnerabilities as well as for the planning for future vulnerability assessments and application security assessment activities. One of the application security activities that take advantage of asset centric risk management is application threat modeling. From an architecture perspective, assets consist on the several components such as application servers, application software, databases and sensitive. Through application threat modeling, it is possible to identify threats and countermeasures for the threats affecting each asset. CISOs whose focus is on asset risk management, should consider implementing application threat modeling as proactive application security and asset centric risk management activity.
Technical vs. Business Risk Management
When deciding how to mitigating the application security risks it is important to make the trade off between technical risks and business risks. Technical risks are the risks of either technical vulnerabilities or control gaps in a application whose exploit might cause a technical impact such as loss and compromise of data, server/host compromise, unauthorized access to a application data and functions, denial or disruption of service as examples. Technical risks can be measured as the impact of confidentiality, integrity and availability of the asset caused by a technical event/cause such as vulnerability that is identified by a application security assessment. The managing of these technical risks typically depends on the type of the vulnerability and the risk rating assigned to it also referred to as "severity" of the vulnerability. The severity of the vulnerability can be calculated based upon risk scoring methods such as FIRST's CVSS while the type of vulnerability can be classified based upon the group that the vulnerability falls into such as using MITRE's CWE. CISOs can use the risk scoring of a vulnerability reported as HIGH for example to prioritize such vulnerability for mitigation ahead of vulnerabilities that are scored as MEDIUM or LOW risk. In making this technical vulnerability risk management decision, CISO won’t consider the economical impact of the vulnerability to the business such as in the case the value of the asset impacted by the vulnerability is either loss or compromised.
Business risk management occurs when the value of the asset is taken into account to determine the impact to the organization. This requires the association of technical risk of the vulnerability with the asset value to quantify the risk. The risk can be factored as the likelihood of the asset being compromised and the business impact caused by the exploit of the vulnerability. For example, in case that an high risk technical vulnerability such as SQL injection (assumed is fully, 100% exposed as a pre-authentication issue) is exploited, the business impact can be determined as impact to an asset such as data that is classified as sensitive data and whose value if compromised is estimated as $ 250/data record (e.g. based upon either internal incident cost estimates or publicly reported estimates). The aggregated value of the sensitive data of 100,000 records stored in a database that could be exploited by SQL injection is therefore $ 25 Million. If the probability of a sensitive data compromise due to the exploit of SQL injection vulnerability is estimated as 10 % (1 successful data breach incidents caused by SQL injection every ten years) the potential economical impact is a loss of $ 2,500,000. Based upon these estimates, it is possible to calculate how much to budget in application security measures (e.g. detective and preventive controls) for mitigating the risks to the business. It should be noted that estimating business risks is much more difficult than estimating technical risks since business risks estimates require estimates of likelihood of specific type of security incidents (e.g. data breaches) as well as the estimates of the monetary losses (e.g. loss of revenue, legal-compliance costs, incident cause repair costs) caused by that incident. Typically these estimates are not easy to make in absence of specific data and calculation tools that can factor the frequency of security data breach incidents and keep records of direct and indirect costs suffered by the organization as result of these security incidents. Nevertheless. statistical data of data breach incidents, estimates of the costs of data breach incidents as well as data breach quantitative risk calculators might help CISOs to estimate a value for business impacts ass these might be caused by the presence and exploit of vulnerability and decide how much is reasonable to spend in application security controls to fix the vulnerability as well as processes and training to reduce the risks for the business. Some statistical data for data breaches and risk calculation formulas and vendor supported tools are also provided in this guide as reference.
Risk Management Strategies
Once security risks have been identified and assigned a qualitative value such as high, medium and low risk, the next step for the CISO is to determine what to do with that risk. To decide “what to do with the risks” CISOs usually rely upon their organization's risk management processes and risk mitigation strategy. Risk management processes are usually different for each type of organization. At high level, risk management depends on the risk mitigation strategy that is adopted by the organization. Depending on the assessment of the level of risk impact and probability for example, an organization might decide to accept the risks whose likelihood and impact are low, mitigate or reduce the risks (e.g. by applying security measures) that have high probability and low impact, transfer or share the risks ( e.g. to/with a third party such as through contractual agreements) that are of low probability and high impact and avoid the risk (e.g. such as not to implement high risk functions, not to adopt high risk technologies) for risks that have high probability and impact. A visual example of this risk mitigation strategy factored by event likelihood and impact is shown in the diagram herein.
In the case high risks cannot be avoided because of business decisions requiring to mitigate them and risks cannot be transferred to third parties through contractual agreements and cyber insurance, a possible risk strategy for the organization could be to mitigate all risks that are medium and high and accept (e.g. do nothing) only the ones whose residual risk (e.g. the risk left after either measures or compensating control are either applied or considered) are low. Risk mitigation strategies can also factor business risks using qualitative risk analysis that factor risks such as probability and economical impacts. Once the risk has been determined, the next step is to decide which risk the organization is willing to accept, mitigate, transfer or to avoid. For the risks that the organization is willing to accept it is important for CISOs to have a risk acceptance process that qualifies the low level of risk based upon the presence of compensating controls and that can be signed off by him and executive management. For the risks that are chosen for risk mitigation, it is important to determine which security measures/corrective actions are deemed acceptable by the organization and to decide which of these measures are most effective in reducing risks by minimizing the costs (e.g. highest benefit vs. minimum security measure total costs). This is where the risk mitigation strategy needs to consider the cost of potential security incidents such as data breaches to decide how much is reasonable for the organization to budget for investments in application security measures. An important aspect of the risk strategy for CISOs is to decide which security measures work best together as "pluribus unum" that includes applying preventive and detective controls to provide a defense in depth of the application's assets. Finally, for the risks that are either transferred or shared with third party, it is important for the CISO to work with legal to make sure risk-liability clauses are documented in the legal agreements and service license agreements that are signed by the organization with the third party service provider/legal entity.
Threat Analysis and Awareness of Emerging Threats
Making the business case for additional spending in application security measures is not always justifiable without risk data from the analysis of the impact of emerging threats and the increased level of risks that needs to be mitigated. Threat analysis data allow informed risk management decisions. In the absence of such data, the management is left with subjective considerations about threats.
Subjective considerations about threats are most often decisions based upon Fear, Uncertainty and Doubt (FUD). Acting upon FUD to mitigate risks posed by emerging threats is late-coming and ineffective. Example actions based on FUD include, but are not limited to:
- Fear of data breaches
- Fear of failing audit and compliance
- Uncertainty regarding business threats
- Doubts about effectiveness of existing security measures in light of recent security incidents
The intent of this part of the guide, is to help CISOs to create additional business case for application security investment based upon objective threat analysis instead of subjective considerations. From compliance with standards perspective, objective considerations are based upon a rationale for investing in applications security that includes complying with new security standards and regulations that impact applications. From threat analysis perspective, objective considerations are based upon data regarding the business impact of emerging threat agents seeking to compromise applications for financial gain. Specifically, in regarding making the case for mitigation of risks, it is necessary for CISOs to avoid assumptions and back the case with data such as reports and analysis of cyber-threats and security incidents, costs of data breaches to estimate liability and quantitative calculations of risk based upon estimate of probability and impacts. Based upon risk calculations and data breach cost estimates, it is possible for the CISO to articulate how much the organization should invest in application security and to determine of which specific measures to invest.
From fear perspective it is true that CISOs can also exploiting the momentum being this either a negative or positive event but this is part of reactive risk management approach and low maturity in dealing with risks. Often application security spending can be triggered by a negative event such a security incident (USE CISO SURVEY DATA TO CONFIRM), since this shifts senior management's perception of risk. In the 2013 OWASP CISO Survey, 20% of respondents indicated that their organization experienced a data breach within the past 12 months (CONFIRM CISO SURVEY DATA). In this case, the money is probably already being spent to limit the damage such as to remediate the incident and implement additional countermeasures. The main question then is what further investment in application security will reduce the likelihood and impact of another similar incident happening in the future. One approach is to focus on applications that might become a target for future attacks.
Addressing the Business Concerns after a Security Incident
Risk quantification can be used as criteria for quantify how much money should be spent to mitigate the risk posed by insecure applications. From risk analysis perspective, if an application has been already attacked and sensitive data already being lost or compromised, it might already be brought to the attention of the business and in scope for identification, remediation and testing of the vulnerabilities that might had been the cause of the exploit/security incident. The next step, might be the design and implementation of risk prevention and detection security controls for similar applications and software that might be at risk of similar attacks and incidents in the future. The main question for the CISO is which application security measures and activities should be targeted for spending to mitigate the risks of breaches of sensitive data due to malware and hacking attacks to applications and software that is developed and managed by the organization.
In Part II of this guide, we address how to target spending to mitigate the risk posed by specific attacks and vulnerability exploits. This helps in prioritizing risk mitigation by likelihood and business impact. From the perspective of risk management, application security spending matching all of the costs of the impact of a possible data breach is not justifiable. The main question for the CISOs is how much should be spent to mitigate the risk of data breach incidents, if not 100%, it is the 50%, 25% or 10% of all possible monetary losses? Also does the total loss estimate includes non-monetary losses such as reputation loss? In addition, if allocating a budget of 25% of the estimated potential losses due to data breaches is justifiable, how much of this 25% should be allocated in upgrading security in applications that have a similar risk profile of the application being breached. Besides investing in security controls, how much should also be invested in improving secure software development/engineering processes, security training and improvements in application security testing? Part II and III of the guide will specifically address these questions and provide the rationale of which security controls and security activities to target for spending.
Budgeting of Application Security Measures for Mitigating Risks of Data Breach Incidents
For guiding the CISOs in making decisions on "how much money the organization need to budget for application security" we will focus on risk mitigation criteria rather than other factors such as percentage of the overall Information Technology (IT) budget and year over year budget allocation for applications security as fraction of overall information security budget that include compliance and operational-governance costs. A risk based application security budgeting criteria documented in this guide consist on the following:
- Estimate of the impact of the costs incurred in the event of an security incident
- Quantitative risk calculation of the annual cost for losses due to a security incident
- Optimization of the security costs in relation to cost of incidents and cost of security measures
- The return of security investment in application security measures
We shall explain in the following sections of this guide each of these criteria and how can be used for quantifying how much money to spend in application security measures
Analyzing the Risks Of Data Breach Incidents
There are two important factors to determine the risk of a security incident: these are the negative impact caused by the security incident and the likelihood (probability) of the incident. To obtain an estimate of the impact of the costs incurred in the event of a security incident, the key factor is the ability to ascertain the costs incurred due to the security incident. Examples of negative impacts to an organization because of a security incident might include:
- reputation loss such as, in the case of publicly traded company, a drop in stock price as consequence of announced security breach;
- loss of revenue such as in the case of denial of service to a site that sells services or goods to clients and customers;
- loss of data that is considered an asset for the company such as users' confidential data, Personal Identifiable Information (PII), authentication data, and trading secrets/intellectual property data;
- inability to deliver a statutory service to citizens;
- adverse impact on individuals whose data has been exposed.
Monetizing the Economical Impacts of Data Breach Incidents
In the case of a security incident that caused a loss of sensitive customer or employee data such as personal identifiable information, debit and credit card data, the costs incurred by the organization that suffered the loss include several operational costs also referred as failure costs. In the case of a financial services company, these are the costs for changing account numbers, remission costs for issuance of new credit and debit cards, liability costs because of fraud committed by the fraudster using the stolen data such as for illicit payment transactions and withdrawal of money from ATMs. Often times, the determination of such “failure” costs is not directly quantifiable by an organization, such as when this monetary loss is not directly caused by a security incident, hence ought to be estimated as a possible impact. In this case, CISOs can use statistical data to determine the possible liability costs to the company in case of data loss incident. By using reported statistical data from data loss incidents, it is possible to estimate the costs incurred by companies to repair the damage caused by security incident that resulted in losses of sensitive data or identity loss. Appendix A contains a detailed discussion on the value of data and the impact of a security incident. The value of data will be different for each organization, but values in the range of $500 to $2,000 per record seem to be common.
Data value: $200 to $2,000 per record
We will use this range for the remaining discussion, but each CISO needs to come up with some valuation of their own that can then be used to calculate the impact of a data loss.
Estimating the Likelihood of Data Breach Incidents
One of the challenges of the calculation of the burden to the company because of a potential data loss is to get an accurate estimate of the amount of the loss x victim and of the probability or likelihood of such loss occurring. Statistical data about reported data loss incidents to breach notification letters sent to various jurisdictions in the United States collected by the Open Security Foundation's (OSF) DataLossDB show that the percentage of 2010 data loss incidents breaching a web interface is 9% and the percentage that reported as being an hack is 12%, fraud 10% and virus 2%. The highest reported incident by breach type is stolen laptop with 13% of all reported incidents.
The data from OSF DataLossDB related to web as type of breach differ from the statistics of the Verizon’s 2011 data breach investigations report where hacking (e.g. brute force, credential guessing) and malware (e.g. backdoors, keyloggers/form grabbers, spyware) represent the majority of threats for security breaches (50% and 49% respectively) and attacks against applications represent 22% of all attack vectors and 38% as percent of records being breached.
These differences might be explained by the fact that the Verizon study is based upon a subset of data from the U.S Secret Service and does not includes for example cases related to theft and fraud that are instead counted on the overall OSF DataLoss DB statistical data. Furthermore, according to the Verizon report;" the scope of the survey was narrowed to only those involving confirmed organizational data breaches". In the case of OSF, survey data include data breaches covered by U.S State data breach notification law such as when resulting in disclosure of customer's Personal Identifiable Information (PII) and reported by organizations with notification letters sent to various jurisdictions in the United States.
Quantification of the Business Impact of Data Breach Incidents
In the cases when the impact of an occurred data breach due to a security incident is not being recorded and notified to the public in compliance with the data breach notification laws enforced by different countries and jurisdictions, it is necessary to estimate it based upon risk estimate calculations. Besides the calculation of liability costs based upon the value of data (refer to Appendix A: Value of Data), quantitative risk analysis can be used to estimate the spending for application security measures on the yearly basis such as by calculating the impact of a security incident on an annual basis. Quantitative risks can be calculated by the assessment of the Single Loss Expectancy (SLE) or probability of a loss as a result of a security incident and the Annual Rate of Occurrence (ARO) or the annual frequency of the security incident. By using quantitative risk analysis and using publicly available reports of data breaches, CISOs can estimate the amount that a given organization managing an application would loose and therefore should spend on application security measures to mitigate the risk of a data loss due to the exploitation of an application vulnerability. The accuracy of this risk estimate depends on how reliable and pertinent the data breach incident is to application security. It is therefore important to choose the data carefully as this is being reported as being caused by an exploit of application vulnerabilities such as SQL injection (refer to Sony and TJX Max data breaches as good examples)
The SLE can be calculated with the following formula:
SLE = AV x EF
Where, AV is the Asset Value (AV) and EF is the Exposure Factor (EF). The EF represents the percentage of the asset loss because of the realization of a threat or an incident. In the case of the 2003 US Federal Trade Commission (FTC) incident data this represents the amount of the population that suffered identity fraud and is 4.6%
Assuming the AV of 1 million accounts of $ 655,000,000 ( $655 per account based upon 2003 FTC data) and exposure factor of 4.6% the estimated SLE of the data breach incident is $ 30,130,000. Assuming a frequency of 1 attack every 5 years such as in the case of TJX Inc data breach incident (discovered in mid-December 2006 and due to SQL injection exploits) the ARO is 20% hence the estimated annual loss or Annual Loss Expectancy (ALE) can be calculated using the formula:
ALE = ARO x SLO
The calculated Annual Loss Expectancy (ALE) for data loss incident is therefore $ 6,026,000/year over 10 years.
Considering Costs and Benefits of Application Security Measures Before Making Investments
Now the question is if, using quantitative risk analysis leads to an estimate to the optimal investment for application security measures. The honest answer is, not necessarily. The correct answer is to use cost vs. benefit analysis to determine the optimal value. By comparing the costs of security incidents against the cost of security measures it is possible to determine when this maximizes the benefit, that is, the overall security of the application. In case of software security costs for example, the cost due to software security failures including security incidents decrease as the company spends more money in security measures as shown in (FIG 1). The optimal investment in the security measures is the one that maximizes the security of the application and minimizes both the cost of security measures and of the cost incurred because of security incidents. According to an analytical study of costs vs. benefits of security, the optimal investment is when the cost of security measures is approximately 37% of the estimated losses. For our example, assuming the total estimated losses of $ 6,026,000/year due to data loss incidents, the optimal expense for security measures, using this empirical value from the study, is $ 2,229,620/year.
Figure 1: Cost of Investment in software security measures against failure costs due to incidents that exploit software vulnerabilities. At the point (A) to the costs due to software security failures exceed of several order of magnitude the expenditure in countermeasures and the assurance on the security of the software is very low, on the contrary in (B) the costs of security measures outweigh the costs due to the software failures, the software can be considered very secure but too much money is spent for software security assurance. In point (C) the cost of losses is nearly two times larger costs of security measures while in point (D) the costs due to incidents is equal to the cost of the security measures. The optimal value for spending of security measures is the one that minimizes both the cost of incidents and security measures and maximizes the benefit or the security of the software.
Analyzing Security Measures as Investments
Return of Security Investments (ROSI) in Application Security
Finally, it is important to determine the most efficient way to spend the application security budget from a perspective of this being an investment. If the CISO considers application security spending as an investment rather than an expense, for example, the budget can be justifiable as additional savings the company gets because of the investment in security. The factor to calculate the savings in terms of investment in security is the Return on Security Investment (ROSI). The ROSI can also help to determine if the investment in countermeasures to thwart hacking and malware attacks is justifiable: if the ROSI is not positive, the investment is not justifiable while if it is null, it does not yield any savings or investment returns. There are several empirical formulas to calculate ROSI; one is to factor of the savings for the data losses avoided over the total cost of the security control. Assuming the Total Cost of Ownership (TCO) for the cost of control is $ 2,229,620 (previously calculated as optimal value of expense in controls x year) that include development costs and acquisition of the new technologies, processes, tools as well as operating and maintenance costs it is possible to calculate the savings. ROSI can be calculated using the following empirical formula:
ROSI= [(ALE x % of effective risk mitigation) - cost of controls]/cost of controls
With this ROSI formula, assuming that the ALE is $ 6,026,000 and that the effectiveness of the risk control mitigation is 75% (assume for example, in the case of a SQL injection, risk mitigation as defense in depth such as different layers of controls that include use of prepared statements/stored procedures in source code as well as filtering of malicious characters at the web server and application server), the cost of countermeasure is $ 2,229,620, the ROSI to the company is 102% per year. Since there is return of investment, the spending in security control measures is worth it and will make the company save money. The best use of ROSI is to compare alternative investments in security measures such as to decide whether to invest in the development of a new countermeasure or extending the capabilities of an existing one.
As a comparative measurement for example, ROSI can be used by CISOs to determine which software security is more efficient or yields the organization the higher savings and returns on the investment. According to research of Soo Hoo (IBM) on ROSI of the various activities of software security in software development cycle, the maximum return of investment (21%) or a savings of $ 210,000 on an investment of a $ 1 Million Secure Software Development Lifecycle (S-SDLC) program for example is obtained when the investment is in activities that aim to identify and remedy security defects during the design phase such as threat modeling. The return of investment is 15% when the defects are identified and remedied during implementation (code) such as with source code analysis and of only 12% when these are identified and remedied during the testing-validation phase such as with ethical hacking/pen tests. The best investment in application security is therefore in activities that aim to identify defects as early as during the design phase of the SDLC, in essence, the more CISOs think about investing in software security engineering programs especially threat modeling/architectural risk analysis, the more they'll save on the costs of implementing and fixing security issues later in the SDLC such as during the validation phase or when the application is already in production in response to security incidents.
Finally, it is important to notice that the criteria dealt with herein are based upon empirical formulas and are as good as the data used. The more accurate is the data the more accurate are the risk and cost estimates. Nevertheless, when these risk-cost criteria are used consistently and based upon quantitative risk decisions and objective security cost considerations, can be used by information risk management decision makers such as CISOs to decide if the investment in application security is financially justifiable from risk and business impact perspective. Since investment in security has to be justified in business terms, these risk-cost criteria can be used for business cases as well as to decide how much to spend and where to spend in application security measures.