Kettenreaktionen : Supply-Chain-Attacken – Bedrohung und Abwehr

Von Marko Klaus, Berlin

Durch die zunehmende Verwendung von Cloud-Services und die damit verbundene Auslagerung von IT-Prozessen ist in den letzten Jahren ein stetiger Anstieg von Supply-Chain-Angriffen zu verzeichnen. Verstärkt wird dieser Trend durch eine steigende Reife der Informations- und IT-Sicherheit in großen Unternehmen und Behörden: Deren zunehmende Security-Ertüchtigung treibt die Angriffskosten in die Höhe – direkt an dieser Stelle anzusetzen bedeutet mehr Aufwand, um Netzwerke und Systeme zu kompromittieren. Ein Gegenstrategie der Angreifer ist die Fokussierung auf Zulieferer.

Eine Supply-Chain-Attacke richtet sich dabei auf die IT-Systeme und zugehörigen Prozesse (bzw. deren Schwachstellen) in der Lieferkette einer Organisation oder Behörde, um letztlich in deren Netze einzudringen und dort möglichst lange unerkannt zu Verweilen. Gleichzeitig wird mit diesem Vorgehen die Attribution, quasi als Nebeneffekt, erschwert.

Akteure und Ziele

Angreifer sind bei Supply-Chain-Attacken eher im Umfeld cyberkrimineller oder gar staatlicher Organisationen zu finden. Für die Unterscheidung und Einschätzung der eigenen Gefährdungslage ist es hilfreich, grundlegend zwischen unterschiedlichen Opfertypen zu unterscheiden.

Besonders im Fokus stehen Unternehmen und Behörden mit besonderer Relevanz. Das BSI meint damit Organisationen, die vertrauliche und geschäftskritische Informationen mit ihrer IT verarbeiten oder aber Geschäfts- und Betriebsgeheimnisse schützen müssen. Hierbei geht es nicht nur um Großunternehmen, sondern auch KMUs und „Hidden Champions“ (vgl. www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Gefaehrdungen/APT/apt_node.html).

Mögliche Opfer für Supply-Chain-Angriffe lassen sich einerseits nach unmittelbar oder mittelbar ausgewählten Organisationen differenzieren (vgl. Abb. 1):

• Primärziele sind Auftraggeber / Einkaufende (im Sinne der Lieferkette): Das Primärziel verfügt beispielsweise im Regelfall über höhere Standards oder einen höheren Reifegrad bei der Absicherung seiner Systeme.
• Sekundärziele sind Zulieferer: Cyberkriminelle wählen sie, wie bereits angesprochen, häufig als Einstiegspunkt, um mit weniger Aufwand Sicherungen des Primärziels zu umgehen.

Eine weitere Charakterisierung der Angriffsart lässt sich durch die Unterscheidung opportunistischer und gezielter Angriffe vornehmen: Opportunistische Angriffe zielen nicht unbedingt auf die eigene, zu verteidigende Organisation oder das zu verteidigende Unternehmen – vielmehr handelt es sich für den Angreifer um „Beifang“. Hier können einfache Maßnahmen helfen, es den Angreifern zu erschweren erfolgreich zu sein. Die Verteidigung gegen gezielte Angriffe ist schwieriger, da hierbei die Persistenz und Richtung des Angreifers auch nach Misserfolgen während der Aufklärung des Ziels (Reconnaissance) erhalten bleibt. Tabelle 1 thematisiert die Beziehung zwischen Angriffsarten aus Sicht der verteidigenden Organisation und liefert damit Ansätze für eine erste risikobasierte Einschätzung der eigenen Gefährdungslage.

Angriff

Supply-Chain-Attacken können über mehrere Ebenen wirken, da Produkte von Zulieferern wiederum weitere externe Zulieferer mit einschließen können. Gut ersichtlich wird dies anhand der Solarwinds-Attacken oder des „Codecov“-Vorfalls, bei dem unter anderem auch die namhafte Firma Hashicorp betroffen war, die eine Reihe von Open-Source-Tools zur Entwicklung großer Service- und Cloud-orientierter Software-Installationen bereitstellt. Mithilfe entsprechender Modelle können sich Organisationen auf diese Art von Angriffen einstellen und ihre Gegenmaßnahmen koordinieren. Die nachfolgende Liste zeigt stark vereinfacht und beispielhaft das Vorgehen eines Angriffs über die Kompromittierung einer legitimen Updatefunktion (nach [1], erweitert um die vorbereitenden Aktionen des Angreifers):

• Zielauswahl und erste Schritte: Reconnaissance bezüglich der Lieferketten durch den Angreifer, Reconnaissance und Kompromittierung des Sekundärziels durch den Angreifer sowie laterale Ausbreitung und gezielte Suche zum Platzieren von Schadsoftware in Produkten, die für das Primärziel relevant sind.
• Kompromittierung des Quelltextes beim Zulieferer
• Download der manipulierten Updates durch den legitimen Update-Prozess beim Opfer
• Ausführung des kompromittierten Updates
• Etablieren eines Command-and-Control-(C2)-Kanals
• Weitere Kommunikation zum Nachladen neuer Schadsoftware und/oder Befehle über den C2-Kanal

Vorsorge und Abwehr

Um sich gegen Supply-Chain-Angriffe zu wappnen, sollte man einen ganzheitlichen Ansatz aus vorbeugenden und reaktiven Mechanismen wählen, der sowohl organisatorische als auch technische Maßnahmen umfasst, wie sie im Folgenden schlagwortartig skizziert sind.

Organisatorische Maßnahmen

• Vertragliche Vereinbarungen: Die Informations- und IT-Sicherheit muss vertraglich berücksichtigt werden. Fachpersonal, beispielsweise eines überwachenden Security-Operation-Centers (SOC) und auch der Abteilung für Informationssicherheit, sollte spezifische Anforderungen in die Vertragsverhandlungen mit einbringen und diese gemeinsam mit dem Einkauf prüfen. Zusätzliche Zertifizierungen (z. B. SOC2 Type II oder das Vorliegen eines C5-Testates) sollten vertraglich vorgeschrieben und geprüft werden – Gleiches gilt für verpflichtende Audits der Informationssicherheit beim Zulieferer. Obligatorische gemeinsame Workshops zwischen den IT- und Informations-Sicherheits-Abteilungen von Zulieferer und Auftraggeber etablieren darüber hinaus notwendige Prozesse zur Begegnung von Sicherheitsvorfällen. Wenn möglich sollte man eine initiale Prüfung des verwendeten Sourcecodes für alle zugelieferten Produkte vorsehen sowie Backgroundchecks der Mitarbeiter beim Zulieferer einfordern (vgl. [2,3]). Überdies hilft eine verpflichtende Offenlegung von Zulieferlisten des Zulieferers bei der Risikoanalyse zu Produkten und Diensten weiterer Dritter.

Asset-Management: Nur das Schaffen und Pflegen eines Inventars aller benutzten Hard- und Software liefert der Security die notwendige Sichtbarkeit (vgl. [4]). Für die Planung von Gegenmaßnahmen ist es zwingend notwendig, zu wissen, welche Komponenten durch ein Zulieferer verwendet.

• End of Life: Produkte, die abgekündigt und nicht mehr durch Support abgedeckt werden können, sollten – soweit möglich – nicht mehr benutzt werden.
• Risikomanagement: Für ein umfassendes Risikomanagement unter Einbeziehung einer Analyse der Kritikalität von Ausfällen liefern Business-Impact-Analysen (BIA) erste Ansätze. Dabei ist auch zu klären, welche Zulieferfunktionen bedient und welche Abnehmerfunktionen durch eine eingekaufte Lösung realisiert werden. Weitere exemplarische Fragen lauten: Werden kritische und sensitive Daten verarbeitet? Wie ist der Zugriff geregelt? Gibt es Notwendigkeiten des Supportzugriffs auf die eigene Infrastruktur? Darüber hinaus hilft ein regelmäßiger Review der Kritikalität jedes Zulieferers dabei, nicht mehr benötigte Komponenten zu identifizieren und diese gegebenenfalls durch andere Produkte abzulösen.
• Sicherer Entwicklungsprozess: Entwicklungsabteilungen von Zulieferern müssen Secure-Software-Development-Ansätze verwenden. Schwachstellenscans sind vor Inbetriebnahme der Gesamtlösung verpflichtend durchzuführen. Weitere Ansätze, die zwingend gefordert und implementiert werden sollten, sind das kontinuierliche Testen, das sogenannte Test-Driven-Development (TDD) sowie Test-Driven-Security (TDS), also eine Sicherheit, die ebenfalls durch Testen vorangebracht wird. Hilfreich sind auch obligatorische Awareness-Maßnahmen für Entwickler – dabei kann beispielsweise die Verwendung des „OWASP Security Knowledge Framework“ (https://owasp.org/www-project-security-knowledge-framework/) und/oder des OWASP Teammentor behilflich sein (https://github.com/TeamMentor).
• Incident-Management-Prozess: Zulieferer müssen prozessuale Schnittstellen zum Abnehmer herstellen und entsprechende Pläne gemeinsam mit den Vertragspartnern etablieren. Die zugehörigen Reporting-Pflichten sollte man ebenfalls gemeinsam ausarbeiten. Des Weiteren müssen Zulieferer den Abnehmer bei einem erfolgreichen Angriff informieren. Die Incident-Response-Prozesse der Partner sollten synchronisiert werden. Die Ausarbeitung von gemeinsamen Incident-Response-Playbooks ist wesentlicher Bestandteil einer gemeinsamen Strategie, um Angreifer gegebenenfalls wieder aus den eigenen Netzen zu drängen.

Technische Maßnahmen

Allem voran steht die Umsetzung passender Standards. Beispielsweise adressieren die ISO 28000 „Spezifikationen für Sicherheitsmanagementsysteme für die Lieferketten“ oder der „Trusted Information Security Assessment Exchange“ (TISAX) direkt die Lieferkette. Auch die Etablierung eines Informationssicherheitsmanagementsystems (ISMS) auf Basis von ISO 27001 und 27002 aufseiten der Zulieferer erhöht das gemeinsame Security-Level und somit auch die allfälligen Kosten für Angreifer. Die folgende Aufzählung listet zudem exemplarisch einige Maßnahmen-Pakete für die Absicherung der CI/CD-Chain (Continuous Integration / Continuous Deployment):

• Nutzung von Security-Frameworks in der Entwicklung: beispielsweise Apache Shiro oder Spring Security
• Abhängigkeitsüberprüfungen von Software-Projekten, die zum Beispiel Open-Source-Produkte verwenden, mittels Services wie „Open Source Insights“ von Google (https://deps.dev) oder aber der OWASP Dependency Check (https://owasp.org/www-project-dependency-check/).
• Software-Management-Tools, wie Repository- und Versionierungs-Tools, müssen abgesichert und mittels Least-Privilige-Prinzip administriert werden.
• Logging-Pipelines aufbauen und die CI/CD-Quellen an das verwendete SIEM koppeln: Das Anschließen von Suppliers an das Monitoring kann beispielsweise über Apache Kafka, Rabbit MQ oder AWS Kinesis erfolgen. Für die Lösung sollten auch entsprechende Threat-Intelligence-Feeds zum Einsatz kommen – basierend auf den verwendeten Software-Modulen (z. B. über die „Malware Information Sharing Platform“ – MISP, https://misp-project.org).
• Automatische Schwachstellen-Scans im Rahmen der Entwicklungspipeline verhindern das einfache Einschleusen bekannter Schwachstellen. Flankieren lässt sich dies durch manuelle Tests via OpenVAS (www.openvas.org) oder für webbasierte Applikationen durch OWASP ZAP (www.zaproxy.org) und die BurpSuite (https://portswigger.net/burp/).
• Zentrale Absicherung des Deployments von Zertifikaten und Schlüsseln – beispielsweise durch Lösungen wie HashiCorp Vault (www.vaultproject.io).
• Toolgestützte sichere Konfiguration: etwa auf der Grundlage des CIS Security Benchmarks (www.cisecurity.org/cis-benchmarks/) oder aber des „Security Content Automation Protocol“ (SCAP, z. B. mittels OpenSCAP, www.open-scap.org).

Fazit

Um gut gegen Supply-Chain-Attacken gewappnet zu sein, sollte man die Betrachtung aus Angreifersicht und damit auch die Motivation der Angreifer mit einbeziehen (vgl. [1]). Wichtig für die Etablierung passender Gegenmaßnahmen ist das Verständnis der eigenen Infrastruktur und der Verknüpfung mit Produkten des Zulieferers (dabei sind sowohl prozessuale und organisatorische als auch technische Abhängigkeiten von großer Relevanz).

Für Maßnahmen im organisatorischen Bereich stehen vielseitige Ansätze und Standards zur Verfügung, die Werkzeuge und Methoden bereitstellen, um potenzielle Gefahren zu minimieren. Wichtig ist das sichere Einbetten des Zulieferers in den eigenen Sicherheitsprozess: Dies kann nur durch gemeinsame Kommunikation und durch gemeinsames Handeln von Zulieferer und Abnehmer auf Augenhöhe gelingen.

Auch auf technischer Seite gibt es eine Vielzahl an hilfreichen Werkzeugen. Die in diesem Beitrag betrachteten Tools bilden dabei nur einen kleinen Teil ab – letztlich muss sich jede Organisation hierbei an den aktuellen Use-Cases der bei ihr und ihren Zulieferern eingesetzten Produkte orientieren.

Technische Maßnahmen und die damit verbundenen Werkzeuge sollten immer darauf abzielen, Angreifern, die über Zulieferer die Sicherheit der Organisation kompromittieren wollen, den Zugang möglichst zu verwehren oder zumindest ein Weiterkommen im eigenen Netz deutlich zu erschweren.

Marko Klaus ist Projektleiter und Principal Consultant Informationssicherheit bei T-Systems MMS.

Literatur

[1] Marko Klaus, Andreas Lang, Enrico Weide, Dominik Weißhaar, AMD&IS, Angreifermodell für den Datenschutz und die IT-Sicherheit, <kes> 2021#2, S. 16
[2] Stephen Fedtke, Epische Macht, „Extremely Privileged IT Staff“ (EPIS) erfordert spezielle Zuverlässigkeits- oder
Sicherheitsüberprüfungen, <kes> 2010#6, S. 6
[3] Stephen Fedtke, EPIS 2.0: Fremde Fürsten, Anwendung des Transparency-Korruptionswahrnehmungsindex in der Risikoanalyse eines Outsourcings systemischer IT, <kes> 2012#2, S. 11
[4] Bettina Weßelmann, Johannes Wiele, Haie fischt man nicht im Trüben, Dauerbaustellen der Security (2), <kes> 2016#4, S. 26