Cerințele minime de asigurare a securității OSE publicate în ordinul 1323/2020 sînt ”controale”.

Auditorul de securitate cibernetică (sau auditorul intern) trebuie să testeze aceste controale:

• testarea proiectării (TOD- test of design) – validează că un control care este declarat a fi pus în aplicare de către OSE a fost într-adevăr stabilit și pus în aplicare.
• testarea eficacității (TOE-test of efectiveness) – controlul a funcționat/funcționează sau nu în mod consecvent în perioada de timp auditată. Spus altfel, acel control, odată pus în practică, își atinge obiectivele.

Cum însă Ordinul 1323 impune care sînt controalele pe care trebuie să le implementeze OSE (incluse în mapa de acreditare), rezultă că auditorul nu va trebui să decidă controalele ce trebuie testate ci doar să realizeze testarea acestora.

Să luăm ca exemplu ”asigurarea continuității și recuperarea în caz de dezastru:

• Măsura de securitate D11 – Asigurarea disponibilității serviciului esențial și a funcționării rețelelor și sistemelor informatice  impune existența PRADE – procedură privind managementul asigurării disponibilității serviciului esențial, în caz de incident de securitate cibernetică 
• Măsura de securitate D12 – Managementul recuperării datelor în caz de dezastre impune existența PROMRE – procedură privind managementul recuperării datelor în caz de dezastre, precum și în caz de incidente severe de securitate cibernetică 
• Măsura de securitate: D21 Organizarea gestionării crizelor impune existența PROCIS – procedură privind organizarea gestionării crizelor în caz de incidente de securitate cibernetică pentru asigurarea continuității activităților organizaționale și PEGEC – procese de gestionare a crizelor; 

Trecînd peste acronimele autohtone (Ordinul nu impune folosirea acestora), înțelegem că este vorba despre continuitate și recuperare în caz de dezastre. Cerința de mai sus ar trebui privită ca o ”poliță de asigurare”: oferă asigurări tuturor părților interesate că organizația continuă să fie viabilă și în cazul unor evenimente cu impact negativ.

Cum scriam la început, auditorul va realiza prima dată TOD, adică va revizui controalele asociate cu continuitatea și recuperarea pentru a obține asigurări că acestea sînt proiectate astfel încît obiectivul ”continuitatea activităților critice” și ”recuperarea în caz de dezastre” sînt atinse. Această testare nu implică însă simpla verificare a existenței back-up urilor și a unor documente etichetate ca în ordin sau BCP/DRP ci analizarea conținutului acestora și a proceselor care au stat la baza întocmiri lor (listă incompletă):

1. BCP trebuie să fie dezvoltat pe baza BIA – Business Impact Analysis
2. BIA trebuie să aibă la bază procesele OSE (au fost incluse toate procesele în BIA?), inventarul activelor (HW, SW, resurse umane), evaluarea riscurilor, RTO, RPO, impactul (financiar, operațional, de conformitate) întreruperii în cazul diferitelor scenarii (cel puțin ”cel mai rău caz”). Riscurile IT sînt tot riscuri operaționale!
3. Rolurile din BCP sînt bine definite (coordonatorul/managerul BCP)
4. Angajați au fost instruiți (conținutul instruirii, rezultate…)
5. Planurile au fost testate, și în funcție de rezultatele testelor s-au executat corecții (planuri/scenarii de test)
6. Vizita amplasamentului de recuperare (unde minimal ar trebui să existe și un border firewall) sau revizuirea contractului/SLA.

Apoi se trece la TOE: activarea BCP prin simularea unui incident conform procedurilor asumate de management. Este suficientă validarea/invalidarea acțiunilor responsabililor de procese conform ierarhiei apelurilor fără a se continua simularea pînă la final (pentru a nu afecta procesele operaționale dacă testul se face într-o perioadă cu activitate intensă). Cu această ocazie se testează și dacă instruirea angajaților a fost reală sau formală….