AN1860: Analytic 1860
Monitor ICS automation network protocols for functions related to reading an operational process state (e.g., “Read” function codes in protocols like DNP3 or Modbus). In some cases, there may be multiple ways to monitor an operational process’ state, one of which is typically used in the operational environment. Monitor for the operating mode being checked in unexpected ways. Monitor applications logs for any access attempts to operational databases (e.g., historians) or other sources of operational data within the ICS environment. These devices should be monitored for adversary collection using techniques relevant to the underlying technologies (e.g., Windows, Linux).
Analyst context for executives and security teams
This analytic is about knowing when someone or something is checking the state of an industrial process in an unusual way. For executives and security leaders, the business issue is not the “read” action by itself; it is whether the organization can distinguish normal operational visibility from unexpected collection of process data through ICS protocols, historians, databases, or other operational data sources.
Executive priority
Prioritize this as an ICS visibility and resilience question: do SOC and operations teams have evidence of who is reading process state, through which approved paths, and whether alternate or unexpected access methods would be noticed? This supports incident decision-making, compliance evidence for monitoring of critical operational environments, and cyber-physical risk management where process state data could inform later disruptive activity.
Technical view
Validate monitoring for ICS automation network protocol functions associated with reading operational state, including read-style function codes in protocols such as DNP3 or Modbus where present in the environment. Establish what the normal operational method is for checking operating mode or process state, then look for unexpected ways of performing the same checks. Also validate application logging for access attempts to operational databases, historians, and other ICS data sources, using monitoring appropriate to the underlying systems such as Windows or Linux where applicable.
Likely telemetry
- ICS automation network protocol traffic showing operational state read functions
- DNP3 or Modbus protocol metadata where those protocols are used
- Requests checking operating mode or process state
- Application logs from historians and operational databases
- Authentication and access logs for ICS operational data sources
Detection direction
- Define normal process-state read paths with operations/engineering teams before alerting on deviations.
- Tune for unexpected methods of checking operating mode, not merely high volumes of legitimate operational reads.
- Correlate protocol-level reads with application/database access to historians or other operational data repositories.
- Review false positives from engineering tools, maintenance activity, polling systems, and approved operator workflows.
- Identify blind spots where ICS protocol inspection, historian logging, or operational database access logs are unavailable or not forwarded to the SOC.
Mitigation priorities
- Inventory approved sources and methods for reading operational process state.
- Enable and retain logs for historians, operational databases, and other ICS data sources.
- Deploy or validate passive monitoring for relevant ICS automation protocols where feasible and safe for the environment.
- Coordinate detection logic with OT engineering to avoid disrupting normal operations and to define expected polling or read behavior.
- Use access control and segmentation reviews to limit who and what can query operational state data.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic in the ICS domain. Its value is strongest when converted into environment-specific baselines: which protocols exist, which systems normally read process state, and which operational data repositories should produce logs. No relationship context was supplied, so this take does not map the analytic to specific techniques, tactics, actors, or campaigns.
Official detection content is not provided, and the object lists no platforms, tactics, labels, aliases, or relationships. The references mention examples such as DNP3, Modbus, historians, Windows, and Linux, but local applicability depends on the actual ICS architecture and logging configuration. This summary does not imply active exploitation or existing detection coverage.
Analytic 1860
Monitor ICS automation network protocols for functions related to reading an operational process state (e.g., “Read” function codes in protocols like DNP3 or Modbus). In some cases, there may be multiple ways to monitor an operational process’ state, one of which is typically used in the operational environment. Monitor for the operating mode being checked in unexpected ways. Monitor applications logs for any access attempts to operational databases (e.g., historians) or other sources of operational data within the ICS environment. These devices should be monitored for adversary collection using techniques relevant to the underlying technologies (e.g., Windows, Linux).
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 | d73715431856… |
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 AN1860Open 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.