Wat zijn Stale Rules?
Stale Rules zijn verouderde of ongebruikte regels binnen een regelset, die geen merkbaar nut meer hebben maar nog steeds worden beoordeeld. Typische voorbeelden zijn vrijgaven voor allang uitgeschakelde applicaties, uitzonderingen voor vertrokken medewerkers of als tijdelijk bedoelde regels die nooit zijn afgebouwd. Stale Rules ontstaan sluipend: projecten eindigen, systemen worden vervangen, maar de bijbehorende regels blijven uit voorzichtigheid staan. Na verloop van tijd groeit zo een regelset die niemand meer volledig overziet. Dat verhoogt de complexiteit van elk onderzoek, vergroot het aanvalsoppervlak door vergeten toestaan-regels en maakt audits bewerkelijker, omdat elke regel moet worden verklaard.
Stale Rules in detail
In de praktijk zijn meerdere soorten te onderscheiden. Ongebruikte regels leveren over een langere observatieperiode geen treffers meer op, bijvoorbeeld omdat de doelapplicatie niet meer bestaat. Verweesde regels verwijzen naar objecten die niet meer bestaan: verwijderde groepen, uitgeschakelde locaties, afgevoerde servers. Verlopen uitzonderingen waren bedoeld als overgangsoplossing, maar zijn nooit verwijderd. Ze hebben allemaal gemeen: ze veranderen het gedrag van de regelset nauwelijks nog, maar kosten bij elke beoordeling, elke review en elk onderzoek aandacht.
In de Zscaler-praktijk raakt dit vooral URL Filtering- en Cloud Firewall-regels in ZIA en toegangsrichtlijnen en App Segments in ZPA. Of een regel echt ongebruikt is, is alleen te beoordelen met gebruiksgegevens over een voldoende lange periode: een regel voor de kwartaalafsluiting levert immers maar vier keer per jaar een treffer op. Precies daarom hoort voor elke opschoning een degelijke, zuiver lezende analyse.
Waarom tellen Stale Rules in de Zscaler-praktijk?
Hoe groter de regelset, hoe duurder elke wijziging wordt. Hoe ongebruikte regels als één bouwsteen naast andere meetellen in één gezondheidsscore, laat onze video over de configuratiescore zien. Wie een nieuwe regel toevoegt, moet begrijpen welke bestaande regels daarvoor al gelden; elke Stale Rule maakt die controle langer en foutgevoeliger. Voor de helpdesk betekent een verwilderde regelset langere doorlooptijden van tickets, omdat er bij elk blokkeergeval meer kandidaten in aanmerking komen. En voor de beveiliging telt: vergeten toestaan-regels uit oude projecten houden toegangen open die niemand meer in de gaten heeft.
Daar komt de bewijskant bij. Wie onder NIS2 of DORA moet aantonen dat toegangs- en filterrichtlijnen het least-privilege-principe volgen, kan regels zonder herkenbaar doel moeilijk verklaren. Een gedocumenteerd opschoningsproces met een motivering per regel is daarom ook een auditargument. De volgorde is belangrijk: eerst de bevinding met gegevens onderbouwen, dan elke verwijdering of deactivering als afzonderlijke, goedgekeurde wijziging doorvoeren, nooit als algemene verzamelactie.
Veelvoorkomende foutbronnen
- Verwijderen zonder bewijs: een regel zonder treffer in de afgelopen maand kan een kwartaal- of jaarproces afdekken; de observatieperiode moet lang genoeg zijn.
- Verzamelopschoning in één keer: tientallen regels tegelijk verwijderen maakt fouten moeilijk te herleiden; beter is één voor één wijzigen en goedkeuren.
- Direct verwijderen in plaats van eerst deactiveren: een deactiveringsfase met observatie is de veilige tussenstap.
- Stale verwarren met shadowed: een regel zonder treffer kan ook door een eerdere regel worden gemaskeerd; dan ligt de oorzaak ergens anders.
Stale Rules in de praktijk: wat CentaurNexus bijdraagt
Policy Hygiene Desk van CentaurNexus analyseert de Zscaler-regelset als zuiver lezende beoordeling via de officiële OneAPI en maakt ongebruikte, verweesde en conflicterende regels inclusief vindplaats zichtbaar. Bewust ontbreekt een automatisme dat de regelset herschikt: elke bevinding blijft een voorstel, en elke opschoning gebeurt als afzonderlijke, navolgbare wijziging, die optioneel via het vierogenprincipe wordt goedgekeurd en in de append-only audit trail terechtkomt. Zo wordt van een diffuse nalatenschap een behapbaar, gedocumenteerd proces. Hoe zo'n regelreview stap voor stap verloopt, laat de gids zien Ongebruikte Zscaler-regels vinden en opruimen.
Verwante begrippen
Veelgestelde vragen over Stale Rules
Via gebruiksgegevens: regels die over een voldoende lange observatieperiode geen treffers opleveren of verwijzen naar objecten die niet meer bestaan, zijn kandidaten. Praktisch is een toolondersteunde, zuiver lezende analyse via de Zscaler-API, die bevindingen inclusief vindplaats documenteert. De periode moet seizoensgebonden processen zoals kwartaalafsluitingen omvatten, anders ontstaan foutieve bevindingen.
Ja, vooral vergeten toestaan-regels: ze houden toegangen open die niemand meer nodig heeft of bewaakt, en vergroten zo het aanvalsoppervlak. Bovendien schenden ze het least-privilege-principe, waaraan regelsets onder NIS2 en DORA moeten worden getoetst. Ook onschuldig ogende oude regels bemoeilijken reviews en leiden de aandacht af van de regels die er echt toe doen.
Niet zonder bewijs en proces. Een aanpak in drie stappen heeft zich bewezen: de bevinding met gebruiksgegevens documenteren, de regel eerst deactiveren en observeren, en pas daarna verwijderen. Elke van deze wijzigingen hoort afzonderlijk te gebeuren, goedgekeurd via het vierogenprincipe en vastgelegd in de audit trail. Verzamelacties zonder goedkeuring veroorzaken nieuwe storingen en zijn nauwelijks terug te herleiden.
Stale Rules zijn inhoudelijk achterhaald: hun doel is vervallen, daarom leveren ze geen treffers meer op. Shadowed Rules zouden inhoudelijk nog relevant zijn, maar worden nooit toegepast, omdat een eerder beoordeelde regel hun reikwijdte volledig afdekt. Beide vallen op door het ontbreken van treffers, maar vragen om verschillende correcties: verwijderen versus conflict oplossen.
Als richtwaarde heeft een vaste reviewcyclus zich bewezen, bijvoorbeeld ieder kwartaal, aangevuld met gerichte controles na migraties, overnames of grotere verbouwingen. Belangrijker dan de exacte frequentie is de verbindendheid: vaste verantwoordelijken, gedocumenteerde bevindingen en één voor één goedgekeurde wijzigingen. Zo blijft de regelset blijvend slank, in plaats van om de paar jaar een risicovolle grote opschoning af te dwingen.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- Zscaler Help Portal: officiële documentatie over ZIA-regels (URL Filtering, Cloud Firewall) - help.zscaler.com
- BSI IT-Grundschutz, bouwsteen NET.3.2 Firewall (eisen voor het onderhoud van de regelset) - bsi.bund.de/.../NET_3_2_Firewall
Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.