⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Apleistų DNS įrašų valdysena NIS2, DORA ir GDPR kontekste

Igor Petreski

CISO gauna pranešimą pirmadienį 07:12.

Saugumo tyrėjas nustatė, kad promo.company.com nukreipia į apleistą debesijos programą. DNS įrašas vis dar aktyvus. Debesijos ištekliaus nebėra. SaaS nuomininkas, kuriame anksčiau veikė kampanija, buvo panaikintas prieš šešis mėnesius, netrukus po to, kai rinkodaros skyrius perėjo į kitą platformą. CNAME įrašo niekas nepašalino.

08:30 klausimas jau nebėra „Ar kas nors gali perimti subdomeną?“ Klausimas tampa „Kodėl niekas nežinojo, kad šis turtas egzistuoja?“

09:15 įsitraukia teisės skyrius, nes subdomenas anksčiau rinko el. pašto adresus produkto laukiančiųjų sąrašui. Įsitraukia pirkimų funkcija, nes kampanijos platformą valdė agentūra. Įsitraukia atitikties komanda, nes įmonė rengiasi ISO/IEC 27001:2022 priežiūros auditui, NIS2 pasirengimo vertinimui ir klientų patikinimo klausimynams. DPO klausia, ar ši ekspozicija galėtų tapti asmens duomenų saugumo pažeidimu pagal GDPR, jeigu subdomenas būtų panaudotas atakai. CFO klausia, ar ta pati silpnoji vieta galėtų paveikti mokėjimų portalą grupės reguliuojamoje finansinių paslaugų aplinkoje.

Techninis ištaisymas gali užtrukti kelias minutes. Valdysenos problema gali būti sprendžiama mėnesius, jeigu organizacija negali įrodyti, kad kiekvienas į internetą nukreiptas turtas yra žinomas, turi savininką, yra peržiūrimas, stebimas ir išimamas iš eksploatacijos pagal kontroliuojamą procesą.

Todėl apleistų DNS įrašų ir subdomenų perėmimo prevencijos negalima traktuoti kaip siauro DNS sutvarkymo darbo. Pasenęs DNS įrašas dažnai yra matomas gilesnių kontrolės priemonių nesuveikimo požymis: neišsami turto apskaita, silpna savininkystė, trūkstami eksploatacijos nutraukimo įrodymai, prasta pakeitimų kontrolė, nepakankamas tiekėjų pasitraukimo valdymas, nepakankama išorinio atakos paviršiaus stebėsena ir neaiški incidentų klasifikacija.

Clarysec klientams apleisti DNS įrašai yra valdymo sistemos testas. Jie parodo, ar politikos, kontrolės priemonės, registrai, įrodymai ir atskaitomybė iš tikrųjų veikia, kai pamiršta debesijos priklausomybė tampa galimybe užpuolikui.

Ką iš tikrųjų reiškia apleisti DNS įrašai

Subdomeno perėmimas tampa įmanomas, kai DNS įrašas, dažnai CNAME, nukreipia į išteklių, kuris nebeegzistuoja arba kurio organizacija nebekontroliuoja. Jeigu užpuolikas gali prisiskirti arba atkurti tikslinį išteklių debesijos ar SaaS platformoje, jis gali pradėti teikti turinį per organizacijos patikimą subdomeną.

Dažni pavyzdžiai:

  • CNAME nukreipia į neprisiskirtą debesijos programos paslaugą.
  • Vardinis SaaS pagrindinio kompiuterio vardas paliekamas DNS po prenumeratos nutraukimo.
  • CDN distribucija pašalinama iš teikėjo konsolės, bet vis dar nurodoma viešajame DNS.
  • Rinkodaros mikrosvetainę agentūra išima iš eksploatacijos nepašalinusi DNS įrašo.
  • Saugyklos galinis taškas arba statinės svetainės susiejimas gali būti užregistruotas iš naujo.
  • Kūrimo subdomenas lieka pasiekiamas per pamirštą platformos kaip paslaugos projektą.

Poveikis verslui gali būti didelis. Užpuolikai gali talpinti fišingo puslapius, rinkti prisijungimo duomenis, platinti kenkimo programinę įrangą, piktnaudžiauti domeno reputacija, perimti sesijų duomenis arba pakenkti pasitikėjimui prekės ženklu. Kai subdomenas anksčiau tvarkė asmens duomenis, net trumpalaikis perėmimas gali inicijuoti GDPR pažeidimo analizę. Kai paveikta paslauga palaiko reguliuojamas finansines operacijas, incidentą taip pat gali reikėti vertinti pagal DORA arba vidines IRT rizikos sistemas.

Auditoriai vis dažniau vertina apleistus DNS įrašus kaip kontrolės priemonių brandos įrodymą. Vienas pasenęs įrašas gali rodyti, kad organizacija nežino, kokį turtą turi, kas yra jo savininkas, kaip peržiūrimi pakeitimai, kaip nutraukiamas debesijos paslaugų naudojimas arba kaip stebimas iš išorės pasiekiamas turtas.

Todėl Clarysec šią problemą susieja su ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019 audito lūkesčiais.

Kodėl ISO 27001:2022 yra praktinis pagrindas

Stipriausias būdas valdyti apleistus DNS įrašus nėra atskirų programų kūrimas NIS2, DORA ir GDPR tikslams. Praktinis kelias yra naudoti ISO/IEC 27001:2022 kaip valdymo sistemos pagrindą ir vieną kartą parengti įrodymus keliems patikinimo poreikiams.

Aktualūs reikalavimai prasideda dar iki Annex A. 4.1–4.4 punktai reikalauja, kad organizacija suprastų savo kontekstą, suinteresuotųjų šalių reikalavimus, ISVS taikymo sritį ir priklausomybes nuo kitų organizacijų. Apleistų DNS įrašų valdysenos atveju taikymo sritis turi apimti išorinį DNS, domenus, registratorius, debesijos paslaugas, SaaS platformas, agentūras, valdomą prieglobą, CDN ir bet kurią trečiąją šalį, kuri gali sukurti arba nutraukti į internetą nukreiptas paslaugas.

5.1–5.3 punktai šią temą paverčia vadovybės ir atskaitomybės klausimu. Vadovybė turi suderinti ISVS su verslo kryptimi, skirti išteklius, komunikuoti informacijos saugumo svarbą ir priskirti atsakomybes. Jeigu rinkodaros skyrius gali paleisti mikrosvetainę, inžinerijos komanda gali sukurti debesijos galinius taškus, o pirkimų funkcija gali nutraukti SaaS sutartis, organizacijai reikia valdysenos modelio, kuris aiškiai priskirtų DNS ir paslaugų savininkystę visoms šioms sritims.

6.1.1–6.1.3 punktai suteikia rizikos vertinimo, rizikos tvarkymo ir Taikomumo pareiškimo logiką. Apleisti DNS įrašai turi būti registruojami kaip realus rizikos scenarijus, o ne tik kaip skenerio išvestis. Jie veikia konfidencialumą, vientisumą ir prieinamumą ir dažnai siejasi su teisiniais, reguliaciniais ir sutartiniais įpareigojimais.

7.5, 8.1, 8.2 ir 8.3 punktai valdyseną paverčia įrodymais. Jie reikalauja kontroliuojamos dokumentuotos informacijos, planuojamų ir kontroliuojamų operacinių procesų, nenumatytų pakeitimų įvertinimo, išorėje teikiamų procesų kontrolės, periodinių rizikos vertinimų ir dokumentuotų rizikos tvarkymo rezultatų.

Annex A pateikia kontrolės priemonių katalogą. Clarysec projektuose pagrindinės ISO/IEC 27002:2022 sąsajos paprastai atrodo taip:

Rizikos sritisISO/IEC 27002:2022 kontrolės priemonės sąsajaKo tikisi auditorius
Nežinomi subdomenai5.9 Informacijos ir kito susijusio turto inventoriusAktualios apskaitos, apimančios domenus, DNS įrašus, debesijos paslaugas, SaaS susiejimus ir savininkus
SaaS ir debesijos susiejimai5.23 Informacijos saugumas naudojantis debesijos paslaugomisDebesijos paslaugos gyvavimo ciklo, deramo patikrinimo, naudojimo patvirtinimo, pasitraukimo ir savininkystės įrodymai
Pasenusios išorinės ekspozicijos8.8 Techninių pažeidžiamumų valdymasIšorinis skenavimas, triažas, taisomųjų veiksmų sekimas ir liekamosios rizikos priėmimas
DNS ir paslaugos eksploatacijos nutraukimas8.32 Pakeitimų valdymasPakeitimų užklausos, rodančios DNS pašalinimą, grąžinimo į ankstesnę būseną planavimą, patvirtinimus ir patikras po pakeitimo
Tiekėjų talpinamas turtas5.19, 5.20, 5.21 ir 5.22 tiekėjų kontrolės priemonėsTiekėjų saugumo reikalavimai, sutartinės nuostatos, stebėsena, peržiūra ir nutraukimo tvarkymas
Aptikimas ir reagavimas8.15 Žurnalų tvarkymas, 8.16 Stebėsenos veikla, 5.24–5.27 incidentų valdymo kontrolės priemonėsStebėsenos įrodymai, įvykių klasifikavimas, reagavimo procedūros ir įgyta patirtis
PII ekspozicija5.31 Teisiniai, įstatyminiai, reguliaciniai ir sutartiniai reikalavimai ir 5.34 Privatumas ir PII apsaugaGDPR susiejimas, pažeidimo vertinimas, duomenų tvarkytojo įrašai ir tvarkymo saugumo įrodymai

Esmė paprasta. ISO/IEC 27001:2022 nereikalauja herojiško vienkartinio sutvarkymo. Jis reikalauja kontroliuojamo veiklos modelio, kuris užkirstų kelią pasikartojimui.

Zenith Controls požiūris: viena rizika, trys kontrolės atramos

Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec naudoja aktualias ISO/IEC 27002:2022 kontrolės priemones kaip kelių atitikties režimų atramas. Apleistų DNS įrašų ir subdomenų perėmimo valdysenai svarbiausios trys kontrolės priemonės.

Kontrolės priemonė 5.9, Informacijos ir kito susijusio turto inventorius, klasifikuojama kaip prevencinė, palaiko konfidencialumą, vientisumą ir prieinamumą, siejasi su Identify kibernetinio saugumo koncepcija ir priklauso turto valdymui kaip operaciniam gebėjimui, o valdysena, ekosistema ir apsauga yra saugumo sritys.

Kontrolės priemonė 5.23, Informacijos saugumas naudojantis debesijos paslaugomis, klasifikuojama kaip prevencinė, palaiko konfidencialumą, vientisumą ir prieinamumą, siejasi su Protect ir priklauso tiekėjų santykių saugumui kaip operaciniam gebėjimui, o valdysena, ekosistema ir apsauga yra saugumo sritys.

Kontrolės priemonė 8.8, Techninių pažeidžiamumų valdymas, klasifikuojama kaip prevencinė, palaiko konfidencialumą, vientisumą ir prieinamumą, siejasi su Identify ir Protect ir priklauso grėsmių ir pažeidžiamumų valdymui kaip operaciniam gebėjimui, o valdysena, ekosistema, apsauga ir gynyba yra saugumo sritys.

Tai svarbu, nes apleisti DNS įrašai nėra vien turto kontrolės priemonės nesuveikimas, vien debesijos kontrolės priemonės nesuveikimas ar vien pažeidžiamumas. Tai visi trys dalykai. Organizacija turi parodyti, kad turto apskaita, debesijos naudojimo valdysena ir pažeidžiamumų valdymas stiprina vienas kitą.

Clarysec dažnai prideda palaikomąsias praktikas prie šių atramų: ISO/IEC 27005 rizikos vertinimo ir tvarkymo disciplinai, ISO/IEC 27017 debesijos paslaugų saugumo valdysenai, ISO/IEC 27018, kai debesijos paslaugos tvarko PII, ISO/IEC 27701 privatumo informacijos valdymui ir ISO 22301, kai aktualus veiklos tęstinumas ir reagavimas į krizę.

Politikos įrodymai, kurie jau reikalauja DNS gyvavimo ciklo kontrolės

Daugelis organizacijų jau turi politikas, kurios, tinkamai įgyvendintos, užkirstų kelią apleistiems DNS įrašams. Spraga ta, kad DNS gyvavimo ciklo kontrolė nėra aiškiai susieta su tomis politikomis.

Clarysec Asset Management Policy-sme Asset Management Policy-sme - SME, Politikos įgyvendinimo reikalavimų 6.6.1 punktas nustato:

Debesijos aplinkoje veikiantys turtai (pvz., saugyklos paskyros, SaaS platformos, žiniatinklio domenai) taip pat turi būti įtraukti į turto apskaitą.

Ta pati politika 6.6.2 punkte papildo:

Savininkystė, paskirtis, prieigos teisės ir atnaujinimo terminai turi būti dokumentuoti.

Apleistų DNS įrašų valdysenai tai reiškia, kad kiekvienas produkcinis subdomenas ir reikšmingas neprodukcinis subdomenas turi turėti įvardytą savininką, verslo paskirtį, susietą paslaugą, prieigos modelį ir peržiūros datą.

Svarbiausia, 6.6.3 punktas nustato:

Pasibaigusio galiojimo arba nenaudojamos paslaugos turi būti deaktyvuotos ir pašalintos iš turto apskaitos.

DNS atveju tai reikia aiškinti atsargiai. Pašalinti paslaugą iš turto apskaitos nepakanka. Taip pat turi būti peržiūrėtas DNS įrašas, debesijos susiejimas, SaaS pasirinktinio domeno priskyrimas, sertifikatas, WAF taisyklė, CDN konfigūracija ir stebėsenos įrašas.

Įmonėms skirta versija sustiprina šią platesnę turto sampratą. Clarysec Asset Management Policy Asset Management Policy, Taikymo srities 2.2.5 punktas nustato:

Loginiai turtai: domenų vardai, licencijos, naudotojų paskyros, bazinės konfigūracijos

Domenų vardai ir konfigūracijos nėra administracinės smulkmenos. Tai pasitikėjimą nešantis turtas, kuris gali tapti atakos keliais.

Pakeitimų kontrolės sąsaja ne mažiau svarbi. Clarysec Change Management Policy Change Management Policy, Tikslo 1.1 punktas nustato:

Ši politika nustato formalią sistemą, skirtą organizacijos informacinių sistemų, infrastruktūros, taikomųjų programų ir susijusių procesų pakeitimams inicijuoti, vertinti, tvirtinti, įgyvendinti ir peržiūrėti.

Todėl DNS pašalinimas, SaaS sutarties nutraukimas, debesijos programos ištrynimas, CDN migracija arba rinkodaros mikrosvetainės eksploatacijos nutraukimas turi sukurti pakeitimo įrodymus. Pakeitimo užklausos nebuvimas dažnai yra pirmasis audito perspėjimo signalas.

Debesijos valdysena taip pat turi būti susieta. Clarysec Cloud Usage Policy Cloud Usage Policy, Valdysenos reikalavimų 5.5 punktas nustato:

Informacijos saugumo komanda turi reguliariai vertinti tinklo srautą, DNS veiklą ir žurnalus, kad aptiktų neautorizuotą debesijos naudojimą (shadow IT). Aptikti pažeidimai turi būti nedelsiant ištirti.

Subdomenų perėmimo prevencijai DNS veiklos stebėsena nėra tik shadow IT aptikimas. Ji taip pat susijusi su pasenusiu IT turtu, t. y. ištekliais, kurie kadaise buvo autorizuoti, bet dabar nebėra kontroliuojami.

Praktinė Clarysec darbo eiga apleistų DNS įrašų valdysenai

Stipri apleistų DNS įrašų programa nėra sudėtinga. Ji turi būti disciplinuota, kartojama ir susieta su ISVS, pažeidžiamumų valdymu, pakeitimų valdymu ir tiekėjų gyvavimo ciklu.

ŽingsnisVeiksmasSaugotini įrodymai
1Eksportuoti autoritetingas DNS zonas iš registratoriaus, DNS teikėjo ir debesijos DNS paslaugųDNS eksporto failai, API išvestis, šaltinio laiko žyma
2Išspręsti visus CNAME, A, AAAA ir ALIAS įrašus ir nustatyti neveikiančius, rezervuotus, neišsprendžiamus arba teikėjo klaidą grąžinančius tikslusSkenavimo ataskaita, priemonės išvestis, ekrano kopijos, kai reikia
3Susieti kiekvieną įrašą su turto savininku, verslo paslauga, debesijos paskyra, SaaS teikėju ir duomenų klasifikacijaTurto registro įrašai, paslaugų registras, savininko patvirtinimas
4Nustatyti perėmimui jautrius teikėjus ir neprisiskirtus pasirinktinių domenų susiejimusRizikų registro įrašas, pažeidžiamumo užklausa
5Patikrinti, ar subdomenas kada nors tvarkė PII arba palaikė kritines verslo funkcijasDuomenų žemėlapis, tvarkymo veiklos įrašas, BIA nuoroda
6Pašalinti, prisiskirti arba iš naujo susieti tikslinį išteklių per pakeitimų kontrolęPakeitimo užklausa, patvirtinimas, įgyvendinimo žurnalas
7Patvirtinti trūkumų pašalinimą išoriniu pakartotiniu testavimuPakartotinio testavimo ataskaita, DNS propagacijos įrodymai
8Atnaujinti tiekėjų, debesijos, turto ir rizikų registrusRegistrų atnaujinimai, sutarties arba pasitraukimo įrodymai
9Nuspręsti, ar reikalingas incidento arba pažeidimo vertinimasĮvykio klasifikavimo įrašas, teisinis arba DPO sprendimas
10Įtraukti įgytą patirtį į įvedimo į darbą, darbo santykių nutraukimo ir pirkimų kontrolinius sąrašusAtnaujinta procedūra, mokymų arba informuotumo pastaba

MVĮ atveju tai gali prasidėti kaip paprastas registras. Įmonėse tai paprastai integruojama su DNS eksportais, išorinio atakos paviršiaus valdymu, debesijos turto apskaita, CMDB įrašais, pažeidžiamumų skeneriais, SIEM įspėjimais ir užklausų valdymo sistemomis.

Valdysenos klausimas išlieka tas pats: ar galite įrodyti, kad kiekvienas iš išorės pasiekiamas subdomenas yra žinomas, turi savininką, yra stebimas ir gali būti pašalintas pagal kontroliuojamą procesą?

Tinkamai sutvarkytas apleistas kampanijos subdomenas

Grįžkime prie pirmadienio incidento. promo.company.com nukreipia į apleistą SaaS kampanijos svetainę.

Pirma, saugumo vadovas sukuria pažeidžiamumo įrašą, nes turtas yra pasiekiamas iš išorės. Clarysec Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, Politikos įgyvendinimo reikalavimų 6.1.1 punktas nustato:

Visos sistemos turi būti skenuojamos bent kartą per mėnesį; didelės rizikos arba išorėje pasiekiami turtai turi būti skenuojami kas savaitę.

MVĮ atveju lygiavertė politika patikslina prioritetus. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Politikos įgyvendinimo reikalavimų 6.5.1 punktas nustato:

Sistemoms, kurios tvarko asmens duomenis, suteikia nuotolinę prieigą arba yra išorėje pasiekiamos, turi būti teikiamas prioritetas skenavimui ir atnaujinimams

Antra, savininkas nustatomas per turto registrą. Jeigu savininkas nežinomas, tai tampa turto valdysenos kontrolės nesuveikimu. Registras atnaujinamas įtraukiant DNS vardą, tikslinį teikėją, pradinį verslo savininką, duomenų klasifikaciją, tiekėją ir būseną.

Trečia, IT patikrina debesijos arba SaaS platformą. Jeigu debesijos paskyra buvo ištrinta, tiesiogiai aktualus Clarysec Cloud Usage Policy-sme Cloud Usage Policy-sme - SME, Politikos įgyvendinimo reikalavimų 6.3.6 punktas:

Ištrintas debesijos paskyras IT paslaugų teikėjas arba generalinis vadovas turi peržiūrėti dėl likutinės prieigos, našlaičių duomenų arba nepastebėto turinio.

Ketvirta, pakeitimo savininkas pateikia neatidėliotino arba pagreitinto pakeitimo užklausą DNS įrašui pašalinti arba ištekliui laikinai prisiskirti prieš pašalinimą. Užklausoje pateikiamas poveikio vertinimas, grąžinimo į ankstesnę būseną planas, patvirtinimai, įgyvendinimo įrodymai ir validavimas po pakeitimo.

Penkta, privatumo vadovas įvertina, ar subdomenas tvarkė arba galėjo atskleisti asmens duomenis. Clarysec PII Security and Access Control Policy PII Security and Access Control Policy, Saugaus konfigūravimo ir pažeidžiamumų valdymo 4.7.4 punktas nustato:

[Both] Sistemos savininkas / taikomosios programos savininkas PRIVALO REG12 registruoti PII tvarkančių sistemų pažeidžiamumų vertinimo aprėptį bent kartą per ketvirtį ir po esminio techninio pakeitimo.

4.7.5 punktas papildo:

[Both] Informacijos saugumo vadovas PRIVALO REG12 per penkias darbo dienas nuo validavimo registruoti neišspręstus didelės rizikos pažeidžiamumus, turinčius poveikį PII.

Šie punktai taikomi nepriklausomai nuo to, ar organizacija veikia kaip duomenų valdytojas, ar kaip duomenų tvarkytojas, nes jie pažymėti [Both]. Kalbant apie apleistą DNS įrašą, susijusį su PII, įrodymai neturi likti tik techninėje užklausoje. Jie turi atsispindėti PII pažeidžiamumų įrodymų registre.

Šešta, jeigu kampaniją talpino agentūra arba SaaS teikėjas, pirkimų funkcija patikrina trečiųjų šalių įrašus. Clarysec Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy, Santykių identifikavimo ir klasifikavimo 4.1.2 punktas nustato:

[All] Proceso savininkas / verslo savininkas PRIVALO REG08 identifikuoti kiekvienus siūlomus santykius su trečiąja šalimi, kuri tvarkys, pasieks, gaus, saugos, perduos, palaikys arba kitaip paveiks PII, prieš pirkimą, įtraukimą, atnaujinimą arba esminį privatumo santykių su trečiąja šalimi pakeitimą.

4.5.5 punktas reikalauja:

[Both] Tiekėjo / pirkimų savininkas PRIVALO REG08 registruoti tvarkymo vietas, prieglobos vietas ir tarptautinio perdavimo požymius ir susieti taikomus perdavimo įrodymus su REG09 prieš patvirtindamas duomenų tvarkytoją, subtvarkytoją, vietos pakeitimą arba perdavimui reikšmingą paslaugos pakeitimą.

Galiausiai atitikties vadovas parengia įrodymų paketą. Clarysec Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, Tikslų 3.4 punktas nustato, kad vienas tikslų yra:

Parengti dokumentuotus įrodymus ir audito pėdsaką reglamentavimo institucijų paklausimams, teisiniams procesams arba klientų patikinimo prašymams pagrįsti.

Būtent tokio rezultato reikia CISO, kai klientas, reguliuotojas arba auditorius klausia: „Kaip žinote, kad tai nepasikartos?“

Kur tinka Zenith Blueprint

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint paverčia kontrolės priemones auditui tinkamomis operacinėmis praktikomis. Apleisti DNS įrašai stipriai siejasi su keturiomis sritimis.

Controls in Action etape 22 žingsnis apima organizacines kontrolės priemones 5.1–5.18, įskaitant ISO/IEC 27002:2022 kontrolės priemonę 5.9. Zenith Blueprint nurodo:

Jokia organizacija negali apsaugoti to, ko nežino turinti. Kontrolės priemonė 5.9 formalizuoja šį pamatinį principą, reikalaudama sukurti ir palaikyti aktualų visos informacijos ir su ja susijusio ISVS aktualaus turto inventorių.

Toliau nurodoma:

Strateginiu požiūriu turto apskaita veikia kaip centrinė jūsų ISVS nervų sistema.

Jūsų subdomenų apskaita nėra šalutinis sąrašas. Ji maitina prieigos sprendimus, pažeidžiamumų skenavimą, žurnalavimą, tiekėjų valdymą, privatumo susiejimą ir reagavimą į incidentus.

20 žingsnyje Zenith Blueprint apima technologines kontrolės priemones 8.18–8.26. Dėl kontrolės priemonės 8.21, Tinklo paslaugų saugumas, jis nurodo organizacijoms validuoti tinklo paslaugų saugumą:

Išvardykite visas vidines ir išorines tinklo paslaugas (DNS, VPN, SMTP, DHCP, API vartus ir kt.).

Todėl DNS teikėjai, registratoriai, debesijos DNS, CDN platformos ir SaaS pasirinktinių domenų funkcijos turi būti paslaugų registre.

19 žingsnyje Zenith Blueprint apima technologines kontrolės priemones 8.1–8.17. Dėl kontrolės priemonės 8.8 nurodoma:

Pažeidžiamumų valdymas yra viena kritiškiausių šiuolaikinės kibernetinės higienos sričių. Nors ugniasienės ir antivirusinės programinės įrangos priemonės suteikia apsaugą, ją gali susilpninti nepataisytos sistemos arba neteisingai sukonfigūruotos paslaugos, paliktos pasiekiamos.

Apleistas DNS įrašas yra neteisingai sukonfigūruotas išorinės paslaugos kelias. Net kai nėra CVE, jis turi būti tvarkomas per pažeidžiamumų valdymą: validuoti, įvertinti balais, priskirti, pašalinti, pakartotinai testuoti ir uždaryti.

23 žingsnyje Zenith Blueprint nagrinėja organizacines kontrolės priemones 5.19–5.37. Dėl kontrolės priemonės 5.23 jis rekomenduoja:

Išvardykite visas šiuo metu naudojamas debesijos paslaugas (5.23), įskaitant žinomą shadow IT. Nustatykite, kas jas patvirtino ir ar buvo atliktas deramas patikrinimas. Parenkite paprastą vertinimo kontrolinį sąrašą, apimantį duomenų vietą, prieigos modelį, žurnalavimą ir šifravimą.

Subdomenų perėmimo prevencijai į šį debesijos paslaugų vertinimo kontrolinį sąrašą įtraukite pasirinktinius domenus, DNS priklausomybes, eksploatacijos nutraukimo savininką ir pasitraukimo įrodymus.

Susiejimas su NIS2, DORA ir GDPR

NIS2 daugeliui esminių ir svarbių subjektų apleistų DNS įrašų valdyseną paverčia valdybos lygmens klausimu. Article 20 reikalauja, kad valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų kibernetinio saugumo mokymuose. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, taikant visus pavojus apimantį požiūrį. Minimalios sritys apima rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, kūrimą ir priežiūrą, pažeidžiamumų tvarkymą, veiksmingumo vertinimą, kibernetinę higieną, mokymus, prieigos kontrolę ir turto valdymą.

Apleistų DNS įrašų programa aiškiai siejasi su šiomis sritimis. Article 21(3) taip pat reikalauja, kad tiekimo grandinės saugumas atsižvelgtų į kiekvienam tiesioginiam tiekėjui ar paslaugų teikėjui būdingus pažeidžiamumus. Jeigu rinkodaros agentūra, SaaS tiekėjas, valdomos prieglobos teikėjas arba debesijos platforma valdo pasirinktinius domenus, tiekėjui skirtos kontrolės priemonės turi apimti DNS savininkystę, paslaugos nutraukimą, pagalbą incidentų atveju ir įrodymų perdavimą.

Article 23 tampa svarbus, jeigu perėmimas įvyksta arba gali sukelti didelį veiklos sutrikimą, finansinius nuostolius arba reikšmingą materialinę ar nematerialinę žalą. NIS2 taiko etapinius pranešimus: ankstyvą įspėjimą per 24 valandas nuo sužinojimo apie reikšmingą incidentą, pranešimą per 72 valandas, tarpines ataskaitas, kai jų prašoma, ir galutinę ataskaitą per vieną mėnesį nuo incidento pranešimo.

Finansų sektoriaus subjektams DORA yra sektoriui taikomas skaitmeninio operacinio atsparumo režimas. Articles 5 ir 6 reikalauja vidaus valdysenos ir kontrolės sistemos IRT rizikos valdymui, galutinės valdymo organo atsakomybės, aiškių IRT vaidmenų, duomenų prieinamumo, autentiškumo, vientisumo ir konfidencialumo politikų, audito planų, išteklių, trečiųjų šalių paslaugų politikos ir dokumentuotos IRT rizikos valdymo sistemos.

Articles 8–14 sudaro operacinį branduolį. Article 8 reikalauja identifikuoti, klasifikuoti ir dokumentuoti IRT palaikomas verslo funkcijas, informacijos išteklius, IRT turtą, priklausomybes, IRT trečiųjų šalių tarpusavio jungtis, inventorius, rizikos scenarijus ir senąsias sistemas. Apleistas CNAME dažnai yra nepastebėta priklausomybė. Article 9 reikalauja apsaugos ir prevencijos. Article 10 reikalauja aptikti anomalią veiklą, IRT incidentus ir galimus vienintelius nesuveikimo taškus. Articles 11 ir 12 apima veiklos tęstinumą, atkūrimą, atsarginių kopijų kūrimą ir atkūrimą. Article 13 reikalauja mokytis iš pažeidžiamumų, grėsmių, incidentų ir testų.

Articles 17–19 formalizuoja incidentų valdymą, klasifikavimą ir pranešimą. Articles 28–30 trečiųjų šalių IRT riziką padaro grindžiamą gyvavimo ciklu. Finansų sektoriaus subjektai lieka visiškai atsakingi naudodamiesi IRT paslaugų teikėjais. DORA pasirengimui Clarysec rekomenduoja į kiekvieną DNS ir debesijos paslaugų registrą įtraukti keturis laukus: svarbios ar ypatingos svarbos funkcijos palaikymą, trečiųjų šalių IRT paslaugų teikėją, sutarties arba registro nuorodą ir pasitraukimo testo būseną.

GDPR taikomas, kai klausimas susijęs su asmens duomenimis. Subdomeno perėmimas savaime nėra asmens duomenų saugumo pažeidimas, bet gali juo tapti, jeigu paveiktas subdomenas renka prisijungimo duomenis, fiksuoja formų duomenis, apsimeta paslauga, atskleidžia naudotojų identifikatorius arba sudaro sąlygas neteisėtai prieigai prie asmens duomenų. GDPR Article 5 reikalauja vientisumo, konfidencialumo ir atskaitomybės. Article 32 reikalauja tinkamo tvarkymo saugumo. Article 33 gali reikalauti pranešti priežiūros institucijai, jeigu asmens duomenų saugumo pažeidimas gali kelti riziką fizinių asmenų teisėms ir laisvėms.

Clarysec PII Incident and Breach Management Policy PII Incident and Breach Management Policy, Klasifikavimo ir pažeidimo vertinimo 4.2.6 punktas palaiko šią kelių režimų inicijavimo sąlygų analizę:

[Conditional] Privatumo vadovas / PIMS vadovas PRIVALO įvertinti taikomas teisines, sektorines, finansų sektoriaus, kibernetinio saugumo, sutartines, klientų ir paslaugos gavėjų pranešimo inicijavimo sąlygas kiekvienam didelio poveikio PII incidentui ir registruoti taikymo rezultatą REG01, REG08 ir REG10.

Būtent toks sprendimo įrašas reikalingas, kai subdomeno perėmimas gali apimti GDPR, NIS2, DORA, sutartis ir klientų informavimą.

Kaip auditoriai tikrins jūsų įrodymus

Integruota ISVS turėtų leisti atsakyti skirtingiems auditoriams remiantis ta pačia įrodymų baze. Klausimo formuluotė keičiasi, bet įrodymų medžiaga dažnai yra ta pati.

ISO/IEC 27002:2022 kontrolės priemonėISO 27001 auditoriaus klausimasNIS2 arba DORA auditoriaus klausimasGDPR auditoriaus klausimas
5.9 Informacijos ir kito susijusio turto inventoriusAr šis subdomenas įtrauktas į apskaitą, turi savininką, yra suklasifikuotas ir valdomas per gyvavimo ciklą?Kaip jūsų apskaita palaiko IRT turto ir priklausomybių identifikavimą?Ar galite nustatyti turtą, kuris tvarko arba anksčiau tvarkė asmens duomenis?
5.23 Informacijos saugumas naudojantis debesijos paslaugomisKoks jūsų debesijos paslaugų įtraukimo, stebėsenos ir pasitraukimo procesas?Kaip IRT trečiųjų šalių priklausomybės valdomos viso gyvavimo ciklo metu?Ar duomenų tvarkytojo arba subtvarkytojo santykiai buvo dokumentuoti ir saugiai nutraukti?
8.8 Techninių pažeidžiamumų valdymasKur yra skenavimo rezultatai, rizikos lygis, taisomųjų veiksmų užklausa ir pakartotinio testavimo įrodymai?Kaip pažeidžiamumų tvarkymas ir kibernetinė higiena palaiko rizikos valdymą?Ar pažeidžiamumas, turintis poveikį PII, buvo įvertintas, užregistruotas ir eskaluotas?
8.32 Pakeitimų valdymasAr DNS pašalinimas arba paslaugos eksploatacijos nutraukimas buvo patvirtintas, įgyvendintas ir peržiūrėtas?Kaip kontroliuojami IRT pakeitimai, kad būtų išvengta veiklos sutrikimų?Ar galite parodyti atskaitomybę už pakeitimus, turinčius poveikį asmens duomenų sistemoms?
5.24–5.27 incidentų valdymo kontrolės priemonėsAr įvykis buvo suklasifikuotas, į jį sureaguota ir jis peržiūrėtas dėl įgytos patirties?Ar buvo įvertintas reikšmingo arba didelio incidento praneštinumas?Ar dokumentuota pranešimo apie pažeidimą analizė?

Platesnė patikinimo perspektyva dažnai apima NIST CSF 2.0 ir COBIT 2019. NIST CSF 2.0 padeda išreikšti tikslinę būseną per GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER rezultatus. Esamos būsenos profilis gali parodyti rankines ketvirtines DNS peržiūras ir nenuoseklų SaaS išvedimą. Tikslinės būsenos profilis gali reikalauti automatizuotų savaitinių perėmimo patikrų, privalomo savininko priskyrimo, tiekėjo pasitraukimo įrodymų ir integracijos su pakeitimų valdymu.

COBIT 2019 arba ISACA krypties auditorius paprastai klausia, kas yra proceso savininkas, kaip rizika vertinama ir nukreipiama, ar pakeitimai kontroliuojami, ar tiekėjai valdomi, ar konfigūracija ir turtas yra patikimi ir ar patikinimo įrodymai palaiko ataskaitų teikimą vadovybei. Jie gali pirmiausia neprašyti CNAME sąrašo. Jie gali paklausti, kaip vadovybė žino, kad išorinės skaitmeninės paslaugos kontroliuojamos viso jų gyvavimo ciklo metu.

Auditoriaus perspektyvaTikėtinas klausimasStiprūs įrodymai
ISO 27001:2022 auditoriusAr DNS ir debesijos paslaugų gyvavimo ciklas įtrauktas į ISVS taikymo sritį, rizikos tvarkymą ir operacinę kontrolę?ISVS taikymo sritis, rizikų registras, Taikomumo pareiškimas, turto apskaita, pakeitimų užklausos, pažeidžiamumų šalinimo įrašai
NIST CSF vertintojasKokia yra esama ir tikslinė išorinio atakos paviršiaus valdysenos būklė?CSF profilis, spragų planas, tiekėjų stebėsenos įrodymai, aptikimo ir reagavimo procedūros
DORA vertintojasAr IRT turtas, priklausomybės, trečiųjų šalių paslaugos ir incidentų klasifikacijos dokumentuotos kritinėms funkcijoms?IRT turto apskaita, trečiųjų šalių registras, incidentų klasifikavimas, atsparumo testavimas, pasitraukimo strategija
GDPR auditorius arba DPOAr pasenęs subdomenas galėtų paveikti asmens duomenis ir ar galima parodyti atskaitomybę?PII duomenų žemėlapis, REG12 pažeidžiamumų įrašai, pažeidimo vertinimas, duomenų tvarkytojo įrašai, prieglobos vietos įrodymai
COBIT 2019 arba ISACA auditoriusAr turto, pakeitimų, tiekėjų ir rizikos valdysena yra veiksminga ir matuojama?RACI, ataskaitos vadovybei, KPI tendencijos, audito išvadų uždarymas, kontrolės priemonių testavimo rezultatai

Kaip atrodo geri audito įrodymai

Apleistų DNS įrašų audito paketas turi būti pakankamai mažas, kad būtų prižiūrimas, bet pakankamai išsamus, kad būtų galima pagrįsti atitiktį. Clarysec paprastai rekomenduoja šį įrodymų rinkinį:

  • DNS zonų apskaita su šaltiniu, data, įrašo tipu, tikslu ir savininku.
  • Išorinio atakos paviršiaus skenavimo rezultatai, rodantys perėmimo patikras.
  • Turto registro įrašai domenams, subdomenams, debesijos paslaugoms, SaaS taikomosioms programoms ir CDN.
  • Paslaugų registras, rodantis vidinę arba tiekėjo atsakomybę.
  • Pakeitimų užklausos dėl DNS įrašų sukūrimo, pakeitimo ir ištrynimo.
  • Debesijos ir SaaS įtraukimo kontroliniai sąrašai, įskaitant pasirinktinių domenų ir DNS peržiūrą.
  • Tiekėjų sutartys arba saugumo nuostatos, apimančios DNS, prieglobą, pagalbą incidentų atveju ir pasitraukimą.
  • Pažeidžiamumų užklausos su sunkumu, savininku, pašalinimo data ir pakartotinio testavimo įrodymais.
  • PII vertinimas, kai subdomenas tvarko arba anksčiau tvarkė asmens duomenis.
  • Incidentų klasifikavimo įrašai dėl įtariamo arba patvirtinto perėmimo.
  • Įgyta patirtis ir po išvadų atnaujintos procedūros.

Rodikliai taip pat svarbūs. Vadovybė turi matyti išorinių subdomenų skaičių, procentinę dalį su priskirtais savininkais, apleistų DNS įrašų išvadų skaičių, vidutinį trūkumų pašalinimo laiką, vėluojamas didelės rizikos išvadas, tiekėjų talpinamus subdomenus be aktualios sutarties nuorodos ir debesijos paslaugų nutraukimų dalį, turinčią DNS pašalinimo įrodymus.

Šie rodikliai techninę higieną paverčia vadovybės priežiūros įrodymais.

Dažni nesuveikimo dėsningumai, kuriuos randa Clarysec

SaaS, finansinių technologijų, sveikatos technologijų, valdomų paslaugų ir e. prekybos klientuose kartojasi tie patys dėsningumai.

Pirma, DNS savininkystė padalyta tarp komandų. Inžinerijos komanda valdo debesiją. Rinkodaros skyrius valdo kampanijas. IT valdo prieigą prie DNS teikėjo. Pirkimų funkcija valdo SaaS nutraukimą. Niekas nevaldo viso gyvavimo ciklo.

Antra, debesijos ištrynimas laikomas paslaugos pabaiga. Iš tikrųjų DNS, sertifikatai, WAF taisyklės, stebėsena, paslaptys, dokumentacija ir tiekėjų įrašai gali likti.

Trečia, pažeidžiamumų skeneriai orientuojasi į veikiančius pagrindinius kompiuterius, bet praleidžia teikėjui būdingas perėmimo sąlygas. Organizacijoms reikia išorinio atakos paviršiaus patikrų, kurios supranta įprastas SaaS ir debesijos klaidų būsenas.

Ketvirta, tiekėjų pasitraukimo procedūros orientuojasi į sąskaitas faktūras ir duomenų grąžinimą, bet ne į pasirinktinius domenus, DNS įrašus ir subtvarkytojų pokyčius.

Penkta, privatumo komandos informuojamos per vėlai. Jeigu subdomenas tvarkė PII, DPO arba privatumo vadovas turi dalyvauti klasifikavime prieš darant prielaidas.

Šešta, įrodymai egzistuoja, bet yra išskaidyti. DNS eksportas yra vienoje priemonėje, pakeitimų užklausos – kitoje, tiekėjų sutartys – pirkimų funkcijoje, pažeidžiamumų ataskaitos – skeneriuose, o privatumo analizė – el. pašte. Auditoriai fragmentaciją vertina kaip silpnybę.

Clarysec priemonių rinkinys tai sprendžia susiedamas politikas, registrus, kontrolės priemones ir įrodymų darbo eigas.

30 dienų veiksmų planas DNS valdysenai

Jeigu radote vieną apleistą DNS įrašą, laikykite, kad jų yra daugiau. Jeigu neradote nė vieno, įsitikinkite, kad galite įrodyti kodėl.

Pradėkite nuo šio 30 dienų plano:

  1. Eksportuokite visas autoritetingas DNS zonas.
  2. Nustatykite CNAME, ALIAS, A ir AAAA įrašus, nukreipiančius į debesijos, SaaS, CDN ir agentūrų valdomas paslaugas.
  3. Priskirkite savininkus ir verslo paskirtis.
  4. Atlikite perėmimo patikras ir rankiniu būdu validuokite įtartinus įrašus.
  5. Sukurkite pažeidžiamumų užklausas patvirtintoms rizikoms.
  6. Pašalinkite arba prisiskirkite paveiktus įrašus per pakeitimų kontrolę.
  7. Atnaujinkite turto registrą, debesijos registrą ir tiekėjų registrą.
  8. Peržiūrėkite, ar kuris nors paveiktas subdomenas tvarkė PII.
  9. Įtraukite DNS gyvavimo ciklo patikras į debesijos įtraukimą, SaaS pirkimus ir tiekėjų pasitraukimą.
  10. Pateikite rodiklius vadovybei.

Techninis apleistų DNS įrašų sutvarkymas dažnai paprastas. Valdysenos sutvarkymas yra tai, kas užkerta kelią kitam perėmimui.

Clarysec gali padėti tai operacionalizuoti naudojant Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls ir mūsų politikų priemonių rinkinį turto valdymui, debesijos naudojimui, pažeidžiamumų valdymui, tiekėjų valdysenai, PII saugumui, reagavimui į incidentus ir audito įrodymams.

Jeigu norite auditui tinkamo požiūrio, Clarysec gali padėti sukurti DNS ir debesijos ekspozicijos įrodymų paketą, susieti jį su ISO/IEC 27001:2022, NIS2, DORA ir GDPR ir paversti pamirštus subdomenus kontroliuojamu, savininką turinčiu ir stebimu turtu. Atsisiųskite aktualų Clarysec priemonių rinkinį, paprašykite demonstracijos arba suplanuokite DNS valdysenos vertinimą prieš tai, kai kitą pamirštą nuorodą ras įsiskverbimo testuotojas, auditorius arba užpuolikas.

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article