Gdy pracujesz w branży cyberbezpieczeństwa, dzwoniący w piątek telefon komórkowy zwykle oznacza złe wieści. Cyberprzestępcy znają nasz rytm pracy i wiedzą, w które dni mają największe szanse na odniesienie sukcesu. Dlatego wiele cyberincydentów ma miejsce właśnie w piątki. Gdy 19 lipca telefon nie przestawał wibrować, obawialiśmy się najgorszego.

Tutaj jednak zaczynają się dobre wieści. Po pierwsze telefon nie wibrował z powodu połączenia z CERT GMV. CERT to całodobowa, działająca przez 7 dni w tygodniu usługa monitorowania bezpieczeństwa i reagowania na incydenty. Otrzymujemy te połączenia, gdy dochodzi do cyberincydentu, który ma wpływ na samą firmę GMV lub któregokolwiek z jej klientów – wówczas nasi koledzy z CERT muszą zgłosić, że coś takiego ma miejsce. Prawdopodobnie nie mieliśmy więc do czynienia z poważnym incydentem, co dało nam czas na bardziej przemyślaną i łatwą do wdrożenia reakcję. 

Drugą dobrą wiadomością jest to, że źródłem dźwięku telefonu komórkowego była wewnętrzna komunikacja, typowa dla działalności CERT. Innymi słowy: coś się działo, ale wykryliśmy to na czas i bylibyśmy w stanie wcześnie zareagować, gdyby sytuacja nabrała poważniejszego charakteru. Niemniej jednak liczba tych komunikatów była znacząco wysoka i warta przeanalizowania. We wszystkich przypadkach chodziło o dane, które radykalnie różniły się od tych zwykle analizowanych przez CERT. Niektóre urządzenia i usługi monitorowane przez CERT zostały całkowicie wyłączone lub wstrzymane. Właściwie to było ich całkiem sporo. Żadne z nich nie należało do firmy GMV, ale do niektórych z jej monitorowanych klientów. Zespół CERT zaczął już badać tę kwestię, aby znaleźć wzorce potencjalnych ataków lub awarii w systemach przesyłania informacji. 

Tymczasem równolegle napływały inne wiadomości. Specjaliści ds. cyberbezpieczeństwa zawsze mówią o wartości sieci współpracy i wzajemnej pomocy. Niektóre z najbardziej rozpowszechnionych ram kontroli bezpieczeństwa określają konkretne wymagania dotyczące tworzenia tych sieci współpracy, dołączania do nich i uczestnictwa w ich strukturach. W piątek 19 lipca sieci te potwierdziły swoją wartość. Wiele grup współpracy utworzonych w mediach społecznościowych tętniło życiem. Wykryto problemy na serwerach i stacjach roboczych użytkowników wyposażonych w oprogramowanie EDR od producenta Crowdstrike. Urządzenia te nie reagowały i były nieaktywne. Niektórzy uczestnicy przyznali, że w urządzeniach wystąpiła jedna z najbardziej przerażających awarii, jaka może mieć miejsce w komputerze pracującym z systemem Windows, a mianowicie słynny niebieski ekran. Niebieskie ekrany pojawiają się, gdy stan komputera z systemem Windows jest niestabilny, a system operacyjny nie jest w stanie działać poprawnie. Ze względów bezpieczeństwa urządzenie ulega wyłączeniu, a na niebieskim ekranie wyświetlany jest komunikat o błędzie z wykrytą przyczyną problemu. To, co wydawało się dziwne, to fakt, że działo się to jednocześnie w wielu organizacjach na całym świecie i na wszystkich typach urządzeń. Najwyraźniej wszystkie te urządzenia miały zainstalowane to samo oprogramowanie EDR. Istniał tu klarowny trop śledczy. 

Na szczęście teoria ta została wkrótce potwierdzona. O godzinie 7.30 czasu hiszpańskiego producent Crowdstrike oficjalnie poinformował – za pośrednictwem swojego portalu pomocy technicznej – o istnieniu alertu technicznego w obrębie jego produktu „Falcon Sensor”, który jest elementem wdrażanym na wszystkich chronionych przez niego urządzeniach. Ten alert techniczny wskazywał na błąd w tymże elemencie, który powodował awarię systemu Windows i wywoływał pojawianie się niebieskiego ekranu.

Za pośrednictwem tych sieci zaczęły się również rozprzestrzeniać informacje o szeregu możliwych działań w ramach rozwiązania tymczasowego (workaround). Rzeczonym rozwiązaniem było uruchomienie komputera w trybie awaryjnym, a następnie ręczne usunięcie pliku o nazwie „C-00000291-*.sys”. Crowdstrike rozpoznał, że ten błędny plik był objęty aktualizacją dokonaną o godz. 4.09 UTC (6.09 czasu hiszpańskiego) i to on spowodował awarię.

W tym momencie CERT pracował już z dotkniętymi awarią klientami, weryfikując potencjalne rozwiązania i dostosowując systemy monitorowania w obliczu lawiny alertów. To była kolejna dobra wiadomość w piątkowe popołudnie z tak mało obiecującym początkiem: 

• Potencjalny cyberincydent spowodowany był awarią operacyjną, a nie złośliwym atakiem, a zatem jego zlikwidowanie polegałoby na usunięciu istniejącego błędu, bez martwienia się o reakcję atakującego na nasze działania powstrzymujące, reakcyjne i naprawcze.

• Istniał wyraźny kandydat na źródło błędu: autor błędu przyznał się do niego, dając wyjaśnienie, które odpowiadało temu, co obserwowaliśmy w GMV, a także w innych podmiotach, i mieliśmy już opracowany odpowiedni sposób działania zmierzający do usunięcia awarii.

• Wszystko to wydarzyło się w ciągu kilku minut, a zatem szybko pojawiło się rozwiązanie pomagające zlikwidować incydent. De facto już zaczęto wdrażać to rozwiązanie.

• Komunikacja była przejrzysta i płynna we wszystkich aspektach: dzieliliśmy się jak największą ilością informacji, dotrzymując dotyczących nas zobowiązań z zakresu poufności.

Nie usłyszeliśmy jednak samych dobrych wieści. Inne organizacje bardzo ucierpiały na skutek tego problemu, a większość ich systemów i usług została sparaliżowana. Pojawiło się wiele nazw wiodących firm oraz operatorów infrastruktury krytycznej. Jeden z naszych pracujących zdalnie kolegów z GMV powiedział swojej rodzinie przy śniadaniu, że prawdopodobnie będzie to wiadomość dnia. Najwyraźniej incydent ten miał mieć wpływ na społeczeństwo, i to niemały. Microsoft zadeklarował, że błąd dotknął 8,5 miliona komputerów, co pociągnęło za sobą poważne konsekwencje: opóźnione zostały loty międzynarodowe i zawieszone połączenia transportu publicznego, niektóre szpitale musiały odwołać badania medyczne, a nawet nie mogły zostać przeprowadzone niektóre transakcje bankowe i płatnicze...

Tymczasem prace nad zlikwidowaniem cyberincydentu stopniowo postępowały. Workaround zostało potwierdzone jako skuteczne dla większości urządzeń. Klienci GMV powrócili już w zasadzie do normalnego stanu. W niektórych sytuacjach konieczne było zastosowanie alternatywnych workarounds dla sprzętów, w przypadku których początkowo zalecane rozwiązanie zawiodło. Stwierdzano, że sprzęt uległ awarii, ale zgłaszane problemy nie były dokładnie takie same. Organizacje analizowały informacje – zarówno te znajdowane przez nie same, jak i te stopniowo przez nas udostępniane. Choć rozwiązanie było znane, wydawało się jasnym, że jego wdrożenie w niektórych firmach zajmie całe dnie lub tygodnie. Niektórzy z naszych kolegów przemieszczali się do miejsc, w których były zlokalizowane komputery, aby przeprowadzić naprawę stacjonarną i wdrożyć workaround ręcznie, przy wykorzystaniu USB. To działało, ale wymagało czasu.

Reszta to już historia. Nie warto tego powtarzać.

Warto natomiast poświęcić miejsce na przeprowadzoną przez nas analizę incydentu, sposobu, w jaki sobie z nim poradziliśmy, tego, jak powinniśmy byli postąpić, jakie narzędzia mieliśmy do dyspozycji... A przede wszystkim: co moglibyśmy poprawić na wypadek zajścia tego typu sytuacji w przyszłości.

Pierwszym wnioskiem jest potrzeba ciągłego, całodobowego monitorowania bezpieczeństwa przez 7 dni w tygodniu za pośrednictwem usługi CERT. Rozbudowanego, działającego w czasie rzeczywistym, skutecznego oraz szybkiego. Z udziałem osób, które będą przygotowane, przeszkolone i wykwalifikowane do wykonywania tej pracy. Powinny one też posiadać zdolność do wykrywania istotnych zdarzeń na różnych poziomach, aby móc w razie potrzeby reagować, ale także – jeśli to możliwe – być zawczasu uprzedzonymi, zanim zajdzie konieczność zainicjowania reakcji. Bez kompetentnego zespołu CERT czy Działu Obsługi Klienta nie jest to możliwe. 

Drugi wniosek dotyczy naszych planów reagowania na incydenty. W tym przypadku nie musieliśmy ich realizować. Nie było nawet konieczne uruchamianie procedur eskalacyjnych. Niemniej jednak plan reagowania zadziałał skutecznie w niezbędnym zakresie. To doskonała wiadomość.

Trzeci wniosek dotyczy naszych planów ciągłości działania. Co by się stało, gdybyśmy wdrożyli oprogramowanie Crowdstrike na szeroką skalę? Wiemy, że z pewnością wykrylibyśmy awarię, ale czy Plan Ciągłości Działania byłby w stanie zareagować na taki scenariusz? Czy byłaby to skuteczna reakcja? Czy jest coś, co moglibyśmy poprawić? Na szczęście nie musieliśmy wdrażać wspomnianego planu w życie, ale mogliśmy go zweryfikować podczas incydentu. Na wszelki wypadek. A także włączyć do Planu pewne dodatkowe aspekty, które umożliwiłyby nam szybszą i skuteczniejszą reakcję oraz zmniejszyłyby skutki, jakie moglibyśmy ponieść.

Ten pamiętny piątek przejdzie z pewnością do historii. Mamy nadzieję, że dzięki wyciągniętym wnioskom oraz zwiększonej świadomości firm w zakresie monitorowania bezpieczeństwa i reagowania na incydenty będziemy lepiej przygotowani na następny potencjalny kryzys. 

Mariano J. Benito, Cybersecurity & Privacy Ambassador w GMV 

Óscar Riaño, kierownik CERT w GMV