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 pełnego bezpieczeństwa. Co więcej, głównym mottem współczesnych przestępców jest „powoli, cierpliwie, po cichu”. 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, a zarządzaniem nimi zajmuje się coraz większa liczba osób. 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ń. 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. Często okazuje się, że choć obca obecność zostaje w końcu wykryta, problemem jest czas, jaki upłynął od ataku do wykrycia, zrozumienie w jaki sposób przestępca przeniknął systemy obrony (i jak może to zrobić ponownie), określenie 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 co wpływa na zmniejszenie budżetów operacyjnych przeznaczonych 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. 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.

SOC i Intelligence-driven Security

Grupa Security for Business Innovation Council, zrzeszająca osoby zarządzające bezpieczeństwem w największych firmach, zaproponowała nowe podejście do ochrony krytycznych informacji i zasobów biznesowych, nazwane „intelligence-driven security”. 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. Centrum ds. bezpieczeństwa ma skupiać się wyłącznie na incydentach bezpieczeństwa i ich jak najszybszym rozwiązywaniu. Ponadto SOC, musi widzieć całą organizację jako jeden organizm, a jego szef najlepiej, żeby podlegał bezpośrednio pod zarząd, a sam system 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 CIRC (Critical Incident Response Center) firmy EMC, który zbiera informacje z całej organizacji i stanowi centralny punkt monitorowania oraz wymuszania bezpieczeństwo i integralności zasobów firmy. 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ół 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.

W CIRC wykorzystywane są różne narzędzia, jednak 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. Integracja rozwiązań pozwala na zbudowanie skutecznego przepływu danych i sterowania pracą, a co za tym idzie wpływa  na przyspieszenie obsługi incydentów i zmniejszenie czasu ich zamknięcia.

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 oraz odpowiedzi na incydent zostało specjalnie opracowanych kilka procesów i technologii. Jedną z nich jest m.in. 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 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 przekazywane do Security Analytics jako tzw. feed, który pozwala na wygenerowanie dodatkowych metadanych. Na przykład znana z ataków APT (ang. APT – Advanced Persistent Threat) domena wygeneruje metadaną o wartości „Severity 1” dla każdej aktywności, w której pojawi się ta domena. Alarmy oparte o nią 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.

Automatyczna analiza końcówek

Wspomnieliśmy o logach i analizie ruchu sieciowego, ale nie sposób pominąć serwery i stacje końcowe użytkowników. 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 (ang. APT – Advanced Persistent Threat). Z tego powodu EMC CIRC wdrożyło rozwiązanie 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.

Rozwiązanie 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. 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 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.

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. 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ć mniejszej infrastruktury, ani że SOC nie może na początek zatrudniać 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.