Die eigene IT ist sauber segmentiert.

MFA ist aktiviert.

Server sind gehärtet.

Backups sind unveränderbar gespeichert.

Das SOC überwacht die Infrastruktur rund um die Uhr.

Und trotzdem gelingt einem Angreifer der Zugriff.

Nicht über die Firewall.

Nicht über Phishing.

Nicht über einen ungepatchten Server.

Sondern über einen vertrauenswürdigen Dienstleister.

Willkommen beim Thema Supply Chain Security – der Sicherheit der Lieferkette.

Moderne IT-Infrastrukturen bestehen längst nicht mehr ausschließlich aus eigenen Servern und Anwendungen. Unternehmen und Behörden greifen auf zahlreiche externe Komponenten zurück:

• Cloud-Dienste,
• SaaS-Anwendungen,
• Managed Services,
• IT-Dienstleister,
• Fernwartungsunternehmen,
• Softwarehersteller,
• Hostinganbieter,
• Rechenzentren,
• externe Entwickler,
• Hardwarelieferanten.

Jede dieser Beziehungen kann neue Abhängigkeiten und damit zusätzliche Risiken erzeugen.

NIS-2 betrachtet deshalb ausdrücklich auch die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen Einrichtungen und ihren unmittelbaren Anbietern beziehungsweise Diensteanbietern.

Die entscheidende Erkenntnis lautet:

Die eigene Cybersecurity endet nicht an der eigenen Firewall.

1. Warum Lieferketten für Angreifer attraktiv sind

Stellen wir uns einen Softwarehersteller mit 3.000 Kunden vor.

Ein Angreifer könnte versuchen, jeden dieser Kunden einzeln anzugreifen.

Oder er kompromittiert den Hersteller.

Wird anschließend beispielsweise ein manipuliertes Softwareupdate verteilt, kann aus einem erfolgreichen Angriff plötzlich ein Angriff auf hunderte oder tausende Organisationen werden.

Das macht Lieferkettenangriffe besonders attraktiv.

Vereinfacht:

Angreifer
    │
    ▼
Softwarehersteller
    │
    ▼
Update-Infrastruktur
    │
    ├── Kunde 1
    ├── Kunde 2
    ├── Kunde 3
    ├── ...
    └── Kunde 3000

Der eigentliche Angriffspunkt befindet sich außerhalb der eigenen Organisation.

Die Auswirkungen landen trotzdem im eigenen Netzwerk.

2. Lieferkettensicherheit beginnt mit Transparenz

Der erste Schritt lautet deshalb:

Welche externen Abhängigkeiten besitzen wir überhaupt?

Eine Organisation sollte ihre relevanten Lieferanten und Dienstleister systematisch erfassen.

Beispielsweise:

Dienstleister
Cloud-Anbieter
Softwarehersteller
Hostingprovider
Rechenzentrum
Telekommunikationsanbieter
Managed Service Provider
Backup-Anbieter
Security-Dienstleister
externe Administratoren

Dabei reicht eine einfache Lieferantenliste nicht aus.

Entscheidend ist die Frage:

Welche Auswirkungen hätte ein Sicherheitsvorfall bei diesem Anbieter auf unsere Organisation?

3. Nicht jeder Lieferant ist gleich kritisch

Der Lieferant für Büromaterial besitzt normalerweise ein anderes Cyberrisiko als der Betreiber des zentralen Cloud-Rechenzentrums.

Deshalb sollten Lieferanten nach ihrer Kritikalität klassifiziert werden.

Beispielsweise:

Niedrige Kritikalität

Kein oder nur sehr geringer Zugriff auf IT-Systeme und sensible Informationen.

Mittlere Kritikalität

Zugriff auf bestimmte Daten oder nicht kritische Systeme.

Hohe Kritikalität

Zugriff auf sensible Daten oder wichtige Systeme.

Kritische Abhängigkeit

Ausfall oder Kompromittierung kann wesentliche Geschäftsprozesse beziehungsweise Dienste beeinträchtigen.

Eine einfache Bewertung könnte berücksichtigen:

• Datenzugriff,
• administrative Berechtigungen,
• Netzwerkzugriff,
• Kritikalität des Dienstes,
• Anzahl abhängiger Prozesse,
• Wiederherstellbarkeit,
• Austauschbarkeit des Lieferanten.

4. Dienstleister mit administrativen Rechten

Besonders kritisch sind externe Dienstleister mit privilegiertem Zugriff.

Beispiele:

• externe Administratoren,
• Managed Service Provider,
• Fernwartungsanbieter,
• Software-Support,
• Rechenzentrumsdienstleister.

Ein kompromittiertes Dienstleisterkonto kann einem Angreifer möglicherweise direkten Zugang zur eigenen Infrastruktur verschaffen.

Deshalb sollten externe Zugänge besonders geschützt werden.

Mögliche Maßnahmen:

• individuelle Benutzerkonten,
• MFA,
• zeitlich begrenzte Berechtigungen,
• Least Privilege,
• Freigabe von Fernwartungssitzungen,
• Jump Hosts,
• PAM-Systeme,
• Protokollierung administrativer Aktionen,
• automatische Deaktivierung nicht benötigter Zugänge.

Ein dauerhaft aktives Konto namens:

servicepartner-admin

mit Domain-Admin-Rechten und einem seit vier Jahren unveränderten Passwort ist keine Lieferkettensicherheit.

Es ist eine Einladung.

5. Cloud-Anbieter bewerten

Cloud-Dienste sind aus modernen IT-Umgebungen kaum noch wegzudenken.

Dazu gehören:

• Infrastructure as a Service,
• Platform as a Service,
• Software as a Service,
• Backup as a Service,
• Security as a Service.

Cloud bedeutet jedoch nicht:

„Der Anbieter kümmert sich jetzt um alles.“

Entscheidend ist das Shared-Responsibility-Prinzip.

Je nach Dienstmodell teilen sich Anbieter und Kunde die Verantwortung.

Vereinfacht:

On-Premises
Kunde: fast alles

IaaS
Provider: Infrastruktur
Kunde: Systeme, Anwendungen, Konfiguration

PaaS
Provider: Plattform
Kunde: Anwendungen, Daten, Identitäten

SaaS
Provider: Anwendung und Plattform
Kunde: Benutzer, Rechte, Daten, Konfiguration

Die genaue Aufteilung hängt vom jeweiligen Dienst ab.

Sie muss verstanden und dokumentiert werden.

6. Sicherheitsfragen an Cloud-Anbieter

Vor der Nutzung eines Cloud-Dienstes sollten unter anderem folgende Punkte betrachtet werden:

• Wo werden Daten verarbeitet?
• Welche Rechenzentren werden genutzt?
• Welche Sicherheitszertifizierungen bestehen?
• Wie erfolgt die Verschlüsselung?
• Wie werden Administratorzugriffe geschützt?
• Welche Logging-Möglichkeiten gibt es?
• Unterstützt der Dienst MFA?
• Welche Schnittstellen existieren?
• Wie werden Backups durchgeführt?
• Wie funktioniert Disaster Recovery?
• Welche Subdienstleister werden eingesetzt?
• Wie werden Sicherheitsvorfälle kommuniziert?
• Wie lassen sich Daten beim Vertragsende exportieren?
• Wie werden Daten anschließend gelöscht?

Die Antwort:

„Wir sind ISO-zertifiziert.“

ist hilfreich, ersetzt aber keine eigene Risikobewertung.

7. Softwarelieferanten als Teil der Lieferkette

Software besitzt heute häufig eine komplexe eigene Lieferkette.

Eine Anwendung kann bestehen aus:

eigener Quellcode
      │
      ├── Framework
      ├── Bibliothek A
      ├── Bibliothek B
      ├── Container Image
      ├── Runtime
      └── externe API

Eine Schwachstelle in einer einzigen Abhängigkeit kann Auswirkungen auf zahlreiche Anwendungen haben.

Bekannte Beispiele aus der Vergangenheit haben gezeigt, wie eine einzelne weit verbreitete Bibliothek plötzlich weltweit Sicherheitsabteilungen beschäftigen kann.

Deshalb sollten Organisationen bei kritischer Software wissen:

Welche Komponenten stecken eigentlich darin?

8. SBOM – Software Bill of Materials

Ein wichtiges Konzept dafür ist die Software Bill of Materials, kurz SBOM.

Eine SBOM ist vereinfacht eine Stückliste für Software.

Sie kann beispielsweise enthalten:

Anwendung: WebPortal 4.2

Komponenten:

Framework X 8.1
Library A 2.7
Library B 4.3
OpenSSL 3.x
Runtime Y

Wird anschließend eine kritische Schwachstelle in einer Komponente bekannt, lässt sich schneller prüfen:

Nutzen wir diese Komponente überhaupt?

Ohne Transparenz beginnt häufig eine hektische Suche durch die gesamte Infrastruktur.

SBOMs können diese Analyse erheblich erleichtern.

9. Softwareupdates müssen vertrauenswürdig sein

Ein besonders kritischer Bestandteil der Softwarelieferkette ist der Updateprozess.

Softwarehersteller sollten Mechanismen einsetzen, mit denen sich die Authentizität und Integrität von Updates prüfen lässt.

Beispielsweise:

• digitale Signaturen,
• Code Signing,
• Hash-Prüfungen,
• geschützte Update-Infrastrukturen,
• abgesicherte Build-Pipelines.

Auch auf Kundenseite sollte nicht jedes beliebige Paket ungeprüft auf kritischen Systemen installiert werden.

Besonders sensible Umgebungen können Updates zunächst in Test- oder Pilotgruppen prüfen.

Damit schließt sich der Kreis zu Teil 11 – Patch- und Schwachstellenmanagement.

10. Verträge sind ein Sicherheitsinstrument

Cybersecurity-Anforderungen sollten nicht nur in technischen Konzepten stehen.

Sie gehören auch in Verträge.

Denn spätestens bei einem Sicherheitsvorfall wird entscheidend:

Was muss der Dienstleister eigentlich leisten?

Mögliche vertragliche Sicherheitsanforderungen betreffen:

• Informationssicherheitsmaßnahmen,
• Patchmanagement,
• Schwachstellenmanagement,
• Zugriffsschutz,
• MFA,
• Verschlüsselung,
• Backup,
• Logging,
• Incident Response,
• Meldepflichten,
• Auditmöglichkeiten,
• Subdienstleister,
• Business Continuity,
• Exit-Verfahren.

Die Anforderungen sollten sich an Kritikalität und Risiko des jeweiligen Dienstes orientieren.

11. Sicherheitsvorfälle müssen schnell gemeldet werden

Ein besonders wichtiger Vertragsbestandteil ist die Meldung von Sicherheitsvorfällen.

Problematisch wäre beispielsweise:

Dienstleister entdeckt Angriff
        │
        ▼
interne Untersuchung
        │
        ▼
5 Tage später
        │
        ▼
Kunde wird informiert

Wenn der Kunde selbst gesetzlichen Meldefristen unterliegt, kann eine derart späte Information problematisch sein.

Deshalb sollten Verträge festlegen:

• wann der Kunde informiert wird,
• welche Vorfälle gemeldet werden,
• über welchen Kanal,
• welche Informationen geliefert werden,
• wie Updates zum Vorfall erfolgen,
• welche Ansprechpartner erreichbar sind.

Dabei sollte berücksichtigt werden, dass die eigene Organisation möglicherweise innerhalb kurzer gesetzlicher Fristen handeln muss.

12. Subdienstleister nicht vergessen

Viele Dienstleister erbringen Leistungen nicht vollständig selbst.

Beispielsweise:

Organisation
     │
     ▼
SaaS-Anbieter
     │
     ▼
Cloud-Provider
     │
     ▼
Rechenzentrum

Oder:

Organisation
     │
     ▼
IT-Dienstleister
     │
     ▼
externer Supportpartner

Damit entsteht eine Unterlieferkette.

Deshalb sollte geklärt werden:

• Welche Subdienstleister werden eingesetzt?
• Welche Daten erhalten sie?
• Welche Systeme können sie erreichen?
• Welche Sicherheitsanforderungen gelten für sie?
• Wie werden Änderungen kommuniziert?

Die eigene Lieferkette kann deutlich länger sein, als es auf den ersten Blick erscheint.

13. Sicherheitsbewertungen vor Vertragsabschluss

Ein kritischer Anbieter sollte nicht erst nach Vertragsabschluss auf seine Sicherheitsmaßnahmen geprüft werden.

Eine Sicherheitsbewertung gehört idealerweise bereits in den Beschaffungsprozess.

Ein möglicher Ablauf:

Bedarf
   │
   ▼
Anbieter auswählen
   │
   ▼
Security Assessment
   │
   ▼
Risiko bewerten
   │
   ├── akzeptabel
   │
   ├── Maßnahmen erforderlich
   │
   └── nicht akzeptabel
   │
   ▼
Vertrag

Damit wird Informationssicherheit Bestandteil der Beschaffung.

14. Security Questionnaires

Ein verbreitetes Instrument sind Sicherheitsfragebögen.

Dabei werden Lieferanten beispielsweise gefragt:

Organisation

• Existiert ein ISMS?
• Gibt es definierte Sicherheitsverantwortlichkeiten?
• Finden regelmäßige Risikoanalysen statt?

Zugriffsschutz

• Wird MFA eingesetzt?
• Gibt es ein Rollen- und Berechtigungskonzept?
• Werden privilegierte Konten besonders geschützt?

Schwachstellenmanagement

• Gibt es regelmäßige Schwachstellenscans?
• Wie schnell werden kritische Sicherheitsupdates installiert?
• Finden Penetrationstests statt?

Incident Response

• Existiert ein Incident-Response-Plan?
• Wie werden Kunden informiert?
• Gibt es einen 24/7-Ansprechpartner?

Business Continuity

• Existieren Backups?
• Werden Restoretests durchgeführt?
• Gibt es Disaster-Recovery-Pläne?

Der Fragebogen allein beweist jedoch noch keine Sicherheit.

15. Nachweise statt Häkchen

Ein Anbieter kann in einem Fragebogen problemlos ankreuzen:

„Ja, wir besitzen ein Informationssicherheitsmanagementsystem.“

Die nächste Frage sollte lauten:

„Können Sie das nachweisen?“

Mögliche Nachweise sind:

• Zertifikate,
• Auditberichte,
• Penetrationstestberichte,
• Sicherheitsrichtlinien,
• technische Dokumentationen,
• Business-Continuity-Nachweise,
• unabhängige Prüfberichte.

Dabei muss selbstverständlich geprüft werden, welche vertraulichen Informationen ein Anbieter tatsächlich bereitstellen kann.

Das Ziel ist nicht, sämtliche internen Dokumente des Dienstleisters einzusammeln.

Das Ziel ist eine angemessene Sicherheitsbewertung.

16. Zertifizierungen richtig einordnen

Zertifizierungen können eine wichtige Orientierung bieten.

Beispielsweise können je nach Anbieter und Dienst relevant sein:

• ISO/IEC 27001,
• branchenspezifische Zertifizierungen,
• Cloud-Sicherheitsstandards,
• BSI-bezogene Nachweise.

Eine Zertifizierung bedeutet jedoch nicht automatisch:

„Dieser Dienst ist für unseren konkreten Einsatzzweck sicher.“

Es muss geprüft werden:

• Was umfasst der Zertifizierungsbereich?
• Welche Standorte sind enthalten?
• Welche Dienste sind enthalten?
• Ist das Zertifikat aktuell?
• Passt der Scope überhaupt zum eingekauften Dienst?

Der Name des Anbieters auf einem Zertifikat reicht nicht.

Der Scope ist entscheidend.

17. Auditrechte vereinbaren

Bei kritischen Dienstleistern können Auditmöglichkeiten sinnvoll sein.

Diese können unterschiedliche Formen besitzen:

• eigene Audits,
• Audits durch unabhängige Dritte,
• Vorlage vorhandener Prüfberichte,
• Zertifizierungsnachweise,
• gemeinsame Sicherheitsreviews.

Nicht jede Organisation muss persönlich mit einem Klemmbrett durch das Rechenzentrum ihres Cloud-Anbieters laufen.

Bei großen Hyperscalern sind individuelle Vor-Ort-Audits häufig ohnehin nicht praktikabel.

Entscheidend ist, dass ausreichende Nachweise zur Bewertung der Sicherheitsmaßnahmen vorhanden sind.

18. Lieferanten kontinuierlich überwachen

Eine einmalige Prüfung bei Vertragsabschluss reicht nicht.

Ein Dienstleister kann sich verändern.

Beispiele:

• neue Eigentümer,
• neue Subdienstleister,
• neue Rechenzentren,
• neue Cloud-Plattform,
• Sicherheitsvorfälle,
• abgelaufene Zertifizierungen,
• erhebliche Produktänderungen.

Deshalb sollte Lieferantenmanagement als Lebenszyklus verstanden werden:

Auswahl
   ↓
Bewertung
   ↓
Vertrag
   ↓
Onboarding
   ↓
Überwachung
   ↓
Review
   ↓
Vertragsende

19. Regelmäßige Sicherheitsreviews

Die Häufigkeit sollte sich an der Kritikalität orientieren.

Beispielsweise:

kritischer Anbieter
→ häufigere Sicherheitsbewertung

wichtiger Anbieter
→ regelmäßiges Review

geringes Risiko
→ vereinfachtes Review

Dabei können unter anderem überprüft werden:

• Zertifizierungen,
• Sicherheitsvorfälle,
• vereinbarte Maßnahmen,
• Änderungen der Leistung,
• Subdienstleister,
• SLA-Erfüllung,
• offene Sicherheitsrisiken.

20. Technische Kontrollen nicht vergessen

Verträge und Fragebögen sind wichtig.

Aber eine Organisation sollte sich nicht ausschließlich darauf verlassen, dass ein Dienstleister niemals kompromittiert wird.

Deshalb gilt weiterhin Zero Trust.

Ein Dienstleister erhält nur die Zugriffe, die tatsächlich benötigt werden.

Beispiel:

Dienstleister
      │
      ▼
MFA
      │
      ▼
VPN
      │
      ▼
Jump Host
      │
      ▼
freigegebenes System

Nicht:

Dienstleister
      │
      ▼
VPN
      │
      ▼
gesamtes Netzwerk

Vertrauen sollte technisch begrenzt werden.

21. Zugriffe überwachen

Externe Zugriffe sollten möglichst nachvollziehbar sein.

Dazu gehören:

• Login-Protokolle,
• VPN-Verbindungen,
• administrative Aktionen,
• Dateiübertragungen,
• Änderungen an Systemen.

Besonders privilegierte Dienstleisterzugriffe können über PAM- beziehungsweise Session-Management-Lösungen kontrolliert werden.

Je nach Lösung lassen sich Sitzungen:

• freigeben,
• zeitlich begrenzen,
• protokollieren,
• überwachen.

Damit wird aus:

„Der Dienstleister hat Zugriff.“

eine wesentlich bessere Aussage:

„Wir wissen, wann, warum und worauf der Dienstleister Zugriff hatte.“

22. Schatten-IT als Lieferkettenrisiko

Nicht jeder Cloud-Dienst wurde offiziell beschafft.

Ein Fachbereich benötigt kurzfristig ein Werkzeug.

Also wird schnell ein SaaS-Dienst registriert.

Kreditkarte eingetragen.

Fertig.

Die IT weiß nichts davon.

Die Informationssicherheit ebenfalls nicht.

Möglicherweise werden dort anschließend sensible Daten verarbeitet.

Damit entsteht ein unbekannter Lieferant – und damit ein unbekanntes Risiko.

Deshalb sollten Organisationen Prozesse schaffen, mit denen Cloud- und SaaS-Dienste vor ihrer Nutzung bewertet werden.

23. Was passiert beim Vertragsende?

Lieferkettensicherheit endet nicht mit der Kündigung.

Beim Offboarding müssen unter anderem folgende Punkte berücksichtigt werden:

• Benutzerkonten deaktivieren,
• VPN-Zugänge entfernen,
• API-Keys widerrufen,
• Zertifikate erneuern,
• Dienstleisterkonten löschen,
• Daten exportieren,
• Daten beim Anbieter löschen,
• Hardware zurückgeben,
• Dokumentation aktualisieren.

Ein ehemaliger Dienstleister sollte nicht drei Jahre später noch über einen funktionierenden VPN-Account verfügen.

24. Vendor Lock-in als Resilienzrisiko

Auch die technische Abhängigkeit von einem Anbieter kann relevant sein.

Fragen sind beispielsweise:

• Können Daten exportiert werden?
• Existieren standardisierte Formate?
• Wie lange würde ein Anbieterwechsel dauern?
• Gibt es Alternativen?
• Was passiert bei Insolvenz des Anbieters?
• Wie schnell können kritische Dienste migriert werden?

Damit wird Lieferkettensicherheit auch zu einem Thema der Business Continuity.

25. Ein Lieferantenregister aufbauen

Für die praktische Umsetzung empfiehlt sich ein zentrales Lieferantenregister.

Darin könnten beispielsweise erfasst werden:

Anbieter:
Dienst:
Verantwortlicher:
Kritikalität:
verarbeitete Daten:
Systemzugriff:
administrativer Zugriff:
Subdienstleister:
Zertifizierungen:
Vertragslaufzeit:
Incident-Meldepflicht:
Auditrecht:
letzte Sicherheitsbewertung:
nächste Bewertung:
offene Risiken:

Damit entsteht Transparenz über die gesamte Lieferkette.

26. Lieferantenrisiken im Risikomanagement

Erkannte Risiken sollten nicht ausschließlich in einem Lieferantenregister verbleiben.

Sie gehören in das allgemeine Risikomanagement.

Beispiel:

Risiko:
Ausfall des zentralen SaaS-Anbieters

Auswirkung:
kritischer Geschäftsprozess nicht verfügbar

Eintrittswahrscheinlichkeit:
mittel

Schadenshöhe:
hoch

Maßnahmen:
- SLA
- Exportverfahren
- Notfallprozess
- regelmäßige Backups
- Exit-Strategie

Damit schließt sich der Kreis zu Teil 4 – Risikomanagement richtig umsetzen.

27. Typische Fehler bei der Lieferkettensicherheit

Fehler 1: Nur die eigene IT betrachten

Cyberrisiken entstehen auch bei Dienstleistern.

Fehler 2: Alle Lieferanten gleich behandeln

Kritikalität und Risiko müssen berücksichtigt werden.

Fehler 3: Zertifikat = automatisch sicher

Der konkrete Scope und Dienst müssen bewertet werden.

Fehler 4: Dienstleister erhält zu viele Rechte

Least Privilege gilt auch für externe Partner.

Fehler 5: Keine Incident-Meldepflicht im Vertrag

Dadurch können wichtige Informationen zu spät eintreffen.

Fehler 6: Subdienstleister werden ignoriert

Die tatsächliche Lieferkette kann mehrere Ebenen besitzen.

Fehler 7: Nur beim Vertragsabschluss prüfen

Lieferantenrisiken verändern sich.

Fehler 8: Offboarding vergessen

Nicht mehr benötigte Zugänge bleiben aktiv.

Praktische NIS-2-Checkliste zur Lieferkettensicherheit

Lieferantenmanagement

☐ Sind alle relevanten IT-Dienstleister erfasst?

☐ Sind Cloud-Anbieter dokumentiert?

☐ Sind kritische Softwarelieferanten bekannt?

☐ Existiert ein zentrales Lieferantenregister?

☐ Werden Lieferanten nach Kritikalität klassifiziert?

Risikobewertung

☐ Werden Lieferantenrisiken vor Vertragsabschluss bewertet?

☐ Werden Datenzugriffe berücksichtigt?

☐ Werden administrative Zugriffe bewertet?

☐ Werden Auswirkungen eines Ausfalls betrachtet?

☐ Werden Lieferantenrisiken in das allgemeine Risikomanagement übernommen?

Verträge

☐ Sind Informationssicherheitsanforderungen definiert?

☐ Gibt es Regelungen zu Sicherheitsvorfällen?

☐ Sind angemessene Informations- und Eskalationsfristen vereinbart?

☐ Sind Subdienstleister berücksichtigt?

☐ Sind Audit- beziehungsweise Nachweismöglichkeiten geregelt?

☐ Existieren Regelungen für Vertragsende und Datenlöschung?

Cloud

☐ Ist das Shared-Responsibility-Modell verstanden?

☐ Sind Speicher- und Verarbeitungsorte bekannt?

☐ Sind Logging-Möglichkeiten vorhanden?

☐ Ist MFA verfügbar und aktiviert?

☐ Sind Backup und Disaster Recovery bewertet?

☐ Existiert eine Exit-Strategie?

Software

☐ Werden kritische Softwarelieferanten bewertet?

☐ Gibt es Informationen über Softwareabhängigkeiten?

☐ Können SBOMs genutzt oder angefordert werden?

☐ Werden Sicherheitsupdates vertrauenswürdig bereitgestellt?

☐ Existiert ein definierter Vulnerability-Disclosure-Prozess beim Hersteller?

Externe Zugriffe

☐ Besitzt jeder Dienstleister ein individuelles Konto?

☐ Wird MFA eingesetzt?

☐ Werden Rechte nach Least Privilege vergeben?

☐ Sind Zugänge zeitlich begrenzbar?

☐ Werden administrative Aktionen protokolliert?

☐ Werden nicht benötigte Konten automatisch deaktiviert?

Kontrollen und Audits

☐ Werden Sicherheitsnachweise regelmäßig geprüft?

☐ Ist der Scope von Zertifizierungen bekannt?

☐ Werden kritische Anbieter regelmäßig neu bewertet?

☐ Werden vereinbarte Sicherheitsmaßnahmen kontrolliert?

☐ Werden relevante Sicherheitsvorfälle des Lieferanten berücksichtigt?

Offboarding

☐ Werden Benutzerkonten gelöscht?

☐ Werden VPN-Zugänge entfernt?

☐ Werden API-Schlüssel widerrufen?

☐ Werden Daten zurückgegeben beziehungsweise gelöscht?

☐ Wird das Lieferantenregister aktualisiert?

Moderne IT-Sicherheit lässt sich nicht mehr ausschließlich innerhalb der eigenen Organisation betrachten.

Cloud-Dienste betreiben Anwendungen.

Softwarehersteller liefern Updates.

Managed Service Provider administrieren Systeme.

Rechenzentren stellen Infrastruktur bereit.

Externe Spezialisten erhalten privilegierte Zugänge.

Damit entsteht ein komplexes digitales Ökosystem.

Und jede Verbindung kann sowohl einen Mehrwert als auch ein Risiko darstellen.

NIS-2 verlangt deshalb zu Recht, die Lieferkette in das Cyber-Risikomanagement einzubeziehen.

Das bedeutet jedoch nicht, jeden Lieferanten mit denselben umfangreichen Audits zu überziehen.

Der richtige Ansatz ist risikobasiert.

Ein kritischer Cloud-Anbieter benötigt eine andere Bewertung als ein Dienstleister ohne Zugriff auf Systeme oder sensible Daten.

Lieferkettensicherheit besteht deshalb aus mehreren Ebenen:

Identifizieren → Klassifizieren → Bewerten → Vertraglich absichern → Technisch begrenzen → Überwachen → Kontrollieren → Neu bewerten → Sicher beenden

Besonders wichtig ist dabei eine Erkenntnis:

Vertrauen ersetzt keine Kontrolle.

Ein Vertrag verhindert keinen Cyberangriff.

Ein ISO-Zertifikat verhindert keine kompromittierten Zugangsdaten.

Und ein renommierter Cloud-Anbieter verhindert keine Fehlkonfiguration auf Kundenseite.

Deshalb müssen organisatorische, vertragliche und technische Maßnahmen zusammenspielen.

Denn am Ende gilt auch für NIS-2:

Ein Dienst kann ausgelagert werden. Die Verantwortung für das eigene Cyberrisiko jedoch nicht.