Din perspectiva auditului, „indicatorii de control„ menționați în Normele emise de CERT reprezintă „probe„ prin care se dovedește îndeplinirea cerințelor minime. Anul acesta nu a fost nevoie de audit. Dar va veni și acel moment. Este posibil să apară din nou scuza cu „nu am avut timp„/„nu am știut„/„nu am avut buget„.

Exemplu 1: Articolul 11 – Gestionarea activelor

 OSE stabilește un cadru adecvat pentru identificarea, clasificarea și implementarea unui inventar al proceselor IT, sistemelor și elementelor componente ale rețelelor și sistemelor informatice.(…)

Indicatori de control. LASPO (lista activelor, sistemelor și proceselor organizației); PRECDI (procedură privind etichetarea și clasificarea datelor și informațiilor).

Din punct de vedere tehnic, pentru OSE cu un număr mare de active, ar trebui să existe o soluție software de tip „asset management„. O astfel de soluție ar rezolva și partea documentară. Mai mult, pe lîngă partea propriu zisă de inventariere ar oferi suport și pentru alte procese: change management, patch, vulnerability etc.

Din punct de vedere documentar/formal, minimal LASPO ar trebui să includă:

1. Pentru echipamentele fizice
   • ID;
   • Denumire
   • Serial number;
   • Localizare/amplasare
   • Adresa IP și adresa HW
   • Responsabilul echipamentului (nu cel care se ocupă de gestiunea contabilă): nume, departament, date de contact (telefon, email)
   • Clasa din care face parte conform procedurii de clasificare (PRECDI)
2. Pentru software
   • detalii tehnice relevante
   • Responsabil cu nume, departament, date de contact
   • Clasificare conform PRECDI și procesele critice în care este utilizat
   • Unde se poate, tipul de suport din partea furnizorului
3. Pentru procese
   • Lista proceselor/harta proceselor
   • Responsabilul de proces

Testarea acestui tip de control din partea auditorului nu presupune doar verificarea existenței fizice a LASPO („compliance„) ci testarea prin sondaj a realității informațiilor înregistrate („substantive„) astfel încît să se poată concluziona că LASPO nu este doar un document.

Exemplul 2: Articolul 28 – Managementul vulnerabilităților și alertelor de securitate

OSE elaborează, actualizează și implementează, în conformitate cu PONIS (politica de securitate a rețelelor și sistemelor informatice care asigură furnizarea serviciilor esențiale), o procedură pentru detectarea alertelor și incidentelor de securitate care afectează rețelele și sistemele informatice.

1. PRODAIS prevede măsuri organizatorice și tehnice destinate detectării alertelor și incidentelor de securitate care afectează rețelele și sistemele informatice.
– Măsurile organizatorice includ procedurile de operare pentru dispozitivele de detectare și descriu lanțul de procesare pentru evenimentele de securitate identificate de aceste dispozitive.
– Măsurile tehnice specifică natura și poziționarea dispozitivelor de detectare.

2. OSE instituie un sistem de detectare a incidentelor și alertelor de securitate.
– Dispozitivele de detecție analizează fluxurile de date care tranzitează rețelele și sistemele informatice pentru a identifica evenimente care ar putea afecta rețelele și sistemele informatice.
– Atunci când acest lucru nu este posibil din motive tehnice, operatorul descrie în MANIS motivele tehnice care au împiedicat utilizarea dispozitivelor de detecție.

Indicatori de control. PRODAIS (procedură pentru detectarea incidentelor de securitate care afectează rețelele și sistemele informatice); SIENIS (sistem de înregistrare evenimente la nivelul rețelelor și sistemelor informatice); MANIS (mapa de acreditare de securitate; document în baza căruia se emite DANIS – decizia de acreditare; decizie formală luată de managementul de nivel înalt al OSE); PEIREV (proces de identificare, clasificare, remediere și eliminare a vulnerabilităților, în special în software și firmware, la nivelul rețelelor și sistemelor informatice); PGMAVU (program pentru managementul vulnerabilităților în rețelele și sistemele informatice); ARNIS (analiza riscurilor de securitate a rețelelor și sistemelor informatice, document elaborat la nivelul OSE, prin care sunt identificate elementele critice care stau la baza furnizării serviciului esențial și sunt identificate principalele riscuri în vederea gestionării și diminuării acestora).

Știm că simpla existență a unei vulnerabilități nu este un lucru grav pentru că vulnerabilități există dincolo de voința noastră. Le întîlnim la nivel:

• Organizare;
• Procese și proceduri
• Activitățile de rutină
• Colaboratori/furnizori
• Mediul fizic
• Configurări ale echipamentelor sau soluțiilor software
• …..

Lucrurile se complică în momentul în care se identifică amenințări care pot exploata vulnerabilitățile. Cam asta este deosebirea: un malware acționează (aproape)imediat ce ajunge în sistem pe cînd vulnerabilitatea este o problemă potențială (lipsa unui patch). În 2020 au fost publicate 10.363 CVE cu o severitate medie de 7.1 din 10.

Articolul 28 face referire și la SIENIS (Art. 29 care se referă la SIEM!).

În concluzie, pe lîngă partea documentară (program, procedură etc.) din punct de vedere tehnic OSE:

• fie are propria soluție pentru managementul vulnerabilităților
• fie achiziționează astfel de servicii (dar nu de la același furnizor care va realiza și auditul 🙂 )

În oricare din cazuri, detalile tehnice vor fi prezentate în PRODAIS și PGMAVU. Procedura trebuie să includă modul în care se tratează vulnerabilitățile identificate. Existența unor proceduri și a unui raport de scanare nu garantează că aceste controale își ating obiectivele. Testarea controalelor din perspectiva auditului implică revizuirea procedurilor și a unui raport de scanare a vulnerabilităților („compliance„) și verificarea (în totalitate sau prin sondaj) modului în care acestea au fost tratate (remediate) prin raportare la prevederile procedurilor. („substantive„)

_____________________

Înregistrarea OSE s-a făcut în acest an pe baza autoevaluării. Anul 2021 ar trebui să fie despre buget și soluții tehnice.