embeX

Produktsicherheit im IoT dauerhaft gewährleisten

9. Dezember 2022, 10:15 Uhr | Dr. Kai Borgwarth, Lukas Fey und Daniel Wisser

Die Cybersicherheit der Produkte im Feld systematisch über die gesamte Produktlebensdauer aufrecht zu erhalten, ist die Aufgabe von PSIRT – den Product Security Incident Response Teams.

Im März 2022 wurde durch eine Cyberattacke die Internetverbindung zu 9.000 Windrädern mit einer Kapazität von 11 GW unterbunden, so dass sich diese nicht mehr steuern ließen. In diesem Jahr wurden durch Angriffe die größte Gas-Pipeline in den USA und weitere in Europa abgeschaltet. Alles typische Fälle mangelhaft gesicherter Systeme im Internet der Dinge – und IoT-Anwendungen gibt es immer mehr (Bild 1). Ist der direkte Schaden im Fall eines gehackten Consumer-Produkts, etwa einer Webcam, meist noch überschaubar, sieht es bei professionellen Anwendungen ganz anders aus: Kein Anwender will riskieren, dass Maschinen in einem industriellen Produktionsprozess oder Versorgungseinrichtungen für Energie und Wasser einen unvorhergesehenen Betriebszustand annehmen (Bild 2).

Obwohl es bereits zahlreiche IoT-Anwendungen in sicherheitskritischen Bereichen gibt, haben bisher nur wenige Hersteller das Thema der (Cyber-) Security ihrer Produkte auf dem Schirm – in der Regel verlässt man sich darauf, dass ein Produkt sorgfältig entwickelt wurde. Doch was passiert, wenn sich herausstellt, dass es doch Sicherheitslücken gibt? Für den Anwender sind IoT-Produkte ‚Black Boxes‘, deren Code er nicht kennt; er kann also keine produktspezifisch vorbeugenden Maßnahmen treffen. Stattdessen steht der Hersteller in der Pflicht, dafür Sorge zu tragen, dass eine mögliche Schwachstelle in seinem Produkt beim Anwender keinen Schaden anrichtet.

Wodurch entstehen Sicherheitsrisiken?

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Security-Schwachstellen werden während des Entwicklungsprozesses im Produkt verankert. Dazu muss man wissen, wie die Erstellung einer Gerätesoftware üblicherweise vonstattengeht: Der Programmcode entsteht meist nur in kleinem Umfang – dem applikationsspezifischen Teil – neu, ansonsten greifen Software-Entwickler auf Komponenten von Drittanbietern wie Betriebssysteme, Bibliotheken, Treiber, Verschlüsselungsalgorithmen etc. zurück. Nur so ist die Entwicklung von vernetzten Produkten wirtschaftlich darstellbar, birgt aber die Gefahr eines Imports von Schwachstellen in das eigene Produkt. Man spricht bei kommerzieller und Open-Source-Software auch von Third-Party-Software. Solche Software-Module und -Betriebssysteme sind aufgrund ihrer weiten Verbreitung als Angriffsziel für Hacker besonders attraktiv. Historisch wurden sie meist nach rein funktionalen Kriterien und ohne Beachtung von Sicherheitsaspekten ausgewählt, denn Security war lange Zeit kein Entwicklungsziel. Es ist leider häufig zu beobachten, dass selbst heute noch Software mit längst bekannten Schwachstellen ihren Weg in neue Applikationen finden.

Aber auch wenn bei der Entwicklung auf Security-Aspekte geachtet wurde, ist das Thema damit nicht erledigt: Selbst nach erfolgreich absolvierten Penetrationstests werden viele Sicherheitslücken erst bekannt, wenn das Produkt längst im Feldeinsatz ist – diese können dann ausgenutzt werden. Parallel entwickeln sich auch die Angriffsmethoden auf vernetzte IoT-Produkte mit hohem Tempo weiter. Um seiner Verantwortung gegenüber den Anwendern und Kunden gerecht zu werden, sollte ein Hersteller somit einen Monitoringprozess über die gesamte Produktlebensdauer etablieren. Bei der Entdeckung einer potenziellen Schwachstelle gilt es, betroffene Anwender in einem ersten Schritt unverzüglich zu informieren und Maßnahmen zur Minderung des Schadensrisikos zu empfehlen. Sobald ein Update verfügbar ist, das die Sicherheitslücke schließt, ist es zur Verfügung zu stellen.

PSIRT – Produkte dauerhaft absichern

PSIRT-Dienstleistungen im Überblick
Die PSIRT-Dienstleistungen von embeX umfasst vier Service-Level:
SLA 1 – Standard Monitoring:
Monitoring Automatisierte Meldung
SLA 2 – Advanced Monitoring:
Monitoring gemäß SLA 1 Analyse des Monitoring-Ergebnisses durch Experten Filterung nach Relevanz und Produktzugehörigkeit Meldung mit qualifizierter Einschätzung zu möglichen Auswirkungen der Schwachstelle
SLA 3 – Supported Product:
Monitoring, Analyse und Filterung gemäß SLA 1-2 Bewertung nach CVSS Analyse auf Basis des Quellcodes und der Systembeschreibung, optional auch der Safety (SLA 3S) Filterung nach Relevanz und Produktzugehörigkeit Qualifizierte Meldung zu möglichen Auswirkungen der Schwachstelle
SLA 4 – Maintained Product:
Monitoring, Analyse, Filterung gemäß SLA 1-3 Optional für Safety-Anwendungen (SLA 4S) Schließen der Sicherheitslücke durch Überarbeiten des Quellcodes Sofern erforderlich, Überarbeiten der Produktdokumentation, zum Beispiel die Risikoanalyse

Fachabteilungen, die sich um einen solchen Monitoringprozess kümmern, werden auch Product Security Incident Response Teams, kurz: PSIRT, genannt. Sie bilden das produktbezogene Pendant beim Hersteller zu den – schon länger etablierten – Computer Emergency Response Teams, kurz: CERT, auf Anwenderseite, die sich um die Security des Unternehmensnetzwerks kümmern und nur in Einzelfällen produktbezogen tätig sind. Selbst bei großen und namhaften Unternehmen sind PSIRT bisher jedoch nicht flächendeckend etabliert, obwohl es mit der internationalen Norm IEC 62443 („IT-Sicherheit für industrielle Automatisierungssysteme“) in Teil 4-1 (Abschnitt 12.4.1) klare Vorgaben für die Aufrechterhaltung der Cybersecurity im Feld gibt. Ebenso gilt es, das im Mai 2021 in Kraft getretene IT-Sicherheitsgesetz 2.0 zum Schutz kritischer Infrastrukturen (KRITIS) einzuhalten.

Die meisten Hersteller sind jedoch mit diesen Aufgaben überfordert: Sie verfügen weder über einschlägiges Expertenwissen noch die notwendigen Personalressourcen, um einen internen PSIRT-Prozess zu etablieren. Hier können Unternehmen auf unabhängige Entwicklungsdienstleister zurückgreifen an: Als externes Sicherheitsteam unterstützt beispielsweise embeX die Hersteller von vernetzten Produkten beim Aufbau von geeigneten PSIRT-Prozessen sowie mit einem maßgeschneiderten Dienstleistungspaket, das den gesamten Produktlebenszyklus umfasst (siehe Kasten unten).

Der PSIRT-Prozess in der Praxis

Wie bereitet man die Absicherung eines Produkts nun konkret vor? Um eine spezifische Schwachstellenanalyse durchführen zu können, muss in einem ersten Schritt bestimmt werden, aus welchen (Sub-)Komponenten der Quellcode der Geräte-Software besteht. Man spricht hier auch von ‚Software Bill of Materials‘ (SBOM), vergleichbar der Teileliste bei einem Hardware-Produkt. Anschließend nimmt der Experte die einzelnen Komponenten unter die Lupe; als Handwerkszeug dienen ihm dabei spezielle Informationsquellen, zum Beispiel CVE-DB, CWE-DB, BSI, in denen bekannte Schwachstellen erfasst werden. Das Aufspüren erfordert viel Fachwissen und Erfahrung – allein die CVE-Datenbank enthält aktuell über 185.000 Einträge. Im nächsten Schritt werden gefundene Schwachstellen auf ihre Relevanz hin bewertet, also ob und wenn ja, welche Risiken im Fall der spezifischen Applikation auftreten können. Die Bewertung erfolgt nach dem ‚Critical Vulnerability Scoring System‘ (CVSS) auf einer Skala von 1 bis 10, wobei Stufe 10 für eine – in Bezug auf die gegebene Anwendung – höchst kritische Schwachstelle steht.
Über die Ergebnisse wird der Hersteller in Kenntnis gesetzt und erhält Empfehlungen für die weitere Vorgehensweise. Dies kann beispielsweise eine verstärkte Beobachtung des Produktes durch den Betreiber sein, oder aber eine Einschränkung, das Produkt nur noch im Verbund mit zusätzlichen Sicherheitsmodulen zu nutzen. Der weitestgehende Schritt ist das Schließen der Sicherheitslücke durch Überarbeitung des Quellcodes. Diese Überarbeitung können auch PSIRT-Dienstleister übernehmen (Service-Level 4).

Security versus Safety
Wenn von der Sicherheit von IoT-Produkten die Rede ist, sind zwei Begriffe zu unterscheiden: Safety und Security. Safety bezeichnet die von technischen Systemen ausgehenden Gefahren für Menschen und/oder die Umwelt. Bei Security (engl. Angriffs-/Einbruchsschutz) geht es um von Menschen (unabsichtlich oder mit Vorsatz) ausgehenden Gefahren, die zu einer Gefährdung von technischen Systemen führen, zum Beispiel die Manipulation eines Geräts durch Ausnutzen einer in der Gerätesoftware enthaltenden Sicherheitslücke. Ein Mangel in der Security eines Produkts kann unmittelbare Auswirkungen auf die Safety eines Geräts haben, indem es sich nicht wie vorhergesehen verhält.

Security versus Safety

Wenn von der Sicherheit von IoT-Produkten die Rede ist, sind zwei Begriffe zu unterscheiden: Safety und Security. Safety bezeichnet die von technischen Systemen ausgehenden Gefahren für Menschen und/oder die Umwelt. Bei Security (engl. Angriffs-/Einbruchsschutz) geht es um von Menschen (unabsichtlich oder mit Vorsatz) ausgehenden Gefahren, die zu einer Gefährdung von technischen Systemen führen, zum Beispiel die Manipulation eines Geräts durch Ausnutzen einer in der Gerätesoftware enthaltenden Sicherheitslücke. Ein Mangel in der Security eines Produkts kann unmittelbare Auswirkungen auf die Safety eines Geräts haben, indem es sich nicht wie vorhergesehen verhält.

Auch im Fall von Neuentwicklungen kann der spezialisierte Dienstleister hinzugezogen werden, um das Thema Security von vornherein im Entwicklungsprozess zu verankern – beginnend mit der Auswahl sicherheitsgeprüfter Komponenten und weiteren entwicklungsbegleitenden Prüfungen der SBOM auf Schwachstellen noch vor der Markteinführung. Dazu gehört auch die Überlegung, inwieweit künftige Sicherheitsupdates die Funktionalität des Produkts, zum Beispiel durch höhere Anforderungen an die Rechenleistung und Speicherkapazität, beeinflussen können.

Cybersecurity im Auge behalten

Die Autoren

Alle Bilder anzeigen (3)

Wer sich Sorgen hinsichtlich der Sicherheit seiner IoT-Produkte macht, kann sich zumindest in einem Punkt trösten: Er befindet sich ‚in guter Gesellschaft‘ mit vielen großen und namhaften internationalen Unternehmen, die ebenfalls keinen oder nur einen lückenhaften Umgang mit dem Thema pflegen. Ist dies bei Herstellern von Consumer-Produkten mit beschränktem Schädigungspotenzial vielleicht noch tolerabel, kann es hierfür in industriellen Anwendungen kein Pardon geben. Entwickler und Angreifer befinden sich in einem Wettrennen über den Produktlebenszyklus – daher ist Stehenbleiben keine Option. Da die Vernetzung der Produkte im IoT und damit auch einschlägige Risiken absehbar weiter zunehmen werden, sollte dem Thema der Cybersecurity die nötige Aufmerksamkeit geschenkt werden. Es geht darum, Folgeschäden bei den Kunden, die sich massiv auf das eigene Image und künftige Kaufentscheidungen auswirken können, zu vermeiden. Wer nicht über die (menschlichen und fachlichen) Ressourcen für ein internes PSIRT-Team verfügt, kann sich das entsprechende Wissen auch als externe Dienstleistung beschaffen. Um es mit einem Bild zu sagen: Nicht jedes Unternehmen benötigt eine eigene Werksfeuerwehr, sollte sich aber dennoch verpflichtet fühlen, alle notwendigen Maßnahmen zur Brandvorbeugung zu treffen.