Revision as of 03:12, 18 September 2013

Introduction

OWASP is a non profit organization whose mission is "making application security visible and empowering application security stakeholders with the right information for managing application security risks". Among the application security stakeholders, Chief Information Security Officers (CISOs) are often the ones responsible for application security from governance, compliance and risk perspectives. This guide seeks to help CISOs manage application security programs according to CISO roles, responsibilities, perspectives and needs. Specifically, this guide is being developed by OWASP in parallel with the 2013 CISO survey. The CISO survey is used to tailor this guide to the specific CISOs needs by highlighting which OWASP projects/resources address these needs.

This CISO guide is written specifically to help CISOs that are responsible for managing application security programs from the information security and risk management perspectives. From the information security perspective, there is a need to protect the organization assets such as the citizen/client/customer sensitive data, the databases where this data is stored, the network infrastructure where the database servers reside and last but not least the applications and software used to access and process this data. Among the assets that CISOs seek to protect, besides business and user data there are also applications and software as a whole since these might provide business critical functions to customers that generate revenues for the organization. Examples include applications and software that provide customers with business services as well as applications and software that are sold as products to the clients. In the case when software application are considered information assets to protect. Since both directly or indirectly provide services to citizens/clients/customers, application security should receive a specific focus in human resources, training, processes, standards and tools. The scope of this guide is the security of software applications and the security of the related infrastructure such as the security of web servers, application servers and databases. This does not include other aspects of security that are not specifically related to the specific application, such as the security of the network infrastructure that supports the applications and constitutes a valued asset whose security properties such as confidentiality, integrity and availability need to be protected as well.

The fact that applications ought to be considered company's assets is "per se" a good reason to put applications in scope for compliance with information security policies and standards. The impact of compliance with information security policies and standards for applications typically depends on the classification of the asset-data stored by the application, the type of exposure of the application to the users (e.g. internet, intranet, extranet) and the risk of the functionality that the application supports with the data (e.g. access to confidential data, transfer of money, payments, users administration etc). From information security perspective, applications should be in scope for organizations specific vulnerability assessments and application security requirements. The security validations and certifications of applications follow specific security requirements such as for the secure design, secure coding and secure operations. These are often part of the goals of application security standards. Therefore compliance is a critical aspect of application security and of CISOs responsibilities but not the only one.

Application security spans also other security domains that CISOs are responsible for. These can be summarised as (GRC) Governance, Risk and Compliance.

From governance perspective CISOs are responsible to institute application security processes, roles and responsibilities to manage them and software security training and awareness for software developers such as defensive coding and vulnerability risk management for information security officers/managers.
From the risk management perspective, the risks managed by the CISOs also include application security risks such as the risks of specific threats targeting applications that process confidential user data by seeking to exploit gaps in security controls as well as vulnerabilities in applications.
Among CISOs security domains, compliance with regulations and security standards is often the one that gets the most attention from the organization's executive management. The aim of this guide, is to help CISOs fulfil compliance requirements as well as to use compliance requirements as one of the reasons for justifying investments in application security. For some organizations managing risks of security incidents such as credit card fraud, theft of personal identifiable information, theft of intellectual property and confidential data is what gets most of executive management attention especially when the organization has been impacted by data breach security incidents.

The mitigation of the risks of cyber threats targeting the organization's assets is today one of the CISOs top priorities. This is due to the emerging cyber threats that characterise today's threat landscape. These threat agents are financially motivated and often seek to either steal money or valuable data such as citizen's personal data, customer's financial accounts, client data and business intellectual property data. Because of the continuously evolving cyber threats and attacks increasingly targeting applications, their source code and data, CISOs today focus on the protection of these assets from these cyber threats. For these reasons, one of the primary goals of this guide is to help CISOs managing the risk of cyber threats specifically targeting these. This guide for example will focus on threat analysis and risk management besides the traditional vulnerability management that is done for applications. For example, managing application risks deals with the identification of the value assets such as mission critical applications, the analysis of threats against these assets, the assessment of vulnerabilities exposing these assets and the selection of security measures to reduce potential impacts for the exploit of these vulnerabilities for the business.

To make informed decisions on how to manage application security risks, CISOs often need to assess the costs of fixing known vulnerabilities and adoption of new countermeasures and to consider the risk mitigation benefits of doing so. Costs vs. benefits trade offs are critical to decide on which application security measures and security controls to invest in to reduce the level of risk. Often CISOs need to explain to executive management what are the risks to applications and articulate the potential business impacts for the organization in case applications are attacked and confidential data is breached. Often a CISO is asked by the business executives to articulate what are the business impacts of potential attacks directed to steal the organization intellectual property and digital assets to understand if the risks are unmitigated so they can decide if it is necessary to invest in new application security measures to mitigate these risks. The aim of this guide is to help CISOs in articulating the needs for application security to the business by analysing the economical impacts derived by the exploits of insecure applications.

One important aspect covered by this guide is to create awareness of the economical impacts caused by the loss and the compromise of confidential data stored and processed by applications. Today's cyber threat landscape is characterised more and more by value driven threat agents rather than the ego driven threat agents of ten years ago. Ego driven threat agents such as script kiddies and hackers sought to exploit computer vulnerabilities for fame. Today's threat agents seek financial gain such as by attacking applications to compromise users' sensitive data and company’s proprietary information for financial gain, fraud as well as for competitive advantage (e.g. through cyber espionage). To mitigate the risks posed by these threat agents, it is necessary to determine the risk exposure and factor the probability and the impact of these threats as well as to identify the type of application vulnerabilities that can be exploited by these threat agents. The exploit of some of these application vulnerabilities might severely and negatively impact the organization and jeopardise the business. The aim of this guide is also to help technical security managers and project managers to prioritise application vulnerabilities for mitigation. Vulnerability management is a critical process for reducing technical risks that the exploit of these vulnerabilities might entail. Unfortunately, just mitigating the risk of application vulnerabilities might not be enough to protect them from attacks of motivated and persistent threat agents seeking to exploit gaps and holes in the deployment and configuration of applications. Even under the assumption that all vulnerabilities identified within an application are fixed, such an application might still be attacked and impacted because of the lack of adequate countermeasures against specific threats. To help CISOs to decide which countermeasures are cost effective for mitigating the risks of specific threats against applications, this guide aims to provide criteria to CISOs for estimating the economical impact that data breach incidents sought by these threats. By estimating the impact for the business of security incidents is possible to compare them with the costs of the security measures to decide which measures to apply.

For risk complacent organizations, the situational awareness of the type of security incidents impacting applications and of the emerging threats causing them, not always translates in the adoption of a new application security measure or of strategic processes to proactively mitigate these risks. For risk adverse organizations, cyber threat awareness of which applications are the primary targets from cyber attacks and incidents might translate in giving CISOs the responsibility for creating a new cyber-threat risk management strategy for mitigating the risk of emerging threats. For organizations that have a conservative approach toward mitigation of the cyber risks a sound risk mitigation strategy consists of proactively managing application security risks. Simply put, proactive risk management in the case of application and software security is one of the goals of security engineering. At a minimum, this includes identifying application vulnerabilities and fixing them before these could be exploited by threat agents and negatively affect the organization's business.

Often vulnerability assessments are just the bare minimum technical risk mitigation process and often these required for compliance with internal information security policies. Unfortunately just identifying vulnerabilities and fixing them is not enough for mitigating the risk of today's emerging cyber-threats. The mitigation of the risk if emerging cyber-threats requires the adoption of new security measures and application security processes that adapt to these cyber-threats. For several organizations the adoption of new application security measures and processes often depends upon different factors besides threat awareness also costs and the organization risk culture also referred by risk managers as the organization "appetite" for risk. This appetite for risk is typically low when one of the organization has been impacted by a security incident and incurred in financial losses as result of it. For some organizations today unfortunately, this is rather the norm then a probability as for many organizations that have already experienced security incidents. Often these security incidents cause significant impact to the business and applications have been targeted resulting in the loss and the compromise of confidential and sensitive data. Because cyber threats are real and impacts noticeable CiSOs are often the ones that are asked by executive management to respond if security incidents involving applications could have been prevented. Unfortunately, for the majority of the CISOs today the question is not "IF" their applications will be impacted by a data breach incident but "WHEN". CISOs therefore need to be prepared to answer these questions more often. One thing that CISOs can do is to make sure application risk are communicated to the business executives such as by providing “emerging cyber-threat awareness” to executive management. CISOs need to be real about cyber-threat risks and present to the business the overall picture of information security risks, not just compliance and vulnerabilities but also security incidents and threat intelligence of threat agents targeting the organization information assets including for applications.

Cyber-threat risk awareness is necessary today to justify a request of spending in application security measures such as processes, tools and technologies to reduce the impact of these cyber-threats to the organization.For CISOs, the understanding of the security investment budgeting constraints, the reasons for investment in application security and the prioritisation of risk mitigation measures within these reasons and constraints is mandatory. For some type of organizations such as financial organizations, the majority of the investments in application security is spent to comply with information security standards and regulatory requirements to pass audits and certifications. For organizations already impacted by security incidents involving applications, the need of investment in application security is for making sure other security incidents in the future won't cause further data losses. In both cases, ability to communicate risks to the business empowers CISOs to articulate the business case for application security and justify additional spending in application security measures. This justification need to consider the economical impact of security incidents comparing with the costs of unlawful non compliance. Today's costs to the business due to the economical impacts of security incidents is much higher than the costs of non-compliance and failing audits. Often the severity of the impact of security incidents might costs CISOs their jobs and the company loosing reputation and revenues.

The focus on mitigating the impact of security incidents targeting applications and software today is no longer an option but a necessity. From risk management perspective, the main questions that CISOs need to answer are "what is the likelihood and impact of application security incidents" and "what are the most cost effective measures to prevent and application security incident". One aspect of risk prevention is focusing on vulnerability testing and vulnerability risk management programs. OWASP is the primary source to provide organizations with the top ten web application risks that need to be mitigated. The testing of OWASP T10 might require organizations to routinely perform security testing of these vulnerabilities in web applications. Once the vulnerabilities are identified and the severity assigned to these, it is important to have a vulnerability management process that allow managers to prioritise the fixes of these vulnerabilities by risk severity but also by the business impacts that might cause in the case these will be exploited by an attacker.But vulnerabilities are just one aspect of risk mitigation for application security risks. Besides managing the risk of application vulnerabilities, it is also important to deploy countermeasures against emerging top cyber-threats targeting applications such as denial of service, hacking and malware.

Another important factor to consider in applying security measures is to follow information security principles and best practices. Today, preventive and detective security controls play an important role in mitigating application security risks and should be considered by CISOs as necessary security measures. There is no silver bullet such and "no one security measure fits all application security needs”. Therefore, proactive and detective security measures need to be implemented at different layers of the application architecture by following security principles such as the principle of “defence in depth” that is to apply layers of security controls that attacks need to break into while at the same time these attacks can be detected and countermeasures can be deployed to resist from them. A good example of application of defence in depth is the mitigation of Distributed Denial of Service (DDoS) attacks agains applications. At the most outer layer that is the edge of the internet it is possible to filter the malicious traffic before attacks the internal layer that is the data centre where the application is hosted and other countermeasures are implemented. As the DDoS attacks take place, defence in depth allows the organization to be alerted and prepare new filtering blocking rules for malicious traffic. But applying the principle of defence in depth, even if it can slow down attackers, is not enough and other defensive security principles need to be followed when deploying countermeasures as well such as to consider control of security of the weakest point, consider the simplicity and openness of the security mechanism so can be managed and vetted securely, apply security as the least privilege for users' access are all essential for the security of the design of security controls of applications and software.

Changes to applications are also are a source of potential risks especially when new or different technologies are integrated within applications. As applications evolve by offering new services to citizens, clients and customers, it is also necessary to plan for mitigation of new vulnerabilities introduced by the adoption and implementation of new technologies such as mobile devices, web 2.0 and new services such as cloud computing. Adopting a risk framework to evaluate the risks introduced by new technologies is essential to determine which countermeasures to adopt to mitigate these new risks. This guide will provide guidance for CISOs on how to mitigate risks of new threats against applications as well as of vulnerabilities that might be introduced by the implementation of new technologies.

From the risk management strategic point of view, the mitigation of application security risks is not a one time exercise; rather it is an ongoing activity that requires paying close attention to emerging threats and planning ahead the deployment of new security measures to mitigate these new threats. This includes the planning for the adoption of new application security activities, processes, controls and training. When planning for new application security processes and controls, it is important for CISOs to know on which application security domains to invest. Accessing process maturity is a prerequisite for adoption of application security and software security processes. One criteria that is often adopted by organizations is to consider the organization's capabilities in application security domains and the maturity of the organization in operating in these domains. Examples of these application security 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, adopt software security assurance if often necessary when there is not direct control on implementing the security of such software since is produced by a third arty vendor. A factor to consider in this case is to measure the software security assurance using a maturity model. A pre-requisite for measuring software security assurance is the adoption of a Secure Software Development Lifecycle (S-SDLC). At high level, S-SDLC consists on embedding "build security in" security activities, training and tools within the SDLC. Examples of these activities might include software security processes/tools such as architectural risk analysis/ threat modelling, secure code reviews/static source code analysis, application security testing/application vulnerability scanning and secure coding for software developers. A reference to OWASP software assurance maturity model as well as to the several OWASP projects dedicated to software security and S-SDLC are provided in this guide as well.

Finally, after application security and software security investments are made, it is important for CISOs to measure and report the status of governance, risk and compliance of the application security program to executive management. Metrics for application security are also necessary for management of processes. One necessary tool that helps CISOs are application risk management metrics. The goal of the risk management metrics is to support informed decisions to decide where to focus the risk mitigation effort and to manage application security risks more effectively. These risk management goals are usually very organization specific and depend on the type of organization and the industry sector that the organization does business with, to decide which application security risks should be prioritised for action. For the sake of this guide, some general guidance on application security metrics suitable for measuring governance, risk and compliance of application security processes are also included herein. One aspect that is often neglected when spending on software security is the economics of dealing with insecure software applications. The investment in software security to identify and fix security issues prior to release of software in production actually pays by itself because save the organization money. Patching vulnerabilities after applications are released into production is very expensive; it is much cheaper than to invest in secure architecture reviews to identify design flaws and remediate them prior to coding, as well as to invest in secure code reviews to identify and fix security bugs in software during coding, and to ensure that releases are configured correctly. An example of the metrics that can help CISOs measure the savings in security testing costs incurred by testing software for software vulnerabilities prior to vulnerability penetration testing it is also included in this guide.

Goal & Objectives

The main goal of this guide to help CISOs in managing the security risks that applications face today by considering the exposure to emerging threats and the compliance requirements. Specifically in regarding the management of application security programs and initiatives within the organization, this guide seeks to achieve the following specific objectives:

Make application security visible to CISOs
Assure compliance of applications with security regulations for privacy, data protection and information security
Prioritise the fixing of application vulnerabilities based upon the risks that these pose to the business
Provide guidance for instituting and managing application security processes
Analyse cyber-threats and attacks targeting applications and identify countermeasures
Institute application security training for developers and managers
Measure and manage application security risks and processes

in seeking to accomplish these objectives, reference to application security best practices and to OWASP documentation resources is made throughout this guide.

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Foreword

This guide is being funded under OWASP project reboot program and developed in alignment of OWASP core values reflected in the openness of the content, innovative ideas and concepts, global reach to the application security community and integrity of the contents that are published as strictly vendor neutral and un-biased by specific commercial interests.This guide has also been developed in respect of the OWASP core values such as to “Promote the implementation of and promote compliance with standards, procedures, controls for application security” and the OWASP principles of delivering free and open content, not for profit interests and a risk based approach for improving application security. The leader of the OWASP Application Security Guide for CISOS project is Marco Morana that developed the original contents of this guide with contributions from Colin Watson, Eoin Keary and Tobias Gondrom and Stephanie Tan.

This project is being developed by the OWASP in parallel with the CISO Survey project lead by Tobias Gondom
The objective is to run these two projects in synch and use the results of the 2013 CISO survey to tailor the guide to the specific CISOs needs by highlighting which OWASP projects/resources address these needs. The final version of the OWASP Application Security Guide for CISO will be presented at the 2013 Appsec USA Conference that will be held in NYC, 18-21 November 2013

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

1 Introduction
2 Goal & Objectives
3 PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK
4 Foreword
5 PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK
6 PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK
7 Part I: Reasons for Investing in Application Security
8 Part II: Criteria for Managing Application Security Risks
9 Part III: Selection of Application Security Processes
10 Part IV: Selection of Metrics For Managing Risks & Application Security Investments
11 References
- 11.1 PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK
12 About OWASP
- 12.1 PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK
13 Appendix

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part I: Reasons for Investing in Application Security

Introduction

In this digital era public and private organizations serve an increasing number of citizens, clients, customers, and employees through applications. Often these applications provide “highly trusted services” over the internet, in the case of financial 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 people: it allows them to perform the same financial transactions as being at the branch/office/outlet, but with the added convenience of conducting these transactions remotely from their home computer or mobile phone. At the same time, this convenience for customers comes at a price to the financial organizations involved in developing and maintaining these applications. Online banking and commerce sites for example, have become the target of an increased number of fraudsters and cyber-criminals and victim of security incidents. Several of these incidents resulted in a denial of online access, breaches of customer’s data and online fraud.

In the case of data breach incidents, often these attacks from fraudsters and cyber-criminals involve the exploitation of applications such as SQL injection to compromise the data stored in the application database and cross site scripting to execute malicious code such as malware on the user’s browser. The targets of these attacks are both the data and the application business functions for processing this data. In the case of online banking applications, the data targeted by hacking and malware include personal data of individuals, bank account data, credit and debit card data, online credentials such as passwords and PINs and last but not least, alteration of data in on-line financial transactions such as transfers of money to commit fraud. Verizon’s 2012 data breach investigations report identifies hacking and malware as the most prominent types of attack, yielding stolen passwords and credentials, and thus posing a major threat to any organization that trades online.

To cope with this increase of incidents targeting applications such as denial of services and data breaches often caused by hacking and malware, Chief Information Security Officers (CISOs) have been called by company’s executives such as the Chief Information Officer (CIO), Legal Counsel or Chief Financial Officer (CFO) to enforce application security measures to avoid, mitigate and reduce application security risks to the organization. For financial organizations for example, the increasing threat to applications such as online banking applications challenges CISOs to enforce additional application security controls an increase the investment in application security to cope with the increasing risk.

Due to the evolving threat landscape and increased pressure from audit, legal and compliance, in the last decade, investments in application security have been a growing proportion of overall information security and information technology budgets. This trend is also captured in applications security surveys such as the 2009 OWASP Security Spending Benchmarks Project Report that for example stated "Despite the economic downturn, over a quarter of respondents expected application security spending to increase in 2009 and 36% expected to remain flat". 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 application features, support of new devices such as mobile phones and investments to retain and attract new clients and customers as well as expand the service uptake or profitability.

Ultimately, in today’s recession type of economic climate and in a scenario of slow growth in business investments including the company’s built-in software, it is increasingly important for CISOs to articulate the "business case" for investment in application security. Since it also appears to be a disconnect between organization's perceived threats (application security threats are greatest) yet spending on network and infrastructure security is still much higher, we would like to shed some light on the business impact of data breaches due to application vulnerability exploits and how much these might costs to organizations.

Typically, additional budget allocation for application security includes the development of changes in the application to fix the causes of the incident (e.g. fixing vulnerabilities) as well as rolling out additional security measures such as preventive and detective controls for mitigating risks of hacking and malware and limiting the likelihood and impact of future data breach incidents.

CISOs can build a business case for additional budget for application security today for different reasons; some directly tailored to the specific company risk culture or appetite for risk; others tailored to application security needs. Some of these needs can be identified by the analysis of the results of application security surveys. To assess these needs, readers of this guide are invited to participate to the OWASP 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 applications. For the sake of this guide we will focus on the following areas to target application security spending:

Compliance with security standards, security policies and regulations;
Identification and remediation of application vulnerabilities;
Implementation of countermeasures against emerging threats targeting applications.

Nevertheless, assuming the business cases can be made along these goals, CISOs today still have the difficult task to determine “how much” money should the company spend for application security and “where” that is on “which security measures” to spend it. Regarding the how much, often it gets down to how much is needed to invest to satisfy compliance requirements and pass the auditor’s check. When the focus is compliance, the focus is to develop and implement application security standards and map these security requirements to current projects. When the focus is vulnerability risk management, the main goal is to fix high risk vulnerabilities and to reduce the residual risk to an acceptable value for the business. When the focus is to security incident management, the focus is how to investigate and analyzed the suspected security breaches and recommend corrective actions. When the focus is application security awareness, the focus is to institute application security training for the workforce.

For today’s CISO there is an increased focus on making decisions for mitigating risks. Both for mitigating real risks (e.g. incidents, vulnerability exploits) and for mitigating non-compliance risks (e.g. unlawful non-compliance), the question for CISOs is "where" and "how" to prioritize the spending of the application security budget. Often the question is which countermeasure, application security process, activity, security tool yields “more bang for the money” for the organization. Regarding the "where" it comes down to balance correctly different application security and risk domains - to name the most important ones: business governance, security risk management, operational management that includes network security, identity management and access control and incident management. Since as a discipline application security encompasses all these domains, it is important to consider all of them and look at the application security investment from different perspectives.

Information Security Standards, Policies and Compliance

Identifying Standards and Policies in Scope for Compliance

One of the main factors for funding an application security program is compliance with information security standards, policies and regulations mandated by applicable industry standards regulatory bodies. Initially, it is important for the CISO to define what is in scope for compliance and how it affects application security. Depending on the industry sector and the geographical location in which the organization operates, there will be several different types of security requirements that the organization need to comply with. The impact of these requirements is also on the applications that manage and process data whose security falls under the scope of these standards and regulations. The impact on applications consists on performing scheduled risks assessment and to report the status on compliance to the auditors. Examples of data security and privacy standards that apply to applications in the US include:

Payment Card Industry (PCI) Data Security Standards (DSS) for organizations whose applications process electronic payments with credit and debit card data
FFIEC guidelines for US financial organizations whose applications allow clients and consumers to bank online and conduct transactions such as payments and money transfers
FISMA law for US federal government agencies whose systems and applications need to provide information security for their operations and assets
HIPAA law for securing privacy of health data whose applications handle patient records in the U.S. healthcare industry
GLBA law for US financial institutions whose applications collect and store individuals’ personal financial information
US State Data Breach Disclosure laws for organizations whose applications store and process US state resident Personal Identifiable Information (PII) data when this data is lost or stolen in clear (e.g. un-encrypted)
FTC privacy rules for organizations whose applications handle private information of consumers in US as well as when operating in EU countries to comply with “Safe Harbor” rules

Capturing Application Security Requirements

PCI-DSS

Most of applications that carry out payment transactions such as merchant type of ecommerce type of applications that handle credit cardholder data are required to comply with the Payment Card Industry Data Security Standard PCI-DSS. The requirements for the protection of cardholder data when is stored by the application includes several PCI DSS requirements such as the rendering or encrypting the Primary Account Number (PAN) and the masking the PAN when it is displayed. The PCI-DSS requirement for card authentication data such as PIN, CVC2/CVV2/CIDs is not to store these data at all even in encrypted form after a payment has been authorized. Credit cardholder data also need to be protected with encryption when is transmitted over open networks. These requirements for protection of cardholder personal account numbers and cardholder authentication data motivates the CISO to document internal security requirements to comply with these provisions and to adopt application security measures and assessment to verify that these requirements are met by the applications that are in scope. Besides protection of cardholder data, PCI-DSS has provisions for the development and maintenance of secure systems and applications, for testing security systems and processes and for the testing of applications for common vulnerabilities such as those defined in the OWASP Top Ten.

The need of compliance with the PCI-DSS requirements can be a reason to justify an additional investment in technology and services for application security testing: examples include source code security reviews with SAST (Static Analysis Security Testing) assessment/tools and application security reviews with DAST (Dynamic Analysis Security Testing) assessments. For a merchant that develops and maintains a web application such as an ecommerce web site that handles credit card payments, the main question is to whether allocate budget to application security measures and activities to comply with PCI DSS or to incur in fines (e.g. Up to $ 500,000 when credit cardholder data is lost or stolen. From this perspective, unlawful/noncompliance with a regulation/standard might be treated as another risk by the organization and as any other risk this could be mitigated, transferred or accepted. If risk of being non-compliant is accepted, CISO should considered that the data breach risk because of not implementing basic security controls such as data encryption but also input validation might be much higher than non-compliance. Consider for example the case of TJX Maxx incident. The company was non-compliant with PCI DSS when the breach of 94 Millions of credit card numbers were compromised, yet the non-compliance costs for failing to encrypt or truncate card numbers as well as to identify and mitigate application vulnerabilities such as SQL injection were less of the overall costs incurred by the businesses impacted because of this security incident of at least by a factor of thousand times higher (if not more) than the costs of not compliance with PCI-DSS (several hundredths of millions of US dollars vs. several hundredths of thousands of US dollars).

FFIEC

In the case of the U.S. banking sector, applications that handle sensitive customer information and allow to process financial transactions such as to transfer money between different bank accounts (e.g. wires) are subjected to comply with strong authentication such as multi factor authentication (MFA) requirements in compliance with Federal Financial Institutions Examination Council (FFIEC) guidelines for online authentication (Ref [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 application.

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 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, applications that store and process data that is considered personal and private by country specific privacy laws need to protect such data when is stored or processed. What is considered private information varies country by country. For countries that are part of the European Union (EU) for example, personal data is defined in EU directive 95/46/EC, for the purposes of the directive: Article 2a: "personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;"

For most of the US States, protection of personal identifiable information (PII) is driven by data breach notification laws such as SB1386 where PII is more narrowly defined than in the EU directive as the individual's first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted: (1) Social security number. (2) Driver's license number or State Identification Card number. (3) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account. For purposes of these laws, "personal information" does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.

Applications that process and store data that is considered personal private data by EU privacy laws or PII by US States data breach notification laws, need to implement security controls such as authentication, authorization, encryption, logging and auditing to protect the confidentiality, availability and integrity of this data. These information security requirements are typically part of the information security policy enforced by the organization. These security requirements, indirectly translate in security requirements for applications that store and process data that is either considered confidential or confidential PII. Budgeting application security program for complying with personal and consumer data privacy requirements is justifiable both as internal compliance with information security policy as well as for mitigating the reputation damage to the organization in the case this data is either lost or compromised. In addition to reputation damage, organizations might incur additional regulatory fines and legal costs in because of unlawful and non-compliant with local privacy laws.

Risk Management

Proactive vs. Reactive Risk Management

Proactive risk management consists on focusing on mitigating the risks of threat events before these might possibly occur and negatively impact the organization. Organizations, whose focus is proactive risk management, plan to protect mission critical assets including applications ahead of potential threats targeting them. Proactive risk mitigation activities for applications include focusing on threat intelligence to learn about threat agents, application threat modeling to learn how the application can be protected by attacks from different threat agents, security testing and fixing of potential vulnerabilities in the application as well as in the source code before these are exploited by potential attackers. Pre-requisite for proactive risk management is have an inventory of the mission critical applications with associated risk profiles that allow CISOs to identify the critical digital assets such as data and functions that need to be prioritized and planned for proactive risk mitigation activities. CISOs whose organizations focus on proactive risk mitigation measures have typically adopted a risk mitigation strategy and act upon information from threat intelligence and monitored security events and alerts to raise the bar on acceptable technical and business risks. CISOs whose focus is proactive risk mitigation usually require the roll out of additional countermeasures ahead of new threats and new compliance requirements.

Reactive risk management consists on responding to risk events as they occur to mitigate negative impacts to the organization. Example of reactive risk management activities includes security incident response, security incident investigations and forensics and fraud management. In the case of application security, reactive risk management activities include vulnerability patch management, fixing application vulnerabilities in response of reported security incidents or when these are identified by third parties, performing application risk assessment due to occasional (not planned) requirements to satisfy specific compliance and audit requirements. CISOs whose organizations focus on reactive risk management typically spend more focus more on responding to unplanned risk management events. Often the focus of reactive risk management is "damage containment" to “stop the bleeding” and less focus is dedicated to planning for risk mitigation ahead of potential negative events targeting applications. Typically organizations whose focus is on reactive risk management have their CISOs spending most of their time on incident response and management and remediating application vulnerabilities either ahead of production releases or patching applications that are already released in production. When the prime focus of the CISO function is on reactive risk management, it is important to recognise that reactive risk mitigation even if cannot always be avoided because security incidents happen, it is not cost effective since the cost of remediating issues after these have been either reported or exploited by an attacker is several factors of magnitude higher than identifying and fixing the same by adopting preventive risk mitigation measures.

A proactive risk mitigation approach is preferable to a reactive risk mitigation approach when making the business case for application security. A proactive risk mitigation approach might consist on using the opportunity of a required technology upgrade of a application to introduce new functionality or when an old applications reached end of life and need to migrate to a newer system/platform. Designing new features to applications represents an opportunity for CiSOS to demand upgrade security technology to new standards and implement stronger security measures as well.

Asset Centric Risk Management

CISOs whose information security policies are derived for compliance with information security standards such as ISO 17799/ISO 27001 include asset management as one of the security domains that need to be covered. In the case when these assets include the applications, assets management requires an inventory of the applications that are managed by the organization in order to implement a risk management approach. This inventory includes information of the type of applications, the risk profile for each application, the type of data that is stored and processed, patching requirements and the security assessments such as vulnerability testing that are required. This inventory of applications is also critical to track application security assessments and risk management processes conducted on the application, the vulnerabilities that have been identified and fixed as well as the ones that are still open for remediation. The risk profile that is assigned to each application can also be stored in the application inventory tool: depending on the inherent risk of the application that depends on the classification of the data and the type of functions that the application provides, it is possible to plan for risk management and the prioritization of the mitigation of existing vulnerabilities as well as for the planning for future vulnerability assessments and application security assessment activities. One of the application security activities that take advantage of asset centric risk management is application threat modeling. From an architecture perspective, assets consist on the several components such as application servers, application software, databases and sensitive. Through application threat modeling, it is possible to identify threats and countermeasures for the threats affecting each asset. CISOs whose focus is on asset risk management, should consider implementing application threat modeling as proactive application security and asset centric risk management activity.

Technical vs. Business Risk Management

When deciding how to mitigating the application security risks it is important to make the trade off between technical risks and business risks. Technical risks are the risks of either technical vulnerabilities or control gaps in a application whose exploit might cause a technical impact such as loss and compromise of data, server/host compromise, unauthorized access to a application data and functions, denial or disruption of service as examples. Technical risks can be measured as the impact of confidentiality, integrity and availability of the asset caused by a technical event/cause such as vulnerability that is identified by a application security assessment. The managing of these technical risks typically depends on the type of the vulnerability and the risk rating assigned to it also referred to as "severity" of the vulnerability. The severity of the vulnerability can be calculated based upon risk scoring methods such as MITRE’s CVSS while the type of vulnerability can be classified based upon the group that the vulnerability falls into such as MITRE's CWE. CISOs can use the risk scoring of a vulnerability reported as HIGH for example to prioritize such vulnerability for mitigation ahead of vulnerabilities that are scored as MEDIUM or LOW risk. In making this technical vulnerability risk management decision, CISO won’t consider the economical impact of the vulnerability to the business such as in the case the value of the asset impacted by the vulnerability is either loss or compromised.

Business risk management occurs when the value of the asset is taken into account to determine the impact to the organization. This requires the association of technical risk of the vulnerability with the asset value to quantify the risk. The risk can be factored as the likelihood of the asset being compromised and the business impact caused by the exploit of the vulnerability. For example, in case that an high risk technical vulnerability such as SQL injection (assumed is fully, 100% exposed as a pre-authentication issue) is exploited, it can be determined to cause an impact to an asset data is classified as sensitive data and whose value is estimated of $ 250/data record. The aggregated value of the sensitive data of 100,000 records stored in a database that could be exploited by SQL injection is therefore $ 25 Million. If the probability of a sensitive data compromise due to the exploit of SQL injection vulnerability is estimated as 10 % (1 successful data breach incidents caused by SQL injection every ten years) the potential economical impact is a loss of $ 2,500,000. Based upon these estimates, it is possible to calculate how much to budget in application security measures for mitigating the risk to the business. It should be noted that estimating business risks is much more difficult than estimating technical risks since business risks estimates require estimates of likelihood of specific type of security incidents as well as the estimates of the monetary losses caused by that incident. Typically these estimates are not easy to make in absence of specific data of frequency of security data breach incidents and records for direct and indirect costs suffered by the organization as result of these security incidents. Nevertheless. statistical data of data breach incidents, estimates of the costs of data breach incidents as well as data breach quantitative risk calculators might help CISOs to estimate a value for business impacts and decide how much is reasonable to spend in security measures to mitigate the risks. Some statistical data for data breaches and risk calculation formulas and vendor supported tools are also provided in this guide as reference.

Risk Management Strategies

Once security risks have been identified and assigned a qualitative value such as high, medium and low risk, the next step for the CISO is to determine what to do with that risk. To decide “what to do with the risks” CISOs usually rely upon their organization's risk management processes and risk mitigation strategy. Risk management processes are usually different for each type of organization. At high level, risk management depends on the risk mitigation strategy that is adopted by the organization. Depending on the assessment of the level of risk impact and probability for example, an organization might decide to accept the risks whose likelihood and impact are low, mitigate or reduce the risks (e.g. by applying security measures) that have high probability and low impact, transfer or share the risks ( e.g. to/with a third party such as through contractual agreements) that are of low probability and high impact and avoid the risk (e.g. such as not to implement high risk functions, not to adopt high risk technologies) for risks that have high probability and impact. A visual example of this risk mitigation strategy factored by event likelihood and impact is shown in the diagram herein.

In the case high risks cannot be avoided because of business decisions requiring to mitigate them and risks cannot be transferred to third parties through contractual agreements and cyber insurance, a possible risk strategy for the organization could be to mitigate all risks that are medium and high and accept (e.g. do nothing) only the ones whose residual risk (e.g. the risk left after either measures or compensating control are either applied or considered) are low. Risk mitigation strategies can also factor business risks using qualitative risk analysis that factor risks such as probability and economical impacts. Once the risk has been determined, the next step is to decide which risk the organization is willing to accept, mitigate, transfer or to avoid. For the risks that the organization is willing to accept it is important for CISOs to have a risk acceptance process that qualifies the low level of risk based upon the presence of compensating controls and that can be signed off by him and executive management. For the risks that are chosen for risk mitigation, it is important to determine which security measures/corrective actions are deemed acceptable by the organization and to decide which of these measures are most effective in reducing risks by minimizing the costs (e.g. highest benefit vs. minimum security measure total costs). This is where the risk mitigation strategy needs to consider the cost of potential security incidents such as data breaches to decide how much is reasonable for the organization to budget for investments in application security measures. An important aspect of the risk strategy for CISOs is to decide which security measures work best together as "pluribus unum" that includes applying preventive and detective controls to provide a defense in depth of the application's assets. Finally, for the risks that are either transferred or shared with third party, it is important for the CISO to work with legal to make sure risk-liability clauses are documented in the legal agreements and service license agreements that are signed by the organization with the third party service provider/legal entity.

Threat Analysis and Awareness of Emerging Threats

Making the business case for additional spending in application security measures is not always justifiable without risk data from the analysis of the impact of emerging threats and the increased level of risks that needs to be mitigated. In absence of threat analysis data that allow to make informed risk management decisions the management is left with subjective considerations about threats. An example of subjective considerations about threats are decisions based upon (FUD) Fear, Uncertainty and Doubt. Unfortunately acting upon FUD to mitigate the risk posed by emerging threats is little too late and not very effective. Example of risk management based upon FUD includes acting upon the fear of data breaches, the fear of failing audit and compliance, uncertain about which threats target the business, how will affect it and doubts about effectiveness of existing security measures in light of recent security incidents. The intent of this part of the guide, is to help CISOs to create additional business case for application security investment based upon objective threat analysis instead of subjective considerations. From compliance with standards perspective, objective considerations are based upon a rationale for investing in applications security that includes complying with new security standards and regulations that impact applications. From threat analysis perspective, objective considerations are based upon data regarding the business impact of emerging threat agents seeking to compromise applications for financial gain. Specifically, in regarding making the case for mitigation of risks, it is necessary for CISOs to avoid assumptions and back the case with data such as reports and analysis of cyber-threats and security incidents, costs of data breaches to estimate liability and quantitative calculations of risk based upon estimate of probability and impacts. Based upon risk calculations and data breach cost estimates, it is possible for the CISO to articulate how much the organization should invest in application security and to determine of which specific measures to invest.

From fear perspective it is true that CISOs can also exploiting the momentum being this either a negative or positive event but this is part of reactive risk management approach and low maturity in dealing with risks. Often application security spending can be triggered by a negative event such a security incident (use survey again to confirm), since this shifts senior management's perception of risk. In this case the money is probably already being spent to limit the damage such as to remediate the incident and implement additional countermeasures. The main question then is what further investment in application security will reduce the likelihood and impact of another similar incident happening in the future. One possible approach is to focus on applications that might become a target for future attacks.

Addressing the Business Concerns after a Security Incident

Risk quantification can be used as criteria for quantify how much money should be spent to mitigate the risk posed by insecure applications. From risk analysis perspective, if an application has been already attacked and sensitive data already being lost or compromised, it might already be brought to the attention of the business and in scope for identification, remediation and testing of the vulnerabilities that might had been the cause of the exploit/security incident. The next step, might be the design and implementation of risk prevention and detection security controls for similar applications and software that might be at risk of similar attacks and incidents in the future. The main question for the CISO is which application security measures and activities should be targeted for spending to mitigate the risks of breaches of sensitive data due to malware and hacking attacks to applications and software that is developed and managed by the organization.

In Part II of this guide, we address how to target spending to mitigate the risk posed by specific attacks and vulnerability exploits. This helps in prioritizing risk mitigation by likelihood and business impact. From the perspective of risk management, application security spending matching all of the costs of the impact of a possible data breach is not justifiable. The main question for the CISOs is how much should be spent to mitigate the risk of data breach incidents, if not 100%, it is the 50%, 25% or 10% of all possible monetary losses? Also does the total loss estimate includes non-monetary losses such as reputation loss? In addition, if allocating a budget of 25% of the estimated potential losses due to data breaches is justifiable, how much of this 25% should be allocated in upgrading security in applications that have a similar risk profile of the application being breached. Besides investing in security controls, how much should also be invested in improving secure software development/engineering processes, security training and improvements in application security testing? Part II and III of the guide will specifically address these questions and provide the rationale of which security controls and security activities to target for spending.

Budgeting of Application Security Measures for Mitigating Risks of Data Breach Incidents

For guiding the CISOs in making decisions on "how much money the organization need to budget for application security" we will focus on risk mitigation criteria rather than other factors such as percentage of the overall Information Technology (IT) budget and year over year budget allocation for applications security as fraction of overall information security budget that include compliance and operational-governance costs. A risk based application security budgeting criteria documented in this guide consist on the following:

Estimate of the impact of the costs incurred in the event of an security incident
Quantitative risk calculation of the annual cost for losses due to a security incident
Optimization of the security costs in relation to cost of incidents and cost of security measures
The return of security investment in application security measures

We shall explain in the following sections of this guide each of these criteria and how can be used for quantifying how much money to spend in application security measures

Analyzing the Risks Of Data Breach Incidents

There are two important factors to determine the risk of a security incident: these are the negative impact caused by the security incident and the likelihood (probability) of the incident. To obtain an estimate of the impact of the costs incurred in the event of a security incident, the key factor is the ability to ascertain the costs incurred due to the security incident. Examples of negative impacts to an organization because of a security incident might include:

reputation loss such as, in the case of publicly traded company, a drop in stock price as consequence of announced security breach;
loss of revenue such as in the case of denial of service to a site that sells services or goods to clients and customers;
loss of data that is considered an asset for the company such as users' confidential data, Personal Identifiable Information (PII), authentication data, and trading secrets/intellectual property data;
inability to deliver a statutory service to citizens;
adverse impact on individuals whose data has been exposed.

Monetizing the Economical Impacts of Data Breach Incidents

In the case of a security incident that caused a loss of sensitive customer or employee data such as personal identifiable information, debit and credit card data, the costs incurred by the organization that suffered the loss include several operational costs also referred as failure costs. In the case of a financial services company, these are the costs for changing account numbers, remission costs for issuance of new credit and debit cards, liability costs because of fraud committed by the fraudster using the stolen data such as for illicit payment transactions and withdrawal of money from ATMs. Often times, the determination of such “failure” costs is not directly quantifiable by an organization, such as when this monetary loss is not directly caused by a security incident, hence ought to be estimated as a possible impact. In this case, CISOs can use statistical data to determine the possible liability costs to the company in case of data loss incident. By using reported statistical data from data loss incidents, it is possible to estimate the costs incurred by companies to repair the damage caused by security incident that resulted in losses of sensitive data or identity loss. Appendix 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: $200 to $2,000 per record

We will use this range for the remaining discussion, but each CISO needs to come up with some valuation of their own that can then be used to calculate the impact of a data loss.

Estimating the Likelihood of Data Breach Incidents

One of the challenges of the calculation of the burden to the company because of a potential data loss is to get an accurate estimate of the amount of the loss x victim and of the probability or likelihood of such loss occurring. Statistical data about reported data loss incidents to breach notification letters sent to various jurisdictions in the United States collected by the Open Security Foundation's (OSF) DataLossDB show that the percentage of 2010 data loss incidents breaching a web interface is 9% and the percentage that reported as being an hack is 12%, fraud 10% and virus 2%. The highest reported incident by breach type is stolen laptop with 13% of all reported incidents.

The data from OSF DataLossDB related to web as type of breach differ from the statistics of the Verizon’s 2011 data breach investigations report where hacking (e.g. brute force, credential guessing) and malware (e.g. backdoors, keyloggers/form grabbers, spyware) represent the majority of threats for security breaches (50% and 49% respectively) and attacks against applications represent 22% of all attack vectors and 38% as percent of records being breached.

These differences might be explained by the fact that the Verizon study is based upon a subset of data from the U.S Secret Service and does not includes for example cases related to theft and fraud that are instead counted on the overall OSF DataLoss DB statistical data. Furthermore, according to the Verizon report;" the scope of the survey was narrowed to only those involving confirmed organizational data breaches". In the case of OSF, survey data include data breaches covered by U.S State data breach notification law such as when resulting in disclosure of customer's Personal Identifiable Information (PII) and reported by organizations with notification letters sent to various jurisdictions in the United States.

Quantification of the Business Impact of Data Breach Incidents

In the cases when the impact of an occurred data breach due to a security incident is not being recorded and notified to the public in compliance with the data breach notification laws enforced by different countries and jurisdictions, it is necessary to estimate it based upon risk estimate calculations. Besides the calculation of liability costs based upon the value of data (refer to Appendix 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 an application would loose and therefore should spend on application security measures to mitigate the risk of a data loss due to the exploitation of an application vulnerability. The accuracy of this risk estimate depends on how reliable and pertinent the data breach incident is to application security. It is therefore important to choose the data carefully as this is being reported as being caused by an exploit of application vulnerabilities such as SQL injection (refer to Sony and TJX Max data breaches as good examples)

The SLE can be calculated with the following formula:

     SLE = AV x EF

Where, AV is the Asset Value (AV) and EF is the Exposure Factor (EF). The EF represents the percentage of the asset loss because of the realization of a threat or an incident. In the case of the 2003 US Federal Trade Commission (FTC) incident data this represents the amount of the population that suffered identity fraud and is 4.6%

Assuming the AV of 1 million accounts of $ 655,000,000 ( $655 per account based upon 2003 FTC data) and exposure factor of 4.6% the estimated SLE of the data breach incident is $ 30,130,000. Assuming a frequency of 1 attack every 5 years such as in the case of TJX Inc data breach incident (discovered in mid-December 2006 and due to SQL injection exploits) the ARO is 20% hence the estimated annual loss or Annual Loss Expectancy (ALE) can be calculated using the formula:

     ALE = ARO x SLO

The calculated Annual Loss Expectancy (ALE) for data loss incident is therefore $ 6,026,000/year over 10 years.

Considering Costs and Benefits of Application Security Measures Before Making Investments

Now the question is if, using quantitative risk analysis leads to an estimate to the optimal investment for application security measures. The honest answer is, not necessarily. The correct answer is to use cost vs. benefit analysis to determine the optimal value. By comparing the costs of security incidents against the cost of security measures it is possible to determine when this maximizes the benefit, that is, the overall security of the application. In case of software security costs for example, the cost due to software security failures including security incidents decrease as the company spends more money in security measures as shown in (FIG 1). The optimal investment in the security measures is the one that maximizes the security of the application and minimizes both the cost of security measures and of the cost incurred because of security incidents. According to an analytical study of costs vs. benefits of security, the optimal investment is when the cost of security measures is approximately 37% of the estimated losses. For our example, assuming the total estimated losses of $ 6,026,000/year due to data loss incidents, the optimal expense for security measures, using this empirical value from the study, is $ 2,229,620/year.

Figure 1: Cost of Investment in software security measures against failure costs due to incidents that exploit software vulnerabilities. At the point (A) to the costs due to software security failures exceed of several order of magnitude the expenditure in countermeasures and the assurance on the security of the software is very low, on the contrary in (B) the costs of security measures outweigh the costs due to the software failures, the software can be considered very secure but too much money is spent for software security assurance. In point (C) the cost of losses is nearly two times larger costs of security measures while in point (D) the costs due to incidents is equal to the cost of the security measures. The optimal value for spending of security measures is the one that minimizes both the cost of incidents and security measures and maximizes the benefit or the security of the software.

Analyzing Security Measures as Investments

Return of Security Investments (ROSI) in Application Security

Finally, it is important to determine the most efficient way to spend the application security budget from a perspective of this being an investment. If the CISO considers application security spending as an investment rather than an expense, for example, the budget can be justifiable as additional savings the company gets because of the investment in security. The factor to calculate the savings in terms of investment in security is the Return on Security Investment (ROSI). The ROSI can also help to determine if the investment in countermeasures to thwart hacking and malware attacks is justifiable: if the ROSI is not positive, the investment is not justifiable while if it is null, it does not yield any savings or investment returns. There are several empirical formulas to calculate ROSI; one is to factor of the savings for the data losses avoided over the total cost of the security control. Assuming the Total Cost of Ownership (TCO) for the cost of control is $ 2,229,620 (previously calculated as optimal value of expense in controls x year) that include development costs and acquisition of the new technologies, processes, tools as well as operating and maintenance costs it is possible to calculate the savings. ROSI can be calculated using the following empirical formula:

      ROSI= [(ALE x % of effective risk mitigation) - cost of controls]/cost of controls

With this ROSI formula, assuming that the ALE is $ 6,026,000 and that the effectiveness of the risk control mitigation is 75% (assume for example, in the case of a SQL injection, risk mitigation as defense in depth such as different layers of controls that include use of prepared statements/stored procedures in source code as well as filtering of malicious characters at the web server and application server), the cost of countermeasure is $ 2,229,620, the ROSI to the company is 102% per year. Since there is return of investment, the spending in security control measures is worth it and will make the company save money. The best use of ROSI is to compare alternative investments in security measures such as to decide whether to invest in the development of a new countermeasure or extending the capabilities of an existing one.

As a comparative measurement for example, ROSI can be used by CISOs to determine which software security is more efficient or yields the organization the higher savings and returns on the investment. According to research of Soo Hoo (IBM) on ROSI of the various activities of software security in software development cycle, the maximum return of investment (21%) or a savings of $ 210,000 on an investment of a $ 1 Million Secure Software Development Lifecycle (S-SDLC) program for example is obtained when the investment is in activities that aim to identify and remedy security defects during the design phase such as threat modeling. The return of investment is 15% when the defects are identified and remedied during implementation (code) such as with source code analysis and of only 12% when these are identified and remedied during the testing-validation phase such as with ethical hacking/pen tests. The best investment in application security is therefore in activities that aim to identify defects as early as during the design phase of the SDLC, in essence, the more CISOs think about investing in software security engineering programs especially threat modeling/architectural risk analysis, the more they'll save on the costs of implementing and fixing security issues later in the SDLC such as during the validation phase or when the application is already in production in response to security incidents.

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.

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part II: Criteria for Managing Application Security Risks

Introduction

Once an 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 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 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 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. citizen, client, employee or 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.

Estimating the Risks of Vulnerability Exploits

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 applications. To estimate the probability that an attack against a 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 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 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 application vulnerabilities to cause a business impact is provided herein:

According to the OWASP Top Ten Risks to Web Applications, 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 application vulnerabilities to determine the risks

Estimating the Probability of Vulnerability Exploits

To estimate the probability of a specific web application vulnerability exploit, we can refer to data reports from the Web Hacking Incident Database (WHID). 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, 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 Vulnerability Exploits

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 user data.

It is important to notice that injection vulnerabilities are considered by OWASP (2010 A1-Injection) the most critical 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 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.

Mitigating the Risks of Attacks Targeting Applications

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.

In regards of the threat agent, it is important to understand “IF” and “HOW” the organization’s 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 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.

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.

Threat Agents their Motivations and Historical Impacts

Script Kiddies, Worms and Viruses's 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 impact of the 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 threat alert for today’s script kiddies threat agents using readily available tools that look for common exploits of known vulnerabilities to expose them to public. CISOs need to make sure that systems and applications are not vulnerable to these easy exploits since this might severely impact the organization operations when critical hosts are infected and disabled as well as damage the company reputation when news of these exploits are posted on social media (e.g twitter).

Fraudsters & Cyber-Criminals

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 institutions 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 identifiable information, might likely become the target of hacktivists for political reasons and need to worry about reputation 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, Hacktivists target websites with DDoS hosted at financial and government 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) Agents

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.

Attacks and Vulnerabilities

In this section of the guide we will describe how to proactively manage the risks posed by specific type of attacks such as threat agents whose motives and attack goals have been previously analysed. Typically risk mitigation consists on fixing vulnerabilities as well as applying new countermeasures. The choice of which vulnerabilities are critical to mitigate starts first with the understanding of the threat scenarios and the threat agents motives especially of hacking and malware and how these threat agents might adversely target 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.

Script Kiddies Attacks

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 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 reputation 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.

Fraudsters and Cyber-Criminals Attacks

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 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 applications 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 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 fraudster than to break into an 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 that can 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 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. As one of the security principles is "you are as much as secure as your weakest point" identifying where these weakest points are is critical in the assessment of the security of any system exposed to attacks including applications. The identification of the data entry points for a given application, internal and external is a critical to determine the attack surface of the application and is usually identified as 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 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.

Business Logic Attacks

A class of vulnerabilities that are often exploited by fraudsters and not tested in applications are design flaws and logical vulnerabilites. 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 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 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 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 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.

Phishing Attacks

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.

"Man in The Browser" and "Man In The Middle" Attacks

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 user’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 identity 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 citizen/client/customer/employee 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 user 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.

Denial of Service Attacks

Denial of Service (DoS) attacks might severely impact the availability of website to users. Depending on the type of services that the website provide to customers, a loss of service might result in a considerable revenue loss for the organization. CISOs should consider the mitigation of the risk of denial of service attacks as top priority especially for web applications that generate considerable revenue and whose availability is considered critical by the organization.

DoS attacks can be facilitated by web application vulnerabilities, OWASP included DoS as one of OWASP Top Ten vulnerabilities in 2004 (OWASP A9:DoS) but this was dropped in 2007 due to the MITRE ranking in 2006. Nevertheless, even if no longer part of the OWASP top ten in 2010, depending on the exposure and the value of the assets impacted, denial of service vulnerabilities might represent an high risk for the organization and prioritized for mitigation. At the application level, a denial of service might be the result of exploits of OWASP A1 injection vulnerabilities, specifically vulnerabilities allowing injections of SQL, XPATH and LDAP commands can cause the web application to crash. At the user level, denial of service attacks can target the usability of the application by a registered user, for example attackers can use scripts to lock user accounts upon guessing valid userIDs and force user accounts to lock upon several un-successful attempts. In absence of temporary account locks (e.g. the user account will unlock automatically in 24 hours), this attack cause users to not be able to log on. A side effect of this is customers calling customer support seeking to unlock their user accounts, possibly flooding the call centers with account unlock calls. At source code level, DoS attacks might occur because of attack vectors exploiting insecure code issues causing exhaustion of computer resources. These are insecure coding issues such as failing to release memory from allocated resources (e.g. object's memory) when exiting programs and causing the application to crash as result. Examples include exploiting of insecure code with NULL pointer deference and improper termination, exploiting uncaught exceptions and exploiting weaknesses when processing XML files causing the XML parsing process to exhaust memory with malicious recursive XML files. In the cases when the application source code is written in programming languages that allow programmers to manage memory such as C, C++, coding errors in the handling of memory allocations and use of unsafe functions might expose the source code and the application to possible exploit of buffer overflow vulnerabilities to cause the application to crash or to take control of. Buffer overflow vulnerabilities can also be exploited at server level because of attacks seeking to exploit web and application servers that are unpatched and vulnerable to buffer overflows. CISOs need to make sure that application and source code vulnerabilities that could be exploited for denial of service are in the scope for security testing since these are typically covered by static and dynamic application security testing tools.

Distributed Denial of Service Attacks

At the transport-network layer, denial of service typically seeks to exploit network layer protocol type vulnerabilities such as by spoofing packets for sake to flood network traffic. A type of denial of service attack called Distributed Denial of Service (DDoS) typically seeks to flood the target web server with an unusually high level of data traffic sent from a coordinated and controlled network of bots. Because of the unusual network traffic that the web server is asked to handle, it might not be able to serve all the requests over the network and deny and request of service to the users of the application. Well known DDoS attacks originating from bots include “Ping of Death” bots that create huge electronic packets and send them to victims, “Mailbomb” bots that send a massive amount of e-mails, crashing e-mail server, Smurf Attack” bots that send Internet Control Message Protocol (ICMP) messages to reflectors to amplificate the attack, and “Teardrop” bots that send malformed pieces of packets that crash a system trying to recombine them.

Today's script kiddies, hacktivists, cyber-criminals and country sponsored attackers use open source DDoS attack tools and bots against possible targets. The typical, likely targets for DDoS attacks are public and private organizations with high visibility. General objectives of these attacks are to cause disruptions, get noticed and damage the company reputation. Specific motives for conducting DDoS attacks varies depending on the type of threat agents and their motives. Script kiddies might use DDoS attacks for opportunistic motives such as to exploit denial of service vulnerabilities and gain notoriety, hacktivist might use DDoS attacks for political reasons and to get attention from public media. Fraudsters and cyber-criminals might use DDoS attacks to derail attention from other attacks such as in the case of an account take over attack seeking to defraud online bank customers. State sponsored cyber-attackers might use DDoS attacks for economic and military reasons such as in the case of disrupting the operation of another country’s government operated website.

The impact of DDoS attacks in terms of reputational and revenue loss to private and public organizations varies greatly depending on the type of website targeted by the attack, the duration of the attack and the number of individuals and customers affected. The business impact of DDoS attacks can be estimated as function of the loss of revenue caused by the loss of services to customers and individuals when the website is taken down. According to the "2011 Second Annual Cost of Cyber Crime Study Benchmark Study By Ponemon Institute" that involved 50 organizations and U.S. companies, the impact of DDoS is estimated to be an average annual cost of $187,506. This cost is weighted by the frequency of the attack incidents for all benchmarked companies. Another survey from CA Technologies including 200 companies in North America as well as Europe, estimated the cost of downtime because of a denial of service of about $150,000 annually. These cost estimates, are just order of magnitudes since business impacts vary greatly depending on the type of online services affected and the volume of the online business affected by the DDoS attacks. For a very large e-business company like Amazon for example, whose business generated $ 48 billion in revenues for the year 2011, assuming that most of Amazon's revenues are generated online, a denial of service of just one hour DDoS attack might cost several millions of dollars in revenue loss. CISOs whose companies generate a significant part of their revenues through online websites such as in the case of e-commerce and financial websites, need to consider the threat of denial of service from DDoS attacks as top priority for risk mitigation and consider investing in security measures to mitigate the risk of such attacks.

Today DDoS attacks are very widespread. The reason why such attacks are so widespread is due to the availability of DDoS tools and of botnets to rent to conduct DDoS attacks at a relatively low cost for the attacker. According to “Modeling the Economic Incentives of DDoS Attacks: Femtocell Case Study, Vicente Segura and Javier Lahuer ta, Department of Network and Services Security of Telefonica” for example, the cost of renting a botnet for DDoS attacks is about $ 100 per day for 1 Gbps bandwidth.

CISOs also need to be aware of the escalating DDoS threat since the severity and sophistication of DDoS attacks is also increasing. According to “2011 Arbor Networks, Sixth Annual Worldwide Infrastructure Security Report”, considering with DDoS of six years ago, the power of DDoS attacks increased ten times reaching bandwidths of 100 Gbps. This escalation of DDoS power cannot be explained by the sophistication of the DDoS tools alone but with new DDoS attacks techniques seeking to amplify the bandwidth of the attacks. These new DDoS attack techniques consists on Distributed Reflector Denial of Service Attacks (DRDoS). DRDoS attacks spoof the victim’s source IP address with DNS queries sent towards open DNS resolvers, since open DNS resolvers that receive the DNS queries they respond to the victim's system with large packets, they can be used to amplify the bandwidth further such as when thousands of bots are querying thousands of DNS servers.

Traditional network layer countermeasures for protecting from DDoS attacks include setting routers to examine and drop packets, filter IP addresses, configure rate limits and apply ingress and egress network filtering. Unfortunately today, most of these countermeasures are not enough to protect from DDoS and DDRoS attacks of the intensity of 100 Gbps bandwidth. In order to protect from high power DDoS and DRDoS attacks, CISOs whose organization high availability websites are under the threat of high bandwidth DDoS and DDRoS attacks, need to consider investments in network segmentation, hosting part of the website static content on CDN (Content Delivery Networks) and use third party cloud-based DDoS protections services with service level agreements to increase traffic bandwidth in case is is consumed during a DDoS attack. Refer to (Attacks FS-ISAC_Threat_Viewpoint_DDoS_June_2012.pdf)

Mitigating the Inherent Risks of New Application 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 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 applications and the data. The increased risk to applications due to the adoption of new technologies includes the increased exposure/attack surface such as in the case extending 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.

Managing the Risk of Mobile Applications

Mobile application security is a particular concern for most organizations today: this is mostly due to the exponential growth in the adoption of mobile smartphones and tablets by users both for personal and business use. From the application security perspective, access of business applications from mobile devices increases the opportunity for threat agents to attack the mobile device and the applications and the data that can be stored in the mobile devices. Mobile phones that are compromised with malware for example, expose both the client application installed on the device as well as the server application that can be assessed through the mobile device. Different mobile communication channels can be also attacked including web channels to access Wi-Fi networks, MMS, SMS messaging and GSM 2G, 3G, 4G wireless networks. Businesses whose applications can be accessed through mobile devices should consider the exposure to attacks increased by the adoption of mobile applications. One important security measure is to require a specific vulnerability assessment for testing the security of mobile applications and of the protection of sensitive data that is stored on the mobile device. The requirement to encrypt any confidential and authentication data that is stored on the device for example might be required by compliance with internal mobile security standards and policies. Exposure of web services that can be accessed through a mobile application need also to be tested for vulnerabilities. Often the organization might decide to avoid the risk of mobile applications accessing financial risk transactions such as money transfers and payment when authentication on the device is considered not as strong as the one available for the internet PC based applications. In some cases, device security controls might be considered not secure enough such as when using device based encryption (e.g. iOS keychain) because this can be brute forced when the user is no longer in possession of the mobile device. These are important risk considerations and can be enforced by requiring the development organization to follow security standards for designing mobile applications.

Besides device compromise because of a device being lost or stolen another risk to consider is the compromise of the mobile device by malware designed to install keyloggers to collect user's credentials and to redirect this stolen credentials to the fraudster's server. Today mobile applications represent an opportunity to attack applications installed on the mobile devices through different communication channels such as emails, social media, video-audio streaming, instant messaging and web. Examples of opportunities for an attacker to compromise mobile devices with malware for example include social engineering mobile users to click on malicious links on emails and messages that carry malware payloads to install spyware and remote access tools. The sophistication of the mobile malware today is a such that some mobile malware is specifically designed to attack the time tokens sent to the user's phone to authenticate to online banking web sites. this type of mobile banking malware has the capability to perform (MiTMO) Man in the Mobile attacks and redirect the one time authentication tokens to the fraudster's mobile phone so can be used to authenticate to the online banking site along with username and passwords. Another avenue of attacks to mobile applications is to upload malicious applications on the mobile application provisioning stores (e.g. Market place and Apple Store) and lure mobile users to download rogue applications from these stores. Since applications for Android and iOS together compose nearly 90 % of the worldwide smartphone type of applications, attacking application provisioning stores represent the best opportunity for an attacker to spread mobile malware to a large numbers of mobile application users. Typically the security checks that are performed by these mobile application stores especially in the case of the Apple Store mitigate these risks but downloading mobile type of applications from sites whose origin cannot always validate by the mobile users (possible for Android mobile type of applications) should be considered a risk.

Nevertheless, a lot of security can be gained by just having mobile users following basic security measures. In some cases the lack of enforcement of basic simple default security measures such as use of PINs to prevent unauthorized access and allowing the installation of applications that require to “jail break” the phone represent an increased risk both for the data and the mobile applications residing on these devices. A good preventive measure is to keep informing users of the threats targeting mobile devices and recommend them to follow basic security measures. Good resource of security awareness for mobile phones and protection from threats targeting mobile devices is US CERT Cyber Threats to Mobile Phones.

For CISOs whose responsibility is to manage the security of mobile applications it is important to consider the adoption of specific security processes and standards for the security of mobile applications. These measures might include the adoption and documentation of mobile technology security standards, the adoption of vulnerability assessments to specifically security test for mobile application type of vulnerabilities and standards for secure provisioning of these mobile applications and application data on the personal owned consumer devices. From the perspective of adoption of specific security testing process for vulnerabilities in mobile type of applications, the OWASP mobile security project is a numbers of resources such as documentation on mobile security risks, free vulnerability assessment tools, cheat-sheets and guidelines for the secure design of mobile applications.

An important aspect that mobile security and of particular CISO concern is to secure organization-issued mobile devices as well as user personal devices brought into the organization (e.g., Bring Your Own Device, BYOD). As the practice to bring personal devices into the enterprise environment becomes prevalent, CISOs will need to access the potential risks and determine how much access to grant to potentially unsafe employee-owned devices. Today some organizations might allow employee owned devices to directly access the organization's network only through secure connectivity such as VPN, secure virtualization, terminal servers or remote access utilities like virtual network computing (VNC). In all these cases, it is important that CISOs have rolled out specific policies for remote access from employee owned devices that are strictly enforced through a secured and centrally managed controlled access technologies and services. A good resource that can help CISOs to set guidelines for BYOD and for centrally manage and secure mobile devices, such as smart phones and tablets is the NIST SP 800-124, Guidelines for Managing and Securing Mobile Devices in the Enterprise (Draft) and Guidelines on Cell Phone and PDA Security.

Managing the Risks of Web 2.0 Technologies

New technologies introduce new risks and new measures need to be put in place by the organization to mitigate these risks. One possible way to prepare for the impact of new technologies it to plan in advance the adoption of security measures and processes to mitigate the risks by knowing when such technologies will become “mainstream” that is will be widely adopted by the business. According to some analysts like Gartner, the adoption of new technologies by the market follow a cycle also referred as “hype” that comprises five phases that are (1) “Technology Trigger”, (2) "Peak of Inflated Expectations", (3) "Trough of Disillusionment", (4) "Slope of Enlightenment" and (5)”Plateau of Productivity". In the hype cycle that Gartner published in 2009 covering emerging technologies, Web 2.0 was shown as two or less than two years for mainstream adoption. This prediction is validated today (2012) by considering that several applications today have adopted and integrated Web 2.0 technologies in their web applications. Since typically senior management and executives’ pay specific attention on the market and security technology research of analysts (e.g. Gartner and Forrester) it is important for CISO to look at this research as well from the perspective of deciding of whether to adopt a certain type of technology as well as for preparing for the security impacts of such technology. First of all it is important to understand the terminology used. Web 2.0 technologies can be defined as “Web applications that facilitate interactive information sharing and collaboration, interoperability, and user-centered design on the World Wide Web”. The main characteristics of Web 2.0 technologies are:

Encourage user’s participation and collaboration through a virtual community of social networks/sites. Users can and add and update their own content, examples include Twitter and social networks such as Facebook, Myspace, LinkedIn, YouTube
Transcend from the technology/frameworks used. Examples include AJAX, Adobe AIR, Flash, Flex, Dojo, Google Gears and others
Combine and aggregate data and functionality from different applications and systems, example include “mashups” as aggregators of client functionality provided by different in-house developed and/or third party services (e.g. web services, SaaS)

One important aspect that CISOs need to be aware of in regarding of Web 2.0 technologies is how these technologies affect the threat landscape. First of all, Web 1.0 threats are amplified by the intrinsic nature of Web 2.0 due to the expanded volume of user’s interaction: consider for example the hundredths of millions of users of social networks and the increased attack surface to the web application offering links to corporate Facebook and twitter account now provides to a threat agent for attacking the user with phishing, malware as well as for exploit of traditional Web 1.0 vulnerabilities such as injection flaws, XSS and CSRF. Social network specifically facilitate customer’s sharing of confidential and private information since boundaries between private and personal information are often crossed by voluntarily sharing of such information with the company even if is not being explicitly requested.

Another element of increased risks is represented by increased complexity of the functionality due to the integration of different Web 2.0 technologies and services both as front-end-client as well as back-end-server. Business rich client interfaces such as widgets for example increase the likelihood of business logic attacks while exposure of new web services increases the exposure of attacks to back end servers.

Web 2.0 Vulnerabilities Exploited by Attackers

Because of the increased risks to web applications due the introduction of Web 2.0 technologies, it is important that CISOs make sure that web applications are specifically designed, implemented and tested to mitigate the risks. From vulnerability and threat analysis perspective, Web 2.0 application vulnerabilities can be analyzed using the OWASP Top 10 and the WASC Top 50 threats. OWASP Top 10 vulnerabilities that Web 2.0 applications need to be tested for include A1-Injection, A2-XSS, A3-Broken Authentication and Session Management and A5-CSRF .Examples of Web 2.0 injection vulnerabilities include XML injections such as when an attacker will provide user-supplied input that is inserted into XML without sufficient validation affecting the structure of the XML record and the tags (and not just content). An particular type of XML injection vulnerability is XPATH injection. This is an attack aimed to alter an XML query to achieve the attacker’s goals such as to perform un-authorized queries for retrieve confidential data. Another Web 2.0 specific injection vulnerabilities include JSON injections to run un-authorized code, potentially malicious by injecting malicious JavaScript code into the JSON (JavaScript Object Notation structure) on the client.

Among Web 2.0 injection vulnerabilities, RSS feed injections can be used to consume un-trusted sources from RSS feeds such as malicious links for download malware on the victim’s computer. Web 2.0 exploits of XSS are facilitated by the fact that a lot of Web 2.0 based sites that allows adding HTML to normal text content such as when posting blogs and feedbacks to the company products-services. When HTML data is unfiltered from malicious input might allow the attacker to enter unsafe HTML tags that can be abused for XSS to attack victims reading the blog postings or comments to select malicious links. An additional attack vector for Web 2.0 XSS is also represented by XSS DOM since WEB 2.0 APIs use DOM in Rich Internet Applications (RIA) written in FLASH, Silverlight such as Mashups and Widgets. The use of AJAX (Asynchronous JavaScript) on the client also increases the possible entry points for attacking several HTTP requests to the web site with XSS attacks. An example of Web 2.0 attack exploiting injection vulnerabilities is included in the Web Hacking Incident Database WHID 2008-32: Yahoo HotJobs XSS that allow the threat agents to exploiting an XSS vulnerability on Yahoo HotJobs to steal session cookies of the victims and gain control of every service accessible to the victim within Yahoo, including Yahoo! Mail.

Example of exploits of Web 2.0 OWASP-A3: Broken Authentication and Session Management vulnerabilities include use of weak passwords, passwords stored in AJAX Widgets/Mashup that are sent and stored in clear outside the control of the host, passwords that are stored on the client as “autologon feature” or in the cloud to SSO from the desktop and password recovery controls that are not protected from brute force attacks since do not lock the accounts when several failed tries to guess the passwords are attempted. An example of this vulnerability type exploit is also part of the WHID catalogue as 2008-47: The Federal Suppliers Guide validates login credential in JavaScript.

A type of vulnerability that is facilitated by Web 2.0 is CSRF such as when clients use AJAX to make XHR calls that enable invisible queries of a web application and the user cannot visually validate for forgery. CSRF is also facilitated by insufficient browser enforcement of the Single Origin Policy for desktop widgets and weak session management when session expiration times are set to be quite high, increasing the risk of session base attacks such as CSRF. Persistent session cookies that are shared by widgets also increase the opportunities for CSRF attacks. A known Web 2.0 security incident that is in the WHID catalogue as 2009-4:”Twitter Personal info CSRF” allowed an attacker to exploit a CSRF bug in Twitter to get twitter profiles of the visitors.

A type of vulnerability that is also exploited and used against Web 2.0 applications but also more in general against web sites is due to the lack of anti-automation defenses. This vulnerability is not tracked by OWASP Top 10 but by the Web Application Secure Consortium (WASC) as Top 21 within the TOP 50 issues tracked by WASC. Automation attacks against Web 2.0 applications that allow to post information such as feedback forms, blogs and wiki pages for example seek to spam these pages with commercial information and potentially by attackers to post links to malicious sites to spread malware via drive by download or by phishing. An example of such attack against Facebook, WHID 2007-65:” Botnet to manipulate Facebook”

Security Measures To Mitigate Risks

Critical to the vulnerability analysis of Web 2.0 applications is the determination of the root causes of the vulnerabilities. Only through the identification of the vulnerabilities root causes vulnerabilities can be eradicated. For example if these vulnerabilities originate from lack of security requirements for Web 2.0 that software developers need to follow, these need to be documented. In case the issues are caused by errors in design, these needs to be prevented by making sure the design of web 2.0 applications is reviewed by a security architect that has subject matter expertize in Web 2.0 technology. For Web 2.0 vulnerabilities that are introduced by software developers as coding errors or because of integration with software and third party libraries that are exposed to Web 2.0 vulnerabilities it is important that software developers are trained to defensive coding Web 2.0 applications and that security testers know how to identity and test Web 2.0 vulnerabilities.

A prescriptive set of Web 2.0 security measures that CISOs can undertake to mitigate the risks include:

Documentation of security standards for Web 2.0 technologies such as security requirements for design, coding and testing specific Web 2.0 technologies such as AJAX, FLASH and enforcement of them at the beginning of the SDLC
Institute a security activity during design to review threats against Web 2.0 applications and identify countermeasures such as application threat modeling. Part of this activity also includes the security review of the application architecture and the security controls that are exploited by attacks against Web 2.0 applications such as input validation, authentication, session management and anti-automation controls such as CAPTCHA.
Require Web 2.0 based applications to undergo a secure code review to assure source code adherence to security coding standards and static source code analysis to identify Web 2.0 coding issues in both client source code used by Widgets, RIA, AJAX components as well as server side code that is used in web services and Service Oriented Architectures (SOA). Specific secure code requirements can be documented for AJAX, these can be socialized with architects and software developers and validated during design and source code reviews.
Require security tests to include specific test cases for testing Web 2.0 component vulnerabilities and for Web Services. Refer to OWASP test guide test cases for testing AJAX and Web Services as example.
Make sure Web 2.0 technical risks are managed such as the business risks that Web 2.0 design flaws and bugs might pose to the business. The OWASP risk methodology can be used to manage Web 2.0 security risks. An example of OWASP risk framework applied to Web 2.0 technologies is included in the figure herein.

Managing the Risk of Cloud Computing Services

The concept of cloud computing per se is not new. Several organizations for example used to outsourced their data centers to third party owned data centers a concept that in cloud computing is considered a deployment of Infrastructure As A Service (IaaS) cloud service. The term cloud computing encompasses outsourced infrastructure such as in the case of Infrastructure as a Service (IaaS), outsourced platforms such as in the case of Platform As A service (PaaS) and through outsourced software a term that is also referred to as Software As A Service (SaaS).

CISOs today face the challenge to assess and assert the security of cloud computing deployments within their network (e.g. on-premises or private cloud) or outside the organization (e.g. outside premise or public cloud). Information and application security is a primary concern for organizations that outsource either their infrastructure component and platforms or software and data to a third party vendor cloud provider. CISOs need to consider the potential risks and assess them prior to decide to outsource their services to third parties. CISOs should consider for example the potential risk of the company data that is hosted on a third party cloud computing provider can be compromised because of a security incident occurring at the cloud provider. CISOs should consider for example the risk that an organization might face when the data service that is provided to their customers is outsourced to a third party software and become unavailable because such cloud service provider has been targeted by a denial of service attack.

It is therefore important that CISOs consider the whole spectrum of information security risks before the organization decides to move either their services or their data to the cloud computing service providers. At high level these risks can be assessed by conducting a due diligence third party information security assessment on the cloud computing provider service vendor. These type of assessments seek to assert the security posture of the cloud provider against the company’s information security policies and standards as well as with audit of industry relevant IT security standards such as SAS 70, SOC, FISMA, PCI DSS, ISO, FIPS-140, ISO/IEC 27001-2005 etc. and others as these are relevant to the organization’s regulated security business operations such as HIPPA, FFIEC, MPAA etc. etc.

In the case of cloud computing assessment, security risks and compliance-audit are actually some of the domains that need to be assessed along with others such as cloud architecture, governance, legal and law enforcement, privacy, business continuity and disaster recovery, incident response, application security, encryption and key management, identity, entitlements and access management, virtualization and security as a service.

A comprehensive guidance on how to conduct oversight on all these a domains of cloud computing is the Cloud Security Alliance. CSA provides top level security guidance for critical areas in cloud computing. CSA also provides a set of tools that can be used by organization to assess security risks of cloud computing services in these domains including a cloud control matrix spreadsheet to assess SaaS, PaaS and IaaS controls for information security, legal, organizational-policies, risk management, resilience and security architecture, against standards such as COBIT 4.1, ISO 27001, NIST SP 800-53, PCI-DSS vs. 2.0 and others. The CSA Consensus Assessments Initiative Questionnaire v1.1 allows CISOs to assert the third party cloud computing service providers with respect to information security as well as compliance, data governance, facility security, human resource security, legal, operations management, risk management, release management, resilience and security architecture. In 2013 CSA also published a white paper with guidance on adopting controls in the cloud to mitigate the risk of the top threats to cloud computing. The top nine threats to cloud computing ranked by severity are: (1) data breaches, (2) data loss, (3) account hijacking, (4) insecure APIs, (5) denial of service, (6) malicious insiders, (7) abuse of cloud services, (8) insufficient due diligence and (9) shared technology issues.

For the sake of this guide, we strongly recommend CISOs to look at the CSA referred documentation guidance; questionnaires and threat analysis referred herein and use these to construct an ad-hoc cloud computing security assessment process that can be used by the organization’s information security team to conduct due diligence information security, risk and compliance-audit assessment on cloud computing providers. Such ad-hoc cloud computing security assessment might consider the organization information security policies, standards and regulations are the starting point to assert the security of cloud providers since these are the same that are applicable and more relevant to the organization requirements to protect confidentiality, integrity and availability of the data. An ad-hoc cloud computing security assessment should at minimum include a standard process that can be followed including a set if questionnaires that can be used to capture and assert the security, compliance and risk management posture of the cloud computing security provider prior to make a business decision to whether outsource services such as infrastructure, networks, platform and software-data to a third party cloud computing service provider.

The main goal of such assessment is to identify control gaps and potential areas of risk for the organization. Examples of application security risks that can be identified with these assessments might include the identification of the lack of end to end encryption of the data granting full control and assurance to the business of the confidentiality of the data either in transit or in storage to the third party cloud provider, the lack of segregation of data from other businesses in a virtualized cloud computing environment and the lack of audit and logging for specific security events and incidents. Examples of mitigating security controls for these risks might include the requirement of use of end to end encryption for confidential data in transit and storage at the cloud provider, the use of virtual firewall and secure hypervisor architecture for securing tenants in SaaS cloud virtualized environments and the adoption of specific audit and logging facilities that can be used to alert both the cloud provider and the organization outsourcing the service in the case of a security incident as few examples.

Once these control gaps have been identified it is important to assign the level of severity-risk and determine if compensating controls might be implemented prior to the deployment of the cloud computing solution. An important aspect for managing these risks is also to make sure a SLA (Service Level Agreement) captures these risks and provide binding contractual agreements with the cloud service provider and liability clauses and indemnities for the organization in case these agreements are breached.

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part III: Selection of Application Security Processes

Introduction

Mitigating the risk of attacks that seek to exploit of 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's Application Security Functions

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 responsibility 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 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 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 responsibility 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 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 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 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 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 and availability. 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.

Assess Risks before Procurement of Third Party Components

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

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 figure herein:

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" 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 applications for compliance with PCI-DSS and OWASP Top 10. At CMM Level 2, the organization has already adopted standard processes for security testing 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 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 OWASP Projects and Tools For Your Organization

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.

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 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.

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.

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

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part IV: Selection of Metrics For Managing Risks & Application Security Investments

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 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 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 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 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/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 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 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 application such as breaches of data as results of an exploit of a vulnerability. The correlation of the security incidents reported for a given 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 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 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 application, being for example a totally newly developed application versus a new release of an existing application. Since new applications were not security tested before, they represent higher risks than existing 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 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 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.

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.

Metrics for Software Security Investments

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).

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.

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

References

Verizon 2011 Data Breach Investigation Report: http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigations-report-2011_en_xg.pdf

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

Supplement to Authentication in an Internet Banking Environment: http://www.fdic.gov/news/news/press/2011/pr11111a.pdf

PCI-DSS: https://www.pcisecuritystandards.org/security_standards/index.php

OWASP Top Ten: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Gartner teleconference on application security, Joseph Feiman, VP and Gartner Fellow http://www.gartner.com/it/content/760400/760421/ks_sd_oct.pdf

Identity Theft Survey Report, Federal Trade Commission,September, 2003: http://www.ftc.gov/os/2003/09/synovatereport.pdf

Dan E Geer Economics and Strategies of Data Security: http://www.verdasys.com/thoughtleadership/

Data Loss Database: http://datalossdb.org/

WHID, Web Hacking Incident Database: http://projects.webappsec.org/w/page/13246995/Web-Hacking-Incident-Database

Imperva's Web Application Attack Report: http://www.imperva.com/docs/HII_Web_Application_Attack_Report_Ed1.pdf

Albert Gonzalez data breach indictment: http://www.wired.com/images_blogs/threatlevel/2009/08/gonzalez.pdf

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

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

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.

Total Cost of Ownership: http://en.wikipedia.org/wiki/Total_cost_of_ownership

Wes SonnenReich, Return of Security Investment, Practical Quantitative Model: http://www.infosecwriters.com/text_resources/pdf/ROSI-Practical_Model.pdf

Tangible ROI through Secure Software Engineering: http://www.mudynamics.com/assets/files/Tangible%20ROI%20Secure%20SW%20Engineering.pdf

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

Share prices and data breaches: http://www.securityninja.co.uk/data-loss/share-prices-and-data-breaches/

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

Sony data breach could be most expensive ever: http://www.csmonitor.com/Business/2011/0503/Sony-data-breach-could-be-most-expensive-ever

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

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/

Dmitri Alperovitch, Vice President, Threat Research, McAfee, Revealed: Operation Shady RAT: http://www.mcafee.com/us/resources/white-papers/wp-operation-shady-rat.pdf

OWASP Security Spending Benchmarks Project Report: https://www.owasp.org/images/b/b2/OWASP_SSB_Project_Report_March_2009.pdf

The Security Threat/Budget Paradox: http://www.verizonbusiness.com/Thinkforward/blog/?postid=164

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

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

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

About OWASP

Short piece about OWASP and including links to Projects, ASVS, SAMM, Commercial Code of Conduct, Citations, ???

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Appendix

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. 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 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 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, 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 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. 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 reputation damage).

Another possible way 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, 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, 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.

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Appendix I-B: Calculation Sheets

Some grids for CISOs to enter their own numbers and calculations

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

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/

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Appendix I-D: Quick CISO Reference to OWASP's Guide & OWASP Projects

Included herein is a quick reference to the the guide. The quick reference maps typical CISO's functions and information security domains to different sections of the guide and relevant OWASP projects.

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.

@@ Line 785: / Line 785: @@
 <br>
+----
+==PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK==
+----
 == Appendix I-B: Calculation Sheets ==
 ''Some grids for CISOs to enter their own numbers and calculations''
+----
+==PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK==
+----
 ==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/
+----
+==PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK==
+----
 ==Appendix I-D: Quick CISO Reference to OWASP's Guide & OWASP Projects ==

Difference between revisions of "Application Security Guide For CISOs"

Revision as of 03:12, 18 September 2013

Introduction

Goal & Objectives

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Foreword

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part I: Reasons for Investing in Application Security

Introduction

Information Security Standards, Policies and Compliance

Identifying Standards and Policies in Scope for Compliance

Capturing Application Security Requirements

PCI-DSS

FFIEC

GLBA

Privacy Laws

Risk Management

Proactive vs. Reactive Risk Management

Asset Centric Risk Management

Technical vs. Business Risk Management

Risk Management Strategies

Threat Analysis and Awareness of Emerging Threats

Addressing the Business Concerns after a Security Incident

Budgeting of Application Security Measures for Mitigating Risks of Data Breach Incidents

Analyzing the Risks Of Data Breach Incidents

Monetizing the Economical Impacts of Data Breach Incidents

Estimating the Likelihood of Data Breach Incidents

Quantification of the Business Impact of Data Breach Incidents

Considering Costs and Benefits of Application Security Measures Before Making Investments

Analyzing Security Measures as Investments

Return of Security Investments (ROSI) in Application Security

Conclusion

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part II: Criteria for Managing Application Security Risks

Introduction

Estimating the Risks of Vulnerability Exploits

Estimating the Probability of Vulnerability Exploits

Estimating the Business Impact of Vulnerability Exploits

Mitigating the Risks of Attacks Targeting Applications

Threat Agents their Motivations and Historical Impacts

Script Kiddies, Worms and Viruses's Authors

Fraudsters & Cyber-Criminals

Hacktivists

Cyber-Spies

Advanced Persistent Threats (APTs) Agents

Attacks and Vulnerabilities

Script Kiddies Attacks

Fraudsters and Cyber-Criminals Attacks

Business Logic Attacks

Phishing Attacks

"Man in The Browser" and "Man In The Middle" Attacks

Denial of Service Attacks

Distributed Denial of Service Attacks

Mitigating the Inherent Risks of New Application Technologies

Managing the Risk of Mobile Applications

Managing the Risks of Web 2.0 Technologies

Web 2.0 Vulnerabilities Exploited by Attackers

Security Measures To Mitigate Risks

Managing the Risk of Cloud Computing Services

PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK PAGE BREAK

Part III: Selection of Application Security Processes

Introduction

Addressing CISO's Application Security Functions

Application Security Governance, Risk and Compliance

The Importance of Security Metrics

Targeting Software Security Activities and S-SDLC Processes

Recognizing Importance and Criticality of Secure Software

Integrating Risk Management as part of The SDLC

Assess Risks before Procurement of Third Party Components

Security in the SDLC (S-SDLC) Methodologies

Software Assurance Maturity Models

How to Choose the Right OWASP Projects and Tools For Your Organization

Project's Maturity

Project's Categories

People, Processes and Technology

People

Processes

Technology

Benchmarking & Maturity