# Module 15: Security & Safety

> What classic Modbus does not protect, write safety practice, and TLS / Modbus Security.

**Phase:** Integration & Real Systems  
**Estimated time:** 9 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/security-safety

## What you'll be able to do
- List what classic Modbus does not protect (authentication, encryption, integrity beyond CRC).
- Apply defensive write practices (allowlists, rate limits, write-readback).
- Describe Modbus/TCP Security at a high level.

## Three things people get wrong
1. **Relying on 'Modbus is internal'.** Flat OT networks are common. Assume the wire is reachable and design accordingly.
2. **Writing without read-back verification.** A successful FC 06/16 response says the bytes arrived, not that the device accepted them. Always read back a critical write.
3. **Ignoring Modbus Security because 'no one uses it yet'.** Adoption is rising. Even if not deploying it today, design with a migration path in mind.

## From the field
**The pump that ran on weekend nights**

An overnight pump cycle no one had scheduled turned out to be a misconfigured maintenance script writing to the wrong Unit ID. There was no authentication, no audit log, and no read-back — just a script running on a laptop someone forgot in a panel.

## References
- [Modbus/TCP Security Protocol Specification v36](https://www.modbus.org/file/secure/modbussecurityprotocol.pdf)
- [ISA/IEC 62443](https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)

## Lesson

# Module 15 Lesson: Security And Safety
## Learner Outcome

By the end of this module, learners can explain why classic Modbus needs compensating controls, distinguish read and write risk, identify write functions in isolated evidence, map Modbus-specific risks to defensive controls, and apply a write-safety stop before any command affects real equipment.

## Key Concepts

- Classic Modbus RTU, ASCII, and TCP were not designed with modern authentication, authorization, or encryption.
- Modbus Security protects the transport with TLS and certificate-based identity, but the underlying Modbus function codes and register meanings still matter.
- Read functions can expose process state; write functions can change process or device state.
- A Modbus write response confirms protocol-level acceptance shape, not the physical outcome.
- Defensive controls include segmentation, allowlisting, write restrictions, monitoring, change control, and safe operating procedures.
- Security labs must be isolated, defensive, authorized, and simulator-first.

## Key Terms

- Classic Modbus: Modbus RTU/ASCII/TCP behavior without modern built-in authentication, authorization, or encryption.
- Modbus Security: TLS-protected Modbus TCP profile associated with `mbap-s`.
- TLS: Transport Layer Security, used to protect network communication.
- Certificate: identity material used by TLS and, in Modbus Security, role-related authorization context.
- Segmentation: network separation that limits which clients can reach Modbus servers.
- Allowlisting: permitting only expected clients, functions, or paths.
- Monitoring: recording and reviewing traffic or events for defensive purposes.
- Write safety: the operational review boundary before any write-capable action.

## Source-Grounded Explanation

### Classic Modbus Is Not The Security Boundary

Classic Modbus TCP commonly runs in plaintext on TCP port `502`. Classic Modbus RTU and ASCII also do not provide modern peer authentication, user authorization, or encryption at the protocol level. If a client can reach a device and the device accepts the request, the protocol itself does not normally prove that the client is authorized to read or write that register.

This is a protocol design boundary, not a reason to panic. Many systems use classic Modbus safely because the surrounding architecture controls who can reach it, what can be changed, and how activity is monitored.

### Modbus Security

Modbus Security, also called Modbus/TCP Security or `mbaps`, wraps Modbus TCP ADUs in TLS and is associated with TCP port `802`. The official security specification describes certificate-based identity and TLS transport protection. Role-based client authorization may be represented through certificate role extensions.

Important boundary: Modbus Security protects the transport and identity layer. It does not make a wrong register map correct, does not define a device's write semantics, and does not prove that a process reached the intended physical state after a command.

### Read Risk Versus Write Risk

Reads and writes deserve different safety treatment:

| Activity | Risk Pattern | Evidence To Collect |
|---|---|---|
| Read coils/discrete inputs/registers | Process information, status, alarms, production context, or sensitive operational state may be exposed. | Source, destination, Unit Identifier or serial server address, function code, address range, polling rate, business need. |
| Write single coil/register | A command, mode, setpoint, reset, or configuration may change state. | Documented meaning, allowed states, safe range, operating mode, rollback, independent feedback. |
| Write multiple coils/registers | Several changes may happen in one request, including packed bits or multi-word values. | Full payload, bit order, word order, expected affected points, before/after state. |
| Mask or read/write multiple registers | Partial bit changes or combined actions may be difficult to reason about. | Mask logic, unaffected bits, write range, read range, vendor semantics. |

Function codes that deserve extra attention in monitoring and safety review include `05`, `06`, `15`, `16`, `22`, and `23` when supported by a device.

### Write Echo Is Not Physical Proof

For common write functions, the normal Modbus response echoes the request address and written value or summarizes the written range. That response is useful protocol evidence, but it is not proof that the physical process reached the desired state.

Real devices may:

- Reject the command because local mode, interlock, safety state, or authority is wrong.
- Accept a setpoint but clamp it internally.
- Echo a command while an active setpoint ramps over time.
- Require unlock registers, command confirmation, or multi-step sequences.
- Store a persistent configuration value that has long-term effects.
- Use product-specific command words, magic values, or role-limited registers.

The safe pattern is: document the command, check preconditions, send only in an authorized isolated or approved context, read independent status, and record rollback or stop actions.

### Defensive Control Map

Use source-backed controls rather than tool-specific magic:

| Modbus Risk | Defensive Control |
|---|---|
| Any client can reach TCP `502` on a classic Modbus device. | Segment OT, block internet exposure, allow only required clients, log new sources. |
| Broad engineering workstation access. | Least-required network paths, maintenance windows, change control, separate read/write access where possible. |
| Unexpected write functions. | Block or alert on write functions except from approved control nodes and expected ranges. |
| Repeated or replayed commands. | Monitor repeated writes, validate state before action, require independent feedback and operator procedure. |
| Gateway path hides downstream target. | Monitor Unit Identifier, route configuration, gateway logs, and downstream target health. |
| Tool syntax differs by version. | Verify Suricata, Zeek, Snort, Wireshark, firewall, and gateway behavior before publishing commands. |

### Safe Course Boundary

This module teaches defensive recognition and safe decision-making. It does not teach unauthorized access, scanning public networks, exploiting devices, or bypassing controls. Labs use synthetic event cards, offline reviewed traffic, localhost simulators, or instructor-controlled lab networks only.

## Practical Example: Synthetic Write Event

Scenario: a lab simulator exposes a synthetic command register with no physical effect. A learner reviews one write event.

| Item | Value |
|---|---|
| Transport | Modbus TCP on isolated lab network or saved fixture |
| Function code | `06` Write Single Register |
| Documented register | Synthetic holding register `40020` |
| Actual PDU address | `0x0013` |
| Quantity | one register |
| Data type | unsigned 16-bit command code |
| Scale/unit | not an engineering measurement |
| Expected normal response | Echo function `06`, address `0x0013`, and written value |
| Defensive observation | New client writes to a command register outside approved context |
| Safety decision | Alert and investigate in lab; in the field, stop and require authorization plus write-safety checklist |

Learner task:

1. Identify the write function.
2. Record source, destination, Unit Identifier, function code, address, and value.
3. Decide whether the source is approved.
4. Draft a plain-language monitoring requirement.
5. Explain why a write echo is not physical proof of the process state.

Plain-language monitoring requirement:

```text
Alert when any unapproved client sends Modbus write function 05, 06, 15, 16, 22, or 23
to the synthetic command range. Record source, destination, Unit Identifier, function code,
address or range, value when available, and time.
```

Do not convert this into deployable Suricata, Zeek, Snort, firewall, or gateway syntax until the selected tool version, parser behavior, field names, and lab traffic are verified.

## Common Pitfalls

- Saying Modbus is secure because it is behind a VPN.
- Treating read-only polling and write commands as the same operational risk.
- Treating a write echo as proof that the physical process changed correctly.
- Writing to reserved, hidden, installer-only, or unclear registers on real devices.
- Ignoring local/remote mode, interlocks, active faults, and command authority.
- Publishing detection-rule syntax before checking the selected tool version.
- Running security labs against public IPs, production systems, or third-party devices.
- Turning a defensive course into offensive instructions.

## Instructor Flow

1. Start with the protocol boundary: classic Modbus does not authenticate command authority.
2. Compare read exposure and write control risk.
3. Show the synthetic write event and ask learners what evidence they would record.
4. Use the threat-to-control worksheet to map risks to segmentation, allowlisting, monitoring, Modbus Security, and write-safety procedure.
5. Stop every real-device write scenario at the write-safety checklist and Safety Review Appendix unless a controlled training device and approved procedure exist.

## Check-Your-Understanding

1. Why does classic Modbus need network and operational controls around it?
2. What does Modbus Security add, and what does it not solve?
3. Why is function `06` higher risk than a read-only function in a live system?
4. What evidence should be recorded when a write function appears in lab traffic?
5. Why should tool-specific detection syntax stay gated until version verification?

## Source Notes

- Official protocol basis: Modbus Application Protocol Specification V1.1b3 for function codes and write response behavior.
- Official security basis: Modbus/TCP Security Protocol Specification for TLS wrapping, certificate identity, role-extension concept, and TCP port `802`.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for write single coil/register shape and echo boundary, write multiple coils/registers quantity limits, mask write register, read/write multiple registers, IANA service name `mbap` on port `502`, IANA service name `mbap-s` on port `802`, Modbus Security wraps Modbus/TCP in TLS, Modbus Security certificates and role authorization, and Modbus Security TLS requirements.
- Authoritative OT security framing: [security-citation-map.md](https://learnmodbus.studioseventeen.io/resource/security-citation-map) rows for NIST SP 800-82 Rev. 3, CISA ICS defense-in-depth guidance, and MITRE ATT&CK for ICS defensive analysis language.
- Internal course basis: `modbus-wiki.md`, `release/write-safety-checklist.md`, `release/threat-to-control-worksheet.md`, and Module 14 troubleshooting stop conditions.
- Tool behavior: Suricata, Zeek, Snort, Wireshark, firewall/DPI gateways, public PCAPs, Node-RED, and simulator outputs require version-pinned verification before learner release.
- Synthetic source: Module 15 lab events are course-authored fixtures, not captured production traffic.

## Completion Checkpoint

Before moving on, learners should identify whether an event is read-only or write-capable, record source/destination/function/address/value evidence, and explain which safety or defensive control gate applies before any real-device action.

## Reusable Assets

- [Defensive write monitoring lab](https://learnmodbus.studioseventeen.io/lesson/security-safety?page=lab-1)
- [Threat-to-control worksheet](https://learnmodbus.studioseventeen.io/resource/threat-to-control-worksheet)
- [Write-function risk reference](https://learnmodbus.studioseventeen.io/resource/write-function-risk-reference)
- [Modbus write-safety checklist](https://learnmodbus.studioseventeen.io/resource/write-safety-checklist)
- [Safety Review Appendix](https://learnmodbus.studioseventeen.io/resource/safety-review-appendix)
- [Module 15 quiz](https://learnmodbus.studioseventeen.io/lesson/security-safety?page=quiz)

## Diagram source

```mermaid
flowchart LR
  C["Client"] -- "TLS handshake" --> S["Server (Modbus Security)"]
  S -. "Cert pinning + auth role" .-> C
  C -- "Authorized writes only" --> S
```

## Labs

### Lab 1

# Lab 20: Defensive Write Monitoring Without A Live Network
## Learner Outcome

Learners can identify Modbus write-function events in synthetic evidence, separate read activity from write activity, draft a defensive monitoring requirement, and apply the write-safety stop before any real command is sent.

## Prerequisites

- Module 4: function codes and write responses.
- Module 12: Modbus TCP and MBAP fields.
- Module 13: gateway Unit Identifier and route evidence.
- Module 14: troubleshooting evidence log and safety stop.
- Module 15 lesson through read/write risk and write echo limitations.

## Safety And Scope

This is a no-hardware and no-network lab. It uses synthetic event cards, not live traffic. Do not scan networks, connect to production devices, or write to real equipment. Tool-specific detection syntax is intentionally out of scope until versions and expected outputs are verified. Any real-device or deployable monitoring extension must pass the [Safety Review Appendix](https://learnmodbus.studioseventeen.io/resource/safety-review-appendix).

## Scenario

A lab system records Modbus TCP events from an isolated simulator. The process has no physical effect. Learners review the event cards and decide which events are ordinary reads, which are write actions, which are suspicious, and which require a safety stop.

## Event Cards

| Card | Event Evidence | Learner Task |
|---|---|---|
| A | Approved HMI reads function `03`, Unit Identifier `1`, PDU address `0x0009`, quantity `2`, every 2 seconds. | Classify read activity and expected baseline evidence. |
| B | Engineering laptop reads function `04`, Unit Identifier `1`, PDU address `0x0032`, quantity `2`, during approved maintenance. | Decide whether this is read exposure or write risk. |
| C | Unknown client sends function `06`, Unit Identifier `1`, documented register `40020`, PDU address `0x0013`, value `0x0001`. | Identify write function and draft alert requirement. |
| D | Approved controller sends function `16`, Unit Identifier `1`, documented registers `40033-40034`, PDU address `0x0020`, quantity `2`, byte count `4`, payload `00 32 00 00`, maintenance window noted. | Record full payload and required independent feedback. |
| E | Unknown client repeatedly sends function `05` to documented coil `00001`, PDU address `0x0000`, value `FF00`, five times in one minute. | Identify repeated write pattern and risk. |
| F | Client sends function `03` through a gateway with unexpected Unit Identifier `9`; gateway returns exception `0A`. | Classify as route/path evidence, not a write event. |
| G | Technician proposes function `06` to a live drive setpoint because the dashboard is wrong. Process effect is unknown. | Apply safety stop and route to write-safety checklist. |
| H | Saved event shows function `06` response echoing address `0x0013` and value `0x0001`; no status register is read afterward. | Explain why echo is incomplete evidence. |

## Procedure

1. Classify each card as read activity, write activity, gateway/path evidence, or safety stop.
2. For write activity, record source role, destination, Unit Identifier, function code, documented address if known, PDU address, value or quantity, approval context, and independent feedback.
3. Decide whether the event should be allowed, alerted, blocked, or escalated in a lab policy.
4. Draft one plain-language monitoring requirement for Cards C and E.
5. For Cards G and H, complete the stop condition and independent-feedback notes instead of sending a command.

## Worksheet

| Card | Classification | Function | Address / Range | Source Context | Decision | Evidence To Record |
|---|---|---|---|---|---|---|
| A |  |  |  |  |  |  |
| B |  |  |  |  |  |  |
| C |  |  |  |  |  |  |
| D |  |  |  |  |  |  |
| E |  |  |  |  |  |  |
| F |  |  |  |  |  |  |
| G |  |  |  |  |  |  |
| H |  |  |  |  |  |  |

## Answer Key

| Card | Classification | Function | Address / Range | Source Context | Decision | Evidence To Record |
|---|---|---|---|---|---|---|
| A | Baseline read | `03` | `0x0009`, quantity `2` | approved HMI | Allow and baseline | source, destination, polling rate, Unit Identifier, function, range |
| B | Read exposure | `04` | `0x0032`, quantity `2` | approved maintenance laptop | Allow if approved; monitor as new source | source, approval window, function, range, business need |
| C | Write activity | `06` | documented `40020`, PDU `0x0013`, value `0x0001` | unknown client | Alert/escalate; block in real control policy if not approved | source, destination, Unit Identifier, function, address, value, time |
| D | Approved write activity | `16` | documented `40033-40034`, PDU `0x0020`, quantity `2`, payload `00 32 00 00` | approved controller in window | Allow only with change record and independent feedback | full payload, expected meaning, echo, status readback, rollback |
| E | Repeated write activity | `05` | documented coil `00001`, PDU `0x0000`, value `FF00` | unknown client | Alert/escalate; investigate repeated command pattern | count, timing, source, coil meaning, response, status effect |
| F | Gateway/path evidence | `03` request plus exception `0A` | read request | unexpected Unit Identifier | Troubleshoot route; not a write alert | Unit Identifier, gateway route/path, exception, source |
| G | Safety stop | proposed `06` | live drive setpoint unknown | technician request | Stop; require authorization and write-safety checklist | device, register, process effect, rollback, independent verification |
| H | Incomplete write evidence | `06` response echo | `0x0013`, value `0x0001` | saved event | Require independent status read | echo, missing status, expected physical state, confirmation register |

## Plain-Language Monitoring Requirements

Card C:

```text
Alert when any unapproved source sends Modbus function 06 to the synthetic command register
at PDU address 0x0013. Record source, destination, Unit Identifier, value, response, and time.
```

Card E:

```text
Alert when a source sends repeated Modbus write function 05 requests to coil 0x0000
more than once inside the lab review window. Record count, timing, source, response, and coil meaning.
```

## Expected Observations

- Read events still matter for exposure and baselining, but write events require stricter safety review.
- Unknown write sources deserve escalation even when the Modbus response is normal.
- A write echo is protocol evidence, not physical proof.
- Gateway exceptions are useful security context but not automatically write activity.
- Tool-specific rules should come after the plain-language detection requirement.

## Troubleshooting Notes

- Do not convert these requirements into production firewall, Suricata, Snort, Zeek, or gateway rules until a tool version, parser behavior, test PCAP, and expected output are verified.
- Do not use this lab as permission to write to real devices.
- Keep source IP examples and address ranges synthetic unless a reviewed lab PCAP is selected.

## Check Questions

1. Which cards contain write functions?
2. Which card proves that a write response echo is incomplete evidence?
3. Which card is a safety stop rather than a technical troubleshooting step?
4. Which card should be handled as gateway route/path evidence?
5. Why are plain-language requirements drafted before tool-specific syntax?

## Instructor Notes

- Keep the exercise defensive: identify, record, alert, stop, and verify.
- Use Card G to reinforce that the safest action may be not sending a Modbus command.
- Add a Wireshark/PCAP extension only after packet-capture licensing and display fields are verified.
- Add Suricata, Snort, or Zeek syntax only after selected versions are installed, expected outputs are documented, and the [Safety Review Appendix](https://learnmodbus.studioseventeen.io/resource/safety-review-appendix) confirms the exercise remains defensive and isolated.

## Source Notes

- Official protocol source: Modbus Application Protocol Specification V1.1b3 for write function codes and response shape.
- Official security source: Modbus/TCP Security Protocol Specification for TLS and certificate-based security context.
- Defensive security basis: NIST SP 800-82 Rev. 3, CISA ICS guidance, and MITRE ATT&CK for ICS.
- Internal course source: Module 15 lesson, [Threat-to-control worksheet](https://learnmodbus.studioseventeen.io/resource/threat-to-control-worksheet), and [Write-safety checklist](https://learnmodbus.studioseventeen.io/resource/write-safety-checklist).
- Synthetic source: all event cards are course-authored fixtures, not captured traffic.

## Knowledge check

# Module 15 Quiz: Security And Safety
## Questions

1. Which statement best describes classic Modbus TCP?
   A. It normally provides user authentication for each register.
   B. It is commonly plaintext and relies on surrounding architecture for access control.
   C. It encrypts every payload by default.
   D. It proves that every write is physically safe.

2. What does Modbus Security primarily add?
   A. TLS transport protection and certificate-based identity for Modbus TCP.
   B. A universal register map.
   C. Automatic proof that a motor started safely.
   D. A replacement for documenting function codes.

3. Which function codes should receive extra safety and monitoring attention when supported?
   A. `03` and `04` only.
   B. `05`, `06`, `15`, `16`, `22`, and `23`.
   C. `01` and `02` only.
   D. Exception functions only.

4. A function `06` response echoes the requested address and value. What does that prove?
   A. The physical process reached the intended final state.
   B. The server returned the expected protocol-level write response shape.
   C. The command was authorized by plant procedure.
   D. The write value is safe for every device.

5. An unknown client writes to a synthetic command register in isolated lab evidence. What is the best learner action?
   A. Ignore it because the response was normal.
   B. Record source, destination, Unit Identifier, function code, address, value, response, and time; draft an alert/escalation requirement.
   C. Run the same write against a production device.
   D. Change word order.

6. Why is a VPN not enough by itself to make classic Modbus commands safe?
   A. VPNs change holding registers into input registers.
   B. VPN access does not authorize specific Modbus commands or prove safe process state.
   C. VPNs make Modbus exception responses impossible.
   D. VPNs remove the need for monitoring.

7. A learner wants to test a write to a live drive setpoint because the dashboard value looks wrong. The process effect is unknown. What should happen?
   A. Stop and complete authorization, precondition, rollback, and independent-verification checks.
   B. Send function `06` and trust the echo.
   C. Increase polling rate.
   D. Try a different Unit Identifier first.

8. Which source boundary is correct?
   A. Tool-specific Suricata, Snort, Zeek, firewall, and Wireshark syntax must be verified against selected versions before release.
   B. Any blog post can define official Modbus write semantics.
   C. A synthetic lab card is captured production traffic.
   D. Modbus Security changes all register meanings.

## Answer Key

1. B. Classic Modbus TCP is commonly plaintext and normally lacks built-in user authentication or command authorization.
2. A. Modbus Security adds TLS and certificate-based identity around Modbus TCP; it does not solve register-map or process-safety semantics.
3. B. These are common write-related function codes and deserve extra monitoring and safety review where supported.
4. B. A write echo is protocol evidence, not proof of physical state, authorization, or safe effect.
5. B. Defensive handling starts with evidence capture and a plain-language alert/escalation requirement.
6. B. A VPN can protect transport access, but it does not authorize specific Modbus functions, ranges, or process states.
7. A. Unknown live write effects require a safety stop before any command.
8. A. Tool behavior and detection syntax are version-specific and must be verified.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | B | A/C invent built-in authentication or encryption for classic Modbus TCP, and D treats transport access as physical safety proof. |
| 2 | A | B invents a universal register map, C overstates physical safety guarantees, and D ignores that function codes still need documentation. |
| 3 | B | A/C include only read functions, and D describes exception responses rather than write-capable operations. |
| 4 | B | A/C/D overstate what a protocol-level write response proves about physical state, procedure, or universal safety. |
| 5 | B | A ignores defensive evidence, C moves a lab finding into production unsafely, and D changes interpretation instead of recording the write event. |
| 6 | B | A/C are false protocol claims, and D removes monitoring despite remaining command and process-risk concerns. |
| 7 | A | B trusts the echo too much, while C/D change unrelated communication settings before authorization and safety checks. |
| 8 | A | B elevates secondary sources above protocol authority, C mislabels synthetic evidence, and D gives Modbus Security semantic power it does not have. |

## Instructor Notes

- Use questions 4 and 7 to reinforce that protocol acceptance is not physical safety.
- Use question 8 to keep detection syntax gated until tool verification.
- Add PCAP or monitoring-tool questions only after the lab evidence is version-pinned.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for write single coil/register shape and echo boundary, write multiple coils/registers quantity limits, mask write register, read/write multiple registers, Modbus Security wraps Modbus/TCP in TLS, Modbus Security certificates and role authorization, Modbus Security TLS requirements, and IANA service name `mbap-s` on port `802`.
- Defensive architecture, monitoring, and operational-risk framing should remain tied to [security-citation-map.md](https://learnmodbus.studioseventeen.io/resource/security-citation-map) primary-source anchors and selected tool evidence before release.

---
_Learn Modbus · learnmodbus.studioseventeen.io · Module 15/16 · v1.0.0 · Exported for offline / agent use._