AN1861: Analytic 1861
Monitor for loss of network traffic which could indicate alarms are being suppressed. A loss of expected communications associated with network protocols used to communicate alarm events or process data could indicate this technique is being used. 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 for loss of operational process data which could indicate alarms are being suppressed. 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 for loss of expected device alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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 for loss of expected operational process alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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
This ICS detection analytic is about noticing when expected alarm or process-data communications go missing. For leaders, the business issue is not just a security alert; it is the possibility that operators may lose visibility into abnormal plant or process conditions because alarms are being suppressed or no longer reaching the right systems.
Executive priority
Prioritize this as an operational resilience and safety-visibility question: can the organization prove that critical alarms, process data, and alarm-related network communications are continuously monitored and reconciled across sources? This matters for incident decisions, compliance evidence, and cyber-physical risk because the analytic explicitly warns that missing communications or discrepancies may only provide indirect evidence and should complement other detections.
Technical view
SOC, OT monitoring, and incident response teams should validate whether they can identify loss of expected ICS network traffic used for alarm events or process data, loss of operational process data, loss of expected device alarms, and discrepancies between multiple alarm sources. Because ATT&CK provides no platform, tactic, relationship, or separate detection logic for this object, teams should treat it as a coverage-validation analytic rather than a standalone confirmation of adversary activity.
Likely telemetry
- Network traffic records for protocols that communicate alarm events or process data
- Operational process data streams and availability/heartbeat indicators
- Device alarm records from ICS equipment or monitoring systems
- Operational process alarm records
- Cross-source alarm comparison data showing whether one alarm source differs from another
Detection direction
- Baseline expected alarm, process-data, and related network communications so that loss or absence can be distinguished from normal downtime or maintenance.
- Correlate missing network traffic with missing process data and missing device or operational alarms; the analytic states these signals do not directly detect execution and should complement other detections.
- Look for discrepancies between multiple alarm sources, since partial suppression may leave some alarms visible while others disappear.
- Tune for expected outages, maintenance windows, communications failures, and sensor/device issues to reduce false positives.
- Escalate when loss of expected alarms coincides with other suspicious OT or ICS monitoring evidence, rather than treating absence alone as proof of malicious activity.
Mitigation priorities
- Confirm that critical alarm and process-data paths are inventoried and have defined expected communication patterns.
- Ensure monitoring covers both network communications and operational alarm/process-data sources, not only one layer.
- Establish procedures for operators and responders to investigate missing or inconsistent alarms as a potential visibility-loss condition.
- Document monitoring coverage, baselines, and response procedures as evidence for operational resilience and compliance readiness.
- Review gaps locally because no ATT&CK mitigation relationships or platform details were supplied for this analytic.
Analyst notes and limits
This Glexia take is based on MITRE ATT&CK ICS analytic AN1861, which focuses on monitoring for loss of network traffic, operational process data, device alarms, and operational process alarms as indirect evidence that alarms may be suppressed. The strongest defensive value is validating visibility and reconciliation across alarm sources.
The supplied object has no platforms, tactics, labels, aliases, relationships, or official detection field beyond the description text. It does not identify a specific technique execution pattern, product, protocol, adversary, or confirmed exploitation scenario. Local ICS architecture and normal operating baselines are required to make this actionable.
Analytic 1861
Monitor for loss of network traffic which could indicate alarms are being suppressed. A loss of expected communications associated with network protocols used to communicate alarm events or process data could indicate this technique is being used. 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 for loss of operational process data which could indicate alarms are being suppressed. 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 for loss of expected device alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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 for loss of expected operational process alarms which could indicate alarms are being suppressed. As noted in the technique description, there may be multiple sources of alarms in an ICS environment. Discrepancies between alarms may indicate the adversary is suppressing some but not all the alarms in the environment. 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 | dd50a0ae166a… |
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 AN1861Open 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.