Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration

Sophos Firewall Hardening bedeutet, die Firewall selbst und die darüber veröffentlichten Dienste bewusst gegen unnötige Angriffsfläche abzusichern. Es geht nicht um eine einzelne magische Einstellung, sondern um einen wiederholbaren Betriebsprozess: Managementzugriffe begrenzen, MFA erzwingen, Firmware aktuell halten, Regeln prüfen, Schutzfunktionen aktivieren und Logs auswerten.

Dieser Artikel ist der zentrale Einstiegspunkt. Er ersetzt nicht die Detailanleitungen, sondern ordnet die wichtigsten Best Practices ein und verlinkt auf die passenden Avanet-KB-Artikel.

Was zuerst geprüft werden sollte

Beim Hardening zählt die Reihenfolge. Eine perfekt getunte IPS-Policy hilft wenig, wenn WebAdmin weltweit über WAN erreichbar ist oder ein altes VPN-Portal ohne MFA offensteht.

Die wichtigsten Sofortprüfungen:

• Ist WebAdmin aus der WAN-Zone erreichbar?
• Ist SSH nur aus vertrauenswürdigen Managementnetzen erlaubt?
• Ist MFA für Admins, VPN Portal und Remote Access aktiv?
• Sind Firmware, Hotfixes und Pattern-Updates aktuell?
• Gibt es DNAT-, WAF- oder VPN-Zugriffe, die nicht mehr benötigt werden?
• Haben veröffentlichte Dienste IPS, WAF, Threat Feeds, Logging und klare Zuständigkeit?
• Werden sicherheitsrelevante Logs unabhängig von der Firewall aufbewahrt und überwacht, mit festgelegter Zuständigkeit und Aufbewahrungsdauer?
• Gibt es ein aktuelles, getestetes Backup inklusive Secure Storage Master Key?

Managementzugriff absichern

Der wichtigste Hardening-Bereich ist der Zugriff auf die Firewall selbst. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal und lokale Dienste sind keine normalen Firewall-Regeln, sondern lokale Dienste der Firewall. Diese Dienste müssen über Device Access und Local Service ACL bewusst begrenzt werden.

Device Access und Local Service ACL

Unter Administration > Device access wird pro Zone festgelegt, welche lokalen Dienste erreichbar sind. Für die WAN-Zone sollte nur aktiv sein, was wirklich gebraucht wird. Admin-Zugriff und SSH gehören normalerweise nicht breit ins Internet.

Wenn Remote-Administration nötig ist, sind diese Varianten sauberer:

• Verwaltung über Sophos Fusion (ehemals Sophos Central).
• Zugriff über ein dediziertes Managementnetz.
• Zugriff über VPN oder ZTNA.
• Eng begrenzte Local Service ACL Exception Rules für feste Admin-Quell-IP-Adressen.

Die konkrete Umsetzung beschreibt Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren. Wenn SSH benötigt wird, hilft zusätzlich Sophos Firewall per SSH verbinden.

Für eine WAN-Ausnahme sollte man sich nicht selbst aussperren. Zuerst einen unabhängigen Rückweg über Konsole, Management-LAN, Admin-VPN oder Sophos Fusion anmelden und testen. Dann unter Administration > Device access bei Local service ACL exception rule auf Add klicken. Ein anpassbares Beispiel ist WAN-Admin-203.0.113.10 mit Rule position Top, IP version IPv4, Source zone WAN, der festen öffentlichen Admin-IP als Source network / host, dem WAN-Interface der Firewall als Destination host, Services HTTPS und nur bei Bedarf SSH sowie Action Accept. 203.0.113.10 ist nur eine Dokumentationsadresse und muss durch die tatsächliche feste Admin-IP ersetzt werden. Die bisherige Admin-Sitzung ebenfalls offen lassen, den Zugriff in einer zweiten Sitzung von dieser Quelle testen und erst danach die breitere WAN-Freigabe für HTTPS oder SSH in Local service ACL entfernen. Schlägt der Test fehl, bleibt die Zonenfreigabe unverändert; die Ausnahme wird über den getesteten Rückweg korrigiert.

MFA, Rollen und Login Security

VPN Portal nicht nur für Downloads einplanen: VPN-Clients und geänderte Konfigurationen werden über das VPN Portal verteilt. Zusätzlich benötigt SSO die erforderliche WAN-Erreichbarkeit dauerhaft: In SFOS 22 betrifft dies Microsoft Entra ID SSO, in SFOS 23 OpenID Connect SSO. Nach Downloads darf man deshalb nicht den noch benötigten SSO-Pfad schliessen. Das User Portal bleibt auf WAN deaktiviert; der Fernzugriff darauf erfolgt über VPN. Die VPN-Portal-Freigabe wird mit geeigneten, möglichst engen ACLs, einem gültigen Zertifikat und Brute-Force-Überwachung abgesichert. MFA wird bei OIDC im IdP durchgesetzt, nicht durch zusätzliches Firewall-OTP. Die folgenden lokalen OTP-Schritte gelten für klassische Authentifizierung, nicht für OIDC. Die Einrichtung erklären Entra VPN SSO und Google Workspace OIDC. Nach ACL- oder Authentifizierungsänderungen eine frische Anmeldung und den tatsächlichen VPN-Tunnel aus dem vorgesehenen externen Netz testen; bei Fehlern ACL, Zertifikat und Redirect-Zuordnung prüfen, statt den WAN-Zugriff pauschal zu öffnen.

MFA sollte für Administratoren und Remote-Access-Benutzer Pflicht sein. Besonders kritisch sind lokale Admin-Konten, VPN Portal, User Portal und Remote Access VPN. MFA ist aber nur ein Teil des Login-Hardenings. Ebenso wichtig sind eigene Admin-Konten, klare Rollen, starke Passwortrichtlinien, begrenzte Login-Versuche und kurze Session-Timeouts.

In SFOS 22 liegt die Benutzerkonfiguration unter Authentication > Multi-factor authentication (MFA). Dort wählt man unter One-time password (OTP) All users oder Specific users and groups, aktiviert bei App-basierten Tokens Generate OTP token with next sign-in und markiert unter Require MFA for jeden tatsächlich verwendeten Dienst. Das eingebaute Konto admin wird separat unter Administration > Device access > MFA for default admin geschützt. Vor dem Erzwingen sollte mindestens ein persönliches Administratorkonto seinen Token registriert haben; unter Issued tokens lässt sich die Ausgabe kontrollieren. Danach prüft man eine neue Anmeldung, während eine bestehende Admin-Sitzung als Rückweg offen bleibt.

Die praktische Einrichtung steht in MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren. Wie persönliche lokale Konten, Device-Access-Profile, Login-Quellen und Offboarding zusammenspielen, erklärt Sophos Firewall Administratoren und Profile sicher einrichten. Für WAF-Szenarien mit Benutzeranmeldung passt Sophos Firewall WAF mit MFA absichern.

Remote-VPN-Berechtigungen prüfen

VPN-Zugriff wird nur den benötigten Benutzern und Gruppen und nur auf die erforderlichen Ressourcen gewährt. Die standardmässige Fallback-Gruppe Open group darf dafür nicht ausgewählt werden. Dort können Benutzer ohne passende Gruppenzuordnung landen, etwa bei AD-Synchronisation. Mitglieder regelmässig prüfen und den richtigen Gruppen zuweisen. Diese Standardgruppe ist weder eine Fallback-Firewall-Regel noch die bewusst eingeschränkte IdP-Fallback-Gruppe aus der verlinkten SSO-Anleitung. Die providerabhängige Zuordnung bleibt dort beschrieben. Zur Abnahme einen erlaubten Benutzer, einen Fallback-/nicht zugeordneten Benutzer und eine nicht erlaubte Ressource testen: Nur der vorgesehene Zugriff darf funktionieren. Bei unerwartetem Erfolg Gruppenzuordnung und VPN-/Firewall-Berechtigungen korrigieren und erneut testen.

Firmware, Hotfixes und Recovery

Eine Firewall ist ein Edge-System. Verzögerte Updates sind deshalb kein kleiner Schönheitsfehler, sondern ein echtes Angriffsfenster. Gleichzeitig dürfen Updates nicht blind erfolgen, weil Remote-Standorte, HA-Cluster, VPNs und produktive NAT-Regeln betroffen sein können.

Updates planbar machen

Firmware-Updates sollten mit Backup, Wartungsfenster, Release-Notes-Prüfung, HA-Planung und Rollback-Kriterien vorbereitet werden. Verfügbare Maintenance Releases werden regelmässig geprüft und nach Freigabe zeitnah eingespielt. In aktuellen SFOS-22-Versionen erscheint auf der WebAdmin-Seite Backup & Firmware > Firmware kein separater Hotfix-Block mehr. Die Hotfix-Funktion besteht aber weiterhin: Sophos installiert Hotfixes standardmässig automatisch und empfiehlt, diese Einstellung nicht zu ändern. Wenn der Status geprüft werden muss, erfolgt das über die Device Console mit system hotfix show. Hotfixes ersetzen aber keinen regulären Update-Prozess. Der Ablauf ist in Sophos Firewall Firmware Update: Vorbereitung und Best Practices beschrieben.

Die Seite hält höchstens zwei Firmware-Versionen vor. Ein Rollback bootet die vorherige Version mit der zugehörigen damaligen Konfiguration; Änderungen seit dem Versionswechsel gehen dabei verloren. Seit SFOS 19.0 MR1 benötigt man nach drei kostenlosen Firmware-Wechseln Enhanced Support oder Enhanced Plus; Hotfixes benötigen dieses Support-Abonnement nicht. Deshalb gehören die erwartete Firmware, Management-Erreichbarkeit, VPNs und kritische Veröffentlichungen in den Abnahmetest, bevor nach dem Update weitere Konfigurationsänderungen erfolgen.

Für grössere Versionssprünge sollte man zusätzlich Upgrade-Pfad, Lizenz, Plattform und bekannte Einschränkungen prüfen. Dafür passt Sophos Firewall vor SFOS 22 Upgrade prüfen.

Backup und Restore prüfen

Hardening endet nicht bei Prävention. Eine gehärtete Firewall muss auch wiederherstellbar sein. Dazu gehören ein aktuelles Backup, das Backup-Passwort, der Secure Storage Master Key, ein dokumentierter Zugriffspfad nach Restore und ein Abnahmetest.

Die Details stehen in Sophos Firewall Backup erstellen oder wiederherstellen. Besonders vor Firmware-Updates, Migrationen, Reimage und Hardwaretausch ist ein vollständiges Recovery-Paket Pflicht.

Eine besondere Compliance-Migration ist der FIPS-140-3-Modus auf Sophos Firewall: Seine Aktivierung führt einen Factory Reset aus und verlangt einen vollständig geplanten Wiederaufbau mit FIPS-konformen VPN- und Zertifikatswerten.

Angriffsfläche im Regelwerk reduzieren

Viele Risiken entstehen nicht durch exotische Angriffe, sondern durch zu breite Regeln, alte Ausnahmen und veröffentlichte Dienste, die niemand mehr wirklich verantwortet.

NAT, WAF und veröffentlichte Dienste

Jeder per DNAT oder WAF veröffentlichte Dienst ist ein bewusst geöffneter Eingang. Das kann nötig sein, muss aber eng geplant werden: Quelle, Ziel, Service, NAT-Reihenfolge, Firewall-Regel, IPS/WAF-Policy, Logging, Test und Owner gehören zusammen.

Für veröffentlichte Server helfen Server per DNAT auf Sophos Firewall veröffentlichen und NAT auf Sophos Firewall verstehen. Wenn Webserver veröffentlicht werden, ist Sophos Firewall WAF: Webserver sicher veröffentlichen die passendere Grundlage.

Firewall-Regeln und Segmentierung

Regeln mit Any bei Source, Destination oder Service sind nicht automatisch falsch, aber immer erklärungspflichtig. Für Hardening sind besonders diese Fragen wichtig:

• Ist die Regel noch nötig?
• Ist Logging aktiv?
• Gibt es eine klarere Source oder Destination?
• Ist die Regel vor breiteren Regeln richtig positioniert?
• Sind Admin-, Server-, Client-, IoT-, Gast- und Backup-Netze sauber getrennt?

Grundlagen dazu stehen in Sophos Firewall-Regeln verstehen und sicher konfigurieren. Zum Prüfen einer konkreten Regel passt Sophos Firewall-Regel sauber testen.

Schutzfunktionen bewusst aktivieren

Schutzfunktionen bringen nur dann etwas, wenn sie zur Regel, zum Traffic und zum Betriebsprozess passen. Blind aktivierte Funktionen erzeugen False Positives, Performance-Probleme oder Supportfälle. Nicht aktivierte Funktionen lassen dagegen unnötig viel Angriffsfläche offen.

IPS, Spoof Protection und DoS

IPS sollte auf eingehendem, nicht vertrauenswürdigem Traffic und auf relevanten internen Übergängen eingesetzt werden. Wichtig sind passende IPS Policies, Logging, False-Positive-Prozess und Performance-Blick. Die Umsetzung steht in Sophos Firewall IPS einrichten und sicher testen.

Spoof Protection und DoS Settings reduzieren unplausible Quellen und einfache Flooding-Muster. Die Aktivierung muss aber vorsichtig getestet werden, besonders bei VoIP, VPN, hoher Paketlast oder speziellen Routing-Designs. Der passende Artikel ist Sophos Firewall Spoof Protection und DoS Settings prüfen.

Threat Feeds für WAF und DNAT

Threat Feeds ergänzen Schutz nur im gesicherten Modul und Traffic-Pfad. Ab SFOS 22 ist für eingehenden, weitergeleiteten DNAT-/WAF-Traffic der Abgleich der Quell-IPv4 mit MDR-, NDR- und Third-Party Threat Feeds dokumentiert. Für lokale Dienste wie das VPN Portal ist der gesicherte Zusatzschutz der Quell-IPv4-Abgleich mit unterstützten Third-Party Feeds; dieser Pfad läuft nicht durch eine Transit-Firewall-Regel. Domain-/URL-Indikatoren betreffen dagegen passende ausgehende Zielabgleiche, nicht die Quell-IP eines eingehenden Logins. Dafür müssen DNS-/IPS-/Application-Classification- beziehungsweise Web-/TLS-Inspektionspfad passen; vollständige HTTPS-URL-Pfade benötigen Entschlüsselung. IPv6-Quellen sind von diesem Feed-Schutz nicht erfasst.

Offene X-Ops-Grenze: Die ATR-Beschreibung und SVG-Traffic-Matrix widersprechen sich bei bestimmten X-Ops-Matchrichtungen, insbesondere Zielabgleich und lokalem Quellabgleich bei ausgehendem Traffic. Aussagen zu MDR, NDR oder Third-Party Feeds dürfen deshalb nicht auf Sophos X-Ops übertragen werden, auch nicht für DNAT/WAF oder lokale Portale. Bis zur belastbaren Klärung nicht auf strittige Feed-Wirkungen bauen: restriktive ACLs, Firewall-/WAF-Regeln, Patching und MFA bleiben unabhängig erforderlich. Nur freigegeben und kontrolliert Modul, Richtung, Logs und tatsächliche Wirkung prüfen. Die Grenze wird in MDR Threat Feeds und der unten verlinkten NDR-Anleitung weiter eingeordnet.

Monitor erkennt und protokolliert Treffer, blockiert aber nicht; Block muss für den geprüften Pfad eingerichtet sein. Ein Feed-Treffer allein belegt weder Blockierung noch vollständiges Logging. Das relevante ATR-/Firewall-/WAF-Log und die tatsächliche Verbindung gemeinsam prüfen; Allowlist, False Positives und Zuständigkeit bleiben nötig. Die folgenden Beispiele gelten nur innerhalb dieser Modul-/Pfadgrenzen.

Besonders wertvoll sind Threat Feeds bei:

• öffentlichen Webservern hinter WAF oder DNAT,
• RDP-, SSH- oder Admin-Zugängen, die noch nicht vollständig durch ZTNA ersetzt wurden,
• VPN- und Portalzugriffen mit viel Internetrauschen,
• Umgebungen, in denen Länder-Blocking allein zu grob ist,
• Kunden, die neben Sophos X-Ops auch kuratierte Drittanbieter-Feeds nutzen möchten.

Wichtig ist der Betrieb: Feed-Qualität, Action Monitor oder Block, Allowlist, False Positives, Logging und Zuständigkeit müssen geklärt sein. Die Konfiguration ist in Sophos Firewall Threat Feeds einrichten und sicher betreiben beschrieben. Für kuratierte Feeds kann Cybora ein sinnvoller Baustein sein, besonders wenn veröffentlichte Dienste konsequent gegen bekannte schlechte Quellen geschützt werden sollen.

Web, DNS, TLS und Zero-Day Protection

Web Protection, DNS Protection, TLS Inspection und Zero-Day Protection erhöhen die Sichtbarkeit und Blockierwirkung, brauchen aber saubere Planung. TLS Inspection sollte nicht als Alles-oder-nichts-Projekt gestartet werden. DNS Protection muss zu den verwendeten DNS-Pfaden passen. Zero-Day Protection hilft nur, wenn die betroffenen Dateitypen und Policies sinnvoll eingebunden sind.

Passende Detailartikel sind Sophos Firewall Web Protection mit Web Policies einrichten, Sophos DNS Protection mit Sophos Firewall einrichten, Sophos Firewall TLS Inspection richtig einführen und Sophos Firewall Zero-Day Protection verstehen und betreiben.

Erkennung, Logging und Review

Hardening ist kein einmaliger Projektpunkt. Regeln, Benutzer, Portale, NAT-Ausnahmen und Firmwarestände verändern sich. Deshalb braucht es regelmässige Reviews und Logs, die nicht erst nach einem Vorfall gesucht werden.

Health Check als Einstieg

Der Sophos Firewall Health Check ist ein guter Startpunkt, weil er riskante Konfigurationen sichtbar macht. Findings sollten nicht blind abgearbeitet werden, sondern nach Risiko, Betriebswirkung und lokaler Architektur bewertet werden.

In SFOS 22 öffnet man dazu im Control Center das Widget Firewall health check oder geht zu Monitor & analyze > Firewall health check. Die Daten werden aktualisiert, sobald sich eine überwachte Konfiguration ändert. Wichtig: Ein Finding lässt sich manuell auf compliant setzen, ohne die Ursache zu beheben. Für die Validierung zählt deshalb die erfüllte Policy-Anforderung und nicht nur der angezeigte Status.

Gute Zeitpunkte für einen Health Check:

• nach dem initialen Setup,
• nach Migrationen,
• vor und nach Firmware-Upgrades,
• nach grösseren Regeländerungen,
• vor Audits,
• quartalsweise im Betrieb.

Telemetrie und Sophos Assistant getrennt bewerten

Unter Administration > Admin and user settings steuert Sophos Adaptive Learning, welche Nutzungs- und Bedrohungsdaten die Firewall an Sophos sendet. Dazu gehören unklassifizierte Anwendungen, Daten zu IPS-Alerts, erkannten Viren, Spam und Active-Threat-Response-Funden. Zusätzlich ist die grundlegende Konfigurations- und Nutzungsberichterstattung standardmässig aktiv: Das Gerät übermittelt regelmässig Konfigurations-, Funktions-, Fehler- und Auslastungsdaten per HTTPS. Sophos gibt an, dabei keine benutzerspezifischen oder personalisierten Informationen zu erfassen. Trotzdem sollte der Entscheid nach Datenschutzvorgaben und Betriebsmodell bewusst dokumentiert werden, statt die Option mit einer Schutzfunktion für den lokalen Traffic zu verwechseln.

Turn on Sophos Assistant betrifft dagegen nur Hilfetexte, Smart Tips und Konfigurationsanleitungen im WebAdmin. Nach einer Änderung muss man sich ab- und wieder anmelden. Das Abschalten des Assistenten reduziert weder die Netzwerk-Angriffsfläche noch automatisch die Telemetrie; beide Einstellungen sind getrennt zu beurteilen.

Logging, Alerts und SIEM

Firewall-Regeln ohne Logging sind bei Fehlersuche und Incident Response oft wertlos. Die dokumentierte Baseline ist zentrale Berichterstattung in Sophos Fusion (ehemals Sophos Central) plus eine ausgewählte SIEM-Lösung. Man legt Ereignisklassen, Empfänger, verantwortlichen Owner, Aufbewahrungsdauer und Überwachung mit Reaktionsweg fest. Eine Architekturabweichung ist ausdrücklich zu dokumentieren und muss einen gleichwertigen, unabhängig von der Firewall aufbewahrten und überwachten Pfad bereitstellen; nicht jede Architektur braucht doppelte Ziele. Regelmässige lokale Log-Viewer-Prüfung allein genügt nicht. MDR, XDR und NDR sind keine austauschbaren Logarchive. Mit einem freigegebenen, unkritischen Testereignis die Zustellung an jedes vorgesehene Ziel, die Suche im gespeicherten Log und den Überwachungs-/Alarmweg prüfen. Bei fehlender Zustellung Ereignisauswahl, Verbindung und Empfänger korrigieren und erneut testen. Aufbewahrung und Berechtigungen zusätzlich am Ziel kontrollieren.

Zusätzlich werden unter System services > Notification list die benötigten Systemereignisse für E-Mail oder SNMP ausgewählt. Dafür müssen zuvor das Mailziel unter Administration > Notification settings beziehungsweise SNMP-Agent und Community oder Benutzer unter Administration > SNMP eingerichtet sein. Nach Save sollte ein kontrolliert auslösbares, unkritisches Ereignis den vorgesehenen Empfänger erreichen; andernfalls zuerst Ziel, Erreichbarkeit und ausgewählte Ereignisklasse prüfen.

Die technische Einrichtung von Syslog beschreibt Sophos Firewall Syslog sicher an SIEM senden. Für zentrale Reports passt Sophos Firewall Central Reporting aktivieren und betreiben. Wenn NDR und Active Threat Response relevant sind, hilft Sophos Firewall NDR und Active Threat Response betreiben.

Änderungen validieren und sicher zurückrollen

Hardening sollte in kleinen, nachvollziehbaren Schritten erfolgen. Vor jedem Block hält man den aktuellen Wert, den verantwortlichen Owner und den vorgesehenen Rückweg fest. Danach ändert man nur einen Bereich, etwa Device Access, eine Firewall-Regel oder eine Threat-Feed-Aktion. Man prüft sowohl den erlaubten Sollpfad als auch einen absichtlich nicht erlaubten Pfad und kontrolliert die passenden Logs. Erst dann folgt der nächste Bereich.

Für den Rückweg wird nur die zuletzt geänderte Einstellung auf den dokumentierten Ausgangswert gesetzt. Bei Device Access bleiben dafür die bestehende Admin-Sitzung und ein zuvor getesteter unabhängiger Managementweg verfügbar. Bei Regeln wird die bisherige Regel nicht gelöscht, bevor die engere Variante erfolgreich geprüft ist. Bei Threat Feeds beginnt man mit Monitor, prüft Treffer und mögliche False Positives und wechselt erst dann zu Block; verursacht die Umstellung Probleme, geht man auf Monitor zurück und ergänzt nur belegte Ausnahmen. Ein vollständiger Backup-Restore ist kein bequemer Undo-Schalter, sondern der Recovery-Weg für grössere Fehlerlagen.

Kompakte Hardening-Checkliste

Für einen ersten Review reicht diese Reihenfolge:

1. WAN-Zugriff auf WebAdmin und SSH begrenzen, User Portal deaktiviert lassen und benötigte VPN-Portal-Erreichbarkeit für Downloads und SSO erhalten und testen.
2. MFA für Admins und Remote Access aktivieren.
3. Lokale Admin-Konten, Rollen und Passwortrichtlinien bereinigen.
4. Firmware, Hotfixes, Pattern-Updates und Supportstatus prüfen.
5. Backup, SSMK, Restore-Pfad und Recovery-Test dokumentieren.
6. DNAT-, WAF- und VPN-Veröffentlichungen auf Notwendigkeit prüfen; VPN-Gruppen/Ressourcen begrenzen, Open group nicht autorisieren und erlaubte sowie abgewiesene Zugriffe testen.
7. Regeln mit Any, fehlendem Logging oder unklarem Owner bereinigen.
8. IPS, Spoof Protection, DoS Settings und Threat Feeds gezielt aktivieren.
9. Web-, DNS-, TLS- und Zero-Day-Policies stufenweise einführen.
10. Health Check, unabhängig aufbewahrte und überwachte Logs, Zustelltests, Alerts und regelmässige Reviews mit Owner und Aufbewahrungsdauer etablieren.

Häufige Fehler

WAN-Zugriff bleibt aus Bequemlichkeit offen

Ein WebAdmin- oder SSH-Zugang wird für einen Supportfall geöffnet und danach vergessen. Genau solche temporären Ausnahmen sollten mit Ablaufdatum, Owner und Nachkontrolle dokumentiert werden.

Threat Feeds werden ohne Betriebskonzept aktiviert

Threat Feeds sind stark, aber nicht wartungsfrei. Ohne Monitoring, Allowlist und False-Positive-Prozess kann ein legitimer Partner, Dienstleister oder Cloud-Dienst blockiert werden. Deshalb zuerst mit Monitor oder begrenztem Scope testen, dann sauber auf Block wechseln.

Logging fehlt bei kritischen Regeln

Wenn eine öffentliche DNAT-Regel, WAF-Regel oder VPN-Regel kein Logging hat, sieht man im Vorfall zu wenig. Mindestens sicherheitsrelevante Eingänge, Admin-Zugriffe, Deny-Regeln und kritische Segmentübergänge sollten nachvollziehbar sein.

Health Check wird als einmalige Aufgabe betrachtet

Ein guter Score nach dem Setup ist kein dauerhafter Zustand. Neue Regeln, neue VPN-Benutzer, temporäre Ausnahmen und Firmwareänderungen können die Lage verändern. Hardening braucht einen Review-Rhythmus.

FAQ