Een zero-day-defect, wat nu?

Op 13 december 2022 rond negen uur in de ochtend kregen wij het bericht dat er een zero-day-defect in de Fortinet Firewalls, die meerdere relaties van ons en wijzelf gebruiken, was gevonden.

Een zero-day-defect is een kwetsbaarheid in bijvoorbeeld software of functionaliteit van een systeem, waarvan de leverancier of ontwikkelaar niet weet dat deze kwetsbaarheid bestaat. En omdat het onbekend is, is er ook nog geen oplossing voor.

We monitoren diverse kanalen waardoor deze meldingen ons op een gestructureerde manier bereiken. Tegelijkertijd werden wij ook door één van onze relaties benaderd met de vraagstelling of er een mogelijke verstoring aan hun firewall was.  

Op het moment dat er een dergelijke defect aan de orde is, zul je direct actie moeten ondernemen. In deze blog geven wij aan hoe wij dit procesmatig hebben aangepakt.

Ondernomen stappen

Stap 1:

De eerste stap is het intern delen van de informatie. Dit zorgt ervoor  dat, als onze klanten bellen, wij hen kunnen aangeven dat wij op de hoogte zijn en bezig zijn met het onderzoek en hen updates zullen geven.

Stap 2:

Direct daarna hebben wij een team gevormd dat de impact van het zero-day-defect analyseert.

Het zero-day-defect had betrekking op een fout in de SSL VPN functionaliteit. Een functionaliteit die nodig is voor bijvoorbeeld thuiswerkers.

Onze relaties, die een Fortinet Firewall hebben en deze functionaliteit niet gebruiken (waar de functionaliteit dus uit staat), werden niet geraakt.

De relaties, die wel gebruik maken van deze SSL VPN functionaliteit, zijn onmiddellijk geïnformeerd.

Het goed op orde hebben van een CMDB draagt hiertoe bij.

Stap 3:

Uit de analyse is naar voren gekomen, dat het installeren van de laatste minor firmware de definitieve oplossing voor het defect was.

Een minor firmware is een release binnen een major branch 6.2.x, 6.4.x  of bijvoorbeeld 7.0.x.

Zo’n minor release bevat over het algemeen geen functionele wijzigingen maar dient voor het oplossen van defects. Wat je niet wilt is een upgrade installeren die allerlei instellingen verandert.

Terug naar het proces van het oplossen van het defect. Omdat we, sinds de coronatijd, te maken hebben met veel thuiswerkers, hebben we gezocht naar een oplossing waarbij we de SSL VPN functionaliteit niet uit hoefden te zetten.

Stap 4:

Mede door het vermelde in stap 3, hebben wij een whitelist met IP-adressen van thuiswerkers, die op dat moment ingelogd waren, geconfigureerd. Deze IP-adressen waren terug te vinden in de firewall.

Een gebruiker waarvan het IP niet in de whitelist stond moest ons eerst haar/zijn IP-adres doorgeven om weer gebruik te kunnen maken van de SSL VPN functionaliteit.

Rond 13:00 uur was deze actie afgerond.

Door deze workaround uit te voeren konden thuiswerkers gebruik blijven maken van de SSL VPN functionaliteit waarbij het defect niet bereikbaar was vanaf het gehele internet.

Stap 5:

In de loop van de dag zijn alle firewalls voorzien van de laatste minor software versie, waarmee er een definitieve oplossing was voor het probleem.

Wij hebben, met iedere individuele relatie een tijdstip, voor het uitvoeren van de upgrade, afgestemd.

Relaties, die van onze Firewall as a Service (FaaS) dienst gebruik maken, zijn geïnformeerd over een noodonderhoud die buiten kantoortijd werd uitgevoerd.

Omdat onze FaaS dienst een redundante oplossing is, zijn de standaard firewall functionaliteiten tijdens de upgrade niet onderbroken. Denk hierbij aan packet-filtering en port-forwarding.

De actieve SSL VPN en IPSec sessies zijn wel onderbroken bij de uitvoering van de upgrade. De impact op de gebruikers is minimaal geweest doordat het onderhoud buiten kantoortijd is uitgevoerd. Na de upgrade zijn de whitelist workarounds weer verwijderd.

Stap 6:

We hebben ook gekeken of het defect misbruikt is. Dit hebben wij gedaan aan de hand van instructies van onze leverancier.

Omdat de firewalls, die in ons beheer zijn, gebruik maken van onze centrale logging faciliteit konden we zien of er aanwijzingen waren dat er aanvallen zijn geweest voordat de whitelists waren ingeregeld.

Wij hebben géén aanwijzingen gevonden.

Conclusie

In dit soort gevallen wil je dat één en ander zo snel mogelijk veilig is. Je moet op zo’n moment direct handelen. Dit betekent ook dat je bepaalde keuzes moet maken en overwogen beslissingen moet nemen.

In bovenstaand geval was het uitzetten van de SSL VPN functionaliteit de snelste oplossing geweest. Maar we zagen dat er tientallen gebruikers waren ingelogd en hebben daarom besloten dat niet te doen en voor een workaround situatie te kiezen.

Het uitzetten van de SSL VPN functionaliteit, die een onderbreking zou veroorzaken, zou leiden tot tientallen belletjes van gebruikers. En dat zorgt vervolgens voor werkdruk op de supportafdeling terwijl je die tijd juist nodig hebt voor het realiseren van een oplossing.

Als we terugkijken, dan vinden wij dat de juiste keuzes zijn gemaakt. Zeker gezien het feit dat wij met de logs konden zien of er wel/geen misbruik was gemaakt van het defect.

Wil je meer weten over hoe je zero-day kwetsbaarheden zo veel mogelijk kunt voorkomen? Neem contact met ons op, we helpen je graag.