Operational technology security protects the systems that run a process: controllers, HMIs, engineering workstations and the networks between them. The work is segmentation, visibility and controlled remote access. Physical protection of panels and control rooms is part of the same boundary, not a separate project.
A plant network usually grew rather than was designed. A controller here, an engineering laptop there, a wireless bridge added during a shutdown, and a vendor connection left open since commissioning. OT security starts by finding out what is actually connected and how it talks.
That inventory is the basis for everything else: where to segment, what to monitor, and which remote paths to keep, close or replace.
Based in Westminster. Serving Denver and clients across Colorado. See all Colorado service areas.
Why IT and OT security are not the same
Office security optimizes for confidentiality and can afford to interrupt a device in order to patch it. A production line optimizes for availability, and a reboot during a batch can cost more than the vulnerability it fixes. That difference changes the design: passive monitoring instead of aggressive scanning, patch windows tied to shutdowns, and changes rehearsed before they reach the plant.
The people are different too. The controls engineer owns the process, IT owns the network, and neither owns the seam between them, which is exactly where the exposure usually sits.
Segmentation that follows the process
The widely used model is zones and conduits: group assets that share a security requirement, then control the paths between them. In practice that means separating the process control network from the business network, and then separating safety systems, remote I/O and the vendor access path from each other.
A firewall between zones, with rules written from the traffic that actually exists, is the usual tool. A flat network with a firewall placed on top, and rules that permit any to any, is a diagram rather than a control.
- Zones defined by function and criticality, not by building layout.
- Conduits that permit only the protocols and hosts that must cross.
- Safety and protection systems on their own segment.
- Wireless links and vendor connections treated as the boundary they are.
Passive visibility before active scanning
You cannot protect what you cannot see, but active vulnerability scanning can upset controllers that were never designed for unexpected traffic. A span port on a core switch, or a network tap, gives a device inventory and a picture of which hosts talk to each other without touching a programmable logic controller.
From that baseline the plant gets the two things it needs: a list of assets with firmware versions, and a record of new or unusual communication. Both are useful without a single probe into the process.
- A passive sensor on a span port rather than an agent on a controller.
- An asset inventory built from observed traffic and confirmed by the controls engineer.
- Baselines for expected communication, so a new peer stands out.
- No active scanning without an agreed window and a rollback plan.
Remote access for vendors and engineers
Remote access is the most useful and the most abused path into a plant. A vendor who is needed during a breakdown is a real requirement. A permanent virtual private network account with a shared password is not the way to meet it.
The pattern that works is a jump host inside the OT zone, accounts tied to named people, multi-factor authentication, a session record, and access enabled when it is needed rather than standing open. It also needs a plan for the case where the vendor cannot connect and the line is down.
- Named accounts rather than shared vendor logins.
- Multi-factor authentication on every remote path.
- Sessions recorded, with a record of who was connected and when.
- Access switched on for a purpose and switched off afterwards.
Physical security is part of the boundary
Controllers sit in cabinets, and cabinets sit in rooms. A panel left unlocked in a public corridor is a network port that anyone can reach. Control rooms, server rooms and electrical rooms should have controlled access, door monitoring and camera coverage, and network ports in production areas should be managed rather than live and unlabeled.
This is where physical and cyber security meet, and it is usually the cheapest part of the risk to close.
Related:Industrial security servicesIndustrial physical security
Patching, change windows and documentation
Patching follows maintenance, not the calendar. The work is deciding which devices can be updated in a window, which need a vendor present, and which will never be patched and so need compensating controls around them. Documenting that decision is worth more than a policy promising quarterly updates nobody follows.
Backups of controller logic and HMI configurations get the same treatment. An engineer with a known-good program is a recovery plan. A plant with none is looking at a rebuild from paper.
- A device list that records firmware, owner and patch route.
- Change windows agreed with production, not assumed.
- Known-good backups of logic and HMI projects, stored offline.
- Compensating controls written down for devices that cannot be patched.
Frequently asked questions
Will network monitoring disturb our process?
A passive sensor on a span port reads a copy of the traffic and sends nothing back to the controllers, so the process sees no change. Active scanning is the tool that can disturb older equipment, and that is why it needs an agreed window.
Do we have to replace our control system?
Rarely. Most of the risk sits in how systems are connected and who can reach them, and segmentation and access control can reduce it around equipment that will be in service for years. Replacement becomes the answer when a device can no longer be supported at all.
Is this the same as our IT security?
No. It covers the same kinds of threat, but the constraints are different: availability comes first, patching waits for maintenance windows, and the equipment may be older than anything in the office. The two programs need to talk to each other at the boundary.
Who should own the OT network?
The plant, with IT as a partner rather than as the sole owner. Controls engineering knows which traffic matters, IT knows the network, and the vendor access path usually belongs to nobody until an incident makes the gap visible.