DNP3 Stateful Protection Catalog¶
DNP3 operations are conversational. A secure interpretation can require link addresses, application direction, function code, application sequence, object group/variation, point index, command attributes, response status, IIN indicators, timing, and prior events. L2Proxy converts these facts into canonical identities that customer policy can correlate without hard-coding the policy into the parser or StateStore.
Production The use cases below have executable YAML samples and automated load/behavior tests. Point assignments, asset mappings, identities, timing, severity, and final verdict remain customer-specific.
1. Select-Before-Operate validation¶
Industrial concern: An Operate should be accepted only after a matching Select was requested and positively confirmed for the same master, outstation, and complete control target set.
Figure — DNP3 Select-Before-Operate sequence validation and enforcement.
Policy behavior:
Select request → pending
Matching successful Select response → selected
Matching Operate → atomic one-time consume → accept
Missing / expired / mismatched / replayed Operate → drop
The control fingerprint includes canonical CROB or Analog Output G41 targets. Multi-object ordering does not change the identity; incomplete parsing does not produce a usable hash.
Operational value:
- blocks Operate without a validated Select;
- detects mismatched point, opcode, timing, value, or target set;
- prevents replay after one successful consumption;
- gives concurrent Operates one atomic winner;
- supports a clear Direct Operate policy.
Full policy: Complete DNP3 SBO Policy
2. Command-to-status verification¶
Industrial concern: A command was transmitted, but the expected indication did not arrive, arrived with the opposite state, or arrived after the permitted response window.
Policy behavior: Map a control point to its expected Binary Input feedback and retain
an awaiting_status state. Matching feedback verifies the operation; opposite, missing,
conflicting, or unsolicited feedback produces a distinct outcome.
Operational value:
- highlights failed or ineffective control;
- distinguishes uncommanded feedback from expected process response;
- creates an auditable command/indication chain;
- supports monitor-first deployment where network loss or local operation is possible.
3. Device restart recovery¶
Industrial concern: A restarted outstation may require time synchronization and an integrity scan before normal controls should resume.
Policy behavior:
Repeated restart, NeedTime, final-fragment completion, recovery timeout, and control during recovery are handled as explicit phases.
Operational value:
- provides evidence of incomplete recovery;
- can log or block controls during an unsafe recovery phase;
- identifies restart outside an approved maintenance context;
- prevents a single response fragment from being mistaken for a completed scan.
4. Maintenance-authorized control¶
Industrial concern: Sensitive operations should be tied to a known engineering user, L2Proxy Connect session, access domain, target device, operation, and time window.
Policy behavior: A designated authorization event creates a scoped, expiring permission. The intended operation atomically consumes it. A different user, session, device, or replay does not satisfy the transition.
Operational value:
- connects network control to maintenance identity;
- implements one-time authorization without a global permit flag;
- records who, where, what, and when;
- makes absence of identity metadata an explicit policy decision.
5. Active/standby master enforcement¶
Industrial concern: A standby master begins issuing controls, both masters appear active, or a former master resumes control after failover.
Policy behavior: Maintain the active master per outstation, require an explicit failover transition, and detect split-brain or control from the non-active source.
Operational value:
- identifies unexpected control ownership;
- supports controlled failover procedures;
- reduces ambiguity during redundant SCADA operation;
- retains an audit trail of ownership changes.
6. Session identity binding¶
Industrial concern: A multi-step control begins under one network or L2Proxy Connect identity and completes under another.
Policy behavior: Bind control context to session, user, hub, network endpoints, device, and operation. Detect drift before the final operation is permitted.
Operational value:
- detects session substitution during a sensitive sequence;
- ties protocol semantics to access identity;
- separates device-address trust from operator/session trust.
7. Safety trip and reset workflow¶
Industrial concern: A reset is attempted without an observed trip, before acknowledgement, before the cause clears, or without the approved operator/maintenance context.
Policy behavior:
Operational value:
- exposes skipped phases in a safety-related workflow;
- supports monitored or enforced reset policy;
- combines process indication, operator identity, and maintenance context;
- creates a chronological reset evidence chain.
Warning
This network-visible policy complements but never replaces PLC logic, relay logic, safety instrumented functions, or approved operating procedures.
8. Unauthorized state change¶
Industrial concern: A binary indication changes without a corresponding command observed within the expected time window.
Policy behavior: A command opens a bounded expected-feedback window. Matching change consumes it; a change with no valid expectation is logged as an investigation candidate.
Operational value:
- detects local operation, alternate control paths, missing command visibility, or possible compromise;
- highlights command/feedback inconsistency;
- supports medium-severity monitoring before any enforcement decision.
Limitations include packet loss, asymmetric visibility, startup mid-sequence, and legitimate local operation. View the complete policy.
9. Process interlock observation¶
Industrial concern: A pump start is requested without a fresh observation that the required valve is open.
Policy behavior: Retain the prerequisite indication with a TTL and atomically consume it for the protected operation. Missing, stale, or already consumed prerequisites take the violation branch.
Operational value:
- expresses a customer process prerequisite at the network boundary;
- detects stale assumptions and repeated commands;
- can begin in monitor mode and move to enforcement after process validation.
10. File-transfer lifecycle¶
Industrial concern: A file transfer uses an unexpected filename, size, owner, handle, block number, final-block marker, or close sequence.
Policy behavior: Track open request/response, assigned handle, owner identity, exact block progression, last block, close request, and successful completion. Atomic counters detect duplicate, skipped, or out-of-order blocks.
Operational value:
- provides a complete transfer audit trail;
- detects session hijack and sequence violation;
- restricts configuration files and size to customer-approved values;
- associates the transfer with maintenance authorization.
11. Configuration change and restart verification¶
Industrial concern: Configuration changes should be followed by the expected restart and health verification; an unexplained restart should be distinguished from an approved change.
Policy behavior:
Operational value:
- detects change without restart and restart without observed change;
- links engineering activity to post-change health evidence;
- supports maintenance-window auditing.
12. Rate, burst, and write-storm detection¶
Industrial concern: Excessive Operate, restart, or write activity can indicate automation failure, operator error, scanning, or malicious use.
Policy behavior: Use atomic per-device counters with bounded windows and a one-time threshold marker to prevent log storms.
Operational value:
- counts industrial operations rather than raw bandwidth;
- scopes thresholds by device and operation;
- emits one meaningful crossing event instead of an alert for every packet.
13. Alarm lifecycle and chattering¶
Industrial concern: An alarm remains active without acknowledgement, clears without the expected lifecycle, or toggles repeatedly in a short interval.
Policy behavior: Track normal, active, acknowledged, and cleared phases while counting real state toggles in a bounded window. A threshold marker avoids repeated chattering alerts.
Operational value:
- separates alarm occurrence from acknowledgement and clearance;
- detects unstable instrumentation or process oscillation;
- supports persistence and chattering analysis in a common audit trail.
Customer configuration worksheet¶
For each selected use case, define:
| Input | Customer decision |
|---|---|
| Assets and DNP3 addresses | Masters, outstations, redundant roles, criticality |
| Object and point mapping | CROB, BI, AI, AO, file, configuration, alarm points |
| Operation identity | Opcode, timing, analog value, target set, function |
| Timing | Correlation TTL, process response deadline, recovery deadline, counter window |
| Identity | Network endpoints, L2Proxy Connect access domain/user/session, maintenance role |
| Normal exceptions | Retry, failover, local operation, startup, emergency procedure |
| Decision mode | Observe, alert, accept allow-list, or drop violation |
| Evidence | Required metadata, severity, retention, and ticket fields |
| Acceptance tests | Happy path, missing, mismatch, expiry, replay, duplicate, concurrency |
Recommended deployment sequence¶
- Select one high-value, well-understood operation.
- Confirm full bidirectional visibility and parser coverage.
- Apply the customer's point and identity mappings.
- Run the policy in log-only mode against representative traffic.
- Review false positives with operations and control engineering.
- Execute negative, timeout, replay, and concurrency fixtures.
- Approve and enable only the required drop branches.
- Monitor state capacity, timeouts, and decision events after rollout.