Bezpieczeństwo pracy zdalnej
Incident Response, czyli jak szybko wykryć i unieszkodliwić zagrożenie
(17.06.2020)

— Sławomir Pyrek —
Tematem przewodnim dzisiejszego spotkania jest wykrywanie i obsługa incydentów. Przez ostatnie kilka miesięcy jesteśmy świadkami dynamicznych zmian w funkcjonowaniu środowiska IT, wywołanych pandemią koronawirusa. Zmiany te dotyczą wielu organizacji. Pierwsza z takich zmian, która nastąpiła, to w sposób niespotykany na taką skalę, zaczęliśmy pracować zdalnie, co rodzi pewne określone skutki, jeżeli chodzi o cyberbezpieczeństwo. Po pierwsze większa część komunikacji, która odbywała się do tej pory wewnętrznie, w ramach organizacji, odbywa się teraz przez Internet, co w oczywisty sposób zwiększa ryzyko ujawnienia danych wrażliwych. Dodatkowo nie wszystkie wewnętrzne systemy zabezpieczeń IT, monitorują działania użytkowników. W sytuacji, kiedy jesteśmy wewnątrz organizacji, wchodząc do Internetu, przechodzimy cały szereg systemów zabezpieczających, które monitorują nasze działania i niwelują szkodliwą działalność przestępczą. W sytuacji, kiedy pracujemy zdalnie, jesteśmy zdecydowanie bardziej narażeni na szkodliwą aktywność. Następnym problemem, który może się pojawić z uwagi na pracę zdalną, są problemy z aktualizacją czy to systemów czy aplikacji, których używamy czy nawet oprogramowania antywirusowego, z racji tego, że nie wszystkie systemy monitorujące i zarządzające są rozciągnięte i mają możliwość monitorowania domowych stacji roboczych. Skutkuje to zwiększonym ryzykiem przełamania zabezpieczeń. Również często występują problemy z dostępem do aplikacji, co przekłada się na korzystanie z jakichś szkodliwych aplikacji, witryn, konwerterów rodzajów plików, co może skutkować ujawnieniem wrażliwych danych.

04:35
By praca zdalna była możliwa, organizacje musiały w szybkim tempie dokonać rozbudowy systemu zdalnego dostępu. Oczywiście było to związane z zakupami i z wdrożeniami tych systemów w bardzo szybkim tempie, co skutkuje możliwością popełnienia błędów w konfiguracji pod presją czasu. W czasie takiego procesu może dojść do penetracji naszych wewnętrznych systemów, z uwagi właśnie na takie błędy. Następnym zjawiskiem, które obserwujemy, jest bardzo szerokie używanie narzędzi zdalnej komunikacji. Narzędzia mają swoje podatności. Oczywiście producenci dokładają zapewne wszelkich starań, żeby te podatności w miarę możliwości na bieżąco usuwać, ale tak czy inaczej skutkuje to też możliwością utraty danych czy też przełamania systemów bezpieczeństwa. Następnym elementem, który jest związany z uruchomieniem pracy zdalnej, jest szybka rekonfiguracja dostępu do zasobów wewnętrznych firmy. Inaczej ten dostęp był zorganizowany w sytuacji, kiedy pracownicy byli bezpośrednio w budynku firmy. Także zmiany w obiegu wrażliwych dokumentów – tutaj również jest ryzyko popełnienia błędów czy to konfiguracyjnych czy ryzyko popełnienia błędów w procesach obiegu dokumentów, co może skutkować wyciekiem wrażliwych danych. I oczywiście wymuszone modyfikacje użytkowanych systemów. Pewnie nie mieliśmy na to czasu, by w 100% przyjrzeć się szczegółowo jak zmiany czy modyfikacje użytkowanych systemów, odniosły się do poziomów podatności czy do poziomu błędów konfiguracyjnych do tych systemów. Zauważamy również wykorzystanie pandemii koronawirusa jako pewnego rodzaju przynęty przy działaniach przestępczych, np. kampanie phishingowe przekierowujące na strony serwujące malware. Te kampanie często są z Covidem w tle. Na początku pandemii, przy brakach w zaopatrzeniu w maseczki, żele czy środki ochrony, pojawiało się bardzo dużo takich kampanii, które oferowały zakup brakujących towarów. W tej chwili spotykamy się z kolei z bardzo dużą ilością ofert dotyczących pomocy finansowej czy pomocy w znalezieniu pracy. Kampanie te są bardzo intensywne i mogą spowodować zainfekowanie komputerów, z których korzystamy w domach.

08:05
Oczywiście szerzej używamy aplikacji chmurowych, co również rodzi pewne skutki chociażby w postaci większego prawdopodobieństwa ujawnienia danych dostępowych, czy też propagacji szkodliwego oprogramowania przez systemy chmurowe. Skutkiem tych wszystkich działań związanych z zakupem, ze zmianami w środowiskach IT, jest również zwiększone obciążenie personelu – zarówno personelu IT jak i personelu odpowiedzialnego za bezpieczeństwo.

— Robert Dąbroś —
Świetnie to wypunktowałeś. Zmieniła się bardzo infrastruktura, sposób dostępu i wszystko co wymieniłeś. Czy jakby w samych zagrożeniach jest coś co nas zaskoczyło, co wymusza na nas jakieś inne podejście?

— Sławomir Pyrek —
Nie, bardziej powiedziałbym, że portfolio zagrożeń jest takie samo, tzn. pewne techniki, sposoby ataku są takie same, natomiast poprzez większą ekspozycję wrażliwych elementów, jakim jest stacja robocza i przede wszystkim wyjście z takiego bastionu, którym do tej pory były nasze firmy, czyli wyjście poza ten obszar murów obronnych w postaci systemów zabezpieczeń, jesteśmy bardziej narażeni na te działania. Oczywiście temat Covidu gdzieś tam się przewija w metodach ataku, natomiast portfolio zagrożeń jest niezmienne, w dalszym ciągu grożą nam wszystkie zagrożenia, które były do tej pory i dalej są one intensywnie rozwijane przez przestępców.

— Robert Dąbroś —
Czyli dzień jak co dzień, musimy być dalej przygotowani na najgorsze i właściwie reagować.

— Sławomir Pyrek —
Właściwie reagować, tylko w trochę zmienionych warunkach. Mamy trochę więcej pracy czy też więcej do przemyślenia i do przekonfigurowania. Co jest nam potrzebne do tego, żeby zapobiegać negatywnym skutkom zmian w IT? Tutaj też się nic nie zmieniło tak naprawdę w porównaniu do czasu sprzed koronawirusa. W dalszym ciągu najistotniejszym elementem są ludzie. Oczywiście do tego potrzebujemy jakichś rozwiązań technologicznych, które nas wspomogą i pewnych ram organizacyjnych na cały proces detekcji zagrożeń, usuwania skutków tych zagrożeń i zapobieganiu im w przyszłości. Po stronie użytkowników należy zadbać o to by zwiększać ich świadomość odnośnie zagrożeń, uczulać ich na kampanie phishingowe, na pewne działania typu korzystanie z nieznanych witryn, odbieranie maili od nieznanych osób – to skutkuje dużo mniejszą ilością pracy. Każde zwiększenie wiedzy użytkownika końcowego, przekłada się wykładniczo na mniejszą ilość pracy dla służb odpowiedzialnych za cyberbezpieczeństwo. Z drugiej strony potrzebujemy odpowiednio wykwalifikowanego personelu, który będzie odpowiedzialny za detekcję i reakcje na zagrożenia. Personel ten musi być oczywiście wyposażony w skuteczne narzędzia. Jeżeli chodzi o reakcję na zagrożenia, to dobrze, jeżeli ta reakcja jest usystematyzowana w formie procesu, odpowiednich procedur. Dobrze było by, gdyby te procedury były powtarzalne. Musimy być przygotowani na najgorsze scenariusze, w związku z tym nie będzie czasu, żeby się zastanawiać co w danym momencie należy zrobić. Dobrze jest, jeżeli będziemy mieli pewien określony sposób postępowania, tak żeby każda osoba, która jest odpowiedzialna chociażby za obsługę incydentu, wiedziała w danej chwili co powinna zrobić. Oczywiście bardzo istotne jest również wsparcie partnera. Nasze zasoby są najczęściej ograniczone – nie mamy nieograniczonych zasobów osobowych zajmujących się cyberbezpieczeństwem, ani osób, które są wyposażone w każdą dostępną wiedzę, więc dobrze jest mieć zaufanego partnera, który w krytycznych sytuacjach może pomóc i wspomóc proces usuwania skutków, wyjaśniania sposobu ataku i zapewnić przywrócenie systemu do stanu sprzed incydentu.

13:42
Najistotniejszym elementem w detekcji i reakcji na zagrożenia jest czas. Typowy scenariusz ataku, według klasycznego przepisu, to jest na początek zdobycie przyczółka w atakowanej organizacji i wstępna infiltracja sieci. Później następuje etap, który nazywamy umacnianiem pozycji, który polega najczęściej na tym, że jest ściągane z odpowiednich centrów zarządzania przestępców, dodatkowe oprogramowanie. Następnie te oprogramowanie zaczyna skanować, czy też próbkować naszą sieć wewnętrzną, w celu znalezienia słabych punktów i rozprzestrzenienia się w sieci. Potem następuje etap identyfikacji zasobów, które są celem ataku i następnie kradzież danych lub ich zmiana. W takim klasycznym przykładzie, wtedy, kiedy nie dbamy o bezpieczeństwo, ten czas potrzebny do wykrycia zagrożenia, jest bardzo długi. W tej chwili przyjmuje się średnio (w zależności od źródła), że od 146 do 240 dni potrzebują firmy na to, żeby znaleźć atakującego u siebie w sieci wewnętrznej. Oczywiście w sytuacji, kiedy organizacja nie dba o bezpieczeństwo, ten czas może się wydłużyć do ponad 300 dni. W tym momencie najczęściej taka informacja jest dostarczana przez podmioty zewnętrzne w stosunku do organizacji, które informują ją o tym, że została spenetrowana. To już jest najbardziej tragiczny scenariusz. Istotnym celem naszego działania jest by skrócić czas zarówno potrzebny do wykrycia zagrożenia, jak i jego unieszkodliwienia, w takim stopniu by zabezpieczyć nas przed kradzieżą czy niedozwolonymi operacjami na naszych danych, czyli generalnie wykrycie ataku w momencie, w którym następuje bądź infiltracja sieci, bądź komunikacja z centrami zarządzania przestępców, czy też na etapie rozprzestrzenia się w sieci. Z uwagi na to, że nie jesteśmy w stanie przy pomocy tylko i wyłącznie siły własnego umysłu poradzić sobie z tym problemem, potrzebujemy narzędzi.

16:55
Po pierwsze, jeżeli chodzi o monitoring i reakcje na zagrożenia, musimy w miarę kompleksowo monitorować zachowania naszych użytkowników, urządzeń końcowych (laptopów, telefonów komórkowych), systemów, które serwują aplikacje i monitować ruch sieciowy. Dobrze, jeżeli monitorowanie jest zrobione na bardzo szczegółowym poziomie technicznym, z uwagi na to, że pewne elementy ataków są zauważalne dopiero na bardzo głębokim poziomie technicznym. W związku z tym, jeżeli monitorujemy sieć, dobrze żebyśmy monitorowali ją do poziomu warstwy siódmej, żebyśmy mieli tam dekodery protokołów sieciowych. Dobrze, jeżeli te dekodery pracują bez względu na numer portu, na który jest sterowany ruch. Powinniśmy mieć możliwość obserwacji obiektów przesyłanych przez sieć, również dekodujących przesyłane obiekty, żebyśmy wiedzieli czy dany plik jest prezentacją w PowerPoincie czy jest tak naprawdę tylko plikiem, który ma rozszerzenie powerpointowe, a tak naprawdę w środku jest np. zaszyty jakiś skrypt lub plik wykonywalny. Jeżeli chodzi o stacje robocze, to dobrze, jeżeli mamy możliwość monitorowania operacji na procesach, rejestrach, systemach plików, ponieważ są tam dosyć dobrze widziane efekty czy też sposoby działania przestępców. Oczywiście system musi być wyposażony, czy też mieć możliwość podłączenia do systemów typu Threat Intelligence, które serwują nam informacje na temat sposobów detekcji szkodliwych operacji i taktyk stosowanych przez atakujących. Jeżeli chodzi o reakcje na podejrzane zachowania, to dobrze, jeżeli taki system posiada rozbudowane narzędzia, które pozwalają nam wykryć znaczącą ilość szkodliwych działań. Najczęściej takie systemy wyposażane są w bazy danych IOC, czyli indykatorów kompromitacji systemów. Istotne jest by ten podsystem był precyzyjny, aby werdykty były precyzyjne i dawały nam maksymalnie dużo informacji przesyłanych obiektów czy ruchu sieciowego i znalezionych indykatorów szkodliwego działania.

20:11
Musimy mieć też system, który będzie potrafił operować na danych historycznych. Przy zagrożeniach typu Zero- day, może umknąć nam (lub systemowi) dana szkodliwa działalność, natomiast w momencie, kiedy zostanie ona zdefiniowana, opisana i są do niej wykonane znaczniki IOC, to w takim momencie system musi te dane historyczne jeszcze raz przejrzeć i posprawdzać czy w przeszłości nie było zdarzenia, które może skutkować przełamaniem naszych zabezpieczeń. Oczywiście z racji tego, że zakładamy, że monitorowanie będzie robione globalnie na niskim poziomie technologicznym, w związku z tym będziemy operowali na bardzo dużych zbiorach danych. Takie systemy muszą sobie z takimi operacjami poradzić. Mało tego, najlepiej, jeżeli radzą sobie w czasie zbliżonym do czasu rzeczywistego. Bardzo istotnym elementem, który taki system powinien mieć, jest umiejętność wyciągania wniosków, czyli poznania sposobów działania przestępców, to jest skrótowo (TTP) określane jako „techniki, taktyki i procedury przestępcze”. Poznanie tych sposobów działania, daje nam możliwość uszczelnienia czy też dostrojenia naszych systemów bezpieczeństwa, tak aby w przyszłości dany incydent się nie powtórzył albo by zostało ograniczone prawdopodobieństwo wystąpienia takiego incydentu.

21:51
To co chcielibyśmy Państwu zaproponować w ramach tego webinaru, to przyjrzenie się bliższe rozwiązaniu Fidelis Elevate, które spełnia warunki, o których wcześniej powiedziałem. Jest to rozwiązanie, które zapewnia nam automatyczną detekcję zagrożeń i daje możliwości odpowiedzi na te zagrożenia. Rozwiązanie te składa się z trzech modułów: modułu do analizy ruchu sieciowego (Fidelis Network), modułu do analizy zachowań stacji roboczych serwerów (Fidelis Endpoint) i modułu do detekcji zachowań atakujących (Fidelis Deception). Na co nam ten system pozwala? Pozwala nam na to, żeby widzieć wszelkie operacje, które są wykonywane przez sieć, zarówno na poziomie stacji roboczej jak i przy łączeniu się do aplikacji chmurowej. Mamy bardzo dokładną analizę ruchu sieciowego – oczywiście warstwa siódma i niezależność od portów. Mało tego, analiza jest zrobiona na bardzo głębokim poziomie związanym z analizą obiektów, które przez tę sieć przepływają, czyli jeżeli przez sieć przesyłany jest plik, to ten plik jest również analizowany pod kątem struktury, czy nie ma tam zagnieżdżonego kodu czy jakichś skryptów lub kawałków szkodliwego oprogramowania. System automatycznie wykrywa tego typu zagrożenia i zapewnia reakcję w postaci blokady, czy też kwarantanny maili zawierających szkodliwą zawartość. Jest tutaj możliwość skonfigurowania polityk, od prostego ostrzegania o podejrzeniu szkodliwej działalności, poprzez blokowanie czy kwarantannowanie ruchu. Mamy również możliwość reakcji na zagrożenia na stacji roboczej. Monitorujemy oczywiście operacje na plikach, rejestrach i procesach, sprawdzamy jakie operacje są robione na podłączonych pendrive’ach, ale mamy również możliwość reakcji na zagrożenia na stacji roboczej. Możemy taką stację automatycznie odciąć od sieci, wyizolować ją, uruchomić zrzut obrazu pamięci, czy też uruchomić wykonanie skryptów. System ma poza tym możliwość kreowania sztucznych obiektów, będących przynętą dla atakującego, co pozwala nam zobaczyć jaki środkami atakujący będzie się posługiwał, żeby spróbować przełamać zabezpieczenia. Daje nam to wiedzę na temat tego, jakich technik/taktyk używa atakujący. Skutkiem stosowania tego systemu, jest redukcja ryzyka naruszenia naszych danych, jak również znacząca redukcja czasu odpowiedzi na incydent.

25:31
System wykonawczy korzysta w warstwie sieciowej z sensorów. Sensory te są różnego rodzaju, tzn. mogą to być sensory do ruchu sieciowego, pracujące w trybie inline bądź out-of-band; mogą to być sensory dedykowane dla ruchu pocztowego, które pracują też w kilku innych trybach, np. MTA czy Blind Copy. Mamy również możliwość włączenia sensorów webowych, komunikujących się z serwerami Proxy, protokołem ICAP i monitorującym ruch HTTP/HTTPS czy FTP. Po stronie endpointa elementami wykonawczymi są agendy. Agendy są instalowane na stacjach roboczych na serwerach i jest to element wykonawczy, który realizuje polityki, które po pierwsze monitorują zachowanie tych niskopoziomowych operacji na serwerach czy stacjach roboczych, ale też pozwalają na wykonywanie operacji reakcyjnych, typu odłączenie komputera od sieci, czy też wykonanie skryptów, zrzutów lub dowolnych operacji. Dane, które są zbierane z tych sond sieciowych i przez agentów na stacjach roboczych i serwerach, są odkładane w postaci metadanych na kolektorach. Oddzielnie jest kolektor do endpointów i oddzielnie do sieci, w związku z tym mamy tutaj historyczną bazę metadanych. Dane na kolektorach sieciowych i endpointowych możemy również poddawać sprawdzeniu. I oczywiście systemy zarządzające, czyli CommandPost w odniesieniu do systemów Fidelis Network, Endpoint Services i do systemu pułapek. Komponent Endpoint Services serwuje polityki i przyjmuje rezultaty wykonanych zleceń ze stacji roboczych. Oczywiście system jest podłączony do systemów producenta, co jest o tyle istotne, że producent w sposób ciągły dba o to aby aktualizować bazę IOC, zarówno w części sieciowej, jak i w części endpointowej na bieżąco aktualizuje informacje na temat znanych zagrożeń. Niezależnie od tego system można jeszcze zintegrować z innymi źródłami danych. Nie wspomniałem jeszcze o Decoy Serwerze, komponencie, który jest odpowiedzialny za konstrukcję systemu pułapek. Jest to system, który pozwala nam na detekcję zachowań atakujących. — Robert Dąbroś — 30:06 Mam tutaj taką próbkę, która nazywa się FTCode. Próbka, którą mamy to tak naprawdę Income Statement – plik XLS. Trochę poddaliśmy tę próbkę obróbce, żeby było bardziej widoczne co tutaj się dzieje. Normalnie ten panel ftcode_safe jest częścią pliku excelowego i w perspektywie użytkownika, po otwarciu takiego pliku nic strasznego się nie dzieje, a w środku nic ciekawego nie ma. Natomiast w efekcie jest to, co w tej dolnej ramce, czyli pojawia się plik excelowy z rozszerzeniem ftcode i nowy plik o nazwie READ_ME_NOW. I teraz cała ta widzialność, o której mówił Sławek, to co się działo w trakcie wykonywania tego Excela, to tutaj widać na kilku zrzutach. To jest właśnie przykład meta danych, czy też artefaktów widzialności hosta na poziomie procesów, które się dzieją. Mamy tutaj wywołanie PowerShella z odpowiednimi opcjami i w konsekwencji tego pliku, to jest taki sposób, żeby użytkownik nie widział, że taka interakcja zachodzi. My to możemy sobie prześledzić w sposób graficzny. To, że PowerShell uruchomił się z Excela i tyle kolejnych zadań wykonał to już jest podejrzane. Na kolejnym zrzucie ekranu widać, bardzo fajną rzecz – jest to etap zadomowienia tej próbki czy też początek zadomowienia się. Tutaj widać jak backup katalog zostaje usunięty, usunięty jest też system state backup. Nie ma jakby do czego wrócić. System działa, natomiast nie mamy żadnej opcji powrotu do ostatniej dobrej zachowanej konfiguracji i tego typu rzeczy. Od tego momentu zaczyna się szyfrowanie i tu nasza próbka została trochę ugłaskana i nie szyfruje ona 190 formatów plików, tylko szuka samego xls i tylko w katalogu, w którym jest uruchomiona. W konsekwencji dostajemy pliki o nowej nazwie ftcode. Jeżeli nie mamy backupu, to nie mamy. Jeżeli mamy backup na udziale sieciowym, a mamy go podłączonego, to jest bardzo duża szansa, że ftcode w kolejnym kroku poszedłby również do tych udziałów sieciowych i zaszyfrował nam nasz backup. Trzeba więc uważać. Teraz mamy taką informację, że trzeba zapłacić za odzyskanie danych 500 USD. Czasami musimy zapłacić, bo się nie da ich odzyskać, czasem udaje się, że ktoś złamie te klucze, dostanie się i wykradnie je, a czasem agencje rządowe wyłączą serwer, na którym te klucze są i już się ich odzyskać nie da. Więc ta widzialność, o której mówiliśmy jest kluczowa po to, żebyśmy mogli coś zrobić. To co się dowiedzieliśmy podczas analizy tej próbki, to po pierwsze, że narzędzie typu Office wywołało jakieś inne narzędzie systemowe, np. w tym przypadku był to Excel i PowerShell i była to jedna z reguł behawioralnych, które moglibyśmy zastosować do wykrycia, że coś jest nie tak. Nie wyobrażam sobie, że każdy na co dzień ma otwartego Excela w biurze i w środku uruchamia się PowerShell – to jest zupełna abstrakcja. Druga – wywołanie samego PowerShella z opcjami – IEX, Download String, Invoke-Expressio – które na co dzień nie są używane, zazwyczaj są jakimiś narzędziami systemowymi, powinny być w sposób przewidywalny używane. Kolejna reguła – Shadow Copy Deleted, widać opcje. Kolejne – bcdedit – to był ten przykład, gdzie próbka się zadomowiała i wszystkie backup katalog, usunięcie takich rzeczy nie jest naturalne dla użytkownika. Jeśli to robi, to coś jest nie tak. Ostatnia opcja, Unusual File Rename, widzimy, jeżeli coś robi masową zmianę na wielu plikach i nadaje jakieś dziwne rozszerzenia, to też jest moment, w którym powinniśmy się zastanowić co się dzieje. Mamy tutaj regułę, która mogłaby wykryć coś takiego, natomiast proszę zauważyć, że zmierzam ciągle do tego jak duża widzialność jest tego co się dzieje na poziomie procesów w systemie i jak możemy zareagować w trakcie, kiedy mamy wykrycie. Nie mając takich danych trudno byłoby zrobić jakikolwiek Incident Response, bo oprócz odtworzenia stacji z backupu byłoby trudno.

— Sławomir Pyrek —
36:00
Część, którą pokazywałeś dotyczy ewidentnie tej części endpointowej. Tutaj było pokazywane generalnie to co widzimy, co jesteśmy w stanie wykryć przy pomocy endpointa. Natomiast w kontekście pracy zdalnej: czy ten system będzie umożliwiał taką samą skuteczną pracę w sytuacji, kiedy pracujemy z domu? Czy tutaj jest możliwość podwiązania naszego komputera w domu, online, w czasie w rzeczywistym do tego systemu zarządzania? — Robert Dąbroś — Jest komponent o nazwie gateway, który uruchomiony w DMZ całej komunikacji zaszyfrowanej, wszystkie komputery, które gdziekolwiek są podłączone do Internetu, są zarządzalne, więc mamy tą samą widzialność i te same opcje dotyczące jego możliwości naprawy. Co teraz moglibyśmy dołożyć do całego zestawu narzędzi, czyli całego Elevate’a, żeby mieć dużą widzialność na poziomie sieciowym? Tutaj są zaznaczone Fidelis Network Sensors. O samym tym moglibyśmy robić godzinną prezentację, jak właściwie zainstalować, co te komponenty mogą zrobić, ale tu prosty przykład: sensor i reguła, która obniża zagnieżdżony skrypt dowolnego typu w dokumentach typu Office i mail do kwarantanny i taka próbka nigdy nie trafia na stację. Oczywiście to ma za zadanie zrobić dużą analizę sieci i zwizualizować nam przepływy. Sensory są odpowiedzialne za wiele rzeczy i wszystko co widzą odkładają w formie artefaktów do kolektora, który jest po lewej, po to żebyśmy mogli z tego skorzystać, kiedy mamy właśnie incydent response. Czyli cały ruch sieciowy, nawet taki w którym nie było wykrycia, w momencie wykrycia jest odkładany w formie artefaktów, które możemy oglądać w kolejnych dniach. Cały system, zarówno endpointowy jak i networkowy, żyje dzięki feedom, gotowym zestawom polityk, które możemy ściągnąć i które w sposób analityczny opisują takie zdarzenie jak to, że PowerShell jest zagnieżdżony w Excelu, albo jest jakiś JavaScript skompresowany itd. Oczywiście jest zintegrowany Malware Detection Engine, który jest takim tworem zlepiającym wszystkie te dane, potrafiącym z nich skorzystać w sposób analityczny po to, żeby mieć również wysoki poziom wykrywalności i widzialności.

38:47
Mówiłem o metadanych. Wszystko co widzą sensory sieciowe, niezależnie od tego czy wygenerowały alert czy nie, to nawet jeżeli nie było alertu, zostaje to zapisane w wielkiej bazie danych, którą możemy przechowywać do 365 dni. Właściwie nie ma żadnych przeciwwskazań technicznych by trzymać je dłużej, licencyjnych pewnie też. W formie takiej dużej bazy metadanych, czy też artefaktów sieciowych – one dzisiaj nic nie znaczą, ale jutro możemy w nich wykrywać, możemy w nich sprawdzać wcześniejsze ruchy hosta, jeżeli będzie taka potrzeba, coś się stało, że ten plik został przetransportowany z punktu A do punktu B, czy ze stacji na serwer itd. To wszystko jest bardzo łatwo sprawdzalne i tutaj możemy sobie mnóstwo fajnych rzeczy obejrzeć. A Fidelis oczywiście wykorzystuje te metadane do kilku rzeczy. Po pierwsze do tego, żeby zbudować coś co nazywamy cyberterenem. Jak rozumiemy co bronimy, czyli jakie hosty są w jakiej sieci, jak się komunikują w konkretnych villainach czy też pomiędzy villainami, jakie są przepływy danych, jak komunikują się hosty z Internetem, jakich używają protokołów itd., jesteśmy w stanie bardziej przygotować się do wykrycia i obsługi incydentu, jeżeli taki nastąpił, bo mamy dane historyczne, dane bieżące i jesteśmy w stanie wszystko sprawdzić. My to wykorzystujemy do tego, żeby na podstawie naszego zrozumienia tego terenu, wykrywać również anomalie występujące w tej sieci, czyli to, że się pojawi nowy serwer i wykorzystuje nowy protokół albo nowy odcisk SSL-owy pojawił się na jakimś nowo otwartym porcie, albo jakiś host komunikuje się z geolokalizacją i robi tam duży upload itd. To wszystko jest efektem zbierania tych metadanych w kolektorze. Dodatkowo system oczywiście sam potrafi skorzystać z Sandboxa, podjąć decyzję, że należy coś umieścić w Sanboxie, bo np. zostało skompilowane godzinę temu, jest małym plikiem i przyszło pocztą z jakiegoś zupełnie niezaufanego, dziwnego adresu. Należy go umieścić w Sandboxie, żeby zobaczyć co to za próbka. Wykrycie zapewnia też element o nazwie Deception, czyli nasz system interaktywnych botów. Pułapki deception są emulatorami prawdziwych obiektów, one też są elementami, które na podstawie tego zrozumienia sieci, czyli zrozumienia terenu, potrafią wykreować elementy, które doskonale odpowiadają rzeczywistości, w konkretnym VLAN’ie, konkretne usługi, konkretne systemy operacyjne, po to żeby się nie odróżniać, a wręcz zachęcać atakującego do rozpoczęcia tej przygody Latteral Movement właśnie z naszymi systemami, a nie z systemami rzeczywistymi. Kiedy adwersarz jest w sieci, to, jeżeli nie mamy systemu klasy Deception, to widzi on to co jest w tej sieci i każdy jego kolejny krok, przybliża go do celu. Czyli czegokolwiek nie dotknie, to jest to jeden z prawdziwych systemów, jedna z możliwości wykonania kolejnego kroku po to, żeby ostatecznie wykonać eksfiltrację. Natomiast po wdrożeniu systemu klasy Deception, całkowicie zmienia się percepcja. Zmieniamy powierzchnię ataku, która zostaje rozszerzona w sposób wirtualny i co najważniejsze to jest forma nieexploitowalna. Te emulatory są tylko emulatorami. Natomiast taki atakujący wykonując kolejny krok, choćby skanowanie portów, natychmiast natknie się na nasze wabiki. Wabiki oczywiście zmieniają obraz sieci tak, żeby było dużo fałszywych komponentów z perspektywy sieciowej, żeby przyciągnąć atakującego do nas. Jest to jeden z dużych elementów wykrywalności już w tej późnej fazie.

42:36
Tutaj świetna nauka TTP o którym mówił Sławek, czyli jakiekolwiek wrzucenie exploita na jeden z wabików kończy się tym, że go sandboxujemy i od razu widzimy rezultaty, co to za narzędzie, co robi, po to, żeby dać nam tą samą widzialność, kiedy wykonuje się to na poziomie endpointa. Tak to wygląda, widzimy tu jakiegoś hosta, który ma emulowane daną liczbę usług. Zielony kolor na wykresach po prawej, oznacza prawdziwe hosty, szary kolor przedstawia hosty emulowane, więc widać dokładnie jak system ściągnął po usługach konkretne rzeczy. I to jest nie do odróżnienia na pierwszy rzut oka. Podłączając się do sieci, nie jesteśmy w stanie odróżnić, musimy dotknąć, one natychmiast alarmują. Jakakolwiek interakcja, próba logowania, udane zalogowanie, to wszystko jest krytycznym alertem i widzimy to. Z wszystkiego co wykryliśmy, czy to na poziomie endpointa, networka, czy Deception, możemy uruchamiać PlayBooki. Tak jak tutaj – mamy PlayBook Emergency Host Isolation. Jednym z pierwszych etapów jest Network Isolation, czyli izolujemy hosta, sami mamy do niego dostęp, możemy wykonywać każde kolejne zadanie, możemy mu się przyglądać, badać, ściągać dane, natomiast oni już więcej nie są się w stanie komunikować, nic nowego zainfekować. Natychmiast sczytujemy tutaj kolejne rzeczy typu autorun, konta użytkowników, administratorzy, analiza pamięci, po to żebyśmy wiedzieli co się w pamięci dzieje, no i oczywiście kontynuujemy swoją przygodę z diagnozą takiego hosta. Tutaj widzimy „pokaż mi otwarte sesje do zasobów sieciowych”, memory acquisition czyli zbierz mi pamięć w celach dowodowych do analizy, pokaż mi zadania zaplanowane, autorun i wszystkie inne rzeczy, które mogą nas zainteresować, po to żeby wykonać właściwy respond, bo tutaj z jednej strony zbieramy informacje żeby zobaczyć co się działo i informacje mamy też oczywiście w kolektorach. Chcemy trochę więcej, po to, żeby wykonać response. A ten response może być bardzo różny. Proszę zobaczyć, że tutaj mamy taką opcję Process Kill By Search, czyli zabijamy jakiś proces, który zidentyfikowaliśmy jako szkodliwy. Możemy to samo zrobić oczywiście w ramach odpowiedzi automatycznej, ale tutaj mamy sytuację, w której analityk siada, podejmuje jakieś decyzje, kolejne kroki, usunięcie kluczy z rejestru, skasowanie pliku itd. Pamiętacie Państwo – przykład był taki, że nie mamy do czego wrócić. Jedyną opcją (nie podaną tutaj w tabelce) byłoby odtworzenie z backupu, natomiast my chcemy, żeby ten ktoś, kto siedzi w domu i akurat ma coś do wykonania, nie musiał się fatygować z laptopem i my żebyśmy go odtworzyli, tylko chcemy to zrobić zdalnie. Jeżeli jest taka opcja, to świetnie, ten skrypt może odtworzyć z backupu system operacyjny, natomiast my chcemy go szybko przywrócić do działania. 45:26 Jeden z ostatnich slajdów, jak to element przywracania do pracy, bo już zidentyfikowaliśmy zagrożenie, pozbyliśmy się go i chcemy sprawdzić czy ten system działa. Np. czy właściwy jest stan Windows Firewalla, czy ustawienia antywirusa są właściwie zaktualizowane, czy compliance haseł i użytkowników jest właściwy itd. Tutaj mamy pełną kontrolę nad stacją, możemy robić z nią dosłownie co chcemy i po prawej co jest tutaj pokazane, to są tzw. konsole Live. Wybraliśmy sobie sytuację, że te pliki excelowe są już zaszyfrowane, użytkownik mówi: mam je tam na serwerze, przekopiujcie mi je tutaj, bo muszę skończyć raport już na teraz”. Mamy tutaj przeglądarkę File System, łączymy się zdalnie do tej maszyny, kopiujemy użytkownikowi z powrotem pliki, które zostały zaszyfrowane i może kontynuować pracę. To jest Konsola Live. Mamy dostęp nieograniczony do systemu operacyjnego, do systemu plików i procesów, po to, żeby móc znowu jeszcze trochę pobawić się w threat hunting, żeby poszukać np. czy te procesy, które tutaj zidentyfikowaliśmy jako złe, występują na innych stacjach itd. Chodzi o to żebyśmy się upewnili, że ta stacja jest czysta i że wszystkie inne, które mogą mieć podobne objawy, też już są czyste i nie mamy zagnieżdżenia tego malware w naszych zasobach. Po to jest ta widzialność, żebyśmy podejmując decyzję o właściwych odpowiedziach, byli pewni, że są one właściwe i że nic nam już więcej nie grozi, żeby ten czas do wykrycia i czas do usunięcia skrócić do maksimum, żeby nie doszło do eksfiltracji dalej. Lekcje odrobiliśmy, mieliśmy wykrycie, mieliśmy metadane, sprawdziliśmy co się działo, kto z kim, po co. Mamy tę część response network i endpoint. To co fajne, to, że mając takie narzędzie z jakimś wkładem, w efekcie jego pracy możemy dużo zmienić, dołożyć kolejne dane do analityki po to, żeby system widział więcej, mógł więcej, wykrywał wcześniej i żeby ta lekcja była odrobiona. Taki Internal Threat Intel, to chyba najlepsze określenie.

— Pytania —

48:20
„Czy ten system posiada Sandbox? Czy korzysta z niego?”
— Robert Dąbroś — System domyślnie posiada Sandboxa w formie cloudowej i to jest tysiąc detonacji URL-i / plików dziennie – taki jest limit darmowości. Można wykupić oczywiście kolejne pakiety zwiększające ilość detonacji, ale istnieje oczywiście opcja on-prem. Ona będzie działała z taką wydajnością z jaką da radę, mniej więcej szacowana jest na 20 tysięcy wykonań w ciągu dnia, a czasami daje radę więcej. Architektura jest bardzo elastyczna, jeżeli chodzi o Fidelisa.

„Jak licencjonowany jest ten system?”
— Robert Dąbroś — Fidelis Network licencjonowany jest na przepływność mierzoną na wszystkich podłączonych do systemu sensorach, agregowana do jednej godziny. Agregacja w jednej godzinie pozwala nam usunąć wszystkie pliki i tego ruchu jest naprawdę stosunkowo niewiele. I czas retencji danych – 30, 60, 180, 365 dni – i to jest wszystko. Jeżeli chodzi o endpointa, to każdy zainstalowany endpoint, niezależnie od tego czy jest zainstalowany na Windows Serverze, na stacji roboczej, w Macu czy Linuxsie, to jest jedna licencja. Jeżeli chodzi o system Deception to tutaj mamy wybór – mamy liczbę villainów albo liczbę użytkowników w organizacji. Bierzemy pod uwagę to, co wychodzi korzystniej.

— Sławomir Pyrek — 50:14
Tak jak Robert powiedział – na każdy z tych tematów można by zrobić kilka oddzielnych prezentacji, ponieważ system jest mocno rozbudowany, a ilość funkcji naprawdę imponująca. Co możemy Państwu jako EXATEL zaproponować? Możemy oczywiście zaproponować wsparcie we wdrożeniu takiego systemu, począwszy od analizy potrzeb, możemy zrobić proof-of-concept u Państwa na miejscu. Mamy specjalne urządzenia dedykowane do tego, żeby robić wdrożenia testowe. Oczywiście robimy projekt techniczny, implementujemy rozwiązania, dajemy do tych systemów wsparcie powdrożeniowe. Co bardzo istotne, wspieramy personel klienta, chociażby w dostrajaniu polityk, ich konstrukcji, w integracjach z rozwiązaniami innych firm. Również bardzo istotne jest to, że nasi specjaliści z Security Operations Center mogą wykonywać przegląd alertów wygenerowanych przez system czy też dokonywać przeglądu metadanych, które były przez taki system składowane, czy to w odniesieniu do endpointów, czy do modułu sieciowego. Dysponujemy również własnym SOC, które działa 24/7, 365 dni w roku i m.in. jednym z zadań, które realizuje SOC, jest monitorowanie i wsparcie w reakcji na incydenty. Używamy na co dzień platformy Fidelisowej, w związku z czym dosyć dobrze ją znamy. Mamy również dosyć duże doświadczenie w analizie alertów pojawiających się w Fidelisie, ale również na wielu innych systemach. Gorąco zachęcam Państwa do kontaktu z nami, do zapoznania się z naszą ofertą, a w szczególności do dogłębnego zapoznania się z technologią Fidelis. Znaczenie ataków typu DDoS znacząco wzrosło w ostatnim czasie. Spośród ataków wymagających jakiegokolwiek udziału technologicznego, a występujących faktycznie w cyberprzestrzeni, ten typ ataków jest zdecydowanie najpopularniejszy, pomijając przestępczość internetową związaną z groźbami karalnymi i hejtem, które to są adresowane w trochę inny sposób i nie wymagają wsparcia technologii i szczególnej wiedzy. Opowiemy dziś Państwu o naszych doświadczeniach związanych z cyberbezpieczeństwem, o atakach DDoS i jaki mają one wpływ na ciągłość działania. Wspomnimy również o tym jak bronić się przed tymi atakami z wykorzystaniem opracowanej przez nas platformy.

Sławomir Pyrek, Kierownik Projektu, EXATEL S.A. Robert Dąbroś, Senior Presales System Engineer, Fidelis Cybersecurity