All the small things

von Dr. Lothar Burger

Die Erkenntnis, dass IT-Produkte Sicherheitsanforderungen erfüllen müssen und im Unternehmen mit professionellem Anspruch zu betreiben sind, ist mittlerweile State of the Art. Doch bei Geräten im Internet of Things – IoT – bricht sich diese Erkenntnis nur langsam Bahn und kommt mit Verzögerung in der gelebten Praxis an. Wir beleuchten die speziellen Herausforderungen bei der Verwaltung von IoT-Devices und stellen aktuelle Managementansätze entlang des Lebenslaufs der kleinen Geräte vor.

oT-Geräte finden sich mittlerweile in Unternehmensnetzen aller Größenordnungen, sei es in Form von vernetzten Überwachungskameras, Bewegungssensoren in Konferenzräumen, Smart-TVs in Foyers, smarten Kaffeemaschinen in Büroküchen, Bluetooth-Tags an Ladungsträgern oder mit Sensoren und Aktoren ausgestatteten Fertigungsmaschinen in Produktionshallen.

Manche dieser Geräte fristen ein Dasein als sogenannte Schatten-IT, weil sie unter Umgehung von lästigen IT-Beschaffungs- und Inbetriebnahmeprozessen von Fachabteilungen gekauft und installiert worden sind. Andere Käufe fanden zwar unter Mitwirkung der IT-Abteilung statt, befinden sich jedoch lediglich in einer reaktiven Verwaltung. Vielleicht sind sie über die Monate und Jahre auch wieder in Vergessenheit geraten, weil der ursprüngliche Anschaffungszweck inzwischen obsolet ist. Solche Geräte fallen im Netzwerk möglicherweise erst wieder auf, nachdem sie einem Angriff zum Opfer gefallen und Mitglied eines IoT-Botnetzes geworden sind.

Es gibt sicherlich IT/OT-Abteilungen oder speziell dafür eingerichtete Teams, die IoT-Geräte mit der erforderlichen Sorgfalt betreiben. Die Vielzahl an Berichten über Sicherheitsvorfälle legt jedoch nahe, dass viele IoT-Devices nicht professionell verwaltet werden und daher ein ständiges Sicherheitsrisiko darstellen. Die oben aufgeführten Beispiele für IoT-Anlagen zeigen, dass nicht nur große, sondern auch mittlere und kleine Unternehmen von dieser Problematik betroffen sein können.

Ebenso wie klassische IT- und Netzwerk-Geräte müssen IT-Verantwortliche auch IoT-Devices professionell verwalten – also IoT-Devicemanagement betreiben. Dies umfasst den gesamten Lebenszyklus – von Installation, Inbetriebnahme, Überwachung, SW-Aktualisierung bis zur geregelten Außerbetriebnahme.

Besonderheiten von IoT-Geräten

Viele der Verwaltungsaufgaben für IoT-Geräte sind bereits aus dem klassischen IT-Management oder dem Mobile Device Management (MDM) bekannt. Die Verwaltung von IoT-Geräten ist jedoch auch mit einigen speziellen Herausforderungen verbunden. So ist absehbar, dass sich in manchen Unternehmensumgebungen zukünftig mehr IoT-Geräte als klassisches IT-Equipment finden. Die Verfahren und Werkzeuge für die Verwaltung von IoT-Devices müssen daher massentauglich sein.

Und obwohl es auch im IoT einen Trend zur IP-basierten Ende-zu-Ende-Kommunikation gibt, können IT-Verantwortliche jedoch nicht in jedem Fall von einer solchen Konstellation ausgehen. IoT-Geräte befinden sich oft in speziellen Funknetzen mit begrenzter Bandbreite wie etwa Bluetooth Low Energy (BLE), Bluetooth Mesh, Zigbee (IEEE 802.15.4) oder LoRaWAN. Die Kommunikation mit IoT-Plattformen im Edge oder in der Cloud ist in solchen Fällen nur über zwischengeschaltete Applikations-Gateways möglich. Schmalbandige Funknetze können auch verhindern, dass sich Softwareupdates auf IoT- Umgebungen ausrollen lassen. Der Betreiber solcher Geräte muss sich dieser Problematik bewusst sein und beispielsweise im Netzwerkdesign passende Gegenmaßnahmen ergreifen, damit etwaige Sicherheitslücken nicht ausgenützt werden können.

Der nächste Aspekt ist der Zugriff auf die Umgebung: IoT-Geräte können mobil oder an schwer zugänglichen Orten installiert sein. Vor-Ort-Wartungsarbeiten sollten daher möglichst nur in seltenen Notfällen erforderlich sein. Zudem handelt es sich bei IoT-Anlagen oft um sogenannte "Constrained Devices" mit beschränkten Rechen- und Speicherkapazitäten. Die Installation von separaten Agenten für Monitoring und Administration ist bei solchen Geräten nur eingeschränkt oder gar nicht möglich.

Zu bedenken gilt auch, dass batteriebetriebene IoT-Geräte typischerweise mit sehr kurzen Aktivphasen arbeiten, um eine lange Batterielebensdauer zu ermöglichen. Solche Anlagen sind nicht jederzeit erreichbar. Häufige Administrationseingriffe oder Softwareaktualisierungen können zu einer unerwünschten Verkürzung der Batterielebensdauer führen. Schließlich besitzen IoT-Devices oft keine direkte Benutzerschnittstelle in Form von Display oder Tastatur. Inbetriebnahme und Konfiguration sind bei solchen Geräten nur über das Netzwerk möglich.

Lebenszyklus von IoT-Geräten

Die IoT-Managementfunktionen lassen sich nach den klassischen Phasen im Produktlebenszyklus einordnen: Beginning of Life, Middle of Life und End of Life. Bild 1 gibt einen Überblick über die Inhalte der einzelnen Lebenszyklusphasen. Das Bild zeigt einen idealisierten linearen Ablauf, in der Realität können auch Zyklen vorkommen. Beispielsweise sind ein Zurücksetzen auf den Auslieferungszustand oder ein Eigentümerwechsel typischerweise mit einem erneuten Onboarding und anschließender Neukonfiguration verbunden.

Die Phase Beginning of Life umfasst alle Aktivitäten, die erforderlich sind, bevor ein Gerät den regulären Betrieb aufnehmen kann. In Middle of Life hat das IoT-Device seinen regulären Betrieb aufgenommen und schickt zum Beispiel regelmäßig Sensordaten an eine Applikation in der Cloud. Diese Phase wird von Administrationsfunktionen begleitet, die prinzipiell aus dem klassischen IT-Management bekannt sind, jedoch IoT-spezifische Anforderungen erfüllen müssen.

Das End of Life handhaben IT-Verantwortliche oft nachlässig, die Phase ist jedoch aus mehreren Gründen wichtig: Die Datenbereinigung verhindert, dass kritische Informationen in falsche Hände geraten können. Die Deaktivierung zielt darauf ab, dass das Gerät nicht weiterhin Kommunikation etwa über Mobilfunk betreibt und dabei Kosten verursacht oder Funknetze stört. Eine zeitnahe physische Deinstallation kann in Einzelfällen schwer zu realisieren sein, insbesondere dann, wenn sich das Gerät an einem Standort außerhalb der Hoheit des Betreibers befindet. Umso wichtiger ist es, dass Datenbereinigung und Deaktivierung zuverlässig und unumkehrbar über das Netzwerk möglich sind.

Im Rahmen dieses Artikels können wir nicht alle Inhalte des Produktlebenszyklus im Detail behandeln. Im Folgenden beleuchten wir zwei Themen ausführlicher: das Onboarding in der Phase Beginning of Life und das Sicherheitsmanagement in Middle of Life.

Onboarding von IoT-Geräten

Anstelle des Begriffs Onboarding finden sich in der Literatur auch alternative Begriffe wie Commissioning, Bootstrapping oder Provisioning. Es geht dabei immer darum, dass ein IoT-Gerät nach der physischen Installation in die Lage versetzt werden muss, ein Kommunikationsnetzwerk zu nutzen und über dieses mit einer meist zentralen Applikation zu kommunizieren. Dabei kann es sich um ein Applikationsgateway oder eine IoT-Plattform im Edge oder in der Cloud handeln.

Ein typisches IoT-Device lässt sich in der Regel nicht schon bei der Produktion so weit parametrisieren, dass es nach der Installation in der Zielumgebung bereits nahtlos seine Funktion aufnehmen kann. Daher müssen IT-Abteilungen das Gerät im Onboarding zunächst mit den erforderlichen Parametern versehen.

Onboarding-Elemente finden sich in nahezu allen Protokollen und Frameworks, die für das IoT relevant sind. Beispiele sind das Pairing und Bonding in Bluetooth LE, Device Provisioning in Bluetooth Mesh, Network-Join in Zigbee, Bootstrap in Lightweight M2M (LWM2M) oder Device Onboarding in OPC UA. Vielfach lassen solche Verfahren unterschiedliche Sicherheitsstufen zu, von der ungesicherten Aufnahme von Geräten über die Verwendung von netzwerkweiten Preshared-Keys bis zum Einsatz von Zertifikaten.

Die Erfahrung zeigt, dass die ungesicherte oder schwach gesicherte Aufnahme von IoT-Geräten in ein Netzwerk ein Einfallstor für Angriffe ist. IoT-Geräte mit unbekannter oder unzureichend verifizierter Identität oder solche, die nicht verifizieren können, ob sie sich in das richtige Netz eingebucht oder sich mit dem richtigen Applikationsserver verbunden haben, sind nicht nur ein Sicherheitsrisiko, sondern stellen auch das Assetmanagement vor Herausforderungen.

Im Folgenden stellen wir zwei aktuelle Standards für das Onboarding von IoT-Geräten vor: Wi-Fi Easy Connect für das Netzwerk-Onboarding und FIDO Device Onboarding für die Applikationsebene.

Netzwerk-Onboarding mit Wi-Fi Easy Connect

Wi-Fi Easy Connect [1] wurde von der Wi-Fi Alliance entwickelt, um typischen IoT-Geräten ein standardisiertes, einfaches und sicheres Onboarding in WLANs zu ermöglichen. Die initiale Spezifikation stammt aus dem Jahr 2018, seit 2022 liegt die Version 3.0 vor. Das zugrunde liegende Protokoll wird auch als Device Provisioning Protocol (DPP) bezeichnet. DPP verwendet Public-Key-Kryptographie, wobei der Public Key der Identifikation eines Geräts dient und der Private Key sicher im Gerät gespeichert ist.

Bild 2 gibt einen Überblick über die Instanzen und Protokollphasen in Wi-Fi Easy Connect. Das neue aufzunehmende Gerät wird als Enrollee bezeichnet. Der Configurator hat die Aufgabe, neue Devices zu authentifizieren und zu konfigurieren, sodass sie anschließend über einen Access Point Zugang zum Netz erhalten können. Der Configurator kann unterschiedlich realisiert sein, zum Beispiel als App auf einem mobilen Gerät wie Smartphone oder Tablet oder auch als Softwarekomponente auf einem Access Point.

Das Bootstrapping bildet die erste Phase des Protokolls. Hierbei erfasst der Configurator grundlegende Informationen über den Enrollee. Dazu gehören dessen öffentlicher Key und die vom Enrollee benutzten Wi-Fi-Kanäle für das On-

boarding. Die Übertragung der Bootstrap-Information erfolgt out-of-band, also außerhalb eines Wi-Fi-Kanals. Mögliche Übertragungswege sind Scannen eines am Zielgerät angebrachten QR-Codes, Übertragung mittels NFC oder Bluetooth oder Bereitstellung durch den Hersteller über das Internet.

In der Authentication-Phase führen Configurator und Enrollee über einen der spezifizierten Wi-Fi-Kanäle eine ein- oder beidseitige Authentifizierung durch. In der abschließenden Configuration-Phase teilt der Configurator dem neuen Gerät in verschlüsselter Form alle erforderlichen Daten für den Netzzugang am Access Point mit, sodass der Enrollee im vierten Schritt sich als Client in das Wi-Fi-Netz einbuchen kann.

In der Configuration-Phase kann das aufzunehmende Device zudem optional eine URL übergeben, die auf eine sogenannte Manufacturer Usage Description (MUD) nach RFC8520 verweist. MUDs sind dazu geeignet, IoT-Geräte im Netzwerk zu identifizieren und deren Kommunikationsverhalten in der Betriebsphase zu überwachen beziehungsweise Anomalien im Kommunikationsverhalten festzustellen. Dies setzt allerdings voraus, dass Switches und Managementkomponenten des Netzwerks solche MUDs unterstützen.

Applikations-Onboarding mit FIDO Device Onboard

Das beschriebene Netzwerk-Onboarding stellt die grundsätzliche Kommunikationsfähigkeit eines IoT-Geräts her. Dies ist jedoch noch nicht ausreichend, um mit einer Applikation auf einem Edge-Server oder mit einer IoT-Plattform in der Cloud zu kommunizieren. Für diesen finalen Schritt ist ein Applikations-On-boarding erforderlich. Dies spezifiziert der Standard FIDO Device Onboard (FDO) [2] der FIDO Alliance (Fast IDentity Online). Der Standard wurde im Jahr 2021 erstmals veröffentlicht, seit 2022 liegt er in der Version 1.1 vor. Er ermöglicht es, IoT-Geräte auf Applikationsebene sicher und automatisiert in Betrieb zu nehmen, wobei weder der Endanwender noch die Zielplattform schon bei der Herstellung des Geräts bekannt sein müssen (late binding).

Eine Alternative wäre, das Gerät bereits beim Hersteller passend zu konfigurieren, sodass es sich beim Kunden ohne weitere Konfigurationsschritte aktivieren lässt. Dies ist jedoch allenfalls bei teuren IoT-fähigen Maschinen eine realisierbare Option. Bei Massengeräten ist eine solche Maßnahme nicht wirtschaftlich darstellbar, zumal bei solchen Geräten der Endabnehmer normalerweise erst am Ende der Lieferkette bekannt ist. Bild 3 gibt einen Überblick über das FIDO-Verfahren von der Herstellung des IoT-Geräts bis zur Einbuchung in die Applikation beziehungsweise IoT-Plattform. Die Nummern in der Abbildung kennzeichnen die zeitliche Abfolge.

Bei der Herstellung landet ein FIDO-Client auf dem Gerät, das zudem über eine Geräte-ID (GUID), einen sicher gespeicherten Private Key, den Public Key des Herstellers und eine oder mehrere Adressen beziehungsweise Namen von Rendezvous-Servern verfügt. Letztgenannte können sowohl im Internet als auch in einem Intranet lokalisiert sein. Ihre Adressen oder Namen sind dem Endgerät durch die Konfiguration beim Hersteller bekannt. Rendezvous-Server ermöglichen es, dass die Entscheidung, mit welcher Gegenstelle ein IoT-Gerät kommunizieren soll, erst im Rahmen der Inbetriebnahme gefällt werden muss.

Das Gerät wird von einem digitalen Dokument, dem sogenannten Ownership Voucher, begleitet. Dieser enthält unter anderem die Public Keys von Hersteller und Gerät. Der Voucher wandert parallel zum Gerät entlang der Lieferkette, wobei mit jeder Besitzübergabe ein zusätzlicher Eintrag im Ownership Voucher entsteht. Dieser enthält den Public Key des Käufers, die Geräte-ID und sonstige Gerätedaten und ist vom Verkäufer signiert. Der aktuelle Besitzer kann somit seine Besitzrechte jederzeit mithilfe seines Private Keys nachweisen. Für die Besitzübergabe ist lediglich ein weiterer Eintrag im Ownership Voucher erforderlich, das zugehörige Gerät musss dazu weder entpackt noch aktiviert werden.

Vor der Inbetriebnahme registriert der Eigentümer das Gerät beim Rendezvous-Server zusammen mit der Adresse der Zielplattform, in die das Device sich einbuchen soll. Während der Inbetriebnahme fragt das Gerät die Adressdaten der Zielplattform beim Rendezvous-Server ab und verbindet sich dann mit der Zielplattform. Mithilfe der Daten, die im Gerät gespeichert sind, und der Inhalte des Ownership Vouchers können sich Gerät und Zielplattform gegenseitig authentifizieren. Die Managementkomponenten auf der Zielplattform können ab diesem Zeitpunkt die weitere Konfigurierung und die Administration der Anlage übernehmen. Das IoT-Gerät ist mit diesem Schritt in die Betriebsphase (Middle of Life) übergegangen.

Sicherheitsmanagement in der Betriebsphase

Der sichere IoT-Betrieb erfordert mehrere Bausteine. Dazu gehört, dass der Betreiber die installierten Geräte, deren Funktionen, Standorte, Softwarestände und so weiter kennt. Ein geregeltes Onboarding verbunden mit einem jederzeit aktuellen Assetmanagement ist dazu unabdingbar. Weitere Elemente sind das Vulnerability- und das Incident-Management. Das Vulnerability-Management verfolgt Sicherheitsschwachstellen und sorgt dafür, dass diese behoben oder zumindest durch Gegenmaßnahmen gemildert werden. Das Incident-Management stellt sicher, dass auf aktuelle sicherheitsrelevante Ereignisse zeitnahe, angemessene und nachvollziehbare Reaktionen erfolgen.

Es reicht jedoch nicht aus, dass der Betreiber diese Prozesse implementiert. Sie sind nur dann wirkungsvoll, wenn korrespondierende Prozesse auf der Seite des Geräteherstellers sie unterstützen. Eine Übersicht der Zusammenhänge zeigt Bild 4. Aktuelle Sicherheitsstandards und -empfehlungen wie etwa ETSI EN 303 645 [3] in Europa oder NISTIR 8259 in den USA heben die Sicherheitsverantwortung des Geräteherstellers hervor. Der Anbieter hat die Pflicht, Sicherheitsdokumentationen bereitzustellen sowie ein Vulnerability- und Incident-Management für sein Produkt zu etablieren.

Im Rahmen des Vulnerability-Managements verfolgt er zum Beispiel Schwachstellen in verwendeten Softwarekomponenten. Seine Kommunikation mit den Kunden stellt sicher, dass diese über Gefährdungen und geeignete Gegenmaßnahmen informiert sind. Zur Behebung von akuten Schwachstellen oder in regelmäßigen Zeitabständen stellt er den Kunden Updates zur Verfügung. Diese Verpflichtungen enden erst mit dem Auslaufen der Supportphase für das Produkt. In manchen Fällen kann ein Kunde ein IoT-Gerät nicht zeitgleich mit dem Ende des Supports außer Betrieb nehmen. Dies stellt ein Sicherheitsrisiko dar, dem durch zusätzliche risikomindernde Maßnahmen wie etwa Abschottung gegen externe Zugriffe begegnet werden kann.

Fazit

Der sichere und wirtschaftliche Betrieb von IoT-Geräten ist mit Herausforderungen verbunden, denen sich in Zukunft nahezu jedes Unternehmen stellen muss. Dies erfordert auf Betreiberseite die passenden Personalressourcen, Kenntnisse, Prozesse und Tools. Genauso wichtig ist es jedoch auch, bei der Auswahl von IoT-Geräten nicht nur auf die primäre Funktionalität, sondern auch auf sekundäre, betriebsrelevante Eigenschaften der Devices zu achten. Dazu gehören die Unterstützung von Verwaltungsfunktionen, die dem aktuellen Stand der Technik entsprechen, ebenso wie die Bereitstellung eines angemessenen Sicherheitsmanagements vonseiten des Geräteherstellers.

Devicemanagement im IoT