Ghid practic
Auditul de securitate pentru infrastructuri critice: metodologie practică
Un cadru de lucru structurat pentru echipele care planifică sau comandă audituri de securitate pe sisteme SCADA și rețele industriale.
De ce auditul de securitate OT diferă fundamental de cel IT
Un audit de securitate pe o rețea corporativă standard urmărește tipare cunoscute: parole slabe, software neactualizat, permisiuni excesive, date expuse. Pe o infrastructură critică — stații de tratare a apei, rețele electrice, sisteme de control al producției — aceleași tehnici de auditare pot provoca incidente operaționale reale dacă sunt aplicate fără adaptare. Un scan agresiv de porturi pe un PLC vechi poate duce la blocarea controlerului și oprirea unui proces industrial. Acesta este motivul pentru care auditul de securitate OT trebuie precedat de o fază de documentare pasivă: colectarea topologiei de rețea prin captură de trafic (fără scanare activă), inventarierea activelor pe baza documentației existente și a observației directe, și cartografierea zonelor de securitate conform standardului IEC 62443. Abia după ce echipa de audit înțelege exact ce se află în rețea și cum comunică, poate trece la testarea activă — și numai pe echipamente clone sau în ferestre de mentenanță programate. Ignorarea acestei secvențe nu este doar o greșeală metodologică; în România, Directiva NIS2, transpusă prin Legea 58/2024, impune cerințe explicite de notificare și poate implica răspundere legală în cazul incidentelor provocate de testări neglijente.
Etapele unui audit structurat și livrabilele așteptate
Un audit de securitate pentru infrastructuri critice are în mod tipic cinci etape: planificare și definirea perimetrului, colectare pasivă de informații, analiză de risc, testare controlată și raportare. Etapa de planificare stabilește ce sisteme sunt incluse, cine autorizează fiecare acțiune și ce proceduri de urgență există dacă o testare produce efecte neașteptate. Colectarea pasivă durează de obicei 3–5 zile și produce o hartă a comunicațiilor interne, o listă de echipamente cu versiunile de firmware identificate și o primă listă de anomalii observate. Analiza de risc mapează vulnerabilitățile identificate pe scenarii de atac credibile — nu pe CVSS abstract, ci pe impacturi operaționale concrete: oprire de linie, pierdere de date de proces, acces neautorizat la interfețe de operator. Testarea controlată, dacă este inclusă în scop, se desfășoară exclusiv în ferestre de mentenanță și cu prezența unui inginer de proces care poate opri testul în orice moment. Raportul final trebuie să conțină nu doar vulnerabilitățile găsite, ci și o matrice de prioritizare și un plan de remediere realist, cu costuri estimate și dependențe tehnice. Un audit care produce o listă de 200 de finding-uri fără prioritizare este mai puțin util decât unul care identifică cinci probleme critice și explică exact cum se remediază fiecare.