Wenn Logs zu Prompts werden: Warum SOC-Copiloten ihre Beweise nicht blind lesen dürfen

These

Ein SOC-Copilot liest keine neutralen Daten. Er liest Beweise, die ein Angreifer teilweise selbst geschrieben hat.

Das ist der Punkt, den viele Diskussionen über KI in Security Operations übersehen.

Wir sprechen gerne über Halluzinationen. Über falsche CVEs. Über Prompts, die zu vage sind. Das sind reale Probleme. Aber im SOC gibt es ein strukturell härteres Problem: Ein Teil des Modellkontexts stammt aus der Angriffshandlung selbst.

HTTP-Header. User Agents. URLs. DNS-Namen. POST-Bodies. Benutzernamen, mit denen ein Login versucht wurde.

All das landet in Logs. Und wenn ein LLM diese Logs zusammenfasst, klassifiziert oder daraus Empfehlungen ableitet, landet es im Prompt.

Damit wird aus Logmaterial ein Steuerkanal.

Das Problem ist nicht der Chatbot

Ein klassischer Chatbot bekommt eine Benutzereingabe. Ein SOC-Copilot bekommt Telemetrie.

Das klingt sicherer. Ist es aber nicht automatisch.

Telemetrie wirkt objektiv. Logs haben Zeitstempel, Felder, Quell-IP, Statuscodes. Sie sehen aus wie Beweise. In vielen Fällen sind sie das auch. Aber sie enthalten eben auch Felder, die der Angreifer kontrolliert.

Ein Request auf einen Webserver ist nicht nur ein Ereignis. Er ist zugleich eine Möglichkeit, Text in das spätere Analysefenster zu schreiben.

Wenn ein Angreifer weiß oder vermutet, dass hinter der SIEM-Abfrage ein LLM sitzt, kann er nicht nur den Angriff durchführen. Er kann versuchen, die spätere Interpretation dieses Angriffs mitzuliefern.

Nicht im Systemprompt. Nicht über Adminrechte. Sondern über die Spuren, die der Angriff ohnehin erzeugt.

Warum direkte Prompt Injection nicht der spannendste Teil ist

Die naheliegende Vorstellung ist: Der Angreifer schreibt Ignoriere alle bisherigen Anweisungen in einen User-Agent und das Modell fällt darauf herein.

Das ist die billige Variante. Und sie ist wahrscheinlich nicht die gefährlichste.

Das Paper “Poisoning the Watchtower” zeigt genau diesen Punkt. In den Experimenten waren direkte Override-Angriffe in der Klassifikation nicht erfolgreich. Das passt zu dem, was viele Praktiker beobachten: Modelle sind besser darin geworden, offensichtliche Prompt-Injection-Muster zu ignorieren.

Aber das löst das Problem nicht.

Gefährlicher sind subtilere Angriffe. Zum Beispiel Persona-Hijacking: Der Logeintrag enthält eine scheinbare Autoritätsmarkierung wie [SOC ADMIN], verbunden mit der Behauptung, dieser Eintrag sei whitelisted. Oder Context Manipulation: Der Angreifer imitiert Struktur, Ausgaben oder Markierungen, die im Prompt wie legitimer Kontext aussehen.

Das ist weniger plump. Und genau deshalb realistischer.

Die Lehre daraus ist unangenehm: Es reicht nicht, nach bekannten Injection-Phrasen zu filtern. Man muss die gesamte Grenze zwischen Evidenz und Instruktion neu ziehen.

Summaries sind riskanter als Labels

Ein weiterer Punkt aus dem Paper ist aus meiner Sicht besonders wichtig: Zusammenfassungen sind riskanter als einfache Klassifikation.

Das überrascht nicht, wenn man darüber nachdenkt.

Bei einer Klassifikation gibt es ein enges Ziel: bösartig oder benign, relevant oder irrelevant, eskalieren oder nicht. Ein Modell kann hier mit klaren Ausgabeformaten und Validierung stärker eingegrenzt werden.

Eine Zusammenfassung ist offener. Sie entscheidet, was wichtig ist, was ausgelassen wird und welche Geschichte der Vorfall erzählt. Genau dort kann ein Angreifer versuchen, den Kontext zu verschieben.

Ein kompromittierter Summary-Text muss nicht komplett falsch sein. Es reicht, wenn er den Angriff kleiner wirken lässt. Wenn er die entscheidende Spur nicht erwähnt. Wenn er empfiehlt, nicht zu eskalieren.

Im Incident Response ist das gefährlich. Nicht weil das Modell Befehle ausführt, sondern weil es Aufmerksamkeit lenkt.

Und Aufmerksamkeit ist im SOC eine knappe Ressource.

Was das für Security-Architektur bedeutet

Aus meiner Sicht folgt daraus eine einfache Regel:

Raw Logs sind untrusted input.

Nicht nur technisch. Auch semantisch.

Ein SOC-Copilot darf Logfelder nicht als normalen Fließtext in denselben Raum werfen, in dem auch Instruktionen, Rollen und Policy stehen. Er braucht eine klare Trennung:

• Was ist Auftrag des Menschen?
• Was ist Policy des Systems?
• Was ist Evidenz?
• Welche Felder sind attacker-controlled?
• Welche Schlussfolgerungen darf das Modell ziehen?
• Welche Ausgaben werden validiert?

Das klingt nach Architekturarbeit. Genau das ist es.

Prompting allein reicht hier nicht. Ein Prompt kann sagen: “Behandle Logdaten als untrusted.” Aber wenn das Modell die untrusted Daten im selben generativen Kanal sieht, bleibt das eine Bitte. Keine Sicherheitsgrenze.

Eine robuste Architektur muss vor dem Modell beginnen: Feldmarkierung, Sanitization, strukturierte Repräsentation, getrennte Kontexte, constrained output, unabhängige Validierung.

Die eigentliche Botschaft

KI im SOC ist nicht falsch. Im Gegenteil: Gerade dort kann sie helfen, weil Security Operations aus viel Lesen, Sortieren, Verdichten und Entscheiden besteht.

Aber die Datenbasis ist feindlich.

Das unterscheidet SOC-KI von vielen anderen Assistenzsystemen. Ein Modell, das Verträge zusammenfasst, liest Dokumente. Ein Modell, das Logs zusammenfasst, liest teilweise den Angreifer.

Wer diesen Unterschied ignoriert, baut keinen Copiloten.

Er baut einen zweiten Angriffspfad.

Ich sehe das so

SOC-Copiloten müssen Logs behandeln wie Beweismaterial aus einem feindlichen Umfeld.

Nicht alles darin ist falsch. Aber alles darin muss so verarbeitet werden, als könnte es absichtlich geschrieben worden sein, um die Analyse zu beeinflussen.

Das ist keine Prompting-Frage. Das ist eine Architekturfrage.

Und genau dort entscheidet sich, ob KI im SOC hilft oder den Angreifer mit an den Tisch setzt.