Testmanagement
Digital Operational Resilience Testing nach DORA
Überblick
Das Testmanagement im Kontext der digitalen operationellen Resilienz umfasst alle Aktivitäten zur Überprüfung und Validierung der Wirksamkeit von Sicherheitsmaßnahmen, Systemen und Prozessen. DORA (Verordnung (EU) 2022/2554) definiert spezifische Anforderungen an regelmäßige Tests der digitalen operationellen Resilienz.
Testarten im Überblick
DORA definiert verschiedene Testarten zur Überprüfung der digitalen operationellen Resilienz. Die folgende Übersicht zeigt alle relevanten Testarten mit ihren Anforderungen, Frequenzen und DORA-Referenzen:
Penetrationstests
Beschreibung: Simulierte Angriffe auf Systeme zur Identifikation von Schwachstellen und Sicherheitslücken
Frequenz: Jährlich (verpflichtend für alle Finanzunternehmen)
DORA-Referenz: Art. 24 Abs. 1
Anwendungsbereich: Alle Finanzunternehmen
Threat-Led-Penetration-Testing (TLPT)
Beschreibung: Umfassende, realistische Angriffssimulationen basierend auf spezifischen Bedrohungsszenarien. Erweiterte Form des Penetrationstests mit Bedrohungsmodellierung, Szenario-Entwicklung und umfassender Bewertung.
Frequenz: Mindestens alle 3 Jahre (verpflichtend für kritische Finanzunternehmen)
DORA-Referenz: Art. 25 Abs. 1, Art. 25 Abs. 2
Anwendungsbereich: Kritische Finanzunternehmen
Vulnerability Scans
Beschreibung: Automatisierte Scans zur Erkennung bekannter Schwachstellen in Systemen und Anwendungen
Frequenz: Kontinuierlich / Monatlich (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. a
Anwendungsbereich: Alle Unternehmen
Red Team Exercises
Beschreibung: Multi-Vektor-Angriffe zur Überprüfung der gesamten Sicherheitspostur und Incident Response
Frequenz: Jährlich / Nach Bedarf (empfohlen für alle)
DORA-Referenz: Art. 24 Abs. 1 lit. b
Anwendungsbereich: Empfohlen für alle
Blue Team Exercises
Beschreibung: Übungen zur Verbesserung der Abwehrfähigkeiten und Reaktionszeiten
Frequenz: Jährlich / Nach Bedarf (empfohlen für alle)
DORA-Referenz: Art. 24 Abs. 1 lit. b
Anwendungsbereich: Empfohlen für alle
Purple Team Exercises
Beschreibung: Kollaborative Übungen zwischen Red und Blue Teams zur Optimierung der Sicherheitsmaßnahmen
Frequenz: Jährlich / Nach Bedarf (empfohlen für alle)
DORA-Referenz: Art. 24 Abs. 1 lit. b
Anwendungsbereich: Empfohlen für alle
Code Reviews / Quellcodeprüfungen
Beschreibung: Manuelle und automatisierte Überprüfung des Quellcodes auf Sicherheitsmängel
Frequenz: Bei jeder größeren Änderung / Kontinuierlich (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. c
Anwendungsbereich: Eigene Entwicklung
Threat Modelling
Beschreibung: Identifikation potenzieller Bedrohungen und Schwachstellen durch strukturierte Analyse
Frequenz: Bei neuen Systemen / Jährlich / Kontinuierlich (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. d
Anwendungsbereich: Alle Unternehmen
Open-Source-Analyse
Beschreibung: Bewertung der Sicherheit und Integrität eingesetzter Open-Source-Komponenten
Frequenz: Kontinuierlich / Bei Updates
DORA-Referenz: Art. 24 Abs. 1 lit. e
Anwendungsbereich: Alle Unternehmen mit OSS
Netzwerksicherheitsbewertung
Beschreibung: Überprüfung der Netzwerkarchitektur auf Sicherheitsrisiken
Frequenz: Jährlich / Halbjährlich (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. f
Anwendungsbereich: Alle Unternehmen
Physische Sicherheitsanalyse
Beschreibung: Bewertung physischer Sicherheitsmaßnahmen und -kontrollen
Frequenz: Jährlich
DORA-Referenz: Art. 24 Abs. 1 lit. g
Anwendungsbereich: Alle Unternehmen
Lasttests / Performance Tests
Beschreibung: Überprüfung der Systemleistung unter hoher Belastung
Frequenz: Bei größeren Releases / Halbjährlich / Quartalsweise (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. h
Anwendungsbereich: Alle Unternehmen
Ende-zu-Ende-Tests
Beschreibung: Ganzheitliche Tests, die den gesamten Datenfluss und die Prozesskette abdecken
Frequenz: Bei größeren Änderungen / Halbjährlich / Quartalsweise (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. i
Anwendungsbereich: Alle Unternehmen
Tabletop-Übungen
Beschreibung: Simulation von Krisenszenarien zur Überprüfung der Reaktionsfähigkeit
Frequenz: Quartalsweise / Monatlich (je nach Unternehmensgröße)
DORA-Referenz: Art. 24 Abs. 1 lit. j
Anwendungsbereich: Alle Unternehmen
Disaster Recovery Tests
Beschreibung: Überprüfung der Wiederherstellungspläne und -fähigkeiten für kritische Services
Frequenz: Halbjährlich / Quartalsweise (kritische Services)
DORA-Referenz: Art. 24 Abs. 1 lit. k
Anwendungsbereich: Alle Unternehmen
Hinweis: Die genaue Frequenz und der Umfang der Tests sollten risikobasiert und unter Berücksichtigung der Unternehmensgröße festgelegt werden. Kritische Finanzunternehmen müssen zusätzlich zum jährlichen Penetrationstest mindestens alle 3 Jahre ein Threat-Led-Penetration-Testing (TLPT) durchführen (Art. 25 Abs. 1).
DORA-Testanforderungen: Übersicht nach Testarten
| Testart | Frequenz | Anwendungsbereich | DORA-Referenz | Dokumentation |
|---|---|---|---|---|
| Penetrationstests | Jährlich | Alle Finanzunternehmen | Art. 24 Abs. 1 | Testbericht mit Ergebnissen und Maßnahmen |
| Threat-Led-Penetration-Testing (TLPT) | Mindestens alle 3 Jahre | Kritische Finanzunternehmen | Art. 25 Abs. 1, Art. 25 Abs. 2 | Umfassender TLPT-Bericht |
| Vulnerability Scans | Kontinuierlich / Monatlich | Alle Unternehmen | Art. 24 Abs. 1 lit. a | Scan-Berichte und Remediation-Status |
| Red Team Exercises | Jährlich / Nach Bedarf | Empfohlen für alle | Art. 24 Abs. 1 lit. b | Exercise-Bericht mit Lessons Learned |
| Code Reviews / Quellcodeprüfungen | Bei jeder größeren Änderung | Eigene Entwicklung | Art. 24 Abs. 1 lit. c | Review-Berichte |
| Threat Modelling | Bei neuen Systemen / Jährlich | Alle Unternehmen | Art. 24 Abs. 1 lit. d | Threat-Modell-Dokumentation |
| Open-Source-Analyse | Kontinuierlich / Bei Updates | Alle Unternehmen mit OSS | Art. 24 Abs. 1 lit. e | Analyse-Berichte und Abhängigkeitslisten |
| Netzwerksicherheitsbewertung | Jährlich / Bei größeren Änderungen | Alle Unternehmen | Art. 24 Abs. 1 lit. f | Bewertungsbericht |
| Physische Sicherheitsanalyse | Jährlich | Alle Unternehmen | Art. 24 Abs. 1 lit. g | Sicherheitsaudit-Bericht |
| Lasttests / Performance Tests | Bei größeren Releases / Halbjährlich | Alle Unternehmen | Art. 24 Abs. 1 lit. h | Performance-Test-Bericht |
| Ende-zu-Ende-Tests | Bei größeren Änderungen / Halbjährlich | Alle Unternehmen | Art. 24 Abs. 1 lit. i | E2E-Test-Bericht |
| Tabletop-Übungen | Quartalsweise | Alle Unternehmen | Art. 24 Abs. 1 lit. j | Übungsprotokoll und Lessons Learned |
| Disaster Recovery Tests | Halbjährlich (kritische Services) | Alle Unternehmen | Art. 24 Abs. 1 lit. k | DR-Test-Bericht |
| Blue Team Exercises | Jährlich / Nach Bedarf | Empfohlen für alle | Art. 24 Abs. 1 lit. b | Exercise-Bericht |
| Purple Team Exercises | Jährlich / Nach Bedarf | Empfohlen für alle | Art. 24 Abs. 1 lit. b | Exercise-Bericht |
Hinweis: Die DORA-Referenzen beziehen sich auf die Verordnung (EU) 2022/2554. Art. 24 regelt die allgemeinen Anforderungen an das Testen der digitalen operationellen Resilienz, Art. 25 spezifische Anforderungen an Threat-Led-Penetration-Testing (TLPT) für kritische Finanzunternehmen.
DORA-Testanforderungen nach Unternehmensgröße
Die DORA-Verordnung unterscheidet zwischen verschiedenen Unternehmensgrößen und kritischen Finanzunternehmen. Die folgenden Tabellen zeigen die Relevanz und empfohlenen Frequenzen für verschiedene Testarten:
Kleine Unternehmen (bis 50 Mitarbeiter, einfache IT-Infrastruktur)
| Testart | Frequenz | Priorität | DORA-Referenz | Hinweise |
|---|---|---|---|---|
| Penetrationstests | Jährlich (verpflichtend) | Hoch | Art. 24 Abs. 1 | Extern durchführen lassen |
| Vulnerability Scans | Monatlich | Hoch | Art. 24 Abs. 1 lit. a | Automatisiert möglich |
| Threat Modelling | Bei neuen Systemen | Mittel | Art. 24 Abs. 1 lit. d | Einfache Methodik ausreichend |
| Code Reviews | Bei größeren Änderungen | Mittel | Art. 24 Abs. 1 lit. c | Nur bei eigener Entwicklung |
| Tabletop-Übungen | Halbjährlich | Mittel | Art. 24 Abs. 1 lit. j | Fokus auf kritische Szenarien |
| Disaster Recovery Tests | Jährlich | Mittel | Art. 24 Abs. 1 lit. k | Fokus auf kritische Services |
| TLPT | Nicht verpflichtend | Niedrig | Art. 25 Abs. 1 | Nur bei kritischen Unternehmen |
| Red Team Exercises | Optional | Niedrig | Art. 24 Abs. 1 lit. b | Kann durch Penetrationstests abgedeckt werden |
Mittlere Unternehmen (50-250 Mitarbeiter, moderate IT-Infrastruktur)
| Testart | Frequenz | Priorität | DORA-Referenz | Hinweise |
|---|---|---|---|---|
| Penetrationstests | Jährlich (verpflichtend) | Hoch | Art. 24 Abs. 1 | Extern durchführen lassen |
| Vulnerability Scans | Wöchentlich / Monatlich | Hoch | Art. 24 Abs. 1 lit. a | Automatisiert mit manueller Überprüfung |
| Threat Modelling | Jährlich / Bei neuen Systemen | Hoch | Art. 24 Abs. 1 lit. d | Strukturierte Methodik |
| Code Reviews | Bei jeder größeren Änderung | Hoch | Art. 24 Abs. 1 lit. c | Automatisiert + manuell |
| Open-Source-Analyse | Kontinuierlich / Bei Updates | Mittel | Art. 24 Abs. 1 lit. e | Automatisierte Tools |
| Netzwerksicherheitsbewertung | Jährlich | Mittel | Art. 24 Abs. 1 lit. f | Extern empfohlen |
| Tabletop-Übungen | Quartalsweise | Mittel | Art. 24 Abs. 1 lit. j | Verschiedene Szenarien |
| Disaster Recovery Tests | Halbjährlich | Mittel | Art. 24 Abs. 1 lit. k | Kritische Services |
| Red Team Exercises | Jährlich | Mittel | Art. 24 Abs. 1 lit. b | Extern durchführen lassen |
| TLPT | Nicht verpflichtend | Niedrig | Art. 25 Abs. 1 | Nur bei kritischen Unternehmen |
Große Unternehmen (250+ Mitarbeiter, komplexe IT-Infrastruktur)
| Testart | Frequenz | Priorität | DORA-Referenz | Hinweise |
|---|---|---|---|---|
| Penetrationstests | Jährlich (verpflichtend), ggf. häufiger | Hoch | Art. 24 Abs. 1 | Extern + intern, verschiedene Bereiche |
| Vulnerability Scans | Kontinuierlich / Wöchentlich | Hoch | Art. 24 Abs. 1 lit. a | Automatisiert mit kontinuierlichem Monitoring |
| Threat Modelling | Kontinuierlich / Bei neuen Systemen | Hoch | Art. 24 Abs. 1 lit. d | Integriert in SDLC |
| Code Reviews | Kontinuierlich / Bei jeder Änderung | Hoch | Art. 24 Abs. 1 lit. c | Automatisiert + manuell, integriert in CI/CD |
| Open-Source-Analyse | Kontinuierlich | Hoch | Art. 24 Abs. 1 lit. e | Automatisierte Tools mit Alerting |
| Netzwerksicherheitsbewertung | Halbjährlich / Jährlich | Hoch | Art. 24 Abs. 1 lit. f | Extern durchführen lassen |
| Physische Sicherheitsanalyse | Jährlich | Mittel | Art. 24 Abs. 1 lit. g | Extern durchführen lassen |
| Lasttests / Performance Tests | Bei größeren Releases / Halbjährlich | Mittel | Art. 24 Abs. 1 lit. h | Automatisiert in CI/CD |
| Ende-zu-Ende-Tests | Bei größeren Änderungen / Halbjährlich | Mittel | Art. 24 Abs. 1 lit. i | Automatisiert wo möglich |
| Tabletop-Übungen | Quartalsweise | Hoch | Art. 24 Abs. 1 lit. j | Verschiedene Szenarien, verschiedene Teams |
| Disaster Recovery Tests | Halbjährlich | Hoch | Art. 24 Abs. 1 lit. k | Alle kritischen Services |
| Red Team Exercises | Jährlich / Halbjährlich | Hoch | Art. 24 Abs. 1 lit. b | Extern durchführen lassen |
| Blue Team Exercises | Jährlich | Mittel | Art. 24 Abs. 1 lit. b | Interne Teams |
| Purple Team Exercises | Jährlich | Mittel | Art. 24 Abs. 1 lit. b | Kollaborative Übungen |
| TLPT | Nicht verpflichtend | Niedrig | Art. 25 Abs. 1 | Nur bei kritischen Unternehmen |
Kritische Finanzunternehmen (nach DORA-Definition)
| Testart | Frequenz | Priorität | DORA-Referenz | Hinweise |
|---|---|---|---|---|
| Penetrationstests | Jährlich (verpflichtend), ggf. häufiger | Hoch | Art. 24 Abs. 1 | Extern + intern, umfassend |
| Threat-Led-Penetration-Testing (TLPT) | Mindestens alle 3 Jahre (verpflichtend) | Hoch | Art. 25 Abs. 1, Art. 25 Abs. 2 | Extern durch qualifizierte Anbieter |
| Vulnerability Scans | Kontinuierlich | Hoch | Art. 24 Abs. 1 lit. a | Automatisiert mit 24/7 Monitoring |
| Threat Modelling | Kontinuierlich / Bei neuen Systemen | Hoch | Art. 24 Abs. 1 lit. d | Integriert in SDLC, regelmäßige Reviews |
| Code Reviews | Kontinuierlich / Bei jeder Änderung | Hoch | Art. 24 Abs. 1 lit. c | Automatisiert + manuell, integriert in CI/CD |
| Open-Source-Analyse | Kontinuierlich | Hoch | Art. 24 Abs. 1 lit. e | Automatisierte Tools mit Alerting |
| Netzwerksicherheitsbewertung | Halbjährlich | Hoch | Art. 24 Abs. 1 lit. f | Extern durchführen lassen |
| Physische Sicherheitsanalyse | Jährlich | Hoch | Art. 24 Abs. 1 lit. g | Extern durchführen lassen |
| Lasttests / Performance Tests | Bei größeren Releases / Quartalsweise | Hoch | Art. 24 Abs. 1 lit. h | Automatisiert in CI/CD |
| Ende-zu-Ende-Tests | Bei größeren Änderungen / Quartalsweise | Hoch | Art. 24 Abs. 1 lit. i | Automatisiert wo möglich |
| Tabletop-Übungen | Monatlich / Quartalsweise | Hoch | Art. 24 Abs. 1 lit. j | Verschiedene Szenarien, verschiedene Teams |
| Disaster Recovery Tests | Quartalsweise / Halbjährlich | Hoch | Art. 24 Abs. 1 lit. k | Alle kritischen Services |
| Red Team Exercises | Halbjährlich / Jährlich | Hoch | Art. 24 Abs. 1 lit. b | Extern durchführen lassen |
| Blue Team Exercises | Halbjährlich / Jährlich | Hoch | Art. 24 Abs. 1 lit. b | Interne Teams |
| Purple Team Exercises | Halbjährlich / Jährlich | Hoch | Art. 24 Abs. 1 lit. b | Kollaborative Übungen |
Kritische Finanzunternehmen
Nach DORA sind kritische Finanzunternehmen solche, die systemrelevante Funktionen erfüllen oder eine erhebliche Marktstellung haben. Diese müssen zusätzlich zum jährlichen Penetrationstest mindestens alle 3 Jahre ein TLPT durchführen.
Risikobasierter Ansatz
Die tatsächliche Frequenz sollte risikobasiert festgelegt werden. Unternehmen mit höherem Risikoprofil sollten häufiger testen.
Kontinuierliche Verbesserung
Die Testfrequenzen sollten regelmäßig überprüft und an veränderte Risiken und Bedrohungen angepasst werden.
Testmanagement-Prozess
1. Planung
Festlegung von Testzielen, -umfang, -methoden und Zeitplan
2. Vorbereitung
Auswahl von Testanbietern, Definition von Testumgebungen und Scope
3. Durchführung
Ausführung der Tests durch interne Teams oder externe Anbieter
4. Analyse
Bewertung der Ergebnisse, Identifikation von Schwachstellen und Risiken
5. Remediation
Priorisierung und Umsetzung von Maßnahmen zur Behebung
6. Validierung
Überprüfung der Wirksamkeit der umgesetzten Maßnahmen
7. Dokumentation
Vollständige Dokumentation für Compliance und kontinuierliche Verbesserung
Testbereiche
Infrastruktur
- Netzwerksicherheit
- Server und Systeme
- Cloud-Infrastruktur
- Endgeräte
Anwendungen
- Web-Anwendungen
- Mobile Apps
- APIs
- Datenbanken
Prozesse
- Incident Response
- Access Management
- Change Management
- Backup & Recovery
Organisation
- Physische Sicherheit
- Social Engineering
- Mitarbeiter-Awareness
- Governance
Qualifikationsanforderungen für Testanbieter
Zertifizierungen
Relevante Zertifizierungen (z.B. OSCP, CEH, GPEN) und Branchenerfahrung
Unabhängigkeit
Externe, unabhängige Testanbieter für objektive Bewertungen
Branchenkenntnis
Verständnis der Finanzbranche und spezifischer regulatorischer Anforderungen
Methodik
Bewährte Testmethoden und -frameworks (OWASP, PTES, NIST)
Testdokumentation
DORA verlangt umfassende Dokumentation aller Tests. Ein Testbericht sollte enthalten:
Testplan
Detaillierte Beschreibung der Testziele, -methoden, -umfang und -zeitplan
Testdurchführung
Dokumentation der durchgeführten Tests, verwendeten Tools und Methoden
Ergebnisse
Detaillierte Auflistung aller identifizierten Schwachstellen mit Risikobewertung
Remediation Plan
Maßnahmenplan zur Behebung der identifizierten Schwachstellen mit Priorisierung
Follow-up
Validierung der umgesetzten Maßnahmen und Nachweis der Behebung
Zusammenhang mit anderen ISMS-Komponenten
- Risikomanagement: Testergebnisse liefern Input für Risikobewertungen und identifizieren neue Risiken
- Assetmanagement: Tests werden auf konkrete Assets durchgeführt, deren Schutzstatus validiert wird
- Incident Management: Red Team Exercises testen die Incident Response Fähigkeiten
- BCM: Tests überprüfen die Resilienz kritischer Systeme und Prozesse
- DORA: DORA definiert verbindliche Anforderungen an Testfrequenz und -umfang
- ISMS: Testmanagement ist integraler Bestandteil des kontinuierlichen Verbesserungsprozesses
Best Practices
Kontinuierliches Testing
Kombination aus regelmäßigen geplanten Tests und kontinuierlichem Monitoring
Risikobasierter Ansatz
Fokussierung auf kritische Assets und Systeme mit höchstem Risiko
Integration in SDLC
Integration von Sicherheitstests in den Software Development Lifecycle