Die 7 Red Flags bei der Erstellung eines Incident-Response-Plans (IRP)

Ein sorgfältig ausgearbeiteter Incident-Response-Plan (IRP) kann Ihre Organisation auf den Ernstfall vorbereiten und Ihnen ermöglichen, strukturierter, effizienter und umfassender auf Vorfälle zu reagieren. Der Incident-Response-Plan zeigt ein strukturiertes Vorgehen zur Behandlung eines Cyber-Vorfalls und dient als Leitfaden für sämtliche Phasen des Incident-Response-Prozesses. Dadurch erhöhen Sie Ihre Incident Response Readiness.

Die Qualität solcher Incident-Response-Pläne ist von Unternehmen zu Unternehmen unterschiedlich. Dabei variiert der Umfang von 2 kurzen A4-Seiten bis hin zu umfangreichen 50-seitigen Konzepten. Oneconsult hat bereits viele dieser Notfallpläne gesehen, überprüft und überarbeitet. Dabei haben wir eine Liste der 7 «Red Flags» erstellt, auf die Sie bei der Entwicklung Ihres eigenen IRP achten und die Sie beheben sollten, um optimal und effektiv auf Vorfälle vorbereitet zu sein.

Red Flag 1: Keine Definition, Einordnung und Priorisierung der Vorfälle

Das erste «Red Flag», auf das wir bei der Überprüfung der Incident-Response-Pläne stossen, ist, dass die Vorfälle nicht definiert, eingeordnet und priorisiert werden. Dies führt im Ernstfall zu einem erheblichen Zeitverlust.

Eine Definition, Einordnung oder Unterscheidung zwischen verschiedenen Schweregraden und deren Priorisierung ist entscheidend, um Unter- oder Überreaktionen zu vermeiden. Typische Schweregrade von Vorfällen sind folgende:

• Ereignis
• Sicherheitsvorfall
• Krise

Die Einstufung des Schweregrades kann beispielsweise anhand der Auswirkungen, der Dringlichkeit, des finanziellen Schadens, des Ausmasses (Anzahl der betroffenen Systeme), des Reputationsschadens und des Aufwands für die Bewältigung des Vorfalls definiert werden. Auf diese Weise können Vorfälle schnell eingeschätzt und entsprechend priorisiert werden. Dadurch wird Zeit bei der Entscheidungsfindung (siehe Red Flag 2) und der Eskalation (siehe Red Flag 3) gespart, was einen direkten Einfluss auf die Reaktionszeit auf die verschiedenen Vorfälle hat. Je nach Kategorisierung wäre beispielsweise eine Warnmeldung eines Antivirenprogramms ein Ereignis, die Kompromittierung einer Geschäfts-E-Mail ein Sicherheitsvorfall und die Verschlüsselung von Systemen durch Ransomware eine Krise. Die Reaktion und Bewältigung unterscheiden sich stark zwischen diesen drei Szenarien. Die für ein Unternehmen relevanten Szenarien sollten in Abhängigkeit von dem, was geschäftskritisch ist, definiert und im Rahmen des Incident-Response-Plans abgedeckt sein.

Red Flag 2: Keine Rollendefinition der Notfallorganisation

Das zweite Problem ist eine fehlende oder unklare Rollendefinition in der Notfallorganisation. Diese umfasst Entscheidungsträger, Kompetenzen, Verantwortlichkeiten und Zuständigkeitsbereiche. Jede Rolle sollte daher eine verantwortliche Person und mindestens eine Stellvertretung haben, um adäquat reagieren zu können, auch wenn ein Mitarbeitender im Urlaub, krank oder verhindert ist.

Bei einem Cyber-Vorfall kommt das Incident Response Team beziehungsweise die Notfallorganisation zum Zuge. Cyber-Vorfälle betreffen oft nicht nur die IT-Abteilung, sondern auch andere Abteilungen, beispielsweise im Falle einer Krise:

• Geschäftsleitung
• Rechtsabteilung
• Kommunikationsabteilung
• HR
• Datenschutzbeauftragter
• etc.

Alle diese Parteien sollten zumindest optional oder bei Bedarf in den Incident-Response-Plan aufgenommen werden. Jeder sollte seine Rolle verstehen und sich über die damit verbundenen Aufgaben im Klaren sein. Zu wissen, wer im Falle eines Vorfalls welche Aufgaben übernimmt, spart Zeit, schafft Klarheit und vermeidet unnötigen Stress. 

Hinzu kommen noch externe Parteien, wie Cyber-Versicherungen, Dienstleister und Incident Response Provider. Legen Sie im Voraus fest, welche Partner informiert oder einbezogen werden müssen. Achten Sie ebenfalls auf die Vertragsbedingungen hinsichtlich der Frage, wie schnell Sie Unterstützung erhalten werden.

Darüber hinaus sollte eine Kontaktliste (siehe Blog DFIR, einfach: Wen ruft man im Cyberernstfall?) mit internen und externen Ansprechpartnern sowie Stellvertretern beiliegen. Darin sollten die verschiedenen Kommunikationskanäle enthalten sein, idealerweise mit Angabe der Privatnummer, um die Erreichbarkeit zu gewährleisten.

Fügen Sie die Kontaktliste dem Incident-Response-Plan bei, um Änderungen, Ergänzungen und Streichungen in der Liste zu erleichtern. Auf diese Weise kann der Anhang als «lebender Teil» verwendet werden, der nicht genehmigt werden muss. Überprüfen, überarbeiten und passen Sie die Kontaktliste regelmässig, beispielsweise jährlich, an. Dies gilt auch für den Incident-Response-Plan selbst.

Red Flag 3: Keine Meldeverfahren und Eskalationswege

Ein weiteres «Red Flag» ist das Fehlen von Meldeverfahren und Eskalationswegen innerhalb der Notfallorganisation. Ein Mangel an proaktivem Engagement und Eskalation kann die Reaktion auf einen Vorfall verzögern und Angreifern möglicherweise wertvolle Zeit verschaffen, um ihre Aktionen erfolgreich durchzuführen. In den Fällen, die wir als CSIRT (Computer Security and Incident Response Team) bearbeiten, werden wir oft zu spät informiert und der Schaden ist bereits sehr gross. Bei rechtzeitiger Benachrichtigung hätte der Schaden erheblich reduziert werden können.

Es sollte festgelegt werden, wer in welcher Reihenfolge und mit welcher Dringlichkeit kontaktiert werden muss. Hierbei ist nach Schweregrad des Vorfalls zu unterscheiden (siehe Red Flag 1). Dies beeinflusst, welche Stakeholder einbezogen werden sollen und müssen. Besteht darüber hinaus eine Informationspflicht, beispielsweise im Rahmen einer Cyber-Versicherung, sollte die Meldefrist dokumentiert sein. Gleiches gilt für sonstige Meldepflichten wie bei Anforderungen der geltenden Datenschutzbestimmungen.

Die Meldeverfahren und Eskalationswege sollten klar und übersichtlich dargestellt werden, zum Beispiel in Form einer Matrix oder einer Liste. Dies ermöglicht einen schnellen Überblick über die Personen, die informiert werden müssen. Auf diese Weise weiss jeder auf den ersten Blick, wie ein Vorfall zu melden oder zu eskalieren ist. Die Matrix könnte beispielsweise wie folgt aussehen:

Wichtig ist in diesem Zusammenhang auch die Festlegung des Kommunikationsmittels (Telefon, E-Mail, SMS etc.), über das die Eskalation erfolgen soll. Für den Fall, dass dieses nicht mehr zur Verfügung steht, ist auch ein Notfallkommunikationsmittel zu definieren.

Red Flag 4: Keine Krisenkommunikation

Sobald der Vorfall und sein Ausmass identifiziert sind, gilt es, je nach Schweregrad des Vorfalls, dies den Mitarbeitenden und allen Betroffenen mitzuteilen. Es ist wichtig, die Kommunikationswege festzulegen und alternative Kanäle zu definieren, falls der Hauptkommunikationskanal nicht verfügbar ist.

Hier ist es besonders wichtig zu definieren:

• Wer für die Kommunikation zuständig ist.
• Wer zu welchem Zeitpunkt informiert werden muss.
• Wie die Information zu erfolgen hat.
• Was kommuniziert werden soll.

Für den letzten Punkt empfiehlt es sich, je nach Szenario und Ansprechpartner, vordefinierte Texte zu erstellen, um im Notfall bezüglich der Kommunikation mit

• Mitarbeitenden
• Kunden/Lieferanten/Partnern
• Presse/Medien

schnell und bestimmt handeln zu können. Die Meldung sollte insbesondere enthalten, um welche Art von Vorfall es sich handelt, ob der Vorfall noch andauert, welche Massnahmen zur Eindämmung oder Behebung des Vorfalls ergriffen wurden und ob andere Organisationen (zum Beispiel Behörden) an der Bewältigung des Vorfalls beteiligt sind. Weitere Empfehlungen zu diesem Thema finden Sie im Blogbeitrag des CERT NZ (Neuseelands Computer Emergency Response Team).

Unsere Erfahrung und die in den Medien publizierten Vorfälle zeigen: Eine angemessene, zeitgerechte und transparente Kommunikation trägt dazu bei, die Beteiligten zu beruhigen, den Ruf Ihrer Organisation zu schützen und das Vertrauen der Stakeholder zu erhalten oder sogar wieder aufzubauen. Geben Sie jedoch nicht zu viele Informationen preis, da dies die Aufmerksamkeit der Angreifer auf sich ziehen könnte. Gerade zu Beginn der Vorfallsbewältigung gilt es, so viel wie nötig, aber so wenig wie möglich zu kommunizieren. Es ist daher von entscheidender Bedeutung, dass ein Unternehmen im Rahmen einer IRP festlegt, wie im Falle eines Cyber-Vorfalls kommuniziert werden soll.

Red Flag 5: Keine definierten Massnahmen

Wenn das Vorgehen und insbesondere die bei jeder Phase des Incident-Response-Prozesses zu ergreifenden Massnahmen nicht klar definiert sind, kann einiges schief gehen. Die Situation kann sich sogar noch verschlimmern, wenn die Massnahmen nicht angemessen sind oder nicht zum richtigen Zeitpunkt eingeleitet werden.

Klar definierte und nachvollziehbare Handlungsprozesse helfen bei der Einleitung geeigneter Massnahmen zur Eindämmung und Bewältigung sowie bei der Wiederherstellung. Sie sollten genau aufzeigen, was in welcher Phase zu tun ist und wer die Verantwortung trägt. Die zu ergreifenden Massnahmen hängen vom Schweregrad und der Art des Vorfalls ab. Beispiele sind die Isolierung betroffener Dateien, Systeme oder Netzwerksegmente, die Deaktivierung von Benutzerkonten und das Zurücksetzen aller Passwörter.

Als nützliche Ergänzungen zum IRP können Playbooks oder Checklisten entwickelt werden, die allgemeine Sofortmassnahmen oder Schritte zur Verbesserung und Beschleunigung des Incident-Response-Prozesses enthalten. Dokumente wie ein Asset-Inventar, ein Netzwerkplan, ein Backup-Konzept und ein Desaster-Recovery-Plan sind ebenfalls sehr nützlich und sollten mit dem Incident-Response-Plan verknüpft werden.

Red Flag 6: Keine ausgedruckte Version des Incident-Response-Plans

Bei den Vorfällen, mit denen das Oneconsult CSIRT befasst war, kam es vor, dass der Incident-Response-Plan weder ausgedruckt noch in einer Offline-Version verfügbar war, so dass dieser zum Zeitpunkt des Angriffs nicht mehr zur Verfügung stand und viel Zeit verloren ging, bis die zentralen Punkte zum weiteren Vorgehen zusammengetragen wurden.

Wir empfehlen, eine ausgedruckte Kopie des Plans anzufertigen und an einem sicheren Ort aufzubewahren. Dadurch wird sichergestellt, dass der IRP auch beim Ausfall zentraler IT-Komponenten verfügbar ist.

Neben dem Incident-Response-Plan werden oft auch andere Dokumente/Informationen nicht krisensicher aufbewahrt, wie zum Beispiel:

• Alle notwendigen referenzierten Dokumente wie zum Beispiel Wiederherstellungspläne
• Ein Krisenkommunikationsplan
• Lizenzen und Schlüssel
• Wichtige Passwörter

Diese können auf einem «Emergency USB Stick» gespeichert werden, um im Notfall weiterhin Zugriff auf diese wichtigen Daten zu gewährleisten. Dieser USB Stick ist ebenfalls sicher aufzubewahren.

Red Flag 7: Fehlende Übung

Ein perfekter Notfallplan ist nur halb so gut, wenn er nicht regelmässig geübt wird. Dies ist das siebte und letzte «Red Flag».

Häufig stossen wir auf sorgfältig ausgearbeitete IRPs, die sich mit den oben genannten Stolpersteinen befassen und diese abmildern. Sobald jedoch eine Übung durchgeführt und der Plan in die Tat umgesetzt wird, stellt sich heraus, dass der Prozess, wie er in der Theorie skizziert wurde, entweder völlig versagt oder nur teilweise funktioniert. In anderen Fällen hat der Prozess zwar funktioniert, aber die Mitglieder der definierten Notfallorganisation kannten den Plan nicht und waren sich daher über ihre Rollen und Verantwortlichkeiten nicht im Klaren.

Regelmässiges Training und Übungen sind daher unerlässlich, um die letzten Hindernisse zu beseitigen und den Plan zu verinnerlichen. Schliesslich kann ein Plan nur dann effizient umgesetzt werden, wenn dieser auch bekannt ist und im Ernstfall befolgt wird.

Fazit

Der Incident-Response-Plan ist eines der grundlegenden Elemente der Incident Response Readiness. Er klärt die Rollen und Verantwortlichkeiten und beschreibt Prozesse und Handlungsabläufe. Er sollte auch eine Liste der Schlüsselpersonen enthalten, die im Krisenfall hinzugezogen werden müssen. Der Plan ist daher besonders wichtig, um bei einem Vorfall richtig und rechtzeitig reagieren zu können. Typische Red Flags sind gerade das Fehlen solcher Informationen. Häufig werden auch Krisenkommunikation und -massnahmen vergessen. Drucken Sie den Incident-Response-Plan aus und testen ihn regelmässig, damit er bei einem Vorfall immer griffbereit und auf dem neuesten Stand ist.

Wenn Sie Unterstützung bei der Erstellung oder Überprüfung Ihres Incident-Response-Plans benötigen, zusätzliche Playbooks brauchen oder Ihren Incident-Response-Plan durch Tabletop-Übungen testen möchten (siehe Incident Response), setzen Sie sich gerne mit uns in Verbindung. In diesen wie auch in allen weiteren Cyber-Security-Themen helfen wir gerne weiter. Wir freuen uns auf Ihre Kontaktaufnahme: