When I originally developed the graphic for IIoT solutions, it was meant to show the different components required to build a system and to highlight a few things decision-makers need to understand. First, there are “degrees” of automation that can be achieved such that solutions can be phased-in over time using a building-block approach. Second, the implementation of an IIoT solution is more complex than just deploying a sensor on some construction equipment. The graphic is helpful in simplifying the conversation and providing a common starting place for it.
The graphic also lends itself well to security discussions. It is helpful in breaking down the complexity of securing IIoT systems because security can be addressed in terms of the components listed in the graphic, with the understanding that the security of the whole system requires that the components be secure.
It is important to understand that the goal of any security program should be to create and maintain trust. This trust is granted by a user based on expectations that the system will work properly and provide true information. Because IIoT systems include a mix of information technology (IT) and operations technology (OT), trust also includes safety – the expectation that systems will perform as expected, without causing harm to people or the environment. Because an IIoT solution is a combination of sensors, transmission and storage systems, and potentially includes third-party software or services, the trustworthiness of the whole system depends, in part, on the trustworthiness of the components. A misconfiguration or security lapse in one component (or factor in the below diagram), can expose the whole system, your data, and potentially even your network, to harm.
The connected and distributed nature of devices acting as sensors means an increase in attack surfaces (components to attack) as well as in attack vectors (mechanisms used to attack). The implementation of sensors and IIoT gateways increases the attack surface of the system. Attacks can be against the physical devices, the network, the software, against users, and even on the supply chain used to build and integrate these solutions. Using the graphic as a structure, let’s take a look at some security considerations.
Collect: Here we are talking about the actual sensors used to collect the data. In the commercial world, this is the whole of IoT – the device. This topic alone deserves a post (or more) of its own as there are many various threats and vulnerabilities to protect against. Suffice it to say, protecting the “things”, or devices, in IIoT is complex. The sensors are typically built on a system on a chip (SoC) architecture, meaning they are self-contained systems that include the processor, graphics chip, communications radios, etc. Producers need to consider everything from secure boot, zero-defect secure code development, protection of data, and overall device security, including the ability to change default username and password information. I believe Blockchain technologies will play an important role here as a means to identify and validate devices as part of a solution within a solution. Overall, security concerns include the physical security of the device, the operating system, any applications running on the device, and data being communicated from the device.
Store: Storage can be on- or off-device. Any data stored on the device needs to be protected from unauthorized access, whether by direct access to the device, or through remote access, and should be encrypted. The authenticity of the collected data needs to be maintained as well. Because these devices are on the edges of a network, they can be harder to physically monitor and therefore are more susceptible to direct access by bad actors. Depending on the intended purpose of the device, data on these devices can be useful in determining the location of users, in understanding user habits, and may even contain personally identifiable information. Encryption should be extended to off-device storage as well, as a matter of good practice, whether the storage is on- or off-premise. The security requirements should be identical regardless, however, control over the physical storage systems may be hampered if using a third-party cloud storage provider.
Transmit: Avoiding plain-text transmission of data is an easy first step to keeping data secure while moving it from your sensor at the edge to a more permanent data storage location. The problem? Conventional cryptology is too resource intensive for devices with low power and computing resources. NIST is working on Lightweight Cryptography, identifying methods more appropriate for low power devices. Even once identified, merely implementing a standard isn’t enough – it has to be implemented properly. Zigbee, a popular wireless transmission protocol for IoT devices was hacked in 2013 despite its encryption being based on the AES algorithm. A 2015 DefCon talk points out that while the encryption was strong, the implementation was not.
Analyze: This is where data gets put into context and becomes usable. For the most part, software completes this task. There are some low-tech (human) methods of analyzing data, but if you’re going to go to the trouble of implementing sensors to collect data, then primarily analyzing that data with people, you’re probably reading the wrong post. When focusing on the more sophisticated business intelligence (BI) and big-data analytics, security gets a little trickier if you don’t have these products on-premise and/or you don’t have direct control over the source code or implementation methods. You have to trust that those offering their products as a service have properly implemented and enforced their security mechanisms. However, you still should take steps to ensure your data is protected through SLAs, proper monitoring, and other metrics. Understanding the security of third-party applications helps you better understand your overall security posture.
Use: “Use” is multifaceted. It involves primarily human interaction with the systems and data across the other components. Here, security must be considered from a user’s perspective. A user may not only be the executives and other company decision makers relying on the business intelligence provided by the system to make corporate decisions, but can also be technicians, developers, and integrators along the entirety of the solution. Here, it is important to reiterate that a security failure along the supply chain that makes up an IIoT solution can not only affect the overall security of the system but can also cascade. Often, these systems are integrated from multiple, non-homogenous parts made by different vendors. Focusing solely on end-user (business decision makers) interaction with the system, providing proper (authenticated) access to business information is key to keeping it safe. Proper training on the system as well as having an understanding of the product can also help secure these systems and the data within them. People are often considered the weakest link in the security chain, and there is a lot of debate as to whether or not you can ever fully change that, or if you can just mitigate risks. I’m not planning on settling that debate here.
The discussions above are just a glimpse into some of the risks associated with IIoT solutions. More in-depth conversations should be had when developing IIoT solutions. These conversations need to include the business decision-makers early and should occur often. The cost to a business isn’t just the upfront cash layout required to implement IIoT solutions. It is often a trade-off between securing devices and data, and the usability of the application or product once it’s been secured.
The bottom line – there is no one-size-fits-all approach for this highly complicated discussion. So let’s talk about it