-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

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

10 czerwca 2015, 22:01 | Aktualności, Teksty | komentarzy 8

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.

O autorze. Przemysław Skowron, lider White Cat Security. Trener od 2004 (aktualnie prowadzi m.in. szkolenie: „Zaawansowany monitoring i obsługa incydentów bezpieczeństwa informacji” w Securitum). Wcześniej odpowiedzialny m.in. za stworzenie zespołu CSIRT dla Grupy Alior Bank. Wg. Z3S: “główny animator frontu walki ze złośliwym oprogramowaniem atakującym klientów bankowości elektronicznej“. Defensywny bezpiecznik z kilkunastoletnim doświadczeniem.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Artur

    Świetny mateirał Przemku. Same konkrety, praktyka i celne spostrzeżenia.
    Ja dodam jeszcze jedno, to wszystko co robi zespół reakcji na incydent, od środka organizacji, musi mieć właściwy kontekst informacyjny dla samej organizacji (jej pracowników i partnerów) jak również klientów.
    O ile nie realizujesz ambitnego planu obserwowania przestępcy, jego identyfikacji i zpułapkowania (szacun jeśli potrafisz, masz środki i glejt na takie działanie), to brak komunikatu wewnętrznego (spójnego ze szkoleniem) i zewnętrznego uwzględniającego politykę ujawniania takich zdarzeń moze doprowadzić do efektu poczty pantoflowej i wielu operacji na własną rękę różnych domorosłych specjalistów lub zwykłej paniki -a w sytuacji poszukiwania anomalii zachowań, dodatkowe tło tylko utrudni zadanie.

    Odpowiedz
    • Przemysław Skowron

      Zgadza się, dlatego koordynacja jest moim zdaniem tak istotna. W praktyce nie udaje się skutecznie wyszkolić wszystkich pracowników firmy, do tego dochodzi ich rotacja czy po prostu ignorowanie założeń. Tutaj ogromna rola zarządzających (na wyższych, ale i na niższych szczeblach) by zachowali dyscyplinę między sobą i wśród swoich ludzi.

      O tym o czym informować na zew. i w wew., jak informować, nie zamierzałem pisać, bo to bardzo zależy od danego incydentu, od jego etapu/rozwoju, momentu, w którym jesteśmy, czasem dla identycznego incydentu (w skutkach) w dwóch różnych firmach trzeba działać zupełnie inaczej. Temat rzeka na indywidualne konsultacje, nie na kierunkowy artykuł odsłaniający kawałek kuchni.

      Dziękuję bardzo za pozytywny feedback i dyskusję :)

      Odpowiedz
  2. Filip

    W kwestii hipotez oraz weryfikacji faktów pomocna powinna okazać się metoda naukowa, którą można z powodzeniem oficjalnie włączyć w proces koordynacji. Zapewnia ona systematyczność i powtarzalność kroków niezbędnych dla realizacji tego właśnie zadania. Daruję sobie i innym opisywanie na czym ona dokładnie polega. Każdy zainteresowany z pewnością jeśli jeszcze nie kojarzy, to rozezna w czym rzecz na własną rękę.

    Sądzę, że jednym z największych wyzwań w procesie obsługi incydentu jest kwestia zachowania dyscypliny i realizacja wcześniej określonych procedur. Podejrzewam, że tylko nabyte doświadczenie osób zaangażowanych w obsługę, daje im mandat aby _zgłosić_ propozycję odejścia od ustalonej wcześniej ścieżki. Propozycja taka po szybkiej konsultacji na drugą rękę skutkowałaby konkretną akcją. Osiągnięcie równowagi w tym zakresie wydaje się być trudne i może samo w sobie wymaga regulacji (incepcja ™). Dobre pomysły z pewnością powinny być realizowane ale nie można też dopuszczać do sytuacji, w których każdy wcześniej ustalony krok będzie „negocjowany”. Posługując się analogią (może trafną może nie). W kryzysowej sytuacji pilot statku powietrznego powinien wykonywać sekwencję czynności mających na celu zapobieżenie katastrofie. W tym celu godzinami są szkoleni na symulatorach. Czasem zdarza się jednak, że życie wymusza na pilocie zrobienie czegoś niepodręcznikowego. Nie jest to jednak chaotyczne wciskanie przycisków i kręcenie pokrętłami tylko chłodne skalkulowane działanie. Na szczęście podczas obsługi incydentu ma się więcej czasu na reakcję niż sekundy czy też minuty. Jak to mówią sukces i powodzenie sprzyja przygotowanym.

    Bez praktyki nie sądzę, żeby można było osiągnąć zadawalający stopień dojrzałości, a sprawdzanie czy proces obsługi incydentów faktycznie działa na żywym organizmie nie wydaje się być optymalnym podejściem. Dlatego uważam, że inicjatywy takie jak Cyber-EXE są potrzebne, a których wciąż jest za mało. Na szczęście coś wydaje się zmieniać na lepsze.

    Odpowiedz
    • Przemysław Skowron

      Filip, dzięki za komentarz. Cieszę się, że jest z kim podyskutować.

      1) podaj proszę nazwę lub słowa kluczowe za pomocą których ja i inni odnajdą tą metodę naukową, którą masz na myśli.

      2) częściowo podzielam Twoje przemyślenia. Jednostka koordynująca musi mieć kompetencje do tego by decydować co robimy, natomiast nie podchodziłbym tak rygorystycznie do słuchania ludzi, którzy nie mają doświadczenia w obsłudze incydentów. Wielokrotnie przekonałem się, że słuchając głosów od osób bez takiego doświadczenia, za to posiadających kompetencje w danej dziedzinie i otwarty umysł, pozwalało szybciej wyjść z opresji. Nie będę generalizował i oceniał ile organizacji ma szczegółowe procedury obsługi incydentów dla tych ich typów, które wg. nich są dla nich najgroźniejsze, najczęściej pojawiające się czy też najbardziej prawdopodobne. Czy firma posiada procedury pod kątem kampanii APT (nie lubię tego skrótu, ale utarł się i wiele osób go rozumie/kojarzy) lub jego elementów? Jeśli nie to ma coś do opracowania, jeśli nie ma kompetencji lub czasu (!) by zrobić to wew. to potrzebny jest ktoś z zew., kto pomoże to zrobić.

      Jeśli uda się wypracować taką strukturę jednostki koordynującej, że choć jedna osoba może faktycznie tylko koordynować, a nie być zajęta realizacją zadania operacyjnego w ramach obsługi incydentu to ma znacznie więcej czasu niż piloci samolotów.

      3) o tym jak ćwiczyć, budować, rozwijać procedury przeczytasz m.in. w pierwszym artykule tej serii. Cyber-EXE znam od niemal podszewki, inicjatywa słuszna – jeśli ktoś chce poćwiczyć częściej, praktycznie (równolegle z prowadzonym kontrolowanym atakiem) lub teoretycznie (sztabowo) ze scenariuszami ukierunkowanymi na daną firmę/instytucję to zapraszam do kontaktu (kontakt {@} whitecatsec.com).

      A wszystko to zgodnie z myślą: „you don’t need to be great to start but you need to start to be great”

      Odpowiedz
      • Filip

        ad.1)
        Na myśli miałem:
        http://pl.wikipedia.org/wiki/Metoda_naukowa
        http://en.wikipedia.org/wiki/Scientific_method

        ad.3)
        Miałem okazję przeczytać. Dzięki za przypomnienie.

        W tym miejscu głównie chodziło mi o podkreślenie faktu, że widoczne są pewne pozytywne zmiany w zakresie defensywy – działalność cert.pl, wspomniany cyber-exe, doktryna bezp., teraz również i twoje wysiłki, inicjatywa OCA etc. Pomimo faktu, że wszystkie te inicjatywy mają wspólny mianownik pt. defense, to podejrzewam, że żywotne interesy każdej z nich mogą być już ciut różne.

        Wskazane byłoby zobaczyć jak powstaje wspólny front defensywny, który by skupiał wysiłki w skoordynowany sposób zarówno sektora prywatnego jak i publicznego przy zachowaniu możliwie dużego stopnia dostępności i transparentności (niekoniecznie kolejna maszynka do robienia pieniędzy i plująca certyfikatami i normami zgodności). Przykładowo, ciekawe byłyby inicjatywy zachęcające absolwentów do podążania tą ścieżką bezpieczeństwa. Spotkania o podobnej formule jak OWASP-owe (swego czasu miałem nadzieję, że podobną funkcję będzie pełnił np. polski chapter honeynet). Pomysłów do realizacji z pewnością wiele, ale i nie czas i miejsce na poruszanie wszystkich możliwości.

        Apropo samego dostępu do wiedzy i jej wymiany. Osobiście hołduję zasadzie Kerckhoffsa nie tylko w odniesieniu do kryptologii i technicznych rozwiązań. Atmosfera tajemnicy, zamkniętości etc. daje jedynie złudne poczucie (zwiększonego) bezpieczeństwa. Wiedza na temat tego jak się bronić, powinna być według mnie jawna w odróżnieniu do tego jak atakować. Tak obecnie wg mnie nie jest. Obawiam się jednak, że zmierzam w dyskusji do miejsca, gdzie nie będzie się dało osiągnąć kompromisu (podobnie jak z full i coordinated disclosure). Na tym więc może poprzestanę.

        Odpowiedz
        • Przemysław Skowron

          ad 1) niestety nie rozumiem, jak będziesz miał ochotę podać przykład zastosowania to będę zobowiązany.

          ad 3) uczestniczyłem w działaniach OWASP Global i OWASP Poland (jako lider chapteru), starałem się brać udział w życiu ISSA oraz ISACA, oraz wielu innych, nieco bardziej zamkniętych, nieformalnych grupach. Polski HoneyNet Chapter na moją wiedzę był współorganizatorem warsztatów HoneyNet w zeszłym roku (świetne, byłem i polecam) i na tym koniec z działalności, którą widać publicznie, a próba dołączenia do Chapteru zakończyła się niepowodzenia z braku aktywności Chaptera.

          Na dzisiaj osobiście nie widzę możliwości skoordynowanej współpracy ze wspólnymi celami.

          Osobiście używam podejścia, które jest w danej sytuacji (w mojej opinii) najlepsze. Nie mówienie o tym jak się bronimy nie ma za zadanie budowania atmosfery złudnego poczucia bezpieczeństwa – przynajmniej wtedy kiedy ja ją stosuję. Mówiąc publicznie(!) o tym jak się bronimy lub ile wiemy o tym jak jesteśmy atakowani prowadzi do naturalnego podniesienia poziomu atakującego lub wykorzystania słabych punktów, które znajdzie nie dotykając przed atakiem danego celu. Niektórzy mówią i robią to z sensownych, inni z bez sensownych powodów czy też bez powodów. Za to zdecydowanie jestem za wymianą wiedzy/informacji w zaufanych kręgach, które mogą się wzajemnie wspierać.

          Odpowiedz
  3. Nurek

    Na moje oko (i doświadczenia) sformalizowany musi być przede wszystkim proces komunikacji i przepływu informacji (tak mówię o kanałach). Tu wtóruję Autorowi i całkowicie się zgadzam.

    Same działania natomiast, powinny być opisane na wyższym poziomie abstrakcji, w moi odczuciu:
    1. identyfikacja
    2. izolacja
    3. minimalizacja skutków
    4. działania naprawcze
    5. analiza i środki zaradcze.

    Nawet bym nie śmiał stawać w szranki z waszym doświadczeniem, gdyż sromotnie bym się pogrążył. Nie mniej doświadczenia troszkę mam i już troszkę incydentów się obsłużyło.

    Dzięki za artykuł, czekam na kolejną część.

    Odpowiedz
    • Nie jestem przeciwnikiem sformalizowania procesu komunikacji, przepływu informacji. Różne organizacje są na różnych poziomach dojrzałości i świadomości, przez co w różny sposób podchodzą do monitorowania bezpieczeństwa w celu wykrycia podejrzenia incydentu bezpieczeństwa oraz jego obsługi.

      To wszystko sprawia, że jeśli chcemy podejść do danej firmy/instytucji indywidualnie (a tak preferuję, w końcu to nie kuchnia wydająca tylko „frytki belgijskie”, ewentualnie można dobrać inny sos) to proponuję podchodzić adekwatnie do miejsca i czasu w jakim się znajdujemy.

      Jeśli jest czas i miejsca na formalizowanie procesów, a przy okazji te procesy skutecznie wdrożymy to warto to zrobić :) – jeśli i tak ich nie wdrożymy to…

      Jestem czasem postrzegany jako „przeciwnik” SIEM’ów, choć to tylko takie złudzenie ;) Jestem zwolennikiem inwestycji w SIEM’a jeśli właśnie teraz tego potrzebujemy, zanim pójdziemy w SIEM’a zróbmy to co potrzebne by SIEM miał sens większy niż „zgodność” z wymogami/regulacjami by był w organizacji.

      Cieszę się, że artykuł się podoba. Na pewno wkrótce kolejna część :-)

      Odpowiedz

Odpowiedz na Przemysław Skowron