Einen Agenten für Sicherheitsuntersuchungen bauen: Tools, SIEM-Korrelation und Gedächtnis
Schritt für Schritt zum SOC-Untersuchungsagenten: Alert-Tools, Log-Korrelation im SIEM, IP-Reputationsprüfung, interner Kontext und Gesprächsgedächtnis, wobei die Analystin oder der Analyst das letzte Wort behält.
Ein Agent für Sicherheitsuntersuchungen ist nur so gut wie die Belege, an die er herankommt. Der TryHackMe-Raum zum Bau von Agenten, Schwierigkeitsgrad mittel, zeigt das, indem er Schritt für Schritt einen SOC-Assistenten für einen fiktiven Händler namens NorthStar Fashion zusammensetzt, eine Fähigkeit nach der anderen. Der Raum liegt unter tryhackme.com/room/agentbuilding, und alles Folgende dient dem Lernen und der defensiven Praxis.
Welches Problem der Agent löst
Wer einen Alert auf dem Tisch hat, muss Fakten aus vielen Quellen zusammentragen. Der Alert sagt das eine, das SIEM enthält dazugehörige Logs, eine IP-Adresse hat woanders vielleicht einen schlechten Ruf, und die Unternehmensdokumente erklären, wie der Normalzustand aussieht. Das von Hand zusammenzufügen dauert, und es wiederholt sich bei jedem Alert.
Der Agent in diesem Raum übernimmt die Laufarbeit. Er startet bei einem Sicherheits-Alert, holt die relevanten Belege, durchsucht zugehörige SIEM-Logs und prüft externen Kontext wie die IP-Reputation. Dann liest er interne Informationen der Organisation und führt alles zu einem begründeten Urteil zusammen, das ein Engineer prüft. Die Entscheidung selbst bleibt beim Menschen.
Was man lernt
Am Ende des Raums kann man:
- einen Untersuchungsagenten nach einem schriftlichen Entwurf bauen
- Tools anbinden, die Alerts abrufen und SIEM-Logs abfragen
- Belege über Konto, IP-Adresse, Gerät, Ereignistyp und Zeit miteinander verknüpfen
- externen und internen Kontext in einen Fall einbringen
- Gesprächsgedächtnis nutzen, damit Rückfragen die Untersuchung nicht neu starten
- belegbare Urteile liefern, während die Analystin oder der Analyst die letzte Entscheidung trifft
Der Laboraufbau
Die Umgebung gibt Zugriff auf ein KI-Modell über TryHackMes eigenen KI-Dienst. Ein Hilfsmodul, thm_ai.py, liegt bereits im Projekt. Es übernimmt die Kommunikation mit dem Dienst und nutzt das temporäre Token, das dem Lab zugeteilt wird. Um Modellanbieter, Zugangsdaten oder Tokens muss man sich nie selbst kümmern. Das Modul ist die einzige Schnittstelle zwischen dem Untersuchungscode und dem Modell, sodass die Logik des Agenten von der Infrastruktur dahinter getrennt bleibt.
Wie der Agent wächst
Jede Aufgabe fügt eine Fähigkeit hinzu, und am Ende kann der Agent das Schlussfolgern des Modells mit freigegebenen Aktionen, SIEM-Alerts, Log-Korrelation, IP-Reputation, Organisationskontext und Gesprächsverlauf kombinieren. Der Ablauf durch den Raum sieht so aus:
Task 3 → Define the agent behaviour and connect to the AI
Task 4 → Execute approved alert capabilities
Task 5 → Correlate alerts with SIEM logs
Task 6 → Add external and organisation context
Task 7 → Continue investigations across follow-up questions
Ein paar Details aus dem Aufbau sollte man sich merken.
Anbindung an das Modell. Zuerst kommen die Anweisungen und das Verhalten des Agenten, danach eine Methode, die eine Nachricht an den KI-Dienst schickt. Die Antwort enthält ein Feld mit dem generierten Assistenten-Text, den der Code ausliest und weitergibt.
Freigegebene Alert-Funktionen. Mit Tools kann der Agent Alerts auflisten und einen vollständigen Alert über seine ID abrufen. Die Liste unterstützt Paging, ein Query-Parameter steuert also, wie viele Alerts übersprungen werden. In diesem frühen Stadium kann der Agent einen Alert wie ALT-051 noch nicht aus dem SIEM holen, weil die Log-Suche noch fehlt.
Logs korrelieren. Der Such-Endpunkt des SIEM nimmt einen POST-Request entgegen. Bedingungen lassen sich mit logischen Operatoren verknüpfen, und AND verlangt, dass beide Bedingungen auf denselben Log-Eintrag zutreffen. Die Übung zeigt, wie das Eingrenzen funktioniert. Eine Suche nach dem Konto eines einzelnen Nutzers liefert viele Logs. Kommt die Quell-IP dazu, schrumpft die Menge, und mit dem Gerät schrumpft sie noch einmal. Jede zusätzliche Bedingung macht aus einer verrauschten Liste eine dichte, belastbare Geschichte.
Externer und organisatorischer Kontext. Zwei weitere Fähigkeiten erweitern den Blick des Agenten. check_ip_abuse prüft, ob eine Adresse bereits wegen missbräuchlicher Aktivität gemeldet wurde. search_org_details durchsucht die internen Dokumente von NorthStar Fashion, damit der Agent weiß, was bei diesem Unternehmen als normal gilt.
Gedächtnis. Als Letztes kommt der Gesprächsverlauf hinzu, den der KI-Dienst von TryHackMe speichert und den der Code über eine eigene Methode abrufen kann. Da der Dienst diesen Verlauf vorhält, braucht der Agent keinen separaten LangGraph-Checkpointer, um sich an ein Gespräch zu erinnern. Analysten können eine Rückfrage stellen, ohne die ganze Untersuchung zu wiederholen.
Der fertige Agent steckt in einer einzigen Datei, die im Verlauf des Raums Schritt für Schritt entsteht.
Warum dieses Design funktioniert
Einige Entscheidungen machen den Agenten vertrauenswürdig und nicht nur beeindruckend:
- Er nutzt nur freigegebene Fähigkeiten. Das Modell kann nicht außerhalb der Tools handeln, die man angebunden hat.
- Urteile stützen sich auf Belege, die sich auf konkrete Logs, Konten, IP-Adressen, Geräte und Zeitstempel zurückführen lassen.
- Externe Reputationsdaten und interne Dokumente liefern Kontext, den Logs allein nicht haben.
- Das Gedächtnis hält eine Untersuchung zusammen, was zählt, wenn die Analyse mehr als eine Frage braucht.
- Für die endgültige Sicherheitsentscheidung bleibt ein Mensch verantwortlich.
Diese Mischung aus Tools, Kontext, Gedächtnis und menschlicher Prüfung ist eine vernünftige Vorlage für jedes SOC-Automatisierungsprojekt, ob es im Lab geübt oder für die Produktion gebaut wird.