Recommended resources
The freely available resources this lesson will direct you to.
Welcome. This course begins with a diagnostic rather than a technical deep dive. Across six modules, you will move from cyber-physical fundamentals to architecture, network defence, workstation security, incident response, and an integrated investigation. Before that work, it helps to establish what you can already explain and do—not merely which terms you recognise.
In this lesson, you will take an ungraded OT baseline assessment, mark it consistently, and turn the results into a learning-gap checklist. Your networking and security experience may transfer well in some areas; the diagnostic is designed to show where industrial processes and operational constraints change the reasoning. Allow about 40–45 minutes. Do the assessment before viewing the diagrams or video below so your result remains a useful baseline.
1. Record an honest baseline
Use a blank document or notebook. For each question, record your answer and a confidence rating: 0 = guessing, 1 = partly confident, or 2 = confident. If you do not know, write “unsure”; that is more informative than looking something up. For short answers, a few precise sentences are enough.
The following scenarios are fictional assessment prompts, not observations from a live industrial system. Do not use scanning or control commands against any real OT equipment.
Baseline assessment — stop before the answer guide
1. Closed-loop control — choose one. A tank-level sensor reports a measurement to a controller, which decides whether to run an inlet pump. Which component directly changes the physical process?
A. Historian · B. Pump actuator · C. HMI display · D. Engineering workstation
2. Operational priorities — choose one. A critical process is running safely, but its controller has an unpatched vulnerability. Which is the best initial security response?
A. Reboot it immediately to install the patch. · B. Disable all controller communications. · C. Assess process consequences, exposure, vendor guidance, and a safe change window with operations. · D. Treat patching as unnecessary in OT.
3. Asset roles — choose one. Which pairing is most accurate?
A. Engineering workstation: changes controller projects; historian: stores time-stamped process data. · B. Engineering workstation: measures tank level; historian: drives the pump. · C. HMI: replaces all controller logic; PLC: displays production reports. · D. RTU: is always a corporate database server.
4. Architecture — choose one. In a simplified Purdue-style diagram, where would you ordinarily place physical sensors and actuators?
A. Enterprise planning layer · B. Industrial DMZ · C. Physical process layer · D. Supervisory layer
5. Protocol reasoning — choose one. In an authorised lab capture, a new Modbus TCP write request appears from an engineering workstation to a controller. What can the packet alone establish?
A. The sender was an attacker. · B. A write operation was requested; its intended and actual process effects require more context. · C. A safety shutdown definitely occurred. · D. The traffic was harmless because the workstation is trusted.
6. Trust boundaries — choose one. A vendor needs temporary access to one OT engineering workstation. Which design best limits the access path?
A. A permanent direct VPN into the controller network. · B. A shared account on every OT host. · C. Approved, time-limited access through an intermediary with access restricted to the required destination. · D. An unrestricted route from the enterprise network.
7. Traffic and process impact — short answer. A supplied, simulated capture shows a previously unseen host sending a controller write request. Name two further pieces of information you would seek before stating that the write changed the physical process.
8. Safety-aware response — short answer. Operators report inconsistent HMI readings while a process remains in service. Name one immediate coordination action and one reason not to disconnect the controller impulsively.
9. Evidence and confidence — short answer. A simulated IDS alert says “possible unauthorised controller change,” but no controller configuration has been collected. State one observed fact and one conclusion that must remain a hypothesis.
10. Risk and governance — short answer. Two identical, outdated workstations exist: one is an isolated training machine; the other is used to maintain a production controller. Name two factors beyond software age that would affect their remediation priority.
11. Windows investigation — short answer. Name two read-only things you could collect from a Windows engineering workstation to begin a host baseline. PowerShell commands are welcome but not required.
12. Safe lab practice — short answer. Before relying on a newly installed training platform for a PLC-to-HMI exercise, name two capabilities or conditions you would verify on your installation, rather than assume from a demonstration or feature list.
Pause here. Record all twelve answers and confidence ratings before continuing. Do not revise the baseline after reading the guide; put later corrections in a separate column.
2. Mark the result, without treating it as a verdict
Give one point each for questions 1–6. The keyed choices are 1 B, 2 C, 3 A, 4 C, 5 B, 6 C.
For questions 7–12, award one point for each distinct criterion met, up to two points per question:
| Question | Two credit-worthy elements |
|---|---|
| 7 | Evidence of what value or command was requested, such as the address, value, and response; and independent context such as tag mapping, controller state, historian data, or physical/process telemetry. A response packet alone need not prove a physical change. |
| 8 | Coordinate promptly with the operator or responsible OT engineer to establish the process state; and recognise that disconnecting a controller could remove visibility/control or disturb a running process. |
| 9 | The alert was generated—subject to checking its underlying data—is an observation; and an unauthorised controller configuration change remains unverified until corroborated. |
| 10 | Any two of: process criticality, reachable attack paths, safety consequences, operational dependencies, available compensating controls, recoverability, or a feasible maintenance window. |
| 11 | Any two distinct read-only baseline categories, such as running services, local accounts, network listeners, firewall state, scheduled tasks, or relevant event logs. Valid examples include Get-Service and Get-NetTCPConnection run on an authorised Windows host. |
| 12 | Any two relevant checks, such as isolation and network exposure; installed-edition/licence limits; actual PLC and HMI availability; end-to-end tag visibility; safe state restoration; or restart, persistence, and reset behaviour. |
Your maximum is 18 points. Keep the raw answers: a single total hides important differences. Someone who correctly names a protocol operation but cannot connect it to process evidence needs a different next step from someone who struggles to recognise the operation at all.
Also flag every confidently incorrect answer. That combination is especially useful: it identifies an assumption worth testing early. A correct answer marked confidence 0 is not yet a dependable working skill.
3. Locate the gaps in a real control-system picture
Now use the resources to check your mental model. The diagrams depict representative arrangements, not an inventory of your lab or a claim that every facility is built this way.
In Closed control loop, follow the solid connections around the process. Notice the difference between a measurement reaching the controller and an actuator actually moving equipment. The HMI can present process information and allow authorised changes, but it is not itself the pump or valve. The dashed maintenance connections deserve separate attention: access useful for diagnosis can also create a security-relevant pathway.
In Typical ICS architecture, look for where the control centre ends and each field site begins. A central HMI, historian, and engineering workstation serve different purposes, while communications links introduce dependencies and trust boundaries. The drawing does not establish that a particular link is secure—or that losing it necessarily stops local control. Those questions require evidence about the actual design.
For a short explanation linking these components to physical equipment, watch selected portions of Mike Holcomb’s Getting Started in OT/ICS Cybersecurity 2026 (Module 3): PLCs, HMIs, and Others Explained.
Getting Started in OT/ICS Cybersecurity 2026 (Module 3): PLCs, HMIs, and Others Explained
Mike Holcomb explains how a PLC connects networked systems to sensors and machinery, then how an HMI gives operators visibility and a means of interaction. Use the clips to test your answers to questions 1, 3, 7, and 8—not to overwrite your original responses.
Watch the PLC bridge, from the introduction of the PLC through its inputs, outputs, and programming languages. Then watch the HMI role, from its introduction through the description of communication with the PLC. Focus on what each component knows, what it can change, and why an interface reading may need corroboration.
A useful distinction emerges: network evidence, controller evidence, and physical-process evidence answer different questions. A packet may show that a request was sent. Controller records may show whether a value was accepted. Process measurements and operator observations may help establish whether anything physical changed. You will practise that distinction repeatedly in later modules.
4. Convert the score into a learning-gap checklist
Assign each question to the area below. Mark an area Priority if you missed a question, guessed correctly, or answered confidently but incorrectly. Mark it Developing if you were partly confident and correct; mark it Starting strength only when you can explain your correct reasoning confidently. This is a planning label, not a professional certification level.
| Area | Baseline questions | What you should eventually be able to demonstrate |
|---|---|---|
| Process and control-loop fundamentals | 1, 7 | Trace a measurement, control decision, actuator action, and physical outcome without conflating them. |
| Safety and operational constraints | 2, 8 | Explain why a security action needs an operational and safety review. |
| OT assets and architecture | 3, 4, 6 | Distinguish asset roles and identify a consequential access boundary. |
| Industrial traffic interpretation | 5, 7 | Separate a protocol operation from its alleged process effect. |
| Investigation and evidence confidence | 8, 9 | Separate observations, corroborated conclusions, and hypotheses. |
| Risk prioritisation | 10 | Compare remediation options using process consequence and exposure, not age alone. |
| Windows host visibility | 11 | Identify safe, read-only sources for a workstation baseline. |
| Lab capability validation | 12 | Verify the installed environment before depending on a live exercise. |
Make your personal checklist actionable rather than writing “learn OT.” Copy this compact record and fill it from your original answers:
Lesson 1 baseline: ____ / 18 Date: __________
Confidently incorrect questions: __________
Correct but guessed questions: ______________
[ ] Priority gap: ______________________________
Evidence from question(s): _________________
Next demonstration I need to perform: ______
[ ] Priority gap: ______________________________
Evidence from question(s): _________________
Next demonstration I need to perform: ______
[ ] Developing area: ___________________________
What I can explain now: ____________________
What I still need to verify: _______________
Starting strength to retain: ___________________
Choose no more than two priority gaps for immediate attention. For example, a gap on question 7 might become “use a tag map and process trend to evaluate a simulated controller write,” rather than “study Modbus.” A gap on question 12 might become “record observed isolation, service, restart, and reset results before selecting a live lab path.” If Windows investigation is a gap, you can keep using your existing Linux and networking skills while deliberately building the PowerShell evidence-collection skill later.
Keep this record for progress tracking. After each module, add a dated note showing whether you can now demonstrate the relevant skill with an explanation or lab artefact. Do not inflate the original baseline score: improvement is clearer when the starting point remains intact.
Conclusion
Your baseline is a map of current evidence about your skills, not a pass/fail test. The most valuable outputs are your raw answers, confidence ratings, confidently incorrect assumptions, and two specific next demonstrations. Keep claims about a process or an installed lab separate from what you have actually observed.
Next, you will examine how OT security priorities differ from familiar IT priorities when a running physical process introduces safety, reliability, availability, and timing constraints. Your checklist will help you notice which of those distinctions need the most attention.