Governance van dangling DNS voor NIS2, DORA en GDPR

De CISO krijgt het bericht op maandag om 07:12.

Een beveiligingsonderzoeker heeft vastgesteld dat promo.company.com verwijst naar een verlaten cloudapplicatie. Het DNS-record is nog actief. De cloudresource bestaat niet meer. De SaaS-tenant die de campagne ooit ondersteunde, is zes maanden geleden verwijderd, kort nadat Marketing naar een ander platform was overgestapt. Niemand heeft de CNAME verwijderd.

Om 08:30 is de vraag niet langer: “Kan iemand het subdomein overnemen?” De vraag is: “Waarom wist niemand dat dit bedrijfsmiddel bestond?”

Om 09:15 is Juridische Zaken betrokken, omdat het subdomein ooit e-mailadressen verzamelde voor een productwachtlijst. Inkoop is betrokken, omdat het campagneplatform door een bureau werd beheerd. Compliance is betrokken, omdat het bedrijf zich voorbereidt op een ISO/IEC 27001:2022-controleaudit, NIS2-gereedheid en beveiligingsvragenlijsten van klanten. De functionaris voor gegevensbescherming vraagt of de blootstelling een inbreuk in verband met persoonsgegevens onder GDPR kan worden als het subdomein wordt misbruikt. De CFO vraagt of dezelfde zwakte ook een betaalportaal binnen de gereguleerde financiële-dienstverleningsomgeving van de groep kan raken.

De technische oplossing kan enkele minuten vergen. Het governanceprobleem kan maanden voortduren als de organisatie niet kan aantonen dat elk vanaf internet bereikbaar bedrijfsmiddel bekend is, een eigenaar heeft, wordt beoordeeld, wordt gemonitord en via een beheerst proces wordt uitgefaseerd.

Daarom mogen dangling DNS en preventie van subdomain takeover niet worden behandeld als een beperkte DNS-opschoontaak. Een verouderd DNS-record is vaak een zichtbaar symptoom van diepere tekortkomingen in de beheersing: een onvolledige inventaris van bedrijfsmiddelen, zwak eigenaarschap, ontbrekend bewijsmateriaal voor buitengebruikstelling, gebrekkig wijzigingsbeheer, ontoereikend leveranciers-exitmanagement, onvoldoende monitoring van het externe aanvalsoppervlak en onduidelijke incidentclassificatie.

Voor klanten van Clarysec is dangling DNS een toets van het managementsysteem. Het laat zien of beleid, beheersmaatregelen, registers, bewijsmateriaal en verantwoordingsplicht daadwerkelijk werken wanneer een vergeten cloudafhankelijkheid een kans voor een aanvaller wordt.

Wat dangling DNS werkelijk betekent

Subdomain takeover wordt mogelijk wanneer een DNS-record, vaak een CNAME, verwijst naar een resource die niet meer bestaat of niet langer onder beheer van de organisatie valt. Als een aanvaller de doelresource op het cloud- of SaaS-platform kan claimen of opnieuw kan aanmaken, kan hij mogelijk content aanbieden onder het vertrouwde subdomein van de organisatie.

Veelvoorkomende voorbeelden zijn:

• Een CNAME die verwijst naar een niet-geclaimde cloudappservice.
• Een vanity-SaaS-hostnaam die in DNS achterblijft nadat het abonnement is beëindigd.
• Een CDN-distributie die uit de providerconsole is verwijderd, maar nog steeds in publieke DNS wordt verwezen.
• Een marketingmicrosite die door een bureau buiten gebruik is gesteld zonder verwijdering uit DNS.
• Een opslagendpoint of mapping voor een statische website die opnieuw kan worden geregistreerd.
• Een ontwikkelsubdomein dat wordt blootgesteld via een vergeten platform-as-a-serviceproject.

De bedrijfsimpact kan aanzienlijk zijn. Aanvallers kunnen phishingpagina’s hosten, inloggegevens vastleggen, malware verspreiden, domeinreputatie misbruiken, sessiegegevens onderscheppen of merkvertrouwen schaden. Wanneer het subdomein eerder persoonsgegevens verwerkte, kan zelfs een kortstondige takeover een GDPR-datalekbeoordeling vereisen. Wanneer de betrokken dienst gereguleerde financiële activiteiten ondersteunt, moet het incident mogelijk ook worden beoordeeld onder DORA of interne kaders voor ICT-risicobeheer.

Auditors zien dangling DNS steeds vaker als bewijsmateriaal voor de volwassenheid van beheersmaatregelen. Eén verouderd record kan erop wijzen dat de organisatie niet weet wat zij bezit, wie eigenaar is, hoe wijzigingen worden beoordeeld, hoe cloudservices worden beëindigd of hoe extern bereikbare bedrijfsmiddelen worden gemonitord.

Daarom koppelt Clarysec dit onderwerp aan auditverwachtingen uit ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT 2019.

Waarom ISO 27001:2022 de praktische ruggengraat is

De sterkste manier om dangling DNS te beheersen is niet het opzetten van afzonderlijke programma’s voor NIS2, DORA en GDPR. De juiste aanpak is ISO/IEC 27001:2022 gebruiken als ruggengraat van het managementsysteem en één keer bewijsmateriaal genereren voor meerdere assurancebehoeften.

De relevante vereisten beginnen al vóór Annex A. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie haar context, de eisen van belanghebbenden, het ISMS-toepassingsgebied en afhankelijkheden met andere organisaties begrijpt. Voor governance van dangling DNS moet het toepassingsgebied externe DNS, domeinen, registrars, cloudservices, SaaS-platformen, bureaus, beheerde hosting, CDN’s en elke derde partij omvatten die vanaf internet bereikbare diensten kan aanmaken of uitfaseren.

Clausules 5.1 tot en met 5.3 maken dit tot een kwestie van leiderschap en verantwoordingsplicht. Het management moet het ISMS afstemmen op de bedrijfsrichting, middelen beschikbaar stellen, het belang van informatiebeveiliging communiceren en verantwoordelijkheden toewijzen. Als Marketing een microsite kan lanceren, Engineering cloudendpoints kan aanmaken en Inkoop SaaS-contracten kan beëindigen, heeft de organisatie een governancemodel nodig dat DNS- en diensteneigenaarschap duidelijk aan al deze partijen toewijst.

Clausules 6.1.1 tot en met 6.1.3 bieden de logica voor risicobeoordeling, risicobehandeling en de Verklaring van Toepasselijkheid. Dangling DNS moet worden vastgelegd als een realistisch risicoscenario, niet alleen als scanneruitvoer. Het raakt vertrouwelijkheid, integriteit en beschikbaarheid en wordt vaak gekoppeld aan wettelijke, regelgevende en contractuele verplichtingen.

Clausules 7.5, 8.1, 8.2 en 8.3 zetten governance om in bewijsmateriaal. Zij vereisen beheerste gedocumenteerde informatie, geplande en beheerste operationele processen, aandacht voor onbedoelde wijzigingen, beheersing van extern geleverde processen, periodieke risicobeoordelingen en gedocumenteerde behandeluitkomsten.

Annex A biedt vervolgens de catalogus van beheersmaatregelen. In Clarysec-projecten zien de kernrelaties met ISO/IEC 27002:2022 er doorgaans als volgt uit:

De kern is eenvoudig. ISO/IEC 27001:2022 vraagt niet om een eenmalige heroïsche opruimactie. De norm vraagt om een beheerst operationeel model dat herhaling voorkomt.

De Zenith Controls-benadering: één risico, drie ankers voor beheersmaatregelen

In Zenith Controls: The Cross-Compliance Guide Zenith Controls gebruikt Clarysec relevante ISO/IEC 27002:2022-beheersmaatregelen als ankers voor koppeling aan meerdere compliancekaders. Voor governance van dangling DNS en subdomain takeover staan drie beheersmaatregelen centraal.

Beheersmaatregel 5.9, Inventaris van informatie en andere bijbehorende bedrijfsmiddelen, is geclassificeerd als preventief, ondersteunt vertrouwelijkheid, integriteit en beschikbaarheid, sluit aan op het cybersecurityconcept Identify en valt onder beheer van bedrijfsmiddelen als operationele capability, met governance, ecosysteem en bescherming als beveiligingsdomeinen.

Beheersmaatregel 5.23, Informatiebeveiliging voor het gebruik van cloudservices, is geclassificeerd als preventief, ondersteunt vertrouwelijkheid, integriteit en beschikbaarheid, sluit aan op Protect en valt onder beveiliging van leveranciersrelaties als operationele capability, met governance, ecosysteem en bescherming als beveiligingsdomeinen.

Beheersmaatregel 8.8, Beheer van technische kwetsbaarheden, is geclassificeerd als preventief, ondersteunt vertrouwelijkheid, integriteit en beschikbaarheid, sluit aan op Identify en Protect en valt onder dreigings- en kwetsbaarhedenbeheer als operationele capability, met governance, ecosysteem, bescherming en verdediging als beveiligingsdomeinen.

Dit is belangrijk omdat dangling DNS niet alleen een falen van assetbeheersmaatregelen is, niet alleen een falen van cloudbeheersmaatregelen en niet alleen een kwetsbaarheid. Het is alle drie tegelijk. De organisatie moet aantonen dat de inventaris van bedrijfsmiddelen, governance van cloudgebruik en kwetsbaarhedenbeheer elkaar versterken.

Clarysec voegt rond deze ankers vaak ondersteunende praktijken toe: ISO/IEC 27005 voor discipline in risicobeoordeling en risicobehandeling, ISO/IEC 27017 voor governance van cloudservicebeveiliging, ISO/IEC 27018 wanneer cloudservices PII verwerken, ISO/IEC 27701 voor privacy-informatiemanagement en ISO 22301 wanneer continuïteit en crisisrespons relevant zijn.

Het beleidsbewijsmateriaal dat DNS-levenscyclusbeheer al vereist

Veel organisaties hebben al beleid dat, mits goed geïmplementeerd, dangling DNS zou voorkomen. Het hiaat is dat DNS-levenscyclusbeheer niet expliciet aan dat beleid is gekoppeld.

Clarysec’s Asset Management Policy-sme Asset Management Policy-sme - SME, Vereisten voor beleidsimplementatie, clausule 6.6.1 bepaalt:

Cloudgebaseerde bedrijfsmiddelen (bijvoorbeeld opslagaccounts, SaaS-platformen, webdomeinen) moeten ook in de inventaris worden opgenomen.

Hetzelfde beleid voegt in clausule 6.6.2 toe:

Eigenaarschap, doel, toegangsrechten en verlengingstermijnen moeten worden gedocumenteerd.

Voor governance van dangling DNS betekent dit dat elk productiesubdomein en elk materieel niet-productiesubdomein een benoemde eigenaar, bedrijfsdoel, gekoppelde dienst, toegangsmodel en beoordelingsdatum moet hebben.

Het belangrijkst is clausule 6.6.3:

Verlopen of ongebruikte diensten moeten worden gedeactiveerd en uit de inventaris worden verwijderd.

Voor DNS moet dit zorgvuldig worden geïnterpreteerd. De dienst uit de inventaris verwijderen is niet genoeg. Het DNS-record, de cloudbinding, de claim op het SaaS-maatwerkdomein, het certificaat, de WAF-regel, de CDN-configuratie en de monitoringregistratie moeten ook worden beoordeeld.

De enterpriseversie versterkt dit bredere assetbegrip. Clarysec’s Asset Management Policy Asset Management Policy, Reikwijdte, clausule 2.2.5 bepaalt:

Logische bedrijfsmiddelen: domeinnamen, licenties, gebruikersaccounts, configuratiebaselines

Domeinnamen en configuraties zijn geen administratieve details. Het zijn bedrijfsmiddelen die vertrouwen dragen en aanvalspaden kunnen worden.

De koppeling met wijzigingsbeheer is even belangrijk. Clarysec’s Change Management Policy Change Management Policy, Doel, clausule 1.1 bepaalt:

Dit beleid stelt een formeel kader vast voor het initiëren, beoordelen, goedkeuren, implementeren en evalueren van wijzigingen in de informatiesystemen, infrastructuur, toepassingen en gerelateerde processen van de organisatie.

Een DNS-verwijdering, SaaS-beëindiging, verwijdering van een cloudapplicatie, CDN-migratie of uitfasering van een marketingmicrosite moet daarom wijzigingsbewijsmateriaal opleveren. Het ontbreken van een wijzigingsticket is vaak het eerste auditalarmsignaal.

Ook cloudgovernance moet worden gekoppeld. Clarysec’s Cloud Usage Policy Cloud Usage Policy, Governancevereisten, clausule 5.5 bepaalt:

Het informatiebeveiligingsteam moet netwerkverkeer, DNS-activiteit en logboeken regelmatig beoordelen om ongeautoriseerd cloudgebruik (shadow IT) te detecteren. Vastgestelde overtredingen moeten onverwijld worden onderzocht.

Voor preventie van subdomain takeover gaat monitoring van DNS-activiteit niet alleen over shadow IT. Het gaat ook over verouderde IT: bedrijfsmiddelen die ooit geautoriseerd waren, maar niet langer onder beheer staan.

Een praktische Clarysec-workflow voor governance van dangling DNS

Een sterk programma voor dangling DNS is niet ingewikkeld. Het is gedisciplineerd, herhaalbaar en gekoppeld aan het ISMS, kwetsbaarhedenbeheer, wijzigingsbeheer en de leverancierslevenscyclus.

Voor mkb-organisaties kan dit beginnen als een lichtgewicht register. Voor ondernemingen integreert dit doorgaans DNS-exporten, beheer van het externe aanvalsoppervlak, cloudassetinventarissen, CMDB-registraties, kwetsbaarheidsscanners, SIEM-waarschuwingen en ticketingsystemen.

De governancevraag blijft dezelfde: kunt u aantonen dat elk extern bereikbaar subdomein bekend is, een eigenaar heeft, wordt gemonitord en via een beheerst proces verwijderbaar is?

Het verlaten campagnesubdomein, correct afgehandeld

Terug naar het incident op maandag. promo.company.com verwijst naar een verlaten SaaS-campagnesite.

Eerst maakt de beveiligingsverantwoordelijke een kwetsbaarheidsregistratie aan, omdat het bedrijfsmiddel extern bereikbaar is. Clarysec’s Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, Vereisten voor beleidsimplementatie, clausule 6.1.1 bepaalt:

Alle systemen moeten ten minste maandelijks worden gescand; bedrijfsmiddelen met een hoog risico of extern blootgestelde bedrijfsmiddelen moeten wekelijks worden gescand.

Voor mkb-organisaties scherpt het equivalente beleid de prioritering aan. De Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Vereisten voor beleidsimplementatie, clausule 6.5.1 bepaalt:

Systemen die persoonsgegevens verwerken, toegang op afstand bieden of extern bereikbaar zijn, moeten prioriteit krijgen voor scanning en updates.

Ten tweede wordt de eigenaar via het assetregister geïdentificeerd. Als de eigenaar onbekend is, is dat een falen van de beheersing rond assetgovernance. Het register wordt bijgewerkt met DNS-naam, doelprovider, oorspronkelijke bedrijfseigenaar, gegevensclassificatie, leverancier en status.

Ten derde controleert IT het cloud- of SaaS-platform. Als het cloudaccount is verwijderd, is Clarysec’s Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, Vereisten voor beleidsimplementatie, clausule 6.3.6 direct relevant:

Verwijderde cloudaccounts moeten door de IT-provider of algemeen directeur worden beoordeeld op resterende toegang, verweesde gegevens of over het hoofd geziene content.

Ten vierde dient de wijzigingseigenaar een noodwijziging of versnelde wijziging in om het DNS-record te verwijderen of de resource tijdelijk opnieuw te claimen vóór verwijdering. Het ticket bevat een impactbeoordeling, rollbackplan, goedkeuringen, implementatiebewijsmateriaal en validatie na de wijziging.

Ten vijfde beoordeelt de privacyverantwoordelijke of het subdomein persoonsgegevens verwerkte of had kunnen blootstellen. Clarysec’s PII Security and Access Control Policy PII Security and Access Control Policy, Beveiligde configuratie en kwetsbaarhedenbeheer, clausule 4.7.4 bepaalt:

[Both] De systeemeigenaar / applicatie-eigenaar MOET de dekking van kwetsbaarheidsbeoordelingen voor systemen die PII verwerken ten minste elk kwartaal en na een wezenlijke technische wijziging in REG12 vastleggen.

Clausule 4.7.5 voegt toe:

[Both] De informatiebeveiligingsverantwoordelijke MOET onopgeloste hoogrisicokwestbaarheden die PII raken binnen vijf werkdagen na validatie in REG12 vastleggen.

Deze clausules zijn van toepassing ongeacht of de organisatie als verwerkingsverantwoordelijke of verwerker optreedt, omdat zij zijn gemarkeerd als [Both]. Bij een dangling-DNS-kwestie waarbij PII betrokken is, mag het bewijsmateriaal niet alleen in een technisch ticket staan. Het moet worden weerspiegeld in het bewijsmateriaalregister voor PII-kwetsbaarheden.

Ten zesde controleert Inkoop de registraties van derden als een bureau of SaaS-provider de campagne hostte. Clarysec’s Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Relatie-identificatie en classificatie, clausule 4.1.2 bepaalt:

[All] De proceseigenaar / bedrijfseigenaar MOET elke voorgenomen relatie met een derde partij die PII zal verwerken, benaderen, ontvangen, opslaan, doorgeven, ondersteunen of anderszins beïnvloeden vóór inkoop, onboarding, verlenging of een wezenlijke privacywijziging bij een derde partij in REG08 identificeren.

Clausule 4.5.5 vereist:

[Both] De leveranciers- / inkoopeigenaar MOET verwerkingslocaties, hostinglocaties en indicatoren voor internationale doorgiften in REG08 vastleggen en toepasselijk doorgiftebewijsmateriaal aan REG09 koppelen voordat een verwerker, subverwerker, locatiewijziging of doorgifterelevante dienstwijziging wordt goedgekeurd.

Tot slot bundelt de complianceverantwoordelijke het bewijsmateriaal. Clarysec’s Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Doelstellingen, clausule 3.4 bepaalt dat één doelstelling is:

Het genereren van verdedigbaar bewijsmateriaal en een audittrail ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of verzoeken om assurance van klanten.

Dat is de uitkomst die de CISO nodig heeft wanneer een klant, toezichthouder of auditor vraagt: “Hoe weet u dat dit niet opnieuw gebeurt?”

Waar de Zenith Blueprint past

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint zet beheersmaatregelen om in operationele praktijken die geschikt zijn voor audits. Dangling DNS sluit sterk aan op vier gebieden.

In de fase Controls in Action behandelt stap 22 organisatorische beheersmaatregelen 5.1 tot en met 5.18, waaronder ISO/IEC 27002:2022-beheersmaatregel 5.9. De Zenith Blueprint stelt:

Geen enkele organisatie kan beschermen wat zij niet weet te bezitten. Beheersmaatregel 5.9 formaliseert dit fundamentele principe en vereist de inrichting en het onderhoud van een actuele inventaris van alle informatie en bijbehorende bedrijfsmiddelen die relevant zijn voor het ISMS.

De tekst vervolgt:

In zijn meest strategische vorm fungeert een inventaris van bedrijfsmiddelen als het centrale zenuwstelsel van uw ISMS.

Uw subdomeininventaris is geen nevenlijst. Zij voedt toegangsbesluiten, kwetsbaarheidsscans, logging, leveranciersmanagement, privacymapping en incidentrespons.

In stap 20 behandelt de Zenith Blueprint technische beheersmaatregelen 8.18 tot en met 8.26. Voor beheersmaatregel 8.21, Beveiliging van netwerkdiensten, instrueert zij organisaties de beveiliging van netwerkdiensten te valideren:

Maak een overzicht van alle interne en externe netwerkdiensten (DNS, VPN, SMTP, DHCP, API-gateways, enz.).

Daarom horen DNS-providers, registrars, cloud-DNS, CDN-platformen en SaaS-functionaliteiten voor maatwerkdomeinen thuis in het dienstenregister.

In stap 19 behandelt de Zenith Blueprint technische beheersmaatregelen 8.1 tot en met 8.17. Voor beheersmaatregel 8.8 stelt zij:

Het beheren van kwetsbaarheden is een van de meest kritieke onderdelen van moderne cyberhygiëne. Hoewel firewalls en antivirus-tools bescherming bieden, kunnen zij worden ondermijnd wanneer ongepatchte systemen of verkeerd geconfigureerde diensten blootgesteld blijven.

Een dangling DNS-record is een verkeerd geconfigureerd extern dienstpad. Ook wanneer er geen CVE is, moet het via kwetsbaarhedenbeheer worden afgehandeld: valideren, scoren, toewijzen, remediëren, hertesten en sluiten.

In stap 23 behandelt de Zenith Blueprint organisatorische beheersmaatregelen 5.19 tot en met 5.37. Voor beheersmaatregel 5.23 adviseert zij:

Maak een overzicht van alle cloudservices die momenteel in gebruik zijn (5.23), inclusief shadow IT waar bekend. Identificeer wie ze heeft goedgekeurd en of due diligence is uitgevoerd. Ontwikkel een lichtgewicht beoordelingschecklist die gegevenslocatie, toegangsmodel, logging en encryptie afdekt.

Voeg voor preventie van subdomain takeover maatwerkdomeinen, DNS-afhankelijkheden, eigenaar voor buitengebruikstelling en exitbewijsmateriaal toe aan die beoordelingschecklist voor clouddiensten.

Koppeling aan NIS2, DORA en GDPR

NIS2 maakt governance van dangling DNS voor veel essentiële en belangrijke entiteiten tot een onderwerp op bestuursniveau. Article 20 vereist dat leidinggevende organen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren, toezicht houden op de implementatie en cyberbeveiligingstraining volgen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen op basis van een benadering die alle risico’s omvat. De minimumgebieden omvatten risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving, ontwikkeling en onderhoud, kwetsbaarheidsafhandeling, beoordeling van doeltreffendheid, cyberhygiëne, training, toegangscontrole en beheer van bedrijfsmiddelen.

Een programma voor dangling DNS sluit rechtstreeks aan op deze gebieden. Article 21(3) vereist ook dat beveiliging van de toeleveringsketen rekening houdt met kwetsbaarheden die specifiek zijn voor elke directe leverancier of dienstverlener. Als een marketingbureau, SaaS-leverancier, aanbieder van beheerde hosting of cloudplatform maatwerkdomeinen beheert, moeten leveranciersspecifieke beheersmaatregelen DNS-eigenaarschap, dienstbeëindiging, incidentondersteuning en overdracht van bewijsmateriaal afdekken.

Article 23 is relevant wanneer takeover plaatsvindt of ernstige operationele verstoring, financieel verlies of aanzienlijke materiële of immateriële schade kan veroorzaken. NIS2 hanteert gefaseerde rapportage: een vroegtijdige waarschuwing binnen 24 uur na kennisname van een significant incident, een melding binnen 72 uur, tussentijdse rapportages wanneer daarom wordt verzocht en een eindrapport binnen één maand na de incidentmelding.

Voor financiële entiteiten is DORA het sectorspecifieke regime voor digitale operationele weerbaarheid. Articles 5 en 6 vereisen een intern governance- en beheersingskader voor ICT-risicobeheer, met eindverantwoordelijkheid van het leidinggevend orgaan, duidelijke ICT-rollen, beleid voor beschikbaarheid, authenticiteit, integriteit en vertrouwelijkheid van gegevens, auditplannen, middelen, beleid voor diensten van derden en een gedocumenteerd ICT-risicobeheerkader.

Articles 8 tot en met 14 vormen de operationele kern. Article 8 vereist identificatie, classificatie en documentatie van door ICT ondersteunde bedrijfsfuncties, informatieactiva, ICT-activa, afhankelijkheden, ICT-interconnecties met derde partijen, inventarissen, risicoscenario’s en legacy-systemen. Een dangling CNAME is vaak een gemiste afhankelijkheid. Article 9 vereist bescherming en preventie. Article 10 vereist detectie van afwijkende activiteit, ICT-incidenten en mogelijke single points of failure. Articles 11 en 12 behandelen continuïteit, herstel, back-up en herstel na back-up. Article 13 vereist leren van kwetsbaarheden, dreigingen, incidenten en tests.

Articles 17 tot en met 19 formaliseren incidentbeheer, classificatie en rapportage. Articles 28 tot en met 30 maken ICT-risico’s van derde partijen levenscyclusgebaseerd. Financiële entiteiten blijven volledig verantwoordelijk wanneer zij ICT-dienstverleners gebruiken. Voor DORA-gereedheid adviseert Clarysec vier velden toe te voegen aan elk DNS- en cloudserviceregister: ondersteuning van kritieke of belangrijke functie, derde aanbieder van ICT-diensten, contract- of registerreferentie en status van de exittest.

GDPR is van toepassing wanneer de kwestie persoonsgegevens betreft. Een subdomain takeover is niet automatisch een inbreuk in verband met persoonsgegevens, maar kan dat wel worden als het betrokken subdomein inloggegevens verzamelt, formuliergegevens vastlegt, zich voordoet als een dienst, gebruikersidentificatoren blootstelt of ongeautoriseerde toegang tot persoonsgegevens mogelijk maakt. GDPR Article 5 vereist integriteit, vertrouwelijkheid en verantwoordingsplicht. Article 32 vereist passende beveiliging van de verwerking. Article 33 kan melding aan de toezichthoudende autoriteit vereisen als een inbreuk in verband met persoonsgegevens waarschijnlijk een risico inhoudt voor de rechten en vrijheden van natuurlijke personen.

Clarysec’s PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Classificatie en datalekbeoordeling, clausule 4.2.6 ondersteunt deze triggeranalyse over meerdere regimes:

[Conditional] De Privacy Lead / PIMS Manager MOET toepasselijke juridische, sectorale, financiële-sector-, cyberbeveiligings-, contractuele, klant- en dienstontvangergerelateerde rapportagetriggers voor elk incident met hoge impact met betrekking tot persoonsgegevens beoordelen en de toepasselijkheidsuitkomst vastleggen in REG01, REG08 en REG10.

Die besluitregistratie is precies wat nodig is wanneer een subdomain takeover GDPR, NIS2, DORA, contracten en klantmeldingen kan raken.

Hoe auditors uw bewijsmateriaal toetsen

Een geïntegreerd ISMS moet het mogelijk maken verschillende auditors met dezelfde bewijsbasis te beantwoorden. De formulering van de vraag verandert, maar het bewijsmateriaal is vaak hetzelfde.

Een breder assuranceperspectief omvat vaak NIST CSF 2.0 en COBIT 2019. NIST CSF 2.0 helpt de doeltoestand uit te drukken via GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- en RECOVER-uitkomsten. Een Current Profile kan handmatige kwartaalbeoordelingen van DNS en inconsistente SaaS-offboarding laten zien. Een Target Profile kan geautomatiseerde wekelijkse takeovercontroles, verplichte toewijzing van eigenaren, leveranciers-exitbewijsmateriaal en integratie met wijzigingsbeheer vereisen.

Een COBIT 2019- of ISACA-georiënteerde auditor zal doorgaans vragen wie eigenaar is van het proces, hoe risico wordt geëvalueerd en gestuurd, of wijzigingen worden beheerst, of leveranciers worden beheerd, of configuratie en bedrijfsmiddelen betrouwbaar zijn en of assurancebewijsmateriaal managementrapportage ondersteunt. Zij vragen mogelijk niet eerst om een lijst met CNAMEs. Zij kunnen vragen hoe het management weet dat externe digitale diensten gedurende hun volledige levenscyclus worden beheerst.

Hoe goed auditbewijsmateriaal eruitziet

Een auditpakket voor dangling DNS moet klein genoeg zijn om te onderhouden, maar volledig genoeg om verdedigbaar te zijn. Clarysec adviseert doorgaans de volgende set bewijsmateriaal:

• DNS-zone-inventaris met bron, datum, recordtype, doel en eigenaar.
• Scanresultaten van het externe aanvalsoppervlak met takeovercontroles.
• Registraties in het assetregister voor domeinen, subdomeinen, cloudservices, SaaS-toepassingen en CDN’s.
• Dienstenregister met interne of leveranciersverantwoordelijkheid.
• Wijzigingstickets voor het aanmaken, wijzigen en verwijderen van DNS-records.
• Onboardingchecklists voor cloud en SaaS, inclusief beoordeling van maatwerkdomeinen en DNS.
• Leverancierscontracten of beveiligingsclausules over DNS, hosting, incidentondersteuning en exit.
• Kwetsbaarheidstickets met ernst, eigenaar, remediatiedatum en hertestbewijsmateriaal.
• PII-beoordeling wanneer het subdomein persoonsgegevens verwerkt of eerder verwerkte.
• Incidentclassificatieregistraties voor vermoedelijke of bevestigde takeover.
• Geleerde lessen en bijgewerkte procedures na bevindingen.

Metrieken zijn ook belangrijk. Het management moet zicht hebben op het aantal externe subdomeinen, het percentage met toegewezen eigenaren, het aantal dangling-bevindingen, de gemiddelde remediatietijd, achterstallige hoogrisicobevindingen, door leveranciers gehoste subdomeinen zonder actuele contractreferentie en het percentage cloudexits met bewijsmateriaal voor DNS-verwijdering.

Deze metrieken zetten technische hygiëne om in bewijsmateriaal voor managementtoezicht.

Veelvoorkomende tekortkomingspatronen die Clarysec aantreft

Bij klanten in SaaS, fintech, zorgtechnologie, beheerde diensten en e-commerce keren dezelfde patronen terug.

Ten eerste is DNS-eigenaarschap verdeeld over teams. Engineering beheert cloud. Marketing beheert campagnes. IT beheert toegang tot de DNS-provider. Inkoop beheert SaaS-beëindiging. Niemand beheert de volledige levenscyclus.

Ten tweede wordt verwijdering uit de cloud gezien als het einde van de dienst. In werkelijkheid kunnen DNS, certificaten, WAF-regels, monitoring, secrets, documentatie en leveranciersregistraties blijven bestaan.

Ten derde richten kwetsbaarheidsscanners zich op live hosts, maar missen zij providerspecifieke takeovercondities. Organisaties hebben controles van het externe aanvalsoppervlak nodig die gangbare fouttoestanden van SaaS- en cloudproviders begrijpen.

Ten vierde richten leveranciers-exitprocedures zich op facturen en teruggave van gegevens, maar niet op maatwerkdomeinen, DNS-records en subverwerkerswijzigingen.

Ten vijfde worden privacyteams te laat geïnformeerd. Als een subdomein PII verwerkte, moet de functionaris voor gegevensbescherming of privacyverantwoordelijke deel uitmaken van de classificatie voordat aannames worden gedaan.

Ten zesde bestaat bewijsmateriaal wel, maar is het versnipperd. De DNS-export staat in de ene tool, wijzigingstickets in een andere, leverancierscontracten bij Inkoop, kwetsbaarheidsrapporten in scanners en privacyanalyse in e-mail. Auditors zien versnippering als een zwakte.

De toolkit van Clarysec lost dit op door beleid, registers, beheersmaatregelen en bewijsworkflows met elkaar te verbinden.

Een 30-dagenactieplan voor DNS-governance

Als u één dangling DNS-record hebt gevonden, ga er dan van uit dat er meer zijn. Als u er geen hebt gevonden, zorg dan dat u kunt aantonen waarom.

Start met dit 30-dagenplan:

1. Exporteer alle gezaghebbende DNS-zones.
2. Identificeer CNAME-, ALIAS-, A- en AAAA-records die verwijzen naar cloud-, SaaS-, CDN- en door bureaus beheerde diensten.
3. Wijs eigenaren en bedrijfsdoelen toe.
4. Voer takeovercontroles uit en valideer verdachte records handmatig.
5. Maak kwetsbaarheidstickets aan voor bevestigde risico’s.
6. Verwijder of claim blootgestelde records opnieuw via wijzigingsbeheer.
7. Werk het assetregister, cloudregister en leveranciersregister bij.
8. Beoordeel of een betrokken subdomein PII verwerkte.
9. Voeg DNS-levenscycluscontroles toe aan cloudonboarding, SaaS-inkoop en leveranciers-exit.
10. Rapporteer metrieken aan het management.

De technische oplossing voor dangling DNS is vaak eenvoudig. De governanceoplossing voorkomt de volgende takeover.

Clarysec kan u helpen dit operationeel te maken met Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls en onze beleidstoolkit voor beheer van bedrijfsmiddelen, cloudgebruik, kwetsbaarhedenbeheer, leveranciersgovernance, PII-beveiliging, incidentrespons en auditbewijsmateriaal.

Als u een aanpak wilt die geschikt is voor audits, kan Clarysec u helpen het bewijspakket voor DNS- en cloudblootstelling op te bouwen, dit te koppelen aan ISO/IEC 27001:2022, NIS2, DORA en GDPR, en vergeten subdomeinen om te zetten in beheerste bedrijfsmiddelen met een eigenaar en monitoring. Download de relevante Clarysec-toolkit, vraag een demo aan of plan een DNS-governancebeoordeling voordat een penetratietester, auditor of aanvaller de volgende vergeten verwijzing vindt.