Testprocedures worden aangescherpt
CrowdStrike heeft de precieze oorzaak opgespoord van de computerstoring die afgelopen vrijdag overal ter wereld luchthavens, banken, ziekenhuizen en vervoersbedrijven platlegde. De leverancier van cybersecurity-software wijt grootschalige uitval van zakelijke Windows-computers aan een fout in de kwaliteitscontrole.
Een ‘bug’ in de tool (Content Validator) waarmee het bedrijf systeem-updates checkt op vergissingen, zorgde ervoor dat een kritieke fout in de software bleef zitten. Een van de twee ‘template instances’ slaagde ten onrechte voor de validatie. De update werd daarop ongehinderd doorgestuurd naar de computers van (eind)gebruikers met alle kwalijke gevolgen van dien.
Het ging om een zogenoemde ‘content configuratie-update’ voor de Windows-sensor die telemetrie moet verzamelen over mogelijke nieuwe bedreigingen en aanvalstechnieken van hackers. Deze updates vormen een routineklus. Ze zijn een vast onderdeel van de dynamische beschermingsmechanismen van CrowdStrike’s Falcon-platform.
Systeemcrash
De problematische Rapid Response Content-configuratie-update resulteerde in een Windows-systeemcrash. Deze snelle respons-inhoud is ontworpen om heel snel te reageren op veranderingen in het dreigingslandschap, aldus de verklaring die CrowdStrike woensdag uitbracht.
CrowdStrike geeft geen inzicht in de precieze aard van die inhoudsgegevens, noch waarom deze problematisch waren. Een ‘template instance’ is een reeks instructies die de software begeleidt bij het zoeken naar bedreigingen en hoe deze moet reageren. Volgens het cybersecuritybedrijf is inmiddels een ‘nieuwe controle’ aan zijn kwaliteitscontrole-proces toegevoegd om te voorkomen dat het probleem zich opnieuw kan voordoen.
Stapsgewijze aanpak
CrowdStrike reageerde ook op critici die zich afvragen of niet veel meer testprocedures nodig zijn voordat dit soort software massaal wordt uitgerold. Een stapsgewijze aanpak zou de schaal verkleinen van de problemen zoals die afgelopen vrijdag plaatsvonden, zo stellen veel experts. Dat zou zeker bij kritieke software moeten gebeuren die hele ecosystemen kan platleggen. Ook gingen stemmen op om dergelijke updates eerst in quarantaine uit te voeren.
De Amerikaanse leverancier is nu van plan om meer tests uit te voeren op het type update dat de crashes veroorzaakte voordat de nieuwe versie naar de klant gaat. Ook wil CrowdStrike voortaan updates geleidelijk uitrollen naar grotere groepen gebruikers. Als het bij zo’n ‘canary-implementatie‘ misgaat, blijft de ramp beperkt.
Miljardenstrop
Begin deze week zei CrowdStrike dat de bug wereldwijd 8,5 miljoen computers heeft getroffen. Veel van deze apparatuur maakte deel uit van grote bedrijfssystemen waardoor aanzienlijke schade is geleden. De financiële schade is groot. Volgens de Amerikaanse verzekeraar Parametrix hebben de vijfhonderd grootste Amerikaanse ondernemingen (exclusief Microsoft) een strop van 5,4 miljard dollar geleden. Hoogstwaarschijnlijk zullen er schadeclaims worden ingediend maar daar is op dit moment nog niets over bekend.
Ach ja, de kanarie in de mijn door uitrol wat geleidelijker te maken om zodoende de impact van fouten te verkleinen gaat nog altijd om het testen in het veld. En clausule van overmacht in het claimen van schade kunnen reizigers misschien succesvol aanvechten als de computerstoring het gevolg is van een slechte kwaliteitscontrole, zeg maar een verwijtbare nalatigheid. En wat betreft het erkennen van fouten wijs ik niet alleen naar Crowdstrike want organisaties die blindelings een leverancier vertrouwen zijn vooral gemakzuchtig in het ontzorgen.
Het blijft natuurlijk een korte berichtgeving, maar ik haal hier twee basis problemen uit die alles te maken hebben met het uitvoeren van een goede kwaliteits controle, dwz: Software testen.
Eerste probleem:
“van de twee ‘template instances’ slaagde ten onrechte voor de validatie.”
Ik lees hier vooral uit het feit dat de kwaliteitscontroles die hier gedaan worden niet veel verder gaan dan een automatische validatie. Dit noemen we “checken” of “valideren”.
Echt testen zit hier niet bij, exploratief testen en / of risico gebaseerde controle voor een specifieke verandering zitten meestal niet in standaard geautomatiseerde testscripts en dan gaat het een keer mis.
Zet een tester in die meedenkt en echt test, ipv te vertrouwen op geautomatiseerde checklists.
Tweede probleem
“Ook gingen stemmen op om dergelijke updates eerst in quarantaine uit te voeren.”
Misschien interpreteer ik het verkeerd, maar dit wordt dus niet eerst uitgerold in een testomgeving en dan bekeken? In quarantaine uitvoeren komt bij mij over als dat er een acceptatie omgeving mist. Lijkt mij vrij standaard. Een crashende Windows PC zou toch vrij makkelijk detecteerbaar moeten zijn in een testomgeving. Doet het niet = stoppen met uirrollen.
De kanarie uitrol is meer een pleister op de wond: de echte (zou je ook kanarie strategie kunnen noemen) is een goede teststrategie (niet alleen checken), professionele testers inhuren en goede testomgevingen gebruiken voordat je naar productie gaat.
Bij Volmac leerden we “Foutloos programmeren”. In de militair gedrilde opleiding kon je je misschien één foutje permitteren maar bij meer lag je er meestal wel uit.
Testen, en met name regressie testen zijn vaak sluitpost van een IT project en daarmee ontstaat ook de kans dat er in productie alsnog veel fout kan gaan.
In dit geval is een changemanagement plan uiteraard een mogelijke oplossing om de kans op schade te beperken. Bij aanpassingen in de kernal software binnen een operating systeem dient ook de goedkeuring en een proefproductietest door de OS fabrikant plaats te vinden, in dit geval Microsoft.
Ook bij de implementatie dient dan ook verplichte gefaseerde uitrol plaats te vinden, in sectoren waar de schade relatief beperkt is, dus luchtvaartmaatschappijen, luchthavens , ziekenhuizen en banken met kwetsbare betaalsystemen niet als eerste fase maar als laatste fase te implementeren.
Dit kun je dan zien als een proven technology gefaseerde uitrol methode van kritische systeemcomponenten.
Tegenwoordig is door de snelle ontwikkelmethodes, o.a. Agile/Scrum een vaak geïntegreerde testfase tijdens de bouwfase. Ook daar moet nog eens goed naar gekeken worden.
De uitvinder van deze methode heeft ook al eens verklaard dat de praktijk van de methode soms niet volgens de richtlijnen wordt opgevolgd, waardoor de kwaliteit niet goed gewaarborgd is.
Precieze oorzaak in de techniek afschuiven: dat is wel makkelijk natuurlijk
De werkelijke oorzaak ligt ergens anders: was er wel een mens betrokken bij het testproces? Een goede tester ziet zoveel meer dan alle net-niet-alles-testende en foutgevoelige geautomatiseerde tests..
Manueel testers, testengineers met een focus op handmatig testen worden wegbezuinigd en vervangen door deze geautomatiseerde testscripts.. Je ziet waartoe dit kan leiden, en in dit geval ook heeft geleidt.
en laat de schadeclaims maar komen: ik zie een donkere toekomst voor Crowdstrike en als zij zich hiervoor niet afdoende heeft verzekerd, zelfs het begin van het eind van dit bedrijf.
Nee, het was niet de techniek maar het proces of eigenlijk de shortcut daarin door te testen in het veld met alle gevolgen van dien. Wel of geen mens betrokken bij de door Dino voorgestelde smoke test is niet relevant want de uitkomst is binair, het werkt wel of het werkt niet is een basale test die je kunt automatiseren. De kanarie in de mijn gaat tenslotte om een van zijn stokje vallend vogeltje door een ongezonde concentratie van mijngassen. Want de ‘nieuwe controle’ aan het kwaliteitscontrole-proces geeft nog geen zekerheid door een verscheidenheid aan updates, een samenloop van omstandigheid is nog niet uitgesloten doordat ook Microsoft een automatisch proces van updates kent.
Mijn stokpaardje van het configuratiemanagement gaat om de processen want de kwaliteitscontrole in ketens laat nog te wensen over doordat er voor CI wel getest moet worden tegen de juiste versies, het afstemmingsproces in geautomatiseerde updates gaat om het ketenbeheer van silo’s die niks met de techniek te maken hebben omdat het versiebeheer gewoon een administratieve last is. Impact van verstoring met ketens waarin Microsoft dominant is gaat om een complexe schuldvraag van veel geld en weinig zekerheden, de kale kip valt niet te plukken maar hoe zit het met de vetgemeste kalkoen?
De bug heeft niet wereldwijd 8,5 miljoen computers getroffen maar vooral Windows endpoints wat om een kanarie in de mijn gaat die al van z’n stokje valt als een foutieve update tot een BYOD leidt. Democratische processen in de ICT zijn leuk maar zolang de gebruiker vraagt om een Windows PC dan zit er vooral wat fout in de uitvraag.
Redactionele opmerking: BSOD, niet BYOD
De ‘canary-implementatie‘ is prima, maar altijd eerst in je eigen testomgeving uittesten. In dit geval op de operating systems van je klanten met de laatste updates en zonder de laatste updates. Een typische CrowdStrike klant zou dat ook moeten doen, kost een beetje, kan later veel meer schelen.