Playbooks und Ticketing

Ein Playbook (oder Runbook) ist ein dokumentiertes, schrittweises Verfahren zur Bearbeitung eines bestimmten Alert- oder Incident-Typs. Playbooks machen die Reaktion einheitlich, schnell und auditierbar.

Ohne Playbooks könnten zwei Analysten denselben Phishing-Alert auf völlig unterschiedliche Weise bearbeiten. Mit Playbooks hängt die Qualität der Reaktion nicht davon ab, wer gerade Dienst hat.

Ein gutes Playbook hat eine vorhersehbare Struktur, damit Analysten es auch unter Druck befolgen können:

• Auslöser — welcher Alert oder welche Bedingung dieses Playbook aktiviert
• Geltungsbereich — was es abdeckt und was nicht
• Schritte — geordnete Untersuchungs- und Reaktionsmaßnahmen
• Entscheidungspunkte — Verzweigungslogik für unterschiedliche Ergebnisse
• Eskalationskriterien — wann die Übergabe erfolgt
• Abschlussbedingungen — wann der Fall abgeschlossen ist

Stellen Sie sich eine gemeldete Phishing-E-Mail vor. Ein typisches Playbook legt klare Schritte fest:

Echte Incidents verlaufen nicht linear. Playbooks enthalten Entscheidungspunkte, an denen sich der Ablauf abhängig von den Ergebnissen verzweigt.

Zum Beispiel im Phishing-Playbook:

• Hat jemand auf den Link geklickt? Wenn nein, eindämmen und schließen. Wenn ja, mit der Bearbeitung einer Kontenkompromittierung fortfahren.
• Wurden Zugangsdaten eingegeben? Wenn ja, einen erzwungenen Passwort-Reset durchführen und auf verdächtige Anmeldungen prüfen.

Durch Verzweigungen bleibt das Playbook angemessen: geringer Aufwand bei harmlosen Meldungen, vollständige Reaktion bei einer tatsächlichen Kompromittierung.

Ein Ticketsystem (Fallmanagement) ist das maßgebliche Dokumentationssystem für jeden Alert und jeden Incident. Jeder Fall ist ein Ticket, in dem die vollständige Untersuchung nachverfolgt wird.

Zu den gängigen Plattformen gehören der SOAR-Fallmanager, ServiceNow, Jira oder ein spezielles IR-Tool. Im Ticket werden Beweise, Zeitablauf und Entscheidungen festgehalten, sodass nichts vom Gedächtnis oder von Chatnachrichten abhängt.

Ein nützliches Ticket enthält alles, was zum Verständnis und zur Prüfung eines Falls erforderlich ist:

• Titel — präzise und eindeutig
• Schweregrad und Status
• Betroffene Assets und Benutzer
• Zeitablauf der Untersuchungsschritte mit Zeitstempeln
• Beweise und IOCs
• Abschlussbewertung und ergriffene Maßnahmen

Schreiben Sie das Ticket so, als würde ein fremder Mensch es ein Jahr später während eines Audits lesen, denn genau das könnte passieren.

Einheitliche Felder für Status und Schweregrad machen Warteschlangen handhabbar und Kennzahlen aussagekräftig.

Wenn ein Incident zu rechtlichen Schritten oder zur Einbeziehung der Personalabteilung führen könnte, ist der Umgang mit Beweisen wichtig. Die Beweismittelkette dokumentiert, wer welches Beweisstück wann erfasst hat und wie es gespeichert wurde.

Tickets unterstützen dies durch die Erfassung von:

• dem genauen Zeitpunkt und der Quelle jedes Artefakts
• dem Analysten, der es erfasst hat
• Hashes, die belegen, dass die Beweise nicht verändert wurden

Ein nachlässiger Umgang mit Beweisen kann dazu führen, dass Ergebnisse nicht zugelassen oder angefochten werden können.

Tickets setzen Service Level Agreements (SLAs) durch, die abhängig vom Schweregrad festlegen, wie schnell Alerts bestätigt und gelöst werden müssen.

Beispiele für SLA-Ziele:

• SEV1: innerhalb von 15 Minuten bestätigen
• SEV2: innerhalb von 1 Stunde bestätigen
• SEV3: innerhalb von 4 Stunden reagieren

Die Zeitstempel im Ticket liefern die Kennzahlen, anhand derer sich erkennen lässt, ob das SOC diese Verpflichtungen erfüllt.

Playbooks veralten, wenn sie nicht gepflegt werden. Tools ändern sich, Angreifer entwickeln sich weiter und Schritte werden überholt. Betrachten Sie Playbooks als lebende Dokumente.

Aktualisieren Sie sie, wenn:

• ein neues Tool oder eine neue Datenquelle hinzugefügt wird
• eine Analyse nach einem Incident eine Lücke aufdeckt
• eine neue Angriffstechnik auftaucht
• ein Analyst einen unklaren oder falschen Schritt entdeckt

Verwenden Sie Versionskontrolle für Ihre Playbooks und prüfen Sie sie regelmäßig nach einem festen Zeitplan.

Viele Schritte in Playbooks sind mechanisch und eignen sich ideal für die SOAR-Automatisierung. Durch ihre Automatisierung werden Analysten für Aufgaben frei, die mehr Beurteilungsvermögen erfordern.

Häufig automatisierte Schritte:

• die ursprüngliche E-Mail abrufen und IOCs extrahieren
• Reputationsabfragen durchführen
• Schadsoftware aus allen Posteingängen entfernen
• das Ticket mit den Ergebnissen aktualisieren

Die wichtigen Entscheidungen trifft weiterhin der Analyst; die Automatisierung führt lediglich die routinemäßigen Teile schneller und konsistent aus.

Testen Sie Ihr Verständnis von Playbooks und Ticketsystemen.

Sie haben gelernt, wie Playbooks und Ticketsysteme die Arbeit eines SOC strukturieren:

• Playbooks liefern konsistente, wiederholbare Schritte mit Entscheidungspunkten und Kriterien für die Eskalation
• Das Ticketsystem ist das maßgebliche Dokumentationssystem für jeden Fall
• Gute Tickets erfassen Zeitablauf, Beweise, IOCs und Abschlussbewertung und unterstützen die Beweismittelkette
• SLAs legen Reaktionszeitziele fest, die anhand der Zeitstempel im Ticket nachverfolgt werden
• Halten Sie Playbooks aktuell und automatisieren Sie ihre mechanischen Schritte mit SOAR

Als Nächstes messen Sie mithilfe von MTTD und MTTR, wie gut das SOC arbeitet.