KI hat unser Security-Team nicht ersetzt, sie hat es multipliziert

Jahrelang war die Annahme in der Security-Branche unkompliziert: Ausgereifte Detection-and-Response-Programme erfordern ein SOC (Security Operations Center). Ein Team von Analyst:innen, das vor einer Wand von Monitoren sitzt und auf einen ausgelösten Alert wartet.

Dieses Modell machte Sinn, solange der einzige Weg, menschliches Urteilsvermögen zu skalieren, darin bestand, mehr Menschen einzustellen.

Die ehrliche Version von KI im SOC

Das Gespräch über KI in der Security ist derzeit größtenteils Vendor-Rauschen. Jedes Tool verspricht, ein einzelnes Silo des SOC zu lösen. Triage. Enrichment. Threat Intel. Kauft man genug davon, hat man einfach denselben fragmentierten Stack wieder aufgebaut, nur mit einem KI-Badge auf jedem Teil.

Was niemand laut genug sagt, ist dies: Man muss sich den Weg zu KI-gestützter Security nicht erkaufen. Ein kleines, technisches und motiviertes Team kann diese Fähigkeiten intern aufbauen, mit engerer Integration, besserem Kontext und weit mehr Kontrolle, als es jedes Vendor-Produkt bieten wird.

Bei Webflow haben wir das letzte Jahr damit verbracht, KI in unsere Detection-and-Response-Workflows zu integrieren. Nicht als Pilotprojekt. Nicht als Demo. In Produktion, aktiv weiterentwickelt und noch immer im Wandel. Und das Wichtigste, was wir gelernt haben, ist dies:

KI hat nicht verändert, wie gute Security aussieht. Sie hat verändert, wie viel ein Team leisten kann.

Was wir tatsächlich gebaut haben

Webflows Programm für Security-Detection-and-Response wird von Engineers geführt. Es gibt kein SOC. Es gibt keine dedizierten Analyst:innen im Schichtwechsel. Es gibt ein kleines Team von Security-Engineers, die für den gesamten Lebenszyklus verantwortlich sind: vom Schreiben und Testen von Detections über das Reagieren auf Incidents bis hin zur laufenden Verbesserung des Systems. Lange bedeutete das gnadenlose Priorisierung, denn man kann unmöglich alles untersuchen. Man trifft Trade-offs.

KI hat diese Trade-offs auf zwei konkrete Arten verschoben.

1. Triage, die nicht bei null anfängt

Früher begann jeder Alert auf dieselbe Weise: das Ticket öffnen, den Kontext ziehen, das Asset-Ownership prüfen, aktuelle Aktivitäten korrelieren, eine vorläufige Schweregrad-Einschätzung treffen. Die Arbeit ist nicht schwer, aber zeitaufwändig. Man loggt sich in mehreren Plattformen ein, um Logs über mehrere Systeme hinweg zu validieren, noch bevor die eigentliche Untersuchung überhaupt beginnt.

Ehrlich gesagt hat KI uns hier zum Handeln gezwungen. Als wir eine Zunahme der Detections um 200 % in einem einzigen Quartal sahen, wurde klar: Das alte Modell – jeder Alert startet bei null, jede Triage läuft manuell – würde nicht standhalten. Wir mussten den Workflow neu denken, nicht nur Kapazität hinzufügen.

Wir nutzen KI jetzt, um die Zusammenstellungsarbeit zu leisten, bevor ein Engineer überhaupt einen Alert ansieht. Bis ein Mensch einbezogen wird, hat das Ticket bereits angereicherten Kontext, relevante historische Signale und eine vorläufige Schweregrad-Bewertung. Und bei Alerts, bei denen wir mit hoher Sicherheit von einem False Positive ausgehen, haben wir Auto-Close-Mechanismen gebaut, die die Auflösung vollständig ohne menschliches Eingreifen übernehmen. Das ist keine Abkürzung. Es ist eine bewusste architektonische Entscheidung, aufgebaut auf Monaten von Tuning und Validierung. Wir wissen genau, welche Alert-Muster die Schwelle für Auto-Close erfüllen, und überprüfen dieses Kriterium regelmäßig, wenn sich unsere Umgebung verändert. Diese kleinen Änderungen haben unserem Team 504 Stunden in einem einzigen Quartal gespart. 

Der Engineer trifft weiterhin jede Ermessensentscheidung, die zählt. Die KI übernimmt die Vorbereitung und nimmt die eindeutigen False Positives komplett aus der Bearbeitung.

Was wir in der Praxis gesehen haben: schnellere Triage, weniger Erschöpfung durch Kontextwechsel und qualitativ hochwertigere Untersuchungen, weil Engineers von einem vollständigeren Bild starten, statt es unter Druck von Grund auf aufzubauen.

2. LLMs als Ermittlungspartner

Das schwierigere Problem ist die mehrdeutige Untersuchung – die Art, bei der Signale über Identity-, Endpoint- und Applikationsebenen hinweg zusammengesetzt werden müssen, ohne dass ein Playbook eindeutig passt. Unabhängig von der Erfahrung fragen sich Responder oft: „Was mache ich als Nächstes?"

Hier experimentieren wir am vorsichtigsten mit LLMs. Nicht um Entscheidungen zu treffen, sondern um die kognitive Last bei komplexer Triage zu senken: Rohdaten-Logvolumen zusammenfassen, ähnliche vergangene Incidents und deren zugehörige Playbooks aufzeigen, nächste Schritte vorschlagen und erste Zeitleisten entwerfen, die ein Engineer anschließend validiert und erweitert. Der Mensch bleibt an jedem bedeutsamen Entscheidungspunkt im Loop. Das ist keine Einschränkung, um die wir herumarbeiten. Es ist ein Designprinzip. KI zeigt auf, organisiert und schlägt vor. Engineers validieren, entscheiden und handeln. In dem Moment, in dem diese Grenze verschwimmt, entsteht ein Risiko, das schwer zu prüfen und noch schwerer nachträglich zu erklären ist.

Wir gehen bewusst damit um, wo wir KI-Ausgaben vertrauen und wo wir sie unabhängig überprüfen. Dieses Vertrauen wird schrittweise erworben, genauso wie wir Vertrauen in jede neue Detection-Logik aufbauen, bevor wir sie unüberwacht laufen lassen.

3. KI im Post-Incident-Prozess

Eine der am meisten unterschätzten Anwendungen von KI in der Security liegt gar nicht in der Detection- oder Response-Phase. Sie liegt in dem, was passiert, nachdem ein Incident geschlossen wurde.

Die Post-Incident-Analyse ist einer dieser Prozesse, deren Wert alle anerkennen und in die fast niemand investiert. Wenn man gerade Stunden oder Tage im Response-Modus verbracht hat, ist es das Letzte, wofür man Energie übrig hat, sich hinzusetzen und eine gründliche Post-Incident-Analyse zu schreiben. Das Ergebnis ist meist eine Dokumentation, die dünner ausfällt als sie sollte, Action Items, die nicht nachverfolgt werden, und Lektionen, die es nicht zurück in die Playbooks schaffen.

Wir haben angefangen, KI zu nutzen, um das zu ändern.

Nachdem ein Incident geschlossen wurde, füttern wir die KI mit dem gesamten Beweismaterial aus der Response: jede Nachricht aus dem Incident-Channel, alle Meeting-Transkripte, Notizen, Timeline-Dokumente und relevante Artefakte. Die KI übernimmt dann die Synthesearbeit, die früher Stunden dauerte:

• Alle Kommunikation und Dokumente durchsehen, um eine vollständige Incident-Timeline zu rekonstruieren.
• Die Post-Incident-Analyse entwerfen: erfassen, was passiert ist, was wir richtig gemacht haben, was wir übersehen haben und wo wir Glück hatten.
• Action Items generieren, mit genug Kontext, dass sie tatsächlich umsetzbar sind, nicht nur vage Erinnerungen.
• Playbooks aktualisieren oder erstellen, basierend auf dem, was der Incident aufgedeckt hat: Lücken füllen, Annahmen korrigieren und die Randfälle erfassen, die nur bei echten Incidents auftauchen.

Es ist einfach, einen Post-Incident-Review zu schreiben, der sich darauf konzentriert, was schiefgelaufen ist und was gut lief. Die schwierigere und wertvollere Aufgabe ist es, die glücklichen Zufälle festzuhalten – die Dinge, die gut liefen, nicht wegen, sondern trotz des Systems. Genau dort verstecken sich oft die wichtigsten Verbesserungen. KI ist überraschend gut darin, diese aufzuzeigen, wenn sie den vollen Kontext der Incident-Kommunikation hat.

Das Ergebnis ist eine Post-Incident-Dokumentation, die vollständiger ist, schneller entsteht und tatsächlich in das Detection-and-Response-System zurückfließt, statt irgendwo in einem Ordner zu verstauben. Jeder Incident erzeugt ein konkretes Ergebnis: ein aktualisiertes Playbook, eine markierte Lücke, eine vorgeschlagene Detection-Regel. KI übernimmt die Fleißarbeit. Engineers übernehmen die Validierung und schließen den Kreislauf. Der Unterschied ist, dass in der Erschöpfung nach einem harten Incident nichts verloren geht.

Der Teil, den die meisten KI-Security-Inhalte auslassen

Hier ist, was nicht oft genug gesagt wird: KI-gestützte Response ist nur so gut wie das Fundament darunter.

Bevor wir Wert aus KI-Triage ziehen konnten, brauchten wir:

• Saubere, verlässliche Datenpipelines, die unser SIEM speisen – nicht nur Datenvolumen, sondern korrekt formatierte und normalisierte Daten, mit denen KI tatsächlich sinnvoll arbeiten kann.
• Ein gut gepflegtes Asset-Inventar, damit die Enrichment-Daten korrekt sind.
• Detection-Logik, die eng genug abgestimmt ist, damit KI nicht einfach nur schneller Rauschen verarbeitet.
• Dokumentierte Playbooks und Incident-Historie, mit denen LLMs arbeiten können.

Sind diese Dinge nicht vorhanden, löst KI das Problem nicht. Sie skaliert es. Verrauschte Detections werden noch verrauschter. Veralteter Kontext wird selbstbewusst präsentiert. False Positives werden effizienter abgearbeitet – direkt in verschwendete Engineering-Zeit.

Die Teams, die wir mit KI in der Security kämpfen sehen, scheitern nicht, weil sie das falsche Modell gewählt haben. Sie scheitern, weil sie versuchen, mit KI grundlegende Lücken zu kompensieren, die KI nicht füllen kann.

Was „modellagnostisch" für uns wirklich bedeutet

Wir binden uns bewusst nicht an einen einzigen KI-Anbieter. Das Tooling in diesem Bereich entwickelt sich zu schnell weiter, um diese Wette einzugehen, und die zugrunde liegende Fähigkeit zählt mehr als die Marke.

Was wir festgestellt haben: Die richtige Frage ist nicht „welches Modell?". Sie lautet: „Wo schafft KI-Urteilsvermögen Mehrwert, und wo braucht es eine menschliche Prüfung?" Diese Frage muss pro Use Case, pro Risikostufe und, ehrlich gesagt, pro Incident-Typ beantwortet werden.

Manche Alerts sind gute Kandidaten für KI-gestützte Auto-Triage. Andere – alles, was privilegierten Zugriff, Kundendaten oder mögliche Breach-Szenarien betrifft – bekommen zuerst menschliche Augen, mit KI als unterstützender Ebene statt als führender. Das ist eine bewusste architektonische Entscheidung, keine Lücke, die wir schließen wollen.

Was ein kleines Team jetzt tatsächlich leisten kann

Security für ein wachsendes Unternehmen ohne SOC zu betreiben, bedeutete früher, eine Obergrenze dafür zu akzeptieren, wie viel man abdecken konnte. Man stimmte Detections ab, um das Volumen zu senken, automatisierte das Offensichtliche und triagierte den Rest nach Priorität.

Diese Obergrenze hat sich verschoben. Nicht weil KI Magie ist, sondern weil KI die wiederholbare kognitive Arbeit gut genug übernimmt, damit Engineers mehr Zeit für die urteilsintensive Arbeit haben, die sie tatsächlich braucht.

Schnellere Triage. Bessere Untersuchungsqualität. Weniger Erschöpfung an Tagen mit hohem Alert-Volumen. Wir messen die langfristige Wirkung noch immer sorgfältig, doch das Richtungssignal ist klar.

Ein kleines, gut strukturiertes Security-Team mit KI, die in jede Schleife des Incident-Response-Lebenszyklus integriert ist, ermöglicht es uns, auf einem Niveau zu agieren, das vor zwei oder drei Jahren deutlich mehr Personal erfordert hätte. Das ist kein Vendor-Pitch. Es ist, was wir in der Praxis beobachten.

Das Fazit

Man braucht kein SOC. Man braucht ein System – eines mit sauberen Daten, engen Detections, dokumentierten Prozessen und Feedback-Loops, die es mit der Zeit klüger machen. KI ersetzt dieses System nicht. Sie ermöglicht es einem kleinen Team von Engineers, die sich gegenseitig vertrauen, sich im Tempo des Geschäfts zu bewegen, ohne dafür Personal aufstocken zu müssen. Bauen Sie zuerst das Fundament. Verstehen Sie Ihre Bedrohungslandschaft, bevor Sie automatisieren. Und wenn Sie KI in den Loop holen, seien Sie ehrlich darüber, wo sie sich Vertrauen verdient und wo es noch eine menschliche Prüfung braucht.

Das ist die Version von KI-gestützter Security, die tatsächlich funktioniert.