AN1921: Analytic 1921
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 reporting messages are blocked. Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications. Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications. 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.
Analyst context for executives and security teams
AN1921 is an ICS detection analytic focused on recognizing possible blocked or lost communications by watching for asset alarms, loss of network connectivity, missing operational process data, relevant process or service termination, and application or protocol setting changes. For security leaders, the practical value is continuity: if an operator, controller, outstation, or supporting ICS application stops communicating, the business risk may be operational disruption, delayed response, or reduced visibility into the physical process.
Executive priority
Treat this analytic as a resilience and monitoring-assurance question: can the organization prove it would notice when critical ICS communications fail or are intentionally blocked? Priority should be based on which assets and communication paths support safety, production, service delivery, or regulatory evidence. Leaders should ask whether alarms, network evidence, application logs, and operational process data are collected, correlated, and reviewed quickly enough to support incident decisions.
Technical view
SOC, OT monitoring, and incident response teams should validate correlation across multiple evidence classes rather than relying on a single alert. The supplied ATT&CK description points to asset alarms indicating communication loss, network traffic showing blocked or missing communications, process or service termination for ICS automation protocols and application software, application log events for protocol or setting changes, and absence of expected operational process data. Because no ATT&CK platforms, tactics, or relationships are supplied, local ICS architecture and asset criticality must drive scoping.
Likely telemetry
- Asset alarms indicating loss of communications
- Network traffic or network monitoring records showing blocked, failed, or absent communication
- Process and service status for ICS automation protocol components and related application software
- Application logs showing network protocol setting changes or related events
- Operational process data feeds, including evidence of missing or stale process values
Detection direction
- Validate whether alarms for communication loss are centrally collected and time-synchronized with network and application telemetry.
- Correlate asset alarms with network evidence before escalating, since communications may fail for benign operational or maintenance reasons.
- Tune for absence-based signals, such as missing operational process data or loss of expected reporting, while accounting for planned outages and alternative communication paths.
- Monitor termination of ICS protocol or application services where local systems expose that telemetry.
- Review application log events for protocol or configuration changes that could explain blocked communications.
Mitigation priorities
- Prioritize visibility for critical ICS communication paths and assets first.
- Ensure asset alarms, network monitoring, application logs, service status, and operational process data can be correlated during incidents.
- Define operational baselines for expected communications and process data reporting so loss-of-signal conditions are meaningful.
- Create runbooks that distinguish maintenance, network failure, application failure, and suspected malicious blocking.
- Use the collected evidence to support compliance and incident-response documentation for communication-loss events.
Analyst notes and limits
This is a detection analytic, not a technique description. The strongest decision value is in confirming whether the organization can detect and investigate loss or blocking of ICS communications using multiple telemetry sources. The object provides no relationship context, so no related techniques, software, groups, or campaigns are inferred.
Official detection content is not provided as a separate field, and the object lists no platforms or tactics. The description gives monitoring guidance but does not define thresholds, protocols, products, or environment-specific indicators. Local ICS topology, normal communication patterns, maintenance schedules, and logging availability are required to operationalize this analytic.
Analytic 1921
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 reporting messages are blocked. Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications. Monitor application logs for changes to settings and other events associated with network protocols that may be used to block communications. 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.
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 | 92c8728b96d2… |
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 AN1921Open 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.