Sophos Firewall Health Check richtig nutzen

Der Sophos Firewall Health Check ist eine integrierte Prüfung der Firewall-Konfiguration. Er zeigt im Control Center, ob wichtige Einstellungen den empfohlenen Sicherheits- und Best-Practice-Vorgaben entsprechen. Für Administratoren ist das besonders nützlich, weil riskante Konfigurationen sichtbar werden, bevor daraus ein Sicherheits- oder Betriebsproblem wird.

Für den übergeordneten Hardening-Kontext passt der Hub Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration.

Der Health Check wurde mit Sophos Firewall v22 eingeführt. Die Funktion bewertet Konfigurationen unter anderem gegen Best Practices und Standards wie CIS-Benchmarks. Mit SFOS 22.0 MR1 wurde auch der zugrunde liegende CIS-Kontext aktualisiert.

Videoanleitung

Wie dieser Leitfaden zu verwenden ist

Der Health Check liefert eine Liste, aber noch keine Entscheidung. Dieser Leitfaden ergänzt deshalb jeden Punkt mit einer Avanet-Einordnung:

• Hohe Priorität: Das Finding betrifft eine grundlegende Schutz- oder Betriebsfunktion. Abweichungen sollten zeitnah behoben oder sehr gut begründet werden.
• Situationsabhängig: Die Empfehlung ist sinnvoll, aber nicht für jede Regel, jeden Traffic-Pfad oder jede Architektur gleichermassen.
• Anders abgedeckt: Das Sicherheitsziel ist sinnvoll, wird aber bereits durch eine gleichwertige Kontrolle eines anderen Herstellers oder einen anderen Betriebsprozess erfüllt. Hier kann ein dokumentierter Override korrekt sein.
• Optional: Das Finding bewertet vor allem eine Compliance-Funktion oder einen zusätzlichen Sophos-Dienst. Ein roter Status bedeutet hier nicht automatisch, dass die Firewall unsicher konfiguriert ist.

Die Einordnung ersetzt keine Risikoanalyse. Sie verhindert aber, dass eine niedrige Sophos-Schwere einen wichtigen Backup-Punkt verharmlost oder eine hohe Schwere aus einer optionalen Produktintegration vorschnell ein Kaufprojekt macht.

Wofür der Health Check gedacht ist

Der Health Check ist kein klassischer Systemstatus und kein Hardware-Sensor. Er prüft nicht, ob ein Netzteil defekt ist oder ob eine SSD bald ausfällt. Dafür passen andere Betriebschecks, zum Beispiel SSD-Gesundheitszustand prüfen oder HA- und Hardware-Monitoring.

Für den wiederkehrenden aktuellen System-, Service-, Security- und Adminstatus passt die tägliche Sophos Firewall Admin-Checkliste. Sie ergänzt den Konfigurations-Health-Check um Control Center, System graphs, Reports und Ereignisse.

Der Health Check beantwortet eher diese Fragen:

• Sind administrative Zugänge zu breit geöffnet?
• Ist MFA für kritische Logins aktiviert?
• Sind Firewall-Regeln zu offen gebaut?
• Sind Backups, Hotfixes, Logging oder Central-Funktionen sauber vorbereitet?
• Weicht die Konfiguration von empfohlenen Sicherheitsstandards ab?
• Gibt es Findings, die vor einem Audit oder Go-live geklärt werden sollten?

Er ist damit ein gutes Werkzeug für Härtung, Review und Change-Kontrolle. Er ersetzt aber keine saubere Architektur, keine Regelwerksdokumentation und keine manuelle Bewertung.

⚠️ Ein grüner Health Check bedeutet nicht automatisch, dass die Firewall sicher geplant ist. Er zeigt, ob bestimmte prüfbare Einstellungen passen. Netzwerkdesign, Geschäftslogik, Ausnahmen, Benutzergruppen und Betriebsprozesse müssen weiterhin fachlich bewertet werden.

Score und Status richtig bewerten

Der Health Check ist hilfreich, aber kein vendor-neutrales Security Audit. Er prüft neben allgemeinen Sicherheitsbasics auch, ob zusätzliche Sophos-Funktionen wie Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds oder Synchronized Security verwendet werden. Aus Avanet-Sicht enthält diese Auswahl einen klaren Cross-Selling-Anteil: Ein nicht konformes Finding kann bedeuten, dass ein Sophos-Dienst nicht eingesetzt wird, obwohl das zugrunde liegende Sicherheitsziel bereits mit Microsoft Defender, einem anderen EDR/NDR, einem SIEM oder einem DNS-Security-Dienst abgedeckt ist.

Das macht die Empfehlung nicht automatisch schlecht. Es bedeutet aber, dass Noncompliant zwei sehr unterschiedliche Dinge ausdrücken kann: eine echte Lücke wie öffentlich erreichbares WebAdmin ohne MFA oder lediglich die Entscheidung, einen optionalen Sophos-Dienst nicht einzusetzen. Der Score sollte deshalb nie zum Selbstzweck werden.

Avanet-Empfehlung: Jedes Finding prüfen, aber nicht jedes ungefragt umsetzen. Ein roter Punkt zu WebAdmin, MFA, unverschlüsselter Authentifizierung, Backups oder offenen Regeln verdient hohe Aufmerksamkeit. Ein roter Punkt zu einem nicht lizenzierten Sophos-Dienst ist zunächst eine Architektur- und Produktentscheidung, keine automatisch nachgewiesene Sicherheitslücke. Erst das Sicherheitsziel, vorhandene Alternativen und der betriebliche Prozess entscheiden, ob aktivieren, anders abdecken oder begründet übersteuern richtig ist.

Darum sollte man nicht jede Empfehlung nur aktivieren, damit die Anzeige grün wird. Ein Beispiel ist der Login disclaimer: In Audit- oder Compliance-Umgebungen kann ein Login-Hinweis gefordert sein. In vielen normalen Betriebsumgebungen erzeugt er aber vor allem einen zusätzlichen Klick bei jedem Login und bringt praktisch keinen technischen Sicherheitsgewinn. Wenn die Funktion benötigt wird, erklärt Sophos Firewall Login-Disclaimer und Messages konfigurieren Textpflege, Vorschau, Abnahme und Rollback. Wenn dadurch nur der Health-Check-Score steigt, ist der Mehrwert überschaubar.

Bei DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control oder Sophos Central Reporting sollte man deshalb vier Fragen beantworten: Welches konkrete Risiko wird reduziert? Besteht bereits eine gleichwertige Kontrolle? Welche Lizenz und Datenübertragung ist nötig? Wer bearbeitet Alerts, Ausnahmen und False Positives? Fehlt darauf eine gute Antwort, ist ein dokumentierter Override oft ehrlicher als eine ungenutzte Funktion, die nur den Score verbessert.

Dabei sollte man NDR Essentials und MDR nicht gleichsetzen. NDR Essentials analysiert ausgewählten Firewall-Traffic und liefert Erkennungen. Sophos MDR steht für Managed Detection and Response und ist ein zusätzlicher, kostenpflichtiger Service mit Analysten und Incident-Prozessen. MDR threat feeds sind nur sinnvoll, wenn dieser Service tatsächlich lizenziert und organisatorisch eingebunden ist. Ein NDR-Finding bedeutet deshalb nicht automatisch, dass man MDR kaufen muss.

Als Faustregel:

• Internetexponierte Managementzugriffe, MFA, automatische Hotfixes, Backups, Passwortregeln und IPS sind in der Regel echte Sicherheits- oder Betriebsbasics. Diese Punkte sollten sehr ernst genommen werden.
• Logging, Reporting, Benachrichtigungen und NTP sind wichtig für Betrieb und Nachvollziehbarkeit. Der konkrete Weg hängt aber vom Betriebsmodell ab.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central und Synchronized Security sind mögliche Lösungen, aber keine allgemeine Pflicht. Eine vorhandene, wirksame Alternative ist wichtiger als das Sophos-Logo auf der Kontrolle.
• Login disclaimer ist meist eher Compliance-/Hinweisfunktion als technische Schutzmassnahme. Aktivieren sollte man ihn nur, wenn es wirklich gefordert oder gewünscht ist.

Schnellentscheidung: Was sollte man wirklich umsetzen?

Wer den Health Check zum ersten Mal öffnet, kann die Findings zunächst in vier Arbeitskörbe sortieren:

• Sofort prüfen und in der Regel beheben: 8, 9, 11, 13 bis 20, 22, 25, 28 und 31. Dazu gehören Hotfix-Status, Login-Schutz, Admin-Passwörter, MFA, verschlüsselte Authentifizierung, SSH, WAN-Exposition, Pattern-Updates, IPS, breite Regeln und korrekte Zeit.
• Sehr wichtig, obwohl Sophos niedrig oder mittel bewertet: 16 und 21. Backups brauchen einen getesteten Restore. Für Alarme muss ein funktionierender Weg über E-Mail, Monitoring, Central oder SIEM existieren.
• Pro Traffic-Pfad und Architektur entscheiden: 3, 5, 10 sowie 23 bis 27. X-Ops, Heartbeat, Benutzer-Passwortregeln, Web Policy, Zero-Day Protection, Application Control und TLS Inspection sind nicht auf jeder Regel gleich sinnvoll.
• Nur bei passendem Sophos-Ökosystem oder bewusstem Cloud-Service aktivieren: 1, 2, 4, 6, 12, 29 und 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection und Central-Funktionen sind kein allgemeiner Mindeststandard. Punkt 7, der Login disclaimer, ist primär eine Compliance-Entscheidung.

Diese Gruppierung ist bewusst deutlicher als der Sophos-Schweregrad. Sie bewertet nicht, was Sophos verkaufen oder technisch integrieren kann, sondern was in einer konkreten Umgebung zuerst Risiko reduziert.

Health Check öffnen

Der Health-Check-Status erscheint im Control center. Die Detailansicht findet man zusätzlich über das Hauptmenü:

Monitor & analyze > Firewall health check

Dort sieht man die Anzahl der geprüften Konfigurationen, die konformen Punkte und die nicht konformen Punkte. Sophos zeigt nicht konforme Einträge nach Schweregrad an. Die Daten werden aktualisiert, wenn sich eine überwachte Konfiguration ändert. Dadurch eignet sich der Health Check auch für eine direkte Nachkontrolle nach Änderungen.

Für den Review sollte man nicht nur den Gesamtstatus notieren. Wichtiger sind die konkreten Findings, der Risikokontext und die geplante Massnahme. Ein einzelnes kritisches Finding zur WAN-Erreichbarkeit des WebAdmin ist im Betrieb wichtiger als mehrere niedrige Findings ohne Internetexposition.

Status, Schweregrad und Override verstehen

Die Detailansicht zeigt pro Prüfung, ob die Konfiguration compliant, nicht compliant oder manuell übersteuert ist. Für den Betrieb sind diese drei Zustände wichtiger als der reine Prozentwert.

• Compliant: Die geprüfte Konfiguration erfüllt die jeweilige Policy. Nach grösseren Änderungen sollte man sie trotzdem technisch validieren.
• Noncompliant: Die geprüfte Konfiguration erfüllt die Policy nicht. Risiko, Exposition und Umsetzbarkeit müssen bewertet werden.
• Manual policy status override: Die Konfiguration erfüllt die Policy nicht, wurde aber manuell als compliant markiert. Dieser Status sollte nur mit Begründung, Owner und Wiedervorlage verwendet werden.

Unter Action bietet die Ansicht je nach Finding direkte Arbeitsschritte. Fix now führt zur passenden Konfigurationsseite, Override status setzt einen nicht konformen Punkt manuell auf compliant, und Undo override nimmt eine solche Übersteuerung wieder zurück. Das ist praktisch, ersetzt aber keine Bewertung: Der Health Check weiss nicht automatisch, ob eine Kontrolle an anderer Stelle wirklich gleichwertig umgesetzt ist.

Der Schweregrad hilft beim Sortieren, ersetzt aber keine Fachbewertung. Er ist eine statische Sophos-Wertung und kennt weder Exposition noch kompensierende Kontrollen. High-Findings mit Internetexposition, Adminzugang, MFA, Hotfixes oder Regelwerk sollten zuerst geprüft werden. Ein Low-Finding zu fehlenden Backups kann betrieblich trotzdem dringender sein als ein Medium-Finding zu einem nicht genutzten Sophos-Dienst.

Bei einem unplausiblen Finding sollte man zusätzlich den Firmwarestand und die bekannten Fehler prüfen. SFOS 22.0 MR1 korrigierte unter anderem falsche Doesn't comply-Meldungen für Firewall-Regeln und für NDR Essentials auf virtuellen Firewalls. Ein offensichtlich falscher Status ist deshalb weder ein Grund für eine riskante Konfigurationsänderung noch für einen vorschnellen Override.

Die Such- und Sortierfunktionen der Health-Check-Tabelle helfen, Findings nach Policy, Modul, Standard oder Schweregrad zu gruppieren. Für grössere Firewalls ist das praktischer als nur die Dashboard-Kachel zu betrachten.

Die Health-Check-Prüfungen einzeln bewertet

Die folgende Liste orientiert sich an den 31 Prüfungen der englischen Health-Check-Ansicht, die für diesen Review verwendet wurde. Sophos kann Anzahl, Bezeichnung, Standard oder Schweregrad mit einem Firmware-Update ändern. Wenn die eigene Firewall zusätzliche oder anders benannte Findings zeigt, ist deshalb die lokale Anzeige massgebend. Der Status ist bewusst nicht aufgeführt, weil er je Firewall unterschiedlich ist. Wichtiger ist, welche Prüfung gemeint ist und wie man sie fachlich einordnet.

Active Threat Response und Advanced Security

• 1. Synchronized Application Control sollte aktiviert sein. Standard: Recommended, Schweregrad: Medium. Die Funktion identifiziert Anwendungen mithilfe von Sophos Endpoint genauer und setzt Security Heartbeat voraus; beim ersten Einsatz muss sie zusätzlich in Sophos Central eingeschaltet werden. Avanet-Einordnung: optional. Nur aktivieren, wenn kompatible Sophos Endpoints vorhanden sind und die erkannten Anwendungen später klassifiziert und über Application Filter genutzt werden. In Umgebungen mit Microsoft Defender oder einem anderen Endpoint-Produkt ist ein begründeter Override sinnvoller als eine wirkungslose Aktivierung.
• 2. NDR Essentials sollte aktiviert sein und mindestens ein Interface überwachen. Standard: Recommended, Schweregrad: Medium. Die Firewall analysiert ausgewählten Traffic über den Sophos-NDR-Cloud-Service, erkennt IoCs und protokolliert sie, blockiert sie aber nicht automatisch. Unterstützt werden ausgewählte Interfaces in LAN, DMZ und Custom Zones; WAN, Wi-Fi und mehrere Interface-Typen wie RED oder XFRM sind ausgeschlossen. Active-Active HA wird nicht unterstützt. Zusätzlich müssen Active-Threat-Response-Logs und je nach IoC-Typ Firewall-, DNS-, IPS- oder Decryption-Prüfungen greifen. Avanet-Einordnung: situationsabhängig bis optional. Nur aktivieren, wenn Lizenz, Cloud-Analyse, Datenschutz, geeignete Interfaces und Alert-Verantwortung geklärt sind. Ein vorhandenes NDR eines anderen Herstellers sollte nicht nur für einen grünen Health Check ersetzt werden.
• 3. Sophos X-Ops sollte aktiviert sein, Action Log and drop. Standard: CIS, Schweregrad: High. Die SophosLabs-Threat-Intelligence kann bekannte schädliche IP-Adressen, Domains und URLs blockieren. Avanet-Einordnung: situationsabhängig mit hohem Nutzen, wenn die erforderliche Lizenz vorhanden ist. Nach Aktivierung Logs und Ausnahmen prüfen; ein anderer wirksamer Threat-Intelligence-Prozess kann das Sicherheitsziel ebenfalls abdecken, wird vom Score aber nicht zwingend anerkannt.
• 4. MDR threat feeds sollten aktiviert sein, Action Log and drop. Standard: Recommended, Schweregrad: High. Dafür sind Sophos MDR, Sophos-Central-Registrierung und passende Firewall-Lizenzen erforderlich. MDR-Analysten können dann kundenspezifische Threat Intelligence an die Firewall übertragen. Avanet-Einordnung: optional. Wer Sophos MDR bereits betreibt, sollte die Integration konsequent nutzen; der verlinkte Ablauf erklärt Pilot, Audit-ID, Task Queue und Incident-Prüfung. Ohne MDR-Vertrag ist das Finding keine Konfigurationslücke, sondern eine Produkt- und Serviceempfehlung.
• 5. Synchronized Security Heartbeat sollte in einer Firewall-Regel verwendet werden. Standard: CIS, Schweregrad: Medium. Damit kann der Endpoint-Gesundheitsstatus den Zugriff beeinflussen. Avanet-Einordnung: situationsabhängig. Sehr nützlich in einer sauber betriebenen Sophos-Endpoint-Umgebung, aber nicht passend bei Microsoft Defender oder einem anderen EDR. Besonders wichtig ist ein Pilot: Geräte, die noch nie einen Heartbeat gesendet haben, können je nach Regel weiterhin zugreifen. Erst die Optionen Block clients with no heartbeat und Block request to destination with no heartbeat erzwingen das gewünschte Verhalten für solche Geräte.
• 6. Security Heartbeat sollte aktiviert sein. Standard: CIS, Schweregrad: High. Die Funktion verbindet Sophos Firewall und Sophos Endpoint über Sophos Central. Avanet-Einordnung: situationsabhängig. Bei Sophos Endpoint ist sie ein sinnvoller Baustein. Ohne Sophos Endpoint ist ein rotes Finding erwartbar und kein Beleg für eine unsichere Firewall.
• 12. DNS Protection sollte konfiguriert und aktiv sein. Standard: Recommended, Schweregrad: Medium. Sophos DNS Protection bietet cloudbasierte DNS-Policies und Reporting. Für einen aktiven Status braucht es die passende Lizenz, die DNS-Protection-Resolver auf der Firewall und die öffentliche Firewall-IP als Location in Sophos Central. Avanet-Einordnung: optional. Nur aktivieren, wenn dieser Dienst bewusst als DNS-Security-Layer betrieben und sein Log ausgewertet wird. Cisco Umbrella, Cloudflare Gateway, Microsoft oder andere DNS-Filter können dasselbe Sicherheitsziel abdecken, ohne dass der Sophos Health Check dies als compliant wertet.

Admin, Authentifizierung und Device Access

• 7. Login disclaimer sollte aktiviert sein. Standard: CIS, Schweregrad: Medium. Avanet-Einordnung: optional beziehungsweise Compliance. Ein rechtlich abgestimmter Hinweis kann in regulierten Umgebungen gefordert sein. Technisch schützt er die Firewall nicht und sollte nicht nur für einen besseren Score aktiviert werden.
• 8. Hotfix setting sollte aktiviert sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. In aktuellen SFOS-22-Versionen ist auf Backup & firmware > Firmware kein separater Hotfix-Block mehr sichtbar. Sophos installiert Hotfixes standardmässig automatisch; der Status lässt sich bei Bedarf in der Device Console mit system hotfix show prüfen. Ein fehlendes UI-Kontrollkästchen ist daher nicht selbst ein Finding.
• 9. Inaktive Sessions sollten beendet und Logins nach Fehlversuchen blockiert werden. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Session Timeout und Login-Sperren begrenzen den Missbrauch offener Sitzungen und automatisierter Anmeldeversuche. Werte so wählen, dass sie schützen, ohne Administratoren zu leicht auszusperren.
• 10. Passwortkomplexität für Benutzer sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität für lokale Konten, sonst situationsabhängig. Bei Entra ID, AD oder einem anderen IdP gelten primär dessen Passwort-, Lockout- und MFA-Policies. Lokale Notfall- und Portalbenutzer bleiben trotzdem separat zu prüfen.
• 11. Passwortkomplexität für Administratoren sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Zusätzlich sind persönliche Admin-Konten, MFA, eingeschränkte Managementnetze und das Entfernen ungenutzter Konten wichtiger als Komplexität allein.
• 13. MFA für Remote Access VPN Logins sollte aktiv sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Für SSL VPN und IPsec Remote Access gehört MFA zum Mindestschutz. Der Rollout braucht Testbenutzer, Notfallprozess und eine Prüfung aller verwendeten Authentifizierungswege.
• 14. MFA für WebAdmin Console und VPN Portal sollte aktiv sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Besonders wichtig ist dies bei aus WAN oder fremden Netzen erreichbaren Portalen. MFA ersetzt jedoch keine Einschränkung über Device Access und Local Service ACL.
• 15. Verbindungen zu Authentication Servern sollten verschlüsselt sein. Standard: CIS, Schweregrad: Medium. Avanet-Einordnung: hohe Priorität. LDAP ohne TLS oder andere unverschlüsselte Authentifizierungswege können Anmeldedaten und Verzeichnisinformationen offenlegen. Zertifikatsprüfung und Ausfallverhalten gehören zum Test.
• 17. Public-Key-Authentifizierung für SSH sollte aktiviert sein. Standard: Recommended, Schweregrad: High. Avanet-Einordnung: hohe Priorität, wenn SSH genutzt wird. Zusätzlich SSH nur aus vertrauenswürdigen Managementnetzen zulassen und ungenutzten Zugriff deaktivieren.
• 18. User Portal sollte nicht aus der WAN-Zone erreichbar sein. Standard: Recommended, Schweregrad: High. Avanet-Einordnung: hohe Priorität mit Ausnahmeprüfung. Wenn WAN-Zugriff fachlich nötig ist, Exposition so weit wie möglich einschränken, MFA erzwingen und Login-Logs überwachen.
• 19. WebAdmin Console sollte nicht aus der WAN-Zone erreichbar sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: höchste Priorität. WebAdmin nie breit ins Internet öffnen. Besser sind VPN oder ZTNA, ein Managementnetz und eng begrenzte Local Service ACL Exception Rules.
• 20. MFA für den Default-Admin sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Das Konto bleibt ein besonders schützenswerter Notfallzugang. Im Alltag sollten persönliche Admin-Konten mit passenden Rollen verwendet werden.

Backup, Updates, Regeln und Inspection

• 16. Backups sollten auf der Firewall oder in Sophos Central geplant sein. Standard: CIS, Schweregrad: Low. Avanet-Einordnung: hohe betriebliche Priorität. Die niedrige Sophos-Schwere ist kein guter Massstab für den Schaden eines fehlenden Restores. Backup verschlüsseln, extern aufbewahren und die Wiederherstellung dokumentiert testen.
• 21. Notification Emails sollten für System- und Security-Events konfiguriert sein. Standard: CIS, Schweregrad: Low. Sophos Firewall kann Benachrichtigungen per E-Mail und SNMP senden; die gewünschten Ereignisse werden unter System services > Notification list ausgewählt. Avanet-Einordnung: situationsabhängig. Entscheidend ist ein funktionierender und getesteter Alarmweg. Wenn Syslog, SIEM, Monitoring oder Central Alerts zuverlässig betrieben werden, ist E-Mail nicht zwingend die beste zusätzliche Kontrolle. Ein konfigurierter SMTP-Server ohne ausgewählte Events und Testzustellung ist noch keine Alarmierung.
• 22. Automatische Pattern-Updates sollten aktiviert sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität. Ohne aktuelle Patterns verlieren mehrere Schutzfunktionen an Wirkung. Der Ablauf zum Konfigurieren und Prüfen der Pattern-Updates zeigt Automatik, Status und die separate Installation der APX- und RED-Firmware. In Air-Gap-Umgebungen braucht es zusätzlich einen dokumentierten manuellen Pattern- und Lizenzprozess.
• 23. Eine Web Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: Recommended, Schweregrad: Medium. Avanet-Einordnung: situationsabhängig. Für Benutzer-Webtraffic oft sinnvoll, für Server-to-Server-, Update- oder Spezialtraffic nicht automatisch. Zuerst den Traffic-Pfad und die gewünschte Kontrolle bestimmen.
• 24. Zero-day protection sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: situationsabhängig mit hohem Nutzen für geeignete Web- und Download-Pfade. Lizenz, Dateitypen, Datenschutz, Verzögerung und False Positives müssen zum Betriebsmodell passen.
• 25. IPS sollte aktiviert sein und eine IPS Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: High. Avanet-Einordnung: hohe Priorität auf relevanten Traffic-Pfaden. Die Policy passend zu Client, Server und veröffentlichtem Dienst wählen, Logging aktivieren und Fehlalarme gezielt behandeln.
• 26. Eine Application-Control-Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: Medium. Avanet-Einordnung: situationsabhängig. Für Client-Internetregeln ist Transparenz und Kontrolle wertvoll. Bei kritischem oder unbekanntem Traffic zuerst im Log-Modus beobachten, bevor blockiert wird.
• 27. Eine SSL/TLS Inspection Rule sollte Action Decrypt verwenden. Standard: CIS, Schweregrad: High. Avanet-Einordnung: situationsabhängig, nicht blind aktivieren. Der Sicherheitsgewinn kann gross sein, aber CA-Verteilung, Datenschutz, Certificate Pinning, Ausnahmen, Pilotphase und Supportprozess sind Voraussetzungen. Ein gezielter Rollout ist besser als ein grüner Score mit instabilen Anwendungen.
• 28. Eine Allow-Regel sollte nicht überall Any bei Netzwerk- und Service-Feldern verwenden. Standard: CIS, Schweregrad: Medium. Avanet-Einordnung: hohe Priorität. Breite Regeln anhand realer Logdaten auf Quelle, Ziel und Service reduzieren. Ein notwendiges Any bleibt zulässig, sollte aber begründet, geloggt und regelmässig überprüft werden.

Sophos Central und Zeit

• 29. Sophos Central Reporting sollte aktiviert sein. Standard: Recommended, Schweregrad: Medium. Avanet-Einordnung: optional. Es ist bequem für zentrale und längere Auswertungen. Ein sauber betriebenes Syslog/SIEM kann das Betriebsziel ebenfalls erfüllen. Ein rotes Finding ist dann kein Reporting-Ausfall.
• 30. Sophos Central Management sollte registriert und aktiviert sein. Standard: Recommended, Schweregrad: Medium. Avanet-Einordnung: optional. Zentrale Verwaltung, Backups und Reporting sind praktisch, bringen aber Cloud-Abhängigkeit und zusätzliche Berechtigungen mit. Lokale, abgeschottete oder Air-Gap-Umgebungen dürfen bewusst darauf verzichten.
• 31. Ein NTP-Server sollte konfiguriert sein. Standard: CIS, Schweregrad: Low. Avanet-Einordnung: hohe betriebliche Priorität. Korrekte Zeit ist für Logs, Zertifikate, MFA, Kerberos und Fehleranalyse grundlegend. Mindestens zwei verlässliche Zeitquellen und Erreichbarkeit über den vorgesehenen Pfad prüfen.

Findings priorisieren und umsetzen

Nicht jedes Finding hat in jeder Umgebung dieselbe Bedeutung. Ein guter Review sortiert die Einträge deshalb nicht nur nach technischer Schwere, sondern auch nach Exposition und Betriebsrisiko.

Bewährt hat sich diese Reihenfolge:

1. Internetexponierte Management- und Portalzugriffe prüfen.
2. MFA und Login-Sicherheit für Admins, VPN Portal, User Portal und Remote Access prüfen.
3. Firewall-Regeln mit zu breiten Quellen, Zielen oder Services bereinigen.
4. Logging, Backups und Hotfixes kontrollieren.
5. Schutzfunktionen pro Regel prüfen, zum Beispiel IPS, Web Policy, Application Control, TLS Inspection oder Zero-Day Protection.
6. Central, Reporting oder NDR-Findings danach bewerten, ob die Funktion in der Umgebung wirklich genutzt und betrieben wird.

Die Reihenfolge ist pragmatisch: Zuerst die Dinge, die direkt im Internet sichtbar sind oder Zugriff auf die Firewall erlauben. Danach Regelhygiene und Schutzfunktionen. Danach Betriebs- und Ökosystemthemen.

Typische Findings und passende Massnahmen

WebAdmin, User Portal oder VPN Portal ist zu breit erreichbar

Wenn administrative oder benutzernahe Portale aus zu vielen Zonen erreichbar sind, steigt das Risiko durch Scans, Brute-Force-Versuche und Credential Stuffing. Der wichtigste Artikel dazu ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

Für produktive Umgebungen sollte man prüfen:

• Ist WebAdmin aus der WAN-Zone wirklich nötig?
• Gibt es eine Local Service ACL Exception Rule für Management-IP oder Admin-Netz?
• Ist SSH nur aus vertrauenswürdigen Netzen erlaubt?
• Sind User Portal und VPN Portal nur dort erreichbar, wo sie gebraucht werden?

MFA fehlt oder ist nicht konsequent aktiviert

MFA gehört mindestens auf administrative Zugänge und Remote Access. Wenn der Health Check MFA-Findings zeigt, sollte man nicht blind für alle Benutzer gleichzeitig umstellen. Besser ist ein kontrollierter Rollout mit Testbenutzer, Fallback-Admin und sauberem Token-Prozess.

Die praktische Anleitung steht in MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.

Firewall-Regeln sind zu offen

Sehr breite Regeln mit Any bei Quelle, Ziel oder Service sind oft historisch gewachsen. Nicht jede breite Regel ist automatisch falsch, aber jede sollte begründet sein.

Für die Bereinigung sind diese Fragen hilfreich:

• Welche Zone darf wirklich auf welche Zone zugreifen?
• Sind Zielnetze oder Services einschränkbar?
• Ist Logging aktiv, damit Treffer sichtbar werden?
• Gibt es alte Testregeln oder temporäre Ausnahmen?
• Kann die Regel in mehrere verständlichere Regeln aufgeteilt werden?

Die Grundlagen stehen in Sophos Firewall-Regeln verstehen und richtig konfigurieren. Wenn unklar ist, welche Regel greift, hilft Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Backups, Hotfixes und Update-Prozess fehlen

Ein Health Check kann auf fehlende Backups oder Update-/Hotfix-Themen hinweisen. Diese Punkte wirken weniger spektakulär als Portal-Exposure, sind im Ernstfall aber entscheidend.

Vor grösseren Änderungen sollte man ein Backup erstellen und wissen, wie ein Restore funktioniert. Der Ablauf ist in Sophos Firewall Backup erstellen oder wiederherstellen beschrieben. Für Firmware-Themen passt Sophos Firewall Firmware Update - Vorbereitung und Best Practices.

Logging und Reporting sind unvollständig

Wenn Logs fehlen, ist der Betrieb blind. Der Health Check kann Hinweise auf Logging- oder Reporting-Themen geben, aber die eigentliche Entscheidung hängt vom Betriebsmodell ab.

Für lokale Analyse sind Log Viewer, Service-Logs und Packet Capture relevant. Für längere Aufbewahrung braucht es Central Firewall Reporting oder Syslog/SIEM. Wenn nicht einzelne Logevents, sondern Traffic-Flows, Bandbreitenspitzen oder auffällige Kommunikationsbeziehungen untersucht werden sollen, passt zusätzlich sFlow Monitoring. Die lokalen Grundlagen stehen in Sophos Firewall Troubleshooting: Services und Logs.

Schutzfunktionen sind nicht in Regeln aktiv

Ein häufiger Punkt sind Regeln ohne IPS, Web Policy, Application Control, TLS Inspection oder Zero-Day Protection. Hier sollte man nicht pauschal alles aktivieren, sondern den Traffic-Pfad verstehen.

Beispiele:

• Benutzer-Webtraffic braucht andere Kontrollen als Server-to-Server-Traffic.
• TLS Inspection muss geplant eingeführt werden, weil sie Anwendungen stören kann.
• IPS und Application Control brauchen Logging und eine Review-Routine.
• NDR- oder Threat-Feed-Funktionen helfen nur, wenn Findings später auch ausgewertet werden.

Für TLS Inspection passt Sophos Firewall TLS Inspection richtig einführen. Für Threat Feeds passt Sophos Firewall Threat Feeds.

Review dokumentieren und nachprüfen

Sophos Firewall erlaubt, den Status einzelner Prüfungen manuell zu übersteuern. Das kann sinnvoll sein, wenn eine Empfehlung in der eigenen Umgebung bewusst nicht umgesetzt wird.

Overrides sollten aber nicht als Aufräumfunktion missverstanden werden. Sinnvoll sind sie nur, wenn die Anforderung bewusst anders erfüllt wird oder eine kompensierende Kontrolle existiert. Ein Beispiel ist MFA: Wenn eine Umgebung Microsoft Entra ID SSO mit MFA als verbindliche Login-Kontrolle nutzt, kann ein lokales MFA-Finding je nach Design fachlich begründet übersteuert werden. Ohne solche Begründung bleibt das Risiko bestehen, auch wenn die Health-Check-Anzeige besser aussieht.

Wenn ein Punkt übersteuert wird, sollte dokumentiert sein:

• Warum ist die Empfehlung nicht passend?
• Wer hat die Entscheidung genehmigt?
• Gilt die Ausnahme dauerhaft oder nur temporär?
• Wann wird sie erneut geprüft?
• Gibt es eine kompensierende Massnahme?

⚠️ Ein Override ist kein Fix. Er ist eine bewusste Risikoakzeptanz oder eine dokumentierte Ausnahme. Ohne Begründung wird der Health Check dadurch weniger wertvoll.

Ergebnis sauber dokumentieren

Ein Health-Check-Review sollte ein nachvollziehbares Ergebnis erzeugen. Sonst sieht man zwar kurz ein Dashboard, weiss aber später nicht mehr, welche Entscheidung getroffen wurde und welche Punkte noch offen sind.

Für kleine Umgebungen reicht oft eine kurze Tracking-Liste mit diesen Feldern:

• Datum: Wann wurde der Health Check geprüft?
• Firmware: Auf welcher SFOS-Version wurde bewertet?
• Finding: Welcher nicht konforme Punkt wurde gemeldet?
• Risiko: Warum ist der Punkt in dieser Umgebung relevant oder weniger relevant?
• Massnahme: Was wird geändert, getestet oder bewusst akzeptiert?
• Verantwortlich: Wer klärt den Punkt fachlich oder technisch?
• Termin: Bis wann soll die Massnahme erledigt oder erneut bewertet werden?
• Nachweis: Screenshot, Ticket, Change-ID oder Audit-Log-Hinweis.

Bei produktiven Firewalls sollte der Nachweis nicht nur aus einem Screenshot bestehen. Wenn eine Konfiguration geändert wurde, gehören Change-Ticket, Audit Trail, betroffene Firewall-Regel und Ergebnis der Nachkontrolle zusammen. Für Änderungen an Regeln, Interfaces, Hosts und Services ist Sophos Firewall Audit Trail Logs prüfen besonders nützlich.

Nach Änderungen erneut prüfen

Nach einem Fix sollte man den Health Check erneut öffnen und kontrollieren, ob das Finding wirklich verschwunden ist. Zusätzlich braucht es eine technische Funktionsprüfung, weil ein grüner Status allein nicht beweist, dass der produktive Traffic weiterhin korrekt läuft.

Beispiele:

• Nach einer Änderung an Device access prüfen, ob Adminzugriff aus dem vorgesehenen Managementnetz noch funktioniert und aus unerwünschten Netzen nicht mehr erreichbar ist.
• Nach MFA-Änderungen mit einem Testbenutzer anmelden und den Fallback-Admin getrennt prüfen.
• Nach Regelwerksänderungen Log Viewer, Policy Test und betroffene Anwendungen testen.
• Nach Logging- oder Reporting-Änderungen kontrollieren, ob neue Ereignisse lokal, in Sophos Central oder im Syslog wirklich sichtbar sind.
• Nach einem Override Wiedervorlage setzen, damit die Ausnahme nicht dauerhaft vergessen wird.

Wenn mehrere Findings gleichzeitig bearbeitet werden, sollte man die Änderungen in kleine Blöcke aufteilen. Sonst ist bei einem späteren Problem unklar, ob Device Access, MFA, Firewall-Regeln, TLS Inspection oder eine andere Änderung die Ursache war.

Health Check als Betriebsprozess nutzen

Der Health Check ist am stärksten, wenn er regelmässig und nach wichtigen Changes ausgeführt wird.

Sinnvolle Zeitpunkte:

• nach der Erstkonfiguration oder einem Go-live,
• vor und nach grösseren Regelwerksänderungen,
• vor Firmware-Upgrades,
• nach Restore oder Hardwaretausch,
• nach Migrationen oder grösseren Architekturänderungen,
• vor Audits,
• quartalsweise als Security Review.

Für Änderungen selbst sollte zusätzlich der Audit Trail genutzt werden. Der Artikel Sophos Firewall Audit Trail Logs prüfen erklärt, wie man configuration-audit.log auswertet und Konfigurationsänderungen nachvollzieht.

Praktischer Review-Ablauf

Ein pragmatischer Health-Check-Review läuft so:

1. Health Check im Control Center öffnen.
2. Nicht konforme Findings nach Schweregrad sortieren.
3. Internetexponierte Dienste und Admin-Zugänge zuerst prüfen.
4. MFA-, Passwort- und Session-Themen bearbeiten.
5. Breite Firewall-Regeln identifizieren und mit Log Viewer validieren.
6. Backup, Hotfixes, Logging und Reporting prüfen.
7. Schutzfunktionen pro Regel bewerten.
8. Berechtigte Ausnahmen dokumentieren statt kommentarlos zu übersteuern.
9. Nach Änderungen erneut prüfen.
10. Ergebnis mit Datum, Bearbeiter und offenen Punkten dokumentieren.

Für wiederkehrende Reviews reichen oft die Felder Finding, Risiko, Massnahme, Verantwortlicher, Status und Wiedervorlage. Wichtig ist, dass Findings nicht nur angesehen, sondern abgearbeitet oder bewusst akzeptiert werden.

Grenzen

Der Health Check ist hilfreich, hat aber klare Grenzen.

• Er kennt nicht die komplette Geschäftslogik der Umgebung.
• Er bewertet nicht, ob eine Regel fachlich benötigt wird.
• Er ersetzt keine Netzwerksegmentierung und kein Zonenmodell.
• Er erkennt nicht automatisch jeden riskanten Sonderfall.
• Er ersetzt kein externes Audit und keine manuelle Regelwerksprüfung.
• Er sagt nicht, ob Alerts später auch bearbeitet werden.

Darum sollte man den Health Check als Startpunkt sehen. Er macht sichtbare Abweichungen greifbar, aber die eigentliche Sicherheitsqualität entsteht durch gute Architektur, saubere Prozesse und konsequente Pflege.

Betriebscheckliste

• Health Check nach Go-live und nach grossen Changes ausführen.
• Findings nach Schweregrad und Exposition priorisieren.
• WAN-Erreichbarkeit von WebAdmin, SSH, User Portal und VPN Portal prüfen.
• MFA für Admins, Portale und Remote Access aktivieren.
• Breite Firewall-Regeln bereinigen oder begründen.
• Logging in wichtigen Regeln einschalten.
• Backups und Restore-Prozess prüfen.
• Hotfix- und Firmware-Prozess dokumentieren.
• Overrides nur mit Begründung setzen.
• Health-Check-Ergebnis regelmässig dokumentieren.

FAQ