If every register on a controller is writable over the network, any host that can speak the protocol can change a setpoint. D3-OVAR OT Variable Access Restriction is the MITRE D3FEND countermeasure that narrows this: D3FEND defines it as "Assign read/write access controls on designated registers or data tags to prevent unauthorized writes." It sits under Access Mediation in the Isolate tactic, restricts the OT Write Command artefact and limits the OT Logic Variable artefact; D3FEND gives "OT Variable Access Policy" as a synonym. This card explains what the control changes, which attacker behaviour it is relevant to, where it is implemented, how to verify it, and its limits. It is written for control engineers, integrators and OT security teams. For the parent technique, see the MITRE D3FEND Access Mediation Implementation Guide.
Key takeaways
- Default to read-only, open writes deliberately. Most tags exist to be read by HMIs and historians; only a small, named set should accept external writes.
- The protocol's own data model is a control. D3FEND's example maps process values to Modbus Input Registers, which the Modbus specification defines as read-only.
- Group writable tags in designated blocks. The Top 20 Secure PLC Coding Practices (practice 10) separates read, write and validate blocks so that firewalls and logic can treat them differently.
- D3FEND lists no ATT&CK mapping yet. Its relevance to T0836 Modify Parameter comes from the shared OT Write Command and OT Logic Variable artefacts, which is NHI Mgmt Group's reading of the ontology.
- Access restriction is not validation. A writable tag still needs range checks in the PLC, because an attacker who reaches an authorised write path can send any value.
D3-OVAR at a glance
| Field | D3-OVAR OT Variable Access Restriction |
|---|---|
| D3FEND ID | D3-OVAR |
| Tactic | Isolate |
| Parent technique | Access Mediation |
| Digital artefacts | OT Write Command (restricts); OT Logic Variable (limits) |
| Defined by (D3FEND) | Top 20 Secure PLC Coding Practices, practice 10 |
| What it changes | Which registers, coils or data tags external sources can write, and from where |
| Typical implementation points | Controller tag and data block properties, protocol register mapping, communication modules and protocol gateways, OT-aware firewalls |
| Typical data sources for verification | Controller project configuration, protocol exception responses, OT network monitoring of write function codes |
| Main limitation | Does not judge whether a permitted write carries a safe value |
| Related ATT&CK mitigation | M0800 Authorization Enforcement (its T0836 guidance includes enabling write protection for parameters) |
How it works
D3FEND's knowledge base article gives three points. Many OT controllers and communication modules allow read-only or read/write access to be set per tag. For tags exposed over Modbus, configuring the tag as a Modbus Input Register uses the protocol's register ranges to stop external sources modifying the data. On Siemens controllers, each data block tag can be configured as "data block write-protected in the device".
The Modbus Application Protocol specification makes the first example concrete. Its data model has four tables:
| Modbus table | Object type | Access | D3-OVAR use |
|---|---|---|---|
| Discrete Inputs | Single bit | Read-only | Status values that no one outside should set |
| Coils | Single bit | Read-write | Only commands that operators must issue |
| Input Registers | 16-bit word | Read-only | Process values for HMIs and historians |
| Holding Registers | 16-bit word | Read-write | Only setpoints and parameters with an operator need |
The write function codes defined by the specification are 05 Write Single Coil, 06 Write Single Register, 15 Write Multiple Coils, 16 Write Multiple Registers, 21 Write File Record, 22 Mask Write Register and 23 Read/Write Multiple Registers. A server that rejects a request returns an exception, for example 01 Illegal Function or 02 Illegal Data Address. D3FEND lists the equivalent write commands for other protocols, including BACnet writeProperty, CIP Set Attribute Single and GE-SRTP write memory commands, so the same thinking applies beyond Modbus.
The Top 20 Secure PLC Coding Practices (practice 10, Assign designated register blocks by function) adds the design pattern: separate blocks for reading, for writes from the HMI or other devices, for validating writes and for calculations. Grouping read-only registers together makes firewall rules simpler, and designated write blocks act as buffers that logic checks before use. It gives a cautionary example: arbitrary writes to register memory changed a pressure value in a way that could push the process beyond its safety margins.
ATT&CK techniques related to D3-OVAR
Relationship type: none listed by D3FEND. The D3FEND technique page for D3-OVAR lists no related offensive techniques in the current release (checked November 2026). The rows below are NHI Mgmt Group's reading of the D3FEND ontology, where these ATT&CK for ICS techniques act on the same OT Write Command or OT Logic Variable artefacts. IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | Link in the D3FEND ontology | What D3-OVAR changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T0836 | Modify Parameter | Produces OT Write Command; modifies OT Logic Variable | Strong for tags made read-only; none for tags left writable |
| T0801 | Monitor Process State | Accesses OT Logic Variable | None: read access is preserved by design |
| T0861 | Point & Tag Identification | Reads OT Logic Variable | None: reads are still allowed |
| T0877 | I/O Image | Reads OT Logic Variable | None: reads are still allowed |
The read techniques are included for honesty: D3-OVAR stops writes, not reconnaissance. ATT&CK's T0836 procedure examples include FrostyGoop, which reads and writes device registers over Modbus to change system settings, and Stuxnet, which changed parameters on frequency converter drives. See the MITRE ATT&CK for ICS T0836 Modify Parameter and the T0861 Point & Tag Identification.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Controller tags and data blocks | Per-tag read-only or read/write access; write protection on data blocks that external systems only read | All tags left at default external access during commissioning |
| Protocol mapping | Map process values to read-only tables (Input Registers, Discrete Inputs); keep writable tables small | Everything mapped to Holding Registers for convenience |
| Communication modules and gateways | Per-tag or per-range read/write settings on the module or protocol gateway (D3FEND cites a multi-protocol gateway manual) | Gateway configured to pass any write to the controller |
| Designated register blocks | Separate write buffer blocks, validated by logic before values reach the process (Top 20 practice 10) | HMI writes go straight into live logic variables |
| OT-aware firewall or protocol filter | Allow write function codes only from named HMIs or engineering hosts and only to the write block range | Firewall permits the protocol port but does not inspect function codes |
For protocol-level controls, see the Industrial Protocol Security Guide and the Industrial Switch and Serial Gateway Hardening Guide.
Implementation steps
- Build a write map. From the controller project and HMI configuration, list every tag that any external system writes, which system writes it, and why. Everything else is a candidate for read-only.
- Confirm with traffic. Use passive OT monitoring to record which hosts send write function codes to which addresses over a representative period, including maintenance.
- Restructure where needed. Move writable values into designated write blocks and process values into read-only tables. Do this in a planned project change, not live.
- Apply the restrictions. Set read-only access on tags and data blocks, then configure gateways and protocol filters to match.
- Test before cutover. On a test bench or simulator, confirm that HMIs still read every value, that permitted writes work, and that blocked writes return an exception rather than silently failing.
- Roll back cleanly. Keep the previous project version so access settings can be restored in one download if an operator function breaks.
- Add validation in logic. For each writable tag, add range checks in the PLC, as practice 8 of the Top 20 recommends, so the HMI is not the only check.
How to verify it works
- Configuration review: export tag and data block access settings from the controller project and compare against the write map at every project change.
- Negative write test: in a maintenance window, from an authorised test host, attempt a write to a read-only address and confirm the controller or gateway refuses it with a protocol exception.
- Source test: attempt a permitted write from a host not on the allow list and confirm the firewall or protocol filter blocks it and logs the attempt.
- Monitoring: ATT&CK's detection strategy for T0836 describes alerting on ICS protocol writes to setpoint registers from sources not on an approved write list, or with values outside safe ranges, outside a change window. Confirm your monitoring produces that alert.
| Metric (examples, not standards) | What it shows | Target direction |
|---|---|---|
| Share of externally exposed tags that are read-only | Size of the writable surface | Rising; writable tags each have a documented owner |
| Writes observed from hosts not on the write allow list | Unexpected writers | Zero, each one investigated |
| Writes to addresses outside designated write blocks | Gaps in the block design | Zero |
| Writable tags without PLC range validation | Values that rely on HMI checks alone | Falling to zero |
Limits, bypasses and failure patterns
- Writable means trusted: a permitted write path still accepts any value. Practice 12 of the Top 20 cites the Oldsmar water case, where an operator could enter setpoints far above normal and physically impossible values.
- Program download overrides tag settings: an attacker who can download a new project can change access settings with it. Pair D3-OVAR with D3-OPR Operating Mode Restriction.
- Compromised HMI or engineering host: writes from an allow-listed host pass every access check. Protect those hosts and their accounts.
- Gateway pass-through: a protocol gateway that converts between networks can expose writable addresses that the controller's own settings never anticipated.
- Drift after maintenance: access settings are relaxed for commissioning or troubleshooting and never restored.
Where identity fits
The write allow list is really a list of machine identities: HMIs, historians, gateways and engineering workstations that the controller trusts by address. Most industrial protocols carry no user identity, so the controller cannot tell an operator's command from an attacker's packet sent from the same host. Treat each allow-listed host as a non-human identity with an owner, a purpose and a review date. See the NHIs in OT.
Framework mapping
| Framework | Reference | Relationship to D3-OVAR |
|---|---|---|
| MITRE ATT&CK for ICS | M0800 Authorization Enforcement | T0836 guidance: restrict parameter changes to roles, restrict online edits, enable write protection |
| MITRE ATT&CK for ICS | M0818 Validate Program Inputs | Complements access restriction for tags that stay writable |
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement | Enforcing read or write authorisation on each data object |
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | Checking values on permitted writes |
| Top 20 Secure PLC Coding Practices | Practice 10 (and 8) | Designated register blocks; validate HMI inputs at the PLC |
Practitioner checklist
- Document every externally written tag with its writer, purpose and owner.
- Set all other exposed tags and data blocks to read-only.
- Map process values to read-only protocol tables and keep writable tables small.
- Place writable values in designated write blocks validated by PLC logic.
- Configure gateways and OT firewalls to allow write function codes only from named hosts to named ranges.
- Test blocked writes return an exception before cutover, and keep the previous project for rollback.
- Alert on writes from unexpected hosts or to unexpected addresses.
- Re-check access settings after every commissioning or troubleshooting change.
Standards and references
- MITRE D3FEND: OT Variable Access Restriction (D3-OVAR)
- PLC Security: Top 20 Secure PLC Coding Practices
- Modbus Organization: Modbus Application Protocol Specification V1.1b3
- MITRE ATT&CK for ICS: T0836 Modify Parameter
- MITRE ATT&CK for ICS: M0800 Authorization Enforcement
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: MITRE D3FEND Access Mediation Implementation Guide · PLC Security Guide · Industrial Protocol Security Guide · MITRE ATT&CK for ICS T0836 Modify Parameter · MITRE D3FEND Guide