OT: ICEFALL Shields Up? The FUD, the Duds, and What to Care About

Recently Vedere Labs released OT:ICEFALL highlighting 56 vulnerabilities that were seen in the assets of 10 operational technology vendors. Perhaps in reading this your heart started racing, your palms grew sweaty, and you were left wondering how this will impact your organization. Well, unless your organization lacks a reasonable cybersecurity hygiene program or your last technology refresh was before the first Obama administration, you can probably breathe easy. Let’s go over what was announced and what it all really means.

First, it’s important to understand that the announced vulnerabilities were discovered by revisiting a 10-year-old research project, called Project Basecamp, which determined that some OT products were “insecure by design.” The Project Basecamp researchers contended that the vendors in question never considered security when they developed various products and protocols, making them inherently insecure.

Since we have been facing this issue for some time now, it’s not much of a revelation. And before we start sweatin’ to the (repackaged) oldies, a fresh look at the “insecure by design” paradigm is worthwhile.

Long-known Vulnerabilities, Common Sense Advice

OT:ICEFALL states that various products from Bentley Nevada, Emerson, Honeywell, JTEKT, Motorola, Omron, Phoenix Contact, Siemens, and Yokogama are susceptible to remote code execution (RCE), denial of service (DoS), firmware manipulation, and credential compromise and authentication bypass attacks.

The report recommended the following mitigation techniques to attend to these vulnerabilities:

1. Discover the devices that are vulnerable
2. Segment your network to isolate these devices
3. Monitor the vendors of these devices for patches
4. Watch your network traffic to make sure there are no exploits

I would argue items 1-3 should be table stakes for any reasonable OT network security operation. You should regularly check your devices for vulnerabilities and identify them. Any reasonably modern OT architecture, whether based in MITRE best practices or just Industry 4.0 convergence awareness, are predicated on segmenting and controlling access to your operational technology devices as well as controlling what other assets those devices communicate with. Regularly checking with the vendors that make the equipment that are critical to the operation of your OT environment for security updates and patches should be a foundational part of any security program.

The Inherent Value of Network Traffic Monitoring

The last recommendation of watching your OT network traffic for irregularities is a relatively new concept for some security vendors. It’s a solid concept, so in my opinion it needs to make its way into all security models. It starts with collecting the information about every frame transmitted and every IP connection established in an environment. Then you need an analytical engine that can cross-reference that data with known exploits as well as determine device behavior abnormalities. And when you can do all of those things in real-time at line rate, then you have true visibility.

To really deliver value, the solution would need to collect this data for every device on the network (cloud or on-premise), not just the OT devices. It would include the IT devices that run common operating systems, the IoT devices running real-time operating systems, and the building management system devices that only put frames on the network. It also should be able to understand all the relevant protocols that these devices natively and regularly use to communicate. The solution needs to understand the context of devices, meaning not what they are but what their function is. For example, a Dell machine running Windows 10 could be a workstation, SCADA server, or multimedia server, so the solution needs to understand the behavior relative to the function. Flexibility, scalability, and the ability to carry out all of these functions in real time is key for maximum effectiveness. Most importantly, the solution would need to be passive, with no active component that could disrupt sensitive devices.

Same Story, Different Day

CISA evaluated the OT:ICEFALL report and determined that out of the 56 vulnerabilities outlined in the document, it should only issue the following five Industrial Control Systems Advisories:

• ICSA-22-172-02 : JTEKT TOYOPUC
• ICSA-22-172-03 : Phoenix Contact Classic Line Controllers
• ICSA-22-172-04 : Phoenix Contact ProConOS and MULTIPROG
• ICSA-22-172-05 : Phoenix Contact Classic Line Industrial Controllers
• ICSA-22-172-06 : Siemens WinCC OA

In the end, OT:ICEFALL did not meet my expectations. For a reboot of a 10-year-old research project, I was let down by the sparse number of impacted devices and 56 vulnerabilities that pretty much have always existed and will continue to exist because of design. OT:ICEFALL is, however, a good reminder and reinforcement that basic blocking and tackling are always fundamental for security programs. At the end of the day, it’s essential to:

• Know exactly what is on your network
• Know its function and behavior
• Understand the communication paths and protocols it uses
• Detect when it is doing something different than what you expect.

And remember, any connected asset is an attack vector for the bad guys. You cannot secure what you cannot see.