Sicherheit im Betrieb: Logging, Erkennung und Reaktion

Sicherheit endet nicht mit dem Deployment

Die früheren Abschnitte dieses Kapitels zielen darauf, Angriffe zu verhindern. Keine Prävention ist perfekt, daher entwerfen reife Organisationen auch unter der Annahme, dass eine Sicherheitsverletzung passieren wird: Sie wollen sie schnell bemerken, ihren Schaden begrenzen, sauber wiederherstellen und daraus lernen. Kapitel 2 beschrieb die Sicherheitstaktiken als Widerstehen, Erkennen, Reagieren und Wiederherstellen und zeigte, wie man Sicherheitsszenarien mit messbaren Reaktionen schreibt, etwa ein abgeflossener Zugangsschlüssel wird innerhalb von 15 Minuten erkannt und widerrufen. Dieser Abschnitt behandelt die Architektur und die Praktiken, die solche Reaktionen erreichbar machen.

Vieles davon baut auf den betrieblichen Grundlagen von Observability und Incident-Management in Kapitel 9 auf. Der Unterschied ist der Gegner: Eine ausfallende Festplatte verwischt keine Spuren, löscht nicht ihre Logs und kommt nicht nächste Woche durch eine Tür zurück, die sie offen gelassen hat.

Sicherheits-Logging: was protokolliert wird und was nie

Sicherheitslogs sollen im Nachhinein beantworten, wer was mit welcher Ressource getan hat, wann, von wo und mit welchem Ergebnis. Das OWASP Logging Cheat Sheet ist die Standardreferenz für die Praxis. Es empfiehlt, Ereignisse wie erfolgreiche und fehlgeschlagene Authentifizierungen, Autorisierungsfehler, Fehler im Sitzungsmanagement, Fehler bei der Eingabevalidierung, Anwendungsfehler, Hochrisikofunktionen wie administrative Aktionen und Datenexporte sowie die Nutzung der Sicherheitskontrollen selbst festzuhalten. Jedes Ereignis sollte wann (ein synchronisierter Zeitstempel), wo (Anwendung, Service, Host, Umgebung), wer (die authentifizierte Identität, die Quelladresse) und was (die Aktion, das Objekt, das Ergebnis und der Grund) enthalten.

Ebenso wichtig ist, was draußen bleiben muss. Logs werden weit kopiert, lange aufbewahrt und von vielen Menschen und Tools gelesen, daher sind sie ein beliebter Ort, aus dem Secrets und personenbezogene Daten abfließen. Protokollieren Sie nie Passwörter, Sitzungskennungen oder Access Tokens (protokollieren Sie einen Hash oder eine Key-ID, wenn Sie korrelieren müssen), Verschlüsselungsschlüssel und Verbindungszeichenfolgen, Zahlungskartendaten oder personenbezogene Daten besonderer Kategorien. Behandeln Sie Logdaten als personenbezogene Daten, wo sie Personen identifizieren, und wenden Sie die Minimierungs- und Aufbewahrungsregeln aus Abschnitt 8.7 an. Schwärzung wird am besten zentral in der Log-Pipeline und zusätzlich im Code durchgesetzt, weil eine einzige vergessene Debug-Anweisung sie aushebeln kann.

{
  "ts": "2026-10-21T19:42:07.318Z",
  "event": "authz.denied",
  "service": "orders",
  "env": "prod",
  "actor": {"type": "user", "id": "cust_4411", "session": "sha256:7c1e..."},
  "client": {"ip": "203.0.113.24", "ua_family": "iOS app 7.3"},
  "action": "GET /orders/81723",
  "resource_owner": "cust_9902",
  "reason": "not_owner",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Logs müssen auch vor Angreifern geschützt werden, deren erster Schritt nach dem Eindringen oft darin besteht, die Beweise zu löschen. Senden Sie Sicherheitslogs zeitnah an ein getrenntes Konto oder einen getrennten Dienst, den die eigenen Zugangsdaten der Anwendung nicht ändern können; speichern Sie sie mit Write-once-Aufbewahrung; beschränken und protokollieren Sie den Zugriff darauf; und halten Sie Uhren synchron, damit Ereignisse aus verschiedenen Systemen zusammenpassen. Behandeln Sie Log-Inhalte als nicht vertrauenswürdige Eingaben: Ein Angreifer, der einen Zeilenumbruch in ein protokolliertes Feld einschleusen kann, kann gefälschte Einträge erzeugen (Log-Injection); kodieren oder verwerfen Sie daher Steuerzeichen und denken Sie daran, dass Log4Shell durch das Protokollieren von angreiferkontrolliertem Text ausgelöst wurde.

Audit-Trails

Ein Audit-Trail ist eine engere, strengere Art von Log: eine vollständige, chronologische, manipulationssichtbare Aufzeichnung festgelegter Aktionen, die geführt wird, um Rechenschaft herzustellen. Debug-Logs werden gesampelt, rotiert und geändert, wann immer Entwickler es wollen; ein Audit-Trail muss für seinen Geltungsbereich vollständig sein (jede Erstattung, jede Rollenänderung, jeder Zugriff auf den Support-Datensatz eines Kunden), unveränderlich, einer authentifizierten Identität zurechenbar und für einen festgelegten Zeitraum aufbewahrt. Vorschriften und Standards verlangen oft einen; PCI DSS etwa verlangt, die Audit-Log-Historie mindestens zwölf Monate aufzubewahren, wobei die letzten drei Monate sofort für Analysen verfügbar sein müssen.

Architektonisch sollten Sie den Audit-Trail als Produkt der Domäne entwerfen, nicht als Nebenprodukt des Loggings. Geben Sie Audit-Events von dem Service aus, dem die Aktion gehört, und zwar in dem Moment, in dem die Aktion committet wird (die Transactional Outbox garantiert, dass entweder beides geschieht oder keines), in einen Append-only-Speicher mit eingeschränktem Schreibzugriff. Manipulationssichtbarkeit lässt sich durch Hash-Verkettung erreichen, bei der jeder Datensatz einen Hash des vorherigen enthält, oder indem regelmäßig ein signierter Digest anderswo verankert wird. Event-Sourcing-Systeme bekommen vieles davon geschenkt, wie Abschnitt 7.5 gezeigt hat. Die Control-Plane-Audit-Logs der Cloud-Anbieter, die jeden API-Aufruf an das Cloud-Konto aufzeichnen, gehören zum selben Bild und müssen in jedem Konto und jeder Region aktiviert sein.

Erkennung: SIEM, Regeln und Reaktionsautomatisierung

Ein Security-Information-and-Event-Management-System (SIEM) sammelt Sicherheitstelemetrie aus der gesamten IT-Landschaft, normalisiert sie, korreliert Ereignisse und löst Alarme aus, wenn Muster zu Erkennungsregeln passen: viele fehlgeschlagene Anmeldungen, gefolgt von einer erfolgreichen, ein Servicekonto, das aus einem neuen Land genutzt wird, eine Rolle, die außerhalb eines Änderungsfensters Administratorrechte erhält, ein großer Export um drei Uhr morgens. Typische Quellen sind das API-Gateway, Sicherheitsereignisse der Anwendungen, der Identity Provider, Cloud-Audit-Logs, Kubernetes-Audit-Logs und Agents für Endpoint Detection and Response (EDR) auf Laptops und Servern der Mitarbeitenden.

Gute Erkennung wird entwickelt, nicht gekauft. Leiten Sie Regeln aus dem Bedrohungsmodell und aus MITRE ATT&CK ab, einer öffentlichen Wissensbasis über Taktiken und Techniken realer Angreifer, die MITRE seit 2015 pflegt; schreiben Sie sie als Code in einem gemeinsamen Format wie Sigma, versionieren Sie sie und testen Sie sie, indem Sie den Angriff simulieren, den sie erkennen sollen. Messen Sie die Alarmqualität: Eine Regel, die fünfzigmal am Tag auslöst und immer harmlos ist, bringt Menschen bei, sie zu ignorieren, und über Alarmmüdigkeit werden echte Angriffe übersehen. Günstige Stolperdrähte mit starkem Signal helfen: Honeytokens, etwa ein gefälschter Zugangsschlüssel oder ein gefälschter Kundendatensatz, den kein legitimer Prozess je anfasst, erzeugen fast keine Fehlalarme. Tools für Security Orchestration, Automation and Response (SOAR) führen dann Playbooks für gut verstandene Alarme aus, etwa einen Benutzer deaktivieren, einen Schlüssel widerrufen oder einen Container isolieren, sodass Menschen sich um die Ermessensentscheidungen kümmern.

Die Aufnahme ins SIEM wird oft nach Volumen abgerechnet, was Teams dazu verleitet, Logs wegzulassen. Ein gestuftes Design hilft: Wertvolle Sicherheitsereignisse gehen zur Echtzeiterkennung ins SIEM; umfangreiche Logs gehen in günstigeren Write-once-Speicher, wo sie während einer Untersuchung durchsucht werden können.

Schwachstellenmanagement

Jeden Tag werden neue Schwachstellen in der Software veröffentlicht, die Sie betreiben. Eine CVE-Kennung (Common Vulnerabilities and Exposures) wie CVE-2021-44228 gibt jeder öffentlich bekannten Schwachstelle einen eindeutigen Namen; das 1999 von MITRE gestartete Programm vergibt Kennungen über Hunderte von CVE Numbering Authorities, darunter große Hersteller und Open-Source-Stiftungen. Die US National Vulnerability Database ergänzt Analysen wie Kennungen der betroffenen Produkte und Bewertungen, doch ein Rückstau bei dieser Anreicherung ab 2024 und ein kurzer Schreck im April 2025, als der Vertrag zur Finanzierung des CVE-Programms beinahe auslief, zeigten das Risiko, von einer einzigen Quelle abzuhängen; die meisten Organisationen kombinieren heute mehrere Quellen, darunter die Advisory-Datenbank von GitHub und die Open-Source-Datenbank OSV.

CVSS (das Common Vulnerability Scoring System, gepflegt von FIRST; Version 4.0 erschien im November 2023) bewertet den Schweregrad von 0 bis 10, mit den Stufen niedrig (0,1 bis 3,9), mittel (4,0 bis 6,9), hoch (7,0 bis 8,9) und kritisch (9,0 bis 10,0). Der veröffentlichte Basiswert beschreibt die Schwachstelle allgemein; die Threat- und Environmental-Metriken von Version 4.0 passen ihn an die Ausnutzungsaktivität und an Ihre eigene Umgebung an. Ein Basiswert ist kein Maß für Ihr Risiko. Zwei Signale verbessern die Priorisierung erheblich: das Exploit Prediction Scoring System (EPSS, ebenfalls von FIRST), das die Wahrscheinlichkeit schätzt, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird, und der Katalog der Known Exploited Vulnerabilities (KEV) der US Cybersecurity and Infrastructure Security Agency, der Schwachstellen mit Belegen für eine reale Ausnutzung auflistet. Kombinieren Sie sie mit Erreichbarkeit (wird die verwundbare Funktion genutzt?) und Exposition (ist der Service aus dem Internet erreichbar?), und die meisten der Hunderte von Befunden eines Scanners landen in der Routinewarteschlange, während eine Handvoll noch heute Handeln verlangt.

Vereinbaren Sie Behebungsziele im Voraus, damit nicht jeder Befund zur Verhandlung wird, und messen Sie die Zeit bis zur Behebung. Die Werte unten sind typische Beispiele, kein Standard; regulierte Umgebungen können eigene vorgeben, PCI DSS etwa verlangt, kritische Sicherheitspatches innerhalb eines Monats nach Erscheinen zu installieren.

Penetrationstests, Bug-Bounties und Offenlegung

Ein Penetrationstest ist ein autorisierter, zeitlich begrenzter Versuch erfahrener Tester, in ein System einzudringen, idealerweise mit Kenntnis seiner Architektur und mit einem schriftlich vereinbarten Umfang. Er findet Klassen von Problemen, die Scanner übersehen, etwa fehlerhafte Autorisierung auf Objektebene und Missbrauch der Geschäftslogik (denselben Gutschein über eine Race Condition zweimal einlösen). Beauftragen Sie einen vor einem großen Launch, nach erheblichen Architekturänderungen und regelmäßig; eine Red-Team-Übung geht weiter und testet Erkennung und Reaktion, indem sie über Wochen einen echten Gegner simuliert.

Externe Forschende werden ebenfalls Probleme finden und brauchen einen sicheren Weg, sie zu melden. Eine Vulnerability Disclosure Policy legt fest, wie gemeldet wird, welche Tests erlaubt sind und dass auf Forschung in gutem Glauben nicht mit rechtlichen Drohungen reagiert wird; eine Datei security.txt unter /.well-known/security.txt (RFC 9116, 2022) sagt Forschenden, wohin sie Meldungen schicken sollen. Ein Bug-Bounty ergänzt eine Bezahlung für gültige Befunde, oft über eine Plattform, die die Einreichungen sichtet. ISO/IEC 29147 (Offenlegung) und ISO/IEC 30111 (Bearbeitung) beschreiben die Prozesse, und die Cyberresilienz-Verordnung verpflichtet Hersteller von Produkten in ihrem Anwendungsbereich zu einer Strategie für die koordinierte Offenlegung von Schwachstellen. Ein Bounty ersetzt keine interne Sicherheitsarbeit: Auf einem ungetesteten System gestartet, erzeugt es meist eine Flut von Meldungen, die das Team nicht bewältigen kann.

Incident Response

Incident Response ist die organisierte Behandlung eines Sicherheitsvorfalls von der Erkennung bis zur Wiederherstellung und zum Lernen. Über ein Jahrzehnt lang war NIST SP 800-61 Revision 2 (2012) die Standardreferenz, mit ihrem Lebenszyklus aus vier Phasen: Vorbereitung; Erkennung und Analyse; Eindämmung, Beseitigung und Wiederherstellung; und Aktivitäten nach dem Vorfall. Revision 3, im April 2025 veröffentlicht als Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, ersetzt diesen Lebenszyklus durch die sechs Funktionen des NIST Cybersecurity Framework 2.0. Govern, Identify und Protect sind fortlaufende Vorbereitung, die Vorfälle unwahrscheinlicher und die Reaktion wirksamer macht; Detect, Respond und Recover sind die Reaktion selbst; und Lessons Learned fließen in die Verbesserung aller Funktionen ein, statt eine letzte Phase zu sein.

In der Praxis braucht eine gute Reaktion benannte Rollen (einen Incident Commander, der koordiniert und entscheidet, technische Leads, die untersuchen und handeln, eine für Kommunikation verantwortliche Person, einen Protokollführer, der die Zeitleiste festhält, und schnellen Zugang zu Rechtsberatung und zum Datenschutzbeauftragten), Schweregrade, die festlegen, wer geweckt wird, und einen Out-of-Band-Kanal, weil ein Angreifer in Ihrem E-Mail- oder Chatsystem die Reaktion mitlesen kann. Eindämmung ist eine Abwägung: Einen Angreifer schnell abzuschneiden begrenzt den Schaden, kann aber Beweise vernichten und ihn warnen; sichern Sie daher Beweise (Snapshots, Logs, Speicherabbilder), bevor Sie neu aufbauen, und vergewissern Sie sich, dass Sie alle seine Brückenköpfe gefunden haben, bevor Sie verkünden, dass er weg ist. Danach fragt ein schuldfreies Review, wie das System und seine Prozesse den Vorfall ermöglicht haben, und erzeugt architektonische Maßnahmen.

Resilienz gegen Ransomware

Ransomware verschlüsselt die Systeme einer Organisation und fordert Geld für den Schlüssel; die meisten Gruppen stehlen inzwischen vorher auch Daten und drohen, sie zu veröffentlichen. Die architektonischen Abwehrmaßnahmen sind die dieses ganzen Kapitels (MFA, Least Privilege, Segmentierung, Patchen, Erkennung), doch die Wiederherstellung hängt vor allem von einem ab: Backups, an die der Angreifer nicht herankommt. Angreifer mit Administratorrechten suchen zuerst nach Backups und löschen oder verschlüsseln sie.

Halten Sie mindestens eine Kopie kritischer Daten unveränderlich oder offline: Objektspeicher mit Write-once-Aufbewahrungssperren, die selbst ein Administrator nicht verkürzen kann, oder Medien, die physisch vom Netzwerk getrennt sind. Legen Sie Backups in ein getrenntes Konto oder einen getrennten Tenant mit eigenen Zugangsdaten und MFA, damit kompromittierte Produktionsidentitäten sie nicht erreichen. Die klassische 3-2-1-Regel (drei Kopien auf zwei Arten von Medien, eine davon außer Haus) ist eine vernünftige Grundlage. Testen Sie vor allem regelmäßig Wiederherstellungen gegen die RTO und RPO, die das Unternehmen vereinbart hat, einschließlich der Reihenfolge der Wiederherstellung: Identitätsdienste und DNS kommen zuerst, weil sich ohne sie nichts anderes wieder aufbauen lässt. 2017 baute die Reederei Maersk ihr weltweites Netzwerk neu auf, nachdem die Malware NotPetya ihre Windows-Domänencontroller zerstört hatte; die Wiederherstellung hing an dem einen Domänencontroller, der überlebt hatte, in Ghana, weil ein Stromausfall ihn während des Angriffs vom Netz genommen hatte.

Verletzungen des Schutzes personenbezogener Daten und Meldefristen

Eine Verletzung des Schutzes personenbezogener Daten ist nach Artikel 4 Nummer 12 DSGVO eine Verletzung der Sicherheit, die, ob unbeabsichtigt oder unrechtmäßig, zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von beziehungsweise zum unbefugten Zugang zu personenbezogenen Daten führt. Sie ist weiter gefasst als Diebstahl: Auch ein Ransomware-Angriff, der Daten unverfügbar macht, oder eine E-Mail an die falschen Empfänger kann darunter fallen. Nach Artikel 33 muss der Verantwortliche die Verletzung unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der Aufsichtsbehörde melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten von Personen; erfolgt die Meldung später, ist ihr eine Begründung für die Verzögerung beizufügen. Nach Artikel 34 muss der Verantwortliche außerdem die betroffenen Personen unverzüglich benachrichtigen, wenn die Verletzung voraussichtlich ein hohes Risiko für sie zur Folge hat. Artikel 33 Absatz 5 verlangt, jede Verletzung zu dokumentieren, ob gemeldet oder nicht. Die UK GDPR enthält dieselben Regeln, wobei Meldungen an das Information Commissioner’s Office gehen.

Andere Regelwerke können parallel gelten, mit eigenen Fristen, Empfängern und Schwellenwerten, und Verträge fügen oft Pflichten gegenüber Kunden und Partnern hinzu. Die Tabelle fasst die wichtigsten Fristen in der EU und im Vereinigten Königreich zusammen. Der Digital-Omnibus-Vorschlag der Europäischen Kommission vom November 2025 würde die Frist der DSGVO auf 96 Stunden verlängern und die Meldung an die Behörde auf Verletzungen mit hohem Risiko beschränken, doch zum Zeitpunkt der Erstellung ist er nicht angenommen, und es gilt die 72-Stunden-Regel.

Die architektonische Lehre ist, dass eine in Stunden gezählte Frist nur eingehalten werden kann, wenn die Systeme schnell und mit Belegen beantworten können, welche Daten betroffen waren, wem sie gehörten und ob tatsächlich darauf zugegriffen wurde. Das erfordert die Datenlandkarte aus Abschnitt 8.7, Datenzugriffslogs auf Speichern mit personenbezogenen Daten und eine Verschlüsselung, die eine abgeflossene Kopie unverständlich machen kann. Wie im Rest dieses Kapitels handelt es sich um Informationen darüber, wie sich das Recht auf Systeme auswirkt, nicht um Rechtsberatung; die Entscheidung über eine Meldung liegt beim Verantwortlichen, beraten durch seinen DSB und seine Juristen.

Runbooks

Ein Runbook ist ein schriftliches, getestetes Verfahren für eine bestimmte Situation: einen abgeflossenen Zugangsschlüssel widerrufen und rotieren, einen kompromittierten Container isolieren, die Bestelldatenbank aus einem unveränderlichen Backup wiederherstellen, auf eine vermutete Verletzung des Schutzes personenbezogener Daten reagieren. Ein gutes Runbook nennt seinen Auslöser, die einzubeziehenden Personen, die genauen Schritte und Befehle, wie sich prüfen lässt, dass jeder Schritt funktioniert hat, wie man zurückrollt und welche Beweise aufzubewahren sind. Runbooks sind dem Wesen nach Code: Halten Sie sie in der Versionskontrolle neben den Systemen, die sie beschreiben, automatisieren Sie die mechanischen Teile und üben Sie sie in Game Days und Tabletop-Übungen, weil ein Verfahren, das nie durchgespielt wurde, meist an Schritt drei scheitert. Jede Erkennungsregel sollte auf das Runbook für ihren Alarm verweisen.

Die Zeitleiste zeigt, warum der Betrieb Teil der Architektur ist. Jeder Schritt, der gut lief, hing von einer Designentscheidung ab, die Monate vorher getroffen wurde: Secret Scanning und Audit-Logs, die ins SIEM flossen, Zugriffslogs auf Objektebene für den Export-Bucket, eine Datenlandkarte, die dem DSB sagte, wessen Daten darin lagen, und ein Identitätsdesign, mit dem sich die Deployment-Rolle ohne langlebige Schlüssel neu aufbauen ließ. Jeder Schritt, der schlecht lief (dass es überhaupt einen langlebigen Schlüssel gab, ein Bucket mit Kundenexporten, den niemand mehr brauchte), war ebenfalls eine Architekturentscheidung.