Was die Auseinandersetzung mit Security Incidents an meinem Blick auf Architektur, Betrieb und Managed Services verändert hat.
Ich beschäftige mich beruflich schon ziemlich lange mit Netzwerken, Security, Automatisierung und Managed Services. Firewalls, Segmentierung, Logging, Monitoring, Schwachstellen, Policies, SIEM, SOC – alles keine neuen Themen. Und natürlich weiß man, dass Systeme kompromittiert werden können. Das steht in jedem Security-Konzept. Man plant dafür, bewertet Risiken, baut Schutzmaßnahmen und definiert Prozesse.
Trotzdem gibt es einen Unterschied zwischen Security auf einem Architekturdiagramm und Security in dem Moment, in dem man einem System nicht mehr vertrauen kann.
Eine Frage ist mir dabei besonders hängen geblieben:
Wann ist ein kompromittiertes System eigentlich wieder sauber?
Klingt erstmal nach einer relativ einfachen Frage.
Ist es aber überhaupt nicht.
„Wir haben nichts mehr gefunden“ heißt nicht automatisch „sauber“
Nehmen wir ein bewusst abstraktes Beispiel.
Wir wissen, dass jemand administrativen Zugriff auf ein System hatte, den er nicht haben sollte. Der Zugriff ist inzwischen geschlossen, das offensichtliche Artefakt entfernt und die Schwachstelle behoben. Die Logs zeigen nichts Auffälliges mehr.
Ist das System jetzt wieder sauber?
Vielleicht.
Aber was ist mit der Konfiguration? Wurden Benutzer angelegt oder Berechtigungen verändert? Was ist mit Credentials, Zertifikaten und Schlüsseln? Was ist mit angebundenen Systemen? Was ist mit Automationen, über die dieses System wiederum andere Systeme verändern darf?
Und irgendwann landet man bei der eigentlich schwierigen Frage:
Woher weiß ich überhaupt, wie der Zustand aussah, dem ich zuletzt sicher vertrauen konnte?
Diese Fragen sind für mich nicht theoretisch.
Genau an diesem Punkt wird aus „wir haben nichts mehr gefunden“ etwas völlig anderes als „wir wissen, dass es sauber ist“.
Und genau da hat sich mein Blick auf Security verändert.
Vertrauen ist ein technisches Thema
Security habe ich lange sehr stark als Schutzfunktion betrachtet.
Wie verhindere ich einen Angriff? Welche Kommunikation ist erlaubt? Welche Ports sind offen? Welche Schwachstellen existieren? Welche Systeme müssen gepatcht werden? Wie weit reichen Berechtigungen?
Das bleibt alles richtig und wichtig.
Nur endet Security für mich heute nicht mehr dort.
Denn wenn die erste Verteidigung einmal nicht gereicht hat, muss ich erkennen können, was passiert ist. Ich muss verstehen können, was verändert wurde. Ich muss den möglichen Wirkungsradius begrenzen können. Ich muss einen definierten Zustand wiederherstellen können.
Und anschließend muss irgendjemand eine Entscheidung treffen:
Vertrauen wir diesem Zustand wieder?
Dafür gibt es keinen grünen Haken.
Auch nicht auf einem Dashboard mit 27 davon.
Es gibt Evidenz, technische Bewertung, Risikoabwägung und irgendwann eine Entscheidung.
Prevent. Observe. Contain. Restore. Trust.
Das ist für mich inzwischen ein hilfreiches Denkmodell, wenn ich auf Architekturen und Plattformen schaue.
Prevent: Wie verhindere ich einen Angriff oder reduziere zumindest seine Wahrscheinlichkeit und seinen möglichen Impact?
Das ist die klassische Security-Welt: Hardening, Patching, Segmentierung, Least Privilege, MFA und vieles mehr.
Observe: Kann ich wirklich nachvollziehen, was in meinem System passiert?
Damit meine ich nicht nur CPU, RAM und „Service available“. Mich interessieren administrative Zugriffe, Konfigurationsänderungen, Kommunikation, Identitäten und die Frage, ob die Informationen lange genug und unabhängig genug verfügbar sind, um sie im Zweifel noch nutzen zu können.
Contain: Was passiert, wenn ich einem Teil meiner Umgebung nicht mehr vertraue?
Wie weit reichen Berechtigungen? Sind administrative Identitäten getrennt? Kann ich Systeme voneinander isolieren? Und was bedeutet es eigentlich, wenn eine zentrale Managementplattform selbst betroffen ist und genau diese Plattform Zugriff auf hunderte andere Systeme hat?
Restore: Wie komme ich zu einem definierten Zustand zurück?
Habe ich Backups? Versionierte Konfigurationen? Known-Good-States? Kann ich neu aufbauen? Credentials und Schlüssel rotieren? Und weiß ich überhaupt, welchen Zustand ich wiederherstellen möchte?
Und dann kommt für mich der entscheidende Punkt:
Trust: Welche Evidenz brauche ich, um anschließend zu sagen: Diesem Zustand vertraue ich wieder genug, um ihn produktiv zu betreiben?
Haben wir dafür nicht schon NIST?
Natürlich ist die Grundidee nicht neu.
Das NIST Cybersecurity Framework 2.0 beschreibt mit Govern, Identify, Protect, Detect, Respond und Recover einen wesentlich umfassenderen und etablierten Rahmen für Cybersecurity Risk Management.
Mein kleines Modell soll das nicht ersetzen. Im Gegenteil.
Prevent, Observe, Contain und Restore sind bewusst eine vereinfachte Sicht auf Fragestellungen, die sich in unterschiedlichen Teilen solcher etablierten Frameworks wiederfinden.
Interessant ist für mich das Trust danach.
„Recover“ beantwortet die Frage, wie betroffene Systeme und Betriebsabläufe wiederhergestellt werden. Für den Betreiber bleibt anschließend aber noch eine andere, ziemlich menschliche Frage:
Wann reicht mir die vorhandene Evidenz, um diesem wiederhergestellten Zustand tatsächlich zu vertrauen?
Das ist keine zusätzliche NIST-Funktion und soll auch keine sein.
Es ist eher die Frage, die ich heute an das Ende von Recovery setzen würde.
Denn „läuft wieder“ und „ich vertraue dem Zustand wieder“ sind für mich zwei unterschiedliche Aussagen.
Ein Managed Service zeigt sich am schlechten Tag
Dieser Gedanke verändert auch meinen Blick auf Managed Services.
Ein Kunde kauft nicht einfach einen Controller, einen Router, eine Firewall oder irgendeine Cloud-Plattform. Er kauft implizit das Versprechen, dass jemand das Gesamtsystem im Griff hat.
Solange alles funktioniert, fällt dieses Versprechen kaum auf.
Interessant wird es, wenn etwas nicht funktioniert. Oder schlimmer: wenn niemand sicher sagen kann, ob noch alles so funktioniert, wie es sollte.
Dann werden plötzlich andere Fragen wichtiger als die Featureliste aus der Ausschreibung.
Wer übernimmt die Führung? Wer hat Zugriff auf welche Informationen? Wer kennt die Abhängigkeiten? Wer darf Entscheidungen treffen? Wer spricht mit Herstellern, wer mit Kunden? Und wer entscheidet am Ende, wann ein System wieder als vertrauenswürdig gilt?
Was ich hier beschreibe, ist im CSF-Sprech im Wesentlichen Govern: Strategie, Erwartungen, Verantwortlichkeiten und Entscheidungswege müssen festgelegt sein, bevor man sie braucht. Genau deshalb gehört das für mich nicht erst ins Betriebshandbuch, sondern bereits in die Architektur eines Managed Service.
Denn während eines Incidents lässt sich das alles nicht nebenbei organisieren.
Zumindest nicht gut.
Automatisierung skaliert. Leider alles.
Ich bin großer Freund von Automatisierung. Wenn etwas reproduzierbar automatisiert werden kann, sollte man aus meiner Sicht ziemlich gut begründen können, warum es noch jemand manuell macht.
Aber Automatisierung skaliert eben nicht nur gute Prozesse.
Eine falsche Änderung auf einem Gerät ist ärgerlich.
Eine falsche automatisierte Änderung auf hunderten Geräten ist ein Feature mit beeindruckender Reichweite.
Das Gleiche gilt für kompromittierte Identitäten oder Systeme mit weitreichenden Berechtigungen.
Je zentraler und mächtiger eine Plattform wird, desto wichtiger werden deshalb Least Privilege, Rollentrennung, nachvollziehbare Änderungen und unabhängige Kontrollmechanismen.
Vor allem möchte ich bei einer Automation nicht nur wissen, dass sie etwas getan hat. Ich möchte nachvollziehen können, warum sie es getan hat, wodurch sie ausgelöst wurde, was sie verändert hat und mit welchem Ergebnis.
Automatisierung ohne Observability ist für mich deshalb keine vollständige Automatisierung.
Und dann gibt es noch den Lifecycle
Security verlangt schnelle Updates. Stabiler Betrieb verlangt gründliche Tests. Beides stimmt.
Gerade bei zentralen Plattformen ist eine Änderung aber eben nicht nur eine Änderung an dieser Plattform. APIs können sich ändern, abhängige Funktionen können sich anders verhalten und Monitoring kann im schlechtesten Fall genau die Information verlieren, die man später gebraucht hätte.
Und damit landen wir wieder beim Vertrauen.
Wenn sich eine Plattform verändert, muss ich wissen, ob mein bisheriger Known-Good-State überhaupt noch der Zustand ist, für den ich ihn halte.
Deshalb gehören für mich Testumgebungen, definierte Abnahmekriterien, Monitoring nach Änderungen und Rollback-Möglichkeiten genauso zu Security und Resilienz wie das eigentliche Update.
Ein erfolgreich installiertes Update ist noch lange kein erfolgreich abgeschlossenes Change.
Wenn danach eine für den Betrieb wichtige Funktion nicht mehr arbeitet und niemand es bemerkt, war das Update technisch vielleicht erfolgreich.
Der Service war es nicht.
Die schwierigsten Fragen stehen in keinem Runbook
Prozesse helfen. Runbooks helfen. Vorbereitung hilft.
Aber irgendwann entstehen Fragen, auf die kein Dokument eine fertige Antwort liefert.
Wie viel Evidenz reicht uns? Welche Annahmen dürfen wir treffen? Wann ist ein Risiko vertretbar? Wann bauen wir neu auf, statt weiter zu analysieren? Und wann sind wir bereit, einem System wieder zu vertrauen?
Irgendwann müssen Menschen diese Entscheidungen treffen – mit unvollständigen Informationen, unter Zeitdruck und mit technischen, wirtschaftlichen und möglicherweise regulatorischen Auswirkungen.
Vielleicht ist Incident Response deshalb für mich heute mindestens genauso ein Organisations- wie ein Security-Thema.
Die Technik liefert Informationen. Die Organisation muss daraus Entscheidungen machen.
Und eine gute Architektur sorgt hoffentlich dafür, dass dafür überhaupt die richtigen Informationen vorhanden sind.
Security oder Resilienz?
Security habe ich früher stärker als Schutz verstanden.
Heute denke ich mehr in der gesamten Kette:
Prevent. Observe. Contain. Restore. Trust.
Man kann sehr viel Geld für Security-Produkte ausgeben. Man kann sehr viele Kontrollen einführen. Und man kann ziemlich beeindruckende Architekturdiagramme malen.
Der eigentliche Test findet an einem schlechten Tag statt.
Dann zeigt sich, ob man nur Security gebaut hat.
Oder Resilienz.