Patchmanagement: een updatestrategie opbouwen voor je server

Waarom patchen de meest voorkomende manier is om binnen te komen

De meeste geslaagde server-inbraken draaien niet om een nieuwe aanvalsmethode. Ze draaien om een bekende kwetsbaarheid waar al een patch voor bestaat, maar die op een systeem met internettoegang gewoon niet is toegepast. Precies dat gat tussen het uitkomen van een patch en het toepassen ervan is het venster waar aanvallers op scannen, en door geautomatiseerd scannen kan dat venster binnen dagen na het bekend worden van een kwetsbaarheid al gevonden en misbruikt worden. Een consistente patchroutine sluit dat venster. Een inconsistente routine laat het onbeperkt openstaan.

Beveiligingspatches versus feature-updates

Niet elke update heeft dezelfde urgentie, en ze allemaal hetzelfde behandelen vertraagt kritieke fixes of introduceert onnodig risico bij routinematige updates.

• Beveiligingspatches verhelpen een specifieke kwetsbaarheid, meestal gekoppeld aan een CVE. Zodra er exploitcode bekend is of er actief misbruik plaatsvindt, is dit echt urgent en kan het niet wachten op een routinematig onderhoudsvenster.
• Feature-updates voegen functionaliteit toe of brengen bredere wijzigingen aan, en lopen meer risico op het breken van iets dat afhankelijk is van het huidige gedrag. Hier zijn een staging-omgeving en een gepland onderhoudsvenster precies voor bedoeld.

Een updatecadans bepalen

Een werkbare strategie draait meestal op twee snelheden tegelijk, in plaats van één enkel schema voor alles:

• Kritieke kwetsbaarheden, gepatcht zodra dat praktisch haalbaar is na het uitkomen, zeker voor alles met internettoegang of waarvan al bekend is dat het actief wordt misbruikt.
• Routinepatches, gebundeld in een vast onderhoudsvenster. Wekelijks of maandelijks is een gangbaar patroon, zodat wijzigingen voorspelbaar zijn, gecontroleerd worden, en de productie niet verstoren buiten een bekend tijdslot.

Automatisering versus handmatige controle

Tools zoals unattended-upgrades op Debian/Ubuntu of dnf-automatic op RHEL-achtige systemen kunnen beveiligingspatches automatisch toepassen, zonder dat er iemand naar hoeft te kijken. Dat is een redelijke standaardinstelling voor systemen met een lager risicoprofiel, waar uptime tijdens een automatische reboot geen probleem is. Voor productiesystemen, zeker systemen met een database of een wijzigingsproces waar andere teams van afhankelijk zijn, is handmatige controle vooraf meestal de veiligere aanpak: automatisering laat nog steeds zien wat er beschikbaar is, maar een mens beslist wanneer het wordt toegepast.

Altijd eerst testen in staging

Voordat een patch een productiedatabase bereikt, of een systeem waar andere diensten van afhankelijk zijn, test je hem eerst in staging. Vooral databasemotoren kunnen het gedrag van queries veranderen of een minor-versie met een fout uitbrengen, en dat in staging ontdekken kost niets. Dat in productie ontdekken kost een storing. Dit speelt het sterkst bij feature-updates en grote versiesprongen, minder bij een beperkte beveiligingspatch, maar de gewoonte om eerst te testen is in beide gevallen de moeite waard.

Bijhouden wat er geïnstalleerd is

Weten wat je huidige patchstatus is, is wat de rest hiervan mogelijk maakt. Op Debian/Ubuntu laat apt list --upgradable zien wat er openstaat. Op RHEL-achtige systemen doet dnf check-update hetzelfde. Op Windows Server toont de updategeschiedenis van Windows Update wat er is toegepast en wat er nog open staat. Ongeacht het platform: dit regelmatig checken, niet alleen wanneer er iets misgaat, is wat patchen verandert van reactief geploeter in een routine.