DC0110: Asset Inventory
This includes sources of current and expected devices on the network, including the manufacturer, model, and necessary identifiers (e.g., IP and hardware addresses)
Analyst context for executives and security teams
Asset Inventory is the evidence base for knowing which devices are expected on an ICS network and how to identify them. For leaders, its value is less about “having a list” and more about enabling defensible decisions during outages, investigations, audits, and change-control reviews: teams cannot reliably spot unknown equipment, validate exposure, or prioritize response if they do not know the expected manufacturer, model, IP address, and hardware address of assets.
Executive priority
Treat this as a foundational control for operational resilience and cyber-physical risk management. An accurate inventory supports incident scoping, vulnerability prioritization, compliance evidence, and change governance. The key leadership question is whether the organization can quickly prove what devices should exist in the ICS environment, which identifiers are authoritative, and who owns keeping that record current.
Technical view
Because ATT&CK provides no detection logic or linked techniques for this data component, SOC and IR teams should use it as a validation requirement rather than a standalone detection. Confirm that current and expected device records include manufacturer, model, IP addresses, and hardware addresses, and that those records can be compared against observed network activity or investigation findings. Coverage gaps usually appear when inventories are stale, incomplete, manually maintained, or disconnected from incident response workflows.
Likely telemetry
- Authoritative lists of current and expected ICS network devices
- Manufacturer and model information for inventoried devices
- IP address records tied to expected assets
- Hardware address records tied to expected assets
- Change records or operational sources used to keep inventory current
Detection direction
- Validate whether SOC and IR teams can distinguish expected from unknown devices using inventory identifiers.
- Tune investigative workflows to compare observed network identifiers against the approved inventory before escalating or closing an event.
- Account for false positives caused by legitimate maintenance, replacement, readdressing, or documentation lag.
- Identify blind spots where devices lack manufacturer, model, IP, or hardware address fields, because those gaps weaken triage and audit confidence.
- Do not assume ATT&CK-defined detection coverage exists for this object; no official detection text or relationship context was supplied.
Mitigation priorities
- Establish an authoritative asset inventory source for ICS devices and assign ownership for updates.
- Require minimum fields aligned to the ATT&CK description: manufacturer, model, IP address, and hardware address or equivalent necessary identifiers.
- Integrate inventory review into change management, incident response, and vulnerability prioritization processes.
- Periodically reconcile expected devices against observed environment data to find stale records or unmanaged assets.
- Preserve inventory history where possible to support audits and incident timelines.
Analyst notes and limits
This is a data component, not a technique or mitigation. Its defensive value is enabling other security and operational decisions: scoping incidents, validating expected devices, supporting compliance evidence, and reducing uncertainty in ICS environments. The supplied object has no platforms, tactics, aliases, labels, or relationship context, so analysis should remain inventory- and evidence-focused.
The official ATT&CK object provides a brief description only and no official detection guidance. No relationships were supplied, so this take cannot tie Asset Inventory to specific ATT&CK techniques, adversary behaviors, platforms, or detections. Local environment architecture and inventory governance must determine practical implementation details.
Asset Inventory
This includes sources of current and expected devices on the network, including the manufacturer, model, and necessary identifiers (e.g., IP and hardware addresses)
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | e3369220bd78… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0110Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.