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

W pierwszej części artykułu pt. Incydent bezpieczeństwa – wprowadzenie do obsługi 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.

Kontynuację cyklu poświęconego obsłudze incydentów bezpieczeństwa znajdziesz w artykule Analiza incydentu bezpieczeństwa, czynności naprawcze i raportowanie.

Jeżeli temat obsługi incydentów bezpieczeństwa jest dla was interesujący zachęcamy do subskrypcji naszego newslettera. Otrzymasz powiadomienie gdy na blogu pojawią się kolejne artykuły.

Obserwuj

Obserwuj