MITRE D3FEND Platform Monitoring Implementation Guide: Choosing, Sequencing and Measuring 21 Platform Monitoring Techniques

Most endpoint and server estates collect plenty of process telemetry, yet very few can say whether their kernel, boot chain, firmware, services and startup configuration have changed since the last known good state. MITRE D3FEND groups the controls that answer that question under Platform Monitoring (D3-PM), a technique in the Detect tactic with 21 descendant techniques, from File Integrity Monitoring to Firmware Verification and Operating Mode Monitoring for OT controllers. This guide treats D3-PM as a programme: what the family covers, how its children fit together, the order to build them in, how to prove they work and where they fail. It is written for detection engineers, endpoint and platform owners and OT security leads. Each child technique has its own page on this site; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• Platform Monitoring watches the layers below the user. D3FEND defines it as monitoring platform components such as operating system software, hardware devices or firmware, including kernel modules, boot code, system libraries, drivers and embedded firmware.
• The family has four natural clusters. Operating system monitoring (ten techniques), file integrity, firmware integrity (five techniques) and OT controller monitoring (four techniques), plus Platform Uptime Monitoring that spans all of them.
• Most children compare state against a baseline. Hashes of files, firmware and service binaries, recorded startup configuration and known operating modes are only useful if the reference value is trustworthy and stored where an attacker cannot change it.
• The ATT&CK links are broad and inferred. D3FEND lists persistence, stealth, defence impairment, credential access and more against D3-PM and labels the mappings "inferred, experimental": use them to plan tests, not to claim coverage.
• Silence is a signal. Endpoint Health Beacon and the tamper checks in System Daemon Monitoring exist because attackers stop the monitor before they act, so a missing heartbeat must page someone.

What D3FEND means by Platform Monitoring

In the D3FEND ontology D3-PM sits in the Detect tactic. Its knowledge base article describes it as the analysis and monitoring of system level devices and low level components, including hardware, to detect unauthorised modification or suspicious activity. The components it names are kernel software modules, boot process code and load logic, operating system components and device files, system libraries and dynamically loaded files, hardware device drivers and embedded firmware devices.

D3-PM is distinct from neighbouring Detect families. Process Analysis watches what running programs do, File Analysis inspects file content for malice, and Network Traffic Analysis watches the wire. Platform Monitoring asks a narrower and more durable question: has the platform itself changed, and is its monitoring still alive? That makes it the natural home for persistence detection, rootkit and bootkit detection and anti-tamper monitoring.

Every child technique and what it watches

The table lists every descendant of D3-PM in the D3FEND ontology, grouped by its position in the hierarchy, with the digital artefact D3FEND says it monitors, analyses or verifies. Indented rows are children of the row above.

How the children fit together

Read as a system rather than a list, the 21 techniques answer five questions. Grouping them this way is our NHI Mgmt Group view, not part of D3FEND.

D3-MBT and D3-IDA sit apart: they are runtime exploit and input device checks usually delivered by endpoint protection or OS hardening rather than by a separate monitoring tool.

Choosing and sequencing the children

The order below is an NHI Mgmt Group recommendation, based on which techniques catch the most common persistence routes at the lowest operational cost.

1. Start with the heartbeat. Deploy D3-EHB and D3-SDM first: alert when an endpoint agent, logging service or forwarder stops reporting or is stopped. Every later technique depends on the telemetry still flowing. In ATT&CK v20 the behaviour this catches is T1685 Disable or Modify Tools.
2. Collect startup and scheduling state. D3-SICA, D3-USICA and D3-SJA cover T1547 Boot or Logon Autostart Execution, T1543 Create or Modify System Process, T1053 Scheduled Task/Job and T1546.004 Unix Shell Configuration Modification. On Windows this is service, Run key and scheduled task telemetry, for example from the Sysmon Guide; on Linux, systemd units, cron and shell profiles.
3. Add integrity baselines for system files. D3-FIM and D3-SFA on authentication databases, sudoers, SSH configuration, web roots and system binaries, then D3-SBV for service executables. See the File Integrity Monitoring Guide for tooling and noise control.
4. Bring firmware into scope. D3-SFV through measured boot and attestation on servers and laptops, then D3-PFV for network cards, storage controllers and BMCs where vendors publish reference hashes. These address T1542.001 System Firmware, T1542.002 Component Firmware and T1542.003 Bootkit. See the Firmware and Boot Security Guide.
5. Add uptime and reboot correlation. D3-PUM is cheap and catches unexpected restarts that often accompany firmware, kernel or controller changes.
6. OT last but not least. For industrial sites D3-OMM, D3-APM, D3-AEM and D3-OPM usually come from the OT monitoring platform and the historian, owned jointly with engineering. Scan time and mode alarms need engineering agreement on what normal looks like.
7. Treat D3-FBA and D3-FEMC as specialist. Both depend on firmware level instrumentation that few organisations can build; adopt them where a device vendor offers them rather than as a project of your own.

Testing and rollback

• Baseline in report mode: collect two patch cycles of integrity and autorun data before alerting, so you learn what legitimate updates change.
• Tie change to change records: suppress alerts that match an approved patch window or package manager transaction, and alert on everything else.
• Emulate safely: in a test environment, create a benign scheduled task, systemd unit and shell profile line, stop the agent service, and confirm each produces an alert within your target time.
• Rollback: monitoring rarely breaks production, but kernel level agents and attestation policies can. Keep a documented way to revert agent versions and to move attestation from enforce to report.

Small versus large organisations

• Small: an EDR platform plus OS native logging will deliver D3-EHB, D3-SDM, D3-SICA, D3-SJA and much of D3-FIM. Add firmware update hygiene rather than firmware verification tooling.
• Large and regulated: add dedicated FIM for regulated systems, attestation for server fleets, firmware inventory for network and storage hardware, and a reference hash store owned outside the endpoint team.
• OT operators: prioritise D3-OMM and D3-APM with the OT Asset Visibility Guide before host agents, which many controllers cannot run.

ATT&CK techniques D3FEND relates to Platform Monitoring

D3FEND relates defensive and offensive techniques through the digital artefacts both touch. For D3-PM the site lists offensive techniques by name across credential access, execution, persistence, privilege escalation, stealth and defence impairment, collection, lateral movement, discovery and impact, and labels them "inferred, experimental". The table is our selection of the entries most useful for testing, with ATT&CK v20 IDs. Where D3FEND still uses the older Impair Defenses grouping, the v20 successor is shown.

For depth on the persistence techniques see MITRE ATT&CK T1542 Pre-OS Boot, T1547 Boot or Logon Autostart Execution Defensive Guide and T1053 Scheduled Task/Job Defensive Guide.

Where identity fits

Several D3-PM children watch artefacts that are identity stores or credential holders. System File Analysis covers authentication databases, and scheduled jobs and services usually run as service accounts with stored credentials. When D3-SJA or D3-SICA finds a new job or service, record the account it runs as, and treat a new job running as a privileged service account as higher severity. See How to Find credentials in cron jobs and scheduled tasks.

Detection and measurement

Useful detections across the family: an agent or log forwarder that stops reporting outside a maintenance window; a new service, scheduled task or autorun entry created outside change control; a changed hash on a monitored system binary that no package transaction explains; a failed measured boot or attestation result; an OT controller switched to Program mode outside an engineering window; an unexpected reboot followed by a firmware or kernel version change.

Metrics we suggest at NHI Mgmt Group (example targets are illustrations, not standards):

1. Child coverage: share of the 21 D3-PM techniques with a named data source and owner.
2. Heartbeat coverage: share of managed endpoints and servers reporting an agent heartbeat in the last 24 hours (example target 98 per cent).
3. Silent endpoint time: median time from last heartbeat to alert for endpoints that go quiet.
4. Integrity baseline coverage: share of tier 0 and regulated servers with FIM on a defined file set.
5. Firmware verification coverage: share of server fleet with attestation or firmware hash verification.
6. Unexplained change rate: integrity or autorun alerts per week not matched to a change record, trended down as tuning matures.

Framework mapping

Common failure patterns

• Baselines stored on the monitored host. An attacker with root can update the reference hash as easily as the file. Keep reference values off host.
• Alert fatigue from patching. FIM that alerts on every update gets muted; correlate with package and change records instead.
• No alert on silence. Agents are stopped or blinded first (see the Bring Your Own Vulnerable Driver and EDR Killers Guide); without D3-EHB the gap looks like a quiet day.
• Firmware out of scope. Endpoint teams own the OS, hardware teams own BIOS and BMCs, and nobody verifies firmware.
• OT monitoring without engineering input. Scan time and mode alarms set by security alone either flood or miss.
• Counting inferred mappings as coverage. A D3FEND link from D3-PM to an ATT&CK technique is a test idea, not evidence of detection.

Practitioner checklist

• Map each of the 21 D3-PM techniques to a data source, owner and alert route.
• Alert on missing heartbeats and stopped security services before building anything else.
• Collect autoruns, services, scheduled jobs and shell profiles from every server and endpoint.
• Run FIM on authentication stores, privileged configuration, web roots and system binaries.
• Store integrity and firmware reference values off the monitored host.
• Add measured boot or firmware verification for server fleets and network hardware.
• Agree OT mode and scan time alarms with engineering.
• Emulate the mapped ATT&CK behaviours in test and record time to alert.
• Report child coverage, heartbeat coverage and unexplained change rate quarterly.

Standards and references

• MITRE D3FEND: Platform Monitoring
• MITRE D3FEND: Operating System Monitoring
• MITRE D3FEND: Firmware Verification
• MITRE ATT&CK: Pre-OS Boot
• MITRE ATT&CK: Disable or Modify Tools
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND Guide · File Integrity Monitoring Guide · Firmware and Boot Security Guide · EDR Guide · MITRE D3FEND Access Mediation Implementation Guide