Tens of millions of IoT devices are now in use worldwide, and their software has numerous vulnerabilities. Do we have to accept the fact that countless security vulnerabilities are not eliminated by updates due to a lack of technical requirements? At the very least, the behavior of providers, users and authorities responsible for cyber security does not indicate any proactive reactions or actions that could change this questionable security situation in the short or medium term.

The causes of these vulnerabilities in IoT products are manifold. First and foremost is the lack of cybersecurity standards for manufacturers and operators of IoT devices.

In comparison to electrical product safety - where there are highly developed and predominantly practical industry standards - the standardization bodies have so far been very inactive when it comes to IoT security. A few exceptions from the past year are the ETSI basic document EN 303 645 and the standard document NISTIR 8259 from the US National Institute of Standard and Technology. The latter is primarily aimed at IoT device manufacturers and is entitled Foundational Cybersecurity Activities for IoT Device Manufacturers. This document contains two helpful chapters. One deals with the aspects before the delivery of an IoT device (pre-market phase). The other deals with the phase after product delivery (post-market phase). Here, under '4.2.4 Software updates', you will find practical suggestions for avoiding IoT update problems. As automation has identical problems, the NISTIR 8259 document is also suitable for the smart factory.

In automation technology, we have now achieved a very high level of networking for the entire OT level (OT: Operation Technology) with the help of various interfaces and protocols.

Local interfaces available

In principle, an automatic software update system for IoT devices consists of three components: maintainer workstation as the update source, target device as the update target and update server as the functional link. The required IT security is ensured by a public key infrastructure (PKI). If the target device cannot be connected directly to the server for technical reasons, an update gateway is interposed as an agent.

© SSV Software Systems

IP-based couplers - edge gateways - can even be found at the 'edge' to IT. Company-wide overall networking is therefore now also in place across the board. In many cases, it extends from the last IO-Link sensor hub in a production cell via all controllers more or less directly to the IT level and therefore indirectly to the Internet in any case. In this respect, it would be reasonable to assume that all networked OT assemblies also have end-to-end device management - including the ability to install software updates as required. The question that every OT technology manager should actually be asking themselves is: How do my IO-Link sensor supplier, my control provider, the frequency inverter and edge gateway manufacturer and all the other device manufacturers actually deal with software updates so that we don't get the same problems in our smart factory as we do in the IoT world?

The answers are often unsatisfactory. Many assemblies at OT level can only be updated by a specialist on site via very special (hardware-related) interfaces and protocols. The variety of interfaces includes USB, JTAG, UART (TTL, RS232, RS485), CAN or other manufacturer-specific ISP variants (ISP: In-System Programming). In some cases, these interfaces are not freely accessible. They are located inside the module (e.g. JTAG). In some cases, a special sequence of actions is required for the software update process (for example: First press button X, then start PC software Z within Y seconds, etc.).

Due to these details, it is therefore not easily possible in practice to connect OT assemblies to a central update server and, if required, to equip them fully or semi-automatically with a new software version, as is the case with smartphones, tablets, IP TVs and networked cars. But it is not impossible either.

Software update systems as retrofit

Klaus-Dieter Walter is a member of the management board at SSV Software Systems.

© SSV Software Systems

In order to guarantee the necessary cybersecurity in a networked smart factory, consistent software update processes with the highest possible degree of automation for all OT devices would of course be desirable. This does not require the entire device base to be replaced, as modern software update solutions can now also be retrofitted. However, component manufacturers and smart factory operators can only develop such processes together. There are suitable industry associations in German-speaking countries that could get something like this off the ground via working groups. The corresponding NISTIR 8259 software update questionnaire is a good starting point for the first steps.

At the latest when digital twins and AI-based edge applications with pre-trained machine learning models find their way into automation landscapes on a broad front, automated configuration and software updates will no longer be possible - see DevOps in the IT world (DevOp: team-based solution approach from development and operation. This refers to continuous further development and the ongoing integration of new software components into operations).