The federal path: RMF, FedRAMP and the ATO

Where you are

Lessons 3 to 5 were about controls and evidence: building them, recording them, checking them automatically. This lesson is about where all of that ends up in US federal work. Every system a federal agency runs, and every cloud service it buys, has to be formally approved before it goes live, through a process with its own steps, documents, roles and acronyms.

If you're applying for roles in the Washington, DC area, this is the vocabulary that job descriptions assume: "RMF", "ATO", "SSP", "POA&M", "ConMon". By the end of this lesson, each one will be a plain idea.

A certificate of occupancy

Before anyone can move into a new building, the city has to sign a certificate of occupancy. Getting one follows the same path everywhere. You decide what kind of building it is, a garden shed or a hospital, which decides which building codes apply. You submit plans showing how you'll meet each one. An inspector checks the building against the plans and writes up what they find. Anything that isn't right yet goes on a list, with dates for fixing it. Then a city official, weighing it all up, signs: people may use this building. And the inspections don't stop there.

That's the federal process almost exactly. In the language of this lesson:

Keep that table in mind; the rest of the lesson fills it in.

The Risk Management Framework

The process is called the RMF (Risk Management Framework), defined by NIST in SP 800-37. It has seven steps, and it's a cycle, not a line: the last step feeds back into the first.

In plain words:

1. Prepare. Agree who's responsible for what, and what the organisation's risks are.
2. Categorize. Decide how bad it would be if the system's data leaked, was changed, or became unavailable. The answer is Low, Moderate or High, and you'll try it below.
3. Select. Pick the controls, starting from the NIST 800-53 baseline that matches the category, then adding or adjusting for this system.
4. Implement. Build them, and describe how in the SSP. This is the engineering from Lessons 3 to 5.
5. Assess. An independent assessor checks that each control works, and writes the SAR.
6. Authorize. A senior official looks at the risk that's left, and decides whether to accept it: the ATO.
7. Monitor. Keep checking the controls, track changes, fix findings, and report regularly. For the life of the system.

Categorize: how bad could it be?

Categorizing uses a standard called FIPS 199 (Federal Information Processing Standard 199). For each of the three classic security goals, you ask how bad a failure would be, and rate it Low, Moderate or High:

• Confidentiality: the data seen by the wrong people.
• Integrity: the data changed without anyone knowing.
• Availability: the system or its data unavailable when needed.

The system as a whole takes the highest of the three, called the high-water mark. One High makes the whole system High, however low the other two are. Try it:

The category isn't a label for its own sake. It picks the baseline, and the baseline decides how much work there is: going from Low to Moderate roughly doubles the number of controls. That's why categorizing carefully matters. Over-rate a system, and you spend months on controls it doesn't need. Under-rate it, and it's not protected enough, and the assessor will say so.

The three documents

Three documents carry the whole process, and you'll hear their acronyms in any federal team:

• SSP (system security plan). The plans for the building: what the system is, where its boundaries are, and for every control in its baseline, how it's met. An SSP for a Moderate system often runs to hundreds of pages. Engineers write much of it, because only they know how each control is actually built.
• SAR (security assessment report). The inspector's report: what the assessor tested, how, and what they found. Every control that doesn't work as the SSP describes becomes a finding.
• POA&M (plan of action and milestones). The fix list: every open weakness, from the SAR, from scans or from monitoring, with who owns it, how it'll be fixed, and by when. An open POA&M isn't failure; every real system has one. An ignored POA&M is.

Here's what one control looks like in an SSP. It's called a control implementation statement, and writing these well is one of the most practical federal skills an engineer can have:

SC-8  Transmission Confidentiality and Integrity
Status: Implemented

All traffic between users and the API is encrypted with TLS 1.2 or
higher. Plain HTTP requests are refused at the edge by a firewall rule
that blocks any request to the API that is not HTTPS. The certificate
is issued and renewed automatically every 90 days. A scheduled job
tests both HTTP and HTTPS daily and keeps the results as evidence.

Responsible role: Platform engineering
Evidence: daily test results; firewall rule configuration

This one is an example, for an API like CivicGrid's; yours would describe your own system. It says what's in place, specifically enough that an assessor can test it, who's responsible, and where the evidence is. Vague statements like "the system uses encryption" are the commonest reason for findings.

The ATO: a decision, not a certificate

The ATO (authority to operate) is the moment the RMF is built around, and it's often misunderstood. It isn't a pass mark from the assessor. It's a decision by a named senior official, the AO (authorizing official), who reads the SSP, the SAR and the POA&M and says, in effect: "I understand the risk that's left, and I accept it on behalf of the agency." A system can get an ATO with open findings, as long as they're on the POA&M and the AO accepts them.

Two more things are worth knowing:

• ATOs have limits. Traditionally an ATO lasted a fixed period, often three years, then the whole process ran again. Many agencies now use ongoing authorization: the ATO stays valid as long as continuous monitoring shows the controls still work. The Department of Defense calls a strong version of this cATO, a continuous ATO, for teams with highly automated pipelines and evidence.
• Changes can need re-approval. A significant change to the system, like a new kind of data or a big architecture change, may need the AO's sign-off again. This is where Lesson 4's change records pay off.

Around the AO, you'll meet a few other roles: the system owner, responsible for the system; the ISSO (information system security officer), who runs its security day to day and is often the engineer's closest contact; and the assessor, who must be independent of the team that built it.

FedRAMP: the same process, for the cloud

FedRAMP, from Lesson 2, is the RMF applied to cloud services that many agencies can share. The steps are the same, with some differences in who does what:

• The cloud company writes the SSP and implements the controls, against a FedRAMP baseline built on NIST 800-53 Low, Moderate or High.
• An accredited 3PAO (third-party assessment organization) does the assessment.
• The usual route is that an agency planning to use the service sponsors it and grants the authorization. The service is then listed on the FedRAMP Marketplace, so other agencies can reuse that work instead of starting again.
• After authorization, continuous monitoring is a duty, not a suggestion: regular vulnerability scans, POA&M updates sent in every month, and yearly assessments.

That monthly rhythm is where many cloud engineers in federal work spend their time: patching what the scans found, closing POA&M items, and producing evidence on schedule. And it's exactly what FedRAMP 20x, from Lesson 2, is trying to automate: replacing paperwork with machine-readable evidence collected continuously, like the daily job in Lesson 4.

Spot the problem

Three situations from real federal programs. Work out what's wrong before you read the explanation.

The three-year sleep. A system gets its ATO, and the team celebrates. For the next three years, nobody looks at the security controls; the POA&M isn't updated, and the scans stop. When the ATO comes up for renewal, the assessment finds dozens of new problems. What went wrong? The team treated the ATO as the finish line. Step 7, monitor, was skipped entirely. An authorization is only as good as the monitoring that keeps it true, which is why so many agencies have moved to ongoing authorization.

The copied SSP. To save time, a team copies large parts of its SSP from another system's. The assessor tests a control described as "multi-factor authentication is required for all users", and finds that this system doesn't have MFA at all. Why is this worse than a simple missing control? A missing control is a gap, which goes on the POA&M. A plan that claims a control exists when it doesn't is an inaccurate statement to the authorizing official, who is making a decision based on it. It damages trust in the whole SSP. Write each implementation statement from the real system, and mark controls honestly as implemented, partly implemented or planned.

The POA&M that never moves. A system's POA&M has forty items. Thirty of them are more than a year past their due dates, and nobody is named as responsible for most. Is this a problem if the system still has its ATO? Yes. The AO accepted those risks on the understanding that they'd be fixed by those dates. Overdue items with no owner mean the risk the AO accepted isn't the risk that exists. Every POA&M item needs an owner, a realistic date, and updates, and a missed date needs a new plan, not silence.

Where you are now

You can walk through the seven RMF steps, categorize a system with FIPS 199 and the high-water mark, explain the SSP, SAR and POA&M, and say what an ATO really is: a named official accepting the risk that's left, kept valid by continuous monitoring. You know how FedRAMP applies the same process to the cloud. Lesson 7 puts the whole track together: CivicGrid against a handful of real NIST 800-53 controls, with the evidence, the gaps and a POA&M of its own.

Check yourself

Key terms

• RMF (Risk Management Framework): NIST's seven-step process for authorizing federal systems, in SP 800-37.
• FIPS 199: the standard for rating confidentiality, integrity and availability as Low, Moderate or High.
• High-water mark: the system takes the highest of its three ratings.
• SSP (system security plan): how the system meets each of its controls.
• SAR (security assessment report): what the assessor tested and found.
• POA&M (plan of action and milestones): open weaknesses, with owners and dates.
• AO (authorizing official): the senior official who accepts the remaining risk.
• ATO (authority to operate): the AO's decision that the system may run.
• ISSO (information system security officer): the person running a system's security day to day.
• 3PAO (third-party assessment organization): FedRAMP's accredited independent assessors.
• Continuous monitoring: checking controls for the life of the system, not just before the ATO.

Go deeper

• NIST's Risk Management Framework (opens in a new tab) pages, with a short guide to each of the seven steps.
• FedRAMP 20x (opens in a new tab), for where the federal process is heading.