Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0728: Detection of Alarm Suppression

DET0728 is an ATT&CK for ICS detection strategy for identifying alarm suppression behavior. The business issue is operational visibility: if protection-fun...

ICSDET0728Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0728 is an ATT&CK for ICS detection strategy for identifying alarm suppression behavior. The business issue is operational visibility: if protection-function alarms are prevented from reaching operators, leaders may lose warning of unsafe or degraded conditions even if other reporting remains available. This matters for incident response, OT monitoring readiness, and cyber-physical risk governance because alarm integrity is often part of how organizations prove they can recognize and respond to critical process conditions.

Executive priority

Treat this as a validation item for OT resilience and audit evidence: can the organization prove that critical alarm paths are monitored, changes to alarm behavior are reviewed, and operators would know if alarms were suppressed or stopped? Budget and control priorities should focus on preserving alarm visibility, collecting defensible evidence from OT systems, and integrating OT alarm anomalies into incident decision-making without assuming IT-centric telemetry is sufficient.

Technical view

The supplied ATT&CK object has no official description, detection text, tactics, or platforms, but it is related to ICS technique T0878: Alarm Suppression. SOC, OT security, and IR teams should therefore validate detection around unexpected changes in protection-function alarm behavior, missing or reduced alarm notifications, and discrepancies between process conditions and alarm/reporting outputs. Because the relationship text notes that disrupting alarms does not necessarily disrupt the whole reporting system, detection should compare multiple evidence sources rather than relying on a single alarm console or reporting path.

Likely telemetry

  • OT alarm/event logs from engineering workstations, HMI, alarm servers, historians, or reporting systems where available
  • Configuration or change records for alarm thresholds, enable/disable states, notification routing, and protection-function settings
  • Operator acknowledgement logs and alarm lifecycle records
  • Process condition telemetry that can be compared against expected alarm generation
  • Access logs for systems or accounts able to modify alarm configuration or notification behavior

Detection direction

  • Validate whether critical alarm enablement, threshold, routing, and notification changes are logged with user, time, asset, and before/after context.
  • Look for mismatches between process conditions and expected alarms, including conditions that should have generated alarms but did not.
  • Correlate alarm changes with privileged access, maintenance windows, engineering activity, and operator actions to reduce false positives.
  • Do not assume normal reporting means alarming is intact; the related technique explicitly distinguishes alarm disruption from broader reporting disruption.
  • Prioritize high-consequence protection-function alarms and environments where loss of operator notification would affect safety, uptime, or regulatory evidence.

Mitigation priorities

  • Inventory critical alarm paths and identify which systems, accounts, and workflows can suppress, disable, reroute, or modify alarms.
  • Require controlled change management and review for alarm configuration and notification changes, especially for protection functions.
  • Ensure OT logging preserves alarm state changes and related administrative activity in a form usable by SOC and incident responders.
  • Establish operational playbooks for suspected alarm suppression, including cross-checking process telemetry, operator observations, and reporting systems.
  • Periodically test monitoring assumptions through defensive validation so teams know whether alarm suppression would be visible before an incident.
Analyst notes and limits

This take is based only on the detection strategy metadata and its ATT&CK relationship to T0878 Alarm Suppression in the ICS domain. The practical value is in validating alarm integrity and evidence collection, not in claiming a specific product, platform, adversary, or incident pattern.

The official object provides no description, detection text, tactics, platforms, aliases, or labels. Recommended telemetry and controls are therefore conservative, relationship-driven, and must be adapted to the organization’s actual OT architecture, alarm systems, logging capability, and operational procedures.

Official MITRE ATT&CK definition

Detection of Alarm Suppression

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
ICS T0878 Alarm Suppression This object detects Alarm Suppression.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
896161ced06e1025...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 896161ced06e…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0728
    Open source URL
Source and licensing

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.