Process
Vulnerability management for OT
A workflow that respects maintenance windows, vendor validation and the fact that a controller reboot is a process event.
01
Intake
Subscribe to vendor advisories and CISA ICS advisories. Route every advisory into one queue with an owner and a due date.
02
Applicability
Match advisories against the asset inventory by product, firmware and module — most advisories will not apply to you, and proving that quickly is valuable.
03
Reachability
Determine which zones can reach the affected service. An unreachable vulnerability is a monitoring item, not an emergency.
04
Consequence
Ask what the affected asset does physically. Score on loss of view, loss of control and safety impact, not on CVSS alone.
05
Decision
Choose patch, mitigate, isolate, monitor or accept. Record the rationale, the compensating controls and the review date.
06
Scheduling
Patches land in maintenance windows after vendor validation and, where possible, lab testing on representative hardware.
07
Execution
Change managed jointly with operations and engineering, with rollback prepared and a person named to execute it.
08
Validation
Verify the fix technically and verify the process is unaffected: setpoints, alarms, interlocks and communications all behave as before.
Decisions
Five valid outcomes
Every advisory ends in one of these, recorded with an owner and a date.
Vendor-validated fix, an available window, and testable rollback.
Disable the affected service, restrict its interface or apply vendor workarounds.
Remove reachability with firewall rules or zone changes until a window exists.
No fix and no isolation possible — add specific detection on the conduit and asset.
Documented, time-bound, approved at the right level, and reviewed on a schedule.
Why should I care?
Unpatchable is not the same as undefendable. Most OT risk reduction comes from removing reachability and adding targeted detection while the fix waits for a window.
Scanning safely
- Prefer passive discovery and configuration data over active scanning in production
- Never run untuned vulnerability scanners against controllers or safety systems
- If active checks are unavoidable, test in a lab and run during an outage with engineering present
- Derive versions from asset management and engineering tools where possible
Metrics that mean something
- Percentage of advisories triaged for applicability within SLA
- Count of internet-reachable or IT-reachable OT services (target: zero)
- Known-exploited vulnerabilities present on reachable OT assets
- Backlog of accepted risks past their review date