Chapter 5

Risk Management Framework

Abstract

The primary method for testing and evaluation of governmental systems, the Risk Management Framework as defined in NIST Special Publication (SP) 800-37, revision 1, is defined and briefly explained.

Keywords

RMF
categorize system
select controls
implement controls
assess system
authorize system
monitor controls
image
Figure 5.1 Risk Management Framework.
Each step of the Risk Management Framework requires detailed knowledge components, understanding the scope and mission of the system under review and external data about the organization, personnel, and activities. The six steps of the Risk Management Framework cover the full picture of the system and its intended use in the federal space. All US governmental agencies now use this defined process to assess and authorize their IT systems for use on a federal network, including DOD and the IC. The following is another representation of the Risk Management Framework with the NIST Special Publications used for guidance on each step added for further clarification:
image
Each step of the Risk Management Framework has delineated steps for accomplishment of the specific requirements within each step. Tasking parameters are defined by required events to be completed, primary and secondary roles and responsibilities for each task, and final results for each task and, subsequently, each step of the framework.

Step 1 – categorization

The primary goal of this step is to categorize the information system and the information processed, stored, and transmitted by that system based on an impact analysis. The objectives of this step are as follows:
• Produce the FIPS-199 Categorization Document for the system.
• Document is utilized in multiple locations and on multiple efforts:
• Storage Service Provider (SSP)
• Budgets and CPIC activities
• System of Records Notice (SORN)
• Program Objective Memorandum (POM) and Program of Requirements (POR) actions for DOD and the military services
Categorization of the information system is based on an impact analysis.
It is performed to determine:
• The types of information included within the security authorization boundary
• The security requirements for the information types
• The potential impact on the organization resulting from a security compromise
The result is used as the basis for developing the security plan, selecting security controls, and determining the risk inherent in operating the system.
The identified tasks for step 1 are as follows:
1. Categorize the information system and document the results of the security categorization in the security plan.
2. Describe the information system (including system boundary) and document the description in the security plan.
3. Register the information system with appropriate organizational program/management offices.
The guidance from the SP 800-37, rev. 1 gives additional insight to categorization: “The security categorization process is carried out by the information system owner and information owner/steward in cooperation and collaboration with appropriate organizational officials (i.e., senior leaders with mission/business function and/or risk management responsibilities). The security categorization process is conducted as an organization-wide activity taking into consideration the enterprise architecture and the information security architecture. This helps to ensure that individual information systems are categorized based on the mission and business objectives of the organization. The information system owner and information owner/steward consider results from the initial risk assessment as a part of the security categorization decision. The security categorization decision is consistent with the organization’s risk management strategy to identify potential impact to mission/business functions resulting from the loss of confidentiality, integrity, and/or availability. The risk management strategy provides guidance and relevant information to authorizing officials (e.g., risk assessment methodologies employed by the organization, evaluation of risks determined, risk mitigation approaches, organizational risk tolerance, approaches for monitoring risk over time, known existing aggregated risks from current information systems, and other sources of risk).
The results of the security categorization process influence the selection of appropriate security controls for the information system and also, where applicable, the minimum assurance requirements for that system. Security categorization determinations consider potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation. The organization may consider decomposing the information system into multiple subsystems to more efficiently and effectively allocate security controls to the system. One approach is to categorize each identified subsystem (including dynamic subsystems). Separately categorizing each subsystem does not change the overall categorization of the information system. Rather, it allows the constituent subsystems to receive a separate allocation of security controls from NIST Special Publication 800-53 instead of deploying higher-impact controls across every subsystem. Another approach is to bundle smaller subsystems into larger subsystems within the information system, categorize each of the aggregated subsystems, and allocate security controls to the subsystems, as appropriate. Security categorization information is documented in the system identification section of the security plan or included as an attachment to the plan.”1

Step 2 – selection

The primary goal of this step is to select an initial set of baseline security controls for the information system based on the security categorization, tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions. The objectives of this step are as follows:
• Identify security controls needed.
• Select minimum security control baseline.
• Build monitoring strategy for identified controls.
The security control baseline is established by determining specific controls required to protect the system based on the security categorization of the system. The baseline is tailored and supplemented in accordance with an organizational assessment of risk and local parameters. The security control baseline, as well as the plan for monitoring it, is documented in the security plan.
The identified tasks for step 2 are as follows:
1. Identify the security controls that are provided by the organization as common controls for organizational information systems and document the controls in a security plan (or equivalent document).
2. Select the security controls for the information system and document the controls in the security plan.
3. Develop a strategy for the continuous monitoring of security control effectiveness and any proposed or actual changes to the information system and its environment of operation.
4. Review and approve the security plan.
The guidance from the SP 800-37, rev. 1 gives additional insight to control selection:

The security controls are selected based on the security categorization of the information system. After selecting the applicable security control baseline, organizations apply the tailoring process to align the controls more closely with the specific conditions within the organization (i.e., conditions related to organizational risk tolerance, missions/business functions, information systems, or environments of operation). The tailoring process includes:

(i) identifying and designating common controls in initial security control baselines;

(ii) applying scoping considerations to the remaining baseline security controls;

(iii) selecting compensating security controls, if needed;

(iv) assigning specific values to organization-defined security control parameters via explicit assignment and selection statements;

(v) supplementing baselines with additional security controls and control enhancements, if needed; and

(vi) providing additional specification information for control implementation, if needed.

Organizations use risk assessments to inform and guide the tailoring process for organizational information systems and environments of operation. Threat data from risk assessments provide critical information on adversary capabilities, intent, and targeting that may affect organizational decisions regarding the selection of additional security controls, including the associated costs and benefits. Risk assessment results are also leveraged when identifying common controls to help determine if such controls available for inheritance meet the security requirements for the system and its environment of operation (including analyses for potential single points of failure). The security plan contains an overview of the security requirements for the information system in sufficient detail to determine that the security controls selected would meet those requirements. The security plan, in addition to the list of security controls to be implemented, describes the intended application of each control in the context of the information system with sufficient detail to enable a compliant implementation of the control. During the security control selection process organizations may begin planning for the continuous monitoring process by developing a monitoring strategy. The strategy can include, for example, monitoring criteria such as the volatility of specific security controls and the appropriate frequency of monitoring specific controls. Organizations may choose to address security control volatility and frequency of monitoring during control selection as inputs to the continuous monitoring process. The monitoring strategy can be included in the security plan to support the concept of near real-time risk management and ongoing authorization. Information system owners inheriting common controls can either document the implementation of the controls in their respective security plans or reference the controls contained in the security plans of the common control providers. Information system owners can refer to the security authorization packages prepared by common control providers when making determinations regarding the adequacy of common controls inherited by their respective systems.

For net-centric architectures where subsystems may be added or removed from an information system dynamically, the organization includes in the security plan for the system:

(i) descriptions of the functions of the dynamic subsystems;

(ii) the security controls employed in the subsystems;

(iii) constraints/assumptions regarding the functions of the dynamic subsystems and the associated security controls in the subsystems;

(iv) dependencies of other subsystems on the proper functioning of the security controls of the dynamic subsystems;

(v) procedures for determining that the dynamic subsystems conform to the security plan, assumptions, and constraints; and

(vi) the impact of the dynamic subsystems and associated security controls on existing security controls in the information system. While inclusion of a dynamic subsystem may impact the information system or some of the currently identified subsystems, it does not necessarily mean the subsystem will impact the security of the system or other subsystems. That is, not all subsystems are security relevant.

Changes in the net-centric architectures that exceed the anticipated limits of the security plan may not be allowed or may require reassessment prior to being approved. When security controls are designated as common controls, the organization ensures that sufficient information is available to information system owners and authorizing officials to support the risk management process. When security services are provided by external providers (e.g., through contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain arrangements), the organization:

(i) defines the external services provided to the organization;

(ii) describes how the external services are protected in accordance with the security requirements of the organization; and

(iii) obtains the necessary assurances that the risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the use of the external services is acceptable.

The organization also considers that replicated subsystems within a complex information system may exhibit common vulnerabilities that can be exploited by a common threat source, thereby negating the redundancy that might be relied upon as a risk mitigation measure. The impact due to a security incident against one constituent subsystem might cascade and impact many subsystems at the same time.2

Step 3 – implementation

The primary goal of this step is to implement the security controls and describe how the controls are employed within the information system and its environment of operation. The objectives of this step are as follows:
• Install security controls into system.
• Document controls as installed.
The security controls specified in the security plan are implemented by taking into account the minimum organizational assurance requirements. The security plan describes how the controls are employed within the information system and its operational environment. The security assessment plan documents the methods for testing these controls and the expected results throughout the system life cycle.
The identified tasks for step 3 are as follows:
1. Implement the security controls specified in the security plan.
2. Document the security control implementation, as appropriate, in the security plan, providing a functional description of the control implementation (including planned inputs, expected behavior, and expected outputs).
The guidance from the SP 800-37, rev. 1 gives additional insight to implementation of controls: “Security control implementation is consistent with the organization’s enterprise architecture and information security architecture. The information security architecture serves as a resource to allocate security controls (including, for example, security mechanisms and services) to an information system and any organization-defined subsystems. Early integration of information security requirements into the system development life cycle is the most cost-effective method for implementing the organizational risk management strategy at Tier 3. Security controls targeted for deployment within the information system (including subsystems) are allocated to specific system components responsible for providing a particular security capability. Not all security controls need to be allocated to every subsystem. Categorization of subsystems, information security architecture, and allocation of security controls work together to help achieve a suitable balance. Allocating some security controls as common controls or hybrid controls is part of this architectural process. Organizations use best practices when implementing the security controls within the information system including system and software engineering methodologies, security engineering principles, and secure coding techniques. Risk assessment may help inform decisions regarding the cost, benefit, and risk trade-offs in using one type of technology versus another for control implementation. In addition, organizations ensure that mandatory configuration settings are established and implemented on information technology products in accordance with federal and organizational policies (e.g., Federal Desktop Core Configuration). Information system security engineers with support from information system security officers employ a sound security engineering process that captures and refines information security requirements and ensures the integration of those requirements into information technology products and systems through purposeful security design or configuration. When available, organizations consider the use of information technology products that have been tested, evaluated, or validated by approved, independent, third-party assessment facilities. In addition, organizations satisfy, where applicable, minimum assurance requirements when implementing security controls. Assurance requirements are directed at the activities and actions that security control developers and implementers define and apply to increase the level of confidence that the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system. Assurance requirements address the quality of the design, development, and implementation of the security functions in the information system. For higher-impact systems (i.e., potential high-value targets) in situations where specific and credible threat information indicates the likelihood of advanced cyber-attacks, additional assurance measures are considered. Organizations consider any implementation-related issues associated with the integration and/or interfaces among common controls and system-specific controls.
For the identified common controls inherited by the information system, information system security engineers with support from information system security officers coordinate with the common control provider to determine the most appropriate way to apply the common controls to the organizational information systems. For certain management and operational controls, formal integration into information technology products, services, and systems may not be required. For certain types of operational and/or technical controls, implementation may require additional components, products, or services to enable the information system to utilize the previously selected common controls to the fullest extent. If selection of common controls previously had been deferred, identification of common controls inherited by the information system is revisited to determine if better determinations can be made at this point in the system development life cycle. Information system owners can refer to the authorization packages prepared by common control providers when making determinations regarding the adequacy of the implementations of common controls for their respective systems. For common controls that do not meet the protection needs of the information systems inheriting the controls or that have unacceptable weaknesses or deficiencies, the system owners identify compensating or supplementary controls to be implemented. Risk assessment may help determine how gaps in protection needs between systems and common controls affect the overall risk associated with the system, and how to prioritize the need for compensating or supplementary controls to mitigate specific risks. To the maximum extent and consistent with the flexibility allowed in applying the tasks in the RMF, organizations and their contractors conduct initial security control assessments (also referred to as developmental testing and evaluation) during information system development and implementation. Conducting security control assessments in parallel with the development and implementation phases of the system development life cycle facilitates the early identification of weaknesses and deficiencies and provides the most cost-effective method for initiating corrective actions. Issues found during these assessments can be referred to authorizing officials for early resolution, as appropriate. The results of the initial security control assessments can also be used during the security authorization process to avoid delays or costly repetition of assessments. Assessment results that are subsequently reused in other phases of the system development life cycle meet the reuse requirements (including independence) established by the organization.”3

Step 4 – assessment

The primary goal of this step is to assess and evaluate the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security objectives of the system. The objective of this step is as follows:
• Conduct evaluation of system security with the following questions answered:
• Are the controls:
- Implemented correctly?
- Operating as intended?
- Producing the desired outcome?
The security control assessment follows the approved plan, including defined procedures, to determine the effectiveness of the controls in meeting security requirements of the information system. The results are documented in the security assessment report.
The identified tasks for step 4 are as follows:
1. Develop, review, and approve a plan to assess the security controls.
2. Assess the security controls in accordance with the assessment procedures defined in the security assessment plan.
3. Prepare the security assessment report documenting the issues, findings, and recommendations from the security control assessment.
4. Conduct initial remediation actions on security controls based on the findings and recommendations of the security assessment report and reassess remediated control(s), as appropriate.
The guidance from the SP 800-37, rev. 1 gives additional insight to assessment: “Security control assessments determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system. Security control assessments occur as early as practicable in the system development life cycle, preferably during the development phase of the information system. These types of assessments are referred to as developmental testing and evaluation and are intended to validate that the required security controls are implemented correctly and consistent with the established information security architecture. Developmental testing and evaluation activities include, for example, design and code reviews, application scanning, and regression testing. Security weaknesses and deficiencies identified early in the system development life cycle can be resolved more quickly and in a much more cost-effective manner before proceeding to subsequent phases in the life cycle. The objective is to identify the information security architecture and security controls up front and to ensure that the system design and testing validate the implementation of these controls.
The information system owner relies on the technical expertise and judgment of assessors to:
(i) assess the security controls employed within or inherited by the information system using assessment procedures specified in the security assessment plan; and
(ii) provide specific recommendations on how to correct weaknesses or deficiencies in the controls and reduce or eliminate identified vulnerabilities. The assessor findings are an unbiased, factual reporting of the weaknesses and deficiencies discovered during the security control assessment.
Organizations are encouraged to maximize the use of automation to conduct security control assessments to help:
(i) increase the speed and overall effectiveness and efficiency of the assessments; and
(ii) support the concept of ongoing monitoring of the security state of organizational information systems.
When iterative development processes such as agile development are employed, this typically results in an iterative assessment as each cycle is conducted. A similar process is used for assessing security controls in COTS information technology products employed within the information system. Even when iterative development is not employed, organizations may choose to begin assessing security controls prior to the complete implementation of all security controls listed in the security plan. This type of incremental assessment is appropriate if it is more efficient or cost-effective to do so. For example, policy, procedures, and plans may be assessed prior to the assessment of the technical security controls in the hardware and software. In many cases, common controls (i.e., security controls inherited by the information system) may be assessed prior to the security controls employed within the system.
The organization ensures that assessors have access to:
(i) the information system and environment of operation where the security controls are employed; and
(ii) the appropriate documentation, records, artifacts, test results, and other materials needed to assess the security controls.
In addition, assessors have the required degree of independence as determined by the authorizing official. Security control assessments in support of initial and subsequent security authorizations are conducted by independent assessors. Assessor independence during continuous monitoring, although not mandated, facilitates reuse of assessment results when reauthorization is required. When security controls are provided to an organization by an external provider (e.g., through contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain arrangements), the organization ensures that assessors have access to the information system/environment of operation where the controls are employed as well as appropriate information needed to carry out the assessment. The organization also obtains any information related to existing assessments that may have been conducted by the external provider and reuses such assessment information whenever possible in accordance with the reuse criteria established by the organization. Descriptive information about the information system is typically documented in the system identification section of the security plan or included by reference or as attachments to the plan. Supporting materials such as procedures, reports, logs, and records showing evidence of security control implementation are identified as well. In order to make the risk management process as timely and cost-effective as possible, the reuse of previous assessment results, when reasonable and appropriate, is strongly recommended. For example, a recent audit of an information system may have produced information about the effectiveness of selected security controls. Another opportunity to reuse previous assessment results comes from programs that test and evaluate the security features of commercial information technology products. Additionally, if prior assessment results from the system developer are available, the security control assessor, under appropriate circumstances, may incorporate those results into the assessment. And finally, assessment results are reused to support reciprocity where possible.”4

Step 5 – authorization

The primary goal of this step is to authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the nation resulting from the operation of the information system and the decision that this risk is acceptable. The objective of this step is as follows:
• Obtain authority to operate approval for system.
The residual risks identified during the security control assessment are evaluated and the decision is made to authorize the system to operate, deny its operation, or remediate the deficiencies. Associated documentation is prepared and/or updated depending on the authorization decision.
The identified tasks for step 5 are as follows:
1. Prepare the plan of action and milestones based on the findings and recommendations of the security assessment report excluding any remediation actions taken.
2. Assemble the security authorization package and submit the package to the authorizing official for adjudication.
3. Determine the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the nation.
4. Determine if the risk to organizational operations, organizational assets, individuals, other organizations, or the nation is acceptable.
The guidance from the SP 800-37, rev. 1 gives additional insight to authorization: “The explicit acceptance of risk is the responsibility of the authorizing official and cannot be delegated to other officials within the organization. The authorizing official considers many factors when deciding if the risk to organizational operations (including mission, function, image, or reputation), organizational assets, individuals, other organizations, and the Nation, is acceptable. Balancing security considerations with mission and operational needs is paramount to achieving an acceptable authorization decision. The authorizing official issues an authorization decision for the information system and the common controls inherited by the system after reviewing all of the relevant information and, where appropriate, consulting with other organizational officials, including the organization’s risk executive (function). Security authorization decisions are based on the content of the security authorization package and, where appropriate, any inputs received from key organizational officials, including the risk executive (function). The authorization package provides relevant information on the security state of the information system including the ongoing effectiveness of the security controls employed within or inherited by the system. Inputs from the risk executive (function), including previously established overarching risk guidance to authorizing officials, provide additional organization-wide information to the authorizing official that may be relevant and affect the authorization decision (e.g., organizational risk tolerance, specific mission and business requirements, dependencies among information systems, and other types of risks not directly associated with the information system). Risk executive (function) inputs are documented and become part of the security authorization decision. Security authorization decisions, including inputs from the risk executive (function), are conveyed to information system owners and common control providers and made available to interested parties within the organization (e.g., information system owners and authorizing officials for interconnected systems, chief information officers, information owners/stewards, senior managers).
The authorization decision document conveys the final security authorization decision from the authorizing official to the information system owner or common control provider, and other organizational officials, as appropriate. The authorization decision document contains the following information:
(i) authorization decision;
(ii) terms and conditions for the authorization; and
(iii) authorization termination date.
The security authorization decision indicates to the information system owner whether the system is:
(i) authorized to operate; or
(ii) not authorized to operate.
The terms and conditions for the authorization provide a description of any specific limitations or restrictions placed on the operation of the information system or inherited controls that must be followed by the system owner or common control provider. The authorization termination date, established by the authorizing official, indicates when the security authorization expires. Authorization termination dates are influenced by federal and/or organizational policies which may establish maximum authorization periods. Organizations may choose to eliminate the authorization termination date if the continuous monitoring program is sufficiently robust to provide the authorizing official with the needed information to conduct ongoing risk determination and risk acceptance activities with regard to the security state of the information system and the ongoing effectiveness of security controls employed within and inherited by the system.
If the security control assessments are conducted by qualified assessors with the required degree of independence based on federal/organizational policies, appropriate security standards and guidelines, and the needs of the authorizing official, the assessment results can be cumulatively applied to the reauthorization, thus supporting the concept of ongoing authorization. Organizational policies regarding ongoing authorization and formal reauthorization, if/when required, are consistent with federal directives, regulations, and/or policies.
The authorization decision document is attached to the original security authorization package containing the supporting documentation and transmitted to the information system owner or common control provider. Upon receipt of the authorization decision document and original authorization package, the information system owner or common control provider acknowledges and implements the terms and conditions of the authorization and notifies the authorizing official. The organization ensures that authorization documents for both information systems and for common controls are made available to appropriate organizational officials (e.g., information system owners inheriting common controls, risk executive (function), chief information officers, senior information security officers, information system security officers). Authorization documents, especially information dealing with information system vulnerabilities, are:
(i) marked and appropriately protected in accordance with federal and organizational policies; and
(ii) retained in accordance with the organization’s record retention policy.
The authorizing official verifies, on an ongoing basis, that the terms and conditions established as part of the authorization are being followed by the information system owner or common control provider.”5

Step 6 – monitoring

The primary goal of this step is to monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.
The objectives of this step are as follows:
• Operate and maintain system security within acceptable risk tolerance.
• Update system securely and safely.
• Conduct mission successfully.
After an Authorization to Operate (ATO) is granted, ongoing continuous monitoring is performed on all identified security controls as well as the political, legal, and physical environment in which the system operates. Changes to the system or its operational environment are documented and analyzed. The security state of the system is reported to designated officials. Significant changes will cause the system to reenter the security authorization process. Otherwise, the system will continue to be monitored on an ongoing basis in accordance with the organization’s monitoring strategy.
The identified tasks for step 6 are as follows:
1. Determine the security impact of proposed or actual changes to the information system and its environment of operation.
2. Assess the technical, management, and operational security controls employed within and inherited by the information system in accordance with the organization-defined monitoring strategy.
3. Conduct remediation actions based on the results of ongoing monitoring activities, assessment of risk, and outstanding items in the plan of action and milestones.
4. Update the security plan, security assessment report, and plan of action and milestones based on the results of the continuous monitoring process.
5. Report the security status of the information system (including the effectiveness of security controls employed within and inherited by the system) to the authorizing official and other appropriate organizational officials on an ongoing basis in accordance with the monitoring strategy.
6. Review the reported security status of the information system (including the effectiveness of security controls employed within and inherited by the system) on an ongoing basis in accordance with the monitoring strategy to determine whether the risk to organizational operations, organizational assets, individuals, other organizations, or the nation remains acceptable.
7. Implement an information system disposal strategy, when needed, which executes required actions when a system is removed from service.
The guidance from the SP 800-37, rev. 1 gives additional insight to ongoing monitoring: “The authorizing official or designated representative reviews the reported security status of the information system (including the effectiveness of deployed security controls) on an ongoing basis, to determine the current risk to organizational operations and assets, individuals, other organizations, or the Nation. The authorizing official determines, with inputs as appropriate from the authorizing official designated representative, senior information security officer, and the risk executive (function), whether the current risk is acceptable and forwards appropriate direction to the information system owner or common control provider. The use of automated support tools to capture, organize, quantify, visually display, and maintain security status information promotes the concept of near real-time risk management regarding the overall risk posture of the organization. The use of metrics and dashboards increases an organization’s ability to make risk-based decisions by consolidating data from automated tools and providing it to decision makers at different levels within the organization in an easy-to-understand format. The risks being incurred may change over time based on the information provided in the security status reports. Determining how the changing conditions affect the mission or business risks associated with the information system is essential for maintaining adequate security. By carrying out ongoing risk determination and risk acceptance, authorizing officials can maintain the security authorization over time. Formal reauthorization actions, if required, occur only in accordance with federal or organizational policies. The authorizing official conveys updated risk determination and acceptance results to the risk executive (function).”6
The Risk Management Framework Authorization Package, as referenced above, has three required documents produced during the assessment and authorization process which are required to obtain an ATO for federal systems. These three documents are the System Security Plan (as defined in SP 800-18), Security Assessment Report (as defined in SP 800-37 and SP 800-53A), and the POAM (as defined in OMB Memorandum M02-01). The following diagram shows the RMF steps with the approximate steps where each of these documents are generated during the process:
image

Continuous Monitoring for Current Systems

The objective of a continuous monitoring program is to determine if the complete set of planned, required, and deployed security controls within an information system or inherited by the system continues to be effective over time in light of the inevitable changes that occur. In 2010, OMB issued guidance to US governmental agencies that continuous monitoring of security controls would now be required for all systems. This began the developmental process for the ongoing efforts to create, develop, and maintain a continuous monitoring program for each agency. NIST provided some guidance when they issued SP 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” in September 2011.
There are several different ISCM programs currently in deployment in various governmental agencies including the Continuous Diagnostic and Mitigation (CDM) effort from DHS and Continuous Monitoring Risk System (CMRS) from DISA in DOD. These efforts will continue to evolve over the next several years. As part of this effort, OMB and NIST are providing guidance and directions on moving to an event-driven authorization process known as Ongoing Authorization (OA) within agencies that have an active ISCM. Recent supplemental guidance to SP 800-37, rev. 1 provides this guidance and it is worth the effort to obtain this document and review it for your area of interest.