Evaluarea riscurilor: un formalism consumator de timp? (Continuare)

În Regulamentul din 22 martie 2021 pentru atestarea și verificarea auditorilor de securitate cibernetică, în Anexa 7 există o cerință:

Se va verifica și opina cu privire la plauzibilitatea metodologiei/tehnicilor utilizate, precum și asupra măsurilor de control implementate în vederea gestionării riscurilor operaționale identificate.

În general, o ”metodologie de management al riscurilor” include:

  • un proces de evaluare a riscurilor (dacă este proces înseamnă că trebuie să se regăsească date de intrare, rezultate și persoane cu responsabilități explicite alocate. ”Procesul” se regăsește în ISO 27005, ISO 31000, COBIT for Risk sau NIST 800-30 dar și în rezumat în Ghidul DNSC)
  • un model care definește termenii cheie și factorii de risc evaluabili și relațiile dintre factori (în cazul securității IT, ”factorii” sînt amenițările, vulnerabilitățile, impactul, probabilitatea);
  • o abordare de evaluare (de exemplu, cantitativă, calitativă sau semi-calitativă), specificând intervalul de valori pe care acei factori de risc le pot asuma în timpul evaluării riscului și modul în care combinațiile de factori de risc sunt identificate/analizate astfel încât valorile acelor factori de risc pot fi combinați funcțional pentru a evalua riscul;
  • o abordare de analiză (de exemplu, orientată spre amenințări, orientată către active/impact sau orientată către vulnerabilitate), care descrie modul în care sunt identificate/analizate combinații de factori de risc pentru a asigura o acoperire adecvată a spațiului problemei la un nivel consistent de detaliu .

Prin urmare pentru OSE nu este dificil să identifice o ”metodologie” și să dezvolte corect o procedură (MEGRE, ARNIS – cum apar în cerințele minime de securitate aplicabile OSE). Auditorului i se solicită însă să își exprime opinia și asupra rezultatelor analizei de risc. Aici discuția comportă două aspecte:

  • pe de o parte sînt controalele obligatorii aplicabile OSE și care vor reduce anumite riscuri ( de exemplu cerințele privind ”senzorul IDS” sau ”SIEM”)
  • pe de altă parte sînt riscuri care nu sînt în mod explicit tratate prin cerințele minime de securitate (de exemplu ransomware)

Trecînd peste subiectivitatea inerentă unor statistici publice, ne trebuie totuși un punct de plecare în orice analiză. Dacă ne raportăm de exemplu la informațiile publice (din 2020 în foto – Sursa Statista), principalul canal de distribuire a ransomware a fost phishingul/spear phishing

Este de bun simț deci ca un astfel de subiect să fie tratat într-o ”evaluare a riscurilor”. Care sînt ”controalele” care ”reduc” un astfel de risc la un nivel acceptabil? Răspunsul la această întrebare ar trebui să se regăsească în ”analiza” OSE și asupra sa va opina auditorul. Un răspuns de tipul ”nu avem/există acest risc” este hilar. Un răspuns de tipul ”instruirea angajaților” (care este și cerință de securitate) va fi insuficient dacă nu este susținut și de dovada instruirii și testării angajaților pe acest subiect. Ar mai trebui să existe și un email gateway prin povestea asta….

Să presupunem însă că acest risc este acceptat. Asta înseamnă că ”cineva” își asumă odată cu acest risc și consecințele în cazul celui ”mai rău scenariu”: indisponibilitatea infrastructurii și aplicațiilor un număr de X ore și pierderile financiare asociate. Dacă lucrurile stau așa, înseamnă că în ”analiza de impact asupra activității” (care este pe la continuitatea/BCP) auditorul va regăsi acest lucru: indisponibilitatea sistemelor timp de X ore are impact redus/minim asupra serviciilor esențiale.

Mulţumesc.

Completează mai jos detaliile cerute sau dă clic pe un icon pentru a te autentifica:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare /  Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare /  Schimbă )

Conectare la %s

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.