AN1916: Analytic 1916
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications. 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 a loss of network communications, which may indicate this technique is being used. 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 command messages are blocked.
Analyst context for executives and security teams
AN1916 is an ICS detection analytic focused on recognizing when communications may be blocked by watching for indirect operational symptoms: terminated ICS automation processes or services, missing operational process data, application log changes related to network protocols, loss of network communications, and asset alarms. For leaders, the value is resilience: if defenders cannot quickly distinguish a real communications blockage from normal maintenance or equipment failure, incident response and plant operations may lose time during an outage or degraded-control event.
Executive priority
Treat this as an operational continuity and evidence-readiness analytic rather than a standalone alert. Security and operations leaders should ask whether the organization can prove, during an incident, that it collects enough ICS process, application, network, and alarm data to identify loss of communications and correlate it with other evidence. Priority should be given to environments where blocked command or process communications could affect safety, production availability, or response decision-making.
Technical view
SOC, OT monitoring, and incident response teams should validate correlation across the evidence types named by MITRE: ICS automation process or service status, operational process data availability, application logs for network-protocol setting changes or related events, network communication loss, and asset alarms. Because the ATT&CK object provides no specific platforms, tactics, or relationship context, implementation should be environment-specific and tuned to known ICS applications, normal communication paths, maintenance windows, and expected alarm behavior. This analytic does not directly detect the underlying technique execution; it supplies supporting evidence that communications may have been blocked.
Likely telemetry
- ICS automation process and service start/stop or termination events
- Operational process data availability or absence indicators
- Application logs showing settings changes or events associated with network protocols
- Network communication status, loss, or traffic-flow evidence
- ICS asset alarms indicating potential loss of communications
Detection direction
- Validate that loss-of-communication alerts are correlated with network traffic evidence rather than treated as isolated alarms.
- Tune for planned maintenance, controller or application restarts, known outages, and expected process-data gaps to reduce false positives.
- Confirm whether alternative communication paths could leave some alarms visible even when command messages are blocked.
- Use this analytic as corroborating evidence alongside other detections, since the official description states it may not directly detect technique execution.
- Document data-source coverage gaps where process/service telemetry, application logs, network visibility, or asset alarms are unavailable.
Mitigation priorities
- Prioritize visibility first: ensure OT teams can collect and retain process/service status, process data availability, application logs, network communication evidence, and asset alarms.
- Define normal communication baselines and maintenance expectations so blocked communications can be distinguished from routine operational changes.
- Establish SOC-to-operations triage procedures for communication-loss events, including escalation criteria and required corroborating evidence.
- Review resilience plans for critical ICS communications where loss or blocking could affect operational continuity.
- Use the analytic’s required evidence sources as compliance and incident-readiness artifacts where applicable.
Analyst notes and limits
This object is a detection analytic in the ICS ATT&CK domain with external ID AN1916. The supplied fields provide a high-level monitoring strategy but no official detection logic, platforms, tactics, aliases, labels, or relationship context. The most defensible interpretation is that AN1916 supports investigation of blocked communications through correlated operational symptoms rather than direct confirmation of malicious execution.
No relationship context, platform list, tactic mapping, or official detection code was supplied. Local ICS architecture, normal operations, logging capability, and alarm semantics are required to determine practical coverage and alert fidelity.
Analytic 1916
Monitor for the termination of processes or services associated with ICS automation protocols and application software which could help detect blocked communications. 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 a loss of network communications, which may indicate this technique is being used. 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 command messages are blocked.
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 | 37550e509569… |
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 AN1916Open 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.