Adversary questions are only as good as the evidence available to answer them. Part three builds a control network collection plan from passive taps, engineering workstation logs, remote access records, and protocol honeypots.
Part one established what you operate. Part two established who is plausibly interested and what they would have to do. Both produce questions. Part three is about making those questions answerable, which is the job of a collection plan.
Start from the question, not the tool
A collection plan is not a shopping list of sensors. It is a mapping from intelligence questions to evidence sources, with an honest note where no source exists.
Take a question from a part two profile: would we detect vendor remote access being used outside an approved maintenance window? Work backwards. That requires jump host authentication logs, session recordings or at minimum session metadata, the maintenance calendar as a data source rather than a spreadsheet nobody exports, and network flow at the conduit between the industrial demilitarized zone and the control zone. If any of those four are missing, the question is currently unanswerable, and that gap is the finding.
The core sources in a control network
- Passive network capture at zone boundaries. Span or tap at the conduit between enterprise, industrial demilitarized zone, and control zones. This is the single highest value source because it requires no agent on fragile equipment.
- Engineering workstation telemetry. These machines hold the project files, the programming software, and the credentials. Endpoint logging here is worth more than broad coverage of low value hosts.
- Remote access records. Jump hosts, VPN concentrators, vendor portals, and any cellular or serial backdoor that exists whether or not it appears on the drawing.
- Controller and historian events. Configuration change counters, mode switches, program download events, and unexplained tag writes.
- Authentication and directory logs. Most industrial intrusions still run on stolen credentials.
- Deception sensors. Honeypots that speak Modbus, DNP3, IEC 104, BACnet, and OPC-UA and that mimic vendor accurate device personas.
Why deception earns its place here
Production control traffic is noisy and consequential. You cannot safely fuzz it, and you cannot always instrument it deeply. Deception inverts the problem. A decoy device has no legitimate users, so every interaction is signal by definition, and false positives approach zero.
Placed inside a segment, a protocol honeypot answers questions that production monitoring struggles with: is anything on this segment enumerating industrial protocols, is anyone attempting a write function code rather than a read, and does a compromised laptop start scanning the moment it connects. Placed at the edge, it tells you what the internet is currently attempting against equipment that looks like yours.
Vendor accuracy matters. A generic banner gets fingerprinted and skipped by a capable operator. A decoy that presents realistic device identity, register layout, and response timing holds attention long enough to capture intent.
Write down what you cannot collect
Every mature collection plan has a gap column. Serial links with no monitoring point. A remote site with bandwidth too thin for full capture. A vendor appliance that exports nothing useful. Recording those honestly prevents a dangerous habit: quietly rewording the intelligence question until the available data happens to answer it.
Review the plan on a schedule
Collection follows adversary behavior, and adversary behavior moves. Review the plan quarterly against the tracked profiles. Retire sources that never produced a decision. Add sources that a real investigation revealed you were missing.
Next in the series
Collection produces raw evidence. Evidence has to become something the SOC can act on at three in the morning. Part four turns intelligence and collected traffic into protocol aware detections with thresholds that survive real operations.