Bezpieczeństwo to nie narzędzia – to przemyślane decyzje

Gdyby miała pani w kilku krokach opisać typowy scenariusz ataku na polską firmę – od pierwszego punktu wejścia do pełnego przejęcia infrastruktury – jak by to wyglądało?

Najpierw pozwolę sobie wyjaśnić nieco postrzeganie samego ataku, jako że ma on podstawy, które najpierw musimy zrozumieć. W cyberbezpieczeństwie wciąż funkcjonuje wygodny mit, że organizacje przegrywają, bo napastnicy są coraz bardziej zaawansowani. W praktyce jest odwrotnie. Większość incydentów nie wynika z przełomowych technik, tylko z przewidywalnych błędów w projektowaniu środowiska, zarządzaniu tożsamością i braku kontroli nad przepływem uprawnień. Z perspektywy osoby, która regularnie symuluje ataki na środowiska enterprise, widać wyraźnie, że atak nie jest chaotycznym zdarzeniem. To proces poruszania się po systemie zależności, który organizacja sama stworzyła. Właśnie dlatego można go przewidzieć. Atak jest często konsekwencją architektury, a nie tylko samym klasycznie postrzeganym incydentem. Największy błąd strategiczny polega na traktowaniu ataku jako „wejścia do systemu”. W rzeczywistości wejście jest tylko momentem inicjalnym. Kluczowe jest to, co środowisko pozwala zrobić dalej.

W praktyce oznacza to, że pojedynczy punkt wejścia rzadko jest problemem sam w sobie, a decydujące znaczenie ma sposób, w jaki tożsamości są zarządzane i wykorzystywane w infrastrukturze. Atak rozwija się zgodnie z logiką środowiska, a nie tylko kreatywnością napastnika. Jeżeli infrastruktura umożliwia nadużycie jednej tożsamości do uzyskania kolejnych, to atak nie musi być wyrafinowany. Wystarczy, że jest konsekwentny.

Kradzież poświadczeń, Pass-the-Hash, Kerberoasting – dlaczego te techniki są dziś tak skuteczne i dlaczego samo MFA nie jest wystarczającą odpowiedzią?

Głównym zadaniem zespołów zajmujących się zabezpieczaniem jest zrobienie wszystkiego, co pozwala na obniżenie ryzyka włamania. Od wielu lat MFA również można obejść i jest to np. przy wykorzystaniu dobrze przeprowadzonej kampanii phishingowej stosunkowo proste. Problem leży więc nie w tym, czy mamy dane rozwiązanie, ale w tym, jak podchodzimy do konkretnej techniki zabezpieczenia. Pass-the-Hash, Kerberoasting, ale również wiele innych ataków ma swój odpowiednik w zabezpieczeniu lub obniżeniu ryzyka. Z perspektywy strategicznej przyczyny są powtarzalne:

1. Brak kontroli nad tożsamością – uprawnienia są przyznawane ad hoc, bez pełnej widoczności ich konsekwencji.

2. Nadmierne zaufanie w architekturze i brak regularnych, dobrze wykonanych (nie ad hoc) audytów – tu zawsze pojawia się zagadnienie, kogo umiejętnościom ufamy. Ważne jest, żeby zespół wykonujący testy był doświadczony nie tylko w samych testach, ale również w bezpieczeństwie ogólnym infrastruktury, czyli po prostu kompletny.

3. Brak segmentacji logicznej, nie tylko sieciowej – granice nie są definiowane przez poziomy ryzyka, tylko przez strukturę organizacyjną.

4. Skupienie na narzędziach zamiast na modelu bezpieczeństwa – technologia często maskuje problemy, zamiast je rozwiązywać.

Z jakimi najbardziej zaskakującymi lukami w zabezpieczeniach spotyka się pani zespół podczas audytów? Czy są błędy, które wciąż panią zaskakują?

W planowaniu strategii cyberbezpieczeństwa najważniejsze jest osiągnięcie stanu zupełnej transparentności, czyli identyfikacja źródeł danych, z których będziemy wiedzieć, co się dzieje w infrastrukturze, a w dalszym etapie korelacja tych danych w dobrym systemie SIEM. Jest to dla mnie takie „hello world” w cyberbezpieczeństwie. Brak tego uważam za jedną z większych luk w zabezpieczeniach. Teoretycznie bezpieczna chmura dzisiaj wymaga gruntownego spojrzenia na to, jakie w nich logujemy informacje, żeby np. w trakcie incydentu móc zrozumieć, co się wydarzyło. Praktycznie nigdy nie widzimy chmury dostosowanej do aktualnych standardów bezpieczeństwa, podobnie jak Active Directory. W obydwu obszarach nadawane są uprawnienia do obiektów, które są często zbędne i za wysokie – to często prowadzi do eskalacji. W Active Directory mamy uprawnienie GenericWrite, które może być nadawane np. przez jakąś aplikację zewnętrzną; w większym obrazie okazuje się to zabójcze dla infrastruktury.

Wiele polskich organizacji wdrożyło Active Directory lata temu i od tamtego czasu niewiele zmieniło w konfiguracji. Jak duże ryzyko to stanowi i od czego powinny zacząć „porządki”?

W środowiskach opartych o Active Directory (czyli w praktycznie wszystkich) rzeczywisty poziom bezpieczeństwa organizacji jest wprost proporcjonalny do jakości jego konfiguracji, podobnie jest z chmurą czy innymi komponentami. Oczywiście pojawiają się również nowe techniki ataków i należy na nie reagować. Dobrym przykładem jest PetitPotam (atak sprzed wielu lat, który często działa również dzisiaj), który pokazał, jak można wymusić uwierzytelnienie i wykorzystać je w scenariuszach relay, szczególnie w kontekście usług certyfikatów (Active Directory Certificate Services). W praktyce jednak kluczowe nie jest reagowanie na pojedyncze techniki, ale eliminowanie klas problemów, które umożliwiają ich wykorzystanie. W przypadku AD CS oznacza to między innymi usunięcie starej strony, przez którą można zrobić zapytanie o nowy certyfikat, np. do uwierzytelniania. Warto również zwrócić uwagę na fakt, że na przykład protokół uwierzytelniania NTLM, w tym NTLMv2, jest dziś mechanizmem de facto przestarzałym i systematycznie wycofywanym, a mimo to wciąż powszechnie obecnym w środowiskach enterprise. Wynika to głównie z kompatybilności wstecznej i zależności od starszych aplikacji, które nadal wymagają tego protokołu. Z mojego punktu widzenia umożliwia on absolutną większość ataków od zera do bohatera, czyli mając w zasadzie tylko dostęp do sieci, możemy przejąć najbardziej uprzywilejowane konto, czyli Domain Admin. Mam nadzieję, że każda firma w Polsce zastanawia się już, jak go usunąć, lub już to zrobiła.

Z perspektywy stratega cyberbezpieczeństwa znacznie istotniejsze od pojedynczych podatności jest utrzymywanie kontroli nad stanem środowiska w czasie. Active Directory bardzo rzadko „psuje się” jednorazowo. Zdecydowanie częściej degraduje się stopniowo, poprzez kolejne zmiany wprowadzane operacyjnie: rozszerzanie uprawnień, dodawanie wyjątków, skracanie ścieżek dostępu. Dlatego regularne wykonywanie przeglądów typu Health Check nie powinno być traktowane jako audyt, ale jako element ciągłego zarządzania ryzykiem. Ich celem nie jest znalezienie pojedynczych błędów, ale identyfikacja: nadmiarowych uprawnień, niekontrolowanych relacji zaufania, ścieżek eskalacji wynikających z konfiguracji czy odchyleń od przyjętego modelu bezpieczeństwa.

Szczególnie istotnym obszarem jest model warstwowy, czyli tzw. tiering. W poprawnie zaprojektowanym środowisku dostęp do najbardziej wrażliwych zasobów, czyli Tier 0, jest ściśle ograniczony do systemów i kont odpowiedzialnych za zarządzanie tożsamością i kontrolą domeny, takich jak kontrolery domeny, systemy zarządzania AD czy uprzywilejowane konta administracyjne. Kluczowe jest nie tylko zdefiniowanie tych poziomów, ale przede wszystkim ich egzekwowanie – brak separacji między warstwami prowadzi do sytuacji, w której kompromitacja pojedynczej stacji roboczej może zostać wykorzystana do przejęcia całej domeny. Dlatego kompromitacja domeny nie jest „kolejnym etapem” ataku. Jest logicznym zakończeniem procesu, który był możliwy od początku.

Kiedy atak już nastąpił – jaki jest najczęstszy błąd, który organizacje popełniają w pierwszych godzinach po wykryciu naruszenia?

Najgorszy błąd to działanie bez ustalenia, co dokładnie się wydarzyło, ale błędów jest wiele. Większość organizacji nie przegrywa z atakującymi dlatego, że są słabe – przegrywa dlatego, że nie widzi, dlatego chociażby z tego punktu widzenia należy jak najszybciej odizolować zainfekowane komponenty i odciąć dostęp do Internetu, aby zatrzymać potencjalne inne działania hakerów. Konieczne jest również odpowiednie zabezpieczenie dowodów (na pewno nie odtwarzanie maszyn w tym samym miejscu), ale też skupienie się na odtworzeniu usługi biznesowej. Konieczne jest również znalezienie persystencji, czyli miejsc, gdzie hakerzy mogą pozostawać w ukryciu, do czasu aż infrastruktura nie zostanie w części odtworzona i nie zostanie przywrócony dostęp do Internetu. Trzeba działać szybko, nie tylko ze względu na konieczność zmieszczenia się w 72 h, żeby zaraportować incydent oraz ogólną odpowiedzialność zarządów względem dostawców, ale również dlatego, że trzeba ustalić, co się wydarzyło, żeby móc dobrze zareagować.

Zajmuję się profesjonalnie odpowiadaniem na globalne incydenty od wielu lat i jeśli nie jesteśmy w stanie odpowiedzieć na trzy pytania:

• Co się wydarzyło?
• Gdzie to się rozprzestrzeniło?
• Do czego uzyskano dostęp, czy wyciekły dane i – jeśli tak – to jakie?

to nie ma gotowości do reagowania na incydenty. Tworzy się narrację o incydencie, zamiast nim zarządzać.

Pytanie brzmi: czy dzisiaj bylibyśmy w stanie udzielić odpowiedzi, jeśli zasymulujemy atak? W Unii Europejskiej odpowiedzi na te pytania w większym lub mniejszym stopniu są wymagane prawem.

Pamiętajmy, że podczas incydentów jedna rzecz staje się boleśnie oczywista: brak transparentności zabija reakcję. Typowe problemy to brak widoczności w logach, brak jasnej osi czasu, brak wspólnego zrozumienia sytuacji między zespołami. Nagle zamiast prowadzić analizę, zaczyna się zgadywanie. Atakujący nie muszą być niewidzialni, wystarczy, że organizacja nie widzi. Z rzeczywistych przypadków wynika, że największe wyzwania są zawsze takie same:

• Rozproszona telemetria
• Niespójne logowanie
• Brakujący lub ukryty kontekst
• Opóźniony dostęp do krytycznych danych

Dlatego transparentność nie dotyczy raportowania, tylko kontroli. Transparentność zamienia chaos w dowody, dowody w decyzje, a decyzje w działania ograniczające skutki. I to właśnie tam wygrywa się prawdziwą walkę.