IIOT Security Essentials : What you need to know

Industrial companies are increasingly implementing the Internet of Things (IoT) on the factory floor and in the field. Such largescale end-to-end Internet Protocol (IP) connectivity will doubtless facilitate many more capabilities at the edge of these networks, but at the same time, it presents a huge security threat. IIoT enabled Operations Technology (OT) offers a much larger surface prone to cyber-attack than the IT space where by comparison the volumes of data are lower and its comings and goings can be more precisely controlled.  


In the industrial sector, huge amounts of data are being processed at the edge and sent back to the cloud for further analysis and used by different applications. These applications as well as the operating systems they reside on, communicate with physical devices through device drivers and firmware. Attackers can exploit these special classes of software to subvert and compromise hardware. Every single device and sensor in the IoT represents a potential risk but today significant numbers of IoT devices are not being used with security in mind. Many are easily available for physical access.


It’s therefore not surprising that for many companies, security is a major and growing priority even though a few may still prefer to delay the harnessing of the full potential benefits of the IIoT if it means security pressure points can be postponed a little while longer. Inevitably, however, all industrial companies will need to take ongoing action to more securely share and analyse critical real-time data. This has to be the end game.


For this to happen it is important to not only secure assets, but also secure the communication links themselves. After all, IIoT networks may span many miles with potentially hundreds of thousands of data points.


Follow these essential IIoT security rules: 

  • Ensure every access is authenticated and authorized
  • All communication should be encrypted
  • All software and firmware must be regularly updated

Apply these to each and every connected device in an industrial internet of things (IIoT) environment.


Putting theory into practice

Let’s put these rules into practice by considering a typical industrial IoT scenario.


Figure 1. (MQTT Diagram) shows a simple sensor setup which is connected via ISO standard MQTT (Message Queuing Telemetry Transport). This is a widely used protocol in IoT and located on the application layer, such as HTTP, FTP, or DNS on top of TCP/IPN Ethernet.


It is a simple subscribe and publish protocol that allows a sensor, or publisher, to publish its data as a topic. In this example, we have the topic “Factory 1, floor 1, robot 3, oil temperature”, which is regularly published by one sensor. If another client is working as a process monitor, it can subscribe to “Factory 1, floor 1, robot 3, #” and then get all that data.


Now, let’s apply our first security rule here, where every access should be authenticated and authorized. For authentication, we need all the participants to be addressed, which means every sensor, client and device needs its own username and password, or its own key file.


OK, so far. And authorization is to do what? In this example, the sensor on the top left is only allowed to send to the topic “Factory 1, floor 1, robot 3, oil temperature”. Being able to distinguish every detail about who is allowed to do what really makes sense, even when you are in a closed network, as there are intruders that might get access.


But authentication and authorization might not be sufficient, especially when there is no encryption in the network. When an unencrypted network client logs in, the credentials are transported in plain text, meaning everybody inside the network can sniff them out very easily. The only thing that you need is a network monitor and access to that network.


So we can avoid that by applying our second rule, encrypting all the transport inside the network. MQTT is really simple because you can set it up on top of any security layer in TCP/IP.


The third rule is that every device’s software and firmware must be upgraded. Remember, an IIoT network usually comprises numerous embedded devices with long lifespans. But generally speaking they’re not like a modern IT operating system such as Windows which is consistently conducting massive updates.


In fact some embedded technologies don’t allow any updates. Remember 2014 when Heartbleed was an issue in OpenSSL? This allowed all the encrypted data to be fully revealed to anyone. On a level of 0 to 10, it got an 11. That meant all the encryption in place was simply in vain. The issue could only be addressed by updating to a fixed version of the software.


There are many other examples such as Poodle which wasn’t as problematic as Heartbleed but still quite an issue. The fix was to update the software but there’s no guarantee it won’t happen again. And more recently we’ve seen the fallout caused by Spectre/ Meltdown.


How to update doesn’t matter so long as it’s done, whether locally or remotely. All clients, servers and devices hosting firmware or software should have the ability to be fixed.


Choose your technology partners wisely



As discussed, the hyper-scale of the IIoT necessitates a far more secure approach to the interconnection of many different kinds of devices, machinery and systems involving hardware, software and firmware. In turn, this now places an even greater emphasis on the selection of the most appropriate technology partners, those who have what it takes to keep the IIoT safe and secure.    


When it comes to embedded boards and controllers, for example, Kontron solutions are already secured by design. To do this we partner with some of the leading security vendors, like Wibu-Systems, to protect our hardware and the software that runs on it.


For example, detecting any unexpected change of code, data or configuration during the boot process, starting from reset time, is a highly desirable feature to discover attempts to compromise the system. For this, designers can integrate our secure, trusted boot software to enable a chain of trust, ensuring the system BIOS is authenticated. The same applies at the OS level, with secured operating systems.


With Kontron APPROTECT there’s also a further level on the application side available. Here Kontron boards include a Wibu Systems security chip with related software to allow full IP protection for running software. The application code can be encrypted, and therefore, not be reverse engineered. The combined hardware and software solution is in addition to the TPM 2.0 (Trusted Platform Module) chip for providing full application level protection.


In summary, most organisations in the industrial space now fully appreciate the huge efficiency gains and competitive advantages on offer by embracing the IIoT. At the same time many are understandably concerned by the increased security risks it presents. The adoption of common sense security best practices and partnering with the right technology providers will help to ease the load.   


For more information about Kontron’s security solutions visit https://www.kontron.com/products/solutions/security


Cover Picture: © Buffaloboy - Fotolia.com

Thank you!

Your comment was submitted.

An error occured on subscribing!:

{{comment.date.format('MMMM DD, YYYY')}}


There are no comments yet.
Contact Sales 1-888-294-4558 / 858-623-3094 Contact Sales Support 888-835-6676 / +1 450-437-5682 Contact Support
More Contact Options