(dzięki Sergeyowi G. Bresterowi za pomysł na tytuł )
Szanowni Państwo, celem tego artykułu jest podzielenie się doświadczeniami z całorocznej pracy testowej nowej klasy rozwiązań IDS opartych na technologiach Deception.
Aby zachować spójność logiczną prezentacji materiału, uważam za konieczne zacząć od założeń. Zatem problem:
- Ataki ukierunkowane są najniebezpieczniejszym rodzajem ataków, mimo że ich udział w ogólnej liczbie zagrożeń jest niewielki.
- Nie wynaleziono jeszcze gwarantowanego skutecznego środka ochrony obwodu (ani zestawu takich środków).
- Z reguły ataki ukierunkowane przebiegają w kilku etapach. Pokonanie obwodu to tylko jeden z początkowych etapów, który (można we mnie rzucać kamieniami) nie wyrządza większych szkód „ofiarze”, chyba że jest to oczywiście atak typu DEoS (Destruction of service) (programy szyfrujące itp.) .). Prawdziwy „ból” zaczyna się później, kiedy zdobyte aktywa zaczynają być wykorzystywane do obracania i rozwijania ataku „w głębi”, a my tego nie zauważyliśmy.
- Ponieważ zaczynamy ponosić realne straty, gdy napastnicy w końcu dotrą do celów ataku (serwery aplikacji, DBMS, hurtownie danych, repozytoria, elementy infrastruktury krytycznej), logiczne jest, że jednym z zadań służby bezpieczeństwa informacji jest przerwanie ataków zanim to smutne wydarzenie. Ale żeby coś przerwać, trzeba się najpierw o tym dowiedzieć. A im szybciej, tym lepiej.
- W związku z tym, aby skutecznie zarządzać ryzykiem (tj. zmniejszyć szkody spowodowane atakami ukierunkowanymi), niezbędne jest posiadanie narzędzi, które zapewnią minimalny TTD (czas wykrycia – czas od momentu włamania do momentu wykrycia ataku). W zależności od branży i regionu okres ten wynosi średnio 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 rozwiązań typu sandbox lub białych list. Chłopaki z „ciemnej strony” są tutaj wciąż o krok przed nami.
- UEBA (systemy profilowania zachowań i identyfikowania odchyleń) – w teorii może być bardzo skuteczne. Jednak moim zdaniem jest to kwestia odległej przyszłości. W praktyce jest to nadal bardzo kosztowne, zawodne i wymaga bardzo dojrzałej i stabilnej infrastruktury informatycznej i bezpieczeństwa informacji, która posiada już wszystkie narzędzia, które będą generować dane do analizy behawioralnej.
- SIEM jest dobrym narzędziem do badań, jednak nie jest w stanie w porę dostrzec i pokazać czegoś nowego i oryginalnego, gdyż zasady korelacji są takie same jak w podpisach.
- W rezultacie istnieje zapotrzebowanie na narzędzie, które:
- z powodzeniem pracował w warunkach już zagrożonego obwodu,
- wykrywał udane ataki w czasie zbliżonym do rzeczywistego, niezależnie od zastosowanych narzędzi i podatności,
- nie zależało od podpisów/reguł/skryptów/polityk/profili i innych statycznych rzeczy,
- nie wymagał do analizy dużej ilości danych i ich źródeł,
- pozwoliłoby na zdefiniowanie ataków nie jako pewnego rodzaju punktacji ryzyka w wyniku działania „najlepszej na świecie, opatentowanej, a zatem zamkniętej matematyki”, co wymaga dodatkowych badań, ale praktycznie jako zdarzenia binarnego – „Tak, jesteśmy atakowani” lub „Nie, wszystko w porządku”,
- był uniwersalny, efektywnie skalowalny i możliwy do wdrożenia w dowolnym środowisku heterogenicznym, niezależnie od zastosowanej topologii sieci fizycznej i logicznej.
O rolę takiego narzędzia rywalizują obecnie tzw. rozwiązania w zakresie oszustwa. Czyli rozwiązania oparte na starej, dobrej koncepcji Honeypotów, ale o zupełnie innym poziomie realizacji. Temat ten zdecydowanie zyskuje obecnie na popularności.
Zgodnie z wynikami Rozwiązania oszukańcze znajdują się w TOP 3 strategii i narzędzi, które warto stosować.
Według raportu Oszustwo to jeden z głównych kierunków rozwoju rozwiązań IDS Intrusion Detection Systems).
Cały odcinek tego ostatniego , dedykowany SCADA, opiera się na danych od jednego z liderów tego rynku, TrapX Security (Izrael), którego rozwiązanie działa w naszym obszarze testowym od roku.
TrapX Deception Grid umożliwia centralne ustalanie kosztów i obsługę masowo rozproszonych systemów IDS, bez zwiększania obciążenia licencyjnego i wymagań dotyczących zasobów sprzętowych. Tak naprawdę TrapX jest konstruktorem pozwalającym stworzyć z elementów istniejącej infrastruktury IT jeden duży mechanizm wykrywania ataków na skalę całego przedsiębiorstwa, swego rodzaju „alarm” sieci rozproszonej.
Struktura rozwiązania
W naszym laboratorium stale badamy i testujemy różne nowości z zakresu bezpieczeństwa IT. Obecnie wdrożonych jest tu około 50 różnych serwerów wirtualnych, w tym komponenty TrapX Deception Grid.
Zatem od góry do dołu:
- TSOC (konsola operacyjna bezpieczeństwa TrapX) to mózg systemu. Jest to centralna konsola zarządzająca, za pośrednictwem której przeprowadzana jest konfiguracja, wdrażanie rozwiązania i wszelkie codzienne operacje. Ponieważ jest to usługa internetowa, można ją wdrożyć w dowolnym miejscu – na obwodzie, w chmurze lub u dostawcy MSSP.
- TrapX Appliance (TSA) to wirtualny serwer, do którego podłączamy się za pomocą portu trunk, te podsieci, które chcemy objąć monitoringiem. Ponadto wszystkie nasze czujniki sieciowe faktycznie „żyją” tutaj.
W naszym laboratorium wdrożono jeden moduł TSA (mwsapp1), ale w rzeczywistości może być ich wiele. Może to być konieczne w dużych sieciach, w których nie ma łączności L2 pomiędzy segmentami (typowy przykład to „Holding i spółki zależne” lub „Centrala i oddziały banku”) lub jeśli sieć ma izolowane segmenty, na przykład zautomatyzowane systemy kontroli procesów. W każdym takim oddziale/segmencie możesz wdrożyć własny TSA i podłączyć go do jednego TSOC, gdzie wszystkie informacje będą centralnie przetwarzane. Architektura ta pozwala na budowę rozproszonych systemów monitorowania bez konieczności radykalnej restrukturyzacji sieci lub zakłócania dotychczasowej segmentacji.
Możemy także przesłać kopię ruchu wychodzącego do TSA za pośrednictwem TAP/SPAN. Jeśli wykryjemy połączenia ze znanymi botnetami, serwerami dowodzenia i kontroli lub sesjami TOR, wynik otrzymamy również w konsoli. Odpowiada za to Network Intelligence Sensor (NIS). W naszym środowisku ta funkcjonalność jest zaimplementowana na firewallu, więc tutaj jej nie wykorzystaliśmy.
- Application Traps (Full OS) – tradycyjne Honeypoty bazujące na serwerach Windows. Nie potrzeba ich wiele, gdyż głównym zadaniem tych serwerów jest świadczenie usług informatycznych kolejnej warstwie czujników lub wykrywanie ataków na aplikacje biznesowe, które mogą być wdrażane w środowisku Windows. Mamy jeden taki serwer zainstalowany w naszym laboratorium (FOS01)
- Emulowane pułapki to główny element rozwiązania, który pozwala nam za pomocą jednej maszyny wirtualnej stworzyć bardzo gęste „pole minowe” dla atakujących i nasycić sieć korporacyjną, wszystkie jej vlany, naszymi czujnikami. Osoba atakująca widzi taki czujnik, czyli host fantomowy, jako prawdziwy komputer PC lub serwer z systemem Windows, serwer Linux lub inne urządzenie, które zdecydujemy się mu pokazać.
Dla dobra biznesu i z ciekawości wdrożyliśmy „po parze każdego stworzenia” – komputery PC i serwery z systemem Windows w różnych wersjach, serwery Linux, bankomat z wbudowanym systemem Windows, SWIFT Web Access, drukarkę sieciową, Cisco przełącznik, kamerę IP Axis, MacBook, urządzenie PLC, a nawet inteligentną żarówkę. W sumie jest 13 gospodarzy. Ogólnie rzecz biorąc, sprzedawca zaleca rozmieszczenie takich czujników w ilości co najmniej 10% liczby rzeczywistych hostów. Górny pasek to dostępna przestrzeń adresowa.Bardzo ważną kwestią jest to, że każdy taki host nie jest pełnoprawną maszyną wirtualną wymagającą zasobów i licencji. Jest to przynęta, emulacja, jeden proces na TSA, który ma zestaw parametrów i adres IP. Dlatego za pomocą choćby jednego TSA możemy nasycić sieć setkami takich hostów fantomowych, które sprawdzą się jako czujniki w systemie alarmowym. To właśnie ta technologia umożliwia ekonomiczne skalowanie koncepcji Honeypot w każdym dużym rozproszonym przedsiębiorstwie.
Z punktu widzenia atakującego hosty te są atrakcyjne, ponieważ zawierają luki w zabezpieczeniach i wydają się stosunkowo łatwym celem. Osoba atakująca widzi usługi na tych hostach i może z nimi wchodzić w interakcję oraz atakować je przy użyciu standardowych narzędzi i protokołów (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus itp.). Nie ma jednak możliwości wykorzystania tych hostów do opracowania ataku lub uruchomienia własnego kodu.
- Połączenie tych dwóch technologii (FullOS i emulowanych pułapek) pozwala nam osiągnąć wysokie statystyczne prawdopodobieństwo, że atakujący prędzej czy później natknie się na jakiś element naszej sieci sygnalizacyjnej. Ale jak możemy się upewnić, że prawdopodobieństwo to jest bliskie 100%?
Do bitwy wchodzą tak zwane żetony oszustwa. Dzięki nim możemy włączyć do naszego rozproszonego systemu IDS wszystkie istniejące komputery i serwery przedsiębiorstwa. Tokeny umieszczane są na rzeczywistych komputerach użytkowników. Ważne jest, aby zrozumieć, że tokeny nie są agentami zużywającymi zasoby i mogącymi powodować konflikty. Tokeny to pasywne elementy informacyjne, swego rodzaju „bułka tarta” dla strony atakującej, która wprowadza ją w pułapkę. Na przykład zmapowane dyski sieciowe, zakładki do fałszywych administratorów sieci w przeglądarce i zapisane dla nich hasła, zapisane sesje ssh/rdp/winscp, nasze pułapki z komentarzami w plikach hostów, hasła zapisane w pamięci, dane uwierzytelniające nieistniejących użytkowników, biuro pliki, otwarcie, które uruchomi system i wiele więcej. Tym samym umieszczamy atakującego w zniekształconym środowisku, nasyconym wektorami ataku, które tak naprawdę nie stanowią dla nas zagrożenia, a wręcz przeciwnie. I nie ma możliwości ustalenia, gdzie informacja jest prawdziwa, a gdzie fałszywa. Dzięki temu nie tylko zapewniamy szybkie wykrycie ataku, ale także znacząco spowalniamy jego postęp.
Przykład tworzenia pułapki sieciowej i ustawiania tokenów. Przyjazny interfejs i brak ręcznej edycji konfiguracji, skryptów itp.
W naszym środowisku skonfigurowaliśmy i umieściliśmy szereg takich tokenów na FOS01 z systemem Windows Server 2012R2 oraz komputerze testowym z systemem Windows 7. Na tych maszynach działa protokół RDP i okresowo „zawieszamy” je w strefie DMZ, gdzie znajduje się wiele naszych czujników (emulowane pułapki) są również wyświetlane. Mamy zatem do czynienia z ciągłym strumieniem incydentów, że tak powiem, naturalnie.
Oto kilka szybkich statystyk za ten rok:
56 208 – zarejestrowano zdarzenia,
2 – wykryto hosty będące źródłem ataku.
Interaktywna, klikalna mapa ataku
Jednocześnie rozwiązanie nie generuje jakiegoś megadziennika ani źródła zdarzeń, których zrozumienie zajmuje dużo czasu. Zamiast tego samo rozwiązanie klasyfikuje zdarzenia według ich typów i pozwala zespołowi ds. bezpieczeństwa informacji skupić się przede wszystkim na tych najbardziej niebezpiecznych – gdy atakujący próbuje wywołać sesje kontrolne (interakcja) lub gdy w naszym ruchu pojawiają się ładunki binarne (infekcja).
Wszelkie informacje o zdarzeniach są czytelne i przedstawione moim zdaniem w formie zrozumiałej nawet dla użytkownika posiadającego podstawową wiedzę z zakresu bezpieczeństwa informacji.
Większość odnotowanych incydentów to próby przeskanowania naszych hostów lub pojedynczych połączeń.
Lub próby brutalnego wymuszenia haseł dla protokołu RDP
Ale zdarzały się też ciekawsze przypadki, zwłaszcza gdy atakującym „udało się” odgadnąć hasło do protokołu RDP i uzyskać dostęp do sieci lokalnej.
Osoba atakująca próbuje wykonać kod przy użyciu psexec.
Atakujący znalazł zapisaną sesję, co wprowadziło go w pułapkę w postaci serwera Linux. Zaraz po podłączeniu jednym, wcześniej przygotowanym zestawem poleceń próbował zniszczyć wszystkie pliki dziennika i odpowiadające im zmienne systemowe.
Osoba atakująca próbuje wykonać zastrzyk SQL w Honeypocie imitującym SWIFT Web Access.
Oprócz takich „naturalnych” ataków przeprowadziliśmy także szereg własnych testów. Jednym z najbardziej odkrywczych jest testowanie czasu wykrywania robaka sieciowego w sieci. W tym celu wykorzystaliśmy narzędzie firmy GuardiCore o nazwie . Jest to robak sieciowy, który może przejąć kontrolę nad systemami Windows i Linux, ale bez żadnego „ładunku”.
Wdrożyliśmy lokalne centrum dowodzenia, uruchomiliśmy pierwszą instancję robaka na jednej z maszyn i otrzymaliśmy pierwszy alert w konsoli TrapX w niecałe półtorej minuty. TTD 90 sekund w porównaniu do średnio 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 CarbonBlack umożliwi automatyczne odłączenie zainfekowanych komputerów od sieci.
Integracja z piaskownicami umożliwia automatyczne przesyłanie plików objętych atakiem do analizy.
Integracja McAfee
Rozwiązanie posiada także własny, wbudowany system korelacji zdarzeń.
Jednak nie byliśmy zadowoleni z jego możliwości, więc zintegrowaliśmy go z HP ArcSight.
Wbudowany system zgłoszeń pomaga całemu światu uporać się z wykrytymi zagrożeniami.
Ponieważ rozwiązanie zostało opracowane „od początku” na potrzeby agencji rządowych i dużego segmentu korporacyjnego, w naturalny sposób implementuje model dostępu oparty na rolach, integrację z AD, rozbudowany system raportów i wyzwalaczy (alertów o zdarzeniach), orkiestrację dla duże struktury holdingowe lub dostawcy usług MSSP.
Zamiast wznowienia
Jeśli istnieje taki system monitoringu, który w przenośni zakrywa nasze plecy, to wraz z kompromisem obwodu wszystko dopiero się zaczyna. Najważniejsze, że istnieje realna możliwość poradzenia sobie z incydentami związanymi z bezpieczeństwem informacji, a nie radzenia sobie z ich konsekwencjami.
Źródło: www.habr.com