CVD für NIS2 und DORA: ISO 27001-Nachweismatrix

Am Dienstag um 08:17 Uhr erhält das Sicherheitspostfach eine Nachricht von einem unabhängigen Sicherheitsforscher. Die Betreffzeile klingt ruhig, fast höflich: „Potenzielle Kontoübernahme in Ihrem Kundenportal“. Der Inhalt ist weniger beruhigend. Der Sicherheitsforscher behauptet, dass eine verkettete Schwachstelle in Ihrer SaaS-Anwendung es einem Mandanten ermöglicht, auf Rechnungsdatensätze eines anderen Mandanten zuzugreifen. Ein Proof of Concept ist beigefügt und mit Ihrem veröffentlichten PGP-Schlüssel verschlüsselt.

Für Maria, die neue CISO bei FinanTechSaaS, könnte der Zeitpunkt kaum schlechter sein. Ihr Unternehmen hat gerade einen großen Vertrag mit einer führenden EU-Bank unterzeichnet. Das Due-Diligence-Team des Kunden hat bereits eine „Richtlinie zur koordinierten Schwachstellenoffenlegung“ sowie Umsetzungsnachweise angefordert und dabei ausdrücklich auf NIS2 und DORA verwiesen. Das Unternehmen hat zwar eine security@-E-Mail-Adresse, diese wird jedoch von einem einzigen Entwickler überwacht. Es gibt kein formales Intake-Register, keinen definierten Validierungs-SLA, keinen Eskalationsweg zur Geschäftsleitung und keinen belastbaren Prüfpfad.

Drei Uhren beginnen gleichzeitig zu laufen.

Die erste Uhr ist operativ. Ist die Schwachstelle real? Ist sie in der Produktion ausnutzbar? Wird sie bereits aktiv missbraucht?

Die zweite Uhr ist regulatorisch. Wenn Kundendaten offengelegt wurden, beginnt die Bewertung einer GDPR-Verletzung des Schutzes personenbezogener Daten. Wenn die Leistungserbringung für eine wesentliche oder wichtige Einrichtung nach NIS2 betroffen ist, können Schwellenwerte für die Vorfallmeldung ausgelöst werden. Wenn das Unternehmen ein Finanzunternehmen oder ein IKT-Anbieter zur Unterstützung von Finanzdienstleistungen ist, können die DORA-Regeln zu Vorfallmanagement, Klassifizierung, Eskalation und Kundenkommunikation relevant werden.

Die dritte Uhr betrifft die Nachweisführung. Sechs Monate später kann ein ISO/IEC 27001:2022-Auditor, eine Finanzaufsichtsbehörde, ein Customer-Assurance-Team oder ein interner Prüfungsausschuss fragen: „Zeigen Sie uns, wie diese Schwachstelle behandelt wurde.“

An dieser Frage erkennen viele Organisationen, dass koordinierte Schwachstellenoffenlegung nicht nur ein Sicherheitspostfach ist. Sie ist ein Governance-System. Sie benötigt Richtlinienverantwortung, einen öffentlichen Meldekanal, einen Triage-Workflow, Abhilfe-SLAs, Lieferanteneskalation, Entscheidungslogik für Vorfälle, Datenschutzprüfung, Managementberichte und belastbare Nachweise.

Clarysec behandelt CVD als integriertes Kontrollmuster, nicht als eigenständiges Postfach. In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint erscheint die Schwachstellenbehandlung in der Phase „Controls in Action“, Step 19: Technological Controls I. Die Vorgabe ist klar: Organisationen sollten Schwachstellenfeststellungen nicht passiv archivieren, sondern triagieren, zuweisen und bis zum Abschluss nachverfolgen. Derselbe Maßstab gilt für externe Offenlegungen. Wenn Ihnen jemand mitteilt, wie Ihr Service ausfallen kann, lautet die eigentliche Frage: Können Sie nachweisen, dass Sie die Meldung erhalten, bewertet, priorisiert, behoben, kommuniziert und daraus gelernt haben?

Warum CVD unter NIS2 und DORA heute ein Thema für das Leitungsorgan ist

Jahrelang haben sicherheitsbewusste Organisationen ethische Hacker eingeladen, Schwachstellen zu melden, weil dies guter Praxis entsprach. Unter NIS2 und DORA ist diese Praxis Teil regulierter digitaler Resilienz geworden.

NIS2 gilt für viele mittelgroße und größere Einrichtungen in Sektoren mit hoher Kritikalität und in anderen kritischen Sektoren, darunter Anbieter digitaler Infrastruktur, Cloud-Computing-Dienste, Rechenzentrumsdienste, Managed Service Provider, Managed Security Service Provider sowie bestimmte digitale Anbieter wie Online-Marktplätze, Suchmaschinen und soziale Netzwerkplattformen. Unabhängig von der Größe kann NIS2 auch für Kategorien wie Vertrauensdiensteanbieter, DNS-Diensteanbieter, TLD-Registrierungsstellen und Anbieter öffentlicher elektronischer Kommunikationsnetze oder -dienste gelten.

NIS2 Article 21 verpflichtet wesentliche und wichtige Einrichtungen, angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen zum Management von Cybersicherheitsrisiken nach einem Allgefahrenansatz umzusetzen. Einer der Mindestbereiche ist die Sicherheit bei Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Schwachstellenbehandlung und Offenlegung. Dieselbe Grundlage umfasst auch den Umgang mit Vorfällen, Sicherheit der Lieferkette, Aufrechterhaltung des Geschäftsbetriebs, Zugriffskontrolle, Asset-Management, Schulung, Kryptografie und Verfahren zur Bewertung der Wirksamkeit von Maßnahmen.

NIS2 Article 20 macht außerdem die Rechenschaftspflicht des Managements ausdrücklich. Leitungsorgane müssen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen absolvieren. Für ein CVD-Programm bedeutet dies, dass das Leitungsorgan oder die obere Führungsebene den Meldekanal, das Vulnerability Response Team, Validierungsfristen, Erwartungen an Abhilfemaßnahmen, Lieferantenabhängigkeiten und Auslöser für Vorfallmeldungen verstehen muss.

DORA schafft ab dem 17. Januar 2025 ein sektorspezifisches Regime für Finanzunternehmen. Es umfasst IKT-Risikomanagement, Meldung IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch, IKT-Drittparteienrisiko, vertragliche Anforderungen, Aufsicht über kritische IKT-Drittanbieter und Zusammenarbeit mit Aufsichtsbehörden. Für Finanzunternehmen, die unter DORA fallen, hat DORA im Bereich IKT-Risikomanagement und Vorfallmeldung in der Regel Vorrang vor NIS2, weil es sich um den sektorspezifischen Rechtsakt der Union handelt. Die praktische Anforderung bleibt jedoch gleich: Finanzunternehmen und die sie unterstützenden IKT-Anbieter müssen einen strukturierten, dokumentierten und testbaren Prozess betreiben, um IKT-Schwächen zu identifizieren, zu analysieren, zu klassifizieren, zu eskalieren, zu beheben und daraus zu lernen.

Eine Schwachstellenmeldung kann als technische Feststellung beginnen, zu einem Sicherheitsereignis werden, zu einem Vorfall eskalieren, eine Bewertung einer GDPR-Verletzung des Schutzes personenbezogener Daten auslösen, Maßnahmen eines Lieferanten erfordern und später in der ISO/IEC 27001:2022-Erklärung zur Anwendbarkeit erscheinen. Deshalb sollte CVD als einheitliches Betriebsmodell über Sicherheit, Compliance, Engineering, Recht, Datenschutz, Beschaffung und Management hinweg gestaltet werden.

Die ISO 27001-Grundlage: von der Offenlegung zu ISMS-Nachweisen

ISO/IEC 27001:2022 liefert CISOs und Compliance-Verantwortlichen das Managementsystem, das CVD auditierbar macht.

Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, Anforderungen interessierter Parteien, ISMS-Grenzen und Abhängigkeiten von anderen Organisationen versteht. Hier fließen NIS2, DORA, GDPR, Kundenverträge, Lieferantenverpflichtungen und Zusagen zur Schwachstellenoffenlegung in das ISMS ein.

Die Klauseln 5.1 bis 5.3 schaffen Führungsverantwortung und Rechenschaftspflicht. Die oberste Leitung muss Informationssicherheit an der strategischen Ausrichtung ausrichten, Ressourcen bereitstellen, Verantwortlichkeiten zuweisen und sicherstellen, dass das ISMS die beabsichtigten Ergebnisse erreicht. Für CVD bedeutet dies, ein Vulnerability Response Team zu benennen, Befugnisse zur Annahme von Restrisiken zu definieren und Schwachstellen mit hoher Auswirkung an das Management zu eskalieren.

Die Klauseln 6.1.1 bis 6.1.3 liefern den Risikomechanismus. Die Organisation muss Risikokriterien definieren, Informationssicherheitsrisiken bewerten, Risikoverantwortliche zuweisen, Optionen zur Risikobehandlung auswählen, Maßnahmen gegen Anhang A abgleichen, eine Erklärung zur Anwendbarkeit erstellen und die Genehmigung für Restrisiken einholen. Die Klauseln 8.1 bis 8.3 verlangen anschließend operative Steuerung, geplante Änderungen, Steuerung extern bereitgestellter Prozesse, Risikobeurteilungen in geplanten Abständen oder nach wesentlichen Änderungen sowie Nachweise über Ergebnisse der Behandlung.

In Zenith Blueprint, Phase Risk Management, Step 13, wird die Erklärung zur Anwendbarkeit als mehr als eine Compliance-Tabelle beschrieben:

„Die SoA ist im Ergebnis ein Brückendokument: Sie verknüpft Ihre Risikobeurteilung/-behandlung mit den tatsächlich vorhandenen Maßnahmen.“
Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

Für koordinierte Schwachstellenoffenlegung sollte die SoA regulatorische Verpflichtungen, Geschäftsrisiken, Anhang-A-Maßnahmen, Richtlinienklauseln und operative Nachweise miteinander verbinden.

Ziel ist nicht, parallele Compliance-Silos zu schaffen. Die CVD-Richtlinie sollte ein gelenkter ISMS-Prozess sein, der gleichzeitig ISO/IEC 27001:2022-Zertifizierung, NIS2-Compliance, DORA-Bereitschaft, Customer Assurance und Sicherheitsbetrieb unterstützt.

Die Richtlinienbasis: Was Ihre CVD-Richtlinie festlegen muss

Die erste sichtbare Kontrolle ist der öffentliche Offenlegungskanal. Sicherheitsforscher, Kunden, Lieferanten und Partner müssen wissen, wo sie Schwachstellen melden und wie sie sensible Nachweise schützen können.

Clarysecs Richtlinie zur koordinierten Schwachstellenoffenlegung Richtlinie zur koordinierten Schwachstellenoffenlegung stellt die Unternehmensgrundlage bereit:

„Öffentliche Offenlegungskanäle: Die Organisation muss einen klaren Kanal zur Meldung von Schwachstellen unterhalten, z. B. eine dedizierte Sicherheitskontakt-E-Mail-Adresse (beispielsweise security@company.com) oder ein Webformular. Diese Informationen müssen auf der Sicherheitsseite der Unternehmenswebsite zusammen mit dem öffentlichen PGP-Schlüssel der Organisation veröffentlicht werden, um verschlüsselte Einreichungen zu ermöglichen.“
Quelle: Richtlinie zur koordinierten Schwachstellenoffenlegung, Umsetzungsanforderungen, Klausel 6.1

Diese Klausel behebt ein häufiges Auditversagen. Viele Organisationen behaupten, Meldungen anzunehmen, aber der Meldeweg ist schwer auffindbar, unverschlüsselt oder dem falschen Team zugeordnet. Ein reifer Kanal ist öffentlich, sicher, überwacht und einer verantwortlichen Funktion zugewiesen.

Die nächste Kontrolle ist Antwortdisziplin. Eine kritische Meldung, auf die Schweigen folgt, erzeugt Offenlegungsrisiko, Reputationsrisiko und Ausnutzungsrisiko. Die Richtlinie zur koordinierten Schwachstellenoffenlegung setzt konkrete Erwartungen an Bestätigung und Validierung:

„Triage und Bestätigung: Nach Eingang einer Meldung muss das VRT diese erfassen und dem Meldenden innerhalb von 2 Geschäftstagen eine Bestätigung mit einer Referenz zur Nachverfolgung senden. Das VRT muss eine vorläufige Schweregradbewertung durchführen, beispielsweise mittels CVSS-Scoring, und das Problem einschließlich Unterstützung durch IT- und Entwicklungsteams, sofern erforderlich, innerhalb eines Zielzeitraums von 5 Geschäftstagen validieren. Kritische Schwachstellen, etwa solche, die Remotecodeausführung oder eine schwerwiegende Datenpanne ermöglichen, müssen beschleunigt behandelt werden.“
Quelle: Richtlinie zur koordinierten Schwachstellenoffenlegung, Umsetzungsanforderungen, Klausel 6.4

Diese Formulierung schafft unmittelbare Nachweispunkte: Eingangszeit, Bestätigungszeit, Referenz zur Nachverfolgung, vorläufiger Schweregrad, Validierungsergebnis und Entscheidung zur beschleunigten Behandlung.

Für KMU verwendet Clarysec dieselbe Logik mit verhältnismäßiger Umsetzung. Die Richtlinie zu Anforderungen an die Anwendungssicherheit-sme Richtlinie zu Anforderungen an die Anwendungssicherheit - KMU verlangt von Organisationen:

„Verpflichtungen zur Offenlegung von Schwachstellen, Reaktionszeiten und Patch-Pflichten festzulegen.“
Quelle: Richtlinie zu Anforderungen an die Anwendungssicherheit-sme, Governance-Anforderungen, Klausel 5.3.2

Sie benötigen kein großes Product-Security-Team, um rechenschaftsfähig zu sein. Sie benötigen ausdrücklich festgelegte Verpflichtungen, realistische Fristen, benannte Verantwortliche und Nachweise, dass der Prozess funktioniert.

Der CVD-Intake-Workflow: von der Forscher-E-Mail zur Entscheidungsaufzeichnung

Ein guter Intake-Workflow ist einfach genug, um unter Druck ausgeführt zu werden, und vollständig genug, um einen Auditor zufriedenzustellen. Er sollte mit einem dedizierten Kanal wie security@[company], einem Webformular oder einer veröffentlichten security.txt-Datei beginnen. Der Einreichungsweg sollte verschlüsselte Nachweise, betroffenes Produkt oder betroffenen Endpoint, Reproduktionsschritte, Kontaktdaten des Meldenden, bevorzugten Offenlegungszeitpunkt sowie Hinweise auf Datenexposition oder aktive Ausnutzung ermöglichen.

Nach Eingang sollte das Vulnerability Response Team einen Datensatz in einem GRC-Werkzeug, einer Ticketing-Plattform, einem Schwachstellenmanagementsystem oder einem gelenkten Register anlegen. Das Werkzeug ist weniger wichtig als Konsistenz und Nachweisqualität.

Der Workflow sollte anschließend sieben operative Schritte durchlaufen.

1. Intake: Die Meldung geht über den öffentlichen Kanal ein und wird automatisch oder manuell protokolliert.
2. Bestätigung: Das VRT antwortet innerhalb von 2 Geschäftstagen und weist eine Referenz zur Nachverfolgung zu.
3. Validierung: Das technische Team reproduziert das Problem, bestätigt betroffene Systeme und führt eine vorläufige Schweregradbewertung durch.
4. Ereignisbewertung: Das VRT entscheidet, ob die Schwachstelle nur eine Schwäche, ein Informationssicherheitsereignis oder ein Vorfall ist.
5. Eskalation: Hohe oder kritische Probleme werden nach Bedarf an Systemverantwortliche, CISO, Datenschutz, Recht, Lieferanten und Management weitergeleitet.
6. Abhilfe: Das verantwortliche Team setzt eine Korrektur, Risikominderung, kompensierende Kontrolle oder vorübergehende Beschränkung um.
7. Abschluss: Das VRT verifiziert die Korrektur, kommuniziert mit dem Meldenden, aktualisiert die Nachweisakte und dokumentiert gewonnene Erkenntnisse.

Clarysec ordnet diesen operativen Schritt über Zenith Controls: The Cross-Compliance Guide Zenith Controls der ISO/IEC 27002:2022-Maßnahme A.5.25, Bewertung und Entscheidung über Informationssicherheitsereignisse, sowie der Maßnahme A.8.8, Management technischer Schwachstellen, zu. Für A.5.25 erläutert Zenith Controls, dass die Ereignisbewertung die Triage-Funktion zwischen rohen Monitoring-Alarmen und formalem Umgang mit Vorfällen ist und Logdaten, Schwellenwerte und Entscheidungskriterien zur Eskalationsentscheidung nutzt. Für A.8.8 verbindet Zenith Controls technisches Schwachstellenmanagement mit Schutz vor Schadsoftware, Konfigurationsmanagement, Änderungsmanagement, Endgerätesicherheit, Bedrohungsinformationen, Überwachung, sicherer Entwicklung, Ereignisbewertung und Incident Response.

Eine Passage aus Zenith Controls ist besonders nützlich, wenn aktive Ausnutzung vermutet wird:

„Bedrohungsinformationen zeigen auf, welche Schwachstellen aktiv ausgenutzt werden, und steuern damit die Priorisierung von Patches.“
Quelle: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022-Maßnahme 8.8, Bezug zu Maßnahme 5.7 Threat Intelligence Zenith Controls

Dies ist ein wichtiger Governance-Punkt. Schweregrad ist nicht nur CVSS. Eine mittel bewertete Schwachstelle, die aktiv gegen Ihren Sektor ausgenutzt wird, kann Vorrang vor einem theoretisch kritischen Problem auf einem nicht exponierten Testsystem haben.

Wann eine Schwachstelle zu einem Vorfall wird

Nicht jede Schwachstellenmeldung ist ein Vorfall. Ein fehlender Sicherheitsheader in einer Staging-Umgebung ist nicht dasselbe wie eine ausgenutzte Autorisierungsumgehung, die Kundenrechnungen offenlegt. Jede glaubwürdige Schwachstellenmeldung sollte jedoch eine Vorfallsentscheidung durchlaufen.

NIS2 Article 23 verlangt, dass wesentliche und wichtige Einrichtungen ihrem CSIRT oder der zuständigen Behörde unverzüglich Vorfälle melden, die erhebliche Auswirkungen auf die Erbringung ihrer Dienste haben. Ein erheblicher Vorfall ist ein Vorfall, der schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder der andere Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann. Die Meldefolge umfasst eine Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung, eine Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichte auf Anforderung und einen Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung.

DORA Articles 17 to 20 verpflichten Finanzunternehmen, IKT-bezogene Vorfälle und erhebliche Cyberbedrohungen zu erkennen, zu managen, aufzuzeichnen, zu klassifizieren, zu eskalieren, zu melden und zu kommunizieren. Schwerwiegende IKT-bezogene Vorfälle müssen an die obere Führungsebene und das Leitungsorgan eskaliert werden. Kundenkommunikation kann erforderlich sein, wenn finanzielle Interessen betroffen sind.

Für KMU muss die Meldekultur ebenso klar sein. Clarysecs Incident-Response-Richtlinie-sme Incident-Response-Richtlinie - KMU legt fest:

„Mitarbeitende müssen jede verdächtige Aktivität oder jeden bestätigten Vorfall an incident@[company] oder mündlich an den General Manager oder IT-Dienstleister melden.“
Quelle: Incident-Response-Richtlinie-sme, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1

In Zenith Blueprint, Phase Controls in Action, Step 16: People Controls II, ist das Prinzip noch einfacher:

„Im Zweifel melden.“
Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Controls in Action, Step 16: People Controls II (A.6.5 bis A.6.8)

Dieser Satz sollte für Entwickler, Support-Teams, Lieferantenmanager, Datenschutzverantwortliche, Führungskräfte und ausgelagerte Anbieter gelten. Eine Schwachstelle, die Vertraulichkeit, Integrität, Verfügbarkeit, Kundenvertrauen, regulatorische Meldung oder Finanzabläufe betreffen kann, sollte erfasst und bewertet werden – und nicht informell im Chat behandelt werden.

Abhilfe, Patching und kompensierende Kontrollen

Sobald eine Schwachstelle validiert ist, muss sie behandelt werden. Die Behandlung sollte risikobasiert, nachweisgestützt und zeitlich begrenzt erfolgen.

Die Richtlinie zur koordinierten Schwachstellenoffenlegung legt die Unternehmenserwartung fest:

„Abhilfeplan: Für alle bestätigten Schwachstellen muss ein Abhilfe- oder Minderungsplan erstellt werden. Die Umsetzung der Korrektur muss nach Schweregrad priorisiert werden. Kritische Schwachstellen müssen beispielsweise, sofern praktikabel, innerhalb von 14 Tagen oder bei erkannter aktiver Ausnutzung früher behoben oder gemindert werden; Probleme mit geringerem Schweregrad müssen innerhalb eines angemessenen Zeitraums bearbeitet werden. Wenn eine vollständige Korrektur verzögert ist, müssen kompensierende Kontrollen oder vorübergehende Minderungsmaßnahmen umgesetzt werden, z. B. die Deaktivierung verwundbarer Funktionalität oder eine verstärkte Überwachung.“
Quelle: Richtlinie zur koordinierten Schwachstellenoffenlegung, Umsetzungsanforderungen, Klausel 6.6

Für die Patch-Disziplin in KMU legt die Richtlinie zum Schwachstellen- und Patch-Management-sme Richtlinie zum Schwachstellen- und Patch-Management - KMU fest:

„Kritische Patches müssen innerhalb von 3 Tagen nach Veröffentlichung eingespielt werden, insbesondere für internetseitig erreichbare Systeme“
Quelle: Richtlinie zum Schwachstellen- und Patch-Management-sme, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.1.1

Diese Fristen widersprechen sich nicht. Ein Hersteller-Patch für ein internetseitig erreichbares System kann eine sehr schnelle Bereitstellung erfordern. Eine Produktschwachstelle, die Codeänderungen, Regressionstests, Kundenkoordination und gestaffelte Freigabe erfordert, kann einen Abhilfeplan mit zwischenzeitlichen Minderungsmaßnahmen benötigen. Entscheidend ist, dass die Entscheidung dokumentiert, einem Risikoverantwortlichen zugeordnet und genehmigt wird, wenn Restrisiko verbleibt.

Ein praktischer Fallablauf sieht so aus:

1. Ein Sicherheitsforscher meldet eine Autorisierungsumgehung in der Kundenabrechnungs-API.
2. Das VRT protokolliert CVD-2026-014 mit Zeitstempel und bestätigt den Eingang innerhalb von 2 Geschäftstagen.
3. Product Security validiert den Fehler innerhalb von 24 Stunden und weist wegen mandantenübergreifendem Datenzugriff den Schweregrad Hoch zu.
4. Datenschutz führt eine GDPR-Verletzungsbewertung durch, weil Rechnungsdatensätze personenbezogene Daten enthalten können.
5. Der Incident Manager eröffnet eine Ereignisbewertung nach ISO/IEC 27002:2022-Maßnahme A.5.25.
6. Der Systemverantwortliche deaktiviert den verwundbaren Endpoint über ein temporäres Feature Flag.
7. Engineering erstellt einen Hotfix nach ISO/IEC 27002:2022-Maßnahme A.8.32, Änderungsmanagement.
8. Überwachungsregeln für Ausnutzungsindikatoren werden ergänzt und mit A.8.15, Protokollierung, sowie A.8.16, Überwachungstätigkeiten, verknüpft.
9. Der CISO informiert die obere Führungsebene, weil das Problem ein hohes Risiko darstellt.
10. Das VRT koordiniert Nachtests und Offenlegungszeitpunkt mit dem Sicherheitsforscher.
11. Der Risikoverantwortliche genehmigt den Abschluss erst nach Verifikationstests und Prüfung der Kundenauswirkungen.
12. SoA, Risikoregister, Ticket, Logs, Managementbenachrichtigung und gewonnene Erkenntnisse werden aktualisiert.

Das ist der Unterschied zwischen „wir haben gepatcht“ und „wir können nachweisen, dass wir es gesteuert haben“.

Lieferanten- und Cloud-Abhängigkeiten: der versteckte Fehlerpunkt

Viele CVD-Fehler sind in Wirklichkeit Lieferantenfehler. Die Schwachstelle kann eine SaaS-Komponente, einen Cloud-Service, einen Managed Security Provider, ein Zahlungsgateway, einen Authentifizierungsbroker, eine Open-Source-Bibliothek, ein ausgelagertes Entwicklungsteam oder einen Unterauftragnehmer betreffen.

NIS2 Article 21 verlangt Sicherheit der Lieferkette, einschließlich Beziehungen zu direkten Lieferanten und Dienstleistern. Maßnahmen für die Lieferkette sollten Lieferantenschwachstellen, Produktqualität, Cybersicherheitspraktiken und Verfahren zur sicheren Entwicklung berücksichtigen.

DORA Articles 28 to 30 gehen für Finanzunternehmen weiter. Sie verlangen, dass IKT-Drittparteienrisiken als Teil des IKT-Risikomanagementrahmens gesteuert werden, einschließlich Registern für IKT-Serviceverträge, Unterscheidung kritischer oder wichtiger Funktionen, Due Diligence vor Vertragsschluss, vertraglicher Sicherheitsanforderungen, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Auditrechten, Kündigungsrechten und Exit-Strategien. Finanzunternehmen bleiben auch bei Nutzung von IKT-Drittanbietern vollständig für die DORA-Compliance verantwortlich.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit-sme Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU enthält eine einfache Eskalationsregel:

„Muss den GM unverzüglich über jede Sicherheitsverletzung, Änderung oder jeden Vorfall benachrichtigen“
Quelle: Richtlinie zur Lieferanten- und Drittparteiensicherheit-sme, Rollen und Verantwortlichkeiten, Klausel 4.4.3

Für Lieferantenverträge im Unternehmensumfeld empfiehlt Zenith Blueprint, Phase Controls in Action, Step 23, Vertraulichkeitspflichten, Verantwortlichkeiten für Zugriffskontrolle, technische und organisatorische Maßnahmen, Fristen zur Vorfallmeldung, Auditrechte, Kontrollen für Unterauftragnehmer und Regelungen zum Vertragsende aufzunehmen. Es heißt dort:

„Entscheidend ist, dass sie existieren und von beiden Parteien verstanden und akzeptiert werden.“
Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Controls in Action, Step 23: Organizational controls (5.19 bis 5.37)

Die Lieferantenbereitschaft für CVD sollte folgende Fragen beantworten:

• Veröffentlicht der Lieferant einen Meldekanal für Schwachstellen?
• Sind Fristen zur Schwachstellenbenachrichtigung im Vertrag definiert?
• Werden kritische Lieferantenschwachstellen unverzüglich gemeldet?
• Sind kundenrelevante Schwächen mit Pflichten zur Unterstützung bei Vorfällen verknüpft?
• Kann der Lieferant Nachweise zur Abhilfe oder Sicherheitshinweise bereitstellen?
• Werden Schwachstellenverpflichtungen an Unterauftragnehmer weitergegeben?
• Gibt es eine Exit-Strategie, wenn die Abhilfe unzureichend ist?

Hier laufen NIS2, DORA und ISO/IEC 27001:2022 zusammen. Lieferantenseitiges Schwachstellenmanagement ist kein Beschaffungshäkchen. Es ist Teil der operationalen Resilienz.

Nachweiszuordnung für ISO 27001, NIS2, DORA, GDPR und COBIT

Die stärksten CVD-Programme denken zuerst in Nachweisen. Sie gehen davon aus, dass jede wesentliche Meldung später von internem Audit, Zertifizierungsauditoren, Regulierungsbehörden, Kunden, Versicherern oder einem Risikoausschuss des Leitungsorgans geprüft werden kann.

Clarysecs P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme P33 – Richtlinie zur Audit- und Compliance-Überwachung - KMU erfasst ein Detail, das viele Teams übersehen:

„Metadaten (z. B. wer sie wann und aus welchem System erhoben hat) müssen dokumentiert werden.“
Quelle: P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.3

Ein Screenshot eines gepatchten Servers ist schwach, wenn niemand weiß, wer ihn wann, von welchem System und mit welcher Zuordnung zur Schwachstelle erstellt hat. Ein Ticket mit Zeitstempeln, Scanner-Ausgabe, Pull Request, Änderungsgenehmigung, Bereitstellungsprotokollen, Monitoring-Abfrage, Bestätigung des Nachtests und Metadaten ist deutlich belastbarer.

Eine detailliertere Rückverfolgbarkeitsmatrix hilft bei Kunden-Due-Diligence und internem Audit.

Unterschiedliche Auditoren prüfen denselben Prozess aus unterschiedlichen Perspektiven.

Ein ISO/IEC 27001:2022-Auditor beginnt beim ISMS. Er wird fragen, ob Verpflichtungen zur Schwachstellenoffenlegung in den Anforderungen interessierter Parteien enthalten sind, ob Risiken konsistent bewertet werden, ob Maßnahmen in der SoA erscheinen, ob operative Nachweise vorhanden sind und ob das Management Trends und überfällige Punkte bewertet.

Ein DORA- oder Finanzdienstleistungsprüfer konzentriert sich auf operationale Resilienz. Er wird Integration in das IKT-Risikomanagement, Vorfallklassifizierung, Eskalation an die obere Führungsebene, Kundenkommunikation, Abhängigkeiten von Drittparteien, Tests und gewonnene Erkenntnisse prüfen. Wenn die Schwachstelle eine kritische oder wichtige Funktion betrifft, wird er eine enge Verknüpfung zwischen technischem Ticket, Geschäftsauswirkung, Auswirkungen auf die Aufrechterhaltung des Geschäftsbetriebs und Lieferantenverpflichtungen erwarten.

Ein GDPR-Prüfer konzentriert sich auf personenbezogene Daten. Waren personenbezogene Daten betroffen? Gab es unbefugten Zugriff, Verlust, Veränderung oder Offenlegung? Waren die Rollen von Verantwortlichem und Auftragsverarbeiter klar? Wurde die Meldeschwelle für die Verletzung bewertet? Waren Schutzmaßnahmen wie Verschlüsselung, Zugriffskontrolle, Protokollierung und Minimierung relevant?

Ein COBIT 2019- oder ISACA-Auditor konzentriert sich auf Governance, Rechenschaftspflicht, Leistung und Assurance. Er wird nach definierter Verantwortung, Kennzahlen, Eskalation, Kontrollzielen, Managementaufsicht und Nachverfolgung von Ausnahmen suchen. Eine überfällige kritische Schwachstelle ist nicht nur ein technisches Problem. Sie ist ein Governance-Problem, sofern sie nicht formal eskaliert und risikobasiert akzeptiert wurde.

Ein NIST-orientierter Assessor denkt in den Kategorien Identify, Protect, Detect, Respond und Recover. Er erwartet Asset-Verantwortung, Schwachstellenidentifikation, Priorisierung, schützende Änderung, Erkennung von Ausnutzung, Koordination der Reaktion und Validierung der Wiederherstellung.

Der Vorteil eines integrierten CVD-Modells besteht darin, dass dieselbe Nachweisstruktur alle diese Prüfungen unterstützen kann.

Der monatliche Kontrollkreislauf: Kennzahlen, die das Management nutzen kann

CVD endet nicht, wenn das Ticket geschlossen wird. Die Richtlinie zur koordinierten Schwachstellenoffenlegung verlangt eine laufende Überprüfung des Protokolls:

„Das VRT muss ein Schwachstellenoffenlegungsprotokoll führen, das jede Meldung vom Eingang bis zum Abschluss nachverfolgt. Das Protokoll muss monatlich überprüft werden, um eine fristgerechte Bearbeitung offener Punkte sicherzustellen. Überfällige Punkte müssen eskaliert werden.“
Quelle: Richtlinie zur koordinierten Schwachstellenoffenlegung, Überwachung und Audit, Klausel 9.1

Diese monatliche Überprüfung macht Schwachstellenoffenlegung zu Governance, die dem Leitungsorgan vorgelegt werden kann. Das Management benötigt nicht jedes technische Detail. Es benötigt Trends, Exposition, Rechenschaftspflicht und überfällige Risiken.

In einer reifen Clarysec-Umsetzung speist diese monatliche Protokollüberprüfung das Risikoregister, die Erklärung zur Anwendbarkeit, den Backlog für sichere Entwicklung, Lieferantenüberprüfungen, gewonnene Erkenntnisse aus Vorfällen, den internen Auditplan und das Management-Reporting-Paket.

Bauen Sie den Prozess auf, bevor die ernste Meldung eintrifft

Der schlechteste Zeitpunkt, koordinierte Schwachstellenoffenlegung zu entwerfen, ist nachdem ein Sicherheitsforscher Ihre Schwäche öffentlich gemacht oder ein kritischer Bankkunde das Onboarding gestoppt hat. NIS2, DORA, GDPR, ISO/IEC 27001:2022, resilienzorientierte Erwartungen nach NIST und COBIT 2019-Governance weisen alle in dieselbe Richtung: Schwachstellenoffenlegung muss geplant, verantwortet, getestet, nachgewiesen und verbessert werden.

Beginnen Sie mit diesen fünf Maßnahmen:

1. Übernehmen oder passen Sie die Richtlinie zur koordinierten Schwachstellenoffenlegung an.
2. Bauen Sie den Intake- und Triage-Workflow mit Zenith Blueprint auf, insbesondere Step 13 für SoA-Rückverfolgbarkeit, Step 16 für Meldekultur, Step 19 für technisches Schwachstellenmanagement und Step 23 für Lieferantenvereinbarungen.
3. Ordnen Sie den Workflow über Zenith Controls zu, mit Fokus auf ISO/IEC 27002:2022-Maßnahmen A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 und A.8.32.
4. Ergänzen Sie KMU-taugliche Klauseln aus Incident-Response-Richtlinie-sme, Richtlinie zum Schwachstellen- und Patch-Management-sme, Richtlinie zur Lieferanten- und Drittparteiensicherheit-sme, Richtlinie zu Anforderungen an die Anwendungssicherheit-sme und P33 – Richtlinie zur Audit- und Compliance-Überwachung-sme, wo Verhältnismäßigkeit erforderlich ist.
5. Führen Sie eine Tabletop-Übung durch, die eine Meldung eines Sicherheitsforschers mit Auswirkungen auf personenbezogene Daten und eine von einem Lieferanten gehostete Komponente simuliert; testen Sie dabei Bestätigung, Triage, Vorfallklassifizierung, Patching, Kundenkommunikation, Nachweiserfassung und Managementeskalation.

Clarysec kann Ihnen helfen, daraus eine funktionsfähige CVD-Richtlinie, ein Intake-Register, eine ISO/IEC 27001:2022-Nachweismatrix, einen NIS2- und DORA-Entscheidungsbaum, ein Modell zur Lieferanteneskalation und ein auditbereites Kontrollpaket zu erstellen. Das Ziel ist einfach: Wenn die nächste Schwachstellenmeldung eintrifft, sollte Ihr Team nicht improvisieren. Es sollte mit Vertrauen, Nachweisen und Kontrolle handeln.