In Part 1 of our FedRAMP development environment guidance, we offered some tips and tricks for keeping dev outside a FedRAMP authorization boundary. Here in Part 2, we’ll discuss best practices that showcase maturity and increase the likelihood that an Authorizing Official (AO) will bless your approach to development security.
Deliberately Select and Apply Technical Security Controls
Just because we said we might be able to keep your development environment out of the authorization boundary does not mean you get to just let it run free. AOs are still going to give it a frosty thrice-over, looking for reasons to not trust the security of your development approach. This is especially true if you’re integrating with third-party tools, with lots of API connections out to various services.
So even if you’re trying to keep dev out of the FedRAMP authorization boundary, still apply as many of the technical FedRAMP controls as possible to demonstrate maturity. Consider comprehensive infrastructure scanning, strong access control and multifactor authentication, rigorous logging, and security monitoring. This will increase the odds of being able to keep the dev environment out of boundary.
CI/CD Pipeline Security
Demonstrating maturity is especially critical for organizations operating a modern Continuous Integration / Continuous Deployment (CI/CD) style approach to software development.
In theory, by integrating automated testing early in the development process, CI/CD approaches should both enhance and simplify security. However, too many organizations use CI/CD processes as an excuse to push sloppy code, based only the results of a few tricky-to-configure automated security tests.
So, there is some healthy skepticism from AOs about the security value of CI/CD-type approaches. By demonstrating advanced security maturity that spans the entire pipeline, development teams can help AOs grow comfortable with this modern approach to software development and release.
Avoid Insecurity-as-Code
Infrastructure-as-Code (IaC) based approaches simplify the challenge of dealing with large infrastructures and deployment. But deploying templates via orchestration tools like CloudFormation, Azure ARM, Terraform, or similar solution, runs the real risk of replicating known vulnerabilities throughout your environment.
So understand that an IaC-based approach will get a healthy dose of well-deserved suspicion. Document and be prepared to discuss all IaC templates in use, how they are selected and managed, what images are referred to by those templates, and why those should be trusted. You will also need to demonstrate a robust approach to scanning templates, one that acknowledges the challenges associated with scanning them. Consider using a variety of tools to provide overlapping coverage.
Implement Formal Threat Modeling
Threat modeling for software is a distinct discipline, far more advanced than a traditional risk assessment. Threat modeling dives deep on potential attack techniques, mapped to system processes and even specific code segments. As an example, your team might consider how every step in user auth could be attacked, or if your application might be vulnerable to some of the more esoteric injection-type vulnerabilities. You can also use the threat modeling process to demonstrate a thorough understanding of your IaC templates and security relevant configurations.
This degree of modeling shows off how well you know both your infrastructure and your code.
Consider Dedicated In-Boundary Staging
In-boundary staging areas sometimes conflict with fully automated CI/CD processes. However, in FedRAMP world it’s a good idea to include in-boundary staging – strictly isolated from the production system – as a landing pad for software coming from dev. This is especially true if you need to apply unique configuration sets for federal clients. Under some circumstances these will be considered federal information. In-boundary staging also facilitates integrity checking, and helps soothe the souls of risk averse AOs.
Delayed Federal Deployment
Many CSPs decide that it’s simply too difficult to apply FedRAMP controls universally across their federal and non-federal customers. So they spin up dedicated environments solely focused on federal clients. In this model the commercial prod environment acts as a test space. Code runs and undergoes at least one monthly scanning cycle and then deploys to the federal environment.
While this may slow feature deployment to federal clients, it often reduces an AO’s perceived risk. If you adopt this approach however, make sure to apply security patches to both environments, immediately as available.
Secure Coding Training
AOs love to see rigorous secure coding training for developers. The more technical, the better. Veracode’s training is pretty slick. On the free front, SAFECode’s content is pretty solid, particularly for introductory content.
Disciplined Manual Code Review
A code scanning and test process, even a purely automated one integrated into a CI/CD pipeline approach, will likely get you through an audit. However automated testing tools often miss vulnerabilities. So consider a disciplined peer/manual review approach, at least for modules that pop as high risk during threat modeling. This will show the type of maturity AOs expect.
A tip: manual reviews can occur outside the CI/CD pipeline. Provided the automated testing approach is rigorous, manual review could occur by a dedicated software assurance team post release. Customers inside and outside the federal government will rest a little easier knowing that black hats aren’t the only ones scouring your production code for vulnerabilities.
Looking Ahead
Some smooth security moves might help you keep dev out of the system boundary. For now.
But in the wake of NotPetya, SolarWinds, Microsoft Exchange and other supply chain attacks – not to mention the Biden Executive Order – dev is probably going to get sucked back into system boundaries in the not too distant future. When it happens, it could happen fast, with limited time for CSPs to comply.
Smart CSPs are preparing for this by looking past bare minimums for audits and implementing best practices that lay the groundwork for full compliance in the future. Contact 38North to learn more about how you can secure and manage your development environment in a way that maximizing FedRAMP success.
