The most common OT security weaknesses and what we can do about them

Operational technology is where digital meets the physical world. It is the control system making sure the power plant is running, the oil and gas processing offshore is working, that the dairy plant can ship cheese to the store. It is also the medical technology supporting hospitals in giving care, the traffic control systems onboard a ferry, whether autonomous or not. It may even be the internet connected washer in your home, or the coffee machine that notifies you on your cell phone it is time to clean it. 

In this post we talk about security for the more critical control systems, those that have long life times, exist in industrial plants or hospitals - and that would cause great problems in society if they become impossible to trust. Coffee is important, but having power in the outlet you plug in your coffee maker to is perhaps even more so. 

A security architecture for your OT network acts as your blueprint for defense. It defines how various security controls – like firewalls, segmentation, and access controls – work together to safeguard your industrial control systems (ICS) from cyber threats. By design, it should minimize risk to acceptable levels while ensuring operational efficiency. This architecture should be a living structure, informed by regular risk assessments and evolving alongside your OT infrastructure.

I have worked on OT network security across many business sectors and firms. Weather you operate railway support system, oil and gas control systems or water purification plants, the following seem to be common weaknesses. 

A basis for thinking about network security in OT systems has long been the Purdue model. This model separates the OT functions into different layers, generally separated by function and the time scales they operate on. 

• Layer 0: Field devices, such as machinery and sensors
• Layer 1: Regulatory control.This is where we find controllers, terminal units, etc. These units make real-time control decisions based on input signals and send them back to actuators in layer 0. They also communicate with the supervisory control layer above. This layer typically consists of OT specific devices, but may also have some regular control systems running on more off-the-shelf hardware, typically embedded Windows and Linux systems. 
• Layer 2: This layer operates at a slower time scale than Layer 1, and includes supervisory control functions, HMI screens, etc. This is where we find the SCADA system (supervisory control and data acquisition). These systems are primarily off-the-shelf hardware with the same operating systems we commonly see in IT networks; Windows Server, and some Linux based machines. The latter is often appliances where the operator has little administrative access. 
• Layer 3: Operations support systems live here. This can include data analytics, maintenance planning, data historians and optimization solutions. Also here we will see the same hardware and operating systems as we do in IT. 
• Layer 3.5 (DMZ). This is a demilitarized zone separating the industrial network from the corporate network. The purpose of the DMZ is to limit exposure of the industrial network. All services needing to exchange data with the outside world should live in the DMZ. This includes patch servers, application servers, antivirus servers. Also here, the devices are common IT systems. 
• Layer 4 and 5: enterprise IT functions. Layer 4 is sometimes used to describe ERP and business systems that integrate with OT systems via the DMZ, and layer 5 is the general IT system. For the purpose of secruring the OT Networks this distinction doesn’t matter much, since we tend to draw the line of the “OT scope” at the IT/DMZ firewall. 

For a good introduction to the Purdue model and its history, ZScaler has written a good overview post: What Is the Purdue Model for ICS Security? | Zscaler. 

Often we see networks implementing some of the principles of the Purdue model, without thinking too much about zones and security enforcement. One such example is to include a DMZ between enterprise IT and the OT network, but where the network inside the OT zone is flat. This is still better than not having any separation between the environments, or a separation with a firewall but without the DMZ.

Chinks in the Armor: 3 Common OT Network Security Weaknesses

Here are three common security weaknesses that can leave your OT network vulnerable:

1. Lax Access Controls: Just like the key to your house, access controls determine who can enter your OT systems and what they can do once inside. Weaknesses here include default passwords, lack of multi-factor authentication, and excessive user privileges. Imagine everyone having a master key to the facility - a single compromised account can wreak havoc.
2. Breaching Network Segmentation: Think of your network as a castle with different zones. Segmentation creates firewalls between these zones, limiting the spread of any attackers who sneak in. If these walls are poorly built or have hidden passages (unmonitored connections), an attacker can easily bypass them and roam free within your OT network.
3. Low Detection Capability: An army needs scouts to spot enemies. OT systems often lack robust monitoring and logging capabilities, making it difficult to detect suspicious activity. Without these tools, you might not even know an intruder is present until it's too late and your operations are disrupted.

There are many factors contributing to weaknesses in OT networks, but a primary driver for fragility here is complexity. Not only are there many different systems that are being interconnected, there is also a lot of complexity in the organizations engineering and operating the systems. Supply chains are deep, and the level of collaboration is often not ideal. 

There is lots of guidance for how to secure OT networks, with perhaps the IEC 62443 standard being the most used and accepted. The problems we see are not there because there is no guidance on what good practice looks like. The problems we see exist because of complex value chains, lack of oversight, unclear responsibilities, and a lot of technical debt for historical reasons. While using IEC 62443 is ideal, you may want some quick wins until you get bigger initiatives to bear fruits, and typically getting an overview of the systems you have in your plant, taking stock of the risks and planning some mitigations can take you a big step forward in security maturity. Here’s a post I wrote about how to get started in 2022: Impact of OT attacks: death, environmental disasters and collapsing supply-chains – safecontrols. 

Let’s consider the 3 pitfalls from above in some more detail: 

Lax access control

There are three common problems with access control and privileges: 

• Shared credentials, reused across systems and known to many people including service providers. Make sure those passwords are changed and set up a system to manage and rotate credentials. 
• Admin accounts, applications and users being logged on as administrators. This is dangerous if an attacker takes control as it makes many post exploitation steps much easier, including further reconnaissance, dumping memory and lateral movement. Set up standard accounts for applications and users, and work with vendors to make this happen. 
• Weak authentication protocols are still common in OT. Weak passwords (admin123) and lack of MFA is often found. Use centralized identity management, and apply stronger authentication practices when possible. 

Breaking network segregation

Network segregation is an effective security control against lateral movement. The firewall can help you stop an attacker from moving from a low criticality system to a high criticality system. Some common weaknesses here include: 

• Wide security zones mixing systems of different functionality and with different security requirements. Then there is no segregation between functions. Follow IEC 62443 guidance for creating zones: don’t allow comms between systems where this is not necessary, and use risk assessments to determine the security levels required. Apply firewalls between zones, at least of different security levels. 

A security level target (SL-T) is a concept in IEC 62443 where a zone is given a target security level from 1-4, with 1 being the least restrictive, and 4 being most restrictive. There are then different requirements to the systems based on the SL-T. 

• Security policy bypasses are common, with multi-homed devices, firewall rule exceptions, 4G/5G based backdoors, etc. Make sure to control where data can flow, and avoid ad-hoc or non-routed connections. Multihomed devices present a particularly common challenge. Here’s some input on that: avoid it if you can, manage it if you must: Secure Multihomed Devices in Control Networks: Managing Risks and Enhancing Resilience – safecontrols.

Low detection capability

Observability and detection engineering is often a neglected area in OT systems. Many operators rely on antivirus, without forwarding alerts to real-time monitoring. This makes it possible for an attacker to stay undetected in the network for quite some time, even if the technology detects suspicious activity. It doesn’t help if nobody notices. To remedy the problem, take steps to make staying undetected in the OT network hard: 

• Turn on audit logging on all servers and send logs to a centralized analysis station. Create rules for alerts based on collected logs, and make sure someone notices and looks at them. 
• Use security features on existing systems to improve detection capabilities. Modern firewalls often have a lot of security capabilities, if you already have them, use them. 
• Identify your detection gaps. Create a threat model, and assess your ability to discover the different events you can expect to see in your systems. Then you can plan how to mitigate it over time.

Words about priorities

Prioritization is important, and not always so easy. The weaknesses described in this post are quite common, and may be a good place to start. These weaknesses typically lead to exploitable vulnerabilities. The good news is that the remedies are not expensive, although they can be more difficult than they seem due to organizational constraints.

When prioritizing, make sure to take both the internal and external context into account.

• What are the risk factors? Thinking about cybersecurity risk, we need to combine the threat actor interests with the system characteristics we want to protect, and the potential vulnerabilities to understand where we are exposed.
• Is the process ready for improved security? Do we have control over necessary data links, avoiding unnecessary manual steps or complex architectural setups?
• Does the organization have the motivation and capacity for change?

We need all of these to help us decide which security measures we will implement. Forcing more security than the organization is ready for, will likely lead to production upsets and inefficiencies. My latest safecontrols post is devoted to this topic - you may find some good tips there for prioritization and decision support: The security sweet spot: avoid destroying your profitability with excessive security controls – safecontrols.