Upravljanje rizikom dangling DNS-a za NIS2, DORA i GDPR

CISO prima poruku u ponedjeljak u 07:12.

Istraživač sigurnosti pronašao je promo.company.com koji upućuje na napuštenu aplikaciju u oblaku. DNS zapis i dalje je aktivan. Resurs u oblaku više ne postoji. SaaS tenant koji je nekad posluživao kampanju izbrisan je prije šest mjeseci, nedugo nakon što je marketing prešao na drugu platformu. Nitko nije uklonio CNAME.

Do 08:30 pitanje više nije: „Može li netko preuzeti poddomenu?” Pitanje je: „Zašto nitko nije znao da ta imovina postoji?”

Do 09:15 uključuje se pravna služba jer je poddomena nekoć prikupljala adrese e-pošte za listu čekanja za proizvod. Uključuje se nabava jer je kampanjskom platformom upravljala agencija. Uključuje se funkcija usklađenosti jer se društvo priprema za nadzornu reviziju ISO/IEC 27001:2022, spremnost za NIS2 i sigurnosne upitnike klijenata. Službenik za zaštitu podataka (DPO) pita može li izloženost postati povreda osobnih podataka prema GDPR-u ako se poddomena zloupotrijebi. CFO pita može li ista slabost utjecati na portal za plaćanja u reguliranom okruženju financijskih usluga unutar grupe.

Tehničko rješenje može trajati nekoliko minuta. Problem upravljanja može se razrješavati mjesecima ako organizacija ne može dokazati da je svaka imovina izložena internetu poznata, ima vlasnika, pregledava se, prati i povlači iz uporabe kroz kontrolirani proces.

Zato se dangling DNS i sprječavanje preuzimanja poddomena ne smiju tretirati kao uski zadatak čišćenja DNS-a. Zastarjeli DNS zapis često je vidljiv simptom dubljih propusta kontrola: nepotpunog popisa imovine, slabog vlasništva, nedostajućih dokaza o povlačenju iz uporabe, slabog upravljanja promjenama, nedostatnog izlaznog postupka dobavljača, nedostatnog praćenja vanjske površine napada i nejasne klasifikacije incidenata.

Za klijente Clarysec, dangling DNS test je sustava upravljanja. Pokazuje funkcioniraju li politike, kontrole, registri, dokazi i odgovornost kada zaboravljena ovisnost u oblaku postane prilika za napadača.

Što dangling DNS zapravo znači

Preuzimanje poddomene postaje moguće kada DNS zapis, često CNAME, upućuje na resurs koji više ne postoji ili više nije pod kontrolom organizacije. Ako napadač može prisvojiti ili ponovno kreirati ciljni resurs na platformi u oblaku ili SaaS platformi, može posluživati sadržaj putem pouzdane poddomene organizacije.

Uobičajeni primjeri uključuju:

• CNAME koji upućuje na nepreuzetu aplikacijsku uslugu u oblaku.
• Prilagođeni SaaS naziv hosta ostavljen u DNS-u nakon otkazivanja pretplate.
• CDN distribuciju uklonjenu iz konzole pružatelja, ali i dalje navedenu u javnom DNS-u.
• Marketinški mikrosajt koji je agencija povukla iz uporabe bez uklanjanja DNS zapisa.
• Krajnju točku za pohranu ili mapiranje statičke web-stranice koje se može ponovno registrirati.
• Razvojnu poddomenu izloženu kroz zaboravljeni projekt platforme kao usluge.

Utjecaj na poslovanje može biti ozbiljan. Napadači mogu hostati phishing stranice, prikupljati vjerodajnice, distribuirati zlonamjerni softver, zloupotrijebiti reputaciju domene, presretati podatke sesije ili narušiti povjerenje u brend. Ako je poddomena prethodno obrađivala osobne podatke, čak i kratkotrajno preuzimanje može pokrenuti analizu povrede prema GDPR-u. Ako zahvaćena usluga podržava regulirane financijske operacije, incident može zahtijevati i procjenu prema DORA-i ili internim okvirima upravljanja IKT rizicima.

Revizori sve češće promatraju dangling DNS kao dokaz zrelosti kontrola. Jedan zastarjeli zapis može pokazati da organizacija ne zna što posjeduje, tko je vlasnik, kako se promjene pregledavaju, kako se izlazi iz usluga u oblaku ili kako se prati imovina izložena prema internetu.

Zato Clarysec mapira ovo pitanje na revizijska očekivanja prema ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Zašto je ISO 27001:2022 praktična okosnica

Najjači način upravljanja rizikom dangling DNS-a nije uspostava zasebnih programa za NIS2, DORA i GDPR. To je korištenje ISO/IEC 27001:2022 kao okosnice sustava upravljanja i izrada dokaza jednom za više potreba osiguranja usklađenosti.

Relevantni zahtjevi počinju prije Annex A. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije svoj kontekst, zahtjeve zainteresiranih strana, opseg ISMS-a i ovisnosti s drugim organizacijama. Za upravljanje rizikom dangling DNS-a opseg treba uključivati vanjski DNS, domene, registre domena, usluge u oblaku, SaaS platforme, agencije, upravljani hosting, CDN-ove i svaku treću stranu koja može kreirati ili povlačiti iz uporabe usluge izložene internetu.

Točke 5.1 do 5.3 čine ovo pitanjem vodstva i odgovornosti. Uprava mora uskladiti ISMS s poslovnim smjerom, osigurati resurse, komunicirati važnost informacijske sigurnosti i dodijeliti odgovornosti. Ako marketing može pokrenuti mikrosajt, razvojni timovi mogu kreirati krajnje točke u oblaku, a nabava može raskinuti SaaS ugovore, organizacija treba model upravljanja koji svim tim područjima dodjeljuje jasno vlasništvo nad DNS-om i uslugama.

Točke 6.1.1 do 6.1.3 daju logiku procjene rizika, obrade rizika i Izjave o primjenjivosti. Dangling DNS treba evidentirati kao realističan scenarij rizika, a ne samo kao rezultat skenera. Utječe na povjerljivost, cjelovitost i dostupnost te se često mapira na pravne, regulatorne i ugovorne obveze.

Točke 7.5, 8.1, 8.2 i 8.3 pretvaraju upravljanje u dokaze. Zahtijevaju kontrolirane dokumentirane informacije, planirane i kontrolirane operativne procese, razmatranje nenamjernih promjena, kontrolu eksternaliziranih procesa, periodične procjene rizika i dokumentirane ishode obrade rizika.

Annex A zatim daje katalog kontrola. U projektima Clarysec ključni odnosi s ISO/IEC 27002:2022 obično izgledaju ovako:

Poanta je jednostavna. ISO/IEC 27001:2022 ne traži jednokratno herojsko čišćenje. Traži kontrolirani operativni model koji sprječava ponavljanje.

Pogled iz Zenith Controls: jedan rizik, tri kontrolna sidra

U Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec koristi relevantne kontrole ISO/IEC 27002:2022 kao sidra za usklađenost među okvirima. Za dangling DNS i upravljanje preuzimanjem poddomena ključne su tri kontrole.

Kontrola 5.9, Popis informacija i druge povezane imovine, klasificirana je kao preventivna, podržava povjerljivost, cjelovitost i dostupnost, usklađena je s funkcijom Identifikacija i nalazi se pod upravljanjem imovinom kao operativnom sposobnošću, uz upravljanje, ekosustav i zaštitu kao sigurnosne domene.

Kontrola 5.23, Informacijska sigurnost pri uporabi usluga u oblaku, klasificirana je kao preventivna, podržava povjerljivost, cjelovitost i dostupnost, usklađena je s funkcijom Zaštita i nalazi se pod sigurnošću odnosa s dobavljačima kao operativnom sposobnošću, uz upravljanje, ekosustav i zaštitu kao sigurnosne domene.

Kontrola 8.8, Upravljanje tehničkim ranjivostima, klasificirana je kao preventivna, podržava povjerljivost, cjelovitost i dostupnost, usklađena je s funkcijama Identifikacija i Zaštita te se nalazi pod upravljanjem prijetnjama i ranjivostima kao operativnom sposobnošću, uz upravljanje, ekosustav, zaštitu i obranu kao sigurnosne domene.

To je važno jer dangling DNS nije samo propust kontrole imovine, nije samo propust kontrole oblaka i nije samo ranjivost. On je sve troje. Organizacija mora pokazati da se popis imovine, upravljanje korištenjem usluga u oblaku i upravljanje ranjivostima međusobno podupiru.

Clarysec često dodaje pomoćne prakse oko tih sidara: ISO/IEC 27005 za disciplinu procjene i obrade rizika, ISO/IEC 27017 za upravljanje sigurnošću usluga u oblaku, ISO/IEC 27018 kada usluge u oblaku obrađuju PII, ISO/IEC 27701 za upravljanje osobnim podacima te ISO 22301 kada su relevantni kontinuitet poslovanja i krizni odgovor.

Dokazi iz politika koji već zahtijevaju kontrolu životnog ciklusa DNS-a

Mnoge organizacije već imaju politike koje bi, ako se pravilno provode, spriječile dangling DNS. Praznina je u tome što kontrola životnog ciklusa DNS-a nije izričito povezana s tim politikama.

Clarysecova Politika upravljanja imovinom-sme Politika upravljanja imovinom-sme - SME, Zahtjevi za provedbu politike, točka 6.6.1 navodi:

Imovina temeljena na oblaku (npr. računi za pohranu, SaaS platforme, web-domene) također mora biti uključena u popis imovine.

Ista politika u točki 6.6.2 dodaje:

Vlasništvo, svrha, privilegije pristupa i rokovi obnove moraju biti dokumentirani.

Za upravljanje rizikom dangling DNS-a to znači da svaka produkcijska poddomena i svaka značajna neprodukcijska poddomena trebaju imati imenovanog vlasnika, poslovnu svrhu, povezanu uslugu, model pristupa i datum pregleda.

Najvažnije, točka 6.6.3 navodi:

Usluge kojima je istekao rok ili se ne koriste moraju se deaktivirati i ukloniti iz popisa imovine.

Za DNS to treba pažljivo tumačiti. Uklanjanje usluge iz popisa imovine nije dovoljno. DNS zapis, povezivanje u oblaku, SaaS zahtjev za prilagođenu domenu, certifikat, WAF pravilo, CDN konfiguracija i stavka praćenja također se moraju pregledati.

Korporativna verzija dodatno jača ovaj širi koncept imovine. Clarysecova Politika upravljanja imovinom Politika upravljanja imovinom, Opseg, točka 2.2.5 navodi:

Logička imovina: nazivi domena, licence, korisnički računi, polazne konfiguracije

Nazivi domena i konfiguracije nisu administrativne sitnice. To je imovina koja nosi povjerenje i može postati put napada.

Povezanost s upravljanjem promjenama jednako je važna. Clarysecova Politika upravljanja promjenama Politika upravljanja promjenama, Svrha, točka 1.1 navodi:

Ova politika uspostavlja formalni okvir za pokretanje, procjenu, odobravanje, implementaciju i pregled promjena u informacijskim sustavima, infrastrukturi, aplikacijama i povezanim procesima organizacije.

Uklanjanje DNS zapisa, prestanak SaaS usluge, brisanje aplikacije u oblaku, migracija CDN-a ili povlačenje marketinškog mikrosajta iz uporabe stoga treba generirati dokaze o promjeni. Izostanak zahtjeva za promjenu često je prvi revizijski signal upozorenja.

Upravljanje uslugama u oblaku također mora biti povezano. Clarysecova Politika korištenja usluga u oblaku Politika korištenja usluga u oblaku, Zahtjevi upravljanja, točka 5.5 navodi:

Tim za informacijsku sigurnost mora rutinski procjenjivati mrežni promet, DNS aktivnost i dnevničke zapise radi otkrivanja neovlaštene uporabe oblaka (shadow IT). Otkrivene povrede moraju se odmah istražiti.

Za sprječavanje preuzimanja poddomene praćenje DNS aktivnosti nije samo pitanje shadow IT-a. Riječ je i o zastarjeloj IT imovini, odnosno imovini koja je nekoć bila odobrena, ali više nije pod kontrolom.

Praktičan Clarysec radni tok za upravljanje rizikom dangling DNS-a

Snažan program za dangling DNS nije kompliciran. Mora biti discipliniran, ponovljiv i povezan s ISMS-om, upravljanjem ranjivostima, upravljanjem promjenama i životnim ciklusom dobavljača.

Za MSP-ove to može početi kao jednostavan registar. Za velike organizacije obično se integriraju izvozi DNS-a, upravljanje vanjskom površinom napada, popisi imovine u oblaku, CMDB zapisi, skeneri ranjivosti, SIEM upozorenja i sustavi za evidentiranje zahtjeva.

Pitanje upravljanja ostaje isto: možete li dokazati da je svaka izvana dostupna poddomena poznata, ima vlasnika, prati se i može se ukloniti kroz kontrolirani proces?

Napuštena kampanjska poddomena, obrađena na ispravan način

Vratimo se na ponedjeljni incident. promo.company.com upućuje na napušteni SaaS kampanjski web.

Prvo, voditelj sigurnosti otvara zapis ranjivosti jer je imovina izložena prema internetu. Clarysecova Politika upravljanja ranjivostima i zakrpama Politika upravljanja ranjivostima i zakrpama, Zahtjevi za provedbu politike, točka 6.1.1 navodi:

Svi sustavi moraju se skenirati najmanje mjesečno; imovina visokog rizika ili izložena prema van mora se skenirati tjedno.

Za MSP-ove ekvivalentna politika dodatno pooštrava prioritizaciju. Politika upravljanja ranjivostima i zakrpama-sme Politika upravljanja ranjivostima i zakrpama-sme - SME, Zahtjevi za provedbu politike, točka 6.5.1 navodi:

Sustavi koji obrađuju osobne podatke, omogućuju udaljeni pristup ili su izloženi prema van moraju imati prioritet za skeniranje i ažuriranja.

Drugo, vlasnik se identificira kroz registar imovine. Ako je vlasnik nepoznat, to postaje propust kontrole u odnosu na upravljanje imovinom. Registar se ažurira tako da uključuje DNS naziv, ciljnog pružatelja, izvornog poslovnog vlasnika, klasifikaciju podataka, dobavljača i status.

Treće, IT provjerava platformu u oblaku ili SaaS platformu. Ako je račun u oblaku izbrisan, Clarysecova Politika korištenja usluga u oblaku-sme Politika korištenja usluga u oblaku-sme - SME, Zahtjevi za provedbu politike, točka 6.3.6 izravno je relevantna:

Izbrisane račune u oblaku mora pregledati pružatelj IT usluga ili glavni direktor radi preostalog pristupa, napuštenih podataka ili previđenog sadržaja.

Četvrto, vlasnik promjene otvara hitan ili ubrzani zahtjev za promjenu radi uklanjanja DNS zapisa ili privremenog ponovnog preuzimanja resursa prije uklanjanja. Zahtjev uključuje procjenu utjecaja, plan povrata, odobrenja, dokaze o implementaciji i provjeru nakon promjene.

Peto, voditelj privatnosti procjenjuje je li poddomena obrađivala ili mogla izložiti osobne podatke. Clarysecova PII Security and Access Control Policy PII Security and Access Control Policy, Sigurna konfiguracija i upravljanje ranjivostima, točka 4.7.4 navodi:

[Oboje] Vlasnik sustava / vlasnik aplikacije MORA evidentirati obuhvat procjene ranjivosti za sustave koji obrađuju PII u REG12 najmanje tromjesečno i nakon značajne tehničke promjene.

Točka 4.7.5 dodaje:

[Oboje] Voditelj informacijske sigurnosti MORA evidentirati neriješene ranjivosti visokog rizika koje utječu na PII u REG12 u roku od pet radnih dana od potvrde.

Te se točke primjenjuju bez obzira djeluje li organizacija kao voditelj obrade ili izvršitelj obrade jer su označene s [Oboje]. Za dangling DNS pitanje koje uključuje PII dokazi ne smiju ostati samo u tehničkoj prijavi. Moraju se odraziti u registru dokaza o ranjivostima povezanima s PII.

Šesto, ako je kampanju hostirala agencija ili SaaS pružatelj, nabava provjerava zapise trećih strana. Clarysecova Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Identifikacija i klasifikacija odnosa, točka 4.1.2 navodi:

[Svi] Vlasnik procesa / vlasnik poslovanja MORA identificirati svaki predloženi odnos s trećom stranom koja će obrađivati, pristupati, primati, pohranjivati, prenositi, podržavati ili na drugi način utjecati na PII u REG08 prije nabave, uvođenja, obnove ili značajne promjene privatnosti treće strane.

Točka 4.5.5 zahtijeva:

[Oboje] Vlasnik dobavljača / nabave MORA evidentirati lokacije obrade, lokacije hostinga i pokazatelje međunarodnog prijenosa u REG08 te povezati primjenjive dokaze o prijenosu s REG09 prije odobrenja izvršitelja obrade, podizvršitelja obrade, promjene lokacije ili promjene usluge relevantne za prijenos.

Na kraju, voditelj usklađenosti priprema paket dokaza. Clarysecova Politika praćenja revizije i usklađenosti Politika praćenja revizije i usklađenosti, Ciljevi, točka 3.4 navodi da je jedan cilj:

Generirati dokazive dokaze i revizijski trag za potrebe upita regulatornih tijela, sudskih postupaka ili zahtjeva klijenata za pružanje potvrda.

To je ishod koji CISO treba kada klijent, regulator ili revizor pita: „Kako znate da se ovo neće ponoviti?”

Gdje se uklapa Zenith Blueprint

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pretvara kontrole u operativne prakse spremne za reviziju. Dangling DNS snažno se mapira na četiri područja.

U fazi „Kontrole u praksi”, korak 22 obuhvaća organizacijske kontrole 5.1 do 5.18, uključujući kontrolu 5.9 iz ISO/IEC 27002:2022. Zenith Blueprint navodi:

Nijedna organizacija ne može zaštititi ono za što ne zna da ima. Kontrola 5.9 formalizira ovo temeljno načelo i zahtijeva uspostavu i održavanje ažurnog popisa svih informacija i povezane imovine relevantne za ISMS.

Nastavlja:

U svojem najstrateškijem obliku, popis imovine služi kao središnji živčani sustav vašeg ISMS-a.

Vaš popis poddomena nije sporedni popis. On utječe na odluke o pristupu, skeniranje ranjivosti, zapisivanje događaja, upravljanje dobavljačima, mapiranje privatnosti i odgovor na incidente.

U koraku 20, Zenith Blueprint obuhvaća tehnološke kontrole 8.18 do 8.26. Za kontrolu 8.21, Sigurnost mrežnih usluga, upućuje organizacije da provjere sigurnost mrežnih usluga:

Popišite sve interne i vanjske mrežne usluge (DNS, VPN, SMTP, DHCP, API pristupnici itd.).

Zato DNS pružatelji, registri domena, cloud DNS, CDN platforme i SaaS funkcionalnosti prilagođenih domena pripadaju u registar usluga.

U koraku 19, Zenith Blueprint obuhvaća tehnološke kontrole 8.1 do 8.17. Za kontrolu 8.8 navodi:

Upravljanje ranjivostima jedno je od najkritičnijih područja moderne kibernetičke higijene. Iako vatrozidi i antivirusni alati pružaju zaštitu, ona se može narušiti ako nezakrpani sustavi ili pogrešno konfigurirane usluge ostanu izloženi.

Dangling DNS zapis pogrešno je konfiguriran put prema vanjskoj usluzi. Čak i kada ne postoji CVE, treba ga obraditi kroz upravljanje ranjivostima: provjeriti, ocijeniti, dodijeliti, otkloniti, ponovno testirati i zatvoriti.

U koraku 23, Zenith Blueprint obrađuje organizacijske kontrole 5.19 do 5.37. Za kontrolu 5.23 savjetuje:

Popišite sve usluge u oblaku koje su trenutačno u uporabi (5.23), uključujući shadow IT gdje je poznat. Utvrdite tko ih je odobrio i je li provedena dubinska analiza dobavljača. Izradite jednostavan kontrolni popis za procjenu koji obuhvaća lokaciju podataka, model pristupa, zapisivanje događaja i šifriranje.

Za sprječavanje preuzimanja poddomene tom kontrolnom popisu za procjenu usluga u oblaku dodajte prilagođene domene, DNS ovisnosti, vlasnika povlačenja iz uporabe i dokaze o izlaznom postupku.

Mapiranje na NIS2, DORA i GDPR

NIS2 za mnoge ključne i važne subjekte čini upravljanje rizikom dangling DNS-a pitanjem na razini upravljačkog tijela. Article 20 zahtijeva da upravljačka tijela odobravaju mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i pohađaju osposobljavanje iz kibernetičke sigurnosti. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere koristeći pristup koji uključuje sve opasnosti. Njegova minimalna područja uključuju analizu rizika, postupanje s incidentima, kontinuitet poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, razvoj i održavanje, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, osposobljavanje, kontrolu pristupa i upravljanje imovinom.

Program za dangling DNS jasno se mapira na ta područja. Article 21(3) također zahtijeva da sigurnost opskrbnog lanca uzme u obzir ranjivosti specifične za svakog izravnog dobavljača ili pružatelja usluga. Ako marketinška agencija, SaaS dobavljač, pružatelj upravljanog hostinga ili platforma u oblaku upravlja prilagođenim domenama, kontrole specifične za dobavljača trebaju obuhvatiti vlasništvo nad DNS-om, izlazak iz usluge, podršku incidentima i primopredaju dokaza.

Article 23 važan je ako do preuzimanja dođe ili ako ono može uzrokovati ozbiljan operativni poremećaj, financijski gubitak ili znatnu materijalnu ili nematerijalnu štetu. NIS2 koristi fazno izvješćivanje: rano upozorenje u roku od 24 sata od saznanja za značajan incident, obavijest u roku od 72 sata, međuutvrđivanja na zahtjev i završno izvješće u roku od mjesec dana od prijave incidenta.

Za financijske subjekte DORA je sektorski režim digitalne operativne otpornosti. Articles 5 i 6 zahtijevaju interni okvir upravljanja i kontrola za upravljanje IKT rizicima, uz krajnju odgovornost upravljačkog tijela, jasne IKT uloge, politike za dostupnost, autentičnost, cjelovitost i povjerljivost podataka, planove revizije, resurse, politiku za usluge trećih strana i dokumentirani okvir upravljanja IKT rizicima.

Articles 8 do 14 čine operativnu jezgru. Article 8 zahtijeva identifikaciju, klasifikaciju i dokumentiranje poslovnih funkcija podržanih IKT-om, informacijskih resursa, IKT imovine, ovisnosti, međupovezivanja s IKT trećim stranama, popisa imovine, scenarija rizika i naslijeđenih sustava. Dangling CNAME često je propuštena ovisnost. Article 9 zahtijeva zaštitu i prevenciju. Article 10 zahtijeva otkrivanje anomalnih aktivnosti, IKT incidenata i mogućih pojedinačnih točaka otkaza. Articles 11 i 12 obrađuju kontinuitet, oporavak, sigurnosno kopiranje i vraćanje podataka. Article 13 zahtijeva učenje iz ranjivosti, prijetnji, incidenata i testova.

Articles 17 do 19 formaliziraju upravljanje incidentima, klasifikaciju i izvješćivanje. Articles 28 do 30 uređuju IKT rizik trećih strana kroz životni ciklus. Financijski subjekti ostaju u potpunosti odgovorni kada koriste pružatelje IKT usluga. Za spremnost za DORA-u Clarysec preporučuje dodavanje četiriju polja u svaki DNS i registar usluga u oblaku: podrška kritičnoj ili važnoj funkciji, IKT pružatelj treće strane, referenca na ugovor ili registar i status testa izlaznog postupka.

GDPR se primjenjuje kada pitanje uključuje osobne podatke. Preuzimanje poddomene nije automatski povreda osobnih podataka, ali to može postati ako zahvaćena poddomena prikuplja vjerodajnice, hvata podatke iz obrazaca, lažno se predstavlja kao usluga, izlaže korisničke identifikatore ili omogućuje neovlašteni pristup osobnim podacima. GDPR Article 5 zahtijeva cjelovitost, povjerljivost i odgovornost. Article 32 zahtijeva odgovarajuću sigurnost obrade. Article 33 može zahtijevati obavješćivanje nadzornog tijela ako je vjerojatno da će povreda osobnih podataka dovesti do rizika za prava i slobode fizičkih osoba.

Clarysecova PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Klasifikacija i procjena povrede, točka 4.2.6 podržava ovu analizu okidača kroz više režima:

[Uvjetno] Voditelj privatnosti / PIMS Manager MORA procijeniti primjenjive pravne, sektorske, financijske, kibernetičke, ugovorne, klijentske i okidače izvješćivanja primatelja usluge za svaki incident visokog utjecaja u vezi s osobnim podacima te evidentirati ishod primjenjivosti u REG01, REG08 i REG10.

Taj zapis o odluci upravo je ono što je potrebno kada preuzimanje poddomene može uključivati GDPR, NIS2, DORA, ugovore i obavješćivanje klijenata.

Kako će revizori testirati vaše dokaze

Integrirani ISMS treba omogućiti odgovaranje različitim revizorima na temelju iste baze dokaza. Formulacija pitanja se mijenja, ali dokaz je često isti.

Šira perspektiva osiguranja usklađenosti često uključuje NIST CSF 2.0 i COBIT 2019. NIST CSF 2.0 pomaže izraziti ciljno stanje kroz ishode GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. Trenutačni profil može pokazati ručne tromjesečne preglede DNS-a i nedosljedan izlazni postupak za SaaS. Ciljni profil može zahtijevati automatizirane tjedne provjere preuzimanja, obveznu dodjelu vlasnika, dokaze o izlaznom postupku dobavljača i integraciju s upravljanjem promjenama.

Revizor usmjeren na COBIT 2019 ili ISACA obično će pitati tko je vlasnik procesa, kako se rizik vrednuje i usmjerava, jesu li promjene kontrolirane, upravlja li se dobavljačima, jesu li konfiguracija i imovina pouzdane te podržavaju li dokazi o osiguranju izvješćivanje uprave. Možda neće prvo tražiti popis CNAME zapisa. Možda će pitati kako uprava zna da su vanjske digitalne usluge kontrolirane tijekom cijelog životnog ciklusa.

Kako izgledaju dobri revizijski dokazi

Revizijski paket za dangling DNS treba biti dovoljno malen za održavanje, ali dovoljno potpun za obranu. Clarysec obično preporučuje sljedeći skup dokaza:

• Popis DNS zona s izvorom, datumom, vrstom zapisa, ciljem i vlasnikom.
• Rezultati skeniranja vanjske površine napada koji prikazuju provjere preuzimanja.
• Unosi u registar imovine za domene, poddomene, usluge u oblaku, SaaS aplikacije i CDN-ove.
• Registar usluga koji prikazuje internu odgovornost ili odgovornost dobavljača.
• Zahtjevi za promjenu za kreiranje, izmjenu i brisanje DNS zapisa.
• Kontrolni popisi za uvođenje oblaka i SaaS-a, uključujući pregled prilagođene domene i DNS-a.
• Ugovori s dobavljačima ili sigurnosne odredbe koje obuhvaćaju DNS, hosting, podršku incidentima i izlazni postupak.
• Prijave ranjivosti s ozbiljnošću, vlasnikom, datumom otklanjanja i dokazima o ponovnom testiranju.
• Procjena PII kada poddomena obrađuje ili je prethodno obrađivala osobne podatke.
• Zapisi o klasifikaciji incidenata za sumnjivo ili potvrđeno preuzimanje.
• Naučene lekcije i ažurirani postupci nakon nalaza.

Važne su i metrike. Uprava treba vidjeti broj vanjskih poddomena, postotak s dodijeljenim vlasnicima, broj dangling nalaza, prosječno vrijeme do otklanjanja, zakašnjele nalaze visokog rizika, poddomene koje hostiraju dobavljači bez trenutačne ugovorne reference i postotak izlazaka iz oblaka s dokazima o uklanjanju DNS zapisa.

Te metrike pretvaraju tehničku higijenu u dokaze nadzora uprave.

Uobičajeni obrasci propusta koje Clarysec pronalazi

Kod klijenata iz područja SaaS-a, fintecha, zdravstvene tehnologije, upravljanih usluga i e-trgovine ponavljaju se isti obrasci.

Prvo, vlasništvo nad DNS-om podijeljeno je između timova. Razvojni timovi posjeduju oblak. Marketing posjeduje kampanje. IT posjeduje pristup DNS pružatelju. Nabava posjeduje prestanak SaaS usluge. Nitko ne posjeduje puni životni ciklus.

Drugo, brisanje resursa u oblaku tretira se kao kraj usluge. U stvarnosti, DNS, certifikati, WAF pravila, praćenje, tajne vrijednosti, dokumentacija i zapisi dobavljača mogu ostati.

Treće, skeneri ranjivosti usredotočuju se na aktivne hostove, ali propuštaju uvjete preuzimanja specifične za pružatelje. Organizacije trebaju provjere vanjske površine napada koje razumiju uobičajena stanja pogrešaka u SaaS-u i oblaku.

Četvrto, izlazni postupci dobavljača usredotočuju se na fakture i povrat podataka, ali ne na prilagođene domene, DNS zapise i promjene podizvršitelja obrade.

Peto, timovi za privatnost obavještavaju se prekasno. Ako je poddomena obrađivala PII, DPO ili voditelj privatnosti treba sudjelovati u klasifikaciji prije donošenja pretpostavki.

Šesto, dokazi postoje, ali su raspršeni. Izvoz DNS-a nalazi se u jednom alatu, zahtjevi za promjenu u drugom, ugovori s dobavljačima u nabavi, izvješća o ranjivostima u skenerima, a analiza privatnosti u e-pošti. Revizori fragmentaciju vide kao slabost.

Clarysecov alatni paket to rješava povezivanjem politika, registara, kontrola i radnih tokova dokaza.

Tridesetodnevni plan aktivnosti za upravljanje DNS-om

Ako ste pronašli jedan dangling DNS zapis, pretpostavite da ih ima još. Ako niste pronašli nijedan, osigurajte da možete dokazati zašto.

Započnite ovim tridesetodnevnim planom:

1. Izvezite sve mjerodavne DNS zone.
2. Identificirajte CNAME, ALIAS, A i AAAA zapise koji upućuju na usluge u oblaku, SaaS, CDN i usluge kojima upravljaju agencije.
3. Dodijelite vlasnike i poslovne svrhe.
4. Provedite provjere preuzimanja i ručno provjerite sumnjive zapise.
5. Otvorite prijave ranjivosti za potvrđene rizike.
6. Uklonite ili ponovno preuzmite izložene zapise kroz upravljanje promjenama.
7. Ažurirajte registar imovine, registar oblaka i registar dobavljača.
8. Pregledajte je li neka zahvaćena poddomena obrađivala PII.
9. Dodajte provjere životnog ciklusa DNS-a u uvođenje usluga u oblaku, nabavu SaaS-a i izlazni postupak dobavljača.
10. Izvijestite upravu o metrikama.

Tehničko rješenje za dangling DNS često je jednostavno. Rješenje upravljanja sprječava sljedeće preuzimanje.

Clarysec vam može pomoći to provesti koristeći Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls i naš alatni paket politika za upravljanje imovinom, korištenje usluga u oblaku, upravljanje ranjivostima, upravljanje dobavljačima, sigurnost PII, odgovor na incidente i revizijske dokaze.

Ako želite pristup spreman za reviziju, Clarysec vam može pomoći izraditi paket dokaza o DNS-u i izloženosti u oblaku, mapirati ga na ISO/IEC 27001:2022, NIS2, DORA i GDPR te pretvoriti zaboravljene poddomene u kontroliranu imovinu s vlasnikom i praćenjem. Preuzmite relevantni Clarysec alatni paket, zatražite demo ili zakažite procjenu upravljanja DNS-om prije nego što penetracijski tester, revizor ili napadač pronađe sljedeći zaboravljeni pokazivač.