4 min leestijd
U patcht niet elke kwetsbaarheid
Op een vrijdag om 16.05 uur publiceert de leverancier van de apparatuur voor toegang op afstand van een ingenieursbureau met 150 medewerkers een beveiligingsbericht: een kritieke kwetsbaarheid, beoordeeld met 9,8 op 10, treft alle versies, en er bestaat nog geen patch. De apparatuur staat bloot aan internet, en veertig ingenieurs verbinden zich er van thuis mee. De IT-afdeling telt drie mensen, en tweehonderd patches staan al in hun wachtrij. Het bedrijf is fictief, de situatie is alledaags: geen enkel team patcht alles, meteen, overal, en kwetsbaarhedenbeheer is dus een reeks keuzes, waarvan sommige verkeerd zullen zijn. Voorbereiding beperkt de schade wanneer dat gebeurt.
Een volume dat keuzes afdwingt
Elk jaar worden tienduizenden nieuwe kwetsbaarheden gepubliceerd. Patchen vraagt testen, een onderhoudsvenster vinden dat voor de activiteit aanvaardbaar is, soms wachten op een leverancier die zijn patch nog niet heeft gepubliceerd, zoals die vrijdag. Sommige systemen kunnen eenvoudigweg niet worden bijgewerkt: industriële apparatuur, medische toestellen, oude toepassingen waarvan niemand de code nog onderhoudt. In die omstandigheden komt prioriteiten stellen neer op het aanvaarden van een risico voor de rest, en dat is geen nalatigheid, het is de aard van het werk.
Het team van ons fictieve bedrijf weet dat maar al te goed. Zijn tweehonderd wachtende patches zijn niet allemaal gelijk, maar niets in de lijst zegt het: updates van werkstations staan naast kwetsbaarheden van servers, en het bericht van vrijdag komt binnen in een stroom waarin alles dringend lijkt. De vraag wordt dan die van het sorteren, dat wil zeggen waarnaar men kijkt om te beslissen.
Prioriteren is niet sorteren op score
De reflex is te sorteren op ernstscore. De CVSS-score meet de technische ernst van een kwetsbaarheid, niet de kans dat ze bij u wordt misbruikt, en die twee verschillen vaak. Meerdere vragen wegen zwaarder. Wordt de kwetsbaarheid al misbruikt in het wild? De catalogus van bekende misbruikte kwetsbaarheden, bijgehouden door het Amerikaanse agentschap CISA en aangeduid met de afkorting KEV, somt de kwetsbaarheden op waarvoor dat vaststaat. Is het betrokken systeem blootgesteld aan internet? Hoe belangrijk is het voor de activiteit? Bestaat er een compenserende maatregel, zoals het uitschakelen van een functie of het filteren van bepaalde toegangen? De EPSS-score, die de kans schat dat een kwetsbaarheid wordt misbruikt, helpt bovendien om gelijkaardige gevallen van elkaar te onderscheiden.
Toegepast op ons bedrijf geeft dit raster een duidelijk resultaat, ook al biedt de vrijdag nog niet alle antwoorden: blootgestelde apparatuur, essentieel voor het werk van veertig mensen, getroffen door een kritieke kwetsbaarheid zonder patch, gaat voor tientallen oudere kwetsbaarheden die diep in een intern netwerk zijn weggestopt.
De dag dat de niet-gepatchte kwetsbaarheid wordt misbruikt
Bij de Log4Shell-kwetsbaarheid, in december 2021, was de moeilijkste vraag voor veel organisaties niet “hoe patchen we dit?” maar “waar gebruiken we dit onderdeel?”. Weten wat men bezit, en in welke versie, hoort bij de voorbereiding, en dat regelt men niet op de dag van het bericht. De tijd tussen de publicatie van een kwetsbaarheid en het eerste misbruik kan bovendien heel kort zijn, soms enkele dagen.
Terug naar die vrijdag om 16.05 uur. Er moeten meerdere beslissingen worden genomen, en in de haast worden ze slecht genomen. Wie beslist om de apparatuur te isoleren, en kan dat doen zonder te wachten? Wie aanvaardt de impact op de activiteit, dat wil zeggen veertig ingenieurs die zich niet meer kunnen verbinden? Hoe zal men weten of men vóór de aankondiging al is gecompromitteerd, en hoelang bewaart men de verbindingslogs? Wie informeert de klanten als er mogelijk toegang tot gegevens was, en binnen welke termijn? Die vragen stelt men zich veel beter op een dinsdag in een vergaderzaal dan op een vrijdagavond. De antwoorden kunnen trouwens de vorm krijgen van vooraf afgesproken drempels: als een kwetsbaarheid wordt misbruikt en het systeem blootgesteld is, isoleert men het binnen een vaste termijn, en wordt de bedrijfsverantwoordelijke geïnformeerd, niet geraadpleegd.
Trager patchen, sneller reageren
Een late patch wordt goedgemaakt door het vermogen om te detecteren en te reageren, en dat vermogen wordt geoefend. De logs op het juiste moment beschikbaar hebben, het contact bij de leverancier kennen met zijn weekendnummer, weten hoe men een spoedwijziging start en hoe men terugkeert als die wijziging iets stukmaakt: dat alles leert men door het te spelen, niet door het te lezen. Een organisatie die het eenmaal heeft gespeeld, improviseert niet op vrijdagavond.
Voor ons fictieve bedrijf is het verschil concreet. Zonder voorbereiding leidt de vrijdag van 16.05 uur tot een avond van discussies en misschien tot een weekend van incident. Met een afgesproken isolatieregel, een bijgewerkte lijst van apparatuur en een geteste noodtoegang leidt ze tot een halve dag verminderde werking en tot een vastgelegde beslissing: het resterende risico is door iemand, met naam en toenaam, aanvaard tot de publicatie van de patch.