”Filosofia” pe care se bazează NIS2 este responsabilitatea managementului organizațiilor în relație cu riscurile IT care îi pot afecta pe beneficiarii serviciilor lor.

Responsabilitatea de a asigura securitatea rețelelor și a sistemelor informatice revine în mare măsură entităților esențiale și entităților importante. Ar trebui să se promoveze și să se dezvolte o cultură a gestionării riscurilor, care să implice evaluări ale riscurilor și aplicarea unor măsuri de gestionare a riscurilor în materie de securitate cibernetică adecvate riscurilor întâmpinate.

Măsurile de gestionare a riscurilor în materie de securitate cibernetică ar trebui să țină seama de gradul de dependență al entității esențiale sau al entității importante de rețelele și sistemele informatice și să includă măsuri pentru identificarea oricăror riscuri de incidente, prevenirea și detectarea incidentelor, răspunsul la incidente și redresarea în urma acestora, precum și pentru atenuarea impactului lor. Securitatea rețelelor și a sistemelor informatice ar trebui să includă securitatea datelor stocate, transmise și prelucrate. Măsurile de gestionare a riscurilor în materie de securitate cibernetică ar trebui să asigure o analiză sistemică, ținând seama de factorul uman, cu scopul de a obține o imagine completă privind securitatea rețelelor și a sistemelor informatice. – Cosiderent 77-78

Probabil în cadrul discuțiilor, legiuitorul european a concluzionat că nu va fi deloc simplu de pus în practică și a decis că

membrii organelor de conducere din cadrul entităților esențiale și al entităților importante au obligația de a urma o formare pentru a dobândi suficiente cunoștințe și competențe pentru a putea identifica riscurile și a evalua practicile de gestionare a riscurilor în materie de securitate cibernetică și impactul acestora asupra serviciilor pe care le furnizează entitatea – Art. 20 (2)

Toate acestea pentru a

se asigura că entitățile esențiale și entitățile importante iau măsuri tehnice, operaționale și organizatorice adecvate și proporționale pentru a gestiona riscurile la adresa securității rețelelor și a sistemelor informatice pe care entitățile respective le utilizează pentru operațiunile lor sau pentru a furniza servicii și pentru a preveni sau reduce la minimum impactul incidentelor asupra beneficiarilor serviciilor lor și asupra altor servicii. – Art. 21 (1)

Realizată corect, estimarea (risk assessment – identificarea posibilelor scenarii de risc) și evaluarea riscurilor (pentru scenariile identificate anterior se atribuie probabilități și impact) poate dura și un an de zile pentru anumite organizații.

Pentru ”organele de conducere” care nu au mai avut tangență cu evaluarea riscurilor de securitate punctul critic îl reprezintă criteriile de acceptare a riscurilor. Activitatea de acceptare a riscurilor trebuie să se asigure că riscurile reziduale sunt acceptate în mod explicit de către ”organul de conducere”. Acest lucru este deosebit de important în situațiile în care implementarea controalelor este refuzată sau amînată de exemplu din cauza costurilor de implementare a controalelor (un SIEM costă X mii euro versus factura lunară la energie electrică care costă aceeași sumă, sumă care nu a fost prinsă în buget). Căci eu, analist de risc pot să propun ceva dar ”responsabilul de proces”/managerul unității funcționale/”risk owner” să spună că nu este de acord. Firesc.

Din teoria generală, din standarde și metodologii știm că aceste criterii depind de mediul organizației, scopurile, obiectivele și interesele părților interesate ale acesteia. Prin urmare nu avem criterii obiective de acceptare/praguri și general valabile. Criteriul clasic de acceptare, pe care îl folosim cu toții în viața de zi cu zi este ”ce cîștig (care este profitul/beneficiul) și ce pierd/pățesc”. Doar că în cazul unei organizații, atunci cînd ești ”organ de conducere” apare un ”influencer”: acolo unde există o cerință de conformitate există tendința de a evalua riscul ca fiind mai mare iar acolo unde ”recompensa” este satisfăcătoare să îl acceptăm….Este dovedit științific. Mai mult, nu putem folosi aceleași criterii de acceptare în întrega organizație, pentru toate unitățile funcționale (să ne aducem aminte din BIA că întreruperea funcționării unui echipament, fie el și IT nu are același impact în toată organizația).
Revenind la NIS2, un risc nu ar trebui acceptat dacă există o cerință legală( cu excepția situației în care beneficiile sînt mai mari decît sancțiunea? 🙂 ). Considerentul 79 oferă indicații despre scenariile minime care trebuie evaluate:

Întrucât amenințările la adresa securității rețelelor și a sistemelor informatice pot avea origini diferite, măsurile de gestionare a riscurilor în materie de securitate cibernetică ar trebui să fie bazate pe o abordare multirisc, care vizează protecția rețelelor și a sistemelor informatice și a mediului fizic al acestor sisteme împotriva unor evenimente cum ar fi furturile, incendiile, inundațiile, defecțiunile la nivelul telecomunicațiilor sau al alimentării cu energie, accesul fizic neautorizat și deteriorarea și interferența la nivelul informațiilor deținute de o entitate esențială sau de o entitate importantă sau al echipamentelor entității respective de prelucrare a informațiilor, care ar putea compromite disponibilitatea, autenticitatea, integritatea sau confidențialitatea datelor stocate, transmise sau prelucrate sau a serviciilor oferite de rețelele și sistemele informatice sau accesibile prin intermediul acestora. Prin urmare, măsurile de gestionare a riscurilor în materie de securitate cibernetică ar trebui să abordeze, de asemenea, securitatea fizică și a mediului în cazul rețelelor și al sistemelor informatice prin includerea unor măsuri pentru a le proteja împotriva defecțiunilor de sistem, a erorilor umane, a acțiunilor răuvoitoare sau a fenomenelor naturale,

Important este să se scrie o justificare pentru orice risc care este acceptat dincolo de criteriile stabilite.