dotshock | shutterstock.com

Angenommen, Ihr Unternehmen wird von Cyberkriminellen angegriffen, kommt dabei aber mit einem blauen Auge davon, weil die Attacke zwar spät, aber noch rechtzeitig entdeckt und abgewehrt werden konnte – ohne größeren Business Impact. Jetzt einfach wie bisher weiterzumachen und die Sache zu vergessen, wäre allerdings kontraproduktiv. Schließlich haben die Angreifer einen Weg gefunden, Ihre Systeme zu kompromittieren und dabei Abwehrmaßnahmen zu umgehen.

Deshalb ist an dieser Stelle ein Post-Incident Review essenziell: Ein strukturierter Prozess, in dessen Rahmen das Unternehmen analysiert,  

• was gut gelaufen ist,
• was nicht, und
• wie die Performance in Zukunft verbessert werden kann.

Das klingt erst einmal simpel – allerdings gilt es einige wichtige Dinge zu beachten, um eine robuste Post-Incident-Review-Strategie zu entwickeln. Welche das sind, haben wir im Gespräch mit verschiedenen Sicherheitsexperten herausgearbeitet.

1. Zeitnah handeln

Nicht nur wenn es um die Analyse geht, ist Timing bei Security Incidents von entscheidender Bedeutung. Lassen Sie erst einmal Wochen oder Monate ins Land ziehen, bevor Sie ein Post-Incident Review anberaumen, steigt das Risiko, dass wichtige Elemente in Vergessenheit geraten – und Sicherheitsentscheider und ihre Teams sich kein vollständiges Bild von dem Angriff mehr machen können.  

David Taylor, Managing Director bei der IT-Beratung Protiviti, rät deshalb dazu, möglichst zeitnah tätig zu werden: “Ein Review kurz nach einem Incident gewährleistet, dass alle Details noch frisch in den Köpfen sind und vermittelt zudem ein Gefühl von Dringlichkeit”. Zudem könnten die Review-Beteiligten auf diese Weise auch eine akkurate Timeline der Ereignisse erarbeiten, so der Chefberater.   

Wie diese Timeline ausgestaltet werden sollte, weiß Heather Clauson Haughian, Mitbegründerin und geschäftsführende Partnerin der auf Datenschutz spezialisierten Anwaltskanzlei CM Law: “Zunächst gilt es, festzuhalten, was genau passiert ist – von den ersten Anzeichen eines Problems bis hin zu seiner Bewältigung.”

Das unterstütze alle Beteiligten dabei, nachzuvollziehen, an welchen Stellen es zu Verzögerungen oder Fehlern gekommen ist – und an welchen nicht. “Es geht im Grunde darum, den Vorfall in eine verständliche ‚Story‘ zu gießen und daraus entsprechende Lehren zu ziehen”, erklärt die Rechtsexpertin.

2. Ursachenanalyse fahren

Pflichtbestandteil eines Post-Incident Reviews ist zudem eine Ursachenanalyse (auch Root Cause Analysis) – zumindest wenn Ihnen daran gelegen ist, künftige Incidents zu verhindern.

Dieser Überzeugung ist auch Michael Brown, Field CISO beim IT-Dienstleister Presidio: “Die Grundursache eines Vorfalls zu identifizieren, ist essenziell. Die Teams müssen herausfinden, ob es sich dabei um eine technische Schwachstelle, menschliches Versagen oder Prozess- beziehungsweise Technologielücken handelt. Nur so lässt sich sicherstellen, dass nicht nur Symptome behandelt werden.”

3. Lücken identifizieren

Ein Post-Incident Review sollte darüber hinaus auch beinhalten, die Performance des Sicherheitsteams mit Blick auf etablierte Prozesse (etwa den Incident-Response-Plan) zu evaluieren. Das ist laut Protiviti-Manager Taylor unerlässlich, um die Team-Fähigkeiten sukzessive zu verbessern: “Es kann wertvolle Informationen für innovative Optimierungen liefern, Schulungslücken identifizieren und Ineffizienzen in der Reaktionsphase beseitigen.”

Presidio geht diesbezüglich mit gutem Beispiel voran, wie Field CISO Brown verrät: “Im Rahmen unserer Post-Incident Reviews bewerten wir die Leistung unseres Incident-Response-Teams in unterschiedlichen Bereichen – etwa Detection, Reaktionszeit, Kommunikation, Koordination oder Prozesstreue.”

4. Business Impact analysieren

Die Auswirkungen eines Sicherheitsvorfalls vollumfänglich zu durchdringen, ist eine vielschichtige Angelegenheit, die sowohl quantitative als auch qualitative Analysen umfassen sollte. Ersteres sollte laut Sicherheitsentscheider Brown beispielsweise Aspekte wie finanzielle Einbußen, verlorene Marktanteile oder Kundenaufträge beinhalten.

Zweiteres sich hingegen mit Fragen befassen wie:

• Wurde die Business Continuity nachhaltig beeinträchtigt?
• Wurden die zuständigen Behörden rechtzeitig informiert?
• Sind Reputationsschäden entstanden?

5. Kontext erfassen

Ein weiterer Schlüsselfaktor für Post-Incident-Analysen ist außerdem der Kontext des Sicherheitsvorfalls. Ihn zu erfassen, ist entscheidend, wenn es darum geht, eine Timeline für den Incident aufzusetzen, aus der alle Beteiligten lernen können.

“Allzu oft wird bei Nachbesprechungen der Kontext, in dem Entscheidungen getroffen wurden, übersprungen”, kritisiert Security-Forscher Eireann Leverett und ergänzt: “Dokumentieren Sie den Vorfall so, wie er sich entwickelt hat – nicht nur das Ergebnis. Incidents entwickeln sich im Zeitverlauf – und das Team, das diesen bearbeitet, kann selten vorab auf sämtliche Fakten zugreifen.”

Jede neue Entdeckung – etwa mit Blick auf das Einfallstor für den Angriff, seinen Scope oder die von den Angreifern verwendeten Tools, könnten die Untersuchungsziele des Teams verändern, so Leverett: “Was als Containment-Vorhaben beginnt, kann schnell zum umfänglichen Recovery-Projekt ausarten. Nur wenn Sie tracken, wann und warum Veränderungen stattgefunden haben, ist später auch nachvollziehbar, welche Maßnahmen ergriffen wurden.”

6. Abteilungsübergreifend kollaborieren

Ein Post-Incident Review zu leiten, ist Sache des CISO – oder anderer Security- oder IT-Führungskräfte. Allerdings ist es empfehlenswert, auch Personen aus anderen Abteilungen einzubinden, die potenziell Insights beitragen können. So empfiehlt etwa Sicherheitsexperte Leverett, das Post-Incident-Team um Kollegen aus den Bereichen Governance, Recht und Risikomanagement zu erweitern: “Diese können die Grundursache des Incidents möglicherweise mit allgemeinen, breiter angelegten Richtlinienlücken in Verbindung bringen.”

Sinnvoll ist nach Meinung von Leverett außerdem, die Finanz- und Personalabteilung einzubinden, sowie – je nach Art und Schwere des Vorfalls – auch Vorstandsmitglieder. Letzteres signalisiere eine strategische Priorisierung und unterstütze dabei, technische Erkenntnisse mit Risiko-Diskussionen auf Governance-Ebene zu verknüpfen, ist der Experte überzeugt.

“Wichtig ist dabei, dass alle Beteiligten gleichberechtigt zu Wort kommen – unabhängig von ihrer Position oder Rolle”, ergänzt Protiviti-Mann Taylor. Das trage nicht nur dazu bei, Security-Vorfälle besser zu durchdringen, sondern etabliere auch ein kooperatives Umfeld.

7. Schuldzuweisungen vermeiden

Im Rahmen eines Post-Incident Reviews “Fingerpointing” zu betreiben, ist mit hoher Wahrscheinlichkeit nicht produktiv. Deshalb empfiehlt auch IT-Anwältin Haughian, den Fokus darauf zu legen, zu lernen und zu optimieren: “Schuldzuweisungen bringen Sie nicht weiter. Es gilt, den tatsächlichen Ablauf der Ereignisse aufzudecken, Entscheidungsprozesse zu verstehen und alle Faktoren zu identifizieren, die zu Fehlern beigetragen haben. Dieser Ansatz kann dabei helfen, künftige strategische Entscheidungen in Zusammenhang mit Tools, Schulungen und Richtlinien zu treffen.”

Auch Leverett hält nichts von einer Kultur der Schuldzuweisung: “Es geht nicht darum, ob ein bestimmtes Individuum die richtige Entscheidung getroffen hat oder nicht. Vielmehr gilt es Fragen zu klären wie: ‚War das Team unter den gegebenen Umständen in der Lage, gute Entscheidungen zu treffen?‘ Oder: ‚Hätten eine bessere Dokumentation, andere Tools oder mehr Budget für schnellere und bessere Ergebnisse gesorgt?‘”

8. Aktiv werden

Sämtliche Erkenntnisse, die im Rahmen eines Post-Incident Reviews gewonnen werden, sind relativ nutzlos, wenn im Nachgang nichts passiert. Soll heißen: Den Erkenntnissen müssen konkrete Maßnahmen folgen.  

Um das bestmöglich umzusetzen, empfiehlt Rechtsexpertin Haughian, schriftlich genau festzuhalten, an welchen Stellen optimiert werden muss, wann das geschehen soll und wer dafür verantwortlich zeichnet: “Diese Verbesserungen können etwa Softwareaktualisierungen, Richtlinienänderungen oder neue Schulungsinitiativen sein. Unabhängig davon macht diese Nachbereitung ein Post-Incident Review erst wirklich nützlich. Bleibt sie aus, entfallen damit auch umsetzbare Empfehlungen – und das Ganze ist nicht mehr als eine akademische Übung”, hält die Datenschutzexpertin fest. (fm)

Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox.