CVD pentru NIS2 și DORA: harta dovezilor ISO 27001

La ora 08:17, într-o zi de marți, căsuța poștală de securitate primește un mesaj de la un cercetător independent. Subiectul este calm, aproape politicos: „Posibilă preluare a contului în portalul dvs. pentru clienți”. Conținutul mesajului este mai puțin confortabil. Cercetătorul susține că o vulnerabilitate înlănțuită în aplicația SaaS permite unui tenant să acceseze înregistrările de facturare ale altui tenant. Este atașată o dovadă de concept, criptată cu cheia publică PGP publicată de organizație.

Pentru Maria, noul Director al securității informației al FinanTechSaaS, momentul nu putea fi mai nepotrivit. Compania tocmai a semnat un contract major cu o bancă de prim rang din UE. Echipa de verificare prealabilă a clientului a solicitat deja o „Politică privind divulgarea coordonată a vulnerabilităților” și dovezi de implementare, cu referire explicită la NIS2 și DORA. Compania are o adresă de e-mail security@, dar aceasta este monitorizată de un singur dezvoltator. Nu există un registru formal de preluare, nu există un SLA definit pentru validare, nu există o cale de escaladare către management și nu există pistă de audit.

Trei cronometre pornesc simultan.

Primul este operațional. Vulnerabilitatea este reală? Poate fi exploatată în producție? O exploatează cineva în mod activ?

Al doilea este de reglementare. Dacă sunt expuse date ale clienților, începe evaluarea încălcării conform GDPR. Dacă livrarea serviciului este afectată pentru o entitate esențială sau importantă în sensul NIS2, pot fi declanșate pragurile de raportare a incidentelor. Dacă organizația este o entitate financiară sau un furnizor TIC care susține servicii financiare, regulile DORA privind gestionarea incidentelor, clasificarea, escaladarea și comunicarea către clienți pot deveni relevante.

Al treilea este probatoriu. Peste șase luni, un auditor ISO/IEC 27001:2022, un supraveghetor din sectorul financiar, o echipă de asigurare solicitată de clienți sau comitetul intern de audit poate întreba: „Arătați-ne cum a fost gestionată această vulnerabilitate.”

În acest punct, multe organizații descoperă că divulgarea coordonată a vulnerabilităților nu înseamnă doar o căsuță poștală de securitate. Este un sistem de guvernanță. Are nevoie de responsabilitate clară pentru politică, un canal public de raportare, un flux de triaj, SLA-uri de remediere, escaladare către furnizori, logică de decizie privind incidentele, analiză de confidențialitate, raportare către management și dovezi care pot fi susținute în audit.

Clarysec tratează CVD ca pe un model integrat de control, nu ca pe un inbox separat. În Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, gestionarea vulnerabilităților apare în faza Controale în acțiune, Pasul 19: Controale tehnologice I, unde îndrumarea este clară: organizațiile nu trebuie să arhiveze pasiv constatările privind vulnerabilitățile, ci să le triajeze, să le atribuie și să le urmărească până la închidere. Același standard se aplică divulgărilor externe. Dacă cineva vă arată cum poate eșua serviciul dvs., întrebarea reală devine: puteți demonstra că ați primit, evaluat, prioritizat, remediat, comunicat și valorificat lecțiile rezultate din acest raport?

De ce CVD este acum o temă la nivelul consiliului de administrație conform NIS2 și DORA

Ani la rând, organizațiile mature din punct de vedere al securității au invitat hackerii etici să raporteze vulnerabilități deoarece era o bună practică. În cadrul NIS2 și DORA, această practică a devenit parte din reziliența digitală reglementată.

NIS2 se aplică multor entități mijlocii și mari din sectoare cu criticitate ridicată și din alte sectoare critice, inclusiv furnizorilor de infrastructură digitală, furnizorilor de servicii de cloud computing, furnizorilor de servicii de centre de date, furnizorilor de servicii administrate, furnizorilor de servicii de securitate administrate și anumitor furnizori digitali, cum ar fi piețele online, motoarele de căutare și platformele de socializare. De asemenea, se poate aplica, indiferent de dimensiune, unor categorii precum prestatorii de servicii de încredere, furnizorii de servicii DNS, registrele TLD și furnizorii de rețele sau servicii publice de comunicații electronice.

NIS2 Article 21 impune entităților esențiale și importante să implementeze măsuri tehnice, operaționale și organizaționale adecvate și proporționale de management al riscurilor de securitate cibernetică, folosind o abordare bazată pe toate riscurile. Unul dintre domeniile minime este securitatea în achiziția, dezvoltarea și mentenanța sistemelor de rețea și informații, inclusiv gestionarea și divulgarea vulnerabilităților. Aceeași bază acoperă și gestionarea incidentelor, securitatea lanțului de aprovizionare, continuitatea activității, controlul accesului, managementul activelor, instruirea, criptografia și procedurile de evaluare a eficacității controalelor.

NIS2 Article 20 face explicită și responsabilitatea managementului. Organele de conducere trebuie să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea și să urmeze instruire. Pentru un program CVD, aceasta înseamnă că membrii consiliului sau conducerea superioară trebuie să înțeleagă canalul de raportare, Echipa de răspuns la vulnerabilități, termenele de validare, așteptările privind remedierea, dependențele față de furnizori și declanșatorii de raportare a incidentelor.

DORA creează, începând cu 17 ianuarie 2025, un regim sectorial pentru entitățile financiare. Acesta acoperă managementul riscurilor TIC, raportarea incidentelor legate de TIC, testarea rezilienței operaționale digitale, schimbul de informații, riscul asociat terților TIC, cerințele contractuale, supravegherea furnizorilor terți critici de servicii TIC și cooperarea cu autoritățile de supraveghere. Pentru entitățile financiare acoperite de DORA, DORA prevalează în general asupra NIS2 pentru managementul riscurilor TIC și raportarea incidentelor, deoarece este actul juridic al Uniunii cu caracter sectorial. Cerința practică rămâne însă aceeași: entitățile financiare și furnizorii TIC care le deservesc trebuie să opereze un proces structurat, documentat și testabil pentru identificarea, analizarea, clasificarea, escaladarea, remedierea și valorificarea lecțiilor din punctele slabe TIC.

Un raport de vulnerabilitate poate începe ca o constatare tehnică, poate deveni un eveniment de securitate, poate escalada într-un incident, poate declanșa o evaluare a încălcării securității datelor cu caracter personal conform GDPR, poate necesita acțiuni din partea furnizorului și poate apărea ulterior în Declarația de aplicabilitate ISO/IEC 27001:2022. De aceea, CVD trebuie proiectat ca model operațional unic pentru securitate, conformitate, inginerie, juridic, confidențialitate, achiziții și management.

Fundamentul ISO 27001: de la divulgare la dovezi SMSI

ISO/IEC 27001:2022 oferă directorilor CISO și liderilor de conformitate sistemul de management care face CVD verificabil prin audit.

Clauzele 4.1-4.4 impun organizației să înțeleagă aspectele interne și externe, cerințele părților interesate, limitele SMSI și dependențele față de alte organizații. Aici intră în SMSI NIS2, DORA, GDPR, contractele cu clienții, obligațiile furnizorilor și angajamentele privind divulgarea vulnerabilităților.

Clauzele 5.1-5.3 stabilesc responsabilitatea conducerii. Conducerea de vârf trebuie să alinieze securitatea informației la direcția strategică, să asigure resurse, să atribuie responsabilități și să se asigure că SMSI obține rezultatele urmărite. Pentru CVD, aceasta înseamnă desemnarea unei Echipe de răspuns la vulnerabilități, definirea autorității de a accepta riscul rezidual și escaladarea vulnerabilităților cu impact ridicat către management.

Clauzele 6.1.1-6.1.3 oferă mecanismul de risc. Organizația trebuie să definească criterii de risc, să evalueze riscurile de securitate a informației, să atribuie proprietari de risc, să selecteze opțiuni de tratare a riscurilor, să compare controalele cu Anexa A, să producă o Declarație de aplicabilitate și să obțină aprobarea riscului rezidual. Clauzele 8.1-8.3 impun apoi control operațional, modificări planificate, controlul proceselor furnizate extern, evaluări ale riscurilor la intervale planificate sau după schimbări semnificative și dovezi ale rezultatelor tratării riscurilor.

În Zenith Blueprint, faza Managementul riscurilor, Pasul 13, Declarația de aplicabilitate este descrisă ca mai mult decât un tabel de conformitate:

„SoA este, în fapt, un document de legătură: conectează evaluarea/tratamentul riscurilor cu controalele reale pe care le aveți.”
Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Managementul riscurilor, Pasul 13: Planificarea tratării riscurilor și Declarația de aplicabilitate (SoA) Zenith Blueprint

Pentru divulgarea coordonată a vulnerabilităților, SoA trebuie să conecteze obligațiile de reglementare, riscul pentru organizație, controalele din Anexa A, clauzele de politică și dovezile operaționale.

Scopul nu este crearea unor silozuri paralele de conformitate. Politica CVD trebuie să fie un proces controlat al SMSI, care susține simultan certificarea ISO/IEC 27001:2022, conformitatea cu NIS2, pregătirea pentru DORA, asigurarea solicitată de clienți și operațiunile de securitate.

Baza politicii: ce trebuie să prevadă politica CVD

Primul control vizibil este canalul public de divulgare. Cercetătorii, clienții, furnizorii și partenerii trebuie să știe unde pot raporta vulnerabilități și cum pot proteja dovezile sensibile.

Politica privind divulgarea coordonată a vulnerabilităților Clarysec Politica privind divulgarea coordonată a vulnerabilităților oferă baza pentru mediile enterprise:

„Canale publice de divulgare: organizația trebuie să mențină un canal clar pentru raportarea vulnerabilităților, cum ar fi o adresă de e-mail dedicată pentru contactul de securitate (de exemplu, security@company.com) sau un formular web. Aceste informații trebuie publicate pe pagina de securitate a site-ului companiei, împreună cu cheia publică PGP a organizației, pentru a permite transmiterea criptată.”
Sursă: Politica privind divulgarea coordonată a vulnerabilităților, Cerințe de implementare, clauza 6.1

Această clauză rezolvă un eșec frecvent în audit. Multe organizații afirmă că acceptă rapoarte, dar ruta de raportare este greu de găsit, necriptată sau deținută de echipa greșită. Un canal matur este public, securizat, monitorizat și atribuit unei funcții responsabile.

Următorul control este disciplina răspunsului. Un raport critic urmat de tăcere creează risc de divulgare, risc reputațional și risc de exploatare. Politica privind divulgarea coordonată a vulnerabilităților stabilește o așteptare concretă privind confirmarea și validarea:

„Triaj și confirmare: la primirea unui raport, VRT trebuie să îl înregistreze și să trimită o confirmare raportorului în termen de 2 zile lucrătoare, alocând o referință de urmărire. VRT trebuie să efectueze o evaluare preliminară a severității, de exemplu folosind scorarea CVSS, și să valideze problema, inclusiv cu sprijinul echipelor IT și de dezvoltare atunci când este necesar, într-un termen-țintă de 5 zile lucrătoare. Vulnerabilitățile critice, cum ar fi cele care permit executarea de cod la distanță sau o încălcare majoră a securității datelor, trebuie accelerate.”
Sursă: Politica privind divulgarea coordonată a vulnerabilităților, Cerințe de implementare, clauza 6.4

Această formulare creează puncte imediate de dovadă: ora primirii, ora confirmării, referința de urmărire, severitatea preliminară, rezultatul validării și decizia de tratare accelerată.

Pentru IMM-uri, Clarysec folosește aceeași logică, cu implementare proporțională. Politica privind cerințele de securitate a aplicațiilor - IMM Politica privind cerințele de securitate a aplicațiilor - IMM impune organizațiilor să:

„specifice obligații pentru divulgarea vulnerabilităților, timpii de răspuns și aplicarea patch-urilor.”
Sursă: Politica privind cerințele de securitate a aplicațiilor - IMM, Cerințe de guvernanță, clauza 5.3.2

Nu aveți nevoie de o echipă mare de securitate a produsului pentru a fi responsabili. Aveți nevoie de obligații explicite, termene realiste, proprietari desemnați și dovezi că procesul funcționează.

Fluxul de preluare CVD: de la e-mailul cercetătorului la înregistrarea deciziei

Un flux bun de preluare este suficient de simplu pentru a funcționa sub presiune și suficient de complet pentru a satisface un auditor. Trebuie să înceapă cu un canal dedicat, cum ar fi security@[company], un formular web sau un fișier security.txt publicat. Ruta de transmitere trebuie să permită dovezi criptate, produsul sau endpoint-ul afectat, pașii de reproducere, datele de contact ale raportorului, momentul preferat al divulgării și orice indiciu de expunere a datelor sau exploatare activă.

După primire, Echipa de răspuns la vulnerabilități trebuie să creeze o înregistrare într-un instrument GRC, o platformă de ticketing, un sistem de management al vulnerabilităților sau un registru controlat. Instrumentul contează mai puțin decât consecvența și calitatea dovezilor.

Fluxul de lucru trebuie să parcurgă apoi șapte pași operaționali.

1. Preluare: raportul este primit prin canalul public și jurnalizat automat sau manual.
2. Confirmare: VRT răspunde în termen de 2 zile lucrătoare și alocă o referință de urmărire.
3. Validare: echipa tehnică reproduce problema, confirmă sistemele afectate și efectuează scorarea preliminară a severității.
4. Evaluarea evenimentului: VRT stabilește dacă vulnerabilitatea este doar un punct slab, un eveniment de securitate a informațiilor sau un incident.
5. Escaladare: problemele cu severitate ridicată sau critică sunt transmise proprietarilor de sistem, CISO, funcției de confidențialitate, departamentului juridic, furnizorilor și managementului, după caz.
6. Remediere: echipa responsabilă aplică o remediere, o măsură de atenuare, un control compensatoriu sau o restricție temporară.
7. Închidere: VRT verifică remedierea, comunică cu raportorul, actualizează dosarul de dovezi și înregistrează lecțiile învățate.

Clarysec mapează acest pas operațional la controlul ISO/IEC 27002:2022 A.5.25, Evaluarea și decizia privind evenimentele de securitate a informațiilor, și la controlul A.8.8, Managementul vulnerabilităților tehnice, prin Zenith Controls: The Cross-Compliance Guide Zenith Controls. Pentru A.5.25, Zenith Controls explică faptul că evaluarea evenimentului este funcția de triaj dintre alertele brute de monitorizare și gestionarea formală a incidentelor, folosind jurnale, praguri și criterii de decizie pentru a determina escaladarea. Pentru A.8.8, Zenith Controls conectează managementul vulnerabilităților tehnice cu protecția antimalware, managementul configurației, managementul schimbărilor, securitatea endpoint-urilor, informațiile privind amenințările, monitorizarea, dezvoltarea securizată, evaluarea evenimentelor și răspunsul la incidente.

Un pasaj din Zenith Controls este deosebit de util atunci când se suspectează exploatare activă:

„Informațiile privind amenințările indică vulnerabilitățile exploatate activ și ghidează prioritizarea patch-urilor.”
Sursă: Zenith Controls: The Cross-Compliance Guide, controlul ISO/IEC 27002:2022 8.8, legătură cu controlul 5.7 Informații privind amenințările Zenith Controls

Acesta este un punct important de guvernanță. Severitatea nu înseamnă doar CVSS. O vulnerabilitate cu scor mediu, exploatată activ împotriva sectorului dvs., poate avea prioritate mai mare decât o problemă critică teoretică pe un sistem de test neexpus.

Când o vulnerabilitate devine incident

Nu orice raport de vulnerabilitate este un incident. Un antet de securitate lipsă într-un mediu de staging nu este același lucru cu o eludare exploatată a autorizării care expune facturi ale clienților. Totuși, fiecare raport credibil de vulnerabilitate trebuie să treacă printr-un punct de decizie privind incidentul.

NIS2 Article 23 impune entităților esențiale și importante să notifice fără întârzieri nejustificate CSIRT-ul sau autoritatea competentă cu privire la incidentele care au un impact semnificativ asupra furnizării serviciilor. Un incident semnificativ este cel care a cauzat sau este capabil să cauzeze perturbări operaționale grave ori pierderi financiare sau care a afectat ori este capabil să afecteze alte persoane prin producerea unor prejudicii materiale sau nemateriale considerabile. Secvența de raportare include o avertizare timpurie în termen de 24 de ore de la luarea la cunoștință, o notificare a incidentului în termen de 72 de ore, rapoarte intermediare la cerere și un raport final în termen de o lună de la notificarea de 72 de ore.

DORA Articles 17 to 20 impun entităților financiare să detecteze, să gestioneze, să înregistreze, să clasifice, să escaladeze, să notifice și să comunice incidentele legate de TIC și amenințările cibernetice semnificative. Incidentele majore legate de TIC trebuie escaladate către conducerea superioară și organul de conducere. Comunicarea către clienți poate fi necesară atunci când interesele financiare sunt afectate.

Pentru IMM-uri, cultura raportării trebuie să fie la fel de clară. Politica de răspuns la incidente - IMM Clarysec Politica de răspuns la incidente - IMM precizează:

„Personalul trebuie să raporteze orice activitate suspectă sau incident confirmat la incident@[company] sau verbal către Directorul general ori furnizorul IT.”
Sursă: Politica de răspuns la incidente - IMM, Cerințe de implementare a politicii, clauza 6.2.1

În Zenith Blueprint, faza Controale în acțiune, Pasul 16: Controale privind personalul II, principiul este și mai simplu:

„Când aveți îndoieli, raportați.”
Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controale în acțiune, Pasul 16: Controale privind personalul II (A.6.5 to A.6.8)

Această frază trebuie să se aplice dezvoltatorilor, echipelor de suport, managerilor de furnizori, responsabililor de confidențialitate, executivilor și furnizorilor externalizați. O vulnerabilitate care poate afecta confidențialitatea, integritatea, disponibilitatea, încrederea clienților, raportarea către autorități sau operațiunile financiare trebuie înregistrată și evaluată, nu gestionată informal pe chat.

Remediere, aplicarea patch-urilor și controale compensatorii

După validarea unei vulnerabilități, aceasta trebuie tratată. Tratarea trebuie să fie bazată pe risc, susținută de dovezi și limitată în timp.

Politica privind divulgarea coordonată a vulnerabilităților stabilește așteptarea pentru mediile enterprise:

„Plan de remediere: pentru toate vulnerabilitățile confirmate trebuie elaborat un plan de remediere sau atenuare. Implementarea remedierii trebuie prioritizată în funcție de severitate. De exemplu, vulnerabilitățile critice trebuie remediate sau atenuate în termen de 14 zile atunci când este fezabil, sau mai devreme atunci când este detectată exploatare activă, în timp ce problemele cu severitate mai redusă trebuie tratate într-un termen rezonabil. Atunci când remedierea completă este amânată, trebuie implementate controale compensatorii sau măsuri temporare de atenuare, cum ar fi dezactivarea funcționalității vulnerabile sau creșterea monitorizării.”
Sursă: Politica privind divulgarea coordonată a vulnerabilităților, Cerințe de implementare, clauza 6.6

Pentru disciplina aplicării patch-urilor în IMM-uri, Politica de management al vulnerabilităților și al patch-urilor - IMM Politica de management al vulnerabilităților și al patch-urilor - IMM precizează:

„Patch-urile critice trebuie aplicate în termen de 3 zile de la lansare, în special pentru sistemele expuse la internet”
Sursă: Politica de management al vulnerabilităților și al patch-urilor - IMM, Cerințe de implementare a politicii, clauza 6.1.1

Aceste termene nu sunt contradictorii. Un patch de furnizor pentru un sistem expus la internet poate necesita o implementare foarte rapidă. O vulnerabilitate de produs care necesită modificări de cod, testare de regresie, coordonare cu clienții și lansare etapizată poate necesita un plan de remediere cu măsuri intermediare de atenuare. Esențial este ca decizia să fie documentată, deținută de proprietarul riscului și aprobată atunci când rămâne risc rezidual.

Un flux practic de caz arată astfel:

1. Un cercetător raportează o eludare a autorizării în API-ul de facturare pentru clienți.
2. VRT înregistrează CVD-2026-014 cu marcaj temporal și confirmă primirea în termen de 2 zile lucrătoare.
3. Echipa de securitate a produsului validează defectul în 24 de ore și atribuie severitate ridicată din cauza accesului la date între tenant-uri.
4. Funcția de confidențialitate efectuează o evaluare a încălcării conform GDPR, deoarece înregistrările de facturare pot conține date cu caracter personal.
5. Managerul de incident deschide o evaluare a evenimentului conform controlului ISO/IEC 27002:2022 A.5.25.
6. Proprietarul de sistem dezactivează endpoint-ul vulnerabil printr-un comutator de funcționalitate temporar.
7. Echipa de inginerie creează o remediere urgentă conform controlului ISO/IEC 27002:2022 A.8.32, Managementul schimbărilor.
8. Sunt adăugate reguli de monitorizare pentru indicatori de exploatare, legate de A.8.15, Jurnalizare, și A.8.16, Activități de monitorizare.
9. CISO informează conducerea superioară deoarece problema este cu risc ridicat.
10. VRT coordonează cu cercetătorul retestarea și momentul divulgării.
11. Proprietarul riscului aprobă închiderea numai după testarea de verificare și revizuirea impactului asupra clienților.
12. SoA, Registrul de riscuri, tichetul, jurnalele, notificarea către management și lecțiile învățate sunt actualizate.

Aceasta este diferența dintre „am aplicat patch-ul” și „putem demonstra că am guvernat procesul”.

Dependențe față de furnizori și cloud: punctul ascuns de eșec

Multe eșecuri CVD sunt, de fapt, eșecuri ale furnizorilor. Vulnerabilitatea poate afecta o componentă SaaS, un serviciu cloud, un furnizor de securitate administrată, un gateway de plăți, un broker de autentificare, o bibliotecă open-source, o echipă de dezvoltare externalizată sau un subcontractant.

NIS2 Article 21 impune securitatea lanțului de aprovizionare, inclusiv relațiile cu furnizorii direcți și furnizorii de servicii. Măsurile privind lanțul de aprovizionare trebuie să ia în considerare vulnerabilitățile furnizorilor, calitatea produselor, practicile de securitate cibernetică și procedurile de dezvoltare securizată.

DORA Articles 28 to 30 merg mai departe pentru entitățile financiare. Acestea impun gestionarea riscului asociat terților TIC ca parte a cadrului de risc TIC, cu registre ale contractelor de servicii TIC, distincții privind funcțiile critice sau importante, verificare prealabilă înainte de contractare, cerințe contractuale de securitate, asistență în caz de incidente, cooperare cu autoritățile, drepturi de audit, drepturi de încetare și strategii de ieșire. Entitățile financiare rămân pe deplin responsabile pentru conformitatea cu DORA chiar și atunci când utilizează furnizori terți de servicii TIC.

Politica de securitate privind terții și furnizorii - IMM Clarysec Politica de securitate privind terții și furnizorii - IMM include o regulă simplă de escaladare:

„Trebuie să notifice imediat Directorul general cu privire la orice încălcare a securității, schimbare sau incident”
Sursă: Politica de securitate privind terții și furnizorii - IMM, Roluri și responsabilități, clauza 4.4.3

Pentru contractele cu furnizorii enterprise, Zenith Blueprint, faza Controale în acțiune, Pasul 23, recomandă includerea obligațiilor de confidențialitate, responsabilităților de control al accesului, măsurilor tehnice și organizatorice, termenelor de raportare a incidentelor, dreptului de audit, controalelor asupra subcontractanților și prevederilor de la finalul contractului. Acesta precizează:

„Ceea ce contează este ca acestea să existe și să fie înțelese și acceptate de ambele părți.”
Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controale în acțiune, Pasul 23: Controale organizaționale (5.19 to 5.37)

Pregătirea furnizorilor pentru CVD trebuie să răspundă la aceste întrebări:

• Furnizorul publică un canal de raportare a vulnerabilităților?
• Termenele de notificare a vulnerabilităților sunt definite în contract?
• Vulnerabilitățile critice ale furnizorului sunt raportate fără întârzieri nejustificate?
• Punctele slabe cu impact asupra clienților sunt legate de obligațiile de asistență în caz de incidente?
• Furnizorul poate furniza dovezi de remediere sau informări de securitate?
• Obligațiile privind vulnerabilitățile sunt transmise subcontractanților?
• Există o strategie de ieșire dacă remedierea este inadecvată?

Aici converg NIS2, DORA și ISO/IEC 27001:2022. Managementul vulnerabilităților furnizorilor nu este o bifă de achiziții. Este parte din reziliența operațională.

Maparea dovezilor pentru ISO 27001, NIS2, DORA, GDPR și COBIT

Cele mai solide programe CVD sunt construite pornind de la dovezi. Ele presupun că orice raport semnificativ poate fi ulterior revizuit de auditul intern, auditori de certificare, autorități de reglementare, clienți, asigurători sau un comitet de risc al consiliului.

Politica de audit și monitorizare a conformității - IMM Clarysec Politica de audit și monitorizare a conformității - IMM surprinde un detaliu pe care multe echipe îl ratează:

„Metadatele (de exemplu, cine le-a colectat, când și din ce sistem) trebuie documentate.”
Sursă: Politica de audit și monitorizare a conformității - IMM, Cerințe de implementare a politicii, clauza 6.2.3

O captură de ecran a unui server pe care s-a aplicat patch-ul este o dovadă slabă dacă nimeni nu știe cine a realizat-o, când, din ce sistem și cum se mapează la vulnerabilitate. Un tichet cu marcaje temporale, rezultate de scanare, pull request, aprobare de schimbare, jurnale de implementare, interogare de monitorizare, confirmare de retestare și metadate este mult mai puternic.

O matrice de trasabilitate mai detaliată ajută în verificarea prealabilă realizată de clienți și în auditul intern.

Auditorii diferiți vor testa același proces prin lentile diferite.

Un auditor ISO/IEC 27001:2022 va începe cu SMSI. Va întreba dacă obligațiile privind divulgarea vulnerabilităților sunt incluse în cerințele părților interesate, dacă riscurile sunt evaluate consecvent, dacă controalele apar în SoA, dacă există dovezi operaționale și dacă managementul revizuiește tendințele și elementele restante.

Un evaluator DORA sau din domeniul serviciilor financiare se va concentra pe reziliența operațională. Acesta va examina integrarea riscului TIC, clasificarea incidentelor, escaladarea către conducerea superioară, comunicarea către clienți, dependențele față de terți, testarea și lecțiile învățate. Dacă vulnerabilitatea afectează o funcție critică sau importantă, se va aștepta la o legătură strânsă între tichetul tehnic, impactul asupra activității, implicațiile pentru continuitate și obligațiile furnizorului.

Un evaluator GDPR se va concentra pe datele cu caracter personal. Au fost implicate date cu caracter personal? A existat acces neautorizat, pierdere, alterare sau divulgare? Rolurile de operator și persoană împuternicită au fost clare? A fost evaluat pragul de încălcare? Au fost relevante măsuri precum criptarea, controlul accesului, jurnalizarea și minimizarea?

Un auditor COBIT 2019 sau ISACA se va concentra pe guvernanță, responsabilitate, performanță și asigurare. Va căuta responsabilitate definită, metrici, escaladare, obiective de control, supravegherea managementului și urmărirea excepțiilor. O vulnerabilitate critică restantă nu este doar o problemă tehnică. Este o problemă de guvernanță dacă nu este escaladată formal și acceptată ca risc.

Un evaluator orientat NIST va gândi în termenii Identify, Protect, Detect, Respond și Recover. Va dori proprietari de active, identificarea vulnerabilităților, prioritizare, schimbare protectivă, detectarea exploatării, coordonarea răspunsului și validarea recuperării.

Avantajul unui model CVD integrat este că aceeași structură de dovezi poate susține toate aceste revizuiri.

Bucla lunară de control: metrici utile managementului

CVD nu se încheie când tichetul este închis. Politica privind divulgarea coordonată a vulnerabilităților impune revizuirea continuă a jurnalului:

„VRT trebuie să mențină un jurnal de divulgare a vulnerabilităților care urmărește fiecare raport de la primire până la închidere. Jurnalul trebuie revizuit lunar pentru a asigura progresul la timp al elementelor deschise. Elementele restante trebuie escaladate.”
Sursă: Politica privind divulgarea coordonată a vulnerabilităților, Monitorizare și audit, clauza 9.1

Această revizuire lunară transformă divulgarea vulnerabilităților într-o guvernanță pregătită pentru consiliu. Managementul nu are nevoie de fiecare detaliu tehnic. Are nevoie de tendințe, expunere, responsabilitate și risc restant.

Într-o implementare Clarysec matură, această revizuire lunară a jurnalului alimentează Registrul de riscuri, Declarația de aplicabilitate, backlog-ul de dezvoltare securizată, revizuirile furnizorilor, lecțiile învățate din incidente, planul de audit intern și pachetul de raportare către management.

Construiți procesul înainte să sosească raportul grav

Cel mai prost moment pentru a proiecta divulgarea coordonată a vulnerabilităților este după ce un cercetător a publicat punctul dvs. slab sau după ce un client bancar critic a blocat integrarea. NIS2, DORA, GDPR, ISO/IEC 27001:2022, așteptările de reziliență în stil NIST și guvernanța COBIT 2019 indică aceeași direcție: divulgarea vulnerabilităților trebuie planificată, deținută, testată, susținută prin dovezi și îmbunătățită.

Începeți cu aceste cinci acțiuni:

1. Adoptați sau adaptați Politica privind divulgarea coordonată a vulnerabilităților.
2. Construiți fluxul de preluare și triaj folosind Zenith Blueprint, în special Pasul 13 pentru trasabilitatea SoA, Pasul 16 pentru cultura raportării, Pasul 19 pentru managementul vulnerabilităților tehnice și Pasul 23 pentru acordurile cu furnizorii.
3. Mapați fluxul de lucru prin Zenith Controls, concentrându-vă pe controalele ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 și A.8.32.
4. Adăugați clauze pregătite pentru IMM-uri din Politica de răspuns la incidente - IMM, Politica de management al vulnerabilităților și al patch-urilor - IMM, Politica de securitate privind terții și furnizorii - IMM, Politica privind cerințele de securitate a aplicațiilor - IMM și Politica de audit și monitorizare a conformității - IMM acolo unde proporționalitatea contează.
5. Derulați un exercițiu de tip tabletop care simulează un raport de la un cercetător ce afectează date cu caracter personal și o componentă găzduită de furnizor, apoi testați confirmarea, triajul, clasificarea incidentului, aplicarea patch-urilor, comunicarea către clienți, captarea dovezilor și escaladarea către management.

Clarysec vă poate ajuta să transformați acest demers într-o politică CVD funcțională, un registru de preluare, o hartă a dovezilor ISO/IEC 27001:2022, un arbore decizional NIS2 și DORA, un model de escaladare către furnizori și un pachet de controale pregătit pentru audit. Obiectivul este simplu: când sosește următorul raport de vulnerabilitate, echipa dvs. nu trebuie să improvizeze. Trebuie să execute cu încredere, dovezi și control.