Styring af dangling DNS for NIS2, DORA og GDPR

CISO’en modtager beskeden kl. 07:12 en mandag.

En sikkerhedsresearcher har fundet promo.company.com, som peger på en nedlagt cloudapp. DNS-posten er stadig aktiv. Cloudressourcen er væk. Den SaaS-tenant, der tidligere betjente kampagnen, blev slettet for seks måneder siden, kort efter at marketing skiftede til en anden platform. Ingen fjernede CNAME-posten.

Kl. 08:30 er spørgsmålet ikke længere: “Kan nogen overtage subdomænet?” Det er: “Hvorfor vidste ingen, at dette aktiv fandtes?”

Kl. 09:15 er juridisk afdeling involveret, fordi subdomænet tidligere indsamlede e-mailadresser til en produktventeliste. Indkøb er involveret, fordi kampagneplatformen blev administreret af et bureau. Compliance er involveret, fordi virksomheden forbereder ISO/IEC 27001:2022-overvågningsrevision, NIS2-parathed og sikkerhedsspørgeskemaer fra kunder. DPO’en spørger, om eksponeringen kan blive et brud på persondatasikkerheden efter GDPR, hvis subdomænet misbruges. CFO’en spørger, om den samme svaghed kan påvirke en betalingsportal i koncernens regulerede finansielle miljø.

Den tekniske afhjælpning kan tage få minutter. Styringsproblemet kan tage måneder at udrede, hvis organisationen ikke kan dokumentere, at hvert internetvendt aktiv er kendt, ejet, gennemgået, overvåget og afviklet gennem en kontrolleret proces.

Derfor kan dangling DNS og forebyggelse af overtagelse af subdomæner ikke behandles som en snæver DNS-oprydningsopgave. En forældet DNS-post er ofte et synligt symptom på dybere kontrolsvigt: ufuldstændig aktivfortegnelse, uklart ejerskab, manglende dokumentation for udfasning, svag ændringsstyring, utilstrækkelig styring af leverandørafvikling, utilstrækkelig overvågning af den eksterne angrebsflade og uklar hændelsesklassificering.

For Clarysec-kunder er dangling DNS en test af ledelsessystemet. Det viser, om politikker, kontroller, registre, bevismateriale og ansvarlighed faktisk fungerer, når en glemt cloudafhængighed bliver en mulighed for en angriber.

Hvad dangling DNS reelt betyder

Overtagelse af et subdomæne bliver mulig, når en DNS-post, ofte en CNAME-post, peger på en ressource, der ikke længere findes eller ikke længere kontrolleres af organisationen. Hvis en angriber kan gøre krav på eller genskabe målressourcen på cloud- eller SaaS-platformen, kan angriberen muligvis levere indhold under organisationens betroede subdomæne.

Almindelige eksempler omfatter:

• En CNAME-post, der peger på en cloudapptjeneste, som ingen har gjort krav på.
• Et vanity-hostnavn i en SaaS-løsning, der er efterladt i DNS, efter at abonnementet blev opsagt.
• En CDN-distribution, der er fjernet fra udbyderens konsol, men stadig refereres i offentlig DNS.
• Et marketingmikrosite, der er udfaset af et bureau uden fjernelse af DNS-posten.
• Et storage-endpoint eller en mapping til et statisk website, som kan registreres igen.
• Et udviklingssubdomæne, der er eksponeret gennem et glemt platform-as-a-service-projekt.

Den forretningsmæssige konsekvens kan være alvorlig. Angribere kan hoste phishing-sider, opsamle legitimationsoplysninger, distribuere malware, misbruge domænets omdømme, opsnappe sessionsdata eller skade tilliden til brandet. Hvis subdomænet tidligere behandlede personoplysninger, kan selv en kortvarig overtagelse udløse en GDPR-vurdering af brud på persondatasikkerheden. Hvis den berørte tjeneste understøtter regulerede finansielle aktiviteter, kan hændelsen også skulle vurderes efter DORA eller interne styringsrammer for IKT-risiko.

Revisorer ser i stigende grad dangling DNS som bevismateriale for kontrolmodenhed. En enkelt forældet post kan indikere, at organisationen ikke ved, hvilke aktiver den ejer, hvem der ejer dem, hvordan ændringer gennemgås, hvordan cloudtjenester afvikles, eller hvordan eksternt eksponerede aktiver overvåges.

Derfor kortlægger Clarysec dette problem på tværs af ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019-revisionsforventninger.

Hvorfor ISO 27001:2022 er den praktiske rygrad

Den stærkeste måde at styre dangling DNS på er ikke at etablere særskilte programmer for NIS2, DORA og GDPR. Det er at anvende ISO/IEC 27001:2022 som rygraden i ledelsessystemet og generere bevismateriale én gang til flere assurance-behov.

De relevante krav begynder før Annex A. Klausul 4.1 til 4.4 kræver, at organisationen forstår sin kontekst, interessentkrav, ISMS-omfang og afhængigheder til andre organisationer. For styring af dangling DNS bør omfanget omfatte ekstern DNS, domæner, registratorer, cloudtjenester, SaaS-platforme, bureauer, managed hosting, CDN’er og enhver tredjepart, der kan oprette eller afvikle internetvendte tjenester.

Klausul 5.1 til 5.3 gør dette til et spørgsmål om ledelse og ansvarlighed. Ledelsen skal afstemme ISMS’et med forretningens retning, stille ressourcer til rådighed, kommunikere betydningen af informationssikkerhed og tildele ansvar. Hvis marketing kan lancere et mikrosite, engineering kan oprette cloud-endpoints, og indkøb kan opsige SaaS-kontrakter, har organisationen brug for en styringsmodel, der tildeler klart ejerskab til DNS og tjenester på tværs af alle disse funktioner.

Klausul 6.1.1 til 6.1.3 giver logikken for risikovurdering, risikobehandling og anvendelseserklæring. Dangling DNS skal registreres som et realistisk risikoscenarie, ikke blot som output fra en scanner. Det påvirker fortrolighed, integritet og tilgængelighed og knytter sig ofte til retlige, regulatoriske og kontraktlige forpligtelser.

Klausul 7.5, 8.1, 8.2 og 8.3 omsætter styring til bevismateriale. De kræver kontrolleret dokumenteret information, planlagte og kontrollerede driftsprocesser, hensyntagen til utilsigtede ændringer, styring af eksternt leverede processer, periodiske risikovurderinger og dokumenterede behandlingsresultater.

Annex A giver derefter kontrolkataloget. I Clarysec-projekter ser de centrale relationer til ISO/IEC 27002:2022 typisk sådan ud:

Pointen er enkel. ISO/IEC 27001:2022 kræver ikke en heroisk engangsoprydning. Den kræver en kontrolleret driftsmodel, der forebygger gentagelse.

Zenith Controls-perspektivet: én risiko, tre kontrolankre

I Zenith Controls: vejledningen til kortlægning på tværs af efterlevelseskrav Zenith Controls anvender Clarysec relevante ISO/IEC 27002:2022-kontroller som ankre for kortlægning på tværs af efterlevelseskrav. For styring af dangling DNS og overtagelse af subdomæner er tre kontroller centrale.

Kontrol 5.9, Inventory of information and other associated assets, klassificeres som forebyggende, understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedskonceptet Identify og hører under styring af aktiver som operationel kapabilitet med styring, økosystem og beskyttelse som sikkerhedsdomæner.

Kontrol 5.23, Information security for use of cloud services, klassificeres som forebyggende, understøtter fortrolighed, integritet og tilgængelighed, er tilpasset Protect og hører under sikkerhed i leverandørrelationer som operationel kapabilitet med styring, økosystem og beskyttelse som sikkerhedsdomæner.

Kontrol 8.8, Management of technical vulnerabilities, klassificeres som forebyggende, understøtter fortrolighed, integritet og tilgængelighed, er tilpasset Identify og Protect og hører under trussels- og sårbarhedsstyring som operationel kapabilitet med styring, økosystem, beskyttelse og forsvar som sikkerhedsdomæner.

Det er vigtigt, fordi dangling DNS ikke kun er et svigt i aktivkontroller, ikke kun et svigt i cloudkontroller og ikke kun en sårbarhed. Det er alle tre dele. Organisationen skal vise, at aktivfortegnelse, styring af brugen af cloudtjenester og sårbarhedsstyring forstærker hinanden.

Clarysec tilføjer ofte understøttende praksisser omkring disse ankre: ISO/IEC 27005 for disciplin i risikovurdering og risikobehandling, ISO/IEC 27017 for sikkerhedsstyring af cloudtjenester, ISO/IEC 27018 hvor cloudtjenester behandler PII, ISO/IEC 27701 for ledelsessystem for databeskyttelse og ISO 22301 hvor forretningskontinuitet og krisehåndtering er relevante.

Det politikbaserede bevismateriale, der allerede kræver styring af DNS-livscyklus

Mange organisationer har allerede politikker, der ville forebygge dangling DNS, hvis de blev implementeret korrekt. Hullet er, at styring af DNS-livscyklus ikke eksplicit forbindes med disse politikker.

Clarysecs Politik for styring af aktiver - SME Politik for styring af aktiver - SME, Krav til implementering af politikken, klausul 6.6.1 angiver:

Cloudbaserede aktiver (f.eks. storage-konti, SaaS-platforme, webdomæner) skal også indgå i aktivfortegnelsen.

Den samme politik tilføjer i klausul 6.6.2:

Ejerskab, formål, adgangsrettigheder og tidsplaner for fornyelse skal dokumenteres.

For styring af dangling DNS betyder det, at hvert produktionssubdomæne og hvert væsentligt ikke-produktionssubdomæne skal have en navngiven ejer, et forretningsformål, en tilknyttet tjeneste, en adgangsmodel og en dato for gennemgang.

Vigtigst er klausul 6.6.3, som angiver:

Udløbne eller ubrugte tjenester skal deaktiveres og fjernes fra aktivfortegnelsen.

For DNS skal dette fortolkes omhyggeligt. Det er ikke tilstrækkeligt at fjerne tjenesten fra aktivfortegnelsen. DNS-posten, cloud-bindingen, SaaS-kravet på custom domain, certifikatet, WAF-reglen, CDN-konfigurationen og overvågningsposten skal også gennemgås.

Enterprise-versionen forstærker dette bredere aktivbegreb. Clarysecs Politik for styring af aktiver Politik for styring af aktiver, Omfang, klausul 2.2.5 angiver:

Logiske aktiver: domænenavne, licenser, brugerkonti, konfigurationsbaselines

Domænenavne og konfigurationer er ikke administrativt bagatellearbejde. De er tillidsbærende aktiver, der kan blive angrebsveje.

Koblingen til ændringsstyring er lige så vigtig. Clarysecs Politik for ændringsstyring Politik for ændringsstyring, Formål, klausul 1.1 angiver:

Denne politik etablerer en formel ramme for at initiere, vurdere, godkende, implementere og gennemgå ændringer i organisationens informationssystemer, infrastruktur, applikationer og relaterede processer.

Fjernelse af en DNS-post, opsigelse af SaaS, sletning af en cloudapp, migrering af CDN eller afvikling af et marketingmikrosite skal derfor generere bevismateriale for ændringen. Fraværet af en ændringssag er ofte det første røde flag i en revision.

Cloudstyring skal også forbindes. Clarysecs Politik for brug af cloudtjenester Politik for brug af cloudtjenester, Styringskrav, klausul 5.5 angiver:

Informationssikkerhedsteamet skal rutinemæssigt vurdere netværkstrafik, DNS-aktivitet og logfiler for at detektere uautoriseret brug af cloudtjenester (shadow IT). Detekterede overtrædelser skal undersøges omgående.

For forebyggelse af overtagelse af subdomæner handler overvågning af DNS-aktivitet ikke kun om shadow IT. Det handler også om forældet IT, dvs. aktiver, der tidligere var godkendte, men ikke længere kontrolleres.

En praktisk Clarysec-arbejdsgang for styring af dangling DNS

Et stærkt program for dangling DNS er ikke kompliceret. Det er disciplineret, gentageligt og forbundet med ISMS, sårbarhedsstyring, ændringsstyring og leverandørens livscyklus.

For SMV’er kan dette begynde som et letvægtsregister. For enterprise-organisationer integreres det typisk med DNS-eksporter, styring af ekstern angrebsflade, cloudaktivfortegnelser, CMDB-registreringer, sårbarhedsscannere, SIEM-alarmer og helpdesk-sagsstyringssystemer.

Styringsspørgsmålet er det samme: Kan I dokumentere, at hvert eksternt tilgængeligt subdomæne er kendt, ejet, overvåget og kan fjernes gennem en kontrolleret proces?

Det forladte kampagnesubdomæne håndteret korrekt

Vend tilbage til mandagshændelsen. promo.company.com peger på et forladt SaaS-kampagnesite.

Først opretter den sikkerhedsansvarlige en sårbarhedsregistrering, fordi aktivet er eksternt eksponeret. Clarysecs Politik for sårbarheds- og patchstyring Politik for sårbarheds- og patchstyring, Krav til implementering af politikken, klausul 6.1.1 angiver:

Alle systemer skal scannes mindst månedligt; højrisikosystemer eller eksternt eksponerede aktiver skal scannes ugentligt.

For SMV’er skærper den tilsvarende politik prioriteringen. Politik for sårbarheds- og patchstyring - SME Politik for sårbarheds- og patchstyring - SME, Krav til implementering af politikken, klausul 6.5.1 angiver:

Systemer, der behandler personoplysninger, giver fjernadgang eller er eksternt eksponerede, skal prioriteres til scanning og opdateringer

Dernæst identificeres ejeren via aktivregisteret. Hvis ejeren er ukendt, bliver det et kontrolsvigt i forhold til aktivstyring. Registeret opdateres med DNS-navn, måludbyder, oprindelig virksomhedsejer, dataklassificering, leverandør og status.

For det tredje kontrollerer IT cloud- eller SaaS-platformen. Hvis cloudkontoen blev slettet, er Clarysecs Politik for brug af cloudtjenester - SME Politik for brug af cloudtjenester - SME, Krav til implementering af politikken, klausul 6.3.6 direkte relevant:

Slettede cloudkonti skal gennemgås af IT-leverandøren eller direktøren for resterende adgang, forældreløse data eller overset indhold.

For det fjerde opretter ændringsejeren en nødændring eller en fremskyndet ændringssag for at fjerne DNS-posten eller midlertidigt generhverve ressourcen før fjernelse. Sagen omfatter konsekvensvurdering, tilbagerulningsplan, godkendelser, implementeringsbevismateriale og validering efter ændringen.

For det femte vurderer den databeskyttelsesansvarlige, om subdomænet behandlede eller kunne have eksponeret personoplysninger. Clarysecs PII Security and Access Control Policy PII Security and Access Control Policy, Sikker konfiguration og sårbarhedsstyring, klausul 4.7.4 angiver:

[Both] Systemejeren / applikationsejeren MUST registrere dækning af sårbarhedsvurderinger for systemer, der behandler PII, i REG12 mindst kvartalsvist og efter væsentlig teknisk ændring.

Klausul 4.7.5 tilføjer:

[Both] Den informationssikkerhedsansvarlige MUST registrere uafklarede højrisikosårbarheder, der påvirker PII, i REG12 inden for fem arbejdsdage efter validering.

Disse klausuler gælder, uanset om organisationen fungerer som dataansvarlig eller databehandler, fordi de er markeret [Both]. Ved et dangling DNS-problem, der involverer PII, må bevismaterialet ikke kun ligge i en teknisk sag. Det skal afspejles i PII-sårbarhedsregisteret som bevismateriale.

For det sjette kontrollerer indkøb tredjepartsregistreringer, hvis et bureau eller en SaaS-udbyder hostede kampagnen. Clarysecs Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Identifikation og klassificering af relationer, klausul 4.1.2 angiver:

[All] Procesejeren / virksomhedsejeren MUST identificere hver foreslået tredjepartsrelation, der vil behandle, tilgå, modtage, opbevare, overføre, understøtte eller på anden måde påvirke PII i REG08 før indkøb, onboarding, fornyelse eller væsentlig ændring vedrørende tredjeparts databeskyttelse.

Klausul 4.5.5 kræver:

[Both] Leverandør-/indkøbsansvarlig MUST registrere behandlingslokationer, hostinglokationer og indikatorer for international overførsel i REG08 og knytte relevant overførselsdokumentation til REG09, før en databehandler, underdatabehandler, lokationsændring eller overførselsrelevant tjenesteændring godkendes.

Endelig samler den compliance-ansvarlige bevismaterialet. Clarysecs Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Mål, klausul 3.4 angiver, at ét mål er:

At generere forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder om dokumentation.

Det er det resultat, CISO’en har brug for, når en kunde, tilsynsmyndighed eller revisor spørger: “Hvordan ved I, at dette ikke sker igen?”

Hvor Zenith Blueprint passer ind

Clarysecs Zenith Blueprint: en 30-trins køreplan for revisorer Zenith Blueprint omsætter kontroller til revisionsklare driftspraksisser. Dangling DNS knytter sig stærkt til fire områder.

I fasen Kontroller i praksis dækker trin 22 organisatoriske kontroller 5.1 til 5.18, herunder ISO/IEC 27002:2022 kontrol 5.9. Zenith Blueprint angiver:

Ingen organisation kan beskytte det, den ikke ved, at den har. Kontrol 5.9 formaliserer dette grundlæggende princip og kræver etablering og vedligeholdelse af en ajourført aktivfortegnelse over alle informationsaktiver og tilknyttede aktiver, der er relevante for ISMS’et.

Den fortsætter:

I sin mest strategiske form fungerer en aktivfortegnelse som centralnervesystemet i jeres ISMS.

Jeres subdomænefortegnelse er ikke en sideliste. Den understøtter adgangsbeslutninger, sårbarhedsscanning, logning, leverandørstyring, kortlægning af databeskyttelse og hændelseshåndtering.

I trin 20 dækker Zenith Blueprint teknologiske kontroller 8.18 til 8.26. For kontrol 8.21, Security of network services, instruerer den organisationer i at validere sikkerheden i netværkstjenester:

Oplist alle interne og eksterne netværkstjenester (DNS, VPN, SMTP, DHCP, API-gateways osv.).

Derfor hører DNS-udbydere, registratorer, cloud-DNS, CDN-platforme og SaaS-funktioner til custom domains hjemme i tjenesteregisteret.

I trin 19 dækker Zenith Blueprint teknologiske kontroller 8.1 til 8.17. For kontrol 8.8 angiver den:

Styring af sårbarheder er et af de mest kritiske områder inden for moderne cyberhygiejne. Selvom firewalls og antivirusværktøjer yder beskyttelse, kan de undermineres, hvis ikke-patchede systemer eller fejlkonfigurerede tjenester efterlades eksponeret.

En dangling DNS-post er en fejlkonfigureret ekstern tjenestevej. Selv når der ikke findes en CVE, skal den håndteres gennem sårbarhedsstyring: validér, scor, tildel, afhjælp, gentest og luk.

I trin 23 behandler Zenith Blueprint organisatoriske kontroller 5.19 til 5.37. For kontrol 5.23 anbefaler den:

Oplist alle cloudtjenester, der aktuelt er i brug (5.23), herunder kendt shadow IT. Identificér, hvem der har godkendt dem, og om der er gennemført due diligence. Udarbejd en let evalueringstjekliste, der dækker datalokation, adgangsmodel, logning og kryptering.

For forebyggelse af overtagelse af subdomæner skal custom domains, DNS-afhængigheder, udfasningsansvarlig og exitdokumentation tilføjes til evalueringstjeklisten for cloudtjenester.

Kortlægning til NIS2, DORA og GDPR

NIS2 gør styring af dangling DNS til et bestyrelsesniveau-spørgsmål for mange væsentlige og vigtige enheder. Article 20 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og gennemfører cybersikkerhedstræning. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger med en tilgang, der omfatter alle farer. Minimumsområderne omfatter risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse, udvikling og vedligeholdelse, håndtering af sårbarheder, effektivitetsvurdering, cyberhygiejne, træning, adgangsstyring og styring af aktiver.

Et program for dangling DNS passer direkte til disse områder. Article 21(3) kræver også, at sikkerhed i forsyningskæden tager højde for sårbarheder, der er specifikke for hver direkte leverandør eller tjenesteudbyder. Hvis et marketingbureau, en SaaS-leverandør, en udbyder af managed hosting eller en cloudplatform administrerer custom domains, skal leverandørspecifikke kontroller dække DNS-ejerskab, afvikling af tjenester, hændelsessupport og overdragelse af bevismateriale.

Article 23 er relevant, hvis overtagelse sker eller kan forårsage alvorlig driftsforstyrrelse, økonomisk tab eller betydelig materiel eller immateriel skade. NIS2 anvender trinvis rapportering: tidlig varsling inden for 24 timer efter kendskab til en væsentlig hændelse, underretning inden for 72 timer, mellemliggende rapporter hvor de anmodes om, og en slutrapport inden for én måned efter hændelsesunderretningen.

For finansielle enheder er DORA det sektorspecifikke regelsæt for digital operationel robusthed. Articles 5 og 6 kræver en intern styrings- og kontrolramme for styring af IKT-risiko med endeligt ansvar hos ledelsesorganet, klare IKT-roller, politikker for dataenes tilgængelighed, autenticitet, integritet og fortrolighed, revisionsplaner, ressourcer, politik for tredjepartstjenester og en dokumenteret styringsramme for IKT-risiko.

Articles 8 til 14 udgør den operationelle kerne. Article 8 kræver identifikation, klassificering og dokumentation af IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver, afhængigheder, sammenkoblinger med IKT-tredjepartsudbydere, fortegnelser, risikoscenarier og legacy-systemer. En dangling CNAME-post er ofte en overset afhængighed. Article 9 kræver beskyttelse og forebyggelse. Article 10 kræver detektion af anomal aktivitet, IKT-hændelser og potentielle single points of failure. Articles 11 og 12 omhandler kontinuitet, genopretning, backup og genetablering. Article 13 kræver læring fra sårbarheder, trusler, hændelser og test.

Articles 17 til 19 formaliserer hændelsesstyring, klassificering og rapportering. Articles 28 til 30 gør tredjeparts-IKT-risiko livscyklusbaseret. Finansielle enheder forbliver fuldt ansvarlige, når de anvender IKT-tjenesteudbydere. For DORA-parathed anbefaler Clarysec at tilføje fire felter til hvert DNS- og cloudtjenesteregister: understøttelse af kritisk eller vigtig funktion, IKT-tredjepartsudbyder, kontrakt- eller registerreference og status for exit-test.

GDPR gælder, når problemet involverer personoplysninger. Overtagelse af et subdomæne er ikke automatisk et brud på persondatasikkerheden, men det kan blive det, hvis det berørte subdomæne indsamler legitimationsoplysninger, opsamler formulardata, udgiver sig for at være en tjeneste, eksponerer brugeridentifikatorer eller muliggør uautoriseret adgang til personoplysninger. GDPR Article 5 kræver integritet, fortrolighed og ansvarlighed. Article 32 kræver passende behandlingssikkerhed. Article 33 kan kræve anmeldelse til tilsynsmyndigheden, hvis et brud på persondatasikkerheden sandsynligvis indebærer en risiko for fysiske personers rettigheder og frihedsrettigheder.

Clarysecs PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Klassificering og vurdering af brud, klausul 4.2.6 understøtter denne analyse af udløsere på tværs af regelsæt:

[Conditional] Den databeskyttelsesansvarlige / PIMS-ansvarlige MUST evaluere relevante juridiske, sektorbaserede, finanssektorrelaterede, cybersikkerhedsmæssige, kontraktlige, kunde- og tjenestemodtagerrelaterede rapporteringsudløsere for hver PII-hændelse med højt konsekvensniveau og registrere resultatet af anvendelighedsvurderingen i REG01, REG08 og REG10.

Denne beslutningsregistrering er præcis det, der er nødvendigt, når overtagelse af et subdomæne kan involvere GDPR, NIS2, DORA, kontrakter og kundeunderretning.

Hvordan revisorer tester jeres bevismateriale

Et integreret ISMS bør gøre det muligt at besvare forskellige revisorer med det samme bevisgrundlag. Spørgsmålets ordlyd ændrer sig, men bevismaterialet er ofte det samme.

Et bredere assurance-perspektiv omfatter ofte NIST CSF 2.0 og COBIT 2019. NIST CSF 2.0 hjælper med at beskrive måltilstanden gennem GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- og RECOVER-resultater. En aktuel profil kan vise manuelle kvartalsvise DNS-gennemgange og uensartet SaaS-offboarding. En målprofil kan kræve automatiserede ugentlige kontroller for overtagelse, obligatorisk ejertildeling, dokumentation for leverandørafvikling og integration med ændringsstyring.

En COBIT 2019- eller ISACA-orienteret revisor vil typisk spørge, hvem der ejer processen, hvordan risiko evalueres og styres, om ændringer kontrolleres, om leverandører styres, om konfigurationer og aktiver er pålidelige, og om assurance-dokumentation understøtter ledelsesrapportering. De spørger måske ikke først efter en liste over CNAME-poster. De kan spørge, hvordan ledelsen ved, at eksterne digitale tjenester kontrolleres gennem hele deres livscyklus.

Hvordan godt revisionsbevismateriale ser ud

En revisionspakke for dangling DNS bør være lille nok til at vedligeholde, men fuldstændig nok til at kunne forsvares. Clarysec anbefaler typisk følgende bevismateriale:

• DNS-zonefortegnelse med kilde, dato, posttype, mål og ejer.
• Scanningsresultater for ekstern angrebsflade, der viser kontroller for overtagelse.
• Poster i aktivregister for domæner, subdomæner, cloudtjenester, SaaS-applikationer og CDN’er.
• Tjenesteregister, der viser internt ansvar eller leverandøransvar.
• Ændringssager for oprettelse, ændring og sletning af DNS-poster.
• Tjeklister for onboarding af cloud og SaaS, herunder gennemgang af custom domains og DNS.
• Leverandørkontrakter eller sikkerhedsklausuler, der dækker DNS, hosting, hændelsessupport og exit.
• Sårbarhedssager med alvorlighed, ejer, afhjælpningsdato og dokumentation for gentest.
• PII-vurdering, hvor subdomænet behandler eller tidligere har behandlet personoplysninger.
• Registreringer af hændelsesklassificering for mistanke om eller bekræftet overtagelse.
• Læringspunkter og opdaterede procedurer efter konstateringer.

Metrikker er også vigtige. Ledelsen bør se antallet af eksterne subdomæner, procentdel med tildelte ejere, antal dangling-konstateringer, gennemsnitlig tid til afhjælpning, overskredne højrisikokonstateringer, leverandørhostede subdomæner uden aktuel kontraktreference og procentdel af cloud-exits med dokumentation for fjernelse af DNS-poster.

Disse metrikker omsætter teknisk hygiejne til dokumentation for ledelsestilsyn.

Almindelige svigtmønstre, som Clarysec finder

På tværs af SaaS-, fintech-, sundhedsteknologi-, managed services- og e-handelskunder går de samme mønstre igen.

For det første er DNS-ejerskab delt mellem teams. Engineering ejer cloud. Marketing ejer kampagner. IT ejer adgang til DNS-udbyderen. Indkøb ejer SaaS-opsigelse. Ingen ejer hele livscyklussen.

For det andet behandles sletning af cloud som afslutningen på tjenesten. I praksis kan DNS, certifikater, WAF-regler, overvågning, hemmeligheder, dokumentation og leverandørregistreringer fortsat bestå.

For det tredje fokuserer sårbarhedsscannere på aktive værter, men overser udbyderspecifikke betingelser for overtagelse. Organisationer har brug for kontroller af ekstern angrebsflade, der forstår almindelige SaaS- og cloudfejltilstande.

For det fjerde fokuserer procedurer for leverandørafvikling på fakturaer og tilbagelevering af data, men ikke på custom domains, DNS-poster og ændringer i underdatabehandlere.

For det femte orienteres databeskyttelsesteams for sent. Hvis et subdomæne har behandlet PII, skal DPO’en eller den databeskyttelsesansvarlige indgå i klassificeringen, før der drages antagelser.

For det sjette findes bevismaterialet, men det er spredt. DNS-eksporten ligger i ét værktøj, ændringssager i et andet, leverandørkontrakter hos indkøb, sårbarhedsrapporter i scannere og databeskyttelsesanalysen i e-mail. Revisorer ser fragmentering som en svaghed.

Clarysecs værktøjssæt løser dette ved at forbinde politikker, registre, kontroller og arbejdsgange for bevismateriale.

En 30-dages handlingsplan for DNS-styring

Hvis I har fundet én dangling DNS-post, bør I antage, at der findes flere. Hvis I ikke har fundet nogen, skal I sikre, at I kan dokumentere hvorfor.

Begynd med denne 30-dages plan:

1. Eksportér alle autoritative DNS-zoner.
2. Identificér CNAME-, ALIAS-, A- og AAAA-poster, der peger på cloud-, SaaS-, CDN- og bureaustyrede tjenester.
3. Tildel ejere og forretningsformål.
4. Gennemfør kontroller for overtagelse, og validér mistænkelige poster manuelt.
5. Opret sårbarhedssager for bekræftede risici.
6. Fjern eller generhverv eksponerede poster gennem ændringsstyring.
7. Opdatér aktivregisteret, cloudregisteret og leverandørregisteret.
8. Gennemgå, om et berørt subdomæne har behandlet PII.
9. Tilføj kontroller af DNS-livscyklus til cloud-onboarding, SaaS-indkøb og leverandørafvikling.
10. Rapportér metrikker til ledelsen.

Den tekniske afhjælpning for dangling DNS er ofte enkel. Styringsrettelsen er det, der forebygger den næste overtagelse.

Clarysec kan hjælpe jer med at operationalisere dette ved hjælp af Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls og vores politikværktøjssæt til styring af aktiver, brug af cloudtjenester, sårbarhedsstyring, leverandørstyring, PII-sikkerhed, hændelseshåndtering og revisionsbevismateriale.

Hvis I ønsker en revisionsklar tilgang, kan Clarysec hjælpe jer med at opbygge bevispakken for DNS- og cloudeksponering, kortlægge den til ISO/IEC 27001:2022, NIS2, DORA og GDPR og omsætte glemte subdomæner til kontrollerede, ejede og overvågede aktiver. Download det relevante Clarysec-værktøjssæt, anmod om en demo, eller planlæg en vurdering af DNS-styring, før en penetrationstester, revisor eller angriber finder den næste glemte pointer.