Sicher verkettet: Vollständiges Erfassen der Software Supply Chain im IoT

Inhaltsverzeichnis

Die Wartung und Absicherung von Software für Anwendungen im Internet of Things (IoT) stellt eine noch größere Herausforderung dar als die Pflege von Backendsystemen. Neue regulatorische Anforderungen werden Hersteller vernetzter Produkte zu verbindlichen Services wie Patches und Updates verpflichten. Das gilt insbesondere für Produkte, die hohe Ansprüche an die Betriebssicherheit stellen, etwa Fahrzeuge. Dabei sind das Erfassen der Softwarebestandteile und die Anpassungen über die gesamte Lebenszeit des Produkts ein komplexes Unterfangen, da Hard- und Softwareentwicklung gemeinsam in einem Netzwerk mit Zulieferern erfolgen.

Aufgrund der steigenden Cybersicherheitsrisiken stehen in naher Zukunft weltweit zusätzliche Standards und Vorgaben für die Absicherung vernetzter Produkte an. Im Automobilbereich werden beispielsweise im Rahmen der UNECE WP.29 neue Vorgaben zur Typenzulassung von Kraftfahrzeugen festgelegt, die Hersteller bis 2024 umsetzen müssen. Dazu gehört die Dokumentation des Entwicklungsprozesses, sichere Over-the-Air-Updates (OTA) und die Bereitstellung von Informationen zur Software, die auf Fahrzeugen installiert ist.

Angesichts des Angriffes auf den Softwarehersteller Solarwinds hat in den USA das Weiße Haus eine Executive Order erlassen, die die IT-Industrie zum Entwickeln von Standards zum Austausch von Software-Bill-of-Materials (SBoM) verpflichten soll. Ziel ist es, Angriffe auf die Softwarelieferkette frühzeitig zu erkennen und Cybersicherheitsrisiken besser zu bewerten. In Europa hat die EU-Kommission jüngst mit dem European Cybersecurity Resilience Act eine Verordnung angekündigt, die die Industrie ebenfalls auf Standards und Maßnahmen zum Absichern von Produkten im Internet der Dinge verpflichten soll. Es ist damit zu rechnen, dass sich die Dokumentation von Softwareentwicklungsprozessen und der Softwarelieferkette als allgemeiner Industriestandard für Produkte des IoT etabliert. Es lohnt sich, das Thema frühzeitig im Entwicklungsprozess anzugehen.

Referenzsystem

Dieser Artikel beschreibt den Aufbau eines Referenzsystems, mit dem sich der Weg der Software vom Entwickeln und Kompilieren bis zur Installation lückenlos nachvollziehen lässt. Hersteller können damit Softwarekomponenten auf Integrität prüfen und einen Herkunftsnachweis für installierte Software ableiten.

Die Heise-Konferenz zum IoT

Am 10. und 11. Mai findet die building IoT bereits zum siebten Mal statt. Nach der Online-Ausgabe von 2021 planen die Veranstalter heise Developer, iX und dpunkt.verlag für dieses Jahr wieder eine Konferenz vor Ort im IHK Haus der Wirtschaft in Karlsruhe. Den beiden Konferenztagen ist ein Workshop-Tag am 9. Mai vorgeschaltet.

Das Programm der Konferenz bietet an zwei Tagen in drei Tracks zahlreiche Vorträge vom Prototyping über Test-driven IoT bis zur Verarbeitung der Daten am Edge und in der Cloud mit Machine Learning.

Dem Absichern der Supply Chain im IoT widmet sich sowohl ein Vortrag als auch ein ganztägiger Workshop. Letzteren richtet der Autor dieses Artikels aus.

Das Referenzsystem basiert auf einem realen Demonstrator, der im Rahmen eines IoT-Entwicklungsprozesses für die Automobilindustrie entstand. Es bildet einen Software-Deployment-Prozess ab und dokumentiert die Prozessschritte der Softwareabnahme bis zum Verteilen und Betrieb auf einem IoT-Endgerät. Dazu integriert es Entwicklungssysteme mit Prozessschritten in einer CI/CD-Pipeline (Continuous Integration/Continuous Delivery). Die Dokumentation der Prozessschritte erfolgt dezentral in einem Distributed-Ledger-System.

Der Demonstrator setzt sich aus folgenden Komponenten und Teilsystemen zusammen:

1. GitLab als System zum Verwalten des Codes und Definieren einer CI/CD-Pipeline zum Erstellen neuer Firmware-Versionen, für automatisierte Tests und für Audits.
2. asvin-Plattform zum OTA-Verteilen der auditierten Firmware, zum Verwalten der IoT-Endgeräte und zur Darstellung der installierten Software-Bill-of-Material.
3. ESP8266-Mikrocontroller als IoT-Edge-Module und zur Simulation einer Prozessoreinheit in einem Fahrzeug.
4. Hyperledger-Besu-Client als verteiltes System zum Archivieren der Softwarefingerabdrücke und Metainformationen zu den Prozessschritten über Etherium Smart Contracts in einen privaten Distributed Ledger auf Basis von Hyperledger.

In dem Demonstrationsaufbau lassen sich alle Prozessschritte vom Software-Deployment bis zur Installation auf dem IoT-Endgerät dokumentieren. Das dezentrale Speichern in einem Distributed Ledger soll die Resilienz der archivierten Prozessdaten maximieren und den Datenaustausch in einem dezentralen Lieferantennetzwerk vorbereiten. Alternativ lässt sich diese Komponente durch eine Datenbank auf einem zentralen Server oder in der Cloud abbilden.

Archivieren der Prozessschritte

Die Dokumentation der Softwareentwicklungsprozesse und Lieferketten ist ein wichtiger Teil der Bestrebungen, die Systemsicherheit und das Risikomanagement im IoT zu verbessern. Wenn bekannt ist, welche Softwarekomponenten in welchen IoT-Endgeräten eingebaut sind, lassen sich Geräte auf Basis der Dokumentation auf bekannte Schwachstellen prüfen. Das sind wichtige Informationen im Rahmen des Risikomanagements sowie einer Patch- und Update-Strategie für Hersteller und Aufsichtsbehörden. Im Demonstrator lässt sich die Umsetzung der neuen Anforderung praktisch erproben.

Da die einzelnen Prozessschritte der Softwarelieferkette im Distributed Ledger dokumentiert sind, kann jeder nachfolgende Schritt die Gültigkeit der vorherigen Aktionen über den Abgleich im Ledger überprüfen. Beispielsweise lassen sich Fingerabdrücke der Software als Hashwerte vergleichen. Unerwartete Abweichungen weisen auf einen Bruch der Software- oder Prozessintegrität hin, wenn beispielsweise statt einer auditierten Firmware eine andere vorliegt. Dafür ist im besten Fall ein Fehler in der Prozesskette der Grund, im schlechtesten Fall handelt es sich um eine Manipulation, um beispielsweise Schadcode in Firmware-Distributionen einzuschleusen – ein klassischer Supply-Chain-Angriff. In beiden Fällen sollte die Softwaredistributionsplattform einen Alarm auslösen und die Auslieferung der Firmware abbrechen oder das IoT-Edge-Device den Firmware-Flash ablehnen.