D3-PUM Platform Uptime Monitoring: Catching Unexpected Restarts on Hosts and Controllers

A forced crash or restart is one of the simplest ways to disrupt a system or load changes that only take effect at boot, and an uptime counter that suddenly resets to zero is often the only trace. MITRE D3FEND names this countermeasure Platform Uptime Monitoring (D3-PUM) and defines it as "Monitor the amount of time since the last power cycle or restart." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM). D3FEND's own data for it is thin: one artefact, one reference and no ATT&CK mapping, so this is a short reference card. It covers what the technique does, where the uptime value comes from on controllers, network devices and servers, how to verify alerts fire, and why the value cannot always be trusted. It is written for OT engineers, infrastructure monitoring owners and SOC analysts.

Key takeaways

• A reset is the signal. D3FEND says monitoring time since the last restart alerts operators to unexpected restarts and their frequency, and gives forensic value as well.
• D3FEND lists no ATT&CK mapping. The D3FEND page shows no related offensive techniques; the Top 20 Secure PLC Coding Practices, D3FEND's reference, ties the practice to ATT&CK for ICS T0816 Device Restart/Shutdown.
• The source can lie. D3FEND's own consideration is that the uptime value may be mutable depending on the platform and its provenance.
• SNMP sysUpTime is not host uptime. RFC 3418 defines it as time since the network management portion of the system was last re-initialised, so an agent restart also resets it.
• Pair uptime with the reason. A reset alone says something happened; shutdown reason codes, crash records and change tickets say whether it was expected.

D3-PUM at a glance

What it detects

The Top 20 Secure PLC Coding Practices (V1.0, June 2021), D3FEND's reference, gives the security reasoning in practice 17: forcing a crash or restart is a basic attack vector, so unexpected restarts can signal unusual activity. It adds a maintenance reason: restart records show which PLCs were worked on and when. Its guidance is to track uptime inside the PLC where a system variable exists, inside the PLC through MIB-2 and SNMP where supported, or externally over SNMP, and to raise an HMI alert on any restart. Practice 18, "Log PLC hard stops and trend them on the HMI", is the companion: record fault or shutdown error codes, log the first scan after the PLC wakes up, and time-synchronise the records.

Outside OT, the same signal applies to servers, hypervisors and network devices. An unexpected reboot can mean a crash caused by exploitation, a deliberate shutdown to disrupt service, or a reboot to activate a bootkit, driver or changed boot configuration.

ATT&CK techniques and D3-PUM

Relationship type: none in D3FEND. The D3FEND page for D3-PUM lists no related ATT&CK techniques and the ontology gives it no artefact shared with ATT&CK. The rows below are NHI Mgmt Group's view of where an uptime reset is a useful signal; the T0816 row follows D3FEND's reference, which maps practices 17 and 18 to it. Each ID was checked against ATT&CK v20.

See MITRE ATT&CK for ICS T0816 Device Restart/Shutdown and MITRE ATT&CK T1529 System Shutdown/Reboot for the attack side.

Where the uptime value comes from

Platform classes are listed alphabetically.

For the controller side, see the PLC Security Guide; for the Windows log pipeline, the Windows Event Log Guide.

Deployment steps

1. Pick the source per platform class. Prefer a host-level value (Windows events, /proc/uptime, a controller status tag) over SNMP sysUpTime where both exist, and record which one each asset uses.
2. Collect on a fixed interval. Poll or stream the value centrally. A value lower than the previous reading is a reset.
3. Attach the reason. On Windows, correlate with 1074 reason codes, 41 and 6008; on controllers, with the hard stop records from practice 18; everywhere, with change and patch windows.
4. Alert on unexplained resets. Resets with no change ticket, maintenance window or patch job are alerts. For critical controllers, D3FEND's reference recommends alerting on any restart.
5. Trend frequency. Repeated resets on one asset point at instability or an ongoing denial of service.
6. Roll back. Monitoring is read-only; if a new rule floods the queue, return it to logging only while maintenance windows are wired in.

How to verify it works

• Planned reboot test: reboot a test server, a network device in the lab and a test controller, inside and outside a declared window. The first should be suppressed or labelled expected; the second should alert.
• Agent restart test: restart only the SNMP agent on a lab device and confirm the rule does not report it as a device reboot, or that it is labelled as an agent restart.
• Unclean shutdown test: on a lab Windows host, cut power and confirm events 41 and 6008 produce an "unexpected restart" alert.
• Coverage check: compare assets reporting uptime against the inventory each week.

Limits, bypasses and failure patterns

• Mutable values: D3FEND warns that the source of the value may be mutable depending on the platform. An attacker with control of a device may be able to alter what it reports; cross-check with an independent source such as network monitoring or the HMI's own records.
• Polling gaps: a reboot that completes between polls still shows as a lower value, but a device that is offline when polled may be recorded as a monitoring failure instead of a restart.
• Counter wrap: sysUpTime is a TimeTicks value in hundredths of a second and wraps after a long uptime; treat a wrap as a possible false reset.
• No reason data: uptime alone cannot separate a patch reboot from an attack, so alert volume grows unless reasons are correlated.
• Treating restart as the only sign: many changes take effect without a reboot; D3-PUM complements, and never replaces, configuration and firmware monitoring such as D3-FV Firmware Verification.

Framework mapping

Practitioner checklist

• Record the uptime source for every critical asset.
• Prefer host-level values to SNMP sysUpTime where both exist.
• Correlate every reset with a change, patch or maintenance record.
• Alert on any restart of a critical controller.
• Log controller hard stops and the first scan after wake-up, with synchronised time.
• Trend restart frequency per asset.
• Test with planned, unplanned and agent-only restarts in the lab.

Standards and references

• MITRE D3FEND: Platform Uptime Monitoring (D3-PUM)
• PLC Security: Top 20 Secure PLC Coding Practices V1.0
• IETF: RFC 3418 Management Information Base for SNMP (sysUpTime)
• Microsoft Learn: Troubleshoot unexpected reboots using system event logs
• Linux man-pages: proc_uptime(5)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE D3FEND Guide · D3-OSM Operating System Monitoring · D3-OPM Operational Process Monitoring · PLC Security Guide · MITRE ATT&CK for ICS T0816 Device Restart/Shutdown