Cybersecurity-Bedrohungen mit GitLab CI/CD automatisieren

Dieser Blogpost ist der zweite Beitrag einer Serie über GitLab Universal Automated Response and Detection (GUARD).

Die Erstellung und Bereitstellung von Security-Threat-Detections in einem Security Information Event Management System (SIEM) ist zentrale Komponente erfolgreicher Cybersecurity-Programme. Der Übergang von manueller Detection-Erstellung zu vollautomatisierten Prozessen durch Detection as Code (DaC) gewährleistet Konsistenz, Qualität, Audit-Fähigkeit und automatisierte Tests. Bei GitLab haben wir DaC-Funktionen in GUARD integriert, unser vollautomatisiertes Detection- und Response-Framework.

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 (systematische Protokollierung). Die vollständige Versionierung aller Detection-Änderungen schafft zudem einen lückenlosen Audit-Trail für Compliance-Nachweise.

Die Herausforderung: Source Control und automatisierte Tests

Die Signals-Engineering- und SIRT-Teams bei GitLab teilen sich die Verantwortung für Erstellung, Aktualisierung und Außerbetriebnahme von Threat-Detections im SIEM. Die Aufrechterhaltung einer Single Source of Truth für Detections ist kritisch, um Konsistenz und Qualitätsstandards sicherzustellen. Unsere Teams entschieden bewusst, den Detection-Erstellungsprozess vom SIEM zu abstrahieren. Dadurch verbesserten sich Issue-Tracking, Konsistenz, Rollback-Prozesse und Metriken.

Zusätzlich stellten Pre-Commit-Detection-Tests außerhalb des SIEM sicher, dass neu erstellte Detections keine übermäßig False-Positive-lastigen Alerts einführten, die Tuning oder Deaktivierung während der Fehlerkorrektur erfordert hätten.

Die Lösung: GitLab CI/CD für Detection-Testing und -Validierung nutzen

Um diese Herausforderungen zu adressieren, entwickelten wir einen Workflow mit GitLab CI/CD, der zu einem sicheren SIEM-Detection-Deployment-Prozess mit systematischer Validierung führte.

Kernkomponenten der GUARD-DaC-Pipeline

1. Detections in JSON-Format in GitLab-Projekt gespeichert

GitLab nutzt das JSON-Format für Threat-Detections. Das Template enthält essenzielle Informationen wie SIEM-Query-Logik, Detection-Titel und -Beschreibung sowie Runbook-Page-Link, MITRE-Tactic und -Technique zur Detection und weitere notwendige Details.

2. Merge Requests initiieren

Wenn ein GitLab-Teammitglied eine neue Threat-Detection erstellen, eine existierende aktualisieren oder eine aktuelle Detection löschen möchte, initiiert es den Prozess durch Einreichen eines Merge Request (MR) im DaC-Projekt, das das Detection-JSON-Template enthält. Die Erstellung des MR löst automatisch eine CI/CD-Pipeline aus.

3. Automatisierte Validierung durch CI/CD-Jobs

Jeder MR enthält automatisierte Checks via GitLab CI/CD:

• Query-Format-Validierung: SIEM-API-Abfrage stellt sicher, dass die Detection-Query valide ist
• JSON-Detection-Fields-Validierung: Validiert, dass alle erforderlichen Felder vorhanden sind und im korrekten Format vorliegen
• Neue Detections und Detection-Modifikationen lösen SIEM-API-Calls aus, um sicherzustellen, dass die Detection keine Fehler enthält und keine Probleme in Production-Detection-Rules eingeführt werden
• Detection-Deletion-MRs lösen Pipeline-SIEM-API-Queries aus, um zu prüfen, dass die zu löschende Detection noch aktiv ist und gelöscht werden kann

4. Peer Review und Approval

Wenn ein Detection-MR-Job erfolgreich abgeschlossen ist, ist ein Peer Review erforderlich, um zu prüfen und zu bestätigen, dass der MR die erforderlichen Qualitäts- und Content-Standards erfüllt, bevor der Detection-MR gemergt werden kann. Merge-Request-Approval-Rules werden genutzt, um den Peer-Review-Prozess auszulösen.

5. Merge und finales Deployment

Nach MR-Approval wird dieser in den Main-Branch gemergt. Als Teil der CI/CD-Pipeline führt ein automatisierter Job einen SIEM-API-Command aus, um zwei Aufgaben durchzuführen:

• Die neue Detection erstellen oder die existierende Detection aktualisieren/löschen, falls erforderlich
• MITRE-ATT&CK-Tactic- und -Technique-Informationen zur Alert aus den JSON-Dateien extrahieren und diese Details an eine Lookup-Table im SIEM übermitteln. Diese Lookup-Table spielt eine wichtige Rolle beim Mapping unserer Alerts zu MITRE-Tactics und -Techniques und hilft uns, unsere Threat-Analyse zu verbessern und Lücken in unseren Detection-Capabilities in Alignment mit dem MITRE-Framework zu identifizieren.

Hinweis: Die notwendigen Credentials für diese Aktionen werden sicher in CI/CD-Variablen gespeichert, um sicherzustellen, dass der Prozess vertraulich und sicher bleibt.

Nachfolgend ein Template für eine GitLab-CI/CD-gitlab-ci.yml-Konfigurationsdatei für eine DaC-Pipeline:

#
---------------------------------------------------------------------------
#
# GitLab CI/CD Pipeline for SIEM Detection Management
#
---------------------------------------------------------------------------
#

image: python:3.12

#
---------------------------------------------------------------------------
#
# Global Configuration
#
---------------------------------------------------------------------------
#

before_script:
  - apt-get update && apt-get install -y jq
  - pip install --upgrade pip
  - pip install -r requirements.txt

#
---------------------------------------------------------------------------
#

stages:
  - fetch
  - test
  - process
  - upload

#
---------------------------------------------------------------------------
#
# Fetch Stage
#
---------------------------------------------------------------------------
#

fetch_changed_files:
  stage: fetch
  script:
    - echo "Fetching changed files..."
    - git branch
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        git diff --name-status HEAD^1...HEAD > changed-files-temp.txt
      else
        git fetch origin $CI_COMMIT_BRANCH:$CI_COMMIT_BRANCH --depth 2000
        git diff --name-status ${CI_DEFAULT_BRANCH}...${CI_COMMIT_SHA} > changed-files-temp.txt
      fi
    - grep -E '\.json$' changed-files-temp.txt > changed-files.txt || true
    - flake8 .
    - pytest
  artifacts:
    paths:
      - changed-files.txt
    expose_as: 'changed_files'

#
---------------------------------------------------------------------------
#
# Test Stage
#
---------------------------------------------------------------------------
#

flake8:
  stage: test
  script:
    - echo "Running Flake8 for linting..."
    - flake8 .

pytest:
  stage: test
  script:
    - echo "Running Pytest for unit tests..."
    - pytest
  artifacts:
    when: always
    reports:
      junit: report.xml

#
---------------------------------------------------------------------------
#
# Process Stage
#
---------------------------------------------------------------------------
#

process_files:
  stage: process
  script:
    - echo "Processing changed files..."
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL
    - mkdir -p modified_rules delete_file new_file
    - python3 move-files.py -x changed-files.txt
    - python3 check-alerts-format.py
  artifacts:
    paths:
      - modified_rules
      - delete_file
      - new_file
#
---------------------------------------------------------------------------
#
# Upload Stage
#
---------------------------------------------------------------------------
#

update_rules:
  stage: upload
  script:
    - echo "Uploading updated rules and lookup tables..."
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL 
    - python3 update-rules.py
    - python3 update-exceptions.py
    - python3 create_ttps_layers.py
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE != "schedule"
      changes:
        - detections/**/*
        - exceptions/**/*

Das folgende Diagramm illustriert den Workflow des oben beschriebenen CI/CD-Prozesses mit seinen vier Phasen: Fetch (Änderungen identifizieren), Test (Linting und Tests), Process (Dateien kategorisieren) und Upload (Rules und Lookup-Tables aktualisieren).

In der deutschen SIEM-Landschaft nutzen Unternehmen primär Plattformen wie Splunk, Elastic SIEM oder IBM QRadar. Der hier beschriebene DaC-Ansatz abstrahiert Detection-Logik vom jeweiligen SIEM-System durch JSON-Templates, wodurch Herstellerunabhängigkeit gewährleistet wird. 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.

Benefits und Ergebnisse

Die Automatisierung unseres Detection-Lifecycles durch einen DaC-CI/CD-gestützten Workflow bringt zahlreiche Benefits für unseren Threat-Detection-Deployment-Prozess:

• Automatisierung: Die Automatisierung von Erstellung und Validierung der SIEM-Detections reduziert manuelle Fehler durch systematische Validierungsstufen und spart Zeit durch Pipeline-Automatisierung.
• Enhanced Security: Der CI-gesteuerte Workflow setzt eine Least-Privilege-Policy um und gewährleistet Konsistenz, Peer Reviews und Qualitätsstandards für Erstellung, Aktualisierung oder Löschung von Threat-Detections.
• Effizienz: Das standardisierte JSON-Detection-Format und die automatisierte Erstellung verkürzen den Deployment-Cycle von Detection-Erstellung bis SIEM-Integration.
• Kollaboration: Der MR- und Review-Prozess implementiert das in Deutschland übliche Vier-Augen-Prinzip: Jede Detection-Änderung durchläuft systematische Peer-Reviews, bevor sie in Production gelangt. Dies gewährleistet nicht nur fachliche Qualität, sondern erfüllt auch Governance-Anforderungen für kritische Sicherheitssysteme.
• Version Control: Die Behandlung von Threat-Detections als Code abstrahiert die Detections von der SIEM-Plattform, in der sie letztlich gespeichert werden. Diese Abstraktion liefert einen historischen Record von Änderungen, erleichtert Kollaboration und ermöglicht Rollbacks zu vorherigen Konfigurationen, falls Probleme auftreten.

Mit DaC starten

Die Nutzung von GitLab CI/CD und einer Least-Privilege-Policy hat unser SIEM-Detection- und Alert-Management mit definierten Quality-Gates systematisiert. Automatisierung hat Effizienz verbessert und Risiken reduziert und bietet ein hilfreiches Beispiel für andere, die ihre Security und Compliance verbessern möchten. Sie können dieses Tutorial ausprobieren, indem Sie sich für eine kostenlose Testversion von GitLab Ultimate anmelden. Für Unternehmen mit Data-Sovereignty-Anforderungen steht GitLab Self-Managed zur Verfügung.