Deși legislația poate duce la o astfel de concluzie, abordarea auditorului în misiunile de verificare a conformității pe legea NIS nu va fi una de tip top/down (cascadă) ci mai degrabă ”agilă”: există un punct de început, dar de acolo revizia nu mai ”curge” liniar.

Anexa nr. 9 La Regulamentul pentru atestarea și verificarea auditorilor de securitate cibernetică precizează:

Activitățile tehnice descrise la [CAS1] până la [CAS4] nu exclud evaluarea securității organizației, respectiv securitatea logică și fizică a domeniului auditat. Această evaluare constă în verificarea faptului că politicile și procedurile de securitate definite pentru asigurarea cerințelor minime de securitate a rețelelor și sistemelor informatice auditate sunt conforme cu nivelul tehnicii.

În articolul precedent scriam despre cum se ”unesc punctele” și că unul dintre puncte este ”inventarul activelor” atunci cînd avem în vedere (nu doar) ”evaluarea riscurilor”. Din punct de vedere al implementării, procesele descrise în COBIT 2019 (de exemplu, pentru că apare în Lista standardelor publicată de DNSC și la care OSE trebuie să se raporteze în implementarea cerințelor minime de securiatte) ajută foarte mult la formalizarea unui program de securitate coerent cu roluri și responsabilități bine definite. CAS 5 precizează că auditorul de securitate cibernetică trebuie:

să analizeze organizarea securității rețelelor și sistemelor informatice pe baza standardelor tehnice și de reglementare stabilite în Lista standardelor și specificațiilor europene și internaționale (LSSEINIS), în conformitate cu cerințele minime de securitate aplicabile operatorilor de servicii esențiale, respectiv furnizorilor de servicii digitale;

Consider că acțiunile descrise în Anexa 9 sînt minimale. Abordarea auditorului va fi una ”bazată pe riscuri” ceea ce înseamnă că nu se va limita la cele indicate în Regulament ci va avea și porpria judecată profesională.

Continuînd exemplul cu ”inventarului activelor” (hardware, software, resurse umane), auditorul va solicita (sau cel puțin așa ar trebui) o copie a inventarului sau acces la aplicația folosită în acest scop (acces = va vizualiza modul de lucru al aplicației, responsabilul aplicației fiind cel care execută instrucțiunile auditorului). Va revizui, cel puțin:

• activele incluse în inventar includ și apetitul la risc al organizației – care sînt activele importante (”sensitive assets”) – clasificarea acestora în funcție de valoarea pentru organizație și criticalitate. Aici adaug că mai înainte a verificat dacă evaluarea de riscuri este conformă cu metodologia asumată de management;
• completitudinea informațiilor despre active (de exemplu id, localizare, furnizor, versiune, responsabil);
• faptul că actualizarea inventarului se face în timp util (frecvența actualizărilor);
• cum se identifică active neautorizate în infrastructură?

Apoi, pentru infrastructura critică auditată va corela informațiile din inventar cu evaluarea riscurilor, diagramele fluxurilor de date (DFD) și diagramele de rețea (logical network diagram). Va ajunge la un activ critic (să spunem switch, firewall sau server) care trebuie să aibă un ”responsabil”/owner cu responsabilități și sarcini bine definite (într-o procedură ar trebui să existe și ”RACI chart”). Autorizarea responsabilului și accesului acestuia (contului asociat identității primare a acelui responsabil) ar trebui să fie tratată într-o procedură de ”identity account”/”privilege account”. Dacă este doar un singur angajat care se ocupă de administrarea echipamentului ar trebui să existe și ”break glass account” (cerințele de la B2)

Apoi se trece la tehnicisme:

• Cum este realizată segmentarea rețelei?
• firewallul are facilități de IPS (pentru că există cerința existenței unui senzor de detecție a intruziunilor) sau nu?
• cum se face filtrarea traficului și accesul la/prin VPN?
• DMZ….

Tot prin lista de active vor fi și niște servere…..”Punctele” de mai sus se unesc și cu ”patch management” și cu ”incident management”, ”SIEM” și…..”pen test” (care va avea în vedere toate cele trei caracteristici ale securității – CIA). Să nu uităm că mai există și furnizori în această poveste.

După ce termină de revizuit fiecare zonă, auditorul ajunge la niște concluzii și face recomandări. Are însă acum o obligație: atunci cînd identifică vulnerabilități să stabilească și impactul acestora în conformitate cu scala din Anexa 10. Vulnerabilitățile vor fi clasificate în funcție de riscul pe care îl prezintă pentru rețelele și sistemele informatice, adică în funcție de impactul vulnerabilității asupra acestora și dificultatea de furnizare a serviciului esențial/digital.

Exemple de riscuri posibile pentru cazul de mai sus:

• dezvăluirea informațiilor privilegiate (C)
• defectarea/indisponibilitatea bunurilor fizice (A)
• încălcarea cerințelor de reglementare
• întreruperea traficului de rețea, ceea ce duce la incapacitatea de a îndeplini funcțiile critice ale OSE (A)
• infectarea sistemelor informatice cu malware care perturbă procesarea (I, A)
• utilizarea rețelei ca rampă de lansare pentru activități rău intenționate împotriva altor organizații (și potențialul de a fi tras la răspundere pentru daunele acestora) (I)