Řízení dangling DNS pro NIS2, DORA a GDPR

CISO obdrží zprávu v pondělí v 07:12.

Bezpečnostní výzkumník zjistil, že promo.company.com odkazuje na opuštěnou cloudovou aplikaci. Záznam DNS je stále aktivní. Cloudový zdroj již neexistuje. Tenant SaaS, který dříve obsluhoval kampaň, byl smazán před šesti měsíci, krátce poté, co marketing přešel na jinou platformu. CNAME nikdo neodstranil.

V 08:30 už otázka nezní: „Může někdo převzít subdoménu?“ Zní: „Proč nikdo nevěděl, že toto aktivum existuje?“

V 09:15 je zapojeno právní oddělení, protože subdoména dříve shromažďovala e-mailové adresy pro pořadník k produktu. Zapojen je nákupní tým, protože platformu pro kampaň spravovala agentura. Zapojen je útvar pro soulad s předpisy, protože společnost se připravuje na dozorový audit ISO/IEC 27001:2022, připravenost na NIS2 a zákaznické bezpečnostní dotazníky. Pověřenec pro ochranu osobních údajů se ptá, zda by se expozice mohla stát porušením zabezpečení osobních údajů podle GDPR, pokud by byla subdoména zneužita. Finanční ředitel se ptá, zda by stejná slabina mohla zasáhnout platební portál v regulovaném prostředí finančních služeb skupiny.

Technická oprava může trvat minuty. Problém řízení se však může řešit měsíce, pokud organizace nedokáže prokázat, že každé internetově dostupné aktivum je známé, má vlastníka, je přezkoumáváno, monitorováno a vyřazováno řízeným procesem.

Proto nelze dangling DNS a prevenci převzetí subdomény chápat jako úzce vymezený úklid DNS. Zastaralý záznam DNS je často viditelným příznakem hlubších selhání kontrol: neúplné evidence aktiv, nejasného vlastnictví, chybějících důkazů o vyřazení z provozu, slabého řízení změn, nedostatečného řízení ukončení spolupráce s dodavateli, nedostatečného monitorování externí útočné plochy a nejasné klasifikace incidentů.

Pro klienty Clarysec je dangling DNS testem systému řízení. Ukazuje, zda politiky, opatření, registry, důkazy a odpovědnost skutečně fungují ve chvíli, kdy se zapomenutá cloudová závislost stane příležitostí pro útočníka.

Co dangling DNS skutečně znamená

Převzetí subdomény je možné tehdy, když záznam DNS, často CNAME, odkazuje na zdroj, který již neexistuje nebo již není pod kontrolou organizace. Pokud si útočník může cílový zdroj v cloudové nebo SaaS platformě nárokovat nebo jej znovu vytvořit, může být schopen poskytovat obsah pod důvěryhodnou subdoménou organizace.

Typické příklady zahrnují:

• CNAME odkazující na nenárokovanou službu cloudové aplikace.
• Vlastní hostname v SaaS ponechaný v DNS po zrušení předplatného.
• Distribuci CDN odstraněnou z konzole poskytovatele, ale stále odkazovanou ve veřejném DNS.
• Marketingový microsite vyřazený agenturou bez odstranění DNS.
• Úložný endpoint nebo mapování statického webu, které lze znovu zaregistrovat.
• Vývojovou subdoménu vystavenou přes zapomenutý projekt platformy jako služby.

Dopad na podnikání může být závažný. Útočníci mohou hostovat phishingové stránky, zachytávat přihlašovací údaje, distribuovat malware, zneužívat reputaci domény, zachytávat data relací nebo poškodit důvěru ve značku. Pokud subdoména dříve zpracovávala osobní údaje, i krátkodobé převzetí může vyvolat analýzu porušení zabezpečení osobních údajů podle GDPR. Pokud dotčená služba podporuje regulované finanční operace, incident může vyžadovat také posouzení podle DORA nebo interních rámců řízení rizik v oblasti ICT.

Auditoři stále častěji vnímají dangling DNS jako důkaz vyspělosti opatření. Jediný zastaralý záznam může naznačovat, že organizace neví, co vlastní, kdo je vlastníkem, jak se přezkoumávají změny, jak se ukončuje používání cloudových služeb nebo jak jsou monitorována externě dostupná aktiva.

Proto Clarysec mapuje tuto oblast na očekávání auditů podle ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Proč je ISO 27001:2022 praktickou páteří

Nejsilnějším způsobem, jak řídit dangling DNS, není vytvářet samostatné programy pro NIS2, DORA a GDPR. Je jím použití ISO/IEC 27001:2022 jako páteře systému řízení a jednorázové vytvoření důkazů pro více potřeb ujištění.

Relevantní požadavky začínají ještě před Přílohou A. Kapitoly 4.1 až 4.4 vyžadují, aby organizace rozuměla svému kontextu, požadavkům zainteresovaných stran, rozsahu ISMS a závislostem na jiných organizacích. Pro řízení dangling DNS by rozsah měl zahrnovat externí DNS, domény, registrátory, cloudové služby, SaaS platformy, agentury, řízený hosting, CDN a jakoukoli třetí stranu, která může vytvářet nebo vyřazovat internetově dostupné služby.

Kapitoly 5.1 až 5.3 z toho činí otázku vedení a odpovědnosti. Vedení musí sladit ISMS se směrem podnikání, zajistit zdroje, komunikovat význam bezpečnosti informací a přiřadit odpovědnosti. Pokud marketing může spustit microsite, vývoj může vytvořit cloudové endpointy a nákup může ukončit SaaS smlouvy, organizace potřebuje model řízení, který napříč všemi těmito oblastmi jasně přiřazuje vlastnictví DNS a služeb.

Kapitoly 6.1.1 až 6.1.3 poskytují logiku posouzení rizik, ošetření rizik a Prohlášení o použitelnosti. Dangling DNS by měl být zaznamenán jako realistický rizikový scénář, nikoli jen jako výstup skeneru. Ovlivňuje důvěrnost, integritu a dostupnost a často se mapuje na právní, regulační a smluvní povinnosti.

Kapitoly 7.5, 8.1, 8.2 a 8.3 převádějí řízení do důkazů. Vyžadují řízené dokumentované informace, plánované a řízené provozní procesy, zohlednění nezamýšlených změn, řízení externě poskytovaných procesů, pravidelné posouzení rizik a dokumentované výsledky ošetření rizik.

Příloha A poté poskytuje katalog opatření. V projektech Clarysec obvykle vypadají klíčové vazby ISO/IEC 27002:2022 takto:

Pointa je jednoduchá. ISO/IEC 27001:2022 nepožaduje heroický jednorázový úklid. Požaduje řízený provozní model, který brání opakování.

Pohled Zenith Controls: jedno riziko, tři kontrolní kotvy

V Zenith Controls: The Cross-Compliance Guide Zenith Controls používá Clarysec relevantní opatření ISO/IEC 27002:2022 jako kotvy pro mapování souladu napříč rámci. Pro řízení dangling DNS a převzetí subdomény jsou klíčová tři opatření.

Opatření 5.9, Evidence informací a dalších souvisejících aktiv, je klasifikováno jako preventivní, podporuje důvěrnost, integritu a dostupnost, odpovídá konceptu kybernetické bezpečnosti Identify a spadá pod správu aktiv jako provozní schopnost s bezpečnostními doménami správa a řízení, ekosystém a ochrana.

Opatření 5.23, Bezpečnost informací při využívání cloudových služeb, je klasifikováno jako preventivní, podporuje důvěrnost, integritu a dostupnost, odpovídá Protect a spadá pod bezpečnost vztahů s dodavateli jako provozní schopnost s bezpečnostními doménami správa a řízení, ekosystém a ochrana.

Opatření 8.8, Řízení technických zranitelností, je klasifikováno jako preventivní, podporuje důvěrnost, integritu a dostupnost, odpovídá Identify a Protect a spadá pod řízení hrozeb a zranitelností jako provozní schopnost s bezpečnostními doménami správa a řízení, ekosystém, ochrana a obrana.

Je to důležité, protože dangling DNS není jen selháním opatření pro aktiva, jen selháním cloudových opatření ani jen zranitelností. Je vším uvedeným současně. Organizace musí prokázat, že evidence aktiv, řízení používání cloudových služeb a řízení zranitelností se vzájemně posilují.

Clarysec k těmto kotvám často doplňuje podpůrné postupy: ISO/IEC 27005 pro disciplínu posouzení a ošetření rizik, ISO/IEC 27017 pro řízení bezpečnosti cloudových služeb, ISO/IEC 27018 tam, kde cloudové služby zpracovávají PII, ISO/IEC 27701 pro systém řízení informací o soukromí a ISO 22301 tam, kde je relevantní kontinuita činností a krizová reakce.

Důkazy z politik, které již vyžadují řízení životního cyklu DNS

Mnoho organizací již má politiky, které by při správné implementaci dangling DNS zabránily. Mezera spočívá v tom, že řízení životního cyklu DNS není s těmito politikami výslovně propojeno.

Clarysec Asset Management Policy-sme Asset Management Policy-sme - SME, Požadavky na implementaci politiky, článek 6.6.1 stanoví:

Aktiva v cloudu, například účty úložiště, SaaS platformy a webové domény, musí být rovněž zahrnuta do evidence.

Stejná politika v článku 6.6.2 doplňuje:

Vlastnictví, účel, přístupová oprávnění a lhůty pro obnovení musí být dokumentovány.

Pro řízení dangling DNS to znamená, že každá produkční subdoména a významná neprodukční subdoména musí mít určeného vlastníka, obchodní účel, navázanou službu, model přístupu a datum přezkumu.

Nejdůležitější je článek 6.6.3, který stanoví:

Expirované nebo nepoužívané služby musí být deaktivovány a odstraněny z evidence.

U DNS je nutné toto ustanovení vykládat pečlivě. Odstranění služby z evidence nestačí. Přezkoumán musí být také záznam DNS, cloudová vazba, nárok na vlastní doménu v SaaS, certifikát, pravidlo WAF, konfigurace CDN a položka monitorování.

Podniková verze posiluje tento širší koncept aktiv. Clarysec Asset Management Policy Asset Management Policy, Rozsah, článek 2.2.5 stanoví:

Logická aktiva: doménová jména, licence, uživatelské účty, výchozí konfigurace

Doménová jména a konfigurace nejsou administrativní drobnosti. Jsou to aktiva nesoucí důvěru, která se mohou stát útočnými cestami.

Stejně důležitá je vazba na řízení změn. Clarysec Change Management Policy Change Management Policy, Účel, článek 1.1 stanoví:

Tato politika stanoví formální rámec pro zahajování, posuzování, schvalování, implementaci a přezkoumávání změn informačních systémů, infrastruktury, aplikací a souvisejících procesů organizace.

Odstranění DNS, ukončení SaaS, smazání cloudové aplikace, migrace CDN nebo vyřazení marketingového microsite proto musí vytvářet důkazy o změně. Absence požadavku na změnu je často prvním auditním varovným signálem.

Propojena musí být také správa cloudových služeb. Clarysec Cloud Usage Policy Cloud Usage Policy, Požadavky na správu a řízení, článek 5.5 stanoví:

Tým informační bezpečnosti musí pravidelně vyhodnocovat síťový provoz, aktivitu DNS a logy za účelem detekce neoprávněného používání cloudových služeb (shadow IT). Zjištěná porušení musí být neprodleně vyšetřena.

Pro prevenci převzetí subdomény není monitorování aktivity DNS pouze o neautorizovaném IT (shadow IT). Jde také o zastaralé IT, tedy aktiva, která byla dříve autorizována, ale již nejsou pod kontrolou.

Praktický pracovní postup Clarysec pro řízení dangling DNS

Silný program pro dangling DNS není složitý. Je disciplinovaný, opakovatelný a propojený s ISMS, řízením zranitelností, řízením změn a životním cyklem dodavatelů.

U malých a středních podniků může jít zpočátku o jednoduchý registr. U podnikových prostředí se obvykle integrují exporty DNS, správa externí útočné plochy, evidence cloudových aktiv, záznamy CMDB, skenery zranitelností, upozornění SIEM a systémy pro správu tiketů.

Otázka řízení zůstává stejná: dokážete prokázat, že každá externě dosažitelná subdoména je známá, má vlastníka, je monitorována a lze ji odstranit řízeným procesem?

Opuštěná kampaňová subdoména řešená správným způsobem

Vraťme se k pondělnímu incidentu. promo.company.com odkazuje na opuštěný SaaS web pro kampaň.

Nejprve vedoucí bezpečnosti vytvoří záznam zranitelnosti, protože aktivum je externě dostupné. Clarysec Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, Požadavky na implementaci politiky, článek 6.1.1 stanoví:

Všechny systémy musí být skenovány alespoň měsíčně; vysoce riziková nebo externě vystavená aktiva musí být skenována týdně.

Ekvivalentní politika pro malé a střední podniky zpřesňuje prioritizaci. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Požadavky na implementaci politiky, článek 6.5.1 stanoví:

Systémy, které zpracovávají osobní údaje, poskytují vzdálený přístup nebo jsou externě dostupné, musí mít prioritu při skenování a aktualizacích.

Za druhé je vlastník identifikován prostřednictvím registru aktiv. Pokud je vlastník neznámý, jde o selhání opatření v oblasti správy aktiv. Registr se aktualizuje o název DNS, cílového poskytovatele, původního vlastníka z obchodní části, klasifikaci dat, dodavatele a stav.

Za třetí IT zkontroluje cloudovou nebo SaaS platformu. Pokud byl cloudový účet smazán, je přímo relevantní Clarysec Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, Požadavky na implementaci politiky, článek 6.3.6:

Smazané cloudové účty musí být přezkoumány poskytovatelem IT služeb nebo generálním ředitelem z hlediska zbytkového přístupu, osiřelých dat nebo přehlédnutého obsahu.

Za čtvrté vlastník změny založí nouzový nebo zrychlený požadavek na změnu za účelem odstranění záznamu DNS nebo dočasného znovunárokování zdroje před jeho odstraněním. Tiket obsahuje posouzení dopadů, plán návratu, schválení, důkazy o implementaci a validaci po změně.

Za páté vedoucí ochrany soukromí posoudí, zda subdoména zpracovávala nebo mohla vystavit osobní údaje. Clarysec PII Security and Access Control Policy PII Security and Access Control Policy, Bezpečná konfigurace a řízení zranitelností, článek 4.7.4 stanoví:

[Obojí] Vlastník systému / vlastník aplikace MUSÍ zaznamenat pokrytí hodnocení zranitelností pro systémy zpracovávající PII v REG12 alespoň čtvrtletně a po významné technické změně.

Článek 4.7.5 doplňuje:

[Obojí] Vedoucí informační bezpečnosti MUSÍ zaznamenat nevyřešené vysoce rizikové zranitelnosti ovlivňující PII v REG12 do pěti pracovních dnů od validace.

Tyto články platí bez ohledu na to, zda organizace jedná jako správce nebo zpracovatel, protože jsou označeny [Obojí]. U problému dangling DNS zahrnujícího PII nesmí důkazy zůstat pouze v technickém tiketu. Musí se promítnout do registru důkazů zranitelností PII.

Za šesté, pokud kampaň hostovala agentura nebo poskytovatel SaaS, nákupní tým zkontroluje záznamy o třetích stranách. Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Identifikace a klasifikace vztahu, článek 4.1.2 stanoví:

[Vše] Vlastník procesu / vlastník společnosti MUSÍ identifikovat každý navrhovaný vztah se třetí stranou, která bude zpracovávat PII, přistupovat k PII, přijímat, ukládat, přenášet, podporovat nebo jinak ovlivňovat PII v REG08 před pořízením, onboardingem, obnovením nebo významnou změnou vztahu se třetí stranou z hlediska ochrany soukromí.

Článek 4.5.5 vyžaduje:

[Obojí] Vlastník dodavatele / nákup MUSÍ zaznamenat lokality zpracování, lokality hostingu a indikátory mezinárodního předávání v REG08 a propojit příslušné důkazy o předávání s REG09 před schválením zpracovatele, dílčího zpracovatele, změny lokality nebo změny služby relevantní pro předávání.

Nakonec vedoucí pro soulad připraví balíček důkazů. Clarysec Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Cíle, článek 3.4 uvádí, že jedním z cílů je:

Vytvářet obhajitelné důkazy a auditní stopu na podporu regulačních šetření, právních řízení nebo požadavků zákazníků na doložení zajištění.

To je výsledek, který CISO potřebuje, když se zákazník, regulační orgán nebo auditor zeptá: „Jak víte, že se to nebude opakovat?“

Kam zapadá Zenith Blueprint

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint převádí opatření do auditně připravených provozních postupů. Dangling DNS se silně mapuje na čtyři oblasti.

Ve fázi Controls in Action pokrývá krok 22 organizační opatření 5.1 až 5.18, včetně opatření 5.9 podle ISO/IEC 27002:2022. Zenith Blueprint uvádí:

Žádná organizace nemůže chránit to, o čem neví, že má. Opatření 5.9 formalizuje tento základní princip a vyžaduje zavedení a udržování aktuální evidence všech informací a souvisejících aktiv relevantních pro ISMS.

Dále uvádí:

Ve své nejstrategičtější podobě funguje evidence aktiv jako centrální nervový systém vašeho ISMS.

Evidence subdomén není vedlejší seznam. Ovlivňuje rozhodování o přístupu, skenování zranitelností, protokolování, řízení dodavatelů, mapování ochrany soukromí a reakci na incidenty.

V kroku 20 pokrývá Zenith Blueprint technická opatření 8.18 až 8.26. U opatření 8.21, Bezpečnost síťových služeb, instruuje organizace, aby validovaly bezpečnost síťových služeb:

Sepište všechny interní a externí síťové služby (DNS, VPN, SMTP, DHCP, brány API atd.).

Proto poskytovatelé DNS, registrátoři, cloudové DNS, CDN platformy a funkce vlastních domén v SaaS patří do registru služeb.

V kroku 19 pokrývá Zenith Blueprint technická opatření 8.1 až 8.17. U opatření 8.8 uvádí:

Řízení zranitelností je jednou z nejkritičtějších oblastí moderní kybernetické hygieny. Ačkoli firewally a antivirové nástroje poskytují ochranu, mohou být oslabeny, pokud zůstanou vystaveny nezáplatované systémy nebo nesprávně nakonfigurované služby.

Záznam dangling DNS je nesprávně nakonfigurovaná cesta k externí službě. I když neexistuje žádné CVE, musí být řešen prostřednictvím řízení zranitelností: validovat, ohodnotit, přiřadit, napravit, retestovat a uzavřít.

V kroku 23 se Zenith Blueprint věnuje organizačním opatřením 5.19 až 5.37. U opatření 5.23 doporučuje:

Uveďte všechny aktuálně používané cloudové služby (5.23), včetně známého shadow IT. Identifikujte, kdo je schválil a zda byla provedena náležitá péče. Vytvořte jednoduchý hodnoticí kontrolní seznam, který pokrývá umístění dat, model přístupu, protokolování a šifrování.

Pro prevenci převzetí subdomény doplňte do tohoto hodnoticího kontrolního seznamu cloudových služeb vlastní domény, závislosti DNS, vlastníka vyřazení z provozu a důkazy o ukončení.

Mapování na NIS2, DORA a GDPR

NIS2 činí z řízení dangling DNS otázku na úrovni vedoucího orgánu pro mnoho základních a důležitých subjektů. Article 20 vyžaduje, aby vedoucí orgány schvalovaly opatření k řízení kybernetických rizik, dohlížely na jejich implementaci a absolvovaly školení kybernetické bezpečnosti. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření s využitím přístupu zohledňujícího všechna rizika. Minimální oblasti zahrnují analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování, vývoj a údržbu, řešení zranitelností, posouzení účinnosti, kybernetickou hygienu, školení, řízení přístupu a správu aktiv.

Program pro dangling DNS se na tyto oblasti mapuje přímo. Article 21(3) také vyžaduje, aby zabezpečení dodavatelského řetězce zohledňovalo zranitelnosti specifické pro každého přímého dodavatele nebo poskytovatele služeb. Pokud vlastní domény spravuje marketingová agentura, dodavatel SaaS, poskytovatel řízeného hostingu nebo cloudová platforma, dodavatelsky specifická opatření musí pokrývat vlastnictví DNS, ukončení služby, podporu při incidentech a předání důkazů.

Article 23 je relevantní, pokud k převzetí dojde nebo pokud je způsobilé způsobit závažné provozní narušení, finanční ztrátu nebo značnou materiální či nemateriální újmu. NIS2 používá fázované hlášení: včasné varování do 24 hodin od zjištění významného incidentu, oznámení do 72 hodin, průběžné zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce od oznámení incidentu.

Pro finanční subjekty je DORA odvětvovým režimem digitální provozní odolnosti. Articles 5 a 6 vyžadují interní rámec správy a řízení a kontrol pro řízení rizik v oblasti ICT, s konečnou odpovědností vedoucího orgánu, jasnými rolemi v oblasti ICT, politikami dostupnosti, autenticity, integrity a důvěrnosti dat, plány auditů, zdroji, politikou služeb třetích stran a dokumentovaným rámcem řízení rizik v oblasti ICT.

Articles 8 až 14 tvoří provozní jádro. Article 8 vyžaduje identifikaci, klasifikaci a dokumentaci podnikových funkcí podporovaných ICT, informačních aktiv, aktiv ICT, závislostí, propojení s ICT třetími stranami, evidencí, rizikových scénářů a starších systémů. Dangling CNAME je často přehlédnutá závislost. Article 9 vyžaduje ochranu a prevenci. Article 10 vyžaduje detekci anomální aktivity, incidentů ICT a potenciálních jednotlivých bodů selhání. Articles 11 a 12 řeší kontinuitu, obnovu, zálohování a obnovení. Article 13 vyžaduje učení ze zranitelností, hrozeb, incidentů a testů.

Articles 17 až 19 formalizují řízení incidentů, klasifikaci a hlášení. Articles 28 až 30 zavádějí životní cyklus řízení rizik ICT třetích stran. Finanční subjekty zůstávají při využívání poskytovatelů služeb ICT plně odpovědné. Pro připravenost na DORA doporučuje Clarysec přidat do každého registru DNS a cloudových služeb čtyři pole: podpora kritické nebo důležité funkce, poskytovatel služeb ICT z řad třetích stran, odkaz na smlouvu nebo registr a stav testu ukončení.

GDPR se použije, pokud problém zahrnuje osobní údaje. Převzetí subdomény není automaticky porušením zabezpečení osobních údajů, ale může se jím stát, pokud dotčená subdoména shromažďuje přihlašovací údaje, zachytává data z formulářů, vydává se za službu, vystavuje uživatelské identifikátory nebo umožňuje neoprávněný přístup k osobním údajům. GDPR Article 5 vyžaduje integritu, důvěrnost a odpovědnost. Article 32 vyžaduje odpovídající zabezpečení zpracování. Article 33 může vyžadovat oznámení dozorovému úřadu, pokud je pravděpodobné, že porušení zabezpečení osobních údajů povede k riziku pro práva a svobody fyzických osob.

Clarysec PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Klasifikace a posouzení porušení zabezpečení, článek 4.2.6 podporuje tuto vícerežimovou analýzu spouštěcích podmínek:

[Podmíněně] Vedoucí ochrany soukromí / manažer PIMS MUSÍ vyhodnotit použitelné právní, odvětvové, finančně-sektorové, kybernetickobezpečnostní, smluvní, zákaznické a služebně-příjemcovské spouštěcí podmínky hlášení pro každý incident s významným dopadem týkající se PII a zaznamenat výsledek použitelnosti v REG01, REG08 a REG10.

Tento záznam o rozhodnutí je přesně to, co je potřeba, když převzetí subdomény může zahrnovat GDPR, NIS2, DORA, smlouvy a oznámení zákazníkům.

Jak budou auditoři testovat vaše důkazy

Integrovaný ISMS by měl umožnit odpovídat různým auditorům stejnou důkazní základnou. Znění otázky se mění, důkaz je však často stejný.

Širší pohled na ujištění často zahrnuje NIST CSF 2.0 a COBIT 2019. NIST CSF 2.0 pomáhá vyjádřit cílový stav prostřednictvím výsledků GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Aktuální profil může ukazovat manuální čtvrtletní přezkumy DNS a nekonzistentní offboarding SaaS. Cílový profil může vyžadovat automatizované týdenní kontroly převzetí, povinné přiřazení vlastníka, důkazy o ukončení spolupráce s dodavatelem a integraci s řízením změn.

Auditor orientovaný na COBIT 2019 nebo ISACA se obvykle zeptá, kdo proces vlastní, jak se riziko vyhodnocuje a řídí, zda jsou změny kontrolovány, zda jsou dodavatelé řízeni, zda jsou konfigurace a aktiva spolehlivá a zda důkazy o ujištění podporují reporting vedení. Nemusí se nejprve ptát na seznam CNAME. Může se zeptat, jak vedení ví, že externí digitální služby jsou kontrolovány po celý svůj životní cyklus.

Jak vypadají dobré auditní důkazy

Balíček důkazů pro dangling DNS by měl být dostatečně malý na udržování, ale dostatečně úplný pro obhajobu. Clarysec obvykle doporučuje následující sadu důkazů:

• Evidence zón DNS se zdrojem, datem, typem záznamu, cílem a vlastníkem.
• Výsledky skenování externí útočné plochy dokládající kontroly převzetí.
• Záznamy v registru aktiv pro domény, subdomény, cloudové služby, SaaS aplikace a CDN.
• Registr služeb uvádějící interní nebo dodavatelskou odpovědnost.
• Požadavky na změnu pro vytvoření, úpravu a odstranění záznamů DNS.
• Kontrolní seznamy onboardingu cloudových a SaaS služeb včetně přezkumu vlastní domény a DNS.
• Smlouvy s dodavateli nebo bezpečnostní doložky pokrývající DNS, hosting, podporu při incidentech a ukončení.
• Tikety zranitelností se závažností, vlastníkem, datem nápravy a důkazy o retestu.
• Posouzení PII, pokud subdoména zpracovává nebo dříve zpracovávala osobní údaje.
• Záznamy o klasifikaci incidentů pro podezření na převzetí nebo potvrzené převzetí.
• Získané poznatky a aktualizované postupy po zjištěních.

Důležité jsou také metriky. Vedení by mělo vidět počet externích subdomén, procento subdomén s přiřazenými vlastníky, počet zjištění dangling DNS, průměrnou dobu nápravy, zpožděná vysoce riziková zjištění, subdomény hostované dodavateli bez aktuálního odkazu na smlouvu a procento ukončení cloudových služeb s důkazy o odstranění DNS.

Tyto metriky převádějí technickou hygienu na důkazy o dohledu vedení.

Typické vzorce selhání, které Clarysec nachází

U klientů ze SaaS, fintechu, zdravotnických technologií, řízených služeb a e-commerce se opakují stejné vzorce.

Za prvé, vlastnictví DNS je rozděleno mezi týmy. Vývoj vlastní cloud. Marketing vlastní kampaně. IT vlastní přístup k poskytovateli DNS. Nákup vlastní ukončení SaaS. Nikdo nevlastní celý životní cyklus.

Za druhé, smazání cloudu je považováno za konec služby. Ve skutečnosti mohou zůstat DNS, certifikáty, pravidla WAF, monitorování, tajné údaje, dokumentace a záznamy dodavatelů.

Za třetí, skenery zranitelností se zaměřují na aktivní hostitele, ale míjejí podmínky převzetí specifické pro poskytovatele. Organizace potřebují kontroly externí útočné plochy, které rozumějí běžným chybovým stavům SaaS a cloudu.

Za čtvrté, postupy ukončení spolupráce s dodavateli se zaměřují na faktury a vrácení dat, nikoli na vlastní domény, záznamy DNS a změny dílčích zpracovatelů.

Za páté, týmy ochrany soukromí jsou informovány příliš pozdě. Pokud subdoména zpracovávala PII, DPO nebo vedoucí ochrany soukromí musí být součástí klasifikace dříve, než se přijmou předpoklady.

Za šesté, důkazy existují, ale jsou rozptýlené. Export DNS je v jednom nástroji, požadavky na změnu v jiném, dodavatelské smlouvy v nákupu, zprávy o zranitelnostech ve skenerech a analýza ochrany soukromí v e-mailu. Auditoři vnímají roztříštěnost jako slabinu.

Sada nástrojů Clarysec toto řeší propojením politik, registrů, opatření a pracovních postupů pro důkazy.

30denní akční plán pro řízení DNS

Pokud jste našli jeden záznam dangling DNS, předpokládejte, že existují další. Pokud jste nenašli žádný, ujistěte se, že dokážete prokázat proč.

Začněte tímto 30denním plánem:

1. Exportujte všechny autoritativní zóny DNS.
2. Identifikujte záznamy CNAME, ALIAS, A a AAAA odkazující na cloudové, SaaS, CDN a agenturou spravované služby.
3. Přiřaďte vlastníky a obchodní účely.
4. Proveďte kontroly převzetí a manuálně validujte podezřelé záznamy.
5. Vytvořte tikety zranitelností pro potvrzená rizika.
6. Odstraňte nebo znovu nárokujte vystavené záznamy prostřednictvím řízení změn.
7. Aktualizujte registr aktiv, registr cloudových služeb a registr dodavatelů.
8. Přezkoumejte, zda některá dotčená subdoména zpracovávala PII.
9. Přidejte kontroly životního cyklu DNS do onboardingu cloudových služeb, nákupu SaaS a ukončení spolupráce s dodavateli.
10. Reportujte metriky vedení.

Technická oprava dangling DNS je často jednoduchá. Náprava v oblasti řízení je to, co zabrání dalšímu převzetí.

Clarysec vám může pomoci toto provozně zavést pomocí Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls a naší sady politik pro správu aktiv, používání cloudových služeb, řízení zranitelností, řízení dodavatelů, zabezpečení PII, reakci na incidenty a auditní důkazy.

Pokud chcete přístup připravený pro audit, Clarysec vám může pomoci vytvořit balíček důkazů pro DNS a cloudovou expozici, namapovat jej na ISO/IEC 27001:2022, NIS2, DORA a GDPR a proměnit zapomenuté subdomény v řízená, vlastněná a monitorovaná aktiva. Stáhněte si příslušnou sadu nástrojů Clarysec, požádejte o demo nebo si naplánujte posouzení řízení DNS dříve, než další zapomenutý odkaz najde penetrační tester, auditor nebo útočník.