RMF Step 4: Assess Security Controls

The security control assessment process ensures that the appropriate resources are used to determine security control effectiveness. The Security Controls Assessor (SCA) develops an approved security assessment plan to ensure that the appropriate resources are used to determine security control effectiveness. For example, when security controls are supplied by an external firm, such as a contract, interagency agreement, line of business arrangement, licensing agreement, or supply chain arrangement, the organization obtains a security assessment plan from the firm.

The security control assessment plan identifies the security control assessment’s objectives, detailed assessment procedures, and the path to perform the assessment. The roadmap is a high-level plan describing assessing a particular system’s controls. The security control assessment should begin early, before the system’s complete development and integration of all components, and may also draw on testing results, if available. This allows the security control assessment to identify and correct deficiencies early and complete the assessment promptly.

The plan matches the organization’s security objectives and employs organizational tools, techniques, procedures, and automation to support information security monitoring and near real-time risk management. The plan’s assessment techniques are cost-effective as well. The AO or AODR, as the case may be, examines the security assessment plan, sets proper expectations for the security control assessment, defines the level of effort, and ensures that assessments get the appropriate resources to determine security controls’ effectiveness.

Security control assessments must be prepared for before a security control assessment exam by completing the following key steps:

 1. All organizational elements must comprehend the security control assessment policies, and all security control assessment steps must be completed before the step; 

2. All RMF steps must be completed before the security control assessment step, and management must be attentive to this process; 

3. Organizational entities responsible for developing and implementing security controls that are identified as common controls and hybrid controls should be assigned; 

4. The objective and scope of the security control assessment should be established.

SCAs perform the following when developing plans to assess system security controls or controls inherited by those systems:​

Select the appropriate assessment procedures based on the security plan and the assessment purpose. In addition to selecting the appropriate security controls and control enhancements to assess, you must also select the appropriate assessment procedures. If required, you may further modify the selected assessment procedures to select appropriate assessment methods and objects or to assign depth and coverage attribute values. Once the selected assessment procedures have been optimized to reduce duplication of effort, such as sequencing, consolidating assessment procedures, and reusing DT&E and OT&E test results, and cost-effective assessment solutions have been provided, you can finalize the assessment plan and obtain the necessary approvals to execute it.

Conduct Assessment Activities​

RMF Technical Advisory Group (TAG) has posted supplemental guidance on RMF Knowledge Service that outlines the assessment procedures prescribed in DoDI 8510.01. Security control assessors (SCAs) use the procedures to ensure that organizations properly implement security controls. Each procedure contains preparatory steps and conditions, actual assessment steps, and expected outcomes for each security control. In addition, background material, sample results, or automated testing tools may be provided for each procedure. RMF TAG maintains the security controls explorer page and manages the assessment procedures. This tool correlates with DISA’s management of eMASS. However, the organization’s assessment procedures may diverge from RMF TAG recommendations, and the SCA must document the divergence and describe the divergence in the SAR. RMF security authorization packages do not require these artifacts to demonstrate security controls’ compliance but must be available to receiving systems’ SCAs upon request. The common control provider maintains these artifacts and supporting documentation and makes them available when requested by receiving systems’ SCAs. Each requirement within a NIST SP 800-53 Rev. 4 security control or enhancement has been split into measurable components. The split doesn’t alter the control’s significance or intention. The breakdown of each requirement is referred to as a Control Correlation Identifier (CCI). Each CCI has a unique number (called a Security Correlation Identifier). It is essential to ensure that CCIs are assessed, and security requirements guides (SRGs) and Security Technical Implementation Guides (STIGs) are applied and consistent with security controls used by the Department of Defense (DoD). The Cyber.mil website (Public site and DoD PKI site) has a complete list of SRGs and STIGs.

DoD Assessment Procedures

The following is an annotated list of the DoD’s guidance on interpreting and using its assessment procedures.

1. Each organization may go further than the DoD guidance on mandatory testing but not beyond what is allowed by the assessment procedures. For example, the DoD does not mandate security controls following RMF TAG implementation guidance, and the assessment procedures do not exclude that option.

2. The standard language was developed to maintain consistency and define which “organization” is being referred to. “The organization conducting the inspection/assessment obtains and examines...”

3. The standard text at the defense department level describes the common security controls a system must support to comply with DoD standards. In addition, the standard text describes the DoD requirements for the common controls. The standard text may therefore describe the system’s compliance with DoD standards.

4. The DoD Specific Assignment Values Working Group (WG) defined DoD-specific assignment values, and RMF TAG (later known as the DIACAP TAG) endorsed these definitions. Because the organization being inspected/assessed is compliant at the DoD level, it is automatically compliant with this CCI.

5. The KS defines many words in the CCI text and assessment procedures using standard definitions.

The SAR details the findings, recommendations, and problems identified in the security control assessment. According to the procedures and standards outlined in each procedure, the assessment’s actual results are recorded and added to the SAR.

1. Compliant (C). Security controls that achieved expected assessment procedure results.

2. Non-Compliant (NC). Security controls that did not achieve all associated assessment procedures for one or more expected results. Failure to achieve expected results for all assessment procedures does not equate to unacceptable risk. AOs must document all NC security controls in a POA&M; however, after assessing risk, the AO may explain why the risk to the system is acceptable.

3. Not Applicable (N/A). Security controls that are not technically or procedurally relevant to the IS and do not impact the security posture of the IS as determined by the AO.

The SAR addresses all security controls in an NC status, including existing and planned mitigations. Before an authorization decision is made, a SAR is always required. When a compelling mission or business need requires the rapid introduction of a new system, assessment activity, and a SAR are still required. If the rapid introduction of a new system is required, assessment activity and a SAR are still required.

POA&M

The SCA documents the NC status of security controls if no vulnerabilities are found after executing the assessment procedures. The SCA documents the security control as compliant in the POA&M if no vulnerabilities are found after executing the assessment procedures. The SCA records the security control as NC if vulnerabilities are found after executing the assessment procedures. The NC status of security controls determined not to be technically or procedurally relevant to the system, as determined by the AO, is recorded in the POA&M with sufficient justification.

The severity values, ranging from 1 to 5, assigned to all NC controls in the security control analysis are part of the vulnerability severity values reported by the SCA. CCIs used in vulnerability severity values for security controls (available on the Cyber.mil website) describe the levels of risk for these controls. If a control has a STIG or SRG associated through CCIs (available on the Cyber.mil website), the vulnerabilities identified by STIG or SRG assessments will be used to estimate its vulnerability severity. See NIST SP 800-30 for more information on vulnerability security values.

Common Security Controls and Inheritance

Common Security Control and Security Control Inheritance Definitions

NIST SP 800-37 and CNSSI 4009 provide the following definitions:

Common Security Control: 

“A security control inherited by one or more organizational information systems.”

Hybrid Security Control: 

“A security control implemented in an information system is part as a common control and part as a system-specific control.”

Security Control Inheritance: 

“A situation in which an IS or application receives protection from security controls (or portions of security controls) that are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application; entities either internal or external to the organization where the system or application resides.”

Common Security Controls

1. Support multiple ISs efficiently and effectively as a common capability.

2. Promote more cost-effective and consistent security across the organization and can also simplify risk management activities.

3. Significantly reduces the number of discrete security controls that must be documented and tested at the IS level, eliminating redundancy, gaining resource efficiencies, and promoting reciprocity.

Identifying Common Security Controls

1. These recommendations assist planning system implementation by identifying security controls that may be implemented as common controls. The system and its intended environment and deployment will determine which security controls will be implemented as common controls.

2. Common Security Controls may be identified at Tier 1, 2, and 3 levels.

• Tier 1: The Department of Defense CIO identifies common security controls documented in DoD policy and guidance and applies them across the DoD. DoD ISs and PITs automatically comply with Tier 1 common security controls because they already conform to documented DoD standards. It is assumed that the risk associated with these controls is shared by the DoD components collectively through their agreement with the DoD standards as issued. The AO for the Tier 1 common security controls is the DoD SISO.

• Tier 2: The DoD component CIO identifies component-specific common security controls that are satisfied by existing component policy and guidance and are applicable throughout the component. However, Tier 2 common security controls might not negate or contradict Tier 1 common security controls. Tier 2 common security controls might not prevent interoperability or reciprocity between or among the DoD components. Component ISs and PIT systems automatically comply with Tier 2 common security controls because they implement and are satisfied by documented component policies and guidance. The risk associated with Tier 2 common security controls is borne by the component that provides the security control. The AO for Tier 2 common security controls is the component SISO. The DoD components identify tier 2 common security controls and should be posted to the component’s KS workspace.

• Tier 3: Enclaves on the Department of Defense information network with a current ATO are designated as Tier 3 common control providers. Tier 3 security controls are identified as common security controls and made available to systems (other enclaves, main applications, PIT systems) hosted in the enclave through bilateral agreements between the enclave and the systems. Infrastructure-type security controls such as physical, environmental, and some policies may be included in this package. Security controls provided to the enclave from a remote entity (e.g., MA-4, Non-local Maintenance) may also be included.

• (a) An enclave must provide all of the required Tier 3 physical and environmental security controls in a hosted system unless an agreement is reached with the site to provide the desired features or services or provide the capability or service itself.

• (b) The hosting enclave maintains a current list of Tier 3 common (i.e., inheritable) security controls. All inheritance relationships must be documented between the security control provider and the receiving system so that current security control assessments and residual risk reports (which indicate non-compliant security controls remaining) are provided to the receiving system. The common control provider must provide security control assessment results and risk assessment reports to receiving systems. Common security controls at Tier 3 must be documented and either accepted, mitigated, or rejected by the hosted system. The AO must only accept Tier 3 common security controls if acceptable. A site is a physical structure or post that provides security services or capabilities to systems hosted on it ( Infrastructure type security controls, for example, might require that a physical structure or environmental condition be present).

• (a) A single building (not including industrial control systems) may host separate Department of Defense enclaves, major applications, or PIT systems for multiple building tenants. The responsible AO evaluates and authorizes the hosted systems, considering any capabilities or services provided by the site that satisfy all or some physical and environmental security controls required by the hosted system. For example, if a building houses DISA, the United States Army, and the United States Navy, it would provide physical and environmental capabilities or services to all three systems. The same would hold true for systems hosted within the physical confines of a post, ship, or another discrete physical unit.

• (b) In certain situations, when a site’s physical and logical boundaries are the same, a site may be organized as an enclave authorized by the AO of the command/organization responsible for the site. For example, the DISA, US Army, and US Navy component systems hosted in the building/enclave might inherit technical security controls at the enclave boundary, such as network (e.g., point of presence to the DISN), boundary protection, and some policies (i.e., user access policies), as well as physical, environmental, and personnel security controls documented in the enclave’s security authorization package and identified as common controls available for inheritance.

• (c) When the logical boundary of an enclave encompasses more than one physical site, systems hosted on a particular site must establish inheritance relationships with the site for physical and environmental controls that have not been identified as common controls available for inheritance in the enclave’s security authorization package. The inheritance relationship must be documented by both parties.

Procedures:

Organizations that provide security solutions for hybrid security controls, including the DoD Component CIOs, must:

1. Identify the security controls provided as solutions for IS and PIT systems, including the common parts of hybrid security controls.

2. Document the assessment and authorization of the common security controls, including the common parts of hybrid security controls, in a security plan (or an equivalent document).

3. Make that documentation available to individual systems inheriting the common security controls.

A security plan (or an equivalent document) must be made available to individual systems that inherit the common security controls so that the security controls can be identified, documented, and enforced. In addition, the compliance status of inherited security controls must be indicated.

A system may only inherit a portion of a security control if the base security control is included in the baseline security control set. For example, suppose the baseline security control set includes the base security control, AC-2 (1), and Account Management/Automated System Account Management. In that case, the system may only inherit the portion of AC-2 that relates to automated system account management. If a security control is not included in the baseline security control set, the system cannot inherit anything from that control.

Non-DoD external service providers cannot assume control of IT services.

Nevertheless, the system PM or ISO must ensure that the security proposed by potential service providers is adequate, including any security controls implemented. A service level agreement (SLA), contract, or order included in the system’s security authorization package should clarify the security approach in addition to the security controls. Interagency agreements with non-DoD federal government agencies must include SLA requirements that include security controls. IT services purchased from commercial firms must include security controls in proposals, evaluate the security offered by potential vendors, and document it in the agreement.

An exception is the DoD organizations contracting for external IT services in the form of commercial cloud computing services must comply with DoD cloud computing policy and procedural guidance as published at

http://iase.disa.mil/cloud_security/Pages/index.aspx.

A system can receive and inherit common security safeguards. For example, an IS, or PIT system accepts the chance of inheriting common security safeguards from a system. In most cases, common security safeguards that are non-compliant are passed on without change since the provider has assumed the risk associated with NC security safeguards, thus reducing the IS or PIT system’s AO of holding residual risk for those safeguards.

An inherited common security control may require more frequent assessment if the AO of the receiving system determines that a more frequent assessment is warranted. For example, if the common security control provider assesses a security control annually and the receiving IS decides to independently assess the security control quarterly if the AO of the receiving system determines that an annual assessment is insufficient, more frequent assessment is warranted. The provided system maintains assessment test results and supporting documentation and makes them accessible to security-concerned auditors of the receiving system. Security auditors should reuse any previous assessment (i.e., leveraged authorization) and T & E documentation for their system evaluation.

The security plan must identify all security controls inherited from external providers and stipulate the required minimum standards for those security controls. For example, suppose a security control is inherited from an enclave outside the US... In that case, it must be documented in a memorandum of agreement, memorandum of understanding, or another type of long-term agreement. The required documentation must be provided for all security controls that have been accomplished by inheritance (e.g., security authorization packages, contract documents, MOAs, and SLAs). System-specific security controls are the sole domain of IS owners and their respective authorizing officials. Hybrid security controls are those where one part of the security control is common, and another part is unique to the system. When security controls are hybrid, they are the responsibility of the IS owner and their respective authorizing officials.

Example Lists of Common Security Controls:

• AT-1

SECURITY AWARENESS AND TRAINING POLICY AND PROCEDURES​

• AT-2

SECURITY AWARENESS TRAINING

• AT-2(1)

SECURITY AWARENESS | PRACTICAL EXERCISES

• AT-2(2)

SECURITY AWARENESS | INSIDER THREAT

• CM-10(1)

SOFTWARE USAGE RESTRICTIONS | OPEN SOURCE SOFTWARE

• CP-1

CONTINGENCY PLANNING POLICY AND PROCEDURES

• IA-1

IDENTIFICATION AND AUTHENTICATION POLICY AND PROCEDURES

• IA-5(14)

AUTHENTICATOR MANAGEMENT | MANAGING CONTENT OF PKI TRUST STORES

• IA-5(3)

AUTHENTICATOR MANAGEMENT | IN-PERSON OR TRUSTED THIRD-PARTY REGISTRATION

• IR-1

INCIDENT RESPONSE POLICY AND PROCEDURES

• IR-4(3)

INCIDENT HANDLING | CONTINUITY OF OPERATIONS

• MP-1

MEDIA PROTECTION POLICY AND PROCEDURES

• PE-1

PHYSICAL AND ENVIRONMENTAL PROTECTION POLICY AND PROCEDURES

• PL-1

SECURITY PLANNING POLICY AND PROCEDURES

• PL-9

CENTRAL MANAGEMENT

• PM-1

INFORMATION SECURITY PROGRAM PLAN

• PM-10

SECURITY AUTHORIZATION PROCESS

• PM-13

INFORMATION SECURITY WORKFORCE

• PM-2

SENIOR INFORMATION SECURITY OFFICER

• PM-7

ENTERPRISE ARCHITECTURE

• PM-8

CRITICAL INFRASTRUCTURE PLAN

• PM-9

RISK MANAGEMENT STRATEGY

• PS-1

PERSONNEL SECURITY POLICY AND PROCEDURES

• RA-1

RISK ASSESSMENT POLICY AND PROCEDURES

• SA-1

SYSTEM AND SERVICES ACQUISITION POLICY AND PROCEDURES

• SA-4(1)

ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF SECURITY CONTROLS

• SI-1

SYSTEM AND INFORMATION INTEGRITY POLICY AND PROCEDURES

​​Model for Assessing Residual Risk Level for Non-Compliant Security Controls

There are five steps in the risk management process: system environment, risk assessment, risk management, policy enforcement, and incident handling. Variations in the scope and intent of the risk assessment result in various risk assessment and analytic approaches. The assessment discussed on this page isolates security problems in a system. There is a greater emphasis on qualitative than quantitative analysis in this assessment approach.

According to NIST SP 800-30 Rev 1, “Guide for Conducting Risk Assessments,” DoD organizations must conduct risk assessments following the instructions. However, SP 800-30 does not address the following:

1. The formality, rigor, or level of detail used to perform risk assessments.

2. Methods, tools, and techniques used to perform risk assessments.

3. The format and content of assessment results and any associated reporting mechanism.

The model provided for this page is intended for non-compliant security controls and is simplified for ease of use and conservation of resources. In addition, it simplifies and summarizes some of the risks described in NIST SP 800-30, particularly regarding threat and threat event occurrence.

The probability and severity of damage caused by using technology depend on its susceptibility and the importance of the threat. The vulnerability of technology and the effectiveness of any protective measures taken are based on its raw susceptibility and severity. Although the two risk factors shown below are not considered separately, the capability of a non-adversarial hostile source and the intent of an adversarial, hostile source are all important considerations in assessing the importance of a threat.

The scarcity of resources and the need for quantifiable or semi-quantifiable data result in risk assessments focusing more on qualitative attributes than numerical values. As a result, qualitative values are used for the risk factors, even though they do not really exist. Using a five-tier scale risk assessments provide sufficient reliability while making comparisons easy. The risk factor levels are expressed as, Very Low (VL), Low (L), Moderate (M), High (H), or Very High (VH).

According to DoDI 8510.01, security controls are assessed for effectiveness and documented in the SAR. However, all NC security controls present potential vulnerabilities that adversarial or non-adversarial threat sources may exploit by initiating or causing threat events. As a result, risk assessments must consider multiple factors for all NC security control vulnerabilities in assigning residual risk levels to each security control. The risk assessment of NC security controls is ultimately the responsibility of the SCA, but it should be conducted in coordination with the PM/SM or ISO. 

Although DoDI 8510.01 does not specifically require a RAR for NC security controls, the SCA must create one for any activity that requires a risk assessment. This documents the facts and decisions of the risk assessment. For example, suppose the SCA identifies six “very high” vulnerabilities in the SAR. In that case, the PM/SM or ISO uses this vulnerability information to perform a risk assessment based on their understanding of the threat, likelihood, and impact on the system’s mission/functionality/technical abilities. Next, the PM/SM or ISO provides a RAR back to the SCA, including any additional mitigations applied to the six “very high” vulnerabilities. After considering its findings, the SCA then reviews the RAR and independently documents its final risk determination in the SAR.

The system-level risk rating provided by the security controls assessment is based on the risk rating of individual controls. In turn, the security controls assessment’s overall risk rating is used to generate the system-level risk rating in the final recommendation to the surgeon general. The AO must evaluate the recommendations concerning the risk tolerance and risk tolerance set by the ISRMC (RMF Tier 1), the DoD components (RMF Tier 2), and the PAOs (RMF Tier 2). To manage residual risk, the AO must assess the risk rating and sometimes the details of the individual controls. The AO must also determine the required remediation of individual controls and the risk reduction over time or acceptance of the risk as remediated. In addition, the AO must determine whether to remediate individual controls and, if so, what action to take.

The PM, SM, or ISO must document all NC controls in the POA&M by documenting the actions required to reduce residual risk to an acceptable level for the AO to grant an ATO. The actions documented in the POA&M might have already remediated or mitigated residual risk; however, those entries merely indicate what may and reasonably be done. The AO must identify the required mitigating actions and specify when they must be completed to reduce residual risk to an acceptable level before or after an authorization decision is made.