A setpoint that is within a controller's general range can still be dangerous in the state the process is in, and a check that ignores state lets a crafted write or a mistyped HMI entry through. MITRE D3FEND names the countermeasure Operational Logic Validation (D3-OLV) and defines it as "Validation of variable state in the context of the control logic of the operational application." It sits under the Harden tactic as a child of Domain Logic Validation (D3-DLV), within Source Code Hardening, and validates the OT Control Function artefact. This card explains what state-aware validation looks like in PLC and controller logic, where it is built, how to test it without upsetting the process, and what it cannot stop. It is for controls engineers, OT security leads and integrators who already know the basics in the PLC Security Guide.
Key takeaways
- It is range checking that knows the process state. D3FEND's example: if a controller has a restricted range in a specified state, the value is cross-checked against the state as well as against a general range.
- The check belongs in the controller. The Top 20 Secure PLC Coding Practices, which D3FEND cites, says HMI input restrictions can be bypassed with crafted network traffic, so values must be validated at the PLC level too.
- D3FEND lists no ATT&CK mapping. The Top 20 document itself maps its validation practices to ATT&CK for ICS techniques such as T0836 Modify Parameter and T0806 Brute Force I/O.
- Every check needs a defined failure action. Substitute a flagged safe value, or restore the last valid value and log the event: the choice is a process safety decision, not only a security one.
- Test it like any logic change. Simulation or a test bench first, then commissioning tests that inject out-of-state values and confirm the alarm and the safe response.
D3-OLV at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-OLV (d3f:OperationalLogicValidation) |
| Tactic | Harden |
| Parent technique | Domain Logic Validation (D3-DLV), under Source Code Hardening (D3-SCH) |
| Digital artefact | OT Control Function, "a function which accesses OT Control Variables" (D3FEND relation: validates) |
| Where the artefact lives | D3FEND models HMI Application as containing OT Control Function; in practice also PLC, RTU and DCS controller logic |
| D3FEND reference | Top 20 Secure PLC Coding Practices (plc-security.com), V1.0, dated 15 June 2021 |
| What it checks | Type, value and range of a variable, given the local operational logic and operational state |
| Effort | Medium: engineering change to controller logic, with testing and management of change |
| Main limitation | Cannot catch a malicious value that is plausible for the current state, or logic that has itself been replaced |
How it works
D3FEND's knowledge base article says D3-OLV validates the type, value and/or range of a variable taking into account the local operational logic and operational state. Its parent, Domain Logic Validation, does the same for business applications; see D3-DLV Domain Logic Validation. The plain type and range checks are separate D3FEND techniques, covered in D3-VTV Variable Type Validation and D3-IRV Integer Range Validation. D3-OLV adds the process context on top.
The Top 20 Secure PLC Coding Practices gives the concrete patterns. The practices below are the ones that implement state-aware validation; numbers and titles are as published.
| Practice | Title | What it adds to D3-OLV |
|---|---|---|
| 2 | Track operating modes | The operational state the validation logic needs to know |
| 6 | Validate timers and counters | Allowed ranges for presets and timeouts; remote writes pass through PLC validation logic rather than writing directly |
| 7 | Validate and alert for paired inputs / outputs | Alarms on physically impossible combinations such as start and stop, or open and close, active together |
| 8 | Validate HMI input variables at the PLC level, not only at HMI | Range and data type checks in the controller, with a defined response to bad values |
| 9 | Validate indirections | Bounds and sentinel checks when one register indexes another |
| 11 | Instrument for plausibility checks | Cross-checks between measurements, for example integrated pump flow against change in tank level |
| 12 | Validate inputs based on physical plausibility | Operators can enter only feasible values; timers alert when an operation completes too fast or too slow |
| 15 | Define a safe process state in case of a PLC restart | The state the logic returns to when validation or the controller itself fails |
A worked example in the document's terms: Practice 6 notes that a 1.3 second alarm timer preset to five minutes would fail to alarm in time, and a stop counter at 10,000 preset to 11,000 would never trigger the stop. A state-aware rule would accept a longer timer preset only in a mode where that is safe, such as maintenance, and reject or alarm on it in normal running. Practice 12 cites the Oldsmar, Florida water incident, where operator input was thousands of times higher than normal and physically impossible: a controller-level limit tied to the dosing state would have rejected the value whatever the HMI allowed.
Choosing the failure response
Practice 8 gives two options for an out-of-range value: substitute a safe default value that is flagged for alerting, or restore the last valid value and log the event. Which one is correct depends on the process. Holding the last value is usually right for a setpoint; forcing a safe value is usually right for a limit that protects equipment. Decide with process and safety engineers, record the decision in the control narrative, and never let a security check override a safety instrumented function.
ATT&CK relationships
D3FEND lists no ATT&CK technique for D3-OLV. No ATT&CK technique is modelled as acting on the OT Control Function artefact, so D3FEND infers no relation (checked November 2026). The rows below come from the Top 20 Secure PLC Coding Practices, which maps its own validation practices to ATT&CK for ICS; they are not D3FEND mappings. Each ID was checked against ATT&CK v20.
| ATT&CK for ICS ID | Technique | Top 20 practices mapped to it | What state-aware validation stops |
|---|---|---|---|
| T0836 | Modify Parameter | 3, 4, 6, 7, 8, 9, 10, 14 | A written setpoint, preset or limit that is invalid for the current state |
| T0806 | Brute Force I/O | 7, 11, 12 | Rapid repeated toggling and implausible I/O combinations |
| T0858 | Change Operating Mode | 2 | Mode changes the logic does not expect, which also invalidate the state the checks rely on |
| T0835 | Manipulate I/O Image | 10 | Writes to registers outside the blocks designated for that function |
ATT&CK for ICS mitigation M0818 Validate Program Inputs describes the same control family. Technique pages: MITRE ATT&CK for ICS T0836 Modify Parameter, T0806 Brute Force I/O and ICS T0858 Change Operating Mode.
Where it is implemented
- Controller logic: PLC, RTU and DCS controller programs, written in the IEC 61131-3 languages or vendor equivalents. This is the primary location, because it is the last point before the value reaches the physical process.
- HMI and SCADA: input limits on screens. Useful for operator feedback, but Practice 8 is explicit that they are not sufficient alone.
- Vendor application notes: the Top 20 project site lists application notes from integrators and vendors that show the practices in specific engineering environments; use the one for your platform where it exists.
- Monitoring: OT network monitoring tools that decode industrial protocols can alert on writes to setpoints outside expected values, which is detection rather than validation but catches cases where the logic has none. See the OT Security Guide.
Implementation steps
- List the variables that matter. Start with setpoints, timer and counter presets, and limits that an HMI, historian or remote system can write. Rank them by consequence if wrong.
- Write down the state model. For each controller, the operating modes and process states (start-up, running, maintenance, shutdown) and which ranges apply in each. Practice 2 (track operating modes) gives the logic the state it needs.
- Define rules and responses. For each variable and state, the valid range, the plausibility cross-check if any, and the failure action (safe value or last valid value, plus alarm). Review with process safety.
- Implement in a test environment. Use the vendor simulator or a test bench. Route remote writes through validation logic rather than direct register writes, as Practice 6 recommends.
- Test and commission. Inject values that are valid in one state and invalid in another, confirm the alarm text, the logged event and the safe response, then commission under management of change.
- Keep a rollback. Store the previous signed or checksummed program version (Practice 5) so a rule that causes nuisance trips can be reverted quickly.
How to verify it works
- Injection tests at commissioning and after each logic change: one test case per rule and state, with recorded results.
- Alarm review: validation alarms reach the HMI and the historian with a clear message; Practice 20 (trap false negatives and false positives for critical alerts) applies to these alarms too.
- Logic integrity: compare running programs with the approved baseline, because validation only helps if the logic carrying it is unchanged.
Example metrics (examples, not standards): percentage of remotely writable setpoints with controller-level validation; validation alarms per month, split between operator error, engineering error and unexplained; time to review an unexplained validation alarm; number of logic changes released without injection tests (target zero).
Limits and failure patterns
- Plausible but malicious: a value that is valid for the current state passes. Plausibility cross-checks between independent measurements (Practice 11) narrow this but do not close it.
- Logic replaced: an attacker who can download a new program (T0843 Program Download) removes the checks with it. Pair D3-OLV with program integrity checks and controller access control.
- State spoofed: if the mode or state variable can itself be written, the check uses the wrong range. Protect state variables as carefully as setpoints.
- HMI-only limits: limits that exist only in HMI scripts are bypassed by any direct protocol write.
- Nuisance trips: rules written without process input trip on legitimate operations, and operators learn to ignore or bypass them.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| Top 20 Secure PLC Coding Practices | Practices 2, 6, 7, 8, 9, 11, 12, 15 | The D3FEND-cited source for the technique |
| ISA/IEC 62443-3-3 and 62443-4-2 | SR 3.5 / CR 3.5 Input validation; SR 3.6 / CR 3.6 Deterministic output (as mapped by the Top 20 document) | System and component requirements; see the IEC 62443-3-3 and 4-2 Security Levels Guide |
| MITRE ATT&CK for ICS | M0818 Validate Program Inputs | Equivalent mitigation |
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation; SI-17 Fail-safe Procedures | Our mapping |
| NIST SP 800-82 Rev 3 | Guide to Operational Technology (OT) Security | OT overlay and architecture context; see the NIST SP 800-82 OT Security Guide |
Practitioner checklist
- List every remotely writable setpoint, preset and limit, ranked by consequence.
- Document operating modes and the valid range of each variable in each mode.
- Validate in the controller, not only in the HMI, and route remote writes through validation logic.
- Agree the failure response for each rule with process safety and record it in the control narrative.
- Alarm on impossible paired I/O states and implausible operation times.
- Protect mode and state variables from unauthorised writes.
- Run injection tests at commissioning and after every logic change, with a stored rollback version.
- Review unexplained validation alarms as possible security events.
Standards and references
- MITRE D3FEND: Operational Logic Validation (D3-OLV)
- Top 20 Secure PLC Coding Practices Project: Top 20 Secure PLC Coding Practices V1.0
- Top 20 Secure PLC Coding Practices Project: project page and application notes
- MITRE ATT&CK for ICS: M0818 Validate Program Inputs
- MITRE ATT&CK for ICS: T0836 Modify Parameter
- NIST: SP 800-82 Rev 3, Guide to Operational Technology (OT) Security
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE ATT&CK for ICS Guide · IEC 62443 Guide · OT Security Assessment Guide