Governance für Dangling DNS im Kontext von NIS2, DORA und GDPR

Der CISO erhält die Meldung an einem Montag um 07:12 Uhr.

Ein Sicherheitsforscher hat festgestellt, dass promo.company.com auf eine aufgegebene Cloud-Anwendung verweist. Der DNS-Eintrag ist weiterhin aktiv. Die Cloud-Ressource existiert nicht mehr. Der SaaS-Mandant, über den die Kampagne früher lief, wurde vor sechs Monaten gelöscht, kurz nachdem das Marketing auf eine andere Plattform gewechselt war. Den CNAME hat niemand entfernt.

Um 08:30 Uhr lautet die Frage nicht mehr: „Kann jemand die Subdomain übernehmen?“ Sondern: „Warum wusste niemand, dass dieses Asset existiert?“

Um 09:15 Uhr ist die Rechtsabteilung eingebunden, weil die Subdomain früher E-Mail-Adressen für eine Produktwarteliste erfasst hat. Der Einkauf ist eingebunden, weil die Kampagnenplattform von einer Agentur verwaltet wurde. Die Compliance-Funktion ist eingebunden, weil sich das Unternehmen auf ein Überwachungsaudit nach ISO/IEC 27001:2022, NIS2-Bereitschaft und Kundensicherheitsfragebögen vorbereitet. Der Datenschutzbeauftragte fragt, ob die Exponierung zu einer Verletzung des Schutzes personenbezogener Daten nach GDPR werden könnte, falls die Subdomain missbraucht wird. Der CFO fragt, ob dieselbe Schwachstelle ein Zahlungsportal innerhalb des regulierten Finanzdienstleistungsumfelds der Gruppe betreffen könnte.

Die technische Behebung kann Minuten dauern. Das Governance-Problem kann Monate in Anspruch nehmen, wenn die Organisation nicht nachweisen kann, dass jedes internetseitig erreichbare Asset bekannt, einem Verantwortlichen zugeordnet, überprüft, überwacht und über einen kontrollierten Prozess außer Betrieb genommen wird.

Deshalb dürfen Dangling DNS und die Verhinderung von Subdomain-Übernahmen nicht als eng begrenzte DNS-Bereinigungsaufgabe behandelt werden. Ein veralteter DNS-Eintrag ist häufig ein sichtbares Symptom tieferliegender Kontrollausfälle: unvollständiges Asset-Inventar, unklare Verantwortlichkeiten, fehlende Nachweise zur Außerbetriebnahme, unzureichende Änderungskontrolle, schwaches Exit-Management bei Lieferanten, unzureichende Überwachung der externen Angriffsfläche und unklare Vorfallklassifizierung.

Für Clarysec-Kunden ist Dangling DNS ein Test des Managementsystems. Es zeigt, ob Richtlinien, Kontrollen, Register, Nachweise und Rechenschaftspflicht tatsächlich funktionieren, wenn eine vergessene Cloud-Abhängigkeit zur Gelegenheit für einen Angreifer wird.

Was Dangling DNS tatsächlich bedeutet

Eine Subdomain-Übernahme wird möglich, wenn ein DNS-Eintrag, häufig ein CNAME, auf eine Ressource verweist, die nicht mehr existiert oder nicht mehr von der Organisation kontrolliert wird. Wenn ein Angreifer die Zielressource auf der Cloud- oder SaaS-Plattform beanspruchen oder neu erstellen kann, kann er unter der vertrauenswürdigen Subdomain der Organisation Inhalte bereitstellen.

Typische Beispiele sind:

• Ein CNAME, der auf einen nicht beanspruchten Cloud-App-Service verweist.
• Ein Vanity-SaaS-Hostname, der nach Kündigung des Abonnements im DNS verbleibt.
• Eine CDN-Distribution, die aus der Anbieterkonsole entfernt wurde, aber weiterhin im öffentlichen DNS referenziert ist.
• Eine Marketing-Microsite, die von einer Agentur außer Betrieb genommen wurde, ohne den DNS-Eintrag zu entfernen.
• Ein Storage-Endpunkt oder eine Zuordnung für eine statische Website, die erneut registriert werden kann.
• Eine Entwicklungs-Subdomain, die über ein vergessenes Platform-as-a-Service-Projekt exponiert ist.

Die geschäftlichen Auswirkungen können erheblich sein. Angreifer können Phishing-Seiten hosten, Zugangsdaten erfassen, Schadsoftware verteilen, die Domain-Reputation missbrauchen, Sitzungsdaten abfangen oder das Vertrauen in die Marke beschädigen. Wenn die Subdomain zuvor personenbezogene Daten verarbeitet hat, kann bereits eine kurzzeitige Übernahme eine Bewertung als Datenschutzverletzung nach GDPR auslösen. Wenn der betroffene Dienst regulierte Finanzprozesse unterstützt, kann der Vorfall außerdem nach DORA oder internen Rahmenwerken für das Management von IKT-Risiken zu bewerten sein.

Auditoren betrachten Dangling DNS zunehmend als Nachweis für den Reifegrad von Kontrollen. Ein einzelner veralteter Eintrag kann darauf hinweisen, dass die Organisation nicht weiß, welche Assets sie besitzt, wer dafür verantwortlich ist, wie Änderungen geprüft werden, wie Cloud-Dienste beendet werden oder wie extern erreichbare Assets überwacht werden.

Deshalb bildet Clarysec dieses Thema auf ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 und die Auditerwartungen nach COBIT 2019 ab.

Warum ISO 27001:2022 das praktische Rückgrat ist

Der wirksamste Ansatz zur Steuerung von Dangling DNS besteht nicht darin, separate Programme für NIS2, DORA und GDPR aufzubauen. Der bessere Ansatz ist, ISO/IEC 27001:2022 als Rückgrat des Managementsystems zu nutzen und Nachweise einmal für mehrere Prüf- und Vertrauensanforderungen zu erzeugen.

Die relevanten Anforderungen beginnen bereits vor Annex A. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation ihren Kontext, die Anforderungen interessierter Parteien, den ISMS-Geltungsbereich und Abhängigkeiten von anderen Organisationen versteht. Für die Governance von Dangling DNS muss der Geltungsbereich externes DNS, Domains, Registrare, Cloud-Dienste, SaaS-Plattformen, Agenturen, Managed Hosting, CDNs und jede Drittpartei umfassen, die internetseitig erreichbare Dienste erstellen oder außer Betrieb nehmen kann.

Die Abschnitte 5.1 bis 5.3 machen daraus eine Frage von Führung und Rechenschaftspflicht. Die Leitung muss das ISMS an der geschäftlichen Ausrichtung ausrichten, Ressourcen bereitstellen, die Bedeutung der Informationssicherheit kommunizieren und Verantwortlichkeiten zuweisen. Wenn Marketing eine Microsite starten kann, Engineering Cloud-Endpunkte erstellen kann und der Einkauf SaaS-Verträge beenden kann, benötigt die Organisation ein Governance-Modell, das DNS- und Serviceverantwortung über alle diese Bereiche hinweg eindeutig zuweist.

Die Abschnitte 6.1.1 bis 6.1.3 liefern die Logik für Risikobeurteilung, Risikobehandlung und Erklärung zur Anwendbarkeit. Dangling DNS muss als realistisches Risikoszenario erfasst werden, nicht nur als Scanner-Ergebnis. Es betrifft Vertraulichkeit, Integrität und Verfügbarkeit und lässt sich häufig gesetzlichen, regulatorischen und vertraglichen Verpflichtungen zuordnen.

Die Abschnitte 7.5, 8.1, 8.2 und 8.3 überführen Governance in Nachweise. Sie verlangen gelenkte dokumentierte Information, geplante und gesteuerte operative Prozesse, die Berücksichtigung unbeabsichtigter Änderungen, die Steuerung extern bereitgestellter Prozesse, regelmäßige Risikobeurteilungen und dokumentierte Behandlungsergebnisse.

Annex A liefert anschließend den Maßnahmenkatalog. In Clarysec-Projekten sehen die zentralen Beziehungen zu ISO/IEC 27002:2022 üblicherweise wie folgt aus:

Der Punkt ist einfach: ISO/IEC 27001:2022 verlangt keine einmalige heroische Bereinigung. Die Norm verlangt ein kontrolliertes Betriebsmodell, das Wiederholungen verhindert.

Die Sicht von Zenith Controls: ein Risiko, drei Kontrollanker

In Zenith Controls: The Cross-Compliance Guide Zenith Controls nutzt Clarysec relevante Maßnahmen aus ISO/IEC 27002:2022 als Cross-Compliance-Anker. Für Dangling DNS und die Governance zur Verhinderung von Subdomain-Übernahmen sind drei Maßnahmen zentral.

Maßnahme 5.9, Inventar der Informationen und anderer zugehöriger Assets, ist als präventiv eingestuft, unterstützt Vertraulichkeit, Integrität und Verfügbarkeit, ist dem Cybersicherheitskonzept Identify zugeordnet und liegt unter Asset-Management als operativer Fähigkeit mit Governance, Ökosystem und Schutz als Sicherheitsdomänen.

Maßnahme 5.23, Informationssicherheit bei der Nutzung von Cloud-Diensten, ist als präventiv eingestuft, unterstützt Vertraulichkeit, Integrität und Verfügbarkeit, ist Protect zugeordnet und liegt unter Sicherheit der Lieferantenbeziehungen als operativer Fähigkeit mit Governance, Ökosystem und Schutz als Sicherheitsdomänen.

Maßnahme 8.8, Management technischer Schwachstellen, ist als präventiv eingestuft, unterstützt Vertraulichkeit, Integrität und Verfügbarkeit, ist Identify und Protect zugeordnet und liegt unter Bedrohungs- und Schwachstellenmanagement als operativer Fähigkeit mit Governance, Ökosystem, Schutz und Verteidigung als Sicherheitsdomänen.

Das ist wichtig, weil Dangling DNS nicht nur ein Kontrollversagen im Asset-Management ist, nicht nur ein Kontrollversagen in der Cloud und nicht nur eine Schwachstelle. Es ist alles drei. Die Organisation muss zeigen, dass Asset-Inventar, Governance der Cloud-Nutzung und Schwachstellenmanagement einander verstärken.

Clarysec ergänzt diese Anker häufig um unterstützende Praktiken: ISO/IEC 27005 für die Disziplin in Risikobeurteilung und Risikobehandlung, ISO/IEC 27017 für Sicherheitsgovernance von Cloud-Diensten, ISO/IEC 27018, wenn Cloud-Dienste PII verarbeiten, ISO/IEC 27701 für Datenschutz-Informationsmanagement und ISO 22301, wenn Aufrechterhaltung des Geschäftsbetriebs und Krisenreaktion relevant sind.

Richtliniennachweise, die bereits eine Steuerung des DNS-Lebenszyklus verlangen

Viele Organisationen verfügen bereits über Richtlinien, die Dangling DNS verhindern würden, wenn sie wirksam umgesetzt wären. Die Lücke besteht darin, dass die Steuerung des DNS-Lebenszyklus nicht ausdrücklich mit diesen Richtlinien verbunden ist.

Clarysecs Richtlinie zum Asset-Management für KMU Richtlinie zum Asset-Management für KMU, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.6.1, legt fest:

Cloud-basierte Assets (z. B. Speicherkonten, SaaS-Plattformen, Webdomains) müssen ebenfalls in das Inventar aufgenommen werden.

Dieselbe Richtlinie ergänzt in Abschnitt 6.6.2:

Verantwortlichkeit, Zweck, Zugriffsberechtigungen und Verlängerungsfristen müssen dokumentiert werden.

Für die Governance von Dangling DNS bedeutet dies: Jede Produktiv-Subdomain und jede wesentliche Nicht-Produktiv-Subdomain muss einen benannten Verantwortlichen, einen Geschäftszweck, einen verknüpften Dienst, ein Zugriffsmodell und ein Überprüfungsdatum haben.

Besonders wichtig ist Abschnitt 6.6.3:

Abgelaufene oder nicht genutzte Dienste müssen deaktiviert und aus dem Inventar entfernt werden.

Für DNS ist dies sorgfältig auszulegen. Es reicht nicht aus, den Dienst aus dem Inventar zu entfernen. Auch der DNS-Eintrag, die Cloud-Bindung, der SaaS-Anspruch auf eine benutzerdefinierte Domain, das Zertifikat, die WAF-Regel, die CDN-Konfiguration und der Überwachungseintrag müssen überprüft werden.

Die Enterprise-Version bekräftigt dieses breitere Asset-Verständnis. Clarysecs Richtlinie zum Asset-Management Richtlinie zum Asset-Management, Geltungsbereich, Abschnitt 2.2.5, legt fest:

Logische Assets: Domainnamen, Lizenzen, Benutzerkonten, Baseline-Konfigurationen

Domainnamen und Konfigurationen sind keine administrativen Nebensächlichkeiten. Sie sind vertrauensbegründende Assets, die zu Angriffspfaden werden können.

Die Verknüpfung mit der Änderungskontrolle ist ebenso wichtig. Clarysecs Änderungsmanagement-Richtlinie Änderungsmanagement-Richtlinie, Zweck, Abschnitt 1.1, legt fest:

Diese Richtlinie etabliert einen formalen Rahmen für die Initiierung, Bewertung, Genehmigung, Implementierung und Überprüfung von Änderungen an Informationssystemen, Infrastruktur, Anwendungen und zugehörigen Prozessen der Organisation.

Eine DNS-Entfernung, SaaS-Beendigung, Löschung einer Cloud-App, CDN-Migration oder Außerbetriebnahme einer Marketing-Microsite muss daher Änderungsnachweise erzeugen. Das Fehlen eines Änderungs-Tickets ist häufig das erste Audit-Warnsignal.

Auch Cloud-Governance muss einbezogen werden. Clarysecs Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten, Governance-Anforderungen, Abschnitt 5.5, legt fest:

Das Informationssicherheitsteam muss Netzwerkverkehr, DNS-Aktivität und Protokolle regelmäßig bewerten, um nicht autorisierte Cloud-Nutzung (Shadow IT) zu erkennen. Erkannte Verstöße müssen unverzüglich untersucht werden.

Für die Verhinderung von Subdomain-Übernahmen geht es bei der Überwachung von DNS-Aktivität nicht nur um Shadow IT. Es geht auch um veraltete IT, also um Assets, die früher autorisiert waren, aber nicht mehr kontrolliert werden.

Ein praktischer Clarysec-Workflow für die Governance von Dangling DNS

Ein wirksames Programm für Dangling DNS ist nicht kompliziert. Es ist diszipliniert, wiederholbar und mit ISMS, Schwachstellenmanagement, Änderungsmanagement und Lieferantenlebenszyklus verbunden.

Für KMU kann dies mit einem schlanken Register beginnen. In Unternehmen wird dies üblicherweise mit DNS-Exporten, Management der externen Angriffsfläche, Cloud-Asset-Inventaren, CMDB-Datensätzen, Schwachstellenscannern, SIEM-Warnmeldungen und Ticketsystemen integriert.

Die Governance-Frage bleibt dieselbe: Können Sie nachweisen, dass jede extern erreichbare Subdomain bekannt, einem Verantwortlichen zugeordnet, überwacht und über einen kontrollierten Prozess entfernbar ist?

Die aufgegebene Kampagnen-Subdomain, richtig behandelt

Zurück zum Vorfall am Montag: promo.company.com verweist auf eine aufgegebene SaaS-Kampagnenseite.

Zuerst erstellt der Sicherheitsverantwortliche einen Schwachstellendatensatz, weil das Asset extern erreichbar ist. Clarysecs Richtlinie zum Schwachstellen- und Patch-Management Richtlinie zum Schwachstellen- und Patch-Management, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.1.1, legt fest:

Alle Systeme müssen mindestens monatlich gescannt werden; risikobehaftete oder extern exponierte Assets müssen wöchentlich gescannt werden.

Für KMU schärft die entsprechende Richtlinie die Priorisierung. Die Richtlinie zum Schwachstellen- und Patch-Management für KMU Richtlinie zum Schwachstellen- und Patch-Management für KMU, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.5.1, legt fest:

Systeme, die personenbezogene Daten verarbeiten, Fernzugriff bereitstellen oder extern erreichbar sind, müssen für Scans und Aktualisierungen priorisiert werden.

Zweitens wird der Verantwortliche über das Asset-Register identifiziert. Ist der Verantwortliche unbekannt, stellt dies ein Kontrollversagen in der Asset-Governance dar. Das Register wird um DNS-Name, Zielanbieter, ursprünglichen Geschäftsinhaber, Datenklassifizierung, Lieferant und Status ergänzt.

Drittens prüft die IT die Cloud- oder SaaS-Plattform. Wenn das Cloud-Konto gelöscht wurde, ist Clarysecs Richtlinie zur Nutzung von Cloud-Diensten für KMU Richtlinie zur Nutzung von Cloud-Diensten für KMU, Anforderungen an die Umsetzung der Richtlinie, Abschnitt 6.3.6, unmittelbar relevant:

Gelöschte Cloud-Konten müssen vom IT-Dienstleister oder General Manager auf verbleibende Zugriffsrechte, verwaiste Daten oder übersehene Inhalte überprüft werden.

Viertens erstellt der Change Owner ein Notfall- oder beschleunigtes Änderungs-Ticket, um den DNS-Eintrag zu entfernen oder die Ressource vorübergehend zurückzufordern, bevor sie entfernt wird. Das Ticket enthält Auswirkungsbewertung, Rollback-Plan, Genehmigungen, Implementierungsnachweise und Validierung nach der Änderung.

Fünftens bewertet der Datenschutzverantwortliche, ob die Subdomain personenbezogene Daten verarbeitet hat oder hätte exponieren können. Clarysecs PII Security and Access Control Policy PII Security and Access Control Policy, sichere Konfiguration und Schwachstellenmanagement, Abschnitt 4.7.4, legt fest:

[Beide] Der Systemverantwortliche / Anwendungsverantwortliche MUSS die Abdeckung der Schwachstellenbewertung für Systeme, die PII verarbeiten, mindestens vierteljährlich und nach wesentlichen technischen Änderungen in REG12 dokumentieren.

Abschnitt 4.7.5 ergänzt:

[Beide] Der Informationssicherheitsverantwortliche MUSS nicht behobene Hochrisiko-Schwachstellen, die PII betreffen, innerhalb von fünf Geschäftstagen nach Validierung in REG12 dokumentieren.

Diese Abschnitte gelten unabhängig davon, ob die Organisation als Verantwortlicher oder Auftragsverarbeiter handelt, weil sie mit [Beide] gekennzeichnet sind. Bei einem Dangling-DNS-Thema mit PII-Bezug dürfen die Nachweise nicht nur in einem technischen Ticket verbleiben. Sie müssen im Nachweisregister für PII-Schwachstellen abgebildet werden.

Sechstens prüft der Einkauf die Drittparteiendatensätze, falls eine Agentur oder ein SaaS-Anbieter die Kampagne gehostet hat. Clarysecs Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Identifizierung und Klassifizierung von Beziehungen, Abschnitt 4.1.2, legt fest:

[Alle] Der Prozessverantwortliche / Fachverantwortliche MUSS jede geplante Drittparteibeziehung, die PII verarbeitet, darauf zugreift, sie empfängt, speichert, übermittelt, unterstützt oder anderweitig betrifft, vor Beschaffung, Onboarding, Verlängerung oder einer wesentlichen datenschutzrelevanten Änderung der Drittpartei in REG08 identifizieren.

Abschnitt 4.5.5 verlangt:

[Beide] Der Lieferanten- / Einkaufsverantwortliche MUSS Verarbeitungsorte, Hosting-Standorte und Indikatoren für internationale Übermittlungen in REG08 dokumentieren und anwendbare Übermittlungsnachweise mit REG09 verknüpfen, bevor ein Auftragsverarbeiter, Unterauftragsverarbeiter, Standortwechsel oder übermittlungsrelevanter Servicewechsel genehmigt wird.

Abschließend bündelt die Compliance-Leitung die Nachweise. Clarysecs Richtlinie zur Audit- und Compliance-Überwachung Richtlinie zur Audit- und Compliance-Überwachung, Ziele, Abschnitt 3.4, nennt als eines der Ziele:

Belastbare Nachweise und einen Prüfpfad zur Unterstützung von Anfragen von Aufsichtsbehörden, Gerichtsverfahren oder Anfragen zur Vertrauensbildung bei Kunden zu erzeugen.

Genau dieses Ergebnis braucht der CISO, wenn ein Kunde, eine Aufsichtsbehörde oder ein Auditor fragt: „Woher wissen Sie, dass das nicht wieder passiert?“

Wo die Zenith Blueprint einzuordnen ist

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint überführt Kontrollen in auditbereite Betriebspraktiken. Dangling DNS lässt sich besonders stark vier Bereichen zuordnen.

In der Phase „Controls in Action“ behandelt Schritt 22 die organisatorischen Maßnahmen 5.1 bis 5.18, einschließlich ISO/IEC 27002:2022 Maßnahme 5.9. Die Zenith Blueprint stellt fest:

Keine Organisation kann schützen, wovon sie nicht weiß, dass sie es besitzt. Maßnahme 5.9 formalisiert dieses Grundprinzip und verlangt die Einrichtung und Pflege eines aktuellen Inventars aller Informationen und zugehörigen Assets, die für das ISMS relevant sind.

Weiter heißt es:

In seiner strategischsten Form dient ein Asset-Inventar als zentrales Nervensystem Ihres ISMS.

Ihr Subdomain-Inventar ist keine Nebenliste. Es speist Zugriffsentscheidungen, Schwachstellenscans, Protokollierung, Lieferantenmanagement, Datenschutzzuordnung und Incident Response.

In Schritt 20 behandelt die Zenith Blueprint die technischen Maßnahmen 8.18 bis 8.26. Für Maßnahme 8.21, Sicherheit von Netzwerkdiensten, weist sie Organisationen an, die Sicherheit von Netzwerkdiensten zu validieren:

Listen Sie alle internen und externen Netzwerkdienste auf (DNS, VPN, SMTP, DHCP, API-Gateways usw.).

Deshalb gehören DNS-Anbieter, Registrare, Cloud-DNS, CDN-Plattformen und SaaS-Funktionen für benutzerdefinierte Domains in das Service-Register.

In Schritt 19 behandelt die Zenith Blueprint die technischen Maßnahmen 8.1 bis 8.17. Für Maßnahme 8.8 heißt es:

Das Management von Schwachstellen ist einer der kritischsten Bereiche moderner Cyberhygiene. Firewalls und Antivirensoftware bieten zwar Schutz, können aber unterlaufen werden, wenn ungepatchte Systeme oder fehlerhaft konfigurierte Dienste exponiert bleiben.

Ein Dangling-DNS-Eintrag ist ein fehlerhaft konfigurierter externer Servicepfad. Auch wenn keine CVE vorliegt, muss er über das Schwachstellenmanagement behandelt werden: validieren, bewerten, zuweisen, beheben, nachprüfen und schließen.

In Schritt 23 behandelt die Zenith Blueprint die organisatorischen Maßnahmen 5.19 bis 5.37. Für Maßnahme 5.23 empfiehlt sie:

Listen Sie alle derzeit genutzten Cloud-Dienste auf (5.23), einschließlich bekannter Shadow IT. Ermitteln Sie, wer sie genehmigt hat und ob gebotene Sorgfalt durchgeführt wurde. Entwickeln Sie eine schlanke Bewertungscheckliste, die Datenstandort, Zugriffsmodell, Protokollierung und Verschlüsselung abdeckt.

Für die Verhinderung von Subdomain-Übernahmen müssen dieser Bewertungscheckliste für Cloud-Dienste benutzerdefinierte Domains, DNS-Abhängigkeiten, Verantwortliche für die Außerbetriebnahme und Exit-Nachweise hinzugefügt werden.

Zuordnung zu NIS2, DORA und GDPR

NIS2 macht die Governance von Dangling DNS für viele wesentliche und wichtige Einrichtungen zu einem Thema auf Ebene des Leitungsorgans. Article 20 verlangt, dass Leitungsorgane Maßnahmen zum Cybersicherheitsrisikomanagement genehmigen, ihre Umsetzung überwachen und an Cybersicherheitsschulungen teilnehmen. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen unter Anwendung eines gefahrenübergreifenden Ansatzes. Die Mindestbereiche umfassen Risikoanalyse, Behandlung von Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung, Entwicklung und Wartung, Schwachstellenbehandlung, Wirksamkeitsbewertung, Cyberhygiene, Schulung, Zugriffskontrolle und Asset-Management.

Ein Programm für Dangling DNS lässt sich diesen Bereichen eindeutig zuordnen. Article 21(3) verlangt außerdem, dass die Sicherheit der Lieferkette Schwachstellen berücksichtigt, die für jeden direkten Lieferanten oder Dienstleister spezifisch sind. Wenn eine Marketingagentur, ein SaaS-Anbieter, ein Managed-Hosting-Anbieter oder eine Cloud-Plattform benutzerdefinierte Domains verwaltet, müssen lieferantenspezifische Kontrollen DNS-Verantwortung, Service-Exit, Unterstützung bei Vorfällen und Nachweisübergabe abdecken.

Article 23 ist relevant, wenn eine Übernahme eintritt oder geeignet ist, schwere Betriebsstörungen, finanzielle Verluste oder erhebliche materielle oder immaterielle Schäden zu verursachen. NIS2 nutzt gestufte Meldungen: Frühwarnung innerhalb von 24 Stunden nach Kenntniserlangung eines erheblichen Vorfalls, Meldung innerhalb von 72 Stunden, Zwischenberichte auf Anforderung und einen Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung.

Für Finanzunternehmen ist DORA das sektorspezifische Regelwerk für digitale operationale Resilienz. Articles 5 und 6 verlangen ein internes Governance- und Kontrollrahmenwerk für das Management von IKT-Risiken mit letztendlicher Verantwortung des Leitungsorgans, klaren IKT-Rollen, Richtlinien für Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten, Auditplänen, Ressourcen, einer Richtlinie für Drittparteidienste und einem dokumentierten Rahmenwerk für das Management von IKT-Risiken.

Articles 8 bis 14 bilden den operativen Kern. Article 8 verlangt Identifizierung, Klassifizierung und Dokumentation IKT-gestützter Geschäftsfunktionen, Informations-Assets, IKT-Assets, Abhängigkeiten, Verbindungen zu IKT-Drittdienstleistern, Inventaren, Risikoszenarien und Altsystemen. Ein Dangling CNAME ist häufig eine übersehene Abhängigkeit. Article 9 verlangt Schutz und Prävention. Article 10 verlangt die Erkennung anomaler Aktivitäten, IKT-Vorfälle und potenzieller Single Points of Failure. Articles 11 und 12 behandeln Aufrechterhaltung des Geschäftsbetriebs, Wiederherstellung, Backup und Recovery. Article 13 verlangt Lernen aus Schwachstellen, Bedrohungen, Vorfällen und Tests.

Articles 17 bis 19 formalisieren Vorfallmanagement, Klassifizierung und Berichterstattung. Articles 28 bis 30 machen das IKT-Drittparteienrisiko lebenszyklusbezogen. Finanzunternehmen bleiben bei der Nutzung von IKT-Dienstleistern voll verantwortlich. Für DORA-Bereitschaft empfiehlt Clarysec, jedem DNS- und Cloud-Service-Register vier Felder hinzuzufügen: Unterstützung einer kritischen oder wichtigen Funktion, IKT-Drittdienstleister, Vertrags- oder Registerreferenz und Status des Exit-Tests.

GDPR gilt, wenn das Thema personenbezogene Daten betrifft. Eine Subdomain-Übernahme ist nicht automatisch eine Verletzung des Schutzes personenbezogener Daten, kann aber dazu werden, wenn die betroffene Subdomain Zugangsdaten sammelt, Formulardaten erfasst, einen Dienst imitiert, Benutzerkennungen exponiert oder unbefugten Zugriff auf personenbezogene Daten ermöglicht. GDPR Article 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 32 verlangt eine angemessene Sicherheit der Verarbeitung. Article 33 kann eine Meldung an die Aufsichtsbehörde verlangen, wenn eine Verletzung des Schutzes personenbezogener Daten voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.

Clarysecs PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Klassifizierung und Bewertung der Datenschutzverletzung, Abschnitt 4.2.6, unterstützt diese Analyse von Auslösern über mehrere Regelwerke hinweg:

[Bedingt] Der Privacy Lead / PIMS Manager MUSS für jeden PII-Vorfall mit hoher Auswirkung anwendbare gesetzliche, sektorale, finanzsektorbezogene, cybersicherheitsbezogene, vertragliche, kundenbezogene und serviceempfängerbezogene Meldeauslöser bewerten und das Ergebnis der Anwendbarkeit in REG01, REG08 und REG10 dokumentieren.

Genau dieser Entscheidungsdatensatz wird benötigt, wenn eine Subdomain-Übernahme GDPR, NIS2, DORA, Verträge und Kundenbenachrichtigungen betreffen könnte.

Wie Auditoren Ihre Nachweise prüfen werden

Ein integriertes ISMS muss es ermöglichen, unterschiedliche Auditoren mit derselben Nachweisbasis zu bedienen. Die Formulierung der Frage ändert sich, der Nachweis ist häufig derselbe.

Eine breitere Assurance-Perspektive umfasst häufig auch NIST CSF 2.0 und COBIT 2019. NIST CSF 2.0 hilft, den Zielzustand über GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- und RECOVER-Ergebnisse auszudrücken. Ein Ist-Profil könnte manuelle vierteljährliche DNS-Prüfungen und inkonsistentes SaaS-Offboarding zeigen. Ein Zielprofil könnte automatisierte wöchentliche Übernahmeprüfungen, verpflichtende Zuweisung von Verantwortlichen, Lieferanten-Exit-Nachweise und Integration in das Änderungsmanagement verlangen.

Ein an COBIT 2019 oder ISACA orientierter Auditor wird üblicherweise fragen, wem der Prozess gehört, wie Risiken bewertet und gesteuert werden, ob Änderungen kontrolliert werden, ob Lieferanten gemanagt werden, ob Konfigurationen und Assets verlässlich sind und ob Assurance-Nachweise das Management-Reporting unterstützen. Er fragt möglicherweise nicht zuerst nach einer Liste von CNAMEs. Er fragt eher, woher die Leitung weiß, dass externe digitale Dienste über ihren gesamten Lebenszyklus kontrolliert werden.

Wie gute Auditnachweise aussehen

Ein Auditpaket für Dangling DNS muss schlank genug sein, um gepflegt zu werden, und vollständig genug, um belastbar zu sein. Clarysec empfiehlt typischerweise den folgenden Nachweissatz:

• DNS-Zoneninventar mit Quelle, Datum, Eintragstyp, Ziel und Verantwortlichem.
• Scanergebnisse zur externen Angriffsfläche mit Übernahmeprüfungen.
• Einträge im Asset-Register für Domains, Subdomains, Cloud-Dienste, SaaS-Anwendungen und CDNs.
• Service-Register mit interner oder Lieferantenverantwortung.
• Änderungs-Tickets für Erstellung, Änderung und Löschung von DNS-Einträgen.
• Cloud- und SaaS-Onboarding-Checklisten einschließlich Prüfung benutzerdefinierter Domains und DNS.
• Lieferantenverträge oder Sicherheitsklauseln zu DNS, Hosting, Unterstützung bei Vorfällen und Exit.
• Schwachstellen-Tickets mit Schweregrad, Verantwortlichem, Behebungsdatum und Nachweisen zur Nachprüfung.
• PII-Bewertung, wenn die Subdomain personenbezogene Daten verarbeitet oder früher verarbeitet hat.
• Vorfallklassifizierungsdatensätze bei vermuteter oder bestätigter Übernahme.
• Lessons Learned und aktualisierte Verfahren nach Feststellungen.

Auch Kennzahlen sind wichtig. Die Leitung sollte die Anzahl externer Subdomains, den Anteil mit zugewiesenen Verantwortlichen, die Anzahl von Dangling-Feststellungen, die mittlere Behebungszeit, überfällige risikobehaftete Feststellungen, von Lieferanten gehostete Subdomains ohne aktuelle Vertragsreferenz und den Anteil der Cloud-Exits mit Nachweis der DNS-Entfernung sehen.

Diese Kennzahlen machen aus technischer Hygiene Nachweise für die Aufsicht durch das Management.

Häufige Fehlermuster, die Clarysec feststellt

Bei Kunden aus SaaS, Fintech, Gesundheitstechnologie, Managed Services und E-Commerce treten dieselben Muster immer wieder auf.

Erstens ist die DNS-Verantwortung auf Teams verteilt. Engineering verantwortet die Cloud. Marketing verantwortet Kampagnen. IT verantwortet den Zugriff auf den DNS-Anbieter. Der Einkauf verantwortet SaaS-Beendigungen. Niemand verantwortet den gesamten Lebenszyklus.

Zweitens wird das Löschen einer Cloud-Ressource als Ende des Dienstes behandelt. In Wirklichkeit können DNS, Zertifikate, WAF-Regeln, Überwachung, Geheimnisse, Dokumentation und Lieferantendatensätze bestehen bleiben.

Drittens konzentrieren sich Schwachstellenscanner auf aktive Hosts, verfehlen aber anbieterspezifische Übernahmebedingungen. Organisationen benötigen Prüfungen der externen Angriffsfläche, die gängige SaaS- und Cloud-Fehlerzustände verstehen.

Viertens konzentrieren sich Lieferanten-Exit-Verfahren auf Rechnungen und Datenrückgabe, nicht aber auf benutzerdefinierte Domains, DNS-Einträge und Änderungen bei Unterauftragsverarbeitern.

Fünftens werden Datenschutzteams zu spät informiert. Wenn eine Subdomain PII verarbeitet hat, muss der Datenschutzbeauftragte oder Datenschutzverantwortliche Teil der Klassifizierung sein, bevor Annahmen getroffen werden.

Sechstens existieren Nachweise, sind aber verteilt. Der DNS-Export liegt in einem Werkzeug, Änderungs-Tickets in einem anderen, Lieferantenverträge im Einkauf, Schwachstellenberichte in Scannern und Datenschutzanalysen in E-Mails. Auditoren sehen Fragmentierung als Schwäche.

Das Clarysec-Toolkit löst dies, indem es Richtlinien, Register, Kontrollen und Nachweis-Workflows verbindet.

Ein 30-Tage-Aktionsplan für DNS-Governance

Wenn Sie einen Dangling-DNS-Eintrag gefunden haben, gehen Sie davon aus, dass es weitere gibt. Wenn Sie keinen gefunden haben, stellen Sie sicher, dass Sie nachweisen können, warum.

Beginnen Sie mit diesem 30-Tage-Plan:

1. Alle maßgeblichen DNS-Zonen exportieren.
2. CNAME-, ALIAS-, A- und AAAA-Einträge identifizieren, die auf Cloud-, SaaS-, CDN- und von Agenturen verwaltete Dienste verweisen.
3. Verantwortliche und Geschäftszwecke zuweisen.
4. Übernahmeprüfungen durchführen und verdächtige Einträge manuell validieren.
5. Schwachstellen-Tickets für bestätigte Risiken erstellen.
6. Exponierte Einträge über die Änderungskontrolle entfernen oder zurückfordern.
7. Asset-Register, Cloud-Register und Lieferantenregister aktualisieren.
8. Prüfen, ob eine betroffene Subdomain PII verarbeitet hat.
9. Prüfungen des DNS-Lebenszyklus in Cloud-Onboarding, SaaS-Beschaffung und Lieferanten-Exit aufnehmen.
10. Kennzahlen an die Leitung berichten.

Die technische Behebung von Dangling DNS ist häufig einfach. Die Governance-Behebung verhindert die nächste Übernahme.

Clarysec kann Sie dabei unterstützen, dies mit Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls und unserem Richtlinien-Toolkit für Asset-Management, Cloud-Nutzung, Schwachstellenmanagement, Lieferanten-Governance, PII-Sicherheit, Incident Response und Auditnachweise zu operationalisieren.

Wenn Sie einen auditbereiten Ansatz benötigen, kann Clarysec Ihnen helfen, das Nachweispaket zur DNS- und Cloud-Exponierung aufzubauen, es auf ISO/IEC 27001:2022, NIS2, DORA und GDPR abzubilden und vergessene Subdomains in kontrollierte, verantwortete und überwachte Assets zu überführen. Laden Sie das relevante Clarysec-Toolkit herunter, fordern Sie eine Demo an oder planen Sie eine Bewertung der DNS-Governance, bevor ein Penetrationstester, Auditor oder Angreifer den nächsten vergessenen Verweis findet.