Śledź Każdy zespół do spraw wykrywania zna ten moment. Reguła jest napisana lub pobrana, przejrzana, przetłumaczona na język zapytań SIEM i wdrożona. Status wskazuje, że jest włączona, liczba reguł rośnie, a raport o pokryciu staje się nieco bardziej zielony.
Żadne z tego nie mówi ci, czy reguła wykryje atak, dla którego została napisana. Reguła może być dobrze napisana i nadal niczego nie znaleźć, ponieważ jej logika, dane lub tłumaczenie cicho nie zgadza się z rzeczywistością. A ponieważ reguła, która nigdy się nie uruchamia, wygląda tak samo jak reguła, która nie ma nic do wykrycia, problem może pozostać ukryty przez długi czas.
Ten artykuł wyjaśnia, co odróżnia działającą regułę od uszkodzonej, gdzie reguły zazwyczaj się mylą i co można zrobić przy użyciu SOC Prime, aby udowodnić, że reguła działa zanim zostanie opublikowana, i aby nadal działała po wdrożeniu.
Skontaktuj się z działem sprzedaży
Co naprawdę oznacza „działanie”
Działająca reguła wykrywania robi trzy rzeczy. Wyraża właściwą logikę dla docelowego zachowania. Działa na danych, które faktycznie zawierają to zachowanie. I jest poprawnie napisana dla platformy, na której jest uruchomiona. Jeśli którakolwiek z tych trzech rzeczy zawiedzie, reguła jest uszkodzona, nawet jeśli jest włączona i nie zgłasza błędów.
To ramowanie pomaga, ponieważ każda porażka ma inną przyczynę i inny sposób naprawy:
- Problemy z logiką istnieją w samej regule. Jest zbyt wąska, aby uchwycić wariacje zachowania, lub tak szeroka, że pasuje do normalnej aktywności.
- Problemy z danymi istnieją w środowisku. Wydarzenia, których reguła potrzebuje, nie są rejestrowane, nie są zbierane lub brakuje im pól, na których opiera się reguła.
- Problemy z tłumaczeniem istnieją podczas przekształcenia między językami. Znaczenie reguły zmienia się, gdy jest zamieniane na składnię zapytań platformy.
Większość zespołów sprawdza pierwszą dokładnie, kiedy pisze regułę. Druga i trzecia to miejsca, w których reguły zwykle łamią się bez niczyjej wiedzy.
Gdzie działające reguły się mylą
Logika, która nie pasuje do zachowania. Reguła oparta tylko na nazwie pliku narzędzia jest łatwa do ominięcia przez zmianę nazwy pliku. Reguła oparta na powszechnym wzorcu linii komend, bez filtracji, może pasować do administratorów przez cały dzień. Żadna z pomyłek nie jest widoczna przy wdrożeniu. Pierwsza pojawia się, gdy napastnik przechodzi obok niej, a druga jako hałas powiadomień.
Dane, które nie są dostępne. Reguła tworzenia procesu zależna od argumentów wiersza poleceń jest bezużyteczna, jeśli rejestrowanie wiersza poleceń nie jest włączone, ponieważ zdarzenie przychodzi bez tego pola. To samo dotyczy źródła logów, które nigdy nie zostało włączone lub agenta, który przestał wysyłać dane. Reguła działa zgodnie z harmonogramem, niczego nie znajduje i wygląda na zdrową.
Pola, które znaczą różne rzeczy w różnych miejscach. To samo pojęcie może mieć różne nazwy w różnych produktach, a nawet modele danych od różnych dostawców są osobnymi umowami. Splunk CIM i Microsoft Sentinel ASIM to dobry przykład: pole, które istnieje w jednym, może nie istnieć w drugim. Przenoszenie znak po znaku daje regułę, która odwołuje się do pól, które nigdy nie są wypełniane przez miejsce docelowe.
Tłumaczenie, które zmienia znaczenie. Automatyczni tłumacze dobrze radzą sobie z prostą logiką wyboru, ale reguły korelacyjne i funkcje zastrzeżone zwykle wymagają przeglądu przez człowieka. Platformy różnią się również w sposobie traktowania szczegółów, takich jak rozróżnianie wielkości liter, dzikie karty i wyrażenia regularne. Reguła może być przetłumaczona „z powodzeniem” i wciąż zachowywać się inaczej niż oryginał.
Ograniczenia platformy, które wycofują dobre reguły. SIEM-y ograniczają liczbę reguł, które mogą działać. Zespoły rutynowo wyłączają działające reguły, aby zrobić miejsce dla nowych, przez co pokrycie maleje, nawet jeśli nikt nie decyduje, że powinno.
Dlaczego to ma znaczenie
Każdy z tych problemów pozostawia liczbę reguł i panel kontrolny niezmienione. Liczby pokrycia, które liczą wdrożone reguły, z tego powodu wyolbrzymiają poziom ochrony, a luka zwykle pojawia się podczas incydentu, gdy ktoś odkrywa, że reguła, która powinna została wywołana, nigdy nie mogła.
Istnieje drugi koszt: cicha reguła jest niejednoznaczna. Jeśli nic się nie uruchomi, czy środowisko jest czyste, czy brakuje telemetrii, czy logika jest błędna? Rozwiązywanie tego po fakcie oznacza sprawdzenie logiki, danych i tłumaczenia po kolei. Znacznie taniej jest zebrać dowody wcześniej i utrzymać je aktualne.
Jak SOC Prime pomaga ci udowodnić, że reguła działa
Walidacja wykrycia to naprawdę łańcuch pytań: czego potrzebuje ta reguła, czy moje środowisko to zapewnia, czy reguła zachowuje się zgodnie z oczekiwaniami na moich danych, a jeśli nie, co należy zmienić? SOC Prime wspiera każdy krok.
Zrozumieć wymagania dotyczące wykrycia
Walidacja rozpoczyna się przed jakimikolwiek testami. SOC Prime dostarcza kontekstowych informacji na temat zawartości wykrywania, w tym zamierzonego zachowania, wymagań telemetrii, mapowania MITRE ATT&CK, potencjalnych fałszywych alarmów i innych metadanych. Daje to inżynierom wykrywania punkt wyjścia do decydowania, czy wykrywanie ma zastosowanie do ich środowiska oraz jakie warunki muszą być spełnione przed przetestowaniem. Reguła, która potrzebuje rejestrowania wiersza poleceń, na przykład, informuje o tym z góry, zamiast zostawiać cię do odkrycia tego później.
Oceniać dostępną telemetrię
Kiedy wiesz, czego potrzebuje reguła, kolejny pytanie brzmi, czy to masz. Prime Hunt może pomóc zespołom ocenić związek między dostępnymi danymi a potencjalnym pokryciem wykryciem. Audyt danych analizuje dostępne dane logów i mapuje je do MITRE ATT&CK, aby zidentyfikować potencjalne luki w widoczności. Pomaga to określić, czy brak pokrycia wykrycia pochodzi z brakującej telemetrii, a nie brakującej zawartości wykrycia, co są dwoma bardzo różnymi problemami z dwoma bardzo różnymi rozwiązaniami.
Testuj wykrycia na danych organizacyjnych
Prime Hunt może również przeprowadzać skanowanie wykrywania na danych z podłączonych środowisk. Testowanie wykryć na rzeczywistych danych dostarcza dowodów, jak zawartość zachowuje się w twoim środowisku, zamiast polegać tylko na teoretycznej walidacji. Wyniki skanowania pomagają identyfikować wykrycia, które produkują istotne dopasowania, oraz wyróżniają te wymagające dalszego dochodzenia lub dostrojenia.
Badaj i poprawiaj logikę wykrywania
Kiedy wykrycie wymaga modyfikacji, SOC Prime dostarcza możliwości inżynierii wykrywania poprzez Prime Core i Prime Architect. Zawartość wykrycia może być przeglądana, dostosowywana, tłumaczona i optymalizowana pod kątem docelowego środowiska. To rozwiązuje różnice w schematach, mapowaniu pól, językach zapytań i wymaganiach specyficznych dla środowiska, bez traktowania każdego problematycznego wykrycia jako zupełnie nowe zadanie rozwojowe.
W praktyce oznacza to:
- Przetłumacz na platformę, na której działasz. Wszystkie zasady Sigma na platformie są już przetłumaczone na wszystkie obsługiwane języki i formaty SIEM, więc możesz pobrać zapytanie dla swojego stosu i wdrożyć je od razu. W przypadku wszystkiego, co jest niestandardowe, lub dla własnych zasad Sigma, użyj obszaru roboczego Translation w Prime Architect, aby przekonwertować je na rodzimy język zapytań twojego SIEM, EDR, XDR lub jeziora danych. Sigma pozostaje źródłem, więc zmiana wprowadzona raz może być ponownie przetłumaczona zamiast być edytowana ręcznie na każdej platformie.
- Mapuj tabele, pola i wartości do swojego schematu. Mapowanie Pola niestandardowego pozwala zdefiniować profile, które mapują twoje niestandardowe tabele, pola i wartości do domyślnych. Stwórz jeden profil, a następnie zastosuj go za każdym razem, gdy wdrażasz regułę lub wysyłasz zapytanie.
- Dodaj filtry, które pasują do twojego środowiska. Filtry dodają warunki do logiki wykrywania przed wdrożeniem, aby uwzględnić lub wykluczyć konkretnych użytkowników, hostów lub inne zbiory elementów. Uniemożliwiają one znanej-benign aktywności zamianę dobrej reguły na hałaśliwą, bez przepisania samej reguły.
- Zapisuj ustawienia wdrożenia jako predefiniowane wartości. Prefiksy zapisują parametry, takie jak okres zapytań, ważność i status reguły, aby wdrożenia były spójne.
- Waliduj, optymalizuj i dopasuj do potrzeb. Obszar roboczy Translation również weryfikuje i optymalizuje zawartość wykrywania. Nie zastępuje to przeglądu: sprawdź każde pole w odniesieniu do schematu miejsca docelowego i dokładnie przyjrzyj się wszystkiemu, co zostało oznaczone, zwłaszcza logice korelacyjnej i funkcjom specyficznym dla platformy. Gdy zmiana wykracza poza mapowanie i filtry, edytuj kod bezpośrednio, przetłumacz go ponownie i zapisz w swoim repozytorium niestandardowym jako aktualizację lub nową regułę.
- Badanie i dostosowanie z pomocą AI w obszarze roboczym. Użyj tego do badania zachowania, które osiąga reguła i pracuj nad zmianami w jej logice. Inżynierowie zachowują kontrolę i przeglądają wszelkie zmiany przed ich wdrożeniem.
Identyfikacja luk w pokryciu
Walidacja wykrycia powinna również odpowiedzieć, co nie jest wykrywane. Audyt Danych w Prime Hunt dostarcza analizy pokrycia na podstawie zarówno dostępnej telemetrii, jak i zawartości wykrywania. Pomaga to zespołom rozróżniać luki spowodowane niewystarczającą widocznością i luki spowodowane brakującymi lub nieodpowiednimi regułami wykrywania. Ta różnica informuje o kolejnych działaniach inżynieryjnych: zebranie większej ilości danych, dostrojenie istniejącego wykrycia lub zidentyfikowanie i opracowanie dodatkowej zawartości wykrywania.
Kontynuowanie walidacji w czasie
Skuteczność wykrywania zmienia się wraz z ewolucją środowisk i zawartości wykrywania. Powtarzająca się walidacja z Prime Hunt pozwala zespołom ponownie ocenić wykrycia na podstawie aktualnych danych, zamiast polegać na pierwotnym wyniku walidacji na zawsze. To ma największe znaczenie w środowiskach, gdzie konfiguracje dzienników, schematy danych, infrastruktura lub zawartość wykrywania zmieniają się często.
Dowody nad założeniami
Wdrożona reguła to twierdzenie. Reguła przetestowana na rzeczywistych danych to dowody. Różnica jest łatwa do przeoczenia, ponieważ obie wyglądają tak samo na liście reguł i obie są ciche, dopóki nie nadejdzie atak.
SOC Prime pomaga zespołom zamknąć tę lukę. Zaczyna się od jasnych wymagań dotyczących wykrywania i uczciwego spojrzenia na dostępną telemetrię, testuje wykrycia na twoich własnych danych i daje ci narzędzia do naprawy tego, co nie pasuje. Analiza pokrycia następnie pokazuje, czy pozostałe luki wymagają większej ilości danych, lepszego dostrojenia czy nowej zawartości, a powtarzająca się walidacja utrzymuje odpowiedź aktualną, gdy twoje środowisko się zmienia. Zacznij od reguł, które mają największe znaczenie, i dowiedz się, które naprawdę by się uruchomiły.
