|
|
| (338 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| − | == Introduction ==
| + | __NOTOC__ |
| | | | |
| − | The scope of this guide is to help Chief Information Security Officers (CISO) in managing application security risks. CISOs today are responsible for directing the overall application security activities such as application security governance, risk and compliance. Specifically to managing of application security risks, one of the roles and responsibilities of CISOs is to direct application security programs that includes developing and implementing security policies, standards and guidelines, work with audit and legal counsel to establish compliance with regulatory compliance requirements and define and implement an ongoing application security program which will identify the critical web application assets, assess threats and vulnerabilities of these assets and recommend application security measures. Specifically for the recommendation of application security measures, it is important for the CISO to make informed decisions on how to mitigate application security risks and decide in which application security measures to invest. This aim of this guide is to help the CISO in making these decisions. For example, by providing CISOs with risk and cost criteria for deciding which application vulnerabilities to prioritize for remediation and which countermeasures to implement to protect web applications from new threats and attacks.
| + | {| width="100%" cellspacing="0" cellpadding="10" |
| | + | |- valign="top" |
| | + | | width="70%" style="background:#d9e9f9" | |
| | | | |
| − | Because of the constantly evolving threat landscape where new threat agents are seeking to attack web applications to compromise customer’s sensitive data and company’s proprietary information for political reasons, financial gain as well as for cyber espionage, CISOs are challenged to make proactive risk decisions to mitigate the risks posed by these new threat agents. These risk decisions often involve analysis of the risk probability and impact to determine the overall risk and trade-offs between the costs and effectiveness of security measures to decide on which ones to prioritize the application security investments. By considering this, the aim of this guide is to provide guidance to CISOs for making informed risk decisions such as to help prioritizing the risk mitigation of web application vulnerabilities that might severely and negatively impact the organization and jeopardize the business. To decide which web application vulnerabilities to prioritize for mitigation as well as which countermeasures to invest, this guide provide the CISO with risk based criteria such as the quantification of the business impacts of data breaches. These business impacts are then compared with the costs and the benefits of investment in application security measures.
| + | = The CISO Guide = |
| | | | |
| − | Besides fixing vulnerabilities that might cause the most impact to the business, it is also important to identify new countermeasures that can mitigate the risks of new threats such as hacking and malware attacking web applications. Today, preventive and detective controls play an important role in mitigating these risks and should be considered as important measures by applying the principle that “no one security measure fits all application security needs” and that measures are implemented at different layers of the application by following the principle of “defense in depth”. As web applications evolve by offering new services with the adoption of new software and hardware technologies, another important factor to consider by CISO is the mitigation of new vulnerabilities introduced by the adoption of new technologies. Adopting a risk framework to evaluate the risks introduced by the adoption of new technologies is critical element for deciding in which application security measures to invest to reduce these new risks. This guide will provide some examples on how to identify countermeasures that mitigate the risks of new threats and new technologies adopted by the organization such as mobile, web 2.0 and cloud computing.
| + | '''Application Security Guide For CISOs''' Version 1.0 was published in November 2013. |
| | + | [https://www.owasp.org/index.php/OWASP_Application_Security_Guide_For_CISOs_Project_v2#Quick_Access Version 2 of the Guide] is currently in the works and planned for publication in Q2 2018. |
| | | | |
| − | From the strategic point of view, risk mitigation is an ongoing activity that requires paying close attention to new threats and planning for new application security processes and new countermeasures to mitigate these new threats. The planning for application security activities should also take into consideration in which domains of application security to invest and the organization capabilities, also referred to as “maturity” in these domains. Examples of these domains include application security governance, vulnerability risk management, regulatory compliance and application security engineering such as to design and implement secure applications. Specifically in the case of application security engineering, software security assurance is a very important factor to consider for deciding in which activities to invest since it allows CISOs to measure the organization capabilities in the software security engineering domains. Examples of these application security development actives might include software security processes/tools such as architectural risk analysis/ threat modeling, secure code reviews/static source code analysis and application security testing/web application vulnerability scanning. A reference to OWASP’s software assurance maturity model as well as to the several OWASP projects that can be used by the CISO for planning and developing processes and evaluating tools for software security is provided: this includes for example, the OWASP application security guidelines for designing and security testing web applications, application security training materials and free security testing tools.
| + | La [[Guía de Seguridad en Aplicaciones para CISOs]] versión 1.0 (Español) fue publicada en marzo de 2015. |
| | | | |
| − | Among the CISO goals for application security, meeting compliance with information security policies is often the one that today has the most focus for deciding on which activities to invest. This guide aims to help CISOs in using compliance of web applications with security standards and regulations as justification for investing in application security activities and increased level of risk mitigation. Since achieving compliance today is no longer enough for secure web applications from the continuous evolving threat landscape, the aim of this guide is shift the focus of CISOs from security compliance to risk management.
| + | == Contents == |
| | | | |
| − | Ideally, CISO’s situational awareness such as the understanding of the business risks posed by web application vulnerabilities leads to a proactive mitigation of risk and adoption of security measures to prevent security incidents such as data breaches caused by exploit of these vulnerabilities to occur. Unfortunately today, most of organizations have already being negatively impacted by security incidents resulting in either a data breach or data compromise. Therefore the question for CISOs today is not IF their web applications will be impacted by a data breach but WHEN they will be impacted. Getting this “situational awareness” is very important also to decide where to focus the investment in application security. As most of the investments in web application security are due to comply with information security standards and regulatory requirements to pass audits and certifications, situational awareness for CISO today means realizing that the costs to the business due to the impacts of security incidents today is much higher than the cost of non-compliance and failing audits. Often this is the case of the cost of CISOs losing their job and reputation. Since investment in compliance as well as operations risk management are among CISO responsibilities, the focus of investment in risk management is articulated as “what are the most cost effective measures to manage security risks”.
| |
| | | | |
| − | Finally, after application security investments are made, it is important for CISOs to measure and report on the status of governance, risk and compliance of the application security program. One important element for CISOs to manage application security risks is to adopt a risk management metrics. The goal of the risk management metrics is to allow CISOs to make informed decisions on where to focus the risk mitigation effort and to manage security risks more effectively. This goals are usually very organization specific and depends on the type of organization and the industry sector that the organization does business with. For the sake of this guide, some general guidance on application security metrics suitable for measuring governance, risk and compliance of application security processes is also included herein.
| + | * Preamble |
| | + | ** [[CISO AppSec Guide: Introduction|Introduction]] |
| | + | ** [[CISO AppSec Guide: Executive Summary|Executive Summary]] |
| | + | ** [[CISO AppSec Guide: Foreword|Foreword]] |
| | + | * The CISO Guide |
| | + | ** [[CISO AppSec Guide: Reasons for Investing in Application Security|Part I: Reasons for Investing in Application Security]] |
| | + | ** [[CISO AppSec Guide: Criteria for Managing Application Security Risks|Part II: Criteria for Managing Application Security Risks]] |
| | + | ** [[CISO AppSec Guide: Application Security Program|Part III: Application Security Program]] |
| | + | ** [[CISO AppSec Guide: Metrics For Managing Risks & Application Security Investments|Part IV: Metrics For Managing Risks & Application Security Investments]] |
| | + | * Supporting Information |
| | + | ** [[CISO AppSec Guide: References|References]] |
| | + | ** [[CISO AppSec Guide: About OWASP|About OWASP]] |
| | + | * Appendix |
| | + | ** [[CISO AppSec Guide: Value of Data & Cost of an Incident|Appendix A: Value of Data & Cost of an Incident]] |
| | + | ** [[CISO AppSec Guide: Quick Reference to OWASP Guides & Projects|Appendix B: Quick Reference to OWASP Guides & Projects]] |
| | | | |
| − | == Structure == | + | == Licensing == |
| | | | |
| − | This guide is articulated in four parts guiding CISOs in the following aspects of the application security program:
| + | The OWASP Application Security Guide For CISOs is free to use. It is licensed under the [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. |
| − | *Business cases & risk-cost criteria for application security spending;
| |
| − | *Application security issues that can be prioritized and targeted for risk mitigation;
| |
| − | *Application security controls, measures and activities can be targeted for spending;
| |
| − | *Metrics for managing application security governance, achieve compliance and mitigate risks
| |
| | | | |
| − | == Foreword == | + | == Feedback & Contributions == |
| | | | |
| − | This project is being developed by the OWASP Global Industry Committee in parallel with the CISO Survey project. <br>The objective is to run these projects in synch and use the results of the [https://www.owasp.org/index.php/Industry:GIC_CISO_Survey_2013 2013 CISO survey] to tailor the guide to the specific CISOs needs by highlighting which OWASP projects/resources address these needs. <br>The draft of the current guide is included herein:
| + | We hope you find the information in the OWASP CISO guide project useful. Please contribute back to the project by sending your comments, questions, and suggestions to the OWASP CISO guide mailing list. |
| | + | You can subscribe to the list by selecting the link [https://lists.owasp.org/mailman/listinfo/owasp_application_security_guide_for_cisos herein] |
| | | | |
| − | __TOC__
| + | | width="100" style="max-height:200px;overflow:hidden;background:#fff;margin:0;padding:0;" cellpadding="0" | |
| | | | |
| − | <br> | + | <div style="width:100px;max-height:300px;border:0;margin:0;padding-left:6px;padding-right:6px;overflow:visible;">[[File:CISO-Guide-bar.jpg|link=]]</div> |
| | | | |
| − | = Part I: Business Case & Risk-Cost Criteria for Application Security Spending = | + | | width="30%" style="background:#eeeeee" | |
| | | | |
| − | == Introduction == | + | =Credits = |
| | | | |
| − | In this digital era public and private organizations serve an increasing number of individuals and customers through web applications. Often these web applications provide customers “highly trusted services” over the internet, in the case of financial web applications for example, these “highly trusted web services” include functions that bear high risk for the business. 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 customers: 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 web 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.
| + | == Project lead and main author == |
| | | | |
| − | In the case of data breach incidents, often these attacks from fraudsters and cyber-criminals involve the exploitation of web application 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 web 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 customers, 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 (Ref [1]) 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.
| + | * [[User:Marco-cincy|Marco Morana]] |
| | | | |
| − | To cope with this increase of incidents targeting web 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 enforce application security measures to avoid, mitigate and reduce application security risks to the organization. For financial organizations for example, the increasing threat to web 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.
| + | == Other contributors == |
| | | | |
| − | 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 (Ref[26]) that for example stated "Despite the economic downturn, over a quarter of respondents expected web application security spending to increase in 2009 and 36% expected to remain flat". Nevertheless, making the business case for increasing the budget for application security today represents a challenge because of the recession economy and prioritization of IT spending for development of new web application features, support of new devices such as mobile phones and investments to retain and attract new customers as well as expand the service uptake or profitability.
| + | Co-authors, contributors and reviewers: |
| | | | |
| − | 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 (Ref [2]), 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 (Ref[27]) 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.
| + | * [[User:Tobias|Tobias Gondrom]] |
| | + | * [[Eoin_Keary|Eoin Keary]] |
| | + | * [[User:Andylew|Andy Lewis]] |
| | + | * [[User:Stephanie_Tan|Stephanie Tan]] |
| | + | * [[User:Clerkendweller|Colin Watson]] |
| | | | |
| − | Typically, additional budget allocation for web 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.
| + | == Versión en español == |
| − | 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 security survey herein so that the contents of this guide can be tailored to the needs of CISOs participating of the survey. OWASP Application Security Survey.
| |
| | | | |
| − | 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 web applications. For the sake of this guide we will focus on the following areas to target application security spending:
| + | La [[Guía de Seguridad en Aplicaciones para CISOs]] (Español) fue editada y corregida por Mauro Gioino, Mauro Graziosi y [[User:Cristian_Borghello|Cristian Borghello]]. |
| − | *Compliance with information security standards;
| |
| − | *Identification and remediation of web application vulnerabilities;
| |
| − | *Countermeasures to mitigate specific threats.
| |
| | | | |
| − | 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 web application security training for the workforce.
| + | === Traductores al español === |
| | | | |
| − | 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.
| + | * Daniel J. Fernández |
| | + | * Franco Cian |
| | + | * German Chiovetta |
| | + | * Javier Albano |
| | + | * Lucas Barbero |
| | + | * [[User:Walter_Heffel|Walter Heffel]] |
| | | | |
| − | == Legal and Compliance Criteria for Application Security Budget Allocation ==
| |
| | | | |
| − | ===Identifying Standards and Laws in Scope for Compliance=== | + | = Further Information = |
| | | | |
| − | 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 web applications that manage and process data whose security falls under the scope of these standards and regulations. The impact on web 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 web applications in the US include:
| + | == CISO guide == |
| − | *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 customers’ 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
| |
| | | | |
| − | ===Capturing the Security Requirements for Web Applications===
| + | The OWASP CISO Guide is also available as |
| | + | * [https://www.owasp.org/index.php/File:Owasp-ciso-guide.pdf [EN] Download PDF] |
| | + | * [https://www.owasp.org/index.php/File:Owasp-ciso-guide_es.pdf [ES] Descarga PDF] |
| | + | * [http://www.lulu.com/shop/owasp-foundation/application-security-guide-for-cisos-v10-nov-2013/paperback/product-21288580.html At cost print on demand monochrome book]. |
| | | | |
| − | ====PCI-DSS====
| |
| | | | |
| − | Most of applications that carry out payment transactions such as merchant type of ecommerce type of web applications that handle credit cardholder data are required to comply with the Payment Card Industry Data Security Standard PCI-DSS (Ref [4]).
| + | For full information about the Application Security Guide For CISOs Project, including mailing list details, the forward plan, how to contribute, the project status, and alternative media, see the project page: |
| − | 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.
| + | * [https://www.owasp.org/index.php/OWASP_Application_Security_Guide_For_CISOs_Project CISO Guide Project Page] |
| − | 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 web 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 web applications for common vulnerabilities such as those defined in the OWASP Top Ten (Ref [5]).
| |
| | | | |
| − | 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 web applications such as ecommerce web site that handle 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 costs for failing to encrypt or truncate card numbers as well as to identify and mitigate application vulnerabilities such as SQL injection were much higher (e.g. several hundredths of millions of dollars) than non-compliance costs (e.g. several hundredthsFF of thousands of dollars).
| |
| | | | |
| − | ====FFIEC==== | + | == CISO survey == |
| | | | |
| − | In the case of the U.S. banking sector, web 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 [3]). 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 web application.
| + | The contributors to the [[OWASP CISO Survey]] also provided invaluable data for this guide. |
| | | | |
| − | ====GLBA====
| + | |} |
| − | | |
| − | 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 web 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.
| |
| − | | |
| − | ====Privacy Laws====
| |
| − | | |
| − | In general, web 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:[9] 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.
| |
| − | | |
| − | Web 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 policiy 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 reputational damage to the organization in the case this data is either lost or compromised. In addition to reputational damage, organizations might incur additional regulatory fines and legal costs in because of unlawful and non-compliant with local privacy laws.
| |
| − | | |
| − | == Risk Mitigation Criteria for Application Security Budget Allocation ==
| |
| − | | |
| − | ====Business Cases for Investment in Application Security====
| |
| − | | |
| − | Often, what is not easy for CISOs to justify is the additional spending for mitigating the increased level of application security risks due to the increased number of security incidents, increased risk exposure and the escalating cyber threats. For some organizations, budgeting for new application security measures is based upon irrational and subjective considerations such as the fear of data breaches, the fear of failing audit and compliance, uncertain risk considerations based upon subjective perception of risks and doubts about effectiveness of existing security measures because of a security incident that severely impacted the organisation. The intent of this part of the guide, is to help CISOs to create additional business case for application security investment based upon objective instead of subjective risk considerations. Objective considerations are based upon rationale for investing in applications security that includes complying with new security standards and regulations that impact web applications as well as new threat agents that seek to attack web applications for compromising data and for financial gain. Specifically, in regarding making the case for mitigation of risks, it is necessary for CISOs to back risk assumptions 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.
| |
| − | | |
| − | ====Seizing the right Opportunity====
| |
| − | | |
| − | Another important factor to consider by CISOs is exploiting the momentum being this either a negative or positive event. An increase in application security spending can be triggered by a negative event such a security incident (use survey again to confirm), since this shifts senior management's perception of risk. In this case the money is probably already being spent to remediate the incident and implement additional countermeasures. The main question then is what investment in application security will reduce the likelihood and impact of another similar incident happening in the future. One possible approach is to focus on web applications that might become a target for future attacks. A positive event might consist on a required technology upgrade of a web application such to introduce new functionality or migrate to a newer platform. This might also represent an opportunity to upgrade security technology and implement stronger security measures as well. Unfortunately, when a CISO need to decide where and how much money to spend in application security, the approach often followed is to use common sense. .
| |
| − | | |
| − | === Application Security Budget Quantification ===
| |
| − | | |
| − | ====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 web applications. From risk analysis perspective, if a web 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 web 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 web 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 web 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.
| |
| − | | |
| − | ====Focusing on Risk Mitigation====
| |
| − | | |
| − | 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
| |
| − | | |
| − | 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
| |
| − | | |
| − | ==== Estimating The Impacts Of Security Incidents ====
| |
| − | | |
| − | ====Analyzing the different Business Impacts ====
| |
| − | | |
| − | 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 (Ref[20]);
| |
| − | #loss of revenue such as in the case of denial of service to a site that sells services or goods to customers (Ref[21]);
| |
| − | #loss of data that is considered an asset for the company such as customer confidential data (Ref[22]), Personal Identifiable Information (PII) (Ref[23]), authentication data (Ref[24]) and trading secrets/intellectual property data (Ref[25])
| |
| − | | |
| − | ====Monetizing the Costs of the Loss of Data====
| |
| − | | |
| − | In the case of a security incident that caused a loss of sensitive customer 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 customer sensitive data or identity loss.
| |
| − | Appendix I-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: $500 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 (Ref [9]) 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 (Ref[1]) 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 web 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 ====
| |
| − | | |
| − | ====Annualized Loss Expectancy====
| |
| − | | |
| − | 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 I-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 a web 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% (Ref [7]) 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.
| |
| − | | |
| − | === Optimization of Spending of Security Measures to Mitigate Security Risks ===
| |
| − | | |
| − | ====Costs of Security Measures vs the Benefits====
| |
| − | | |
| − | 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 (Ref [15]) 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.
| |
| − | | |
| − | [[Image:Securitycosts.jpg]]<br>''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 and Investment===
| |
| − | | |
| − | ==== Return on Security Investment ====
| |
| − | | |
| − | 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 countermeasures. Assuming the Total Cost of Ownership (TCO) (Ref [16]) for the cost of countermeasure is $ 2,229,620 (previously calculated as optimal value of expense in countermeasures 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 (Ref [17]):
| |
| − | | |
| − | ROSI= [(ALE x % of effective risk mitigation) - cost of countermeasures]/cost of countermeasures
| |
| − | | |
| − | With this ROSI formula, assuming that the ALE is $ 6,026,000 and that the effectiveness of the mitigation is 75% (assume for example, in the case of a SQL injection, risk mitigation as defense in depth such as different layer of mitigation 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 countermeasures is worth it and will make the company save money. The best use of ROSI (Ref[17]) is to compare alternative investments in security countermeasures such as to decide whether to invest in the development of a new countermeasure or extending the capabilities of an existing one.
| |
| − | | |
| − | ====Using ROSI for Investing in Application Security Activities ====
| |
| − | | |
| − | 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) (Ref [18]) 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.
| |
| − | | |
| − | ==== Conclusion ====
| |
| − | | |
| − | 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.
| |
| − | | |
| − | = Part II: Selection of Application Security Issues to Target Spending =
| |
| − | | |
| − | == Introduction ==
| |
| − | | |
| − | Once a web application has been targeted by an attack and the organization has suffered either a data breach incident or fraud as result of it, it is important to understand the root causes (e.g. vulnerabilities, control gaps) of the incident and to invest in security measures that will prevent such incident to occur again. In this section of the guide, we address how to target spending to mitigate the risk posed by specific attacks and vulnerability exploits that caused data breach incidents. As best practice, we are not advocating to fix only vulnerabilities that might have been the cause of the incident even if these are the ones that need to be prioritized first for remediation to limit further damage. Vulnerabilities that might have been already exploited to attack the web application certainly represent the highest probability to be also exploited in future targeted attacks.
| |
| − | | |
| − | The main question for the CISO is also to whether the same vulnerabilities can be used in attacks in the future against web applications that have a similar functionality and type of data. Nevertheless, the application might have other type of vulnerabilities that might be opportunistically exploited by an attacker. These are vulnerabilities that either enable or facilitate an attacker to conduct the attacks against web applications. The main point to is that since the risk of data breaches and online fraud are a factor of likelihood and impact of vulnerabilities, it is important to consider likelihood and impact as factors to determine which issues to target for spending. In general, vulnerabilities are prioritized based upon technical risks not business impact, for example, vulnerabilities that yield high technical risks are prioritized for remediation over low risk ones. A vulnerability of high technical risk can be SQL injection for example independently from the data asset and the value that such asset has for the organization. Clearly if that SQL injection vulnerability is affecting either authentication or confidential data might represent a very different risk to the organization than a SQL injection vulnerability that might affect data that is considered of low risk for the organization such as marketing research data for example. The impact might be more of reputation risk in this case rather than data breach risk.
| |
| − | | |
| − | In part I of this guide we provide business cases that CISO can use to request budget for application security. Application security budget typically need to cover several information security and risk governance needs. Besides the usual need to spend for compliance with information security standards, policies and regulations, CISO might advocate additional budget to address mitigation of increased risks of data breach incidents. One critical factor is to quantify the impact of the data breach incident that already occurred. This implies that the CISOs are authorized to access data in relation to data breach incident such as incident reports filed by the Security Incident Response Teams (SIRT), data from legal in relation to law suits and regulatory fines and fraud data that includes amount of money losses incurred because of online fraud. All this type of information is essential to determine the overall impact. In absence of this data, the best the CISO can do is to use data breach incident data from public sources and data breach incident reports. In part I of this guide, we provided some examples of how this data can be used to estimate impact. We documented what are the critical factors to estimate impacts of data breaches: these as the value of the data assets (e.g. Customer confidential and personal identifiable information, credit cards and bank account data) and the liability for the organization in case these asset are lost. Once the potential business impact of a data breach is estimated, the next step is to determine how much should be spend to mitigate the risk. At high level, this is a risk strategy decision that depends by the organization risk culture and the organization priorities for mitigating risks.
| |
| − | | |
| − | Depending on the type of the organization, the number one priority can be "to not to be caught in unlawful non-compliance" such as in case of suffering a data breach and additionally failing to comply with compliance with PCI-DSS standards. This can be the case of small company that provides online payment processing services and who could lose business from credit card issuers and additional fines, law suits and audit and legal costs. For an organization such as an engineering or research organization whose patents and trading secrets are a critical assets, the protection from internal threats of commercial or country sponsored spying might represent number one priority. In general, it is important to address to application security as a business enabler for protecting digital assets whose value is represented in terms of costs of security measures vs. benefits in protecting the digital assets. In part I of the guide we present one criteria that can be used is the one that optimize spending by maximize risk mitigation value while minimize the security costs. Another criteria, is to consider security not as a tax but as an investment, this criteria is the Return of Investment in Security (ROSI). The ROSI can be used for making both tactical and strategic risk mitigation decisions. Tactically, ROSI can be used to decide which security measures should be targeted for spending by considering the cost vs the effective of the measure in mitigating the impact of the data loss. Strategically, ROSI can be used to decide which application security activities to invest in the SDLC such as the ones that will bring money savings in the long term.
| |
| − | | |
| − | == Targeting Vulnerabilities with the Most Business Impact ==
| |
| − | | |
| − | In this section of the guide, we would like to address a more tactical approach that helps CISOs to decide where to spend the budget in application security by addressing first the immediate needs such fixing security issues that were exploited in a data breach security incident and vulnerabilities that have been exploited in publicly reported incidents affecting similar organizations and web applications. To estimate the probability that an attack against a web application will cause a data loss, we would need to identify sources of attacks that correlate data from different type of publicly disclosed incidents (e.g. data loss, denial of service, defacement etc.) with sources of monitored attacks seeking to exploit specific web application vulnerabilities.
| |
| − | | |
| − | The risks posed by web application vulnerabilities depend on different factors. Generally "Risk (R)" is the product of the "Probability (P)" of event occurring and the "Impact (I)" that event would have on an asset. A simplified formulation for risk is therefore:
| |
| − | | |
| − | Risk = P x I
| |
| − | | |
| − | Furthermore, the impact of an asset depends on the exploit of a weakness such as a "Vulnerability (V)" of the web application that might allow a "Threat (T)" to cause a business impact that depends on the "Asset Value (AV)". A simplified formulation for risk that considers the asset value is therefore:
| |
| − | | |
| − | Risk = T x V * AV
| |
| − | | |
| − | It is possible to combine the two definitions of risk and consider the "Threat Likelihood (TL)" that is the probability of the occurrence of the threat and the probability of the exposure to the threat as "Vulnerability Exposure (VE)". The overall formulation for risk is therefore:
| |
| − | | |
| − | Risk = TL x VE * AV
| |
| − | | |
| − | These empirical formulas for risk are useful for CISOs for determining the risks to the business of a threat agent exploiting either vulnerabilities or control weaknesses and gaps to compromise an asset and cause a negative impact to the business. To note that the value of the asset has nothing to do with the asset’s cost of financial value is the relative value that the organization places into the asset in the case this asset is either lost or compromised.
| |
| − | | |
| − | A visualization of the risk of threat agents exploiting web application vulnerabilities to cause a business impact is provided herein:
| |
| − | | |
| − | [[File:OWASPT10.jpg]]
| |
| − | | |
| − | According to the OWASP Top Ten Risks of Web Application Vulnerabilities, the characterization of risk of vulnerability is as such “Attackers can potentially use many different paths through your application to do harm to your business or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant attention”.
| |
| − | | |
| − | We shall explain in the following section of this guide how CISO can estimate the probability and the business impact of web application vulnerabilities to determine the risks
| |
| − | | |
| − | ===Estimating the Probability of Application Security Threats===
| |
| − | | |
| − | To estimate the probability of a specific web application vulnerability exploit, we can refer to data reports from the Web Hacking Incident Database (WHID) (Ref [10]). The WHID is a Web Application Security Consortium (WASC) project to provide statistical analysis information of web application security incidents collected from public sources. in 2010 WHID categorized 222 incidents and observed that 33% of the incidents aimed to take down web sites (e.g. with Denial of Service), 15% aimed to deface web sites and 13% to steal information. Among the overall type of attacks the ones that sought to exploit application vulnerabilities such as SQL injection were 21%.
| |
| − | By using 2010 WHID data of reported incident and analysis, the overall probability of an attack aimed to steal information by exploiting of a SQL injection vulnerability is therefore 13 % x 21 % = 2.7%. Since SQL injection was also reported to be used for defacement, this ought to be considered as rough estimate.
| |
| − | | |
| − | In another survey of malicious web attack traffic observed over a period of six months, December 2010 through May 2011 from the security company Imperva (Ref [11]), SQL injection was identified in 23% of the attacks as third most prevalent after cross site scripting, the second most prevalent in 36% of the attacks and directory traversal as the most prevalent in 37% of all the attacks.
| |
| − | | |
| − | ====Estimating the Business Impact of SQL Injection Attacks====
| |
| − | | |
| − | By comparing WHID and Imperva web attack surveys, an order of magnitude of 21-23% for attacks exploiting SQL injection vulnerability seems an acceptable rough estimate. By assuming the cost of data loss of security incident for a financial organization of $355/record (Ponemon Institute 2010 data), and that the probability that such incident exploits a SQL injection vulnerability is 2.7% (WHID 2010 data), the 2010 liability for a company's web site such as online banking for a data loss of 1 million records is thus $ 9,585,000. With this figures a 2010 budget of $9 Million spent by a financial organization for application security measures specifically focused to prevent risks of data losses due to SQL injection attacks would have been justifiable.
| |
| − | | |
| − | Assuming that I will spend as much in security measures, this is the maximum amount estimated for expenses in security measures to thwart SQL injection attacks that includes acquisition of technology for secure software development, documentation, standards, processes, tools as well costs for the recruitment of qualified personnel and secure coding training especially for web developers. Normally this dollar figure ought to be considered a maximum value since assumes for example a total loss of the customer data.
| |
| − | | |
| − | It is important to notice that injection vulnerabilities are considered by OWASP (Ref [5]) (2010 A1-Injection) the most critical web application security risks for opportunistic vulnerability exploits. OWASP rates the risk of data injection, including SQL injection vulnerability, as severe since "can result in data loss or corruption, lack of accountability, or denial of access and sometimes lead to complete host takeover". The business impact that we calculated as liability for a medium size financial services company (1 million registered online banking users) assumes that the value of the data assets can be stolen by a threat agent to cause tangible harm to the company.
| |
| − | | |
| − | Historically, SQL injection attacks have been of high impact and in the United States, have been associated with the largest data breach incidents ever committed and prosecuted. In the August 2009 U.S. indictment case (Ref[12]) against Albert Gonzalez (also indicted in May 2009 in Massachusetts for the TJX Inc breach) and other two Russian hackers, SQL injection attacks were used to break into 7-Eleven network in August 2007 resulting in the theft of credit card data. Allegedly, the same kind of attack was also used to infiltrate Hannaford Brothers in November 2007 which resulted in 4.2 million debit and credit card numbers being stolen and to steal 130 million credit card numbers from Heartland Payment Systems on December 2007. In 2010, Albert Gonzalez was found guilty and sentenced to serve 20 years in federal prison while Heartland paid about $ 140 million in fines and settlements because of the security breach.
| |
| − | | |
| − | === Identifying The Threat Agents ===
| |
| − | | |
| − | One important the element for the determination of risk is the identification and characterization of the threat agents. For the sake of understanding the terminology used herein, a threat agent (https://www.owasp.org/index.php/Category:Threat_Agent) “is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company.” A threat agent can be defined as the function of his capabilities, intentions and past activities:
| |
| − | | |
| − | Threat Agent = Capabilities + Intentions + Past Activities
| |
| − | | |
| − | The characterization of the threat agent is critical for the assessment of risk since risk can be defined as in NIST SP 800-30 as “the potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability”. In essence a threat agent can be characterized as the intersection between the agent’s motives, the specific type of attacks used and the vulnerabilities that are exploited. that are exploited. An example of this is shown in the figure herein.
| |
| − | | |
| − | [[File:ThreatAgents.jpg]]
| |
| − | | |
| − | In regards of the threat agent, it is important to understand “IF” and “HOW” the organization’s web applications and the data stored might be a likely target for an attack. By identifying the threat agent intentions and the capabilities such as the types of attacks used against web applications and the vulnerabilities that are exploited, CISOs can determine the likelihood, the data that is targeted and the potential impacts. As cyber threats continuously evolve and escalate in severity, it is important to understand what these threat agents are, their intentions and the past activities that is the type of attacks used by them. By analyzing how threats evolve, CISO can adapt application security measures to mitigate the risks of these threats.
| |
| − | | |
| − | ===Analysis of Threat Agents Past Activities===
| |
| − | | |
| − | The estimation of the threat agents is possible by analyzing their evolution in the last decade to identify the different types of threat agents involved, their motives and the type of attacks used. Threat agents have radically changed from the ones of ten years ago; their motives have changed as well as the sophistication and impact of the attacking tools and techniques used.
| |
| − |
| |
| − | ===Script Kiddies, Worms and Virus Authors===
| |
| − | | |
| − | Between the years 2000 and 2005, the main threats agents could be characterized as the so called “script kiddies” seeking to gain notoriety by hacking into government systems using easy-to-find techniques and scripts to search for and exploit weaknesses in other computers as worm and virus authors seeking to spread them for causing notable major computer disruptions and get famous as a result. Historically, the primary targets of these threat agents weren’t websites but computer hosts for the sake of getting notoriety by infecting them with viruses and worms. Notable script kiddie of the late 90s includes Jonathan James, known as "cOmrade" on the Net, that pleaded guilty to intercepting 3,300 emails, stealing passwords, and nicking data by using network sniffers installed by compromising servers of US Dept of Defense with backdoors. In the year 2000, Jeanson James Ancheta created a worm that allowed him to infect as many computers on the Internet as he could with off-the-shelf Remote Access Trojans (RATs). Over time, he amassed about 40,000 worm-infected remote access computers (also known as bots). In the same year 2000, Onel Deguzman authors the ILOVEYOU virus that spreads by emails to 10 million hosts worldwide costing companies an estimated $ 5.5 billion dollars for cleaning it. In the year 2000, a 15 year script kiddie, Michael Calce known as “mafia boy” takes down eBay, Amazon and CNN websites for 90 minutes by accidental use of file sharing tool. Notable worm author of the year 2004 is Sven Jascham author of the Sasser worm that is estimated to have impacted 10 million hosts. The impacts of Sasser worm included disabling hosts for satellite communications, disabling hosts for operation of air lines trans-Atlantic flights and disabling hosts for at financial organizations and hospitals. Today CISOs need to be on the alert for today’s script kiddies using readily available tools that look for common exploits of vulnerabilities to expose them to public. CISOs need to make sure that systems and web applications are not vulnerable to these easy exploits since this might damage the company reputation when these are published.
| |
| − | | |
| − | ===Fraudsters & Cyber-Criminal Gangs===
| |
| − | | |
| − | In the years between 2005 and 2010, the motives of the threat agents shifted from hacking for fame and notoriety to hacking for financial gain. During this period, the targets of the attacks also shifted from hosts to websites and the motives for the attacks changed from causing disruption using viruses and worms to stealing confidential and sensitive data such as personal data for identity theft and credit and debit card data for credit card fraud. In the year 2007 for example, Albert Gonzales and other three conspirators succeeded in stealing 130 million credit card numbers from Heartland Payment Systems, a New Jersey card payment processor; 7-Eleven, the Texas-based convenience store chain; and Hannaford Brothers, a Maine-based supermarket chain. The attackers used SQL Injection attacks that resulted in the placement of malware to sniff the network for credit card data used at retail stores. They later engaged ATM fraud by encoding the data on the magnetic stripes of blank cards and withdrawing tens of thousands of dollars at a time from ATMs.
| |
| − | In 2010, a cyber-criminal gang of 37 Russian hackers succeeded in stealing $ 3 million from online bank accounts by infecting online bank users PCs with the ZEUS banking Trojan. The ZEUS Trojan is specifically designed to steal banking information by using man in the browser, key logging and attacking online banking applications by hijacking the session and by taking over the victim bank accounts.
| |
| − | In 2012, Zeus banking malware has evolved in newer and more sophisticated named “GameOver” that is designed to steal user’s online banking credentials by defeating common methods of multi factor authentication employed by financial institutions as well as to perform wire transfers using the victims’ credentials without requiring any interaction from the victim during the attack. For CISOs at financial institutions, understanding how these threat agents and malware attacks seek to compromise user’s online credentials and bypass multi factor authentication is critical to determine which countermeasures can be deployed to protect the financial institions from these attacks. Often CISOs at financial organization subscribe to “threat intelligence services” so that are notified when customer's online credentials and bank and credit card data have been recovered from Zeus Command and Control and “dropping” servers. Typically these alerts are the outcome of ZEUS malware hosted botnets being taken down by law enforcement. Based upon this information, CISO can inform the businesses to take actions to limit the impact such as notifying the customers and suspend and replace credit and bank accounts.
| |
| − | | |
| − | ===Hacktivists===
| |
| − | | |
| − | In the years between 2010 and 2012, a new class of threat agents emerged that seek to attack government and corporate websites for political motives. These are computer hacker groups of such as Lulzec and Anonymous. In 2011, Lulzec, claimed responsibility for compromising user accounts and credit card data users of the Sony’s PlayStation Network while Anonymous claimed responsibility for defacing the site of the company HBGary federal and publishing several thousand of client’s emails. These threat agents are commonly referred to as “hacktivists” and seek to attack websites not for financial gain but for exposing corporate and government owned information to the public. It is mportant for CISOs to notice, that according to the 2012's Verizon Data Breach Investigation Report (released on March, 22nd 2012), event if hacktivists caused a small percentage of incidents (3%) hence affecting a low probability, overall, they account for the largest impact in terms of volume of data records compromised (58%). According to the Verizon's report, hacktivists are more likely to attack large organizations rather than small ones since these provide them with the most return of investment (i.e. from the attacker's perspective) in terms of data that can be compromised and disclosed to public. CISOs in large private and public (e.g. Government) organization that have a known public brand should consider the risk of confidential data (e.g. names, last names and emails) and confidential personal identifiable data (e.g. names, last names and card numbers) as high risk. CISOs responsible for the security of both government and corporate hosted and managed websites that store customer's confidential and personal identificable information, might likely become the target of hacktivists for political reasons and need to worry about reputational damage impacts also resulting from public disclosure of website vulnerabilities. Hacktivists often engage in attacking the organization's employees and customers with spear phishing and their websites with SQL injection, Cross Site Scripting and web service vulnerability exploits for the sake to steal and post the compromised information online. Another type of attack that CISOs managing government and corporate websites need to worry about are disruptions due to Distributed Denial of Service (DDoS) attacks. Typically, hacktivits target websites with DDoS hosted at financial and govenment organizations for political reasons. For example, several of credit card sites such as Mastercard.com, Visa.com were attacked in 2011 by Anonymous with DDoS in retaliation of removing WikiLeaks operators among the VISA's and MasterCard's clients.
| |
| − | | |
| − | ===Cyber-spies===
| |
| − | | |
| − | Since the years 2011 and 2012, besides hacktivists, fraudsters and cyber-criminals, another class of new threat agents that some of the CISO of international organizations, governments, financial, defense and high tech engineering type of companies need to deal with is cyber-spies seeking to compromise websites for stealing top secrets, financial restricted and intellectual property type of information such as company’s trading secrets. These type of attacks often involve the use of Remote Access Tools (RATs) as publicly revealed by McAfee in the operation Shady RAT report. In this 2011 study, it is reported that these type attacks went on for several years starting in mid-2006, impacting "at least 72 organizations, including defense contractors, businesses worldwide, the United Nations and the International Olympic Committee". These type of cyber espionage attacks involved the use “spear-phishing email containing an exploits sent to an individual with the right level of access at the company, and the exploit, when opened, in an unpatched system, will trigger a download of the implant malware”. Spyware malware typically execute and initiate a backdoor communication channel to the C&C web server and interpret the instructions encoded in the hidden comments embedded in the webpage code.” Besides spear-phishing, cyber espionage tools can spread also by compromising web servers via SQL injection (http://www.mcafee.com/uk/about/night-dragon.aspx), infected USBs, and infected hardware or software. The analysis of some of the most recently used cyber-spying malware seems to indicate that these are developed by countries engaged in cyber espionage. In 2012 for example, Kaspersky labs identified a cyber-spying malware such as “Gauss” that bear code similarities with other cyber-espionage tools such as Flame and cyber-war tools like Stuxnet. According to Kaspersky Gauss is “designed to steal sensitive data, with a specific focus on browser passwords, online banking account credentials, cookies, and specific configurations of infected machines.
| |
| − | | |
| − | ===Advanced Persistent Threats (APTs)===
| |
| − | | |
| − | Often cyber-espionage activities are associated with APTs (Advanced Persistent Threats). APT are characterized by advanced that is use sophisticated methods, such as zero-day exploits and persistent that is, the attackers returns to target system over and over again with a long term objective and achieving his goals without detection. Historical APTs includes operation Aurora targeting Google, Juniper, Rackspace and Adobe companies as well as operation Nitro, Lurid, Night Dragon, Stuxnet and DuQu. CISOs of government organizations as well as corporations whose protection of intellectual property and confidential and restricted information constitute a primary concern, need to be aware that might become the target of APTs seeking to target employees and customers with spear phishing to infect PCs with spyware, as well as to exploit system and web application vulnerabilities like SQL injection for installation and dissemination of cyber espionage tools.
| |
| − | | |
| − | == Targeting Threats with Countermeasures ==
| |
| − | | |
| − | The goal of this chapter is to provide CISO with tactical guidance for mitigation of threats against web applications. Threat mitigation consists on fixing vulnerabilities as well as applying new countermeasures.The choice of which countermeasures are critical to mitigate threats need to start first with the understanding of the threat scenario and the threat agents especially of hacking and malware and how these threats adversely affects security controls in web applications leading to compromise of the data assets as well as of critical business functions. One critical tool that CISOs can use to prioritize risk is the use of risk frameworks that factor the threat agents, the technical risks posed by application vulnerabilities that the threat agent seek to exploit and the business impacts. The risk profile of each application is different depending on the inherent values of the asset whose business impact depends upon and the likelihood as the application might be the targeted by a threat agent. After vulnerabilities are prioritized for remediation, it is important to consider the effectiveness of existing countermeasures and identify any gaps in risk mitigation measures that require the CISO to consider new countermeasures. The control gap analysis can be used to determine which countermeasures need to be implemented based upon security principles. The principle of defense in depth can be used to identify gaps and these gaps can be filled by applying countermeasures. To decide on which countermeasures to invest, CISOs should consider both the costs and the effectiveness of new countermeasures in mitigating the risks. To decide of how much should be spent in countermeasures, the calculation of potential financial losses as factor of likelihood and impact to determine the financial liability can also be used as criteria.
| |
| − | | |
| − | ===Countermeasures against Script Kiddies===
| |
| − |
| |
| − | In this section of the guide we will describe how to proactively mitigate the risks posed by certain threat agents whose motives and attack goals have been previously analyzed. In the case of script kiddies, the attacks that CISO need to be prepared to defend from are the ones seeking to run scripts and off the shelf vulnerability scanning tool for the sake to identify web application vulnerabilities. Among the script kiddies goals is to probe websites for common vulnerabilities and when these are identified, they often seek to disclose them to public for fame and notoriety. Since script kiddies often seek to identify vulnerabilities and not necessarily to exploit them for data compromise, the impact for the business is often reputational damage. Assuming that this vulnerability discovery is limited to running vulnerability scanning tools, the main vulnerabilities that CISOs need to worry about are the ones that are most common, more precisely, the ones that OWASP Top 10 characterizes as ‘widespread” and “easy to detect” such as cross site scripting (OWASP A2 XSS), Cross Site Request Forgery (OWASP A5-CSRF) and security misconfigurations (OWASP A6-Config.). Other these vulnerabilities are disclosed to the public without contacting the organization whose web application has been identified to be vulnerable. When these are disclosed to public, they might obviously also increase the risk to the organization since these might be exploited to compromise the website as well as the data. It is therefore important that CISOs pay close attention to script kiddies threat and remediate this type of vulnerabilities. In some cases, these vulnerabilities are published in a public accessible database after the owners of the vulnerability have been contacted and offered help to remediate. For example xssed.org collects and validates information about XSS vulnerabilities and publicly tracks them for remediation as well as offer a service to notify organizations when these vulnerabilities are released to public.
| |
| − | | |
| − | CISOs cannot assume that reputational damage is just restricted to the organization’s vulnerabilities being released to public since vulnerabilities can be occasionally exploited for defacing the website and publish unauthorized content. Example of vulnerabilities that can be exploited for defacing includes exploit of file injection vulnerabilities such as Cross Frame Scripting (XFS), that is part of (OWASP A1:Injection) group.For mitigating the risk of these vulnerabilities, CISOs need to invest on vulnerability scanning tools for testing them before the web application is released into production environment. Additionally, the focus should be given to building secure software whose components and libraries such as the OWASP ESAPI (Enterprise Security API) ESAPI “a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications”.
| |
| − | | |
| − | Besides investing in vulnerability testing and secure software to mitigate the risk of reputational type of impacts, CISO can also invest in attack monitoring and detection measures such as WAF (Web Application Firewalls). Since these types of vulnerabilities are easy to identify and widespread among web application are also the ones that websites are most probed for therefore knowing when a web application is a target of a script kiddie attack can be used for further monitor the activities and issue alerts in case the attacks are not limited to probing the website but to try to exploit the vulnerability for compromise data.
| |
| − | | |
| − | ===Countermeasures against fraudsters and cybercriminals===
| |
| − | | |
| − | Fraudsters and cyber-criminals attack websites that represent an opportunity for them for financial gain. Examples are websites that process credit card payments such as ecommerce websites, websites that allow to access credit and debit card data as well as bank accounts and perform financial transactions and as do wire transfers such as online banking websites and any website that stores and collect private information such Personal Identifiable Information of an individual. Besides to commit fraud by attacking the financial transactions such as payments and money transfers that the websites supports, other type of attacks that are sought by fraudsters are the ones that allow to get unauthorized access to sensitive data such as credit and debit card data that can be used for card non present financial transactions and to counterfeit cards as well as personal identifiable information that can be used for impersonating the victim for identity theft.
| |
| − | | |
| − | By taking into consideration these attacker financial goals, any vulnerability that allow the fraudster/cyber-criminal to control payments and money transfers as well as to gain unauthorized access to sensitive data is a very likely to be the target for an exploit. First and for most, these are vulnerabilities that can be exploited for gaining un-authorized access to ecommerce and financial type of web applications. These include exploit of weak authentication and session management vulnerabilities (OWASP A3- Broken Authentication and Session Management) since the exploit might allow to compromise credentials for accessing the web application such as username and passwords as well as SessionIDs for impersonating the victim. Other likely vulnerability exploits might include the exploit of the Cross Site Request Forgery (OWASP-A5-CSRF) vulnerability to ride the session for performing un-authorized financial transactions such as payments and money transfers. Among the most damaging web application vulnerabilities that fraudsters and cyber-criminals might seek to exploit are SQL injection (OWASP- A1-Injection), access to sensitive data by manipulating unprotected parameters such as direct references (OWASP A4 Insecure direct object reference), exploit of failure of the web application to restrict URL access (OWSP A8-Failure to Restrict URL Access), poor or non-existent cryptographic controls to protect confidential data in storage (OWASP A7-Insecure Crypto Storage) and in transit (OWASP A9-Insufficient Transport layer protection. In the case the CISO are responsible of managing risks of inherently risky websites such as e-commerce, online banking and sites that process confidential and personal information such as for insurance, loans, credit they need to focus on testing and fixing these vulnerabilities since these are the most likely to be exploited and cause the highest business impact for the business. Application layer intrusion detection rules (IDS) can be also be embedded within the web application as OWASP ESAPI or in the web server such as a WAF (Web Application Firewall) can log and monitor suspicious activity and trigger alerts for potential fraud attempts.
| |
| − | | |
| − | Application threat analysis and modeling is the key activity for determining the exposure of web applications to threats and to determine how to protect the data from the impact of these threats. From threat analysis perspective, after threat agents and their motives and attacks are identified it is important to analyze the probable attack scenarios, identify the attack vectors used and the vulnerabilities that can be exploited. An attack tree, can help to translate the attacker goals into the means to realize these goals. From the attacker perspective, the main goal is to pursuit attacks that are easier and cheaper to conduct and have the highest probability to succeed rather than otherwise. For example, consider that credit card and account data can be purchased from cyber-criminal organizations on the black market and if it is easier, cheaper and less risky for a fraudtsr than to break into a web application, this is probably what a fraudster will do. If the website that stores credit card data has open vulnerabilities that are easily exploitable to get credit card data, probably the fraudster will attack this website first instead. From CISOs perspective, fixing of application vulnerabilities thatncan be exploited by a fraudster can be justified as reduced opportunity for exploiting them. Attack trees can also be useful to understand the realization of possible threats by following the same attack patterns used by a fraudster. This allows to identify any weaknesses and points of least resistance for an attacker to pursuit. For example, if web applications are accessible through different data interfaces and channels, the fraudster will focus on the ones that offer the least resistance and greatest opportunity for compromise data such as mobile instead of web channels. The identification of the data entry points for a given web application, internal and external is a critical step to determine the attack surface of the web application and is usually part of the application threat modeling assessment.
| |
| − | | |
| − | Another critical analysis that is part of application threat modeling is to analyze which threats can be realized by exploiting a certain class of vulnerabilities so that CISOs can focus on applying countermeasures for mitigating these vulnerabilities.. An in depth analysis of threats impacting web applications and software is best conducted by using threat trees and risk frameworks. These are formal methods that allow to map threats to vulnerabilities and countermeasures. OWASP has included guides for application threat modeling as well as reference to "threat trees" and "threat-countermeasures" frameworks that can be used for this threat analysis.
| |
| − | | |
| − | A class of vulnerabilities that are often exploited by fraudsters and not tested in web applications are design flaws. One of the main reasons these are not tested is because automated vulnerability scanning tools do not understand the business logic of the application to be able to identify them. In absence of specific manual security tests that test for possible use and abuse cases of the web application for example, these type of vulnerabilities are most likely not identified and remediated and might cause serious financial losses and business impacts when are exploited. Examples of attacks that exploit these vulnerabilities are the so called "business logic attacks". Examples of business logic attacks that exploit design flaws in web applications include bypassing role base access controls to gather unauthorized confidential data and to perform un-authorized financial transactions, attacking the logic of shopping carts to alter the price of an item before check out and alter the shipping address of a purchased item before credit card validations are completed during a check out. Typically, business logic attacks exploit input validation vulnerabilities such as in missing validation of parameters in business transactions (e.g. Role ID, RuleIDs,PriceIDs), weak enforcement of controls for transaction workflows, flaws in committing financial transactions before all checks are done and misconfigurations of Role Based Access Controls (RBAC) and business policy rules. Most of these vulnerabilities need to be tested manually based upon use and mis-use cases a technique that is considered part of application threat modeling and also documented in OWASP Application Threat Modeling methodology.
| |
| − | | |
| − | Often design flaws are to be found in how application security controls are designed and require specific security testing to identify them. For example, this is the case of flaws in the design of password resets, use of guessable challenge questions in multi-factor authentication, session management flaws allowing sessions to not expire or not close, misconfiguration of authorizations and access controls. These design flaws usually fall under the class of common vulnerabilities such as OWASP A3 Broken Authentication and Session Management, OWASP A4 Insecure Direct Object Reference, OWASP A6 Security Mis-Configurations and OWASP A8 Failure To Restrict URL access and can be tested for specific manual tests. OWASP provides specific guidelines for security testing web applications for vulnerabilities as well. A class of vulnerabilities also exploited for business logic attacks includes the insufficient anti-automation (WASC 21). This is a vulnerability that can be exploited by attackers to spam online registrations, posting of information using automation tools but also for fraud such as to automatically enumerate and validate credit card data such as numbers and PINs using automated scripts that test the application error codes and success responses.
| |
| − | | |
| − | The most important criteria for CISOs for protect from business logic attacks is not to assume that the testing of design flaws and business logic flaws is covered under normal vulnerability scans and security tests. Design and business logic flaws is a class of vulnerabilities that requires to be tested by deriving specific security tests from use and abuse cases produced by security teams specifically engaged in threat modeling web applications. CISOs should consider the investment in application threat modeling process specifically for identifying and testing this class of vulnerabilities when these are not identified and tested by other security processes.
| |
| − | | |
| − | Since often one of the attack techniques adopted by fraudsters and cybercriminals is social engineer the victim to select malicious links serving malware, exploits of web application vulnerabilities that facilitate phishing the victim with malicious links might also be targeted. These attack include using Cross Site Scripting (A2: XSS) vulnerabilities to run malicious scripts that can steal cookies, run keyloggers. Another web application vulnerability that can be used for tricking a victim to visit a malicious site and get infected with malware is OWASP A10: invalidated redirects and forwards. Additional vulnerabilities that facilitate malware installation through phishing include XFS exploits for click jacking attacks. These attacks trick a victim into performing undesired actions by clicking on a concealed malicious link. These are vulnerabilities that CISOs can prioritize for remediation since facilitate the installation of malware on the victim’s PC. Since the identification of these vulnerabilities often require manual security testing such as manual ethical hacking/penetration testing as well as manual source code review to identify these vulnerabilities in the source code, it is critical for the CISO to invest in hiring and train pen testers as well as software developers with secure coding skills as well as secure code review processes, secure coding standards and static source code analysis tools.
| |
| − | | |
| − | Unfortunately, identifying and fixing these vulnerabilities is not a guarantee of immunity from attack of fraudsters but of a minimum level of software security assurance. Resilient software today require the CISO to consider investment in countermeasures to protect web applications from another class of attacks such as Man in the Browser (MiTB) and Man in the Middle (MiTM). Through MitB, fraudsters can collect confidential, authentication and credit/card data from the victim by injecting HTML fields in the browser outside the control of the web application. Additionally, the victim’s logging credentials are collected through key loggers and sent to the fraudster’s for impersonating the victim. In a money transfer session for example, the fraudster will connect to the victim’s PC from his command and control server and hijack the session to transfer money to an account under the control of the attacker (e.g. money mule account). Through, MiTM, fraudsters will redirect the victim to a malicious site whose web traffic and data will be under the controlled by the attacker.
| |
| − | | |
| − | To protect e-commerce and financial web applications from MiTB and MiTM attacks, CISOs need to adopt a defense in depth approach that includes different layers of controls at the client-PC layer, at the web server and web application server layer as well as at the backend databases and services layers. At the client PC layer, investing in customer’s information and awareness on malware threats is very important. Simple measures such as keeping browsers and PCs up to date and patched as well as hardened with limited user’s privileges and with a limited number applications installed (e.g. ideally with no email and no Facebook installed on PC) can limit the chances of malware infections. Pointed security information embedded in the website login web pages can keep warning users about malware risks every time they login.
| |
| − | | |
| − | Additionally, CISOs can invest on providing anti-malware client software for free to their clients since this is more effective in detecting and protecting the PC than traditional anti-virus.Assuming the client PC/browser has been compromised with banking malware, additional countermeasures that CISO might consider includes adding additional customer validations controls for high risk transactions such as in the case of wire transfers and payments. These include positive pay, dual verification & authorizations, anomaly and fraud detection. Since the online channel is assumed compromised by the attacker, using out of band transaction validation/authentication for payments and financial transactions with two way notification confirmation via independent mobile/voice channels puts the customers in control of the transaction and allow them to reject transactions that either cannot confirmed or whose integrity of transaction parameters have been modified by the attacker and cannot be validated. Detection measures such as receiving out of band alerts for financial transactions as well as auditing and logging and monitoring of web traffic with WAF and SIEM and use behavioral fraud detection to detect abnormal transaction rates/parameters might also allow CISOs to receive reports on detected malware based transactional events and to recommend proactive actions to limit the impact of financial losses (e.g. suspend the accounts that are flagged as suspicious till further validation).
| |
| − |
| |
| − | When deciding on which countermeasures to deploy for mitigating the risk of MiTB and MiTM attacks, CISOs might need to conduct a trade-offs between the risk, the effectiveness of these countermeasures and the costs. The countermeasures that cost the least and mitigate MiTB and MiTM attacks the most can be prioritized for investment. Typically client based anti-malware software can be effective in mitigating the malware risks at the front door and it is rather inexpensive to acquire and deploy if this cost does not include the total cost of maintenance of the solution for a large customer population. Security awareness campaigns for customers can be the least expensive measure but might not be that affective since often customers do not pay attention to security warnings. Acquiring and deploying out of band authentication and out of band transaction validation/authorization can be expensive but it offer strong mitigation against man in the middle attacks and can be a viable option to protect high risk transactions. Implementation of fraud detection systems for monitoring malicious traffic might be expensive to implement and maintain and need to be justified on the case by case basis. For example, if it is known that some web applications are constantly under attack from malware and impacted by fraud, investing in fraud detection systems might be justifiable due to the tested capability of fraud detection systems to detect attacks earlier than with other methods (e.g. looking at transaction logs that feed to SIEMs). CISOs can select which web applications should be put in scope for remediation of vulnerabilities sought by fraudsters and implementation of new countermeasures against MiTB and MiTM attacks based upon the risk profile of the application. The risk profile of the web application can be a function of the value of the data assets and the risk of the transactions that the web application provides to customers. A control gap analysis can be used to identify gaps in protective and detective controls and to determine the degree of risk mitigation that can be obtained when these are implemented. Once the security measures are adopted a calculation of the residual risk highlights to whether the risk can be accepted or need to be reduced further by implementing additional controls.
| |
| − | | |
| − | == Targeting the Risks of New Technologies ==
| |
| − | | |
| − | The goal of this chapter is to guide the CISO on the consideration of the security risks posed to the organization by the adoption of new technologies. The term “technologies” is used herein to include recent examples of technologies that impact web applications such as mobile technologies, web 2.0 technologies, and cloud computing Software as a Service (SaaS). As technologies evolve, it is important for the CISO to understand the security risks introduced by the adoption of these new technologies since these might represent new opportunities for attackers to attack both web applications and the data. The increased risk to web applications due to the adoption of new technologies includes the increased exposure/attack surface such as in the case extending web applications to mobile devices, the introduction of new class of client and server side vulnerabilities such as in the case of Web 2.0 and the increased risk of loss of data and transaction integrity due to the use of cloud computing. In order to target the mitigation of the risks due to the adoption of these technologies, CISO need to have a clear picture of the risks that are introduced and decide to invest in new type of application security assessments, tools and security measures to mitigate the risks.
| |
| − | | |
| − | = Part III: Selection of Application Security Processes to Target For Spending =
| |
| − | | |
| − | == Introduction ==
| |
| − | | |
| − | Mitigating the risk of attacks that seek to exploit of web application vulnerabilities as well as potential gaps in protective and detective controls is one of the CISOs main concerns. In the case when vulnerability is only found after a security incident occurred, the next step is to fix the vulnerability and limit further impact. Typically this involves retesting of the vulnerability and make sure is being fixed so ca no longer be exploited in the future. If the incident is due to a gap of a security control such as for example a failure to filter malicious input or to detect the attack event, the next logical step is to implement a countermeasure to mitigate the risk. To makes such decisions, the CISO need to consider both the risks of vulnerabilities as well as the weaknesses of security control measures to make a decision on how to mitigate the risks. Typically fixing a vulnerability involves a vulnerability management cycle that includes identifying the vulnerability, fixing it and then re-testing it to determine that is no longer present.
| |
| − | | |
| − | In case of countermeasures the test that the countermeasure is effective in preventing and detecting an attack vector can also be tested with a functional security test after countermeasure is deployed. The decision to which countermeasure to deploy might depend on different factors such as the cost of the countermeasure vs. the business impact of the incident as well as on how risk mitigation effective is the countermeasure by comparing with others. The next step for the CISO after the security incident is under control is to make sure any vulnerabilities are fixed and countermeasures are deployed to mitigate the risk. In this section of the guide we focus on application security measures that are most cost effective to target the issues identified in Part 2. For example how to divide budgets across software security activities such as secure code training, secure code reviews, secure verification/test and issue and risk management". The results of the CISO survey will be used to determine where money is spent and in which activities to determine if application security money is spent effectively (e.g. focus on security build in activities vs security bolt-on security activities). The results of the CISO survey will also be used to identify if standard application security controls are used to highlight which OWASP objects are most useful (e.g. SAMM, ESAPI, CLASP, Security Development, Coding and Testing Guides) "''
| |
| − | | |
| − | == Addressing CISO Role & Responsibility in Budgeting for Application Security ==
| |
| − | | |
| − | ===CISO Role & Responsibilities in Application Security Governance, Risk and Compliance ===
| |
| − | | |
| − | Governance is the process that introduce policies, standards, processes and sets the strategy, goals and organizational structure to support them. At operational level, governance, compliance and risk management are interrelated. As part of governance responsibilities, CISOs influence the application security goals and work with executive management to set the application security standards, processes and organizational structure to support these goals. As part of compliance responsibilities, CISOs work with auditors and the legal counsel to derive information security policies and establish requirements to comply, measure and monitor these requirements including application security requirements. As part of risk management responsibilities, CISOs identify, quantify and make risk evaluations to determine how to mitigate application security risks that includes introducing new application security standards and processes (governance), new application security requirements (compliance) and new application security measures (risks and controls).
| |
| − | | |
| − | From governance perspective, the adoption of application and software security processes, the establishment of application security teams and application security standards within any given organization varies greatly depending on the type of the organization’s industry, the size of the organization and the different roles and responsability that the CISO has in that organization. The source of application security investments also varies depending on the size and the type of the organization. For CISOs reporting to the organization's head of operational information security and risk management, typically the budget for application security is part of the overall budget allocated by information security and operational risk departments. For these CISOs, one the main reasons for the adoption of new application security activities, guides and tools such as the ones that OWASP provides, is first and for the most to satisfy compliance and to reduce risks to the organization’s assets such as web applications and software. Compliance varies greatly depending on the type of industry and clients served by the organization. For example, organizations that produces software that implements cryptography for use by governments such as the department and agencies of the United States Federal government need to comply with Federal Information Processing Standards (FIPS) 140. Organizations that produce software and applications that handle cardholder data such credit and debit card data for payments need to comply with is the Payment Card Industry Data Security Standard (PCI DSS).
| |
| − | | |
| − | CISOs that report to the organization's head of information technology, typically have responsibility on both security and information technology functions that might also include the compliance of applications and software with technology security standards such as FIPS 140 and PCI-DSS. Compliance with security technology standards represent an opportunity for promoting secure development and testing within the organization such as by using OWASP security testing guides for achieving security certifications for applications and software products. Compliance with PCI-DSS requirements for example might already require the organization to test web applications for a minimum set of common vulnerabilities such as the OWASP Top 10. The budget allocated by the IT department for achieve certifications with technology security standards such as FIPS-140 and PCI-DSS can also be used for promoting secure coding guides such as the OWASP secure coding guide and invest on static code analysis tools. For example, in the case of compliance with PCI-DSS, CISOs might opt for static code analysis to satisfy the requirement 6.6 of PCI-DSS. CISOs of small organizations can also use defect management metrics to make the business case in which phases of the SDLC to invest in security and improve both software quality as well as security. For example, since most of the quality and security bugs are due coding errors, it is important for CISOs to emphasize to the IT department the need of secure coding processes, standards and training for developers since focusing on these software security activities also leads to cost savings for the organization. A study from NIST about the cost of fixing security issues for example has shown that the cost of fixing a coding issue in production is six times more expensive than fixing it during coding. To achieve these money saving and efficiency goals, CISOs can work together with the engineering department managers to promote application and secure software initiatives.
| |
| − | | |
| − | For CISOs whose main focus is information security and risk management, one of the main requirements besides compliance is to introduce efficiencies and save the money spent for existing security processes, including, application security. Since the information security department allocates budgeting, any request for budget of application security need to be justified by improving security and by reducing risks. Security and risk reduction goals are aligned by improving security test processes with use of better tools and training for developers. For CISOs of large organizations, promoting a software security initiative is also justified by the return of investment in the overall application security program and processes, specifically as reduction in the cost of fixing vulnerabilities because of developers following secure coding standards, conducting secure code reviews and security teams conducting security testing for vulnerabilities earlier than the validation phase of the SDLC. OWASP provides secure development guides and secure coding guides as well as training modules that can be used to achieve this cost saving goals. Often CISOs need to justify the budget for application security by taking into consideration the different needs of security and business departments. For CISOs that serve in financial organizations for example, security is often a compromise with security and business goals. In this case, it is important for CISOs to be able to align application security programs with the business goals and when these goals not align, to focus on the ones that do. For example, by focusing on improving both software quality and security and by reaching a compromise in the case security impacts negatively the customer experience so different security options need to be considered. In the case the business is sponsoring a new application development project, CISOs can use this as an opportunity to promote new application security features for the application and work together with project managers by achieving compliance with security standards, improving security by design and by coding and yet achieving overall cost savings for the overall project.
| |
| − | | |
| − | ===The Importance of Security Metrics===
| |
| − | | |
| − | For CISOs whose responsability is manage application vulnerability risks, security metrics such as application vulnerability metrics constitutes an important factor in making business cases for investing in application security measures to control and reduce risks. Security metrics such as measurements of vulnerabilities found on the same applications during the roll out of application security activities aimed to reduce the number and the risk of vulnerabilities for example, can demonstrate to senior managers and company executives that the adoption of application security processes, training and tools ultimately helps the organization to deliver web applications and software products that have a fewer number of vulnerabilities and pose less risk to the organization and the customers.
| |
| − | | |
| − | == Targeting Software Security Activities and S-SDLC Processes ==
| |
| − | | |
| − | ===Recognizing Importance and Criticality of Secure Software===
| |
| − |
| |
| − | Since a large number of vulnerabilities in web applications are caused by insecure coding, it is important that the CISO recognizes the importance that secure software has in improving the security of the web application. The causes of insecure software might depends by different factors such as coding errors, not following secure coding standards and security requirements, integration with vulnerable software libraries, missing secure code review processes and security testing and formal secure code training and awareness for software developers. From CISO perspective, it is important to understand that software security is a complex discipline and requires a special focus in security processes, tools as well as people skills. It is also important to recognize that investing in software security helps the organization to save money spent in web application vulnerability remediation costs in the future. By investing in software security initiatives, organizations can focus on fixing vulnerabilities as early as during coding phase of the Software Development Life-Cycle (SDLC) where is cheaper to identify, test and fix them than during the validation phase.
| |
| − | | |
| − | Today, also thanks to OWASP, software security has matured and evolved as a discipline. For example, several organizations already adopt software security best practices within their software development processes such as the documentation of security requirements, following of secure coding standards and use of software security testing tools such as static source code analysis tools to identify vulnerabilities in source code before releasing source code to be build and integrated for final integrated and user acceptance tests. By integrating software security activities in the SDLC, organizations can produce software and applications with a fewer number of vulnerabilities and lower risks than software and applications that don’t.
| |
| − | | |
| − | ===Integrating Risk Management as part of The SDLC===
| |
| − | | |
| − | The question for CISO is rather not IF but WHICH and HOW software security activities can be integrated as part of the SDLC. According to the National Institute of Standards and Technology’s Special Publication 800-30, “Effective risk management must be totally integrated into the SDLC ... [which] has five phases: initiation, development or acquisition, implementation, operation or maintenance and disposal.” The integration of security in the SDLC process begins by identifying the information assets that the software will be processing and by specifying requirements for confidentiality, integrity, availability and auditability. The next step consists on the determining the value of information assets, identifying the potential threats and determine the requirements for application security controls such as authentication, authorization and encryption to protect the confidentiality, integrity and availability of the data assets.
| |
| − | | |
| − | A comprehensive set of security requirements need to also include requirements to implement secure software by following certain security and technology standards, security approved technologies and platforms as well as security checks prior of software integration with other vendors software components/libraries. When software is acquired as either part of the commercial off-the-shelf (COTS) or as free open source (FOSS) for example, it is important for CISO to have a process in place to validate this type of software libraries against specific security requirements prior to acquiring them. This could provide the CISO of the organization a certain level of assurance that the acquired software is secure and can be integrated with the application. In that regard, OWASP had developed a legal project and a contract annex of a sample contract that included security requirements for the life cycle so that COTS products would be more secure.
| |
| − |
| |
| − | ===Security in the SDLC (S-SDLC) Methodologies===
| |
| − | | |
| − | In cases when the CISO of the organization has also responsibility over promoting a software security process within the organization, it is important not to take this goal lightly since usually requires careful planning of resources and development of new processes and activities. Fortunately today, several “Security in the SDLC” (S-SDLC) methodologies can be adopted by CISOs to incorporate security in the SDLC. The most popular S-SDLC methodologies used today are Cigital’s Touch Points, Microsoft SDL and OWASP CLASP. At high level, these S-SDLC methodologies are very similar and consist on integrating security activities such as security requirements, secure architecture review, architecture risk analysis/threat modeling, static analysis/review of source code, security/penetration testing activities within the existing SDLCs used by the organization. The challenge for the integration of security in the SDLC from CISO perspective is to make sure that these software security activities are aligned with the software engineering processes used by the organization. This means for example to integrate with different types of S-SDLC s such as Agile, RUP, Waterfall as these might be already followed by different software development teams within the organization. An example on how these can be integrated within a waterfall SDLC as well as iterated within different iterations of a SDLC process is shown herein
| |
| − | | |
| − | [[File:S-SDLC-Activities.jpg]]
| |
| − | | |
| − | From CISO perspective, adopting a holistic approach toward application and software security leads to better results since can align with information security and risk management already adopted by the organization.. From information security perspective, the holistic approach toward application security should include for example security training for software developers as well as security officers and managers, integration with information security and risk management, alignment with information security policies and technology standards and leveraging of information security tools and technologies used by the organization.
| |
| − | | |
| − | ===Software Assurance Maturity Models===
| |
| − | | |
| − | Besides of following a holistic approach toward application security that considers other domains it is also important for the CISO to consider what the organization capabilities are from day one in building software security and plan on how to integrate new activities in the future. Measuring the organizations capabilities in software security is possible today with software security maturity models such as the Build Security In Maturity Model (BSIMM) and the Software Assurance Maturity Model (SAMM). These models can also help the CISO in the assessment, planning and implementation of a software security initiative for the organization. These maturity models are explicitly designed for software security assurance. These models, even if are based upon empirical measurements, are feed from real data (e.g. software security surveys) hence allow to measure organizations against peers that already had implemented software security initiatives. By allowing their organization’s secure software development software practices to be measured using these models, CISOs can compare their organization secure software development capabilities against other software development organizations to determine in which software security activities the organization either leads or lags.
| |
| − | | |
| − | For the software security activities for which the organization is lagging, BSIMM and SAMM measurements allow the CISO to construct a plan for software security activities to close these gaps in the future. It is important to notice that these models are not prescriptive that is, are not telling organizations what to do but rather to measure security activities in comparison with similar organizations in the field. The models are organized along similar domains, governance, intelligence, SSDL touch points, deployment for BSIMM and governance,construction, verification, deployment for SAMM. SAMM measurements are done in three best practices and three levels of maturity for each business function. The business functions and the security practices for each business function are shown in the fugure herein:
| |
| − | | |
| − | [[File:SAMM.jpg]]
| |
| − | | |
| − | BSIMM measurements cover 12 best practices and 110 software security activities. The maturity levels help the CISO to plan for the organizational improvements in software security processes. Software security improvements can be measured by assigning goals and objectives to reach for each activity. For CISOs that either have already started to deploy a software security initiative such as S-SDLC within their organization or that just plan it in the future, the measurements that a model such as BSIMM and SAMM provide are important measurement yard sticks to determine in which application security activities to focus spending. If not already familiar with BSIMM and SAMM, CISOs can also refer to the Capability Maturity Model (CMM) and the various maturity levels to plan for the organization secure software development process capabilities.
| |
| − | | |
| − | Like BSIMM and SAMM, CMM is also an empirical model whose goal is improve the predictability, effectiveness, and control of an organization's software processes. In CMM for example, these are five levels that can be used to measure how the organization moves up to different levels of maturity of software engineering process: initial, repeatable, defined, managed, optimizing. In the first level (initial), the software engineering process is ad-hoc and used by the organization in uncontrolled and reactive manner. As the software development organization reaches level 2, the software development processes are repeatable and is possible to provide consistent results. When an organization reaches level 3, it means that it has adopted a set of defined and documented standard software development processes and these are followed consistently across the organization. At a level 4, that is managed, a software development organization has adopted metrics and measurements so that software development can be managed and controlled. When a software development organization is at level 5, optimized, the focus is on continually improving process performance through both incremental and innovative technological change and improvements in software development.
| |
| − | | |
| − | In reference to software security processes, at CMM Level 1 (Initial) CISOs have an ad-hoc process to “catch” and "patch" web application vulnerabilities. At this level, the organization maturity in software security practice consists on running web application vulnerability scanning tool in reaction of events such as to validate the web applications for compliance with PCI-DSS and OWASP Top 10. At CMM Level 2, the organization has already adopted standard processes for security testing web applications for vulnerabilities including secure code reviews of the existing software libraries and components. At this level, the secure testing process can be repeated to produce consistent results (e.g. get same security issues if executed by different testers) but is not adopted across all software development groups within the same organization. At CMM Level 2, the application security processes are also reactive, that is, are not executed as required by the security testing standards. At CMM Level 3, application security processes are executed by following defined process standards and these are followed by all security teams within the same organization. At this level, application security processes are also proactive that means are executed to security test applications as part of governance, risk and compliance requirements prior to release into production. At level CMM 4 (managed) application security risks are identified and managed at different phases of the SDLC. At this level, the focus of security is the reduction of risks for all web applications before these are released in production. At level CMM 5 (optimized), the application security processes are optimized for increased application coverage and for the highest return of investments in application security activities.
| |
| − | | |
| − | == How to choose the right tools from OWASP and other organizations ==
| |
| − | | |
| − | Depending on the overall security level and risk profile of the organization unit different tools and standards can be particularly useful for the CISO in advancing his security strategy.
| |
| − | Note, following the risk discussions in the previous chapter, depending on the risk profile of different business units, the security strategy can actually be different based on their different individual risk scenarios and different regulatory requirements. For example a financial department may require a substantially stronger security posture, while an internal web page announcing the lunch menus of the cantine may be sufficiently protected with basic security measures (though to the authors knowledge in military settings, even the lunch menu can be considered as confidential information as further information about supply logistics etc. could be derived from that).
| |
| − | Based on these different risk profiles different tools and standards may be more relevant for the project and organizational unit in question.
| |
| − | In general tools can be classified in various categories (and so are also the OWASP projects):
| |
| − | | |
| − | ===Project's Maturity===
| |
| − | | |
| − | - Stable (a project or tool that is mature and constantly maintained to a good quality)
| |
| − | - Beta (relatively proven, though not to optimal quality)
| |
| − | - Alpha (this usually reflects a good first prototype, but still a lot of functionality may be missing or not up to standard)
| |
| − | - Inactive (former projects that have been retired or deprecated or that at some point have been abandoned).
| |
| − | Obviously for a CISO, the most interesting projects and tools would be stable and reliable ones. He can rely on a certain proven quality, and on them being available and maintained to a certain degree in the future days to come. Beta projects can also be very valuable, as they may represent projects that have not finished their full review cycle yet but are already available for early adopters and can help to build good foundations for your security programs and tools going forward.
| |
| − | | |
| − | [[File:CISO_Categories_600x407px.jpg]]
| |
| − | | |
| − | A second dimension would be the various:
| |
| − | | |
| − | ===Project's Categories===
| |
| − | | |
| − | Usually OWASP projects are divided in either '''Tools''' or '''Documentation'''.
| |
| − | And by the category of use: '''Protect''', '''Detect''' and '''Life Cycle'''.
| |
| − | These categories can help the manager to quickly navigate the large portfolio of OWASP tools available and more easily find the right project for his current needs.
| |
| − | Please find a page of the various OWASP projects classified by categories [https://www.owasp.org/index.php/Category:OWASP_Project here].
| |
| − | | |
| − | === People, Processes and Technology ===
| |
| − | | |
| − | The CISO can also choose to achieve his security goals through three main ways. '''People''', '''Processes''' and '''Technology'''. Managing the organization it is usually important to shape all three pillars to achieve the best impact throughout your organization. Focusing on only one or two of them can leave the organization vulnerable.
| |
| − | | |
| − | | |
| − | [[File:CISO_PPT_500x280px.jpg]]
| |
| − | | |
| − | | |
| − | ==== People ====
| |
| − | | |
| − | This will address the training and motivation of staff, suppliers, clients and partners.
| |
| − | If they are well educated and motivated, the chances of malicious behavior or accidental mistakes can dramatically be reduced and many basic security threats can be avoided.
| |
| − | | |
| − | ==== Processes ====
| |
| − | | |
| − | If an organization becomes more mature, the processes will be well defined and in fact channel and enable the work force to do things the "right way". Processes can ensure that the actions of the organization became reliable and repeatable. For example with well-defined standard operating procedures, the incident response process will be reliable and not rely on ad hoc decisions that would before have varied with the individual decision maker. In highly mature organizations, the business and IT processes will be constantly evaluated and improved. If a failure happens, improved processes can allow an organization as a whole to learn from past mistakes and improve its operation to more efficient and secure ways.
| |
| − | | |
| − | ==== Technology ====
| |
| − | | |
| − | In general technology can guide and support people by providing good training and knowledge, by being engaging and motivating to work with. And Technology can enable an organization to make the following the right processes easy by providing good tools, while making it hard to deviate from the right path for malicious users. For example good technology would automate access controls and authentication and make them very simple for the authorized user, while denying access or privileges to an unauthorized attacker. And last but not least a number of automated tools can in the background help and support the people and organization in their work to defend against risks more effectively and more efficiently.
| |
| − | Many of the security standards and tools (in OWASP and other bodies) can also be seen as focusing on parts of this framework.
| |
| − | For example, staff training will enable the people to build their security understanding and do the right thing, while the various SDLC models can help an organization establish the right level of processes for its development and incident response mechanisms.
| |
| − | | |
| − | ==== Benchmarking & Maturity ====
| |
| − | | |
| − | One of the very first steps for a CISO is to understand his current situation by reviewing the current security maturity of his organization or the individual department and benchmark it against peers or his target security posture.
| |
| − | | |
| − | [[File:CISO_Maturity_400x250px.jpg]]
| |
| − | | |
| − | There are several maturity models published, with variations in focus and depth of detail. Usually they share a number of good practices and for a CISO it may be advisable to review whether his organization is elsewhere already using one of the maturities models and possibly align with this for an easier initial benchmark of his organization. In the medium term the decision for which maturity model to use, would be driven be question of: what level of detail is required, are we required by a regulatory body to use and report based on a specific type of maturity model, can our model be easily integrated with the organization’s culture and common reporting information, ...
| |
| − | In the end, the author believes that most maturity models can equally fulfill your basic needs and that it will be up to the tactical judgment of the CISO to decide which model to use.
| |
| − | The openSAMM maturity model has in the past been developed by OWASP and is a very mature ("stable") project, that offers a fairly lightweight way in analyzing your current security maturity and benchmarking your organization against your peers and your targets.
| |
| − | See also: Software Assurance Maturity Models (SAMM), OWASP, http://www.opensamm.org/
| |
| − | Other maturity models can be taken from BSIMM, CMM (Common Maturity Model), the ISO-2700x series
| |
| − | | |
| − | = Part IV: Metrics For Managing Risks & Application Security Spending =
| |
| − | | |
| − | == Introduction ==
| |
| − | | |
| − | The aim of this part of the guide is to help CISO to manage the several aspects of the application security program specifically risk and compliance as well as application security resources such as processes, people and tools. One of the goals of the application security metrics is to measure application security risks as well as compliance with application security requirements mandated by information security standards. Among critical application security processes that the CISO need to report of and manage are web application vulnerability management. It is often CISO responsibility for example to report the status of the application security activities to senior management such as the status of application security testing and software security activities in the SDLC. From the risk management perspective it is important that the application security metrics allow to reports on the technical risks such as the un-mitigated vulnerabilities for the applications that are developed and managed by the organization. Another important aspect of the application security metrics is to measure coverage such as the percentage of the application’s portfolio regularly assessed in application security verification program, the percentage of internal apps vs. external apps covered, the inherent risk of these apps and the type of security assessments performed on these applications and when in the SDLC are performed. This type of metrics helps the CISO in reporting on application security process compliance and application security risks to the head of the information security as well as to the application business owners.
| |
| − |
| |
| − | Since one of the CISOs responsibilities is to manage both information security and applications security risks and to make decisions on how to mitigate them, it is important for this metrics to be able to measure these risks in terms of vulnerability exposure to the organization’s assets that include application’s data and functions.
| |
| − | | |
| − | == Application Security Process Metrics ==
| |
| − | | |
| − | ===Metrics and Measurements Goals===
| |
| − | | |
| − | The goal of the application security process metrics is to determine how good are the organizations application security processes in meeting the security requirements set forth by application security policies and technical standards. For example an application vulnerability process might include requirements to execute vulnerability assessments on internet facing applications every six or twelve months depending on the inherent risk rating of the web application. Another vulnerability process requirement would be to execute security in the SDLC type of processes such as architecture risk analysis/threat modeling, static source code analysis/secure code reviews and risk based security testing on web applications that store customer’s confidential information and whose business functionality is a critical service to customers.
| |
| − | | |
| − | From the perspective of process coverage, one of the goals of this metrics might be to report on the coverage of application security process such as to measure how web applications fall in scope for application security assessments to identify potential vulnerability assessment gaps based upon application type and the application security requirements. This type of metrics helps the CISO to provide visibility on process coverage as well as the status of the operational execution of the application security programs. For example the metrics might show (e.g. in red status) that some of the application security processes in the SDLC such as secure code reviews are not executed in some of the high risk rated applications and flag this as an out of compliance issue with the security testing requirements. This type of metrics allow the CISO to prioritize resources by allocating them on where is most needed to comply with the standard process requirements.
| |
| − | | |
| − | Another important measurement for application security testing is to measure the time of when the application security processes are scheduled and executed to identify potential delays in the scheduling and execution of application security processes such as secure code review/static source code analysis as well as ethical hacking/web application pen testing.
| |
| − | | |
| − | == Application Security Risk Metrics ==
| |
| − | | |
| − | ===Vulnerability Risk Management Metrics===
| |
| − | | |
| − | One of CISO responsibilities is to manage application security risks. From technical risk perspective, application security risks might be due to vulnerabilities in the applications that might expose the application assets such as the data and the application critical functions to potential attacks seeking to compromise the data and/or the critical functions that the application provides. Typically, technical risk management consists on mitigate the risks posed by vulnerabilities by applying fixes and countermeasures. The mitigation of the risk of these vulnerabilities is typically prioritized based upon the qualitative measurement of risks. For example, for each web application that is developed and managed by the organization that would be a certain number of vulnerabilities identified at high, medium and low risk severity. The higher the number of high and medium risk vulnerabilities the higher is the risk to the application. The higher the value of the data assets protected by the application and the criticality of the functions supported, the higher the impact of these vulnerabilities on the application assets.
| |
| − | One important emphasis that is given in the vulnerability metrics is the determination of the number of vulnerabilities that are still not fixed. A given number of application vulnerabilities might still be “open” that is not yet fixed in production environment: these represent a risk to the organization and require the CISO to prioritize the risk mitigating action such as “closing” the vulnerability within the compliance timeframes that is deemed acceptable by the application vulnerability management standards.
| |
| − | | |
| − | ===Security Incident Metrics===
| |
| − | | |
| − | Another CISO important metrics for the managing of information security risks is the reporting of security incidents for web applications that are developed and/or managed by the organization. The CISO might gather this data from reported from SIRT (Security Incident Response Team Incidents) that affect a given web application such as breaches of data as results of an exploit of a vulnerability. The correlation of the security incidents reported for a given web application with the vulnerabilities reported by security testing allows the CISO to prioritize the risk mitigation effort on mitigating vulnerabilities that might cause the most impact to the organization. Obviously, waiting for a security incident to occur to decide which vulnerabilities to mitigate is symptomatic of a reactive rather than proactive approach toward risk management.
| |
| − | | |
| − | ===Threat Intelligence Reporting and Attack Monitoring Metrics===
| |
| − | | |
| − | Risk proactive organizations do not wait for security incidents to occur but rather learn from information about attacks and threat intelligence and use that information to take proactive risk mitigation measures such as to develop and implement countermeasures yet mitigating all high risk known vulnerabilities that might be potentially exploited in an incident to cause the most impact to the organization. The CISO can use threat intelligence reports as well as metrics from monitored application layer security events such as from SIEM (Security Incident Event Management) systems to assess the level of risk. Unfortunately today, most of security incidents are discovered and reported only after months from the initial intrusion or data compromise. A security metrics that is actionable toward preventing risks of attacks is of critical importance for CISO since it might allow deciding which web applications to put under alert and monitoring and to act quickly in the case of an attack. For example a threat alert of a possible distributed denial of service against online banking applications might allow the CISO to put the organization on alert and prepare to roll out countermeasures to prevent outage. A reported threat of malware targeting online banking applications to steal user credentials and conduct un-authorized financial transactions for example allows the CISO to issue monitoring alerts for the online banking application secure incident event monitoring management team.
| |
| − | | |
| − | == Security in SDLC Issue Management Metrics ==
| |
| − | | |
| − | ===Metrics for Risk Mitigation Decisions===
| |
| − | | |
| − | Once vulnerabilities are identified the next step is to decide which should be fixed and when and how should be fixed. The first question can be answered by the vulnerability assessment process compliance requirements that might require for example of high risk type of vulnerabilities to be remediated in shorter time frames than medium and low risk type of vulnerabilities. The requirement might also vary depending on the type of web application, being for example a totally newly developed web application versus a new release of an existing web application. Since new web applications were not security tested before, they represent higher risks than existing web applications and therefore this might require that high risk vulnerabilities to be mitigated prior to release the application in the production. Once the issues are identified and prioritized for mitigation based upon the risk severity of the vulnerability, the next step is to determine how to fix the vulnerability. This depends on factors such as the type of the vulnerability such as the security controls/measures that are affected by the vulnerability and where the vulnerability is most likely being introduced. This type of metrics allows the CISO to point to the root causes of vulnerabilities and present the case for remediation to the application development teams.
| |
| − | | |
| − | ===Metrics for Vulnerability Root Causes Identification===
| |
| − | | |
| − | When the vulnerability metrics is reported as a trend, it allows the CISO to assess improvements. For example, in the case the same type of security issues are measures over time for the same type of web application, it is possible for the CISO to point to potential root causes. For example, with trend vulnerability metrics and categorization of the type of vulnerabilities, it is possible for the CISO to make the case of investing in certain type of security activities such as process improvements, adoption of testing tools as well as training and awareness. For example, the metrics showed in figure 1 shows positive trends of certain type of vulnerabilities by comparing two quarterly releases of the same web applications. Application security improvements measures as a reduced number of vulnerabilities identified from one quarterly release to another is observed for most vulnerability types except for authentication and user/session management issues.
| |
| − | | |
| − | [[File:VA_Metrics.jpg]]
| |
| − | | |
| − | The CISO might use this metrics to discuss with CIOs and development directors on whether the organization is getting better or worst over time in releasing more secure application software and to direct the application security resources (e.g. process, people and tools) where is most needed for reducing risks. With the metrics shown in Figure 1 for example, assuming the application changes introduced between releases do not differ much in term of type and complexity of the changes introduced as well as the number and the type of software developers in the development team and the tools used, a case can be made on focusing on the type of vulnerabilities that the organization is having trouble fixing such as better design and implementation of authentication and user/session management controls. The CISO might then coordinate with the CIO and the development directors to schedule a targeted training on this type of vulnerabilities, document development guides for authentication and session management and adopt specific security test cases. Ultimately this coordinated effort will empower software developers in designing, implementing and testing more secure authentication and session management controls and show these as improvements in the vulnerability metrics.
| |
| − | | |
| − | ===Security Defect Management Metrics===
| |
| − | | |
| − | Another important aspect of the S-SDLC security metrics is to decide where in the SDLC to invest in security testing and remediation. To know this, it is important to measure in which phase of the SDLC the most of vulnerabilities (higher percentage of issues) originate, when these vulnerabilities are tested and how much cost to the organization to fix them in each phase of the SDLC. A sample metrics that measure this is shown in figure 2 based upon a case study on the costs of testing and managing software bugs (Ref Capers Jones Study).
| |
| − | | |
| − | [[ File:Issue_SDLC_metrics.jpg]]
| |
| − | | |
| − | A similar type of security defect management metrics can be used by the CISOs for managing security issues effectively by reducing overall security costs. Assuming the CISO has rolled out a security in the SDLC process and has budget allocated for investment in security in the SDLC activities such as secure coding training and secure code review process and static code analysis tools, this metrics allows the CISO to make that case for investing in testing and fixing security issues in the early phases of the SDLC. This is based upon the following measurements from this case study: 1) most of the vulnerabilities are introduced by software developers during coding, 2) the majority of these vulnerabilities are tested during field tests prior to production and 3) testing and fixing vulnerabilities late in the SDLC is the most inefficient way to do it since is approx. ten times more expensive to fix issues during pre-production tests than during unit tests. CISOs can use vulnerability case studies like these or use their own metrics to make the case for investing in secure software development activities since these will save the organization time and money.
| |
| − |
| |
| − | == References ==
| |
| − | | |
| − | Ref [1]: Verizon 2011 Data Breach Investigation Report: http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2011_en_xg.pdf
| |
| − | | |
| − | Ref [2]: US Q2 2011 GDP Report Is Bad News for the US Tech Sector, But With Some Silver Linings: http://blogs.forrester.com/andrew_bartels/11-07-29-us_q2_2011_gdp_report_is_bad_news_for_the_us_tech_sector_but_with_some_silver_linings
| |
| − | | |
| − | Ref [3]: Supplement to Authentication in an Internet Banking Environment: http://www.fdic.gov/news/news/press/2011/pr11111a.pdf
| |
| − | | |
| − | Ref [4] PCI-DSS: https://www.pcisecuritystandards.org/security_standards/index.php
| |
| − | | |
| − | Ref [5] OWASP Top Ten: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
| |
| − | | |
| − | Ref [6] Gartner teleconference on application security, Joseph Feiman, VP and Gartner Fellow [http://www.gartner.com/it/content/760400/760421/ks_sd_oct.pdf http://www.gartner.com/it/content/760400/760421/ks_sd_oct.pdf]
| |
| − | | |
| − | Ref [7] Identity Theft Survey Report, Federal Trade Commission,September, 2003: http://www.ftc.gov/os/2003/09/synovatereport.pdf
| |
| − | | |
| − | Ref [8] Dan E Geer Economics and Strategies of Data Security: http://www.verdasys.com/thoughtleadership/
| |
| − | | |
| − | Ref [9] Data Loss Database: http://datalossdb.org/
| |
| − | | |
| − | Ref [10] WHID, Web Hacking Incident Database: http://projects.webappsec.org/w/page/13246995/Web-Hacking-Incident-Database
| |
| − | | |
| − | Ref [11] Imperva's Web Application Attack Report: http://www.imperva.com/docs/HII_Web_Application_Attack_Report_Ed1.pdf
| |
| − | | |
| − | Ref [12] Albert Gonzalez data breach indictment: http://www.wired.com/images_blogs/threatlevel/2009/08/gonzalez.pdf
| |
| − | | |
| − | Ref [13] First Annual Cost of Cyber Crime Study Benchmark Study of U.S. Companies, Sponsored by ArcSight Independently conducted by Ponemon Institute LLC, July 2010: http://www.arcsight.com/collateral/whitepapers/Ponemon_Cost_of_Cyber_Crime_study_2010.pdf
| |
| − | | |
| − | Ref [14] 2010 Annual Study: U.S. Cost of a Data Breach: http://www.symantec.com/content/en/us/about/media/pdfs/symantec_ponemon_data_breach_costs_report.pdf?om_ext_cid=biz_socmed_twitter_facebook_marketwire_linkedin_2011Mar_worldwide_costofdatabreach
| |
| − | | |
| − | Ref [15] Gordon, L.A. and Loeb, M.P. “The economics of information security investment”, ACM Transactions on Information and Systems Security, Vol.5, No.4, pp.438-457, 2002.
| |
| − | | |
| − | Ref [16] Total Cost of Ownership: http://en.wikipedia.org/wiki/Total_cost_of_ownership
| |
| − | | |
| − | Ref [17] Wes SonnenReich, Return of Security Investment, Practical Quantitative Model: http://www.infosecwriters.com/text_resources/pdf/ROSI-Practical_Model.pdf
| |
| − | | |
| − | Ref [18] Tangible ROI through Secure Software Engineering: http://www.mudynamics.com/assets/files/Tangible%20ROI%20Secure%20SW%20Engineering.pdf
| |
| − | | |
| − | Ref [19] The Privacy Dividend: the business case for investing in proactive privacy protection, Information Commissioner's Office, UK, 2009: http://www.ico.gov.uk/news/current_topics/privacy_dividend.aspx
| |
| − | | |
| − | Ref[20] Share prices and data breaches: http://www.securityninja.co.uk/data-loss/share-prices-and-data-breaches/
| |
| − | | |
| − | Ref[21] A commissioned study conducted by Forrester Consulting on behalf of VeriSign: DDoS: A Threat You Can’t Afford To Ignore: http://www.verisigninc.com/assets/whitepaper-ddos-threat-forrester.pdf
| |
| − | | |
| − | Ref[22] Sony data breach could be most expensive ever: http://www.csmonitor.com/Business/2011/0503/Sony-data-breach-could-be-most-expensive-ever
| |
| − | | |
| − | Ref[23] Health Net discloses loss of data to 1.9 million customers: http://www.computerworld.com/s/article/9214600/Health_Net_discloses_loss_of_data_to_1.9_million_customers
| |
| − | | |
| − | Ref[24] EMC spends $66 million to clean up RSA SecureID mess: http://www.infosecurity-us.com/view/19826/emc-spends-66-million-to-clean-up-rsa-secureid-mess/
| |
| − | | |
| − | Ref[25] Dmitri Alperovitch, Vice President, Threat Research, McAfee, Revealed: Operation Shady RAT: http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf
| |
| − | | |
| − | Ref[26] OWASP Security Spending Benchmarks Project Report: https://www.owasp.org/images/b/b2/OWASP_SSB_Project_Report_March_2009.pdf
| |
| − | | |
| − | Ref[27] The Security Threat/Budget Paradox: http://www.verizonbusiness.com/Thinkforward/blog/?postid=164
| |
| − | | |
| − | Ref [?] S-SDLC processes: MS-SDL, OWASP-CLASP, Cigital-TP
| |
| − | | |
| − | Ref [?] ESAPI
| |
| − | | |
| − | Ref[?] OWASP-CLASP
| |
| − | | |
| − | Ref[?] OWASP- Development Guide
| |
| − | | |
| − | Ref[?] OWASP- Coding Guide
| |
| − | | |
| − | Ref[?] OWASP- Testing Guide
| |
| − | | |
| − | Ref [?] Security and the Software Development Lifecycle: Secure at the Source, Aberdeen Group, 2011 http://www.aberdeen.com/Aberdeen-Library/6983/RA-software-development-lifecycle.aspx
| |
| − | | |
| − | Ref [?] State of Application Security - Immature Practices Fuel Inefficiencies, But Positive ROI Is Attainable, Forrester Consulting, 2011 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=813810f9-2a8e-4cbf-bd8f-1b0aca7af61d&displaylang=en
| |
| − | | |
| − | == About OWASP ==
| |
| − | | |
| − | ''Short piece about OWASP and including links to Projects, ASVS, SAMM, Commercial Code of Conduct, Citations, ???''
| |
| − | | |
| − | == Appendix I-A: Value of Data & Cost of an Incident ==
| |
| − | | |
| − | ''The discussion of various information sources, which gives a single illustrative value for the main text''
| |
| − | | |
| − | === Value of Information ===
| |
| − | | |
| − | The selection of security measures must consider the value of asset being protected. Like personal data, all types of data can have value determined from a number of different perspectives. While it may be most common the look at the value of data by its value as an asset to the organization or the cost of an incident, these are neither always the most appropriate nor greatest valuations to consider. For example, a report looking at the value of personal data (personally identifiable information) suggests four perspectives from which personal information draws its privacy value (Ref 19). These are:
| |
| − | | |
| − | *its value as an asset used within the organization’s operations;
| |
| − | *its value to the individual to whom it relates;
| |
| − | *its value to other parties who might want to use the information, whether for legitimate or improper purposes;
| |
| − | *its societal value as interpreted by regulators and other groups.
| |
| − | | |
| − | The value to the subject of the data, to other parties or to society may be more appropriate for some organizations than others. The report (ref 19) also examines the wider consequences of not protecting (personal) data and the benefits of protection. It describes how incidents involving personal data that lead to financial fraud can have much larger impacts on individuals, but that financial effects are not the only impact. The report provides methods of calculation, and provides examples where the value of an individual's personal data record could be in the £500-£1,100 (approximately $800-$1,800) in 2008.
| |
| − | | |
| − | === Data Breaches and Monetary Losses ===
| |
| − | | |
| − | Regarding the monetary loss per victim, exact figures vary depending on the factors that are considered to calculate them depending by the type of industry and the type of attack causing the data loss incident. According to a July 2010 study conducted by Ponemon Institute (Ref[13]) on 45 organizations of different industry sectors about the costs of cyber attacks, the costs of web-based attacks is 17% of the annualized cyber-attack costs. This cost varies across different industry sectors with the higher costs for defense, energy and financial services ($16.31 million, $15.63 million and $12.37 million respectively) than organization in retails, services and education.
| |
| − | | |
| − | Also according to the 2011 Ponemon Institute annual survey of data loss costs for U.S. companies (Ref[14]), the average cost per compromised record in 2010 was $214 up 5% from 2009. According to this survey, the communication sector bear the highest cost of $380 per customer record with financial services the second highest cost of $353 followed by healthcare with $345, media, at $131, education at $112 and the public sector at $81.
| |
| − | | |
| − | The security company Symantec, which sponsored the report, developed with Ponemon Institute a [http://databreachcalculator.com.sapin.arvixe.com/ data breach risk calculator] that can be used to calculate the likelihood of data breach in the next 12 months, as well as to calculate the the average cost per breach and average cost per lost record.
| |
| − | | |
| − | The Ponemon institute direct costs estimates, are also used for estimating the direct cost of data breach incidents collected by OSF DataLossDB (Ref[9]). 2009 direct cost figures of $60.00/record are multiplied by the number of records reported by each incident to obtain the monetary loss estimate. It is assumed that direct costs are suffered by the breached organizations while this is not always true such as in the case of credit card number breaches where the direct costs can often be suffered by banks and card issuers. Furthermore, estimate costs does not include indirect costs (e.g. time, effort and other organizational resources spent) as well as opportunity costs (e.g. the cost resulting from lost business opportunities because of reputational damage).
| |
| − | | |
| − | According to (Ref [8]) another possible ways to make a risk management decision on whether to mitigate a potential loss is to determine if the company will be legally liable for that data loss. By using the definition of legal liability from a U.S. liability case law, given as Probability (P) of the loss, (L) the amount of the Loss, then there is liability whenever the cost of adequate precautions or the Burden (B) to the company is:
| |
| − | | |
| − | B < P x L
| |
| − | | |
| − | By applying this formula to 2003 data from the the Federal Trade Commission (FTC) for example (Ref [7]), the probability of the loss is 4.6% as the amount of the population that suffered identity fraud while the amount of the loss x victim can be calculated by factoring how much money was spent to recover from the loss considering the time spent was 300 million hours at the hourly wages of $ 5.25/hr plus out of pocket expenses of $ 5 billion:
| |
| − | | |
| − | L = [Time Spent x Recover From Loss x Hourly Wage + Out Of Pocket Expenses]/Number of Victims
| |
| − | | |
| − | With this formula for calculating the amount of loss due to an identity fraud incident, based upon 2003 FTC data, the loss per customer/victim is approximately $ 655 dollars and the burden imposed to the company is $ 30.11 per customer/victim per incident.
| |
| − | | |
| − | The risk management decision is then to decide to whether it is possible to protect a customer for $ 30.11 per customer per annum. If it is, according to (Ref [8]) then liability is found and there is liability risk for the company. This calculation can be useful to determine the potential liability risk in case of data loss incidents, for example by applying the FTC figures to the TJX Inc. incident of 2007 where it was initially announced the exposure of confidential information of 45,700,000 customers, the exposure to the incident for the victims involved could be calculated as:
| |
| − | | |
| − | Cost exposure to the incident = Number of victims exposed by the incident x loss per victim
| |
| − | | |
| − | With this formula using TJX Inc data or number of victims affected and by applying the loss per victim using FTC data, the cost of the incident that represents the loss potential is $ 30 Billion. By factoring this with the probability of the incident occurring, then it is possible to determine how much money should be spend in security measures. In the case of TJX Inc incident for example, assuming a 1 in 1000 chance of occurrence a $ 30 Million security program for TJX Inc would have been justifiable.
| |
| − | | |
| − | === Summary ===
| |
| − | | |
| − | We can see that there are different ways to determine the value of information and the that some of these are purely based on the costs relating to data breaches. But overall, the references suggest that typically individual's data can be valued in the range $500 to $2,000 per record.
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == Appendix I-B: Calculation Sheets ==
| |
| − | | |
| − | ''Some grids for CISOs to enter their own numbers and calculations''
| |
| − | | |
| − | == Appendix I-C: Online Calculator ==
| |
| − | | |
| − | A calculator for estimating the cost incurred by organizations, across industry sectors, after experiencing a data breach is provided by Symantec based upon data surveys of the Ponemon institute: https://databreachcalculator.com/
| |
| − | | |
| − | <br>{{Template:Stub}}
| |
| | | | |
| | [[Category:OWASP_Application_Security_Guide_For_CISO_Project]] | | [[Category:OWASP_Application_Security_Guide_For_CISO_Project]] |
