Sicherheitsverantwortliche weltweit haben ein Umdenken vollzogen. Während KI-Projekte lange mit Misstrauen betrachtet wurden, wächst die Bereitschaft, diese Technologien strategisch in Security Operations einzubauen. Doch zwischen Idealvorstellung und Realität gibt es erhebliche Unterschiede.
Frederick Lee, Chief Information Security Officer bei Reddit, beschreibt die praktische Anwendung: Sein Team nutzt LLMs vor allem zur Automatisierung und Vereinfachung bisher manueller Prozesse. Ein Beispiel ist die Workflow-Plattform Tines, die durch natürlichsprachige Befehle leichter bedienbar wird. Ein weiteres Anwendungsfeld ist die Umwandlung bestehender Runbooks in KI-gestützte Agenten, die eigenständig Sicherheitsvorfälle bearbeiten können.
Besonders wertvoll erweist sich die Fähigkeit von LLMs, natürliche Sprache in spezialisierte Query-Sprachen zu übersetzen. Statt komplexe Befehle in Tools wie Splunk oder BigQuery zu erlernen, können Analysten einfach ihre Fragen formulieren – die KI übersetzt die Anfrage automatisch. Das spart Zeit und senkt die Einstiegshürden für weniger erfahrene Sicherheitsfachleute.
Dave Gruber, Analyst bei Omdia, unterteilt die KI-Anwendungen in zwei Kategorien: Horizontale Use Cases wie automatische Datenberreichung, Malware-Sandboxing und die Zusammenfassung von Incident Reports – Aufgaben, die KI bereits sehr gut bewältigt. Dann gibt es vertikale Use Cases wie Threat Intelligence Analysis, wo es besonders wichtig ist, externe Bedrohungsinformationen schnell in die eigene Infrastruktur zu integrieren. Jede Verzögerung erhöht das Risiko.
Risiken und Fehlentwicklungen
Doch das Risiko ist real. Lee weist auf mehrere kritische Probleme hin: Prompt Injection, vergleichbar mit SQL-Injection in traditioneller Programmierung, kann dazu führen, dass Angreifer LLMs manipulieren. Noch problematischer ist, dass viele Organisationen ihre Zugriffskontrolle nicht hinreichend durchdacht haben. Wenn LLMs zur Wissensvermittlung eingesetzt werden, werden gleichzeitig Dokumentenzugriffe offengelegt, die eigentlich beschränkt sein sollten – Mitarbeiter können sich unbemerkt Informationen beschaffen, zu denen sie nicht berechtigt sind.
Ein weiteres Problem: Viele Teams nutzen ihre Standard-Mitarbeiterzugangsdaten für LLM-Anfragen. Dadurch wird unklar, ob eine bestimmte Aktion von einem Menschen oder einem Bot ausgeführt wurde. Schlimmer noch, Keys und Credentials werden oft fahrlässig in LLM-Systemen gespeichert und können von Angreifern extrahiert werden.
Zum Thema “KI schreibt unsicheren Code” nimmt Lee eine differenzierte Position ein. Die vielzitierte Veracode-Studie aus dem Jahr 2025 zeigte, dass LLMs sichere Implementierungen nur in 45 % der Fälle wählten und in 86 % der Fälle Cross-Site-Scripting-Schwachstellen nicht verhinderten. Allerdings handelt es sich dabei um sechs Monate alte Forschung – und Lee argumentiert, dass die Kontexte entscheidend sind. Entwickler in etablierten Unternehmungen arbeiten mit Guidelines, Best-Practice-Beispielen und Security-Richtlinien. LLMs sind hervorragend darin, solche Vorgaben zu befolgen.
Daten und Prozesse entscheiden
Gruber bringt einen entscheidenden Punkt auf den Tisch: Datenhygiene ist kritischer als je zuvor. Während Menschen intuitiv offensichtliche Fehler erkennen und filtern können, tun das automatisierte Systeme nicht. Wenn Millionen von Datensätze in ein KI-Modell fließen, muss deren Qualität überprüft sein. Das ist besonders bei SOAR-ähnlichen automatisierten Systemen entscheidend – schlecht strukturierte Daten führen zu schlechten Entscheidungen.
Lee verdeutlicht dies an einem Beispiel: LLMs werden nur dann gute Ergebnisse liefern, wenn die Grundlagen stimmen. Ein Unternehmen mit mangelhaften Prozessen wird dieselben Fehler durch KI einfach schneller replizieren.
Implementierung und Strategie
Für Organisationen, die KI in ihren SOC einführen möchten, empfehlen die Experten folgende Schritte:
Architektur-First-Ansatz: Ein LLM-Gateway sollte kontrollieren, welche Modelle verwendet werden. Model Context Protocol (MCP) Gateways ermöglichen bessere Auditierbarkeit und Zugriffskontrolle.
Bestehende Prozesse überprüfen: Nicht jedes Problem erfordert KI. Der erste Schritt sollte sein, bestehende Sicherheitslücken zu identifizieren – mangelnde Zugriffskontrolle, schlechte Dokumentation, unklare Runbooks.
Klein anfangen: Low-Hanging-Fruit identifizieren – gut definierte Runbooks in agentenbasierte Workflows umwandeln, automatische Summarization für Incident Reports nutzen.
Ressourcenrealistisch planen: Kleinere Organisationen sollten mit Managed Security Service Providern (MSSPs) zusammenarbeiten. Größere Unternehmen können in-house experimentieren und gleichzeitig kommerzielle Lösungen nutzen.
Vendor-Druck: Security-Käufer signalisieren deutlich, dass Anbieter ihre Tools mit KI-Funktionen erweitern müssen – oder werden ausgetauscht.
Die ROI-Frage
Zum Thema Kosten: Eine KI-Sicherheitslösung, die einem Sicherheitsanalyst entspricht und das Gehalt eines Analysten kostet, amortisiert sich schnell. Ein Analyst arbeitet 8 Stunden täglich – eine KI läuft 24/7/365. Das ist wirtschaftlich sinnvoll, wenn die Lösung tatsächlich funktioniert.
Aber es gibt auch Verschwendung: Viele Unternehmen implementieren KI, weil es gerade trendig ist, nicht weil ein echtes Problem gelöst wird. Das führt zu Frustration bei Teams, hohen Kosten und schlechten ROI-Zahlen.
Fazit: Strategie vor Technologie
Die Botschaft der Experten ist klar: KI ist kein Allheilmittel, sondern ein Werkzeug. Unternehmen, die damit erfolgreich sind, beginnen mit einer klaren Problemdefinition, überprüfen ihre Daten und Prozesse, und implementieren dann gezielt – mit menschlicher Aufsicht. Für deutsche Unternehmen bedeutet dies, realistische Erwartungen zu setzen und nicht dem Hype hinterherzulaufen. Die größten Chancen liegen in der Automatisierung von Routineaufgaben und der Verbesserung der Analysefähigkeiten – aber nur mit solider Governance.