DET0786: Detection of Denial of Control
DET0786 is a detection strategy placeholder for identifying Denial of Control in ICS environments: situations where operators or engineers are temporarily...
Analyst context for executives and security teams
DET0786 is a detection strategy placeholder for identifying Denial of Control in ICS environments: situations where operators or engineers are temporarily unable to interact with process controls. The business significance is operational resilience—an affected process may continue running while staff cannot adjust it, which can turn a cyber event into a safety, availability, quality, or recovery-time problem.
Executive priority
Leaders should treat this as a cyber-physical continuity question, not only a SOC alerting question. The priority is to confirm whether the organization can prove when control access is lost, distinguish cyber-related loss of control from normal communications or equipment faults, and escalate quickly enough for operations, engineering, and incident response to make safe decisions. Because ATT&CK provides no platform, tactic, or detection detail for this strategy, local ICS architecture and process criticality should drive investment and audit evidence.
Technical view
SOC, IR, and OT engineering teams should validate detection around the related ATT&CK technique T0813, Denial of Control. Focus on evidence that shows temporary loss of operator or engineer interaction with control devices, loss of communication with control devices, or inability to adjust process controls while the process may continue operating. Since the official detection text and platforms are not specified, detection engineering should be based on site-specific control system communications, operator workstation/HMI activity, controller availability, and process-state context rather than assumptions from the ATT&CK object alone.
Likely telemetry
- ICS network communications between operator/engineering stations, HMIs, and control devices
- Controller or control-device availability and communication status logs where available
- HMI/operator workstation events showing failed interaction, unavailable controls, or loss of session/connectivity
- Engineering workstation activity relevant to attempted control interaction
- Process historian or operational data showing process state during periods of lost control interaction
Detection direction
- Confirm that monitoring can identify loss of communication or control interaction with control devices, not just IT host outages.
- Correlate operator/HMI symptoms with controller communication status and process-state data to avoid treating every network interruption as malicious Denial of Control.
- Tune for operational false positives such as maintenance windows, planned controller downtime, network changes, equipment faults, and known process upsets.
- Define escalation paths that include OT operations and engineering, because process state may remain active even when control interaction is unavailable.
- Document visibility gaps explicitly, especially where control devices, HMIs, or engineering workstations do not provide accessible logs or where passive ICS network monitoring is absent.
Mitigation priorities
- Prioritize resilient monitoring and response procedures for critical processes where temporary loss of control would create safety, production, or recovery risk.
- Maintain clear operational runbooks for loss-of-control scenarios, including safe-state decision criteria and OT/IR handoffs.
- Validate network and system segmentation, access controls, and change-management evidence around systems used to interact with process controls.
- Test backup communication paths, manual procedures, or compensating operational controls where appropriate to the environment.
- Use tabletop and technical exercises to prove that alerts, operations awareness, and incident escalation work during a control-access interruption.
Analyst notes and limits
This take is based on the ATT&CK detection strategy object DET0786 and its relationship to technique T0813, Denial of Control. The practical value is in validating site-specific visibility and response for temporary loss of operator or engineer control over ICS processes.
The supplied ATT&CK object has no official description, detection text, tactics, platforms, aliases, or labels. Telemetry and control recommendations are therefore conservative and derived from the related T0813 description plus general defensive validation needs for ICS environments; local architecture and operational evidence are required.
Detection of Denial of Control
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 | T0813 | Denial of Control | This object detects Denial of Control. |
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 | a8450dfa9573… |
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 DET0786Open 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.