devsecops

Continuous Authorization to Operate (cATO) needs a DevSecOps platform

,

Written by Chris Cropper and Rita Manachi  

Several branches of the U.S. federal government have been steadily announcing a slew of executive orders and bills focused on IT modernization and improved cybersecurity. Federal agencies across the board are racing to maintain digital relevance in a dynamic and rapidly changing landscape. This is certainly true at the Department of Defense (DoD) whose modernization strategy focuses on strengthening its ability to deliver good software quickly and securely. 

While the DoD has been embracing modern DevSecOps practices and principles, the agency recognized there are some processes that still hinder its mission to “modernize its approach to software development and delivery to keep pace with the constantly changing threat so that it can deliver resilient software capability at the speed of relevance.” [SOURCE: Department of Defense DevSecOps Continuous Authorization To Operate Implementation Guide]

ATO does not have to mean DOA 

One such process is the Authorization To Operate (ATO).  Known to be especially lengthy and painful, ATO gives any piece of software or hardware running on a DoD system permission to operate on those systems. It’s essentially a verification that the thing you are running on the system has met several requirements related to data protection, federal regulations, and general safety, to name a few. 

In response, the Department of Defense (DoD) CIO office recently released the official DevSecOps Continuous Authorization Implementation Guide which applies to all DoD information systems. Here’s how they sum it up:

Many DoD Components identify obtaining an Authorization to Operate (ATO) as the longest step in developing and deploying software. Delivering new features rapidly requires an authorization process that can keep pace with continuous change for a developing capability— called Continuous Authorization to Operate (cATO). An organization with a cATO is allowed to continuously assess and deploy subsystems that meet the risk tolerances for use within a system authorization boundary. A cATO moves away from a control assessment point-in-time approach to focusing on continuous risk determination and authorization through demonstrated continuous assessing, monitoring, and risk management.

Turning compliance into a superpower

The goal of cATO, as we understand it, is to maintain strong security postures AND move quickly. Within the definition of cATO is the idea that “traditional risk assessments and authorizations become redundant.” Redundancy may seem like the antithesis to speed, in this case we can interpret it to mean re-usability in the service of scale. By building a repeatable process on a validated platform teams can not only get their software into production more quickly and safely, but also keep up with changing regulatory requirements and delivery software at the speed of relevance! This is true to any public sector agency or private enterprise functioning in a highly regulated environment.    

The Tanzu Labs Modern Compliance Architects team helps organizations in highly regulated industries, including the DoD, to understand and articulate the hundreds of NIST security controls and requirements, and fast-tracking their ATO process, in some cases reducing the time it took to achieve ATO from months to weeks. With a combination of deep knowledge of privacy and security controls outlined in the NIST 800-53 standard and expertise in drafting policies that include inherited controls the MCAs can reduce the number of Application Security and Development STIG questions from hundreds to less than 40. By simplifying RMF requirements, our clients turn compliance into a superpower.    

A secure platform is the foundation for cATO

The cATO memo highlights three main competencies that must be met for cATO. They are continuous monitoring (CONMON), active cyber defense (ACD), and DevSecOps with Secure Software Supply Chains (SSSC). Before exploring those it’s important to know that the implementation guide assumes you’re running on an RMF-accredited platform that has already achieved ATO. Specifically, “systems seeking a cATO must have already achieved an Authorization to Operate (ATO) and have entered the Risk Management Framework (RMF) monitor state”, essentially implying that an organization cannot simply stand up a new platform and receive cATO accreditation without being fully accredited under RMF. For a platform to serve as the foundation for your applications it must meet specific RMF requirements as defined by NIST. The requirements are grouped in Control Families to address multiple aspects of a security framework, including  access enforcements, information flow, separation of duties, information sharing, data mining protection, and information sharing, among others. 

Running on an accredited platform lets you consolidate the security controls at the platform level leaving the application level – and the developers responsible for building them – to focus on releasing code with minimal friction.When you run on an accredited platform, the applications running on the platform only need to meet the  Assess Only requirements and demonstrate minimum vulnerability analysis because they applications inherit security capabilities and posture from the platform.

Figures 1 and 2 below are simple diagrams that show how Tanzu Platform can help with that.

cATO: active, automated, repeatable  

The competencies for cATO are rooted in regular collaboration between platform engineering, security and dev teams, an active prevention and recovery strategy and comprehensive automation. Essentially the hallmarks of DevSecOps. Let’s explore some of the competencies described in the cATO memo with examples of how Tanzu Platform can help support them.  

Continuous monitoring
Some attributes of continuous monitoring include near real-time reporting and analysts of the application landscape throughout the entitle lifecycle. This requires certain levels of automation and cross-team agreement on policies and adoption of DevSecOps practices as well as regular testing of the system and process.  

Tanzu Platform 10 provides end-to-end observability, allowing platform teams to monitor the entire application lifecycle. From initial code commits to production deployment, you’ll have comprehensive insights into performance, errors, and resource utilization.

Active cyber defense  
Active cyber defense requires a “shift security everywhere” ethos whereby everyone involved from the first line of code to updating and patching in production. Automation plays an important role in ACD. Platform engineers can, for example, enforce policies and requirements set by governing authorities and/or industry regulators at scale. With Tanzu Platform tasks like vulnerability patching, rolling upgrades, and policy enforcement can be automated. Meanwhile, developers can automate secure container builds, bind services to apps and deploy code with simple commands with confidence that they are adhering to their organizations security standards. The crux of the Tanzu Platform’s security-enhancing capabilities is the 3Rs concept: rotate, repave, repair which you can learn more about here.  

DevSecOps/SSSC
The approved reference design for a software factory is a great place to start for an outline of a DevSecOps type operating model. The DoD makes specific mention of secure software supply chains, automated image scanning, continuous testing, and quick mitigation critical to secure software supply chains. There is also a special focus on the Software Bill of Material (SBOM). 

SBOMs are a must for app dev and platform teams, and in some highly regulated industries a matter of regulation. Mandates on SBOM usage have been released from the FDA, Department of Homeland Security, the U.S. Army, PCI-DSS, CISA, the NSA and the Office of Management and Budget, to name a few. 

Tanzu Platform 10 includes multiple features and capabilities including automated SBOM generation via Buildpacks and Tanzu Application Catalog, and SBOM analysis to identify dated libraries and bad imagines or containers. Developers also get a quick view of what actions are needed to update their application code. Meanwhile, platform engineers can keep their libraries up to date and enable continuous platform upgrades to mitigate security risks. 

Successful DevSecOps adoption requires a continuous upgrade culture. With the right platform and operating model.  

Continuous Learning
To learn more about how to foster continuous compliance and security in your digital operating model check out the resources linked below. If you operate in a highly regulated environment you’ll find insights into embracing operational change, technology adoption, and practical stories from your peers. 

If you are attending the ISC2 Security Congress next week be sure to check out Did You Think About Your Inheritance Today? Rethinking Inheritable Control and say hi to Chris who is presenting with Angelica Phaneuf, CISO of the Army Software Factory.  

Related Articles