Security teams detect monitored process state changes by tracking process values, state transitions, and sensor updates for patterns that diverge from normal operations. Unexpected spikes, flatlines, or missing updates can signal tampering or failure. Correlate process telemetry with network and operator activity, and alert when state changes occur without matching control actions.
What a process state change detector is actually watching
Process state change detection is less about raw uptime and more about whether the process still behaves like the process you expect. The detector should watch value trajectories, state transitions, and sensor freshness together, so the team can distinguish a legitimate operational step from a silent fault, spoofed input, or tampering event.
The useful unit of analysis is not a single reading. A healthy process usually shows small, explainable movement, while a compromised or degraded process often shows abrupt jumps, stuck values, repeating values, or a sequence that stops matching its normal operating rhythm.
For teams managing industrial environments, this is the same practical problem described in the OT Security Guide: you need to compare process telemetry with the control environment around it, not treat one sensor as proof that the system is stable.
How to tell normal drift from a meaningful change
A useful detector compares present behaviour against a baseline that reflects expected operating modes, not a single “normal” line. Normal change may be gradual, cyclical, or event-driven, while suspicious change often arrives as a flatline, an impossible step change, an out-of-sequence transition, or an update that arrives too late to be trusted.
The simplest heuristic is to ask whether the process can still be reconciled with recent commands, schedules, and physical context. If a sensor changes but no corresponding control action, maintenance activity, or operator event explains it, the change deserves review even when the absolute value still appears plausible.
In digital infrastructure, the same logic applies to stateful artefacts and configuration drift. The Infrastructure as Code Security Guide reflects the same detection principle, which is to compare declared state and observed state so silent divergence does not hide in plain sight.
Correlating telemetry, network activity, and operator actions
Single-signal monitoring creates blind spots. Security teams should correlate process values with network events, authentication events, operator actions, and device health so they can see whether a state change was caused by a real operational change or by an external interference path.
This correlation matters most when process telemetry changes without a corresponding control-plane event, when an operator action occurs but the expected sensor state does not follow, or when the sensor update pattern itself changes. Those mismatches are often the earliest sign that the environment is being manipulated, suppressed, or partially failed.
Effective detection usually requires combining process-aware alerting with an adversary model. The MITRE ATT&CK Enterprise Matrix is useful here because it helps teams map suspicious state changes to credential access, lateral movement, and defence evasion patterns rather than treating them as isolated anomalies.
Risk and Threat Considerations
Monitored process state changes are risky when defenders trust the value stream more than the control path. Attackers and failure conditions both exploit that trust gap: one can spoof, freeze, delay, or selectively alter updates while the underlying process continues to move, and the other can create the same appearance through sensor failure or lost telemetry.
Failure mechanism: State changes become dangerous when monitoring loses freshness, sequence integrity, or source authenticity. A flatline, duplicate sample, or missing transition can mask manipulation, while a plausible-looking value can still be wrong if it no longer matches operator actions or surrounding process behaviour.
Impact: Teams can miss unsafe process movement, waste time on false stability, or respond too late to tampering, equipment fault, or control drift. In high-consequence environments, that can turn a monitoring gap into a safety, availability, or production incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1562 — Impair Defenses | Process telemetry tampering often hides by weakening detection visibility. |
| Recommendation — Map suspicious state anomalies to defense-evasion patterns and hunt for telemetry suppression. | ||
| NIST CSF 2.0 | DE.CM-01 — Anomalies and Events are Monitored | The question is about detecting abnormal process changes through monitoring. |
| DE.AE-02 — Anomalies are Analyzed | Teams must interpret abnormal state changes against expected operational context. | |
| Recommendation — Monitor process telemetry for anomalies, stale updates, and unexpected transitions. Analyze anomalous process changes against baseline behaviour and control activity. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Correlation of process, network, and operator events depends on reviewed telemetry. |
| SI-4 — System Monitoring | Continuous monitoring is central to spotting tampered or failed process updates. | |
| Recommendation — Review correlated logs and process records to identify unexplained state changes. Implement continuous monitoring for process values, state transitions, and sensor freshness. | ||
Practitioner Guidance
What to verify: Confirm that alerts are driven by change logic, not just threshold logic. A good detector should be able to flag abnormal persistence, sudden discontinuity, and stale data separately, because those failure modes tell you different things about the process and the monitoring path.
Decision rule: If a state change is not explainable by a recent control action, maintenance event, or expected operating mode, treat it as an investigation trigger even when the value remains inside an acceptable range. If the process is safety- or availability-critical, investigate telemetry integrity before assuming the plant or system is stable.
Practitioner takeaway: The best process-state detection logic does not just ask “did the value move?” It asks whether the movement is timely, explainable, and aligned with the control reality that should have produced it.
Related resources from NHI Mgmt Group
- How should security teams govern automation that changes access or identity state?
- How do security teams detect obfuscated malware that changes strings to evade scanners?
- How should security teams detect risky privilege changes in Okta before they are abused?
- How do security teams detect when AD password changes and remote access controls are being abused?