Are My Containers Affected by the New OpenSSL Vulnerabilities?
On October 25th it was announced to the world that the OpenSSL project team would release OpenSSL version 3.0.7 to fix a critical security issue that affected all OpenSSL 3 versions the day after Halloween, November 1st.
Many of us security folk, while trick-or-treating with our kids, were confronted with the fear of not only spooky Halloween decorations and costumes but of understanding what this vulnerability mean to the security of our applications? Asking ourselves, is this going to be a new Heartbleed all over again?
November 1st came, and the news ended up being less scary than our fears: the one vulnerability became two, CVE-2022-3602 and CVE-2022-3786, but they were downgraded to HIGH. As scary as HIGH might seem, it’s definitely a considerable downgrade as, according to the OpenSSL team, these vulnerabilities are less likely to be exploited.
Nevertheless, these are still vulnerabilities that deserve attention, and teams are scrambling to figure out if their container-based applications are vulnerable to them. Are you part of that group? Follow these recommendations, ordered by level of security maturity.
Lower: Discard vulnerable container images
Rule number one for container security is to make sure you are not running vulnerable container images in the first place. Most organizations with basic security maturity as part of their supply chain make sure they are scanning the container image artifacts for vulnerabilities either before pushing them to their container registries or before deployment. This is typically implemented as part of their supply chain.
Higher: Make sure deployed containers are not vulnerable
Organizations with a higher level of security maturity go a step further and implement, utilizing the Kubernetes Admission Controller API, a time-of-deployment check that makes sure that containers leveraging untested or unapproved images are forbidden from being admitted to the cluster. Adding this extra layer of security at the deployment level makes sure that the image has passed tests and checks earlier in the pipeline so that only the most secure containers are deployed.
Highest: Immediately find out if running containers are vulnerable
This tactic is used by organizations with the most mature security practices and help the greatest with the OpenSSL situation we are dealing with today. Running containers might be leveraging vulnerable versions of OpenSSL that were considered non-vulnerable when they first went through the scanning process in their pipeline. To solve that, organizations have put in place mechanisms to make sure they are aware of the composition of each container image that is being currently used in production, so they can, at a glance, understand their potential exposure to new vulnerabilities such as with these new OpenSSL ones.
Trend Micro Cloud One™ – Container Security
Trend Micro Cloud One™ – Container Security customers can easily assess if any container running on their Kubernetes clusters is impacted by the newly released vulnerabilities.
The first step is to make sure the cluster is protected by Container Security and configured to do runtime vulnerability scanning1. This capability scans all running containers of a cluster looking for open-source and operating system vulnerabilities.
