Eksploatować Sophos XDR Custom Detection i Suppression Rules

Pod Security Operations > Rules zarządza się własnymi regułami detection i Suppression Rules. Pierwsze tworzą detections ze znormalizowanych zdarzeń; drugie wcześnie oznaczają pasujące detections jako stłumione. Obie zmieniają proces dochodzenia i wymagają zatwierdzonego, wąskiego warunku oraz właściciela.

Instrukcja Cases i reguł Classic wyjaśnia nadal odmienny widok Classic. Jego wymogów Super Admin, liczbowych ani 20-minutowych nie przenosi się na Security Operations. Procedury dotyczą interfejsu użytkownika w tenancie.

Przed utworzeniem własnej reguły

Najpierw ustala się cel, źródło, schemat, oczekiwane trafienia i celowo wykluczone przypadki. Odpowiednie historyczne zdarzenia w Data Lake Search pozwalają sprawdzić sens warunku. Zatwierdzony test korzysta z osobnego konta lub innych dozwolonych danych; nie generuje rzeczywistej szkodliwej aktywności.

Trafienie w historii nie dowodzi identycznego działania aktywnej reguły. Silniki wyszukiwania i reguł różnią się; część wzbogaconych pól powstaje później. Odbiór obejmuje więc oczekiwane trafienie i oczekiwany brak trafienia. Przed zmianą zapisuje się zapytanie, nazwę, opis, severity, aktywację i wcześniejsze wyniki.

Utworzyć Custom Detection Rule

Najpierw tworzy się odpowiednie zapytanie Advanced Search w Security Operations > Data Lake Search. Ma trafiać w znormalizowane zdarzenia właściwego schematu. Następnie:

1. Skopiować sprawdzony tekst i otworzyć Security Operations > Rules.
2. Wybrać Create Rule nad tabelą Custom Rules.
3. Wstawić zapytanie do Rule Criteria.
4. Podać czytelną Name, właściwe Mitre Attack Categories i zrozumiałą Description.
5. Wybrać uzasadnioną severity i utworzyć przez Create Rule.

Nowa Custom Rule jest po utworzeniu włączona. Zgoda i właściciel muszą istnieć wcześniej. To inna wartość domyślna niż w nowym Custom Parser. Nie włącza się nieograniczonego warunku w produkcji wyłącznie na próbę.

Streaming nie jest zapisanym wyszukiwaniem

Custom Rules działają na danych strumieniowych. Pola prymitywne nie otrzymują tam automatycznie wartości domyślnych obecnych później w Data Lake. Warunki NULL muszą uwzględniać faktycznie brakujące wartości. Wzorce glob nie są obsługiwane; ograniczone są też konstrukcje regex, takie jak backreferences, wzorce rekurencyjne, dowolne asercje zerowej szerokości typu look-around i kod osadzony. Działające wyrażenie Search nie staje się bez sprawdzenia gwarantowaną regułą.

Pola logiczne jak @user mogą rozwijać się do pól wybranego schematu. Reguła dopasowuje jednak tylko jeden schemat. Część pól dodawanych później jest niedostępna: np. hostname, wzbogacenia geo/blacklist w auth/netflow/dns_query oraz WHOIS schematu DNS. Wymagane pola sprawdza się w kontekście reguły, bez zastępowania podobnie nazwanymi polami Search.

Circuit breaker i odpowiedzialność klienta

Custom Rules mogą tworzyć maksymalnie 5 000 detections na godzinę lub 100 000 w ciągu 24 godzin. Po przekroczeniu circuit breaker wyłącza regułę, a Sophos wysyła autorowi e-mail. Następnie zawęża się zakres; nie włącza ponownie niezmienionej reguły. Zatrzymany strumień alertów może zatem oznaczać wyłączoną regułę, nie usunięcie ryzyka.

Cases powstające automatycznie z reguł klienta są customer-managed i nie uruchamiają automatycznego dochodzenia MDR. Schematy Antivirus, Email, NIDS i Thirdparty opisują też is_custom_alert=true: takie Custom Alerts trafiają do obsługi przez tenant, nie do kolejki usługi MDR; severity się nie zmienia. Nie wyklucza to z MDR każdego rekordu Custom Parser. Tworzenie i walidacja parserów wyjaśnia wcześniejszą normalizację.

Świadomie ograniczyć suppression

Suppression służy potwierdzonym, legalnym powtórzeniom, nie ukrywaniu niewyjaśnionej aktywności. Reguły tenanta działają tylko w nim; Global są zarządzane przez Sophos i tylko do odczytu. Pytania o regułę globalną dokumentuje się i wyjaśnia normalną ścieżką wsparcia.

Stłumiona detection otrzymuje status wcześnie, zanim wyzwoli dalszą automatyczną reakcję. Playbook lub izolacja hosta mogą więc nie nastąpić. Przed zgodą trzeba określić, jaka legalna aktywność zostanie dopasowana i jaka reakcja bezpieczeństwa świadomie nie wystąpi.

Utworzyć suppression z zapytania

1. Sprawdzić warunek na istniejących detections w Data Lake Search.
2. Wybrać Create Rule pod Security Operations > Rules > Suppression Rules.
3. Wpisać warunek do Rule Criteria.
4. Użyć See potential matches with current data jako podglądu prawdopodobnych dopasowań.
5. Ustawić nazwę, opis i zamierzony status rozstrzygnięcia, po czym utworzyć przez Create Rule.

Nowe reguły suppression też są domyślnie włączone. Zakres, zgoda i wycofanie muszą zatem poprzedzać Create Rule.

Alternatywnie otwiera się konkretną detection i Actions > Create Suppression Rule. Wstępnie wypełnione entities wybiera się świadomie; kilka warunków jest łączonych przez AND. Specjalne znaki regex wpisywane ręcznie trzeba odpowiednio zabezpieczyć escape. Z pojedynczego oczekiwanego trafienia nie wyprowadza się uniwersalnej suppression.

Dlaczego podgląd i aktywna reguła mogą się różnić

Podgląd używa Advanced Search na gotowych, wzbogaconych detections. Suppression działa w czasie ich powstawania. Pola enrichment_details, status i case są niedostępne; dla wartości zewnętrznych stosuje się schemat zdarzeń thirdparty, nie third_party_details. Wszystkie kryteria muszą być prawdziwe razem w momencie suppression. Gotowy rekord może łączyć warunki wcześniej prawdziwe jedynie osobno.

Dlatego See potential matches nie gwarantuje działania. Po utworzeniu, edycji, włączeniu lub wyłączeniu czeka się co najmniej dziesięć minut przed oceną. Detections powstałe tuż po zmianie nie są wiarygodnym testem nowego stanu.

IPv4-CIDR jest możliwe w suppression, choć Detection Search nie obsługuje wyszukiwania CIDR. Zapytanie sprawdza się najpierw bez zakresu, a potem dostosowuje do reguły. Adresy IPv6 mogą być porównywane po normalizacji; IPv6-CIDR i IPv4-mapped IPv6 nie są obecnie obsługiwane w suppression. Nie przenosi się bez kontroli składni zakresów z zapory.

Sprawdzić działanie, udokumentować i wycofać

Kliknięcie nazwy pokazuje kryteria i szczegóły. Jeśli w ostatnich siedmiu dniach były trafienia, widać liczbę, ostatni wynik i wykres. Dla suppression History pokazuje też historię zmian. Brak wykresu może po prostu oznaczać, że pasujące zdarzenie nie wystąpiło.

Detections z Custom Rules uwzględnia się przez Custom Detections na liście. Stłumione, już obsłużone w triage detections pokazuje Triaged Detections; ze szczegółów reguły można otworzyć odpowiednie wyszukiwanie. Kontrola obejmuje oczekiwane trafienia i braki trafień, schemat/źródło oraz zamierzoną lub świadomie nieobecną reakcję.

Enabled włącza lub wyłącza regułę. Archive wyłącza ją i usuwa z listy domyślnej. Archiwalną regułę otwiera się przez Showing Archived Rules; Restore przywraca ją wyłączoną. Nie aktywuje się przywróconej reguły bez nowego odbioru. Udokumentowane opóźnienie suppression obowiązuje także przy wyłączaniu.

Jeśli odbiór się nie powiedzie, wyłącza się tylko własną daną regułę i sprawdza poprzedni zapisany stan. Istniejące Cases, eksporty i stłumione detections nie znikają automatycznie. Stłumione detections można w razie potrzeby dodać do Cases i zmienić ich etykietę. Nie wyłącza się globalnej ochrony ani cudzej reguły, aby dopasować wynik testu.

Przekazanie do eksploatacji obejmuje źródło/schemat, kryteria i wersję, autora, zgodę, dowody trafień i braków trafień, severity/rozstrzygnięcie, aktywację, monitoring circuit breakera i termin przeglądu. Odbiór integracji jest warunkiem: milcząca reguła nie naprawia brakującego źródła danych.