Patru termene din ultimele două luni, toate verificabile:
- Citrix NetScaler CVE-2026-19490 — adăugat în catalogul CISA al vulnerabilităților exploatate cunoscute pe 9 septembrie 2026, termen de remediere 12 septembrie.
- WordPress core CVE-2026-87902 — patch publicat pe 22 septembrie, prima tentativă de exploatare înregistrată la 11:49 UTC în aceeași zi. În catalog pe 25 septembrie, termen 28 septembrie.
- Ivanti Connect Secure CVE-2026-104935 — avertizarea și listarea în catalog, ambele pe 13 octombrie, termen 16 octombrie, marcat ca necesitând analiză criminalistică.
- Atlassian CVE-2026-21589 — în catalog pe 15 octombrie, termen 18 octombrie, cu tentative de exploatare începute la aproximativ două ore după publicarea analizei tehnice.
Trei zile, trei zile, trei zile și, într-un caz, trei ore. Niciunul nu încape într-o fereastră lunară de mentenanță. Niciunul nu supraviețuiește unui comitet de aprobare a schimbărilor care se reunește din două în două marți.
Întrebarea interesantă nu este dacă organizația poate aplica repede un patch. Majoritatea pot. Întrebarea este dacă organizația poate decide repede, iar acesta este un cu totul alt mecanism.
Constrângerea nu este aproape niciodată tehnică
Întreabă o echipă de ce un patch critic a durat unsprezece zile și rareori vei auzi că patch-ul a fost dificil. Vei auzi o variantă a următoarelor:
- Proprietarul sistemului era în concediu și nimeni altcineva nu putea aproba o repornire
- Comitetul de schimbare se întrunește joi, iar cazul nu a fost clasificat ca urgență
- Era înghețare de schimbări pentru închiderea de trimestru și nimeni nu știa cine o poate ridica
- Credențialele pentru portalul producătorului erau la o singură persoană, iar ziua era sâmbătă
- Nimeni nu voia să fie cel care repornește serverul care se dovedește apoi esențial
Fiecare este o deficiență de proces îmbrăcată în haine tehnice. Patch-ul a fost disponibil tot timpul.
Ce cere efectiv NIS 2 aici
Articolul 21 din NIS 2, transpus în România prin OUG nr. 155/2024, enumeră „gestionarea și divulgarea vulnerabilităților" printre măsurile obligatorii, alături de gestionarea incidentelor și continuitatea activității. Nu prescrie un număr de zile. Auditorii nu îți vor da o țintă, iar cei mai mulți nici nu vor să o facă.
Ce caută în schimb o evaluare competentă este dacă procesul există, dacă are termene scrise în el și dacă dovezile arată că acele termene sunt respectate — sau ratate conștient, cu o decizie consemnată de cineva care avea autoritatea să o ia.
Ultima parte este cea pe care organizațiile o sar. Un termen ratat, cu o acceptare de risc datată și semnată de proprietarul sistemului, înseamnă un proces funcțional. Un termen ratat pe care nu l-a observat nimeni, nu.
Șablonul de schimbare de urgență, aprobat dinainte
Cel mai util document aici este un șablon de schimbare scris înainte să ai nevoie de el, aprobat o singură dată de cine aprobă în mod normal schimbările, și ținut la îndemână.
Trebuie să numească, din timp:
- Condițiile care transformă o schimbare în urgență — apariția în catalogul CISA, o avertizare de la producător peste o severitate convenită, exploatare confirmată în sălbăticie, sau o instrucțiune de la CSIRT-ul național
- Cine poate aproba, pe rol și nu pe nume, cu cel puțin două roluri în adâncime, astfel încât concediul unei persoane să nu blocheze procesul
- Cine poate aproba în afara programului și cum este contactat efectiv la 22:00 — un număr de telefon la care răspunde cineva, nu o căsuță de e-mail comună
- Ce testare se suspendă în condiții de urgență și ce nu se suspendă niciodată
- Ce se consemnează în timpul schimbării, nu înaintea ei, ca documentarea să nu devină blocajul
- Cine este anunțat și când — serviciul de suport, proprietarii de business afectați, echipa de gardă
Rostul scrierii lor dinainte este ca, în momentul în care ai nevoie, nimeni să nu decidă cine decide. Oamenii doar execută.
Problema înghețării schimbărilor
Majoritatea organizațiilor îngheață schimbările în jurul închiderii de trimestru, al vârfurilor de activitate, al închiderii de an sau al unei puneri în producție majore. Majoritatea politicilor de înghețare nu spun nimic despre urgențele de securitate, ceea ce înseamnă că în practică sunt interpretate pe loc de cine este cel mai îngrijorat.
Scrie excepția chiar în politica de înghețare, cu aceleași roluri nominalizate. O înghețare care nu poate fi ridicată pentru o vulnerabilitate exploatată activ este o politică ce a decis deja că un raport de final de trimestru contează mai mult decât o compromitere — iar cineva ar trebui să ia decizia aceea deliberat, nu prin omisiune.
Lucrurile pe care nimeni nu le găsește sâmbăta
O parte surprinzător de mare din patching-ul de urgență se blochează în logistică:
- Contul pe portalul de suport al producătorului, deținut de persoana care a cumpărat inițial produsul
- Numărul contractului de mentenanță, necesar pentru descărcarea corecției
- Credențialele de management out-of-band pentru echipament
- Care dintre cele trei servere asemănătoare este, de fapt, cel din avertizare
- Versiunea de firmware care rulează efectiv, nu cea din inventarul de active
Ultima merită insistență. În cazul Ivanti, echipamentul compromis era complet actualizat la momentul atacului, iar avertizarea Atlassian se aplică „tuturor versiunilor" — așa că un inventar care consemnează versiunile intenționate, nu pe cele care rulează, nu îți spune nimic util în niciunul dintre cazuri.
Patch-ul este primul pas, nu tot răspunsul
Lanțul Ivanti este cel mai clar argument recent că aplicarea corecției este locul unde începe munca.
Volexity nu a găsit niciun web shell și niciun malware de primă etapă pe echipamentul investigat, pentru că escaladarea de privilegii rula exclusiv în memorie, iar atacatorul reexecuta întregul lanț pentru fiecare comandă. Instrumentul de verificare a integrității de la Ivanti nu putea vedea nimic. CISA a comunicat organizațiilor că vor avea nevoie de analiză criminalistică pe rețea și pe memorie, iar intrarea din catalog a fost marcată ca necesitând triaj criminalistic — o instrucțiune distinctă de „instalează actualizarea".
Deci procesul de schimbare de urgență are nevoie de o a doua jumătate: când avertizarea spune că exploatarea a precedat divulgarea, ce dovezi colectezi, cine le colectează și ce roteși după aceea? În cazul Ivanti, răspunsul a inclus parolele tuturor conturilor de domeniu, de administrator și locale, plus certificatele stocate, cheile de API și credențialele de licențiere. Un echipament corectat, dar cu credențialele furate încă valabile, a închis ușa și a lăsat cheile afară.
Repetă o dată
Acesta este unul dintre puținele lucruri pe care un exercițiu de tip tabletop chiar le îmbunătățește, pentru că deficiențele sunt organizatorice și ies la suprafață imediat.
Organizează-l ca o ședință de nouăzeci de minute. Alege o avertizare reală din ultima lună — nu duci lipsă. Pune ceasul vineri la 18:00. Apoi parcurge totul cu voce tare: cine declară urgența, pe cine sună, ce se întâmplă dacă persoana aceea nu răspunde, cine ține credențialele producătorului, cine semnează repornirea, cine anunță businessul că VPN-ul pică și ce faci dacă avertizarea spune să presupui compromiterea.
Vei găsi două-trei verigi rupte. Repară-le și ai scurtat fiecare răspuns viitor mai mult decât ar fi făcut-o orice achiziție de unelte.
Ce scrii luna aceasta
Trei documente, niciunul lung:
- Un șablon de schimbare de urgență, preaprobat, cu condiții declanșatoare și roluri de aprobare nominalizate, inclusiv o cale în afara programului
- O clauză explicită de excepție de securitate în politica de înghețare a schimbărilor
- O pagină cu harta de contacte și credențiale pentru sistemele expuse în internet: cine deține fiecare sistem, cine poate aproba o repornire, unde sunt credențialele producătorului și cum confirmi versiunea care rulează
Dacă nu ești sigur ce sisteme ar trebui să fie pe lista aceea — ce servicii răspund pe adresele tale publice și ce versiune raportează fiecare — este o întrebare la care răspunde din exterior o evaluare a suprafeței externe de atac, exact cum și-ar construi lista un atacator. Unde trebuie examinat procesul, nu tehnologia, un audit de conformitate sub NIS 2 acoperă asta, iar un test de penetrare intern arată la ce ajunge efectiv un sistem neactualizat odată ce cineva este înăuntru.
Termenele nu vor deveni mai lungi. O fereastră federală de remediere de trei zile este acum obișnuită, nu excepțională, iar distanța dintre o analiză publicată și prima scanare se măsoară în ore. Organizațiile care închid decalajul nu sunt cele cu scanere mai bune. Sunt cele în care cineva știe deja pe cine să sune.
Surse: Catalogul CISA al vulnerabilităților exploatate cunoscute · Volexity despre lanțul Ivanti Connect Secure · Avertizarea Atlassian pentru CVE-2026-21589 · Patchstack despre momentul exploatării CVE-2026-87902
Datele de adăugare în catalog și termenele de mai sus sunt cele raportate de producători și de presa de securitate; nu am citit direct fiecare intrare din catalog. Momentele exploatării provin din telemetria unor rețele de tip honeypot și nu reprezintă numărul organizațiilor compromise.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.