RMF Step 3: Implement Security Controls

A Quick Introduction to Security Controls

Information processed, stored, and transmitted by an organization's systems and systems are protected by security controls, which are safeguards/countermeasures to preserve confidentiality, integrity, and availability. Security controls serve as a management language for establishing cybersecurity needs. The security controls serve as a common language for information owners, PMs, outsourced service providers, enclave managers, assessing and authorizing authorities, and information system security engineers to discuss security controls. It assists in negotiating and allocating cybersecurity requirements and capabilities, enabling traceability to specific cybersecurity solutions, and providing a consistent reference for certification activities and findings. 

Each of the 18 security controls in the NIST SP 800-53 is associated with one of the 18 subject families, indicating the major focus of attention.

(AC) Access Control

(AT) Awareness and Training

(AU) Audit and Accountability

(CA) Security Assessment and Authorization

(CM) Configuration Management

(CP) Contingency Planning

(IA) Identification and Authentication

(IR) Incident Response

(MA) Maintenance

(MP) Media Protection

(PE) Physical and Environmental Protection

(PL) Planning

(PM) Program Management

(PS) Personnel Security

(RA) Risk Assessment

(SA) System and Service Acquisition

(SC) System and Communication Protection

(SI) System and Information Integrity

The NIST SP 800-53 also has a set of privacy controls organized into 8 subject families.

(AP) Authority and Purpose

(AR) Accountability, Audit, and Risk Management

(DI) Data Quality and Integrity

(DM) Data Minimization and Retention

(IP) Individual Participation and Redress

(SE) Security

(TR) Transparency

(UL) Use Limitation

​A security control consists of the following components.

Security Control Number: A unique identifier composed of two letters, a dash, and a number that identifies a security control in two words. The individual security control families are abbreviated in the letters.

Security Control Name: A short title phrase describing individual security control.

Security Control Section: Specifies what actions or activities must be taken by an organization or information system to be secure. It is a list of actions that must be taken to make an information system security. An organization is a collection of activities that are usually process-led or entity-oriented rather than process-driven or entity-oriented. It is a list of actions that must be taken to make a system secure. The term information system refers to an information technology system that includes hardware, software, and firmware. Organization refers to activities that are usually process-driven or entity-oriented rather than process-driven or entity-oriented. Security controls concerned with organizations use the term organization to mean human or procedural-based security controls. The three tiers of the risk management hierarchy are still available for use with information system terminology.

Security Control Supplemental Guidance Section: Non-prescriptive, additional information for specific security control. Security controls can be created, developed, and/or implemented under the non-prescriptive, additional information provided by the Security Control Supplemental Guidance Sections.

Security Control Enhancement Section: A security control enhancement statement describes how to build on or increase control strength. Either type of statement can be used in an information system or operating environment to enhance control protection beyond that provided by the base control. In both cases, higher protection is required than the base control provides due to the potential for adverse organizational impacts or when organizations seek to expand the control's functionality or specificity based on risk assessment.

References Section

The References Section lists all federal laws, executive orders, directives, policies, regulations, standards, and guidelines that apply to a particular security control (e.g., OMB Circulars/Memoranda, Homeland Security Presidential Directives, FIPS Publications, and NIST Special Publications).

Priority and Security Control Baseline Allocation Section

A recommended priority code for sequencing decisions during security control implementation. The Priority and Security Control, Baseline Allocation Section provides the initial allocation of security controls and control enhancements to the baselines. Refer to Chapter 2, Section 2.2 of NIST SP 800-53 for a detailed discussion of the security control structure.

Implementing Security Controls

RMF develop security control implementation guidance in line with DoD and DoD Component cybersecurity architectures and standards, employing system and software engineering methodologies, security engineering principles, and secure coding techniques. Security controls specified in the security plan must be implemented in accordance with the DoD implementation guidance found on the Security Controls Explorer page. The CNSSI 1253 defines several security controls and their families. The Security Controls Explorer is a tool created for RMF Knowledge Service to help users determine the individual security controls and their families. The CNSSI 1253 defines several security controls and their families. The CNSSI 1253 provides users with a streamlined method for choosing integrity, confidentiality, and availability (CIA) selections and CNSSI overlays for a certain system type. The more sophisticated version of the Security Controls Explorer tool is designed to allow users to search for various controls and their details and CNSSI overlay filters and search terms to find out more about them. Users may also find export mechanisms for custom control sets, implementation advice, and assessment procedures. The Security Controls Explorer questionnaire has been updated to include an NSS system filter. The CNSSI 1253 baselines, which include the NSS Security Controls, will continue to be the default required categorization guidance for all DoD systems. When used for non-NSS systems, the button will simplify and speed up categorization by removing non-NSS controls. NSS systems should leave this box or filter empty.

Reciprocity

When an organization implements a security control, it must follow DoD implementation guidance and assessment procedures and satisfy the DoD enterprise-wide specific assignment values. Each organization may require more stringency than the published DoD implementation guidance and DoD-specific assignment values for individual security controls. However, increasing stringency or departing from DoD implementation guidance would help interoperability and reciprocity. The assessment procedure must be documented when more stringency or divergence from DoD implementation guidance is required.

Common Correlation Identifiers

NIST SP 800-53 Rev. 4 security controls and enhancements are discrete steps. These steps maintain the intent and significance of the procedures. Every requirement is broken down into separate parts and labeled (using numbers) as a Control Correlation Identifier (CCI). DISA has provided implementation guidance for each CCI. The following table lists examples of CCIs. The mapping of CCIs to STIGs enables an organization to recognize the part of a control accomplished by employing the prescribed configuration. Before proceeding to step 3 of RMF (implement security controls), organizations must identify the hardware and software products utilized in the system and accumulate a list of applicable STIGs. When a STIG is unavailable for a product, organizations may use a Security Requirements Guide (SRG) for configuring software. DISA develops SRGs to provide security compliance guidelines in general. For example, if a new database server is not yet covered by a STIG, the implementer may use the Database SRG to assess CCIE compliance until DISA develops a suitable one. Because STIGs are established from SRGs, they also function as source documents for developing DoD implementation guidance.

The following is an example of DoD implementation guidance: 

1. "The organization being inspected/assessed is specified by the standard language." 

2. "By standard language, the language describes that a particular organization is being specified." 

3. "By standard language, the language describes that a particular organization is being specified." 

4. "The DoD SPAV WG has defined DoD-specific values for assignment (DSPAV). The DIACAP TAG has approved these values."

5. The ISO or PM/SM ensures that system security engineers and mission authority(s) participate in security control implementation to ensure that it conforms with system design standards and that security engineering activities do not detract from system performance.

Systems Implementing a CDS

CDSs are typically deployed within the higher-classification system's authorization boundary and are part of that system's authorization. Therefore, the ATO responsible for the system must consider the security consequences of CDS operations in the overall authorization decision. Besides the high-side security requirements and the ATO, AOs must also consider the security of the information's integrity on the low-side system. See DoDI 8540.01, "Cross Domain (CD) Policy," and the National Cross Domain Solution and Management Office websites on SIPRnet and JWICS. Users will find cross-domain policies, contracts, and a cross-domain portfolio that includes the CDS Baseline and the CDS Sunset List on these sites. 

DoDI 8540.01 can be found here: https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/854001p.pdf

​​Type Authorization

Only a single security authorization package can be created for an archetype (common) version of a system and deployed to multiple identical instances in places that meet the conditions specified in the package and installation instructions. The system can then be deployed to multiple locations with specific security control, operational security, and configuration requirements specified by the hosting enclave. Type authorizations may be granted to systems controlled by a program management office (GO) in the Defence Organisation (DoD). Type authorizations may be used in various AO sectors across DoD departments. The Defence Information Systems Agency (DISA), the Defence Enterprise Computing Centre (DECC), the Navy and Marine Corps Intranet (NMCI), and so forth may all be given a type of authorization. A single body of evidence is used to validate a single security assessment decision. Many businesses may satisfy RMF standards by using the ATO risk decision produced by the type authorization (ABT).

AO may accept the security authorization package sent by the originator organization as authorized. If the AO requires changes to the deployed system (e.g., configuration changes), they must seek a separate authorization. Whenever feasible, receiving organizations should work with the originator organization on changes to the system to maintain a single configuration and type authorization. The system, configuration, and other elements of the type of authorization may frequently change, generating significant duties for the AO to support, configure, fund, operate, approve, and maintain. Strictly, receiving organizations must notify all concerned parties of any changes to the system, including the originator organization. Any changes to the deployed system may void the current Memorandum of Agreement (MOA), Memorandum of Understanding (MOU), Service Level Agreement (SLA), or internal inheritance authorizations. An organization may reuse security testing, assessment results, or other applicable information from a type of authorization to support authorization of a similar system when a type of authorization is not appropriate. However, in these situations, the originating organization has no responsibility to the organization reusing the security testing or assessment results.

Organizational Responsibilities

Frequent communications between parties are essential to ensure the successful management and operation of type-authorized systems. The managerial and technical levels of communication must remain open. Formal agreements should be documented and published electronically via a tracking tool (for example, eMASS or Component Risk Management Framework Knowledge Service Workspace). Unless all parties agree to different methods, documents should be kept and published electronically. Before installing the type-authorized system, the originating and receiving organizations should have an MOU, MOA, or SLA. The agreement should include a description of the types of security controls or security requirements the receiving organization must meet (for example, physical and environmental).

Joint Responsibilities between Originating and Receiving Organizations

Before signing a contract, or rolling out a type-authorized system, receiving and originating companies must perform several activities. The following activities may be included.

Determine who will provide the resources (e.g., funding, hardware, software, and personnel) to manage and operate the system. Confirm that the receiving organization has implemented the appropriate installation security controls required by the authorization package and that it has implemented the mitigation strategies recommended by the POA&M of the originating organization. Ensure that type authorizations and/or interconnected systems are not adversely affected by new vulnerabilities. Ensure all stakeholders have access to the security authorization package, including configuration specifications. Maintain the correct configuration. Document all tasks that must be completed and the associated responsible organization resulting from an agreement between the originating and receiving organizations.

Responsibilities of Originating Organization

• Provide the security authorization package and deployment instructions (or access to it), including the current POA&M, to receiving organizations. 

• Provide the security authorization package and deployment instructions (or access to it) with the current POA&M. 

• All changes to the system throughout its lifecycle, including version updates, should be communicated to receiving organizations. 

• Whenever new threats, vulnerabilities, or similar information is discovered, it should be reported to receiving organizations throughout the authorization life cycle. 

• When developing the system, gather requirements from potential leveraging organizations to ensure the widest range of uses for a standardized configuration. 

• A POC (point of contact) should be provided to receiving organizations for requesting information. 

• Six months before a reauthorization event, notification should be provided to receiving organizations to ensure consideration of their inputs.

• Letting the receiving organizations know of any plans that can affect the use of the system, such as decommissioning or firmware version changes. 

• Identify reasons for terminating the MOU/MOA agreement. 

• Comply with DOD and other requirements and timelines. 

• Maintain system locations as recorded by the originating organization's tracking tool.

• Ensure that an accredited CSSP (cybersecurity specialist) has continuous monitoring, patch management, vulnerability management, operational orders, POA&M, and annual and quarterly or monthly reviews of authorized systems.

Responsibilities of Receiving Organization

• The originating organization AO should receive the request for a security authorization package and configuration instructions (or access to it), including a current POA&M, from the requested security authorization package recipient. 

• The originating organization AO should accept the authorization request. 

• The system should be deployed using configuration requirements in the security authorization package and configuration instructions. 

• All inherited security controls, mitigations, or support functions must be provided for the requested authorization. 

• The system must be allowed to connect and operate within the organization's network to obtain any necessary authorization.

• Provide a single POC to originating organizations providing information. 

• Update necessary authorization tracking tools within the organization.

• Provide necessary patches and changes under Project Management (PM) guidance. 

• Notify originating organizations of any new findings, such as new threats, discovered vulnerabilities, or similar information throughout the authorization life cycle. 

• Implement mitigations following the originating Information Technology Security POA&M.

These requirements still need to be completed. Additions or deletions to the requirements may be necessary. All modifications to the agreements must be agreed to in writing by the originating and receiving organizations.

Change Management

All organizations must include POCs as part of their MOU, MOA, or SLA to support the management and operation of the type-authorized system, as required by the original AO. If a PM notices any event that could compromise the security posture of the type-authorized system or the installed environment, they must immediately inform the original AO. Agreement procedures, timing, and notification requirements must be specified.

Examples of events requiring notification:

• Security incidents

• Disasters and other contingencies

• Material changes to system configuration

• Personnel changes in critical positions

• New user types, such as Foreign Nationals

• Changes to the operating environment (such as a facility once cleared for open storage no longer having such clearance)

A Denial of Authorization to Operate (DATO) is applied to the network the system is connected to.

Stand-Alone Systems​

Stand-alone systems are isolated networks that do not exchange data with other networks. Stand-alone systems may range in size from a single workstation to multiple interconnected subsystems as long as they comply with the following requirements. Stand-alone systems are treated the same way as any other system, but with the approval of the AO, security control sets may be tailored to eliminate network-related controls, such as eliminating CNSSI 1253 baselines. In CNSSI 1253 baselines, stand-alone systems are presumed to be in networked environments.

An organization may deploy stand-alone systems with identical security control implementation to multiple locations using type authorization. As a result, there is no risk to the system when certain cybersecurity controls are not implemented. These controls are listed as NA on the RMF security plan and described on the system's POA&M as a means to document and explain why the control is listed as NA.

RMF Relationship to DT&E and OT&E​

The Defense Department CIO, the Deputy Assistant Secretary of Defense for Developmental Test and Evaluation (DASD (DT&E)), and the Director of Operational Test and Evaluation (DOT&E) work together to ensure that DT&E and OT&E activities are integrated into RMF as soon as possible. The aim of T&E for cybersecurity is to enhance the security of DoD IS and PIT systems and to help program and procurement decision-makers mitigate cyberspace-related risks by systematically identifying and resolving gaps throughout the acquisition process.

The DASD (DT&E) ensures that acquisition programs' responsible DT&E authorities set up procedures to resource, document, and execute adequate DT&E to support cybersecurity. In addition to providing advice and other input, the DASD (DT&E) and the DoD Test Resource Management Center work to improve cybersecurity DT&E resource management to help senior officials create more robust cybersecurity DT&E designs.

The goal of cybersecurity DT&E is to identify issues related to the resilience of military capabilities before MS C. It is possible to reduce the impact of issues by remediation if system vulnerabilities can be discovered early. DASD (DT&E) evaluations and DT&E assessments are provided at significant decision points in Defense

Acquisition Executive Summaries.

DOT&E ensures that OT&E activities are integrated into RMF to ensure adequate cybersecurity evaluation for all DoD IT acquisitions subject to oversight and provides the TAG with advice and other input as required. The chief objective of cybersecurity OT&E is to ensure that the system under test can withstand realistic cyber-attack threats and return to normal operations in the event of a cyber-attack.

The DASD (DT&E) and the DOT&E have mandated that T&E authorities for acquisition programs ensure that adequate T&E support is planned, resourced, documented, and can be executed promptly for cybersecurity requirements. Heads of the component concerned are required to enforce the procedures.

PMs of programs acquiring IS and PIT systems, together with the SCA and the program's Chief Developmental Tester / T&E working-level integrated product team, ensure that security control assessment activities are coordinated with DT&E and OT&E events and that DT&E and OT&E activities are documented in the security assessment plan and the program's T&E documentation to maximize effectiveness, reuse, and efficiency.

An IATT may be issued for DT&E and OT&E activities and events. Still, it is only given when an operational environment or live data is required to complete a specific test objective (e.g., replicating certain operating conditions in the test environment is not practicable). Testing (normally for fewer than 90 days) must be completed using an IATT. An IATT may be applied in support of DT&E if operational testing and evaluation are conducted in the operational environment or on deployed capabilities. An ATO (rather than an IATT) may be required to conduct complete and independent operational testing. In this case, the ATO should be reviewed following the operational testing and evaluation for modification as necessary in consideration of the operational test results. 

The DT&E and the Director of OT&E are collaborating on a cybersecurity T&E T&E guidance that will be incorporated into the Defense Acquisition Guidebook, Chapter 9, T&E. This guidance will cover the approach to T&E. The Chief Developmental Tester and the test community will profit from Chapter 9 of the DAG in understanding their part in RMF's T&E planning, execution, and assessment. It emphasizes that cybersecurity T&E planning, analysis, and implementation are iterative processes that begin at the beginning of the acquisition lifecycle and continue throughout the system's maintenance.