Cloud Compliance - At the Speed of Government

A look at the absurdity and self-imposed limitations of Federal Cloud Compliance Cycles and Timelines

If you’re in the Federal IT/Cybersecurity community like me, you undoubtedly saw the news recently announced by the Federal Risk and Authorization Management Program (FedRAMP) that they released their new security control baselines, to align with the overarching National Institute of Standards and Technology (NIST) 800-53 Security and Privacy Controls for Information Systems and Organizations, which is on Revision 5.

My LinkedIn feed was full with people celebrating the announcement.

Some with a real experience and expertise in the Federal Cloud Compliance space, and others just looking for social media fodder and to stoke their desire to pursue business opportunities in the space without any real cloud security and compliance experience, but I digress.

The circular congratulatory and back patting seems exciting at first, until you step back and realize the absurdity of the process and timelines involved, as well as the impact on both the Government cloud consumers and the CSP’s that are governed and bound by FedRAMP.

NIST 800-53 essentially serves as the authoritative source for security controls for Federal IT systems, being used to tailor security control baselines for Federal systems or systems processing Federal data. They generally manifest in the form of Low, Moderate and High baselines, with each level having an increased number of security controls and associated control enhancements.

FedRAMP, which is a program the U.S. Federal Government uses to assess and authorize Cloud Service Providers (CSP)’s for Federal consumption and use, derives their security control baselines largely from the overarching NIST 800-53 series.

NIST originally published 800-53 r5 in September of 2020.

This means it took roughly 32 months or nearly 3 years for the FedRAMP PMO to update their security control baselines from NIST 800-53 r4 to r5. When you factor in the implementation timeline, which we will discuss below, it brings it to 3 full years, and essentially 50% of the lifespan (based on previous 800-53 update cycles by NIST) of NIST’s 800-53 r5 was eaten up by the time it took the FedRAMP PMO to merely adopt and update their own security control baselines.

Implementation Timelines and Sending the Wrong Message

While the timeline for the FedRAMP PMO to release the updated FedRAMP Baselines derived from NIST 800-53 r5 was measured in years (32 months roughly), ironically, the implementation timeline for CSP’s is measured in months. They have until September 1st 2023 to identify gaps from their existing r4 implementation contrasted against r5, then by October 2nd 2023 they have to update plans and then during POAM management or their next assessment they will be assessed against the implementation statements for r5.

On one hand I’m an advocate of this because many of the additional controls are things that CSP’s, especially the more mature CSP’s should be doing already, not to mention enough time has already been wasted, but it also sends the wrong message to industry.

It has a sense of “do as I say, not as I do”, with industry having just a handful of months to migrate their service offerings and associated compliance artifacts and FedRAMP packages to the new requirements, while the FedRAMP PMO themselves took years to do so.

Supply Chain Security Matters, Sort Of?

Another ironic aspect of this timeline of activities is that we can’t turn a corner in the Federal space or broader IT/Cyber industry right now, without hearing about Software Supply Chain Security and more broadly, Cybersecurity Supply Chain Risk Management (C-SCRM).

We have seen a flurry of guidance and requirements (much of which we have discussed extensively on this newsletter/blog) such as the Cybersecurity Executive Order (EO), OMB Memos, an updated NIST Secure Software Development Framework (SSDF), CISA Secure Software Self-Attestation Forms and of course the National Cyber Strategy (NCS), all of which emphasized the importance of securing the software supply chain.

The publication of NIST 800-53 r5 introduced the Supply Chain Risk Management (SCRM) or “SR” family of controls in the NIST 800-53 catalog, which of course FedRAMP is derived from.

This means while that same flurry of requirements and publications was occurring around software supply chain security, CSP’s governed by FedRAMP will have had a 3 year period where the entire SCRM or SR control family wasn’t in their required security control baselines, and therefore not required.

This is despite Cloud and SaaS being a significant attack vector and avenue of malicious actors looking to compromise the software supply chain. CSP’s serve millions of customers, countless organizations and serve as a significant concentration of risk in our ecosystem, with some even advocating that CSP’s be considered “Critical Infrastructure” themselves, due to the societal dependence we now have on them, including within the Department of Defense (DoD) and Intelligence Community (IC).

Smuggling Past Emerging and Relevant Requirements

Another interesting angle is that CSP’s and Cloud often experience a bit of being smuggled in through the backdoor as it relates to emerging requirements. For example, in the DoD space, it is required that a CSP a Defense Industrial Base (DIB) firm use be FedRAMP authorized, or at least FedRAMP equivalent (whatever the hell equivalent means is an open ended can of worms that I enjoy watching and debating with fellow peers on LinkedIn).

Additionally, the emerging OMB 22-18 memo and CISA Secure Software Self Attestation form having ambiguous language that potentially allows organizations that are FedRAMP authorized/assessed by a 3PAO to avoid needing to go through additional rigor.

This is ridiculous for several reasons. The first is that FedRAMP doesn’t encompass the breadth of the NIST SSDF nor CISA Secure Software Self Attestation form requirements, and secondly because the FedRAMP baselines as we’re discussing here didn’t even include the SR control family into 32 months after their introduction by NIST.

For example, DoD’s Defense Federal Acquisition Regulation Standard (DFARS) 7012, which is generally included in contracts and subcontracts governing Controlled Unclassified Information (CUI) has a section D which states:

(D) If the Contractor intends to use an external cloud service provider to store, process, or transmit any covered defense information in performance of this contract, the Contractor shall require and ensure that the cloud service provider meets security requirements equivalent to those established by the Government for the Federal Risk and Authorization Management Program (FedRAMP) Moderate baseline (https://www.fedramp.gov/resources/documents/) and that the cloud service provider complies with requirements in paragraphs (c) through (g) of this clause for cyber incident reporting, malicious software, media preservation and protection, access to additional information and equipment necessary for forensic analysis, and cyber incident damage assessment.

This means that emerging requirements for securing the software supply chain in the Federal space as well as existing ones allow CSP’s to avoid relevant requirements and control families that directly address supply chain risk management. If you can make sense of that one, let me know.

I’ll also add that despite the requirements for CSP’s being used by the Federal Civilian Executive Branch (FCEB), DoD and the DIB entities to be FedRAMP authorized (or equivalent in the case of DFARS 7012) the use of non-FedRAMP’d SaaS is rampant, but that’s a discussion for another day.

We also have seen increased calls for CSP’s to be treated as “Critical Infrastructure”, which acting National Cyber Director, Kemba Walden, making statements pointing out that the cloud “has become essential to our daily lives” and that its disruption “could create large potentially catastrophic disruptions to our economy and to our government”.

Similar statements have been made by the former Executive Director of the Cyberspace Solarium Commission, Mark Montgomery, including on a recent episode of the Resilient Cyber Podcast where I interviewed him and brought up the topic.

So we have what leading industry experts and national leaders consider to be critical infrastructure and services that could cause potentially catastrophic disruptions to our economy and society entirely immune for the last three years when it comes to supply chain risk management security controls in the FedRAMP baseline, which governs what CSP’s are authorized for use by our Federal Government and Department of Defense.

Summary

So to wrap it up, we watched the FedRAMP PMO take nearly 50% of the potential lifespan of NIST 800-53 r5 to update their own respective FedRAMP security control baselines.

We also watched CSP’s go nearly 3 years entirely immune and ungoverned by the Supply Chain Risk Management (SCRM) security control family, at the same time while we’ve seen a 742% increase in software supply chain attacks, with malicious actors increasingly seeing CSP’s as a concentrated target that can have a broad impact, including on Federal customers and consumers.

You could make this stuff, but there’s no need, as the truth is indeed often stranger, and more perplexing, than fiction.

We recently saw the passage of the FedRAMP Authorization Act, as well as the creation of Federal Secure Cloud Advisory Committee. I’ve written extensively about the act in an article here, and the announcement of the FSCAC committee members can be found here.

To say I remain cautiously optimistic that we will see significant changes and improvements would be putting it lightly, but I do remain optimistic, because the Governments digital transformation and ultimately national security relies on utilizing cloud effectively, securely and expediently.

I also recently helped co-found a grassroots industry group of cloud security and compliance leaders with extensive public sector experience, where we’re trying to help advocate for change and innovation in the space. The group was originally dubbed the “FedRAMP Advisory Board”, is open to anyone who wants to participate and more information can be found here.