Affected versions of OpenSSL:
The versions you want to see after updating OpenSSL are:
- Series 3.0: A new version will be 3.0.8.
- Series 1.1.1: A new version will be 1.1.1t (It’s T-for-Tango at the end).
- Series 1.0.2: A new version will be 1.0.2 zg (Zulu-Golf).
If you have these versions, let’s see below what you need to do and plan.
what should you do?
Companies should patch their OpenSSL deployments. Pay particular attention to applications that bundle OpenSSL in their releases. Make sure you have an accurate inventory of all your hardware and software assets. Review your software database to determine your potential impact from these vulnerabilities. Be careful when patching systems where applications have been compiled with their own version of OpenSSL. If you have the means to scan systems with authentication, do so to ensure that you have patched all installed versions of OpenSSL before and after patching. There are special circumstances to watch out for when patching Linux systems. Consult your operating system vendor’s advice on patching OpenSSL. Are there workarounds for them to fix?
Emergency solution if repair is not possible:
Currently, there are no known workarounds to mitigate these risks outside of patching. Now we move on to vulnerability management.
Do you have a vulnerability notification management process in place?
If you subscribe to CyberHoot’s awareness training platform, you have access to our policy and process library, which contains the Vulnerability Alert Management Document (VAMP). This document sets out how to respond to such situations and in what time frame. If your company has not yet adopted a VAMP-like process, now is a great time to start.
If you’re a vCISO customer, we’ve built this process for you and you now need to follow through with the measures and timeframes set out. If you are not a vCISO customer or CyberHoot product subscriber, you may want to register here.
