GUARD-Framework für automatisierte Security-Detections

GitLab Security Operations nutzt Automatisierung als zentrales Prinzip, damit Security-Engineers Zeit für wesentliche Aufgaben haben – nicht für standardisierbare manuelle Tätigkeiten, die automatisiert werden können. Dieses Prinzip wurde auf die Absicherung der GitLab.com-SaaS-Plattform angewendet, die täglich Terabytes an Log-Daten generiert. Das GitLab-Security-Team musste Security-Workflows standardisieren, automatisieren und skalieren, um Schutz und Effizienz zu verbessern. Das Ergebnis: Ein neues Framework namens GitLab Universal Automated Detection and Response (GUARD) – eine Kollaboration zwischen dem Security Incident Response Team (SIRT) und dem Signals Engineering Team.

Für deutsche Unternehmen ist dieser systematische Ansatz besonders relevant: Die Automatisierung von Security-Detections unterstützt Compliance-Anforderungen wie ISO 27001 (technisches Schwachstellenmanagement nach A.12.6.1), DSGVO Artikel 32 (angemessene technische Maßnahmen) und BSI Grundschutz OPS.1.1.5 (Protokollierung und Monitoring). Die vollständige Versionierung aller Detection-Änderungen durch das Framework schafft einen lückenlosen Audit-Trail für Compliance-Nachweise. In der deutschen SIEM-Landschaft nutzen Unternehmen primär Plattformen wie Splunk, Elastic SIEM oder IBM QRadar – GUARD abstrahiert Detection-Logik vom jeweiligen SIEM-System, wodurch Herstellerunabhängigkeit gewährleistet wird.

GUARD deckt alle Aspekte der Security-Detection ab, darunter:

• Erstellung
• Wartung
• Alert-Routing und -Handling
• Metriken-Erfassung
• Workflow für Alert-Closure oder Incident-Eskalation

Die Ziele von GUARD

GUARD wurde mit einer Reihe zentraler Ziele entwickelt und konzipiert:

1. Standardisierung der Detection- und Alerting-Pipeline von SIRT zur Produktion qualitativ hochwertiger Detections mit Fokus auf Peer-Reviews und Automatisierung
2. Reduktion von Alert-Fatigue durch Alert-Konsolidierung, Deduplizierung, Risk-Scoring und automatisiertes Feedback
3. Metriken zur Messung der Response-Effizienz und frühzeitigen Identifikation von Problemen
4. GitLab als Kern durch Nutzung von GitLab als Single Source of Truth für Detection-Definitionen

Die Design-Prinzipien von GUARD

GUARD entstand aus operativer Notwendigkeit mit klarer Zielvorstellung. Vor GUARD folgten Detections keinem Standardformat, Alert-Metriken waren nicht verfügbar, Detection-Erstellung und -Wartung erfolgten ad-hoc. Ein skalierbares, GitLab-zentriertes Framework mit Automatisierung manueller Aufgaben war zentral für den Erfolg von GUARD. Durch die realisierten Zeiteffizienzgewinne haben SecOps-Engineers mehr Kapazität für komplexe Probleme und anspruchsvolle Incidents.

GUARD-Komponenten

Das GUARD-Framework besteht aus mehreren Modulen. Im Zentrum steht die GitLab-Plattform selbst – sie fungiert als Single Source of Truth für Detection-Rules und ermöglicht SIRT das automatische Deployment von Detections as Code mittels GitLab CI/CD.

GUARD umfasst folgende Komponenten:

• Detection as Code (DaC) - Deployed Detections durch die GitLab-CI/CD-Pipeline.
• User Attestation Module - Ermöglicht GitLab-Teammitgliedern, zu potenziell bösartigen Aktivitäten Stellung zu nehmen.
• Enrichments - Abfrage historischer und kontextueller Informationen zur Alert-Anreicherung für einfachere Triage.
• Alert Triage and Response - Bereitstellung eines standardisierten Formats für Alert-Triage und vordefinierter Eskalationsaktionen.
• Metrics Generation - Erfassung von Insights zum Alert-Handling.

Jedes GUARD-Modul arbeitet zusammen, um GitLabs Security-Detections und Alert-Pipeline zu standardisieren, automatisieren und iterativ zu verbessern.

GitLab als Kern

GitLab ist zentral für kritische GUARD-Komponenten: als Single Source für Threat-Detections, zur Automatisierung der Detection-as-Code-Pipeline durch GitLab CI/CD und als "Frontend" für GUARD, über das Security-Engineers Threat-Detections hinzufügen, bearbeiten und löschen können.

Wie GitLab-Features GUARD nutzen:

• GitLab Projects: GUARD nutzt ein GitLab-Projekt-Repository als Single Source für GUARD-Threat-Detections, gespeichert im JSON-Format.
• GitLab MRs: Alle Änderungen an GUARD-Detections, einschließlich neuer Detections, nutzen GitLab-MRs gegen das Haupt-GUARD-Projekt. Ein detailliertes MR-Template wird verwendet, in dem Details zur hinzugefügten, bearbeiteten oder gelöschten Detection validiert und dokumentiert werden. MR-Approval-Rules, einschließlich CodeOwners und Protected Branches, stellen sicher, dass ordnungsgemäße Detection-Reviews vor dem Merge abgeschlossen sind.
• GitLab Issues: Bug-Reports oder andere Engineering-Aufgaben im Zusammenhang mit GUARD werden in GitLab Issues erfasst.
• GitLab Labels: Ein Set standardisierter Labels stellt sicher, dass Security-Engineers GUARD-Änderungen auf leicht nachvollziehbare Weise dokumentieren.
• GitLab CI/CD: GUARD nutzt eine GitLab-CI-Pipeline zur Automatisierung des Deployments neuer, geänderter oder gelöschter Detections in GitLabs Security Incident and Event Management (SIEM). Die CI-Pipeline von GUARD führt zahlreiche Validierungs-, Test- und Qualitätschecks durch, bevor die Pipeline erfolgreich passiert wird und Änderungen in GitLabs SIEM-Plattform committed werden.

Metriken-Generierung

Interaktionen mit der Alert-Handling-Oberfläche werden erfasst, um zentrale Performance-Metriken zu generieren: Time to Respond, Time to Resolve sowie Insights zu Alerts wie True/False-Positive-Rates. Zusätzlich erfasste Metadaten beinhalten eine Emoji-basierte Sentiment-Analyse. Engineers, die Alerts bearbeiten, geben "Feedback" zu behandelten Alerts in Form von Emojis, sodass dieses Feedback bei der Iteration von Detection-Rules berücksichtigt werden kann.

Alert-Handling-Metriken werden in einer separaten Datenbank gespeichert, um Visualisierungen zu erstellen, die von Engineers und Management konsultiert werden. Diese sind zentral für das Verständnis der Team-Performance bei Alert-Resolution und Alert-Fidelity, sodass kontinuierliche Verbesserung möglich ist.

Gemeinsam iterieren

Die Nutzung von GitLab als Single Source of Truth für Threat-Detection-Code ermöglichte GUARD, Prozesse von spezifischer SIEM-Technologie zu extrahieren. Dies unterstützt größere Flexibilität, einfachere Nutzung, Modularisierung und Audit-Fähigkeit. Für deutsche Unternehmen mit strengen Datenschutzanforderungen ist relevant: Die Lösung funktioniert vollständig mit GitLab Self-Managed, sodass keine Detection-Daten externe Cloud-Systeme verlassen müssen.

Iteration ist ein zentraler GitLab-Wert – wir starten mit dem kleinsten wertvollen Element, um schnelles Feedback zu erhalten und effizient ein gewünschtes Endziel zu erreichen. GUARD ist keine Ausnahme. Wir hoffen, dass das Teilen von GUARD Lesern hilft, in Richtung eigener Automatisierungsverbesserungen zu iterieren.

Dieser Artikel ist der erste einer Serie über GitLab GUARD. Als Nächstes werden wir Details zu verschiedenen Aspekten unserer iterativen Journey zur Implementierung von GUARD bei GitLab teilen. Der zweite Teil der Serie, "Cybersecurity-Bedrohungen mit GitLab CI/CD automatisieren", beschreibt den Detection-as-Code-Workflow mit CI/CD-Pipeline-Details, automatisierten Quality-Gates und praktischen Implementierungsbeispielen.