Bedrohungen & Vorfälle

Welche Bedrohungen oder Vorfälle haben wir in diesem Zyklus bearbeitet?

Wir haben eine Phishing-Kampagne gegen die Finanzabteilung innerhalb von 30 Minuten nach der ersten Meldung eingedämmt.
Ein falsch konfigurierter S3-Bucket hat interne Logs offengelegt, Kundendaten waren aber nicht betroffen.
Am Wochenende gab es mehrere Brute-Force-Anmeldeversuche auf unser VPN-Gateway.
Kontrollen & Erfolge

Welche Abwehrmaßnahmen, Tools oder Prozesse haben gut funktioniert?

Unsere SIEM-Korrelationsregeln haben den Lateral-Movement-Versuch früh erkannt.
Dank des Übergabedokuments für die Rufbereitschaft lief die Eskalation um 2 Uhr nachts reibungslos und schnell.
Die automatische Eindämmung in unserem EDR hat uns Stunden manueller Arbeit erspart.
Lücken & Schwachstellen

Wo hatten wir blinde Flecken oder Schwächen?

Wir hatten keinerlei Einblick in die kompromittierte SaaS-App des Drittanbieters.
Wegen Alert Fatigue blieb ein echtes Signal zwei Stunden lang unbearbeitet.
Unser Patch-Zyklus ist für kritische CVEs zu langsam.
Maßnahmen & Härtung

Was tun wir, um unsere Sicherheitslage zu verbessern?

SIEM-Regeln bis zum nächsten Review so anpassen, dass die False Positives um 25 % sinken.
Die SaaS-App des Drittanbieters in den Umfang unseres kontinuierlichen Monitorings aufnehmen.
In diesem Sprint ein Playbook für die Übernahme von Cloud-Konten erstellen und testen.

Was ist die Cyber-Security-Ops-Retrospektive?

Die Cyber-Security-Ops-Retrospektive bringt euer Security-Operations-Team zusammen, um auf den letzten Zyklus zurückzublicken: was ihr erkannt habt, wie ihr reagiert habt und wie ihr den Normalbetrieb wiederhergestellt habt. Sie richtet sich an SOC-Analysten, Incident Responder, Threat Hunter und Security Engineers, die aus Alerts, Vorfällen und Beinahe-Vorfällen konkrete Verbesserungen ableiten wollen. Das Board hat vier Spalten. Unter „Bedrohungen & Vorfälle“ haltet ihr fest, was passiert ist. „Kontrollen & Erfolge“ dokumentiert die Tools und Prozesse, die funktioniert haben. „Lücken & Schwachstellen“ umfasst die blinden Flecken und Schwächen, die sichtbar wurden. Unter „Maßnahmen & Härtung“ vereinbart ihr, was sich ändern soll, mit einer verantwortlichen Person für jeden Punkt. Wenn ihr bereits mit MITRE ATT&CK oder dem NIST CSF arbeitet, ordnet die Erkenntnisse diesen Frameworks zu, damit ihr den Fortschritt von Zyklus zu Zyklus verfolgen könnt. Achtet darauf, dass niemand beschuldigt wird. Nur wenn alle wissen, dass es um Systeme und Prozesse geht, sprechen sie offen über den übersehenen Alert oder den Beinahe-Vorfall, den sie selbst verursacht haben. Führt die Retrospektive nach einem größeren Vorfall, am Ende einer Rufbereitschaftsrotation oder in festen Abständen durch, und prüft die Maßnahmen aus dem letzten Zyklus, bevor ihr neue hinzufügt.

Format der Cyber-Security-Ops-Retrospektive

Bedrohungen & Vorfälle

Welche Bedrohungen oder Vorfälle haben wir in diesem Zyklus bearbeitet?

Sammelt die Alerts, Ereignisse und Vorfälle, die das Team in diesem Zeitraum bearbeitet hat. Bittet alle, sich darauf zu beschränken, was passiert ist, wann und was betroffen war, ohne Schuld zuzuweisen. So haben alle denselben Kenntnisstand, bevor ihr besprecht, was funktioniert hat.

Kontrollen & Erfolge

Welche Abwehrmaßnahmen, Tools oder Prozesse haben gut funktioniert?

Benennt die Kontrollen, Automatisierungen und Übergaben, die euch geschützt haben, und seid konkret, welches Tool oder welcher Prozess die Arbeit geleistet hat. Erfolge gehen in Security-Teams leicht unter. Wenn ihr sie festhaltet, wisst ihr, was ihr beibehalten solltet.

Lücken & Schwachstellen

Wo hatten wir blinde Flecken oder Schwächen?

Hier kommen Erkennungslücken, Grenzen der Tools, Reibung in Prozessen und ungepatchte Risiken auf den Tisch. Sorgt dafür, dass niemand beschuldigt wird, damit auch unangenehme Punkte angesprochen werden. Was hier landet, bestimmt meist den Großteil des Maßnahmenplans.

Maßnahmen & Härtung

Was tun wir, um unsere Sicherheitslage zu verbessern?

Macht aus den Lücken Maßnahmen mit einer verantwortlichen Person und einem Termin. Priorisiert sie nach Eintrittswahrscheinlichkeit und Auswirkung und verknüpft jede Maßnahme mit der Lücke, die sie schließt, damit ihr beim nächsten Mal den Fortschritt prüfen könnt.

Wann sollte diese Retrospektive durchgeführt werden?

  • Nach einem schwerwiegenden Sicherheitsvorfall oder einer Datenpanne, um Erkenntnisse ohne Schuldzuweisungen festzuhalten.
  • Am Ende einer Rufbereitschafts- oder SOC-Schichtrotation, um die Alerts und Übergaben zu besprechen.
  • Monatlich oder quartalsweise, um wiederkehrende Lücken zu verfolgen und zu prüfen, ob die Korrekturen aus dem letzten Zyklus gehalten haben.
  • Nach einer Tabletop-Übung, einem Red-Team-Einsatz oder einem Penetrationstest, um gemeinsam festzulegen, was die Ergebnisse für euer Team bedeuten.
  • Wenn ihr neue SecOps-Tools oder -Praktiken eingeführt habt und prüfen wollt, ob sie funktionieren.

Vorschläge für Fragen zum Icebreaker

  • Wenn du einen Tag lang Hacker wärst, was wäre deine Waffe der Wahl und warum?
  • Was war der kreativste Phishing-Versuch, den du je gesehen hast, und hätte er fast funktioniert?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Beschuldigt niemanden. Sprecht über Systeme und Prozesse statt über einzelne Personen, damit Fehler und Beinahe-Vorfälle offen zugegeben werden.
  • Ordnet die Erkenntnisse einem Framework wie MITRE ATT&CK oder NIST CSF zu, damit sich Verbesserungen über längere Zeit leicht verfolgen lassen.
  • Ladet Analysten, Responder, Engineers und eine Führungskraft ein. Jede Rolle sieht blinde Flecken, die den anderen entgehen.
  • Lasst alle ihre Notizen zuerst verdeckt oder anonym erfassen, damit auch Junior-Analysten Probleme ansprechen, ohne sich den Erfahreneren unterzuordnen.
  • Setzt für jede Spalte ein Zeitlimit und reserviert den letzten Teil der Sitzung dafür, aus Lücken Maßnahmen mit Verantwortlichen und Terminen zu machen.
  • Verfolgt die Maßnahmen von einer Retrospektive zur nächsten, damit wiederkehrende Schwachstellen nicht unbemerkt liegen bleiben.

Häufig gestellte Fragen

Wann sollten wir eine Cyber-Security-Ops-Retrospektive durchführen?
Führt sie nach einem größeren Vorfall, am Ende einer Rufbereitschaftsrotation oder monatlich bzw. quartalsweise durch. Ein fester Rhythmus hilft euch, wiederkehrende Lücken zu erkennen, bevor daraus Vorfälle werden.
Wie lange dauert eine Cyber-Security-Ops-Retrospektive?
Plant 45 bis 75 Minuten ein, je nach Teamgröße und Anzahl der zu besprechenden Vorfälle. Ein Zeitlimit für jede der vier Spalten hält die Sitzung im Rahmen.
Worin unterscheidet sich das von einem klassischen Incident-Postmortem?
Ein Postmortem geht tief in einen einzelnen Vorfall. Diese Retrospektive betrachtet den ganzen Zyklus, von den bearbeiteten Alerts über die wirksamen Kontrollen bis zu den gefundenen Lücken. Erkenntnisse aus Postmortems sind dafür ein guter Input.
Wie stellen wir sicher, dass in der Retrospektive niemand beschuldigt wird?
Sprecht über Systeme, Prozesse und Tools statt über einzelne Personen, und beginnt mit verdeckten oder anonymen Notizen. Wer keine Schuldzuweisung fürchten muss, berichtet eher von Beinahe-Vorfällen.
Wer sollte an einer Cyber-Security-Ops-Retrospektive teilnehmen?
SOC-Analysten, Incident Responder, Threat Hunter, Security Engineers und jemand aus dem Management. Durch die Mischung der Rollen werden blinde Flecken sichtbar, die einer einzelnen Gruppe entgehen würden.
Können wir die Erkenntnisse mit Security-Frameworks verknüpfen?
Ja. Wenn ihr die Erkenntnisse MITRE ATT&CK oder dem NIST CSF zuordnet, habt ihr einen gemeinsamen Bezugsrahmen und könnt den Fortschritt über mehrere Zyklen leichter messen.
Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus