In an industrial plant the clearest sign of an attack is often in the process itself: a setpoint nobody approved, an alarm that was silenced, a controller that changed mode, and those signs are visible only if someone is watching process data and operator actions with security in mind. MITRE D3FEND names this countermeasure Operational Process Monitoring (D3-OPM), with the synonym Supervisory Control Monitoring, and defines it as "Monitoring physical parameters and operator actions related to an operational environment." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM). This card explains how D3-OPM works, which ATT&CK techniques D3FEND relates to it, where it is implemented in an OT architecture, and how to verify it catches tampering. It is written for OT security engineers, control engineers and SOC teams that monitor industrial sites, and assumes the background in the OT Security Guide.
Key takeaways
- It watches the process, not just the network. D3FEND's description combines physical events and operator actions with analysis of event logs, so it sees misuse made with valid credentials and valid commands.
- Two artefacts carry it. D3-OPM monitors the Event Log and uses the OT Process Data Historian, the system that stores telemetry, events, alerts and alarms about the process.
- D3FEND names five tampering indicators. Malfunctions, unauthorised commands, unsafe setpoint changes, alarm suppression and anomalous mode transitions.
- The ATT&CK list is Enterprise and inferred. D3FEND relates D3-OPM to Enterprise techniques that touch event logs, such as log clearing and token manipulation; it shows no ICS techniques, so the ICS mapping on this page is our own view and labelled as such.
- Process engineers are part of the control. Only people who know the plant can say whether a setpoint change or a mode transition was safe and expected.
D3-OPM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-OPM (d3f:OperationalProcessMonitoring) |
| Synonym | Supervisory Control Monitoring |
| Tactic | Detect |
| Parent technique | Platform Monitoring (D3-PM) |
| Digital artefacts | monitors Event Log; uses OT Process Data Historian |
| D3FEND reference | NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (Final, September 2023) |
| Typical data sources | Controller and HMI logs, historian tags and event tables, alarm and event journals, engineering workstation logs |
| D3FEND version checked | 1.6.0, November 2026 |
How it works
D3FEND's knowledge base article notes that while some OT systems run without human intervention, most are designed so people can monitor and modify the physical process. D3-OPM detects adversarial risks to that process by observing physical events and operator actions and analysing event logs. D3FEND lists four steps:
- Read logs generated by controllers and HMIs, through data acquisition units and data acquisition agents.
- Produce digital event records from those logs.
- Aggregate and store: display the data on an HMI or process historian, and write the records to event logs and to the OT process data historian for traceability and incident reconstruction.
- Monitor and detect incidents or indicators of tampering.
The five indicators D3FEND names map onto observable data. The table below is our practical reading of each; the examples are illustrations, not D3FEND content.
| D3FEND indicator | What to watch (example) | Related ATT&CK for ICS technique (NHI Mgmt Group view) |
|---|---|---|
| Malfunctions | Process values outside engineering limits, unexplained trips, controller faults recorded in the historian | T0827 Loss of Control |
| Unauthorised commands | Write commands from a source that is not an approved HMI or engineering workstation, or outside a work order window | T0831 Manipulation of Control |
| Unsafe setpoint changes | Setpoint or parameter changes beyond approved ranges, or changes made by an unexpected operator account | MITRE ATT&CK for ICS T0836 Modify Parameter |
| Alarm suppression | Alarms shelved or disabled, alarm limits changed, a drop in alarm count that does not match process state | MITRE ATT&CK for ICS T0878 Alarm Suppression, MITRE ATT&CK for ICS T0838 Modify Alarm Settings |
| Anomalous mode transitions | Controller switched to program or remote mode outside maintenance | ICS T0858 Change Operating Mode |
Mode transitions are covered in more depth by the sibling card D3-OMM Operating Mode Monitoring.
ATT&CK techniques D3FEND relates to D3-OPM
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-OPM. The techniques below are inferred because they act on the Event Log artefact that D3-OPM monitors; D3FEND labels these relations inferred and experimental (D3FEND 1.6.0, checked November 2026). The D3FEND page shows Enterprise techniques only. D3FEND lists Clear Windows Event Logs under an ID that ATT&CK v20 has revoked; its v20 successor is T1685.005. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Relevance in OT |
|---|---|---|
| T1685.005 | Clear Windows Event Logs | Clearing logs on Windows HMIs, historians and engineering workstations to hide operator actions |
| T1070.003 | Clear Command History | Removing shell history on Linux-based gateways and servers |
| T1546.003 | Windows Management Instrumentation Event Subscription | Persistence on Windows OT servers through WMI event subscriptions |
| T1546.005 | Trap | Persistence through shell signal traps on Unix-like OT servers |
| T1134.002, T1134.003 | Create Process with Token, Make and Impersonate Token | Acting as another operator or service account, which corrupts the "who did it" field in the log |
| T1548.003 | Sudo and Sudo Caching | Privilege escalation on Linux hosts in the OT DMZ |
| T1110.001, T1110.003, T1110.004 | Password Guessing, Password Spraying, Credential Stuffing | Attempts against HMI, historian and remote access logons, recorded in event logs |
| T1003.006 | DCSync | Credential theft from a domain that also serves the OT zone |
| T1140, T1187 | Deobfuscate/Decode Files or Information, Forced Authentication | Shown on the D3FEND page without IDs; IDs added here from ATT&CK v20 |
The D3FEND ontology also records that T0811 Data from Information Repositories accesses the OT Process Data Historian, the artefact D3-OPM uses, though the D3FEND page shows no ICS row. Protecting the historian matters because it is both the detection store and an attack target; see T0811 Data from Information Repositories. For log clearing and token abuse in depth, see the T1070 Indicator Removal Defensive Guide and MITRE ATT&CK T1134 Access Token Manipulation.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| Process historian with event and alarm journals | Time series of process values and records of operator actions, alarms and acknowledgements | A historian already exists; security rules can be added as calculated tags or queries |
| HMI and SCADA alarm and audit logs | Operator logon, setpoint writes, alarm shelving, with operator identity | The HMI supports per-operator accounts and forwards its audit log |
| OT network monitoring platforms | Passive protocol decoding of read and write commands, mode changes and programme downloads, correlated with assets | Many sites and vendors, or controllers without useful logs |
| SIEM with OT content | Correlation of historian, HMI and Windows event logs with IT identity data | A central SOC monitors IT and OT; see Securing the OT security monitoring platform itself |
Platform choices and rollout are covered in the OT security monitoring platform rollout playbook. This page does not repeat them.
Where identity fits
D3-OPM is only as good as the identity in each record. Shared HMI logons, a single "operator" account per shift, and service accounts that write setpoints on behalf of batch systems all make "unauthorised command" impossible to judge. Per-person operator accounts and named service accounts for automated writers turn the log into evidence. The account side is covered in the D3-LAM Local Account Monitoring card.
Deployment steps
- Agree the critical variables with process engineers. For each unit, list the setpoints, alarms and mode states whose unexpected change is unsafe, with their approved ranges. This becomes the rule set.
- Confirm the sources. Check that controllers and HMIs produce logs with operator identity, that data acquisition reaches the historian, and that clocks are synchronised across controllers, HMIs and historian.
- Write rules in alert-only mode. Start with the five D3FEND indicators for the critical variables. Run them against historical historian data first to estimate alert volume before going live.
- Route alerts to both teams. Operations sees process context; the SOC sees the IT context (logons, remote access sessions). Agree who decides whether a change was legitimate.
- Protect the historian and logs. Forward event records out of the OT zone through a one-way or tightly controlled path so tampering on a compromised HMI does not erase them.
- Roll back without touching the process. Monitoring rules are read-only; disabling a noisy rule never changes control logic. Keep it that way: do not let detection tooling write to controllers.
How to verify it works
- Simulator or test bench: make an out-of-range setpoint change, shelve an alarm and switch a test controller mode, then confirm each produces an alert with operator, source and time. Never test on a live process without operations approval and a safety review.
- Replay: replay a recorded maintenance event through the rules and confirm it is recognised as approved when matched to the work order.
- Log integrity: clear a log on a test HMI and confirm the central copy and the T1685.005 alert both exist.
- Time sync check: compare controller, HMI and historian timestamps for the same event; drift breaks incident reconstruction.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Critical variables with a monitoring rule | 100% of the agreed list |
| Setpoint and alarm changes attributable to a named person or service account | Above 95% |
| Alerts reconciled with a work order within one shift | Above 90% |
| Test bench scenarios detected each quarter | All five indicators |
| Maximum clock drift between controller, HMI and historian | Under one second |
Limits, bypasses and failure patterns
- Spoofed process values: an attacker who controls the controller or the data path can feed normal-looking values to the HMI and historian while the process does something else. Independent sensing and safety systems are the backstop.
- Shared accounts: without per-operator identity, "unauthorised command" cannot be separated from routine work.
- Historian as a single point of failure: if detection reads only from the historian, an attacker who reaches the historian (T0811) can read and possibly alter the evidence.
- Rules without process knowledge: thresholds set by the SOC alone either flood operators or miss unsafe changes that stay within generic limits.
- Alert fatigue in the control room: security alerts mixed into the operator alarm list compete with safety alarms; route them separately.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-82 Rev. 3 | Guide to OT Security | D3FEND's reference for D3-OPM; OT monitoring in its operational context. NIST lists a Revision 4 initial public draft open for comment as of November 2026. |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting, CA-7 Continuous Monitoring | Monitoring and review of process and operator events |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring computing hardware and software and runtime environments; analysing adverse events |
| MITRE D3FEND | D3-PM, D3-OPM | Parent and technique |
Practitioner checklist
- Agree a list of critical setpoints, alarms and mode states with process engineers.
- Give every operator and automated writer its own account.
- Synchronise clocks across controllers, HMIs and historian.
- Write rules for all five D3FEND indicators, starting in alert-only mode.
- Forward event records out of the OT zone and alert on log clearing.
- Keep monitoring read-only; never let detection tooling write to controllers.
- Test on a simulator or bench each quarter, never on a live process without approval.
- Route security alerts separately from the operator alarm list.
Standards and references
- MITRE D3FEND: Operational Process Monitoring (D3-OPM)
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE CAR: CAR-2016-04-002 User Activity from Clearing Event Logs
- MITRE ATT&CK for ICS: T0878 Alarm Suppression
- MITRE ATT&CK for ICS: T0836 Modify Parameter
Related NHI Mgmt Group resources: MITRE D3FEND Guide · NIST SP 800-82 OT Security Guide · PLC Security Guide · D3-OMM Operating Mode Monitoring · OT Security Guide