Cyber Incident Response: Flussdiagramm für SOC und CSIRT

Was ist cyber incident response: flussdiagramm für soc und csirt?

Ein Cyber-Incident-Response-Prozess ist der Arbeitszyklus, den ein Security Operations Center oder ein CSIRT abarbeitet, sobald eine Detektion auslöst. Alert triagieren und anreichern, entscheiden, ob es ein True Positive ist, den Vorfall deklarieren und seinen Schweregrad festlegen, eine Einsatzleitung benennen, jedes System und jedes Konto finden, das der Angreifer berührt hat, eindämmen ohne die Beweise zu zerstören, die Bedrohung entfernen, ihre Beseitigung nachweisen, und erst dann wiederherstellen. Diese Vorlage zeichnet diese Abfolge über fünf Bahnen: Detektion / SOC, Incident Responder, Incident Commander, IT-Betrieb und Management.

Es lohnt sich, klar zu sagen, was dieser Prozess nicht ist, denn zwei benachbarte Prozesse werden regelmäßig hineingezogen, und beide werden dadurch schwächer. Er ist kein IT-Incident-Management: Das misst sich an der Wiederherstellung eines gestörten Dienstes und ist beendet, sobald der Nutzer wieder arbeiten kann. Ein Sicherheitsvorfall ist mit der Rückkehr des Dienstes gerade nicht vorbei, denn eine zu frühe Wiederherstellung gibt dem Angreifer seinen Zugang zurück. Er ist auch keine Meldung von Datenschutzverletzungen. Die Frage, ob personenbezogene Daten betroffen sind, ob eine Aufsichtsbehörde oder ein Kunde informiert werden muss und in welcher Frist, liegt bei Recht, Datenschutzbeauftragtem und Kommunikation, folgt gesetzlichen statt technischen Uhren und gehört in den übergeordneten Prozess zur Reaktion auf Sicherheitsvorfälle. Dieses Diagramm läuft neben dieser Arbeit her, statt sie aufzusaugen.

Die Form folgt der Abfolge, die praktisch alle veröffentlichten Leitfäden teilen. Das Sechs-Schritte-Modell von SANS (Vorbereitung, Identifikation, Eindämmung, Beseitigung, Wiederherstellung, Lessons Learned) bildet sich unmittelbar darauf ab, und NIST SP 800-61 Revision 2 gruppiert dieselbe Arbeit als Detektion und Analyse; Eindämmung, Beseitigung und Wiederherstellung; sowie Nachbereitung. Revision 3 ordnet die Leitlinien an den Funktionen des Cybersecurity Framework 2.0 statt an einer festen Phasenliste aus, an der Reihenfolge, in der ein Responder tatsächlich arbeitet, ändert das nichts. Die Vorbereitung ist bewusst nicht als Kasten gezeichnet, weil sie laufende Arbeit ist (Werkzeuge, Rufbereitschaft, Rahmenverträge, Übungen) und kein Schritt während eines Vorfalls. Was das Diagramm wirklich schützen soll, ist die Reihenfolge: Beweise vor Beseitigung, Prüfung vor Wiederherstellung, und eine benannte Person, die das Abschalten eines Produktivsystems freigeben darf.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Rollenbahnen (Detektion / SOC, Incident Responder, Incident Commander, IT-Betrieb und Management) über sechs Phasenspalten: Detektion und Triage, Deklaration, Umfang und Eindämmung, Beseitigung, Wiederherstellung und Auswertung.
• Die Triage in der SOC-Bahn: „Alert triagieren und anreichern“ mündet in die Entscheidung „True Positive?“, deren Nein-Zweig „Alert schließen und Regel nachschärfen“ auslöst: ein False Positive verändert also die Detektion, statt nur weggeklickt zu werden.
• Übergabe und Führung: „Vorfall deklarieren und Schweregrad festlegen“ verschiebt die Arbeit vom SOC zum Incident Responder, und „Incident Commander benennen“ bestimmt die Person, die für den Rest des Vorfalls die Entscheidungen verantwortet.
• Die Entscheidung „Eindämmung stört den Betrieb?“ in der Bahn des Incident Commander: Der Ja-Zweig führt über „Betriebsstörende Eindämmung freigeben“ im Management, bevor der IT-Betrieb „Betroffene Hosts und Konten isolieren“ ausführt.
• Beweise vor Aufräumen: „Forensische Beweise und Images sichern“ liegt zwischen Eindämmung und der Spalte Beseitigung, die die Suche nach weiteren Zugängen des Angreifers, das Entfernen von Malware und Persistenz sowie das Zurücksetzen von Zugangsdaten und Schließen der ausgenutzten Lücken umfasst.
• Die Prüfentscheidung „Bedrohung vollständig beseitigt?“, die bei einem Nein über den Zweig Neu bewerten auf „Betroffene Systeme und Konten ermitteln“ zurückführt; erst danach folgen Neuaufbau aus sauberen Backups, überwachte Wiederherstellung in der SOC-Bahn, Nachbereitung und „Detektionsregeln und Playbooks aktualisieren“ vor dem Schließen der Vorfallakte.

Wann Sie diese Vorlage verwenden sollten

• Sie betreiben ein SOC oder CSIRT oder bauen eines auf und wollen den technischen Lebenszyklus auf einer Seite haben, von der Alert-Queue bis zu der Detektionsregel, die beim nächsten Mal auslöst.
• Sie schreiben den Runbook-Teil eines Incident-Response-Plans und brauchen die Reihenfolge von Eindämmung, Beweissicherung und Beseitigung vorab abgestimmt statt im Vorfall ausdiskutiert.
• Sie bereiten eine Planübung oder einen Purple-Team-Test vor und wollen Entscheidungspunkte, Schleifen und Übergaben ausgelegt haben, gegen die Sie testen können.
• Sie brauchen eine vorab getroffene Einigung zwischen Security, IT-Betrieb und Management darüber, wer das Abschalten eines Produktivsystems freigeben darf, und was gilt, wenn diese Person schläft.
• Sie führen neue Analysten ein und wollen den Eskalationsweg von der Triage über den Responder bis zum Incident Commander ausdrücklich gezeichnet haben, statt ihn nebenbei lernen zu lassen.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihrer echten Aufstellung

   Ersetzen Sie Detektion / SOC, Incident Responder, Incident Commander, IT-Betrieb und Management durch das, was Sie tatsächlich haben: einen externen MSSP, getrennte Bahnen für Tier 1 und Tier 2, ein Plattform- oder Cloud-Team statt IT-Betrieb, einen Forensik-Dienstleister mit Rahmenvertrag. Löschen Sie eine Bahn, statt sie unbesetzt zu lassen, und führen Sie Commander und Responder zusammen, wenn beides bei Ihnen wirklich eine Person macht.

2. Hinterlegen Sie Ihre Schweregradmatrix an der Deklaration

   Öffnen Sie „Vorfall deklarieren und Schweregrad festlegen“ und ersetzen Sie den Kommentar durch Ihre eigenen Kriterien: Was macht einen Vorfall kritisch, wer darf deklarieren, und wozu verpflichtet jede Stufe bei Reaktionszeit, Besetzung und Rufbereitschaft. Der Schweregrad steuert jede nachgelagerte Entscheidung in diesem Diagramm. Hier lohnt sich Genauigkeit.

3. Legen Sie die Freigaberegel für die Eindämmung fest

   Der Zweig „Eindämmung stört den Betrieb?“ funktioniert nur, wenn ihn jemand um drei Uhr nachts beantworten kann. Schreiben Sie auf, welche Systeme der Responder eigenständig isolieren darf, welche eine Geschäftsentscheidung brauchen, wer diese Entscheidung hält und was passiert, wenn diese Person innerhalb einer vereinbarten Zeit nicht erreichbar ist.

4. Klären Sie die Beweisregeln vor der Eindämmung

   Halten Sie Ihre Sicherungsreihenfolge an „Forensische Beweise und Images sichern“ fest: Arbeitsspeicher und flüchtiger Netzwerkzustand vor der Festplatte, Festplatte vor archivierten Logs, nach dem Prinzip der Flüchtigkeitsreihenfolge aus RFC 3227. Notieren Sie, dass Hosts auf Netzwerkebene isoliert und nicht ausgeschaltet werden, und wo die Images liegen und wer sie gegenzeichnet.

5. Definieren Sie, was „vollständig beseitigt“ bedeutet

   Schreiben Sie die Ausstiegskriterien neben die Entscheidung „Bedrohung vollständig beseitigt?“: das Beobachtungsfenster ohne Angreiferaktivität, jeder Indikator über die gesamte Landschaft gesucht, jedes kompromittierbare Konto rotiert, die ausgenutzte Schwachstelle geschlossen. Entscheiden Sie außerdem, ob der Fehlerzweig wie hier zur Umfangsbestimmung zurückführt oder zur Eindämmung.

6. Verbinden Sie das Diagramm mit den Nachbarprozessen und versionieren Sie es

   Ergänzen Sie ausdrückliche Verweise auf Ihren Meldeweg für Datenschutzverletzungen, auf Problem- oder Change-Management für die dauerhaften Fixes sowie auf Cyberversicherung oder Lieferantenmeldungen, soweit einschlägig. Geben Sie das Diagramm anschließend an Sicherheitsleitung, IT-Betrieb und Management zur Freigabe und bewahren Sie die freigegebene Fassung auf: der Plan, den Sie üben, sollte der Plan sein, den Sie veröffentlichen.

Häufig gestellte Fragen

Aus welchen Phasen besteht ein Cyber-Incident-Response-Prozess?

Dieses Diagramm nutzt sechs Spalten: Detektion und Triage, Deklaration, Umfang und Eindämmung, Beseitigung, Wiederherstellung und Auswertung. Das bildet sich unmittelbar auf das Sechs-Schritte-Modell von SANS ab (Vorbereitung, Identifikation, Eindämmung, Beseitigung, Wiederherstellung, Lessons Learned) und auf NIST SP 800-61 Revision 2, das dieselbe Arbeit als Detektion und Analyse; Eindämmung, Beseitigung und Wiederherstellung; sowie Nachbereitung gruppiert. Revision 3 ordnet die Leitlinien an den Funktionen des Cybersecurity Framework 2.0 statt an einer festen Phasenliste aus. Die Vorbereitung ist nicht als Schritt gezeichnet, weil sie laufende Arbeit ist (Detektionsentwicklung, Rufbereitschaft, Rahmenverträge, Übungen), die vor jedem Alert stattfindet und nicht während eines Alerts.

Wie grenzt sich das von IT-Incident-Management und von der Meldung einer Datenpanne ab?

IT-Incident-Management stellt einen gestörten Dienst wieder her und schließt, sobald der Nutzer wieder arbeiten kann. In einem Sicherheitsvorfall steckt ein Gegner, deshalb ist die Wiederherstellung nicht die Ziellinie, sondern der Punkt maximalen Risikos, solange die Bedrohung noch im Netz sitzt, genau deshalb liegt in diesem Diagramm eine Prüfentscheidung vor der Wiederherstellung. Die Meldung einer Datenpanne ist der andere Nachbar. Die Frage, ob personenbezogene Daten betroffen sind, ob Aufsichtsbehörde oder Kunde informiert werden müssen und in welcher gesetzlichen Frist, ist Arbeit von Recht und Kommunikation an einer gesetzlichen Uhr und läuft parallel zur technischen Reaktion, nicht in ihr.

Warum kommt die Beweissicherung vor der Beseitigung?

Weil die häufigsten Eindämmungsmaßnahmen genau die Beweise zerstören, die Sie später brauchen. Ein ausgeschalteter Host verliert speicherresidente Malware, laufende Netzwerkverbindungen, entschlüsseltes Material und injizierte Prozesse. Ein Server, der neu aufgebaut wird, bevor der Umfang verstanden ist, verliert die Artefakte, die zeigen, wie der Angreifer hereinkam und wohin er gelangte. Die praktische Regel ist das in RFC 3227 beschriebene Prinzip der Flüchtigkeitsreihenfolge: zuerst Arbeitsspeicher und flüchtiger Zustand, dann Datenträger, dann archivierte Logs. In diesem Diagramm liegt der Beweisschritt nach der Isolierung und vor jeder Beseitigungsarbeit, und Hosts werden auf Netzwerkebene isoliert, damit sie weiterlaufen.

Woran erkennt man, dass die Bedrohung vollständig beseitigt ist?

An Kriterien, die vor dem Vorfall geschrieben wurden, nicht an einem Bauchgefühl im Moment. Typischerweise: keine beobachtete Angreiferaktivität in der gesamten Landschaft über ein vereinbartes Beobachtungsfenster; jeder Indikator aus der Untersuchung über alle Hosts gesucht, nicht nur über die, die Alarm ausgelöst haben; jedes Konto rotiert, dessen Zugangsdaten hätten abgegriffen werden können, einschließlich Dienst- und Maschinenkonten; und die Schwachstelle oder Fehlkonfiguration geschlossen, die den Erstzugang ermöglicht hat. Lautet die Antwort Nein, war meist der Umfang falsch und nicht das Aufräumen schlampig, deshalb führt der Fehlerzweig hier auf „Betroffene Systeme und Konten ermitteln“ zurück und nicht auf die Isolierung.

Wer gibt eine Eindämmung frei, die einen Produktivdienst abschaltet?

Jemand, der die geschäftlichen Folgen tragen darf, selten der Responder, der das Problem entdeckt hat. Dieses Diagramm führt den Fall durch die Management-Bahn, aber es geht nicht um den Namen der Bahn: Es geht darum, dass die Entscheidung, die benannte Rolle und die Ausweichregel bei Nichterreichbarkeit vorab vereinbart sind. Viele Teams geben die Isolierung für eine definierte Liste von Systemen und Schweregraden vorab frei, damit die Standardfälle nie auf einen Anruf warten, und heben die Eskalation für umsatztragende oder sicherheitsrelevante Dienste auf. Ohne das findet die Diskussion statt, während der Angreifer weiterarbeitet.