AiSOC: die selbst hostbare KI-SOC mit Investigation Ledger im Detail

npx aisoc triage --demo: der 60-Sekunden-Einstieg

Das README von beenuar/AiSOC verspricht einen Probelauf in 60 Sekunden: npx aisoc triage --demo, ohne clone, ohne Docker, ohne Schluessel. Die Beispielausgabe zeigt, was die wedge-CLI tut: AiSOC triaged 200 alerts, mit dem Ergebnis 12 TP, 171 FP suppressed (85.5 percent noise), 17 need review, in 0.1 Sekunden. Die Bewertung stuft jeden Alert auf eine der Entscheidungen escalate, review oder suppress.

Wichtig fuer die Einordnung ist die Technik dahinter: Eine deterministische Engine, portiert aus dem produktionsnahen Triage-Scorer, macht diese Bewertung, ganz ohne LLM-Schluessel. Damit misst der Schnelltest die Rechenlogik, nicht die KI-Untersuchung, was die Antwortzeit von 0.1 Sekunden plausibel macht.

Ein Vorbehalt gehoert dazu: npx aisoc erscheint laut README erst mit dem v8.0-Start auf npm, derzeit wird das Paket aus packages/aisoc-lite/ gebaut. Das Projekt haelt also seinen Einsteigerpfad und seinen Produktionspfad bewusst auseinander, und die README-Tabelle fuehrt vier Wege je nach vorhandener Ausstattung, von Python 3.10 ohne Docker bis zum Bootstrap-Skript via curl, das Docker, Node, pnpm und git nachzieht.

Investigation Ledger: Agentenentscheidungen Schritt fuer Schritt protokolliert

Das Unterscheidungsmerkmal, mit dem AiSOC wirbt, ist die Pruefbarkeit der Agenten. Das Investigation Ledger speichert fuer jeden Schritt jedes Laufs den LLM-Prompt, die Antwort, die zitierten Belege und die nachgelagerten Tool-Aufrufe. Laeufe lassen sich spaeter wiedergeben, was fuer Audits und fuer die Weiterentwicklung von Prompts die entscheidende Grundlage ist.

Im Demo-Betrieb sieht man das direkt: Die Docker-Variante landet auf /cases/INC-RT-001?tab=ledger, einem eingespeisten LockBit 3.0-Ransomware-Fall mitten in der Untersuchung, in dem Prompts, Tool-Aufrufe und Begruendungen in das Ledger einlaufen. Die 90-Sekunden-Durchlaeufer sind als Material fuer den v8.0-Start angekündigt, die Shotlist dafuer liegt in docs/demo/SCREENCAST_SHOTLIST.md.

Der Orchestrator ist ein etwa 600 Zeilen langer LangGraph-Graph in services/agents/. Das README nennt diese Groesse bewusst als Eigenschaft: klein genug, um ihn komplett zu lesen, Modelle auszutauschen und zu patchen. Der Substrat und der Agent sind beide MIT-lizenziert, beide Teile lassen sich also einzeln ersetzen oder forken.

Fuenf Eval-Suiten gegen main und develop: der CI-Benchmark von AiSOC

Das zweite Verkaufsargument ist ein oeffentliches Bewertungsgeruest in der CI. Fuenf Suiten schirmen jeden Pull Request gegen main oder develop ab. Eine misst die Alert-Reduktion gegen einen festen Strom von 1.000 Alerts, drei rubrik-basierte Suiten pruefen die Selbstkonsistenz des Substrats ueber einen deterministischen Datensatz von 200 Vorfallen mit 55 Templates und je-Template-Makros, und eine fuenfte validiert den zugrunde liegenden Telemetriekorpus.

Dazu gehoert eine selbstbewusste Einschraenkung: Die Benchmark-Seite apps/docs/docs/benchmark.md dokumentiert laut README genau, was jede Suite misst und was nicht. Diese Angreifbarkeit der eigenen Zahlen ist selten und wertvoller als jede Punktzahl, denn sie erlaubt dem Pruefer, die Messung nachzuvollziehen.

Neben den Eval-Suiten laufen fuenf Betriebs-Workflows: Jeder Push fuehrt compose-smoke aus, denselben pnpm aisoc:demo-Pfad, den man lokal laufen liesse, plus e2e gegen die eingespeiste Konsole, nachts wiederholt compose-smoke-nightly mit kalten Caches. Ein rotes Badge gilt laut README als Release-Blocker, die Demo-Bootfaehigkeit auf main ist damit eine erzwungene Zusicherung, nicht eine Behauptung.

aisoc-sandbox: fuenf Szenarien von lateral-movement bis github-token-theft

Der erste Weg in der README-Tabelle ist zugleich der neue: aisoc-sandbox, installiert mit pip install -e packages/aisoc-sandbox und gestartet mit aisoc-sandbox demo. Es ist ein null-abhaengiger, rein in-memory-Simulator der Agenten-Funnel, der eine Offline-Untersuchung durch die Phasen Detect, Triage, Hunt und Respond fuehrt und auf stdout druckt, in unter 5 Sekunden, ohne API-Schluessel und ohne Netzwerk.

Der Simulator bringt gebuendelte Szenarien mit: lateral-movement, aws-credential-exfil, phishing-payload, kubernetes-privesc und github-token-theft. Eigene Faelle lassen sich per JSON-Datei ueber den Schalter --file einspeisen. Damit ist die Sandbox ein Testbett fuer Prompts und Auswertungen, das ohne Infrastruktur auskommt.

Die anderen drei Wege booten dagegen den echten Stack: Docker plus pnpm mit pnpm aisoc:demo bringt Postgres, Redis, Kafka, api, agents und web hoch, Codespaces benoetigt rund fuenf Minuten Kaltstart und Port 3000, und das Bootstrap-Skript installiert die Werkzeugkette automatisch. Beendet wird der lokale Stack mit pnpm aisoc:demo:down. Wer Szenarien vergleichen will, faehrt mit der Sandbox billiger, wer die Echtkette pruefen will, nimmt Docker.

Datenfluesse und Pseudonymisierung: docs/trust/data-flows.md

Das dritte Unterscheidungsmerkmal betrifft den Datenabfluss. AiSOC verspricht keine Rueckrufe an eine Hersteller-Cloud und keine Telemetrie unter dem Stichwort Modellverbesserung. Bei einem gehosteten LLM werden die Belege standardmaessig pseudonymisiert: interne IPs, Hostnamen, E-Mail-Adressen, Pfade, Secrets und Nutzernamen werden zu opaken Token. Wer eine voelligluftabgeschirmte Strecke will, faehrt ein lokales Modell mit Ollama oder vLLM.

Welche Daten in welchem Modus verlassen, steht laut README genau in docs/trust/data-flows.md. Diese Datei ist der zentrale Leseort fuer jeden Betreiber, denn die Antwort auf die Frage, was den Perimeter verlaesst, haengt am Betriebsmodus, nicht am Tool.

Der produktionsnahe Rahmen ist entsprechend ausgewiesen: Der Multi-Plattform-Deploy-Leitfaden liegt in apps/docs/docs/installation.md und deckt Render, Fly.io, Docker Compose, Kubernetes und Terraform ab, fuer den vollwertigen Speichertier gibt es infra/helm/ und infra/terraform/. Die Community-Demo auf tryaisoc.com laeuft laut README auf Fly.io und kann offline gehen, der Runbook-Pfad ist docs/operations/live-demo-runbook.md, als Dauerfalle dient Codespaces.

LangGraph-Orchestrator und der Vergleich mit Wazuh und Splunk ES

Das README stellt AiSOC in eine Vergleichstabelle mit Wazuh, Splunk ES und geschlossenen KI-SOC-Anbietern. Die Achsen sind Offenheit und Hosting: Wazuh ist GPL-2-lizenziert und selbst hostbar, hat aber laut Tabelle keine autonome KI-Untersuchung, Splunk ES ist proprietär und enterprise-only, geschlossene KI-SOCs sind cloud-only, AiSOC hingegen MIT-lizenziert, selbst hostbar und mit LangGraph-basierter Untersuchung samt oeffentlichem Entscheidungsprotokoll.

Inhaltlich beschreibt sich AiSOC als ein einzelner selbst hostbarer Stack, der Sicherheitsereignisse aufnimmt, korreliert, KI-gestuetzte Untersuchung laufen laesst und die Ergebnisse in einer SOC-Konsole ausgiebt. Die Release-Historie zeigt v7.5.0 vom 29. Juni 2026, v7.6.0 vom 13. Juli 2026 und v7.7.0 vom 4. August 2026, ein dichter Takt mit 2.384 Sternen und 252 Forks.

Die harte Grenze aller Aussagen ist die Quellenlage: Rule-Anzahlen und Benchmark-Ergebnisse stehen im README, die Metadaten des Repositories pruefen sie nicht. Fuer die Einfuehrungsentscheidung zaehlt deshalb der Eigenlauf: erst aisoc-sandbox, dann pnpm aisoc:demo, und die Zahlen aus apps/docs/docs/benchmark.md gegen die eigenen Erwartungen halten.

Redaktionelles Fazit

AiSOC passt fuer Sicherheitsteams, die eine KI-gestuetzte Triage und Untersuchung im eigenen Netz betreiben wollen und Transparenz ueber Agentenentscheidungen brauchen, etwa wegen Audit-Pflichten. Fuer Betreiber ohne eigene Infrastruktur oder ohne Interesse an einem umfangreichen Stack aus Kafka, Postgres und ClickHouse ist es zu schwer. Pruefen Sie zuerst npx aisoc triage --demo gegen einen eigenen Alert-Stapel und lesen Sie apps/docs/docs/benchmark.md, um zu verstehen, was die gemeldete Noise-Reduktion misst und was nicht.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes