Als een software-updateproces mislukt, kan dit catastrofale gevolgen hebben, zoals we gezien hebben met de wijdverspreide ‘blue screens of death’ die werden toegeschreven aan een slecht uitgevoerde update van CrowdStrike.
Cybersecurity gaat vaak over snelheid; een dreigingsactor creëert een kwaadaardige aanvalstechniek of -code, cybersecuritybedrijven reageren op de nieuwe dreiging en passen, indien nodig, hun methodes aan om de bedreiging te detecteren. Die aanpassing kan vereisen dat cloud-detectiesystemen en/of endpoint-toestellen moeten worden bijgewerkt om de nodige bescherming tegen die bedreiging te bieden. Als bedreigingen zich voordoen is snelheid dus van essentieel belang, en de cybersecuritysector er is om te beschermen, te detecteren en te reageren.
Cybersecuritybedrijven implementeren doorgaans ingrijpende processen om conflicten tussen een update en het besturingssysteem of andere producten te voorkomen. Het gaat daarbij om geautomatiseerde testomgevingen waarin real-world scenario’s van verschillende besturingssystemen, verschillende varianten van systeemstuurprogramma’s en dergelijke gesimuleerd worden.
In sommige gevallen kan dit door mensen overzien worden. Het gaat hierbij om een keuring die bewijst dat alle processen en procedures gevolgd werden en dat er geen conflicten zijn. In deze mix kunnen er ook derde partijen betrokken zijn, zoals een leverancier van een besturingssysteem, die onafhankelijk van de leverancier van cyberbeveiliging, testen uitvoert om een grote uitval te voorkomen, zoals we hebben kunnen zien.
In een perfecte wereld zou een cybersecurityteam de update testen in de eigen omgeving, om te zorgen dat er geen incompatibiliteit is. Zodra het zeker is dat de update geen problemen veroorzaakt, zou een geplande uitrol van de update beginnen, wellicht afdeling per afdeling. Het risico dat er voor de bedrijfsvoering een significant probleem ontstaat, wordt zo verkleind.
Dit is niet en kan ook niet het proces zijn voor updates van cybersecurityproducten. Deze moeten geïmplementeerd worden tegen dezelfde snelheid als die waarmee een bedreiging verspreid wordt, dus bijna onmiddellijk. Mislukt het updateproces, dan kan dat catastrofaal zijn, zoals dit het geval was met een software-update van CrowdStrike, met blue screens of death (BSOD) tot gevolg en volledige infrastructuren die plat lagen.
Het betekent helemaal niet dat de leverancier incompetent is. Het is wellicht een pechscenario, een perfecte storm van updates of configuraties die het incident veroorzaakt hebben. Tenzij de update natuurlijk gemanipuleerd werd door een kwaadwillende, wat hier niet het geval lijkt te zijn.
Wat kunnen we van dit incident leren?
Ten eerste zullen alle leveranciers van cybersecurity waarschijnlijk hun updateprocessen herzien om ervoor te zorgen dat er geen hiaten zijn en om te zien hoe ze deze nog kunnen versterken. Volgens mij is de echte les dat als een bedrijf een significante marktpositie bereikt, zijn dominantie een soort semi-monocultuur kan veroorzaken, één enkel probleem zal dan heel wat zaken beïnvloeden.
Elke cybersecurityprofessional zal termen gebruiken als ‘verdediging in de diepte’ of ‘verdedigingslagen’. Dit verwijst naar het gebruik van meerdere technologieën en, in de meeste gevallen, meerdere leveranciers om zo potentiële aanvallen af te weren. Het gaat ook om veerkracht in de architectuur en niet op één enkele leverancier te vertrouwen.
We mogen niet uit het oog verliezen wie de schuld draagt wanneer een incident als dit zich voordoet. Als cybercriminelen en aanvallers van natiestaten geen cyberdreigingen gecreëerd hadden, zouden we geen real-time bescherming nodig hebben.
Auteur : Tony Anscombe, ESET Chief Security Evangelist