Als er een security patch beschikbaar komt voor een applicatie, wordt deze doorgaans zo snel mogelijk uitgevoerd. En gelukkig maar, want je wil het risico op een kwetsbaarheid binnen je organisatie zoveel mogelijk beperken. Wel wordt doorgaans een belangrijk aspect vergeten bij het uitrollen van de patch: de performance van het systeem. Vaak wordt nog niet gerealiseerd dat dit serieuze impact kan hebben op de ervaring van de gebruiker.
Toen Intel een patch aankondigde voor de kwetsbaarheden ZombieLoad, RIDL en Fallout, werd zelfs expliciet aangegeven dat de patch de prestaties van de processoren kon beïnvloeden, bijvoorbeeld door het uitschakelen van Hyper-Threading. In opdracht van enkele klanten hebben we daarom direct na het uitrollen van de patch verschillende applicaties onderworpen aan performancetesten. Zo konden we valideren of de patches daadwerkelijk invloed hadden op de performance (responstijden, maximale capaciteit etc.). Op basis van verschillende load- en stresstesten was de conclusie dat de responstijden van de applicaties niet werden beïnvloed en de eindgebruiker geen hinder heeft ondervonden.
Performance-verlies bij patches voor Spectre en Meltdown
Waar het installeren van de ene security patch de responstijden niet heeft beïnvloed, kan de volgende security patch wel tot ernstig performance-verlies leiden.
Betekent dit dat de test voor niets was? Zeker niet! Iedere patch voor een kwetsbaarheid in combinatie met de infrastructuur van de organisatie is anders. Ook dit artikel geeft aan dat de patch voor Zombieload onder bepaalde workloads wel tot ernstig performance-verlies kan leiden. Verder hebben we bij Computest in het verleden bij klanten ervaren dat load- en stresstesten na uitrol van patches voor Spectre en Meltdown, een performance-verlies van 16% lieten zien. In deze gevallen werd een capaciteitslimiet sneller bereikt door een sneller toenemende CPU-belasting op de onderliggende infrastructuur. Deze degradatie werd waargenomen aan de hand van het maximumaantal pageviews per seconde, dat kon worden verwerkt door het applicatie-landschap.
In onderstaande grafiek is het CPU-gebruik van een server zichtbaar tijdens twee stresstesten. De blauwe lijn vertegenwoordigt de baseline-stresstest, voor de uitrol van de Spectre en Meltdown patches. In de gele lijn is het CPU-gebruik, onder dezelfde load, van dezelfde server zichtbaar, tijdens de effectmeting. Duidelijk is te zien dat de limieten (de afvlakking bovenin de grafiek) eerder worden bereikt, nadat de patches waren uitgerold.
De focus op het snel uitrollen van een security patch valt niemand kwalijk te nemen. De impact van een kwetsbaarheid die wordt misbruikt, kan immers vele malen groter zijn dan een verminderde performance. Hoe kun je performance-wijzigingen dan zo snel mogelijk vaststellen na de implementatie van security patches?
Snel beschikking over performance-expert
Hoe kun je performance-wijzigingen zo snel mogelijk vaststellen na de implementatie van security patches?
Idealiter voer je, voordat je de patch in productie uitrolt, een performance-test uit op de acceptatie-omgeving. Hiermee krijg je direct inzicht in de gevolgen van de patch voor je productie-omgeving. Daarvoor is het belangrijk om ervoor te zorgen dat je in het proces snel de beschikking hebt over een performance-expert, zodat ook eventuele performance-impact in kaart kan worden gebracht bij de uitrol van security patches. Het mooist is natuurlijk om daarbij te werken volgens de DevOps-methodiek in een team waarin de disciplines performance, security en beheer vertegenwoordigd zijn.
Door deze werkwijze blijft de onverminderde focus op security van je omgeving bestaan zonder dat performance onbedoeld pas na het uitrollen van een patch een issue wordt van de eindgebruiker.