Don’t blame the technology. This is a people problem.
The Internet of Things is famously insecure, but not because the technology to build it or secure it is immature. Likewise, severely insufficient security on the Industrial IoT suffers from a lack of will. Neither tech buyers nor providers have yet invested the same effort expended in other areas of the tech world to create and adopt steps that will make everyone safer, according to chipmakers and analysts.
“My evaluation of security in the IIoT? Zero,” said Richard Soley, executive director of the Industrial Internet Consortium (IIC), which issues IIoT guidelines, and chairman and CEO of the Object Management Group. “Nearly all implementations of the IIoT I’ve seen assume you’re going to build a wall around them and they won’t need extra security because the perimeter will keep any threats away. That’s nonsense. On the consumer Internet, 80% of breaches involve something inside the perimeter that breaks security, whether it’s malware, or a phishing call, or an insider you shouldn’t have trusted.”
This is especially unnerving because of how much is connected to the IIoT. No longer just about the IoT and connectivity to the factory floor, the IIoT has many use cases, from utilities and transportation to in-building systems, like HVAC and lighting.
“You hear a lot of horror stories,” said Pim Tuyls, CEO of Intrinsic ID, which provides security products and IP to chipmakers, including immutable physical identification designed to eliminate the possibility of silicon either being faked by counterfeiters or spoofed by attackers pretending to be a friendly device. “It can be worse than other situations with the Industrial IoT, though, because there is often a physical risk to attacks on the electric grid or water utilities in addition to the risk of a data breach.”
A survey of 1,703 embedded systems designers, taken by the Barr Group in early 2018, found that the wide variety of architectures and applications means there will never be a “one-size-fits-all” solution to security.
Technology providers are falling down on the job in a number of ways, according to the Barr Group’s analysis. “About 1 in 6 designers of potentially injurious Internet-connected embedded systems are completely ignoring security,” the report found.
“It’s not that the pieces aren’t there,” Soley said. “I would argue that the pieces are all there, or almost there. It’s that people don’t know how to use them.”
Facing the OT/IT divide
Many technical issues contribute to the fractured, uncoordinated nature of security in the IIoT market, but the focus and security habits of the end users responsible for the projects comes up in almost every discussion about it. Operational security staff just don’t seem to understand or believe in security risks in the same way IT staff and chipmakers do, according to Steve Hanna, senior principal in the U.S. for Germany-based Infineon Technologies.
The three heaviest contributors to IIoT spending in 2018, according to IDC, will be manufacturing ($189 billion), transportation ($85 billion), and utilities ($73 billion).
Traditional IT people deal with end users, wrestle with malware and infosec issues and go back to deal with more users, who are a consistent source of access for attackers. Phishing emails—lying to people via electronic text with no digital wizardry involved—accounted for 93% of social attacks and were involved in 98% of all incidents (successful or not) and 88% of financial pretexting attacks, according to the cybersecurity report of record Verizon’s “2017 Data Breach Investigations Report”.
Operational technology (OT) staffers come from a very different environment—one that has been automated and digitally controlled as part of an industrial control system whose connections to the Internet would have been carefully filtered or nonexistent. Industrial software is designed as an integrated complex system using the same set of security controls, without the direct Internet connections that adds one layer of risk to an IoT connection, or the stack of Internet applications and protocols that add the rest.
“I don’t want to put too much blame on the OT side of the house, but networking had a very different meaning if we went back a few years in the OT environment,” said Hanna. “Your plant really was a separate environment. It wasn’t connected to much except maybe headquarters. And it didn’t have the same protocols or cross connections as a business net. Thanks to the IoT, they definitely do now.”
OT staffs aren’t completely naïve, said Gerardo Pardo, CTO for Real Time Innovations. They just assume no one would use networks or connections so inherently flawed as the Internet. OT staff don’t realize the holes they’re missing when they ignore the potential for breaches and the need for end users and technology providers to work together to lock down the potential threats they just introduced.
“Security is a broad thing,” Pardo said. “Someone on your team wants to monitor the oil rig with an iPad running Javascript on a WiFi network you’re not too sure about? You might as well build a high-performance vehicle with steering that doesn’t work, or no transmission. Then you’re not high performance, you’re vulnerable. But sometimes you have to dig down through a few layers to find that out,” Pardo said.
Guidelines and standards—pick one and stick to it
There is plenty of information out there, and plenty of guidelines, from the IIC, NIST, IEC, ISO, Trusted Security Group, Cisco, IBM, the Dell-focused EdgeX Foundry, European Industrie 4.0, the Object Management Group, and IEEE.
“It’s not that we don’t have standards or guidelines, we have too many of both,” Hanna said. “What we don’t have is a way to consolidate on the best ones and get participation from security companies, for example, to help create the kind of integrated standards and support fabric that’s common in other areas.”
The IIC has issued a series of guidelines, how-to papers, and frameworks, including a guide to help IIoT designers and vendors navigate security guidelines or frameworks issued by other organizations and a third defining all the elements that go into a “mature” program of security of IoT devices—including safety, reliability, and predictability of the behavior of the device, in addition to simple resistance to being pwned.
Even all those detailed guidelines are unlikely to give many companies exactly the answers they need, Hanna said. That’s the reason for best-practice documents and common standards that can fill in the gaps. Best practices—when followed—can to keep things relatively safe even when those responsible for building a project and those building the devices for it work in a relative vacuum and do not know how to approach questions about security.
“It’s not one-size-fits-all in the industrial realm,” Hanna said. “Even at the device level you need to navigate multiple levels of security, prioritize critical systems according to level of risk and choose a level of security appropriate to that device. We need consistent participation from companies from all over—security providers, OEMs, chip makers, integrators, operators, service providers—to establish standards and best practices and certifications that apply broadly to more than just one industry or just one technology provider.”
“One gap has been that most of the discussions on IoT security are happening in operational environments, with device operators, IoT consumers who are taking technologies and trying to build use cases and applications on top of them,” according to Ranjeet Khanna, director of product management, IoT and embedded systems for Entrust Datacard.
“If those discussions are just one-on-one, what about the rest of the OEMs and device makers? How will I know how to issue a certificate to a device? These are the gaps in how we should educate our peers,” Khanna said. “We have a unique opportunity with the IIoT, but also a responsibility to create a foundation for IoT security. We live in a world of competition, but we can compete with standards that also let us provide a complete product. My goal is to sell my product or services yes, but not by offloading tons of responsibilities onto customers and elude my own responsibility.”
The vast number of hardware platforms and operating environments used for IIoT devices makes interoperability difficult, as does the wide variety of requirements in individual vertical markets.
The big problem, according to a 2018 survey by embedded-systems consultancy and training firm Barr Group, however, is a consistent failure by the technology providers involved to do the things that make either a cohesive community or good security happen.
Both those flaws and others can be addressed using well-known software-development best practices—but they haven’t been.
Better, more consistent security may be a big step forward for the industry, but it won’t eliminate every potential issue.
“One challenge, from a security analysis perspective, is that it’s difficult to verify that security is working as intended because the same architecture that hides security information doesn’t make it easy to verify,” according to Atul Prakash, a University of Michigan professor of electrical engineering and computer science who led a team that cracked and then documented weak smarthome security in 2016, wrote an information flow-control system for IoT devices and a contextual permissions app for them, but also and figured out how to fool the AI steering an autonomous vehicle by putting stickers on a stop sign.
“You obviously don’t want to leave the secure part exposed, but there have been concerns raised on the supply-chain side of the chip business that should make us wonder if we know where every complement of chips is coming from, whether they’re running the right code and whether the firmware has been compromised,” he said.
Fig. 1: Diversity of embedded systems hardware and software architectures. Source: Barr Group
The problem with hardware
The devices themselves are also a problem. Unlike in the x86 world, every IIoT device is different.
Most are built to one degree or another on Arm Cortex microcontrollers or IP but are so heavily customized to accomplish the specific task required for the one project they were designed for that there is little resemblance or chance for interoperability among chipsets from different vendors.
Nearly all Arm microcontroller IP includes some degree of security – or at least the wiring that would make secure boot, encryption, authentication or fully functional PKI certificate management possible, according to Rob Coombs, director of business development for Arm’s IoT Device IP business.
Arm IP has had a trust execution environment and security ecosystem built in since 2002, for both resource-constrained microcontrollers for sensors and other low-power devices and more high-function hardware.
“We offer high-quality reference architecture, and a whole series of APIs and libraries of functions to make it easier, but it is up to them how they want to implement it,” Coombs said. “When you’re deciding what to put in a chip that you might produce in the billions, a penny difference is a big deal so you have to be very careful about what you put into it—not security or now, but how much security.”
And, in fact, “a lot of the chipsets being used have the hardware to be fundamentally secure but 90% to 95% of the OEMs are not implementing those functions,” according to Asaf Ashkenazi, vice president of IoT Security Products at Rambus.
Ashkenazi is one of the few who has had the opportunity to check a wide range of hardware, which he did as part of the research to put together Rambus’ CryptoManager IoT Security Service—a cloud-based service that promises to lock down IIoT devices using remote monitoring and authentication for devices based on silicon from Rambus or a range of other vendors. That interoperability is possible only because other vendors helped Rambus develop SDKs to allow it, which have to be installed at each client site, Ashkenazi said.
“The hardware is different for every vendor. Even if you only look at the root of trust, each has a different way of doing that, different memory restrictions in the device, maybe not all the software is in there or it’s not implemented completely,” Ashkenazi said.
If the vendor didn’t implement most of the security functions Arm supports for the particular bit of its silicon or IP in the device, it can be very difficult for end user, an external security provider or even another chipmaker to discover how a secure key is stored, how to securely identify the device and how the root of trust must be handled, Ashkenazi said.
To even get started, a security service needs three things:
The cloud service—or whatever application is providing the control—has to be able to communicate with the devices it controls. It also must keep them from communicating with unauthorized devices to reduce the chance of contracting Mirai or any other strain of malware, and build up a database of common behaviors to use as a template and quash any unusual activity.
“They’re very basic operations—wake up, measure something, send it to the cloud, go to sleep,” said Rambus’ Ashkenazi. “You have to know what to expect so you can recognize when something is happening that’s a problem. It’s not magic; it’s a lot of hard work. Without some kind of service, some companies have no way to know where their devices are or what is connected. We had a company come to us that had deployed 1,000 devices, but 3,000 had connected to the service. That’s why you need strong authentication and to know which device is connecting and that it hasn’t been compromised.
Rambus’ CryptoManager IoT Security Service is not a cloud access security broker (CASB), but it is an add-on security service applied after the connection is made, the users are in business and someone has to provide a filter to prevent disaster.
It is more difficult to secure dozens or hundreds or thousands of newly connected smart-factory devices than it would be to protect a similar number of x86-based PCs and servers, but the device is just a start, Ashkenazi said.
Most chipsets are built on, or at least include, some IP from Arm that would include secure boot, secure device identification and possibly support for certificate-based authentication and/or SSL or TLS encryption for data being transmitted. But that doesn’t mean they implement the same functions the same way.
Related Stories
Toward IIoT Security Standards
What the industrial IoT would look like if it was mature, secure and reliable.
Why IIoT Security Is So Difficult
A fragmented market and ecosystem mean it will take at least five years to get security to a meaningful level.
IIoT Security Threat Rising
Rising value of data and growing complexity driving sense or urgency.
Data Leakage And The IIoT
Connecting industrial equipment to the Internet offers big improvements in uptime and efficiency, but it adds security issues.
IIoT Grows, But So Do Risks
Things are coming together for the Industrial Internet of Things, but security is a huge and growing issue.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply