Angriffe auf die Software-Lieferkette stellen eine zunehmend besorgniserregende Bedrohung dar. Laut einer aktuellen Studie von BlueVoyant waren beeindruckende 97 Prozent der befragten Unternehmen bereits negativ von einer Sicherheitsverletzung in ihrer Lieferkette betroffen, und 38 Prozent gaben an, keine Möglichkeit zu haben, von potenziellen Problemen mit der Cybersicherheit eines Drittanbieters zu erfahren.
Ankur Shah, Senior Vice President für Prisma-Cloud-Produkte bei Palo Alto Networks, sagte gegenüber eSecurity Planet, dass öffentlichkeitswirksame Bedrohungen wie die Log4j- und Spring4Shell-Schwachstellen diese Sorgen ins Zentrum der Aufmerksamkeit gerückt haben – und dass sie aus drei wesentlichen Gründen immer häufiger auftreten, so Shah.
3 Ursachen für die wachsenden Bedrohungen der Lieferkette
Erstens wurde laut Shah in seiner Zeit als Entwickler vor Jahren nichts, was er erstellte, bereitgestellt, bevor es umfangreiche Sicherheits- und Qualitätssicherungstests durchlaufen hatte. „Heute können Entwickler praktisch direkt aus ihrer IDE heraus auf eine Schaltfläche klicken und innerhalb weniger Minuten alles testen, absichern und bereitstellen“, sagte er. „Kunden bringen Anwendungen jede Stunde, jeden Tag und immer dann auf den Markt, wenn sie wollen, und Unternehmen lieben das. Es ist ein Kreislauf, der sich selbst verstärkt, und daran wird sich nichts ändern – Entwickler werden wegen Qualität oder Sicherheit nicht langsamer arbeiten.“
Zweitens ist die Zahl der Entwickler deutlich schneller gewachsen als die Zahl der Sicherheitsexperten, sodass es für die Sicherheitsfachleute nahezu unmöglich ist, Schritt zu halten. „Heute ist jeder ein Entwickler“, sagte Shah. „Es gibt mehr als 33 Millionen Entwickler gegenüber 3 Millionen Sicherheitsexperten. Das ist also ein Kampf, den die Sicherheitsseite nicht gewinnen kann.“
Drittens bestand laut Shah in seiner Zeit als Entwickler der eigene Code meist zu etwa 80 Prozent und Open-Source-Bibliotheken zu 20 Prozent – heute sei es oft umgekehrt. „Lade Open-Source-Code von hack me dot com herunter, und schon ist er Teil deines Container-Images, was auch immer es ist – und dann weiß niemand, was passiert. Er wird in Hunderttausenden Workloads bereitgestellt, und die Hölle bricht los“, sagte er.
Und der Code muss nicht einmal von irgendeiner beliebigen Website stammen – Log4j ist nicht bloß irgendeine beliebige Komponente eines kleinen Drittanbieters. „Das ist Apache“, sagte Shah. „Der Anbieter ist dafür bekannt, Open Source 101 zu verkörpern – ein vertrauenswürdiger Anbieter, eine vertrauenswürdige Komponente – und trotzdem hat jemand eine Schwachstelle entdeckt, die sich relativ leicht ausnutzen lässt.“
Lesen Sie auch: Neue Open-Source-Sicherheitsinitiative gegen Angriffe auf die Lieferkette
4 Schritte zur Codesicherheit
Als Reaktion darauf müssen Unternehmen laut Shah den gesamten Anwendungslebenszyklus vom Code bis zur Laufzeit absichern. Dazu gehört, die Sicherheit an mindestens vier wichtigen Punkten des Prozesses aktiv zu überwachen.
Der erste Schritt erfolgt während der Entwicklung: Es muss sichergestellt werden, dass jeder verwendete Open-Source-Code sicher ist. „Wenn Entwickler ihren Code in der IDE erstellen und einfach sagen: ‚Importiere diese Open-Source-Komponente‘, sollten sie sofort erfahren: ‚Bist du sicher, dass du das tun willst? Denn diese bestimmte Open-Source-Komponente weist eine bekannte Schwachstelle auf‘“, sagte Shah.
Das Bewusstsein der Entwickler für diese Probleme zu schärfen, sei ein guter Anfang, sagte er. Allerdings müsse jedes Unternehmen seine eigene Risikotoleranz bestimmen. Ein Fintech-, Gesundheits- oder Regierungsunternehmen muss bei Open-Source-Komponenten wahrscheinlich vorsichtiger sein als Unternehmen in anderen Branchen, die möglicherweise ein anderes Gleichgewicht zwischen Sicherheit und Bereitstellungsgeschwindigkeit anstreben.
Der nächste zu berücksichtigende Bereich ist die Infrastruktur als Code. „Häufig nutzen Angreifer Schwachstellen in der Infrastruktur aus – übermäßig großzügige Sicherheitsgruppen und Ähnliches. Deshalb muss neben dem Open-Source-Code auch die Infrastruktur als Code abgesichert werden“, sagte Shah.
Ebenso wichtig ist es, das Code-Repository abzusichern – der dritte Schritt in Shahs Vorgehen. „Stellt sicher, dass euer VCS, euer Git-Repository, keine Schwachstellen aufweist – etwa indem es dem öffentlichen Internet ausgesetzt ist. Bei Capital One war das Code-Repository offengelegt, und jemand konnte es ausnutzen. Stellt sicher, dass ihr über Multi-Faktor-Authentifizierung verfügt, dass ihr nur innerhalb eures Unternehmens-VPN darauf zugreifen könnt und dass es nicht im öffentlichen Internet verfügbar ist.“
Schließlich sollte vor der Bereitstellung eine zusätzliche Prüfung erfolgen. „Überprüft eure Container-Registries und eure CI/CD-Pipeline und stellt sicher, dass dort noch eine weitere Prüfung durchgeführt wird“, sagte Shah. „Danach folgt die letzte Phase: Die Dinge gehen in die Produktion.“
Lesen Sie auch:
Verteidigung in der Tiefe
Bei diesem gesamten Prozess geht es laut Shah darum, eine mehrschichtige Verteidigung sicherzustellen. „Man führt nicht nur einen Schritt aus“, sagte er. „Man nimmt diese Sicherheitsprüfungen und Kontrollen auf jedem Abschnitt des Weges vor – beim Schreiben des Codes, beim Erstellen, bei der Bereitstellung und zur Laufzeit. Wenn man das tut, ist die Wahrscheinlichkeit eines Fehlers minimal.“
Durch Prüfungen während des gesamten Prozesses entsteht laut Shah ein Ansatz für Code, der Toyotas Konzept Jidoka ähnelt und es jedem ermöglicht, das Fließband anzuhalten, wenn ein Fehler entdeckt wird. „Die Idee dahinter ist, dass das Problem umso schlimmer wird, je weiter das Auto am Fließband voranschreitet – also sollte man es so früh wie möglich beheben. Führt auf jedem Abschnitt des Weges Qualitätsprüfungen durch.“
Schließlich lohnt es sich laut Shah für viele Unternehmen, einen Plattformanbieter in Betracht zu ziehen, statt Lösungen stückweise zu kombinieren. „Mehr Sicherheitstools machen euch nicht sicherer“, sagte er. „Sie machen euch weniger sicher. Mit einem Plattformansatz für eure Sicherheit erhaltet ihr einen umfassenden Überblick – ihr müsst nicht eine Reihe voneinander unabhängiger Dinge zusammenfügen.“
Weiterführende Lektüre: