Stało się. Reakcja na incydenty bezpieczeństwa IT.

W niniejszym artykule podzielimy się swoimi doświadczeniami z wykonywanych zawodowo procesów obsługi incydentów. Przedstawimy krajobraz, na jaki zwykle możemy natknąć się w organizacji bezpośrednio po wykryciu incydentu. Pokażemy przykłady błędnych działań, które są wtedy podejmowane, oraz takich, które powinny zostać podjęte.

Stare komputerowe porzekadło mówi, że administratorzy IT dzielą się na takich, którzy robią kopie zapasowe i na takich, którzy je będą robić. Na gruncie bezpieczeństwa IT można by powiedzieć, że firmy dzielą się na takie, które wykonują (zazwyczaj zlecają) testy bezpieczeństwa i takie, które kiedyś to zrobią. Należałoby tu też uczciwie zaznaczyć, że wykonane testy bezpieczeństwa (i oczywiście wdrożenie po nich poprawek) nie gwarantują, że do żadnego incydentu nie dojdzie. Takie działania po prostu wyeliminują szerokie spektrum zagrożeń technicznych, ale wciąż będzie mogło dojść do incydentu, którego źródłem będą metody socjotechniczne, np. phishing.

W każdym zatem wypadku warto na incydent być przygotowanym. Po pierwsze dlatego, że incydent wystąpi nagle, bez ostrzeżenia i prawdopodobnie w najmniej oczekiwanym przez organizację momencie (tu warto wtrącić, że atakujący z reguły najbardziej aktywni są w okolicach wolnych od pracy dni). Z jednej więc strony mamy niespodziewaną informację, że intruz kontroluje w jakimś stopniu naszą infrastrukturę, z drugiej nie wiemy właściwie w jakim zakresie i jakie ma zamiary. Nie wiemy, czy przerwał swoje działania czy może właśnie wyprowadza bądź niszczy nasze dane.  

Można by się pokusić o porównanie włamania cybernetycznego z włamaniem fizycznym do lokalu bądź budynku i to drugie okaże się dla ofiary bardziej komfortowe, jakkolwiek by to nie brzmiało. Stwierdzić, że złodzieja nie ma w lokalu jest relatywnie łatwo i można to zrobić we własnym zakresie (teoretycznie, w praktyce zalecamy pomoc Policji). Nie nastręczy też większych problemów ustalenie jakich dóbr w lokalu ubyło i jakie zostały zniszczone.  Zupełnie inaczej sprawy się mają w wypadku ataku IT, bo po pierwsze system komputerowy jest daleko bardziej skomplikowany niż mieszkanie a po drugie zawłaszczenia dóbr cyfrowych z reguły zwyczajnie nie widać. Wszystko to każdy administrator systemu czuje intuicyjne, ale ta wiedza niekoniecznie pomaga w działaniach. Ta świadomość oraz presja czasu ze strony przełożonych, współpracowników czy klientów mogą przekładać się (i przekładają się) na nieprzemyślane działania.

Najczęstszym działaniem w tego rodzaju okolicznościach jest odłączenie systemu komputerowego od zasilania, co jest kardynalnym błędem. Wyłączenie zasilania jest rozwiązaniem typowo chwilowym, które co prawda pozwoli przerwać atak, ale jednocześnie bardzo skutecznie zatrze jego ślady. Dla jasności powiedzmy, że tzw. grzeczne zamknięcie systemu (ang. shutdown) nie jest tu bardziej korzystne – a zapewne może i mniej.  Dlaczego tak jest? W ulotnej pamięci operacyjnej komputera przechowywane są najważniejsze z punktu dalszego dochodzenia okoliczności ataku informacje: zainfekowane procesy systemowe, własne procesy atakujących czy informacje o otwartych połączeniach sieciowych. Zainfekowany komputer należy zatem odłączyć od sieci informatycznej – najpewniej jest wyciągnąć wtyczkę Ethernet z gniazdka. Dzięki temu definitywnie zostanie przerwana komunikacja pomiędzy maszyną a atakującym: więcej danych komputera nie opuści i nie zostaną też przekazane kolejne instrukcje z zewnątrz.  To nam wystarczy.

No dobrze, a co jeśli zaatakuje nas nie człowiek, a skrypt, pokroju szyfrujących Wannacry czy CryptoLockera? Po odłączeniu komputera od sieci należy go zahibernować. Hibernacja (na szczęscie dostępna w każdym systeme rodziny Windows, ulubionej przez szkodliwe szyfratory), spowoduje, że szyfrowanie zostanie przerwane, a znajdujące się w pamięci operacyjnej dane (klucze szyfrujące), które mogą pomóc w deszyfracji danych przez specjalistę nie znikną z naszego zasięgu.

Przestrzeganie przedstawionych prostych zasady samo w sobie w ogromnym stopniu ułatwi proces późniejszego łagodzenia skutków incydentu teleinformatycznego. Należy jednak pamiętać, iż organizacja powinna wypracować na swój użytek bardziej złożone procedury reakcji na incydent bezpieczeństwa, które będą uwzględniały specyfikę danego środowiska, np. krytyczności i zależności systemów komputerowych czy kompetencje pracowników.  Istnieją też różne kategorie incydentów i w ślad za nimi warto mieć różne warianty postępowań.

Od niedawna dużą rolę odgrywa też wszechobecne RODO – na zgłoszenie incydentu z udziałem danych osobowych mamy 72h, czyli 3 doby. W praktyce to nie jest wiele czasu, żeby choć wstępnie zapanować nad poincydentalnym chaosem i ocenić, czy faktycznie doszło do naruszenia ochrony danych osobowych. Procedury na taką okoliczność mogą okazać się zbawienne. Warto o tym pamiętać.

Znaczenie zarządzania logami dla bezpieczeństwa organizacji

W artykule postaramy się przybliżyć tematykę zbierania i analizy szeroko rozumianych logów systemów informatycznych. Wyjaśnimy przy okazji, czym jest ostatnio popularne ostatnio pojęcie SIEM.

Cechą wszystkich systemów informatycznych jest to, że zapisują logi, czyli prowadzą dzienniki swoich działań. Bez logów niemożliwe byłoby zarówno bieżące nadzorowanie takich systemów, jak też dochodzenie przyczyn ich awarii. Logi systemowe mogą być także kopalnią wiedzy na temat zagrożeń i ataków, z którymi przychodzi mierzyć się serwerom i aplikacjom. Niestety, to ostatnie zastosowanie najczęściej jest zaniedbywane.  

Każdy, kto kiedyś zaglądał w dzienniki jakiejś aplikacji dostępnej w sieci, choćby wewnętrznej, zdaje sobie sprawę, jak bogate życiea ona prowadzi: loguje użytkowników  bądź odmawia zalogowania, dostarcza określonych zasobów, wchodzi w interakcje z innymi systemami, nawiązuje własne połączenia, miewa problemy z działaniem, zamyka się i jest uruchamiana – przykładów jest wiele. Wśród takich rejestrowanych działań oczywiście mogą pojawiać się też takie, które wynikają z prowadzonego ataku (bo atak sieciowy to pewna sekwencja zdarzeń odnotowanych na poszczególnych urządzeniach), bądź już jego konsekwencji (np. wyprowadzanie danych). To teraz wyobraźmy sobie firmę, gdzie mamy serwery HTTP,  load balancery, serwery backupu, program kadrowy, aplikację do fakturowania, serwer dyskowy, programy antywirusowe i wszystko to spięte infrastrukturą sieciową, która także składa się z podsystemów, jak przełączniki, routery, access pointy czy zapory sieciowe. Każdy z tych elementów jest źródłem logów. Każde takie źródło podczas ataku cybernetycznego wygeneruje i zapisze informacje, które danego ataku będą dotyczyć.

Wyobraźmy sobie zatem, jaką ilość informacji firma powinna przetworzyć, żeby trzymać rękę na pulsie.  Przyjrzyjmy się teraz, dlaczego jednak warto to robić i jak można sobie taką pracę ułatwić.

Ze wszelakich statystyk wynika, że w cyklu życia incydentu najdłuższy jest czas od wykonania ataku do momentu jego wykrycia, który to najczęściej wynosi tygodnie lub miesiące (polecamy tu np. coroczne raporty Verizon).  W tymże okresie atakujący prawdopodobnie będą buszować po serwerze i sieci lokalnej ofiary, prowadząc podsłuch, wyprowadzając dane i próbując kompromitować kolejne systemy. Dlatego codzienna analiza logów powinna być częścią obowiązków administratora systemów IT, tak samo jak bieżąca obsługa takich systemów, wgrywanie aktualizacji itd. Wykonywanie obowiązku monitoringu logów można sobie na szczęście ułatwić, choćby gromadząc wszystkie dzienniki w jednym miejscu – a konkretnie systemie, który je będzie agregował. Taki system nosi fachową nazwę “loghost” i spowoduje, że nie trzeba będzie przeglądać logów na każdym systemie IT z osobna. Przede wszystkim jednak, widząc zdarzenia ze wszystkich systemów w jednym zestawieniu, doświadczony administrator może zauważyć związki (korelacje) pomiędzy nimi i wyciągnąć czasem krytyczne dla firmy wnioski.

Monitoring logów można zoptymalizować jeszcze bardziej. Stanie się to dzięki zastosowaniu aplikacji, którae będzie nie tylko logi agregować, ale także znajdować korelację pomiędzy nadesłanymi danymi i samoczynnie oceniać stopień zagrożenia na bazie pojedynczych, jak też skorelowanych informacji. Aplikacja taka może robić to w czasie rzeczywistym, wysyłając powiadomienia o sytuacjach, które uzna za groźne. Takie aplikacje nazywamy SIEM (Security Information and Event Management) i obecnie notujemy na rynku ogromny wzrost ich popularności.  Siła SIEM-ów leży przede wszystkim w dużej liczbie i jakości reguł korelacji, która jest w nie wbudowana. Reguły te odzwierciedlają sekwencje różnych ataków i wynikają z doświadczeń producentów SIEM, gromadzonych często latami, podczas monitorowania cyberprzestrzeni, jak też analizy konkretnych przypadków włamań. Ponadto aplikacje tego typu umożliwiają długoterminowe przechowywanie danych historycznych – a takie mogą być potrzebne, gdyby jednak doszło do włamania i trzeba by prześledzić jego historię. Środowiska IT w firmach mają raczej tendencje rozwojowe, podobnie jak liczba ataków na świecie.  Wymaga to zastosowania skalowalnego rozwiązania do analizy logów. Systemy SIEM wpisują się dobrze w takie potrzeby. Zwykle wraz ze wzrostem liczby źródeł danych do analizy wystarczy rozbudować zasoby sprzętowe systemu. Rynek aplikacji SIEM także nie będzie więc malał. Klient musi tylko dobrze wybrać. Jak ? – polecamy choćby zajrzeć do raportów Gartnera.

O bezpieczeństwie aplikacji webowych z lotu ptaka

W niniejszym artykule chcemy nakreślić podstawowe zagadnienia związane z bezpieczeństwem aplikacji webowych.

Można śmiało powiedzieć, że aplikacje webowe to obecnie jeden z najbardziej rozpowszechnionych typów oprogramowania. Używając słowa „aplikacja”, mamy na myśli serwisy WWW, które generują zawartość dynamicznie, tj. zmieniają swój wygląd pod wpływem działań użytkownika. W tym znaczeniu aplikacją webową nie będzie np. statyczna (tj. zawsze posiadająca ten sam, niezmienny dla użytkownika wygląd) strona napisana w czystym języku HTML. Będzie nią natomiast już serwis napisany choćby w języku PHP, który przyjmuje i wykonuje akcje od użytkownika, np. wysłanie formularza, wyszukanie produktu czy zalogowanie. W wypadku wspomnianego PHP wypadałoby jednak zastrzec, że złośliwi twierdzą, iż pojęcie takie jak „programista PHP” jest sprzeczne samo w sobie (a wręcz że to oksymoron) i, co za tym idzie, taki sam charakter ma “aplikacja webowa w PHP”. Tak naprawdę jednak kod witryn pisanych w tym języku potrafi być zarówno bardzo skomplikowany, jak też może sprowadzać się oczywiście do pojedynczych wstawek PHP w kodzie HTML.

Z punktu widzenia bezpieczeństwa aplikacje webowe są znacznie bardziej interesujące niż statyczne strony HTML. Te ostatnie posiadają przede wszystkim znacznie mniejszą powierzchnię ataku. Dla porównania możemy wyobrazić sobie długi i gruby mur pozbawiony bram, zbudowany z dużych i identycznych cegieł – w charakterze strony statycznej, oraz drugi – równie gruby ale zbudowany z różnorakich budulców, jak cegły, pustaki, drewno czy kamienie użyte w różnych konfiguracjach i do tego wyposażony w wiele różnych bram. W tym drugim wypadku możliwość znalezienia słabego punktu będzie znacznie bardziej prawdopodobna – wspomniana powierzchnia ataku będzie większa. Tak jak właśnie w wypadku dynamicznych stron WWW – aplikacji webowych.

Strony WWW, które reagują zmianą wyglądu i zachowania na działania użytkownika, przede wszystkim muszą przyjmować od niego wartości różnych zmiennych, jak choćby login i hasło, język w którym będzie wyświetlana treść, wspomniana fraza do wyszukania treści czy nazwa produktu, którego szczegółowe dane zostaną wyświetlone. Takie zmienne przesyłane przez przeglądarkę (tzw. parametry zapytań) pozwalają witrynie WWW wejść w interakcję z użytkownikiem, przy okazji stanowiąc też niestety potencjalną furtkę do włamania. Przeglądarka WWW ogranicza co prawda zakres danych, które mogą zostać przesłane do danego serwisu webowego, ale atakujący nie jest z kolei ograniczony do używania przeglądarki. Sztandarowym narzędziem atakujących aplikacje webowe (ale także testujących ich bezpieczeństwo) jest tzw. „intercepting proxy” – czyli program, który pozwala przechwycić wysyłane przez przeglądarkę żądania, a następnie już dowolnie je modyfikować i przesyłać w takiej formie do atakowanego serwera.

W jaki sposób spreparowany parametr żądania może naruszyć bezpieczeństwo aplikacji? Otóż treść żądania HTTP przetwarzana w aplikacji jest zazwyczaj przez wiele warstw programowych, np. żądanie jest dekodowane, następnie mapowane na zasób dyskowy bądź konkretny segment kodu wykonywalnego aplikacji, dalej może trafić do systemu bazodanowego, z którego to zostanie pobrana odpowiedź. Na końcu użytkownikowi zostanie wyświetlona odpowiedź na jego żądanie, która będzie z nim związana pośrednio (np. poprzez zapytanie do bazy danych) lub bezpośrednio (np. użytkownik zobaczy jakie przed chwilą zapytanie wpisał w polu wyszukiwania). W praktyce warstw tych może być więcej, a na każdej z nich może okazać się, że programista za nią odpowiedzialny nie przewidział skutków jakie wywoła dostarczenie odpowiednio spreparowanych danych (czyli głównie parametrów żądań) bądź ich konfiguracji. Co więcej, może zdarzyć się także, że pozornie nieznaczące uchybienia bezpieczeństwa na kilku warstwach mogą zsumować się do bardzo groźnej podatności (zaryzykujmy tu użycie pojęcia synergii). Pojęcie warstw aplikacji możemy rozszerzyć na komponenty, tj. dana warstwa może być zbudowana z wielu różnych komponentów, którymi są najczęściej biblioteki programistyczne.

Ten krótki artykuł pozwoli nam zrozumieć, jak skomplikowany system może stać za zmieniającymi się podstronami w naszej przeglądarce WWW. Niestety, wysoki poziom skomplikowania powoduje adekwatne ryzyko występowania błędów.

©Prawa autorskie. Wszystkie treści opublikowane na tym blogu objęte są prawami autorskimi. Zabrania się kopiowania, rozpowszechniania i ich odtwarzania bez zgody autora.

Błażej Bednarski – autor

Jest wieloletnim ekspertem z zakresu zarządzania systemami IT i bezpieczeństwa. Specjalizuje się w analizach podatności i testach bezpieczeństwa.