În cadrul unei audieri în Congresul SUA cu privire la incidentul CrowdStrike din iulie, unul dintre directorii companiei a răspuns întrebărilor formulate de responsabili. Un punct care a atras atenția în timpul dezbaterii ce a urmat a fost sugestia că viitoare incidente de o asemenea amploare ar putea fi evitate printr-o formă de recuperare automată a sistemului.

Fără a intra în detaliile tehnice ale incidentului și cum putea fi evitat, propunerea ridică o întrebare fundamentală: ar trebui ca recuperarea automată să fie responsabilitatea furnizorului de software terț sau ar trebui să fie considerată o problemă mai largă, legată de reziliența sistemului de operare (OS), ceea ce presupune ca acesta din urmă să inițieze un proces de recuperare automată în colaborare cu aplicațiile terțe?

Un sistem care se vindecă singur

O eroare catastrofală de boot care provoacă un blocaj de tip ecran albastru (Blue Screen Of Death - BSOD) apare atunci când dispozitivul nu reușește să încarce software-ul necesar pentru a prezenta utilizatorului un sistem de operare funcțional, împreună cu aplicațiile instalate pe dispozitiv. De exemplu, poate fi declanșat atunci când este instalat sau actualizat un software. În acest caz specific, un fișier de actualizare corupt/ defect, folosit în timpul procesului de boot, a declanșat BSOD-ul, care a dus în cele din urmă la o prăbușire IT globală – bine documentată.

Unele programe software, cum ar fi aplicațiile de securitate, necesită acces de nivel scăzut, cunoscut sub denumirea de „modul kernel”. Dacă o componentă de la acest nivel eșuează, un BSOD este un rezultat posibil. Rebootarea dispozitivului duce la bucla de BSOD și este nevoie de intervenția unui expert pentru a întrerupe acest ciclu. (Desigur, un BSOD poate apărea și în „modul utilizator”, care oferă un mediu mai restrâns pentru funcționarea software-ului.)

Dacă menționarea modului kernel pare complicată, iată o analogie pentru a clarifica lucrurile. Gândiți-vă la un motor de mașină pe benzină. Motorul are nevoie de o scânteie pentru a aprinde amestecul de aer și combustibil, care vine de la o bujie. Într-un program obișnuit de întreținere, bujiile trebuie înlocuite, altfel motorul nu va funcționa așa cum trebuie. Un mecanic deschide capota mașinii și schimbă bujiile. Pornim cheia (sau apăsăm butonul de start) și motorul pornește – cu excepția cazului când nu se întâmplă asta. Cam așa s-a petrecut acest incident, dar din punct de vedere software.

Acum, apare întrebarea: ar trebui să fie responsabilitatea unui producător de bujii, dintre care avem mulți, să creeze un mecanism de recuperare automată pentru acest scenariu? În contextul software, ar trebui ca furnizorul terț să fie responsabil? Sau ar trebui ca mecanicul să deschidă din nou capota, să revină la bujiile utilizate anterior și să repornească mașina în starea sa de funcționare anterioară?

În opinia mea, procesul de recuperare ar trebui să fie același în toate circumstanțele, indiferent de software-ul terț implicat (sau bujiile). Realitatea este, desigur, puțin mai complexă decât analogia de mai sus, deoarece bujiile (software-ul) sunt actualizate și înlocuite fără ca mecanicul (OS-ul) să știe.

Argumentul pentru o recuperare gestionată de OS

Cum ar fi ca, de fiecare dată când un pachet software terț se actualizează și face o modificare în funcționarea de bază a dispozitivului, instalând un fișier nou sau modificat – necesar în procesul de boot, ar înregistra această modificare într-un jurnal din sistemul de operare și fișierul sau starea anterioară funcțională ar fi lăsată deoparte, în loc să fie suprascrisă? În teorie, dacă la următoarea pornire dispozitivul ajunge într-o situație de BSOD, atunci o pornire ulterioară ar putea, ca primă sarcină, să verifice de ce dispozitivul nu a pornit corect la pornirea anterioară și să-i ofere utilizatorului opțiunea de a recupera fișierul sau versiunea inițială, eliminând actualizarea. Același scenariu ar putea fi utilizat pentru toate programele terțe care au acces la modul kernel.

Deja există un precedent pentru acest tip de recuperare gestionată de OS. Când un nou driver de afișare este instalat, dar nu reușește să se inițializeze corect în timpul procesului de boot, eșecul este blocat, iar sistemul de operare va reveni automat la o stare implicită și va oferi un driver cu o rezoluție foarte mică, care funcționează cu toate afișajele. Este evident că acest scenariu nu funcționează pentru produsele de securitate cibernetică, deoarece nu există o stare implicită, dar ar putea exista o stare anterioară funcțională, de dinainte de actualizare.

A avea o opțiune de recuperare încorporată în sistemul de operare pentru toate programele software terțe ar fi mai eficient decât să ne bazăm pe fiecare furnizor de software să dezvolte propria soluție. Desigur, ar fi nevoie de consultare și colaborare între OS și furnizorii de software terți pentru a se asigura că mecanismul funcționează și nu poate fi exploatat de actori rău intenționați.

Desigur, poate că la prima vedere totul pare simplu, iar efortul necesar pentru a dezvolta o astfel de soluție este (supra)simplificat, dar, chiar și așa, existența acestuia ar fi mult mai eficientă decât mii de dezvoltatori software care încearcă să creeze propria metodă de recuperare a sistemului. În cele din urmă, o soluție de recuperare automată integrată ar putea contribui mult la îmbunătățirea rezilienței sistemului și la prevenirea întreruperilor extinse – precum cea declanșată de actualizarea defectuoasă CrowdStrike.