This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Industry:Project Review/NIST SP 800-37r1 FPD Chapter 3

From OWASP
Revision as of 05:27, 4 December 2009 by Dan Philpott (talk | contribs) (Initial add for GIC review of NIST SP 800-37r1 FPD)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CHAPTER THREE

THE PROCESS

EXECUTING THE RISK MANAGEMENT FRAMEWORK TASKS


This chapter describes the process of applying the Risk Management Framework (RMF) to federal information systems.<ref>The process for managing risk from information systems described in this publication can be tailored to meet the needs of many communities of interest within the federal government including, for example, the Civil, Defense, and Intelligence Communities. Tailoring provides flexibility in applying the concepts of the RMF in a manner that is most suitable for the organizations and the information systems involved.</ref> The process includes a set of well-defined risk-related tasks that are to be carried out by selected individuals or groups within the organization (e.g., risk executive (function), authorizing official, authorizing official designated representative, chief information officer, senior information security officer, enterprise architect, information security architect, information owner/steward, information system owner, common control provider, information system security officer, and security control assessor). The RMF extends beyond the organization to external providers (e.g., providers of security controls in external environments). Each RMF task description includes the individual or group with the primary responsibility for carrying out the task, the supporting roles that may be called upon to assist in completing the task, the system development life cycle phase most closely associated with the task, supplemental guidance to help explain how the task is executed, and appropriate references for publications or Web sites with information related to the task.

The RMF tasks can be applied at appropriate phases in the system development life cycle. While the tasks appear in sequential order, there can be many points in the risk management process that require divergence from the sequential order. For example, the results from security control assessments can trigger remediation actions on the part of an information system owner, which can in turn require the reassessment of selected controls. Monitoring the security controls in an information system can also generate a potential cycle of tracking changes to the system and its environment of operation, conducting security impact analyses, taking remediation actions, reassessing security controls, and reporting the security status of the system. There may also be other opportunities to diverge from the sequential nature of the tasks when it is more efficient or cost-effective to do so. For example, while the security control assessment tasks are listed after the security control implementation tasks, some organizations may choose to begin the assessment of certain controls as soon as they are implemented but prior to the complete implementation of all controls described in the security plan. This may result in the organization assessing the physical and environmental protection controls within a facility prior to assessing the security controls employed in the hardware and software components of the information system (which may be implemented at a later time).

The process of implementing the RMF tasks (i.e., the order and manner in which the tasks occur and are executed, the names of primary/supporting roles, the names and format of artifacts) may vary from organization to organization. The security categorization process influences the level of effort expended when implementing the RMF. Information systems supporting the most critical and/or sensitive operations and assets within the organization as indicated by the security categorization process, demand the greatest level of attention and effort to ensure that appropriate information security and risk mitigation are achieved. A summary table of the RMF tasks is provided in Appendix E.


APPLICATION OF THE RISK MANAGEMENT FRAMEWORK

The Risk Management Framework and associated RMF tasks apply to both information system owners and common control providers. In addition to supporting the authorization of information systems, the RMF tasks support the selection, development, implementation, assessment, authorization, and ongoing monitoring of common controls inherited by organizational information systems. Execution of the RMF tasks by common control providers, both internal and external to the organization, helps to ensure that the security capabilities provided by the common controls can be inherited by information system owners with a known degree of assurance. This approach recognizes the importance of security control effectiveness within information systems and the infrastructure supporting those systems.

Since the tasks in the RMF are described in a sequential manner, organizations may choose to deviate from that sequential structure in order to be consistent with their established management and system development life cycle processes or to achieve more cost-effective and efficient solutions with regard to the execution of the tasks. Regardless of the task ordering, the last step before an information system is placed into operation is the explicit acceptance of risk by the authorizing official. Organizations may also execute certain RMF tasks in an iterative manner or in different phases of the system development life cycle. For example, security control assessments may be carried out during system development, system implementation, and system operations/maintenance (as part of continuous monitoring).

Organizations may also choose to expend a greater level of effort on certain RMF tasks and commit fewer resources to other tasks based on the level of maturity of selected processes and activities within the organization. Since the RMF is life cycle based, there will be a need to revisit various tasks over time depending on how the organization manages changes to the information systems and the environments in which those systems operate. Managing information security-related risks for an information system is viewed as part of a larger enterprise-wide risk management activity that must be carried out by senior leaders. The RMF must simultaneously provide a disciplined and structured approach to mitigating risks from the operation and use of organizational information systems and the flexibility and agility to support the core missions and business operations of the organization in highly dynamic environments of operation.


3.1 RMF STEP 1 - CATEGORIZE INFORMATION SYSTEM

Task 1-1 - SECURITY CATEGORIZATION

SECURITY CATEGORIZATION


TASK 1-1: Categorize the information system and document the results of the security categorization in the security plan.

Primary Responsibility: Information System Owner; Information Owner/Steward.

Supporting Roles: Risk Executive (Function); Authorizing Official or Designated Representative; Chief Information Officer; Senior Information Security Officer; Information System Security Officer.

System Development Life Cycle Phase: System Initiation (concept/requirements definition).

Supplemental Guidance: 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 results of the security categorization process influence the selection of appropriate security controls for the information system and also the minimum assurance requirements for that system. 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. The risk executive (function) provides guidance and relevant information to authorizing officials concerning the risk management strategy for the organization (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). Security categorization determinations consider potential adverse impacts to organizational operations, organizational assets, individuals, other organizations, and the Nation.

References: FIPS Publication 199; NIST Special Publications 800-18, 800-30, 800-39, 800-60; CNSS Instruction 1253.

Task 1-2 - INFORMATION SYSTEM DESCRIPTION

INFORMATION SYSTEM DESCRIPTION


TASK 1-2: Describe the information system (including system boundary) and document the description in the security plan.

Primary Responsibility: Information System Owner.

Supporting Roles: Authorizing Official or Designated Representative; Senior Information Security Officer; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Initiation (concept/requirements definition).

Supplemental Guidance: Descriptive information about the information system is documented in the system identification section of the security plan, included in attachments to the plan, or referenced in other standard sources for information generated as part of the system development life cycle. System identification information can also be provided by reference. The level of detail provided in the security plan is determined by the organization and is typically commensurate with the security categorization of the information system. Information may be added to the system description as it becomes available during the system development life cycle and execution of the RMF tasks. A typical system description may include, for example:

- Full descriptive name of the information system including associated acronym;
- Unique information system identifier (typically a number or code);
- Information system owner and authorizing official including contact information;
- Parent or governing organization that manages, owns, and/or controls the information system;
- Location of the information system and environment in which the system operates;
- Version or release number of the information system;
- Purpose, functions, and capabilities of the information system and missions/business processes supported;
- How the information system is integrated into the enterprise architecture and information security architecture.
- Status of the information system with respect to acquisition and/or system development life cycle;
- Results of the security categorization process for the information and information system;
- Identification and functional summary of common controls inherited from common control providers;
- How hybrid security controls are derived from system-specific and common controls;
- Types of information processed, stored, and transmitted by the information system;
- Boundary of the information system for risk management and security authorization purposes;
- Applicable laws, directives, policies, regulations, or standards affecting the security of the information system;
- Architectural description of the information system including network topology;
- Hardware and firmware devices included within the information system;
- System and applications software resident on the information system;
- Hardware, software, and system interfaces (internal and external);
- Information flows and paths (including inputs and outputs) within the information system;
- Cross domain devices/requirements;
- Network connection rules for communicating with external information systems;
- Interconnected information systems and identifiers for those systems;
- Encryption techniques used for information processing, transmission, and storage;
- Cryptographic key management information (public key infrastructures, certificate authorities, etc.);
- Information system users (including organizational affiliations, access rights, privileges, citizenship, if applicable);
- Ownership/operation of information system (e.g., government-owned, government-operated; government-owned, contractor-operated; contractor-owned, contractor-operated; nonfederal (state and local governments, grantees);
- Security authorization date and authorization termination date (if applicable);
- Incident response points of contact; and
- Other information as required by the organization.

References: NIST Special Publication 800-18.

Task 1-3 - INFORMATION SYSTEM REGISTRATION

INFORMATION SYSTEM REGISTRATION


TASK 1-3: Register the information system with appropriate organizational program/management offices.

Primary Responsibility: Information System Owner.

Supporting Roles: Information System Security Officer.

System Development Life Cycle Phase: System Initiation (concept/requirements definition).

Supplemental Guidance: The registration process begins by identifying the information system (and subsystems, if appropriate) in the system inventory and establishes a relationship between the information system and the parent or governing organization that owns, manages, and/or controls the system. Registration, either formal or informal in accordance with organizational policy, uses information in the system identification section of the security plan to inform the parent or governing organization of: (i) the existence of the information system; (ii) the key characteristics of the system; and (iii) any security implications for the organization due to the ongoing operation of the system. Information system registration provides organizations with an effective management/tracking tool that is necessary for security status reporting in accordance with applicable laws, Executive Orders, directives, policies, standards, guidance, or regulations. Those subsystems that are more dynamic in nature (e.g., subsystems in net-centric architectures) may not be present throughout all phases of the system development life cycle. For such subsystems, it may not be possible to complete all registration information. Some information about dynamic subsystems is known prior to the subsystem manifesting itself in the information system (e.g., assumptions and constraints specified in the security plan). However, more detailed information may not be known until the subsystem manifests itself.

References: None.


Milestone Checkpoint #1

 
- Has the organization completed a security categorization of the information system including the information to be processed, stored, and transmitted by the system?
- Are the results of the security categorization process for the information system consistent with the organization's enterprise architecture and commitment to protecting organizational mission/business processes?
- Do the results of the security categorization process reflect the organization's risk management strategy?
- Has the organization adequately described the characteristics of the information system?
- Has the organization registered the information system for purposes of management, accountability, and oversight?


3.2 RMF STEP 2 - SELECT SECURITY CONTROLS

Task 2-1 - SECURITY CONTROL SELECTION

SECURITY CONTROL SELECTION


TASK 2-1: Select the security controls for the information system and document the controls in the security plan.

Primary Responsibility: Information Security Architect; Information System Owner.

Supporting Roles: Authorizing Official or Designated Representative; Information Owner/Steward; Information System Security Officer; Information System Security Engineer.

System Development Life Cycle Phase: System Initiation (requirements definition).

Supplemental Guidance: The security controls are selected based on the security categorization of the information system. The selection process includes, as appropriate: (i) tailoring the baseline security controls by applying scoping, parameterization, and compensating control guidance; (ii) supplementing the tailored baseline security controls, if necessary, with additional controls or control enhancements to address unique organizational needs based on a risk assessment (either formal or informal) and local conditions including environment of operation, organization-specific security requirements, specific threat information, cost-benefit analyses, or special circumstances; and (iii) specifying minimum assurance requirements. 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 list the controls in their respective security plans or reference the controls contained in the security plans of the common control providers (see Task 2.2). 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 exchanges), 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 large and complex information system (or system of systems) 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.

References: FIPS Publications 199, 200; NIST Special Publications 800-18, 800-30, 800-53; CNSS Instruction 1253.

Task 2-2 - COMMON CONTROL IDENTIFICATION

COMMON CONTROL IDENTIFICATION


TASK 2-2: 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).

Primary Responsibility: Chief Information Officer or Senior Information Security Officer; Information Security Architect; Common Control Provider.

Supporting Roles: Risk Executive (Function); Authorizing Official or Designated Representative; Information System Owner; Information System Security Engineer.

System Development Life Cycle Phase: System Initiation (concept/requirements definition).

Supplemental Guidance: Common controls are identified by the chief information officer and/or senior information security officer in collaboration with the information security architect and assigned to specific organizational entities (designated as common control providers) for development, implementation, assessment, and monitoring. Common control providers may also be information system owners when the common controls are resident within an information system. Organizations determine the appropriate baseline (low, moderate, or high) for common controls inherited by information systems within the organization. The organization consults information system owners inheriting common controls when considering baseline selection to ensure that the security capability provided by the controls is sufficient to deliver adequate protection. When employing common controls in information systems with higher baselines than those of the common controls, information system owners supplement the common controls with system-specific or hybrid controls to achieve the required protection for the system and/or accept greater risk. Information system owners inheriting common controls can either list the controls in their respective security plans or reference the controls contained in the security plan of the common control provider. Organizations may choose to defer common control identification and security control selection until later in the system development life cycle. When common controls are not resident within an information system (e.g., physical and environmental protection controls, personnel security controls), the organization selects one or more senior organizational officials or executives to serve as authorizing officials for those controls. These authorizing officials are responsible for accepting the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the deployment of the security controls provided by common control providers and inherited by organizational information systems. Common control providers are responsible for: (i) documenting common controls and associated baseline in a security plan (or equivalent document prescribed by the organization); (ii) ensuring that common controls are developed, implemented, and assessed for effectiveness by qualified assessors with a level of independence required by the organization; (iii) documenting assessment findings in a security assessment report; (iv) producing a plan of action and milestones for all common controls deemed less than effective (i.e., having unacceptable weaknesses or deficiencies in the controls); (v) receiving authorization for the common controls from the designated authorizing official; and (vi) monitoring common control effectiveness on an ongoing basis.

Security plans, security assessment reports, and plans of action and milestones for common controls (or a summary of such information) are made available to information system owners (whose systems are inheriting the controls) after the information is reviewed and approved by the senior official or executive responsible and accountable for the controls. The organization ensures that common control providers keep this information current since the controls typically support multiple organizational information systems. Security plans, security assessment reports, and plans of action and milestones for common controls are used by authorizing officials within the organization to make risk-based decisions in the security authorization process for their information systems. The use of common controls is documented within the security plans for information systems inheriting those controls. However, that information is inadequate when common control providers have to rapidly broadcast changes in the status of common controls that negatively effects the protections being provided by and expected of the common controls. For this reason, the organization maintains records of the specific common controls used in each organizational information system. This enables common control providers to rapidly inform information system owners when problems arise in the inherited common controls (e.g., when an assessment or reassessment of a common control indicates the control is flawed in some manner, when a new threat or attack method arises that renders the common control less than adequate in protecting against the new threat or attack method). If common controls are provided to the organization (and its information systems) by entities external to the organization (e.g., shared and/or external service providers), arrangements are made with the external/shared service providers by the organization to obtain information on the effectiveness of the deployed controls. Information obtained from external organizations regarding the effectiveness of common controls is factored into authorization decisions.

References: FIPS Publications 199, 200; NIST Special Publications 800-18, 800-30, 800-53; CNSS Instruction 1253.

Task 2-3 - MONITORING STRATEGY

MONITORING STRATEGY


TASK 2-3: Develop a strategy for the continuous monitoring of security control effectiveness and any proposed/actual changes to the information system and its environment of operation.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Risk Executive (Function); Authorizing Official or Designated Representative; Chief Information Officer; Senior Information Security Officer; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Initiation (concept/requirements definition).

Supplemental Guidance: A critical aspect of risk management is the ongoing monitoring of security controls employed within or inherited by the information system. An effective monitoring strategy is developed early in the system development life cycle (i.e., during system design or COTS procurement decision) and can be included in the security plan. The implementation of a robust continuous monitoring program allows an organization to understand the security state of the information system over time and maintain the initial security authorization in a highly dynamic environment of operation with changing threats, vulnerabilities, technologies, and missions/business functions. The ongoing monitoring of security controls using automated tools and supporting databases facilitates near real-time risk management for the information system. An effective monitoring program includes:

  • Configuration management and control processes;
  • Security impact analyses on actual or proposed changes to the information system and its environment of operation;
  • Assessment of selected security controls employed within and inherited by the information system (including controls in dynamic subsystems); and
  • Security status reporting to appropriate organizational officials.

The criteria for selecting security controls to be monitored post deployment and for determining the frequency of such monitoring is established by the information system owner or common control provider in collaboration with selected organizational officials including, for example, the authorizing official or designated representative, chief information officer, senior information security officer, and risk executive (function). In many cases, the approach for monitoring security controls may be a continuation of the control assessments conducted during system development and prior to deployment. The selection criteria reflect the priorities and importance of the information system to organizational operations and assets, individuals, other organizations, and the Nation. Security controls that are volatile (i.e., most likely to change over time), critical to certain aspects of the organization's protection strategy, or identified in current plans of action and milestones are assessed as frequently as necessary consistent with the criticality of the function and capability of the monitoring tools. The use of automation facilitates a greater frequency and volume of security control assessments. Determining the frequency for assessing security controls inherited by the information system (i.e., common controls) includes the organization's determination of the trustworthiness of the common control provider. An organizational assessment of risk (either formal or informal) can also be used to guide the selection of specific security controls to be monitored and the frequency of such monitoring.

The authorizing official or designated representative and the senior information security officer approve the monitoring strategy including the set of security controls that are to be monitored on an ongoing basis as well as the frequency of the monitoring activities. The approval of the monitoring strategy can be obtained in conjunction with the security plan approval. The monitoring of security controls continues throughout the system development life cycle. For security controls employed in information systems with dynamic subsystems, the monitoring strategy accounts for subsystems that did not exist at the beginning of the system development life cycle. An effective monitoring strategy for dynamic subsystems achieves an appropriate balance with regard to risk by: (i) not placing unnecessary or unrealistic burdens on the organization by requiring reauthorization of the information system each time a new subsystem is added or removed; and (ii) not compromising the accepted security posture of the overall system.

References: NIST Special Publications 800-30, 800-39, 800-53; 800-53A; CNSS Instruction 1253.

Task 2-4 - SECURITY PLAN APPROVAL

SECURITY PLAN APPROVAL


TASK 2-4: Review and approve the security plan.

Primary Responsibility: Authorizing Official or Designated Representative.

Supporting Roles: Risk Executive (Function); Chief Information Officer; Senior Information Security Officer.

System Development Life Cycle Phase: System Development/Acquisition.

Supplemental Guidance: The independent review of the security plan by the authorizing official or designated representative with support from the senior information security officer, chief information officer, and risk executive (function), helps determine if the plan is complete, consistent, and satisfies the stated security requirements for the information system. The security plan review also helps to determine, to the greatest extent possible with available planning or operational documents, if the security plan correctly and effectively identifies the potential risk to organizational operations and assets, individuals, other organizations, and the Nation, that would be incurred if the controls identified in the plan were implemented as intended. Based on the results of this independent review and analysis, the authorizing official or designated representative, chief information officer, senior information security officer, or risk executive (function) may recommend changes to the security plan. If the security plan is deemed unacceptable, the authorizing official or designated representative sends the plan back to the information system owner (or common control provider) for appropriate action. If the security plan is deemed acceptable, the authorizing official or designated representative accepts the plan. The acceptance of the security plan represents an important milestone in the risk management process. The authorizing official or designated representative, by accepting the security plan, agrees to the set of security controls (system-specific, hybrid, and/or common controls) proposed to meet the security requirements for the information system. This agreement allows the risk management process to advance to the next step in the RMF (i.e., the implementation of the security controls). The acceptance of the security plan also approves the level of effort required to successfully complete the remainder of the steps in the RMF and also provides the basis of the security specification for the acquisition of the information system, subsystems, or components.

References: NIST Special Publications 800-18, 800-30, 800-53; CNSS Instruction 1253.


Milestone Checkpoint #2

 
- Has the organization allocated all security controls to the information system as system-specific, hybrid, or common controls?
- Has the organization identified authorizing officials for the information system and all common controls inherited by the system?
- Has the organization tailored and supplemented the [1] to the information system as system-specific, hybrid, or common controls?
- Has the organization identified authorizing officials for the information system and all common controls inherited by the system?
- Has the organization tailored and supplemented the baseline security controls to ensure that the controls, if implemented, adequately mitigate risks to organizational operations and assets, individuals, other organizations, and the Nation?
- Has the organization addressed minimum assurance requirements for the security controls employed within and inherited by the information system?
- Has the organization approved the security control baseline for the common controls inherited by the information system?
- Has the organization supplemented the common controls with system-specific or hybrid controls when the security control baselines of the common controls are less than those of the information system inheriting the controls?
- Has the organization developed a continuous monitoring strategy for the information system (including monitoring of security control effectiveness for system-specific, hybrid, and common controls) that reflects the organizational risk management strategy and organizational commitment to protecting critical missions and business functions?
- Have appropriate organizational officials approved security plans containing system-specific, hybrid, and common controls?


3.3 RMF STEP 3 - IMPLEMENT SECURITY CONTROLS

Task 3-1 - SECURITY CONTROL IMPLEMENTATION

SECURITY CONTROL IMPLEMENTATION


TASK 3-1: Implement the security controls specified in the security plan.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information Owner/Steward; Information System Security Officer; Information System Security Engineer.

System Development Life Cycle Phase: System Development/Acquisition; System Implementation.

Supplemental Guidance: 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. 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. 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 their integration 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 minimum assurance requirements when implementing security controls. 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 also 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 (or their designee) 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. For common controls that have unacceptable weaknesses or deficiencies or that are not designed for the security categorization associated with the information system inheriting the controls, the system owner identifies compensating or supplementary controls to be implemented.

References: FIPS Publication 200; NIST Special Publications 800-27, 800-30, 800-53, 800-70; CNSS Instruction 1253; Web: SCAP.NIST.GOV.

Task 3-2 - SECURITY CONTROL DOCUMENTATION

SECURITY CONTROL DOCUMENTATION


TASK 3-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).

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information Owner/Steward; Information System Security Officer; Information System Security Engineer.

System Development Life Cycle Phase: System Development/Acquisition; System Implementation.

Supplemental Guidance: Security control documentation describes how system-specific, hybrid, and common controls are implemented. The documentation formalizes plans and expectations regarding the overall functionality of the information system. Documentation of security control implementation allows for traceability of decisions taken prior to and after deployment of the information system. The level of effort expended on documentation of the information system is commensurate with the purpose, scope, and impact of the system with respect to organizational missions, business functions, and operations. To the extent possible, organizations reference existing documentation (either by vendors or other organizations that have employed the same or similar information systems), use automated support tools, and maximize communications to increase the overall efficiency and cost effectiveness of security control implementation. The documentation also addresses platform dependencies and includes any additional information necessary to describe how the security capability required by the security control is achieved at level of detail sufficient to support control assessment. Documentation for security control implementation follows best practices for hardware and software development as well as for system/security engineering disciplines and is consistent with established organizational policies and procedures for documenting system development life cycle activities. Whenever possible and practicable for technical security controls that are mechanism-based, organizations take maximum advantage of functional specifications provided by or obtainable from hardware and software vendors and/or systems integrators including security-relevant documentation that may assist the organization during the assessment and monitoring of the controls. Similarly, for management and operational controls, organizations obtain security control implementation information from appropriate organizational entities (e.g., facilities offices, human resource offices, physical security offices). Since the enterprise architecture and information security architecture established by the organization significantly influence the approach used to implement security controls, providing documentation of this process helps to ensure traceability with regard to meeting the organization's information security requirements.

References: NIST Special Publications 800-18, 800-53.


Milestone Checkpoint #3

 
- Has the organization allocated security controls as system-specific, hybrid, or common controls consistent with the enterprise architecture and information security architecture?
- Has the organization demonstrated the use of sound information system and security engineering methodologies in integrating information technology products into the information system and in implementing the security controls contained in the security plan?
- Has the organization documented how common controls inherited by organizational information systems have been implemented?
- Has the organization documented how system-specific and hybrid security controls have been implemented within the information system taking into account specific technologies and platform dependencies?
- Has the organization taken into account the minimum assurance requirements when implementing security controls?


3.4 RMF STEP 4 - ASSESS SECURITY CONTROLS

Task 4-1 - ASSESSMENT PREPARATION

ASSESSMENT PREPARATION


TASK 4-1: Develop, review, and approve a plan to assess the security controls.

Primary Responsibility: Security Control Assessor.

Supporting Roles: Authorizing Official or Designated Representative; Chief Information Officer; Senior Information Security Officer; Information System Owner or Common Control Provider; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The security assessment plan provides the objectives for the security control assessment and a detailed roadmap of how to conduct such an assessment including the use of automation, where appropriate. The assessment plan reflects the type of assessment the organization is conducting (e.g., security control assessments in support of initial information system authorizations, ongoing security control monitoring, assessments subsequent to remediation actions). The security assessment plan is reviewed and approved by appropriate organizational officials to ensure that the plan is consistent with the security objectives of the organization, employs state-of-the practice tools, techniques, procedures, and automation to support the concept of continuous monitoring and near real-time risk management, and is cost-effective with regard to the resources allocated for the assessment. The purpose of the security assessment plan approval is two-fold: (i) to establish the appropriate expectations for the security control assessment; and (ii) to bound the level of effort for the security control assessment. An approved security assessment plan helps to ensure that an appropriate level of resources is applied toward determining security control effectiveness. 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 exchanges), the organization obtains a security assessment plan from the provider.

Organizations consider both the technical expertise and level of independence required in selecting security control assessors. An independent assessor is any individual or group capable of conducting an impartial assessment of security controls employed within or inherited by an information system. Impartiality implies that assessors are free from any perceived or actual conflicts of interest with respect to the development, operation, and/or management of the information system or the determination of security control effectiveness. Independent security control assessment services can be obtained from other elements within the organization or can be contracted to a public or private sector entity outside of the organization. Contracted assessment services are considered independent if the information system owner is not directly involved in the contracting process or cannot unduly influence the independence of the assessor(s) conducting the assessment of the security controls. The authorizing official or designated representative determines the required level of independence for security control assessors based on the results of the security categorization process for the information system and the ultimate risk to organizational operations and assets, individuals, other organizations, and the Nation. The authorizing official determines if the level of assessor independence is sufficient to provide confidence that the assessment results produced are sound and can be used to make a credible, risk-based decision on whether to place the information system into operation or continue its operation. In special situations, for example when the organization that owns the information system is small or the organizational structure requires that the security control assessment be accomplished by individuals that are in the developmental, operational, and/or management chain of the system owner or authorizing official, independence in the assessment process can be achieved by ensuring that the assessment results are carefully reviewed and analyzed by an independent team of experts to validate the completeness, consistency, and veracity of the results. The authorizing official consults with the Office of the Inspector General, the senior information security officer, and the chief information officer to fully discuss the implications of any decisions on assessor independence in the types of special circumstances described above.

Organizations also ensure that security control assessors possess the required technical skills and expertise to successfully carry out assessments of system-specific, hybrid, and common controls. This includes knowledge of and experience with the specific hardware, software, and firmware components employed by the organization to host technical controls (e.g., access controls, auditing and accountability controls, identification and authentication controls, system and communications protection controls).

References: NIST Special Publication 800-53A.

Task 4-2 - SECURITY CONTROL ASSESSMENT

SECURITY CONTROL ASSESSMENT


TASK 4-2: Assess the security controls in accordance with the assessment procedures defined in the security assessment plan.

Primary Responsibility: Security Control Assessor.<ref>At the discretion of the organization, security control assessors may be given additional duties or responsibilities for the post-processing and analysis of security control assessment findings and results, including for example, making specific recommendations and determinations to authorizing officials (also known as certification recommendations or certification determinations).</ref>

Supporting Roles: Information System Owner or Common Control Provider; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: 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. 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 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 strongly 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 allowed 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 the assessor has 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. 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 exchanges), 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 be 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, in some cases, 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. And finally, if prior assessment results from the system developer are available, the security control assessor, under appropriate circumstances, may incorporate those results into the assessment.

References: NIST Special Publication 800-53A.

Task 4-3 - SECURITY ASSESSMENT REPORT

SECURITY ASSESSMENT REPORT


TASK 4-3: Prepare the security assessment report documenting the issues, findings, and recommendations from the security control assessment.

Primary Responsibility: Security Control Assessor.

Supporting Roles: Information System Owner or Common Control Provider; Information System Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The results of the security control assessment, including recommendations for correcting any weaknesses or deficiencies in the controls, are documented in the security assessment report. The security assessment report is one of three key documents in the security authorization package developed for authorizing officials. The assessment report includes information from the assessor necessary to determine the effectiveness of the security controls employed within or inherited by the information system based upon the assessor's findings. The security assessment report is an important factor in an authorizing official's determination of risk to organizational operations and assets, individuals, other organizations, and the Nation. Security control assessment results are documented at a level of detail appropriate for the assessment in accordance with the reporting format prescribed by organizational and/or federal policies. The reporting format is also appropriate for the type of security control assessment conducted (e.g., self-assessments, independent verification and validation, independent assessments supporting the security authorization process, or independent audits/evaluations). Security control assessment results obtained during system development are brought forward in an interim report and included in the final security assessment report. This supports the concept that the security assessment report is an evolving document that includes assessment results from all relevant phases of the system development life cycle including the results generated during continuous monitoring. Organizations may choose to develop an executive summary from the detailed findings that are generated during a security control assessment. An executive summary provides an authorizing official with an abbreviated version of the assessment report focusing on the highlights of the assessment, synopsis of key findings, and/or recommendations for addressing weaknesses and deficiencies in the security controls.

References: NIST Special Publication 800-53A.


Milestone Checkpoint #4

 
- Has the organization developed a comprehensive plan to assess the security controls employed within or inherited by the information system?
- Was the assessment plan reviewed and approved by appropriate organizational officials?
- Has the organization considered the appropriate level of assessor independence for the security control assessment?
- Has the organization provided all of the essential supporting assessment-related materials needed by the assessor(s) to conduct an effective security control assessment?
- Did the assessor(s) complete the security control assessment in accordance with the stated assessment plan?
- Did the organization receive the completed security assessment report with appropriate findings and recommendations from the assessor(s)?


3.5 RMF STEP 5 - AUTHORIZE INFORMATION SYSTEM

Task 5-1 - REMEDIATION ACTIONS

REMEDIATION ACTIONS


TASK 5-1: Conduct initial remediation actions based on the findings and recommendations of the security assessment report.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Authorizing Official or Designated Representative; Chief Information Officer; Senior Information Security Officer; Information Owner/Steward; Information System Security Officer; Information System Security Engineer; Security Control Assessor.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The security assessment report provides visibility into specific weaknesses and deficiencies in the security controls employed within or inherited by the information system that could not reasonably be resolved during system development. The findings generated during the security control assessment facilitate a disciplined and structured approach to mitigating risks in accordance with organizational priorities. Information system owners and common control providers, in collaboration with selected organizational officials (e.g., information system security engineer, authorizing official designated representative, chief information officer, senior information security officer, information owner/steward), may decide that certain findings are inconsequential and present no significant risk to the organization. Alternatively, the organizational officials may decide that certain findings are in fact, significant, requiring immediate remediation actions. In all cases, organizations review assessor findings and determine the severity or seriousness of the findings (i.e., the potential adverse impact on organizational operations and assets, individuals, other organizations, or the Nation) and whether the findings are sufficiently significant to be worthy of further investigation or remediation. An updated assessment of risk based on the results of the findings produced during the security control assessment and any inputs from the risk executive (function), helps to determine the initial remediation actions and the prioritization of such actions. Senior leadership involvement in the mitigation process may be necessary in order to ensure that the organization's resources are effectively allocated in accordance with organizational priorities, providing resources first to the information systems that are supporting the most critical and sensitive missions and business functions for the organization or correcting the deficiencies that pose the greatest degree of risk. If weaknesses or deficiencies in security controls are corrected, the remediated controls are reassessed for effectiveness. Security control assessments determine the extent to which the remediated controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system. The security plan is updated based on the findings of the security control assessment and any remediation actions taken. The updated security plan reflects the actual state of the security controls after the initial assessment and any modifications by the information system owner or common control provider in addressing recommendations for corrective actions. At the completion of the assessment, the security plan contains an accurate list and description of the security controls implemented (including compensating controls) and a list of residual vulnerabilities.

Organizations can prepare an optional addendum to the security assessment report that is transmitted to the authorizing official. The optional addendum provides information system owners and common control providers an opportunity to respond to the initial findings of assessors. The addendum may include, for example, information regarding initial remediation actions taken by information system owners or common control providers in response to assessor findings, or provide an owner's perspective on the findings (e.g., including additional explanatory material, rebutting certain findings, and correcting the record). The addendum to the security assessment report does not change or influence in any manner, the initial assessor findings provided in the original report. Information provided in the addendum is considered by authorizing officials in their risk-based authorization decisions. Organizations may choose to employ an issue resolution process to help determine the appropriate actions to take with regard to the security control weaknesses and deficiencies identified during the assessment. Issue resolution can help address vulnerabilities and associated risk, false positives, and other factors that may provide useful information to authorizing officials regarding the security state of the information system including the ongoing effectiveness of system-specific, hybrid, and common controls. The issue resolution process can also help to ensure that only substantive items are identified and transferred to the plan of actions and milestones.

References: NIST Special Publications 800-18, 800-30, 800-53A.

Task 5-2 - PLAN OF ACTION AND MILESTONES

PLAN OF ACTION AND MILESTONES


TASK 5-2: Prepare the plan of action and milestones based on the findings and recommendations of the security assessment report excluding any remediation actions taken.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The plan of action and milestones, prepared for the authorizing official by the information system owner or the common control provider, is one of three key documents in the security authorization package and describes the specific tasks that are planned: (i) to correct any weaknesses or deficiencies in the security controls noted during the assessment; and (ii) to address the residual vulnerabilities in the information system. The plan of action and milestones identifies: (i) the tasks to be accomplished with a recommendation for completion either before or after information system implementation; (ii) the resources required to accomplish the tasks; (iii) any milestones in meeting the tasks; and (iv) the scheduled completion dates for the milestones. The plan of action and milestones is used by the authorizing official to monitor progress in correcting weaknesses or deficiencies noted during the security control assessment. Plan of action and milestones entries are not required when weaknesses or deficiencies identified during the security control assessment are: (i) adequately addressed through specific remediation actions; (ii) determined to be insignificant; or (iii) deemed to be acceptable risks in accordance with the organizational risk management strategy. The plan of action and milestones is not used to intentionally delay the implementation of essential security controls for the information system or to inflate the requirements for security capabilities that are not consistent with the overall goals and objectives of the organization including its strategy for managing risk.

Organizations define a strategy for developing plans of action and milestones that facilitates a prioritized approach to risk mitigation that is consistent across the organization. The strategy helps to ensure that organizational plans of action and milestones are based on:

  • The security categorization of the information system;
  • The specific weaknesses or deficiencies in the security controls;
  • The importance of the identified security control weaknesses or deficiencies (i.e., the direct or indirect effect the weaknesses or deficiencies may have on the overall security state of the information system, and hence on the risk exposure of the organization, or ability of the organization to perform its mission or business functions); and
  • The organization's proposed risk mitigation approach to address the identified weaknesses or deficiencies in the security controls (e.g., prioritization of risk mitigation actions, allocation of risk mitigation resources).

References: OMB Memorandum 02-01; NIST Special Publications 800-30, 800-53A.

Task 5-3 - SECURITY AUTHORIZATION PACKAGE

SECURITY AUTHORIZATION PACKAGE


TASK 5-3: Assemble the security authorization package and submit the package to the authorizing official for adjudication.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information System Security Officer; Security Control Assessor.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The security authorization package contains: (i) the security plan; (ii) the security assessment report; and (iii) the plan of action and milestones. The information in these key documents is used by authorizing officials to make credible, risk-based authorization decisions. For information systems inheriting common controls for specific security capabilities, the security authorization package for the common controls or a reference to such documentation is also included in the authorization package. 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 exchanges), the organization ensures that the information needed for authorizing officials to make credible, risk-based decisions, is made available by the provider. Additional information can be included in the security authorization package at the request of the authorizing official carrying out the authorization action. The contents of the security authorization package are protected appropriately in accordance with federal and organizational policies. Organizations are strongly encouraged to use automated support tools in preparing and managing the content of the security authorization package to help provide an effective vehicle for maintaining and updating critical information for authorizing officials regarding the ongoing security status of information systems within the organization. Providing orderly, disciplined, and timely updates to the security plan, security assessment report, and plan of action and milestones on an ongoing basis, supports the concept of near real-time risk management and ongoing authorization. It also facilitates more cost-effective and meaningful reauthorization actions, if required. With the use of automated tools and supporting databases, authorizing officials and other senior leaders within the organization are able to maintain awareness with regard to the security state of the information system including the ongoing effectiveness of system-specific, hybrid, and common controls.

References: None.

Task 5-4 - RISK DETERMINATION

RISK DETERMINATION


TASK 5-4: Determine the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation.

Primary Responsibility: Authorizing Official or Designated Representative.

Supporting Roles: Risk Executive (Function); Senior Information Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: The authorizing official or designated representative, in collaboration with the senior information security officer, assesses the information provided by the information system owner or common control provider regarding the current security state of the system or the common controls inherited by the system and the recommendations for addressing any residual risks. Risk assessments may be updated to provide information on threats, vulnerabilities, and potential impacts and the analyses for the risk mitigation recommendations. The risk executive (function) also provides information to the authorizing official that is considered in the final determination of risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation and use of the information system. Risk-related information includes the criticality of organizational missions and/or business functions supported by the information system and the risk management strategy for the organization. The risk management strategy typically describes: (i) how risk is assessed within the organization (i.e., tools, techniques, procedures, and methodologies); (ii) how assessed risks are evaluated with regard to severity or criticality; (iii) known existing aggregated risks from organizational information systems and other sources; (iv) risk mitigation approaches; (v) organizational risk tolerance; and (vi) how risk is monitored over time. When making the final risk determination, the authorizing official or designated representative considers information obtained from the risk executive (function) and the information provided by the information system owner or common control provider in the security authorization package (i.e., security plan, security assessment report, and plan of action and milestones). Conversely, information system-related security risk information derived from the execution of the RMF is available to the risk executive (function) for use in formulating and updating the organization-wide risk management strategy.

References: NIST Special Publications 800-30, 800-39.

Task 5-5 - RISK ACCEPTANCE

RISK ACCEPTANCE


TASK 5-5: Determine if the risk to organizational operations, organizational assets, individuals, other organizations, or the Nation is acceptable.

Primary Responsibility: Authorizing Official.

Supporting Roles: Risk Executive (Function); Authorizing Official Designated Representative; Senior Information Security Officer.

System Development Life Cycle Phase: System Implementation.

Supplemental Guidance: 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 key 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 transmits the final security authorization decision from the authorizing official to the information system owner or common control provider, and other key organizational officials, as appropriate. The authorization decision document contains the following information:

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. 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. However, organizational policies regarding ongoing authorization and formal reauthorization, if required, must be 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 accepts the terms and conditions of the authorization. The authorizing official documents the acceptance of the terms and conditions of the authorization. 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.

References: None.


Milestone Checkpoint #5

 
- Did the organization take the necessary remediation actions to address the most important weaknesses and deficiencies in the information system and its environment of operation based on the findings and recommendations in the security assessment report?
- Did the organization update appropriate security plans based on the findings and recommendations in the security assessment report and any subsequent changes to the information system and its environment of operation?
- Did the organization develop a plan of action and milestones reflecting organizational priorities for addressing the remaining weaknesses and deficiencies in the information system and its environment of operation?
- Did the final risk determination and risk acceptance by the authorizing official reflect the risk management strategy developed by the organization and conveyed by the risk executive (function)?
- Was the authorization decision conveyed to appropriate organizational personnel including information system owners and common control providers?


3.6 RMF STEP 6 - MONITOR SECURITY CONTROLS

Task 6-1 - INFORMATION SYSTEM AND ENVIRONMENT CHANGES

INFORMATION SYSTEM AND ENVIRONMENT CHANGES


TASK 6-1: Determine the security impact of proposed or actual changes to the information system and its environment of operation.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Risk Executive (Function); Authorizing Official or Designated Representative; Senior Information Security Officer; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: Information systems are in a constant state of change with upgrades to hardware, software, or firmware and modifications to the surrounding environments where the systems reside and operate. A disciplined and structured approach to managing, controlling, and documenting changes to an information system or its environment of operation is an essential element of an effective security control monitoring program. Strict configuration management and control processes are established by the organization to support such monitoring activities. It is important to record any relevant information about specific changes to hardware, software, or firmware such as version or release numbers, descriptions of new or modified features/capabilities, and security implementation guidance. It is also important to record any changes to the environment of operation for the information system (e.g., modifications to hosting networks and facilities, mission/business use of the system, threats), or changes to the organizational risk management strategy. The information system owner and common control provider use this information in assessing the potential security impact of the changes. Documenting proposed or actual changes to an information system or its environment of operation and subsequently assessing the potential impact those changes may have on the security state of the system or the organization is an important aspect of security control monitoring and maintaining the security authorization over time. Information system changes are generally not undertaken prior to assessing the security impact of such changes. Organizations are encouraged to maximize the use of automation when managing changes to the information system or its environment of operation.

Security impact analysis conducted by the organization, determines the extent to which proposed or actual changes to the information system or its environment of operation can affect or have affected the security state of the system. Changes to the information system or its environment of operation may affect the security controls currently in place (including system-specific, hybrid, and common controls), produce new vulnerabilities in the system, or generate requirements for new security controls that were not needed previously. If the results of the security impact analysis indicate that the proposed or actual changes can affect or have affected the security state of the system, corrective actions are initiated and appropriate documents revised and updated (e.g., the security plan, security assessment report, and plan of action and milestones). The information system owner or common control provider consults with appropriate organizational officials/entities (e.g., configuration management or control board, senior information security officer, information system security officer) prior to implementing any security-related changes to the information system or its environment of operation. The authorizing official or designated representative uses the revised and updated security assessment report in collaboration with the senior information security officer and risk executive (function) to determine if a formal reauthorization action is necessary. Most routine changes to an information system or its environment of operation can be handled by the organization's continuous monitoring program, thus supporting the concept of ongoing authorization and near real-time risk management. Conducting security impact analyses is part of an ongoing assessment of risk. The authorizing official or designated representative, in collaboration with the risk executive (function), confirms as needed, determinations of residual risk. The risk executive (function) notifies the authorizing official of any significant changes in the organizational risk posture.

References: NIST Special Publications 800-30, 800-53A.

Task 6-2 - ONGOING SECURITY CONTROL ASSESSMENTS

ONGOING SECURITY CONTROL ASSESSMENTS


TASK 6-2: Assess a selected subset of the technical, management, and operational security controls employed within and inherited by the information system in accordance with the organization-defined monitoring strategy.

Primary Responsibility: Security Control Assessor.

Supporting Roles: Authorizing Official or Designated Representative; Information System Owner or Common Control Provider; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: Organizations assess all security controls employed within and inherited by the information system during the initial security authorization. Subsequent to the initial authorization, the organization assesses a subset of the security controls (including management, operational, and technical controls) on an ongoing basis during continuous monitoring. The selection of appropriate security controls to monitor and the frequency of monitoring are based on the monitoring strategy developed by the information system owner or common control provider and approved by the authorizing official and senior information security officer. The use of automation to support security control assessments facilitates a greater frequency and volume of assessments that is consistent with the continuous monitoring strategy established by the organization. Organizations can use the current year's assessment results to meet the annual FISMA security control assessment requirement. To satisfy this requirement, organizations can draw upon the assessment results from any of the following sources, including but not limited to: (i) security control assessments conducted as part of an information system authorization, ongoing authorization, or formal reauthorization, if required; (ii) continuous monitoring activities; or (iii) testing and evaluation of the information system as part of the system development life cycle process or audit (provided that the testing, evaluation, or audit results are current, relevant to the determination of security control effectiveness, and obtained by assessors with the required degree of independence). Existing security assessment results are reused to the extent that they are still valid and are supplemented with additional assessments as needed. Reuse of assessment information is critical in achieving a cost-effective, fully integrated security program capable of producing the needed evidence to determine the security status of the information system.

References: NIST Special Publication 800-53A.

Task 6-3 - ONGOING REMEDIATION ACTIONS

ONGOING REMEDIATION ACTIONS


TASK 6-3: Conduct selected remediation actions based on the results of ongoing monitoring activities and the outstanding items in the plan of action and milestones.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Authorizing Official or Designated Representative; Information Owner/Steward; Information System Security Officer; Information System Security Engineer; Security Control Assessor.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: The assessment information produced by an assessor during continuous monitoring is provided to the information system owner and common control provider in an updated security assessment report. The information system owner and common control provider initiate remediation actions on outstanding items listed in the plan of actions and milestones and findings produced during the ongoing monitoring of security controls. The security control assessor may provide recommendations as to appropriate remediation actions. Security controls that are modified, enhanced, or added during the continuous monitoring process are reassessed by the assessor to ensure that appropriate corrective actions are taken to eliminate weaknesses or deficiencies or to mitigate the identified risk.

References: NIST Special Publications 800-30, 800-53, 800-53A; CNSS Instruction 1253.

Task 6-4 - CRITICAL UPDATES

CRITICAL UPDATES


TASK 6-4: Update the security plan, security assessment report, and plan of action and milestones based on the results of the continuous monitoring process.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: To facilitate the near real-time management of risk associated with the operation and use of the information system, the organization updates the security plan, security assessment report, and plan of action and milestones on an ongoing basis. The updated security plan reflects any modifications to security controls based on risk mitigation activities carried out by the information system owner or common control provider. The updated security assessment report reflects additional assessment activities carried out to determine security control effectiveness based on modifications to the security plan and deployed controls. The updated plan of action and milestones: (i) reports progress made on the current outstanding items listed in the plan; (ii) addresses vulnerabilities discovered during the security impact analysis or security control monitoring; and (iii) describes how the information system owner or common control provider intends to address those vulnerabilities. The information provided by these critical updates helps to raise awareness of the current security state of the information system (and the common controls inherited by the system) thereby supporting the process of ongoing authorization and near real-time risk management.

The frequency of updates to critical risk management-related information is at the discretion of the information system owner, common control provider, and authorizing officials in accordance with federal and organizational policies. Updates to critical information regarding the security state of the information system (and common controls inherited by the system) are accurate and timely since the information provided influences ongoing security-related actions and decisions by authorizing officials and other senior leaders within the organization. With the use of automated support tools and effective organization-wide security program management practices, authorizing officials are able to readily access the current security state of the information system including the ongoing effectiveness of system-specific, hybrid, and common controls. This facilitates near real-time management of risk to organizational operations and assets, individuals, other organizations, and the Nation, and provides essential information for continuous monitoring and ongoing authorization.

When updating critical information in security plans, security assessment reports, and plans of action and milestones, organizations ensure that the original information needed for oversight, management, and auditing purposes is not modified or destroyed. Providing an effective method of tracking changes to information over time through strict configuration management and control procedures (including version control) is necessary to: (i) achieve transparency in the information security activities of the organization; (ii) obtain individual accountability for security-related actions; and (iii) better understand emerging trends in the organization's information security program.

References: NIST Special Publications 800-18, 800-53A.

Task 6-5 - SECURITY STATUS REPORTING

SECURITY STATUS REPORTING


TASK 6-5: Report the security status of the information system (including the effectiveness of security controls employed within and inherited by the system), to appropriate organizational officials on an ongoing basis in accordance with the organization-defined monitoring strategy.

Primary Responsibility: Information System Owner or Common Control Provider.

Supporting Roles: Information System Security Officer.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: The results of monitoring activities are recorded and reported to the authorizing official on an ongoing basis in accordance with the monitoring strategy. Security status reporting can be: (i) event-driven (e.g., when the information system or its environment of operation changes or the system is compromised or breached); (ii) time-driven (e.g., weekly, monthly, quarterly); or (iii) both (event- and time-driven). Security status reports provide the authorizing official and other senior leaders within the organization, essential information with regard to the security state of the information system including the effectiveness of deployed security controls. Security status reports describe the ongoing monitoring activities employed by the information system owner or common control provider. Security status reports also address vulnerabilities in the information system and its environment of operation discovered during the security control assessment, security impact analysis, and security control monitoring and how the information system owner or common control provider intends to address those vulnerabilities. Organizations have significant latitude and flexibility in the breadth, depth, and formality of security status reports.<ref>Security status reports can take whatever form the organization deems most appropriate. The goal is cost-effective and efficient ongoing communication with senior leaders conveying the current security state of the information system and its environment of operation with regard to organizational missions and business functions.</ref> At a minimum, security status reports summarize key changes to security plans, security assessment reports, and plans of action and milestones.

The frequency of security status reports is at the discretion of the organization and in accordance with federal and organizational policies. Status reports occur at appropriate intervals to transmit significant security-related information about the information system (including information regarding the ongoing effectiveness of security controls employed within and inherited by the system), but not so frequently as to generate unnecessary work. The authorizing official uses the security status reports in collaboration with the senior information security officer and risk executive (function) to determine if a formal reauthorization action is necessary. Security status reports are appropriately marked, protected, and handled in accordance with federal and organizational policies. At the discretion of the organization, security status reports can be used to help satisfy FISMA reporting requirements for documenting remedial actions for any security-related weaknesses or deficiencies. Note that this status reporting is intended to be ongoing, not to be interpreted as requiring the time, expense, and formality associated with the information provided for the initial approval to operate. Rather, the reporting is conducted in the most cost-effective manner consistent with achieving the reporting objectives.

References: NIST Special Publication 800-53A.

Task 6-6 - ONGOING RISK DETERMINATION AND ACCEPTANCE

ONGOING RISK DETERMINATION AND ACCEPTANCE


TASK 6-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.

Primary Responsibility: Authorizing Official.

Supporting Roles: Risk Executive (Function); Authorizing Official Designated Representative; Senior Information Security Officer.

System Development Life Cycle Phase: System Operations/Maintenance.

Supplemental Guidance: 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, and maintain security status information promotes the concept of near real-time risk management regarding the overall risk posture of the organization. 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).

References: NIST Special Publications 800-30, 800-39.

Task 6-7 - INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING

INFORMATION SYSTEM REMOVAL AND DECOMMISSIONING


TASK 6-7: Implement an information system decommissioning strategy, when needed, which executes required actions when a system is removed from service.

Primary Responsibility: Information System Owner.

Supporting Roles: Risk Executive (Function); Authorizing Official Designated Representative; Senior Information Security Officer; Information Owner/Steward; Information System Security Officer.

System Development Life Cycle Phase: System Disposition.

Supplemental Guidance: When a federal information system is removed from operation, a number of risk management-related actions are required. Organizations ensure that all security controls addressing information system decommissioning (e.g., media sanitization, configuration management and control) are implemented. Organizational tracking and management systems (including inventory systems) are updated to indicate the specific information system components that are being removed from service. Security status reports reflect the new status of the information system. Users and application owners hosted on the decommissioned information system are notified as appropriate, and any security control inheritance relationships are reviewed and assessed for impact.

References: NIST Special Publications 800-30, 800-53A.


Milestone Checkpoint #6

 
- Is the organization effectively monitoring changes to the information system and its environment of operation including the effectiveness of deployed security controls in accordance with the continuous monitoring strategy?
- Is the organization effectively analyzing the security impacts of identified changes to the information system and its environment of operation?
- Is the organization conducting ongoing assessments of security controls in accordance with the monitoring strategy?
- Is the organization taking the necessary remediation actions on an ongoing basis to address identified weaknesses and deficiencies in the information system and its environment of operation?
- Does the organization have an effective process in place to report the security status of the information system and its environment of operation to the authorizing officials and other designated senior leaders within the organization on an ongoing basis?
- Is the organization updating key risk management documents based on ongoing monitoring activities?
- Are authorizing officials conducting ongoing security authorizations by employing effective continuous monitoring activities and communicating updated risk determination and acceptance decisions to information system owners and common control providers?



Footnotes

<references />


Sources