Log4Shell oder Solarwinds sind typische Beispiele für Angriffe auf Unternehmen, die über deren Software-Lieferkette erfolgten. Kennzeichnend dafür ist, dass Cyberkriminelle sich nicht direkt Zugang zum Zielunternehmen verschaffen, sondern der Angriff über eine Hintertür - im Fall von Solarwinds beispielsweise über ein kompromittiertes Update - erfolgt.
Doch was bedeutet das für die Cybersecurity-Branche und die Sicherheitsarchitektur von Unternehmen?
Lässt man einige Angriffe der letzten Zeit (insb. Solarwinds oder Log4Shell) Revue passieren, so fällt auf, dass diese immer mehr „über Bande“ spielen. Das bedeutet die Angreifer greifen Zielunternehmen nicht mehr direkt an, sondern über deren (Software)-Lieferkette. Ob nun Opfer über kompromittierte Solarwinds-Updates oder Lücken in Log4Shell angegriffen werden – in beiden Fällen ist die Software-Lieferkette gleichzeitig auch Infektionskette.
Damit gewinnt das Thema der Integrität der Supply Chain immer mehr an Brisanz. Das bedeutet in erster Linie: Kenne ich alle Lieferanten/Dienstleister in meiner Lieferkette? Und zwar nicht nur die direkten, sondern auch die transienten Abhängigkeiten!
Ist die gesamte Lieferkette so dokumentiert, dass man im Falle einer Lücke in genutzten Bibliotheken direkt sagen kann, ob die eigene Software betroffen ist? Sei es, weil man die Bibliothek direkt selbst einsetzt oder eine der transienten Abhängigkeiten.
Die „Integrität der Supply Chain“ rückt insbesondere bei Sicherheitsvorfällen schnell in den Mittelpunkt. In solchen Fällen ist man bemüht, den Schaden schnellstmöglich einzugrenzen. Je nach Umgebung gibt es dafür auch verschiedene technische Lösungen: (Virtuelle) Patches, Updates von Software-Abhängigkeiten, SLAs mit Dienstleistern und vieles mehr.
Leider lässt das Interesse daran, wie so oft, wenn der akute Schmerz weg ist, schnell nach, sobald das gröbste überstanden ist. Dabei sollte jedem klar sein, dass die Integrität der Lieferkette nichts ist, was man im Falle des Falles immer schnell mit einem technischen „Pflaster“ angehen sollte.
Vielmehr geht es hier um die Etablierung von entsprechenden Prozessen (und auch technischen Vorgehensweisen), die einem helfen, die Integrität der eigenen Supply Chain effizient zu verwalten. Dies führt zumeist zu einer kleineren Angriffsoberfläche und mindestens zu einer besseren Datenbasis, die bei einem Sicherheitsvorfall die manuelle Nachforschung reduziert.
Leider ist die Einführung von Prozessen zur Pflege der Integrität der eigenen Softwarelieferkette oft langwierig. Insbesondere da es hier nicht nur um technische Schutzaspekte geht, sondern es auch eine menschliche und administrative Komponente gibt. Außerdem ist im Vergleich zur technischen IT-Sicherheit das Wissen und Fachpersonal nur dünn vorhanden.
In diese Lücke stößt die Neufassung der NIST Special Publication SP800-161r1 („Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations“). Diese enthält eine umfassende Einführung in die Hintergründe, Mitwirkende und Implementation von sicheren Software-Lieferketten.
Die darin dokumentierten Vorgehensweisen und Beispielszenarien geben einen exzellenten Einblick in die Implementierung, aber auch in die Vorteile von sicheren Software-Lieferketten.
Damit ist die NIST-Publikation eine sehr wertvolle Ressource für jeden, der die Integrität seiner Software-Lieferkette verbessern möchte. Und daran sollte jedem gelegen sein! Zeigt die Erfahrung doch, dass Angreifer sich auf Angriffsmodelle konzentrieren, die funktionieren. Und dieser Nachweis ist bei Angriffen über die Lieferkette definitiv gegeben.
Daher sollte man sich jetzt mit der Absicherung und Dokumentation der Lieferkette beschäftigen – denn beim nächsten Angriff ist es dafür zu spät. Beziehungsweise ist man so mit der Abwehr beschäftigt, dass Prozesse eh‘ keine Rolle spielen. Und damit beginnt das Dilemma wieder von vorne ...