Industrial Stateful Detection

Industrial risk often exists in a sequence, not in one packet. A command can be valid in isolation but unsafe because it arrived from the wrong session, skipped a required selection, occurred during recovery, contradicted process feedback, or repeated after its authorization was consumed.

L2Proxy state machines allow policy to retain bounded context between frames and make the final decision at the point where the operational meaning is known.

Industrial problems addressed

Use case	State retained	Operational value
Command/response correlation	transaction identity, target, expected result	Distinguish completion, failure, mismatch, and replay
Command-to-status verification	command, expected feedback, deadline	Detect a command that did not produce the expected process indication
Maintenance authorization	user/session/device/operation, expiry	Restrict sensitive activity to a scoped and time-limited authorization
Active/standby controller	current owner and failover phase	Detect command activity from a standby or split-brain source
Restart recovery	restart, time sync, integrity scan, operational state	Prevent normal control before recovery prerequisites complete
Safety trip/reset	trip, acknowledge, cause clear, reset permission	Detect or reject reset attempts that skip required safety workflow
Process interlock	prerequisite observation and freshness	Enforce a network-visible prerequisite before a critical operation
Unauthorized state change	expected feedback window	Identify a process indication with no observed network command
File/configuration lifecycle	owner, handle, block, expected restart	Detect hijack, missing steps, duplicate blocks, and incomplete change workflows
Burst/chattering	bounded counter and time window	Identify excessive control, restart, write, or alarm-toggle activity

The basic state pattern

ABSENT ──valid start──▶ PENDING ──matching response──▶ READY
   ▲                      │                              │
   │                      └──failure/timeout──▶ INVALID │
   │                                                     │
   └──────────── cleanup ◀── atomic one-time consume ────┘

Figure — Stateful detection follows industrial state patterns such as select, operate, response, and timeout.

A secure policy does not use “check, then set” for a one-time decision. It atomically transitions from the exact expected state. Concurrent or replayed packets then have only one winner.

Generic state primitives

Primitive	Intended use
set_state	Record an observation or begin a phase
delete_state	Cancel, invalidate, or complete a lifecycle
transition_state	Atomic compare-and-transition, including creation from @absent
increment_state	Atomic bounded event counting
TTL	Expire stale authorization and correlation context
Optional scheduler	Emit a timeout event even if no later packet arrives

The engine is protocol-neutral. Protocol helpers provide identities and values; YAML defines the process sequence and enforcement policy.

Example: one-time operation consumption

  - name: consume-ready-operation
    order: 40
    condition: 'operation_event && operation_identity != ""'
    action: transition_state
    state_key_expr: '"protocol:machine:" + session_identity'
    state_from_expr: '"ready|" + operation_identity'
    state_value: consumed
    state_ttl: 1

  - name: accept-consumed-operation
    order: 50
    condition: >
      operation_event &&
      state_action_rule == "consume-ready-operation" &&
      state_action_applied
    action: accept
    log: true

  - name: drop-missing-mismatched-or-replayed-operation
    order: 60
    condition: 'operation_event'
    action: drop
    log: true

Timeout is part of the process model

Every temporary state should answer:

• How long is this observation valid?
• Does a new observation replace the deadline?
• What happens when the deadline expires?
• Is timeout visible only on the next packet, or must an independent event be emitted?
• Does timeout produce an alert, invalidate authorization, or change forwarding behavior?

By default, expiration is lazy. The optional scheduler emits state_timeout without waiting for another packet, but it does not evaluate a new rule by itself.

Customer-specific design inputs

Before deployment, the customer and integrator define:

• asset and device scope;
• initiator, session, or engineering identity;
• protocol target and command identity;
• valid states, events, and guards;
• TTL and timeout consequence;
• expected retry and duplicate behavior;
• maintenance and failover procedures;
• monitoring versus blocking branches;
• evidence required in the audit event.

Detection boundaries

A network state machine represents observed traffic. It can diverge from the physical process when packets are lost, only one direction is visible, capture begins mid-session, an operator acts locally, traffic is encrypted, or parsing is incomplete. Process safety must remain in the control and safety systems. L2Proxy adds network-visible policy and evidence; it does not replace physical permissives or safety logic.

Current customer-ready focus

DNP3 has the most complete tested stateful catalog. S7comm stateful helpers and policies are intentionally not represented as ready. See DNP3 State Machines and the transparent Capability Status.