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ć.
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.
W niniejszym artykule omówimy metody, które mogą służyć do oceny stanu bezpieczeństwa sieci komputerowej. Najprościej mówiąc (za Słownikiem Języka Polskiego) stan bezpieczeństwa to stan braku zagrożeń. Bezpieczny system komputerowy to zatem system posiadający cechy, które skutecznie utrudniają nieuprawniony dostęp do jego zasobów.
Opiszemy różne metody określania i podnoszenia bezpieczeństwa w systemach IT. Pokażemy też, że brak widocznych symptomów włamania nie daje miarodajnej wiedzy na ten temat oraz wskażemy, skąd taką wiedzę powinniśmy czerpać.
Metody ochrony sieci i systemów komputerowych najprościej można podzielić na reaktywne oraz proaktywne.
Metody reaktywne można przez analogię porównać do alarmu i monitoringu wizyjnego w budynku mieszkalnym. Spowodują wszczęcie alarmu po wykryciu podejrzanego działania, bądź też dostarczą informacji, na podstawie których operator będzie w stanie wywnioskować, że dzieje się coś niepożądanego. Wymieńmy podstawowe metody reaktywne w systemach IT:
Wymienione wyżej nazwy sugerują same, że chodzi tutaj o wykrycie konkretnego zdarzenia, czyli mówiąc bardziej fachowo: incydentu bezpieczeństwa. Incydent taki jest pojęciem szerokim i może składać się z kilku etapów, takich jak: rekonesans, kolejne próby przełamania wybranych zabezpieczeń, a następnie zainstalowanie ukrytej furtki (ang. backdoor) oraz finalnie eskalacja uprawnień – przełamanie kolejnych, głębszych zabezpieczeń, w celu osiągnięcia jak najwyższych praw dostępu lub najbardziej cennych danych. Wymienione powyżej przykładowe metody reaktywne odpowiadają różnym etapom ataku i mogą tu zadziałać z osobna lub łącznie.
Sens zastosowania takich metod jest oczywiście bezsporny, niemniej jednak zasadne byłoby postawienie tu prostego pytania – „Czy to nie jest już trochę za późno?”.
Wracając do naszej analogii z budynkiem mieszkalnym – świetnie jest mieć informację o fakcie włamania się, ale idealnie byłoby, gdyby do tego włamania w ogóle nie doszło. Ponadto, czy brak sygnałów z systemów reaktywnych świadczy o wysokim bezpieczeństwie, czy może raczej o wysokich kompetencjach atakującego, który potrafi np. rozciągać atak w czasie, manewrować źródłowymi adresami IP i technikami oraz dysponuje zaawansowanymi “backdoorami” integrującymi się z głębokimi warstwami systemów operacyjnych?
Co więcej, już po uzyskaniu dostępu, atakujący z reguły nadal będzie chciał pozostać niezauważony przez długi czas, który umożliwi mu zorientowanie się, jakie dane i zasoby warte są jego uwagi.
W tym właśnie miejscu należałoby odwołać się do istnienia metod proaktywnych. Idąc w ślad za pierwotną definicją proaktywności – z obszaru psychologii – można powiedzieć, że są to metody polegające na kontrolowaniu danych sytuacji, przewidywaniu negatywnych scenariuszy oraz – co najważniejsze – zapobieganiu im.
Wracając do świata IT, metodami proaktywnymi określania i podnoszenia bezpieczeństwa są:
Jak widać, wszystkie powyższe metody, w odróżnieniu od wcześniejszych, mają charakter zapobiegawczy. Skupmy się na dwóch pierwszych – obie polegają na badaniu odporności systemów i są metodami technicznymi.
Skanowanie pod kątem podatności to proces w dużej mierze zautomatyzowany. Dedykowany takiemu zadaniu skaner posiada bazę tysięcy znanych podatności, podatnych wersji oprogramowania i słabych konfiguracji usług. Baza taka służy do porównania z obrazem testowanej sieci, jaki jest uzyskiwany w procesie skanowania. Za wynikami takiego skanu oczywiście powinno pójść wprowadzenie poprawek i zabezpieczeń (oraz optymalnie ponowny skan). Jeśli skany są wykonywane regularnie od momentu powstania danej infrastruktury IT, to nasza pewność co do tego, że nie została ona gdzieś po drodze zasiedlona przez niepożądanych gości, powinna znacznie wzrosnąć – analogicznie jak w wypadku budynku z przeciwwłamaniowymi oknami, drzwiami i zamkami.
Pogłębioną względem skanów metodą analizy podatności są testy penetracyjne. W tym podejściu wyniki skanów stają się zaledwie wstępem do dalszych działań i stanowią fazę rekonesansu dla ataków. Mówimy oczywiście o atakach kontrolowanych i symulowanych, bo tak można określić testy penetracyjne. Testy penetracyjne od prawdziwych ataków różnią się jednak zasadniczo. Przede wszystkim:
Czasochłonność ich wykonania względem skanów bezpieczeństwa jest znacząco większa, ponieważ w dużo większym stopniu angażuje się tu ludzi (ekspertów). Należy jednak stwierdzić, że o ile poprawnie przeprowadzone skany chronią przed podstawowymi i masowymi zagrożeniami z Internetu, to w wypadku testów penetracyjnych mówimy o ochronie przed atakami bardziej zaawansowanymi – podobnie jak one same prowadzonymi przez ludzi, a nie automaty.
O testach penetracyjnych, jak i innych proaktywnych metodach można by napisać jeszcze wiele ale to już temat na kolejne artykuły naszego bloga. 🙂
