La întîlnirea ISACA-DNSC din 14.06 au fost adresate mai multe întrebări care abordau subiectul SCADA atît din perspectiva OSE cît și a auditorului.

În continuare voi explica înțelegerea și abordarea mea cu privire la acest subiect (N.B – există o probabilitate să nu fie corecte)

1. Perspectiva OSE

Presupunem că în cazul unui OSE doar sistemul SCADA intră sub incidența legii.

Art. 10 (1)(a)din Legea 362/2018 precizează că:

 În scopul asigurării securității rețelelor și sistemelor informatice, operatorii de servicii esențiale au următoarele obligații:

a) implementează măsurile tehnice și organizatorice adecvate și proporționale pentru îndeplinirea cerințelor minime de securitate stabilite în temeiul prevederilor art. 25 alin. (3);

Ordinul 1323/2020 (Normele tehnice) la Art. 2(4) precizează că

În procesul de implementare a cerințelor de securitate, OSE identifică riscurile privind neimplementarea, planifică activitățile care stau la baza implementării și stabilește responsabilii pentru realizarea acestora.

iar la Art. 26

OSE trebuie să identifice și analizeze riscurile de securitate și să implementeze măsuri de securitate pentru limitarea accesului neautorizat.

Rezultă că prima acțiune pe care trebuie să o realizeze OSE este să efectueze analiza riscurilor în cazul particular al unei infrastructuri SCADA. Cum face acest lucru?

Ideal ar fi să știm că există Decizia DNSC nr. 88/2020 care prezintă lista standardelor internaționale aplicabile OSE și auditorilor:

Standardele și/sau specificațiile europene și internaționale se aplică individual sau grupate în funcție de domeniile, subdomeniile, măsurile și cerințele de securitate, după caz, stabilite în conformitate cu normele tehnice privind cerințele minime de asigurare a securității rețelelor și sistemelor informatice.

În cazul SCADA vom regăsi familia IEC 62443:

Partea 3-2 descrie cerințele pentru abordarea riscurilor de securitate cibernetică într-un IACS/SCADA dar nu specifică și metodologia exactă care trebuie utilizată. Metodologia utilizată trebuie să fie stabilită de către proprietarul activelor (Operator) și ar trebui să fie în concordanță cu metodologia generală de evaluare a riscurilor a organizației.

În Partea 3-3 se vor regăsi 7 cerințe de securitate și 3 niveluri de securitate, astfel:

Foundational Requirements

• FR 1 – Identification and Authentication Control (IAC)
• FR 2 – Use Control (UC)
• FR 3 – System Integrity (SI)
• FR 4 – Data Confidentiality (DC)
• FR 5 – Restricted Data Flow (RDF)
• FR 6 – Timely Response to Events (TRE)
• FR 7 – Resource Availability (RA)

Security Level

• SL1 – conceput pentru a proteja împotriva încălcărilor întâmplătoare ale securității
• SL2 – adaugă la SL1 alte 23 de cerințe individuale
• SL3 – adaugă la SL2 alte 30 de cerințe individuale

OSE realizează deci evaluarea de riscuri și aplică corespunzător situației sale cerințele unui SL.

2. Perspectiva auditorului

Orice misiune de audit are nevoie de un referențial/criterii de audit la care se raportează auditorul. În cazul auditului solicitat de DNSC acest lucru este întărit explicit prin cerința ca auditorul să menționeze în raportul de audit standardele la care s-a raportat.

Auditorul va solicita prima dată evaluarea de risc:

• pentru a verifica corectitudinea metodologiei și realitatea riscurilor identificate și evaluate
• pentru a putea evalua cerințele de securitate aplicate sistemului auditat

Mai departe lucrurile se desfășoară ”ca la carte”: test of design respectiv test of effectiveness pentru fiecare control.

Închei cu unul din citatele mele favorite: „în practică, diferenţa dintre teorie şi practică este mai mare decît diferenţa dintre teorie şi practică, din teorie”.