← Alle artikelen

# Van 30 dagen naar 48 uur: hoe bouw je een patchproces dat bijhoudt met aanvallers?

Bijgewerkt op 14 oktober 2026: de indeling in sporen gaat nu uit van actief misbruik en bereikbaarheid in plaats van alleen de CVSS-score, en er is een stap toegevoegd over bewijs veiligstellen voor en na een noodpatch. Aanleiding zijn de recente aanvallen op Citrix NetScaler en Ivanti Connect Secure.

Door Sander 19 mei 2026 5 min leestijd

Dit artikel volgt op onze post over Palo Alto en Fortinet, waarin aanvallers bij CVE-2026-0300 al weken in netwerken zaten voordat er een patch was, en bij CVE-2026-35616 het misbruik begon vóór de officiële melding.

In het kort

Misbruik begint steeds vaker binnen dagen na een melding, en soms al ervoor.
Een maandelijkse patchcyclus kan dat niet bijhouden; een apart noodspoor voor een klein aantal kwetsbaarheden wel.
Bepaal de urgentie op basis van actief misbruik en bereikbaarheid vanaf internet. De CVSS-score alleen is daarvoor niet genoeg.

Het probleem: patchcycli zijn ontworpen voor een andere wereld

Traditionele patchprocessen draaien op maandelijkse of driemaandelijkse cycli. Dat was ooit logisch: patches konden systemen ontregelen, testen kostte tijd, en een kwetsbaarheid was beheersbaar zolang er andere maatregelen waren.

Die redenering houdt geen stand meer. Google schat de gemiddelde tijd tot misbruik in M-Trends 2026 op min zeven dagen: misbruik begint gemiddeld een week voordat er een patch is. In 2018 was dat nog 63 dagen. En als er wel eerst een patch is, gaat het snel. Een kwetsbaarheid in BeyondTrust werd dit jaar binnen vier dagen na bekendmaking misbruikt, en binnen zeven dagen door zes groepen tegelijk. Hoe AI daarin een rol speelt, beschreven we eerder deze week.

Een traditioneel proces loopt op drie punten vast:

Operationeel. Patches worden gebundeld in onderhoudsvensters. Een kritieke patch voor een firewall wacht in dezelfde rij als een update voor printersoftware.
Organisatorisch. Goedkeuring vraagt meerdere handtekeningen, en een change advisory board vergadert wekelijks, niet dagelijks.
Technisch. Elke patch doorloopt dezelfde testcyclus, ongeacht hoe ernstig het probleem is.

De oplossing: verschillende sporen

Het antwoord is geen snellere versie van hetzelfde proces, maar een ander model: de urgentie van een kwetsbaarheid bepaalt het spoor, niet de planning. Dat betekent ook niet dat alles binnen 48 uur moet. Volgens Google wordt maar ongeveer 0,23 procent van alle gemelde kwetsbaarheden in het wild misbruikt. Het noodspoor is voor dat kleine deel.

Stap 1: deel kwetsbaarheden direct in

Volg dagelijks een aantal betrouwbare bronnen en deel elke relevante melding meteen in een spoor in:

Spoor	Criteria	Maximale termijn
Nood	Actief misbruikt, en het systeem is bereikbaar vanaf internet	24–48 uur
Hoog	Actief misbruikt op een intern systeem, of publieke aanvalscode voor een systeem aan het internet	7 dagen
Normaal	Kritiek of hoog, maar geen misbruik bekend	30 dagen
Laag	Overige kwetsbaarheden	Reguliere cyclus

"Actief misbruikt" betekent: genoemd in de lijst van actief misbruikte kwetsbaarheden van CISA, door het NCSC of door de leverancier zelf.

Waarom niet op CVSS? Omdat de score niets zegt over misbruik. De Ivanti-zeroday van deze week heeft een score van 8.6 en een van de Citrix-kwetsbaarheden van oktober 8.7, en beide werden actief misbruikt. In een indeling die het noodspoor pas bij 9.0 opent, waren ze in de wachtrij beland. Het Britse NCSC noemt SSVC als methode voor deze afweging, omdat die rekening houdt met misbruik en blootstelling.

Bronnen voor dit overzicht: de lijst van CISA, de alerts en advisories van het NCSC, de beveiligingsmeldingen van uw eigen leveranciers en de dagelijkse rapporten van de Shadowserver Foundation.

Voor het management: de termijnen in de tabel zijn risicodrempels, geen IT-voorkeur. Leg ze vast in beleid, zodat er bij een melding niet opnieuw over hoeft te worden besloten.

Stap 2: haal het noodspoor uit de reguliere cyclus

Een patch in het noodspoor, zeker voor een firewall, VPN-gateway of ander edge device, wacht niet op het volgende onderhoudsvenster. Richt er een eigen procedure voor in:

Vereenvoudigde goedkeuring: één technisch verantwoordelijke en één akkoord van het management. Geen vergadering van het change advisory board.
Een vooraf goedgekeurde testchecklist per type apparaat, zodat niemand onder tijdsdruk hoeft te improviseren (zie stap 5).
Een vooraf bepaald terugvalplan: een configuratiesnapshot voor de update, en weten hoe u binnen 30 minuten terugrolt.

Stap 3: stel bewijs veilig voor u patcht

Deze stap ontbrak in de eerste versie van dit artikel, en de afgelopen weken hebben laten zien waarom hij nodig is. Bij Citrix NetScaler en Ivanti Connect Secure werden de kwetsbaarheden al misbruikt voordat er een update was. Een update sluit de deur, maar zegt niets over wie er al binnen was. En een herstart wist het werkgeheugen, waarin bij Ivanti juist het bewijs zat.

Voor een kwetsbaarheid in het noodspoor die al voor de bekendmaking werd misbruikt:

Voor de update: draai de controletool van de leverancier als die er is, bewaar de logbestanden, ook die op uw centrale logserver, en maak bij een virtueel apparaat een snapshot.
Na de update: controleer opnieuw op achtergebleven sporen. Bij Citrix overleefden webshells en aangepaste configuraties een update.
Vervang de inloggegevens die het apparaat gebruikt als er een kans is dat ze zijn ingezien, zoals het account waarmee een VPN-gateway in uw directory kijkt.

Dit kost een paar uur extra. Het verschil is dat u achteraf kunt vaststellen of u een incident heeft, in plaats van het te moeten raden. Voor organisaties onder de Cyberbeveiligingswet is dat ook de basis voor een eventuele melding.

Stap 4: automatiseer het zicht, en de updates waar het kan

Automatiseer in elk geval wat u nodig heeft om snel te weten of u geraakt bent:

Inventaris van systemen: welke versies van welke software draaien waar? Dat moet actueel zijn, niet uit een spreadsheet van twee maanden oud.
Koppeling met nieuwe meldingen: verbind die inventaris met nieuwe CVE's, zodat u binnen minuten weet of een melding u raakt.
Alarmering: stuur een melding naar de juiste mensen zodra een kwetsbaarheid in het noodspoor of het hoge spoor valt.

Daarvoor bestaan commerciële platforms, maar in een kleinere omgeving werkt ook een eenvoudig script dat de lijst van CISA vergelijkt met een bijgehouden lijst van systemen.

Over het automatisch installeren van updates zelf zijn de adviezen genuanceerd. Het Britse NCSC adviseert automatische updates en hot patching waar het kan; AIVD en MIVD waarschuwen dat een update in productie niet altijd direct verstandig is. Een werkbare middenweg: laat werkplekken, browsers en SaaS zichzelf bijwerken, en houd voor edge devices en kritieke servers de handmatige, geteste route van het noodspoor aan. Zo houdt u capaciteit over voor de systemen die aandacht nodig hebben.

Stap 5: test gericht, niet uitputtend

Voor een noodpatch op een edge device heeft u geen volledige regressietest nodig, wel een gerichte checklist. Voor een firewall of VPN-gateway minimaal:

VPN-tunnels zijn actief na de update (steekproef van de belangrijkste verbindingen).
Aanmelden op de beheerinterface werkt.
Het verkeersbeleid is actief en klopt (steekproef van de belangrijkste regels).
Logging werkt en komt aan op de centrale logserver.
Geen onverwachte pieken in processor- of geheugengebruik in het eerste kwartier na de herstart.

Dat is een test van minder dan een uur, geen reden voor een cyclus van een week.

Stap 6: meet en rapporteer

Een patchproces zonder meting wordt niet beter. Houd per spoor bij:

Gemiddelde tijd tot patch: worden de termijnen gehaald?
Dekking: welk deel van de kwetsbare systemen is binnen de termijn bijgewerkt?
Blootstellingsvenster: hoeveel dagen stond een kwetsbaarheid in het noodspoor open?

Rapporteer dit maandelijks aan het management. Het maakt risico zichtbaar en geeft het IT-team het mandaat om noodpatches door te zetten.

Wat vraagt dit van het management?

Een sneller patchproces is geen puur technische kwestie. Het vraagt om vier dingen:

Mandaat voor noodpatches. Beheerders moeten een patch in het noodspoor kunnen uitrollen zonder op een vergadering te wachten.
Onderhoud op afroep. Er moet binnen 24 uur een onderhoudsvenster mogelijk zijn voor kritieke systemen, ook buiten kantooruren.
Budget voor zicht en logging. Een actuele inventaris en centrale logging kosten geld, maar minder dan een incident. AIVD en MIVD adviseren logs minstens een halfjaar te bewaren, liever een jaar.
Afspraken over wat niet lukt. Niet elke kwetsbaarheid is binnen 48 uur te dichten. Leg vast welke tijdelijke maatregelen dan gelden, zoals de toegang beperken, een functie uitschakelen of het apparaat tijdelijk van het internet halen.

Tot slot

Een patchproces dat bijhoudt met aanvallers draait niet om meer mensen of meer tools, maar om onderscheid, voorbereiding en mandaat. Het noodspoor is klein, maar moet klaarstaan voordat u het nodig heeft. En omdat misbruik soms begint voordat er een patch is, hoort het veiligstellen van bewijs daar net zo vast bij als het installeren van de update.