Strona główna Wstecz New search Date Minimum Max Aeronautyka Motoryzacja Dział korporacyjny Cyberbezpieczeństwo Obronność i bezpieczeństwo Finanse Opieka zdrowotna Przemysł Inteligentne systemy transportowe Cyfrowe usługi publiczne Usługi Przemysł kosmiczny Blog Cyberbezpieczeństwo – wszystkie podsektory Crowdstrike: Kiedy antywirus stał się informacją dnia 24/07/2024 Drukuj Podziel się 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 z GMV - całodobowej, działającej przez 7 dni w tygodniu usługi 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, i 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, że coś się działo, ale że wykryliśmy to na czas i byliśmy w stanie wcześnie zareagować, jeśli sytuacja nabrałaby 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 kooperacji. 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 udowodnił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, iż 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 07:30 czasu hiszpańskiego producent Crowdstrike oficjalnie poinformował - za pośrednictwem swojego portalu pomocy technicznej - o istnieniu alertu technicznego w obrębie swojego 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 rozwiązań z zastosowaniem 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 plik ten odpowiadał aktualizacji dokonanej o godz. 04:09 UTC (06:09 czasu hiszpańskiego), zawierającej ten błędny plik, który 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 cyberatak spowodowany był awarią operacyjną, a nie działaniem złośliwego ataku, a zatem rozwiązanie cyberincydentu 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 solidny sposób działania, zmierzający do jego rozwiązania.Wszystko to wydarzyło się w ciągu kilku minut, a zatem incydent został szybko rozwiązany. De facto, już zaczęto wdrażać wspomniane rozwiązanie.Komunikacja była przejrzysta i płynna we wszystkich aspektach: wzajemnie dzieliliśmy się jak największą ilością informacji, wypełniając zobowiązania z zakresu poufności, do których dotrzymania jesteśmy zobowiązani.Nie wszystko było jednak dobrymi wieściami. 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 organizacji i 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 przerwane 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 rozwiązaniem cyberincydentu stopniowo postępowały. Workaround zostało potwierdzone jako skuteczne na większości urządzeń. Klienci GMV powrócili już w zasadzie do normalnego stanu. W niektórych przypadkach konieczne było zastosowanie alternatywnych workarounds dla sprzętów, w przypadku których początkowo zalecane rozwiązanie zawiodło. Stwierdzono, że sprzęt uległ awarii, ale nie wystąpiła w nich dokładnie taka sama, zgłoszona awaria. Organizacje analizowały informacje - zarówno te znajdowane przez nie, jak i te stopniowo przez nas udostępniane. Choć rozwiązanie było znane, wydawało się jasne, że jego wdrożenie w niektórych firmach zajmie całe dnie lub tygodnie. Niektórzy z naszych kolegów fizycznie przemieszczali się do komputerów z USB, aby zastosować workaround ręcznie. To zadziałało, ale wymagało czasu.Reszta to już historia. Nie warto tego ponownie powtarzać.Warto natomiast poświęcić miejsce na przeprowadzoną przez nas analizę zaszłego 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 i szybkiego. Z udziałem osób, które będą przygotowane, przeszkolone i wykwalifikowane do wykonywania tej pracy. A także posiadających 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 uprzedzonym, zanim zajdzie konieczność zainicjowania reakcji. Bez kompetentnego zespołu CERT lub 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 go realizować. Nie było nawet konieczne uruchamianie procedur eskalacyjnych. Niemniej 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ą byśmy to wykryli, 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 dodanie do planu pewnych dodatkowych aspektów, 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 i 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, Cibersecurity & Privacy Ambassador GMV Óscar Riaño, kierownik CERT w GMV Drukuj Podziel się Comments Nazwisko lub pseudonim Temacie Komentarz O formatach tekstu Ograniczony HTML Dozwolone znaczniki HTML: <a href hreflang target> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> Znaki końca linii i akapitu dodawane są automatycznie. Adresy web oraz email zostaną automatycznie skonwertowane w odnośniki CAPTCHA To pytanie sprawdza czy jesteś człowiekiem i zapobiega wysyłaniu spamu.