In der weiteren Entwicklung bis zum gegenwärtigen Zeitpunkt wurde der potenzielle Schweregrad von Log4Shell (CVE-2021-44228) deutlich.
Bemerkenswert an Log4Shell ist aber weniger die Verbreitung als vielmehr die Erkenntnis, die durch die Aufdeckung ausgelöst wurde: Unternehmen und Behörden mussten nun überdenken wie sie Open-Source-Software verwenden und wie es um die Sicherheit von OSS im Allgemeinen bestellt ist. Also einer Software, die nicht von kommerziellen Anbietern kommt, sondern größtenteils von unbezahlten Freiwilligen entwickelt und gepflegt wird. Vielfach ist es Firmen nicht oder nicht ausreichend bewusst, wie viel Open Source in ihrer Software steckt.
Und noch eins hat der Vorfall mit Log4j gezeigt. Nämlich, dass Unternehmen grundsätzlich großes Vertrauen in Open Source setzen. Das hat dazu geführt, dass die meisten Entwicklerteams Open Source ohne die Sicherheitsüberprüfungen verwenden, wie sie für kommerzielle oder proprietäre Software erforderlich sind.
Nutzung von Open Source nimmt zu
Laut dem kürzlich veröffentlichten „2022 Open Source Security and Risk Analysis“ (OSSRA)-Bericht des Synopsys Cybersecurity Research Center, nimmt die Nutzung von Open Source und Fremdsoftware weiterhin rasant zu. Tatsächlich enthalten 4 der 17 im OSSRA-Bericht 2022 vertretenen Branchen – Computerhardware und Halbleiter, Cybersicherheit, Energie und Clean Tech sowie Internet der Dinge – in 100 Prozent der geprüften Codebasen Open Source.
Die übrigen Branchen verwenden Open Source in 93 Prozent bis 99 Prozent ihrer Codebasen. Anders formuliert: Entwickler nutzen zweifellos Open Source in irgendeiner Form innerhalb des Lebenszyklus der Softwareentwicklung.
Wenn Sie als Softwareanbieter Open Source zusammen mit den Komponenten von Drittanbietern und kommerziellen Anbietern verwenden, werden diese Komponenten Teil der Lieferkette. Und diese Lieferkette endet nicht beim eigenen Team. Sie geht über die eigenen Entwicklungs- und Lieferaktivitäten hinaus und reicht bis zum Endbenutzer der betreffenden Anwendungen.
Zu dieser Lieferkette zählt alles, was mit der Anwendung in Berührung kommt oder bei der Zusammenstellung, Entwicklung und Bereitstellung eine Rolle spielt. So gesehen umfasst die Lieferkette auch proprietären Code und Komponenten, die von Ihrem Entwicklungsteam erstellt wurden, APIs und Cloud-Dienste, die ihre Software nutzt, und die gesamte Infrastruktur, für die Erstellung und Bereitstellung der Software an den Endbenutzer.
Beispiel Automobilbau
Ein gutes Beispiel, sich die komplexe Verflechtung von Lieferketten vor Augen zu führen, ist der Automobilbau. Die Lieferkette beginnt bei den Rohstoffen. Rohstofflieferanten stellen Metalle, Baumwolle, Leder, Holz und so weiter für die Teilehersteller bereit. Diese wiederum produzieren Teile wie Schrauben, Stoffe, Muttern und Bolzen, die dann an die Hersteller von Autoteilen und -systemen gehen.
Hier werden die für den Bau eines Fahrzeugs benötigten Komponenten (Motoren, Getriebe) konfektioniert. Schließlich werden diese Teile in Automobilqualität an Erstausrüster geliefert. Die schließlich bauen die Fahrzeuge am Fließband zusammen und bereiten sie zum Verkauf an den Verbraucher vor.
Wenn Sie sich diesen Prozess vergegenwärtigen, wird schnell klar, wo überall Risiken lauern. Welche Qualität haben die Teile, die für den Bau dieses Autos verwendet wurden? Wie gut hat der Automobilproduzent die Teile montiert? Wie verhält sich das Fahrzeug tatsächlich, wenn der Benutzer sich hinters Steuer setzt? Wie reagiert es auf Zwischenfälle und weniger ideale Fahrbedingungen?
Die Realität einer Lieferkette ist, dass das Endprodukt und seine Benutzer durch sämtliche am Prozess beteiligten Komponenten, Personen, Aktivitäten, Materialien oder Verfahren beeinflusst werden. Schwachstellen in jedem einzelnen Abschnitt dieses Workflows führen zu Risiken.
Die einzige Möglichkeit, sie zu senken, besteht darin, die komplette Lieferkette zu kennen. Das gilt analog für die Softwarelieferkette. Einfach ausgedrückt: Ein Unternehmen ist nur dann in der Lage, Risiken zu managen, wenn es Einblick in die gesamte Lieferkette hat. Bei derart vielen beweglichen Teilen reicht schon eine einzige unerkannte Schwachstelle oder ein Konstruktionsfehler, um weitreichende Auswirkungen zu provozieren.
Mehr Sicherheit für die Lieferkette: Einige grundsätzliche Überlegungen
Grundsätzlich geht es darum, Anwendungen vor vorgelagerten Risiken schützen und gleichzeitig zu verhindern, dass das eigene Unternehmen selbst nachgelagerte Risiken hervorbringt. Im Wesentlichen sind es sechs Bereiche, die Sie berücksichtigen sollten.
1. Ist die verwendete Open Source sicher?
Die Verbreitung von Open Source ist eine der grundlegenden Herausforderungen für die Sicherheit von Lieferketten. Open Source ist zwar nicht mehr oder weniger riskant als proprietärer Code. Fehlen angemessene Sicherheitsvorkehrungen, kann Open Source allerdings zu einem großen Risiko für die Gesamtsicherheit eines Unternehmens werden.
Entwickler nutzen wahrscheinlich bei fast jeder Anwendung, die sie erstellen, Open Source. Jede Ihrer Anwendungen wird also vermutlich zu einem nicht unbeträchtlichen Teil auf Code basieren, den Sie nicht selbst geschrieben haben. Das bestätigt schon der OSSRA-Bericht von 2021: 98 Prozent der für den Report gescannten Codebasen enthielten Open Source.
Und nicht immer ist es so, dass Open Source absichtlich benutzt wird. Man kann wohl davon ausgehen, dass Open Source den Weg in jedes Projekt findet, und das oft auch unbemerkt. Das Gleiche gilt für die Lieferanten, mit denen Sie zusammenarbeiten. Das ist nicht per se schlecht. Aber es ist nicht auszuschließen, dass vorgelagerte Risiken so den Weg in Ihre Anwendungen finden.
Es liegt folglich in Ihrer Verantwortung, Open Source-Komponenten, Lizenzen, Schwachstellen und die damit verbundenen Risiken innerhalb Ihrer Lieferkette nachzuverfolgen. Angesichts des nicht ganz unbeträchtlichen Umfangs ist das manuell nicht oder nur unzureichend möglich – und nicht zuletzt viel zu zeitaufwendig.
Neben Sicherheitsrisiken sollten Firmen die rechtliche Seite berücksichtigen. Die juristischen Folgen von Lizenzverstößen und -konflikten sind oft weniger bekannt als andere Sicherheitsrisiken. Bei Fusionen und Übernahmen führen sie aber schnell zu Streitigkeiten mit Lieferanten und zu Vertriebsproblemen. Für Softwareanbieter kann das juristische Risiko einer Schwachstelle in der Lieferkette schwerwiegende Auswirkungen auf den Ruf und die finanzielle Stabilität einer Firma haben.
Und schließlich kann ein operatives Risiko entstehen, wenn Teams veraltete Komponenten, Komponenten, die nicht mehr weiter entwickelt werden, oder Komponenten aus Projekten ohne tragfähige Entwickler-Community (der Code also nicht aktiv gepflegt wird) verwenden.
Abgesehen davon, dass es zu Problemen bei der Codequalität, der Zuverlässigkeit und der Wartung führt, ist das operationelle Risiko ein Einfallstor für Sicherheitsrisiken. Gibt es keine Entwickler, die Bugs in einem Projekt finden und beheben, gibt es auch keine Entwickler, die Sicherheitsmängel finden, offenlegen und beheben. Dies gilt insbesondere dann, wenn Projekte mit einem eher zweifelhaften Ruf oder wenig bekannte Projekte genutzt werden. Sie sind für Angreifer leichte Beute.
2. Wie sicher ist der Code, den Sie schreiben?
Open Source macht den größten Teil des Codes einer Anwendung aus. Da überrascht es nicht, dass er auch den überwiegenden Teil der Angriffsfläche repräsentiert. Dennoch ist es wichtig, dass der betreffende Code, sensible Daten und Systeme vor Cyberangriffen schützt.
Sicherheitsmängel und Schwachstellen, die versehentlich in Anwendungen kodiert werden, öffnen Angriffen wie Buffer Overflows, SQL-Injection und Cross-Site Scripting Tür und Tor. Sollte das System gehackt werden, sind sensible Daten gefährdet. Zudem lassen sich solche Schwachstellen ausnutzen, um in das Betriebssystem oder andere Systeme vorzudringen.
3. Wie schützt man sich vor mutwillig eingefügtem Schadcode?
Forrester prognostizierte, dass 33 Prozent der Sicherheitsverletzungen im Jahr 2021 auf Insider-Bedrohungen zurückgehen. Ganz gleich, ob es sich um einen verärgerten Entwickler handelt, der eine Backdoor einfügt oder um einen Hacker, der in ein System eingedrungen ist und einen größeren Angriff plant. Sorgfältig platzierter bösartiger Code ist ein immenses Risiko für die Software, die Sie entwickeln und betreiben.
Bösartiger Code wird meist von jemandem eingeschleust, der das Softwaresystem genau kennt. Deshalb erscheint das anfällige System oft als völlig normal. Das erschwert es, Risiken dieser Art mit herkömmlichen Tools zu erkennen.
4. Wie sicher ist die Infrastruktur für Entwicklung und Bereitstellung?
Der Bedarf an Datenspeichern wächst, die Bereitstellungsfristen werden kürzer und eine schnelle Skalierbarkeit war noch nie so wichtig wie heute. Die Softwarebranche ist als Folge davon zunehmend auf Cloud-Technologien angewiesen, um ihre Anwendungen zu betreiben.
Ein Teil dieses Cloud-nativen Ansatzes basiert auf Methoden, die gedacht sind, um schneller skalieren zu können und agile Prozesse zu unterstützen. Etwas, das Containerisierung und Infrastructure-as-Code (IaC) sehr gut können. Unternehmen sollten genau wissen, welche Software in Containern enthalten ist und wie eine Cloud-Plattform Infrastructure-as-Code für die Sicherheit bei der Bereitstellung nutzt.
5. Sind die APIs und Protokolle, die Ihre Anwendungen für die Kommunikation mit anderen Systemen verwenden, tatsächlich sicher?
APIs und Protokolle erlauben es, Daten und Dienste zwischen Anwendungen und Benutzern schnell zu übertragen. Obwohl immer mehr Unternehmen auf solche Methoden zurückgreifen, haben sie gleichzeitig Schwierigkeiten damit, die verwendeten APIs zu inventarisieren und dementsprechend weniger Kontrolle darüber, welche Benutzer auf welche Dienste zugreifen. Fehlende Transparenz und mangelnde Kontrolle über APIs gefährden die Sicherheit kritischer Systeme und sensibler Benutzerdaten.
Wenn sich die Gelegenheit bietet, kann ein Hacker solche Schwachstellen nutzen, um z.B. ein kritisches System zum Absturz zu bringen, für einen Man-in-the-Middle-Angriff oder einen Lauschangriff mit dem Ziel, Informationen wie Schlüssel, Passwörter, Anmeldeinformationen und Kontodaten abzugreifen. Genau die werden dann im Zuge weitreichender Angriffe an anderer Stelle innerhalb der Lieferkette verwendet.
6. Ist die Softwarelieferkette für Kunden und andere Stakeholder transparent?
Es ist wichtig, Kunden Einblick in die Inhalte einer Anwendung zu gewähren, damit sie Sicherheits- und Compliance-Probleme rechtzeitig erkennen und beheben können. Die Pflege einer Software-Stückliste (SBOM) ist eine bewährte Methode und der Eckpfeiler eines erfolgreichen Sicherheitsprogramms für die Lieferkette.
Ohne einen vollständigen, dynamischen Überblick über sämtliche Komponenten einer Anwendung können weder Sie selbst noch Ihre Lieferanten, noch Ihre Kunden zuverlässig feststellen, welchen Risiken Sie ausgesetzt sind.
