Wissensraum · Deep Dive 12 von 22
Vulnerability Management & Patch-Zyklen unter DORA
Warum klassische Patch-Modelle nicht mehr ausreichen
Kontextbasiertes Patching · CVSS vs. Business Impact · Zero-Day-Response · Supply-Chain-Schwachstellen · Governance der Priorisierung
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.
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) Rein kalenderbasiertes Patchen ohne risikobasierte Eskalation
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
Ausgangslage
Ein Zahlungsdienstleister nutzt eine weit verbreitete Open-Source-Bibliothek. Eine Schwachstelle wird öffentlich bekannt; kurz darauf stellt der Hersteller ein Sicherheitsupdate bereit.
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
Mögliche aufsichtsrechtliche Nachfragen bzw. Anforderung einer Ursachen- und Maßnahmenanalyse
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
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 führen dazu, dass Patches nicht-inventarisierte Systeme gar nicht erreichen.
CVSS-Scores sind irreführend ohne Kontext. Eine technisch kritische Schwachstelle in einem tatsächlich isolierten, nicht betriebenen System kann ein deutlich geringeres unmittelbares Risiko darstellen. Eine niedrig bewertete Lücke in einer Komponente mit Zugriff auf Zahlungsverkehr kann umgekehrt kontextbedingt kritisch sein. Kontextlose Metadaten führen zu falsch priorisierten Repairs.
Supply-Chain-Sicherheit ist der versteckte Hebel. Ein erheblicher Teil der Angriffsfläche moderner Software entsteht durch Dritt- und Open-Source-Komponenten. Wer nur eigene Code-Schwachstellen patcht und Open-Source-Komponenten ignoriert, arbeitet mit offenen Augen blind.
Patching ist Mittel, nicht Ziel. Es geht nicht darum, hundert Patches eingespielt zu haben. Für Aufsicht und interne Governance ist wesentlich, welche relevanten Schwachstellen in kritischen Systemen offen sind, welches Risiko sie erzeugen, warum sie noch nicht behoben wurden und welche Zwischenmaßnahmen bestehen.