Śledź Weryfikacja detekcji to praktyka udowadniania, że reguła detekcji nadal reaguje na zdarzenia, do których została stworzona. Dekay detekcji to cicha awaria reguły, która wcześniej działała, po tym, jak zmienia się źródło logów, schemat lub parser. Reguła wdrożona i aktywna to nie reguła, która udowodniła swoje działanie.
Jak możesz wiedzieć, czy reguła detekcji nadal działa?
Reguła działa, jeśli uruchamia się na znanym zdarzeniu w zdefiniowanym oknie czasowym. Wszystko inne to przypuszczenie.
Większość zespołów traktuje 'wdrożona i aktywna’ jako stan działania: reguła istnieje w SIEM, przechodzi weryfikację w momencie wdrażania, mapa pokrycia pozostaje zielona. Status wykonania i status pokrycia mierzą obecność, nie funkcjonalność. Reguła, która wykonuje się pomyślnie na pustym zestawie wyników, wygląda z perspektywy platformy tak samo, jak reguła obserwująca cichą sieć. Dashboard pozostaje zielony w obu przypadkach.
Uczciwa drabina dowodowa ma pięć poziomów, od najsłabszego do najsilniejszego:
| Poziom | Stan | Co udowadnia | Czego NIE udowadnia |
|---|---|---|---|
| 0 | Zadeklarowane | Reguła istnieje | Nic na temat funkcji |
| 1 | Przeszło lint | Prawidłowo analizuje, wymagane bloki są obecne, pola istnieją w docelowym schemacie | Że pasuje do czegokolwiek |
| 2 | Przegrana atrapa | Dopasowuje zarejestrowane znane złe zdarzenia, odrzuca sparowane łagodne atrapy (offline) | Że uruchamia się w działającym kanale |
| 3 | Zweryfikowane emulacją | Uruchamia się od końca do końca przeciwko emulowanym rzeczywistym procedurom (Atomic Red Team or MITRE Caldera) w wdrożonym kanale | Że rzeczywista procedura przeciwników emituje to zdarzenie w środowisku z taką konfiguracją systemu operacyjnego i dzienników |
| 4 | Przeszło produkcję | Wywołano przy rzeczywistej działalności przeciwników lub zespołu czerwonego z zapisem decyzji | Najwyższy poziom |
Reguła, która analizuje, to nie reguła, która pasuje. Reguła, która pasuje do testowej atrapy, to nie reguła, która uruchamia się w produkcji. Luka między poziomem 1 a poziomem 3 to miejsce, gdzie żyją ukryte awarie: reguła może czysto analizować i odwoływać się do prawidłowych pól, zwracając zero dopasowań, ponieważ pole na którym się opiera jest puste, przekształcone lub teraz wypełnione inną semantyką niż ta, do której reguła została napisana.
Skąd mam wiedzieć, które z moich reguł detekcji przestały działać bezgłośnie?
Cztery niezależne sygnały ujawniają ukryte awarie reguł w Splunk, Microsoft Sentinel, i Elastic Security. Żaden pojedynczy sygnał nie jest wystarczający sam.
Bazowanie na współczynniku uruchomień
Porównaj aktualny współczynnik uruchomień każdej reguły z jej własnym ostatnim poziomem bazowym. Powiadom o spadku do zera lub utrzymującym się spadku znacznie poniżej tego poziomu bazowego w określonym oknie.
Gdzie znajdują się dane:
| Platforma | Dane o współczynniku uruchomień | Metadane dotyczące zdrowia i wykonania |
|---|---|---|
| Splunk | index=notable | index=_internal sourcetype=scheduler, index=_audit |
| Microsoft Sentinel | Tabele SecurityAlert, SecurityIncident | Tabela SentinelHealth .alerts-security.alerts-* |
| Elastic Security | .alerts-security.alerts-* | Zakładka Monitoring strony reguł (logi wykonania reguł, 8.x+) |
Znane ograniczenia: Bazowanie na współczynniku uruchomień nie działa dla reguł o niskim współczynniku bazowym, których normalny stan to zero uruchomień przez tygodnie. Reguła, która prawidłowo uruchamia się dwa razy w roku, nie może być monitorowana wyłącznie przez współczynnik uruchomień. Dlatego istnieją kolejne trzy sygnały.
Zdarzenia kanarek
Wstrzykuj syntetyczne zdarzenie, które jest znane jako dopasowanie do reguły. Potwierdź, że reguła uruchamia się od początku do końca. Jest to wzorzec, a nie funkcja natywna produktu.
| Platforma | Powierzchnia iniekcji | Powierzchnia weryfikacji |
|---|---|---|
| Splunk | Kolektor zdarzeń HTTP (HEC) | index=notable |
| Microsoft Sentinel | API ingerencji logów za pomocą reguły zbierania danych do niestandardowej tabeli | Tabela SecurityAlert |
| Elastic Security | Zbiorczy lub _doc index API do monitorowanego indeksu | .alerts-security.alerts-* |
Zdarzenia kanarek udowadniają zasięg: zdarzenie przetrwało procesy zbierania, parsowania, normalizacji i reguła je dopasowała. Nie dowodzą zachowania: rzeczywista procedura przeciwnika może produkować inną telemetrię niż zakładał kanarek.
Okresowe odtwarzanie
Uruchom ponownie regułę na danych historycznych (prawdziwych przeszłych zdarzeniach lub zapisanym pozytywnym przykładzie). Upewnij się, że nadal wywołuje alerty.
Odtwarzanie musi być skierowane do oznaczonego lub nie-paginacyjnego zlewu. Bez kontrolek idempotencji, walidacja odtwarzania tworzy duplikaty zdarzeń i generuje fałszywe strony SOC.
Natywne wsparcie jest różne. Elastic Security (8.x+) ma ręczne i obejmujące luki mechanizmy dla reguł detekcji. Splunk wspiera ponowne uruchamianie wyszukiwania w historycznym zakresie czasu. Microsoft Sentinel nie ma natywnego odtwarzania reguł analitycznych.
Alerty o dryfie schematu
Wykrywaj, że kształt danych przychodzących uległ zmianie (pole zostało zmienione nazwa, usunięte, zmienione typ lub nowa wartość enum), zanim reguła cicho się na nim zawiesi.
| Platforma | Powierzchnia wykrywania dryfu |
|---|---|
| Splunk | Poglądy audytowe modelu danych CIM w Enterprise Security, ekstrakcje pól |
| Microsoft Sentinel | Tabela SentinelHealth tabela, kontrolna karta zdrowia zbierania danych. Kolumna, która przestaje być wypełniana, pokazuje się jako rosnące wartości null, a nie błąd schematu |
| Elastic Security | Konflikty mapowania w zarządzaniu indeksami, Elastic Common Schema (ECS) zgodność |
Bazowanie na współczynniku uruchomień jest niezbędne i niewystarczające. Użyj wszystkich czterech.
Prime Hunt audytowanie treści automatycznie mapuje już uruchomione przez ciebie reguły do MITRE ATT&CK, a jego zautomatyzowane wyszukiwanie zagrożeń poszukuje najnowszych TTPs w twoich połączonych środowiskach bez przenoszenia danych.
Skontaktuj się z działem sprzedaży
Dlaczego reguły detekcji przestają działać?
Pięć mechanizmów powoduje cichy dekay. W każdym przypadku reguła nadal wykonuje się, zwraca zero dopasowań, a status wykonania pozostaje zielony. Nie ma rzucania błędu, a mapa pokrycia nie zmienia się.
1. Zmiana wersji źródła logów. Źródło wysyła nową wersję logu i zmienia semantykę istniejącego pola. Przykład: dostawca tożsamości łączy wynik uwierzytelniania z trzech stanów (sukces, niepowodzenie, wyzwanie) do dwóch (sukces, niepowodzenie). Reguła wykrywająca obejście MFA przez poszukiwanie „sukcesu bez poprzedzającego wyzwania” nie może już odróżnić normalnego przepływu MFA od obejścia. Reguła nadal działa. Pole nadal istnieje. Jego znaczenie uległo zmianie.
2. Wycofanie pola. Źródło przestaje emitować dane w polu. Mapa normalizacji teraz produkuje null dla tego pola. Reguła filtrująca na tym polu zwraca zero wierszy, ponieważ każda wartość to null. Jedyny widoczny objaw: wskaźnik null na tym polu rośnie z prawie zera w kierunku pełnego.
3. Zmiana schematu (pole zmienione nazwa lub typ). Źródło zmienia nazwę pola lub jego typ. Mapa normalizacji nadal wskazuje na starą nazwę lub stare przekształcenie typu. Dalsze w procesie normalizowane pole jest puste lub błędne.
Konkretny przykład: w 2019 roku Microsoft dodał przedrostek Device do tabel zaawansowanego łowienia w ATP Defenderze (ProcessCreationEvents stało się DeviceProcessEvents), przed wprowadzeniem ujednoliconego schematu, który później został wydany jako Microsoft 365 Defender, a następnie Defender XDR. Zapisane zapytania w portalu i niestandardowe detekcje zostały automatycznie przekształcone; zapytania wykonane przez API lub przechowywane poza portalem zachowały stare nazwy i przestały zwracać wyniki (przewodnik migracji Microsoft). Zapytania zaawansowanego łowienia na przemianowanej tabeli zwracają pusty wynik, a nie poważny błąd.
4. Zmiana parsera. Źródło zmienia format loga, a regex parsera nie pasuje już. Zdarzenia trafiają do kolejki listów martwych zamiast do warstwy detekcji. Każda reguła zależna od pól z tych zdarzeń milknie, ponieważ zdarzenia nigdy nie przybywają ustrukturyzowane.
5. Źródło wycofane. Źródło logów jest wycofane, przeniesione lub ma wyłączone audytowanie logów. Każda reguła, która czyta to źródło, zwraca zero. Jeśli świeżość SLO obserwuje źródło, czas wykrywania to kwestia minut. Jeśli nic go nie obserwuje, luka jest odkrywana przy kolejnych audytach lub kolejnych incydentach.
Przykład podręcznikowy cichego dekaya to Windows Event 4688 (tworzenie procesów). Loguje, gdy włączone jest śledzenie tworzenia procesów, ale pole linii poleceń procesu jest wypełnione tylko wtedy, gdy również włączone jest ustawienie zasad grupowych („Dołącz linię poleceń do zdarzeń tworzenia procesów”). Jeśli ta polityka zostanie wyłączona, przywrócona podczas odświeżania polityki, umieszczona w nowej jednostce organizacyjnej, lub usunięta z odbudowanego złotego obrazu, każda detekcja bazująca na zawartości linii poleceń cicho przestaje pasować.
Reguła nadal analizuje. Zdarzenie 4688 nadal przybywa. Pole, na którym reguła się opiera, jest puste. Nic nie radzi błędu. Można to odtworzyć poprzez przełączanie ustawienia polityki i ponowne uruchomienie reguły na świeżych zdarzeniach 4688. (Splunk Lantern: Włączanie logowania linii poleceń procesów za pomocą GPO)
Wszystkie pięć współdzieli jedną cechę: zielony oznacza popsuty, nie cichy. Tylko sygnały z płaszczyzny danych (wskaźnik null, wskaźnik analizy, objętość źródła, wskaźnik uruchomień) ujawniają awarię.
Jak udowodnię, że moje reguły detekcji rzeczywiście uruchamiają się przy prawdziwym ataku w moim środowisku, zanim on nastąpi?
Potrzebne są dwie nogi dowodowe. Żadna samodzielna nie jest wystarczająca.
Noga 1: emulowana rzeczywista procedura (noga zachowania)
Uruchom rzeczywistą technikę przeciw środowisku, a nie ręcznie stworzone zdarzenie, i potwierdź, że reguła reaguje na nie. To dowodzi, że reguła jest zgodna z zachowaniem rzeczywistego przeciwnika.
- Atomic Red Team. Testy atomowe na poziomie technik: izolowane, powtarzalne procedury mapowane do identyfikatorów technik MITRE ATT&CK. Uruchom pojedynczy test (na przykład, T1059.001 Wykonanie PowerShell) i potwierdź, że detekcja reaguje.
- MITRE Caldera. Łańcuchowa emulacja przeciwnika: wiele technik wykonuje się w sekwencji, aby symulować kampanię. Potwierdź, że skorelowane detekcje uruchamiają się w porządku.
- Ćwiczenia purple-team. Walidacja najwyższej kontekstowości. Operator wykonuje zestaw technik, podczas gdy inżynierowie detekcji obserwują.
Noga 2: od końca do końca środowiska nabywcy (noga zasięgu)
Sprawdzenie prawdziwych pozytywnych w działającym kanale, z zapisem pass na regułę. To dowodzi, że telemetria techniki przetrwała kolekcję, analizę i normalizację w tej sieci. Reguła, która działa w laboratorium testowym a zawodzi w produkcji, udowodniła składnię, a nie zasięg.
Reguła, która uruchamia się na syntetycznym zdarzeniu testowym, udowodniła składnię i dopasowanie (poziomy 1 i 2 na drabinie dowodowej). Nie udowodniła, że rzeczywista procedura przeciwników produkuje to zdarzenie w tym środowisku. Technika może nie emitować zdarzenia, którego oczekuje reguła, w tej wersji systemu operacyjnego, na tym agencie końcowym lub w tej konfiguracji logowania.
Reguła, która nigdy nie została wykazana jako uruchamiana przeciwko emulowanemu zachowaniu, jest traktowana jako dekoracyjna, dopóki nie zostanie udowodnione inaczej.
Jak zdecydować, które z moich istniejących reguł SIEM wycofać, nie tworząc przy tym ślepej plamy?
Wycofanie to decyzja dotycząca pokrycia, a nie zadanie porządkowe. Usuwanie reguły bez wiedzy, co unikalnie pokrywa, to sposób, w jaki tworzą się ślepe plamy. Cztery wejścia informują o odpowiedzialnym wycofaniu, a jedna nagrana decyzja go zamyka.
Historia uruchomień
Czy reguła wywołała prawdziwy alarm w określonym okresie? Reguła, która nie wywołała prawdziwego alarmu w okresie przeglądu, to kandydat, a nie werdykt. Niektóre reguły istnieją dla technik rzadkich, lecz o wysokim wpływie. Sprawdź zdrowie źródła danych przed podjęciem decyzji, że reguła jest martwa, a nie niewykorzystana.
Mapowanie techniki
Które z technik MITRE ATT&CK pokrywa reguła? Bez mapowania nie można ocenić, czy jej wycofanie tworzy lukę. Jeśli reguła jest jedynym pokryciem dla tej techniki, jej wycofanie tworzy lukę, która musi być wypełniona przed jej usunięciem, lub zaakceptowana i udokumentowana jako świadome ryzyko.
Pokrycie pokrywające się
Czy inna reguła lub inne źródło danych pokrywa tę samą technikę? Dwie reguły, które obie pokrywają T1078, nie są wymienne, jeśli jedna odczytuje logi dostawcy tożsamości, a druga odczytuje telemetrię końcową. Pokrycie pokrycie oznacza technikę plus źródło danych, a nie samą technikę.
Status źródła danych
Czy źródło logów, od którego zależy reguła, nadal działa i jest wypełnione? Reguła przeciwko wycofanemu źródłu nie produkuje nic i może zostać wycofana bez utraty pokrycia.
Zapis decyzji
Detection-as-Code traktuje wycofanie jako wersjonowaną, podlegającą przeglądowi zmianę: wiadomość commit, różnicę i zapis, nie ciche usunięcie z konsoli SIEM. Zapis wycofania zawiera nazwę reguły, technikę(e), którą pokrywała, decyzję dotyczącą pokrycia (pokrycie gdzie indziej, zaakceptowane ryzyko lub zastąpione), datę i autora. Cykl przeglądu kwartalnego wyłania kandydatów. Prime Hunt dostarcza powierzchnię pokrycia i walidacji dla mapowania treści detekcji do technik ATT&CK na różnych platformach.
Warunki, które wymuszają wycofanie: źródło danych, od którego zależy reguła, zostało wycofane, technika została całkowicie zastąpiona przez bardziej precyzyjną regułę przeciwko tym samym danym lub reguła produkuje tylko fałszywe alarmy po dostrojeniu, a żadne przeprojektowanie nie może tego naprawić.
Wyrzuć przestarzałe detekcje. Nie tłum ich. Tłumiona reguła zwiększa liczbę reguł i tworzy fałszywe poczucie pokrycia.
Jaka jest obronna częstotliwość walidacji?
Żaden zewnętrzny standard nie ustala tych częstotliwości. Co następuje, to rekomendacje praktyków. Każdy wiersz łączy cykl kalendarzowy z wyzwalaczem zdarzenia, ponieważ dekay jest napędzany zdarzeniami bardziej niż czasem.
| Klasa reguły | Metoda testu | Częstotliwość kalendarzowa | Ponownie weryfikować w przypadku zdarzenia | Dowód wyprodukowany |
|---|---|---|---|---|
| Źródło o wysokiej zmienności (EDR, audyt w chmurze, niestandardowy parser) | Powtórka Atomic Red Team + współczynnik bazowy uruchomień | Miesięcznie | Aktualizacja sensora/agenta, zmiana parsera, zmiana nazwy pola, zmiana konektora | Zapis pass na regułę + wymagany współczynnik null w oknie |
| Stabilne źródło (sieć, firewall) | Test atomowy + współczynnik bazowy uruchomień | Kwartalnie | Zmiana formatu źródła, zmiana trasy ingerencji | Zapis pass + objętość źródła w pasmie |
| Reguła korelacji / stanowa | Łańcuchowa emulacja MITRE Caldera | Kwartalnie i przy każdej zmianie reguły składnika | Każda zmiana komponentu reguły lub jej źródła danych | Od końca do końca ogień z decyzją |
| Reguła powiązana z zgodnością | Emulacja + udokumentowane prawdziwe pozytywne | Kwartalnie, zgodność z audytem | Regulacja lub zmiana kontroli | Datowany pakiet dowodowy |
| Reguła stworzona przez AI | Pełna drabina (lint, jednostka, emulacja, współczynnik FP) przed wdrożeniem, potem częstotliwość jej klasy | Przed każdym wdrożeniem | Przeprojektowanie, zmiana prompt lub modelu | Zapis pochodzenia (co stworzono, kto przeanalizował) + dowód ogniowy |
Obowiązują dwie zasady operacyjne.
Bazowanie na współczynniku uruchomień, monitorowanie wymaganych pól na poziomie null oraz objętości źródła są ciągłe. Działają zawsze, a nie według kalendarza, co pozwala na zauważenie cichego dekaya między zaplanowanymi weryfikacjami.
Natywne widoki zdrowotne platformy wspierają to. Splunk udostępnia metadane harmonogramów w index=_internal i wykonanie wyszukiwania korelacyjnego w index=_audit. Sentinel udostępnia zdrowie reguł analitycznych w SentinelHealth. Elastic Security udostępnia status wykonania reguły na zakładce Monitoring (8.x+). Zbuduj podstawę współczynnika uruchomień z tego.
Wyzwalacze zdarzeń w tabeli nie są opcjonalne. Kwartalna częstotliwość, która ignoruje zmianę parsera w środku kwartału, pomija dekay, do którego odkrycia została stworzona.
Gdzie to się nie sprawdza
- Analityka behawioralna oraz detekcje oparte na ML nie mają dyskretnej logiki reguł do odtwarzania lub testów atrapowych. Walidacja dla modelu, który ocenia anomalie, oznacza testowanie jego danych wejściowych (czy oczekiwane dane nadal przychodzą, w oczekiwanym kształcie) i sprawdzanie jego rozkładu wyjściowego, a nie odgrywanie akcji Sigma.
- Dopasowanie wskaźnika wywiadowczego zagrożenie (hashe, IP, domeny) traci ważność z innego powodu. Wskaźniki wygasają, ponieważ przeciwnik obraca infrastrukturę, a nie dlatego, że schemat się zmienił. Pytanie dotyczące walidacji to świeżość feedu wskaźników, a nie czy logika dopasowania nadal analizuje.
- Detekcje bazujące na retorcie (honeypots, honeytokeny, konta kanarkowe) są własną powierzchnią weryfikacji. Testem jest, czy interakcja z łudzącym zasobem nadal generuje oczekiwany alert, co bardziej przypomina iniekcję zdarzenia kanarka niż odtwarzanie reguły.
- Alertowanie o dryfie schematu jest niedojrzałe jako natywna funkcjonalność. Żadna większa SIEM nie udostępnia zapakowanego, świadomego reguł alertu, który mówi „pole, od którego zależy twoja detekcja, właśnie się zmieniło”. Dane do detekcji dryfu istnieją (wskaźnik null, konflikty mapowania, luki CIM). Okablowanie od zmiany pola do zależnej reguły jest dzisiaj ręczne.
- Te częstotliwości nie są standardami. Żadne ciało regulacyjne ani struktura przemysłowa nie nakładają określonych częstotliwości walidacji detekcji. Powyższe częstotliwości są rekomendacjami praktyków. Dostosuj je do prędkości zmian w swoim środowisku.
WERYFIKACJA DETEKCJI LISTA KONTROLNA
Przed wdrożeniem
[ ] Reguła parsu przeciw docelowy schemat (poziom 1)
[ ] Reguła dopasowania znany-pozytywny atrapa zdarzenia (poziom 2)
[ ] Reguła odrzuca sparowane znane-łagodne atrapa zdarzenia (poziom 2)
[ ] Reguła wystartuje przeciw emulowaną rzeczywistą procedurę:
Atomic Red Team or MITRE Caldera (poziom 3)
[ ] Reguła wystartuje end to end in the wdrożony kanał (poziom 3)
[ ] Podstawę wprowadzenia udokumentowana przeciw produkcja telemetria
[ ] MITRE ATT&CK technika mapowanie odnotowane
Po wdrożeniu (pierwsze 7 dni)
[ ] Wskaźnik uruchomień wprowadzenia ustanowiony
[ ] Alert wolumen porównano to przed-wdrożenie szacunek
[ ] No nieoczekiwany fałszywe-pozytywne wolumen
Przez cały czas
[ ] Wskaźnik uruchomień monitorowane przeciw wprowadzenia (ciągle)
[ ] Wymagany-współczynnik null monitorowane (ciągle)
[ ] Źródło wolumen monitorowane for spadek (ciągle)
[ ] Kanarek zdarzenie iniekcja planowany (według częstotliwości tabela)
[ ] Emulacja odtwarzanie planowany (według częstotliwości tabela)
[ ] Monitorowanie driwu schematu aktywne on wymagane pola
Przegląd wycofania (kwartalnie)
[ ] Historia przeglądana: prawdziwe pozytywne okno in wycofania Technika
[ ] bieżące mapowanie Pokrycie
[ ] pokrycie sprawdzono: inna reguła źródło or pokrywa
Dane the technika
[ ] potwierdzony: pokrywa potwierdzony: nadal wypełniony aktywne and zdecydowanie
[ ] Przegląd z odnotowane techniki, pokrycie uzasadnienie,
data, autor and Dowód
walidacji per cykl Zapis
[ ] pass metody, per źródło techniki, autor rezultat and wskaźniki null
[ ] bazowania współczynnika uruchomień and sprawdź powód Pokrycie
[ ] Monitorowanie zamiana Pokrycie
[ ] Przegląd log Pokrycie techniki, reason and Cztery sygnały przechwytują cicho złamane reguły: bazowanie współczynnika uruchomień przeciwko ostatniemu poziomowi bazowemu każdej reguły, iniekcja zdarzeń kanarkowych od początku do końca przez kanał detekcji, okresowe odtwarzanie zapisanych pozytywnych próbek i monitorowanie dryfu schematu w wymaganych polach. Bazowanie współczynnika uruchomień jest najczęstszym punktem wyjścia. Nie działa dla reguł o niskim współczynniku bazowym, których normalny poziom uruchomień to zero, co jest powodem, dla którego wszystkie cztery sygnały są potrzebne razem. Splunk, Microsoft Sentinel i Elastic Security każdy z nich udostępnia współczynnik uruchomień i zdrowie wykonania przez natywne powierzchnie danych opisane w powyższych tabelach platform. Prime Hunt dostarcza powierzchnię pokrycia i walidacji dla mapowania treści do technik ATT&CK.
FAQ
Skąd mam wiedzieć, które z moich reguł detekcji przestały działać bezgłośnie?
Four signals catch silently broken rules: fire-rate baselining against each rule’s own recent baseline, canary event injection end to end through the detection pipeline, periodic replay of stored positive samples, and schema-drift monitoring on required fields. Fire-rate baselining is the most common starting point. It fails for low-base-rate rules whose normal fire count is zero, which is why all four signals are needed together. Splunk, Microsoft Sentinel, and Elastic Security each expose fire-rate and execution health through native data surfaces described in the platform tables above. Prime Hunt provides a coverage and validation surface for mapping content to ATT&CK techniques.
Jak udowodnić, że moje reguły detekcji uruchomiłyby się przy prawdziwym ataku, zanim on się wydarzy?
Dwie nogi dowodowe, obie wymagane. Po pierwsze, uruchom rzeczywistą technikę przeciw środowisku używając Atomic Red Team do testów na poziomie technik lub MITRE Caldera do łańcuchowej emulacji przeciwników, i potwierdź, że detekcja reaguje. To noga zachowania. Po drugie, zweryfikuj, czy reguła uruchamia się od początku do końca w działającym kanale z zapisem pass na regułę. To noga zasięgu. Reguła, która uruchamia się przy syntetycznym zdarzeniu testowym, udowodniła składnię i dopasowanie. Nie udowodniła jeszcze, że rzeczywista procedura przeciwnika produkuje taką samą telemetrię w tym środowisku.
Jak zdecydować, które reguły SIEM wycofać, nie tworząc ślepej plamy?
Cztery wejścia czynią decyzję odpowiedzialną: historia uruchomienia reguły w okresie przeglądu, jej mapowanie techniczne MITRE ATT&CK, czy inna reguła lub źródło danych pokrywa tę samą technikę, oraz czy źródło danych reguły jest nadal aktywne. Decyzja o wycofaniu jest zapisana z dyscypliną Detection-as-Code: nazwa reguły, pokryta technika, uzasadnienie pokrycia (pokrycie gdzie indziej, zaakceptowane ryzyko lub zastąpione), data i autor. Kwartalna częstotliwość wyłania kandydatów.
Jak często powinienem ponownie walidować detekcje?
Żaden zewnętrzny standard nie nakłada określonych częstotliwości walidacji detekcji. Tabela częstotliwości powyżej zawiera rekomendacje praktyków: miesięcznie dla reguł przeciwko źródłom o wysokiej zmienności (EDR, audyt w chmurze, niestandardowe parsery), kwartalnie dla stabilnych źródeł (sieć, firewall), i przed każdym wdrożeniem dla reguł tworzonych przez AI. Wyzwalacze zdarzeń są tak samo ważne jak kalendarz: zmiana parsera, aktualizacja sensora lub zmiana nazwy pola wywołuje natychmiastową ponowną walidację niezależnie od harmonogramu. Bazowanie współczynnika uruchomień i monitorowanie wskaźników null działają ciągle.
