Risiken bezüglich Lieferanten

Lieferantenrisiken richtig bewerten – drei Blickwinkel, ein Risikoprofil


Lieferanten werden häufig zunächst unter einem klassischen Gesichtspunkt bewertet: Kann der Lieferant die vereinbarte Leistung in der geforderten Qualität, zum richtigen Zeitpunkt und zu akzeptablen Kosten erbringen?

Für viele Unternehmen reicht diese Betrachtung heute jedoch nicht mehr aus.

Ein Lieferant kann gleichzeitig ein Qualitätsrisiko, Informationssicherheitsrisiko und kaufmännisches bzw. strategisches Risiko darstellen. Hinzu kommen Abhängigkeiten aus der Lieferkette, von Subunternehmern, von einzelnen Technologien oder von bestimmten Standorten.

Besonders kritisch wird es, wenn ein Lieferant Zugang zu vertraulichen Informationen, IT-Systemen oder privilegierten Funktionen hat oder für einen geschäftskritischen Prozess benötigt wird.

Eine belastbare Lieferantenbewertung sollte deshalb nicht nur fragen:

„Wie gut ist dieser Lieferant?“

sondern vor allem:

„Welche Abhängigkeit entsteht durch diesen Lieferanten – und was passiert, wenn seine Leistung morgen ausfällt?“

 

1. Drei Blickwinkel auf das Lieferantenrisiko

Eine praxisgerechte Bewertung kann zunächst aus drei Perspektiven erfolgen:

  1. Qualität und Leistung
  2. Informationssicherheit
  3. Kaufmännische und strategische Aspekte

Diese Perspektiven sollten nicht isoliert betrachtet werden. Erst ihre Kombination ergibt ein belastbares Lieferanten-Risikoprofil.

 

2. Qualitäts- und Leistungsrisiken

Die klassische Lieferantenbewertung beschäftigt sich vor allem mit der Fähigkeit des Lieferanten, die vereinbarte Leistung zuverlässig und in der geforderten Qualität zu erbringen.

Typische Risiken sind:

  • verspätete Lieferungen
  • Ausfall oder Unterbrechung der Leistung
  • hohe Fehler- oder Reklamationsquote
  • mangelnde Prozessreife
  • unzureichende Dokumentation
  • fehlende Nachvollziehbarkeit
  • Abhängigkeit von einzelnen Personen
  • mangelnde Kapazitäten
  • häufige Änderungen von Ansprechpartnern
  • instabile Sub-Lieferanten
  • Qualitätsprobleme in der vorgelagerten Lieferkette

Mögliche Auswirkungen

Die Folgen können erheblich sein:

  • Produktionsunterbrechungen
  • Verzögerungen bei Kundenprojekten
  • zusätzliche Prüf- und Nacharbeitskosten
  • Vertragsverletzungen
  • Kundenbeschwerden
  • Imageschäden
  • erhöhte operative Belastung
  • Nichterfüllung eigener Qualitätsanforderungen

Gerade bei kritischen Lieferanten reicht deshalb eine einmalige Bewertung bei der Lieferantenauswahl nicht aus.

Die Leistungsfähigkeit muss während der gesamten Geschäftsbeziehung überwacht werden.

 

3. Informationssicherheitsrisiken

Bei vielen modernen Lieferantenbeziehungen ist die Informationssicherheit mindestens ebenso relevant wie die Qualität.

Ein Lieferant kann beispielsweise:

  • auf vertrauliche Informationen zugreifen
  • personenbezogene Daten verarbeiten
  • Zugang zu internen IT-Systemen erhalten
  • Remote-Zugriffe durchführen
  • administrative Berechtigungen besitzen
  • Software entwickeln oder betreiben
  • Cloud-Dienste bereitstellen
  • Sicherheits- oder Betriebsprozesse übernehmen
  • Daten speichern oder übertragen
  • weitere Subunternehmer einsetzen

Damit entsteht eine zusätzliche Risikofläche außerhalb der direkten Kontrolle des eigenen Unternehmens.

Typische Informationssicherheitsrisiken

Beispiele sind:

  • unzureichendes Berechtigungsmanagement
  • nicht ausreichend geschützte Remote-Zugänge
  • fehlende oder unzureichende MFA
  • unzureichende Verschlüsselung
  • fehlende Protokollierung
  • unzureichendes Schwachstellenmanagement
  • mangelhaftes Incident Management
  • unzureichende Datensicherung
  • fehlende Business-Continuity-Maßnahmen
  • unkontrollierte Subunternehmer
  • unzureichende Trennung von Kundendaten
  • fehlende Regelungen zur Rückgabe oder Löschung von Daten

Die zentrale Frage lautet dabei nicht:

„Ist der Lieferant ein IT-Dienstleister?“

Sondern:

„Welche Informationen, Systeme und Berechtigungen erhält dieser konkrete Lieferant?“

Ein externer Dienstleister mit administrativem Zugriff auf produktive Systeme kann beispielsweise ein wesentlich höheres Risiko darstellen als ein IT-Lieferant, der lediglich Standardhardware liefert.

 

4. Kaufmännische und strategische Risiken

Neben Qualität und Informationssicherheit sollte auch die wirtschaftliche und strategische Abhängigkeit betrachtet werden.

Typische Risiken sind:

  • finanzielle Instabilität
  • Insolvenzrisiko
  • starke Preissteigerungen
  • unklare Preis- und Abrechnungsmodelle
  • ungünstige Vertragsbedingungen
  • unzureichende Haftungsregelungen
  • zu lange Vertragsbindungen
  • fehlende Kündigungs- oder Exit-Möglichkeiten
  • hohe Migrationskosten
  • fehlende alternative Lieferanten
  • Vendor Lock-in
  • mangelnder Support
  • fehlende strategische Perspektive
  • Abhängigkeit von einer bestimmten Technologie
  • Währungsrisiken
  • geopolitische Risiken
  • Export- oder Sanktionsrisiken

Gerade bei Cloud- und Softwaredienstleistungen kann der Exit ein wesentliches Risiko darstellen.

Die Frage lautet dann beispielsweise:

Was passiert, wenn der Anbieter den Dienst einstellt oder wir den Vertrag kurzfristig beenden müssen?

Kann das Unternehmen seine Daten exportieren?

Gibt es einen alternativen Anbieter?

Wie lange dauert die Migration?

Welche Kosten entstehen?

Kann der eigene Betrieb die Leistung vorübergehend übernehmen?

 

5. Lieferketten- und Resilienzrisiken

Eine zusätzliche Betrachtung ist heute häufig erforderlich: die Stabilität der Lieferkette.

Ein Lieferant kann selbst von weiteren Unternehmen abhängig sein.

Beispielsweise:

Unternehmen → IT-Dienstleister → Cloud Provider → Rechenzentrum → Netzbetreiber

Oder:

Unternehmen → Hersteller → Zulieferer → Rohstofflieferant

Ein Ausfall kann deshalb mehrere Ebenen der Lieferkette gleichzeitig betreffen.

Relevant sind beispielsweise:

  • Single Source
  • fehlende Alternativen
  • Abhängigkeit von einzelnen Standorten
  • Abhängigkeit von einzelnen Subunternehmern
  • geopolitische Risiken
  • Naturkatastrophen
  • Transport- und Logistikrisiken
  • Energieversorgung
  • politische Instabilität
  • Abhängigkeit von kritischen Technologien
  • Konzentrationsrisiken bei Cloud- oder Plattformanbietern

Diese Aspekte überschneiden sich mit den drei oben genannten Perspektiven. Sie sollten deshalb nicht zwingend als vierter separater Bewertungsprozess behandelt werden, sondern können als Querschnittsthema der Lieferantenrisikobewertung verstanden werden.

 

6. Nicht der Lieferantentyp entscheidet – sondern die konkrete Abhängigkeit

Eine häufige Vereinfachung lautet:

Lieferant - Risikoklasse

Cloud Provider - hoch

IT-Dienstleister - hoch

Marketingagentur - mittel

Büromaterial - niedrig


Eine solche Einstufung kann als erste Orientierung dienen, ist aber für eine belastbare Risikobewertung zu pauschal.

Entscheidend sind die tatsächlichen Eigenschaften der Geschäftsbeziehung.

Ein besserer Ansatz ist:

Niedriges Risiko

  • kein Zugriff auf kritische Informationen
  • kein Zugriff auf IT-Systeme
  • keine privilegierten Berechtigungen
  • kein Einfluss auf kritische Prozesse
  • kurzfristig ersetzbar
  • geringe wirtschaftliche Abhängigkeit

Mittleres Risiko

  • Zugriff auf interne Informationen oder Prozesse
  • begrenzter Systemzugriff
  • gewisse Abhängigkeit
  • Lieferant nicht unmittelbar ersetzbar
  • moderate Auswirkungen bei Ausfall

Hohes Risiko

  • Zugriff auf sensible oder kritische Informationen
  • privilegierter oder administrativer Zugriff
  • Unterstützung kritischer Geschäftsprozesse
  • hohe Verfügbarkeitsabhängigkeit
  • schwer ersetzbarer Lieferant
  • erhebliche regulatorische, finanzielle oder operative Auswirkungen
  • starke Abhängigkeit von Subunternehmern
  • erheblicher Aufwand für Migration oder Exit

Die Einstufung sollte daher immer auf der konkreten Lieferantenbeziehung basieren.

 

7. Eine einfache Kernfrage für die Risikobewertung

Eine besonders hilfreiche Frage lautet:

Was passiert, wenn dieser Lieferant morgen für 30 Tage nicht mehr verfügbar ist?

Die Antwort liefert häufig bereits wichtige Informationen für die Risikobewertung.

Dabei sollte betrachtet werden:

  • Welche Prozesse sind betroffen?
  • Welche Informationen sind betroffen?
  • Welche Systeme sind betroffen?
  • Welche Kunden sind betroffen?
  • Welche gesetzlichen oder vertraglichen Verpflichtungen sind betroffen?
  • Gibt es einen alternativen Lieferanten?
  • Kann die Leistung intern übernommen werden?
  • Wie schnell kann eine Ersatzlösung aufgebaut werden?
  • Welche Kosten entstehen?
  • Welche Daten befinden sich beim Lieferanten?
  • Welche Zugriffsrechte besitzt der Lieferant?
  • Können Daten und Systeme zurückgeführt werden?
  • Gibt es einen funktionierenden Exit- oder Notfallplan?

Damit wird aus einer allgemeinen Lieferantenbewertung eine konkrete Abhängigkeits- und Risikobetrachtung.

 

8. Lieferantenrisiko anhand konkreter Kriterien bewerten

Eine einfache Bewertungsmatrix kann beispielsweise folgende Dimensionen verwenden:

Dimension:   Leitfrage

Kritikalität: Wie wichtig ist die Leistung für das Unternehmen?

Informationen: Auf welche Informationen hat der Lieferant Zugriff?

Systemzugriff : Auf welche Systeme kann der Lieferant zugreifen?

Berechtigungen: Besitzt er privilegierte oder administrative Rechte?

Verfügbarkeit: Welche Folgen hat ein Ausfall?

Qualität: Welche Folgen haben Fehler oder mangelhafte Leistungen?

Subunternehmer: Welche weiteren Unternehmen sind beteiligt?

Abhängigkeit: Wie stark ist das Unternehmen vom Lieferanten abhängig?

Ersetzbarkeit: Gibt es kurzfristig Alternativen?

Exit: Wie schwierig ist eine Beendigung bzw. Migration?

Wirtschaftlichkeit: Welche finanziellen Risiken bestehen?

Compliance: Welche gesetzlichen oder regulatorischen Anforderungen sind betroffen?

Geografie: Welche Länder-, Standort- oder geopolitischen Risiken bestehen?

Resilienz: Wie robust ist die Lieferkette gegenüber Ausfällen?


Aus diesen Kriterien kann anschließend eine Lieferanten-Risikoklasse abgeleitet werden.

 

9. Informationssicherheit nach ISO/IEC 27001:2022

Für ein Informationssicherheitsmanagementsystem nach ISO/IEC 27001:2022 ist die Lieferantenbeziehung insbesondere im Annex A relevant.

Besonders wichtig sind:

  • A.5.19 – Information security in supplier relationships
  • A.5.20 – Addressing information security within supplier agreements
  • A.5.21 – Managing information security in the ICT supply chain
  • A.5.22 – Monitoring, review and change management of supplier services
  • A.5.23 – Information security for use of cloud services

Damit wird deutlich: Lieferantenmanagement ist nicht nur eine Frage der Einkaufspolitik.

Es ist auch Bestandteil des Informationssicherheitsmanagements.

Dabei geht es nicht ausschließlich um die Auswahl eines Lieferanten. Die Lieferantenbeziehung muss über ihren gesamten Lebenszyklus gesteuert werden.

 

10. Der Lieferanten-Lebenszyklus

Eine praktische Struktur ist:

Auswahl → Vertrag → Onboarding → Leistungserbringung → Überwachung → Änderung → Neubewertung → Exit

a. Auswahl

  • Leistungsfähigkeit bewerten
  • Risiken identifizieren
  • Informationen und Zugriffe bestimmen
  • Alternativen betrachten
  • Risikoklasse festlegen

b. Vertrag

Je nach Risiko können beispielsweise geregelt werden:

  • Leistungsumfang
  • SLA
  • Informationssicherheit
  • Datenschutz
  • Vertraulichkeit
  • Berechtigungen
  • Incident-Meldungen
  • Audit- und Nachweisrechte
  • Subunternehmer
  • Änderungsmanagement
  • Business Continuity
  • Datenrückgabe
  • Löschung
  • Exit

c. Onboarding

Der Lieferant erhält nur die Zugriffe und Informationen, die tatsächlich benötigt werden.

Besonders bei IT-Dienstleistern sollte der Grundsatz gelten:

So viel Zugriff wie erforderlich – so wenig Zugriff wie möglich.

d. Überwachung

Je nach Risikoklasse können beispielsweise überwacht werden:

  • SLA-Erfüllung
  • Qualitätskennzahlen
  • Sicherheitsvorfälle
  • Schwachstellen
  • Auditberichte
  • Zertifikate
  • Änderungen beim Lieferanten
  • Subunternehmer
  • finanzielle Situation
  • Leistungsfähigkeit

e. Neubewertung

Eine Neubewertung sollte nicht nur in festen Intervallen erfolgen.

Sie ist insbesondere bei wesentlichen Änderungen sinnvoll, beispielsweise:

  • neue Dienstleistung
  • neue Systeme
  • neue Daten
  • neue Zugriffsrechte
  • neuer Subunternehmer
  • Standortwechsel
  • Übernahme oder Fusion
  • Sicherheitsvorfall
  • erhebliche Leistungsprobleme
  • Änderung gesetzlicher Anforderungen

f. Exit

Auch das Ende einer Lieferantenbeziehung sollte geplant sein.

Dazu gehören beispielsweise:

  • Rückgabe der Daten
  • Löschung der Daten
  • Entzug von Berechtigungen
  • Rückgabe von Geräten
  • Übergabe von Dokumentation
  • Migration
  • Übergang zu einem Ersatzlieferanten
  • Nachweis der vollständigen Beendigung des Zugriffs

 

11. Hohe Lieferantenrisiken erfordern stärkere Maßnahmen

Nicht jeder Lieferant benötigt die gleiche Prüftiefe.

Bei einem Lieferanten mit geringem Risiko kann eine einfache Bewertung ausreichend sein.

Bei einem kritischen Lieferanten können dagegen zusätzliche Maßnahmen erforderlich sein:

  • detaillierter Sicherheitsfragebogen
  • Prüfung von Zertifizierungen
  • Bewertung eines ISO/IEC-27001-Zertifikats
  • Prüfung von SOC-Berichten oder anderen Nachweisen
  • Sicherheitsanforderungen im Vertrag
  • definierte Incident-Meldezeiten
  • Audit- oder Assessment-Rechte
  • Regelungen zu Subunternehmern
  • regelmäßige Neubewertung
  • technische Sicherheitsanforderungen
  • Business-Continuity-Anforderungen
  • Exit- und Fallback-Strategie

Der Grundsatz sollte lauten:

Je höher die Abhängigkeit und das Risiko, desto höher sollte auch die Tiefe der Lieferantensteuerung sein.

 

12. Lieferantenrisiko ist nicht nur ein Einkaufsthema

Eine gute Lieferantenbewertung benötigt häufig mehrere Fachbereiche.

Beispielsweise:

Einkauf
→ Vertrag, Preise, Lieferfähigkeit, Alternativen

Fachbereich
→ Prozesskritikalität, Leistungsanforderungen, Qualität

IT / Informationssicherheit
→ Systeme, Daten, Zugriffe, Sicherheitsanforderungen

Datenschutz
→ personenbezogene Daten, Auftragsverarbeitung

Qualitätsmanagement
→ Qualitätsanforderungen, Reklamationen, Audits

Business Continuity / Resilienz
→ Abhängigkeiten, Ausfallszenarien, Wiederanlauf

Dadurch entsteht kein isoliertes Lieferantenrating, sondern ein integriertes Lieferanten-Risikoprofil.

 

13. Ein praktisches Beispiel

Ein Unternehmen beauftragt einen externen IT-Dienstleister mit dem Betrieb eines geschäftskritischen Systems.

Der Dienstleister:

  • besitzt administrativen Zugriff,
  • verarbeitet vertrauliche Unternehmensdaten,
  • unterstützt einen kritischen Geschäftsprozess,
  • nutzt selbst einen Cloud Provider,
  • ist nur schwer kurzfristig ersetzbar.

Aus den drei Perspektiven ergibt sich:

Qualität

Ausfall oder mangelhafte Leistung kann den Geschäftsprozess unterbrechen.

Informationssicherheit

Der Dienstleister besitzt privilegierte Zugriffsrechte und verarbeitet vertrauliche Informationen.

Kaufmännisch / strategisch

Eine kurzfristige Ablösung wäre schwierig und mit erheblichen Kosten verbunden.

Lieferkette / Resilienz

Zusätzlich besteht eine Abhängigkeit vom Cloud Provider des Dienstleisters.

Das Ergebnis ist eindeutig:

Die konkrete Lieferantenbeziehung besitzt ein hohes Risikoprofil.

Entsprechend sollte auch die Steuerung intensiver sein.

 

14. Lieferantenrisiko als Bestandteil des Risikomanagements

Lieferantenrisiken sollten nicht als isolierte Excel-Liste neben dem eigentlichen Risikomanagement existieren.

Sie sollten mit dem bestehenden Risikomanagement verbunden sein.

Eine mögliche Kette lautet:

·      Lieferant identifizieren

·      Abhängigkeit verstehen

·      Risiken bewerten

·      Risikoklasse bestimmen

·      Anforderungen festlegen

·      vertragliche / technische / organisatorische Maßnahmen umsetzen

·      Leistung und Risiken überwachen

·      bei Änderungen neu bewerten

·      Exit- und Fallback-Fähigkeit sicherstellen

Damit wird aus der Lieferantenbewertung ein kontinuierlicher Steuerungsprozess.

 

15. Fazit

Lieferantenrisiken lassen sich nicht allein anhand von Qualität, Einkaufspreisen oder einer Checkliste für Informationssicherheit bewerten.

Eine belastbare Bewertung betrachtet mindestens drei Perspektiven:

Qualität und Leistung
→ Kann der Lieferant die erforderliche Leistung zuverlässig erbringen?

Informationssicherheit
→ Welche Informationen, Systeme und Berechtigungen sind betroffen?

Kaufmännische und strategische Aspekte
→ Welche wirtschaftliche und strategische Abhängigkeit entsteht?

Ergänzend sollte die Resilienz der Lieferkette betrachtet werden.

Dabei ist die entscheidende Frage nicht:

„Welche Art Lieferant ist das?“

Sondern:

„Welche konkrete Abhängigkeit entsteht durch diesen Lieferanten?“

Genau daraus lässt sich ableiten, welche Anforderungen, Vertragsregelungen, Kontrollen, Überwachungsmaßnahmen und Exit-Strategien erforderlich sind.

Ein Lieferantenrisiko endet deshalb auch nicht mit der Auswahl des Lieferanten.

Es muss über den gesamten Lebenszyklus gesteuert werden – von der Auswahl über den Vertrag und die Leistungserbringung bis zur Neubewertung und zum Exit.

Das Ziel ist nicht, jeden Lieferanten maximal zu kontrollieren.

Das Ziel ist:

Die richtigen Lieferanten angemessen steuern – abhängig von ihrer tatsächlichen Kritikalität, ihrem Zugriff, ihrer Abhängigkeit und ihrem Risiko.



Viel Erfolg, Ihr Konstantin Ziouras


Konstantin Ziouras Blog Artikel

von Konstantin Ziouras • 5. Oktober 2026
Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit
von Konstantin Ziouras • 5. Oktober 2026
ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken
von Konstantin Ziouras • 22. September 2026
Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board
von Konstantin Ziouras • 22. September 2026
Anforderungsmanagement nach IREB - International Requirements Engineering Board
von Konstantin Ziouras • 22. September 2026
Requirements Engineering als Qualitäts- und Sicherheitsfaktor
von Konstantin Ziouras • 18. Mai 2026
Unterschiede zwischen EULA, SLA und AVV
von Konstantin Ziouras • 18. Mai 2026
Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern
von Konstantin Ziouras • 10. Mai 2026
Lieferanten, Auswahl und Bewertung
von Konstantin Ziouras • 15. April 2026
Endpoint Security bedeutet: Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen. Endpoint Security sorgt dafür, dass diese Türen: • nicht offenstehen • nicht mit gestohlenen Schlüsseln geöffnet werden • und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen. Warum das Thema heute wichtig ist 1. Angriffe starten fast immer am Endpoint • Phishing Mails → Klick → Malware auf dem Laptop • Ransomware → Verschlüsselung startet am Endpoint • Initial Access Broker → kompromittierte Endgeräte werden verkauft 2. Arbeitswelt hat sich verändert • Homeoffice, Remote Work, BYOD • Cloud Zugriffe von überall • Mehr Endgeräte, weniger klarer Perimeter 3. Business Relevanz • Ein kompromittierter Endpoint kann: o Zugang zu AD / Identitäten geben o Ransomware ins gesamte Netz bringen o Datenabfluss ermöglichen • Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen. Technische Grundlagen Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät. Wichtige Bausteine: • Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz • Host Firewall: Filtert eingehenden/ausgehenden Traffic • Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response • Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten • Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste) • Patch Management: Schließen von Schwachstellen Stand der Technik / Best Practices 1. Von klassischem AV zu EDR/XDR • Klassischer Virenscanner allein ist nicht mehr ausreichend. • Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen. 2. Zero Trust am Endpoint • Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist. • Kombination aus: o Gerätestatus (Compliance) o Identität (User) o Kontext (Ort, Zeit, Risiko) 3. Harter Fokus auf Identitäten • Endpoint Security ist eng mit Identity & Access Management verknüpft. • Kompromittierter Endpoint → kompromittierte Identität → lateral movement. 4. Standardisierte Baselines • CIS Benchmarks, BSI Empfehlungen, Hardening Guides • Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme. Typische Risiken & Fehler in der Praxis • Nur Antivirus, kein EDR/XDR • Kein zentrales Management der Endpoints • Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins) • Lokale Adminrechte für Benutzer • Kein Application Whitelisting (alles darf laufen) • Shadow IT (private Geräte, nicht verwaltete Systeme) • OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“ • Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt Moderne Lösungsansätze & Technologien • EDR/XDR Plattformen o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien) o Erkennen verdächtige Muster (z. B. Ransomware Verhalten) o Unterstützen Incident Response (Isolieren von Endpoints, Forensik) • Zero Trust Network Access (ZTNA) o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check) • Mobile Device Management (MDM) / Unified Endpoint Management (UEM) o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung) • Application Control / Whitelisting o Nur erlaubte Anwendungen dürfen laufen o Sehr wirksam gegen Malware und Ransomware • Hardware basierte Sicherheit o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault) Relevanz für Informationssicherheit & Compliance NIS2 • Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen. • Endpoint Security ist zentral für: o Schutz vor Ransomware o Incident Detection & Response o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden. ISO 27001:2022 • Relevante Controls u. a.: o A.5.15: Access control o A.5.23: Information security for use of mobile devices o A.8.7: Protection against malware o A.8.8: Management of technical vulnerabilities o A.8.9: Configuration management IEC 62443 (für OT) • Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen: o gehärtet sein o nur notwendige Dienste bereitstellen o überwacht werden o in Zonen/Conduits eingebettet sein. Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443. Empfehlungen für Unternehmen (konkret, priorisiert) Priorität 1 – Basis schaffen • Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile) • EDR Lösung ausrollen (mindestens auf kritischen Systemen) • Patch Management etablieren (inkl. Drittsoftware) • Plattferverschlüsselung aktivieren (Laptops, mobile Geräte) • Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin) Priorität 2 – Reifegrad erhöhen • Application Whitelisting für besonders kritische Systeme • Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint • Integration in SIEM/SOC: Alarme zentral auswerten • Standardisierte Hardening Baselines (CIS, BSI) Priorität 3 – OT & Spezialumgebungen • OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server) • Schutzkonzept definieren: o Hardening o Segmentierung o Monitoring (passiv, wo aktiv nicht möglich) • Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording. CTO Checkliste: Die 3 entscheidenden Fragen 1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“ Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten: • verhaltensbasierte Erkennung • Prozess und Speicheranalyse • Telemetrie Korrelation • automatische Isolation des Endpoints • Integration ins SOC/SIEM Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern. 2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“ Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten: • zentrales Endpoint Management (UEM/MDM) • automatisiertes Patch Management (inkl. Drittsoftware) • CIS/BSI Hardening Baselines • Compliance Checks vor Zugriff (Zero Trust) Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend. 3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“ Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten: • EDR gestützte Isolation per Klick • klare Rollen (SOC, IT Ops, Dienstleister) • forensische Daten (Prozesse, Registry, Netzwerk, Timeline) • definierte Reaktionszeiten • Playbooks Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.
von Konstantin Ziouras • 14. April 2026
1. Was ist eine Firewall? Stell dir dein Netzwerk wie ein Gebäude vor. Eine Firewall ist: • Der Türsteher: Prüft, wer rein darf. • Der Sicherheitszaun: Hält unerwünschte Besucher draußen. • Die Schleuse: Kontrolliert jeden, der das Gelände betreten oder verlassen will. Sie entscheidet basierend auf Regeln: Wer darf mit wem worüber sprechen? 2. Was ist ein Gateway? Ein Gateway ist wie ein Grenzübergang zwischen zwei Bereichen: • zwischen internem Netzwerk und Internet • zwischen IT und OT • zwischen Cloud und On Premises • zwischen verschiedenen Sicherheitszonen Es kontrolliert: • welche Daten passieren dürfen • wie sie geprüft werden • ob sie sicher sind 3. Warum braucht man Firewalls und Gateways? Weil Netzwerke ohne sie offene Häuser wären. Sie schützen vor: • Hackern • Malware • Ransomware • Datenklau • unbefugten Zugriffen • Angriffen auf OT Systeme Ohne Firewalls wäre jedes Gerät direkt aus dem Internet erreichbar — ein Albtraum. 4. Welche Arten von Firewalls gibt es? 1) Klassische Firewalls • prüfen IP Adressen und Ports • wie ein Türsteher, der nur auf die Eintrittskarte schaut 2) Next Generation Firewalls (NGFW) • prüfen Inhalte • erkennen Angriffe • filtern Apps (z. B. „erlaube nur Teams, blockiere Torrent“) • wie ein Türsteher, der auch Taschen kontrolliert 3) Web Application Firewalls (WAF) • schützen Webseiten und APIs • blockieren SQL Injection, XSS, Bots 4) OT Firewalls • verstehen industrielle Protokolle (Modbus, OPC UA) • blockieren gefährliche Befehle • schützen Produktionsanlagen 5) Cloud Firewalls • steuern Traffic in AWS, Azure, GCP • sind Teil moderner Cloud Architekturen 5. Wie schützen Firewalls uns? Sie: • blockieren Angriffe • verhindern unbefugte Zugriffe • segmentieren Netzwerke • überwachen Datenverkehr • erkennen Anomalien • stoppen Malware • schützen kritische Systeme 6. Typische Fehler (die in der Praxis noch vorkommen) • „Allow ANY ANY“ (alles erlaubt) • keine Segmentierung (Flat Network) • keine Dokumentation • veraltete Regeln • keine Überwachung • keine TLS Inspection → Blindflug • OT Netze ohne Protokollfilter 7. Was bedeutet das für Unternehmen? Sie brauchen: • klare Netzwerkzonen • moderne Firewalls • regelmäßige Regelwerks Reviews • Monitoring & Logging • Zero Trust Prinzipien • OT spezifische Schutzmaßnahmen • Cloud Firewalls für moderne Umgebungen 8. Verbindung zu Standards • NIS2 verlangt „angemessene technische Maßnahmen“ → Firewalls sind Pflicht • ISO 27001 verlangt Netzwerksegmentierung und Zugriffskontrollen • IEC 62443 verlangt Zonen/Conduits und OT Firewalls • ISO 22301 verlangt Schutz kritischer Systeme Kurz gesagt Firewall und Gateway Sicherheit bedeutet: • Netzwerke in sichere Bereiche aufteilen • nur erlaubten Verkehr zulassen • Angriffe erkennen und blockieren • OT und Cloud Systeme speziell schützen • Regeln regelmäßig prüfen • Monitoring aktiv betreiben Es ist die Grundlage jeder modernen Sicherheitsarchitektur. Checkliste für Firewall und Gateway Sicherheit 1. Architektur & Netzwerkdesign • Netzwerk in Sicherheitszonen segmentiert (z. B. IT, OT, DMZ, Cloud) • Klare Trust Boundaries definiert • Firewalls an allen Übergängen zwischen Zonen platziert • Redundante Firewall Cluster vorhanden • Zero Trust Prinzipien berücksichtigt • OT Netze strikt von IT getrennt • Remote Zugänge nur über gesicherte Gateways 2. Regelwerk & Policies • „Deny by default“ als Grundprinzip • Nur explizit erlaubte Verbindungen freigeschaltet • Keine ANY Regeln (Any Source, Any Destination, Any Service) • Identity-based Rules (Regeln basieren auf User-Gruppen, nicht nur IPs) • Regeln nach Least Privilege Prinzip • Regelwerk dokumentiert und versioniert • Regelwerk regelmäßig überprüft (mind. quartalsweise) • Alte oder ungenutzte Regeln entfernt • Regeln nach Zonen, Services und Verantwortlichkeiten strukturiert 3. Traffic Analyse & Inspektion • Deep Packet Inspection (DPI) aktiviert • TLS Inspection für relevante Verbindungen aktiviert • Intrusion Prevention System (IPS) aktiv • Virtual Patching (WAF/IPS schützt vor Lücken, für die es noch kein Software-Update gibt). • Malware Scanning aktiviert • Bot und Anomalie Erkennung aktiv • Geo Blocking (falls sinnvoll) • Rate Limiting für kritische Services 4. Web , API und Cloud Gateways • Web Application Firewall (WAF) für Web Anwendungen aktiv • API Gateway mit Auth, Rate Limit, Input Validation • Schutz vor OWASP API Top 10 • Cloud Firewalls (AWS/Azure/GCP) korrekt konfiguriert • Keine offenen Cloud Security Groups • CDN /Edge Security integriert (falls genutzt) 5. OT /ICS spezifische Firewall Sicherheit • OT Firewalls verstehen industrielle Protokolle (Modbus, OPC UA, S7) • Protokoll Whitelisting aktiv • Unidirektionale Gateways (Data Diodes) für kritische Systeme • Engineering Ports nur temporär freigeschaltet • Keine direkten Verbindungen zwischen IT und OT • OT Zonen nach IEC 62443 modelliert 6. Zugriffskontrolle & Administration • Administrationszugänge nur über Jump Server • MFA für alle Admin Zugänge • RBAC für Firewall Management • Änderungen nur über Change Management • Konfigurations Backups vorhanden • Firmware aktuell und signiert • Admin Sessions geloggt 7. Logging, Monitoring & SIEM • Zentrales Logging aller Firewall Events • Logs werden mindestens 12 Monate aufbewahrt • SIEM Integration vorhanden • Alerts für kritische Ereignisse (z. B. Port Scans, Blocked Traffic) • Anomalie Erkennung aktiv • Regelmäßige Auswertung der Logs • Forensik Daten vollständig 8. Tests & Qualitätssicherung • Regelmäßige Penetrationstests • Firewall Regelwerk wird automatisiert geprüft • Konfigurations Drift Erkennung aktiv • Notfall Szenarien getestet (Failover, Cluster Switch) • Testumgebung für Regeländerungen vorhanden • Regelmäßige Überprüfung der TLS Inspection 9. Dokumentation & Compliance • Vollständige Dokumentation der Firewall Topologie • Regelwerk dokumentiert und nachvollziehbar • Verantwortlichkeiten definiert • Audit Trails vorhanden • Konformität zu Standards geprüft, z.B. o NIS2 o ISO 27001 (A.8.20, A.8.16, A.5.17/18) o IEC 62443 (Zonen/Conduits, SR 3.x, SR 5.x, SR 7.x) o ISO 22301 (Schutz kritischer Systeme) 10. Typische Fehler, die vermieden werden müssen • Keine ANY Regeln • Keine offenen Ports „zur Sicherheit“ • Keine unüberwachten Remote Zugänge • Keine veralteten Firewall Versionen • Keine ungenutzten Regeln • Keine direkte IT ↔OT Kommunikation • Keine / fehlende TLS Inspection