DET0910: Detection of Block Communications
DET0910 is an ICS ATT&CK detection strategy for identifying behavior related to Block Communications (T1695). The business issue is not just network downti...
Analyst context for executives and security teams
DET0910 is an ICS ATT&CK detection strategy for identifying behavior related to Block Communications (T1695). The business issue is not just network downtime: in operational technology, blocked reporting or command messages can reduce operator visibility, delay control actions, disrupt operations, and create cyber-physical risk. Because MITRE provides no detailed detection text for this strategy, organizations should treat it as a prompt to verify whether critical OT communications paths are observable and whether loss of communications can be investigated quickly.
Executive priority
Prioritize this where business operations depend on continuous OT command and reporting paths. Leaders should ask which industrial processes lose visibility or control if serial, Ethernet, Wi-Fi, cellular, or satellite communications are interrupted; whether the SOC and operations teams share evidence during outages; and whether incident response playbooks distinguish malicious blocking from routine network, carrier, maintenance, or equipment failures. This supports resilience planning, audit evidence for monitoring coverage, and cyber-physical risk governance.
Technical view
This object is a detection strategy in the ICS domain and is related to technique T1695, Block Communications. No platforms, tactics, official description, or official detection logic are specified for DET0910, so SOC and OT teams should validate coverage against the related behavior: reporting messages and command messages failing to reach intended devices across OT communications media. Detection engineering should focus on correlation between communication path availability, device or gateway status, missed polling/reporting, command delivery failures, and process/operator alarms rather than relying on a single log source.
Likely telemetry
- OT network flow or session metadata for critical Ethernet paths
- Serial gateway, COM server, or protocol converter status and error logs where available
- Wireless, cellular, or satellite modem/link health and connectivity events where used in OT communications
- Controller, RTU, PLC, HMI, engineering workstation, or supervisory system logs showing failed communications, missed polling, or command failures
- Historian, alarm, or SCADA records indicating loss of reporting from field devices
Detection direction
- Map critical OT command and reporting paths first; detection value depends on knowing which communications must remain available for safe and reliable operations.
- Tune alerts around loss of expected communications, repeated failed command delivery, missing telemetry, and simultaneous visibility gaps across related devices or network segments.
- Correlate cyber telemetry with process alarms and operator observations to avoid treating every outage as malicious while still escalating unexplained disruptions quickly.
- Account for blind spots in non-traditional or less centrally logged media such as serial links, Wi-Fi, cellular, and satellite communications.
- Use maintenance schedules and known network/provider issues as false-positive suppressors, but require documentation so malicious blocking is not dismissed as routine downtime.
Mitigation priorities
- Inventory and classify OT communications paths that carry command or reporting messages for critical processes.
- Ensure monitoring and logging exist for the most important paths, including gateways and non-Ethernet communications where feasible.
- Define joint SOC, OT operations, and incident response procedures for communication-loss events, including escalation criteria and evidence preservation.
- Test whether teams can detect, triage, and explain loss of communications without relying on a single device or single monitoring layer.
- Use findings to prioritize resilience improvements, alternate visibility, and operational contingency planning for processes with cyber-physical consequences.
Analyst notes and limits
MITRE’s supplied DET0910 fields are sparse: the object has no official description, no official detection text, and no specified platforms or tactics. The practical guidance above is derived from the object’s ICS domain and its relationship to T1695 Block Communications, whose description notes that OT communications may use serial COM, Ethernet, Wi-Fi, cellular, and satellite media and that blocked messages can disrupt operations and cause cyber-physical impacts.
This summary does not assert active exploitation, actor attribution, specific affected platforms, or guaranteed detection coverage. Local architecture, communications media, logging availability, process criticality, and maintenance practices are required to turn this detection strategy into deployable analytics or response procedures.
Detection of Block Communications
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 | T1695 | Block Communications | This object detects Block Communications. |
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 | 23848d8801b4… |
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 DET0910Open 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.