Cloud Service Providers (CSPs) new to FedRAMP immediately stumble into one of FedRAMP’s most perplexing challenges: How to properly define an authorization boundary.
Boundary definition is always tricky. It’s especially complicated when it comes to development environments. Security measures in dev environments obviously impact production security posture. But applying all the FedRAMP controls to dev complicates life for modern development teams.
In part one of this two post series, we’re going to discuss how to build and maintain a FedRAMP-friendly development environment.
Yes, You Need a Dev Environment
Let’s get this out of the way early on: we’ve seen CSPs that want to die on the “don’t-need-a-dev-environment” hill. Which is exactly what their FedRAMP hopes and dreams will do without a dedicated development environment.
Can I point to any single control in the FedRAMP baseline or NIST 800-53a that states “thou-shalt-separate-dev-and-prod”? No.
But, from patch testing requirements in SI-2, to the entire Configuration Management family and even extending to elements of Access Control, there are numerous FedRAMP controls that you won’t realistically pass without a dedicated development environment.
So yes, you will need to separate dev and prod if you want to earn FedRAMP-authorization, at any level.
A Modern Approach to Dev Security
However, this does not mean that you need to bring dev within the system boundary and apply all the FedRAMP security controls. Per the current FedRAMP boundary guidance “Development environments that do not process, store, or transmit federal information” may be excluded from the authorization boundary, at the Authorizing Official (AO)’s discretion.
In practice, this conditionally frees development environments to adopt processes and tooling that would be difficult in-boundary. Love Agile development? No problem. Operate a slick CI/CD pipeline process? You do you (though, we’ll talk about the CD part in a sec). Wedded to a bunch of nifty DevOps tools? We can probably make it work.
Building a FedRAMP Friendly Dev Environment
But dev can’t be a free-for-all. There are two major caveats to the FedRAMP boundary guidance that can drag a dev environment back into scope.
Just Say No (to Fed Data)
Unless you want a one way ticket to boundaryville, dev environments can’t process, store or transmit federal information. At first glance this looks easy: don’t use live system data from federal customers in dev. Done.
Right?
Not quite. In FedRAMP world, the term “federal information” is pretty broad. It includes not just federal data directly owned by fed customers, but also system metadata. Hostnames, ticketing info, custom configs, security documentation, vulnerabilities and a whole slew of other system-related data can all count as federal information.
You can probably start to see how this complicates things.
AO God Mode
Agency AOs get to decide if dev will be excluded from the boundary. Your AO having a bad day? Dev is in.
So if you want to keep dev out, you’re going to need to show a lot of security maturity around development processes. This will be especially true after the Biden administration’s Executive Order on Cybersecurity, which encourages enhanced scrutiny of software development processes.
So you’re going to need to bring your A game to dev security if you want to keep your AO happy.
What To Do
Here at 38North, we separate our guidance into required minimums and best practices. Required minimums will likely get you past an audit, while best practices will showcase maturity and fast track your authorization.
You Gotta Get Down to Get Out
These are the bare minimum requirements your dev environment needs to meet if you don’t want it dragged back into the boundary.
CD-Light
In the post NotPetya/SolarWinds/Etc. era, controls surrounding the push from dev-to-prod are getting intense scrutiny. This does put somewhat of a damper on fully-automated continuous deployment models. You will need to prove to an auditor that push to prod is strictly controlled, and can’t be hijacked by a malicious user. This gets complicated fast, but one of 38North’s specialties is helping CI/CD processes stay compliant with FedRAMP. So contact us to chat more about this unique challenge.
No Live System Data
You will not be able to use actual data from prod in your dev and test environments. This includes customer data, but also things like server hostnames, unique configurations and client identifiers of any kind. Your development environment will need to be genericized and not easily mappable to the production environment.
No Custom Configs in Dev
The hardest part of the no live system data rule is that some CSPs use test environments that simulate OSs and infrastructure in production. No problem. However, if you’re applying custom configurations to that infrastructure to meet federal requirements, those will need to be applied in a staging environment that’s within the boundary. These configurations are sometimes considered federal information, and can drag a development environment in scope.
No Vulnerability Ticketing
This is a tricky one. You need your developers to fix security issues discovered in your production code. But you won’t be able to document this in an out-of-boundary ticketing system.
As an example, you won’t be able to write a ticket outside of the boundary to the effect of “application testing shows that we’re totally hosed because of a stored XSS vulnerability in our latest release, version 3.2.” Instead, this level of detail needs to be tracked in-boundary, with only a genericized feature / fix request, handled in whatever development workflow tracks bug fixes. Or you can have a specialized team of developers with access to the boundary who handle these issues.
Tight Control Over Open Source
CSPs new to the US government often think that open source software is a no-go. False. Use of open source software isn’t only permitted, it’s often embraced as a best practice. But that doesn’t mean you can just go to Github, grab random code and slap it into production without a second thought. You’ll need to prove to auditors that you have a controlled process, one that draws from established open source communities, considers and respects licenses, and tests and scans all code prior to integration. Additionally, you’re going to need to show understanding of all libraries and dependencies used by your code, and any security issues hiding there.
Static and Dynamic Scanning
Both static and dynamic scans will need to be conducted. It’s a hard requirement, enshrined in the Systems and Services Acquisition (SA) control family. You have leeway to select tools – though tools will be scrutinized to ensure that they provide full code coverage – but you will need to consistently scan all code prior to release.
Integrity Verification / Code Signing
Code integrity will need to be validated before and after it is pushed to the system boundary. There are a number of ways to do this, from manual file hashing and verification, to code signing, to fully automated solutions that seamlessly operate across the build process. But regardless of which path you take, you will need to prove to an auditor and to AOs that you have a firm handle on software integrity, with a technical method for non-repudiation.
Best Practices
Satisfying the bare minimums above will likely keep your development environment out of the FedRAMP authorization boundary. In part 2, we’ll discuss additional best practices that will demonstrate maturity and help future proof your development environment against evolving security requirements.
Contact Us
Contact 38North to learn more about how you can secure and manage your development environment in a way that maximizing FedRAMP success.
