AN1908: Analytic 1908
Monitor asset management systems for device configuration changes which can be used to understand expected parameter settings. Monitor device application logs parameter changes, although not all devices will produce such logs. Monitor for device alarms produced when parameters are changed, although not all devices will produce such alarms. Monitor ICS management protocols for parameter changes, including for unexpected values, changes far exceeding standard values, or for parameters being changed in an unexpected way (e.g., via a new function, at an unusual time).
Analyst context for executives and security teams
AN1908 is an ICS detection analytic focused on spotting device parameter and configuration changes. Its business value is in reducing the chance that unauthorized or mistaken changes go unnoticed in environments where equipment behavior, safety margins, and operational continuity depend on expected settings.
Executive priority
Security and operations leaders should treat this as a control-validation question: can the organization prove when critical ICS parameters change, who or what changed them, whether the new values are expected, and whether alarms or logs are retained for investigation? This matters for incident response readiness, operational resilience, compliance evidence, and cyber-physical risk management, especially because the ATT&CK description notes that not all devices generate parameter-change logs or alarms.
Technical view
SOC, IR, and OT security teams should validate monitoring across asset management systems, device application logs, device alarms, and ICS management protocol traffic for parameter changes. Detection should emphasize unexpected values, changes far outside normal ranges, changes made at unusual times, and changes performed through unexpected functions or methods. Because no platform, tactic, or relationship context is supplied, teams should map this analytic to their own ICS device inventory, management workflows, and normal engineering change windows before tuning alerts.
Likely telemetry
- Asset management system records showing device configuration or parameter changes
- Device application logs that record parameter changes, where available
- Device alarms generated when parameters are changed, where available
- ICS management protocol traffic or records indicating parameter modification
- Approved change records or maintenance windows for comparison with observed changes
Detection direction
- Confirm which ICS assets actually produce parameter-change logs or alarms; absence of logging is a material blind spot, not proof of no change.
- Baseline expected parameter values and acceptable ranges so alerts can distinguish routine engineering activity from unusual or unsafe changes.
- Correlate observed parameter changes with approved work orders, maintenance windows, and authorized engineering activity to reduce false positives.
- Monitor for unexpected change methods, new or unusual functions, unusual timing, and values far outside standard settings, as specified in the ATT&CK description.
- Use asset management and protocol-level visibility together where possible, since individual devices may not provide complete local logs.
Mitigation priorities
- Prioritize an inventory of critical ICS parameters and expected settings for high-consequence devices and processes.
- Ensure configuration and parameter changes are governed by documented change control and review workflows.
- Improve collection and retention of asset management, device log, alarm, and ICS management protocol evidence where the environment supports it.
- Define operational thresholds for unusual values and out-of-window changes with engineering stakeholders.
- Test incident response procedures for investigating unauthorized or unexplained parameter changes without assuming every device will provide complete forensic detail.
Analyst notes and limits
This take is based only on the supplied ATT&CK analytic description for AN1908. The object is an ICS detection analytic and does not provide tactics, platforms, relationships, or a separate official detection field. The strongest supported interpretation is that defenders should validate visibility and alerting for ICS parameter/configuration changes across management systems, device logs, alarms, and management protocol activity.
No relationship context, platform list, tactic mapping, adversary attribution, active exploitation claim, or vendor-specific telemetry is supplied. Local device capabilities, engineering practices, and available OT monitoring determine whether this analytic can be implemented effectively.
Analytic 1908
Monitor asset management systems for device configuration changes which can be used to understand expected parameter settings. Monitor device application logs parameter changes, although not all devices will produce such logs. Monitor for device alarms produced when parameters are changed, although not all devices will produce such alarms. Monitor ICS management protocols for parameter changes, including for unexpected values, changes far exceeding standard values, or for parameters being changed in an unexpected way (e.g., via a new function, at an unusual time).
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 | 849fe73bd32b… |
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 AN1908Open 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.