Zum Inhalt springen
Resilience Platform DORA · MaRisk · ISO 27001

DORA Kapitel IV / Methodik

Testentscheidungs-Algorithmus.

Systematische Entscheidungsunterstützung für risikobasierte Testauswahl: Eingabeparameter, Scoring-Modell, Entscheidungsregeln und Testempfehlungen.

Disclaimer: Dieser Testentscheidungs-Algorithmus stellt eine originäre Methodik zur systematischen Priorisierung von Resilienztests dar. Die Gewichtungen und Regeln basieren auf betrieblichen Erfahrungen und regulatorischen Anforderungen, ersetzen aber keine individuelle Fachbeurteilung durch qualifizierte Risikomanager oder CISOs.

Management-Zusammenfassung

  • Der Testentscheidungs-Algorithmus ermöglicht risikobasierte Priorisierung und Auswahl von Resilienztests.
  • Systematische Bewertung von Eingabeparametern (Schutzbedarfsklasse, KWF-Status, regulatorische Klassifizierung) führt zu objektiven Testempfehlungen.
  • Algorithmus unterstützt Managemententscheidungen und dokumentiert die Begründung für Testscope und -frequenz.
  • Abgestimmt auf DORA Kapitel IV, TIBER-EU und EBA-Leitlinien zu Resilienztests.

Algorithmus-Übersicht

Systematische Entscheidungsunterstützung für die Auswahl und Priorisierung von Resilienztests basierend auf objektiven Kriterien.

Algorithmus-Typ

Multi-Kriterien-Entscheidungsmodell mit gewichteter Scoring-Methode.

Ausgabe

Priorisierte Testempfehlung mit Begründung und regulatorischer Einordnung.

Eingabeparameter

Klassifikation des zu testenden Assets oder der Funktion

Schutzbedarfsklasse (kF) Gewichtung: 30%
1

Normal

Nicht-kritische Assets, Standardbetrieb

2

Hoch

Wichtige Funktionen, erhoehter Schutzbedarf

3

Sehr Hoch

Kritische Funktionen, intensiver Schutzbedarf

4

Exkursionsschutz

Höchste Kritikalität, maximaler Schutzbedarf

Kritisch/wichtige Funktion (kwF) Gewichtung: 25%

Ob das Asset eine kritisch/wichtige Funktion unterstützt

Asset-Typ Gewichtung: 15%
Infrastruktur (Netzwerk, Server, Storage)
Anwendung (Web, Mobile, API)
Endgerät (Workstation, Mobile)
Cloud-Service (SaaS, PaaS, IaaS)
Drittparteien-Service
Datenbank/Dateirepository

Risikofaktoren für Testpriorisierung (10 Faktoren)

  • Schutzbedarf (kF 1-4): Höchster Schutzbedarf = höchste Testpriorität (Gewichtung 20%)
  • kwF-Unterstützung: Kritische/wichtige Funktionen erhöhen Priorität (Gewichtung 15%)
  • Asset-Typ: Risikobewertung nach Asset-Kategorie (Gewichtung 10%)
  • Testfälligkeit: Überfälligkeit erhöht Priorität (Gewichtung 10%)
  • Incidents: Kürzliche Major/Extreme Incidents triggern sofortige Tests (Gewichtung 10%)
  • Bedrohungsexposition: Internet-facing Assets erhalten höhere Priorität (Gewichtung 10%)
  • Änderungsaktivität: Major Changes erfordern erneute Validierung (Gewichtung 5%)
  • Drittparteienbezug: Ausgelagerte Assets erfordern Nachweisanforderung statt Tests (Gewichtung 5%)
  • Risikoprofil: Kritisches Risikoprofil beschleunigt Testentscheidung (Gewichtung 10%)
  • Offene Findings: Ungelöste kritische Findings erhöhen Dringlichkeit (Gewichtung 5%)

Scoring-Matrix

Gesamt-Score = kF×15 + kwF(+20) + Asset-Typ-Bonus + Exposure(+20) + Legacy(+20) + Incident(+40) + Overdue(+30) + Drittparteien(+15/+25) + Risikoprofil(+20/+35) + MajorChange(+25) + OffeneFindings(+10/+15/+20)

Critical

100-295

SLA: 14 Tage

High

60-99

SLA: 30 Tage

Medium

20-59

SLA: 60 Tage

Low

0-19

SLA: 90 Tage

Testauswahl-Regeln

  • Kritische kwF mit kürzlichem Major-Incident erfordern umfassende Widerstandsfähigkeitsprüfung durch TLPT und Red-Team. (Priorität: critical, Zeitplan: Sofort (< 14 Tage))
  • [PFLICHT] CTPP-Beteiligung bei Significant Entity verpflichtet zu TLPT gemäß DORA Art. 26. (Priorität: high, Zeitplan: Jährlich (TLPT-Zyklus))
  • Internet-facing Applikationen mit kritischer Bedrohungslage benötigen intensive technische Tests. (Priorität: high, Zeitplan: 3-monatiger Zyklus)
  • Major Changes an kritischen Systemen erfordern erneute Validierung der Sicherheitskonfiguration. (Priorität: high, Zeitplan: Innerhalb 4 Wochen nach Go-Live)
  • Drittparteien mit höherem Schutzbedarf müssen auf Resilienz und Continuity geprüft werden. (Priorität: medium, Zeitplan: Jährlich)
  • [PFLICHT] Überfällige Tests bei wichtigen/kritischen Assets müssen nachgeholt werden (3-Jahres-Regel). (Priorität: high, Zeitplan: Sofort (< 30 Tage))
  • Bevorstehende Prüfungen erfordern aktualisierte Testnachweise für Audit-Demonstration. (Priorität: medium, Zeitplan: 4 Wochen vor Audit)
  • Nicht-kritische, nicht-kwf-Assets benötigen nur Basis-Schwachstellenüberprüfung. (Priorität: low, Zeitplan: Jährlich oder halbjährlich)
  • Vollständig ausgelagerte Assets erfordern Nachweisanforderung an Dienstleister statt eigener Tests. Dienstleister-Scanberichte, SOC-/ISO-Zertifikate und Fragebögen einholen. (Priorität: high, Zeitplan: Nachweisanforderung quartalsweise (GSV) bzw. gemäß PRT-Zyklus)
  • Kritisches Risikoprofil mit hohen offenen Findings erfordert sofortige Ad-hoc-Tests und Resilience-Board-Entscheidung. (Priorität: critical, Zeitplan: Sofort (< 14 Tage))
  • Teilausgelagerte kritische Assets: Kombination aus internen Tests und Dienstleister-Nachweisen. (Priorität: high, Zeitplan: Alle 2 Jahre (PRT P2))

Testpakete

Baseline package All entities, all kF levels

Grundlegende Testkombination für alle Assets

vulnerability scanning
Standard package kF >= 2, wichtige Systeme

Standard-Testpaket für wichtige Funktionen

vulnerability scanning security configuration review application security testing
Advanced package kF >= 3, kritische Systeme

Erweitertes Testpaket für kritische Funktionen

vulnerability scanning penetration testing application security testing security configuration review business continuity testing
Comprehensive package kF = 4, Significant Entities, CTPPs

Umfassendes Testpaket für höchste Kritikalität

vulnerability scanning threat led penetration testing red team exercise application security testing disaster recovery testing purple team exercise
Third party package Drittparteien-Services, kF >= 2

Drittparteien-spezifisches Testpaket

third party resilience testing business continuity testing incident response testing
Post incident package Nach Major/Extreme Incidents

Nach-Incident Validierungspaket

penetration testing incident response testing red team exercise
Provider evidence package Fully outsourced, kF >= 2

Dienstleister-Nachweispaket für vollständig ausgelagerte Assets

vulnerability scanning third party resilience testing questionnaire self assessment

Entscheidungsbaum (vereinfacht)

  • START: Ist das Asset Teil einer kwF?
  • JA → Betriebsart prüfen: vollständig ausgelagert? → Nachweisanforderung an Dienstleister
  • JA → kF-Level prüfen: kF=4 + CTPP → TLPT mandatory (jährlich)
  • JA → kF=3 + kürzlicher Incident → Post-Incident-Package (sofort)
  • JA → kF=2 + Major Change → Config-Review + Standard-Package
  • NEIN → kF=1 → Baseline-Package (jährlich)
  • ALLE: Offene Findings + kritisches Risikoprofil → Ad-hoc Test + Resilience Board
  • ALLE Pfade: Internet-facing → Penetrationstest hinzufügen

Dynamische Frequenzanpassung

  • BESCHLEUNIGUNG: Major Incident → Frequenz × 1.5 (6 Monate)
  • BESCHLEUNIGUNG: Kritische CVE (9.0+) → Sofortiger Ad-hoc-Test
  • BESCHLEUNIGUNG: Kritisches Risikoprofil → Testvorzug innerhalb 14 Tagen
  • BESCHLEUNIGUNG: Offene kritische Findings → Retest + Resilience Board
  • BESCHLEUNIGUNG: APT-Kampagne gegen Branche → +1 zusätzlicher Zyklus
  • VERLANGSAMUNG: 24 Monate Clean-History → Frequenz × 0.8 (max. 1 Stufe)
  • AUSNAHME: TLPT darf weder beschleunigt noch verlangsamt werden

Beispiel-Szenarien

EX-001

Online-Banking-Portal (kwF)

Critical (110)

Inputs

kF=4, kwF=Ja, Exposure=critical

Empfohlene Tests

threat-led-penetration-testing, penetration-testing +2 weitere

Kritisches kwF-Asset mit höchstem Schutzbedarf und Internet-Exposure. Trotz guter Historie ist maximale Testabdeckung erforderlich.

EX-002

Internes HR-System (nicht-kwf)

Medium (30)

Inputs

kF=2, kwF=Nein, Exposure=low

Empfohlene Tests

vulnerability-scanning, application-security-testing

Nicht-kwf-Asset mit niedriger Bedrohungsexposition und guter Testhistorie. Basis-Testabdeckung ausreichend.

EX-003

Cloud-Payment-Service nach Ransomware-Vorfall

Critical (245)

Inputs

kF=4, kwF=Ja, Exposure=critical

Empfohlene Tests

threat-led-penetration-testing, red-team-exercise +3 weitere

Kritisches kwF-Cloud-Service mit kürzlichem Major Incident und CTPP-Beteiligung. Maximale Dringlichkeit, alle verfügbaren Testarten einsetzen.

Erfolgskriterien des Algorithmus

  • Algorithmus-Adoptionsrate: >= 80% — Prozent der Testentscheidungen, die auf Algorithmus-Empfehlungen basieren
  • Test-Risiko-Alignment: >= 0.7 (Pearson-Korrelation) — Korrelation zwischen Algorithmus-Priorität und tatsächlichem Risiko (gemessen an Incidents/Findings)
  • Overdue-Test-Rate: < 5% — Prozent der Tests, die trotz Algorithmus-Empfehlung überfällig sind
  • False-Positive-Rate: < 10% — Prozent der "Critical" Empfehlungen (Score ≥ 100), die sich als nicht kritisch erwiesen
  • Faktorabdeckung: >= 95% — Anteil der Testentscheidungen, die alle 10 Entscheidungsfaktoren berücksichtigen
  • Schwellenwert-Kalibrierung: < 20% Anpassungsrate signalisiert stabile Modellgüte — Prozentsatz der Assets, deren Prioritätseinstufung bei der jährlichen Kalibrierung angepasst wird

Umsetzungshinweise

  • Integration: Anbindung an IKT-Risikoinventar für automatische kF-Ermittlung
  • Integration: Betriebsart (eigener Betrieb / ausgelagert) aus Auslagerungsdokumentation
  • Integration: Übertragung in Testplanungstool für automatisierte Planung
  • Integration: Anbindung an Finding Register für offene Findings
  • Trigger: Automatische Empfehlungs-Generierung bei Incidents
  • Automatisierung: Scoring-Berechnung vollautomatisch, Komplexe Fälle manuell validieren
  • Review: Halbjährliche Überprüfung der Gewichtungen und Schwellenwerte

Algorithmus-Kern

Eingaben

kF-Level, kwF-Status, Asset-Typ, Testfälligkeit, Incidents, Bedrohung, Änderung, Drittparteien, Risikoprofil, Offene Findings (10 Faktoren)

Verarbeitung

Gewichtetes Scoring + Entscheidungsregeln

Ausgabe

Priorisierter Score, Testempfehlungen, Zeitplan

ISO 27001 Verbindung

Der Testentscheidungs-Algorithmus operationalisiert DORA-Anforderungen in ein praktisches Entscheidungsinstrument.

  • A.5.30: Sicherheitsprüfung der Informationstechnologie
  • A.5.31: Bewertung von Informationssicherheitsvorfällen
  • A.5.35: Unabhängige Überprüfung der Informationssicherheit
  • DORA Art. 24: Risikobasiertes Testprogramm
  • DORA Art. 26: Threat-Led Penetration Testing

ISO/IEC 27001:2022 dient als Kontrollanker und Management-System-Referenz. Die Verbindung zu ISO 27001 unterstützt integrierte Resilienz- und Sicherheitsprogramme.

Reifegrad

  1. 1 Initial

    Ad-hoc-Ansätze, keine formalen Prozesse

  2. 2 Defined

    Formale Prozesse definiert, aber nicht durchgängig umgesetzt

  3. 3 Implemented

    Prozesse vollständig umgesetzt und dokumentiert

  4. 4 Monitored

    Prozesse werden überwacht und gemessen

  5. 5 Optimized

    Kontinuierliche Verbesserung und Anpassung