.png)
FedRAMP Revision 5 introduces a new requirement in Section CA-7: monthly scans of configuration files. In this blog, we'll break down what this update means and provide quick tips on how to meet this new requirement efficiently.
Section CA-7 has a new requirement in Fedramp revision 5, namely the monthly scan of configuration files. To quote the document:
Requirement: Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually (Source)
In particular - section CM-6, which requires Fedramp compliant companies to check the following in an automated fashion:
Requirement: The service provider shall use the DoD STIGs or Center for Internet Security guidelines to establish configuration settings;
CoGuard is greatly enthusiastic about new requirement, as it’s a benchmark of our entire process and methodology: Configurations are similar to code in that there are many opportunities for error on the side of the personnel working with them which can easily result in their accidentally exposing data and potentially causing down-time. Poor hygiene is not only a security risk, but a recipe for an ever-growing legacy code issues and buggy infrastructure.
Configurations handle much more than just setting some ports and establishing database connections. Many pillars of security can be derived and assessed from configuration files. These include, but are not limited to:
If a company does not comply with these items, the configurations reveal it. And in order to make the changes recommended by CoGuard scans, some other architectural errors need to be fixed as well. All in all, it will increase the quality of one’s setup to the best and get rid of technical and architectural debt.
Both the Center for Information Security benchmarks as well as the DoD STIGs are a collection of configuration parameters and their recommended values for different software products. There is an intersection between both benchmarks, but there is also software that is covered exclusively by one of the benchmarks.
Both benchmarks are available for download. There are some automated tools as well, but generally the benchmarks are provided via documents.
Extracting configurations and finding them in your infrastructure is hard. When CoGuard was talking to our first customers, we often heard IT-people say: “Wait, I have a configuration file?”. As humorous as this sounds, it is a clear result of the ever-increasing complexity.
We invested aggressively into the effort to automatically discover files and configuration settings. There are multiple ways that configurations can be communicated to software, and the discovery process needs to take all of them into account: Environment variables, files and call parameters.
Furthermore, available benchmarks only cover established and popular software, and these benchmarks are maintained mostly by volunteers (e.g. in the CIS-example). (You are talking about volunteers maintaining this - so, this is open source, right? If so, you should mention this.) Newer or edge-case legacy software cannot be found there, albeit by handling potentially sensitive information. (I’m confused by this sentence - can you explain?)
TL;DR: CoGuard has the most comprehensive collection of tools supported in its scan, and its CLI can discover configurations and infrastructure dependencies automatically.
CoGuard has the most complete configuration coverage available. Operating Systems, Databases, Web applications, containers and service configuration scans: This is our entire focus and we’re able to achieve this in one tool with an elegant and simple to use interface.
Our CLI automatically discovers configuration files for you, and can even detect one’s that users were not aware of. For example, Kubernetes manifests frequently contain references to external Docker images. CoGuard recursively scans those for configurations as well, and often discovers an extra database dependency along the way.
Now that configurations have made it into the CYA (cover your assets) list of companies, let’s talk about how to take it to the next level.
A lot of configuration requirements are fairly simple to accommodate. This is why we have developed a feature to speed up the fixing process for developers through auto-remediation. The current documentation on that feature can be found here.
Looking at individual configurations is like using `grep` to perform static code analysis. More sophisticated static code analyzers build abstract syntax trees and analyze runtime pathways throughout your code. The same needs to be done for infrastructure. This methodology was patented by CoGuard in March of 2024. In our discovery process, we are also heuristically generating a model of the infrastructure and performing contextual analysis that ensures that any change in code does not accidentally take down a whole different area depending on it.
Auto-Generation of policies
As mentioned previously, we have a limitation of tools which are actually listed in the common benchmarks. Does that mean the rest can be ignored? Certainly not. Best practices that determine what is important or not can be derived from NIST guidelines and similar documents. CoGuard developed an automated pipeline to ensure that our customers have as few blind-spots as possible. This is achieved by using LLMs in the development process. It appears that LLMs are particularly well suited for this discovery task (see e.g. our research in the context of the OpenAI cybersecurity grant).
Fedramp is one of the most extensive frameworks in existence. However, items included in Fedramp are likely to expand into other frameworks, such as CMMC. Getting ahead of the curve is key. The existing configuration benchmarks are there to help people improve their security posture and stability, but have been mostly a voluntary effort so far. This is changing now. And the reason is very clear: Configurations offer significant insight into the architectural maturity of a system, and the number control criteria they are covering from most compliance frameworks is huge. If you look into the details of most breaches, a misconfiguration can be found as one of the most common causes. It is no surprise that regulators are now starting to focus on these areas with an ever increasing sense of urgency. The benefits will be seen in the near future, and expanding on the need for clean configurations even outside these concrete benchmarks will grow. Hopefully, this will result in the ultimate end-goal: Less breaches and less down-times.
CoGuard is perfectly equipped to scan configurations across your infrastructure, and ensure you’ve fulfilled your DoD STIG requirements for each item in an automated way (or assist you in getting there). Send us a message today to info@coguard.io to learn more.
