applatenmaken.com/kennisbank/patchtermijnen

Binnen hoeveel tijd moet een kwetsbaarheid gedicht zijn?

Een kritiek lek in GitLab werd deze week binnen twee dagen na het uitkomen van de patch actief misbruikt. In dezelfde week kwamen er ernstige lekken naar buiten in Citrix NetScaler, in Apple-besturingssystemen en een grote noodronde bij Oracle. Deze pagina gaat over de vraag die daarop volgt: binnen hoeveel tijd moet uw leverancier zoiets bij u gedicht hebben, en hoe legt u dat vast.

Waarom uw onderhoudscontract hier meestal niets over zegt

De meeste onderhoudscontracten voor maatwerksoftware regelen reactietijden voor storingen en doorlooptijden voor wijzigingen. Beveiligingslekken vallen in geen van beide categorieën. Het is geen storing, want alles werkt gewoon, en het is geen wijziging die u heeft aangevraagd. Daardoor valt het door de mazen.

Dat was jarenlang geen groot probleem, omdat er weken zaten tussen het uitkomen van een patch en het moment dat iemand er misbruik van maakte. Die tijd is er niet meer. Zodra een leverancier een patch publiceert, is publiek te zien wat er is gerepareerd en dus wat er kapot was. Bij het GitLab-lek van deze week zaten er twee dagen tussen.

Praktisch betekent dat: als er in uw contract geen termijn staat, is de termijn in de praktijk de agenda van uw leverancier. Dat kan prima uitpakken, maar u heeft er geen zicht op en geen grond om iets af te dwingen op het moment dat het uitmaakt.

Wat er nieuw is
Kritieke lekken worden binnen dagen misbruikt, niet binnen weken.
Wat er ontbreekt
Beveiligingslekken vallen buiten de reactietijden voor storingen en wijzigingen.
Waarom dat nu telt
De Cyberbeveiligingswet legt de zorgplicht bij u, inclusief uw keten.
Wat u vastlegt
Termijnen naar ernst, en wie bepaalt welke ernst iets heeft.

Termijnen die redelijk zijn om af te spreken

Eén termijn voor alles werkt niet, want dan wordt hij ofwel onhaalbaar ofwel betekenisloos. Onderstaande indeling naar ernst is gebruikelijk en te onderbouwen. De precieze getallen bepaalt u samen met uw leverancier op basis van wat uw toepassing doet.

CategorieWat het betekentWaar u op let
Actief misbruiktEr wordt op dit moment aangevallen; alles gaat opzij!Dat hier een aparte, veel kortere termijn geldt dan bij kritiek zonder misbruik
KritiekOvername op afstand zonder inloggegevens!Dat de termijn in dagen wordt uitgedrukt en niet in weken
HoogErnstig, maar er is toegang of gebruikersinteractie nodig!Dat er een termijn staat en niet bij de eerstvolgende release
Middel en laagKan mee met regulier onderhoud!Dat er wel een uiterste grens is, anders blijven ze eeuwig staan
Niet van toepassing!Het lek zit in een functie die u niet gebruikt!Dat uw leverancier dat kan onderbouwen en niet alleen beweert

Let op de laatste regel. Een aanzienlijk deel van de meldingen raakt u niet, omdat u de kwetsbare functie niet gebruikt. Spreek af dat uw leverancier dat vaststelt en vastlegt, want anders krijgt u ofwel paniek over elk bericht ofwel stilte over alles.

Wat u naast de termijn afspreekt

Een termijn zonder de rest is een getal in een contract. Deze punten maken het werkbaar.

Het derde punt wordt het vaakst vergeten. Melden en dichten zijn twee verschillende termijnen, en de eerste heeft u nodig voor uw eigen afwegingen.

De laatste vraag lijkt administratief maar is dat niet. Zonder terugkoppeling kunt u bij een audit of een incident niet laten zien dat uw keten onder controle is, en dat is precies wat de zorgplicht van u vraagt. Wat daar verder bij hoort staat in de Cyberbeveiligingswet en uw softwareleverancier.

Wat als dichten niet meteen kan

Soms is er geen patch, of breekt de patch iets anders. Dat is geen uitzonderlijke situatie en het hoort in uw afspraken te zitten. De gebruikelijke route is een tijdelijke maatregel: de kwetsbare functie uitschakelen, de toegang ertoe beperken tot bekende adressen, of een filter ervoor zetten. Dat is minder mooi dan een patch en het koopt u de tijd die u nodig heeft.

Spreek af dat zo'n tijdelijke maatregel binnen dezelfde termijn valt als de patch zelf. Anders ontstaat de situatie waarin uw leverancier meldt dat er nog geen oplossing beschikbaar is en het daarbij laat. Er is bijna altijd iets te doen, ook als het definitieve antwoord nog niet bestaat.

Leg tot slot vast dat een tijdelijke maatregel een einddatum heeft. In de praktijk blijven noodoplossingen jarenlang staan omdat niemand meer weet waarom ze er zijn. Dat is precies het soort erfenis waar u tegenaan loopt bij een leverancierswissel of bij het uitfaseren van een systeem; zie een oud systeem uitfaseren.

Wat u zelf moet regelen

Twee dingen liggen aan uw kant. Het eerste is dat u bereikbaar bent. Een leverancier die u binnen vier uur moet informeren, kan dat niet als het enige contactpunt een algemene mailbox is die maandagochtend wordt gelezen. Wijs één persoon aan met een vervanger, en geef een nummer dat buiten kantoortijd werkt.

Het tweede is dat u kunt besluiten. Een noodpatch buiten kantoortijd betekent vaak een korte onderbreking van uw dienstverlening, en iemand moet daar op dat moment ja tegen zeggen. Als die beslissing eerst langs drie mensen moet, is uw termijn in de praktijk niet haalbaar hoe goed uw leverancier ook werkt.

Wie die persoon is en waar dat is vastgelegd, hangt samen met hoe verantwoordelijkheid voor software bij u is belegd. Dat staat in wie is bij u verantwoordelijk voor de software. Voor wat er in het bredere onderhoudscontract hoort, zie het onderhoudscontract. Wat er in uw situatie juridisch geldt, legt u voor aan een jurist; deze pagina is uitleg en geen juridisch advies.

Veelgestelde vragen

Hoe snel worden lekken tegenwoordig misbruikt?

Sneller dan de meeste contracten aannemen. Het kritieke GitLab-lek van deze week werd binnen twee dagen na het uitkomen van de patch actief misbruikt. Zodra een patch verschijnt is publiek zichtbaar wat er is gerepareerd en dus wat er kapot was, en die informatie volstaat om een aanval te bouwen.

Staat dit niet gewoon in mijn onderhoudscontract?

Meestal niet. Onderhoudscontracten regelen reactietijden voor storingen en doorlooptijden voor wijzigingen. Een beveiligingslek is geen van beide: alles werkt gewoon en u heeft er niet om gevraagd. Daardoor valt het buiten de afspraken, en is de feitelijke termijn de agenda van uw leverancier.

Welke termijnen zijn redelijk?

Werk met categorieën in plaats van één termijn. Actief misbruikte lekken vragen om onmiddellijke actie, kritieke lekken om een termijn in dagen, hoge lekken om een vastgelegde termijn die korter is dan uw reguliere onderhoudscyclus, en de rest kan mee met gewoon onderhoud mits er een uiterste grens is. De precieze getallen bepaalt u met uw leverancier.

Wie bepaalt hoe ernstig een lek is?

Leg dat expliciet vast, want anders ontstaat er discussie op het moment dat er haast is. Gebruikelijk is dat uw leverancier de indeling voorstelt op basis van een openbare classificatie en of de kwetsbare functie in uw toepassing wordt gebruikt, en dat u de mogelijkheid heeft om dat te betwisten.

Moet ik ook horen over lekken die mij niet raken?

Ja, maar anders. Spreek af dat uw leverancier vaststelt of een lek u raakt en dat vastlegt, en dat u periodiek een overzicht krijgt. Zonder die afspraak krijgt u ofwel bij elk nieuwsbericht paniek, ofwel maandenlang stilte zonder te weten of er iets is beoordeeld.

Wat als er nog geen patch beschikbaar is?

Dan hoort er een tijdelijke maatregel te komen binnen dezelfde termijn: de kwetsbare functie uitschakelen, de toegang beperken tot bekende adressen of een filter ervoor plaatsen. Er is bijna altijd iets te doen. Leg wel vast dat zo'n maatregel een einddatum heeft, anders blijft hij jaren staan zonder dat iemand nog weet waarom.

Wat moet ik zelf regelen om een korte termijn haalbaar te maken?

Bereikbaar zijn en kunnen besluiten. Een leverancier die u binnen vier uur moet informeren, kan dat niet als het enige contactpunt een algemene mailbox is. En een noodpatch betekent vaak een korte onderbreking, waar iemand op dat moment ja tegen moet zeggen. Wijs één persoon aan met een vervanger.

Hoe hangt dit samen met de Cyberbeveiligingswet?

De zorgplicht uit die wet ligt bij uw organisatie en omvat uitdrukkelijk de risico's in uw toeleveringsketen. Patchtermijnen met uw leverancier zijn een van de concreetste manieren om te laten zien dat u dat risico beheerst. Een terugkoppeling achteraf over wat er is gedicht en wanneer, is daarbij het bewijsstuk.

Verder lezen