So lässt sich Open-Source-Software in der Fertigung nutzen

Embedded-Software ist zentral für das IIoT. Sie ist es, die aus Geräten letztendlich die Smart Factory von morgen macht. Doch mit dem wachsenden Einsatz von Embedded-Software in vormals reinen Hardwaregeräten, tauchen auch neue Sicherheitsaspekte auf. Ist ein Gerät permanent mit dem Internet verbunden, verwandelt es sich fast schon automatisch in ein attraktives Ziel für Hacker, um beispielsweise Malware in das System einzuschleusen oder einzelne Geräte in Botnets einzubinden. Die vernetzten Geräte bieten eine ideale Angriffsfläche, da sie häufig durchgehend an High-Speed-Netzwerkverbindungen angebunden sind, auf Linux basieren und dabei Monitoring-Systeme, Filter oder Protokolle vermissen, die vor einer Infiltration warnen.

Hinzu kommt, dass viele dieser Systeme nur für einen eingeschränkten Rollout ausgelegt sind oder von Fremdanbietern stammen, die dem Software-Hardening und der Sicherheit nur wenig Aufmerksamkeit schenken. Die Kombination aus leistungsstarken, vernetzten Systemen und hoher Verwundbarkeit bietet Botnets ein Einfallstor, um IoT-Geräte zu infizieren – wie Mirai und Bashlite im letzten Jahr eindrucksvoll bewiesen haben.

Open Source ist überall

90 % von Angriffen zielen auf die Anwendungsebene. iStock/maxkabakov

Eine wichtige Rolle nimmt hier Open-Source-Software (OSS) ein. OSS macht bis zu 50 Prozent des Codes in kommerzieller Software aus. Vor allem bei Programmierroutinen greifen Softwareentwickler auf OSS- und kommerzielle Komponenten von Drittanbietern zurück, um schneller und effizienter arbeiten zu können. Neun von zehn IoT-Entwickler verwenden Open-Source-Software. Das proaktive Management und die Pflege dieser Komponenten werden dabei leider oft vernachlässigt. Tatsächlich kennen Entwickler oft nur etwa vier Prozent des Codes von Drittanbietern in Embedded-Software. Auf jede bekannte Komponente, fallen damit 24 weitere Komponenten, die unerkannt und unverwaltet in der Software verwendet und an Kunden ausgeliefert werden. Das im IoT weit verbreitete Betriebssystem Linux enthält beispielsweise Dutzende bis Hunderte von Open-Source-Paketen.

Unverwaltete und un-dokumentierte OS-Komponenten bergen zweierlei Risiken: Zum einen gilt es auch bei OSS die Compliance einzuhalten. Zum anderen ist die Dokumentation über die Verwendung von OS-Komponenten entscheidend, um bekanntgewordene Schwachstellen schnell und sicher zu patchen.

Stückliste auch für Software

Um proaktiv und frühzeitig Sicherheitslücken zu schließen, sollten IoT-Entwickler genau nachverfolgen und festhalten, welche Komponenten im Betriebssystem sowie in den Anwendungen zum Einsatz kommen. Wie in der Fertigung ist es daher auch bei der Softwareentwicklung mittlerweile üblich, ein aktuelles Verzeichnis aller Abhängigkeiten und eingesetzten Komponenten einer Software zu erstellen. Mit der Software-Stückliste oder Bill-of-Materials (BOM) können Softwareanbieter einfacher und schneller feststellen, ob eine kürzlich veröffentlichte Vulnerability ihre Produkte auch tatsächlich betrifft. Erst anhand dieser Übersicht lassen sich selbstständige Aktualisierungsfunktionen in die Geräte integrieren und Updates sowie Patches schneller bereitstellen.

In der Praxis stellt eine solche Software-Stückliste viele Unternehmen jedoch vor eine echte Herausforderung. Die bloße Einschätzung von Entwicklerseite garantiert weder Vollständigkeit noch Detailtiefe. In vielen Fällen lohnt sich daher ein Selbsttest, der prüft, ob sich eine aktuelle Stückliste erstellen lässt und wann diese zuletzt aktualisiert wurde. Mit einfachen Schritten kann so sehr schnell eine große Menge bisher unbekannter Drittsoftware aufgedeckt werden:

• Anhand von Stichproben des Quellcodes lässt sich die Aktualität der angegebenen Versionsnummern überprüfen.
• Eine kurze Untersuchung von Bibliotheks-Namen und Datei-Endungen, die auf vermeintliche Drittanbieter hinweisen (zum Beispiel .JAR, .DLL), sowie die Suche nach Copyright-Informationen, Lizenzen und kopierten Dateien schafft einen ersten Überblick.
• Über die Suche nach dem String „Open SSL“ lassen sich mit hoher Wahrscheinlichkeit zahlreiche Kopien von bislang nicht bekannten Fällen von Open SSL in Open Source und in kommerziellen Komponenten finden – sowohl in Binärprogrammen als auch in Quelldateien.

Thema der nächsten Seite: Abgleich mit öffentlichen Schwachstellen-Datenbanken

Ist eine Stückliste erstellt, folgt der Abgleich mit Komponenten, die bekannte Sicherheitslücken enthalten. Eine Liste dieser Schwachstellen findet sich beispielsweise in der National Vulnerability Database oder in der Schwachstellenampel des BSI. Erfahrungsgemäß lässt sich so bereits im ersten Durchlauf eine Vielzahl an gefährdeten Komponenten identifizieren. Da sich die Schwachstellen hinsichtlich ihres Risikopotenzials stark voneinander unterschieden, ist es gängige Praxis zunächst Prioritäten zu vergeben und eine Handlungsreihenfolge für den Ernstfall festzusetzen. Zu den wirkungsvollsten Maßnahmen der Gefahrenbehebung zählen Updates auf die nächste Softwareversion, Patch-Prozesse sowie das Blockieren des Zugangs. In manchen Fällen kann es sogar nötig sein, die Komponente sowie alle Produktfeatures vollständig zu entfernen.

Updaten, Updaten, Updaten

Vor allem bei Programmierroutinen verwenden IoT-Entwickler OSS. Flexera

Software- und Firmware-Updates sind entscheidend für Sicherheits- und Compliance-Prozesse. Vor wenigen Jahren reichte es noch völlig aus, Software alle paar Monate zu aktualisieren. Vernetzte Geräte innerhalb des IoTs erfordern allerdings noch häufigere Updates, die sich über manuelle und isoliert voneinander ablaufende Prozesse kaum noch realisieren lassen. Gefragt sind daher automatisierte Systeme, die sich dem Kundenbestand, der Anzahl an Software-Produkten und Versionen sowie der nötigen Update-Frequenz anpassen können.

Doch auch beim automatisierten Updaten ist Vorsicht geboten. Hacker und Cyberkriminelle sind dazu übergangen, entsprechende Systeme zur Verbreitung von Malware zu missbrauchen. Werden beispielsweise einprogrammierte Passwörter über mehrere Geräte oder Gerätefamilien geteilt, kann sich die Malware großflächig und blitzschnell verbreiten. Bleibt dieser Angriffsvektor versperrt, nutzen die Schadprogramme auch weit verbreitete Schwachstellen wie Open SSL oder Bash aus oder versuchen über eine gemeinsame kommerzielle Firmware digitale Videorekorder (DVR) oder Kameraplatinen zu infizieren.

Die richtige Strategie auf Anwendungsebene

Fast 90 Prozent der Angriffe auf Software zielen auf die Anwendungsebene selbst ab, darunter Software-Schwachstellen und fehlerhafte Codes. Um hier Software-Produkte zuverlässig zu schützen, empfiehlt es sich für IoT-Entwickler, das Management von Open-Source-Komponenten explizit in ihre allgemeine Sicherheitsstrategie miteinzubinden. Dazu zählt unter anderem:

• Prüfungen auf Code-Ebene und Penetrationstests für intern entwickelten Code vor der Bereitstellung.
• Einfordern von Audits auf Code-Ebene auf Seiten externer Entwicklungs- und Geschäftspartner.
• Code von Dritten in den eigenen Software-Anwendungen auf Sicherheitsschwachstellen und Updates prüfen und nachverfolgen.
• Intern entwickelte Anwendungen mit ausreichenden Prüfpunkten versehen, um gründliche Audit-Trails zu ermöglichen.

Neue Technologien machen es IoT-Entwicklern deutlich einfacher, die Übersicht über Open-Source- und kommerzielle Komponenten zu behalten und melden darüber hinaus neu entdeckte Schwachstellen in den genutzten Komponenten. Auf dieser Basis lassen sich Berechtigungs-Workflows implementieren, die sicherstellen, dass Produkte nicht nur bei der Auslieferung keine bereits bekannten Schwachstellen enthalten, sondern auch über ihren Produktlebenszyklus hinweg überwacht und bei Bedarf neu veröffentlichte Schwachstellen gepatcht werden können.

(neu)