Firewallregelbeoordeling voor ISO 27001, NIS2, DORA en GDPR
Het is 07:42 op maandagochtend. De CISO van een groeiende SaaS- en FinTech-aanbieder bekijkt drie afzonderlijke berichten.
Het eerste komt van het SOC. Een gecompromitteerde ontwikkelaarswerkplek heeft ’s nachts geprobeerd verbinding te maken met een intern databasesubnet. Het verkeer is geblokkeerd, maar de analist wil bevestiging dat de firewallregel bewust is ingericht, actueel is en is goedgekeurd.
Het tweede komt van een grote zakelijke klant. Die wil bewijsmateriaal dat productie-, ontwikkel-, bedrijfs- en supportomgevingen zijn gesegmenteerd, dat firewallregels periodiek worden beoordeeld en dat uitzonderingen verlopen.
Het derde komt van de compliancemanager. De organisatie valt als belangrijke digitale aanbieder binnen de reikwijdte van NIS2, heeft GDPR-verantwoordelijkheden als verwerker en bedient financiële klanten die om DORA-achtig bewijsmateriaal voor ICT-risico’s vragen. Het bestuursorgaan wil weten of hetzelfde ISO/IEC 27001:2022-bewijsmateriaal alle drie kan afdekken.
Daarna komt de post-incidentreview binnen. Een ontwikkelserver was tijdens een wijziging laat op de avond bijna vanaf internet bereikbaar geworden. Er zijn geen klantgegevens verloren gegaan, maar het forensische team ontdekte iets ernstigers dan de initiële fout: een vijf jaar oude firewallregel voor een “tijdelijke test” stond nog steeds ruime laterale beweging tussen ontwikkeling en productie toe. Als een aanvaller toegang had verkregen, had het netwerk weinig weerstand geboden.
Dat is het moment waarop veel organisaties een pijnlijke waarheid ontdekken. Ze hebben misschien firewalls, VLAN’s, cloud-securitygroups en diagrammen, maar geen governance over segmentatiezones, eigenaarschap van regels, tijdelijke toegang, wijzigingsgoedkeuringen, hercertificering en auditbewijsmateriaal.
In 2026 is “we hebben een firewall” geen verdedigbaar antwoord. Auditors, toezichthouders, klanten en verzekeraars willen bewijs dat netwerken bewust zijn gescheiden, dat verkeer wordt beheerst op basis van zakelijke noodzaak, dat risicovolle uitzonderingen worden beheerst en dat logboeken aantonen dat de beheersmaatregelen werken.
Waarom firewallgovernance nu een bestuurskwestie is
Netwerksegmentatie werd vroeger behandeld als een technisch engineeringonderwerp. Infrastructuurteams waren eigenaar van VLAN’s, firewallbeheerders onderhielden regelsets, cloudteams beheerden securitygroups en de compliancefunctie zag tijdens audits alleen een diagram.
Dat operationele model werkt niet meer.
De NIS2-richtlijn vereist dat essentiële en belangrijke entiteiten passende en evenredige technische, operationele en organisatorische maatregelen implementeren om risico’s voor netwerk- en informatiesystemen te beheersen. Article 21 omvat beleid voor risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, beveiliging bij verwerving en onderhoud, beoordeling van de doeltreffendheid, cyberbeveiligingsbasishygiëne, toegangscontrole en beheer van bedrijfsmiddelen. Bestuursorganen moeten deze maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en erop toezien.
DORA is vanaf 17 januari 2025 van toepassing op veel financiële entiteiten en maakt ICT-risicobeheer tot een bestuurde en gedocumenteerde discipline. Articles 5, 6 en 8 vereisen governance, een ICT-risicobeheerkader en identificatie van door ICT ondersteunde bedrijfsfuncties, informatieactiva, ICT-activa, afhankelijkheden, kritieke activa en interconnecties. Articles 9, 10 en 11 behandelen bescherming, preventie, detectie, respons en herstel. Articles 24 tot en met 27 vereisen tests van digitale operationele weerbaarheid, waaronder geavanceerde tests voor bepaalde entiteiten. Daardoor is segmentatie een weerbaarheidsvraagstuk, niet alleen een firewallvraagstuk.
GDPR voegt de laag van privacyverantwoording toe. Article 32 vereist passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen, met inbegrip van vertrouwelijkheid, integriteit, beschikbaarheid en weerbaarheid. Article 5(1)(f) vereist integriteit en vertrouwelijkheid, en Article 5(2) vereist verantwoordingsplicht. Als systemen met persoonsgegevens bereikbaar zijn vanaf gecompromitteerde endpoints, gastnetwerken of onbeheerde paden van derden, kan een toezichthoudende autoriteit vragen waarom die paden bestonden.
ISO/IEC 27001:2022 biedt de managementsysteemfundering die deze verplichtingen verbindt. De norm vereist scope, eisen van belanghebbenden, risicobeoordeling, risicobehandeling, een Verklaring van Toepasselijkheid, operationele planning en beheersing, leiderschapsverantwoordelijkheid, meetbare doelstellingen, gedocumenteerde informatie en voortdurende verbetering. Annex A, ondersteund door de richtlijnen van ISO/IEC 27002:2022, omvat de beheersingsgebieden die nodig zijn voor leveranciersrisico, in de cloud gehoste diensten, logging, monitoring, beveiligde architectuur, scheiding van omgevingen en wijzigingsbeheer.
De kern is eenvoudig: netwerksegmentatie en firewallregelbeoordeling zijn inmiddels bewijsmateriaal van governance.
Het operationele patroon van Clarysec: 8.20, 8.22 en 8.32
Clarysec behandelt segmentatie en firewallbeoordeling als één operationeel patroon over ISO/IEC 27002:2022-beheersmaatregelen heen, niet als geïsoleerde technische taken.
De drie primaire beheersmaatregelen zijn:
| ISO/IEC 27002:2022-gebied | Governancevraag | Bewijsmateriaal dat auditors verwachten |
|---|---|---|
| 8.20 Netwerkbeveiliging | Zijn netwerken ontworpen, beheerd, bewaakt en beschermd op basis van risico? | Architectuurdiagrammen, firewallstandaarden, procedures voor veilige netwerken, monitoringlogboeken, IDS/IPS-bewijsmateriaal, voorbeelden van VPN- en cloudnetwerkconfiguraties |
| 8.22 Scheiding van netwerken | Zijn zones gescheiden op basis van gevoeligheid, functie en vertrouwensniveau? | Zoneringsmodel, gegevensstroommatrix, VLAN- en subnetontwerp, DMZ-grenzen, interzone-firewallregels, resultaten van segmentatietests |
| 8.32 Wijzigingsbeheer | Worden regelwijzigingen geëvalueerd, goedgekeurd, getest, gelogd en beoordeeld? | Wijzigingstickets, risicobeoordelingen, goedkeuringen, rollbackplannen, post-implementatiereviews, registraties van noodwijzigingen |
In Zenith Blueprint: een 30-stappenroadmap voor auditors [ZB] plaatst Clarysec netwerkbeveiliging in de fase Controls in Action, stap 20: beheersmaatregelen 8.18 tot en met 8.26. De gids formuleert de kernvraag voor de audit helder:
“In de kern vereist deze beheersmaatregel dat organisaties ervoor zorgen dat netwerken architectonisch veilig zijn, en niet pas achteraf worden beveiligd door firewalls of antivirus toe te voegen. Dat betekent strategisch nadenken over netwerksegmentatie, toegangscontrole, encryptie tijdens transport, monitoring en defense-in-depth. Het begint met een eenvoudige vraag: wie en wat communiceert met elkaar, en hoort dat zo te zijn?”
Die vraag, “wie en wat communiceert met elkaar, en hoort dat zo te zijn?”, is het beste praktische vertrekpunt voor firewallregelbeoordeling. Ze haalt het gesprek weg bij duizenden cryptische ACL-regels en brengt het terug naar stromen met een zakelijke rechtvaardiging.
Dezelfde Zenith Blueprint instrueert teams om netwerkarchitectuur te beoordelen door te verifiëren dat firewallregels, IPS/IDS en configuraties voor toegang op afstand actueel en gehard zijn, en te bevestigen dat cloud-securitygroups, routering en VPC- of subnetregels overeenkomen met de beoogde architectuur. Ook vermeldt de gids dat auditors een document inzake netwerkbeveiligingsarchitectuur verwachten waarin firewalls, VPN-gateways, DMZ-zones, VLAN-scheiding en vertrouwensgrenzen zichtbaar zijn.
Voor wijzigingsbeheer plaatst de Zenith Blueprint ISO/IEC 27002:2022-beheersmaatregel 8.32 in de fase Controls in Action, stap 21: beheersmaatregelen 8.27 tot en met 8.34, en benadrukt waarom firewallgovernance faalt wanneer wijzigingsbeheer zwak is:
“Deze beheersmaatregel erkent een harde waarheid binnen IT: veel incidenten worden niet veroorzaakt door aanvallen, maar door verkeerd beheerde wijzigingen. Een firewallregel die te ruim is geopend. Een debug-instelling die ingeschakeld blijft. Een vergeten afhankelijkheid na een migratie.”
Precies zo worden tijdelijke firewallopeningen permanente aanvalspaden.
Hoe goede netwerksegmentatie eruitziet
Een volwassen segmentatieprogramma heeft vier lagen.
Ten eerste is er een zoneringsmodel. Zones zijn geen willekeurige subnetten. Het zijn vertrouwensgrenzen die zijn afgestemd op bedrijfsfunctie en gegevensgevoeligheid, zoals een internetgerichte DMZ, productielaag voor applicaties, productielaag voor databases, bedrijfsgebruikersnetwerk, netwerk voor geprivilegieerd beheer, ontwikkelomgeving, testomgeving, back-upnetwerk, gast-wifi, OT- of IoT-zone en zone voor toegang van derden.
Ten tweede is er een gegevensstroommatrix. Voor elk zonepaar documenteert de organisatie toegestane bron, bestemming, protocol, poort, toepassing, bedrijfseigenaar, systeemeigenaar, gegevenstype, rechtvaardiging en loggingvereiste.
Ten derde is er eigenaarschap van regels. Elke firewallregel, cloud-securitygroupregel of beleid voor softwaregedefinieerde perimeter heeft een eigenaar, verloop- of hercertificeringsdatum, gekoppeld wijzigingsticket en zakelijke rechtvaardiging. “Any to any” moet als bevinding worden behandeld, tenzij het formeel als risico is geaccepteerd, tijdgebonden is en wordt ondersteund door compenserende beheersmaatregelen.
Ten vierde is er periodieke beoordeling. Beoordeling betekent meer dan één keer per jaar een firewallregelset exporteren. Het omvat hercertificering door de eigenaar, vergelijking met waargenomen verkeer, detectie van ongebruikte regels, validatie van tijdelijke uitzonderingen, beoordeling van internetblootstelling, segmentatietesten en reconciliatie met de inventaris van bedrijfsmiddelen.
Clarysec’s Beleid inzake netwerkbeveiliging [P-NS] stelt de ondernemingsbrede verwachting duidelijk vast:
“Al het interzoneverkeer moet worden beheerst door firewalls of softwaregedefinieerde perimeteroplossingen, met expliciete default-deny-configuraties.”
Uit Enterprise Policy, Beleid inzake netwerkbeveiliging, sectie “Governancevereisten,” clausule 5.2.
Hetzelfde beleid verbindt firewallwijzigingen rechtstreeks met wijzigingsbeheer:
“Elke wijziging aan firewallregelsets, routeringstabellen of configuraties van securitygroups moet het Wijzigingsbeheerbeleid (P5) van de organisatie volgen, inclusief rollbackplannen en auditlogging.”
Uit Enterprise Policy, Beleid inzake netwerkbeveiliging, sectie “Governancevereisten,” clausule 5.4.
Voor mkb-organisaties biedt Clarysec’s Beleid inzake netwerkbeveiliging-sme [P-NS-SME] hetzelfde principe in operationele termen:
“Default-denyregels moeten worden afgedwongen voor alle inkomende verbindingen, tenzij deze expliciet vereist en goedgekeurd zijn”
Uit SME Policy, Beleid inzake netwerkbeveiliging-sme, sectie “Vereisten voor beleidsimplementatie,” clausule 6.1.2.
En specifiek voor segmentatie:
“Verkeer tussen segmenten moet worden gefilterd, en toegang tussen segmenten moet het principe van minimale rechten volgen”
Uit SME Policy, Beleid inzake netwerkbeveiliging-sme, sectie “Vereisten voor beleidsimplementatie,” clausule 6.2.3.
Deze beleidsclausules stellen een auditor in staat de lijn te volgen van risico naar beheersmaatregel, van beheersmaatregel naar regel, van regel naar goedkeuring en van goedkeuring naar logboeken.
Eén bewijspakket voor ISO 27001, NIS2, DORA en GDPR
De fout die veel teams maken, is het bouwen van afzonderlijke bewijspakketten: één voor ISO/IEC 27001:2022, één voor NIS2, één voor GDPR, één voor DORA-klanten en één voor cyberverzekering.
Een betere aanpak is het bouwen van één bewijspakket voor segmentatie- en firewallgovernance dat over raamwerken heen wordt gemapt.
Zenith Controls: de gids voor cross-compliance [ZC] mapt ISO/IEC 27002:2022-beheersmaatregel 8.22 Scheiding van netwerken als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt, afgestemd op het Protect-concept voor cyberbeveiliging en de operationele capability voor systeem- en netwerkbeveiliging. De gids verbindt 8.22 met 8.20 Netwerkbeveiliging, 8.21 Beveiliging van netwerkdiensten, 8.7 Bescherming tegen malware, 8.27 Principes voor veilige systeemarchitectuur en engineering, en 8.31 Scheiding van ontwikkel-, test- en productieomgevingen.
De gids legt de NIS2-relevantie van segmentatie als volgt uit:
“Scheiding van netwerken is een direct antwoord op deze verplichtingen; het verkleint aanvalsvlakken en voorkomt laterale beweging door netwerksystemen.”
Die zin beschrijft waarom NIS2-programma’s voor cyberbeveiligingshygiëne segmentatie niet als optioneel mogen behandelen. Indamming van ransomware gaat niet alleen over endpointbescherming. Het gaat ook over het beperken van laterale beweging wanneer preventie faalt.
Voor GDPR mapt Zenith Controls 8.22 naar Article 32 en Recital 49, met de kanttekening dat netwerkdiagrammen en zoneringsbeleid belangrijk bewijsmateriaal voor naleving worden. Voor DORA mapt Zenith Controls netwerkbeveiliging en scheiding naar ICT-risicobeheer en incidentindamming. Segmentatietests kunnen bewijsmateriaal voor ICT-weerbaarheid ondersteunen, vooral wanneer zij aantonen dat een compromittering in één zone zich niet vrij kan verplaatsen naar kritieke financiële diensten, repositories met persoonsgegevens of systemen voor geprivilegieerd beheer.
| Bewijsartefact | Gebruik voor ISO/IEC 27001:2022 en ISO/IEC 27002:2022 | Gebruik voor NIS2 | Gebruik voor DORA | Gebruik voor GDPR |
|---|---|---|---|---|
| Document inzake netwerkbeveiligingsarchitectuur | Ondersteunt ISMS-toepassingsgebied, operationele beheersing, 8.20 en 8.22 | Toont technische maatregelen voor de beveiliging van netwerk- en informatiesystemen | Toont ICT-interconnecties en afhankelijkheden van kritieke diensten | Toont beschermingsgrenzen rond systemen met persoonsgegevens |
| Zone- en gegevensstroommatrix | Toont risicogebaseerde scheiding en minimale rechten aan | Ondersteunt cyberbeveiligingshygiëne en beoordeling van doeltreffendheid | Ondersteunt classificatie van ICT-activa en afhankelijkheden | Ondersteunt technische maatregelen en verantwoordingsplicht onder Article 32 |
| Registraties van firewallregelbeoordelingen | Bewijsmateriaal van monitoring van beheersmaatregelen en voortdurende verbetering | Toont dat maatregelen worden beoordeeld en niet statisch zijn | Ondersteunt ICT-risicobeoordeling en weerbaarheidstesten | Toont doorlopende beveiliging van de verwerking aan |
| Wijzigingstickets voor firewallregels | Ondersteunt 8.32 wijzigingsbeheer | Ondersteunt veilig onderhoud en traceerbaarheid | Ondersteunt beheerste ICT-wijzigingen en weerbaarheid | Toont dat wijzigingen die systemen met persoonsgegevens raken op risico zijn beoordeeld |
| Uitzonderingenregister | Ondersteunt risicobehandeling en acceptatie van restrisico | Toont managementtoezicht op afwijkingen | Ondersteunt risicotolerantie en governance | Toont verantwoordingsplicht voor tijdelijke blootstelling |
| Logboeken van geblokkeerd en toegestaan interzoneverkeer | Ondersteunt logging, monitoring en doeltreffendheid van beheersmaatregelen | Ondersteunt detectie en incidentrespons | Ondersteunt incidentclassificatie en rapportage | Ondersteunt beoordeling van inbreuken en bewaring van bewijsmateriaal |
Deze tabel is niet alleen een compliancemapping. Het is een roadmap voor het verzamelen van bewijsmateriaal.
De firewallregelbeoordeling die echt werkt
Een firewallregelbeoordeling faalt wanneer alleen wordt gevraagd: “Is deze regel nog nodig?” Regeleigenaren zeggen vaak ja omdat zij bang zijn iets te verstoren.
Een betere beoordeling stelt zes vragen:
- Welke zakelijke dienst ondersteunt deze regel?
- Welke eigenaar van het bedrijfsmiddel en welke gegevenseigenaar hebben de gegevensstroom goedgekeurd?
- Bevindt de bestemming zich in de juiste zone voor de gegevens en functie?
- Is de regel ruimer dan het waargenomen verkeer vereist?
- Is logging ingeschakeld voor hoogrisicostromen?
- Heeft de regel een beoordelingsdatum, vervaldatum of uitzonderingsregistratie?
Het Beleid inzake netwerkbeveiliging-sme vereist periodieke beoordeling:
“De IT-supportverlener moet jaarlijks een beoordeling uitvoeren van firewallregels, netwerkarchitectuur en draadloze configuraties”
Uit SME Policy, Beleid inzake netwerkbeveiliging-sme, sectie “Governancevereisten,” clausule 5.6.1.
Jaarlijkse beoordeling is de ondergrens, niet het maximum. Hoogrisicoregels hebben frequentere hercertificering nodig.
| Regelcategorie | Voorbeeld | Beoordelingsfrequentie | Verwachte goedkeuring |
|---|---|---|---|
| Inkomend internetverkeer naar productie | Publieke API naar applicatiegateway | Per kwartaal of na majeure release | Service-eigenaar, security, wijzigingsgoedkeurder |
| Interzone-toegang tot productiedatabase | Applicatielaag naar databaselaag | Per kwartaal | Applicatie-eigenaar en gegevenseigenaar |
| Beheerderstoegang | Jumpbox naar poorten voor serverbeheer | Maandelijks of per kwartaal | Infrastructuureigenaar en CISO-gemachtigde |
| Toegang van derden | Leveranciers-VPN naar supportsubnet | Maandelijks of bij contractmijlpaal | Leveranciereigenaar en security |
| Tijdelijke uitzondering | Noodtoegang tijdens migratie | Vóór verloop, maximaal 90 dagen | ISMS-manager of CISO |
| Standaard interne regel met laag risico | Monitoringserver naar beheerde endpoints | Jaarlijks | Service-eigenaar |
Het Beleid inzake netwerkbeveiliging is expliciet over uitzonderingen:
“Het verzoek moet worden beoordeeld en goedgekeurd door de ISMS-manager of de CISO en worden geregistreerd in het ISMS-uitzonderingenregister, met een maximale goedkeuringsperiode van 90 dagen, verlengbaar na herbeoordeling.”
Uit Enterprise Policy, Beleid inzake netwerkbeveiliging, sectie “Risicobehandeling en uitzonderingen,” clausule 7.3.
Voor mkb-organisaties vereist het Beleid inzake netwerkbeveiliging-sme dat uitzonderingsverzoeken de juiste minimale gegevens bevatten:
“Het verzoek moet de rechtvaardiging, reikwijdte, duur en compenserende beheersmaatregelen bevatten (bijv. IP-toelatingslijsten, logging)”
Uit SME Policy, Beleid inzake netwerkbeveiliging-sme, sectie “Risicobehandeling en uitzonderingen,” clausule 7.3.3.
Die clausule verandert afhandeling van uitzonderingen van informeel chatverkeer in auditeerbare risicobehandeling.
Praktisch voorbeeld: een risicovolle productiedatabaseregel verwijderen
Stel dat een organisatie tijdens de beoordeling de volgende regel vindt:
| Veld | Huidige waarde |
|---|---|
| Bron | VLAN voor bedrijfsgebruikers |
| Bestemming | Subnet voor productiedatabase |
| Poort | TCP 5432 |
| Actie | Toestaan |
| Opmerking | Tijdelijke toegang voor rapportagemigratie |
| Aangemaakt | 14 maanden geleden |
| Eigenaar | Onbekend |
| Logging | Uitgeschakeld |
Dit is een klassieke auditbevinding. De regel schendt het principe van minimale rechten, heeft geen duidelijke eigenaar, geen vervaldatum, geen actuele rechtvaardiging en geen logging. De regel creëert ook blootstelling onder GDPR Article 32 als de productiedatabase persoonsgegevens van klanten bevat.
Het herstelproces moet bewijsmateriaal creëren, niet alleen een slechte regel verwijderen.
| Stap | Actie | Clarysec-referentie | Gecreëerd auditbewijsmateriaal |
|---|---|---|---|
| 1. Map de regel naar het zoneringsmodel | Bevestig of bedrijfsgebruikers ooit het subnet voor productiedatabases mogen bereiken | Zenith Blueprint, Controls in Action stap 20 | Bijgewerkte notities van de architectuurbeoordeling en zone-indeling |
| 2. Maak de stroomregistratie aan of werk deze bij | Documenteer bron, bestemming, poort, gegevenstype, eigenaar, rechtvaardiging en risico | Zenith Controls, mapping voor 8.22 | Vermelding in de zone- en gegevensstroommatrix |
| 3. Open een wijzigingsticket | Stel verwijdering voor of vervanging door een gecontroleerd pad via een rapportagedienst | Beleid inzake netwerkbeveiliging, clausule 5.4 | Wijzigingsregistratie met risicoanalyse, testplan en rollbackplan |
| 4. Bepaal de behandeling | Verwijder de ruime regel of vervang deze door een alleen-lezen replica, bastion, IP-toelatingslijst en logging | Beleid inzake netwerkbeveiliging, clausule 7.3 | Besluit over risicobehandeling of tijdgebonden uitzondering |
| 5. Schakel logging in voor goedgekeurde gegevensstromen | Stuur hoogrisico-interzone-firewallgebeurtenissen naar monitoring | Beleid voor logging en monitoring, clausule 6.1.1.6 | SIEM-registraties, waarschuwingsregels en monitoringscreenshots |
| 6. Valideer segmentatie | Test dat het databasesubnet alleen via goedgekeurde paden bereikbaar is | Zenith Blueprint, stap 20 | Resultaat van segmentatietest en sluiting van herstelmaatregel |
Clarysec’s Beleid voor logging en monitoring [P-LM] noemt externe communicatie en firewallregeltriggers als logrelevante gebeurtenissen:
“Externe communicatie en firewallregeltriggers”
Uit Enterprise Policy, Beleid voor logging en monitoring, sectie “Vereisten voor beleidsimplementatie,” clausule 6.1.1.6.
Voor hoogrisico-interzoneregels moeten firewalltriggers naar het SIEM of monitoringplatform gaan, met waarschuwingen voor ongebruikelijke bronhosts, volumes of tijdvensters.
Het mkb-beleid vereist ook wijzigingsdiscipline:
“Alle wijzigingen aan netwerkconfiguraties (firewallregels, switch-ACL’s, routeringstabellen) moeten een gedocumenteerd wijzigingsbeheerproces volgen”
Uit SME Policy, Beleid inzake netwerkbeveiliging-sme, sectie “Vereisten voor beleidsimplementatie,” clausule 6.9.1.
Eén opschoning van deze regel creëert bewijsmateriaal voor ISO/IEC 27001:2022 operationele beheersing, ISO/IEC 27002:2022 8.20, 8.22 en 8.32, NIS2-cyberbeveiligingshygiëne, GDPR Article 32 en DORA-achtig ICT-risicobeheer.
Cloud, SaaS en hybride netwerken moeten worden meegenomen
Moderne segmentatie bestaat niet alleen uit VLAN’s en fysieke firewalls. Zij omvat AWS security groups, Azure network security groups, Kubernetes-netwerkbeleid, cloudrouteringstabellen, SaaS-beheertoelatingslijsten, private endpoints, VPN’s, SD-WAN, identiteitsbewuste proxy’s en softwaregedefinieerde perimeterbeheersmaatregelen.
Voor een SaaS-aanbieder of gereguleerde digitale dienst moet de firewallregelbeoordeling ten minste het volgende omvatten:
- Internetgerichte load balancers en applicatiegateways
- Cloud-securitygroups en netwerk-ACL’s
- Routeringstabellen voor private subnetten
- Peering- en transitgatewaypaden
- VPN- en externe beheerpaden
- Beheerinterfaces en managementplanes
- Kubernetes-ingress en netwerkbeleid
- Toegang van CI/CD-runners tot productie
- Loggingdekking voor geweigerde en toegestane hoogrisicostromen
- Supporttoegang door derden en break-glass-paden
Als een cloud-securitygroup inkomend databaseverkeer vanaf een breed bedrijfs-IP-bereik toestaat, behandel deze dan als een firewallregel. Er zijn eigenaarschap, rechtvaardiging, goedkeuring, beoordeling, logging en een vervaldatum nodig.
Hier versterken ondersteunende ISO-normen ook het verhaal. ISO/IEC 27017 ondersteunt duidelijkheid over verantwoordelijkheden voor cloudbeveiliging. ISO/IEC 27033 biedt diepgaandere richtlijnen voor netwerkbeveiligingsarchitectuur, DMZ’s, segmentatiezones, verkeersfiltering en beveiligde communicatie tussen netwerken. ISO/IEC 27701 versterkt privacygovernance waar persoonlijk identificeerbare informatie over netwerken beweegt. ISO/IEC 27035 ondersteunt incidentindamming, en ISO/IEC 27005 ondersteunt het selecteren van segmentatie als risicobehandeling voor ongeautoriseerde toegang, malwareverspreiding en laterale beweging.
Hoe auditors dezelfde beheersmaatregel verschillend toetsen
Een van de sterke punten van Zenith Controls is dat het uitlegt hoe verschillende auditmethodologieën dezelfde beheersmaatregel onderzoeken. Het bewijsmateriaal kan worden hergebruikt, maar de vragen verschillen.
| Auditperspectief | Waarschijnlijke vraag | Beste bewijsmateriaal |
|---|---|---|
| ISO/IEC 27001:2022-auditor | Is segmentatie geselecteerd, geïmplementeerd en beoordeeld op basis van risico? | Risicobeoordeling, SoA, netwerkbeleid, diagrammen, beoordelingsregistraties |
| Auditor volgens ISO/IEC 27007-stijl | Komen geïmplementeerde firewallregels en VLAN-schema’s overeen met het gedocumenteerde beleid? | Voorbeelden van firewallregels, router-ACL’s, VLAN-ontwerp, interviews met beheerders |
| Certificeringsauditbenadering volgens ISO/IEC 27006-1:2024 | Worden kritieke netwerkgrenzen geaudit met passende competentie en risicogebaseerde planning? | Auditplan, technische steekproeven, bewijsmateriaal van cloud-securitygroups, testresultaten |
| NIST-georiënteerde auditor | Worden grenzen en informatiestromen afgedwongen en bewaakt? | Firewallregels, ACL’s, segmentatietests, monitoringregistraties |
| COBIT 2019-auditor | Wordt netwerkbeveiliging bestuurd, bewaakt en gerapporteerd? | Eigenaarschapsmatrix, KPI’s, managementrapportage, risicoregister |
| ISACA ITAF-auditor | Werken algemene IT-beheersmaatregelen consistent? | Wijzigingstickets, goedkeuringen van uitzonderingen, logboeken, steekproeven van regelhercertificering |
| GDPR-toezichthoudende autoriteit | Werden systemen met persoonsgegevens beschermd door passende technische maatregelen? | Gegevensstroomdiagrammen, isolatie van zones met persoonlijk identificeerbare informatie (PII), toegangspaden, firewalllogboeken |
| DORA-gerichte assessor | Ondersteunt segmentatie ICT-weerbaarheid en incidentindamming? | Afhankelijkheidskaart van ICT-activa, stromen van kritieke functies, incidentdraaiboeken, testregistraties |
Een DORA-gerichte assessor kan vragen of een compromittering in een betalingsgateway kan pivoteren naar klantdatabases. Een bevoegde NIS2-autoriteit kan vragen of ransomware op een beheerderswerkplek de kernsystemen voor dienstverlening kan bereiken. Een GDPR-autoriteit kan vragen welke beperkingen op netwerkniveau systemen beschermden die persoonsgegevens verwerken. Een ISO-auditor kan simpelweg vragen naar de risicobeoordeling, SoA, het beleid, de procedure en bewijsmateriaal dat beoordelingen hebben plaatsgevonden.
De beste programma’s beantwoorden al deze vragen met dezelfde artefacten.
Metrieken die segmentatie zichtbaar maken voor de leiding
NIS2 en DORA leggen beide nadruk op verantwoordingsplicht van het management. ISO/IEC 27001:2022 vereist leiderschap, doelstellingen, rollen, middelen, rapportage en voortdurende verbetering. Dat betekent dat segmentatie metrieken nodig heeft die de leiding begrijpt.
Nuttige managementmetrieken zijn onder meer:
- Percentage firewallregels met toegewezen eigenaar
- Percentage regels met gedocumenteerde zakelijke rechtvaardiging
- Aantal verlopen tijdelijke regels
- Aantal regels met “any” als bron, bestemming of service
- Aantal aan internet blootgestelde diensten per kritikaliteit
- Percentage hoogrisico-interzonestromen waarvoor logging is ingeschakeld
- Aantal noodwijzigingen aan firewalls per kwartaal
- Percentage bemonsterde regels dat is gekoppeld aan goedgekeurde wijzigingstickets
- Aantal mislukkingen van segmentatietests
- Gemiddelde tijd om risicovolle of ongebruikte regels te herstellen
- Aantal uitzonderingen ouder dan 90 dagen
- Aantal regels voor toegang van derden dat is beoordeeld en opnieuw is gecertificeerd
Het Beleid inzake netwerkbeveiliging benoemt “doeltreffendheid van firewallregels” als overweging voor naleving en handhaving in de sectie “Handhaving en naleving,” clausule 8.2.2. Die formulering is belangrijk omdat het bestaan van regels niet volstaat. Regels moeten doeltreffend zijn, worden beoordeeld en aansluiten op het actuele risico.
Bouw het segmentatiebewijspakket voor 2026
Een praktisch bewijspakket voor segmentatie en firewallregelbeoordeling moet klaar zijn voordat de auditor erom vraagt.
Onderhoud minimaal:
- Actueel netwerkarchitectuurdiagram, inclusief cloud- en hybride zones
- Standaard voor zone-indeling, inclusief gevoeligheid en vertrouwensniveau
- Gegevensstroommatrix voor kritieke diensten en systemen met persoonsgegevens
- Export van firewallregels en cloud-securitygroupregels
- Register van regeleigenaren en hercertificering
- Procedure en kalender voor firewallbeoordelingen
- Wijzigingsregistraties voor bemonsterde firewallwijzigingen
- Uitzonderingenregister met goedkeuringen, vervaldatum en compenserende beheersmaatregelen
- Resultaten van segmentatietests en herstelregistraties
- Bewijsmateriaal voor logging en monitoring van hoogrisicostromen
- Incidentdraaiboeken die indamming per zone aantonen
- Managementrapportagemetrieken en notulen
Map dit bewijsmateriaal naar ISO/IEC 27001:2022-clausules en Annex A-beheersingsgebieden. Verwijs het vervolgens kruislings naar NIS2 Article 21, GDPR Article 32, DORA-vereisten voor ICT-risicobeheer en testing, NIST CSF 2.0-uitkomsten zoals GOVERN, PROTECT, DETECT en RESPOND, en COBIT-governancepraktijken.
NIST CSF 2.0 is vooral nuttig als communicatielaag richting bestuur. De GOVERN-functie richt zich op wettelijke, regelgevende en contractuele eisen, risicobereidheid, rollen, beleid en toezicht. De operationele uitkomsten behandelen configuratiebeheer, logging, monitoring, gegevensbescherming, incidentrespons en herstel. Dit helpt de leiding risico’s te begrijpen zonder firewall-ACL’s te lezen.
Veelvoorkomende bevindingen die Clarysec ziet in segmentatieaudits
Bij SaaS, fintech, managed service providers en gereguleerde mkb-organisaties verschijnen steeds dezelfde bevindingen:
- Plat netwerk tussen gebruikerseindpunten en productiediensten
- Productiedatabases bereikbaar vanuit ontwikkel- of bedrijfsnetwerken
- Brede cloud-securitygroups gekopieerd uit oude sjablonen
- Tijdelijke leveranciersregels zonder vervaldatum
- Firewallwijzigingen buiten het wijzigingsproces om
- Regels zonder eigenaar of zakelijke rechtvaardiging
- Logging uitgeschakeld op hoogrisicoregels die verkeer toestaan
- Gast-wifi niet volledig geïsoleerd
- Beheerinterfaces bereikbaar vanuit algemene netwerken
- Diagrammen die niet overeenkomen met daadwerkelijke routering
- Geen bewijsmateriaal dat regelbeoordelingen zijn voltooid
- Geen segmentatietesten na majeure architectuurwijzigingen
- Geen mapping tussen systemen met persoonsgegevens en netwerkzones
- Geen managementrapportage over netwerkblootstelling
Deze bevindingen zijn niet alleen technische zwaktes. Ze ondermijnen het vermogen van de organisatie om NIS2-cyberbeveiligingshygiëne, DORA operationele weerbaarheid en verantwoordingsplicht onder GDPR Article 32 aan te tonen.
Van reactieve opschoning naar verdedigbare beheersmaatregel
Netwerksegmentatie en firewallregelbeoordeling vormen het punt waar beveiligingsarchitectuur en auditrealiteit samenkomen. Als u een risicogebaseerd zoneringsmodel, beheerste interzonestromen, goedgekeurde firewallwijzigingen, tijdgebonden uitzonderingen, loggingbewijsmateriaal en periodieke validatie kunt aantonen, kunt u een breed scala aan vragen over ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST en COBIT beantwoorden met één coherent verhaal.
Clarysec kan u helpen dat verhaal op te bouwen.
Gebruik Zenith Blueprint: een 30-stappenroadmap voor auditors om het implementatietraject te structureren, in het bijzonder Controls in Action stap 20 voor netwerkbeveiliging en segmentatie, en stap 21 voor wijzigingsbeheer. Gebruik Zenith Controls: de gids voor cross-compliance om ISO/IEC 27002:2022-beheersmaatregelen 8.20, 8.22 en 8.32 te mappen naar auditverwachtingen voor NIS2, DORA, GDPR, NIST en COBIT. Veranker uw operationele regels in Clarysec’s Beleid inzake netwerkbeveiliging, Beleid inzake netwerkbeveiliging-sme en Beleid voor logging en monitoring.
Uw volgende stap is eenvoudig en waardevol: selecteer deze week één kritieke dienst, zoals klantproductie, betalingsverwerking of identiteitsbeheer, en voer een steekproefbeoordeling van 10 regels uit. Bevestig voor elke regel eigenaar, rechtvaardiging, bron, bestemming, poort, logging, wijzigingsticket en vervaldatum. Als u die zeven feiten niet kunt aantonen, hebt u het begin van uw verbeterplan voor segmentatie in 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
