Sophos Firewall: Best Practices voor moderne netwerkbeveiliging

Firewalls waren lange tijd de plek waar aanvallen werden afgeweerd. Tegenwoordig zijn ze zelf een van de aantrekkelijkste doelen. Dat is logisch: een firewall bevindt zich op een bevoorrechte positie tussen internet, lokale netwerken, clouddiensten, VPN-toegangen en interne applicaties. Wie hier een kwetsbaarheid, een zwak wachtwoord of een verkeerde configuratie vindt, staat niet meer voor de deur, maar vaak al midden in het gebouw.

Precies daarom is het niet meer voldoende om een firewall alleen als policy-engine voor toestaan- en weigeren-regels te beschouwen. Moderne netwerkbeveiliging heeft drie pijlers nodig: Versterking, Bescherming en Detectie en Reactie. Je moet het aanvalsoppervlak vóór een aanval verkleinen, tijdens een aanval correct blokkeren en daarna snel herkennen wat er is gebeurd.

Ik beheer al vele jaren Sophos Firewall-omgevingen in zeer uiteenlopende groottes en sectoren. De volgende aanbevelingen zijn daarom niet bedoeld als theoretische featurelijst, maar als wat zich in echte klantomgevingen, migraties, audits en supportgevallen keer op keer heeft bewezen.

Waarom firewalls zo sterk in de belangstelling staan

Een firewall is voor aanvallers een aantrekkelijk doel omdat ze blootgesteld, bevoorrecht en vaak bedrijfskritisch is. Bovendien: veel omgevingen draaien firewalls, VPN-portalen of remote management-toegangen jarenlang. Niet elke omgeving is goed gepatcht, niet elke managementinterface is echt afgeschermd en niet elke aanmelding is beveiligd met multi-factor authenticatie.

In de praktijk zijn er vooral drie terugkerende oorzaken voor succesvolle aanvallen:

• Kwetsbaarheden in firewalls en edge-systemen, vooral als patches te laat of helemaal niet worden toegepast.
• Gecompromitteerde inloggegevens en identiteitsaanvallen, vaak zonder MFA of met een zwakke MFA-configuratie. Het Sophos Active Adversary Report 2026 noemt identiteitsgerelateerde oorzaken als hoofdoorzaak in 67,32% van de onderzochte gevallen.
• Blootgestelde systemen, zoals RDP, VPN-portalen, gebruikersportalen of beheerdersinterfaces die direct vanaf het internet bereikbaar zijn.

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

De drie pijlers van moderne netwerkbeveiliging

Moderne netwerkbeveiliging kan worden gezien als een spectrum van proactief tot reactief:

1. Versterking: Aanvalsoppervlak verkleinen, verouderde systemen verwijderen, veilige producten gebruiken, configuraties controleren, toegang beperken.
2. Bescherming: Aanvallen blokkeren, versleuteld verkeer controleren, web-, IPS-, zero-day- en applicatiecontrolefuncties zinvol gebruiken.
3. Detectie en Reactie: Afwijkingen herkennen, gecompromitteerde apparaten isoleren, bedreigingsgegevens correleren en automatisch reageren.

Veel firewalls zijn traditioneel sterk in de tweede pijler. Deze systemen blokkeren verkeer, controleren pakketten, herkennen bekende patronen en voeren beleidsregels uit. Dat is belangrijk, maar niet meer voldoende. Als de firewall zelf verkeerd is geconfigureerd, als remote access zonder MFA draait of als een ongepatcht systeem nog steeds productief is, heb je een structureel probleem dat geen enkele IPS-regel netjes kan oplossen.

Mijn ervaring toont aan: de beste resultaten ontstaan niet door een enkele magische functie, maar door een schone basisconfiguratie, regelmatige reviews en een firewall die is geïntegreerd in het overige beveiligingsproces.

Pijler 1: Versterking vóór de aanval

Versterking is het deel van het beveiligingswerk dat zelden applaus krijgt, maar in geval van nood het verschil maakt. Het gaat om minder aanvalsoppervlak, minder oude lasten, minder open managementroutes en minder afhankelijkheid van handmatige reacties.

Infrastructuur verminderen en oude systemen verwijderen

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

Voor Sophos Firewall-beheerders 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 als daardoor de complexiteit afneemt: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, rapportage en centraal beheer moeten zo goed mogelijk op elkaar worden afgestemd.
• Documenteren welke diensten echt vanaf het internet bereikbaar moeten zijn.

Het doel is niet om zoveel mogelijk in één product te stoppen. Het doel is om blinde oude lasten te vermijden. Een kleine, actuele en goed gecontroleerde infrastructuur is bijna altijd veiliger dan een grote, historisch gegroeide omgeving met veel “dat was altijd 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 het WAN bereikbaar moeten zijn. Als remote-administratie noodzakelijk is, zou dit via Sophos Central, een speciaal managementnetwerk, ZTNA of een andere gecontroleerde weg moeten gebeuren.

Ik zie in klantomgevingen steeds weer dat niet de meest gecompliceerde aanvalstechniek het probleem is, maar een oud beheerdersaccount, een historisch gegroeid portaal of een “tijdelijke” uitzondering die nooit meer is verwijderd. Precies zulke plekken horen in een regelmatig firewall-review.

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

• MFA voor beheerders activeren, vooral voor de standaardbeheerder en alle accounts met uitgebreide rechten.
• MFA voor VPN- en portaal-aanmeldingen afdwingen, als dergelijke toegangen nog worden gebruikt.
• WAN-toegang tot Admin Console en User Portal vermijden of sterk beperken tot specifieke bronnetwerken.
• Sterke wachtwoordregels voor gebruikers en beheerders configureren.
• SSH beveiligen, idealiter met public-key-authenticatie en zonder brede WAN-bereikbaarheid.
• Centrale back-ups activeren en back-up-toegang beschermen, omdat configuratieback-ups gevoelige informatie kunnen bevatten.
• Meldingen en logging activeren, zodat beveiligingsrelevante gebeurtenissen niet in de operatie verloren gaan.

Het punt met de back-ups wordt vaak onderschat. Een firewall-back-up bevat niet alleen onschuldige instellingen, maar ook informatie over netwerken, regels, certificaten, VPN’s en interne structuren. Daarom moeten back-ups versleuteld, gecontroleerd opgeslagen en regelmatig getest worden.

Device Access en Local Service ACL bewust instellen

Als men over WAN-toegang spreekt, moet men bij de Sophos Firewall specifiek over Device Access en Local Service ACL spreken. In de Device-Access-matrix wordt per zone vastgesteld welke lokale firewall-diensten bereikbaar zijn: HTTPS-admin, User Portal, SSH, Ping, DNS, Captive Portal, VPN-portalen en andere diensten.

Best practice is hier heel eenvoudig, maar effectief: vanuit de WAN-zone moet alleen bereikbaar zijn wat echt nodig is. Beheertoegang, SSH en User Portal horen niet breed op het internet. Als uitzonderingen nodig zijn, moeten ze via Local Service ACL Exception Rules worden beperkt tot specifieke bron-IP-adressen of managementnetwerken.

Landenregels als minimale bescherming

Als vaste bron-IP-adressen niet realistisch zijn, raad ik aan om ten minste met landenregels te werken. Toegang alleen vanuit enkele relevante landen is nog steeds aanzienlijk beter dan wereldwijde bereikbaarheid. Alternatief kan men landen blokkeren waarmee het bedrijf geen verband heeft en waar ook geen medewerkers of beheerders zich doorgaans bevinden. Dit is geen vervanging voor MFA, sterke rollen en schone ACL’s, maar het vermindert onnodig lawaai en veel geautomatiseerde toegangspogingen.

Uit mijn ervaring is dit een van de eerste punten in elke firewall-review. Veel risicovolle configuraties ontstaan niet door kwade opzet, maar omdat een dienst voor een migratie, een supportgeval of een test kort werd geopend en later nooit meer werd gesloten. Precies zulke details onderscheiden een firewall die gewoon werkt van een firewall die echt goed wordt beheerd.

Loginbeveiliging en beheerdersrollen controleren

MFA is belangrijk, maar de loginlaag bestaat uit meer dan een tweede factor. Beheerders moeten eigen, traceerbare accounts gebruiken en niet permanent met een gedeelde volbeheerder werken. Rollen gebaseerde rechten helpen om support-, rapportage- of helpdesktoegangen van de eigenlijke firewallbeheerder te scheiden.

Daarnaast moeten mislukte inlogpogingen worden beperkt, sessies netjes worden beëindigd en beheertoegangen worden beperkt tot gedefinieerde netwerken. 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 het principe van de minste bevoegdheid.

Patch-moeheid vermijden: Hotfixes moeten snel werken

Patching is een van de onderwerpen waarbij theorie en praktijk ver uit elkaar liggen. Natuurlijk weet elke beheerder dat firmware-updates belangrijk zijn. In de realiteit betekenen ze echter onderhoudsvensters, risicoafweging, HA-planning, communicatie met afdelingen en soms ook downtime. Dit leidt tot patch-moeheid: updates worden uitgesteld omdat ze arbeidsintensief zijn.

Precies hier is de tijdcomponent gevaarlijk. Identiteitsaanvallen zijn inmiddels de dominante hoofdoorzaak, maar kwetsbaarheidsuitbuiting blijft een reëel vector, vooral bij edge-systemen zoals firewalls, VPN’s en andere internetnabije diensten. Het Sophos Active Adversary Report 2026 noemt als voorbeeld CVE-2024-40766 in SonicOS, die in een groot deel van de bevestigde exploitgevallen in de dataset zichtbaar was. Tegelijkertijd lag de mediane tijd tussen fabrikantadvies of patch en waargenomen uitbuiting op 322 dagen. Dat is een vrij duidelijk signaal: patch-moeheid is geen abstract operationeel probleem, maar een aanvalsvlak.

Sophos Firewall zet hier een belangrijke stap: Automated Hotfixes maken veiligheidsrelevante live-patches mogelijk zonder klassiek onderhoudsvenster. Voor beheerders is dat enorm waardevol, omdat de kritische beschermingswerking niet pas optreedt wanneer het volgende vrije onderhoudsvenster komt.

Toch geldt: hotfixes vervangen geen schone updatestrategie. Hotfixes dichten de gevaarlijke kloof tussen ontdekte kwetsbaarheid en regulier firmware-upgrade. De best practice luidt daarom:

• Hotfixes geactiveerd laten.
• Firmwareversies regelmatig controleren en de Firmware-Update-Voorbereiding documenteren.
• Upgradepaden en compatibiliteit vooraf lezen.
• Back-ups en rollback-plan voorbereiden.
• HA-cluster en remote locaties apart plannen.

VPN niet als bewijs van vertrouwen behandelen

Remote Access VPN was jarenlang de standaard. Het probleem: klassiek VPN denkt vaak in netwerken, niet in applicaties. Wie succesvol is verbonden, bevindt zich vanuit het perspectief van veel omgevingen al in een vertrouwde zone. Als het eindapparaat is gecompromitteerd of inloggegevens zijn gestolen, kan een aanvaller zich van daaruit verder verplaatsen.

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

ZTNA is geen automatische Sophos-beslissing

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 naam van de fabrikant, maar of identiteit, apparaatstatus, applicatietoegang, logging en operatie goed samenwerken.

Dit is ook mijn fundamentele houding in Sophos-projecten: ik kies niet automatisch voor Sophos bij elk onderwerp. Als een oplossing van een derde partij bij ZTNA, SSE, Threat Intelligence, SIEM of NDR beter past, is dat precies de betere aanbeveling. Een goede beveiligingsarchitectuur ontstaat niet door maximale fabrikantbinding, maar door goed geïntegreerde componenten met duidelijke verantwoordelijkheid.

Voor puur Sophos-omgevingen kan de integratie toch interessant zijn, omdat ZTNA, Endpoint, Firewall en Sophos Central gezamenlijk kunnen worden gebruikt. Een gecompromitteerd of niet-conform apparaat kan de toegang verliezen zonder dat een beheerder eerst handmatig firewallregels moet aanpassen. Het is ook de moeite waard om te kijken naar het ZTNA Gateway op de Sophos Firewall. Bij gemengde of grotere omgevingen moet men echter bewust vergelijken en niet automatisch de bestaande firewallfabrikant als ZTNA-platform kiezen.

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

• MFA voor elke remote-access-toegang afdwingen.
• Oude of ongebruikte VPN-gebruikers verwijderen.
• Groepenimport 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 web-apps, RDP, SSH, beheerportalen en zakelijke applicaties.

Segmentatie tegen laterale beweging

Als aanvallers met geldige inloggegevens of via een blootgestelde dienst binnenkomen, bepaalt de interne segmentatie hoe ver ze zich kunnen verplaatsen. Een firewall mag daarom niet alleen een perimeter-gateway zijn, maar moet interne zones goed scheiden: gebruikers, servers, beheer, IoT, gastnetwerk, productie, back-up en bijzonder kritieke systemen horen niet blind in hetzelfde vertrouwensmodel.

Praktisch betekent dit: VLAN’s en zones niet alleen uit ordeliefde bouwen, maar met echte firewallregels beveiligen. Tussen gebruikers- en servernetwerken mogen alleen de benodigde applicaties worden toegestaan. Beheertoegangen horen in speciale beheernetwerken. IoT- en printernetwerken mogen niet vrij met servers communiceren. Back-ups en domeincontrollers verdienen bijzonder restrictieve regels en goede logging.

Precies hier sluit de cirkel zich naar de uitspraak “aanvallers loggen zich in”. Als een gecompromitteerd account wel toegang heeft tot een applicatie, 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 is het nog steeds mogelijk, maar aanzienlijk lastiger, omdat applicaties, uitzonderingen en historische afhankelijkheden dan eerst moeten worden ontwart.

Foutconfiguraties zichtbaar maken

Een firewall kan technisch zeer krachtig zijn en toch door verkeerde configuratie gevaarlijk worden. Te brede regels, “Any”-objecten, zwakke authenticatie, ontbrekende IPS-beleidsregels, uitgeschakelde patroonupdates of open portalen zijn typische voorbeelden. Het moeilijke daaraan: in gegroeide omgevingen ziet men dergelijke risico’s niet altijd meteen.

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 riskant zijn of afwijken van aanbevolen standaarden. De resultaten zijn naar risico geprioriteerd, leiden per klik naar de getroffen instellingen en kunnen afhankelijk van de situatie worden opgelost of bewust worden genegeerd.

Bijzonder nuttig is de Health Check voor terugkerende operationele processen:

• na een nieuwe firewall-uitrol,
• na grote regelwijzigingen,
• voor en na firmware-upgrades,
• voor audits,
• na migraties van oude hardware,
• als regelmatige kwartaalcontrole.

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

Uit mijn ervaring is de Health Check vooral als lopend operationeel hulpmiddel sterk. Hij is niet alleen iets voor de eerste go-live, maar een goed startpunt voor kwartaalreviews, auditvoorbereiding en het opschonen van oude regelwerken.

Secure by Design: De firewall zelf versterken

Uit mijn ervaring zijn niet alleen beveiligingsproducten nodig, maar veilige beveiligingsproducten. 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 daarbij meerdere lagen:

• Geharde kernel en gemoderniseerde architectuur: De nieuwere Xstream-architectuur zet sterker in op isolatie, modularisering, containerisering en privilege-scheiding. Hierdoor worden bepaalde kwetsbaarheidsklassen verminderd en gevolgen door betere isolatie beperkt. Daarnaast zijn er mitigaties tegen side-channel- en CPU-kwetsbaarheden. Dit maakt het platform robuuster, maar niet immuun voor kwetsbaarheden.
• Automated Hotfixes: Veiligheidsreparaties kunnen zeer snel en zonder klassiek onderhoudsvenster worden verspreid.
• Remote Integrity Monitoring: De geïntegreerde Sophos XDR Linux Sensor kan systeemintegriteit in realtime bewaken, zoals ongeoorloofde configuratiewijzigingen, rule exports, verdachte programma-uitvoering of file tampering. Dit is echter alleen waardevol als de functie is geactiveerd, gelicenseerd, aangesloten en in de operatie ook wordt bewaakt.
• Veilig centraal beheer: Administratie kan via Sophos Central plaatsvinden, zonder managementpoorten breed op het internet te openen.
• Health Check: Risicovolle configuraties worden direct zichtbaar.
• Versleutelde back-ups: Configuratiegegevens worden beschermd overgedragen en opgeslagen.

Daarnaast zet Sophos in op de proactieve bewaking van de geïnstalleerde firewallbasis. Telemetrie van firewalls kan helpen om aanwijzingen voor aanvallen of manipulaties eerder te herkennen. Als een patroon zichtbaar wordt, kan Sophos klanten of partners gericht ondersteunen en hotfixes zeer snel breed uitrollen.

Deze punten zijn in het dagelijks leven minder spectaculair dan een nieuwe firewallregel of een geblokkeerde aanval in het logboek. Op de lange termijn zijn ze echter cruciaal. Een gehard product vermindert de kans dat de firewall zelf een toegangspunt wordt. Het vervangt echter geen schone patch-proces, geen monitoring en geen regelmatige configuratiecontrole.

Waarop men bij de firewallfabrikant moet letten

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

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

Pijler 2: Bescherming tijdens de aanval

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

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 er meer prestatie-reserve over voor Deep Packet Inspection, TLS Inspection en Zero-Day Protection.

Juist TLS Inspection is een goed voorbeeld van de balans tussen beveiliging en operatie. Zonder ontsleuteling blijft een groot deel van het moderne verkeer onzichtbaar. Met slecht geplande TLS-regels creëert men echter supportgevallen, certificaatproblemen of prestatieknelpunten. Best practice is daarom niet “alles blind ontsleutelen”, maar netjes classificeren:

• kritische gebruikersgroepen en servers eerst,
• bankieren, gezondheid, privacy en bekende problematische categorieën netjes uitsluiten,
• blokkeer- en waarschuwingspagina’s testen,
• certificaatdistributie documenteren,
• logs actief evalueren.

Mijn aanbeveling is om TLS Inspection niet als een alles-of-niets-project te starten. Beter is een nette uitrol met duidelijke gebruikersgroepen, uitzonderingen, testvensters en log-evaluatie. Zo stijgt de zichtbaarheid zonder dat de helpdesk op de eerste dag wordt overrompeld.

Ook Threat Feeds horen in dit beschermingsgebied. Dergelijke feeds helpen om bekende kwaadaardige IP’s, domeinen of URL’s direct aan de netwerkgrens te blokkeren. In nieuwere Sophos Firewall-versies zijn ze aanzienlijk sterker geïntegreerd in Active Threat Response en beschermingsmechanismen.

Bijzonder interessant worden Threat Feeds wanneer niet alleen generieke lijsten worden gebruikt, maar ook samengestelde feeds van derden met actuele context. Een voorbeeld hiervan is Cybora.io, waar kwaadaardige IP’s en domeinen uit verschillende bronnen en firewalltelemetrie tot bruikbare feeds worden samengevoegd. Hoe dergelijke feeds op firewalls kunnen worden ingezet, heb ik in het artikel Threat Intelligence Feeds voor de Firewall uitgebreider beschreven.

Ook hier geldt: Threat Feeds moeten worden getest en geobserveerd. Te agressieve feeds, ontbrekende allowlist-processen of onduidelijke verantwoordelijkheden kunnen legitiem verkeer blokkeren en in de operatie meer schade dan nut veroorzaken. Goede feeds zijn geen vervanging voor een regelreview, maar een extra bouwsteen met eigen tuning.

Daarnaast moet men de klassieke SFOS-versterkingen niet vergeten: Spoof Protection en passende DoS-instellingen evenals Geo-IP-Blocking kunnen eenvoudige, luide of duidelijk ongewenste toegangen verminderen. Dit vervangt geen schone policy, maar het neemt de firewall onnodig lawaai weg en blokkeert aanvalspaden die in veel omgevingen geen legitiem doel hebben.

Ik raad aan hier pragmatisch te werk te gaan: eerst de grote risico’s netjes controleren, dan de beschermingsfuncties stapsgewijs aanscherpen en met logs aantonen wat echt werkt. Een overladen policy die niemand meer begrijpt, is op de lange termijn geen veiligheidswinst.

Pijler 3: Detectie en Reactie na het eerste signaal

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

Ecosystemen helpen alleen als ze passen

Synchronized Security en Security Heartbeat zijn goede ideeën: de firewall kan de status van endpoints in overweging nemen en bij gecompromitteerde apparaten communicatie beperken of blokkeren. In de realiteit gebruiken echter steeds meer bedrijven Microsoft Defender of andere endpoint-oplossingen. Dan werkt dit deel van het Sophos-ecosysteem slechts beperkt of helemaal niet. Precies 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 kan worden geïmplementeerd. Als Microsoft Defender, een andere EDR, een derde partij NDR of een extern SIEM de betere basis is, dan moet de firewall netjes in deze architectuur worden geïntegreerd. Belangrijker dan cross-selling is dat logs op de juiste plek terechtkomen, alarmen worden begrepen en iemand regelmatig controleert wat de systemen melden. Zonder log-analyse, tuning en incident-proces helpt ook de beste integratie weinig.

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

Automatisering heeft runbooks nodig

Automatisering heeft echter richtlijnen nodig. Het moet duidelijk zijn welke signalen automatisch mogen blokkeren, wie een isolatie weer opheft, hoe false positives worden behandeld en hoe dergelijke processen worden getest. Zonder runbooks, verantwoordelijkheden en regelmatige oefeningen weet anders niemand in geval van nood of een blokkering gewenst, correct of te agressief was.

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

Voor beheerders 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 beheerder dan op vrijdagavond handmatig een regel moet bouwen, is de reactietijd te lang. Geautomatiseerde reactie betekent niet dat mensen worden vervangen. Bedoeld is dat de eerste indamming onmiddellijk plaatsvindt en het team daarna netjes kan onderzoeken.

Juist in kleinere IT-teams is deze automatisering waardevol. Niet elk bedrijf heeft 24/7 een firewallspecialist beschikbaar. Als Endpoint, Firewall, NDR, MDR en SIEM fabrikantoverschrijdend zinvol samenwerken, wint men tijd, en tijd is bij actieve aanvallen vaak de belangrijkste factor.

Praktische checklist voor Sophos Firewall-beheerders

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

Direct controleren

• Zijn hotfixes geactiveerd?
• Is MFA voor beheerders actief?
• Zijn Web Admin Console en User Portal vanaf het WAN bereikbaar?
• Zijn SSL VPN of IPsec Remote Access met MFA beschermd?
• Zijn er nog ongebruikte lokale beheerdersaccounts?
• Zijn back-ups gepland, versleuteld en getest?
• Zijn Device Access en Local Service ACL tot het minimum beperkt?
• Zijn WAN-bereikbare diensten ten minste beperkt tot relevante landen of bekende bronnetwerken?
• Zijn patroonupdates en firmwareversies actueel?

Binnen de komende weken

• Health Check uitvoeren en bevindingen prioriteren.
• Oude firewallregels met “Any” bij bron, doel of service controleren.
• Beheerdersrollen, loginbeveiliging, sessietime-outs en brute-force-bescherming controleren.
• Blootgestelde diensten zoals RDP, SSH, webservers, portalen en NAT-regels inventariseren.
• Interne zones en VLAN-regels tegen laterale beweging 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 naar 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 beheer, rapportage en alarmering standaardiseren, bijvoorbeeld via Sophos Central, SIEM of bestaande beveiligingsplatforms.
• Syslog-/SIEM-export en log-retentie voor forensische analyses definiëren.
• MDR/XDR/NDR-signalen in het incident-proces integreren.
• Terugkerende firewall-versterkingsreviews 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 worden versterkt, gepatcht, gecontroleerd en in de detectie worden geïntegreerd.

Mijn aanbeveling na vele jaren met Sophos Firewall is daarom duidelijk: een moderne firewall moet vandaag meer zijn dan een beveiligingsproduct. Doorslaggevend zijn een veilig ontwerp, zichtbare foutconfiguraties, snelle veiligheidsreparaties en een reactie die in geval van nood samenwerkt met Endpoint, NDR, XDR en MDR.

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

Ondersteuning door Avanet

Als er ondersteuning nodig is bij het versterken van een Sophos Firewall, kan men contact opnemen met Avanet. Ik ondersteun als langdurige Sophos-specialist bij firewall-audits, Health Check-reviews, regelwerkopruiming, remote access en ZTNA/SSE-planning, updatestrategieën en trainingen voor IT-teams.

Juist een externe blik op managementtoegangen, VPN-configuratie, oude regels, WAN-blootgestelde diensten en update-status loont zich vaak. Veel risico’s ontstaan niet door een enkele verkeerde instelling, maar door gegroeide uitzonderingen die in het dagelijks leven niemand meer in twijfel trekt.

Bij interesse volstaat een kort bericht via het contactformulier. Daarna kan gezamenlijk worden bepaald of een compact firewall-review, 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 elimineren
• 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