Upravljanje opuščenih DNS-zapisov za NIS2, DORA in GDPR

Vodja informacijske varnosti prejme sporočilo v ponedeljek ob 07:12.

Varnostni raziskovalec je odkril, da promo.company.com kaže na opuščeno aplikacijo v oblaku. DNS-zapis je še vedno aktiven. Vir v oblaku ne obstaja več. Najemnik SaaS, ki je nekoč podpiral kampanjo, je bil izbrisan pred šestimi meseci, kmalu po tem, ko je trženje prešlo na drugo platformo. CNAME ni odstranil nihče.

Ob 08:30 vprašanje ni več: »Ali lahko kdo prevzame poddomeno?« Vprašanje je: »Zakaj nihče ni vedel, da to sredstvo obstaja?«

Ob 09:15 je vključena pravna služba, ker je poddomena nekoč zbirala e-poštne naslove za čakalni seznam izdelka. Vključena je nabava, ker je platformo za kampanjo upravljala agencija. Vključena je skladnost, ker se podjetje pripravlja na nadzorno presojo ISO/IEC 27001:2022, pripravljenost na NIS2 in vprašalnike naročnikov za zagotavljanje zaupanja. Pooblaščena oseba za varstvo podatkov (DPO) vpraša, ali bi izpostavljenost lahko pomenila kršitev varnosti osebnih podatkov po GDPR, če bi bila poddomena zlorabljena. Finančni direktor vpraša, ali bi lahko ista slabost vplivala na plačilni portal v reguliranem okolju finančnih storitev znotraj skupine.

Tehnična odprava lahko traja nekaj minut. Težava upravljanja pa se lahko razrešuje več mesecev, če organizacija ne more dokazati, da je vsako sredstvo, izpostavljeno internetu, znano, ima lastnika, je pregledano, spremljano in izločeno iz uporabe po nadzorovanem postopku.

Zato opuščenih DNS-zapisov in preprečevanja prevzema poddomen ni mogoče obravnavati kot ozko nalogo čiščenja DNS. Zastarel DNS-zapis je pogosto vidni simptom globljih odpovedi kontrol: nepopolne evidence sredstev, nejasnega lastništva, manjkajočih dokazil o izločitvi iz uporabe, šibkega nadzora sprememb, neustreznega upravljanja izstopa dobaviteljev, nezadostnega spremljanja zunanje napadalne površine in nejasnega razvrščanja incidentov.

Za stranke Clarysec so opuščeni DNS-zapisi preizkus sistema upravljanja. Pokažejo, ali politike, kontrole, registri, dokazila in odgovornost dejansko delujejo, ko pozabljena odvisnost v oblaku postane priložnost za napadalca.

Kaj opuščeni DNS-zapisi dejansko pomenijo

Prevzem poddomene postane mogoč, kadar DNS-zapis, pogosto CNAME, kaže na vir, ki ne obstaja več ali ga organizacija ne obvladuje več. Če lahko napadalec na platformi v oblaku ali SaaS prevzame ali ponovno ustvari ciljni vir, lahko pod zaupanja vredno poddomeno organizacije streže vsebino.

Pogosti primeri vključujejo:

• CNAME, ki kaže na nezahtevano aplikacijsko storitev v oblaku.
• Prilagojeno gostiteljsko ime SaaS, ki po preklicu naročnine ostane v DNS.
• Distribucijo CDN, odstranjeno iz konzole ponudnika, vendar še vedno navedeno v javnem DNS.
• Marketinško mikrospletno mesto, ki ga je agencija izločila iz uporabe brez odstranitve DNS-zapisa.
• Končno točko shrambe ali preslikavo statičnega spletnega mesta, ki jo je mogoče ponovno registrirati.
• Razvojno poddomeno, izpostavljeno prek pozabljenega projekta platforme kot storitve.

Poslovni vpliv je lahko resen. Napadalci lahko gostijo strani za lažno predstavljanje, zajemajo poverilnice, distribuirajo zlonamerno programsko opremo, zlorabijo ugled domene, prestrezajo podatke sej ali škodujejo zaupanju v blagovno znamko. Kadar je poddomena prej obdelovala osebne podatke, lahko tudi kratkotrajen prevzem sproži analizo kršitve po GDPR. Kadar prizadeta storitev podpira regulirane finančne operacije, bo morda treba incident oceniti tudi po DORA ali notranjih okvirih upravljanja IKT-tveganj.

Presojevalci opuščene DNS-zapise vse pogosteje obravnavajo kot dokaz zrelosti kontrol. En sam zastarel zapis lahko kaže, da organizacija ne ve, kaj ima v lasti, kdo je lastnik, kako se spremembe pregledujejo, kako se zaključuje uporaba storitev v oblaku ali kako se spremljajo sredstva, izpostavljena internetu.

Zato Clarysec to vprašanje preslika na pričakovanja presoje po ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

Zakaj je ISO 27001:2022 praktično izhodišče

Najmočnejši način za upravljanje opuščenih DNS-zapisov ni vzpostavljanje ločenih programov za NIS2, DORA in GDPR. ISO/IEC 27001:2022 je treba uporabiti kot hrbtenico sistema upravljanja in dokazila enkrat vzpostaviti za več potreb zagotavljanja zaupanja.

Ustrezne zahteve se začnejo že pred Prilogo A. Točke 4.1 do 4.4 zahtevajo, da organizacija razume svoj kontekst, zahteve zainteresiranih strani, obseg ISMS in odvisnosti od drugih organizacij. Pri upravljanju opuščenih DNS-zapisov mora obseg vključevati zunanji DNS, domene, registrarje, storitve v oblaku, platforme SaaS, agencije, upravljano gostovanje, CDN in vsako tretjo osebo, ki lahko ustvari ali ukine storitve, izpostavljene internetu.

Točke 5.1 do 5.3 to vprašanje postavijo na raven vodstva in odgovornosti. Vodstvo mora ISMS uskladiti s poslovno usmeritvijo, zagotoviti vire, komunicirati pomen informacijske varnosti in dodeliti odgovornosti. Če lahko trženje zažene mikrospletno mesto, inženiring ustvari končne točke v oblaku, nabava pa prekine pogodbe SaaS, organizacija potrebuje model upravljanja, ki vsem jasno dodeli lastništvo DNS in storitev.

Točke 6.1.1 do 6.1.3 določajo logiko ocene tveganja, obravnave tveganja in Izjave o uporabnosti. Opuščene DNS-zapise je treba evidentirati kot realističen scenarij tveganja, ne zgolj kot izpis skenerja. Vplivajo na zaupnost, celovitost in razpoložljivost ter se pogosto preslikajo na zakonske, regulativne in pogodbene obveznosti.

Točke 7.5, 8.1, 8.2 in 8.3 upravljanje pretvorijo v dokazila. Zahtevajo nadzorovane dokumentirane informacije, načrtovane in nadzorovane operativne procese, upoštevanje nenamernih sprememb, nadzor nad zunanje zagotovljenimi procesi, periodične ocene tveganj in dokumentirane rezultate obravnave tveganj.

Priloga A nato zagotovi katalog kontrol. V projektih Clarysec so ključna razmerja po ISO/IEC 27002:2022 običajno naslednja:

Bistvo je preprosto. ISO/IEC 27001:2022 ne zahteva junaškega enkratnega čiščenja. Zahteva nadzorovan operativni model, ki preprečuje ponovitev.

Pogled Zenith Controls: eno tveganje, tri sidrne kontrole

V Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec uporablja ustrezne kontrole ISO/IEC 27002:2022 kot sidra za preslikavo med okviri skladnosti. Pri upravljanju opuščenih DNS-zapisov in preprečevanju prevzema poddomen so osrednje tri kontrole.

Kontrola 5.9, Popis informacij in drugih povezanih sredstev, je razvrščena kot preventivna, podpira zaupnost, celovitost in razpoložljivost, se ujema s konceptom kibernetske varnosti Identify ter spada pod upravljanje sredstev kot operativno zmožnost, pri čemer so varnostna področja upravljanje, ekosistem in zaščita.

Kontrola 5.23, Informacijska varnost pri uporabi storitev v oblaku, je razvrščena kot preventivna, podpira zaupnost, celovitost in razpoložljivost, se ujema s Protect ter spada pod varnost odnosov z dobavitelji kot operativno zmožnost, pri čemer so varnostna področja upravljanje, ekosistem in zaščita.

Kontrola 8.8, Upravljanje tehničnih ranljivosti, je razvrščena kot preventivna, podpira zaupnost, celovitost in razpoložljivost, se ujema z Identify in Protect ter spada pod upravljanje groženj in ranljivosti kot operativno zmožnost, pri čemer so varnostna področja upravljanje, ekosistem, zaščita in obramba.

To je pomembno, ker opuščeni DNS-zapisi niso le odpoved kontrole sredstev, niso le odpoved kontrole oblaka in niso le ranljivost. So vse troje. Organizacija mora dokazati, da se evidenca sredstev, upravljanje uporabe storitev v oblaku in upravljanje ranljivosti medsebojno krepijo.

Clarysec tem sidrom pogosto doda podporne prakse: ISO/IEC 27005 za disciplino ocenjevanja in obravnave tveganj, ISO/IEC 27017 za upravljanje varnosti storitev v oblaku, ISO/IEC 27018, kadar storitve v oblaku obdelujejo PII, ISO/IEC 27701 za sistem upravljanja informacij o zasebnosti in ISO 22301, kadar sta pomembna neprekinjeno poslovanje in krizni odziv.

Dokazila iz politik, ki že zahtevajo nadzor življenjskega cikla DNS

Številne organizacije že imajo politike, ki bi ob pravilni izvedbi preprečile opuščene DNS-zapise. Vrzel je v tem, da nadzor življenjskega cikla DNS ni izrecno povezan s temi politikami.

Clarysecova Politika upravljanja sredstev-sme Politika upravljanja sredstev-sme - SME, Zahteve za implementacijo politike, točka 6.6.1 določa:

Sredstva v oblaku (npr. računi za shranjevanje, platforme SaaS, spletne domene) morajo biti prav tako vključena v evidenco.

Ista politika v točki 6.6.2 dodaja:

Lastništvo, namen, pravice dostopa in roki podaljšanja morajo biti dokumentirani.

Za upravljanje opuščenih DNS-zapisov to pomeni, da mora imeti vsaka produkcijska poddomena in vsaka pomembna neprodukcijska poddomena imenovanega lastnika, poslovni namen, povezano storitev, model dostopa in datum pregleda.

Najpomembneje je, da točka 6.6.3 določa:

Potekle ali neuporabljene storitve morajo biti deaktivirane in odstranjene iz evidence.

Pri DNS je treba to razlagati previdno. Odstranitev storitve iz evidence ni dovolj. Pregledati je treba tudi DNS-zapis, vezavo v oblaku, zahtevek prilagojene domene SaaS, digitalno potrdilo, pravilo WAF, konfiguracijo CDN in vnos za spremljanje.

Podjetniška različica ta širši koncept sredstev dodatno utrjuje. Clarysecova Politika upravljanja sredstev Politika upravljanja sredstev, Področje uporabe, točka 2.2.5 določa:

Logična sredstva: domenska imena, licence, uporabniški računi, izhodiščne konfiguracije

Domenska imena in konfiguracije niso administrativne podrobnosti. So sredstva, ki nosijo zaupanje in lahko postanejo poti napada.

Enako pomembna je povezava z nadzorom sprememb. Clarysecova Politika upravljanja sprememb Politika upravljanja sprememb, Namen, točka 1.1 določa:

Ta politika vzpostavlja formalni okvir za uvedbo, ocenjevanje, odobritev, izvajanje in pregled sprememb informacijskih sistemov, infrastrukture, aplikacij in povezanih procesov organizacije.

Odstranitev DNS-zapisa, prenehanje uporabe SaaS, izbris aplikacije v oblaku, migracija CDN ali izločitev marketinškega mikrospletnega mesta iz uporabe morajo zato ustvariti dokazila o spremembi. Odsotnost zahtevka za spremembo je pogosto prvi revizijski opozorilni znak.

Povezati je treba tudi upravljanje storitev v oblaku. Clarysecova Politika uporabe storitev v oblaku Politika uporabe storitev v oblaku, Zahteve upravljanja, točka 5.5 določa:

Ekipa za informacijsko varnost mora redno ocenjevati omrežni promet, dejavnost DNS in dnevnike za zaznavanje nepooblaščene uporabe storitev v oblaku (shadow IT). Zaznane kršitve je treba nemudoma preiskati.

Pri preprečevanju prevzema poddomen spremljanje dejavnosti DNS ni pomembno le zaradi nepooblaščene IT (shadow IT). Pomembno je tudi zaradi zastarele IT, torej sredstev, ki so bila nekoč odobrena, vendar niso več pod nadzorom.

Praktičen delovni tok Clarysec za upravljanje opuščenih DNS-zapisov

Močan program za opuščene DNS-zapise ni zapleten. Je discipliniran, ponovljiv in povezan z ISMS, upravljanjem ranljivosti, upravljanjem sprememb in življenjskim ciklom dobaviteljev.

Za SME se to lahko začne kot enostaven register. V podjetjih se običajno povezujejo izvozi DNS, upravljanje zunanje napadalne površine, popisi sredstev v oblaku, zapisi CMDB, skenerji ranljivosti, opozorila SIEM in sistemi za upravljanje zahtevkov.

Vprašanje upravljanja ostaja enako: ali lahko dokažete, da je vsaka zunanje dosegljiva poddomena znana, ima lastnika, je spremljana in jo je mogoče odstraniti po nadzorovanem postopku?

Opuščena poddomena kampanje, obravnavana pravilno

Vrnimo se k ponedeljkovemu incidentu. promo.company.com kaže na opuščeno kampanjsko mesto SaaS.

Najprej vodja varnosti ustvari zapis o ranljivosti, ker je sredstvo izpostavljeno internetu. Clarysecova Politika upravljanja ranljivosti in popravkov Politika upravljanja ranljivosti in popravkov, Zahteve za implementacijo politike, točka 6.1.1 določa:

Vsi sistemi morajo biti skenirani vsaj mesečno; sredstva z visokim tveganjem ali sredstva, izpostavljena internetu, morajo biti skenirana tedensko.

Pri SME enakovredna politika dodatno izostri prioritizacijo. Politika upravljanja ranljivosti in popravkov-sme Politika upravljanja ranljivosti in popravkov-sme - SME, Zahteve za implementacijo politike, točka 6.5.1 določa:

Sistemi, ki obdelujejo osebne podatke, zagotavljajo oddaljeni dostop ali so izpostavljeni internetu, morajo imeti prednost pri skeniranju in posodobitvah

Drugič, lastnik se identificira prek registra sredstev. Če lastnik ni znan, je to odpoved kontrole upravljanja sredstev. Register se posodobi tako, da vključuje ime DNS, ciljnega ponudnika, prvotnega poslovnega lastnika, razvrstitev podatkov, dobavitelja in status.

Tretjič, IT preveri platformo v oblaku ali SaaS. Če je bil račun v oblaku izbrisan, je neposredno relevantna Clarysecova Politika uporabe storitev v oblaku-sme Politika uporabe storitev v oblaku-sme - SME, Zahteve za implementacijo politike, točka 6.3.6:

Izbrisane račune v oblaku mora ponudnik IT ali generalni direktor pregledati glede preostalega dostopa, osirotelih podatkov ali spregledane vsebine.

Četrtič, lastnik spremembe odpre zahtevek za nujno ali pospešeno spremembo za odstranitev DNS-zapisa ali začasno ponovno zahtevanje vira pred odstranitvijo. Zahtevek vključuje oceno vpliva, načrt povrnitve, odobritve, dokazila o izvedbi in validacijo po spremembi.

Petič, vodja za zasebnost oceni, ali je poddomena obdelovala ali bi lahko izpostavila osebne podatke. Clarysecova Politika varnosti PII in nadzora dostopa Politika varnosti PII in nadzora dostopa, Varna konfiguracija in upravljanje ranljivosti, točka 4.7.4 določa:

[Oboje] Lastnik sistema / lastnik aplikacije MORA najmanj četrtletno in po bistveni tehnični spremembi evidentirati pokritost ocenjevanja ranljivosti za sisteme, ki obdelujejo PII, v REG12.

Točka 4.7.5 dodaja:

[Oboje] Vodja informacijske varnosti MORA v petih delovnih dneh po validaciji v REG12 evidentirati nerešene ranljivosti z visokim tveganjem, ki vplivajo na PII.

Ti točki se uporabljata ne glede na to, ali organizacija deluje kot upravljavec ali obdelovalec, ker sta označeni z [Oboje]. Pri težavi z opuščenimi DNS-zapisi, ki vključuje PII, dokazila ne smejo ostati samo v tehničnem zahtevku. Odražati se morajo v registru dokazil o ranljivostih PII.

Šestič, če je kampanjo gostila agencija ali ponudnik SaaS, nabava preveri evidence tretjih oseb. Clarysecova Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti, Identifikacija in razvrstitev razmerij, točka 4.1.2 določa:

[Vsi] Lastnik procesa / poslovni lastnik MORA pred nabavo, uvajanjem, podaljšanjem ali bistveno spremembo obdelave pri tretji osebi v REG08 identificirati vsako predlagano razmerje s tretjo osebo, ki bo obdelovala, dostopala do, prejela, hranila, prenašala, podpirala ali drugače vplivala na PII.

Točka 4.5.5 zahteva:

[Oboje] Lastnik dobavitelja / nabave MORA pred odobritvijo obdelovalca, podobdelovalca, spremembe lokacije ali spremembe storitve, relevantne za prenos, v REG08 evidentirati lokacije obdelave, lokacije gostovanja in kazalnike mednarodnega prenosa ter povezati ustrezna dokazila o prenosu z REG09.

Na koncu vodja skladnosti pripravi paket dokazil. Clarysecova Politika spremljanja presoje in skladnosti Politika spremljanja presoje in skladnosti, Cilji, točka 3.4 določa, da je eden od ciljev:

Ustvarjati zagovorljiva dokazila in revizijsko sled v podporo regulativnim poizvedbam, pravnim postopkom ali zahtevam naročnikov za zagotavljanje zaupanja.

To je rezultat, ki ga potrebuje vodja informacijske varnosti, ko stranka, regulator ali presojevalec vpraša: »Kako veste, da se to ne bo ponovilo?«

Kam sodi Zenith Blueprint

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pretvarja kontrole v operativne prakse, pripravljene za presojo. Opuščeni DNS-zapisi se močno preslikajo na štiri področja.

V fazi Controls in Action korak 22 obravnava organizacijske ukrepe 5.1 do 5.18, vključno s kontrolo 5.9 po ISO/IEC 27002:2022. Zenith Blueprint navaja:

Nobena organizacija ne more varovati tega, za kar ne ve, da ima. Kontrola 5.9 formalizira to temeljno načelo in zahteva vzpostavitev ter vzdrževanje ažurnega popisa vseh informacij in povezanih sredstev, pomembnih za ISMS.

Nadaljuje:

V svoji najbolj strateški obliki evidenca sredstev deluje kot osrednji živčni sistem vašega ISMS.

Evidenca poddomen ni stranski seznam. Napaja odločitve o dostopu, skeniranje ranljivosti, beleženje, upravljanje dobaviteljev, preslikavo zasebnosti in odziv na incidente.

V koraku 20 Zenith Blueprint obravnava tehnološke nadzorne ukrepe 8.18 do 8.26. Pri kontroli 8.21, Varnost omrežnih storitev, organizacijam naroča, naj preverijo varnost omrežnih storitev:

Navedite vse notranje in zunanje omrežne storitve (DNS, VPN, SMTP, DHCP, prehodi API itd.).

Zato morajo ponudniki DNS, registrarji, DNS v oblaku, platforme CDN in funkcionalnosti domen po meri v SaaS soditi v register storitev.

V koraku 19 Zenith Blueprint obravnava tehnološke nadzorne ukrepe 8.1 do 8.17. Pri kontroli 8.8 navaja:

Upravljanje ranljivosti je eno najkritičnejših področij sodobne kibernetske higiene. Čeprav požarni zidovi in antivirusna programska oprema zagotavljajo zaščito, jih lahko izničijo nepopravljeni sistemi ali napačno konfigurirane storitve, ki ostanejo izpostavljene.

Opuščen DNS-zapis je napačno konfigurirana zunanja pot do storitve. Tudi kadar ni CVE, ga je treba obravnavati prek upravljanja ranljivosti: validirati, oceniti, dodeliti, odpraviti, ponovno testirati in zapreti.

V koraku 23 Zenith Blueprint obravnava organizacijske ukrepe 5.19 do 5.37. Pri kontroli 5.23 svetuje:

Navedite vse storitve v oblaku, ki so trenutno v uporabi (5.23), vključno s shadow IT, kjer je znan. Ugotovite, kdo jih je odobril in ali je bil opravljen skrbni pregled. Pripravite enostaven kontrolni seznam za ocenjevanje, ki zajema lokacijo podatkov, model dostopa, beleženje in šifriranje.

Za preprečevanje prevzema poddomen v ta kontrolni seznam za ocenjevanje storitev v oblaku dodajte domene po meri, odvisnosti DNS, lastnika izločitve iz uporabe in dokazila o izstopu.

Preslikava na NIS2, DORA in GDPR

NIS2 pri številnih bistvenih in pomembnih subjektih postavlja upravljanje opuščenih DNS-zapisov na raven upravljalnega organa. Article 20 zahteva, da upravljalni organi odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo izvajanje in se udeležujejo usposabljanja na področju kibernetske varnosti. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe ob uporabi pristopa, ki upošteva vsa tveganja. Minimalna področja vključujejo analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno pridobivanje, razvoj in vzdrževanje, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, usposabljanje, nadzor dostopa in upravljanje sredstev.

Program za opuščene DNS-zapise se jasno preslika na ta področja. Article 21(3) zahteva tudi, da varnost dobavne verige upošteva ranljivosti, značilne za vsakega neposrednega dobavitelja ali ponudnika storitev. Če marketinška agencija, dobavitelj SaaS, ponudnik upravljanega gostovanja ali platforma v oblaku upravlja domene po meri, morajo kontrole za posameznega dobavitelja zajemati lastništvo DNS, izstop iz storitve, podporo pri incidentih in primopredajo dokazil.

Article 23 je pomemben, če do prevzema pride ali če lahko povzroči resno operativno motnjo, finančno izgubo ali znatno materialno ali nematerialno škodo. NIS2 uporablja postopno poročanje: zgodnje opozorilo v 24 urah od seznanitve s pomembnim incidentom, obvestilo v 72 urah, vmesna poročila na zahtevo in končno poročilo v enem mesecu od obvestila o incidentu.

Za finančne subjekte je DORA sektorska ureditev digitalne operativne odpornosti. Articles 5 in 6 zahtevata notranji okvir upravljanja in kontrol za upravljanje tveganj IKT, s končno odgovornostjo upravljalnega organa, jasnimi vlogami IKT, politikami za razpoložljivost, avtentičnost, celovitost in zaupnost podatkov, načrti presoj, viri, politiko storitev tretjih oseb in dokumentiranim okvirom upravljanja IKT-tveganj.

Articles 8 do 14 tvorijo operativno jedro. Article 8 zahteva identifikacijo, razvrstitev in dokumentiranje poslovnih funkcij, podprtih z IKT, informacijskih sredstev, IKT-sredstev, odvisnosti, povezav s tretjimi ponudniki storitev IKT, evidenc, scenarijev tveganj in zastarelih sistemov. Opuščen CNAME je pogosto spregledana odvisnost. Article 9 zahteva zaščito in preprečevanje. Article 10 zahteva zaznavanje anomalne dejavnosti, incidentov IKT in potencialnih enojnih točk odpovedi. Articles 11 in 12 obravnavata neprekinjeno poslovanje, obnovitev, varnostno kopiranje in obnovo. Article 13 zahteva učenje iz ranljivosti, groženj, incidentov in testov.

Articles 17 do 19 formalizirajo upravljanje incidentov, razvrščanje in poročanje. Articles 28 do 30 določajo življenjski cikel tveganj tretjih oseb na področju IKT. Finančni subjekti ostajajo v celoti odgovorni pri uporabi ponudnikov storitev IKT. Za pripravljenost na DORA Clarysec priporoča dodajanje štirih polj v vsak register DNS in storitev v oblaku: podpora kritični ali pomembni funkciji, tretji ponudnik storitev IKT, sklic na pogodbo ali register ter status testiranja izhodne strategije.

GDPR se uporablja, kadar vprašanje vključuje osebne podatke. Prevzem poddomene ni samodejno kršitev varnosti osebnih podatkov, vendar to lahko postane, če prizadeta poddomena zbira poverilnice, zajema podatke iz obrazcev, se lažno predstavlja kot storitev, izpostavlja identifikatorje uporabnikov ali omogoča nepooblaščen dostop do osebnih podatkov. GDPR Article 5 zahteva celovitost, zaupnost in odgovornost. Article 32 zahteva ustrezno varnost obdelave. Article 33 lahko zahteva obvestilo nadzornemu organu, če je verjetno, da bo kršitev varnosti osebnih podatkov povzročila tveganje za pravice in svoboščine posameznikov.

Clarysecova Politika upravljanja incidentov in kršitev PII Politika upravljanja incidentov in kršitev PII, Razvrščanje in ocena kršitve, točka 4.2.6 podpira to analizo sprožitvenih pogojev v več ureditvah:

[Pogojno] Vodja zasebnosti / vodja PIMS MORA za vsak incident v zvezi z osebno določljivimi podatki z velikim vplivom oceniti ustrezne zakonske, sektorske, finančno-sektorske, kibernetskovarnostne, pogodbene, naročniške in storitveno-prejemniške sprožitvene pogoje za poročanje ter izid uporabljivosti evidentirati v REG01, REG08 in REG10.

Ta zapis odločitve je natančno to, kar je potrebno, kadar bi prevzem poddomene lahko vključeval GDPR, NIS2, DORA, pogodbe in obveščanje strank.

Kako bodo presojevalci preverjali vaša dokazila

Integriran ISMS mora omogočati, da različnim presojevalcem odgovorite z isto dokazno osnovo. Besedilo vprašanja se spremeni, dokaz pa je pogosto isti.

Širši pogled zagotavljanja zaupanja pogosto vključuje NIST CSF 2.0 in COBIT 2019. NIST CSF 2.0 pomaga izraziti ciljno stanje prek rezultatov GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER. Trenutni profil lahko pokaže ročne četrtletne preglede DNS in nedosleden postopek izstopa iz SaaS. Ciljni profil lahko zahteva avtomatizirane tedenske preverbe prevzema, obvezno dodelitev lastnika, dokazila o izstopu dobaviteljev in integracijo z upravljanjem sprememb.

Presojevalec, usmerjen v COBIT 2019 ali ISACA, bo običajno vprašal, kdo je lastnik procesa, kako se tveganje vrednoti in usmerja, ali so spremembe nadzorovane, ali so dobavitelji upravljani, ali so konfiguracije in sredstva zanesljivi ter ali dokazila za zagotavljanje zaupanja podpirajo poročanje vodstvu. Morda najprej ne bo zahteval seznama CNAME. Lahko pa vpraša, kako vodstvo ve, da so zunanje digitalne storitve nadzorovane skozi celoten življenjski cikel.

Kako izgledajo dobra revizijska dokazila

Paket revizijskih dokazil za opuščene DNS-zapise mora biti dovolj majhen za vzdrževanje, vendar dovolj popoln za zagovor. Clarysec običajno priporoča naslednji nabor dokazil:

• Evidenca DNS-con z virom, datumom, vrsto zapisa, ciljem in lastnikom.
• Rezultati skeniranja zunanje napadalne površine, ki prikazujejo preverbe prevzema.
• Vnosi v register sredstev za domene, poddomene, storitve v oblaku, aplikacije SaaS in CDN.
• Register storitev, ki prikazuje notranjo odgovornost ali odgovornost dobavitelja.
• Zahtevki za spremembe pri ustvarjanju, spreminjanju in brisanju DNS-zapisov.
• Kontrolni seznami uvajanja storitev v oblaku in SaaS, vključno s pregledom domen po meri in DNS.
• Pogodbe z dobavitelji ali varnostne klavzule, ki zajemajo DNS, gostovanje, podporo pri incidentih in izstop.
• Zahtevki za ranljivosti z resnostjo, lastnikom, datumom odprave in dokazili o ponovnem testiranju.
• Ocena PII, kadar poddomena obdeluje ali je prej obdelovala osebne podatke.
• Zapisi razvrstitve incidentov za sum ali potrjen prevzem.
• Pridobljene izkušnje in posodobljeni postopki po ugotovitvah.

Pomembne so tudi metrike. Vodstvo mora videti število zunanjih poddomen, odstotek z dodeljenimi lastniki, število ugotovitev opuščenih zapisov, povprečni čas odprave, zapadle ugotovitve z visokim tveganjem, poddomene, ki jih gosti dobavitelj brez aktualnega pogodbenega sklica, in odstotek izstopov iz oblaka z dokazili o odstranitvi DNS-zapisov.

Te metrike tehnično higieno pretvorijo v dokazila o nadzoru vodstva.

Pogosti vzorci odpovedi, ki jih ugotavlja Clarysec

Pri strankah iz SaaS, finančne tehnologije, zdravstvene tehnologije, upravljanih storitev in e-trgovine se ponavljajo isti vzorci.

Prvič, lastništvo DNS je razdeljeno med ekipe. Inženiring je lastnik oblaka. Trženje je lastnik kampanj. IT je lastnik dostopa do ponudnika DNS. Nabava je lastnik prenehanja SaaS. Nihče ni lastnik celotnega življenjskega cikla.

Drugič, izbris v oblaku se obravnava kot konec storitve. V resnici lahko ostanejo DNS, digitalna potrdila, pravila WAF, spremljanje, skrivnosti, dokumentacija in evidence dobaviteljev.

Tretjič, skenerji ranljivosti se osredotočajo na aktivne gostitelje, vendar spregledajo pogoje za prevzem, značilne za posameznega ponudnika. Organizacije potrebujejo preverjanja zunanje napadalne površine, ki razumejo pogosta stanja napak v SaaS in oblaku.

Četrtič, postopki izstopa dobaviteljev se osredotočajo na račune in vračilo podatkov, ne pa na domene po meri, DNS-zapise in spremembe podobdelovalcev.

Petič, ekipe za zasebnost so obveščene prepozno. Če je poddomena obdelovala PII, mora biti DPO ali vodja za zasebnost del razvrščanja, preden se sprejmejo predpostavke.

Šestič, dokazila obstajajo, vendar so razpršena. Izvoz DNS je v enem orodju, zahtevki za spremembe v drugem, pogodbe z dobavitelji v nabavi, poročila o ranljivostih v skenerjih, analiza zasebnosti pa v e-pošti. Presojevalci razpršenost obravnavajo kot slabost.

Orodja Clarysec to rešujejo s povezovanjem politik, registrov, kontrol in delovnih tokov za dokazila.

30-dnevni akcijski načrt za upravljanje DNS

Če ste našli en opuščen DNS-zapis, predpostavite, da jih je več. Če jih niste našli, zagotovite, da lahko dokažete zakaj.

Začnite s tem 30-dnevnim načrtom:

1. Izvozite vse avtoritativne DNS-cone.
2. Identificirajte zapise CNAME, ALIAS, A in AAAA, ki kažejo na storitve v oblaku, SaaS, CDN in storitve, ki jih upravljajo agencije.
3. Dodelite lastnike in poslovne namene.
4. Izvedite preverbe prevzema in ročno validirajte sumljive zapise.
5. Ustvarite zahtevke za ranljivosti za potrjena tveganja.
6. Odstranite ali ponovno zahtevajte izpostavljene zapise prek nadzora sprememb.
7. Posodobite register sredstev, register storitev v oblaku in register dobaviteljev.
8. Preglejte, ali je katera prizadeta poddomena obdelovala PII.
9. Dodajte preverjanja življenjskega cikla DNS v uvajanje storitev v oblaku, nabavo SaaS in izstop dobaviteljev.
10. Poročajte metrike vodstvu.

Tehnična odprava opuščenih DNS-zapisov je pogosto preprosta. Odprava upravljanja je tisto, kar prepreči naslednji prevzem.

Clarysec vam lahko pomaga to operacionalizirati z uporabo Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls in našega nabora politik za upravljanje sredstev, uporabo storitev v oblaku, upravljanje ranljivosti, upravljanje dobaviteljev, varnost PII, odziv na incidente in revizijska dokazila.

Če želite pristop, pripravljen za presojo, vam lahko Clarysec pomaga vzpostaviti paket dokazil o izpostavljenosti DNS in oblaka, ga preslikati na ISO/IEC 27001:2022, NIS2, DORA in GDPR ter pozabljene poddomene pretvoriti v nadzorovana, lastniško opredeljena in spremljana sredstva. Prenesite ustrezen nabor orodij Clarysec, zahtevajte predstavitev ali se dogovorite za oceno upravljanja DNS, preden naslednji pozabljeni kazalec najde penetracijski preizkuševalec, presojevalec ali napadalec.