Security Operations Center w podejściu RSA

Autor: Grzegorz Mucha
Senior Systems Engineer, RSA, Dział zabezpieczeń EMC.

Gdyby jeszcze kilka lat temu poddać w wątpliwość bezwzględną skuteczność ówczesnych rozwiązań bezpieczeństwa, można by zostać zakrzyczanym: „Jak to? Wydaliśmy setki tysięcy złotych na najbardziej zaawansowane firewalle, IPS-y, systemy antywirusowe; przeszliśmy pomyślnie testy penetracyjne i audyty bezpieczeństwa, a Pan mówi, że ktoś może się do nas włamać? To niedorzeczne!”. Historie kilku wielkich i wielu mniejszych firm pokazują, że coś jednak na rzeczy jest. W miarę rozwoju technik ataków i środków na nie przeznaczanych, a niejednokrotnie również wsparcia służb wrogich państw, musimy się zacząć przyzwyczajać do myśli, że nasza z trudem budowana ochrona nie gwarantuje, że nikt obcy w naszej sieci się nie znajdzie i nie będzie miał dostępu do strzeżonych danych. Co więcej, głównym mottem współczesnych przestępców jest „powoli, cierpliwie, po cichu”. Owszem, gdzieś wciąż czają się aktywiści, którym zależy przede wszystkim na rozgłosie, ale w większości przypadków możemy się spodziewać, że wroga obecność zostanie odkryta po tygodniach czy nawet miesiącach od wejścia do systemu IT. Dlaczego?

Środowiska informatyczne stają się coraz bardziej złożone i coraz trudniejsze do spójnego monitorowania. Ze względu na ową złożoność, zarządzaniem nimi zajmuje się coraz większa liczba osób, a zazwyczaj różne logiczne elementy środowiska zarządzane są przez inne grupy, np. kto inny zarządza infrastrukturą wirtualną, kto inny system operacyjnym maszyn wirtualnych, a jeszcze kto inny działającymi tam bazami danych. Występujące nierzadko wewnętrzne animozje pomiędzy tymi grupami (związane np. z konkurowaniem o ten sam budżet) nie ułatwiają komunikacji i tworzą precedensy utrudniania czy opóźniania dostępu do informacji. Kolejny powód to coraz większe wymagania samych użytkowników – mobilność, dostęp z każdego miejsca i każdego urządzenia, a równocześnie minimum utrudnień. Oczywiście, wielu administratorów bezpieczeństwa chciałoby zablokować wszystko co możliwe na komputerach użytkowników, ale w konfrontacji z użytkownikiem biznesowym ich szanse są marne. Nie można też zapomnieć o współpracujących z nami firmach czy konsultantach zewnętrznych, wobec których, co do zasady, kontrola jest ograniczona. To wszystko powoduje, że miejsc, w których przestępca może się ukryć, jak również tych, na które i z których może przeprowadzić atak, jest coraz więcej. A co się dzieje, gdy atak nastąpi? Często okazuje się, że choć obca obecność zostaje w końcu wykryta, problemem jest czas, jaki upłynął od ataku do wykrycia, trudne lub niemożliwe staje się zrozumienie w jaki sposób przestępca przeniknął systemy obrony (i jak może to zrobić ponownie), zrozumienie jakie szkody spowodował, i wreszcie brak jest możliwości szybkiej oraz skutecznej reakcji. Celem takiej reakcji powinno być nie tylko powstrzymanie wykrytej obecności, ale minimalizacja strat biznesowych, reewaluacja ryzyka i wdrożenie odpowiednich działań naprawczych.

W wielu organizacjach alokacja środków skupiona jest na obszarze prewencji. Firmy inwestują w systemy aktywnych zabezpieczeń i automatyzację alarmów, a równocześnie zmniejszają budżety operacyjne przeznaczone na bezpieczeństwo. W efekcie rośnie ilość systemów do zarządzania, zaś obsługą zdarzeń bezpieczeństwa zajmują się administratorzy, których podstawowym zadaniem jest utrzymanie tychże systemów. Niestety, takie podejście staje się coraz mniej aktualne. Arogancją byłoby stwierdzenie, że prewencja przestała być potrzebna, ale najwyższy czas uznać, że głównym celem działań w zakresie bezpieczeństwa jest ochrona wartości biznesowych organizacji, a nie zapobieganie włamaniu samemu w sobie. Najlepszym sposobem zapobiegania stratom biznesowym jest szybka identyfikacja oraz reakcja na atak. Aby to osiągnąć organizacje powinny przenieść część środków na inwestycję w inteligentne systemy rozszerzające możliwości wykrywania i odpowiedzi na skomplikowane ataki. Systemy takie muszą umożliwić pełny wgląd w środowisko IT oraz wykorzystywać zewnętrzne źródła informacji o zagrożeniach. W wyniku tych działań znacznie zwiększy się ilość i rodzaj danych do analizy – i organizacje muszą się nauczyć z nich korzystać. Nie wystarczy bowiem zebranie samych logów z urządzeń oraz statystycznych informacji o ruchu sieciowym, ustawienie dziesiątek reguł alarmów i przekonanie, że system obroni się sam.

SOC i Intelligence-driven Security

Grupa Security for Business Innovation Council, zrzeszająca osoby zarządzających bezpieczeństwem w największych firmach, zaproponowała nowe podejście ochrony krytycznych informacji i zasobów biznesowych, nazwane „intelligence-driven security”. Język angielski ma swoistą łatwość w formułowaniu tak zwięzłych, a równocześnie niosących pełną treść sformułowań, po polsku trzeba by pewnie powiedzieć, że jest to podejście zakładające wykorzystanie każdej dostępnej informacji dotyczącej bezpieczeństwa, pochodzącej ze źródeł wewnętrznych i zewnętrznych, w celu identyfikacji ukrytych zagrożeń, a potencjalnie również ich przewidywania. Główną tezą jest ograniczenie polegania na systemach statycznej ochrony i rozwiązaniach bazujących na sygnaturach, które potrafią identyfikować typy ataków, które wydarzyły się już w przeszłości. Zamiast tego należy poszukiwać podejrzanych aktywności i wzorców nietypowych w konkretnym środowisku. Narzędziem do wdrożenia tego zalecenia jest utworzenie dedykowanego centrum ds. bezpieczeństwa, czyli SOC-u (SOC – Security Operations Center).

Aby SOC był skuteczny, musi być zbudowany niezależnie od istniejącego centrum zarządzania infrastrukturą. Zadaniem SOC nie jest bowiem codzienne utrzymanie środowiska i reagowanie na awarie, SOC ma skupiać wyłącznie na incydentach bezpieczeństwa i ich jak najszybszym rozwiązywaniu. To trochę tak jak z armią – większość państw utrzymuje siły zbrojne, które wykonują w miarę rutynowe działania, obarczone pewną bezwładnością i przewidywalnością. Ale w wojsku istnieją też niewielkie (w porównaniu z innymi) siły specjalne, stanowiące osobny pion, podległy bezpośrednio pod główne dowództwo, mający własny regulamin i dużo większą swobodę działań niż regularne jednostki, zdolny błyskawicznie reagować na sytuacje krytyczne. Tak samo SOC, który musi widzieć całą organizację jako jeden organizm, jego szef najlepiej, żeby podlegał bezpośrednio pod zarząd, a sam SOC musi łączyć w sobie technologie, odpowiednie procesy oraz dedykowany personel.

Z tej trójki najmniej myśli się o procesach – a SOC powinien być odpowiedzialny za regularną ocenę ryzyka ataku, szacowanie wektorów ataku, badanie zagrożeń, szacowanie stanu bezpieczeństwa i ciągłe podnoszenie stopnia dojrzałości organizacji przez projektowanie i testowanie planów zarządzania odpowiedzią na atak – zarówno ze strony technologicznej, jak i organizacyjnej (np. wyznaczone procedury współpracy w działem prawnym oraz działem PR). Osoby pracujące w SOC nie mogą się równocześnie zajmować administrowaniem systemami lub innymi zadaniami w dziale IT. Ich zadaniem jest rozpoznanie incydentu, jego ocena oraz przedsięwzięcie adekwatnych działań w jak najkrótszym czasie. SOC musi zatrudniać osoby lub współpracować z zewnętrznymi ekspertami w dziedzinie informatyki śledczej, analityki danych, analizy zagrożeń. Kwalifikacje takich osób powinny być regularnie podnoszone, i jest to zadanie managera SOC. Pracownicy SOC obsługujący incydenty powinny mieć odpowiednie prerogatywy nadane przez zarząd, aby nie okazało się, że śledztwo w sprawie krytycznego incydentu nagle staje na kilkanaście godzin, ponieważ jest weekend i śledczy musi oczekiwać na uzyskanie zgody na dostęp do jakiegoś systemu w celu zebrania dowodów do poniedziałku, kiedy w pracy będzie odpowiedni manager – a istnieje ryzyko, że w tym czasie dowody zostaną zniszczone lub utracone.

Zostały jeszcze technologie – tu można by wyróżnić kilka kluczowych wymagań:

  • skalowalna analityka, czyli mechanizmy umożliwiające analizę dużych ilości ciągle zmieniających się danych w czasie bliskim rzeczywistemu
  • hurtownia danych, zbierająca wszelkie informacje związane z bezpieczeństwem w jednym miejscu, powiązane wzajemnie między sobą i dostępne dla mechanizmów analitycznych
  • elastyczna architektura systemów monitorowania, umożliwiająca zbieranie danych z różnych źródeł i w różnych formatach, ich indeksowanie, normalizację i analizę
  • centralna konsola do prowadzenia śledztw i do zarządzania odpowiedzią na incydent
  • nagrywanie ruchu sieciowego, dające możliwość rekonstrukcji sesji sieciowych, czy wyciągnięcie przesłanych plików do analizy
  • integracja z wewnętrznymi źródłami danych np. o zasobach wewnętrznych, ich znaczeniu biznesowym dla organizacji
  • integracja z zewnętrzną informacją o zagrożeniach, możliwość korelacji tych danych z pozyskanymi informacjami o zdarzeniach i ruchu sieciowym

Jak to można robić – przykład

Dobrym przykładem na realizację idei SOC-a jest EMC – globalna firma, która przechodzi ciągły proces udoskonalania narzędzi, umiejętności i procesów związanych z zarządzaniem bezpieczeństwem. jednym z kroków na tej drodze było utworzenie wewnętrznego CIRC-u (Critical Incident Response Center), który zbiera informacje z całej organizacji i stanowi centralny punkt monitorowania i wymuszania bezpieczeństwa i integralności zasobów firmy. Skala nie jest mała – EMC CIRC zbiera dane m.in. z ponad 1,400 urządzeń zabezpieczających i 250,000 komputerów rozsianych w 500 lokalizacjach na całym świecie.

W ramach CIRC zespół dobrze wytrenowanych specjalistów monitoruje globalne środowisko IT EMC, odpowiada na zagrożenia i podatności, od malware’u i wycieku danych po czysto fizyczne jak kradzież sprzętu. CIRC prezentuje działania swojej pracy bezpośrednio do wyższego managementu, co pozwala na skuteczne wdrożenie idei ciągłej poprawy stanu bezpieczeństwa organizacji.

EMC CIRC zbudowany jest przede wszystkim o oparciu o technologie i najlepsze praktyki od RSA. Choć w CIRC wykorzystywane są różne narzędzia, serce systemu stanowią rozwiązania RSA Archer i RSA Security Analytics. Te dwa systemy integrują dane pochodzące z innych narzędzi i dają personelowi CIRC jedno spójne repozytorium informacji i centralny punkt zarządzania, co widać na poniższym rysunku.

rysunek1

Integracja RSA Archer z RSA Security Analytics pozwala na zbudowanie skutecznego przepływu danych i sterowania pracą, a co za tym idzie pozwala na przyspieszenie obsługi incydentów i zmniejszenie czasu na zamknięcie tych incydentów.

Codziennie do CIRC trafiają setki alarmów. Zanim alarm zostanie przesłany analitykowi do dalszego śledztwa, jest automatycznie korelowany z zestawem danych związanych z incydentem. W celu integracji danych kontekstowych i zewnętrznych informacji w procesie wykrywania i odpowiedzi na incydent zostało specjalnie opracowanych kilka procesów i technologii. EMC CIRC m.in. opracował system wskazywania na zagrożenie w oparciu o informacje z wewnętrznych i zewnętrznych źródeł, informacji od partnerów i własnego zespołu RSA FirstWatch. Wskaźniki zagrożeń (IOC – Indicators of Compromise) obejmują szeroki zakres informacji, od podejrzanych adresów IP i wrogich domen, do charakterystyk komunikacji, takich jak specyficzne nagłówki maili. Wskaźniki są klasyfikowane względem poziomu ważności (severity) i automatycznie ładowane do Security Analytics jako tzw. feed, który pozwala na wygenerowanie dodatkowych metadanych. Na przykład znana z ataków APT domena wygeneruje metadaną o wartości „Severity 1” dla każdej aktywności, w której pojawi się ta domena. Alarmy oparte o tą metadaną są przesyłane do konsoli Archera, gdzie mogą utworzyć lub uzupełnić incydent. Zanim jednak alarm dotrze do analityka, z centralnej bazy CIRC dołączane są do opisu sesji dodatkowe elementy, pomagające analitykowi zobaczyć pełen kontekst zdarzenia. Rysunek poniżej pokazuje jak działa proces wzbogacania danych i utworzenia ostatecznego alarmu.

rysunek2

Automatyczna analiza końcówek

Wspomnieliśmy o logach i analizie ruchu sieciowego, ale nie sposób pominąć serwerów i stacji końcowych użytkowników. Nie jest niczym nowym stwierdzenie, że systemy antywirusowe oraz hostowe IPS-y, które wciąż bazują głównie na sygnaturach, coraz trudniej wykrywają współczesny malware, i są zupełnie nieskuteczne wobec ataków celowanych typu APT. O ile tradycyjne podejście do bezpieczeństwa stacji końcowej jest wciąż ważnym składnikiem całościowego bezpieczeństwa, nie można już liczyć na to, że załatwi wszystkie problemy. Z tego powodu EMC CIRC wdrożyło rozwiązanie RSA ECAT (Enterprise Compromise Assessment Tool) jako dodatkowe narzędzie analizy, wykorzystywane do sprawdzania końcówek, co do których istnieje podejrzenie zarażenia lub innego rodzaju wrogiej obecności – na co może wskazywać np. analiza ruchu sieciowego z takiego komputera.

RSA ECAT wykorzystuje wiele technik analizy komputera i wykrywa anomalie typowe dla zarażeń złośliwym oprogramowaniem, takich jak hooking, modyfikacje jądra systemu, modyfikacje uruchomionych procesów w pamięci, zmiany w rejestrach, ukrywanie komunikacji, itp. ECAT pozwala również błyskawicznie porównać stan systemu z czystym systemem wzorcowym i wykryć wszelkie odstępstwa. Analizę może przyspieszyć identyfikacja „dobrego” oprogramowania dzięki wykorzystaniu list znanych programów np. od Bit9. Nieznane pliki mogą być dodatkowo wysłane do przeskanowania przez OPSWAT Metascan, wykorzystujący wiele silników antywirusowych. Ten mechanizm pozwala ograniczyć listę podejrzanych plików, którymi powinien się zająć analityk malware’u, a tym samym znacznie przyspieszyć czas analizy. Na koniec analizy ECAT produkuje wynik (MSL – Machine Suspect Level), który wskazuje na prawdopodobieństwo, że stacja została skutecznie zaatakowana lub zarażona. Co więcej, dzięki zbieraniu wyników skanów do wspólnej bazy, analityk który zidentyfikuje podejrzany proces na jednym komputerze może natychmiast sprawdzić, na jakich innych komputerach ten proces był uruchomiony. Analiza jest wykonywana na bardzo niskim poziomie, a zastosowane techniki praktycznie uniemożliwiają malware’owi ukrycie się przez ECAT-em.

Wdrożenie ECAT-a w EMC CIRC pozwoliło na jeszcze lepszą priorytetyzację prac i dalsze zredukowanie czasu obsługi incydentu, w którym istniało podejrzenie co do integralności stacji końcowej użytkownika.

Podsumowując – nie ma i nie sądzę, żebyśmy doczekali w pełni automatycznej metody wykrywania wszystkich zagrożeń oraz ich likwidacji. Zamiast polegać na pojedynczych technologiach organizacje powinny realokować część budżetu na stworzenie SOC-a opartego na takich rozwiązaniach, które umożliwią szybką i pełną analizę zdarzeń, z wykorzystaniem co najmniej informacji z logów, pełnego ruchu sieciowego oraz stacji użytkowników, a także informacji wewnętrznych i zewnętrznych wzbogacających kontekst zdarzeń i dających odniesienie do wartości biznesowej chronionych zasobów. Technologie nie mogą żyć w oderwaniu od ludzi – SOC powinien być obsługiwany przez zespół stale podnoszących swoje kwalifikacje fachowców, którzy nie mają w swoich obowiązkach zajmowania się codziennym utrzymaniem systemów. Ponadto żeby działania zespołu SOC były skuteczne, za jego stworzeniem musi iść wsparcie na poziomie zarządu firmy, oraz dobrze zdefiniowane i opisane procesy.

I jeszcze jedna rzecz – zdaję sobie sprawę, że wielu czytelników może pomyśleć „EMC? Globalna korporacja? 250,000 komputerów? Jak to się na do naszych polskich realiów?”. Otóż ma się, i nie chodzi o wielkość organizacji, tylko o zasadę. Dokładnie te same potrzeby mają nasze rodzime firmy, dokładnie te same idee i te same technologie mają zastosowanie dla lokalnych SOC-ów. Nikt nie mówi, że nie należy monitorować infrastruktury o dwa rzędy wielkości mniejszej, ani że SOC nie może na początek zatrudniać ledwie kilka osób. W końcu od ilości dużo ważniejsza jest skuteczność tych osób, a to można osiągnąć dzięki zaleceniom opisanym powyżej.

*w artykule wykorzystano materiały EMC.

Artykuł ukazał się także w Magazynie Informatyki Śledczej.

[ZOBACZ INNE WPISY W JĘZYKU POLSKIM]

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *