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 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 Central, 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.

MDR Threat Feeds w ośmiu krokach

1. Sprawdzić, czy na zaporze aktywny jest Xstream Protection Bundle, a w Sophos Central Sophos MDR Essentials lub Sophos MDR Complete.
2. W System > Sophos Central potwierdzić, że właściwa zapora jest zarejestrowana na właściwym koncie Central.
3. Udokumentować w Sophos Central 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 albo Log and drop dla ochrony produkcyjnej po udanej akceptacji, a następnie kliknąć Apply.
7. Wykonać test pozytywny i negatywny za pomocą Log Viewer, kontekstu endpointu i Sophos Central.
8. Udokumentować Audit ID, osoby odpowiedzialne, proces wyjątków, datę przeglądu i rollback.

Ważne: MDR Threat Feeds są tylko częścią działania MDR. Nie zastępują umowy MDR, sensorów endpoint, komunikacji podczas incydentu, precyzyjnych reguł zapory ani przetestowanej ścieżki odzyskiwania. Szeroki wyjątek lub niekontrolowane wyłączenie może osłabić trwającą reakcję zespołu MDR.

Co zapewniają MDR Threat Feeds

Analitycy Sophos MDR mogą przesyłać informacje o aktywnym incydencie bezpośrednio do zapory przez Sophos Central. Feed jest więc bardziej specyficzny dla 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 dopasowaniu:

• Log only rejestruje dopasowanie, ale zezwala na ruch.
• Log and drop rejestruje i odrzuca pasujący ruch.

Sophos zaleca blokowanie znanych IoC. Krótki pilot Log only może jednak być przydatny, jeśli istniejące środowisko musi najpierw zweryfikować widoczność, logowanie i możliwe skutki uboczne. Pilot wymaga ustalonej daty zakończenia. Bez zaplanowanej zmiany aktywna integracja MDR może pozostać na stałe bez lokalnego efektu blokowania.

Threat response mode w Sophos Central i lokalna akcja feedu to dwa odrębne poziomy. Tryb Central określa uprawnienia zespołu MDR do reagowania. Log only lub Log and drop określa sposób traktowania przez zaporę już przesłanego IoC. Przed wdrożeniem oba ustawienia należy uzgodnić z umową MDR i wewnętrznym procesem obsługi incydentów.

Dokładne sprawdzenie wymagań

Licencja i Sophos Central

MDR Threat Feeds wymagają na zaporze Xstream Protection Bundle. Dodatkowo w Sophos Central potrzebny jest Sophos MDR Essentials lub Sophos MDR Complete. Sam pakiet Xstream nie obejmuje pełnej usługi MDR.

Zapora musi być zarejestrowana na właściwym koncie Sophos Central. W System > Sophos Central sprawdza się rejestrację oraz przekazywanie raportów i logów. Łączenie Sophos Firewall z Sophos Central opisuje cały proces.

Przed aktywacją należy również wyjaśnić odpowiedzialności:

• Kto może zmieniać Threat response mode w Central?
• Kto odbiera połączenie lub zapytanie MDR poza godzinami pracy?
• Kto może zatwierdzić wyjątek?
• Gdzie dokumentowane są Audit ID, Incident ID i dowody techniczne?
• Które systemy można odizolować po potwierdzeniu naruszenia?

Aktywacja miejsc docelowych logów

W System services > Log settings, w wierszu Active threat response, aktywować co najmniej jedno z następujących miejsc docelowych:

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

Kolumna Central reporting pojawia się dopiero po aktywacji Send reports and logs to Sophos Central na stronie Sophos Central. Modele XGS 87/87w i 107/107w nie obsługują raportowania lokalnego; wymagają Central Reporting lub Syslog.

Dla powiadomień należy również sprawdzić System services > Notification list. Aktywacja miejsca docelowego logów potwierdza tylko ścieżkę transportu, a nie poprawną obsługę alarmów.

Widoczność adresu IP, domeny i URL

IoC działa tylko na ruch, który zapora może odpowiednio przetworzyć. Przekazywany ruch do docelowego adresu IP wymaga pasującej reguły zapory. Dopasowania domen wymagają Application Classification lub polityki IPS w danej regule. Pełna ścieżka HTTPS URL wymaga Web Proxy z odszyfrowaniem albo DPI z odpowiednią regułą SSL/TLS Inspection.

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

Bezpieczna konfiguracja i eksploatacja Threat Feeds na Sophos Firewall wyjaśnia ogólną logikę ruchu, modułów i inspekcji. Opisuje też, dlaczego wykrywanie domeny lub URL może nie działać bez właściwej klasyfikacji albo odszyfrowania.

Konfiguracja MDR Threat Feeds

1. Zalogować się do WebAdmin za pomocą indywidualnego konta administratora.
2. Otworzyć Protect > Active threat response > MDR threat feeds.
3. Włączyć MDR threat feeds.
4. W Action wybrać Log only dla pilota z określonym terminem lub Log and drop po udanej akceptacji.
5. Zapisać za pomocą Apply.
6. Odświeżyć stronę i sprawdzić, czy przełącznik oraz akcja zostały zapisane.
7. W Audit Trail sprawdzić czas, administratora i zmianę.
8. W Sophos Central potwierdzić, że zapora jest online, a MDR przypisano do właściwego klienta lub tenantu.

Nie należy jednocześnie wprowadzać szerokich zmian w logowaniu, inspekcji, wyjątkach i akcji. Stopniowe wdrożenie pokazuje, która zmiana spowodowała dopasowanie lub skutek uboczny.

Wiarygodna walidacja działania

Sophos nie publikuje ogólnego, nieszkodliwego wskaźnika testowego MDR. Wywoływanie prawdziwej domeny malware lub znanego złośliwego adresu IP nie jest więc odpowiednim testem akceptacyjnym. Kontrolę techniczną dzieli się na kilka możliwych do udowodnienia poziomów.

Konfiguracja i transport

1. Sprawdzić przełącznik MDR i wymaganą akcję na zaporze.
2. Zweryfikować rejestrację Central i licencję MDR.
3. Potwierdzić logowanie Active Threat Response do oczekiwanego miejsca docelowego.
4. W Central sprawdzić, czy zadania MDR lub zapory zostały poprawnie przetworzone.
5. Podczas rzeczywistego incydentu MDR potwierdzić oczekiwany IoC i powiązany Audit ID z zespołem MDR.

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

Analiza dopasowania w Log Viewer

W Log viewer > Active threat response należy zachować co najmniej te informacje:

• znacznik czasu, zapora i w HA węzeł przetwarzający ruch
• akcja i nazwa feedu
• źródłowy i docelowy adres IP, domena lub URL
• porty i protokół
• Event ID i inne pola szczegółowe
• audit_ID dla MDR

Dzięki Synchronized Security zapora może również pokazać użytkownika, host i proces dla zarządzanych endpointów Windows. W Log Viewer istotne są Process user i Executable, a w widoku szczegółowym host_process_user, endpoint_id oraz execution_path. Te dane procesu nie pojawiają się dla macOS; endpoint identyfikuje się tam za pomocą źródłowego adresu IP i danych Central.

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 wyjaśnia również atr.log. Nie należy analizować pojedynczego wpisu w izolacji: trzeba skorelować zdarzenia zapory, DNS, web, IPS, endpoint i Central z tego samego przedziału czasu.

Test pozytywny i negatywny

Pilot produkcyjny powinien obejmować co najmniej te dwa przypadki:

1. Pozytywny: Rzeczywisty IoC lub incydent potwierdzony przez zespół MDR generuje na oczekiwanej zaporze możliwy do prześledzenia wpis z prawidłową akcją i Audit ID.
2. Negatywny: Porównywalny prawidłowy proces biznesowy pozostaje dostępny i nie powoduje niezamierzonej blokady MDR.

Bez rzeczywistego incydentu nie tworzy się sztucznego IoC MDR. Zamiast tego sprawdza się konfigurację, przetwarzanie zadań, transport logów i ścieżkę komunikacji. Do w pełni kontrolowanego testu ruchu własny pilotażowy feed zewnętrzny jest bezpieczniejszy niż obcy złośliwy cel.

Traktowanie dopasowania MDR jako incydentu

Dopasowanie MDR to silny sygnał, ale sam wpis w logu nie wyjaśnia pełnej ścieżki ataku. Spokojny proces wygląda następująco:

1. Zachować czas, akcję, IoC, nazwę feedu, Event ID i audit_ID.
2. Określić host i użytkownika za pomocą źródłowego IP, DHCP, Synchronized Security i danych endpointu.
3. Otworzyć w Sophos Central powiązany przypadek MDR, detekcję i inne zdarzenia urządzenia.
4. Skorelować logi zapory, DNS, web, IPS i endpointu z tego samego przedziału czasu.
5. Wyjaśnić z zespołem MDR, dlaczego dodano IoC i jaka reakcja jest przewidziana.
6. Po potwierdzeniu naruszenia uruchomić wewnętrzny proces reagowania na incydenty.
7. Dopiero potem zdecydować o naprawie, dodatkowych regułach lub wąskim wyjątku.

Audit ID identyfikuje działanie analityka MDR. Jest widoczny w widoku szczegółowym Admin w Log Viewer oraz w My Products > Firewall management > Tasks Queue w Sophos Central. W zapytaniu do MDR należy podać go wraz z numerem seryjnym zapory, czasem, IoC, Event ID i Incident ID.

Kontrolowane zarządzanie wyjątkami

W Protect > Active threat response > Add threat exclusions można dodać wyjątki hostów/sieci oraz zagrożeń. Wyjątki obowiązują między modułami. Wyjątek dla dopasowania MDR może zatem osłabić również X-Ops, NDR lub zewnętrzne Threat Feeds.

Przed dodaniem wyjątku dokumentuje się IoC, dotknięty proces biznesowy, przypadek MDR i potwierdzenie fałszywego alarmu. Wyjątek powinien być możliwie wąski i mieć uzasadnienie, właściciela, ticket oraz datę przeglądu lub wygaśnięcia. Całe sieci klientów ani szerokie zakresy domen nie są właściwą szybką naprawą.

Konfiguracji Threat Feeds nie można oddzielnie importować ani eksportować, natomiast Threat Exclusions można. Ustawień feedu MDR nie można też przenieść przez Import existing configuration do początkowej konfiguracji nowej grupy zapór Central. Po migracji, odtworzeniu lub wymianie należy jawnie ponownie sprawdzić funkcję, akcję, logowanie i przypisanie Central.

Gdy nie pojawia się dopasowanie MDR

Kontrola nie zaczyna się od restartu usługi. Najpierw należy rozdzielić warstwy:

1. Czy licencja MDR, konto Central, rejestracja zapory i Threat response mode są prawidłowe?
2. Czy MDR Threat Feeds jest lokalnie aktywny i zapisano akcję?
3. Czy zespół MDR rzeczywiście przesłał odpowiedni IoC do tego środowiska?
4. Czy Central Task Queue pokazuje Success, Partial Success, Failed, czy nadal Pending?
5. Czy logi Active Threat Response są aktywne lokalnie, dla Syslog lub w Central?
6. Czy ruch przechodzi przez oczekiwaną zaporę, regułę i inspekcję?
7. Czy IoC znajduje się w wyjątku Active Threat Response, web lub SSL/TLS?
8. Czy przedział czasu i, w HA, badany węzeł są właściwe?

Dla stanu silnika i feedu należy czasowo skorelować atr.log z Log Viewer i Central Task Queue. Logi są tylko odczytywane; nieudokumentowane zmiany w danych feedów, bazach danych lub usługach nie są standardowym krokiem. Jeśli przyczyna pozostaje niejasna, należy zebrać CTR, istotne logi, Task ID, Audit ID, build i czas dla Sophos MDR lub Sophos Support.

Rollback i kontrola zmian

Przed aktywacją dokumentuje się poprzedni stan przełącznika, akcję, miejsca docelowe logów i istniejące wyjątki. W razie nieoczekiwanego wpływu na biznes nie należy od razu tworzyć szerokiego wyjątku.

1. Zachować dotknięte dopasowanie i wpływ na biznes.
2. Poinformować zespół MDR, podając Audit ID i incydent.
3. Jeśli zatwierdzono, tymczasowo zmienić lokalną akcję z Log and drop na Log only.
4. Tylko jeśli to nie wystarczy i MDR wyrazi zgodę, kontrolowanie przywrócić feed 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ą z nową datą 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 failoverze należy ponownie zweryfikować połączenie Central, stan feedu, nowe wpisy logów i rzeczywisty ruch; nie zakładać nieprzerwanej ciągłości MDR ani logów.

Lista kontrolna

• aktywny Xstream Protection Bundle
• aktywny Sophos MDR Essentials lub MDR Complete
• zapora zarejestrowana na właściwym koncie Central
• udokumentowany Threat response mode i ścieżka kontaktu MDR
• aktywne miejsce docelowe logów Active Threat Response
• włączony MDR Threat Feeds
• świadomie wybrana akcja i pilot z określonym terminem
• sprawdzona widoczność ruchu dla IPv4, domeny i URL
• Remote source match aktywny dla DNAT/WAF, gdy jest potrzebny
• porównane Task Queue i stan lokalny
• znany Audit ID i proces obsługi incydentu
• sprawdzony kontekst endpointu i ograniczenia platformy
• wyjątki z właścicielem i datą przeglądu
• udokumentowany rollback i test HA

Często zadawane pytania