Sophos Firewall ATP: X-Ops Threat Feeds konfigurieren

Die frühere Advanced Threat Protection (ATP) heisst in SFOS 22 Sophos X-Ops Threat Feeds. Die Firewall gleicht ausgehenden Traffic mit einer von Sophos gepflegten Datenbank bekannter schädlicher IP-Adressen, Domains und URLs ab. So kann sie beispielsweise verhindern, dass ein infizierter Client einen bekannten Command-and-Control-Server erreicht.

Ein Threat Feed ist eine laufend aktualisierte Liste solcher Indikatoren, kurz IoCs (Indicators of Compromise). X-Ops erhält die globale SophosLabs-Datenbank automatisch; es wird keine eigene Feed-URL eingetragen. Unter Active Threat Response lassen sich einzelne oder mehrere Module konfigurieren: MDR Threat Feeds liefern Hinweise der MDR-Analysten zu aktiven Bedrohungen im eigenen Netz; NDR Essentials analysiert Firewall-Traffic mit Machine Learning, bewertet erkannte IoCs und protokolliert sie. Bei Third-Party Threat Feeds hinterlegt man dagegen eigene Feed-URLs. Ein aktives X-Ops-Modul schaltet die anderen Module nicht automatisch ein.

Für den produktiven Einsatz ist Log and drop das Ziel. Die Funktion ist standardmässig ausgeschaltet und blockiert nach dem Aktivieren nur dann, wenn diese Aktion ausgewählt wurde.

X-Ops Threat Feeds einrichten

Das X-Ops-Modul benötigt Network Protection. Für die Umsetzung der Threat-Feed-Prüfung ist zusätzlich Web Protection erforderlich. Beide Lizenzen sind im Standard- und Xstream-Protection-Bundle enthalten oder können einzeln lizenziert werden; eine zusätzliche Sophos-Fusion-Lizenz (ehemals Sophos Central) ist für X-Ops nicht erforderlich.

Vor Änderungen werden Firmware-Build, Lizenzen, bisherige Action, Prüfumfang, Logziele und Ausnahmen dokumentiert. Für Synchronized Security ist zusätzlich eine Intercept-X-Lizenz in Sophos Fusion beziehungsweise Sophos Central erforderlich; die X-Ops-Lizenz allein liefert keine Endpoint-Integration. Man prüft auch, ob Firewall-Regeln auf einen roten Security Heartbeat reagieren: Die in SFOS 23 dokumentierte Statusänderung kann dann zusätzlich zur einzelnen blockierten Verbindung den Zugriff des Endpoints beeinflussen.

1. System services > Log settings öffnen.

2. In der Zeile Active threat response mindestens Local reporting aktivieren. Je nach Betrieb zusätzlich das gewünschte Syslog-Ziel und Central reporting auswählen. Die auf diesem Modell unterstützten Logziele auf der Seite Log settings mit Apply speichern. Die Seite neu laden und bestätigen, dass die ausgewählten Ziele weiterhin gesetzt sind, bevor man zur X-Ops-Konfiguration wechselt. Lokale Ereignislogs sind nicht mit lokalem Reporting gleichzusetzen; die Alternativen für Modelle ohne lokales Reporting stehen unten.

3. Protect > Active threat response > Sophos X-Ops threat feeds öffnen.

4. Sophos X-Ops threat feeds einschalten.

5. Als Action entweder Log only für einen kurzen kontrollierten Pilot oder Log and drop für den produktiven Schutz wählen.

   SFOS 23: Log only protokolliert den Treffer, ohne den Security-Heartbeat-Status des Endpoints zu ändern. Log and drop protokolliert und blockiert den Treffer und setzt den Security-Heartbeat-Status des Endpoints auf rot.

6. Unter Advanced security settings zwischen Inspect untrusted content und Inspect all content entscheiden.

7. Mit Apply speichern.

8. Danach Einstellung, Logziele und vorhandene Ausnahmen kontrollieren.

XGS 87/87w und 88/88w unterstützen kein lokales Reporting. Auf diesen Modellen wird stattdessen Central Reporting oder ein Syslog-Server verwendet. Die Spalte Central reporting erscheint erst, nachdem unter Sophos Fusion (ehemals Sophos Central) die Option Send reports and logs to Sophos Central aktiviert wurde.

Sophos empfiehlt, bekannte IoCs zu blockieren und nicht nur zu protokollieren. Für eine neue oder bisher nicht überwachte Umgebung kann Log only trotzdem für eine kurze, klar terminierte Beobachtungsphase sinnvoll sein. Diese Phase braucht einen Verantwortlichen und ein Umstellungsdatum; sonst bleibt die Funktion leicht dauerhaft ohne Blockwirkung aktiv.

Was X-Ops schützt – und was nicht

X-Ops prüft bekannte schädliche Ziele im ausgehenden, weitergeleiteten Traffic. Ein typischer Treffer entsteht, wenn ein Client oder Server eine bekannte Malware-, Phishing- oder C2-IP, -Domain oder -URL aufrufen will. Je nach Aktion wird der Versuch nur protokolliert oder direkt verworfen.

Die Übersicht und die X-Ops-Beschreibung sind nicht widerspruchsfrei: Die Traffic-Matrix der SFOS-22/23-Übersicht markiert für X-Ops den Destination Match als nicht unterstützt, den lokalen Source Match dagegen als unterstützt. Der X-Ops-Konfigurationsabschnitt beschreibt hingegen den Abgleich schädlicher IP-Adressen, Domains und URLs, auf dem die Zielprüfung in diesem Artikel beruht. Aus dieser widersprüchlichen Matrix lässt sich weder eine Garantie für alle weitergeleiteten Ziele noch eine belastbare lokale Source-Match-Abdeckung ableiten. Für diese Abgrenzung braucht es eine Bestätigung für den eingesetzten Build, bevor man bestehende Schutzregeln ersetzt. Übereinstimmend zeigt die Matrix keinen X-Ops-Schutz für entfernte Quellen bei DNAT/WAF und für Quellen systembestimmten Traffics zu WebAdmin, VPN-Portal oder VPN. Für diese Dienste bleiben restriktive Firewall-, WAF- und Device-Access-Regeln notwendig; alternative Feeds werden im Artikel über Third-Party Threat Feeds eingeordnet.

Auch IPS, Malware Scanning und Zero-Day Protection lösen andere Aufgaben. X-Ops arbeitet indikatorbasiert: Ein Ziel muss bereits als schädlicher IoC bekannt sein. IPS erkennt dagegen bekannte Angriffsmuster im Traffic. Beide Funktionen ergänzen sich, ersetzen einander aber nicht.

Active Threat Response prüft die Module in der Reihenfolge MDR, NDR Essentials, Sophos X-Ops und Third-Party Threat Feeds. Blockiert ein früheres Modul denselben IoC, beendet die Firewall die weitere Prüfung. Ein fehlender X-Ops-Logeintrag bedeutet deshalb nicht automatisch, dass kein Schutz gegriffen hat. Die Details zur Reihenfolge und zu überschneidenden Indikatoren stehen im Artikel über Third-Party Threat Feeds.

Welche Voraussetzungen für Treffer gelten

Die Aktivierung allein garantiert noch nicht, dass die Firewall jeden IP-, Domain- oder URL-Indikator sehen kann. Entscheidend ist, welche Information im jeweiligen Netzwerkpfad sichtbar ist.

IP-Adressen

Für einen Ziel-IP-Treffer muss der ausgehende Traffic durch eine passende Firewall-Regel laufen. Die Firewall kann die Zieladresse direkt mit dem X-Ops-Feed vergleichen; eine TLS-Entschlüsselung ist dafür nicht erforderlich.

Domains

Für Domain-Erkennung müssen die erforderlichen IPS-bezogenen Einstellungen wirksam sein: Application Classification muss eingeschaltet oder eine IPS-Policy in der betroffenen Firewall-Regel ausgewählt sein. Application Classification ist laut Dokumentation standardmässig eingeschaltet; der tatsächliche Zustand wird trotzdem geprüft. Sie ist hier nicht als zusätzlicher Schalter in jeder Firewall-Regel zu verstehen. Die Anforderung betrifft insbesondere HTTPS und DNS-Anfragen an externe Resolver über HTTP beziehungsweise HTTPS. Fehlt die erforderliche Klassifizierung, kann der Domain-Abgleich im betreffenden Traffic-Pfad ausbleiben.

Beantwortet die Firewall selbst die DNS-Anfragen der Clients, übernimmt das DNS-Modul den Domain-Abgleich. Verwenden die Clients einen externen Resolver, muss auch dieser DNS-Pfad durch die Firewall laufen und mit den erforderlichen IPS-bezogenen Einstellungen sichtbar sein. Bei einem ausbleibenden Domain-Treffer wird deshalb immer der tatsächlich verwendete Resolverpfad geprüft, nicht nur die Client-Regel zum Webziel.

Vollständige URLs über HTTPS

Eine URL enthält neben der Domain auch einen Pfad, zum Beispiel https://example.invalid/download/payload.exe. Bei verschlüsseltem HTTPS-Traffic sieht die Firewall ohne Entschlüsselung über SNI normalerweise nur die Domain, nicht den Pfad /download/payload.exe.

Soll der vollständige URL-Indikator geprüft werden, braucht es Web Proxy mit aktivierter HTTPS-Entschlüsselung oder eine passende SSL/TLS-Inspection-Regel mit Decrypt. TLS Inspection sollte nicht nur für X-Ops unkontrolliert global aktiviert werden: Zertifikatsverteilung, Datenschutz, Ausnahmen, Applikationskompatibilität und Performance gehören in einen eigenen Rollout.

Beim Web Proxy werden in der passenden Firewall-Regel unter Web filtering die Optionen Use web proxy instead of DPI engine und Decrypt HTTPS during web proxy filtering gewählt. Beim DPI-Pfad bleibt Use web proxy instead of DPI engine ausgeschaltet; die passende Entschlüsselungsregel wird unter Rules and policies > SSL/TLS inspection rules mit Action Decrypt eingerichtet. Beide Pfade brauchen für vollständige HTTPS-URL-Prüfung auch die oben genannten Klassifizierungsvoraussetzungen. Man ändert nur den freigegebenen Traffic-Pfad und prüft danach Zertifikatsvertrauen, den normalen Geschäftsprozess und die tatsächlich treffende Regel im Log Viewer.

Prüfumfang bewusst wählen

Unter Advanced security settings legt man fest, wie breit X-Ops den Traffic untersucht:

• Inspect untrusted content beschränkt die Prüfung auf Traffic mit nicht vertrauenswürdigen Quellen oder Zielen. Diese Einstellung benötigt weniger Ressourcen und ist ein sinnvoller Startpunkt, wenn Last und Nebenwirkungen noch nicht bekannt sind.
• Inspect all content prüft vertrauenswürdigen und nicht vertrauenswürdigen Traffic. Das bietet mehr Abdeckung, kann aber besonders in stark ausgelasteten Umgebungen die Performance beeinflussen.

Für besonders schützenswerte Client-, Server- oder Administrationsnetze kann Inspect all content sinnvoll sein, wenn die Appliance genügend Reserve besitzt. Die Änderung sollte in einem Wartungsfenster erfolgen. Anschliessend werden CPU-Auslastung, Latenz, Durchsatz und Helpdesk-Rückmeldungen mit dem vorherigen Zustand verglichen.

Die Dokumentation beschreibt den Performance-Unterschied zwischen den beiden Prüfumfängen meist als gering, bei hohem Traffic aber als möglicherweise erheblich. Vor dem Wechsel wird der bisherige Wert festgehalten. Zeigt der Vergleich eine relevante Verschlechterung, setzt man unter Advanced security settings den vorherigen Prüfumfang zurück, speichert mit Apply und prüft Geschäftsprozess, Last und Logging erneut. Die Blockaktion muss dafür nicht pauschal abgeschaltet werden.

Aktion und Prüfumfang sollten bei einer Einführung möglichst nicht gleichzeitig mehrfach verändert werden. Ändert man zuerst die Sichtbarkeit und danach die Blockaktion, lässt sich bei einem Problem besser nachvollziehen, welche Einstellung die Ursache war.

Wirkung und Logging kontrollieren

Nach dem Speichern reicht es nicht, nur den aktiven Schalter zu prüfen. Eine belastbare Betriebskontrolle umfasst drei Ebenen:

1. Konfiguration: X-Ops ist eingeschaltet, die gewünschte Action und der Prüfumfang sind gespeichert.
2. Sichtbarkeit: Firewall-Regel, Application Classification beziehungsweise IPS und bei vollständigen HTTPS-URLs die TLS-Entschlüsselung passen zum Indikatortyp.
3. Nachweis: Unter Log viewer > Active threat response beziehungsweise im konfigurierten Central- oder Syslog-Ziel sind Treffer auffindbar.

Für eine lokale Zusammenfassung öffnet man Reports > Network & threats > Active threat response. Das gleichnamige Widget im Control Center zeigt einen Überblick über betroffene Hosts und Threat-Ereignisse. MDR und X-Ops zeigen Status und blockierte Threats, NDR Essentials Status und überwachte Threats; Third-Party Threat Feeds zeigen zusätzlich konfigurierte Feeds und deren Synchronisierungsstatus. Configure führt zur Konfiguration, Reports zu den Berichten und More details erweitert die Widget-Ansicht. Auf Geräten ohne lokales Reporting fehlt die Schaltfläche Reports; dort werden die konfigurierten Central- oder Syslog-Ziele verwendet. Eine NDR-Zählung überwachter Threats ist kein Nachweis einer Blockierung. Die konkrete Aktion und die Verbindungsdetails prüft man im Report oder Log Viewer. Das Widget zeigt für Third-Party Threat Feeds auch die Anzahl der durch diese Feeds blockierten Threats.

Der technische Syslog-Logtyp heisst weiterhin ATP, obwohl die Oberfläche heute X-Ops und Active Threat Response verwendet. Je nach Verarbeitungspfad kann log_component auf Firewall, DNS, IPS oder Web zeigen. Für eine Untersuchung sind Zeitstempel, Aktion, Source, Destination, Ports, Domain oder URL, Threat-Name, Feedname und Event-ID besonders hilfreich.

In der Advanced Shell ist ips.log das wichtigste Engine-Log für Active Threat Response. garner.log hilft bei der Verarbeitung und Weiterleitung von Events, insbesondere wenn Central Reporting unvollständig wirkt. Die Einordnung dieser Dateien und der sichere SSH-Zugriff stehen in der Übersicht der Sophos-Firewall-Dienste und Logdateien.

Es gibt keinen allgemein dokumentierten harmlosen X-Ops-Testindikator. Deshalb sollte man nicht absichtlich eine echte Malware-Domain oder bekannte schädliche IP aufrufen. Wenn ein reproduzierbarer Funktionstest nötig ist, ist ein eigener Third-Party-Pilot-Feed mit einem kontrollierten Testziel die sicherere Methode. Für X-Ops selbst werden Konfiguration und Sichtbarkeit geprüft; die tatsächliche Blockwirkung bestätigt der nächste reale, sorgfältig untersuchte Treffer.

Wenn ein IoC nicht blockiert oder kein X-Ops-Log erscheint

Die Prüfung beginnt beim konkreten Indikatortyp und dem tatsächlichen Traffic-Pfad. So vermeidet man breite Ausnahmen oder globale TLS-Änderungen auf Verdacht:

1. Unter Protect > Active threat response > Sophos X-Ops threat feeds kontrollieren, ob X-Ops aktiv ist und Action wirklich auf Log and drop steht. Log only erzeugt lediglich einen Eintrag.
2. Im Log viewer > Active threat response für denselben IoC das Modul, die tatsächliche Aktion und die Verbindungsdetails prüfen. Nur eine nachgewiesene blockierende Aktion eines früheren Moduls, etwa MDR mit Log and drop, beendet die weitere Prüfung vor X-Ops. NDR Essentials erkennt und protokolliert mit Log threats, blockiert aber nicht. Ein überwachtes NDR-Ereignis allein beendet die X-Ops-Prüfung nicht und erklärt keinen fehlenden X-Ops-Logeintrag.
3. Für Ziel-IP-Adressen die tatsächlich treffende LAN-to-WAN-Firewall-Regel kontrollieren. Für Domains zusätzlich Application Classification, IPS-Policy und Resolverpfad prüfen.
4. Für vollständige HTTPS-URLs im Log viewer > SSL/TLS inspection nach dem Servernamen suchen. Zeigt die passende SSL/TLS rule Don't decrypt, kann X-Ops den URL-Pfad nicht sehen. Erst nach der Regelzuordnung eine möglichst enge Decrypt-Regel planen.
5. Im Log viewer > Web filter nach Domain oder URL suchen; zusätzlich die Spalte Category und die Detailansicht prüfen. Dort werden die Firewall-Regel-ID und die ausgewählte Web-Policy zugeordnet. Zeigt die verantwortliche Web policy Allow, Regel- und Policy-Reihenfolge prüfen. Für eine bestätigte schädliche Domain oder URL kann eine eng begrenzte URL-Gruppe mit einer Web-Policy-Aktion Block in einer passenden LAN-to-WAN-Regel oberhalb der bisher erlaubenden Regel verwendet werden. Beim Web-Proxy-Pfad zusätzlich Web > Exceptions prüfen: URL pattern matches, Web categories, Destination IP addresses und Source IP addresses können den Indikator oder den anfragenden Endpoint erfassen. Beim DPI-Pfad die SSL/TLS Exclusion Lists kontrollieren. Eine Ausnahme wird nicht pauschal entfernt; zuerst werden Zweck, betroffener Geschäftsprozess und Freigabe geklärt.
6. Unter Protect > Active threat response > Add threat exclusions nach dem IoC sowie nach dem anfragenden Host oder Netz suchen. Diese Ausnahmen gelten modulübergreifend.

Nach jeder Korrektur wird derselbe Geschäftsprozess erneut ausgeführt und in den passenden Logs geprüft. Bleibt die Ursache unklar, werden Zeitstempel, Firewall-Regel-ID, Web- beziehungsweise SSL/TLS-Regel-ID und die Detailansicht des Active-Threat-Response-Ereignisses für den Supportfall gesichert.

X-Ops-Alarm untersuchen

Ein blockierter IoC ist ein starkes Signal, aber noch keine vollständige Incident-Analyse. Die Zieladresse kann beispielsweise durch Malware, einen Phishing-Link, eine kompromittierte Browser-Erweiterung oder einen legitimen, aber falsch eingestuften Dienst kontaktiert worden sein.

Ein sinnvoller Ablauf ist:

1. Zeitstempel, Firewall beziehungsweise HA-Knoten, Aktion und vollständige Logdetails sichern.
2. Source-IP, Ziel-IP, Domain oder URL, Ports, Protokoll, Threat-Name und Feedname erfassen.
3. Im selben Zeitfenster Firewall-, DNS-, IPS- und Web-Logs korrelieren.
4. Den internen Client über DHCP-Lease, Benutzerzuordnung oder Endpoint-Daten identifizieren.
5. Auf dem betroffenen System nach zugehörigem Prozess, Browser-Verlauf, Download und weiteren Security-Events suchen.
6. Bei bestätigter Kompromittierung das System isolieren und nach dem internen Incident-Response-Runbook behandeln.
7. Erst nach der Analyse entscheiden, ob Bereinigung, ein zusätzlicher Block oder eine eng begrenzte Ausnahme nötig ist.

Mit Synchronized Security können bei unterstützten Windows-Endpoints zusätzlich Prozessbenutzer, Endpoint-ID und Ausführungspfad erscheinen. Auf macOS stehen diese Prozessdetails nicht zur Verfügung; dort bleibt die Source-IP für die Zuordnung besonders wichtig.

Bekannter HA-Fehlalarm NC-170292

Auf einem HA-System mit SFOS 21.5.1 MR1 Build 261 kann NC-170292 in Sophos Fusion (ehemals Sophos Central) einen falschen Advanced threat detected-Alarm mit Raw Logs auslösen. Eine E-Mail der Firewall kann gleichzeitig ohne verwertbare Details eintreffen.

Diese Einschränkung gilt nicht pauschal für andere Builds oder Standalone-Firewalls. Ein Alarm wird deshalb zuerst wie oben beschrieben gesichert und untersucht. Passt das System exakt zum betroffenen Build und fehlen belastbare Trefferdetails, nennt Sophos den Neustart des Garner-Dienstes als temporären Workaround. Da die Known-Issues-Liste für diesen Fehler keinen konkreten CLI-Befehl nennt, sollte der Neustart nur nach freigegebenem Support- oder Wartungsablauf erfolgen. Bei wiederkehrenden Meldungen gehören HA-Status, Firmware-Build, Zeitstempel und garner.log in den Sophos-Supportfall.

Ausnahmen nur nach bestätigter Analyse

Unter Protect > Active threat response > Add threat exclusions können Host and network exclusions sowie Threat exclusions für IP-Adressen, Domains oder URLs angelegt werden. Ein Eintrag unter Threat exclusions darf höchstens 128 Zeichen lang sein. Eine solche Ausnahme gilt nicht nur für X-Ops, sondern für alle Active-Threat-Response-Module. Eine schnelle Ausnahme kann daher gleichzeitig den Schutz durch MDR, NDR oder Third-Party Threat Feeds schwächen.

Wenn ein False Positive bestätigt ist, sollte nur der kleinste erforderliche Indikator ausgenommen werden. Zur Ausnahme gehören Grund, Ticket, verantwortliche Person und Review-Datum. Ganze Client-Netze oder breite Domainbereiche vorsorglich auszuschliessen, beseitigt zwar den sichtbaren Alarm, aber auch einen grossen Teil der Schutzwirkung.

Für eine freigegebene Ausnahme öffnet man Protect > Active threat response > Add threat exclusions und verwendet je nach Ausnahmeart eine der folgenden Alternativen:

• Hosts oder Netze: Unter Host and network exclusions auf Add new item klicken und nur die freigegebenen Host- oder Netzwerkobjekte auswählen.
• Bedrohungsindikator: Stattdessen unter Threat exclusions die freigegebene IP-Adresse, Domain oder URL eingeben und mit Add in die Liste aufnehmen. Die Grenze von 128 Zeichen pro Eintrag beachten.

Anschliessend mit Apply speichern. Die Seite erneut öffnen und kontrollieren, ob nur die beabsichtigten Einträge gespeichert sind. Add new item beziehungsweise Add allein ersetzt diesen abschliessenden Speicherschritt nicht.

Nach der Änderung wird derselbe Geschäftsprozess erneut geprüft und im Log Viewer kontrolliert, ob nur der beabsichtigte Treffer ausbleibt. Andere X-Ops-Ereignisse müssen weiterhin protokolliert beziehungsweise blockiert werden.

Für den Rückweg wird nur die zuletzt vorgenommene Änderung zurückgenommen: Der Prüfumfang wird auf den dokumentierten vorherigen Wert gesetzt und mit Apply gespeichert; eine neu angelegte Web-/SSL/TLS-Regel oder Ausnahme wird gezielt zurückgenommen, ohne bestehende Regeln oder andere Ausnahmen zu verändern. Danach werden Geschäftsprozess, tatsächlich treffende Regel und Logs erneut geprüft. Wird eine Ausnahme zurückgenommen, kann der betreffende Treffer wieder blockiert werden. Falls wegen einer Betriebsstörung vorübergehend Log only nötig ist, entfällt währenddessen die X-Ops-Blockwirkung; Verantwortliche und Endzeit werden festgelegt und Log and drop nach der Ursachenklärung wiederhergestellt. Ein deaktiviertes Modul ist kein gleichwertiger Rückweg, da dann auch seine Prüfung entfällt. Ein kontrollierter Test mit einem eigens dafür eingerichteten Pilot-Feed unter Third-Party Threat Feeds belegt nur den Traffic-Pfad dieses Feeds, nicht die Zustellung oder den Abgleich der X-Ops-Datenbank.

XML API: Aktivierung, Aktion und Ausnahmen getrennt behandeln

Wer X-Ops automatisiert, muss im dokumentierten XML-Objekt ATP drei unabhängige Einstellungen auseinanderhalten. Die SFOS-22/23-API-Referenz beschreibt:

• ATP/ThreatProtectionStatus: skalarer Modulschalter mit Enable oder Disable. Er aktiviert beziehungsweise deaktiviert X-Ops; er ist weder die Trefferaktion noch eine einzelne Ausnahme.
• ATP/Policy: skalare Trefferaktion. Die Parametertabelle nennt Log Only und Log and Drop, führt Log Only als Default auf und markiert das Feld als erforderlich, wenn X-Ops aktiviert ist. Das ist eine Angabe der API-Tabelle, kein Nachweis für den gespeicherten Zustand der eigenen Firewall.
• ATP/InspectContent: skalarer Prüfumfang mit all oder untrusted. Ein anderer Prüfumfang ist nicht mit Disable oder dem Wechsel der Trefferaktion gleichzusetzen.
• ATP/HostException/Host: Liste von Zeichenketten für auszunehmende Quellhosts oder Quellnetze. Im Muster steht HostName; für einen Eintrag wird die freigegebene Objektreferenz der eigenen Konfiguration benötigt.
• ATP/ThreatException/Threat: getrennte Liste von Zeichenketten für auszunehmende Zielindikatoren. Die API-Tabelle nennt Ziel-IP-Adressen und Domains. Die oben beschriebene URL-Eingabe in der Oberfläche beweist für sich allein keine XML-Payload-Syntax für URLs.

Die beiden Ausnahmelisten liegen also unter unterschiedlichen Eltern und können mehrere Einträge enthalten. Sie sind keine globalen Abschaltschalter. Die API-Tabelle nennt ihre Wirkung für X-Ops, MDR und Third-Party Threat Feeds; die weitergehende modulübergreifende Warnung und die Freigaberegeln im Abschnitt zu Ausnahmen bleiben deshalb wichtig.

Vor einem schreibenden Request den Policy-Konflikt klären: Das XML-Muster verwendet für Policy den Text alert/drop, während die Parametertabelle Log Only und Log and Drop nennt. Diese Schreibweisen werden nicht stillschweigend ineinander umgewandelt; auch die Schreibweise der UI-Labels ist kein Beweis für einen gültigen API-Wert. Vor der Automatisierung bestätigt man den konkreten Wert und die Request-Struktur anhand der API-Hilfe des installierten Builds oder mit Sophos Support. Bis dahin ist das Muster kein kopierfertiger, verifiziert funktionierender Request.

Die sichere Einrichtung der XML API wird separat behandelt. Vor einer freigegebenen Änderung sichert man Modulstatus, Aktion, Prüfumfang und beide Ausnahmelisten. Danach liest man den tatsächlich gespeicherten Zustand erneut aus beziehungsweise öffnet die Konfigurationsseite und vergleicht diese fünf Bereiche einzeln. Bei einem Fehler wird vor einem Retry zuerst der gespeicherte Zustand geprüft; eine Ausnahme oder ein anderer Prüfumfang darf nicht unbeabsichtigt zur globalen Deaktivierung werden.