AN1929: Analytic 1929
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 over serial COM ports 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
This analytic matters because loss of communications in an ICS environment can affect operational visibility and response. The ATT&CK text points to a practical detection approach: look for asset alarms, loss of network communications, missing operational process data, application log changes related to network protocols, and terminated ICS protocol or application services. For leaders, the value is not just detecting a single event; it is validating whether the organization can prove when control-system communications degrade or disappear.
Executive priority
Prioritize this as an operational resilience and incident decision-making control. Executives should ask whether SOC, OT operations, and incident response teams can distinguish normal communications loss from potentially suspicious blocked communications, and whether evidence is collected across alarms, network traffic, process data, application logs, and service/process status. This also supports compliance and audit readiness where organizations must demonstrate monitoring of critical industrial communications and response to loss of visibility.
Technical view
SOC and OT defenders should validate monitoring for communications loss using multiple evidence sources because the supplied analytic notes that no single signal directly proves execution. Correlate asset alarms with network traffic showing blocked or absent communications, gaps in operational process data, application log events tied to network protocol settings, and termination of processes or services associated with ICS automation protocols and application software. Also account for environments with alternate outstation communications paths, where alarms may remain visible even if serial COM port messages are blocked.
Likely telemetry
- ICS asset alarms indicating loss of communications
- Network traffic metadata or logs showing blocked, absent, or failed communications
- Operational process data streams, including gaps or lack of expected values
- Application logs for settings changes or events associated with network protocols
- Process and service monitoring for ICS automation protocol services and application software
Detection direction
- Validate correlation logic across alarms, network traffic, process data, application logs, and process/service status rather than relying on one signal.
- Tune baselines for expected operational process data frequency and expected communications patterns to reduce false positives from maintenance, outages, or planned configuration changes.
- Include alternate communications paths in detection design; visibility through one path may mask loss over another path.
- Review application log coverage for network protocol setting changes and related events.
- Confirm that service/process termination monitoring covers ICS automation protocol services and application software relevant to the local environment.
Mitigation priorities
- Establish an inventory of critical ICS communications paths, including network and serial communications where applicable.
- Ensure monitoring coverage for alarms, network traffic, process data, application logs, and process/service state before depending on this analytic operationally.
- Define response procedures for loss-of-communications events, including OT operations validation and escalation criteria.
- Maintain baselines for normal communications and process data availability to support faster triage.
- Use incident reviews and tabletop exercises to test whether teams can identify, correlate, and respond to communications loss without over-escalating routine outages.
Analyst notes and limits
The object is a detection analytic in the ICS ATT&CK domain with no tactics, platforms, or relationship context supplied. The strongest use of this analytic is as a cross-source validation pattern for loss of communications, not as a standalone proof of malicious activity.
Official detection text is not provided, and no related techniques, groups, software, mitigations, or platforms were supplied. Local asset inventory, protocol knowledge, expected communications patterns, and operational context are required to turn this into reliable detection logic.
Analytic 1929
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 over serial COM ports 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 | dbee70e614c7… |
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 AN1929Open 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.