DET0727: Detection of Monitor Process State
This detection strategy is tied to identifying activity associated with monitoring industrial process state. For an executive or security leader, the signi...
Analyst context for executives and security teams
This detection strategy is tied to identifying activity associated with monitoring industrial process state. For an executive or security leader, the significance is that process-state visibility can help an adversary understand how an industrial operation behaves and potentially time later actions around real operating conditions. Because the ATT&CK object provides no official detection logic or platform scope, the business value is in using it as a coverage question: can the organization see who or what is querying, reading, or collecting process-state information such as OPC tags, historian data, PLC block information, or relevant network traffic?
Executive priority
Prioritize this as an ICS operational resilience and incident-readiness issue rather than a generic IT alert. Leaders should ask whether SOC, OT engineering, and incident response teams have agreed on what normal process-state monitoring looks like, what systems are authorized to collect it, and what evidence would be available during an investigation. This is especially relevant for audit and risk discussions where the organization must show that cyber monitoring is aligned to safety, uptime, and physical-process awareness.
Technical view
The only supplied relationship is that DET0727 detects T0801, Monitor Process State, in the ICS ATT&CK domain. Defensive validation should therefore focus on whether telemetry exists for access to process-state sources named in the related technique: OPC tags, historian data, PLC block information, and network traffic. SOC and detection engineering teams should avoid assuming platform coverage because no platforms or official detection details are provided. Instead, they should map local ICS data flows, identify authorized consumers of process-state information, and look for deviations in source, destination, query volume, timing, or access patterns.
Likely telemetry
- OPC access or query logs where available
- Historian access logs and read/query activity
- PLC engineering or controller access records where PLC block information is exposed
- ICS network traffic metadata related to process-state reads or polling
- Asset inventory and approved data-flow baselines for systems that legitimately monitor process state
Detection direction
- Validate that the organization can distinguish normal process monitoring from unusual collection of process-state information.
- Baseline authorized systems and users that read OPC tags, historian data, PLC block information, or related network traffic.
- Tune detections for changes in source host, account, destination, frequency, volume, or timing of process-state reads, while accounting for legitimate engineering, maintenance, and operations activity.
- Correlate process-state access with asset role and approved OT data flows to reduce false positives.
- Document blind spots explicitly, especially where historians, OPC infrastructure, PLC access, or ICS network traffic are not logged or not forwarded to the SOC.
Mitigation priorities
- Start by inventorying systems and services authorized to monitor process state.
- Restrict access to process-state data sources based on operational need and approved engineering workflows.
- Ensure logging is enabled and retained for key process-state sources where operationally safe and supported.
- Establish normal baselines with OT engineering input before creating high-severity alerts.
- Integrate OT-specific triage procedures into incident response so unusual process-state monitoring can be assessed without disrupting operations.
Analyst notes and limits
This object is a detection strategy with external ID DET0727 and is related to ICS technique T0801, Monitor Process State. The ATT&CK-supplied relationship provides the main analytic context: adversaries may gather physical process-state information from sources such as OPC tags, historian data, PLC block information, or network traffic. Because there is no official detection text, the practical recommendation is to use this as a validation and coverage-mapping item rather than as a ready-made analytic.
The supplied object has no official description, no official detection guidance, no platforms, no tactics, and no labels. Any environment-specific detection logic, severity, alert thresholds, or tooling assumptions must be derived from local ICS architecture, logging capabilities, and OT operating practices. This summary does not assert active exploitation, attribution, or guaranteed detection coverage.
Detection of Monitor Process State
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0801 | Monitor Process State | This object detects Monitor Process State. |
All related ATT&CK context
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 | 1.0 | Current bundle | 631ec32fa677… |
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 DET0727Open 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.