Zum Hauptinhalt springen
Lieferkettenrisiken infolge der Schwachstelle Log4j mindern
Perspektiven

Lieferkettenrisiken infolge der Schwachstelle Log4j mindern

Der neueste Cyber Bug zeigt, wie mangelnde Visibilität in Software von Dritten weiterhin organisatorische Netzwerke bedroht. So können Sie sich schützen.

Es ist zu erwarten, dass die Sicherheitslücke „ Log4j “ in den kommenden Monaten und Jahren im Internet für großes Chaos sorgen wird. Das Installieren von Patches hat sich für Unternehmen und Behörden zu einem Wettlauf entwickelt. Der Erfolg hängt von der Netzwerktransparenz, der Geschwindigkeit der Patching-Maßnahmen und den Arbeitsabläufen ab.

Log4j ist ein Protokollierungsprogramm. Es wird von nahezu jedem Cloud-Dienst und jedem Unternehmensnetzwerk weltweit genutzt, um Zugriff auf Server zu erhalten. Es handelt sich lediglich um die jüngste Schwachstelle in der Software-Lieferkette (ähnlich derjenigen, die bei dem groß angelegten SolarWinds-Angriff aufgedeckt wurde), die unser digitales Leben derzeit beeinträchtigt.

Die Wahrheit über diese Schwachstellen in der Lieferkette lautet jedoch: Sie können – und sollten – bekämpft werden, bevor sie Schaden anrichten können.

[Lesen Sie auch: Was ist Log4j und wie schütze ich mein Unternehmen?]

Nick Selby, ehemaliger Chief Security Officer beim Blockchain-Dienstleister Paxos, geht keine unnötigen Risiken ein, wenn es um die Sicherheit der Lieferkette im Bereich Software- s geht. Deshalb macht er sich Sorgen darüber, wie sich viele Organisationen derzeit schützen.

„Wir versuchen, moderne Umgebungen auf fast dieselbe Weise zu sichern wie vor 20 Jahren, und dies führt zu einem völligen Missverständnis der Angriffsfläche“, warnt Selby. „Das ist etwas, was die Branche ändern muss – und zwar schnell“, fügt er hinzu.

Dieses Missverständnis ist größtenteils auf einen Mangel an Transparenz hinsichtlich der Sicherheitsrisiken von Software von Drittanbietern, Cloud-Software-Diensten und Open-Source-Software zurückzuführen. „Risiken durch Dritte, die auf Schwachstellen in der Lieferkette oder in Softwarekomponenten von Drittanbietern zurückzuführen sind, stellen nach wie vor einen wesentlichen Faktor bei extern verursachten Sicherheitsverletzungen dar“, warnte Sandy Carielli, Principal Analyst bei Forrester Research, kürzlich auf dem „ Security & Risk Forum 2021“ des Unternehmens. „Unternehmen haben wahrscheinlich mehr Drittanbieter in ihrem Ökosystem als je zuvor“, fügte sie hinzu.

Angriffe auf die Lieferketten von „ “-Software haben während der Pandemie stark zugenommen. Erst im vergangenen Sommer wies das Tool von Atlassian für agiles Projektmanagement und die Nachverfolgung von Softwarefehlern eine „Ein-Klick“-Sicherheitslücke auf, die es einem Hacker ermöglichte, in das agile Planungssystem oder das Code-Repository einzudringen – wodurch es möglich wurde, Exploits in die Codebasis eines ahnungslosen Nutzers einzuschleusen.

Wie Chris Condo, Sicherheitsanalyst bei Forrester, auf dem Sicherheits- und Risikoforum des Unternehmens erklärte: „Sie würden gar nicht bemerken, dass sich jemand angemeldet und Ihre Software verändert hat.“ „Das sind die Probleme, mit denen wir tagtäglich konfrontiert sind.“

Angriffe auf die Lieferkette (von denen nicht alle öffentlich bekannt gegeben werden) haben sich nach Angaben der Agentur der Europäischen Union für Cybersicherheit (ENISA) im Jahr 2021 gegenüber 2020 voraussichtlich vervierfacht. Die ENISA stellt fest, dass bei 66 % dieser Angriffe die Angreifer zunächst die Codebasis des Lieferanten ins Visier nahmen, um ihre Angriffe auf das eigentliche Ziel auszuweiten.
Da sich Angreifer zunehmend auf Angriffe im Stil von Lieferkettenangriffen konzentrieren, müssen Unternehmen verstehen, wie sie sich besser schützen können. Betrachten Sie dies als den ersten Schritt in jedem risikobasierten Schwachstellenmanagement.
 

Passen Sie Ihre Taktik an, um den sich wandelnden Angriffen entgegenzuwirken

Angriffe auf die Lieferkette nehmen zu, da sie große Unternehmen treffen können, die ihre Vorgehensweise zur Minderung von Risiken im Zusammenhang mit Unternehmenstechnologie und Drittanbietern seit Jahrzehnten nicht geändert haben. „Unternehmen haben nicht mit der Art und Weise Schritt gehalten, wie moderne Unternehmen Technologie erwerben, entwickeln und verwalten“, sagt Selby, Co-Moderator des Podcasts „ : Tech Debt Burndown“ (,  ), der kürzlich Paxos verlassen hat, um zum Cybersicherheits-Forschungs- und Beratungsunternehmen Trail of Bits zu wechseln. „Wir führen nach wie vor Due-Diligence-Prüfungen durch Dritte auf der Grundlage von Tabellenkalkulationen durch, die im Jahr ’90s von Wirtschaftsprüfern erstellt wurden.“

„. Organisationen haben wahrscheinlich mehr Drittanbieter in ihrem Ökosystem als je zuvor.“

Diese Vorgehensweisen bewahrheiteten sich zu einer Zeit, als das größte Sicherheitsrisiko durch Sicherheitsverletzungen bei Drittanbietern in der Offenlegung vertraulicher Daten oder dem Ausfall von Diensten bestand. Allerdings schneiden sie nicht gut ab, wenn es um Risiken durch Dritte geht, die auf einen direkten Angriff abzielen, um Ihr Unternehmen mit Ransomware lahmzulegen oder zu blockieren. Eine risikobasierte Strategie zum Schwachstellenmanagement muss dies berücksichtigen.
So funktionieren Angriffe auf die Lieferkette. Anstatt Organisationen direkt ins Visier zu nehmen, richten Cyberkriminelle und staatlich gestützte Hacker ihre Angriffe auf Softwarehersteller und Anbieter von Software-Dienstleistungen. Sie schleusen Schadcode in Software ein, die anschließend von anderen Organisationen genutzt wird. Diese Angreifer zielen gezielt auf anfällige Softwareentwicklungs-Pipelines und unsichere Cloud-Konfigurationen ab oder nutzen Software-Update-Prozesse aus.
Nach dem verheerenden SolarWinds-Hack haben Bundesbeamte versucht, Behörden und Organisationen der Privatwirtschaft dabei zu unterstützen, Risiken in der Software -Lieferkette besser zu bewältigen. Im Rahmen der „ Mai 2021“ erließ Präsident Biden die Exekutivverordnung „ “ zur Verbesserung der Cybersicherheit der Nation (), wonach Anbieter, die Software an die Bundesregierung liefern, für alle in ihren Produkten enthaltenen Komponenten eine Software-Stückliste (SBOM) beifügen müssen.
 

[Lesen Sie auch: Was die Verordnung von Präsident Biden für Führungskräfte der Technologiebranche bedeutet]

Eine SBOM ist so etwas wie eine Aufstellung der Komponenten und Abhängigkeiten innerhalb einer Softwareanwendung oder eines Softwarepakets, einschließlich proprietären und Open-Source-Codes.

„Die Durchführungsverordnung sieht einige beispiellose Maßnahmen vor“, erklärte Alla Valente, Senior Research Analyst bei Forrester, vor den Teilnehmern des Sicherheits- und Risikoforums des Unternehmens. Auch wenn es sich dabei weder um ein Allheilmittel noch um einen Ersatz für gute Praktiken der Cyberhygiene handelt, hat die Verordnung die Bemühungen um die Sicherheit der Lieferkette beschleunigt.

Allan Friedman stimmt dem zu. Als Befürworter von SBOMs bei der Cybersecurity and Infrastructure Security Agency (CISA) erklärte Friedman kürzlich bei einer CISO-Podiumsdiskussion von SecurityWeek zum Thema „ “ (Transparenz in der Lieferkette) unter dem Titel „“: „Einer der Aspekte, die mir besonders am Herzen liegen, ist eine bessere Analyse und Überwachung der Lieferkette.“

Eine Fahrbahnschwelle anlegen

Die Überprüfung von externen Cloud- und Softwareanbietern beginnt mit der Ermittlung ihres Sicherheitsreifegrades. Bevor Selby eine Zusammenarbeit mit einem Softwareanbieter eingeht, führt er zunächst einen einfachen, unkomplizierten Test durch, der darauf abzielt, Anbieter mit unausgereiften Sicherheitsprogrammen auszusortieren.

„Bei Paxos haben wir einen Fragebogen mit 10 Fragen als Vorabbewertung verwendet, und dieser ist von größter Bedeutung. „Wir haben dies als eine Art ‚Geschwindigkeitsbegrenzung‘ eingeführt, nicht als unsere abschließende Sicherheits- oder Compliance-Bewertung“, sagt er.

„Wenn [Ihr Sicherheitsleiter] der Vizepräsident für Technik ist, dann haben Sie kein Sicherheitsprogramm.“
Nick Selby, ehemaliger CSO bei Paxos

Zu den einleitenden Fragen gehören: „Verfügen Sie über gedruckte und schriftlich festgehaltene Sicherheitsrichtlinien und -verfahren? Darf ich sie sehen? Erzählen Sie mir bitte etwas über Ihr Trainingsprogramm. Gibt es in Ihrem Unternehmen eine namentlich benannte Führungskraft, deren alleinige Aufgabe die Informationssicherheit ist?

„Wenn ja, und es handelt sich dabei um den Vizepräsidenten für Technik“, sagt Selby, „dann verfügen Sie über kein Sicherheitsprogramm.“ „Ich möchte hören: ‚Ja, ich habe einen Sicherheitsleiter, einen Leiter für Informationssicherheit und einen Direktor für Informationssicherheit‘ – jemanden, der in der Verantwortung steht und für die Gewährleistung der Sicherheit rechenschaftspflichtig ist.“
Ein wesentlicher Bestandteil jeder Sicherheitsbewertung von „ “-Software sollte auch die Überprüfung von Code durch Dritte umfassen. Selby rät Unternehmen, die sich mit Software für die Lieferkette befassen, sich darauf zu konzentrieren, die Softwareentwicklung des Anbieters und die Praktiken seines Entwicklerteams im Hinblick auf sichere Programmierung zu verstehen. „Nehmen Sie an einer Schulung zum Thema sicheres Programmieren teil, und was machen Sie dort?“ fragt Selby. „Erzählen Sie uns etwas über Ihr Trainingsprogramm.“
Das Bestehen einer Sicherheitsüberprüfung bedeutet nicht, dass der Anbieter den Auftrag erhält. Das bedeutet jedoch, dass sie die grundlegendste und entscheidende Prüfhürde genommen haben. „Wir wissen zumindest, dass wir darauf vertrauen können, dass sie unsere Anforderungen in Bezug auf Compliance, Sicherheit und Recht erfüllen werden“, sagt Selby.

„Und genau das sollten Unternehmen meiner Meinung nach tun: die Sicherheitsabteilung frühzeitig in die Onboarding-Prozesse für neue Lieferanten einbeziehen. „Leider beziehen Unternehmen das Thema Sicherheit nach wie vor erst ganz am Ende mit ein.“

Open Source ist kostenlos, aber nicht risikofrei

Eine angemessene Sicherheit der Lieferkette erfordert zudem, dass ermittelt und verstanden wird, welche lokalen und Cloud-basierten Softwaredienste sowie Softwareprogramme in der Netzwerkumgebung ausgeführt werden. „Das ist eine komplexere Herausforderung, als es auf den ersten Blick erscheinen mag“, sagt Selby.

Durch den Einsatz von Open-Source-Komponenten wird dies zu einer noch größeren Herausforderung. „Da Unternehmen Open-Source-Software zur Entwicklung von Anwendungen nutzen oder diese in kommerziell erhältlicher Software einsetzen, die selbst bis zu 90 % Open-Source-Code enthält, führen sie damit ein beängstigendes Maß an Risiken durch Drittanbieter in ihre Umgebung ein“, erklärte Valente auf dem Sicherheits- und Risikoforum.

„: Im Handel erhältliche Software enthält bis zu 90 % Open-Source-Code, was ein beängstigendes Maß an Risiken durch Drittanbieter mit sich bringt.“

Um die Risiken im Zusammenhang mit Open-Source-Software zu bewältigen, müssen Sicherheitsteams den Quellcode der Software eingehend prüfen. Das bedeutet nicht, dass man lediglich auf bekannte Sicherheitslücken prüfen und davon ausgehen sollte, dass Entwarnung gegeben ist, wenn alle -Patches auf dem neuesten Stand sind.

„Meistens läuft es genau so ab“, sagt Selby im Rahmen einer Überprüfung des Sicherheitsteams. „Sie prüfen das Open-Source-Projekt auf CVEs [Common Vulnerabilities and Exposures] und wenn keine kritischen Sicherheitslücken vorliegen, erachten sie es als unbedenklich.“ „Das ist doch verrückt.“
Stattdessen müssen Sicherheitsteams alle Komponenten und Softwareabhängigkeiten innerhalb eines Open-Source-Projekts betrachten und nachvollziehen, wie die verschiedenen Komponenten auf Sicherheitslücken geprüft und getestet wurden.

„Open Source bedeutet, dass der Quellcode offen zugänglich ist, sodass Sie ihn nutzen, prüfen und verbessern können“, sagt Selby. „Open Source bedeutet nicht: ‚Entweder so oder gar nicht‘.“

Sicherheit in der Software-Lieferkette in der Praxis

Während die Verordnung von Präsident Biden neue Anforderungen an Bundesbehörden zur Verbesserung ihrer Sicherheitsprogramme vorsieht – wie beispielsweise die Einführung von „ “ im Rahmen des „Zero-Trust“-s, die Verbesserung der Cloud-Sicherheitsstrategien unter sowie die Einführung von SBOMs –, arbeitet das National Institute of Standards and Technology (NIST) daran, diese Instrumente in die Praxis umzusetzen.

“Stop using the same spreadsheets that procurement weasels have used since the ’90s.”
Nick Selby

Im Rahmen eines kürzlich abgehaltenen Workshops hat das NIST die Aktualisierungen seiner Sonderveröffentlichung „ “ (SP 800-218) mit dem Titel „“ geprüft. Das Dokument wurde im Rahmen von „ September 2021“ veröffentlicht und beschreibt eine Reihe zentraler, hochgradig sicherer Praktiken der Softwareentwicklung, die Unternehmen in ihre Softwareentwicklungszyklen integrieren können. Die endgültigen Richtlinien zur Verwendung von SBOMs sollen unter Februar 2022 veröffentlicht werden.
Unterdessen hat die National Telecommunications and Information Administration (NTIA) kürzlich die Mindestanforderungen an die in SBOMs enthaltenen Elemente festgelegt. Dazu sollten der Name des Softwareherstellers, Angaben zur Softwareversion, eindeutige Identifikationsmerkmale für Softwarekomponenten, eine Auflistung der Abhängigkeiten zwischen den Komponenten sowie eine Aufzeichnung darüber gehören, wer die SBOM erstellt hat und wann dies geschehen ist. Die NTIA hat drei offene Standards für den Austausch von SBOM-Informationen anerkannt: SPDX, CycloneDX und SWID.
Analysten zufolge unterscheiden sich die drei Standards voneinander. Während SWID darauf ausgelegt ist, Softwarelizenzen und kommerzielle Nutzungsrechte zu erfassen, deckt SPDX Lizenzen, Softwarekomponenten, Sicherheitsinformationen und weitere Metadaten ab. Gleichzeitig ist der CycloneDX-Standard auf Softwaresicherheit ausgerichtet.
“„CycloneDX wurde speziell für eine Reihe von Anwendungsfällen im Bereich der Cybersicherheit entwickelt, die weit über die von der NTIA veröffentlichten Mindestanforderungen hinausgehen“, erklärte Steve Springett kürzlich bei der CISO-Podiumsdiskussion von SecurityWeek. Herr Springett ist Vorsitzender des „CycloneDX SBOM Standard“, einer Arbeitsgruppe des Open Web Application Security Project (OWASP), einer Online-Community, die kostenlose Artikel, Methoden, Dokumentationen, Tools und Technologien für die Sicherheit von Webanwendungen bereitstellt.
 

[Lesen Sie auch: Ist Ihre Behörde auf das Ende des Lebenszyklus von Software vorbereitet?]

Da sich die Standards ständig weiterentwickeln, müssen sich Unternehmen, die ihre Softwareentwicklung sicherer gestalten möchten, mit den derzeit verfügbaren Mitteln begnügen. Diese Prozesse lassen sich nicht ohne Weiteres umsetzen, und die entsprechenden Hilfsmittel entwickeln sich ständig weiter.

Dennoch ist es für Unternehmen unerlässlich, mit der Absicherung ihrer Software-Lieferkette zu beginnen. „Unternehmen sollten sich damit befassen, wie sie ihre vorhandene Software optimal nutzen können, sei es eine GRC-Plattform oder eine Plattform zur Risikobewertung von Drittanbietern“, erklärte Valente den Teilnehmern des Forums.

Zwar beginnt die Sicherheit der Software-Lieferkette mit einer gründlichen Überprüfung der Sicherheitsprozesse und eines sicheren Softwareentwicklungszyklus, doch werden Cyberkriminelle und Staaten weiterhin Angriffe auf Dienstleister starten und diese dann als Sprungbrett nutzen, um Kunden anzugreifen. Jene Kunden, die über die besten allgemeinen Sicherheitsmaßnahmen verfügen, werden bei der Gewährleistung der Sicherheit in ihren Organisationen erfolgreicher sein.

[Lesen Sie auch: Neue Umfrage – IT-Sicherheitsexperten mangelt es an Transparenz und Schnelligkeit für ein effektives Bedrohungsmanagement]

Dies setzt voraus, dass Sie die in Ihrem Unternehmen eingesetzte Software kennen und diese stets auf dem neuesten Stand halten, ein solides Konfigurationsmanagement gewährleisten sowie über effektive Überwachungsmaßnahmen und sowie Fähigkeiten zur Reaktion auf Vorfälle verfügen.

Was Selby betrifft, so sagt er, dass es für Unternehmen derzeit zu den wichtigsten Maßnahmen gehört, sich so schnell wie möglich von den alten Methoden zur Steuerung von Risiken im Zusammenhang mit Drittanbietersoftware und der Lieferkette zu lösen.

“Stop using the same spreadsheets that procurement weasels have used since the ’90s,” he says. „Es ist an der Zeit, diese Fragen so umzuformulieren, dass der Schwerpunkt darauf liegt, wie diese Organisationen Risiken für ihre Umwelt bewältigen.“