AN2055: Analytic 2055
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 Wi-Fi 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 2055 is an ICS detection analytic focused on recognizing possible blocked or lost communications by watching for asset alarms, missing operational process data, application log changes related to network protocols, and termination of ICS protocol or application services. Its business value is resilience: a communications loss in an industrial environment can reduce visibility and control even when the original blocking activity is not directly observed.
Executive priority
Treat this as a control-validation item for operational continuity and incident readiness rather than a standalone alert. Leaders should ask whether the organization can prove it will notice loss of ICS communications quickly, correlate it with network evidence, and distinguish a cyber-relevant interruption from expected outages, maintenance, or equipment faults. This supports audit evidence, SOC/OT coordination, and incident decision-making when communications to assets or outstations are disrupted.
Technical view
SOC, OT, and IR teams should validate whether they collect and correlate the evidence classes named by ATT&CK: asset alarms indicating loss of communications, network traffic showing blocked communications, absence of expected operational process data, application logs showing protocol setting changes or related events, and process/service termination events for ICS automation protocols and application software. Because the supplied object has no ATT&CK platforms, tactics, or relationship context, implementation should be mapped locally to the site’s ICS applications, protocols, outstations, and alarm sources.
Likely telemetry
- Asset alarms indicating loss of communications
- Network traffic or network control evidence showing traffic has been blocked
- Operational process data feeds, including gaps or absence of expected data
- Application logs for settings changes and events associated with network protocols
- Process and service monitoring for ICS automation protocol services and application software
Detection direction
- Correlate loss-of-communications alarms with network traffic evidence before treating the event as cyber-relevant.
- Monitor for absence of expected operational process data as supporting evidence, recognizing that this does not directly detect execution of the underlying behavior.
- Review application logs for protocol-related settings changes and events that could explain blocked communications.
- Alert on termination of processes or services associated with ICS automation protocols and application software, tuned against maintenance and restart activity.
- Account for alternate communication paths: ATT&CK notes that alarms may still be visible even if Wi-Fi messages are blocked.
Mitigation priorities
- Inventory critical ICS communication paths, outstations, protocol services, and alarm sources so detection logic can be scoped correctly.
- Ensure asset alarms, operational process data, application logs, network traffic evidence, and process/service events are retained and available to SOC/OT responders.
- Define triage procedures for communications loss that separate maintenance, equipment failure, and potential blocking activity.
- Test correlation workflows during tabletop or operational resilience exercises to confirm responders can act when primary communications are unavailable.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS domain with no relationship context. The most useful interpretation is not that any single alarm proves malicious activity, but that multiple weak signals can strengthen confidence around a communications-loss event.
Official detection content is not separately provided, platforms and tactics are not specified, and no related techniques, mitigations, groups, or software were supplied. Local engineering knowledge is required to identify the relevant protocols, applications, services, outstations, expected process data, and normal maintenance patterns.
Analytic 2055
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 Wi-Fi 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 | 2311a37118b0… |
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 AN2055Open 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.