# Van 30 dagen naar 48 uur: hoe bouw je een patchproces dat bijhoudt met aanvallers?
Vulnerability management — mei 2026 · 7 min leestijd In onze vorige post beschreven we zes kritieke kwetsbaarheden in Palo Alto- en Fortinet-firewalls die dit jaar actief werden uitgebuit. Eén getal viel daarbij op: bij CVE-2026-0300 zaten aanvallers al actief in netwerken weken voordat de patch beschikbaar was. Bij CVE-2026-35616 begon de
Vulnerability management — mei 2026 · 7 min leestijd
In onze vorige post beschreven we zes kritieke kwetsbaarheden in Palo Alto- en Fortinet-firewalls die dit jaar actief werden uitgebuit. Eén getal viel daarbij op: bij CVE-2026-0300 zaten aanvallers al actief in netwerken weken voordat de patch beschikbaar was. Bij CVE-2026-35616 begon de exploitatie zelfs vóór de officiële advisory.
Maar dat is uitzonderlijk. Vaker is het patroon andersom: een patch komt uit, en binnen drie tot vijf dagen volgen de aanvallen. Drie tot vijf dagen om te testen, goed te keuren en te deployen. Voor de meeste organisaties is dat onhaalbaar met een traditioneel patchproces.
Dit artikel legt uit waarom dat zo is — en hoe u het verandert.
Het probleem: patchcycli zijn ontworpen voor een andere wereld
Traditionele patchprocessen zijn gebouwd op maandelijkse of kwartaalcycli. De redenering was ooit logisch: patches konden systemen destabiliseren, testen kostte tijd, en de risico's van een kwetsbaarheid waren beheersbaar zolang u andere compenserende maatregelen had.
Die redenering klopt niet meer.
De gemiddelde tijd tussen publieke CVE-disclosure en massale geautomatiseerde exploitatie is in 2026 gedaald naar minder dan vijf dagen, en voor high-profile kwetsbaarheden in veelgebruikte producten soms naar minder dan 24 uur. Dat blijkt uit onderzoek van de Shadowserver Foundation en Rapid7's jaarlijkse Vulnerability Intelligence Report.
Het probleem zit op drie niveaus:
Operationeel: Patches worden gebundeld en gepland in onderhoudsvensters. Kritieke patches voor firewalls en edge devices volgen dezelfde wachtrij als routineupdates voor printersoftware.
Organisatorisch: Patchgoedkeuring vereist meerdere handtekeningen. Change advisory boards vergaderen wekelijks, niet dagelijks.
Technisch: Testprocedures zijn niet gedifferentieerd naar risiconiveau. Elke patch doorloopt dezelfde testcyclus, ongeacht ernst.
De oplossing: een gedifferentieerd patchproces
Het antwoord is geen snellere versie van hetzelfde proces. Het is een fundamenteel ander model: één waarbij de snelheid van respons wordt bepaald door de ernst van de kwetsbaarheid, niet door de planningsmethodiek.
Stap 1 — Classificeer kwetsbaarheden bij binnenkomst
Richt een dagelijkse of zelfs continue feed in van betrouwbare dreigingsinformatiebronnen. Koppel die aan een harde classificatie die direct bepaalt welk spoor een kwetsbaarheid volgt:
| Classificatie | Criteria | Maximale patchtijd |
|---|---|---|
| Kritiek / Nood | CVSS ≥ 9.0 én actieve exploitatie of KEV-vermelding | 24–48 uur |
| Hoog | CVSS 7.0–8.9 of PoC beschikbaar | 7 dagen |
| Gemiddeld | CVSS 4.0–6.9, geen actieve exploitatie | 30 dagen |
| Laag | CVSS < 4.0 | Reguliere cyclus |
Bronnen die u in deze feed wilt opnemen: CISA KEV-catalogus, PSIRT-meldingen van uw leveranciers, Shadowserver Daily Reports, en eventueel een commerciële threat intelligence feed.
Voor management: Dit is geen IT-beslissing alleen. De maximale patchtijden in de tabel hierboven zijn risicodrempels. Als organisatie besluit u welk restniveau u acceptabel vindt. Leg die drempels vast in beleid.
Stap 2 — Ontkoppel kritieke patches van de reguliere cyclus
Kritieke patches — met name voor firewalls, VPN-concentrators en andere edge devices — mogen nooit wachten op het eerstvolgende onderhoudsvenster. Richt een afzonderlijk noodpatchproces in met:
- Vereenvoudigde goedkeuring: één technisch verantwoordelijke en één managementakkoord volstaan voor noodpatches. Geen CAB-vergadering vereist.
- Pre-goedgekeurde testprocedure: een verkorte maar gedocumenteerde testchecklist specifiek voor firewall-firmware-updates, zodat beheerders niet hoeven te improviseren onder tijdsdruk.
- Vooraf bepaald terugvalplan: vóór elke noodpatch een configuratie-snapshot maken en weten hoe u terugrol in minder dan 30 minuten.
Stap 3 — Automatiseer zichtbaarheid, niet de deployment
Een veelgemaakte fout is het proberen te automatiseren van de patch-deployment zelf — zeker op firewalls. Dat is risicovol. Wat u wél moet automatiseren:
- Asset inventarisatie: welke versies van PAN-OS en FortiOS draaien er in uw omgeving, op welke locaties? Dit moet real-time beschikbaar zijn, niet opgehaald uit een spreadsheet die twee maanden oud is.
- CVE-matching: koppel uw asset inventaris automatisch aan nieuwe CVE-publicaties zodat u binnen minuten weet of u geraakt bent.
- Alerting: stuur meldingen naar de juiste mensen op het moment dat een kwetsbaarheid uw classificatiedrempel overschrijdt.
Tools die hiervoor worden ingezet: Tenable.io, Qualys VMDR, of — voor kleinere omgevingen — een combinatie van CISA KEV RSS-feeds gekoppeld aan een eenvoudig script dat matcht tegen een bijgehouden asset-lijst.
Stap 4 — Test slim, niet uitputtend
Voor kritieke edge device patches heeft u geen uitgebreide regressietestcyclus nodig. U heeft een gerichte functionele checklist nodig. Die checklist bevat voor een firewall-update minimaal:
- VPN-tunnels actief na update (steekproef van kritieke verbindingen)
- Authenticatie via beheerinterface werkt
- Verkeersbeleid actief en correct (steekproef van kritieke regels)
- Logging functioneert en bereikt SIEM
- Geen onverwachte CPU/geheugenspikes in eerste 15 minuten na herstart
Dat is een test van minder dan een uur — geen reden voor een weekcyclus.
Stap 5 — Meet en verantwoord
Een patchproces zonder meting verbetert niet. Houd bij:
- Mean Time to Patch (MTTP) per classificatieniveau — worden de drempels gehaald?
- Patch coverage — welk percentage van kwetsbare assets is gepatcht binnen de gestelde termijn?
- Exposure window — hoeveel dagen stond een kritieke kwetsbaarheid open in uw omgeving?
Rapporteer deze cijfers maandelijks aan management. Ze maken risico concreet en zichtbaar, en geven de IT-afdeling een mandaat om noodpatches door te zetten zonder bureaucratische vertraging.
Wat vraagt dit van management?
Een sneller patchproces is geen puur technische exercitie. Het vereist organisatorische randvoorwaarden:
- Mandaat voor noodpatches: beheerders moeten kritieke patches kunnen uitrollen zonder te wachten op een vergadering. Leg dat vast.
- Onderhoudsvensters op aanvraag: zorg dat er altijd een beschikbaar onderhoudsvenster kan worden ingepland binnen 24 uur voor kritieke systemen, ook buiten kantooruren.
- Budget voor tooling: goede asset-inventarisatie en CVE-matching kosten geld. Maar ze kosten minder dan een incident.
- Acceptatie van restniveau: niet elke kwetsbaarheid kan in 48 uur worden gepatcht. Leg vast welk restniveau acceptabel is en welke compenserende maatregelen dan van toepassing zijn (netwerksegmentatie, tijdelijk uitschakelen van kwetsbare features).
Samenvatting
Een patchproces dat bijhoudt met de exploit-snelheid van 2026 is geen kwestie van meer mensen of meer tools. Het is een kwestie van differentiatie, voorbereiding en mandaat. Kritieke kwetsbaarheden in edge devices verdienen een eigen, verkorte procedure — met heldere drempels, vooraf getest, en met de bevoegdheid om snel te handelen.
De vraag is niet of u een noodpatch ooit nodig zult hebben. De vraag is of u er klaar voor bent als het zover is.
Dit artikel is het tweede deel in een reeks over netwerkbeveiliging en vulnerability management. Deel één behandelde de kritieke kwetsbaarheden in Palo Alto- en Fortinet-firewalls in de eerste vijf maanden van 2026.
Bronnen: CISA KEV-catalogus, Rapid7 Vulnerability Intelligence Report 2026, Shadowserver Foundation, Palo Alto Networks PSIRT, Fortinet FortiGuard Labs.