Nach der Attacke

Es ist über ein Jahr her, dass SolarWinds Sunburst Tausende von Unternehmen auf der ganzen Welt in Aufruhr versetzte und zu einem Beben in der Branche führte. Kürzlich kam es zu einem Nachbeben, als Cyberkriminelle die Schwachstelle Log4Shell ausnutzten. Sie ermöglichte es ihnen, über ein betroffenes Gerät oder eine Anwendung auf ganze Netzwerke zuzugreifen und Millionen von Geräten im Internet zu kompromittieren. Eine andere Sicherheitslücke mit Namen Spring4Shell machte Millionen von Anwendungen und Websites für Angriffe anfällig. Bereits in einer Woche waren 37.000 Instanzen der Sicherheitslücke ausgenutzt wurden.

Das Ausmaß dieser Angriffe macht den Unterschied aus. Angriffe auf die Lieferkette gab es schon früher, aber 2021 war das Jahr, in dem sie in den Mittelpunkt der weltweiten Öffentlichkeit rückten. Wie bei den ausgenutzten Angriffen durch Spring4Shell und Log4j hat die Verwendung von Open-Source-Lösungen das Risiko erhöht. Sie sind in fast jeder Form der Entwicklung allgegenwärtig und werden oft mit hoher Geschwindigkeit programmiert, was zu Sicherheitslücken führt. Das bedeutet, dass die Auswirkungen von Schwachstellen in diesen Komponenten weitaus größer sind.

Nach den Vorfällen mit Log4J und Spring4Shell gibt es drei wichtige Lektionen, die Unternehmen lernen müssen, damit sie bei der Nutzung von Open-Source-Software sicher bleiben.

Risikoerkennung und -bewertung

Bei der Entwicklung, Verwaltung und Pflege einer Software-Lieferkette verhält es sich ähnlich wie bei allen anderen Dingen, die auf einer Kette beruhen – man muss alle Glieder verstehen und im Blick haben. Ein Incident Response-Team muss alle Fähigkeiten der beteiligten Personen kennen, wissen, welche Tools zur Verfügung stehen, bis hin zu den Sprachen der Personen und der Umgebung, in der sich die Situation ereignet. Wenn all diese Informationen nicht verfügbar sind, sind diese wie blind und haben keine Vorstellung von den Risiken. Unternehmen müssen beim Schutz ihrer Software-Lieferketten den gleichen Ansatz verfolgen und sicherstellen, dass jedes Glied sicher ist.

Es ist unvermeidlich, dass neue kritische Schwachstellen in der Supply-Chain-Software entdeckt werden, vor allem in den Open-Source-Bibliotheken und -Frameworks, die immer beliebter werden und in Unternehmen auf der ganzen Welt eingesetzt werden.

Um die Sicherheit zu gewährleisten, benötigen Unternehmen jedoch eine klare Bestandsaufnahme und ein genaues Verständnis aller verwendeten Open-Source-Komponenten. Sie können es sich nicht leisten, blind auf die Herkunft und Sicherheit von Softwarekomponenten zu vertrauen. Wenn die Vorfälle von Log4Shell, Spring4Shell und SolarWinds etwas gelehrt haben, dann, dass es ein größeres Bewusstsein für alle verschiedenen verwendeten Softwarekomponenten bedarf. Dazu gehört auch, wie und wo sie entwickelt wurden sowie wo sie im Unternehmen eingesetzt werden, damit bei der Entdeckung von Sicherheitslücken das Problem schnell behoben werden kann, um den Schaden zu begrenzen.

Komplexität entfernen

Nummer zwei auf der Liste ist die Notwendigkeit, sich robust aufzustellen. Bei der Entwicklung von Frameworks oder Bibliotheken ist es wichtig, dass sie gut aufgebaut werden. Aber es ist auch wichtig, einen einfacheren Ansatz zu wählen, damit man nicht unwissentlich Schwachstellen einführt.

Sich darauf zu konzentrieren, einige wenige Dinge gut zu machen, ist besser, als viele Funktionen schlecht einzuführen. Im Fall von Log4J gab es all den Schnickschnack, der es zweifellos zu einem so beliebten Produkt der es aber auch verwundbar machte. Je mehr Funktionen es gibt, desto wahrscheinlicher ist es, dass es eine kritische Sicherheitslücke gibt. Wenn IT-Verantwortliche also überlegen, welche neuen Funktionen sie zu ihren Produkten und Diensten hinzufügen möchten, sollten sie sorgfältig abwägen, ob sie diese tatsächlich benötigen. Sie sollten nur solche Funktionen einschalten, von denen sie wissen, dass sie unerlässlich sind. Trotz der Notwendigkeit, schnell zu entwickeln, müssen Unternehmen sich die Zeit nehmen, um wirklich darüber nachzudenken, welche Funktionen sie unbedingt brauchen und warum – denn alles, was überflüssig ist, kann Schwachstellen Tür und Tor öffnen.

Standardaufgaben automatisieren

Drittens müssen Unternehmen bei der Konzeption und Entwicklung verschiedener Anwendungen auf übergreifende Aspekte achten. Ob Protokollierung, Metriken, verschlüsselte Kommunikation oder Caching – es ist wichtig zu überlegen, ob diese laufenden Belange innerhalb der Anwendung behandelt werden müssen oder ob sie stattdessen ausgelagert werden können.

Nehmen wir ein Beispiel. Bei der Protokollierung können viele Frameworks Protokolle an verschiedene Stellen senden, z. B. an Ausgabedateien namens stdout oder an Alarmierungsdienste, für die die Anwendung verantwortlich ist. Es gibt jedoch einen besseren und sichereren Ansatz, den die Verantwortlichen wählen können. Sie sollten stattdessen ihre Anwendung dazu zu bringen, Protokolle an stdout zu senden und dann einen Protokollsammeldienst zu nutzen, um die Protokolle an alle erforderlichen Endstellen zu senden. Durch die Auslagerung dieser Belange müssen sich die Entwickler weniger um Code und Konfiguration kümmern, und daher gibt es auch weniger Schwachstellen, die sich einschleichen können.

Fazit

Log4Shell und Spring4Shell dienten dazu, die Notwendigkeit für Unternehmen zu betonen, proaktive Schritte zum Schutz ihrer Umgebungen zu unternehmen. Dies wird jedoch nur noch schwieriger werden, da technische Innovationen immer schneller voranschreiten und immer mehr Maschinenidentitäten geschaffen werden, auf die Unternehmen ein Auge haben müssen.

Der Versuch, all diese Maschinenidentitäten zu überwachen und zu verwalten und gleichzeitig den Überblick über alle Softwarekomponenten zu behalten und eine einfache Software-Entwicklung sicherzustellen, ist keine leichte Aufgabe. Den Unternehmen fehlen heutzutage einfach die Fähigkeiten und Ressourcen, um all diese Aufgaben zu bewältigen. Stattdessen sollten sie Automatisierungs- und Sicherheitstools einsetzen, um sicherzustellen, dass diese Schwachstellen auf ein Minimum reduziert werden, so dass die Schockwellen von Angriffen in Folge der Log4j-Schwachstelle nicht so stark zu spüren sind.