Incident-Response-Prozess: Flussdiagramm für Sicherheitsvorfälle

Was ist incident-response-prozess: flussdiagramm für sicherheitsvorfälle?

Ein Incident-Response-Prozess ist die Abfolge, die eine Organisation von dem Moment an durchläuft, in dem etwas Verdächtiges auffällt, bis zu dem Moment, in dem der Vorfall geschlossen wird. Er ist bewusst nicht dasselbe wie ein IT-Störungsprozess. Das Ziel ist nicht nur, den Dienst wiederherzustellen, sondern zu rekonstruieren, was ein Angreifer getan hat, ihn daran zu hindern, weiterzumachen, die Beweise unversehrt zu halten und zu entscheiden, ob der Vorfall einer Aufsichtsbehörde gemeldet werden muss.

Die veröffentlichten Verfahren haben fast alle dasselbe Skelett. NIST SP 800-61r2 gliedert in Vorbereitung, Erkennung und Analyse, Eindämmung, Bereinigung und Wiederherstellung sowie Nachbereitung. ISO/IEC 27035 verwendet Planung und Vorbereitung, Erkennung und Meldung, Bewertung und Entscheidung, Reaktion sowie Lehren aus dem Vorfall. Das Diagramm folgt dieser Form und zieht die beiden Entscheidungen heraus, über die im laufenden Vorfall am meisten gestritten wird: Ist das überhaupt ein Sicherheitsvorfall, und ist die Datenpanne meldepflichtig?

Was Teams unter Druck falsch machen, sind meist die Reihenfolgeregeln. Wer ein System zur Eindämmung einfach ausschaltet, vernichtet die flüchtigen Speicherbeweise. Wer einen Server neu aufsetzt, bevor der Umfang analysiert ist, kann später nicht mehr belegen, was abgeflossen ist. Wer den Dienst wiederherstellt, bevor die Systeme nachweislich sauber sind, infiziert die Umgebung erneut. Diese Reihenfolge vorab zu vereinbaren, mit einer Bahn je Rolle, ist die einzige Art, wie sie einen Anruf um drei Uhr morgens übersteht.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Rollenbahnen (Meldende Person / Detektion, Security-Team, Incident Commander, IT-Betrieb sowie Recht und Kommunikation) über fünf Phasen: Erkennung und Meldung, Triage und Einstufung, Eindämmung, Bereinigung und Wiederherstellung sowie Meldung und Nachbereitung.
• Erkennung und Meldung: Eine verdächtige Aktivität wird über einen einzigen Incident-Kanal gemeldet, danach erfasst das Security-Team den Vorfall und startet die Zeitachse, die später jede Meldefrist belegen muss.
• Die Entscheidung „Bestätigter Sicherheitsvorfall?“ nach der Triage: Fehlalarme werden dokumentiert geschlossen, bestätigte Vorfälle laufen weiter in die Einstufung von Schweregrad und Auswirkung.
• Die Entscheidung „Vorfall mit hohem Schweregrad?“, die bei hohem Schweregrad einen namentlich benannten Incident Commander einsetzt und alle anderen Fälle direkt in die Eindämmung führt.
• Eindämmung in zwei Stufen: Der IT-Betrieb isoliert betroffene Systeme, dazwischen sichert das Security-Team Beweise und erstellt Abbilder, danach folgt die langfristige Eindämmung, die Analyse von Umfang und betroffenen Daten, die Beseitigung der Bedrohung und die Prüfung „Systeme nachweislich sauber?“, die bei Nein zurück in die Isolierung führt.
• Die Entscheidung „Meldepflichtige Datenpanne?“ in der Bahn Recht und Kommunikation: Der Ja-Zweig führt zur Meldung an die Aufsichtsbehörde und zur Benachrichtigung der betroffenen Personen innerhalb der gesetzlichen Frist, danach folgen für beide Zweige die Nachbereitung und der Abschluss mit festgehaltenen Lehren.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten einen Incident-Response-Plan und brauchen eine Seite, die zeigt, wer was in welcher Reihenfolge tut.
• Sie bereiten ein ISO-27001-Audit oder ein Kunden-Sicherheitsassessment vor und sollen einen dokumentierten Reaktionsprozess vorlegen (das Diagramm belegt den Prozess, es begründet für sich genommen keine Konformität).
• Sie führen eine Tabletop-Übung durch und wollen Entscheidungspunkte, Übergaben und die Meldefrist ausgelegt haben, um sie durchzuspielen.
• Sie schulen neue Analysten oder eine Rufbereitschaft, die auch Personen außerhalb des Security-Teams umfasst.
• Sie wollen, dass Security, IT-Betrieb und Rechtsabteilung ihre Übergaben vor einem Vorfall abstimmen und nicht während eines Vorfalls.

So funktioniert es

1. 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.

2. 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?

3. 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.

4. 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.

5. 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.

6. 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.