Most intrusions change a setting somewhere, a firewall rule, an audit policy, a Run key, a cloud logging switch, and without a record of what the setting was supposed to be nobody can tell the change from normal administration. MITRE D3FEND names the countermeasure that provides that record Configuration Inventory (D3-CI): "Configuration inventory identifies and records the configuration of software and hardware and their components throughout the organization." It sits in the Model tactic as a child of Asset Inventory. This guide covers what to record, how to collect it on Windows, Linux, network devices and cloud platforms, how to keep it current, how it feeds hardening and detection, and how to tell whether it works. It is for platform engineers, configuration management owners and detection engineers. The family overview is in the MITRE D3FEND Asset Inventory Implementation Guide.
Key takeaways
- It records actual state, not intended state. D3-CI captures how things are configured; a baseline says how they should be. Drift is the difference, and you need both to see it.
- D3FEND names the collection methods. Its knowledge base describes retrieving configuration through SNMP MIB records, WBEM CIM records, other protocols or custom scripts into a repository, typically a CMDB.
- Security-relevant settings first. Audit and logging policy, firewall state, autostart locations, authentication settings and cloud logging switches are the settings attackers change most, and D3FEND's inferred ATT&CK links point at exactly those.
- History matters as much as the snapshot. Cloud configuration services keep change history for limited periods, so export it if investigations need longer look-back.
- Configuration holds identities. Service account logon settings, connection strings and cloud role bindings live in configuration, so the inventory doubles as a map of where machine credentials are used.
D3-CI at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CI (d3f:ConfigurationInventory) |
| Tactic | Model |
| Parent technique | Asset Inventory (D3-AI) |
| D3FEND relation | inventories Configuration Resource ("a resource used to configure a system including software and hardware") |
| Collection methods named by D3FEND | SNMP (MIB records), WBEM (CIM records), other protocols, custom scripts; stored in a Configuration Management Database (CMDB) |
| D3FEND references | DMTF Web-Based Enterprise Management; Microsoft Windows Management Infrastructure; Microsoft Windows Management Instrumentation |
| Typical outputs | Per asset: setting name, current value, source, collection time, baseline value, owner, change history |
| Main limitation | A record, not a control: it shows a change only if someone compares it with a baseline and acts |
What to record
A full configuration dump of every asset is neither possible nor useful. Start with the settings that change security outcomes and that attackers are known to alter.
| Area | Example settings to record | Why it matters |
|---|---|---|
| Logging and audit | Windows audit policy and event log service state, Linux audit rules, cloud audit log and flow log status | Disabling logging is a standard first step after access |
| Host firewall and network | Host firewall profile state and rules, cloud security groups and firewall rules, SNMP community and version settings | Opened ports and widened rules enable lateral movement and exfiltration |
| Autostart and execution | Registry Run keys and startup folders, services and their binary paths, scheduled tasks, cron, RC scripts | Persistence lives here |
| Authentication | Password filter and security support provider registrations, conditional access policies, local administrator membership, sudoers | Changes here capture credentials or bypass controls |
| Security tooling | EDR and antivirus state, exclusions, tamper protection setting | Exclusions and disabled agents hide later activity |
| Cloud compute | Instance metadata service settings, instance profiles and attached roles, snapshot and image settings | Metadata credentials and new instances are common cloud abuse paths |
| Application and service | Service account used by each service, connection strings (recorded as a reference to the secret, never the secret), TLS settings | Shows which machine identities each system depends on |
Collection methods by platform
| Platform | Collection mechanism | Notes |
|---|---|---|
| Windows | WMI and its successor interface Windows Management Infrastructure (MI), queried from PowerShell or a management agent; Group Policy and device management reports | WMI is Microsoft's management data infrastructure; Microsoft describes MI as fully compatible with previous WMI versions |
| Cross-platform hosts | Endpoint agents and osquery, which exposes the operating system as SQL tables on Windows, macOS and Linux, with the osqueryd daemon running scheduled queries and logging state changes | Good for registry, services, packages and startup items in one query language |
| Standards-based management | DMTF WBEM: CIM-modelled resources accessed through CIM-XML over HTTP (DSP0200) or WS-Management (DSP0226) | Common for servers, storage and baseboard management controllers |
| Network devices | SNMP MIB reads, ideally SNMPv3 (RFC 3411 architecture, which adds message security and access control); configuration file backup over SSH or vendor APIs | Prefer read-only SNMPv3 credentials; SNMPv1 and v2c community strings travel in clear text |
| Cloud platforms (alphabetical) | AWS Config records resource configurations, relationships and history and evaluates them with rules; Azure Resource Graph queries resource properties with KQL and shows the last 14 days of changes; Google Cloud Asset Inventory keeps up to 35 days of create, update and delete history and supports export to BigQuery or Cloud Storage and change feeds through Pub/Sub | All three are eventually consistent; export history to long-term storage if you need more than the native window |
| Containers and Kubernetes | Declarative manifests in source control plus the live object state from the API server | Compare the two: live edits that bypass the pipeline are drift |
Decision guidance: small organisations usually get most of D3-CI from device management reports, the cloud provider's native configuration service and network device configuration backups. Larger estates benefit from one normalised store, a CMDB or a security data lake, so that configuration, software and vulnerability records share asset IDs. Whichever you choose, collect with read-only accounts and keep collection credentials separate from the accounts that change configuration.
Where identity fits
Configuration is where machine identities are wired in: the account a Windows service logs on as, the key in an application's settings, the role attached to a cloud instance, the service account mounted into a pod. Recording those references turns D3-CI into an NHI dependency map, which answers "what breaks if we rotate this credential" and "which systems use this compromised account". Record the reference and the secret store location, never the secret value. The collectors themselves (WMI remote accounts, SNMPv3 users, cloud read roles) are non-human identities with broad read access and need the same vaulting, scoping and monitoring as any privileged account. See the NHI Discovery Guide.
How to build it
- Define the security-relevant setting list. Start from the table above and your hardening standard, for example CIS Benchmarks, so each recorded setting has an expected value. See the CIS Benchmarks Guide.
- Pick one collector per platform. Avoid three tools reporting different values for the same setting. Record collection time with every value.
- Turn on native cloud recording. Enable the provider's configuration recording in every account, subscription or project and region in use, and aggregate it centrally.
- Pilot and compare. Collect from a small group of assets, check values manually on a sample and fix parsing errors before scaling.
- Attach baselines. Store expected values beside recorded values and compute drift. Approved changes update the baseline through change control; everything else is drift to investigate.
- Retain history. Keep configuration history long enough for your incident investigations, and longer than the native 14 or 35 day windows where those apply.
- Roll back safely. D3-CI only reads. If a collector causes load or errors on a device class, pause that collector and fall back to configuration backups while it is fixed; never grant collectors write access to make collection easier.
How it feeds other countermeasures
- Hardening: drift reports feed configuration hardening work. See D3-ACH Application Configuration Hardening and the Configuration Drift and Baseline Enforcement Guide.
- Vulnerability enumeration: many findings depend on configuration, not version. See D3-AVE Asset Vulnerability Enumeration.
- Detection: a change to a monitored setting (audit policy, firewall state, Run key, cloud logging) is a detection signal in its own right, and the inventory supplies the "was this expected" context for triage.
- Incident response: configuration history shows when a setting changed and what it was before, which is evidence and a restore point.
ATT&CK techniques D3FEND relates to D3-CI
Relationship type: inferred only. D3FEND derives these links because the techniques modify configuration resources that D3-CI inventories (D3FEND 1.6.0, checked November 2026). They show which recorded settings an attacker would change; D3-CI itself does not detect them unless changes are compared and alerted. D3FEND still lists six Impair Defenses sub-techniques that ATT&CK v20 has revoked; the table shows their v20 successors. All IDs were checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques (configuration they change) |
|---|---|
| Defense Impairment | T1685.001 Disable or Modify Windows Event Log, T1685.002 Disable or Modify Cloud Log, T1686 Disable or Modify System Firewall, T1686.001 Cloud Firewall, T1688 Safe Mode Boot, T1690 Prevent Command History Logging (v20 successors of the revoked IDs D3FEND lists); T1578.002 Create Cloud Instance, T1578.003 Delete Cloud Instance, T1578.004 Revert Cloud Instance, T1578.005 Modify Cloud Compute Configurations; T1556.002 Password Filter DLL, T1556.009 Conditional Access Policies; T1553.003 SIP and Trust Provider Hijacking |
| Stealth | T1564.008 Email Hiding Rules, T1218.002 Control Panel, T1574.011 Services Registry Permissions Weakness, T1574.012 COR_PROFILER, T1134.005 SID-History Injection |
| Persistence and Privilege Escalation | T1037.004 RC Scripts, T1037.005 Startup Items; T1547.001 Registry Run Keys / Startup Folder, T1547.002 Authentication Package, T1547.003 Time Providers, T1547.004 Winlogon Helper DLL, T1547.005 Security Support Provider, T1547.010 Port Monitors; T1546.001 Change Default File Association, T1546.002 Screensaver, T1546.007 Netsh Helper DLL, T1546.008 Accessibility Features, T1546.009 AppCert DLLs, T1546.010 AppInit DLLs, T1546.011 Application Shimming, T1546.014 Emond; T1137.001 Office Template Macros, T1137.002 Office Test, T1137.004 Outlook Home Page, T1137.005 Outlook Rules |
| Privilege Escalation | T1548.001 Setuid and Setgid, T1548.002 Bypass User Account Control, T1548.005 Temporary Elevated Cloud Access |
| Credential Access | T1552.005 Cloud Instance Metadata API, T1552.006 Group Policy Preferences |
| Discovery and Collection | T1518.001 Security Software Discovery, T1114.003 Email Forwarding Rule |
| Impact | T1490 Inhibit System Recovery |
Read the table as a prioritised setting list: if a setting appears here and is not in your inventory, add it. Detection content for several rows is in the T1047 Windows Management Instrumentation Defensive Guide and related ATT&CK pages on this site.
How to verify it works
- Planted change test: on a test host and a test cloud account, make an authorised change to three monitored settings (for example an audit policy, a firewall rule and a logging switch) and confirm each appears in the inventory and raises drift within the expected collection interval.
- Sample accuracy check: each quarter, compare recorded values with live values on a random sample of assets.
- Coverage reconciliation: compare assets with a recent configuration record against the network node and cloud resource inventories.
- History check: confirm you can answer "what was this setting 60 days ago" for a cloud resource, which tests export beyond native retention.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | What it shows |
|---|---|---|
| Assets with a configuration record newer than 24 hours | Above 95% of managed assets | Collection coverage and freshness |
| Security-relevant settings with a defined baseline value | 100% of the agreed setting list | Whether drift can be computed at all |
| Unapproved drift items older than 30 days | Falling month on month | Whether drift is acted on |
| Planted change tests detected | 100% | End-to-end pipeline health |
| Services with a recorded service identity | Rising quarter on quarter | Usefulness as an NHI dependency map |
Common failure patterns
- A CMDB of owners and models with no settings: the record says what an asset is, but not how it is configured, so it cannot show drift.
- Values without timestamps: a setting with no collection time cannot be trusted during an incident.
- Native history assumed to be enough: cloud change history ages out after 14 or 35 days on some platforms, often before an intrusion is discovered.
- Collectors with write rights: a management account that can change every host is a single point of compromise.
- Secrets captured as configuration: scripts that dump application settings wholesale copy passwords and keys into the CMDB, creating a new place to steal them from.
- SNMP v1 or v2c in production: community strings sent in clear text across the network for convenience of collection.
Framework mapping
| Framework | Reference | Relevance to D3-CI |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-2, CM-2(2), CM-2(3) | Baseline configuration, automated currency of the baseline, retention of previous configurations |
| NIST SP 800-53 Rev. 5 | CM-6, CM-6(1) | Configuration settings and their automated management and verification |
| NIST SP 800-53 Rev. 5 | CM-8, CM-8(2) | System component inventory and its automated maintenance |
| NIST SP 800-53 Rev. 5 | CM-3 | Configuration change control, which separates approved change from drift |
| NIST SP 800-128 | Security-focused configuration management | The process D3-CI supports |
| NIST CSF 2.0 | PR.PS-01, ID.AM-08 | Configuration management practices; life cycle management of systems and software |
| CIS Controls v8.1 | Control 4 Secure Configuration of Enterprise Assets and Software | Secure configuration that D3-CI records and checks |
See the NIST SP 800-128 Security-Focused Configuration Management Guide and the CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide.
Practitioner checklist
- Agree a list of security-relevant settings per platform, each with an expected value.
- Collect with read-only, vaulted, monitored service identities.
- Use SNMPv3 for network device reads.
- Enable cloud configuration recording in every account, subscription, project and region, and aggregate centrally.
- Export configuration history beyond native retention windows.
- Record service identities and secret references, never secret values.
- Compute drift against baselines and route it to owners.
- Run a planted change test each quarter and record the result.
Standards and references
- MITRE D3FEND: Configuration Inventory (D3-CI)
- NIST: SP 800-128 Guide for Security-Focused Configuration Management of Information Systems
- DMTF: Web-Based Enterprise Management (WBEM)
- IETF: RFC 3411 An Architecture for Describing SNMP Management Frameworks
- Microsoft Learn: Windows Management Instrumentation
- AWS: What Is AWS Config?
- Microsoft Learn: Azure Resource Graph overview
- Google Cloud: Cloud Asset Inventory overview
- osquery: documentation
Related NHI Mgmt Group resources: MITRE D3FEND Asset Inventory Implementation Guide · Asset Inventory and CMDB Security Guide · Configuration Drift and Baseline Enforcement Guide · MITRE D3FEND Guide