piątek, 4 kwietnia 2014

Techniki Analizy Big Data w walce z Advanced Presistent Threats



Big Data Analytics i APT
Zagrożenia malware nie są nowością dla organizacji, które walczą z rożnego rodzaju zagrożeniami poprzez stosowanie programów anty wirusowych, firewalli, IPS, IDS, Web Secure Gateways. Mimo tego w obliczu nowego rodzaju zagrożeń zwanych zaawansowane ciągłe zagrożenia (ang. Advanced Persistent Threat, APTs). W ciągu ostatnich miesięcy zagrożenia APT stają się coraz bardziej powszechne i przedsiębiorstwa powinny ponownie zwrócić uwagę na stosowane technologie zabezpieczeń, oraz odświeżyć podejście do kwestii ochrony sieci i danych. Wykrycie ataku APT jest bardzo trudne ponieważ w przeciwności do innych rodzajów ataków, APT jest to atak typu "low and slow", który przez dłuższy czas pozostaje niezauważalny, nie generując znacznego ruchu sieciowego i nie zwracając na siebie uwagi. Jedną z nowych technologii, która jest w stanie wykryć prawie niewidzialne ataki APTs jest Big Data Security Analytisc (BDSA). Ponizej przedstawie trzy bardzo proste do wdrożenia techniki

Wykrywanie nadużyć konta użytkownika przez insiderów i APTs

Atakujacy zazwyczaj rekrutują insidera czyli osobę która pomoże w rozpoczęciu ataku od wewnątrz. Jest to jedyna metoda aby dotrzec do komputera docelowego, który nie jest podłączony do Internetu. Każdy użytkownik czy tez insider loguje się używając jakiegoś konta, które posiada odpowiedni dostęp. Najprostszą metodą kradzieży informacji, do których nie ma dostępu jest podanie się za kogoś innego, czyli zalogowanie się nie swoim kontem.




Zakładając że w większości przypadków stacja robocza jest powiązana z użytkownikiem, do wykrycia nadużycia konta użytkownika potrzebna jest analiza zdarzenia uwierzytelniania zarejestrowanego w dzienniku zabezpieczeń, oraz dostęp do danych informacyjnych w celu filtracji fałszywych alarmów. Istnieją wyjątki od tej reguły i zostaną one opisanie poniżej, ale generalnie w momencie gdy użytkownik próbuje używać innego konta mamy do czynienia z przypadkiem nadużycia konta. Posiadając dostęp do danych informacyjnych można automatycznie zidentyfikować przypadki, w których używa się multikont i odfiltrować fałszywy alarm.

Pierwszy krok to zebranie wszystkich zdażeń uwierzytelniania, które są logowane w dziennikach zdarzeń. W środowisku Active Directory należy włączyć "Audit Kerberos authentication service" we wszystkich kontrolerach domen i przesłać wszystkie logi bezpieczeństwa do systemu SIEM. Teraz mamy dostęp do wszystkich prób uwierzytelniania w całym środowisku Active Directory. Zdarzenie uwierzytelniania kerberos (TGT - ticket granting ticket) identyfikuje konto oraz adres IP z którego została wykonana próba zalogowania się.

Następnym krokiem jest identyfikacja przypadków w których uwierzytelnianie multikont jest wykonywane z tego samego klienta. W przypadku gdy używamy środowiska DHCP krok ten może wydawać się trudny ponieważ IP klienta zmienia się, zazwyczaj jednak adresy IP pozostają przypisane do komputerów tygodniami i się nie zmieniaja, ponieważ czas dzierżawy adresu IP jest długi, oraz na serwerze DHCP zdefiniowane są duże pule.


Jeżeli potrzebujemy uwzględnić sytuację odmowy przedłużenia dzierżawy, musimy dowiedziec się jaki adres IP klient posiadał w danym czasie. Istnieją dwa źródła takich informacji z których dowiemy się tego: logi serwera DHCP, oraz zdarzenia audytu "Audit Kerberos service ticket operations" zalogowane przez kontroler domeny. Jeżeli chcemy użyć logów DHCP, to musimy znać adres IP który znajdziemy w zdarzeniu uwierzytelniania Kerberos, nastepnie znaleźć ostatnie zdarzenie dzierżawy bądź odnowienia adresu IP w serwerze DHCP, który poprzedza zdarzenie uwierzytelniania Kerberos. Nastepnie można powiązać nazwę użytkownika ze zdarzenia uwierzytelniania Kerberos z nazwa komputera w logu DHCP.

Alternatywą do logów DHCP jest użycie zdarzenia audytu kontrolera domeny "Audit Kerberos service ticket operations". W mechanizmie uwierzytelniania usługi Kerberos po wstępnym uwierzytelnieniu do kontrolera domeny (otrzymaniu TGT), otrzymujemy bilet sesji, który będzie używany podczas dostępu do usług systemowych, dla którego Kontroler domeny loguje zdarzenie ID 4769.
W zdarzeniu tym pole service name odpowiada nazwe konta komputera w Active Directory. Dla każdego pomyślnego logowania można bardzo łatwo powiązać nazwę konta użytkownika z nazwa konta komputera, gdzie nazwa użytkownika zgadza się w dwóch zdarzeniach i pole service name nie jest krbtgt lub nazwa kontrolera domeny. Pole service name takiego zdarzenia odpowiada nazwie komputera użytkownika.

Trzeba jednak zwrócić uwagę, że należy ignorować zdarzenia, w których pole service name jest nazwą kontrolera domeny, ponieważ kiedy logujemy się do Active Directory, Windows automatycznie otrzymuje bilet sesji do kontrolera domeny i jest pobierana lista zasad (Group Policy). W tym celu możemy stworzyć statyczną listę kontrolerów domeny i wykorzystać ją do stworzenia logiki korelacji, ale jeżeli system SIEM posiada możliwości BDSA to powinien być w stanie wykorzystać rożne informacje a nie tylko te z dziennika zdarzeń. W tym przypadku chcemy żeby system SIEM wykorzystał zaktualizowaną listę kontrolerów domeny regularnie uzyskiwaną z Active Directory poprzez zapytania LDAP.

Dodatkowo używanie zdarzeń Kerberos service ticket do zamiany adresu IP na nazwę komputera nastepuje wyłącznie po uzyskaniu TGT. Jeżeli użytkownik próbuje zgadnąć hasło do innego konta, uwierzytelnianie nie powiedzie się i bilet sesji który identyfikuje nazwę komputera nie jest wykonany. W tym przypadku logi kontrolera domeny posiadają wyłącznie nazwę użytkownika i adres IP komputera. Dlatego jeżeli nie posiadamy środowiska DHCP ze stabilnymi adresami IP i nie możemy polegać na logach DHCP, może trzeba pominąć błędy uwierzytelniania w scenariuszu z nadużyciem konta. Obojetnie czy używamy zdarzeń DHCP czy Kerberos service ticket posiadamy listę prób uwierzytelniania składającą się z nazwy użytkownika i nazwy komputera. Teraz wystarczy wyszukać przypadki wielu nazw użytkownika dla tego samego komputera.
Istnieją wyjątki dla których takie zachowanie jest w pełni uzasadnione:
  • Komputery na których pracują zmienni pracownicy.
  • Komputery w tzw "hotelling" środowisku.
  • Komputery pracowników IT na których logują się zwykłym użytkownikiem i uprzywilejowanym kontem.
  • Przypadek helpdesku kiedy to osoba z pomocy technicznej loguje się wlanym kontem na komputer użytkownika w celu rozwiązania problemu.
W takich sytuacjach systemy SIEM które maja możliwości BDSA mogą wykorzystać dane informacyjne do inteligentnej analizy zdarzenia. Na przykład komputery w trzech pierwszych przypadkach mogą być zgromadzone w kontenerze, który jest zidentyfikowany jako komputery, które maja wielu użytkowników i kont. Czwarty scenariusz może korzystać z danych systemu Help Desk.

Identyfikowanie eksfiltracji danych

Głównym celem większości ataków APT jest kradzież informacji, które w jakiś sposób muszą zostać wyslane do serwera C&C (command-and-control). Stosowanie wielopoziomowych struktur ochrony pozwoli zapobiec lub chociaż wykryć APT w pierwszych fazach ataku poprzez analizę wchodzącego i wychodzącego ruchu sieciowego.

Kolejny scenariusz BDSA oparty jest na dwóch założeniach, które sprawdzają się w większości przypadków użytkowników w organizacjach. Po pierwsze załóżmy, że APT nie wytwarza znaczącego ruchu sieciowego podczas wysyłania informacji do serwera C&C. Po drugie załóżmy, że większość użytkowników korzystających z Internetu przegląda strony internetowe, a co za tym idzie ściąga więcej informacji niż wysyła, co jest typowym trendem dla użytkowników webowych.

W celu wykrycia eksfiltracji (skrytej ewakuacji) danych, trzeba zwrócić uwagę na przypadki, w których normalny stosunek bazowy ściągniętych bitów na godzinę w stosunku do wysłanych nagle się zmieni czyli wystąpi anomalia. Potrzebne do tego będą logi z firewalla bądź tez serwera proxy, dzięki którym system SIEM będzie w stanie oszacować ile bitów na godzinę jest wysłanych i odebranych z Internetu przez użytkownika. Niestety większość firewalli nie jest w stanie powiązać ruchu sieciowego do użytkownika, jedynie do adresu IP. Dlatego korzystając z pierwszego scenariusza jesteśmy w stanie powiązać użytkownika do adresu IP poprzez wykorzystanie zdarzeń Kerberosa lub logów z serwera DHCP. Serwery proxy wymagają uwierzytelniania użytkownika a tym samym ułatwiają analizy wzorców ruchu Internetowego w oparciu o użytkownika.

Posiadamy kilka możliwości przy ustalaniu odniesienia dla ruchu wychodzącego i przychodzącego. Może ono być statyczne, bądź dynamiczne aktualizowane w czasie. Zdefiniowane dla wszystkich użytkowników lub oddzielnie dla każdego użytkownika, czy tez grup użytkowników. Zwyczajny próg bitów na godzinę, który jest bardziej podatny na fałszywe alarmy wyzwalane podczas gdy użytkownik intensywnie korzysta z Internetu, np pod czas przerwy na lunch. Można także obliczyć stosunek danych wychodzących do przychodzących, dzięki czemu momenty gdy użytkownik intensywnie korzysta z Internetu zostaną odfiltrowane, ale w dalszym ciągu będzie można rozpoznać momenty kiedy użytkownik przesyła znacznie więcej danych niż zwykle. Oczywiście wszystko zależy od tego jakie posiadamy dane, czy można je wysłać do systemu SIEM, oraz jakie ma on możliwości współpracy z BDSA.

W przypadku gdy system SIEM wykryje sytuacje, gdy ruch wychodzący przekroczy próg bitów na godzinę, lub wartość stosunku danych wychodzących do przychodzących, musi on wykorzystać wszystkie posiadane źródła informacji do filtrowania fałszywego alarmu. Z czasem można zidentyfikować rodzaje użytkowników, których rodzaj pracy wymaga do wykonywania większej ilości wysalania danych i stworzenie dla nich osobnych ratingów. Korzystając z dobrodziejstw Big Data systemy SIEM mogą wykorzystać informacje o tożsamości użytkownika i ewentualnie filtrować alerty dla tytułów zawodowych lub działów, które maja zidentyfikowany większy rating wysalania danych. Oczywiście tworzenie takich logik zawsze otwiera możliwość przesyłania danych w sposób niespostrzeżony ale będzie to o wiele trudniejsze, niż bez jakichkolwiek struktur obronnych.

Powiadomienie przy uruchamianiu nowego procesu

Podczas ataku APT nastepuje uruchomienie złośliwego kodu w naszym środowisku. Podstawowym elementem obrony przed taka sytuacją są wdrożone systemy IDS i IPS do wykrywania i zapobiegania uruchamiania złośliwego kodu w naszej sieci. BDSA idzie o krok dalej, pozwala nam na zastosowanie dodatkowych detekcyjnych mechanizmów kontrolnych w celu zwiększenia bezpieczeństwa infrastruktury IT.

Z bardzo dużą łatwością można skonfigurować systemy operacyjne do logowania zdarzenia tworzenia procesów. Na przykład w Windows wystarczy włączyć opcje "Audit process creation", która będzie logowala zdarzenia ID 4688. Zdarzenie to loguje pełną nazwę uruchamianego pliku, nazwę użytkownika na ktorym jest uruchamiany proces i numer ID poprzedniego procesu który go uruchomił.
Nastepnie musimy przesłać takie informacje ze wszystkich komputerów w sieci wliczając serwery, stacje robocze i laptopy, które są okazyjnie podłączone do sieci. Instalując agenta na każdej końcówce nie jest obecnie praktyczne, w zamian możemy użyć funkcji Windows event forwarding która pozwoli skonfigurować system do wysyłania określonych zdarzeń do dziennika logów innego systemu. Funkcja ta może zostać zoptymalizowana w celu oszczędzania przepustowości, oraz skonfigurowana do wysyłania zdarzeń przez Internet korzystając z SSL/TLS. Wykorzystując Group Policy możemy łatwo skonfigurować wszystkie końcówki do wysyłania zdarzeń uruchomienia procesów do jednego lub kilku centralnych systemów, które monitoruje system SIEM.

W celu zidentyfikowania nowego programu organizacje posiadają dynamicznie aktualizowane listy zatwierdzonego oprogramowania składające się z nazwy programu, oraz ścieżki do jego uruchomienia. W celu zbudowania takiej listy możemy skanować system plików, ale lepiej jest posiadać rozwiązanie SIEM, które po prostu zbuduje listę podczas czasu obserwacji na podstawie własnej analizy. Podczas tego czasu każde zdarzenie uruchomienia nowego procesu zostanie dodane do listy jeżeli nazwa programu i ścieżka są nowe. Po zakończeniu procesu obserwacji, każdy nowy uruchomiony program spowoduje uruchomienie alertu.

W przypadku aktualizowania systemu bądź oprogramowania istnieje ryzyko wystąpienia fałszywych alertów ponieważ nowe programy są uruchamiane po raz pierwszy. W takim przypadku warto wdrożyć logikę w korelacji do reguł automatycznego dodawania nowych programów, która pozwoli okreslic czy nowy program został uruchomiony w całym środowisku. Bez wdrożenia logiki która zlikwiduje alerty związane z aktualizacjami, najpierw zauważymy bardzo dużo alertów w momencie uruchamiania aktualizacji które z czasem znikną. Warto zwrócić uwagę na ustalenie i udostępnienie harmonogramu aktualizacji dla pracowników SOC (Security Operating Center), którzy będą przygotowani na wystąpienie fałszywych alarmów. Dodatkowym atutem wystąpienia fałszywych alarmów związanych z aktualizacjami jest potwierdzenie, że wdrożone mechanizmy działają tak jak powinny.

Rozwiązania BDSA pomagają przedsiębiorstwom stawić czoła największym wyzwaniom w zakresie bezpieczeństwa poprzez wykorzystanie wielkich zbiorów danych i łączenie wielu źródeł zdarzeń i informacji w oparciu o inteligentna analizę danych, która ma pomóc w zidentyfikowaniu i obrony przed atakami APT.

Brak komentarzy:

Prześlij komentarz