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

Welcher Security-Artikel passt?

Der Health Check ist ein guter Startpunkt, aber nicht jedes Finding wird im Health-Check-Artikel vollständig gelöst. Für die praktische Umsetzung helfen diese Einstiege:

• Findings sammeln, priorisieren und dokumentieren: Dieser Artikel.
• WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping ist zu breit erreichbar: Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.
• MFA für Admins, VPN Portal oder Remote Access fehlt: MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.
• XML API oder Automationszugriff ist zu offen: Sophos Firewall XML API Zugriff absichern.
• Firewall-Regeln sind zu breit oder unklar: Sophos Firewall-Regeln verstehen und richtig konfigurieren.
• IPS soll aktiviert oder geprüft werden: Sophos Firewall IPS einrichten und sicher testen.
• TLS Inspection soll eingeführt werden: Sophos Firewall TLS Inspection richtig einführen.
• Web Protection, Kategorien oder Instant Alerts sind relevant: Sophos Firewall Web-Kategorien und Instant Alerts nutzen.
• DNS-Schutz soll über Sophos Central betrieben werden: Sophos DNS Protection mit Sophos Firewall einrichten.
• Threat Feeds, NDR oder Active Threat Response sollen Findings liefern: Sophos Firewall NDR und Active Threat Response betreiben.
• Konfigurationsänderungen müssen nachvollziehbar sein: Sophos Firewall Audit Trail Logs prüfen.

Diese Aufteilung verhindert zwei typische Fehler: Findings werden entweder nur als Dashboard-Meldung betrachtet, ohne sie technisch abzuarbeiten, oder es werden Schutzfunktionen pauschal aktiviert, ohne Logging, Ausnahmen und Verantwortlichkeiten zu klären.

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.

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 der Score sollte nicht zum Selbstzweck werden. Einige Punkte sind klare Sicherheitsbasics, zum Beispiel MFA, Hotfixes, Passwortregeln, eingeschränkter WebAdmin-Zugriff, Backups oder IPS. Andere Punkte sind stärker vom Sophos-Ökosystem, der Lizenzierung oder vom Betriebsmodell abhängig.

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 dadurch nur der Health-Check-Score steigt, ist der Mehrwert überschaubar.

Ähnlich ist es bei Funktionen wie DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control oder Sophos Central Reporting. Diese Funktionen können sinnvoll sein, wenn sie lizenziert, verstanden, überwacht und im Betrieb wirklich genutzt werden. Blind einschalten sollte man sie aber nicht, nur weil der Health Check sie empfiehlt. Entscheidend ist immer: Reduziert die Massnahme ein echtes Risiko in dieser Umgebung, und gibt es einen Owner für Betrieb, Ausnahmen und False Positives?

Als Faustregel:

• Internetexponierte Managementzugriffe, MFA, 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 und Synchronized Security sind sinnvoll, wenn die Funktion genutzt, lizenziert, überwacht und in Prozesse eingebunden ist. Ein besserer Score allein reicht nicht als Begründung.
• Login disclaimer ist meist eher Compliance-/Hinweisfunktion als technische Schutzmassnahme. Aktivieren sollte man ihn nur, wenn es wirklich gefordert oder gewünscht ist.

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. High-Findings mit Internetexposition, Adminzugang, MFA, Hotfixes oder Regelwerk sollten zuerst geprüft werden. Medium- und Low-Findings können trotzdem wichtig sein, wenn sie in einer regulierten Umgebung, bei einem Audit oder in einem MSP-Betriebsmodell relevant sind.

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 31 Health-Check-Prüfungen im Überblick

Die folgende Liste orientiert sich an der englischen Health-Check-Ansicht. 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. Sinnvoll ist das vor allem in Sophos-Endpoint-Umgebungen. In gemischten oder Microsoft-Defender-Umgebungen sollte man zuerst prüfen, ob die Funktion tatsächlich Daten liefert.
• 2. NDR Essentials sollte aktiviert sein und mindestens ein Interface überwachen. Standard: Recommended, Schweregrad: Medium. Wertvoll ist das nur, wenn die überwachten Interfaces sinnvoll gewählt sind und Findings später ausgewertet werden.
• 3. Sophos X-Ops sollte aktiviert sein, Action Log and drop. Standard: CIS, Schweregrad: High. Sicherheitsrelevant ist das, wenn Threat Feeds aktiv genutzt werden. False Positives und Logging müssen geprüft werden.
• 4. MDR threat feeds sollten aktiviert sein, Action Log and drop. Standard: Recommended, Schweregrad: High. Sinnvoll ist das nur, wenn MDR beziehungsweise passende Threat-Feed-Funktionen lizenziert und betrieblich eingebunden sind.
• 5. Synchronized Security Heartbeat sollte in einer Firewall-Regel verwendet werden. Standard: CIS, Schweregrad: Medium. Der Mehrwert ist stark, wenn Sophos Endpoint genutzt wird. Ohne Sophos Endpoint sollte man das nicht nur als Score-Thema betrachten.
• 6. Security Heartbeat sollte aktiviert sein. Standard: CIS, Schweregrad: High. Wichtig ist das in Sophos-Endpoint-Umgebungen. Sonst ist zuerst das Endpoint-Design zu klären.
• 12. DNS Protection sollte konfiguriert und aktiv sein. Standard: Recommended, Schweregrad: Medium. DNS Protection sollte nicht pauschal aktiviert werden, sondern nur wenn Central-DNS-Policies und Reporting wirklich genutzt werden.

Admin, Authentifizierung und Device Access

• 7. Login disclaimer sollte aktiviert sein. Standard: CIS, Schweregrad: Medium. Das ist vor allem ein Compliance-Thema. Technisch ist die Schutzwirkung gering, dafür entsteht ein zusätzlicher Klick beim Login.
• 8. Hotfix setting sollte aktiviert sein. Standard: CIS, Schweregrad: High. Hotfixes sollten in produktiven Umgebungen aktiv sein, sofern der Change-Prozess das erlaubt.
• 9. Inaktive Sessions sollten beendet und Logins nach Fehlversuchen blockiert werden. Standard: CIS, Schweregrad: High. Das ist klare Login-Härtung und besonders wichtig bei exponierten Portalen und Adminzugängen.
• 10. Passwortkomplexität für Benutzer sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Relevant ist das besonders bei lokalen Benutzern und Portalen. Bei externem IdP sollte zusätzlich dessen Passwort- und MFA-Policy geprüft werden.
• 11. Passwortkomplexität für Administratoren sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Das ist Basis-Härtung. Noch wichtiger sind individuelle Admins, MFA und eingeschränkter Zugriff.
• 13. MFA für Remote Access VPN Logins sollte aktiv sein. Standard: CIS, Schweregrad: High. Sehr wichtig für SSL VPN und IPsec Remote Access. Der Rollout braucht Fallback-Admin und Testbenutzer.
• 14. MFA für WebAdmin Console und VPN Portal sollte aktiv sein. Standard: CIS, Schweregrad: High. Besonders wichtig ist das, wenn Portale aus weniger stark kontrollierten Netzen erreichbar sind.
• 15. Verbindungen zu Authentication Servern sollten verschlüsselt sein. Standard: CIS, Schweregrad: Medium. Bei AD/LDAP/RADIUS-Anbindungen sollte unverschlüsselte Authentifizierung vermieden werden.
• 17. Public-Key-Authentifizierung für SSH sollte aktiviert sein. Standard: Recommended, Schweregrad: High. Zusätzlich sollte SSH nur aus vertrauenswürdigen Netzen erlaubt werden.
• 18. User Portal sollte nicht aus der WAN-Zone erreichbar sein. Standard: Recommended, Schweregrad: High. Wenn WAN-Zugriff nötig ist, sollte er stark eingeschränkt und mit MFA geschützt werden.
• 19. WebAdmin Console sollte nicht aus der WAN-Zone erreichbar sein. Standard: CIS, Schweregrad: High. Das ist einer der wichtigsten Punkte. WebAdmin sollte nie breit ins Internet geöffnet werden.
• 20. MFA für den Default-Admin sollte konfiguriert sein. Standard: CIS, Schweregrad: High. Zusätzlich braucht es einen sauberen Admin-Prozess mit persönlichen Admin-Konten.

Backup, Updates, Regeln und Inspection

• 16. Backups sollten auf der Firewall oder in Sophos Central geplant sein. Standard: CIS, Schweregrad: Low. Der Schweregrad wirkt niedrig, aber im Ernstfall ist der Punkt extrem wichtig. Der Restore-Prozess sollte ebenfalls getestet werden.
• 21. Notification Emails sollten für System- und Security-Events konfiguriert sein. Standard: CIS, Schweregrad: Low. Alternativ oder zusätzlich können Monitoring, Syslog, SIEM oder Central Alerts eingebunden werden.
• 22. Automatische Pattern-Updates sollten aktiviert sein. Standard: CIS, Schweregrad: High. Ohne aktuelle Pattern verlieren viele Schutzfunktionen an Wert. In Air-Gap-Umgebungen braucht es stattdessen einen manuellen Pattern- und Lizenzprozess.
• 23. Eine Web Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: Recommended, Schweregrad: Medium. Das ist für Benutzer-Webtraffic sinnvoll, sollte aber nicht blind auf Server-to-Server- oder Spezialtraffic angewendet werden.
• 24. Zero-day protection sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: High. Das passt für geeignete Web- und Download-Pfade. Lizenz, Performance und False Positives müssen berücksichtigt werden.
• 25. IPS sollte aktiviert sein und eine IPS Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: High. IPS ist ein wichtiger Schutzpunkt, muss aber pro Traffic-Pfad passend gewählt und geloggt werden.
• 26. Eine Application-Control-Policy sollte in einer Firewall-Regel ausgewählt sein. Standard: CIS, Schweregrad: Medium. Für Client-Internetregeln ist das sinnvoll. Bei kritischem Traffic sollte man zuerst testen.
• 27. Eine SSL/TLS Inspection Rule sollte Action Decrypt verwenden. Standard: CIS, Schweregrad: High. TLS Inspection sollte nicht blind aktiviert werden, weil CA-Verteilung, Ausnahmen, Pilotphase und Troubleshooting-Prozess nötig sind.
• 28. Eine Allow-Regel sollte nicht überall Any bei Netzwerk- und Service-Feldern verwenden. Standard: CIS, Schweregrad: Medium. Any kann bewusst nötig sein, muss dann aber begründet und geloggt sein.

Sophos Central und Zeit

• 29. Sophos Central Reporting sollte aktiviert sein. Standard: Recommended, Schweregrad: Medium. Das ist nützlich für Reporting und längere Auswertungen, aber nicht zwingend, wenn Syslog/SIEM sauber betrieben wird.
• 30. Sophos Central Management sollte registriert und aktiviert sein. Standard: Recommended, Schweregrad: Medium. Praktisch ist das für zentrale Verwaltung, Backups und Reporting. Nicht jede Umgebung will oder braucht Cloud-Management.
• 31. Ein NTP-Server sollte konfiguriert sein. Standard: CIS, Schweregrad: Low. Ohne korrekte Zeit leiden Logs, Zertifikate, Authentifizierung und Troubleshooting.

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