A vendor advisory is raw material. Turning it into intelligence for an ICS/OT environment takes exposure mapping, exploitability assessment, and a clear tie to a decision.
A new ICS vendor advisory drops. It lands in a group chat, in an ISAC digest, in three vendor newsletters. The CVE gets a number. Someone asks in Slack "are we affected?" and the question sits there for a week.
That advisory is not intelligence yet. It is raw material.
The four questions that turn it into intelligence
- Do we have the affected product, version, and configuration anywhere in the environment?
- Is it exposed in a way that makes the vulnerability reachable by the described attack path?
- Is there any evidence of exploitation in the wild against this product?
- What decision does the answer drive: emergency patch, compensating control, monitoring only, or accept and document?
Until those four questions have answers with named owners, the advisory is a rumor with a CVE attached.
Where OT programs get stuck
Most OT programs get stuck at question one. Asset inventory in OT is famously incomplete. Firmware versions in particular are often unknown or stale. That is not a reason to skip the question. It is a reason to invest in answering it faster next time.
Question two is where honeypot fleets and external exposure data pay for themselves. If your decoys running the same vendor stack are seeing exploitation attempts, that changes the answer to question four.
The output
An advisory processed this way produces one paragraph, not a report:
"Advisory X affects product Y version Z, deployed on N devices in sites A and B. Two of those are reachable from the corporate network via jump host J. No exploitation observed in our honeypot fleet or in public reporting. Patch scheduled for next maintenance window. Compensating rule added at firewall F. Owner: name. Next review: date."
That paragraph is intelligence. The original advisory was a press release.