Geräte-Cybersecurity aktuell halten

Sichere Software-Updates für alle IoT-Geräte

24. August 2022, 17:53 Uhr | Klaus-Dieter Walter
SSV Software Systems
Klaus-Dieter Walter ist neben seiner Tätigkeit als CEO von SSV Software Systems auch durch Vorträge, Fachbücher und Beiträge in Fachzeitschriften bekannt.
© SSV Software Systems

Die bestehenden Standards und Normen zur Cybersecurity in vernetzten Anwendungen sind so umfassend und vielschichtig, dass praktisch alle IoT-Geräte eine sichere Möglichkeit für Software-Updates erfordern. Nur so lassen sich die Geräte immer auf dem aktuellen Stand von Technik und Normung halten.

Die hochentwickelte Norm ETSI EN 303 645 für die Cybersecurity im Internet of Things (IoT) fasst die Anforderungen unter der Überschrift „Keep Software Updated“ zusammen. Man findet dort unter anderem 15 Detailanforderungen plus 13 Beispiele für sichere Software-Updates von IoT-Baugruppen. Zur Sprache kommen dabei die Authentisierungs- und Authentifizierungsaspekte sowie Empfehlungen bezüglich automatisierter Update-Services. Auch in der NISTIR 8259 und der Ergänzung NISTIR 8259A wird das Thema behandelt. Entsprechendes gilt für die umfangreiche und weitreichende IEC 62443, die sich im deutschsprachigen Raum zunehmend als Cybersecurity-Norm für die Automatisierungstechnik etabliert. Sowohl Baugruppenhersteller als auch Betreiber vernetzter Automatisierungslösungen sollten sich daher mit dem Thema befassen, um zumindest in ihrem Verantwortungsbereich dafür zu sorgen, dass der aktuelle Stand der Technik auch umgesetzt wird.

Anbieter zum Thema

zu Matchmaker+

Überschaubare Connectivity-Aufgaben

Automatische Software-Update-Lösung für die Automatisierung
Abbildung 1: Eine automatische Software-Update-Lösung für die Automatisierung besteht aus drei Bausteinen: 1) Die Maintainer Workstation als Update-Quelle, 2) das Target Device als Ziel des Updates und 3) der Update Server als funktionales Bindeglied. Die IT-Sicherheit erfordert eine dem Stand der Technik entsprechende Teilnehmerauthentifizierung, etwa per PKI und X.509-Zertifikaten.
© SSV Software Systems

Aus kommunikationstechnischer Sicht sind der Erzeuger eines Software-Updates (z.B. der Maintainer einer Embedded-System-Firmware) und die eigentlichen Zielsysteme über ein IP-Netzwerk unterschiedlicher Ausdehnung und Komplexität miteinander verbunden. Vor Edge-Baugruppen oder in Automatisierungskomponenten eingebetteten Mikrocontrollern, die sich aus unterschiedlichen Gründen nicht direkt in eine solche Netzwerkinfrastruktur einbinden lassen, wird meist ein geeignetes (Update-)Gateway installiert. Es sorgt für die nötigen Protokoll- und Datenumwandlungen sowie die zwingend erforderliche Cybersecurity des jeweiligen Software-Update-Zielsystems. Schließlich müssen sowohl Authentizität als auch Integrität eines Software-Updates unter allen Umständen gewährleistet sein, bevor der neue Code erstmals ausgeführt wird.

Zwischen Update-Quelle und Download-Ziel befindet sich eine Rechnerplattform mit einem speziellen Update-Service-Prozess. Der Maintainer kann von seiner Workstation aus jederzeit ein neues Update an den Service übermitteln (Upload). Die Update-Gateways oder andere Zielbaugruppen prüfen von Zeit zu Zeit über entsprechende Anfragen, ob für sie jeweils neue Updates vorliegen. Ist das der Fall, werden die Updates heruntergeladen (Download), in den jeweiligen Programmcodespeicher übertragen und anschließend ausgeführt.

Authentifizierung als Herausforderung

Vor der Nutzung eines digitalen Service müssen sich sowohl menschliche als auch maschinelle Nutzer zunächst einmal gegenüber dem Serviceerbringer authentisieren.
Abbildung 2: Vor der Nutzung eines digitalen Service müssen sich sowohl menschliche als auch maschinelle Nutzer zunächst einmal gegenüber dem Serviceerbringer authentisieren. Die Gesamtkomplexität dieses Themengebiets wird in der Praxis nach wie vor vielfach unterschätzt. Aus diesem Grund erfolgen Cyberangriffe vielfach über Benutzerschnittstellen.
© SSV Software Systems

Will man in der digitalen Welt einen Service nutzen, muss man sich gegenüber dem Serviceerbringer zunächst einmal mittels geeigneter Faktoren authentisieren (also einen möglichst „eindeutigen“ Nachweis liefern), damit die Nutzeridentität authentifizierbar wird. Es gibt verschiedene serverseitige Methoden, um Nutzer zu authentifizieren. Sie hängen von den jeweiligen Faktoren ab und lassen sich in drei Kategorien gliedern:

Wissen (Knowledge Factors): Hier geht es um den Nachweis der Kenntnis einer sehr speziellen Information, also beispielsweise das Wissen um ein Passwort, eine Personal Identification Number (PIN) oder die Antwort auf eine bestimmte Frage.

Besitz (Ownership Factors): Im Besitz des Servicenutzers befindet sich ein bestimmter Gegenstand, etwa eine ID-Karte, ein Smartphone mit einem bestimmten Hardwaremerkmal oder einer besonderen Software, ein Sicherheits-Token in Form eines USB-Sticks. Auch ein Mikrochip-Implantat auf RFID-Basis oder digitale Zertifikate fallen in diese Kategorie.

Körperliches Merkmal/Biometrie (Inherence Factors): Zu dieser Kategorie gehören verschiedene physische Eigenschaften oder biometrische Merkmale, die als Identitätsnachweis ausgewertet werden. Dafür sind Mess- und Auswerteverfahren für Fingerabdruck-, Iris- und Retinastruktur- sowie Gesichtserkennungsdaten einsetzbar.

Identitätsnachweismethoden sind einzeln (Ein-Faktor-Authentifizierung) oder in Kombination (Mehr-Faktor-Authentifizierung) anwendbar. So lässt sich beispielsweise ein Passwort mit einer ID-Karte kombinieren. Die ersten beiden Kategorien ermöglichen allerdings bei genauer Betrachtung nur eine implizite Identitätsprüfung durch den Serviceerbringer. Das Passwort als Geheimnis, das einer bestimmten Person beim Erzeugen des Benutzerkontos zugewiesen wurde, kann schließlich versehentlich oder durch einen Cyberangriff in den Besitz Dritter gelangen. Ein Smartphone mit SIM-Karte, Telefonnummer und App kann entwendet werden. Lediglich die Biometrie führt unter halbwegs normalen Umständen zu einem mehr oder weniger eindeutigen Identitätsnachweis.

Die praktische Umsetzung

Die kritischen Komponenten einer Update-Lösung sollten unter Zuhilfenahme geeigneter Normen und Werkzeuge auf mögliche Schwachstellen in den verschiedenen Kommunikationsschnittstellen untersucht werden.
Abbildung 3: Die kritischen Komponenten einer Update-Lösung sollten unter Zuhilfenahme geeigneter Normen und Werkzeuge auf mögliche Schwachstellen in den verschiedenen Kommunikationsschnittstellen untersucht werden. Des Weiteren wäre zu prüfen, ob zumindest der Update-Server für den laufenden Betrieb spezielle Sensoren zur Erkennung von Cyberangriffen benötigt.
© SSV Software Systems

Wegen der stark zunehmenden Anzahl von Cyberangriffen auf industrielle Anlagen ist die Cybersecurity einer automatisierten Software-Update-Lösung inzwischen die größte Herausforderung. Benutzername und Passwort zur Maintainer-Authentisierung beim Verbindungsaufbau zum Update-Server reichen als Identitätsnachweis definitiv nicht aus. Empfehlenswert ist der Einsatz einer Public-Key-Infrastruktur (PKI) aus dem Bereich der asymmetrischen Kryptografie, die auf mathematischen Einwegfunktionen beruht. Dabei erzeugen alle Kommunikationspartner jeweils ein digitales Schlüsselpaar, bestehend aus einem öffentlichen Schlüssel (Public Key) und einem geheimen Schlüssel (Private Key). Die öffentlichen Schlüssel werden zwischen den Teilnehmern, die direkt miteinander kommunizieren wollen, ausgetauscht (dafür ist keine besonders gesicherte Verbindung notwendig; der Tausch kann zur Not auch per E-Mail erfolgen). Der Sender einer vertraulichen Nachricht nutzt zum Verschlüsseln jeweils den Public Key des Empfängers. Dieser kann die Nachricht mit Hilfe seines Private Keys entschlüsseln. Auf die gleiche Art und Weise lassen sich auch die von den eingangs benannten Standards und Normen geforderten digitalen Signaturen zur Update-Sicherung erzeugen. In diesem Fall erzeugt der Nachrichtensender eine digitale Signatur mit Hilfe seines privaten Schlüssels, die der Empfänger mit dem Public Key des Senders überprüfen kann.

Vor dem echten Praxiseinsatz von Public/Private-Key-Lösungen ist allerdings noch ein weiteres Problem zu lösen: Der Empfänger eines Public Keys weiß nie genau, ob der Schlüssel wirklich vom Absender stammt – es könnte sich ja auch ein Cyberangreifer im Rahmen eines Identitätsdiebstahls als der gewünschte Absender ausgeben. Das Vertrauen in die Authentizität eines öffentlichen Schlüssels lässt sich über den zusätzlichen Einsatz digitaler X.509-Zertifikate herstellen. Bei diesen Zertifikatsdateien handelt es sich um überprüfbare Datensätze, die von einer (dritten) Instanz (Trusted Third Party) erstellt werden, der beide Kommunikationspartner vertrauen. Ein solches Zertifikat lässt sich dem jeweiligen Public Key verifizierbar zuordnen. Mit öffentlichen Schlüsseln und X.509-Zertifikaten als Besitzfaktor (Ownership Factor) sind dann von einem Update-Server sowohl der Maintainer als auch die Zielsysteme relativ sicher zu authentifizieren. Weil die Maintainer-Aufgaben (Upload der Updates zum Server) als besonders kritisch einzustufen sind, empfiehlt sich hier der Einsatz eines zweiten Authentisierungsfaktors. Geeignet wäre beispielsweise eine zusätzliche Smartphone-App, mit der dem Server bei jeder Maintainer-Anmeldung ein Einmalpasswort über einen zusätzlichen Übertragungskanal (also „Out-of-Band“) bestätigt werden muss.

Komponentenprüfung

Bei Anwendung der IEC 62443 sollte man die kritischen Kommunikationskomponenten einer solchen Software-Update-Lösung mittels geeigneter Prozesse auch gezielt überprüfen und die Ergebnisse entsprechend dokumentieren. Dabei geht es in erster Linie darum, die Eingangsschnittstellen des Update-Servers und Gateways beispielsweise über Penetrationstestverfahren (Pen-Test; Testwerkzeuge siehe unter https://www.esecurityplanet.com/applications/open-source-penetration-testing-tools/) zu untersuchen, um sicherzustellen, dass Zugriffe nur im Rahmen der vorgesehenen Funktionen und ausschließlich nach erfolgreicher Authentifizierung möglich sind. Dabei ist zu berücksichtigen, dass X.509-Zertifikate für ungültig erklärt werden können (Blacklist-Management-Prozess) und dass Update-Dateien zusätzliche digitale Signaturen besitzen sollten, die vor dem Schreibzugriff auf den Programmcodespeicher ebenfalls erfolgreich zu prüfen wären.

Der Autor: Klaus-Dieter Walter ist neben seiner Tätigkeit als CEO von SSV Software Systems auch durch Vorträge, Fachbücher und Beiträge in Fachzeitschriften bekannt.


Verwandte Artikel

SSV Software Systems GmbH

Industrie 4.0