Wenn ein Account ungewöhnlich viele Logins zeigt, ein Server plötzlich neue Administratoren hat oder Daten „verschwinden“, zählt vor allem eins: die ersten Entscheidungen müssen sitzen. In der Praxis scheitert das weniger an fehlenden Tools, sondern an unklaren Zuständigkeiten, fehlender Dokumentation und hektischer Kommunikation. Ein kompaktes Runbook (Einsatzplan) macht Teams in der ersten Stunde handlungsfähig, ohne jedes Mal bei null zu starten.
Im Fokus steht ein Runbook, das für typische Sicherheitsvorfälle funktioniert: kompromittierte Konten, Malware-Funde, Datenabfluss-Verdacht, auffällige Admin-Aktivitäten oder verdächtige E-Mail-Regeln. Es ersetzt kein Incident-Response-Programm, liefert aber den operativen Kern, der in KMU und IT-Teams sofort nutzbar ist.
Welche Vorfälle das Runbook abdecken sollte
Ein Runbook muss nicht jeden Sonderfall abbilden. Es sollte die Vorfälle abdecken, die in der Realität am häufigsten eskalieren: Identitätsmissbrauch, laterale Bewegung im Netzwerk, verdächtige Änderungen an Infrastruktur und Datenzugriffen. Für jeden Vorfallstyp reichen wenige, eindeutige Entscheidungsfragen, die zu passenden Sofortmaßnahmen führen.
Typische Auslöser, die eine Reaktion rechtfertigen
Folgende Signale sind in vielen Umgebungen belastbar genug, um das Runbook zu starten: neue Weiterleitungsregeln im Mailkonto, MFA-Änderungen ohne Change, neue OAuth-App-Zustimmungen, unbekannte Admin-Gruppenmitgliedschaften, verdächtige geplante Tasks, unerwartete ausgehende Verbindungen oder massenhafte Dateioperationen.
Wichtig ist eine klare Schwelle: Nicht „bei jedem Alarm“, sondern bei plausiblen Indikatoren. Ein Runbook definiert deshalb konkrete Trigger (z. B. „Admin-Konto kompromittiert vermutet“), statt abstrakte Begriffe wie „kritischer Alarm“ zu verwenden.
Einordnung nach Impact statt nach Bauchgefühl
Für die ersten 60 Minuten reicht eine grobe Einstufung nach Auswirkungen: betrifft der Vorfall Identitäten, Systeme oder Daten? Und wie wahrscheinlich ist eine Fortsetzung der Aktivität? Das Ziel ist nicht perfekte Klassifizierung, sondern die Auswahl der richtigen nächsten Schritte, insbesondere bei Identitätsvorfällen.
Rollen, Erreichbarkeit und Entscheidungswege festzurren
Ein Runbook wirkt nur, wenn klar ist, wer entscheiden darf und wer informiert werden muss. Praktisch hat sich eine kleine Kernrunde bewährt: Incident Lead (koordiniert), IT-Operator (setzt Maßnahmen um), Security-Owner (prüft Risiken/Beweise) und ein Business-Entscheider für Freigaben.
Minimalbesetzung definieren (und Stellvertretungen)
Die Minimalbesetzung sollte auch nachts funktionieren. Zu jeder Rolle gehören Name, Vertretung, Kontaktweg und Eskalationsschwelle. Kritisch: ein alternativer Kommunikationskanal, falls E-Mail oder Chat betroffen sind (z. B. Telefonliste oder externe Messenger-Policy).
Kommunikation absichern: intern, extern, dokumentiert
Unkontrollierte Kommunikation verursacht Folgeschäden: voreilige Kundenmails, widersprüchliche Aussagen oder das Leaken von Details. Im Runbook stehen daher vorformulierte interne Status-Updates (kurz, faktenbasiert), ein festgelegter Sprecher nach außen und ein Protokollort (Ticket, Incident-Dokument).
Erste 60 Minuten: Prioritäten, die Folgeschäden verhindern
Die erste Stunde entscheidet häufig darüber, ob ein Vorfall klein bleibt oder eskaliert. Ein gutes Runbook priorisiert drei Dinge: Eindämmung (Stoppen weiterer Aktionen), Sicherung von Belegen und Stabilisierung des Betriebs. Dabei muss nicht jedes System sofort „hart“ abgeschaltet werden; oft ist kontrolliertes Isolieren besser als blindes Trennen.
Containment zuerst: Identitäten und privilegierte Zugänge
Bei modernen Angriffen ist Identität der zentrale Hebel. Wenn ein Angreifer Zugriff auf ein Konto hat, sind Firewall-Regeln oder Endpoint-Tools nur begrenzt hilfreich. Priorität haben daher: kompromittierte Konten sperren, aktive Sessions beenden, Tokens widerrufen, API-Schlüssel rotieren und Admin-Zugänge überprüfen. Besonders wichtig ist Incident Response (geplantes Vorgehen bei Sicherheitsvorfällen) für privilegierte Konten, da hier die größten Folgeschäden entstehen.
Wo möglich, sollte temporär der Zugriff auf kritische Admin-Oberflächen begrenzt werden (z. B. nur aus einem Admin-Netzsegment). Wer dafür bereits ein Zero-Trust-Konzept nutzt, profitiert von klaren Grenzen; als Grundlage kann der Beitrag Zero Trust praktisch umsetzen helfen.
Beweissicherung ohne Forensik-Labor
In vielen Teams fehlt ein dediziertes Forensik-Setup. Trotzdem lässt sich mit einfachen Regeln viel retten: keine Systeme „aufräumen“, bevor relevante Informationen gesichert sind; keine Logs überschreiben; und jede Maßnahme dokumentieren. Ein Runbook nennt Mindestartefakte: betroffene Benutzer, Zeitfenster, IPs, Hostnamen, Prozessnamen, Hashes (falls vorhanden), relevante Logquellen, sowie Screenshots von kritischen Admin-Änderungen.
Gerade bei Cloud- und SaaS-Vorfällen sind Audit-Logs entscheidend. Wenn zentrale Protokollierung existiert, sollten Daten unverzüglich exportiert oder gesichert werden. Für Teams mit zentraler Logauswertung ist eine enge Verzahnung mit SIEM im Mittelstand sinnvoll, weil dort typische Abfragen und Korrelationen etabliert werden können.
Stabilisierung: gezielt isolieren statt reflexartig abschalten
Abschalten kann Beweise zerstören (z. B. volatile Daten) und Geschäftsprozesse unnötig stoppen. Besser ist oft: betroffene Endpoints vom Netzwerk trennen, aber eingeschaltet lassen; verdächtige Accounts deaktivieren; und kritische Systeme in einen eingeschränkten Betriebsmodus versetzen. Wenn Ransomware-Verdacht besteht, sind zusätzlich sichere Backups und eine klare Restore-Strategie zentral, siehe Backups gegen Ransomware.
Runbook-Bausteine: Was konkret hinein muss
Ein Runbook ist am wirkungsvollsten, wenn es aus wiederverwendbaren Bausteinen besteht. So bleibt es kurz, aber nicht oberflächlich. Die folgenden Elemente haben sich als „Minimum viable Runbook“ bewährt.
Kontrollfragen, die sofort Entscheidungen ermöglichen
Pro Vorfallstyp reichen 5–8 Fragen, etwa: Ist ein privilegiertes Konto betroffen? Gibt es Hinweise auf Datenabfluss (Downloads, Exporte, ungewöhnliche Mail-Weiterleitungen)? Wurden Sicherheitsfunktionen verändert (MFA deaktiviert, Regeln geändert)? Sind mehrere Systeme betroffen oder nur ein Endpoint? Diese Fragen führen zu klaren Pfaden und verhindern Aktionismus.
Logquellen und Abfragen: klein starten, zuverlässig sein
Ein Runbook listet die wichtigsten Logquellen mit Zugriffspfad: Identity-Provider (Anmeldungen, MFA-Events), E-Mail-Audit (Regeln, Weiterleitungen), Endpoint-Telemetrie, Firewall/Proxy, Server-Eventlogs und Admin-Änderungen. Wer noch keinen strukturierten Zugriff hat, sollte das als Nacharbeit priorisieren, nicht im Incident improvisieren.
Wiederherstellung und „Clean State“ festlegen
Nach dem Containment stellt sich die Frage: wann gilt ein System wieder als vertrauenswürdig? Das Runbook definiert Minimalbedingungen: Passwort-Reset, Token-Invalidierung, Patchstand prüfen, Konfigurationen mit Sollwerten vergleichen, neu ausrollen statt „reparieren“, wenn Integrität unklar ist. Gerade bei Windows-Umgebungen kann eine klare Baseline helfen; für die Schutzschicht auf Endpoints ist die konsistente Konfiguration von Windows Defender ein typischer Baustein.
Ein kompakter Ablaufplan, der in Tickets passt
Damit das Runbook nicht als PDF verschwindet, muss es in den Arbeitsalltag passen. Ein kurzer Ablaufplan lässt sich direkt in ein Ticket oder Incident-Dokument kopieren. Er ist bewusst handlungsorientiert und vermeidet Tool-Abhängigkeiten.
Konkrete Schritte für die ersten 60 Minuten
- Vorfall-Trigger festhalten: Was wurde beobachtet, wann, von wem, welche Systeme/Accounts?
- Incident Lead bestimmen und Kommunikationskanal festlegen (inkl. Ausweichkanal).
- Scope skizzieren: betroffene Identitäten, Systeme, Datenarten; Hypothese notieren.
- Containment starten: kompromittierte Konten sperren, Sessions beenden, privilegierte Gruppen prüfen.
- Beweissicherung (sichere Sammlung relevanter Spuren) durchführen: Logs exportieren, Screenshots, Zeitlinien, Hostdaten sichern.
- Betroffene Geräte isolieren: Netzwerkzugriff einschränken, aber Zustand erhalten, wenn möglich.
- Erste Bewertung: Fortlaufende Aktivität ja/nein, Datenabfluss-Verdacht ja/nein, Business-Impact.
- Nächste Schritte planen: tiefergehende Analyse, Recovery-Pfad, interne/externe Meldungen nach Vorgaben.
Häufige Fehler beim Runbook-Design (und wie sie vermieden werden)
Viele Runbooks scheitern nicht an fehlendem Fachwissen, sondern an Praxisferne. Typische Fehler lassen sich relativ leicht vermeiden, wenn das Dokument wie ein Einsatzplan geschrieben wird: kurz, eindeutig, umsetzbar.
Zu viel Theorie, zu wenig Zugriff auf reale Systeme
„Logs prüfen“ hilft nicht, wenn niemand weiß, wo die Logs liegen oder ob die Rechte fehlen. Ein Runbook muss deshalb Zugangspfade nennen (Portal/Server/Tool), Verantwortliche und Mindestaufbewahrung. Wo möglich, sollten Leserechte für Audit-Logs vorab vergeben werden.
Maßnahmen, die den Angreifer warnen
Manche Schritte können Gegenreaktionen auslösen, etwa das Zurücksetzen von Passwörtern ohne gleichzeitige Session-Beendigung oder das Blocken einzelner IPs, während Tokens weiter gültig sind. Der Runbook-Text sollte die Reihenfolge festlegen: erst Zugriff entziehen, dann rotieren, dann aufräumen.
Unklare Regeln für privilegierte Konten
Privilegierte Zugänge brauchen eigene Leitplanken: separate Admin-Konten, restriktive Anmeldung, Monitoring. Als Schutzprinzip ist Least Privilege (minimale Rechte) besonders wirksam, weil es die Ausbreitung begrenzt. Ein Runbook sollte explizit festhalten, wie Admin-Zugriffe im Incident temporär eingeschränkt werden dürfen, ohne den Betrieb zu blockieren.
Runbook regelmäßig testen, ohne große Übungen zu planen
Ein Runbook veraltet schnell: neue SaaS-Dienste, neue Logpfade, andere Ansprechpartner. Statt seltene Großübungen reicht ein kurzer, wiederkehrender Test: einmal pro Quartal ein 20-Minuten-„Tabletop“ anhand eines realistischen Szenarios. Dabei wird nur geprüft, ob Kontaktwege, Rechte und Schritte noch stimmen.
Mini-Szenarien, die echte Lücken aufdecken
Drei bewährte Tests: (1) CFO-Mailkonto zeigt neue Weiterleitungsregel, (2) Admin-Gruppe hat neues Mitglied, (3) Endpoint meldet verdächtigen PowerShell-Start. Für jedes Szenario sollte das Team in der Lage sein, innerhalb von 10 Minuten die zuständige Person zu erreichen, die relevanten Logs aufzurufen und das erste Containment sauber zu starten.
Bei Endpoint-Sichtbarkeit kann EDR (Endpoint Detection and Response, erweiterte Erkennung und Reaktion) helfen, Prozesse und Verbindungen schnell einzuordnen. Entscheidend bleibt aber: auch ohne EDR muss das Runbook funktionieren, sonst entsteht eine gefährliche Abhängigkeit.
Nacharbeit als feste Liste: Zugang, Logging, Härtung
Aus jedem Test ergeben sich konkrete To-dos: fehlende Audit-Logs aktivieren, Aufbewahrung anpassen, Admin-Zugänge trennen, Benachrichtigungen sinnvoll einstellen. Ein Runbook sollte am Ende eine kurze „Verbesserungsliste“ enthalten, die nach jedem Vorfall ergänzt wird, statt alles im Kopf zu behalten.
Entscheidungshilfe bei typischen Sofortmaßnahmen
Gerade im Stress hilft eine einfache Abzweigung: lieber isolieren oder sofort abschalten, lieber Passwort ändern oder Token widerrufen, lieber blocken oder beobachten. Die folgende Logik passt in viele Umgebungen und vermeidet die häufigsten Fehlgriffe.
Wenn-dann-Struktur für die ersten Maßnahmen
- Wenn privilegierte Konten betroffen sind: zuerst Sessions beenden und Tokens widerrufen, dann Passwörter zurücksetzen, dann Admin-Gruppen auditieren.
- Wenn Datenabfluss vermutet wird: Exporte/Downloads im Portal prüfen, Freigaben einschränken, Protokolle sichern, Kommunikationsfreigabe klären.
- Wenn Malware auf einem Endpoint gefunden wurde: Gerät isolieren, Belege sichern, erst danach bereinigen oder neu ausrollen.
- Wenn der Vorfall unklar ist, aber aktiv: kurzfristig begrenzen (Zugriff einschränken), parallel analysieren, nicht „wegklicken“.
Als Zielbild sollte ein Runbook jederzeit ermöglichen, aus chaotischen Einzelmeldungen in einen kontrollierten Prozess zu wechseln. Wer Identitäten priorisiert, Belege sauber sichert und Kommunikation diszipliniert, reduziert Folgeaufwand und erhöht die Chance, Ursachen nachhaltig zu beheben.
