Wat is patchmanagement?
Patchmanagement is het gestructureerde proces waarmee een organisatie software-, besturingssysteem- en firmware-updates inventariseert, beoordeelt, test, uitrolt en verifieert, zodat bekende kwetsbaarheden tijdig worden gedicht zonder de bedrijfsvoering te verstoren. In IT-omgevingen (servers, werkplekken, applicaties) is patchen een maandelijkse routine. In OT-omgevingen met PLC’s, SCADA, HMI’s en DCS-systemen is het lastiger: beschikbaarheid en veiligheid gaan voor, leveranciers moeten patches eerst goedkeuren en veel systemen zijn niet meer te updaten. Patchmanagement is daarom een onderdeel van breder vulnerability management: wie niet kan patchen, moet het risico op een andere manier beheersen.
🎯 Waarom is patchmanagement belangrijk?
- Bekende lekken dichten - aanvallers misbruiken veel vaker kwetsbaarheden waarvoor al een CVE en een patch bestaan dan zero-days
- Malware en ransomware tegenhouden - WannaCry (mei 2017) misbruikte een SMBv1-lek waarvoor Microsoft twee maanden eerder patch MS17-010 had uitgebracht en legde onder meer fabrieken van Renault en Nissan stil
- Stabiliteit en betrouwbaarheid - patches lossen ook bugs en geheugenlekken op
- Compliance - NIS2, ISO 27001 (beheersmaatregel A.8.8, beheer van technische kwetsbaarheden), IEC 62443 en de BIO eisen aantoonbaar kwetsbaarheidsbeheer
- Minder incidenten en stilstand - preventief onderhoud is goedkoper dan herstel na een incident
🔄 Wat is het verschil tussen patchen in IT en OT?
| Aspect | IT | OT |
|---|---|---|
| Prioriteit | Vertrouwelijkheid en snelheid | Beschikbaarheid en functionele veiligheid |
| Ritme | Maandelijks (Patch Tuesday), kritieke patches binnen dagen | Gepland onderhoudsvenster of stop, soms één of enkele keren per jaar |
| Goedkeuring | Eigen IT-afdeling | Systeemleverancier moet patch kwalificeren |
| Herstart | Meestal acceptabel buiten kantooruren | Kan productie of een continu proces stilleggen |
| Levensduur systemen | 3–5 jaar | 15–25 jaar of langer |
| Testen | Pilotgroep, automatische uitrol | Testsysteem of digital twin, handmatige uitrol per node |
| Firmware | Beperkt (BIOS, netwerkapparatuur) | Groot deel: PLC’s, IO-modules, schakelaars, SIS |
De kern van het verschil: in IT is een niet-gepatcht systeem vaak het grootste risico, in OT kan een slecht geteste patch zelf een productie- of veiligheidsincident veroorzaken.
🧱 Hoe ziet het patchproces eruit?
- Inventarisatie van assets - een actuele asset-inventaris met firmware- en softwareversies; een SBOM laat zien welke componenten in een product zitten
- Instroom van kwetsbaarheden - meldingen uit leveranciersadvisories (bijvoorbeeld Siemens ProductCERT, dat op de tweede dinsdag van de maand publiceert), de KEV-catalogus van CISA, NCSC-adviezen en vulnerability scans
- Risicobeoordeling en prioritering - combineer ernst (CVSS), kans op misbruik (EPSS, KEV) en blootstelling van het systeem
- Leveranciersgoedkeuring - controleer of de OEM of systeemleverancier de patch heeft gekwalificeerd voor uw versie van het besturingssysteem
- Testen - eerst op een testsysteem, reservesysteem of redundante node
- Planning via change management - wijzigingsaanvraag, onderhoudsvenster, terugvalplan en een actuele back-up
- Uitrol naar productie - gefaseerd, met procesoperators op de hoogte
- Verificatie - controleer of de patch actief is en het proces normaal draait; volg logging en alarmen
- Documentatie en rapportage - leg patchstatus en uitzonderingen vast voor configuratiebeheer en audits
📊 Hoe prioriteert u patches op basis van risico?
CVSS meet de technische ernst van een kwetsbaarheid, niet het risico voor uw organisatie. Een goede prioritering combineert meerdere signalen:
| Signaal | Wat het zegt | Typische waarde of drempel |
|---|---|---|
| CVSS (v3.1 / v4.0) | Technische ernst | Kritiek 9,0–10,0; hoog 7,0–8,9; midden 4,0–6,9 |
| EPSS (FIRST) | Kans op misbruik in de komende 30 dagen | Kans tussen 0 en 1; versie 4 sinds maart 2025 |
| CISA KEV | Aantoonbaar actief misbruikt | Opgenomen in de catalogus: altijd voorrang |
| Blootstelling | Bereikbaar vanaf internet, kantoornet of alleen lokaal? | Internet- of DMZ-systemen eerst |
| Impact op proces | Gevolg bij uitval of manipulatie | Systemen met SIS of kritieke productie hoger |
Het Amerikaanse CISA verving op 10 juni 2026 richtlijn BOD 22-01, met vaste KEV-termijnen van twee weken voor recente CVE’s, door BOD 26-04. Die laat de termijn afhangen van blootstelling, actief misbruik, automatiseerbaarheid en technische impact, met deadlines van drie dagen tot “bij de volgende systeemupgrade”. Dat sluit aan bij de OT-praktijk: een kritieke CVE op een geïsoleerde HMI kan rustig mee in de volgende stop, terwijl een actief misbruikte kwetsbaarheid in een remote-access-gateway direct aandacht vraagt.
🔐 Welke obstakels maken patchen in OT lastig?
| Obstakel | Uitleg |
|---|---|
| Legacy-systemen | HMI’s, engineering stations en historians draaien vaak op Windows-versies zonder support (XP, 7 en sinds oktober 2025 ook de meeste Windows 10-edities) |
| Leverancierscertificering | De systeemleverancier test Microsoft- en andere patches op compatibiliteit; een niet-goedgekeurde patch kan support of garantie kosten |
| Productiecontinuïteit | Herstarten betekent vaak een procesonderbreking; patchen wacht op een geplande stop |
| Firmware op controllers | PLC’s draaien op eigen firmware; een update vraagt vaak een stop van de controller en hertesten van de applicatie |
| Veiligheid en validatie | Wijzigingen aan een SIS vallen onder IEC 61511; in de farma-industrie geldt revalidatie volgens GMP |
| Offline-systemen | Geen internetverbinding; patches gaan via een gecontroleerde route of gescande media |
🛡️ Wat doet u als u niet kunt patchen?
Als een patch niet beschikbaar is, niet is goedgekeurd of pas bij de volgende stop kan worden geïnstalleerd, zet u compenserende maatregelen in volgens het principe van defense in depth:
- Netwerksegmentatie - plaats het systeem in een aparte zone met strikte firewall-regels en een conduit naar boven
- Application whitelisting - laat alleen bekende software draaien; dit werkt goed op statische OT-systemen
- Hardening - schakel ongebruikte diensten en protocollen uit, zoals SMBv1
- Beperkte toegang - toegang op afstand alleen via een jump server met MFA
- Monitoring - een OT-IDS signaleert misbruikpogingen op niet-gepatchte systemen
- Vervangen - plan migratie van systemen die structureel geen updates meer krijgen
IEC 62443-2-1:2024 erkent dit expliciet: binnen het element voor componentbeveiliging vraagt de norm om patchbeheer én om mitigatie voor componenten die niet meer worden ondersteund. Leg elke uitzondering vast in een risicoregister met eigenaar en herbeoordelingsdatum.
📜 Welke normen en wetten stellen eisen aan patchmanagement?
| Kader | Wat het vraagt |
|---|---|
| IEC TR 62443-2-3:2015 | Technisch rapport over patchbeheer in IACS, met rollen voor asset owner en leverancier en een uitwisselformaat voor patchinformatie |
| IEC 62443-2-1:2024 | Securityprogramma voor asset owners, inclusief patchbeheer en mitigatie voor niet-ondersteunde componenten |
| IEC 62443-2-4 | Eisen aan systeemintegratoren en serviceleveranciers, onder meer voor het leveren en testen van patches |
| NIS2 / Cyberbeveiligingswet | Artikel 21 vraagt beveiliging bij onderhoud en kwetsbaarheidsbeheer; de Nederlandse wet is sinds 15 augustus 2026 van kracht |
| Cyber Resilience Act | Fabrikanten leveren gratis beveiligingsupdates gedurende een supportperiode van in de regel minimaal vijf jaar; meldplicht sinds 11 september 2026, volledig van toepassing vanaf 11 december 2027 |
| ISO 27001:2022 | Beheersmaatregel A.8.8: technische kwetsbaarheden tijdig identificeren en behandelen |
| NIST SP 800-40 Rev. 4 | Ziet patchen als preventief onderhoud dat leiding en techniek samen plannen |
De CRA verschuift de verantwoordelijkheid deels naar de fabrikant: elke beveiligingsupdate moet minimaal tien jaar beschikbaar blijven (of de rest van de supportperiode als die langer is), en de einddatum van de supportperiode moet bij aankoop vermeld staan, zodat u producten daarop kunt vergelijken.
🏭 Hoe richt u patchmanagement in een OT-omgeving in?
Een werkbare aanpak voor een Nederlandse productielocatie:
- Rollen - leg vast wie wat doet: IT beheert vaak de Windows-servers, OT de controllers en de leverancier de kwalificatie; zonder afstemming tussen IT, OT en leveranciers vallen systemen tussen wal en schip
- Beleid - leg per zone vast hoe snel patches worden beoordeeld (bijvoorbeeld binnen 14 dagen) en geïnstalleerd (volgende onderhoudsstop, of direct bij KEV-status en blootstelling)
- Leverancierscontracten - eis in inkoop en onderhoudscontracten patchkwalificatie, een SBOM en een opgegeven supportperiode, in lijn met leveranciersbeveiliging
- Patch-repository in de DMZ - goedgekeurde patches staan op een tussenserver in de DMZ, niet rechtstreeks vanaf internet
- Tools - Microsoft Configuration Manager (voorheen SCCM) of WSUS (sinds september 2024 deprecated, nog wel ondersteund) voor Windows; ManageEngine of Ivanti voor patchbeheer op meerdere platforms; Qualys of Tenable voor detectie van ontbrekende patches; Claroty, Nozomi of Dragos voor zicht op OT-assets en kwetsbaarheden; leveranciersportalen van Siemens en Rockwell Automation voor goedgekeurde patches
- KPI’s - gemiddelde tijd tot patchen per prioriteit, percentage assets binnen de gestelde termijn, aantal open uitzonderingen en aandeel systemen zonder leveranciersondersteuning
❓ Veelgestelde vragen
Hoe vaak moet u OT-systemen patchen?
Er is geen vaste frequentie: OT-systemen worden meestal gepatcht in geplande onderhoudsvensters, van maandelijks bij redundante servers tot jaarlijks of minder bij continue processen. Patchmanagement in OT stelt daarom risico boven ritme. Actief misbruikte en bereikbare kwetsbaarheden krijgen voorrang, de rest volgt bij de volgende stop.
Wat is het verschil tussen patchmanagement en vulnerability management?
Vulnerability management is het bredere proces van het vinden, beoordelen en behandelen van alle kwetsbaarheden. Patchmanagement is één behandeloptie daarbinnen: het installeren van een update. Als patchen niet kan, kiest vulnerability management voor compenserende maatregelen of risicoacceptatie.
Mag ik een Windows-patch zelf installeren op een SCADA-server?
Alleen als de leverancier van het SCADA- of DCS-systeem die patch heeft goedgekeurd voor uw softwareversie. Leveranciers als Siemens en Rockwell Automation publiceren compatibiliteitslijsten voor Microsoft-updates. Een niet-gekwalificeerde patch kan de werking verstoren en support of garantie kosten.
Wat is IEC TR 62443-2-3?
IEC TR 62443-2-3 is een technisch rapport uit 2015 over patchbeheer in industriële automatiserings- en besturingssystemen. Het beschrijft de taken van asset owners en leveranciers en een standaardformaat waarmee leveranciers patchinformatie en compatibiliteit doorgeven. Het is een richtlijn, geen certificeerbare norm.
Wat verandert de Cyber Resilience Act voor patchmanagement?
De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen om gedurende de supportperiode, in de regel minimaal vijf jaar, gratis beveiligingsupdates te leveren. Ook moeten zij actief misbruikte kwetsbaarheden sinds 11 september 2026 melden. Voor asset owners wordt patchbaarheid daarmee een harde inkoopeis.
Wat is Patch Tuesday?
Patch Tuesday is de tweede dinsdag van de maand, waarop Microsoft zijn maandelijkse beveiligingsupdates uitbrengt. Ook OT-leveranciers als Siemens en Schneider Electric publiceren hun beveiligingsadviezen op die dag, zodat asset owners hun patchmanagement op één vast moment kunnen plannen. Voor OT-systemen betekent Patch Tuesday niet direct installeren: eerst volgt de kwalificatie door de systeemleverancier.
📌 Samengevat
Patchmanagement is het risicogestuurde proces van inventariseren, prioriteren, testen, uitrollen en verifiëren van updates, zodat systemen veilig, stabiel en compliant blijven.
In IT draait het om snelheid en automatisering; in OT om leveranciersgoedkeuring, onderhoudsvensters en compenserende maatregelen waar patchen niet kan. Met IEC 62443, NIS2 en de Cyber Resilience Act is aantoonbaar patch- en kwetsbaarheidsbeheer een kritieke bouwsteen van elke cybersecuritystrategie, zeker in omgevingen met veel legacy- en OT-systemen.