The Industrial Internet of Things (IIoT) is proving to be a double-edged sword for sensors. Sure, the connectivity that it brings is simplifying their installation and streamlining the distribution of collected data. But the IIoT has also made it easier for hackers to use sensors to break into industrial networks and cause trouble.
Another reason that sensors and other intelligent devices have begun to capture the attention of hackers is that most of these devices have not been designed for cybersecurity. Add to that the fact that they are designed to collect and pass along data within a network. “Vulnerabilities in these devices could give hackers the means to hijack a session, change the data or modify data collection patterns in a way that might deceive the end-consumer—be it a person or a machine,” says Dave Weinstein, vice president of threat research at cybersecurity supplier Claroty.
Vulnerabilities fall into two basic categories. The first is software bugs that hackers can exploit to launch attacks either internally against the control network itself or externally against some other target. The second category of vulnerabilities is the hardware. It is possible to launch an attack by manipulating the physical properties of the hardware itself, such as by using acoustics or electromagnetic waves to mount transduction attacks that spoof data.
“Hardware vulnerabilities, while scarier, are less common,” Weinstein reports. “The majority of incidents relate to software bugs—and these are far easier to fix than hardware vulnerabilities.”
Even so, these vulnerabilities can pose serious threats to manufacturing operations. “Attackers aren’t targeting credit card numbers or other personal information,” observes Eric Braun, engineering director for applications, gateways, and security at Emerson Automation Solutions. When it comes to attacks on industrial control systems (ICSs), many of the perpetrators are looking to cause physical damage. For evidence, Braun points to the Triton malware discovered at a petrochemical plant back in 2017, which took aim at the facility’s safety system.
The most likely vector for a hacker to launch an attack on a sensor or like device would be from the higher, Internet-facing layers of the Purdue reference model. Such attacks have typically begun with some sort of phishing scheme. “Attackers will target individuals and attempt to get them to open a malicious attachment or click on a malicious link,” Braun explains. “These actions will allow the attackers to steal credentials, navigate through the network, and work their way down to the lower layers of the Purdue model.” In a segmented network with firewalls protecting each segment, however, it is unlikely that a hacker would drill that deeply into a network.
A new attack vector
What is more likely these days is for hackers to attack sensors that are no longer at the bottom of the hierarchy outlined in the Purdue model. Today’s IIoT devices communicate directly with whatever or whoever needs the data that they are exchanging. With this kind of connectivity, a drive for a welding robot, for example, could be transmitting utilization data to the robot’s builder via the cloud. “It could be saying that, based on my duty cycle, I’m going to need to have a particular part replaced in approximately 17 days and four hours,” says Dan Schaffer, product marketing manager at Phoenix Contact.
As helpful as this exchange of data can be for maximizing performance and uptime, the robot is talking directly to the Internet rather than going through a conventional control hierarchy. This direct communication circumvents the several layers of firewalls that would exist between the logical segmentations of a secured network following the Purdue model or security standards like ISA99 and IEC 62443. “If there is a flaw in the robot’s operating system, it could allow the robot to be the victim of a buffer overflow or some sort of other communications attack,” Schaffer notes.
Such vulnerabilities can sneak up on users who initially designed the network security of their manufacturing operations around the Purdue or other model. “These users think that they are adhering to the model, but really aren’t,” Schaffer says. “They think that they are following best practices but aren’t.”
Among the devices lulling users to let their guards down in this manner are the IP cameras that are appearing just about everywhere these days. “Visual imagery is becoming a key stream of data for processes,” Schaffer says. “Cameras are cheap and easily deployed technologies that give you immediate visibility into what’s going on at a given location.” Because these devices were typically not designed with network security in mind, video streams transmitted over the Internet from remote locations can easily be an attack vector.
To drive the point home, Schaffer points to two vulnerabilities—overflow and authentication vulnerabilities—that were discovered recently in iLnkP2P, a widely used peer-to-peer software from Shenzhen Yunni Technology. More than 2 million IoT devices, including IP cameras, are affected. It is possible for hackers to exploit these vulnerabilities both to intercept the video streams and to steal device credentials.
Unprotected IP cameras are also among the IoT devices that are susceptible to a recent variant of the Emotet Trojan malware first discovered in the banking industry. The new variant enlists IP cameras and other IoT devices as proxies in command-and-control attacks, thereby allowing Emotet to communicate through an intermediary, instead of directly with the command-and-control server.
Phoenix Contact’s mGuard security router and other appliances can serve as firewalls in industrial networks.
Shield against attacks
To guard against these kinds of threats, security experts urge users to ensure that their sensors and intelligent devices are safely tucked behind suitable firewalls. And because no network is impregnable, they further advise users to develop a defense strategy that includes both dividing the network into logical segments to contain any intrusions that might occur and monitoring traffic to detect and stop those intrusions.
To support this effort, automation vendors have rolled out a number of devices that can serve as firewalls in industrial networks. For example, Phoenix Contact’s FL mGuard line of cybersecurity appliances includes industrial-grade routers and concentrators. Even the company’s I/O devices and safety bridges are designed to support cybersecurity. Devices like these use encryption to protect data and authentication protocols to permit only authorized traffic. They can also actively block traffic based on who it’s coming from, where it’s coming from, and the type of traffic it is.
“The technology is of the same type that the IT folks are using in their data centers,” Schaffer says. A big difference, however, is that Phoenix Contact and other automation vendors are packaging their technology for the control cabinet out on the factory floor. That means the devices are hardened to withstand the humidity, temperatures, and electromagnetic interference typically found in manufacturing facilities. Another important difference is that these industrial security devices are designed to be managed by a control engineer rather than an IT expert who manages networks for a living.
Emerson has incorporated many of the same defensive principles in its wireless technology, which is based on the WirelessHART protocol. “WirelessHART has done a lot to secure sensor networks,” Braun reports. “It has proven to be a very secure alternative to some of the more unprotected wired networks.”
Built-in security measures protect against many kinds of cyber intrusions, including replay attacks, eavesdropping, spoofing, man-in-the-middle, and denial-of-service (DoS) attacks. WirelessHART, for example, supports layers and encrypts all data with multiple keys using AES-128 bit encryption. “All devices on the network, moreover, are authenticated so a user doesn’t have to worry about unwanted or rogue activity,” Braun says.
In fact, the encrypted transmissions in wireless communications is currently filling a void at the lower levels of the Purdue model, according to Aurel Buda, factory automation product manager at Turck. “With the exception of wireless communication systems, hardly any communication protocols at the field level in automation supports encryption,” he says.
Buda attributes this lack of support in part to the separation that manufacturing companies have tried to maintain between their automation and IT networks. In the past, the perception was that the separation made securing field-level communications unnecessary. Another reason that Buda gives for the scarcity of encryption support at the field level is money. “Secure communication comes at a cost,” he says. “Considering that large facilities consist of thousands of field devices, the utilization of intrinsically secure components would increase their costs significantly.”
Scout for intruders
When coupled with the practice of shutting off unused ports, controlling the traffic permitted to cross firewalls limits the visibility that outsiders might otherwise have into the network. “Not knowing what is there on the network makes it much more difficult to do anything, let alone anything malicious,” Schaffer notes. “It’s difficult to attack something you can’t see.”
Although a good cyber defense will strive to make the devices on a network as invisible as possible to hackers, it will strive to maximize their visibility to authorized personnel overseeing the network. “You can’t protect what you can’t see,” Weinstein explains. “So, at a minimum, users must increase the visibility of their OT [operational technology] network assets to include those sensors and other devices at levels 0 and 1 of the Purdue model.”
For Weinstein, visibility goes beyond simply adding them to a detailed inventory containing a list of devices on the network and their configuration settings. Visibility also includes the ability to inspect the communications among those devices. “Industrial cybersecurity demands a deep understanding of each asset’s function and the relationships among the devices,” he says. “Only by dissecting and correlating these process automation conversations from every corner of the network can 100 percent visibility be achieved.”
To help users achieve this goal, Claroty has developed tools that use multispectral data acquisition (MDA), a combination of passive monitoring, active querying, and application database parsing. Through passive collection, the tools automatically inventory the facility’s assets and profile each asset’s communication pattern. Active querying is a targeted process for gathering those details not collectable through passive monitoring. Because some of the richest and most up-to-date asset data resides in the configuration files used to restore systems from backup, MDA also parses these large and complex binary files. The resulting collection of patterns form a baseline that Claroty’s software uses to detect security problems.
Ultimately, though, the visibility spectrum of all security measures must bring sensors and other devices under the same cybersecurity umbrella that is protecting the rest of the network. “Protecting automation infrastructures requires holistic cybersecurity concepts that have to be reevaluated in regular audits,” Buda says.
