Rippuvate DNS-kirjete haldus NIS2, DORA ja GDPR-i kontekstis

Infoturbejuht saab teate esmaspäeval kell 07:12.

Turbeuurija on leidnud, et promo.company.com viitab mahajäetud pilverakendusele. DNS-kirje on endiselt aktiivne. Pilveressurssi enam ei ole. SaaS-i tenant, mis kunagi kampaaniat teenindas, kustutati kuus kuud tagasi, vahetult pärast seda, kui turundus kolis teisele platvormile. CNAME jäi eemaldamata.

Kell 08:30 ei ole küsimus enam „Kas keegi saab alamdomeeni üle võtta?“. Küsimus on: „Miks keegi ei teadnud, et see vara olemas oli?“

Kell 09:15 on kaasatud õigusosakond, sest alamdomeen kogus kunagi e-posti aadresse toote ootenimekirja jaoks. Kaasatud on hankeosakond, sest kampaaniaplatvormi haldas agentuur. Kaasatud on vastavusüksus, sest ettevõte valmistub ISO/IEC 27001:2022 järelevalveauditiks, NIS2-valmiduseks ja klientide kindlustandvateks küsimustikeks. DPO küsib, kas see avatus võib muutuda GDPR-i tähenduses isikuandmetega seotud rikkumiseks, kui alamdomeen muudetakse ründevahendiks. CFO küsib, kas sama nõrkus võiks mõjutada grupi reguleeritud finantsteenuste keskkonna makseportaali.

Tehniline parandus võib võtta minuteid. Juhtimisprobleemi lahendamine võib võtta kuid, kui organisatsioon ei suuda tõendada, et iga internetile avatud vara on teada, sellel on omanik, seda vaadatakse läbi, seda seiratakse ja see kõrvaldatakse kasutuselt kontrollitud protsessi kaudu.

Seetõttu ei saa rippuvaid DNS-kirjeid ja alamdomeenide ülevõtmise ennetamist käsitleda kitsa DNS-i korrastamise ülesandena. Aegunud DNS-kirje on sageli sügavamate kontrollimeetmete tõrgete nähtav sümptom: puudulik varade register, nõrk omanikuvastutus, puuduv kasutuselt kõrvaldamise tõendusmaterjal, ebapiisav muudatuste juhtimine, puudulik tarnijasuhte lõpetamise haldus, ebapiisav välise ründepinna seire ja ebaselge intsidendi klassifitseerimine.

Clarysec klientide jaoks on rippuv DNS juhtimissüsteemi test. See näitab, kas poliitikad, kontrollimeetmed, registrid, tõendusmaterjal ja vastutus toimivad tegelikult siis, kui unustatud pilvesõltuvusest saab ründaja võimalus.

Mida rippuv DNS tegelikult tähendab

Alamdomeeni ülevõtmine muutub võimalikuks siis, kui DNS-kirje, sageli CNAME, viitab ressursile, mida enam ei eksisteeri või mis ei ole enam organisatsiooni kontrolli all. Kui ründaja saab pilve- või SaaS-platvormil sihtressursi hõivata või uuesti luua, võib ta saada võimaluse avaldada sisu organisatsiooni usaldatud alamdomeeni all.

Levinud näited on järgmised:

• CNAME viitab hõivamata pilverakenduse teenusele.
• Bränditud SaaS-hostinimi jäetakse pärast tellimuse lõpetamist DNS-i alles.
• CDN-i jaotus eemaldatakse teenuseosutaja konsoolist, kuid sellele viidatakse endiselt avalikus DNS-is.
• Agentuur kõrvaldab turunduse mikrosaidi kasutuselt ilma DNS-kirjet eemaldamata.
• Salvestuse lõpp-punkt või staatilise veebisaidi vastendus on uuesti registreeritav.
• Arendusalamdomeen on avatud unustatud PaaS-projekti kaudu.

Ärimõju võib olla tõsine. Ründajad võivad majutada andmepüügilehti, püüda autentimisandmeid, levitada pahavara, kuritarvitada domeeni mainet, pealt kuulata seansiandmeid või kahjustada usaldust brändi vastu. Kui alamdomeen töötles varem isikuandmeid, võib isegi lühiajaline ülevõtmine käivitada GDPR-i rikkumise analüüsi. Kui mõjutatud teenus toetab reguleeritud finantstoiminguid, võib intsident vajada hindamist ka DORA või sisemiste IKT-riskiraamistike alusel.

Audiitorid käsitlevad rippuvat DNS-i üha enam kontrollimeetmete küpsuse tõendusmaterjalina. Üks aegunud kirje võib näidata, et organisatsioon ei tea, milliseid varasid ta omab, kes nende eest vastutab, kuidas muudatusi läbi vaadatakse, kuidas pilveteenuste kasutamine lõpetatakse või kuidas internetile avatud varasid seiratakse.

Seetõttu seostab Clarysec selle teema ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT 2019 auditiootustega.

Miks ISO 27001:2022 on praktiline selgroog

Kõige tugevam viis rippuva DNS-i juhtimiseks ei ole luua NIS2, DORA ja GDPR-i jaoks eraldi programme. Tugevam lähenemine on kasutada ISO/IEC 27001:2022 standardit juhtimissüsteemi selgroona ja koguda tõendusmaterjali üks kord mitme kindlustandva vajaduse jaoks.

Asjakohased nõuded algavad juba enne lisa A. Punktid 4.1 kuni 4.4 nõuavad, et organisatsioon mõistaks oma konteksti, huvitatud poolte nõudeid, ISMS-i kohaldamisala ja sõltuvusi teistest organisatsioonidest. Rippuva DNS-i juhtimise puhul peaks kohaldamisala hõlmama välist DNS-i, domeene, domeeniregistraatoreid, pilveteenuseid, SaaS-platvorme, agentuure, hallatud majutust, CDN-e ja kõiki kolmandaid osapooli, kes saavad luua või kasutuselt kõrvaldada internetile avatud teenuseid.

Punktid 5.1 kuni 5.3 muudavad selle juhtimise ja vastutuse küsimuseks. Juhtkond peab viima ISMS-i kooskõlla ärisuunaga, tagama ressursid, kommunikeerima infoturbe olulisust ja määrama vastutused. Kui turundus saab käivitada mikrosaidi, arendus saab luua pilve lõpp-punkte ja hange saab lõpetada SaaS-lepinguid, vajab organisatsioon juhtimismudelit, mis määrab kõigi nende tegevuste lõikes selge DNS-i ja teenuste omanikuvastutuse.

Punktid 6.1.1 kuni 6.1.3 annavad riskihindamise, riskikäsitluse ja kohaldatavusdeklaratsiooni loogika. Rippuv DNS tuleb registreerida realistliku riskistsenaariumina, mitte üksnes skanneri väljundina. See mõjutab konfidentsiaalsust, terviklust ja käideldavust ning seostub sageli õiguslike, regulatiivsete ja lepinguliste kohustustega.

Punktid 7.5, 8.1, 8.2 ja 8.3 muudavad juhtimise tõendusmaterjaliks. Need nõuavad kontrollitud dokumenteeritud teavet, kavandatud ja kontrollitud tööprotsesse, soovimatute muudatuste arvestamist, väljastpoolt osutatavate protsesside kontrolli, perioodilisi riskihindamisi ja dokumenteeritud käsitlustulemusi.

Lisa A annab seejärel kontrollikataloogi. Clarysec projektides näevad peamised ISO/IEC 27002:2022 seosed tavaliselt välja järgmiselt:

Põhimõte on lihtne. ISO/IEC 27001:2022 ei nõua kangelaslikku ühekordset koristust. See nõuab kontrollitud toimimismudelit, mis ennetab kordumist.

Zenith Controls vaade: üks risk, kolm kontrollankrut

Dokumendis Zenith Controls: The Cross-Compliance Guide Zenith Controls kasutab Clarysec asjakohaseid ISO/IEC 27002:2022 kontrollimeetmeid raamistikeülese vastavuse ankrutena. Rippuva DNS-i ja alamdomeeni ülevõtmise juhtimise puhul on keskse tähtsusega kolm kontrollimeedet.

Kontroll 5.9, teabe ja muude seotud varade register, on liigitatud ennetavaks, toetab konfidentsiaalsust, terviklust ja käideldavust, joondub küberturbe kontseptsiooniga Identify ning paikneb varahalduse all operatiivse võimekusena, mille turbevaldkondadeks on juhtimine, ökosüsteem ja kaitse.

Kontroll 5.23, infoturve pilveteenuste kasutamisel, on liigitatud ennetavaks, toetab konfidentsiaalsust, terviklust ja käideldavust, joondub kontseptsiooniga Protect ning paikneb tarnijasuhete turbe all operatiivse võimekusena, mille turbevaldkondadeks on juhtimine, ökosüsteem ja kaitse.

Kontroll 8.8, tehniliste haavatavuste haldus, on liigitatud ennetavaks, toetab konfidentsiaalsust, terviklust ja käideldavust, joondub kontseptsioonidega Identify ja Protect ning paikneb ohtude ja haavatavuste halduse all operatiivse võimekusena, mille turbevaldkondadeks on juhtimine, ökosüsteem, kaitse ja tõrje.

See on oluline, sest rippuv DNS ei ole ainult varade kontrollimeetme tõrge, ainult pilvekontrolli tõrge ega ainult haavatavus. See on kõik kolm korraga. Organisatsioon peab näitama, et varade register, pilveteenuste kasutamise juhtimine ja haavatavuste haldus tugevdavad üksteist.

Clarysec lisab nende ankrute ümber sageli toetavad praktikad: ISO/IEC 27005 riskihindamise ja riskikäsitluse distsipliiniks, ISO/IEC 27017 pilveteenuste turbejuhtimiseks, ISO/IEC 27018 juhtudeks, kus pilveteenused töötlevad PII-d, ISO/IEC 27701 privaatsusteabe halduseks ning ISO 22301 olukordades, kus talitluspidevus ja kriisireageerimine on asjakohased.

Poliitika tõendusmaterjal, mis juba nõuab DNS-i elutsükli kontrolli

Paljudel organisatsioonidel on juba poliitikad, mis nõuetekohase rakendamise korral ennetaksid rippuvat DNS-i. Puudujääk seisneb selles, et DNS-i elutsükli kontroll ei ole nende poliitikatega selgelt seotud.

Clarysec Asset Management Policy-sme Asset Management Policy-sme - SME, poliitika rakendamise nõuete punkt 6.6.1 sätestab:

Pilvekeskkonnas asuvad varad (nt salvestuskontod, SaaS-platvormid, veebidomeenid) tuleb samuti registrisse lisada.

Sama poliitika lisab punktis 6.6.2:

Omand, eesmärk, juurdepääsuõigused ja uuendamise tähtajad tuleb dokumenteerida.

Rippuva DNS-i juhtimise puhul tähendab see, et igal tootmiskeskkonna alamdomeenil ja olulisel tootmisvälisel alamdomeenil peab olema nimeline omanik, ärieesmärk, seotud teenus, juurdepääsumudel ja läbivaatamise kuupäev.

Kõige olulisem on punkt 6.6.3:

Aegunud või kasutamata teenused tuleb deaktiveerida ja registrist eemaldada.

DNS-i puhul tuleb seda tõlgendada ettevaatlikult. Teenuse registrist eemaldamisest ei piisa. Läbi tuleb vaadata ka DNS-kirje, pilvesidumine, SaaS-i kohandatud domeeni nõue, sertifikaat, WAF-i reegel, CDN-i konfiguratsioon ja seirekirje.

Ettevõtte versioon tugevdab seda laiemat varakäsitlust. Clarysec Asset Management Policy Asset Management Policy, kohaldamisala punkt 2.2.5 sätestab:

Loogilised varad: domeeninimed, litsentsid, kasutajakontod, konfiguratsiooni lähtealused

Domeeninimed ja konfiguratsioonid ei ole halduslik pisiasi. Need on usaldust kandvad varad, mis võivad muutuda ründeteedeks.

Seos muudatuste juhtimisega on sama oluline. Clarysec Change Management Policy Change Management Policy, eesmärgi punkt 1.1 sätestab:

Käesolev poliitika kehtestab ametliku raamistiku organisatsiooni infosüsteemide, taristu, rakenduste ja seotud protsesside muudatuste algatamiseks, hindamiseks, heakskiitmiseks, rakendamiseks ja läbivaatamiseks.

Seega peaks DNS-i eemaldamine, SaaS-i lõpetamine, pilverakenduse kustutamine, CDN-i migreerimine või turunduse mikrosaidi kasutuselt kõrvaldamine looma muudatuse tõendusmaterjali. Muudatuse pileti puudumine on sageli esimene auditiriskile viitav märk.

Ühendada tuleb ka pilveteenuste juhtimine. Clarysec Cloud Usage Policy Cloud Usage Policy, juhtimisnõuete punkt 5.5 sätestab:

Infoturbe meeskond peab regulaarselt hindama võrguliiklust, DNS-i tegevust ja logisid, et tuvastada volitamata pilveteenuste kasutamine (varjatud IT). Tuvastatud rikkumisi tuleb viivitamata uurida.

Alamdomeeni ülevõtmise ennetamisel ei puuduta DNS-i tegevuse seire üksnes varjatud IT-d. See puudutab ka aegunud IT-d ehk varasid, mis olid kunagi heaks kiidetud, kuid ei ole enam kontrolli all.

Praktiline Clarysec töövoog rippuva DNS-i juhtimiseks

Tugev rippuva DNS-i programm ei ole keeruline. See on distsiplineeritud, korratav ning seotud ISMS-i, haavatavuste halduse, muudatuste juhtimise ja tarnija elutsükliga.

VKE-de puhul võib see alata lihtsustatud registrina. Suuremates ettevõtetes integreeritakse tavaliselt DNS-i ekspordid, välise ründepinna haldus, pilvevarade registrid, CMDB kirjed, haavatavuste skannerid, SIEM-i teavitused ja piletihaldussüsteemid.

Juhtimisküsimus jääb samaks: kas suudate tõendada, et iga väliselt ligipääsetav alamdomeen on teada, omanikuga, seiratud ja kontrollitud protsessi kaudu eemaldatav?

Mahajäetud kampaania alamdomeen õigesti käsitletuna

Naaseme esmaspäevase intsidendi juurde. promo.company.com viitab mahajäetud SaaS-kampaania saidile.

Esiteks loob turbejuht haavatavuse kirje, sest vara on internetile avatud. Clarysec Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, poliitika rakendamise nõuete punkt 6.1.1 sätestab:

Kõiki süsteeme tuleb skannida vähemalt kord kuus; kõrge riskiga või väliselt avatud varasid tuleb skannida kord nädalas.

VKE-de puhul täpsustab samaväärne poliitika prioriseerimist. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, poliitika rakendamise nõuete punkt 6.5.1 sätestab:

Süsteemid, mis töötlevad isikuandmeid, pakuvad kaugjuurdepääsu või on väliselt avatud, tuleb skannimise ja uuenduste puhul prioriseerida

Teiseks tuvastatakse omanik vararegistri kaudu. Kui omanik on teadmata, on see varahalduse kontrollimeetme tõrge. Registrit uuendatakse nii, et see hõlmaks DNS-nime, sihtteenuse osutajat, algset ärilist omanikku, andmete klassifikatsiooni, tarnijat ja staatust.

Kolmandaks kontrollib IT pilve- või SaaS-platvormi. Kui pilvekonto on kustutatud, on otseselt asjakohane Clarysec Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, poliitika rakendamise nõuete punkt 6.3.6:

Kustutatud pilvekontod peab IT-teenusepakkuja või tegevjuht läbi vaatama, et tuvastada jääkjuurdepääsuõigused, omanikuta andmed või märkamata jäänud sisu.

Neljandaks algatab muudatuse omanik erakorralise või kiirendatud muudatuse pileti, et DNS-kirje eemaldada või ressurss enne eemaldamist ajutiselt uuesti hõivata. Pilet sisaldab mõjuhindamist, tagasipööramiskava, heakskiite, rakendamise tõendusmaterjali ja muudatusejärgset valideerimist.

Viiendaks hindab privaatsuse eest vastutav isik, kas alamdomeen töötles või võis avaldada isikuandmeid. Clarysec PII Security and Access Control Policy PII Security and Access Control Policy, turvalise seadistamise ja haavatavuste halduse punkt 4.7.4 sätestab:

[Mõlemad] Süsteemiomanik / rakenduse omanik PEAB vähemalt kord kvartalis ja pärast olulist tehnilist muudatust registreerima PII-d töötlevate süsteemide haavatavuste hindamise katvuse REG12-s.

Punkt 4.7.5 lisab:

[Mõlemad] Infoturbe juht PEAB valideerimisest viie tööpäeva jooksul registreerima REG12-s lahendamata kõrge riskiga haavatavused, mis mõjutavad PII-d.

Need punktid kehtivad sõltumata sellest, kas organisatsioon tegutseb vastutava töötleja või volitatud töötlejana, sest need on märgistatud [Mõlemad]. Kui rippuva DNS-i probleem hõlmab PII-d, ei tohi tõendusmaterjal jääda ainult tehnilisse piletisse. See peab kajastuma PII haavatavuste tõendusmaterjali registris.

Kuuendaks, kui kampaaniat majutas agentuur või SaaS-teenuse osutaja, kontrollib hankeosakond kolmandate osapoolte kirjeid. Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, suhte tuvastamise ja klassifitseerimise punkt 4.1.2 sätestab:

[Kõik] Protsessiomanik / ettevõtte omanik PEAB enne hanget, kaasamist, uuendamist või olulist kolmanda osapoole privaatsusmuudatust tuvastama REG08-s iga kavandatava kolmanda osapoole suhte, mis töötleb, kasutab, saab, säilitab, edastab, toetab või muul viisil mõjutab PII-d.

Punkt 4.5.5 nõuab:

[Mõlemad] Tarnija / hanke omanik PEAB enne volitatud töötleja, alltöötleja, asukohamuudatuse või edastusega seotud teenusemuudatuse heakskiitmist registreerima REG08-s töötlemiskohad, majutuskohad ja rahvusvahelise edastamise indikaatorid ning siduma kohaldatava edastamise tõendusmaterjali REG09-ga.

Lõpuks koondab vastavusjuht tõendusmaterjali. Clarysec Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, eesmärkide punkt 3.4 sätestab, et üks eesmärk on:

Luua kaitstav tõendusmaterjal ja auditijälg regulatiivsete päringute, kohtumenetluste või klientidele kindluse andmise taotluste toetamiseks.

Just seda tulemust vajab infoturbejuht, kui klient, regulaator või audiitor küsib: „Kuidas te teate, et seda enam ei juhtu?“

Kuhu sobitub Zenith Blueprint

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint teisendab kontrollimeetmed auditivalmiteks tööpraktikateks. Rippuv DNS seostub tugevalt nelja valdkonnaga.

Controls in Action etapis käsitleb samm 22 organisatsioonilisi kontrollimeetmeid 5.1 kuni 5.18, sealhulgas ISO/IEC 27002:2022 kontrolli 5.9. Zenith Blueprint sätestab:

Ükski organisatsioon ei saa kaitsta seda, mille olemasolust ta ei tea. Kontroll 5.9 vormistab selle aluspõhimõtte, nõudes ISMS-i jaoks asjakohase kogu teabe ja seotud varade ajakohase registri loomist ja hoidmist.

See jätkub:

Kõige strateegilisemas vormis toimib varade register teie ISMS-i keskse närvisüsteemina.

Teie alamdomeenide register ei ole kõrvaline loend. See toetab juurdepääsuotsuseid, haavatavuste skannimist, logimist, tarnijahaldust, privaatsuskaardistust ja intsidentidele reageerimist.

Sammus 20 käsitleb Zenith Blueprint tehnilisi kontrollimeetmeid 8.18 kuni 8.26. Kontrolli 8.21, võrguteenuste turve, puhul suunab see organisatsioone valideerima võrguteenuste turvalisust:

Loetlege kõik sisemised ja välised võrguteenused (DNS, VPN, SMTP, DHCP, API-lüüsid jne).

Seetõttu kuuluvad teenuseregistrisse DNS-teenuse osutajad, domeeniregistraatorid, pilve DNS, CDN-platvormid ja SaaS-i kohandatud domeenide funktsioonid.

Sammus 19 käsitleb Zenith Blueprint tehnilisi kontrollimeetmeid 8.1 kuni 8.17. Kontrolli 8.8 kohta sätestab see:

Haavatavuste haldamine on üks tänapäevase küberhügieeni kriitilisemaid valdkondi. Kuigi tulemüürid ja viirusetõrjevahendid pakuvad kaitset, võib see kaitse nõrgeneda, kui paikamata süsteemid või väärkonfigureeritud teenused jäävad avatuks.

Rippuv DNS-kirje on väärkonfigureeritud välise teenuse tee. Isegi kui CVE-d ei ole, tuleb seda käsitleda haavatavuste halduse kaudu: valideerida, skoorida, määrata vastutaja, parandada, kordustestida ja sulgeda.

Sammus 23 käsitleb Zenith Blueprint organisatsioonilisi kontrollimeetmeid 5.19 kuni 5.37. Kontrolli 5.23 puhul soovitab see:

Loetlege kõik praegu kasutatavad pilveteenused (5.23), sealhulgas teadaolev varjatud IT. Tuvastage, kes need heaks kiitis ja kas tehti hoolsuskontroll. Töötage välja lihtsustatud hindamise kontrollnimekiri, mis hõlmab andmete asukohta, juurdepääsumudelit, logimist ja krüptimist.

Alamdomeeni ülevõtmise ennetamiseks lisage sellesse pilveteenuse hindamise kontrollnimekirja kohandatud domeenid, DNS-sõltuvused, kasutuselt kõrvaldamise omanik ja väljumise tõendusmaterjal.

NIS2, DORA ja GDPR-i vastendus

NIS2 muudab rippuva DNS-i juhtimise paljude oluliste ja tähtsate üksuste jaoks juhtorgani tasandi küsimuseks. Artikkel 20 nõuab, et juhtorganid kiidaksid heaks küberturbe riskijuhtimise meetmed, jälgiksid nende rakendamist ja läbiksid küberturbe koolituse. Artikkel 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi meetmeid, kasutades kõiki ohte hõlmavat lähenemisviisi. Selle miinimumvaldkonnad hõlmavad riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist, arendust ja hooldust, haavatavuste käsitlemist, tõhususe hindamist, küberhügieeni, koolitust, juurdepääsukontrolli ja varahaldust.

Rippuva DNS-i programm vastendub nende valdkondadega selgelt. Artikkel 21(3) nõuab ka, et tarneahela turve arvestaks iga otsese tarnija või teenuseosutaja spetsiifilisi haavatavusi. Kui turundusagentuur, SaaS-i tarnija, hallatud majutusteenuse osutaja või pilveplatvorm haldab kohandatud domeene, peaksid tarnijapõhised kontrollimeetmed hõlmama DNS-i omanikuvastutust, teenuse lõpetamist, intsidendituge ja tõendusmaterjali üleandmist.

Artikkel 23 on oluline juhul, kui ülevõtmine toimub või võib põhjustada raske tegevushäire, rahalise kahju või märkimisväärse materiaalse või mittemateriaalse kahju. NIS2 kasutab etapiviisilist aruandlust: varajane hoiatus 24 tunni jooksul olulise intsidendi teada saamisest, teavitus 72 tunni jooksul, vahearuanded taotluse korral ning lõpparuanne ühe kuu jooksul pärast intsidenditeavitust.

Finantssektori üksuste jaoks on DORA sektoripõhine digitaalse tegevuskerksuse raamistik. Artiklid 5 ja 6 nõuavad IKT-riski juhtimiseks sisemist juhtimis- ja kontrolliraamistikku, milles on juhtorgani lõplik vastutus, selged IKT-rollid, poliitikad andmete käideldavuse, autentsuse, tervikluse ja konfidentsiaalsuse tagamiseks, auditiplaanid, ressursid, kolmandatest isikutest teenuseosutajate poliitika ning dokumenteeritud IKT-riskijuhtimise raamistik.

Artiklid 8 kuni 14 moodustavad operatiivse tuuma. Artikkel 8 nõuab IKT-toega ärifunktsioonide, teabevarade, IKT-varade, sõltuvuste, kolmandatest isikutest IKT-teenuseosutajate ühenduste, registrite, riskistsenaariumide ja pärandsüsteemide tuvastamist, klassifitseerimist ja dokumenteerimist. Rippuv CNAME on sageli märkamata jäänud sõltuvus. Artikkel 9 nõuab kaitset ja ennetust. Artikkel 10 nõuab anomaalse tegevuse, IKT-intsidentide ja võimalike üksikute rikkepunktide tuvastamist. Artiklid 11 ja 12 käsitlevad talitluspidevust, taastet, varundust ja taastamist. Artikkel 13 nõuab haavatavustest, ohtudest, intsidentidest ja testidest õppimist.

Artiklid 17 kuni 19 vormistavad intsidendihalduse, klassifitseerimise ja aruandluse. Artiklid 28 kuni 30 muudavad kolmandast isikust IKT-teenuseosutajate riski elutsüklipõhiseks. Finantsüksused jäävad IKT-teenuseosutajaid kasutades täielikult vastutavaks. DORA-valmiduse jaoks soovitab Clarysec lisada igasse DNS-i ja pilveteenuse registrisse neli välja: kriitilise või olulise funktsiooni tugi, kolmandast isikust IKT-teenuseosutaja, lepingu või registri viide ning väljumistesti staatus.

GDPR kohaldub siis, kui probleem hõlmab isikuandmeid. Alamdomeeni ülevõtmine ei ole automaatselt isikuandmetega seotud rikkumine, kuid see võib selleks muutuda, kui mõjutatud alamdomeen kogub autentimisandmeid, püüab vormiandmeid, kehastab teenust, avaldab kasutajatunnuseid või võimaldab loata juurdepääsu isikuandmetele. GDPR Artikkel 5 nõuab terviklust, konfidentsiaalsust ja vastutust. Artikkel 32 nõuab töötlemise asjakohast turvalisust. Artikkel 33 võib nõuda järelevalveasutuse teavitamist, kui isikuandmetega seotud rikkumisega kaasneb tõenäoliselt risk füüsiliste isikute õigustele ja vabadustele.

Clarysec PII Incident and Breach Management Policy PII Incident and Breach Management Policy, klassifitseerimise ja rikkumise hindamise punkt 4.2.6 toetab sellist mitme režiimi käivitajate analüüsi:

[Tingimuslik] Privaatsusjuht / PIMS-i juht PEAB iga suure mõjuga PII intsidendi puhul hindama kohaldatavaid õiguslikke, sektoripõhiseid, finantssektori, küberturbe, lepingulisi, kliendi ja teenusesaaja aruandluskäivitajaid ning registreerima kohaldatavuse tulemuse REG01-s, REG08-s ja REG10-s.

Just sellist otsuse kirjet on vaja siis, kui alamdomeeni ülevõtmine võib hõlmata GDPR-i, NIS2, DORA, lepinguid ja klientide teavitamist.

Kuidas audiitorid teie tõendusmaterjali testivad

Integreeritud ISMS peaks võimaldama vastata eri audiitoritele sama tõendusbaasi abil. Küsimuse sõnastus muutub, kuid tõendusmaterjal on sageli sama.

Laiem kindlustandev vaade hõlmab sageli ka NIST CSF 2.0 ja COBIT 2019. NIST CSF 2.0 aitab väljendada sihtseisundit tulemuste GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER kaudu. Praegune profiil võib näidata käsitsi tehtavaid kvartalipõhiseid DNS-i läbivaatamisi ja ebaühtlast SaaS-i lõpetamisprotsessi. Sihtprofiil võib nõuda automatiseeritud iganädalasi ülevõtmiskontrolle, kohustuslikku omaniku määramist, tarnijasuhte lõpetamise tõendusmaterjali ja lõimimist muudatuste juhtimisega.

COBIT 2019 või ISACA suunitlusega audiitor küsib tavaliselt, kes protsessi omab, kuidas riski hinnatakse ja suunatakse, kas muudatused on kontrollitud, kas tarnijaid juhitakse, kas konfiguratsioon ja varad on usaldusväärsed ning kas kindlustandev tõendusmaterjal toetab juhtkonna aruandlust. Nad ei pruugi esmalt küsida CNAME-ide loendit. Nad võivad küsida, kuidas juhtkond teab, et välised digitaalsed teenused on kogu elutsükli jooksul kontrolli all.

Milline näeb välja hea audititõendus

Rippuva DNS-i auditipakett peaks olema piisavalt väike, et seda hoida ajakohasena, kuid piisavalt täielik, et see oleks kaitstav. Clarysec soovitab tavaliselt järgmist tõendusmaterjali kogumit:

• DNS-tsoonide register koos allika, kuupäeva, kirjetüübi, sihtmärgi ja omanikuga.
• Välise ründepinna skannimistulemused, mis näitavad ülevõtmiskontrolle.
• Vararegistri kirjed domeenide, alamdomeenide, pilveteenuste, SaaS-rakenduste ja CDN-ide kohta.
• Teenuseregister, mis näitab sisemist või tarnija vastutust.
• Muudatuste piletid DNS-kirjete loomiseks, muutmiseks ja kustutamiseks.
• Pilve ja SaaS-i kasutuselevõtu kontrollnimekirjad, mis hõlmavad kohandatud domeeni ja DNS-i läbivaatamist.
• Tarnijalepingud või turbeklauslid, mis hõlmavad DNS-i, majutust, intsidendituge ja väljumist.
• Haavatavuste piletid koos tõsiduse, omaniku, paranduskuupäeva ja kordustestimise tõendusmaterjaliga.
• PII hindamine juhul, kui alamdomeen töötleb või varem töötles isikuandmeid.
• Intsidendi klassifitseerimise kirjed kahtlustatava või kinnitatud ülevõtmise kohta.
• Õppetunnid ja uuendatud protseduurid pärast leide.

Olulised on ka mõõdikud. Juhtkond peaks nägema väliste alamdomeenide arvu, omanikega alamdomeenide osakaalu, rippuvate leidude arvu, keskmist parandamisaega, tähtaja ületanud kõrge riskiga leide, tarnija majutatud alamdomeene ilma kehtiva lepinguviiteta ning pilveteenuste lõpetamiste osakaalu, millel on DNS-i eemaldamise tõendusmaterjal.

Need mõõdikud muudavad tehnilise hügieeni juhtkonna järelevalve tõendusmaterjaliks.

Levinud ebaõnnestumise mustrid, mida Clarysec leiab

SaaS-i, fintechi, tervisetehnoloogia, hallatud teenuste ja e-kaubanduse klientide puhul korduvad samad mustrid.

Esiteks on DNS-i vastutus jaotatud meeskondade vahel. Arendus vastutab pilve eest. Turundus vastutab kampaaniate eest. IT vastutab DNS-teenuse osutaja juurdepääsu eest. Hange vastutab SaaS-i lõpetamise eest. Keegi ei vastuta kogu elutsükli eest.

Teiseks käsitletakse pilve kustutamist teenuse lõpuna. Tegelikkuses võivad DNS, sertifikaadid, WAF-i reeglid, seire, saladused, dokumentatsioon ja tarnijakirjed alles jääda.

Kolmandaks keskenduvad haavatavuste skannerid aktiivsetele hostidele, kuid jätavad märkamata teenuseosutajapõhised ülevõtmistingimused. Organisatsioonid vajavad välise ründepinna kontrolle, mis mõistavad levinud SaaS-i ja pilve veaseisundeid.

Neljandaks keskenduvad tarnijasuhte lõpetamise protseduurid arvetele ja andmete tagastamisele, kuid mitte kohandatud domeenidele, DNS-kirjetele ja alltöötlejate muudatustele.

Viiendaks teavitatakse privaatsusmeeskondi liiga hilja. Kui alamdomeen töötles PII-d, peaks DPO või privaatsusjuht olema klassifitseerimisse kaasatud enne eelduste tegemist.

Kuuendaks on tõendusmaterjal olemas, kuid laiali. DNS-i eksport on ühes tööriistas, muudatuste piletid teises, tarnijalepingud hankes, haavatavuste aruanded skannerites ja privaatsusanalüüs e-kirjades. Audiitorid näevad killustatust nõrkusena.

Clarysec tööriistakomplekt lahendab selle, ühendades poliitikad, registrid, kontrollimeetmed ja tõendusmaterjali töövood.

30 päeva tegevusplaan DNS-i juhtimiseks

Kui leidsite ühe rippuva DNS-kirje, eeldage, et neid on veel. Kui te ei leidnud ühtegi, veenduge, et suudate tõendada, miks.

Alustage sellest 30 päeva plaanist:

1. Eksportige kõik autoriteetsed DNS-tsoonid.
2. Tuvastage CNAME-, ALIAS-, A- ja AAAA-kirjed, mis viitavad pilve-, SaaS-, CDN- ja agentuuri hallatavatele teenustele.
3. Määrake omanikud ja ärieesmärgid.
4. Tehke ülevõtmiskontrollid ja valideerige kahtlased kirjed käsitsi.
5. Looge kinnitatud riskide jaoks haavatavuste piletid.
6. Eemaldage või hõivake avatud kirjed uuesti muudatuste juhtimise kaudu.
7. Uuendage vararegistrit, pilveregistrit ja tarnijaregistrit.
8. Vaadake läbi, kas mõni mõjutatud alamdomeen töötles PII-d.
9. Lisage DNS-i elutsükli kontrollid pilveteenuste kasutuselevõtu, SaaS-hanke ja tarnijasuhte lõpetamise protsessidesse.
10. Esitage mõõdikud juhtkonnale.

Rippuva DNS-i tehniline parandus on sageli lihtne. Juhtimisparandus ennetab järgmist ülevõtmist.

Clarysec saab aidata selle rakendada, kasutades Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls ning meie poliitikakomplekti varahalduse, pilveteenuste kasutamise, haavatavuste halduse, tarnijate halduse, PII turbe, intsidentidele reageerimise ja audititõenduse jaoks.

Kui soovite auditivalmis lähenemist, saab Clarysec aidata teil koostada DNS-i ja pilve avatuse tõendusmaterjali paketi, vastendada selle ISO/IEC 27001:2022, NIS2, DORA ja GDPR-iga ning muuta unustatud alamdomeenid kontrollitud, omanikuga ja seiratud varadeks. Laadige alla asjakohane Clarysec tööriistakomplekt, küsige demo või leppige kokku DNS-i juhtimise hindamine enne, kui penetratsioonitestija, audiitor või ründaja leiab järgmise unustatud viite.