# Notfall-Runbook: Die Kontrolle über KI-Agenten zurückgewinnen Agentengesteuerte Systeme brauchen ein Notfallverfahren, bevor sie die nächste Berechtigungseinstellung brauchen. Wenn ein Agent eine API aufrufen, eine SSH-Sitzung öffnen, eine Bereitstellung ändern oder Daten an einen externen Dienst senden kann, muss ein Mensch die Arbeit stoppen, die Befugnis entziehen und unter Druck nachvollziehen können, was geschehen ist. Ein Notfall-Runbook macht ein unsicheres Design nicht sicher. Es gibt Menschen eine Möglichkeit, Unsicherheit einzudämmen, bevor daraus Schaden entsteht. Die brauchbare Version passt für die ersten fünfzehn Minuten auf eine Seite, benennt tatsächliche Befugnisse statt nur Jobtitel und wurde von Personen getestet, die nicht an ihrer Erstellung beteiligt waren. ## Notfallbefugnisse gehören benannten Rollen Ein Notfall-Runbook funktioniert nur, wenn klar darin steht, wer ohne weitere Genehmigung handeln darf. «Das Plattformteam» und «die Sicherheitsabteilung» sind um 02:00 Uhr keine Antworten, besonders wenn mehrere Personen davon ausgehen, dass jemand anderes die Entscheidung trifft. Weisen Sie vier Rollen zu und ordnen Sie jeder Rolle aktuelle Personen und Stellvertretungen zu. In einem kleinen Team kann dieselbe Person zwei Rollen übernehmen. Lassen Sie jedoch nicht eine Person alle Rollen innehaben. - Die Einsatzleitung ruft den Notfallmodus aus, setzt das unmittelbare Ziel und dokumentiert Entscheidungen. - Der Zugriffs-Widerrufer deaktiviert die Agentensitzung, ihren Aktionskanal oder die erreichbaren Zugangsdaten. - Der Serviceverantwortliche entscheidet, ob eine kritische Arbeitslast sicher pausieren kann, und bestätigt die Wiederherstellung. - Die dokumentierende Person führt ein Ereignisprotokoll mit Zeitstempeln und schützt das Beweispaket. Der Zugriffs-Widerrufer braucht technische Befugnisse, bevor ein Vorfall eintritt. Er muss den betreffenden Agentenprozess deaktivieren, den Zugriff an der Aktionsgrenze entziehen und bei Bedarf eine Rotation der Zugangsdaten anfordern können. Eine Notfalltelefonnummer ohne den erforderlichen Konsolenzugriff macht diese Rolle zur reinen Formsache. Setzen Sie nach Möglichkeit zwei Widerrufer aus unterschiedlichen Berichtslinien ein, einen Hauptverantwortlichen und eine Vertretung. Der Serviceverantwortliche kann einem langen Ausfall widersprechen, sollte aber die anfängliche Eindämmung nicht verhindern können, wenn die Einsatzleitung einen aktiven Agenten für unsicher hält. Den Dienst können Sie wiederherstellen, sobald die Lage verstanden ist. Einen externen API-Aufruf oder einen destruktiven SSH-Befehl können Sie nicht rückgängig machen. Nehmen Sie für jede Rolle folgende Angaben in das Runbook auf: Name, Stellvertretung, Kontaktmöglichkeit während der Arbeitszeit, gegebenenfalls eine Methode außerhalb der Arbeitszeit und die Systeme, die die Person tatsächlich kontrollieren kann. Prüfen Sie die Liste nach personellen Änderungen. Eine veraltete Kontaktliste ist kein kleines Verwaltungsproblem. Sie zwingt Einsatzkräfte gerade in dem Moment zum Improvisieren, in dem sie handeln sollten. Trennen Sie Befugnis und Beratung. Recht, Compliance, Kundensupport und die Geschäftsleitung müssen je nach betroffener Arbeit möglicherweise informiert werden. Sie sollten jedoch keine Warteschlange vor der Eindämmung bilden. Die Einsatzleitung informiert sie nach der ersten sicheren Maßnahme, sofern keine konkrete rechtliche Pflicht etwas anderes verlangt. ## Stoppen, widerrufen und sichern sind verschiedene Maßnahmen Das Stoppen eines Agentenprozesses, der Entzug seiner Befugnis und die Sicherung von Beweismaterial lösen unterschiedliche Probleme. Teams vermischen sie regelmäßig und glauben dann, ein inaktiver Prozess habe keinen Zugriff mehr, obwohl das nicht stimmt. Ein Stopp verhindert weitere Arbeit dieses Prozesses. Das kann bedeuten, einen lokalen Prozess zu beenden, eine geplante Aufgabe zu deaktivieren, einen Agenten-Runner zu pausieren oder einen Repository-Trigger zu entfernen. Stoppen Sie zuerst, wenn der Prozess noch aktiv ist und sein Verhalten unklar bleibt. Ein Widerruf entfernt die Befugnis, die eine Aktion ermöglicht hat. Dazu kann gehören, eine Aktionssitzung zu deaktivieren, eine Dienstidentität zurückzuziehen, einen Zugriffstresor zu sperren, ein vorgelagertes Token zu ersetzen oder eine genau begrenzte Integration zu blockieren. Ein Agent, der heute gestoppt wird, kann morgen aus einer Wiederholungsschlange oder auf einem anderen Rechner neu starten. Seine Befugnis darf nicht versehentlich weiter verfügbar bleiben. Die Sicherung bewahrt, was Einsatzkräfte benötigen, bevor die routinemäßige Wiederherstellung es überschreibt. Erfassen Sie die Prozessidentität, gegebenenfalls die Quellrevision oder den Prompt-Kontext, das Bedienerkonto, Start- und Endzeit, Zielsysteme und die letzte bestätigte Aktion. Bewahren Sie Protokolle und Konfigurations-Snapshots gemäß Ihren Aufbewahrungsregeln auf. Fügen Sie bei der Beweissicherung keine Geheimnisse in ein Vorfallticket ein. Verwenden Sie in den ersten Minuten diese Entscheidungskarte: ```text Vorfall-ID: Ausgerufen von / Zeitpunkt: Betroffener Agentenprozess oder betroffene Sitzung: Unmittelbares Risiko: aktive Aufrufe / mögliche Preisgabe von Zugangsdaten / unbekannt [ ] Aktuellen Lauf stoppen [ ] Agentenberechtigung widerrufen [ ] Betroffenen Zugangsdatenpfad sperren oder rotieren [ ] Prozessidentität und Aktionsaufzeichnungen sichern [ ] Serviceverantwortlichen benachrichtigen Widerrufer / Zeitpunkt: Dokumentierende Person / Zeitpunkt: Wiederherstellung ist untersagt, bis die Einsatzleitung sie genehmigt. ``` Die letzte Zeile verhindert einen typischen Fehler. Ein Entwickler sieht, dass die Arbeit in der Produktion pausiert, startet den Agenten neu, damit die Warteschlange weiterläuft, und zerstört die klare Grenze, die die Einsatzkräfte gerade geschaffen haben. Die Wiederherstellung braucht eine eigene Entscheidung, weil sie das Risiko erneut verändert. Verlangen Sie von Einsatzkräften nicht, vor ihrem Handeln böswilliges Verhalten nachzuweisen. Ein ungewöhnliches Ziel, ein fehlgeschlagener Freigabeweg, ein Agent, der sich nicht stoppen lässt, oder eine Abweichung zwischen erwarteten und beobachteten Aktionen reicht aus, um zunächst einzudämmen. Die spätere Prüfung kann zwischen einem Fehler, einer falschen Konfiguration und einem Angriff unterscheiden. ## Dringende Arbeiten brauchen einen engen Freigabeweg Dringende Arbeiten können manchmal nicht auf den normalen Verantwortlichen warten. «Dringend» wird jedoch oft benutzt, um genau die Kontrollen zu umgehen, die eine schlechte Anfrage sichtbar machen würden. Das Runbook sollte eine eng begrenzte Ausnahme erlauben, ohne jeden Vorfall in eine pauschale Freigabe zu verwandeln. Definieren Sie dringende Arbeit als ein bestimmtes Serviceergebnis, das erheblichen Schaden nimmt, wenn es auf den normalen Weg warten muss. Eine ausstehende Bereitstellung, weil jemand vor der Mittagspause fertig werden möchte, ist nicht dringend. Die Wiederherstellung einer ausgefallenen Produktionsabhängigkeit kann dringend sein. Die Beschreibung muss die genaue Aktion, das Ziel, das erwartete Ergebnis und den spätesten sinnvollen Abschlusszeitpunkt nennen. Verwenden Sie diese Freigabefolge: 1. Der Anfragende nennt die Auswirkungen auf den Service, die genau geplante Aktion, das betroffene Konto oder die betroffene Umgebung und den Ablaufzeitpunkt. 2. Die Einsatzleitung bestätigt, dass die Eindämmung bestehen bleibt, und bestimmt einen Serviceverantwortlichen oder Stellvertreter zur Prüfung des Umfangs. 3. Der Widerrufer gewährt nur die für diese Aktion erforderliche Befugnis, mit einem ausdrücklichen Ablaufzeitpunkt und einem dokumentierten Genehmiger. 4. Der Anfragende führt die Arbeit aus, während die dokumentierende Person die resultierende Aktionsaufzeichnung und das Ergebnis festhält. 5. Der Widerrufer entfernt die vorübergehende Befugnis sofort, nachdem das Ergebnis geprüft wurde. Der Freigabevermerk sollte vollständig und unspektakulär sein. Akzeptieren Sie im Chat nicht «genehmigt, bitte reparieren». Verlangen Sie eine Erklärung wie diese: ```text Freigabe für Notfallarbeiten Anfrage-ID: IR-2025-041 Angeforderte Aktion: Bereitstellung von payment-worker in der Produktion neu starten Umfang: eine benannte Bereitstellung, keine Repository-Schreibzugriffe, keine Kontoänderungen Grund: Warteschlange fällt aus und das Zeitfenster für die manuelle Wiederherstellung endet um 14:30 UTC Genehmiger: Stellvertretung des Serviceverantwortlichen Freigebender Widerrufer: Zugriffs-Widerrufer Gültig bis: 14:30 UTC Ergebnis und Zeitpunkt der Entfernung: ``` Das Beispiel gibt einer Einsatzkraft keine Erlaubnis, irgendetwas neu zu starten. Es zeigt den erforderlichen Detailgrad, der eine Ausweitung des Umfangs verhindert. «Produktion wiederherstellen» verbirgt Dutzende mögliche Aktionen. Eine benannte Bereitstellung und ein Ablaufzeitpunkt lassen sich prüfen. Verwenden Sie für diesen Weg nach Möglichkeit keine dauerhaft bereitstehende Notfallzugangsdaten. Teams mögen einen ständigen Notfallzugriff, weil er schnell wirkt. Er schafft aber auch ein dauerhaft wertvolles Angriffsziel. Irgendwann wird er aus Bequemlichkeit für gewöhnliche Arbeiten verwendet. Gewähren Sie eine Befugnis für eine begrenzte Aktion und entfernen Sie sie anschließend. Wenn niemand mit entsprechender Befugnis eine dringende Aktion genehmigen kann, lassen Sie die Eindämmung bestehen und eskalieren Sie entlang der Verantwortungsstruktur. Eine verzögerte Wiederherstellung ist schädlich. Eine unbefugte Wiederherstellung, die einen Vorfall ausweitet, kann deutlich größeren Schaden anrichten. ## Die ersten fünfzehn Minuten sollten mechanisch ablaufen Unter Stress lassen Menschen Zeitstempel weg, diskutieren Begriffe und gehen davon aus, dass ein Kollege eine Maßnahme durchgeführt hat. Ein Runbook braucht eine geordnete Erstreaktion, die auch dann funktioniert, wenn die Ursache noch unbekannt ist. In Minute null erstellt die Person, die das Problem bemerkt, einen Vorfall und beschreibt die beobachtbare Tatsache. Schreiben Sie «Agentenprozess hat Anfragen an einen unbekannten Endpunkt gesendet» statt «Agent wurde kompromittiert». Fakten halten einer späteren Prüfung besser stand als frühe Theorien. Die Einsatzleitung ruft anschließend einen von zwei Zuständen aus: Untersuchung oder Notfall-Eindämmung. Untersuchung bedeutet, dass es keinen Hinweis auf eine aktiv unsichere Befugnis gibt und das Team prüfen kann, ohne die Arbeit zu pausieren. Notfall-Eindämmung bedeutet, dass das Team die aktuellen Befugnisse oder Aktionen des Agenten nicht sicher feststellen kann. Der zweite Zustand berechtigt den Widerrufer zum Handeln. Führen Sie in den nächsten fünfzehn Minuten Folgendes in dieser Reihenfolge aus: 1. Identifizieren Sie den aktiven Prozess oder die Sitzung und erfassen Sie sichtbare Identität, Host, Verantwortlichen, Startzeit und aktuelle Aufgabe. 2. Stoppen Sie die weitere Ausführung, wenn sie noch aktiv ist oder ein Scheduler sie erneut starten kann. 3. Widerrufen Sie die für diesen Prozess verfügbare Befugnis, beginnend mit dem folgenschwersten externen Aktionspfad. 4. Informieren Sie den betroffenen Serviceverantwortlichen über die aktive Eindämmung und nennen Sie die betriebliche Folge klar. 5. Sichern Sie Aktionsaufzeichnungen und Konfigurationskontext, bevor Sie unabhängige Einstellungen ändern. Vermeiden Sie in dieser Phase umfassende Aufräumarbeiten. Bauen Sie keine Hosts neu auf, löschen Sie keine Arbeitsverzeichnisse, rotieren Sie nicht jedes Geheimnis im Unternehmen und ändern Sie keine Bereitstellungseinstellungen, nur weil die Lage beunruhigend wirkt. Solche Maßnahmen können später gerechtfertigt sein, vergraben aber die Beweise und verursachen zusätzliche Ausfälle. Die dokumentierende Person sollte an einem gemeinsamen Ort eine einfache Zeitleiste führen: ```text 14:07 Beobachter meldete unerwartete ausgehende Anfrage aus Agentenlauf A-184. 14:09 Einsatzleitung rief Notfall-Eindämmung aus. 14:10 Widerrufer stoppte Lauf A-184 und deaktivierte seine Aktionsberechtigung. 14:12 Serviceverantwortlicher bestätigte, dass die Auftragsverarbeitung pausieren kann. 14:14 Dokumentierende Person sicherte Aktionsaufzeichnungen und Konfigurationsdigest. 14:18 Team begann mit der Prüfung des Umfangs. Keine Wiederherstellungsbefugnis erteilt. ``` Das ist hilfreicher als eine lange, nachträglich verfasste Erzählung. Die Zeitleiste zeigt, was das Team wusste, wer handelte und wann sich die Befugnis änderte. Halten Sie Meinungen und Hypothesen in einer separaten Untersuchungsnotiz fest. ## Freigabemüdigkeit ist ein Designfehler Menschen ignorieren Warnungen, wenn derselbe Hinweis sowohl bei harmlosen als auch bei folgenreichen Arbeiten erscheint. Wiederholte Freigaben erzeugen keine Sorgfalt. Sie bringen Menschen dazu, die Karte wegzuklicken, damit die Arbeit weitergeht. Ihr Notfall-Runbook sollte festlegen, welche Aktionen eine ausdrückliche menschliche Entscheidung erfordern und welche im Rahmen der normalen Befugnis fortgesetzt werden können. Die Grenze muss sinnvoll sein. Eine Aktion, die Infrastruktur ändert, ein neues externes Ziel erreicht, ein Konto verändert oder Zugangsdaten außerhalb des erwarteten Servicepfads verwendet, verdient mehr Prüfung als ein Lesevorgang innerhalb eines bekannten Bereichs. Versuchen Sie nicht, das mit einer riesigen schriftlichen Richtlinie voller Bedingungen zu lösen. Während eines Vorfalls braucht eine Einsatzkraft einige klare Entscheidungen: ablehnen, stoppen, widerrufen, eine begrenzte Notfallaktion gewähren oder den normalen Betrieb wiederherstellen. Wenn das Verfahren die Auslegung von zwanzig Ausnahmeklauseln verlangt, wird es bei jeder Einsatzkraft anders scheitern. Die Freigabeansicht oder der Freigabevermerk muss den Aufrufer so genau identifizieren, dass ein Mensch einen erwarteten Lauf von einem unerwarteten unterscheiden kann. Der Prozessname allein ist schwache Evidenz, weil Namen leicht kopiert werden können. Erfassen Sie die Herkunft des Prozesses, sofern das Betriebssystem sie bereitstellt die Code-Signaturidentität, den Startkontext und die Sitzungs-ID. So kann ein Genehmiger sagen: «Das ist das erwartete Entwicklertool, das von diesem Pfad gestartet wurde», statt: «Die Bezeichnung kommt mir bekannt vor.» Eine häufige schlechte Empfehlung lautet, dass jeder sensible Aufruf die Freigabe einer Person erfordern sollte. Das klingt sicher, weil ein Mensch in jede Schleife gesetzt wird. Es scheitert, wenn eine legitime Aufgabe viele Aufrufe ausführt: Die Bedienperson genehmigt blind, der Agent kann eine begrenzte Wartung nicht abschließen und das Team schaltet die Einstellung schließlich ab. Verwenden Sie Einzelfreigaben für Befugnisse mit wesentlichen Folgen und Sitzungsfreigaben nur, wenn die Sitzungsidentität klar und ihr Umfang vertretbar ist. Sallyport folgt dieser praktischen Aufteilung mit einer Tresorsperre, standardmäßiger Freigabe pro Sitzung und einer optionalen Anforderung pro Schlüssel, bei jedem Einsatz eine Freigabe einzuholen. Das ersetzt kein Runbook, weil ein Mensch weiterhin die Befugnis braucht, die Arbeit anzuhalten und zu entscheiden, ob eine dringende Ausnahme gerechtfertigt ist. ## Protokolle müssen zeigen, wer gehandelt und wer freigegeben hat Ein Vorfallprotokoll mit dem Eintrag «Der Agent war es» ist unvollständig. Agenten laufen über Prozesse, Identitäten, Aktionskanäle und menschliche Freigabewege. Ihre Beweiskette muss jedes Glied sichtbar machen. Bewahren Sie für jeden wichtigen Aufruf die Agentensitzung oder Prozessidentität, den initiierenden Menschen oder das initiierende System, den Zieldienst oder Host, die angeforderte Aktion, den Berechtigungsstatus, das Ergebnis und eine vertrauenswürdige Zeitangabe auf. Bei Notfallarbeiten müssen Genehmiger, Widerrufer, angeforderter Umfang, Ablaufzeitpunkt und Zeitpunkt der Entfernung neben der Aufzeichnung des Aufrufs stehen. Halten Sie den Freigabevermerk getrennt vom Aktionsergebnis und verknüpfen Sie beide über eine Vorfall- oder Anfrage-ID. Das ist wichtig. Eine Freigabe bedeutet, dass jemand einen begrenzten Versuch genehmigt hat. Sie beweist nicht, dass der Versuch erfolgreich war, nur das vorgesehene Objekt berührte oder nach Ablauf endete. Stellen Sie bei der Prüfung diese Fragen: - Welcher Prozess hat die Anfrage gestellt und wie wurde er gestartet? - Welche Befugnis erlaubte die Anfrage zu diesem Zeitpunkt? - Wer hat die Notfallarbeit genehmigt und welchen genauen Umfang hat diese Person freigegeben? - Entsprach das Ergebnis diesem Umfang? - Kann eine unabhängige prüfende Person veränderte oder fehlende Aufzeichnungen erkennen? NIST Special Publication 800-61 Revision 2, Computer Security Incident Handling Guide, behandelt Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung und Wiederherstellung sowie Aktivitäten nach dem Vorfall als zusammenhängende Arbeit. Die Hinweise zum Dokumentieren und Bewahren von Vorfalldaten sind weiterhin nützlich. Agentenbetrieb ergänzt jedoch ein Detail, das ältere Runbooks oft übersehen: Sie brauchen eine Aufzeichnung delegierter Maschinenbefugnisse, nicht nur eine Aufzeichnung menschlicher Anmeldungen. Verwechseln Sie gewöhnliche Anwendungsprotokolle nicht mit einem Audit-Trail. Anwendungsprotokolle können den Berechtigungskontext auslassen, umfassende administrative Änderungen erlauben oder beim Neuaufbau eines Rechners verschwinden. Bewahren Sie sie auf, dokumentieren Sie aber, was jede Aufzeichnung beweisen kann und was nicht. Bei Systemen mit einer kryptografischen Audit-Kette sollte die Prüfung Teil der Übung sein. Sallyport bietet mit `sp audit verify` eine Offline-Prüfung, mit der ein Prüfer das verschlüsselte, hashverkettete Auditprotokoll ohne Tresorschlüssel kontrollieren kann. Führen Sie den Befehl während einer Probe gegen einen kopierten Beweissatz aus, nicht zum ersten Mal, während eine Einsatzleitung auf eine Antwort wartet. ## Wiederherstellung muss sich die Befugnis zurückverdienen Die Wiederherstellung eines Dienstes ist nicht dasselbe wie der Abschluss eines Vorfalls. Ein Team sollte nur Befugnisse wiederherstellen, die es erklären kann, und dies in ausreichend kleinen Schritten tun, damit ein erneutes Problem eine sichtbare Grenze hat. Vor der Wiederherstellung braucht die Einsatzleitung drei Antworten: Was hat die Eindämmungsentscheidung ausgelöst? Welche Befugnis wurde offengelegt oder genutzt? Welche Kontrolle verhindert nun eine Wiederholung? Die vollständige Ursache ist möglicherweise noch nicht bekannt. Sie brauchen trotzdem genug Sicherheit, um zu erklären, warum die erste wiederhergestellte Aktion sicher ist. Stellen Sie den Dienst in begrenzten Stufen wieder her. Beginnen Sie nach Möglichkeit mit einer schreibgeschützten Prüfung, dann mit einer einzelnen bekannten Aktion und anschließend mit einem kurzen überwachten Lauf. Aktivieren Sie nicht jeden Agenten, jede Integration und jede Zugangsdatenquelle wieder, nur weil ein Dienst zurück ist. Halten Sie die Vorfallgrenze aufrecht, bis Serviceverantwortlicher und Einsatzleitung übereinstimmen, dass der betroffene Pfad verstanden ist. Verwenden Sie eine Wiederherstellungsfreigabe, die sich von der Freigabe für dringende Arbeiten unterscheidet. Die Notfallfreigabe erlaubt eine notwendige Aktion trotz des Vorfalls. Die Wiederherstellungsfreigabe bestätigt, dass die normale Befugnis nach der Eindämmung zurückkehren darf. Führen Sie dafür einen separaten Vermerk: ```text Wiederherstellungsfreigabe Vorfall-ID: Ursache oder verbleibende Unsicherheit: Wiederherzustellende Befugnis: Durchgeführte Validierung: Verantwortlicher für Überwachung und Prüfzeitpunkt: Genehmigt von Einsatzleitung und Serviceverantwortlichem: ``` Auch hier ist der Ablaufzeitpunkt wichtig. Bleibt eine vorübergehende Wiederherstellungsfreigabe nach einem erfolgreichen Test bestehen, wird sie zu einem nicht dokumentierten dauerhaften Zugriff. Der Widerrufer sollte ihre Entfernung als Teil des Wiederherstellungsvermerks bestätigen. Bei der Rotation von Zugangsdaten ist Augenmaß statt bloßer Formsache gefragt. Rotieren Sie, wenn die Zugangsdaten einen nicht vertrauenswürdigen Prozess, ein nicht vertrauenswürdiges Ziel, Repository, Protokoll oder eine Person erreicht haben könnten oder wenn sich ihre Nutzungsgrenze nicht feststellen lässt. Behaupten Sie nicht, die Rotation habe den Vorfall behoben, wenn ein Agent den Ersatz weiterhin über denselben unsicheren Pfad erhalten kann. Reparieren Sie zuerst diesen Pfad. Die Nachbesprechung sollte Änderungen hervorbringen, nicht nur Beobachtungen. Ersetzen Sie «Die Kommunikation war unklar» durch «Die dokumentierende Person verwendet die Vorlage für die Vorfallzeitleiste und auf der Seite des Serviceverantwortlichen steht eine Stellvertretung». Ersetzen Sie «Der Zugriff war schwierig» durch die genaue fehlende Berechtigung, die Person, die sie gewähren wird, und den Termin der nächsten Übung. ## Übungen zeigen, wem die offenen Aufgaben gehören Ein nicht getestetes Runbook ist ein Vorschlag. Beim ersten echten Einsatz werden veraltete Kontakte, fehlende Befugnisse und Unklarheiten darüber sichtbar, wer die Arbeit wieder aufnehmen darf. Eine Übung macht diese Unbekannten zu behebbaren Fehlern, solange die Folgen gering sind. Führen Sie zunächst eine Planspielübung und anschließend eine kontrollierte technische Übung durch. Geben Sie den Teilnehmenden im Planspiel ein kurzes Szenario mit unvollständigen Informationen, etwa einen Agenten, der während einer Bereitstellung unerwartet eine SSH-Verbindung herstellt. Bitten Sie sie, die Anrufkette auszuführen, über die Eindämmung zu entscheiden, den Freigabevermerk auszufüllen und anzugeben, welche Beweise sie sichern würden. Lassen Sie nicht den Autor des Runbooks jede Frage beantworten. Verwenden Sie bei der technischen Übung ein Nichtproduktionsziel oder einen ausdrücklich isolierten Testpfad. Starten Sie einen bekannten Agentenprozess, geben Sie eine harmlose Aktion frei, lösen Sie die Eindämmung aus, bestätigen Sie, dass weitere Aktionen fehlschlagen, sichern Sie die Aufzeichnungen und führen Sie eine begrenzte Wiederherstellung durch. Messen Sie die Zeiten, machen Sie die Übung aber nicht zu einem Geschwindigkeitswettbewerb. Eine schnelle Reaktion, bei der der Widerruf fehlt, ist schlechter als eine langsamere Reaktion mit einer klaren Grenze. Bewerten Sie die Übung anhand beobachtbarer Kriterien: - Konnte der Beobachter die Einsatzleitung und den Widerrufer über die dokumentierten Wege erreichen? - Hatte der Widerrufer die nötige Befugnis, ohne dass ein Administrator den Zugriff improvisieren musste? - Hat das Team zwischen dem Stoppen des Prozesses und dem Entzug seiner Befugnis unterschieden? - Konnte eine prüfende Person die Notfallfreigabe dem daraus entstandenen Aktionsprotokoll zuordnen? - Verschwand der vorübergehende Zugriff zum angegebenen Ablauf- oder Entfernungszeitpunkt? NIST SP 800-61 empfiehlt ausdrücklich, Fähigkeiten zur Reaktion auf Vorfälle zu testen, und nennt dafür einen praktischen Grund: Übungen zeigen Lücken in Verfahren, Schulung und technischen Kontrollen. Beschränken Sie die Tests nicht auf das Incident-Response-Team. Beziehen Sie die Personen ein, die den Agenten betreiben, den betroffenen Service verantworten und dringende Arbeiten genehmigen. Meist brechen die Abläufe an deren Annahmen. Aktualisieren Sie das Runbook direkt nach der Übung, solange Namen, Verzögerungen und verwirrende Anweisungen noch frisch sind. Planen Sie anschließend die nächste Übung und weisen Sie jede Korrektur einer verantwortlichen Person zu. Wenn niemand für eine Korrektur zuständig ist, haben Sie einen Fehler dokumentiert und sich entschieden, ihn nicht zu beheben. ## Bewahren Sie die Karte für die erste Maßnahme dort auf, wo kein Fehler verborgen bleibt Das vollständige Runbook kann in Ihrem kontrollierten Dokumentationssystem liegen. Einsatzkräfte brauchen jedoch eine kurze Karte, die verfügbar bleibt, wenn gewöhnliche Werkzeuge langsam oder betroffen sind. Bewahren Sie sie an einem Ort auf, den das Team unabhängig von der Agentenumgebung erreichen kann, und sorgen Sie dafür, dass die Karte auf aktuelle Kontakte verweist, statt veränderliche Details zu kopieren. Die Karte sollte dem Beobachter sagen, wen er anrufen muss, der Einsatzleitung, wann sie eine Eindämmung ausrufen darf, dem Widerrufer, welche Befugnis zuerst entfernt werden muss, und allen Beteiligten, dass die Wiederherstellung eine neue Entscheidung erfordert. Sie sollte außerdem den Beweissatz und den Ort nennen, an dem die dokumentierende Person die Zeitleiste führt. Prüfen Sie die Karte jedes Mal, wenn Sie Agenten-Runner, Aktionskanäle, Zuständigkeiten oder Systeme zur Zugriffserteilung ändern. Warten Sie nicht auf ein jährliches Audit. In dem Moment, in dem ein Team ändert, wie ein Agent die Außenwelt erreicht, kann sein Notfallverfahren zur Fiktion geworden sein. Eine gute Übung endet mit einer leicht peinlichen Liste übersehener Annahmen. Bewahren Sie diese Liste auf. Ein Team, das seine Fehler in der Probe findet, hat die notwendige Arbeit geleistet, um sie nicht während eines Ausfalls zu entdecken.