OT vs IT security: learn ICS through a small process lab

A login alert on an office application raises questions about accounts and data. A change to a pump controller raises another question first: what is the process doing now? The same network event can have very different consequences depending on the equipment at the other end.

Operational technology, or OT, includes systems that monitor or control physical processes. Industrial control systems, or ICS, are part of that wider category. Learning OT security means connecting digital activity to the process it can affect. A simulated tank is a useful place to start because you can follow the signal, the decision, and the physical consequence without touching a real facility.

NIST SP 800-82 Revision 3 addresses OT's performance, reliability, and safety requirements. As of 9 October 2026, Revision 3 is the published final guide; Revision 4 is listed as a draft. Check the publication status when you return to the guidance.

How OT and IT security differ

IT and OT both need confidentiality, integrity, and availability. Their operating context changes how those goals are balanced. An industrial system may have timing constraints, a long service life, or a tightly controlled maintenance window. A security change that interrupts a process can introduce its own risk.

That does not make “availability always comes first” a complete rule. A controller staying online with incorrect logic may be dangerous. Ask what correct and safe operation requires in the particular process, then evaluate how a cyber event could interfere with it.

Use the table as a set of questions, not a universal split. A hospital IT outage can affect safety. An industrial historian can contain confidential information. The boundary between categories should help you understand the system rather than hide its dependencies.

Learn the components in one small process

Imagine a training simulation in which a pump fills a tank. A sensor measures its level. A programmable logic controller, or PLC, receives that measurement and runs the control logic. A human-machine interface, or HMI, displays the state to an operator. An engineering workstation can configure the controller, and a historian may retain measurements over time.

This is an invented teaching model. It omits many details of a real installation, including redundant equipment, independent protective systems, and operating procedures. Its purpose is to make a few relationships visible.

Before looking for a flaw, write down what each component does. Which value is measured? Which value is requested by an operator? Which device decides whether the pump runs? A display reading and the underlying process state may not be the same thing.

Build a small asset inventory before testing

A list of IP addresses gives you locations but little process context. For the simulated lab, record each component's role, the system it talks to, and the consequence of losing or changing that connection.

The 2025 joint asset-inventory guidance from CISA and partner agencies provides a foundation for identifying and maintaining OT assets. For this beginner exercise, expand your inventory with the device owner, operating role, relevant software version, and important communications. Mark unknown information explicitly.

In a simulation, the lab description and configuration can provide much of this evidence. In a real facility, discovery methods require coordination with the people responsible for operations and device behavior. A scan that worked in an ordinary IT environment should not be assumed suitable for every industrial device.

Investigate one simulated setpoint change

Set up the exercise with a normal operating baseline. In this invented model, the tank's requested level is 60 percent, the pump changes state according to the controller logic, and the HMI displays the measurement. Record a short period of ordinary behavior before changing anything.

Now introduce a change through the simulation's documented controls: adjust the requested level from 60 to 75 percent. Capture the operator action, controller acceptance, pump command, and level trend. The numbers are illustrative and should not be treated as operating limits for real equipment.

09:10:00  Operator requests setpoint 60 → 75
09:10:01  Controller accepts the requested value
09:10:02  Pump command changes
09:10:20  Simulated level trend begins to rise

Questions:
Who requested the change?
Which control allowed it?
Does the process response match the requested change?
What evidence would distinguish an authorized action?

Repeat the exercise with an account that should only observe the process. Predict the result before using the same documented control. The observer should be unable to change the setpoint. If the simulator permits it, record which permission decision failed and how the process responded.

This connects naturally to a two-account authorization test. The method is similar, but the consequence is a changed process value rather than a private document response. Keep the exercise inside the simulator and use its reset procedure afterward.

Read network evidence alongside process evidence

A packet capture may show that a message was sent. It does not, by itself, establish why it was sent or what the equipment did with it. Put the network event beside the operator record, controller state, and measured trend.

Begin with a timeline. Check time zones and clock differences before concluding that one event caused another. Label observations separately from your interpretation: “the setpoint changed at 09:10” is different from “a remote session caused the change.” The second statement needs evidence connecting the actor and operation.

Use MITRE ATT&CK for ICS to learn vocabulary for adversary behavior. Its matrix includes process-focused behaviors such as manipulating control and impairing process control. A technique label is a way to organize observations; it does not prove the cause or identity behind a lab event.

For the tank exercise, finish with three short statements: the digital action observed, the process response observed, and the remaining uncertainty. For example: “The observer account submitted a setpoint change. The simulator accepted it and the level rose. We have not checked whether other control actions enforce the same permission.”

Keep the learning environment separate from operations

A useful beginner OT lab has a known starting state, synthetic process data, a documented reset, and no route to an operational plant. Use the simulator's intended controls and captures. Practice describing the impact of a change before escalating the complexity of the exercise.

When you review a training platform, ask what is simulated, what is emulated, and which behavior the exercise actually represents. A realistic-looking diagram does not establish that a lab models a controller's timing or failure modes. Record those limits in your write-up.

The next exercise can focus on visibility: make the HMI display differ from the underlying simulated value, then work out which independent evidence exposes the mismatch. Another can focus on recovery: identify the known-good state, reset the simulation, and verify that both the control setting and the process trend return to baseline.

Explore VulnOS's OT/ICS training overview for the platform's industrial-security focus. If you are new to practical security work, the first-month lab plan gives you a notebook method you can also use here.

Questions about learning OT security

Are OT and ICS the same thing?

OT is the broader category of technology interacting with physical processes. ICS refers to industrial control systems within that category. A training exercise should identify the particular system it models rather than treating every OT environment as interchangeable.

Do I need a physical PLC to start?

A simulator can teach component roles, process context, timelines, and permission boundaries. Physical hardware introduces device-specific behavior and handling requirements. Start with a simulation whose limits are clear, then choose hardware when it serves a defined learning objective.

Does a successful IT security test transfer directly to OT?

The reasoning may transfer, but the test method and operating impact need review. Device behavior, process state, maintenance constraints, and safety responsibilities affect what is appropriate. Use an isolated exercise to learn those differences before considering operational work.