Guvernanța înregistrărilor DNS orfane pentru NIS2, DORA și GDPR

Directorul securității informației (CISO) primește mesajul luni, la 07:12.

Un cercetător în securitate a găsit promo.company.com indicând către o aplicație cloud abandonată. Înregistrarea DNS este încă activă. Resursa cloud nu mai există. Entitatea SaaS care susținuse campania a fost ștearsă acum șase luni, la scurt timp după ce Marketingul a migrat pe o altă platformă. Nimeni nu a eliminat înregistrarea CNAME.

La 08:30, întrebarea nu mai este „Poate cineva prelua subdomeniul?”. Întrebarea devine „De ce nu a știut nimeni că acest activ există?”.

La 09:15, departamentul Juridic este implicat deoarece subdomeniul colectase cândva adrese de e-mail pentru lista de așteptare a unui produs. Achizițiile sunt implicate deoarece platforma de campanie era administrată de o agenție. Conformitatea este implicată deoarece compania se pregătește pentru auditul de supraveghere ISO/IEC 27001:2022, pentru pregătirea NIS2 și pentru chestionarele de asigurare solicitate de clienți. Responsabilul cu protecția datelor (DPO) întreabă dacă expunerea ar putea deveni o încălcare a securității datelor cu caracter personal în temeiul GDPR, dacă subdomeniul este folosit ca vector de atac. CFO întreabă dacă aceeași slăbiciune ar putea afecta un portal de plăți din mediul reglementat de servicii financiare al grupului.

Remedierea tehnică poate dura câteva minute. Problema de guvernanță poate necesita luni pentru a fi rezolvată dacă organizația nu poate demonstra că fiecare activ expus la internet este cunoscut, are un proprietar, este revizuit, monitorizat și dezafectat printr-un proces controlat.

De aceea, prevenirea înregistrărilor DNS orfane și a preluării subdomeniilor nu poate fi tratată ca o simplă activitate de curățare DNS. O înregistrare DNS perimată este adesea un simptom vizibil al unor deficiențe de control mai profunde: inventar incomplet al activelor, proprietate neclară asupra activelor, lipsa dovezilor de dezafectare, control slab al schimbărilor, management insuficient al ieșirii furnizorilor, monitorizare inadecvată a suprafeței externe de atac și clasificare neclară a incidentelor.

Pentru clienții Clarysec, DNS orfan este un test al sistemului de management. El arată dacă politicile, controalele, registrele, dovezile și responsabilitatea funcționează efectiv atunci când o dependență cloud uitată devine o oportunitate pentru atacator.

Ce înseamnă, de fapt, DNS orfan

Preluarea unui subdomeniu devine posibilă atunci când o înregistrare DNS, adesea un CNAME, indică o resursă care nu mai există sau nu mai este controlată de organizație. Dacă un atacator poate revendica sau recrea resursa-țintă pe platforma cloud sau SaaS, acesta poate ajunge să publice conținut sub subdomeniul de încredere al organizației.

Exemple frecvente includ:

• Un CNAME care indică un serviciu de aplicație cloud nerevendicat.
• Un nume de gazdă SaaS personalizat rămas în DNS după anularea abonamentului.
• O distribuție CDN eliminată din consola furnizorului, dar încă referențiată în DNS public.
• Un microsite de marketing dezafectat de o agenție fără eliminarea înregistrării DNS.
• Un endpoint de stocare sau o mapare pentru site web static care poate fi reînregistrată.
• Un subdomeniu de dezvoltare expus printr-un proiect platform-as-a-service uitat.

Impactul asupra organizației poate fi sever. Atacatorii pot găzdui pagini de phishing, pot captura credențiale, pot distribui programe malware, pot abuza de reputația domeniului, pot intercepta date de sesiune sau pot afecta încrederea în brand. Atunci când subdomeniul a prelucrat anterior date cu caracter personal, chiar și o preluare de scurtă durată poate declanșa analiza unei încălcări a securității datelor în temeiul GDPR. Atunci când serviciul afectat susține operațiuni financiare reglementate, incidentul poate necesita și evaluare în temeiul DORA sau al cadrului intern de management al riscurilor TIC.

Auditorii văd tot mai des înregistrările DNS orfane ca dovezi ale maturității controalelor. O singură înregistrare perimată poate indica faptul că organizația nu știe ce deține, cine este proprietarul activelor, cum sunt revizuite schimbările, cum sunt închise serviciile cloud sau cum sunt monitorizate activele expuse extern.

De aceea, Clarysec mapează această problemă la așteptările de audit din ISO/IEC 27001:2022 ISO/IEC 27001:2022, ISO/IEC 27002:2022 ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST CSF 2.0 și COBIT 2019.

De ce ISO 27001:2022 este coloana vertebrală practică

Cea mai solidă modalitate de a guverna DNS orfan nu este crearea unor programe separate pentru NIS2, DORA și GDPR. Este utilizarea ISO/IEC 27001:2022 ca bază a sistemului de management și generarea o singură dată a dovezilor pentru mai multe nevoi de asigurare.

Cerințele relevante încep înainte de Anexa A. Clauzele 4.1 la 4.4 solicită organizației să înțeleagă contextul, cerințele părților interesate, domeniul de aplicare al SMSI și dependențele față de alte organizații. Pentru guvernanța înregistrărilor DNS orfane, domeniul de aplicare trebuie să includă DNS extern, domenii, registrari, servicii cloud, platforme SaaS, agenții, găzduire administrată, CDN-uri și orice terț care poate crea sau retrage servicii expuse la internet.

Clauzele 5.1 la 5.3 transformă acest subiect într-o problemă de leadership și responsabilitate. Managementul trebuie să alinieze SMSI la direcția organizației, să asigure resurse, să comunice importanța securității informației și să atribuie responsabilități. Dacă Marketingul poate lansa un microsite, Ingineria poate crea endpointuri cloud, iar Achizițiile pot închide contracte SaaS, organizația are nevoie de un model de guvernanță care atribuie clar proprietatea asupra DNS și asupra serviciilor în toate aceste zone.

Clauzele 6.1.1 la 6.1.3 asigură logica de evaluare a riscurilor, tratament al riscului și Declarație de aplicabilitate. DNS orfan trebuie înregistrat ca scenariu de risc realist, nu doar ca rezultat al unui scanner. El afectează confidențialitatea, integritatea și disponibilitatea și se mapează frecvent la obligații legale, de reglementare și contractuale.

Clauzele 7.5, 8.1, 8.2 și 8.3 transformă guvernanța în dovezi. Ele cer informații documentate controlate, procese operaționale planificate și controlate, luarea în considerare a schimbărilor neintenționate, controlul proceselor furnizate din exterior, evaluări periodice de risc și rezultate documentate ale tratamentului.

Anexa A oferă apoi catalogul de controale. În proiectele Clarysec, relațiile principale cu ISO/IEC 27002:2022 arată, de regulă, astfel:

Ideea este simplă. ISO/IEC 27001:2022 nu cere o curățare eroică, punctuală. Cere un model operațional controlat, care previne reapariția problemei.

Perspectiva Zenith Controls: un risc, trei ancore de control

În Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec utilizează controale ISO/IEC 27002:2022 relevante ca ancore pentru maparea cerințelor de conformitate între cadre. Pentru guvernanța DNS orfan și prevenirea preluării subdomeniilor, trei controale sunt centrale.

Controlul 5.9, Inventarul informațiilor și al altor active asociate, este clasificat ca preventiv, susține confidențialitatea, integritatea și disponibilitatea, se aliniază conceptului de securitate cibernetică Identify și se încadrează în managementul activelor ca abilitate operațională, având guvernanța, ecosistemul și protecția ca domenii de securitate.

Controlul 5.23, Securitatea informației pentru utilizarea serviciilor cloud, este clasificat ca preventiv, susține confidențialitatea, integritatea și disponibilitatea, se aliniază conceptului Protect și se încadrează în securitatea relațiilor cu furnizorii ca abilitate operațională, având guvernanța, ecosistemul și protecția ca domenii de securitate.

Controlul 8.8, Managementul vulnerabilităților tehnice, este clasificat ca preventiv, susține confidențialitatea, integritatea și disponibilitatea, se aliniază conceptelor Identify și Protect și se încadrează în managementul amenințărilor și vulnerabilităților ca abilitate operațională, având guvernanța, ecosistemul, protecția și apărarea ca domenii de securitate.

Acest lucru contează deoarece DNS orfan nu este doar un eșec al controalelor privind activele, nu este doar un eșec al controalelor cloud și nu este doar o vulnerabilitate. Este toate trei. Organizația trebuie să arate că inventarul activelor, guvernanța utilizării serviciilor cloud și managementul vulnerabilităților se consolidează reciproc.

Clarysec adaugă frecvent practici de sprijin în jurul acestor ancore: ISO/IEC 27005 pentru disciplina evaluării și tratamentului riscurilor, ISO/IEC 27017 pentru guvernanța securității serviciilor cloud, ISO/IEC 27018 atunci când serviciile cloud prelucrează PII, ISO/IEC 27701 pentru managementul informațiilor privind confidențialitatea și ISO 22301 acolo unde continuitatea și răspunsul la criză sunt relevante.

Dovezile de politică ce impun deja controlul ciclului de viață DNS

Multe organizații au deja politici care, dacă ar fi implementate corect, ar preveni DNS orfan. Lacuna este că managementul ciclului de viață DNS nu este conectat explicit la aceste politici.

Asset Management Policy-sme Asset Management Policy-sme - SME de la Clarysec, Cerințe de implementare a politicii, clauza 6.6.1, prevede:

Activele din medii cloud (de exemplu, conturi de stocare, platforme SaaS, domenii web) trebuie incluse și ele în inventar.

Aceeași politică adaugă în clauza 6.6.2:

Proprietatea, scopul, privilegiile de acces și termenele de reînnoire trebuie documentate.

Pentru guvernanța DNS orfan, aceasta înseamnă că fiecare subdomeniu de producție și fiecare subdomeniu semnificativ care nu este de producție trebuie să aibă un proprietar nominal, un scop de business, un serviciu asociat, un model de acces și o dată de revizuire.

Cel mai important, clauza 6.6.3 prevede:

Serviciile expirate sau neutilizate trebuie dezactivate și eliminate din inventar.

Pentru DNS, acest lucru trebuie interpretat cu atenție. Eliminarea serviciului din inventar nu este suficientă. Înregistrarea DNS, asocierea cloud, revendicarea domeniului personalizat SaaS, certificatul, regula WAF, configurația CDN și intrarea de monitorizare trebuie, de asemenea, revizuite.

Versiunea enterprise consolidează acest concept mai larg de activ. Asset Management Policy Asset Management Policy de la Clarysec, Domeniu de aplicare, clauza 2.2.5, prevede:

Active logice: nume de domenii, licențe, conturi de utilizator, configurații de referință

Numele de domenii și configurațiile nu sunt detalii administrative. Sunt active purtătoare de încredere, care pot deveni căi de atac.

Legătura cu controlul schimbărilor este la fel de importantă. Change Management Policy Change Management Policy de la Clarysec, Scop, clauza 1.1, prevede:

Această politică stabilește un cadru formal pentru inițierea, evaluarea, aprobarea, implementarea și revizuirea schimbărilor aduse sistemelor informatice, infrastructurii, aplicațiilor și proceselor conexe ale organizației.

Prin urmare, eliminarea unei înregistrări DNS, încetarea unui serviciu SaaS, ștergerea unei aplicații cloud, migrarea unui CDN sau retragerea unui microsite de marketing trebuie să genereze dovezi de schimbare. Lipsa unui tichet de schimbare este adesea primul semnal de alarmă în audit.

Guvernanța cloud trebuie conectată, de asemenea. Cloud Usage Policy Cloud Usage Policy de la Clarysec, Cerințe de guvernanță, clauza 5.5, prevede:

Echipa de securitate a informațiilor trebuie să evalueze periodic traficul de rețea, activitatea DNS și jurnalele pentru a detecta utilizarea neautorizată a serviciilor cloud (shadow IT). Încălcările detectate trebuie investigate prompt.

Pentru prevenirea preluării subdomeniilor, monitorizarea activității DNS nu vizează doar shadow IT. Ea vizează și IT-ul perimat, adică active care au fost cândva autorizate, dar nu mai sunt controlate.

Un flux practic Clarysec pentru guvernanța DNS orfan

Un program solid pentru DNS orfan nu este complicat. Este disciplinat, repetabil și conectat la SMSI, managementul vulnerabilităților, managementul schimbărilor și ciclul de viață al furnizorilor.

Pentru IMM-uri, acest lucru poate începe ca un registru simplificat. Pentru organizațiile enterprise, de regulă integrează exporturi DNS, managementul suprafeței externe de atac, inventare ale activelor cloud, înregistrări CMDB, scanere de vulnerabilitate, alerte SIEM și sisteme de ticketing.

Întrebarea de guvernanță rămâne aceeași: puteți demonstra că fiecare subdomeniu accesibil din exterior este cunoscut, are un proprietar, este monitorizat și poate fi eliminat printr-un proces controlat?

Subdomeniul de campanie abandonat, gestionat corect

Revenim la incidentul de luni. promo.company.com indică un site de campanie SaaS abandonat.

Mai întâi, responsabilul cu securitatea creează o înregistrare de vulnerabilitate deoarece activul este expus extern. Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy de la Clarysec, Cerințe de implementare a politicii, clauza 6.1.1, prevede:

Toate sistemele trebuie scanate cel puțin lunar; activele cu risc ridicat sau expuse extern trebuie scanate săptămânal.

Pentru IMM-uri, politica echivalentă clarifică prioritizarea. Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, Cerințe de implementare a politicii, clauza 6.5.1, prevede:

Sistemele care prelucrează date cu caracter personal, oferă acces la distanță sau sunt expuse extern trebuie prioritizate pentru scanare și actualizări

În al doilea rând, proprietarul este identificat prin registrul activelor. Dacă proprietarul este necunoscut, aceasta devine o deficiență de control față de guvernanța activelor. Registrul este actualizat pentru a include numele DNS, furnizorul-țintă, proprietarul inițial de business, clasificarea datelor, furnizorul și starea.

În al treilea rând, IT verifică platforma cloud sau SaaS. Dacă respectivul cont cloud a fost șters, Cloud Usage Policy-sme Cloud Usage Policy-sme - SME de la Clarysec, Cerințe de implementare a politicii, clauza 6.3.6, este direct relevantă:

Conturile cloud șterse trebuie revizuite de furnizorul IT sau de Directorul general pentru acces rezidual, date orfane sau conținut omis.

În al patrulea rând, proprietarul schimbării deschide un tichet de schimbare de urgență sau accelerată pentru eliminarea înregistrării DNS ori revendicarea temporară a resursei înainte de eliminare. Tichetul include evaluarea impactului, planul de revenire, aprobările, dovezile de implementare și validarea post-schimbare.

În al cincilea rând, responsabilul pentru confidențialitate evaluează dacă subdomeniul a prelucrat sau ar fi putut expune date cu caracter personal. PII Security and Access Control Policy PII Security and Access Control Policy de la Clarysec, Configurare securizată și managementul vulnerabilităților, clauza 4.7.4, prevede:

[Ambele] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să înregistreze acoperirea evaluării vulnerabilităților pentru sistemele care prelucrează PII în REG12 cel puțin trimestrial și după o schimbare tehnică semnificativă.

Clauza 4.7.5 adaugă:

[Ambele] Responsabilul cu securitatea informațiilor TREBUIE să înregistreze vulnerabilitățile nerezolvate cu risc ridicat care afectează PII în REG12 în termen de cinci zile lucrătoare de la validare.

Aceste clauze se aplică indiferent dacă organizația acționează ca operator sau persoană împuternicită, deoarece sunt etichetate [Ambele]. Pentru o problemă de DNS orfan care implică PII, dovezile nu trebuie să rămână doar într-un tichet tehnic. Ele trebuie reflectate în registrul de dovezi privind vulnerabilitățile PII.

În al șaselea rând, dacă o agenție sau un furnizor SaaS a găzduit campania, Achizițiile verifică înregistrările privind terții. Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy de la Clarysec, Identificarea și clasificarea relațiilor, clauza 4.1.2, prevede:

[Toate] Proprietarul de proces / Proprietarul de business TREBUIE să identifice fiecare relație propusă cu un terț care va prelucra, accesa, primi, stoca, transmite, susține sau afecta în alt mod PII în REG08 înainte de achiziție, integrare, reînnoire sau schimbare semnificativă privind confidențialitatea la nivelul terțului.

Clauza 4.5.5 cere:

[Ambele] Proprietarul furnizorului / achiziției TREBUIE să înregistreze locațiile de prelucrare, locațiile de găzduire și indicatorii de transfer internațional în REG08 și să lege dovezile de transfer aplicabile la REG09 înainte de aprobarea unei persoane împuternicite, a unei persoane subîmputernicite, a unei schimbări de locație sau a unei schimbări de serviciu relevante pentru transfer.

În final, responsabilul de conformitate pregătește pachetul de dovezi. Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy de la Clarysec, Obiective, clauza 3.4, prevede că unul dintre obiective este:

Generarea de dovezi defensabile și a unei piste de audit pentru susținerea solicitărilor autorităților de reglementare, procedurilor juridice sau cererilor clienților privind asigurarea controalelor.

Acesta este rezultatul de care CISO are nevoie atunci când un client, o autoritate de reglementare sau un auditor întreabă: „De unde știți că acest lucru nu se va repeta?”.

Unde se încadrează Zenith Blueprint

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint de la Clarysec transformă controalele în practici operaționale pregătite pentru audit. DNS orfan se mapează puternic la patru zone.

În faza Controls in Action, Pasul 22 acoperă controalele organizaționale 5.1 la 5.18, inclusiv controlul 5.9 din ISO/IEC 27002:2022. Zenith Blueprint afirmă:

Nicio organizație nu poate proteja ceea ce nu știe că deține. Controlul 5.9 formalizează acest principiu fundamental, cerând stabilirea și menținerea unui inventar actualizat al tuturor informațiilor și activelor asociate relevante pentru SMSI.

Continuă astfel:

În forma sa cea mai strategică, un inventar al activelor servește drept sistemul nervos central al SMSI.

Inventarul subdomeniilor nu este o listă secundară. El alimentează deciziile de acces, scanarea vulnerabilităților, jurnalizarea, managementul furnizorilor, maparea confidențialității și răspunsul la incidente.

În Pasul 20, Zenith Blueprint acoperă controalele tehnologice 8.18 la 8.26. Pentru controlul 8.21, Securitatea serviciilor de rețea, acesta instruiește organizațiile să valideze securitatea serviciilor de rețea:

Listați toate serviciile de rețea interne și externe (DNS, VPN, SMTP, DHCP, gateway-uri API etc.).

De aceea, furnizorii DNS, registrarii, DNS cloud, platformele CDN și funcțiile SaaS de domenii personalizate trebuie incluse în registrul serviciilor.

În Pasul 19, Zenith Blueprint acoperă controalele tehnologice 8.1 la 8.17. Pentru controlul 8.8, acesta afirmă:

Gestionarea vulnerabilităților este una dintre cele mai critice zone ale igienei cibernetice moderne. Deși firewall-urile și instrumentele antivirus oferă protecție, acestea pot fi subminate dacă sistemele neactualizate sau serviciile configurate greșit rămân expuse.

O înregistrare DNS orfană este o cale externă către un serviciu configurat greșit. Chiar și atunci când nu există CVE, ea trebuie gestionată prin managementul vulnerabilităților: validare, scorare, atribuire, remediere, retestare și închidere.

În Pasul 23, Zenith Blueprint abordează controalele organizaționale 5.19 la 5.37. Pentru controlul 5.23, acesta recomandă:

Listați toate serviciile cloud utilizate în prezent (5.23), inclusiv shadow IT acolo unde este cunoscut. Identificați cine le-a aprobat și dacă a fost efectuată verificarea prealabilă. Dezvoltați o listă de verificare simplificată pentru evaluare, care să acopere locația datelor, modelul de acces, jurnalizarea și criptarea.

Pentru prevenirea preluării subdomeniilor, adăugați domeniile personalizate, dependențele DNS, proprietarul dezafectării și dovezile de ieșire în acea listă de verificare pentru evaluarea serviciilor cloud.

Maparea la NIS2, DORA și GDPR

NIS2 transformă guvernanța DNS orfan într-un subiect la nivelul organului de conducere pentru multe entități esențiale și importante. Articolul 20 cere organelor de conducere să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire în domeniul securității cibernetice. Articolul 21 cere măsuri tehnice, operaționale și organizaționale adecvate și proporționale, folosind o abordare bazată pe toate riscurile. Ariile sale minime includ analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția, dezvoltarea și mentenanța securizate, gestionarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, instruirea, controlul accesului și managementul activelor.

Un program pentru DNS orfan se mapează direct la aceste arii. Articolul 21(3) cere, de asemenea, ca securitatea lanțului de aprovizionare să ia în considerare vulnerabilitățile specifice fiecărui furnizor direct sau prestator de servicii. Dacă o agenție de marketing, un furnizor SaaS, un furnizor de găzduire administrată sau o platformă cloud administrează domenii personalizate, controalele specifice furnizorului trebuie să acopere proprietatea DNS, ieșirea din serviciu, suportul pentru incidente și predarea dovezilor.

Articolul 23 devine relevant dacă preluarea are loc sau este capabilă să provoace perturbări operaționale severe, pierderi financiare ori prejudicii materiale sau nemateriale considerabile. NIS2 utilizează raportare etapizată: avertizare timpurie în termen de 24 de ore de la luarea la cunoștință a unui incident semnificativ, notificare în termen de 72 de ore, rapoarte intermediare la cerere și un raport final în termen de o lună de la notificarea incidentului.

Pentru entitățile financiare, DORA este regimul sectorial specific de reziliență operațională digitală. Articolele 5 și 6 cer un cadru intern de guvernanță și control pentru managementul riscurilor TIC, cu responsabilitate finală a organului de conducere, roluri TIC clare, politici privind disponibilitatea, autenticitatea, integritatea și confidențialitatea datelor, planuri de audit, resurse, politică privind serviciile furnizate de terți și un cadru documentat de management al riscurilor TIC.

Articolele 8 la 14 formează nucleul operațional. Articolul 8 cere identificarea, clasificarea și documentarea funcțiilor de business susținute de TIC, a activelor informaționale, a activelor TIC, a dependențelor, a interconectărilor cu terți TIC, a inventarelor, a scenariilor de risc și a sistemelor moștenite. Un CNAME orfan este adesea o dependență omisă. Articolul 9 cere protecție și prevenire. Articolul 10 cere detectarea activității anormale, a incidentelor TIC și a potențialelor puncte unice de eșec. Articolele 11 și 12 abordează continuitatea, recuperarea, backup-ul și restaurarea. Articolul 13 cere învățare din vulnerabilități, amenințări, incidente și teste.

Articolele 17 la 19 formalizează gestionarea incidentelor, clasificarea și raportarea. Articolele 28 la 30 fac ca riscul asociat terților TIC să fie gestionat pe întreg ciclul de viață. Entitățile financiare rămân pe deplin responsabile atunci când utilizează furnizori de servicii TIC. Pentru pregătirea DORA, Clarysec recomandă adăugarea a patru câmpuri în fiecare registru DNS și de servicii cloud: susținerea unei funcții critice sau importante, furnizorul terț TIC, referința la contract sau registru și starea testului de ieșire.

GDPR se aplică atunci când problema implică date cu caracter personal. Preluarea unui subdomeniu nu este automat o încălcare a securității datelor cu caracter personal, dar poate deveni una dacă subdomeniul afectat colectează credențiale, captează date din formulare, uzurpă identitatea unui serviciu, expune identificatori ai utilizatorilor sau permite acces neautorizat la date cu caracter personal. Articolul 5 din GDPR cere integritate, confidențialitate și responsabilitate. Articolul 32 cere securitatea adecvată a prelucrării. Articolul 33 poate impune notificarea autorității de supraveghere dacă o încălcare a securității datelor cu caracter personal este susceptibilă să genereze un risc pentru drepturile și libertățile persoanelor fizice.

PII Incident and Breach Management Policy PII Incident and Breach Management Policy de la Clarysec, Clasificare și evaluarea încălcării securității datelor, clauza 4.2.6, susține această analiză a criteriilor de raportare în mai multe regimuri:

[Condițional] Responsabilul pentru confidențialitate / Managerul PIMS TREBUIE să evalueze criteriile de raportare legale, sectoriale, specifice sectorului financiar, de securitate cibernetică, contractuale, ale clienților și ale destinatarilor serviciului aplicabile pentru fiecare incident PII cu impact ridicat și să înregistreze rezultatul privind aplicabilitatea în REG01, REG08 și REG10.

Această înregistrare a deciziei este exact ceea ce este necesar atunci când preluarea unui subdomeniu ar putea implica GDPR, NIS2, DORA, contracte și notificarea clienților.

Cum vă vor testa auditorii dovezile

Un SMSI integrat trebuie să vă permită să răspundeți auditorilor diferiți folosind aceeași bază de dovezi. Formularea întrebării se schimbă, dar dovada este adesea aceeași.

O perspectivă mai largă de asigurare include frecvent NIST CSF 2.0 și COBIT 2019. NIST CSF 2.0 ajută la exprimarea stării-țintă prin rezultatele GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER. Un Profil curent poate arăta revizuiri DNS trimestriale manuale și încetarea neuniformă a serviciilor SaaS. Un Profil țintă poate impune verificări săptămânale automatizate pentru preluarea subdomeniilor, atribuirea obligatorie a proprietarilor, dovezi de ieșire de la furnizori și integrarea cu managementul schimbărilor.

Un auditor orientat COBIT 2019 sau ISACA va întreba, de regulă, cine deține procesul, cum este evaluat și direcționat riscul, dacă schimbările sunt controlate, dacă furnizorii sunt gestionați, dacă activele și configurațiile sunt fiabile și dacă dovezile de asigurare susțin raportarea către management. Este posibil să nu ceară mai întâi o listă de CNAME-uri. Poate întreba cum știe managementul că serviciile digitale externe sunt controlate pe întreg ciclul lor de viață.

Cum arată dovezile de audit bune

Un pachet de audit pentru DNS orfan trebuie să fie suficient de compact pentru a fi menținut, dar suficient de complet pentru a susține concluziile. Clarysec recomandă, de regulă, următorul set de dovezi:

• Inventar al zonelor DNS cu sursa, data, tipul înregistrării, ținta și proprietarul.
• Rezultate ale scanării suprafeței externe de atac care arată verificările de preluare.
• Înregistrări în registrul activelor pentru domenii, subdomenii, servicii cloud, aplicații SaaS și CDN-uri.
• Registru al serviciilor care indică responsabilitatea internă sau a furnizorului.
• Tichete de schimbare pentru crearea, modificarea și ștergerea înregistrărilor DNS.
• Liste de verificare pentru integrarea serviciilor cloud și SaaS, incluzând domeniul personalizat și revizuirea DNS.
• Contracte cu furnizorii sau clauze de securitate care acoperă DNS, găzduirea, suportul pentru incidente și ieșirea.
• Tichete de vulnerabilitate cu severitate, proprietar, dată de remediere și dovezi de retestare.
• Evaluare PII atunci când subdomeniul prelucrează sau a prelucrat anterior date cu caracter personal.
• Înregistrări de clasificare a incidentelor pentru preluări suspectate sau confirmate.
• Lecții învățate și proceduri actualizate după constatări.

Metricile contează, de asemenea. Managementul trebuie să vadă numărul de subdomenii externe, procentul cu proprietari atribuiți, numărul de constatări DNS orfan, timpul mediu de remediere, constatările cu risc ridicat restante, subdomeniile găzduite de furnizori fără referință contractuală curentă și procentul ieșirilor din cloud cu dovezi de eliminare DNS.

Aceste metrici transformă igiena tehnică în dovezi de supraveghere managerială.

Tipare frecvente de eșec identificate de Clarysec

La clienți din SaaS, fintech, tehnologie medicală, servicii administrate și e-commerce, aceleași tipare reapar.

În primul rând, proprietatea DNS este împărțită între echipe. Ingineria deține cloud-ul. Marketingul deține campaniile. IT deține accesul la furnizorul DNS. Achizițiile dețin încetarea serviciilor SaaS. Nimeni nu deține întregul ciclu de viață.

În al doilea rând, ștergerea din cloud este tratată ca sfârșitul serviciului. În realitate, DNS, certificatele, regulile WAF, monitorizarea, secretele, documentația și înregistrările privind furnizorii pot rămâne.

În al treilea rând, scanerele de vulnerabilitate se concentrează pe gazde active, dar ratează condițiile de preluare specifice furnizorilor. Organizațiile au nevoie de verificări ale suprafeței externe de atac care înțeleg stările de eroare comune din SaaS și cloud.

În al patrulea rând, procedurile de ieșire a furnizorilor se concentrează pe facturi și returnarea datelor, nu pe domenii personalizate, înregistrări DNS și modificări privind persoanele subîmputernicite.

În al cincilea rând, echipele de confidențialitate sunt notificate prea târziu. Dacă un subdomeniu a prelucrat PII, DPO sau responsabilul pentru confidențialitate trebuie să participe la clasificare înainte de formularea presupunerilor.

În al șaselea rând, dovezile există, dar sunt dispersate. Exportul DNS este într-un instrument, tichetele de schimbare în altul, contractele cu furnizorii în Achiziții, rapoartele de vulnerabilitate în scanere, iar analiza de confidențialitate în e-mail. Auditorii văd fragmentarea ca o slăbiciune.

Setul de instrumente Clarysec rezolvă această problemă prin conectarea politicilor, registrelor, controalelor și fluxurilor de dovezi.

Un plan de acțiune de 30 de zile pentru guvernanța DNS

Dacă ați găsit o înregistrare DNS orfană, presupuneți că există și altele. Dacă nu ați găsit niciuna, asigurați-vă că puteți demonstra de ce.

Începeți cu acest plan de 30 de zile:

1. Exportați toate zonele DNS autoritative.
2. Identificați înregistrările CNAME, ALIAS, A și AAAA care indică servicii cloud, SaaS, CDN și servicii administrate de agenții.
3. Atribuiți proprietari și scopuri de business.
4. Rulați verificări de preluare și validați manual înregistrările suspecte.
5. Creați tichete de vulnerabilitate pentru riscurile confirmate.
6. Eliminați sau revendicați înregistrările expuse prin controlul schimbărilor.
7. Actualizați registrul activelor, registrul cloud și registrul furnizorilor.
8. Revizuiți dacă vreun subdomeniu afectat a prelucrat PII.
9. Adăugați verificări ale ciclului de viață DNS la integrarea cloud, achiziția SaaS și ieșirea furnizorilor.
10. Raportați metricile către management.

Remedierea tehnică pentru DNS orfan este adesea simplă. Remedierea de guvernanță este cea care previne următoarea preluare.

Clarysec vă poate ajuta să operaționalizați acest lucru folosind Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls și setul nostru de politici pentru managementul activelor, utilizarea serviciilor cloud, managementul vulnerabilităților, guvernanța furnizorilor, securitatea PII, răspunsul la incidente și dovezile de audit.

Dacă doriți o abordare pregătită pentru audit, Clarysec vă poate ajuta să construiți pachetul de dovezi privind expunerea DNS și cloud, să îl mapați la ISO/IEC 27001:2022, NIS2, DORA și GDPR și să transformați subdomeniile uitate în active controlate, cu proprietar desemnat și monitorizate. Descărcați setul de instrumente Clarysec relevant, solicitați un demo sau programați o evaluare a guvernanței DNS înainte ca un tester de penetrare, un auditor sau un atacator să găsească următorul pointer uitat.