Riadenie osirelých DNS záznamov pre NIS2, DORA a GDPR

CISO dostáva správu v pondelok o 07:12.

Bezpečnostný výskumník zistil, že promo.company.com smeruje na opustenú cloudovú aplikáciu. DNS záznam je stále aktívny. Cloudový zdroj už neexistuje. SaaS tenant, ktorý kedysi obsluhoval kampaň, bol vymazaný pred šiestimi mesiacmi, krátko po tom, ako marketing prešiel na inú platformu. CNAME nikto neodstránil.

O 08:30 už otázka neznie: „Môže niekto prevziať subdoménu?“ Otázka znie: „Prečo nikto nevedel, že toto aktívum existuje?“

O 09:15 sa zapája právne oddelenie, pretože subdoména kedysi zbierala e-mailové adresy do čakacej listiny k produktu. Zapája sa obstarávanie, pretože kampaňovú platformu spravovala agentúra. Zapája sa funkcia zabezpečenia súladu, pretože spoločnosť sa pripravuje na dozorný audit ISO/IEC 27001:2022, pripravenosť na NIS2 a zákaznícke dotazníky na preukázanie súladu. DPO sa pýta, či by sa expozícia mohla stať porušením ochrany osobných údajov podľa GDPR, ak by bola subdoména zneužitá. CFO sa pýta, či by rovnaká slabina mohla ovplyvniť platobný portál v regulovanom prostredí finančných služieb skupiny.

Technická náprava môže trvať niekoľko minút. Problém riadenia sa však môže riešiť mesiace, ak organizácia nevie preukázať, že každé aktívum prístupné z internetu je známe, má vlastníka, je preskúmavané, monitorované a vyraďované prostredníctvom riadeného procesu.

Preto sa osirelé DNS záznamy a prevencia prevzatia subdomény nesmú považovať za úzku úlohu čistenia DNS. Neaktuálny DNS záznam je často viditeľným príznakom hlbších zlyhaní kontrol: neúplnej inventarizácie aktív, slabého vlastníctva, chýbajúcich dôkazov o vyradení, nedostatočného riadenia zmien, neprimeraného riadenia ukončenia dodávateľa, nedostatočného monitorovania externej útočnej plochy a nejasnej klasifikácie incidentov.

Pre klientov Clarysec sú osirelé DNS záznamy testom systému riadenia. Ukazujú, či politiky, kontroly, registre, dôkazy a priradenie zodpovednosti skutočne fungujú, keď sa zabudnutá cloudová závislosť stane príležitosťou pre útočníka.

Čo osirelé DNS záznamy skutočne znamenajú

Prevzatie subdomény je možné vtedy, keď DNS záznam, často CNAME, smeruje na zdroj, ktorý už neexistuje alebo už nie je pod kontrolou organizácie. Ak si útočník dokáže cieľový zdroj v cloudovej alebo SaaS platforme nárokovať alebo ho znovu vytvoriť, môže byť schopný zobrazovať obsah pod dôveryhodnou subdoménou organizácie.

Bežné príklady zahŕňajú:

• CNAME smerujúci na nenárokovanú cloudovú aplikačnú službu.
• Vlastný názov hostiteľa v SaaS ponechaný v DNS po zrušení predplatného.
• CDN distribúciu odstránenú z konzoly poskytovateľa, ktorá je však stále uvedená vo verejnom DNS.
• Marketingovú mikrostránku vyradenú agentúrou bez odstránenia DNS.
• Koncový bod úložiska alebo mapovanie statickej webovej stránky, ktoré možno znovu zaregistrovať.
• Vývojovú subdoménu vystavenú cez zabudnutý projekt typu platforma ako služba.

Dopad na organizáciu môže byť závažný. Útočníci môžu hostovať phishingové stránky, zachytávať prihlasovacie údaje, distribuovať malvér, zneužívať reputáciu domény, zachytávať údaje relácie alebo poškodiť dôveru v značku. Ak subdoména predtým spracúvala osobné údaje, aj krátkodobé prevzatie môže spustiť analýzu porušenia ochrany údajov podľa GDPR. Ak dotknutá služba podporuje regulované finančné operácie, incident môže vyžadovať aj posúdenie podľa DORA alebo interných rámcov rizík IKT.

Audítori čoraz častejšie vnímajú osirelé DNS záznamy ako dôkaz zrelosti kontrol. Jeden neaktuálny záznam môže naznačovať, že organizácia nevie, čo vlastní, kto je vlastníkom, ako sa preskúmavajú zmeny, ako sa ukončuje používanie cloudových služieb alebo ako sa monitorujú aktíva dostupné z internetu.

Preto Clarysec mapuje túto tému naprieč ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a auditnými očakávaniami COBIT 2019.

Prečo je ISO 27001:2022 praktickou chrbticou

Najúčinnejší spôsob riadenia osirelých DNS záznamov nie je vytvárať samostatné programy pre NIS2, DORA a GDPR. Je ním použiť ISO/IEC 27001:2022 ako chrbticu systému riadenia a vytvoriť dôkazy raz pre viaceré potreby uistenia.

Relevantné požiadavky začínajú ešte pred Annex A. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela svojmu kontextu, požiadavkám zainteresovaných strán, rozsahu ISMS a závislostiam od iných organizácií. Pri riadení osirelých DNS záznamov by rozsah mal zahŕňať externé DNS, domény, registrátorov, cloudové služby, SaaS platformy, agentúry, spravovaný hosting, CDN a každú tretiu stranu, ktorá môže vytvárať alebo vyraďovať služby prístupné z internetu.

Kapitoly 5.1 až 5.3 z tejto témy robia otázku vedenia a preukázateľnej zodpovednosti. Vrcholový manažment musí zosúladiť ISMS so strategickým smerovaním organizácie, poskytnúť zdroje, komunikovať dôležitosť informačnej bezpečnosti a prideliť zodpovednosti. Ak marketing môže spustiť mikrostránku, engineering môže vytvárať cloudové koncové body a obstarávanie môže ukončovať SaaS zmluvy, organizácia potrebuje model riadenia, ktorý medzi nimi jasne priraďuje vlastníctvo DNS a služieb.

Kapitoly 6.1.1 až 6.1.3 poskytujú logiku posúdenia rizík, ošetrenia rizík a vyhlásenia o aplikovateľnosti. Osirelé DNS záznamy majú byť zaznamenané ako realistický rizikový scenár, nie iba ako výstup skenera. Ovplyvňujú dôvernosť, integritu a dostupnosť a často sa mapujú na zákonné, regulačné a zmluvné povinnosti.

Kapitoly 7.5, 8.1, 8.2 a 8.3 premieňajú riadenie na dôkazy. Vyžadujú riadené zdokumentované informácie, plánované a riadené prevádzkové procesy, zohľadnenie neúmyselných zmien, riadenie externe poskytovaných procesov, pravidelné posúdenia rizík a zdokumentované výsledky ošetrenia rizík.

Annex A následne poskytuje katalóg kontrol. V projektoch Clarysec vyzerajú hlavné vzťahy ISO/IEC 27002:2022 zvyčajne takto:

Pointa je jednoduchá. ISO/IEC 27001:2022 nevyžaduje jednorazové hrdinské čistenie. Vyžaduje riadený prevádzkový model, ktorý zabraňuje opakovaniu.

Pohľad Zenith Controls: jedno riziko, tri kontrolné kotvy

V Zenith Controls: príručka pre súlad naprieč rámcami Zenith Controls používa Clarysec relevantné kontroly ISO/IEC 27002:2022 ako kotvy pre súlad naprieč rámcami. Pre riadenie osirelých DNS záznamov a prevzatia subdomén sú kľúčové tri kontroly.

Kontrola 5.9, Inventarizácia informácií a iných súvisiacich aktív, je klasifikovaná ako preventívna, podporuje dôvernosť, integritu a dostupnosť, je zosúladená s kyberbezpečnostným konceptom Identify a patrí pod správu aktív ako prevádzkovú schopnosť, pričom riadenie, ekosystém a ochrana sú bezpečnostnými doménami.

Kontrola 5.23, Informačná bezpečnosť pri používaní cloudových služieb, je klasifikovaná ako preventívna, podporuje dôvernosť, integritu a dostupnosť, je zosúladená s Protect a patrí pod bezpečnosť vzťahov s dodávateľmi ako prevádzkovú schopnosť, pričom riadenie, ekosystém a ochrana sú bezpečnostnými doménami.

Kontrola 8.8, Riadenie technických zraniteľností, je klasifikovaná ako preventívna, podporuje dôvernosť, integritu a dostupnosť, je zosúladená s Identify a Protect a patrí pod riadenie hrozieb a zraniteľností ako prevádzkovú schopnosť, pričom riadenie, ekosystém, ochrana a obrana sú bezpečnostnými doménami.

Je to dôležité preto, že osirelé DNS záznamy nie sú iba zlyhaním kontroly aktív, iba zlyhaním cloudovej kontroly ani iba zraniteľnosťou. Sú všetkým naraz. Organizácia musí preukázať, že inventarizácia aktív, riadenie používania cloudových služieb a riadenie zraniteľností sa navzájom posilňujú.

Clarysec k týmto kotvám často pridáva podporné praktiky: ISO/IEC 27005 pre disciplínu posudzovania a ošetrenia rizík, ISO/IEC 27017 pre riadenie bezpečnosti cloudových služieb, ISO/IEC 27018 tam, kde cloudové služby spracúvajú PII, ISO/IEC 27701 pre systém manažérstva informácií o ochrane súkromia a ISO 22301 tam, kde sú relevantné kontinuita činností a krízová reakcia.

Dôkazy z politík, ktoré už vyžadujú riadenie životného cyklu DNS

Mnohé organizácie už majú politiky, ktoré by pri správnej implementácii osirelým DNS záznamom zabránili. Medzera spočíva v tom, že riadenie životného cyklu DNS nie je s týmito politikami výslovne prepojené.

Clarysec Politika správy aktív pre MSP Politika správy aktív pre MSP, Požiadavky na implementáciu politiky, bod 6.6.1 stanovuje:

Aktíva v cloudovom prostredí (napr. účty úložísk, SaaS platformy, webové domény) musia byť tiež zahrnuté do evidencie.

Tá istá politika v bode 6.6.2 dopĺňa:

Vlastníctvo, účel, prístupové oprávnenia a lehoty obnovy musia byť zdokumentované.

Pre riadenie osirelých DNS záznamov to znamená, že každá produkčná subdoména a každá významná neprodukčná subdoména má mať určeného vlastníka, účel použitia, prepojenú službu, prístupový model a dátum preskúmania.

Najdôležitejší je bod 6.6.3:

Služby po uplynutí platnosti alebo nepoužívané služby musia byť deaktivované a odstránené z evidencie.

Pri DNS sa to musí vykladať opatrne. Odstránenie služby z evidencie nestačí. Preskúmať sa musí aj DNS záznam, cloudová väzba, nárok na vlastnú doménu v SaaS, certifikát, pravidlo WAF, konfigurácia CDN a monitorovací záznam.

Enterprise verzia posilňuje tento širší koncept aktív. Clarysec Politika správy aktív Politika správy aktív, Rozsah, bod 2.2.5 stanovuje:

Logické aktíva: názvy domén, licencie, používateľské účty, referenčné konfigurácie

Názvy domén a konfigurácie nie sú administratívna drobnosť. Sú to aktíva nesúce dôveru, ktoré sa môžu stať cestami útoku.

Rovnako dôležitá je väzba na riadenie zmien. Clarysec Politika riadenia zmien Politika riadenia zmien, Účel, bod 1.1 stanovuje:

Táto politika ustanovuje formálny rámec na iniciovanie, posudzovanie, schvaľovanie, implementáciu a preskúmanie zmien informačných systémov, infraštruktúry, aplikácií a súvisiacich procesov organizácie.

Odstránenie DNS záznamu, ukončenie SaaS služby, vymazanie cloudovej aplikácie, migrácia CDN alebo vyradenie marketingovej mikrostránky by preto mali vytvoriť dôkazy o zmene. Neexistencia tiketu zmeny je často prvým auditným varovným signálom.

Prepojené musí byť aj riadenie cloudu. Clarysec Politika používania cloudových služieb Politika používania cloudových služieb, Požiadavky na riadenie, bod 5.5 stanovuje:

Tím informačnej bezpečnosti musí pravidelne posudzovať sieťovú prevádzku, DNS aktivitu a logy s cieľom odhaliť neoprávnené používanie cloudových služieb (tieňové IT). Zistené porušenia musia byť bezodkladne vyšetrené.

Pri prevencii prevzatia subdomény nie je monitorovanie DNS aktivity iba o tieňovom IT. Ide aj o neaktuálne IT, teda o aktíva, ktoré boli kedysi schválené, ale už nie sú pod kontrolou.

Praktický pracovný postup Clarysec pre riadenie osirelých DNS záznamov

Silný program pre osirelé DNS záznamy nie je zložitý. Je disciplinovaný, opakovateľný a prepojený s ISMS, riadením zraniteľností, riadením zmien a životným cyklom dodávateľov.

Pre MSP sa to môže začať jednoduchým registrom. V podnikových prostrediach sa zvyčajne integrujú exporty DNS, správa externej útočnej plochy, inventáre cloudových aktív, záznamy CMDB, skenery zraniteľností, upozornenia SIEM a tiketovacie systémy.

Otázka riadenia zostáva rovnaká: viete preukázať, že každá externe dostupná subdoména je známa, má vlastníka, je monitorovaná a je odstrániteľná prostredníctvom riadeného procesu?

Opustená kampaňová subdoména riešená správnym spôsobom

Vráťme sa k pondelkovému incidentu. promo.company.com smeruje na opustenú SaaS kampaňovú stránku.

Najprv vedúci bezpečnosti vytvorí záznam zraniteľnosti, pretože aktívum je dostupné z internetu. Clarysec Politika riadenia zraniteľností a záplat Politika riadenia zraniteľností a záplat, Požiadavky na implementáciu politiky, bod 6.1.1 stanovuje:

Všetky systémy musia byť skenované aspoň mesačne; aktíva s vysokým rizikom alebo externe vystavené aktíva musia byť skenované týždenne.

Pre MSP ekvivalentná politika spresňuje prioritizáciu. Politika riadenia zraniteľností a záplat pre MSP Politika riadenia zraniteľností a záplat pre MSP, Požiadavky na implementáciu politiky, bod 6.5.1 stanovuje:

Systémy, ktoré spracúvajú osobné údaje, poskytujú vzdialený prístup alebo sú dostupné z internetu, musia mať prioritu pri skenovaní a aktualizáciách.

Po druhé, vlastník sa identifikuje prostredníctvom registra aktív. Ak je vlastník neznámy, ide o zlyhanie kontroly správy aktív. Register sa aktualizuje tak, aby obsahoval názov DNS, cieľového poskytovateľa, pôvodného vlastníka za organizáciu, klasifikáciu údajov, dodávateľa a stav.

Po tretie, IT skontroluje cloudovú alebo SaaS platformu. Ak bol cloudový účet vymazaný, priamo relevantná je Clarysec Politika používania cloudových služieb pre MSP Politika používania cloudových služieb pre MSP, Požiadavky na implementáciu politiky, bod 6.3.6:

Vymazané cloudové účty musí poskytovateľ IT služieb alebo generálny riaditeľ preskúmať z hľadiska reziduálneho prístupu, osirelých údajov alebo prehliadnutého obsahu.

Po štvrté, vlastník zmeny založí núdzový alebo zrýchlený tiket zmeny na odstránenie DNS záznamu alebo na dočasné znovunárokovanie zdroja pred jeho odstránením. Tiket obsahuje posúdenie dopadu, plán návratu do pôvodného stavu, schválenia, dôkazy o implementácii a validáciu po zmene.

Po piate, vedúci ochrany súkromia posúdi, či subdoména spracúvala alebo mohla sprístupniť osobné údaje. Clarysec Politika bezpečnosti a riadenia prístupu k osobným údajom Politika bezpečnosti a riadenia prístupu k osobným údajom, Bezpečná konfigurácia a riadenie zraniteľností, bod 4.7.4 stanovuje:

[Obe] Vlastník systému / vlastník aplikácie MUSÍ zaznamenať pokrytie posúdenia zraniteľností systémov spracúvajúcich PII v REG12 aspoň štvrťročne a po podstatnej technickej zmene.

Bod 4.7.5 dopĺňa:

[Obe] Vedúci informačnej bezpečnosti MUSÍ zaznamenať nevyriešené vysokorizikové zraniteľnosti ovplyvňujúce PII v REG12 do piatich pracovných dní od validácie.

Tieto body sa uplatňujú bez ohľadu na to, či organizácia vystupuje ako prevádzkovateľ alebo sprostredkovateľ, pretože sú označené ako [Obe]. Pri probléme s osirelým DNS záznamom zahŕňajúcom PII nesmú dôkazy zostať iba v technickom tikete. Musia sa premietnuť aj do registra dôkazov zraniteľností týkajúcich sa PII.

Po šieste, ak kampaň hostovala agentúra alebo poskytovateľ SaaS, obstarávanie skontroluje záznamy tretích strán. Clarysec Politika riadenia súkromia sprostredkovateľov, ďalších sprostredkovateľov a tretích strán Politika riadenia súkromia sprostredkovateľov, ďalších sprostredkovateľov a tretích strán, Identifikácia a klasifikácia vzťahu, bod 4.1.2 stanovuje:

[Všetci] Vlastník procesu / vlastník organizácie MUSÍ identifikovať každý navrhovaný vzťah s treťou stranou, ktorá bude spracúvať, pristupovať, prijímať, ukladať, prenášať, podporovať alebo inak ovplyvňovať PII, v REG08 pred obstarávaním, nástupom, obnovou alebo podstatnou zmenou ochrany súkromia tretej strany.

Bod 4.5.5 vyžaduje:

[Obe] Vlastník dodávateľa / obstarávania MUSÍ zaznamenať miesta spracúvania, miesta hostovania a indikátory medzinárodného prenosu v REG08 a prepojiť príslušné dôkazy prenosu s REG09 pred schválením sprostredkovateľa, ďalšieho sprostredkovateľa, zmeny lokality alebo zmeny služby relevantnej pre prenos.

Nakoniec vedúci súladu pripraví balík dôkazov. Clarysec Politika monitorovania auditov a súladu Politika monitorovania auditov a súladu, Ciele, bod 3.4 uvádza, že jedným cieľom je:

Vytvárať obhájiteľné dôkazy a auditnú stopu na podporu regulačných preverení, súdnych konaní alebo požiadaviek zákazníkov na preukázanie súladu.

Presne tento výsledok CISO potrebuje, keď sa zákazník, regulátor alebo audítor opýta: „Ako viete, že sa to už nezopakuje?“

Kam zapadá Zenith Blueprint

Clarysec Zenith Blueprint: 30-kroková cestovná mapa pre audítora Zenith Blueprint premieňa kontroly na prevádzkové praktiky pripravené na audit. Osirelé DNS záznamy sa výrazne mapujú na štyri oblasti.

Vo fáze Controls in Action krok 22 pokrýva organizačné opatrenia 5.1 až 5.18 vrátane kontroly ISO/IEC 27002:2022 5.9. Zenith Blueprint uvádza:

Žiadna organizácia nemôže chrániť to, o čom nevie, že to má. Kontrola 5.9 formalizuje tento základný princíp tým, že vyžaduje zriadenie a udržiavanie aktuálnej evidencie všetkých informačných a súvisiacich aktív relevantných pre ISMS.

Pokračuje:

Vo svojej najstrategickejšej podobe slúži inventarizácia aktív ako centrálny nervový systém vášho ISMS.

Inventár subdomén nie je vedľajší zoznam. Vstupuje do rozhodnutí o prístupe, skenovania zraniteľností, logovania, riadenia dodávateľov, mapovania ochrany súkromia a reakcie na incidenty.

V kroku 20 Zenith Blueprint pokrýva technologické kontrolné opatrenia 8.18 až 8.26. Pri kontrole 8.21, Bezpečnosť sieťových služieb, ukladá organizáciám validovať bezpečnosť sieťových služieb:

Uveďte všetky interné a externé sieťové služby (DNS, VPN, SMTP, DHCP, API brány atď.).

Preto patria poskytovatelia DNS, registrátori, cloudové DNS, CDN platformy a funkcie vlastných domén v SaaS do registra služieb.

V kroku 19 Zenith Blueprint pokrýva technologické kontrolné opatrenia 8.1 až 8.17. Pri kontrole 8.8 uvádza:

Riadenie zraniteľností je jednou z najkritickejších oblastí modernej kybernetickej hygieny. Hoci firewally a antivírusové nástroje poskytujú ochranu, môžu byť oslabené, ak zostanú vystavené nezaplátané systémy alebo nesprávne nakonfigurované služby.

Osirelý DNS záznam je nesprávne nakonfigurovaná externá cesta k službe. Aj keď neexistuje CVE, má sa riešiť prostredníctvom riadenia zraniteľností: validovať, ohodnotiť, priradiť, napraviť, opätovne otestovať a uzavrieť.

V kroku 23 sa Zenith Blueprint venuje organizačným opatreniam 5.19 až 5.37. Pri kontrole 5.23 odporúča:

Uveďte všetky cloudové služby, ktoré sa aktuálne používajú (5.23), vrátane tieňového IT, ak je známe. Identifikujte, kto ich schválil a či bola vykonaná due diligence. Vypracujte jednoduchý hodnotiaci kontrolný zoznam, ktorý pokrýva lokalitu údajov, prístupový model, logovanie a šifrovanie.

Na prevenciu prevzatia subdomény doplňte do tohto kontrolného zoznamu hodnotenia cloudovej služby vlastné domény, DNS závislosti, vlastníka vyradenia a dôkazy o ukončení.

Mapovanie na NIS2, DORA a GDPR

NIS2 robí z riadenia osirelých DNS záznamov otázku na úrovni riadiaceho orgánu pre mnohé základné a dôležité subjekty. Article 20 vyžaduje, aby riadiace orgány schvaľovali opatrenia na riadenie kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenia v oblasti kybernetickej bezpečnosti. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia s využitím komplexného prístupu k rizikám. Medzi minimálne oblasti patria analýza rizík, riešenie incidentov, kontinuita činností, bezpečnosť dodávateľského reťazca, bezpečné obstarávanie, vývoj a údržba, riešenie zraniteľností, posúdenie účinnosti, kybernetická hygiena, školenie, riadenie prístupu a správa aktív.

Program pre osirelé DNS záznamy sa na tieto oblasti mapuje priamo. Article 21(3) tiež vyžaduje, aby bezpečnosť dodávateľského reťazca zohľadňovala zraniteľnosti špecifické pre každého priameho dodávateľa alebo poskytovateľa služieb. Ak marketingová agentúra, SaaS dodávateľ, poskytovateľ spravovaného hostingu alebo cloudová platforma spravuje vlastné domény, kontroly špecifické pre dodávateľa majú pokrývať vlastníctvo DNS, ukončenie služby, podporu pri incidente a odovzdanie dôkazov.

Article 23 je relevantný, ak dôjde k prevzatiu alebo ak prevzatie môže spôsobiť závažné prevádzkové narušenie, finančnú stratu alebo značnú materiálnu či nemateriálnu ujmu. NIS2 používa stupňované hlásenie: včasné varovanie do 24 hodín od zistenia významného incidentu, oznámenie do 72 hodín, priebežné správy na vyžiadanie a záverečnú správu do jedného mesiaca od oznámenia incidentu.

Pre finančné subjekty je DORA odvetvovo špecifickým režimom digitálnej prevádzkovej odolnosti. Articles 5 a 6 vyžadujú interný rámec riadenia a kontrolný rámec pre riadenie rizík IKT, s konečnou zodpovednosťou riadiaceho orgánu, jasnými rolami IKT, politikami pre dostupnosť, autentickosť, integritu a dôvernosť údajov, plánmi auditov, zdrojmi, politikou služieb tretích strán a zdokumentovaným rámcom riadenia rizík IKT.

Articles 8 až 14 tvoria prevádzkové jadro. Article 8 vyžaduje identifikáciu, klasifikáciu a dokumentovanie obchodných funkcií podporovaných IKT, informačných aktív, aktív IKT, závislostí, prepojení s externými poskytovateľmi IKT, inventárov, rizikových scenárov a legacy systémov. Osirelý CNAME je často prehliadnutá závislosť. Article 9 vyžaduje ochranu a prevenciu. Article 10 vyžaduje detekciu anomálnych aktivít, incidentov IKT a potenciálnych jednotlivých bodov zlyhania. Articles 11 a 12 sa venujú kontinuite, obnove, zálohovaniu a rekonštrukcii. Article 13 vyžaduje učenie sa zo zraniteľností, hrozieb, incidentov a testov.

Articles 17 až 19 formalizujú riadenie incidentov, klasifikáciu a hlásenie. Articles 28 až 30 zakotvujú riziko IKT tretích strán na báze životného cyklu. Finančné subjekty zostávajú plne zodpovedné pri využívaní poskytovateľov IKT služieb. Pre pripravenosť na DORA odporúča Clarysec doplniť do každého registra DNS a cloudových služieb štyri polia: podpora zásadnej alebo dôležitej funkcie, externý poskytovateľ IKT, referencia na zmluvu alebo register a stav testu ukončenia.

GDPR sa uplatní, keď sa problém týka osobných údajov. Prevzatie subdomény nie je automaticky porušením ochrany osobných údajov, ale môže sa ním stať, ak dotknutá subdoména zbiera prihlasovacie údaje, zachytáva údaje z formulárov, vydáva sa za službu, sprístupňuje identifikátory používateľov alebo umožňuje neoprávnený prístup k osobným údajom. GDPR Article 5 vyžaduje integritu, dôvernosť a preukázateľnú zodpovednosť. Article 32 vyžaduje primeranú bezpečnosť spracúvania. Article 33 môže vyžadovať oznámenie dozornému orgánu, ak porušenie ochrany osobných údajov pravdepodobne povedie k riziku pre práva a slobody fyzických osôb.

Clarysec Politika riadenia incidentov a porušení ochrany osobných údajov Politika riadenia incidentov a porušení ochrany osobných údajov, Klasifikácia a posúdenie porušenia ochrany údajov, bod 4.2.6 podporuje túto analýzu spúšťačov naprieč viacerými režimami:

[Podmienečne] Vedúci ochrany súkromia / manažér PIMS MUSÍ vyhodnotiť príslušné právne, odvetvové, finančno-sektorové, kyberbezpečnostné, zmluvné, zákaznícke a príjemcom služieb určené spúšťače hlásenia pre každý incident s vysokým dopadom týkajúci sa osobných údajov a zaznamenať výsledok uplatniteľnosti v REG01, REG08 a REG10.

Presne takýto záznam o rozhodnutí je potrebný, keď prevzatie subdomény môže zahŕňať GDPR, NIS2, DORA, zmluvy a oznámenie zákazníkom.

Ako budú audítori testovať vaše dôkazy

Integrovaný ISMS by vám mal umožniť odpovedať rôznym audítorom rovnakou dôkazovou základňou. Znenie otázky sa mení, ale dôkaz je často rovnaký.

Širší pohľad na uistenie často zahŕňa NIST CSF 2.0 a COBIT 2019. NIST CSF 2.0 pomáha vyjadriť cieľový stav prostredníctvom výsledkov GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Aktuálny profil môže ukazovať manuálne štvrťročné preskúmania DNS a nekonzistentné ukončovanie SaaS služieb. Cieľový profil môže vyžadovať automatizované týždenné kontroly prevzatia, povinné priradenie vlastníka, dôkazy o ukončení dodávateľa a integráciu s riadením zmien.

Audítor orientovaný na COBIT 2019 alebo ISACA sa zvyčajne opýta, kto vlastní proces, ako sa riziko hodnotí a usmerňuje, či sú zmeny riadené, či sú dodávatelia riadení, či sú konfigurácie a aktíva spoľahlivé a či dôkazy pre uistenie podporujú podávanie správ manažmentu. Nemusí sa najprv pýtať na zoznam CNAME. Môže sa opýtať, ako manažment vie, že externé digitálne služby sú pod kontrolou počas celého životného cyklu.

Ako vyzerajú dobré auditné dôkazy

Auditný balík pre osirelé DNS záznamy má byť dostatočne malý na udržiavanie, ale dostatočne úplný na obhajobu. Clarysec zvyčajne odporúča tento súbor dôkazov:

• Inventarizácia DNS zón so zdrojom, dátumom, typom záznamu, cieľom a vlastníkom.
• Výsledky skenovania externej útočnej plochy zobrazujúce kontroly prevzatia.
• Záznamy v registri aktív pre domény, subdomény, cloudové služby, SaaS aplikácie a CDN.
• Register služieb zobrazujúci internú alebo dodávateľskú zodpovednosť.
• Tikety zmien pre vytvorenie, úpravu a vymazanie DNS záznamov.
• Kontrolné zoznamy zavedenia cloudových a SaaS služieb vrátane preskúmania vlastných domén a DNS.
• Zmluvy s dodávateľmi alebo bezpečnostné doložky pokrývajúce DNS, hosting, podporu pri incidente a ukončenie.
• Tikety zraniteľností so závažnosťou, vlastníkom, dátumom nápravy a dôkazmi z opätovného testovania.
• Posúdenie PII, ak subdoména spracúva alebo predtým spracúvala osobné údaje.
• Záznamy o klasifikácii incidentov pri podozrení alebo potvrdení prevzatia.
• Získané poučenia a aktualizované postupy po zisteniach.

Dôležité sú aj metriky. Manažment má vidieť počet externých subdomén, percento s priradenými vlastníkmi, počet zistení osirelých záznamov, priemerný čas nápravy, oneskorené vysokorizikové zistenia, subdomény hostované dodávateľom bez aktuálnej referencie na zmluvu a percento ukončení cloudových služieb s dôkazom odstránenia DNS.

Tieto metriky premieňajú technickú hygienu na dôkazy o dohľade manažmentu.

Bežné vzorce zlyhaní, ktoré Clarysec nachádza

U klientov zo SaaS, fintechu, zdravotníckych technológií, spravovaných služieb a e-commerce sa opakujú rovnaké vzorce.

Po prvé, vlastníctvo DNS je rozdelené medzi tímy. Engineering vlastní cloud. Marketing vlastní kampane. IT vlastní prístup k poskytovateľovi DNS. Obstarávanie vlastní ukončenie SaaS. Nikto nevlastní celý životný cyklus.

Po druhé, vymazanie cloudovej služby sa považuje za koniec služby. V skutočnosti môžu zostať DNS, certifikáty, pravidlá WAF, monitorovanie, tajomstvá, dokumentácia a záznamy dodávateľov.

Po tretie, skenery zraniteľností sa zameriavajú na živé hosty, ale prehliadajú podmienky prevzatia špecifické pre poskytovateľov. Organizácie potrebujú kontroly externej útočnej plochy, ktoré rozumejú bežným chybovým stavom SaaS a cloudu.

Po štvrté, postupy ukončenia dodávateľa sa zameriavajú na faktúry a vrátenie údajov, nie na vlastné domény, DNS záznamy a zmeny ďalších sprostredkovateľov.

Po piate, tímy ochrany súkromia sú informované príliš neskoro. Ak subdoména spracúvala PII, DPO alebo vedúci ochrany súkromia má byť súčasťou klasifikácie ešte pred vytvorením predpokladov.

Po šieste, dôkazy existujú, ale sú rozptýlené. Export DNS je v jednom nástroji, tikety zmien v inom, zmluvy s dodávateľmi v obstarávaní, správy o zraniteľnostiach v skeneroch a analýza ochrany súkromia v e-mailoch. Audítori vnímajú fragmentáciu ako slabinu.

Toolkit Clarysec to rieši prepojením politík, registrov, kontrol a dôkazových pracovných tokov.

30-dňový akčný plán pre riadenie DNS

Ak ste našli jeden osirelý DNS záznam, predpokladajte, že existujú ďalšie. Ak ste nenašli žiadny, uistite sa, že viete preukázať prečo.

Začnite týmto 30-dňovým plánom:

1. Exportujte všetky autoritatívne DNS zóny.
2. Identifikujte záznamy CNAME, ALIAS, A a AAAA smerujúce na cloudové služby, SaaS, CDN a služby spravované agentúrou.
3. Priraďte vlastníkov a účely organizácie.
4. Spustite kontroly prevzatia a podozrivé záznamy manuálne validujte.
5. Vytvorte tikety zraniteľností pre potvrdené riziká.
6. Odstráňte alebo znovu si nárokujte exponované záznamy prostredníctvom riadenia zmien.
7. Aktualizujte register aktív, register cloudových služieb a register dodávateľov.
8. Preskúmajte, či niektorá dotknutá subdoména spracúvala PII.
9. Doplňte kontroly životného cyklu DNS do zavádzania cloudových služieb, obstarávania SaaS a ukončenia dodávateľov.
10. Reportujte metriky manažmentu.

Technická oprava osirelých DNS záznamov je často jednoduchá. Náprava riadenia je to, čo zabráni ďalšiemu prevzatiu.

Clarysec vám môže pomôcť operacionalizovať tento prístup pomocou Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls a nášho balíka politík pre správu aktív, používanie cloudových služieb, riadenie zraniteľností, riadenie dodávateľov, bezpečnosť PII, reakciu na incidenty a auditné dôkazy.

Ak potrebujete prístup pripravený na audit, Clarysec vám pomôže vytvoriť balík dôkazov pre DNS a cloudové expozície, namapovať ho na ISO/IEC 27001:2022, NIS2, DORA a GDPR a premeniť zabudnuté subdomény na riadené aktíva s vlastníkom a monitorovaním. Stiahnite si príslušný toolkit Clarysec, požiadajte o demo alebo si naplánujte posúdenie riadenia DNS skôr, než ďalší zabudnutý ukazovateľ nájde penetračný tester, audítor alebo útočník.