Industrial IoT and consumer IoT can benefit each other, but actualising these benefits requires a deep understanding of the topics; something that can seem overwhelming due to the sheer amount of possibilities and technologies. By Dr. Johannes Bauer, UL Principal Security Advisor, Identity Management & Security
Even though the importance of the Internet of Things (IoT) for manufacturing and industry ranks highest according to a 2019 study by Dresner Advisory Services, most of the press that IoT gets revolves around consumer devices.
The space we call industrial IoT (IIOT) is quite similar in terminology to consumer IoT, but they have vastly different requirements regarding core aspects of their system designs.
The need for availability, cryptographic flexibility, patch intervals and choice of application protocols are approached so differently between the two that the commonalities seem surprisingly small.
Furthermore, the domains have had little overlap in the past and each has their fair share of prejudice against the other: industrial control systems are often viewed as anachronistic and inflexible while the consumer IoT space is likewise portrayed as just chasing every latest trend in hipster computing without putting lots of thought into it. Sometimes such stereotypes may contain a grain of truth inside them.
However, what is important when we are trying to improve the security posture of IIoT products and solutions is not to rush to judgement, but to truly understand why different domains with such similar names use different approaches internally, and how they can be fully integrated and interconnected.
Stepping back and looking at the types of products generally considered as IIoT, we typically mean devices that have their origins purely in Industrial Automation and Control Systems (IACS), but that have received an “IoT upgrade.”
Such products might include industrial firewalls, routers, PLC or SCADA systems. Typical realisations of IIoT digital twins, for example, are implemented by the components having a direct IP link to a (typically cloud-hosted) backend server.
That server accepts telemetry data using a protocol such as MQTT, often (and hopefully) performed over Transport Layer Security (TLS).
The cloud backend then does the processing of aggregated data to show dashboards or relay sensory input to device models – digital twins – to make predictions or improve controllability from one central aspect.
Overall, this enables more efficient processes and control, leading ultimately to cost savings. An example of this would be a silicon manufacturer who can automatically correlate large-scale orders with fabrication plants in real-time to improve plant utilisation.
Getting such an IIoT implementation running is often quite easy from a functional side; there are vast amounts of open-source software available that can allow the development of a proof-of-concept within a day’s worth of time.
Something that we observe in the IIoT device space frequently is that the final products have a high maturity from the pure IACS device aspect, but oversights that can create security weaknesses occur within the IoT side of things.
IoT At Scale
The treacherous simplicity of getting IoT running is often confused with the intricacies of getting these protocols running at scale, using mass-produced devices while still retaining all security guarantees.
One reason for this is because the protocols that are used in the IoT space are usually not just simple but composed of whole families of protocols which differ greatly from each other in terms of their security promises. To the casual observer, this difference is not even visible nor obvious.
For example, TLS can be roughly categorised into three versions: SSL, TLS v1.0 to v1.2 and TLS v1.3. And while TLSv1.2 and TLSv1.3 seem like just a minor version difference, this could not be further from the truth. TLSv1.3 is a complete redesign and overhaul of the whole protocol, ridding itself from a lot of historic baggage while trying to balance its act in a somewhat backward-compatible way.
One reason why consumer IoT can work with such complexities is that their testing and release process is typically different. Release cycles are shorter, and a great focus lies on the automation of not only unit testing, integration testing of the whole product.
Of course, such a high degree of automation is more difficult to realise when there are hardware components involved which cannot be easily simulated by a software-implemented test stub.
When we circle back to the reputation that classical IACS devices have when asking people from the consumer IoT sphere, admittedly the development in the industrial space is quite conservative and can thus be regarded as inflexible or slow.
However, that is only part of the whole picture: The truth is that this is often an intentional, and quite deliberate, design choice of IACS systems to use protocols and algorithms that have proven their robustness.
In the domain that we find IACS systems in, an outage is not merely a minor inconvenience such as often the case with consumer IoT. Instead, an outage of an IACS device can mean that production on a line or even a whole factory grinds to a halt, causing a cascade of incurred cost due to running liabilities. Robustness, resilience and availability are of utmost importance and cannot be risked under any circumstances for just the next fad.
During security assessment of such devices, experience shows that availability is often the top priority, that even outplays security in many cases.
Rather than touching a system that has been proven to work reliably, vendors often opt to externalise cybersecurity countermeasures, such as firewalling missing-critical systems that are known to have security vulnerabilities. Having externally scoped and protected networks on which IoT systems are deployed is something that consumer IoT systems could also benefit from.
Stereotypes and the reputation of specific industries are rarely a good guiding star. Both industrial and consumer IoT domains have specific traits that need to be understood when the goal is an excellent overall security posture of a product that plays in both domains.
Each domain has aspects that can be beneficial to the other, but actualising these benefits requires a deep understanding of the topics; something that can seem overwhelming due to the sheer amount of possibilities and technologies.
Check out these articles:
- How To Regulate IoT Cybersecurity
- IoT Solutions World Congress Shows The Way To Smarter, More Secure Connectivity
- Zebra Study: Record Number Of Enterprises Becoming “Intelligent” With Growing IoT Investments
- Smart Factory With IoT: igus Develops Smart Plastics App For Fanuc FIELD System
- The Importance Of Safeguarding An IIoT Network
- The Key To Unlocking The Value Of IoT In Manufacturing
CLICK HERE FOR LATEST NEWS.
READ CURRENT AND PAST ISSUES OF IAA.
KEEP YOURSELF UPDATED, SUBSCRIBE TO IAA NOW!