Sophos Firewall ATP: konfiguracja X-Ops Threat Feeds

Dawna funkcja Advanced Threat Protection (ATP) nosi w SFOS 22 nazwę Sophos X-Ops Threat Feeds. Firewall porównuje ruch wychodzący z zarządzaną przez Sophos bazą znanych złośliwych adresów IP, domen i URL. Może dzięki temu na przykład uniemożliwić zainfekowanemu klientowi połączenie ze znanym serwerem Command and Control.

Threat Feed to stale aktualizowana lista takich wskaźników, w skrócie IoCs (Indicators of Compromise). X-Ops automatycznie otrzymuje globalną bazę danych SophosLabs; nie wprowadza się własnego adresu URL feedu. W sekcji Active Threat Response można skonfigurować jeden lub kilka modułów: MDR Threat Feeds dostarczają informacje od analityków MDR o aktywnych zagrożeniach we własnej sieci; NDR Essentials analizuje ruch zapory przy użyciu uczenia maszynowego, ocenia wykryte IoCs i zapisuje je w logach. Natomiast w przypadku Third-Party Threat Feeds wprowadza się własne adresy URL feedów. Aktywny moduł X-Ops nie włącza automatycznie pozostałych modułów.

Docelową akcją w środowisku produkcyjnym jest Log and drop. Funkcja jest domyślnie wyłączona, a po jej włączeniu blokuje ruch tylko wtedy, gdy wybrano tę akcję.

Konfiguracja X-Ops Threat Feeds

Moduł X-Ops wymaga licencji Network Protection. Do realizacji kontroli threat feedów potrzebna jest dodatkowo licencja Web Protection. Obie licencje są zawarte w pakietach Standard i Xstream Protection lub można je nabyć oddzielnie; X-Ops nie wymaga dodatkowej licencji Sophos Fusion (wcześniej Sophos Central).

Przed wprowadzeniem zmian dokumentuje się kompilację firmware, licencje, dotychczasową wartość Action, zakres sprawdzania, miejsca docelowe logów i wyjątki. Do korzystania z Synchronized Security wymagana jest dodatkowo licencja Intercept X w Sophos Fusion lub Sophos Central; sama licencja X-Ops nie zapewnia integracji z endpointami. Sprawdza się również, czy reguły zapory reagują na czerwony status Security Heartbeat: zmiana statusu opisana w dokumentacji SFOS 23 może wtedy wpływać na dostęp endpointa, niezależnie od zablokowania pojedynczego połączenia.

1. Otworzyć System services > Log settings.

2. W wierszu Active threat response włączyć co najmniej Local reporting. Zależnie od modelu eksploatacji wybrać także docelowy serwer Syslog i Central reporting. Na stronie Log settings zapisać za pomocą Apply miejsca docelowe logów obsługiwane przez ten model. Ponownie wczytać stronę i potwierdzić, że wybrane miejsca docelowe są nadal ustawione, zanim przejdzie się do konfiguracji X-Ops. Lokalne logi zdarzeń nie są tym samym co lokalne raportowanie; alternatywy dla modeli bez lokalnego raportowania podano poniżej.

3. Otworzyć Protect > Active threat response > Sophos X-Ops threat feeds.

4. Włączyć Sophos X-Ops threat feeds.

5. W polu Action wybrać Log only dla krótkiego, kontrolowanego pilota albo Log and drop dla ochrony produkcyjnej.

   SFOS 23: Log only rejestruje zdarzenie bez zmiany statusu Security Heartbeat endpointu. Log and drop rejestruje zdarzenie, blokuje zagrożenie i zmienia status Security Heartbeat endpointu na czerwony.

6. W sekcji Advanced security settings zdecydować między Inspect untrusted content i Inspect all content.

7. Zapisać przez Apply.

8. Następnie sprawdzić ustawienie, miejsca docelowe logów i istniejące wyjątki.

Modele XGS 87/87w i 88/88w nie obsługują lokalnego raportowania. Na tych urządzeniach należy użyć Central Reporting albo serwera Syslog. Kolumna Central reporting pojawia się dopiero po włączeniu Send reports and logs to Sophos Central w sekcji Sophos Fusion (wcześniej Sophos Central).

Sophos zaleca blokowanie znanych IoC zamiast samego rejestrowania zdarzeń. W nowym lub dotąd niemonitorowanym środowisku Log only może jednak pomóc podczas krótkiej, jasno ograniczonej czasowo fazy obserwacji. Taka faza wymaga osoby odpowiedzialnej oraz daty przełączenia; w przeciwnym razie funkcja może pozostać na stałe bez działania blokującego.

Co chroni X-Ops, a czego nie chroni

X-Ops sprawdza znane złośliwe cele w przekazywanym ruchu wychodzącym. Typowe zdarzenie powstaje, gdy klient lub serwer próbuje połączyć się ze znanym adresem IP, domeną lub URL powiązanym z malware, phishingiem albo C2. Zależnie od wybranej akcji próba jest jedynie rejestrowana lub od razu odrzucana.

Przegląd i opis X-Ops nie są ze sobą w pełni zgodne: macierz ruchu w przeglądzie SFOS 22/23 oznacza Destination Match dla X-Ops jako nieobsługiwany, a lokalny Source Match jako obsługiwany. Sekcja konfiguracji X-Ops opisuje natomiast dopasowywanie złośliwych adresów IP, domen i adresów URL, na którym opiera się sprawdzanie celów w tym artykule. Z tej sprzecznej macierzy nie można wywnioskować ani gwarancji ochrony wszystkich celów ruchu przekazywanego, ani wiarygodnego zakresu obsługi lokalnego Source Match. Aby ustalić ten zakres, przed zastąpieniem istniejących reguł ochrony potrzebne jest potwierdzenie dla używanej kompilacji. Macierz zgodnie wskazuje brak ochrony X-Ops dla zdalnych źródeł w przypadku DNAT/WAF oraz dla źródeł ruchu kierowanego do samego systemu: WebAdmin, VPN-Portal lub VPN. Dla tych usług nadal konieczne są restrykcyjne reguły zapory, WAF i Device Access; alternatywne feedy omówiono w artykule o Third-Party Threat Feeds.

IPS, Malware Scanning i Zero-Day Protection również mają inne zadania. X-Ops działa na podstawie wskaźników: cel musi być już znany jako złośliwy IoC. IPS rozpoznaje natomiast znane wzorce ataków w ruchu. Obie funkcje się uzupełniają, ale się nie zastępują.

Active Threat Response sprawdza moduły w następującej kolejności: MDR, NDR Essentials, Sophos X-Ops, a następnie Third-Party Threat Feeds. Jeśli wcześniejszy moduł zablokuje ten sam IoC, firewall przerywa dalszą kontrolę. Brak wpisu X-Ops w logu nie oznacza więc automatycznie, że żadna ochrona nie zadziałała. Przewodnik po Third-Party Threat Feeds dokładniej wyjaśnia kolejność i nakładające się wskaźniki.

Warunki potrzebne do wykrywania zdarzeń

Sama aktywacja nie gwarantuje, że firewall zobaczy każdy wskaźnik IP, domenę lub URL. Decyduje o tym informacja widoczna w danej ścieżce sieciowej.

Adresy IP

Aby dopasować docelowy adres IP, ruch wychodzący musi przechodzić przez odpowiednią regułę firewall. Firewall może bezpośrednio porównać adres docelowy z feedem X-Ops; odszyfrowanie TLS nie jest do tego potrzebne.

Domeny

Aby wykrywanie domen działało, wymagane ustawienia związane z IPS muszą być aktywne: Application Classification musi być włączone lub w odpowiedniej regule zapory musi być wybrana polityka IPS. Zgodnie z dokumentacją Application Classification jest domyślnie włączone; mimo to sprawdza się jego rzeczywisty stan. Nie należy traktować go tutaj jako dodatkowego przełącznika w każdej regule zapory. Wymóg dotyczy w szczególności HTTPS oraz zapytań DNS do zewnętrznych resolverów przez HTTP lub HTTPS. Jeśli brakuje wymaganej klasyfikacji, dopasowywanie domen może nie działać w danej ścieżce ruchu.

Jeśli firewall sam odpowiada na zapytania DNS klientów, dopasowanie domeny wykonuje moduł DNS. Gdy klienci używają zewnętrznego resolvera, także ta ścieżka DNS musi przechodzić przez firewall i być widoczna dzięki wymaganym ustawieniom IPS. Przy braku zdarzenia domenowego należy więc sprawdzić faktycznie używaną ścieżkę resolvera, a nie tylko regułę klienta do miejsca docelowego w sieci Web.

Pełne URL przez HTTPS

URL oprócz domeny zawiera także ścieżkę, na przykład https://example.invalid/download/payload.exe. W zaszyfrowanym ruchu HTTPS bez odszyfrowania firewall widzi przez SNI zazwyczaj tylko domenę, a nie ścieżkę /download/payload.exe.

Sprawdzenie pełnego wskaźnika URL wymaga Web Proxy z włączonym odszyfrowaniem HTTPS albo odpowiedniej reguły SSL/TLS Inspection z akcją Decrypt. TLS Inspection nie należy włączać globalnie i bez kontroli wyłącznie na potrzeby X-Ops: dystrybucja certyfikatów, prywatność, wyjątki, zgodność aplikacji i wydajność wymagają osobnego wdrożenia.

W przypadku Web Proxy w odpowiedniej regule zapory, w sekcji Web filtering, wybiera się opcje Use web proxy instead of DPI engine i Decrypt HTTPS during web proxy filtering. W przypadku ścieżki DPI opcja Use web proxy instead of DPI engine pozostaje wyłączona; odpowiednią regułę deszyfrowania konfiguruje się w Rules and policies > SSL/TLS inspection rules, ustawiając Action na Decrypt. Obie ścieżki wymagają również spełnienia wymienionych wyżej warunków klasyfikacji, aby umożliwić pełne sprawdzanie adresów URL w HTTPS. Zmienia się tylko zatwierdzoną ścieżkę ruchu, a następnie sprawdza zaufanie do certyfikatów, normalny przebieg procesu biznesowego oraz regułę faktycznie dopasowaną do ruchu w Log Viewer.

Świadomy wybór zakresu inspekcji

W sekcji Advanced security settings określa się, jak szeroko X-Ops ma sprawdzać ruch:

• Inspect untrusted content ogranicza kontrolę do ruchu z niezaufanymi źródłami lub celami. Zużywa mniej zasobów i jest rozsądnym punktem wyjścia, gdy obciążenie i skutki uboczne nie są jeszcze znane.
• Inspect all content sprawdza ruch zaufany i niezaufany. Zapewnia szersze pokrycie, lecz może wpływać na wydajność, zwłaszcza w środowiskach o dużym natężeniu ruchu.

Dla szczególnie chronionych sieci klientów, serwerów lub administracji Inspect all content może być właściwym wyborem, jeżeli appliance ma wystarczającą rezerwę. Zmianę należy przeprowadzić w oknie serwisowym. Następnie porównuje się obciążenie CPU, opóźnienia, przepustowość i zgłoszenia helpdesku ze stanem wcześniejszym.

Dokumentacja opisuje różnicę wydajności między dwoma zakresami sprawdzania jako zazwyczaj niewielką, ale przy dużym natężeniu ruchu potencjalnie znaczną. Przed zmianą zapisuje się dotychczasową wartość. Jeśli porównanie wykaże istotne pogorszenie, w sekcji Advanced security settings przywraca się poprzedni zakres sprawdzania, zapisuje ustawienie za pomocą Apply i ponownie sprawdza proces biznesowy, obciążenie oraz rejestrowanie zdarzeń. Nie wymaga to całkowitego wyłączenia akcji blokowania.

Podczas wdrażania lepiej nie zmieniać wielokrotnie i jednocześnie akcji oraz zakresu inspekcji. Zmiana najpierw widoczności, a później akcji blokującej ułatwia ustalenie, które ustawienie spowodowało problem.

Kontrola działania i rejestrowania zdarzeń

Po zapisaniu nie wystarczy sprawdzić, czy przełącznik jest aktywny. Wiarygodna kontrola operacyjna obejmuje trzy poziomy:

1. Konfiguracja: X-Ops jest włączony, a wybrana Action i zakres inspekcji zostały zapisane.
2. Widoczność: reguła firewall, Application Classification lub IPS oraz, dla pełnych URL HTTPS, odszyfrowanie TLS odpowiadają typowi wskaźnika.
3. Dowód: zdarzenia są widoczne w Log viewer > Active threat response albo w skonfigurowanym celu Central lub Syslog.

Aby wyświetlić lokalne podsumowanie, otwiera się Reports > Network & threats > Active threat response. Widżet o tej samej nazwie w Control Center pokazuje przegląd hostów, których dotyczą zdarzenia, oraz zdarzeń związanych z zagrożeniami. MDR i X-Ops pokazują status i zablokowane zagrożenia, a NDR Essentials — status i monitorowane zagrożenia; Third-Party Threat Feeds pokazują dodatkowo skonfigurowane feedy i stan ich synchronizacji. Configure prowadzi do konfiguracji, Reports do raportów, a More details rozszerza widok widżetu. Na urządzeniach bez lokalnego raportowania przycisk Reports jest niedostępny; korzysta się tam ze skonfigurowanych miejsc docelowych Central lub Syslog. Liczba zagrożeń monitorowanych przez NDR nie stanowi dowodu ich zablokowania. Konkretną akcję i szczegóły połączenia sprawdza się w raporcie lub Log Viewer. Widżet pokazuje dla Third-Party Threat Feeds także liczbę zagrożeń zablokowanych przez te feedy.

Techniczny typ logu Syslog nadal nazywa się ATP, mimo że interfejs używa dziś nazw X-Ops i Active Threat Response. Zależnie od ścieżki przetwarzania log_component może wskazywać Firewall, DNS, IPS lub Web. W analizie szczególnie przydatne są znacznik czasu, akcja, Source, Destination, porty, domena lub URL, Threat Name, Feed Name i Event ID.

W Advanced Shell ips.log jest głównym logiem silnika Active Threat Response. garner.log pomaga analizować przetwarzanie i przekazywanie zdarzeń, zwłaszcza gdy Central Reporting wygląda na niekompletny. Przegląd usług i logów Sophos Firewall wyjaśnia te pliki oraz bezpieczny dostęp SSH.

Nie ma powszechnie udokumentowanego, nieszkodliwego wskaźnika testowego X-Ops. Nie należy więc celowo otwierać prawdziwej domeny malware ani łączyć się ze znanym złośliwym adresem IP. Jeśli potrzebny jest powtarzalny test, bezpieczniejszą metodą jest własny Third-Party Pilot Feed z kontrolowanym celem testowym. W X-Ops sprawdza się konfigurację i widoczność; faktyczne działanie blokowania potwierdzi następne rzeczywiste, dokładnie przeanalizowane zdarzenie.

Gdy IoC nie jest blokowany lub nie pojawia się log X-Ops

Sprawdzanie należy zacząć od konkretnego typu wskaźnika i rzeczywistej ścieżki ruchu. Pozwala to uniknąć szerokich wyjątków lub globalnych zmian TLS wprowadzanych na podstawie przypuszczeń:

1. W Protect > Active threat response > Sophos X-Ops threat feeds sprawdzić, czy X-Ops jest aktywny, a Action rzeczywiście ma wartość Log and drop. Log only tworzy tylko wpis.
2. W Log viewer > Active threat response sprawdzić moduł, faktyczną akcję i szczegóły połączenia dla tego samego IoC. Tylko potwierdzona akcja blokująca wcześniejszego modułu, na przykład MDR z Log and drop, kończy dalsze sprawdzanie przed X-Ops. NDR Essentials wykrywa i rejestruje zagrożenia za pomocą Log threats, ale ich nie blokuje. Samo monitorowane zdarzenie NDR nie kończy sprawdzania przez X-Ops i nie wyjaśnia braku wpisu X-Ops w logach.
3. Dla docelowego adresu IP sprawdzić faktycznie dopasowaną regułę LAN-to-WAN. Dla domeny sprawdzić także Application Classification, politykę IPS i ścieżkę resolvera.
4. Dla pełnego URL HTTPS wyszukać nazwę serwera w Log viewer > SSL/TLS inspection. Jeśli pasująca SSL/TLS rule wskazuje Don't decrypt, X-Ops nie widzi ścieżki URL. Dopiero po zidentyfikowaniu tej reguły zaplanować możliwie wąską regułę Decrypt.
5. W Log viewer > Web filter wyszukać domenę lub adres URL; dodatkowo sprawdzić kolumnę Category i widok szczegółów. Można tam ustalić identyfikator reguły zapory i wybraną politykę WWW. Jeśli odpowiedzialna Web policy wskazuje Allow, sprawdzić kolejność reguł i polityk. Dla potwierdzonej złośliwej domeny lub adresu URL można użyć grupy adresów URL o wąskim zakresie wraz z akcją polityki WWW Block w odpowiedniej regule LAN-to-WAN, umieszczonej powyżej reguły, która dotychczas zezwalała na ruch. W przypadku ścieżki Web Proxy dodatkowo sprawdzić Web > Exceptions: URL pattern matches, Web categories, Destination IP addresses i Source IP addresses mogą obejmować wskaźnik lub endpoint wysyłający żądanie. W przypadku ścieżki DPI sprawdzić SSL/TLS Exclusion Lists. Wyjątku nie usuwa się bezwarunkowo; najpierw wyjaśnia się jego cel, proces biznesowy, którego dotyczy, oraz zatwierdzenie.
6. W Protect > Active threat response > Add threat exclusions wyszukać zarówno IoC, jak i host lub sieć wysyłającą żądanie. Wyjątki te dotyczą wszystkich modułów.

Po każdej korekcie ponownie wykonać ten sam proces biznesowy i sprawdzić odpowiednie logi. Jeśli przyczyna nadal jest niejasna, zapisać znacznik czasu, ID reguły firewall, ID reguły Web lub SSL/TLS oraz szczegółowy widok zdarzenia Active Threat Response do zgłoszenia wsparcia.

Analiza alarmu X-Ops

Zablokowany IoC jest istotnym sygnałem, ale nie stanowi jeszcze pełnej analizy incydentu. Z adresem docelowym mogło połączyć się malware, link phishingowy, przejęte rozszerzenie przeglądarki albo legalna usługa sklasyfikowana błędnie.

Przydatna kolejność działań:

1. Zabezpieczyć znacznik czasu, firewall lub węzeł HA, akcję i pełne szczegóły logu.
2. Zapisać Source IP, Destination IP, domenę lub URL, porty, protokół, Threat Name i Feed Name.
3. Skorelować logi firewall, DNS, IPS i Web z tego samego przedziału czasu.
4. Zidentyfikować klienta wewnętrznego przez DHCP Lease, przypisanie użytkownika lub dane endpointu.
5. Na danym systemie sprawdzić powiązany proces, historię przeglądarki, pobranie i inne zdarzenia bezpieczeństwa.
6. Po potwierdzeniu kompromitacji odizolować system i obsłużyć go zgodnie z wewnętrznym runbookiem Incident Response.
7. Dopiero po analizie zdecydować o czyszczeniu, dodatkowej blokadzie lub bardzo wąskim wyjątku.

W przypadku Synchronized Security na obsługiwanych endpointach Windows mogą pojawić się także użytkownik procesu, Endpoint ID i ścieżka wykonania. Na macOS te informacje o procesie nie są dostępne; Source IP pozostaje tam szczególnie ważny dla identyfikacji.

Znany fałszywy alarm HA NC-170292

W systemie HA z SFOS 21.5.1 MR1 Build 261 problem NC-170292 może wygenerować w Sophos Fusion fałszywy alarm Advanced threat detected z Raw Logs. Jednocześnie może nadejść wiadomość e-mail z firewalla bez przydatnych szczegółów.

To ograniczenie nie dotyczy ogólnie innych buildów ani firewalli standalone. Alarm należy więc najpierw zabezpieczyć i przeanalizować zgodnie z powyższym opisem. Jeśli system dokładnie odpowiada wersji objętej problemem i brakuje wiarygodnych szczegółów zdarzenia, Sophos wskazuje restart usługi Garner jako tymczasowe obejście. Ponieważ Known Issues List nie podaje konkretnego polecenia CLI dla tego błędu, restart należy wykonywać wyłącznie zgodnie z zatwierdzoną procedurą wsparcia lub utrzymania. Przy powtarzających się alarmach do zgłoszenia Sophos Support należy dołączyć status HA, firmware build, znacznik czasu i garner.log.

Wyjątki dopiero po potwierdzonej analizie

W Protect > Active threat response > Add threat exclusions można dodać Host and network exclusions oraz Threat exclusions dla adresów IP, domen lub URL. Wpis w Threat exclusions może mieć maksymalnie 128 znaków. Taki wyjątek nie dotyczy wyłącznie X-Ops, lecz wszystkich modułów Active Threat Response. Szybko dodany wyjątek może więc jednocześnie osłabić ochronę MDR, NDR lub Third-Party Threat Feeds.

Po potwierdzeniu false positive należy wykluczyć tylko najmniejszy niezbędny wskaźnik. Wyjątek powinien mieć uzasadnienie, numer ticketu, osobę odpowiedzialną i datę przeglądu. Prewencyjne wykluczanie całych sieci klienckich lub szerokich zakresów domen usuwa widoczny alarm, ale także dużą część ochrony.

Aby dodać zatwierdzony wyjątek, otwiera się Protect > Active threat response > Add threat exclusions i zależnie od rodzaju wyjątku wybiera jedną z poniższych alternatyw:

• Hosty lub sieci: W sekcji Host and network exclusions kliknąć Add new item i wybrać tylko zatwierdzone obiekty hostów lub sieci.
• Wskaźnik zagrożenia: Zamiast tego w sekcji Threat exclusions wprowadzić zatwierdzony adres IP, domenę lub adres URL i dodać go do listy za pomocą Add. Przestrzegać limitu 128 znaków na wpis.

Następnie zapisać za pomocą Apply. Ponownie otworzyć stronę i sprawdzić, czy zapisane są tylko zamierzone wpisy. Samo użycie Add new item lub Add nie zastępuje tego końcowego kroku zapisywania.

Po zmianie ponownie sprawdza się ten sam proces biznesowy i w Log Viewer potwierdza, że znika tylko zamierzone zdarzenie. Pozostałe zdarzenia X-Ops muszą być nadal rejestrowane albo blokowane.

Aby powrócić do poprzedniego stanu, cofa się tylko ostatnio wprowadzoną zmianę: zakres inspekcji ustawia się na udokumentowaną poprzednią wartość i zapisuje za pomocą Apply; nowo utworzoną regułę lub wyjątek Web/SSL/TLS wycofuje się w sposób ukierunkowany, bez zmieniania istniejących reguł ani innych wyjątków. Następnie ponownie sprawdza się proces biznesowy, regułę, do której faktycznie następuje dopasowanie, oraz logi. Jeśli wyjątek zostanie wycofany, dane dopasowanie może zostać ponownie zablokowane. Jeśli z powodu zakłócenia działania konieczne jest tymczasowe użycie Log only, w tym czasie X-Ops przestaje blokować; określa się osoby odpowiedzialne i czas zakończenia, a po wyjaśnieniu przyczyny przywraca się Log and drop. Wyłączony moduł nie jest równoważnym sposobem powrotu do poprzedniego stanu, ponieważ przestaje on również przeprowadzać inspekcję. Kontrolowany test z użyciem własnego, dedykowanego feedu pilotażowego w Third-Party Threat Feeds potwierdza tylko ścieżkę ruchu dla tego feedu, a nie dostarczenie bazy danych X-Ops ani dopasowanie do jej wpisów.

XML API: oddzielne traktowanie aktywacji, akcji i wyjątków

Automatyzacja X-Ops wymaga rozróżnienia trzech niezależnych ustawień w udokumentowanym obiekcie XML ATP. Dokumentacja API dla SFOS 22/23 opisuje:

• ATP/ThreatProtectionStatus: skalarny przełącznik modułu o wartości Enable lub Disable. Włącza lub wyłącza X-Ops; nie jest ani akcją wykonywaną przy dopasowaniu, ani pojedynczym wyjątkiem.
• ATP/Policy: skalarna akcja wykonywana przy dopasowaniu. Tabela parametrów wymienia Log Only i Log and Drop, podaje Log Only jako wartość domyślną i oznacza pole jako wymagane, gdy X-Ops jest włączony. Jest to informacja z tabeli API, a nie dowód na stan zapisany we własnym firewallu.
• ATP/InspectContent: skalarny zakres inspekcji o wartości all lub untrusted. Inny zakres inspekcji nie jest równoznaczny z Disable ani ze zmianą akcji wykonywanej przy dopasowaniu.
• ATP/HostException/Host: lista ciągów znaków określających hosty lub sieci źródłowe, które mają zostać wykluczone. W przykładzie widnieje HostName; do utworzenia wpisu potrzebne jest zatwierdzone odwołanie do obiektu z własnej konfiguracji.
• ATP/ThreatException/Threat: oddzielna lista ciągów znaków określających wskaźniki docelowe, które mają zostać wykluczone. Tabela API wymienia docelowe adresy IP i domeny. Opisana powyżej możliwość wprowadzania adresów URL w interfejsie sama w sobie nie dowodzi, jaka składnia danych żądania XML jest prawidłowa dla adresów URL.

Obie listy wyjątków są więc zagnieżdżone pod różnymi elementami nadrzędnymi i mogą zawierać wiele wpisów. Nie są globalnymi przełącznikami wyłączającymi. Tabela API opisuje ich działanie dla X-Ops, MDR i Third-Party Threat Feeds; dlatego nadal istotne są szersze ostrzeżenie dotyczące wpływu na inne moduły oraz zasady zatwierdzania opisane w sekcji o wyjątkach.

Przed wysłaniem żądania zapisu wyjaśnić rozbieżność dotyczącą Policy: Przykład XML używa dla Policy tekstu alert/drop, podczas gdy tabela parametrów wymienia Log Only i Log and Drop. Tych zapisów nie przekształca się automatycznie jeden w drugi; również pisownia etykiet interfejsu nie stanowi dowodu na prawidłową wartość API. Przed automatyzacją potwierdza się konkretną wartość i strukturę żądania na podstawie pomocy API zainstalowanej kompilacji lub z Sophos Support. Do tego czasu przykład nie jest gotowym do skopiowania żądaniem o zweryfikowanym działaniu.

Bezpieczna konfiguracja XML API została omówiona osobno. Przed zatwierdzoną zmianą zapisuje się stan modułu, akcję, zakres inspekcji i obie listy wyjątków. Następnie ponownie odczytuje się faktycznie zapisany stan lub otwiera stronę konfiguracji i porównuje każdy z tych pięciu obszarów oddzielnie. W razie błędu przed ponowieniem żądania najpierw sprawdza się zapisany stan; wyjątek ani inny zakres inspekcji nie mogą niezamierzenie doprowadzić do globalnego wyłączenia.