Wissensraum · Deep Dive 16 von 27

Vulnerability Management & Patch-Zyklen unter DORA

Warum klassische Patch-Modelle nicht mehr ausreichen

16 Min Vulnerability Management
Deep Dive 16

Was dieser Deep Dive Ihnen zeigt

Wie Vulnerability Management unter DORA einzuordnen ist, welche Anforderungen an Identifikation, Klassifikation und Behebung bestehen – und warum Patching allein nicht ausreicht.

RegulierungDORA
ThemaSchwachstellenmanagement, Patch-Priorisierung, Zero-Day-Response
KernfrageWann ist Vulnerability Management unter DORA ausreichend?
RelevanzIT-Operations, Security, Development, Management
DORA-ArtikelArt. 9, 10 DORA – ICT-Sicherheit, Schutzmaßnahmen

Vulnerability Management wurde lange als rein technisches Thema verstanden. Unter DORA entwickelt es sich zu einem strukturellen Risikothema, das Governance, Technik und Compliance miteinander verbindet.

Ziel ist nicht möglichst schnelles Patchen um jeden Preis, sondern nachvollziehbare, risikobasierte Entscheidungen, die kritische Funktionen schützen.

1. Reifegrade im Patch- und Vulnerability-Management

A) Kalenderbasiertes Patchen (veraltet)

Feste monatliche oder quartalsmäßige Patch-Zyklen

Keine kontextbezogene Risikobewertung

Verzögerte Reaktion auf Zero-Day-Schwachstellen

Einordnung

Ein ausschließlich kalenderbasierter Ansatz ist für kritische Risiken unter DORA in der Regel nicht ausreichend.

B) Risikobasiertes Patchen (weiterentwickelt, aber oft unvollständig)

Priorisierung anhand von CVSS-Werten (standardisiertes Schwachstellen-Scoring)

Beschleunigte Behandlung hoch bewerteter Schwachstellen

Operative Abstimmung zwischen Teams

Einordnung

CVSS-Scores bilden technische Schwere ab, nicht das tatsächliche Risiko im jeweiligen Unternehmenskontext.

C) Kontextbasiertes Patchen (DORA-orientierter Ansatz)

Die Kritikalität einer Schwachstelle ergibt sich aus ihrem Kontext – insbesondere wenn sie:

Kritische Systeme oder Funktionen betrifft

Öffentlich exponierte oder extern erreichbare Services berührt

Identitäts- und Berechtigungslogiken beeinflusst

Datenflüsse in Kernprozessen gefährdet

Externe Angriffsflächen vergrößert

Entscheidend ist der Zusammenhang – nicht allein der Score.

2. Welche Anforderungen sich aus DORA ergeben

Schwachstellen systematisch erkennen, bewerten und priorisieren

Klare, abgestimmte Prozesse zwischen Security, Operations und Produktteams

Nachvollziehbare Entscheidungen und deren Umsetzung dokumentieren

Verzahnung mit Incident-Management- und Reporting-Prozessen

Drittanbieter- und Open-Source-Komponenten berücksichtigen

Eindeutige Verantwortlichkeiten und Eskalationswege

3. Fallstudie

Fallstudie · Der Patch, der zu spät kam

Ausgangslage

Ein Zahlungsdienstleister nutzt eine weit verbreitete Open-Source-Bibliothek. Eine Zero-Day-Schwachstelle wird öffentlich bekannt.

Was passiert

Das Security-Team stuft die Schwachstelle als kritisch ein

Produkt- und Entwicklungsteams sehen keinen unmittelbaren Handlungsbedarf

Release-Zyklen sind träge

Tests sind nicht vorbereitet

Der Patch wird erst nach mehreren Wochen eingespielt.

Konsequenzen

Ausnutzung der Schwachstelle durch Angreifer

Systemkompromittierung

Potenziell meldepflichtiger Vorfall

Vertrauensverlust bei Kunden

Forderung einer Root-Cause-Analyse durch die Aufsicht

Was ein wirksamer Prozess geleistet hätte

Sofortige Kontextanalyse: Welche kritischen Funktionen sind betroffen?

Definierte Zero-Day-Response-Prozesse

Vorbereitete Test- und Staging-Umgebungen

Klare Eskalations- und Entscheidungswege

Praxis-Impuls

Unter DORA ist Vulnerability Management kein reaktiver IT-Prozess mehr. Es ist ein Führungs-, Architektur- und Governance-Thema. Stellen Sie für jede neue Schwachstelle die Frage: Welche unserer kritischen Systeme sind betroffen – direkt oder über Abhängigkeiten? Erst dann entscheiden.

Was bleibt

1

Vulnerability Management ist kein Patching-Prozess. Es fängt viel früher an: Asset-Inventar, Klassifikation der Kritikalität, dann Identifikation, Priorisierung, Behebung. Fehler in frühen Schritten lassen Sie Patches auf nicht-inventarisierten Systemen spielen.

2

CVSS-Scores sind irreführend ohne Kontext. Eine kritische Schwachstelle in einem unbenutzten System ist unkritisch. Eine niedrig bewertete Lücke in einer Komponente mit Zugriff auf Zahlungsverkehr ist kritisch. Kontextlose Metadaten führen zu falsch priorisierten Repairs.

3

Supply-Chain-Sicherheit ist der versteckte Hebel. Die meisten Vulnerabilities kommen nicht aus Ihrer eigenen Software, sondern aus Dependencies. Wer nur eigene Code-Schwachstellen patcht und Open-Source-Komponenten ignoriert, arbeitet mit offenen Augen blind.

4

Patching ist Mittel, nicht Ziel. DORA interessiert nicht, dass Sie hundert Patches eingespielt haben. DORA interessiert: Wie viele identifizierte Schwachstellen in Ihren kritischen Systemen sind derzeit offen? Und warum noch?

← Wissensraum