Unsere letzten Messeteilnahmen haben es wieder eindrücklich gezeigt: Cyber Security als Ganzes und Identity and Access Management (IAM) als essenzieller Teil davon nehmen an Bedeutung zu. Doch zu einem erleichterten Juhu-Schrei sollte sich kein Unternehmen verleiten lassen. Denn Wissenslücken wurden mit Blick auf ein großes Einfallstor deutlich sichtbar: die Software-Lieferkette.

Warum ein einzelnes Unternehmen hacken, wenn man eine Open-Source-Komponente, die in tausende von Software-Paketen eingebaut wird, mit wenig Aufwand infizieren kann? Willkommen in der Realität moderner Softwareentwicklung! Wer hier kurz stutzig wird: Ja, Open Source ist hochgelobt. Schließlich kann jeder, der sich darum bemüht, Schwachstellen im frei zugänglichen Quellcode finden und, falls dazu qualifiziert, ausbessern – aber eben auch für sich ausnutzen.

Software kommt meist nicht allein aus der Hand eines Herstellers. Heute ist sie viel mehr als Baukasten zu verstehen. Bits and Pieces – zusammengewürfelt aus eigenen Entwicklungen, Open-Source-Komponenten und Code-Fragmenten von Dienstleistern aus allen Teilen der Welt – fließen darin ein. Ein Vorgehen, das ein immenses Problem mit sich bringen kann: Ist eine Open-Source-Bibliothek „verseucht“, weisen hunderte von Produkten Sicherheitslücken auf. Die Konsequenzen werden meist erst deutlich, wenn es bereits zu spät ist. Vor allem, weil man selbst die bloße Möglichkeit zur akribischen Fehlersuche im Quellcode oft vernachlässigt oder dies „den anderen Nutzern“ überlässt.

Heute ist es für viele Unternehmen ein Mysterium, was eigentlich in der von ihnen genutzten Software steckt. Herkunft, Version, interne Abhängigkeiten zu Open Source Libraries? Fehlanzeige. Dokumentation? Nicht vorhanden! Kontrolle? Kaum. Noch schlimmer wird es aber, wenn sich Verantwortliche nicht einmal darüber im Klaren sind, dass gerade in der Software Supply Chain Sicherheitsrisiken lauern.

Umso positiver empfinden wir es, dass der Gesetzgeber mit Pflichten und Sicherheitsanforderungen gegensteuert. Wichtig, auch wenn die Formulierungen allgemeiner getroffen sind: All das betrifft auch die Software Supply Chain! Ein Auszug.

NIS2-Richtlinie (Network and Information Security):

• Pflicht zur Risikobewertung: Unternehmen müssen regelmäßig die Sicherheitspraktiken ihrer Lieferanten und Dienstleister bewerten und entsprechende Maßnahmen ergreifen, um die Sicherheit der Lieferkette zu gewährleisten.
• Vorstandsverantwortung: Die Unternehmensleitung ist verpflichtet, die Cyber-Sicherheitsmaßnahmen zu überwachen, zu genehmigen und sich entsprechend schulen zu lassen.
• Meldepflichten: Bei erheblichen Sicherheitsvorfällen müssen Unternehmen innerhalb von 24 Stunden eine Frühwarnung, innerhalb von 72 Stunden einen detaillierten Bericht und innerhalb eines Monats einen Abschlussbericht an die zuständigen Behörden übermitteln.

Digital Operational Resilience Act (DORA):

• Anforderungen an Finanzunternehmen: DORA verpflichtet Finanzunternehmen, sicherzustellen, dass sie gegenüber allen Arten von ITK-bezogenen Störungen und Bedrohungen widerstandsfähig sind.
• Drittanbieter-Risiken: Der Fokus liegt auf der Identifizierung und dem Management von Risiken, die durch Drittanbieter entstehen, insbesondere im Zusammenhang mit der Software-Lieferkette.
• Meldepflichten bei Schwachstellen: DORA schreibt umfassende Berichtspflichten bei schwerwiegenden Sicherheitsvorfällen vor – vergleichbar mit NIS2.

KRITIS-Dachgesetz

• Risikomanagement in der Lieferkette: Auch bei KRITIS müssen eingesetzte IT-Komponenten und Dienstleister hinsichtlich ihrer Sicherheitspraktiken bewertet werden – vornehmlich im Hinblick auf Herkunft, Betrieb und Kontrolle.
• Audits und Nachweispflichten: Die Sicherheitsmaßnahmen müssen nicht nur umgesetzt, sondern auch durch Prüfungen und Nachweise belegbar sein. Das betrifft auch eingesetzte Softwareprodukte.
• Verpflichtung zu Sicherheitsupdates: Systeme müssen kontinuierlich aktualisiert und gepatcht werden – vor allem dann, wenn sie sicherheitskritische Funktionen erfüllen.

Der Cyber Resilience Act (CRA) ist das einzige Regelwerk, das explizit eine SBOM-Pflicht (Software Bill of Materials) vorsieht – mehr dazu unten. Damit verbunden sind auch weitreichenden Folgen für Unternehmen außerhalb des IT-Sektors.

Cyber Resilience Act (CRA):

• Sicherheitsanforderungen für Produkte: Der CRA legt verbindliche Cyber-Sicherheitsanforderungen für Produkte mit digitalen Elementen fest, einschließlich Software und vernetzter Hardware.
• Verpflichtung zur Bereitstellung von Sicherheitsupdates: Hersteller müssen sicherstellen, dass ihre Produkte während des gesamten Lebenszyklus geschützt bleiben. Das bezieht sich auch auf die Bereitstellung von Sicherheits-Updates.
• Konformitätsbewertung: Produkte werden je nach Kritikalität in Klassen eingeteilt, die unterschiedliche Anforderungen an die Sicherheitsbewertung und -zertifizierung stellen.

Diese Punkte sind jeweils nur Auszüge. Was darüber hinaus gefordert wird und wie sich die Richtlinien gleichen oder unterscheiden, zeigt die Grafik (✅ bereits gefordert, ⭕ nicht gefordert/eventuell in Planung).

Die Umsetzung dieser Anforderungen können auf unterschiedliche Weise erfolgen. Nicht fehlen sollte aber eine Software Bill of Materials (SBOM) – nicht nur bei der CRA-Umsetzung. Sie stellt eine strukturierte Auflistung aller Komponenten, Bibliotheken und Abhängigkeiten dar, die innerhalb einer Software-Anwendung existieren. Führen Organisationen ihre SBOM gewissenhaft, erhalten sie im ersten Schritt Transparenz.

Im nächsten Schritt sollten Verantwortliche aber unbedingt tiefer graben. Schließlich zeigen uns reale Angriffe täglich, dass sich ausgenutzte Schwachstellen in der Software mit herkömmlichen Analysen nicht immer aufdecken lassen – denken Sie beispielsweise an den SolarWinds Vorfall, der eine unangenehme Kombination von Schwachstellen und Fehlverhalten einzelner Mitarbeiter des Dienstleisters darstellte. Ist eine Gefahr bzw. ein Risiko nicht erfasst und katalogisiert, wird es schwer, passende Gegenmaßnahmen zu etablieren.

Da bei gekaufter Software oftmals gar kein Quellcode verfügbar ist, muss die Analyse der gelieferten Binaries in den Fokus rücken. Sie untersucht die Binärdateien, um Manipulationen, versteckte Schadsoftware oder nicht dokumentierte Änderungen aufzudecken. Dies ist besonders wichtig, da nicht alle Hersteller selbst einen Überblick der verwendeten Bibliotheken in den Metadaten mitliefern.   

Zum Ziel „umfassende Sicherheitsstrategie für die Software Supply Chain“ gelangen Unternehmen durch eine Kombination von SBOM und binärer Analyse.

• Transparenz: SBOM liefern eine klare Übersicht über alle verwendeten Komponenten.
• Tiefe Analyse: Binäre Analysen decken verborgene Risiken auf, die in den Metadaten nicht sichtbar sind.
• Schnelle Reaktion: Bei Bekanntwerden neuer Schwachstellen lassen sich betroffene Komponenten schnell identifizieren und aktualisieren.

Sie nehmen Software Supply Chain Security nach diesem Beitrag ernst? Sie möchten sich tiefer mit Lösungen, wie denen unseres Partners ReversingLabs auseinandersetzen? Dann sollte sich Ihre Cyber-Sicherheitsstrategie nicht nur um Identity Security, sondern auch um Software Supply Chain Security drehen. So lassen sich verschiedenste Sicherheitslücken schließen und Ihr Unternehmen bewegt sich zielsicher in Richtung Compliance.