Nach einem Vorfall stellt sich jeder Incident-Response- und Security-Operations-Bereich dieselbe unbequeme Frage: Was haben wir übersehen, und warum? Eine gründliche Antwort erfordert echte Arbeit – jemand muss die Incident-Timeline durcharbeiten, die Angreiferaktionen auf Erkennungsmöglichkeiten mappen, die Alarme identifizieren, die hätten ausgelöst werden sollen, und diese Erkenntnisse in konkrete Verbesserungen übersetzen. Manuell durchgeführt ist das zeitaufwändig, inkonsistent und leicht zu deprioritisieren, wenn der nächste Vorfall bereits vor der Tür steht.
Das Signals Engineering Team bei GitLab ist verantwortlich für den Aufbau und die Pflege der Erkennungsregeln, die die Plattform und das Unternehmen schützen. Wir kennen das Detection-Gap-Problem aus eigener Erfahrung und haben die Gap-Analyse mit dem GitLab Duo Agent Platform automatisiert, um unsere Bewertung dieser Lücken und deren Schließung zu verbessern.
In diesem Artikel beschreiben wir unseren Ansatz – mit zwei KI-Agenten, die sich in der eigenen Umgebung einsetzen lassen: dem integrierten Security Analyst Agent und einem selbst entwickelten Agent namens Detection Engineering Assistant.
Das Detection-Gap-Problem
Eine Detection Gap ist genau das, was der Name vermuten lässt: Ein Angreifer hat eine Aktion durchgeführt, und die eigenen Erkennungsregeln haben sie nicht erfasst. Gap-Analyse ist der Prozess, bei dem Sicherheitsvorfälle systematisch ausgewertet werden, um diese verpassten Erkennungsmöglichkeiten zu identifizieren und festzulegen, welche neuen oder verbesserten Regeln die Lücken schließen würden.
Die Herausforderung liegt nicht im konzeptionellen Verständnis. Sie liegt darin, dass die Analyse ein sorgfältiges, methodisches Durcharbeiten von Incident-Daten erfordert und die Ereignisse mit der eigenen Erkennungsabdeckung abgeglichen werden müssen. Bei einem einzelnen Vorfall gelingt das einer erfahrenen Analystin oder einem erfahrenen Analysten gut. Über einen kontinuierlichen Strom von Vorfällen hinweg, mit mehreren beteiligten Engineers, ist Konsistenz schwer aufrechtzuerhalten – die Auswertung wird leicht oberflächlich.
Ziel war ein Prozess, der reproduzierbar, gründlich und direkt in dem Workflow verankert ist, in dem Sicherheitsvorfälle bereits dokumentiert werden: GitLab Issues.
Was ist GitLab Duo Agent Platform?
GitLab Duo Agent Platform ist GitLabs Framework zum Aufbau und Betrieb von KI-Agenten, die eigenständig planen, Aktionen ausführen und nativ mit GitLab-Ressourcen wie Issues, Merge Requests und Code interagieren. Anders als ein einfaches Chat-Interface lassen sich Agenten in Duo Agent Platform mit spezifischen Rollen, Domänenwissen und Werkzeugzugang ausstatten – und sind dadurch für domänenspezifische Workflows wie Security Operations geeignet.
Duo Agent Platform bietet zwei Wege:
- Vordefinierten Agent nutzen – GitLab liefert mehrere fertig konfigurierte Agenten aus, darunter einen Security Analyst Agent für sicherheitsbezogene Aufgaben.
- Eigenen Agent entwickeln – Ein benutzerdefinierter Agent lässt sich in wenigen Minuten erstellen: Name, Beschreibung und System-Prompt genügen. Der System-Prompt ist dabei das eigentliche Herzstück.
Beide Wege sind für die Detection-Gap-Analyse geeignet.
1. Security Analyst Agent
Der einfachste Einstieg ist der Security Analyst Agent, der mit Sicherheits-Domänenwissen vorkonfiguriert ist und direkt aus einem GitLab Issue aufgerufen werden kann.
Für die Gap-Analyse navigieren wir zu einem abgeschlossenen Incident-Issue und bitten den Agent, Beschreibung, Timeline, Aufgaben und Kommentare auf fehlende oder unzureichende Erkennungsregeln zu prüfen. Der Agent liest den gesamten Issue-Inhalt – einschließlich Kommentare, verknüpfte Artefakte und Timeline-Details – und leitet daraus potenzielle Lücken ab. Er kann nicht erkannte Taktiken, Techniken und Vorgehensweisen (TTPs) auf MITRE ATT&CK mappen und Bereiche vorschlagen, in denen neue Erkennungsregeln die Abdeckung verbessern würden.
Das eignet sich gut für einen ersten Durchgang, insbesondere wenn Incident-Issues gut dokumentiert sind. Der Security Analyst Agent verfügt über Wissen zu allgemeinen Sicherheitskonzepten, typischen Angreiferverhalten und Erkennungsprinzipien. Für Teams, die mit KI-gestütztem Betrieb beginnen, bietet er sofortigen Mehrwert ohne Konfigurationsaufwand.
Allerdings kennt der vordefinierte Agent die spezifische Umgebung nicht – das eigene SIEM, die Log-Quellen, den Detection Stack oder die teameigenen Detection-Engineering-Standards. Die Empfehlungen sind zwar fachlich korrekt, treffen aber manchmal nicht den konkreten Kontext, der für umsetzbare Erkennungsregeln erforderlich ist. Das war der Ausgangspunkt für die Entwicklung eines eigenen Agents.
2. Den Detection Engineering Assistant entwickeln
Einen benutzerdefinierten Agent in GitLab Duo Agent Platform zu erstellen ist unkompliziert. Im Duo Agent Platform Interface wird dem Agent ein Name gegeben (bei uns: Detection Engineering Assistant), eine kurze Beschreibung und ein System-Prompt. Damit ist der Agent einsatzbereit.
Der System-Prompt ist der entscheidende Teil. Er ist die Wissensbasis des Agents: alles, was er über das Team, die Umgebung, die Standards und die eigene Arbeitsweise wissen soll. Ein dünner, vager System-Prompt liefert dünne, vage Ergebnisse. Ein ausführlicher, sorgfältig ausgearbeiteter System-Prompt erzeugt einen Agent, der sich wie ein fachkundiges Teammitglied verhält.
So sind wir beim Schreiben des System-Prompts für den Detection Engineering Assistant vorgegangen:
Rolle und Aufgabenbereich klar definieren
Der System-Prompt beginnt damit, dem Agent genau mitzuteilen, was er ist und wofür er verantwortlich ist – nicht nur „du bist ein Security Analyst", sondern konkret: „Du bist der Detection Engineering Assistant für GitLabs Signals Engineering Team, verantwortlich für die Analyse von Sicherheitsvorfällen und die Identifizierung von Lücken in unserer Erkennungsabdeckung." Diese Rahmung verankert jede Antwort des Agents.
Erkennungsphilosophie kodieren
Wir haben festgehalten, was für uns eine gute Erkennung ausmacht: niedrige False-Positive-Rate, hohe Signalqualität und umsetzbare Alarme, die Responders den notwendigen Kontext liefern. Außerdem haben wir unsere Präferenz für verhaltensbasierte Erkennungen gegenüber IOC-basierten Erkennungen beschrieben und wie wir den Zielkonflikt zwischen Abdeckungsbreite und Alert-Fatigue abwägen.
Tech-Stack und Log-Quellen als Kontext mitgeben
Ein Agent kann nur empfehlen, was tatsächlich umsetzbar ist. Wir haben dem Agent mitgeteilt, welche Log-Quellen wir erfassen, wie unser SIEM aufgebaut ist und welche Daten verfügbar sind. Damit empfiehlt er neue Erkennungsregeln in Bezug auf das, was wir tatsächlich implementieren können – nicht auf Basis hypothetischer Telemetrie.
In MITRE ATT&CK verankern
Der Agent wurde angewiesen, Gap-Findings anhand von ATT&CK-Taktiken und -Techniken zu strukturieren. Das liefert konsistente, strukturierte Ausgaben, die direkt auf unser internes Coverage-Tracking mappen und die Priorisierung der zu schließenden Lücken vereinfachen.
Ausgabeformat festlegen
Wir haben genau vorgegeben, was der Agent produzieren soll: eine strukturierte Liste von Detection Gaps, jeweils mit der relevanten ATT&CK-Technik, einer Beschreibung des Versäumten, der Log-Quelle oder den Daten, die eine Erkennung ermöglichen würden, sowie einem empfohlenen Ansatz. Ein einheitliches Ausgabeformat erleichtert die Triage und die Überführung in Engineering-Aufgaben.
Beispiel-System-Prompt
Hinweis: Unser vollständiger System-Prompt für den Detection Engineering Assistant umfasst 1.870 Wörter und 337 Zeilen. Das folgende Beispiel zeigt nur einen kleinen Ausschnitt.
Du bist der Detection Engineering Assistant für GitLabs Security Operations Team. Deine Aufgabe: abgeschlossene Incidents analysieren und Lücken in unserer Detection-Coverage identifizieren.
Beim Review eines Incidents:
1. Identifiziere jede Angreifer-Aktion oder -Technik aus der Incident-Timeline
2. Bewerte für jede Aktion, ob unsere bestehenden Detections sie erfasst hätten
3. Dokumentiere nicht erkannte Aktionen als Detection Gap
Für jeden Gap:
- MITRE ATT&CK Technique ID und Name (z. B. T1078 – Valid Accounts)
- Kurze Beschreibung: was passierte, warum nicht erkannt
- Log-Quelle oder Telemetrie, die einen Detection-Ansatz ermöglichen würde (z. B. Auth-Logs, Process-Execution-Events, Netzwerkflüsse)
- Empfohlener Detection-Ansatz, umsetzbar in unserem SIEM
Unser SIEM erfasst [Log-Quellen]. Wir bevorzugen verhaltensbasierte Detections gegenüber statischen IOCs. Keine Empfehlungen, die ohne soliden Tuning-Pfad zu erheblichen False Positives führen...
Ein so spezifischer System-Prompt liefert deutlich nützlichere Ergebnisse als ein generischer. Der Agent gibt keine allgemeinen Sicherheitsempfehlungen mehr, sondern konkrete Detection-Engineering-Empfehlungen.
Gap-Analyse an Vorfällen durchführen
Mit dem konfigurierten Detection Engineering Assistant ist der Workflow unkompliziert. Nach Abschluss eines Vorfalls wird der Assistant aus dem Incident-Issue in GitLab aufgerufen. Er liest den gesamten Issue – Zusammenfassung, Timeline, Ermittlungsnotizen und verknüpfte Ressourcen – und gibt eine strukturierte Gap-Analyse zurück.
Eine typische Ausgabe sieht so aus:
Gap: Laterale Bewegung über gültige Credentials nicht erkannt
- ATT&CK: T1078.004 – Valid Accounts: Cloud Accounts
- Was passierte: Ein Angreifer verwendete ein gültiges Access Token, um sich bei einer zusätzlichen GitLab-Instanz zu authentifizieren. Kein Alarm wurde ausgelöst, da Authentifizierungs-Baseline-Erkennungen für diese Instanz fehlten.
- Log-Quelle: Authentifizierungslogs von
example.gitlab.com - Empfohlener Ansatz: Erkennung erstellen, die bei erstmaliger Authentifizierung eines Nutzerkontos bei
example.gitlab.cominnerhalb eines 90-Tage-Rollfensters auslöst, mit Unterdrückung für Konten mit etablierten Zugriffsmustern.
Diese Art strukturierter Ausgabe fließt direkt in den Engineering-Backlog. Der Agent liefert einen hochwertigen ersten Entwurf – ein Engineer prüft die Findings, verifiziert, ob Lücken bereits durch undokumentierte Erkennungsregeln abgedeckt sind, und ergänzt Kontext, bevor daraus ein Engineering-Issue wird. Die aufwändige Arbeit des Durchlesens und der initialen Analyse ist automatisiert.
Was wir gelernt haben
Drei Erkenntnisse aus dem Aufbau und der Weiterentwicklung dieses Workflows:
Der System-Prompt ist ein lebendes Dokument – Jedes Mal, wenn der Agent eine offensichtliche Lücke übersieht oder das Framing nicht stimmt, wird der Prompt aktualisiert. Die Qualität des Agents spiegelt direkt wider, wie gut das Domänenwissen darin kodiert ist.
Die Qualität der Incident-Dokumentation ist entscheidend – Ein Agent kann nur über das urteilen, was aufgeschrieben ist. Vorfälle mit detaillierten, strukturierten Timelines liefern deutlich bessere Gap-Analysen als knappe oder informelle Dokumentationen. Der Aufbau des Gap-Analyse-Workflows hatte einen unerwarteten Nebeneffekt: Er gab uns einen konkreten Grund, unsere Dokumentationsstandards für Vorfälle zu verbessern.
Das ist ein Kraftmultiplikator, kein Ersatz – Der Detection Engineering Assistant ersetzt keine erfahrene Detection Engineerin und keinen erfahrenen Detection Engineer, verstärkt deren Wirkung jedoch. Der Mensch prüft die Findings, bewertet die Empfehlungen und trifft die finale Entscheidung darüber, was in den Backlog kommt. Der Aufwand für die initiale Analyse sinkt dabei deutlich, und die Konsistenz über Vorfälle hinweg steigt.
Einstieg
Wer einen eigenen Detection-Gap-Analyse-Agenten entwickeln möchte:
- Die letzten drei bis fünf abgeschlossenen Vorfälle durchsehen und festhalten, was eine gründliche Gap-Analyse jeweils zutage gefördert hätte.
- Aus diesen Beobachtungen einen System-Prompt entwickeln, der die eigene Umgebung, Standards und das gewünschte Ausgabeformat kodiert.
- Einen benutzerdefinierten Agent in GitLab Duo Agent Platform mit diesem Prompt erstellen.
- Den Agent gegen einen der Vorfälle laufen lassen und den Prompt auf Basis der Ausgabe iterieren.
Das Detection-Gap-Problem besteht weiterhin. Mit GitLab Duo Agent Platform lässt sich die Analyse jedoch reproduzierbar und konsistent gestalten – direkt dort, wo die Security-Arbeit bereits stattfindet.
