Wykrywanie zagrożeń i reagowanie na punktach końcowych w sieciach wojskowych: EDR w środowiskach niejawnych

Przeciwnik z trwałym dostępem do niejawnej wojskowej stacji roboczej nie ogłasza swojej obecności. Działa po cichu wewnątrz legalnych drzew procesów, nadużywa zaufanych plików binarnych systemu i przemieszcza się bocznie po enklawie, korzystając z protokołów wyglądających jak zwykły ruch administracyjny. Endpoint detection and response (EDR) to dyscyplina stworzona w celu wykrywania tego rodzaju aktywności: zbierania szczegółowej telemetrii z każdego punktu końcowego, stosowania modeli behawioralnych do identyfikacji wzorców ataku oraz zapewniania analitykom widoczności na poziomie procesów niezbędnej do ustalenia zakresu i izolacji kompromitacji. Wdrożenie EDR w niejawnych środowiskach wojskowych zmusza jednak do ponownego przeanalizowania każdego założenia architektonicznego przyjętego przez dostawców komercyjnych -- od potoku telemetrii chmurowej po model subskrypcji informacji o zagrożeniach. Niniejszy artykuł analizuje ograniczenia sieci niejawnych kształtujące architekturę EDR, mechanizmy detekcji najistotniejsze wobec zaawansowanych zagrożeń oraz ścieżkę integracji EDR z wojskowym SIEM i zautomatyzowanym reagowaniem na incydenty.

Dlaczego komercyjne produkty EDR zawodzą w niejawnych środowiskach wojskowych

Komercyjny rynek EDR opiera się na wspólnym założeniu architektonicznym: agent na punkcie końcowym przesyła telemetrię do hostowanego przez dostawcę analitycznego zaplecza chmurowego, gdzie w skali odbywa się polowanie na zagrożenia, wnioskowanie z modeli uczenia maszynowego i korelacja informacji o zagrożeniach. Model ten zapewnia możliwości wykrywania w czasie rzeczywistym klientom korporacyjnym z punktami końcowymi podłączonymi do internetu, ale fundamentalnie nie może działać w niejawnej enklawie wojskowej. Sieci izolowane fizycznie, ścisłe filtrowanie ruchu wychodzącego i wymagania dotyczące obsługi danych na poziomie klauzuli tajności uniemożliwiają jakikolwiek wychodzący strumień telemetrii do chmury komercyjnej. W chwili zerwania połączenia sieciowego większość zdolności detekcyjnych komercyjnego produktu EDR zostaje uśpiona.

Poza kwestią łączności, komercyjne produkty EDR są zależne od ciągłych aktualizacji zarządzanych przez dostawcę: codziennych lub godzinowych kanałów sygnatur, ponownego trenowania modeli behawioralnych na korpusie informacji o zagrożeniach dostawcy i automatycznych aktualizacji agenta przesyłanych przez internet. W środowisku niejawnym każda aktualizacja oprogramowania musi przejść przez zatwierdzone rozwiązanie między domenami lub zostać dostarczona na nośniku wymiennym zgodnie z procedurami integralności dwuosobowej. Cykle aktualizacji, które produkty komercyjne obsługują automatycznie w ciągu minut, rozciągają się na tygodnie w środowiskach niejawnych. Kanał sygnatur z 30-dniowym opóźnieniem jest operacyjnie bezużyteczny wobec przeciwnika z poziomu państwa, który nieustannie rotuje narzędziami. EDR wdrożony w środowiskach niejawnych musi być zatem zaprojektowany od podstaw z myślą o pracy offline, a aktualizacje informacji o zagrożeniach traktowane jako celowe, audytowalne działanie w łańcuchu dostaw, a nie transakcja sieciowa działająca w tle.

Istnieje również wymiar licencjonowania i dostępu dostawcy, który otrzymuje mniej uwagi niż ograniczenia techniczne. Wiele komercyjnych produktów EDR przyznaje dostawcy bieżący zdalny dostęp do konsoli zarządzania lub konfiguracji agenta w celach wsparcia i rozwiązywania problemów. W systemie niejawnym zdalny dostęp dostawcy jest albo całkowicie zabroniony, albo wymaga niezwykle restrykcyjnej umowy o kontrolowanym dostępie, której większość dostawców komercyjnych nie jest w stanie lub nie chce obsługiwać. Zbudowane celowo lub o otwartej architekturze frameworki EDR, które klient kontroluje w całości -- w tym infrastrukturę zarządzania, model detekcji i potok aktualizacji -- są jedynym architektonicznie czystym rozwiązaniem dla najbardziej wrażliwych programów niejawnych.

Architektura agenta EDR: zbieranie telemetrii bez ryzyka eksfiltracji danych

Agent EDR to składnik oprogramowania na poziomie jądra lub hiperwizora, instalowany na każdym punkcie końcowym, który instrumentuje system operacyjny do rejestrowania zdarzeń istotnych dla bezpieczeństwa: tworzenia i zakończenia procesów z pełnymi argumentami wiersza poleceń, zapisów plików do lokalizacji plików wykonywalnych i skryptów, modyfikacji rejestru dla ścieżek kluczy trwałości, połączeń sieciowych z adresem i portem docelowym oraz zdarzeń ładowania sterowników i bibliotek DLL z informacjami o skrócie i podpisie. W środowisku niejawnym agent musi realizować tę instrumentację bez tworzenia jakiegokolwiek ryzyka eksfiltracji danych, co oznacza, że potok telemetrii musi być całkowicie wewnętrzny w stosunku do niejawnej enklawy, a agent musi być w weryfikowalny sposób wolny od nieujawnionych kanałów komunikacji sieciowej.

Wdrożenie agenta na niejawnych wojskowych punktach końcowych wymaga procesu łańcucha dostaw oprogramowania znacznie bardziej rygorystycznego niż komercyjna praktyka korporacyjna. Plik binarny agenta musi zostać poddany przeglądowi -- poprzez audyt kodu źródłowego, analizę binarną lub obie metody -- w celu potwierdzenia, że nie zawiera kanałów telemetrycznych innych niż udokumentowane, żadnych automatycznych mechanizmów aktualizacji ani żadnego materiału kryptograficznego, który mógłby służyć do nawiązania ukrytej komunikacji. Przegląd ten musi być powtarzany dla każdej aktualizacji wersji agenta przed wdrożeniem. Obciążenie przeglądem jest głównym powodem, dla którego niejawne wdrożenia EDR preferują frameworki o otwartej architekturze, w których klient ma dostęp do pełnej bazy kodu, zamiast komercyjnych agentów typu czarna skrzynka, których wewnętrzne zachowanie musi być wnioskowane z monitorowania zachowania.

Zakres zbierania telemetrii musi być starannie dostrojony dla środowiska niejawnego. Zbieranie surowej zawartości plików lub pełnych zrzutów pamięci w strumieniowym potoku telemetrii jest operacyjnie niewskazane: objętość jest ekstremalna, klasyfikacja zebranego materiału może być wyższa niż własny poziom klasyfikacji punktu końcowego, a infrastruktura pamięci masowej i przetwarzania wymagana do obsługi pełnego strumienia telemetrii w skali może nie być dostępna w enklawie. Produkcyjne niejawne wdrożenia EDR zbierają ustrukturyzowane rekordy zdarzeń -- drzewa procesów, podsumowania przepływów sieciowych, rekordy ścieżek plików i skrótów -- i rezerwują pozyskiwanie surowej pamięci dla kryminalistyki na żądanie wyzwalanej potwierdzonym alertem. Ta architektura utrzymuje ciągłą objętość telemetrii w zarządzalnym zakresie, zachowując jednocześnie zdolność do zbierania bogatych danych kryminalistycznych, gdy są rzeczywiście potrzebne.

Detekcja behawioralna a dopasowanie sygnatur: co każda wykrywa, a co pomija

Dopasowanie sygnatur -- porównywanie skrótów plików lub sekwencji bajtów z bazą danych znanych złośliwych artefaktów -- jest szybkie, nie generuje fałszywych alarmów dla rozpoznanych zagrożeń i nakłada minimalne obciążenie obliczeniowe na punkt końcowy. Jest również strukturalnie ślepe na każde zagrożenie, które nie pasuje do znanych sygnatur: nowe złośliwe oprogramowanie, zmodyfikowane lub przekompilowane narzędzia, bezplikowe techniki ataku wykonywane wyłącznie z pamięci i techniki living-off-the-land uzbrajające legalne pliki binarne systemu operacyjnego, które nigdy nie pojawią się w żadnej bazie sygnatur złośliwego oprogramowania. Wobec przeciwnika z poziomu państwa działającego przeciwko niejawnym systemom wojskowym, samo dopasowanie sygnatur zapewnia zasadniczo zerowe pokrycie detekcyjne dla początkowego włamania, które niezmiennie wykorzystuje specjalnie zbudowane narzędzia, nieobserwowane wcześniej.

Detekcja behawioralna porzuca pytanie, czy konkretny plik binarny jest znany jako złośliwy, na rzecz pytania, czy sekwencja działań na poziomie systemu stanowi znane techniki ataku. Proces, który tworzy proces potomny z zakodowanym w base64 argumentem wiersza poleceń, który następnie nawiązuje połączenie sieciowe z zewnętrznym adresem IP, który następnie zapisuje bibliotekę DLL do katalogu systemowego, wykazuje wzorzec behawioralny związany z dropperem niezależnie od tego, czy którykolwiek z zaangażowanych plików binarnych był kiedykolwiek wcześniej widziany. Reguły detekcji behawioralnej są wyrażone w kategoriach drzew procesów, sekwencji zdarzeń i wzorców wywołań systemowych, i generalizują się na całą rodzinę narzędzi implementujących daną technikę. Framework MITRE ATT&CK zapewnia ustrukturyzowaną taksonomię technik przeciwnika, która służy jako słownik referencyjny do tworzenia reguł detekcji behawioralnej, odwzorowując każdą technikę na obserwowalne zdarzenia telemetryczne zdradzające jej użycie.

Praktycznym ograniczeniem detekcji behawioralnej są fałszywe alarmy. Legalne narzędzia administracyjne, agenci zarządzania poprawkami i instalatory aplikacji misyjnych generują wzorce drzew procesów, które powierzchownie przypominają techniki ataku. Skrypt PowerShell, który odczytuje dane z udziału sieciowego, dekoduje ciąg base64 i wywołuje zestaw .NET, jest albo narzędziem do wdrażania oprogramowania, albo dropperem złośliwego oprogramowania -- sygnatura behawioralna jest identyczna. Zarządzanie fałszywymi alarmami na niejawnych wojskowych punktach końcowych wymaga gruntownego ćwiczenia bazowego: uruchomienia silnika detekcji behawioralnej w trybie audytu przez tygodnie w celu zmapowania pełnego zakresu legalnej aktywności na każdej klasie punktów końcowych, a następnie tworzenia reguł tłumienia pokrywających znane prawidłowe wzorce przy jednoczesnym zachowaniu detekcji tych samych wzorców w nieoczekiwanych kontekstach. Ta praca dostrajania jest pracochłonna i musi być ponawiana za każdym razem, gdy linia bazowa oprogramowania na punktach końcowych zmienia się znacząco.

Kryminalistyka pamięci i wykrywanie wstrzyknięć procesów na wojskowych punktach końcowych

Złośliwe oprogramowanie bezplikowe i zaawansowane implanty działają wyłącznie w obrębie pamięci ulotnej działających procesów, nie zapisując żadnych plików na dysku, które tradycyjne narzędzia bezpieczeństwa punktów końcowych mogłyby wykryć. Implant załadowany przez refleksyjne wstrzyknięcie DLL do legalnego procesu, takiego jak przeglądarka lub aplikacja misyjna, będzie działał bezterminowo bez tworzenia jakiegokolwiek artefaktu na dysku. Jedynym niezawodnym sposobem wykrycia takiego implantu jest bezpośrednia inspekcja pamięci działających procesów -- poszukiwanie wykonywalnych regionów pamięci niepowiązanych z żadnym plikiem na dysku, łańcuchów hooków API przekierowujących wywołania systemowe przez kod kontrolowany przez atakującego oraz rozbieżności między obrazami w pamięci i na dysku załadowanych bibliotek. Kryminalistyka pamięci nie jest zatem opcjonalnym ulepszeniem możliwości niejawnych wojskowych wdrożeń EDR -- jest podstawową warstwą detekcji dla najbardziej wyrafinowanych i trwałych zagrożeń, z jakimi mierzy się to środowisko.

Wykrywanie wstrzyknięć procesów koncentruje się na konkretnym zestawie dobrze scharakteryzowanych technik. Refleksyjne wstrzyknięcie DLL ładuje bibliotekę do przestrzeni adresowej procesu, wykonując samodzielny stub ładujący, który rozwiązuje importy i stosuje relokacje bez użycia standardowego programu ładującego systemu operacyjnego -- pozostawiając region pamięci, który jest wykonywalny, zapisywalny i niemapowany do żadnego pliku. Drążenie procesów zastępuje obraz wykonywalny nowo utworzonego legalnego procesu złośliwym kodem przed wznowieniem wykonania, tworząc proces, którego obraz na dysku nie pasuje do jego wykonywalnej zawartości w pamięci. Przejęcie wątku wstrzykuje kod do kontekstu wykonania istniejącego wątku przez modyfikację zapisanego stanu rejestru wątku. Każda z tych technik pozostawia charakterystyczny ślad pamięci, który agent EDR może wykryć przez przechodzenie przestrzeni adresowej procesu, sprawdzanie atrybutów regionów pamięci i porównywanie wykonywalnej zawartości w pamięci z obrazem na dysku odpowiedniego pliku. Na niejawnych wojskowych punktach końcowych, gdzie linia bazowa procesów jest stosunkowo stabilna i dobrze rozumiana, te kontrole mają wysoką wierność sygnału przy zarządzalnym współczynniku fałszywych alarmów.

Przepływy izolacji: odizolowanie skompromitowanego punktu końcowego bez zakłócania operacji

Pierwszym odruchem po wykryciu potwierdzonej kompromitacji jest odłączenie kabla sieciowego -- pełna izolacja, natychmiast. Ta odpowiedź jest operacyjnie właściwa dla korporacyjnego środowiska IT, gdzie stacje robocze są wymienne. W niejawnym środowisku wojskowym skompromitowany punkt końcowy może obsługiwać aktywną aplikację C2 zasilającą misję, proces agregacji danych z czujników, usługę zarządzania kluczami kryptograficznymi lub przekaźnik komunikacyjny. Pełna izolacja sieciowa tego hosta może być operacyjnie równoważna zniszczeniu sprzętu w trakcie misji. Decyzja o izolacji musi zatem uwzględniać rolę operacyjną zaatakowanego hosta, a platforma EDR musi obsługiwać stopniowane polityki izolacji równoważące odpowiedź na zagrożenie z ciągłością operacyjną.

Stopniowany model izolacji stosuje ukierunkowane odcinanie zamiast blankietowego blokowania sieci. Najczęstszymi wektorami propagacji ataku ze skompromitowanego punktu końcowego są udziały plików SMB, kanały zdalnego wykonania kodu RPC i DCOM oraz narzędzia ruchu bocznego wykorzystujące protokoły administracyjne. Zablokowanie tych konkretnych protokołów na zaporze hosta -- przy jednoczesnym zachowaniu przepływów warstwy aplikacji, których punkt końcowy potrzebuje do swojej funkcji operacyjnej (strumień danych serwera TAK, interfejs czujnika, łączność głosowa) -- zakłóca zdolność atakującego do przemieszczania się bocznie, utrzymując host w sprawności operacyjnej. Agent EDR egzekwuje tę politykę na poziomie Windows Filtering Platform lub iptables, stosując reguły podpisane kryptograficznie przez konsolę zarządzania, które nie mogą być usunięte przez proces działający w przestrzeni użytkownika, nawet przez proces działający na skompromitowanym koncie administratora.

Tworzenie procedur izolacji wymaga ścisłej koordynacji między zespołem obrony cybernetycznej a personelem operacyjnym rozumiejącym, co każda klasa stacji roboczych rzeczywiście robi w sieci. Wstępnie zatwierdzony profil izolacji dla każdej roli punktu końcowego -- stacja robocza, serwer uwierzytelniania, agregator czujników, terminal C2 -- powinien istnieć przed jakimkolwiek incydentem, sprawdzony i zatwierdzony zarówno przez oficera bezpieczeństwa, jak i dowódcę operacyjnego. Gdy pojawi się potwierdzony alert, analityk wybiera odpowiedni wstępnie zatwierdzony profil izolacji z procedury SOAR zamiast improwizować niestandardową politykę odizolowania pod presją czasu. Czas od potwierdzenia alertu do zastosowania polityki izolacji powinien wynosić poniżej pięciu minut, a procedura wycofania przywracająca pełny dostęp sieciowy powinna być udokumentowana i możliwa do wykonania w poniżej dwóch minut, aby wspierać szybkie odtwarzanie operacyjne po zakończeniu dochodzenia.

Integracja z wojskowym SIEM i zautomatyzowana orkiestracja reagowania

Telemetria EDR jest najbardziej wartościowa, gdy jest korelowana z danymi z innych czujników bezpieczeństwa: rekordów przepływów sieciowych, dzienników zdarzeń uwierzytelniania, wyników skanowania podatności i danych kontroli dostępu fizycznego. Wojskowy SIEM jest punktem integracji, gdzie te strumienie danych się zbiegają, a jakość integracji EDR z SIEM decyduje o tym, czy analitycy mogą zbudować kompletny obraz incydentu obejmującego wiele punktów końcowych i segmentów sieci. Zdarzenia EDR muszą być przekazywane do SIEM w formacie, który czysto odwzorowuje się na wspólny schemat zdarzeń SIEM, z identyfikatorami procesów, identyfikatorami hostów i znacznikami czasu znormalizowanymi tak, aby zdarzenie wykonania procesu z EDR mogło być automatycznie połączone z odpowiednim zdarzeniem uwierzytelniania w dzienniku zdarzeń bezpieczeństwa Windows i odpowiednim rekordem przepływu sieciowego z zapory. Bez tej warstwy normalizacji zapytania korelacyjne wymagają ręcznego mapowania pól, co wprowadza opóźnienia i błędy analityka do procesu ustalania zakresu incydentu.

Zautomatyzowana orkiestracja reagowania -- warstwa SOAR ponad SIEM -- zamyka pętlę od detekcji do izolacji bez konieczności zatwierdzania każdego indywidualnego działania przez człowieka. W przypadku dobrze scharakteryzowanych typów alertów o wysokiej pewności zautomatyzowane reagowanie skraca czas od detekcji do izolacji z godzin (oczekiwanie na przetworzenie kolejki alertów przez analityka) do sekund. Standardowymi kandydatami do automatyzacji w niejawnym wojskowym wdrożeniu EDR są: kill procesu i kwarantanna dla wykryć wykonania złośliwego oprogramowania powyżej progu pewności, blokowanie ruchu bocznego na poziomie hosta dla wykryć kradzieży danych uwierzytelniających oraz zbieranie migawek do przeglądu kryminalistyki pamięci po wykryciu anomalicznego regionu pamięci. Każde zautomatyzowane działanie musi być zarejestrowane z identyfikatorem wyzwalającego alertu, konkretnym podjętym działaniem i potwierdzeniem agenta, że działanie zostało zastosowane, tworząc ścieżkę audytu wspierającą przegląd po incydencie i formalne wymagania sprawozdawcze wojskowego reagowania na incydenty cybernetyczne.

Architektura integracji SIEM i SOAR dla sieci wojskowych musi również uwzględniać poziom klauzuli tajności samej telemetrii EDR. Zdarzenia tworzenia procesów rejestrujące pełne argumenty wiersza poleceń każdego procesu na niejawnym punkcie końcowym mogą same zawierać informacje niejawne: ścieżki plików do danych niejawnych, nazwy użytkowników personelu z poświadczeniami bezpieczeństwa i fragmenty nazw dokumentów niejawnych. Potok telemetrii musi klasyfikować każdy rekord zdarzenia na odpowiednim poziomie i obsługiwać go stosownie, co w praktyce oznacza, że zarówno konsola zarządzania EDR, jak i SIEM muszą być akredytowane na najwyższym poziomie klauzuli tajności dowolnego monitorowanego przez nie punktu końcowego. Budowanie jednolitej platformy EDR obejmującej wiele poziomów klauzuli tajności jest technicznie złożone i zazwyczaj realizowane przez model oddzielnych instancji z jednokierunkowym eksportem danych przez zatwierdzone rozwiązanie między domenami.

Wyzwania akredytacyjne: przeprowadzenie EDR przez proces zatwierdzania systemu niejawnego

Uzyskanie autoryzacji operacyjnej (ATO) dla wdrożenia EDR w niejawnym systemie wojskowym jest jednym z najbardziej czasochłonnych i technicznie wymagających ćwiczeń akredytacji oprogramowania w sektorze obronnym. Podstawowym wyzwaniem jest to, że EDR z założenia jest uprzywilejowanym składnikiem systemu z dostępem na poziomie jądra do każdego procesu, pliku i połączenia sieciowego na hoście. Agent EDR zawierający nieujawnioną funkcjonalność -- ukryty kanał, ukryty strumień telemetrii lub zdolność do zdalnego wykonania -- stanowiłby katastrofalne naruszenie łańcucha dostaw całej niejawnej enklawy. Organ akredytacji wymaga zatem poziomu weryfikacji gwarancji oprogramowania, który wykracza daleko poza to, co jest stosowane do większości oprogramowania warstwy aplikacji: pełny przegląd kodu źródłowego (lub, dla produktów wyłącznie binarnych, binarna analiza statyczna połączona z dynamicznym monitorowaniem zachowania), kryptograficzny proces weryfikacji kompilacji i zdefiniowana procedura weryfikacji każdej aktualizacji przed jej zastosowaniem na niejawnych punktach końcowych.

Behawioralne modele detekcji i zestawy reguł w systemie EDR tworzą wtórne obawy akredytacyjne, które są mniej oczywiste, ale równie ważne. Reguły detekcji kodują wiedzę o tym, co stanowi anomalne zachowanie na niejawnych punktach końcowych -- które procesy uzyskują dostęp do których plików, które połączenia sieciowe są oczekiwane, które ścieżki rejestru są modyfikowane przez legalne operacje. Jeśli przeciwnik uzyska kopię zestawu reguł detekcji, zyskuje precyzyjną specyfikację, jakie zachowania EDR będzie i nie będzie oznaczać, co umożliwia mu projektowanie operacji włamaniowych pozostających całkowicie w białej przestrzeni reguł. Reguły detekcji i modele behawioralne muszą zatem być klasyfikowane na odpowiednim poziomie i traktowane jako wrażliwe dane konfiguracyjne, z ścisłą kontrolą dostępu i procesem zarządzania zmianami śledzącym każdą modyfikację.

Praktyczne harmonogramy akredytacji EDR w systemach niejawnych zazwyczaj trwają od 12 do 24 miesięcy dla nowych produktów, które nie były wcześniej oceniane. Produkty, które już ukończyły ocenę dla jednego niejawnego programu, mogą czasem wykorzystać wcześniejsze artefakty oceny do przyspieszenia kolejnych akredytacji -- proces formalizowany przez US DoD w ramach Continuous ATO (cATO) dla narzędzi cyberbezpieczeństwa. Wybór produktu lub frameworku EDR posiadającego już doświadczenie w niejawnych wdrożeniach systemowych i istniejącą dokumentację oceny znacznie skraca harmonogram akredytacji. Dla programów, które nie mogą czekać na pełne ATO, obsługa EDR w trybie tylko monitorowania (zbieranie i analiza telemetrii bez automatycznego reagowania) na podstawie tymczasowego zezwolenia na testy (IATT) pozwala zespołowi operacji bezpieczeństwa rozpocząć budowanie zdolności detekcji i linii bazowej behawioralnej podczas przetwarzania pełnego ATO.