Vom Satz zum Playbook – Wie ein Skill, ein MCP und Splunk SOAR zusammenspielen

Dieser Blog nimmt euch mit auf eine kleine Reise und zeigt euch, wie aus einem Satz in normaler Sprache ein lauffähiges, editierbares Splunk-SOAR-Playbook wird — und wie KI, ein Git-Repo und echte Fehler zusammen den Weg dahin gebaut haben.

Viel Spaß!

Ein Satz genügt

„Erstelle mir ein Playbook, das eine URL-Reputation prüft. Wenn die URL verdächtig ist, soll eine Notiz zum Case hinzugefügt werden, und ein Analyst soll den Vorfall prüfen und per Prompt mit Ja oder Nein bestätigen, ob die Domain geblockt werden soll.“

Abb.: Genau dieser eine Prompt — im Chat, in ganz normaler Sprache.

Ein Satz. Keine Zeile Code, kein Zusammenklicken im Editor. Wenige Minuten später existiert in Splunk SOAR ein fertiges Playbook — nicht nur als Text, sondern als richtiges, im Visual Playbook Editor anklickbares Ablaufdiagramm. Und das Beste: Es hat sich selbst getestet.

Klingt nach Magie. Ist aber eine bodenständige Geschichte aus drei Bausteinen — und aus vielen kleinen Fehlern, die auf dem Weg gelernt werden mussten. Schauen wir Schritt für Schritt zu, wie aus dem Satz ein Playbook wird.

Zuerst übersetzt der Skill deinen Satz in einen Ablauf — einen „Flow“, der zeigt, wie die KI die Aufgabe verstanden hat.

Abb.: Der geplante Ablauf: URL-Reputation → Notiz → Analyst-Prompt → bedingter Domain-Block.

Bevor irgendetwas gebaut wird, legt der Skill einen Change-Contract vor — er zeigt dir schwarz auf weiß, was passieren soll. Erst wenn du mit „Ja“ bestätigst, setzt die KI das Playbook um.

Abb.: Der Change-Contract: Datei, Funktion und was sich ändert — deine Freigabe vor dem Bauen.

Und so sieht das Ergebnis im Visual Playbook Editor aus — kein Black-Box-Skript, sondern ein voll editierbares Playbook:

Abb.: Das fertige Playbook im Visual Playbook Editor: Start → URL-Reputation → Entscheidung → Notiz → Analyst-Prompt → Domain-Block → Ende.

Jeder Baustein ist dabei sauber vorkonfiguriert — hier die vier zentralen Blöcke in ihrer Reihenfolge:

Abb.: 1) „url reputation“: VirusTotal v3, Eingabe artifact:*.cef.requestURL — live entdeckt, nicht geraten.

Abb.: 2) Die Entscheidung: bösartig > 0 ODER verdächtig > 0 → verdächtig.

Abb.: 3) Der Analyst-Prompt: „Block the domain?“ (Ja/Nein) mit menschenlesbarer Zusammenfassung.

Abb.: 4) Die Auswertung der Analyst-Antwort: „== Yes“ → Domain blocken.

Das Problem, das jeder im SOC kennt

Playbooks — die automatischen Reaktionsabläufe eines Security-Teams — von Hand zu bauen ist zäh und fehleranfällig. Und Automatisierung scheitert selten am großen Ganzen, sondern an Details: ein falsches Feld, ein Connector, der anders heißt als gedacht.

Der eigentliche Haken, den viele unterschätzen: Ein SOAR-Playbook ist zwei Dinge gleichzeitig. Es ist ein Bild — das Ablaufdiagramm, das man im Editor zusammenklickt. Und es ist Code, der tatsächlich ausgeführt wird. Beide müssen exakt übereinstimmen. Weichen sie voneinander ab, passiert eins von zwei Dingen: Entweder lässt sich das Playbook nicht mehr im Editor bearbeiten, oder es läuft nicht sauber.

Deshalb greift „die KI schreibt halt den Code“ zu kurz. Code allein ergibt ein Playbook, das vielleicht läuft, aber im Editor kaputt aussieht. Man braucht beide Seiten — und zwar konsistent.

Die drei Akteure

Der Übersetzer — der Skill („soar-playbook-builder“). Er nimmt deinen Satz und macht daraus einen präzisen Bauplan. Kein wildes Raten: Er formt aus der Alltagssprache eine saubere, prüfbare Beschreibung dessen, was das Playbook tun soll.

Die Brücke — der MCP („soar_mcp_server“). Er verbindet die KI direkt und komplett im eigenen Netz mit Splunk SOAR. Über ihn kann die KI SOAR echte Fragen stellen und echte Aktionen ausführen — mit 40 Werkzeugen, die standardmäßig nur lesen, und Schreib-Werkzeugen, die man ganz bewusst einzeln zuschalten muss.

Die Fabrik — Splunk SOAR. Hier laufen die Playbooks und lösen echte Reaktionen aus: eine Firewall-Regel, eine Quarantäne, das Sperren einer IP. Der Ort, an dem aus Automatisierung tatsächlich Wirkung wird.

Abb.: Übersetzer → Brücke → Fabrik: aus einem Satz wird eine echte Reaktion.

Das Zusammenspiel — ein Kreislauf

Wenn du deinen Satz absetzt, läuft im Hintergrund ein kleiner, disziplinierter Ablauf. In Klartext:

1. Lernen. Statt zu raten, schaut sich der Skill an einer echten, funktionierenden Vorlage ab, wie ein gültiges Playbook aufgebaut sein muss.
2. Entdecken. Über die Brücke fragt die KI SOAR live: Welcher Connector kann „URL-Reputation“? Wie genau heißt das Datenfeld, das die Anzahl bösartiger Treffer enthält? So kann nichts halluziniert werden — alles Connector-Spezifische kommt aus der echten Instanz
3. Planen. Aus all dem entsteht ein einziger, geprüfter Bauplan, der jeden Fehler auf einmal meldet — bevor gebaut wird.
4. Erzeugen. Aus diesem einen Plan werden zwei stimmige Ausgaben erzeugt: das Bild (Ablaufdiagramm) und der Code. Weil beide aus derselben Quelle stammen, passen sie zusammen — per Konstruktion.
5. Importieren & Selbst-Testen. Das Playbook wandert nach SOAR, die KI baut einen isolierten Testfall, lässt das Playbook laufen und prüft die Wirkung — zum Beispiel: Ist die Severity wirklich auf ‚hoch' gesprungen?

Abb.: Der Kreislauf: fünf Schritte — und der Rückspielball, der aus jedem Fehler lernt.

Die Reise: der Rückspielball

Das Spannende ist nicht nur, dass es funktioniert — sondern wie es entstanden ist. Nicht am Reißbrett durchgeplant, sondern iterativ, im Ping-Pong mit einer echten SOAR-Instanz.

Der Rhythmus war immer derselbe: Die KI erzeugt ein Playbook → SOAR lehnt es ab (HTTP 400 oder 403) → der Fehlschlag wird ein GitHub-Issue → die KI analysiert ihn (Problem, Ursache, Lösung), fixt → und importiert erneut. Das Git-Repo ist damit nicht nur Code-Ablage, sondern ein Logbuch der Reise: Der Changelog wandert von Version 1.6.5 bis 1.11.6, jede Zeile ein gelöstes echtes Problem.

Ein paar hart erkämpfte Lektionen, stellvertretend:

• „Die Oberfläche ist nachsichtig, die Schnittstelle ist streng.“ Ein Playbook, das der UI-Import schluckt, kann über die REST-Schnittstelle trotzdem scheitern. Wahrheit ist nur der echte Import — nicht die Vorschau.
• Der falsche Ablageort. Ein scheinbar harmloses Standard-Repo war schreibgeschützt → 403. Lösung: explizit ein beschreibbares Repo angeben.
• „Niemals tar czf auf dem Mac.“ macOS schmuggelt unsichtbare Zusatzdateien ins Archiv, die SOARs Import zerschossen. Erst ein sauberer, eigener Pack-Vorgang löste es.
• Entdecken statt Raten. Das Feld für „bösartig“ heißt bei jedem Connector anders. Wer rät, baut Bruch. Wer live nachfragt, baut, was funktioniert.

Genau so lässt es sich im Repo nachlesen — hier am Beispiel des Visual-Editor-Compatibility-Checkers (Issue #21):

Abb.: 1) Das Issue: Problem, Ziel und vorgeschlagenes Tool — sauber dokumentiert.

Abb.: 2) Die KI-Analyse als Issue-Kommentar: Problem, Verständnis, Lösungsvarianten, Risiko.

Abb.: 3) Die Triage-Entscheidung: Verdikt, Scope, Abhängigkeiten — und der Commit, der es umsetzt.

Live-Beispiel

Hier der reale Durchlauf zum Nachvollziehen — mit echten Screenshots aus einer Live-Session.

Sicherheit & Vertrauen

Automatisierung, die echte Reaktionen auslöst, braucht Leitplanken — und die sind eingebaut:

• On-premises. Alles bleibt im eigenen Netz. Bei Claude Desktop/Code verlässt kein Fall die Umgebung.
• Read-only per Default. Schreib-Tools sind aus und werden stufenweise zugeschaltet — von „nur Notiz“ bis „Playbook ausführen“.
• Human-in-the-Loop. Die KI schlägt vor, der Analyst bestätigt. „Ich empfehle X auf Fall 12345 — ausführen?“
• Least Privilege & Audit. Dedizierter Service-Account mit minimalen Rechten, jeder Tool-Aufruf landet im SOAR-Audit-Log, Tokens sind widerrufbar.

Was das für SOC-Teams bedeutet

• Schneller vom Konzept zum lauffähigen Playbook — Minuten statt Stunden.
• Weniger Halluzination: Connector und Datenfelder kommen aus der echten Instanz, nicht aus dem Bauch der KI.
• Das Ergebnis bleibt editierbar — es ist kein Black-Box-Skript, sondern ein Playbook, das dein Team weiter pflegt.
• Vertrauen durch Beweis: Der Self-Test zeigt Wirkung, statt „müsste eigentlich laufen“.

Wie es gebaut wurde — mit KI, Git & Issues

Entstanden ist das Ganze mit Claude Code. Das Git-Repo erzählt die Reise mit: Commits, Changelog und Issues sind die Chronik jedes gelösten Problems. Die eigentliche Botschaft ist nicht „KI ersetzt Entwickler“, sondern: KI + Domänenwissen + eine echte Feedback-Schleife ergeben zusammen etwas, das keiner der drei allein hinbekäme. Der Rückspielball zwischen KI und echter SOAR-Instanz war der Motor.

Ausprobieren

Beide Teile sind offen einsehbar und für Splunk-SOAR-Nutzer gedacht. Wenn du Playbooks baust oder ein SOC betreibst: Verbinde deine SOAR-Instanz, stell eine Frage in normaler Sprache — und schau zu, wie aus einem Satz ein getestetes Playbook wird.

• MCP-Server: github.com/abuis78/soar_mcp_server
• Skill: github.com/abuis78/skill_Claude_generate_SOAR_playbook

Hinweis: Community-App, nicht von Splunk offiziell. Splunk und SOAR sind Marken von Splunk Inc.