Policy first is a distinguishing tenet for Anchore as a product in today’s container security marketplace. When it comes to policy, we at Anchore receive a lot of questions from customers regarding different compliance standards, guidelines, and how the Anchore platform can help meet their requirements which remain a priority. Today, we will review our top three (in no particular order) policy and compliance questions we receive to demonstrate how Anchore can alleviate some of policy/compliance woes when choosing a container security tool to bring into your tech stack.
How can Anchore Help me Satisfy NIST 800-53 controls?
We receive a lot of questions regarding how Anchore can help different organizations meet compliance baselines that deal heavily with the implementation of NIST 800-53 controls. As a result, we talk about a lot of controls we satisfy in our federal white paper on container security. At a high level, Anchore helps organizations satisfy requirements for RA-5: Vulnerability Scanning, SI-2 Flaw Remediation, CA-7 Continuous Monitoring.
However, Anchore does more than just help organizations with vulnerability scanning and policy enforcement with containers. As a part of our process, Anchore provides an in-depth inspection of the image as they pass through Anchore analyzers that enforce whitelisted and blacklisted attributes such as ports/protocols, types of images, and types of OS as described in our previous blog post. Anchore Enterprise users can customize and enforce whitelisting/blacklisting within the Anchore Enterprise UI, navigating to the Whitelists tab will show the lists of whitelists that are present in the current DoD security policies bundle.
As a result, this allows organizations to comply with configuration management controls as well, specifically CM-7(5) Least Functionality: Whitelisting/Blacklisting in addition to CM-7(4) Unauthorized Software and Blacklisting. To prevent unauthorized software from entering your image, simply selecting “whitelist/blacklist” images tab as demonstrated below which allows you to blacklist OS, image, or packages :
How does Anchore Help Organizations Meet the Guidelines Specified in NIST 800-190: Application Container Security Guide?
Anchore provides a policy first approach to automated vulnerability scanning and compliance scanning for Docker images. By having customizable policies at the center of Anchore Engine itself, we provide the capability to react swiftly as new Federal security policies are published. NIST 800-190 was no different for the Anchore team. NIST 800-190 specifies, “Organizations should automate compliance with container runtime configuration standards. Documented technical implementation guidance, such as the Center for Internet Security Docker Benchmark.”
Out of the box, Anchore provides a CIS Policy Bundle for open source and Enterprise users alike which allows you to check for Host Configuration, Docker daemon configuration, Docker daemon configuration files, Container Images and Build File, and Container Runtime. Below, we can see how the latest Postgres image stacks up against the CIS Benchmarks called out in NIST 800-190:
From here, we would recommend hardening the image to comply with the CIS benchmarks before advancing this image into production.
Is Anchore FIPS 140-2 Validated?
Anchore is not a FIPS 140-2 validated product, nor is it a FIPS 140-2 Compliant product. However, it’s important to explain why Anchore has no plans on becoming FIPS 140-2 Validated. As NIST explains FIPS 140-2 applicability is listed here:
“This standard is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract...”
A majority of the products found on the list deal with validating encryption as a protection mechanism for products associated with networking hardware or hardware/software involved in the identification and authentication of users into an environment that is outside of the scope of the Anchore product. Anchore believes it is important to protect sensitive information generated from Anchore scanning. However, Anchore does not provide FIPS 140-2 validated protection of that information. Rather, Anchore believes it is the responsibility of the team managing Anchore deployments to protect the data generated from Anchore which can be done using FIPS 140-2 validated products. As of 2018, Docker became the first container relevant vendor to have a FIPS 140-2 validated product with the Docker Enterprise Edition Crypto Library. Furthermore, no other container security tools in the market are FIPS 140-2 validated.
Conclusion
Although we simply covered NIST standards in this post due to its wide use and popularity amongst our customers, Anchore Enterprise exists as a policy first tool that provides teams with the flexibility to adapt their container vulnerability scanning in a timely fashion to comply with any compliance standard across various markets. Please contact our Anchore team if you are having trouble enforcing a compliance standard or if there is a custom Anchore policy bundle we can create in line with your current compliance needs.
