It’s time to revisit the ICS/OT world, as it has unique characteristics that influence its processes and tools.

First, I would categorize this broad field into the following groups:

• Systems localized within a confined area (e.g., a building or campus)
• Systems geographically distributed but accessible through protected/dedicated networks (often SCADA systems fall under this category)
• Systems geographically distributed and connected to the Internet without additional controls (often IoT systems fall under this category).

I’ve chosen this classification because, as we’ll see in the following posts, it dictates our ability to mitigate risks by implementing additional security measures. Clearly, there are other categorizations we should consider (e.g., based on risk), but this is the one I’d like to use as a starting point.

Based on my experience, I want to highlight that most ICS/OT/IoT systems have a longer lifespan than the support period of individual components. This is crucial when planning a realistic strategy. Even though certain regulations require that components be upgradable, we will inevitably face situations where we need to protect components that are no longer sold, supported, or maintained.

Lifespan vs. Support Duration

As previously mentioned, in my experience, ICS/OT/IoT systems often remain operational for longer than the manufacturers of individual components anticipated. In other words, the components (particularly software, but not exclusively) are no longer supported, yet the integrated system is still in use.

Those familiar with the industrial, medical, maritime, or oil & gas sectors (and I’d add banking as well) encounter this daily: systems are based on components (e.g., Windows) and remain active well beyond the end of their support period. This is unavoidable for three reasons:

1. The aforementioned systems are generally untouchable: no changes or updates are permitted because their effects are unknown. In some cases, I’ve had vendors strongly advise against updating IEC62443-certified products, despite the regulation allowing for it.
2. Many of the above systems have a very high acquisition cost (in terms of millions or tens of millions). Decommissioning or even simple refitting incurs unjustifiable costs for a system that is still functional (in the sense that it performs its intended work).
3. I’ve often encountered operational systems supplied by defunct companies, leaving no support available. Here again, the cost of acquiring a new system is unjustifiable.

The three points above mainly stem from the approach of the companies and individuals designing such systems. These systems are built to perform their tasks safely, even under stress. But… when we began discussing Industry 4.0 and started connecting systems designed to work to an IP network, we introduced a new risk: Cyber risk.

In conversations with suppliers and customers of ICS/OT/IoT systems, I realize that Cyber risk is not even considered. To be honest, as a professional, I find some topological choices rather peculiar.

In this regard, manufacturers and integrators still need to fully grasp the implications of bringing fragile technologies (from a Cyber perspective) onto IP and connecting them to the Internet.

Given the topic, I’d add that the regulatory world is moving in a certain direction (see NIS, machinery regulation, IMO…). Will we finally see concrete results? Personally, I’m not so optimistic.

Component Lifespan

We’ve discussed regulations and reality. Now, let’s look at some examples demonstrating that component lifespan will inevitably be shorter than system lifespan. As mentioned earlier, systems continue to be used until they fail and repairs become economically unfeasible compared to purchasing a new system.

Let’s examine a few examples.

Bluetooth

In the ICS world, I’ve noticed a preference for using Bluetooth in recent years to simplify system reconfiguration activities. Specifically, Bluetooth is used to remote some control commands (non-emergency). In this case, we should consider the risks introduced by a wireless protocol, but for now, let’s focus on the various protocol releases. A new Bluetooth protocol standard is released approximately every 2-3 years. This means that in an industrial system with a lifespan of 15 years, we could find very old and potentially vulnerable protocol releases.

WiFi

A similar discussion applies to the WiFi standard, which has been used in ICS for years to manage mobile parts. Regarding security, in just under 20 years, we’ve seen four standards (WEP, WPA, WPA2, WPA3) successively introduced to address security issues.

Today, it’s quite common to find ICS systems based on WEP, where the WiFi network is an extension of the wired field network.

HMI

Even today, almost all HMI systems I encounter are based on Microsoft Windows. Starting from Windows XP, we’ve seen 6 different versions over 23 years, approximately one every 4 years. As before, it’s equally easy to find ICS/OT systems still running on Windows XP.

And as recent history has shown, there are systems with even older versions, released more than 30 years ago, and just because they’re old doesn’t necessarily mean they need to be replaced.

On the other hand, with Ubuntu, which I see fairly widespread, an LTS has a lifespan of about 5 years. Considering that no development is aligned with the latest release, we can assume that a system around 3 years old is already out of support. This doesn’t just impact ICS systems but typically OT and IoT systems as well.

Vulnerability Management

Managing vulnerabilities doesn’t necessarily mean updating. It means managing risk, which can be done by implementing additional security measures to reduce it.

When conducting vulnerability assessments, I generally advise against doing so on ICS/OT parts. Here’s why:

1. ICS/OT systems are extremely fragile, and it’s highly likely (I’d say certain) that a VA activity would negatively impact the systems.
2. ICS/OT systems are generally untouchable. This means that even if vulnerabilities are found, they can’t be mitigated through updates or EDR.
3. As mentioned, ICS/OT systems have a long lifespan, so it’s likely (again, I’d say certain) that we’ll find vulnerabilities due to obsolete systems.

The point I want to make is that in ICS/OT environments, it’s almost certain that there will be severe, unpatchable vulnerabilities. Based on this assumption (which, in my experience, has always been true), we can develop our strategy.

In the IoT world, we can draw similar conclusions, with one complication: IoT systems are generally directly connected to the Internet, with all the associated consequences.

Defense Strategies

We’ve established that ICS/OT systems are vulnerable and unpatchable. In our vulnerability management plan, we can’t rely on patching. Instead, we need to build a series of layers to adequately reduce risk.

First, I’d start with the so-called Purdue model, which provides a foundation for correctly approaching the problem. Generally, there should be no direct traffic from OT networks to IT/Internet networks and vice versa. The conditional “should” is necessary because, in my experience, the Purdue model is often not applicable today. I often find ICS/OT systems that have (contractual, not technical) requirements for direct Internet access.

My approach today is to create a particularly stringent security perimeter around the ICS/OT environment, inspired by the concept of ZTA (Zero Trust Architecture). Specifically, a combination of firewalls and IDS allows me to control access to ICS/OT systems and monitor any anomalies within the networks. It may sound simple, but consider that:

• Many ICS/OT systems reside together on large networks (I’ve seen thousands of IPs on a single 10.0.0.0/8 network).
• What we see isn’t necessarily what’s there (there are numerous 3/4/5G gateways implementing an independent, invisible Internet access point directly into the ICS/OT network).
• In many environments, VPN terminators are installed by contract, enabling remote assistance (and, once identified, these might be the lesser evil).

ICS/OT security, therefore, involves an assessment to understand how chaotic the situation is and what possible paths exist.

Network Segmentation

We’ve seen some critical aspects to consider within a proper security strategy. One, in particular, deserves further discussion, though in most cases, it’s not feasible.

We’ve seen that ICS/OT systems within a company often reside on a single, large network. This means that compromising a single component exposes all systems to the same risk. We also know that ICS/OT systems are untouchable, and changing the addressing scheme isn’t an option. In this case, technologies that allow transparent segmentation of L2 networks can help. Personally, I’ve had experience with the VLAN Insertion feature offered by Palo Alto Networks. Different vendors have similar implementations with the same goal: to segment/micro-segment an L2 network transparently.

The reason I consider this security measure impractical is that the production world is often under the responsibility of the OT Manager, who comes from the OT world, not IT. I notice a certain skepticism, if not fear, when “IT technologies” are proposed in the OT world. The result is that the OT Manager opposes and shifts responsibility for any production downtime to those who alter the topology.

In some cases, I’ve seen people sit down and seek a compromise that satisfies all parties, but in many cases, no one wants to take the risk of changing the status quo, and everything remains the same.

Network Access

Previously, we discussed how to segment ICS networks to reduce the impact in case of a breach. Now, let’s touch on a topic that is both trendy and delicate. The idea behind NAC solutions is to enable network access for permitted devices while keeping out all others. However, there are some important considerations to keep in mind:

• The fact that a device is allowed access does not reduce the possibility of it being compromised;
• Today’s NAC solutions rely on the 802.1x protocol and a series of compromises when this protocol cannot be used.

In the ICS world, most devices (if not all) do not support 802.1x, which necessitates compromises such as MAB (MAC Authentication Bypass). Additionally, it is important to consider the risk posed by “silent” devices, those that tend to receive traffic more than send it. “Silent” devices might require further compromises.

I am not demonizing NAC solutions, but I would like to emphasize that security is built in layers, and NAC solutions are just one layer. Like any security measure, they come with their own impacts. You can find more reflections on this topic in the “802.1x bypass” episode of the podcast I host with podcast.

Code Security

Finally, I want to address a still very niche topic (unfortunately): the security of code in the context of PLCs. We know that some vulnerabilities related to PLCs are caused by how they are programmed. We can address this, or rather prevent it, by writing correct code. This is not my area of expertise, so I will leave you with the Top 20 Secure PLC Coding Practices and encourage you to follow Sarah Flucks on LinkedIn.