IOC (indicator of compromise)

Obsługa incydentu bezpieczeństwa – śledztwo oraz IOC

W pierwszej części artykułu pt. Obsługa incydentu bezpieczeństwa – przygotowanie na incydent omówiliśmy kwestie związane z identyfikowaniem incydentów, reakcją na incydent (IR), budowaniem zespołu do obsługi incydentów i czynnościami wstępnymi w ramach śledztwa. W tej części skupimy się na samym przebiegu śledztwa oraz t.zw. IOC (Indicator Of Compromise).

Pięciostopniowy proces prowadzenia śledztwa

Śledztwa w sprawie incydentów komputerowych prowadzone są zazwyczaj wg metodyki OSCAR (O – obtain information, S – strategize, C – collect evidence, A – analyse, R – report), czyli skupiają się kolejno na następujących czynnościach:

  • Zebraniu informacji wstępnych
  • Przyjęciu strategii działania
  • Zebraniu informacji szczegółowych
  • Analizie zebranego materiału
  • Raportowaniu

Wstępne tropy

Zgromadzenie wstępnego materiału ma krytyczne znaczenie dla powodzenia całej operacji ponieważ bez danych wstępnych niemożliwe jest podjęcie decyzji o koniecznych do przeprowadzenia kolejnych krokach. W początkowej fazie śledztwo powinno zatem skupiać się na badaniu tropów, których trzy podstawowe cechy to:

  • Istotność — trop dotyczy aktualnie badanego incydentu. Błędem jest kwalifikowanie wszystkiego, co wydaje się podejrzane, jako rzeczy istotnej we właśnie prowadzonym śledztwie.
  • Szczegółowość — trop ma cechy określające potencjalny kierunek śledztwa, np. datę i godzinę zdarzenia, adres IP, nazwę systemu ub użytkownika itp.
  • Przydatność — trop zawiera informacje, które można wykorzystać, a organizacja posiada środki potrzebne do pójścia tym tropem.

IOC (Indicator of Compromise) – co to jest?

„Indicator of Compromise” nie ma chyba sensownego odpowiednika w języku polskim. „Wskaźnik kompromitacji” jest niezbyt udaną kalką językową, chociaż „kompromitacja” jako naruszenie bezpieczeństwa przyjęła się już w branży. Na potrzeby artykułu, aby nie nadużywać zapożyczeń, będę się posługiwał terminem „wskaźniki zagrożenia”. Tworzenie wskaźników zagrożenia to proces polegający na dokumentowaniu cech charakterystycznych i artefaktów związanych z incydentem. Mogą to być takie elementy jak:

  • nazwy katalogów roboczych
  • nazwy plików lub ich hashe
  • ścieżki sieciowe
  • zdarzenia logowania
  • adresy IP i nazwy domenowe
  • URL-e
  • próbki ruchu sieciowego
  • klucze rejestru windows
  • certyfikaty

Prawidłowo zidentyfikowane i udokumentowane wskaźniki zagrożenia ułatwiają wyśledzenie kolejnych hostów, systemów i użytkowników mogących brać udział w incydencie.

Ważnym czynnikiem, który należy wziąć pod uwagę jest wybór sposobu reprezentacji wskaźników zagrożenia. Zaleca się używanie uniwersalnych standardów, które umożliwią zastosowanie wskaźników w innych regionach organizacji lub poza jej granicami. Sieciowe wskaźniki zagrożenia są najczęściej reprezentowane za pomocą reguł open source’owego systemu IDS – Snort, lub jego nowszego odpowiednika – Suricata. Wskaźniki zagrożeń na poziomie hosta mogą być natomiast opisywane za pomocą otwartego standardu Open IOC stosowanego m.in. w narzędziach dostarczanych przez firmę FireEye (opisane one zostaną w dalszej części naszego cyklu).

Wdrażanie wskaźników zagrożenia

Opisywanie wskaźników zagrożenia za pomocą formatu Open IOC umożliwia zespołowi IR wyszukiwanie niepożądanych elementów w sposób automatyczny (np. za pomocą skanerów, skryptów lub technologii WMI (Windows Management Instrumentation). Skuteczność śledztwa zależy zatem od możliwości szukania wskaźników zagrożenia w całej organizacji i automatycznego ich zgłaszania (wdrażania).
Jeśli chodzi o wskaźniki sieciowe, większość rozwiązań obsługuje reguły Snort i na ich podstawie jest w stanie rozpoznać zagrożenie. W przypadku wskaźników na poziomie hosta firma FireEye udostępnia darmowe narzędzie Redline , za pomocą którego można szukać reguł OpenIOC w systemach (opisem tego narzędzia zajmiemy się również w dalszej części cyklu).

Identyfikacja zagrożonych systemów

Wdrożenie wskaźników zagrożenia wygeneruje zdarzenia trafień w reguły IOC. Przed podjęciem jakichkolwiek działań należy jednak dobrze przyjrzeć się otrzymanym informacjom i upewnić, że nie jest to fałszywy alarm (t.zw. false positive).  Zaleca się postępowanie zgodnie z poniższymi regułami:

  • Weryfikacja — zbadaj wstępnie informacje o znalezionych elementach i sprawdź, czy są wiarygodne.
  • Kategoryzacja — przyporządkuj zidentyfikowany system do jednej lub większej liczby kategorii ułatwiających prowadzenie śledztwa w uporządkowany sposób. Pomocne są kategorie, które wskazują na rodzaj odkrytych działań intruza, np. „backdoor”, „dostęp przy użyciu prawidłowych danych poświadczających”, „SQL injection”, „wyciek danych”
  • Szeregowanie względem ważności — zidentyfikowanemu systemowi przypisz względny numer w szeregu w odniesieniu do ważności odkrycia. Często stosowanym rozwiązaniem jest szeregowanie na podstawie czynników biznesowych, takich jak główny użytkownik albo typ przetwarzanych informacji. Jeżeli jednak początkowe szczegóły zidentyfikowanego zagrożenia w systemie zgadzają się z odkryciami z innych systemów, dalsze badanie tego systemu może nie dostarczyć żadnych nowych tropów i system ten można oznaczyć jako mniej ważny. Uzasadnione będzie natomiast nadanie wyższego priorytetu w sytuacji, gdy szczegóły sugerują coś nowego.

Jeżeli temat obsługi incydentów bezpieczeństwa jest dla was interesujący zachęcamy do subskrypcji naszego newslettera, już wkrótce opublikujemy kolejną część cyklu poświęconą zbieraniu i dokumentowaniu dowodów oraz analizie danych.


Zostaw e-mail aby otrzymać powiadomienia o nowościach oraz dostęp do wszystkich bonusowych materiałów przygotowanych wyłącznie dla subskrybentów.

Leave a Reply

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.