Jak wykorzystać IOC w scenariuszach bezpieczeństwa?

Nie będzie przesadą stwierdzenie, iż sformułowanie „wskaźniki kompromisu” jako kalka z angielskiego Indicators of Compromise (IoC) nie przyjęło się w języku polskim. Będziemy więc używali oryginalnego skrótu, a nie odpowiedników.

Same IoC są jednym z popularniejszych terminów w cyberbezpieczeństwie i chyba każdy podświadomie go rozumie. Są one również wskazywane na końcu każdego artykułu analitycznego opisującego działanie malware. Zwykle po haśle „IoC” występują skróty MD5, adresy IP i inne dane techniczne, które powinny pomóc specjalistom ds. bezpieczeństwa w zwalczaniu konkretnego zagrożenia.

W tym artykule postaramy się wyjaśnić nieco dokładniej, czym są IoC, co się do nich zalicza i jak powinny być wykorzystywane w codziennej pracy zespołów ds. bezpieczeństwa informatycznego.

Co to są IoC?

IoC to dane techniczne, które można wykorzystać do niezawodnego identyfikowania złośliwych działań lub narzędzi, takich jak złośliwa infrastruktura (nazwy hostów, domen, adresy IP), komunikacja (adresy URL, wzorce komunikacji sieciowej itp.) lub implanty (skróty oznaczające pliki, ścieżki plików, klucze rejestru systemu Windows, artefakty zapisywane w pamięci przez złośliwe procesy itp.). Podczas gdy większość z nich będzie w praktyce skrótami plików (MD5, SHA) – oznaczającymi próbki złośliwych implantów – oraz nazwami domen –identyfikującymi złośliwą infrastrukturę (C&C) – ich charakter, format i reprezentacja nie są ograniczone. Istnieją jednak pewne standardy udostępniania IoC, takie jak STIX.

Jak wspomniano wcześniej, IoC są jednym z rezultatów działań wywiadowczych dotyczących cyberzagrożeń. Przydają się na poziomie operacyjnym i taktycznym do identyfikowania złośliwych elementów i pomagają powiązać je ze znanymi zagrożeniami. IoC są dostarczane klientom w raportach analitycznych i wywiadowczych oraz w kanałach danych technicznych, a także są dodatkowo zintegrowane z produktami obsługującymi Threat Intelligence.

Jak IoC wykorzystywane są w scenariuszach SOC?

Z naszej perspektywy każde centrum operacyjne bezpieczeństwa (SOC) wykorzystuje w swoich działaniach znane wskaźniki naruszenia, w taki czy inny sposób. Przejdźmy do konkretnych kategorii.

Prewencja

Ogólnie rzecz biorąc, dzisiejsze najlepsze praktyki SOC nakazują nam bronić się przed atakami poprzez blokowanie potencjalnych zagrożeń na jak najwcześniejszym etapie. jeżeli znamy dokładne przesłanki ataku, możemy go zablokować, a najlepiej zrobić to na wielu poziomach (zarówno sieciowym, jak i końcowym) naszego chronionego środowiska. Blokowanie wszelkich prób połączenia ze złośliwym adresem IP, rozwiązywania nazw C2 lub uruchomienia złośliwego systemu ze znanym hashem powinno zapobiec atakowi, a przynajmniej nie podać atakującemu celu na tacy. Oszczędza to również czas analityków w SOC i zmniejsza szum z fałszywych alarmów. Niestety wysoki poziom zaufania reguł ma najważniejsze znaczenie dla scenariusza użycia prewencji. W przeciwnym razie ogromna liczba blokad wywołanych „false-positive” wpłynęłaby na funkcje biznesowe chronionego środowiska.

Detekcja

Najpopularniejszy scenariusz wykorzystania IoC w SOC – automatyczne dopasowanie telemetrii z infrastruktury do ogromnej kolekcji wszystkich możliwych IoC. Najczęstszym miejscem do korelowania takich reguł jest SIEM. Scenariusz ten jest popularny z kilku powodów:

• SIEM rejestruje wiele typów zdarzeń, co oznacza, iż możemy dopasować ten sam IoC do wielu źródeł, np. nazwa domeny z żądaniami DNS, te otrzymane z korporacyjnych serwerów DNS i żądane adresy URL uzyskane z serwera proxy.
• Dopasowywanie w SIEM pomaga nam zapewnić rozszerzony kontekst dla analizowanych zdarzeń; z dodatkowych informacji analityk może dowiedzieć się, dlaczego alert oparty na IoC został uruchomiony, jaki jest to rodzaj zagrożenia, poziom ryzyka itp.
• Posiadanie wszystkich danych na jednej platformie może zmniejszyć obciążenie zespołu SOC związane z utrzymaniem infrastruktury i zapobiec konieczności organizowania dodatkowych kanałów obsługi zdarzeń.

Innym popularnym rozwiązaniem do dopasowywania danych do IoC są platformy Threat Intelligence. Zwykle obsługują dokładniejsze scenariusze dopasowywania i zakładają zmniejszenie wpływu na wydajność środowiska. Kolejną ogromną zaletą TIP jest to, iż tego typu rozwiązanie zostało początkowo zaprojektowane do pracy właśnie z IoC, do obsługi ich schematu danych i zarządzania nimi, z większą elastycznością i funkcjami do konfigurowania logiki detekcji złośliwego zachowania.

Jeśli chodzi o wykrywanie (detekcję) jesteśmy tutaj bardziej tolerancyjni w przypadku fałszywych alarmów. Przyjęło się, iż przy ogromnej ilości dostarczanych informacji jest to normą.

Inwestygacja

Inną procedurą, w ramach której współpracujemy z IoC, jest faza dochodzenia w sprawie każdego incydentu. W tym przypadku jesteśmy zwykle ograniczeni do określonego podzbioru IOC – tych, które zostały ujawnione w ramach konkretnego incydentu. Wskaźniki są potrzebne do zidentyfikowania dodatkowych dotkniętych atakami celów w naszym środowisku, aby określić rzeczywisty zakres incydentu. Zasadniczo zespół SOC obraca się w takiej pętli:

1. Zidentyfikuj IOC związane z incydentem
2. Wyszukaj IOC na dodatkowych hostach
3. Zidentyfikuj dodatkowy IOC na ujawnionych celach, powtórz krok 2.

Threat Hunting

Przez polowanie na zagrożenia rozumiemy działania mające na celu ujawnienie ukrytej złośliwej aktywności, takiej, która ominęła możliwości zapobiegania i wykrywania innych systemów. Zgodnie z regułą „Assume Breach” zakładamy, iż pomimo wszystkich możliwości zapobiegania i wykrywania możliwe jest, iż przegapiliśmy udany atak i musimy przeanalizować naszą infrastrukturę tak, jakby była naruszona, i znaleźć ślady tego naruszenia.

Prowadzi nas to do polowania na zagrożenia opartego na IoC. Zespół SOC analizuje informacje związane z atakiem i ocenia, czy zagrożenie dotyczy chronionego środowiska. jeżeli tak, hunter próbuje znaleźć IoC w przeszłych zdarzeniach (takich jak zapytania DNS, próby połączenia IP, wykonanie procesów) lub w samej infrastrukturze – obecność określonego pliku w systemie, określonej wartości klucza rejestru itp. Typowymi rozwiązaniami wspierającymi zespół SOC w takiej działalności są SIEM, EDR i TIP. W przypadku tego typu scenariuszy najbardziej odpowiednie IoC to te wyodrębnione z raportów APT.

Rodzaje IoC

W scenariuszach użycia IoC wielokrotnie poruszaliśmy zagadnienie różnych ich typów. Podsumujmy te informacje, dzieląc rodzaje IoC według ich pochodzenia:

• Kanały dostawców – subskrypcja IoC dostarczana przez dostawców zabezpieczeń w formie feed. Zwykle zawiera ogromną liczbę IoC obserwowanych w różnych atakach. Poziom zaufania różni się w zależności od dostawcy, a zespół SOC powinien wziąć pod uwagę jego specjalizację i profil geograficzny, aby wykorzystać rzeczywiste wskaźniki. Taka integracja często uważana jest za wątpliwą ze względu na potencjalnie wysoki poziom fałszywych trafień.
• Incydenty – IoC generowane przez zespół SOC podczas analizy incydentów bezpieczeństwa. Zwykle najbardziej zaufany typ IoC.
• Threat Intelligence — ogromna rodzina IoC wygenerowana przez specjalistów. Jakość zależy bezpośrednio od poziomu wiedzy analityków TI. Wykorzystanie ich do zapobiegania zależy w dużej mierze od jakości danych TI i może wywołać zbyt wiele fałszywych alarmów, a tym samym wpłynąć na działalność biznesową.
• Peer IoC – zapewniane przez organizacje partnerskie, jednostki rządowe i społeczności branżowe. Zwykle można je uznać za podzbiór IoC TI, w zależności od charakteru społeczności.

Jeśli podsumujemy przejrzane scenariusze, pochodzenie IoC l i ich zastosowanie, a następnie zmapujemy te informacje na etapy obsługi incydentów, możemy stworzyć poniższą tabelę.

Źródło: securelist.com

Wszystkie te scenariusze mają różne wymagania dotyczące jakości IoC. Warto wiedzieć, iż wyróżnia się zarówno poziom zaufania, jak i jakość wskaźników. Poniżej kilka przykładów parametrów, które można wykorzystać do badania jakości IoC:

• Konwersja do incydentu – jaka część IoC wywołała rzeczywisty incydent. Stosowane dla scenariuszy wykrywania.
• Wskaźnik FP – odsetek wyników fałszywie dodatnich generowany przez IoC. Działa wykrywająco i zapobiegawczo.
• Wyjątkowość – stosowana dla źródła IoC, mówi zespołowi SOC, jak wyjątkowy jest zestaw dostarczonych IoC w porównaniu z innymi źródłami.
• Starzenie się – czy źródło IoC zapewnia aktualne informacje, czy nie.
• Ilość – liczba IoC dostarczonych z danego źródła.
• Informacje kontekstowe – użyteczność i kompletność kontekstu zapewnianego przez IoC.

Aby zebrać powyższe parametry, zespół SOC powinien dokładnie śledzić każde pochodzenie IoC, scenariusz użycia i jego wynik.

Podsumowanie

Ostatecznie wszystkie zidentyfikowane IoC wykorzystywane są do identyfikacji zagrożonych zasobów sieciowych i blokowania działań atakujących. Ponadto wskaźniki ataku budowane są w oparciu o wskaźniki kompromisu, które służą do prewencyjnego wykrywania osób atakujących. W końcowym etapie reakcji znalezione wskaźniki służą z kolei do sprawdzenia, czy w sieci nie ma już śladów obecności atakujących. Wynikiem każdej zakończonej sprawy wraz z dochodzeniem jest raport, w którym zebrane są wszystkie IoC oraz oparte na nich przesłanki ataku. Zespoły monitorujące powinny dodać te wskaźniki do swoich systemów monitorowania i wykorzystywać je do proaktywnego wykrywania zagrożeń.