DC0107: Process History/Live Data
This includes any data stores that maintain historical or real-time events and telemetry recorded from various sensors or devices
Analyst context for executives and security teams
Process History/Live Data is the evidence source for understanding what sensors and devices reported over time or in real time in an ICS environment. For leaders, its value is not just security monitoring: it supports operational resilience, incident reconstruction, safety assurance, and audit evidence when an event affects industrial processes.
Executive priority
Treat this data component as a business-critical visibility dependency. Executives and risk owners should ask whether historical and live process telemetry is retained, protected, and available quickly enough to support incident response, compliance inquiries, and operational decision-making. Gaps here can leave teams unable to distinguish a cyber event from process instability, equipment failure, or normal operational variance.
Technical view
Because ATT&CK provides no specific detection logic, platforms, tactics, or relationships for this component, SOC and IR teams should validate the basics: which process historians, event stores, sensor telemetry repositories, and real-time monitoring feeds exist; what they record; how long data is retained; who can access or modify it; and whether timestamps, device identifiers, and event context are reliable enough for investigation.
Likely telemetry
- Historical sensor and device telemetry
- Real-time process events
- Process historian records or equivalent operational data stores
- Device or sensor event records
- Timestamps and source identifiers associated with recorded process events
Detection direction
- Inventory the systems that store historical or live process telemetry and confirm they are accessible to authorized security and response teams.
- Validate retention periods against incident response and compliance needs, not only operational needs.
- Check whether telemetry has sufficient time synchronization and device context to support event correlation.
- Identify blind spots where critical sensors or devices are not recorded, are recorded only locally, or are unavailable to the SOC/IR workflow.
- Because no official detection guidance is supplied, tune detection use cases using local process baselines and engineering input to reduce false positives from normal operational changes.
Mitigation priorities
- Prioritize governance for retention, access control, and integrity of process history/live data stores.
- Ensure operational telemetry sources needed for incident response are documented and included in response playbooks.
- Protect availability of these data stores so investigations are not blocked during operational disruption.
- Coordinate security, engineering, and compliance teams on what telemetry must be preserved as evidence.
- Periodically test whether responders can retrieve and interpret relevant historical and live process data during tabletop or incident response exercises.
Analyst notes and limits
This is an ATT&CK for ICS data component, not a technique. Its practical value is as a visibility and evidence source for monitoring, investigation, and operational context. The absence of supplied relationships means this take should be used as a coverage-planning prompt rather than as behavior-specific detection content.
The official object provides only a short description and no detection text, platforms, tactics, aliases, or relationship context. Local architecture, sensor coverage, historian configuration, retention policy, and operational process knowledge are required to assess real defensive coverage.
Process History/Live Data
This includes any data stores that maintain historical or real-time events and telemetry recorded from various sensors or devices
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.1 | Current bundle | 8c4fb34a884b… |
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 DC0107Open 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.