DET0911: Detection of Block Ethernet
DET0911 is a detection strategy for identifying attempts to block Ethernet communications in ICS environments. The business issue is operational continuity...
Analyst context for executives and security teams
DET0911 is a detection strategy for identifying attempts to block Ethernet communications in ICS environments. The business issue is operational continuity: if Ethernet traffic between IT, OT, control systems, and devices is interrupted, instructions, configuration messages, commands, or reporting may not reach the systems that need them. For leaders, this is less about a single alert and more about proving the organization can notice communications loss quickly enough to support safe operations and incident decisions.
Executive priority
Prioritize this as an operational resilience and incident readiness concern for environments where Ethernet connectivity supports control, monitoring, configuration, or reporting. Executives should ask whether OT network outages, disabled interfaces, or stopped communication services are visible to the SOC and operations teams, whether response ownership is clear between IT and OT, and whether evidence exists for audits or post-incident review. Because the ATT&CK object provides no official detection logic or platform scope, local architecture and telemetry availability should drive investment decisions.
Technical view
This detection strategy is associated with detecting ATT&CK for ICS technique T1695.002, Ethernet. SOC, detection engineering, and IR teams should validate whether they can observe loss or blocking of Ethernet communications that could prevent instructions, configuration messages, command traffic, or reporting from reaching target systems and devices. Useful validation should focus on network availability signals, interface state changes, service stoppage indicators where relevant, and gaps between expected and observed communications across IT/OT paths. Since no official detection text, tactics, or platforms are specified, teams should map this to their own ICS network segments, critical devices, and normal communication patterns before writing or tuning detections.
Likely telemetry
- OT/ICS network monitoring showing expected versus missing Ethernet communications
- Switch, router, firewall, or network infrastructure logs indicating link state, port status, blocked traffic, or communication failures
- Endpoint or device logs showing network interface disablement or loss of connectivity where available
- Service status or process telemetry for communication services where available
- Control system, engineering workstation, historian, HMI, or device reporting gaps that indicate command, configuration, or telemetry interruption
Detection direction
- Baseline expected Ethernet communication paths between IT, OT, control systems, and devices, then alert on unexpected loss, blocking, or sustained absence of required traffic.
- Correlate network infrastructure events with endpoint/device state changes and OT application reporting gaps to reduce false positives from maintenance, planned outages, or network changes.
- Validate that detections distinguish maliciously relevant communication blocking from routine link flaps, device reboots, segmentation changes, or scheduled service work.
- Ensure SOC runbooks include OT operator confirmation, because loss of reporting may be an operations event, a security event, or both.
- Use the relationship to T1695.002 as the detection focus; the ATT&CK object itself does not provide official analytics, platforms, or tactics.
Mitigation priorities
- Identify the Ethernet communication paths that are critical to safe and reliable operations, including command, configuration, and reporting flows.
- Ensure monitoring exists at network, device, and operational application layers so communication loss is not dependent on a single telemetry source.
- Define joint IT/OT escalation procedures for suspected communication blocking, including how to verify maintenance versus unauthorized disruption.
- Maintain change control and evidence for network interface, service, and infrastructure configuration changes that could affect Ethernet communications.
- Test incident response procedures for communication loss scenarios in a safe, non-disruptive manner appropriate to the ICS environment.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy in the ICS domain with external ID DET0911 and a relationship indicating it detects T1695.002 Ethernet. The official description and official detection fields are not provided, so this take is based on the relationship context: blocking Ethernet communications may prevent instructions, configuration messages, commands, or reporting from reaching target systems and devices.
Platforms, tactics, official detection logic, aliases, and labels are not specified. This summary does not assert active exploitation, attribution, specific vendor exposure, or guaranteed detection coverage. Local ICS architecture, network design, logging, and operational procedures are required to determine actual risk and detection feasibility.
Detection of Block Ethernet
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.
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 | 153f3754629d… |
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 DET0911Open 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.