Styrning av dangling DNS för NIS2, DORA och GDPR

Informationssäkerhetschefen får meddelandet kl. 07.12 en måndag.

En säkerhetsforskare har hittat promo.company.com, som pekar på en övergiven molnapplikation. DNS-posten är fortfarande aktiv. Molnresursen är borta. SaaS-tenantmiljön som tidigare drev kampanjen raderades för sex månader sedan, strax efter att marknadsavdelningen bytte till en annan plattform. Ingen tog bort CNAME-posten.

Kl. 08.30 är frågan inte längre: ”Kan någon ta över subdomänen?” Frågan är: ”Varför visste ingen att den här tillgången fanns?”

Kl. 09.15 är juristfunktionen involverad eftersom subdomänen tidigare samlade in e-postadresser till en väntelista för en produkt. Upphandling är involverad eftersom kampanjplattformen hanterades av en byrå. Compliancefunktionen är involverad eftersom företaget förbereder sig för uppföljande revision enligt ISO/IEC 27001:2022, NIS2-beredskap och säkerhetsfrågeformulär från kunder. Dataskyddsombudet frågar om exponeringen kan bli en personuppgiftsincident enligt GDPR om subdomänen utnyttjas. Ekonomichefen frågar om samma svaghet kan påverka en betalningsportal inom koncernens reglerade miljö för finansiella tjänster.

Den tekniska åtgärden kan ta några minuter. Styrningsproblemet kan ta månader att reda ut om organisationen inte kan visa att varje internetexponerad tillgång är känd, ägd, granskad, övervakad och avvecklad genom en kontrollerad process.

Därför kan dangling DNS och förebyggande av subdomänövertagande inte behandlas som en avgränsad DNS-städning. En inaktuell DNS-post är ofta ett synligt tecken på djupare kontrollbrister: ofullständig tillgångsförteckning, svagt ägarskap, saknat avvecklingsunderlag, bristande ändringshantering, otillräcklig leverantörsavveckling, otillräcklig övervakning av extern angreppsyta och oklar incidentklassificering.

För Clarysec-kunder är dangling DNS ett test av ledningssystemet. Det visar om policyer, kontroller, register, underlag och ansvar faktiskt fungerar när ett bortglömt molnberoende blir en möjlighet för en angripare.

Vad dangling DNS egentligen innebär

Subdomänövertagande blir möjligt när en DNS-post, ofta en CNAME-post, pekar på en resurs som inte längre finns eller inte längre kontrolleras av organisationen. Om en angripare kan göra anspråk på eller återskapa målresursen i moln- eller SaaS-plattformen kan angriparen eventuellt publicera innehåll under organisationens betrodda subdomän.

Vanliga exempel är:

• En CNAME-post som pekar på en molnapplikationstjänst som ingen har gjort anspråk på.
• Ett anpassat SaaS-värdnamn som finns kvar i DNS efter att abonnemanget har avslutats.
• En CDN-distribution som har tagits bort i leverantörens konsol men fortfarande refereras i publik DNS.
• En kampanjwebbplats som har avvecklats av en byrå utan att DNS-posten har tagits bort.
• En lagringsslutpunkt eller mappning till statisk webbplats som kan registreras på nytt.
• En utvecklingssubdomän som exponeras genom ett bortglömt platform-as-a-service-projekt.

Affärskonsekvensen kan vara allvarlig. Angripare kan publicera phishingsidor, fånga upp autentiseringsuppgifter, distribuera skadlig kod, missbruka domänens anseende, avlyssna sessionsdata eller skada förtroendet för varumärket. Om subdomänen tidigare behandlade personuppgifter kan även ett kortvarigt övertagande utlösa en bedömning av personuppgiftsincident enligt GDPR. Om den berörda tjänsten stödjer reglerad finansiell verksamhet kan incidenten också behöva bedömas enligt DORA eller interna ramverk för IKT-riskhantering.

Revisorer ser i allt högre grad dangling DNS som indikator på kontrollmognad. En enda inaktuell post kan indikera att organisationen inte vet vad den äger, vem som äger det, hur ändringar granskas, hur molntjänster avvecklas eller hur externt exponerade tillgångar övervakas.

Därför mappar Clarysec denna fråga mot ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och revisionsförväntningar enligt COBIT 2019.

Varför ISO 27001:2022 är den praktiska ryggraden

Det starkaste sättet att styra dangling DNS är inte att skapa separata program för NIS2, DORA och GDPR. Det är att använda ISO/IEC 27001:2022 som ryggrad för ledningssystemet och skapa underlag en gång för flera försäkransbehov.

De relevanta kraven börjar före bilaga A. Klausulerna 4.1 till 4.4 kräver att organisationen förstår sin kontext, intressenters krav, LIS-omfattning och beroenden till andra organisationer. För styrning av dangling DNS bör omfattningen inkludera extern DNS, domäner, registrarer, molntjänster, SaaS-plattformar, byråer, hanterad hosting, CDN:er och varje tredje part som kan skapa eller avveckla internetexponerade tjänster.

Klausulerna 5.1 till 5.3 gör detta till en fråga om ledarskap och ansvar. Ledningen ska anpassa LIS till verksamhetens inriktning, tillhandahålla resurser, kommunicera vikten av informationssäkerhet och tilldela ansvar. Om marknadsavdelningen kan lansera en kampanjwebbplats, utvecklingsteamet kan skapa molnslutpunkter och upphandling kan avsluta SaaS-avtal behöver organisationen en styrningsmodell som tilldelar tydligt DNS- och tjänsteägarskap över alla dessa områden.

Klausulerna 6.1.1 till 6.1.3 ger logiken för riskbedömning, riskbehandling och tillämpbarhetsförklaring. Dangling DNS bör registreras som ett realistiskt riskscenario, inte bara som utdata från en skanner. Det påverkar konfidentialitet, riktighet och tillgänglighet och kan ofta kopplas till rättsliga, regulatoriska och avtalsmässiga skyldigheter.

Klausulerna 7.5, 8.1, 8.2 och 8.3 omsätter styrning till underlag. De kräver styrd dokumenterad information, planerade och kontrollerade operativa processer, beaktande av oavsiktliga ändringar, styrning av externt tillhandahållna processer, periodiska riskbedömningar och dokumenterade behandlingsresultat.

Bilaga A innehåller därefter kontrollkatalogen. I Clarysec-projekt ser de centrala relationerna i ISO/IEC 27002:2022 vanligtvis ut så här:

Poängen är enkel. ISO/IEC 27001:2022 efterfrågar inte en heroisk engångsstädning. Standarden kräver en kontrollerad operativ modell som förhindrar återkomst.

Zenith Controls-perspektivet: en risk, tre kontrollankare

I Zenith Controls: The Cross-Compliance Guide Zenith Controls använder Clarysec relevanta ISO/IEC 27002:2022-kontroller som ankare för efterlevnad av flera regelverk. För styrning av dangling DNS och subdomänövertagande är tre kontroller centrala.

Kontroll 5.9, Förteckning över information och andra tillhörande tillgångar, klassificeras som förebyggande, stödjer konfidentialitet, riktighet och tillgänglighet, linjerar med cybersäkerhetskonceptet Identify och ligger under tillgångshantering som operativ förmåga, med styrning, ekosystem och skydd som säkerhetsdomäner.

Kontroll 5.23, Informationssäkerhet vid användning av molntjänster, klassificeras som förebyggande, stödjer konfidentialitet, riktighet och tillgänglighet, linjerar med Protect och ligger under säkerhet i leverantörsrelationer som operativ förmåga, med styrning, ekosystem och skydd som säkerhetsdomäner.

Kontroll 8.8, Hantering av tekniska sårbarheter, klassificeras som förebyggande, stödjer konfidentialitet, riktighet och tillgänglighet, linjerar med Identify och Protect och ligger under hot- och sårbarhetshantering som operativ förmåga, med styrning, ekosystem, skydd och försvar som säkerhetsdomäner.

Detta är viktigt eftersom dangling DNS inte bara är ett misslyckande i tillgångskontroller, inte bara ett misslyckande i molnkontroller och inte bara en sårbarhet. Det är alla tre. Organisationen måste visa att tillgångsförteckning, styrning av molnanvändning och sårbarhetshantering förstärker varandra.

Clarysec lägger ofta till stödjande praxis kring dessa ankare: ISO/IEC 27005 för disciplin i riskbedömning och riskbehandling, ISO/IEC 27017 för säkerhetsstyrning av molntjänster, ISO/IEC 27018 när molntjänster behandlar PII, ISO/IEC 27701 för ledningssystem för hantering av integritetsinformation och ISO 22301 när kontinuitet och krisrespons är relevanta.

Policyunderlaget som redan kräver livscykelstyrning av DNS

Många organisationer har redan policyer som, om de genomfördes korrekt, skulle förhindra dangling DNS. Bristen är att livscykelstyrning av DNS inte uttryckligen kopplas till dessa policyer.

Clarysecs Asset Management Policy-sme Asset Management Policy-sme - SME, krav för genomförande av policyn, klausul 6.6.1 anger:

Molnbaserade tillgångar, t.ex. lagringskonton, SaaS-plattformar och webbdomäner, ska också ingå i tillgångsförteckningen.

Samma policy lägger till i klausul 6.6.2:

Ägarskap, syfte, åtkomstbehörigheter och tidsfrister för förnyelse ska dokumenteras.

För styrning av dangling DNS innebär detta att varje produktionssubdomän och varje väsentlig icke-produktionssubdomän bör ha en namngiven ägare, ett verksamhetssyfte, en kopplad tjänst, en åtkomstmodell och ett granskningsdatum.

Viktigast är klausul 6.6.3, som anger:

Utgångna eller oanvända tjänster ska avaktiveras och tas bort från tillgångsförteckningen.

För DNS måste detta tolkas noggrant. Det räcker inte att ta bort tjänsten från tillgångsförteckningen. DNS-posten, molnbindningen, anspråket på anpassad SaaS-domän, certifikatet, WAF-regeln, CDN-konfigurationen och övervakningsposten måste också granskas.

Enterprise-versionen förstärker detta bredare tillgångsbegrepp. Clarysecs Asset Management Policy Asset Management Policy, omfattning, klausul 2.2.5 anger:

Logiska tillgångar: domännamn, licenser, användarkonton, konfigurationsbaslinjer

Domännamn och konfigurationer är inte administrativ kuriosa. De är tillgångar som bär förtroende och kan bli angreppsvägar.

Kopplingen till ändringshantering är lika viktig. Clarysecs Change Management Policy Change Management Policy, syfte, klausul 1.1 anger:

Denna policy fastställer ett formellt ramverk för att initiera, bedöma, godkänna, genomföra och granska ändringar i organisationens informationssystem, infrastruktur, applikationer och relaterade processer.

Borttagning av DNS, avslut av SaaS, radering av molnapplikation, CDN-migrering eller avveckling av en kampanjwebbplats bör därför skapa ändringsunderlag. Avsaknad av ett ändringsärende är ofta den första varningssignalen vid revision.

Molnstyrning måste också kopplas in. Clarysecs Cloud Usage Policy Cloud Usage Policy, styrningskrav, klausul 5.5 anger:

Informationssäkerhetsteamet ska regelbundet bedöma nätverkstrafik, DNS-aktivitet och loggar för att upptäcka otillåten användning av molntjänster (skugg-IT). Upptäckta överträdelser ska utredas skyndsamt.

För att förebygga subdomänövertagande handlar övervakning av DNS-aktivitet inte bara om skugg-IT. Det handlar också om inaktuell IT, det vill säga tillgångar som tidigare var godkända men inte längre kontrolleras.

Ett praktiskt Clarysec-arbetsflöde för styrning av dangling DNS

Ett starkt program för dangling DNS är inte komplicerat. Det är disciplinerat, repeterbart och kopplat till LIS, sårbarhetshantering, ändringshantering och leverantörernas livscykel.

För små och medelstora företag kan detta börja som ett lättviktigt register. För större organisationer integreras det vanligtvis med DNS-exporter, hantering av extern angreppsyta, molnbaserade tillgångsförteckningar, CMDB-poster, sårbarhetsskannrar, SIEM-larm och ärendehanteringssystem.

Styrningsfrågan är densamma: kan ni visa att varje externt nåbar subdomän är känd, ägd, övervakad och möjlig att ta bort genom en kontrollerad process?

Den övergivna kampanjsubdomänen, hanterad på rätt sätt

Återgå till måndagsincidenten. promo.company.com pekar på en övergiven SaaS-baserad kampanjsida.

Först skapar den säkerhetsansvarige en sårbarhetspost eftersom tillgången är externt exponerad. Clarysecs Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, krav för genomförande av policyn, klausul 6.1.1 anger:

Alla system ska skannas minst månadsvis. Högriskklassade eller externt exponerade tillgångar ska skannas veckovis.

För små och medelstora företag skärper motsvarande policy prioriteringen. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, krav för genomförande av policyn, klausul 6.5.1 anger:

System som behandlar personuppgifter, tillhandahåller fjärråtkomst eller är externt exponerade ska prioriteras för skanning och uppdateringar

Därefter identifieras ägaren via tillgångsregistret. Om ägaren är okänd blir det en kontrollbrist i tillgångsstyrningen. Registret uppdateras med DNS-namn, målleverantör, ursprunglig verksamhetsägare, dataklassificering, leverantör och status.

Därefter kontrollerar IT moln- eller SaaS-plattformen. Om molnkontot har raderats är Clarysecs Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, krav för genomförande av policyn, klausul 6.3.6 direkt relevant:

Raderade molnkonton ska granskas av IT-leverantören eller verkställande chefen avseende kvarstående åtkomst, herrelösa data eller förbisett innehåll.

Därefter skapar ändringsägaren ett akut eller skyndsamt ändringsärende för att ta bort DNS-posten eller tillfälligt återta resursen innan den tas bort. Ärendet omfattar konsekvensbedömning, rollback-plan, godkännanden, genomförandeunderlag och validering efter ändring.

Därefter bedömer dataskyddsombudet om subdomänen behandlade eller kunde ha exponerat personuppgifter. Clarysecs PII Security and Access Control Policy PII Security and Access Control Policy, säker konfiguration och hantering av sårbarheter, klausul 4.7.4 anger:

[Båda] Systemägaren / applikationsägaren SKA registrera täckningen för sårbarhetsbedömningar av system som behandlar PII i REG12 minst kvartalsvis och efter väsentlig teknisk ändring.

Klausul 4.7.5 lägger till:

[Båda] Informationssäkerhetsansvarig SKA registrera olösta högriskklassade sårbarheter som påverkar PII i REG12 inom fem arbetsdagar efter validering.

Dessa klausuler gäller oavsett om organisationen agerar som personuppgiftsansvarig eller personuppgiftsbiträde, eftersom de är märkta [Båda]. För ett dangling DNS-problem som involverar PII får underlaget inte bara finnas i ett tekniskt ärende. Det måste återspeglas i underlagsregistret för PII-sårbarheter.

Därefter, om en byrå eller SaaS-leverantör driftade kampanjen, kontrollerar upphandling tredjepartsposterna. Clarysecs Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, identifiering och klassificering av relationer, klausul 4.1.2 anger:

[Alla] Processägaren / verksamhetsägaren SKA identifiera varje föreslagen tredjepartsrelation som kommer att behandla, få åtkomst till, ta emot, lagra, överföra, stödja eller på annat sätt påverka PII i REG08 före upphandling, introduktion, förnyelse eller väsentlig integritetsrelaterad tredjepartsändring.

Klausul 4.5.5 kräver:

[Båda] Leverantörs-/upphandlingsägaren SKA registrera behandlingsplatser, driftplatser och indikatorer för internationell överföring i REG08 och koppla tillämpligt överföringsunderlag till REG09 innan ett personuppgiftsbiträde, underbiträde, byte av plats eller överföringsrelevant tjänsteändring godkänns.

Slutligen paketerar complianceansvarig underlaget. Clarysecs Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, mål, klausul 3.4 anger att ett mål är:

Att skapa försvarbart underlag och ett revisionsspår till stöd för förfrågningar från tillsynsmyndigheter, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.

Det är resultatet informationssäkerhetschefen behöver när en kund, tillsynsmyndighet eller revisor frågar: ”Hur vet ni att detta inte händer igen?”

Var Zenith Blueprint passar in

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint omsätter kontroller till operativa rutiner med revisionsberedskap. Dangling DNS mappar tydligt mot fyra områden.

I fasen Controls in Action omfattar steg 22 organisatoriska kontroller 5.1 till 5.18, inklusive ISO/IEC 27002:2022 kontroll 5.9. Zenith Blueprint anger:

Ingen organisation kan skydda det den inte vet att den har. Kontroll 5.9 formaliserar denna grundläggande princip genom att kräva att en aktuell förteckning över all information och alla tillhörande tillgångar som är relevanta för LIS etableras och underhålls.

Den fortsätter:

I sin mest strategiska form fungerar en tillgångsförteckning som det centrala nervsystemet i ert LIS.

Er subdomänförteckning är inte en sidolista. Den matar beslut om åtkomst, sårbarhetsskanning, loggning, leverantörshantering, dataskyddsmappning och incidenthantering.

I steg 20 behandlar Zenith Blueprint tekniska kontroller 8.18 till 8.26. För kontroll 8.21, Säkerhet i nätverkstjänster, instrueras organisationer att validera säkerheten i nätverkstjänster:

Lista alla interna och externa nätverkstjänster (DNS, VPN, SMTP, DHCP, API-gateways osv.).

Det är därför DNS-leverantörer, registrarer, molnbaserad DNS, CDN-plattformar och funktioner för anpassade domäner i SaaS hör hemma i tjänsteregistret.

I steg 19 behandlar Zenith Blueprint tekniska kontroller 8.1 till 8.17. För kontroll 8.8 anger den:

Sårbarhetshantering är ett av de mest kritiska områdena inom modern cyberhygien. Även om brandväggar och antivirusverktyg ger skydd kan de undergrävas om opatchade system eller felkonfigurerade tjänster lämnas exponerade.

En dangling DNS-post är en felkonfigurerad extern tjänsteväg. Även när det inte finns någon CVE bör den hanteras genom sårbarhetshantering: validera, poängsätt, tilldela, åtgärda, omtesta och stäng.

I steg 23 behandlar Zenith Blueprint organisatoriska kontroller 5.19 till 5.37. För kontroll 5.23 ger den rådet:

Lista alla molntjänster som används för närvarande (5.23), inklusive skugg-IT där den är känd. Identifiera vem som godkände dem och om leverantörsgranskning genomfördes. Ta fram en lättviktig utvärderingschecklista som omfattar datalagringsplats, åtkomstmodell, loggning och kryptering.

För att förebygga subdomänövertagande bör anpassade domäner, DNS-beroenden, avvecklingsägare och avslutsunderlag läggas till i denna checklista för utvärdering av molntjänster.

Mappning mot NIS2, DORA och GDPR

NIS2 gör styrning av dangling DNS till en fråga på styrelsenivå för många väsentliga och viktiga entiteter. Article 20 kräver att ledningsorgan godkänner åtgärder för cybersäkerhetsriskhantering, övervakar genomförandet och genomgår cybersäkerhetsutbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder med ett allriskperspektiv. Minimiområdena omfattar riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, utveckling och underhåll, sårbarhetshantering, effektivitetsbedömning, cyberhygien, utbildning, åtkomstkontroll och tillgångshantering.

Ett program för dangling DNS mappar tydligt mot dessa områden. Article 21(3) kräver också att säkerhet i leveranskedjan beaktar sårbarheter som är specifika för varje direkt leverantör eller tjänsteleverantör. Om en marknadsföringsbyrå, SaaS-leverantör, leverantör av hanterad drift eller molnplattform hanterar anpassade domäner bör leverantörsspecifika kontroller omfatta DNS-ägarskap, tjänsteavveckling, incidentstöd och överlämning av underlag.

Article 23 är relevant om ett övertagande inträffar eller kan orsaka allvarlig driftstörning, ekonomisk förlust eller betydande materiell eller immateriell skada. NIS2 använder stegvis rapportering: tidig varning inom 24 timmar från det att organisationen fått kännedom om en betydande incident, anmälan inom 72 timmar, delrapporter när sådana begärs och en slutrapport inom en månad från incidentanmälan.

För finansiella entiteter är DORA den sektorsspecifika regleringen för digital operativ resiliens. Articles 5 och 6 kräver ett internt styrnings- och kontrollramverk för IKT-riskhantering, med yttersta ansvar hos ledningsorganet, tydliga IKT-roller, policyer för datans tillgänglighet, autenticitet, riktighet och konfidentialitet, revisionsplaner, resurser, policy för tredjepartstjänster och ett dokumenterat ramverk för IKT-riskhantering.

Articles 8 till 14 utgör den operativa kärnan. Article 8 kräver identifiering, klassificering och dokumentation av IKT-stödda verksamhetsfunktioner, informationstillgångar, IKT-tillgångar, beroenden, sammankopplingar med IKT-tredjepartsleverantörer, förteckningar, riskscenarier och äldre system. En dangling CNAME-post är ofta ett missat beroende. Article 9 kräver skydd och förebyggande åtgärder. Article 10 kräver detektering av avvikande aktivitet, IKT-incidenter och potentiella enskilda felpunkter. Articles 11 och 12 behandlar kontinuitet, återhämtning, säkerhetskopiering och återställning. Article 13 kräver lärande från sårbarheter, hot, incidenter och tester.

Articles 17 till 19 formaliserar incidenthantering, klassificering och rapportering. Articles 28 till 30 gör IKT-tredjepartsrisker livscykelbaserade. Finansiella entiteter är fortsatt fullt ansvariga när de använder IKT-tjänsteleverantörer. För DORA-beredskap rekommenderar Clarysec att fyra fält läggs till i varje DNS- och molntjänstregister: stöd för kritisk eller viktig funktion, IKT-tredjepartsleverantör, avtals- eller registerreferens samt status för exit-test.

GDPR gäller när frågan involverar personuppgifter. Ett subdomänövertagande är inte automatiskt en personuppgiftsincident, men det kan bli det om den berörda subdomänen samlar in autentiseringsuppgifter, fångar upp formulärdata, imiterar en tjänst, exponerar användaridentifierare eller möjliggör obehörig åtkomst till personuppgifter. GDPR Article 5 kräver riktighet, konfidentialitet och ansvarsskyldighet. Article 32 kräver lämplig säkerhet i behandlingen. Article 33 kan kräva anmälan till tillsynsmyndighet om en personuppgiftsincident sannolikt leder till en risk för fysiska personers rättigheter och friheter.

Clarysecs PII Incident and Breach Management Policy PII Incident and Breach Management Policy, klassificering och bedömning av personuppgiftsincident, klausul 4.2.6 stödjer denna triggeranalys över flera regelverk:

[Villkorad] Dataskyddsansvarig / PIMS-ansvarig SKA utvärdera tillämpliga rättsliga, sektoriella, finanssektorsrelaterade, cybersäkerhetsrelaterade, avtalsmässiga, kundrelaterade och tjänstemottagarrelaterade rapporteringsutlösare för varje personuppgiftsincident med hög påverkan och registrera utfallet av tillämpligheten i REG01, REG08 och REG10.

Det beslutsunderlaget är exakt vad som behövs när ett subdomänövertagande kan involvera GDPR, NIS2, DORA, avtal och kundavisering.

Hur revisorer kommer att testa ert underlag

Ett integrerat LIS bör låta er besvara olika revisorers frågor med samma underlagsbas. Frågans formulering ändras, men underlaget är ofta detsamma.

Ett bredare försäkransperspektiv inkluderar ofta NIST CSF 2.0 och COBIT 2019. NIST CSF 2.0 hjälper till att uttrycka målbilden genom utfall inom GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER. En Current Profile kan visa manuella kvartalsvisa DNS-granskningar och inkonsekvent SaaS-avveckling. En Target Profile kan kräva automatiserade veckovisa kontroller av övertaganderisk, obligatorisk ägartilldelning, leverantörsavslutsunderlag och integration med ändringshantering.

En COBIT 2019- eller ISACA-orienterad revisor frågar vanligtvis vem som äger processen, hur risk utvärderas och styrs, om ändringar kontrolleras, om leverantörer hanteras, om konfiguration och tillgångar är tillförlitliga samt om försäkransunderlag stödjer ledningsrapportering. Revisorn kanske inte först ber om en lista över CNAME-poster. Revisorn kan fråga hur ledningen vet att externa digitala tjänster är kontrollerade genom hela livscykeln.

Hur bra revisionsunderlag ser ut

Ett revisionspaket för dangling DNS bör vara tillräckligt litet för att kunna underhållas men tillräckligt komplett för att kunna försvaras. Clarysec rekommenderar vanligtvis följande underlag:

• DNS-zonförteckning med källa, datum, posttyp, mål och ägare.
• Skanningsresultat för extern angreppsyta som visar kontroller av övertaganderisk.
• Poster i tillgångsregistret för domäner, subdomäner, molntjänster, SaaS-applikationer och CDN:er.
• Tjänsteregister som visar internt ansvar eller leverantörsansvar.
• Ändringsärenden för skapande, ändring och radering av DNS-poster.
• Checklistor för introduktion av moln- och SaaS-tjänster, inklusive granskning av anpassad domän och DNS.
• Leverantörsavtal eller säkerhetsklausuler som omfattar DNS, hosting, incidentstöd och avslut.
• Sårbarhetsärenden med allvarlighetsgrad, ägare, åtgärdsdatum och omtestningsunderlag.
• PII-bedömning när subdomänen behandlar eller tidigare behandlade personuppgifter.
• Incidentklassificeringsposter för misstänkt eller bekräftat övertagande.
• Erfarenhetsåterföring och uppdaterade rutiner efter iakttagelser.

Mätetal är också viktiga. Ledningen bör se antalet externa subdomäner, andel med tilldelade ägare, antal dangling DNS-iakttagelser, genomsnittlig tid till åtgärd, försenade högriskklassade iakttagelser, leverantörsdriftade subdomäner utan aktuell avtalsreferens och andel molnavvecklingar med underlag för borttagning av DNS.

Dessa mätetal omvandlar teknisk hygien till underlag för ledningens tillsyn.

Vanliga bristmönster som Clarysec identifierar

Hos kunder inom SaaS, fintech, hälso- och sjukvårdsteknik, hanterade tjänster och e-handel återkommer samma mönster.

För det första är DNS-ägarskapet uppdelat mellan team. Utveckling äger molnet. Marknad äger kampanjer. IT äger åtkomsten till DNS-leverantören. Upphandling äger avslut av SaaS. Ingen äger hela livscykeln.

För det andra behandlas radering i molnet som slutet på tjänsten. I praktiken kan DNS, certifikat, WAF-regler, övervakning, hemligheter, dokumentation och leverantörsposter finnas kvar.

För det tredje fokuserar sårbarhetsskannrar på aktiva värdar men missar leverantörsspecifika förhållanden för övertagande. Organisationer behöver kontroller av extern angreppsyta som förstår vanliga felstatusar i SaaS- och molntjänster.

För det fjärde fokuserar rutiner för leverantörsavslut på fakturor och återlämning av data, men inte på anpassade domäner, DNS-poster och ändringar rörande underbiträden.

För det femte underrättas dataskyddsteam för sent. Om en subdomän behandlade PII bör dataskyddsombudet eller dataskyddsansvarig delta i klassificeringen innan antaganden görs.

För det sjätte finns underlag men är utspritt. DNS-exporten finns i ett verktyg, ändringsärenden i ett annat, leverantörsavtal hos upphandling, sårbarhetsrapporter i skannrar och dataskyddsanalys i e-post. Revisorer ser fragmentering som en svaghet.

Clarysecs verktygslåda löser detta genom att koppla samman policyer, register, kontroller och arbetsflöden för underlag.

En 30-dagars handlingsplan för DNS-styrning

Om ni hittade en dangling DNS-post, utgå från att det finns fler. Om ni inte hittade någon, säkerställ att ni kan visa varför.

Börja med denna 30-dagarsplan:

1. Exportera alla auktoritativa DNS-zoner.
2. Identifiera CNAME-, ALIAS-, A- och AAAA-poster som pekar på moln-, SaaS-, CDN- och byråhanterade tjänster.
3. Tilldela ägare och verksamhetssyften.
4. Kör kontroller av övertaganderisk och validera misstänkta poster manuellt.
5. Skapa sårbarhetsärenden för bekräftade risker.
6. Ta bort eller återta exponerade poster genom ändringshantering.
7. Uppdatera tillgångsregistret, molnregistret och leverantörsregistret.
8. Granska om någon berörd subdomän behandlade PII.
9. Lägg till kontroller av DNS-livscykeln i molnintroduktion, SaaS-upphandling och leverantörsavslut.
10. Rapportera mätetal till ledningen.

Den tekniska åtgärden för dangling DNS är ofta enkel. Styrningsåtgärden är det som förhindrar nästa övertagande.

Clarysec kan hjälpa er att operationalisera detta med Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls och vår policyverktygslåda för tillgångshantering, användning av molntjänster, sårbarhetshantering, leverantörsstyrning, PII-säkerhet, incidenthantering och revisionsunderlag.

Om ni vill ha ett arbetssätt med revisionsberedskap kan Clarysec hjälpa er att bygga underlagspaketet för DNS- och molnexponering, mappa det mot ISO/IEC 27001:2022, NIS2, DORA och GDPR och omvandla bortglömda subdomäner till kontrollerade, ägda och övervakade tillgångar. Ladda ned relevant Clarysec-verktygslåda, begär en demo eller boka en DNS-styrningsbedömning innan en penetrationstestare, revisor eller angripare hittar nästa bortglömda pekare.