Wie man beurteilt, ob ein SOC für KI-Agenten bereit ist

Die Einführung von KI wird bei Teams für den Sicherheitsbetrieb zunehmend verbreitet. Die Studie „State of AI in Security Operations 2026“ von Prophet Security unter mehr als 250 CISOs, SOC-Leitern und Praktikern ergab, dass 40 % der Teams KI täglich einsetzen, während weitere 56 % sie testen. Nur 4 % erklärten, dass sie keine Pläne zur Einführung der Technologie hätten.

Für Teams, die KI noch bewerten, lautet die zentrale Frage, ob ihr SOC bereit ist, Agenten einzusetzen. Bereitschaft hat zwei Dimensionen: die operativen Probleme, die ein KI-Agent lösen könnte, sowie die technischen und Governance-Grundlagen, die erforderlich sind, um Warnungen präzise zu untersuchen.

KI-Agenten sind besonders nützlich in SOCs, die mit verspäteten Eskalationen aus Managed Detection and Response, fehlendem Kontext, einer begrenzten Abdeckung durch Anbieter, Warnungsrückständen und mangelnder Transparenz bei Untersuchungsentscheidungen umgehen müssen. Interne Teams haben möglicherweise ebenfalls Schwierigkeiten, schnell zu beantworten, ob sie von einer neuen Schwachstelle oder Kampagne betroffen sind, Warnungen mit niedrigerem Schweregrad zu untersuchen, verrauschte Erkennungen zu optimieren, Threat Hunts durchzuführen und die Abdeckung außerhalb der normalen Arbeitszeiten aufrechtzuerhalten.

Die Studie ergab, dass 60 % der Befragten erlebt hatten, dass eine ignorierte oder übersehene Warnung später zu einem schwerwiegenden Problem wie einem Sicherheitsverstoß oder einer Dienstunterbrechung wurde. Außerdem wurde berichtet, dass 28 % der Warnungen nie untersucht werden. Dadurch konkurrieren proaktive Suche und Detection Engineering mit der täglichen Bearbeitung von Warnungen.

Das von Prophet Security beschriebene Reifegradmodell für SOCs stellt das Warnungsmanagement an die Basis, gefolgt von Erkennungsabdeckung, Bedrohungsbewusstsein, proaktiver Suche und Verbesserungen der Sicherheitslage. KI-Agenten beginnen im Allgemeinen mit der Untersuchung von Warnungen, obwohl neuere Plattformen auch Threat Hunting und Detection Engineering unterstützen können. Die durch Routinearbeiten zurückgewonnene Zeit kann anschließend auf Aktivitäten weiter oben im Modell gelenkt werden.

Die technische Bereitschaft beginnt mit dem Zugriff. Ein Agent kann nur Daten untersuchen, die er abfragen kann. Relevante Integrationen können daher das SIEM, EDR, den Identitätsanbieter, Cloud-Plattformen, E-Mail und wichtige SaaS-Anwendungen umfassen. Außerdem benötigt er lesbaren Kontext wie die Kritikalität von Assets, Benutzerrollen, VIP-Listen, Geschäftsbereiche und bekannte gutartige Aktivitäten. Ebenso wichtig ist die Überwachung des Zustands und der Aktualität von Protokollierungspipelines, da fehlende oder verspätete Daten eine Untersuchung vollständig erscheinen lassen können, obwohl wichtige Beweise fehlen.

Ein praktischer Test besteht darin, fünf kürzlich bearbeitete Vorfälle zu prüfen und jede Abfrage aufzulisten, die ein erfahrener Analyst zu ihrer Klärung verwendet hat. Jede Abfrage, die der geplante Agent nicht ausführen kann, weist auf eine Zugriffs- oder Integrationslücke hin. Auch der Umgang mit Daten muss geprüft werden: 44 % der Befragten nannten den Datenschutz und das Training von KI-Modellen als großes Hindernis. Organisationen sollten Anbieter fragen, ob Kundendaten zum Training von Modellen verwendet werden und wo diese Daten verarbeitet werden.

Für einen Pilotversuch ist außerdem eine schriftliche Definition einer abgeschlossenen Untersuchung erforderlich. Dieser Standard sollte festlegen, welche Beweise für typische Fälle wie Phishing- und Impossible-Travel-Warnungen benötigt werden und was ausreicht, um eine Warnung als gutartig einzustufen. Organisationen sollten Ausgangskennzahlen erfassen, etwa den Prozentsatz der untersuchten Warnungen, die durchschnittliche Untersuchungsdauer, die Zeit bis zur ersten Prüfung und die Rate, mit der geschlossene Warnungen wieder geöffnet werden.

Der Bericht erklärt, dass eine gründliche Untersuchung durchschnittlich 75 Minuten dauert und dass Warnungen häufig fast eine Stunde warten, bevor sie geöffnet werden. Außerdem heißt es, dass bis zu 40 % der Organisationen einige Erkennungen deaktiviert haben, weil ihnen die Kapazität zu ihrer Prüfung fehlte. Eine dokumentierte Liste dieser Erkennungen kann dabei helfen, Bereiche zu identifizieren, in denen zusätzliche automatisierte Untersuchungen die Abdeckung wiederherstellen könnten.

Governance muss zwischen Untersuchung und Reaktion unterscheiden. In der Studie verlangten 57 % der Teams eine menschliche Prüfung vor jeder KI-Entscheidung, eine Warnung zu schließen. Bei Reaktionsmaßnahmen nutzten 44 % KI, um von Menschen auszuführende Maßnahmen zu empfehlen, während 30 % eine autonome Behebung bei Fällen mit geringem Risiko erlaubten. Kein Befragter berichtete, vollständige, unbeaufsichtigte Autonomie gewährt zu haben.

Vor einem Pilotversuch sollten Organisationen festlegen, welche Maßnahmen immer eine Genehmigung erfordern, wer die Berechtigungen des Agenten erweitern darf, wo seine Ergebnisse erscheinen und wer für die Prüfung von Fehlern verantwortlich ist. Mit schreibgeschütztem Untersuchungszugriff zu beginnen und die Berechtigungen schrittweise auszuweiten, entspricht demselben vorsichtigen Ansatz, der bei der Einführung eines neuen menschlichen Analysten verwendet wird.

Die vorgeschlagene Bereitschafts-Checkliste unterscheidet zwischen dem Bedarf an KI und der Fähigkeit, sie einzusetzen. Ein starker Grund für die Einführung kann bestehen, wenn Warnungen verspätet eintreffen, Anbietern Kontext fehlt, Untersuchungen verzögert werden, Erkennungen deaktiviert wurden oder schwierige Fälle von nur wenigen erfahrenen Analysten abhängen. Die Einsatzbereitschaft hängt dagegen von API-Zugriff, verfügbarem Asset- und Benutzerkontext, schriftlichen Untersuchungsstandards, Genehmigungsregeln, der Überwachung von Protokollquellen, Ausgangsdaten zur Leistung, einer Aufzeichnung deaktivierter Erkennungen und einem Plan für die Nutzung der an das Team zurückgegebenen Zeit ab.

Wenn das SOC nicht bereit ist, besteht die empfohlene Vorbereitung weitgehend aus Konfigurations- und Dokumentationsarbeit. Teams können damit beginnen, die bei der Prüfung der fünf Vorfälle festgestellten Zugriffslücken zu schließen, Standards für ihre Warnungstypen mit dem höchsten Volumen zu dokumentieren und einen Agenten mehrere Wochen lang parallel zu Analysten laufen zu lassen. Übersteuerungen durch Analysten sollten als Hinweise auf fehlenden Kontext oder fehlerhaftes Verhalten aufgezeichnet werden. Anschließend können die Berechtigungen schrittweise um jeweils eine Handlungskategorie erweitert werden.

Der Aufbau eines eigenen Agenten ist eine weitere Option, doch die Studie weist auf erhebliche Risiken hin. Unter den KI-Nutzern hatten 72 % versucht, interne KI-Tools zu entwickeln, und 46 % dieser Projekte wurden aufgegeben, erreichten die Produktion nicht oder wurden durch ein kommerzielles Produkt ersetzt. Über einen Prototyp hinaus müssen Teams Integrationen pflegen, API-Änderungen und Ratenbegrenzungen bewältigen, Modellabkündigungen verwalten, Evaluierungen und Tests auf Prompt-Injection wiederholen und Prüfpfade erhalten, die die Entscheidungen zu Warnungen erklären.

Prophet Security beschreibt seine eigene Prophet-AI-Plattform als eine Lösung für Untersuchungen, Threat Hunting und Detection Engineering. Der SOC-Analyst-Agent fragt Sicherheitstools ab und zeichnet die Fragen, Abfragen und Beweise hinter den Entscheidungen auf, während Reaktionsmaßnahmen weiterhin den vom Kunden festgelegten Berechtigungen und der standardmäßigen menschlichen Genehmigung unterliegen. Die Komponente Threat Hunter soll Suchen nach neu veröffentlichten Bedrohungen und geplanten Untersuchungen durchführen, während die Komponente Detection Engineer Untersuchungsergebnisse und Abdeckungslücken nutzt, um vor der Genehmigung Erkennungen vorzuschlagen und Backtests durchzuführen.

Nach Angaben des Unternehmens speisen sich die Ergebnisse dieser Funktionen gegenseitig: Untersuchungen können verrauschte oder fehlende Erkennungen aufdecken, Hunts können diese Lücken prüfen, und ihre Ergebnisse können in neue Erkennungsregeln einfließen. Prophet Security erklärt außerdem, dass Kundendaten nicht zum Training seiner Modelle verwendet werden und dass seine Datenebene innerhalb der eigenen Virtual Private Cloud eines Kunden ausgeführt werden kann.

Quellen: The Hacker News.