Cyber Resilience Management

Wenn „compliant“ nicht automatisch „resilient“ heißt 

Viele Organisationen investieren viel Energie in Anforderungen aus Standards und Regulatorik – von ISO 27001 über IT-Grundschutz bis hin zu branchenspezifischen Vorgaben. Das Ergebnis sind Konzepte, Richtlinien, Notfallhandbücher und oft auch erfolgreich absolvierte Audits. Trotzdem zeigt die Praxis: Im Ernstfall entscheidet nicht die Dokumentation, sondern ob die Umgebung tatsächlich so aufgebaut und betrieben wird, wie es geplant war, und wie bei Abweichungen – durch bewusste Veränderungen oder unerwünschte Ereignisse – reagiert wird. Mit einer zielgerichteten Umsetzung von NIS2, DORA oder KRITIS verschiebt sich der Fokus zunehmend von der reinen Dokumentation hin zur nachweisbaren Wirksamkeit im laufenden Betrieb. 

Cyber Resilience Management setzt genau hier an: Es verbindet konzeptionelle Arbeit (Was muss erreicht werden?) mit der technischen und operativen Umsetzung (Wie bleibt die Umgebung dauerhaft in diesem Zustand und wie werden kritische digitale Services auch unter Cyberangriffen oder Störungen beherrschbar betrieben oder kontrolliert wiederhergestellt?). 

Warum Konzepte und Realität auseinanderlaufen 

 Philipp Kleinmanns, SVP Cyber Resilience Management bei Materna, macht deutlich: 

„Zwischen Konzept und Betrieb entsteht schnell eine Lücke. Vor allem dann, wenn Konfigurationen und Änderungen überwiegend manuell umgesetzt werden. Ohne Automatisierung und einen kontinuierlichen Soll-Ist-Abgleich ist nicht gesichert, dass die Infrastruktur dauerhaft in dem Zustand bleibt, der konzeptionell geplant war.“ 

• Manuelle Umsetzung: Je mehr Einstellungen händisch gesetzt werden, desto wahrscheinlicher sind Inkonsistenzen besonders unter Zeitdruck. 

• Configuration Drift: Selbst, wenn der Zielzustand einmal erreicht wurde, verändert sich die Umgebung kontinuierlich durch Patches, neue Systeme und neue Abhängigkeiten und entfernt sich schrittweise vom Konzept. 

• Komplexität durch zusätzliche Schichten: Virtualisierung, Container-Plattformen, Cloud-Services und APIs erhöhen die Zahl der Komponenten und damit die Stellen, an denen Abweichungen entstehen können. 

• Fehlende durchgängige Sicht: Klassisches Infrastruktur-Monitoring reicht nicht aus, wenn es nicht auch „Compliance-Fragen“ beantworten kann (z. B. Berechtigungen, Baselines, Härtungszustand). 

• Fehlende Steuerungslogik: Resilienz wird dokumentiert, aber nicht als dauerhaft zu steuernder Betriebszustand mit klaren Verantwortlichkeiten und Kennzahlen geführt. 

Die Ursache dieser Lücke ist dabei selten fehlende Technik, sondern fehlende Verantwortung für den Zielzustand im Betrieb. Solange niemand explizit dafür accountable ist, dass Systeme dauerhaft im definierten Zustand bleiben, entsteht Drift systematisch und unabhängig von der eingesetzten Technologie. Gerade beim Umgang mit Drift und Anomalien wird KI zunehmend relevant. Nicht als Zusatzfunktion, sondern als Bestandteil der Betriebssteuerung: Sie erweitert die Angriffsfläche, ermöglicht aber gleichzeitig, Abweichungen und Muster im laufenden Betrieb frühzeitig zu erkennen, zu priorisieren und Reaktionen zu automatisieren. Damit wird sie zu einem zentralen Hebel, um den Zielzustand nicht nur zu definieren, sondern auch kontinuierlich aufrechtzuerhalten.

Drei Hebel, die in der Praxis den Unterschied machen 

1) Automatisierung: Zielzustände wiederholbar herstellen (und halten) 

Wenn Resilienz im Betrieb funktionieren soll, muss der gewünschte Zustand der Umgebung nicht nur beschrieben, sondern technisch reproduzierbar sein. Automatisierung reduziert manuelle Fehler, beschleunigt Rollouts und ist ein wirksames Gegenmittel gegen Drift. 

• Baselines als Code: Härtungs- und Konfigurationsvorgaben so abbilden, dass sie automatisiert ausgerollt und versioniert werden können. 

• Changes standardisieren: Wiederkehrende Änderungen (z. B. Berechtigungen, Policies, Plattform-Settings) nach festem Muster umsetzen statt „individuell von Hand“. 

• Fehlerfolgen begrenzen: Gerade in großen Umgebungen (z. B. Arbeitsplatz- bzw. Client-Management) kann ein einzelner Konfigurationsfehler tausende Systeme betreffen. Automatisierung hilft, Änderungen kontrolliert, testbar und rückrollbar zu machen. 

• Automatisierung erfordert klare Governance, Versionierung und Ownership: Schlecht umgesetzte Automatisierung skaliert nicht nur Stabilität, sondern potenziell auch Fehler. 

2) Compliance-orientiertes Monitoring: Abweichungen sichtbar machen, bevor sie zum Risiko werden 

Klassisches Monitoring beantwortet meist die Frage: „Läuft das System?“ Für Resilienz ist zusätzlich wichtig: „Ist das System noch so konfiguriert, wie wir es vorgesehen haben?“ Genau hier setzt ein auf Compliance ausgerichtetes Monitoring an als kontinuierlicher Abgleich zwischen Konzept (Soll) und Betrieb (Ist), häufig als Continuous Controls Monitoring verstanden. 

• Konfiguration und Härtung: Sind Baseline-Settings umgesetzt (und nicht nachträglich aufgeweicht)? 

• Identitäten und Berechtigungen: Haben Personen oder Servicekonten Zugriffe, die sie nicht haben sollten (z. B. zu weitreichende Adminrechte)? 

• Abweichungen im Zeitverlauf: Wo entsteht Drift und welche Ereignisse waren der Auslöser? 

3) Ereignisse überwachen: Security Monitoring und Observability zusammendenken 

Neben dem „Zustand“ der Umgebung zählt das, was gerade passiert: ungewöhnliche Anmeldeereignisse, auffällige Zugriffe, Phishing-Wellen oder erste Anzeichen für eine Kompromittierung. Gleichzeitig können Verfügbarkeits- und Performanceprobleme Hinweise auf Störungen oder Angriffe liefern. Ein resilienzorientierter Betrieb betrachtet deshalb Security Monitoring und Observability nicht als getrennte Welten, sondern als komplementäre Sichten auf dieselben Services und Abhängigkeiten. 

• Security Monitoring: Logdaten und Events nutzen, um auch unscheinbare Sicherheitsvorfälle früh zu erkennen (z. B. unpassende Zugriffsrechte, ungewöhnliche Login-Muster). 

• Observability/Verfügbarkeit: Abhängigkeiten von Services sichtbar machen und Ausfälle bzw. Degradationen schnell lokalisieren, damit die Wiederherstellung nicht zur Suchaktion wird. 

• Gemeinsame Datengrundlage: Wenn Infrastruktur-Logs ohnehin zentral gesammelt werden, lohnt es sich, daraus sowohl Sicherheits- als auch Verfügbarkeitsindikatoren abzuleiten. 

Resilience by Design: Nicht nachträglich „dranflicken“ 

Philipp Kleinmanns beschreibt „Resilience by Design“ als konsequentes Vorausdenken: 

„Resilienz und Security sollten bereits beim Entwurf von Plattformen und Infrastrukturen berücksichtigt werden, statt im Nachhinein unter Druck mit Einzelmaßnahmen zu versuchen, eine Umgebung „irgendwie“ widerstandsfähiger zu machen.“ 

Im Kern geht es dabei nicht primär um Technik, sondern um den Schutz der Geschäfts- und Lieferfähigkeit: Ausfälle zu begrenzen, Wiederanlauf zu beherrschen und Entscheidungsfähigkeit zu sichern. Ausfälle zu in ihrer Reichweite begrenzen ist dabei auch eine Frage der Architektur: Klare Entkopplung, begrenzter Blast Radius und definierte Abhängigkeiten sind entscheidend, um im Ernstfall handlungsfähig zu bleiben. 

Ein wiederkehrendes Muster: Resilienz wird erst dann „aufgerufen“, wenn etwas schiefgeht. Effektiver ist es, sie von Beginn an mitzudenken – wie auch beim Secure Software Development. Das betrifft Infrastruktur- und Plattformentscheidungen (z. B. Hochverfügbarkeit, sinnvolle Entkopplung, klare Abhängigkeiten) genauso wie Security-Grundprinzipien und bewusste Architektur- und Investitionsentscheidungen. Wer Systeme so entwirft, dass Teilausfälle nicht sofort den gesamten Dienst lahmlegen, gewinnt im Ernstfall wertvolle Zeit. 

Rollen, Entscheidungswege, Ablageorte: Im Vorfall zählt jede Minute 

Technische Maßnahmen greifen im Vorfall nur, wenn auch die Organisation vorbereitet ist. Wer sich erst während eines Sicherheitsvorfalls oder einer Störung fragt, wer entscheidet, wer kommuniziert und wo die relevanten Dokumente liegen, verliert Zeit und erhöht die Schäden. Deshalb gehören klare Verantwortlichkeiten, Meldewege, Eskalationsstufen und ein funktionierendes Notfallmanagement (inkl. Business Continuity Management) zur Cyber Resilienz zwingend als geübte Praxis dazu. Wichtig ist auch der „Offline“-Gedanke: Was ist noch erreichbar, wenn zentrale Systeme oder übliche Kommunikationskanäle ausfallen? 

Vom Einmal-Projekt zum Kreislauf: Cyber Resilienz kontinuierlich betreiben 

Cyber Resilienz ist kein Zustand, den man einmal erreicht und dann „abhakt“. Neue digitale Dienste, neue Bedrohungen und Veränderungen in der Infrastruktur erzeugen laufend neue Risiken. Erfolgreiche Organisationen etablieren daher einen wiederkehrenden Prozess, der Konzept und Betrieb dauerhaft zusammenhält. Ziel ist es, Cyber Resilienz als steuerbaren Betriebszustand zu etablieren: 

1. Kritische Services und zugehörige Risiken identifizieren und priorisieren (Auswirkung, Abhängigkeiten, Toleranzen). 

2. Zielzustand definieren (Architektur, Baselines, Rollen, Notfallabläufe) – idealerweise als umsetzbare Standards. 

3. Automatisiert umsetzen – damit der Zielzustand reproduzierbar wird. 

4. Kontinuierlich überwachen – Zustand (Compliance) und Ereignisse (Security bzw. Observability). 

5. Verbessern und anpassen – Abweichungen beheben, Konzepte aktualisieren, neue Systeme automatisch aufnehmen (Discovery). 

Entscheidend ist dabei nicht die Anzahl erfüllter Controls, sondern ob Organisationen ihre Resilienz über Kennzahlen wie Kontrollabdeckung, Drift, Erkennungs- und Wiederherstellungszeiten aktiv steuern und verbessern können. 

Mini-Checkliste für den Start: Machen Sie Drift sichtbar (Ist/Soll), definieren Sie wenige klare Baselines, automatisieren Sie wiederkehrende Changes, schließen Sie Monitoring-Lücken (Compliance und Ereignisse) und testen Sie Notfallrollen und Kommunikationswege in Übungen nicht nur „fürs Audit“, sondern für den Ernstfall. 

• Risikobasiert starten: gemeinsam priorisieren, welche Szenarien den Geschäftsbetrieb am stärksten gefährden. 

• Zielbild und Roadmap: Soll-Architektur, Baselines und operative Anforderungen (inkl. Rollen und Notfallkonzept) in umsetzbare Schritte übersetzen. 

• Technisch wirksam umsetzen: Resilience by Design, Härtung und sauberes Identity- und Access-Management als Grundlage. 

• Dauerhaft betreiben: Compliance-orientiertes Monitoring, Security Monitoring und Observability verzahnen, damit Abweichungen und Vorfälle früh sichtbar werden. 

• Kontinuierlich verbessern: regelmäßige Reviews und Übungen, Aktualisierung von Dokumentation und Controls bei neuen Diensten und Risiken. 

• Lücke messbar machen: Transparenz über Abweichungen zwischen Zielbild und Betrieb (z. B. Baseline-Abdeckung, Drift, Wiederherstellungsfähigkeit kritischer Services).