ezesecops/rmf-ato-core huggingface dataset:
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER TWO > 2.6 REQUIREMENTS AND CONTROLS

2.6 REQUIREMENTS AND CONTROLS

Before executing the RMF, it is important to understand the concept of security and privacy
requirements and the relationship between requirements and controls. The term requirements
can be used in different contexts. In the context of federal information security and privacy
policies, the term is generally used to refer to information security and privacy obligations
imposed on organizations. For example, OMB Circular A-130 imposes a series of information
security and privacy requirements with which federal agencies must comply when managing
information resources. In addition to the use of the term requirements in the context of federal
policy, the term requirements is used in this guideline in a broader sense to refer to an
expression of the set of stakeholder protection needs for a particular system or organization.
Stakeholder protection needs and corresponding security and privacy requirements may be
derived from many sources (e.g., laws, executive orders, directives, regulations, policies,
standards, mission and business needs, or risk assessments). The term requirements, as used in
this guideline, includes both legal and policy requirements, as well as an expression of the
broader set of stakeholder protection needs that may be derived from other sources. All of
these requirements, when applied to a system, help determine the required characteristics of
the system-encompassing security, privacy, and assurance.
Organizations may choose to divide security and privacy requirements into more granular
categories depending on where the requirements are employed in the SDLC and for what
purpose. Organizations may use the term capability requirement to describe a capability that
the system or organization must provide to satisfy a stakeholder protection need. In addition,
organizations may refer to system requirements that pertain to particular hardware, software,
and firmware components of a system as specification requirements-that is, capabilities that
implement all or part of a control and that may be assessed (i.e., as part of the verification,
validation, testing, and evaluation processes). Finally, organizations may use the term statement
of work requirements to refer to actions that must be performed operationally or during system
development.
Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate
for achieving the particular security and privacy objectives of the organization and reflecting the
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
CHAPTER TWO > 2.7 SECURITY AND PRIVACY POSTURE

2.7 SECURITY AND PRIVACY POSTURE

The purpose of the RMF is to help ensure that, throughout the SDLC, information systems,
organizations, and individuals are adequately protected, and that authorizing officials have the
information needed to make credible, risk-based decisions regarding the operation or use of
systems or the provision of common controls. A key aspect of risk-based decision making for
authorizing officials is understanding the security and privacy posture of information systems
and the common controls that are available for inheritance by those systems. The security and
privacy posture represents the status of information systems and information resources (e.g.,
personnel, equipment, funds, and information technology) within an organization based on
information assurance resources (e.g., people, hardware, software, policies, procedures) and
the capabilities in place to manage the defense of the organization in its operation or use of
systems; comply with applicable privacy requirements and manage privacy risks; and react as
the situation changes.
The security and privacy posture of information systems and organizations is determined on an
ongoing basis by assessing and continuously monitoring system-specific, hybrid, and common
controls.44 The control assessments and monitoring activities provide evidence that the controls
selected by the organization are implemented correctly, operating as intended, and satisfying
the security and privacy requirements in response to laws, executive orders, regulations,
directives, policies, standards, or mission and business requirements. Authorizing officials use
the security and privacy posture to determine if the risk to organizational operations and assets,
44 Monitoring of controls is part of an organization-wide risk management approach defined in [SP 800-39].
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
6 (along with the security and privacy assessment and monitoring frequency determinations

6 (along with the security and privacy assessment and monitoring frequency determinations

established as part of the continuous monitoring strategy), organizations determine a frequency
with which authorizing officials review security and privacy information via the security or
privacy management and reporting tool or manual process.153 The near real-time information
from the reporting tool or manual process is used to determine whether the mission or business
risk of operating the system or providing the common controls continues to be acceptable. [SP
800-137] provides criteria for determining assessment and monitoring frequencies.
Under ongoing authorization, time-driven authorization triggers refer to the frequency with
which the organization determines that authorizing officials are to review security and privacy
information and authorize the system (or common controls) for continued operation as
described above. Time-driven authorization triggers can be based on a variety of organization-
defined factors including the impact level of the system. When a time-driven trigger occurs,
authorizing officials review security and privacy information on the systems for which they are
responsible and accountable to determine the ongoing organizational mission or business risk,
the acceptability of such risk in accordance with organizational risk tolerance, and whether the
approval for continued operation is justified. The organizational continuous monitoring process,
supported by the organization's security and privacy management and reporting tools, provides
153 Ongoing authorization and ongoing assessment are different concepts but closely related. To employ an ongoing
authorization approach (which implies an ongoing understanding and acceptance of risk), organizations must have in
place, an organization-level and system-level continuous monitoring process to assess implemented controls on an
ongoing basis. The findings or results from the continuous monitoring process provides information to authorizing
officials to support near-real time risk-based decision making.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
Abstract

Abstract

This publication describes the Risk Management Framework (RMF) and provides guidelines for
applying the RMF to information systems and organizations. The RMF provides a disciplined,
structured, and flexible process for managing security and privacy risk that includes information
security categorization; control selection, implementation, and assessment; system and
common control authorizations; and continuous monitoring. The RMF includes activities to
prepare organizations to execute the framework at appropriate risk management levels. The
RMF also promotes near real-time risk management and ongoing information system and
common control authorization through the implementation of continuous monitoring
processes; provides senior leaders and executives with the necessary information to make
efficient, cost-effective, risk management decisions about the systems supporting their missions
and business functions; and incorporates security and privacy into the system development life
cycle. Executing the RMF tasks links essential risk management processes at the system level to
risk management processes at the organization level. In addition, it establishes responsibility
and accountability for the controls implemented within an organization's information systems
and inherited by those systems.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX A

POLICIES, REGULATIONS, DIRECTIVES, AND INSTRUCTIONS
[OMB A-123]
Office of Management and Budget Circular No. A-123, Management's
Responsibility for Enterprise Risk Management and Internal Control, July
2016.
https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2016/
m-16-17.pdf
[OMB A-130]
Office of Management and Budget Circular A-130, Managing Information as
a Strategic Resource, July 2016.
https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A130/a13
0revised.pdf
[OMB M-13-13]
Office of Management and Budget Memorandum M-13-13, Open Data
Policy-Managing Information as an Asset, May 2013.
https://obamawhitehouse.archives.gov/sites/default/files/omb/memoranda/2013
/m-13-13.pdf
[OMB M-17-25]
Office of Management and Budget Memorandum M-17-25, Reporting
Guidance for Executive Order on Strengthening the Cybersecurity of Federal
Networks and Critical Infrastructure, May 2017.
https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2017/
M-17-25.pdf
[OMB M-19-03]
Office of Management and Budget Memorandum M-19-03, Strengthening
the Cybersecurity of Federal Agencies by enhancing the High Value Asset
Program, December 2018.
https://www.whitehouse.gov/wp-content/uploads/2018/12/M-19-03.pdf
[CNSSI 1253]
Committee on National Security Systems Instruction 1253, Security
Categorization and Control Selection for National Security Systems, March
2014.
https://www.cnss.gov/CNSS/issuances/Instructions.cfm
[CNSSI 4009]
Committee on National Security Systems Instruction 4009, Committee on
National Security Systems (CNSS) Glossary, April 2015.
https://www.cnss.gov/CNSS/issuances/Instructions.cfm
[CNSSD 505]
Committee on National Security Systems Directive 505, Supply Chain Risk
Management, August 2017.
https://www.cnss.gov/CNSS/issuances/Directives.cfm
[OCIO HVA]
Office of the Federal Chief Information Officer, The Agency HVA Process.
https://policy.cio.gov/hva/process
[DODI 5200.44]
Department of Defense Instruction 5200.44, Protection of Mission Critical
Functions to Achieve Trusted Systems and Networks (TSN), July 2017.
http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/520044p.pdf
STANDARDS, GUIDELINES, AND REPORTS
[IEEE 610.12]
Institute of Electrical and Electronics Engineers (IEEE) Std. 610.12-1990, IEEE
Standard Glossary of Software Engineering Terminology, December 1990.
https://ieeexplore.ieee.org/iel1/2238/4148/00159342.pdf
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX A

Revision 1, Guide for Developing Security Plans for Federal Information
Systems, February 2006.
[SP 800-30]
Revision 1, Guide for Conducting Risk Assessments, September 2012.
[SP 800-39]
Managing Information Security Risk: Organization, Mission, and
Information System View, March 2011.
[SP 800-47]
Security Guide for Interconnecting Information Technology Systems, August
2002.
[SP 800-53]
Revision 4, Security and Privacy Controls for Federal Information Systems
and Organizations, April 2013.
[SP 800-53A]
Revision 4, Assessing Security and Privacy Controls in Federal Information
Systems and Organizations: Building Effective Security Assessment Plans,
July 2008.
[SP 800-55]
Revision 1, Performance Measurement Guide for Information Security,
December 2014.
[SP 800-59]
Guideline for Identifying an Information System as a National Security
System, August 2003.
[SP 800-60 v1]
Volume 1, Revision 1, Guide for Mapping Types of Information and
Information Systems to Security Categories, August 2008.
[SP 800-60 v2]
Volume 2, Revision 1, Guide for Mapping Types of Information and
Information Systems to Security Categories: Appendices, August 2008.
[SP 800-61]
Revision 2, Computer Security Incident Handling Guide, August 2012.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX A

Revision 2, Security Considerations in the System Development Life Cycle,
October 2008.
[SP 800-82]
Revision 2, Guide to Industrial Control Systems (ICS) Security, May 2015.
[SP 800-88]
Guidelines for Media Sanitization, December 2014.
[SP 800-128]
Guide for Security-Focused Configuration Management of Information
Systems, August 2011.
[SP 800-137]
Information Security Continuous Monitoring for Federal Information
Systems and Organizations, September 2011.
[SP 800-160 v1]
Volume 1, Systems Security Engineering: Considerations for a
Multidisciplinary Approach in the Engineering of Trustworthy Secure
Systems, November 2016.
[SP 800-161]
Supply Chain Risk Management Practices for Federal Information Systems
and Organizations, April 2015.
[SP 800-181]
National Initiative for Cybersecurity Education (NICE) Cybersecurity
Workforce Framework, August 2017.
[IR 8011 v1]
Volume 1, Automation Support for Security Control Assessments: Overview,
June 2017.
[IR 8062]
Introduction to Privacy Engineering and Risk Management in Federal
Systems, January 2017.
[IR 8179]
Criticality Analysis Process Model: Prioritizing Systems and Components,
April 2018.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX A

MISCELLANEOUS PUBLICATIONS AND WEBSITES
[DSB 2013]
Department of Defense, Defense Science Board, Task Force Report:
Resilient Military Systems and the Advanced Cyber Threat, January 2013.
https://www.acq.osd.mil/dsb/reports/2010s/ResilientMilitarySystemsCyberThreat.
pdf
[NARA CUI]
National Archives and Records Administration, Controlled Unclassified
Information (CUI) Registry.
https://www.archives.gov/cui
[NARA RECM]
National Archives and Records Administration, NARA Records Management
Guidance and Regulations.
https://www.archives.gov/records-mgmt/policy/guidance-regulations.html
[NIST CSF]
Critical Infrastructure Cybersecurity (Cybersecurity Framework), Version 1.1,
April 2018.
https://www.nist.gov/cyberframework
[OMB FEA]
Office of Management and Budget, Federal Enterprise Architecture (FEA).
https://obamawhitehouse.archives.gov/omb/e-gov/fea
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX D

•
An organization-wide security program is effectively implemented resulting in adequate
security for all organizational systems and environments of operation;
•
Security and privacy (including supply chain) risk management considerations are integrated
into programming/planning/budgeting cycles, enterprise architectures, the SDLC, and
acquisitions;
•
Organizational systems and common controls are covered by approved system security
plans and possess current authorizations;
•
Security activities required across the organization are accomplished in an efficient, cost-
effective, and timely manner; and
•
There is centralized reporting of security activities.
The chief information officer and authorizing officials determine the allocation of resources
dedicated to the protection of systems supporting the organization's missions and business
functions based on organizational priorities. For information systems that process personally
identifiable information, the chief information officer and authorizing officials coordinate any
determination about the allocation of resources dedicated to the protection of those systems
with the senior agency official for privacy. For selected systems, the chief information officer
may be designated as an authorizing official or a co-authorizing official with other senior
organizational officials. The role of chief information officer is an inherent U.S. Government
function and is assigned to government personnel only.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F

•
Modifications to how information, including PII, is processed;
•
Modifications to cryptographic modules or services;
•
Changes in information types processed, stored, or transmitted by the system; or
•
Modifications to security and privacy controls.
Significant changes to the environment of operation that may trigger an event-driven
authorization action may include, but are not limited to:
•
Moving to a new facility;
•
Adding new core missions or business functions;
•
Acquiring specific and credible threat information that the organization is being targeted by
a threat source; or
•
Establishing new/modified laws, directives, policies, or regulations.
The examples of changes listed above are only significant when they represent a change that is
likely to affect the security and privacy posture of the system. Organizations establish criteria for
what constitutes significant change based on a variety of factors (e.g., mission and business
needs; threat and vulnerability information; environments of operation for systems; privacy
risks; and security categorization).
Risk assessment results or the results from an impact analysis may be used to determine if
changes to systems or common controls are significant and trigger an authorization action. If an
authorization action is initiated, the organization targets only the specific controls affected by
the changes and reuses previous assessment results wherever possible. An effective monitoring
program can significantly reduce the overall cost and level of effort of authorization actions.
Most changes to a system or its environment of operation can be handled through the
continuous monitoring program and ongoing authorization.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX F

Collaboration on security categorization, control selection and tailoring, a plan for assessing
controls to determine effectiveness, a plan of action and milestones, and a system-level
continuous monitoring strategy is necessary for a successful joint authorization. The terms and
conditions of the joint authorization are established by the participating parties in the joint
authorization including the process for ongoing determination and acceptance of risk. The joint
authorization remains in effect only while there is agreement among authorizing officials and
the authorization meets the specific requirements established by federal and organizational
policies. [SP 800-53] controls CA-6(1), Joint Authorization - Same Organization and CA-6(2) Joint
Authorization - Different Organizations, describe the requirements for joint authorizations.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX G

Organizations can employ the concept of subsystems to divide complex systems into a set of
manageable system elements or identify those elements that support a similar mission, but are
sufficiently distinct to be identified separately. Each subsystem has its own boundary (distinct
from an authorization boundary) and can be defined within a comprehensive authorization
boundary that includes all subsystems.
For example, an organization may find it useful to combine several systems that are under the
same direct management control or that have similar missions or business functions into a
single system to achieve the dual purposes of effective risk and resource management. An
organization may also choose to develop a system composed of multiple independent systems
(distributed across a widespread geographic area) supporting a set of common missions or
business functions. Similarly, a system can be divided into multiple subsystems to facilitate and
support management of the system and risk-based decision making (e.g., categorization
decisions, tailoring decisions, and control allocation decisions).
Dividing a system into subsystems (i.e., divide and conquer) facilitates a targeted application of
controls to achieve adequate security, protection of individual privacy, and a cost-effective risk
management process. Dividing complex systems into subsystems also supports the important
security concepts of domain separation and network segmentation, which can be significant
when dealing with high value assets. When systems are divided into subsystems, organizations
may choose to develop individual subsystem security and privacy plans or address the system
and subsystems in the same security and privacy plans.
Information security and privacy architectures play a key part in the process of dividing complex
systems into subsystems. This includes monitoring and controlling communications at internal
boundaries among subsystems and selecting, allocating, and implementing controls that meet
or exceed the security and privacy requirements of the constituent subsystems. One approach
to control selection and allocation is to categorize each identified subsystem separately (see
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX G > AUTHORIZATION BOUNDARIES AND EXTERNAL PROVIDERS

AUTHORIZATION BOUNDARIES AND EXTERNAL PROVIDERS

While the concepts of external systems and external service providers are not new, the current
pervasiveness and frequency of their invocation can present organizations with significant, new
challenges. There are instances where system elements, subsystems, or perhaps the entire
system may be outside of the direct control of the organization that authorizes its operation.
The nature of such external systems can vary from organizations employing external cloud
computing services to process, store, and transmit federal information to organizations allowing
platforms under their control to host applications or services developed by some external
entity.165
FISMA and OMB policy require external providers that process, store, or transmit federal
information or operate information systems on behalf of the federal government to meet the
same security and privacy requirements as federal agencies. Federal security and privacy
requirements also apply to external systems storing, processing, or transmitting federal
information and any services provided by or associated with the external system. Furthermore,
165 The Federal Risk and Authorization Management Program (FedRAMP) operated by the General Services
Administration (GSA) provides guidance on determining cloud authorization boundaries.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
APPENDIX G > AUTHORIZATION BOUNDARIES FOR COMPLEX SYSTEMS

AUTHORIZATION BOUNDARIES FOR COMPLEX SYSTEMS

The determination of authorization boundaries for complex systems can present significant
challenges to organizations. A complex system can be viewed as set of individual subsystems. A
subsystem is a major subdivision of a system consisting of system elements that perform one or
more specific functions. Figure G-1 illustrates the concept of a complex system.
FIGURE G-1: CONCEPTUAL VIEW OF A COMPLEX SYSTEM
T
ENVIRONMENT OF OPERATION
Note: The system is categorized at the high-
water mark of all designated subsystems.
SYSTEM
(AUTHORIZATION BOUNDARY)
Other
System
Enabling
System
SUBSYSTEM 1
System
Element
System
Element
System
Element
SUBSYSTEM 2
System
Element
System
Element
System
Element
SUBSYSTEM 3
System
Element
System
Element
System
Element
Enabling
System