Sophos Firewall: best practices voor netwerkbeveiliging

Firewalls waren lange tijd de plek waar aanvallen werden tegengehouden. Vandaag zijn ze zelf een van de aantrekkelijkste doelwitten. Dat is logisch: een firewall staat op een bevoorrechte positie tussen internet, vestigingsnetwerken, cloudservices, VPN-toegang en interne applicaties. Wie hier een kwetsbaarheid, zwak wachtwoord of misconfiguratie vindt, staat niet meer voor de deur, maar vaak al midden in het gebouw.

Daarom volstaat het niet meer om een firewall alleen te zien als policy-engine voor Allow- en Deny-regels. Moderne netwerkbeveiliging heeft drie pijlers nodig: hardening, protection en detection and response. De aanvalsvlakte moet vóór een aanval worden verkleind, aanvallen moeten tijdens de aanval netjes worden geblokkeerd en daarna moet snel duidelijk zijn wat er is gebeurd.

Ik werk al vele jaren met Sophos Firewall-omgevingen in zeer uiteenlopende groottes en sectoren. De volgende aanbevelingen zijn daarom geen theoretische featurelijst, maar wat zich in echte klantomgevingen, migraties, audits en supportcases steeds opnieuw bewijst.

Waarom firewalls zo sterk in beeld zijn

Een firewall is voor aanvallers een lonend doelwit, omdat hij blootgesteld, bevoorrecht en vaak bedrijfskritisch is. Daarbij komt dat veel omgevingen firewalls, VPN-portalen of remote management-toegang jarenlang gebruiken. Niet elke omgeving is netjes gepatcht, niet elk managementvlak is echt afgeschermd en niet elke login is beschermd met multi-factor authentication.

In de praktijk zijn vooral drie terugkerende oorzaken zichtbaar bij succesvolle aanvallen:

• Kwetsbaarheden in firewalls en edge-systemen, vooral wanneer patches laat of helemaal niet worden geïnstalleerd.
• Gecompromitteerde credentials en identiteitsaanvallen, vaak zonder MFA of met een zwakke MFA-configuratie. Het Sophos Active Adversary Report 2026 noemt identiteitsgerelateerde oorzaken als root cause in 67.32% van de onderzochte gevallen.
• Blootgestelde systemen, zoals RDP, VPN-portalen, User Portals of admininterfaces die direct vanaf internet bereikbaar zijn.

De belangrijkste gedachte daarachter: veel aanvallen zijn tegenwoordig geen spectaculaire “inbraak” meer. Heel vaak loggen aanvallers gewoon in. Als een gebruikersaccount, adminwachtwoord of VPN-toegang is gecompromitteerd, lijkt de eerste stap voor de firewall in eerste instantie op legitiem gebruik.

De drie pijlers van moderne netwerkbeveiliging

Sophos beschrijft de bescherming van moderne netwerken als een spectrum van proactief tot reactief:

1. Hardening: aanvalsvlak verkleinen, verouderde systemen verwijderen, veilige producten gebruiken, configuraties controleren, toegang beperken.
2. Protection: aanvallen blokkeren, versleuteld verkeer controleren, Web-, IPS-, Zero-Day- en Application Control-functies zinvol gebruiken.
3. Detection and Response: afwijkingen herkennen, gecompromitteerde apparaten isoleren, dreigingsdata correleren en automatisch reageren.

Veel firewalls zijn traditioneel sterk in de tweede pijler. Ze blokkeren verkeer, controleren pakketten, herkennen bekende patronen en dwingen policies af. Dat is belangrijk, maar niet meer voldoende. Als de firewall zelf verkeerd is geconfigureerd, Remote Access zonder MFA draait of een ongepatcht systeem productief blijft, is er een structureel probleem dat geen enkele IPS-regel netjes oplost.

Mijn ervaring laat zien: de beste resultaten ontstaan niet door één magische functie, maar door een nette basisconfiguratie, regelmatige reviews en een firewall die in het bredere securityproces is ingebed.

Pijler 1: Hardening vóór de aanval

Hardening is het deel van securitywerk dat zelden applaus krijgt, maar in een incident het verschil maakt. Het gaat om minder aanvalsvlak, minder oude systemen, minder open managementroutes en minder afhankelijkheid van handmatige reacties.

Infrastructuur verkleinen en oude systemen verwijderen

De eenvoudigste manier om een aanvalsvlak te verkleinen is soms de ongemakkelijkste: dingen uitschakelen. Elke oude appliance, vergeten VPN-dienst, managementportal en niet meer ondersteunde server is een extra aanvalspunt. Vooral systemen aan de netwerkrand of systemen die indirect bevoorrechte toegang tot interne netwerken mogelijk maken, zijn kritisch.

Voor Sophos Firewall admins betekent dit concreet:

• Regelmatig controleren welke firewalls, REDs, VPN-gateways, WLAN-controllers, reverse proxies en Remote Access-componenten nog productief zijn.
• End-of-life- of end-of-support-systemen uit bevoorrechte posities verwijderen.
• Functies consolideren wanneer dat complexiteit verlaagt: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting en central management moeten zo schoon mogelijk op elkaar worden afgestemd.
• Documenteren welke diensten echt vanaf internet bereikbaar moeten zijn.

Het doel is niet om zoveel mogelijk in één product te stoppen. Het doel is om blinde legacy te vermijden. Een kleine, actuele en goed gecontroleerde infrastructuur is bijna altijd veiliger dan een grote, historisch gegroeide omgeving met veel “dat was altijd al zo”-uitzonderingen.

Managementtoegang consequent beveiligen

Een van de belangrijkste best practices is simpel: de Web Admin Console en het User Portal zouden niet onnodig vanaf de WAN bereikbaar moeten zijn. Als beheer op afstand nodig is, zou dat via Sophos Central, een dedicated managementnetwerk, ZTNA of een ander gecontroleerd pad moeten gebeuren.

In klantomgevingen zie ik steeds opnieuw dat niet de ingewikkeldste aanvalstechniek het probleem is, maar een oude admin-toegang, een historisch gegroeid portal of een “tijdelijke” uitzondering die nooit is verwijderd. Juist zulke plekken horen in een regelmatige firewallreview.

De volgende punten zouden in elke Sophos Firewall-omgeving moeten worden gecontroleerd:

• MFA voor beheerders activeren, vooral voor de standaardadmin en alle accounts met uitgebreide rechten.
• MFA voor VPN- en portallogins afdwingen wanneer zulke toegangen nog worden gebruikt.
• WAN-toegang tot Admin Console en User Portal vermijden of sterk beperken tot dedicated bronnetwerken.
• Sterke wachtwoordregels voor gebruikers en beheerders configureren.
• SSH beveiligen, idealiter met public-key-authenticatie en zonder brede WAN-bereikbaarheid.
• Centrale backups activeren en backuptoegang beschermen, omdat configuratiebackups gevoelige informatie kunnen bevatten.
• Meldingen en logging activeren, zodat securityrelevante gebeurtenissen niet verloren gaan in de dagelijkse operatie.

Backups worden vaak onderschat. Een firewallbackup bevat niet alleen onschuldige instellingen, maar informatie over netwerken, regels, certificaten, VPNs en interne structuren. Backups moeten daarom versleuteld, gecontroleerd opgeslagen en regelmatig getest worden.

Device Access en Local Service ACL bewust instellen

Wanneer men over WAN-toegang spreekt, moet men bij Sophos Firewall concreet spreken over Device Access en Local Service ACL. In de Device Access-matrix wordt per zone vastgelegd welke lokale firewallservices bereikbaar zijn: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, VPN-portalen en verdere diensten.

De best practice is hier eenvoudig maar effectief: vanuit de WAN-zone zou alleen bereikbaar moeten zijn wat echt nodig is. Admin-toegang, SSH en User Portal horen niet breed op internet. Als uitzonderingen nodig zijn, moeten ze via Local Service ACL Exception Rules tot concrete bron-IP-adressen of managementnetwerken worden beperkt.

Landregels als minimale bescherming

Als vaste bron-IP-adressen niet realistisch zijn, adviseer ik minimaal met landregels te werken. Toegang alleen vanuit enkele relevante landen is nog altijd veel beter dan wereldwijde bereikbaarheid. Alternatief kunnen landen worden geblokkeerd waarmee het bedrijf geen relatie heeft en waar medewerkers of admins normaal gesproken niet zijn. Dat is geen vervanging voor MFA, sterke rollen en nette ACLs, maar vermindert onnodige ruis en veel geautomatiseerde toegangspogingen.

Vanuit mijn perspectief is dit een van de eerste punten in elke firewallreview. Veel risicovolle configuraties ontstaan niet uit kwade wil, maar omdat een dienst voor een migratie, supportcase of test kort werd geopend en later nooit meer gesloten. Precies zulke details onderscheiden een firewall die gewoon draait van een firewall die echt netjes wordt beheerd.

Login Security en adminrollen controleren

MFA is belangrijk, maar de loginlaag bestaat uit meer dan een tweede factor. Beheerders zouden eigen, traceerbare accounts moeten gebruiken en niet permanent met een gedeelde full admin werken. Rolgebaseerde rechten helpen support-, reporting- of helpdesktoegang te scheiden van het echte firewallbeheer.

Daarnaast moeten mislukte loginpogingen worden beperkt, sessies netjes worden beëindigd en admin-toegang tot gedefinieerde netwerken worden beperkt. Een login-disclaimer kan in bepaalde omgevingen juridisch zinvol zijn, maar is geen vervanging voor echte technische controles. Belangrijker zijn sterke wachtwoordrichtlijnen, korte inactieve sessies, brute-force-bescherming en least privilege.

Patch fatigue vermijden: Hotfixes moeten snel werken

Patching is een van die onderwerpen waarbij theorie en praktijk ver uiteenlopen. Natuurlijk weet elke admin dat firmware-updates belangrijk zijn. In de realiteit betekenen ze onderhoudsvensters, risicoafweging, HA-planning, communicatie met businessafdelingen en soms downtime. Dat leidt tot patch fatigue: updates worden uitgesteld omdat ze omslachtig zijn.

Precies hier wordt de tijdsfactor gevaarlijk. Identiteitsaanvallen zijn inmiddels de dominante root cause, maar exploitatie van kwetsbaarheden blijft een reële vector, vooral bij edge-systemen zoals firewalls, VPNs en andere internetnabije diensten. Het Sophos Active Adversary Report 2026 noemt als voorbeeld CVE-2024-40766 in SonicOS, zichtbaar in een groot deel van de bevestigde exploitgevallen in de dataset. Tegelijk lag de mediane tijd tussen vendor advisory of patch en waargenomen exploitatie op 322 dagen. Dat is een duidelijk signaal: patch fatigue is geen abstract operationeel probleem, maar een aanvalvenster.

Sophos Firewall zet hier een belangrijke stap: Automated Hotfixes maken securityrelevante live patches mogelijk zonder klassiek onderhoudsvenster. Voor admins is dat enorm waardevol, omdat de kritieke bescherming niet hoeft te wachten tot het volgende vrije onderhoudsvenster.

Toch vervangen Hotfixes geen nette updatestrategie. Ze sluiten de gevaarlijke kloof tussen ontdekte kwetsbaarheid en reguliere firmware-upgrade. De best practice is daarom:

• Hotfixes ingeschakeld laten.
• Firmwareversies regelmatig controleren en de voorbereiding van firmware-updates documenteren.
• Upgradepaden en compatibiliteit vooraf lezen.
• Backups en rollbackplan voorbereiden.
• HA-clusters en remote sites apart plannen.

VPN niet als bewijs van vertrouwen behandelen

Remote Access VPN was jarenlang de standaard. Het probleem: klassieke VPN denkt vaak in netwerken, niet in applicaties. Wie succesvol verbonden is, bevindt zich vanuit veel omgevingen al in een vertrouwd gebied. Als het endpoint gecompromitteerd is of credentials zijn gestolen, kan een aanvaller vanaf daar verder bewegen.

Zero Trust Network Access (ZTNA) lost dit niet door magie op, maar door een beter principe: Trust nothing, verify everything. Toegang wordt niet breed op een netwerk verleend, maar beoordeeld per gebruiker, apparaat, toestand en applicatie. Een apparaat moet gezond en compliant zijn, de identiteit moet worden geverifieerd en de policy beslist granulair welke applicatie bereikbaar is.

ZTNA is geen automatische Sophos-keuze

Belangrijk hierbij: ZTNA is geen beslissing die automatisch voor Sophos ZTNA moet spreken. Afhankelijk van de omgeving kunnen gespecialiseerde ZTNA-, SSE- of SASE-aanbieders functioneel verder zijn, betere integraties bieden of organisatorisch beter passen. Doorslaggevend is niet de vendornaam, maar of identiteit, device posture, applicatietoegang, logging en operatie netjes samenwerken.

Dat is ook mijn algemene houding in Sophos-projecten: ik kies niet bij elk onderwerp automatisch voor Sophos. Als een third-party oplossing voor ZTNA, SSE, Threat Intelligence, SIEM of NDR technisch beter past, is dat de betere aanbeveling. Een goede securityarchitectuur ontstaat niet door maximale vendorbinding, maar door netjes geïntegreerde componenten met duidelijke verantwoordelijkheid.

Voor pure Sophos-omgevingen kan de integratie toch interessant zijn, omdat ZTNA, Endpoint, Firewall en Sophos Central samen gebruikt kunnen worden. Een gecompromitteerd of niet-compliant apparaat kan toegang verliezen zonder dat een admin eerst handmatig firewallregels moet ombouwen. Daarbij is ook een blik op de ZTNA Gateway op de Sophos Firewall zinvol. In gemengde of grotere omgevingen moet men echter bewust vergelijken en niet automatisch de bestaande firewallleverancier als ZTNA-platform kiezen.

Wie vandaag nog sterk op SSL VPN of IPsec Remote Access vertrouwt, zou minimaal deze punten moeten controleren:

• MFA voor elke Remote Access-toegang afdwingen.
• Oude of ongebruikte VPN-gebruikers verwijderen.
• Groepsimport uit AD of Entra ID controleren, zodat Remote Access niet onbedoeld wordt geactiveerd.
• Split-Tunnel, toegestane netwerken en rechten tot het minimum beperken.
• Stapsgewijze migratie naar een passende ZTNA-, SSE- of SASE-oplossing plannen, vooral voor interne webapps, RDP, SSH, beheerportalen en businessapplicaties.

Segmentatie tegen Lateral Movement

Wanneer aanvallers met geldige credentials of via een blootgestelde dienst binnenkomen, bepaalt interne segmentatie hoe ver ze kunnen bewegen. Een firewall mag daarom niet alleen perimeter-gateway zijn, maar moet interne zones netjes scheiden: gebruikers, servers, management, IoT, gastnet, productie, backup en bijzonder kritieke systemen horen niet blind in hetzelfde vertrouwensmodel.

Praktisch betekent dit: VLANs en zones niet alleen uit ordelijkheid bouwen, maar met echte firewallregels beveiligen. Tussen gebruikers- en servernetwerken zouden alleen de noodzakelijke applicaties toegestaan moeten zijn. Managementtoegang hoort in dedicated adminnetwerken. IoT- en printernetwerken zouden niet vrij met servers mogen praten. Backups en domain controllers verdienen bijzonder restrictieve regels en goede logging.

Hier sluit de cirkel met de uitspraak “aanvallers loggen in”. Als een gecompromitteerd account wel toegang tot een applicatie heeft, maar niet tot het hele netwerk, wordt een incident niet automatisch een volledige compromittering.

Bij nieuwe projecten plan ik segmentatie daarom zo vroeg mogelijk mee. Achteraf kan het nog steeds, maar het is duidelijk lastiger, omdat applicaties, uitzonderingen en historische afhankelijkheden dan eerst ontrafeld moeten worden.

Misconfiguraties zichtbaar maken

Een firewall kan technisch zeer krachtig zijn en toch gevaarlijk worden door verkeerde configuratie. Te brede regels, “Any”-objecten, zwakke authenticatie, ontbrekende IPS-policies, uitgeschakelde pattern updates of open portalen zijn typische voorbeelden. Het lastige is dat zulke risico’s in gegroeide omgevingen niet altijd meteen zichtbaar zijn.

De Sophos Firewall Health Check adresseert precies dit probleem. Hij controleert tientallen instellingen tegen best practices en benchmarks en toont in het Control Center waar configuraties risicovol zijn of afwijken van aanbevolen standaarden. Resultaten worden op risico geprioriteerd, leiden direct naar de betrokken instellingen en kunnen afhankelijk van de situatie worden opgelost of bewust worden genegeerd.

Health Check is vooral nuttig voor terugkerende operationele processen:

• na een nieuwe firewall-rollout,
• na grotere regelwijzigingen,
• vóór en na firmware-upgrades,
• vóór audits,
• na migraties van oude hardware,
• als regelmatige kwartaalcheck.

Belangrijk is ook: een Health Check neemt admins het denken niet uit handen. Niet elke aanbeveling past bij elke omgeving. Sommige punten hebben compliance- of operationele redenen, andere zijn duidelijke securitygaten. Doorslaggevend is afwijkingen bewust te beoordelen en niet ongemerkt te laten groeien.

Vanuit mijn perspectief is Health Check vooral sterk als doorlopend operationeel hulpmiddel. Het is niet alleen iets voor de eerste go-live, maar een goed startpunt voor kwartaalreviews, auditvoorbereiding en het opruimen van oude regelsets.

Secure by Design: de firewall zelf hardenen

Vanuit mijn perspectief hebben we niet alleen securityproducten nodig, maar veilige securityproducten. Dat is een belangrijk verschil. Een firewall mag niet alleen aanvallen op andere systemen blokkeren, maar moet zelf tegen aanvallen gehard zijn.

Bij Sophos Firewall horen daar meerdere lagen bij:

• Geharde kernel en gemoderniseerde architectuur: de nieuwere Xstream-architectuur zet sterker in op isolatie, modularisering, containerisering en privilegescheiding. Daardoor worden bepaalde kwetsbaarheidsklassen verminderd en effecten door betere isolatie beperkt. Daar komen mitigaties tegen side-channel- en CPU-kwetsbaarheden bij. Dit maakt het platform robuuster, maar niet immuun voor kwetsbaarheden.
• Automated Hotfixes: securitycorrecties kunnen zeer snel en zonder klassiek onderhoudsvenster worden verspreid.
• Remote Integrity Monitoring: de geïntegreerde Sophos XDR Linux Sensor kan systeemintegriteit in realtime bewaken, bijvoorbeeld ongeoorloofde configuratiewijzigingen, Rule Exports, verdachte programma-uitvoering of File Tampering. Waardevol is dit alleen als de functie is geactiveerd, gelicenseerd, aangesloten en in de operatie ook wordt bewaakt.
• Veilige Central-beheer: administratie kan via Sophos Central verlopen zonder managementpoorten breed aan internet bloot te stellen.
• Health Check: risicovolle configuraties worden direct zichtbaar.
• Versleutelde backups: configuratiedata wordt beschermd overgedragen en opgeslagen.

Daarnaast zet Sophos in op proactieve monitoring van de geïnstalleerde firewallbasis. Telemetrie uit firewalls kan helpen om aanwijzingen voor aanvallen of manipulatie eerder te herkennen. Wanneer een patroon zichtbaar wordt, kan Sophos klanten of partners gericht ondersteunen en Hotfixes snel breed uitrollen.

Deze punten zijn in het dagelijks werk minder spectaculair dan een nieuwe firewallregel of een geblokkeerde aanval in het log. Op lange termijn zijn ze echter doorslaggevend. Een gehard product verkleint de kans dat de firewall zelf het instappunt wordt. Maar het vervangt geen net patchproces, geen monitoring en geen regelmatige configuratiereview.

Waarop men bij een firewallfabrikant moet letten

Secure by Design is niet alleen een producteigenschap, maar ook een leveranciersvraag. Klanten mogen van fabrikanten verwachten dat ze kwetsbaarheden transparant behandelen, lifecycle-informatie duidelijk communiceren, securityfixes snel uitrollen en producten zo bouwen dat misconfiguraties en gecompromitteerde componenten zo vroeg mogelijk opvallen.

De verantwoordelijkheid is gedeeld. Fabrikanten moeten veilige producten leveren en transparant reageren. Klanten moeten updates installeren, EOL-systemen vervangen, MFA gebruiken en de operatie regelmatig controleren. Beide horen bij elkaar.

Pijler 2: Protection tijdens de aanval

Hardening is de basis. Daarna moet de firewall blijven doen waarvoor hij wordt ingezet: verkeer controleren en aanvallen blokkeren. Bij Sophos Firewall horen daar onder andere IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection en Threat Intelligence Feeds bij.

Sophos zet hiervoor sterk in op de Xstream-architectuur. Vertrouwd verkeer kan efficiënter worden verwerkt, rekenintensieve taken zoals crypto-operaties lopen via geoptimaliseerde paden, en voor verkeer met hoger risico blijft meer performance-reserve over voor Deep Packet Inspection, TLS Inspection en Zero-Day Protection.

TLS Inspection is een goed voorbeeld van de balans tussen security en operatie. Zonder ontsleuteling blijft een groot deel van modern verkeer onzichtbaar. Met slecht geplande TLS-regels ontstaan echter supportcases, certificaatproblemen of performanceknelpunten. De best practice is daarom niet “alles blind ontsleutelen”, maar netjes classificeren:

• kritieke gebruikersgroepen en servers eerst,
• banking, health, privacy en bekende problematische categorieën netjes uitzonderen,
• blokkeer- en waarschuwingspagina’s testen,
• certificaatdistributie documenteren,
• logs actief evalueren.

Mijn aanbeveling is om TLS Inspection niet als alles-of-niets-project te starten. Beter is een nette rollout met duidelijke gebruikersgroepen, uitzonderingen, testvensters en logevaluatie. Zo stijgt de zichtbaarheid zonder dat de helpdesk op dag één wordt overspoeld.

Ook Threat Feeds horen in dit beschermingsgebied. Zulke feeds helpen bekende kwaadaardige IPs, domeinen of URLs direct aan de netwerkgrens te blokkeren. In nieuwere Sophos Firewall-versies zijn ze veel sterker geïntegreerd in Active Threat Response en beschermingsmechanismen.

Threat Feeds worden vooral interessant wanneer niet alleen generieke lijsten worden gebruikt, maar gecureerde third-party feeds met actuele context. Een voorbeeld is Cybora.io, waar kwaadaardige IPs en domeinen uit verschillende bronnen en firewalltelemetrie tot bruikbare feeds worden samengevoegd. Hoe zulke feeds op firewalls gebruikt kunnen worden, heb ik uitgebreider beschreven in het artikel Threat Intelligence Feeds voor de firewall.

Ook hier geldt: Threat Feeds moeten getest en geobserveerd worden. Te agressieve feeds, ontbrekende allowlist-processen of onduidelijke verantwoordelijkheden kunnen legitiem verkeer blokkeren en operationeel meer schade dan voordeel opleveren. Goede feeds vervangen geen regelreview, maar zijn een extra bouwsteen met eigen tuning.

Daarnaast mogen de klassieke SFOS-hardeningmaatregelen niet worden vergeten: Spoof Protection, passende DoS-instellingen en Geo-IP-Blocking kunnen eenvoudige, luide of duidelijk ongewenste toegangen verminderen. Dat vervangt geen nette policy, maar neemt onnodige ruis weg en blokkeert aanvalspaden die in veel omgevingen geen legitiem doel hebben.

Ik raad hier een pragmatische aanpak aan: eerst de grote risico’s netjes controleren, daarna beschermingsfuncties stap voor stap aanscherpen en met logs aantonen wat echt werkt. Een overbelaste policy die niemand meer begrijpt, levert op lange termijn geen securitywinst op.

Pijler 3: Detection and Response na het eerste signaal

Het spannendste deel van moderne netwerkbeveiliging is de reactie. Een firewall zou niet geïsoleerd moeten werken, maar signalen uit Endpoint, Server, NDR, MDR, XDR en Threat Intelligence moeten gebruiken. Sophos kan hier ecosysteemvoordelen uitspelen, maar alleen als deze integraties echt bij de omgeving passen.

Ecosystemen helpen alleen als ze passen

Synchronized Security en Security Heartbeat zijn goede ideeën: de firewall kan de toestand van endpoints meenemen en communicatie van gecompromitteerde apparaten beperken of blokkeren. In de praktijk gebruiken echter steeds meer bedrijven Microsoft Defender of andere endpointoplossingen. Dan werkt dit deel van het Sophos-ecosysteem slechts beperkt of helemaal niet. Daarom moet men niet automatisch alles van dezelfde fabrikant nemen alleen omdat het als geïntegreerd ecosysteem wordt aangeboden.

Mijn aanbeveling is hier duidelijk: doorslaggevend is wat bij het bedrijf past en netjes geïmplementeerd kan worden. Als Microsoft Defender, een andere EDR, een third-party NDR of een externe SIEM de betere basis is, moet de firewall netjes in die architectuur worden geïntegreerd. Belangrijker dan cross-selling is dat logs op de juiste plek terechtkomen, alerts begrepen worden en iemand regelmatig controleert wat de systemen melden. Zonder loganalyse, tuning en incidentproces helpt zelfs de beste integratie weinig.

Met Active Threat Response kunnen gedetecteerde dreigingen automatisch in netwerkbeslissingen worden vertaald. En met NDR Essentials krijgt de firewall extra zicht op verdacht netwerkverkeer, ook waar geen klassieke endpoint agent is geïnstalleerd.

Automatisering heeft runbooks nodig

Automatisering heeft kaders nodig. Het moet duidelijk zijn welke signalen automatisch mogen blokkeren, wie een isolatie opheft, hoe false positives worden behandeld en hoe zulke processen worden getest. Zonder runbooks, verantwoordelijkheden en regelmatige oefeningen weet in een incident niemand of een blokkade bedoeld, correct of te agressief was.

Wat gebeurt er in een incident? Een gecompromitteerd apparaat kan worden geïsoleerd, C2-communicatie onderbroken, exfiltratie geblokkeerd en een MDR- of XDR-analist kan Active Threat Response activeren zonder eerst handmatig een regel in de firewall te bouwen. Dat is vooral waardevol wanneer een aanval buiten normale werktijden wordt herkend.

Voor admins is vooral één ding belangrijk: de reactie moet snel genoeg zijn. Als een MDR- of XDR-analist eerst moet bellen, een ticket moet schrijven en een lokale admin dan op vrijdagavond handmatig een regel moet bouwen, is de reactietijd te lang. Geautomatiseerde reactie betekent niet dat mensen worden vervangen. Het betekent dat de eerste indamming direct gebeurt en het team daarna netjes kan onderzoeken.

Juist in kleinere IT-teams is deze automatisering waardevol. Niet elk bedrijf heeft 24/7 een firewall-specialist beschikbaar. Als Endpoint, Firewall, NDR, MDR en SIEM vendor-overstijgend zinvol samenwerken, wordt tijd gewonnen, en tijd is bij actieve aanvallen vaak de belangrijkste factor.

Praktische checklist voor Sophos Firewall admins

Wie vandaag zijn Sophos Firewall wil hardenen, kan met deze lijst beginnen:

Direct controleren

• Zijn Hotfixes geactiveerd?
• Is MFA actief voor beheerders?
• Zijn Web Admin Console en User Portal vanaf WAN bereikbaar?
• Zijn SSL VPN of IPsec Remote Access met MFA beschermd?
• Zijn er nog ongebruikte lokale adminaccounts?
• Zijn backups gepland, versleuteld en getest?
• Zijn Device Access en Local Service ACL tot het minimum beperkt?
• Zijn WAN-bereikbare diensten minstens tot relevante landen of bekende bronnetwerken beperkt?
• Zijn pattern updates en firmwareversies actueel?

Binnen de komende weken

• Health Check uitvoeren en findings prioriteren.
• Oude firewallregels met “Any” bij bron, doel of service controleren.
• Adminrollen, Login Security, session timeouts en brute-force-bescherming controleren.
• Blootgestelde diensten zoals RDP, SSH, webservers, portalen en NAT-regels inventariseren.
• Interne zones en VLAN-regels tegen lateral movement controleren.
• ZTNA-, SSE- of SASE-opties voor typische Remote Access-applicaties vergelijken.
• Threat Feeds en DNS Protection controleren.
• Spoof Protection, DoS-bescherming en Geo-IP-Blocking op basis van risico activeren.
• TLS Inspection gestructureerd testen en stapsgewijs uitrollen.

Strategisch plannen

• End-of-life-systemen vervangen.
• Firewall-, VPN-, DNS-, SD-WAN- en ZTNA/SSE-operatie zinvol op elkaar afstemmen.
• Centraal management, reporting en alerting standaardiseren, bijvoorbeeld via Sophos Central, SIEM of bestaande securityplatforms.
• Syslog/SIEM-export en logretentie voor forensische analyses definiëren.
• MDR/XDR/NDR-signalen in het incidentproces integreren.
• Terugkerende firewall-hardeningreviews invoeren.

Conclusie

Network Security Best Practices zijn geen eenmalig project, maar een operationeel model. Juist omdat firewalls aan de netwerkrand zo bevoorrecht zijn, moeten ze regelmatig gehard, gepatcht, gecontroleerd en in detectie geïntegreerd worden.

Mijn aanbeveling na vele jaren met Sophos Firewall is daarom duidelijk: een moderne firewall moet meer zijn dan een beschermingsproduct. Doorslaggevend zijn een veilig ontwerp, zichtbare misconfiguraties, snelle securitycorrecties en een reactie die in een incident met Endpoint, NDR, XDR en MDR samenwerkt.

Of praktisch gezegd: als een firewall zo oud is dat hij eerder in een museum dan in een rack thuishoort, is dat niet alleen een operationeel risico. Het is een aanvalsvlak. En precies dat aanvalsvlak houd ik zo klein mogelijk.

Ondersteuning door Avanet

Als ondersteuning nodig is bij het hardenen van een Sophos Firewall, kan Avanet helpen. Als jarenlange Sophos-specialist ondersteun ik IT-teams bij firewall-audits, Health Check-reviews, opschonen van regelsets, Remote Access- en ZTNA/SSE-planning, updatestrategieën en trainingen.

Een externe blik op managementtoegang, VPN-configuratie, oude regels, WAN-blootgestelde diensten en update-status loont vaak. Veel risico’s ontstaan niet door één verkeerde instelling, maar door gegroeide uitzonderingen die in de dagelijkse praktijk niemand meer bevraagt.

Bij interesse volstaat een kort bericht via het contactformulier. Daarna kan samen worden bekeken of een compacte firewallreview, een audit of een training voor de betreffende omgeving het meest zinvol is.

FAQ

Verdere links

• Avanet Blog: Sophos Firewall v22: overzicht en alle nieuwe functies
• Avanet Blog: Threat Intelligence Feeds voor de firewall
• Avanet Blog: Sophos ZTNA Gateway op de Sophos Firewall
• Avanet Blog: Sophos NDR - blinde vlekken in het netwerk wegwerken
• Avanet KB: Sophos Firewall Firmware Update - voorbereiding en best practices

Bronnen

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report