NIST SP 800-39

Risk can never be eliminated, but it can be managed using the risk management process. The National Institute of Standards and Technology (NIST) 800 series documents are well-known and accepted as industry standards in information security. Review the NIST SP 800-39, a special publication that outlines a process on how to manage information security risks. Read pages 32-45 for a detailed explanation of the risk management process. Pay attention to the general description for each step in the process: framing risk, assessing risk, responding to risk, and monitoring risk. After you read, you should be able to explain the order of the steps in the process and what happens during in each step.

The Process

1. Framing Risk

Risk framing establishes the context and provides a common perspective on how organizations manage risk. Risk framing, as its principal output, produces a risk management strategy that addresses how organizations intend to assess risk, respond to risk, and monitor risk. The risk management strategy makes explicit the specific assumptions, constraints, risk tolerances, and priorities/trade-offs used within organizations for making investment and operational decisions. The risk management strategy also includes any strategic-level decisions and considerations on how risk to organizational operations and assets, individuals, other organizations, and the Nation, is to be managed by senior leaders/executives.

At Tier 1, senior leaders/executives, in consultation and collaboration with the risk executive (function), define the organizational risk frame including the types of risk decisions (e.g., risk responses) supported, how and under what conditions risk is assessed to support those risk decisions, and how risk is monitored (e.g., to what level of detail, in what form, and with what frequency). At Tier 2, mission/business owners apply their understanding of the organizational risk frame to address concerns specific to the organization’s missions/business functions (e.g., additional assumptions, constraints, priorities, and trade-offs). At Tier 3, program managers, information system owners, and common control providers apply their understanding of the organizational risk frame based on how decision makers at Tiers 1 and 2 choose to manage risk.

The Risk Management Framework is the primary means for addressing risk at Tier 3. The RMF addresses concerns specific to the design, development, implementation, operation, and disposal of organizational information systems and the environments in which those systems operate. The risk frame can be adapted at Tier 3 based on the current phase of the system development life cycle, which further constrains potential risk responses. Initially, organizational risk frames might not be explicit or might not be defined in terms that correspond to the risk management tiers. In the absence of explicit risk frames (describing assumptions, constraints, risk tolerance, and priorities/trade-offs), mission/business owners can have divergent perspectives on risk or how to manage it. This impedes a common understanding at Tier 1 of how information security risk contributes to organizational risk, and at Tier 2, of how risk accepted for one mission or business function potentially affects risk with respect to other missions/business functions. Differences in risk tolerance and the underlying assumptions, constraints, and priorities/trade-offs are grounded in operational and/or architectural considerations and should be understood and accepted by senior leaders/executives within their respective organizations.

STEP 1: RISK FRAMING

Inputs and Preconditions

Risk framing is the set of assumptions, constraints, risk tolerances, and priorities/trade-offs that shape an organization’s approach for managing risk. Risk framing is informed by the organizational governance structure, financial posture, legal/regulatory environment, investment strategy, culture, and trust relationships established within and among organizations. Inputs to the risk framing step include, for example, laws, policies, directives, regulations, contractual relationships, and financial limitations which impose constraints on potential risk decisions by organizations. Other inputs to risk framing can include, for example, specific information from organizations to make explicit: the identification of trust relationships and trust models (see Appendix G) that derive from existing memoranda of understanding or agreement (MOUs or MOAs); and the identification of the governance structures and processes that indicate the extent of or limits on decision-making authority for risk decisions that can be delegated to mission or business owners. The key precondition for risk framing is senior leadership commitment to defining an explicit risk management strategy and holding mission/business owners responsible and accountable for implementing the strategy. The guidance produced by the risk framing step, and the underlying assumptions, constraints, risk tolerances, and priorities/trade-offs used to develop that guidance, may be inappropriate to one or more organizational missions or business functions. In addition, the risk environment has the potential to change over time. Thus, the risk management process allows for feedback to the risk framing step from the other steps in the process, as follows:

  • Risk assessment: Information generated during the risk assessment may influence the original assumptions, change the constraints regarding appropriate risk responses, identify additional tradeoffs, or shift priorities. For example, the characterization of adversaries (including representative tactics, techniques, and procedures), or sources of vulnerability information may not be consistent with how some organizations conduct their missions/business functions; a source of threat/vulnerability information that is useful for one mission/business function could, in fact, be useful for others; or organizational guidance on assessing risk under uncertainty may be too onerous, or insufficiently defined, to be useful for one or more mission/business functions.
  • Risk response: Information uncovered during the development of alternative courses of action could reveal that risk framing has removed or failed to uncover some potentially high-payoff alternatives from consideration. This situation may challenge organizations to revisit original assumptions or investigate ways to change established constraints
  • Risk monitoring: Security control monitoring by organizations could indicate that a class of controls, or a specific implementation of a control, is relatively ineffective, given investments in people, processes, or technology. This situation could lead to changes in assumptions about which types of risk responses are preferred by organizations. Monitoring of the operational environment could reveal changes in the threat landscape (e.g., changes in the tactics, techniques, and procedures observed across all organizational information systems; increasing frequency and/or intensity of attacks against specific missions/business functions) that cause organizations to revisit original threat assumptions and/or to seek different sources of threat information. Significant advances in defensive or proactive operational and technical solutions could generate the need to revisit the investment strategy identified during the framing step. Monitoring of legal/regulatory environments could also influence changes in assumptions or constraints. Also, monitoring of risk being incurred might result in the need to reconsider the organizational risk tolerance if the existing statement of risk tolerance does not appear to match the operational realities.


Activities

RISK ASSUMPTIONS

TASK 1-1: Identify assumptions that affect how risk is assessed, responded to, and monitored within the organization.

Supplemental Guidance: Organizations that identify, characterize, and provide representative examples of threat sources, vulnerabilities, consequences/impacts, and likelihood determinations promote a common terminology and frame of reference for comparing and addressing risks across disparate mission/business areas. Organizations can also select appropriate risk assessment methodologies, depending on organizational governance, culture, and how divergent the missions/business functions are within the respective organizations. For example, organizations with highly centralized governance structures might elect to use a single risk assessment methodology. Organizations with hybrid governance structures might select multiple risk assessment methodologies for Tier 2, and an additional risk assessment methodology for Tier 1 that assimilates and harmonizes the findings, results, and observations of the Tier 2 risk assessments. Alternatively, when autonomy and diversity are central to the organizational culture, organizations could define requirements for the degree of rigor and the form of results, leaving the choice of specific risk assessment methodologies to mission/business owners.

Threat Sources
Threat sources cause events having undesirable consequences or adverse impacts on organizational operations and assets, individuals, other organizations, and the Nation. Threat sources include: hostile cyber/physical attacks; human errors of omission or commission; or natural and man-made disasters. For threats due to hostile cyber attacks or physical attacks, organizations provide a succinct characterization of the types of tactics, techniques, and procedures employed by adversaries that are to be addressed by safeguards and countermeasures (i.e., security controls) deployed at Tier 1 (organization level), at Tier 2 (mission/business process level), and at Tier 3 (information system level) - making explicit the types of threat-sources that are to be addressed as well as making explicit those not being addressed by the safeguards/countermeasures. Adversaries can be characterized in terms of threat levels (based on capabilities, intentions, and targeting) or with additional detail. Organizations make explicit any assumptions about threat source targeting, intentions, and capabilities. Next, organizations identify a set of representative threat events. This set of threat events provides guidance on the level of detail with which the events are described. Organizations also identify conditions for when to consider threat events in risk assessments. For example, organizations can restrict risk assessments to those threat events that have actually been observed (either internally or externally by partners or peer organizations) or alternatively, specify that threat events described by credible researchers can also be considered. Finally, organizations identify the sources of threat information found to be credible and useful (e.g., sector Information Sharing and Analysis Centers [ISACs]). Trust relationships determine from which partners, suppliers, and customers, threat information is obtained as well as the expectations placed on those partners, suppliers and customers in subsequent risk management process steps. By establishing common starting points for identifying threat sources at Tier 1, organizations provide a basis for aggregating and consolidating the results of risk assessments at Tier 2 (including risk assessments conducted for coalitions of missions and business areas or for common control providers) into an overall assessment of risk to the organization as a whole. At Tier 2, mission/business owners may identify additional sources of threat information specific to organizational missions or business functions. These sources are typically based on: a particular business or critical infrastructure sector (e.g., sector ISAC); operating environments specific to the missions or lines of business (e.g., maritime, airspace); and external dependencies (e.g., GPS or satellite communications). The characterization of threat sources are refined for the missions/business functions established by organizations - with the results being that some threat sources might not be of concern, while others could be described in greater detail. At Tier 3, program managers, information system owners, and common control providers consider the phase in the system development life cycle to determine the level of detail with which threats can be considered. Greater threat specificity tends to be available later in the life cycle.

Vulnerabilities
Organizations identify approaches used to characterize vulnerabilities, consistent with the characterization of threat sources and events. Vulnerabilities can be associated with exploitable weakness or deficiencies in: the hardware, software, or firmware components that compose organizational information systems (or the security controls employed within or inherited by those systems; mission/business processes and enterprise architectures (including embedded information security architectures) implemented by organizations; or organizational governance structures or processes. Vulnerabilities can also be associated with the susceptibility of organizations to adverse impacts, consequences, or harm from external sources (e.g., physical destruction of non-owned infrastructure such as electric power grids). Organizations provide guidance regarding how to consider dependencies on external organizations as vulnerabilities in the risk assessments conducted. The guidance can be informed by the types of trust relationships established by organizations with external providers. Organizations identify the degree of specificity with which vulnerabilities are described (e.g., general terms, Common Vulnerability Enumeration [CVE] identifiers, identification of weak/deficient security controls), giving some representative examples corresponding to representative threats. Organizational governance structures and processes determine how vulnerability information is shared across organizations. Organizations may also identify sources of vulnerability information found to be credible and useful. At Tier 2, mission/business owners may choose to identify additional sources of vulnerability information (e.g., a sector ISAC for information about vulnerabilities specific to that sector). At Tier 3, program managers, information system owners, and common control providers consider the phase in the system development life cycle - and in particular, the technologies included in the system – to determine the level of detail with which vulnerabilities can be considered. Organizations make explicit any assumptions about the degree of organizational or information system vulnerability to specific threat sources (by name or by type).

Consequences and Impact
Organizations provide guidance on how to assess impacts to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation (e.g., using FIPS 199, CNSS Instruction 1253, or a more granular approach). Organizations can experience the consequences/impact of adverse events at the information system level (e.g., failing to perform as required), at the mission/business process level (e.g., failing to fully meet mission/business objectives), and at the organizational level (e.g., failing to comply with legal or regulatory requirements, damaging reputation or relationships, or undermining long-term viability). Organizations determine at Tier 1, which consequences and types of impact are to be considered at Tier 2, the mission/business process level. An adverse event can have multiple consequences and different types of impact, at different levels, and in different time frames. For example, the exposure of sensitive information (e.g., personally identifiable information) by a particular mission/business area (e.g., human resources) can have organization-wide consequences and adverse impact with regard to reputation damage; the information system consequence/impact for multiple systems of an attacker more easily overcoming identification and authentication security controls; and the mission/business process consequence/impact (for one or more mission/business areas) of an attacker falsifying information on which future decisions are based. To ensure consistency, organizations determine at Tier 1, how consequences/impacts experienced in different time frames are to be assessed. At Tier 2, mission/business owners may amplify organizational guidance, as appropriate. The types of consequences and impact considered in risk determinations are identified to provide a basis for determining, aggregating, and/or consolidating risk results and to facilitate risk communication. Organizations also provide guidance to Tier 2 and Tier 3 with regard to the extent that risk assessments are to consider the risk to other organizations and the Nation. Organization make explicit any assumptions about the degree of impact/consequences related to specific threat sources (by name or by type) or through specific vulnerabilities (individually or by type).

Likelihood
Organizations can employ a variety of approaches for determining the likelihood of threat events. Some organizations treat the likelihood that a threat event will occur and the likelihood that, if it occurs, it will result in adverse effects as separate factors, while other organizations assess threat likelihood as a combination of these factors. In addition, some organizations prefer quantitative risk assessments while other organizations, particularly when the assessment involves a high degree of uncertainty, prefer qualitative risk assessments. Likelihood determinations can be based on either threat assumptions or actual threat data (e.g., historical data on cyber attacks, historical data on earthquakes, or specific information on adversary capabilities, intentions, and targeting). When specific and credible threat data is available (e.g., types of cyber attacks, cyber attack trends, frequencies of attacks), organizations can use the empirical data and statistical analyses to determine more specific probabilities of threat events occurring. Organizations select a method consistent with organizational culture and risk tolerance. Organizations can also make explicit assumptions concerning the likelihood that a threat event will result in adverse effects as follows: worst case (i.e., attack will be successful unless strong, objective reasons to presume otherwise); best case (i.e., attack will not be successful unless specific, credible information to the contrary); or something in between best and worst cases (e.g., the most probable case). Organizations document any overarching assumptions. Organizations can use empirical data and statistical analyses to help inform any of the approaches used to determine the likelihood of threat events occurring. Organizations select a method consistent with organizational culture, understanding of the operational environment, and risk tolerance.

RISK CONSTRAINTS

TASK 1-2: Identify constraints on the conduct of risk assessment, risk response, and risk monitoring activities within the organization.

Supplemental Guidance: The execution of the risk management process can be constrained in various ways, some of which are direct and obvious, while others are indirect. Financial limitations can constrain the set of risk management activities directly (e.g., by limiting the total resources available for investments in risk assessments or in safeguards or countermeasures) or indirectly (e.g., by eliminating activities which, while involving relatively small investments in risk response, entail curtailing or discarding investments in legacy information systems or information technology). Organizations might also discover that the need to continue to depend on legacy information systems may constrain the risk management options available to the organization. Constraints can also include legal, regulatory, and/or contractual requirements. Such constraints can be reflected in organizational policies (e.g., restrictions on outsourcing, restrictions on and/or requirements for information to be gathered as part of risk monitoring). Organizational culture can impose indirect constraints on governance changes (e.g., precluding a shift from decentralized to hybrid governance structures) and which security controls are considered by organizations as potential common controls. In particular, organizational attitudes toward information technology risk that, for example, favor extensive automation and early adoption of new technologies can constrain the degree of risk avoidance and perhaps risk mitigation that can be achieved. Any cultural constraints that limit senior leader/executive (e.g., chief information officer) visibility into organizational information systems that are beyond their formal authority (e.g. mission-related systems) may impede overall understanding of the complexity of information systems environment and the related risks to the organization. At Tier 2, mission/business owners interpret constraints in light of organizational missions/business functions. Some regulatory constraints may not apply to particular missions/business functions (e.g., regulations that apply to international operations, when mission/business areas are restricted to the United States). Alternately, additional requirements may apply (e.g., mission/business processes performed jointly with another organization, which imposes contractual constraints). At Tier 3, information system owners, common control providers, and/or program managers interpret the organization-wide and mission/business function-specific constraints with respect to their systems and environments of operation (e.g., requirements to provide specific security controls are satisfied through common controls).

RISK TOLERANCE

TASK 1-3: Identify the level of risk tolerance for the organization.

Supplemental Guidance: Risk tolerance is the level of risk that organizations are willing to accept in pursuit of strategic goals and objectives. Organizations define information security-related risk tolerance organization-wide considering all missions/business functions. Organizations can use a variety of techniques for identifying information security risk tolerance (e.g., by establishing zones in a likelihood-impact trade space or by using a set of representative scenarios). Organizations also define tolerance for other types of organizational and operational risks (e.g., financial, risk, safety risk, compliance risk, or reputation risk). At Tier 2, mission/business owners may have different risk tolerances from the organization as a whole. The risk executive (function) provides organizations with ways to resolve such differences in risk tolerances at Tier 2. The level of residual risk accepted by authorizing officials for information systems or inherited common controls is within the organizational risk tolerance, and not the individual risk tolerances of those authorizing officials. In addition, organizations provide to Tier 2 and Tier 3, guidance on evaluating risk for specific mission/business processes or information systems and a focus on near-term mission/business effectiveness with the longer-term, strategic focus of the organizational risk tolerance. See Section 2.3.3 for additional information on risk tolerance

PRIORITIES AND TRADE-OFFS

TASK 1-4: Identify priorities and trade-offs considered by the organization in managing risk.

Supplemental Guidance: Risk is experienced at different levels, in different forms, and in different time frames. At Tier 1, organizations make trade-offs among and establish priorities for responding to such risks. Organizations tend to have multiple priorities that at times conflict, which generates potential risk. Approaches employed by organizations for managing portfolios of risks reflect organizational culture, risk tolerance, as well as risk-related assumptions and constraints. These approaches are typically embodied in the strategic plans, policies, and roadmaps of organizations which may indicate preferences for different forms of risk response. For example, organizations may be willing to accept short-term risk of slightly degraded operations to achieve long-term reduction in information security risk. However, this trade-off could be unacceptable for one particularly critical mission/business function (e.g., real-time requirements in many industrial/process control systems). For that high-priority area, a different approach to improving security may be required including the application of compensating security controls.

Outputs and Post Conditions
The output of the risk framing step is the risk management strategy that identifies how organizations intend to assess, respond to, and monitor risk over time. The framing step also produces a set of organizational policies, procedures, standards, guidance, and resources covering the following topics: scope of the organizational risk management process (e.g., organizational entities covered; mission/business functions affected; how risk management activities are applied within the risk management tiers); risk assessment guidance including, for example, the characterization of threat sources, sources of threat information, representative threat events (in particular, adversary tactics, techniques, and procedures), when to consider and how to evaluate threats, sources of vulnerability information, risk assessment methodologies to be used, and risk assumptions; risk response guidance including, for example, risk tolerances, risk response concepts to be employed, opportunity costs, trade-offs, consequences of responses, hierarchy of authorities, and priorities; risk monitoring guidance, including, for example, guidance on analysis of monitored risk factors to determine changes in risk, and monitoring frequency, methods, and reporting; other and risk constraints on executing risk management activities; and organizational priorities and trade-offs. Outputs from the risk framing step serve as inputs to the risk assessment, risk response, and risk monitoring steps.