MITRE ATT&CK for ICS T0878 Alarm Suppression: Detecting Silenced Alarms Before Operators Miss Them

Alarm Suppression (T0878) is an adversary stopping protection alarms from reaching operators, so a dangerous condition develops while the control room sees nothing wrong. Alarms are how a plant tells people that something needs a response; suppressing them removes the human from the loop at the moment they matter most. MITRE ATT&CK for ICS v20 places T0878 under Inhibit Response Function across Embedded, Windows, Linux and Network Devices platforms, which reflects how many places an alarm can be silenced: in the controller, in the alarm server, on the HMI or on the network in between. This guide is for control engineers, alarm management owners, OT security engineers and OT SOC analysts. It covers how ATT&CK describes the technique, the v20 detection analytics, the mitigations, and a response that keeps process safety first. For the tactic overview see the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Key takeaways

• Two goals, not one. ATT&CK, citing a Secura presentation, describes a dual aim: stop outgoing alarms being raised, and stop incoming alarms being responded to.
• The method depends on the alarm type. ATT&CK lists alarms raised by a protocol message, signalled with I/O, or set as a flag bit, each suppressed in a different place.
• Silence is the signal. The v20 analytic looks for a process value crossing a known alarm threshold with no matching alarm event, and for alarm state changes with no operator behind them.
• A second path for alarms is the core mitigation. ATT&CK maps Out-of-Band Communications Channel (M0810) with static configuration, allowlists and segmentation.
• Maroochy is the recorded case. ATT&CK's Maroochy Water Breach campaign entry states the adversary suppressed alarm reporting to the central computer.

What T0878 covers

ATT&CK describes T0878 as adversaries targeting protection function alarms to prevent them from notifying operators of critical conditions. It stresses that disrupting the alarm system does not imply disrupting the reporting system as a whole: process values may keep updating on the HMI while the alarms that should accompany them never arrive. In ICS environments the adversary may have to contend with several alarms and with alarm propagation to reach a goal. ATT&CK lists methods including tampering with or altering device displays and logs, modifying in-memory code to fixed values, and tampering with assembly-level instruction code.

T0878 sits beside several related techniques, and naming them helps scope detections. Modify Alarm Settings (T0838) changes thresholds or disables alarms through configuration; see T0838 Modify Alarm Settings. Manipulation of View (T0832) shows operators false values; see T0832 Manipulation of View. Loss of Protection (T0837) is the impact when protective functions fail; see T0837 Loss of Protection. Block Communications (T1695) and Block Operational Technology Message (T1691) describe stopping messages on the wire; see T1691 Block Operational Technology Message.

The recorded case: Maroochy Water Breach

ATT&CK's only procedure example for T0878 is the Maroochy Water Breach campaign (C0020), dated February to April 2000. ATT&CK records that the adversary suppressed alarm reporting to the central computer, and in the same campaign disabled alarms at four pumping stations (mapped to T0838), used a dedicated two-way radio to send false data and instructions, and caused the release of roughly 800,000 litres of raw sewage. ATT&CK's source is Marshall Abrams' 2008 MITRE case study.

The lessons still apply. The adversary had engineering software, knowledge of the system and a radio path that nobody was watching. The central computer had no independent way to learn that stations were in trouble. Modern equivalents are an alarm server that accepts configuration writes from any host and a communications path with no second channel.

The 2026 joint advisory AA26-097A (FBI, CISA and partners) describes Iranian-affiliated actors disabling critical shutdown and alarm logic on PLCs so that unsafe conditions could occur without operator notice. ATT&CK maps that activity to other techniques in its CyberAv3ngers procedure examples, but the defensive lesson is the same: alarm logic in the controller is as much a target as the alarm server. See the Water and Wastewater Cybersecurity Guide.

Detection: the ATT&CK v20 analytics

MITRE's detection strategy for T0878 (DET0728, Detection of Alarm Suppression) has four analytics, one per platform. Each applies ATT&CK's OT operational fidelity gate: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and falls outside an approved change window or lacks change control context.

The most robust of these is the process-versus-alarm comparison, because it does not depend on catching the suppression act itself. It needs the historian to hold both the process value and the alarm journal, and an agreed list of alarm thresholds. Build it with the alarm management owner, since legitimately shelved or out-of-service alarms will otherwise flood the queue. See the OT Network Security Monitoring Guide and the OT Security Operations Centre Guide.

Prevention: ATT&CK mitigations in practice

Alarm management discipline supports these controls. ANSI/ISA-18.2-2016, Management of Alarm Systems for the Process Industries, covers the alarm lifecycle including change management, and ISA-TR18.2.5-2022 covers alarm system monitoring, assessment and auditing, including standing alarms. A rationalised alarm system with a documented philosophy gives the security team a baseline: which alarms exist, their priority, and who may shelve or suppress them. Without that baseline, an adversary's suppression looks like the many alarms already ignored. Harden the alarm servers themselves too; see the HMI and SCADA Server Hardening Guide.

Where identity fits

The v20 analytics depend on an operator or session identity: an alarm suppressed "without operator_id" is the alert. Shared HMI logins make that impossible, because every action looks like the same person. Use named operator accounts on HMIs and alarm servers where the product supports it, separate rights to shelve or suppress alarms from rights to view them, and treat the service account of the alarm management application as privileged, since the Linux analytic relies on knowing which UID should write alarm configuration. See the OT and ICS Identity and Access Guide.

How to implement

1. Agree the baseline with alarm management: master alarm list, priorities, who may shelve or suppress, and the change process.
2. Map alarm paths: for each critical alarm, record whether it travels by protocol message, I/O or flag bit, and through which servers and network devices.
3. Add an out-of-band path for the alarms whose loss would be most serious, decided with process safety engineers.
4. Collect the logs: alarm journal and process history from the historian, alarm server audit logs, Sysmon or auditd on alarm servers, and syslog from network devices on alarm paths.
5. Deploy the analytics in alert-only mode, starting with the process-versus-alarm comparison for top-priority alarms, and tune through a maintenance cycle.
6. Restrict and fix configuration: static automation connections and allowlists on communication servers and gateways, rolled out one site or unit at a time with prior settings recorded for rollback.

Decision guidance

• Small sites: a hardwired or independent notification for a handful of critical alarms, plus named HMI accounts, gives most of the benefit without a monitoring platform.
• Large sites with a historian: invest in the process-versus-alarm comparison; it catches suppression regardless of method.
• Substations using IEC 61850 GOOSE: include the stNum and test-mode checks from the ATT&CK analytic in protocol monitoring.
• Where alarms carry safety functions: involve the process safety team; the safety instrumented system must not depend on the alarm path an adversary can reach. See the Safety and Security Co-engineering Guide.

Responding to suspected alarm suppression

If alarms may be suppressed, operators may be blind to a developing hazard, so the first step is operational, not forensic.

1. Tell operations immediately so they can increase field checks, rely on local indications and independent readings, and decide on any process action.
2. Preserve evidence: alarm journal, historian data, alarm server audit and configuration, network device configuration and captures.
3. Restore alarm configuration from a verified baseline, with alarm management confirming each change, and confirm alarms annunciate by test where safe.
4. Contain the source: block the host or account that made the change and check for related view or control manipulation.

See the OT Incident Response Guide.

Detection and measurement

• Coverage: percentage of highest-priority alarms with an out-of-band path.
• Silent crossings: count of threshold crossings with no alarm event, and time to explain each.
• Unattributed changes: alarm suppress, shelve or disable actions without an operator ID or change reference.
• Account hygiene: percentage of HMI and alarm server actions made under named accounts.
• Standing suppressions: number of alarms shelved or out of service beyond their approved period.

Framework mapping

Common failure patterns

• Alarm floods accepted as normal: with hundreds of standing alarms, one more suppressed alarm goes unnoticed.
• Shared HMI accounts: no way to tell an operator's shelving from an adversary's.
• One path for every alarm: a single communication server or gateway can silence the whole plant.
• Monitoring only the alarm server: suppression in controller logic or on the network is missed.
• Test mode left on: protection relays or devices in test mode stop reporting real events.

Practitioner checklist

• Agree a master alarm list and suppression rights with alarm management.
• Map how each critical alarm travels and where it could be silenced.
• Provide an out-of-band path for the highest-priority alarms.
• Compare process values against alarm events for critical thresholds.
• Alert on alarm suppression without an operator ID or change reference.
• Use named HMI and alarm server accounts.
• Fix automation connections statically and allowlist gateway access.
• Review standing shelved and out-of-service alarms each week.

Standards and references

• MITRE ATT&CK for ICS: Alarm Suppression (T0878)
• MITRE ATT&CK: Detection of Alarm Suppression (DET0728)
• MITRE ATT&CK: Maroochy Water Breach (C0020)
• MITRE ATT&CK: Out-of-Band Communications Channel (M0810)
• ISA: ISA-18 Series of Standards (Alarm Management)
• FBI, CISA and partners: AA26-097A, Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · ATT&CK for ICS Inhibit Response Function Tactic Guide · HMI and SCADA Server Hardening Guide · OT Security Operations Centre Guide