Creating a FedRAMP compliance checklist can be vital to approaching compliance methodically. While government contracting is full of FedRAMP challenges stories, the move to cloud-native development grants us new tools, technologies, and methodologies to better set your projects up for FedRAMP compliance success. It’s up to you to capture these best practices in a checklist or process flow for your teams to follow.
Considerations for your FedRAMP Compliance Checklist
Here are some concerns to include in your checklist:
1. Shift Security Left
Shifting left describes using tools and practices to improve and encourage more rapid feedback from security stakeholders about security and compliance into the early development stages. However, the objective is always to hand bugs and fixes back to developers as part of a smooth, ongoing, continuous development process.
Unit testing is a familiar example of shifting left by delivering early, user-experience feedback on functionality. Shifting unit testing left ensures that most problems are caught early, during the development stage, where it is quicker and simpler to remedy them.
By shifting security left, the handling of each vulnerability becomes an integral part of the CI/CD pipeline. This prevents a mass of vulnerabilities from appearing as a single irritating blockage before your team admits a system into production. More frequent vulnerability scanning during development ensures bugs and other issues can be dealt with quickly and efficiently as they arise, and security becomes a part of the development process.
With the primary focus of CI/CD environments on fast, efficient development and innovation, security has to work efficiently as part of this process. Anchore advises that DoD and federal security teams use tools that can deliver rapid feedback into development. Security tools must integrate with typical CI/CD and container orchestration tools. The tools you choose should also promote early-stage interaction with developers.
2. Follow the 30/60/90 rule to keep Images Secure
Anchore recommends following the 30/60/90 rule to satisfy the guidance outlined in the DoD Cloud Computing Security Requirements Guide. This rule sets out the number of days to fix security issues:
- 30 days to fix critical vulnerabilities
- 60 days to fix high vulnerabilities
- 90 days to fix moderate vulnerabilities
In support of this, it is also strongly recommended to use a tool that allows security teams to update and validate vulnerability databases with new security data frequently. Not only is this necessary to satisfy Security Controls RA-5(2), but using such a tool is a best practice to ensure your security data is timely and relevant.
By following the 30/60/90 rule and ensuring that you update your vulnerability databases and feeds promptly, you empower your security teams to remediate new security challenges quickly and efficiently.
3. Make use of Tools that Support Container Image Allow/Deny Listing
Federal agencies should leverage container security tools that can enforce allowlisting and denylisting of container images. Maintaining allow and denylists are common methods of securing networks and software dependencies. However, they are less common in a containerized environment.
This capability is crucial, as attackers can potentially use containers to deploy denylisted software into secure areas such as your DevOps toolchain. The elements and dependencies of a container may not always appear in a software bill of materials (SBOM) from existing scanning tools. Therefore it’s crucial that the tools used can examine the contents of a container and can enforce allowlist and denylist safeguards.
Anchore advises that container image denylisting should occur at the CI/CD stage to allow rapid feedback. By shifting the security feedback to the developers, they receive immediate feedback on issues. This technique allows for faster remediation, as denylisted container images or the software contained within them are immediately flagged to the developer.
4. Deploy a Container Security Tool that Maintains Strong Configuration Management over Container Images
Software delivery and security operations teams should maintain an accurate inventory of all software they deploy on any federal information system. This inventory gives both teams accurate situational awareness of their systems and enables more precise decisionmaking.
Anchore advises federal agencies to implement a container-native security tool that can systematically deconstruct and inspect container images for all known software packages and display findings for information security personnel in an organized and timely manner.
5. Use a Container Scanning Tool that runs on IL-2 through IL-6
The DoD and federal agencies must leverage tools that keep any vulnerability data regarding the information system within their authorization boundaries. However, many FedRAMP vulnerability scanning tools require an agent that connects to the vendor’s external cloud environment. The DoD designates this as interconnectivity between DoD/federal systems and the tool vendor and would rule out the use of any agent/cloud-based tool within an IL-6 classified environment.
Where organizations still choose to implement an agent-based container security tool, they are then responsible for ensuring that the security vendor maintains an up-to-date accreditation for their cloud environment. The environment must also have the relevant RMF/FedRAMP security controls that the federal information system can inherit during the ATO process. In addition, any DoD or federal agency should ensure the agent-based tool can run in both classified/unclassified environments.
Learn how Anchore brings DevSecOps to DoD software factories.
6. Express Security Policy as Code
Where possible, select tools that enable your teams to define security policy as code. These tools enable security teams to establish and automate best practices that they can push to tools, either across the network or in more secure environments.
Expressing security policy as code also enables your ops teams to manage systems using existing software development life cycle (SDLC) techniques. For example, policy as code enables the versioning of security policies. Now teams can compare policy versions for configuration drift or other unexpected changes.
In essence, it will enable the policies themselves to be subjected to the same level as rigorous as the code they are applied against.
The onus of implementing new security policies shifts security left onto developers. It can be important not to tighten container security policies too far in one step. Versioning also enables any agencies to improve and tighten security policy over time.
This iterative approach towards improving security stops over-intrusive security policies from stalling development in the CI/CD pipeline. It prevents the emergence of any culture clash between developers and security operations. Security teams can begin with a policy base that delivers on minimum compliance standards and develop this over time towards evolving best practices.
Conclusion
Think of a FedRAMP Compliance Checklist as more than just a documented list of activities your teams need to perform to get your application FedRAMPed. Rather, think of it as a methodical and strategic approach for your developers and security teams to follow as part of holistic and proactive strategies for secure software development and government compliance.
Download our FedRAMP containers checklist to help jump start your organization’s FedRAMP compliance checklist.