Security Control Baseline Selection

The sections that follow walk through many of these tasks in roughly the order a team typically encounters them. As you read, keep the following principles in mind:

​

• ATO is not a technical certification. It is a personal risk acceptance by the AO. They are asking, “Do I understand the risks well enough to put my name on this?” That’s why transparency matters more than perfection and why hand-waving is fatal. You do not need zero findings. You need no unacknowledged findings.

​

• Once authorized, you enter continuous monitoring. Controls are reassessed incrementally and evidence becomes automated over time. Only after this point does continuous ATO (cATO) become realistic. cATO is an optimization of trust, not a shortcut to it. This article does not go in depth on cATO; we focus on what you might need required for initial ATO.

​

[BASE-1] Know whether you need RMF, FedRAMP, or CMMC

RMF authorizes systems, CMMC certifies contractors, and FedRAMP authorizes cloud services. One of the most common (and expensive) early mistakes in defense software is solving the wrong compliance problem. RMF, CMMC, and FedRAMP address different risk questions, apply to different system boundaries, and are enforced by different authorities.

​

Risk Management Framework (RMF)

The Risk Management Framework (RMF), formally National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37, governs systems that operate within, or connect to, Department of War environments. The Department of War (DoW) has acknowledged a reality that engineers have lived for years: RMF often results in a static, “paperwork-first” process that is fundamentally incompatible with modern CI/CD and rapid operational tempos. Despite our hope that reform initiatives like Software Fast Track Initiative (SWFT), Cybersecurity Risk Management Construct (CSRMC), Software Acquisition Pathway (SWP), and Continuous ATO (cATO) will succeed, RMF is still the only legally recognized path to ATO per DoD Instruction (DoDI) 8510.01 (Risk Management Framework for DoD Systems, 19 July 2022). (For more details on these reform efforts, see Appendix A – Understand the RMF reforms on the horizon.)

​

RMF is concerned with whether a specific system, in a specific operational context, implements adequate security controls from NIST SP 800-53 to sufficiently manage cybersecurity risk. The outcome of RMF is either an Authorization to Operate (ATO) or an Interim Authority to Test (IATT) issued by an Authorizing Official (AO) for that system boundary. This article will focus on pursuing ATO/IATT under RMF.

​

You can find general information about RMF online, but we found this chart quite instructive on the whole process:​​

Cybersecurity Maturity Model Certification (CMMC)

Cybersecurity Maturity Model Certification (CMMC) is fundamentally different, as it does not authorize systems. It certifies that a contractor’s corporate networks and internal IT environments adequately protect DoW data outside DoW-controlled systems. Its scope is limited to environments that store or process Controlled Unclassified Information (CUI) or Federal Contract Information (FCI) on contractor-owned infrastructure.

​

Federal Risk and Authorization Management Program (FedRAMP)

Federal Risk and Authorization Management Program (FedRAMP) enters the picture when cloud service providers are involved. FedRAMP is the U.S. government’s standardized authorization framework for commercial cloud services used by federal agencies. If you are offering a SaaS product and hosting it in your own cloud environment, FedRAMP may be required. However, if your system is deployed into a DoW environment or a DoW-managed cloud and authorized under RMF, FedRAMP is often irrelevant to you as the application developer.

​

[BASE-2] Define preliminary authorization boundary

The authorization boundary is the line that tells the AO exactly what you are asking them to trust. It defines who is responsible when something goes wrong. If a component is inside your boundary, you own its vulnerabilities, incident response, and compliance drift, regardless of whether it is “just managed by another team” or “mostly handled by the platform.”

​

If you’re just trying to get your software deployed into a DoW space, then your best goal is to focus just on your software and try and inherit as much security posture as possible from an existing hosting platform. There may be various options for this, but a containerized Kubernetes-based DevSecOps platform (Party Bus, Big Bang, UDS, etc.) has become increasingly common to help maximize security control inheritance and minimize extra work to deploy new software applications.

​

[BASE-3] Select applicable security controls

Controls are selected by means of a control baseline, which is a reference model that defines the set of risks an Authorizing Official expects to reason about for a given class of system.

​

At this point, engineers often make a critical mistake: they treat the control baseline as a checklist of security features that must be fully implemented before any software can be deployed. That is not how Authorizing Officials actually use a baseline, particularly in today’s push to deploy software faster.

​

While RMF baselines are often treated operationally as checklists, their original intent, and increasingly the way many AOs reason about them, is as a shared risk vocabulary. They provide the reference frame the AO needs to understand what protections exist today, what is missing, and what risk is being consciously accepted in order to field capability quickly.

​

This distinction matters because initial authorizations are rarely about perfection. There is no generally correct answer to the question, “what is the minimal we can start with, regardless of baseline,” because authorizations are not issued against an abstract notion of reasonable security. They are risk acceptance decisions, made by a specific Authorizing Official, for a specific mission, against a specific baseline and risk tolerance. Incremental deployment works precisely this way: software is authorized not because it meets some universal minimum, but because its risks are clearly articulated, bounded, and consciously accepted for the intended scope of use.

​

Control baselines flow from the System Security Categorization (SSC) under Federal Information Processing Standards (FIPS) 199, which in DoW practice is operationalized through Committee on National Security Systems Instruction (CNSSI) 1253. You assess the impact of compromise on Confidentiality, Integrity, and Availability on a Low/Moderate/High scale, and the highest of the three becomes your SCC. As a rule of thumb, any system that touches classified information will likely have High SSC, while systems handling CUI are more commonly Moderate.

​

CNSSI 1253 maps the SCC to a baseline control set derived from NIST SP 800-53. Your specific customer might require overlays that add, remove, or tailor controls based on mission, environment, or data sensitivity.

​

An individual NIST SP 800-53 control looks like the following:

And controls frequently include one or more control enhancements, which increase rigor or scope depending on the baseline. When specified by the baseline, enhancements are not optional and carry the same accountability as the parent control. Here’s an example of enhancements to a control: