Threat intelligence for SCADA fails when nobody can say what is actually installed, reachable, and business critical. Part one of a five part series builds the asset truth that every later intelligence judgment depends on.
Most SCADA security programs start in the wrong place. They start with a feed. Someone buys indicators, wires them into a SIEM, and waits for a match. Weeks later the team has alerts nobody can act on, because no one can answer the only question that matters when an ICS advisory lands: do we operate that thing, and if we do, where is it?
This is part one of a five part series on SCADA cybersecurity through a threat intelligence lens. Each part builds on the one before it. We begin with asset truth, because every intelligence judgment downstream inherits its accuracy.
Intelligence needs a subject
Threat intelligence is a claim about an adversary set against a defended environment. Remove the environment and you are left with trivia. A report describing a campaign against a specific programmable logic controller family is only actionable if you know your controller models, firmware versions, communication protocols, and network placement.
In practice, the gap looks like this. An advisory names a vulnerability in a widely deployed RTU. The control engineer believes those units were replaced in a 2021 refresh. The maintenance records show a partial refresh. Three substations still run the old hardware, and one of them was temporarily connected to a vendor support laptop last month. Nobody knew that until someone went looking.
The inventory that intelligence actually needs
A compliance asset list is not the same as an intelligence grade inventory. To support analysis, each record should carry:
- Identity: make, model, firmware or software version, and serial where practical
- Function: what physical process the device influences and what happens if it misbehaves
- Protocols: Modbus, DNP3, IEC 60870-5-104, MMS, OPC-UA, BACnet, or proprietary variants
- Reachability: which zone it sits in, what conduits cross that boundary, and whether remote access ever terminates near it
- Ownership: the human who can approve a change and the vendor who supports it
- Consequence tier: the operational impact ranking used to prioritize work
Consequence tier is the field most programs skip and the one intelligence work depends on most. Two identical PLCs are not equally important. One sequences a nonessential auxiliary. One trips a feeder that serves a hospital.
Building it without stopping the plant
You do not need an invasive scan to make progress. Passive traffic collection at aggregation points, configuration exports from engineering workstations, historian tag lists, vendor purchase records, and interviews with the operators who actually run the process will get you most of the way. Passive first, active only with a maintenance window and engineering approval.
Expect the inventory to disagree with itself. That disagreement is a finding, not an embarrassment. Every conflict between what the drawings say and what the network shows is a place an adversary could operate unobserved.
What good looks like
You know you have enough asset truth when three things become fast:
- A new advisory can be answered with a device count and a location list within one working day.
- Any alert can be attributed to a named device with a known process function.
- Any proposed mitigation can be evaluated against operational consequence before it is applied.
Until those three are true, more feeds will not help. They will only make the noise louder.
Next in the series
With a defensible picture of what you operate, the next question becomes who is interested in it. Part two moves from assets to adversaries and shows how to build actor profiles that stay tied to your specific SCADA footprint rather than drifting into generic geopolitics.