(podziękowania za pomysł nagłówka dla Sergey G. Brester) )
Koleżanki i koledzy, celem tego artykułu jest chęć podzielenia się doświadczeniami rocznego testowania nowej klasy rozwiązań IDS opartych na technologiach Deception.
Aby zachować logiczną spójność przedstawianego materiału, uważam za stosowne zacząć od przesłanek. Zatem problematyka:
- Ataki skierowane – to najbardziej niebezpieczny rodzaj ataków, mimo że ich udział w ogólnej liczbie zagrożeń jest niewielki.
- Jak dotąd nie wymyślono żadnego gwarantującego skutecznego środka ochrony perymetru (ani kompleksu takich środków).
- Zazwyczaj ataki skierowane przebiegają w kilku etapach. Pokonanie perymetru to tylko jeden z początkowych etapów, który (możecie mnie obrzucić kamieniami) nie niesie dużego szkody dla «ofiary», chyba że mówimy o atakach DEoS (Destruction of service) (szyfrowanie itp.). Naprawdę „bolesne” zaczyna się dopiero później, kiedy przejęte aktywa zaczynają być wykorzystywane do pivotingu i rozwijania ataku „w głąb”, a my tego nie zauważamy.
- Skoro zaczynamy ponosić prawdziwe straty wtedy, gdy przestępcy faktycznie docierają do celów ataku (serwery aplikacji, DBMS, magazyny danych, repozytoria, elementy krytycznej infrastruktury), logiczne jest, że jednym z zadań służby bezpieczeństwa informacji jest przerwanie ataków przed tym smutnym wydarzeniem. Jednak aby coś przerwać, najpierw trzeba się o tym dowiedzieć. Im wcześniej – tym lepiej.
- W związku z tym, dla skutecznego zarządzania ryzykiem (tj. zmniejszenia szkód z powodu skierowanych ataków) kluczowe znaczenie ma posiadanie narzędzi, które zapewnią minimalny TTD (czas wykrywania – czas od momentu intruzji do momentu wykrycia ataku). W zależności od branży i regionu, ten okres w średnim wynosi 99 dni w USA, 106 dni w regionie EMEA, 172 dni w regionie APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
- Co oferuje rynek?
- „Piaskownice”. Kolejna kontrola zapobiegawcza, która jest daleka od ideału. Istnieje wiele skutecznych technik wykrywania i omijania piaskownic lub rozwiązań whitelistingowych. Chłopaki z „ciemnej strony” są tutaj na razie krok przed nami.
- UEBA (systemy profilowania zachowań i wykrywania anomalii) teoretycznie może być bardzo skuteczne. Jednak moim zdaniem to coś, co znajduje się w odległej przyszłości. W praktyce jest to na razie bardzo drogie, niepewne i wymaga bardzo dojrzałej i stabilnej infrastruktury IT i bezpieczeństwa, w której znajdują się już wszystkie narzędzia generujące dane do analizy zachowań.
- SIEM to dobry instrument do prowadzenia dochodzeń, ale nie ma zdolności do zauważania i zgłaszania czegoś nowego, oryginalnego na czas, ponieważ reguły korelacji to po prostu te same sygnatury.
- W związku z tym pojawiła się potrzeba takiego narzędzia, które:
- skutecznie działałoby w warunkach już skompromitowanego perymetru,
- wykrywałoby udane ataki w zbliżonym do rzeczywistego czasie, niezależnie od używanego narzędzia i podatności, które są wykorzystywane,
- nie byłoby uzależnione od sygnatur/reguł/scenariuszy/polityk/profili i innych statycznych elementów,
- nie wymagałoby dużych zbiorów danych i ich źródeł do analizy,
- umożliwiało określanie ataków nie jako pewnego ryzyka w wyniku działania 'najlepszej na świecie, opatentowanej i dlatego zamkniętej matematyki', wymagającej dodatkowego dochodzenia, a praktycznie jako binarne zdarzenie – 'Tak, jesteśmy atakowani' lub 'Nie, wszystko w porządku',
- było uniwersalne, efektywnie skalowalne i realnie wdrażane w każdej heterogenicznej środowisku, niezależnie od używanej fizycznej i logicznej topologii sieci.
Na rolę takiego narzędzia obecnie pretendują tzw. rozwiązania decepcyjne. To znaczy rozwiązania, które opierają się na starej dobrej koncepcji honeypotów, ale z zupełnie innym poziomem realizacji. Temat ten obecnie zdecydowanie zyskuje na znaczeniu.
Z wynikami Rozwiązania decepcyjne znajdują się w pierwszej trójce strategii i narzędzi, które są rekomendowane do zastosowania.
Według raportu Deception jest jednym z kluczowych kierunków rozwoju systemów wykrywania intruzów (IDS).
Cała sekcja najnowszego , poświęcona SCADA, oparta jest na danych jednego z liderów tego rynku, TrapX Security (Izrael), którego rozwiązanie już od roku działa w naszej strefie testowej.
TrapX Deception Grid umożliwia budowanie i eksploatację rozproszonych IDS w sposób scentralizowany, bez zwiększania obciążenia licencyjnego i wymagań dotyczących zasobów sprzętowych. W rzeczywistości TrapX jest konstrukcją, która pozwala stworzyć z elementów istniejącej infrastruktury IT jeden duży mechanizm detekcji ataków na poziomie całego przedsiębiorstwa, rodzaj rozproszonej sieciowej "alarmówki".
Struktura Rozwiązania
W naszym laboratorium nieustannie badamy i testujemy różne nowinki w dziedzinie bezpieczeństwa IT. Obecnie jest tu uruchomionych około 50 różnych serwerów wirtualnych, w tym komponenty TrapX Deception Grid.
Zatem, od góry do dołu:
- TSOC (TrapX Security Operation Console) – mózg systemu. To centralna konsola zarządzająca, za pomocą której odbywa się konfiguracja, wdrożenie rozwiązania i codzienna praca. Ponieważ jest to serwis webowy, może być uruchamiany gdziekolwiek – w perymetrze, w chmurze lub u dostawcy MSSP.
- TrapX Appliance (TSA) – wirtualny serwer, do którego za pomocą portu trunk łączymy te podsieci, które chcemy objąć monitoringiem. Tutaj w rzeczywistości "żyją" wszystkie nasze sieciowe sensory.
W naszym laboratorium uruchomiony jest jeden TSA (mwsapp1), ale w rzeczywistości może ich być wiele. Może to być konieczne w dużych sieciach, gdzie między segmentami nie ma łączności L2 (typowy przykład – "Holding i spółki córki" lub "Główna siedziba banku i jego oddziały") lub jeśli w sieci są izolowane segmenty, na przykład APT. W każdym takim oddziale/segmencie można uruchomić swój TSA i podłączyć go do centralnego TSOC, na którym wszystkie informacje będą przetwarzane w sposób scentralizowany. Taka architektura pozwala budować rozproszone systemy monitorowania bez potrzeby radykalnej przebudowy sieci lub naruszenia istniejącej segmentacji.
Ponadto, na TSA możemy skierować kopię wychodzącego ruchu przez TAP/SPAN. W przypadku wykrycia połączeń z znanymi botnetami, serwerami dowodzenia, sesjami TOR również otrzymamy wyniki w konsoli. Odpowiada za to Network Intelligence Sensor (NIS). W naszym środowisku ta funkcjonalność jest realizowana na zaporze sieciowej, dlatego tutaj jej nie użyliśmy.
- Pułapki aplikacyjne (pełny OS) – tradycyjne honeypoty oparte na serwerach Windows. Nie wymaga się ich wielu, ponieważ głównym celem tych serwerów jest dostarczenie usług IT dla następnego poziomu czujników lub wykrywanie ataków na aplikacje biznesowe, które mogą być uruchamiane w środowisku Windows. W naszej laboratorium zainstalowaliśmy jeden taki serwer (FOS01)
- Emulowane pułapki – główny komponent rozwiązania, który pozwala nam przy pomocy jednej wirtualnej maszyny stworzyć gęste "minowe" pole dla atakujących i nasycić sieć przedsiębiorstwa, wszystkie jego vlan-y, naszymi czujnikami. Atakujący widzi taki czujnik, lub fantomowy host, jako prawdziwy komputer PC z Windows lub serwer, serwer Linux lub inne urządzenie, które decydujemy się pokazać.
Dla dobra sprawy i z ciekawości, wdrożyliśmy „każdemu stworzeniu po parze” — komputery PC z Windows i serwery różnych wersji, serwery Linux, bankomat z Windows embedded, SWIFT Web Access, sieciową drukarkę, przełącznik Cisco, kamerę IP Axis, MacBooka, urządzenie PLC i nawet inteligentną żarówkę. W sumie – 13 hostów. Ogólnie, dostawca zaleca wdrożenie takich czujników w ilości minimum 10% od liczby rzeczywistych hostów. Górna granica to dostępna przestrzeń adresowa.Bardzo ważnym aspektem jest to, że każdy taki host – to nie pełnoprawna maszyna wirtualna, która wymaga zasobów i licencji. To „oszustwo”, emulacja, jeden proces na TSA, który ma zestaw parametrów i adres IP. Dlatego przy pomocy nawet jednego TSA możemy nasycić sieć setkami takich fantomowych hostów, które będą działać jak czujniki w systemie alarmowym. To właśnie ta technologia pozwala efektywnie ekonomicznie skalować koncepcję „honeypotów” na poziomie każdej dużej, rozproszonej firmy.
Te hosty z punktu widzenia atakującego są atrakcyjne, ponieważ zawierają luki i wydają się stosunkowo łatwymi celami. Atakujący widzi usługi na tych hostach i może z nimi interakcjonować, atakować je, używając standardowych narzędzi i protokołów (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus itp.). Jednak wykorzystanie tych hostów do rozwijania ataku i uruchamiania własnego kodu jest niemożliwe.
- Połączenie tych dwóch technologii (FullOS i emulowane pułapki) pozwala osiągnąć wysokie prawdopodobieństwo, że atakujący prędzej czy później napotka jakiś element naszej sieci sygnalizacyjnej. Jak jednak sprawić, aby to prawdopodobieństwo było bliskie 100%?
W grę wchodzą tzw. tokeny (Deception tokens). Dzięki nim możemy włączyć do naszego rozproszonego IDS wszystkie dostępne komputery i serwery w przedsiębiorstwie. Tokeny są umieszczane na rzeczywistych komputerach użytkowników. Ważne jest, aby zrozumieć, że tokeny to nie agenci, którzy konsumują zasoby i mogą powodować konflikty. Tokeny to pasywne elementy informacyjne, swoiste 'okruszki chleba' dla atakującej strony, które prowadzą ją w pułapkę. Na przykład, podłączone dyski sieciowe, zakładki do fałszywych paneli administracyjnych w przeglądarce i zapisane hasła do nich, zapisane sesje ssh/rdp/winscp, nasze pułapki z komentarzami w plikach hosts, hasła przechowywane w pamięci, dane uwierzytelniające nieistniejących użytkowników, pliki biurowe, których otwarcie spowoduje uruchomienie systemu, i wiele innych. W ten sposób umieszczamy atakującego w zniekształconym środowisku, nasyconym takimi wektorami ataków, które w rzeczywistości nie stanowią dla nas zagrożenia, a wręcz przeciwnie. I nie ma on możliwości ustalenia, która informacja jest prawdziwa, a która fałszywa. Tak więc nie tylko zapewniamy szybkie wykrycie ataku, ale także znacznie spowalniamy jego przebieg.
Przykład tworzenia sieciowej pułapki i konfigurowania tokenów. Przyjazny interfejs i żadnej ręcznej edycji konfiguracji, skryptów itp.
W naszym środowisku skonfigurowaliśmy i rozmieszcziliśmy szereg takich tokenów na FOS01 działającym pod Windows Server 2012R2 oraz na testowym komputerze z systemem Windows 7. Na tych maszynach działa RDP, a my okresowo 'wywieszamy' je w DMZ, gdzie umieszczone są również nasze sensory (emulowane pułapki). W ten sposób uzyskujemy stały strumień incydentów, można powiedzieć, w sposób naturalny.
Oto krótka statystyka za rok:
56 208 – incydentów zarejestrowano,
2 912 – hostów źródłowych ataków wykryto.
Interaktywna, klikalna mapa ataków
Rozwiązanie to nie generuje żadnych gigantycznych dzienników ani strumieni wydarzeń, które wymagałyby długotrwałej analizy. Zamiast tego, samo klasyfikuje wydarzenia według typów, co pozwala zespołowi zabezpieczeń skupić się przede wszystkim na tych najbardziej niebezpiecznych – gdy atakujący próbuje nawiązać sesje kontrolne (interaction) lub gdy w naszym ruchu pojawiają się złośliwe payloady (infection).
Wszystkie informacje o zdarzeniach są czytelne i moim zdaniem przedstawiane w przystępny sposób nawet dla użytkownika z podstawową wiedzą w zakresie zabezpieczeń.
Większość zarejestrowanych incydentów to próby skanowania naszych hostów lub pojedynczych połączeń.
Lub próby łamania haseł dla RDP.
Jednak zdarzały się również bardziej interesujące przypadki, zwłaszcza gdy przestępcom udało się dobrać hasło do RDP i uzyskać dostęp do sieci lokalnej.
Napastnik próbuje wykonać kod za pomocą psexec.
Przestępca znalazł zapisane sesje, które zaprowadziły go w pułapkę w postaci serwera Linux. Zaraz po połączeniu, zestawem wcześniej przygotowanych poleceń, próbował zniszczyć wszystkie pliki dzienników i odpowiednie zmienne systemowe.
Atakujący próbuje przeprowadzić SQL injection na pułapce imituje SWIFT Web Access.
Oprócz takich „naturalnych” ataków przeprowadziliśmy również szereg własnych testów. Jednym z najciekawszych jest testowanie czasu wykrywania robaka sieciowego w sieci. Do tego użyliśmy narzędzia od GuardiCore, które nazywa się . Jest to robak sieciowy, który potrafi zarażać Windows i Linux, ale bez jakiegoś „przydatnego” ładunku.
Uruchomiliśmy lokalne centrum dowodzenia, na jednej z maszyn uruchomiliśmy pierwszy egzemplarz robaka i otrzymaliśmy pierwsze powiadomienie w konsoli TrapX w mniej niż półtorej minuty. TTD 90 sekund w porównaniu do średnich 106 dni...
Dzięki możliwości integracji z innymi klasami rozwiązań możemy przejść od szybkiego wykrywania zagrożeń do automatycznego reagowania na nie.
Na przykład integracja z systemami NAC (Network Access Control) lub z CarbonBlack pozwoli automatycznie odłączać skompromitowane komputery od sieci.
Integracja z piaskownicami pozwala automatycznie przekazywać do analizy pliki uczestniczące w ataku.
Integracja z McAfee
W rozwiązaniu znajduje się wbudowany system korelacji zdarzeń.
Jednakże nie były dla nas wystarczające jego możliwości, dlatego zintegrowaliśmy go z HP ArcSight.
Zintegrowany system ticketowy pomaga radzić sobie z odkrytymi zagrożeniami 'wspólnymi siłami'.
Ponieważ rozwiązanie od samego początku było rozwijane z myślą o potrzebach instytucji rządowych i dużego sektora korporacyjnego, oczywiście, wdrożono tam model dostępu oparty na rolach, integrację z AD, rozwinięty system raportów i triggerów (powiadomień zdarzeniowych), orkiestrację dla dużych struktur holdingowych lub dostawców MSSP.
Zamiast podsumowania
Jeśli istnieje podobny system monitorowania, który, mówiąc obrazowo, chroni naszą „tylną stronę”, to kompromitacja perymetru to dopiero początek. Najważniejsze jest to, że istnieje realna możliwość walki z incydentami bezpieczeństwa informacji, a nie zajmowanie się usuwaniem ich skutków.
Źródło: habr.com
