Controllers count their own faults and timer failures all the time, and when someone changes their logic or parameters those counters often move before anything else does. MITRE D3FEND names this countermeasure Application Exception Monitoring (D3-AEM), synonym Application Failure Monitoring, and defines it as "Monitoring the failures of system counters and timers." It sits under the Detect tactic as a child of Application Performance Monitoring (D3-APM), and it monitors two digital artefacts: the Application Failure Count Variable and the Log. D3FEND's knowledge base article and its single reference, the Top 20 Secure PLC Coding Practices, place it firmly in industrial control: PLC error flags, timer and counter status bits, and fault logs. This card explains what D3-AEM detects, how D3FEND relates it to ATT&CK, how to implement and verify it on controllers, and where the same idea applies to IT applications. It is written for OT security engineers, controls engineers and the SOC analysts who receive their alerts.
Key takeaways
- It watches the controller's own error bookkeeping. Error flags such as divide by zero, counter overflow, negative timer or counter presets and I/O scan overrun are counted and alerted on rather than silently cleared.
- Safety and security share the signal. D3FEND notes that timer and counter failures matter for both safety and security, and may reveal tampering with the device or the process it controls.
- The ATT&CK links are inferred through the Log artefact. D3FEND relates D3-AEM to 14 enterprise techniques that modify or may modify a log, such as Clear Command History (T1070.003) and DCSync (T1003.006); the PLC-specific mappings come from the Top 20 practices, not from D3FEND.
- It needs no new hardware. The Top 20 practices that underpin it use functions native to the PLC and the HMI, so the main cost is engineering time and alarm design.
- Thin on its own. Fault counters detect clumsy or disruptive changes; a careful adversary who changes logic without tripping a fault needs integrity checks and cycle time monitoring as well.
D3-AEM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-AEM (d3f:ApplicationExceptionMonitoring) |
| Synonym | Application Failure Monitoring |
| Tactic | Detect |
| Parent technique | Application Performance Monitoring (D3-APM), which monitors controller cycle count and duration |
| Digital artefacts | Application Failure Count Variable (monitors); Log (monitors) |
| Artefact definition | Application Failure Count Variable: "Variables that keep count of various failures and errors" |
| Vendor tag examples in D3FEND | Allen-Bradley S:ERR (system error), T4:0.DN (timer status bit), C5:0.OV (counter overflow bit) |
| D3FEND reference | Top 20 Secure PLC Coding Practices, V1.0 (15 June 2021) |
| Main limitation | Only detects changes that cause faults or timer and counter anomalies |
How it works
D3FEND's description is brief: monitoring timer and counter failures or exceedances can reveal issues with the program or platform, and may help identify tampering or malicious activity affecting the device or the processes it controls. The artefact note adds that controller brands expose different system tags for this, giving Allen-Bradley examples for a system error, a timer done bit and a counter overflow bit.
The Top 20 Secure PLC Coding Practices, which D3FEND cites, turn this into concrete practices:
- Practice 4, Use PLC flags as integrity checks: count error flags such as divide by zero, counter overflow, negative counter or timer presets and I/O scan overrun so that unexpected faults are investigated rather than ignored. Because most PLCs offer no cryptographic integrity checking, unexpected flags can indicate that logic was changed. The document maps this to Modify Parameter (T0836).
- Practice 6, Validate timers and counters: check preset values written to timers and counters against an allowed range inside the PLC rather than trusting the HMI. The document's examples: a 1.3 second alarm timer preset to 5 minutes would never fire in time, and a stop counter at 10,000 set to 11,000 would never reach its stop point. Mapped to T0836.
- Practice 18, Log PLC hard stops and trend them on the HMI: store fault and shutdown events, read and clear the controller's last fault codes and forward them to a syslog server, with time synchronisation for accurate timestamps. Mapped to Device Restart/Shutdown (T0816).
- Practice 20, Trap false negatives and false positives for critical alerts: compare each critical alarm's trigger bit with its trigger conditions, so a suppressed alarm or a fake alarm is itself detected. Mapped to Alarm Suppression (T0878).
Practices 16 (cycle times), 17 (uptime) and 19 (memory usage) belong to the parent, Application Performance Monitoring, and to the related Platform Uptime Monitoring technique; they complement D3-AEM and are usually implemented on the same HMI trend screens.
Signals to collect
| Signal | Where it lives | What a change may indicate |
|---|---|---|
| Math and overflow error flags (divide by zero, counter overflow) | Controller status file or system tags | New or altered logic, out-of-range parameters written remotely |
| Negative or out-of-range timer and counter presets | Timer and counter structures | Parameter tampering intended to delay or prevent an action (T0836) |
| I/O scan overrun | Controller diagnostics | Added logic or abnormal communication load |
| Major and minor fault codes, hard stops | Controller fault log, read with vendor instructions (for Rockwell, the GSV instruction named in the Top 20 document) | Forced restarts or crashing logic (T0816) |
| Alarm trigger bit versus trigger conditions | PLC logic written for the purpose | Alarm suppression or false alarm injection (T0878) |
ATT&CK techniques D3FEND relates to D3-AEM
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-AEM. Every row below is inferred through the Log artefact: D3-AEM monitors Log, and each technique modifies or may modify a Log or one of its sub-artefacts such as Event Log or Command History Log. D3FEND labels these relations inferred and experimental (D3FEND 1.6.0, checked November 2026). D3FEND shows no ATT&CK for ICS mapping for D3-AEM. D3FEND also lists Clear Windows Event Logs under an ID that ATT&CK has since revoked; its ATT&CK v20 successor is T1685.005, shown below. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Practical relevance to D3-AEM |
|---|---|---|
| T1070.003 | Clear Command History | Log tampering on engineering workstations; the log monitoring side of D3-AEM |
| T1685.005 | Clear Windows Event Logs | Gaps or clears in host logs that sit beside fault logs |
| T1134.002, T1134.003 | Create Process with Token, Make and Impersonate Token | May modify event logs; weak relation for controller monitoring |
| T1546.003, T1546.005 | Windows Management Instrumentation Event Subscription, Trap | Log modification on IT hosts; weak relation |
| T1548.003 | Sudo and Sudo Caching | Configuration and log effects on Linux hosts; weak relation |
| T1110.001, T1110.003, T1110.004 | Password Guessing, Password Spraying, Credential Stuffing | Failure counts in authentication logs, the IT analogue of a failure counter |
| T1003.005, T1003.006 | Cached Domain Credentials, DCSync | May modify logs; weak relation |
| T1140 | Deobfuscate/Decode Files or Information | May modify event logs; weak relation |
| T1187 | Forced Authentication | Entries in authentication logs; weak relation for controller monitoring |
In NHI Mgmt Group's view most of these enterprise relations are a by-product of the generic Log artefact rather than what D3-AEM is for. The techniques that matter for controller fault monitoring come from the Top 20 practices: MITRE ATT&CK for ICS T0836 Modify Parameter, MITRE ATT&CK for ICS T0816 Device Restart/Shutdown and MITRE ATT&CK for ICS T0878 Alarm Suppression.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| PLC logic | Counting error flags, range-checking presets and comparing alarm bits with conditions inside the controller, as the Top 20 practices describe | Always; it is the closest point to the process and needs no extra hardware |
| HMI and SCADA alarms and trends | Alarms on fault count increases and trend screens for faults, cycle time, uptime and memory | Operators need to see the signal next to the process |
| Historian and syslog forwarding | Long-term storage of fault codes and hard stops, with synchronised timestamps | Investigations and baselining over months |
| OT network monitoring platforms | Passive collection of controller diagnostics, mode changes and program downloads seen on the network | Many controllers, mixed vendors, a central OT SOC |
| IT application monitoring (analogue, NHI Mgmt Group view) | Exception and crash counts from application performance monitoring and error tracking tools | The same pattern applied to business applications, where a spike in exceptions can accompany injection or fuzzing |
Controller-side hardening is in the PLC Security Guide and network-side collection in the OT Network Security Monitoring Guide. For the IT analogue, secure exception handling is covered in the Secure Error Handling and Logging Guide.
Implementation steps
- Inventory the fault signals per controller family. For each PLC model, list the system tags or diagnostic functions that expose error flags, fault codes and timer and counter status, from the vendor's programming documentation.
- Agree ranges with process engineers. For every safety- or quality-relevant timer and counter, record the allowed preset range. This is engineering knowledge, not security knowledge, and it is the basis for Practice 6.
- Add counting and validation logic in a test environment. Count flags rather than clearing them, validate presets inside the PLC, and write alarm trap logic for critical alarms. Test on a simulator or spare controller first, because added logic changes cycle time.
- Surface on the HMI and forward off the controller. Create alarms for fault count increases and trends for faults and hard stops; forward fault codes to syslog or the historian with synchronised time.
- Baseline. Some processes produce benign faults routinely. Record a few weeks of counts (the period is an example, not a standard) and set alarm thresholds above normal background.
- Route to the right responders. A fault spike may be maintenance, process upset or tampering. Agree in the OT Incident Response Guide process who looks first and when security is called.
- Roll back safely. Keep the previous program version under change control so added monitoring logic can be removed in a planned window if it causes cycle time or alarm problems.
How to verify it works
- Bench test: on a test controller, force each monitored condition (an out-of-range preset, a divide by zero in a test routine, a forced alarm bit) and confirm the count increments, the HMI alarms and the event reaches the historian or SIEM.
- Alarm trap test: during a planned window, assert a critical alarm's conditions with the trigger bit held off in a test routine and confirm Practice 20 logic reports a false negative.
- Restart evidence: after a planned restart, confirm the hard stop is logged with the correct timestamp.
- Exercise inclusion: in tabletop or purple team exercises, include a scenario where parameters are changed remotely and check that fault signals were seen.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Critical controllers with fault counting and forwarding in place | 100% of safety- and production-critical PLCs | Coverage of the assets that matter |
| Critical timers and counters with documented allowed ranges | Rising towards 100% | Validation is impossible without ranges |
| Bench test conditions detected end to end | 100% per test cycle | Proves the chain from PLC to responder |
| Fault alarms investigated with a recorded cause | All high-priority alarms | Prevents alarm fatigue hiding tampering |
Limits, bypasses and failure patterns
- Clearing faults instead of counting them: code that silently resets error flags to keep the process running removes the very signal D3-AEM depends on.
- Careful changes that never fault: an adversary who modifies logic or parameters within valid ranges trips no flag. Pair D3-AEM with program integrity checks (Practice 5) and cycle time and memory trending from the parent technique; see T0889 Modify Program.
- Alarm logic that can itself be suppressed: the Top 20 document cites the Triton attack, where rogue code suppressed alerts. Alarm trap logic and off-controller logging make suppression harder to hide; see the ICS Malware History Guide.
- Writable diagnostics: where controller web servers or protocols expose variables with misconfigured access rights, alert bits can be changed remotely. Restrict variable access, as in D3-OVAR OT Variable Access Restriction.
- Unsynchronised clocks: fault logs without reliable time cannot be correlated with engineering workstation or network events.
- Performance surprises: extra logic adds scan time; adding it to a heavily loaded controller without testing can cause the overrun it is meant to detect.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring the system to detect attacks and anomalies |
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity | Fault signals as an indirect integrity indicator for controller logic |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Review of forwarded fault and hard stop logs |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring computing hardware, software and runtime environments; analysing adverse events |
| Top 20 Secure PLC Coding Practices | Practices 4, 6, 18, 20 | The concrete source practices behind D3-AEM |
| MITRE D3FEND | D3-APM, D3-AEM | Parent and technique |
Related countermeasures
- Application Performance Monitoring (D3-APM): the parent, covering cycle count and duration.
- Platform Uptime Monitoring (D3-PUM): restarts and uptime trends, Practice 17.
- OT Variable Access Restriction (D3-OVAR): limits who can write the variables D3-AEM watches.
- Operating Mode Restriction (D3-OPR): blocks program changes while the controller is in run mode; see D3-OPR Operating Mode Restriction.
Practitioner checklist
- List the error flag, fault code and timer and counter status tags for each controller family.
- Count error flags instead of silently clearing them.
- Validate timer and counter presets inside the PLC against ranges agreed with process engineers.
- Write alarm trap logic for every critical alarm.
- Forward fault codes and hard stops to syslog or the historian with synchronised time.
- Test added logic on a simulator or spare controller for cycle time impact.
- Baseline normal fault counts before setting alarm thresholds.
- Bench test every monitored condition end to end each test cycle.
- Pair fault monitoring with program integrity checks and cycle time trending.
Standards and references
- MITRE D3FEND: Application Exception Monitoring (D3-AEM)
- PLC Security: Top 20 Secure PLC Coding Practices V1.0
- PLC Security: Secure PLC Coding Practices project
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: MITRE D3FEND Guide · PLC Security Guide · OT Security Guide · HMI and SCADA Server Hardening Guide · OT Network Security Monitoring Guide