Before You Hand Over the Wheel: Evaluating LLMs for Security Incident Analysis

Die Arbeit stellt SIABENCH vor, ein agentic Evaluierungsframework mit einem neuartigen Datensatz und einem autonomen Agenten, das die Leistung von 11 großen Sprachmodellen bei der Sicherheitsvorfallanalyse umfassend bewertet und so die Lücke in der rigorosen Benchmarking für diesen Bereich schließt.

Das Wesentliche

Titel: Bevor Sie das Lenkrad übergeben: Ein Test für KI im Sicherheitsbereich

Stellen Sie sich vor, ein Sicherheitszentrum (ein sogenanntes SOC) ist wie eine riesige, chaotische Kontrollstation in einem modernen Flughafen. Tausende von Alarmen leuchten auf den Bildschirmen auf. Manche bedeuten, dass jemand versucht, die Tür aufzubrechen (echte Bedrohungen), aber die meisten sind nur falsche Alarme – vielleicht hat jemand versehentlich die falsche Taste gedrückt oder ein Vogel hat gegen das Fenster geklopft.

Die menschlichen Sicherheitsanalysten, die hier arbeiten, sind wie erfahrene Detektive. Doch sie sind überlastet. Sie müssen riesige Datenberge durchsuchen, komplexe Werkzeuge bedienen und in Sekundenschnelle entscheiden, was echt ist und was nicht. Oft sind sie so müde von den falschen Alarmen, dass sie echte Gefahren übersehen.

Deshalb denken viele Firmen: „Warum setzen wir nicht Künstliche Intelligenz (KI) ein? Vielleicht kann ein super-smarter KI-Assistent uns helfen?"

Aber hier kommt das Problem: Man kann einem Piloten nicht einfach das Steuer übergeben, ohne vorher zu wissen, ob er fliegen kann. Wenn die KI falsch liegt, könnte sie die Sicherheit verschlechtern statt verbessern. Bisher gab es aber keinen „Flugsimulator" oder einen standardisierten Test, um zu prüfen, wie gut diese KIs wirklich sind.

Was haben die Forscher gemacht?

Die Autoren dieses Papers haben genau diesen Simulator gebaut. Sie nennen ihr Projekt SIABENCH. Man kann es sich wie einen riesigen, digitalen „Fahrschul-Parcours" für KI vorstellen, der speziell für Sicherheitsfälle entwickelt wurde.

Hier ist, was sie getan haben, einfach erklärt:

1. Der Prüfungsplan (Der Datensatz)
Statt nur ein paar einfache Fragen zu stellen, haben sie zwei Arten von Prüfungen erstellt:

• Der „Detektiv-Test" (25 Szenarien): Hier müssen die KIs komplexe Fälle lösen. Stellen Sie sich vor, ein Hacker hat das Netzwerk infiltriert. Die KI muss wie ein Sherlock Holmes Beweise sammeln: Woher kam der Hacker? Welche Dateien wurden gestohlen? Wie hat er sich versteckt? Das erfordert viele Schritte und das Benutzen von speziellen Werkzeugen (wie digitale Lupe für Computer-Speicher oder Netzwerk-Daten).
• Der „Wächter-Test" (135 Szenarien): Hier geht es darum, Alarme zu sortieren. Die KI bekommt eine Liste von Alarmen und muss sagen: „Das ist ein echter Einbrecher" oder „Das ist nur ein Vogel gegen das Fenster".

2. Der KI-Agent (Der Schüler)
Die Forscher haben eine KI-Agenten-Software gebaut. Diese KI ist nicht nur ein Chatbot, der redet. Sie ist wie ein digitaler Praktikant, der tatsächlich arbeiten kann.

• Sie kann Befehle in einem Computer eingeben.
• Sie kann Dateien öffnen und analysieren.
• Sie kann Fehler machen, daraus lernen und einen neuen Plan schmieden.
• Sie muss sich selbstständig durch den Fall arbeiten, genau wie ein menschlicher Analyst.

3. Die große Prüfung (Das Benchmarking)
Sie haben 11 verschiedene KI-Modelle (die bekanntesten und mächtigsten der Welt, wie GPT-5, Claude, Llama etc.) durch diesen Parcours geschickt. Sie wollten sehen: Wer besteht die Prüfung? Wer scheitert? Und wo liegen die Schwachstellen?

Was haben sie herausgefunden?

Die Ergebnisse sind eine Mischung aus „Gut gemacht" und „Noch viel zu tun":

• Die Spitze ist stark: Die neuesten und stärksten KIs (wie Claude 4.5 und GPT-5) sind bereits sehr gut darin, einfache bis mittlere Fälle zu lösen. Sie können oft erkennen, ob ein Alarm echt ist oder falsch.
• Der „Junior-Analyst"-Effekt: Die KIs wurden getestet, als ob sie „Junior-Analysten" wären. In einfachen Fällen schneiden sie gut ab. Aber sobald die Fälle sehr komplex werden (z. B. wenn der Hacker seine Spuren verwischt hat oder verschlüsselte Daten nutzt), stolpern viele KIs.
• Die häufigen Fehler:
  • Halluzinationen: Die KI erfindet Beweise, die gar nicht existieren (wie ein Detektiv, der sich einen Täter ausdenkt, weil er keine Beweise findet).
  • Infinite Loops: Die KI steckt in einer Schleife fest und wiederholt immer wieder den gleichen falschen Befehl, ohne weiterzukommen.
  • Oberflächlichkeit: Sie schaut nur auf offensichtliche Wörter und ignoriert die tiefere Bedeutung.
• Der Unterschied zwischen „Reden" und „Tun": Die Studie zeigte, dass KIs, die erst nachdenken (Planung) und dann handeln (Befehle ausführen), viel besser sind als solche, die einfach nur drauflos tippen.

Warum ist das wichtig?

Dieses Papier ist wie ein Verbrauchertest für KI-Sicherheitswerkzeuge.

• Für Sicherheitsfirmen: Es zeigt, welche KIs man kaufen sollte und welche noch nicht bereit sind, das Lenkrad zu übernehmen. Es warnt davor, blindlings auf KI zu vertrauen.
• Für die Zukunft: Es hilft dabei, die KIs besser zu trainieren. Wenn wir wissen, wo sie scheitern (z. B. bei verschlüsselten Dateien), können wir sie genau dort verbessern.

Fazit:
KI ist ein mächtiger Assistent, der den Sicherheitsleuten helfen kann, den Überblick zu behalten. Aber wie bei einem Fahrschüler darf man ihm das Steuer noch nicht allein überlassen. Er braucht noch viel Übung, und wir brauchen klare Tests wie SIABENCH, um sicherzustellen, dass er nicht in den Graben fährt, bevor er auf die Autobahn darf.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Before You Hand Over the Wheel: Evaluating LLMs for Security Incident Analysis" auf Deutsch:

1. Problemstellung

Die Analyse von Sicherheitsvorfällen (Security Incident Analysis – SIA) stellt Security Operations Centers (SOCs) vor enorme Herausforderungen. Analysten müssen mit einer überwältigenden Flut an Alarmen, heterogenen Datenquellen und komplexen Toolchains umgehen, oft bei begrenzter personeller Expertise.

• Herausforderungen: Vorfälle entwickeln sich dynamisch und erfordern mehrstufiges, vielschichtiges reasoning (Schlussfolgern).
• Risiko bei LLM-Einführung: Obwohl Organisationen zunehmend Large Language Models (LLMs) zur Unterstützung einsetzen wollen, fehlt es an rigorosen Benchmarks. Ein vorschneller Einsatz könnte die Sicherheit verschlechtern, wenn die Modelle ineffektiv sind oder falsche Schlüsse ziehen.
• Forschungslücke: Es existieren keine standardisierten, LLM-fähigen Datensätze, die das breite Spektrum von SIA-Aufgaben abdecken, und keine etablierten Best Practices für die Bewertung, da SIA im Gegensatz zu CTF-Wettbewerben (Capture The Flag) multiple Ziele und iterative Workflows umfasst.

2. Methodik: SIABENCH Framework

Die Autoren stellen SIABENCH vor, ein agentic (agentenbasiertes) Evaluierungsframework, das aus drei Hauptkomponenten besteht:

A. Der Datensatz (SIABENCH Dataset)

Der Datensatz wurde in enger Zusammenarbeit mit SOC-Experten entwickelt und besteht aus zwei Teilen:

1. Security Incident Analysis (SIA) Tasks (25 Szenarien, 229 Fragen):
   • Simuliert tiefe investigative Workflows (z. B. Ransomware-Angriffe, Phishing, Server-Kompromittierung).
   • Abdeckung von Domänen: Netzwerk-Forensik, Speicher-Forensik, Malware-Analyse (Binär, Code, PDF), Phishing-Analyse und Log-Analyse.
   • Schwierigkeitsgrade: Einfach, Mittel, Schwer.
   • Datenvorverarbeitung: Um „Data Contamination" (das Auswendiglernen von Trainingsdaten) zu vermeiden, wurden Szenarien paraphrasiert, Identifikatoren (Namen, IPs) neutralisiert und Fragen so umformuliert, dass sie keine Annahmen enthalten (z. B. statt „Welche IP hat gescannt?" wird gefragt „Gibt es Hinweise auf Scanning?").
2. Alert-Triage-Tasks (135 Szenarien):
   • Fokus auf die Unterscheidung zwischen True Positives (echte Bedrohungen) und False Positives (falsche Alarme).
   • Basierend auf benignem und bösartigem Netzwerkverkehr (PCAP-Dateien), generiert mit IDS-Tools wie Snort und Suricata.

B. Der SIA-Agent

Ein autonomer Agent, der LLMs als „Gehirn" nutzt, um die Aufgaben auszuführen.

• Architektur: Der Agent durchläuft einen mehrstufigen Workflow (Multi-State Workflow):
  1. Init: Eingabe von Szenario, Artefakten und Fragen.
  2. Incident Analysis (ReAct-Framework): Der Agent plant (Reasoning), führt Aktionen aus (Tool-Execution) und beobachtet Ergebnisse.
  3. Summarizer: Um Kontextgrenzen zu überwinden, fasst der Agent lange Log-Ausgaben in „Key Security Insights" (KSI) zusammen, bevor er zum nächsten Schritt übergeht.
  4. Solved: Speicherung des Ergebnisses und Wechsel zur nächsten Frage.
• Fähigkeiten: Der Agent kann CLI-Tools (wie tshark, Volatility, Oledump) ausführen, Artefakte analysieren und bei Bedarf neue Tools installieren.

C. Evaluierung

Es wurden 11 führende LLMs evaluiert (4 Open-Weight, 7 Closed-Weight), darunter Claude-4.5-Sonnet, GPT-5, GPT-4o, Llama-3.1-Familie und DeepSeek-Reasoner. Die Bewertung erfolgte unter deterministischen Bedingungen (Temperature = 0).

3. Wichtige Ergebnisse

Leistung auf SIA-Aufgaben (RQ1 & RQ2)

• Gesamtleistung: Selbst die besten Modelle lösen nur einen kleinen Teil der Szenarien vollständig. Claude-4.5-Sonnet und GPT-5 führen mit ca. 80% Partially Solved (PS) und 8/25 bzw. 5/25 vollständig gelösten Szenarien. Kleinere Modelle (z. B. Llama-3.1-8B) scheitern fast vollständig.
• Taktik-Level: Modelle performen gut bei Reconnaissance (Aufklärung, 100% bei Claude-4.5) und Exfiltration. Sie haben jedoch große Schwierigkeiten bei Defense Evasion (Tarnung/Obfuskation) und komplexer Execution-Analyse, wo oft Reverse-Engineering-Fähigkeiten nötig sind.
• Live-Tests: Die Ergebnisse auf neuen, nach dem Trainings-Cutoff veröffentlichten Aufgaben bestätigten die Benchmark-Ergebnisse, was auf geringe Datenkontamination hindeutet.

Fehleranalyse (RQ3)

Die Hauptfehlerursachen sind:

1. Falsche Befehle: Syntaxfehler bei Tool-Nutzung.
2. Endlosschleifen: Modelle wiederholen denselben Befehl ohne Fortschritt (besonders bei Llama-Modellen).
3. Halluzinationen: Erfinden von Beweisen ohne Datenbasis.
4. Oberflächliche Analyse: Verlassen sich auf offensichtliche Schlüsselwörter statt tiefer Untersuchung.
5. Abhängigkeit: Ein Fehler in einer frühen Frage führt zum Scheitern aller abhängigen Analysen.

Konsistenz und Ablationsstudie (RQ4 & RQ6)

• Multi-State vs. Single-State: Der mehrstufige Workflow (Fragen nacheinander bearbeiten) führt zu signifikant besseren Ergebnissen als das gleichzeitige Beantworten aller Fragen.
• Summarizer: Das Zusammenfassen von Log-Daten ist entscheidend, um Kontextgrenzen (Context Limitation Errors) zu vermeiden und die Leistung um bis zu 32% zu steigern.
• ReAct vs. Act-Only: Das „Reasoning before Acting" (ReAct) ist für ältere Modelle essenziell; neuere Modelle (wie GPT-5) können dies teilweise intrinsisch, profitieren aber dennoch von der Struktur.

Alert Triaging (RQ7)

• Bei der Unterscheidung von True/False Positives zeigen Top-Modelle (GPT-5, Claude-4.5) eine sehr hohe Genauigkeit (bis zu 98% bei GPT-5).
• GPT-5 erkannte 100% der False Positives korrekt, was für die Entlastung von Analysten (Alert Fatigue) entscheidend ist.

4. Schlüsselbeiträge

1. Erster SIA-Benchmark-Datensatz: Ein umfassender, debiasierter Datensatz mit 25 tiefen Untersuchungsszenarien und 135 Alert-Triage-Szenarien, der reale SOC-Arbeitsabläufe abbildet.
2. Automatisierter SIA-Agent: Ein Framework, das LLMs autonom mit Sicherheitstools interagieren lässt und komplexe, mehrstufige Untersuchungen durchführt.
3. Umfassende Evaluierung: Die erste systematische Bewertung von 11 LLMs in diesem Kontext, die zeigt, dass zwar Fortschritte bestehen, aber noch erhebliche Lücken in der Zuverlässigkeit und beim Umgang mit komplexen Tarnungen bestehen.

5. Bedeutung und Ausblick

Das Paper warnt davor, LLMs blind in SOC-Workflows zu integrieren („Before You Hand Over the Wheel"). Es liefert SOC-Teams und Forschern:

• Eine fundierte Basis für die Auswahl von Modellen (z. B. GPT-5 oder Claude-4.5 für komplexe Aufgaben).
• Ein Verständnis der aktuellen Grenzen (z. B. bei Obfuskation und Halluzinationen).
• Ein Werkzeug (SIABENCH), um zukünftige Modelle und Agenten-Architekturen kontinuierlich zu evaluieren.

Die Studie unterstreicht, dass LLMs derzeit eher als Assistenzsysteme für Junior-Analysten geeignet sind, um Routineaufgaben zu automatisieren, während die endgültige Verantwortung und komplexe Entscheidungsfindung weiterhin menschlicher Expertise bedürfen.