Actor names are easy to collect and hard to use. Part two turns generic ICS threat reporting into adversary profiles anchored to the specific devices, protocols, and access paths you documented in part one.
In part one we built asset truth: the devices, protocols, reachability, and consequence tiers that describe what you actually operate. That inventory is now the filter for everything that follows. In part two we use it to decide which adversaries deserve your attention and what about them is worth tracking.
The problem with actor collecting
Many programs treat adversary tracking as a naming exercise. The wall fills with group names, flags, and slide graphics, and none of it changes a single control decision. The failure is not the reporting. It is that the reporting was never intersected with the environment.
An adversary profile becomes useful when it answers a scoped question: given what we operate, what would this group need to do here, and would we see it?
Anchor profiles to behavior, not identity
Attribution is interesting. Behavior is operational. For each group you decide to track, record the elements that map onto your own environment:
- Initial access patterns: internet exposed remote access, vendor and integrator paths, phishing into the business network, removable media
- Pivot behavior: how they move from enterprise to the industrial demilitarized zone and then into control zones
- Protocol interaction: whether they have demonstrated the ability to speak Modbus, DNP3, IEC 104, or MMS rather than only living on Windows hosts
- Tooling and living off the land: engineering software abuse, legitimate vendor utilities, dual use administrative tools
- Impact intent: data theft and positioning versus disruption or manipulation of process
- Observed sectors and device families: the direct intersection with your inventory
That last item is where most tracking lists collapse. If a group has only ever been documented against equipment you do not operate, the profile still has value for anticipating tradecraft, but it does not compete for immediate defensive spend.
Score relevance, then say so out loud
Relevance is a judgment and it should be written like one. A workable format for each tracked group is short:
Assessment: moderate relevance to our footprint. Because: they target the vendor remote access model we use and have demonstrated interaction with DNP3 outstations, two of which appear in our substation inventory. Unknown: whether they have operated against our specific firmware branch. Therefore: we prioritize remote access telemetry and DNP3 function code baselining this quarter.
That structure keeps analysts honest. Observed, assessed, unknown, next action. It also makes the profile reviewable, which matters because relevance decays. A group that shifts targeting or retires tooling should drop in priority, and the only way that happens is if the reasoning was recorded in the first place.
Positioning is the signal to watch
Serious SCADA intrusions rarely open with damage. They open with quiet positioning: credential collection, engineering workstation access, documentation theft, and long dwell time while the adversary learns the process. Profiles that only describe the destructive endgame train defenders to look for the loudest phase of an operation and to miss the months that precede it.
Track the boring stages. Track the vendor account that logged in from a new network. Track the historian query pattern nobody scheduled. Those are the observations that arrive early enough to matter.
Next in the series
Profiles generate questions. Questions require evidence, and evidence requires deliberate collection. Part three builds the SCADA collection plan that turns these adversary questions into specific sensors, logs, and honeypot deployments.