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

DET0777: Detection of Modify Alarm Settings

DET0777 is an ATT&CK for ICS detection strategy for identifying attempts to modify alarm settings. In operational technology environments, alarm settings a...

ICSDET0777Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0777 is an ATT&CK for ICS detection strategy for identifying attempts to modify alarm settings. In operational technology environments, alarm settings are not just configuration data: they are part of how operators recognize abnormal or unsafe process conditions. If alarm behavior is changed, an organization may lose warning signals that support safe operations, incident response, and business continuity.

Executive priority

Treat this as an operational resilience and safety-relevant detection gap to validate, not as a generic IT alert. Leaders should ask whether alarm configuration changes are authorized, logged, reviewed, and recoverable, and whether SOC and operations teams can distinguish planned engineering work from suspicious suppression of operator visibility. Because the ATT&CK object provides no platform-specific guidance or official detection text, priority should be based on the organization’s local ICS architecture, critical processes, and reliance on alarms for safe operations.

Technical view

This detection strategy is related to ATT&CK technique T0838, Modify Alarm Settings, where adversaries may alter alarm settings to prevent alerts that would inform operators of their presence or prevent responses to dangerous or unintended scenarios. SOC, IR, and OT engineering teams should validate whether changes to alarm configuration, alarm thresholds, reporting messages, acknowledgements, and related control-system state reporting are captured with sufficient user, asset, timestamp, and before/after context. Since no official platforms, tactics, or detection logic are supplied, teams should map this strategy to local control-system components and approved alarm-management workflows before writing detections.

Likely telemetry

  • Alarm configuration change records from control-system or engineering environments
  • Operator, engineer, or administrator activity logs associated with alarm management
  • Change-management records for approved alarm tuning or suppression
  • Control-system reporting messages and acknowledgements that show alarm state or system state changes
  • Asset and account context for systems authorized to modify alarm settings

Detection direction

  • Inventory where alarm settings can be changed and confirm those systems generate auditable events.
  • Baseline approved alarm-management activity so detections can separate maintenance or tuning from unusual changes.
  • Alert on alarm setting changes that lack approved change records, occur outside expected windows, or involve unusual accounts or assets, where local telemetry supports this.
  • Correlate alarm-setting changes with loss, reduction, or unexpected absence of reporting messages or operator alerts.
  • Account for false positives from legitimate engineering work, commissioning, alarm rationalization, and maintenance activities.

Mitigation priorities

  • Establish formal change control and approval for alarm setting modifications.
  • Restrict alarm-management privileges to authorized operations or engineering personnel.
  • Ensure alarm configuration data and related change logs are retained for investigation and audit evidence.
  • Coordinate SOC, incident response, and OT operations playbooks for suspicious alarm suppression or unauthorized alarm changes.
  • Periodically review alarm settings and compare them against approved baselines, especially for critical physical processes.
Analyst notes and limits

The supplied ATT&CK object is a detection strategy with no official description, no official detection text, no specified platforms, and no specified tactics. The practical value comes primarily from its relationship to ICS technique T0838, Modify Alarm Settings. Any production detection should be engineered against local ICS products, alarm-management practices, and change-control procedures.

This take does not infer specific technologies, adversaries, exploitation activity, or guaranteed detection coverage. The related technique description provided is partial, and local environment evidence is required to determine applicable telemetry, severity, and control ownership.

Official MITRE ATT&CK definition

Detection of Modify Alarm Settings

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 T0838 Modify Alarm Settings This object detects Modify Alarm Settings.
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
8bce7f102376a94b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 8bce7f102376…
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 DET0777
    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.