Ranking OT vulnerabilities by consequence, not by score
Scanner severity ranks vulnerabilities in the abstract. Operations needs ranking against consequence. How we layer process context over CVSS without discarding the scanner data.
CVSS answers a narrow question: how bad can this vulnerability be in the worst case. Operations asks a different one: what happens to the process if it is exercised today, on this asset, during this batch.
In this note
- A 9.8 on an engineering workstation reachable only from a jump host is not the same risk as a 6.5 on the interlocked controller running the line.
- Process state decides impact: the same flaw is a nuisance at idle and a safety event mid-batch.
- Compensating controls that exist on paper are not compensating controls that are in place.
We keep the scanner data and layer operational context over it: asset role, network reachability, process dependency, existing compensating controls, and the window in which the asset is actually live. The output is a register ordered by what operations would have to suspend if it were exercised, not by what a scanner would like fixed first.
At one site the highest CVSS score in the estate sat on a reporting server nobody depended on. The item that mattered was a medium-severity flaw on the historian interface every operator screen queried. Ordering by severity would have fixed the wrong thing first.