Obsługa Sophos XDR Cases i Detection Rules

Sophos XDR łączy Detections i powiązane encje w przypadki, które można zbadać. Case nie jest automatycznie rozwiązanym incydentem, lecz wspólnym obszarem pracy dla dowodów, odpowiedzialności i działań Response.

Dotychczasowe procedury w tym artykule opisują obsługę Cases i Detection Rules w Threat Analysis Center, nadal dostępnej Classic view platformy Security Operations. Osobna sekcja o Security Operations wyjaśnia aktualne granice odpowiedzialności i statusów MDR. Przed zmianą sprawdź, którego widoku używa Twój tenant. Security Operations również udostępnia Cases, Detections i Detectors; nie dowodzi to, że obowiązują tam te same statusy, role, okresy usuwania czy reguły tłumienia. W szczególności Detectors nie jest utożsamiane z opisanymi poniżej Detection Rules w Classic.

W Classic Cases wymagają EDR, XDR lub MDR. Sophos automatycznie tworzy Case dla High-Risk Detection, jeżeli tego samego dnia nie znajduje się ona jeszcze w pasującym Case. Późniejsze Detections tego samego typu mogą zostać do niego dodane.

Case typu Sophos-managed, oparty na MDR Detections, jest badany przez zespół MDR. Case typu Self-managed, utworzony z XDR Detections, pozostaje odpowiedzialnością klienta i jest przypisywany administratorowi. Sophos go tworzy, ale nie bada automatycznie.

Ta granica odpowiedzialności dotyczy również sygnałów NDR i autoryzowanych testowych trafień NDR: źródło NDR nie przekazuje automatycznie Self-managed XDR Case do Sophos MDR. Administrator klienta pozostaje Ownerem do czasu zamknięcia Case zgodnie z własnym procesem. Tylko Case oznaczony jako Sophos-managed, utworzony na podstawie MDR Detections, należy do zespołu MDR. Jednoznaczną korelację i uporządkowanie testowego trafienia opisuje runbook testowej Detection NDR.

Detection, Alert i Case w Classic

Wiele Detections może należeć do tego samego łańcucha ataku. Z drugiej strony pojedyncza podejrzana Detection może już uzasadniać dochodzenie.

W Self-managed Cases statusy New, Investigating, On Hold i Resolved tworzą pełny przebieg: nowo utworzony, aktywnie badany, tymczasowo wstrzymany lub zamknięty. Sophos-managed Cases używają natomiast statusów Investigating, Action required i Resolved. Action required oznacza, że klient musi podjąć działanie; Sophos powiadamia skonfigurowane osoby kontaktowe.

Praca nad Case w Classic

Rozpocznij w Threat Analysis Center > Cases. Otwórz automatycznie wygenerowany Self-managed Case przez jego Case ID. Na karcie Overview użyj menu obok nazwy Case, aby ustawić ważność. Następnie zmień status z New na Investigating i wybierz odpowiedzialnego administratora w polu Owner. Jeśli go brakuje, dodaj go przez Add user. Owner może też zostać przypisany później.

Self-managed Case można utworzyć ręcznie na dwa oficjalnie opisane sposoby:

• W Threat Analysis Center > Cases > Create case > Self-managed case wpisz nazwę i opis, wybierz Severity, status New i opcjonalnie Assignee, po czym zapisz przez Create. Następnie w Threat Analysis Center > Detections zaznacz trafienia i użyj Actions > Add to Case.
• Albo najpierw zaznacz trafienia w Threat Analysis Center > Detections i wybierz Actions > Create Case. Późniejsze Detections dodaj przez Actions > Add to Case.

Ręcznie utworzone Cases mogą zawierać wyłącznie Sophos XDR Detections, a nie MDR ani Managed Risk Detections. Sophos zaleca używanie w nazwie Case tylko znaków alfanumerycznych, spacji i podstawowych znaków interpunkcyjnych, ponieważ API mogą interpretować znaki specjalne jako składnię.

Podczas samego dochodzenia:

1. Odczytanie podsumowania, ważności i osi czasu.
2. Sprawdzenie urządzeń, użytkowników, procesów, adresów IP i plików.
3. Ocenę technik MITRE ATT&CK i źródła Detection.
4. Użycie Threat Graph, Live Discover i dostępnych Enrichments.
5. Udokumentowanie ograniczenia zagrożenia, na przykład izolacji lub Live Response.
6. Zapisanie przyczyny, zakresu i decyzji o zamknięciu.

W przypadku Self-managed Case zapisuj notatki z dochodzenia na karcie Notebook. Dzięki temu historia dowodów i decyzji pozostaje bezpośrednio przy Case.

Podsumowania generowane przez AI mogą przyspieszyć triage, lecz należy je porównać z danymi surowymi i osią czasu.

Detection Rules

Poniższe reguły dotyczą widoku Classic w Threat Analysis Center > Detection rules, a nie ogólnie Security Operations. Detection Rules mogą obecnie wyłącznie tłumić niepożądane Detections i wymagają roli Super Admin. Reguła zapobiega wyświetleniu pasującej Detection na liście Detections i utworzeniu przez nią Self-managed XDR Case. Nie można w ten sposób tłumić MDR Cases.

Utwórz regułę z istniejącej Detection: przejdź do Threat Analysis Center > Detections, otwórz menu z trzema kropkami obok nazwy i wybierz Add detection rule. W Rule Details wpisz nazwę i opis; reguła jest domyślnie włączona. Suppress jest obecnie jedyną opcją w Actions. W Conditions wybierz cechy istniejącego trafienia, które mają uruchamiać regułę, i kliknij Save. Jeden tenant może mieć najwyżej 25 Detection Rules.

Przed zapisaniem domyślnie włączonej reguły udokumentuj jej nazwę, cel, źródło danych, oczekiwaną częstotliwość, Ownera i termin przeglądu. Warunki powinny identyfikować wyłącznie potwierdzony prawidłowy wyzwalacz, a nie jedynie ważność lub zbyt ogólną cechę procesu.

Nowa reguła może potrzebować do 20 minut i działa wyłącznie na Detections powstałe po jej utworzeniu. Warunki rozróżniają wielkość liter: Windows i windows mogą być traktowane inaczej.

Istniejącymi regułami zarządza się w Threat Analysis Center > Detection rules. Regułę można włączyć, wyłączyć, zduplikować lub usunąć, ale nie edytować bezpośrednio. Aby ją zmienić, zduplikuj i dostosuj kopię przez menu z trzema kropkami, a po kontrolowanym zastąpieniu wyłącz lub usuń oryginał.

Kontrola tłumienia

Tłumienie ogranicza znane i oczekiwane trafienia. Nie jest czyszczeniem i nie może ukrywać rzeczywistej aktywności. Każda supresja wymaga:

• precyzyjnego warunku zamiast szerokiego wzorca,
• udokumentowanego prawidłowego wyzwalacza,
• właściciela i daty przeglądu,
• kontroli już stłumionych Detections.

Spokojna konsola nie jest wskaźnikiem jakości, jeżeli reguły tłumią zbyt szeroki zakres.

Aby sprawdzić wynik, przejdź do Threat Analysis Center > Detections > Show filters. W sekcji Detection Visibility wyłącz Hide Suppressed Detections i kliknij Apply. Pozwala to zobaczyć, co reguła faktycznie obejmuje. Ponieważ reguły nie działają wstecz, ten widok jest lepszą podstawą następnego przeglądu niż sam spadek liczby widocznych trafień.

Security Operations: Cases i odpowiedzialność MDR

Ta sekcja dotyczy Security Operations, a nie poprzedzających ją statusów i reguł Classic. W Security Operations > Cases kliknięcie nazwy Case otwiera najpierw podsumowanie. Ikona New Tab prowadzi do pełnej strony szczegółów. Dostępne są tam Overview, Evidence, Response, History i Enrichment. Komentarze można czytać w podsumowaniu, ale dodawać tylko na pełnej stronie szczegółów.

Ustal Managed By przed potwierdzeniem

W bieżących Cases MDR pole Managed By określa, kto prowadzi Case: Self oznacza odpowiedzialność klienta, a Sophos MDR zarządzanie przez zespół MDR. Assignee wskazuje natomiast użytkownika lub grupę odpowiedzialną za następne działanie. Zmiana Assignee nie przenosi odpowiedzialności za Case.

Na pełnej stronie szczegółów wybierz oferowaną odpowiedzialność w Manage Case > Managed By i potwierdź dopiero po powyższej kontroli. Następnie sprawdź wyświetlaną wartość. Self można wybrać tylko dla typów Cases MDR Investigation i Other; Threat Hunt, Health Check i Incident są Sophos-managed. Klient nie tworzy Incident. Przy tworzeniu ręcznym Managed By ustala się już podczas tworzenia. W Cases generowanych automatycznie przez reguły Sophos należy ustawić je przed użyciem elementów sterujących Manage Case. W Cases z reguł klienta wartość wynosi automatycznie Self.

Case Self-managed analizuje własny zespół; dostępne zmiany, działania reagowania oraz dzielenie/scalanie zależą też od typu Case i uprawnień. W Cases Sophos-managed można czytać szczegóły, komentować, przypisywać do Sophos i zamykać, jeśli dostępne jest działanie zamknięcia. Nie daje to uprawnień do dowolnej zmiany statusu, edycji Key Findings, dodawania kolejnych zdarzeń lub Detections jako dowodów ani dzielenia lub scalania Case.

Bieżące statusy MDR i działania klienta

Bieżące Cases MDR używają zależnie od typu statusów New, In Progress, Customer Action Required, Awaiting Sophos Assignment i Closed. Wartości tych nie utożsamia się ani ze statusami Classic, ani z ogólnymi statusami XDR Open, Active, Awaiting Action, Suspended i Closed. Awaiting Sophos Assignment oznacza oczekiwanie na wewnętrzne przypisanie w zespole MDR; Customer Action Required wymaga natomiast działania organizacji.

Gdy zespół MDR ustawi Case Sophos-managed na Customer Action Required, rozpoczyna się licznik bezczynności. Bez działania klienta co 24 godziny wysyłane jest przypomnienie e-mail; po pięciu dniach bezczynności Case zamyka się automatycznie. Komentarz, działanie reagowania, zmiana Assignee albo nowy link lub załącznik resetuje licznik. Nie zastępuje to wymaganej pracy merytorycznej: pytania wyjaśniaj z zespołem MDR, zamiast podtrzymywać licznik wyłącznie formalnymi zmianami. Nigdy nie wykonuj działań reagowania tylko po to, by go zresetować.

Na pełnej stronie szczegółów ikona komentarza po prawej otwiera Comments. Wprowadź niezbędne informacje w Comment i zapisz przyciskiem Save. @sophos powiadamia zespół MDR. Po zapisaniu sprawdź, czy komentarz trafił do właściwego Case. Skonfiguruj kontakty MDR i uprawnienia do reagowania przed incydentem, a nie dopiero po pierwszym przeoczonym pytaniu.

Zamknięcie rozwiązuje też powiązane Detections i oznacza je zgodnie z wybranym werdyktem. MDR udostępnia True Positive – Benign, True Positive – Malicious, Inconclusive i False Positive; dla Inconclusive etykieta Detection to Not Actionable. Zamknięty Case nie jest technicznym dowodem usunięcia zagrożenia. Przed zamknięciem sprawdź wynik analizy i zaległe zadania klienta.

W ciągu 30 dni od zamknięcia Case MDR Sophos-managed można ponownie otworzyć komentarzem z @sophos; w Case customer-managed zmienia się status Closed. Po tych 30 dniach potrzebny jest nowy Case. Ten limit ponownego otwarcia nie określa usuwania ani przechowywania bieżących Cases MDR; terminy Classic podane wyżej lub niżej nadal dotyczą tylko Classic.

Rules zamiast samego tłumienia Classic

W Security Operations > Rules istnieją dwa oddzielne rodzaje Customization Rules: Custom detection rules generują nowe Detections ze znormalizowanych zdarzeń za pomocą zaawansowanego zapytania wyszukiwania. Detection suppression rules rozwiązują pasujące Detections jako stłumione już przy tworzeniu, dzięki czemu domyślnie nie pojawiają się na liście. Detectors nie jest tym samym obszarem zarządzania co te reguły.

Cases powstające automatycznie z reguł klienta są customer-managed i nie uruchamiają automatycznej analizy MDR. Ograniczenia Classic: 25 reguł, wymóg Super Admin, 20 minut oczekiwania i duplikowanie zamiast edycji nie są przenoszone do nowego interfejsu. Ta sekcja wyjaśnia rozróżnienia, a nie pełną procedurę tworzenia własnych reguł. Przed tłumieniem nadal trzeba potwierdzić prawidłową, nieszkodliwą przyczynę i ocenić utratę widoczności.

Zamknięcie i wnioski w Classic

Case można zamknąć po udokumentowaniu zakresu, przyczyny, ograniczenia, usunięcia zagrożenia i odzyskania sprawności. Następnie należy dostosować Detection Rules, polityki, wyjątki i runbooki, jeżeli dochodzenie wykazało lukę.

Self-managed Case zamyka się przez ustawienie statusu Resolved. Pozostaje na liście przez 30 dni, po czym Sophos go usuwa. Partner Super Admins i Enterprise Super Admins nie mogą zamykać ani usuwać Case, dlatego ograniczenie roli trzeba uwzględnić przed przypisaniem Ownera.

Podstawową telemetrię i pracę z zapytaniami opisuje artykuł Sophos XDR Data Collection i Live Discover.

Często zadawane pytania

Pełny aktualny proces pod Security Operations > Rules opisuje Eksploatacja Custom Detection i Suppression Rules. Warunki strumieniowe, circuit breaker, ograniczenia podglądu i wycofanie są tam oddzielone od zachowanych tu reguł Classic.