The Expansion of the RMF

Abstract

This chapter discusses proposed changes to the RMF in the future, including adding new documentation. It also addresses implementation of the RMF in the Department of Defense (DoD) and the intelligence community (IC)

Table of Contents

Chapter Overview and Key Learning Points

Use of the RMF is expanding, today the RMF is being implemented in many of the agencies that make up the Intelligence Community (IC) and will soon be implemented in the Department of Defense (DoD). However these are not the only place that the RMF can be implemented, corporations in the private sector can benefit from implementing the RMF including those that must comply with specific compliance requirements such as Payment Card Industry (PCI), the Health Insurance Portability and Accountability Act (HIPAA) and cloud implementations like Federal Risk and Authorization Management Program (FedRAMP).

The Transition to the RMF

One of the primary goals of the Joint Task Force Transformation Initiative was to migrate the federal government away from a patchwork of differing methods of evaluation and approval systems entering the production environment. In the past, the intelligence community (IC), the Department of Defense (DoD), and the rest of the federal government used different standards and control sets for conducting these evaluations. All three groups are beginning to use the Risk Management Framework as a standard process for approving the information systems they manage. This unprecedented step will align all of the federal government’s security systems under a single standard, the RMF, and a single controls catalog, SP 800-53.

Many of the changes, developments, and improvements in the RMF over the past few years can be traced directly to the development of a standard tool set that can be used holistically across the federal government.

Implementation of the RMF in the Intelligence Community (IC)

While the majority of the federal government has been using the Risk Management Framework for quite some time, the intelligence community has been hesitant to transition from the Director of Central Intelligence Directive (DCID) 6/3 process, which has been used successfully for some years. This process, like many older processes, viewed risk from an information systems perspective. After a full evaluation of the RMF process, Director of National Intelligence John M. McConnell issued the Intelligence Community Directive (ICD 503) to the community. This directive mandated each of the agencies that comprise the IC to develop a transition plan away from the older DCID 6/3 process and to the newer, more efficient Risk Management Framework. As the IC is composed of many information systems that are categorized as national security systems, or NSS, it is exempt from many of the FISMA legal requirements. However, ICD 503 has directed the RMF to be used, as well as the security controls catalog, NIST SP 800-53. To assist information system owners, developers, and others in correctly implementing the RMF with the unique challenges of NSS, the IC turned to the Committee on National Security Systems (CNSS). The unique challenges of the IC required that some parts of the process be modified slightly and that certain minimum standards would be met. In many cases, these minimum standards are simply defining organizationally defined control and control enhancement variables at the overall IC level.

These unique processes and standards were published in the Committee on National Security Systems Instruction Number 1253, or CNSSI 1253. This document modifies portions of the RMF to be more in line with the way the IC protects systems and information. For example, the high-water mark process used by the RMF, which results in a single categorization of low, moderate, or high, was modified to result in a categorization determination for each one of the security objectives (confidentiality, integrity, and availability), resulting in more fine-grained control of the system’s security classification. This difference in the way systems are categorized results in the need to define a low, moderate, or high rating for each control and enhancement, as seen in Table D-1 in CNSSI 1253. Many of the organizationally defined variables are listed in CNSSI 1253, which also lists definitions of controls that the community has identified as good candidates to be common controls. While the IC is not required to determine information types using the process and information types listed in NIST SP 800-60, NSSI 1253 does recommend this process be used to assist in determining information system categorization. Organizations outside the intelligence community may find a good deal of useful information in CNSSI 1253. One of the tables from the document is reproduced in Appendix C of this book.

Implementation of the RMF in the Department of Defense (DoD)

While the DoD only recently transitioned from DITSCAP to DIACAP, it is currently undergoing another transition, this time to the Defense Information Assurance Risk Management Framework (DIARMF). Once complete, this transition will bring the DoD in line with the rest of the federal government. At that point, the entire federal government will be using a single process to assess and authorize information systems. Although this transition is still underway, many high-level officials see the advantage of using a single standard and understand the efficacy of the RMF, which make it the best choice for this single standard. As the transition progresses, the DoD will release new documentation detailing how to implement the DIARMF process and itemizing the timetables to transition from DoD Information Assurance Certification and Accreditation Process (DIACAP).

Implementation of the RMF in the Private Sector

It is easy to justify using the RMF in the government, as using it is a legal and regulatory requirement. Commercial organizations can also gain significant benefits from using the RMF to manage security requirements and compliance. In these organizations, the benefits can translate to improvements in efficiency and reductions in cost, resulting in better performance at a lower price while increasing compliance and security.

Most commercial organizations have detailed security settings, procedures, and compliance requirements that must be followed, based on organizational policy or directive. In these cases, the organization’s requirements take the place of the security control catalog (NIST SP 800-53) in defining the settings required to validate that a system is both secure and compliant with corporate policy. Organizational leadership and security staff are taxed with the additional task of determining the security classification of each requirement or control—high, moderate, or low—as the guidance provided by NIST in the control catalog will not be available for these unique company requirements. There may be company-required controls that are quite close to those defined by NIST, and in these cases, the categorization provided by NIST may be adequate.

Future Updates to the RMF Process

The basic structure of the Risk Management Framework will remain unchanged for the foreseeable future. This structure, the six-phase process of system categorization, control selection, control implementation, control assessment, system authorization, and continuous monitoring, will remain in place, with only minor changes based on the framework’s recent expansion across the entire federal government. Many of the supporting documents will change and expand as the framework expands and matures.

An excellent example of this change is the development of a newly expanded control catalog, NIST SP 800-53 Revision 4, titled Security and Privacy Controls for Federal Information Systems and Organizations. This document is in its final public draft version, but should be released in its final version by the time of this book’s publication. Once the final version is released, the total number of controls in the catalog will jump from about six hundred to more than eight hundred. These new controls provide an expanded depth to the RMF; they are listed in Table C-4 in appendix C. This does not mean that all of these controls will be used for every system, they will allow for greater flexibility in implementation of the RMF. This update and those to follow will primarily be as a result of expansion of the RMF process into new areas, the discovery of new threats, and the development and adoption of new technologies.

Security professionals responsible for system security and authorization must remain vigilant in maintaining the required skillset and knowledge required by the framework. This maintenance will ensure that the systems these professionals are responsible are as secure as possible and in compliance with all required controls.

Using the RMF with Other Control Sets and Requirements

The RMF has been developed to support systems that are seeking authorizations under the requirements of FISMA and other supporting legislation and regulations. This does not mean that the framework is only functional in this environment. Cloud computing is gaining wide acceptance in both the private industry and federal agencies. The Federal Risk and Authorization Management Program (FedRAMP) has been developed to facilitate securing cloud-based infrastructures. The health care industry must follow strict security requirements to ensure that patient data remains protected; both private industry and the federal government adhere to the Healthcare Insurance Portability and Accountability Act, which helps provide protection to patient data. The charge card industry protects financial data on millions of individuals; for this purpose, the payment card industry (PCI) protection standards have been developed. The following sections provide a high-level overview of these programs as well as insight on how the RMF can enhance these security programs.

FedRAMP

Over the past decade, the advantages of cloud computing have become more advantageous to both civil and federal information processing needs. Obvious advantages, including reduced operating costs, flexibility, and redundant recoverable systems, have driven many organizations to rethink traditional architectures and begin adopting cloud computing infrastructures. In implementing the Federal Risk and Authorization Management Program (FedRAMP), the federal government has developed a program that leverages the advantages of the Risk Management Framework and the security controls catalog (NIST SP 800-53). Instead of creating new security controls for cloud computing infrastructures and systems, FedRAMP has used the security controls catalog and developed two baselines of controls that support unique cloud implementations—low and moderate. Table C-5 in Appendix C illustrates these two baselines and includes the required controls for each. Using these baselines, cloud service providers and other information system owners using cloud-based technologies can use the RMF to gain authorizations to operate (ATO) cloud-based systems. It is important to note that the FedRAMP process adds additional requirements to the traditional RMF. More information on the FedRAMP process can be found at the GSA FedRAMP website, (http://www.gsa.gov/portal/category/102371).

The Health Insurance Portability and Accountability Act (HIPAA)

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 seeks to protect personal healthcare information by providing administrative, physical, and technical safeguards for this type of information. The Act provides guidance in the requirements for storing, processing, transmitting, and handling personal healthcare data. NIST has developed SP 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, to assist in correctly implementing HIPAA security rule requirements. This publication explains not only the requirements, but also generally explains the HIPAA legislation itself and provides detailed information on the security rule that focuses on electronic protected health information (EPHI). Table C-6 provides a mapping to the correct section of the HIPAA security rule for security controls defined in the security controls catalog.

NIST SP 800-66 details the procedure for correct compliance with HIPAA, including using the Risk Management Framework to ensure compliance with the required law. The use of the RMF for the security of HIPAA data provides an integrated methodical, repeatable, risk-based approach for selecting, specifying, and implementing security controls to adequately protect EPHI. In developing a program that secures HIPAA data, replace the controls selected in phase 1 of the basic RMF process with those controls required by the Act. The remainder of the framework remains the same.

Payment Card Industry (PCI)

The payment card industry (PCI) data security standard (DSS) provides protection of consumer credit card data and information. The standard was created to reduce the incidents of credit card fraud by increasing the amount of security controls around cardholder data. Qualified security assessors (QSA) use the twelve PCI DSS requirements to evaluate the security and compliance of a particular information system. These requirements and the six control objectives they are categorized into are listed in Table C-7 in Appendix C. To effectively comply with these requirements, organizations can use the Risk Management Framework by replacing the controls selected in phase 2 of the RMF with those required by PCI DSS, allowing this flexible framework to be used to ensure PCI compliance.

Use with Other Standards

The use of the RMF is not limited to FedRAMP, HIPAA, and PCI. There are numerous computer and information security and compliance requirements and standards across the globe. With only minor configuration changes, the Risk Management Framework can be used to ensure compliance with any of the major requirement sets published today. By using this structured framework, system developers, owners, security staff, and other stakeholders can ensure efficient and effective implementation and assessment of the required security controls. Management and senior leadership can be assured that the required controls are in place and protecting the information and information system as needed, allowing these officials to validate and approve systems prior to their being placed into the production environment. Risk management boards and groups can visualize and rationalize the organizational impact of placing systems into operation and understand the risk to the organization, business unit, system, and information, should the system begin operating. The RMF provides a single framework that can be used across multiple-requirement sets to effectively manage information system risk and its impact on the organization.

Conclusion

Implementing the Risk Management Framework is often a challenging and stressful process at first, but organizations that implement the framework correctly quickly realize this new process will not only save money, but also increase system development efficiency. Developing an organization-wide risk management process and a risk executive (function); identifying, assigning, and authorizing common controls; and correctly categorizing organizational and information system types can ensure that new and existing systems are not exposing the organization to unneeded risk, reduce duplication of effort, and ensure that security controls are baked into the system engineering and design processes. Organizations that expect to replace their existing certification and accreditation programs with the RMF without changing organizational mindsets and processes will struggle with implementing the framework and will most likely increase the cost of system development and decrease efficiency, resulting in longer systems completion times, delayed release schedules, and, often, less secure systems overall.