Cyber Resilience Testing nach DORA: TLPT, Penetrationstests und Testing-Strategie

Mit DORA wird Cyber Resilience Testing zur regulatorischen Pflicht für alle Finanzinstitute in der EU. Die Verordnung fordert umfassende, realitätsnahe Tests der digitalen Widerstandsfähigkeit – von Vulnerability Scans bis zu hochkomplexen Threat-Led Penetration Tests (TLPT). Ab Januar 2025 müssen Institute nachweisen, dass ihre IKT-Systeme auch gegen ausgefeilte Cyber-Angriffe resilient sind.

Regulatorische Grundlagen: DORA Art. 24-27

Verpflichtende Tests für alle Finanzinstitute (Art. 25)

Mindestanforderungen an alle Institute:

1. Vulnerability Assessments and Scans: Mindestens jährlich für alle kritischen Systeme
2. Open Source Analyses: Überwachung von öffentlich bekannten Schwachstellen
3. Network Security Assessments: Überprüfung der Netzwerksegmentierung und Firewall-Regeln
4. Gap Analyses: Identifikation von Sicherheitslücken im IKT-Risikomanagement
5. Physical Security Reviews: Prüfung der physischen Sicherheit kritischer Infrastruktur (Rechenzentren)
6. Questionnaires und Scanning-Software-Lösungen: Standardisierte Assessments
7. Source Code Reviews: Bei Eigenentwicklungen kritischer Systeme
8. Szenario-basierte Tests: Simulation von Angriffsvektoren (DDoS, Ransomware, Social Engineering)
9. Compatibility Testing: Sicherstellung der Kompatibilität nach Updates
10. Performance Testing: Belastungstests unter Berücksichtigung von Sicherheitsaspekten
11. End-to-End-Testing: Ganzheitliche Tests der Prozessketten
12. Penetrationstests: Gezielte Simulation von Angriffen

Advanced Testing für bedeutende Institute (Art. 26-27)

Systemrelevante Institute müssen zusätzlich Threat-Led Penetration Tests (TLPT) durchführen – die anspruchsvollste Form des Cyber Resilience Testing.

Threat-Led Penetration Tests (TLPT)

Was ist TLPT?

TLPT sind realitätsnahe, geheimdienstähnliche Angriffssimulationen durch externe Experten (Red Team), die auf aktueller Threat Intelligence basieren. Im Gegensatz zu klassischen Penetrationstests sind TLPT:

• Threat Intelligence-gestützt: Angriffsmethoden realer APT-Gruppen (Advanced Persistent Threats)
• Unangekündigt: IT-Teams (Blue Team) wissen nicht, wann der Test beginnt
• Realistisch: Volle Ausnutzung von Schwachstellen (mit Sicherheitsvorkehrungen)
• Ganzheitlich: Kombination technischer, organisatorischer und physischer Angriffe
• Crown Jewel-fokussiert: Fokus auf die kritischsten Systeme und Daten

Wer muss TLPT durchführen?

Kriterien für TLPT-Verpflichtung (Art. 26 Abs. 1):

Nationale Aufsichtsbehörden (in Deutschland: BaFin, EZB/SSM) designieren Institute basierend auf:

1. Größe: Bilanzsumme > 30 Mrd. EUR (indikativ)
2. Systemische Bedeutung: Systemrelevante Institute (G-SIB, O-SII)
3. Kritikalität der Geschäftstätigkeit: Payment Service Provider, Systemdienstleister
4. IKT-Risikoprofil: Institute mit hoher Cyber-Exposition
5. Vernetzung: Zentrale Rolle im Finanzsystem (z.B. Clearinghäuser)

Schätzung Deutschland: ~30-50 Institute (alle G-SIBs, große LSIs, Finanz Informatik, Giesecke+Devrient)

Häufigkeit: Mindestens alle 3 Jahre (oder bei wesentlichen Änderungen der IKT-Infrastruktur)

TLPT-Framework: TIBER-EU

DORA verweist auf den TIBER-EU Framework (Threat Intelligence-based Ethical Red Teaming) der EZB als Best Practice:

TIBER-EU Phasen:
1. Preparation (Vorbereitung)
2. Testing (Durchführung)
3. Closure (Abschluss und Lessons Learned)

Phase 1: Preparation (3-6 Monate)

Schritt 1.1: Scoping

• Scope-Definition: Welche Systeme werden getestet? (Crown Jewels)
• Test Objectives: Was soll erreicht werden? (z.B. Zugriff auf Kundendaten, Manipulation von Zahlungsverkehr)
• Threat Intelligence: Welche Angreifer-Gruppen sind relevant? (z.B. APT28, FIN7)

Praxisbeispiel: Scope für eine Bank

Crown Jewels:
├─ Kernbankensystem (Kundendaten, Kontostände)
├─ SWIFT-Anbindung (Zahlungsverkehr)
├─ Online-Banking-Plattform (Authentifizierung, Transaktionen)
└─ Data Warehouse (Geschäftsgeheimnisse, Strategiedaten)

Out of Scope:
├─ Nicht-produktive Testsysteme
├─ Externe Cloud-Dienste (separate Tests beim Provider)
└─ Physische Angriffe auf Filialen (optional, kann inkludiert werden)

Schritt 1.2: Threat Intelligence

Spezialisierte Threat-Intelligence-Provider erstellen ein Targeted Threat Intelligence Report (TTIR):

• Angreifer-Profile: Welche APT-Gruppen könnten das Institut angreifen? (z.B. Nationalstaaten, Cybercrime-Gruppen)
• Tactics, Techniques, Procedures (TTPs): Wie gehen diese Angreifer vor? (MITRE ATT&CK Framework)
• Known Vulnerabilities: Welche Schwachstellen sind typisch für die eingesetzte Technologie?
• Aktuelle Kampagnen: Welche Angriffskampagnen laufen aktuell gegen den Finanzsektor?

Schritt 1.3: Red Team Selection

• Zertifizierung: Red Team-Provider müssen von nationaler Aufsicht akkreditiert sein (BaFin-Liste ab Q2 2025)
• Erfahrung: Nachgewiesene Expertise in Financial Services, APT-Simulationen
• Unabhängigkeit: Keine Interessenkonflikte (z.B. Provider darf nicht gleichzeitig IT-Dienstleister des Instituts sein)

Kosten: 150.000 - 500.000 EUR je nach Komplexität

Phase 2: Testing (4-12 Wochen)

Red Team Operations:

Das Red Team versucht, die definierten Test Objectives zu erreichen – mit allen Mitteln, die auch reale Angreifer einsetzen würden:

Angriffsvektoren:

1. Reconnaissance (Aufklärung)

   • Open-Source-Intelligence (OSINT): Öffentliche Daten über Institute sammeln (LinkedIn, Stellenausschreibungen, Konferenzen)
   • Social Engineering: Mitarbeiter ausforschen (Phishing-Simulationen)
   • Network Scanning: Externe Netzwerk-Scans für offene Ports, Dienste

2. Initial Access (Erstzugriff)

   • Spear-Phishing: Zielgerichtete E-Mails an Mitarbeiter (z.B. CEO-Fraud, Fake-Rechnungen)
   • Watering Hole Attacks: Kompromittierung von häufig besuchten Webseiten
   • Supply Chain Attacks: Kompromittierung von Drittanbietern (z.B. Software-Updates)
   • VPN/RDP-Angriffe: Brute-Force oder Ausnutzung von Schwachstellen in Remote-Zugängen

3. Privilege Escalation (Rechteausweitung)

   • Ausnutzung von Schwachstellen in Windows/Linux (z.B. ungepatche Kernel-Exploits)
   • Pass-the-Hash, Pass-the-Ticket (Kerberos-Angriffe)
   • Credential Dumping (z.B. Mimikatz auf kompromittierten Clients)

4. Lateral Movement (Bewegung im Netzwerk)

   • Exploitation von Vertrauensstellungen zwischen Systemen
   • Pivoting über kompromittierte Jump Hosts
   • Ausnutzung von Schwachstellen in internen Diensten (SMB, RDP, WinRM)

5. Exfiltration (Datenabfluss)

   • Datenexfiltration über DNS-Tunneling, HTTPS
   • Kompromittierung von Backup-Systemen
   • Manipulation von Transaktionsdaten (Goal: Zahlungsverkehr)

Purple Team Approach (optional, aber empfohlen):

Während des Tests arbeiten Red Team und Blue Team (IT-Security-Team des Instituts) in begrenztem Umfang zusammen:

• Blue Team beobachtet: Erkennt das SIEM/SOC die Angriffe?
• Feedback-Loops: Täglich kurze Abstimmungen (ohne Details zu verraten)
• Continuous Improvement: Blue Team kann Detektionsregeln in Echtzeit anpassen

Phase 3: Closure (4-8 Wochen)

Replaying und Lessons Learned:

• Detailed Walkthrough: Red Team zeigt genau, wie Zugriff erlangt wurde
• Blue Team Analysis: Wo hat die Detektion versagt? Warum?
• Remediation Plan: Priorisierte Maßnahmen zur Behebung der Schwachstellen

TLPT-Bericht:

Der finale Report muss enthalten:

1. Executive Summary: Für Geschäftsleitung (nicht-technisch)
2. Test Objectives: Wurden die Ziele erreicht?
3. Attack Paths: Detaillierte Darstellung der Angriffspfade (Attack Tree)
4. Findings: Alle identifizierten Schwachstellen (CVSS-Scoring)
5. Blue Team Performance: Erkennungsrate, Response-Zeiten
6. Recommendations: Priorisierte Handlungsempfehlungen
7. Compliance Statement: Erfüllung der DORA-Anforderungen

Submission an Aufsicht:

• Zusammenfassung des TLPT-Berichts muss an BaFin/EZB übermittelt werden (innerhalb von 4 Wochen nach Abschluss)
• Full Report auf Anfrage verfügbar

Allgemeine Tests: Best Practices

Auch Institute ohne TLPT-Verpflichtung müssen umfassende Tests durchführen. Hier eine strukturierte Testing-Strategie:

1. Vulnerability Management und Scanning

Häufigkeit: Wöchentlich (automatisiert), monatlich (manuell validiert)

Tools:

• Tenable Nessus: Branchenstandard für Vulnerability Scanning
• Qualys VMDR: Cloud-basiertes Scanning mit Priorisierung
• Rapid7 InsightVM: Integration mit SIEM

Prozess:

1. Automated Scan (wöchentlich)
    ↓
2. Schwachstellen-Priorisierung (CVSS-Score, Exploitability)
    ↓
3. Remediation oder Mitigating Controls (Frist: 48h für Critical, 30 Tage für High)
    ↓
4. Verification Scan (nach Patch)
    ↓
5. Reporting an IT-Security-Management (monatlich)

2. Web Application Security Testing

OWASP Top 10 Coverage obligatorisch

Dynamic Application Security Testing (DAST):

• Tools: Burp Suite, OWASP ZAP, Acunetix
• Häufigkeit: Bei jedem Major Release, mindestens quartalsweise

Static Application Security Testing (SAST):

• Tools: SonarQube, Checkmarx, Veracode
• Integration: In CI/CD-Pipeline (automatisiert bei jedem Commit)

3. Social Engineering und Phishing-Simulationen

Häufigkeit: Quartalsweise (variierte Szenarien)

Szenarien:

• CEO-Fraud: Fake-E-Mail von Geschäftsleitung mit Zahlungsanweisung
• Credential Harvesting: Fake-Login-Seiten (z.B. Office 365, VPN)
• Malware-Attachments: Makro-basierte Dokumente, ZIP-Archive
• Vishing (Voice Phishing): Telefonanrufe mit Social-Engineering-Ansatz

Tools: KnowBe4, Cofense, Microsoft Attack Simulator

KPIs:

• Click-Rate: < 5% (Ziel)
• Credential-Submission-Rate: < 2% (Ziel)
• Reporting-Rate: > 40% (Ziel – Mitarbeiter melden verdächtige E-Mails)

4. Network Penetration Testing

Häufigkeit: Jährlich (extern + intern)

Scope:

• Externe Tests: Angriffe aus dem Internet (öffentliche IP-Bereiche)
• Interne Tests: Angriffe aus dem internen Netz (Assumed Breach-Szenario)

Methodik:

• Black Box: Tester hat keine Vorabinformationen (realistisch)
• Grey Box: Tester erhält begrenzte Informationen (z.B. IP-Bereiche)
• White Box: Vollständige Informationen (maximale Coverage)

Deliverables:

• Detaillierter Pen-Test-Report mit Schwachstellen
• Proof-of-Concept-Exploits (wo möglich)
• Priorisierte Remediation Roadmap

5. Red Team Exercises (Light Version)

Für Institute ohne TLPT-Verpflichtung empfohlen:

Difference TLPT vs. Red Team Exercise:

Aspekt	TLPT (DORA-konform)	Red Team Exercise
Regulatorisch	Verpflichtend für bedeutende Institute	Freiwillig
Threat Intelligence	Verpflichtend (TTIR)	Optional
Scope	Crown Jewels, volle Kette	Flexibel
Dauer	4-12 Wochen	1-4 Wochen
Kosten	150k-500k EUR	30k-100k EUR
Aufsichtsreporting	Pflicht	Freiwillig

Testing-Kalender: Empfohlener Jahresplan

Q1:
├─ Vulnerability Scans (wöchentlich, laufend)
├─ Phishing-Simulation (Januar)
├─ Internal Network Pen-Test (Februar-März)
└─ Web Application DAST (alle kritischen Apps)

Q2:
├─ External Pen-Test (April)
├─ Phishing-Simulation (April)
├─ Source Code Review (Mai, kritische Eigenentwicklungen)
└─ Physical Security Review (Juni, alle Rechenzentren)

Q3:
├─ Social Engineering Campaign (Juli, neue Szenarien)
├─ Disaster Recovery Drill (August, inkl. Cyber-Incident)
├─ Red Team Exercise (September, optional)
└─ Vulnerability Scan Review (Trend-Analyse über 12 Monate)

Q4:
├─ TLPT (Oktober-November, alle 3 Jahre für bedeutende Institute)
├─ Compliance Gap Analysis (DORA, BAIT)
├─ Phishing-Simulation (Oktober)
└─ Annual Security Assessment (Dezember, Gesamtbericht an Geschäftsleitung)

Dokumentation und Reporting

DORA-konforme Dokumentation:

1. Test-Strategie: Dokumentiertes Testing-Framework (Häufigkeiten, Scope, Methodiken)
2. Test-Pläne: Detaillierte Pläne für jeden Test (Scope, Timing, Verantwortlichkeiten)
3. Test-Reports: Findings, Recommendations, Remediation Status
4. Remediation Tracking: Nachvollziehbare Behebung aller Schwachstellen (Ticketsystem)
5. Lessons Learned: Dokumentierte Verbesserungsmaßnahmen nach jedem Test

Reporting an Geschäftsleitung:

Quartalsweise Dashboard mit:

• Anzahl durchgeführter Tests
• Anzahl identifizierter Schwachstellen (nach Severity)
• Remediation-Status (% behoben)
• Trend-Analysen (Verbesserung über Zeit?)
• Compliance-Status (DORA, BAIT)

Best Practices

Top 10 Empfehlungen:

1. Threat Intelligence Integration: Testing basiert auf realen Bedrohungen (nicht nur OWASP Top 10)
2. Purple Team Mindset: Kooperative Tests (Red + Blue) für maximalen Lerneffekt
3. Continuous Testing: Nicht nur jährliche Pen-Tests, sondern kontinuierliche Assessments
4. Automation: Vulnerability Scans, SAST/DAST in CI/CD integrieren
5. Third-Party Specialists: Externe Expertise für TLPT und komplexe Pen-Tests
6. Realistic Scenarios: Tests müssen reale Angriffsvektoren abbilden
7. Remediation Focus: Schwachstellen finden ist einfach – Behebung ist entscheidend
8. Metrics-Driven: KPIs definieren (z.B. Mean Time to Remediate MTTR)
9. Board-Level Awareness: Geschäftsleitung muss Testergebnisse verstehen und Budgets freigeben
10. Post-Test Action: Lessons Learned in Prozessverbesserungen überführen

---

Fazit: Cyber Resilience Testing ist kein optionales Nice-to-have mehr, sondern regulatorische Pflicht. TLPT für bedeutende Institute sind anspruchsvoll und kostenintensiv, aber unverzichtbar für echte Cyber-Resilienz. Institute sollten Testing als kontinuierlichen Verbesserungsprozess begreifen – nur wer seine Schwachstellen kennt, kann sie beheben.