Cele mai utile controale NIS2 sunt cele care reduc întâi expunerea materială: identitatea și accesul privilegiat, continuitatea și restaurarea, logging-ul și monitorizarea, răspunsul la incidente și riscul furnizorilor. Fiecare trebuie să aibă owner, criteriu de eficacitate, frecvență de verificare și dovezi.
Un incident nu devine critic fiindcă lipsește o politică.
Devine critic când un cont privilegiat este compromis, când backupul nu poate fi restaurat în timpul necesar sau când echipa nu are suficiente date pentru a înțelege ce s-a întâmplat.
De aceea, controalele NIS2 prioritare nu trebuie tratate ca o listă extinsă de cerințe implementate simultan.
Prioritatea trebuie acordată măsurilor care reduc mai întâi expunerea materială și care pot fi demonstrate prin dovezi verificabile.
Pentru organizațiile din energie, sănătate, transport, servicii financiare, industrie, servicii digitale sau infrastructură publică, ordinea exactă depinde de servicii, active, date și scenarii de întrerupere.
Totuși, anumite zone apar constant într-o evaluare serioasă: identitatea, privilegiile, continuitatea, detectarea, răspunsul la incidente și riscul furnizorilor.
01. Cum se stabilesc controalele NIS2 prioritare
NIS2 cere organizațiilor relevante să implementeze măsuri de gestionare a riscurilor de securitate cibernetică adecvate și proporționale.
Directiva introduce și responsabilitate la nivelul organelor de conducere pentru aprobarea și supravegherea acestor măsuri.
În practică, organizația nu ar trebui să înceapă cu întrebarea: „ce politică mai trebuie să redactăm?”.
Întrebarea utilă este: ce scenariu ne poate opri serviciul, afecta clienții sau obliga să gestionăm și raportăm un incident?
Prioritizarea trebuie să țină cont de impactul operațional, exploatabilitatea expunerii, viteza cu care atacatorul poate escalada și capacitatea reală de recuperare.
Un mediu Microsoft 365 cu MFA aplicată incomplet pentru utilizatori, administratori sau acces extern poate avea o expunere mai urgentă decât o procedură care necesită doar actualizare editorială.
Similar, existența unui backup nu este suficientă dacă restaurarea nu a fost testată față de RTO și RPO aprobate de business.
Un assessment util corelează fiecare constatare cu:
- serviciul afectat;
- activul expus;
- scenariul de amenințare;
- impactul de business;
- ownerul măsurii;
- termenul de remediere;
- dovada care confirmă închiderea.
Regulamentul de punere în aplicare (UE) 2024/2690, aplicabil anumitor categorii de entități digitale prevăzute de NIS2, detaliază această logică prin risk assessment, risk treatment, prioritizarea măsurilor, responsabilități și acceptarea riscului rezidual.
Vezi: Regulamentul de punere în aplicare (UE) 2024/2690 .
Criteriul de decizie: impact, exploatabilitate, dovadă
Un control merită tratat prioritar atunci când reduce un risc exploatabil în prezent, protejează un proces critic și poate fi implementat fără a introduce o dependență necontrolată.
De exemplu, eliminarea conturilor administrative partajate și activarea accesului privilegiat just-in-time pot reduce rapid suprafața de atac.
Dar măsura trebuie adaptată contextului.
Într-un mediu industrial sau într-o organizație cu aplicații legacy, implementarea PIM/JIT trebuie validată atent pentru a evita blocarea unor intervenții operaționale.
Dovada este al treilea criteriu.
Dacă organizația afirmă că patchingul este realizat, trebuie să poată demonstra inventarul de active, acoperirea, excepțiile aprobate, rapoartele de conformitate și remedierea întârzierilor.
O recomandare nu este suficientă.
Controlul trebuie să lase dovezi.
02. Identitate, MFA și acces privilegiat
Identitatea este unul dintre cele mai importante perimetre de apărare pentru organizațiile moderne.
Phishingul, reutilizarea parolelor, token theft și compromiterea conturilor administrative pot oferi acces direct către date, cloud și sisteme de business.
Controlul prioritar nu este doar „MFA activ”.
Pentru scenariile cu impact ridicat trebuie evaluate metode de autentificare rezistente la phishing, în special pentru administratori și alte identități cu acces sensibil.
Aplicarea trebuie să fie consecventă pentru accesul cloud, accesul extern și celelalte identități relevante, iar excepțiile trebuie limitate, justificate și revizuite.
Un grup exclus permanent dintr-o politică Conditional Access poate transforma o excepție operațională într-o expunere persistentă.
Pentru privilegii, organizația trebuie să distingă între conturile standard și cele administrative, să evite conturile administrative partajate, să aplice least privilege și să revizuiască periodic drepturile acordate.
PIM și accesul Just-In-Time sunt relevante mai ales în mediile Microsoft 365, Azure și alte platforme cloud unde privilegiile extinse nu trebuie să rămână active permanent.
Dovezi utile
- inventarul identităților privilegiate;
- role assignments;
- configurația Conditional Access;
- rapoarte de autentificare;
- excepții aprobate și termene de expirare;
- activări PIM/JIT;
- access reviews și recertificări.
03. Backup, restaurare și continuitate testată
Backupul nu devine automat un control de continuitate doar pentru că joburile rulează cu succes.
Organizația trebuie să poată demonstra că aplicațiile critice, configurațiile, datele și dependențele relevante pot fi recuperate în timpul acceptat de business.
Primul pas este identificarea serviciilor critice și a dependențelor acestora:
- infrastructură;
- aplicații;
- baze de date;
- configurații de rețea;
- identitate;
- servicii SaaS;
- furnizori externi.
Pentru fiecare serviciu, RTO și RPO trebuie validate cu ownerii de business, nu presupuse unilateral de IT.
Dacă un sistem poate fi pornit tehnic în patru ore, dar reconcilierea și validarea datelor necesită două zile, timpul real de recuperare este mai mare decât timpul de restaurare tehnică.
Testele de restore trebuie să producă dovezi clare:
- scenariul testat;
- data testului;
- sistemele și datele implicate;
- timpul efectiv de restaurare;
- diferențele față de RTO/RPO;
- problemele identificate;
- ownerul acțiunii;
- termenul de remediere.
Copiile imutabile sau segregate pot reduce riscul de compromitere a backupului în scenarii ransomware, dar nu înlocuiesc testarea recuperării.
La fel, un plan de continuitate bine redactat nu înlocuiește un exercițiu în care sunt testate deciziile, escaladarea și comunicarea.
04. Logging, monitorizare și capacitatea de investigație
Fără logging suficient, organizația poate avea un incident în desfășurare fără să îl poată confirma, delimita sau reconstrui.
Aceasta afectează atât răspunsul tehnic, cât și deciziile managementului și capacitatea de a susține o raportare cu informații credibile.
Prioritatea nu este colectarea nelimitată de loguri.
Prioritatea este acoperirea surselor care permit detectarea și investigarea scenariilor relevante.
În funcție de infrastructură, acestea pot include:
- identitate și autentificări;
- acțiuni administrative și privilegiate;
- endpoint-uri;
- email și collaboration;
- firewall și VPN;
- platforme cloud;
- sisteme critice;
- platforme de backup;
- accesul furnizorilor.
Retenția trebuie corelată cu timpul realist în care un incident poate fi descoperit și investigat.
O perioadă foarte scurtă de retenție poate elimina exact informația necesară pentru a reconstrui o compromitere persistentă sau o mișcare laterală.
Monitoring fără ownership nu este control
Organizația trebuie să poată răspunde simplu:
- cine analizează alertele;
- în ce interval;
- ce evenimente trebuie investigate obligatoriu;
- când se face escaladarea;
- cum sunt documentate deciziile;
- cum sunt urmărite false positive-urile și excepțiile.
Un SIEM sau un EDR licențiat, fără acoperire verificată și fără un proces operațional de răspuns, demonstrează existența tehnologiei, nu eficacitatea controlului.
05. Răspuns la incidente și disciplina de raportare
NIS2 introduce obligații de notificare pentru incidentele semnificative și impune organizațiilor relevante să poată reacționa într-un interval foarte scurt.
Pentru management, problema nu este însă doar termenul legal.
Problema este dacă organizația poate identifica incidentul, evalua impactul, conserva informațiile relevante și lua decizii fără blocaje de autoritate.
NIS2 prevede, pentru incidentele semnificative, o abordare etapizată care include o avertizare timpurie în termen de 24 de ore și o notificare a incidentului în termen de 72 de ore, urmate de raportarea ulterioară prevăzută de directivă.
Vezi cerințele oficiale în Directiva (UE) 2022/2555 — Articolul 23 .
Planul de răspuns la incidente trebuie să definească:
- rolurile tehnice;
- responsabilitățile managementului;
- rolul juridic și de compliance;
- comunicarea internă și externă;
- criteriile de clasificare;
- contactele de escaladare;
- conservarea dovezilor;
- continuitatea serviciilor;
- relația cu furnizorii și autoritățile relevante.
Într-un incident real, lipsa unui owner clar pentru decizia de izolare poate prelungi expunerea cu ore critice.
Tabletop exercise: testarea deciziei, nu a prezentării
Exercițiile tabletop sunt utile atunci când folosesc scenarii plauzibile pentru organizație.
Exemplele pot include compromiterea unui administrator, exfiltrarea de date, ransomware într-un sistem critic sau indisponibilitatea unui furnizor cloud.
Rezultatul nu trebuie să fie doar o prezentare.
Trebuie să rămână minute, decizii, probleme identificate, acțiuni corective, owneri și termene.
06. Furnizori, acces extern și dependențe critice
O organizație poate avea controale interne bune și totuși să rămână expusă printr-un furnizor.
Un acces VPN permanent, un administrator extern insuficient protejat sau o aplicație SaaS critică fără cerințe clare privind continuitatea și notificarea incidentelor pot deveni puncte importante de risc.
NIS2 include explicit securitatea lanțului de aprovizionare în măsurile de management al riscurilor de securitate cibernetică.
Evaluarea nu trebuie redusă la colectarea formală a unui chestionar anual.
Organizația trebuie să înceapă prin clasificarea furnizorilor în funcție de:
- accesul la sisteme;
- accesul la date;
- criticitatea serviciului;
- impactul indisponibilității;
- nivelul de substituibilitate;
- dependențele și subcontractorii relevanți.
Un furnizor de mentenanță cu acces la infrastructura de producție nu trebuie tratat identic cu un furnizor fără acces la sisteme sau informații sensibile.
Contractele și procesele de vendor management trebuie să trateze, după caz:
- cerințele minime de securitate;
- notificarea incidentelor;
- drepturile de audit sau evaluare;
- subcontractarea;
- continuitatea serviciului;
- returnarea sau ștergerea datelor;
- revocarea accesului la încetarea colaborării.
Pentru accesul extern, identitatea trebuie să fie nominativă, privilegiul limitat la necesar, accesul limitat în timp acolo unde este posibil și activitatea monitorizată.
Dovezile pentru supplier risk
- registrul furnizorilor critici;
- clasificarea acestora;
- evaluările de risc;
- aprobările pentru acces;
- revizuirile periodice;
- clauzele contractuale;
- rezultatele controalelor și remedierea constatărilor.
07. De la măsură implementată la control demonstrabil
Ordinea sănătoasă este: assess → prioritize → implement → evidence.
Mai întâi se identifică expunerea și controlul existent.
Apoi se prioritizează riscurile materiale.
Implementarea trebuie să aibă owner, termen, dependențe și criteriu de acceptare.
La final, organizația verifică eficacitatea și păstrează dovezile necesare pentru management, clienți și auditatori.
Această abordare este reflectată și în Regulamentul (UE) 2024/2690, care pentru entitățile cărora li se aplică cere documentarea evaluărilor de risc, a planului de tratare și a responsabilităților, precum și evaluarea eficacității măsurilor.
ENISA oferă, pentru aceleași categorii de entități, ghidaj tehnic privind implementarea și exemple de evidence care pot susține aceste controale.
Vezi: ENISA NIS2 Technical Implementation Guidance .
Nu toate controalele pot fi implementate cu aceeași viteză.
MFA și curățarea privilegiilor pot avea efect relativ rapid.
Segmentarea rețelei, modernizarea aplicațiilor legacy sau schimbarea unui furnizor critic pot necesita investiții, testare și decizii de business.
Diferența esențială este ca riscul rezidual să fie explicit, acceptat la nivelul potrivit și urmărit până la reducere.
NIS2 nu se măsoară în numărul de politici publicate
Un program NIS2 matur trebuie să poată răspunde simplu și documentat la întrebări dificile.
Cine are acces privilegiat?
Ce evenimente sunt monitorizate?
Cât de repede putem recupera serviciile critice?
Cine poate decide izolarea unui sistem într-un incident?
Ce furnizori pot afecta direct operațiunile?
Ce dovezi arată că măsurile implementate funcționează în realitate?
Acesta este punctul de plecare pentru control real: nu conformitate decorativă, ci risc redus, responsabilitate clară și evidence verificabil.