Wettrüsten : Hase und (K)Igel 4.0 : Wie Unternehmen im KI-Wettlauf mit Angreifern die Nase vorn behalten
Angreifer setzen verstärkt auf generative und agentische KI – Sicherheitsverantwortliche ziehen nach und setzen ebenfalls zunehmend auf KI, um Angreifer mit gleichen Mitteln zu kontern. Doch zwischen Anspruch und Realität klafft eine wachsende Lücke. Welche Maßnahmen können Unternehmen wirklich ergreifen, um mit der Angreiferseite Schritt zu halten und dieser sogar einen Schritt voraus zu sein?
Viele Security-Anbieter werben mit KI-gestützten Tools – doch entscheidend ist deren Zusammenspiel: Ohne produktübergreifende Korrelation lässt sich ein SOC nicht sinnvoll auf KI-Abläufe umstellen; stattdessen drohen KI-Alarmfluten. Zudem lassen sich erfolgreiche Kompromittierungen selten mit einem einzelnen Tool erkennen oder priorisieren. Für die Erkennung identitätsbasierter Angriffe müssen Analysten Indicators of Attack (IoAs, Angriffsindikatoren) aus verschiedenen Quellen zusammenführen – genau hier setzt der Aufbau einer passenden KI-Umgebung für das SOC an.
KI-Umgebung für SOCs
Auf Plattformen wie etwa Hugging Face stehen zahlreiche große und kleine Sprachmodelle (Large/Small Language-Models – LLMs/SLMs) zur Auswahl. Die Herausforderung besteht darin, das passende Modell für die jeweilige Aufgabe zu wählen. Entscheidend ist dabei, welche KI-Agenten man im SOC einsetzen will: einfache Agenten, die Informationen extrahieren, oder komplexere, die ihre Ergebnisse hinterfragen und nachvollziehbar begründen (Reasoning)?
Unternehmen versuchen in der Regel zunächst, alles mit einem LLM wie Anthropic Opus 4.6 oder 4.7 abzudecken. Das Risiko liegt dabei darin, mit Kanonen auf Spatzen zu schießen, also viele Tokens zu verbrauchen, sodass die Kosten eskalieren. Das Modell muss zum Aufgabenbereich der KI-Agenten passen. Für Extraktionsagenten reicht beispielsweise auch ein SLM.
System- und Input-Prompts
Ein KI-Agent umfasst im Prinzip einen sehr ausführlichen Prompt. Je nach Aufgabe erhält er Zugriff auf Tools via Model-Context-Protocol (MCP, siehe auch [4]) oder sonstige Programmschnittstellen (APIs). Die Ergebnisqualität hängt stark vom richtigen System- und Input-Prompting ab – schließlich ist das Kernproblem aller KI-Modelle: Sie halluzinieren. Wichtig ist daher ein sehr detailliertes Prompting, zum Beispiel: „Beziehe dich nur auf den Input, den ich dir gebe, nicht auf dein Hintergrundwissen aus dem Training. Zeige mir in Einzelschritten auf, wie du zum Ergebnis gekommen bist.“
Mit Tools wie LangGraph lassen sich KI-Agenten orchestrieren: Nutzer* legen damit fest, in welcher Reihenfolge welche Agenten auszuführen sind. Ein Agent erledigt dann seinen Job und spielt das Ergebnis zurück – davon hängt im Entscheidungsbaum das weitere Vorgehen ab.
Feintuning mittels Golden Data-Set
So lassen sich Agenten-Workflows erstellen – doch diese weisen zunächst eine hohe Fehlerrate auf. Das Feintuning erfordert einen Datenpool mit einem sogenannten „Golden Data-Set“, also einer gelabelten Menge von Input, zu dem der Nutzer den Soll-Output kennt (wie aus dem Einsatz für Machine-Learning bekannt). So kann er das LLM über sein Golden Data-Set laufen lassen, das Ergebnis prüfen und die Fehlerrate senken.
Die Herausforderung: Dieser Prozess erfordert eine große Menge realer, gelabelter Daten, um belastbare Ergebnisse zu liefern. Manche KI-Start-ups offerieren daher auch Abwehr-Tools, die mit synthetischen Daten trainiert wurden. Aber ein Vergleich deckt die Schwachstelle hierbei auf: Ein „Street-Fighter“-Computerspiel gespielt zu haben, bedeutet eben nicht, für den physischen Straßenkampf bereit zu sein.
Eine weitere Hürde liegt darin, dass der Ablauf iterativ erfolgen muss. Oft sind Unternehmen aber nicht selbst der Dateneigner: Ändert beispielsweise ein SecurityAnbieter die Struktur seiner Alerts, dann verursacht dies Abweichungen (sog. Drift) in den Ergebnissen. Hinzu kommt der LLM-typische Model-Drift, da Modelle mit der Zeit „altern“ und deshalb immer wieder neu trainiert werden müssen.
Die Frage des Konfidenzwerts Zentral ist bei der Agentenerstellung die Definition des Konfidenzwerts: Ab welchem Wert erfolgen KI-Aktionen automatisiert, bis zu welchem Wert involviert man Menschen, um zu kontrollieren (Human on the Loop) oder einzugreifen (Human in the Loop)? Ist der Konfidenzwert zu niedrig angesetzt, häufen sich Fehler der KI-Agenten – ist er zu hoch, bleibt die Entlastung des SOC-Teams aus. Denn in letzterem Fall tritt lediglich eine KI-Meldungsflut an die Stelle der Alarmflut. Konfidenzwerte sollten daher beim Feintuning der KI-Agenten wohlüberlegt austariert werden.
Es empfiehlt sich, ein Golden Data-Set pro AlertTyp zu nutzen. Für typische SOC-Arbeitsabläufe werden allerdings unter anderem eine ganze Reihe von Ticket-Systemen und Bedrohungsinformationen abgefragt. Hierzu müssen alle benötigten historischen Daten vorliegen. Es ist daher ratsam, alle Daten konsequent zu speichern, wenn Agenten das Golden Data-Set durchlaufen – sonst lassen sich Ergebnisse später nicht sauber mit denen aus dem Feintuning vergleichen.
Sinnvoll ist zudem eine Limitierung des Einsatzes von KI-Agenten, um Performance- und Skalierungsprobleme zu vermeiden. Soll ein Agent beispielsweise im Ticket-System bestimmte Vorfälle aufspüren und ist der Prompt zeitlich nicht sauber eingeschränkt, dann sucht die KI über die gesamte Ticket-Historie hinweg. Und KIAgenten merken ja nicht, wenn ihre Abfragen ein System „zum Glühen“ bringen. Hinzu kommt: Agenten rufen Daten über APIs ab – auch diese müssen mit der Last klarkommen, die hierdurch plötzlich über sie hereinbricht.
Regelmäßige Stichproben gegen Drift
Als Praxisbeispiel soll ein KI-Agenten-Workflow das Rauschen (Noise) im Alert-Strom reduzieren: Erkennt das LLM einen Fall als False Positive, schließt ein KIAgent diesen selbsttätig. Ein gut justierter KI-Workflow kann hier bessere Ergebnisse liefern als ein SOC-Team. Solche Agentic Automation erfordert allerdings regelmäßige Spot-Checks (Stichproben), um Model- und Input-Drift aufzudecken und so die Fehlerrate dauerhaft im Zaum zu halten.
Hier gilt es zu definieren: Welche Fehlerrate will man erreichen und mit welchem Konfidenzintervall? Diese Parameter bestimmen Umfang und Häufigkeit der Qualitätsprüfungen. Je niedriger der akzeptierte Schwellenwert für die Fehlerrate und je geringer das tolerierte Risiko einer Fehlfreigabe des Agenten-Workflows (Signifikanzniveau) sind, desto größer ist die Menge der Stichproben pro Prüfzyklus zu wählen. Hier ist praxisgerechtes Justieren notwendig.
Arbeitsteilige Qualitätskontrolle
Die Qualitätskontrolle der KI beruht auf Arbeitsteilung: Datenwissenschaftler sind die Modell- und Prompting-Experten – sie wählen das passende Modell, orchestrieren die Agenten-Workflows und vermeiden, dass der KI-Einsatz unnötig viele Token verschlingt.
Die Durchführung stichprobenartiger Analysen der KI-Ergebnisse ist hingegen Aufgabe der Security-Analysten. Nur sie können beurteilen: Ist das Ergebnis richtig? Ist der Weg dorthin (das Reasoning) nachvollziehbar? Je stärker sich das SOC auf KI-Agenten stützt, desto zentraler wird die Funktion der SOC-Analysten als Qualitätsprüfer der KI-Ergebnisse.
Spot-Checks sind unumgänglich, lassen sich jedoch mithilfe eines „AI-Judge“ (KI-Richters) teilweise automatisieren: Hierzu nutzt das SOC-Team ein leistungsfähiges LLM, um die zu ausgewählte Stichprobe zu prüfen – dann vergleicht es das Ergebnis dieses LLMs mit dem aus dem Standard-Workflow. Nur bei Diskrepanzen muss ein SOC-Mitarbeiter näher nachforschen.
Geeignete KI-Einsatzfälle
Die zentrale Frage lautet, welche Use-Cases im SOC von KI-Agenten am stärksten profitieren. Angesichts von SOC-Teams, die durch Alarmfluten stark belastet sind, kann KI in einem ersten Schritt ihre Stärken nicht zuletzt bei der Triage von Alerts ausspielen und schnell messbare Erfolge erzielen. Die Triage eignet sich auch deshalb gut als erster Einsatzfall, weil hierfür im SOC bereits Runbooks vorliegen – daraus lassen sich Playbooks für Agenten-Workflows ableiten. Aber auch bei der Bedrohungssuche und der Reaktion auf Vorfälle kann KI das Tempo steigern, ebenso beim Security- und Compliancereporting.
Am effektivsten ist KI im SOC, wenn sie menschliches Fachwissen ergänzt, Rohdaten in Erkenntnisse umwandelt und es SOC-Teams ermöglicht, Routineabläufe zu beschleunigen. Zur Erkennung von Bedrohungen können KI-Agenten zum Beispiel aus Beschreibungen zu „Tactics, Techniques and Procedures“ (TTP) Kandidaten für die Erkennungslogik generieren, erkannte Bedrohungen über Umgebungen hinweg vergleichen und Lücken in der Telemetrieabdeckung aufspüren.
Die derzeitige Diskussion um Claude Mythos scheint überdies nahezulegen, dass SOC-Teams agentische KI nutzen sollten, um nach DevSecOps-Vorbild möglichst schnell vom Vulnerability-Management zu VulnOps zu gelangen. Offensichtlich sind Exploits vor allem für zum Internet ausgerichtete Ressourcen eine Gefahr – hier wird sich automatisches Patchen etablieren. Angreifer können aber dank KI viel leichter Schwachstellen in Konfigurationen automatisiert finden und ausnutzen. Deshalb ist es nützlicher, KI-Agenten zum automatisierten Audit von Konfigurationen einzusetzen.
Fazit
Die Security-Welt erlebt einen (weiteren) Wettlauf von Angreifern und Verteidigern – dieses Mal in Sachen KI-Einsatz. Gewinnen wird, wer KI am effektivsten in messbare Ergebnisse ummünzen kann.
Derzeit scheinen die Angreifer die Nase vorn zu haben, denn generative und agentische KI macht Angriffe kostengünstiger, schneller und effektiver. Doch Verteidiger haben einen Vorteil: Sie kennen ihre eigene Umgebung und können mithilfe von KI Systemhärtung, Angriffserkennung und -abwehr optimieren.
Theoretisch ist die Abwehr sogar in der „Pole-Position“ des KI-Rennens, doch es gibt etliche Bremsklötze in Form unübersichtlicher, verteilter Datenbestände (befördert auch durch Tool-Wildwuchs) sowie einen Mangel an KI-Know-how und vor allem an Fachkräften überhaupt. Manch ein überfordertes SOC-Team wird deshalb externe Expertise hinzuziehen müssen. Die Zusammenarbeit mit einem MDR-Anbieter, der den Wandel zum umfassend KI-gestützten SOC-Betrieb bereits durchlaufen hat, kann im Wettrennen mit KI-bewanderten Angreifern durchaus einen wichtigen Vorsprung sichern.
Christopher Fielder ist Field CTO, Dr. Sebastian Schmerl ist Vice President Security Services EMEA bei Arctic Wolf
Literatur
[1] Europol, The evolving threat landscape: how encryption, proxies and AI are expanding cybercrime, Internet Organised Crime Threat Assessment (IOCTA) 2026, April 2026, www.europol.europa.eu/publication-events/main-reports/iocta-2026-evolving-threatlandscape
[2] Arctic Wolf, 2026 Threat Report, Februar 2026, https://arcticwolf.com/resource/aw/arctic-wolfthreat-report-2026 (Registrierung erforderlich)
[3] Munich RE, Global Cyber Risk and Insurance Survey 2026, April 2026, www.munichre.com/de/insights/cyber/global-cyber-risk-and-insurance-survey-2026.html (Registrierung erforderlich)
[4] Paula Hemker, Thomas Hemker, Nützlich, aber gefährlich, Betrachtungen zum Model-Context-Protocol für den Cybersecurity-Einsatz und als Sicherheitsproblem, 2025# 6, S. 14, www.kesinformationssicherheit.de/print/titelthema-security-schulungen-wie-nachhaltiges-training-gelingt/nuetzlich-aber-gefaehrlich/ (<kes>+)