ezesecops/rmf-ato-core huggingface dataset:
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.2 RISK ASSESSMENT

2.2 RISK ASSESSMENT

This publication focuses on the risk assessment component of risk management-providing a
step-by-step process for organizations on: (i) how to prepare for risk assessments; (ii) how to
conduct risk assessments; (iii) how to communicate risk assessment results to key organizational
personnel; and (iv) how to maintain the risk assessments over time. Risk assessments are not
simply one-time activities that provide permanent and definitive information for decision makers
to guide and inform responses to information security risks. Rather, organizations employ risk
assessments on an ongoing basis throughout the system development life cycle and across all of
the tiers in the risk management hierarchy-with the frequency of the risk assessments and the
resources applied during the assessments, commensurate with the expressly defined purpose and
scope of the assessments.
14 In the absence of an explicit or formal organizational risk management strategy, organizational resources (e.g., tools,
data repositories) and references (e.g., exemplary risk assessment reports) can be used to discern those aspects of the
organization's approach to risk management that affect risk assessment.
15 Organizational vulnerabilities are not confined to information systems but can include, for example, vulnerabilities in
governance structures, mission/business processes, enterprise architecture, information security architecture, facilities,
equipment, system development life cycle processes, supply chain activities, and external service providers.
16 Environments of operation include, but are not limited to: the threat space; vulnerabilities; missions/business
functions; mission/business processes; enterprise and information security architectures; information technologies;
personnel; facilities; supply chain relationships; organizational governance/culture; procurement/acquisition processes;
organizational policies/procedures; organizational assumptions, constraints, risk tolerance, and priorities/trade-offs).
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.3 KEY RISK CONCEPTS

2.3 KEY RISK CONCEPTS

Risk is a measure of the extent to which an entity is threatened by a potential circumstance or
event, and is typically a function of: (i) the adverse impacts that would arise if the circumstance
or event occurs; and (ii) the likelihood of occurrence. Information security risks are those risks
that arise from the loss of confidentiality, integrity, or availability of information or information
systems and reflect the potential adverse impacts to organizational operations (i.e., mission,
functions, image, or reputation), organizational assets, individuals, other organizations, and the
Nation. Risk assessment is the process of identifying, estimating, and prioritizing information
security risks. Assessing risk requires the careful analysis of threat and vulnerability information
to determine the extent to which circumstances or events could adversely impact an organization
and the likelihood that such circumstances or events will occur.
A risk assessment methodology typically includes: (i) a risk assessment process (as described in
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.4 APPLICATION OF RISK ASSESSMENTS

2.4 APPLICATION OF RISK ASSESSMENTS

As stated previously, risk assessments can be conducted at all three tiers in the risk management
hierarchy-organization level, mission/business process level, and information system level.
Figure 4 illustrates the risk management hierarchy defined in NIST Special Publication 800-39,
which provides multiple risk perspectives from the strategic level to the tactical level. Traditional
risk assessments generally focus at the Tier 3 level (i.e., information system level) and as a result,
tend to overlook other significant risk factors that may be more appropriately assessed at the Tier
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.4.1 Risk Assessments at the Organizational Tier

2.4.1 Risk Assessments at the Organizational Tier

At Tier 1, risk assessments support organizational strategies, policies, guidance, and processes for
managing risk. Risk assessments conducted at Tier 1 focus on organizational operations, assets,
and individuals-comprehensive assessments across mission/business lines. For example, Tier 1
risk assessments may address: (i) the specific types of threats directed at organizations that may
be different from other organizations and how those threats affect policy decisions; (ii) systemic
weaknesses or deficiencies discovered in multiple organizational information systems capable of
being exploited by adversaries; (iii) the potential adverse impact on organizations from the loss or
compromise of organizational information (either intentionally or unintentionally); and (iv) the
use of new information and computing technologies such as mobile and cloud and the potential
effect on the ability of organizations to successfully carry out their missions/business operations
while using those technologies. Organization-wide assessments of risk can be based solely on the
assumptions, constraints, risk tolerances, priorities, and trade-offs established in the risk framing
step (i.e., derived primarily from Tier 1 activities). However, more realistic and meaningful risk
assessments are based on assessments conducted across multiple mission/business lines (i.e.,
derived primarily from Tier 2 activities). The ability of organizations to effectively use Tier 2 risk
35 In particular, risk assessment results support investment risk management. NIST Special Publication 800-65 provides
guidance on integrating information security into the Capital Planning and Investment Control (CPIC) process.
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.4.2 Risk Assessments at the Mission/Business Process Tier

2.4.2 Risk Assessments at the Mission/Business Process Tier

At Tier 2, risk assessments support the determination of mission/business process protection and
resiliency requirements, and the allocation of those requirements to the enterprise architecture as
part of mission/business segments (that support mission/business processes). This allocation is
accomplished through an information security architecture embedded within the enterprise
architecture. Tier 2 risk assessments also inform and guide decisions on whether, how, and when
to use information systems for specific mission/business processes, in particular for alternative
mission/business processing in the face of compromised information systems. Risk management
and associated risk assessment activities at Tier 2 are closely aligned with the development of
Business Continuity Plans (BCPs). Tier 2 risk assessments focus on mission/business segments,
which typically include multiple information systems, with varying degrees of criticality and/or
sensitivity with regard to core organizational missions/business functions.37 Risk assessments at
Tier 2 can also focus on information security architecture as a critical component of enterprise
architecture to help organizations select common controls inherited by organizational information
systems at Tier 3. Risk assessment results produced at Tier 2 are communicated to and shared
with organizational entities at Tier 3 to help inform and guide the allocation of security controls
to information systems and environments in which those systems operate. Tier 2 risk assessments
also provide assessments of the security and risk posture of organizational mission/business
processes, which inform assessments of organizational risks at Tier 1. Thus, risk assessment
results at Tier 2 are routinely communicated to organizational entities at Tier 1 and Tier 3.
Guide for Conducting Risk Assessments
CHAPTER 2 > 2.4.3 Risk Assessments at the Information System Tier

2.4.3 Risk Assessments at the Information System Tier

The Tier 2 context and the system development life cycle determine the purpose and define the
scope of risk assessment activities at Tier 3. While initial risk assessments (i.e., risk assessments
performed for the first time, rather than updating prior risk assessments) can be performed at any
phase in the system development life cycle, ideally these assessments should be performed in the
Initiation phase.38 In the Initiation phase, risk assessments evaluate the anticipated vulnerabilities
and predisposing conditions affecting the confidentiality, integrity, and availability of information
systems in the context of the planned environments of operation. Such assessments inform risk
response, enabling information system owners/program managers, together with mission/business
owners to make the final decisions about the security controls necessary based on the security
categorization and the environment of operation. Risk assessments are also conducted at later
phases in the system development life cycle, updating risk assessment results from earlier phases.
These risk assessment results for as-built or as-deployed information systems typically include
36 NIST Special Publication 800-34 provides guidance on Information System Contingency Planning (ISCP).
37 The criticality of information systems to organizational missions/business functions may be identified in Business
Impact Analyses.
38 NIST Special Publication 800-64 provides guidance for security considerations in the system development life cycle.
Guide for Conducting Risk Assessments
3 (information system level). At Tiers 1 and 2, organizations use risk assessments to evaluate, for

3 (information system level). At Tiers 1 and 2, organizations use risk assessments to evaluate, for

example, systemic information security-related risks associated with organizational governance
and management activities, mission/business processes, enterprise architecture, or the funding of
information security programs. At Tier 3, organizations use risk assessments to more effectively
support the implementation of the Risk Management Framework (i.e., security categorization;
security control selection, implementation, and assessment; information system and common
control authorization; and security control monitoring).8
5 The term organization describes an entity of any size, complexity, or positioning within an organizational structure
(e.g., a federal agency or, as appropriate, any of its operational elements) that is charged with carrying out assigned
mission/business processes and that uses information systems in support of those processes.
6 Organizations also manage information technology in the form of common infrastructures, sets of shared services, and
sets of common controls.
7 An information system is a discrete set of information resources organized for the collection, processing, maintenance,
use, sharing, dissemination, or disposition of information.
8 The Risk Management Framework is described in NIST Special Publication 800-37.
O
Guide for Conducting Risk Assessments
CHAPTER 3 > 3.1 PREPARING FOR THE RISK ASSESSMENT

3.1 PREPARING FOR THE RISK ASSESSMENT

The first step in the risk assessment process is to prepare for the assessment. The objective of this
step is to establish a context for the risk assessment. This context is established and informed by
the results from the risk framing step of the risk management process. Risk framing identifies, for
example, organizational information regarding policies and requirements for conducting risk
assessments, specific assessment methodologies to be employed, procedures for selecting risk
factors to be considered, scope of the assessments, rigor of analyses, degree of formality, and
requirements that facilitate consistent and repeatable risk determinations across the organization.
Organizations use the risk management strategy to the extent practicable to obtain information to
prepare for the risk assessment. Preparing for a risk assessment includes the following tasks:
•
Identify the purpose of the assessment;
•
Identify the scope of the assessment;
•
Identify the assumptions and constraints associated with the assessment;
•
Identify the sources of information to be used as inputs to the assessment; and
•
Identify the risk model and analytic approaches (i.e., assessment and analysis approaches) to
be employed during the assessment.
Guide for Conducting Risk Assessments
CHAPTER 3 > 3.3 COMMUNICATING AND SHARING RISK ASSESSMENT INFORMATION

3.3 COMMUNICATING AND SHARING RISK ASSESSMENT INFORMATION

The third step in the risk assessment process is to communicate the assessment results and share
risk-related information.47 The objective of this step is to ensure that decision makers across the
organization have the appropriate risk-related information needed to inform and guide risk
decisions. Communicating and sharing information consists of the following specific tasks:
•
Communicate the risk assessment results; and
•
Share information developed in the execution of the risk assessment, to support other risk
management activities.
Guide for Conducting Risk Assessments
CHAPTER 3 > 3.4 MAINTAINING THE RISK ASSESSMENT

3.4 MAINTAINING THE RISK ASSESSMENT

The fourth step in the risk assessment process is to maintain the assessment. The objective of this
step is to keep current, the specific knowledge of the risk organizations incur. The results of risk
assessments inform risk management decisions and guide risk responses. To support the ongoing
review of risk management decisions (e.g., acquisition decisions, authorization decisions for
information systems and common controls, connection decisions), organizations maintain risk
assessments to incorporate any changes detected through risk monitoring.48 Risk monitoring
provides organizations with the means to, on an ongoing basis: (i) determine the effectiveness of
risk responses; (ii) identify risk-impacting changes to organizational information systems and the
environments in which those systems operate;49 and (iii) verify compliance.50 Maintaining risk
assessments includes the following specific tasks:
•
Monitor risk factors identified in risk assessments on an ongoing basis and understanding
subsequent changes to those factors; and
•
Update the components of risk assessments reflecting the monitoring activities carried out by
organizations.
Guide for Conducting Risk Assessments
APPENDIX K > Appendices

Appendices

•
List references and sources of information.
•
List the team or individuals conducting the risk assessment including contact information.
•
List risk assessment details and any supporting evidence (e.g., Tables D-7, D-8, E-5, F-3,
F-6, H-4), as needed to understand and enable reuse of results (e.g., for reciprocity, for
subsequent risk assessments, to serve as input to Tier 1 and Tier 2 risk assessments).
Guide for Conducting Risk Assessments
APPENDIX A

4.
Information Security Risk: Organization, Mission, and Information System View, March
2011.
5.
Recommended Security Controls for Federal Information Systems and Organizations,
August 2009.
6.
Guide for Assessing the Security Controls in Federal Information Systems and
Organizations: Building Effective Security Assessment Plans, June 2010.
7.
Identifying an Information System as a National Security System, August 2003.
8.
Guide for Mapping Types of Information and Information Systems to Security Categories,
August 2008.
9.
Security Considerations in the System Development Life Cycle, October 2008.
IT Security into the Capital Planning and Investment Control Process, January 2005.
National Checklist Program for IT Products--Guidelines for Checklist Users and
Developers, February 2011.
Guide to Adopting and Using the Security Content Automation Protocol (SCAP), July
2010.
Technical Specification for the Security Content Automation Protocol (SCAP): SCAP
Version 1.0, November 2009.
Security Continuous Monitoring for Federal Information Systems and Organizations,
September 2011.
Guide for Conducting Risk Assessments
APPENDIX B

Authentication
[FIPS 200]
Verifying the identity of a user, process, or device, often
as a prerequisite to allowing access to resources in an
information system.
Authenticity
[CNSSI No. 4009]
The property of being genuine and being able to be
verified and trusted; confidence in the validity of a
transmission, a message, or message originator. See
Authentication.
Authorization
(to operate)
[CNSSI No. 4009]
The official management decision given by a senior
organizational official to authorize operation of an
information system and to explicitly accept the risk to
organizational operations (including mission, functions,
image, or reputation), organizational assets, individuals,
other organizations, and the Nation based on the
implementation of an agreed-upon set of security
controls.
Authorization Boundary
[CNSSI No. 4009]
All components of an information system to be
authorized for operation by an authorizing official and
excludes separately authorized systems, to which the
information system is connected.
Authorizing Official
[CNSSI No. 4009]
Senior (federal) official or executive with the authority to
formally assume responsibility for operating an
information system at an acceptable level of risk to
organizational operations (including mission, functions,
image, or reputation), organizational assets, individuals,
other organizations, and the Nation.
Availability
[44 U.S.C., Sec. 3542]
Ensuring timely and reliable access to and use of
information.
Chief Information Officer
[PL 104-106, Sec. 5125(b)]
Agency official responsible for:
(i) Providing advice and other assistance to the head of
the executive agency and other senior management
personnel of the agency to ensure that information
technology is acquired and information resources are
managed in a manner that is consistent with laws,
Executive Orders, directives, policies, regulations, and
priorities established by the head of the agency;
(ii) Developing, maintaining, and facilitating the
implementation of a sound and integrated information
technology architecture for the agency; and
(iii) Promoting the effective and efficient design and
operation of all major information resources management
processes for the agency, including improvements to
work processes of the agency.
Chief Information Security Officer
See Senior Agency Information Security Officer.
Common Control
[NIST SP 800-37]
A security control that is inherited by one or more
organizational information systems. See Security Control
Inheritance.
Guide for Conducting Risk Assessments
APPENDIX B

Security Control Baseline
[CNSSI No. 4009]
[CNSSI No. 1253]
The set of minimum security controls defined for a low-
impact, moderate-impact, or high-impact information
system.
A set of information security controls that has been
established through information security strategic
planning activities to address one or more specified
security categorizations; this set of security controls is
intended to be the initial security control set selected for a
specific system once that system's security categorization
is determined.
Security Control Enhancement
[NIST SP 800-39, adapted]
Statement of security capability to: (i) build in additional,
but related, functionality to a basic security control;
and/or (ii) increase the strength of a basic control.
Security Control Inheritance
[CNSSI No. 4009]
A situation in which an information system or application
receives protection from security controls (or portions of
security controls) that are developed, implemented,
assessed, authorized, and monitored by entities other than
those responsible for the system or application; entities
either internal or external to the organization where the
system or application resides. See Common Control.
Security Controls
[FIPS 199, CNSSI No. 4009]
The management, operational, and technical controls
(i.e., safeguards or countermeasures) prescribed for an
information system to protect the confidentiality,
integrity, and availability of the system and its
information.
Security Impact Analysis
[NIST SP 800-37]
The analysis conducted by an organizational official to
determine the extent to which changes to the information
system have affected the security state of the system.
Security Objective
[FIPS 199]
Confidentiality, integrity, or availability.
Security Plan
[NIST SP 800-18]
Formal document that provides an overview of the
security requirements for an information system or an
information security program and describes the security
controls in place or planned for meeting those
requirements.
See System Security Plan or Information Security
Program Plan.
Security Policy
[CNSSI No. 4009]
A set of criteria for the provision of security services.
Security Posture
[CNSSI No. 4009]
The security status of an enterprise's networks,
information, and systems based on information assurance
resources (e.g., people, hardware, software, policies) and
capabilities in place to manage the defense of the
enterprise and to react as the situation changes.
Guide for Conducting Risk Assessments
APPENDIX B

Security Requirements
[FIPS 200]
Requirements levied on an information system that are
derived from applicable laws, Executive Orders,
directives, policies, standards, instructions, regulations,
procedures, or organizational mission/business case needs
to ensure the confidentiality, integrity, and availability of
the information being processed, stored, or transmitted.
Semi-Quantitative Assessment
[Department of Homeland Security
(DHS) Risk Lexicon]
Use of a set of methods, principles, or rules for assessing
risk based on bins, scales, or representative numbers
whose values and meanings are not maintained in other
contexts.
Senior Agency
Information Security
Officer
[44 U.S.C., Sec. 3544]
Official responsible for carrying out the Chief
Information Officer responsibilities under FISMA and
serving as the Chief Information Officer's primary liaison
to the agency's authorizing officials, information system
owners, and information system security officers.
[Note: Organizations subordinate to federal agencies may use the term
Senior Information Security Officer or Chief Information Security
Officer to denote individuals filling positions with similar
responsibilities to Senior Agency Information Security Officers.]
Senior Information Security
Officer
See Senior Agency Information Security Officer.
Sensitivity
[NIST SP 800-60]
A measure of the importance assigned to information by
its owner, for the purpose of denoting its need for
protection.
Subsystem
[NIST SP 800-39]
A major subdivision or component of an information
system consisting of information, information
technology, and personnel that performs one or more
specific functions.
Supplementation (Security
Controls)
[NIST SP 800-39]
The process of adding security controls or control
enhancements to a security control baseline from NIST
Special Publication 800-53 or CNSSI No. 1253 in order
to adequately meet the organization's risk management
needs.
System
See Information System.
System Security Plan
[NIST SP 800-18]
Formal document that provides an overview of the
security requirements for an information system and
describes the security controls in place or planned for
meeting those requirements.
System-Specific Security Control
[NIST SP 800-37]
A security control for an information system that has not
been designated as a common control or the portion of a
hybrid control that is to be implemented within an
information system.