Vulnerability management is starting to get traction in OT, and where it does, asset owners are faced with an unpleasant surprise. While many are expecting the need to fix dozens of vulnerabilities, in reality the number is much higher. If your organization operates hundreds or thousands of computers in the OT space (think of HMIs, engineering stations, operator panels etc.), chances are that several hundred thousand vulnerabilities are waiting to be patched.
Why is this the case? Because in OT, automatic patching is the rare exception, and manual patching usually addresses only a few hand-picked vulnerabilities. It is therefore not unusual to see computers with more than thousand vulnerabilities.
On the other hand, with selective manual patching being the preferred course of action in OT, you can only patch so much with given resources in a given timeframe. As a matter of fact, the OT-BASE Asset Management Platform will tell you exactly what that number is for your organization. Since it will always be much lower than the speed with which new vulnerabilities are discovered, the task at hand becomes prioritization. Which vulnerabilities should you address, for which other vulnerabilities should you accept the risk?
Vulnerability management is about prioritization
First and foremost, this task requires a good understanding of your attack surface. You need to know which vulnerabilities affect significant chunks of your installed base, because once that these vulnerabilities get exploited, they will cause major trouble through scaling. On the positive side, scaling plays into your hands because the preparatory step of analyzing if a patch is safe to apply only needs to be done once, but affects a large number of devices. The other parameter that you want to have an eye on is the severity of the vulnerabilitiy, which is usually expressed as its CVSS base score (a number ranging from zero to ten).
While the data set that is required for this type of contextual awareness gaterhing can easily be displayed as a table, a visualization is much easier to grasp. A good way to make it happen is to use a treemap, where the size of rectangles represents the number of vulnerable devices and the rectangles’ color indicates CVSS base score. In other words, it’s a treemap combined with a heatmap. Hovering over any rectangle will display the CVE identifier of the respective vulnerability along with other information in a tooltip.
What you want to focus on here is the large, dark red rectangles. They represent severe vulnerabilities that affect a large number of devices. When used inside the OT-BASE Asset Management Platform, a mouse click will bring up the profile page for the vulnerabilitiy where more information is listed, including the identity and location of vulnerable devices.
Device criticality adds an important third dimension
So far, so good — but still not good enough. For all but the best patched OT infrastructures, this approach will not give you enough leverage for substantial risk reduction, because not all devices are equal when it comes to risk. As an example, patching a small number of engineering stations for safety systems may yield more risk reduction than patching a many HMI stations which may fail without severe impact. Once that we factor device criticality into the equation, our decision making may change. Fixing vulnerabilities that show a significant third (criticality) dimension should be your priority, because these vulnerabilities account for more risk (cost of consequence) than others.
Certainly this requires a data set which includes criticality assessments/scores for devices. In the OT-BASE Asset Management Platform, this is accomplished by allowing users to rate the criticality of a device in respect to one or more dimensions, and also express a score. For example, a highly safety critical device may be rated as SAFETY:2, and a device being critical for product quality as QUALITY:1. Such data can be used as an additional dimension in our visualization:
In this example you see the same treemap as above, but the Z axis indicates compound device criticality. The resulting 3D object can be rotated in all directions, allowing for easy in-detph examination of the attack surface. Just like with the 2D version, pointing to a CVE object brings up a tooltip with additional data, and a left click launches the CVE profile with information on the affected devices.
Conclusion
The difficult task in OT vulnerability management is to get prioritization right. Multiple data inputs, including but not limited to CVE severity, number of vulnerable devices, and device criticality, must be transformed into a decision on which vulnerabilities to patch next. This decision requires a human expert who can be made much more efficient with state of the art visualizations.
For more information on the OT-BASE Asset Management Platform check langner.com/ot-base.