Zigmillionen IoT-Geräte sind mittlerweile weltweit im Einsatz, deren Software zahlreiche Schwachstellen aufweist. Müssen wir uns damit abfinden, dass dabei unzählige Sicherheitslücken aufgrund fehlender technischer Voraussetzungen nicht durch Updates beseitigt werden? Zumindest sind am Verhalten der Anbieter, Anwender und für die Cybersicherheit zuständigen Behörden keine proaktiven Reaktionen beziehungsweise Aktionen erkennbar, die diese fragwürdige Sicherheitslage kurz- oder mittelfristig verändern könnten.

Die Ursachen für diese Schwachstellen in den IoT-Produkten sind vielfältig. In erster Linie sind die fehlenden Normen zur Cybersecurity für Hersteller und Betreiber von IoT-Geräten zu nennen.

Im Vergleich zur elektrischen Produktsicherheit – hier existieren hochentwickelte und überwiegend praxistaugliche Industrienormen – sind die Normierungsgremien beim Thema IoT-Sicherheit bisher sehr inaktiv. Einige wenige Ausnahmen aus dem vergangenen Jahr sind das ETSI-Grundlagendokument EN 303 645 und das Standard-Dokument NISTIR 8259 des US-amerikanischen National Institute of Standard and Technology. Letzteres adressiert primär die IoT-Device-Hersteller und trägt den Titel Foundational Cybersecurity Activities for IoT Device Manufacturers. Dieses Dokument enthält zwei hilfreiche Kapitel. Das eine befasst sich mit den Aspekten vor der Auslieferung eines IoT Device (Pre-Market-Phase). Das andere geht auf die Phase nach der Produktauslieferung ein (Post-Market-Phase). Hier findet man unter ‚4.2.4 Software Updates‘ durchaus praxistaugliche Anregungen, mit denen sich IoT-Update-Probleme vermeiden lassen. Da die Automatisierung identische Probleme hat, ist das NISTIR-8259-Dokument auch für die Smart Factory geeignet.

In der Automatisierungstechnik haben wir inzwischen für die gesamte OT-Ebene (OT: Operation Technology ) mit Hilfe verschiedener Schnittstellen und Protokolle einen sehr hohen Vernetzungsgrad erreicht.

Lokale Schnittstellen vorhanden

Ein automatisches Software-Update-System für IoT Devices besteht im Prinzip aus drei Bausteinen: Maintainer Workstation als Update-Quelle, Target Device als Ziel des Updates und Update-Server als funktionales Bindeglied. Die erforderliche IT-Sicherheit wird durch eine Public Key Infrastructure (PKI) gewährleistet. Lässt sich das Target Device aus technischen Gründen nicht direkt mit dem Server verbinden, wird ein Update-Gateway als Agent dazwischengeschaltet.

© SSV Software Systems

An der ‚Edge‘ zur IT sind sogar IP-basierte Koppler – Edge-Gateways – zu finden. Auch eine unternehmensweite Gesamtvernetzung ist daher mittlerweile durchgängig existent. Sie reicht vielfach vom letzten IO-Link-Sensorhub in einer Fertigungszelle über alle Steuerungen mehr oder weniger direkt bis in die IT-Ebene und somit indirekt auf jeden Fall bis ins Internet. Insofern wäre eigentlich davon auszugehen, dass auch für alle vernetzten OT-Baugruppen ein durchgängiges ‚Device Management‘ existiert – inklusive der Möglichkeit, bei Bedarf Software-Updates einzuspielen. Die Frage, die sich jeder OT-Technikverantwortliche eigentlich stellen müsste, ist: Wie gehen mein IO-Link-Sensoriklieferant, mein Steuerungsanbieter, der Frequenzumrichter- und Edge-Gateway-Hersteller sowie all die anderen Device-Hersteller eigentlich mit Software-Updates um, damit wir in unserer Smart Factory nicht die gleichen Probleme wie in der IoT-Welt bekommen?

Die Antworten sind oft nicht zufriedenstellend. Sehr viele Baugruppen in der OT-Ebene sind nur über sehr spezielle (Hardware-nahe) Schnittstellen und Protokolle durch einen Spezialisten vor Ort Update-fähig. Zur Schnittstellenvielfalt gehören etwa USB, JTAG, UART (TTL, RS232, RS485), CAN oder andere herstellerspezifische ISP-Varianten (ISP: In-System-Programming). In einigen Fällen sind diese Schnittstellen nicht frei zugänglich. Sie befinden sich im Inneren der Baugruppe (etwa JTAG). Teilweise ist für den Software-Update-Vorgang eine besondere Handlungssequenz erforderlich (beispielsweise: Erst die Taste X drücken, dann innerhalb von Y Sekunden die PC-Software Z starten usw.).

Aufgrund dieser Details ist es in der Praxis daher nicht ohne weiteres möglich, OT-Baugruppen mit einem zentralen Update-Server zu verbinden und bei Bedarf voll- oder halbautomatisch mit einer neuen Softwareversion auszustatten, wie das etwa von den Smartphones, Tablets, IP-TVs und vernetzten PKWs bekannt ist. Unmöglich ist es aber auch nicht. 

Software-Update-Systeme als Retrofit

Klaus-Dieter Walter ist Mitglied der Geschäftsführung bei SSV Software Systems.

© SSV Software Systems

Um die notwendige Cybersecurity in einer vernetzten Smart Factory zu gewährleisten, wären natürlich durchgängige Software-Update-Prozesse mit einem möglichst hohen Automatisierungsgrad für alle OT-Geräte wünschenswert. Dafür muss nicht die gesamte Gerätebasis ausgetauscht werden, da sich moderne Software-Update-Lösungen inzwischen auch per Retrofit nachrüsten lassen. Baugruppenhersteller und Smart-Factory-Betreiber können solche Prozesse aber nur gemeinsam entwickeln. Geeignete Branchenverbände, die so etwas über Arbeitsgruppen auf den Weg bringen könnten, gibt es im deutschsprachigen Raum. Die entsprechende Software-Update-Fragenliste der NISTIR 8259 eignet sich hier durchaus als roter Faden für die ersten Schritte.

Spätestens, wenn digitale Zwillinge und KI-basierte Edge-Anwendungen mit vortrainierten Machine-Learning-Modellen auf breiter Front Einzug in die Automatisierungslandschaften halten, geht es nicht mehr ohne automatisierte Konfigurations- und Software-Updates – siehe die sogenannten DevOps in der IT-Welt (DevOp: Team-basierter Lösungsansatz aus Development und Operation. Gemeint sind damit die kontinuierlichen Weiterentwicklungen sowie die fortlaufende Integration der neuen Software-Komponenten in den operativen Betrieb).