Aktywacja i weryfikacja MDR Threat Feeds w Sophos Firewall

MDR Threat Feeds łączą usługę Sophos MDR z Sophos Firewall. Analitycy MDR mogą za pośrednictwem Sophos Fusion (dawniej Sophos Central) przesyłać do zapory adresy IPv4, domeny i adresy URL związane z aktywnym incydentem w środowisku klienta. Zapora następnie rejestruje lub blokuje pasujący ruch bez ręcznego utrzymywania własnego pliku feedu.

Bezpieczne wdrożenie wymaga czegoś więcej niż włączenia przełącznika w WebAdmin. Licencja MDR, rejestracja w Sophos Fusion, lokalna akcja, wymagana widoczność ruchu, miejsca docelowe logów i ścieżka kontaktu z zespołem MDR muszą być ze sobą zgodne. Lokalny stan Log and drop nie dowodzi jeszcze, że dotarł konkretny IoC ani że dany przepływ przechodzi wymagane inspekcje.

Nazwy w interfejsie: Użyte tutaj ścieżki Sophos Fusion są zgodne z pomocą SFOS 22. Pomoc SFOS 23 nadal używa nazwy Sophos Central dla tego samego połączenia z chmurą. Jeśli używana kompilacja wyświetla tę nazwę, należy otworzyć odpowiednią stronę Sophos Central; sama nazwa nie mówi nic o rejestracji, uprawnieniu MDR ani dostarczeniu feedu. Send reports and logs to Sophos Central pozostaje udokumentowaną nazwą opcji rejestrowania.

MDR Threat Feeds w ośmiu krokach

1. Sprawdzić, czy na zaporze dostępny jest Xstream Protection Bundle, a w Sophos Fusion aktywne uprawnienie MDR.
2. W System > Sophos Fusion potwierdzić, że właściwa zapora jest zarejestrowana na właściwym koncie Sophos Fusion.
3. Udokumentować w Sophos Fusion planowany Threat response mode i operacyjną ścieżkę kontaktu z MDR.
4. W System services > Log settings aktywować co najmniej jedno użyteczne miejsce docelowe logów dla Active threat response.
5. Otworzyć Protect > Active threat response > MDR threat feeds i włączyć funkcję.
6. Wybrać Log only dla krótkiego, kontrolowanego pilotażu albo Log and drop dla ochrony produkcyjnej po pomyślnym odbiorze, a następnie kliknąć Apply.
7. Przeprowadzić test pozytywny i negatywny z wykorzystaniem Log Viewer, kontekstu endpointu i Sophos Fusion.
8. Udokumentować Audit ID, osoby odpowiedzialne, proces obsługi wyjątków, termin przeglądu i procedurę wycofania zmian.

Ważne: MDR Threat Feeds są tylko częścią obsługi MDR. Nie zastępują umowy MDR, sensorów endpointowych, komunikacji dotyczącej incydentów, restrykcyjnych reguł zapory ani przetestowanej procedury przywracania. Szeroki wyjątek lub niekontrolowane wyłączenie funkcji może osłabić trwającą reakcję zespołu MDR.

Co zapewniają MDR Threat Feeds

Analitycy Sophos MDR mogą wysyłać informacje o zagrożeniach związanych z aktywnym incydentem bezpośrednio do zapory za pośrednictwem Sophos Fusion. Feed jest więc bardziej dostosowany do konkretnego klienta niż ogólna, globalna lista reputacji. Przesłany IoC może być adresem IPv4, domeną lub adresem URL.

Lokalna akcja zapory określa, co dzieje się po wykryciu dopasowania:

• Log only rejestruje trafienie, ale przepuszcza ruch.
• Log and drop rejestruje i odrzuca pasujący ruch.

Sophos zaleca blokowanie znanych IoC. Krótki pilotaż z Log only może jednak mieć sens, jeśli w istniejącym środowisku trzeba najpierw sprawdzić widoczność, rejestrowanie zdarzeń i możliwe skutki uboczne. Taki pilotaż wymaga ustalonej daty zakończenia. Bez zaplanowanego przełączenia aktywna integracja MDR może pozostać na stałe bez lokalnego blokowania.

Threat response mode w Sophos Fusion i lokalna akcja feedu to dwa różne poziomy. Tryb w Sophos Fusion określa uprawnienia zespołu MDR do reagowania. Log only lub Log and drop określa sposób, w jaki zapora traktuje już przesłany IoC. Przed wdrożeniem oba ustawienia należy uzgodnić z umową MDR i wewnętrznym procesem obsługi incydentów. Aktualna dokumentacja Sophos dotycząca Threat response mode rozróżnia Collaborate, Authorize i Notify Only.

Rozróżnienie telemetrii zapory i reakcji analityków

Dane przepływają także w przeciwnym kierunku: zapora dostarcza zdarzenia bezpieczeństwa na potrzeby dochodzenia MDR. W tym celu musi być zarejestrowana w Sophos Central firewall management; na zaporze muszą być włączone Sophos Central services oraz zaznaczona opcja Send reports and logs to Sophos Central. MDR stale analizuje logi bezpieczeństwa z Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection i Application Control. W połączeniu z danymi z endpointów, serwerów i innych zintegrowanych źródeł zdarzenia te pomagają wykrywać szkodliwą aktywność, IoC i próby ruchu bocznego. Telemetria napływająca z zapory nie jest jednak feedem IoC specyficznym dla klienta, który analitycy MDR wysyłają z powrotem do zapory.

W przypadku krytycznego incydentu zespół MDR może na przykład zakończyć sesje VPN użytkowników, których konta zostały przejęte. Jest to działanie analityków w ramach reagowania na incydenty i przyznanych uprawnień, a nie automatyczna konsekwencja trafienia w feedzie ani lokalna instrukcja wykonywania kliknięć lub poleceń CLI. Przy Authorize zespół może reagować na aktywne zagrożenia bez uprzedniej konsultacji z wyznaczonymi osobami kontaktowymi; przy Collaborate reakcja jest z nimi uzgadniana. Nie oznacza to nieograniczonych uprawnień do reagowania dla wszystkich urządzeń lub integracji. Nie kończy się produkcyjnych sesji VPN w ramach testu działania.

Działania przez Live Response wymagają zezwolenia na Live Response na danym urządzeniu. Artykuł Izolowanie Sophos Endpoint i badanie za pomocą Live Response wyjaśnia wymagania i bezpieczny sposób postępowania. Działania Microsoft 365, takie jak blokowanie lub zezwalanie na logowanie, unieważnianie aktywnych sesji i wyłączanie Inbox Rules, wymagają skonfigurowanej integracji do reagowania; obowiązuje odrębna procedura opisana w Integracjach MDR i XDR. Rejestrowanie logów zapory ani dostarczony IoC MDR nie umożliwiają automatycznie tych działań.

Z kolei cybora.io Threat Feeds, których Avanet używa w Sophos Firewall, to Third-Party Threat Feeds, a nie Sophos MDR Threat Feeds ani feedy MDR tworzone przez Avanet. Ich konfiguracja przebiega zgodnie z procedurą dla feedów innych dostawców; nie przyznaje ona zespołowi Sophos MDR dodatkowych uprawnień do reagowania.

Kolejność przetwarzania i cykl życia

SFOS 22 przetwarza Active Threat Response w kolejności MDR, NDR Essentials, Sophos X-Ops i Third-Party Threat Feeds. Jeśli IoC zostanie dopasowany w MDR przy ustawieniu Log and drop, zapora odrzuca ruch, rejestruje go w MDR i nie sprawdza już kolejnych feedów. Przy Log only lub Monitor mogą powstać osobne zdarzenia dla MDR, X-Ops i Third-Party Feeds. Trafienie MDR z Log and drop zatrzymuje sprawdzanie kolejnych feedów. Przy Log only lub różnych akcjach modułów nie należy zakładać ogólnego zezwolenia; trzeba uwzględnić pozostałe skonfigurowane akcje i sprawdzić dowody w ruchu oraz logach.

Poszczególnych IoC MDR nie tworzy się ani nie edytuje w WebAdmin. Analitycy MDR dodają je za pośrednictwem Sophos Fusion i tam je usuwają. Obie operacje są rejestrowane wraz z akcją i tożsamością analityka jako audit_ID. Tych zdarzeń administracyjnych należy szukać w widoku szczegółowym Admin w Log Viewer lub w Sophos Fusion Firewall Task Queue, a nie mylić ich z trafieniami w ruchu w Active threat response. Lokalnie można jedynie określić, czy feed MDR jest aktywny oraz czy trafienia mają być rejestrowane, czy dodatkowo odrzucane. Threat Exclusions mają natomiast charakter globalny i obowiązują we wszystkich modułach Active Threat Response.

Dokumentacja SFOS 22 nie podaje okresu ważności IoC MDR, który administrator zapory mógłby ustawić. Nie należy więc wnioskować o dacie wygaśnięcia na podstawie lokalnego interfejsu. Jeśli wpis budzi wątpliwości lub może być nieaktualny, należy zachować audit_ID, IoC i czas zdarzenia oraz wyjaśnić jego status z zespołem MDR. Ma to znaczenie również przy wycofywaniu zmian: przełączenie z Log and drop na Log only dotyczy wszystkich aktualnie dostarczonych IoC MDR; Threat Exclusion może dodatkowo osłabić NDR, X-Ops i Third-Party Feeds.

Dokładna weryfikacja wymagań

Licencja i Sophos Fusion

MDR Threat Feeds wymagają na zaporze Xstream Protection Bundle. Tabela licencji SFOS 22 wymienia dodatkowo Sophos MDR Essentials lub Sophos MDR Complete w Sophos Fusion; aktualna dokumentacja Sophos Fusion określa warianty usługi jako MDR i MDR Plus. Dlatego należy sprawdzić aktywne uprawnienie MDR na własnym koncie Sophos Fusion, zamiast wnioskować o nim wyłącznie na podstawie dawnej nazwy produktu. Sam pakiet Xstream nie obejmuje usługi MDR.

Zapora musi być zarejestrowana na właściwym koncie Sophos Fusion. W System > Sophos Fusion należy sprawdzić rejestrację oraz przekazywanie raportów i logów. Pełną procedurę połączenia opisuje artykuł Łączenie Sophos Firewall z Sophos Fusion.

Ponadto usługa Sophos MDR musi być skonfigurowana. Sama rejestracja zapory i weryfikacja licencji nie zastępują tej konfiguracji. Przed lokalnym włączeniem funkcji należy potwierdzić z osobą odpowiedzialną za MDR, że usługa jest skonfigurowana dla właściwego klienta, a Threat response mode został świadomie ustalony. Sophos wymaga co najmniej jednej upoważnionej osoby kontaktowej, zanim będzie można skonfigurować kolejne ustawienia MDR lub korzystać z usługi. Dla dodatkowego kontekstu endpointu uzyskiwanego przez Synchronized Security tabela licencji SFOS 22 wymienia również licencję Intercept X w Sophos Fusion; sam pakiet Xstream nie gwarantuje tego kontekstu.

Sophos MDR: konfiguracja kontaktów i Threat Response opisuje pełny proces centralny: role kontaktów, wariant awaryjny Collaborate, dostęp do urządzeń i bezpieczne sprawdzanie zapisanych wartości. Nie zastępuje następującej po nim lokalnej konfiguracji feedu.

Przed aktywacją należy także ustalić odpowiedzialności:

• Kto może zmieniać Threat response mode w Sophos Fusion?
• Kto odbierze telefon od MDR lub odpowie na pytanie poza godzinami pracy?
• Kto może zatwierdzić wyjątek?
• Gdzie dokumentuje się Audit ID, Incident ID i dowody techniczne?
• Które systemy można odizolować po potwierdzeniu naruszenia bezpieczeństwa?

Aktywacja miejsc docelowych logów

W System services > Log settings, w wierszu Active threat response, należy aktywować co najmniej jedno z tych miejsc docelowych:

• Local reporting dla Log Viewer i raportów lokalnych
• skonfigurowany Syslog server dla SIEM lub SOC
• Central reporting dla Sophos Fusion

Kolumna Central reporting pojawia się dopiero po włączeniu Send reports and logs to Sophos Central na stronie Sophos Fusion. XGS 87/87w i 107/107w nie obsługują raportowania lokalnego; w ich przypadku potrzebne jest Central Reporting lub Syslog.

Po wybraniu miejsc docelowych logów w System services > Log settings należy kliknąć Apply. Następnie ponownie załadować stronę i sprawdzić, czy zamierzone miejsca docelowe nadal są zaznaczone w wierszu Active threat response. Potwierdza to zapisaną konfigurację; rzeczywisty transport logów i dostarczanie powiadomień o incydentach sprawdza się osobno.

Dla powiadomień należy dodatkowo sprawdzić System services > Notification list. Aktywacja miejsca docelowego logów określa ścieżkę transportu, ale nie dowodzi ani rzeczywistego dostarczenia, ani prawidłowej obsługi alarmów.

Widoczność adresów IP, domen i adresów URL

IoC działa tylko na ruch, który zapora może odpowiednio przetworzyć. Dla przekazywanego ruchu do docelowego adresu IP potrzebna jest odpowiednia reguła zapory. Dopasowania domen wymagają w danej regule Application Classification lub polityki IPS. W przypadku pełnej ścieżki URL w HTTPS potrzebny jest Web Proxy z deszyfrowaniem albo DPI z odpowiednią regułą SSL/TLS Inspection.

Ruch kierowany do samego systemu, do usług w Administration > Device access, takich jak WebAdmin, VPN Portal i VPN, może być sprawdzany na podstawie złośliwego źródłowego adresu IPv4. W przypadku przychodzącego, przekazywanego ruchu DNAT lub WAF należy dodatkowo włączyć Remote source match (inbound traffic) w System services > Log settings > Active threat response, aby uzyskać oczekiwaną widoczność w logach.

Niewyjaśnione ograniczenie ATR/X-Ops: Oficjalny opis i macierz ruchu są ze sobą sprzeczne w kwestii dopasowań adresów docelowych i lokalnych adresów źródłowych dla Sophos X-Ops. W tych przypadkach nie potwierdzono wiarygodnie ani obsługi, ani jej braku; podlinkowane informacje o ruchu i modułach nie stanowią zatwierdzonej podstawy konfiguracji w tym zakresie. Nie należy na tej podstawie wnioskować o kierunku ruchu MDR ani zakładać skuteczności ochrony w tych przypadkach X-Ops. Przed wprowadzeniem zmiany opartej na takich założeniach potrzebne jest wiążące wyjaśnienie od Sophos lub wyraźnie zatwierdzony test produktu; poniższe linki nie rozstrzygają tej sprzeczności.

Ogólną logikę ruchu, modułów i inspekcji opisano w artykule Konfiguracja i bezpieczna eksploatacja Sophos Firewall Threat Feeds. Wyjaśniono tam również, dlaczego bez odpowiedniej klasyfikacji lub deszyfrowania domena albo adres URL mogą nie zostać wykryte.

Konfiguracja MDR Threat Feeds

1. Zalogować się do WebAdmin przy użyciu osobistego konta administratora.
2. Otworzyć Protect > Active threat response > MDR threat feeds.
3. Włączyć MDR threat feeds.
4. Jako Action wybrać Log only dla pilotażu z ustalonym terminem zakończenia albo Log and drop po pomyślnym odbiorze.
5. Zapisać przez Apply.
6. Ponownie załadować stronę i sprawdzić, czy stan przełącznika oraz Action zostały zapisane.
7. Sprawdzić znacznik czasu, administratora i zmianę w Audit Trail.
8. W Sophos Fusion sprawdzić, czy zapora jest online i czy MDR jest przypisany do właściwego klienta lub tenanta.

Nie należy jednocześnie wprowadzać szerokich zmian w rejestrowaniu, inspekcji, wyjątkach i Action. Etapowe wdrożenie pozwala ustalić, która zmiana spowodowała trafienie lub skutek uboczny.

Wiarygodna weryfikacja skuteczności

Zweryfikowana tutaj pomoc MDR nie wskazuje uniwersalnego, nieszkodliwego wskaźnika testowego MDR. Dlatego wywołanie prawdziwej domeny złośliwego oprogramowania lub znanego szkodliwego adresu IP nie jest właściwym testem odbiorczym. Kontrolę techniczną należy podzielić na kilka poziomów, dla których można zebrać dowody. Własny test Third-Party potwierdza tylko sprawdzoną w nim ścieżkę ruchu i inspekcji, a nie dostarczenie IoC MDR przez zespół analityków.

Konfiguracja i transport

1. Sprawdzić przełącznik MDR i oczekiwaną Action na zaporze.
2. Zweryfikować rejestrację w Sophos Fusion i licencję MDR.
3. Potwierdzić rejestrowanie Active Threat Response dla oczekiwanego miejsca docelowego.
4. W Sophos Fusion sprawdzić, czy zadania MDR lub zapory zostały pomyślnie przetworzone.
5. W przypadku rzeczywistego incydentu MDR uzgodnić z zespołem MDR oczekiwany IoC i powiązany Audit ID.

Sophos Fusion Firewall Task Queue pokazuje zadania MDR i API. Success potwierdza przetworzenie zadania Sophos Fusion, ale jeszcze nie jego działanie na konkretny przepływ danych. Przy Partial Success lub Failed należy zachować informacje o danej zaporze, Entity, Action i Credential ID oraz porównać je z konfiguracją lokalną.

Analiza trafień w Log Viewer

W Log viewer > Active threat response należy zachować co najmniej następujące informacje:

• znacznik czasu, zaporę oraz, w przypadku HA, węzeł przetwarzający ruch
• Action i nazwę feedu
• źródłowy i docelowy adres IP, domenę lub adres URL
• porty i protokół
• Event ID i pozostałe pola szczegółowe
• w przypadku MDR dodatkowo powiązany audit_ID ze zdarzenia administracyjnego lub Task Queue

Dowód dotyczący ruchu i akcja analityka to odrębne dowody. Brak pola audit_ID we wpisie dotyczącym ruchu sam w sobie nie oznacza błędu dostarczenia. Powiązanie ustala się na podstawie IoC, zapory i przedziału czasu, a w razie wątpliwości potwierdza z MDR.

Dzięki Synchronized Security zapora może dodatkowo pokazywać użytkownika, host i proces dla zarządzanych endpointów Windows. W Log Viewer istotne są w tym celu Process user i Executable, a w widoku szczegółowym host_process_user, endpoint_id i execution_path. W macOS te szczegóły procesu nie są wyświetlane; endpoint identyfikuje się tam na podstawie źródłowego adresu IP i danych Sophos Fusion.

Po wykryciu zapora odpytuje o te szczegóły endpointy zarządzane przez Sophos Fusion. Pomoc opisuje ich wyświetlanie dla Windows 7 i nowszych; nie jest to zalecenie używania Windows 7 ani gwarancja aktualnej obsługi endpointów dla każdego starszego systemu Windows. W macOS może zamiast tego pojawić się ogólny komunikat, taki jak Active threat C2/Generic-C deleted. Nie zastępuje on ani identyfikacji hosta na podstawie źródłowego adresu IP, ani dowodu określającego, jaka akcja zapory została zastosowana do ruchu.

Lokalne podsumowanie znajduje się w Reports > Network & threats > Active threat response, na liście Synchronized IoC. Przegląd usług i plików logów Sophos Firewall dodatkowo wyjaśnia rolę atr.log. Pojedynczego wpisu w logu nigdy nie należy oceniać w oderwaniu od pozostałych: zdarzenia zapory, DNS, Web, IPS, endpointu i Sophos Fusion z tego samego przedziału czasu należy rozpatrywać łącznie.

Test pozytywny i negatywny

Pilotaż produkcyjny powinien obejmować co najmniej te dwa przypadki:

1. Pozytywny: Dla rzeczywistego IoC lub incydentu potwierdzonego przez zespół MDR należy osobno zachować możliwy do zweryfikowania wpis dotyczący ruchu z prawidłową Action oraz powiązaną akcję analityka z Audit ID, a następnie je ze sobą porównać. Nie generuje się w tym celu dodatkowego ruchu do szkodliwej infrastruktury.
2. Negatywny: Porównywalny, legalny proces biznesowy pozostaje dostępny i nie powoduje niezamierzonej blokady MDR.

Bez rzeczywistego incydentu nie tworzy się sztucznie IoC MDR. Zamiast tego sprawdza się konfigurację, przetwarzanie zadań, transport logów i ścieżkę komunikacji. Do w pełni kontrolowanego testu ruchu lepiej nadaje się własny pilotażowy feed Third-Party niż zewnętrzny szkodliwy cel.

Traktowanie trafień MDR jako incydentów

Trafienie MDR to silny sygnał, ale sam wpis w logu nie wyjaśnia jeszcze pełnej ścieżki ataku. Zalecany spokojny tok postępowania:

1. Zachować czas, Action, IoC, nazwę feedu, Event ID i audit_ID.
2. Ustalić host i użytkownika, których dotyczy zdarzenie, na podstawie źródłowego adresu IP, DHCP, Synchronized Security i danych endpointu.
3. Otworzyć w Sophos Fusion powiązaną sprawę MDR, detekcję i pozostałe zdarzenia urządzeń.
4. Skorelować logi zapory, DNS, Web, IPS i endpointu z tego samego przedziału czasu.
5. Wyjaśnić z zespołem MDR, dlaczego IoC został dodany i jaka reakcja jest przewidziana.
6. Po potwierdzeniu naruszenia bezpieczeństwa uruchomić wewnętrzną procedurę reagowania na incydenty.
7. Dopiero potem zdecydować o usunięciu skutków naruszenia, dodatkowych regułach lub wąskim wyjątku.

Audit ID identyfikuje akcję analityka MDR. W Log Viewer należy najpierw kliknąć przycisk widoku szczegółowego, a następnie wybrać Admin z listy rozwijanej. Tam należy zachować akcję i audit_ID dodania lub usunięcia. Alternatywnie akcja analityka jest dostępna w My Products > Firewall management > Tasks Queue w Sophos Fusion. Przy zapytaniu do MDR należy dołączyć do sprawy Audit ID wraz z numerem seryjnym zapory, czasem zdarzenia, IoC, Event ID i Incident ID. Zarejestrowane usunięcie potwierdza operację administracyjną, a nie usunięcie zagrożenia z danego endpointu.

Kontrolowane zarządzanie wyjątkami

W Protect > Active threat response > Add threat exclusions można tworzyć wyjątki dla hostów i sieci oraz wyjątki dotyczące zagrożeń. Obowiązują one we wszystkich modułach. Wyjątek dla trafienia MDR może więc osłabić również X-Ops, NDR lub Third-Party Threat Feeds.

Przed utworzeniem wyjątku należy udokumentować IoC, dany proces biznesowy, sprawę MDR i potwierdzenie fałszywego alarmu. Zakres wyjątku powinien być jak najwęższy; należy przypisać mu uzasadnienie, właściciela, zgłoszenie oraz datę przeglądu lub wygaśnięcia. Całe sieci klienckie ani szerokie zakresy domen nie są odpowiednim sposobem na szybką naprawę.

Konfiguracji feedów zagrożeń nie można osobno importować ani eksportować; Threat Exclusions można. Ustawień feedu MDR nie można również przenieść przez Import existing configuration do początkowej konfiguracji nowej grupy zapór Sophos Fusion. Dlatego po migracji, przywróceniu lub wymianie należy ponownie, jawnie sprawdzić funkcję, Action, rejestrowanie i przypisanie w Sophos Fusion.

Gdy nie pojawia się trafienie MDR

Weryfikacji nie zaczyna się od ponownego uruchomienia usługi. Najpierw należy rozdzielić poszczególne warstwy:

1. Czy licencja MDR, konto Sophos Fusion, rejestracja zapory i Threat response mode są prawidłowe?
2. Czy MDR Threat Feeds są lokalnie aktywne, a Action została zapisana?
3. Czy zespół MDR rzeczywiście przesłał dany IoC dla tego środowiska?
4. Czy Sophos Fusion Firewall Task Queue pokazuje Success, Partial Success, Failed, czy nadal Pending?
5. Czy logi Active Threat Response są włączone lokalnie, dla Syslog lub w Sophos Fusion?
6. Czy ruch przechodzi przez oczekiwaną zaporę, regułę i inspekcję?
7. Czy IoC jest objęty wyjątkami Active Threat Response, Web lub SSL/TLS?
8. Czy przedział czasu jest właściwy, a w przypadku HA analizowany jest odpowiedni węzeł?

Aby sprawdzić stan silnika i feedów, można skorelować czasowo atr.log z Log Viewer i Sophos Fusion Firewall Task Queue. Logi należy tylko odczytywać; nieudokumentowane zmiany danych feedów, baz danych lub usług nie są standardowym krokiem. Jeśli przyczyna pozostaje nieznana, należy zachować CTR, odpowiednie logi, Task ID, Audit ID, kompilację i czas zdarzenia dla Sophos MDR lub Sophos Support.

Wycofywanie zmian i kontrola zmian

Przed aktywacją należy udokumentować poprzedni stan przełącznika, Action, miejsca docelowe logów i istniejące wyjątki. W razie nieoczekiwanego zakłócenia działalności nie należy od razu tworzyć szerokiego wyjątku.

1. Zachować informacje o danym trafieniu i wpływie na działalność.
2. Poinformować zespół MDR, podając Audit ID i incydent.
3. Jeśli zostanie to zatwierdzone przez odpowiedzialne osoby, tymczasowo przełączyć lokalną Action z Log and drop na Log only.
4. Tylko jeśli to również nie wystarcza i MDR wyrazi zgodę, przywrócić feed w kontrolowany sposób do udokumentowanego stanu poprzedniego.
5. Po każdej zmianie ponownie sprawdzić ten sam proces biznesowy i efekt w logach.
6. Usunąć przyczynę i przywrócić ochronę produkcyjną, wyznaczając nowy termin przeglądu.

W środowiskach HA konfigurację i stan sprawdza się na aktualnym Primary. Logi znajdują się na węźle, który przetwarzał ruch. Po kontrolowanym przełączeniu awaryjnym należy ponownie zweryfikować połączenie z Sophos Fusion, stan feedu, nowe wpisy w logach i rzeczywisty ruch; nie zakłada się nieprzerwanej ciągłości MDR ani logów.

Lista kontrolna

• Xstream Protection Bundle jest aktywny
• w Sophos Fusion dostępne jest aktywne uprawnienie MDR
• zapora jest zarejestrowana na właściwym koncie Sophos Fusion
• Threat response mode i ścieżka kontaktu z MDR są udokumentowane
• miejsce docelowe logów Active Threat Response jest aktywne
• MDR Threat Feeds są włączone
• Action została świadomie wybrana, a pilotaż ma ustalony termin zakończenia
• widoczność ruchu dla IPv4, domen i adresów URL została sprawdzona
• Remote source match dla DNAT/WAF jest włączone, jeśli jest potrzebne
• Task Queue i stan lokalny zostały porównane
• Audit ID i proces obsługi incydentów są znane
• kontekst endpointu i ograniczenia platform zostały sprawdzone
• wyjątki mają właściciela i datę przeglądu
• procedura wycofania zmian i weryfikacja HA są udokumentowane

Często zadawane pytania