There are slight differences between information technology (IT) and operational technology (OT) security operations that must be considered when understanding IT and OT differences.

Twenty years ago, the demarcation between IT and OT was clear. IT was in the office, and controls engineers did what they wanted. The differing status was that a remote server was not going to restrict a robot, and safety systems could not be done remotely. This is not always true any more, as many components and systems are on the IT side or tied into it. The SANS Institute— SANS stands for SysAdmin, Audit, Network, Security—has outlined some controls for the OT side of the house.

SANS lists five controls to be concerned with. The following applies:

1. Incident command must incorporate safety protocol based on manufacturing and operational continuity.
2. Architecture should include zones for industrial defense areas and segmentation.
3. OT protocols should only be passively monitored for visibility.
4. Vendor management and remote access procedures should be scrutinized.
5. Vulnerability management should be prioritized off more than the National Institute of Standards and Technology (NIST) Common Vulnerability Scoring System (CVSS).

How does that affect machine builders? It won’t be expected that end users will have a network protocol and a switch protocol and some kind of standardization on PLC addressing and subnets, and remote logins will be more tightly managed as that crosses over into information technology as opposed to operations technology.

It also means the old-school person who wants a 10K engineering station needs to understand that local copies of PLC programs are not viable any longer. It also means that controls engineers must know the demarcation point between IT and OT. The result: programming is harder due to access, not just functionality.

Thus, the integrator or machine builder should understand that there is one more group to deal with when bidding a project and installing a machine. Gone are the days of popping up a switch in the control room and thinking no one would notice. Gone are the days of an indefinite logon to a server back door to troubleshoot the PLC via remote desktop or a machine image at your convenience.

Let’s talk about it in manufacturing machine speak.

Incident command and safety: Can you control the machine safety as far as actions like no chemical spill, no hurt personnel, no explosion if someone takes control of the PLC? How can a PLC know if it’s got a bad actor?

Get your subscription to Control Design’s daily newsletter.

1. Log machine logons. Log when there are events after hours or if there are trends that are broken. People have behavioral habits. They log on at the same time every day. They drink coffee at the same break time.
2. Make the machine network easy to interface with the plant intrusion detection system. Are there ways to watch configurations of the unauthorized protocols? If your machine is a CIP network and you start picking up Profinet protocols, it should raise suspicion.
3. Make the machine defensible. Use up-to-date hardware. Predetermine how people will access the machine. This includes limiting who has access to the engineering stations and the historians. Implement an OT firewall to mirror the IT firewall. Create a cyber plan like safety matrices and outline principles, network segmentation, monitoring and access control. Do not allow direct connectivity. And use redundancy in the machine network if applicable.
4. Remote access is a given and privileged door to the machine, but it should be with boundaries. Remote server with a logon and privileges should literally restrict the user to an access location, and that’s it. Time out the access and the privileges.
5. Reduce vulnerabilities by regulating physical cyber machine locations under lock and key, not allowing thumb drives, restricting remote access to people that need it.

How would an end user start? The first step is developing a response to a machine hack. In doing so, a vulnerability list would emerge that can be tied to specific activities to reduce those vulnerabilities. The risk measures need to be analyzed for feasibility and costs, and then you can prioritize implementation.

Another key component to a security plan is having the OT and the IT crews interact so that demarcations and responsibilities are understood. IT guys won’t know machine boundaries, but they can speak protocols. OT guys will know if a PLC is putting out signals that IT may not recognize or if there are physical activities going on in the PLC that don’t match the HMI or the physical world. The OT people probably know the operators’ names, as well.

Either way, reading through the cyber speak at a machine-builder, integrator or end-user level is cumbersome. Most controls engineers like practicality and not fuzzy logic with magic numbers. It is easy to put out what should be done, but many folks do not know how to apply the vagueness of network speak to the plant floor. The end users and equipment buyers need to know what the company expects, and then they can communicate it to the integrators and machine builders.

Where is there more information? Industrial-specific defenses and practical implementation can be found with SANS. NIST has regulatory guidance and framework categories. ISO 27001 is about documentation. NERC provides CIP requirements for electric utilities. FDA 21 CFR Part 11 demonstrates guidelines for pharmaceuticals. IEC 62443 lists security levels.