IT incident koji je paralizovao svet: Srpski stručnjak objašnjava kako je softverska greška izazvala haos

Želeli smo da saznamo kako je ovako kritična greška mogla da se dogodi i koje su tehničke i organizacione greške dovele do ovog incidenta

Nedavni IT pad, najveći u istoriji, izazvao je značajne probleme širom sveta, a tim povodom smo razgovarali sa Miletom Jelićem, regionalnim menadžerom poslovnog razvoja u Comtrade System Integration.

Želeli smo da saznamo kako je ovako kritična greška mogla da se dogodi i koje su tehničke i organizacione greške dovele do ovog incidenta.

Preporučujemo

Mile, kao stručnjak sa dugogodišnjim iskustvom, podelio je svoja saznanja o uzrocima ovog incidenta. Objasnio nam je kako su tehničke i organizacione greške dovele do kritične greške u softveru koja je prošla neopaženo tokom razvoja i testiranja. Posebno je istakao pritisak na brzinu isporuke softverskih rešenja na uštrb sigurnosti, što je često uzrok ovakvih problema.

Jelić je detaljno opisao proces validacije i testiranja softverskih ažuriranja, naglašavajući važnost faznog pristupa i najboljih praksi koje mogu ublažiti rizike. Takođe, Mile je istakao specifičnost situacije sa Crowdstrike-om, gde je veliki tržišni udeo dodatno pojačao uticaj incidenta.

• Koje su moguće tehničke i organizacione greške koje su dovele do toga da ovako kritična greška prođe neopaženo tokom razvoja i testiranja softvera?

Greška koja je izazvala BSOD (Blue Screen Of Death) na Windows operativnim sistemima, izazvana je konfiguracionim fajlom koji je distribuiran Crowdstrike klijentima 19. jula kao ažuriranje. Možemo samo nagađati šta je konkretno izazvalo ovakav ishod u organizacionom smislu, ali definitivno je zakazao sam proces testiranja i način distribuiranja novog softvera. Sve softverske kompanije imaju veliki pritisak brzog kreiranja softvera i akcenat je uvek na brzini isporuke, a ne na sigurnosti. Ruku na srce, ovde se ipak radi više o procesnom propustu. Sigurnosni rizik je usledio posle.

• Kako funkcioniše proces validacije i testiranja softverskih ažuriranja u velikim IT kompanijama?

Svaki proizvođač ima određene specifičnosti u kontekstu validacije i distribucije novog softvera. Sa druge strane, postoji nešto što se zove najbolja praksa, a ona kaže da se tek po testiranju softver pušta u produkciju. Naravno, uvek postoje specifične situacije i izazovi, ali oni se ublažavaju faznim pristupom primene ažuriranja.

• Zašto se toliko kritične infrastrukture oslanja na jedan softver i kako se minimiziraju rizici od ovakvih incidenata?

U slučaju Crowdstrike-a, situacija je poprilično specifična, pošto se radi o EDR (Endpoint Detect and Response) rešenju. Ovakvo rešenje, da bi moglo efikasno da funkcioniše, zahteva visoke privilegije, a samim tim i veliki uticaj, kako na operativni sistem tako i na ostale aplikacije. Kompanija Crowdstrike ima najveći tržišni udeo na tom tržištu, tako da je to razlog ovako velikog uticaja ovog događaja. Ne znam da li znate, ali Bajdenova administracija je u maju 2021. godine, donela izvršnu odredbu kojom propisuje korišćenje naprednih sajber alata kao što je Crowdstrike, što je dovelo do ubrzanog širenja kompanije. Što se umanjenja rizika tiče, postoji više načina za to. Svakako jedan od njih je umanjenje zavisnosti od jednog softvera. Iako je konsolidacija odlična za produktivnost, u ovom slučaju se pokazalo da i nije baš pomogla. Kao i u životu, najteže je održati balans.

• Kako se sprovode health check-ovi tokom implementacije softverskih ažuriranja i zašto ovakvi problemi nisu uhvaćeni na vreme?

Inženjerima Crowdstrike-a je trebalo samo 79 minuta da otkriju i primene zakrpu. Opet, sa druge strane, dovoljno vremena da se napravi toliki haos. Očigledno je propust bio u samom procesu pripreme.

• Kako kompanije implementiraju strategije rollback-a kada se suoče sa kritičnim greškama u ažuriranjima?

Kompanije pristupaju izradi tzv „zakrpa“ koje praktično anuliraju greške koje su se pojavile sa lošom verzijom softvera. U slučaju Crowdstrike-a, situacija je dodatno bila otežana, iz razloga što je za razrešenje problema bila potrebna fizička prisutnost. Bilo je potrebno restartovati mašinu u Safe mod, obrisati odgovarajući fajl i ponovo je restartovati. Radnja se dodatno komplikovala ukoliko su kompanije imale primenjenu enkripciju sa Bitlocker-om, što je sam proces razrešenja znatno produžavao.

• Koji su najčešći izazovi sa kojima se suočavaju timovi za kontrolu kvaliteta prilikom testiranja novih softverskih verzija na velikoj skali i koja bi bila najbolja praksa?

Kao što sam i ranije napomenuo, izazova je dosta, a uglavnom su izazvani potrebom za brzom izradom softvera (zahtevni korisnici, konkurencija…). Ono što bih mogao da predložim kao najbolju praksu, za koju znam da koriste kompanije koje proizvode sličan softver jeste:

• Automatsko i ručno testiranje softvera.
• Inicijalna primena novog softvera „u kući“, na svojoj infrastrukturi, čime se ublažava njen uticaj. Ukoliko dođe do nekih grešaka, sve se rešava unutar matične kompanije.
• Primena softvera kod klijenata u fazama, a ne modelom „svi u isto vreme“, kakav je bio slučaj sa Crowdstrike-om.
• Primena novog softvera se vrši u radno vreme, kako bi tehnička podrška bila prisutna ukoliko dođe do nekih problema.

• Koje su ključne lekcije koje se mogu naučiti iz ovakvih incidenata kako bi se poboljšali procesi razvoja i implementacije softverskih rešenja?

Mislim da je lekcija iz incidenta ove veličine, jasna. Unapređenje procesa testiranja i praksi sajber bezbednosti. Unapređenje procesa odgovora na sam incident. Naravno, mislim da je neizbežno uključiti i veštačku inteligenciju koja bi trebalo da unapredi i ubrza sve ove procese. Takođe, pokazalo se da kao ljudi, previše zavisimo od tehnologije. Potrebno je pronaći način da se ta zavisnost umanji, bez uticaja na kvalitet naših života.

(Telegraf.rs)