ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

Ein Informationssicherheitsmanagementsystem (ISMS) kann viele Prozesse, Richtlinien und Sicherheitsmaßnahmen besitzen und trotzdem nicht wirksam sein.

Ein ISMS kann beispielsweise:

  • 100 % der Mitarbeiter geschult haben,
  • alle Richtlinien freigegeben haben,
  • regelmäßige Risikobewertungen durchführen,
  • Backups erstellen,
  • Schwachstellen überwachen und
  • zahlreiche technische Controls betreiben.

Doch daraus folgt noch nicht automatisch:

Die Informationssicherheitsziele werden tatsächlich erreicht.

Für die Bewertung der Wirksamkeit braucht es deshalb neben Aktivitäts- und Prozesskennzahlen auch Ergebnis- und Wirksamkeitsmetriken.

Dieser Artikel beschreibt ein pragmatisches Mindestmaß an Wirksamkeitszielen für ein ISMS.



1. KPI ist nicht gleich Wirksamkeitsnachweis

Ein wichtiger Grundsatz lautet:

Ein KPI zeigt, was gemessen wird. Ein Wirksamkeitsnachweis zeigt, ob das Sicherheitsziel tatsächlich erreicht wird.

Ein einfaches Beispiel:

Ziel: Mitarbeiter sollen Sicherheitsrisiken erkennen.

KPI:

98 % der Mitarbeiter haben die Awareness-Schulung absolviert.

Das ist eine gute Kennzahl für die Durchführung der Schulung.

Aber sie beantwortet noch nicht die Frage:

Haben die Mitarbeiter tatsächlich gelernt, Phishing und andere Angriffe zu erkennen?

Dafür wäre beispielsweise eine kontrollierte Phishing-Simulation wesentlich aussagekräftiger.

Die drei Ebenen

Eine sinnvolle Messlogik unterscheidet daher:

Aktivität / Control

Was haben wir getan?

KPI / Prozessleistung

Wie gut funktioniert unser Prozess?

Wirksamkeitsnachweis / Outcome

Erreichen wir damit tatsächlich unser Sicherheitsziel?

Diese Unterscheidung ist für ein wirksames ISMS entscheidend.



2. Ein pragmatisches Mindestset für das ISMS

Ein Unternehmen muss nicht hunderte Kennzahlen erheben.

Für eine grundlegende Wirksamkeitsbewertung reicht häufig ein überschaubares Set von 8 bis 10 zentralen Wirksamkeitszielen.

Die konkrete Auswahl hängt natürlich von Unternehmensgröße, Geschäftsmodell, Risiken und regulatorischen Anforderungen ab.

Das folgende Set kann jedoch als praktischer Ausgangspunkt dienen.



3. Mindestmaß an ISMS-Wirksamkeitszielen (Siehe detailierte Tabelle am Ende)

  • Vertraulichkeit wird wirksam geschützt
  • Integrität wird wirksam geschützt
  • Verfügbarkeit kritischer Services wird sichergestellt
  • Sicherheitsvorfälle werden rechtzeitig erkannt
  • Sicherheitsvorfälle werden wirksam behandelt
  • Wiederherstellung funktioniert
  • Schwachstellen werden wirksam beherrscht
  • Informationssicherheitsrisiken werden beherrscht
  • Lieferanten- und Drittparteirisiken werden beherrscht
  • Mitarbeiter können Sicherheitsrisiken wirksam erkennen


Diese Tabelle sollte nicht als universelle normative Mindestanforderung verstanden werden.

Sie ist vielmehr ein praxisorientiertes Mindestset, mit dem ein Unternehmen beginnen kann, die tatsächliche Wirksamkeit seines ISMS zu bewerten.



4. Vertraulichkeit: Haben wir tatsächlich Informationen geschützt?

Ein typisches ISMS misst beispielsweise:

  • MFA-Abdeckung
  • Berechtigungsüberprüfungen
  • DLP-Regeln
  • Verschlüsselungsquote
  • Anzahl blockierter Übertragungen

Diese Kennzahlen sind wichtig.

Sie zeigen jedoch hauptsächlich die Innensicht.

Für die Wirksamkeit interessiert zusätzlich die Außensicht:

Sind Informationen tatsächlich in unberechtigte Hände gelangt?

Beispiel

KPI:

98 % der privilegierten Konten verwenden MFA.

Metrik:

Anzahl erfolgreicher unberechtigter Zugriffe.

Wirksamkeitsnachweis:

  • Anzahl tatsächlicher Datenabflüsse
  • Anzahl betroffener Datensätze
  • Schutzbedarf der betroffenen Informationen
  • betroffene Kunden oder Geschäftspartner
  • tatsächlich überschrittene Vertrauensgrenzen

Damit wird aus einer technischen Kennzahl eine Aussage über die tatsächliche Wirkung.



5. Integrität: Wurden Informationen tatsächlich manipuliert?

Ein Unternehmen kann sehr gute Change-Management-Prozesse besitzen.

Das allein beweist noch nicht, dass die Integrität seiner Informationen geschützt ist.

KPI

Anteil kontrollierter Änderungen.

Metriken

  • Anzahl nicht autorisierter Änderungen
  • Anzahl erkannter Manipulationen
  • Zeit bis zur Erkennung
  • Anzahl betroffener Systeme oder Datensätze

Wirksamkeitsnachweis

Können unberechtigte oder unbeabsichtigte Veränderungen tatsächlich erkannt und aus einer vertrauenswürdigen Quelle vollständig wiederhergestellt werden?

Hier zeigt sich ein wichtiger Unterschied zwischen Kontrolle und Wirksamkeit.



6. Verfügbarkeit: Funktionieren die kritischen Services tatsächlich?

Eine Verfügbarkeitskennzahl von beispielsweise 99,9 % kann gut aussehen.

Für das Management ist jedoch entscheidend:

Welche Services waren tatsächlich betroffen und welche Auswirkungen hatte der Ausfall?

KPI

Verfügbarkeit kritischer Services.

Metriken

  • tatsächliche Ausfallzeit
  • Anzahl Ausfälle
  • Anzahl betroffener Nutzer
  • verlorene Transaktionen
  • Dauer der Geschäftsunterbrechung

Wirksamkeitsnachweis

Die tatsächliche Verfügbarkeit liegt innerhalb der für den Geschäftsprozess definierten Anforderungen und die Auswirkungen bleiben innerhalb akzeptierter Grenzen.



7. Erkennung von Sicherheitsvorfällen

Ein ISMS muss nicht nur Angriffe verhindern.

Es muss auch erkennen können, wenn Schutzmaßnahmen versagen.

KPI

Mean Time to Detect – MTTD

Metriken

  • Zeit zwischen Ereignis und Erkennung
  • Anteil innerhalb definierter Zeit erkannter Vorfälle
  • Anzahl unentdeckter oder verspätet erkannter Vorfälle

Wirksamkeitsnachweis

Ein tatsächlicher Sicherheitsvorfall wird innerhalb des definierten Zeitfensters erkannt.

Dabei ist Vorsicht bei einer scheinbar einfachen Kennzahl geboten:

„0 erkannte Vorfälle“ bedeutet nicht automatisch „0 Vorfälle“.

Es kann auch bedeuten, dass die Organisation einen Vorfall nicht erkannt hat.



8. Reaktion und Eindämmung

Die Erkennung allein reicht nicht.

Nach einem Sicherheitsvorfall muss die Organisation wirksam reagieren können.

KPI

Mean Time to Respond / Mean Time to Contain

Metriken

  • Zeit bis zur ersten Reaktion
  • Zeit bis zur Eindämmung
  • Zeit bis zur Beseitigung
  • Anteil innerhalb definierter Zielwerte behandelter Vorfälle

Wirksamkeitsnachweis

Die Organisation kann einen tatsächlichen Sicherheitsvorfall innerhalb der definierten Anforderungen wirksam eindämmen und seine Auswirkungen begrenzen.



9. Wiederherstellbarkeit: Funktionieren unsere Backups wirklich?

Hier zeigt sich besonders deutlich der Unterschied zwischen KPI und Wirksamkeitsnachweis.

KPI

99,8 % der geplanten Backups wurden erfolgreich durchgeführt.

Das ist eine wichtige Kennzahl.

Aber:

Ein erfolgreiches Backup ist noch kein erfolgreicher Restore.

Metriken

  • Restore-Testquote
  • erfolgreiche Restore-Tests
  • tatsächliche Wiederherstellungszeit
  • tatsächlicher Datenverlust
  • RTO-Erfüllung
  • RPO-Erfüllung

Wirksamkeitsnachweis

Ein kritisches System kann tatsächlich innerhalb des definierten RTO wiederhergestellt werden und der Datenverlust bleibt innerhalb des definierten RPO.

Damit wird aus:

„Wir haben Backups.“

die wesentlich wichtigere Aussage:

„Wir können unsere kritischen Informationen und Systeme tatsächlich wiederherstellen.“



10. Schwachstellenmanagement

Eine hohe Zahl behobener Schwachstellen bedeutet nicht automatisch, dass das Unternehmen gut geschützt ist.

Interessanter ist:

Werden die kritischen Schwachstellen rechtzeitig behandelt?

KPI

Anteil fristgerecht behandelter kritischer Schwachstellen.

Metriken

  • Anzahl kritischer Schwachstellen
  • Alter kritischer Schwachstellen
  • Zeit bis zur Behebung
  • Anteil außerhalb definierter Fristen
  • tatsächlich ausgenutzte Schwachstellen

Wirksamkeitsnachweis

Kritische Schwachstellen werden innerhalb der definierten Risikofrist behandelt oder es existieren dokumentierte und akzeptierte kompensierende Maßnahmen.



11. Risikomanagement

Ein ISMS soll nicht möglichst viele Risiken dokumentieren.

Es soll Informationssicherheitsrisiken wirksam beherrschen.

KPI

Anteil behandelter kritischer Risiken.

Metriken

  • Anzahl kritischer Risiken
  • Anteil innerhalb definierter Frist behandelter Risiken
  • Anzahl überfälliger Maßnahmen
  • Anzahl akzeptierter Restrisiken
  • Entwicklung des Gesamtrisikos

Wirksamkeitsnachweis

Das verbleibende Risiko liegt innerhalb der definierten Akzeptanzkriterien oder wurde durch die zuständigen Verantwortlichen bewusst akzeptiert.

Dabei ist eine wichtige Unterscheidung notwendig:

Ein geschlossenes Risiko-Ticket ist noch kein Beweis für eine wirksame Risikobehandlung.

Die entscheidende Frage lautet:

Hat sich das Risiko tatsächlich ausreichend reduziert?



12. Lieferanten- und Drittparteirisiken

Gerade bei Cloud-Diensten und ausgelagerten IT-Services kann die Informationssicherheit eines Unternehmens erheblich von externen Parteien abhängen.

KPI

Anteil kritischer Lieferanten mit aktueller Sicherheitsbewertung.

Metriken

  • Anteil bewerteter kritischer Lieferanten
  • Anzahl überfälliger Bewertungen
  • Anzahl kritischer Feststellungen
  • Anzahl Lieferanten-Sicherheitsvorfälle

Wirksamkeitsnachweis

Nicht nur:

„98 % der Lieferanten wurden bewertet.“

Sondern:

Sind kritische Abhängigkeiten tatsächlich angemessen beherrscht und haben Lieferantenereignisse keine unakzeptablen Auswirkungen auf unsere Informationssicherheit?



13. Awareness: Schulungsquote ist nicht gleich Wirksamkeit

Die klassische Kennzahl lautet:

100 % der Mitarbeiter haben an der Awareness-Schulung teilgenommen.

Das ist eine gute Teilnahmequote.

Aber sie sagt wenig darüber aus, ob Mitarbeiter tatsächlich sicherheitsbewusst handeln.

KPI

Awareness-Teilnahmequote.

Metriken

  • Teilnahmequote
  • Testergebnisse
  • Phishing-Klickrate
  • Melderate verdächtiger Nachrichten
  • Wiederholungsfehler

Wirksamkeitsnachweis

Mitarbeiter erkennen und melden relevante Sicherheitsereignisse in realistischen Situationen zuverlässig.

Damit wird aus:

„Mitarbeiter wurden geschult.“

die deutlich bessere Aussage:

„Mitarbeiter zeigen in realistischen Situationen das gewünschte Sicherheitsverhalten.“



14. Leading und Lagging Indicators

Die Unterscheidung zwischen Leading und Lagging Indicators kann die Systematik zusätzlich unterstützen.

Leading Indicators (Frühindikatoren)

Sie zeigen, ob die Organisation gute Voraussetzungen geschaffen hat.

Beispiele:

  • MFA-Abdeckung
  • Patch-Quote
  • Schulungsquote
  • Backup-Quote
  • Anteil bewerteter Lieferanten
  • Anteil behandelter Risiken

Lagging / Outcome Indicators (Spätindikatoren)

Sie zeigen, was tatsächlich passiert ist.

Beispiele:

  • erfolgreiche Datenabflüsse
  • tatsächliche Manipulationen
  • Ausfallzeiten
  • tatsächlicher Datenverlust
  • erfolgreiche Angriffe
  • tatsächlich ausgenutzte Schwachstellen
  • tatsächliche Lieferanten-Sicherheitsvorfälle

Eine gute Wirksamkeitsbewertung benötigt beide Perspektiven.

Denn:

Leading Indicators zeigen, ob wir vorbereitet sind. Outcome Indicators zeigen, ob diese Vorbereitung tatsächlich Wirkung zeigt.



15. Ein einfaches Mindest-Dashboard für das Management

Für ein Management-Review muss daraus kein Dashboard mit 100 Kennzahlen entstehen.

Ein kompaktes ISMS-Wirksamkeitsdashboard könnte beispielsweise folgende zehn Fragen beantworten:


Frage? Beispiel-Kennzahl

1. Werden vertrauliche Informationen tatsächlich geschützt?  erfolgreiche Datenabflüsse

2. Werden Informationen vor Manipulation geschützt? erfolgreiche Manipulationen

3. Sind kritische Services verfügbar? tatsächliche Ausfallzeit

4. Erkennen wir Angriffe schnell genug? MTTD

5. Reagieren wir schnell genug? MTTR / Containment Time

6. Können wir Systeme tatsächlich wiederherstellen? RTO-/RPO-Erfüllung

7. Beherrschen wir kritische Schwachstellen? fristgerechte Behebung

8. Reduzieren wir unsere wesentlichen Risiken? Entwicklung des Restrisikos

9. Beherrschen wir unsere Lieferantenrisiken? kritische Lieferantenrisiken

10. Verhalten sich Mitarbeiter tatsächlich sicher? Awareness-/Phishing-Ergebnis


Damit erhält das Management keine reine Aktivitätenliste, sondern eine Aussage darüber, ob das ISMS seine wesentlichen Ziele tatsächlich erreicht.

16. Der wichtigste Grundsatz

Bei der Auswahl von KPI und Metriken sollte immer die Frage gestellt werden:

„Wenn sich dieser Wert verbessert, wissen wir dann wirklich, dass unsere Informationssicherheit besser geworden ist?“

Wenn die Antwort „Nein“ lautet, handelt es sich möglicherweise lediglich um eine Aktivitäts- oder Prozesskennzahl.

Das bedeutet nicht, dass solche KPI nutzlos sind.

Sie sind wichtig für die Steuerung.

Sie sollten aber nicht mit einem Wirksamkeitsnachweis verwechselt werden.



17. Von KPI zur Wirksamkeit

Die vollständige Logik lässt sich damit sehr einfach darstellen:

·      Informationssicherheitsziel

·      Sicherheitsanforderung

·      Control / Maßnahme

·      Prozessziel

·      KPI

·      Metrik

·      Wirksamkeitsnachweis

·      Managementbewertung

Ein Beispiel:

·      Ziel: Vertraulichkeit
Anforderung: Nur Berechtigte dürfen auf vertrauliche Daten zugreifen
Control: MFA + Rollenberechtigungen + DLP
Prozessziel: Berechtigungen werden korrekt verwaltet
KPI: Anteil fristgerecht geprüfter Berechtigungen
Metrik: erfolgreiche unberechtigte Zugriffe
Wirksamkeitsnachweis: keine bzw. akzeptable tatsächliche Datenoffenlegung
Managementbewertung: Ziel erreicht / teilweise erreicht / nicht erreicht

Fazit

Ein wirksames ISMS benötigt nicht möglichst viele Kennzahlen.

Es benötigt die richtigen Kennzahlen.

Ein sinnvolles Mindestmaß sollte deshalb mindestens die folgenden Fragen beantworten:

  1. Sind Informationen vertraulich?
  2. Bleiben Informationen integer?
  3. Sind kritische Services verfügbar?
  4. Erkennen wir Sicherheitsvorfälle rechtzeitig?
  5. Können wir wirksam reagieren?
  6. Können wir tatsächlich wiederherstellen?
  7. Beherrschen wir kritische Schwachstellen?
  8. Reduzieren und beherrschen wir unsere wesentlichen Risiken?
  9. Beherrschen wir kritische Drittparteirisiken?
  10. Zeigen Mitarbeiter tatsächlich das erwartete Sicherheitsverhalten?

Der entscheidende Unterschied liegt dabei zwischen „Wir haben etwas getan“ und „Es wirkt“.

Nicht nur messen, ob das ISMS arbeitet – messen, ob es wirkt.

Das ist letztlich der Kern einer wirksamen Informationssicherheitssteuerung.


Nr. Wirksamkeitsziel KPI Metrik Wirksamkeitsnachweis
1 Vertraulichkeit wird wirksam geschützt Unberechtigte Zugriffe Anzahl erfolgreicher unberechtigter Zugriffe / Datenabflüsse Keine bzw. akzeptable Anzahl tatsächlicher Vertraulichkeitsverletzungen; Umfang und Schutzbedarf der betroffenen Informationen werden bewertet
2 Integrität wird wirksam geschützt Manipulationsvorfälle Anzahl erfolgreicher unberechtigter Änderungen Tatsächlich manipulierte Daten/Systeme und Fähigkeit zur vollständigen Wiederherstellung aus einer vertrauenswürdigen Quelle
3 Verfügbarkeit kritischer Services wird sichergestellt Verfügbarkeit / Ausfallzeit tatsächliche Ausfallzeit kritischer Services Tatsächliche Verfügbarkeit und tatsächliche Geschäftsbeeinträchtigung
4 Sicherheitsvorfälle werden rechtzeitig erkannt Detection Performance MTTD / Zeit bis zur Erkennung Tatsächliche Vorfälle werden innerhalb definierter Zeit erkannt
5 Sicherheitsvorfälle werden wirksam behandelt Response Performance MTTR / Zeit bis zur Eindämmung oder Wiederherstellung Vorfälle werden innerhalb definierter Zielwerte eingedämmt und ihre Auswirkungen begrenzt
6 Wiederherstellung funktioniert RTO-/RPO-Erfüllung % erfolgreicher Recovery Tests innerhalb Zielwert Ein tatsächlicher oder simulierter Restore erreicht den definierten vertrauenswürdigen Zustand
7 Schwachstellen werden wirksam beherrscht Fristgerechte Behebung % kritischer Schwachstellen innerhalb definierter Frist Kritische Schwachstellen werden vor Ausnutzung oder innerhalb akzeptierter Restfristen wirksam behandelt
8 Informationssicherheitsrisiken werden beherrscht Behandlung kritischer Risiken Anzahl / Anteil kritischer unbehandelter Risiken Risiken liegen innerhalb der definierten Akzeptanzkriterien oder sind angemessen behandelt
9 Lieferanten- und Drittparteirisiken werden beherrscht Bewertungs-/Behandlungsquote % kritischer Lieferanten mit aktueller Bewertung Tatsächliche Sicherheitsvorfälle und Auswirkungen aus kritischen Lieferantenbeziehungen bleiben innerhalb akzeptierter Grenzen
10 Mitarbeiter können Sicherheitsrisiken wirksam erkennen Awareness-Wirksamkeit Fehlerquote bei Phishing-/Awareness-Tests Verhalten in realistischen oder simulierten Situationen zeigt eine ausreichende Erkennungs- und Reaktionsfähigkeit

Konstantin Ziouras Blog Artikel

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
Risiken bezüglich Lieferanten
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
von Konstantin Ziouras • 14. April 2026
Docker ist eine Technologie, mit der Software in Container verpackt wird. Ein Container ist wie eine kleine, abgeschlossene Box, in der alles drin ist, was ein Programm zum Laufen braucht: die Anwendung selbst Bibliotheken Konfigurationen Systemabhängigkeiten Dadurch läuft die Software überall gleich, egal ob: auf einem Laptop in der Cloud auf einem Server in einem Rechenzentrum Docker löst das klassische Problem „Bei mir läuft’s, bei dir nicht“ vollständig. Warum Container? Weil klassische Software oft abhängig ist von: • bestimmten Versionen von Bibliotheken • bestimmten Betriebssystemen • bestimmten Konfigurationen Container isolieren diese Abhängigkeiten — wie ein eigenes Mini System. Wie funktioniert Docker technisch? Docker nutzt Containerisierung, nicht Virtualisierung. Virtual Machine (VM) enthält ein komplettes Betriebssystem braucht viel Speicher startet langsam Docker Container nutzt das Host Betriebssystem mit ist extrem leichtgewichtig startet in Sekundenbruchteilen Technisch basiert Docker auf: Namespaces (Isolation) cgroups (Ressourcenbegrenzung) Union File Systems (schichtbasierte Images) Woraus besteht Docker? 1. Docker Image Ein Image ist eine Bauvorlage für Container. Beispiel: „Webserver Image“, „Python App Image“. 2. Docker Container Ein laufendes Exemplar eines Images. Beispiel: „Webserver Container läuft jetzt auf Port 80“. 3. Dockerfile Eine Textdatei, die beschreibt, wie ein Image gebaut wird. 4. Docker Engine Die Software, die Container startet und verwaltet. 5. Docker Hub Eine Art „App Store“ für fertige Images. Wofür wird Docker genutzt? 1. Softwareentwicklung Entwickler können identische Umgebungen nutzen. 2. DevOps & CI/CD Automatisierte Builds, Tests und Deployments. Ein Entwickler kann per Knopfdruck eine komplexe Datenbank-Umgebung starten, ohne sie lokal installieren zu müssen. Automatisches Testen von Code in einer sauberen Umgebung. 3. Microservices Jeder Service läuft in seinem eigenen Container. Statt einer riesigen, schweren Software nutzt man 20 kleine Container, die miteinander kommunizieren. 4. Cloud Betrieb Container sind perfekt für AWS, Azure, GCP. 5. Skalierung Container können automatisch hoch und runtergefahren werden. Sicherheitsaspekte (für Nicht Admins) Container sind isoliert, aber teilen sich den Kernel. Das bedeutet: • sie sind sicherer als klassische Apps • aber weniger isoliert als VMs Wichtige Sicherheitsmechanismen: Signierte Images Trusted Registries Schwachstellenscans (z.B. mit Trivy, Clair) Least Privilege (keine Root Container)