Integrating the Risk Management Framework (RMF) with DevOps

Information security should be at the heart of every system launched. In accordance with the Federal Information Security Management Act (FISMA), an information technology system is granted an Authority to Operate (ATO) after passing a risk-based cybersecurity assessment.

The ATO Problem

However, the ATO process can pose several challenges to the modern DevOps processes, as it requires an authorizing official (AO) to approve systems against a preset of risk controls before putting the systems into operation. An ATO is typically valid for three years based on the assumption that the system’s cybersecurity posture will not change significantly during that period. This assumption is often unrealistic, making the “set and forget” ATO inadequate. As a result, the need to reassess and reauthorize the system negatively impacts the overall cost and schedule of delivering it to the end-users. What is more, it is contrary to the DevOps agile principles of:

• embracing continuous integration, testing, and delivery
• embedding operations in team to internalize expertise on delivery and maintenance

The Risk Management Framework (RMF) Solution

According to a Carnegie Mellon University study, the Risk Management Framework (RMF) suggests an alternative approach to the traditional three-year ATO process through ongoing authorization decisions or continuous reauthorization. Dubbed NIST SP 800-37, the guide for “Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach” offers a structured process to secure, authorize and manage IT systems. RMF defines a process cycle that is used for initially securing the protection of systems through an Authorization to Operate (ATO) and for integrating ongoing risk management (continuous monitoring). The RMF transforms the traditional Certification and Accreditation (C&A) process into a six-step procedure that integrates information security and risk management activities into the system development lifecycle. These steps are:

• Step 1: Categorize Information Systems
• Step 2: Select Security Controls
• Step 3: Implement Security Controls
• Step 4: Assess Security Controls
• Step 5: Authorize Information System
• Step 6: Monitor Security Controls

RMF assumes these systems have “been evaluated as having sufficiently robust system-level continuous monitoring programs” and that they seamlessly align with core tenets of DevOps, subsequently paving the way for DevSecOps.

Security in DevOps

Security is often focused on the testing phase of software development, and security activities are often conducted outside and apart from the software development process. As a result, the outcomes of security activities are presented in documents that do not fit any of the software development activities. The goal should be to guide the development of new activities and adjust existing ones to make it efficient to build security into an agile process. Incorporating security activities into the software development lifecycle (SDLC) helps development teams seamlessly integrate security and compliance functions into their regular workflows by inserting the necessary steps into the continuous integration/continuous delivery (CI/CD) pipeline.

Benefits of Continuous Reauthorization

This is where RMF’s continuous reauthorization concept comes in handy, because it directly aligns with the DevOps four primary focus areas:

• Collaboration between teams and roles
• Infrastructure as Code (IaC) to create a scripted infrastructure configuration
• Automation of tasks, processes and workflows
• Monitoring of applications and infrastructure

Continuous reauthorization changes the perspective of authorization from an event to a process and makes systems more secure because it

• reduces errors during development,
• provides continuous feedback and monitoring,
• is always available,
• is repeatable,
• reduces time to deploy and resolve errors, and
• is responsive to business needs.

It is critical to involve security and operations teams in the initial, as well as routine, pipeline-related activities to ensure that the right security steps are built into the pipelines. Consistent collaboration between the teams help to build and reinforce trust in the pipeline(s) used in software development. Laying out the security requirements early in the software development process helps developers weave the necessary security protections into their workflows and establish delivery pipelines that security teams trust. Automating processes and workflows minimizes defects due to human error, and app developers can deliver higher performing and better-quality products by embedding automated security controls and tests into their pipelines. They also avoid bottlenecks and deliver capabilities faster by automating the tasks and approval gates that really do not require a human intervention.

Security as an Enabler

Many believe that security is an impediment to software delivery, an inevitable blocker. However, the truth is that security can promote speed at DevOps scale. Properly integrating security into DevOps accelerates software delivery because security checks are completed, and defects are corrected continuously throughout the SDLC. This is good news for everybody. Developers see their products make it into deployment faster. Security teams can more easily authorize the system since it has been developed in compliance with organizational policy. Operations teams inherit a system that is worthy of running on their network. In addition, security teams gain transparency and useful insights at every step of the SDLC through audit trails, governance measures and real-time compliance reporting without waiting for developers to generate and share reports post-development. Those continuous insights, coupled with the confidence of trustworthy pipelines, eliminate wasteful back-and-forth between the security office and development teams as well as result in much quicker ATO. When security is fully integrated into the full Software Development, Maintenance and Operational lifecycle, a sufficiently robust system-level continuous monitoring program can be demonstrated to achieve a continuous reauthorization. You may read the full Carnegie Mellon University paper here, or you may learn more about RMF and how to apply it in your programs by reading our whitepaper: “Adjusting to the reality of the RMF.”