Riscurile ascunse legate de distribuirea fișierelor în mediile OT

În majoritatea mediilor OT, introducerea unui fișier într-un sistem critic urmează o secvență specifică de pași. Procesul începe cu sosirea unui furnizor cu firmware, a unui contractor care aduce un patch sau a unei echipe de întreținere care efectuează actualizări de configurare. Fișierele sunt scanate, aprobate și predate. Cu toate acestea, undeva între aceste proceduri și momentul în care fișierul ajunge la PLC (controler logic programabil) sau la HMI (interfață om-mașină), echipele de securitate îl pierd complet din vedere.

Pentru a face față acestei provocări se utilizează numeroase abordări. Soluțiile bazate pe rețea gestionează transferul fișierelor între sistemele IT și OT, iar fluxurile de lucru bazate pe chioșcuri verifică suporturile amovibile la punctul de intrare. Totuși, o parte a problemei rămâne în mod constant nerezolvată. Este vorba despre ce se întâmplă cu un fișier după ce a fost verificat, în timp ce se află în tranzit către sistemul critic.

Majoritatea operatorilor din domeniul OT dispun de fluxuri de lucru solide și integrate pentru inspecție. De obicei, suporturile amovibile și dispozitivele temporare sunt scanate înainte de a intra în mediul OT izolat, iar aprobările sunt înregistrate. Aceste măsuri de control sunt necesare, dar au o limitare comună: ele creează un singur moment de încredere.

Sistemele OT vechi nu au fost concepute pentru a verifica conținutul datelor care le parvin. PLC-urile, interfețele HMI și stațiile de lucru de inginerie vechi nu pot, de obicei, să ruleze agenți EDR (Endpoint Detection and Response) sau să verifice dacă fișierele primite corespund aprobărilor inițiale. Atunci când un dispozitiv este conectat, fișierele devin accesibile în mod implicit.

Aceste limitări fac ca securitatea fiecărei distribuiri de fișiere într-un sistem critic să depindă de respectarea de către fiecare operator a pașilor de verificare manuală. Faptul de a se baza pe respectarea de către fiecare operator a fiecărui pas în fiecare locație reprezintă o ipoteză de proces, nu o măsură de securitate.

Întrebarea ar trebui să se schimbe acum de la „fișierul acesta era curat în momentul scanării?” la „putem confirma că este tot același fișier în momentul implementării sale în sistemul critic?”

În sectoarele reglementate, este esențial să se confirme că un fișier nu a suferit modificări de la momentul aprobării până la implementare. Odată ce un fișier trece de punctul de verificare, trebuie să existe un mecanism care să confirme dacă acesta a suferit modificări.

În mediile OT, problema rămâne nerezolvată, majoritatea fluxurilor de lucru actuale neavând un mecanism de detectare a modificărilor ulterioare verificării. Dacă un fișier este modificat după verificare, fie din cauza unei erori, fie prin alterare deliberată, sistemul țintă OT nu poate detecta acest lucru. Înregistrarea scanării rămâne valabilă, iar aprobarea este în continuare consemnată. Un fișier care a fost verificat ca fiind sigur acum trei zile și care a fost modificat între timp arată identic cu un fișier care a fost considerat sigur acum trei zile și care nu a fost modificat. Operatorul care îl distribuie nu dispune de nicio metodă fiabilă de a face diferența.

Verificarea nu se limitează la MetaDefender Kiosk . Dacă un fișier verificat este modificat după scanare și înainte de implementare, acesta este blocat și ascuns automat. În acest caz, fișierul respectiv trebuie să treacă din nou prin procesul de verificare înainte de a putea fi făcut accesibil.

Acest mecanism asigură integritatea fișierelor, astfel încât operatorul nu trebuie să efectueze manual această operațiune. Astfel, modelul de securitate trece de la „scanare o singură dată și distribuire” la „verificare continuă până la implementare”.