Den Grundstein legen: Software-Supply-Chain-Sicherheit

Im weiteren Sinne ist eine Lieferkette alles, was benötigt wird, um ein Produkt zu erstellen und an den Endverbraucher zu liefern. Eine Software-Lieferkette ist also nicht anders – die einzige Nuance besteht darin, dass sie sich auf Code und Anwendungen und alles bezieht, was mit ihrer Entwicklung und Bereitstellung zu tun hat.

So wie ein Automobilhersteller über ein breites Netzwerk von Lieferanten und Teilen verfügen kann, kann sich ein Softwareanbieter bei der Herstellung seines Produkts auf eine komplexe Vielfalt von Codes, Tools und Ressourcen verlassen.

Das Hauptanliegen hierbei ist, dass ein Defekt oder eine Schwachstelle an einer beliebigen Stelle in einer Lieferkette Auswirkungen auf alle weiter unten in der Lieferkette befindlichen Einheiten (oft als „nachgelagert“ bezeichnet) haben kann.

Dies war jedoch schon immer ein Anliegen der Lieferkette, also warum ist es heute in der Softwarebranche so wichtig?

Da wir durch die digitale Transformation mehr denn je von Technologie abhängig sind, um unsere Geschäfte und unser tägliches Leben zu führen, ist das Rennen für Technologieunternehmen, ihre Produkte auf den Markt zu bringen, sehr wettbewerbsintensiv. Infolgedessen konzentrieren sich diese Unternehmen mehr auf die Innovation dessen, was ihre Produkte einzigartig macht, und weniger darauf, „das Rad neu zu erfinden“. Mit anderen Worten, Software hat sich vom Erstellen zum Zusammenbauen verlagert – jedes Teil stammt von verschiedenen Einheiten, die sich auf die Herstellung dieses Teils spezialisiert haben. Beispielsweise verschwendet ein E-Commerce-Unternehmen keine Zeit mit dem Aufbau einer Datenbank; ein Online-Banking-Institut verschwendet keine Zeit damit, Tools für die Benutzeroberfläche zu erstellen; Ein IoT-Unternehmen wird keine Zeit damit verschwenden, ein benutzerdefiniertes Betriebssystem zu erstellen. Stattdessen wenden sie sich alle an Dritte, Open-Source- Projekte und Auftragnehmer, die diese Teile liefern.

Tatsächlich hat der jüngste Open Source Security & Risk Analysis (OSSRA)-Bericht von Synopsys festgestellt, dass durchschnittlich 97 % aller geschriebenen Software mindestens einen Teil des Open-Source-Codes enthalten. Von den 17 im Bericht vertretenen Branchen enthielten Computerhardware und Halbleiter, Cybersicherheit, Energie und saubere Technologien sowie das Internet der Dinge (IoT) Open Source in 100 % ihrer Codebasen. Die übrigen Branchen hatten Open Source in 93 % bis 99 % ihrer Codebasen. Selbst die Sektoren mit dem niedrigsten Prozentsatz – Healthcare, Health Tech, Life Sciences – hatten 93 %, was immer noch sehr hoch ist. Es ist klar, dass Open Source wirklich überall ist.

Aber was passiert, wenn eine Open-Source-Komponente eine Schwachstelle enthält? Oder wurde vielleicht das Konto des Betreuers gehackt und bösartiger Code eingefügt? Das bedeutet, dass das IoT-Unternehmen ein Betriebssystem mit einer kritischen Schwachstelle verwendet, die dem Endbenutzer die Möglichkeit gibt, sein intelligentes Thermostat oder seine WLAN-Kamera möglicherweise zu hacken. Das Problem begann innerhalb der Open-Source-Komponente. Es wurde von der IoT-Firma in ihr Produkt implementiert, das an den Endbenutzer verkauft wurde, der schließlich angegriffen wurde. Dies ist die Essenz eines Software-Supply-Chain-Unternehmens. Laut den OSSRA-Ergebnissen von 2022 enthielten 100 % der Codebasen im IoT-Sektor Open Source, und erstaunliche 92 % des geprüften Codes in diesem Sektor waren Open Source. Beunruhigenderweise enthielten 64 % der IoT-Codebasen auch Schwachstellen.

In ähnlicher Weise hatten die Sektoren Luft- und Raumfahrt, Luftfahrt, Automobil, Transport und Logistik Open Source in 97 % ihrer Codebasen, und 60 % des gesamten Codes bestand aus Open Source. Sechzig Prozent der Codebasen dieser Sektoren wiesen Open-Source-Schwachstellen auf.

Hier sind zwei Beispiele aus der Praxis für Bedenken in der Softwarelieferkette:

1. SolarWinds.

Vielleicht einer der bemerkenswertesten Angriffe auf die Softwarelieferkette. Ein internes Passwort wurde online geleakt, das von Angreifern verwendet wurde, um sich Zugang zu den Build-Systemen von SolarWinds zu verschaffen. Hier begann der Angriff auf die Lieferkette. Angreifer fügten schädlichen Code in die bevorstehende Version von Orion, dem Flaggschiff von SolarWinds, ein

Produkt. Dieser bösartige Code blieb unentdeckt, wurde in die Artefakte der Produktversion eingebaut und an Kunden versendet. Und mit dieser Version diente Orion nun als Portal für Angreifer, um SolarWinds-Kunden zu infiltrieren. Zu diesen Kunden gehörten mehrere US-Bundesbehörden. Die Tatsache, dass der anfängliche Angriff mehrere Grad vom beabsichtigten Ziel entfernt stattfand, macht ihn zu einem leuchtenden Beispiel für einen Supply-Chain-Angriff. Es ist dieser Angriff, zusammen mit anderen Angriffen auf kritische Infrastrukturen, die zur Cybersecurity Executive Order geführt haben.

2. Log4Shell.

Obwohl es keine [bestätigten] erfolgreichen Angriffe gegeben hat, die diese Schwachstelle ausnutzen, dient sie als solides Beispiel für die potenziellen Auswirkungen einer Schwachstelle auf die Lieferkette. Apache Log4J ist ein äußerst beliebtes Java-Protokollierungsframework. Es arbeitet im Hintergrund von Anwendungen, mit denen unzählige Unternehmen und Verbraucher täglich interagieren. Im Dezember 2021 wurde eine Zero-Day-Schwachstelle mit hohem Schweregrad in mehreren Versionen bekannt, die von entfernten Angreifern ausgenutzt werden konnte, um Zugriff auf die Betriebsserver zu erhalten. Wäre dies zuerst von Angreifern entdeckt worden, wären die Auswirkungen verheerend und weitreichend gewesen. Dies zeigt, wie ein einfaches Datenbereinigungsproblem in einer einfachen (aber beliebten) Komponente die Lieferkette in Mitleidenschaft ziehen und verheerende Auswirkungen auf alle Anwendungen haben kann, die davon abhängen. Die 2022 OSSRA stellte fest, dass 15 % der geprüften Java-Codebasen eine anfällige Log4J-Komponente enthielten.

Es gibt zwei Arten von Unternehmen, die sich um das Risiko der Softwarelieferkette kümmern sollten: Softwarehersteller und Softwarebetreiber. Oft stellen wir fest, dass die meisten Organisationen beides sind; sie nutzen Software, die von anderen Unternehmen entwickelt wurde, und verwenden sie, um Software zu erstellen, die sie verkaufen/vertreiben oder selbst betreiben. Unabhängig davon kommt es bei der Minderung des Lieferkettenrisikos darauf an, zu wissen, was in Ihrer Software steckt, und sie gegen bekannte Angriffe zu schützen. Noch einfacher ausgedrückt: Unternehmen müssen ihren Softwareentwicklungslebenszyklus (SDLC) sichern.

Die Sicherung des SDLC kann in einige wichtige Überlegungen unterteilt werden:

Sicherheitscode

· Open-Source-Abhängigkeiten. Identifizieren Sie den gesamten Open-Source-Code, der in Ihren Anwendungen verwendet wird, damit sie überwacht und auf Sicherheits- und Lizenzeinhaltungsbedenken hin bewertet werden können.

· Kommerziell/Drittanbieter. Verfolgen Sie den gesamten Code von Drittanbietern, damit er und sein Inhalt auf alle damit verbundenen Risiken bewertet werden können.

· Brauch. Stellen Sie sicher, dass jeder benutzerdefinierte oder proprietäre Code, den Ihr Unternehmen schreibt, frei von Fehlern oder Sicherheitslücken ist.

Sichere Bereitstellung

· Behälter. Vergewissern Sie sich, was der Inhalt eines Containers ist, bevor Sie ihn versenden. Schwachstellen in Basis-Images, Abhängigkeiten, die während der Build-Zeit eingeführt werden, und fest codierte Geheimnisse sind alles Bereiche, die Anlass zur Sorge geben.

· Infrastruktur als Code (IaC). Was früher in der Verantwortung eines erfahrenen IT-/Ops-Experten lag, liegt jetzt in der Verantwortung der Entwickler, die Infrastruktur zu konfigurieren, auf der ihre Apps ausgeführt werden. Häufige Sicherheitslücken und Open-Source-Vorlagen können Angriffen Tür und Tor öffnen.

Software-Stückliste (SBOM)

· Produzieren Sie es, verlangen Sie es. Wenn Sie Software für den Betrieb beschaffen, fordern Sie von Ihren Anbietern eine SBOM an. Wenn Sie Software produzieren, sollten Sie darauf vorbereitet sein, Ihren Kunden eine zur Verfügung zu stellen, insbesondere wenn sie im öffentlichen Sektor oder in der US-Regierung tätig sind. An dieser Stelle ist es am besten, die NTIA-Richtlinien für die Anforderungen an eine SBOM zu befolgen. Diese Dokumente bieten Einblick in die Software, die Ihr Unternehmen antreibt, sodass Sie schnell auf Bedrohungen reagieren können.