Es war der erste Freitag im Juli, als der US-amerikanische Softwarehersteller Kesaya mitteilte, möglicherweise Opfer eines Hackerangriffs geworden zu sein. Insbesondere betroffen war die vielerorts eingesetzte Fernwartungssoftware "VSA". Als IT-Administrator kennen Sie den "No Change Friday", gern auch "Read-only Friday" genannt, und wissen natürlich auch, was so eine Nachricht am letzten Arbeitstag der Woche bedeuten kann. Das wussten auch die Hacker, die ihren Angriff vermutlich ganz bewusst auf einen Freitag gelegt haben.

Die schwedische Supermarktkette Coop war eines der ersten betroffenen Unternehmen, zumindest soweit öffentlich bekannt. Bereits am Samstagmorgen schlossen alle knapp 800 Filialen, da die Kassensysteme in den Läden ausgefallen waren und keine Zahlungen mehr abgewickelt werden konnten. Coop war selbst gar nicht von dem Hackerangriff betroffen, denn das Unternehmen ist offenbar gar kein Kunde von Kesaya. Vielmehr war aber der Zahlungsdienstleister Visma Essco durch den Angriff beeinträchtigt und dessen Systeme funktionierten nicht mehr zuverlässig. Visma Essco betreibt die Kassensysteme von Coop, ebenso wie die von der schwedischen Bahngesellschaft SJ sowie von Tankstellen und Apotheken in Schweden.

Auch Unternehmen aus Deutschland waren als Kunden von Kesaya unmittelbar betroffen. Die Hacker verschlüsselten mit einer Ransomware alle Systeme von Kesaya-Kunden, derer sie habhaft werden konnten. Wie schon das Beispiel Coop zeigt, hatte das aber mitunter auch Auswirkungen auf Unternehmen, die Kesaya gar nicht einsetzten. So waren unter den Kaseya-VSA-Kunden auch Dienstleister oder Systemhäuser, die selbst wiederum Remotezugriff auf Kundensysteme haben oder Daten ihrer Kunden auf eigenen Servern oder Backupsystemen vorhalten. Damit erhielten die Hacker hier einen direkten Durchgriff auf Systeme und Daten von hunderten Unternehmen.

Beim Begriff Lieferkettensicherheit denken nur wenige als Erstes an Software oder IT-Dienstleister. Viele haben das deutlich anschaulichere Beispiel industrieller Produktion im Kopf. Ganz im Stil von Industrie 4.0 und vernetzten Fabriken werden Rohstoffe für eine Produktion ohne Zwischenlagerung pünktlich für die weitere Verarbeitung bereitgestellt, sodass eine optimale Auslastung der Fabriken gewährleistet ist, minimale Kosten für notwendige Zwischenlagerung anfallen und hohe Synergien über alle beteiligten Unternehmen spürbar werden.

Dieser Idee folgend gilt also, dass vor allem Zulieferer überprüft werden (sollten). Dass dies nicht der Fall ist, zeigt eine Umfrage des Unternehmens Blue Voyant aus dem Jahr 2020. 1500 Führungskräfte wurden unter anderem gefragt, ob sie Risiken für die Sicherheit ihres Unternehmens durch Dritte überwachen. Diese Frage haben lediglich zwei Prozent positiv beantwortet. Das kann daran liegen, dass entsprechende Zulieferverträge häufig Vertragsstrafen vorsehen und das unternehmerische Risiko damit gefühlt einfach weitergegeben wird.

Das mag jedoch zu kurz gedacht sein, entsprechende Kosten werden nämlich häufig allein auf Basis eines möglichen Umsatzverlusts durch stillstehende Fabriken berechnet. Hier kommen dann aber schwer kalkulierbare Kosten hinzu, nämlich dann, wenn sich die Waren der anderen Zulieferer nicht mehr verarbeiten lassen, mit diesen aber eine bestimmte Abnahmemenge vereinbart ist – was wiederum zu Vertragsstrafen oder deutlich höheren Kosten für die Zwischenlagerung führt.

In Unternehmen eingesetzte Software unterliegt an vielen Stellen derselben Gefahr wie die bereits vorgestellten industriellen Lieferketten. Ähnlich wie bei Kesaya wurde nur ein Jahr vorher das Unternehmen Solarwinds Opfer eines Hackerangriffs. Das von Solarwinds angebotene Orion ist eine Management- und Monitoring-Plattform für heterogene IT-Infrastrukturen. Hackern war es gelungen, über ein schwaches Passwort auf den Updateservern des Anbieters manipulierte Software-Aktualisierungen zu verteilen. Damit erhielten die Hacker nahezu uneingeschränkten Zugriff auf ganze Infrastrukturen großer Unternehmen und Einrichtungen, etwa des US-amerikanischen Finanzministeriums oder des Ministeriums für Innere Sicherheit. Das zeigt deutlich, dass damit auch in kritischen Infrastrukturen niemand gerechnet hatte.

In Unternehmen eingesetzte Open-Source-Software macht den Prozess der Risikobestimmung noch deutlich komplizierter. Derartige Software basiert in der Regel auf einer Menge weiterer Open-Source-Bibliotheken, die strenggenommen alle Teile der Software-Lieferkette sind – und sei der Anteil am Gesamtprodukt noch so klein. Während wir aber bei handelsüblicher Software ein Unternehmen als Teil der Lieferkette betrachten können und die Einhaltung entsprechender Schutzmaßnahmen in diesem Unternehmen, fällt dies bei Open-Source-Projekten nicht immer so leicht.

Eine versehentlich eingebrachte Sicherheitslücke wie bei Kesaya oder eine Hintertür wie ein bekanntes Zugangspasswort können damit weitreichende Konsequenzen haben. Die 2014 in der OpenSSL-Bibliothek gefundene Heartbleed-Schwachstelle hatte eine entsprechende Reichweite und ein hohes Schadpotential. Auf den ersten Blick könnten wir vermuten, dass ein Vorteil von Open-Source-Software darin läge, dass eine Sicherheitslücke zeitnah gefunden und behoben wird. Laut Octoverse-Studie von GitHub [1] aus dem Jahr 2020 existieren Sicherheitslücken in Open-Source-Projekten allerdings vier Jahre, bis sie gepatcht werden.

Um nicht auf Programmierfehler der Entwickler warten zu müssen, haben Hacker bei Open-Source-Software zudem die Chance, selbst direkt schadhaften Code in die Software einzupflegen. Ein sehr bekanntes, wenn auch schon etwas älteres Beispiel aus dem Jahr 2011 ist das Projekt "Very Secure FTP Daemon" (VSFTPD). Dort hatte ein bis heute unbekannter Angreifer Schadcode eingefügt, der bei der Eingabe von ":)" als Benutzername aktiv wird und einen Serverport mit Shell-Zugriff auf Port 6200 öffnet. Dabei hat der Angreifer jedoch nicht einfach in der Login-Funktion auf diesen Benutzernamen geprüft, sondern die bereits verwendete Funktion zur Prüfung auf Leerzeichen im Benutzernamen angepasst.

Wissenschaftler der Universität Bonn haben in einem Konferenzbeitrag von 2020 mögliche Wege ermittelt, um Schadsoftware in die Software-Lieferkette einzubringen [2]. Dabei fokussierten sie insbesondere auf Paket-Repositories moderner Entwicklungsumgebungen wie pip oder npm und haben die im Bild dargestellten Angriffsmöglichkeiten identifiziert.

Ein Angreifer entscheidet sich also zunächst, ein neues Softwarepaket zu erstellen oder ein bestehendes Paket zu manipulieren. Auf den ersten Blick gestaltet sich die erste Möglichkeit eher schwierig. Selbst wenn ein neues Softwarepaket angeboten wird, benötigt der Angreifer schlussendlich noch Nutzer, die es dann auch herunterladen, installieren und ausführen. Um die wahre Intention und den schadhaften Code zu verschleiern, kann der Angreifer ein für sein Ziel nützliches Softwarepaket erstellen und dieses mit einem Trojaner versehen.

Die beiden weiteren Möglichkeiten Typosquatting und Use After Free erlauben dem Angreifer den Erfolg eines anderen Softwarepakets für die eigenen Zwecke zu nutzen. Beim Typosquatting registriert der Angreifer ein Paket mit ähnlichem Namen zu einem bereits existierenden Paket. Sollte nun ein Entwickler durch einen Tippfehler das falsche Paket herunterladen, landet der Code des Angreifers auf dem System des Entwicklers. Definiert der Angreifer das Originalpaket selbst als Abhängigkeit, wird dieses ebenfalls heruntergeladen und dem Entwickler fällt sein Tippfehler nicht einmal unmittelbar auf. Bei Use After Free übernimmt der Angreifer den Namen eines zuvor entfernten Softwarepakets und spekuliert auf alte Referenzen in anderen Projekten.

Zusätzlich zu diesen drei Möglichkeiten gibt es für Angreifer die Möglichkeit zum sogenannten Namesquatting. Die meisten Paketmanager, insbesondere aber pip und npm, unterstützen sowohl lokale als auch entfernte Repositories. Verwaltet Ihr Unternehmen in einem internen Repository eigens entwickelte Bibliotheken und erhält ein Angreifer Kenntnis darüber, kann er durch die Bereitstellung einer Bibliothek mit demselben Namen, aber einer höheren Versionsnummer in einem öffentlichen Repository erreichen, dass seine Bibliothek auf Ihren Entwicklungssystemen landet. Schon während dieser Installation kann Schadcode des Angreifers zur Ausführung kommen.

Um Namesquatting zu verhindern, sind einige Unternehmen dazu übergegangen, einfach leere Pakete mit entsprechenden Namen auch in öffentlichen Repositories anzulegen. Dies verstößt aber häufig gegen die Richtlinien der Betreiber, sodass diese leere Pakete regelmäßig wieder entfernen. Sie müssten also, selbst wenn Sie interne Bibliotheken verwenden, tatsächlich ein wenig funktionierenden Code in einem öffentlichen Paket bereitstellen, um erfolgreiches Namesquatting durch einen Angreifer zu verhindern.

Microsoft hat Anfang des Jahres 2021 einen Minileitfaden mit drei Strategien veröffentlicht, wie sich bei der Verwendung privater Repositories Angriffe über öffentliche Repositories eindämmen lassen [3]. Jede Strategie wird dabei sinnvoll mit praktischen Tipps für die unterschiedlichen Paketmanager ergänzt.

Für das Einschleusen von Schadsoftware in Softwareprojekten hat ein Angreifer drei unterschiedliche Möglichkeiten:

1. die Manipulation des Quellcodes und damit die automatische Verteilung über resultierende Softwarepakete,

2. die Veränderung des Build-Prozesses und damit verbunden die Manipulation der resultierenden Artefakte, um die Schadsoftware als Teil der zur Verfügung gestellten Pakete auszubringen, oder

3. die Änderung der ausgelieferten Pakete unmittelbar in den Paket-Repositories.

Üblicherweise wird der Source Code von Softwareprojekten heutzutage in versionierten Repositories mit unterschiedlichen Branches vorgehalten. Die ausgelieferte Software liegt dabei entweder in einem eigenen Deployment-Branch oder in dem Haupt-Branch des Repositories. Änderungen entwickeln die beitragenden Developer, in unserem Fall also der Angreifer, in eigenen Branches und bitten nach Fertigstellung über ein Pull-Request darum, die Änderungen in den Haupt-Branch zu übernehmen. Hauptentwickler können ihre Änderungen direkt in den Haupt-Branch einbringen und so auch die Pull-Requests der Entwickler bearbeiten und nach einer entsprechenden Durchsicht und Qualitätssicherung den Entwicklerbranch in den Haupt-Branch integrieren.

Um die Qualitätssicherung des Haupt-Branches zu umgehen – vor allem natürlich, weil dabei die Gefahr besteht, entdeckt zu werden – kann ein Angreifer versuchen, Hauptentwicklerrechte zu erhalten. Dafür probiert er, das Benutzerkonto eines Hauptentwicklers zu übernehmen, etwa wenn dieser ein schwaches oder ein bereits gestohlenes Benutzerpasswort zum Schutz seines Accounts verwendet, oder aber sich über Social-Engineering zu einem Hauptentwickler befördern zu lassen.

Hat ein Angreifer, beispielsweise über andere Verwundbarkeiten oder gestohlene Benutzerkonten, Zugang zum Build-System der Software, kann er entweder vor dem Bau der Pakete die notwendigen Änderungen am Source Code vornehmen, sodass diese beim Erstellen der Pakete dann berücksichtigt werden, oder die Pakete nach dem Build-Prozess gegen eigene Versionen austauschen. Das spart vor allem den Umweg über die versionierten Repositories und ist damit im Nachgang auch schwerer nachzuvollziehen. Die Manipulation muss aber vor dem Erstellen der digitalen Signatur der Pakete stattfinden, sodass später keine Verdachtsmomente bei der Verwendung auftreten.

Als Drittes gibt es für einen Angreifer die Möglichkeit, über Schwachstellen oder gestohlene Benutzerdaten Zugang zu den Paket-Repositories zu erlangen, über die die Software später verteilt wird. Durch gezielte Manipulation der Metadaten lassen sich so auch kryptografische Prüfsummen austauschen, damit die Veränderung der ausgelieferten Pakete bei der Verwendung nicht auffällt.

Stücklisten spielen beim Management analoger Lieferketten eine große Rolle. Dort wird für alle eingesetzten Produkte festgehalten, welche Bestandteile oder Bauteile für die Produktion notwendig sind. Dieses Prinzip hat die National Telecommunications and Information Administration (NTIA) unter dem Begriff "Software Bill Of Materials" (SBOM, zu Deutsch Software-Stückliste) für die Nutzung bei Softwareprodukten abgeleitet [4]. Auf den zugehörigen Webseiten bietet die NTIA grundlegende Informationen zur SBOM an und gibt Hinweise zum Aufbau und zur Benutzung.

Für Softwarehersteller selbst ist eine SBOM im Grunde obligatorisch. Vor allem dann, wenn Lizenzgebühren für die Verwendung der Software anfallen. Je nachdem, welche Bibliotheken zum Einsatz kommen, finden nämlich Lizenzgebühren und -bedingungen Anwendung. Einmal angelegt, erlaubt die SBOM auch die regelmäßige Überprüfung der Abhängigkeiten. Im Rahmen der Lieferketten-Überprüfung können diese Informationen von den Softwareherstellern an Kunden weitergereicht werden.

Ein wichtiger Punkt bei der automatisierten Erstellung, Verwendung und Überwachung von Software-Stücklisten ist die maschinenlesbare Darstellung. Es gibt drei unterschiedliche von der NTIA empfohlene Formate einer SBOM:

- das Software Package Data Exchange (SPDX) [5],

- CycloneDX [6] und

- die Spezifikation aus ISO/IEC 19770-2:2015.

Wenn Sie für Ihre eigene oder die in Ihrem Unternehmen genutzte Software eine SBOM anlegen möchten, sollten Sie sich diese Spezifikationen entsprechend genau ansehen und die für Ihren Anwendungsfall optimale Darstellung auswählen.

Wenn Sie die Überwachung der Lieferketten Ihres Unternehmens erfolgreich gestalten möchten, müssen Sie ein umfassendes Verständnis einer Lieferkette und aller daran beteiligten Unternehmen entwickeln. Der erste Schritt ist also eine Auflistung von Unternehmen, mit denen Ihr Unternehmen zusammenarbeitet. Diese Informationen ließen sich beispielsweise nach Abteilung sammeln. Eine Zusammenstellung erfolgt dabei anhand Ihrer Unternehmensstruktur und könnte etwa wie folgt aussehen.

Fangen wir etwa bei den Mitarbeitern Ihres Unternehmens an, so existieren Lieferketten in Richtung Recruiting-Unternehmen oder Headhuntern, zu Anbietern von Corporate-Benefit-Plattformen oder Abrechnungsunternehmen. Auch in Richtung Ihrer Kunden und des möglicherweise ausgelagerten Kunden-Supports existieren Lieferketten. Dazu gehören dann auch externe Vertriebsmitarbeiter, Loyality-Partner, Systemhäuser und Franchise-Unternehmen, aber auch Joint-Ventures und Logistikpartner.

Vielleicht unterhält Ihr Unternehmen für die Erstellung und Durchsetzung von Verträgen, für Patentanträge oder die Durchführung laufender Rechtsverfahren auch Verbindungen zu Kanzleien oder Wirtschaftsberatern und -prüfern für die betriebswirtschaftlichen Abläufe. Für die Absicherung von Risiken, etwa von Angriffen gegen Ihre IT-Infrastruktur oder Ihre Lieferketten, haben Sie Versicherungen abgeschlossen und sind in regem Austausch mit Agenturen. Auf keinen Fall vergessen sollten Sie Lieferketten mit Bezug zu den Räumlichkeiten Ihres Unternehmens samt Ausstattung. Auch diese sollten Sie in Ihre Planung einbeziehen wie auch Hersteller und Lieferanten von Computer- und Netzwerkhardware samt Druckern.

Haben Sie alle Unternehmen katalogisiert, machen Sie sich klar, welche Beziehung Sie zu jedem einzelnen Unternehmen haben, welche Informationen Sie mit diesem austauschen und wie kritisch ein Ausfall jeweils ist. Wer verarbeitet möglicherweise Daten von Ihnen oder Ihren Kunden und was würde es bedeuten, wenn diese für einen gewissen Zeitraum nicht zugreifbar wären – oder im Gegenteil, was passiert, wenn die Daten dort ausgeleitet und vielleicht sogar veröffentlicht werden? Gibt es Verträge, die eine Überprüfung der Lieferkette ermöglichen?

Wenn Sie die Kritikalität der Unternehmen bewertet haben, dann suchen Sie das Gespräch, zunächst intern mit den Kollegen, die eng mit den kritischen Firmen zusammenarbeiten, und anschließend mit den Partnern selbst. Lassen Sie sich Informationen über die Maßnahmen geben, die dort getroffen wurden, und hinterfragen Sie die Risikostrategien auch hinsichtlich der dort existierenden Lieferketten.

Es gibt unterschiedliche Ansätze, um ein zentralisiertes IT-Sicherheitsmonitoring auch über Unternehmensgrenzen hinweg zu etablieren. Individuelle Vereinbarungen zwischen Unternehmen einer Lieferkette können dies ermöglichen. Eine große Hürde dabei sind jedoch Aspekte des Datenschutzes und des Schutzes von Unternehmensgeheimnissen. Da Lieferketten, wenngleich der Begriff eine Linearität suggeriert, eher sternförmig sind und bei dem Hersteller des Endprodukts zusammenlaufen, besteht zwischen einzelnen Zulieferern möglicherweise keine vertragliche Vereinbarung, vielleicht sogar eine Konkurrenzsituation.

Das vom Bundesministerium für Bildung und Forschung geförderte und von der Fraunhofer Gesellschaft geleitete Forschungsprojekt "MonIKA" [7] untersuchte von 2012 bis 2014 Möglichkeiten kooperativen Monitorings kombiniert mit Ansätzen zur Pseudonymisierung geteilter Informationen wie Logeinträgen und darauf aufbauender Anomalie-Erkennung. Am Beispiel einer Lieferkette in der Automobilindustrie wurden Logsensoren bei allen Zulieferern ausgebracht und die Daten vor dem Versand anhand festgelegter Regeln verändert beziehungsweise datenschutzrelevante Elemente pseudonymisiert. Eine zentrale Instanz hat die geteilten Informationen zusammengeführt und mit Hilfe angepasster Algorithmen zur Anomalieerkennung Angriffe gegen die Lieferkette erkannt.

Auch wenn die Ergebnisse des MonIKA-Projekts offenbar nicht bis zur Marktreife weiterentwickelt wurden, ist es heutzutage möglich, IT-sicherheitsrelevante Informationen über Threat-Intelligence-Plattformen wie MISP [8] unter allen an einer Lieferkette beteiligten Unternehmen zu teilen, ohne dabei Geschäftsgeheimnisse zu offenbaren. Tatsächlich ermöglichen unterschiedliche MISP-Instanzen beziehungsweise eine entsprechende Hierarchie sowie die Unterscheidung von internen und externen Informationen auch die Teilnahme an mehreren Kooperationsnetzwerken. Als Zulieferer müssen Sie hier natürlich nicht nur ein Unternehmen oder eine Lieferkette bedienen, sondern möglichst alle. Damit dieser Ansatz erfolgreich die Sicherheit der Lieferkette erhöhen kann, müssen bei allen entsprechenden Unternehmen genügend Ressourcen zur Verfügung stehen, um Angriffsversuche und erfolgreiche Angriffe zu analysieren und über MISP zu teilen.

Leider können wir in diesem Artikel keine umfassende Lösung in Sachen Supply-Chain-Angriffe präsentieren. Doch zumindest gibt es Ansätze, die Sie in Ihrem Unternehmen zur Absicherung gegen Cyberangriffe über Lieferketten umsetzen können. Vor allem der zeitnahe Austausch von Bedrohungs- und Angriffsinformationen über Unternehmensgrenzen hinweg ist hilfreich.