Intrarea în vigoare a Legii nr. 294/2024 privind reziliența entităților critice, alături de OUG nr. 155/2024, schimbă semnificativ modul în care organizațiile care furnizează servicii esențiale trebuie să privească infrastructura IT și OT. Dacă OUG 155/2024 este orientată către securitatea rețelelor și sistemelor informatice, Legea 294/2024 introduce perspectiva rezilienței serviciului esențial.

Organizația trebuie să poată demonstra că serviciile sale critice pot continua sau pot fi restabilite într-un interval acceptabil chiar și atunci cînd infrastructura IT, OT, comunicațiile, energia sau alți furnizori critici sînt afectați.

Două perspective

Cele două acte normative nu trebuie privite ca două regimuri de conformitate complet separate. Ele abordează riscul din perspective diferite, dar complementare.

Domeniu	OUG 155/2024 / NIS2	Legea 294/2024 / CER
Obiectiv principal	Securitatea rețelelor și sistemelor informatice	Continuitatea și reziliența serviciului esențial
Cybersecurity	Direct	Integrată în perspectiva generală de reziliență
IT/OT	Protejarea sistemelor și rețelelor	Capacitatea sistemelor de a susține serviciul în situații de criză
Evaluarea riscurilor	”al hazards” dar asociate securității cibernetice	„all-hazards”: cyber, fizic, energie, dezastre, personal etc.
Continuitate și Disaster Recovery	Componentă a managementului riscului cyber	Componentă centrală a rezilienței
Perspectivă	„Cum împiedicăm compromiterea sistemului?”	„Cum continuăm serviciul dacă sistemul devine indisponibil?”

Legislația subsecventă Legii 294/2024 clarifică relația dintre cele două cadre: pentru componenta de securitate cibernetică, măsurile de reziliență sînt implementate în conformitate cu OUG 155/2024 (Cyfun) și cu cerințele autorităților sectoriale. Organizațiile nu trebuie să construiască două sisteme paralele de cybersecurity. Provocarea este integrarea cybersecurity în sistemul de management al rezilienței. (N.M: așa cum de fapt este scris în teorie de zeci de ani)

Evaluarea riscurilor

Dacă se păstra cumva viziunea că ”evaluarea riscurilor este treaba IT-ului”, una din consecințele Legii 294/2024 este schimbarea perspectivei asupra riscului. Evaluarea nu se mai limitează la întrebarea

„Ce amenințări pot compromite sistemele informatice?”

Acum trebuie căutat răspunsul și la întrebarea:

„Ce se întâmplă cu serviciul esențial dacă sistemele IT nu mai sînt disponibile?”

Din perspectiva IT, apar întrebări/scenarii precum:

• Ce se întâmplă cu serviciul esențial dacă infrastructura/serviciul de management al identității (de exemplu) devine indisponibilă?
• Ce se întâmplă dacă organizația pierde comunicațiile dintre sediul central și punctele operaționale?
• Ce se întâmplă dacă sistemele SCADA sau alte platforme OT devin indisponibile?
• Ce se întâmplă dacă centrul de date este inaccesibil?
• Ce se întâmplă dacă serviciile de telecomunicații sînt întrerupte?
• Ce se întâmplă dacă un furnizor IT critic nu mai poate presta serviciile contractate?
• ….

Business Continuity și Disaster Recovery

În multe organizații, Disaster Recovery este tratat tradițional ca o responsabilitate exclusiv tehnică: backup, replicare, servere redundante și restaurarea datelor. Legea 294/2024 împinge însă organizațiile către o abordare orientată către serviciul furnizat, nu doar către infrastructură: un backup existent nu demonstrează automat reziliența (aducere aminte incidentul ANCPI). Trebuie stabilit:

Serviciu esențial – proces critic – sistem IT/OT – infrastructură – dependențe – RTO/RPO – soluție alternativă – procedură de recuperare.

Întrebarea nu mai este „Putem recupera serverul?”, ci „Putem restabili serviciul în intervalul necesar organizației?” Și așa ajungem din nou de fapt la …BIA (Analiza de impact asupra activității)

Dependențe

Un alt efect este necesitatea identificării dependențelor dintre infrastructuri. Un serviciu esențial poate depinde de un lanț precum:

Telecomunicații – firewall/VPN – infrastructură IT –  sistem de control –  echipamente OT –  proces operațional –  serviciu esențial

O defecțiune într-un singur punct poate afecta întregul serviciu. Analiza rezilienței trebuie deci să identifice Single Points of Failure și să determine dacă există soluții alternative. Granița tradițională dintre IT și OT devine din ce în ce mai puțin relevantă. Din perspectiva rezilienței, contează întregul lanț tehnic care permite furnizarea serviciului.

Testare

Existența documentației nu este suficientă (cum se știe deja din legislația NIS2). O organizație poate avea un BCP și un DRP foarte bine redactate și, în același timp, să descopere în timpul unui incident că procedurile nu pot fi executate, backupurile nu pot fi restaurate sau infrastructura alternativă nu poate prelua sarcina. Din acest motiv, testele de reziliență trebuie construite pe scenarii realiste și nefavorabile.

Organizația trebuie să poată răspunde la cîteva întrebări de bază:

• Putem continua serviciul?
• Pentru cât timp?
• În ce regim degradat putem funcționa?
• Ce funcții trebuie recuperate primele?
• În cît timp putem reveni la funcționarea normală?

Testele, de obicei, scot la iveală probleme care nu sînt evidente într-o evaluare pur teoretică: lucruri/resurse inaccesibile în situații de urgență, documentație în format electronic disponibilă doar pe infrastructura afectată, dependențe necunoscute, furnizori indisponibili, lipsa accesului alternativ sau proceduri manuale care nu au fost niciodată testate etc.

Inventarul activelor

OUG 155/2024 impune deja organizațiilor vizate o abordare structurată a managementului riscurilor de securitate cibernetică. Legea 294/2024 adaugă însă o întrebare suplimentară (care în securitate poate fi omisă dacă nu se face BIA):

Care dintre activele IT și OT sînt necesare pentru furnizarea serviciului esențial și ce se întâmplă dacă acestea nu mai sînt dispponibile?

Inventarul activelor tehnic clasic poate indica serverul, sistemul de operare, adresa IP, proprietarul tehnic și versiunea software. Pentru reziliență sînt necesare însă informații suplimentare. Abordarea este cea din …..BIA:

Serviciu esențial – proces critic – aplicație/sistem –  infrastructură – furnizor – dependențe – impact – RTO/RPO – soluție alternativă.

Un exemplu

Să presupunem că o entitate critică utilizează un sistem centralizat de monitorizare și control pentru o infrastructură distribuită geografic. Din perspectiva OUG 155/2024 (Cyfun), organizația trebuie să analizeze, cel puțin aspecte precum:

• segmentarea rețelelor IT și OT;
• autentificarea și controlul accesului;
• managementul vulnerabilităților și actualizărilor;
• monitorizarea și jurnalizarea;
• backupul;
• gestionarea incidentelor;
• securitatea accesului furnizorilor;
• riscurile din lanțul de aprovizionare.

Perspectiva Legii 294/2024 introduce însă o întrebare suplimentară:

Dacă sistemul centralizat devine complet indisponibil pentru 24, 48 sau 72 de ore, mai poate organizația furniza serviciul esențial la un nivel acceptabil? (Cum Anexa cu efectul perturbator este clasificată și nu este publică, nu cunosc ce scrie acolo)

Răspunsul conduce la implementarea:

• redundanță;
• proceduri de operare manuală;
• comunicații alternative;
• backup offline;
• restaurări testate periodic;
• infrastructură de rezervă;
• alimentare electrică alternativă;
• acces de urgență;
• documentație disponibilă offline;
• exerciții comune IT–OT–operațional;
• proceduri pentru funcționarea în regim degradat.

Diferența este subtilă, dar fundamentală: cybersecurity încearcă să reducă probabilitatea și impactul compromiterii sistemului în timp ce reziliența presupune că incidentul SE POATE PRODUCE ORICUM și întreabă cum continuă organizația să funcționeze.