There are two general approaches to OT security. One approach is threat-centric and attempts to identify and eliminate cyber threats in OT networks. The other approach is infrastructure-centric and largely doesn’t care about threats. Instead, it attempts to create a robust OT infrastructure that is well protected against the vast majority of conceivable cyber attacks.

In order to understand how infrastructure-centric OT security works, we’ll look at two primary disciplines: Network security, and endpoint security.

OT network security is priority #1

OT products are insecure by design and will stay that way for the next couple of decades. This means even if you would patch each and every known vulnerability of your OT infrastructure, you would still be left with an insecure mess. For PLCs, RTUs, actuators etc., the only way to establish security is via access control. You must be able to prevent unauthorized traffic on the network, and the way to do it is by network segregation.

While this is a very straightforward method, many struggle with identifying good zoning opportunities. Spoiler alert: The Purdue model doesn’t help you here, it may even be counterproductive.

The key to appropriate OT network segregation is to map your OT devices to functional process units such as work cells. This requires the collaboration of process SMEs, and cyber-physical modelling capabilities.

In order to arrive at a proper segmentation architecture, the specific process function of OT devices and networks must be understood. Why? Because at the end of the day, the objective is to limit cost of consequence in case of compromise.

Let’s say you are running six machine lines at a given manufacturing site. What you want to achieve is that in case OT devices of line 1 are compromised, resulting in an outage of this line, the other lines may still continue operation.

Now you see why the Purdue model is counterproductive as a security architecture: A horizontal zoning strategy will allow malware to spread horizontally, affecting all six lines. A vertical zoning strategy, on the other hand, will prevent the malware spread to the other lines.

Bottom line, cyber-physical system modelling of your OT devices and networks is a must in order to arrive at rock solid OT network security. The OTbase OT asset management software provides you with the necessary framework to make it happen – within hours.

The OTbase OT asset management software exposes network topology as associated with functional process entities such as work cells, which yields the best network segregation strategy

OT endpoint security: Security booster if done right

When thinking about OT endpoint security, the default method is patching, with all its difficulties in OT. The reality is, there are other methods that are much more efficient than patching. Examples are removal of unwanted software, and removal of insecure protocols/services (HTTP, Telnet,…).

The key to success though is scoping. This is where most OT asset owners fail. They either favor the idea of patching all Windows computers (how often?), or single dedicated systems that are picked more or less anecdotally. Neither strategy will yield breakthrough results.

The only way to succeed in OT endpoint security is to specify groups of devices that are subject to the same set of endpoint security measures, and to assure that such measures are applied consistently, including new devices that are connected to process networks.

If you wanted to single out devices that deserve better protection than others, based on individual analysis, it would be much too time consuming. Efficiency is key in OT security, and the path to efficiency is to define group policies. (When we talk about group policies here we need you to abstract from Microsoft Windows and Active Directory. Just think about a group of devices that are subject to the same policy.) Sample group policies are:

  • “This group of devices must be patched at least once per quarter.”
  • “This group of devices must not use outdated operating system versions.”
  • “This group of devices must not use Telnet.”
  • “This group of devices must not have Adobe Flash Player (or VNC, or other unwanted software) installed.”
  • “This group of devices must not carry known vulnerabilities (CVEs) with known exploits.”

When it comes to defining such “groups of devices”, one would logically use criteria that indicate specific criticality. Meaning that if such a device gets compromised, consequence will be bad. Another aspect would be to cover devices that are more exposed to untrusted traffic and users than others.

The OTbase OT asset management software makes it extremely simple to set up your group policies, and to execute automatic compliance audits. First you define a set of properties that qualify your result set. This could be device type, network connectivity, geolocation, process association, you name it. A couple of clicks get you there.

The OTbase OT asset management software lets you filter for complex contextual criteria such as network connectivity and network type. The result set can be piped into policy definitions, and is updated automatically when configurations change.

Than you slap a policy on the result set, using criteria such as prohibited software. Done! You will then automatically see non-compliant devices along with their specific details. Open a change case for those devices, done.

A policy profile in OTbase exposes non-compliant devices. The timeline gives a graphical representation on how well you’re doing with your compliance efforts.

Policies are such a powerful tool for OT endpoint security because they start with the definition of how things should be configured, rather than trying to catch anything that might be deemed insecure. They are a true efficiency booster.

Why not do both infrastructure-centric and threat-centric?

These days, when you discuss the advantages of a certain approach over another on social media, five minutes later someone argues that BOTH approaches have their merits and should be done together. So, sure enough this will also happen to the discussion of threat-centric vs. infrastructure-centric OT security. It would only expose uninformed reasoning though.

A threat-centric approach could make sense if we would see real-world cyber-physical attacks every other week. Which we don’t. If the hackers have other things to do and couldn’t care less about cyber-physical systems, a threat-centric OT security approach doesn’t yield any value. Where there’s nothing to detect, investments in detection are a waste of resources. And even more than you think: Any ICS Detection solution won’t show nothing in the absence of actual attacks. It will still produce dozens of alerts. It will show you traffic that could indicate malicious activity but actually does not. Which you only find out after an analyst worked the case for several hours.

Bottom line, from an ROI perspective, infrastructure-centric OT security yields a much better return on investment than a threat-centric approach as long as actual cyber-physical attacks remain unicorns. Best of all: If you invest in infrastructure-centric protection, you can make sure that it stays that way.

To learn more about the OTbase OT asset management software, check