AN1920: Analytic 1920
Monitor ICS automation protocols for anomalies related to reading point or tag data, such as new assets using these functions, changes in volume or timing, or unusual information being queried. Many protocols provide multiple ways to achieve the same result (e.g., functions with/without an acknowledgment or functions that operate on a single point vs. multiple points). Monitor for changes in the functions used. Monitor asset application logs which may provide information about requests for points or tags. Look for anomalies related to reading point or tag data, such as new assets using these functions, changes in volume or timing, or unusual information being queried. Many devices provide multiple ways to achieve the same result (e.g., functions with/without an acknowledgment or functions that operate on a single point vs. multiple points). Monitor for changes in the functions used.
Analyst context for executives and security teams
This analytic matters because unauthorized or unusual reading of ICS points or tags can be an early sign that someone or something is mapping process state, controller data, or operational context before taking further action. For leaders, the practical question is whether the organization can see abnormal use of automation protocol read functions and asset application requests well enough to distinguish expected engineering or monitoring activity from unusual discovery-like behavior.
Executive priority
Prioritize this as an ICS visibility and operational resilience control. It helps answer whether SOC and OT teams have evidence to investigate suspicious access to process data, support incident decisions, and demonstrate monitoring around critical industrial assets. The main business risk is not the read action alone, but what unusual point or tag queries may reveal about intent, asset exposure, and potential follow-on risk to operations.
Technical view
Validate whether ICS network monitoring and asset application logs capture requests for point or tag data, including source asset, destination asset, protocol function used, timing, volume, and queried information where available. Since the ATT&CK object notes that many protocols and devices support multiple ways to achieve similar reads, detection should focus on deviations from established baselines: new assets performing reads, changed read frequency or timing, unusual points or tags being queried, and shifts between single-point, multi-point, acknowledged, or non-acknowledged functions. No ATT&CK platforms or tactics were supplied, so local ICS architecture and protocol inventory are required to scope implementation.
Likely telemetry
- ICS automation protocol traffic metadata and decoded function usage where available
- Source and destination asset identifiers for read requests
- Point or tag request details, when logged or safely observable
- Read request volume, timing, and periodicity baselines
- Asset application logs showing point or tag access requests
Detection direction
- Build baselines for normal point/tag read behavior by asset role, protocol, function type, time window, and expected queried data.
- Alert on new or unexpected assets using read functions, especially when they query unusual information or operate outside normal timing patterns.
- Tune for legitimate polling, historian collection, HMI refreshes, engineering activity, and maintenance windows to reduce false positives.
- Look for changes in function selection that achieve the same read outcome, such as movement between single-point and multi-point reads or acknowledged and non-acknowledged variants.
- Confirm whether monitoring can parse the relevant ICS protocols; otherwise, detection may be limited to coarse flow or log-based anomalies.
Mitigation priorities
- Inventory expected ICS assets, protocols, and normal point/tag read relationships before relying on anomaly detection.
- Ensure passive ICS network monitoring and asset application logging are enabled where safe and operationally appropriate.
- Define approved read paths and expected roles for HMIs, historians, engineering workstations, controllers, and other OT systems.
- Integrate OT monitoring outputs into SOC and incident response workflows with escalation criteria agreed by operations teams.
- Review segmentation, access control, and change-management practices if unexpected assets are observed reading process data.
Analyst notes and limits
This is a detection analytic, not a technique description. The supplied ATT&CK content focuses on monitoring ICS automation protocols and asset application logs for anomalies in reading point or tag data. There are no supplied relationships, tactics, platforms, aliases, or official detection logic beyond the descriptive guidance, so implementation should be driven by local protocol use, asset roles, and operational baselines.
Coverage depends on protocol visibility, safe collection of OT telemetry, asset log availability, and the organization’s ability to baseline normal read behavior. The supplied object does not identify specific platforms, affected protocols, adversaries, campaigns, or confirmed exploitation, so no assumptions should be made about exposure or detection effectiveness without local evidence.
Analytic 1920
Monitor ICS automation protocols for anomalies related to reading point or tag data, such as new assets using these functions, changes in volume or timing, or unusual information being queried. Many protocols provide multiple ways to achieve the same result (e.g., functions with/without an acknowledgment or functions that operate on a single point vs. multiple points). Monitor for changes in the functions used. Monitor asset application logs which may provide information about requests for points or tags. Look for anomalies related to reading point or tag data, such as new assets using these functions, changes in volume or timing, or unusual information being queried. Many devices provide multiple ways to achieve the same result (e.g., functions with/without an acknowledgment or functions that operate on a single point vs. multiple points). Monitor for changes in the functions used.
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 | 375d802e856f… |
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 AN1920Open 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.