2 november 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Managed firewall: wat de aanbieder beheert, welke fouten de dienst moet voorkomen en hoe u er een beoordeelt
Vrijwel elke interne penetratietest die wij uitvoeren, loopt uiteindelijk door een firewallregel waarvan niemand zich herinnert dat hij is goedgekeurd. Managed firewall, oftewel firewall beheer uitbesteden, bestaat om dat te voorkomen: een aanbieder is eigenaar van de regellevenscyclus, het patchen, de bewaking en het bewijs, zodat uw firewalls het beleid afdwingen dat u denkt dat zij afdwingen.
Wat managed firewall is
Managed firewall is een uitbesteed beheermodel waarbij een securityaanbieder de dagelijkse verantwoordelijkheid voor uw firewalls overneemt: het beleid ontwerpen, elke regelwijziging doorvoeren en documenteren, firmware en software patchen, gezondheid en verkeer bewaken, logs naar een SIEM sturen, de regelset op een vaste cadans beoordelen en het bewijs opleveren waar auditors onder PCI DSS, HIPAA, SOC 2, NIS2 of ISO 27001 om vragen. De hardware of cloudinstantie kan van u zijn of van de aanbieder. Wat verandert, is dat een team met naam verantwoordelijk is voor een firewall die elke dag een geschreven beleid afdwingt, en niet alleen op de dag van installatie.
De behoefte is om twee redenen gegroeid. Ten eerste bestaat het firewalllandschap niet meer uit drie appliances aan de rand van het datacenter; het bestaat uit next-generation firewalls op locaties, virtuele firewalls in AWS, Azure en Google Cloud, hostgebonden regels en een firewall-as-a-service-laag voor thuiswerkers, elk met een eigen console en regelsyntaxis. Ten tweede is het randapparaat zelf een primair doelwit geworden. Internet-facing firewalls en VPN-concentrators kwamen in 2024 en 2025 veelvuldig voor in de Known Exploited Vulnerabilities-catalogus van het Amerikaanse CISA, en een ongepatchte beheerinterface is een van de betrouwbaarste manieren om een netwerk binnen te komen. Firewallbeheer is daarmee zowel een hygiëne- als een patchprobleem.
Wat een managed firewall-dienst omvat
Een voorstel dat alleen bewaking en ticketafhandeling dekt, is een helpdesk, geen beheerde dienst.
Beleidsontwerp en segmentatie
Bedrijfseisen vertalen naar een zonemodel en een default-deny-beleid: welke netwerken met welke mogen praten, over welke diensten, met de kaarthouder-, patiënt- of OT-omgeving geïsoleerd van alles wat haar niet nodig heeft.
Regellevenscyclus en wijzigingsbeheer
Elke regel komt binnen via een aanvraag met eigenaar, zakelijke onderbouwing, risicobeoordeling en einddatum; wordt doorgevoerd in een wijzigingsvenster; wordt gedocumenteerd; en wordt verwijderd wanneer de onderbouwing vervalt. Geen regel bestaat zonder reden die u aan een auditor kunt tonen.
Patchen, firmware en hardening
Leveranciersadviezen en CISA-waarschuwingen voor uw platforms volgen, updates testen en binnen een afgesproken venster toepassen, beheertoegang harden (MFA, apart beheernetwerk, geen blootstelling aan internet) en geteste configuratieback-ups bijhouden.
Bewaking en incidentafhandeling
Apparaatgezondheid, doorvoer, VPN-tunnels, high-availability-status en patronen in geweigerd verkeer 24/7 volgen, met een pad naar uw incident response-proces wanneer een firewallgebeurtenis deel is van iets groters.
Logging naar de SIEM en rapportage
Allow- en deny-logs met de juiste detailgraad doorsturen naar uw SIEM, zodat firewalldata gecorreleerd kan worden met identiteits- en endpointgebeurtenissen, plus maandelijkse servicerapporten en bewijsdossiers per kader.
Periodieke regelsetreview en opschoning
Een gestructureerde review minimaal elk halfjaar: ongebruikte regels, overschaduwde en dubbele regels, te brede regels, verlopen uitzonderingen en ongedocumenteerde NAT, elk met een vastgelegd besluit.
NGFW, klassieke firewall, cloudfirewall en FWaaS vergeleken
De meeste organisaties draaien drie van deze vier tegelijk. Een beheerde dienst dekt ze onder één beleid en één wijzigingsproces.
| Aspect | Klassieke stateful firewall | Next-generation firewall (NGFW) | Cloud-native firewall | Firewall as a service (FWaaS) |
|---|---|---|---|---|
| Waar hij staat | Netwerkperimeter of tussen segmenten, fysieke of virtuele appliance | Perimeter, datacenter en locatieranden, fysiek of virtueel | Binnen AWS, Azure of Google Cloud als beheerde dienst of virtuele appliance uit de marketplace | In de cloud van de aanbieder, tussen gebruikers of vestigingen en internet of interne applicaties |
| Wat hij inspecteert | IP-adressen, poorten, protocollen en verbindingsstatus | Applicaties, gebruikers, URL's, ontsleutelde TLS, bestanden, met intrusion prevention en threat feeds | Cloudnetwerkstromen, security groups en netwerk-ACL's, vaak met laag-7-regels en DNS-filtering | Gebruikers- en apparaatidentiteit, applicatie, inhoud, meestal gecombineerd met secure web gateway en zero-trust-toegang |
| Gebruikelijk beheervlak | Regeltabel per apparaat, weinig centraal beheer | Centrale beheerconsole, beleidsobjecten, apparaatgroepen | Cloudconsole, infrastructure as code, beleid per account of per VPC | Eén cloudbeleid voor alle gebruikers en locaties |
| Meest geziene fout bij testen | Duizenden opgestapelde regels die niemand durft te verwijderen | Rijke functies gelicentieerd maar nooit ingeschakeld; ontsleuteling uit | Security groups tijdens een uitrol wijd opengezet en nooit meer vernauwd | Toegang tot interne applicaties breed verleend; beleidsdrift tussen identiteits- en netwerkteam |
| Waar beheer het meest toevoegt | Regelopschoning, migratieplanning, logging | Beleidsontwerp, tuning van preventiefuncties, patchen, ontsleutelingsstrategie | Governance over wie wat mag wijzigen, driftdetectie, logging naar SIEM | Afstemming identiteit en beleid, uitzonderingsbeheer, rapportage |
| Meest geschikt voor | Legacy-segmenten in afwachting van migratie | Locaties, datacenters, OT-grenzen, PCI-omgevingen | Cloud-first workloads, omgevingen met veel accounts | Verspreide werknemers, vestigingen zonder lokale hardware |
De firewallfouten die een beheerde dienst moet voorkomen
De patronen die onze testers het vaakst aantreffen in interne en externe penetratietesten, hier beschreven als maatregel die de dienst in stand moet houden, niet als techniek.
1. Permit-any-regels en te brede objecten
Een regel die elke bron naar elke bestemming over elke dienst toestaat, of een adresgroep 'servers' die het halve netwerk bevat, maakt van een firewall een router. De dienst moet least privilege per regel afdwingen, met expliciete bronnen, bestemmingen en diensten, en elke regel markeren waarvan de reikwijdte de gedocumenteerde onderbouwing overschrijdt.
2. Verouderde, overschaduwde en verlopen regels
Regels voor projecten die jaren geleden eindigden, regels die nooit matchen omdat een eerdere regel het verkeer al vangt, en 'tijdelijke' uitzonderingen zonder einddatum. De dienst moet hittellingen en einddata bijhouden en regels bij elke review verwijderen of opnieuw onderbouwen.
3. Vlakke segmentatie
Werkplekken die elke server kunnen bereiken, servers die domeincontrollers op elke poort kunnen bereiken, OT-netwerken gekoppeld aan het kantoornetwerk. De dienst moet eigenaar zijn van een zonemodel, dit afdwingen met deny-by-default tussen zones en het laten testen, en daar komt onze netwerkpenetratietest in beeld.
4. Blootgestelde beheerinterfaces
Een beheerpagina of SSH-dienst van een firewall die bereikbaar is vanaf internet, of vanaf het algemene gebruikersnetwerk, is de misconfiguratie met de grootste gevolgen die wij zien. De dienst moet beheertoegang beperken tot een apart beheernetwerk met MFA en die beperking van buitenaf verifiëren.
5. Geen uitgaande filtering
De meeste firewalls zijn ingericht om inkomend verkeer te stoppen en alles naar buiten te laten. Aanvallers vertrouwen daarop voor command-and-control en gegevensdiefstal. De dienst moet uitgaand beleid per bestemming en dienst inrichten, met DNS- en webverkeer verplicht via geïnspecteerde paden.
6. Ongepatchte platforms en zwakke beheerhygiëne
Firmware die jaren achterloopt, gedeelde beheerdersaccounts, standaardwachtwoorden op een secundaire interface, configuratieback-ups onversleuteld opgeslagen. De dienst moet eigenaar zijn van de patchcadans, persoonlijke accounts met MFA afdwingen en de configuratie als gevoelig bedrijfsmiddel beschermen.
7. Logging uitgeschakeld of nooit verzameld
Een firewall die alleen weigeringen logt, of naar een lokale buffer die elke paar uur overschrijft, kan een onderzoek niet ondersteunen. De dienst moet allow- en deny-gebeurtenissen van de relevante regels naar uw SIEM sturen en opmerken wanneer die logstroom stopt.
Reviewcadans, PCI DSS Requirement 1 en NIST SP 800-41
De duidelijkste externe norm voor firewallbeheer is PCI DSS v4.0.1 Requirement 1, Install and Maintain Network Security Controls. Zij eist dat alle toegestane diensten, protocollen en poorten zijn geïdentificeerd, goedgekeurd en van een zakelijke noodzaak voorzien (1.2.5); dat de configuratie van netwerkbeveiligingsmaatregelen minimaal elk halfjaar wordt beoordeeld op relevantie en effectiviteit (1.2.7); dat netwerktoegang van en naar de kaarthouderomgeving is beperkt (1.3); dat verbindingen tussen vertrouwde en niet-vertrouwde netwerken worden beheerst, met inkomend verkeer beperkt tot het noodzakelijke (1.4); en dat risico's van apparaten die zowel met niet-vertrouwde netwerken als met de kaarthouderomgeving verbinden, worden beperkt (1.5). Een managed firewall-dienst die is gebouwd rond een gedocumenteerde halfjaarlijkse review met eigenaren en besluiten, voldoet aan de moeilijkste van deze eisen door haar opzet.
NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy, blijft de referentie die Amerikaanse auditors het vaakst aanhalen. De richtlijnen vallen direct samen met de dienst: schrijf het firewallbeleid voordat u regels schrijft, weiger standaard alle verkeer dat niet expliciet is toegestaan, bescherm het beheervlak, log en beoordeel, en plan uitrol gefaseerd met terugvaloptie. NIST SP 800-207 over zero trust-architectuur trekt de lijn door: de firewall wordt een van meerdere beleidshandhavingspunten en zijn regels moeten aansluiten op identiteitsgebaseerde toegangsbesluiten in plaats van die te vervangen. Andere kaders wijzen dezelfde richting: NIST SP 800-171 Revision 3 (en daarmee CMMC 2.0 Level 2) eist bewaking en beheersing van communicatie op externe en belangrijke interne grenzen en standaardweigering van netwerkverkeer; ISO 27001:2022 maatregelen A.8.20 tot A.8.22 dekken netwerkbeveiliging, netwerkdiensten en netwerkscheiding; NIS2 artikel 21(2) eist beveiliging bij onderhoud van netwerk- en informatiesystemen en toegangsbeleid; en DORA artikel 9 eist netwerkbeveiligingsbeheer inclusief segmentatie.
Hoe managed firewall past bij segmentatie en zero trust
Een firewall is geen zero trust-strategie, maar zero trust werkt niet zonder. Welk volwassenheidsmodel u ook volgt, de praktische eerste stappen zijn nog altijd netwerksegmentatie en uitgaande filtering, en beide leven in het firewalllandschap. Een managed firewall-dienst geeft u de discipline om die stappen te zetten: een zonemodel waarover identiteits-, cloud- en netwerkteam het eens zijn, consequent afgedwongen over NGFW, cloudfirewall en FWaaS, en geverifieerd door testen.
Verificatie is het deel dat de meeste programma's missen. Een segmentatiebeleid dat in de console correct lijkt, kan ongedaan worden gemaakt door één vergeten regel, een host met twee netwerkkaarten of een cloud security group. Daarom is segmentatietesten een vast onderdeel van onze interne penetratietesten, en daarom eist PCI DSS v4.0.1 Requirement 11.4.5 dat segmentatiemaatregelen minimaal jaarlijks worden getest (elk halfjaar voor dienstverleners onder 11.4.6). De beheerde dienst sluit de cirkel: bevindingen uit de test worden regelwijzigingen, en de volgende test bevestigt ze.
Vragen aan een managed firewall-aanbieder
De antwoorden tonen of u verantwoordelijkheid koopt of een ticketwachtrij.
- Welke platforms beheert u (NGFW-leveranciers, cloud-native firewalls, FWaaS) en onder één beleidsmodel of meerdere?
- Hoe verloopt een regelaanvraag: wie keurt goed, welke risicobeoordeling wordt toegepast, hoe wordt de einddatum afgedwongen en wat is het wijzigingsvenster?
- Hoe vaak wordt de volledige regelset beoordeeld, wat legt de review vast en kunnen wij een voorbeeldrapport zien?
- Wat is uw patchtoezegging voor kritieke firewallkwetsbaarheden, en hoe gaat u om met een noodadvies buiten het normale venster?
- Hoe is beheertoegang beveiligd: apart beheernetwerk, MFA, persoonlijke accounts, sessielogging, en kunt u dat van buitenaf aantonen?
- Welke logs worden naar onze SIEM doorgestuurd, met welke detailgraad, en hoe merkt u dat de logstroom is gestopt?
- Wat is het escalatiepad wanneer een firewallgebeurtenis deel is van een breder incident, en hoe werkt u samen met onze MDR-aanbieder of incident response-retainer?
- Welk compliancebewijs is standaard: reviewverslagen onder PCI DSS Requirement 1, wijzigingshistorie, resultaten van segmentatietesten?
- Hoe wordt de dienst geprijsd (per apparaat, per regelwijziging, per locatie) en wat gebeurt er bij exit met beleidsdocumentatie en wijzigingshistorie?
Waar HackersHub past: de firewall testen en zijn logs bewaken
HackersHub is een offensive-securitybedrijf uit Amsterdam dat ook managed security levert aan enterprise-klanten in de EU en de Verenigde Staten, op afstand en op locatie waar een opdracht dat vraagt. Wij beheren uw firewalls niet. Onze rol ligt aan weerszijden daarvan: netwerkpenetratietesten die de regelset en de segmentatie vanuit de positie van de aanvaller valideren, en managed security (24/7-bewaking, SIEM- en EDR-beheer) die de logs van uw firewalls verwerkt en omzet in detecties. De uitleg over managed SIEM en de MSSP-contractchecklist behandelen die aangrenzende keuzes.
Wat wij toevoegen, is de blik van de aanvaller op een regelset. Onze testers hebben minimaal OSCP, met OSWE- en CREST-gecertificeerde testers in het team, en de zeven foutpatronen hierboven komen uit hun opdrachtnotities, niet uit een leveranciersbrochure. In een netwerkpenetratietest wordt elke relevante regel langs één vraag gelegd: wat kan ik hiermee bereiken dat ik eerder niet kon bereiken? De bevindingen gaan als concrete regelwijzigingen terug naar uw firewallteam of uw managed firewall-aanbieder, en de volgende test bevestigt dat zij zijn doorgevoerd.
Veelgestelde vragen
Gerelateerde gidsen over managed security en netwerktesten
- Managed security services van HackersHub
- Managed SIEM: wat de dienst omvat en hoe u inkoopt
- Netwerkpenetratietest: verifieer uw segmentatie
- Penetratietest laten uitvoeren door HackersHub
- MSSP-contractchecklist: wat u op papier wilt hebben
- Wat is SOC as a service?
- Externe vs interne penetratietest
- PCI DSS pentest: Requirement 11.4 uitgelegd
Dwingen uw firewalls het beleid af dat u denkt?
Wij testen uw regelsets en segmentatie vanaf de kant van de aanvaller, en ons managed security-team zet de logs van uw firewalls om in detecties. Praat met een expert.