AN1915: Analytic 1915
Monitor device management protocols for functions that modify programs such as online edit and program append events. Monitor device alarms that indicate the program has changed, although not all devices produce such alarms. Engineering and asset management software will often maintain a copy of the expected program loaded on a controller and may also record any changes made to controller programs. Data from these platforms can be used to identify modified controller programs. Monitor device application logs that indicate the program has changed, although not all devices produce such logs.
Analyst context for executives and security teams
AN1915 is an ICS detection analytic focused on spotting unauthorized or unexpected changes to controller programs. Its business value is that controller logic changes can directly affect production, safety, quality, and recovery confidence. Executives and security leaders should treat this as a validation point for whether engineering changes are visible, attributable, and reconcilable against an approved baseline.
Executive priority
Prioritize this where operational continuity depends on programmable controllers and where audit or incident response teams must prove whether controller logic changed. The key leadership question is not simply whether the SOC has alerts, but whether engineering, asset management, and device-level evidence can confirm the expected program on a controller and identify online edits, appended logic, alarms, or logs indicating change.
Technical view
SOC, OT security, and incident response teams should validate collection and correlation of evidence from device management protocols, controller/device alarms, engineering workstations, asset management software, and device application logs. Because the ATT&CK object does not specify platforms, tactics, or a formal detection expression, implementation should be environment-specific and tied to known controller types, approved engineering workflows, and the authoritative source of expected controller programs.
Likely telemetry
- Device management protocol activity showing functions that modify programs, such as online edit or program append events
- Controller or device alarms indicating that a program has changed
- Engineering software records of controller program changes
- Asset management software copies or baselines of expected controller programs
- Device application logs indicating program modification, where available
Detection direction
- Confirm whether protocol monitoring can distinguish normal engineering activity from program-modifying functions such as online edits or append events.
- Compare observed controller program state against expected copies maintained by engineering or asset management systems.
- Tune detection around approved maintenance windows, authorized engineering workstations, and documented change tickets to reduce false positives.
- Account for blind spots: not all devices generate program-change alarms or application logs, and the official ATT&CK object provides no platform-specific detection logic.
- Use multiple evidence sources where possible, because reliance on a single alarm or log source may miss changes on devices that do not emit those records.
Mitigation priorities
- Establish and maintain authoritative baselines of expected controller programs in engineering or asset management systems.
- Require documented approval and traceability for controller program changes, including online edits and append operations.
- Ensure OT monitoring, engineering tools, and asset management platforms retain sufficient records to support incident response and compliance evidence.
- Review devices that do not produce program-change alarms or logs and compensate with protocol monitoring, periodic comparison, or engineering-system records.
- Validate incident response procedures for rapidly determining whether a controller program changed and whether the current logic matches the approved baseline.
Analyst notes and limits
This analytic is especially relevant to OT environments where controller program integrity is central to operational resilience. The supplied ATT&CK content points to monitoring and comparison sources rather than a complete detection rule. Glexia would use this as a control validation item: can the organization prove what logic should be on a controller, see when it changes, and reconcile the change to an authorized engineering action?
The supplied object has no platforms, tactics, relationships, or official detection text beyond the description. It does not identify specific vendors, protocols, controller families, adversaries, or exploitation activity. Local asset inventory, engineering workflows, device capabilities, and logging architecture are required to determine actual coverage.
Analytic 1915
Monitor device management protocols for functions that modify programs such as online edit and program append events. Monitor device alarms that indicate the program has changed, although not all devices produce such alarms. Engineering and asset management software will often maintain a copy of the expected program loaded on a controller and may also record any changes made to controller programs. Data from these platforms can be used to identify modified controller programs. Monitor device application logs that indicate the program has changed, although not all devices produce such logs.
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 | a5c3f57a10b7… |
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 AN1915Open 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.