Ihre eigene IT mag gut aufgestellt sein: gepatchte Systeme, Multi-Faktor-Authentifizierung, ein SOC, das Alarme bearbeitet. Doch der Wartungstechniker Ihres Maschinenherstellers wählt sich mit einem Passwort ein, das seit drei Jahren gilt. Der IT-Dienstleister verwaltet Ihre Server mit einem Konto, das auf allen seinen Kunden dieselben Rechte hat. Und das Update Ihrer Buchhaltungssoftware kommt von einem Server, den Sie nie gesehen haben. Angreifer wissen das – und nehmen zunehmend den Umweg über Dienstleister.
Laut Verizon Data Breach Investigations Report 2025 waren Drittparteien an 30 Prozent der untersuchten Sicherheitsverletzungen beteiligt, doppelt so viele wie im Vorjahr. Gleichzeitig verlangen das NIS2-Umsetzungsgesetz und DORA, dass Unternehmen die Sicherheit ihrer Lieferkette aktiv managen. Dieser Beitrag zeigt, welche Pflichten gelten, über welche Pfade Angreifer typischerweise über Dienstleister eindringen, wie ein Red Team Lieferantenzugänge prüft und welche Fragen Sie Ihren Dienstleistern stellen sollten.
Warum Dienstleister im Fokus stehen
Für Angreifer ist der Weg über einen Dienstleister aus drei Gründen attraktiv. Erstens ist er effizient: Wer einen IT-Dienstleister mit hundert Kunden kompromittiert, hat hundert potenzielle Ziele. Zweitens ist er leise: Zugriffe über legitime Fernwartungszugänge sehen in den Logs aus wie der normale Betrieb. Drittens umgeht er die Verteidigung: Viele Unternehmen härten ihren eigenen Perimeter, behandeln den Dienstleisterzugang aber als vertrauenswürdig und überwachen ihn kaum.
Ein Supply-Chain-Angriff ist daher nicht auf manipulierte Software beschränkt, auch wenn diese Fälle die Schlagzeilen bestimmen. In der Praxis sehen wir häufiger den unspektakulären Weg: ein gestohlenes oder erratenes Passwort eines Dienstleisterkontos, das direkt auf Server des Kunden führt. Der Verizon DBIR 2025 weist den Missbrauch von Zugangsdaten mit 22 Prozent als einen der häufigsten Erstzugriffswege aus – und Dienstleisterkonten sind dafür ein bevorzugtes Ziel, weil sie oft ohne MFA, mit langen Passwortlaufzeiten und weitreichenden Rechten betrieben werden.
Pflichten nach NIS2 und DORA
Zwei Regelwerke machen die Lieferkettensicherheit zur ausdrücklichen Pflicht.
Das NIS2-Umsetzungsgesetz, in Kraft seit dem 6. Dezember 2025, verlangt von den rund 29.500 betroffenen Einrichtungen Risikomanagementmaßnahmen, die ausdrücklich die Sicherheit der Lieferkette einschließen – einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu direkten Anbietern und Dienstleistern. Unternehmen müssen die Risiken bewerten, die von ihren Dienstleistern ausgehen, und geeignete Anforderungen vertraglich und organisatorisch durchsetzen. Welche Pflichten das Gesetz im Einzelnen vorsieht, fasst der Beitrag NIS2: Pflichten der Geschäftsleitung und Sicherheitstests zusammen.
DORA geht für Finanzunternehmen weiter. Die Verordnung regelt das Management des IKT-Drittparteienrisikos in einem eigenen Kapitel: Informationsregister aller IKT-Dienstleister, Mindestvertragsinhalte, Ausstiegsstrategien und eine EU-weite Überwachung kritischer IKT-Drittdienstleister. Für bedrohungsgeleitete Penetrationstests (TLPT) nach Art. 26 verlangt DORA ausdrücklich, dass kritische IKT-Dienstleister in den Test einbezogen werden, wenn sie Systeme betreiben, die kritische Funktionen unterstützen. Wie das organisatorisch gelingt – etwa über Pooled Testing mehrerer Institute bei demselben Dienstleister –, beschreibt der Beitrag DORA TLPT: Zeitplan, Rollen und Fristen.
Beiden Regelwerken gemeinsam ist der Grundsatz: Die Verantwortung für die Sicherheit lässt sich nicht auslagern. Wer einen Dienstleister beauftragt, bleibt für das Risiko verantwortlich und muss nachweisen können, dass er es kennt und steuert.
Typische Angriffspfade über Dienstleister
Aus unseren Red-Team-Einsätzen kennen wir die Pfade, über die ein Angriff auf das Unternehmen über einen Dienstleister verläuft. Die folgenden Szenarien sind typisiert und beschreiben keine konkreten Kunden.
| Angriffspfad | Typisches Szenario | Warum er funktioniert |
|---|---|---|
| VPN-Zugang des Dienstleisters | Ein Dienstleisterkonto mit VPN-Zugang wird per Password Spraying oder aus einem geleakten Datensatz übernommen; der Angreifer steht im internen Netz. | Kein MFA, kein Ablaufdatum, Zugang ins gesamte Netz statt in ein Segment. |
| Fernwartung von Maschinen und Anlagen | Ein Fernwartungsrouter des Anlagenherstellers ist aus dem Internet erreichbar; über ihn gelangt der Angreifer in das Produktionsnetz. | Vom Hersteller installiert, der IT unbekannt, nie gepatcht, keine Überwachung. |
| Administrationskonten des IT-Dienstleisters | Der Dienstleister nutzt für alle Kunden dasselbe lokale Administratorkonto oder dieselben Service-Accounts; ein Vorfall beim Dienstleister trifft alle Kunden. | Geteilte Zugangsdaten, keine kundenindividuelle Trennung. |
| Software-Updates | Der Update-Mechanismus einer Branchensoftware wird manipuliert; das Update installiert Schadcode mit den Rechten der Software. | Updates werden automatisch vertraut und selten geprüft. |
| Cloud- und SaaS-Integrationen | Ein Dienstleister hat über eine API-Anbindung oder eine delegierte Administration Zugriff auf den Mandanten; dessen Token wird gestohlen. | Weitreichende Berechtigungen für Integrationen, selten überprüft. |
| Phishing im Namen des Dienstleisters | Der Angreifer kompromittiert ein Postfach beim Dienstleister und schickt den Kunden eine täuschend echte Rechnung oder einen Login-Link. | Vertrauensverhältnis, bekannter Absender, erwarteter Kontext. |
| Physischer Zugang | Reinigungs-, Wartungs- oder Lieferpersonal hat Zutritt zu Räumen mit Netzwerkzugang; ein Angreifer gibt sich als solches aus. | Externe Personen werden seltener hinterfragt als Fremde ohne Rolle. |
Fast alle Pfade haben eines gemeinsam: Sie nutzen Zugänge, die absichtlich eingerichtet wurden und deshalb legitim wirken. Der Angriff ist kein Einbruch, sondern die Nutzung einer offenen Tür durch die falsche Person.
Wie Red Teams Lieferantenzugänge testen
Ein Red Teaming kann Dienstleisterzugänge auf zwei Arten einbeziehen. Welche passt, hängt von Scope, Vertragslage und Risikobereitschaft ab.
Szenario Assumed Breach über den Dienstleister. Wir gehen davon aus, dass ein Dienstleister kompromittiert ist, und starten mit dessen Zugang: einem VPN-Konto, einem Fernwartungszugang, einem Administrationskonto. Von dort prüfen wir, wie weit ein Angreifer kommt – ob der Zugang auf das Nötige beschränkt ist oder ins gesamte Netz führt, ob Lateral Movement möglich ist, ob die Nutzung des Zugangs außerhalb der üblichen Zeiten oder von ungewöhnlichen Orten auffällt. Dieses Szenario braucht keine Beteiligung des Dienstleisters, nur seine Zugangsart. Es ist der direkteste Weg, die Wirksamkeit von Netzwerksegmentierung und Least Privilege für Drittzugänge zu belegen. Mehr dazu im Beitrag Assumed Breach erklärt.
Szenario Angriff über den Dienstleister. Hier beginnt das Red Team außerhalb und versucht, über den Dienstleister einzudringen: durch OSINT zu seinen Mitarbeitenden und Zugängen, durch Phishing in seinem Namen, durch die Suche nach exponierten Fernwartungssystemen. Dieses Szenario ist realistischer, setzt aber voraus, dass der Dienstleister einbezogen wird: Angriffe auf seine Systeme brauchen seine schriftliche Autorisierung, sonst sind sie strafbar. In der Praxis beschränken wir uns deshalb oft auf das, was ohne Eingriff beim Dienstleister prüfbar ist – etwa die Frage, ob Ihre Mitarbeitenden eine Phishing-Mail im Namen des Dienstleisters erkennen und ob Ihre Systeme einen Zugriff vom Dienstleisterkonto zu ungewöhnlicher Zeit alarmieren.
In beiden Szenarien gehört die Detektion zum Ergebnis: Hat Ihr SOC bemerkt, dass ein Dienstleisterkonto Dinge tut, die es sonst nie tut? Diese Frage ist für die Lieferkette zentral, weil Sie die Systeme des Dienstleisters nicht kontrollieren – wohl aber, was sein Zugang in Ihrem Netz darf und ob Sie es sehen.
Praxis-Tipp: Lassen Sie sich vor dem Test eine vollständige Liste aller externen Zugänge geben – VPN-Konten, Fernwartungsgeräte, delegierte Cloud-Administrationen, API-Schlüssel. In fast jedem Projekt ist diese Liste unvollständig, und die fehlenden Einträge sind die interessantesten: Fernwartungsrouter, die der Anlagenhersteller vor Jahren installiert hat, oder Dienstleisterkonten, deren Vertrag längst beendet ist. Allein das Erstellen der Liste ist eine Sicherheitsmaßnahme.
Fragenkatalog für Lieferanten
Die folgenden Fragen stellen wir im Rahmen von Scoping und Risikoanalyse an Dienstleister mit Zugang zu Systemen unserer Kunden. Sie eignen sich als Grundlage für Ihre eigene Lieferantenbewertung nach NIS2 oder DORA. Entscheidend ist weniger die Antwort als der Nachweis dahinter.
- Welche Ihrer Mitarbeitenden haben Zugang zu unseren Systemen, und wie wird dieser Kreis dokumentiert und aktuell gehalten?
- Über welche technischen Wege greifen Sie auf unsere Systeme zu (VPN, Fernwartungsgerät, Jump-Host, Cloud-Delegation), und sind diese Wege uns vollständig bekannt?
- Ist jeder Zugang personalisiert, oder werden Konten zwischen Mitarbeitenden oder Kunden geteilt?
- Ist für jeden Zugang zu unseren Systemen Multi-Faktor-Authentifizierung aktiv, und welche Verfahren setzen Sie ein?
- Wie schnell entziehen Sie Zugänge, wenn Mitarbeitende Ihr Unternehmen verlassen oder das Projekt wechseln, und wie erfahren wir davon?
- Werden Zugriffe auf unsere Systeme bei Ihnen protokolliert, und stellen Sie uns die Protokolle auf Anfrage oder bei einem Vorfall zur Verfügung?
- Nutzen Sie für den Zugriff auf unsere Systeme dedizierte, gehärtete Arbeitsplätze, oder dieselben Geräte wie für E-Mail und Internet?
- Wie sichern Sie den Prozess für Software-Updates ab, die Sie uns bereitstellen (Signaturen, Prüfsummen, Trennung von Entwicklung und Auslieferung)?
- Wann wurde Ihr eigenes Unternehmen zuletzt einem Penetrationstest oder Red Teaming unterzogen, und können Sie uns eine Zusammenfassung der Ergebnisse und Maßnahmen vorlegen?
- Welche Zertifizierungen oder Nachweise (ISO 27001, BSI IT-Grundschutz, branchenspezifische Testate) halten Sie, und welchen Geltungsbereich haben sie?
- Innerhalb welcher Frist informieren Sie uns über einen Sicherheitsvorfall bei Ihnen, der unsere Systeme oder Daten betreffen könnte, und ist diese Frist vertraglich vereinbart?
- Welche Ihrer Unterauftragnehmer haben mittelbar Zugang zu unseren Systemen oder Daten, und gelten für sie dieselben Anforderungen?
- Stimmen Sie zu, dass Ihre Zugänge zu unseren Systemen Bestandteil unserer Sicherheitstests sind, und unter welchen Bedingungen dürfen wir Ihre Schnittstellen zu uns prüfen?
- Was passiert mit unseren Daten und Zugängen bei Vertragsende, und wie weisen Sie die Löschung nach?
Die Antworten gehören in Ihr Informationsregister beziehungsweise Ihre Lieferantenbewertung, die Anforderungen in den Vertrag. Frage 13 ist dabei die wichtigste für Ihre eigene Testplanung: Ohne ein vertraglich vereinbartes Prüfrecht bleibt der Dienstleisterzugang eine Blackbox.
Maßnahmen, die sich bewährt haben
Unabhängig vom Ergebnis eines Tests reduzieren wenige Maßnahmen das Drittparteienrisiko deutlich. Dienstleisterzugänge sollten zeitlich begrenzt und nur auf Anforderung freigeschaltet werden, statt dauerhaft offen zu stehen. Jeder externe Zugang gehört in ein eigenes Netzsegment mit Zugriff nur auf die Systeme, die der Dienstleister betreut. Konten externer Personen brauchen MFA ohne Ausnahme und eine Überwachung, die ungewöhnliche Zeiten, Orte und Aktionen alarmiert. Fernwartungsgeräte von Herstellern gehören in das Inventar der IT und hinter eine kontrollierte Einwahl. Und für die Reaktion gilt: Ein Vorfall beim Dienstleister ist ein Vorfall bei Ihnen – der Incident-Response-Plan muss den Fall abdecken, dass der Angreifer über einen vertrauenswürdigen Zugang gekommen ist.
Fazit
Dienstleister sind der Teil Ihrer Angriffsfläche, den Sie am wenigsten kontrollieren und am seltensten prüfen – und genau deshalb an 30 Prozent der Sicherheitsverletzungen beteiligt. NIS2 und DORA machen das Management dieses Risikos zur Pflicht, lassen die Methode aber offen. Ein Red Teaming, das mit einem Dienstleisterzugang beginnt, zeigt in wenigen Wochen, was dieser Zugang in Ihrem Netz tatsächlich erlaubt und ob Sie seinen Missbrauch bemerken würden. Dieser Beitrag ersetzt keine Rechtsberatung zu Ihren vertraglichen Pflichten. Wenn Sie Ihre externen Zugänge unter realen Bedingungen prüfen lassen möchten, finden Sie unter Red Teaming unser Vorgehen – oder sprechen uns über Kontakt direkt an.
Quellen
- Verizon, Data Breach Investigations Report 2025
- NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG), BGBl. 2025 I Nr. 301, in Kraft seit 6. Dezember 2025
- Verordnung (EU) 2022/2554 (DORA), Kapitel V (IKT-Drittparteienrisiko) und Art. 26, eur-lex.europa.eu
- Bundesamt für Sicherheit in der Informationstechnik, Die Lage der IT-Sicherheit in Deutschland 2025, bsi.bund.de
Häufige Fragen zum Thema
Wie häufig sind Angriffe über Dienstleister?
Darf ein Red Team die Systeme meines Dienstleisters angreifen?
Was verlangt NIS2 zur Lieferkette?
Was ist der wichtigste erste Schritt?
Welche Maßnahmen wirken am schnellsten?
Begriffe aus diesem Beitrag
Redaktion Gruppe RotDieser Beitrag wurde vom Red-Team von Gruppe Rot verfasst und fachlich geprüft. Er ersetzt keine Rechtsberatung. Zahlen und Quellen sind im Text genannt; bei Fragen oder Korrekturhinweisen freuen wir uns über eine Nachricht.