Ambiguity
IT managers today are developing a soft spot for hardened images. The prospect of strengthening software images against continuously emerging vulnerabilities and cyber threats is an attractive one. We discussed in part one of this topic, the growing need for the hardening process in order to combat security threats to today’s companies.
There’s just one question: what exactly does “Hardening” mean?
David Hernandez, Lead Cloud Security at Telefónica, writes on Medium.com that “’Hardening’ is one of those words that always appear in all kinds of meetings but nobody is clear about what it is.”
The reason why it’s not abundantly clear what exactly hardening is, lies in the fact that it is a very general term used to imply a series of protocols, benchmarks, and best practices intended to enhance security. The very nature of protocols, benchmarks and best practices implies subjective standards, divergent ideas of what takes priority, and different methodologies of what works and what doesn’t.
In addition, hardening can apply to strengthening any type of system, not just image strengthening, in order to reduce exposure to attack, which broadens its scope. Therefore, Image hardening will differ from network hardening or database hardening.
In terms of image hardening, there is no one absolute authority that determines the protocols, benchmarks and best practices for the hardening process.
The CIS
However, there is an organization that has achieved broad recognition in this area: The Center of Internet Security, or CIS.
The CIS creates consensus-based benchmarks by sending out surveys and emails in order to compile security recommendations. The CIS then maintains these benchmarks within a community of developers, editors and technology vendors.
Aside from creating security benchmarks for virtual machine images, the CIS also developed the Docker CIS Benchmark, which offers detailed recommendations in the areas of host configuration, Docker Daemon configuration, container image and build-file configuration, container runtime configuration, Docker security operations, Docker Swarm configuration, and Docker Enterprise configuration.
When it comes to the images themselves, the recommendations are quite straightforward:
- Only use trusted base images
- Perform security scans on images
- Rebuild images to include security patches
Scanning for vulnerabilities allows developers to review the state of the container images and take steps to address the issues identified during the scan.
Trivy
Of the scanners available for this task, it seems that Trivy is rated highest overall for accuracy, ease-of-use, and suitability for CI.
Trivy is a comprehensive and versatile scanner, searching for vulnerabilities in container images and inspecting the code in Git repositories. It can also advise regarding configuration files, investigate Kubernetes deployments, and verify Infrastructure as Code.
In scanning Docker images, Trivy feeds from Aqua’s vulnerability database and other OS and programming language databases. Results from the image scan can be filtered by adding “critical” and “high” to the command, thereby enabling us to determine which level of security is adequate.
Also, it is advised to remove those packages with vulnerability issues that are not really necessary anyway. From there a new base image can be built, and then tested to determine if the vulnerabilities have disappeared.
Those that have remained can be patched. Some of them can be ignored if they are assessed as posing a low threat level.
Scanner Limitations
However, scanners are not invincible. Among the limitations is that public security vulnerabilities databases are the reference point for the scanners. This means that non-disclosed security flaws won’t be exposed. Any package that is not publicly monitored, including older open source software package versions that have been rebuilt, won’t be fully transparent.
Iron Bank
One way to tackle this problem is to ensure an exclusive, secure environment from the ground up. Iron Bank, which is the US Department of Defense’s source for hardened and approved containers, admits only pre-approved container images into their repository.
At Iron Bank, when a vendor is onboarded, the vendor makes code and commits to building the Docker images. A Container Hardening Team engineer then initiates a justification process whereby the image is analyzed and finally approved.
Then, once the image is approved, it will need to be continually monitored by the user in case of continually emerging vulnerabilities, which scanning will address.
Bringing out the SBOM in the War against Cyber Threats
Another grass-roots approach is the US government’s initiative to create and standardize transparency. The White House actually published a requirement, as part of its Executive Order on Improving the Nation’s Cybersecurity, that government software should contain a machine-readable record with an explicit description of all components of open source package versions. This record is called the Software Bill of Materials, or SBOM. This transparency will afford consumers the ability to enact security controls based on all the data they have.
And being machine-readable, this would enable automation of the security-strengthening process, making it an attractive contribution to the hardening process.
Practically speaking, however, the challenge lies in creating the SBOM. Since the SBOM requires a full listing of every package that goes into making a container image, that can tally to thousands of packages.
Syft
Fortunately, there are tools such as Anchore’s Syft which can pull down images and extract a full SBOM rapidly. It will not only list every package name, but also every package version.
That kind of transparency is great for ensuring a clean start on the image, and then continuous scanning will help to preserve its security.
A Sneak Peek at Snyk
Then there are tools that relieve the inconvenience of having to continually scan the images for vulnerabilities. Snyk is a developer security platform that not only automates upgrades to base images, but also provides continuous monitoring for new vulnerabilities. It integrates directly into the user’s development tools and workflows, and actually keeps an eye on what the user himself has installed afterwards. Snyk pinpoints any additional vulnerabilities the user may be introducing by adding tools and code to the container.
The Future
Hardening is a continually evolving process, and our company, Hossted, is taking a holistic view of all the benchmarks, protocols and procedures that contribute to the process. Hossted is critically evaluating and actively applying security protocols to our images, with a vision of creating the most optimized, secure images available in the cloud marketplaces.
Sources: