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.
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.
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:
| Situation | Besserer Einstieg |
|---|---|
| Findings sammeln, priorisieren und dokumentieren | Dieser Artikel |
| WebAdmin, SSH, User Portal, VPN Portal, DNS oder Ping 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 nicht als Ziel missverstehen
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:
| Kategorie | Bewertung |
|---|---|
| Internetexponierte Managementzugriffe, MFA, Hotfixes, Backups, Passwortregeln, IPS | In der Regel echte Sicherheits- oder Betriebsbasics. Diese Punkte sollten sehr ernst genommen werden. |
| Logging, Reporting, Benachrichtigungen, NTP | Wichtig für Betrieb und Nachvollziehbarkeit. Der konkrete Weg hängt aber vom Betriebsmodell ab. |
| DNS Protection, NDR, MDR threat feeds, X-Ops, Synchronized Security | Sinnvoll, wenn die Funktion genutzt, lizenziert, überwacht und in Prozesse eingebunden ist. Nicht automatisch besser nur wegen Score. |
| Login disclaimer | Meist eher Compliance-/Hinweisfunktion als technische Schutzmassnahme. Nur aktivieren, 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ü:
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.
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.
| Nr. | Prüfung | Modul | Standard | Schweregrad | Einordnung |
|---|---|---|---|---|---|
| 1 | Synchronized Application Control sollte aktiviert sein. | Active threat response | Recommended | Medium | Sinnvoll in Sophos-Endpoint-Umgebungen. In gemischten oder Microsoft-Defender-Umgebungen zuerst prüfen, ob die Funktion tatsächlich Daten liefert. |
| 2 | NDR Essentials sollte aktiviert sein und mindestens ein Interface überwachen. | Active threat response | Recommended | Medium | Nur wertvoll, 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. | Active threat response | CIS | High | Sicherheitsrelevant, 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. | Active threat response | Recommended | High | Nur sinnvoll, wenn MDR beziehungsweise passende Threat-Feed-Funktionen lizenziert und betrieblich eingebunden sind. |
| 5 | Eine Firewall-Regel sollte Synchronized Security Heartbeat verwenden. | Active threat response and Advanced security | CIS | Medium | Starker Mehrwert mit Sophos Endpoint. Ohne Sophos Endpoint nicht einfach als Score-Thema betrachten. |
| 6 | Security Heartbeat sollte aktiviert sein. | Active threat response and Advanced security | CIS | High | Wichtig, wenn Sophos Endpoint genutzt wird. Sonst ist zuerst das Endpoint-Design zu klären. |
| 7 | Login disclaimer sollte aktiviert sein. | Admin settings | CIS | Medium | Compliance-Thema. Technisch wenig Schutzwirkung, erzeugt aber einen zusätzlichen Klick beim Login. |
| 8 | Hotfix setting sollte aktiviert sein. | Admin settings | CIS | High | Sehr wichtig. Hotfixes sollten in produktiven Umgebungen aktiv sein, sofern der Change-Prozess das erlaubt. |
| 9 | Inaktive Sessions sollten beendet und Logins nach Fehlversuchen blockiert werden. | Admin settings | CIS | High | Klare Login-Härtung. Besonders wichtig bei exponierten Portalen und Adminzugängen. |
| 10 | Passwortkomplexität sollte für Benutzer konfiguriert sein. | Admin settings | CIS | High | Sinnvoll, besonders bei lokalen Benutzern und Portalen. Bei externem IdP zusätzlich dessen Passwort- und MFA-Policy prüfen. |
| 11 | Passwortkomplexität sollte für Administratoren konfiguriert sein. | Admin settings | CIS | High | Basis-Härtung. Noch wichtiger sind individuelle Admins, MFA und eingeschränkter Zugriff. |
| 12 | DNS Protection sollte konfiguriert und aktiv sein. | Advanced security | Recommended | Medium | Nicht pauschal aktivieren. DNS Protection ist sinnvoll, wenn Central-DNS-Policies und Reporting wirklich genutzt werden. |
| 13 | MFA sollte für Remote Access VPN Logins aktiv sein. | Authentication | CIS | High | Sehr wichtig für SSL VPN und IPsec Remote Access. Rollout mit Fallback-Admin und Testbenutzern planen. |
| 14 | MFA sollte für WebAdmin Console und VPN Portal aktiv sein. | Authentication | CIS | High | Sehr wichtig, besonders wenn Portale aus weniger stark kontrollierten Netzen erreichbar sind. |
| 15 | Verbindungen zu Authentication Servern sollten verschlüsselt sein. | Authentication servers | CIS | Medium | Wichtig bei AD/LDAP/RADIUS-Anbindungen. Unverschlüsselte Authentifizierung vermeiden. |
| 16 | Backups sollten auf der Firewall oder in Sophos Central geplant sein. | Backup & restore | CIS | Low | Niedriger Schweregrad, aber im Ernstfall extrem wichtig. Restore-Prozess ebenfalls testen. |
| 17 | Public-Key-Authentifizierung sollte für SSH aktiviert sein. | Device access | Recommended | High | Sehr sinnvoll. Zusätzlich SSH nur aus vertrauenswürdigen Netzen erlauben. |
| 18 | User Portal sollte nicht aus der WAN-Zone erreichbar sein. | Device access | Recommended | High | In vielen Umgebungen richtig. Wenn WAN-Zugriff nötig ist, stark einschränken und MFA verwenden. |
| 19 | WebAdmin Console sollte nicht aus der WAN-Zone erreichbar sein. | Device access | CIS | High | Einer der wichtigsten Punkte. WebAdmin niemals breit ins Internet öffnen. |
| 20 | MFA sollte für den Default-Admin konfiguriert sein. | Device access | CIS | High | Wichtig, aber besser ist zusätzlich ein sauberer Admin-Prozess mit persönlichen Admin-Konten. |
| 21 | Notification Emails sollten für System- und Security-Events konfiguriert sein. | Notification settings | CIS | Low | Betrieblich wichtig. Alternativ oder zusätzlich Monitoring, Syslog, SIEM oder Central Alerts einbinden. |
| 22 | Automatische Pattern-Updates sollten aktiviert sein. | Pattern updates | CIS | High | Basisbetrieb. 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. | Rules and Policies | Recommended | Medium | Für Benutzer-Webtraffic sinnvoll. Nicht blind auf Server-to-Server- oder Spezialtraffic anwenden. |
| 24 | Zero-day protection sollte in einer Firewall-Regel ausgewählt sein. | Rules and Policies | CIS | High | Sinnvoll für passende Web- und Download-Pfade. Lizenz, Performance und False Positives beachten. |
| 25 | IPS sollte aktiviert sein und eine IPS Policy sollte in einer Firewall-Regel ausgewählt sein. | Rules and Policies | CIS | High | Sehr wichtiger Schutzpunkt. IPS muss aber pro Traffic-Pfad passend gewählt und geloggt werden. |
| 26 | Eine Application-Control-Policy sollte in einer Firewall-Regel ausgewählt sein. | Rules and Policies | CIS | Medium | Für Client-Internetregeln sinnvoll. Bei kritischem Traffic zuerst testen. |
| 27 | Eine SSL/TLS Inspection Rule sollte Action Decrypt verwenden. | Rules and Policies | CIS | High | Nicht blind aktivieren. TLS Inspection braucht CA-Verteilung, Ausnahmen, Pilotphase und Troubleshooting-Prozess. |
| 28 | Eine Allow-Regel sollte nicht überall Any bei Netzwerk- und Service-Feldern verwenden. | Rules and Policies | CIS | Medium | Sehr wichtig für Regelhygiene. Any kann bewusst nötig sein, muss dann aber begründet und geloggt sein. |
| 29 | Sophos Central Reporting sollte aktiviert sein. | Sophos central | Recommended | Medium | Nützlich für Reporting und längere Auswertungen. Nicht zwingend, wenn Syslog/SIEM sauber betrieben wird. |
| 30 | Die Firewall sollte für Sophos Central Management registriert und Central Management aktiviert sein. | Sophos central | Recommended | Medium | Praktisch für zentrale Verwaltung, Backups und Reporting. Nicht jede Umgebung will oder braucht Cloud-Management. |
| 31 | Ein NTP-Server sollte konfiguriert sein. | Time | CIS | Low | Basisanforderung. Ohne korrekte Zeit leiden Logs, Zertifikate, Authentifizierung und Troubleshooting. |
Findings richtig priorisieren
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:
- Internetexponierte Management- und Portalzugriffe prüfen.
- MFA und Login-Sicherheit für Admins, VPN Portal, User Portal und Remote Access prüfen.
- Firewall-Regeln mit zu breiten Quellen, Zielen oder Services bereinigen.
- Logging, Backups und Hotfixes kontrollieren.
- Schutzfunktionen pro Regel prüfen, zum Beispiel IPS, Web Policy, Application Control, TLS Inspection oder Zero-Day Protection.
- 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.
Overrides bewusst dokumentieren
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. 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 einfache Tabelle:
| Feld | Zweck |
|---|---|
| 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:
- Health Check im Control Center öffnen.
- Nicht konforme Findings nach Schweregrad sortieren.
- Internetexponierte Dienste und Admin-Zugänge zuerst prüfen.
- MFA-, Passwort- und Session-Themen bearbeiten.
- Breite Firewall-Regeln identifizieren und mit Log Viewer validieren.
- Backup, Hotfixes, Logging und Reporting prüfen.
- Schutzfunktionen pro Regel bewerten.
- Berechtigte Ausnahmen dokumentieren statt kommentarlos zu übersteuern.
- Nach Änderungen erneut prüfen.
- Ergebnis mit Datum, Bearbeiter und offenen Punkten dokumentieren.
Für wiederkehrende Reviews reicht oft eine einfache Tabelle mit Finding, Risiko, Massnahme, Verantwortlichem, 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.