Supply-Chain-Angriff

Unternehmen sichern ihre eigenen Systeme immer besser ab. Angreifer weichen deshalb auf einen leiseren Weg aus: Sie kompromittieren Software-Hersteller oder Dienstleister und lassen sich von dort mit gültigen Signaturen und legitimen Zugängen zu ihren eigentlichen Zielen tragen. Ein Supply-Chain-Angriff missbraucht damit das Wertvollste in jeder Geschäftsbeziehung: Vertrauen.

Was ist ein Supply-Chain-Angriff?

Ein Supply-Chain-Angriff (Lieferkettenangriff) richtet sich gegen ein Unternehmen über dessen Zulieferer. Statt die gut geschützte Zielorganisation direkt anzugreifen, kompromittiert der Angreifer ein schwächeres Glied in der Lieferkette und nutzt die bestehende Vertrauensbeziehung als Einfallstor: automatische Updates, signierten Code, Fernwartungszugänge oder Datenanbindungen.

Zwei Ausprägungen sind zu unterscheiden. Die Software-Lieferkette umfasst alles, woraus Anwendungen entstehen: Open-Source-Bibliotheken, Entwicklungswerkzeuge, Build-Systeme und Update-Mechanismen. Wird hier Schadcode eingeschleust, verteilt er sich über reguläre Releases an alle Kunden. Die Dienstleister-Lieferkette betrifft Firmen mit Zugang zu Systemen oder Daten: IT-Dienstleister, Wartungsfirmen, Cloud-Anbieter oder Zulieferer mit Netzkopplung. Hier wird ein legitimer Zugang zum Angriffsweg.

Transparenz beginnt bei der Inventur: Eine SBOM (Software Bill of Materials) listet wie eine Stückliste auf, aus welchen Komponenten eine Software besteht. Wird in einer Bibliothek eine Schwachstelle bekannt, lässt sich mit SBOMs schnell klären, welche Produkte und Systeme betroffen sind. Gefordert werden solche Stücklisten zunehmend auch regulatorisch, etwa im europäischen Cyber Resilience Act für Hersteller vernetzter Produkte. Für Einkauf und Betrieb wird die SBOM damit zum normalen Bestandteil von Ausschreibungen und Vertragsanhängen.

So läuft ein Angriff ab

Die meisten Fälle folgen einem wiederkehrenden Muster:

  • Einbruch beim Zulieferer: Der Angreifer kompromittiert einen Software-Hersteller oder Dienstleister, häufig über gestohlene Zugangsdaten oder Schwachstellen in dessen Infrastruktur.
  • Manipulation des Produkts: In Build-Systeme, Update-Server oder Code-Pakete wird Schadcode eingeschleust. Trägt er die gültige Signatur des Herstellers, wirkt er für Prüfmechanismen vertrauenswürdig.
  • Verteilung über legitime Kanäle: Die Kunden installieren das manipulierte Update oder Paket im regulären Betrieb. Klassische Schutzmaßnahmen schlagen selten an, weil Quelle und Signatur stimmen.
  • Selektive Aktivierung: Die eingebaute Hintertür meldet sich beim Angreifer. Der wählt aus den betroffenen Organisationen die lohnenden Ziele aus und beginnt dort mit Ausbreitung und Datenabfluss.
  • Weg über Dienstleisterzugänge: Alternativ missbraucht der Angreifer Fernwartungszugänge oder stehende Netzkopplungen eines kompromittierten Dienstleisters und steht damit direkt im Kundennetz.

Auffällig ist die Geduld dieser Angriffe: Zwischen dem Einbruch beim Zulieferer und der Aktivierung beim Endziel können Monate liegen. Eine einmalige Sicherheitsprüfung des Lieferanten reicht deshalb selten aus. Entscheidend ist der laufende Blick darauf, was dessen Software und Zugänge im eigenen Netzwerk tatsächlich tun und mit wem sie kommunizieren.

Warum Schutz vor Supply-Chain-Angriffen wichtig ist

  • Ein einziger kompromittierter Zulieferer kann viele Organisationen gleichzeitig treffen, die Auswahl der Opfer trifft der Angreifer nachgelagert.
  • Der Schadcode kommt aus vertrauenswürdiger Quelle und passiert damit Kontrollen, die auf externe Angriffe ausgelegt sind.
  • Moderne Anwendungen bestehen zu großen Teilen aus Fremdkomponenten, deren Herkunft und Pflegezustand selten vollständig bekannt sind.
  • Fernwartungs- und Dienstleisterzugänge führen oft tief in interne Netze und werden seltener überwacht als externe Zugänge.
  • Die NIS-2-Richtlinie verpflichtet betroffene Unternehmen ausdrücklich, Risiken in der Lieferkette zu bewerten und zu behandeln, Details erklärt unser Glossarartikel zu NIS-2 .
  • Auch vertraglich wächst der Druck, weil Kunden Sicherheitsanforderungen zunehmend an ihre Lieferanten weiterreichen.

Typische Szenarien

  • Ein manipuliertes Update einer verbreiteten IT-Management-Software installiert eine Hintertür bei allen Kunden, ausgenutzt wird sie bei ausgewählten Zielen.
  • Ein beliebtes Open-Source-Paket wechselt den Betreuer, kurz darauf enthält eine neue Version Code, der Zugangsdaten ausleitet.
  • Angreifer übernehmen die Fernwartungssoftware eines IT-Dienstleisters und verschlüsseln anschließend die Systeme von dessen Kunden.
  • Über die Netzkopplung eines Logistikpartners gelangen Angreifer in das Produktionsnetz eines Herstellers.
  • Eine kompromittierte Build-Pipeline signiert Schadcode mit dem offiziellen Zertifikat des Herstellers.

Supply-Chain-Angriff vs. direkter Angriff

Beim direkten Angriff sucht der Angreifer Schwachstellen in der Infrastruktur des Ziels, etwa exponierte Dienste oder ungepatchte Systeme. Dagegen helfen Perimeterschutz, Patching und eigene Härtung. Der Supply-Chain-Angriff umgeht diese Verteidigung, weil er über einen Kanal kommt, dem das Ziel technisch und organisatorisch vertraut. Für die Verteidigung heißt das: Prävention an der Außengrenze reicht nicht aus. Es braucht Transparenz über Abhängigkeiten und minimale Rechte für Dritte, dazu eine Architektur, die den Schaden begrenzt, wenn vertrauenswürdige Software oder Partner kompromittiert sind.

Schutz vor Supply-Chain-Angriffen bei KAEMI

Vollständig verhindern lässt sich die Kompromittierung eines Zulieferers von außen nicht. Umso wichtiger ist eine Architektur, die den Wirkradius begrenzt. Mit Zero Trust Mikrosegmentierung isoliert KAEMI Systeme und Dienstleisterzugänge so, dass eine Hintertür in einer einzelnen Software keinen Weg durch das gesamte Netzwerk öffnet: Jede Verbindung braucht eine explizite Freigabe, Wartungszugriffe bleiben auf das Nötigste beschränkt. Ergänzend stellt SASE/SSE sicher, dass externe Partner definierte Anwendungen erreichen statt ganzer Netzsegmente. So bleibt ein Lieferkettenvorfall ein begrenztes Ereignis statt eines Totalausfalls.

Häufige Fragen zu Supply-Chain-Angriff

Was ist eine SBOM und wozu brauche ich sie?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste, die alle Komponenten einer Software samt Version auflistet, inklusive Open-Source-Bibliotheken. Wird eine Schwachstelle in einer Komponente bekannt, zeigt die SBOM sofort, welche Anwendungen betroffen sind. Ohne diese Transparenz dauert die Betroffenheitsanalyse nach einem Vorfall oft Tage. Zunehmend verlangen Kunden und Regulierer SBOMs von Herstellern.

Worin unterscheiden sich Software- und Dienstleister-Lieferkette?

Die Software-Lieferkette betrifft den Code selbst: Bibliotheken, Build-Systeme und Update-Wege, über die Schadcode in Produkte gelangt und sich an alle Kunden verteilt. Die Dienstleister-Lieferkette betrifft Zugänge: IT-Dienstleister, Wartungsfirmen oder Partner mit Netzkopplung, deren legitime Verbindungen Angreifer übernehmen. Beide Wege umgehen den Perimeter, verlangen aber unterschiedliche Gegenmaßnahmen, von SBOM und Update-Kontrolle bis zu streng begrenzten Fernzugängen.

Was verlangt NIS-2 beim Thema Lieferkette?

NIS-2 verpflichtet betroffene Unternehmen, die Sicherheit ihrer Lieferkette aktiv zu managen. Dazu gehören die Bewertung der Sicherheitsniveaus direkter Zulieferer und Dienstleister, vertragliche Sicherheitsanforderungen sowie die Berücksichtigung von Schwachstellen einzelner Anbieter im eigenen Risikomanagement. Die Pflicht wirkt in die Breite: Auch Firmen, die selbst gar nicht unter NIS-2 fallen, bekommen die Anforderungen von ihren Kunden weitergereicht.

Wie erkenne ich, ob mein Unternehmen von einem bekannt gewordenen Lieferkettenvorfall betroffen ist?

Grundlage ist ein aktuelles Inventar: Welche Software, Versionen und Dienstleisterzugänge sind im Einsatz? SBOMs beschleunigen den Abgleich mit Herstellerangaben erheblich. Prüfen Sie anschließend die Advisories des Herstellers und einschlägige Warnungen, etwa des BSI, und suchen Sie in Protokollen nach den veröffentlichten Kompromittierungsindikatoren. Ohne Inventar bleibt eine aufwendige manuelle Suche, während das Zeitfenster für Angreifer offen steht.

Welche Maßnahmen begrenzen den Schaden eines Supply-Chain-Angriffs?

Gehen Sie davon aus, dass einzelne Komponenten oder Partner kompromittiert werden können, und begrenzen Sie die Folgen: Netzwerksegmentierung hält betroffene Systeme isoliert, Dienstleisterzugänge erhalten minimale Rechte über kontrollierte Übergänge, Updates werden gestaffelt ausgerollt statt überall gleichzeitig. Ergänzend helfen Monitoring auf ungewöhnliche Verbindungen und geübte Notfallprozesse, damit die Trennung betroffener Systeme schnell gelingt.

Offene Fragen dazu in Ihrer Umgebung? KAEMI berät Sie anforderungsorientiert und übernimmt auf Wunsch auch den Betrieb.