Der lange dunkle Weg ins Licht : Integrität digitaler Artefakte in der Lieferkette

Kein Teil der langen Lieferketten scheint heute mehr ohne Weiteres verlässlich und sicher. Im Mai 2023 wurde ein Fall der Kompromittierung von Android-Smartphones während der Produktion in ungeahnten Ausmaßen bekannt [1]: Die „Lemon Group“ hat schätzungsweise mindestens 8,9 Millionen Geräte mit einer Schadsoftware infiziert, noch bevor sie in den Verkauf gingen. Wie und wo das passieren konnte, ist bislang unklar – sicher ist jedoch, dass dies vor dem Verpackungsprozess geschehen ist. Ob bereits kompromittierte Master-Images für den Flash-Speicher vorlagen oder eine Infektion während der QA-Phase oder später stattfand, ließ sich jedoch bis heute nicht ermitteln.

Malware ab Werk

Die aufgebrachte Malware enthält eine ganze Reihe von Plugins (Abb. 1), um SMS, WhatsApp, Facebook, Telefonbuch und vieles mehr zu kompromittieren [2]. Kurz gesagt hat also eine Unzahl von Nutzer:inne:n ein nagelneues Smartphone erhalten, das sie von vorne bis hinten ausspioniert und bei Bedarf sogar mit weiteren Plugins „getunt“ werden kann.

Dieser krasse Fall zeigt deutlich, dass das heute oft an den Tag gelegte blinde Vertrauen in Mobile-Devices nicht gerechtfertigt sein kann. Die Konsequenzen sind vielfältig – eine der einfachsten ist fast noch die Erkenntnis „You get what you pay for“: Auf der einen Seite stehen Hersteller, die ihre Gerät selbst sowie das umgebende Ökosystem vollständig kontrollieren. Am prominentesten ist hier sicherlich Apple, wo das gesamte Ökosystem in einer Hand liegt. Dieser „Walled Garden“ ermöglicht es Apple, über den gesamten Lebenszyklus der Geräte sehr genau zu überwachen, was darauf installiert und ausgeführt werden kann. Das geht sogar so weit, dass iPhones nach dem Austausch des Displays durch einen Drittanbieter bestimmte Funktionen deaktivieren. Man kann also davon ausgehen, dass nicht nur Signaturen von Bootloader, Kernel und Betriebssystem (OS) in Hardware-Sicherheitsmodulen gespeichert werden, sondern zum Beispiel auch Seriennummern bestimmter Baugruppen.

Damit einher geht allerdings ein Verlust an „Freiheit“ bei der Nutzung des Systems (z. B. mit alternativen Programmen oder Ökosystemen), sofern man das Gerät nicht gerade durch einen Jailbreak „aufbricht“. Außerdem bezahlt man (zumindest bei Apple) auch mit einem entsprechenden Preisniveau.

Letztlich wird dabei implizites blindes Vertrauen quasi durch explizites blindes Vertrauen ersetzt, frei nach dem Motto: Ich traue einem Hersteller Sicherheit zu und zahle dafür den entsprechenden Aufpreis. Dieser Ansatz hat nichts mit technischen Risikominderungsmaßnahmen zu tun, ist aber als Prozess durchaus valide. Gleichwohl ist anzumerken, dass das natürlich ebenfalls keine 100%ige Sicherheit bedeutet – entsprechende „Notfallprozesse“ sind daher auch in solchen Umgebungen vorzusehen, wenn auch vielleicht in geringerem Umfang.

Quasi auf der gleichen Seite, aber nicht ganz so geschlossen, stehen die Android-Umgebungen etablierter Hersteller: Auch hier trifft man standardmäßig auf ein geschlossenes Ökosystem. Allerdings gibt es fast immer die Möglichkeit, diese Systeme zu „öffnen“. Entsprechende Hersteller kontrollieren und verifizieren ihr Ökosystem sehr umfassend, lassen aber dem Nutzer die Option (nach eindringlicher Warnung), den geschützten Bereich zu verlassen. Solche Systeme in der Standardkonfiguration zu kompromittieren, ist für Cyberkriminelle ähnlich schwierig wie bei völlig geschlossenen Systemen – egal ob Gerät, Firmware, (Hersteller-)AppStore oder Apps. Wird der Nutzer jedoch dazu gebracht, die sichere Umgebung explizit zu verlassen, sieht das anders aus.

Aus Sicht von Verteidigern ist das Sicherheitsniveau etablierter mobiler Geräte in der Standardkonfiguration daher als sehr hoch einzustufen – besonders deshalb, weil diese Devices die Signaturen von Bootloader, Kernel, OS und auch Apps anhand von im HardwareSicherheitsmodul (HSM) hinterlegten Zertifikate validieren. Sobald Entwicklerzugänge freigeschaltet, das Gerät „gerootet“ oder eine alternative Firmware aufgespielt wird, fallen die Systeme jedoch massiv im Sicherheitsniveau ab. Nicht umsonst ist die Erkennung, ob ein Gerät im Entwicklermodus oder gerootet läuft, für viele Mobile-DeviceManagement-(MDM)-Systeme ein (berechtigter) Grund, solches Equipment komplett zu sperren.

Android ist nicht gleich Android

Bei generischen Geräten, die zwar oft deutlich günstiger, aber „nur“ mit der Android-Standarddistribution ausgestattet sind, ist hingegen kein Sicherheit versprechender „Walled Garden“ in Sicht! Hier kann Geräten weder implizit noch explizit vertraut werden – es bedarf einer (technischen) Maßnahme aufseiten des Anwenders, um die „Unversehrtheit“ des Systems zumindest ansatzweise selbst verifizieren zu können.

Die dazu notwendigen Maßnahmen sind bekannt und erprobt: Prüfsummen und digitale Signaturen für Firmware, Daten, Apps et cetera – der Einsatz von HSM bietet zusätzlichen Schutz vor Kompromittierung. Um zu verifizieren, dass Geräte und Firmware in der Lieferkette nicht kompromittiert wurden, ist aber für Endanwender/Administratoren erforderlich, dass digitale Signaturen des „gewünschten“ Systems auch tatsächlich verfügbar sind. Und genau hier hakt es häufig: Während beispielsweise die Standard-AndroidDistribution oft unverändert installiert wird und sich somit gegen offizielle Signaturen verifizieren ließe, wird das bei Bootloadern, Kerneln oder generell allen vom Hersteller vorgenommenen Modifikationen ohne Hilfe des Anbieters schwierig bis unmöglich. Natürlich kann man diese Signaturen zunächst auf dem „jungfräulichen“ Gerät selbst erstellen und später verifizieren. Wenn aber Malware bereits in der werkseitigen Erstkonfiguration aktiv ist, validiert man die Schadsoftware quasi mit.

Theoretisch gäbe es natürlich die Möglichkeit, sich eine eigene Android-Distribution inklusive Bootloader-Kernel und anderen Firmware-Blöcken zusammenzubauen, für diese dann Signaturen zu erstellen und zu verifizieren – praktisch ist diese Option aber nicht wirklich.

So ist man bei „Non-Walled Gardens“ de facto darauf angewiesen, dass die Hersteller diese Signaturen zur Verfügung stellen. Tun sie dies nicht (Stichwort: zusätzliche Kosten), lassen sie sich kaum mit vertretbarem Aufwand und gleichzeitig sicher herbeizaubern. Und selbst wenn sie vorliegen, heißt das noch lange nicht, dass sie auch im Basissystem oder sogar per Hardware (HSM) validiert werden. Dieses Manko lässt sich zwar durch zeitgesteuerte Validierungsläufe abmildern, allerdings verliert man unter Umständen massiv an Reaktionszeit, wenn Änderungen nicht „sofort“, sondern erst beim nächsten Scan erkannt werden.

Industrielle Systeme

Lässt sich bei Konsumgütern die Validierung der Integrität von Geräten auf den Anwender abwälzen, besteht diese Option für Hersteller von Industriegeräten nicht: Sie haben ein ureigenes Interesse an der Integrität ihrer Systeme. Sie wollen (und müssen teils aufgrund von Vorschriften) sicherstellen, dass deren Integrität von der Produktion über die Auslieferung und den Betrieb bis hin zur Außerbetriebnahme erhalten bleibt – ob Manipulationen dabei beispielsweise durch Veränderungen von Cyberkriminellen oder profane Lizenzverletzungen von Betreibern verursacht würden, spielt für die getroffenen Maßnahmen kaum eine Rolle.

Auch hier arbeitet mit digitalen Signaturen und HSMs bekannte Technologie – vielleicht mit dem Unterschied, dass Sicherungsmaßnahmen oft schon deutlich früher in der Produktion von (Teil-)Baugruppen zum Einsatz kommen. An dieser Stelle sei auf das hervorragende Whitepaper des ZVEI e. V. „Schutz der Integrität von Daten, Systemen und Prozessen in der Produktion – Kernelement der Digitalisierung in der Industrie“ [3] hingewiesen, das für diese Herstellergruppe wichtige Aspekte zusammenfasst.

Digitale Zwillinge

Ein oft vernachlässigter Aspekt der (erweiterten) Lieferkette ist die Integrität des Prozesses, in dem Systeme eingesetzt werden: Mithilfe sogenannter „digitaler Zwillinge“ ist es möglich, die Funktion von Geräten und Baugruppen vorab zu simulieren und später zu verifizieren. Die dazu notwendigen Informationen werden in sogenannten „digitalen Verwaltungsschalen“ gespeichert (Asset Administration Shell, [4,5]), die neben (Meta-)Beschreibungen der (konkreten) Baugruppe auch Dokumentationen, Links zu Firm-/Software und vieles mehr umfassen. Ein mögliches Datenformat sind sogenannte AASX-Dateien [6,7], welche die Beschreibung von Assets und deren (Sicherheits-) Eigenschaften ermöglichen.

Oft wird jedoch übersehen, dass zum Beispiel auch Zugriffsbeschränkungen und Kommunikationsbeziehungen kodiert werden können. Diese Informationen ermöglichen die quasi-automatische Erstellung, Validierung und Durchsetzung von Sicherheitsrichtlinien durch entsprechende technische Verfahren. So muss man etwa Änderungen an der Firewall nicht mehr fehleranfällig und zeitaufwendig manuell pflegen, sondern kann passende Regeln vollautomatisch erstellen, aktualisieren und löschen. Dadurch können Administratoren die Integrität von Prozessen und Geräten besser überwachen und sicherstellen.

Software-Artefakte

Auch ohne Bezug zu physischen Geräten spielt die Integrität der Lieferkette eine Rolle – genauer gesagt der Software-Lieferkette: Kaum eine Anwendung wird heute noch von Grund auf neu entwickelt, ohne auf Bibliotheken Dritter (Open Source oder kommerziell) zurückzugreifen. Und was mit der Einbindung einiger weniger Bibliotheken beginnt, kann schnell zu einem massiven Abhängigkeitsbaum führen (transiente Abhängigkeiten) – denn die selbst hinzugefügten Abhängigkeiten haben wiederum Abhängigkeiten und so weiter (vgl. Abb. 3).

Grundsätzlich kann eine Schwachstelle oder Sicherheitslücke in jeder der (transienten) Abhängigkeiten auch die eigene Anwendung angreifbar machen – das schließt Lücken mit ein, die erst lange nach der Veröffentlichung bekannt werden. Der „Einschlagkrater“ entsprechender Vorkommnisse kann also (ohne eigenes Zutun) massiv und quasi überraschend auftreten. Das bekannteste Beispiel aus der jüngeren Vergangenheit ist die Sicherheitslücke in Log4J, einem weitverbreiteten Logging-Framework für Java, die eine Remote-Code-Execution (RCE) in nahezu jeder betroffenen Java-Anwendung ermöglichte – kurz: der Super-GAU.

Um das Problem zu verschärfen, greift die Problematik nicht nur für die erstellten Bibliotheken und Apps: Docker-Container sind aus Sicht der Lieferkette lediglich ein Paketierungsformat. Aus Sicht der Abhängigkeiten kommt aber noch eine Vielzahl von Drittanwendungen, Paketen, Betriebssystemwerkzeugen, Container-Overlays und anderen Artefakten hinzu. Und wie bei direkten Bibliotheksabhängigkeiten kann eine Schwachstelle in einer dieser Komponenten die gesamte Anwendung kompromittieren – spätestens dann steht man meist vor einem Abhängigkeiten-Konstrukt ungeahnter Größe.

Software-Stücklisten

Der erste Schritt muss dann die Schaffung von Sichtbarkeit sein – aufgrund der Menge und Komplexität der entsprechenden Daten kann dies nicht als manueller Prozess erfolgen. Analog zu den (Teile-/Baugruppen-) Stücklisten in der Produktion (engl. Bill of Materials, BOM) setzen sich in der IT langsam sogenannte SBOMs (Software Bills of Materials) durch, die sich mit (Open-Source-) Tools automatisiert erstellen lassen.

Am effizientesten läuft die Erstellung einer SBOM im Rahmen der CI/CD-Pipeline: Nur dort sind mögliche Abhängigkeitsinformationen noch vollständig vorhanden. Ist dies nicht umsetzbar (z. B. bei Third-Party-Software oder Containern), besteht immer noch die Möglichkeit, SBOM-Informationen aus dem „toten“ Software-Artefakt zu extrahieren. Dabei muss man sich jedoch bewusst sein, dass bestimmte Abhängigkeitsinformationen möglicherweise nicht mehr sichtbar sind. Das gilt etwa für statisch kompilierte Binaries oder auch Abhängigkeiten, die zwar zur Entwicklungs-/Compilezeit benötigt werden, nicht aber zur Laufzeit.

Die nachträgliche Extraktion von SBOMs ist zwar besser als nichts. Will man auf die Qualität von SBOMs aus der CI/CD-Pipeline nicht verzichten, sind jedoch – besonders bei kommerzieller Software – die Entwickler in der Pflicht, solche Listen mitzuliefern. Auch wenn sich die Hersteller derzeit noch etwas sträuben, ist davon auszugehen, dass SBOMs zum Standard werden (bes. bei der Auslieferung in kritische Umgebungen). In den USA gibt es mit der „Executive Order on Improving the Nation’s Cybersecurity“ [8] bereits eine gesetzliche Vorgabe, genau dies zu tun – zumindest wenn man als Hersteller noch in den Regierungsbereich liefern möchte. In Deutschland und der EU gibt es noch keine solche regulatorische Anforderung – wenn man aber die einschlägige Kommunikation und entsprechende Arbeitsgruppensitzungen verfolgt, muss man davon ausgehen, dass SBOMs auch hier früher oder später in der einen oder anderen Form verpflichtend werden – wenigstens für bestimmte Kunden/Anwendungsbereiche.

Es ist unbedingt zu beachten, dass erstellte SBOMs nur genau für die „gelockte“ Version der Abhängigkeiten gelten. Selbst kleine Anpassungen können einen Rattenschwanz von Änderungen in den Versionen der transienten Abhängigkeiten nach sich ziehen und die (unpassenden) SBOM-Informationen praktisch wertlos machen. Im Kontext von Programmiersprachen und Packagemanagern ist das allerdings kein großes Problem: Die meisten aktuellen Packagemanager pflegen zusätzlich zu den Informationen über die gewünschten Abhängigkeiten sogenannte „Lockfiles“. In diesen wird für alle Abhängigkeiten nicht nur die Versionsangabe des Benutzers (z. B. Webserver Version 3.1.x) gespeichert, sondern auch die genaue Version, die bei der Auflösung der Abhängigkeiten ermittelt wird. Werden diese Lockfiles im Repository aufbewahrt, so kann man sicherstellen, dass beim Aus- und Wieder-Ein-Checken genau die gleichen Abhängigkeiten und Versionen verwendet werden.

Unbesehen eingepackt

Eine unrühmliche Ausnahme bilden leider Docker-Files und Kubernetes-Manifeste: In beiden Fällen ist es durchaus üblich, Container-Images ohne weitere Versionsbezeichnung oder mit dem Tag „latest“ einzubinden. Das Abhängigkeiten-Bild anhand der jeweils aktuellsten Versionen kann sich daher von einer Minute auf die andere oder von einem Pull zum nächsten ändern. Auch die Angabe der Versionsnummer – beispielsweise „node:20“ für NodeJS in der Version 20 – ist nur geringfügig besser, da sich diese oft nur auf die Majorrelease-Nummer bezieht: Bei Patches oder Minor-Updates verweist das Major-VersionsTag also jeweils auf ein neues Image.

SHA256-Werte als Tags liefern zwar eine Möglichkeit, um eine „Lockfile“-Funktionalität auch in Docker/Kubernetes zu erhalten. Denn die Hashwerte referenzieren ein Container-Image unabhängig von Versionsnummern immer eindeutig. Leider ist die (manuelle) Pflege solcher Prüfsummen aber sehr aufwendig – besonders wenn man die Abhängigkeiten von Zeit zu Zeit aktualisieren möchte, bricht hier die Agilität massiv ein.

In diese Lücke stößt „Docker Lock“ [9], ein Tool für Docker- und Docker-Compose-Dateien sowie Kubernetes-Manifeste, das diese Funktionen automatisiert: In den Quelldateien schlummern dazu zunächst nur semantische Tags für Container – nach einem „Docker Lock“ werden sie jedoch durch Hashes ersetzt. Verwendet man dann dieses Dockerfile zum Build oder das Kubernetes-Manifest zum Deploy, so kann man sicherstellen, dass immer genau die gleichen getesteten und validierten Container-Images zum Einsatz kommen. Möchte man die Abhängigkeiten aktualisieren, dann genügt es, diese über Docker Lock zu „entsperren“ – dadurch werden die Abhängigkeiten aktualisiert und bei Bedarf erneut gesperrt.

Prüfen auf Verwundbarkeiten

Nachdem man im ersten Schritt die vorliegenden Abhängigkeiten durch SBOM sichtbar gemacht hat, geht es im zweiten Schritt darum, diese kontinuierlich gegen (neu) bekannte Verwundbarkeiten zu validieren – wobei die Betonung auf „kontinuierlich“ liegen sollte. Viele Werkzeuge zur Generierung von SBOMs sind in der Lage, das Mapping gegen Verwundbarkeiten praktisch sofort durchzuführen. So nützlich dies auch sein mag, ist hier Vorsicht geboten, da das Mapping sozusagen eine Momentaufnahme zu einem bestimmten Zeitpunkt darstellt. Wesentlich effizienter ist der Einsatz dedizierter Tools, die einmal importierte SBOMs weiterführen und automatisiert gegen aktuelle Verwundbarkeiten validieren.

DependencyTrack von OWASP ist eines der bekanntesten Open-Source-Tools für diesen Zweck [10]. Damit lassen sich SBOMs im Rahmen von Projekten und Versionsnummern importieren und anschließend automatisiert kontinuierlich auf (neue) Schwachstellen prüfen. Die Ergebnisse sind (managementkompatibel) in Dashboards und Reports einsehbar oder werden direkt an Benachrichtigungssysteme (Slack, Teams, …), APIs oder Vulnerability-Aggregation-Systeme übergeben (vgl. Abb. 4). Wenn man dann noch die Verbreitung von Software anhand der Versionsnummer pflegt, ist man schon sehr gut gerüstet. Sollte also beim nächsten Log4J-artigen Incident die Frage aufkommen, ob man betroffen ist, lässt sich diese mit einem Blick für verschiedenste Produkte und Versionen beantworten. In Kombination mit dem Verbreitungsgrad ergibt sich gegebenenfalls auch eine optimale Grundlage für Risikobewertung und Priorisierung.

Integrität beim Software-Betrieb

Ähnlich wie bei digitalen Zwillingen lässt sich auch der Betrieb von Software-Artefakten massiv vereinfachen und automatisieren: Im Kubernetes-Umfeld ist es beispielsweise längst Standard, Security-Policies nicht manuell zu erstellen und deployen. Vielmehr werden Manifeste für Services mit Metadaten (z. B. Ports) und Tags angereichert. Kubernetes-Controller können diese automatisch erkennen und so entsteht eine Grundlage für die automatische Erstellung von Security-Policies, die sich dann von entsprechenden Enforcement-Lösungen durchsetzen lassen.

Das ist jedoch keineswegs auf Kubernetes als Betriebsumgebung beschränkt: SBOM-Formate wie CycloneDX [11] ermöglichen die Kodierung von Ports, (URL-)Endpoints, Authentifizierungs- sowie Autorisierungs-Anforderungen und vieles mehr in der SBOM. Würden ausgelieferte SBOMs solche Daten enthalten, könnte man auch hier eine massive Automatisierung der Policies erreichen. Und selbst wenn man den Angaben nicht „trauen“ würde, wären sie doch äußerst hilfreich bei der Dokumentation für den Software-Betrieb. Obwohl diese Informationen heute in SBOMs kodiert werden könnten, ist die praktische Nutzung solcher Attribute noch sehr lückenhaft. Aus Sicht von Software-Betrieb und Dokumentation sind diese Funktionen äußerst interessant, bleiben aber derzeit eher ein „Wunschkonzert“.

Google GUAC

Betrachtet man die verschiedenen Aspekte digitaler Artefakte in der Lieferkette, so ergibt sich ein sehr heterogenes Bild. Die unterschiedlichen Artefakttypen (Firmware, Digital Twins, Software, SBOMS, Container, …) bedingen jeweils sehr spezifische Herausforderungen. Dennoch gibt es große Überschneidungen bei den Anforderungen, gerade auf der Betriebs- und Prozessebene. Beispielsweise wäre eine Lösung wie Dependency Track auch für Firmware oder digitale Zwillinge interessant.

Das von Google initiierte Projekt „Graph for Understanding Artifact Composition“ (GUAC, [12]) hat unter anderem den Anspruch, diese Silos aufzubrechen, das heißt: Wegfall spezifischer Datenformate für verschiedene Anwendungsfälle und die Verknüpfung von Daten über Silos und Anwendungsfälle hinweg.

Vereinfacht gesagt sollen Daten aus verschiedenen Anwendungsfällen normalisiert und in einem Graphen gespeichert werden: Dieser enthält „offizielle“ Attribute für Knoten und Kanten, lässt sich aber auch mit eigenen Daten anreichern. Alle Funktionen (z. B. das Mapping von Schwachstellen auf Software-Artefakte) werden über Such-, Lese- und Schreiboperationen auf diesem Graphen abgebildet. Der Graph selbst wird dazu in einer Datenbank gespeichert, die zunächst lokal läuft – es ist jedoch geplant, über Föderationskonzepte auch Daten aus anderen (öffentlichen) Graphen zu referenzieren oder eigene Daten freizugeben.

Dieser auf den ersten Blick vielleicht etwas komplexe Ansatz hat einen immensen Vorteil: Alle Informationen werden in einem offenen und zugänglichen System gespeichert. Fremde und eigene Tools können auf diesem Graphen beliebig mit offiziellen und auch privaten Daten arbeiten – ohne Hacks, Datenbankdumps und dergleichen. Obwohl das Projekt noch in den Kinderschuhen steckt, ist das Potenzial mittelfristig extrem hoch. Ein guter Vergleich wäre vielleicht Gopher versus HTTP: Auch über das 1991 vorgestellte Gopher-Protokoll konnte man Inhalte via Internet bereitstellen und verlinken. Seine strikte Hierarchie – (heute würde man vielleicht „Silos“ sagen) digitaler Verwaltungsschaden – und die damit verbundenen Restriktionen verhinderten jedoch einen Erfolg. Im Vergleich dazu punktete HTTP, das im gleichen Jahr in Version 0.9 erschien: Über seine offene Architektur konnte jeder ohne vorherige Absprache Informationen bereitstellen, integrieren und verknüpfen – der Rest ist Geschichte.

Die Verwaltung verschiedener Datenformate und Tools in der Lieferkette kann eine Herausforderung darstellen. Google GUAC bietet eine Alternative zur Konsolidierung dieser Daten und ihrer Verwaltung. Es ermöglicht die Modellierung aller Daten als benutzerspezifisch erweiterbaren Graphen und schafft so einen kombinierten Graphen als „Single Source of Truth“. Administratoren können die Graphdatenbank nutzen, um Daten zu verwalten und zu verarbeiten, und so die Integrität der Lieferkette sicherstellen.

Fazit

Die Integrität digitaler Artefakte in der Lieferkette ist für die Sicherheit und Zuverlässigkeit von IT-Systemen von entscheidender Bedeutung. Durch den Einsatz digitaler Signaturen, Hardware-Security-Modules (HSMs), digitaler Verwaltungsschalen (AASX), Software Bills of Materials (SBOMs) und geeigneter Werkzeuge wie Dependency Track und Google GUAC können Administratoren die Integrität „ihrer“ digitalen Supply-Chains sicherstellen und Schwachstellen in der Lieferkette proaktiv identifizieren und beheben.

Viele der Werkzeuge und Prozesse sind mittlerweile bekannt und ausgereift. Was aber in vielen Fällen fehlt, ist der Wille, sie auch einzusetzen – auch weil so etwas eben nicht „aktiv“ im Sinne von Prävention und Detektion schützt. Vielmehr sind diese Themen im Prozess- und Compliance-Umfeld angesiedelt. Betrachtet man jedoch die aktuelle Sicherheits- und Gesetzeslage, so ist davon auszugehen, dass sie sich von „kann man machen, wenn man Zeit hat“ hin zu „müssen wir machen, um unseren Dokumentations- und Regulierungspflichten nachzukommen“ entwickeln werden. Um hier keinen massiven manuellen Aufwand zu generieren, ist es daher nahezu unabdingbar, die Prozesse zur Aufbewahrung/Dokumentation digitaler Artefakte in der Lieferkette so früh, so weit und so schnell wie möglich zu automatisieren.

Bei aller Betonung der Aspekte „Management“, „Compliance“ und „Dokumentation“ darf man eines nicht vergessen: Nur weil Schwachstellen und Verwundbarkeiten nun „verwaltet“ werden, bedeutet das nicht automatisch, ein höheres Sicherheitsniveau zu erreichen. Das geschieht erst, wenn man die identifizierten Lücken auch tatsächlich schließt! Die beschriebenen Werkzeuge und Prozesse helfen jedoch dabei, die einzelnen Schwachstellen zu bewerten und die Patch-Reihenfolge zu priorisieren.

Udo Schneider ist IoT Security Evangelist Europe bei Trend Micro.

Literatur

[1] Fyodor Yarochkin, Zhengyu Dong, Vladimir Kropotov, Paul Pajares, „Behind the Scenes: How Criminal Enterprises Pre-infect Millions of Mobile Devices,“ Vortrag BlackHat Asia, Mai 2023. [Link](www.blackhat.com/asia-23/briefings/schedule/index.html#behind-the-scenes-how-criminal-enterprises-pre-infect-millionsof-mobile-devices-31235)

[2] Fyodor Yarochkin, Zhengyu Dong, Paul Pajares, „Lemon Group’s Cybercriminal Businesses Built on Preinfected Devices,“ Trend Micro Analysis, Mai 2023. [Link](www.trendmicro.com/en_us/research/23/e/lemon-group-cybercriminal-businesses-built-on-preinfected-devices.html)

[3] Zentralverband Elektrotechnik und Elektronikindustrie e. V. (ZVEI), „Schutz der Integrität von Daten, Systemen und Prozessen in der Produktion – Kernelement der Digitalisierung in der Industrie (Teil 2),“ Whitepaper, November 2019. [Link](www.zvei.org/presse-medien/publikationen/schutz-der-integritaet-vondaten-systemen-und-prozessen-inder-produktion-kernelement-derdigitalisierung-in-der-industrie)

[4] Dr. Jörg Neidig, Andreas Orzelski, Stefan Pollmeier, „Asset Administration Shell Reading Guide,“ Januar 2022. [Link](www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/AAS-ReadingGuide_202201.pdf)

[5] Plattform Industrie 4.0, „Details of the Asset Administration Shell, Part 1 – The exchange of information between partners in the value chain of Industrie 4.0,“ Version 3.0RC02, Mai 2022. [Link](www.plattform-i40.de/IP/Redaktion/DE/Downloads/Publikation/Details_of_the_Asset_Administration_Shell_Part1_V3.html)

[6] Industrial Digital Twin Association e. V. (IDTA), „AASX Package Explorer,“ Github Repository, Februar 2023. [Link](https://github.com/admin-shell-io/aasx-package)

[7] Industrial Digital Twin Association e. V. (IDTA), „Package File Format (AASX), Specification of the Asset Administration Shell Part 5,“ April 2023. [Link](https://industrialdigitaltwin.org/en/content-hub/downloads)

[8] The White House, „Executive Order on Improving the Nation’s Cybersecurity,“ Mai 2021. [Link](www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-thenations-cybersecurity/)

[9] Safe Waters [Organization], „Docker Lock,“ Github Repository, September 2021. [Link](https://github.com/safe-waters/docker-lock)

[10] Open Worldwide Application Security Project (OWASP), „Dependency Track,“ Projektwebsite. [Link](https://dependencytrack.org)

[11] Open Worldwide Application Security Project (OWASP), „CycloneDX Software Bill of Materials (SBOM) Standard,“ Projektwebsite. [Link](https://cyclonedx.org)

[12] Brandon Lum, Mihai Maruseac, Isaac Hepworth, „Announcing GUAC, a great pairing with SLSA (and SBOM)!,“ Google Security Blogpost, Oktober 2022. [Link](https://security.googleblog.com/2022/10/announcing-guac-great-pairingwith-slsa.html)