DET0789: Detection of Block Reporting Message
DET0789 is a detection strategy for identifying attempts to block industrial control system reporting messages. In practical terms, this matters because re...
Analyst context for executives and security teams
DET0789 is a detection strategy for identifying attempts to block industrial control system reporting messages. In practical terms, this matters because reporting messages carry telemetry about equipment and process state; if they do not reach operators or monitoring systems, the organization may lose visibility into unsafe or abnormal conditions. The business issue is not just missing data—it is delayed operator awareness and potentially inhibited response in a physical process environment.
Executive priority
Security and operations leaders should treat this as an operational resilience and safety-visibility concern. The key question is whether the organization can prove that critical process telemetry is reaching its intended destinations reliably, and whether loss, delay, or suppression of reporting messages would be noticed quickly enough to support incident response and operational decision-making. This is also relevant to audit and compliance evidence where monitoring, alarm integrity, or control-room visibility must be demonstrated.
Technical view
ATT&CK identifies this detection strategy as detecting ICS technique T1691.002, Reporting Message, where an adversary may prevent telemetry messages from reaching the intended target in order to hide activity from an operator. Because the ATT&CK object does not provide official detection logic, SOC, OT monitoring, and incident response teams should validate environment-specific indicators of message loss, interruption, or inconsistent process visibility across trusted data sources. Detection design should focus on whether expected telemetry flows, I/O values, reporting intervals, and operator-facing views remain consistent with the actual process and with other independent observations.
Likely telemetry
- ICS network traffic showing reporting-message flows between field/control assets and intended monitoring or operator systems
- Historian, HMI, SCADA, or other operator-view logs showing missing, delayed, stale, or inconsistent telemetry values
- Device or controller logs where available that indicate reporting state, communication failures, or data publication issues
- Alarm and event records showing communication loss, bad quality values, or inhibited visibility
- Independent process observations or redundant telemetry that can be compared against operator-facing reporting data
Detection direction
- Validate that critical reporting paths have known baselines for expected message frequency, source, destination, and data quality.
- Look for gaps, sustained stale values, or asymmetric visibility where one system sees process changes but the intended operator or monitoring target does not.
- Tune detections to distinguish malicious blocking from common operational causes such as maintenance, network faults, device outages, configuration changes, or planned communication interruptions.
- Correlate reporting-message anomalies with process changes, operator alarms, network events, and any concurrent control activity to avoid treating isolated packet loss as conclusive evidence.
- Identify blind spots where SOC tooling lacks access to OT network telemetry, historian/HMI quality indicators, or independent process-state validation.
Mitigation priorities
- Prioritize visibility of critical reporting paths and confirm that loss of reporting messages generates actionable alerts for operators and responders.
- Maintain redundant or independent telemetry sources for high-consequence processes where feasible, so blocked reporting to one target does not eliminate situational awareness.
- Document normal reporting intervals, expected data quality states, and approved maintenance windows to support investigation and reduce false positives.
- Integrate OT monitoring, operations procedures, and incident response playbooks so telemetry suppression is handled as both a cyber and operational risk.
- Use findings from detection validation to prioritize segmentation, access control, monitoring coverage, and resilience improvements around the most critical reporting flows.
Analyst notes and limits
This take is based on the ATT&CK detection strategy DET0789 and its relationship to ICS technique T1691.002, Reporting Message. The decision value is strongest for environments where reporting messages inform operator awareness, alarms, or response functions for physical processes.
The supplied ATT&CK object has no official description, detection text, tactics, platforms, or aliases. Recommendations are therefore conservative and derived from the related technique description and the detection-strategy name. Local architecture, protocols, asset roles, and monitoring sources are required to turn this into specific analytics or control requirements.
Detection of Block Reporting Message
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 | T1691.002 | Reporting Message Sub-technique | This object detects Reporting Message. |
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 | 200ff80a9c57… |
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 DET0789Open 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.