Inhoudsopgave:
Hoe werkt een patch?
Een patch is een stukje software dat additioneel gedownload wordt bij een softwarepakket, en hierboven op geïnstalleerd wordt. Patches worden gebruikt voor upgrades, updates, bug fixes, of de toevoeging van nieuwe functionaliteit. Ze worden ontwikkeld door de softwareleverancier zelf, of door andere personen, die meestal over de broncode beschikken (open source software).
Zijn patches gratis?
In veel gevallen wel. Patches ontwikkeld door de leverancier van een geïmplementeerd softwarepakket, zitten meestal inbegrepen in de maintenance fee. Beveiliging, maar ook nieuwe functionaliteit kan zo toegevoegd worden, en daarvoor hoeft in de meeste gevallen niet extra te worden betaald. Niet alle extra functionaliteiten of beveiligingsproducten worden echter als gratis patches aangeboden. Een patch is meestal een prestatieverbetering van wat al geïmplementeerd is. In tegenstelling tot een volledig nieuwe module, die gepaard gaat met een implementatie en bijbehorende factuur. Er bestaan geen echte ‘regels’ voor het al dan niet aanrekenen van patches. Uiteindelijk beslist de leverancier dit gewoon zelf.
Interessant: er is veel discussie over betaalde patches, vooral wat betreft IT-security. Velen beargumenteren dat beveiligingspatches altijd gratis zouden moeten zijn. Anderen op hun beurt zeggen dat de consument geen absoluut recht heeft op een ‘foutloos’ of ‘onverslijtbaar’ product. Volgens deze redenering zijn patches dan alleen inbegrepen als je overstapt op een nieuwere softwareversie (waar vaak wel voor moet worden betaald).
Het belang van goed patchbeheer
Weinig bedrijven hebben een goed overzicht van welke patches toegepast zijn op de bestaande software, en of er hiaten zijn. En zelfs als dit bekend is, is er vaak terughoudendheid om alle beschikbare patches toe te voegen. Dit heeft verschillende redenen:
- Het is soms moeilijk te controleren of alle patches in het bedrijfsnetwerk up-to-date zijn. Zeker als het bedrijf bepaalde ICT-taken outsourcet, raakt het overzicht al snel zoek.
- Het toepassen van patches kan gepaard gaan met downtime (zoals een PC die niet meteen opstart omdat er updates moeten worden uitgevoerd).
- Er is vaak angst voor het onbekende. Uit vrees voor de impact op bedrijfsprocessen, blijven sommige bedrijven liever bij het oude bekende, ook al zijn er gebreken aan te wijzen.
“Our recent research revealed that more than 80 percent of CIOs have refrained from adopting an important security update or patch due to concerns about the impact it might have on business operations.” – Matt Ellard, EMEA Managing Director at Tanium in Computer Business Software.
Toch is het voor een bedrijf belangrijk het patchbeheer in strakke banen te leiden. Patches voor nieuwe functionaliteit zijn in dit opzicht vaak minder belangrijk, al kunnen ze wel een competitief voordeel opleveren ten opzichte van de concurrentie. De vlakken waarop bedrijven echter zeker moeten zorgen dat patches up-to-date zijn, zijn de volgende:
- Beveiliging: niet-gepatchte netwerken zijn kwetsbaar (security-patches). Vergeet hierbij ook de persoonlijke toestellen waarmee werknemers aanmelden op het bedrijfsnetwerk niet (BYOD).
- Probleemoplossing: de leverancier lost softwareproblemen vaak niet op totdat alle update-patches in orde zijn (zelfs al is het probleem niet gerelateerd aan de patch).
- Auditing: bepaalde patches moeten in orde zijn voor een positieve keuring (het soort patches hangt af van de sector en het soort keuring).
Heb je voor patchbeheer een specialist nodig?
Patchbeheer kan ingewikkeld worden, zeker voor bedrijven met veel IT-toepassingen, netwerken en outsourcing. Vandaar dat de meeste organisaties een (externe) specialist in de arm nemen. Dit kan een medewerker van de softwareleverancier zelf zijn die (parttime of fulltime) bij het bedrijf aan het werk is. Het is ook mogelijk om een patch management tool te gebruiken. Maar ook dan moet er bepaalde technische kennis aanwezig zijn. Een specialist snapt uit de patchinformatie bijvoorbeeld direct of:
- er een reboot van het systeem nodig is, en er dus downtime zal optreden;
- het onderliggende dataformaat moet worden geüpdatet;
- bepaalde code van maatwerk (custom code) aangepast moet worden;
- etc.
Deze informatie helpt het bedrijf om keuzes te maken over het al dan niet installeren van de patch, hoe de installatie van de patch kan worden aangepast, en welke voorzorgsmaatregelen kunnen worden genomen. Een ziekenhuis kan er bijvoorbeeld voor zorgen dat de patch geïnstalleerd wordt op het moment dat de downtime geen invloed heeft op operaties. Ook een back-up voor wanneer er complicaties opduiken met het nieuwe dataformaat is vaak een goede maatregel.
Kunnen patches zelf ontwikkeld worden?
In principe kan iedereen die over de broncode van een softwarepakket beschikt, of die wat van reverse engineering kent, een patch ontwikkelen. Voor software met een open broncode is dit zelfs de meest voorkomende manier om een bijdrage te leveren aan de software. Wie een bijdrage levert, moet deze als patch naar de originele ontwikkelaar sturen voor verificatie en toevoeging. Goedkeuring door de originele ontwikkelaar is nodig, omdat de software anders door de continue stroom van (soms slechte) toevoegingen onstabiel zou kunnen worden.
Een patch ontwikkel je echter niet zomaar. De ontwikkelaar moet een degelijke softwarekennis hebben. Daarnaast moet hij of zij ervoor zorgen dat:
- de codestandaarden en documentatie voor het project gevolgd worden. De patch moet compliant zijn met de basissoftware;
- hij of zij weet wat de laatste versie is van de software. Als de patch op een voorgaande versie gemaakt wordt, zullen er compatibiliteitsproblemen optreden. Dit betekent niet dat de patch meteen in de prullenbak gegooid moet worden, maar de oplossing is vaak een extra stukje coding. Dit stukje moet bij een volgende update weer overgenomen en aangepast worden, en vergroot de kans dat deze update fout gaat;
- het voor anderen ook duidelijk is wat de patch doet, hoe hij geïnstalleerd moet worden, en hoe hij gebruikt wordt.
Opmerking: er bestaan ook niet-officiële patches. Deze worden gemaakt door mensen die niets met de originele ontwikkelaar te maken hebben. Dit kan een goede oplossing zijn voor producten die End-of-Life gaan, en waarvoor dus geen officiële patches meer uitkomen. Let wel op: deze patches geven geen garantie op succes, en kunnen in sommige gevallen zelfs schade toebrengen aan de systemen. Zorg er dus voor dat ze steeds beoordeeld worden door een specialist.
