It’s the kind of story many of us grew up hearing: “Someday, your fridge will know what you need from the store before you do.”

We didn’t worry about things like firmware or attack surface. Now, the Internet of things (IoT) enables both today’s devices and potential attacks.

Today, some fridges do know what food you need to buy. Your doorbell has strong opinions about the company you keep. We’re all one spoken request away from getting the answer in a trivia debate. But, this is just an extension of what’s been happening in the workplace.

Operational technology (OT), IoT and Internet of Medical things (IoMT) have been shaping productivity for decades, and each device is becoming ‘smarter’ with every release. More and more, employers are asking security professionals to secure all these devices. This means bringing them into the world of IT and including them in our vulnerability management programs. Hop aboard this tour of this vast new sea of ours.

Uncharted Waters of IoT

The very first challenge on any IoT expedition, which we’ll call this voyage while also including OT and IoMT when we say it, is to locate and catalog the devices themselves. No surprise, then, that IoT scanners like X-Force for IoT, Nozomi, Cylera, Tenable.ot and Qualys IoT all use passive scanning. This type of scanning is actually listening — just like the microphones on a submarine — and it requires that we connect the solution to a place in our network where it can ‘hear’ everything. This is called a mirror port, a monitor session or a network tap depending on the vendor and context. These solutions earn their keep early on just by finding and fingerprinting IoT devices based on their signatures.

Why call it passive scanning? IoT devices are fragile; They might wither if we send them the barrage of active requests that come with IT scanning. Ever see a printer spew reams of paper with nonsense on it? You can thank your friendly neighborhood scanner for that one. In a real submarine, the word ‘ping’ comes from the sound of sonar bouncing off the craft. IoT devices are in that tricky ‘important but fragile’ zone, and this kid-gloves approach separates IoT scanners from their brethren.

Once found, the IoT scanner inspects the device’s traffic and compares it to its own database of profiles to determine what kind of creature it’s dealing with. With a positive hit, the system will then cross-reference the device’s profile with known risks for the version of IoT firmware detected.

New Meets Old

This represents a departure from other types of scanning; instead of measuring how a device responds, passive scanners observe what a device does. In essence, the modern IoT scanner is more like an intrusion detection system, and indeed some solutions actually attempt to block bad behavior, putting them into the intrusion prevention system bucket. There are pros and cons to this. By listening, we learn more about the system, and we’re more likely to positively identify it. On the flip side, we might not be able to detect all its open ports unless we directly see another system connect to it.

This is all well and good for modern, network-connected IoT, but what about scary old OT devices lurking in the depths? These beasts use technologies from the heady days of SONET rings and serial connections. It very much depends on how the system manages these things. Most of the time, the best you can hope for is the detection of a human-machine interface (HMI) that is relatively up to date. Like an octopus, these systems have several tentacles connected to sensors, valves, pumps and other OT devices via another connection medium. In cases where an attacker gets control of one of these systems, scary things can happen thanks to buttons with labels like ‘Valve Shutoff’ and ‘Release the Kraken.’

Gateways to Secure Devices

In other cases, clients use a small device known as a serial gateway, which allows them to connect to a service like secure shell or the infamous Telnet and manage the device as if it were directly connected.

The IoT scanner will then detect these HMI and serial gateway systems on the network. We need to remember that they represent many more devices from an inventory perspective. This is often where help is needed, whether it’s importing devices from the HMIs by hand or using a bespoke system, such as tdi ConsoleWorks.

Finding Your IoT Current Course and Speed

With all of our IoT systems discovered, the question becomes, “How do we secure them?” The Purdue Model for Control Hierarchy will be our North Star. It was the result of a joint venture between Purdue University and the Industrial Society for Automation 99 committee. Its four zones and six levels correspond to layers of difference between actual IoT devices (mostly OT devices) and enterprise networks. There is a helpful document that references the Purdue model for those who want to take a look, located here.

Purdue Model for Industrial Control Systems

The reality of what we find out in the deep ocean of IoT sometimes requires a bigger boat. The Purdue model is fairly specific to manufacturing. It also relies on organizations to change their environments in order to get the most value from it. Contrast this with IoMT use cases, where tablets, Windows XP computers and even the scale are all sharing the network and spreading lies about my weight. The organic adoption of these devices into production environments has been brave and hideous at the same time, making personnel more efficient while creating a tanker full of new attack angles with every feature upgrade.

Adding to the struggle is the number of new devices that quickly and easily connect with existing networks. For many IoT use cases, product managers are sweating bullets and trying to get a product to market with newer and better features than their rivals. To them, the Purdue model is a treasure map, where X marks the C-level executive that wants an easy fix and can write a check.

It’s no surprise that concerned industry forums and standards are springing up to lower the anchor and slow this ride down a bit. The IoXT Alliance is a good example of smart-tech vendors that are joining forces for good (IBM is a member). And the European Medical Device Regulation is worth keeping an eye on, with enforcement expected to begin in 2021.

Here Be IoT Monsters

What we are all trying to avoid, of course, is the situation where those pirates from the scary ghost ship get ahold of our personally identifiable information and protected health information, or even sink our critical ships altogether. In other words, these devices we are talking about are simultaneously critical and fragile. We need to protect them and their data despite them becoming more common.

Newer devices are just smart enough to be dangerous. They may employ decked-out Linux configurations and offer services like tiny, albeit powerful, servers. Clients mix them in with other devices, using real-time operating systems that you may have not heard of, but might be running inside things you use every day. Your car or the self-service check-out at the grocery store might include these. And still more of these devices run an outdated, embedded version of Windows. You might recognize it from those days where you worried about your Myspace page.

Handling End-of-Life Devices

These devices do not defend themselves. Many perfectly functional IoT devices are actually end-of-life from a support perspective but are still humming along until someone realizes that they are vulnerable to a seven-year-old exploit.

Recent cloud service shutdowns striking consumer security cameras demonstrate the disparity between software and hardware functionality. It left these otherwise working devices without a place to send their video feed. At work, these same IoT concerns apply — short product lifetimes and the same vendor dependence, even if the devices can still function once they lose support. In this way, older OT devices could outlive their smart IoT counterparts that depend on the cloud, just by virtue of their self-contained nature.

Considering all of these challenges, it’s easy to feel lost at sea. IoT scanners run, find new devices and tell us about their risks. These are great solutions, but if they generate thousands of findings, as scanners tend to do, how do we get a handle on their results? And, how do we look at the IoT from a risk-based perspective?

Help On The Horizon: Vulnerability Ranking

Nearly all vulnerabilities that a scanner reports, IoT or IT, reference a common vulnerabilities and exposures (CVE) number. MITRE maintains this repository of all of the reported vulnerabilities that affect vendor software and hardware. Handily, security researchers often reference this when they release proof-of-concept exploit code that targets the vulnerability. Not all vulnerabilities are publicly proven to be exploitable — X-Force Red finds that only about 16% of CVEs fall into this category.

While darknet and deep web diving can find specific instances of exploit usage, measuring the popularity of CVE exploits on the surface — think sites like Metasploit, ExploitDB and Github — gives us a really good picture of what security researchers are seeing.

In addition, you can use a combination of hands-on attack experience and artificial intelligence to rate each CVE according to how likely attackers are to deploy it. This helps add reality to CVEs that are so simple they don’t require exploit code and for configuration-based findings that don’t have an associated CVE.

Risk Analysis

Due to how complex IoT risks can be, it’s important to take both the technical and business risks into account before plotting a course. Technologies such as IBM partner AbedGraham’s [CCOM2] add health care-specific risk to findings and identify the IoMT devices that clinical engineering teams should focus on first.

For instance, despite vulnerabilities inherent in a certain model of patient monitor, the ability to take down a hospital’s magnetic resonance imaging (MRI) machines is often a more pressing threat. These risks can be viewed through different lenses. In the case of [CCOM2], vulnerable systems are measured against risks commonly associated with a clinical environment.

In addition, X-Force Red often takes these things apart to better understand what other risks might be lurking below. Tools such as FiniteState can help to analyze firmware and keep us posted on new threats to these devices over time. X-Force Red Hardware Penetration Testing can help to find vulnerabilities that may be present in the device’s behavior or its communication methods.

IoT Remediation Strategies

Fixing IoT vulnerabilities can be a long journey. For one, we often don’t control much about the device, other than some basic configuration. In addition, the affected device is sometimes part of a larger solution. Our point-of-contact might not be in a position to do anything about that. In the worst case, the vendor reminds us that the affected device is end-of-life and unsupported. Creative thinking is needed, and often we approach these situations from multiple angles.

Attack detection is first. Regardless of whether we can prevent it, we can certainly spot some scalawag trying to exploit it. Real attacks should be rare cases, and the IoT scanner, through its ability to listen to traffic, can sometimes detect and even block this behavior. In cases where we can detect it, we can tie this to our incident response playbook, knowing what is being attempted and what to look for during an incident.

Segmentation is also sometimes an option, if we find that the device is inappropriately or accidentally exposed. This process adds protection at the infrastructure level to build a seawall around the device. Essentially, an attacker may be completely cut off from this device if we place it on a different, protected network.

Patching is sometimes still an option for IoT devices. However, it’s less common and more difficult to perform than it is on IT counterparts. In the best cases, a configuration change can be pushed out with low risk in order to disable a vulnerable, unneeded service. If a patch does exist, the devices will often need to be taken out of service to be patched. In some cases, the device will require physical access to install the patch. Devices that experience failed firmware updates are considered ‘bricked’ and often need to be sent out for repair. Thus, patching high availability, critical devices is scary and dangerous, which in turn requires change windows and lengthy rollouts.

Responsible disclosure is the long-term process we find ourselves in when the security team or a client discovers a new flaw in a device. This is more common in the IoT space, due to the very things we spoke about earlier. Namely, it comes from the rush to market and the quick enabling of network features. Many of these devices have flaws that the team can quickly discover once they take them apart. You could say that it’s a real ‘big catch’ of vulnerabilities out there in the briny deep of IoT.

Come Sail Away

The seafaring metaphor has grown a bit fishy by this point. But, it’s sound. Moving from the relative predictability of workstations and servers to securing IoT devices is like setting sail for parts unknown. You need a program based on discovery, prioritization and remediation in order to maintain a tight IoT ship.

X-Force Red and Tenable will be hosting a webinar at 11 a.m. EST on Nov. 17, 2020 about securing the OT infrastructure. Please join us to learn more about the top threats against and vulnerabilities exposing OT devices and how to overcome the typical security challenges. Register to attend.