AN2053: Analytic 2053
Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist, alarms may still be visible even if messages are blocked.
Monitor for a loss of network communications, which may indicate this technique is being used.
Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution but instead may provide additional evidence that the technique has been used and may complement other detections.
Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.
Analyst context for executives and security teams
AN2053 is an ICS detection analytic focused on recognizing loss of communications. For business leaders, the value is not simply identifying a network issue; in industrial environments, missing communications or missing process data can affect operational awareness, incident triage, and confidence in safe continuity decisions.
Executive priority
Treat this as an operational resilience and incident decision-making control. Leaders should ask whether the organization can distinguish routine communications loss from potentially intentional blocking, whether alarms remain visible through alternate paths, and whether SOC/OT teams have enough correlated evidence to support timely escalation without disrupting operations unnecessarily.
Technical view
Validate monitoring for asset alarms indicating loss of communications, absence of operational process data, application log events tied to network protocol settings, and termination of ICS automation protocol or application services. Because the object provides no platform, tactic, or relationship context, detection engineering should be environment-specific and should correlate alarm, network, process-data, application-log, and service/process telemetry before treating the condition as malicious.
Likely telemetry
- Asset alarms indicating loss of communications
- Network traffic evidence showing blocked or absent communications
- Operational process data availability or absence
- Application logs for network protocol setting changes and related events
- Process and service monitoring for ICS automation protocol or application software termination
Detection direction
- Confirm that loss-of-communications alarms are collected, timestamped, and available to SOC or OT responders.
- Correlate alarms with network traffic data to determine whether traffic appears blocked or absent.
- Use lack of operational process data as supporting evidence, not as standalone proof of technique execution.
- Review application logs for protocol-related configuration or event changes that could explain blocked communications.
- Monitor termination of ICS automation protocol and application software processes or services, while tuning for maintenance, failover, or planned engineering activity.
Mitigation priorities
- Prioritize telemetry coverage and retention for ICS alarms, network communications, process data, application logs, and service/process state.
- Document normal communication-loss scenarios, maintenance windows, failover behavior, and alternate communication paths to reduce false positives.
- Build escalation playbooks that require correlation across OT alarms, network evidence, and application/service status before operational action.
- Use findings to support compliance and resilience evidence showing that loss of communications can be detected, investigated, and escalated.
Analyst notes and limits
This analytic is best used as a correlation pattern for OT/ICS monitoring rather than a single alert. Its practical value depends on local knowledge of automation protocols, outstation communication design, normal outage patterns, and which teams own alarm, network, and application telemetry.
The supplied ATT&CK object has no platforms, tactics, relationships, or separate official detection field. It does not identify a specific adversary, tool, technique relationship, or guaranteed detection method. Local architecture and telemetry availability are required to operationalize it.
Analytic 2053
Monitor asset alarms which may help identify a loss of communications. Consider correlating alarms with other data sources that indicate traffic has been blocked, such as network traffic. In cases where alternative methods of communicating with outstations exist, alarms may still be visible even if messages are blocked.
Monitor for a loss of network communications, which may indicate this technique is being used.
Monitor for lack of operational process data which may help identify a loss of communications. This will not directly detect the technique’s execution but instead may provide additional evidence that the technique has been used and may complement other detections.
Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications.
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 3fa35368729f… |
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 AN2053Open 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.