Sophos Firewall NDR und Active Threat Response betreiben

Sophos Firewall kann mit NDR Essentials und NDR Active Threat Intelligence zusätzliche Hinweise auf verdächtigen Netzwerkverkehr liefern. Das ist hilfreich, wenn man Angriffe nicht nur blockieren, sondern auch erkennen, untersuchen und in Sophos Fusion (ehemals Sophos Central), XDR, MDR oder einem SIEM weiterverarbeiten möchte.

Wichtig ist die Erwartung: NDR auf der Firewall ist kein magischer Schalter, der jedes Problem automatisch löst. Die Funktion braucht passende Lizenzen, sichtbaren Traffic, aktivierte Logtypen, bewusst ausgewählte Firewall-Regeln und einen Prozess, der Treffer auswertet. Ohne diesen Betriebsteil entstehen nur zusätzliche Logs.

Kurzentscheidung für SFOS 22: NDR Essentials lernt aus ausgewählten Interface-Flows und führt erkannte IP- und Domain-IoCs in einem lokalen Feed. NDR Active Threat Intelligence prüft dagegen nur den Traffic der Firewall-Regeln, in denen Scan with NDR Active threat intelligence aktiviert ist. Bei beiden Funktionen ist Action fest auf Log threats eingestellt; die NDR-Module selbst blockieren den erkannten Traffic daher nicht.

Ergänzung aus der SFOS-23-Dokumentation: Alarme von NDR Essentials und NDR Active Threat Intelligence werden protokolliert, ändern allein aber weder den Security Heartbeat-Status von Endpoints noch isolieren sie diese. Eine erforderliche Eindämmung bleibt eine separat freizugebende Massnahme. Das ist eine dokumentierte Einschränkung, kein hier getesteter Versionswechsel.

Für klassische Indicators of Compromise wie bösartige IP-Adressen, Domains oder URLs passt zuerst Sophos Firewall Threat Feeds einrichten und sicher betreiben. Dieser Artikel konzentriert sich auf NDR Essentials, NDR Active Threat Intelligence und die operative Auswertung.

Offene Grenze beim Threat-Feeds-Verweis: In der Sophos-Dokumentation widersprechen sich ATR-Beschreibung und SVG-Traffic-Matrix zur Eignung von Sophos X-Ops für bestimmte Matchrichtungen, insbesondere zum Zielabgleich und zum lokalen Quellabgleich bei ausgehendem Traffic. Dieser Widerspruch ist nicht geklärt. Übertragbar sind nur die für das jeweilige Modul und den konkreten Traffic-Pfad gesicherten Fälle; Aussagen zu MDR, NDR oder Third-Party Threat Feeds belegen keine entsprechende X-Ops-Wirkung, auch nicht für DNAT/WAF oder systemgerichteten Traffic. Für strittige Fälle braucht es unabhängig vom Feed restriktive Firewall-, DNAT-/WAF- und Zugriffskontrollen sowie eine freigegebene, kontrollierte Prüfung von Matchrichtung, Modul, Log und tatsächlicher Wirkung. Bis zur belastbaren Klärung darf man die umstrittene Feed-Wirkung nicht als Schutzvoraussetzung einplanen.

Die Begriffe sauber trennen

Sophos verwendet mehrere ähnliche Namen. Für Admins ist die Unterscheidung wichtig, weil jede Funktion anders arbeitet.

Die wichtigsten Bausteine:

• NDR Essentials: Die Firewall erfasst Metadaten aus TLS-verschlüsseltem Traffic und DNS-Abfragen, sendet diese zur Analyse an den gewählten Sophos Cloud Service und erkennt IoCs wie IP-Adressen oder Domains. Der Nutzen liegt in netzwerkbasierten Hinweisen ohne separate Sensor-VM und ohne vollständige TLS-Entschlüsselung für jede Erkennung.
• NDR Active Threat Intelligence: Die Firewall nutzt kuratierte Taegis-NDR-Muster, erkennt verdächtigen Traffic, loggt Events und sendet sie an den Sophos Data Lake. Das liefert hochsignalige Detection für XDR, MDR oder Security Operations.
• Sophos NDR: Das ist ein separates NDR-Produkt mit eigener Sensor-VM, typischerweise über SPAN, Mirror oder TAP. Es liefert breitere Sicht auf Ost-West-Traffic, unmanaged Geräte und interne Netzwerkbewegungen.
• Threat Feeds: IoC-Listen wie IPs, Domains oder URLs werden gegen Traffic geprüft. Diese Listen helfen, bekannte schädliche Ziele oder Quellen zu blockieren oder zu überwachen.

NDR Essentials und NDR Active Threat Intelligence erweitern also die Sicht der Firewall. Sophos NDR ist eine eigene Architektur mit separatem Sensor. Third-Party Threat Feeds sind wieder ein anderer Baustein: Diese arbeiten indikatorbasiert und können je nach Aktion direkt blockieren.

Wann der Einsatz sinnvoll ist

NDR und Active Threat Response sind besonders nützlich, wenn eine Firewall nicht nur als Paketfilter betrieben wird, sondern Teil eines Detection-and-Response-Prozesses ist.

Typische Szenarien:

• Internet-Traffic von Clients soll auf verdächtige Ziele oder Muster geprüft werden.
• Server oder DMZ-Systeme sollen zusätzliche Detection-Signale liefern.
• XDR, MDR oder SOC sollen Firewall-Events in Untersuchungen einbeziehen.
• Mehrere Firewalls sollen zentral in Sophos Fusion oder einem SIEM ausgewertet werden.
• Es gibt bereits einen Prozess für Alarme, Tickets, False Positives und Eskalation.

Weniger sinnvoll ist der Einsatz, wenn niemand die Ereignisse prüft, keine Logs weitergeleitet werden oder die relevanten Firewall-Regeln nicht angepasst werden. Dann ist zuerst Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden wichtiger.

Voraussetzungen

Vor der Aktivierung sollten diese Punkte geprüft werden:

• Die Firewall läuft auf einer unterstützten SFOS-Version.
• Für NDR Active Threat Intelligence ist das Xstream Protection Bundle aktiv.
• Für NDR Essentials ist die konkrete Subscription geprüft. Die Übersicht zu den Sophos Firewall Bundles grenzt die verfügbaren Pakete voneinander ab, ersetzt aber keinen Live-Abgleich des Entitlements: Die tatsächlich gebuchte Subscription sollte man in der Firewall beziehungsweise beim Sophos-Partner bestätigen, weil NDR Essentials anders als NDR Active Threat Intelligence zugeordnet sein kann und Entitlements sich ändern können.
• Wenn Central Firewall Reporting oder die optionale XDR/MDR-Analyse für NDR Active Threat Intelligence genutzt wird, muss Send reports and logs to Sophos Central unter Sophos Central Services aktiviert sein. Für die Untersuchung in XDR oder MDR ist zusätzlich die passende XDR-, MDR-Essentials- oder MDR-Complete-Lizenz nötig. Der Central-Export ist keine Voraussetzung für lokale Erkennung und IPS-Logauswertung; Xstream-Lizenz, unterstützte Plattform, globale Aktivierung, Aktivierung pro Regel und IPS-Logging bleiben erforderlich.
• Die relevanten Logtypen sind unter System services > Log settings aktiviert.
• Für NDR Active Threat Intelligence ist IPS-Logging aktiv.
• Für NDR Essentials ist Active-Threat-Response-Logging aktiv.
• Es gibt einen definierten Owner für Prüfung, Tuning, Ausnahmen und Eskalation.

Vor der Aktivierung müssen die Plattformgrenzen geprüft werden. NDR Essentials wird auf allen XGS Appliances der Generationen 1 und 2 sowie auf VMware, KVM, Hyper-V, Azure, AWS, XEN und Software Appliances unterstützt, aber nicht in Active-Active-HA. NDR Active Threat Intelligence wird zusätzlich auf XGS 87, XGS 87w, XGS 88 und XGS 88w nicht unterstützt; die übrigen genannten Plattformen sind freigegeben. In HA-Umgebungen sollte man deshalb zuerst Sophos Firewall HA Cluster Varianten verstehen prüfen.

Diese Anleitung bezieht sich auf SFOS 22.0 MR2. NDR Active Threat Intelligence kam mit 22.0 MR1 hinzu; gleichzeitig erweiterte Sophos NDR Essentials auf XGS Appliances sowie virtuelle, Software- und Cloud-Firewalls. Vor einem Rollout auf einem älteren 22.0-Build sollte man die Vorbereitung für das Sophos Firewall Firmware Update durchlaufen, den installierten Build notieren und den unterstützten Upgradepfad sowie den aktuellen Known-Issue-Stand in Firewall und Partner- oder Support-Portal prüfen.

NDR Essentials konfigurieren

NDR Essentials wird unter Protect > Active threat response > NDR Essentials and Active threat intelligence konfiguriert.

Grundablauf:

1. NDR Essentials aktivieren.
2. Relevante Interfaces hinzufügen.
3. Data center location für die Analyse wählen.
4. Minimum threat score bewusst setzen.
5. Action prüfen. NDR Essentials erkennt und loggt zunächst.
6. System services > Log settings öffnen.
7. Logging für Active threat response aktivieren.
8. Save wählen und nach einigen Minuten Log Viewer, Reports oder Central prüfen.

Als Data center location wählt SFOS standardmässig die Region mit der niedrigsten Latenz. Ein späterer Wechsel kann laufende Analysen verlieren. Die Region sollte daher nicht als Performance-Tuning-Schalter verwendet werden: Datenresidenz, interne Freigabe und Erreichbarkeit zuerst klären, Region und Zeitpunkt dokumentieren und nach einem nötigen Wechsel einen neuen Testlauf durchführen.

Bei den Interfaces sollte man nicht wahllos alles auswählen. SFOS 22 unterstützt physische Interfaces, VLANs direkt auf physischen Interfaces, LAGs und Bridge-Member in LAN-, DMZ- und Custom-Zonen. Nicht unterstützt werden RED- und XFRM-Interfaces, VLANs über LAG oder Bridge, das dedizierte Management-Interface sowie WAN- und Wi-Fi-Zonen. Wird ein überwachtes Interface aus seiner Zone gelöst, entfernt SFOS es aus der NDR-Liste. Die Firewall muss den Traffic nur auf einer Seite des Flows überwachen.

Wenn keine Interfaces ausgewählt werden, erkennt NDR Essentials keine neuen IoCs aus dem Traffic. Die Firewall kann aber weiterhin mit bereits erkannten IoCs arbeiten. Das ist im Betrieb leicht zu übersehen.

Beim Minimum threat score ist High risk (Score 9 and 10) - Recommended ein sinnvoller Startpunkt. Sophos führt IoCs ab Score 6. Das Summary Widget zeigt überwachte Traffic-Flows und eindeutige, nach Score gruppierte IoCs; wie viele IoCs gespeichert werden können, hängt von der Appliance-Grösse ab. Für Folgetraffic erzeugt SFOS je nach eingerichteten Zielen Logs, E-Mail-Benachrichtigungen sowie lokale und Central-Reports.

Jeder IoC besitzt eine TTL, abgelaufene Einträge entfernt ein täglicher Job. Erhält ein IoC später einen tieferen Score, bleibt der gespeicherte Score bestehen und nur die TTL wird aktualisiert. Bei einem höheren Score aktualisiert SFOS auch die Bewertung. Unter Threat indicators lässt sich nach IP-Adresse, Domain oder Teilstring suchen. Diese Dynamik ist wichtig, bevor aus einem einzelnen Wert ein dauerhaftes Blocking abgeleitet wird.

NDR Essentials selbst steht auf Log threats. Muss ein bestätigter IoC gezielt blockiert werden, verbindet man sich per SSH mit der Firewall, wählt im CLI-Menü 5. Device Management und danach 3. Advanced Shell und prüft den aktuellen Feed mit den lesenden Befehlen cd /content/ndr und cat threatfeed.json. Danach wird unter Hosts and services > IP host beziehungsweise FQDN host ein Objekt für genau diese IP-Adresse oder Domain angelegt. Unter Rules and policies > Firewall rules verwendet eine enge, geloggte Drop-Regel dieses Objekt als Destination network und steht oberhalb einer allgemeineren Allow-Regel.

Das ist ein kontrollierter manueller Eingriff, keine dauerhafte Feed-Automation. Quelle, Ticket, Owner, Ablaufdatum und derselbe Testtraffic gehören zur Freigabe. Beim Rückbau zuerst den Treffer und die Regelstatistik sichern, dann die dedizierte Drop-Regel deaktivieren und den vormals geblockten Testtraffic erneut prüfen. Das Hostobjekt wird erst gelöscht, wenn keine andere Regel es mehr referenziert.

NDR Essentials mit dem Sophos-Test abnehmen

Sophos stellt einen ungefährlichen Test bereit, der eine Kommunikation mit verdächtigen Domain- und Zertifikatsmerkmalen simuliert. Er wird auf einem freigegebenen Windows-Testgerät hinter der Firewall ausgeführt, dessen Traffic tatsächlich über eines der überwachten Interfaces läuft. Die Datei stammt ausschliesslich von Sophos Test; trotz der harmlosen Simulation gehört der Ablauf in ein angekündigtes Testfenster, weil er absichtlich einen Security Event erzeugt.

1. Auf Sophos Test Network Security > Network Detection and Response öffnen und die Testdatei herunterladen.
2. Das Archiv auf dem Windows-Testgerät entpacken und eine Eingabeaufforderung als Administrator starten.
3. Im entpackten Verzeichnis NdrEicarClient.exe -- all ausführen.
4. Einige Minuten warten und denselben Befehl ein zweites Mal ausführen.
5. Unter Threat indicators nach dem neuen IoC und unter Log viewer > Active threat response nach dem passenden NDR-Ereignis suchen.

Der erste Lauf liefert die Verbindung zur Cloudanalyse. Nachdem NDR das Ziel als IoC bewertet und der Firewall-Feed aktualisiert wurde, bestätigt der zweite Lauf die lokale Erkennung und Protokollierung. Bleibt der Treffer aus, zuerst das überwachte Interface, den echten Egress-Pfad, die Cloud-Erreichbarkeit, das Active-Threat-Response-Logging und die Wartezeit prüfen. Ein erfolgreicher Schalter allein ersetzt diesen Ende-zu-Ende-Test nicht.

NDR Active Threat Intelligence konfigurieren

NDR Active Threat Intelligence nutzt kuratierte Taegis-NDR-Erkennungsmuster. Die Firewall erkennt und loggt passende Events und leitet sie an den Sophos Data Lake weiter. Diese Signale können dann in Sophos Fusion, XDR, MDR oder einem SOC-Kontext untersucht werden.

Typische Muster sind der Missbrauch von Certutil zum Download ausführbarer Dateien, SSH-Scanning und Brute-Force-Versuche eines bereits kompromittierten Hosts, HTTP-GET-Verkehr auf dem üblichen DNS-Port oder Datenabfluss mit legitimen Werkzeugen wie finger. Solche Aktivitäten lassen sich nicht immer sofort als bestätigte Bedrohung blockieren. Sie sind starke Untersuchungssignale und müssen mit Host-, Benutzer- und weiteren Netzwerkinformationen korreliert werden.

Grundablauf:

1. Protect > Active threat response > NDR Essentials and Active threat intelligence öffnen.
2. NDR Active threat intelligence aktivieren.
3. Minimum severity level wählen.
4. Action prüfen. Die Aktion steht auf Log threats.
5. System services > Log settings öffnen.
6. IPS-Logging aktivieren.
7. Speichern.
8. Danach Rules and policies > Firewall rules öffnen und eine relevante Regel bearbeiten.
9. Unter Other security features die Option Scan with NDR Active threat intelligence aktivieren.
10. Änderungen speichern und mit definiertem Traffic validieren.

Der letzte Punkt ist entscheidend. Die globale Aktivierung allein reicht nicht. NDR Active Threat Intelligence muss in jeder Firewall-Regel aktiviert werden, deren Traffic analysiert werden soll.

Minimum severity level ist eine kumulative Schwelle. Critical (1) berücksichtigt nur kritische Muster, Warning (5) dagegen alle Stufen von Critical bis Warning. Das Summary Widget zeigt die Gesamtzahl der letzten sieben Tage und gruppiert sie nach Schweregrad. Die Schwelle muss zur verfügbaren Analysekapazität passen; eine breite Erfassung ohne Triage-Prozess erzeugt nur zusätzliche unbehandelte Signale.

Welche Regeln man zuerst auswählt

Ein guter Rollout beginnt nicht auf allen Regeln gleichzeitig. Besser ist ein kontrollierter Pilot mit gut verständlichem Traffic.

Sinnvolle Startpunkte:

• Client-Netze mit Internetzugriff.
• Server-Netze mit ausgehendem Internetzugriff.
• DMZ-Regeln mit veröffentlichten Diensten.
• Regeln für besonders kritische interne Segmente.
• Regeln mit bereits aktiviertem IPS-, Web- oder TLS-Inspection-Konzept.

Regeln ohne klares Logging, ohne Owner oder mit sehr breitem unklassifiziertem Traffic sind kein guter Start. Dort sollte zuerst die Regelbasis bereinigt werden. Ein anpassbares Pilotbeispiel ist eine geloggte LAN-zu-WAN-Regel für ein verwaltetes Testnetz wie 192.0.2.0/24: Dieses Dokumentationsnetz muss durch das reale Testnetz ersetzt werden. Entscheidend ist, dass die Clients nachweislich genau diese Regel treffen und der Owner die zusätzlichen IPS-Ereignisse auswertet. Für Regelanalyse und Matching passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Sichtbarkeit, TLS und DNS

NDR-Signale sind nur so gut wie der Traffic, den die Firewall tatsächlich sieht. Bei NDR Essentials ist wichtig: Die Funktion kann TLS-Metadaten und DNS-Abfragen auswerten und damit auch ohne vollständige TLS Inspection Hinweise auf verdächtige verschlüsselte Kommunikation liefern. Das ersetzt aber keine sauber geplante Web- oder TLS-Inspection, wenn Inhalte, Downloads, Web-Kategorien oder weitere Schutzmodule geprüft werden sollen.

Für NDR Active Threat Intelligence und andere Security Features bleibt die Regel- und Inspection-Planung entscheidend. Wenn Traffic nicht über die erwartete Firewall-Regel läuft, Logging fehlt oder der Browser über andere Pfade ausweicht, entstehen Lücken in der Auswertung.

Das bedeutet nicht, dass man TLS Inspection überall sofort aktivieren sollte. TLS Inspection ist ein eigenes Betriebsprojekt mit Zertifikaten, Ausnahmen, Datenschutz, Performance und Supportaufwand. Für einen geplanten Rollout passt Sophos Firewall TLS Inspection richtig einführen.

Auch QUIC und HTTP/3 können Web- und Inspection-Konzepte beeinflussen. Wenn Browser Traffic an klassischen HTTPS-Inspection-Pfaden vorbeiläuft, sollte Sophos Firewall QUIC und HTTP/3 richtig blockieren mitgeprüft werden.

Logs und Auswertung

Ohne Logauswertung ist NDR kaum nützlich. Je nach Funktion sind unterschiedliche Logbereiche relevant.

Relevante Prüfstellen:

• NDR Essentials: Active threat response Logs, Threat indicators, Central Reporting oder SIEM.
• NDR Active Threat Intelligence: IPS-Logs, Log Viewer Filter Category is NDR Active threat intelligence und Central Firewall Reporting.
• XDR/MDR-Auswertung: Sophos Fusion Threat Analysis Center, Detections oder Cases.
• Langfristige Korrelation: Syslog, SIEM, SOC- oder MDR-Plattform.

Für lokale Reports lautet der Pfad Reports > Network & Threat > Intrusion attacks. In Sophos Fusion stehen die Ereignisse unter My Products > Firewall Management > Report Generator; dort unter Report templates den Report IPS wählen. Beide Ansichten ergänzen den Log-Viewer-Filter, ersetzen aber nicht die Prüfung des tatsächlich getroffenen Traffic-Pfads und der Firewall-Regel.

Für Sophos Fusion muss die Firewall Logs und Reports an Central senden. Der Ablauf steht in Sophos Firewall Central Reporting aktivieren und betreiben. Für ein eigenes SIEM muss der passende Logtyp per Syslog weitergeleitet und im Zielsystem geparst werden. Nur das Aktivieren der Funktion beweist also noch nicht, dass Detections später auffindbar sind.

Prüfpunkte nach der Aktivierung:

• Erscheinen lokale Logeinträge im Log Viewer?
• Werden Active-Threat-Response- oder IPS-Logs an Central gesendet?
• Kommen die Logs im SIEM an?
• Werden Felder wie Source, Destination, Firewall, Rule ID und Kategorie korrekt erkannt?
• Gibt es ein Dashboard oder eine Suche für NDR-/ATR-Treffer?
• Ist klar, wer Treffer bewertet?

Für die Abnahme von NDR Active Threat Intelligence genügt kein leerer Report als Erfolgsbeweis: Zuerst müssen die globale Einstellung, IPS-Logging, Central-Übertragung bei genutzter Central-/XDR-/MDR-Auswertung und der Counter der tatsächlich getroffenen Pilotregel stimmen. Ein Detection-Treffer ist nur dann ein positives End-to-End-Kriterium, wenn dafür ein von Sophos dokumentierter Test oder ein ohnehin vorhandenes, sicher eingeordnetes Ereignis genutzt wird. Ungeprüfte Exploit- oder Malware-Simulationen gehören nicht in ein Produktionsnetz.

Was bei einem Treffer passieren sollte

Ein Treffer ist zuerst ein Untersuchungssignal. Nicht jeder Treffer ist automatisch ein bestätigter Angriff, aber jeder relevante Treffer braucht einen Ablauf.

Die SFOS-23-Dokumentation stellt für beide NDR-Funktionen klar: Der Alarm allein ändert keinen Endpoint-Security-Heartbeat und löst keine Endpoint-Isolation aus. Eine nach der Untersuchung nötige Isolation oder manuelle Blockierung muss separat freigegeben, ausgeführt und auf ihre Wirkung geprüft werden.

Minimaler Ablauf:

1. Source IP, Destination IP, Benutzer, Regel und Uhrzeit erfassen.
2. Im Log Viewer prüfen, welche Regel und welches Modul beteiligt waren.
3. In Central, XDR, MDR oder SIEM nach weiteren Ereignissen desselben Hosts suchen.
4. Endpoint-, DNS-, Web- und Authentifizierungslogs korrelieren.
5. Entscheiden, ob Endpoint-Isolation, ein enger Firewall-Block oder weitere Analyse nötig ist. Eine Threat Exclusion kommt erst nach bestätigtem False Positive und dokumentierter Wirkungsanalyse infrage.
6. Ergebnis dokumentieren.

Bei wiederholten False Positives sollte nicht sofort eine breite Ausnahme gesetzt werden. Besser ist eine enge Ausnahme mit Grund, Ticket und Review-Datum. Ausnahmen in Active Threat Response können Schutzwirkung entfernen und gehören deshalb in einen kontrollierten Prozess.

Eine Threat Exclusion nimmt Source oder Destination aus dem Scan sämtlicher Active-Threat-Response-Module, also auch aus NDR Active Threat Intelligence. Sie wirkt nicht nur auf eine einzelne Signatur und kann dadurch auch andere Threat Feeds abschwächen. Bei einem Signaturtreffer wird deshalb zuerst der Kontext untersucht. Nur wenn der False Positive bestätigt und die modulübergreifende Wirkung akzeptiert ist, kommt eine möglichst eng begrenzte Host-, Netz-, IP-, Domain- oder URL-Ausnahme infrage; andernfalls sollte Sophos Support die Logdetails und Pattern-Informationen prüfen.

Sicher zurückbauen

Ein Rollback soll die neu geschaffene Analyse gezielt entfernen, nicht nebenbei andere Schutzmodule abschalten:

1. Vorher Zeitraum, Pilotregeln, Interface-Auswahl, Schwellenwerte und letzte relevante Treffer dokumentieren.
2. Bei NDR Active Threat Intelligence zuerst Scan with NDR Active threat intelligence nur aus den Pilotregeln entfernen. Danach kann der globale Schalter deaktiviert werden.
3. Bei NDR Essentials zuerst die überwachten Interfaces entfernen oder den Schalter deaktivieren. Wenn keine Interfaces ausgewählt sind, kann die Firewall bereits erkannte IoCs weiterhin anwenden; deshalb anschliessend Threat indicators und Log viewer > Active threat response kontrollieren.
4. Manuelle IoC-Drop-Regeln separat deaktivieren und testen. Sie verschwinden nicht durch das Abschalten von NDR Essentials.
5. Im Pilot angelegte Threat Exclusions separat prüfen und nur entfernen, wenn sie nicht von einem anderen freigegebenen Anwendungsfall benötigt werden.
6. IPS-Logging, Central Reporting oder Syslog nur zurücknehmen, wenn diese Einstellungen nicht auch für andere Schutz- und Betriebsfunktionen benötigt werden.

Der Rückbau ist erfolgreich, wenn die Pilotregel weiterhin den erwarteten Traffic verarbeitet, NDR Active Threat Intelligence dort nicht mehr aktiviert ist und keine manuelle Blockregel oder Pilot-Ausnahme unbeabsichtigt aktiv geblieben ist. Bei NDR Essentials können bereits erkannte IoCs bis zu ihrem Ablauf weiterhin Logs erzeugen; solche Einträge sind deshalb nicht automatisch ein fehlgeschlagener Rückbau.

Typische Fehler

• NDR Active Threat Intelligence wird global aktiviert, aber nicht in den Firewall-Regeln eingeschaltet.
• NDR Essentials wird aktiviert, aber es werden keine passenden Interfaces ausgewählt.
• IPS- oder Active-Threat-Response-Logging ist nicht aktiv.
• Central Reporting oder Syslog ist nicht eingerichtet, obwohl zentrale Auswertung erwartet wird.
• Detections werden erzeugt, aber niemand prüft sie.
• Severity oder Threat Score wird zu empfindlich gesetzt und erzeugt unnötiges Rauschen.
• Ausnahmen werden zu breit gesetzt.
• Active-Active HA oder kleine XGS-Appliance-Modelle werden eingeplant, obwohl die Funktion dort nicht unterstützt ist.
• TLS Inspection wird als Nebenhaken behandelt, statt sauber geplant zu werden.

Auf frühen SFOS-22.0-Ständen können zudem zwei bereits korrigierte Anzeigen irritieren: NC-152904 zeigte nicht unterstützte Interfaces in der NDR-Auswahl, und NC-165825 meldete für virtuelle Firewalls im Firewall Health Check fälschlich Doesn’t comply. Beide Probleme wurden in Build 411 behoben. Wenn das Symptom auftritt, die ID als Suchschlüssel im aktuellen Partner- oder Support-Portal verwenden, den installierten Build lokal vergleichen und dem unterstützten Updatepfad folgen, statt die Plattformgrenzen zu umgehen.

Checkliste

• SFOS-Version und Lizenz geprüft.
• Unterstützte Appliance oder Plattform bestätigt.
• HA-Modus geprüft.
• Sophos Fusion Registrierung geprüft, wenn Central Reporting, XDR oder MDR genutzt wird.
• Relevante Logtypen unter System services > Log settings aktiviert.
• NDR Essentials Interfaces bewusst ausgewählt.
• Data center location und Minimum threat score dokumentiert.
• NDR Active Threat Intelligence aktiviert.
• Relevante Firewall-Regeln mit Scan with NDR Active threat intelligence versehen.
• Log Viewer, Central Reporting oder SIEM auf Treffer geprüft.
• Owner, Alarmierung, False-Positive-Prozess und Review-Intervall dokumentiert.

Häufige Fragen