Wie bauen Sie einen Incident-Response-Plan auf, der funktioniert?

Die meisten Organisationen scheitern bei der Incident Response nicht, weil ihnen Tools fehlen. Sie scheitern, weil vorher niemand klärte, wer was tut, und der erste echte Incident wird zu einer Besprechung statt zu einer Reaktion.

Beginnen Sie mit den Phasen, nicht mit dem Playbook

NIST SP 800-61 definiert vier Phasen: Vorbereitung, Erkennung und Analyse, Eindämmung/Beseitigung/Wiederherstellung und Aktivitäten nach dem Incident. Diese Reihenfolge ist wichtig. Teams springen gerne direkt zur Eindämmung, weil es sich produktiv anfühlt, aber wenn Sie die Vorbereitungsarbeit nicht geleistet haben, kennen Sie Ihr Netzwerk nicht gut genug, um etwas sauber einzudämmen.

Vorbereitung bedeutet Asset-Inventare, die tatsächlich aktuell sind, nicht die Tabelle aus 2022. Es bedeutet, Ihr Log-Aufbewahrungsfenster zu kennen (wenn es 7 Tage sind und der Angreifer 30 Tage Dwell-Time hatte, haben Sie die Timeline bereits verloren). Es bedeutet vorbereitete Forensik-Tools — Velociraptor, KAPE oder selbst ein dokumentiertes tar/dd-Verfahren für Disk-Images — damit niemand während eines aktiven Incidents Tools auf einen kompromittierten Host herunterlädt.

Definieren Sie Schweregrade, bevor Sie sie brauchen

Ein SEV1 (aktive Datenexfiltration, Ransomware-Detonation, Domain-Admin-Kompromittierung) benötigt eine andere Reaktion als ein SEV3 (isolierte Malware auf einer einzelnen unprivilegierten Workstation). Schreiben Sie dies als Matrix auf: Impact vs. Scope vs. Konfidenz. Ordnen Sie jedem Schweregrad eine erforderliche Reaktionszeit und einen Eskalationspfad zu. Wenn Ihr Incident Commander für einen SEV1 dieselbe Person ist, die jede Bestellung über 500 Dollar genehmigen muss, haben Sie einen Engpass in Ihren eigenen Notfallprozess eingebaut.

Die Incident-Commander-Rolle ist nicht optional

Eine Person leitet den Incident. Nicht automatisch die ranghöchste Ingenieurin — die Person, die am besten koordinieren, delegieren und Eindämmungsentscheidungen unter Druck treffen kann. Diese Person muss während der Reaktion nicht zwingend eine Tastatur anfassen; sie verfolgt die Timeline, verwaltet die Kommunikation mit Recht und Geschäftsleitung und entscheidet, wann das Signal zum Isolieren eines Segments oder zum Offline-Nehmen eines Systems gegeben wird.

Ohne diese Rolle haben Sie fünf Personen SSH'd in die gleiche Box, keine spricht mit der anderen, und niemand erfasst flüchtigen Speicher, bevor jemand die Maschine neu startet, um "zu sehen, ob es das behebt".

Eindämmungsentscheidungen, die wirklich zählen

Der schwierigste Anruf in den meisten Incidents ist: Jetzt isolieren oder ein wenig länger beobachten, um das Ausmaß zu verstehen? Netzwerkzugriff zu früh zu unterbrechen verrät einen Angreifer, der sich immer noch seitlich bewegt, und zerstört Ihre Chance, seinen nächsten Schritt zu sehen. Zu lange zu warten lässt Ransomware Freigaben fertig verschlüsseln.

Ein vernünftiger Mittelweg: Verwenden Sie Netzwerksegmentierung und EDR-Isolierung (CrowdStrike, Defender for Endpoint, SentinelOne unterstützen dies alle), um einen Host von lateraler Bewegung abzuschneiden und ihn dabei eingeschaltet zu halten, um Speicher zu erfassen. Ein vollständiger Shutdown sollte ein letzter Ausweg sein — er zerstört flüchtige Beweise und kann bei Ransomware-Fällen das Anti-Forensik-Verhalten auslösen, das in manchen Payloads verankert ist.

Logging-Lücken, die Sie während, nicht vorher bereuen werden

Windows Event Log-Standardwerte sind nicht genug. Wenn Sie Sysmon nicht mit einer anständigen Konfiguration bereitgestellt haben (SwiftOnSecurity's oder Olaf Hartong's Baseline-Configs sind ein solider Ausgangspunkt), werden Sie Prozessbäume aus Fragmenten rekonstruieren müssen. Auf der Netzwerkseite sind NetFlow- oder Zeek-Logs wichtiger als den meisten Organisationen bewusst ist, bis sie antworten müssen