DET0788: Detection of Point & Tag Identification
DET0788 is an ICS detection strategy for identifying activity related to Point & Tag Identification, where an adversary collects point and tag values to un...
Analyst context for executives and security teams
DET0788 is an ICS detection strategy for identifying activity related to Point & Tag Identification, where an adversary collects point and tag values to understand how process variables map to the control environment. For business leaders, the concern is not just data access; in an industrial setting, tag context can help an intruder understand operations well enough to make later actions more precise and harder to triage.
Executive priority
Prioritize this as an ICS visibility and resilience question: do security, operations, and incident response teams know where point and tag definitions are stored, who can access them, and whether access is logged? The ATT&CK object does not provide a detection method, so the immediate value is in validating whether the organization has evidence to prove or disprove tag discovery during an incident.
Technical view
MITRE links this detection strategy to ICS technique T0861, Point & Tag Identification. Because the detection object has no official detection text, platforms, or tactics, SOC and IR teams should treat it as a coverage validation item: identify systems that expose point/tag values, confirm auditability of access and enumeration, and build detections around abnormal collection or browsing of tag metadata relative to normal engineering and operator workflows.
Likely telemetry
- HMI, SCADA, engineering workstation, historian, or other ICS application audit logs where available
- Authentication and session records for users or services accessing point/tag repositories
- Configuration, project, or tag database access logs where such repositories exist
- ICS network telemetry that can show unusual reads, browsing, or enumeration of point/tag-related data
- Change-management or engineering workflow records to distinguish expected maintenance from suspicious discovery
Detection direction
- First inventory where point and tag values are stored or queried; MITRE does not specify platforms for DET0788.
- Baseline normal operator, engineer, and service-account access to tag information, then look for unusual volume, timing, source, or account usage.
- Correlate tag access with authentication context and remote access paths to reduce false positives from legitimate engineering activity.
- Validate whether passive network monitoring or application logging can observe tag browsing or enumeration; many ICS environments may have limited native audit logs.
- Use the relationship to T0861 as the analytic scope: the goal is to detect collection of point/tag context that could map inputs, outputs, memory locations, and process variables to control processes.
Mitigation priorities
- Restrict access to point/tag repositories and engineering data to roles with operational need.
- Ensure logging is enabled and retained for systems that store or expose point/tag values.
- Separate routine operator visibility from engineering or administrative access where feasible.
- Review service accounts and shared accounts that can read tag data, because weak identity context limits incident reconstruction.
- Include point/tag data access in ICS incident response playbooks and compliance evidence collection.
Analyst notes and limits
This take is based on DET0788 and its relationship to T0861. The practical defensive focus is coverage validation: knowing whether the organization can observe access to point and tag information and distinguish normal engineering activity from abnormal collection.
The supplied ATT&CK detection strategy has no official description, detection guidance, tactics, or platforms. Recommendations are therefore conservative and must be validated against the local ICS architecture, logging capabilities, and operational workflows.
Detection of Point & Tag Identification
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0861 | Point & Tag Identification | This object detects Point & Tag Identification. |
All related ATT&CK context
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 | 53aa3d6696d3… |
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 DET0788Open 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.