Ghid pentru un program de management al vulnerabilităților: De la scanare la remediere (2026)

Managementul vulnerabilităților este una dintre cele mai solicitante din punct de vedere operațional discipline de securitate — și una dintre cele mai frecvent examinate de auditori în cadrul DORA, NIS2 și ISO 27001. Acest ghid descrie cum să construiești un program complet, justificabil și proporțional: de la arhitectura de scanare și acoperirea activelor, prin prioritizare bazată pe risc, până la SLA-uri, metrici și dovezi pentru cerințele de reglementare.

De ce managementul vulnerabilităților nu înseamnă doar scanare

Multe organizații rulează un scanner și cred că au un program de management al vulnerabilităților. Scanarea este primul pas — nu întregul proces. Un program matur de management al vulnerabilităților necesită:

• Inventarul activelor. Nu poți scana ceea ce nu știi că există. Fără un inventar precis și actualizat al activelor, acoperirea scanării este necunoscută — iar acoperirea necunoscută este ea însăși un risc.
• Prioritizare bazată pe risc. Scanerele produc mii de constatări. Fără o metodologie de triere, echipele sunt copleșite și vulnerabilitățile cele mai periculoase ar putea să nu primească atenție primele.
• Responsabilitate pentru remediere. Vulnerabilitățile identificate au nevoie de responsabili care să fie responsabili pentru remedierea lor, urmăriți printr-un flux de lucru cu SLA-uri măsurabile.
• Metrici și raportare. Conducerea și auditorii trebuie să vadă dovezi ale eficacității programului, nu doar o listă de constatări.
• Îmbunătățire continuă. Acoperirea, instrumentele, SLA-urile și procesele necesită revizuire periodică pe măsură ce mediul se schimbă.

Construirea inventarului de active ca fundament

Un inventar al activelor este fundația pe care orice audit o va verifica primul. Pentru scopurile managementului vulnerabilităților, ai nevoie de:

• O listă a tuturor activelor hardware (servere, stații de lucru, dispozitive de rețea, OT/IoT unde este aplicabil)
• Toate activele software și versiunile care rulează în mediu
• Clasificare clară a activelor după criticitate (critic, important, standard) — legată de funcțiile de afaceri
• Activele cloud incluse — VM-urile cloud, containerele și sarcinile de lucru serverless lipsesc frecvent din inventare
• Componentele gestionate de terți clar identificate — responsabilitatea pentru scanare și remediere trebuie definită
• Inventarul este revizuit și actualizat cel puțin trimestrial sau la schimbări semnificative

Arhitectura de scanare și acoperirea

Scopul arhitecturii de scanare este o acoperire completă, autentificată, cu constatări exacte și oportune. Opțiuni comune:

Scanare autentificată față de neautentificată

Scanarea neautentificată (bazată pe rețea) arată ce poate vedea un atacator din rețea. Scanarea autentificată se conectează la sisteme și oferă o imagine mult mai completă a software-ului instalat, nivelurilor de patch și configurației locale. Pentru orice program serios, scanarea autentificată este standardul — scanarea neautentificată singură va rata majoritatea vulnerabilităților.

Frecvența de scanare

• Credențialele de scanare sunt menținute și rotite conform politicii de gestionare a accesului organizației
• Acoperirea scanării este măsurată ca procent din inventarul cunoscut de active — și această metrică este raportată
• Excluderile de la scanare sunt documentate cu o justificare de afaceri și revizuite periodic
• Activele cloud sunt acoperite — fie prin scanare bazată pe agenți, fie prin integrări cloud-native
• Rezultatele scanării sunt păstrate în scopuri de audit (cel puțin 12 luni, mai mult în conformitate cu DORA)

Triajul și prioritizarea bazată pe risc

Un scor CVSS singur nu este o bază suficientă pentru prioritizare. CVSS măsoară severitatea intrinsecă a unei vulnerabilități în izolare; nu ține cont de mediul tău, de exploatabilitate în practică sau de criticitatea activului. O abordare matură de prioritizare combină:

• Scorul de bază CVSS — un punct de plecare, nu finalul
• Criticitatea activului — o constatare de severitate Critică pe un sistem care susține o funcție bancară de bază este mai urgentă decât aceeași constatare pe un server de test
• Exploatabilitate în practică — catalogul Known Exploited Vulnerabilities (KEV) al CISA și feed-urile de informații privind amenințările identifică ce vulnerabilități sunt exploatate activ; acestea sunt de obicei cea mai mare prioritate indiferent de CVSS
• Expunerea — sistemele expuse pe internet prezintă un risc mai mare decât sistemele interne cu segmentare puternică a rețelei
• Controale compensatoare — o vulnerabilitate poate fi atenuată în context de un WAF, control de rețea sau configurație care reduce exploatabilitatea reală

• Există o metodologie documentată de scoring al riscului și este aplicată în mod consecvent
• Organizația se abonează la informații relevante privind amenințările (cel puțin CISA KEV, NVD, avize ENISA și buletine de securitate ale furnizorilor)
• Vulnerabilitățile critice și cele exploatate activ au un traseu accelerat de triere și remediere, separat de SLA-ul standard

SLA-uri și fluxul de lucru de remediere

SLA-urile fac programul măsurabil și auditabil. Fără termene definite de remediere, fiecare constatare este efectiv opțională. Atât DORA, cât și NIS2 solicită procese documentate de patch management; auditorii vor cere definiții ale SLA-urilor și dovezi de conformitate.

• SLA-urile sunt definite per nivel de severitate și aprobate formal
• Constatările de vulnerabilitate sunt urmărite într-un sistem de ticketing (sau o platformă de management al vulnerabilităților) cu un responsabil, dată scadentă și stare
• Conformitatea cu SLA este măsurată și raportată — procentul de constatări remediate în termenul SLA este un KPI de bază
• Există procese de excepție și acceptare a riscului: constatările care nu pot fi patch-uite în termenul SLA sunt acceptate ca risc cu documentație, nu pur și simplu omise
• Constatările remediate sunt verificate printr-o scanare de urmărire, nu doar marcate ca închise de responsabil

Cerințele DORA și NIS2 pentru managementul vulnerabilităților

Atât DORA, cât și NIS2 adresează explicit managementul vulnerabilităților și patch-urilor ca capacități de securitate necesare:

• DORA (Articolul 9): Managementul riscurilor TIC trebuie să includă patch management ca măsură de protecție, acoperind toate activele TIC. Identificarea și remedierea vulnerabilităților sunt explicit așteptate.
• DORA (Pilonul 3 / Articolul 25): Programul de testare a rezilienței trebuie să includă evaluări ale vulnerabilităților și teste de penetrare. Constatările din teste trebuie urmărite și remediate — nu doar documentate.
• NIS2 (Articolul 21(2)(e)): Securitatea în achiziția, dezvoltarea și mentenanța rețelelor și sistemelor informaționale include politici de gestionare și divulgare a vulnerabilităților și patch management ca măsură minimă.
• NIS2 (Articolul 21(2)(g)): Practicile de igienă cibernetică de bază includ explicit patch-uirea.

• Managementul vulnerabilităților este documentat ca program formal cu o politică, domeniu de aplicare, proces și un responsabil
• Programul acoperă toate sistemele care susțin funcții critice sau importante (conform definițiilor din DORA sau NIS2)
• Există dovezi pentru auditori: rapoarte de scanare, evidențe de remediere, metrici de conformitate SLA și jurnale de excepții
• Constatările din testele de penetrare sunt urmărite prin fluxul de lucru de management al vulnerabilităților, nu într-un siloz separat

Metricile care contează

Un program de management al vulnerabilităților ar trebui să producă metrici care înseamnă ceva atât pentru echipele tehnice, cât și pentru conducere. Cele mai utile:

• Rata de acoperire: procentul inventarului de active scanat cu succes în ultimul ciclu de scanare
• Timpul mediu de remediere (MTTR): timpul mediu de la identificarea constatării până la închiderea verificată, per nivel de severitate
• Rata de conformitate cu SLA: procentul de constatări remediate în termenul SLA definit, per nivel de severitate
• Restanțe critice: numărul de constatări critice și ridicate deschise — tendința este la fel de importantă ca numărul absolut
• Rata de recurență: cât de des reapar constatările după închidere — o rată ridicată semnalează probleme de calitate a remedierii
• Vârsta excepțiilor: cât timp au fost deschise excepțiile acceptate ca risc fără re-examinare

Cele cinci lacune de maturitate pe care le vedem cel mai des

1. Acoperire parțială considerată completă. Organizațiile exclud porțiuni mari din mediul lor de la scanare (cloud, OT, site-uri remote) și nu măsoară lacuna. Metricile de acoperire fac vizibile punctele oarbe.
2. CVSS ca unic semnal de triere. Fără date de exploatabilitate și criticitatea activului, echipele investesc efort în constatări High cu risc scăzut în timp ce cele Critice listate în KEV așteaptă în coadă.
3. Constatări fără responsabil. Managementul vulnerabilităților necesită un responsabil nominalizat per constatare, nu doar o coadă de echipă. Restanțele anonime cresc necontrolat.
4. SLA-uri care există dar nu sunt măsurate. Definirea SLA-urilor într-un document de politică și măsurarea efectivă a conformității sunt lucruri diferite. Auditorii cer dovezi de conformitate, nu doar definiția.
5. Constatările din testele de penetrare într-un spreadsheet separat. Rezultatele din teste de penetrare și exerciții TLPT aparțin fluxului de lucru de management al vulnerabilităților. Urmărirea în siloz înseamnă că îmbătrânesc fără urmărire sistematică.

Cum poate ajuta SephiraSec

SephiraSec proiectează și maturizează programe de management al vulnerabilităților în medii enterprise — inclusiv arhitectura de scanare Tenable SC, cadre de triere bazate pe risc, definirea SLA-urilor, integrare CMDB, pachete de dovezi DORA/NIS2 și raportare pentru conducere. Cu sediul în Viena, disponibil în toată UE, lucrând în engleză, germană și română.