CrowdStrike deelt meer details over de update-fout die tot wereldwijde IT-chaos leidde. Een volwaardige Root Cause Analysis volgt, maar vandaag is een aanvankelijke en al vrij uitgebreide Post Incident Review (PIR) verschenen.
Een reguliere update aan een configuratiebestand voor de CrowdStrike Falcon-sensor leidde tot 8,5 miljoen gecrashte Windows-systemen. Eerder hebben we al uitgebreid de impact en initiële bevindingen over dit incident gedeeld. Nu laat CrowdStrike weten hoe de vork precies in de steel zat en hoe het de eigen processen gaat verbeteren.
Lees ook: CrowdStrike waarschuwt voor valse herstelhandleiding
Update voor Rapid Response Content
CrowdStrike kan niet zomaar de Falcon-sensor updaten. Dit is omdat het draait op kernel-niveau, een geprivilegieerde status waarvoor Windows Hardware Quality Labs (WHQL)-validatie een vereiste is. WHQL is een testproces van Microsoft om deze impactvolle drivers te valideren. De CrowdStrike-sensor zelf wordt via “Sensor Content” geüpdatet. Hiermee kan het bedrijf on-sensor AI- en ML-modellen wijzigen en andere features voor op de langere termijn uitbouwen. CrowdStrike benadrukt dat de Quality Assurance (QA) voor deze soort updates significant is. De verantwoordelijkheid is daarnaast altijd gedeeld met Microsoft. Als klap op de vuurpijl verschijnt Sensor Content via een slow rollout, waardoor eventuele problemen die QA wisten te omzeilen, nooit direct alle gebruikers raken. CrowdStrike heeft een digitale noodknop voorhanden om de uitrol stop te zetten als zorgelijke meldingen binnenkomen.
Het IT-incident van vrijdag kwam vanuit een andere koker: die van Rapid Response Content-releases. Deze updates verschijnen veel vaker dan Sensor Content, namelijk meerdere keren per maand, en voorzien zogeheten “Channel Files” van updates. Op deze manier detecteert de sensor nieuwe specifieke vormen van kwaadaardig gedrag. Dankzij deze updates kan CrowdStrike op de meest actuele dreigingen reageren. Idealiter merkt de eindgebruiker niets van deze functionaliteit.
Data vanuit de cloud (via het Content Configuration System) belandt in de Channel Files. Deze bestanden bewaren en valideren Template Instances. Opnieuw benadrukt CrowdStrike dat eventuele fouten dankzij een Content Interpreter “op elegante wijze” worden afgehandeld. Tot zover lijkt het erop dat CrowdStrike alles goed had dichtgetimmerd om grootschalige problemen te voorkomen.
Best practices ingezet, maar…
In de aanloop naar de wereldwijde IT-storing ging het dan ook lang goed. De Falcon-sensor bestaat al sinds 2013 en ook de afgelopen maanden verschenen updates probleemloos, stelt CrowdStrike. Er is bewijs voor dat dit niet waar is, trouwens: ook verschillende Linux-distributies zouden in april met een soortgelijk incident te maken hebben gehad. Hoe dan ook: in februari, maart en april vonden er updates plaats aan verschillende CrowdStrike-componenten zonder grootschalige problemen en met alle vereiste groene vinkjes vanuit de controlemechanismen.
Een opkomende aanvalstechniek, gericht op de interne communicatie van besturingssystemen, dwong CrowdStrike ertoe een nieuw “Template Type” te starten. Twee nieuwe Template Instances op basis van dit type verschenen op 19 juli, die beide gevalideerd werden. Eerder was dit nieuwe type Template al met succes uitgerold. Echter: door een bug in CrowdStrike’s Content Validator kwam één van de updates op 19 juli onterecht door deze digitale APK.
Het succesvolle debuut van de nieuwe Template Type, vertrouwen in de output van de Content Validator en eerdere geslaagde Instance-deployments leidden tot de uiteindelijke, fatale, deployment. CrowdStrike bevestigt de suggestie van velen dat de Windows-uitval kwam doordat de Falcon-sensor een geheugenadres opvroeg dat niet bestond. Het verwijzen naar een “null pointer” is een klassieke, veel voorkomende programmeerfout, bijvoorbeeld in de taal C++.
Voorkomen is beter dan genezen
Een subtiele fout met gigantische gevolgen, waardoor CrowdStrike het eigen beleid fors gaat wijzigen. Het testen van Rapid Response Content gaat op de schop en krijgt zes nieuwe checks, veelal aangerade middelen in de developer-gemeenschap zoals rollback testing, fuzzing en stabiliteitstests. De Content Validator-bug zou inmiddels verholpen zijn. Daarnaast moet de Content Interpreter, dat de informatie vanuit Channel Files leest, voortaan foutieve informatie beter opvangen. Lessen en proeven genoeg voor alle software-componenten die erger hadden kunnen voorkomen dus.
Ook zal Rapid Response Content voortaan geleidelijk uitrollen. “Canary deployment” geeft sommige gebruikers als eerste de nieuwste updates, die (zoals is gebleken) zelden maar niet nooit fouten kunnen bevatten. Gebruikers krijgen daarnaast meer controle over wanneer updates plaatsvinden. Het zal voortaan aan IT-teams zijn om te bepalen hoe gretig men van actuele bescherming gebruik wil maken. Vermoedelijk wordt dit een groot discussiepunt met hun managementteams, die de perikelen van vrijdag net als de rest van de wereld niet zijn ontgaan. Ten slotte maken release notes duidelijk waar CrowdStrike precies tegen verdedigt met de nieuwe updates.
Snelheid boven veiligheid
De uitgebreide checks aan de eerder genoemde Sensor Content zijn niet alleen logisch, maar ook gewoon verplicht. Microsoft staat het niemand toe om Windows-drivers op kernel-niveau zonder WHQL-check uit te brengen. Toch koos CrowdStrike ervoor om andere updates via Rapid Response Content sneller te pushen dan dergelijke checks toe zouden staan. Dat gaat doorgaans goed, mede omdat er al controlemechanismen waren die doorgaans naar behoren werken.
Totdat een enkele bug in de Content Validator roet in het eten gooide. Feitelijk is het de enige directe oorzaak die CrowdStrike noemt, een software-fout die iedereen had kunnen overkomen. Het bedrijf benadrukt dat andere tools, zoals de Content Interpreter, volwassen genoeg zouden zijn om een onzinnige input te herkennen. Ook die liet steken vallen. De implicatie is dat deze soort incorrecte input simpelweg niet gedekt was.
De waslijst aan nieuw ingevoerde controles laat zien dat Rapid Response Content simpelweg een te kleine checklist had. Het is lang goed gegaan met de oude werkwijze, die het bedrijf mogelijk ook een competitief voordeel heeft gegeven door sneller dan anderen updates uit te voeren. Dat zou een toevoeging zijn aan de claim dat Falcon zes tot elf keer sneller dreigingen opspoort dan oplossingen van concurrenten. Kritiek over CrowdStrike’s snelheid met updates waar gebruikers geen controle over hebben, ligt nu voor de hand. Nu is het eindelijk zo dat gebruikers zelf kunnen bepalen wanneer updates plaatsvinden, dus de snelheidsdrang vanuit CrowdStrike is niet meer leidend. Daarnaast is er meer informatie beschikbaar over welke dreigingen het bedrijf beter weert via deze updates. Die zaken hadden al zo moeten zijn, maar CrowdStrike lijkt dat ook inmiddels wel door te hebben.
Beluister ook onze Techzine Talks-aflevering over het CrowdStrike-debacle: