[TTD] PLC Configuration Manipulation and Water/Wastewater Process-Control Disruption

Report Type: Threat-to-Detection
Threat Category: Operational Technology / Industrial Control System Manipulation
Assessment Date: August 05, 2026

Amendment Date: August 20, 2026
Primary Impact Domain: Water and Wastewater Process-Control Integrity
Secondary Impact Domains: Operational Disruption, Public Health, Environmental Compliance, Service Continuity, Process Safety, Regulatory Exposure
Affected Asset Class: PLCs, Remote Terminal Units, HMIs, SCADA Systems, Engineering Workstations, Historians, OT Remote-Access Infrastructure, Cellular Gateways, and Supporting Process-Control Systems
Threat Objective Classification: Unauthorized Controller Configuration Manipulation, Process-Control Disruption, Loss of View, Loss of Control, and Physical-Process Impact

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: August 05, 2026
Publication Type: Cybersecurity Research Report / White Paper

BLUF

‍  PLC configuration manipulation and water/wastewater process-control disruption create material business risk because unauthorized engineering access can become a path to controller logic modification, parameter manipulation, credential and network-setting changes, firmware activity, controller mode changes, HMI/SCADA manipulation, operator lockout, loss of view, loss of control, process deviation, manual-operation transition, and service disruption. The core risk is whether adversaries can alter trusted controller or supervisory-control behavior before the organization can validate engineering access, controller state, project integrity, configuration history, HMI/SCADA activity, process conditions, operator actions, maintenance context, and operational consequences. Immediate executive action is required to restrict engineering access, validate controller and HMI/SCADA integrity, preserve known-good projects and configurations, review unexplained changes, confirm safe operating conditions, and deploy behavior-led detection across industrial network, engineering, endpoint, controller, supervisory-control, historian, process, and operator telemetry.

Executive Risk Translation

PLC manipulation exposure shifts the business risk from routine OT access control or controller maintenance to uncertainty over whether critical treatment, pumping, storage, distribution, collection, and wastewater processes can still be trusted. If controller logic, parameters, credentials, network settings, firmware, operating modes, HMI/SCADA commands, alarms, process values, and operator access cannot be tied to reliable evidence, leadership may need to assume process-control trust was exposed until proven otherwise. That response can expand into emergency engineering review, controller and project comparison, facility-level operational validation, manual-operation preparation, remote-access restriction, credential rotation, process testing, regulatory consultation, service-continuity planning, customer or public communications, and executive reporting.

S5 Executive Risk Summary

Business Risk

PLC and HMI/SCADA manipulation can undermine process safety, treatment integrity, water-quality assurance, wastewater-control integrity, operator trust, service continuity, environmental compliance, operational resilience, and public confidence.

Technical Cause

The issue involves unauthorized or unexplained access to PLC, HMI, SCADA, engineering, remote-access, or controller-management functions followed by project transfer, logic change, parameter modification, credential change, network-setting change, firmware activity, reset, restore, operating-mode change, supervisory-control manipulation, or process-impact behavior. The durable detection issue is the sequence from abnormal access or engineering activity into confirmed controller change, critical latent risk, loss of control, process deviation, or multi-controller expansion.

Threat Posture

This is strategically significant for organizations that rely on PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, historians, cellular gateways, or remote-support infrastructure to operate drinking-water, wastewater, pumping, treatment, storage, distribution, collection, or related utility processes. It should be treated as process-control trust-boundary abuse, not as a narrow exposed-device, remote-access, protocol-write, or controller-maintenance issue.

Executive Decision Requirement

Leadership should require review of engineering and remote-access exposure, controller and HMI/SCADA integrity validation, comparison against known-good projects and configurations, verification of credentials and network settings, review of unexplained process changes, confirmation of safe operating conditions, preservation of relevant evidence, and deployment of the S25 detection logic across viable OT, endpoint, SIEM, and correlation platforms.

S6 Executive Cost Summary

PLC configuration manipulation and water/wastewater process-control disruption create financial exposure because the organization must determine whether unauthorized access was used to alter controller logic, process parameters, credentials, communications settings, firmware, operating modes, HMI/SCADA controls, alarms, or process behavior. The cost profile is higher than routine controller maintenance when affected systems support treatment, pumping, storage, distribution, wastewater collection, environmental control, safety functions, regulatory monitoring, or continuous public service.

Response cost is driven by affected-controller inventory, engineering access review, controller and project comparison, configuration and firmware validation, HMI/SCADA review, remote-access investigation, credential rotation, process testing, laboratory validation, operator support, manual-operation requirements, service-continuity measures, environmental review, regulatory engagement, and restoration of trusted operating baselines.

Low Impact Scenario

Rapid investigation confirms exposed or abnormal engineering access, suspicious authentication, an unusual remote-access path, or another access-stage concern without evidence that a PLC project was transferred or that controller, HMI/SCADA, or process-control changes occurred. Response remains limited to access restriction, credential and session review, targeted log analysis, controller and engineering-source validation, maintenance-record reconciliation, short-term monitoring, and executive assurance.

Where suspicious PLC project upload is identified without evidence of subsequent manipulation, response must also validate the affected controller and project scope, source and user authorization, project destination, transfer path, collection volume, multi-controller activity, external transfer, known-good project integrity, remote-access context, and related credentials. The event remains within the Low Impact Scenario only when this expanded validation confirms that no unauthorized project modification, download, deployment, credential exposure, controller change, or process impact occurred. Estimated impact $50K - $250K.

Moderate Impact Scenario

Confirmed or strongly suspected unauthorized manipulation affects one or more controllers, HMIs, SCADA systems, engineering workstations, or process areas and includes project download, online edit, parameter change, credential or network-setting modification, controller mode change, alarm or set-point manipulation, loss of visibility, controller instability, or uncertainty over treatment or wastewater-process integrity. Response may require emergency engineering support, controller and project forensics, credential rotation, network reconfiguration, HMI/SCADA validation, process testing, laboratory sampling, manual-operation preparation, regulatory consultation, and extended operational monitoring. Estimated impact $250K - $2.5M.

High Impact Scenario

PLC or supervisory-control abuse becomes an enterprise-impact event when there is confirmed manipulation of treatment-critical or safety-relevant logic, chemical-dosing limits, interlocks, permissives, protection functions, pressure, flow, level, sequencing, alarms, or multiple controllers; loss of control or operator access; unsafe or threshold-confirmed process deviation; boil-water response; wastewater-release concern; prolonged manual operations; service interruption; environmental impact; or public-health consequences. Response may require controller rebuilds, facility shutdown or reduced operations, emergency water or wastewater measures, broad engineering validation, laboratory and field testing, outside specialist support, regulatory reporting, legal review, customer or public communications, infrastructure restoration, and board-level oversight. Estimated impact $2M - $15M+.

S6A Key Cost Drivers

·        Number, location, and operational importance of affected PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, process areas, facilities, and sites.

·        Whether affected systems support drinking-water treatment, chemical dosing, pumping, storage, distribution, wastewater collection, aeration, disinfection, discharge control, safety functions, or regulatory monitoring.

·        Evidence of project upload, project download, online edit, logic change, parameter modification, credential change, network-setting change, firmware activity, controller reset, project restore, operating-mode change, alarm suppression, set-point manipulation, manual-command activity, or operator lockout.

·        Scope, destination, transfer path, and collection volume of suspicious PLC project uploads, including whether multiple controllers or external destinations were involved.

·        Whether unauthorized changes affect treatment-critical or safety-relevant logic, interlocks, permissives, protection functions, chemical-dosing limits, pressure, flow, level, sequencing, or water-quality parameters.

·        Availability of controller audit logs, engineering logs, industrial NDR telemetry, HMI/SCADA logs, historian data, endpoint telemetry, remote-access logs, operator records, laboratory results, work orders, and known-good project or configuration baselines.

·        Scope of controller, HMI/SCADA, remote-access, engineering, vendor, integrator, and administrative credentials requiring review or rotation.

·        Completeness of approved engineering-source, user, project, controller-scope, maintenance-window, work-order, process-threshold, and asset-relationship records.

·        Need for emergency engineering support, controller comparison, project reconstruction, firmware validation, process testing, laboratory sampling, field inspection, or outside control-system specialists.

·        Business disruption caused by manual operations, process shutdown, reduced treatment capacity, service interruption, emergency water supply, wastewater-containment measures, or delayed restoration.

·        Environmental, public-health, customer, contractual, regulatory, legal, insurance, or board-level exposure when safe operation, water quality, discharge integrity, or service continuity cannot be proven.

S6B Compliance and Risk Context

PLC configuration manipulation and water/wastewater process-control disruption may create regulatory, environmental, public-health, operational-resilience, emergency-management, customer-notification, contractual, legal, or governance exposure when treatment integrity, wastewater-control integrity, process safety, water quality, discharge conditions, operator access, or service continuity are affected or cannot be reliably validated.

For water and wastewater environments, the core governance question is whether the organization can prove that controller logic, process parameters, credentials, network settings, firmware, operating modes, HMI/SCADA controls, alarms, operator actions, process values, laboratory results, and service conditions remained authorized and within approved boundaries during the exposure window.

Risk Register Entry

Risk Title

PLC Configuration Manipulation and Water/Wastewater Process-Control Disruption

Risk Description

Unauthorized or unexplained engineering access may create a path to PLC project transfer, logic modification, parameter manipulation, credential or network-setting changes, firmware activity, controller reset or mode change, HMI/SCADA manipulation, alarm suppression, operator lockout, loss of control, process deviation, manual-operation transition, environmental impact, or service disruption.

Likelihood

Medium-High

Impact

Critical

Risk Rating

Critical

Annualized Risk Exposure

Estimated $250K - $2.5M+ for materially exposed water and wastewater environments with internet-accessible or weakly governed remote access, shared or vendor credentials, incomplete engineering records, limited controller audit telemetry, missing known-good projects, weak HMI/SCADA logging, incomplete process-threshold validation, or insufficient controller-to-process relationship mapping. Exposure may exceed $2M - $15M+ where manipulation affects treatment-critical or safety-relevant logic, chemical dosing, interlocks, permissives, protection functions, multiple controllers, water quality, wastewater discharge, operator control, service continuity, public health, environmental obligations, legal review, customer or public communications, or board-level reporting.

S10 Threat Overview

PLC configuration manipulation and water/wastewater process-control disruption involve unauthorized or unexplained engineering access followed by PLC project transfer, logic modification, parameter changes, credential or network-setting changes, firmware activity, controller reset or restore, operating-mode changes, HMI/SCADA manipulation, or process-control impact.

The activity becomes materially significant because PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, historians, and remote-access systems may directly influence treatment, pumping, chemical dosing, storage, distribution, wastewater collection, aeration, disinfection, discharge control, alarms, safety functions, and operator decision-making.

An adversary who gains access to an engineering workstation, controller-management path, HMI, SCADA server, OT jump host, remote-support system, cellular gateway, or trusted vendor connection may convert that access into unauthorized controller change, loss of operational visibility, operator lockout, process deviation, environmental impact, or service disruption.

This TTD treats the activity as PLC configuration manipulation and process-control trust abuse, not as a narrow exposed-device, remote-access, default-password, protocol-write, controller-vulnerability, or patching event.

S17 MITRE ATT&CK Chain Flow Mapping

Stage 1: Remote Access to the Engineering or Control Environment

The adversary uses a remote-access, vendor-support, jump-host, cellular, engineering, HMI, SCADA, or controller-management path to reach the control environment.

·        T0886 Remote Services.

·        T0859 Valid Accounts, applied where legitimate, shared, default, vendor, contractor, integrator, or compromised credentials are used.

Stage 2: PLC Project Collection

The adversary retrieves a PLC project to understand controller logic, process relationships, parameters, sequencing, or available modification paths.

·        T0845 Program Upload, applied when a project is transferred from a controller to an engineering or intermediary system.

Stage 3: Controller Program or Parameter Modification

The adversary transfers or changes controller logic, tasking, routines, function blocks, configuration, or operational parameters.

·        T0843 Program Download, including full download, online edit, or program append where observed.

·        T0889 Modify Program.

·        T0836 Modify Parameter.

Stage 4: Physical-Process or Operator-View Manipulation

The adversary uses controller or supervisory-control changes to alter process behavior, set points, commands, alarms, displayed values, or operator understanding.

·        T0831 Manipulation of Control.

·        T0832 Manipulation of View, applied only where HMI, SCADA, historian, alarm, or displayed process information is altered or suppressed.

Conditional Technique Notes

T0821 Modify Controller Tasking should only be added when task associations, execution intervals, priorities, scheduling, or controller execution order are specifically changed.

Techniques for firmware modification, operating-mode change, alarm suppression, credential change, device restart or shutdown, denial of control, denial of view, loss of safety, or service interruption should only be added when the corresponding behavior is confirmed in the active incident or source material.

Generic enterprise discovery, scripting, persistence, credential-access, command-and-control, and exfiltration techniques are not included because they are not required to explain the durable PLC manipulation chain.

S18 Attack Path Narrative

An attacker reaches an engineering workstation, HMI, SCADA system, OT jump host, remote-access service, cellular gateway, vendor-support system, or controller-management interface.

The attacker authenticates through stolen, shared, default, dormant, vendor, contractor, integrator, or otherwise weakly governed credentials, or abuses an exposed engineering or remote-management path.

The attacker identifies reachable PLCs, remote terminal units, engineering applications, available projects, HMI/SCADA systems, process areas, and controller-management functions.

The attacker accesses engineering software, controller-management functions, project repositories, remote sessions, or administrative interfaces.

The attacker may upload PLC projects for collection, comparison, reconnaissance, preparation, or theft.

The attacker downloads a modified project or performs an online edit, program append, logic change, task or routine change, parameter change, credential change, network-setting change, firmware action, controller reset, project restore, or operating-mode change.

The attacker may modify HMI or SCADA set points, alarms, alarm thresholds, displays, tags, administrative settings, accounts, control modes, scripts, macros, or manual commands.

The controller or supervisory-control changes may cause communications loss, controller fault, operator lockout, loss of view, loss of control, stale or inconsistent process data, abnormal equipment behavior, or process deviation.

The activity may expand across multiple controllers, process areas, facilities, sites, or controller vendors through a shared engineering workstation, user, remote-access session, project, artifact, or repeated change pattern.

Operational consequences may include manual-operation transition, reduced treatment capacity, process shutdown, boil-water response, wastewater-release concern, environmental impact, service interruption, or public-health risk.

Defenders should detect this through correlated remote-access, engineering, controller-state, HMI/SCADA, endpoint, historian, sensor, operator, laboratory, maintenance, and process evidence rather than relying on isolated protocol commands, exposed-device findings, endpoint events, or process anomalies.

S20 TTP Analysis

Initial Access

Initial access may occur through remote-access services, VPN infrastructure, cellular gateways, vendor-support paths, OT jump hosts, exposed controller-management interfaces, internet-facing HMI or SCADA services, compromised engineering workstations, or direct local access.

Attackers may use stolen, shared, default, dormant, contractor, vendor, integrator, local-administrator, or otherwise weakly governed credentials.

Execution

Execution may occur through PLC engineering software, controller-management utilities, HMI or SCADA administrative tools, vendor utilities, firmware-management applications, project-transfer functions, online editing, program append, manual commands, or supporting command and scripting activity on engineering or OT-support systems.

Persistence

Persistence may occur through new or modified remote-access tools, services, scheduled tasks, startup entries, scripts, macros, plugins, accounts, tokens, certificates, trusted devices, HMI projects, engineering projects, hidden controller routines, dormant logic, delayed conditions, alternate execution paths, or altered backup and recovery artifacts.

Privilege Escalation

Privilege escalation may occur through privileged engineering accounts, controller administrator credentials, HMI or SCADA administrative accounts, local-administrator access, vendor-support privileges, shared engineering accounts, service accounts, or exploitation of OT-supporting applications.

Defense Evasion

Attackers may blend into legitimate engineering, maintenance, commissioning, backup, recovery, troubleshooting, integrator, or emergency-operation workflows.

They may use approved engineering applications, trusted remote-access paths, normal project-transfer functions, expected protocol services, shared accounts, broad maintenance windows, or familiar controller-management commands.

Defense evasion may also involve disabling alarms, modifying HMI displays, altering historian values, deleting engineering records, corrupting known-good projects, removing backups, modifying change records, or creating hidden and conditionally activated controller logic.

Credential Access

Attackers may access engineering credentials, controller passwords, HMI or SCADA accounts, remote-access credentials, VPN credentials, vendor credentials, integrator credentials, local-administrator accounts, service accounts, tokens, certificates, password files, project files containing secrets, browser credentials, vault data, or stored connection profiles.

Discovery

Attackers may inspect controllers, remote terminal units, HMIs, SCADA servers, engineering workstations, historians, OT jump hosts, cellular gateways, remote-access systems, users, accounts, controller models, firmware versions, network zones, programming services, projects, configurations, process areas, tags, alarms, set points, interlocks, permissives, safety functions, remote-I/O relationships, and facility dependencies.

Collection

Attackers may collect PLC projects, controller configurations, firmware images, HMI projects, SCADA configurations, process diagrams, network diagrams, screenshots, historian data, alarm history, operator records, credentials, project repositories, known-good backups, or engineering documentation.

Lateral Movement

Lateral movement may occur through shared engineering workstations, OT jump hosts, remote-access systems, HMI or SCADA servers, vendor-support systems, common credentials, controller-management services, file shares, remote administration, cross-site engineering paths, or centralized management infrastructure.

Command and Control

Command and control may use remote-access tools, VPN sessions, remote desktop, remote shells, vendor-support infrastructure, encrypted tunnels, cellular connections, consumer remote-access services, proxy infrastructure, or outbound communications from engineering workstations, HMIs, SCADA servers, historians, jump hosts, or gateways.

Exfiltration

Attackers may transfer PLC projects, controller configurations, firmware, process diagrams, network diagrams, credentials, screenshots, historian data, laboratory data, engineering documentation, or related operational information to external or unapproved destinations.

Impact

Attackers may alter controller logic, parameters, credentials, network settings, firmware, operating modes, HMI/SCADA controls, alarms, set points, tags, manual commands, interlocks, permissives, protection conditions, chemical-dosing limits, pressure, flow, level, sequencing, or treatment behavior.

Impact may include controller fault, communications loss, operator lockout, loss of view, loss of control, abnormal equipment behavior, unsafe or threshold-confirmed process deviation, manual-operation transition, process shutdown, reduced treatment capacity, boil-water response, wastewater-release concern, environmental impact, service interruption, or public-health consequences.

S20A — Adversary Tradecraft Summary

The durable tradecraft pattern is process-control trust conversion: unauthorized access to an engineering, remote-access, HMI/SCADA, or controller-management path is used to collect or alter PLC projects, modify controller or supervisory-control behavior, suppress or distort operational visibility, and affect one or more physical processes. Detection should focus on the sequence from access through engineering activity, controller change, HMI/SCADA behavior, controller-state change, process deviation, and operational consequence rather than a single protocol command, exposed device, default credential, CVE, vendor, actor name, project filename, or proof-of-concept artifact.

S21 Detection Strategy Overview

Detection Philosophy

Detect unauthorized PLC and water/wastewater process-control manipulation through correlated access, engineering, controller-state, HMI/SCADA, and process behavior rather than through isolated network connections, exposed-device findings, individual protocol commands, or single endpoint events.

The durable detection object is unauthorized or unexplained change to controller logic, configuration, operating mode, network settings, credentials, HMI/SCADA control, alarms, or process parameters that affects or could affect treatment, pumping, storage, distribution, wastewater collection, or related operational processes.

Primary Detection Anchors

·        Access to PLCs, HMIs, SCADA systems, engineering workstations, OT jump hosts, remote-access systems, or cellular gateways from unauthorized, unusual, newly observed, internet-originating, or non-engineering sources.

·        PLC project upload, project download, full program download, online edit, program append, task change, routine change, function-block change, logic change, parameter change, firmware update, firmware replacement, or firmware-update-mode activation.

·        Controller password, account, privilege, IP address, subnet, gateway, communications, protocol, remote-access, or management-setting modification.

·        Controller operating-mode changes involving Run, Program, Remote Program, Stop, maintenance, firmware-update, or equivalent vendor-specific states.

·        Unexpected controller stop, restart, reset, fault, communications loss, configuration mismatch, logic checksum change, project-signature change, or operator lockout.

·        HMI or SCADA changes involving set points, alarms, alarm thresholds, alarm suppression, administrative settings, operator accounts, process displays, tag values, or manual commands.

·        Physical-process deviation following controller, engineering, or HMI/SCADA activity.

·        Transition to manual operations, process shutdown, boil-water notice, service interruption, wastewater-release concern, or another documented operational consequence.

Detection Prioritization Model

Prioritize activity where an abnormal access path or unauthorized engineering source is followed within a bounded time window by one or more of the following:

·        PLC project, logic, task, routine, function-block, parameter, firmware, credential, network, or operating-mode change.

·        HMI or SCADA administrative, alarm, display, set-point, tag, or command modification.

·        Controller fault, communications loss, project mismatch, or operator lockout.

·        Process-value deviation outside approved engineering, safety, operating, or water-quality boundaries.

·        Manual-operation transition or documented service impact.

High confidence normally requires multiple evidence layers unless authoritative controller, engineering, or configuration-integrity evidence independently confirms an unauthorized change.

Authoritative evidence may include a vendor-confirmed or cryptographically validated unauthorized program download, online edit, project change, controller-password change, controller IP-address change, firmware change, or configuration-integrity mismatch.

Critical severity applies when any of the following are confirmed:

·        Unauthorized modification of safety-critical or treatment-critical logic.

·        Hidden, dormant, delayed, or conditionally activated controller logic.

·        Interlock, permissive, alarm, or protection bypass.

·        Unauthorized chemical-dosing, treatment-limit, pressure, flow, level, or sequencing changes.

·        Malicious project download with unresolved latent process consequences.

·        Changes affecting multiple controllers, process areas, facilities, or sites.

·        Loss of control, loss of view, operator lockout, abnormal equipment operation, threshold-confirmed unsafe deviation, manual-operation transition, or service impact.

Correlation Strategy (Strict Enforcement)

Do not promote an isolated OT protocol connection, controller scan, failed login, exposed-device finding, HMI session, engineering-software execution, controller restart, alarm event, set-point change, or process deviation to confirmed malicious PLC manipulation without supporting evidence.

High-confidence correlation should normally combine at least two of the following evidence layers unless authoritative change evidence independently confirms manipulation:

·        Access or source-path evidence.

·        Engineering or controller-change evidence.

·        Controller-state evidence.

·        HMI/SCADA evidence.

·        Physical-process evidence.

·        Change-management or operator-confirmation evidence.

Process anomalies without cyber or engineering evidence should remain operational-investigation signals.

Cyber or engineering changes without observed process impact may still justify high or critical severity when they affect treatment-critical logic, safety-relevant conditions, latent execution paths, interlocks, permissives, protection logic, dosing parameters, or multiple controllers.

Telemetry Prioritization

Prioritize authoritative evidence first:

·        PLC, controller, and vendor engineering-software audit records where supported.

·        Controller project, logic, task, routine, function-block, parameter, configuration, firmware, checksum, and signature comparison records.

·        HMI and SCADA application, operator, command, alarm, tag-change, and administrative logs.

·        Historian and process-value telemetry.

Use the following as supporting and correlation evidence:

·        OT-aware NDR telemetry with industrial protocol, service, function, command, session, and asset-role visibility.

·        OT remote-access, VPN, firewall, cellular gateway, jump-host, and privileged-access telemetry.

·        Engineering-workstation and OT-support-server process, file, removable-media, authentication, and network telemetry.

·        Asset inventory, network-zone, approved engineering-path, maintenance-window, and change-management records.

·        Operator shift logs, manual-operation records, laboratory results, work orders, alarm-response records, and incident records.

Pure NetFlow, generic firewall logs, endpoint telemetry, cloud logs, or identity events alone cannot directly establish PLC logic or process modification.

Detection Design Constraints

·        Avoid detection designs based only on an actor name, campaign name, CVE, PLC vendor, product model, default port, default password, IP address, IOC, exploit string, or internet-exposure result.

·        Do not assume all programming traffic is malicious; approved engineering, integrator, maintenance, commissioning, backup, recovery, and troubleshooting activity may produce similar behavior.

·        Do not assume a controller restart, mode change, checksum difference, set-point change, or alarm suppression is malicious without validating change and operational context.

·        Do not use generic IT endpoint, cloud, identity, or network anomalies as direct proof of PLC logic modification.

·        Do not treat HMI display changes as proof that controller logic or the field process changed unless controller or process evidence supports that conclusion.

·        Do not infer unsafe operating or water-quality conditions from cyber telemetry alone. An approved engineering, safety, operating, laboratory, or water-quality threshold must establish the condition.

·        Keep vendor-specific protocol commands, event codes, project formats, and engineering actions in local mappings rather than creating a false universal PLC schema.

·        Preserve the distinction between attempted access, successful access, unauthorized engineering activity, controller manipulation, process manipulation, and confirmed operational impact.

Baseline and Deployment Requirements

·        Baseline PLCs, remote terminal units, HMIs, SCADA servers, engineering workstations, historians, cellular gateways, OT jump hosts, remote-access systems, and associated network zones.

·        Baseline approved engineering sources, operator stations, administrator accounts, service accounts, integrator systems, vendor-support paths, and remote-access paths.

·        Baseline expected industrial protocols, programming services, controller peers, engineering paths, polling patterns, process communications, and controller operating modes.

·        Maintain known-good PLC projects, logic versions, controller parameters, firmware versions, configurations, checksums, and signatures where supported.

·        Baseline approved HMI screens, alarm configurations, tag mappings, operator roles, set-point ranges, manual-command patterns, and administrative settings.

·        Define approved operating ranges and rate-of-change boundaries for critical process variables.

·        Maintain approved maintenance windows, work orders, change tickets, commissioning events, emergency changes, firmware updates, logic downloads, and process-testing windows.

·        Validate time synchronization or document timestamp offsets across controllers, engineering systems, HMI/SCADA systems, historians, NDR sensors, remote-access systems, and SIEM platforms.

Variant Resilience Requirements

Detection logic should remain useful across future PLC vendors, controller families, engineering applications, remote-access methods, and water/wastewater operating environments when the behavior remains consistent:

·        Unauthorized or abnormal access.

·        Engineering or configuration activity.

·        Controller logic, task, parameter, credential, network, firmware, or mode change.

·        HMI/SCADA display, alarm, account, set-point, tag, or command manipulation.

·        Controller fault, operator lockout, or communications loss.

·        Physical-process deviation or service impact.

Rules should model controller and process behavior rather than depend on one vendor command, protocol offset, project filename, advisory, campaign, or proof-of-concept artifact.

Operational Detection Model

·        Begin with passive discovery and hunt-mode analytics.

·        Validate controller identities, network zones, protocol parsers, engineering sources, user mappings, project identifiers, process tags, and change records.

·        Test logic against approved maintenance, commissioning, integrator, backup, recovery, and emergency-operation activity.

·        Tune asset-specific and process-specific thresholds rather than applying one threshold across all facilities.

·        Validate whether process deviations represent cyber activity, equipment malfunction, sensor failure, operator action, maintenance, environmental conditions, or legitimate process response.

·        Ensure alert output identifies the controller, source, user, engineering workstation, project, changed object, prior value, new value, operating mode, process area, and observed consequence where available.

·        Promote to alert mode only after joins, baselines, exceptions, maintenance handling, process thresholds, and OT escalation workflows have been validated.

·        Use safety-preserving response procedures. Detection logic must not automatically stop controllers, alter process states, block communications required for monitoring, control, protection, or safe manual operation, or interrupt treatment without approved engineering and operational safeguards.

Explicit Non-Deployment Guardrails

·        Do not alert on every PLC write, program download, online edit, mode change, HMI command, alarm acknowledgement, or set-point change.

·        Do not represent internet exposure, default credentials, scanning, or version status as successful manipulation.

·        Do not claim PLC modification from engineering-software execution alone without project, controller, network, or audit evidence.

·        Do not claim physical-process impact without historian, sensor, HMI, alarm, operator, laboratory, or process evidence.

·        Do not use generic endpoint-only, cloud-only, identity-only, or flow-only detections as direct PLC manipulation detections.

·        Do not automate containment that could create unsafe operating conditions, interrupt treatment, disable visibility, or prevent safe manual control.

·        Do not suppress unexplained controller changes solely because they occur during a broad maintenance window. Validate the source, user, controller, project, changed object, work order, and expected process effect.

Figure 1 — PLC Manipulation Detection and Process-Impact Correlation Model

S22 Primary Detection Signals

Primary Detection Signals

·        PLC project upload, project download, full program download, online edit, program append, project restore, task change, routine change, function-block change, logic change, tag change, parameter change, firmware update, firmware replacement, or firmware-update-mode activation.

·        Controller project hash, logic checksum, task structure, routine structure, parameter set, firmware state, or configuration state differing from the approved version.

·        Programming or configuration activity from an unauthorized engineering workstation, HMI, jump host, remote-access source, cellular path, IT-network source, internet source, or newly observed internal source.

·        Programming or administrative activity involving an unexpected, shared, default, dormant, newly created, disabled, vendor, or out-of-pattern account.

·        Controller password, privilege, IP address, subnet, gateway, communications, protocol, remote-access, or management-setting modification.

·        Controller mode change into Program, Remote Program, Stop, maintenance, firmware-update, or another engineering-enabled state outside approved activity.

·        Unexpected controller stop, restart, reset, fault, memory clear, communications loss, project mismatch, or operator lockout.

·        HMI or SCADA modification involving set points, manual commands, alarms, alarm thresholds, alarm suppression, administrative passwords, operator accounts, displays, tags, or control modes.

·        Controller, HMI, or engineering activity followed by process deviation outside approved operating boundaries.

·        Unapproved controller or HMI change followed by manual operations, process shutdown, boil-water notice, service interruption, wastewater-release concern, or another operational consequence.

Supporting Detection Signals

·        First-seen or rare source communicating with PLC programming, management, HMI, SCADA, remote-access, or cellular-management services.

·        IT-to-OT, internet-to-OT, vendor-to-OT, cellular-to-OT, or cross-site traffic outside the approved architecture.

·        Authentication from an unexpected source, device, account, location, time, or remote-access path.

·        Failed authentication followed by successful PLC, HMI, SCADA, VPN, or engineering access.

·        Engineering software launched on a non-engineering asset or by an unauthorized user.

·        PLC project, configuration, firmware, or engineering files created, modified, copied, compressed, exported, or transferred outside approved workflows.

·        Remote desktop, remote-management, VPN, screen-sharing, or vendor-support access to an engineering workstation or HMI before controller activity.

·        New services, scheduled tasks, remote-access tools, scripting engines, transfer tools, credential utilities, or suspicious processes on engineering workstations or OT-support systems.

·        Changes to controller inventories, approved source lists, firewall rules, remote-access policies, NAT rules, cellular settings, or jump-host configurations.

·        Missing known-good projects, unavailable backups, or inability to reconcile the running controller state with the approved repository.

Access and Unauthorized Engineering Signals

·        Internet-originating or non-OT access to PLC, HMI, SCADA, engineering, VPN, remote-access, or cellular-management services.

·        Use of default, shared, dormant, contractor, vendor, or weakly governed credentials.

·        Authentication attempts against multiple PLCs, HMIs, process areas, or facilities from the same source.

·        Scanner-like enumeration followed by successful authentication or engineering activity.

·        Connections to vendor-specific programming services from systems that do not normally perform engineering work.

·        Repeated protocol errors, unsupported service requests, or controller exceptions near successful administrative activity.

·        Access through unexpectedly exposed cellular modems, port forwards, unmanaged gateways, or alternate remote-management paths.

·        Remote access followed by project download, mode change, password change, IP-address change, HMI manipulation, or operator lockout.

Controller and Process-Impact Signals

·        Creation, deletion, renaming, reordering, or modification of tasks, routines, programs, function blocks, data blocks, tags, variables, timers, counters, interlocks, permissives, or sequencing logic.

·        Changes to scan rate, task priority, task interval, execution order, scaling values, limits, set points, timer values, treatment rates, pressure targets, flow targets, equipment sequencing, or duty cycles.

·        Forced inputs, forced outputs, bypassed interlocks, disabled permissives, suppressed alarms, overridden protection conditions, or unexpected manual commands.

·        Controller reset, memory clear, factory reset, project restore, failed program download, interrupted download, or partial configuration.

·        Controller network or credential change followed by loss of management, communications, visibility, or legitimate operator access.

·        HMI or SCADA values inconsistent with controller state, historian data, redundant sensors, laboratory results, field observations, or calculated process expectations.

·        Process-variable or equipment-state deviation occurring shortly after controller, HMI, set-point, logic, parameter, network, credential, or mode changes.

·        Threshold-confirmed abnormal pump, valve, blower, dosing, level, flow, pressure, water-quality, aeration, treatment-sequence, or wastewater-process behavior.

·        Multiple related process variables changing in a physically inconsistent manner.

·        Manual-operation transition or service-impact response following unexplained OT activity.

Outbound Communication Signals

·        Engineering workstations, HMIs, SCADA servers, historians, OT jump hosts, or gateways communicating with newly observed, rare, suspicious, or unapproved destinations.

·        PLCs initiating outbound communication inconsistent with their approved role.

·        DNS activity from OT assets that normally use fixed addressing or do not perform DNS resolution.

·        Remote-access sessions routed through unapproved relays, consumer remote-access services, anonymization infrastructure, or newly registered domains.

·        Transfer of PLC projects, configurations, firmware, process diagrams, network diagrams, screenshots, historian data, or credentials from OT-support systems.

·        Unusual communication between facilities, sites, or process areas that do not normally exchange engineering traffic.

Persistence and Continued-Access Signals (Conditional)

·        New or modified PLC, HMI, SCADA, engineering, VPN, remote-access, local administrator, vendor, or integrator accounts.

·        New remote-access tools, services, scheduled tasks, scripts, tunnels, tokens, certificates, or trusted devices on engineering or OT-support systems.

·        Modified controller logic containing hidden routines, dormant conditions, delayed triggers, unauthorized communications, or alternate execution paths.

·        Modified HMI projects, startup screens, alarm settings, scripts, macros, or administrative configurations.

·        Replacement, removal, or corruption of known-good PLC projects, backups, configuration repositories, or change records.

Controller-to-Controller and Facility Expansion Signals (Conditional)

·        One engineering source initiating programming or administrative connections to multiple controllers outside its approved scope.

·        Shared engineering, vendor, or integrator credentials used across multiple sites or facilities.

·        Controller discovery or programming activity expanding across OT zones.

·        Similar logic, parameter, password, IP-address, HMI, alarm, or account changes appearing across multiple controllers or facilities.

·        Project, configuration, firmware, or engineering artifacts copied into additional controller environments.

·        Synchronized disruption or manipulation affecting multiple process areas, sites, or water/wastewater facilities.

Signal Usage Constraints

·        Do not treat one connection, protocol write, login, project transfer, mode change, set-point change, alarm event, or process anomaly as compromise confirmation.

·        Promote confidence when evidence aligns by controller, engineering workstation, HMI/SCADA system, source, user, remote-access session, project, changed object, process area, and time window.

·        Require change-management validation before assigning malicious intent to engineering activity.

·        Require controller, HMI/SCADA, historian, operator, laboratory, or process evidence before claiming operational impact.

·        Allow authoritative controller, engineering, or integrity evidence to independently confirm unauthorized manipulation when sufficiently reliable.

·        Distinguish attempted access, successful access, unauthorized engineering activity, controller manipulation, latent process risk, process manipulation, and confirmed service impact.

S23 Telemetry Requirements

Required Telemetry

Minimum viable detection requires:

·        OT-aware industrial network telemetry or controller and engineering audit telemetry.

·        Controller and OT asset inventory.

·        Approved engineering-source, user, and change-control records.

·        HMI/SCADA or historian and process telemetry.

·        Remote-access visibility where remote engineering, vendor support, cellular access, or cross-site administration is permitted.

A facility may achieve viable detection without every source listed below, but confidence and coverage improve as controller, engineering, HMI/SCADA, process, endpoint, and remote-access evidence are combined.

Strongly Recommended Telemetry

·        PLC and controller audit logs where supported.

·        Vendor engineering-software audit, session, project-transfer, and change logs where supported.

·        OT-aware NDR with industrial protocol, command, function, session, and asset-role visibility.

·        Known-good controller project, logic, configuration, firmware, parameter, checksum, or signature records where supported.

·        HMI application, operator, command, alarm, tag-change, and administrative logs.

·        SCADA application, command, authentication, alarm, and configuration logs.

·        Historian data for critical process variables.

·        Engineering-workstation process, file, removable-media, authentication, and network telemetry.

·        OT jump-host and remote-access telemetry.

·        VPN, firewall, router, switch, cellular-gateway, and privileged-access logs.

·        PLC project repository and configuration-management records.

·        File-integrity or project-difference monitoring for PLC, HMI, and SCADA artifacts.

·        Operator shift logs, manual-operation records, alarm-response records, work orders, laboratory results, and incident records.

·        Equipment-state, field-device, remote-I/O, motor-control, drive, actuator, and redundant-sensor telemetry where available.

·        Asset criticality, process-safety classification, and approved operating-boundary records.

Local Mapping Required

Map the following fields where supported by the local PLC, HMI, SCADA, engineering, network, endpoint, and historian platforms:

·        Facility, site, process area, treatment stage, and asset criticality.

·        Controller identifier, IP address, make, model, firmware, role, network zone, and process association.

·        Engineering workstation, HMI, SCADA, historian, OT jump host, gateway, and remote-access system identifiers.

·        Engineering software, session, project, project version, project hash, logic checksum, configuration checksum, and firmware state.

·        Controller action, engineering action, command, function, service, protocol, program-download type, and operating mode.

·        Changed object, including task, routine, program, function block, tag, parameter, set point, account, credential, network setting, alarm, or configuration.

·        Prior value, new value, prior mode, new mode, and change result.

·        Source and destination IP addresses, ports, assets, users, roles, network zones, and remote-access sessions.

·        HMI/SCADA action, operator station, alarm state, tag value, manual command, and administrative action.

·        Process variable, engineering unit, approved range, rate of change, threshold status, equipment state, and process consequence.

·        Maintenance-window, work-order, change-ticket, approved-source, approved-user, vendor, integrator, emergency-change, and expected-process-effect status.

·        Controller-fault, communications-loss, operator-lockout, manual-operation, process-threshold-breach, and service-impact status.

·        Event time, first-seen time, last-seen time, and time-source confidence.

S24 Detection Opportunities and Gaps

Detection Opportunities

·        Industrial protocol monitoring can identify controller programming, project transfer, write, mode-change, reset, firmware, and configuration activity when the protocol is visible and correctly parsed.

·        Controller and engineering logs can identify the user, source, session, project, changed object, download type, operating mode, and result where supported.

·        Comparison against known-good projects, configurations, firmware, parameters, checksums, or signatures can reveal unauthorized change when the access path is unknown.

·        Engineering-workstation telemetry can reveal unauthorized programming software, project-file manipulation, remote access, removable-media use, credential activity, scripting, or file transfer.

·        HMI and SCADA telemetry can reveal set-point manipulation, alarm suppression, administrative changes, manual commands, account changes, display manipulation, or operator lockout.

·        Historian, sensor, laboratory, and process telemetry can demonstrate whether controller or HMI activity produced an operational effect.

·        Remote-access, VPN, cellular, firewall, jump-host, and privileged-access records can identify the source path into the control environment.

·        Change-management and work-order records can distinguish approved engineering work from unexplained change.

·        Cross-site comparison can identify repeated password, IP-address, logic, HMI, alarm, or process manipulation across multiple facilities.

·        Operator records and manual-operation transitions can provide operational-impact evidence when electronic telemetry is incomplete.

Detection Gaps

·        Many PLCs provide limited, volatile, vendor-specific, or no security and change audit logs.

·        Industrial protocols may be unauthenticated, proprietary, encrypted, encapsulated, or incompletely parsed.

·        Passive monitoring may identify a write or download without revealing the semantic effect of changed logic.

·        Online edits and appended logic may not immediately interrupt controller operations or produce visible process effects.

·        Known-good projects, running logic, configurations, and approved versions may not be centrally stored or version controlled.

·        Engineering logs may be local-only, incomplete, or difficult to centralize.

·        Shared accounts, unmanaged integrator systems, vendor support, or direct cellular access may reduce attribution and bypass enterprise visibility.

·        HMI displays, historian data, and controller state may disagree or rely on the same manipulated data source.

·        Sensor failure, equipment malfunction, maintenance, environmental conditions, and operator error may resemble cyber-induced process deviation.

·        Physical effects may be delayed, conditional, or dependent on later process states.

·        Time synchronization may be inconsistent across controllers, HMIs, historians, network sensors, endpoint systems, and operator records.

·        Endpoint monitoring may be unavailable or unsuitable on legacy OT systems.

·        Encrypted remote-access sessions may conceal engineering commands.

·        Password or IP-address changes may lock out operators while leaving limited evidence of the source or user.

Compensating Controls

·        Use passive OT monitoring to establish asset, protocol, communication-path, programming, and controller-state baselines.

·        Maintain protected known-good PLC, HMI, SCADA, firmware, configuration, and parameter records for comparison.

·        Perform scheduled and event-driven comparison between running controller state and approved engineering baselines where supported.

·        Centralize controller, engineering, HMI/SCADA, historian, remote-access, VPN, firewall, cellular, and operator records where feasible.

·        Use controlled engineering paths and maintain controller-to-source, user-to-source, integrator-to-site, and remote-access-to-work-order mappings.

·        Require controller changes to identify the source, user, project, changed object, expected process effect, approval, validation result, and rollback plan.

·        Use independent operational validation through redundant sensors, laboratory data, field inspection, operator rounds, or separate safety and quality systems.

·        Preserve relevant controller, engineering, HMI/SCADA, historian, network, endpoint, operator, and change-management evidence after suspicious activity.

·        Establish joint OT operations, control engineering, water-quality, safety, and cybersecurity triage procedures for unexplained changes and process anomalies.

Do not rely only on asset inventory, firmware status, internet-exposure validation, password rotation, or vulnerability remediation when suspicious engineering, controller, HMI, or process activity occurred. Unauthorized logic, parameters, accounts, communications settings, HMI changes, or alternate access paths may remain after exposure is reduced.

‍ ‍

S25 Ultra-Tuned Detection Engineering Rules

‍ ‍

NDR / Network Behavioral Analytics

‍ ‍

Detection Viability Assessment

‍ ‍

NDR provides direct detection viability when the deployed platform identifies PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, OT jump hosts, industrial protocols, controller-management functions, programming operations, operating-mode changes, and normal asset relationships.

‍ ‍

Because no specific industrial NDR product is named, the Detection Query Patterns below define vendor-neutral behavioral implementation requirements. They are not presented as executable syntax. Engineering teams must translate the logic into the selected platform’s native industrial protocol parsers, asset models, baselines, policies, and correlation capabilities.

‍ ‍

Generic flow telemetry without industrial command, controller-role, or asset-relationship context provides supporting visibility but cannot independently confirm PLC manipulation.

‍ ‍

Rule

‍ ‍

Unauthorized PLC Engineering and Configuration Manipulation

‍ ‍

Rule Format

‍ ‍

Vendor-neutral industrial network behavioral analytic

‍ ‍

Detection Purpose

‍ ‍

Detect unauthorized or abnormal PLC programming, project-transfer, logic, parameter, firmware, credential, network-configuration, or operating-mode activity while distinguishing lower-confidence engineering access from confirmed manipulation and critical latent process risk.

‍ ‍

Detection Logic

‍ ‍

Evaluate industrial protocol and controller-management activity directed at PLCs, remote terminal units, and related controllers.

‍ ‍

Treat the following as confirmed change behaviors where the platform can identify them:

‍ ‍

·        Project download or full program download.

‍ ‍

·        Online edit or program append.

‍ ‍

·        Logic, task, routine, program, function-block, tag, or parameter modification.

‍ ‍

·        Firmware update, firmware replacement, or firmware-update-mode activation.

‍ ‍

·        Controller credential, password, privilege, IP address, subnet, gateway, routing, protocol, communications, or management-setting change.

‍ ‍

·        Controller reset, memory clear, project restore, or operating-mode change.

‍ ‍

Treat project upload as a lower-confidence engineering-access or collection signal unless one or more of the following conditions apply:

‍ ‍

·        The source is unauthorized or outside its approved controller scope.

‍ ‍

·        The destination or transfer path is unusual or unapproved.

‍ ‍

·        The upload occurs outside an approved work order or maintenance activity.

‍ ‍

·        The same source uploads projects from multiple controllers.

‍ ‍

·        The upload is followed by project modification, project download, online edit, parameter change, credential change, network change, or operating-mode change.

‍ ‍

·        The uploaded project is transferred to an external, unapproved, or newly observed destination.

‍ ‍

Promote activity when one or more of the following conditions apply:

‍ ‍

·        The source is not an approved engineering workstation, HMI, OT jump host, vendor-support system, or controller-management asset for the destination.

‍ ‍

·        The source-to-controller relationship is first seen, rare, cross-zone, internet-originating, cellular-originating, or inconsistent with the approved OT architecture.

‍ ‍

·        The activity occurs outside an approved work order, maintenance window, commissioning event, recovery action, or emergency change.

‍ ‍

·        The user, session, source, project, controller, engineering path, or changed object does not match the approved change record.

‍ ‍

·        The action affects treatment-critical or safety-relevant logic, interlocks, permissives, alarms, process parameters, credentials, communications settings, or controller operating mode.

‍ ‍

·        Multiple high-impact engineering actions occur within one session or bounded activity period.

‍ ‍

Classify the resulting alert as one of the following:

‍ ‍

·        Attempted or suspicious engineering access.

‍ ‍

·        Confirmed unauthorized manipulation.

‍ ‍

·        Critical manipulation or latent process risk.

‍ ‍

Do not require a physical-process deviation when authoritative protocol, controller, engineering, or configuration-integrity evidence independently confirms an unauthorized change.

‍ ‍

Required Telemetry

‍ ‍

·        OT-aware NDR telemetry with industrial protocol or controller-management parsing.

‍ ‍

·        Controller, HMI, SCADA, engineering-workstation, jump-host, and gateway asset roles.

‍ ‍

·        Source and destination asset identifiers and network zones.

‍ ‍

·        Industrial protocol, service, function, command, action, result, and session fields where supported.

‍ ‍

·        Approved engineering-source and controller-to-source mappings.

‍ ‍

·        Approved user, integrator, vendor, maintenance-window, and change-control context where available.

‍ ‍

·        Controller criticality and process-area mapping.

‍ ‍

·        Project, configuration, checksum, or integrity context where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Map supported vendor protocols into normalized action categories for:

‍ ‍

·        Read-only access.

‍ ‍

·        Project upload.

‍ ‍

·        Project download.

‍ ‍

·        Online edit.

‍ ‍

·        Program append.

‍ ‍

·        Logic or task modification.

‍ ‍

·        Parameter modification.

‍ ‍

·        Credential modification.

‍ ‍

·        Network configuration modification.

‍ ‍

·        Firmware activity.

‍ ‍

·        Reset or restore.

‍ ‍

·        Operating-mode change.

‍ ‍

Maintain controller-specific approved engineering-source mappings rather than relying on one facility-wide allowlist.

‍ ‍

Treat maintenance windows as supporting context rather than automatic suppression. Require the source, user, controller, project, action, changed object, and work order to align with the approved activity.

‍ ‍

Consolidate repeated commands occurring within the same engineering session into one activity record when they affect the same controller and change context.

‍ ‍

Use the following alert precedence:

‍ ‍

·        This rule opens the initial unauthorized-manipulation alert.

‍ ‍

·        Rule 2 enriches or supersedes this alert when process impact, loss of control, operator lockout, or critical latent risk is identified.

‍ ‍

·        Rule 3 creates a separate expansion alert when the activity affects multiple controllers, process areas, facilities, or sites.

‍ ‍

Use a deduplication key based on:

‍ ‍

·        Controller identifier.

‍ ‍

·        Source engineering asset or source session.

‍ ‍

·        User where available.

‍ ‍

·        Normalized action category.

‍ ‍

·        Project or change identifier where available.

‍ ‍

·        Bounded activity window.

‍ ‍

Update the existing alert when additional events belong to the same engineering session or change sequence. Re-alert only when the activity resumes after the locally defined quiet period, affects a new controller or changed object, or increases the alert classification.

‍ ‍

Preserve the native protocol action, controller, source, destination, user, session, project, changed object, prior state, new state, change context, parser confidence, and alert classification.

‍ ‍

Suppress approved polling, read-only monitoring, backups, project uploads, maintenance, recovery, and commissioning only after validating the complete controller-to-source and change-management relationship.

‍ ‍

DRI Assessment

‍ ‍

High reliability is achievable when the NDR platform provides controller-aware parsing, controller-specific source mappings, and approved change context. Reliability decreases when the platform exposes only generic write activity or flow metadata without identifying the engineering action or affected object.

‍ ‍

The score is a design-stage estimate and must be validated against the selected NDR platform, supported protocols, parser fidelity, local asset mappings, and approved engineering baselines.

‍ ‍

DRI

‍ ‍

8.9

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong for network-visible programming and controller-management activity but does not cover local programming, serial access, removable-media transfer, encrypted vendor sessions, or changes that bypass the monitored path.

‍ ‍

Full telemetry adds controller audit, project-integrity, engineering-workstation, identity, and change-management evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.5

‍ ‍

Full-Telemetry TCR

‍ ‍

9.4

‍ ‍

Limitations

‍ ‍

·        Proprietary, encrypted, encapsulated, serial, or unsupported protocols may conceal engineering activity.

‍ ‍

·        Some platforms may identify a write or download without revealing the changed logic or parameter.

‍ ‍

·        Local programming and removable-media activity may not cross the monitored network.

‍ ‍

·        Legitimate integrator, commissioning, recovery, and emergency activity may resemble malicious engineering.

‍ ‍

·        Project upload alone may represent approved backup, troubleshooting, or state comparison.

‍ ‍

·        Incomplete asset classification or protocol parsing may produce false attribution.

‍ ‍

·        NDR alone may not establish the semantic or physical consequence of a controller change.

‍ ‍

Detection Query Pattern

‍ ‍

Implement this rule through the selected industrial NDR platform’s native asset, protocol, policy, baseline, and alerting capabilities.

‍ ‍

·        Identify sessions directed at PLCs, remote terminal units, or controllers.

‍ ‍

·        Normalize observed actions into read-only access, project upload, confirmed controller change, credential change, network change, firmware activity, reset, restore, or operating-mode change.

‍ ‍

·        Evaluate the source against the destination controller’s approved engineering sources, network zones, user scope, remote-access paths, maintenance context, and work orders.

‍ ‍

·        Treat project upload as suspicious engineering access unless additional evidence establishes unauthorized collection, preparation for manipulation, or a subsequent controller change.

‍ ‍

·        Classify confirmed project downloads, online edits, program appends, logic changes, parameter changes, credential changes, network changes, firmware changes, resets, restores, and mode changes as confirmed manipulation when unauthorized or unexplained.

‍ ‍

·        Elevate activity to critical manipulation or latent process risk when the changed object affects treatment-critical logic, safety-relevant logic, hidden or delayed execution, interlocks, permissives, protection conditions, dosing limits, or multiple controllers.

‍ ‍

·        Consolidate repeated commands from the same session into one alert.

‍ ‍

·        Deduplicate by controller, source or session, user, action category, project or change identifier, and bounded activity window.

‍ ‍

·        Open the initial alert under Rule 1 and permit Rule 2 to enrich or supersede it if impact or critical latent risk is later identified.

‍ ‍

·        Retain source, destination, controller, protocol, native command, normalized action, session, user, project, changed object, prior state, new state, approval context, parser confidence, and alert classification.

‍ ‍

Rule

‍ ‍

Controller or HMI Manipulation Followed by Loss of Control or Process Deviation

‍ ‍

Rule Format

‍ ‍

Vendor-neutral industrial network behavioral correlation analytic

‍ ‍

Detection Purpose

‍ ‍

Detect controller, HMI, or SCADA manipulation followed by communications loss, operator lockout, controller instability, abnormal equipment behavior, process deviation, manual-operation transition, or operational impact, while separately identifying confirmed critical manipulation with unresolved latent consequences.

‍ ‍

Detection Logic

‍ ‍

Implement two distinct correlation branches within one durable rule.

‍ ‍

The first branch correlates a confirmed or highly suspicious controller, HMI, or SCADA change with a subsequent impact signal.

‍ ‍

The initiating change may include:

‍ ‍

·        Program or configuration modification.

‍ ‍

·        Credential or controller-password change.

‍ ‍

·        Controller IP address, subnet, gateway, routing, protocol, or communications change.

‍ ‍

·        Operating-mode change, reset, stop, restart, restore, or firmware activity.

‍ ‍

·        HMI or SCADA set-point, alarm, tag, display, account, administrative, or manual-command change.

‍ ‍

·        Interlock, permissive, protection, treatment-limit, or process-parameter modification.

‍ ‍

The subsequent impact may include:

‍ ‍

·        Loss of PLC-to-HMI, PLC-to-SCADA, PLC-to-historian, remote-I/O, peer-controller, or engineering communications.

‍ ‍

·        Controller fault, stop, restart, reset, project mismatch, or repeated reconnect.

‍ ‍

·        Failed legitimate operator or engineering access after a credential or network change.

‍ ‍

·        HMI or SCADA loss of view, loss of control, stale values, or inconsistent values.

‍ ‍

·        Process deviation outside an approved engineering, safety, operating, laboratory, or water-quality threshold.

‍ ‍

·        Manual-operation transition, process shutdown, boil-water notice, wastewater-release concern, or service interruption.

‍ ‍

The second branch identifies authoritatively confirmed critical manipulation without requiring a subsequent impact event.

‍ ‍

This branch applies when confirmed unauthorized activity affects:

‍ ‍

·        Treatment-critical or safety-relevant logic.

‍ ‍

·        Hidden, dormant, delayed, or conditionally activated logic.

‍ ‍

·        Interlocks, permissives, protection logic, or alarm-enforcement logic.

‍ ‍

·        Chemical-dosing, treatment-limit, pressure, flow, level, sequencing, or other critical process parameters.

‍ ‍

·        Multiple controllers, process areas, facilities, or sites.

‍ ‍

·        A malicious project download with unresolved latent process consequences.

‍ ‍

Prefer correlation by the same controller identifier.

‍ ‍

Where the initiating change and impact involve different assets, use an explicit relationship such as:

‍ ‍

·        HMI or SCADA system mapped to the affected controller.

‍ ‍

·        Controller mapped to the affected equipment group.

‍ ‍

·        Controller mapped to the same process area.

‍ ‍

·        Controller mapped to a dependent remote-I/O, field-device, historian, or operator system.

‍ ‍

Process-area correlation without a direct controller or asset dependency must use stricter evidence requirements and should normally require more than one independent impact indicator.

‍ ‍

Required Telemetry

‍ ‍

Minimum direct NDR evidence includes:

‍ ‍

·        Industrial protocol, controller-management, HMI, or SCADA activity identifying the initiating change.

‍ ‍

·        Controller identity, asset role, process area, and known asset relationships.

‍ ‍

·        Controller state, communications, protocol-error, and session telemetry where supported.

‍ ‍

External evidence may be ingested directly into the NDR platform or supplied through SIEM, historian, operator, laboratory, or process-system correlation. This may include:

‍ ‍

·        HMI and SCADA logs.

‍ ‍

·        Historian and process-variable telemetry.

‍ ‍

·        Independent sensor and field-device telemetry.

‍ ‍

·        Operator-lockout and manual-operation records.

‍ ‍

·        Laboratory and water-quality data.

‍ ‍

·        Service-impact and incident records.

‍ ‍

·        Approved thresholds, maintenance context, and change-management records.

‍ ‍

The rule remains viable without every external source, but impact confidence must reflect the evidence available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Create two separate native implementation branches:

‍ ‍

·        Confirmed change followed by impact.

‍ ‍

·        Authoritatively confirmed critical manipulation without observed impact.

‍ ‍

Do not implement the second branch as an exception inside a sequence that requires a subsequent event.

‍ ‍

For the change-to-impact branch, prefer the same controller identifier as the correlation key.

‍ ‍

Use mapped relationships only where direct controller identity is unavailable:

‍ ‍

·        HMI or SCADA to controller.

‍ ‍

·        Controller to equipment group.

‍ ‍

·        Controller to process area.

‍ ‍

·        Controller to historian tags.

‍ ‍

·        Controller to remote I/O or field devices.

‍ ‍

Require stricter corroboration when only process-area or facility-level relationships are available.

‍ ‍

For each process-impact event, retain:

‍ ‍

·        Evidence source.

‍ ‍

·        Data path.

‍ ‍

·        Sensor, historian, HMI, controller, laboratory, or operator-system identity.

‍ ‍

·        Whether the evidence is independent of the initiating controller or HMI.

‍ ‍

·        Approved threshold.

‍ ‍

·        Threshold direction.

‍ ‍

·        Threshold duration.

‍ ‍

·        Rate of change.

‍ ‍

·        Repetition count.

‍ ‍

·        Expected operating phase.

‍ ‍

·        Maintenance status.

‍ ‍

·        Redundant-source confirmation where available.

‍ ‍

Do not treat one transient communications loss, controller restart, stale value, threshold crossing, or inconsistent value as sufficient impact evidence unless the event is independently designated as critical.

‍ ‍

Apply locally defined controls for:

‍ ‍

·        Minimum duration.

‍ ‍

·        Repetition count.

‍ ‍

·        Rate of change.

‍ ‍

·        Approved threshold.

‍ ‍

·        Expected operating phase.

‍ ‍

·        Maintenance or testing status.

‍ ‍

·        Independent or redundant confirmation.

‍ ‍

Increase confidence when process deviation is supported through a separate data path, redundant sensor, laboratory result, field observation, operator record, or independent safety or quality system.

‍ ‍

Do not label a condition unsafe unless it crosses an approved engineering, safety, operating, laboratory, or water-quality threshold.

‍ ‍

Use the following alert precedence:

‍ ‍

·        Locate the related Rule 1 alert using the controller, source or session, user, project or change identifier, and bounded activity window.

‍ ‍

·        Enrich and supersede the Rule 1 alert when loss of control, process impact, operator lockout, or critical latent risk is established.

‍ ‍

·        Do not create a second independent alert for the same controller and change sequence unless platform limitations prevent alert updating.

‍ ‍

·        Permit Rule 3 to create a separate expansion alert when multiple controllers, process areas, facilities, or sites are involved.

‍ ‍

Use a deduplication key based on:

‍ ‍

·        Controller identifier.

‍ ‍

·        Initiating change identifier or project.

‍ ‍

·        Source or engineering session.

‍ ‍

·        Impact category or critical-latent-risk category.

‍ ‍

·        Bounded correlation window.

‍ ‍

Update the alert as new impact evidence arrives. Re-alert only when severity increases, a new independent consequence appears, a new controller or process area becomes affected, or activity resumes after the locally defined quiet period.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when the initial manipulation is observed through authoritative controller or parsed industrial protocol evidence and the impact maps to the same controller or an explicit dependent asset.

‍ ‍

Reliability decreases when process data lacks independent validation, asset relationships are incomplete, or the impact signal is transient.

‍ ‍

The score is a design-stage estimate and must be validated against the selected NDR platform and local evidence architecture.

‍ ‍

DRI

‍ ‍

9.1

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong for visible change-to-impact chains and confirmed critical manipulation.

‍ ‍

Full coverage requires controller audit, HMI/SCADA logs, historian data, independent process evidence, approved thresholds, operator records, and reliable asset dependency mappings.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.7

‍ ‍

Full-Telemetry TCR

‍ ‍

9.6

‍ ‍

Limitations

‍ ‍

·        Process effects may be delayed, conditional, or dependent on later operating states.

‍ ‍

·        HMI, historian, and network telemetry may share the same manipulated source.

‍ ‍

·        Equipment failure, sensor failure, maintenance, environmental conditions, or operator error may resemble cyber-induced deviation.

‍ ‍

·        Some credential or network changes may disconnect a controller before complete event details are captured.

‍ ‍

·        Local or serial changes may produce impact without a visible initiating network event.

‍ ‍

·        Process telemetry may be delayed, down-sampled, filtered, or unavailable.

‍ ‍

·        Facility-level correlation may be too broad without explicit asset dependency mappings.

‍ ‍

·        Not every NDR platform can directly ingest laboratory, operator, historian, or service-impact records.

‍ ‍

Detection Query Pattern

‍ ‍

Implement this rule through two separate native correlation branches.

‍ ‍

·        For the change-to-impact branch, identify an unauthorized or unexplained controller, HMI, or SCADA change.

‍ ‍

·        Prefer the same controller identifier when correlating the subsequent impact.

‍ ‍

·        Where different assets are involved, require an explicit HMI-to-controller, controller-to-equipment, controller-to-process, controller-to-historian, or controller-to-field-device relationship.

‍ ‍

·        Use process-area correlation only as a fallback and require multiple corroborating impact indicators or one independently validated critical indicator.

‍ ‍

·        Require impact signals to satisfy locally defined duration, repetition, rate-of-change, threshold, operating-phase, and maintenance controls.

‍ ‍

·        Retain evidence source, data path, system or sensor identity, independence status, threshold context, duration, direction, and redundant confirmation.

‍ ‍

·        For the critical-latent-risk branch, alert on authoritatively confirmed unauthorized changes to treatment-critical logic, safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection logic, dosing limits, critical process parameters, or multiple controllers without requiring a subsequent impact event.

‍ ‍

·        Locate and update the related Rule 1 alert where possible.

‍ ‍

·        Supersede the Rule 1 classification when impact or critical latent risk is established.

‍ ‍

·        Deduplicate by controller, initiating change or project, source or session, impact category, and bounded correlation window.

‍ ‍

·        Retain the initiating change, changed object, prior state, new state, controller, process area, related assets, impact evidence, independence status, threshold context, severity, and confidence.

‍ ‍

Rule

‍ ‍

Multi-Controller or Cross-Facility Manipulation Expansion

‍ ‍

Rule Format

‍ ‍

Vendor-neutral industrial network behavioral aggregation analytic

‍ ‍

Detection Purpose

‍ ‍

Detect one source, identity, engineering workstation, remote-access session, project, artifact, or repeated change pattern performing unauthorized programming or administrative activity across multiple controllers, process areas, facilities, or sites.

‍ ‍

Detection Logic

‍ ‍

Evaluate expansion through separate entity-specific aggregation branches.

‍ ‍

The source-asset branch groups activity by engineering workstation, OT jump host, HMI, vendor-support system, or other source asset.

‍ ‍

The identity branch groups activity by named user, service account, vendor account, integrator account, or other attributable identity.

‍ ‍

The remote-access branch groups activity by VPN session, privileged-access session, remote-desktop session, cellular session, or other remote-access identifier.

‍ ‍

The project or artifact branch groups activity by PLC project identifier, project hash, configuration package, firmware artifact, or other engineering artifact.

‍ ‍

The repeated-change-pattern branch groups activity by a normalized sequence of actions, changed-object type, native command pattern, timing, and target distribution.

‍ ‍

Do not combine these different entity classes through one fallback or coalesced key.

‍ ‍

Promote activity when an entity-specific branch identifies unauthorized or unexplained engineering or administrative activity against:

‍ ‍

·        Multiple controllers outside the entity’s approved scope.

‍ ‍

·        Multiple process areas not covered by the same approved work order.

‍ ‍

·        Multiple facilities or sites.

‍ ‍

·        Controller families or vendors not normally managed by the source.

‍ ‍

·        A sequence consistent with controller discovery followed by manipulation.

‍ ‍

·        Multiple assets that later experience similar lockout, communications, fault, process, or manual-operation conditions.

‍ ‍

Evaluate approved scope according to entity type:

‍ ‍

·        User-to-controller scope.

‍ ‍

·        Engineering-workstation-to-controller scope.

‍ ‍

·        Remote-session-to-site scope.

‍ ‍

·        Integrator-to-facility scope.

‍ ‍

·        Project-to-controller scope.

‍ ‍

·        Change-ticket-to-asset scope.

‍ ‍

A native command pattern or repeated behavior does not receive an approved operational scope. It is evaluated against rarity, target distribution, similarity, timing, and associated authorized entities.

‍ ‍

Required Telemetry

‍ ‍

·        OT-aware NDR activity with controller and engineering-action classification.

‍ ‍

·        Source asset, user, remote-access session, project, artifact, native action, and destination identifiers where supported.

‍ ‍

·        Controller, process-area, facility, site, vendor, and asset-role mappings.

‍ ‍

·        User-to-controller, workstation-to-controller, remote-session-to-site, integrator-to-facility, project-to-controller, and change-ticket-to-asset mappings where applicable.

‍ ‍

·        Historical source-to-controller and user-to-controller baselines.

‍ ‍

·        Work-order, maintenance-window, vendor, and integrator context.

‍ ‍

·        Controller-state and process-impact telemetry for consequence enrichment where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Implement separate aggregation branches for:

‍ ‍

·        Source asset or engineering workstation.

‍ ‍

·        User or identity.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact.

‍ ‍

·        Repeated change pattern.

‍ ‍

Evaluate each branch against its correct approved-scope model.

‍ ‍

Do not apply user scope to project hashes, workstation scope to source IP addresses affected by NAT, or operational scope to generic command patterns.

‍ ‍

For source IP aggregation, require supporting source-asset, session, NAT, or network-location context before treating the IP address as a stable entity.

‍ ‍

Define local thresholds according to facility size, controller density, centralized engineering practices, and legitimate multi-site management.

‍ ‍

Avoid static count-only logic. Include:

‍ ‍

·        Target rarity.

‍ ‍

·        Cross-zone movement.

‍ ‍

·        Cross-facility activity.

‍ ‍

·        Approved scope.

‍ ‍

·        Work-order alignment.

‍ ‍

·        Change similarity.

‍ ‍

·        Time distribution.

‍ ‍

·        Controller criticality.

‍ ‍

·        Subsequent impact.

‍ ‍

Exclude approved fleet-wide firmware, backup, recovery, configuration, or project operations only when the source, identity, controller set, project, action, work order, and time window all match the approved change.

‍ ‍

Consolidate the outputs of the entity-specific branches into one expansion alert when they refer to the same activity cluster.

‍ ‍

Use a deduplication key based on:

‍ ‍

·        Primary entity type.

‍ ‍

·        Primary entity identifier.

‍ ‍

·        Activity-cluster identifier.

‍ ‍

·        Affected controller set.

‍ ‍

·        Bounded aggregation period.

‍ ‍

Preserve all affected controllers, process areas, facilities, and sites in one alert.

‍ ‍

Update the alert as additional affected assets or related entities are identified.

‍ ‍

Re-alert only when:

‍ ‍

·        A new facility or site is affected.

‍ ‍

·        The affected controller set materially expands.

‍ ‍

·        Severity increases.

‍ ‍

·        A new impact category appears.

‍ ‍

·        The activity resumes after the defined quiet period.

‍ ‍

·        A separate activity cluster is identified.

‍ ‍

Use the following alert precedence:

‍ ‍

·        Rule 1 remains the controller-level unauthorized-manipulation alert.

‍ ‍

·        Rule 2 remains the controller-level impact or critical-latent-risk alert.

‍ ‍

·        Rule 3 creates a separate campaign or expansion alert only when multiple controllers, process areas, facilities, or sites are involved.

‍ ‍

·        Rule 3 should reference related Rule 1 and Rule 2 alert identifiers rather than recreating all controller-level alerts.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when entity identities, approved scopes, controller mappings, facilities, work orders, and remote-access relationships are accurately maintained.

‍ ‍

Reliability decreases in centralized environments where one engineering source legitimately manages many controllers without granular change records.

‍ ‍

The score is a design-stage estimate and must be validated against local asset, identity, project, and network mappings.

‍ ‍

DRI

‍ ‍

8.7

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong for network-visible expansion across multiple controllers or facilities.

‍ ‍

Full telemetry improves attribution through engineering audit, identity, project, remote-access, change-management, and process-impact evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.6

‍ ‍

Full-Telemetry TCR

‍ ‍

9.3

‍ ‍

Limitations

‍ ‍

·        Central engineering teams and integrators may legitimately manage many controllers.

‍ ‍

·        Shared accounts, NAT, jump hosts, and common remote-access gateways may obscure the responsible entity.

‍ ‍

·        Local or serial programming at separate controllers may not aggregate through the monitored network.

‍ ‍

·        Different vendor protocols may normalize similar actions inconsistently.

‍ ‍

·        A low-and-slow actor may avoid local count or time thresholds.

‍ ‍

·        Incomplete facility, process-area, user, project, or approved-scope mappings may prevent reliable correlation.

‍ ‍

·        Project hashes or repeated command patterns may be shared by legitimate activity and require entity and change context.

‍ ‍

·        A single source IP may represent multiple systems or sessions.

‍ ‍

Detection Query Pattern

‍ ‍

Implement separate native aggregation branches rather than one combined fallback key.

‍ ‍

·        Group source-asset activity by stable engineering workstation, OT jump host, HMI, vendor-support system, or source-asset identifier.

‍ ‍

·        Group identity activity by named user, service account, vendor account, or integrator account.

‍ ‍

·        Group remote-access activity by stable VPN, privileged-access, cellular, or remote-management session identifier.

‍ ‍

·        Group project and artifact activity by project identifier, project hash, configuration package, firmware artifact, or equivalent engineering artifact.

‍ ‍

·        Group repeated behavior by normalized action sequence, changed-object type, timing, target distribution, and native command characteristics.

‍ ‍

·        Evaluate each branch against its corresponding approved-scope relationship.

‍ ‍

·        Do not assign an approved operational scope to a generic command pattern.

‍ ‍

·        Require source-asset or session context before using source IP as a durable aggregation entity.

‍ ‍

·        Consolidate related entity branches into one activity cluster when timing, target set, project, session, or change characteristics demonstrate a common operation.

‍ ‍

·        Trigger a separate expansion alert only when the activity affects multiple controllers, process areas, facilities, or sites outside approved scope.

‍ ‍

·        Preserve all affected targets in one alert and reference related Rule 1 and Rule 2 alert identifiers.

‍ ‍

·        Deduplicate by primary entity type, primary entity identifier, activity cluster, affected controller set, and bounded aggregation period.

‍ ‍

·        Update the alert when additional assets or evidence are added, and re-alert only for material expansion, severity increase, new impact, resumed activity, or a separate activity cluster.

‍ ‍

SentinelOne

‍ ‍

Detection Viability Assessment

‍ ‍

SentinelOne provides viable endpoint-support detection for agent-instrumented engineering workstations, OT jump hosts, HMI/SCADA support servers, historian servers, vendor-support systems, and other compatible Windows or Linux assets.

‍ ‍

SentinelOne can detect engineering-application execution, protected project-file activity, suspicious access and execution chains, and persistence or tampering connected to PLC engineering workflows. It cannot independently confirm PLC logic modification, controller operating-mode change, HMI manipulation, field-device behavior, or physical-process impact.

‍ ‍

The rules use SentinelOne STAR base detections built from Deep Visibility queries. Ordered sequencing, authorization context, work-order validation, expected-state comparison, deduplication, and cross-rule alert handling may be completed through SentinelOne XDR, the Security Data Lake, an automation workflow, or the receiving SIEM.

‍ ‍

Local executable names, engineering paths, project-file patterns, and supported field names must be validated in the target SentinelOne tenant before deployment.

‍ ‍

Rule

‍ ‍

Unauthorized PLC Engineering Tool or Protected Project Activity

‍ ‍

Rule Format

‍ ‍

SentinelOne STAR base detections with authorization and scope correlation

‍ ‍

Detection Purpose

‍ ‍

Detect PLC, HMI, SCADA, firmware, or controller-engineering applications and protected engineering artifacts used from an unauthorized endpoint, user, application path, project assignment, or facility scope.

‍ ‍

Detection Logic

‍ ‍

Detect execution of locally inventoried PLC, HMI, SCADA, controller-configuration, and firmware-management applications.

‍ ‍

Detect creation, modification, rename, move, or deletion involving protected PLC projects, HMI/SCADA projects, controller configurations, firmware packages, repositories, and known-good recovery artifacts.

‍ ‍

Classify activity as suspicious engineering-tool or artifact activity when it involves:

‍ ‍

·        First-seen engineering software.

‍ ‍

·        An unusual execution path.

‍ ‍

·        Portable engineering applications.

‍ ‍

·        Project activity outside the normal operating pattern.

‍ ‍

·        Incomplete maintenance or work-order context.

‍ ‍

Classify activity as confirmed unauthorized endpoint engineering activity only when maintained authorization data shows that the endpoint, user, application, protected artifact, project assignment, or facility assignment is not approved.

‍ ‍

Classify activity as high risk requiring PLC or OT correlation when confirmed unauthorized endpoint behavior involves:

‍ ‍

·        Treatment-critical or safety-relevant projects.

‍ ‍

·        Firmware or controller configuration packages.

‍ ‍

·        Multiple facility-specific projects.

‍ ‍

·        Protected known-good or recovery artifacts.

‍ ‍

·        Engineering activity directed toward OT address space.

‍ ‍

·        Activity consistent with preparation for controller access or project deployment.

‍ ‍

Rarity, an unusual path, or an uncommon user alone must not establish confirmed unauthorized activity.

‍ ‍

Remote-access tools, scripting engines, transfer utilities, archive tools, removable media, and unusual network activity may enrich the alert but must not independently satisfy this rule unless they directly perform the protected engineering-artifact action.

‍ ‍

Required Telemetry

‍ ‍

·        Process creation and ancestry.

‍ ‍

·        Process name.

‍ ‍

·        Process image path.

‍ ‍

·        Process command line.

‍ ‍

·        Process hash and signer where available.

‍ ‍

·        Endpoint identifier and endpoint group.

‍ ‍

·        User.

‍ ‍

·        File path and file action.

‍ ‍

·        Source process associated with file activity.

‍ ‍

·        Storyline or True Context identifier where available.

‍ ‍

·        Endpoint network activity for enrichment.

‍ ‍

·        Approved engineering applications, endpoints, users, project paths, facility assignments, maintenance windows, and work orders.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Maintain local inventories for:

‍ ‍

·        Approved PLC engineering applications.

‍ ‍

·        Approved HMI and SCADA engineering applications.

‍ ‍

·        Approved firmware-management applications.

‍ ‍

·        Approved executable paths, hashes, signers, and versions.

‍ ‍

·        Approved engineering endpoints and users.

‍ ‍

·        Protected project, configuration, firmware, repository, and recovery paths.

‍ ‍

·        Endpoint-to-project, user-to-project, and endpoint-to-facility scope.

‍ ‍

·        Treatment-critical and safety-relevant projects.

‍ ‍

Create STAR detections for engineering-application execution and protected engineering-artifact activity.

‍ ‍

Validate each query in Deep Visibility before conversion to STAR.

‍ ‍

Apply endpoint, user, project, facility, maintenance, and work-order authorization through available SentinelOne enrichment, automation, data-lake correlation, or SIEM correlation.

‍ ‍

Rule 1 opens the initial engineering-activity alert.

‍ ‍

Rule 2 may enrich or supersede Rule 1 when suspicious access or execution behavior precedes the engineering activity.

‍ ‍

Rule 3 creates a separate persistence or protected-artifact-tampering alert.

‍ ‍

NDR, controller, engineering-audit, HMI/SCADA, project-integrity, or process evidence is required before endpoint activity is represented as confirmed PLC manipulation.

‍ ‍

Deduplicate Rule 1 by endpoint, user, engineering application or protected artifact, Storyline or True Context identifier where available, and bounded activity window.

‍ ‍

Re-alert when a new endpoint, user, project, facility, Storyline, protected artifact, or materially higher classification is identified.

‍ ‍

Use alert-only response by default. Do not automatically terminate engineering software or isolate an OT-support endpoint without an approved operational-response procedure.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when engineering applications, endpoints, users, protected artifacts, project assignments, and authorization records are accurately maintained.

‍ ‍

Reliability decreases where portable engineering applications, shared accounts, unmanaged integrators, emergency procedures, or inconsistent project storage are common.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

8.7

‍ ‍

TCR Assessment

‍ ‍

Operational coverage identifies endpoint-side engineering execution and protected-artifact activity on instrumented systems.

‍ ‍

It cannot establish that a project was transferred to a controller or that a physical-process change occurred.

‍ ‍

Full telemetry requires NDR, controller audit, project-integrity, HMI/SCADA, historian, and change-management correlation.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

7.9

‍ ‍

Full-Telemetry TCR

‍ ‍

9.1

‍ ‍

Limitations

‍ ‍

·        Exact Deep Visibility fields and event availability may vary by tenant and operating system.

‍ ‍

·        SentinelOne may not be deployable on PLCs, embedded HMIs, appliances, or legacy OT devices.

‍ ‍

·        Engineering applications may be portable, renamed, wrapped, or launched through vendor-specific processes.

‍ ‍

·        Shared accounts reduce attribution.

‍ ‍

·        File telemetry does not reveal the semantic effect of a project change.

‍ ‍

·        Offline testing may legitimately modify engineering projects.

‍ ‍

·        Endpoint activity does not prove that a project was deployed to a controller.

‍ ‍

·        Authorization and work-order correlation may require an external enrichment layer.

‍ ‍

·        Automatic endpoint response could interrupt essential engineering or recovery work.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy tenant-validated S1QL detections using locally approved application names and protected engineering paths.

‍ ‍

(

‍ ‍

    ProcessName ContainsCIS "<LOCAL_PLC_ENGINEERING_EXECUTABLE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_HMI_SCADA_ENGINEERING_EXECUTABLE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_FIRMWARE_MANAGEMENT_EXECUTABLE>"

‍ ‍

    OR ProcessImagePath RegExp "<LOCAL_ENGINEERING_APPLICATION_PATH_REGEX>"

‍ ‍

)

‍ ‍

FileFullName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

AND (

‍ ‍

    FileCreatedAt Is Not Empty

‍ ‍

    OR FileModifyAt Is Not Empty

‍ ‍

)

‍ ‍

OldFileName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

AND FileFullName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

Rule

‍ ‍

Remote Access or Suspicious Execution Chain Preceding PLC Engineering Activity

‍ ‍

Rule Format

‍ ‍

SentinelOne STAR base detections feeding ordered correlation

‍ ‍

Detection Purpose

‍ ‍

Detect remote-access, credential, scripting, transfer, archive, removable-media, or suspicious execution behavior that occurs before PLC, HMI, SCADA, firmware, or controller-engineering activity on the same endpoint and within an attributable activity chain.

‍ ‍

Detection Logic

‍ ‍

Detect precursor activity involving:

‍ ‍

·        Unapproved remote desktop, remote-support, remote-shell, screen-sharing, or remote-management software.

‍ ‍

·        Suspicious command interpreters or scripting engines.

‍ ‍

·        Credential, vault, browser-credential, token, or password-retrieval tooling.

‍ ‍

·        File-transfer, download, synchronization, or archive utilities.

‍ ‍

·        Removable-media execution.

‍ ‍

·        New services, scheduled tasks, startup entries, tunnels, or remote-access configuration.

‍ ‍

·        Encoded commands or suspicious child-process execution.

‍ ‍

·        Unauthorized or out-of-scope user or remote sessions.

‍ ‍

Detect subsequent engineering activity involving:

‍ ‍

·        PLC, HMI, SCADA, firmware, or controller-engineering application execution.

‍ ‍

·        Access to engineering projects, configuration packages, firmware packages, HMI projects, or protected repositories.

‍ ‍

·        Creation or modification of engineering artifacts.

‍ ‍

·        Network activity from an engineering application or related process toward OT address space.

‍ ‍

Require:

‍ ‍

·        The precursor event to occur first.

‍ ‍

·        The engineering event to occur second.

‍ ‍

·        The same endpoint.

‍ ‍

·        The same Storyline, True Context, process group, direct process ancestry, stable remote-access session, or authenticated user session.

‍ ‍

·        A locally defined maximum interval.

‍ ‍

Same-endpoint activity without a supporting Storyline, process, or session relationship is insufficient.

‍ ‍

Events occurring only after the engineering activity may enrich the alert but must not satisfy the precursor requirement.

‍ ‍

Required Telemetry

‍ ‍

·        Process creation and ancestry.

‍ ‍

·        Process name, image path, and command line.

‍ ‍

·        Endpoint identifier.

‍ ‍

·        User.

‍ ‍

·        Storyline or True Context identifier.

‍ ‍

·        Process group and process session identifiers where available.

‍ ‍

·        Remote-access and logon-session context where available.

‍ ‍

·        Remote-access application execution.

‍ ‍

·        Scripting and command-interpreter execution.

‍ ‍

·        Credential-tool execution.

‍ ‍

·        Transfer and archive-tool execution.

‍ ‍

·        Removable-media telemetry where available.

‍ ‍

·        Service, scheduled-task, and startup activity.

‍ ‍

·        Engineering-application execution.

‍ ‍

·        Engineering-artifact activity.

‍ ‍

·        Endpoint network activity.

‍ ‍

·        Approved users, remote-support tools, projects, facilities, maintenance windows, and work orders.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Create STAR base detections for:

‍ ‍

·        Remote-access and suspicious-tool execution.

‍ ‍

·        Suspicious child-process execution beneath remote-access, scripting, transfer, or administrative parents.

‍ ‍

·        Engineering-application execution.

‍ ‍

A protected-artifact match from Rule 1 may also satisfy the subsequent engineering-event side.

‍ ‍

Validate each query in Deep Visibility before conversion to STAR.

‍ ‍

Correlate the base events through available SentinelOne XDR, Security Data Lake, automation, or SIEM capabilities.

‍ ‍

Require the precursor timestamp to occur before the engineering timestamp.

‍ ‍

Require the same endpoint and prefer the same Storyline, True Context, process group, or direct process ancestry.

‍ ‍

Where those relationships are unavailable, require the same stable remote-access session or authenticated user session.

‍ ‍

Reject same-endpoint-only correlation.

‍ ‍

Use shorter windows for direct process, Storyline, or process-group relationships. Use longer windows only when a stable user or remote-access session links the events.

‍ ‍

Search for a related Rule 1 alert and enrich or supersede it where the correlation platform supports alert lifecycle operations. Otherwise, create Rule 2 and reference the Rule 1 alert identifier.

‍ ‍

Do not represent alert merging or superseding as guaranteed STAR behavior.

‍ ‍

Require OT evidence before representing the activity as confirmed controller manipulation.

‍ ‍

Deduplicate Rule 2 by endpoint, Storyline or session, precursor category, engineering application or protected artifact, and bounded correlation window.

‍ ‍

Re-alert when a new endpoint, user, session, Storyline, application, project, facility, or materially higher severity is identified.

‍ ‍

Use alert-only response by default.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when Storyline, process ancestry, session context, approved support tools, engineering applications, and work orders are available.

‍ ‍

Reliability decreases on shared endpoints or where remote-session and user attribution are incomplete.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

8.9

‍ ‍

TCR Assessment

‍ ‍

Operational coverage detects endpoint-side access and execution chains preceding engineering behavior.

‍ ‍

It cannot establish the controller command, deployed logic, or physical-process consequence.

‍ ‍

Full telemetry requires NDR, controller, engineering-audit, HMI/SCADA, historian, and change-management evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.2

‍ ‍

Full-Telemetry TCR

‍ ‍

9.3

‍ ‍

Limitations

‍ ‍

·        Exact Deep Visibility fields and event availability may vary by tenant.

‍ ‍

·        Approved vendor-support sessions may closely resemble the detected sequence.

‍ ‍

·        Some remote tools do not expose stable session identifiers.

‍ ‍

·        Shared engineering workstations may merge unrelated activity.

‍ ‍

·        Vendor wrappers and service processes may weaken direct ancestry.

‍ ‍

·        Credential activity may occur through approved password-management workflows.

‍ ‍

·        STAR detects the component events but ordered correlation may require XDR, data-lake, automation, or SIEM processing.

‍ ‍

·        Endpoint activity does not prove that a controller change occurred.

‍ ‍

·        Automated containment may disrupt essential support or recovery.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy tenant-validated S1QL precursor and engineering-event detections and perform the ordered sequence through the selected correlation layer.

‍ ‍

(

‍ ‍

    ProcessName ContainsCIS "<LOCAL_REMOTE_ACCESS_TOOL>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_SCRIPTING_ENGINE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_CREDENTIAL_ACCESS_TOOL>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_TRANSFER_TOOL>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_ARCHIVE_TOOL>"

‍ ‍

    OR ProcessCmd RegExp "<LOCAL_ENCODED_OR_SUSPICIOUS_COMMAND_REGEX>"

‍ ‍

)

‍ ‍

(

‍ ‍

    ParentProcessName ContainsCIS "<LOCAL_REMOTE_ACCESS_PARENT>"

‍ ‍

    OR ParentProcessName ContainsCIS "<LOCAL_SCRIPTING_PARENT>"

‍ ‍

    OR ParentProcessName ContainsCIS "<LOCAL_TRANSFER_PARENT>"

‍ ‍

)

‍ ‍

AND (

‍ ‍

    ProcessName ContainsCIS "<LOCAL_COMMAND_INTERPRETER>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_SCRIPTING_ENGINE>"

‍ ‍

    OR ProcessCmd RegExp "<LOCAL_SUSPICIOUS_CHILD_COMMAND_REGEX>"

‍ ‍

)

‍ ‍

(

‍ ‍

    ProcessName ContainsCIS "<LOCAL_PLC_ENGINEERING_EXECUTABLE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_HMI_SCADA_ENGINEERING_EXECUTABLE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_FIRMWARE_MANAGEMENT_EXECUTABLE>"

‍ ‍

    OR ProcessImagePath RegExp "<LOCAL_ENGINEERING_APPLICATION_PATH_REGEX>"

‍ ‍

)

‍ ‍

Rule

‍ ‍

PLC Engineering-Workflow Persistence and Protected-Artifact Tampering

‍ ‍

Rule Format

‍ ‍

SentinelOne STAR base detections feeding protected-state and conditional correlation

‍ ‍

Detection Purpose

‍ ‍

Detect persistence connected to PLC engineering workflows and unauthorized tampering with protected PLC projects, HMI/SCADA projects, controller configurations, engineering applications, repositories, firmware packages, or known-good recovery artifacts.

‍ ‍

Detection Logic

‍ ‍

Detect persistence attached to the engineering workflow, including:

‍ ‍

·        Services, scheduled tasks, startup entries, scripts, macros, plugins, remote-access mechanisms, or tunnels referencing an engineering application, engineering directory, protected project, repository, firmware package, or controller-support workflow.

‍ ‍

·        Persistent mechanisms created by an engineering application, child process, related Storyline, or remote-access session associated with engineering activity.

‍ ‍

·        Persistent mechanisms configured to launch or modify engineering tools, projects, repositories, or controller-support functions.

‍ ‍

Detect protected-artifact tampering, including:

‍ ‍

·        Replacement, deletion, encryption, concealment, rename, move, permission change, or unexpected modification of protected projects, configurations, firmware, known-good backups, integrity records, repository metadata, engineering binaries, libraries, plugins, templates, scripts, or macros.

‍ ‍

·        A protected artifact changed by a process, user, endpoint, updater, repository client, or backup tool outside its approved scope.

‍ ‍

·        An observed artifact state differing from a maintained expected hash, signer, owner, permission, path, version, or repository state.

‍ ‍

·        Backup or integrity records removed immediately before or after protected-artifact modification.

‍ ‍

Generic account creation, security-control changes, logging changes, or time-service changes must not independently satisfy the rule.

‍ ‍

They may enrich Rule 3 only when directly connected to engineering activity or protected-artifact modification through Storyline, process ancestry, session, artifact, or bounded timing.

‍ ‍

STAR identifies the endpoint persistence event or protected-path file event.

‍ ‍

The protected-state and authorization correlation determines:

‍ ‍

·        Whether the artifact is protected.

‍ ‍

·        Whether the observed state differs from the expected state.

‍ ‍

·        Whether the responsible process, updater, repository client, backup tool, endpoint, or user is approved.

‍ ‍

·        Whether a matching change ticket or maintenance activity exists.

‍ ‍

·        Whether persistence and protected-artifact activity belong to the same engineering chain.

‍ ‍

Required Telemetry

‍ ‍

·        Process creation and ancestry.

‍ ‍

·        Process name, image path, and command line.

‍ ‍

·        Storyline or True Context identifier.

‍ ‍

·        Process group and session identifiers where available.

‍ ‍

·        Service creation.

‍ ‍

·        Scheduled-task creation.

‍ ‍

·        Startup modification.

‍ ‍

·        Script, macro, plugin, or remote-access configuration activity where available.

‍ ‍

·        File creation, modification, rename, move, permission change, encryption, and deletion.

‍ ‍

·        File path and old file name where available.

‍ ‍

·        Source process associated with file activity.

‍ ‍

·        Endpoint identifier.

‍ ‍

·        User.

‍ ‍

·        Protected-artifact inventory.

‍ ‍

·        Expected hash, signer, owner, permission, version, or repository state where available.

‍ ‍

·        Approved updater, repository client, backup tool, user, endpoint, maintenance, and work-order records.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Maintain a protected-artifact inventory containing, where available:

‍ ‍

·        Protected path.

‍ ‍

·        Artifact type.

‍ ‍

·        Facility and controller association.

‍ ‍

·        Expected hash.

‍ ‍

·        Expected signer.

‍ ‍

·        Expected owner.

‍ ‍

·        Expected permissions.

‍ ‍

·        Expected version or repository state.

‍ ‍

·        Approved updater.

‍ ‍

·        Approved repository client.

‍ ‍

·        Approved backup tool.

‍ ‍

·        Approved user and endpoint scope.

‍ ‍

·        Treatment or safety criticality.

‍ ‍

Create STAR base detections for:

‍ ‍

·        File activity involving protected engineering paths.

‍ ‍

·        Scheduled-task activity referencing engineering applications, project directories, or protected artifacts.

‍ ‍

·        Script, service, startup, tunnel, or remote-access persistence associated with an engineering application or protected artifact.

‍ ‍

·        Suspicious child processes launched by engineering applications.

‍ ‍

Validate each query in Deep Visibility before conversion to STAR.

‍ ‍

Perform expected-state comparison, approved-process validation, maintenance matching, work-order matching, and bounded persistence-to-artifact correlation through available SentinelOne XDR, Security Data Lake, automation, or SIEM capabilities.

‍ ‍

Require at least one protected-state, authorization, or approved-change violation before classifying activity as tampering.

‍ ‍

Create a separate Rule 3 alert and link related Rule 1 or Rule 2 alerts through endpoint, Storyline, user, project, artifact, and bounded activity window.

‍ ‍

Do not represent alert linking as guaranteed STAR behavior.

‍ ‍

Require OT or project-deployment evidence before asserting that a tampered artifact reached a controller.

‍ ‍

Deduplicate Rule 3 by endpoint, protected artifact or persistence object, Storyline or responsible process tree, user, and bounded activity window.

‍ ‍

Re-alert when a different protected project, endpoint, facility, persistence mechanism, or materially higher severity is identified.

‍ ‍

Use alert-only response by default. Do not automatically delete persistence objects, restore files, kill engineering processes, or roll back protected artifacts without approved OT restoration procedures.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when protected artifacts, expected states, approved updaters, repository clients, backup tools, users, and change records are accurately maintained.

‍ ‍

Reliability decreases where engineering projects are stored ad hoc, expected states change frequently, integrators use unmanaged tools, or legitimate updates lack change records.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

8.8

‍ ‍

TCR Assessment

‍ ‍

Operational coverage detects engineering-workflow persistence and protected-artifact events on agent-instrumented endpoints.

‍ ‍

It does not identify changes stored only inside a PLC, embedded HMI, unsupported appliance, offline engineering device, or unobserved removable medium.

‍ ‍

Full telemetry requires NDR, controller audit, project-integrity, repository, HMI/SCADA, and change-management correlation.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.1

‍ ‍

Full-Telemetry TCR

‍ ‍

9.3

‍ ‍

Limitations

‍ ‍

·        Exact Deep Visibility fields and event availability may vary by tenant.

‍ ‍

·        Legitimate project saves, application updates, repository synchronization, backup rotation, and recovery modify protected artifacts.

‍ ‍

·        Accurate classification depends on maintained expected-state and approved-process inventories.

‍ ‍

·        Proprietary project containers may conceal semantic changes.

‍ ‍

·        Offline laptops, removable media, embedded HMIs, and unsupported systems may lack coverage.

‍ ‍

·        Expected-state, authorization, and work-order correlation may require XDR, data-lake, automation, or SIEM processing.

‍ ‍

·        File modification does not prove deployment to a controller.

‍ ‍

·        Automatic rollback or remediation could damage valid engineering work or recovery material.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy tenant-validated S1QL detections and perform protected-state comparison and authorization correlation through the selected correlation layer.

‍ ‍

FileFullName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

AND (

‍ ‍

    FileCreatedAt Is Not Empty

‍ ‍

    OR FileModifyAt Is Not Empty

‍ ‍

)

‍ ‍

OldFileName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

AND FileFullName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

(

‍ ‍

    TaskName RegExp "<LOCAL_ENGINEERING_RELATED_TASK_NAME_REGEX>"

‍ ‍

    OR TaskPath RegExp "<LOCAL_ENGINEERING_RELATED_TASK_PATH_REGEX>"

‍ ‍

    OR ProcessCmd ContainsCIS "schtasks"

‍ ‍

)

‍ ‍

AND (

‍ ‍

    ProcessCmd RegExp "<LOCAL_ENGINEERING_APPLICATION_OR_PROJECT_REGEX>"

‍ ‍

    OR ProcessImagePath RegExp "<LOCAL_ENGINEERING_APPLICATION_PATH_REGEX>"

‍ ‍

)

‍ ‍

(

‍ ‍

    ProcessCmd RegExp "<LOCAL_PERSISTENCE_CREATION_COMMAND_REGEX>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_PERSISTENCE_UTILITY>"

‍ ‍

)

‍ ‍

AND (

‍ ‍

    ProcessCmd RegExp "<LOCAL_ENGINEERING_APPLICATION_OR_PROJECT_REGEX>"

‍ ‍

    OR ProcessImagePath RegExp "<LOCAL_ENGINEERING_APPLICATION_PATH_REGEX>"

‍ ‍

    OR FileFullName RegExp "<PROTECTED_ENGINEERING_ARTIFACT_PATH_REGEX>"

‍ ‍

)

‍ ‍

ParentProcessName ContainsCIS "<LOCAL_ENGINEERING_APPLICATION_NAME>"

‍ ‍

AND (

‍ ‍

    ProcessName ContainsCIS "<LOCAL_SCRIPTING_ENGINE>"

‍ ‍

    OR ProcessName ContainsCIS "<LOCAL_REMOTE_ACCESS_TOOL>"

‍ ‍

    OR ProcessCmd RegExp "<LOCAL_PERSISTENCE_CREATION_COMMAND_REGEX>"

‍ ‍

)

‍ ‍

Splunk

‍ ‍

Detection Viability Assessment

‍ ‍

Splunk provides full correlation viability when industrial NDR, PLC and engineering audit, HMI/SCADA, historian, remote-access, endpoint, asset, and change-management telemetry is normalized into searchable fields.

‍ ‍

The three rules use native SPL correlation searches and preserve the distinction between suspicious engineering access, confirmed unauthorized manipulation, controller or process impact, and multi-controller expansion.

‍ ‍

Environment-specific indexes, sourcetypes, normalized field names, macros, lookups, thresholds, relationship mappings, maintenance windows, and suppression values must be validated before deployment.

‍ ‍

Rule

‍ ‍

Unauthorized Engineering Access Followed by PLC Manipulation

‍ ‍

Rule Format

‍ ‍

Splunk SPL correlation search

‍ ‍

Detection Purpose

‍ ‍

Detect unauthorized or abnormal access to an OT engineering environment followed by PLC project transfer, logic modification, parameter modification, credential change, network change, firmware activity, reset, restore, or operating-mode manipulation.

‍ ‍

Detection Logic

‍ ‍

Correlate an abnormal access event with subsequent controller-engineering or configuration activity involving the same attributable access chain.

‍ ‍

Qualifying access activity includes:

‍ ‍

·        VPN, privileged-access, remote-desktop, cellular, firewall, jump-host, or vendor-support access from an unapproved source.

‍ ‍

·        Access by an unapproved, dormant, shared, default, vendor, integrator, or out-of-scope account.

‍ ‍

·        A first-seen source-to-engineering-system relationship.

‍ ‍

·        IT-to-OT, internet-to-OT, cellular-to-OT, or cross-zone access outside the approved architecture.

‍ ‍

·        Failed authentication followed by successful access.

‍ ‍

·        Engineering access outside an approved work order, maintenance window, commissioning event, recovery action, or emergency change.

‍ ‍

Qualifying manipulation activity includes:

‍ ‍

·        Project download or full program download.

‍ ‍

·        Online edit or program append.

‍ ‍

·        Logic, task, routine, program, function-block, tag, or parameter change.

‍ ‍

·        Controller credential, password, privilege, IP address, subnet, gateway, routing, communications, or management-setting change.

‍ ‍

·        Firmware update, firmware replacement, or firmware-update-mode activation.

‍ ‍

·        Controller reset, memory clear, project restore, or operating-mode change.

‍ ‍

Treat project upload as lower-confidence engineering-access or collection activity unless it:

‍ ‍

·        Originates from an unauthorized source.

‍ ‍

·        Occurs outside an approved change.

‍ ‍

·        Collects projects from multiple controllers.

‍ ‍

·        Transfers a project to an unapproved destination.

‍ ‍

·        Is followed by project modification or controller manipulation.

‍ ‍

Classify the result as:

‍ ‍

·        Suspicious engineering access.

‍ ‍

·        Confirmed unauthorized manipulation.

‍ ‍

·        Critical manipulation or latent process risk.

‍ ‍

Critical classification applies when confirmed unauthorized activity affects treatment-critical or safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection conditions, dosing limits, critical process parameters, or multiple controllers.

‍ ‍

Required Telemetry

‍ ‍

·        VPN, remote-access, privileged-access, jump-host, firewall, cellular, and authentication logs.

‍ ‍

·        Industrial NDR or controller-management events.

‍ ‍

·        PLC and engineering-software audit logs where available.

‍ ‍

·        Controller, engineering-workstation, HMI, SCADA, jump-host, and remote-access asset inventory.

‍ ‍

·        Source and destination asset identifiers.

‍ ‍

·        Controller identifier and process area.

‍ ‍

·        User and session identifiers.

‍ ‍

·        Normalized engineering action.

‍ ‍

·        Project or change identifier where available.

‍ ‍

·        Approved engineering-source lookup.

‍ ‍

·        Historical source-to-engineering-system relationship lookup.

‍ ‍

·        Engineering-system-to-controller relationship lookup.

‍ ‍

·        Approved user, integrator, controller-scope, maintenance-window, and work-order lookups.

‍ ‍

·        Controller criticality and protected-object lookup.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize access events with:

‍ ‍

·        Source.

‍ ‍

·        Destination engineering system.

‍ ‍

·        User.

‍ ‍

·        Session.

‍ ‍

·        Access path.

‍ ‍

·        Authentication result.

‍ ‍

·        Source zone.

‍ ‍

·        Destination zone.

‍ ‍

·        Approval status.

‍ ‍

·        Event time.

‍ ‍

Normalize engineering events with:

‍ ‍

·        Controller identifier.

‍ ‍

·        Engineering source.

‍ ‍

·        User.

‍ ‍

·        Session.

‍ ‍

·        Project.

‍ ‍

·        Action category.

‍ ‍

·        Changed object.

‍ ‍

·        Prior state.

‍ ‍

·        New state.

‍ ‍

·        Process area.

‍ ‍

·        Criticality.

‍ ‍

·        Event time.

‍ ‍

Map access to the controllers reachable through the destination engineering workstation, OT jump host, HMI, vendor-support system, or other approved management path.

‍ ‍

Create an attributable actor key using the strongest available relationship:

‍ ‍

·        Stable remote-access or engineering session.

‍ ‍

·        User and source asset.

‍ ‍

·        User and source address when source-asset identity is unavailable.

‍ ‍

Do not correlate events when no stable actor or session relationship exists.

‍ ‍

Require the access event to precede the manipulation event within a locally validated maximum interval.

‍ ‍

Apply approved-source, approved-user, controller-scope, maintenance-window, work-order, and protected-object lookups before aggregation.

‍ ‍

Maintain a historical relationship lookup containing previously observed source, user, destination engineering system, and controller relationships. Populate first_seen_relationship from this lookup rather than referencing an undefined field.

‍ ‍

Treat maintenance windows as context rather than automatic suppression. Require the source, user, controller, project, action, changed object, and work order to align.

‍ ‍

Consolidate repeated commands from the same actor, controller, project, and engineering session into one alert.

‍ ‍

Rule 1 opens the initial unauthorized-manipulation alert.

‍ ‍

Rule 2 enriches or supersedes Rule 1 when loss of control, process impact, operator lockout, or critical latent risk is established.

‍ ‍

Rule 3 creates a separate expansion alert when multiple controllers, process areas, facilities, or sites are involved.

‍ ‍

Deduplicate Rule 1 by:

‍ ‍

·        Controller identifier.

‍ ‍

·        Actor or access session.

‍ ‍

·        User.

‍ ‍

·        Project or change identifier.

‍ ‍

·        Manipulation category.

‍ ‍

·        Bounded activity window.

‍ ‍

Re-alert when severity increases, a different changed object appears, a new actor or session is involved, a new controller is affected, or activity resumes after the local quiet period.

‍ ‍

Use risk-based alerting where available. Assign risk to the controller, engineering asset, and attributable user while retaining the normalized alert classification.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when access, controller, engineering, asset, and change-management fields are consistently normalized and controller relationships are accurate.

‍ ‍

Reliability decreases when stable sessions are absent, shared accounts are common, source assets cannot be resolved, or controller changes are visible only as generic writes.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.2

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong where access and controller-change telemetry is centralized in Splunk.

‍ ‍

Full telemetry adds authoritative controller audit, project integrity, HMI/SCADA, historian, operator, and process evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.9

‍ ‍

Full-Telemetry TCR

‍ ‍

9.6

‍ ‍

Limitations

‍ ‍

·        Local, serial, removable-media, or unmonitored engineering activity may not appear in Splunk.

‍ ‍

·        Proprietary or encrypted protocols may conceal the exact controller action.

‍ ‍

·        Shared accounts, NAT, and common jump hosts may weaken attribution.

‍ ‍

·        Project upload may represent approved backup, troubleshooting, or state comparison.

‍ ‍

·        Asset, relationship, and change-management lookups may be incomplete or stale.

‍ ‍

·        Endpoint or access evidence alone does not prove PLC manipulation.

‍ ‍

·        Events without a stable actor or session relationship may require separate investigation.

‍ ‍

·        Missing time synchronization may disrupt event ordering.

‍ ‍

·        The append subsearch limits must be tuned or replaced with summary-index or accelerated data-model searches in high-volume environments.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following SPL after mapping local indexes, sourcetypes, fields, relationship lookups, and thresholds.

‍ ‍

search index=<OT_ACCESS_INDEX>

‍ ‍

sourcetype IN (

‍ ‍

    <VPN_SOURCETYPE>,

‍ ‍

    <REMOTE_ACCESS_SOURCETYPE>,

‍ ‍

    <JUMP_HOST_SOURCETYPE>,

‍ ‍

    <FIREWALL_SOURCETYPE>,

‍ ‍

    <CELLULAR_GATEWAY_SOURCETYPE>

‍ ‍

)

‍ ‍

action IN ("success", "allowed", "connected", "login_success")

‍ ‍

| eval event_stage="access"

‍ ‍

| eval engineering_system_id=coalesce(engineering_asset_id, dest_asset_id, dest)

‍ ‍

| lookup engineering_system_controller_scope

‍ ‍

    engineering_system_id

‍ ‍

    OUTPUT controller_id

‍ ‍

| mvexpand controller_id

‍ ‍

| lookup approved_ot_access

‍ ‍

    source

‍ ‍

    user

‍ ‍

    engineering_system_id

‍ ‍

    controller_id

‍ ‍

    OUTPUT approved_access, approved_scope, approved_window

‍ ‍

| lookup historical_ot_access_relationships

‍ ‍

    source

‍ ‍

    user

‍ ‍

    engineering_system_id

‍ ‍

    controller_id

‍ ‍

    OUTPUT relationship_previously_seen

‍ ‍

| eval first_seen_relationship=if(

‍ ‍

    coalesce(relationship_previously_seen, "false")="true",

‍ ‍

    0,

‍ ‍

    1

‍ ‍

)

‍ ‍

| eval access_suspicious=if(

‍ ‍

    coalesce(approved_access, "false")!="true"

‍ ‍

    OR coalesce(approved_scope, "false")!="true"

‍ ‍

    OR coalesce(approved_window, "false")!="true"

‍ ‍

    OR in(source_zone, "internet", "cellular", "unapproved_it")

‍ ‍

    OR first_seen_relationship=1,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| where access_suspicious=1

‍ ‍

| eval actor_key=case(

‍ ‍

    isnotnull(session_id),

‍ ‍

        "session|".session_id,

‍ ‍

    isnotnull(user) AND isnotnull(source_asset_id),

‍ ‍

        "user_asset|".user."|".source_asset_id,

‍ ‍

    isnotnull(user) AND isnotnull(source),

‍ ‍

        "user_source|".user."|".source,

‍ ‍

    true(),

‍ ‍

        null()

‍ ‍

)

‍ ‍

| where isnotnull(actor_key) AND isnotnull(controller_id)

‍ ‍

| eval access_time=_time

‍ ‍

| fields _time event_stage controller_id actor_key access_time source

‍ ‍

         source_asset_id user session_id engineering_system_id source_zone

‍ ‍

         access_path first_seen_relationship approved_access approved_scope

‍ ‍

         approved_window

‍ ‍

| append maxout=<APPEND_MAX_RESULTS> [

‍ ‍

    search index=<OT_ENGINEERING_INDEX>

‍ ‍

    sourcetype IN (

‍ ‍

        <INDUSTRIAL_NDR_SOURCETYPE>,

‍ ‍

        <PLC_AUDIT_SOURCETYPE>,

‍ ‍

        <ENGINEERING_SOFTWARE_SOURCETYPE>

‍ ‍

    )

‍ ‍

    normalized_action IN (

‍ ‍

        "project_upload",

‍ ‍

        "project_download",

‍ ‍

        "download_all",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "routine_change",

‍ ‍

        "function_block_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_update",

‍ ‍

        "firmware_replacement",

‍ ‍

        "firmware_update_mode",

‍ ‍

        "controller_reset",

‍ ‍

        "memory_clear",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change"

‍ ‍

    )

‍ ‍

    | eval event_stage=if(

‍ ‍

        normalized_action="project_upload",

‍ ‍

        "project_upload",

‍ ‍

        "manipulation"

‍ ‍

    )

‍ ‍

    | eval controller_id=coalesce(controller_id, dest_asset_id, dest)

‍ ‍

    | eval actor_key=case(

‍ ‍

        isnotnull(session_id),

‍ ‍

            "session|".session_id,

‍ ‍

        isnotnull(user) AND isnotnull(source_asset_id),

‍ ‍

            "user_asset|".user."|".source_asset_id,

‍ ‍

        isnotnull(user) AND isnotnull(source),

‍ ‍

            "user_source|".user."|".source,

‍ ‍

        true(),

‍ ‍

            null()

‍ ‍

    )

‍ ‍

    | where isnotnull(actor_key) AND isnotnull(controller_id)

‍ ‍

    | lookup approved_controller_changes

‍ ‍

        controller_id

‍ ‍

        source

‍ ‍

        user

‍ ‍

        project_id

‍ ‍

        normalized_action

‍ ‍

        OUTPUT approved_change, approved_destination, protected_object,

‍ ‍

               treatment_critical, safety_relevant, hidden_or_conditional,

‍ ‍

               interlock_or_permissive, critical_process_parameter

‍ ‍

    | eval change_unauthorized=if(

‍ ‍

        coalesce(approved_change, "false")!="true",

‍ ‍

        1,

‍ ‍

        0

‍ ‍

    )

‍ ‍

    | eval upload_suspicious=if(

‍ ‍

        normalized_action="project_upload"

‍ ‍

        AND (

‍ ‍

            change_unauthorized=1

‍ ‍

            OR coalesce(approved_destination, "false")!="true"

‍ ‍

        ),

‍ ‍

        1,

‍ ‍

        0

‍ ‍

    )

‍ ‍

    | eventstats

‍ ‍

        dc(eval(if(normalized_action="project_upload", controller_id, null())))

‍ ‍

            AS uploaded_controller_count

‍ ‍

        BY actor_key

‍ ‍

    | eval upload_suspicious=if(

‍ ‍

        normalized_action="project_upload"

‍ ‍

        AND (

‍ ‍

            upload_suspicious=1

‍ ‍

            OR uploaded_controller_count>=<MULTI_CONTROLLER_UPLOAD_THRESHOLD>

‍ ‍

        ),

‍ ‍

        1,

‍ ‍

        upload_suspicious

‍ ‍

    )

‍ ‍

    | where change_unauthorized=1 OR upload_suspicious=1

‍ ‍

    | eval engineering_time=_time

‍ ‍

    | fields _time event_stage controller_id actor_key engineering_time

‍ ‍

             source source_asset_id user session_id project_id

‍ ‍

             normalized_action changed_object prior_state new_state

‍ ‍

             process_area approved_change approved_destination

‍ ‍

             upload_suspicious uploaded_controller_count protected_object

‍ ‍

             treatment_critical safety_relevant hidden_or_conditional

‍ ‍

             interlock_or_permissive critical_process_parameter

‍ ‍

]

‍ ‍

| sort 0 controller_id actor_key _time

‍ ‍

| stats

‍ ‍

    earliest(access_time) AS access_time

‍ ‍

    earliest(eval(if(event_stage="manipulation", engineering_time, null())))

‍ ‍

        AS manipulation_time

‍ ‍

    earliest(eval(if(event_stage="project_upload", engineering_time, null())))

‍ ‍

        AS upload_time

‍ ‍

    values(source) AS sources

‍ ‍

    values(source_asset_id) AS source_assets

‍ ‍

    values(user) AS users

‍ ‍

    values(session_id) AS sessions

‍ ‍

    values(engineering_system_id) AS engineering_systems

‍ ‍

    values(project_id) AS projects

‍ ‍

    values(normalized_action) AS engineering_actions

‍ ‍

    values(changed_object) AS changed_objects

‍ ‍

    values(prior_state) AS prior_states

‍ ‍

    values(new_state) AS new_states

‍ ‍

    values(process_area) AS process_areas

‍ ‍

    max(upload_suspicious) AS upload_suspicious

‍ ‍

    max(uploaded_controller_count) AS uploaded_controller_count

‍ ‍

    max(treatment_critical) AS treatment_critical

‍ ‍

    max(safety_relevant) AS safety_relevant

‍ ‍

    max(hidden_or_conditional) AS hidden_or_conditional

‍ ‍

    max(interlock_or_permissive) AS interlock_or_permissive

‍ ‍

    max(critical_process_parameter) AS critical_process_parameter

‍ ‍

    BY controller_id actor_key

‍ ‍

| eval access_precedes_manipulation=if(

‍ ‍

    isnotnull(access_time)

‍ ‍

    AND isnotnull(manipulation_time)

‍ ‍

    AND access_time<manipulation_time

‍ ‍

    AND manipulation_time-access_time<=<MAX_ACCESS_TO_CHANGE_SECONDS>,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| eval access_precedes_upload=if(

‍ ‍

    isnotnull(access_time)

‍ ‍

    AND isnotnull(upload_time)

‍ ‍

    AND access_time<upload_time

‍ ‍

    AND upload_time-access_time<=<MAX_ACCESS_TO_UPLOAD_SECONDS>,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| eval upload_followed_by_manipulation=if(

‍ ‍

    isnotnull(upload_time)

‍ ‍

    AND isnotnull(manipulation_time)

‍ ‍

    AND upload_time<manipulation_time

‍ ‍

    AND manipulation_time-upload_time<=<MAX_UPLOAD_TO_CHANGE_SECONDS>,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| where access_precedes_manipulation=1

‍ ‍

    OR (

‍ ‍

        upload_suspicious=1

‍ ‍

        AND (

‍ ‍

            access_precedes_upload=1

‍ ‍

            OR upload_followed_by_manipulation=1

‍ ‍

            OR uploaded_controller_count>=<MULTI_CONTROLLER_UPLOAD_THRESHOLD>

‍ ‍

        )

‍ ‍

    )

‍ ‍

| eval critical_manipulation=if(

‍ ‍

    treatment_critical=1

‍ ‍

    OR safety_relevant=1

‍ ‍

    OR hidden_or_conditional=1

‍ ‍

    OR interlock_or_permissive=1

‍ ‍

    OR critical_process_parameter=1,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| eval alert_classification=case(

‍ ‍

    access_precedes_manipulation=1 AND critical_manipulation=1,

‍ ‍

        "Critical manipulation or latent process risk",

‍ ‍

    access_precedes_manipulation=1,

‍ ‍

        "Confirmed unauthorized manipulation",

‍ ‍

    upload_suspicious=1,

‍ ‍

        "Suspicious engineering access",

‍ ‍

    true(),

‍ ‍

        "Suspicious engineering access"

‍ ‍

)

‍ ‍

| eval first_activity_time=coalesce(access_time, upload_time)

‍ ‍

| eval last_activity_time=coalesce(manipulation_time, upload_time)

‍ ‍

| eval dedup_key=controller_id."|".actor_key."|".

‍ ‍

    coalesce(mvindex(projects, 0), "no_project")."|".alert_classification

‍ ‍

| table controller_id actor_key first_activity_time last_activity_time

‍ ‍

        sources source_assets users sessions engineering_systems projects

‍ ‍

        engineering_actions changed_objects prior_states new_states

‍ ‍

        process_areas uploaded_controller_count alert_classification dedup_key

‍ ‍

Rule

‍ ‍

Controller or HMI Manipulation Followed by Loss of Control or Process Deviation

‍ ‍

Rule Format

‍ ‍

Splunk SPL correlation search

‍ ‍

Detection Purpose

‍ ‍

Detect unauthorized controller, HMI, or SCADA manipulation followed by communications loss, operator lockout, controller instability, threshold-confirmed process deviation, manual-operation transition, or operational impact, while also identifying confirmed critical manipulation with unresolved latent consequences.

‍ ‍

Detection Logic

‍ ‍

Implement two independent branches within one durable rule.

‍ ‍

The first branch correlates an unauthorized or unexplained controller, HMI, or SCADA change with subsequent impact.

‍ ‍

Qualifying manipulation includes:

‍ ‍

·        PLC program, logic, task, routine, parameter, credential, network, firmware, reset, restore, or mode changes.

‍ ‍

·        HMI or SCADA set-point, alarm, tag, display, account, administrative, control-mode, or manual-command changes.

‍ ‍

·        Interlock, permissive, protection, treatment-limit, or critical process-parameter changes.

‍ ‍

Qualifying impact includes:

‍ ‍

·        Controller communications loss.

‍ ‍

·        Controller fault, stop, restart, reset, or project mismatch.

‍ ‍

·        Failed legitimate operator or engineering access.

‍ ‍

·        Loss of view or loss of control.

‍ ‍

·        Stale or inconsistent process values.

‍ ‍

·        Process deviation outside an approved engineering, safety, operating, laboratory, or water-quality threshold.

‍ ‍

·        Manual-operation transition.

‍ ‍

·        Process shutdown.

‍ ‍

·        Boil-water notice.

‍ ‍

·        Wastewater-release concern.

‍ ‍

·        Service interruption.

‍ ‍

The second branch identifies authoritatively confirmed critical manipulation without requiring observed impact.

‍ ‍

This branch applies to confirmed unauthorized changes involving:

‍ ‍

·        Treatment-critical or safety-relevant logic.

‍ ‍

·        Hidden, dormant, delayed, or conditionally activated logic.

‍ ‍

·        Interlocks, permissives, protection logic, or alarm enforcement.

‍ ‍

·        Chemical-dosing or treatment limits.

‍ ‍

·        Critical pressure, flow, level, sequencing, or process parameters.

‍ ‍

·        Multiple controllers.

‍ ‍

·        Malicious project downloads with unresolved latent consequences.

‍ ‍

Use same-controller correlation first.

‍ ‍

Where the change and consequence involve different assets, require an explicit HMI-to-controller, SCADA-to-controller, controller-to-equipment, controller-to-historian-tag, controller-to-remote-I/O, or controller-to-field-device relationship.

‍ ‍

Use process-area correlation only as a fallback with stricter independent-evidence requirements.

‍ ‍

Required Telemetry

‍ ‍

·        Industrial NDR, controller audit, or engineering audit events.

‍ ‍

·        HMI and SCADA command, configuration, alarm, account, and tag-change logs.

‍ ‍

·        Controller state and communications telemetry.

‍ ‍

·        Historian and process-variable data.

‍ ‍

·        Independent sensor or field-device data where available.

‍ ‍

·        Operator-lockout and manual-operation records.

‍ ‍

·        Laboratory and water-quality data where available.

‍ ‍

·        Service-impact and incident records.

‍ ‍

·        Controller, HMI, SCADA, historian, equipment, sensor, and process-area relationship mappings.

‍ ‍

·        Approved process thresholds.

‍ ‍

·        Maintenance-window and change-management records.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize each change event with:

‍ ‍

·        Controller identifier.

‍ ‍

·        Change identifier.

‍ ‍

·        Changed system.

‍ ‍

·        Source.

‍ ‍

·        User.

‍ ‍

·        Session.

‍ ‍

·        Project.

‍ ‍

·        Action.

‍ ‍

·        Changed object.

‍ ‍

·        Prior state.

‍ ‍

·        New state.

‍ ‍

·        Process area.

‍ ‍

·        Criticality.

‍ ‍

·        Event time.

‍ ‍

Create a stable change identifier using the native change or project identifier where available. Otherwise, derive one from the controller, source or session, user, action, changed object, and bounded time bucket.

‍ ‍

Normalize each impact event with:

‍ ‍

·        Direct controller identifier where present.

‍ ‍

·        Affected asset.

‍ ‍

·        Impact category.

‍ ‍

·        Evidence source.

‍ ‍

·        Data path.

‍ ‍

·        Sensor or system identifier.

‍ ‍

·        Independence status.

‍ ‍

·        Threshold.

‍ ‍

·        Threshold direction.

‍ ‍

·        Duration.

‍ ‍

·        Rate of change.

‍ ‍

·        Repetition count.

‍ ‍

·        Operating phase.

‍ ‍

·        Maintenance status.

‍ ‍

·        Event time.

‍ ‍

Resolve impact-to-controller relationships in this order:

‍ ‍

·        Direct controller identity.

‍ ‍

·        Explicit asset-dependency lookup.

‍ ‍

·        Process-area-to-controller fallback.

‍ ‍

Retain the correlation method for every impact event.

‍ ‍

For process-area fallback, require at least two independent evidence paths or one independently validated critical signal.

‍ ‍

Create an independent-evidence key from the source system, data path, and sensor or affected asset. Count distinct independent-evidence keys rather than distinct impact-category names.

‍ ‍

Require locally validated minimum duration, repetition, threshold, rate-of-change, operating-phase, and maintenance conditions.

‍ ‍

A single transient communications loss, restart, stale value, or threshold crossing must not satisfy the impact branch unless independently classified as critical.

‍ ‍

Correlate each impact event to the most recent qualifying prior change for the same resolved controller. Use streamstats to carry the most recent change context forward in time.

‍ ‍

Do not aggregate all changes and impacts for a controller across the complete scheduled search window.

‍ ‍

Implement the critical-latent branch separately and append its results after the change-to-impact correlation.

‍ ‍

Locate the related Rule 1 alert using the controller, change identifier, source or session, user, project, and bounded activity window.

‍ ‍

Where alert updating is supported, enrich or supersede Rule 1 rather than creating a duplicate notable.

‍ ‍

Where updating is unavailable, create Rule 2 and retain the related Rule 1 identifier.

‍ ‍

Deduplicate Rule 2 by:

‍ ‍

·        Controller identifier.

‍ ‍

·        Change identifier.

‍ ‍

·        Impact category or critical-latent category.

‍ ‍

·        Bounded correlation window.

‍ ‍

Re-alert when severity increases, a new independent consequence appears, a new controller or process area is affected, or activity resumes after the quiet period.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when authoritative change evidence maps to the same controller or an explicit dependent asset and the impact satisfies validated threshold and evidence-independence controls.

‍ ‍

Reliability decreases when process evidence is not independent, relationship mappings are incomplete, or impact events are transient.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.3

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong where controller, HMI/SCADA, communications, and process telemetry is centralized.

‍ ‍

Full coverage requires independent process evidence, reliable asset relationships, approved thresholds, operator records, and laboratory or field validation where appropriate.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

9.0

‍ ‍

Full-Telemetry TCR

‍ ‍

9.7

‍ ‍

Limitations

‍ ‍

·        Process effects may be delayed or conditional.

‍ ‍

·        HMI, historian, and controller telemetry may share the same manipulated data source.

‍ ‍

·        Equipment failure, sensor failure, maintenance, environmental conditions, or operator error may resemble cyber-induced deviation.

‍ ‍

·        Process-area fallback is less reliable than direct controller or explicit dependency correlation.

‍ ‍

·        Process data may be delayed, down-sampled, filtered, or incomplete.

‍ ‍

·        Local or serial controller changes may lack a visible initiating event.

‍ ‍

·        Not all facilities centralize operator, laboratory, or service-impact records.

‍ ‍

·        Time misalignment can disrupt sequence evaluation.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following SPL after mapping local change, impact, relationship, threshold, and alert-tracking fields.

‍ ‍

search index=<OT_CHANGE_INDEX>

‍ ‍

sourcetype IN (

‍ ‍

    <INDUSTRIAL_NDR_SOURCETYPE>,

‍ ‍

    <PLC_AUDIT_SOURCETYPE>,

‍ ‍

    <ENGINEERING_SOFTWARE_SOURCETYPE>,

‍ ‍

    <HMI_SCADA_AUDIT_SOURCETYPE>

‍ ‍

)

‍ ‍

normalized_action IN (

‍ ‍

    "project_download",

‍ ‍

    "online_edit",

‍ ‍

    "program_append",

‍ ‍

    "logic_change",

‍ ‍

    "task_change",

‍ ‍

    "parameter_change",

‍ ‍

    "credential_change",

‍ ‍

    "network_configuration_change",

‍ ‍

    "firmware_change",

‍ ‍

    "controller_reset",

‍ ‍

    "project_restore",

‍ ‍

    "operating_mode_change",

‍ ‍

    "hmi_setpoint_change",

‍ ‍

    "alarm_configuration_change",

‍ ‍

    "tag_change",

‍ ‍

    "manual_command",

‍ ‍

    "administrative_change"

‍ ‍

)

‍ ‍

| eval event_stage="change"

‍ ‍

| eval correlation_controller=coalesce(controller_id, related_controller_id)

‍ ‍

| lookup approved_controller_changes

‍ ‍

    correlation_controller

‍ ‍

    source

‍ ‍

    user

‍ ‍

    project_id

‍ ‍

    normalized_action

‍ ‍

    OUTPUT approved_change, treatment_critical, safety_relevant,

‍ ‍

           hidden_or_conditional, interlock_or_permissive,

‍ ‍

           critical_process_parameter

‍ ‍

| where coalesce(approved_change, "false")!="true"

‍ ‍

| eval change_id=coalesce(

‍ ‍

    change_event_id,

‍ ‍

    project_id,

‍ ‍

    md5(

‍ ‍

        correlation_controller."|".coalesce(session_id, source, "no_source").

‍ ‍

        "|".coalesce(user, "no_user")."|".normalized_action."|".

‍ ‍

        coalesce(changed_object, "no_object")."|".

‍ ‍

        tostring(floor(_time/<CHANGE_ID_BUCKET_SECONDS>))

‍ ‍

    )

‍ ‍

)

‍ ‍

| eval change_time=_time

‍ ‍

| fields _time event_stage correlation_controller change_id change_time

‍ ‍

         source user session_id project_id normalized_action changed_object

‍ ‍

         prior_state new_state process_area treatment_critical

‍ ‍

         safety_relevant hidden_or_conditional interlock_or_permissive

‍ ‍

         critical_process_parameter

‍ ‍

| append maxout=<APPEND_MAX_RESULTS> [

‍ ‍

    search index=<OT_IMPACT_INDEX>

‍ ‍

    sourcetype IN (

‍ ‍

        <CONTROLLER_STATE_SOURCETYPE>,

‍ ‍

        <HMI_SCADA_EVENT_SOURCETYPE>,

‍ ‍

        <HISTORIAN_SOURCETYPE>,

‍ ‍

        <PROCESS_SENSOR_SOURCETYPE>,

‍ ‍

        <OPERATOR_EVENT_SOURCETYPE>,

‍ ‍

        <LABORATORY_EVENT_SOURCETYPE>

‍ ‍

    )

‍ ‍

    impact_category IN (

‍ ‍

        "communications_loss",

‍ ‍

        "controller_fault",

‍ ‍

        "controller_stop",

‍ ‍

        "controller_restart",

‍ ‍

        "project_mismatch",

‍ ‍

        "operator_lockout",

‍ ‍

        "loss_of_view",

‍ ‍

        "loss_of_control",

‍ ‍

        "stale_process_value",

‍ ‍

        "inconsistent_process_value",

‍ ‍

        "process_threshold_breach",

‍ ‍

        "manual_operations",

‍ ‍

        "service_interruption"

‍ ‍

    )

‍ ‍

    | eval event_stage="impact"

‍ ‍

    | eval direct_controller_id=controller_id

‍ ‍

    | lookup ot_asset_controller_relationships

‍ ‍

        affected_asset

‍ ‍

        OUTPUT related_controller_id, relationship_type

‍ ‍

    | lookup ot_process_area_controller_map

‍ ‍

        process_area

‍ ‍

        OUTPUT process_area_controller_id

‍ ‍

    | eval correlation_controller=case(

‍ ‍

        isnotnull(direct_controller_id),

‍ ‍

            direct_controller_id,

‍ ‍

        isnotnull(related_controller_id),

‍ ‍

            related_controller_id,

‍ ‍

        isnotnull(process_area_controller_id),

‍ ‍

            process_area_controller_id,

‍ ‍

        true(),

‍ ‍

            null()

‍ ‍

    )

‍ ‍

    | eval correlation_method=case(

‍ ‍

        isnotnull(direct_controller_id),

‍ ‍

            "direct_controller",

‍ ‍

        isnotnull(related_controller_id),

‍ ‍

            "explicit_dependency",

‍ ‍

        isnotnull(process_area_controller_id),

‍ ‍

            "process_area_fallback",

‍ ‍

        true(),

‍ ‍

            "unresolved"

‍ ‍

    )

‍ ‍

    | where isnotnull(correlation_controller)

‍ ‍

    | lookup approved_process_thresholds

‍ ‍

        process_variable

‍ ‍

        process_area

‍ ‍

        operating_phase

‍ ‍

        OUTPUT approved_threshold, minimum_duration,

‍ ‍

               minimum_repetitions, maximum_rate_of_change

‍ ‍

    | eval threshold_conditions_met=if(

‍ ‍

        isnotnull(approved_threshold)

‍ ‍

        AND threshold_breached="true"

‍ ‍

        AND duration_seconds>=minimum_duration

‍ ‍

        AND repetition_count>=minimum_repetitions

‍ ‍

        AND (

‍ ‍

            isnull(maximum_rate_of_change)

‍ ‍

            OR abs(rate_of_change)>=maximum_rate_of_change

‍ ‍

        )

‍ ‍

        AND coalesce(maintenance_status, "false")!="true",

‍ ‍

        1,

‍ ‍

        0

‍ ‍

    )

‍ ‍

    | eval impact_valid=if(

‍ ‍

        threshold_conditions_met=1

‍ ‍

        OR independently_critical="true",

‍ ‍

        1,

‍ ‍

        0

‍ ‍

    )

‍ ‍

    | where impact_valid=1

‍ ‍

    | eval independent_evidence_key=if(

‍ ‍

        evidence_independent="true",

‍ ‍

        coalesce(evidence_source, "unknown_source")."|".

‍ ‍

        coalesce(data_path, "unknown_path")."|".

‍ ‍

        coalesce(sensor_id, affected_asset, "unknown_asset"),

‍ ‍

        null()

‍ ‍

    )

‍ ‍

    | eval impact_time=_time

‍ ‍

    | fields _time event_stage correlation_controller correlation_method

‍ ‍

             impact_time affected_asset impact_category evidence_source

‍ ‍

             data_path sensor_id independent_evidence_key

‍ ‍

             independently_critical approved_threshold threshold_direction

‍ ‍

             duration_seconds rate_of_change repetition_count operating_phase

‍ ‍

             maintenance_status process_area

‍ ‍

]

‍ ‍

| sort 0 correlation_controller _time

‍ ‍

| streamstats current=f

‍ ‍

    last(change_id) AS prior_change_id

‍ ‍

    last(change_time) AS prior_change_time

‍ ‍

    last(source) AS prior_change_source

‍ ‍

    last(user) AS prior_change_user

‍ ‍

    last(session_id) AS prior_change_session

‍ ‍

    last(project_id) AS prior_change_project

‍ ‍

    last(normalized_action) AS prior_change_action

‍ ‍

    last(changed_object) AS prior_changed_object

‍ ‍

    last(prior_state) AS prior_state_value

‍ ‍

    last(new_state) AS prior_new_state

‍ ‍

    last(treatment_critical) AS prior_treatment_critical

‍ ‍

    last(safety_relevant) AS prior_safety_relevant

‍ ‍

    last(hidden_or_conditional) AS prior_hidden_or_conditional

‍ ‍

    last(interlock_or_permissive) AS prior_interlock_or_permissive

‍ ‍

    last(critical_process_parameter) AS prior_critical_process_parameter

‍ ‍

    BY correlation_controller

‍ ‍

| where event_stage="impact"

‍ ‍

    AND isnotnull(prior_change_id)

‍ ‍

    AND impact_time>prior_change_time

‍ ‍

    AND impact_time-prior_change_time<=<MAX_CHANGE_TO_IMPACT_SECONDS>

‍ ‍

| stats

‍ ‍

    earliest(prior_change_time) AS change_time

‍ ‍

    earliest(impact_time) AS first_impact_time

‍ ‍

    latest(impact_time) AS last_impact_time

‍ ‍

    values(prior_change_source) AS sources

‍ ‍

    values(prior_change_user) AS users

‍ ‍

    values(prior_change_session) AS sessions

‍ ‍

    values(prior_change_project) AS projects

‍ ‍

    values(prior_change_action) AS change_actions

‍ ‍

    values(prior_changed_object) AS changed_objects

‍ ‍

    values(prior_state_value) AS prior_states

‍ ‍

    values(prior_new_state) AS new_states

‍ ‍

    values(impact_category) AS impact_categories

‍ ‍

    values(evidence_source) AS evidence_sources

‍ ‍

    values(data_path) AS evidence_paths

‍ ‍

    values(sensor_id) AS sensor_ids

‍ ‍

    dc(independent_evidence_key) AS independent_evidence_paths

‍ ‍

    max(eval(if(independently_critical="true", 1, 0)))

‍ ‍

        AS independently_critical_impact

‍ ‍

    values(approved_threshold) AS thresholds

‍ ‍

    values(duration_seconds) AS durations

‍ ‍

    values(repetition_count) AS repetitions

‍ ‍

    values(correlation_method) AS correlation_methods

‍ ‍

    values(process_area) AS process_areas

‍ ‍

    BY correlation_controller prior_change_id

‍ ‍

| eval process_area_fallback_only=if(

‍ ‍

    mvcount(correlation_methods)=1

‍ ‍

    AND mvfind(correlation_methods, "^process_area_fallback$")=0,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| where (

‍ ‍

        process_area_fallback_only=0

‍ ‍

        AND (

‍ ‍

            independent_evidence_paths>=1

‍ ‍

            OR independently_critical_impact=1

‍ ‍

        )

‍ ‍

    )

‍ ‍

    OR (

‍ ‍

        process_area_fallback_only=1

‍ ‍

        AND (

‍ ‍

            independent_evidence_paths>=2

‍ ‍

            OR independently_critical_impact=1

‍ ‍

        )

‍ ‍

    )

‍ ‍

| eval alert_classification=

‍ ‍

    "Manipulation followed by loss of control or process deviation"

‍ ‍

| eval dedup_key=correlation_controller."|".prior_change_id."|impact"

‍ ‍

| append maxout=<APPEND_MAX_RESULTS> [

‍ ‍

    search index=<OT_CHANGE_INDEX>

‍ ‍

    sourcetype IN (

‍ ‍

        <INDUSTRIAL_NDR_SOURCETYPE>,

‍ ‍

        <PLC_AUDIT_SOURCETYPE>,

‍ ‍

        <ENGINEERING_SOFTWARE_SOURCETYPE>,

‍ ‍

        <HMI_SCADA_AUDIT_SOURCETYPE>

‍ ‍

    )

‍ ‍

    normalized_action IN (

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change",

‍ ‍

        "hmi_setpoint_change",

‍ ‍

        "alarm_configuration_change",

‍ ‍

        "tag_change",

‍ ‍

        "manual_command",

‍ ‍

        "administrative_change"

‍ ‍

    )

‍ ‍

    | eval correlation_controller=coalesce(

‍ ‍

        controller_id,

‍ ‍

        related_controller_id

‍ ‍

    )

‍ ‍

    | lookup approved_controller_changes

‍ ‍

        correlation_controller

‍ ‍

        source

‍ ‍

        user

‍ ‍

        project_id

‍ ‍

        normalized_action

‍ ‍

        OUTPUT approved_change, treatment_critical, safety_relevant,

‍ ‍

               hidden_or_conditional, interlock_or_permissive,

‍ ‍

               critical_process_parameter

‍ ‍

    | where coalesce(approved_change, "false")!="true"

‍ ‍

    | eval critical_latent=if(

‍ ‍

        treatment_critical=1

‍ ‍

        OR safety_relevant=1

‍ ‍

        OR hidden_or_conditional=1

‍ ‍

        OR interlock_or_permissive=1

‍ ‍

        OR critical_process_parameter=1,

‍ ‍

        1,

‍ ‍

        0

‍ ‍

    )

‍ ‍

    | where critical_latent=1

‍ ‍

    | eval prior_change_id=coalesce(

‍ ‍

        change_event_id,

‍ ‍

        project_id,

‍ ‍

        md5(

‍ ‍

            correlation_controller."|".coalesce(session_id, source, "no_source").

‍ ‍

            "|".coalesce(user, "no_user")."|".normalized_action."|".

‍ ‍

            coalesce(changed_object, "no_object")."|".

‍ ‍

            tostring(floor(_time/<CHANGE_ID_BUCKET_SECONDS>))

‍ ‍

        )

‍ ‍

    )

‍ ‍

    | eval change_time=_time

‍ ‍

    | eval first_impact_time=null()

‍ ‍

    | eval last_impact_time=null()

‍ ‍

    | eval sources=source

‍ ‍

    | eval users=user

‍ ‍

    | eval sessions=session_id

‍ ‍

    | eval projects=project_id

‍ ‍

    | eval change_actions=normalized_action

‍ ‍

    | eval changed_objects=changed_object

‍ ‍

    | eval prior_states=prior_state

‍ ‍

    | eval new_states=new_state

‍ ‍

    | eval impact_categories=null()

‍ ‍

    | eval evidence_sources=null()

‍ ‍

    | eval evidence_paths=null()

‍ ‍

    | eval sensor_ids=null()

‍ ‍

    | eval independent_evidence_paths=0

‍ ‍

    | eval thresholds=null()

‍ ‍

    | eval durations=null()

‍ ‍

    | eval repetitions=null()

‍ ‍

    | eval correlation_methods="authoritative_critical_change"

‍ ‍

    | eval process_areas=process_area

‍ ‍

    | eval alert_classification="Critical manipulation or latent process risk"

‍ ‍

    | eval dedup_key=correlation_controller."|".prior_change_id."|critical_latent"

‍ ‍

    | table correlation_controller prior_change_id change_time

‍ ‍

            first_impact_time last_impact_time sources users sessions

‍ ‍

            projects change_actions changed_objects prior_states new_states

‍ ‍

            impact_categories evidence_sources evidence_paths sensor_ids

‍ ‍

            independent_evidence_paths thresholds durations repetitions

‍ ‍

            correlation_methods process_areas alert_classification dedup_key

‍ ‍

]

‍ ‍

| stats

‍ ‍

    earliest(change_time) AS change_time

‍ ‍

    earliest(first_impact_time) AS first_impact_time

‍ ‍

    latest(last_impact_time) AS last_impact_time

‍ ‍

    values(sources) AS sources

‍ ‍

    values(users) AS users

‍ ‍

    values(sessions) AS sessions

‍ ‍

    values(projects) AS projects

‍ ‍

    values(change_actions) AS change_actions

‍ ‍

    values(changed_objects) AS changed_objects

‍ ‍

    values(prior_states) AS prior_states

‍ ‍

    values(new_states) AS new_states

‍ ‍

    values(impact_categories) AS impact_categories

‍ ‍

    values(evidence_sources) AS evidence_sources

‍ ‍

    values(evidence_paths) AS evidence_paths

‍ ‍

    values(sensor_ids) AS sensor_ids

‍ ‍

    max(independent_evidence_paths) AS independent_evidence_paths

‍ ‍

    values(thresholds) AS thresholds

‍ ‍

    values(durations) AS durations

‍ ‍

    values(repetitions) AS repetitions

‍ ‍

    values(correlation_methods) AS correlation_methods

‍ ‍

    values(process_areas) AS process_areas

‍ ‍

    values(alert_classification) AS classifications

‍ ‍

    BY correlation_controller prior_change_id dedup_key

‍ ‍

| eval alert_classification=if(

‍ ‍

    mvfind(classifications, "Critical manipulation or latent process risk")>=0,

‍ ‍

    "Critical manipulation or latent process risk",

‍ ‍

    "Manipulation followed by loss of control or process deviation"

‍ ‍

)

‍ ‍

| table correlation_controller prior_change_id change_time

‍ ‍

        first_impact_time last_impact_time sources users sessions projects

‍ ‍

        change_actions changed_objects prior_states new_states

‍ ‍

        impact_categories evidence_sources evidence_paths sensor_ids

‍ ‍

        independent_evidence_paths thresholds durations repetitions

‍ ‍

        correlation_methods process_areas alert_classification dedup_key

‍ ‍

Rule

‍ ‍

Multi-Controller or Cross-Facility Manipulation Expansion

‍ ‍

Rule Format

‍ ‍

Splunk SPL aggregation and entity-correlation search

‍ ‍

Detection Purpose

‍ ‍

Detect one source, identity, engineering workstation, remote-access session, project, artifact, or repeated change pattern performing unauthorized engineering or administrative activity across multiple controllers, process areas, facilities, or sites.

‍ ‍

Detection Logic

‍ ‍

Evaluate expansion through separate entity types:

‍ ‍

·        Engineering source or workstation.

‍ ‍

·        User or identity.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact.

‍ ‍

·        Repeated change pattern.

‍ ‍

Do not collapse different entity classes into one fallback value.

‍ ‍

Evaluate approved scope according to entity type:

‍ ‍

·        User-to-controller scope.

‍ ‍

·        Engineering-workstation-to-controller scope.

‍ ‍

·        Remote-session-to-site scope.

‍ ‍

·        Integrator-to-facility scope.

‍ ‍

·        Project-to-controller scope.

‍ ‍

·        Change-ticket-to-asset scope.

‍ ‍

Calculate scope authorization for every entity-target event before aggregation.

‍ ‍

Preserve the specific controllers that are outside approved scope even when other controllers in the same activity cluster are approved.

‍ ‍

Promote activity when an entity performs unauthorized or unexplained programming or administrative activity against:

‍ ‍

·        Multiple controllers outside approved scope.

‍ ‍

·        Multiple process areas not covered by the same work order.

‍ ‍

·        Multiple facilities or sites.

‍ ‍

·        Controller families or vendors not normally managed by that entity.

‍ ‍

·        A sequence consistent with discovery followed by manipulation.

‍ ‍

·        Multiple assets that later experience similar lockout, communications, fault, process, or manual-operation conditions.

‍ ‍

Do not assign an approved operational scope to a generic command pattern. Evaluate repeated patterns through rarity, target distribution, timing, similarity, and associated identities or assets.

‍ ‍

Required Telemetry

‍ ‍

·        Industrial NDR, PLC audit, engineering-software, and HMI/SCADA events.

‍ ‍

·        Source asset.

‍ ‍

·        User.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact identifier.

‍ ‍

·        Normalized action.

‍ ‍

·        Changed-object type.

‍ ‍

·        Controller identifier.

‍ ‍

·        Controller vendor and family.

‍ ‍

·        Process area.

‍ ‍

·        Facility and site.

‍ ‍

·        Historical entity-to-controller relationships.

‍ ‍

·        Entity-specific scope lookups.

‍ ‍

·        Work orders and maintenance windows.

‍ ‍

·        Controller impact and Rule 1 or Rule 2 alert identifiers where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Create distinct entity records for:

‍ ‍

·        Source asset.

‍ ‍

·        User.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact.

‍ ‍

·        Repeated change pattern.

‍ ‍

Use an explicit entity_type and entity_id for each record.

‍ ‍

Do not combine user, source, session, project, source address, or command pattern through coalesce.

‍ ‍

Evaluate each entity-target event against its corresponding approved-scope lookup before aggregation.

‍ ‍

Use source address as an entity only when NAT, source-asset, network-location, or session context establishes that it represents a stable source.

‍ ‍

Define local thresholds according to facility size, controller density, centralized engineering practices, and legitimate multi-site administration.

‍ ‍

Avoid count-only detection. Include:

‍ ‍

·        Approved scope.

‍ ‍

·        Target rarity.

‍ ‍

·        Cross-zone movement.

‍ ‍

·        Cross-facility activity.

‍ ‍

·        Work-order alignment.

‍ ‍

·        Change similarity.

‍ ‍

·        Time distribution.

‍ ‍

·        Controller criticality.

‍ ‍

·        Subsequent impact.

‍ ‍

Use a sessionized activity cluster based on the elapsed time between consecutive events for the same entity.

‍ ‍

Start a new cluster when the gap exceeds the locally defined maximum cluster pause.

‍ ‍

Do not use the time bucket itself as the final aggregation identity.

‍ ‍

Preserve every affected controller, out-of-scope controller, process area, facility, and site in the alert.

‍ ‍

Rule 3 remains a separate expansion alert and references related Rule 1 and Rule 2 alerts rather than recreating their controller-level evidence.

‍ ‍

Deduplicate Rule 3 by:

‍ ‍

·        Primary entity type.

‍ ‍

·        Primary entity identifier.

‍ ‍

·        Activity-cluster identifier.

‍ ‍

·        Affected controller set.

‍ ‍

·        Bounded aggregation period.

‍ ‍

Re-alert when a new facility or site is affected, the controller set materially expands, severity increases, a new impact category appears, activity resumes after the quiet period, or a separate activity cluster is identified.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when source assets, identities, sessions, projects, facilities, controller mappings, and approved scopes are maintained accurately.

‍ ‍

Reliability decreases in centralized engineering environments with broad legitimate access, shared accounts, NAT, or weak work-order records.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.0

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong for centralized network-visible expansion.

‍ ‍

Full telemetry improves attribution through engineering audit, identity, project, remote-access, change-management, controller-state, and process-impact evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.9

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5

‍ ‍

Limitations

‍ ‍

·        Central engineering teams and integrators may legitimately access many controllers.

‍ ‍

·        Shared accounts, NAT, and jump hosts may obscure the responsible entity.

‍ ‍

·        Local or serial programming may not be centrally visible.

‍ ‍

·        Vendor protocols may normalize similar actions differently.

‍ ‍

·        Low-and-slow activity may span beyond the configured cluster pause.

‍ ‍

·        Incomplete facility, project, identity, or approved-scope mappings may weaken correlation.

‍ ‍

·        Common projects or command patterns may appear in legitimate fleet operations.

‍ ‍

·        Excessively long cluster pauses may merge unrelated engineering work.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following SPL after mapping entity fields, entity-specific scope lookups, thresholds, and cluster timing.

‍ ‍

search index=<OT_ENGINEERING_INDEX>

‍ ‍

sourcetype IN (

‍ ‍

    <INDUSTRIAL_NDR_SOURCETYPE>,

‍ ‍

    <PLC_AUDIT_SOURCETYPE>,

‍ ‍

    <ENGINEERING_SOFTWARE_SOURCETYPE>,

‍ ‍

    <HMI_SCADA_AUDIT_SOURCETYPE>

‍ ‍

)

‍ ‍

normalized_action IN (

‍ ‍

    "project_upload",

‍ ‍

    "project_download",

‍ ‍

    "online_edit",

‍ ‍

    "program_append",

‍ ‍

    "logic_change",

‍ ‍

    "task_change",

‍ ‍

    "routine_change",

‍ ‍

    "function_block_change",

‍ ‍

    "parameter_change",

‍ ‍

    "credential_change",

‍ ‍

    "network_configuration_change",

‍ ‍

    "firmware_change",

‍ ‍

    "controller_reset",

‍ ‍

    "project_restore",

‍ ‍

    "operating_mode_change",

‍ ‍

    "hmi_administrative_change",

‍ ‍

    "hmi_setpoint_change",

‍ ‍

    "alarm_configuration_change"

‍ ‍

)

‍ ‍

| lookup approved_controller_changes

‍ ‍

    controller_id

‍ ‍

    source_asset

‍ ‍

    user

‍ ‍

    project_id

‍ ‍

    normalized_action

‍ ‍

    OUTPUT approved_change

‍ ‍

| where coalesce(approved_change, "false")!="true"

‍ ‍

| eval source_entity=if(

‍ ‍

    isnotnull(source_asset),

‍ ‍

    "source_asset|".source_asset,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval user_entity=if(

‍ ‍

    isnotnull(user),

‍ ‍

    "user|".user,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval session_entity=if(

‍ ‍

    isnotnull(remote_session_id),

‍ ‍

    "remote_session|".remote_session_id,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval project_entity=if(

‍ ‍

    isnotnull(project_id),

‍ ‍

    "project|".project_id,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval pattern_entity=if(

‍ ‍

    isnotnull(normalized_action)

‍ ‍

    AND isnotnull(changed_object_type),

‍ ‍

    "change_pattern|".normalized_action."|".changed_object_type,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval entity=mvappend(

‍ ‍

    source_entity,

‍ ‍

    user_entity,

‍ ‍

    session_entity,

‍ ‍

    project_entity,

‍ ‍

    pattern_entity

‍ ‍

)

‍ ‍

| mvexpand entity

‍ ‍

| where isnotnull(entity)

‍ ‍

| rex field=entity "^(?<entity_type>[^|]+)\|(?<entity_id>.+)$"

‍ ‍

| eval scope_entity_id=case(

‍ ‍

    entity_type="source_asset",

‍ ‍

        source_asset,

‍ ‍

    entity_type="user",

‍ ‍

        user,

‍ ‍

    entity_type="remote_session",

‍ ‍

        remote_session_id,

‍ ‍

    entity_type="project",

‍ ‍

        project_id,

‍ ‍

    true(),

‍ ‍

        null()

‍ ‍

)

‍ ‍

| lookup approved_ot_entity_target_scope

‍ ‍

    entity_type

‍ ‍

    scope_entity_id

‍ ‍

    controller_id

‍ ‍

    facility_id

‍ ‍

    site_id

‍ ‍

    OUTPUT scope_approved

‍ ‍

| eval out_of_scope=case(

‍ ‍

    entity_type="change_pattern",

‍ ‍

        null(),

‍ ‍

    coalesce(scope_approved, "false")="true",

‍ ‍

        0,

‍ ‍

    true(),

‍ ‍

        1

‍ ‍

)

‍ ‍

| eval out_of_scope_controller=if(

‍ ‍

    out_of_scope=1,

‍ ‍

    controller_id,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval out_of_scope_process_area=if(

‍ ‍

    out_of_scope=1,

‍ ‍

    process_area,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval out_of_scope_facility=if(

‍ ‍

    out_of_scope=1,

‍ ‍

    facility_id,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| eval out_of_scope_site=if(

‍ ‍

    out_of_scope=1,

‍ ‍

    site_id,

‍ ‍

    null()

‍ ‍

)

‍ ‍

| sort 0 entity_type entity_id _time

‍ ‍

| streamstats current=f

‍ ‍

    last(_time) AS previous_event_time

‍ ‍

    BY entity_type entity_id

‍ ‍

| eval new_activity_cluster=if(

‍ ‍

    isnull(previous_event_time)

‍ ‍

    OR _time-previous_event_time><MAX_CLUSTER_PAUSE_SECONDS>,

‍ ‍

    1,

‍ ‍

    0

‍ ‍

)

‍ ‍

| streamstats

‍ ‍

    sum(new_activity_cluster) AS cluster_sequence

‍ ‍

    BY entity_type entity_id

‍ ‍

| stats

‍ ‍

    earliest(_time) AS first_seen

‍ ‍

    latest(_time) AS last_seen

‍ ‍

    dc(controller_id) AS distinct_controllers

‍ ‍

    dc(process_area) AS distinct_process_areas

‍ ‍

    dc(facility_id) AS distinct_facilities

‍ ‍

    dc(site_id) AS distinct_sites

‍ ‍

    dc(controller_vendor) AS distinct_controller_vendors

‍ ‍

    dc(out_of_scope_controller) AS out_of_scope_controller_count

‍ ‍

    dc(out_of_scope_process_area) AS out_of_scope_process_area_count

‍ ‍

    dc(out_of_scope_facility) AS out_of_scope_facility_count

‍ ‍

    dc(out_of_scope_site) AS out_of_scope_site_count

‍ ‍

    values(controller_id) AS affected_controllers

‍ ‍

    values(out_of_scope_controller) AS out_of_scope_controllers

‍ ‍

    values(process_area) AS affected_process_areas

‍ ‍

    values(out_of_scope_process_area) AS out_of_scope_process_areas

‍ ‍

    values(facility_id) AS affected_facilities

‍ ‍

    values(out_of_scope_facility) AS out_of_scope_facilities

‍ ‍

    values(site_id) AS affected_sites

‍ ‍

    values(out_of_scope_site) AS out_of_scope_sites

‍ ‍

    values(controller_vendor) AS controller_vendors

‍ ‍

    values(normalized_action) AS change_actions

‍ ‍

    values(changed_object_type) AS changed_object_types

‍ ‍

    values(project_id) AS projects

‍ ‍

    values(source_asset) AS source_assets

‍ ‍

    values(user) AS users

‍ ‍

    values(remote_session_id) AS sessions

‍ ‍

    values(related_rule1_alert_id) AS rule1_alerts

‍ ‍

    values(related_rule2_alert_id) AS rule2_alerts

‍ ‍

    BY entity_type entity_id cluster_sequence

‍ ‍

| eval cluster_duration=last_seen-first_seen

‍ ‍

| eval expansion_detected=case(

‍ ‍

    entity_type!="change_pattern"

‍ ‍

        AND out_of_scope_controller_count>=<OUT_OF_SCOPE_CONTROLLER_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type!="change_pattern"

‍ ‍

        AND out_of_scope_process_area_count>=<OUT_OF_SCOPE_PROCESS_AREA_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type!="change_pattern"

‍ ‍

        AND out_of_scope_facility_count>=<OUT_OF_SCOPE_FACILITY_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type!="change_pattern"

‍ ‍

        AND out_of_scope_site_count>=<OUT_OF_SCOPE_SITE_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type="change_pattern"

‍ ‍

        AND distinct_facilities>=<PATTERN_FACILITY_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type="change_pattern"

‍ ‍

        AND distinct_sites>=<PATTERN_SITE_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    entity_type="change_pattern"

‍ ‍

        AND distinct_controllers>=<PATTERN_CONTROLLER_THRESHOLD>

‍ ‍

        AND distinct_controller_vendors>=<PATTERN_VENDOR_THRESHOLD>,

‍ ‍

        1,

‍ ‍

    true(),

‍ ‍

        0

‍ ‍

)

‍ ‍

| where expansion_detected=1

‍ ‍

| eval affected_controller_set=mvjoin(

‍ ‍

    mvsort(affected_controllers),

‍ ‍

    ","

‍ ‍

)

‍ ‍

| eval activity_cluster_id=md5(

‍ ‍

    entity_type."|".entity_id."|".tostring(cluster_sequence)."|".

‍ ‍

    tostring(first_seen)."|".affected_controller_set

‍ ‍

)

‍ ‍

| eval dedup_key=entity_type."|".entity_id."|".activity_cluster_id

‍ ‍

| table first_seen last_seen cluster_duration entity_type entity_id

‍ ‍

        cluster_sequence distinct_controllers distinct_process_areas

‍ ‍

        distinct_facilities distinct_sites out_of_scope_controller_count

‍ ‍

        out_of_scope_process_area_count out_of_scope_facility_count

‍ ‍

        out_of_scope_site_count affected_controllers

‍ ‍

        out_of_scope_controllers affected_process_areas

‍ ‍

        out_of_scope_process_areas affected_facilities

‍ ‍

        out_of_scope_facilities affected_sites out_of_scope_sites

‍ ‍

        controller_vendors change_actions changed_object_types projects

‍ ‍

        source_assets users sessions rule1_alerts rule2_alerts

‍ ‍

        activity_cluster_id dedup_key

‍ ‍

Elastic

‍ ‍

Detection Viability Assessment

‍ ‍

Elastic provides full correlation viability when industrial NDR, PLC and engineering audit, HMI/SCADA, historian, remote-access, endpoint, asset, and change-management telemetry is normalized into Elastic Common Schema fields or a controlled local OT extension.

‍ ‍

The three rules use:

‍ ‍

·        EQL for ordered access-to-change and change-to-impact sequences.

‍ ‍

·        ES|QL for independently suspicious project-upload activity, critical manipulation without observed impact, and multi-entity expansion.

‍ ‍

·        Preprocessing or ingest enrichment for controller relationships, authorization status, evidence independence, validated process thresholds, activity-chain identifiers, per-target scope decisions, and sessionized expansion clusters.

‍ ‍

·        Elastic Security alert suppression, risk scoring, alert enrichment, and case linking for operational deployment.

‍ ‍

Mandatory local OT fields must be mapped consistently across the participating indices. Genuinely conditional EQL fields must use the ? optional-field operator or be removed from the rule.

‍ ‍

Environment-specific index patterns, enrich policies, thresholds, field mappings, activity windows, criticality records, and suppression values must be validated before deployment.

‍ ‍

Rule

‍ ‍

Unauthorized Engineering Access Followed by PLC Manipulation

‍ ‍

Rule Format

‍ ‍

Elastic EQL sequences with ES|QL project-upload companion analytics

‍ ‍

Detection Purpose

‍ ‍

Detect unauthorized or abnormal access to an OT engineering environment followed by PLC project transfer, logic modification, parameter modification, credential change, network change, firmware activity, reset, restore, or operating-mode manipulation.

‍ ‍

Detection Logic

‍ ‍

Correlate suspicious remote or engineering access with subsequent PLC engineering activity involving the same controller and attributable activity chain.

‍ ‍

Qualifying access activity includes:

‍ ‍

·        VPN, privileged-access, remote-desktop, cellular, jump-host, or vendor-support access from an unauthorized source.

‍ ‍

·        Access by an unauthorized, shared, default, dormant, vendor, integrator, or out-of-scope account.

‍ ‍

·        A first-seen source-to-engineering-system or source-to-controller relationship.

‍ ‍

·        IT-to-OT, internet-to-OT, cellular-to-OT, or cross-zone access outside the approved architecture.

‍ ‍

·        Failed authentication followed by successful engineering access.

‍ ‍

·        Access outside an approved work order, maintenance window, commissioning event, recovery action, or emergency change.

‍ ‍

Qualifying manipulation activity includes:

‍ ‍

·        Project download or full program download.

‍ ‍

·        Online edit or program append.

‍ ‍

·        Logic, task, routine, program, function-block, tag, or parameter change.

‍ ‍

·        Controller credential, password, privilege, IP address, subnet, gateway, routing, communications, or management-setting change.

‍ ‍

·        Firmware update, firmware replacement, or firmware-update-mode activation.

‍ ‍

·        Controller reset, memory clear, project restore, or operating-mode change.

‍ ‍

Treat project upload as lower-confidence engineering-access or collection behavior.

‍ ‍

Project upload should alert through one of two branches:

‍ ‍

·        Suspicious project upload followed by controller manipulation.

‍ ‍

·        Independently suspicious project upload involving unauthorized access, an unauthorized transfer destination, or multi-controller collection.

‍ ‍

Classify activity as:

‍ ‍

·        Suspicious engineering access.

‍ ‍

·        Confirmed unauthorized manipulation.

‍ ‍

·        Critical manipulation or latent process risk.

‍ ‍

Critical classification applies when confirmed unauthorized activity affects treatment-critical or safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection conditions, dosing limits, critical process parameters, or multiple controllers.

‍ ‍

Required Telemetry

‍ ‍

·        VPN, remote-access, privileged-access, jump-host, firewall, cellular, and authentication logs.

‍ ‍

·        Industrial NDR or controller-management events.

‍ ‍

·        PLC and engineering-software audit logs where available.

‍ ‍

·        Controller, engineering-workstation, HMI, SCADA, jump-host, and remote-access asset inventory.

‍ ‍

·        Controller identifier.

‍ ‍

·        Engineering-system identifier.

‍ ‍

·        Source asset and source address.

‍ ‍

·        User and session identifiers.

‍ ‍

·        Normalized actor key.

‍ ‍

·        Normalized activity-chain identifier.

‍ ‍

·        Normalized engineering action.

‍ ‍

·        Project or change identifier where available.

‍ ‍

·        Approved engineering-source status.

‍ ‍

·        Historical source-relationship status.

‍ ‍

·        User-to-controller and engineering-system-to-controller scope.

‍ ‍

·        Maintenance-window and work-order status.

‍ ‍

·        Controller and changed-object criticality.

‍ ‍

·        Project-transfer destination status.

‍ ‍

·        Multi-controller upload count or upload-cluster status.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Normalize and enrich access and engineering events before enabling the rule.

‍ ‍

The following fields are mandatory for the primary EQL sequence:

‍ ‍

·        ot.controller.id

‍ ‍

·        ot.actor.key

‍ ‍

·        ot.activity_chain.id

‍ ‍

·        ot.access.suspicious

‍ ‍

·        ot.access.authorized

‍ ‍

·        ot.engineering.authorized

‍ ‍

·        ot.engineering.action

‍ ‍

Create ot.actor.key using the strongest attributable relationship:

‍ ‍

·        Remote-access or engineering session.

‍ ‍

·        User and source asset.

‍ ‍

·        User and source address.

‍ ‍

Create ot.activity_chain.id from the controller, actor, engineering path, remote-access session, project, and bounded activity period.

‍ ‍

Do not assign one activity-chain identifier to unrelated sessions sharing only a controller, user, facility, or broad time window.

‍ ‍

Map access events to controllers reachable through the destination engineering workstation, jump host, HMI, vendor-support system, or other management path before EQL execution.

‍ ‍

Use a separate ES|QL preprocessing or transform job to calculate:

‍ ‍

·        Multi-controller upload counts.

‍ ‍

·        Upload-cluster identifiers.

‍ ‍

·        Unauthorized transfer destinations.

‍ ‍

·        Related project and controller scope.

‍ ‍

·        Upload criticality.

‍ ‍

Use Rule 1 to open the initial controller-level unauthorized-manipulation alert.

‍ ‍

Rule 2 may enrich, supersede, or reference Rule 1 when impact or critical latent risk is detected.

‍ ‍

Rule 3 creates a separate expansion alert when multiple controllers, process areas, facilities, or sites are affected.

‍ ‍

Suppress duplicate Rule 1 alerts by:

‍ ‍

·        Controller identifier.

‍ ‍

·        Activity-chain identifier.

‍ ‍

·        Project or change identifier where available.

‍ ‍

·        Alert classification.

‍ ‍

Re-alert when severity increases, a different changed object appears, a new activity chain is involved, a new controller is affected, or activity resumes after the configured quiet period.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when access and engineering telemetry shares stable controller, actor, activity-chain, project, and authorization fields.

‍ ‍

Reliability decreases when shared accounts, NAT, common jump hosts, missing controller relationships, or generic industrial writes weaken attribution.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.2

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong where access and controller-change telemetry is normalized and centralized in Elastic.

‍ ‍

Full telemetry adds authoritative controller audit, project integrity, HMI/SCADA, historian, operator, and process evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.9

‍ ‍

Full-Telemetry TCR

‍ ‍

9.6

‍ ‍

Limitations

‍ ‍

·        Local, serial, removable-media, or unmonitored engineering activity may not be visible.

‍ ‍

·        Proprietary or encrypted protocols may conceal the exact controller action.

‍ ‍

·        Shared accounts, NAT, and common jump hosts may weaken actor attribution.

‍ ‍

·        Project upload may represent approved backup, troubleshooting, or state comparison.

‍ ‍

·        Relationship and authorization enrichment may be incomplete or stale.

‍ ‍

·        Access evidence alone does not prove PLC manipulation.

‍ ‍

·        The primary sequence depends on a correctly generated activity-chain identifier.

‍ ‍

·        Missing time synchronization can prevent correct sequence ordering.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following EQL sequence after mapping the mandatory local OT fields and generating the normalized actor and activity-chain identifiers.

‍ ‍

sequence by ot.controller.id, ot.actor.key, ot.activity_chain.id

‍ ‍

  with maxspan=<ACCESS_TO_CHANGE_WINDOW>

‍ ‍

  [authentication where

‍ ‍

      event.outcome == "success" and

‍ ‍

      ot.access.suspicious == true and

‍ ‍

      ot.access.authorized != true

‍ ‍

  ]

‍ ‍

  [any where

‍ ‍

      event.category == "configuration" and

‍ ‍

      ot.engineering.authorized != true and

‍ ‍

      ot.engineering.action in (

‍ ‍

        "project_download",

‍ ‍

        "download_all",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "routine_change",

‍ ‍

        "function_block_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_update",

‍ ‍

        "firmware_replacement",

‍ ‍

        "firmware_update_mode",

‍ ‍

        "controller_reset",

‍ ‍

        "memory_clear",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change"

‍ ‍

      )

‍ ‍

  ]

‍ ‍

Deploy the following EQL sequence for suspicious project upload followed by manipulation.

‍ ‍

sequence by ot.controller.id, ot.actor.key, ot.activity_chain.id

‍ ‍

  with maxspan=<UPLOAD_TO_CHANGE_WINDOW>

‍ ‍

  [any where

‍ ‍

      event.category == "configuration" and

‍ ‍

      ot.engineering.action == "project_upload" and

‍ ‍

      (

‍ ‍

        ot.engineering.authorized != true or

‍ ‍

        ot.project.destination_authorized != true or

‍ ‍

        ot.project.multi_controller_collection == true

‍ ‍

      )

‍ ‍

  ]

‍ ‍

  [any where

‍ ‍

      event.category == "configuration" and

‍ ‍

      ot.engineering.authorized != true and

‍ ‍

      ot.engineering.action in (

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "routine_change",

‍ ‍

        "function_block_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change"

‍ ‍

      )

‍ ‍

  ]

‍ ‍

Deploy the following ES|QL companion analytic for independently suspicious project uploads that do not require a subsequent manipulation event.

‍ ‍

FROM <OT_ENGINEERING_INDEX_PATTERN>

‍ ‍

| WHERE event.category == "configuration"

‍ ‍

    AND ot.engineering.action == "project_upload"

‍ ‍

    AND (

‍ ‍

        ot.engineering.authorized != true

‍ ‍

        OR ot.project.destination_authorized != true

‍ ‍

        OR ot.project.multi_controller_collection == true

‍ ‍

    )

‍ ‍

| EVAL alert_classification = "Suspicious engineering access"

‍ ‍

| KEEP @timestamp,

‍ ‍

       ot.controller.id,

‍ ‍

       ot.actor.key,

‍ ‍

       ot.activity_chain.id,

‍ ‍

       source.ip,

‍ ‍

       user.name,

‍ ‍

       ot.project.id,

‍ ‍

       ot.project.destination,

‍ ‍

       ot.project.destination_authorized,

‍ ‍

       ot.project.multi_controller_collection,

‍ ‍

       ot.project.uploaded_controller_count,

‍ ‍

       alert_classification

‍ ‍

Rule

‍ ‍

Controller or HMI Manipulation Followed by Loss of Control or Process Deviation

‍ ‍

Rule Format

‍ ‍

Elastic EQL sequences over pre-enriched OT events with ES|QL critical-manipulation companion analytic

‍ ‍

Detection Purpose

‍ ‍

Detect unauthorized controller, HMI, or SCADA manipulation followed by communications loss, operator lockout, controller instability, threshold-confirmed process deviation, manual-operation transition, or operational impact, while independently identifying confirmed critical manipulation with unresolved latent consequences.

‍ ‍

Detection Logic

‍ ‍

Implement three controlled branches within one durable rule:

‍ ‍

·        Preferred activity-chain correlation.

‍ ‍

·        Short-window controller-only fallback.

‍ ‍

·        Authoritatively confirmed critical manipulation without observed impact.

‍ ‍

The preferred branch correlates unauthorized manipulation with impact using:

‍ ‍

·        The same controller.

‍ ‍

·        The same normalized activity-chain identifier.

‍ ‍

·        A bounded change-to-impact interval.

‍ ‍

The controller-only fallback applies only when no reliable activity-chain identifier can be generated.

‍ ‍

The fallback requires:

‍ ‍

·        The same controller.

‍ ‍

·        A shorter correlation window.

‍ ‍

·        At least two independent evidence paths or one independently validated critical impact.

‍ ‍

·        No active approved maintenance state.

‍ ‍

·        A validated process threshold, duration, repetition, or operational-impact condition.

‍ ‍

Qualifying manipulation includes:

‍ ‍

·        PLC program, logic, task, routine, parameter, credential, network, firmware, reset, restore, or mode changes.

‍ ‍

·        HMI or SCADA set-point, alarm, tag, display, account, administrative, control-mode, or manual-command changes.

‍ ‍

·        Interlock, permissive, protection, treatment-limit, or critical process-parameter changes.

‍ ‍

Qualifying impact includes:

‍ ‍

·        Controller communications loss.

‍ ‍

·        Controller fault, stop, restart, reset, or project mismatch.

‍ ‍

·        Failed legitimate operator or engineering access.

‍ ‍

·        Loss of view or loss of control.

‍ ‍

·        Stale or inconsistent process values.

‍ ‍

·        Threshold-confirmed process deviation.

‍ ‍

·        Manual-operation transition.

‍ ‍

·        Process shutdown.

‍ ‍

·        Boil-water notice.

‍ ‍

·        Wastewater-release concern.

‍ ‍

·        Service interruption.

‍ ‍

The critical-manipulation branch applies without observed impact when confirmed unauthorized changes involve:

‍ ‍

·        Treatment-critical or safety-relevant logic.

‍ ‍

·        Hidden, dormant, delayed, or conditionally activated logic.

‍ ‍

·        Interlocks, permissives, protection logic, or alarm enforcement.

‍ ‍

·        Chemical-dosing or treatment limits.

‍ ‍

·        Critical pressure, flow, level, sequencing, or process parameters.

‍ ‍

·        Multiple controllers.

‍ ‍

·        A malicious project download with unresolved latent consequences.

‍ ‍

Required Telemetry

‍ ‍

·        Industrial NDR, controller audit, and engineering audit events.

‍ ‍

·        HMI and SCADA command, configuration, alarm, account, and tag-change logs.

‍ ‍

·        Controller state and communications events.

‍ ‍

·        Historian and process-variable data.

‍ ‍

·        Independent sensor and field-device data where available.

‍ ‍

·        Operator-lockout and manual-operation records.

‍ ‍

·        Laboratory and water-quality data where available.

‍ ‍

·        Service-impact and incident records.

‍ ‍

·        Controller and dependent-asset relationship mappings.

‍ ‍

·        Approved process thresholds.

‍ ‍

·        Operating-phase and maintenance context.

‍ ‍

·        Normalized controller identifier.

‍ ‍

·        Normalized activity-chain identifier where available.

‍ ‍

·        Relationship type.

‍ ‍

·        Independent-evidence key and count.

‍ ‍

·        Validated-impact status.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Mandatory preprocessing must occur before EQL execution.

‍ ‍

The preprocessing layer must:

‍ ‍

·        Resolve each impact event to a controller.

‍ ‍

·        Assign the relationship type.

‍ ‍

·        Validate approved thresholds.

‍ ‍

·        Validate minimum duration.

‍ ‍

·        Validate repetition count.

‍ ‍

·        Validate rate-of-change conditions.

‍ ‍

·        Validate operating phase.

‍ ‍

·        Validate maintenance state.

‍ ‍

·        Create the independent-evidence key.

‍ ‍

·        Calculate the independent-evidence count.

‍ ‍

·        Mark independently critical impact.

‍ ‍

·        Generate an activity-chain identifier where reliable linkage exists.

‍ ‍

Resolve the controller relationship in this order:

‍ ‍

·        Direct controller identifier.

‍ ‍

·        Explicit dependent-asset relationship.

‍ ‍

·        Process-area fallback.

‍ ‍

Create the independent-evidence key from:

‍ ‍

·        Source system.

‍ ‍

·        Data path.

‍ ‍

·        Sensor, affected asset, laboratory source, or operator system.

‍ ‍

Do not count multiple impact categories from the same controller, HMI, historian path, or sensor as independent corroboration.

‍ ‍

The following fields are mandatory for the preferred EQL sequence:

‍ ‍

·        ot.controller.id

‍ ‍

·        ot.activity_chain.id

‍ ‍

·        ot.engineering.authorized

‍ ‍

·        ot.engineering.action

‍ ‍

·        ot.impact.valid

‍ ‍

·        ot.impact.category

‍ ‍

·        ot.relationship.type

‍ ‍

·        ot.impact.independent_evidence_count

‍ ‍

·        ot.impact.independently_critical

‍ ‍

The controller-only fallback must use a shorter maximum span and stronger evidence requirements.

‍ ‍

Conditional investigative fields such as project, session, previous value, new value, and sensor identifier may be referenced with the optional-field operator or retained only as alert-enrichment fields.

‍ ‍

Use a separate ES|QL rule for critical manipulation without observed impact.

‍ ‍

All components must share the same CyberDax rule name and normalized classification.

‍ ‍

Suppress duplicate alerts by:

‍ ‍

·        Controller identifier.

‍ ‍

·        Activity-chain identifier where available.

‍ ‍

·        Change identifier where available.

‍ ‍

·        Impact or critical-latent classification.

‍ ‍

Rule 2 should reference the related Rule 1 alert where the alert workflow supports correlation or case linking.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when authoritative change evidence maps to the same controller and activity chain or satisfies the controlled controller-only fallback.

‍ ‍

Reliability decreases when process evidence is not independent, controller relationships are incomplete, activity-chain assignment is unreliable, or impact events are transient.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.3

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong where controller, HMI/SCADA, communications, and process telemetry is normalized in Elastic.

‍ ‍

Full coverage requires independent process evidence, approved thresholds, reliable dependency mappings, operator records, and laboratory or field validation where appropriate.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

9.0

‍ ‍

Full-Telemetry TCR

‍ ‍

9.7

‍ ‍

Limitations

‍ ‍

·        Process effects may be delayed or conditional.

‍ ‍

·        HMI, historian, and controller telemetry may derive from the same manipulated source.

‍ ‍

·        Equipment failure, sensor failure, maintenance, environmental conditions, or operator error may resemble cyber-induced deviation.

‍ ‍

·        Process-area fallback is less reliable than direct controller correlation.

‍ ‍

·        Controller-only fallback may still associate an unrelated change and consequence if its window is too broad.

‍ ‍

·        Process data may be delayed, down-sampled, filtered, or incomplete.

‍ ‍

·        Local or serial controller changes may lack a visible initiating event.

‍ ‍

·        EQL depends on mandatory preprocessing and consistently mapped join fields.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following preferred EQL sequence when both stages contain the same normalized activity-chain identifier.

‍ ‍

sequence by ot.controller.id, ot.activity_chain.id

‍ ‍

  with maxspan=<CHANGE_TO_IMPACT_WINDOW>

‍ ‍

  [any where

‍ ‍

      event.category == "configuration" and

‍ ‍

      ot.engineering.authorized != true and

‍ ‍

      ot.engineering.action in (

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "routine_change",

‍ ‍

        "function_block_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change",

‍ ‍

        "hmi_setpoint_change",

‍ ‍

        "alarm_configuration_change",

‍ ‍

        "tag_change",

‍ ‍

        "manual_command",

‍ ‍

        "administrative_change"

‍ ‍

      )

‍ ‍

  ]

‍ ‍

  [any where

‍ ‍

      ot.impact.valid == true and

‍ ‍

      ot.impact.category in (

‍ ‍

        "communications_loss",

‍ ‍

        "controller_fault",

‍ ‍

        "controller_stop",

‍ ‍

        "controller_restart",

‍ ‍

        "project_mismatch",

‍ ‍

        "operator_lockout",

‍ ‍

        "loss_of_view",

‍ ‍

        "loss_of_control",

‍ ‍

        "stale_process_value",

‍ ‍

        "inconsistent_process_value",

‍ ‍

        "process_threshold_breach",

‍ ‍

        "manual_operations",

‍ ‍

        "service_interruption"

‍ ‍

      ) and

‍ ‍

      (

‍ ‍

        (

‍ ‍

          ot.relationship.type != "process_area_fallback" and

‍ ‍

          ot.impact.independent_evidence_count >= 1

‍ ‍

        )

‍ ‍

        or

‍ ‍

        (

‍ ‍

          ot.relationship.type == "process_area_fallback" and

‍ ‍

          ot.impact.independent_evidence_count >= 2

‍ ‍

        )

‍ ‍

        or

‍ ‍

        (

‍ ‍

          ot.impact.independently_critical == true

‍ ‍

        )

‍ ‍

      )

‍ ‍

  ]

‍ ‍

Deploy the following tightly bounded controller-only fallback when no reliable activity-chain identifier is available.

‍ ‍

sequence by ot.controller.id

‍ ‍

  with maxspan=<SHORT_CONTROLLER_ONLY_FALLBACK_WINDOW>

‍ ‍

  [any where

‍ ‍

      event.category == "configuration" and

‍ ‍

      ot.engineering.authorized != true and

‍ ‍

      ot.engineering.action in (

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change",

‍ ‍

        "hmi_setpoint_change",

‍ ‍

        "alarm_configuration_change",

‍ ‍

        "tag_change",

‍ ‍

        "manual_command",

‍ ‍

        "administrative_change"

‍ ‍

      )

‍ ‍

  ]

‍ ‍

  [any where

‍ ‍

      ot.impact.valid == true and

‍ ‍

      ot.maintenance.active != true and

‍ ‍

      (

‍ ‍

        ot.impact.independent_evidence_count >= 2

‍ ‍

        or ot.impact.independently_critical == true

‍ ‍

      )

‍ ‍

  ]

‍ ‍

Deploy the following ES|QL companion analytic for confirmed critical manipulation without observed impact.

‍ ‍

FROM <OT_CHANGE_INDEX_PATTERN>

‍ ‍

| WHERE event.category == "configuration"

‍ ‍

    AND ot.engineering.authorized != true

‍ ‍

    AND ot.engineering.action IN (

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change",

‍ ‍

        "hmi_setpoint_change",

‍ ‍

        "alarm_configuration_change",

‍ ‍

        "tag_change",

‍ ‍

        "manual_command",

‍ ‍

        "administrative_change"

‍ ‍

    )

‍ ‍

    AND (

‍ ‍

        ot.change.treatment_critical == true

‍ ‍

        OR ot.change.safety_relevant == true

‍ ‍

        OR ot.change.hidden_or_conditional == true

‍ ‍

        OR ot.change.interlock_or_permissive == true

‍ ‍

        OR ot.change.critical_process_parameter == true

‍ ‍

    )

‍ ‍

| EVAL alert_classification = "Critical manipulation or latent process risk"

‍ ‍

| KEEP @timestamp,

‍ ‍

       ot.controller.id,

‍ ‍

       ot.activity_chain.id,

‍ ‍

       source.ip,

‍ ‍

       user.name,

‍ ‍

       session.id,

‍ ‍

       ot.project.id,

‍ ‍

       ot.engineering.action,

‍ ‍

       ot.change.object,

‍ ‍

       ot.change.previous_value,

‍ ‍

       ot.change.new_value,

‍ ‍

       ot.process.area,

‍ ‍

       alert_classification

‍ ‍

Rule

‍ ‍

Multi-Controller or Cross-Facility Manipulation Expansion

‍ ‍

Rule Format

‍ ‍

Elastic ES|QL aggregation over pre-normalized entity-event documents

‍ ‍

Detection Purpose

‍ ‍

Detect one source, identity, engineering workstation, remote-access session, project, artifact, or repeated change pattern performing unauthorized engineering or administrative activity across multiple controllers, process areas, facilities, or sites.

‍ ‍

Detection Logic

‍ ‍

Evaluate expansion separately for:

‍ ‍

·        Engineering source or workstation.

‍ ‍

·        User or identity.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact.

‍ ‍

·        Repeated change pattern.

‍ ‍

Do not combine unrelated entity classes through a single fallback field.

‍ ‍

Evaluate approved scope according to entity type:

‍ ‍

·        User to controller.

‍ ‍

·        Engineering workstation to controller.

‍ ‍

·        Remote session to site.

‍ ‍

·        Integrator to facility.

‍ ‍

·        Project to controller.

‍ ‍

·        Change ticket to asset.

‍ ‍

Determine scope authorization for each entity-target event before aggregation.

‍ ‍

Preserve the existence and counts of out-of-scope controllers, process areas, facilities, and sites even when the same entity also performs approved activity.

‍ ‍

Promote activity when an entity performs unauthorized or unexplained engineering activity against:

‍ ‍

·        Multiple controllers outside approved scope.

‍ ‍

·        Multiple process areas not covered by the same approved change.

‍ ‍

·        Multiple facilities or sites.

‍ ‍

·        Controller families or vendors not normally managed by the entity.

‍ ‍

·        Assets consistent with discovery followed by manipulation.

‍ ‍

·        Multiple controllers that later experience similar lockout, fault, communications, process, or manual-operation effects.

‍ ‍

Do not assign approved operational scope to a generic action pattern.

‍ ‍

Evaluate repeated patterns using rarity, target distribution, timing, similarity, and associated identities or source assets.

‍ ‍

Required Telemetry

‍ ‍

·        A pre-normalized OT entity-event index or data stream.

‍ ‍

·        Entity type and entity identifier.

‍ ‍

·        Controller identifier.

‍ ‍

·        Controller vendor and family.

‍ ‍

·        Process area.

‍ ‍

·        Facility and site.

‍ ‍

·        Normalized engineering action.

‍ ‍

·        Changed-object type.

‍ ‍

·        Per-target scope status.

‍ ‍

·        Activity-cluster identifier.

‍ ‍

·        Work-order and maintenance context.

‍ ‍

·        Target rarity or historical relationship status.

‍ ‍

·        Controller criticality.

‍ ‍

·        Related Rule 1 and Rule 2 alert identifiers where available.

‍ ‍

Engineering Implementation Instructions

‍ ‍

Create separate entity-event documents for:

‍ ‍

·        Source asset.

‍ ‍

·        User.

‍ ‍

·        Remote-access session.

‍ ‍

·        Project or artifact.

‍ ‍

·        Repeated change pattern.

‍ ‍

Each document must contain:

‍ ‍

·        ot.entity.type

‍ ‍

·        ot.entity.id

‍ ‍

·        ot.controller.id

‍ ‍

·        ot.process.area

‍ ‍

·        ot.facility.id

‍ ‍

·        ot.site.id

‍ ‍

·        ot.controller.vendor

‍ ‍

·        ot.engineering.action

‍ ‍

·        ot.change.object_type

‍ ‍

·        ot.scope.approved

‍ ‍

·        ot.activity_cluster.id

‍ ‍

·        @timestamp

‍ ‍

Calculate per-target scope authorization before documents enter the entity-event index.

‍ ‍

Generate ot.activity_cluster.id through a transform, ingest process, stream processor, or other preprocessing workflow that starts a new cluster when the interval between consecutive events for the same entity exceeds the approved cluster-pause threshold.

‍ ‍

Do not use a fixed time bucket as the sole cluster identity.

‍ ‍

The ES|QL rule is not intended to operate directly over heterogeneous raw OT telemetry.

‍ ‍

Use COUNT_DISTINCT only after validating acceptable cardinality precision for the deployment.

‍ ‍

Do not require the preview VALUES aggregation function.

‍ ‍

Affected-target collections should be supplied through:

‍ ‍

·        Transform-generated summary fields.

‍ ‍

·        Alert enrichment.

‍ ‍

·        A related investigation query.

‍ ‍

·        A target-summary field created during entity-event preprocessing.

‍ ‍

Avoid count-only detection. Include:

‍ ‍

·        Per-target scope violation.

‍ ‍

·        Cross-zone or cross-facility activity.

‍ ‍

·        Controller criticality.

‍ ‍

·        Change similarity.

‍ ‍

·        Work-order alignment.

‍ ‍

·        Subsequent impact.

‍ ‍

·        Target rarity.

‍ ‍

Rule 3 remains a separate expansion alert and should reference related Rule 1 and Rule 2 alerts where available.

‍ ‍

Suppress duplicate alerts by:

‍ ‍

·        Entity type.

‍ ‍

·        Entity identifier.

‍ ‍

·        Activity-cluster identifier.

‍ ‍

Re-alert when a new facility or site is affected, the controller set materially expands, severity increases, a new impact appears, or a separate activity cluster is identified.

‍ ‍

DRI Assessment

‍ ‍

Reliability is high when entity identities, controller mappings, facility mappings, per-target scope decisions, and activity clusters are prepared accurately.

‍ ‍

Reliability decreases in centralized engineering environments with broad legitimate access, shared accounts, NAT, weak change records, or inaccurate preprocessing.

‍ ‍

The score is a design-stage estimate and requires local validation.

‍ ‍

DRI

‍ ‍

9.0

‍ ‍

TCR Assessment

‍ ‍

Operational coverage is strong for centralized network-visible expansion.

‍ ‍

Full telemetry improves attribution through engineering audit, identity, project, remote-access, change-management, controller-state, and process-impact evidence.

‍ ‍

The scores are design-stage estimates and require local validation.

‍ ‍

Operational TCR

‍ ‍

8.9

‍ ‍

Full-Telemetry TCR

‍ ‍

9.5

‍ ‍

Limitations

‍ ‍

·        Central engineering teams and integrators may legitimately manage many controllers.

‍ ‍

·        Shared accounts, NAT, and common jump hosts may obscure the responsible entity.

‍ ‍

·        Local or serial programming may not be centrally visible.

‍ ‍

·        Vendor protocols may normalize similar actions differently.

‍ ‍

·        Low-and-slow activity may span separate activity clusters.

‍ ‍

·        Incomplete scope, facility, project, or controller mappings may weaken detection.

‍ ‍

·        COUNT_DISTINCT is approximate and requires local precision validation.

‍ ‍

·        The rule depends on a correctly maintained pre-normalized entity-event index.

‍ ‍

Detection Query Pattern

‍ ‍

Deploy the following ES|QL rule only over pre-normalized entity-event documents containing per-target scope decisions and sessionized activity-cluster identifiers.

‍ ‍

FROM <OT_ENGINEERING_ENTITY_INDEX_PATTERN>

‍ ‍

| WHERE event.category == "configuration"

‍ ‍

    AND ot.engineering.authorized != true

‍ ‍

    AND ot.engineering.action IN (

‍ ‍

        "project_upload",

‍ ‍

        "project_download",

‍ ‍

        "online_edit",

‍ ‍

        "program_append",

‍ ‍

        "logic_change",

‍ ‍

        "task_change",

‍ ‍

        "routine_change",

‍ ‍

        "function_block_change",

‍ ‍

        "parameter_change",

‍ ‍

        "credential_change",

‍ ‍

        "network_configuration_change",

‍ ‍

        "firmware_change",

‍ ‍

        "controller_reset",

‍ ‍

        "project_restore",

‍ ‍

        "operating_mode_change",

‍ ‍

        "hmi_administrative_change",

‍ ‍

        "hmi_setpoint_change",

‍ ‍

        "alarm_configuration_change"

‍ ‍

    )

‍ ‍

| EVAL out_of_scope_controller =

‍ ‍

    CASE(

‍ ‍

        ot.scope.approved != true,

‍ ‍

        ot.controller.id,

‍ ‍

        null

‍ ‍

    )

‍ ‍

| EVAL out_of_scope_process_area =

‍ ‍

    CASE(

‍ ‍

        ot.scope.approved != true,

‍ ‍

        ot.process.area,

‍ ‍

        null

‍ ‍

    )

‍ ‍

| EVAL out_of_scope_facility =

‍ ‍

    CASE(

‍ ‍

        ot.scope.approved != true,

‍ ‍

        ot.facility.id,

‍ ‍

        null

‍ ‍

    )

‍ ‍

| EVAL out_of_scope_site =

‍ ‍

    CASE(

‍ ‍

        ot.scope.approved != true,

‍ ‍

        ot.site.id,

‍ ‍

        null

‍ ‍

    )

‍ ‍

| STATS

‍ ‍

    first_seen = MIN(@timestamp),

‍ ‍

    last_seen = MAX(@timestamp),

‍ ‍

    distinct_controllers = COUNT_DISTINCT(ot.controller.id),

‍ ‍

    distinct_process_areas = COUNT_DISTINCT(ot.process.area),

‍ ‍

    distinct_facilities = COUNT_DISTINCT(ot.facility.id),

‍ ‍

    distinct_sites = COUNT_DISTINCT(ot.site.id),

‍ ‍

    distinct_controller_vendors = COUNT_DISTINCT(ot.controller.vendor),

‍ ‍

    out_of_scope_controller_count = COUNT_DISTINCT(out_of_scope_controller),

‍ ‍

    out_of_scope_process_area_count = COUNT_DISTINCT(out_of_scope_process_area),

‍ ‍

    out_of_scope_facility_count = COUNT_DISTINCT(out_of_scope_facility),

‍ ‍

    out_of_scope_site_count = COUNT_DISTINCT(out_of_scope_site),

‍ ‍

    critical_target_count = COUNT_DISTINCT(

‍ ‍

        CASE(

‍ ‍

            ot.controller.critical == true,

‍ ‍

            ot.controller.id,

‍ ‍

            null

‍ ‍

        )

‍ ‍

    ),

‍ ‍

    impacted_target_count = COUNT_DISTINCT(

‍ ‍

        CASE(

‍ ‍

            ot.related.impact_present == true,

‍ ‍

            ot.controller.id,

‍ ‍

            null

‍ ‍

        )

‍ ‍

    )

‍ ‍

  BY ot.entity.type, ot.entity.id, ot.activity_cluster.id

‍ ‍

| WHERE (

‍ ‍

        ot.entity.type != "change_pattern"

‍ ‍

        AND (

‍ ‍

            out_of_scope_controller_count >= <OUT_OF_SCOPE_CONTROLLER_THRESHOLD>

‍ ‍

            OR out_of_scope_process_area_count >= <OUT_OF_SCOPE_PROCESS_AREA_THRESHOLD>

‍ ‍

            OR out_of_scope_facility_count >= <OUT_OF_SCOPE_FACILITY_THRESHOLD>

‍ ‍

            OR out_of_scope_site_count >= <OUT_OF_SCOPE_SITE_THRESHOLD>

‍ ‍

        )

‍ ‍

    )

‍ ‍

    OR (

‍ ‍

        ot.entity.type == "change_pattern"

‍ ‍

        AND (

‍ ‍

            distinct_facilities >= <PATTERN_FACILITY_THRESHOLD>

‍ ‍

            OR distinct_sites >= <PATTERN_SITE_THRESHOLD>

‍ ‍

            OR (

‍ ‍

                distinct_controllers >= <PATTERN_CONTROLLER_THRESHOLD>

‍ ‍

                AND distinct_controller_vendors >= <PATTERN_VENDOR_THRESHOLD>

‍ ‍

            )

‍ ‍

        )

‍ ‍

    )

‍ ‍

| EVAL alert_classification =

‍ ‍

    "Multi-controller or cross-facility manipulation expansion"

‍ ‍

| KEEP first_seen,

‍ ‍

       last_seen,

‍ ‍

       ot.entity.type,

‍ ‍

       ot.entity.id,

‍ ‍

       ot.activity_cluster.id,

‍ ‍

       distinct_controllers,

‍ ‍

       distinct_process_areas,

‍ ‍

       distinct_facilities,

‍ ‍

       distinct_sites,

‍ ‍

       distinct_controller_vendors,

‍ ‍

       out_of_scope_controller_count,

‍ ‍

       out_of_scope_process_area_count,

‍ ‍

       out_of_scope_facility_count,

‍ ‍

       out_of_scope_site_count,

‍ ‍

       critical_target_count,

‍ ‍

       impacted_target_count,

‍ ‍

       alert_classification

‍ ‍QRadar

Detection Viability Assessment

QRadar provides full correlation viability when industrial NDR, controller and engineering audit, HMI/SCADA, historian, remote-access, authentication, asset, and change-management telemetry is normalized into reliable event properties.

The three rules use native QRadar Custom Rules Engine event rules, reusable building blocks, reference data, ordered event tests, anomaly rules over saved searches, and offense responses.

AQL supports field validation, tuning, investigation, and retrospective analysis. It does not replace the real-time CRE or anomaly-rule implementation.

Environment-specific log sources, QIDs, custom event properties, building blocks, saved searches, reference collections, thresholds, network hierarchy, domains, offense indexes, and response actions must be validated before deployment.

Custom properties used in rule tests or offense indexing must be enabled, parsed in advance, and optimized where appropriate.

Controller ID must be non-null before any rule attempts to create or contribute to an offense indexed by Controller ID. Events without a resolved Controller ID must generate an investigation-only response or enter a separate unresolved-controller workflow.

Rule

Unauthorized Engineering Access Followed by PLC Manipulation

Rule Format

QRadar CRE event rules with building blocks, reference data, and ordered event correlation

Detection Purpose

Detect unauthorized or abnormal access to an OT engineering environment followed by PLC project transfer, logic modification, parameter modification, credential change, network change, firmware activity, reset, restore, or operating-mode manipulation.

Detection Logic

Correlate suspicious access with subsequent PLC engineering activity involving the same controller and attributable actor, source, or session.

Qualifying access activity includes:

·        VPN, privileged-access, remote-desktop, cellular, jump-host, firewall, or vendor-support access from an unauthorized source.

·        Access by an unauthorized, dormant, shared, default, vendor, integrator, or out-of-scope account.

·        A first-seen source-to-engineering-system or source-to-controller relationship.

·        IT-to-OT, internet-to-OT, cellular-to-OT, or cross-zone access outside the approved architecture.

·        Failed authentication followed by successful access.

·        Access outside an approved work order, maintenance window, commissioning event, recovery action, or emergency change.

Qualifying manipulation activity includes:

·        Project download or full program download.

·        Online edit or program append.

·        Logic, task, routine, program, function-block, tag, or parameter change.

·        Controller credential, password, privilege, network, communications, or management-setting change.

·        Firmware update, firmware replacement, or firmware-update-mode activation.

·        Controller reset, memory clear, project restore, or operating-mode change.

Treat project upload as lower-confidence engineering-access or collection activity unless it:

·        Originates from an unauthorized source.

·        Occurs outside an approved change.

·        Transfers a project to an unauthorized destination.

·        Collects projects from multiple controllers.

·        Is followed by project modification or controller manipulation.

Classify activity as:

·        Suspicious engineering access.

·        Confirmed unauthorized manipulation.

·        Critical manipulation or latent process risk.

Critical classification applies when confirmed unauthorized activity affects treatment-critical or safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection conditions, chemical-dosing limits, critical process parameters, or multiple controllers.

Required Telemetry

·        VPN, privileged-access, remote-access, jump-host, firewall, and cellular logs.

·        Authentication events.

·        Industrial NDR or controller-management events.

·        PLC and engineering-software audit logs.

·        Source IP and source asset identifier.

·        Destination engineering-system identifier.

·        Controller identifier.

·        User.

·        Remote-access or engineering-session identifier.

·        Project or change identifier where available.

·        Normalized engineering action.

·        Changed object.

·        Prior and new state where available.

·        Process area.

·        Controller criticality.

·        Approved engineering-source, user, controller-scope, maintenance, work-order, and project-destination data.

Engineering Implementation Instructions

Create and maintain the following reusable building blocks:

·        BB:OT Suspicious Engineering Access

·        BB:OT Direct Controller Manipulation

·        BB:OT Suspicious Project Upload

·        BB:OT Critical or Protected Controller Change

·        BB:OT Approved Maintenance and Work Order

·        BB:OT Approved Engineering Source and User

·        BB:OT Resolved Controller Identity

·        BB:OT Same OT Session Correlation

·        BB:OT Same User and Source Asset Correlation

·        BB:OT Same User and Stable Source IP Correlation

Create custom event properties for:

·        Controller ID

·        Engineering System ID

·        Source Asset ID

·        OT Session ID

·        Project ID

·        Engineering Action

·        Changed Object

·        Process Area

·        Activity Chain ID

·        Criticality

·        Authorized Change Status

·        Project Destination Authorization

·        Multi-Controller Upload Status

·        Related Offense ID

Controller ID must be:

·        Enabled.

·        Parsed in advance for rules, reports, and searches.

·        Optimized for operational use.

·        Verified as non-null before offense creation.

·        Restricted to log sources and event types that reliably provide the property.

Populate reference data for:

·        Approved engineering sources.

·        Approved engineering users.

·        User-to-controller scope.

·        Engineering-system-to-controller scope.

·        Approved project destinations.

·        Active maintenance windows.

·        Active work orders.

·        Critical controllers and protected objects.

·        Previously observed source, user, engineering-system, and controller relationships.

Generate Activity Chain ID upstream where possible from the controller, attributable session, actor, engineering source, project, and bounded activity period.

Where Activity Chain ID is unavailable, use separate companion rules for each approved fallback relationship:

·        Same Controller ID and same OT Session ID.

·        Same Controller ID, same user, and same Source Asset ID.

·        Same Controller ID, same user, and same stable Source IP.

Do not express these alternatives as an ambiguous mixed AND and OR test stack.

Do not correlate solely on controller, facility, username, or broad time proximity.

Create the primary ordered CRE rule:

·        BB:OT Suspicious Engineering Access occurs.

·        BB:OT Direct Controller Manipulation subsequently occurs.

·        Both events contain a non-null Controller ID.

·        Both events share Controller ID.

·        Both events share Activity Chain ID.

·        The manipulation occurs within the approved access-to-change interval.

·        The manipulation is not fully aligned with approved maintenance and work-order context.

Create three separate actor-fallback companion rules if Activity Chain ID is unavailable:

·        OT Session fallback.

·        User and Source Asset fallback.

·        User and stable Source IP fallback.

Create independently suspicious project-upload detection as a separate companion rule under the same durable Rule 1 family.

Create another companion correlation rule for project upload followed by manipulation. That rule must:

·        Detect BB:OT Suspicious Project Upload.

·        Detect later BB:OT Direct Controller Manipulation.

·        Require the same non-null Controller ID.

·        Require the same Activity Chain ID or one explicitly defined fallback relationship.

·        Contribute to the existing Controller ID offense where possible.

·        Otherwise create a linked higher-priority offense containing the original offense identifier.

·        Reclassify the behavior as confirmed unauthorized manipulation.

The initial upload rule must not contain an undeployable instruction to wait for and process an unspecified future event inside its response.

Use Rule 1 to create the initial controller-level offense only when Controller ID is non-null.

Index the offense by Controller ID after confirming that the property is enabled, parsed, optimized, and populated.

For events with null Controller ID:

·        Do not attempt Controller ID offense indexing.

·        Dispatch an investigation event or notification.

·        Add the event to an unresolved-controller reference collection.

·        Include source, user, session, engineering system, project, and action.

·        Allow later enrichment to associate the event with a resolved controller offense.

Rule 2 should increase offense magnitude or create a linked higher-priority offense when impact or critical latent risk is established.

Rule 3 should create a separate expansion offense when multiple controllers, process areas, facilities, or sites are affected.

Limit repeated responses by Controller ID, Activity Chain ID, Project ID, manipulation category, and bounded time window.

Re-alert when severity increases, a new changed object appears, a new actor or session is involved, another controller is affected, or activity resumes after the quiet period.

Do not automatically block, isolate, terminate, reset, or alter an OT engineering asset without an approved operational-response procedure.

DRI Assessment

Reliability is high when Controller ID, session, source asset, user, action, scope, and authorization properties are consistently parsed.

Reliability decreases when shared accounts, NAT, generic jump hosts, missing sessions, incomplete reference data, or generic industrial-write events weaken attribution.

The score is a design-stage estimate and requires local validation.

DRI

9.1

TCR Assessment

Operational coverage is strong when remote-access and controller-change events reach the same QRadar deployment with reliable custom properties.

Full telemetry adds authoritative controller audit, project integrity, HMI/SCADA, historian, operator, and process evidence.

The scores are design-stage estimates and require local validation.

Operational TCR

8.8

Full-Telemetry TCR

9.6

Limitations

·        Local, serial, removable-media, or unmonitored engineering activity may not be visible.

·        Proprietary or encrypted protocols may conceal the exact engineering action.

·        Shared accounts, NAT, and common jump hosts may weaken attribution.

·        Project upload may represent legitimate backup or troubleshooting.

·        Custom-property parsing failures can prevent correlation.

·        Reference data can become stale or incomplete.

·        CRE sequence tests require stable shared properties.

·        Null Controller ID prevents Controller ID offense indexing.

·        Controller-only correlation is not permitted without an approved actor or session relationship.

Detection Query Pattern

Implement the primary activity-chain rule in the QRadar Rule Wizard.

APPLY

  CyberDax - Unauthorized Engineering Access Followed by PLC Manipulation

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Engineering Access

FOLLOWED BY

  an event that matches BB:OT Direct Controller Manipulation

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events have the same Activity Chain ID

WITHIN

  <ACCESS_TO_CHANGE_WINDOW>

AND NOT WHEN

  the manipulation event matches BB:OT Approved Maintenance and Work Order

RESPOND

  create or contribute to an offense indexed by Controller ID

  set severity from Controller Criticality and Changed Object Criticality

  annotate source, user, session, project, action, and Activity Chain ID

  limit responses by Controller ID and Activity Chain ID

Implement the OT Session fallback as a separate companion rule.

APPLY

  CyberDax - Unauthorized Engineering Access Followed by PLC Manipulation - OT Session Fallback

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Engineering Access

FOLLOWED BY

  an event that matches BB:OT Direct Controller Manipulation

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events match BB:OT Same OT Session Correlation

WITHIN

  <SHORT_ACTOR_FALLBACK_WINDOW>

AND NOT WHEN

  the manipulation event matches BB:OT Approved Maintenance and Work Order

RESPOND

  contribute to the Controller ID offense

  annotate the correlation method as OT Session fallback

Implement the user and Source Asset fallback as a separate companion rule.

APPLY

  CyberDax - Unauthorized Engineering Access Followed by PLC Manipulation - User Asset Fallback

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Engineering Access

FOLLOWED BY

  an event that matches BB:OT Direct Controller Manipulation

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events match BB:OT Same User and Source Asset Correlation

WITHIN

  <SHORT_ACTOR_FALLBACK_WINDOW>

AND NOT WHEN

  the manipulation event matches BB:OT Approved Maintenance and Work Order

RESPOND

  contribute to the Controller ID offense

  annotate the correlation method as User and Source Asset fallback

Implement the user and stable Source IP fallback as a separate companion rule.

APPLY

  CyberDax - Unauthorized Engineering Access Followed by PLC Manipulation - User Source IP Fallback

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Engineering Access

FOLLOWED BY

  an event that matches BB:OT Direct Controller Manipulation

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events match BB:OT Same User and Stable Source IP Correlation

WITHIN

  <SHORT_SOURCE_IP_FALLBACK_WINDOW>

AND NOT WHEN

  the manipulation event matches BB:OT Approved Maintenance and Work Order

RESPOND

  contribute to the Controller ID offense

  annotate the correlation method as User and stable Source IP fallback

Implement independently suspicious project upload as a parallel event rule.

APPLY

  CyberDax - Independently Suspicious PLC Project Upload

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Project Upload

AND WHEN

  the event matches BB:OT Resolved Controller Identity

AND WHEN

  any of the following project-upload conditions is true:

    Authorized Change Status is not true

    Project Destination Authorization is not true

    Multi-Controller Upload Status is true

RESPOND

  create or contribute to an offense indexed by Controller ID

  classify as Suspicious Engineering Access

  annotate project, source, user, destination, and upload scope

  limit responses by Controller ID, Project ID, and Activity Chain ID

Implement upload followed by manipulation as a separate ordered companion rule.

APPLY

  CyberDax - Suspicious PLC Project Upload Followed by Manipulation

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Project Upload

FOLLOWED BY

  an event that matches BB:OT Direct Controller Manipulation

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events have the same Activity Chain ID

WITHIN

  <UPLOAD_TO_CHANGE_WINDOW>

RESPOND

  contribute to the existing Controller ID offense

  classify as Confirmed Unauthorized Manipulation

  increase magnitude based on controller and changed-object criticality

  annotate the related upload event and prior offense identifier

  create a linked higher-priority offense if reliable contribution is unavailable

Implement unresolved controller handling separately.

APPLY

  CyberDax - Unresolved OT Engineering Activity

ON EVENTS

WHEN

  an event matches BB:OT Suspicious Engineering Access

  or BB:OT Suspicious Project Upload

  or BB:OT Direct Controller Manipulation

AND NOT WHEN

  the event matches BB:OT Resolved Controller Identity

RESPOND

  dispatch an investigation event or notification

  do not create an offense indexed by Controller ID

  add the event identifier to the unresolved-controller reference collection

  annotate source, user, session, engineering system, project, and action

Use the following AQL structure to validate parsing and investigate matched activity.

SELECT

  starttime,

  sourceip,

  destinationip,

  username,

  "Controller ID",

  "Engineering System ID",

  "OT Session ID",

  "Activity Chain ID",

  "Project ID",

  "Engineering Action",

  "Changed Object",

  "Authorized Change Status"

FROM events

WHERE

  "Engineering Action" IS NOT NULL

ORDER BY starttime ASC

LAST <INVESTIGATION_WINDOW>

Rule

Controller or HMI Manipulation Followed by Loss of Control or Process Deviation

Rule Format

QRadar CRE event rules with ordered impact correlation and critical-change companion rule

Detection Purpose

Detect unauthorized controller, HMI, or SCADA manipulation followed by communications loss, operator lockout, controller instability, threshold-confirmed process deviation, manual-operation transition, or operational impact, while independently identifying confirmed critical manipulation with unresolved latent consequences.

Detection Logic

Implement three controlled branches under one durable rule:

·        Preferred activity-chain correlation.

·        Short-window controller-only fallback.

·        Authoritatively confirmed critical manipulation without observed impact.

Qualifying manipulation includes:

·        PLC project, program, logic, task, routine, parameter, credential, network, firmware, reset, restore, or operating-mode changes.

·        HMI or SCADA set-point, alarm, tag, account, administrative, control-mode, or manual-command changes.

·        Interlock, permissive, protection, treatment-limit, or critical process-parameter changes.

Qualifying impact includes:

·        Controller communications loss.

·        Controller fault, stop, restart, reset, or project mismatch.

·        Failed legitimate operator or engineering access.

·        Loss of view or loss of control.

·        Stale or inconsistent process values.

·        Threshold-confirmed process deviation.

·        Manual-operation transition.

·        Process shutdown.

·        Boil-water notice.

·        Wastewater-release concern.

·        Service interruption.

The preferred branch requires:

·        Same non-null Controller ID.

·        Same Activity Chain ID.

·        Manipulation before impact.

·        Impact within the approved change-to-impact interval.

·        Validated impact status.

·        Required independent-evidence conditions.

The controller-only fallback requires:

·        Same non-null Controller ID.

·        A shorter time window.

·        No active approved maintenance.

·        At least two independent evidence paths or one independently critical impact.

·        Validated duration, repetition, threshold, or operational-impact conditions.

The critical-latent branch does not require an impact event when an authoritative unauthorized change affects:

·        Treatment-critical or safety-relevant logic.

·        Hidden, dormant, delayed, or conditionally activated logic.

·        Interlocks, permissives, protection logic, or alarm enforcement.

·        Chemical-dosing or treatment limits.

·        Critical pressure, flow, level, sequencing, or process parameters.

·        Multiple controllers.

·        Malicious project downloads with unresolved latent consequences.

Required Telemetry

·        Industrial NDR and controller or engineering audit events.

·        HMI and SCADA command, configuration, alarm, account, and tag-change logs.

·        Controller-state and communications events.

·        Historian and process-variable data.

·        Independent sensor and field-device data.

·        Operator-lockout and manual-operation records.

·        Laboratory and water-quality data where available.

·        Service-impact and incident records.

·        Controller and dependent-asset relationships.

·        Approved process thresholds.

·        Operating-phase and maintenance context.

·        Independent Evidence Key.

·        Independent Evidence Count.

·        Validated Impact Status.

·        Relationship Type.

·        Activity Chain ID where reliable.

Engineering Implementation Instructions

Create and maintain the following building blocks:

·        BB:OT Unauthorized Controller or HMI Change

·        BB:OT Validated Controller or Process Impact

·        BB:OT Independently Critical Impact

·        BB:OT Critical or Protected Controller Change

·        BB:OT Active Approved Maintenance

·        BB:OT Resolved Controller Identity

Create custom event properties for:

·        Controller ID

·        Change ID

·        Activity Chain ID

·        Relationship Type

·        Impact Category

·        Evidence Source

·        Evidence Data Path

·        Evidence Asset ID

·        Independent Evidence Key

·        Independent Evidence Count

·        Validated Impact Status

·        Independently Critical Impact

·        Treatment-Critical Change

·        Safety-Relevant Change

·        Hidden or Conditional Change

·        Interlock or Permissive Change

·        Critical Process Parameter Change

·        Related Offense ID

Enable, parse in advance, and optimize Controller ID before using it as an offense index.

Resolve impact-to-controller relationships before CRE evaluation in this order:

·        Direct controller identity.

·        Explicit dependent-asset relationship.

·        Process-area fallback.

Validate impact events before CRE evaluation by applying:

·        Approved threshold.

·        Minimum duration.

·        Minimum repetition.

·        Rate of change.

·        Operating phase.

·        Maintenance state.

·        Evidence independence.

Create Independent Evidence Key from:

·        Evidence source system.

·        Data path.

·        Sensor, laboratory source, operator system, or affected asset.

Calculate Independent Evidence Count across the bounded impact interval.

Do not count multiple categories originating from the same controller, HMI, historian path, sensor, or dependent system as independent evidence.

Create the preferred CRE rule:

·        BB:OT Unauthorized Controller or HMI Change occurs.

·        BB:OT Validated Controller or Process Impact subsequently occurs.

·        Both events contain a non-null Controller ID.

·        Both share Controller ID.

·        Both share Activity Chain ID.

·        Required relationship and evidence tests pass.

Create a fallback CRE rule under the same durable CyberDax rule:

·        Activity Chain ID is unavailable.

·        Both events contain and share a non-null Controller ID.

·        The interval is shorter.

·        Independent Evidence Count is at least two, or Independently Critical Impact is true.

·        Approved maintenance is not active.

Create a separate critical-change event rule:

·        BB:OT Critical or Protected Controller Change occurs.

·        Authorized Change Status is not true.

·        Controller ID is non-null.

·        No later impact event is required.

Where possible, contribute Rule 2 events to the existing Rule 1 offense by Controller ID and annotate the related Activity Chain ID or Change ID.

If updating the original offense is unreliable, create a linked Rule 2 offense containing the related Rule 1 offense identifier.

For null Controller ID, dispatch an investigation event and do not attempt Controller ID offense indexing.

Limit repeated responses by Controller ID, Change ID or Activity Chain ID, classification, and bounded interval.

Re-alert when a new independent consequence appears, a new process area is affected, severity increases, another controller becomes involved, or activity resumes after the quiet period.

DRI Assessment

Reliability is high when unauthorized changes, controller relationships, validated impact status, and independent-evidence counts are accurately populated.

Reliability decreases when process evidence is not independent, relationship mappings are incomplete, or impact events are transient.

The score is a design-stage estimate and requires local validation.

DRI

9.3

TCR Assessment

Operational coverage is strong where change, controller-state, HMI/SCADA, and process events are centralized in QRadar.

Full coverage requires independent process evidence, reliable dependency mappings, approved thresholds, operator records, and laboratory or field validation where appropriate.

The scores are design-stage estimates and require local validation.

Operational TCR

9.0

Full-Telemetry TCR

9.7

Limitations

·        Process effects may be delayed or conditional.

·        HMI, historian, and controller telemetry may derive from the same manipulated source.

·        Equipment failure, sensor failure, maintenance, environmental conditions, or operator error may resemble cyber-induced deviation.

·        Process-area fallback is less reliable than direct or explicit dependency correlation.

·        Controller-only fallback may associate unrelated activity if its interval is too broad.

·        Independent-evidence counting requires reliable enrichment.

·        Null Controller ID prevents Controller ID offense indexing.

·        Time misalignment can disrupt sequence evaluation.

Detection Query Pattern

Implement the preferred activity-chain sequence.

APPLY

  CyberDax - Controller or HMI Manipulation Followed by Process Impact

ON EVENTS

WHEN

  an event matches BB:OT Unauthorized Controller or HMI Change

FOLLOWED BY

  an event that matches BB:OT Validated Controller or Process Impact

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

AND WHEN

  both events have the same Activity Chain ID

WITHIN

  <CHANGE_TO_IMPACT_WINDOW>

AND WHEN

  Relationship Type is Direct Controller

  or Explicit Dependency

AND WHEN

  Independent Evidence Count is at least 1

  or Independently Critical Impact is true

RESPOND

  contribute to or create an offense indexed by Controller ID

  classify as Manipulation Followed by Loss of Control or Process Deviation

  annotate Change ID, Activity Chain ID, impact category, evidence source,

  relationship type, and independent evidence count

Implement process-area fallback separately.

APPLY

  CyberDax - Controller Manipulation and Process-Area Impact Fallback

ON EVENTS

WHEN

  an event matches BB:OT Unauthorized Controller or HMI Change

FOLLOWED BY

  an event that matches BB:OT Validated Controller or Process Impact

WHEN

  both events match BB:OT Resolved Controller Identity

AND WHEN

  both events have the same Controller ID

WITHIN

  <SHORT_PROCESS_AREA_FALLBACK_WINDOW>

AND WHEN

  Relationship Type is Process Area Fallback

AND WHEN

  Independent Evidence Count is at least 2

  or Independently Critical Impact is true

AND NOT WHEN

  the impact event matches BB:OT Active Approved Maintenance

RESPOND

  contribute to or create an offense indexed by Controller ID

  annotate the correlation method as process-area fallback

Implement critical manipulation independently.

APPLY

  CyberDax - Critical PLC Manipulation or Latent Process Risk

ON EVENTS

WHEN

  an event matches BB:OT Critical or Protected Controller Change

AND WHEN

  the event matches BB:OT Resolved Controller Identity

AND WHEN

  Authorized Change Status is not true

RESPOND

  contribute to or create an offense indexed by Controller ID

  classify as Critical Manipulation or Latent Process Risk

  increase severity for treatment-critical, safety-relevant,

  hidden or conditional, interlock, permissive, protection,

  or critical process parameter changes

Implement unresolved controller handling separately.

APPLY

  CyberDax - Unresolved Controller Impact Correlation

ON EVENTS

WHEN

  an event matches BB:OT Unauthorized Controller or HMI Change

  or BB:OT Validated Controller or Process Impact

  or BB:OT Critical or Protected Controller Change

AND NOT WHEN

  the event matches BB:OT Resolved Controller Identity

RESPOND

  dispatch an investigation event or notification

  do not create an offense indexed by Controller ID

  add the event to the unresolved-controller reference collection

Use the following AQL structure for investigation and relationship validation.

SELECT

  starttime,

  sourceip,

  destinationip,

  username,

  "Controller ID",

  "Change ID",

  "Activity Chain ID",

  "Engineering Action",

  "Changed Object",

  "Impact Category",

  "Relationship Type",

  "Evidence Source",

  "Independent Evidence Key",

  "Independent Evidence Count",

  "Validated Impact Status"

FROM events

WHERE

  "Engineering Action" IS NOT NULL

  OR "Impact Category" IS NOT NULL

ORDER BY starttime ASC

LAST <INVESTIGATION_WINDOW>

Rule

Multi-Controller or Cross-Facility Manipulation Expansion

Rule Format

QRadar anomaly rules using accumulated unique counts over pre-normalized entity-target saved searches

Detection Purpose

Detect one source, identity, engineering workstation, remote-access session, project, artifact, or repeated change pattern performing unauthorized engineering or administrative activity across multiple controllers, process areas, facilities, or sites.

Detection Logic

Evaluate expansion separately for:

·        Engineering source or workstation.

·        User or identity.

·        Remote-access session.

·        Project or artifact.

·        Repeated change pattern.

Do not combine entity classes into one fallback property.

Evaluate approved scope according to entity type:

·        User to controller.

·        Engineering workstation to controller.

·        Remote session to site.

·        Integrator to facility.

·        Project to controller.

·        Change ticket to asset.

Determine scope status for each entity-target event before anomaly-rule evaluation.

Preserve out-of-scope target identity even when the same entity also performs approved activity.

Promote activity when an entity performs unauthorized or unexplained engineering activity against:

·        Multiple controllers outside approved scope.

·        Multiple process areas not covered by the same work order.

·        Multiple facilities or sites.

·        Controller vendors or families not normally managed by the entity.

·        Targets consistent with discovery followed by manipulation.

·        Multiple assets later experiencing similar communications, fault, lockout, process, or manual-operation effects.

Do not apply approved operational scope to a generic change pattern.

Evaluate repeated change patterns through target distribution, rarity, timing, similarity, and related source, user, session, or project context.

Required Telemetry

·        Pre-normalized engineering entity-target events.

·        Entity Type.

·        Entity ID.

·        Controller ID.

·        Process Area.

·        Facility ID.

·        Site ID.

·        Controller vendor and family.

·        Engineering Action.

·        Changed Object Type.

·        Per-Target Scope Approved.

·        Activity Cluster ID.

·        Controller criticality.

·        Target rarity.

·        Work-order and maintenance status.

·        Related Rule 1 and Rule 2 offense identifiers where available.

Engineering Implementation Instructions

Generate separate entity-target events for:

·        Source asset.

·        User.

·        Remote-access session.

·        Project or artifact.

·        Repeated change pattern.

Each event must contain one Entity Type and one Entity ID.

Do not merge source, user, session, project, IP address, or change pattern through one fallback property.

Populate reference maps or tables for:

·        Source-asset-to-controller scope.

·        User-to-controller scope.

·        Remote-session-to-site scope.

·        Project-to-controller scope.

·        Integrator-to-facility scope.

·        Entity-to-historical-controller relationships.

Calculate Per-Target Scope Approved before the saved search and anomaly rule evaluate the event.

Generate Activity Cluster ID upstream or through a stateful integration that starts a new cluster when the pause between events for the same entity exceeds the approved interval.

Do not use a fixed time bucket alone as Activity Cluster ID.

Create one saved search per Entity Type or one carefully grouped saved search that includes:

·        Entity Type.

·        Entity ID.

·        Activity Cluster ID.

·        Controller ID.

·        Process Area.

·        Facility ID.

·        Site ID.

·        Controller vendor.

·        Per-Target Scope Approved.

·        Related offense identifiers.

Filter the saved search to unauthorized or unexplained entity-target activity.

Create anomaly rules that use accumulated properties, including:

·        UniqueCount(Controller ID)

·        UniqueCount(Process Area)

·        UniqueCount(Facility ID)

·        UniqueCount(Site ID)

·        UniqueCount(Controller Vendor)

Test each accumulated property separately for each grouping of:

·        Entity Type.

·        Entity ID.

·        Activity Cluster ID.

Do not present distinct-controller or distinct-facility accumulation as an ordinary CRE event-count threshold.

Use anomaly-rule responses to dispatch a normalized expansion event.

Use a downstream CRE event rule to:

·        Require non-null Entity ID and Activity Cluster ID.

·        Create the expansion offense.

·        Index or group the offense by Entity ID when that property is enabled, parsed, optimized, and non-null.

·        Annotate Activity Cluster ID and accumulated target counts.

·        Reference related Rule 1 and Rule 2 offenses.

For null Entity ID:

·        Do not attempt custom-property offense indexing.

·        Dispatch an investigation-only response.

·        Add the event to an unresolved-entity reference collection.

Maintain affected and out-of-scope target lists through:

·        Reference maps.

·        Reference map-of-sets.

·        An upstream summary event.

·        A linked AQL investigation search.

Limit repeated responses by Entity Type, Entity ID, Activity Cluster ID, and accumulated target class.

Re-alert when a new facility or site is affected, the controller set materially expands, severity increases, a new impact category appears, or a new Activity Cluster ID is observed.

DRI Assessment

Reliability is high when entity identities, target scope, facility mappings, saved-search grouping, and activity clusters are prepared accurately.

Reliability decreases in centralized engineering environments with broad legitimate access, shared accounts, NAT, weak change records, or inaccurate entity preprocessing.

The score is a design-stage estimate and requires local validation.

DRI

9.0

TCR Assessment

Operational coverage is strong for centralized network-visible expansion.

Full telemetry improves attribution through engineering audit, identity, project, remote-access, change-management, controller-state, and process-impact evidence.

The scores are design-stage estimates and require local validation.

Operational TCR

8.9

Full-Telemetry TCR

9.5

Limitations

·        Central engineering teams and integrators may legitimately manage many controllers.

·        Shared accounts, NAT, and jump hosts may obscure the responsible entity.

·        Local or serial programming may not be centrally visible.

·        Vendor protocols may normalize similar actions differently.

·        Low-and-slow activity may span separate activity clusters.

·        Incorrect scope reference data can create false positives or false negatives.

·        Anomaly rules require correctly grouped saved searches and accumulated properties.

·        Null Entity ID prevents custom-property offense indexing.

·        The rule depends on pre-normalized entity-target events and reliable Activity Cluster IDs.

Detection Query Pattern

Create the source-asset expansion anomaly rule from a saved search grouped by Entity ID and Activity Cluster ID.

APPLY

  CyberDax - Source Asset Multi-Controller Expansion

AS AN ANOMALY RULE

USING SAVED SEARCH

  CyberDax - Unauthorized OT Entity Target Activity - Source Asset

GROUP EACH RESULT BY

  Entity ID

  Activity Cluster ID

TEST ACCUMULATED PROPERTY

  UniqueCount(Controller ID)

WHEN

  UniqueCount(Controller ID) is at least <CONTROLLER_THRESHOLD>

RESPOND

  dispatch a CyberDax OT Expansion Threshold event

  include Entity Type, Entity ID, Activity Cluster ID,

  controller count, facility count, site count,

  and related offense identifiers

Create equivalent anomaly rules for user, remote session, and project entities.

APPLY

  CyberDax - <ENTITY_TYPE> Multi-Controller or Cross-Facility Expansion

AS AN ANOMALY RULE

USING SAVED SEARCH

  CyberDax - Unauthorized OT Entity Target Activity - <ENTITY_TYPE>

GROUP EACH RESULT BY

  Entity ID

  Activity Cluster ID

TEST ACCUMULATED PROPERTY

  UniqueCount(Controller ID)

  or UniqueCount(Facility ID)

  or UniqueCount(Site ID)

WHEN

  the locally approved accumulated-property threshold is reached

RESPOND

  dispatch a CyberDax OT Expansion Threshold event

  include the triggering accumulated property and count

Create repeated change-pattern expansion as an anomaly rule over a change-pattern saved search.

APPLY

  CyberDax - Repeated PLC Change Pattern Expansion

AS AN ANOMALY RULE

USING SAVED SEARCH

  CyberDax - Unauthorized OT Change Pattern Activity

GROUP EACH RESULT BY

  Entity ID

  Activity Cluster ID

TEST ACCUMULATED PROPERTIES

  UniqueCount(Controller ID)

  UniqueCount(Controller Vendor)

  UniqueCount(Facility ID)

WHEN

  UniqueCount(Controller ID) is at least <PATTERN_CONTROLLER_THRESHOLD>

AND WHEN

  UniqueCount(Controller Vendor) is at least <PATTERN_VENDOR_THRESHOLD>

  or UniqueCount(Facility ID) is at least <PATTERN_FACILITY_THRESHOLD>

RESPOND

  dispatch a CyberDax Repeated Change Pattern Expansion event

Use a downstream CRE rule to create the expansion offense.

APPLY

  CyberDax - Multi-Controller or Cross-Facility Manipulation Expansion

ON EVENTS

WHEN

  an event is dispatched by a CyberDax OT expansion anomaly rule

AND WHEN

  Entity ID is not null

AND WHEN

  Activity Cluster ID is not null

RESPOND

  create a separate expansion offense indexed or grouped by Entity ID

  annotate Entity Type, Activity Cluster ID,

  triggering accumulated property, accumulated count,

  controller count, process-area count, facility count, and site count

  reference related Rule 1 and Rule 2 offense identifiers

  limit responses by Entity Type, Entity ID, and Activity Cluster ID

Implement unresolved Entity ID handling separately.

APPLY

  CyberDax - Unresolved OT Expansion Entity

ON EVENTS

WHEN

  an event is dispatched by a CyberDax OT expansion anomaly rule

AND WHEN

  Entity ID is null

RESPOND

  dispatch an investigation notification

  do not create an offense indexed by Entity ID

  add the event to the unresolved-entity reference collection

Use the following AQL structure to validate entity-target normalization and investigate expansion.

SELECT

  MIN(starttime) AS first_seen,

  MAX(starttime) AS last_seen,

  "Entity Type",

  "Entity ID",

  "Activity Cluster ID",

  COUNT(*) AS event_count,

  UNIQUECOUNT("Controller ID") AS controller_count,

  UNIQUECOUNT("Process Area") AS process_area_count,

  UNIQUECOUNT("Facility ID") AS facility_count,

  UNIQUECOUNT("Site ID") AS site_count

FROM events

WHERE

  "Entity Type" IS NOT NULL

  AND "Entity ID" IS NOT NULL

  AND "Activity Cluster ID" IS NOT NULL

  AND "Per-Target Scope Approved" != 'true'

GROUP BY

  "Entity Type",

  "Entity ID",

  "Activity Cluster ID"

ORDER BY last_seen DESC

LAST <EXPANSION_INVESTIGATION_WINDOW>

SIGMA

Detection Viability Assessment

Sigma provides strong portable detection-definition viability when industrial NDR, PLC engineering, HMI/SCADA, remote-access, controller-state, historian, process, asset, and change-management events are normalized into a controlled OT field taxonomy.

The three durable rules use:

·        Base Sigma rules for qualifying access, manipulation, project-upload, impact, critical-change, and expansion events.

·        Sigma temporal_ordered correlations for ordered access-to-manipulation and manipulation-to-impact behavior.

·        Sigma value_count correlations for distinct-controller, process-area, facility, site, and vendor expansion.

·        Separate standalone rules where an event must remain independently alertable.

·        Backend-specific processing pipelines for local field mapping, logsource selection, authorization enrichment, threshold validation, and alert handling.

The YAML uses concrete default timespans so that the correlation documents remain schema-valid:

·        Access to manipulation: 30m

·        Upload to manipulation: 30m

·        Preferred manipulation to impact: 30m

·        Controller-only fallback: 10m

·        Expansion analytics: 1h

·        Repeated-pattern expansion: 2h

These are CyberDax engineering defaults. They must be tuned to the facility’s operating model, telemetry latency, controller density, remote-support workflow, and normal engineering duration before production deployment.

Sigma correlation support varies by target backend. A conversion backend must support the specified grouping, ordering, distinct-value counting, and timespan behavior before the generated detection is approved for deployment.

Rule

Unauthorized Engineering Access Followed by PLC Manipulation

Rule Format

Sigma base rules with temporal_ordered correlations and a separate independently alertable project-upload rule

Detection Purpose

Detect unauthorized or abnormal access to an OT engineering environment followed by PLC project transfer, logic modification, parameter modification, credential change, network change, firmware activity, reset, restore, or operating-mode manipulation.

Detection Logic

Correlate suspicious access with subsequent controller-engineering activity involving the same controller and attributable activity chain.

Qualifying access activity includes:

·        VPN, privileged-access, remote-desktop, cellular, jump-host, firewall, or vendor-support access from an unauthorized source.

·        Access by an unauthorized, dormant, shared, default, vendor, integrator, or out-of-scope account.

·        A first-seen source-to-engineering-system or source-to-controller relationship.

·        IT-to-OT, internet-to-OT, cellular-to-OT, or cross-zone access outside the approved architecture.

·        Failed authentication followed by successful engineering access.

·        Access outside an approved work order, maintenance window, commissioning event, recovery action, or emergency change.

Qualifying manipulation activity includes:

·        Project download or full program download.

·        Online edit or program append.

·        Logic, task, routine, program, function-block, tag, or parameter change.

·        Controller credential, password, privilege, IP address, subnet, gateway, routing, communications, or management-setting change.

·        Firmware update, firmware replacement, or firmware-update-mode activation.

·        Controller reset, memory clear, project restore, or operating-mode change.

Treat project upload as lower-confidence engineering-access or collection activity.

Project upload alerts through either:

·        A standalone suspicious-upload rule when the upload is unauthorized, uses an unauthorized destination, or involves multi-controller collection.

·        An ordered upload-to-manipulation correlation when suspicious upload is followed by controller manipulation.

Classify activity as:

·        Suspicious engineering access.

·        Confirmed unauthorized manipulation.

·        Critical manipulation or latent process risk.

Critical classification applies when confirmed unauthorized activity affects treatment-critical or safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection conditions, chemical-dosing limits, critical process parameters, or multiple controllers.

Required Telemetry

·        Remote-access, VPN, privileged-access, jump-host, firewall, cellular, and authentication logs.

·        Industrial NDR and controller-management events.

·        PLC and engineering-software audit logs.

·        Controller identifier.

·        Engineering-system identifier.

·        Source asset and source address.

·        User and session identifiers.

·        Actor key.

·        Activity Chain ID.

·        Normalized engineering action.

·        Project identifier.

·        Changed object.

·        Process area.

·        Authorization status.

·        Project-destination authorization.

·        Multi-controller upload status.

·        Criticality and protected-object status.

Engineering Implementation Instructions

Define a controlled OT Sigma taxonomy or processing pipeline that maps local source fields to:

·        ControllerId

·        EngineeringSystemId

·        SourceAssetId

·        SourceIp

·        User

·        SessionId

·        ActorKey

·        ActivityChainId

·        EngineeringAction

·        ProjectId

·        ChangedObject

·        ProcessArea

·        Authorized

·        DestinationAuthorized

·        MultiControllerCollection

·        TreatmentCritical

·        SafetyRelevant

·        HiddenOrConditional

·        InterlockOrPermissive

·        CriticalProcessParameter

The following fields are mandatory for the preferred ordered correlations:

·        ControllerId

·        ActivityChainId

Generate Activity Chain ID before Sigma evaluation using:

·        Controller.

·        Attributable session or actor.

·        Engineering source.

·        Project where available.

·        Bounded activity period.

Do not assign the same Activity Chain ID to unrelated activity sharing only a controller, username, facility, or broad time window.

Create separate base components for:

·        Suspicious engineering access.

·        Direct controller manipulation.

·        Suspicious project upload used only by correlation.

·        Critical or protected controller manipulation.

Create a separate standalone suspicious project-upload rule with a distinct rule ID and name. Do not rely on a correlation component to generate the independent alert.

Create one temporal_ordered correlation for suspicious access followed by manipulation.

Create one temporal_ordered correlation for suspicious project upload followed by manipulation.

Use backend alert suppression based on:

·        Controller ID.

·        Activity Chain ID.

·        Project ID where available.

·        Alert classification.

Rule 2 should enrich, supersede, or reference Rule 1 when process impact or critical latent risk is established.

Rule 3 should remain a separate expansion alert.

Do not approve a generated backend query if it cannot preserve ordered correlation or all mandatory grouping fields.

DRI Assessment

Reliability is high when controller, activity-chain, authorization, action, and project fields are consistently normalized.

Reliability decreases when shared accounts, NAT, generic jump hosts, missing activity-chain identifiers, or generic industrial writes weaken attribution.

The score is a design-stage estimate and requires local validation.

DRI

9.0

TCR Assessment

Operational coverage is strong where access and engineering events are normalized into a backend supporting Sigma ordered correlations.

Full telemetry adds authoritative controller audit, project integrity, HMI/SCADA, historian, operator, and process evidence.

The scores are design-stage estimates and require local validation.

Operational TCR

8.7

Full-Telemetry TCR

9.5

Limitations

·        Sigma defines portable detection logic but does not provide telemetry or enrichment.

·        Some conversion backends do not support ordered correlations.

·        Local, serial, removable-media, or unmonitored engineering activity may not be visible.

·        Shared accounts, NAT, and common jump hosts may weaken attribution.

·        Project upload may represent approved backup or troubleshooting.

·        Activity Chain ID must be generated before Sigma evaluation.

·        Authorization and maintenance context require preprocessing or backend enrichment.

·        Unsupported correlation behavior must not be converted into an unordered approximation.

·        The concrete default timespans require local tuning before production deployment.

Detection Query Pattern

Deploy the following standalone suspicious-upload rule as an independent Sigma detection.

title: Independently Suspicious PLC Project Upload

id: 397dfabe-2f04-4a45-bf1a-230623ea70dd

name: independently_suspicious_plc_project_upload

status: test

description: Detects unauthorized PLC project uploads, unauthorized project-transfer destinations, or multi-controller project collection.

logsource:

    category: application

    product: ot

    definition: Normalized PLC engineering project-transfer events

detection:

    selection_upload:

        EventCategory: configuration

        EngineeringAction: project_upload

        ControllerId|exists: true

    selection_unauthorized:

        Authorized: false

    selection_destination:

        DestinationAuthorized: false

    selection_collection:

        MultiControllerCollection: true

    condition: selection_upload and (selection_unauthorized or selection_destination or selection_collection)

level: medium

Deploy the following multi-document package for access followed by manipulation. The project-upload component has a separate name and ID from the standalone alert.

title: Suspicious OT Engineering Access Correlation Component

id: 71889abc-38de-4fc7-a460-2d89ee350f7d

name: suspicious_ot_engineering_access_component

status: test

logsource:

    category: network_connection

    product: ot

    definition: Normalized remote-access and engineering-access events

detection:

    selection:

        EventCategory: engineering_access

        AccessSuccessful: true

        AccessSuspicious: true

        Authorized: false

        ControllerId|exists: true

        ActivityChainId|exists: true

    condition: selection

---

title: Unauthorized PLC Engineering Manipulation Correlation Component

id: c5db138f-d61c-47e0-a679-bc79b9959fd6

name: unauthorized_plc_engineering_manipulation_component

status: test

logsource:

    category: application

    product: ot

    definition: Normalized PLC, HMI, SCADA, and engineering audit events

detection:

    selection:

        EventCategory: configuration

        Authorized: false

        ControllerId|exists: true

        ActivityChainId|exists: true

        EngineeringAction:

            - project_download

            - download_all

            - online_edit

            - program_append

            - logic_change

            - task_change

            - routine_change

            - function_block_change

            - parameter_change

            - credential_change

            - network_configuration_change

            - firmware_update

            - firmware_replacement

            - firmware_update_mode

            - controller_reset

            - memory_clear

            - project_restore

            - operating_mode_change

    condition: selection

---

title: Suspicious PLC Project Upload Correlation Component

id: 840db27e-b7b0-4635-b148-57e0a4a11466

name: suspicious_plc_project_upload_component

status: test

logsource:

    category: application

    product: ot

    definition: Normalized engineering project-transfer events used for ordered correlation

detection:

    selection_upload:

        EventCategory: configuration

        EngineeringAction: project_upload

        ControllerId|exists: true

        ActivityChainId|exists: true

    selection_unauthorized:

        Authorized: false

    selection_destination:

        DestinationAuthorized: false

    selection_collection:

        MultiControllerCollection: true

    condition: selection_upload and (selection_unauthorized or selection_destination or selection_collection)

---

title: Unauthorized Engineering Access Followed by PLC Manipulation

id: 4f40f13e-d56d-4b7e-a2be-505c24a5111d

status: test

description: Detects suspicious engineering access followed by unauthorized PLC manipulation within the same controller activity chain.

correlation:

    type: temporal_ordered

    rules:

        - suspicious_ot_engineering_access_component

        - unauthorized_plc_engineering_manipulation_component

    group-by:

        - ControllerId

        - ActivityChainId

    timespan: 30m

level: high

---

title: Suspicious PLC Project Upload Followed by Manipulation

id: d0d82140-4de4-45cd-a09d-7a27468f8f2e

status: test

description: Detects suspicious PLC project upload followed by unauthorized controller manipulation.

correlation:

    type: temporal_ordered

    rules:

        - suspicious_plc_project_upload_component

        - unauthorized_plc_engineering_manipulation_component

    group-by:

        - ControllerId

        - ActivityChainId

    timespan: 30m

level: high

Rule

Controller or HMI Manipulation Followed by Loss of Control or Process Deviation

Rule Format

Sigma base rules with exclusive preferred and fallback temporal_ordered correlations and an independently alertable critical-change companion

Detection Purpose

Detect unauthorized controller, HMI, or SCADA manipulation followed by communications loss, operator lockout, controller instability, threshold-confirmed process deviation, manual-operation transition, or operational impact, while independently identifying confirmed critical manipulation with unresolved latent consequences.

Detection Logic

Implement three controlled branches:

·        Preferred activity-chain correlation.

·        Exclusive short-window controller-only fallback.

·        Critical manipulation without observed impact.

The preferred branch requires:

·        Unauthorized change.

·        Subsequent validated impact.

·        Same controller.

·        Same Activity Chain ID.

·        Approved change-to-impact timespan.

The controller-only fallback applies only when Activity Chain ID is absent from both component events and requires:

·        Same controller.

·        Shorter timespan.

·        Validated impact.

·        At least two independent evidence paths or an independently critical impact.

·        No active approved maintenance state.

Qualifying manipulation includes:

·        PLC project, program, logic, task, routine, parameter, credential, network, firmware, reset, restore, or operating-mode changes.

·        HMI or SCADA set-point, alarm, tag, account, administrative, control-mode, or manual-command changes.

·        Interlock, permissive, protection, treatment-limit, or critical process-parameter changes.

Qualifying impact includes:

·        Controller communications loss.

·        Controller fault, stop, restart, reset, or project mismatch.

·        Failed legitimate operator or engineering access.

·        Loss of view or loss of control.

·        Stale or inconsistent process values.

·        Threshold-confirmed process deviation.

·        Manual-operation transition.

·        Process shutdown.

·        Boil-water notice.

·        Wastewater-release concern.

·        Service interruption.

The critical-manipulation branch does not require observed impact when unauthorized changes involve:

·        Treatment-critical or safety-relevant logic.

·        Hidden, dormant, delayed, or conditionally activated logic.

·        Interlocks, permissives, protection logic, or alarm enforcement.

·        Chemical-dosing or treatment limits.

·        Critical pressure, flow, level, sequencing, or process parameters.

·        Multiple controllers.

·        Malicious project downloads with unresolved latent consequences.

Required Telemetry

·        Controller and engineering audit events.

·        HMI and SCADA configuration and command events.

·        Controller-state and communications events.

·        Historian and process-variable data.

·        Independent sensor, field-device, laboratory, operator, and incident data.

·        Controller identifier.

·        Activity Chain ID where reliable.

·        Relationship type.

·        Validated-impact status.

·        Independent Evidence Count.

·        Independently Critical Impact.

·        Maintenance status.

·        Critical-change classifications.

Engineering Implementation Instructions

Preprocessing is mandatory before Sigma evaluation.

The preprocessing layer must:

·        Resolve each impact to a controller.

·        Set Relationship Type.

·        Validate process thresholds.

·        Validate duration and repetition.

·        Validate rate of change.

·        Validate operating phase.

·        Validate maintenance state.

·        Create independent-evidence keys.

·        Calculate Independent Evidence Count.

·        Set Independently Critical Impact.

·        Generate Activity Chain ID where reliable.

Create separate preferred component rules requiring ActivityChainId|exists: true for both the change and impact events.

Create separate fallback component rules requiring ActivityChainId|exists: false for both the change and impact events.

Do not reuse the preferred change component in the controller-only fallback.

The preferred impact component must require either:

·        Direct or explicit dependency with at least one independent evidence path.

·        An independently critical impact.

The fallback impact component must require either:

·        At least two independent evidence paths.

·        An independently critical impact.

The fallback must use the shorter 10m timespan.

Do not emulate Activity Chain ID by grouping only on user, facility, source address, or process area.

The critical-change rule remains independently alertable.

Use backend suppression based on:

·        Controller ID.

·        Activity Chain ID where available.

·        Change ID where available.

·        Classification.

Do not approve conversion if the backend cannot preserve ordered temporal behavior.

DRI Assessment

Reliability is high when change, impact, relationship, maintenance, and evidence-independence fields are correctly prepared.

Reliability decreases when process evidence is not independent, relationships are incomplete, or controller-only fallback windows are too broad.

The score is a design-stage estimate and requires local validation.

DRI

9.2

TCR Assessment

Operational coverage is strong where controller, HMI/SCADA, communications, and process events are normalized into a correlation-capable backend.

Full coverage requires independent process evidence, reliable dependency mappings, approved thresholds, operator records, and laboratory or field validation where appropriate.

The scores are design-stage estimates and require local validation.

Operational TCR

8.9

Full-Telemetry TCR

9.7

Limitations

·        Process effects may be delayed or conditional.

·        Controller, HMI, and historian data may derive from the same manipulated source.

·        Equipment failure, maintenance, sensor failure, environmental conditions, or operator error may resemble cyber-induced effects.

·        Controller-only fallback may associate unrelated activity.

·        Evidence independence must be calculated before Sigma evaluation.

·        Some conversion backends do not support ordered temporal correlations.

·        Sigma cannot calculate stateful threshold validation or asset relationships by itself.

·        Unsupported ordered behavior must not be converted into unordered proximity.

·        The default correlation windows require local validation.

Detection Query Pattern

Deploy the critical unauthorized-change rule independently.

title: Critical Unauthorized PLC or HMI Manipulation

id: 745325e9-23dd-43e5-9896-f732dbab2980

name: critical_unauthorized_ot_change

status: test

logsource:

    category: application

    product: ot

    definition: Normalized critical PLC and HMI or SCADA change events

detection:

    selection:

        EventCategory: configuration

        Authorized: false

        ControllerId|exists: true

    critical:

        TreatmentCritical: true

    safety:

        SafetyRelevant: true

    hidden:

        HiddenOrConditional: true

    protection:

        InterlockOrPermissive: true

    process:

        CriticalProcessParameter: true

    condition: selection and (critical or safety or hidden or protection or process)

level: critical

Deploy the following preferred and fallback correlation package.

title: Unauthorized Controller or HMI Change With Activity Chain

id: c9df02cb-82b2-42d4-b563-5d17c4874081

name: unauthorized_ot_controller_change_preferred

status: test

logsource:

    category: application

    product: ot

    definition: Normalized PLC engineering and HMI or SCADA changes with reliable activity-chain identity

detection:

    selection:

        EventCategory: configuration

        Authorized: false

        ControllerId|exists: true

        ActivityChainId|exists: true

        EngineeringAction:

            - project_download

            - online_edit

            - program_append

            - logic_change

            - task_change

            - routine_change

            - function_block_change

            - parameter_change

            - credential_change

            - network_configuration_change

            - firmware_change

            - controller_reset

            - project_restore

            - operating_mode_change

            - hmi_setpoint_change

            - alarm_configuration_change

            - tag_change

            - manual_command

            - administrative_change

    condition: selection

---

title: Validated Direct or Explicit Dependency OT Impact With Activity Chain

id: b8ea33c5-80ee-47bf-9c49-f119ece587bb

name: validated_direct_ot_impact_preferred

status: test

logsource:

    category: application

    product: ot

    definition: Pre-enriched impact events with reliable controller activity-chain identity

detection:

    selection:

        ImpactValid: true

        ControllerId|exists: true

        ActivityChainId|exists: true

        RelationshipType:

            - direct_controller

            - explicit_dependency

        ImpactCategory:

            - communications_loss

            - controller_fault

            - controller_stop

            - controller_restart

            - project_mismatch

            - operator_lockout

            - loss_of_view

            - loss_of_control

            - stale_process_value

            - inconsistent_process_value

            - process_threshold_breach

            - manual_operations

            - service_interruption

    evidence:

        IndependentEvidenceCount|gte: 1

    critical:

        IndependentlyCriticalImpact: true

    condition: selection and (evidence or critical)

---

title: Unauthorized Controller or HMI Change Without Activity Chain

id: 3a468045-b762-4ae2-a42a-f64dd75f95a1

name: unauthorized_ot_controller_change_fallback

status: test

logsource:

    category: application

    product: ot

    definition: Unauthorized controller changes for exclusive controller-only fallback correlation

detection:

    selection:

        EventCategory: configuration

        Authorized: false

        ControllerId|exists: true

        ActivityChainId|exists: false

        EngineeringAction:

            - project_download

            - online_edit

            - program_append

            - logic_change

            - task_change

            - routine_change

            - function_block_change

            - parameter_change

            - credential_change

            - network_configuration_change

            - firmware_change

            - controller_reset

            - project_restore

            - operating_mode_change

            - hmi_setpoint_change

            - alarm_configuration_change

            - tag_change

            - manual_command

            - administrative_change

    condition: selection

---

title: Validated Process Impact Without Activity Chain

id: 7aaeb705-bb5e-4595-85e9-6191cf97ed14

name: validated_ot_impact_fallback

status: test

logsource:

    category: application

    product: ot

    definition: Pre-enriched impact events for exclusive controller-only fallback correlation

detection:

    selection:

        ImpactValid: true

        MaintenanceActive: false

        ControllerId|exists: true

        ActivityChainId|exists: false

        ImpactCategory:

            - communications_loss

            - controller_fault

            - controller_stop

            - controller_restart

            - project_mismatch

            - operator_lockout

            - loss_of_view

            - loss_of_control

            - stale_process_value

            - inconsistent_process_value

            - process_threshold_breach

            - manual_operations

            - service_interruption

    evidence:

        IndependentEvidenceCount|gte: 2

    critical:

        IndependentlyCriticalImpact: true

    condition: selection and (evidence or critical)

---

title: Controller or HMI Manipulation Followed by Process Impact

id: be5f08f5-4964-444e-ae7c-56eac82a0cf4

status: test

description: Detects unauthorized controller or HMI manipulation followed by validated impact within the same controller activity chain.

correlation:

    type: temporal_ordered

    rules:

        - unauthorized_ot_controller_change_preferred

        - validated_direct_ot_impact_preferred

    group-by:

        - ControllerId

        - ActivityChainId

    timespan: 30m

level: critical

---

title: Controller Manipulation and Process Impact Fallback

id: 1f674940-85ca-4ddb-8e06-456eb4659315

status: test

description: Detects controller manipulation followed by strongly corroborated impact when no reliable activity-chain identifier is present.

correlation:

    type: temporal_ordered

    rules:

        - unauthorized_ot_controller_change_fallback

        - validated_ot_impact_fallback

    group-by:

        - ControllerId

    timespan: 10m

level: critical

Rule

Multi-Controller or Cross-Facility Manipulation Expansion

Rule Format

Sigma base entity-target rule with value_count correlation companions

Detection Purpose

Detect one source, identity, engineering workstation, remote-access session, project, artifact, or repeated change pattern performing unauthorized engineering or administrative activity across multiple controllers, process areas, facilities, sites, or controller vendors.

Detection Logic

Evaluate expansion separately for:

·        Engineering source or workstation.

·        User or identity.

·        Remote-access session.

·        Project or artifact.

·        Repeated change pattern.

Do not combine unrelated entity classes through one fallback field.

Each normalized entity-target event must contain:

·        One Entity Type.

·        One Entity ID.

·        One Activity Cluster ID.

·        One Controller ID.

·        Per-target scope status.

·        Relevant facility, site, process-area, and controller-vendor values.

Determine scope authorization before Sigma evaluation.

Create independent value_count correlations for:

·        Distinct controllers.

·        Distinct process areas.

·        Distinct facilities.

·        Distinct sites.

·        Distinct controller vendors for repeated patterns.

Each correlation groups by:

·        Entity Type.

·        Entity ID.

·        Activity Cluster ID.

Do not attempt to express multiple alternative distinct-value conditions inside one unsupported correlation object.

For repeated change patterns, use companion correlations for:

·        Distinct-controller threshold.

·        Distinct-vendor threshold.

·        Distinct-facility threshold.

A backend-native higher-level analytic may combine the companion alerts when correlation chaining is supported.

Required Telemetry

·        Pre-normalized unauthorized entity-target events.

·        Entity Type.

·        Entity ID.

·        Activity Cluster ID.

·        Controller ID.

·        Process Area.

·        Facility ID.

·        Site ID.

·        Controller Vendor.

·        Engineering Action.

·        Changed Object Type.

·        Per-Target Scope Approved.

·        Controller criticality.

·        Target rarity.

·        Related Rule 1 and Rule 2 alert identifiers where available.

Engineering Implementation Instructions

Generate separate entity-target documents or events for:

·        Source asset.

·        User.

·        Remote-access session.

·        Project or artifact.

·        Repeated change pattern.

Do not combine source, user, session, project, source IP, or pattern into one EntityId.

Create Activity Cluster ID before Sigma evaluation through a stateful upstream process that starts a new cluster when the approved maximum pause is exceeded.

Do not use a fixed wall-clock bucket as the sole cluster identifier.

Create one base Sigma rule matching unauthorized entity-target activity.

Create separate value_count correlations for each distinct target dimension.

Use environment-specific thresholds based on:

·        Facility size.

·        Controller count.

·        Centralized engineering model.

·        Legitimate integrator scope.

·        Normal multi-site operations.

·        Controller criticality.

Require the selected conversion backend to support:

·        value_count

·        Multiple group-by fields

·        Distinct-value field counting

·        Correct timespan evaluation

If the backend cannot preserve these requirements, deploy a backend-native expansion analytic instead of a degraded Sigma conversion.

Rule 3 should remain a separate expansion alert and reference related Rule 1 and Rule 2 alerts where supported.

Suppress by:

·        Entity Type.

·        Entity ID.

·        Activity Cluster ID.

·        Triggering target dimension.

Re-alert when a new facility or site is affected, the controller set materially expands, severity increases, a new impact appears, or a new Activity Cluster ID is observed.

DRI Assessment

Reliability is high when entity identities, scope decisions, target mappings, and activity clusters are accurately prepared.

Reliability decreases in centralized engineering environments with broad legitimate access, shared accounts, NAT, weak change records, or inaccurate preprocessing.

The score is a design-stage estimate and requires local validation.

DRI

8.9

TCR Assessment

Operational coverage is strong for centralized expansion visible through normalized entity-target events.

Full telemetry improves attribution through engineering audit, identity, project, remote-access, change-management, controller-state, and process-impact evidence.

The scores are design-stage estimates and require local validation.

Operational TCR

8.7

Full-Telemetry TCR

9.4

Limitations

·        Sigma does not generate entity-target events or Activity Cluster IDs.

·        Central engineering teams and integrators may legitimately manage many controllers.

·        Shared accounts, NAT, and common jump hosts may obscure the responsible entity.

·        Local or serial programming may not be centrally visible.

·        Low-and-slow activity may span separate activity clusters.

·        Incorrect scope data can create false positives or false negatives.

·        value_count support varies across conversion backends.

·        A backend that cannot preserve distinct-value counting must not deploy an event-count approximation.

·        Default timespans and thresholds require local validation.

Detection Query Pattern

Deploy the following base rule and companion value_count correlations.

title: Unauthorized OT Engineering Entity Target Activity

id: 03aa36ea-b2e3-4d30-bca4-896bd12325cc

name: unauthorized_ot_entity_target

status: test

logsource:

    category: application

    product: ot

    definition: Pre-normalized entity-target events for unauthorized OT engineering activity

detection:

    selection:

        EventCategory: configuration

        Authorized: false

        PerTargetScopeApproved: false

        EntityType|exists: true

        EntityId|exists: true

        ActivityClusterId|exists: true

        ControllerId|exists: true

        EngineeringAction:

            - project_upload

            - project_download

            - online_edit

            - program_append

            - logic_change

            - task_change

            - routine_change

            - function_block_change

            - parameter_change

            - credential_change

            - network_configuration_change

            - firmware_change

            - controller_reset

            - project_restore

            - operating_mode_change

            - hmi_administrative_change

            - hmi_setpoint_change

            - alarm_configuration_change

    condition: selection

---

title: OT Entity Expansion Across Multiple Controllers

id: 0288a24d-05e6-4c06-8edf-6219230cd230

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 1h

    condition:

        field: ControllerId

        gte: 3

level: high

---

title: OT Entity Expansion Across Multiple Process Areas

id: 9122397c-e911-43bf-b9ad-63187e25477a

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 1h

    condition:

        field: ProcessArea

        gte: 2

level: high

---

title: OT Entity Expansion Across Multiple Facilities

id: 349a2f89-e381-4279-8946-11e2b7835ea4

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 1h

    condition:

        field: FacilityId

        gte: 2

level: critical

---

title: OT Entity Expansion Across Multiple Sites

id: b18f3848-d1bd-4830-9ccd-f50784d75ad8

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 1h

    condition:

        field: SiteId

        gte: 2

level: critical

---

title: Repeated OT Change Pattern Across Multiple Controllers

id: b9f9ed71-31df-4a8c-a9ae-99cb1174efea

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 2h

    condition:

        field: ControllerId

        gte: 3

level: critical

---

title: Repeated OT Change Pattern Across Controller Vendors

id: b67c1f0e-d6e8-4070-8dd2-4b4b3bfeec13

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 2h

    condition:

        field: ControllerVendor

        gte: 2

level: critical

---

title: Repeated OT Change Pattern Across Facilities

id: a027ae5c-8d49-482e-b3c3-dc48d600f238

status: test

correlation:

    type: value_count

    rules:

        - unauthorized_ot_entity_target

    group-by:

        - EntityType

        - EntityId

        - ActivityClusterId

    timespan: 2h

    condition:

        field: FacilityId

        gte: 2

level: critical

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this TTD.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, controller-change driven, engineering-session dependent, industrial-network dependent, HMI/SCADA dependent, process-state dependent, controller-relationship based, process-impact based, asset-scope based, authorization-context based, maintenance-context based, and cross-controller expansion based rather than static-file, malware-signature, or artifact-matching based.

YARA may provide limited supporting value only if a confirmed malicious engineering artifact, PLC project file, controller configuration package, firmware image, exploit harness, loader, dropper, script, archive, memory artifact, credential-harvesting artifact, malicious library, unauthorized engineering plugin, persistence artifact, post-compromise tool, or reusable malware-family artifact is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

AWS Coverage Disposition

AWS has zero deployable rules for this TTD.

AWS is not viable as a primary S25 detection system because the report’s detection model concerns on-premises or operational-technology controller manipulation, engineering access, PLC configuration changes, HMI/SCADA changes, controller operating-state changes, industrial communications, process deviation, loss of control, and cross-facility expansion rather than AWS-native control-plane, identity, workload, storage, network, or managed-service activity.

AWS may provide limited supporting value only where the affected organization intentionally hosts OT-supporting workloads, engineering repositories, remote-access infrastructure, historian services, data pipelines, backup systems, vendor-support services, digital-twin platforms, or industrial-management applications in AWS and the relevant AWS telemetry can be directly correlated with the controller-manipulation chain.

Supporting AWS telemetry may include CloudTrail, VPC Flow Logs, GuardDuty, IAM activity, Systems Manager activity, EC2 process or network telemetry, S3 object access, container-service activity, managed-database activity, and security-group or route changes. These sources would provide supporting cloud context rather than primary PLC-manipulation detection.

Final AWS Outcome

No AWS rules survive.

Azure

Azure Coverage Disposition

Azure has zero deployable rules for this TTD.

Azure is not viable as a primary S25 detection system because the report’s detection model concerns PLC engineering activity, controller configuration manipulation, HMI/SCADA changes, industrial-network behavior, controller operating-state changes, process-impact evidence, operator loss of control, and multi-controller or cross-facility expansion rather than Azure-native identity, control-plane, workload, storage, network, or managed-service activity.

Azure may provide limited supporting value only where the affected organization intentionally hosts OT-supporting workloads, engineering repositories, remote-access infrastructure, historian services, data pipelines, backup systems, vendor-support services, digital-twin platforms, or industrial-management applications in Azure and the relevant Azure telemetry can be directly correlated with the controller-manipulation chain.

Supporting Azure telemetry may include Microsoft Entra ID sign-in and audit logs, Azure Activity Logs, Network Security Group flow logs, virtual-machine telemetry, Azure Arc activity, storage access, Key Vault activity, Azure DevOps activity, container-platform events, and Defender for Cloud alerts. These sources would provide supporting cloud or identity context rather than primary PLC-manipulation detection.

Final Azure Outcome

No Azure rules survive.

GCP

GCP Coverage Disposition

GCP has zero deployable rules for this TTD.

GCP is not viable as a primary S25 detection system because the report’s detection model concerns controller engineering access, PLC configuration changes, HMI/SCADA manipulation, industrial communications, controller-state changes, process deviation, loss of operational control, and multi-controller or cross-facility expansion rather than GCP-native identity, control-plane, workload, storage, network, or managed-service activity.

GCP may provide limited supporting value only where the affected organization intentionally hosts OT-supporting workloads, engineering repositories, remote-access infrastructure, historian services, data pipelines, backup systems, vendor-support services, digital-twin platforms, or industrial-management applications in GCP and the relevant cloud telemetry can be directly correlated with the controller-manipulation chain.

Supporting GCP telemetry may include Cloud Audit Logs, VPC Flow Logs, IAM activity, Compute Engine activity, Cloud Storage access, Google Kubernetes Engine events, service-account activity, firewall changes, route changes, Security Command Center findings, and managed-database activity. These sources would provide supporting cloud context rather than primary PLC-manipulation detection.

Final GCP Outcome

No GCP rules survive.

S26 Threat-to-Rule Traceability

Unauthorized Engineering Access

Covered by NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, and SIGMA where remote-access, engineering-workstation, session, user, source, controller, and authorization telemetry can be correlated.

PLC Project Upload and Engineering Collection Activity

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where project-transfer activity, controller identity, project destination, authorization status, and multi-controller collection context are available.

PLC Logic, Program, Parameter, and Configuration Manipulation

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where controller-management events, engineering audit records, industrial protocol activity, or normalized configuration-change telemetry is available.

Engineering-Workstation Execution and Protected-Artifact Activity

Covered by SentinelOne, Splunk, Elastic, QRadar, and SIGMA where engineering-application execution, protected project files, configuration packages, firmware packages, repositories, or recovery artifacts are visible.

Remote Access or Suspicious Execution Preceding Engineering Activity

Covered by SentinelOne, Splunk, Elastic, QRadar, SIGMA, and NDR correlations where remote-access sessions, scripting activity, transfer utilities, credential activity, process ancestry, engineering-system identity, and controller scope are available.

Controller Credential, Network, Firmware, Reset, Restore, and Operating-Mode Changes

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where the affected controller, engineering source, normalized action, prior state, new state, and authorization context can be identified.

HMI and SCADA Manipulation

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where HMI or SCADA set-point, alarm, tag, account, display, administrative, control-mode, or manual-command changes can be mapped to the affected controller or process area.

Engineering-Workflow Persistence and Protected-Artifact Tampering

Covered by SentinelOne, Splunk, Elastic, QRadar, and SIGMA where scheduled tasks, services, startup activity, scripts, plugins, remote-access mechanisms, project-file changes, repository changes, or recovery-artifact changes are observable.

Controller Communications Loss, Fault, Stop, Restart, and Project Mismatch

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where controller-state, industrial-network, engineering-audit, HMI/SCADA, or controller-management telemetry is available.

Operator Lockout, Loss of View, and Loss of Control

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where operator, HMI/SCADA, remote-access, authentication, controller-state, and process-control events can be joined to the initiating manipulation.

Process Deviation and Operational Impact

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where historian, sensor, field-device, laboratory, operator, service-impact, and controller telemetry can be correlated through validated thresholds and independent evidence paths.

Critical or Latent Process Risk

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where unauthorized changes affect treatment-critical or safety-relevant logic, hidden or conditional logic, interlocks, permissives, protection functions, chemical-dosing limits, or critical process parameters.

Multi-Controller and Cross-Facility Manipulation Expansion

Covered by NDR / Network Behavioral Analytics, Splunk, Elastic, QRadar, and SIGMA where source, user, session, project, pattern, controller, process-area, facility, site, scope, and activity-cluster data can be correlated.

Static Artifact and Malware Detection

YARA has no direct deployable coverage because the primary detection model is behavioral and process-control based. YARA may provide supporting value only when a confirmed malicious project file, firmware image, script, payload, plugin, library, exploit artifact, persistence artifact, or reusable malware-family artifact is recovered.

Cloud Control-Plane and Workload Context

AWS, Azure, and GCP have no direct deployable rules because primary detection depends on PLC, engineering, HMI/SCADA, industrial-network, controller-state, and physical-process telemetry. Cloud logs may provide supporting identity, repository, remote-access, backup, workload, storage, or infrastructure context when those services directly support the affected OT environment.

Evidence and Visibility Gaps

Covered through Required Telemetry, Engineering Implementation Instructions, DRI and TCR assessments, Limitations, authorization and maintenance validation, relationship mapping, independent-evidence requirements, unresolved-identity handling, and explicit non-coverage dispositions.

S29 Detection Coverage Summary

Coverage is strongest where industrial NDR telemetry, PLC and engineering audit logs, HMI/SCADA logs, controller-state events, engineering-workstation endpoint telemetry, remote-access logs, authentication records, historian data, independent sensor evidence, operator records, laboratory or water-quality data, asset relationships, maintenance records, and work orders can be joined by controller, activity chain, source, user, session, project, process area, facility, and time window.

Minimum viable coverage requires visibility into unauthorized engineering access and controller configuration or engineering activity. This includes controller identity, engineering source, normalized action, authorization status, and sufficient actor or session context to avoid controller-only correlation.

Stronger coverage requires correlation between controller or HMI/SCADA manipulation and independently validated operational consequences such as communications loss, controller fault, operator lockout, loss of view, loss of control, threshold-confirmed process deviation, manual-operation transition, or service impact.

The strongest coverage requires authoritative controller or engineering audit evidence, protected-project integrity, validated asset relationships, independent process evidence, approved process thresholds, maintenance and work-order context, and entity-level expansion analysis across controllers, process areas, facilities, and sites.

Endpoint telemetry strengthens coverage for engineering-application execution, remote-access precursors, suspicious execution chains, persistence, protected-project activity, firmware-package activity, and recovery-artifact tampering. Endpoint evidence alone does not confirm that a change reached a controller or affected a physical process.

Cloud-native logs alone are insufficient because AWS, Azure, and GCP do not provide direct visibility into PLC logic, controller operating state, industrial protocol activity, HMI/SCADA manipulation, or physical-process impact. Cloud telemetry provides supporting value only when cloud-hosted identity, remote-access, repository, backup, historian, digital-twin, engineering-support, or vendor-support infrastructure can be tied directly to the controller-manipulation chain.

YARA does not provide primary coverage because no stable malicious file or malware artifact is required for the behavior. YARA becomes relevant only when a validated project artifact, firmware image, script, payload, plugin, library, persistence mechanism, or reusable malware-family artifact is recovered.

Customer-specific telemetry mapping, field normalization, lookup construction, threshold selection, activity-chain generation, and local deployment validation are expected. These implementation requirements do not reduce production readiness when Required Telemetry, Engineering Implementation Instructions, DRI and TCR assessments, Limitations, and the platform-specific rule logic provide the engineer or administrator with a clear implementation path.

S33 Defensive Control & Hardening Improvements

Eliminate direct internet exposure for PLCs, HMIs, SCADA systems, engineering workstations, cellular gateways, and controller-management interfaces where technically feasible. Where direct exposure cannot be removed, restrict access through approved gateways, network controls, source restrictions, strong authentication, and continuous monitoring.

Segment water and wastewater control environments from enterprise, vendor, cellular, wireless, and internet-facing networks. Permit only documented and operationally required communications between approved engineering sources, controllers, HMIs, SCADA systems, historians, remote-access systems, and supporting services.

Require controlled OT jump hosts, managed remote-access gateways, or privileged-access systems for remote engineering, vendor, contractor, and integrator access. Restrict access by named user, approved source, facility, site, controller group, process area, purpose, and maintenance window.

Require MFA for remote access to OT-supporting infrastructure wherever technically feasible. Eliminate default, shared, dormant, unnecessary, and weakly governed credentials, and maintain attributable named-user access for engineering, administrative, remote-access, and controller-management activity.

Restrict PLC programming, project upload, project download, online edit, program append, credential management, network configuration, firmware activity, reset, restore, and operating-mode functions to approved engineering sources and authorized personnel.

Disable or restrict unnecessary programming services, web interfaces, management functions, cellular access paths, serial gateways, remote-access services, and controller protocols according to operational requirements.

Maintain authoritative inventories for PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, historians, OT jump hosts, cellular gateways, remote-access systems, vendor-support systems, controller projects, firmware, and recovery artifacts.

Maintain approved user-to-controller, workstation-to-controller, remote-session-to-site, integrator-to-facility, project-to-controller, and change-ticket-to-asset relationships. Use these relationships to validate whether engineering and administrative activity remains within approved operational scope.

Maintain protected known-good PLC projects, HMI projects, SCADA configurations, controller parameters, firmware packages, configuration baselines, checksums, signatures, and recovery artifacts. Validate project, firmware, configuration, and controller state against these baselines after suspicious activity or material changes.

Require independent authorization and post-change validation for changes affecting treatment-critical or safety-relevant logic, interlocks, permissives, protection functions, chemical dosing, pressure, flow, level, sequencing, alarms, set points, or other critical process limits.

Verify controller state, project version, process values, alarm behavior, equipment response, operator visibility, and safe operating conditions after significant engineering, firmware, configuration, or supervisory-control changes.

Enable and retain controller, engineering-software, HMI/SCADA, historian, remote-access, authentication, endpoint, industrial-network, process, operator, maintenance, and work-order telemetry. Forward relevant records to protected centralized storage with synchronized time and sufficient retention for investigation.

Deploy industrial NDR visibility at appropriate control-network boundaries and critical controller communication paths. Deploy compatible endpoint telemetry on engineering workstations, OT jump hosts, HMI/SCADA support servers, historian servers, vendor-support systems, and other instrumentable assets that directly support the affected control environment.

Monitor for unauthorized or unexplained PLC project upload, project download, online edit, program append, logic change, parameter change, credential change, network-setting change, firmware activity, reset, restore, and operating-mode change.

Monitor HMI and SCADA set-point, alarm, tag, display, account, administrative, control-mode, and manual-command changes when those systems directly support the affected controller or process area.

Monitor project-upload activity for unauthorized destinations, unusual collection volume, multiple-controller collection, first-seen projects, external transfer, or activity outside approved engineering scope.

Correlate controller and supervisory-control changes with communications loss, controller fault, stop, restart, reset, project mismatch, operator lockout, loss of view, loss of control, stale or inconsistent values, process deviation, manual-operation transition, or service impact.

Use historian data, independent sensors, field-device evidence, laboratory or water-quality results, operator records, maintenance records, and work orders to validate process consequences where those sources are available. Detailed production correlation thresholds and evidence-quality requirements should remain aligned with the S21 through S25 implementation guidance.

Protect engineering workstations, project repositories, firmware packages, configuration files, and recovery artifacts from unauthorized modification, deletion, replacement, or external transfer. Restrict removable media and unapproved engineering-support tools where they could be used to introduce, alter, or remove controller-related artifacts.

Include cloud-hosted identity, repository, backup, historian, remote-access, engineering-support, vendor-support, digital-twin, or workload systems in the control scope only when they directly support the affected OT environment. Treat cloud telemetry as supporting context rather than primary PLC-manipulation visibility.

Create incident-response procedures for unauthorized engineering access, suspicious project collection, controller manipulation, HMI/SCADA manipulation, loss of view, loss of control, process deviation, and multi-controller or cross-facility expansion.

Preserve relevant PLC projects, controller records, engineering logs, HMI/SCADA logs, historian data, remote-access logs, endpoint telemetry, industrial-network evidence, operator records, laboratory results, maintenance records, work orders, and recovery artifacts during investigation.

Prepare recovery procedures for isolating affected access paths, securing credentials, comparing controller and project state against known-good baselines, restoring approved configurations, validating process behavior, and returning affected operations to controlled service.

Do not return affected controllers, engineering systems, HMI/SCADA systems, or process areas to trusted production status until minimum authorization, configuration-integrity, operating-state, and safety validation is complete.

S39 — Economic Impact & Organizational Exposure

PLC configuration manipulation and water/wastewater process-control disruption create organizational exposure by turning trusted engineering and supervisory-control authority into a path for unauthorized project collection, controller-program modification, parameter manipulation, credential and network-setting changes, firmware activity, HMI/SCADA manipulation, operator lockout, loss of view, loss of control, process deviation, environmental impact, service interruption, and public-health consequences.

The governing risk is not limited to one PLC vendor, controller family, engineering product, HMI platform, protocol, exposed interface, default credential, CVE, malware family, actor, campaign, project file, ladder-logic program, or proof-of-concept implementation. The material question is whether an adversary obtained or misused engineering, HMI/SCADA, remote-access, or controller-management authority and whether that authority resulted in unauthorized project upload, project download, online edit, program append, logic change, parameter modification, credential change, communications change, firmware activity, operating-mode change, supervisory-control manipulation, process impact, or expansion across multiple controllers or facilities.

The same behavior-led exposure model applies to current 2026 Iranian-affiliated targeting of internet-connected PLCs; exploitation of PLC, HMI, SCADA, engineering, and remote-access vulnerabilities; abuse of legitimate engineering applications; compromised vendor-support pathways; controller-focused malware; malicious engineering projects; unauthorized ladder-logic replacement; and safety-controller manipulation.

Estimated Economic Exposure

Estimated economic exposure should be modeled through three scenario bands. The most defensible estimate depends on whether activity remains limited to suspicious access, unsuccessful engineering activity, or project collection without confirmed manipulation; progresses into unauthorized controller or HMI/SCADA changes with limited operational uncertainty; or results in treatment-critical manipulation, loss of control, unsafe process deviation, environmental consequences, service interruption, public notification, or prolonged restoration of process-control trust.

Low Impact Scenario

Estimated impact $50K - $250K.

Low impact applies when suspicious engineering, remote-access, controller-management, HMI/SCADA, or project-upload activity is detected early and available evidence confirms no unauthorized project download, online edit, program append, logic change, parameter modification, credential change, network-setting change, firmware activity, operating-mode change, supervisory-control manipulation, process deviation, or service impact.

Where suspicious PLC project upload occurred, low impact applies only when the affected controller and project scope, source and user authorization, destination, transfer path, collection volume, multi-controller activity, external transfer, related credentials, known-good project integrity, and absence of subsequent manipulation can be validated.

Response remains limited to access restriction, credential and session review, controller and project validation, targeted telemetry review, maintenance and work-order reconciliation, short-term monitoring, and executive assurance.

Moderate Impact Scenario

Estimated impact $250K - $2.5M.

Moderate impact applies when confirmed or strongly suspected unauthorized activity affects one or more PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, or process areas and includes project download, online edit, program append, logic modification, parameter manipulation, credential or communications-setting changes, firmware activity, controller mode change, alarm or set-point manipulation, loss of visibility, controller instability, or uncertainty over treatment or wastewater-process integrity.

Response may require emergency engineering support, controller and project forensics, credential rotation, network reconfiguration, firmware and configuration validation, HMI/SCADA review, process testing, laboratory or water-quality sampling, manual-operation preparation, regulatory consultation, vendor or integrator coordination, and extended operational monitoring.

High Impact Scenario

Estimated impact $2M - $15M+.

High impact applies when activity involves confirmed manipulation of treatment-critical or safety-relevant logic, chemical-dosing limits, interlocks, permissives, protection functions, alarms, pressure, flow, level, sequencing, or multiple controllers; operator lockout; loss of view; loss of control; unsafe or threshold-confirmed process deviation; boil-water response; wastewater-release concern; prolonged manual operation; facility shutdown; service interruption; environmental impact; or public-health consequences.

Response may require controller rebuilds, broad project and firmware validation, facility shutdown or reduced operations, emergency water or wastewater measures, laboratory and field testing, outside control-system specialists, broad credential and remote-access remediation, regulatory reporting, legal review, public or customer communications, infrastructure restoration, and board-level oversight.

Annualized Risk Exposure

Estimated annualized risk exposure is $250K - $2.5M+.

Annualized exposure is driven by internet-accessible or broadly reachable PLC and HMI interfaces, default or shared credentials, weak remote-access governance, inadequate network segmentation, broad vendor or integrator access, incomplete controller logging, missing known-good projects, weak engineering-change control, insufficient process-threshold validation, limited independent sensor evidence, controller criticality, multi-site engineering reach, detection delay, and the organization’s ability to prove who changed each controller or supervisory-control object and why.

A realized severe event may exceed $2M - $15M+ when one compromised engineering workstation, remote-access session, vendor pathway, project artifact, controller credential, or centralized management path can reach multiple treatment processes, facilities, sites, or public-service dependencies.

Operational Dependency

Economic exposure increases when PLCs, remote terminal units, HMIs, SCADA systems, engineering workstations, historians, remote-access infrastructure, field devices, laboratory systems, or supporting communications are required for continuous drinking-water treatment, chemical dosing, disinfection, pumping, pressure management, storage, distribution, wastewater collection, aeration, discharge control, safety functions, environmental compliance, or regulatory monitoring.

One compromised engineering source, project, credential, remote-access session, or controller-management pathway can create broad investigation and restoration requirements when it can affect multiple controllers, process areas, facilities, or sites.

Control Trust

Control trust is reduced when engineering or controller-management interfaces are broadly reachable, default or shared credentials remain in use, remote access is weakly governed, vendor access is not attributable, project transfers are not recorded, controller changes cannot be tied to work orders, or known-good projects and configurations are incomplete.

Trust is further reduced when suspicious activity occurs through legitimate engineering applications, valid controller functions, expected protocols, approved remote-access products, familiar vendor accounts, normal programming ports, or authorized-looking maintenance windows.

Restricting an access path, changing a password, terminating a session, restoring a project, resetting a controller, or replacing firmware can reduce future exposure but does not independently prove that prior logic, parameter, HMI/SCADA, credential, network, or process manipulation did not occur.

Visibility Confidence

Visibility confidence depends on industrial NDR telemetry, controller and engineering audit records, project-transfer records, HMI/SCADA logs, controller-state events, engineering-workstation endpoint telemetry, remote-access logs, authentication records, historian data, independent sensors, field-device evidence, laboratory or water-quality results, operator records, maintenance records, work orders, asset relationships, and synchronized timestamps.

Visibility confidence is reduced when the organization lacks controller identity, engineering-source attribution, user or session context, project identifiers, changed-object details, prior and new state, process-area mapping, known-good baselines, independent process evidence, or sufficient retention to reconstruct activity before and after the suspected controller change.

Endpoint execution or network traffic alone cannot confirm that a project or change reached a controller. A controller fault or process anomaly alone cannot confirm that adversary manipulation caused the outcome.

Change-Control Confidence

Change-control confidence decreases when project upload, project download, online edit, program append, logic change, parameter change, credential change, network-setting change, firmware activity, controller reset, project restore, operating-mode change, HMI/SCADA modification, alarm change, set-point change, or manual command is poorly documented, inconsistently approved, weakly logged, or difficult to distinguish from attacker-driven activity.

Confidence is further reduced when shared engineering accounts, emergency maintenance, undocumented vendor support, broad maintenance windows, offline project changes, unmanaged project repositories, incomplete work orders, or missing post-change validation prevent defenders from separating authorized engineering from malicious process-control manipulation.

Engineering and Privileged-Object Dependency

PLC manipulation activity frequently intersects with engineering accounts, controller passwords, HMI/SCADA administrative accounts, remote-access identities, vendor and integrator accounts, local-administrator credentials, project repositories, firmware packages, controller communication settings, trusted engineering workstations, recovery artifacts, and protected process-control objects.

Exposure increases when unauthorized access is followed by controller-password change, account modification, project replacement, firmware activity, communications-setting change, operating-mode change, alarm suppression, HMI display manipulation, or modification of treatment-critical logic.

Downstream Dependency

Downstream exposure increases when the same engineering workstation, remote-access pathway, vendor account, integrator identity, project file, controller credential, management service, or centralized repository can reach multiple controllers, process areas, facilities, sites, or controller vendors.

Cloud-hosted identity, remote-access, repository, historian, backup, vendor-support, engineering-support, or digital-twin systems may increase downstream exposure when they directly support the affected OT environment. Cloud presence alone does not establish PLC manipulation or physical-process impact.

Confirmed access to one controller should not automatically be described as compromise of every controller, facility, site, or process without supporting project, session, asset, network, controller-state, process, or incident-response evidence.

Customer and Regulatory Exposure

Customer, public-health, contractual, environmental, and regulatory exposure increases when PLC or supervisory-control manipulation may affect drinking-water safety, water quality, wastewater discharge, chemical dosing, treatment integrity, service availability, emergency response, public notification, or confidence in utility operations.

Exposure also increases when incomplete telemetry prevents confident scoping of controller changes, project transfers, HMI/SCADA activity, operator loss of control, process deviation, laboratory results, environmental impact, or service interruption.

Notification and reporting decisions must be based on validated local evidence and applicable obligations rather than PLC vendor presence, exposed-device status, default credentials, actor attribution, malware naming, public campaign reporting, or isolated engineering activity alone.

Residual Economic Risk

Access restriction, credential rotation, project restoration, firmware replacement, controller reset, HMI/SCADA recovery, engineering-workstation containment, network blocking, or remote-access remediation can reduce future exposure but do not automatically prove that prior unauthorized process-control activity did not occur.

Removal of one malicious project, controller program, engineering artifact, remote session, user account, malware component, or persistence mechanism does not prove that additional controllers, process areas, facilities, or recovery artifacts were not affected before remediation.

Residual risk should remain elevated until historical controller, engineering, HMI/SCADA, remote-access, endpoint, industrial-network, historian, laboratory, operator, maintenance, process, and incident-response evidence has been assessed and the organization can demonstrate that process-control trust has been restored.

Residual risk is highest where hidden, dormant, delayed, conditionally activated, treatment-critical, or safety-relevant logic may remain present without immediate visible process impact.

CVE / KEV Behavioral Coverage Assessment

The OSINT-to-S25 assessment identified vulnerabilities involving unauthorized HMI and SCADA tag modification, controller configuration-field overwrite, PLC process-loop disruption, malicious engineering-project upload, unauthorized program transfer, arbitrary controller application modification, remote programming writes, administrative PLC control, historical process-data manipulation, controller denial of service, engineering-project-driven web-session compromise, and unauthenticated arbitrary server-file write.

Direct coverage applies where the documented successful-exploitation outcome produces unauthorized engineering or HMI/SCADA access, project or application modification, controller configuration change, parameter or tag modification, controller disruption, HMI or communications loss, process-impact behavior, or another observable outcome already represented by the current S25 behavior model.

Coverage With Adaptation applies where the current behavioral model remains relevant but reliable detection requires product-specific web, application, database, project, endpoint, browser-session, controller-protocol, memory-corruption, availability, historian, or native-event telemetry that is not implemented as a first-class object in the current rules.

Known exploitation and KEV status increase remediation and investigation urgency. They do not independently establish detection coverage or prove compromise in a specific environment.

Detection Engineering Coverage Interpretation

The S25 detection content provides behavioral coverage when observable activity includes:

·        Unauthorized or unexplained engineering, remote-access, HMI/SCADA, or controller-management access.

·        Suspicious PLC project upload involving unauthorized destinations, excessive collection, multiple-controller collection, external transfer, or activity outside approved scope.

·        Unauthorized project download, online edit, program append, logic change, task change, routine change, function-block change, or parameter modification.

·        Controller credential, network-setting, firmware, reset, restore, or operating-mode changes.

·        HMI or SCADA set-point, alarm, tag, display, account, administrative, control-mode, or manual-command changes.

·        Engineering-workstation execution or protected-project activity associated with controller access or project deployment.

·        Controller or HMI/SCADA manipulation followed by communications loss, controller fault, operator lockout, loss of view, loss of control, process deviation, manual-operation transition, or service impact.

·        Authoritatively confirmed manipulation of treatment-critical or safety-relevant logic with unresolved latent consequences.

·        Correlated activity across multiple controllers, process areas, facilities, sites, vendors, projects, users, sources, or remote-access sessions.

The S25 rules intentionally avoid dependence on one PLC vendor, controller model, protocol, engineering application, actor, malware family, CVE, project name, source address, ladder-logic signature, hash, or static indicator.

A single exposed PLC, authentication event, project transfer, engineering-process execution, protocol command, controller fault, HMI change, or process anomaly should not be treated as proof of successful adversary manipulation without the authorization, relationship, state, or impact evidence required by the applicable rule.

Direct Coverage

·        CVE-2026-25752 — Directly covered where FUXA authorization bypass produces observable unauthorized device-tag modification, communications-driver disablement, HMI/SCADA manipulation, connected-device disruption, or physical-process effects represented by S25. The initial WebSocket authorization-bypass request is not claimed as directly detected without FUXA-specific application telemetry.

·        CVE-2023-6448 — Directly covered where use of Unitronics Vision insecure default administrative credentials produces observable unauthorized PLC or HMI administration, project or logic modification, parameter change, communications change, HMI manipulation, controller-state change, or process-impact behavior represented by S25. The use of the default password alone is not claimed as directly detected without authentication evidence.

·        CVE-2023-46143 — Directly covered where unauthenticated code download to Phoenix Contact classic-line PLCs modifies some or all controller applications and produces observable program, project, controller-state, latent-risk, or process-impact behavior represented by S25.

·        CVE-2022-30243 — Directly covered where unauthenticated programming writes to Honeywell Alerton controllers store or execute unauthorized code, change or stop controller programs, alter controller function, or produce subsequent operational-impact behavior represented by S25.

Direct Coverage — Tooling / Exploitation Tradecraft

·        Ongoing 2026 Iranian-affiliated exploitation of internet-connected PLCs — Directly covered at the behavioral level where activity produces observable project manipulation, configuration wiping, sensor or process-data tampering, HMI disruption, controller disruption, operational impact, or multi-facility expansion represented by S25.

·        Unitronics PLC manipulation tradecraft documented in the 2023–2024 CyberAv3ngers activity — Directly covered at the behavioral level where unauthorized administrative access is followed by ladder-logic replacement, upload restrictions, communications-setting changes, HMI defacement, loss of view, operator impact, controller disruption, or multi-device activity represented by S25.

Coverage With Adaptation

·        CVE-2026-11826 — Covered with adaptation where OpenPLC v3 exploitation produces adjacent configuration-field overwrite, runtime crash, denial of service of the PLC process-control loop, controller disruption, or subsequent process impact. Adaptation is required for OpenPLC web requests, Modbus configuration parsing, memory-corruption indicators, configuration-state evidence, runtime-crash telemetry, and controller-process relationships.

·        CVE-2026-14480 — Covered with adaptation where the OpenPLC v3 program-upload workflow is abused to write arbitrary files, modify protected engineering artifacts, introduce executable code, alter controller-supporting files, or initiate follow-on controller activity. Adaptation is required for OpenPLC web, database, upload, filesystem, compilation, and runtime-process telemetry.

·        CVE-2026-9307 — Covered with adaptation where exposed Rockwell CompactLogix CIP connection information is used to construct malicious traffic that causes controller denial of service, communications loss, controller fault, or operational impact. Adaptation is required for Rockwell diagnostic-page access, CIP connection identifiers, malicious-packet behavior, controller model, and disruption evidence.

·        CVE-2026-25786 — Covered with adaptation where a malicious Siemens TIA project or PLC or station name produces unauthorized project activity, controller-communications-setting interaction, web-session script execution, administrative misuse, or follow-on controller changes. Adaptation is required for Siemens TIA project, web-interface, station-name, browser-session, user-interaction, and downstream activity telemetry.

·        CVE-2026-25895 — Covered with adaptation where unauthenticated FUXA path traversal is abused to write arbitrary files outside the intended server path, including files that may affect application integrity or support follow-on HMI/SCADA, engineering, controller, or process-control activity. Adaptation is required for FUXA upload-API, destination-path, authentication-state, filesystem, file-integrity, service-account, runtime-process, and downstream HMI/SCADA-to-process telemetry.

·        CVE-2026-25751 — Covered with adaptation where FUXA administrative database credentials are exposed and then used to read, modify, delete, or corrupt historical process data or disrupt historian availability. Adaptation is required for FUXA, InfluxDB, historian-object, database-authentication, data-integrity, and HMI-to-process correlation.

Coverage With Adaptation — Malware / Tooling / Tradecraft

·        INCONTROLLER / PIPEDREAM — Covered with adaptation where controller-focused malware performs PLC discovery, project upload, program download, logic modification, parameter manipulation, operating-mode change, protocol manipulation, routing or proxy activity, memory wiping, or controller disruption. Product-specific adaptation is required for Schneider Electric, Omron, CODESYS, OPC UA, Modbus, native engineering fields, controller relationships, and process context.

·        Stuxnet — Covered with adaptation where infected engineering projects, unauthorized program transfer, PLC-code modification, controller tasking, hidden logic, or process manipulation intersects with the current controller-manipulation model. Stuxnet-specific project infection, propagation, rootkit, driver, and Siemens Step 7 telemetry requires separate implementation.

·        Triton / TRISIS / HatMan — Covered with adaptation where safety-controller access produces program upload, program download, controller-tasking changes, operating-mode changes, memory or firmware manipulation, safety-function interference, or related process risk. Triconex-specific protocol, firmware, controller-tasking, and safety-process relationships require separate implementation.

·        PLC-Blaster — Covered with adaptation where PLC-resident or PLC-propagating code changes controller operating mode, transfers unauthorized code, modifies controller tasking, discovers peer controllers, expands across multiple PLCs, or causes controller denial of service. Siemens S7-specific protocol, propagation, controller-resident execution, and cycle-time telemetry are environment-specific adaptation requirements when those behaviors must be identified directly. These product-specific adaptation requirements do not represent an unfinished S25 detection object; observable unauthorized controller access, engineering or configuration change, operating-mode change, controller disruption, process impact, and multi-controller expansion remain governed by the existing behavior-led S25 model.

Coverage With Adaptation — APT / Actor / Campaign Activity

·        Iranian-affiliated 2026 PLC targeting — Covered with adaptation at the actor and campaign level. The associated project manipulation, configuration wiping, sensor tampering, HMI disruption, controller disruption, and operational-impact behaviors may be directly covered, but actor attribution, infrastructure, access mechanism, target selection, and campaign linkage require intelligence enrichment.

·        CyberAv3ngers — Covered with adaptation at the actor and campaign level. The associated Unitronics PLC manipulation behaviors may be directly covered, but attribution, infrastructure, target selection, defacement context, and campaign linkage require supporting intelligence.

·        CHERNOVITE-associated INCONTROLLER activity — Covered with adaptation where activity produces controller discovery, project upload, program download, operating-mode change, parameter modification, memory wiping, controller manipulation, protocol abuse, or disruption represented by S25. Actor attribution and malware-specific infrastructure require separate evidence.

·        TEMP.Veles-associated Triton activity — Covered with adaptation where activity produces safety-controller program transfer, controller-tasking changes, operating-mode changes, memory or firmware manipulation, or safety-function interference. Actor attribution and Triconex-specific implementation require separate evidence.

·        Poland private-APN / CHP / PLC destructive-operations incident — Covered with adaptation as a campaign procedure set where private-APN and cellular connectivity are used for lateral reachability, an industrial controller or gateway is used as an intermediate access path into the OT environment, PLC and SCADA assets are accessed, controller operating state or access protection is manipulated, industrial-device configurations are altered, and physical-process disruption follows. The existing S25 behavior model covers observable unauthorized controller access, operating-mode change, operator lockout, controller disruption, process impact, and multi-controller or cross-environment expansion. Adaptation is required for private-APN communication context, cellular-router and gateway telemetry, tunneling evidence, WAGO and Siemens native events, industrial-device configuration telemetry, asset relationships, and campaign-specific incident linkage.

Non-Coverage Conditions

·        PLC vendor, controller family, HMI product, engineering application, CVE, vulnerable-version status, exposed-device status, default credential, protocol, project file, malware family, actor, campaign, hash, source address, ladder-logic pattern, or proof-of-concept presence without aligned local behavior.

·        Initial exploit requests that produce no retained application, controller, engineering, HMI/SCADA, endpoint, network, project, process, operator, historian, or maintenance telemetry.

·        Legitimate engineering or controller-management activity tied to an approved user, source, controller scope, project, work order, maintenance window, expected change, and validated post-change state.

·        Project transfer without sufficient source, user, session, controller, project, destination, authorization, timestamp, scope, and follow-on activity context.

·        Controller changes that are unavailable, unlogged, encrypted, unsupported by the monitoring platform, or indistinguishable from approved maintenance.

·        Endpoint engineering-tool execution without evidence that a controller project, protected artifact, controller, HMI/SCADA object, or process was accessed or changed.

·        Controller fault, communications loss, operator lockout, process deviation, laboratory result, water-quality deviation, manual-operation transition, or service impact inferred to be malicious solely from one isolated event.

·        Malware-family, actor, or campaign attribution inferred solely from one exposed PLC, default credential, project file, HMI message, network connection, controller event, or static indicator.

·        Cloud-only identity, repository, workload, storage, network, or control-plane activity that cannot be tied directly to the OT engineering and controller-manipulation chain.

·        Universal detection of PLC exploitation, engineering-application exploitation, web-interface exploitation, protocol abuse, memory corruption, controller firmware compromise, project-file infection, safety-system compromise, malware execution, physical-process impact, environmental impact, or public-health consequences.

·        Environments where required controller inventories, engineering-source mappings, project baselines, asset relationships, controller audit logs, HMI/SCADA logs, endpoint telemetry, process evidence, maintenance records, timestamp alignment, retention, or approved-scope evidence is unavailable.

Current Coverage Count

Directly Covered CVEs

4

CVEs Covered With Adaptation

6

Known Exploited Vulnerabilities Represented in This Coverage Set

1

Directly Covered CVE Clusters

4

Directly Covered Named Tooling / Exploitation Tradecraft Patterns

2

Named Malware / Tooling / Tradecraft Patterns Covered With Adaptation

4

APT / Actor / Campaign Activity Names Directly Covered

0

APT / Actor / Campaign Activity Names Covered With Adaptation

5

Directly Covered Core Behavior Classes

8

The eight directly covered core behavior classes are unauthorized engineering access, suspicious PLC project collection, controller-program or parameter manipulation, controller credential or communications manipulation, firmware or operating-mode activity, HMI/SCADA manipulation, controller or process-impact correlation, and multi-controller or cross-facility expansion.

Not Currently Counted as Separately Covered

The ongoing 2026 Iranian-affiliated PLC exploitation pattern and the Iranian-affiliated actor or campaign entry describe overlapping activity. The observable exploitation behavior is counted under Direct Coverage — Tooling / Exploitation Tradecraft, while the actor and campaign identity is counted under Coverage With Adaptation.

The Unitronics PLC manipulation pattern and CyberAv3ngers describe overlapping behavior and attribution. The observable Unitronics manipulation pattern is counted under Direct Coverage — Tooling / Exploitation Tradecraft, while CyberAv3ngers is counted under Coverage With Adaptation — APT / Actor / Campaign Activity.

INCONTROLLER and PIPEDREAM are associated names for the same controller-focused malware framework and are counted as one adapted malware or tooling entry.

Triton, TRISIS, and HatMan are associated names for the same safety-controller attack framework and are counted as one adapted malware or tooling entry.

CVE-2026-25752, CVE-2026-25895, and CVE-2026-25751 affect the same FUXA release family but represent materially different device-tag manipulation, unauthenticated arbitrary-file-write, and historical-data credential-exposure paths and are counted separately.

The Poland private-APN / CHP / PLC destructive-operations incident is counted once as a Coverage With Adaptation campaign procedure set. No CVE is associated with this amendment, and it does not change the Direct Coverage CVE, Coverage With Adaptation CVE, KEV, CVE-cluster, direct tooling or exploitation-tradecraft, adapted malware or tooling, or directly covered core-behavior-class counts.

No CVE is counted solely because it can provide initial access to an OT environment. Each listed CVE has a documented outcome that aligns with an implemented S25 behavior or a clearly defined adapted behavior.

Coverage Qualification

The direct-coverage register contains vulnerabilities and exploitation patterns whose documented successful-exploitation outcomes align with the report’s implemented unauthorized-access, project-transfer, controller-change, HMI/SCADA-manipulation, controller-state, process-impact, critical-latent-risk, and expansion model.

Direct Coverage does not mean S25 identifies every exploit request, payload, vulnerable version, web path, packet structure, password value, memory-corruption primitive, or product-specific mechanism. It means the documented successful-exploitation outcome can produce observable behavior already represented by the current S25 detection model.

Coverage With Adaptation applies where the current behavioral model remains relevant but reliable detection requires product-specific web, application, database, protocol, project, engineering, controller, historian, browser-session, availability, memory-corruption, or native-event telemetry that is not implemented as a first-class object in the current rules.

Product-specific adaptation requirements identify telemetry needed to observe vendor-native, exploit-stage, malware-specific, or procedure-specific behavior directly. They do not by themselves indicate that S25 requires an additional first-class rule when the resulting controller-manipulation behavior is already represented by the existing behavior model.

CVE-2026-25895 is Coverage With Adaptation because unauthenticated FUXA path traversal permits arbitrary file writes to arbitrary server-filesystem locations, while reliable detection of the exploit-stage behavior requires FUXA-specific upload-API, destination-path, authentication-state, filesystem, file-integrity, service-account, and runtime-process telemetry. Existing S25 behavior remains relevant where the resulting compromise progresses into observable protected-artifact, HMI/SCADA, engineering, controller, or process-control activity. The report does not claim that S25 directly identifies the initial traversal request or every arbitrary server-file write.

CVE-2023-6448 is the one CISA Known Exploited Vulnerability represented in the current register. Its KEV status increases urgency, but Direct Coverage is based on observable unauthorized PLC or HMI administrative activity and its follow-on behavior, not on KEV status or default-password presence alone.

The direct 2026 Iranian-affiliated and Unitronics exploitation-tradecraft entries describe behavior coverage. The corresponding Iranian-affiliated and CyberAv3ngers actor or campaign entries remain Coverage With Adaptation because actor identity and campaign linkage require evidence beyond the behavioral detections.

The Poland private-APN / CHP / PLC destructive-operations incident is Coverage With Adaptation because its observable controller access, operating-mode manipulation, access-protection changes, controller disruption, physical-process impact, and expansion through connected OT infrastructure align with the existing behavior model, while reliable detection and reconstruction of the complete procedure set require private-APN, cellular-router, gateway, tunneling, controller-native, industrial-device configuration, asset-relationship, and incident-context telemetry. No CVE is associated with this amendment.

The report does not claim universal PLC exploitation detection, universal engineering-access detection, universal protocol-abuse detection, universal project-file detection, universal firmware-compromise detection, universal safety-controller detection, universal malware detection, universal actor or campaign detection, or standalone physical-process, environmental, public-health, or customer-impact attribution.

Detection confidence depends on industrial NDR visibility, controller and engineering audit records, HMI/SCADA telemetry, engineering-workstation endpoint coverage, project and configuration baselines, remote-access records, controller-to-process relationships, historian and independent sensor evidence, process thresholds, operator and laboratory records, maintenance and work-order context, timestamp alignment, retention, local query validation, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when unauthorized engineering or controller activity creates uncertainty over whether PLC logic, process parameters, HMI/SCADA controls, alarms, operator visibility, water quality, wastewater control, treatment safety, and service continuity remain reliable.

The strategic risk is not one PLC vendor, default password, internet-facing device, project file, malware family, actor, or vulnerability. It is the possibility that an adversary can convert engineering or controller authority into physical-process manipulation while the organization lacks sufficient evidence to prove what changed, which controllers and processes were affected, whether latent risk remains, and whether safe operational trust has been restored.

S40 — References

Government and Water-Sector Guidance

U.S. Environmental Protection Agency — EPA, FBI, CISA, and NSA Issue Joint Cybersecurity Advisory to Water Systems Regarding Iranian-Affiliated Cyber Attacks, April 7, 2026.

hxxps://www[.]epa[.]gov/newsreleases/epa-fbi-cisa-nsa-issue-joint-cybersecurity-advisory-water-system-regarding-iranian

U.S. Environmental Protection Agency — Iranian APT Actors Targeting PLCs: Impacts and Mitigations for Water and Wastewater Systems, May 14, 2026.

hxxps://www[.]epa[.]gov/cyberwater/iranian-apt-actors-targeting-plcs-impacts-and-mitigations-water-and-wastewater-systems

U.S. Environmental Protection Agency — EPA Cybersecurity for the Water Sector.

hxxps://www[.]epa[.]gov/cyberwater

National Institute of Standards and Technology — NIST Special Publication 800-82 Revision 3, Guide to Operational Technology Security, September 2023.

hxxps://csrc[.]nist[.]gov/pubs/sp/800/82/r3/final

Vulnerability Records

NVD — CVE-2026-25752 — FUXA authorization bypass enabling unauthorized device-tag modification and communications-driver disablement.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25752

NVD — CVE-2023-6448 — Unitronics Vision PLC and HMI insecure default administrative password enabling remote commands and administrative control.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-6448

NVD — CVE-2023-46143 — Phoenix Contact classic-line PLC unauthenticated modification of controller applications.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-46143

NVD — CVE-2022-30243 — Honeywell Alerton unauthenticated programming writes enabling code storage, controller-program change, or controller-program stop.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2022-30243

NVD — CVE-2026-11826 — OpenPLC v3 heap-based buffer overflow causing adjacent configuration-field overwrite, runtime crash, and denial of service of the PLC process-control loop.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-11826

NVD — CVE-2026-14480 — OpenPLC v3 authenticated arbitrary file write through the legacy program-upload workflow with potential native-code execution.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-14480

NVD — CVE-2026-9307 — Rockwell CompactLogix 5370 diagnostic-page information disclosure supporting malicious packets and controller denial of service.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-9307

NVD — CVE-2026-25786 — Siemens PLC or station-name script injection through a downloaded TIA project.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25786

NVD — CVE-2026-25895 — FUXA unauthenticated path traversal allowing arbitrary files to be written to arbitrary locations on the server filesystem.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25895

NVD — CVE-2026-25751 — FUXA administrative database-credential disclosure enabling historical process-data access, modification, deletion, corruption, or denial of service.

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25751

Federal / KEV Qualification

CISA — Known Exploited Vulnerabilities Catalog.

hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Direct PLC Exploitation and Campaign Activity

CISA, FBI, NSA, EPA, INCD, CCCS, and NCSC — IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including U.S. Water and Wastewater Systems Facilities, AA23-335A, originally published December 1, 2023 and revised December 18, 2024.

hxxps://www[.]cisa[.]gov/news-events/cybersecurity-advisories/aa23-335a

Campaign Procedure-Set — Coverage With Adaptation

CERT Polska / NASK — Uzupełnienie raportu z incydentu w sektorze energii w grudniu 2025 roku, August 8, 2026.

hxxps://www[.]gov[.]pl/attachment/cf8316d8-db3c-40c5-9f24-0a68e3fdf7dc

Threat Technique Framework

MITRE ATT&CK — Groups Catalog.

hxxps://attack[.]mitre[.]org/groups/

MITRE ATT&CK — Software Catalog.

hxxps://attack[.]mitre[.]org/software/

MITRE ATT&CK for ICS — Techniques Catalog.

hxxps://attack[.]mitre[.]org/techniques/ics/

Detection Platform Documentation

SentinelOne Documentation.

hxxps://docs[.]sentinelone[.]com/

Splunk Search Reference.

hxxps://docs[.]splunk[.]com/Documentation/Splunk/latest/SearchReference/WhatsInThisManual

Elastic Security Detection Rules Documentation.

hxxps://www[.]elastic[.]co/guide/en/security/current/rules-ui-management[.]html

IBM QRadar Documentation.

hxxps://www[.]ibm[.]com/docs/en/qradar-common

Sigma Rule Specification.

hxxps://sigmahq[.]io/docs/basics/rules[.]html

Reference Usage Note

This reference set supports the report’s focus on unauthorized PLC and engineering access, suspicious project collection, project and program modification, controller configuration and parameter changes, HMI/SCADA manipulation, operating-mode activity, controller disruption, process-impact correlation, critical latent process risk, and multi-controller expansion.

The April 7 and May 14, 2026 EPA sources support the current-year threat context and the direct behavioral interpretation of ongoing Iranian-affiliated exploitation of internet-connected PLCs affecting U.S. critical infrastructure, including water and wastewater systems. The sources support urgency and behavioral alignment but do not independently establish actor attribution or compromise in any specific environment.

The NVD references support the four Direct Coverage CVE entries and six Coverage With Adaptation CVE entries. Direct Coverage is based on documented successful-exploitation outcomes that align with implemented S25 behaviors. Coverage With Adaptation is used where product-specific application, web, database, memory-corruption, project, protocol, browser-session, historian, availability, filesystem, upload-workflow, or runtime-process telemetry is required.

The CVE-2026-25895 NVD record supports the FUXA Coverage With Adaptation entry. The vulnerability permits an unauthenticated remote attacker to exploit path traversal to write arbitrary files to arbitrary locations on the FUXA server filesystem in affected versions through 1.2.9, with version 1.2.10 containing the fix. Coverage With Adaptation is used because reliable exploit-stage detection requires FUXA-specific upload-API, destination-path, authentication-state, filesystem, file-integrity, service-account, and runtime-process telemetry, while the current S25 behavioral model remains relevant where compromise progresses into protected-artifact, HMI/SCADA, engineering, controller, or process-control activity.

The CISA KEV Catalog supports the KEV classification of CVE-2023-6448. The main catalog URL is retained to avoid reference bloat. KEV status is treated as an urgency and remediation-prioritization signal rather than detection coverage by itself.

The CISA AA23-335A reference supports the Unitronics PLC manipulation behavior and CyberAv3ngers campaign context. The observable manipulation pattern is treated as Direct Coverage — Tooling / Exploitation Tradecraft. CyberAv3ngers identity and campaign linkage remain Coverage With Adaptation.

The CERT Polska / NASK follow-up analysis supports the Poland private-APN / CHP / PLC destructive-operations campaign procedure-set entry. The source documents private-APN lateral reachability, industrial gateway or controller pivoting, tunneled OT access, PLC and SCADA interaction, controller operating-state and access-protection manipulation, destructive industrial-device configuration activity, and physical-process disruption. The incident is treated as Coverage With Adaptation because the observable controller-manipulation and process-impact behaviors align with the current S25 model while complete procedure-set detection requires environment-specific private-APN, cellular, gateway, tunneling, controller-native, industrial-device configuration, and asset-relationship telemetry. No CVE is associated with this amendment.

The MITRE ATT&CK catalog references support the named CyberAv3ngers, INCONTROLLER / PIPEDREAM, Stuxnet, Triton / TRISIS / HatMan, PLC-Blaster, CHERNOVITE-associated, and TEMP.Veles-associated coverage entries and ATT&CK-aligned behavioral interpretation. Catalog-level references are retained rather than individual software and group URLs to avoid reference bloat.

The EPA and NIST references support the water-sector, OT-risk, control-trust, operational-dependency, incident-response, recovery, segmentation, access-control, asset-management, and process-safety framing.

The detection-platform references support the S25 implementation modes and the platforms containing deployable rules. They do not establish that any customer environment currently collects the required fields or that the rules can be deployed without local schema mapping, enrichment, baselining, suppression, performance validation, and SOC testing.

CVE presence, vulnerable-version status, KEV status, actor attribution, malware attribution, public campaign reporting, internet exposure, default credentials, and named-product presence increase urgency but do not independently prove successful compromise, local process impact, or detection coverage.