Production container usage has become mainstream, and one of the more interesting container use cases is as part of a vulnerability response plan. With vulnerability disclosures showing no signs of decreasing, a validation model that can scale will help.
A recent set of OpenSSL patches provides an example.
On 22 September, the OpenSSL team released two updates – one for the 1.1.0 version and another for the 1.0.2 version of the library. Four days later both received additional updates. While the second update for version 1.1.0 addressed new issues, the one for version 1.0.2 contained a fix for a bug introduced in the 22 September update. It's this patching of OpenSSL 1.0.2i to create 1.0.2j that has gotten media attention.
So, what exactly happened in this OpenSSL patch release sequence?
The obvious question is “how did this happen”? As with many things, the answer is a bit mundane. The source code commit for the fix modifies only two lines of code relating to the processing of certificate revocation lists (CRLs). A CRL is a list containing security certificates which have been revoked for any reason, and it's a key component in keeping internet transactions safe. Due to the nature of this bug, anyone using OpenSSL 1.0.2i with CRLs is likely to experience a program crash, and should update to 1.0.2j immediately.
While it's tempting to point fingers at the OpenSSL team and ask hard questions, the more important issue is how well vulnerability response plans account for this scenario.
As part of any vulnerability response plan, organisations should include procedures to account for frequent security updates to components they depend upon. Containerisation can help in that effort.
Most vulnerability response plans include a requirement to test a patch in a lab environment. This presents two challenges – timing and resources. Maintaining a lab environment requires hardware and the ability to replicate a production environment. Ideally, this lab would validate all security patches to ensure overall application stability, but that takes time, and the longer a vulnerability is unpatched the greater the potential for attack. This is where containerised applications, and specifically micro-services, prove beneficial.
By segmenting applications into containers, or follow the micro-services design pattern, each container will have a limited set of functionality. This not only reduces lab requirements, but also allows for focused validation efforts on only those containers with vulnerable components. With a main goal of reducing the time to provision a security patch, validation efforts should include a clear set of functional requirements that can be executed quickly. In the case of a transactional web application, one functional requirement would be a CRL test, which would have caught the OpenSSL 1.0.2i bug and failed it for release. In failing a security patch for release, the vulnerability response plan should also identify any additional monitoring or perimeter defences required to detect attacks resulting from disclosed vulnerabilities in the failed patch.
All vulnerability response plans should have a requirement to patch quickly. They should also consider the potential for a patch to contain an issue that will also be patched quickly.
Although OpenSSL 1.0.2i is fresh in our minds, it's far from the only patch the software industry has released with an issue requiring a subsequent release. Using Docker containers as part of a vulnerability response plan can ease the testing requirements for patches, but it's important to understand the contents of any containerised applications.
Contributed by Tim Mackey, senior technical evangelist, Black Duck Software