EU-CRA-Zeiträume für Sicherheitsunterstützung mit ISO 27001 steuern

Es ist 08:20 Uhr an einem Dienstag, und der Produktverantwortliche eines vernetzten B2B-Gateways erhält eine Nachricht eines regulierten Kunden: „Bitte bestätigen Sie den Zeitraum für Sicherheitsunterstützung für Firmware-Version 4.6, das SLA für die Reaktion auf Schwachstellen und ob das Gerät während unseres fünfjährigen Servicevertrags weiterhin für Sicherheitsaktualisierungen berechtigt bleibt.“

Um 09:00 Uhr hat der Einkauf einen DORA-Due-Diligence-Fragebogen weitergeleitet. Um 10:15 Uhr fragt die Rechtsabteilung, ob der beworbene Supportzeitraum mit den Kundenverträgen übereinstimmt. Um 11:00 Uhr wird der CISO in eine NIS2-Prüfung des Lieferantenrisikos einbezogen, weil das Produkt von einem Managed-Service-Provider in der EU eingesetzt wird. Nach dem Mittagessen fragt das Datenschutzteam, ob eine nicht mehr unterstützte API-Bibliothek im Produkt die Sicherheit personenbezogener Daten unter GDPR beeinträchtigen könnte.

Die unbequeme Wahrheit wird schnell sichtbar. Das Unternehmen hat eine Roadmap, einen Patch-Prozess, einen Release-Kalender und ein Kunden-Supportportal, aber keine gesteuerten Nachweise zum Zeitraum der Sicherheitsunterstützung.

Diese Lücke ist relevant. Nach dem EU Cyber Resilience Act ist der Zeitraum für Sicherheitsunterstützung nicht nur eine Produktkennzeichnung. Er ist eine Lebenszykluszusage, die Schwachstellenbehandlung, Verfügbarkeit von Aktualisierungen, Management von Lieferantenabhängigkeiten, Kundenkommunikation, vertragliche Zusicherungen und Überwachung nach dem Inverkehrbringen beeinflusst. Für SaaS-Anbieter, Gerätehersteller, Softwareanbieter, Cloud-Anbieter und IKT-Dienstleister wird der Supportzeitraum zu einem Compliance-Gegenstand, den Auditoren und regulierte Kunden prüfen werden.

Die praxisgerechte Antwort ist keine weitere isolierte Compliance-Tabelle. Die Antwort besteht darin, den Zeitraum für Sicherheitsunterstützung innerhalb eines Informationssicherheits-Managementsystems nach ISO/IEC 27001:2022 zu steuern und dieselben Nachweise anschließend NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT-orientierten Auditerwartungen zuzuordnen.

Das ist das Clarysec-Betriebsmodell: das ISMS als Nachweismotor nutzen, durchsetzbare Richtlinien zur Definition von Verantwortlichkeiten einsetzen, mit Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Nachvollziehbarkeit aufbauen und Zenith Controls: The Cross-Compliance Guide Zenith Controls als Kompass für übergreifende Compliance verwenden.

Warum der Zeitraum für Sicherheitsunterstützung jetzt ein Auditobjekt ist

Ein Zeitraum für Sicherheitsunterstützung beantwortet eine einfache Frage: Wie lange stellt der Hersteller Sicherheitsaktualisierungen, Schwachstellenbehebung, Hinweise zur Risikominderung und zugehörigen Kundensupport für ein Produkt oder eine Produktversion bereit?

In der Praxis hängt diese Antwort von vielen beweglichen Teilen ab:

• Produktarchitektur und Wartbarkeit
• Unterstützung für Drittkomponenten und Open-Source-Abhängigkeiten
• Zusagen von Lieferanten und Cloud-Services
• Prozesse für die Entgegennahme von Schwachstellenmeldungen, Triage, Abhilfemaßnahmen und Offenlegung
• Release Engineering und Testkapazität
• Kundenvertragsbedingungen und regulatorische Verpflichtungen
• Incident Response und Meldewege gegenüber Leistungsempfängern
• Nachweisaufbewahrung und Genehmigungsaufzeichnungen

Wenn ein Hersteller fünf Jahre Sicherheitsunterstützung zusagt, eine kritische kryptografische Bibliothek aber nach drei Jahren nicht mehr unterstützt wird, wird der Supportzeitraum zu einer Risikoentscheidung. Wenn ein Kunde ein Finanzunternehmen im Anwendungsbereich von DORA ist, wird derselbe Supportzeitraum Teil der Absicherung von IKT-Drittparteienrisiken. Wenn das Produkt personenbezogene Daten verarbeitet, kann nicht mehr unterstützte Software Teil der Rechenschaftspflicht für die Sicherheit der Verarbeitung nach GDPR werden. Wenn das Produkt eine wesentliche oder wichtige Einrichtung unter NIS2 unterstützt, wird Lebenszyklussicherheit zu einem Thema der Sicherheit der Lieferkette.

NIS2 macht diese Governance-Perspektive ausdrücklich. Article 20 verlangt, dass Leitungsorgane wesentlicher und wichtiger Einrichtungen Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen, deren Umsetzung überwachen und Schulungen erhalten. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Umgang mit Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, sichere Entwicklung und Wartung, Schwachstellenbehandlung und Offenlegung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugriffskontrolle, Asset-Management und Authentifizierung. Article 23 ergänzt gestufte Meldepflichten für erhebliche Sicherheitsvorfälle.

DORA erzeugt einen ähnlichen Druck für Finanzunternehmen. DORA verlangt IKT-Risikomanagement, Tests der digitalen operationalen Resilienz, Vorfallmanagement und Governance für IKT-Drittparteienrisiken. DORA Article 28 behandelt Grundsätze des IKT-Drittparteienrisikomanagements, und Article 30 verlangt schriftliche vertragliche Vereinbarungen mit klaren Leistungsbeschreibungen, Sicherheitsmaßnahmen, Unterstützung bei Vorfällen, Auditrechten, Kündigungsrechten und Exit-Regelungen.

GDPR ergänzt die Datenschutzebene. Wenn das Produkt personenbezogene Daten verarbeitet, benötigen Verantwortliche und Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen nach Article 32, vertragliche Klarheit nach Article 28 sowie die Fähigkeit zur Bewertung von Datenschutzverletzungen und zur Meldung nach Articles 33 und 34.

Deshalb muss der CRA-Zeitraum für Sicherheitsunterstützung wie eine Kontrollfamilie im ISMS gesteuert werden und darf nicht als isoliertes Feld im Produktmanagement behandelt werden.

ISO 27001 als Kontrollrückgrat für CRA-Zeiträume der Sicherheitsunterstützung

ISO/IEC 27001:2022 ist wertvoll, weil die Norm skalierbar, risikobasiert und managementsystemorientiert ist. Sie verlangt, dass die Organisation Kontext, interessierte Parteien, Geltungsbereich und zusammenwirkende Prozesse definiert und anschließend gesetzliche, regulatorische und vertragliche Anforderungen in Risikobeurteilung, Risikobehandlung, operative Kontrollen und Nachweise übersetzt ISO/IEC 27001:2022.

Für die Governance von Zeiträumen der Sicherheitsunterstützung bedeutet dies, dass die Organisation:

1. Produkte, Versionen, Module, Cloud-Services und Abhängigkeiten im Geltungsbereich identifiziert.
2. Interessierte Parteien identifiziert, darunter Kunden, Aufsichtsbehörden, Distributoren, Importeure, Integratoren, Auftragsverarbeiter, Unterauftragsverarbeiter, Incident-Response-Partner und Lieferanten.
3. Gesetzliche, regulatorische und vertragliche Supportverpflichtungen erfasst.
4. Risiken beurteilt, die die Erfüllung von Supportzusagen verhindern könnten.
5. Kontrollen für Schwachstellenmanagement, sichere Entwicklung, Lieferantensicherheit, Vorfallmanagement, Aufrechterhaltung des Geschäftsbetriebs, Datenschutz und dokumentierte Information auswählt.
6. Hinweise in der Statement of Applicability erstellt, die begründen, warum Kontrollen anwendbar sind.
7. Den Supportzeitraum überprüft, wenn sich Architektur, Lieferantenabhängigkeiten, Bedrohungsexposition oder Kundenzusagen ändern.

Zenith Controls identifiziert drei thematisch einschlägige Kontrollen aus ISO/IEC 27002:2022 als zentrale Anker für dieses Governance-Problem: 5.31 Gesetzliche, satzungsmäßige, regulatorische und vertragliche Anforderungen, 8.8 Management technischer Schwachstellen und 8.25 Sicherer Entwicklungslebenszyklus. Sie sind nicht die einzigen beteiligten Kontrollen, bilden aber das Governance-Rückgrat.

Entscheidend ist die Nachvollziehbarkeit. Ein Produkt-Supportzeitraum sollte von der Verpflichtung zum Risikoszenario, vom Risikoszenario zu ausgewählten Kontrollen, von Kontrollen zu Richtlinienanforderungen und von Richtlinienanforderungen zu Nachweisen nachvollziehbar sein.

Zenith Blueprint, Phase Risikomanagement, Schritt 13, beschreibt diese Nachvollziehbarkeitsdisziplin direkt:

„Regelwerke querverweisen: Wenn bestimmte Kontrollen ausdrücklich umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkung) oder in den SoA-Hinweisen vermerken.“

Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Risikomanagement, Schritt 13: Risikobehandlungsplanung und Statement of Applicability Zenith Blueprint

Für einen CRA-Zeitraum für Sicherheitsunterstützung sollte die Statement of Applicability nicht lediglich sagen: „Schwachstellenmanagement ist anwendbar.“ Sie sollte erklären, dass Schwachstellenmanagement anwendbar ist, weil das Unternehmen CRA-Lebenszykluszusagen, NIS2-Erwartungen an sichere Entwicklung und Lieferketten, DORA-Anforderungen aus Kunden-Due-Diligence, GDPR-Sicherheitsverpflichtungen bei Verarbeitung personenbezogener Daten und vertragliche Supportzusagen hat.

Von der Supportzusage zum gesteuerten Lebenszyklus

Ein vom Hersteller definierter Zeitraum für Sicherheitsunterstützung sollte sechs Governance-Prüfungen bestehen.

Erstens muss er definiert sein. Die Organisation benötigt eine standardisierte Taxonomie, etwa aktiver Support, ausschließlich sicherheitsbezogener Support, erweiterter Support, eingeschränkter Support und nicht unterstützt. Jeder Status sollte Verfügbarkeit von Aktualisierungen, Schwachstellenbehandlung, Kundenkommunikation und Eskalationswege erläutern.

Zweitens muss er risikobeurteilt sein. Fünf Jahre Support für ein cloudverwaltetes SaaS-Produkt mit kontrollierten Aktualisierungskanälen unterscheiden sich von fünf Jahren für ein eingebettetes Gerät mit Feldeinschränkungen, Abhängigkeiten von Drittanbieter-Chips und kundenseitig verwalteten Bereitstellungsfenstern.

Drittens muss er genehmigt sein. Produkt, Sicherheit, Recht, Datenschutz, Kundensupport und rechenschaftspflichtiges Management sollten den Basiszeitraum und Ausnahmen genehmigen.

Viertens muss er kommuniziert sein. Kunden sollten Supportbeginn, Supportende, Aktualisierungsmethode, Meldekanal für Schwachstellen, Erwartungen an Abhilfemaßnahmen, Folgen des Supportendes und verfügbare Verlängerungsoptionen verstehen.

Fünftens muss er überwacht werden. Abhängigkeiten ändern sich. Lieferanten stellen Bibliotheken ein. Schwachstellen treten auf. Kundenumgebungen verändern sich. Governance für Supportzeiträume muss Lebenszyklusüberwachung von Komponenten, Lieferantenüberprüfung, Schwachstellen-Feeds, Patch-Protokolle, Release-Tests und Erkenntnisse aus Vorfällen umfassen.

Sechstens muss er nachgewiesen werden. Wenn ein Auditor, eine Aufsichtsbehörde oder ein regulierter Kunde Nachweise verlangt, sollte die Organisation Compliance-Register, Produkt-Supportregister, Risikobeurteilung, SoA-Zuordnung, Schwachstellenregister, Patch-Aufzeichnungen, Lieferantenüberprüfungen, Release-Freigaben und Kundenmitteilungen vorlegen können.

Clarysec-Richtlinien machen dies praktikabel. Die Enterprise Richtlinie zur rechtlichen und regulatorischen Compliance Richtlinie zur rechtlichen und regulatorischen Compliance verlangt:

„Alle gesetzlichen und regulatorischen Verpflichtungen müssen innerhalb des Informationssicherheits-Managementsystems (ISMS) konkreten Richtlinien, Kontrollen und Verantwortlichen zugeordnet werden.“

Quelle: Richtlinie zur rechtlichen und regulatorischen Compliance, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.2.1 Richtlinie zur rechtlichen und regulatorischen Compliance

Für KMU beginnt die entsprechende Disziplin mit einem einfacheren Register. Die SME Richtlinie zur rechtlichen und regulatorischen Compliance - SME Richtlinie zur rechtlichen und regulatorischen Compliance - SME lautet:

„Der GM muss ein einfaches, strukturiertes Compliance-Register führen, das Folgendes auflistet:“

Quelle: Richtlinie zur rechtlichen und regulatorischen Compliance - SME, Governance-Anforderungen, Klausel 5.1.1 Richtlinie zur rechtlichen und regulatorischen Compliance - SME

Eine Supportzeitraum-Zusage sollte im Compliance-Register stehen, wenn sie durch Gesetz, Kundenvertrag, sektorale Regulierung oder Erwartung eines regulierten Kunden getrieben ist. Sie sollte nicht nur in Release Notes oder Marketingtexten existieren.

Ein CRA-Supportzeitraum-Register in einem Workshop aufbauen

Stellen Sie sich einen SaaS-Anbieter vor, der ein vernetztes Analysegerät an EU-Logistikdienstleister und Kunden aus dem Finanzsektor verkauft. Das Produkt umfasst einen eingebetteten Agenten, eine Cloud-API, eine mobile Administrations-App und mehrere Open-Source-Bibliotheken. Der Vertrieb möchte für jede wesentliche Geräteversion fünf Jahre Sicherheitsunterstützung zusagen.

Der CISO kann einen fokussierten Workshop mit Produkt, Engineering, Recht, Datenschutz und Lieferantenmanagement durchführen.

Schritt 1: Supportzeitraum-Register erstellen

Erstellen Sie eine Zeile je Produktversion und erfassen Sie:

• Produkt und Version
• Release-Datum
• Supportbeginn
• Standard-Enddatum der Sicherheitsunterstützung
• Option für erweiterten Support
• Bereitstellungsmethode für Aktualisierungen
• Offenlegungskanal für Schwachstellen
• Zielvorgabe für kritische Patches
• Rolle bei der Datenverarbeitung, etwa Verantwortlicher, Auftragsverarbeiter oder beides
• Kritische Lieferanten und Komponenten
• Betroffene Kundensektoren
• Risikoverantwortlicher
• Genehmigungsdatum
• Nachweisablage

Dieses Register wird zu dokumentierter Information im ISMS. Zenith Blueprint, Phase ISMS-Grundlagen und Führung, Schritt 6, beschreibt die Erwartung an die Dokumentenlenkung:

„Dokumente sollten ordnungsgemäß gekennzeichnet sein (ein Titel, gegebenenfalls eine Dokumentennummer oder eindeutige Kennung, ein Autor), ein geeignetes Format haben und vor der Verwendung auf Angemessenheit überprüft und genehmigt werden.“

Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase ISMS-Grundlagen und Führung, Schritt 6: Dokumentierte Information und Aufbau der ISMS-Bibliothek Zenith Blueprint

Clarysecs Enterprise PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy wendet ähnliche Nachweisgrundsätze auf Datenschutzdokumentation an:

„[Alle] Der Privacy Lead / PIMS Manager MUSS vor der Veröffentlichung dokumentierter PIMS-Informationen in REG12 eine Dokumentenkennung, einen Verantwortlichen, eine Versionsnummer, einen Genehmigungsstatus, ein Wirksamkeitsdatum und ein Prüfdatum zuweisen.“

Quelle: PIMS Documented Information Evidence Management Policy, Erstellung, Genehmigung, Versionierung und Veröffentlichung, Klausel 4.2.1 PIMS Documented Information Evidence Management Policy

Auch wenn das Supportzeitraum-Register nicht standardmäßig ein Datenschutzdokument ist, gilt dieselbe Disziplin: Verantwortlicher, Version, Genehmigung, Wirksamkeitsdatum und Prüfdatum.

Schritt 2: Supportzusagen mit Risikobehandlung verknüpfen

Erstellen Sie für jede Produktversion Risikoszenarien wie:

• Eine kritische Schwachstelle wird in einer unterstützten Version entdeckt, aber Engineering-Kapazität ist nicht verfügbar.
• Eine Drittkomponente wird vor Ende des erklärten Zeitraums für Sicherheitsunterstützung nicht mehr unterstützt.
• Ein Lieferant ändert Hosting-Standort oder Unterauftragnehmer und beeinträchtigt die Bereitstellung von Aktualisierungen.
• Eine Schwachstelle betrifft personenbezogene Daten und löst eine Bewertung einer Datenschutzverletzung aus.
• Ein regulierter Finanzkunde verlangt Nachweise zur Resilienz von IKT-Drittparteien.

ISO/IEC 27001:2022 clauses 6.1.1 to 6.1.3 stellen den Planungsmechanismus bereit: Risiken identifizieren, Eintrittswahrscheinlichkeit und Auswirkungen beurteilen, Risikoverantwortliche zuweisen, Behandlungen auswählen, ausgewählte Kontrollen mit Annex A abgleichen, die Statement of Applicability erstellen und die Genehmigung des Restrisikos einholen.

Für das Risiko „nicht unterstützte Komponente vor Supportende“ sollte der Risikodatensatz die ISO/IEC 27002:2022-Kontrollen 5.31, 8.8 und 8.25 enthalten, außerdem Lieferantenkontrollen wie 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette und 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten.

Schritt 3: Regeln für Schwachstellen- und Patch-Nachweise festlegen

Ein Supportzeitraum ist nur glaubwürdig, wenn das Schwachstellenmanagement während dieses Zeitraums funktioniert.

Die SME Richtlinie zum Schwachstellen- und Patch-Management - SME Richtlinie zum Schwachstellen- und Patch-Management - SME legt für dringende Exposition eine strenge Anforderung 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 Richtlinie zum Schwachstellen- und Patch-Management - SME

Sie verlangt außerdem auditfähige Aufzeichnungen:

„Ein Patch-Protokoll muss geführt und im Rahmen von Audits und Incident-Response-Aktivitäten überprüft werden.“

Quelle: Richtlinie zum Schwachstellen- und Patch-Management - SME, Governance-Anforderungen, Klausel 5.4.1 Richtlinie zum Schwachstellen- und Patch-Management - SME

Für Unternehmensumgebungen verlangt die Enterprise Richtlinie zum Schwachstellen- und Patch-Management Richtlinie zum Schwachstellen- und Patch-Management:

„Ein zentrales Register für das Schwachstellenmanagement muss vom Security Operations Team geführt und monatlich durch den CISO oder eine delegierte Stelle überprüft werden.“

Quelle: Richtlinie zum Schwachstellen- und Patch-Management, Governance-Anforderungen, Klausel 5.1 Richtlinie zum Schwachstellen- und Patch-Management

Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 19, erläutert die operative Erwartung hinter ISO/IEC 27002:2022 control 8.8:

„Bleiben Sie über neue Sicherheitsfehler (über Herstellerwarnmeldungen, CVE-Feeds usw.) für Ihre Software und Hardware informiert. Beurteilen Sie, welche davon relevant sind (nutzen wir diese Software? wie kritisch ist der Fehler?) und spielen Sie zeitnah Korrekturen ein oder setzen Sie Risikominderungen um.“

Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Kontrollen in der Praxis, Schritt 19: Technische Maßnahmen I Zenith Blueprint

Jede unterstützte Produktversion benötigt eine Nachweiskette für Schwachstellen: Entgegennahme, Relevanzanalyse, Schweregrad, betroffene Versionen, Abhilfeplan, Fix-Release, Hinweise zur Risikominderung, Kundenkommunikation und Abschlussfreigabe.

Schritt 4: Sichere Entwicklung mit der Supportdauer verknüpfen

Sicherheitsunterstützung beginnt vor dem Release. Sie hängt von Entwicklungspraktiken ab, die das Produkt wartbar machen.

Die SME Richtlinie für sichere Softwareentwicklung - SME Richtlinie für sichere Softwareentwicklung - SME lautet:

„Komponenten müssen regelmäßig aktualisiert werden, wenn Sicherheits-Patches veröffentlicht werden. Wenn eine kritische Schwachstelle identifiziert wird, muss die Komponente unverzüglich aktualisiert oder ersetzt werden.“

Quelle: Richtlinie für sichere Softwareentwicklung - SME, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.6.3 Richtlinie für sichere Softwareentwicklung - SME

Die SME Richtlinie zu Anforderungen an die Anwendungssicherheit - SME Richtlinie zu Anforderungen an die Anwendungssicherheit - SME verlangt, dass Verträge und Anforderungen:

„Verpflichtungen zur Offenlegung von Schwachstellen, Reaktionszeiten und Patch-Pflichten festlegen.“

Quelle: Richtlinie zu Anforderungen an die Anwendungssicherheit - SME, Governance-Anforderungen, Klausel 5.3.2 Richtlinie zu Anforderungen an die Anwendungssicherheit - SME

Wenn das Unternehmen Support bis 2031 zusagt, muss die Architektur wartbare Aktualisierungen, den Austausch von Abhängigkeiten, sichere Build-Pipelines, Regressionstests und Notfall-Releases unterstützen. ISO/IEC 27002:2022-Kontrollen für sichere Entwicklung, Sicherheitsarchitektur, sichere Programmierung, Sicherheitsprüfung, ausgelagerte Entwicklung, Trennung von Umgebungen und Änderungsmanagement werden zu Voraussetzungen für den Supportzeitraum.

Ein Nachweissatz für CRA, NIS2, DORA und GDPR

Dieselben Nachweise zum Supportzeitraum können unterschiedliche regulatorische Gespräche bedienen, aber jedes Rahmenwerk stellt die Frage anders.

Lieferantenabhängigkeiten sind häufig der Punkt, an dem Supportzusagen scheitern. Die Enterprise Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten verlangt:

„Register für Lieferantenabhängigkeiten: Das VMO muss ein aktuelles Register aller kritischen Lieferanten führen, einschließlich Angaben zu bereitgestellten Services/Produkten, ob der Lieferant eine Single-Source-Beziehung darstellt, verfügbaren alternativen Lieferanten oder Ersetzbarkeit, aktuellen Vertragsbedingungen sowie einer Bewertung der Auswirkungen, falls der Lieferant ausfällt oder kompromittiert wird.“

Quelle: Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten, Umsetzungsanforderungen, Klausel 6.1 Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten

Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 23, warnt, dass Auditoren Lieferantenvereinbarungen und Nachweise zur Lieferantenüberwachung prüfen werden:

„Auditoren werden Stichproben von Verträgen oder Servicevereinbarungen prüfen. Sie suchen nach ausdrücklichen Klauseln zur Informationssicherheit, etwa Fristen zur Meldung von Verstößen, Zugriffsbeschränkungen, Datenverarbeitungspflichten, Verschlüsselungsanforderungen oder Auditrechten.“

Quelle: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Phase Kontrollen in der Praxis, Schritt 23: Organisatorische Maßnahmen Zenith Blueprint

Für DORA-Kunden ist dies entscheidend. Verträge über IKT-Dienste, die kritische oder wichtige Funktionen unterstützen, benötigen klare Leistungsbeschreibungen, Bedingungen für Unterbeauftragung, Sicherheitsmaßnahmen, Unterstützung bei Vorfällen, Audit- und Inspektionsrechte, Kündigungsrechte und Übergangsregelungen. Ein Lieferant, der diese Zusagen nicht unterstützen kann, kann den Hersteller daran hindern, eine glaubwürdige Zusage zum Zeitraum für Sicherheitsunterstützung abzugeben.

Kontrollzuordnung für auditfähige Governance von Supportzeiträumen

Diese Kontrollzuordnung ermöglicht Sicherheits-, Rechts-, Produkt- und Vertriebsteams eine gemeinsame Sprache. Das Supportzeitraum-Register ist nicht nur CRA-Nachweis. Es ist Lieferantensicherheit für NIS2, Drittparteienabsicherung für DORA, Unterstützung der Sicherheit der Verarbeitung für GDPR und ein Governance-Artefakt für die ISO 27001-Zertifizierung.

Der Datenschutzaspekt: Wenn nicht unterstützt zu unsicher wird

Governance für Zeiträume der Sicherheitsunterstützung ist nicht nur ein Cybersicherheitsthema. Wenn das Produkt personenbezogene Daten speichert, überträgt oder verarbeitet, kann nicht mehr unterstützte Software zu einem Datenschutzrisiko werden.

GDPR gilt für Verarbeitungen im Kontext einer Niederlassung in der EU und kann auch für Organisationen außerhalb der EU gelten, die Einzelpersonen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. GDPR definiert personenbezogene Daten weit und behandelt eine Verletzung des Schutzes personenbezogener Daten als Sicherheitsverletzung, die zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugriff auf verarbeitete personenbezogene Daten führt.

Für die Governance von Supportzeiträumen müssen Datenschutzteams wissen, welche Produktversionen personenbezogene Daten verarbeiten, welche Systeme noch unterstützt werden und ob Schwachstellen Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten beeinträchtigen.

Clarysecs Enterprise PII Security Access Control Policy PII Security Access Control Policy verlangt:

„[Beide] Der Systemverantwortliche / Anwendungsverantwortliche MUSS die Abdeckung von Schwachstellenbewertungen für Systeme, die PII verarbeiten, mindestens quartalsweise und nach wesentlichen technischen Änderungen in REG12 erfassen.“

Quelle: PII Security Access Control Policy, Sichere Konfiguration und Schwachstellenmanagement, Klausel 4.7.4 PII Security Access Control Policy

Die Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy ergänzt eine laufende Überwachung für datenschutzbezogene Hochrisikobeziehungen:

„[Alle] Der Vendor / Procurement Owner MUSS aktive Hochrisiko-Beziehungen mit Auftragsverarbeitern und Unterauftragsverarbeitern quartalsweise sowie andere aktive Beziehungen mit PII-Auftragsverarbeitern und -Unterauftragsverarbeitern jährlich anhand von Due-Diligence-Bedingungen, Vertragsstatus, Sicherstellungsstatus, offenen Punkten und Prüfdatum in REG08 überwachen.“

Quelle: Processor Subprocessor Third Party Privacy Management Policy, Laufende Überwachung, Unterstützung, Offenlegungsschnittstelle und Exit, Klausel 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Wenn eine Schwachstelle zu einem Vorfall wird, verlangt die Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy eine Auslöserbewertung über mehrere Rahmenwerke hinweg:

„[Bedingt] Der Privacy Lead / PIMS Manager MUSS für jeden Datenschutzvorfall mit hoher Tragweite anwendbare gesetzliche, sektorale, finanzsektorbezogene, cybersicherheitsbezogene, vertragliche, kundenbezogene und leistungsempfängerbezogene Meldeauslöser bewerten und das Ergebnis der Anwendbarkeit in REG01, REG08 und REG10 erfassen.“

Quelle: PII Incident Breach Management Policy, Klassifizierung und Bewertung der Datenschutzverletzung, Klausel 4.2.6 PII Incident Breach Management Policy

Dies ist die praktische Schnittmenge zwischen CRA-Supportzusagen, NIS2-Vorfallkommunikation, DORA-Behandlung schwerwiegender IKT-bezogener Vorfälle und GDPR-Rechenschaftspflicht bei Datenschutzverletzungen.

Wie Auditoren denselben Supportzeitraum-Prozess prüfen

Ein robuster Governance-Prozess für Supportzeiträume sollte unterschiedlichen Auditstilen standhalten. Die Nachweise ändern sich kaum, aber die Perspektive des Auditors schon.

NIST CSF 2.0 ist als Kommunikationsebene nützlich, weil seine GOVERN Function gesetzliche, regulatorische, vertragliche und datenschutzbezogene Verpflichtungen, Ziele des Risikomanagements, Risikobereitschaft, Rollen, Richtlinien und Aufsicht umfasst. Seine Lieferkettenergebnisse decken Lieferantenstrategie, Kritikalität, Verträge, gebotene Sorgfalt, Überwachung, Vorfallkoordination und Regelungen zum Ende der Geschäftsbeziehung ab.

COBIT- und ISACA-orientierte Auditoren konzentrieren sich häufig auf das Governance-Design: Wer verantwortet die Entscheidung, welcher Prozess ist definiert, welche Kennzahlen zeigen Leistung, wie werden Ausnahmen genehmigt und wie wird kontinuierliche Verbesserung umgesetzt?

Clarysecs Enterprise Informationssicherheitsleitlinie Informationssicherheitsleitlinie erfasst das Prinzip der Auditierbarkeit:

„Alle implementierten Kontrollen müssen auditierbar sein, durch dokumentierte Verfahren unterstützt werden und durch aufbewahrte Nachweise des Betriebs belegbar sein.“

Quelle: Informationssicherheitsleitlinie, Anforderungen an die Umsetzung der Richtlinie, Klausel 6.6.1 Informationssicherheitsleitlinie

Dieser Satz sollte für jeden Zeitraum der Sicherheitsunterstützung erfüllbar sein.

Support verlängern, verkürzen oder beenden, ohne falsche Sicherheit zu schaffen

Die schwierigsten Governance-Momente liegen nicht beim Produktstart. Sie entstehen, wenn sich die Realität ändert.

Möglicherweise müssen Sie Support verlängern, weil regulierte Kunden vom Produkt abhängen, eine Migration nicht machbar ist oder ein Sektorkunde vertragliche Kontinuitätsanforderungen hat. Möglicherweise müssen Sie Support verkürzen oder einschränken, weil ein Lieferant Sicherheitswartung einstellt, eine Komponente nicht mehr patchbar ist, eine Plattform technische Grenzen erreicht oder die Produktarchitektur eine Schwachstellenklasse nicht mehr sicher unterstützen kann.

Eine kontrollierte Änderung des Supportzeitraums sollte Folgendes umfassen:

• Änderungsauslöser, etwa End-of-Life eines Lieferanten, kritische Schwachstelle, Kundenvertrag oder regulatorische Änderung
• Betroffene Produkte, Versionen, Kunden und Sektoren
• Analyse der Auswirkungen auf personenbezogene Daten und kritische Services
• Machbarkeitsprüfung für Lieferanten und Komponenten
• Risikobeurteilung und Restrisikoentscheidung
• Aktualisiertes Supportzeitraum-Register
• Aktualisierte Kundenmitteilung und vertragliche Position
• Aktualisierte SoA-Hinweise, wenn sich Kontrollen oder Verpflichtungen ändern
• Managementfreigabe und Prüfdatum

Die Enterprise Richtlinie zur koordinierten Offenlegung von Schwachstellen Richtlinie zur koordinierten Offenlegung von Schwachstellen ist nützlich, wenn die Änderung schwachstellengetrieben ist:

„Für alle bestätigten Schwachstellen ist ein Abhilfe- oder Minderungsplan zu entwickeln. Die Umsetzung der Korrektur ist nach Schweregrad zu priorisieren. Kritische Schwachstellen sind beispielsweise, soweit machbar, innerhalb von 14 Tagen zu beheben oder zu mindern, oder schneller, wenn eine aktive Ausnutzung festgestellt wird; Schwachstellen mit geringerem Schweregrad sind innerhalb eines angemessenen Zeitrahmens zu adressieren.“

Quelle: Richtlinie zur koordinierten Offenlegung von Schwachstellen, Umsetzungsanforderungen, Klausel 6.6 Richtlinie zur koordinierten Offenlegung von Schwachstellen

Wenn ein vollständiger Fix nicht sofort bereitgestellt werden kann, können kompensierende Kontrollen, deaktivierte Funktionen, verstärkte Überwachung oder kundenseitige Konfigurationshinweise vorübergehend akzeptabel sein; die Entscheidung muss jedoch dokumentiert und kommuniziert werden.

Praktische Clarysec-Checkliste für Supportzeitraum-Bereitschaft

Verwenden Sie diese Checkliste, bevor Sie eine CRA-Zusage zum Zeitraum für Sicherheitsunterstützung veröffentlichen oder erneuern.

• Ist das Produkt einschließlich Version im Supportzeitraum-Register aufgeführt?
• Wurde das Supportende durch Produkt, Sicherheit und rechenschaftspflichtiges Management genehmigt?
• Sind gesetzliche, regulatorische und vertragliche Treiber im Compliance-Register zugeordnet?
• Ist das Supportzeitraum-Risikoszenario im Risikoregister enthalten?
• Sind Kontrollen in der Statement of Applicability zugeordnet, einschließlich 5.31, 8.8 und 8.25, soweit anwendbar?
• Sind kritische Lieferanten und Komponenten im Register für Lieferantenabhängigkeiten zugeordnet?
• Gibt es Nachweise, dass Komponenten während des Supportzeitraums gepatcht oder ersetzt werden können?
• Sind Verantwortlichkeiten für Entgegennahme, Triage, Abhilfe und Offenlegung von Schwachstellen definiert?
• Sind SLAs für kritische Patches mit Richtlinie und Kundenverträgen abgestimmt?
• Werden Patch-Protokolle, Release-Aufzeichnungen und Schwachstellenentscheidungen aufbewahrt?
• Sind Systeme mit personenbezogenen Daten durch Nachweise zu Schwachstellenbewertungen abgedeckt, sofern PII verarbeitet wird?
• Sind Kundenmitteilungen, Supportaussagen und Vertragsbedingungen konsistent?
• Gibt es einen Prozess, um Support mit Risikogenehmigung zu verlängern, zu verkürzen oder zu beenden?
• Erhalten Managementbewertungen Eingaben zu Supportzeitraum-Risiken, Lieferanten, Schwachstellen und Vorfällen?
• Können Nachweise innerhalb von 48 Stunden für ein Kundenaudit oder eine Anfrage einer Aufsichtsbehörde bereitgestellt werden?

Die Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy stärkt die Disziplin der Managementbewertung für Datenschutzprogramme:

„[Beide] Die oberste Leitung MUSS bei jeder Managementbewertung Eingaben zu PIMS-Nichtkonformitäten, Korrekturmaßnahmen, Überwachungsergebnissen, Auditergebnissen, Datenschutzrisiken, Lieferantensicherstellung und Änderungen interessierter Parteien in REG12 überprüfen.“

Quelle: PIMS Monitoring Audit Improvement Policy, PIMS-Managementbewertung, Klausel 4.3.5 PIMS Monitoring Audit Improvement Policy

Für die Governance von Zeiträumen der Sicherheitsunterstützung sollte derselbe Überprüfungsrhythmus im gesamten ISMS gelten: Schwachstellen, Patch-Leistung, Lieferantensicherheit, Kundenzusagen, Vorfälle, Supportausnahmen und Korrekturmaßnahmen sollten in die Managementbewertung einfließen.

Den Zeitraum für Sicherheitsunterstützung belastbar machen

Der EU Cyber Resilience Act verändert die Denkweise in der Produktsicherheit. Er zwingt Hersteller und Softwareanbieter, über den Releasetag hinauszudenken. Der Zeitraum für Sicherheitsunterstützung wird zu einer Lebenszykluszusage, die technisch ermöglicht, gesteuert, überwacht und nachgewiesen werden muss.

Für CISOs ist die Lehre klar: Der Supportzeitraum darf nicht nur im Produktmarketing stehen. Für Compliance-Manager gilt: Bauen Sie kein separates CRA-Nachweissilo. Für Auditoren gilt: Prüfen Sie, ob Supportzusagen zu Risiken, Kontrollen, Lieferanten, Vorfällen und dokumentierten Genehmigungen nachvollziehbar sind. Für Geschäftsverantwortliche gilt: Ein glaubwürdiger Supportzeitraum kann zum Marktvorteil werden, insbesondere beim Vertrieb an NIS2-regulierte Sektoren, DORA-Finanzunternehmen und datenschutzsensible Kunden.

Clarysec unterstützt Organisationen bei der Operationalisierung durch:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint für den Aufbau von ISMS-Nachvollziehbarkeit, dokumentierter Information, SoA-Zuordnung und Auditbereitschaft
• Zenith Controls: The Cross-Compliance Guide Zenith Controls für die Zuordnung von ISO/IEC 27002:2022-Kontrollen zu NIS2, DORA, GDPR, NIST CSF 2.0 und Auditerwartungen
• Enterprise- und SME-Richtlinienpakete für Schwachstellenmanagement, sichere Entwicklung, rechtliche Compliance, Lieferantenabhängigkeiten, Datenschutznachweise und Incident Response
• Praktische Register und Nachweis-Workflows, die Supportzeitraum-Zusagen in auditierbare Governance überführen

Ihr nächster Schritt ist einfach: Wählen Sie eine zentrale Produktversion aus und erstellen Sie deren Nachweisakte zum Zeitraum für Sicherheitsunterstützung. Ordnen Sie die Verpflichtung zu, genehmigen Sie den Supportzeitraum, testen Sie den Schwachstellenprozess, validieren Sie Lieferantenabhängigkeiten, bestätigen Sie die Kundenkommunikation und bewahren Sie die Aufzeichnungen auf.

Wenn Sie ein Produkt belastbar vertreten können, können Sie das Modell skalieren. Wenn Sie nicht einmal ein Produkt belastbar vertreten können, ist die Lücke nicht Dokumentation. Sie ist Governance.

Laden Sie den Zenith Blueprint herunter, verwenden Sie Zenith Controls zur Zuordnung Ihrer Nachweise oder fordern Sie eine Clarysec-Bereitschaftsbewertung an, um CRA-Zeiträume für Sicherheitsunterstützung in auditfähige ISO 27001-Governance zu überführen.