MITRE ATT&CK for ICS: OT Threat Detection with Passive Monitoring and Zeek

Every major attack on industrial control systems of the last decade shared one uncomfortable property: the final, damaging commands were perfectly valid protocol traffic. A Modbus write to a holding register looks the same on the wire whether an engineer or an intruder sends it. That is why MITRE ATT&CK for ICS is useful to defenders only when it is bound to something observable, and why passive network monitoring, rather than endpoint agents or inline blocking, has become the default visibility layer in operational technology (OT).

This matters now because the framework keeps moving. At the time of writing, the official ATT&CK for ICS matrix page shows version 20, released in October 2026, with 12 tactics and a defensive model built around detection strategies and analytics rather than free-text detection notes. Meanwhile, Dragos, Mandiant and ESET have documented ICS-specific tooling that speaks Modbus, IEC 60870-5-104 and OPC UA natively.

This guide builds a working reference architecture: where to place sensors on the Purdue model, how Zeek and Suricata parse OT protocols, how to turn function-code allowlists and process-variable bounds into alerts, and how to map every detection to an ATT&CK technique so the SOC can reason about coverage.

What this covers: the ATT&CK for ICS matrix and its current state, what real incidents teach about detection, passive sensor placement, Zeek and Suricata detection logic with an illustrative Modbus script, baselining, IT/OT SOC integration, and the response constraints that make OT different from IT.

Context and Background

ATT&CK for ICS is MITRE’s knowledge base of adversary behavior against industrial control systems, organized like its Enterprise sibling as tactics (the adversary’s goal) and techniques (how the goal is achieved). It was first released in January 2020 and has been updated in step with the main ATT&CK releases since. According to the official matrix page consulted for this article, the current ICS matrix has twelve tactics: Initial Access, Execution, Persistence, Privilege Escalation, Evasion, Discovery, Lateral Movement, Collection, Command and Control, Inhibit Response Function, Impair Process Control and Impact.

Two of those tactics have no Enterprise equivalent, and they carry the framework’s real insight. Inhibit Response Function covers actions that stop safety, protection and alarm mechanisms from reacting to a hazardous state. Impair Process Control covers manipulation of the process itself: changing setpoints, parameters or control logic. Enterprise ATT&CK describes how an attacker steals data and persists. ICS ATT&CK describes how an attacker makes a physical process misbehave while the operators are blind or distracted.

The defensive model changed in v18

ATT&CK v18, published in October 2025, replaced the old per-technique “Detection” prose and the Data Sources objects with two new object types: Detection Strategies and Analytics, backed by reworked Data Components. The v18 release notes list, for the ICS domain, 83 detection strategies, 82 analytics and 36 data components, alongside 12 tactics, 83 techniques, 14 groups, 23 software entries, 7 campaigns, 52 mitigations and 18 assets. The v20 changelog adds nine further behavioral detection strategies for command, scripting and protocol misuse in ICS and states that ICS detection strategies now carry platform and asset context.

For a detection engineer this is a practical improvement. A detection strategy names the behavior, an analytic expresses a platform-specific way of observing it, and the data components say which telemetry you need. You can now ask a precise question: do my sensors produce the data components that the analytics for this technique require?

Where passive monitoring fits

OT networks differ from IT networks in ways that dictate the architecture. Many controllers cannot host agents, patch cycles are measured in years, protocols such as Modbus carry no authentication, and a mistimed scan can fault a legacy PLC. Passive monitoring, which copies traffic from a switch SPAN port or network TAP and analyzes it out of band, sidesteps those constraints. It cannot disrupt the process, it needs no change on the endpoints, and it sees the one layer attackers cannot avoid: the traffic that carries commands.

The standards agree on the direction. NIST SP 800-82 Rev. 3, published in September 2023, is the US reference guide for OT security, and the IEC 62443 series defines zones, conduits and security levels. If you have not read it, our guide to IEC 62443 zones and conduits explains the segmentation model that the sensor placement in this article assumes. The official ATT&CK for ICS knowledge base lives at attack.mitre.org, and every technique ID cited below resolves there.

The thesis: map telemetry to techniques, not products to tactics

Most vendor material maps a product to the matrix and colors cells green. That tells you nothing about whether your deployment can see an attack. The approach in this article inverts it. Start from the protocol fields your sensors can actually extract, such as function code, register address, unit identifier and source host. Derive detections from those fields. Only then label each detection with the technique it covers. Coverage becomes a measurable property of your telemetry rather than a marketing claim.

Reference Architecture: Passive Detection Mapped to ATT&CK for ICS

A passive OT detection architecture copies traffic from Purdue levels 1 to 3 through TAPs or SPAN ports into protocol-aware sensors running Zeek and Suricata, enriches the output with an asset inventory and baseline, and forwards technique-tagged alerts to a shared IT/OT SOC. Sensors never sit inline, so they cannot break the process.

Figure 1: Reference architecture. Mirrored traffic from field, control and supervisory networks feeds Zeek and Suricata sensors, which write technique-tagged logs into an OT analytics tier and the enterprise SOC.

Figure 1 shows the data path. Switches at the control and supervisory levels mirror traffic to a sensor over a dedicated monitoring interface that has no IP address and cannot transmit. Zeek turns packets into structured protocol logs. Suricata applies signature rules and emits alerts. A normalizer attaches asset identity and ATT&CK technique labels, and the results flow across the DMZ to a log platform that the SOC already uses. Control actions never flow back along this path.

Sensor placement on the Purdue model

The Purdue Enterprise Reference Architecture, as adopted by IEC 62443 and ISA-95 practice, divides the plant into levels. Level 0 is the physical process with sensors and actuators. Level 1 holds PLCs, RTUs and safety controllers. Level 2 holds HMIs and local supervisory systems. Level 3 is site operations: historians, engineering workstations, patch servers. Level 3.5 is the industrial DMZ, and Levels 4 and 5 are enterprise IT.

The placement rule is simple: put a sensor where traffic crosses a trust boundary or concentrates command flow. In practice that means four capture points.

The Level 3 to Level 2/1 boundary. This is where engineering workstations and SCADA servers talk to controllers. Almost every Impair Process Control and Inhibit Response Function technique must cross it.
Between Level 3 and the DMZ. Remote access, historian replication and vendor connections cross here. This is where Initial Access and Lateral Movement become visible.
Inside Level 2/1 on the aggregation switches. Controller-to-controller and HMI-to-PLC traffic that never leaves the cell is invisible from higher up.
At safety-system and remote-site links. Safety instrumented system (SIS) networks and WAN links to substations deserve their own tap, because an attacker aiming at Loss of Safety will go there.

Level 0 fieldbus traffic, such as HART loops or PROFIBUS segments, generally cannot be mirrored with a standard switch, and this is a genuine blind spot. We return to it under trade-offs.

SPAN versus TAP

A SPAN (port mirroring) configuration is free and quick, but it shares switch CPU, can drop frames under load and may silently omit errored packets. A network TAP is a dedicated device that duplicates the link at line rate with fail-open behavior, so a power loss does not sever the link. For a safety-critical or high-throughput segment, use a TAP. For a quiet cell with a few hundred packets per second, SPAN is usually adequate. Either way, validate capture completeness: compare switch interface counters with the sensor’s received-packet count and alert on divergence, because a sensor that silently misses packets produces false confidence, which is worse than no sensor.

Encrypted or authenticated protocols change what passive monitoring can see. OPC UA with the SignAndEncrypt security mode hides payloads from a passive sensor, leaving only connection metadata, certificate exchange and sizes. This is the correct security trade, but it means detection moves toward metadata and endpoint telemetry. Our OPC UA security hardening guide covers the certificate and policy side of that trade.

Why Zeek and Suricata together

Zeek and Suricata overlap but do different jobs. Suricata matches known-bad patterns with signature rules and is the right place for IOCs and well-defined protocol misuse. Zeek is a scripting framework that produces rich per-connection logs and lets you write stateful logic, such as “this host has never written to this controller before.” In OT, where the interesting question is usually “is this command normal for this pair of hosts,” Zeek’s stateful scripting and logging usually carries more weight, while Suricata contributes fast, deterministic rules for the threats that are already described in public reporting.

Core Zeek ships analyzers for Modbus and DNP3. CISA and Idaho National Laboratory publish the ICSNPP (Industrial Control System Network Protocol Parsers) suite, whose repository lists parsers for BACnet, BSAP, C12.22, EtherCAT, EtherNet/IP with CIP, Genisys, OPC UA Binary, ROC-Plus, S7Comm, Synchrophasor and Profinet IO CM, plus parsers for GE-SRTP, HART-IP and Omron FINS. The same repository also provides scripts that extend logging for Zeek’s built-in DNP3 and Modbus analyzers. Protocol coverage therefore depends on which of these packages you deploy, and each should be pinned and tested as a dependency.

Tying sensors to the matrix

Figure 2 below shows the logic that makes the mapping defensible. Each protocol parser exposes fields. A detection rule consumes one or more fields and a baseline. The rule declares which ATT&CK technique it observes and which data component it depends on. If a parser is missing or a link is encrypted, the dependent technique is marked as a coverage gap rather than assumed safe.

Figure 2: From protocol fields to technique coverage. Detections are derived from observable fields and baselines, then labeled with techniques, so gaps appear wherever a field cannot be observed.

The long-description version: parsers on the left produce fields such as function code, object address and source host. Rules in the middle compare those fields against the allowlist and baseline. Technique labels on the right let the SOC count which techniques have at least one working detection and which have none.

What Real ICS Attacks Teach About Detection

Incidents are the best test of a detection model, because they show which observable the defender needed. The facts below come from the primary sources consulted for this article; where a claim was not re-verified in this run it is labelled.

FrostyGoop: valid Modbus, no vulnerability

Dragos reported FrostyGoop, an ICS-specific malware written in Go and compiled for Windows, which communicates with controllers over Modbus TCP on port 502 and can read and write holding registers. MITRE’s software entry (S1165) maps it to Command and Scripting Interpreter, Commonly Used Port (T0885), Modify Parameter (T0836), Monitor Process State (T0801) and Standard Application Layer Protocol (T0869). Per Dragos reporting relayed by WaterISAC, it was used against a municipal district energy company in Lviv, Ukraine, disrupting heating to more than 600 apartment buildings in sub-zero temperatures, with remediation taking almost two days. The same reporting says the attackers possibly entered through an externally facing Mikrotik router, and that the router, four management servers and the heating controllers were not adequately segmented.

The detection lesson is blunt. No exploit was needed, because Modbus TCP has no authentication; the commands were well-formed. A signature for malware would have missed it, since antivirus did not detect FrostyGoop when Dragos found it. What would have caught it is a baseline: a new source host sending Modbus writes to heating controllers it had never contacted, from a segment that had no business talking to Level 1.

Industroyer2: the protocol is the payload

ESET analyzed Industroyer2 in April 2022 with CERT-UA. It targeted a Ukrainian energy provider, with destructive actions scheduled for 8 April 2022. Unlike its 2016 predecessor, which carried several protocol modules, Industroyer2 supports only IEC 60870-5-104 (IEC-104), and the analyzed sample contained eight hard-coded device IP addresses. ESET assessed with high confidence that Sandworm was responsible and noted that CaddyWiper and Linux and Solaris wiper tooling accompanied it to slow recovery.

Two lessons follow. First, a hard-coded list of target IPs is a gift to a baseline: an IEC-104 session from a host that is not the known control center to an RTU is an anomaly by definition. Second, the wipers show why OT detection cannot stop at the process network. The attacker also destroyed the operator’s visibility, so the sensor and its log store must sit outside the blast radius.

INCONTROLLER/PIPEDREAM: tooling built for many vendors

Mandiant, working with Schneider Electric, described INCONTROLLER (also called PIPEDREAM) in April 2022. It is a modular toolset with three components. TAGRUN scans for and interacts with OPC UA servers. CODECALL talks Modbus and CODESYS to devices such as the Schneider Electric Modicon M251. OMSHELL targets Omron controllers over HTTP, Telnet and the Omron FINS protocol. Mandiant stated that it saw no confirmed deployment against an operational environment, assessed the toolset as very likely state-sponsored and judged it capable of disruption, sabotage and potentially physical destruction. The joint CISA advisory AA22-103A covered the same toolset.

The detection lesson is that protocol-aware discovery is the early warning. Enumerating OPC UA servers, brute-forcing logins and scanning for Modbus devices generate characteristic traffic long before any harmful write. These map to the Discovery tactic, and a sensor that logs OPC UA sessions and connection fan-out can see it.

TRITON and Stuxnet: attacks on safety and logic

MITRE’s entry for TRITON (S1009, also known as TRISIS and HatMan) describes it as an attack framework for Triconex safety controllers, associated with the group TEMP.Veles and the Triton Safety Instrumented System Attack campaign. The mapped techniques include Detect Operating Mode (T0868), Program Download (T0843), Change Operating Mode (T0858), Modify Controller Tasking (T0821) and Loss of Safety (T0880). For a network sensor, the critical observables are a program download or mode change to a safety controller from any host that is not the engineering workstation, and a controller mode switch outside a maintenance window.

Stuxnet, discovered in 2010 and aimed at Siemens S7 controllers in an enrichment facility, is the original example of logic manipulation. Its specifics were not re-fetched for this article, so treat the following as general background: it modified PLC code delivered through the engineering software and masked the change from operators. The detection principle holds for any similar attack: a block download or upload to a PLC is a rare, scheduled event, and S7comm logging can surface it.

Figure 3 summarizes how these incidents line up across the tactic chain and which passive observable would have flagged each stage.

Figure 3: A generic ICS intrusion mapped to ATT&CK tactics and the passive observable that exposes each stage. Detection is cheapest at Initial Access and Discovery, and most valuable at Impair Process Control.

The chain in Figure 3 runs left to right: a foothold through an exposed edge device, discovery of controllers, lateral movement into the control network, then the three tactics that matter physically. A detection placed late in the chain is a detection of a fault already in progress. A good program spends its effort on the early links while keeping a hard backstop on write commands.

Passive DPI of Industrial Protocols

Deep packet inspection (DPI) for OT means decoding the application protocol far enough to extract who is asking, what operation they request and which object they target. This section covers what each major protocol exposes, and where the visibility ends.

Modbus TCP

A Modbus TCP frame carries a transaction identifier, protocol identifier, length, a unit identifier and then the function code and data. The function code is the key field. Function codes 1 to 4 are reads of coils, discrete inputs, holding registers and input registers. Codes 5, 6, 15 and 16 write a single coil, write a single register, write multiple coils and write multiple registers. Function 23 reads and writes registers in one request. Exception responses echo the function code with its top bit set, so a failed write to function 6 returns 0x86.

Zeek’s Modbus analyzer exposes this as events, including modbus_message for every PDU with its header and direction, and request and response events for each write function (for example modbus_write_single_register_request with an address and value). Modbus has no notion of identity, so the only identity is the source IP address and the unit identifier. That is why the baseline of which hosts may write is the central control.

DNP3

DNP3 carries function codes for read, write, select, operate and direct operate, and adds unsolicited responses from outstations. Select-before-operate sequences are normal for control actions, so an unexpected Direct Operate or a cold restart request to an outstation is high-signal. Secure Authentication exists in the standard (IEEE 1815) but deployment is uneven, so a sensor must assume that many links are unauthenticated.

Siemens S7comm

S7comm and its encrypted successor S7CommPlus carry read and write variable operations and block-level functions such as download, upload and PLC stop. A passive sensor can see the unencrypted classic variant fully. For S7CommPlus with integrity protection, visibility is reduced and you rely on connection metadata. The ICSNPP suite includes an S7comm parser, so block transfers and CPU stop commands become log records.

EtherNet/IP and CIP

CIP (Common Industrial Protocol) over EtherNet/IP carries explicit messaging for services such as get and set attribute, and implicit I/O messaging over UDP for cyclic data. Explicit services that write attributes or change a controller’s mode are the interesting ones. CIP Security adds authentication and encryption but is not universal, so brownfield sites remain largely observable.

OPC UA

OPC UA is the protocol most likely to be encrypted. In its None or Sign modes, a sensor can decode service calls such as Browse, Read, Write and Call, which exposes enumeration behavior like the TAGRUN pattern. In SignAndEncrypt mode, you see only the secure channel establishment, certificate details and traffic volume. The ICSNPP suite provides an OPC UA Binary parser; verify which security modes your servers actually negotiate before assuming coverage.

IEC 60870-5-104 and others

IEC-104, central to Industroyer2, runs over TCP port 2404 and uses typed information objects and commands. Command types such as single and double commands are the equivalent of writes. Whether your Zeek build parses IEC-104 depends on the package; if it does not, a Suricata or custom-binpac approach, or a commercial platform, fills the gap. I could not confirm a maintained open-source IEC-104 parser in this research, so verify before relying on one.

A table of what the sensor can see

Protocol	Typical port	Passive visibility	High-signal observable
Modbus TCP	502	Full, unauthenticated	Write function codes from unlisted hosts
DNP3	20000	Full unless Secure Authentication	Direct Operate, cold restart, unsolicited floods
S7comm	102	Full for classic, partial for S7CommPlus	Block download, CPU stop
EtherNet/IP and CIP	44818 and 2222	Full unless CIP Security	Set attribute, mode change
OPC UA	4840 and vendor ports	None-to-Sign visible, SignAndEncrypt metadata only	Browse fan-out, Write from new client
IEC-104	2404	Depends on parser availability	Command ASDUs from non-master hosts

Port numbers are the registered defaults; plants frequently change them, so detect protocols by content rather than port wherever the analyzer supports it.

Writing Detections: Zeek Scripts, Suricata Rules and Baselines

Detection logic for OT falls into three families. Signatures catch known-bad content. Allowlists catch anything outside an approved set of functions, hosts or objects. Baselines catch statistical or behavioral drift in process values and communication patterns. Mature programs use all three, because each fails differently.

Function-code allowlisting with Zeek

The first Zeek script below is deliberately small. It does two things: it flags any Modbus request whose function code is outside an approved set, and it flags any write function code sent by a host that is not a known engineering station or SCADA server. It is an illustrative sketch, not production code. I did not run it against live traffic for this article, and the ModbusHeaders field name function_code should be confirmed against your Zeek version’s documentation before deployment.

@load base/protocols/modbus
@load base/frameworks/notice

module OTDetect;

export {
    redef enum Notice::Type += {
        Modbus_Write_From_Unlisted_Host,   # ATT&CK for ICS T0836 Modify Parameter
        Modbus_Function_Not_Allowlisted    # ATT&CK for ICS T0855 Unauthorized Command Message
    };

    # Illustrative values - replace with your asset inventory
    const authorized_writers: set[addr] = { 10.20.5.10, 10.20.5.11 } &redef;
    const write_functions: set[count] = { 5, 6, 15, 16, 23 } &redef;
    const allowed_functions: set[count] = { 1, 2, 3, 4, 5, 6, 15, 16 } &redef;
}

event modbus_message(c: connection, headers: ModbusHeaders, is_orig: bool)
    {
    if ( ! is_orig )
        return;   # only inspect requests, not responses

    local fc = headers$function_code;

    if ( fc !in allowed_functions )
        NOTICE([$note=Modbus_Function_Not_Allowlisted,
                $conn=c,
                $msg=fmt("Modbus function %d from %s to %s is outside the allowlist",
                         fc, c$id$orig_h, c$id$resp_h),
                $identifier=cat(c$id$orig_h, c$id$resp_h, fc)]);

    if ( fc in write_functions && c$id$orig_h !in authorized_writers )
        NOTICE([$note=Modbus_Write_From_Unlisted_Host,
                $conn=c,
                $msg=fmt("Modbus write function %d from unlisted host %s to %s",
                         fc, c$id$orig_h, c$id$resp_h),
                $identifier=cat(c$id$orig_h, c$id$resp_h)]);
    }

Three design choices matter more than the syntax. The script keys on requests only, so responses do not double-count. It uses $identifier so Zeek’s notice framework suppresses repeats instead of flooding the SOC when an intruder writes hundreds of registers. And the allowlists are &redef constants, so they can be generated from the asset inventory and shipped as configuration rather than edited as code.

Notice that the allowlist treats a function code such as 8 (diagnostics) or 17 (report server ID) as suspicious by default. That is a policy decision. Some historians and diagnostic tools legitimately use them, and your first deployment will surface those, which is the point of an allowlist: it forces the plant to document what normal is.

Signature rules with Suricata

Suricata’s Modbus support allows rules that match on function codes or access type. The following illustrative rules assume network variables $ENGINEERING_STATIONS and $PLC_NET are defined in your configuration. The modbus keyword syntax should be checked against the documentation for your installed Suricata version before use, because I could not fetch the current keyword page during this research.

alert modbus !$ENGINEERING_STATIONS any -> $PLC_NET any (msg:"OT Modbus write from non-engineering host - ATT&CK ICS T0836"; modbus: access write; flow:to_server; classtype:attempted-admin; sid:9100001; rev:1;)

alert modbus any any -> $PLC_NET any (msg:"OT Modbus diagnostics function used - possible device disruption"; modbus: function 8; flow:to_server; classtype:attempted-dos; sid:9100002; rev:1;)

The first rule overlaps the Zeek script, which is deliberate redundancy: two independent parsers must both be fooled to hide a write. The second targets the diagnostics function, which includes sub-functions that can put a device into listen-only mode. Treat both as starting points that you tune with your own traffic, not as validated detection content.

Baselining: assets, communications and process values

Allowlists need data, and data comes from a learning period. A passive sensor builds three baselines.

The asset inventory. Passive discovery observes which IP and MAC addresses speak which protocols, extracts vendor and model strings from protocol responses where the protocol exposes them, and lists firmware versions when available. This works without scanning, which matters because active scans can fault fragile devices. The inventory is also the prerequisite for ATT&CK coverage reasoning: you cannot say which techniques apply to an asset you do not know exists. Rogue-device detection, a new MAC on a control VLAN, covers Initial Access and Lateral Movement cheaply.

The communications matrix. For each pair of hosts, record protocol, direction, function codes and rough periodicity. Control traffic is remarkably regular: a SCADA server polls the same registers on a fixed schedule. A new edge in the graph, or a known edge that changes function code, is an anomaly worth review. A learning window of two to four weeks that covers shift changes, batch cycles and maintenance windows is a common practice, though the right duration depends on the process and I am not citing a standard for it.

Process-variable bounds. Because the sensor decodes register values in write requests and read responses, you can apply range checks. A tank-level setpoint written as 0 when the historical range is 40 to 80 percent is suspect regardless of who sent it. This is the closest passive monitoring comes to process awareness, and it matters most for Impair Process Control and Manipulation of Control. The caveat is semantic: a register is just an integer until someone maps it to a tag, scaling and engineering unit. Building that map is a joint project with the controls engineers, and it is where most of the effort goes.

Anomaly detection without a data-science project

Fancy models are rarely the bottleneck. Three simple statistics catch most behavior changes: the rate of write requests per source per minute, the count of distinct destination hosts contacted by a source in a window (fan-out, which exposes discovery sweeps), and the entropy or variance of values written to a register. Because OT traffic is periodic, even a threshold of a few standard deviations over a rolling baseline works. Reserve machine learning for cases where rules demonstrably fail, and always keep the allowlist as the explainable layer, since an operator will ask why an alert fired.

Mapping detections to ATT&CK techniques

The table below shows how detections in this article map to technique IDs. The IDs come from the MITRE pages consulted for this article (FrostyGoop S1165 and TRITON S1009 entries and the v20 changelog); the remaining labels use technique names from the ICS matrix and should be checked against the live matrix, since v20 deprecated or renumbered some entries. For example, the legacy page for Unauthorized Command Message (T0855) now redirects to T1692/001.

Detection	Observable	ATT&CK for ICS technique
Write function from unlisted host	Modbus function 5, 6, 15 or 16	Modify Parameter T0836
Function code outside allowlist	Any unexpected function code	Unauthorized Command Message T1692/001 (formerly T0855)
Controller mode change	S7 or CIP mode service	Change Operating Mode T0858
Program download to PLC	S7 block download or CIP file transfer	Program Download T0843
Broadcast or sweep discovery	High fan-out of new connections	Remote System Discovery, Broadcast Discovery T0846.002
Unusual register read polling	Reads from a new source	Monitor Process State T0801
New Modbus client on port 502	New host in comms matrix	Commonly Used Port T0885
Safety controller write	Any traffic to SIS zone from non-engineering host	Loss of Safety T0880

Figure 4 below shows how an alert travels from the sensor to the SOC and what the operator can do next, which brings us to integration and response.

Figure 4: Alert flow and response. Sensor alerts are enriched with asset and process context, triaged jointly by the SOC and plant operations, and resolved through controlled response actions rather than automatic blocking.

Trade-offs, Gotchas, and What Goes Wrong

Passive monitoring has limits that vendors rarely volunteer. Knowing them is the difference between a sensor program and a compliance checkbox.

Encryption erodes visibility. As OPC UA SignAndEncrypt, S7CommPlus, CIP Security and Modbus/TCP Security spread, payload inspection disappears. This is good security and bad news for DPI. Plan for metadata detection (who connected, when, how much) and for endpoint or controller-side logging, and do not claim coverage for techniques that depend on payload fields you cannot see.

SPAN drops and asymmetric capture. A mirrored port that drops frames makes Zeek miss half a conversation, which breaks stateful logic and creates false positives. Monitor capture loss explicitly. Capturing only one direction of a flow has the same effect.

The learning-period trap. If an intruder is already present during baseline learning, their behavior becomes normal. Validate the learned matrix with the process owners before enforcing it, and re-validate after every change window.

Alert fatigue from legitimate engineering work. Engineers download logic, change setpoints and switch modes as part of their job. If the SOC cannot distinguish a planned change from an attack, analysts will mute the rules that matter most. Integrate with the change-management calendar so alerts during approved windows are annotated, not suppressed.

Level 0 and serial blind spots. Serial Modbus RTU, HART and fieldbus segments often have no mirrorable port. The compromise is to monitor at the gateways that bridge them to Ethernet and to accept that direct sensor tampering is invisible.

Parser maturity and the supply chain. Community parsers vary in quality, and a parser crash or a malformed-packet bug is itself a risk on a sensor that reads attacker-influenced bytes. Run sensors with least privilege, patch them, and treat them as part of the attack surface. This is consistent with the zero-trust posture described in our industrial zero trust architecture guide.

ATT&CK is not a checklist. A technique list says nothing about prevalence or impact. Counting green cells encourages breadth over depth. Prioritize the techniques that your own threat model says lead to a safety or production consequence, and test each detection with a replayed packet capture or a lab PLC before you trust it.

IT/OT SOC Integration and Response Constraints

Integrating with the enterprise SOC

Send Zeek logs and Suricata alerts through a one-way path across the industrial DMZ, typically a data diode or a tightly restricted syslog or message-queue relay, into the same SIEM the enterprise SOC uses. Normalize fields to a common schema so an OT alert appears with source, destination, protocol, function and technique label next to the IT events that preceded it. The most valuable correlation is IT-to-OT: a credential misuse on a jump host followed minutes later by a new Modbus writer is a single incident, and the ATT&CK Enterprise and ICS matrices are designed to chain this way.

Staffing is the harder problem. IT analysts do not know that a Modbus write to register 40001 may open a valve. Pair analysts with a plant-side responder, write runbooks that name the process consequence of each alert class, and put the asset owner’s phone number in the alert enrichment.

Why you cannot just block

The IT instinct to isolate a compromised host can cause the very harm an attacker wants. Cutting a link to a controller can trigger a fail-safe trip, a process shutdown or, in the worst case, a loss of view that leaves the process running unobserved. Inline blocking also adds latency and a new failure point to deterministic control loops. For these reasons the default response to an OT alert is investigate, contain at the boundary, and fall back to manual operation, not isolate automatically.

Containment options therefore escalate by consequence. First, increase monitoring and verify with the operator. Second, tighten firewall rules at the Level 3 or DMZ boundary to cut the attacker’s path to the control network while leaving cell-level control intact. Third, place the affected cell in a known-safe state under operator supervision. Only after those would you isolate a controller, and only with the process owner’s approval. Put these decisions in the incident response plan before the incident, and rehearse them in a tabletop exercise that includes operations, safety and engineering, not just security.

NIST SP 800-82 Rev. 3 and IEC 62443-2-1 both stress that OT incident response must account for safety and availability. The Dragos recommendations relayed after FrostyGoop point the same way: ICS incident response, a defensible architecture, network visibility and monitoring, secure remote access and risk-based vulnerability management.

Practical Recommendations

Start with visibility, not detection content. A small number of well-placed TAPs and a trustworthy asset inventory outperform a large rule set built on a partial view. Deploy one sensor at the Level 3 to Level 2 boundary first, run it in alert-only mode and learn the communication matrix for several weeks before turning on allowlist alerts.

Write detections from fields, then label them. Begin with the highest-consequence behaviors: writes from unlisted hosts, program downloads, mode changes and any traffic into safety zones. Keep a coverage sheet that lists each technique, the data component needed, the detection that covers it and the date it was last tested. Mark encrypted links as gaps.

Treat the sensors as production assets. Pin Zeek, Suricata and every ICSNPP package, test upgrades on replayed captures and monitor capture loss. Keep logs off the process network so an attacker who wipes Windows hosts cannot also erase the evidence, a lesson that the Industroyer2 incident makes concrete.

Finally, decide the response before the alert. Agree with operations on what containment steps are acceptable for each alert class, and document who can authorize them.

Place sensors at the L3 to L2/1 boundary, the DMZ crossing and safety links; prefer TAPs on critical segments.
Build the asset inventory passively; never scan fragile controllers.
Create function-code and source-host allowlists per controller pair, reviewed with controls engineers.
Label every detection with an ATT&CK technique and track untestable techniques as gaps.
Forward alerts one-way to the SOC with asset and process context.
Pre-approve containment steps; default to boundary tightening over blocking.
Test detections with replayed captures and a quarterly purple-team run.

Frequently Asked Questions

What is MITRE ATT&CK for ICS?

MITRE ATT&CK for ICS is a public knowledge base of adversary tactics and techniques observed against industrial control systems. It extends the ATT&CK approach with tactics specific to physical processes, such as Inhibit Response Function and Impair Process Control. Defenders use it to describe attacks consistently, map detections to behaviors, and measure which techniques they can actually observe. The current matrix, per the official site, is version 20 with twelve tactics.

How is ATT&CK for ICS different from Enterprise ATT&CK?

Enterprise ATT&CK models attacks on IT systems such as endpoints, identity and cloud. The ICS matrix models attacks on controllers, safety systems and industrial protocols, and includes tactics for manipulating or disabling physical processes. Its impact techniques concern loss of control, safety and availability rather than data theft alone. Real incidents often cross both matrices, so mature SOCs chain Enterprise techniques on the IT side with ICS techniques on the OT side.

Why use passive monitoring instead of an inline firewall or IPS in OT?

Passive monitoring receives a copy of traffic, so it cannot add latency, drop packets or fault a sensitive controller. Many legacy devices cannot run agents and may crash during active scanning. Inline blocking can also trip a fail-safe or cause loss of view. Passive sensors are therefore the standard first layer, with enforcement placed at well-understood boundaries such as the industrial DMZ.

Can Zeek parse industrial protocols out of the box?

Zeek ships analyzers for Modbus and DNP3. For others, the CISA and INL ICSNPP suite adds parsers listed in its repository, including BACnet, EtherNet/IP with CIP, OPC UA Binary, S7comm, Profinet IO CM, EtherCAT and Synchrophasor, among others. Quality and coverage vary, so test each parser on captures from your own equipment before relying on it, and check how it behaves with encrypted variants of the protocol.

Can you detect FrostyGoop-style attacks with passive monitoring?

Yes, in principle, because the attack used well-formed Modbus TCP traffic. A sensor that baselines which hosts write to which controllers and which function codes appear would flag a new source writing to heating controllers. Signature-only approaches may miss it, since antivirus reportedly did not detect the malware initially. Segmentation between the edge router, management servers and controllers would also have reduced exposure.

Does ATT&CK coverage mean I am protected?

No. Coverage describes whether you have a detection for a technique, not whether it works, fires in time or gets triaged correctly. A technique with a green cell but an untested rule is a false assurance. Use coverage as a planning tool, validate with replayed traffic and purple-team exercises, and weight techniques by the consequence they carry for your specific process.