Last week, Anchore went public with our federal whitepaper “Container Security for US Government Information Systems” which contained key guidance for US government personnel responsible for securing container deployments on US government information systems. One of the key components of the whitepaper focused on utilizing a container-native security tool with the ability to whitelist and blacklist different packages, ports/protocols, and services within container images in order to maintain security in depth across environments.
Today we will focus on how Anchore integrates whitelisting and blacklisting into our custom DoD Security Policies bundle to provide in-depth security enforcement for our customers.
Whitelisting with Anchore Enterprise
Anchore provides pre-configured out of the box DoD and CIS policy bundles (https://github.com/anchore/hub/tree/master/sources/bundles) that serve as the unit of policy definition and evaluation for enforcing container security and compliance. Within these policies, Anchore engineers have worked to develop comprehensive whitelists of authorized software packages, users, and user permissions.
Additionally, users can whitelist specific ports that apply to each service running within their container image in order to validate only authorized ports are open for their containers when they are pushed into production.
This is a critical part of maintaining any kind of acceptable cybersecurity posture for a federal information system since assessment teams are constantly inspecting for unauthorized ports, protocols, and services running on US government information systems. Additionally, whitelisting is critical to SecOps teams that need to tailor whitelists for CVE’s to account for false positives that continuously appear in their scans. When done correctly, whitelists are an effective strategy for validating only authorized images and software packages are installed on your system. Through whitelisting, the security team can minimize the false positive rate and simultaneously maximize their security posture by using Anchore’s scanning policies that will only allow authorized images, ports/protocols, and packages in container images that end up handling production workloads.
Anchore Enterprise makes whitelisting extremely simple. 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.
From here, the user can tailor the whitelist specific to their environment. For example, you can edit the existing DoD security policies bundle to fit the needs of your environment by entering the CVE/Vulnerability identifier and package name:
The policy bundle is then automatically updated to reflect the updated whitelist and you are now ready to begin scanning using your tailored policy. Anchore Enterprise provides this flexibility specifically for security teams and development teams that need to comply with various policy requirements while not adversely impacting deployment velocity.
Blacklisting with Anchore Enterprise
Conversely, the infosec best practice of blacklisting can also be done using Anchore Enterprise. Again, with Anchore’s out-of-the-box DoD security policy bundle, customers have SSH-22 and Telnet-23 blacklisted by default. Blacklisting of Telnet and SSH as evident in the screenshot of the DoD security policy bundle:
SecOps teams can take this a step further and tailor the policy bundle to blacklist additional ports if needed by navigating to edit the exposed ports check:
Upon each scan, Anchore can then take inspection a step further to blacklist certain types of effective users found in an image. One of these checks that Anchore incorporated into the DoD security policy is validating the effective user is not set to root. By looking at the DoD Security
Policy Bundle below through our Anchore Enterprise console, we can see that the Anchore DoD Security Policies is automatically validating the effective user that we have blacklisted:
If SecOps teams have data indicating known malicious software packages, then they should be utilizing a tool to block known packages from being incorporated into Docker images that will eventually end up deployed on a Federal information system. Again, you could do this by navigating to the DoD security policies bundle and selecting “whitelisting/blacklisting” as seen below:
From here, you are just seconds away from improving your security posture and blacklisting images from being pushed into production. By simply selecting “Lets add one” the user can then specify an image to blacklist based on Image Name, Image ID, or by Image Digest :
With Anchore’s policy first approach, enforcing whitelisting/blacklisting for Docker images has never been easier as it serves to meet the various security baselines and requirements that span across the US Government space. Anchore provides the flexibility to meet your security requirements for your federal workloads at scale ranging from classified and unclassified information systems.