AN2054: Analytic 2054
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 Ethernet 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
Analytic 2054 is an ICS-focused detection analytic for recognizing possible loss of communications between operational assets, including situations where messages may be blocked. Its business value is early warning: loss of visibility or control communications can affect operational continuity, incident triage, and confidence in process monitoring even when the underlying cause is not yet proven malicious.
Executive priority
Security and operations leaders should treat this as a resilience and evidence question: do we have enough OT alarm, network, application, service, and process-data visibility to distinguish a communications outage from intentional blocking or misconfiguration? This analytic supports incident decision-making and compliance evidence by validating whether the organization can detect and investigate loss of operational communications across relevant ICS environments.
Technical view
SOC, OT monitoring, and incident response teams should validate correlation across asset alarms, network traffic indications of blocked communications, missing operational process data, application logs for protocol-setting changes, and termination of ICS automation protocol or application services. Because no ATT&CK platform or tactic is specified, implementation should be scoped to the local ICS architecture and communication paths, including any alternative outstation communication methods that may continue to produce alarms even when Ethernet messages are blocked.
Likely telemetry
- ICS asset alarms indicating loss of communications
- Network traffic or network control evidence showing blocked or interrupted communications
- Operational process data feeds, including gaps or absence of expected data
- Application logs for network protocol setting changes and related events
- Process and service status events for ICS automation protocol and application software
Detection direction
- Correlate loss-of-communications alarms with network evidence rather than treating alarms alone as proof of malicious activity.
- Tune for absence of expected operational process data, while recognizing this is supporting evidence and not direct detection of execution.
- Review application-log events for changes to settings associated with network protocols that could block communications.
- Monitor termination of processes or services associated with ICS automation protocols and application software.
- Account for blind spots where alternative communication methods keep some alarms visible even when Ethernet messages are blocked.
Mitigation priorities
- Prioritize visibility into OT asset alarms, process data availability, application logs, and service/process state before relying on this analytic operationally.
- Define normal communication patterns and expected process-data cadence for critical assets so loss-of-communications events can be triaged quickly.
- Establish investigation playbooks that combine OT operations context with network and application evidence.
- Validate logging retention and access for systems that manage ICS automation protocols and related application software.
- Use findings to inform resilience planning for communication path failures and blocked-message scenarios.
Analyst notes and limits
The supplied object is a detection analytic in the ICS ATT&CK domain with no specified platforms, tactics, aliases, labels, or relationship context. The practical emphasis is correlation: alarms, network indicators, process-data gaps, application-log changes, and service termination together provide stronger investigative value than any single signal.
Official detection content is not provided beyond the description, and no relationships identify a specific technique, platform, or campaign context. Local engineering knowledge is required to determine which alarms, protocols, services, and process-data streams are authoritative in a given ICS environment.
Analytic 2054
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 Ethernet 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 | eb85368c4d61… |
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 AN2054Open 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.