Kurzfassung: Ein Incident-Response-Prozess regelt vor dem Vorfall, wer entscheidet, was zuerst getan wird und was auf keinen Fall. SANS beschreibt ihn in sechs Phasen von der Vorbereitung bis zu Lessons Learned, NIST ordnet ihn seit Revision 3 von SP 800-61 in die sechs Funktionen des Cybersecurity Framework ein; die Arbeit im Vorfall ist bei beiden dieselbe. Entscheidend sind ein benannter Incident Lead mit Mandat, Beweissicherung vor jeder Veränderung, ein unabhängiger Kommunikationskanal und ein Protokoll, das ab der ersten Minute geführt wird.
Ein Incident-Response-Prozess legt fest, was passiert, wenn ein Sicherheitsvorfall bestätigt ist: wer entscheidet, was zuerst getan wird, was auf keinen Fall getan wird und wie aus dem Vorfall etwas gelernt wird. Die beiden Referenzmodelle, an denen sich fast jeder Prozess orientiert, stammen von SANS und vom NIST. In diesem Beitrag erfährst du, wie beide aufgebaut sind, was NIST 2025 mit Revision 3 seiner Leitlinie geändert hat, welche Rollen ein Vorfall braucht, wie die ersten Stunden ablaufen sollten und an welchen Stellen Organisationen in der Praxis scheitern.
Ereignis oder Vorfall? Die erste Entscheidung
Nicht jeder Alarm ist ein Vorfall. Ein Ereignis ist alles, was in Logs auftaucht: ein fehlgeschlagener Login, ein blockierter Anhang, ein Portscan von außen. Ein Sicherheitsvorfall ist ein Ereignis oder eine Kette von Ereignissen, die Vertraulichkeit, Integrität oder Verfügbarkeit tatsächlich verletzt oder unmittelbar bedroht: ein kompromittiertes Konto, Schadsoftware, die ausgeführt wurde, Daten, die das Haus verlassen haben. Die Grenze zwischen beidem muss vor dem ersten Vorfall definiert sein, sonst wird sie nachts um zwei von der Person gezogen, die gerade Bereitschaft hat. Aus dieser Definition folgt auch die Klassifikation: Welche Vorfälle sind kritisch und lösen den vollen Prozess aus, welche behandelt das SOC im Tagesgeschäft?
Der Incident-Response-Prozess nach SANS: sechs Phasen
Das SANS-Modell ist das, was die meisten Incident Responder im Kopf haben, weil es die Reihenfolge der Arbeit abbildet. Sechs Phasen, im Englischen als PICERL abgekürzt:
- Preparation (Vorbereitung). Alles, was vor dem Vorfall passiert: Rollen, Kontaktlisten, Playbooks, Werkzeuge, Logging, Backups, Übungen. Die Phase, die über den Ausgang aller anderen entscheidet und am häufigsten übersprungen wird. Was in den Incident-Response-Plan gehört, steht im eigenen Beitrag.
- Identification (Erkennung und Bewertung). Der Alarm wird zum Vorfall erklärt. Was ist betroffen, seit wann, wie weit reicht es? Hier entsteht die erste Zeitlinie, meist aus dem SIEM und den Endpunktdaten.
- Containment (Eindämmung). Den Schaden begrenzen, ohne Beweise zu vernichten: Systeme isolieren statt abschalten, Konten sperren, Netzsegmente trennen. Oft in zwei Stufen, kurzfristig und langfristig.
- Eradication (Beseitigung). Die Ursache entfernen: Schadsoftware, Persistenzmechanismen, kompromittierte Zugangsdaten, die ausgenutzte Schwachstelle. Erst wenn der Angreifer keinen Weg zurück hat, geht es weiter.
- Recovery (Wiederherstellung). Systeme kontrolliert zurück in den Betrieb, aus sauberen Backups oder neu aufgesetzt, mit verstärktem Monitoring in den ersten Tagen danach.
- Lessons Learned (Nachbereitung). Was ist passiert, was hat funktioniert, was nicht, was ändern wir? Ohne diese Phase wiederholt sich der Vorfall. Wie der Post-Incident-Review abläuft, steht im eigenen Beitrag.
Der Incident-Response-Prozess nach NIST
Das NIST hat mit Special Publication 800-61 jahrelang das zweite Standardmodell geliefert: vier Phasen, in denen Eindämmung, Beseitigung und Wiederherstellung zu einem Block zusammengefasst sind und ein Rücksprung von der Eindämmung zurück in die Analyse ausdrücklich vorgesehen ist, weil man während eines Vorfalls ständig Neues erfährt.
Im April 2025 hat das NIST SP 800-61 in Revision 3 veröffentlicht und damit Revision 2 abgelöst. Der Ansatz ist ein anderer: Incident Response wird nicht mehr als eigener Prozess mit vier Phasen beschrieben, sondern entlang der sechs Funktionen des NIST Cybersecurity Framework 2.0 in das gesamte Risikomanagement eingeordnet. Govern, Identify und Protect sorgen dafür, dass weniger Vorfälle entstehen und die Organisation vorbereitet ist; Detect, Respond und Recover bilden den eigentlichen Vorfall ab. Die operativen Details, wie einzelne Schritte technisch ablaufen, hat NIST bewusst aus dem Dokument herausgenommen und auf begleitende Online-Ressourcen verlagert, weil sie sich zu schnell ändern, um in einer statischen Publikation zu stehen.
Für die Praxis heißt das: Revision 3 ist das Dokument für die Frage, wie Incident Response in Governance, Risikomanagement und Compliance verankert wird. Das Phasenmodell für den Vorfall selbst bleibt sinnvoll, und die Modelle lassen sich problemlos übereinanderlegen:
| SANS (PICERL) | NIST SP 800-61 Rev. 2 | NIST CSF 2.0 (Rev. 3) |
|---|---|---|
| Preparation | Preparation | Govern, Identify, Protect |
| Identification | Detection and Analysis | Detect |
| Containment, Eradication, Recovery | Containment, Eradication and Recovery | Respond, Recover |
| Lessons Learned | Post-Incident Activity | Identify (Improvement), Govern |
Rollen im Vorfall
Ein Vorfall scheitert seltener an der Technik als an der Frage, wer entscheidet. Diese Rollen müssen vorher benannt sein, mit Stellvertretung:
- Incident Lead. Eine Person, die den Vorfall führt, Prioritäten setzt und Entscheidungen trifft, auch unangenehme wie das Abschalten eines Produktivsystems. Nicht die Person, die gleichzeitig die Forensik macht.
- Technische Analyse. SOC-Analysten, Incident Responder, Forensiker. Sie liefern die Fakten: Umfang, Zeitlinie, Einstiegspunkt.
- IT-Betrieb. Die Leute, die Systeme isolieren, Konten sperren, Backups einspielen. Ohne sie bleibt jede Entscheidung Theorie.
- Kommunikation. Intern, gegenüber Kunden, Presse. Eine Stimme, abgestimmte Botschaften.
- Recht und Datenschutz. Meldepflichten, Beweissicherung, Verträge, Versicherung. Der Datenschutzbeauftragte gehört ab der ersten Stunde an den Tisch, nicht erst, wenn die 72-Stunden-Frist der DSGVO fast abgelaufen ist.
- Geschäftsführung. Wird informiert und trifft die Entscheidungen, die Geld oder Reputation betreffen. Sie führt den Vorfall nicht selbst.
- Externe. IR-Dienstleister, Forensik, Cyberversicherung, Behörden. Kontaktdaten und Vertragsbedingungen gehören ins Playbook, nicht in eine E-Mail, die im Vorfall nicht mehr erreichbar ist.
Die ersten Stunden: Reihenfolge schlägt Tempo
Was in den ersten Stunden passiert, entscheidet darüber, ob ein Vorfall ein Zwischenfall bleibt oder zur Krise wird. Die Reihenfolge, die sich bewährt hat:
- Bestätigen und einordnen. Ist es wirklich ein Vorfall, und welcher Klasse? Wer ist der Incident Lead?
- Kommunikationskanal wechseln. Wenn E-Mail oder der Chat kompromittiert sein könnten, läuft die Koordination über einen unabhängigen Kanal: Telefon, ein separates Messenger-System, notfalls ein Raum.
- Umfang bestimmen. Welche Systeme, welche Konten, seit wann? Ein einzelner infizierter Client und ein kompromittierter Domain-Admin sind zwei verschiedene Vorfälle mit zwei verschiedenen Reaktionen.
- Beweise sichern, bevor etwas verändert wird. Speicherabbilder, Logs, Netzwerkmitschnitte. Ein Neustart löscht den Arbeitsspeicher und damit oft die einzige Spur, wie der Angreifer arbeitet. Die Reihenfolge und die Werkzeuge dafür beschreibt der Beitrag zur forensischen Triage.
- Eindämmen. Isolieren, nicht abschalten. Zugangsdaten zurücksetzen, angefangen bei den privilegierten Konten. Persistenz prüfen, bevor die Entwarnung kommt.
- Dokumentieren, laufend. Wer hat wann was entschieden und getan? Diese Liste brauchst du für Versicherung, Behörden und die Nachbereitung, und niemand kann sie drei Tage später aus dem Gedächtnis rekonstruieren.
- Meldefristen prüfen. Sind personenbezogene Daten betroffen, läuft die 72-Stunden-Frist der DSGVO. Für Einrichtungen unter NIS2 kommt eine Frühwarnung an das BSI innerhalb von 24 Stunden dazu. Die Fristen laufen ab Kenntnis, nicht ab Abschluss der Analyse. Welche Pflichten für wen gelten und wie du sie in den Prozess einbaust, steht im Beitrag Meldepflichten bei Cyberangriffen: NIS2, DSGVO, BSI.
Das BSI stellt für Unternehmen ohne eigenes IR-Team Checklisten für die ersten Schritte bereit, getrennt nach Organisation und Technik, auf seiner Seite Ich habe einen IT-Sicherheitsvorfall, was soll ich tun?. Wer keinen eigenen Prozess hat, fängt dort an.
Ein Vorfall durch alle Phasen: das kompromittierte Konto
Der Prozess wird greifbar, wenn man ihn an einem Fall durchspielt, der in fast jeder Organisation vorkommt. Ausgangslage: Montag, 9:40 Uhr, das Cloud-Anmeldeprotokoll meldet eine erfolgreiche Anmeldung des Kontos einer Mitarbeiterin aus der Buchhaltung von einer Adresse in einem Land, in dem das Unternehmen niemanden hat, mit bestätigter MFA. Die Mitarbeiterin sitzt im Büro.
| Phase | Was passiert | Wer | Zeit |
|---|---|---|---|
| Identification | Der Analyst prüft: MFA-Methode war eine Push-Bestätigung, Gerät unbekannt, dazu im Postfach eine neue Regel, die Mails mit „Rechnung“ in einen Unterordner verschiebt. Kein Fehlalarm. Klasse: kritisch, weil Zahlungsbezug. Incident Lead wird benannt, das Vorfallprotokoll beginnt mit dem ersten Eintrag. | SOC, Incident Lead | 9:40 bis 10:10 |
| Containment, kurzfristig | Alle Sitzungen des Kontos werden widerrufen, die Anmeldung gesperrt, das Postfach bleibt unverändert für die Beweissicherung. Koordination läuft ab jetzt per Telefon und einem separaten Kanal, nicht über das betroffene Mailsystem. Die Mitarbeiterin wird persönlich informiert, nicht per Mail. | IT-Betrieb, Incident Lead | 10:10 bis 10:30 |
| Identification, zweiter Durchgang | Umfang: Seit wann? Die Anmeldeprotokolle zeigen die erste fremde Anmeldung am Freitag um 17:52 Uhr nach einem Klick auf eine Phishing-Seite. Was wurde getan? Postfach durchsucht, drei Rechnungen an Kunden mit geänderter Bankverbindung beantwortet, eine Datei aus dem Cloud-Speicher heruntergeladen. Der Vorfall wächst: Business Email Compromise mit Zahlungsbezug und möglichem Datenabfluss. Die Geschäftsführung wird informiert. | Analyse, Incident Lead | 10:30 bis 12:00 |
| Beweissicherung | Export der Anmeldeprotokolle, der Postfachregeln, der gesendeten Elemente und des Audit-Logs des Cloud-Speichers, jeweils mit Hash im Protokoll. Screenshots der Regel vor dem Löschen. | Analyse | parallel |
| Containment, langfristig, und Eradication | Passwort durch den Administrator neu gesetzt, fremde MFA-Methode entfernt, Postfachregel gelöscht, OAuth-Zustimmungen geprüft, alle Konten mit Klick auf dieselbe Phishing-Seite identifiziert und gleich behandelt. Die Phishing-Domain wird im Gateway und DNS-Filter gesperrt, die Mail aus allen Postfächern entfernt. | IT-Betrieb, SOC | 12:00 bis 14:00 |
| Kommunikation und Meldung | Die drei Kunden werden telefonisch gewarnt, die Buchhaltung prüft offene Zahlungen. Datenschutz bewertet: Die heruntergeladene Datei enthält Kundendaten, die 72-Stunden-Frist der DSGVO läuft ab Kenntnis um 10:10 Uhr. Die Meldung an die Aufsichtsbehörde wird vorbereitet. | Kommunikation, Datenschutz, Recht | 14:00 bis 17:00 |
| Recovery | Konto wird nach neuer MFA-Registrierung wieder freigegeben, mit erhöhter Überwachung für zwei Wochen. Kein System muss neu aufgesetzt werden. | IT-Betrieb | Dienstag |
| Lessons Learned | Review nach zehn Tagen: Warum hat die Phishing-Mail das Gateway passiert, warum wurde die Push-Bestätigung durchgewunken, warum hat niemand die Postfachregel bemerkt? Maßnahmen: Phishing-resistente MFA für Konten mit Zahlungsbezug, Alarm auf neue Postfachregeln mit Weiterleitung, Vier-Augen-Prinzip bei Änderungen von Bankverbindungen. | Alle Rollen | zweite Woche |
Zwei Dinge zeigt das Beispiel. Erstens: Die Phasen laufen nicht sauber nacheinander; die Bewertung des Umfangs wird nach der ersten Eindämmung wiederholt, und NIST hat genau diesen Rücksprung schon in Revision 2 vorgesehen. Zweitens: Der größte Teil der Arbeit ist nicht technisch. Von acht Zeilen der Tabelle betreffen drei Kommunikation, Meldung und Nachbereitung, und das ist die Verteilung, die in echten Vorfällen die Regel ist. Die technischen Schritte im Detail stehen im Phishing-Playbook.
Vorlage: das Vorfallprotokoll
Das Vorfallprotokoll ist das Dokument, das Versicherung, Behörden und der Review später verlangen und das niemand nachträglich aus dem Gedächtnis schreiben kann. Es wird ab der ersten Minute von einer benannten Person geführt, nicht vom Incident Lead, der andere Aufgaben hat, und liegt an einem Ort, der auch ohne das Firmennetz erreichbar ist. Ein Kopfblock, dann eine Zeile pro Eintrag:
| Feld | Inhalt |
|---|---|
| Vorfall-ID und Titel | Fortlaufende Nummer, Kurzbezeichnung, Klassifikation |
| Incident Lead, Protokollführer | Name, Erreichbarkeit, Stellvertretung |
| Zeitpunkt der Kenntnis | Datum und Uhrzeit, ab der die Meldefristen laufen |
| Betroffene Systeme, Konten, Daten | Laufend ergänzt, mit Stand der Erkenntnis |
| Beweismittel | Was gesichert wurde, wann, von wem, Hash, Ablageort |
| Meldungen | An wen, wann, Frist, Status |
Jeder Eintrag danach hat vier Spalten: Zeitstempel, wer, was wurde festgestellt oder entschieden oder getan, und die Quelle oder Begründung. „10:12, Müller, Sitzungen des Kontos widerrufen, Entscheidung Incident Lead“ ist ein guter Eintrag; „Konto gesperrt“ ohne Zeit und Person ist keiner. Entscheidungen werden mit dem Wissensstand notiert, den man zu dem Zeitpunkt hatte, weil genau diese Frage im Review und gegenüber der Versicherung gestellt wird: Was war bekannt, als das entschieden wurde? Wer das Protokoll in einem Fallmanagement wie TheHive führt, bekommt Zeitstempel und Zuständigkeit automatisch; ein Textdokument mit dieser Struktur tut es auch.
Stolperfallen aus der Praxis
- Zu früh eindämmen. Wer beim ersten Fund sofort alle Passwörter zurücksetzt, verrät dem Angreifer, dass er entdeckt wurde, bevor der Umfang bekannt ist. Bei Ransomware-Gruppen kann das die Verschlüsselung auslösen, die eigentlich noch Tage entfernt war. Wie die ersten 24 Stunden in diesem Fall ablaufen, steht im Beitrag Ransomware-Vorfall: die ersten 24 Stunden.
- Zu spät eindämmen. Das Gegenteil: tagelang beobachten, um alles zu verstehen, während die Daten abfließen. Der Incident Lead entscheidet, wann genug bekannt ist.
- Beweise vernichten. Neu aufsetzen, bevor jemand ein Abbild gezogen hat. Danach lässt sich weder der Einstiegsweg noch der Umfang belegen, und die Versicherung fragt genau danach.
- Über kompromittierte Kanäle koordinieren. Der Angreifer liest mit, wenn das IR-Team im gekaperten Mailsystem seine nächsten Schritte plant.
- Kein Mandat. Wenn nachts niemand entscheiden darf, ob der Fileserver vom Netz geht, verliert das Team die Stunden, in denen der Vorfall noch klein war.
- Ungetestete Backups. Die Wiederherstellung ist nur so gut wie der letzte erfolgreiche Restore-Test. Viele Organisationen erfahren im Vorfall, dass ihre Backups verschlüsselt, unvollständig oder Wochen alt sind.
- Nachbereitung ausfallen lassen. Nach dem Vorfall will jeder nur noch zurück zum Normalbetrieb. Ohne Lessons Learned bleibt die Lücke offen, durch die der Angreifer kam.
Häufige Fragen zum Incident-Response-Prozess
SANS oder NIST: Welches Modell soll ich nehmen?
Für die Arbeit im Vorfall das SANS-Modell, weil es die Reihenfolge der Handgriffe abbildet und jeder Incident Responder es kennt. Für die Verankerung in Governance, Risikomanagement und Audits NIST SP 800-61 Revision 3, weil Prüfer und Regulierer darauf verweisen. Beide beschreiben dieselbe Arbeit; die Tabelle oben zeigt, wie sie sich übereinanderlegen.
Was ist der Unterschied zwischen Incident-Response-Prozess, Plan und Playbook?
Der Prozess ist das Modell: Phasen, Rollen, Entscheidungswege. Der Plan ist das Dokument, das diesen Prozess für die eigene Organisation festschreibt, mit Namen, Kontaktlisten, Klassifikation und Meldewegen. Ein Playbook ist die Schritt-für-Schritt-Anleitung für einen bestimmten Vorfalltyp, etwa Ransomware oder ein kompromittiertes Konto, und hängt als Anhang am Plan.
Wer sollte den Vorfall führen?
Eine Person mit Mandat, Erfahrung und Ruhe, die nicht gleichzeitig die technische Analyse macht. In kleinen Organisationen ist das oft der IT-Leiter, in größeren ein benannter Incident Manager aus dem Sicherheitsteam. Die Geschäftsführung führt den Vorfall nicht, sie trifft die Entscheidungen, die Geld und Reputation betreffen, und bekommt dafür die Fakten geliefert.
Wann ist ein Vorfall abgeschlossen?
Nicht, wenn die Systeme wieder laufen, sondern wenn die Ursache beseitigt ist, keine Persistenz mehr gefunden wird, die Meldungen erledigt sind und der Review stattgefunden hat. Viele Organisationen erklären einen Vorfall nach der Wiederherstellung für beendet und erleben ihn drei Wochen später noch einmal, weil der Angreifer einen zweiten Zugang hatte.
Wie oft sollte der Prozess geübt werden?
Mindestens einmal im Jahr als Tabletop-Übung mit allen Rollen inklusive Geschäftsführung, dazu nach jeder wesentlichen Änderung an Organisation oder Technik. Die Übung dauert einen halben Tag und deckt zuverlässig die Stellen auf, an denen der Plan auf dem Papier funktioniert und in der Praxis nicht: fehlende Kontaktdaten, unklare Mandate, Backups, die niemand getestet hat.
Brauche ich einen externen Incident-Response-Dienstleister?
Wenn die Organisation keine eigene Forensik hat, ja, und zwar mit Rahmenvertrag vor dem Vorfall. Im Ernstfall einen Dienstleister zu suchen kostet Tage, in denen die Beweise verschwinden und der Schaden wächst. Viele Cyberversicherungen bringen einen Dienstleister mit; dann gehört seine Nummer in den Plan und die Bedingungen, unter denen er gerufen werden darf.
Fazit
Ob du dein Vorgehen an SANS oder NIST ausrichtest, ist zweitrangig; die Phasen sind dieselben, nur anders geschnitten. Entscheidend ist, dass der Prozess vor dem ersten Vorfall existiert, dass eine Person ihn führt und dass er geübt wurde. NIST hat mit Revision 3 den Rahmen dafür in das Risikomanagement geholt; die Arbeit im Vorfall selbst bleibt Handwerk: Umfang klären, Beweise sichern, eindämmen, dokumentieren, lernen. Wer das Blue Team dafür aufstellt, bevor es brennt, hat den schwierigsten Teil hinter sich.