Fakty i Mity Defensywnych aspektów Bezpieczeństwa Informacji: część II

Kontynuując serię artykułów (I część znajdziesz tutaj) o defensywie zapraszam do kolejnej części. Tym razem skupię się na efektywnej Obsłudze Incydentów Bezpieczeństwa, o tym co naprawdę jest ważne i bez czego moim zdaniem nie ma mowy o skutecznym działaniu. Pewnie słyszeliście o tym jak ważna jest komunikacja – ja pokażę, że bez sprawnej koordynacji komunikacja nie ma tak dużego znaczenia. Drugim zagadnieniem jest dość często przemilczany temat aktualnego schematu sieci, w której doszło do incydentu – schematu, a właściwe grafu sieci, możesz nie mieć dzisiaj, ale w dniu Obsługi Incydentu bezpieczeństwa może okazać się bezcenny. Dlaczego? – Zapraszam do artykułu!

Zanim przejdziemy do omówienia konkretnych sytuacji, rozterek które możemy spotkać, chcę mieć pewność, że tak samo rozumiemy kilka pojęć.

• Zdarzenia – informacje o aktywności (lub jej braku) systemu, usługi, aplikacji, użytkownika, etc. W monitoringu najczęściej wykorzystywane są zdarzenia mówiące o nadużyciach, choć w kolejnych etapach ich wyjaśniania oraz na kolejnych etapach dojrzałości procesu identyfikacji incydentów bezpieczeństwa, okaże się, że interesują nas również inne zdarzenia (głównie pozwalające osiągnąć rozliczalność).
• Alarmy – to pojedyncze Zdarzenia, grupy Zdarzeń wygenerowane w danym okresie i wspólnej cesze/cechach (np. przez ich agregację lub korelację).
• Podejrzenie incydentu – domyślna klasyfikacja Alarmów (pojedynczych, ich agregacji czy korelacji – UWAGA: zauważcie, że to drugi raz kiedy stosujemy takie operacje, tym razem na Alarmach, wcześniej miały już miejsce na poziomie Zdarzeń), które nie przeszły jeszcze weryfikacji i wstępnej oceny czy mamy do czynienia z Incydentem Bezpieczeństwa czy nie.
• Incydent Bezpieczeństwa – co najmniej wstępnie zweryfikowane Podejrzenie incydentu, które nie okazało się Fałszywym Pozytywem.

Przy okazji poznaliście ogólny cykl życia Zdarzenia->Alarmy->Podejrzenia Incydentów->Incydenty Bezpieczeństwa. W tym i w kolejnych artykułach będę używał tych zwrotów.

Płynnie przejdźmy do konkretów.

1) Komunikacja vs. Koordynacja

Jednym z podstawowych elementów sprawnej obsług Incydentów Bezpieczeństwa jest efektywna komunikacja. Jest ona bardzo związana z innym aspektem, bez którego nawet wypracowane metody komunikacji nie pozwolą na sprawną obsługę incydentów – koordynacja.

W momencie wystąpienia (podejrzenia) incydentu bezpieczeństwa, głównie takiego, który się wcześniej nie wydarzył (UWAGA: dla osoby, która zauważy/zgłosi/padnie ofiarą incydentu „każdy raz” może być jak pierwszy), pojawia się stres, który może prowadzić do chaosu. W takich warunkach łatwo zapomnieć o wypracowanych ścieżkach komunikacji, ważniejsze jest by było jasne do kogo informacja o incydencie ma trafić. Nie będziemy przecież ganić kogoś o to, że zgłosił to w sposób niezgodny z procedurami, najistotniejszy jest dla nas parametr „czas wykrycia” i drugi „czas reakcji„. Z tych powodów istotne jest by w organizacji została wyznaczona jednostka (dedykowana lub jako jeden z obowiązków o wysokim priorytecie), która zajmie się koordynacją przypadków incydentów i każdy w firmie będzie o tym wiedział, nawet jeśli zapomni procedurę o tym jak ma to zrobić – na pewno znajdzie adres e-mail, nr. telefonu czy po prostu podejdzie zgłosić symptomy (podejrzenia) Incydentu Bezpieczeństwa.

Jednostka koordynująca musi posiadać w firmie wyłączność na koordynację, natomiast jednocześnie uprawnienia by mogła korzystać ze wsparcia innych jednostek. Istotne jest by inne jednostki nie miały wątpliwości kto koordynuje i z kim bezwzględnie należy konsultować działania by nie doszło do pracy równoległej (w tym wzajemnego przeszkadzania), zagłodzenia zasobów w jednostce wspierającej („nie możemy Wam pomóc bo rozwiązujemy awarię” – a chodzi o incydent z którym przychodzi jednostka koordynująca), czy też zostanie to przez inne jednostki niż koordynującą sklasyfikowane – co może doprowadzić do katastrofy. Wyłączność na klasyfikację incydentu również musi posiadać jednostka koordynująca, która może wspierać się innymi jednostkami czy też włączyć w proces klasyfikacji inne ciała jak sztab antykryzysowe.

Takie podejście ma przeciwdziałać takim reakcjom w innych jednostkach jak: „nic się nie stało„, „ja nic nie widzę„, „to nie moja sprawa„, jedno z najgorszych: „poradzimy sobie sami„.

Koordynacja ma zapewnić adekwatną do potrzeb (wg. klasyfikacji incydentu) reakcję i efektywne wsparcie tych obszarów firmy, które są niezbędne do szybkiego opanowania sytuacji.

Chcąc dać Wam kolejną wędkę, opowiem jak często radzę sobie z koordynacją. Do koordynacji incydentów od lat korzystam z tzw. „białej tablicy” – moja własna nazwa robocza. Jaką będzie ona mieć postać dopasujcie do swoich potrzeb, może to być flipchart, fizyczna biała tablica rodem ze szkoły, system ticketowy czy cokolwiek innego z czym wygodnie się Wam pracuje. Jeśli Wasz zespół, w którym koordynujecie obsługę incydentu oraz zespoły wspierające są rozproszone geograficznie to prawdopodobnie lepszą wersją będzie „biała tablica” w postaci aplikacji, którą będzie można wyświetlić na ekranie, dodać w niej załącznik i uzyskać dostęp do niej zewsząd  – pamiętajcie, że nie zawsze jesteście przy biurku w pracy kiedy dowiadujecie się o incydencie :) UWAGA : z tym „zewsząd” zachowajcie umiar, „biała tablica” zawiera wrażliwe dane i musi być chroniona.

Na „Białej tablicy” zapisujemy zadania niezbędne do obsługi incydentu, które mają:

• Status: TODO, W trakcie, Zrobione
• Priorytet (pozwalający zarządzać kolejnością wykonywanych zadań – rzadko będą zasoby ludzkie by realizować wszystkie równolegle)
• Przypisaną osobę/jednostkę realizującą, innymi słowy mówiąc: właściciela odpowiedzialnego za dociągnięcie zadania do końca
• Opis zadania (dobrze wskazać co chcemy sprawdzić, nie zawsze będzie ekspertami w danej dziedzinie i nie próbujmy na siłę go udawać)
• Wnioski, w tym wynik zadania oraz sposób realizacji zadania (jeśli to możliwe i nie zajmuje dużo czasu) – np. użyty „jedno linijkowiec” w linii poleceń, nazwa skryptu, generalnie coś co pozwoli w razie czego szybko się wrócić do zadania, zmodyfikować parametry, nie zawsze za pierwszym razem znajdziemy to czego szukamy, ale również zapewnić wiarygodność przez powtarzalność realizacji zadań.

Taka tablica pozwala mi na bieżąco oceniać co jest do zrobienia, co robimy, gdzie jesteśmy i co już zrobione – świetne do podsumowań, raportowania, wniosków o kolejne zasoby ludzkie lub wręcz na odwrót, zmniejszanie zespołu, który pracuje nad obsługą danego incydentu by mogli wrócić do swoich naturalnych/pierwotnych zadań.

Jeśli dla danego typu incydentu przygotowaliście wcześniej listę standardowych zadań (kroków obsługi) to jest to idealne miejsce by na początku wrzucić je na „białą tablicę„, a wraz z obsługą uzupełniać o inne zadania, które wyjdą w boju lub wykreślać te, które okazują się zbędne. UWAGA: polecam wykreślanie (czyt. skreślanie) zamiast usuwania byście mogli wyciągnąć później wnioski i w oparciu o praktykę wprowadzić kolejne elementy pragmatyki do procedur obsługi incydentów – po co utrzymywać w nich „martwe” kroki i dlaczego nie uzupełniać ich tym co w praktyce i tak potrzebne?

2) Włamanie – „shit happens”, co teraz?

Zdarza się i tak, że przegramy bitwę i dojdzie do skutecznego włamania. Poniżej garść tego co prawdopodobnie będziecie potrzebować w przypadkach skutecznego włamania do serwera dostępnego z sieci Internet, kradzieży danych z kluczowej bazy danych czy skompromitowania komputera pracownika wysokiego szczebla.

Wiedząc jaka maszyna została skompromitowana (serwer lub komputer pracownika) czy też jakie dane zostały wykradzione potrzebujemy znaleźć odpowiedzi na m.in. następujące pytania:

• jaką drogę pokonał napastnik by osiągnąć cel?
• jakie słabości wykorzystał?
• czy zostały osiągnięte inne cele?

Aby próbować odpowiedzieć na te pytania potrzebujecie grafu infrastruktury z uwzględnieniem miejsc, w których doszło do incydentu (będą to oczywiste serwery, komputer pracownika jak i wszystkie miejsca, w których występują kopie wykradzionych danych). Graf, nie lista – lista nie pokaże ścieżek i zależności. Jeśli nie od razu to w kolejnym etapie przyda się nałożenie na graf polityk sieciowych (z firewalla i innych urządzeń, które odpowiadają za filtrowanie czy segmentację w sieci) – bez tego powstanie bardzo dużo hipotez i obsługa incydentu będzie coraz mniej efektywna. Jeśli nie ma jak szybko nałożyć na graf polityk można wspierać się danymi z flow’ów, ruchu sieciowego (pcap), logami z rozwiązań realizujących filtrowanie/segmentację sieci.

UWAGA: nie ufajcie informacjom, że host X komunikuje się z hostem Y tylko po porcie 1521/TCP bez sprawdzenia jak może się komunikować naprawdę. Z wielu różnych powodów firewalle dopuszczają znacznie więcej niż się wydawało (czyt. jest w dokumentacji, której i tak szybko nie znajdziecie w trakcie obsługi incydentu), że powinny, bo tak zostały skonfigurowane – w Obsłudze Incydentów liczą się fakty, a nie hipotezy – hipotezy są pomocne w wyobrażaniu co się mogło stać, ale finalnie musimy hipotezę udowodnić, obalić lub z niej zrezygnować jeśli mamy na do tego racjonalne powody.

Jeśli nie posiadasz takiego grafu to w ramach ćwiczenia spróbuj go stworzyć przy najbliższej okazji, choćby metodami pośrednimi, o których wspomniałem, a na pewno wymyślisz jeszcze inne.

Podsumowanie

Zamiast klasycznego podsumowania, na koniec kilka słów od Sun Tzu:

„Jeśli znasz siebie i swego wroga, przetrwasz pomyślnie sto bitew. Jeśli nie poznasz swego wroga, lecz poznasz siebie, jedną bitwę wygrasz, a drugą przegrasz. Jeśli nie znasz ni siebie, ni wroga, każda potyczka będzie dla Ciebie zagrożeniem.”

Do kolejnej części! – w komentarzach lub mailach bezpośrednio do mnie piszcie, które aspekty monitorowania/obsługi incydentów czy budowy aktywnej obrony są dla Was najciekawsze. Pamiętajcie, że pokazuję „kuchnię” dla Was.