Cât costă o vulnerabilitate nereparată pe server

În 2025, Directoratul Național de Securitate Cibernetică a informat 2.020 de instituții publice și operatori de servicii esențiale despre peste 43.000 de vulnerabilități exploatabile găsite pe infrastructura lor IT&C expusă public, cu recomandarea de a le remedia urgent. O vulnerabilitate nereparată nu e, pentru cele mai multe dintre organizațiile acelea, un risc necunoscut. E o linie într-un mail pe care l-a primit cineva, cu produsul, adresa și corecția deja disponibilă.

Ce se întâmplă când linia aceea rămâne o linie apare în același raport. Aaylex ONE SA, grupul alimentar din spatele brandului CocoRico — peste 2.000 de angajați, 36 de locații în nouă județe — a fost lovit de ransomware Akira, cu efecte pe contabilitate, producție, operațiuni și serverele de fișiere; DNSC a recuperat ulterior peste 66% din date. Accesul inițial s-a produs cel mai probabil prin exploatarea CVE-2020-3259, din interfața web a echipamentelor Cisco ASA și Firepower Threat Defense. Primele patru cifre ale identificatorului sunt anul publicării.

Cât ține fereastra și ce costă o vulnerabilitate nereparată

Constatarea e deja făcută și am scris-o separat, în articolul despre servere expuse la internet: ediția 2026 a Verizon DBIR, construită pe peste un miliard de înregistrări de detecție, măsoară 43 de zile mediane până la remedierea completă a unei vulnerabilități din catalogul CISA de vulnerabilități exploatate activ, în creștere de la 32, și doar 26% complet remediate, în scădere de la 38%. Aici nu reluăm constatarea. Facem socoteala.

Mediana ascunde partea care contează. Analizele pe aceleași date arată că la ziua 7 între 60% și 70% dintre vulnerabilitățile exploatate activ sunt încă deschise — indiferent de an, de volum sau de maturitatea organizației; chiar la vârful performanței lor, organizațiile repară 30-40% în prima săptămână. La ziua 28, 35% dintre instanțe erau încă deschise în 2025, față de 27% în 2024. Iar volumul crește: în cazul median, cu 50% mai multe vulnerabilități critice decât în anul precedent. Iar restanța se acumulează: într-o măsurătoare separată, a Cyentia și Veracode, 82% dintre organizații au vulnerabilități cunoscute nerezolvate de peste un an.

Durata are preț, și există o cifră în care durata e singura variabilă. IBM Cost of a Data Breach Report 2026 arată că breșele identificate și limitate în peste 200 de zile au costat în medie 5,65 milioane de dolari, față de 4,32 milioane pentru cele rezolvate mai repede — o diferență de circa 1,33 milioane, iar distanța dintre cele două grupuri s-a lărgit față de anul precedent, nu s-a redus.

Cifrele de milioane sună a corporație americană, și pe bună dreptate. Cea mai apropiată de o firmă mijlocie vine din sondajul Sophos The State of Ransomware 2026, pe 2.158 de lideri IT din 17 țări, din firme de 100 până la 5.000 de angajați lovite de ransomware: organizațiile cu venituri sub 50 de milioane de dolari au primit cereri de răscumpărare mediane de circa 140.000 de dolari, cele de peste 5 miliarde, 5,7 milioane. Atacatorii calibrează cererea după capacitatea percepută de plată. Costul mediu de recuperare, fără răscumpărare, a fost de 1.700.200 de dolari — un ordin de mărime pentru populația aceea, nu o factură pentru un IMM românesc.

Mai ușor de simțit decât banii e probabilitatea. În același sondaj, 41% dintre atacuri au fost oprite înainte de criptare — dar firmele de 3.001-5.000 de angajați reușesc asta în 46% din cazuri, iar cele de 100-250 de angajați în doar 34%. Raportul nu explică cele douăsprezece puncte de diferență, dar ele traduc fereastra din bani în probabilitate: cu cât se uită cineva mai târziu, cu atât atacul ajunge mai des până la criptare. Iar cauza-rădăcină stă acolo unde e fereastra: aplicații și sisteme expuse 38%, firewall 21%.

Unde se pierde fereastra, concret, într-o firmă care nu e neglijentă:

• Notificarea ajunge pe o adresă generică, de unde e transmisă „către IT" fără termen și fără cineva care să confirme că s-a aplicat.
• Corecția cere o fereastră de mentenanță, fereastra cere acordul cuiva din operațiuni, iar acordul se amână până la weekendul următor — de trei weekenduri.
• Echipamentul vulnerabil e la marginea rețelei și îl administrează furnizorul de internet sau integratorul, deci nimeni din firmă nu se simte proprietar.
• Se repară cele cu scor mare, pentru că scorul mare se explică mai ușor conducerii, iar cea care se exploatează efectiv rămâne pe locul unsprezece.

De ce fereastra nu se închide angajând mai repede

Reflexul normal, când vezi cifrele de mai sus, e să conchizi că îți lipsește un om. Datele nu susțin concluzia. Cyentia Institute a modelat, pe aproximativ 300 de organizații, rata lunară de închidere față de cea de deschidere a vulnerabilităților și a găsit ceva incomod de stabil: o organizație tipică are capacitatea de a remedia în jur de 1 din 10 vulnerabilități pe lună din mediul ei, iar asta pare valabil pentru firme mari, mici și de orice mărime între. Capacitatea de remediere se comportă ca un plafon, nu ca o funcție liniară de câți oameni ai în echipă.

Sondajul Sophos arată același lucru din altă direcție. Lipsa de oameni sau de capacitate e invocată masiv de firmele cu 100-250 de angajați, ceea ce nu surprinde pe nimeni; partea neașteptată e că patru din zece organizații cu 3.001-5.000 de angajați o invocă la o rată cu doar 3% mai mică. Resursele nu devin neapărat mai ușoare cu scara. Iar cauza operațională cea mai citată, pentru al doilea an consecutiv, rămâne „lacune de securitate, cunoscute sau necunoscute", la 62%, peste lipsa de oameni sau competențe, la 58%.

Un argument în plus, din România: în raportul pe 2025, DNSC declară un nivel de încadrare cu personal de 17,69%. Autoritatea națională operează la mai puțin de o cincime din posturile prevăzute și tot a monitorizat 317.000 de înregistrări CVE, din care a analizat în detaliu 121 imediat după publicare. Nu a făcut asta angajând mai mult. A făcut-o selectând.

Problema nu e volumul de muncă, e ordinea

Aici se schimbă toată discuția. FIRST.org, organismul care publică scorurile EPSS, precizează că catalogul KEV al CISA conține circa 0,5% dintre CVE-urile publicate, iar într-o fereastră oarecare de 30 de zile EPSS observă activitate de exploatare pe aproximativ 2,5-3% dintre ele. Estimarea cea mai generoasă spune că cel mult aproximativ 6% dintre CVE-urile publicate sunt vreodată exploatate în sălbăticie; seturile mai stricte indică 1-2%. Din 35.364 de vulnerabilități publicate în primul semestru 2026, doar 85 apăruseră în KEV la momentul unei analize independente — cu precizarea corectă că KEV are întârziere de luni și înregistrează doar exploatarea confirmată.

Citită împreună cu plafonul de capacitate, cifra asta răstoarnă problema. Dacă repari oricum aproximativ 10% din inventar pe lună, iar dintre vulnerabilitățile din inventar doar câteva procente vor fi vreodată folosite împotriva ta, atunci nu ai o problemă de volum de muncă. Ai o problemă de selecție. Firma care repară 10% pe lună și alege prost pierde; firma care repară exact aceleași 10% și alege bine e acoperită. Diferența dintre ele nu e un om în plus.

Nu repari mai mult. Repari în altă ordine — iar ordinea trebuie recalculată în ritmul în care se schimbă lista atacatorului, nu în ritmul în care se face raportul trimestrial.

Ritmul acela nu e generos. VulnCheck a măsurat, pe 884 de vulnerabilități intrate în KEV în 2025, că 28,96% aveau dovezi de exploatare în ziua publicării CVE-ului sau chiar înainte; în primul semestru 2026, 23,43%. Ediția 2025 a DBIR măsura, pe date din 2024, 5 zile mediane până la exploatarea în masă a unei vulnerabilități KEV și zero zile pentru cele de perimetru — cifră din ediția precedentă, pe alt an, deci nu una din care se scade ceva. La aproape o vulnerabilitate din patru, cronometrul atacatorului pornește oricum înaintea cronometrului tău.

De aceea nu funcționează prioritizarea după un singur criteriu. Scorul de severitate CVSS descrie cât de rău ar fi dacă, nu cât de probabil e. Nici probabilitatea singură nu ajunge: în august 2026, dintre 26 de vulnerabilități adăugate în catalogul KEV, 18 aveau un scor EPSS sub 1%. Ce funcționează e o combinație de cinci: severitatea, probabilitatea de exploatare, prezența pe lista de exploatare confirmată, expunerea reală a serviciului și criticitatea lui pentru business. Așa apare situația care sperie un auditor și e totuși corectă: o vulnerabilitate de severitate medie, exploatată activ, pe un serviciu expus la internet, trece înaintea unei vulnerabilități aproape maxime pe care nu o exploatează nimeni, într-un serviciu intern.

Cât de mult cântărește vectorul de vulnerabilitate față de celelalte e un subiect pe care sursele nu îl tranșează: DBIR 2026 îl pune pe primul loc, la 31% dintre breșe; sondajul Sophos îl vede coborând de la 32% la 18%, sub emailul malițios — dar întreabă victime ce cred că a fost cauza, iar o firmă de 150 de oameni recunoaște mai ușor un email decât o vulnerabilitate pe care nu știa că o are. Cifrele nu sunt comparabile între ele. Ce nu depinde de care alegi: 59% dintre cererile de răscumpărare din atacuri pornite de la o vulnerabilitate exploatată pe firewall sunt de un milion de dolari sau mai mult, față de 48% din toate cererile. Un vector mai rar și mai scump nu e un motiv să-l ignori.

Ordinea operațiilor, dacă vrei să scurtezi fereastra

Nimic din lista următoare nu presupune un buget de corporație. Presupune doar că lucrurile se fac în ordinea asta, nu invers.

1. 1Fă inventarul expunerii reale — ce răspunde efectiv la o cerere venită din exterior, nu ce își amintește cineva. Fără el, orice prioritizare se face pe o hartă greșită.
2. 2Stabilește cine primește notificările — de la DNSC, de la furnizorul echipamentului de perimetru, de la propria scanare — și scrie un termen de răspuns. O notificare fără proprietar și fără termen nu e o notificare, e o arhivă.
3. 3Prioritizează pe cele cinci criterii, nu pe scorul de severitate, și recalculează des: catalogul CISA de vulnerabilități exploatate activ a primit 26 de intrări noi doar în august 2026, deci o ordine stabilită trimestrial e deja veche când o citești.
4. 4Tratează perimetrul separat și primul. ENISA descrie activitatea grupărilor cu susținere statală în 2025 exact prin exploatarea susținută a infrastructurii de perimetru, iar asigurătorul Coalition, pe daunele pe care le-a plătit în 2024, arată 58% dintre daunele de ransomware pornite de la compromiterea unui echipament de perimetru.
5. 5Când nu poți aplica corecția acum — și uneori nu poți — scrie ce pui în loc până atunci: acces restrâns la sursele care au nevoie de el, monitorizare pe serviciul afectat, un termen de revenire. O fereastră asumată e altceva decât una uitată.
6. 6Ține un istoric al deciziilor: ce s-a reparat, ce s-a amânat, pe ce bază și de către cine. E singurul lucru care transformă „nu am avut timp" în „am prioritizat, iată cum".
7. 7Dacă nu ai pe cine pune să facă asta săptămânal, externalizează partea de judecată, nu doar uneltele — un partener de securitate cibernetică care ia și decizia, nu doar livrează raportul de scanare.

Ce face un produs care se uită la server non-stop

Clasa de produs care se potrivește pe problema asta nu e un antivirus și nu e un SIEM. E detecție deterministă care rulează non-stop, la cost aproape zero pe eveniment, plus un strat de judecată bazat pe model, chemat doar la ce trece un prag — ambele pe infrastructura clientului. Detecția non-stop ține lista de priorități actuală; stratul de judecată o face citibilă de cineva care nu e specialist. Ce poate și ce nu poate un model în triaj l-am discutat în articolul despre triajul alertelor de securitate.

Sentinel, produsul nostru, e o ilustrare concretă a clasei, iar felul cel mai util de a-l descrie într-un articol e prin ce nu face. Prioritizarea remedierii se calculează din severitate, probabilitate de exploatare, prezența pe lista CISA de vulnerabilități exploatate activ, expunere și criticitate — exact cele cinci criterii de mai sus — iar planul de reparare e redactat comandă cu comandă, cu backup, verificări și pași de revenire. Dar nu îl aplică singur, la niciun nivel comercial: la nivelul de bază aplicarea corecțiilor e explicit exclusă din serviciu, la nivelul administrat planurile redactate de model sunt verificate de noi înainte să ajungă la client, iar aplicarea cere două confirmări explicite pe telefon, cu butonul care moare dacă planul se regenerează.

De spus direct, pentru orice cumpărător: produsul nu închide fereastra în locul tău. O face vizibilă, o ordonează corect și îți pune în mână procedura; decizia de a opri producția cinci minute ca să aplici o corecție rămâne a firmei. Lipsurile sunt declarate și ele: logurile din containere nu sunt colectate încă, nu există un monitor dedicat de integritate a fișierelor dincolo de auditd, iar instalarea pe Debian e acoperită de teste, dar încă neverificată pe o gazdă Debian reală. Cele trei niveluri comerciale au prețul „la cerere", pentru că depinde de câte mașini și cât din operare preiei tu.

Pentru omul tehnic care evaluează: ce întrebi înainte să semnezi

Dacă tu ești cel care va trăi cu produsul pe server, întrebările care contează nu sunt despre tablou de bord. Și merită puse oricărui furnizor din clasă, nu doar nouă.

• Ce colectează, exact. La noi sunt cinci tipuri de surse enumerate public — sshd, sudo și su, nginx, auditd, Suricata. Cere lista, nu un număr: ce nu e pe listă nu e monitorizat.
• Cât de des se uită și pe ce reguli. Detecția rulează determinist la fiecare 10 secunde, pe praguri publicate: brute-force pe SSH la 15 eșecuri în 60 de secunde, enumerare web la 200 de căi inexistente în 5 minute. Un prag pe care nu ai voie să-l vezi e un prag pe care nu poți să-l calibrezi.
• Cum se numără incidentele. Deduplicarea prin fingerprint face din 400 de încercări de la o adresă un singur incident, nu 400. Fără ea, primul weekend de scanare automată îți antrenează echipa să ignore alertele.
• Ce se întâmplă cu planul redactat de model. La noi trece printr-un validator determinist care îl refuză dacă nu e sigur: modelul redactează, validatorul decide. Comanda rm nu e în lista de binare permise, iar ștergerea trece printr-o operațiune unică limitată la directorul de backup.
• Cum sunt tratate liniile de log. Ele sunt scrise de atacator, deci sunt date neîncrezute: ajung la model cu delimitatori expliciți, transportul care citește fișiere rulează în permission-mode plan, iar un test plantează IGNORE PREVIOUS INSTRUCTIONS într-un access log și verifică că nu s-a executat nimic. O injecție reușită schimbă o etichetă, nu sistemul.
• Ce se întâmplă când produsul cade. Regula de bază nftables e policy accept, adică e un deny-lister, nu un firewall: dacă procesul moare sau configurația e greșită, traficul trece. Un produs de securitate care îți oprește afacerea prin propriul eșec e o problemă nouă.
• Cum se pornește blocarea automată. La noi există și e testată, dar se livrează oprită: primele 72 de ore arată doar ce ar fi blocat. Cine pornește blocarea din prima zi pe o rețea pe care nu a văzut-o încă îți promite un incident de disponibilitate.

Concluzie

Fereastra dintre momentul în care afli că ai o vulnerabilitate nereparată și momentul în care ai reparat-o nu se închide muncind mai mult, pentru că plafonul de remediere se măsoară cam la fel într-o firmă mică și într-una de câteva mii de oameni. Se închide alegând mai bine, săptămânal, dintr-un inventar în care doar câteva procente vor fi vreodată folosite împotriva ta — iar alegerea aceea cere ceva care se uită la serverul tău în ritmul atacatorului, nu în ritmul raportului trimestrial. Dacă vrei să vedem împreună ce ai expus acum și în ce ordine ar trebui reparat, hai să discutăm 30 de minute, fără obligații.

Surse

• DNSC — Raport anual de activitate 2025, aprobat prin Hotărârea CSAT nr. 117 din 7 august 2026 (dnsc.ro)
• Verizon — Data Breach Investigations Report 2026, peste un miliard de înregistrări de detecție, cu analize publicate de Tenable, Nucleus Security și Qualys; ediția 2025 a aceluiași raport, prin analiza GreyNoise
• Cyentia Institute — „Patching, Fast and Slow" (cyentia.com); Cyentia / Veracode — 2026 State of Software Security
• Sophos — The State of Ransomware 2026, 2.158 de lideri IT, 17 țări, firme de 100-5.000 de angajați (sophos.com)
• IBM — Cost of a Data Breach Report 2026, cercetare Ponemon Institute (ibm.com/reports)
• FIRST.org — EPSS FAQ și documentația EPSS (first.org/epss)
• VulnCheck — State of Exploitation 2026 și 1H-2026 (vulncheck.com)
• ENISA — Threat Landscape 2026, 8.257 de incidente din 2025 (enisa.europa.eu)
• Coalition — Cyber Threat Index 2025, pe daune plătite de asigurător (coalitioninc.com)
• Jerry Gamblin — CVE Mid-Year 2026 Check-In (jerrygamblin.com); isMalicious — analiză KEV și EPSS, august 2026 (ismalicious.com)
• CryptoITData — Sentinel, documentație de produs și limite declarate public (cryptoitdata.eu/sentinel)