Reducing Risk in IIoT

What is a “Security Framework” and how can it help protect against the unique threat landscape that is evolving with the Industrial Internet of Things? For the Industrial Internet Consortium (IIC), it is a broad-based set of responses to common security challenges in Industrial Internet systems, which speak to stakeholders with business, functional and implementation perspectives.  And the goal of its Industrial Internet Security Framework, (IISF), published this month after two years of work by the IIC Security Working Group, is to define “trustworthiness” in IIoT systems, viewed through the lenses of safety, reliability, resilience, security and privacy. But who are the IIC, and what is the primary challenge that differentiates IIoT security needs?

Hamed Soroush, senior research security engineer RTI and co-chair of the IIC Security Working Group
Hamed Soroush, senior research security engineer RTI and co-chair of the IIC Security Working Group

Founded in March 2014 by AT&T, Cisco, General Electric, IBM and Intel to accelerate the development, adoption and use of interconnected machines and advanced analytics in industrial environments, The Industrial Internet Consortium (IIC) is an open organization that now boasts over 250 members from 30 countries. Focused on finding solutions to industry problems such as interoperability, the integration of IT and OT (operational technologies), architectural design, or defining IIoT business strategy, the group now operates 19 separate working groups, including one on Security. According to Hamed Soroush, senior research security engineer for RTI and co-chair of the IIC Security Working Group, the IIC is not a standards body or certification organization, rather it is an industry-driven group that is tasked with generating documents, such as reference architectures or best practices, that can provide guidance in the Industrial Internet space. Against this backdrop, he explained, the IISF “is more about bringing up the challenges that the industry faces, creating a language that stakeholders in different sectors can recognize, uniting people with different IIoT perspectives through creation of common terminology and a common culture, and reviewing some of the key technologies and standards to help owners and operators address security issues.”

The IIC’s focus on security is well founded. The Industrial control systems and the protocols they run on have driven automation in industrial environments for many years based on a walled garden approach. But with IIoT, the connection of sensors, devices, motors and machines to Internet technologies introduces new levels of risk, due in part to the sheer number of new network nodes in IIoT systems and due also to greater exposure to hack attacks that Internet connectivity brings. At the same time, the consequence of failure remains the same and dire – production stoppage, safety risk, and potentially even loss of life. Imagine malware intrusion in a nuclear generating facility, the factory floor, in a connected vehicle or digitized medical implant.

Soroush describes new levels of risk as a product of basic incompatibility between IT and OT processes: “IIoT systems are a combination of very different technologies. OT, which you would have in industrial control systems, such as SCADA systems, represent a completely different mindset and technology [from ICT]. But these are now being connected to an IT environment. This completely changes the threat landscape: what should happen is that people working on the IT side of IIoT should understand the requirements of OT, and those who are on the OT side, should understand the requirements of the IT folks. And they both should understand the new threat landscape that is emerging.”

So in addition to technical challenges, the convergence of IT and OT also creates cultural problems that resonate at a business level. As Soroush explained, risk management, including the communication of threat potential and outcomes to senior leaders who may have more influence over investment priorities or business processes, than, say, the shop floor engineer, is a critical requirement. One of the strengths of the IISF document is that it addresses this kind of requirement; based on the notion that security is not just a technological problem, it tackles issues that are of concern to the business manager in order to offer more holistic guidance. In fact, the Security Framework assumes the viewpoint of business – the CEO, who may not understand in minutiae of technical security but needs to engage in risk management around culture and process, the functional perspective of workers who are more engaged with the architectural building blocks of IIoT systems, and the implementation viewpoint, which focuses on technologies – web portals, for example, or communications protocols that may require security support in IT – in discrete sections of the document. “Owners/operators of IIoT systems, component dealers and system integrators each have different perspectives, requirements and expectations for security,” Soroush added.

In IoT generally, one of the biggest tests lies in trying to apply a standard security approach across solutions that are composed of multiple components built on proprietary technologies that may operate according to different protocols. In IIoT, difficulties associated with creating pervasive security are compounded by the co-existence of IT and OT within the solution. The IISF discusses the user organization’s need for end-to-end security in the functional/implementation viewpoint section of the document, breaking this down into advice for securing the end point – hardware technologies for hardening the devices – for securing communications – protocol dependencies and what they should provide, firewalls and network segmentation – guidance for the security management and configuration of large industrial systems, and for security monitoring and analytics. The document also tackles issues around assurance – how much trust, for example, can the user place in a piece of software? While securing each component is one way to skin the cat, vulnerabilities remain where component systems intersect, an issue that Soroush agrees is an ongoing problem in IIoT implementation: “we absolutely take that into account. It’s actually not just the components that need to be secure, somebody needs to look at the whole system from end to end, and the threat models that are built should be end to end. We talk about the data lifecycle – the path of data collected through sensors, and sent via networks to the cloud, and then on to an IIoT application – which should be the subject of security analysis. The architectural perspective that shows how data traverses systems should be part of threat modelling and the discussion of risk.”

From the IISF report.
From the IISF report.

The huge economic value that can be derived through the convergence of IT and OT, either through optimization of existing processes or the creation of new products/services across a range of sectors, means that momentum in this area is unlikely to slow – despite security risks. In a report commissioned by GE, Accenture, for example, has outlined the transformative potential of IIoT, citing value estimates arising from the Industrial Internet ranging from worldwide spending of $500 billion by 2020 to $15 trillion of global GDP by 2030. But in the rush to value, how does security factor into solution development? “This, in fact, is one of the biggest sources of fear,” Soroush explained. “What’s happened to security is that people build a system, and want to bolt security on after the fact. So the system is built without a thought for security needs. OT systems were designed in an era where there were no gaps and mutual trust in system components was the norm; they were not designed for the world that we are bringing them into.” In many deployments, new IoT solutions are built on top of legacy OT systems, introducing additional risk. Soroush noted, “When you have components that are not secure, or not capable of becoming secure, you increase the threat surface; dealing with legacy systems is a huge problem in IIoT.”

All is not lost, however; Soroush pointed to the testbed facilities provided by the IIC that allow users to test not only the functionality of a new IIoT solution, but also its inherent security. And as further guidance, the IISF discusses technologies that may be used to provide integration and security support for various components. The ultimate goal, of course, is to learn more about how these systems can benefit from security by design and to develop best practices that enable this. On this note, Soroush stressed the importance of embedding security into initial design, and also the need to improve software development processes in IT and OT as keys to better security outcomes. IT approaches alone may not prove workable; production shut down to accommodate sporadic software patching are unlikely to be welcome in many industrial environments. “We need much more assurance around the ways we produce software, and at the same time, we need better protocols and better standards on the OT side. So by using the best of what we know on both sides and combining the two, we will at least reduce some of the risk.”

Going forward, the IISF Working Group is looking to tackle some of the other critical requirements in IIoT systems – privacy and safety, for example, may receive more attention in subsequent works. In the meantime, the group is hoping to incorporate feedback on the IISF from the community in new versions of the document. Considered comments welcome, and may be addressed to: Michael Linehan, Operations Manager, IIC. linehan@iiconsortium.org

The IISF is free of charge and available here.

IISF editors and other security experts will be presenting at the Industrial Internet Security Forum on October 6th, 2016 in Sunnyvale, CA.

LEAVE A REPLY