Scanare de vulnerabilități lunară: ce vede și ce ratează

Raportul lunar de scanare de vulnerabilități a ieșit curat: zero critice, două medii, un grafic verde. Îl trimiți conducerii și treci la altceva. Pe prima pagină nu scrie dacă scanerul a intrat pe servere sau doar a bătut la ușă, ce echipamente a sărit din oficiu și ce a apărut pe lista atacatorilor din ziua în care a rulat.

Ultimul punct se poate număra. În ultimele 365 de zile, catalogul CISA de vulnerabilități cu exploatare confirmată (KEV) a primit 315 intrări, circa 26 la fiecare 30 de zile, după numărătoarea noastră pe feedul oficial din 4 noiembrie 2026. Nu toate te privesc. Dar între două scanări lunare lista atacatorilor se mișcă, iar raportul tău rămâne cum l-ai primit.

De ce un raport curat nu înseamnă o rețea curată

Un scaner raportează ce a reușit să verifice. Ce n-a verificat lipsește din listă, iar o listă scurtă arată la fel ca o rețea bine întreținută. Patru feluri concrete în care se întâmplă asta:

• Scanerul a rămas afară. Tenable, producătorul Nessus, spune că scanarea neautentificată vede rețeaua ca un atacator din afară și nu dă imaginea completă; verificările locale cer autentificare. Nessus are și un plugin dedicat, 21745, care semnalează că evaluarea patch-urilor nu a rulat, de exemplu pentru că acreditările nu au permis autentificarea.
• Scanerul a sărit echipamente. Nessus marchează implicit imprimantele și multifuncționalele ca „Dead” și le sare, pentru că reacționează prost la scanare. Ce e sărit nu apare în raport.
• Scanerul n-avea verificarea. Într-un benchmark din ianuarie 2024, făcut de Pentest-Tools.com (furnizor concurent, cu propriul scaner în test), pe 128 de medii vulnerabile detectabile de la distanță, fără autentificare și cu setări implicite, Nessus a revendicat detecție pentru 67,19% și a identificat efectiv 22,66%. Nu e rata de detecție din producție și nu arată că Nessus ar fi slab. Arată că o bază de semnături nu e o garanție.
• Lista conține zgomot. Red Hat repară prin backport fără să schimbe versiunea, iar uneltele care decid doar după numărul versiunii raportează fals pozitive. Timpul pierdut pe ele iese din aceeași echipă care trebuia să repare restul.

Mai e și ce un scaner nu-și propune să vadă: autorizarea, logica aplicației, lanțurile de atac. Diferența dintre scanare, audit și pentest am explicat-o într-un articol separat.

Varianta evidentă, „instalăm noi un scaner gratuit”, se lovește repede de licență. Nessus Essentials înseamnă până la 5 IP-uri, licență de 30 de zile, plugin-uri cu 30 de zile întârziere și uz strict necomercial, deci nu e o opțiune pentru o firmă (mai găsești pagini terțe cu 16 IP-uri; contează pagina Tenable). Nessus Professional costă $4.790 pe an la licența de 1 an. OpenVAS are un feed Community gratuit, pentru software și sisteme larg folosite, iar echipamentele de rețea precum Cisco sau Palo Alto apar printre ce adaugă feedul Enterprise, cu plată. Dacă perimetrul tău e pe lista aceea, verifică înainte ce acoperă varianta gratuită.

Scanarea de vulnerabilități e un instrument de măsură

Întrebarea obișnuită e câte critice a găsit scanerul. Întrebarea utilă e cum a fost reglată măsurătoarea. Cât te poți baza pe listă depinde de patru reglaje: cât de des măsori, de unde te uiți, cu ce acces intri și ce faci între două măsurători. Schimbi poziția sau accesul și, pe aceeași rețea, primești altă listă.

Un raport curat îți spune ce n-a găsit scanerul. Despre rețea îți spune doar atât cât l-ai lăsat să vadă.

Cât de des: standardele nu dau același număr

Caută răspunsul în standarde și primești cinci răspunsuri:

• Ghidul tehnic ENISA v1.0, din iunie 2025: o listă orientativă sugerează scanări săptămânale pentru vulnerabilități noi, cu precizarea că frecvența depinde de evaluarea de risc, plus scanări după incidente sau schimbări semnificative. Ghidul nu e obligatoriu.
• CIS Controls: lunar sau mai des pe activele expuse extern (Safeguard 7.6, scaner configurat la cel mult 30 de zile) și trimestrial sau mai des pe intern (Safeguard 7.5). Se aplică grupurilor IG2 și IG3, nu IG1.
• PCI DSS v4.0.1: intern și extern cel puțin o dată la trei luni, cele externe prin ASV, potrivit surselor secundare consultate.
• Regulamentul (UE) 2024/2690: scanări acolo unde e cazul, cu dovezi, la intervale planificate. Niciun număr. Vizează entități digitale (DNS, cloud, centre de date, servicii gestionate și altele), nu toate entitățile NIS2.
• ISO 27001:2022, A.8.8: nicio frecvență fixă în sursele secundare consultate.

Cifrele nu se exclud. Unele sunt praguri de conformitate, altele recomandări, și vorbesc unor publicuri diferite. În România, Ordinul DNSC nr. 1 din 6 august 2026, publicat în Monitorul Oficial nr. 712 din 27 august, aprobă măsurile de gestionare a riscurilor, cu anexele în 712 bis. N-am putut citi anexa, deci nu afirmăm nimic despre ce spune în privința scanării: verifică în anexă controlul aplicabil nivelului tău. Obligațiile față de DNSC le-am adunat separat.

Concluzia practică: nu există un număr de copiat. Alegi o cadență, o justifici prin risc și o scrii. Lunar pe ce e expus și cel puțin trimestrial pe intern e pragul CIS, un reper bun de la care să argumentezi. N-am găsit date care să arate că scanatul mai des duce și la reparat mai repede, așa că nu plăti o frecvență pe care echipa nu o poate consuma.

De unde se uită: extern și intern măsoară altceva

Scanarea externă arată ce vede oricine de pe internet, inclusiv cei care scanează automat non-stop. Scanarea internă arată ce găsește cineva ajuns deja înăuntru. Diferența se vede în date: în raportul Edgescan 2026, pe stratul de rețea, 24,62% dintre vulnerabilitățile de pe activele nepublice sunt critice sau înalte, față de circa 10% pe cele publice. Populația sunt clienții Edgescan, iar severitatea e pe scorul propriu al furnizorului, deci nu e o fotografie a IMM-urilor românești. Lectura noastră: cine scanează doar perimetrul măsoară partea care arată mai bine.

Tot acolo, CVE-urile cu identificatori din 2020 sau mai vechi fac circa 44% din aparițiile pe active publice și circa 38% pe cele interne (sumele sunt ale noastre, din tabelele raportului; identificatorul nu e mereu anul publicării). Lectura noastră: o bună parte din ce găsește o scanare nu a apărut luna asta.

Cu ce acces: aici standardele merg în aceeași direcție

Pe cadență diferă, pe acces nu. CIS numără separat activele acoperite de scanare autentificată, ghidul ENISA o sugerează acolo unde se poate, iar PCI DSS v4.0.1 o cere pentru scanarea internă din 31 martie 2025, potrivit acelorași surse secundare. Scanarea autentificată înseamnă că scanerul intră pe sistem cu un cont, de multe ori cu privilegii ridicate, și face verificări locale, în loc să se uite doar din rețea. Cât găsește în plus nu știm: cifrele care circulă n-au un studiu în spate, așa că nu-ți dăm una.

Întrebarea practică e pe câte hosturi a reușit autentificarea. O scanare autentificată pe hârtie, cu acreditări respinse pe o parte din parc, măsoară mai puțin decât scrie pe copertă.

Ce acoperă intervalul dintre două scanări

Volumul brut spune puțin. În ianuarie-aprilie 2026 au fost publicate 20.293 de CVE, circa 5.073 pe lună (media e calculată de noi), iar FIRST prognozează circa 66.000 pentru tot anul, adăugând în iunie că povara acționabilă, măsurată prin KEV și EPSS peste 10%, rămâne plată. Numărătoarea noastră pe feedul CISA arată între timp 284 de adăugări în 2026 până la 4 noiembrie, față de 245 în tot 2025, cu 43 în septembrie și 36 în octombrie. Perioadele și măsurătorile diferă, iar două luni nu fac o tendință, deci de aici nu rezultă că FIRST a greșit.

Pentru intervalul tău contează altceva: 50 dintre cele 284 au identificatori din 2024 sau mai vechi. Pe lista exploatărilor confirmate ajung și vulnerabilități vechi, deci ordinea din raportul de luna trecută se poate învechi fără ca scanerul să fi rulat. Nici viteza nu ajută: M-Trends 2026 estimează timpul mediu până la exploatare la -7 zile, adică exploatarea vine de obicei înaintea corecției, pe o populație de organizații care au chemat Mandiant. Tot acolo, exploit-urile sunt primul vector inițial, cu 32% din intruziuni; DBIR 2026 dă 31%, pe altă populație.

Nu conta nici pe o notificare. În 2025, DNSC a informat 2.020 de instituții publice și operatori de servicii esențiale despre peste 43.000 de vulnerabilități exploatabile. O firmă privată obișnuită nu e pe lista aceea, deci intervalul îl acoperi singur.

Cum faci o scanare de vulnerabilități pe care te poți baza

1. 1Scrie ce trebuie scanat, apoi compară cu ce a scanat efectiv unealta. Ghidul ENISA sugerează ca dovadă exact asta: configurația care arată că scanerul acoperă toată infrastructura relevantă și are definiții la zi.
2. 2Fixează cadența în scris, cu motivul ei: extern cel puțin lunar, intern cel puțin trimestrial, plus o scanare după fiecare schimbare semnificativă.
3. 3Folosește un cont dedicat pentru scanarea autentificată și, la fiecare raport, verifică pe câte hosturi a reușit. În Nessus, pluginul 21745 e locul de pornire.
4. 4Ține o listă separată cu ce e exclus din scanare, de la imprimante la echipamentele OT, care au tratament aparte, și scrie cum le verifici altfel. Un echipament sărit rămâne în rețea.
5. 5Compară săptămânal intrările noi din feedul CISA KEV cu inventarul tău și urmărește canalele pe care Regulamentul 2024/2690 le dă ca exemplu: CSIRT-uri, autorități, furnizori.
6. 6Cere rapoartele zilnice gratuite Shadowserver pentru spațiul tău de rețea. Sunt pentru cine controlează acel spațiu, cu verificarea identității.
7. 7Păstrează dovezile: programul scanărilor, rezultatele și ce ai făcut cu ele. Regulamentul 2024/2690 cere entităților vizate dovezi ale rezultatelor, ghidul ENISA sugerează și jurnale cu programul și urmările scanărilor, iar potrivit rezumatelor publicate ale Ordinului DNSC, autoevaluarea e anuală. Jurnalele te scutesc atunci de reconstituiri.

Pentru intervalul dintre scanări avem și un produs separat, Sentinel, în care prioritizarea pe mai multe criterii ține de produs, nu de pachetul de scanare.

Ce întrebi orice furnizor, inclusiv pe noi

Pachetul Vulnerability Scanning Lunar din lista noastră de pachete înseamnă scan extern și intern lunar cu Nessus/OpenVAS, raport prioritizat CVSS, recomandări concrete de remediere și retest post-fix la cerere. Pentestul e serviciu separat, la securitate cibernetică. Prețurile din catalog, pe lună:

• Micro, până la 10 hosturi: 850 lei fără TVA (1.028,50 lei cu TVA).
• Small, 10-50 de hosturi: 1.800 lei fără TVA (2.178 lei cu TVA).
• Medium, 50-100 de hosturi: 3.500 lei fără TVA (4.235 lei cu TVA).
• Large, 100+ hosturi: 6.500 lei fără TVA (7.865 lei cu TVA).

În catalog scrie CVSS, așa că spunem direct cum să-l citești: e punctul de plecare al ordinii, nu punctul ei de sosire. La Edgescan, trei categorii fac aproape 60% din constatările critice și înalte de rețea și host (Diffie-Hellman DoS 24%, OpenSSH 22%, SWEET32 13,2%), iar circa 6,2% dintre vulnerabilitățile descoperite sunt legate de campanii de ransomware. Media de remediere la clienții Edgescan, pentru critice și înalte, e de 39 de zile pe device și rețea, dar ajunge la 134,3 zile la EPSS peste 0,7, iar raportul conchide că prioritizarea urmează încă CVSS mai mult decât EPSS sau KEV. În plus, NIST nu mai adaugă de rutină un scor propriu când există deja unul, de unde deducem că scorul din raport vine tot mai des de la furnizorul produsului. Cum ordonezi lista după ce o ai am scris în articolul despre vulnerabilitățile nereparate.

Înainte să semnezi, cu noi sau cu altcineva, întreabă:

• Scanarea internă e autentificată? Pe câte hosturi a reușit în ultimul raport?
• Ce s-a exclus din scanare și unde văd asta în raport?
• Ce unealtă și ce feed rulează pe echipamentele mele de perimetru?
• Raportul spune doar CVSS sau adaugă KEV și EPSS?
• Cine validează fals pozitivele și în ce ferestre rulează scanările? Orange Business România, de exemplu, listează validare manuală și scanări în ferestre de mentenanță, deci e un reper de piață pentru întrebare.
• Retestul e inclus în preț? Ce se numără ca host?

O parte dintre răspunsurile noastre nu sunt în fișa pachetului, așa că pune-ni-le la fel de direct. Un furnizor care ocolește întrebarea despre hosturile autentificate îți vinde o listă, fără să-ți spună ce a măsurat.

Concluzie

O scanare de vulnerabilități lunară își merită banii în măsura în care știi ce a măsurat: la ce cadență, din ce poziție, cu ce acces și ce ai făcut între două rulări. Fără cele patru răspunsuri, un raport curat e doar o listă scurtă. Dacă vrei să ne uităm împreună pe ultimul tău raport și să vedem ce a rămas nemăsurat, hai să discutăm 30 de minute.

Surse

• CISA — Known Exploited Vulnerabilities, feedul oficial, versiunea 2026.11.04, calcul propriu (cisa.gov)
• CIS Controls Assessment Specification — Safeguards 7.5 și 7.6 (controls-assessment-specification.readthedocs.io)
• Regulamentul de punere în aplicare (UE) 2024/2690, anexă, pct. 6.10.2, și ENISA — Technical implementation guidance v1.0, 26 iunie 2025 (enisa.europa.eu); McCann FitzGerald, pentru caracterul neobligatoriu al ghidului (mccannfitzgerald.com)
• SecurityMetrics și WithPCI — cerințele de scanare PCI DSS v4.0.1 (securitymetrics.com); ISMS.online — ISO 27001:2022 A.8.8 (isms.online)
• Ordinul DNSC nr. 1/2026, Monitorul Oficial nr. 712 din 27 august 2026 (lege5.ro, legis.medleg.ro); rezumate publicate: Awarely Monitor, Business Generator, Optimizor
• DNSC — Raport anual 2025, p. 16
• Jerry Gamblin — CVE 2026 Half-Year Forecast Update, 5 mai 2026 (jgamblin.github.io); FIRST — Vulnerability Forecast Update, 15 iunie 2026 (first.org)
• Google Cloud / Mandiant — M-Trends 2026, 23 martie 2026 (cloud.google.com); Edgescan — analiză Verizon DBIR 2026 (edgescan.com)
• NIST — actualizarea operațiunilor NVD, 15 aprilie 2026 (nist.gov)
• Edgescan — Vulnerability Statistics Report 2026 (edgescan.com)
• Tenable — documentație scanare, pluginurile Nessus 21745 și 11933, Nessus Essentials și prețuri (tenable.com)
• Pentest-Tools.com — Network Vulnerability Scanner Benchmark, 2024 (pentest-tools.com); Red Hat — backporting (access.redhat.com); Greenbone — feed comparison (greenbone.net)
• Shadowserver — Get Reports (shadowserver.org); Orange Business România — SCUT Vulnerability Assessment (orange.ro)