Indicators expire. Behavior does not. Part four converts adversary profiles and collected control network evidence into detections built on protocol semantics, process context, and thresholds that survive normal operations.
Parts one through three gave us assets, adversaries, and evidence. Part four is where intelligence stops being a document and becomes a rule that fires.
Why indicator matching underperforms in OT
Hashes and addresses are the shortest lived artifacts an adversary owns. In an industrial environment they are also the least likely to appear, because much of the damaging activity uses legitimate engineering software talking legitimate protocols. A detection strategy resting on indicator matches will be quiet right up until it matters.
Behavior lasts longer. Someone has to enumerate devices, read configuration, write a value, or download a program. Those actions have protocol level expressions, and protocol level expressions can be detected.
Build detections on protocol semantics
Industrial protocols are unusually predictable in production, which is a gift to detection engineering. Normal traffic is often a repeating poll pattern between a fixed set of peers. That makes deviation meaningful.
Useful detection classes include:
- New peer relationships. A host that has never spoken Modbus to a controller suddenly does. Low volume, high value.
- Function code anomalies. Read traffic is routine. Write single register, write multiple registers, program download, and mode change requests belong to a small approved set of sources at known times.
- Enumeration behavior. Sequential unit identifier or point scanning, especially from a single source across many outstations.
- Timing deviation. Poll intervals that shift, bursts outside the historical envelope, or requests arriving during a period that has been quiet for a year.
- Engineering action outside a window. Any configuration write correlated against the maintenance calendar.
- Deception interaction. Any packet reaching a decoy sensor, treated as a high confidence alert.
Tie every rule to a question and a consequence
Each detection should carry three lines of metadata: the intelligence question it serves, the asset consequence tier it covers, and the expected analyst action. A rule with no expected action becomes noise the SOC learns to close without reading.
Consequence tiering also solves prioritization. An unauthorized write to a tier one device that trips a feeder is a page. The same write to a lab bench unit is a ticket. Without the inventory work from part one this distinction is impossible, which is why the series runs in this order.
Baseline before you threshold
Do not guess at normal. Use the passive capture from part three to establish real baselines per segment: which peers talk, which function codes appear, at what cadence, and during which hours. Then set thresholds against measured behavior. Baselines drift after plant changes, so treat them as living artifacts tied to change management rather than a one time exercise.
Validate safely
Test detections against replayed capture, against a honeypot you control, and against a lab or spare unit. Never validate a control network detection by generating unexpected traffic toward production equipment. The rule is simple: prove the detection on a system where being wrong is affordable.
Measure what actually improved
Track a small number of honest metrics. How many detections produced a real defensive action. How long from evidence to alert. How many of the questions from part two are now covered by at least one rule. Coverage against your own questions is a better measure than counting rules.
Next in the series
Detections raise alerts. Alerts in a control environment require decisions that involve engineers, operators, and sometimes regulators. Part five closes the loop with intelligence driven response, from first alert to an action an operator can safely take.