Incident-Response-Prozess: Flussdiagramm für Sicherheitsvorfälle
Swimlane-Flussdiagramm für den Incident-Response-Prozess: Erkennung, Triage, Eindämmung, Beweissicherung, Bereinigung, Meldung an die Aufsichtsbehörde und Nachbereitung.
So funktioniert es
Benennen Sie die Bahnen nach Ihren echten Rollen
Ersetzen Sie die fünf Bahnen durch die Rollen, die es bei Ihnen wirklich gibt: SOC oder MSSP, Service Desk, Security-Leitung, Plattformteam, Datenschutzbeauftragter, externe Forensik oder externe Rechtsberatung. Gibt es eine Rolle nicht, löschen Sie die Bahn, statt sie unbesetzt stehen zu lassen.
Legen Sie Ihre Kriterien für den Schweregrad fest
Öffnen Sie den Schritt „Schweregrad und Auswirkung einstufen“ und ersetzen Sie den Kommentar durch Ihre eigene Matrix: Was macht einen Vorfall zu einem Vorfall mit hohem Schweregrad, wer darf ihn ausrufen, und welche Reaktionszeit sagt jede Stufe zu?
Tragen Sie Meldefrist und Aufsichtsbehörde ein
Passen Sie die Entscheidung „Meldepflichtige Datenpanne?“ so an, dass sie die für Sie geltenden Regime benennt: Art. 33 DSGVO verlangt die Meldung einer Verletzung des Schutzes personenbezogener Daten an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, Art. 34 die Benachrichtigung der Betroffenen bei hohem Risiko. Ergänzen Sie NIS2, branchenspezifische Pflichten und vertragliche Meldefristen gegenüber Kunden, die häufig kürzer sind als die gesetzlichen.
Hinterlegen Sie die Kontaktpunkte, die nachts um drei gebraucht werden
Schreiben Sie den Incident-Kanal, die Rufbereitschaftsnummer, den Plan für den Incident Commander und den Ablageort der Beweise in die Kommentare der Knoten, damit das Diagramm während eines Vorfalls benutzbar ist und nicht nur bei der Nachbereitung.
Passen Sie die Schleifen an und ergänzen Sie fehlende Schritte
Prüfen Sie, ob der Rückweg von „Systeme nachweislich sauber?“ in die Isolierung zu Ihrer Arbeitsweise passt, und ergänzen Sie, was für Ihre Umgebung spezifisch ist: die Beauftragung eines Forensik-Dienstleisters mit Rahmenvertrag, die Meldung an die Cyberversicherung oder eine Freigabestufe für die Kundenkommunikation.
Lassen Sie das Diagramm freigeben und versionieren Sie es
Geben Sie das Diagramm an Security-Leitung, IT-Betrieb und Rechtsabteilung zur Freigabe und bewahren Sie die freigegebene Fassung auf. Ein Incident-Response-Plan ist ein gelenktes Dokument, und die Version, die Sie üben, sollte die Version sein, die Sie veröffentlichen.
Häufig gestellte Fragen
Aus welchen Phasen besteht der Incident-Response-Prozess?
Dieses Diagramm nutzt fünf: Erkennung und Meldung, Triage und Einstufung, Eindämmung, Bereinigung und Wiederherstellung sowie Meldung und Nachbereitung. Das deckt sich weitgehend mit NIST SP 800-61r2, das Erkennung und Analyse, Eindämmung, Bereinigung und Wiederherstellung sowie Nachbereitung kennt. NIST führt zusätzlich eine Vorbereitungsphase, doch Vorbereitung ist laufende Arbeit — Werkzeuge, Rufbereitschaftspläne, Übungen, Rahmenverträge — und kein Schritt, den Sie während eines Vorfalls ausführen. Deshalb ist sie nicht im Ablauf gezeichnet.
Worin unterscheidet sich Incident Response von IT-Störungsmanagement?
Eine IT-Störung ist beendet, wenn der Dienst wieder läuft. Ein Sicherheitsvorfall nicht, denn es gibt einen Gegner. Zu frühe Wiederherstellung kann dem Angreifer seinen Zugang zurückgeben, und es bestehen Pflichten, die ein ITIL-Störungsprozess nicht kennt: Beweise vor dem Neuaufbau sichern, feststellen, welche Daten betroffen sind, und dort melden, wo Aufsichtsbehörden und Betroffene informiert werden müssen. Genau deshalb stehen in diesem Diagramm Beweissicherung und Abbilder vor der Bereinigung, und nach der Wiederherstellung folgt ein eigener Meldezweig.
Wer sollte Incident Commander sein, und wann wird er benannt?
Der Incident Commander sollte die Person sein, die entscheiden darf — ein Produktionssystem abschalten, externe Anwälte beauftragen, Kunden kontaktieren — und nicht zwingend die technisch versierteste verfügbare Person. Sie koordiniert, sie ermittelt nicht. In diesem Diagramm wird sie erst benannt, wenn die Entscheidung „Vorfall mit hohem Schweregrad?“ mit Ja beantwortet wird; Vorfälle geringeren Schweregrads bleiben beim Security-Team. Bei langen Vorfällen wird die Rolle bei jedem Schichtwechsel ausdrücklich übergeben.
Wann beginnt die 72-Stunden-Frist für die Meldung einer Datenpanne?
Nach Art. 33 DSGVO laufen die 72 Stunden ab dem Zeitpunkt, zu dem die Organisation Kenntnis von der Verletzung des Schutzes personenbezogener Daten erlangt — nicht ab Beginn des Angriffs und nicht ab Abschluss der Untersuchung. Liegt noch kein vollständiges Bild vor, dürfen Sie schrittweise nachmelden. Die Benachrichtigung der betroffenen Personen ist eine eigene Prüfung nach Art. 34 DSGVO und nur bei voraussichtlich hohem Risiko erforderlich. NIS2 und branchenspezifische Regelungen kennen andere Fristen, etwa eine Erstmeldung binnen 24 Stunden — tragen Sie deshalb die Frist und die Behörde, die für Sie gelten, an der Entscheidung ein.