Jak zbudować skuteczną ochronę przed ransomware

Ataki ransomware pozostają jednym z najpoważniejszych zagrożeń dla współczesnych organizacji. Ich konsekwencją może być nie tylko zaszyfrowanie danych i zatrzymanie działania infrastruktury IT, ale również kradzież informacji, utrata ciągłości działania oraz długotrwały i kosztowny proces odtwarzania środowiska. Warto zapoznać się z praktycznymi rekomendacjami dla administratorów i zespołów bezpieczeństwa.

Moje doświadczenia jako analityka Incident Response, oparte na kilkunastu analizach forensics realizowanych po rzeczywistych incydentach bezpieczeństwa, doprowadziły mnie do dość prostego wniosku: wielu z tych ataków można było uniknąć, a przynajmniej znacząco utrudnić ich przeprowadzenie i ograniczyć skutki.

W analizowanych przypadkach bardzo często niejedna krytyczna podatność czy pojedynczy błąd prowadziły do pełnej kompromitacji środowiska. Znacznie częściej był to ciąg pozornie niezależnych problemów: brak MFA, nieaktualne systemy, zbyt szerokie uprawnienia, płaska sieć, współdzielone konta administratorów, niewystarczający monitoring czy brak możliwości szybkiej izolacji zaatakowanych systemów.

Każdy z tych elementów osobno nie musi prowadzić do poważnego incydentu. Połączone tworzą jednak ścieżkę, którą atakujący może wykorzystać do przejścia od początkowego dostępu do przejęcia kolejnych systemów, eskalacji uprawnień, eksfiltracji danych i ostatecznie wdrożenia ransomware.

Nie ma jednego pomysłu na ochronę

Oczywiście każdy incydent jest inny. Różne są możliwości, motywacje i poziom determinacji atakujących. Nie istnieje zestaw zabezpieczeń, który zagwarantuje, że organizacja nigdy nie zostanie skutecznie zaatakowana.

Jednocześnie większość obserwowanych przeze mnie ataków nie była zbiorem przypadkowych działań. Atakujący korzystają ze sprawdzonych narzędzi, technik i schematów postępowania. Uzyskują początkowy dostęp, prowadzą rekonesans środowiska, zdobywają kolejne uprawnienia, przemieszczają się pomiędzy systemami, przejmują konta uprzywilejowane, wyłączają mechanizmy bezpieczeństwa, kopiują dane, a następnie uruchamiają ransomware.

To dobra wiadomość dla obrońców. Jeżeli znamy typowe etapy ataku, możemy budować zabezpieczenia w taki sposób, aby na każdym z nich atakujący napotykał kolejną przeszkodę.

Nie chodzi przy tym o znalezienie jednego produktu czy technologii, która „zatrzyma ransomware”. Skuteczna ochrona powinna składać się z wielu wzajemnie uzupełniających się warstw – od wiedzy o posiadanych zasobach i właściwej architektury sieci przez zarządzanie tożsamością i ochronę systemów końcowych, aż po monitoring, detekcję, reagowanie na incydenty i możliwość odtworzenia środowiska.

Poniższe rekomendacje są zbiorem praktycznych działań, które mogą pomóc organizacji zmniejszyć prawdopodobieństwo skutecznego ataku ransomware, utrudnić działania napastnika oraz ograniczyć skalę incydentu, jeśli do kompromitacji mimo wszystko dojdzie.

Nie jest to lista gwarantująca pełną odporność na ransomware. Jest to raczej próba odpowiedzi na bardzo praktyczne pytanie:

Co możemy zrobić dzisiaj, aby jutro atakujący miał znacznie trudniejsze zadanie?

Warstwa 1. Architektura i ograniczenie powierzchni ataku

Pierwszą linią obrony jest wiedza o własnym środowisku oraz właściwie zaprojektowana infrastruktura. Nie powinniśmy zakładać wyłącznie, że uda nam się uniemożliwić uzyskanie początkowego dostępu. Znacznie bezpieczniejszym założeniem jest przyjęcie, że pojedynczy system może zostać przejęty, a następnie zaprojektowanie środowiska tak, aby jego kompromitacja nie oznaczała automatycznie kompromitacji całej organizacji.

1. Zacznij od wiedzy o własnych zasobach

Trudno chronić infrastrukturę, o której istnieniu nie wiemy. Organizacja powinna posiadać aktualną ewidencję wykorzystywanych systemów, urządzeń, aplikacji i usług, wraz z informacją o ich właścicielach, funkcji biznesowej, wersjach oprogramowania oraz ekspozycji na Internet.

Szczególnej kontroli powinny podlegać zasoby dostępne publicznie. Zapomniany serwer, nieużywana aplikacja, stary koncentrator VPN czy urządzenie pozostawione z nieaktualnym oprogramowaniem mogą stać się najprostszą drogą do infrastruktury organizacji.

Asset Management stanowi fundament wielu kolejnych procesów bezpieczeństwa. Bez wiedzy o posiadanych zasobach trudno skutecznie zarządzać podatnościami, aktualizacjami, wdrożeniem EDR czy centralnym logowaniem.

2. Segmentacja i mikrosegmentacja sieci

Należy wdrożyć architekturę sieciową uwzględniającą segmentację. Tam, gdzie jest to uzasadnione – również mikrosegmentację.

Stacje robocze użytkowników, serwery, systemy administracyjne, infrastruktura kopii zapasowych oraz systemy krytyczne powinny funkcjonować w odpowiednio wydzielonych strefach bezpieczeństwa. Komunikacja pomiędzy nimi powinna być ograniczona zgodnie z zasadą najmniejszych uprawnień. Jeżeli stacja użytkownika nie musi komunikować się bezpośrednio z określonym serwerem lub inną stacją roboczą, taki ruch powinien być domyślnie zablokowany.

Segmentacja znacząco utrudnia prowadzenie rekonesansu i ruchu lateralnego oraz ogranicza możliwość rozprzestrzenienia ransomware na całe środowisko.

3. Kontrola i inspekcja ruchu pomiędzy strefami

Ruch pomiędzy kluczowymi segmentami sieci powinien być kontrolowany przez odpowiednio skonfigurowane firewalle. Tam, gdzie jest to uzasadnione – również monitorowany przez rozwiązania klasy Intrusion Detection/Prevention System (IDS/IPS). Systemy te mogą wspierać identyfikację prób rekonesansu, skanowania usług, ataków brute-force, wykorzystania znanych podatności czy transmisji potencjalnie złośliwych plików.

IPS nie powinien być traktowany wyłącznie jako zabezpieczenie styku z internetem. W odpowiednio zaprojektowanej architekturze może również stanowić element kontroli i monitorowania komunikacji pomiędzy wybranymi strefami wewnętrznymi.

4. Web Proxy i kontrola dostępu do Internetu

Ruch HTTP i HTTPS generowany przez stacje robocze powinien podlegać kontroli z wykorzystaniem rozwiązania Web Proxy, Secure Web Gateway lub równoważnego mechanizmu bezpieczeństwa. System powinien umożliwiać blokowanie zasobów o złej reputacji oraz – zależnie od polityki organizacji – nowo utworzonych, nieskategoryzowanych lub nieznanych domen.

Jeszcze bardziej restrykcyjne zasady powinny dotyczyć serwerów. Serwer, który nie wymaga bezpośredniego dostępu do internetu, nie powinien go posiadać. W pozostałych przypadkach należy ograniczyć komunikację do usług i kierunków niezbędnych do realizacji jego funkcji. Takie podejście może znacząco utrudnić zarówno pobieranie kolejnych komponentów malware, jak i komunikację z infrastrukturą Command&Control.

5. DNS reputacyjny

Kolejną warstwę ochrony powinien stanowić system DNS wykorzystujący informacje reputacyjne. Pozwala on blokować komunikację ze znanymi domenami phishingowymi, serwerami Command&Control, infrastrukturą dystrybucji malware oraz innymi zasobami powiązanymi ze złośliwą aktywnością. Mechanizm ten działa na bardzo wczesnym etapie komunikacji i może uniemożliwić połączenie ze złośliwą infrastrukturą jeszcze przed nawiązaniem właściwej sesji sieciowej.

Warstwa 2. Tożsamość, konta i kontrola dostępu

W wielu incydentach ransomware kluczowym momentem nie jest samo uruchomienie malware, lecz przejęcie konta posiadającego wystarczające uprawnienia do dalszego przemieszczania się po środowisku. Uzyskanie poświadczeń administratora może całkowicie zmienić skalę incydentu. Dlatego ochrona tożsamości powinna być jednym z najważniejszych elementów strategii anty-ransomware.

6. MFA i ochrona dostępu zdalnego

Uwierzytelnianie wieloskładnikowe powinno być obowiązkowe przynajmniej dla dostępu VPN, poczty, usług chmurowych, systemów administracyjnych oraz wszystkich kont uprzywilejowanych. Tam, gdzie jest to możliwe, warto preferować mechanizmy MFA odporne na phishing zamiast opierać ochronę wyłącznie na kodach SMS czy prostych powiadomieniach push.

W przypadku infrastruktury VPN można dodatkowo rozważyć ograniczenie możliwości nawiązywania połączeń z lokalizacji geograficznych, z których organizacja nie prowadzi działalności – jeżeli takie ograniczenie wynika z analizy ryzyka.

Należy również przeanalizować zasadność wykorzystywania split tunnelingu. W środowiskach wymagających pełnej kontroli ruchu jego wyłączenie pozwala kierować komunikację użytkownika przez firmowe mechanizmy bezpieczeństwa.

7. Oddziel konta administracyjne od codziennej pracy

Konta administracyjne nie powinny być wykorzystywane do codziennej pracy, przeglądania internetu czy obsługi poczty elektronicznej. Administrator powinien posiadać oddzielne konto użytkownika oraz oddzielne konto administracyjne, wykorzystywane wyłącznie podczas wykonywania czynności wymagających podwyższonych uprawnień.

W bardziej dojrzałych środowiskach warto dodatkowo wdrożyć model separacji poziomów administracyjnych oraz dedykowane, odpowiednio zabezpieczone stacje wykorzystywane do zarządzania infrastrukturą, np. PAW (Privileged Access Workstation). Celem jest ograniczenie sytuacji, w której kompromitacja zwykłej stacji administratora automatycznie daje napastnikowi dostęp do poświadczeń pozwalających zarządzać kluczowymi systemami.

8. Windows LAPS

W środowiskach Windows należy wdrożyć Windows LAPS umożliwiający centralne zarządzanie hasłami lokalnych kont administratorów. Każdy system powinien posiadać inne, odpowiednio złożone i automatycznie rotowane hasło administratora lokalnego.

Wykorzystywanie tego samego hasła lokalnego administratora na wielu komputerach tworzy bardzo dogodne warunki do ruchu lateralnego. Przejęcie poświadczeń na jednym systemie może w takim przypadku umożliwić uzyskanie dostępu do kolejnych urządzeń. LAPS znacząco ogranicza to ryzyko.

9. Zarządzanie tożsamością i recertyfikacja dostępów

Organizacja powinna posiadać centralną ewidencję kont i nadanych uprawnień. Dostępy powinny podlegać regularnej recertyfikacji, a nieaktywne konta, niepotrzebne uprawnienia oraz dostępy osób, które zmieniły stanowisko lub zakończyły współpracę z organizacją, powinny być niezwłocznie usuwane.

Należy konsekwentnie stosować zasadę najmniejszych uprawnień. Użytkownik, administrator, konto techniczne czy aplikacja powinny posiadać wyłącznie takie uprawnienia, jakie są niezbędne do realizacji ich funkcji. Szczególnej kontroli powinny podlegać konta uprzywilejowane oraz konta techniczne.

Warstwa 3. Ochrona stacji roboczych i serwerów

Kolejnym poziomem ochrony są same systemy końcowe. Nawet jeżeli napastnik przedostanie się do sieci, jego działania na stacji roboczej lub serwerze powinny pozostawiać ślady i zostać możliwie szybko wykryte.

10. Endpoint Detection and Response

Rozwiązanie klasy EDR powinno zostać wdrożone na wszystkich obsługiwanych stacjach roboczych i serwerach, na których jest to technicznie możliwe. Reguły detekcyjne powinny uwzględniać techniki wykorzystywane podczas ataków ransomware, takie jak próby wyłączania mechanizmów bezpieczeństwa, usuwanie kopii Volume Shadow Copy, manipulowanie usługami, wykorzystanie PowerShell, WMI czy PsExec, pozyskiwanie poświadczeń oraz nietypowe masowe operacje na plikach.

EDR powinien również umożliwiać szybką zdalną izolację hosta od sieci.

W praktyce możliwość odizolowania zainfekowanej stacji lub serwera w ciągu kilku minut od wykrycia podejrzanej aktywności może mieć kluczowe znaczenie dla ograniczenia skali incydentu.

11. Sysmon jako dodatkowe źródło telemetrii

W środowiskach Windows warto rozważyć wdrożenie Sysmon jako dodatkowego źródła telemetrii bezpieczeństwa. Odpowiednio skonfigurowany Sysmon pozwala rejestrować m.in. tworzenie procesów, połączenia sieciowe, operacje na plikach i rejestrze oraz inne zdarzenia przydatne podczas wykrywania i analizy ataków.

Sysmon sam w sobie nie jest jednak mechanizmem ochronnym. Jego wartość pojawia się dopiero wtedy, gdy generowane dane są centralnie zbierane i analizowane. Dlatego logi Sysmon powinny być przesyłane do SIEM i wykorzystywane przez odpowiednio przygotowane reguły detekcyjne.

12. Hardening systemów

Konfiguracja systemów operacyjnych powinna ograniczać możliwość wykorzystania funkcji, które nie są wymagane biznesowo. Należy ograniczać zbędne usługi, protokoły i mechanizmy administracyjne, kontrolować możliwość uruchamiania skryptów oraz wykorzystywać mechanizmy bezpieczeństwa oferowane przez system operacyjny.

W przypadku środowisk Windows szczególnej analizie powinny podlegać m.in. NTLM, SMB, PowerShell, RDP oraz mechanizmy przechowywania i ochrony poświadczeń. Zasada jest prosta: jeżeli dana funkcja nie jest potrzebna – powinna zostać wyłączona lub ograniczona.

Warstwa 4. Podatności i systemy wystawione do internetu

Jednym ze sposobów uzyskania początkowego dostępu pozostaje wykorzystanie podatności w publicznie dostępnych systemach. Szczególnie atrakcyjnym celem są urządzenia brzegowe: koncentratory VPN, firewalle, systemy zdalnego dostępu oraz publicznie dostępne aplikacje.

13. Zarządzanie podatnościami

Organizacja powinna posiadać ciągły proces zarządzania podatnościami obejmujący identyfikację zasobów, skanowanie podatności, ocenę ryzyka, priorytetyzację oraz kontrolę procesu ich usuwania.

Samo wykonanie skanu nie jest zarządzaniem podatnościami. Kluczowe jest doprowadzenie procesu do momentu usunięcia podatności, zastosowania mechanizmu ograniczającego ryzyko albo świadomej i udokumentowanej akceptacji związanego z nią ryzyka.

Priorytetyzacja nie powinna wynikać wyłącznie z wartości CVSS. Należy również uwzględniać ekspozycję systemu, jego znaczenie dla organizacji oraz informacje o rzeczywistym wykorzystywaniu danej podatności przez atakujących.

14. Aktualizacje i zarządzanie wersjami oprogramowania

Wszystkie systemy operacyjne, aplikacje oraz urządzenia infrastruktury powinny być aktualizowane zgodnie z zaleceniami producentów. Najwyższy priorytet powinny otrzymywać podatności aktywnie wykorzystywane przez atakujących oraz systemy dostępne bezpośrednio z internetu.

Standardowy cykl aktualizacji może być niewystarczający w sytuacji, gdy pojawia się krytyczna podatność aktywnie wykorzystywana w atakach. Organizacja powinna posiadać możliwość uruchomienia przyspieszonego, awaryjnego procesu aktualizacji dla takich przypadków.

Należy również posiadać ewidencję wykorzystywanych wersji oprogramowania, aby szybko określić, które systemy wymagają interwencji.

15. Web Application Firewall

Publicznie dostępne aplikacje internetowe powinny być chronione za pomocą rozwiązania klasy Web Application Firewall (WAF). WAF stanowi dodatkową warstwę zabezpieczeń umożliwiającą identyfikację i blokowanie części prób wykorzystania podatności aplikacyjnych. Nie zastępuje on jednak procesu zarządzania podatnościami, aktualizacji ani bezpiecznego procesu tworzenia oprogramowania. Powinien być traktowany jako kolejna warstwa ochrony, a nie rozwiązanie problemu podatnej aplikacji.

Warstwa 5. Monitoring i detekcja

Atak ransomware bardzo rzadko rozpoczyna się od szyfrowania danych. Wcześniej napastnik może przez wiele godzin lub dni prowadzić rekonesans, pozyskiwać poświadczenia, eskalować uprawnienia, przemieszczać się po środowisku i przygotowywać infrastrukturę do przeprowadzenia właściwego ataku.

To właśnie na tym etapie istnieje największa szansa na jego wykrycie, zanim dojdzie do zaszyfrowania systemów.

16. Centralny SIEM

Organizacja powinna posiadać centralny system gromadzenia i analizy zdarzeń bezpieczeństwa klasy SIEM. Do systemu powinny trafiać logi m.in. z systemów operacyjnych, usług katalogowych, urządzeń sieciowych, VPN, firewalli, WAF, IDS/IPS, EDR, systemów antywirusowych oraz kluczowych aplikacji. Nie chodzi jednak wyłącznie o zgromadzenie możliwie dużej liczby logów.

SIEM powinien posiadać zestaw reguł korelacyjnych i detekcyjnych pozwalających identyfikować zarówno pojedyncze podejrzane zdarzenia, jak i sekwencje działań mogących wskazywać na trwający atak. Reguły powinny być regularnie rozwijane i dostosowywane do zmian infrastruktury oraz aktualnego krajobrazu zagrożeń.

17. SOC i ciągły monitoring

Alert musi trafić do kogoś, kto potrafi go właściwie zinterpretować. Zdarzenia generowane przez SIEM, EDR i pozostałe systemy bezpieczeństwa powinny być analizowane przez zespół odpowiedzialny za monitoring bezpieczeństwa – wewnętrzny SOC lub zewnętrzną usługę realizującą taką funkcję.

Kluczowe jest zapewnienie odpowiedniego czasu reakcji. Alert bezpieczeństwa, którego nikt nie analizuje przez kilkanaście godzin, może mieć niewielką wartość podczas szybko rozwijającego się incydentu ransomware. Wraz z procesem monitorowania należy przygotować scenariusze postępowania określające, co analityk powinien zrobić po wykryciu konkretnych rodzajów aktywności oraz kiedy zdarzenie wymaga natychmiastowej eskalacji.

18. Cyber Threat Intelligence

Proces monitorowania powinien być wspierany przez analizę aktualnego krajobrazu zagrożeń.

Cyber Threat Intelligence pozwala identyfikować nowe techniki, narzędzia i sposoby działania grup ransomware, a następnie przekładać tę wiedzę na konkretne działania obronne. Nie powinno sprowadzać się wyłącznie do kolekcjonowania adresów IP, domen czy hashy plików. Największą wartość daje wiedza o sposobie działania przeciwnika – jego taktykach, technikach i procedurach – którą można przełożyć na nowe reguły SIEM i EDR, mechanizmy blokowania, scenariusze threat huntingu oraz zmiany konfiguracji infrastruktury.

Warstwa 6. Reagowanie i odporność organizacji

Nawet najlepsze zabezpieczenia nie gwarantują, że organizacja nigdy nie zostanie zaatakowana. Dlatego strategia anty-ransomware musi odpowiadać również na pytanie:

Co zrobimy, jeśli atakujący jednak dostanie się do naszej infrastruktury?

19. Przygotuj plan Incident Response

Organizacja powinna posiadać przygotowany i regularnie testowany plan reagowania na incydent ransomware. Procedura powinna określać role i odpowiedzialności, sposób eskalacji incydentu, zasady komunikacji oraz działania techniczne wykonywane podczas jego obsługi.

Zespół reagowania powinien mieć możliwość szybkiej izolacji pojedynczych urządzeń, blokowania kont użytkowników, odcinania serwerów, a w sytuacji krytycznej również izolowania całych segmentów sieci. Decyzje takie nie powinny być po raz pierwszy uzgadniane w momencie trwającego ataku.

Warto wcześniej określić, kto posiada uprawnienia do podjęcia decyzji o izolacji systemu lub części infrastruktury i w jakich sytuacjach może to zrobić.

20. Backup i możliwość odtworzenia środowiska

Kopie zapasowe są jedną z najważniejszych ostatnich linii obrony przed ransomware.

Można stosować strategię 3-2-1-1-0: co najmniej trzy kopie danych, na dwóch różnych typach nośników, jedna kopia poza podstawową lokalizacją, jedna kopia offline lub immutable oraz brak błędów podczas testów odtwarzania.

Szczególnie istotne jest odseparowanie infrastruktury backupowej od podstawowego środowiska oraz ograniczenie możliwości jej administracji z wykorzystaniem tych samych kont, które zarządzają pozostałą infrastrukturą. Atakujący również wiedzą, że backup może uniemożliwić skuteczny szantaż. Dlatego infrastruktura kopii zapasowych często staje się jednym z celów ataku.

Samo posiadanie backupu nie wystarcza. Organizacja musi regularnie sprawdzać, czy rzeczywiście jest w stanie odtworzyć z niego kluczowe systemy oraz ile czasu taki proces zajmuje. Backup, którego nigdy nie próbowano odtworzyć, jest jedynie założeniem, że posiadamy backup (żartobliwie nazywany Backupem Schroedingera).

21. Ćwicz, zanim wydarzy się prawdziwy incydent

Procedury reagowania powinny być regularnie testowane. Warto prowadzić ćwiczenia TableTop, Purple Team oraz symulacje incydentów ransomware obejmujące zarówno zespoły techniczne, jak i osoby odpowiedzialne za zarządzanie organizacją, komunikację, kwestie prawne oraz ciągłość działania.

Ćwiczenia powinny odpowiadać na bardzo praktyczne pytania:

• Kto podejmuje decyzję o odłączeniu części infrastruktury?
• Jak skontaktujemy się ze sobą, jeśli poczta przestanie działać?
• Kto odpowiada za kontakt z klientami?
• Jak szybko potrafimy ustalić skalę kompromitacji?
• Czy wiemy, które systemy muszą zostać odtworzone jako pierwsze?
• Czy potrafimy odtworzyć je z backupu?

Pierwszym momentem, w którym organizacja sprawdza swój plan reagowania na ransomware, nie powinien być rzeczywisty atak.

Zamiast jednej bariery przeciwko ransomware – wiele warstw

Nie istnieje pojedynczy produkt, który rozwiązuje problem ransomware. EDR nie zastąpi segmentacji. Segmentacja nie zastąpi MFA. MFA nie usunie podatności. SIEM nie pomoże, jeśli nikt nie analizuje generowanych przez niego alertów. Backup nie zatrzyma ataku, ale może zdecydować o tym, czy po incydencie organizacja będzie w stanie odtworzyć swoje środowisko.

Dlatego skuteczna ochrona przed ransomware powinna opierać się na koncepcji Defense in Depth – wielu niezależnych, wzajemnie uzupełniających się warstw zabezpieczeń. Można spojrzeć na nie jak na kolejne przeszkody ustawione na drodze atakującego: poznaj swoje zasoby → ogranicz powierzchnię ataku → chroń tożsamość → utrudnij ruch lateralny → chroń endpointy → monitoruj → wykrywaj → reaguj → odtwarzaj.

Atakujący może ominąć jedną z tych warstw. Być może ominie również drugą. Każda kolejna zwiększa jednak koszt i czas potrzebny do przeprowadzenia ataku oraz prawdopodobieństwo jego wykrycia.

Warto również pamiętać, że sukces obrony nie zawsze musi oznaczać całkowite uniemożliwienie włamania. Jeżeli napastnik wykorzysta podatność i przejmie pojedynczy serwer, ale segmentacja uniemożliwi mu dalszy ruch, EDR wykryje jego działania, SOC zareaguje na alert, a zespół Incident Response odizoluje system, zanim atakujący uzyska dostęp do kluczowej infrastruktury – mechanizmy bezpieczeństwa spełniły swoją funkcję.

I właśnie to powinno być jednym z podstawowych celów dobrze zaprojektowanej architektury bezpieczeństwa: nie zakładać, że atak nigdy się nie wydarzy, lecz zbudować środowisko, w którym jego skuteczne przeprowadzenie będzie możliwie trudne, jego działania możliwie szybko wykryte, a skutki incydentu ograniczone.