This article establishes the role that risk management and risk assessment play in determining what security practices to implement and in what order. Risk management is critical in sustaining an acceptable level of security, given that it is not possible to be 100% secure.
Why Are Risk-Centered Practices Necessary?
Given that it is impractical (and probably impossible) to ensure that an operational system is 100% secure at any point in time, security practitioners have found it useful to adopt risk management and assessment strategies to determine which security practices to deploy.
Risk assessment results are identified as a key prerequisite for sustainable operational security in Plan, Do, Check, Act, Table 1. This topic is described in more detail in the BSI Risk Management and Architectural Risk Analysis content areas and applied to deployment and operations here.
Definition of Risk
Alberts [Alberts 05] defines risk as “the possibility of suffering harm or loss.” Jones [Jones 05] defines risk as “the probable frequency and probable magnitude of future loss.” NIST’s Special Publication Risk Management Guide for Information Technology Systems states the following [Stoneburner 02]:
Risk is the net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.
Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations’ missions.
Questions to Ask
In determining what risk-centered practices need to be deployed to ensure a more sustainable level of security, practitioners (and their managers) need to ask and answer the following questions [Allen 05; BSI Governance & Management article "How Much Security Is Enough?"]:
- What is the value we need to protect?
- To sustain this value, what software, system, and information assets need to be protected? Why do they need to be protected? What happens if they’re not protected?
- What potential adverse conditions and consequences need to be prevented and managed? At what cost? How much disruption can we stand before we take action?
- How do we determine and effectively manage residual risk (the risk remaining after mitigation actions are taken)?
- How do we integrate our answers to these questions into an effective, implementable, enforceable security strategy and plan?
Principles that Argue for a Risk-Centered Approach
NIST Special Publication 800-27, Engineering Principles for Information Technology Security [Stoneburner 04] identifies 33 principles for IT security, 7 of which are essential for deploying and operating a system using risk-centered practices. The 800-27 principle numbers are retained here to ease traceability to the publication:
- "Principle 5: Reduce risk to an acceptable level. The goal is to enhance mission/business capabilities by mitigating mission/business risk to an acceptable level. (See also BSI Governance & Management article "How Much Security Is Enough?" for a discussion of risk tolerance).
- Principle 6: Assume that external systems are insecure. Those responsible for deployment and operations should presume the security measures of an external system are different from those of a trusted internal system and deploy security practices accordingly.
- Principle 7: Identify potential tradeoffs between reducing risk, increased costs, and decreased operational effectiveness. A cost-benefit analysis should be conducted for each proposed security control. In some cases, the benefits of a more secure system may not justify the costs. In modifying or adjusting security goals, an acceptance of greater risk and cost may be inevitable.
- Principle 8: Implement tailored system security measures to meet organizational security goals. Implement lower assurance solutions with lower costs to protect less critical systems and higher assurance solutions only for the most critical assets.
- Principle 9: Protect information while being processed, in transit, and in storage. Select security measures that protect the confidentiality, integrity, and availability of information in all of these states.
- Principle 10: Consider custom products to achieve adequate security. In some instances, commercially available products may not be sufficient.
- Principle 11: Protect against all likely classes of “attacks.” Examples include passive monitoring, active network attacks, insider threat, attacks requiring physical access, social engineering, and the insertion of malicious code during software development and distribution."
Identifying the organization’s most critical assets and where those assets are most at risk should inform the selection and prioritization of security practices for deployment and operations.
Risk-centered practices that aid in security practice selection for deployment and operations include the following. These are listed in the order recommended for implementation.
- Define the scope of the risk assessment. Ensure a clear and direct tie to business and mission objectives.
- Identify information and software assets that are important to the organization. Focus risk assessment on those assets judged to be the most critical.
- Identify asset owners and custodians.
- Determine the criteria for accepting risks and the acceptable levels of risk, often referred to as risk tolerances or risk thresholds.
- Identify the relationships among critical assets, the threats to those assets, and vulnerabilities (both organizational and technological) that can expose assets to threats.
- Assess the likelihood of threats and vulnerabilities.
- Identify the impacts due to losses resulting from realized risks.
- Identify risks and evaluate options for treatment of risks (accept, mitigate, avoid, transfer, share with a third party (such as a supplier)).
- Identify practice-based protection strategies (control objectives and controls) that reduce risks to critical assets to levels that are within acceptable tolerances. Controls can be deployed to reduce likelihood and impact.
- Identify potential tradeoffs between reducing risk, increased costs, and decreased operational effectiveness.
- Identify approaches for managing residual risks that remain after protection strategies are adopted.
- Measure, review, and revise risk-centered practices. Re-assess risks periodically.
Table 1 (included at the end of this article) provides additional details and sources that expand these practices.
Description of Sources
The following sources were used to identify the risk-centered practices described above and expanded in Table 1.
British Standard 7799-3 Guidelines for information security risk management [BSI 06] defines in detail the risk management practices identified in ISO 27002/17799 [ISO 05a] and ISO 27001 [ISO 05b]. It states the following in its introduction:
A process approach (for assessing risks, treating risks, and ongoing risk monitoring, risk reviews, and re-assessments) emphasizes the importance of (a) understanding business information security requirements and the need to establish policy and objectives for information security; (b) selecting, implementing, and operating controls in the context of managing an organization’s overall business risks; (c) monitoring and reviewing the performance and effectiveness of the Information Security Management System (ISMS)
Defined in [ISO 05b].to manage business risks; (d) continual improvement based on objective risk measurement.
BS 7799-3 includes useful information identifying categories of information security and organizational risk in Annex B and examples of assets, threats, vulnerabilities, and risk assessment methods in Annex A.
With respect to identifying and categorizing information-related assets, NIST’s Standards for Security Categorization of Federal Information and Information Systems provides useful guidance to establish security categories for both information and information systems. The security categories are based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization [NIST 04].
Establish the context for information security risk management. This includes selecting criteria for evaluating risk, determining impact, and accepting risk; defining the asset scope and boundaries over which risk management will be conducted (for example, which applications will be assessed); and determining the organizational structure, roles, and responsibilities for performing risk management. (Clause 7)
Risk assessment involves conducting risk analysis to identify risks in terms of assets and their value, threats, existing controls, vulnerabilities that could be exploited, and consequences due to impact and loss should risks be realized. The magnitude of potential consequences is estimated in qualitative terms, quantitative where possible, taking the likelihood of incident occurrence into account. Risks are prioritized against evaluation criteria and organizational objectives. (Clause 8)
Develop a risk treatment plan that identifies the controls necessary to reduce, retain, avoid, or transfer identified risks. Controls are selected by performing a cost/benefit analysis, taking criteria into account. Residual risk falls within acceptable risk tolerances. (Clause 9)
The decision to accept identified risks and the responsibilities for each decision are formally documented. Responsible managers review and approve proposed risk treatment plans. (Clause 10) Risk information is shared between decision makers and key stakeholders to provide assurance and support ongoing decision making. (Clause 11)
Implement the risk treatment plan.
Continually monitor and review risks including all relevant factors (including asset value, impacts, threats, vulnerabilities, and likelihood). Identify and act on any changes that add new assets, threats, and vulnerabilities or that update existing risk dimensions, priorities, and treatment. (Clause 12)
Maintain and improve the information risk management process through ongoing monitoring and review. (Clause 12)
OCTAVE and OCTAVE Allegro
OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability EvaluationSM) is a method for managing information security risks. Unlike technology-focused assessments (such as vulnerability assessments or penetration tests), “OCTAVE is targeted at organizational risk and focused on strategic, practice-related issues. The intent of OCTAVE is to strike a balance between operational risk, security practices, and technology” [Alberts 03].
The three phases of OCTAVE are
- Phase 1: Build Asset-Based Threat Profiles
- Process 1: Identify senior management knowledge.
- Process 2: Identify operational area knowledge.
- Process 3: Identify staff knowledge.
- Process 4: Create threat profiles.
- Phase 2: Identify Infrastructure Vulnerabilities
- Process 5: Identify key components.
- Process 6: Evaluate selected components.
- Phase 3: Develop Security Strategy and Plans
- Process 7: Conduct risk analysis.
- Process 8: Develop protection strategy.
OCTAVE Allegro is a more streamlined approach that “optimizes the process of assessing information security risks to that an organization can obtain sufficient results with a small investment in people, time, and other limited resources” [Caralli 07]. Allegro focuses primarily on the use, storage, transport, and processing of information assets, and asset exposure to threats, vulnerabilities, and disruptions.
Allegro has the following eight steps:
1. Establish risk measurement criteria
2. Develop an information asset profile
3. Identify information asset containers
4. Identify areas of concern
5. Identify threat scenarios
Identify and Mitigate Risks
6. Identify risks
7. Analyze risks
8. Select mitigation approach
Software Security: Building Security In
- Understand the business context.
- Identify the business and technical risks.
- Synthesize and rank the risks.
- Define the risk mitigation strategy.
- Carry out fixes and validate.
This chapter also presents a comprehensive example of applying RMF to a server application with stringent first-to-market delivery date requirements, high availability requirements (99.999% uptime), and 100% transaction accuracy requirements to meet federal regulations.
Risk-centered practices represent the state of practice for some organizations and systems. Field work in using the OCTAVE method
If the organization performing system deployment and operations has no framework in which to accept localized risk assessment findings and deploy risk mitigation strategies to benefit the entire organization (and system), sustained improvement may be problematic. That said, an effective way to get started with risk-centered practices is described in the GAO’s report Information Security Risk Assessment: Practices of Leading Organizations:
Rather than conducting one large risk assessment covering all of an entity’s operations at once, the organizations generally conducted a series of narrower assessments on various individual segments of the business. As a result, the scope of each assessment was limited to a particular business unit, system, or facility, or to a logically related set of operations [GAO 99].
Risk-centered practices assume the presence of an appropriate risk assessment method, selected to satisfy business objectives and security, legal, and regulatory requirements. The selected risk assessment method should ensure that subsequent assessments “produce comparable and reproducible results” [ISO 05b].
To be effective and sustainable, risk-centered practices must be deployed using a continuous, plan-do-check-act approach through the useful life of the system.
Table 1: Risk-Centered Practices that Aid in Security Practice Selection for Deployment and Operations
Table 1 lists risk-centered practices and pointers to sources that provide detailed descriptions and implementation guidance. Practices are listed in the order recommended for implementation. Each source is fully cited on its first occurrence and summarized thereafter.
Table 1. Risk-centered practices that aid in security practice selection for deployment and operations
Define the scope of the risk assessment. Ensure a clear and direct tie to business and mission objectives.
Identify information assets that are important to the organization. Focus risk assessment on those assets judged to be the most critical:
Identify asset owners and custodians.
Determine the criteria for accepting risks and the acceptable levels of risk, often referred to as risk tolerances or risk thresholds.
Identify the relationships among critical assets, the threats to those assets, and vulnerabilities (both organizational and technological) that can expose assets to threats.
Assess the likelihood of threats
Identify the impacts due to losses resulting from realized risks.
Identify risks and evaluate options for treatment of risks (accept, mitigate, avoid, transfer, share with a third party (such as a supplier)).
Identity practice-based protection strategies (control objectives and controls) that reduce risks to critical assets to levels that are within acceptable tolerances. Controls can be deployed to reduce likelihood and impact.
Identify potential tradeoffs between reducing risk, increased costs, and decreased operational effectiveness.
Identify approaches for managing residual risks that remain after protection strategies are adopted.
Measure, review, and revise risk-centered practices. Take into account changes to the organization, business objectives and processes, regulatory and marketplace factors, threats, technology, and control effectiveness. Re-assess risks periodically.
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at firstname.lastname@example.org.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.