Pe 8 septembrie 2026, undeva în jurul orei 17:00, site-ul Directoratului Național de Securitate Cibernetică a încetat să mai răspundă normal. A doua zi dimineață, la Radio România Actualități, directorul general Dan Câmpean a dat cifrele: atacatorii au lansat circa 2,8 milioane de solicitări de acces, dintre care aproximativ 50.000 au trecut de toate filtrele tehnice implementate și au suprasolicitat platforma. Întreruperea a durat sub 30 de minute.
Răspunsul tehnic a fost direct. DNSC a izolat tot traficul dinspre internet către site și, temporar, a permis accesul doar din România — pentru că foarte multe dintre solicitările care veneau spre site proveneau din Olanda, Statele Unite, Indonezia și Singapore.
Ironia că instituția care apără România de atacuri cibernetice a trebuit să-și apere propriul site a fost exploatată din plin în presă. Citirea utilă este alta. Un DDoS asupra unui site public nu este o breșă: nu s-au compromis date și nu a pătruns nimeni în sisteme. Este însă, în logica NIS 2, un incident de securitate care afectează disponibilitatea — iar disponibilitatea este exact obligația la care s-au gândit cel mai puțin entitățile din România.
Disponibilitatea este cerință de securitate, nu temă de infrastructură
Art. 21 din OUG nr. 155/2024, care transpune NIS 2 în dreptul intern, enumeră continuitatea activității și managementul crizelor printre măsurile de gestionare a riscurilor pe care o entitate esențială sau importantă trebuie să le ia. În majoritatea organizațiilor, paragraful ăsta e citit de echipa de infrastructură ca „uptime", iar de echipa de securitate ca problema altcuiva.
Incidentul de la DNSC arată limpede de ce împărțirea asta nu funcționează. Nu a existat nicio vulnerabilitate de patch-uit. Nu a existat nicio credențială de rotit. Întreg rezultatul a fost decis de două lucruri stabilite dinainte: ce capacitate de filtrare era deja în fața site-ului și cât de repede a putut un om să autorizeze o decizie drastică privind traficul.
Formularea lui Câmpean merită citată în discuțiile interne: orice organizație, orice site de web, orice aplicație, orice platformă poate fi la un moment dat impactată de un incident cibernetic, iar ce contează foarte mult este capacitatea echipelor tehnice de a restabili rapid infrastructura.
Mai spun ceva și cifrele, despre succesul parțial. Filtrele au oprit aproximativ 98% din trafic. Restul de 2% a fost suficient ca să dărâme site-ul. O protecție anti-DDoS care funcționează nu este același lucru cu o protecție anti-DDoS care ajunge, iar singurul mod de a ști diferența este să-ți fi măsurat propria capacitate, nu pe cea din fișa tehnică a furnizorului.
Protecția se contractează înainte de incident
Lecția practică ține de achiziții, nu de inginerie. Protecția anti-DDoS cumpărată în timpul incidentului ajunge târziu, costă mai mult și cere schimbări de DNS sau de rutare sub presiune, exact când omul care are credențialele de la registrar nu răspunde la telefon.
Patru lucruri trebuie să fie clare dinainte:
- Unde stă mitigarea. La furnizorul upstream, într-un CDN, într-un serviciu de scrubbing sau la propriul edge. Fiecare are alt traseu de activare și alt om care îl poate declanșa.
- Ce o declanșează. Un prag automat sau un telefon? Dacă e un telefon, al cui și care e numărul în afara programului?
- Ce capacitate ai cumpărat efectiv. Multe contracte acoperă atacuri volumetrice, dar nu și inundarea la nivel de aplicație a unui endpoint anume — adică exact ce înseamnă câteva zeci de mii de cereri HTTP bine formate.
- Dacă protecția acoperă și serviciile din spatele site-ului. Site-ul public este ținta vizibilă. Portalul în care se autentifică clienții, API-ul apelat de parteneri și gateway-ul de mail valorează de regulă mai mult și sunt adesea în afara contractului.
Geo-filtrarea este o decizie de business, cu clienți reali în spate
Răspunsul DNSC — acces doar din România, temporar — a fost proporțional pentru o autoritate națională al cărei public este covârșitor intern. Copiat fără gândire, transformă o întrerupere de 30 de minute într-o săptămână de reclamații.
Înainte de a fi nevoie, cineva din afara IT-ului trebuie să răspundă: din ce țări se conectează utilizatorii noștri legitimi, inclusiv angajații aflați în deplasare, partenerii, furnizorii și clienții din diaspora? Ce se rupe dacă tăiem restul — plăți, webhook-uri, monitorizare, integrări cu terți? Cine are dreptul să accepte compromisul ăsta la ora 17:00 într-o marți și cum anunțăm clienții afectați?
Geo-filtrarea este un instrument bun. Este și o decizie asumată de a face serviciul indisponibil pentru un set definit de oameni reali, iar decizia aparține businessului, stabilită din timp, nu improvizată de cine e de tură.
Când se raportează un incident de disponibilitate
Entitățile presupun frecvent că obligația de raportare apare doar la compromiterea datelor. Nu este așa. Art. 15 din OUG nr. 155/2024 stabilește secvența pentru un incident semnificativ, iar semnificația se evaluează inclusiv pe perturbarea operațională:
- O avertizare timpurie în 24 de ore de la momentul în care ai luat cunoștință de incidentul semnificativ.
- O notificare de incident în 72 de ore, cu o evaluare inițială care include gravitatea, impactul și, unde există, indicatorii de compromitere.
- Un raport intermediar doar dacă CSIRT-ul național îl solicită.
- Un raport final în 30 de zile — sau un raport de progres, dacă incidentul este încă în desfășurare.
Două detalii scurtează mult discuțiile interne. Primul: art. 15 alin. (3) prevede că raportarea în sine nu expune entitatea unei răspunderi sporite, deci „încă nu cunoaștem impactul complet" este un răspuns valid la 24 de ore. Al doilea: conform art. 15 alin. (9), CSIRT-ul național trebuie să răspundă în 24 de ore și să ofere, la cerere, îndrumare de atenuare — ceea ce face avertizarea timpurie utilă pentru tine, nu doar pentru autoritate.
O întrerupere de sub 30 de minute a unui site public nu va atinge, de multe ori, pragul de semnificație. Motivul pentru care tratezi întrebarea acum este că nimeni nu poate evalua un prag în mijlocul incidentului, cu site-ul căzut. Secvența primei ore e detaliată în prima oră a unei raportări la DNSC.
A testa un plan de continuitate înseamnă a degrada ceva
Un plan de continuitate care nu a fost niciodată exersat este un document, iar art. 21 cere măsuri care funcționează, cu testarea și auditarea eficacității lor printre elementele enumerate.
Exersarea disponibilității nu presupune să dobori producția. O secvență utilă:
- Testează la sarcină traseul real, nu un endpoint sintetic. Află unde se rupe site-ul tău și la ce rată de cereri — ca data viitoare, când vezi o cifră ca 50.000 de solicitări, să știi dacă e supraviețuibilă.
- Dă telefonul de activare. Sună linia de urgență a furnizorului anti-DDoS în timpul programului și vezi cine răspunde și ce îți cere. Multe echipe descoperă aici că persoana de contact din contract a plecat din companie.
- Repetă geo-filtrarea într-o fereastră de mentenanță, cu decidentul de business pe apel, și notează ce s-a rupt.
- Cronometrează traseul uman. De la alertă până la cineva autorizat să acționeze, în afara programului. Numărul acela, nu tehnologia de mitigare, îți dă de regulă durata întreruperii.
Un exercițiu de tip tabletop îmbunătățește pașii 2–4 mai mult decât orice unealtă. Partea care cere verificare tehnică — dacă edge-ul tău rezistă la ce crezi că rezistă — intră într-un test de penetrare pe infrastructură și într-o evaluare de vulnerabilități, iar partea de guvernanță și dovezi ține de audit, risc și conformitate.
Trendul din spatele incidentului
În același interviu, Câmpean a dat cifra care contează mai mult decât atacul în sine: în prima jumătate a anului 2026, DNSC a identificat și raportat mai multe incidente decât în tot anul precedent.
A descris onest și motivația. Atacurile DDoS de acest tip sunt frecvente, imensa majoritate nu au succes, iar scopul lor este reputațional — să transmită mesajul că infrastructura unei instituții este vulnerabilă, pentru a submina încrederea partenerilor, a publicului și a cetățenilor. Majoritatea sunt motivate ideologic, iar atacatorii anunță adesea din timp, pe forumuri, pe canale din dark net sau pe rețele sociale. Ultimul detaliu este acționabil: campaniile anunțate sunt o sursă de threat intelligence, iar faptul că știi că vine un val valorează mai mult decât orice control izolat.
Surse: Radio România Actualități — interviu cu Dan Câmpean, 9 septembrie 2026 · Economedia, 8 septembrie 2026
DNSC a descris evenimentul ca posibilitatea unui atac DDoS, pe baza datelor tehnice disponibile, și nu a publicat o atribuire. Volumele de trafic și țările sursă provin din declarațiile publice ale directorului general și nu au fost verificate independent.
Acest articol are caracter general de informare și nu constituie consultanță juridică sau de reglementare.