Skip to content

15 · SCADA and industrial-control architecture

Depth: developed lesson · Prerequisites: networking, system boundaries · Time: one 90-minute session.

This chapter teaches an original, fictional control-system scenario using public primary references. It is available now; it is not a claim that the private OT books have been distilled or that a physical plant has been tested.

Outcomes

  • Distinguish SCADA, a controller, an operator interface, and the physical process.
  • Trace an attacker’s required access from an enterprise account to a control action.
  • Explain why a valid packet, an accepted command, and a physical outcome need different evidence.
  • Produce an asset-and-flow model with explicit missing information.

The system you are investigating

Imagine a training water tank with a level sensor, an inlet valve, and a controller. The controller receives measurements and determines its outputs. Operators see the process through a screen. Engineers maintain the controller configuration. A separate reporting service stores measurements over time.

This is our teaching model, not an installation design. Its deliberately simplified relationships let you reason about authority before learning a device-specific tool.

Enterprise reporting             Approved maintenance access
         |                                  |
  [report replica]                 [maintenance gateway]
         |                                  |
---------------- reviewed operations boundary ----------------
         |                                  |
    [historian]                       [engineering workstation]
         ^                                  |
         |                            configuration / diagnostics
         |                                  v
       [HMI] <---- readings and commands --> [controller]
                                               ^    |
                                         input |    | output
                                               |    v
                                           [sensor / valve]
                                               |
                                         physical tank

Arrows describe intended information or command paths, not firewall rules. A line in a drawing does not establish reachability, authorization, or a tested restriction.

Vocabulary that changes the investigation

OT covers systems that monitor or affect physical processes. A PLC performs control logic; an HMI presents information and operator controls. SCADA provides supervisory monitoring/control across an installation, while DCS describes a distributed control arrangement commonly associated with a plant. Remote terminal units connect remote measurements and control. A historian retains process data; an engineering workstation supports configuration and maintenance. These roles can coexist, and a product name alone does not establish the actual topology. See NIST SP 800-82 Rev. 3, section 2.

For the fictional tank, assign roles before assigning vulnerabilities:

Asset What the scenario permits Question the assessor must answer
Report replica Display historical summaries Is it a one-way copy or can it influence operations?
Historian Read measurements Can its connection also carry control requests?
HMI Display state and request approved changes Who is allowed to operate it, and where is that checked?
Engineering workstation Maintain configuration How are maintenance identity, time window, and changes recorded?
Controller Execute the training control program Which program and register map are actually installed?
Sensor and valve Measure and change the physical model What independent evidence confirms their state?

Think in attack prerequisites

A useful attack hypothesis names the missing permissions between steps:

  1. An attacker gains access to the fictional reporting host.
  2. That host can reach an operations service.
  3. The service accepts a request with more authority than reporting needs.
  4. A downstream component interprets it as a control action.
  5. The physical process changes in a way the investigator can demonstrate.

Each numbered statement needs evidence. Proving step 1 does not prove step 3. Finding a protocol parser does not prove that the controller accepts a write. A response packet does not independently establish what the valve did.

Now consider a second route: an authorized maintenance account used outside its approved window. Network segmentation may leave that route intentionally available. The investigation must examine identity, maintenance approval, application permissions, and change records together. The interesting boundary is the authority to change the process, not simply which subnet an address occupies.

Availability, integrity, and safety

NIST’s OT guidance treats performance, reliability, and safety as operational constraints. Security changes must be assessed against those requirements; conventional IT actions cannot be assumed appropriate merely because they are routine elsewhere. Read the OT/IT comparison in SP 800-82 Rev. 3, section 2.4.

In our scenario, ask three separate questions:

  • Availability: can the operator obtain a sufficiently current tank reading?
  • Integrity: is the value associated with the correct sensor, scale, and time?
  • Safety: what prevents the training process from reaching an unacceptable state?

An available screen can show stale data. A correctly decoded number can use the wrong engineering units. An independent protective action might work even if the operator screen is misleading. None of these possibilities is resolved by a ping or a screenshot alone.

Lab: build the assessment model

Use a Markdown file, not a live network. Spend 15 minutes drawing the fictional topology and 25 minutes filling in these four records:

Asset: historian
Owner: fictional training operator
Needed capability: read tank measurements
Unexpected capability to investigate: send control writes
Evidence available: synthetic request trace in chapter 16
Evidence missing: actual identity, server decision, physical response
Containment question: can reporting access be removed without hiding operator state?

Then make a flow table with one row for every arrow in the diagram. Record origin, destination, purpose, required authority, evidence source, and the consequence of losing the flow. Mark unknown fields explicitly; do not fill them with product assumptions.

Finally, remove the historian from your diagram. Identify which observations disappear and whether the controller’s assumed local operation changes. Repeat with the HMI. Your answer should depend on the scenario’s stated relationships, not on a universal claim about all plants.

Evidence

Save the topology, six asset records, flow table, and two dependency analyses. Label each fact as scenario definition, observation, or hypothesis. The deliverable proves that you can model a control boundary; it does not prove industrial-device assessment experience.

An acceptable finding is: “The training policy gives the historian read-only intent; the next exercise will test whether observed request functions agree with that intent.” An unsupported finding is: “The historian can change the physical tank,” before a controller decision and independent process evidence exist.

Safety and scope

This exercise uses only a fictional diagram and local notes. It requires no PLC, radio, industrial network, packet transmission, or changes to safety equipment. A future hardware exercise needs its own approved equipment, operating limits, reset procedure, and responsible operator.

Teach-back

  1. Explain the difference between an operator view and the underlying process state.
  2. Name two permissions an attacker would still need after compromising the report replica.
  3. Explain why removing a network connection may affect your ability to observe an incident.
  4. State the exact evidence missing from a claim of physical impact.

Continue: 16 · Industrial protocols and trace analysis. The course coverage map shows other developed lessons and the sections still at outline depth.