Sophos Firewall Health Check correct gebruiken

De Sophos Firewall Health Check is een geïntegreerde controle van de firewall-configuratie. Het toont in het Control Center of belangrijke instellingen voldoen aan de aanbevolen veiligheids- en best practice-richtlijnen. Voor beheerders is dit bijzonder nuttig omdat risicovolle configuraties zichtbaar worden voordat ze een veiligheids- of operationeel probleem veroorzaken.

Voor de bredere hardening-context past de hub Sophos Firewall Hardening: best practices voor een veilige configuratie.

De Health Check werd geïntroduceerd met Sophos Firewall v22. De functie beoordeelt configuraties onder andere tegen best practices en standaarden zoals CIS-benchmarks. Met SFOS 22.0 MR1 werd ook de onderliggende CIS-context bijgewerkt.

Videohandleiding

Deze gids gebruiken

De Health Check geeft een lijst, maar neemt geen beslissing. Daarom voegt deze gids een Avanet-beoordeling toe:

• Hoge prioriteit: fundamentele beveiligings- of beheercontrole; oplossen of zeer goed motiveren.
• Contextafhankelijk: nuttig, maar niet voor elke regel, verkeersstroom of architectuur.
• Anders afgedekt: het beveiligingsdoel wordt al bereikt met een gelijkwaardige controle van een andere leverancier of met een ander operationeel proces. Een gedocumenteerde override kan dan correct zijn.
• Optioneel: compliancefunctie of aanvullende Sophos-dienst; een rode status betekent niet automatisch dat de firewall onveilig is.

Deze indeling vervangt geen risicoanalyse. Ze voorkomt dat een lage Sophos-ernst een belangrijk back-uppunt bagatelliseert of dat een optionele integratie te snel een aankoopproject wordt.

Waarvoor de Health Check bedoeld is

De Health Check is geen klassieke systeemstatus en geen hardware-sensor. Hij controleert niet of een voeding defect is of een SSD binnenkort uitvalt. Daarvoor zijn andere operationele controles geschikt, zoals SSD-gezondheid controleren of HA- en hardwaremonitoring.

De Health Check beantwoordt eerder deze vragen:

• Zijn administratieve toegangen te breed geopend?
• Is MFA voor kritieke logins geactiveerd?
• Zijn firewall-regels te open opgesteld?
• Zijn back-ups, hotfixes, logging of Central-functies goed voorbereid?
• Wijkt de configuratie af van aanbevolen veiligheidsstandaarden?
• Zijn er bevindingen die voor een audit of go-live moeten worden opgelost?

Het is daarmee een goed hulpmiddel voor versterking, beoordeling en wijzigingscontrole. Het vervangt echter geen goede architectuur, geen documentatie van regels en geen handmatige beoordeling.

⚠️ Een groene Health Check betekent niet automatisch dat de firewall veilig is gepland. Het toont aan of bepaalde controleerbare instellingen kloppen. Netwerkontwerp, bedrijfslogica, uitzonderingen, gebruikersgroepen en bedrijfsprocessen moeten nog steeds professioneel worden beoordeeld.

Score en status correct beoordelen

De Health Check is nuttig, maar geen vendor-neutrale security audit. Hij beloont ook het gebruik van Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds en Synchronized Security. Vanuit Avanet gezien bevat dit duidelijke cross-selling: Noncompliant kan een echte tekortkoming betekenen, zoals WebAdmin zonder MFA op internet, maar ook alleen dat een optionele Sophos-dienst niet wordt gebruikt terwijl Microsoft Defender, een andere EDR/NDR, een SIEM of DNS-filter het doel al afdekt.

Avanet-aanbeveling: beoordeel elke bevinding, maar voer niet alles zonder afweging uit. Een rode bevinding over WebAdmin, MFA, onversleutelde authenticatie, back-ups of open regels verdient veel aandacht. Een rode bevinding over een niet-gelicentieerde Sophos-dienst is in eerste instantie een architectuur- en productbeslissing, geen automatisch bewezen beveiligingslek. Het beveiligingsdoel, bestaande alternatieven en het beheerproces bepalen of activeren, anders afdekken of gemotiveerd overrulen de juiste keuze is.

Daarom moet men niet elke aanbeveling alleen activeren om de weergave groen te maken. Een voorbeeld is de Login disclaimer: in audit- of compliance-omgevingen kan een login-melding vereist zijn. In veel normale bedrijfsomgevingen veroorzaakt het echter vooral een extra klik bij elke login en biedt het praktisch geen technische veiligheidswinst. Als daardoor alleen de Health-Check-score stijgt, is de meerwaarde beperkt.

Vraag bij zulke functies welk risico ze verminderen, of al een gelijkwaardige controle bestaat, welke licentie en gegevensoverdracht nodig zijn en wie alerts, uitzonderingen en false positives behandelt. Zonder duidelijke antwoorden is een gedocumenteerde override vaak eerlijker dan een ongebruikte functie alleen voor de score.

Behandel NDR Essentials en MDR niet als hetzelfde. NDR Essentials analyseert geselecteerd firewallverkeer en levert detecties. Sophos MDR staat voor Managed Detection and Response en is een aanvullende betaalde dienst met analisten en incidentprocessen. MDR threat feeds zijn alleen zinvol wanneer deze dienst daadwerkelijk is gelicentieerd en operationeel is geïntegreerd. Een NDR-bevinding betekent dus niet automatisch dat MDR moet worden aangeschaft.

Als vuistregel:

• Internetblootgestelde beheerstoegangen, MFA, hotfixes, back-ups, wachtwoordregels en IPS zijn meestal echte veiligheids- of bedrijfsbasisprincipes. Deze punten moeten zeer serieus worden genomen.
• Logging, rapportage, meldingen en NTP zijn belangrijk voor beheer en traceerbaarheid. De concrete weg hangt echter af van het bedrijfsmodel.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central en Synchronized Security zijn mogelijke oplossingen, geen universele verplichtingen. Een effectieve bestaande controle telt meer dan het Sophos-logo.
• Login disclaimer is meestal eerder een compliance-/meldingsfunctie dan een technische beschermingsmaatregel. Alleen activeren als het echt vereist of gewenst is.

Snelle beslissing: wat moet men echt implementeren?

Bij de eerste Health Check kunnen de bevindingen in vier werkgroepen worden ingedeeld:

• Direct controleren en normaal oplossen: 8, 9, 11, 13-20, 22, 25, 28 en 31. Dit omvat hotfixstatus, loginbeveiliging, adminwachtwoorden, MFA, versleutelde authenticatie, SSH, WAN-blootstelling, pattern updates, IPS, brede regels en correcte tijd.
• Zeer belangrijk, ook als Sophos Low of Medium aangeeft: 16 en 21. Back-ups vereisen een geteste restore. Alerts vereisen een werkend pad via e-mail, monitoring, Central of SIEM.
• Per verkeerspad en architectuur beslissen: 3, 5, 10 en 23-27. X-Ops, Heartbeat, wachtwoordregels voor gebruikers, Web Policy, Zero-Day Protection, Application Control en TLS Inspection zijn niet op elke regel even nuttig.
• Alleen activeren met het passende Sophos-ecosysteem of een bewuste cloudkeuze: 1, 2, 4, 6, 12, 29 en 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection en Central-functies zijn geen universele minimumeisen. Punt 7, Login disclaimer, is vooral een compliancebeslissing.

Deze indeling is bewust directer dan de Sophos-ernst. Ze beoordeelt wat in de werkelijke omgeving eerst risico vermindert, niet wat Sophos kan verkopen of technisch integreren.

Health Check openen

De Health-Check-status verschijnt in het Control center. De detailweergave is ook te vinden via het hoofdmenu:

Monitor & analyze > Firewall health check

Daar ziet men het aantal gecontroleerde configuraties, de conforme punten en de niet-conforme punten. Sophos toont niet-conforme vermeldingen naar ernst. De gegevens worden bijgewerkt wanneer een bewaakte configuratie verandert. Hierdoor is de Health Check ook geschikt voor een directe opvolging na wijzigingen.

Voor de beoordeling moet men niet alleen de algehele status noteren. Belangrijker zijn de concrete bevindingen, de risicocontext en de geplande maatregel. Een enkele kritische bevinding over de WAN-bereikbaarheid van de WebAdmin is in de praktijk belangrijker dan meerdere lage bevindingen zonder internetblootstelling.

Status, ernst en override begrijpen

De detailweergave toont per controle of de configuratie compliant, noncompliant of handmatig overschreven is. Voor beheer zijn deze drie toestanden belangrijker dan alleen het percentage.

• Compliant: de gecontroleerde configuratie voldoet aan de betreffende policy. Na grotere wijzigingen moet dit toch technisch worden gevalideerd.
• Noncompliant: de gecontroleerde configuratie voldoet niet aan de policy. Risico, blootstelling en uitvoerbaarheid moeten worden beoordeeld.
• Manual policy status override: de configuratie voldoet niet aan de policy, maar is handmatig als compliant gemarkeerd. Deze status hoort alleen gebruikt te worden met reden, owner en herbeoordelingsdatum.

Onder Action biedt de weergave afhankelijk van de bevinding directe werkstappen. Fix now leidt naar de passende configuratiepagina, Override status zet een niet-conform punt handmatig op compliant en Undo override maakt zo’n overschrijving ongedaan. Dat is praktisch, maar vervangt geen beoordeling: de Health Check weet niet automatisch of een controle elders echt gelijkwaardig is uitgevoerd.

De ernst helpt bij het sorteren, maar vervangt geen inhoudelijke beoordeling. Het is een statische Sophos-waardering zonder kennis van blootstelling of compenserende controles. Een Low-bevinding voor ontbrekende back-ups kan urgenter zijn dan een Medium-bevinding voor een ongebruikte Sophos-dienst.

Controleer bij een onlogische bevinding ook de firmwareversie en bekende fouten. SFOS 22.0 MR1 corrigeerde onjuiste Doesn't comply-resultaten voor firewall-regels en voor NDR Essentials op virtuele firewalls. Een duidelijk foutieve status is dus geen reden voor een riskante configuratiewijziging of een overhaaste override.

De zoek- en sorteerfuncties van de Health Check-tabel helpen om bevindingen te groeperen op policy, module, standaard of ernst. Voor grotere firewalls is dat praktischer dan alleen naar de dashboardtegel kijken.

Elke Health-Check-controle afzonderlijk beoordeeld

De lijst is gebaseerd op de 31 controles in de Engelse Health-Check-weergave die voor deze beoordeling is gebruikt. Sophos kan aantal, naam, standaard of ernst met een firmware-update wijzigen. Als de lokale firewall extra of anders benoemde bevindingen toont, is die weergave bepalend. De status is niet vermeld omdat deze per firewall verschilt. Belangrijker is wat elke controle betekent en hoe men die beoordeelt.

Active Threat Response en Advanced Security

• 1. Synchronized Application Control moet geactiveerd zijn. Standaard: Recommended, Ernst: Medium. De functie identificeert toepassingen nauwkeuriger via Sophos Endpoint en vereist Security Heartbeat; bij het eerste gebruik moet zij ook in Sophos Central worden ingeschakeld. Avanet-beoordeling: optioneel. Alleen activeren met compatibele Sophos-endpoints en wanneer gedetecteerde toepassingen later worden geclassificeerd en via Application Filter worden gebruikt. Met Microsoft Defender of een ander endpointproduct is een gemotiveerde override nuttiger dan een activering zonder effect.
• 2. NDR Essentials moet geactiveerd zijn en ten minste één interface bewaken. Standaard: Recommended, Ernst: Medium. De firewall analyseert geselecteerd verkeer via de Sophos NDR-clouddienst, detecteert IoC’s en logt ze, maar blokkeert ze niet automatisch. Alleen bepaalde interfaces in LAN-, DMZ- en Custom-zones worden ondersteund; WAN, Wi-Fi en verschillende interfacetypen, zoals RED en XFRM, zijn uitgesloten. Active-Active HA wordt niet ondersteund. Ook moeten Active Threat Response-logs actief zijn en moeten, afhankelijk van het IoC-type, firewall-, DNS-, IPS- of decryptioncontroles van toepassing zijn. Avanet-beoordeling: contextafhankelijk of optioneel. Alleen activeren wanneer licentie, cloudanalyse, privacy, geschikte interfaces en alert-eigenaarschap zijn geregeld. Vervang een bestaand NDR niet alleen om de Health Check groen te maken.
• 3. Sophos X-Ops moet geactiveerd zijn, actie Log and drop. Standaard: CIS, Ernst: High. Veiligheidsrelevant als Threat Feeds actief worden gebruikt. False positives en logging moeten worden gecontroleerd.
• 4. MDR threat feeds moeten geactiveerd zijn, actie Log and drop. Standaard: Recommended, Ernst: High. Dit vereist Sophos MDR, registratie in Sophos Central en passende licenties. Avanet-beoordeling: optioneel. Zonder MDR-contract is dit geen configuratiefout, maar een product- en dienstaanbeveling.
• 5. Synchronized Security Heartbeat moet in een firewall-regel worden gebruikt. Standaard: CIS, Ernst: Medium. Avanet-beoordeling: contextafhankelijk. Zeer nuttig met Sophos Endpoint, maar niet passend bij Microsoft Defender of een andere EDR. Een pilot is essentieel: apparaten die nog nooit een heartbeat hebben verzonden, kunnen afhankelijk van de regel toch toegang krijgen. De opties Block clients with no heartbeat en Block request to destination with no heartbeat dwingen het gewenste gedrag voor deze apparaten af.
• 6. Security Heartbeat moet geactiveerd zijn. Standaard: CIS, Ernst: High. Belangrijk als Sophos Endpoint wordt gebruikt. Anders moet eerst het Endpoint-ontwerp worden verduidelijkt.
• 12. DNS Protection moet geconfigureerd en actief zijn. Standaard: Recommended, Ernst: Medium. Voor de status Active zijn de passende licentie, de DNS Protection-resolvers op de firewall en het openbare IP-adres van de firewall als Location in Sophos Central nodig. Avanet-beoordeling: optioneel. Alleen activeren wanneer de dienst bewust als DNS-beveiligingslaag wordt beheerd en de logs worden beoordeeld. Andere DNS-filters kunnen hetzelfde doel afdekken zonder dat de Sophos Health Check dit als compliant markeert.

Admin, authenticatie en Device Access

• 7. Login disclaimer moet geactiveerd zijn. Standaard: CIS, Ernst: Medium. Compliance-onderwerp. Technisch weinig beschermingswaarde, maar veroorzaakt een extra klik bij het inloggen.
• 8. Hotfix setting moet geactiveerd zijn. Standaard: CIS, Ernst: High. Avanet-beoordeling: hoge prioriteit. In actuele SFOS 22-versies staat onder Backup & firmware > Firmware geen apart Hotfix-blok meer. Sophos installeert hotfixes standaard automatisch; controleer de status zo nodig met system hotfix show in Device Console. Een ontbrekend selectievakje is geen bevinding.
• 9. Inactieve sessies moeten worden beëindigd en logins na mislukte pogingen geblokkeerd. Standaard: CIS, Ernst: High. Duidelijke login-versterking. Vooral belangrijk bij blootgestelde portalen en beheertoegangen.
• 10. Wachtwoordcomplexiteit moet voor gebruikers zijn geconfigureerd. Standaard: CIS, Ernst: High. Zinvol, vooral bij lokale gebruikers en portalen. Bij externe IdP ook het wachtwoord- en MFA-beleid daarvan controleren.
• 11. Wachtwoordcomplexiteit moet voor beheerders zijn geconfigureerd. Standaard: CIS, Ernst: High. Basisversterking. Nog belangrijker zijn individuele beheerders, MFA en beperkte toegang.
• 13. MFA moet voor Remote Access VPN-logins actief zijn. Standaard: CIS, Ernst: High. Zeer belangrijk voor SSL VPN en IPsec Remote Access. Uitrol plannen met fallback-beheerder en testgebruikers.
• 14. MFA moet voor WebAdmin Console en VPN Portal actief zijn. Standaard: CIS, Ernst: High. Zeer belangrijk, vooral als portalen vanuit minder sterk gecontroleerde netwerken bereikbaar zijn.
• 15. Verbindingen met authenticatieservers moeten versleuteld zijn. Standaard: CIS, Ernst: Medium. Belangrijk bij AD/LDAP/RADIUS-koppelingen. Onversleutelde authenticatie vermijden.
• 17. Public-Key-authenticatie moet voor SSH geactiveerd zijn. Standaard: Recommended, Ernst: High. Zeer zinvol. Daarnaast SSH alleen uit vertrouwde netwerken toestaan.
• 18. User Portal moet niet vanuit de WAN-zone bereikbaar zijn. Standaard: Recommended, Ernst: High. In veel omgevingen juist. Als WAN-toegang nodig is, sterk beperken en MFA gebruiken.
• 19. WebAdmin Console moet niet vanuit de WAN-zone bereikbaar zijn. Standaard: CIS, Ernst: High. Een van de belangrijkste punten. WebAdmin nooit breed op het internet openen.
• 20. MFA moet voor de standaardbeheerder geconfigureerd zijn. Standaard: CIS, Ernst: High. Belangrijk, maar beter is daarnaast een schoon beheerproces met persoonlijke beheerdersaccounts.

Back-ups, updates, regels en inspection

• 16. Back-ups moeten op de firewall of in Sophos Central gepland zijn. Standaard: CIS, Ernst: Low. Lage ernst, maar in geval van nood extreem belangrijk. Herstelproces ook testen.
• 21. Notificatie-e-mails moeten voor systeem- en beveiligingsevenementen geconfigureerd zijn. Standaard: CIS, Ernst: Low. Sophos Firewall kan meldingen per e-mail en SNMP verzenden; de gewenste gebeurtenissen worden geselecteerd onder System services > Notification list. Avanet-beoordeling: contextafhankelijk. Een betrouwbaar en getest alarmeringspad is doorslaggevend. Als Syslog, SIEM, monitoring of Central Alerts betrouwbaar worden beheerd, is e-mail niet verplicht. Een geconfigureerde SMTP-server zonder geselecteerde gebeurtenissen en bezorgtest is nog geen alarmeringsproces.
• 22. Automatische patroonupdates moeten geactiveerd zijn. Standaard: CIS, Ernst: High. Avanet-beoordeling: hoge prioriteit. Zonder actuele patronen verliezen verschillende beschermingsfuncties effectiviteit. Updates zijn standaard automatisch actief, maar de status en laatste geslaagde update moeten toch worden gecontroleerd. Firmware voor Access Points en RED-apparaten wordt alleen gedownload en apart geïnstalleerd omdat een herstart nodig is. In Air-Gap-omgevingen is een handmatig patroon- en licentieproces nodig.
• 23. Een webbeleid moet in een firewall-regel geselecteerd zijn. Standaard: Recommended, Ernst: Medium. Zinvol voor gebruikers-webverkeer. Niet blind toepassen op server-naar-server- of speciaal verkeer.
• 24. Zero-day bescherming moet in een firewall-regel geselecteerd zijn. Standaard: CIS, Ernst: High. Zinvol voor passende web- en downloadpaden. Licentie, prestaties en false positives in acht nemen.
• 25. IPS moet geactiveerd zijn en een IPS-beleid moet in een firewall-regel geselecteerd zijn. Standaard: CIS, Ernst: High. Zeer belangrijk beschermingspunt. IPS moet echter per verkeerspad passend worden gekozen en gelogd.
• 26. Een Application-Control-beleid moet in een firewall-regel geselecteerd zijn. Standaard: CIS, Ernst: Medium. Zinvol voor client-internetregels. Bij kritisch verkeer eerst testen.
• 27. Een SSL/TLS Inspection Rule moet actie Decrypt gebruiken. Standaard: CIS, Ernst: High. Niet blind activeren. TLS Inspection vereist CA-distributie, uitzonderingen, pilotfase en probleemoplossingsproces.
• 28. Een Allow-regel moet niet overal Any bij netwerk- en servicevelden gebruiken. Standaard: CIS, Ernst: Medium. Zeer belangrijk voor regelhygiëne. Any kan bewust nodig zijn, maar moet dan worden verantwoord en gelogd.

Sophos Central en tijd

• 29. Sophos Central Reporting moet geactiveerd zijn. Standaard: Recommended, Ernst: Medium. Nuttig voor rapportage en langere evaluaties. Niet verplicht als Syslog/SIEM goed wordt beheerd.
• 30. De firewall moet voor Sophos Central Management geregistreerd en Central Management geactiveerd zijn. Standaard: Recommended, Ernst: Medium. Praktisch voor centraal beheer, back-ups en rapportage. Niet elke omgeving wil of heeft cloudbeheer nodig.
• 31. Een NTP-server moet geconfigureerd zijn. Standaard: CIS, Ernst: Low. Basisvereiste. Zonder correcte tijd lijden logs, certificaten, authenticatie en probleemoplossing.

Bevindingen prioriteren en uitvoeren

Niet elke bevinding heeft in elke omgeving dezelfde betekenis. Een goede beoordeling sorteert de vermeldingen daarom niet alleen op technische ernst, maar ook op blootstelling en operationeel risico.

Deze volgorde heeft zich bewezen:

1. Internetblootgestelde beheer- en portaltoegangen controleren.
2. MFA en login-veiligheid voor beheerders, VPN Portal, User Portal en Remote Access controleren.
3. Firewall-regels met te brede bronnen, doelen of services opruimen.
4. Logging, back-ups en hotfixes controleren.
5. Beschermingsfuncties per regel controleren, zoals IPS, webbeleid, Application Control, TLS Inspection of Zero-Day Protection.
6. Central, rapportage of NDR-bevindingen daarna beoordelen of de functie in de omgeving echt wordt gebruikt en beheerd.

De volgorde is pragmatisch: eerst de zaken die direct op het internet zichtbaar zijn of toegang tot de firewall toestaan. Daarna regelhygiëne en beschermingsfuncties. Daarna operationele en ecosysteemonderwerpen.

Typische bevindingen en passende maatregelen

WebAdmin, User Portal of VPN Portal is te breed toegankelijk

Als administratieve of gebruikersportalen vanuit te veel zones toegankelijk zijn, neemt het risico toe door scans, brute-force pogingen en credential stuffing. Het belangrijkste artikel hierover is Sophos Firewall-toegang beveiligen: Device Access correct configureren.

Voor productieve omgevingen moet men controleren:

• Is WebAdmin vanuit de WAN-zone echt nodig?
• Is er een Local Service ACL Exception Rule voor management-IP of beheernetwerk?
• Is SSH alleen vanuit vertrouwde netwerken toegestaan?
• Zijn User Portal en VPN Portal alleen daar bereikbaar waar ze nodig zijn?

MFA ontbreekt of is niet consequent geactiveerd

MFA hoort minimaal op administratieve toegangen en Remote Access. Als de Health Check MFA-bevindingen toont, moet men niet blind voor alle gebruikers tegelijk overschakelen. Beter is een gecontroleerde uitrol met testgebruiker, fallback-beheerder en een goed tokenproces.

De praktische handleiding staat in MFA voor Sophos Firewall WebAdmin, VPN Portal en Remote Access activeren.

Firewall-regels zijn te open

Zeer brede regels met Any bij bron, doel of service zijn vaak historisch gegroeid. Niet elke brede regel is automatisch fout, maar elke moet worden verantwoord.

Voor de opruiming zijn deze vragen nuttig:

• Welke zone mag echt op welke zone toegang hebben?
• Zijn doelnetwerken of services te beperken?
• Is logging actief, zodat treffers zichtbaar worden?
• Zijn er oude testregels of tijdelijke uitzonderingen?
• Kan de regel in meerdere begrijpelijkere regels worden opgesplitst?

De basisprincipes staan in Sophos Firewall-regels begrijpen en correct configureren. Als onduidelijk is welke regel van toepassing is, helpt Firewall-regel testen met Log Viewer, Policy Test en Packet Capture.

Back-ups, hotfixes en updateproces ontbreken

Een Health Check kan wijzen op ontbrekende back-ups of update-/hotfix-onderwerpen. Deze punten lijken minder spectaculair dan portalblootstelling, maar zijn in geval van nood cruciaal.

Voor grotere wijzigingen moet men een back-up maken en weten hoe een herstel werkt. De procedure is beschreven in Sophos Firewall Backup maken of herstellen. Voor firmware-onderwerpen past Sophos Firewall Firmware Update - Voorbereiding en Best Practices.

Logging en rapportage zijn onvolledig

Als logs ontbreken, is de operatie blind. De Health Check kan aanwijzingen geven over logging- of rapportageonderwerpen, maar de eigenlijke beslissing hangt af van het bedrijfsmodel.

Voor lokale analyse zijn Log Viewer, service-logs en Packet Capture relevant. Voor langere bewaring is Central Firewall Reporting of Syslog/SIEM nodig. Als niet afzonderlijke logevents, maar verkeersstromen, bandbreedtepiekken of opvallende communicatiepatronen moeten worden onderzocht, past daarnaast sFlow Monitoring. De lokale basisprincipes staan in Sophos Firewall Troubleshooting: Services en Logs.

Beschermingsfuncties zijn niet in regels actief

Een veelvoorkomend punt zijn regels zonder IPS, webbeleid, Application Control, TLS Inspection of Zero-Day Protection. Hier moet men niet alles blind activeren, maar het verkeerspad begrijpen.

Voorbeelden:

• Gebruikers-webverkeer vereist andere controles dan server-naar-server-verkeer.
• TLS Inspection moet gepland worden ingevoerd, omdat het applicaties kan verstoren.
• IPS en Application Control vereisen logging en een beoordelingsroutine.
• NDR- of Threat-Feed-functies helpen alleen als bevindingen later ook worden geëvalueerd.

Voor TLS Inspection past Sophos Firewall TLS Inspection correct invoeren. Voor Threat Feeds past Sophos Firewall Threat Feeds.

Review documenteren en opnieuw controleren

Sophos Firewall staat toe om de status van afzonderlijke controles handmatig te overschrijven. Dit kan zinvol zijn als een aanbeveling in de eigen omgeving bewust niet wordt uitgevoerd.

Overrides moeten echter niet als opruimfunctie worden misverstaan. Als een punt wordt overschreven, moet worden gedocumenteerd:

• Waarom is de aanbeveling niet passend?
• Wie heeft de beslissing goedgekeurd?
• Geldt de uitzondering permanent of slechts tijdelijk?
• Wanneer wordt deze opnieuw beoordeeld?
• Is er een compenserende maatregel?

⚠️ Een override is geen oplossing. Het is een bewuste risicoacceptatie of een gedocumenteerde uitzondering. Zonder reden verzwakt een override de waarde van de Health Check.

Resultaat correct documenteren

Een Health-Check-beoordeling moet een traceerbaar resultaat opleveren. Anders ziet men wel kort een dashboard, maar weet men later niet meer welke beslissing is genomen en welke punten nog openstaan.

Voor kleine omgevingen volstaat vaak een eenvoudige tabel:

• Datum: Wanneer is de Health Check gecontroleerd?
• Firmware: Op welke SFOS-versie is beoordeeld?
• Bevinding: Welke niet-conforme punt is gemeld?
• Risico: Waarom is het punt in deze omgeving relevant of minder relevant?
• Maatregel: Wat wordt gewijzigd, getest of bewust geaccepteerd?
• Verantwoordelijke: Wie lost het punt professioneel of technisch op?
• Termijn: Tegen wanneer moet de maatregel zijn uitgevoerd of opnieuw worden beoordeeld?
• Bewijs: Screenshot, ticket, wijzigings-ID of audit-log-verwijzing

Bij productieve firewalls moet het bewijs niet alleen uit een screenshot bestaan. Als een configuratie is gewijzigd, horen wijzigingsticket, audit trail, betrokken firewall-regel en resultaat van de opvolging samen. Voor wijzigingen aan regels, interfaces, hosts en services is Sophos Firewall Audit Trail Logs controleren bijzonder nuttig.

Na wijzigingen opnieuw controleren

Na een oplossing moet men de Health Check opnieuw openen en controleren of de bevinding echt verdwenen is. Daarnaast is een technische functietest nodig, omdat een groene status alleen niet bewijst dat het productieve verkeer nog steeds correct verloopt.

Voorbeelden:

• Na een wijziging aan Device access controleren of beheertoegang vanuit het beoogde beheernetwerk nog werkt en vanuit ongewenste netwerken niet meer bereikbaar is.
• Na MFA-wijzigingen met een testgebruiker aanmelden en de fallback-beheerder apart controleren.
• Na wijzigingen in het regelwerk Log Viewer, Policy Test en betrokken applicaties testen.
• Na logging- of rapportagewijzigingen controleren of nieuwe gebeurtenissen lokaal, in Sophos Central of in de Syslog echt zichtbaar zijn.
• Na een override een herinnering instellen, zodat de uitzondering niet permanent wordt vergeten.

Als meerdere bevindingen tegelijkertijd worden behandeld, moet men de wijzigingen in kleine blokken opdelen. Anders is bij een later probleem onduidelijk of Device Access, MFA, firewall-regels, TLS Inspection of een andere wijziging de oorzaak was.

Health Check als operationeel proces gebruiken

De Health Check is het sterkst als hij regelmatig en na belangrijke wijzigingen wordt uitgevoerd.

Geschikte tijdstippen:

• na de eerste configuratie of een go-live,
• voor en na grotere wijzigingen in het regelwerk,
• voor firmware-upgrades,
• na herstel of hardwarevervanging,
• na migraties of grotere architectuurwijzigingen,
• voor audits,
• driemaandelijks als beveiligingsbeoordeling.

Voor wijzigingen zelf moet daarnaast de audit trail worden gebruikt. Het artikel Sophos Firewall Audit Trail Logs controleren legt uit hoe men configuration-audit.log evalueert en configuratiewijzigingen traceert.

Praktische beoordelingsprocedure

Een pragmatische Health-Check-beoordeling verloopt als volgt:

1. Health Check in het Control Center openen.
2. Niet-conforme bevindingen naar ernst sorteren.
3. Internetblootgestelde diensten en beheertoegangen eerst controleren.
4. MFA-, wachtwoord- en sessiethema’s behandelen.
5. Brede firewall-regels identificeren en met Log Viewer valideren.
6. Back-up, hotfixes, logging en rapportage controleren.
7. Beschermingsfuncties per regel beoordelen.
8. Gerechtvaardigde uitzonderingen documenteren in plaats van zonder commentaar te overschrijven.
9. Na wijzigingen opnieuw controleren.
10. Resultaat met datum, behandelaar en openstaande punten documenteren.

Voor terugkerende beoordelingen volstaat vaak een eenvoudige tabel met bevinding, risico, maatregel, verantwoordelijke, status en herinnering. Belangrijk is dat bevindingen niet alleen worden bekeken, maar worden afgehandeld of bewust geaccepteerd.

Grenzen

De Health Check is nuttig, maar heeft duidelijke grenzen.

• Hij kent niet de volledige bedrijfslogica van de omgeving.
• Hij beoordeelt niet of een regel professioneel nodig is.
• Hij vervangt geen netwerksegmentatie en geen zonemodel.
• Hij herkent niet automatisch elke risicovolle uitzondering.
• Hij vervangt geen extern audit en geen handmatige regelbeoordeling.
• Hij zegt niet of waarschuwingen later ook worden behandeld.

Daarom moet men de Health Check als startpunt zien. Hij maakt zichtbare afwijkingen tastbaar, maar de eigenlijke veiligheidskwaliteit ontstaat door goede architectuur, schone processen en consequente verzorging.

Operationele checklist

• Health Check na go-live en na grote wijzigingen uitvoeren.
• Bevindingen naar ernst en blootstelling prioriteren.
• WAN-bereikbaarheid van WebAdmin, SSH, User Portal en VPN Portal controleren.
• MFA voor beheerders, portalen en Remote Access activeren.
• Brede firewall-regels opruimen of verantwoorden.
• Logging in belangrijke regels inschakelen.
• Back-ups en herstelproces controleren.
• Hotfix- en firmwareproces documenteren.
• Overrides alleen met reden instellen.
• Health-Check-resultaat regelmatig documenteren.

FAQ