In 2008 as part of my early career as an industrial control system (ICS) / operations technology (OT) cybersecurity consultant, I was helping a major electric utility comply with patch management compliance for NERC CIP. The regulation mandated the creation of a patch management program along with processes, procedures, and evidence. At the time, no such content existed from ISO 27000, NIST SP800, or ISA99; this meant I had to develop from ground-up a program for 5 hydro, 5 gas, and 6 coal power generation plants. At the end of the project, I recognized the knowledge gap and decided to share my experience with industry by contributing it to ISA99/62443.
For the next several years I helped lead a working group in ISA99 focused on ICS/OT patch management. I was one of the leading contributors to Annex B ‘Asset Owner Guidance’ and Annex C ‘Product Supplier Guidance’, leveraging my industry experience with customers to help others tackle this same problem. In 2015, I was proud to publish TR62443-2-3 with myself as Lead Editor and Co-Chair, still in effect today.
At the time, the patching decision was based on a risk assessment consisting of criteria such as:
Exploit code at the time took months to years to appear, and the biggest concern was the need to shutdown the system or not in order to install the patch.
In 2008 the US Department of Homeland Security (DHS) released the ‘Recommended Practice for Patch Management of Control Systems’. In this document they introduced a “Patch urgency decision tree”, which recommended a risk analysis based upon the vulnerability as well as the business impact of deploying the patch.
But in the details of the DHS Patch Management recommendations, it is much like the TR62443-2-3 in that it provides a list of questions that should be asked as part of the risk assessment process to determine the urgency of the patch, constrained by the business and operations that may not afford shutting down simply to install a patch.
In 2022, Robert Lee and Tim Conway published with SANS the Top 5 Cybersecurity Controls for ICS. Number 5 was labelled ‘Risk-Based Vulnerability Management’ and used the same workflow published by DHS in 2008. They built upon DHS guidance by explaining and defining risk-based vulnerability management (RBVM) for OT as those vulnerabilities that actually drive risk to the organization. They explain those that drive risk as:
Numerous OT cybersecurity vendors all claim they offer risk-based vulnerability management (RBVM) because they use scoring of the (i) vulnerability severity and (ii) exploitability by a threat. There is no standard method to calculate RBVM, and anyone can claim a vulnerability prioritization system is risk-based.
DeNexus with the financial quantification capabilities of DeRISK can determine the financial loss potential of individual CVE vulnerabilities. How do we do that? The DeRISK platform includes a simulation engine that leverages inside telemetry from the actual environment (e.g., vulnerabilities, network architecture, security controls maturity) to run millions of Monte Carlo model simulations to estimate the financial impact of a cyber-attack with and without the vulnerability.
With the vulnerability, it manifests in the simulation as an increased probability for a cyber incident, as well as prolonged severity of impact. If the vulnerability is removed from the simulation, the probability and impact both reduce and we assign the reduced financial impact to the CVE vulnerability.
DeNexus’ DeRISK platform has a unique cyber-attack simulation capability that no other vulnerability identification solution can offer. We call it DeRISK Quantified Vulnerability Management (DeRISK QVM).
Key highlights of the new offering include:
For more information about DeNexus' DeRISK QVM or to request a demonstration, please visit: https://www.denexus.io/products/derisk/derisk-quantified-vulnerability-management .