MITRE ATT&CK for ICS: How to Use It to Build Concrete Detection Rules

What MITRE ATT&CK for ICS Is and Why Reading It Is Not Enough

MITRE ATT&CK for ICS is a structured knowledge base of tactics, techniques and procedures (TTPs) documented in real attacks against industrial control systems. It is not a list of vulnerabilities, nor a regulatory standard: it is a catalogue of observed offensive behaviours, organised in a matrix that covers the entire lifecycle of an ICS attack, from initial access through to manipulation of the physical process.

The framework has existed since 2020 and is updated on a regular basis, incorporating analyses of documented campaigns such as INDUSTROYER, TRITON, Sandworm and more recent attacks. Today it counts dozens of techniques spread across eleven tactics.

The problem is not the quality of the material: it is how it gets used. Many organisations treat it as an awareness checklist, read it once, perhaps use it for an assessment, then file it away. This produces no detection capability at all. The useful question is not "which techniques does the framework use?" but "which of these techniques are detectable on our network, with the tools we have, right now?"

Answering this question requires a mapping effort that starts from analysing your own visibility capabilities, not from the framework.

The Most Relevant Tactics for Manufacturing SMEs

Not all eleven tactics carry the same relevance for a mid-sized manufacturing plant. Some require levels of sophistication historically observed in state-sponsored actors targeting national critical infrastructure. Others, by contrast, appear in almost every documented incident, including those involving mid-sized industrial organisations.

Initial Access (TA0108) is the entry point. The most frequent techniques in industry are the abuse of legitimate remote access connections (T0822), such as vendor VPNs, remote maintenance systems and exposed jump servers, and the compromise of software supply chains (T0862). Spearphishing aimed at IT staff that then becomes the springboard into OT does not have a dedicated technique in ICS but is modelled in the IT phase of the ATT&CK Enterprise framework that precedes lateral movement.

Lateral Movement (TA0109) includes techniques such as Default Credentials (T0812), still hugely widespread in OT environments, where many devices keep their factory credentials, and Program Download (T0843), which describes the modification of control logic through legitimate programming connections.

Impair Process Control (TA0106) and Inhibit Response Function (TA0107) are the final tactics of the most destructive attacks. Techniques such as Spoof Reporting Message (T0856) or Manipulate I/O Image (T0835) are hard to detect without deep visibility into the process, but some precursors, such as unusual access to a PLC's write functions, are detectable at the network level.

Discovery (TA0102) is often the most visible phase: after entering the OT network, attackers carry out reconnaissance to understand the topology and identify critical assets. This activity generates detectable anomalous traffic: ARP scans, requests to devices a host had never communicated with before, enumeration of PLC registers.

What You Can Detect with Passive Network Traffic Monitoring

Passive monitoring, that is, capturing and analysing all traffic in transit without sending any active probe, offers substantial coverage across several MITRE ATT&CK for ICS techniques, but not all of them.

Techniques detectable from network traffic include:

• New communications between hosts that had never interacted: indicates possible lateral movement or discovery.
• Access to critical function codes in industrial protocols (Modbus write coils, DNP3 direct operate, OPC-UA write): detectable by decoding the application payload, not just the TCP headers.
• Connections to unknown remote addresses from OT devices: a warning sign of C2 or exfiltration.
• Program downloads to PLCs via programming protocols (S7comm, EtherNet/IP CIP): the signature of programming traffic is distinguishable from normal operational traffic.
• Variations in communication timing and volumes relative to the baseline: some manipulation techniques introduce delays or variations in polling cycles that show up at the network level.
• Presence of scanning tools: traffic patterns that indicate active reconnaissance of the OT network.

Techniques not detectable from network traffic alone include changes to a PLC's internal logic made through an already authorised programming channel (if the credentials are valid the traffic looks legitimate), manipulation of process parameters within an authorised session, and techniques that take place entirely within a single device without generating external traffic.

How to Build a Map of Your Detection Capabilities

The practical approach is to build a coverage matrix: for each relevant technique of the framework, document whether an active detection rule exists, which data source it relies on and what the confidence level is.

A useful template for each technique:

1. Is it detectable with our current data sources? (network traffic, firewall logs, SIEM logs, endpoint logs if available)
2. Does a detection rule already exist? If so, when was it last tested?
3. What is the confidence level? High confidence: the technique generates an unambiguous signal. Medium: it requires correlation with other events. Low: the signal is weak or easily confused with legitimate behaviour.
4. What are the expected false positives? A rule with medium confidence but a high expected false positive rate is less useful than a rule with high confidence.

This exercise systematically reveals the gaps: the techniques for which there is no coverage at all, not even in theory. These gaps must be documented and used to guide visibility investment decisions: not to draw up a shopping list of tools, but to understand which additional data (endpoint logs, specific probes, integration with control systems) would change coverage significantly.

Prioritising the Rules Worth Investing in First

With limited resources, the reality for SMEs, it is not possible to cover all of the framework's techniques at once. Prioritisation must be driven by three criteria:

Documented frequency: some techniques appear in almost every documented ICS incident (abuse of remote access, use of default credentials, network discovery), others in a narrow subset of sophisticated attacks. Start with the former.

Detectability with current capabilities: all else being equal, give priority to techniques for which the data source already exists and only the rule is missing. It is the fastest way to increase coverage without infrastructure investment.

Potential impact on the process: a technique that could lead to a production line shutdown or a physical safety incident deserves priority over one that leads only to data exfiltration.

The outcome of this process is not a theoretical document but a concrete backlog of detection rules to develop, test and put into production, ordered by expected impact. This backlog must be reviewed every time the framework is updated with new techniques or when campaigns emerge that use TTPs not yet covered.

The Continuous Improvement Cycle

One thing the MITRE ATT&CK for ICS framework does not state explicitly but that emerges from practice: detection is not a state to reach but a continuous process. Attack techniques evolve, environment configurations change, detection rules degrade over time because the network changes and the baseline shifts.

A realistic improvement cycle for a mid-sized industrial organisation includes: quarterly review of the coverage map, periodic testing of existing rules with simulations of anomalous behaviour, updating rules when new threat intelligence reports on ICS campaigns are published, and verifying that the data sources the rules rely on are still active and not degraded.

The goal is not to achieve total coverage, which does not exist, but to have clear visibility into what you can detect, with what confidence, and where the blind spots lie. This transparency is the foundation of an honest, improvable security posture.

The MON5 Angle

The article's key question, which techniques are detectable with current tools, has an uncomfortable answer for many organisations: few, because OT traffic visibility is missing. MON5 covers exactly the area where passive monitoring delivers the most: out-of-band NDR decodes native protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) and detects discovery, lateral movement and anomalous writes to PLCs, while ML anomaly detection flags deviations from the baseline.

The result is ATT&CK for ICS technique coverage that is measurable on network data. To map your current coverage, plan an OT assessment.