U.S. Flag Official website of the Department of Homeland Security

Note: This page is part of the us-cert.gov archive.This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact info@us-cert.gov if you have any questions about the US-CERT website archive.

TLP:WHITE

Risk-Centered Practices

Published: October 30, 2006 | Last revised: July 02, 2013

Author(s): Julia H. Allen Maturity Levels and Audience Indicators: L4  / L M  SDLC Life Cycles: Deployment Copyright: Copyright © Carnegie Mellon University 2005-2012.

Abstract

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.

Introduction

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

Risk-Centered Practices

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.

  1. Define the scope of the risk assessment. Ensure a clear and direct tie to business and mission objectives.
  2. Identify information and software assets that are important to the organization. Focus risk assessment on those assets judged to be the most critical.
  3. Identify asset owners and custodians.
  4. Determine the criteria for accepting risks and the acceptable levels of risk, often referred to as risk tolerances or risk thresholds.
  5. Identify the relationships among critical assets, the threats to those assets, and vulnerabilities (both organizational and technological) that can expose assets to threats.
  6. Assess the likelihood of threats and vulnerabilities.
  7. Identify the impacts due to losses resulting from realized risks. 
  8. Identify risks and evaluate options for treatment of risks (accept, mitigate, avoid, transfer, share with a third party (such as a supplier)).
  9. 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.
  10. Identify potential tradeoffs between reducing risk, increased costs, and decreased operational effectiveness.
  11. Identify approaches for managing residual risks that remain after protection strategies are adopted.
  12. 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.

BS 7799-3

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.

FIPS 199

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

ISO/IEC 27005

This standard [ISO 08] defines a Plan, Do, Check, Act information security risk management process, consisting of the following steps:

Plan

 

1.

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)

2.

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)

3.

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)

4.

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)

Do

 

5.

Implement the risk treatment plan.

Check

 

6.

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)

Act

 

7.

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:

Establish Drivers
   1. Establish risk measurement criteria
Profile Assets
   2. Develop an information asset profile
   3. Identify information asset containers
Identify Threats
   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

Chapter 2 of the book Software Security: Building Security In describes a risk management framework (RMF) comprising five stages [McGraw 06]:

  1. Understand the business context.
  2. Identify the business and technical risks.
  3. Synthesize and rank the risks.
  4. Define the risk mitigation strategy.
  5. 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.

Implementation Considerations

Risk-centered practices represent the state of practice for some organizations and systems. Field work in using the OCTAVE methodSome OCTAVE experience reports are available on the CERT Web site (http://www.cert.org/octave/). has shown that if a risk assessment is performed at a mid-level in the organization, localized decisions can be made and acted on. Occasionally there are barriers to extrapolating these decisions to an organizational or system-wide level, which is often required to sustain successful improvement at the local level. An example is the need for a policy on incident reporting that enables local action but needs to be authored and sponsored at a broader organizational level to be enforceable.

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

Conclusion

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

Practice

Sources

Define the scope of the risk assessment. Ensure a clear and direct tie to business and mission objectives.

  • “Introduction to the OCTAVE®Approach” [Alberts 03]; OCTAVE Allegro [Caralli 07]
  • Software Security:Building Security In, Chapter 2, “A Risk Management Framework” [McGraw 06]
  • ISO 27005 Information Security Risk Management [ISO 08]

Identify information assets that are important to the organization. Focus risk assessment on those assets judged to be the most critical:

  • asset value
  • business and legal requirements
  • impact of loss of confidentiality, integrity, availability
  • FIPS 199 Security Categorization of Federal Information and Information Systems [NIST 04]
  • Software Security, Chapter 2 [McGraw 06]
  • BS 7799-3 Guidelines for information security risk management [BSI 06]
  • ISO 27005 [ISO 08]
  • OCTAVE [Alberts 03]; OCTAVE Allegro [Caralli 07]

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 Threats include characterizing an organization’s “adversaries, their potential motivations, and their classes of attack” http://nsa2.www.conxion.com/support/guides/sd-1.pdf. 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)).

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.

  • NIST 800-27 (Principle 7) Engineering Principles for Information Technology Security [Stoneburner 04]
  • ISO 27005 [ISO 08]

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.

 


Back to Top