By Steve Edwards, and
Richard Jaenicke
PALM HARBOR, Fla. – The Risk Management Framework (RMF) is a U.S. federal government policy and set of standards developed by the National Institute of Standards and Technology (NIST) in Gaithersburg, Md., for the assessment and authorization of mission systems.
Given that systems typically are an integration of several products, using component products that meet functional and assurance security requirements, such as Common Criteria (CC) protection profiles, can streamline assessing the integrated system.
Increasingly, U.S. military programs are using RMF to address cyber security and trusted-computing requirements, and for some systems, it is required to get an Approval to Operate (ATO). Because RMF is a system-level certification, it is for certifying whole systems -- not just an individual component.
This includes all the hardware and software in that system, and there are some steps that system designers can take for board-level hardware and software components to make RMF certification easier.
Getting started with RMF
The RMF establishes security and privacy controls for systems and organizations. It contains more than 800 controls to select from, many of which don't apply to embedded systems. It is up to the program office or federal agency to go through all the RMF controls and determine which apply. The RMF controls come in a series of NIST and Federal Information Processing Standards (FIPS) documents:
-- NIST SP 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems;
-- NIST SP 800-53: Security and privacy controls for Federal Information Systems and Organizations; and
-- FIPS 199: Standards for Security Categorization of Federal Information and Information Systems.
The Committee on National Security Systems has produced CNSSI-1253 to provide guidance on selecting RMF controls for national security systems (NSS). CNSSI-1253 should be reviewed along with SP800-53 in cases where the system is classified as crucial to national security.
The RMF contains 20 families of controls, ranging from access control to supply chain risk management. Some of the controls focus primarily on security functionality while other controls focus on assurance. Some controls can support functionality and assurance.
The U.S. military often relies on RMF to ensure that U.S. military systems go through sufficient cyber security scrutiny to operate securely on U.S. military networks. Because the RMF process applies to many different types of systems -- from enterprise to small embedded systems -- there are many possible controls that systems designers must analyze and document that may not apply to embedded systems.
For instance, there are RMF controls related to awareness and training (AT family) and personnel security (PS family) that may apply to the overall program but unlikely to apply to the embedded system itself. Still, it takes time to analyze, document, verify, and monitor the embedded system to ensure that none of the assumptions change. It's also important not only to prevent any backdoors into the system, but also to understand that additional work may be necessary to secure Pentagon approval for these sorts of systems.
The RMF was developed with the understanding that it applies across a wide variety of systems. This resulted in designing the concept of overlays to help address this concern. An overlay is a selection of controls specific to a particular type of system.
An overlay either can add or remove controls from the required set used to analyze the system security risks. It also can refine controls, adding additional text for clarity. Although systems designers have discussed developing an overlay that makes it easier to apply the RMF to embedded systems, that hasn't happened yet.
Still, there is progress in developing overlays specific to weapon systems or mission computers that may apply to embedded systems. For example, Appendix F of CNSSI 1253 references six different overlays, including a space platform overlay. Programs should look to the military services to understand if an overlay that applies to their type of system has already been developed before spending unnecessary time going through all RMF controls and documenting their decisions.
Once the systems integrator identifies the appropriate RMF controls he or she needs to determine how to implement them (Step 3 in the RMF Process Overview Diagram). The process of assessing, authorizing, and monitoring (Step 4-6 in the diagram) is undertaken by the prime contractor or U.S. military with the information provided by the hardware vendor. The entire process should be thought of as iterative, and there may be discussions about whether or not a certain control applies.
To implement RMF, the system needs to be categorized. Lower-level hardware and software, for example, are for controls. Each category needs to be evaluated for how it influences confidentiality, integrity, and availability.
Related: The essentials of trusted computing and cyber security
Low-impact involves conditions like degraded mission, minor damage to organization, and minor harm to individuals. Moderate impact involves significantly degraded mission capability, significant harm to individuals, or significant financial loss. High impact, meanwhile, involves the inability to perform a mission, loss of life, life-threatening injuries, or major damage to organizational assets.
Examples of impact levels could be a mission computer for a helicopter, which as high confidentiality, high integrity, moderate availability. An autonomous car detect-and-avoid system has moderate confidentiality, high integrity, and high availability. A tank fire-control system has low confidentiality, high integrity, and high availability.
Implementing RMF in COTS products
The VPX3-1260 single-board computer (SBC) from Curtiss-Wright Defense Solutions in Ashburn, Va., illustrates how board-level hardware and software can apply to these RMF controls. This SBC contains an onboard solid-state drive for storing application code and data at rest.
Either hardware self-encryption or software encryption can provide confidentiality. Intel Boot Guard can check the initial integrity of the boot code, and the board can enable authentication software to execute.
Related: Military cyber security: threats and solutions
Additional code monitoring ensures that no changes occur. Curtiss-Wright supplies sanitization routines and a certificate of volatility with its products that detail how non-volatile memories can be erased.
Security-centric embedded operating systems can provide additional controls, such as audit capability (AU family). The INTEGRITY-178 tuMP high-assurance real-time operating system (RTOS) from Green Hills Software in Palm Harbor, Fla., has taken part in national security systems such as those containing cross-domain solutions (CDS).
Earlier versions of INTEGRITY-178 passed evaluation by the National Security Agency (NSA) for systems requiring high robustness, and that evaluation included penetration testing. Security life cycle data is available for INTEGRITY-178 tuMP to support customer security certification efforts.
RMF provides system-level cyber controls. Leading COTS vendors provide board-level hardware and software that can help address the controls defined by RMF, while software from partners can address additional controls. For more information on RMF, please consult the following resources:
Related: Trusted computing: an overview
-- NIST SP 800-37 - Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy Overview of RMF and guidance on how to apply to systems;
-- NIST SP 800-60 - Guide for Mapping Types of Information and Information Systems to Security Categories Guide on how to categorize security levels/risks for system;
-- NIST SP 800-53 - Security and Privacy Controls for Federal Information Systems and Organizations A comprehensive list of controls used in RMF;
-- NIST SP 800-53A - Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans Provides guidance on how to verify each control has been implemented appropriately;
-- FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems Defines the impact categories for confidentiality, integrity, and availability;
-- JSIG - Joint Special Access Program Implementation Guide Supplemental guidance for controls with additional details specific to SAP programs;
-- CNSSI 1253 - Security Categorization and Control Selection For National Security Systems Provides additional controls for National Security Systems based on system categorization; and
-- NIAP PP_APP_V1.1-map - Mapping Between Protection Profile for Application Software and NIST SP 800-53 Provides a mapping from Common Criteria requirements used in applications to the controls specified in the RMF.
Steve Edwards is director product management at Curtiss-Wright Defense Solutions in Ashburn, Va. Richard Jaenicke is director of marketing at Green Hills Software in Palm Harbor, Fla.
