Security Chaos Engineering: Resilienztests für Sicherheitssysteme

Netflix tötet regelmäßig eigene Server in der Produktion - mit dem “Chaos Monkey”. Die Idee: Wenn Systeme jederzeit ausfallen können, müssen sie so gebaut sein dass sie trotzdem funktionieren. Security Chaos Engineering überträgt dieses Denken auf Sicherheitssysteme: Was passiert wenn ein SIEM-Alert übersehen wird? Wenn ein EDR-Agent ausfällt? Wenn der Incident-Response-Prozess unter Druck versagt?

Security Chaos Engineering vs. Penetrationstest

Vergleich der Ansätze

Penetrationstest:

• Ziel: Schwachstellen in Systemen/Applikationen finden
• Frage: “Kann ein Angreifer eindringen?”
• Perspektive: Offensiv (Red Team)
• Ergebnis: Liste von Schwachstellen + Empfehlungen
• Frequenz: Jährlich / projektbezogen

Security Chaos Engineering (SCE):

• Ziel: Resilienzt von Sicherheitskontrollen testen
• Frage: “Erkennen und reagieren wir auf Angriffe korrekt?”
• Perspektive: Defense Testing (Purple Team)
• Ergebnis: Detection Coverage, MTTR, False-Negative-Rate
• Frequenz: Kontinuierlich (automatisiert!)

SCE-Hypothesen (Chaos-Prinzip)

“Das System funktioniert wie erwartet, wenn…”

Beispiel: “Wenn ein Angreifer Mimikatz auf einem DC ausführt, wird unser EDR es erkennen und ein Alert in < 5 Minuten erzeugen”

Test: Mimikatz simulieren → EDR-Alert gemessen? → Hypothese bestätigt/falsifiziert

Was SCE beantwortet

• Erkennen wir Lateral-Movement-Techniken in unserem SIEM?
• Wie lange dauert es vom Angriff bis zum Alert?
• Reagiert unser IR-Team korrekt auf den Alert?
• Funktioniert unsere Detection auch um 2 Uhr nachts?
• Wie resilient ist unser SIEM wenn 10.000 Events/Sekunde ankommen?
• Was passiert wenn unser EDR-Agent nicht läuft?

MITRE ATT&CK als Testrahmen

ATT&CK-basiertes Detection Testing

MITRE ATT&CK Matrix als Blueprint:

• 14 Tactics (Taktiken): Reconnaissance bis Impact
• 200+ Techniques (Techniken): spezifische Angriffsmethoden
• Sub-Techniques: detaillierte Implementierungsvarianten

Beispiel Detection Coverage Analyse

Tactic: Credential Access

Technique	Beschreibung	EDR	SIEM	SOC-Alert	MTTR
T1003.001	LSASS Memory	✓	✓	✓	3 min
T1003.002	Security Account Mgr	?	?	?	?
T1558.003	Kerberoasting	✗	✓	✓	47 min
T1110.001	Password Guessing	✗	✓	✗ (!)	N/A
T1555.003	Keychain Credentials	-	-	-	eher macOS

T1110.001: SIEM erkennt, aber kein Alert ausgelöst! (Lücke gefunden!)

ATT&CK-Navigator für Coverage-Visualisierung

• URL: https://mitre-attack.github.io/attack-navigator/
• Layer importieren mit Coverage-Daten
• Rot = nicht erkannt, Gelb = teilweise, Grün = voll erkannt
• Direktes Reporting für CISO!

Tools für Security Chaos Engineering

1. Atomic Red Team (Red Canary)

• Open-Source-Bibliothek von ATT&CK-Testatomics
• Über 1.000 Tests für Windows/Linux/macOS
• YAML-basiert, einfach erweiterbar
• Jeder Test: isoliert, kontrolliert, dokumentiert

# Installation:
Install-Module -Name invoke-atomicredteam -Force
Import-Module invoke-atomicredteam

# Ausführung (Windows, T1003.001 - LSASS Dump):
Invoke-AtomicTest T1003.001
# → Führt kontrollierten LSASS-Test aus
# → Danach: prüfen ob EDR-Alert ausgelöst wurde!

# Cleanup automatisch:
Invoke-AtomicTest T1003.001 -Cleanup
# → Räumt Test-Artefakte auf

# Alle Tests einer Tactic ausführen:
Invoke-AtomicTest T1059 -GetPrereqs  # Lateral Movement - Scripting
Invoke-AtomicTest T1059

2. Stratus Red Team (Datadog)

• Fokus: Cloud-Angriffe (AWS, Azure, GCP, K8s)
• ATT&CK-basiert, granulare Cloud-Techniken

# Alle verfügbaren Tests anzeigen:
stratus list

# Einzelnen Test detonieren (AWS):
stratus detonate aws.credential-access.ec2-get-password-data
# → AWS-API-Call der legitim aussieht aber verdächtig ist
# → Prüfen: AWS CloudTrail Alert im SIEM?

# Azure-Tests:
stratus detonate azure.persistence.backdoor-account

# GCP-Tests:
stratus detonate gcp.exfiltration.share-object-with-external-account

# Cleanup:
stratus cleanup --all

3. MITRE Caldera

• Vollautomatisiertes Adversary-Emulation-Framework
• Web-Interface für Red/Purple-Team-Operationen
• “Agents” auf Zielmaschinen installiert → Command & Control
• Vorgefertigte “Adversary-Profile” (z.B. APT29-Simulation)

git clone https://github.com/mitre/caldera.git
cd caldera && pip install -r requirements.txt
python server.py --insecure

Use Case: Kontinuierliche Detection-Validierung

• Caldera-Agent auf Honeypot-System
• Täglich: Automated Red-Team-Simulation
• SIEM-Alerts überprüfen: wurden alle Techniken erkannt?

4. BAS-Tools (Breach and Attack Simulation)

Kommerzielle Lösungen für Enterprise:

Tool	Stärke
Cymulate	SaaS-basiert, umfangreiche ATT&CK-Abdeckung
XM Cyber	Attack-Path-Simulation + Priorisierung
Pentera	Automatisierter Pentest + Remediation
SafeBreach	Continuous Security Validation

Unterschied zu SCE:

• BAS = automatisierter Pentest (zeigt Schwachstellen)
• SCE = Detection/Response Testing (zeigt ob Security Ops funktioniert)

SCE-Programm aufbauen

Implementierungs-Roadmap

Phase 1: Grundlagen schaffen (Monat 1-2)

• ATT&CK-Coverage-Matrix für eigene Umgebung erstellen
• Baseline: aktuellen Erkennungsgrad messen (IST-Zustand)
• Testumgebung aufbauen (isolierte VMs für destruktive Tests)
• Stakeholder-Alignment: IT-Ops, SOC, Management informieren

Phase 2: Erste Tests (Monat 2-4)

• Atomic Red Team installieren (auf Test-VMs, nicht Produktion!)
• 5-10 kritische Techniken testen (LSASS, PsExec, BloodHound)
• SIEM-Alerts messen: welche wurden ausgelöst, welche nicht?
• Lücken dokumentieren und priorisieren

Phase 3: Kontinuierliches Testing (ab Monat 4)

• Automatisierte Tests: wöchentlich 10-20 Atomic Tests
• Regression-Tests: nach SIEM-Updates prüfen ob Detection noch funktioniert
• Coverage-Dashboard für SOC-Team

Sicherheitsmaßnahmen für SCE-Ausführung

• Change Management: jeder SCE-Test muss als Change dokumentiert sein
• Nie in Produktion ohne explizite Freigabe
• Rollback-Pläne für jeden Test
• Benachrichtigung SOC-Team VOR dem Test (Purple-Team-Modus) - oder KEIN Vorabinfo (Blind-Test für realistische IR-Messung)
• Zeit-begrenzte Tests (kein 24h-Angriff!)

Key Metrics für das SCE-Programm

Metrik	Beschreibung
Detection Rate	% der Tests die einen Alert ausgelöst haben
False Negative Rate	% der echten Angriffe die NICHT erkannt wurden
MTTD	Mean Time to Detect (vom Test bis zum Alert)
MTTR	Mean Time to Respond (vom Alert bis zur Maßnahme)
Coverage Score	% der ATT&CK-Techniken mit aktiver Detection
Trend	Verbesserung über Zeit (Quarterly Review)

Reporting an Management

Statt technischer Details:

• “Wir haben 847 Angriffstechniken simuliert: 71% erkannt (Vorjahr: 58%)”
• “Nach Angriff dauert es Ø 4 Minuten bis zum Alert (Ziel: <5 min)”
• “3 kritische Detection-Lücken identifiziert, 2 bereits geschlossen”
• “Unsere Erkennung von Ransomware-Precursor-Aktivitäten: 100%”

---

Security Chaos Engineering schließt die Lücke zwischen “Wir haben Security-Tools” und “Unsere Security-Tools funktionieren wenn es darauf ankommt”. AWARE7 unterstützt beim Aufbau eines kontinuierlichen SCE-Programms und der Analyse von Detection Coverage.

Security Chaos Engineering anfragen | Purple Team Assessment