AN1909: Analytic 1909
Monitor ICS asset application logs that indicate alarm settings have changed, although not all assets will produce such logs. Consult asset management systems to understand expected alarm settings. Data about the industrial process may indicate it is operating outside of expected bounds and could help indicate that that an alarm setting has changed. 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 alarm setting changes observable in automation or management network protocols.
Analyst context for executives and security teams
This analytic matters because changed alarm settings in an industrial control environment can reduce an organization’s ability to notice unsafe or abnormal process conditions. For executives and security leaders, the decision point is whether the business can prove that critical alarms are configured as expected, that changes are logged where possible, and that process deviations are investigated even when the asset itself does not generate a clear security event.
Executive priority
Treat this as an operational resilience and safety-monitoring control question, not only a SOC detection question. Leaders should ask which ICS assets have business-critical alarm thresholds, where the approved settings are documented, who can change them, and whether incident responders can quickly compare current settings against expected baselines. This also supports compliance and audit evidence by showing that alarm configurations are managed, monitored, and reviewed.
Technical view
SOC, OT security, and incident response teams should validate three evidence paths described by MITRE: ICS asset application logs that show alarm setting changes; asset management records that define expected alarm settings; and industrial process data that may show operations outside expected bounds. Teams should also assess whether alarm setting changes are visible in automation or management network protocols. Because MITRE notes that not all assets produce application logs, detection should not depend on one log source alone.
Likely telemetry
- ICS asset application logs related to alarm configuration or alarm threshold changes
- Asset management or configuration management records showing expected alarm settings
- Industrial process data indicating operation outside expected bounds
- Automation network protocol traffic where alarm setting changes may be observable
- Management network protocol traffic where alarm setting changes may be observable
Detection direction
- Inventory which ICS assets can and cannot log alarm setting changes; document gaps explicitly.
- Compare current alarm settings against expected values from asset management systems rather than relying only on event logs.
- Correlate alarm configuration changes with process data that shows unexpected operating conditions, recognizing that process deviation is supporting evidence rather than direct proof of execution.
- Monitor automation and management network protocols for observable alarm setting changes where visibility exists.
- Tune investigations to distinguish authorized engineering or maintenance changes from unexpected changes by using approved configuration records and change context.
Mitigation priorities
- Establish and maintain authoritative expected alarm settings in asset management or configuration management systems.
- Prioritize logging and monitoring for assets and network paths where alarm setting changes are observable.
- Create review workflows for alarm setting changes, especially on critical industrial processes.
- Ensure incident response playbooks include comparison of current alarm settings, expected baselines, relevant logs, and process data.
- Document assets that do not produce sufficient logs so risk owners understand residual monitoring limitations.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS domain. Its practical value is in validating whether alarm configuration integrity can be observed through asset logs, configuration baselines, process data, and network protocol visibility. No ATT&CK tactics, platforms, or relationship context were supplied, so this take avoids mapping the analytic to a specific technique, vendor, asset class, or adversary behavior beyond the official description.
Official detection content is not provided, platforms are listed as none, tactics are not specified, and no relationships were supplied. Local engineering baselines, asset capabilities, logging coverage, and process context are required to determine whether this analytic is feasible and useful in a specific environment.
Analytic 1909
Monitor ICS asset application logs that indicate alarm settings have changed, although not all assets will produce such logs. Consult asset management systems to understand expected alarm settings. Data about the industrial process may indicate it is operating outside of expected bounds and could help indicate that that an alarm setting has changed. 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 alarm setting changes observable in automation or management network protocols.
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 | f30c32b13aa3… |
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 AN1909Open 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.