Luchtvaartmaatschappij Delta klaagt CrowdStrike aan wegens grootschalige storing

Delta Airlines heeft CrowdStrike aangeklaagd vanwege de grote storing in juli. De luchtvaartmaatschappij beweert dat CrowdStrike 'niet-geteste en gebrekkige updates forceerde' naar zijn klanten. Delta zegt hierdoor meer dan 500 miljoen dollar aan schade te hebben geleden.

"CrowdStrike veroorzaakte een wereldwijde ramp doordat het de kantjes er vanaf liep", beweert Delta in de aanklacht waar onder meer CNBC over schrijft. "Als het bedrijf de gebrekkige update ook maar op één computer zou hebben getest voordat het deze aan alle klanten zou verstrekken, zou die computer zijn gecrasht." De vliegtuigmaatschappij beweert dat het bedrijf de automatische updates van CrowdStrikes beveiligingssoftware had uitgeschakeld, maar dat de update in kwestie toch werd uitgevoerd.

Delta beweert dat de storing zijn activiteiten meerdere dagen lamlegde en dat het bedrijf zo'n zevenduizend vluchten moest annuleren. De vliegtuigmaatschappij eist meer dan 500 miljoen dollar aan verloren inkomsten en extra kosten als gevolg van de storing. Het Amerikaanse ministerie van Transport begon kort na de storing een onderzoek om erachter te komen waarom het Delta veel meer tijd kostte dan andere luchtvaartmaatschappijen om de activiteiten te hervatten.

CrowdStrike zegt in een reactie aan CNBC dat 'Delta's beweringen zijn gebaseerd op desinformatie' en dat ze 'een gebrek aan begrip aantonen van hoe moderne cybersecurity werkt'. Het bedrijf vindt dat het trage herstel komt doordat Delta zijn 'verouderde IT-infrastructuur' niet heeft gemoderniseerd en dat de schuld niet bij CrowdStrike ligt.

De storing in CrowdStrikes Falcon Sensor-software vond op 19 juli plaats. De storing leidde tot bsod's op miljoenen Windows-computers, waardoor hele systemen plat kwamen te liggen. Naast luchthavens had dit ook grote gevolgen voor onder meer ziekenhuizen en banken.

Reacties (133)

[supersnathan94]

CrowdStrike beweert in een reactie aan CNBC dat 'Delta's beweringen zijn gebaseerd op desinformatie' en dat ze 'een gebrek aan begrip aantonen van hoe moderne cybersecurity werkt'. Het bedrijf vindt dat het trage herstel komt doordat Delta zijn 'verouderde IT-infrastructuur' niet heeft gemoderniseerd en dat de schuld niet bij CrowdStrike ligt.

Eh wat? Kom nou ff. Die software crashte doordat men er van uit ging dat er een array/list nooit langer zou zijn dan 20. Dat is toch wel programmeren 101 dat je dat niet doet. En dan je klant betichten dat het niet weet hoe “moderne cybersecurity” werkt terwijl je zelf de meest basale best practices in de wind slaat?

Poeh die hebben wel lef.

[Blokker_1999]

Dat is wel een enorm vereenvoudigde uitleg die je daar geeft. De problematische template bevatte namelijk al sinds maart van dit jaar 21 elementen. De reden dat het nooit problemen heeft gegeven is omdat het laatste element altijd een wildcard was geweest. In een update op 19 julie werd voor het eerst een definitie gemaakt waarin dit 21ste element geen wildcard was, maar een definitie bevatte.

Ja, het is idioot dat de testing ook altijd gebeurd lijkt te zijn met een wildcard. Want aanpassingen aan de code worden blijkbaar een stuk beter getest dan aanpassingen aan definities. Maar dat laatste zou men volgens het eigen rapport dus ook aanpassen. Al zit je altijd met de afweging van hoe veel tijd kan je steken in testen wanneer je weet dat een zero-day actief misbruikt wordt.

[BugBoy]

De software van CrowdStrike werkt met definities die regelmatig worden geupdate. Dat is inderdaad heel gebruikelijk in de cybersecurity, maar het is ook gebruikelijk dat die definities wel intern op een aantal systemen worden geladen in de CI/CD pipeline voordat je ze vrijgeeft. Dat is duidelijk niet gebeurd. Als er edge-cases waren geweest waar dit probleem was opgetreden, dan was het een heel ander verhaal. Alle systemen met deze definities crashten, dus CrowdStrike is zeker aansprakelijk voor het ontstaan ven het probleem in mijn ogen.

[Cambionn]

dus CrowdStrike is zeker aansprakelijk voor het ontstaan ven het probleem in mijn ogen.

Hier is iedereen het ook wel over eens, ook CS. De discussie is nu wie er aansprakelijk is voor het feit dat Delta zo lang downtime had (iets wat verder niemand had zover bekend). Als het zoals CS zegt door Delta komt dat het langer duurde dan nodig, is het wel logisch dat CS zich dáár niet aansprakelijk voor laat stellen. Immers, is die schade dan door Delta zo vergroot, niet door hun.

[YopY]

Dat zal een heel lastige, interessante en waarschijnlijk enorm langdradige zaak worden. Is CrowdStrike, die een dagenlange outage veroorzaakt heeft, verantwoordelijk voor die dagenlange outage, of is Delta verantwoordelijk omdat ze hun zaken niet op orde hebben? Lijkt me erg moeilijk te voorspellen wat de uitkomst zal zijn, dwz, CS moet bewijzen dat Delta nalatig was, waarvoor Delta hun hele IT huishouding (van voor de outage) moet open stellen. Als dat al niet openbaar is, gezien audits, beursnotering, etc.

[Tim_bots]

Wie er nu "fout" is, is lastig te zeggen.

Van ongeveer 1 maand geleden de meest "neutrale" view.
YouTube: Pirate Software explains Crowdstrike Blog Post

[Krommetenen]

Was de update voor de zogenaamde “zero day” in je theorie dan niet via een snelkere methode bij re werken terwijl je ondertussen zonder Wildcard kan testen,

Men heeft een stap in hun proces overgeslagen was toch de consensus?
Tja dat Delta zichzelf knullig formuleert toont enkel hoe onhandig de juridische sector is.
Doet niet af van de hoofdclaim dat men in gebreke blijkt te zijn geweest.

[ChefA]

Die software crashte doordat men er van uit ging dat er een array/list nooit langer zou zijn dan 20.

Bron?

[Houtenklaas]

Google is your friend: https://www.crowdstrike.c...e-Analysis-08.06.2024.pdf


The new IPC Template Type defined 21 input parameter fields, but the integration code that
invoked the Content Interpreter with Channel File 291’s Template Instances supplied only 20
input values to match against. This parameter count mismatch evaded multiple layers of
build validation and testing, as it was not discovered during the sensor release testing
process, the Template Type (using a test Template Instance) stress testing or the first
several successful deployments of IPC Template Instances in the field. In part, this was due
to the use of wildcard matching criteria for the 21st input during testing and in the initial IPC
Template Instances.

[Alfa1970]

Hmm, dat lijkt op een set van tests die is ontwikkeld door dezelfde programmeurs die het product hebben ontwikkeld.
Je moet nooit dezelfde programmeur gebruiken voor je test suite als degene die het product maakt.
Die programmeur is "blind" voor dat soort problemen want die weet hoe het product zou moeten werken, en kan nooit alle situaties overzien die getest moeten worden, want dat bevat scenario's waar de software bestand moet zijn tegen situaties waar het product niet voor ontwikkeld is.
Een programmeur die niet diep bekend is met de algemene interne werking van het product heeft een veel grotere kans om tests te schrijven die juist dat soort problemen vindt.
Mijn collega's vervloeken me soms omdat ik problemen blootleg die soms al jaren in het product zitten.
Hoe doe je dat? Ik zeg altijd dat ik niet wordt gehinderd door de kennis.
Ik weet wel dat ik na een paar jaar wat minder effectief ben geworden, juist doordat ik kennis over het product opdeed.
Wij "misbruiken" mensen die nieuw binnenkomen nu steevast voor het ontdekken van problemen.
Zelfs als het geen bugs zijn en het product naar behoren functioneert, kunnen nieuwe mensen veel beter aangeven wat er aan het product schort dan mensen die er al jaren in zitten.
Ik ben me bewust dat niet ieder bedrijf die luxe positie heeft dat er een vrij constante stroom aan nieuwe mensen binnenkomt, en dat het software product feitelijk een neven activiteit is.

[BugBoy]

Je kan nog zo je best doen, maar je moet niet de illusie hebben dat je alles af kan denken met unit en integratietesten. Sommige bugs zijn zo specifiek en treden slechts op in specifieke scenarios. Dat zal nooit waterdicht zijn. Je moet leren van je fouten, maar foutloos is een utopie.

Het probleem bij CrowdStrike was echter geen complex issue, want je mag verwachten dat dit soort "configuratiedata" wel op een paar systemen wordt geladen in je CI/CD pipeline voordat het vrijgegeven wordt. Dat is blijkbaar niet gebeurd en dat was prima te voorkomen.

De waarheid zal hier wel in het midden liggen. De fout is primair ontstaan dat CrowdStrike zijn testproces niet op orde heeft en het lange offline zijn wellicht door EOL hardware/software. CrowdStrike is daarmee aansprakelijk voor de schade, maar wellicht slechts voor een deel van die schade, omdat Delta door EOL systemen de boel niet snel genoeg weer in de benen kreeg.

Dit is vooral voer voor de juridische teams. Technisch is het allemaal vrij duidelijk, dus het zal vooral door advocaten en juristen bepaald gaan worden. Gaat vast lang duren, want daar willen ze graag wel wat uurtjes kunnen schrijven...

[nandervv]

Ik snap andersom ook niet hoe Delta het voor elkaar gekregen heeft dat een software-leverancier zo vol-automatisch al hun computers neergooit. Dan heb je aan je eigen kant ook niet voldoende defensief ingericht.

Crowdstrike was hier zonder meer aan het prutsen op een niveau dat niet hoort bij het type klanten dat ze hadden, maar Delta had zelf ook meer moeten doen om vervolgschade te voorkomen naar mijn mening.

[BugBoy]

Alle cybersecurity software zal definities pushen om real-time security te implementeren. Dat kan nu eenmaal niet echt anders. De enige andere oplossing is air-gapped servers of het risico nemen dat je te laat bent met je definities doorvoeren en dat het kwaad al geschied is. Ik denk dat dit vrij normaal is in de bedrijfsvoering van (grote) ondernemingen.

Met de software van CrowdStrike draag je inderdaad een stukje verantwoordelijkheid van je servers over aan een derde partij. Dat is helemaal niet vreemd en dat gebeurd wel vaker. Sommige zaken moet je aan de experts overlaten. Het probleem hier was alleen dat die experts het behoorlijk verkloot hebben.

[batjes]

Maar de halve wereld draait op EOL systemen, Delta is hier absoluut geen uitzondering in.

Als dat wel een belangrijk punt van aandacht wordt, kan het een heel gevoelig precedent scheppen.

[FreezeXJ]

Ik ben in elk geval voor, dat dwingt af dat bedrijven zelf updaten in plaats van naar elkaar te wijzen en niks te doen.
Hoe het precies juridisch zit is mijn afdeling niet, maar ik zou zeggen dat CrowdStrike hier verantwoordelijk is voor de schade die ze bij een goed-georganiseerd bedrijf zouden veroorzaken. Als Delta op oude onbeheerbare zeut wil draaien en daardoor langer schade ondervindt, is dat eigen schuld.

Alternatief is dat een CrowdStrike (of een Microsoft, of whatever) eerst een audit moet doen of ze wel op je systeem durven draaien omdat ze grotere schadeclaims kunnen krijgen.

[DdeM]

Interessante anekdote maar onderzoek toont juist het tegenovergestelde aan. Juist software waarbij de developers zelf de tests schrijven is over het algemeen hogere kwaliteit dan software waar tests uitsluitend gedaan worden door andere teams.

Maar dit geld uiteraard niet voor alle soorten tests (bijv exploratory tests) en het vereist een manier van werken die de meerderheid van de bedrijven niet doen, ondanks al het bewijs dat het een betere manier van werken is.

[Frame164]

Het grote risico daarbij bljjft nog steeds dat er een zekere blindheid is voor iets waar je alle details van kent. Of dat je uit gaat van het hebben van rockstars als developer. Dat is ook niet goed. Een rockstar stapt makkelijk over want iedereen wil die mensen hebben en dan ben je kennis in ke organisatie kwijt.

[Reactie gewijzigd door Frame164 op 27 oktober 2024 18:07]

[DdeM]

Het grote risico daarbij bljjft nog steeds dat er een zekere blindheid is voor iets waar je alle details van kent.

Daarom is communicatie zo belangrijk, maar wat ik zie is dat nou juist is waar het bij veel bedrijven fout gaat. Of informatie krijg je pas aan het eind ("dit is niet wat we wilde") of je mag als developer uberhaupt niet met een klant/eindgebruiker praten (ticket silo).

En inderdaad, rockstars moet je niet willen hebben.

[Pep7777]

Tot op zekere hoogte heb je gelijk de code wordt inderdaad beter. Grootste probleem is dat je vaak nou net vergeet een test te schrijven voor de situatie waarin je ook in je code niet hebt gedacht. Dus het helpt nog altijd om met je team de test cases ook goed te bekijken, en een collega de "dankbare" taak te geven om te kijken of hij/zij jou code kan mollen

[DdeM]

Zal bij mij eerder omgekeerd zijn Doe zelf (A)TDD dus zal eerder gebeuren dat er een requirement mist en het niet zie. En in het verlengde daarvan probeer ik altijd testcases te bedenken samen met, of op basis van input van het team, iemand met een QA achtegrond en iemand die de business case van een feature die we gaan bouwen goed kent (danwel klant, danwel daadwerkelijk eindgebruiker).

En voor het proberen te mollen is mutation testing ook een hele goede, dat is gewoon een geautomatiseerd proces en in mijn ervaring pakt die veel meer dan een mens.

Dat allemaal betekend uiteraard niet dat je alle mogelijk fouten altijd pakt, maar daar heb je o.a. exploratory testing voor.

[Barsonax]

Ik merk juist dat door ik tests schrijf ik allerlei edge cases en nuances ontdek in wat ik geprogrammeerd heb. Het helpt je om uit de box te klimmen. Onderzoek toont ook aan dat practices als TDD gewoon de kwaliteit verhogen.

Neemt natuurlijk niet weg dat het ook helpt als anderen ernaar kijken die er niet zo in zitten. Dat kan op meerdere manieren zoals bijv PR's maar ook gewoon een aparte tester.

[xiam]

Heel goede strategie. Als ik voor gebruikers iets uitzet dan doe ik dat eerst op een kleine groep onwetenden. Kun je altijd van leren.

[DdeM]

Naja niet doet...

Je kan het wel doen, maar je moet het wel fatsoenlijk testen en rekening houden met de situatie als het wel gebeurd.

Maar persoonlijk vermoed ik dat dit met een schikking afloopt.

[MarcelBreugel]

Ik weet het niet. Het zijn juridische schermutselingen, maar geen enkel miljardenbedrijf kan accepteren dat een leverancier op deze knullige manier de bedrijfsvoering overhoop gooit en dan ook nog publiekelijk aangeeft dat het aan Delta zelf ligt dat de schade zo groot is.

[WillySis]

Delta heeft er langer over gedaan om de schade te herstellen dan andere getroffen instellingen. De rede daarvan wordt nog door het ministerie van Transport onderzocht. Waar andere bedrijven slechts enkele uren tot een dag nodig hadden om weer in de lucht te komen deed Delta er enkele dagen over. De schuld daarvoor op CS schuiven is wat kort door de bocht. De reactie van CS is daarom wel (deels) terecht.

CS aansprakelijk stellen voor de verkeerde update zal leiden tot een enorme massaclaim die CS nooit kan betalen en daarmee zinloos is.

[MooiNiet]

Zonder disrespect voor jou opmerkingen, vindt ik het jammer dat aan de ene kant gezegd wordt dat de reden voor het lange herstel nog onderzocht wordt en aan de andere kant wordt er wel een oordeel gegeven over de schuldvraag.

Dat is nou iets wat ik jammer vind, we weten kennelijk nog niet alle details, maar speculeren wel en dan nog zonder voorbehoud. Laten we het bij de feiten houden. Later zal hopelijk blijken wat de exacte reden was en wie er volgend de instanties "schuld" heeft.

[WillySis]

Voor de uiteindelijke oorzaak waarom het bij Delta zo lang duurde zullen we de onderzoeken moeten afwachten. CS heeft echter hulp aangeboden en die is door Delta geweigerd. Delta heeft CS dus ook niet de gelegenheid gegeven om de schade te beperken. De reactie van CS is daarom minimaal voor een deel terecht (dat schreef ik ook). In hoeverre CS en Delta zelf schuldig zijn aan de lange storing is nog in onderzoek en die uitslag zullen we moeten afwachten voor het (en ons) uiteindelijke oordeel.

[Mosterd]

Delta is misschien wel groter dan die andere firma’s en kan niet zo snel schakelen?

[Madshark]

Dit, en wellicht ook omdat Delta wat minder flexibel kan zijn vanwege de vele stenge regelgevingen en procedures die opgevolgd moeten worden als airliner.
Luchtvaart industrie is wat dat betreft wel een vrij unieke tak.

[DdeM]

Ze waren ook langzamer dan alle andere airliners....

[cadsite]

Zonder kennis van zake verder, maar er is altijd 1 iemand de traagste.

[WillySis]

Alle Amerikaanse airlines hebben met dezelfde regelgeving te maken en die konden wel binnen een dag weer operationeel zijn.

[xiam]

Goede reactie. Ik vind dat er hier bij tweakers netjes om gegaan wordt met elkaars commentaar. Was vroeger wel eens anders.

[xorpd]

Dan kun je de politieke topics maar beter mijden...

[freaq]

Ik denk eerder dat dit het eerste schaap over de dam is, en dat er wss nog vele gaan volgen…

Delta is niet de enige, en er zijn vele met flinke kosten,

Op de achtergrond zullen er heus wel schikkingen getroffen zijn (1 jaar gratis 2 jaar gratis service bijv etc)

Maar er zullen er heus wel meer zijn welke dat niet genoeg vinden, en die zullen zich mogelijk bijvoegen om ofwel een flink hogere schikking af te dwingen of idd echt er gewoon mee door te gaan.

[WillySis]

Ik denk niet dat er nog meer maatschappijen gaan volgen. Als dat zo is zal CS direct faillissement aan kunnen vragen, want CS zal nog geen % van de totale schade betalen. Een eventuele verzekering zal om dezelfde rede niet betalen. Vermoedelijk staat er ook wel iets in de kleine lettertjes over de verantwoordelijkheid bij dit soort problemen.
Delta probeert nu een gerechtelijke procedure omdat het oplossen van het probleem, maar omdat zij de "automatische update" uitgeschakeld zouden hebben en het bij hun dagen langer duurde voordat alle systemen weer in de lucht waren, niet vanwege het probleem zelf.

De gang van zake maakt vooral duidelijk dat automatische updates ook een gevaar herbergen. Updates wil je zo snel mogelijk over je hete netwerk uitrollen, maar het is verstandiger om die eerst kleinschalig binnen een klein deel van het netwerk uit te testen.

[MarcelBreugel]

Zoals ik het had begrepen, was 'de noodoplossing' in eerste instantie (4 dagen of zo) het uitschakelen van Crowdstrike door het verwijderen van een config bestandje of zoiets (opstarten in safe mode en bestand x wissen). Er hoeft dan nog maar één medewerker een fout linkje te klikken voor een catastrofe.

Dan ontstaat er wel een dilemma, kies je voor veiligheid of bedrijfsvoering? En er is de vraag 'hoe lang gaat dit duren, hoe lang staat de achterdeur wagenwijd open?'

Zo gezien begrijp ik dat verschillende bedrijven verschillende keuzes maken.

[WillySis]

Eén machine niet goed behandelen heeft nog geen gevolgen voor het hele netwerk, tenzij je dat doet op een machine die de instellingen naar het netwerk pusht. Normaal gesproken is dat maar een heel beperkt aantal computers.
Men hoefde ook niet alle computers af als men in plaats van het gewraakte bestandje te wissen er een leef bestand van maakte. Daarna hoefden alle andere computers alleen herstart te worden. Voordat je eerst alle computers hebt uitgeschakeld en na herstel weer hebt opgestart kan een grote organisatie best een aantal uur zoet zijn. Tel daarbij nog de uren op voordat deze "patch" bekend werd gemaakt.

[DdeM]

Ik verwacht vooral dat er een schikking komt door wat @WillySis ook aangeeft. Het is Delta die er langer over deed te herstellen dan andere, wat dus een teken is dat ook hun niet alles op orde hadden. CS is wat mij betreft zeker laakbaar voor de update ansich, maar ook Delta heeft hier zichzelf ook waarschijnlijk wel wat te verwijten.

[VisionMaster]

Maar waarom had Delta er zolang last van? Waarom meer dan anderen?

[BugBoy]

Grote organisatie met verouderde IT systemen. In een kleinere organisatie kan je veel sneller schakelen. In grote organisaties met meer hiërarchie durft/mag vrijwel niemand verantwoordelijkheid nemen. Ik ken het van Prorail, waar een server plat lag en daarmee een heel deel v/h treinverkeer. Niemand mocht de server resetten, dus een collega van mij is in de auto gestapt en na een uur heeft die de boel herstart. Daarna waren de problemen over. Heel triest, maar zo werkt het in dat soort organisaties. Is wel 15+ jaar geleden, maar zou me niet verbazen dat het nog steeds zo is.

[SuperDre]

Ja, de initieele schuld ligt bij Crowdstrike, voor het niet fatsoenlijk testen, maar het dagenlang er uit liggen, ligt wel degelijk aan de verouderde infrastructuur van Delta. Dus waarschijnlijk zal een rechter op het punt van ondegelijke software ze wel een behoorlijk bedrag toewijzen, maar het deel dat het zo lang down was zal men waarschijnlijk niet toewijzen.

[kodak]

Waarop baseer je dat het dagenlang er uit liggen ligt aan verouderde infrastructuur?

Daarbij, heeft crowdstrike minimale eisen aan de infrastructuur van klanten als Delta gesteld? Want anders valt infrastructuur altijd wel verouderd te noemen als een leverancier de eigen veroorzaakte problemen niet kan herstellen op een manier die ze zelf willen.

[Cambionn]

Waarop baseer je dat het dagenlang er uit liggen ligt aan verouderde infrastructuur?

Dit is de claim van CS? Gezien elke andere luchtvaarmaatschappij veel sneller de boel weer werkend had, zal er toch óók iets niet lekker zitten aan Delta's kant.

Daarbij, heeft crowdstrike minimale eisen aan de infrastructuur van klanten als Delta gesteld?

Ook zonder minimuumeisen (die er ongetwijfeld geweest zijn. Wat supported is/kan zijn is wellicht vaak veel breeder voor bedrijven maar niet oneindig) kun je objectief outdated zijn. Door software of hardware te draaien die door de leverancier, normen of zelfs de industriestandaard zo bestempeld wordt bijvoorbeeld, zeker als die expliciet aangeven dat je het niet zou moeten te gebruiken. Als je, bij wijze van, op systemen uit de jaren "80 draait kun je problemen verwachten die je met nieuwer spul niet zou hebben. Zeker als de rest in de industrie wel op nieuwer spul draaien, en het aantoonbaar dus niet nodig is. Dan is niet upgraden toch ook wel een bewust (of wellicht onbewust, maar dat maakt Delta’s case dan niet bepaald sterker) risico, tenzij CS expliciet zegt het wél te ondersteunen. De vraag is dan meer of Delta zo duidelijk verouderd was, of discuteerbaar is daarin. En nogmaals, dat is afgezien van dat er over het algemeen toch wel een vorm van eisen zijn.

Daarbij beweerde CS in een eerder nieuwsbericht ook dat Delta hulp van CS wijgerde om het probleem op te lossen. Tja, als dat zo is dan sta je wel zwakker als je vervolgens langer offline bent dan de rest en dat 100% wil verhalen op CS. Dan kan CS terugzeggen dat het minder lang had geduurd als de hulp wél aanvaard was, en ze geen kans hebben gekregen om schade te beperken.

Denk dat de zaak wel iets genuanceerder ligt dan dat CS alle verantwoordelijkheid draagt. Het zal idd op een gedeelde schuld uitkomen gok ik. CS veroorzaakt, dat staat vast. Maar door Delta duurde het mogelijk langer dan nodig (en was de schade dus groter dan nodig). Er vanuit gaande dat CS hun verhaal klopt natuurlijk. Ben ergens wel benieuwd wat hier uit komt.

[Reactie gewijzigd door Cambionn op 27 oktober 2024 20:58]

[kodak]

Zonder duidelijke grenzen wat verouderde automatisering is is het te simpel om te doen alsof dit het geval is. Dus dan mag wel hard bewijs gegeven worden, anders kan men net zo goed gaan suggereren dat een klant niets goeds in gebruik heeft zolang crowdstrike die automatisering niet uit komt. En dat is precies waarom ik vraag of crowdstrike minimale eisen stelde voor een klant hun producten kon gaan gebruiken.

Dat andere klanten sneller online waren is niet zomaar vergelijkbaar. Dat kan net zo goed komen omdat die klanten zich over hebben geleverd aan de eisen die crowdstrike is gaan stellen om te kunnen helpen. En aangezien het zeer ongeloofwaardig is als crowdstrike geen eisen zou hebben is dus de belangrijkste vraag welke grenzen crowdstrike stelde aan de automatisering van hun klanten. Zeker als valt te verwachten dat niet ieder bedrijf maar even de eisen aan de hulp gaat accepteren van een leverancier die duidelijk een enorme uitval veroorzaakt door zelf grote risico's te nemen met onacceptabele gevolgen voor duizenden klanten en miljoenen afhankelijke personen daarvan.

[Cambionn]

Zonder duidelijke grenzen wat verouderde automatisering is is het te simpel om te doen alsof dit het geval is
[...]
Dat andere klanten sneller online waren is niet zomaar vergelijkbaar. Dat kan net zo goed

Maar wie zegt dat zulke dingen niet duidelijk zijn? En er kan net zo goed heel veel. Maar mijn punt was niet dat CS per se gelijk heeft, maar dat er prima realistische scenarios in te denken zijn waar ze dat zijn. Nu zeggen dat CS 100% verantwoordelijk is, is nét zo voorbarig als zeggen dat dat niet zo is. Het benodigde bewijs om te weten hoe het zit zal pas in de daadwerkelijke rechtzaak naar voren komen. Dat geef je meestal niet in een press-release of reactie uit. En verder zeg ik dat ik verwacht dat de waarheid wat genuanceerder ligt, maar dat is mijn verwachting.

Zo denk ik dat als CS echt rare hele eisen stelde, dat meer bedrijven dan 1 dat zou weigeren en anders achteraf zouden aanklagen met de stelling dat CS misbruik maskte van de noodsituatie. Ook denk ik dat als dat wel zo blijkt en de rest uit nood akkoord ging, dat CS keihard een klap krijgt als dat uitkomt in een rechtzaak, en ze dan wel voorzichtiger zouden zijn met uitspraken gezien de klap die ze al hebben gehad door dit incident zelf.

Daarbij heeft een bedrijf als CS duizenden klanten, zo niet meer. Als maar 1 bedrijf deze problemen (de langere downtime dan de rest, want daar gaat het om. De schuld voor het initiele probleem wordt gewoon erkent door CS) heeft, is het niet gek je af te vragen of dat niet aan dat bedrijf ligt. Dat Delta als enige die problemen heeft, zegt dus iig íéts. Wat precies moet in de rechtzaak uitgewezen worden. Want dat kán theoretisch idd ook zijn dat ze de enige zijn die hun mond erover opentrekken. Maar persoonlijk lijkt mij dat dus sterk. En again, dat is dus mijn persoonlijke verwachting, geen feit.

anders kan men net zo goed gaan suggereren dat een klant niets goeds in gebruik heeft zolang crowdstrike die automatisering niet uit komt

Dit gaat natuurlijk 2 kanten op. Elk bedrijf van dit formaat behoord een degelijk ISMS te hebben, met daarin een fatsoenlijke risicoanalyse en BCP. Als Delta inderdaad op oud spul draait, zou dat bekend moeten zijn en zouden de mogelijke gevolgen daarvan ook bekend en gedocumenteerd moeten zijn. Als ze vervolgens langer offline zijn dan nodig puur daardoor kunnen ze dat niet 100% op CS verantwoorden. Immers, is het een ingecalculeerd risico. En als dat niet ingecalculeerd is, dan zijn processen mogelijk niet op orde bij Delta. Ook dat is niet CS hun fout. Dat moet je ook meenemen, anders kan ieder bedrijf namelijk ook gewoon niks upgraden en bijhouden en leveranciers overal voor laten opdraaien als het mis gaat. En dat is net zo problematisch als wanneer CS iedereen hun systemen de schuld zou kunnen geven. Beide moet niet kunnen. (wat CS overigens niet eens doet, ze erkennen de fout die het initieel veroorzaakte en claimen enkel dat de langere downtime specifiek door Delta komt waardoor ze niet aansprakelijk gesteld kunnen worden. En helaas zijn verouderde systemen veel voorkomend, zeker bij kritieke dingen en grote bedrijven/instanties want die zijn vaak duur en complex om te vervangen. En zolang het werkt... Het is dus niet ondenkbaar. En again, dat zegt niet dat het zo is. Enkel het zo kan zijn. En dat daarom nu meteen roepen dat het CS het zich er makkelijk vanaf maakt en de boel wil naaien, echt kort door de bocht is en niet per se waar).

Een setje minimumeisen is echt niet het eind van dat verhaal, en een gebrek daaraan of het bestaan daarvan onzegt een bedrijf niet van common sense en goede processen. Mijn eerdere voorbeeld van een "80 systeem kan je problemen mee verwachten, ongeacht minimumeisen. En een bedrijf van dit formaat behoord dat in kaart te hebben. Maar een systeem van bijv. 15 jaar oud is al een stuk minder duidelijk. Dan kom je dus op de afweging waar de grens zit. Die moet idd duidelijk zijn, maar zal de rechter mogelijk nog moeten beslissen. De eisen van CS zijn daar niet het einde van het verhaal, die zijn daar slechts een deel van.

In zo'n rechtzaak zal er dus gekeken moeten worden hoe die verhouding in verantwoordelijkheid ligt. Dat heeft best veel nuance. Wat waren de eisen van CS, maar ook hóé oud waren de systemen en hoe zagen die er precies uit, wat is de standaard, was de verwachte downtime met die systemen en was die realistisch, hoe zag Delta hun BCP eruit, waarom werd hulp geweigerd en hoeveel downtime had voorkomen kunnen worden als die niet geweigert was, waarom was de rest wél snel weer werkend en enkel Delta niet, en zo nog veel meer dingen. Dat maakt allemaal uit in de afweging.

De aansprakelijkheid nu puur bij CS leggen, zeker als het slechts bij 1 van de duizende (als niet meer) klanten zo mis ging, is gewoon te voorbarig. Wellicht blijkt het zo te zijn en krijgt Delta groot gelijk, maar dat kunnen we nu nog niet weten. Maar gebaseerd op wat we wel weten, verwacht ik persoonlijk een genuanceerdere zaak. Maar gezien ik het bewijs ook niet heb, weet ik dat net zo min zeker als jij en kan ik het natuurlijk ook fout hebben.

[Reactie gewijzigd door Cambionn op 27 oktober 2024 23:17]

[kodak]

Mijn vraag om bewijs komt door een gebrek aan onderbouwing door crowdstrike. Ik ben het er mee eens dat het om nuance gaat, maar simpel doen alsof er dus maar naar aantallen gekeken kan worden toont geen nuance. Juist omdat er heel veel verschillende oorzaken kunnen zijn dat het bij anderen sneller ging. En aangezien Crowdstrike nauwelijks onderbouwing geeft neem ik hun suggererende beweringen met een korrel zout. Zij zijn daarbij het bedrijf wat aantoonbaar fouten hebben gemaakt met enorme risico's voor anderen, waar ze mee weg lijken te willen komen alsof service bieden om je puinhopen te herstellen genoeg zou zijn. Ik verwacht meer van bedrijven die wel flink verdienen aan enorme hoge rechten verkrijgen maar het dan belangrijker vinden om met modder te gooien als die risico's bij anderen financiële schade veroorzaken. Er mag dan wel meer duidelijkheid blijken, wat ze kennelijk liever niet doen. Daar hebben de miljoenen afhankelijke personen niets aan.

Aangezien crowdstrike enorme belangen heeft dat een rechter voor nu en de toekomst geen hogere eisen heeft dan waar ze zelf risico's mee willen nemen verwacht ik dat ze uiteindelijk een overeenkomst sluiten met geheimhouding.

[Cambionn]

Ik zeg nergens dat er enkel naar aantallen gekeken moet worden, maar juist naar heel veel dingen. Dat aantal (slechts 1) is wel een mogelijke indicator van iets, maar ook niet meer dan dat. Er speelt, zoals gezegd, heel veel meer mee.

Verder vraag ik me sterk af dat er geen bewijs is. Dat ze niet preciese data over Delta's situatie publiekelijk vermelden zegt niet dat ze het niet hebben. Zoals gezegd wordt dat over het algemeen niet zo snel publiekelijk gepubliseerd, en ik kan me indenken dat ze dat ook helaal niet mogen want daar zal vertrouwlijke informatie in zitten. In een rechtzaak zal dit wel na voren komen.

De argumentatie van CS is niet onrealistisch. Of het waar is, is een tweede en dat zullen we moeten zien in de rechtzaak nadat daar bewijs is aangeleverd. Maar tot dat gebeurd is gewoon niet met zekerheid te zeggen of CS aansprakelijk is of dat Delta ook zelf deels schuld heeft (en daar aansprakelijk voor is). Niet door jou, niet door mij, niet door een andere random Tweaker. Ik hou discussie hier ook maar op, want alles is wel gezegd en ik val in herhaling.

[Mathijs Kok]

Heb jij kennis van de infrastructuur van Delta? Ik een klein beetje en kan die met de beste wil van de wereld niet echt outdated vinden. Waarom denk jij van wel?

[latka]

Tsja, als het zo lang duurt om het te herstellen dan lijkt dat toch niet heel erg resilient te noemen. Wellicht een perfect storm waardoor het zo lang duurde, maar als je een uitwijk centrum hebt zou dit niet moeten kunnen. Wellicht dat je dan op je uitwijk wel opnieuw op moet bouwen, maar als alles geautomatiseerd is dan zou dat vlot moeten kunnen. Het kan zijn dat de architectuur wel modern maar gewoon rommelig is, dan helpt dit uiteraard allemaal niet.

[SirMemeAlot]

Ze zeggen in je statement ook niet dat het probleem komt door de verouderde IT-infrastructuur, maar het doorvoeren van de oplossing langer duurde door verouderd infrastructuur.

Ik ben de laatste d ie hier kennis van heeft, maar dit is wel een belangrijke nuance.

[sjorsjuhmaniac]

helemaal mee eens.

Wat CS hier echter bedoelt is dat Delta waarschijnlijk dacht dat de 'don't update software' switch betekende dat er ook geen nieuwe definities van malware werden gedownload. Dat zijn echter 2 verschillende dingen en het continu updaten van de definitie database is hoe 'moderne cybersecurity' nu eenmaal werkt.
De comment van CS is buiten context geplaatst imho, journalistiek issue, maar levert meer clicks.

De 2e opmerking zal waarschijnlijk 100% waar zijn. CS weet precies hoe de infra van Delta eruit ziet en dat zal hoogst waarschijnlijk niet up to date zijn. Daardoor is het geclaimed bedrag buiten proporties omdat het significant minder gekost zou hebben als ze wel up-to-date infra hadden gehad, aldus CS.

[Reactie gewijzigd door sjorsjuhmaniac op 27 oktober 2024 13:56]

[Tijn89]

Valt mee, als ik me goed herinner was het delta die hulp van zowel crowdstrike als Microsoft weigerde.

[Powerblast]

Ik had begrepen dat het issue ontstaan was doordat een definitie file corrupt was geraakt bij het uploaden naar de CDN. De drivers checkte vervolgens niet of het bestand wel gelezen kon worden en crashte daarop.

Edit: nvm, blijkbaar wat gemist.

[Reactie gewijzigd door Powerblast op 27 oktober 2024 14:21]

[rko4u]

Dat riekt inderdaad een beetje naar de veronderstelling dat er maar 2 karakters nodig waren om een jaartal weer te geven.

[jpsch]

Vind het meer klinken als een buffer overrun. Dacht dat het inmiddels common practice was om daar maatregelen tegen te nemen.

[CH4OS]

Wat voor destijds trouwens ook geen hele gekke gedachte was, omdat geheugen destijds zoveel mogelijk op bespaart werd, er was nooit veel aanwezig, in tegenstelling tot heden ten dage. Dus de vergelijking die je nu maakt, is niet helemaal toepasbaar/eerlijk, omdat het destijds om andere redenen weggelaten is in vergelijking met hier.

[Reactie gewijzigd door CH4OS op 27 oktober 2024 19:10]

[- peter -]

Delta had zelf geen hulp geaccepteerd van Microsoft en Crowdstrike, en alle andere bedrijven hadden na een downtime van dagen(?) alles weer draaiend. Delta zelf niet, en dat lag niet puur aan Crowdstrike, maar aan hun algehele staat van IT. Dus nee, dit is gewoon de blame shiften. (Uiteraard snap ik wel dat je Crowdstrike wil laten betalen voor het probleem zelf)

[jozuf]

Ben ik het niet zonder meer mee eens.
Je beperkt de array grootte vanwege performance overwegingen, en laat het groeien als het nodig is (lees kopieert de array naar een die groter is).
Ipv managed talen die dit vaak voor je doen (afhankelijk wat/hoe je dit doet, maar dat kost je dus performance afhankelijk waar je voor kiest).
Dat dit een knullige fout is ben ik het mee eens, maar dit kan wel een heel bewuste keus zijn vanuit de programmeur(s).

[Reactie gewijzigd door jozuf op 27 oktober 2024 14:50]

[BugBoy]

Dan heeft die programmeur nog een fout gemaakt, want je moet ook je input-files valideren. Als die meer dan 20 posities heeft, dan moet je gewoon een (niet systeemfatale) fout geven en het bestand niet laden. Ook al zou je geen fixed array hebben, dan zou je het nog moeten maximaliseren, want je wilt ook je systeem niet onderuit halen met een bestand dat bedoeld is om je systeem te laten crashen.

Dit is allemaal waarschijnlijk kernel-level software, maar ook daar kunnen dit soort checks ook prima gedaan worden. Dit is gewoon een fout en die gebeuren en dat voorkom je niet. Wat CrowdStrike heeft nagelaten is fatsoenlijk de definities te testen op testsystemen in hun CI/CD pipeline alvorens ze vrij te geven. Dat vind ik wel verwijtbaar. Het is een zeer grote club die hoge prijzen vraagt en dan mag je wel verwachten dat ze hun zaakjes een beetje op orde hebben.

[aikebah]

Nee, dit is gewoon een knullige fout (broddelwerk bij het testen)
Bij de uitbreiding van de template-API van 'tot 20 parameters' naar 'tot 21 parameters' had ook de code die niet bleek aangepast uitgebreid moeten worden om tot 21 parameters te verwachten.
Bij diezelfde template-API change (die dus al ruim voor het wereldwijde crowdstrike incident was doorgevoerd) had er ook minstens 1 template in de test moeten staan die daadwerkelijk inhoudelijk een 21e parameter ging gebruiken. Dan was toentertijd de test al gefaalt en de code gepatcht om ook bij het verwerken van template parameters rekening te houden met genoeg ruimte om 21 parameteriseringen te ontvangen.
Testing 101 is dat je in ieder geval de bounderies gaat testen, omdat daar het vaakst een onbewuste fout in de code gemaakt wordt.

[jozuf]

Ja eens, maar dit is gewoon mensen werk en dus een menselijke fout.
Zo'n out of bounds exceptie is iets waar in menig software, menige bugfixes voor zijn door de jaren heen.
Natuurlijk kaart het niet opvallen van de fout aan dat er iets mis is met de QA van de software /het bedrijf, maar de fout ansich word gewoon heel veel gemaakt en in dat opzicht niet opmerkelijk.

De comment Waar ik op reageerde deed vermoeden dat het enorm stom is en dat het programmeren van dit type fout echt beginners werk is. Dat is het dus niet. Ja, je had het moeten vinden via tests voordat je het uitlevert. Maar nee, deze fout wordt aan de lopende band gemaakt zelfs door erg ervaren ontwikkelaars.

[Reactie gewijzigd door jozuf op 27 oktober 2024 16:08]

[aikebah]

Voor een 'gewoon' IT-bedrijf ben ik het met je eens. Voor een bedrijf opererend in het werkgebied (rapid-reponse beveiligingssoftware) en met de modus (full-blown 100% roll-out wereldwijd zonder zelfs maar knoppen voor IT beheerders om het in te richten als een staging roll-out) van CrowdStrike is het een onacceptabele fout.
In zo'n geval moet je procedureel geborgd hebben dat er voor 100% minstens op de boundaries getest wordt. (alternatief is een staged roll-out aanbieden, zodat je met minder schade wegkomt als er wat doorheen glipt bij het testen)

[BugBoy]

Helemaal eens met jouw reactie. We hebben het hier niet oven een eenmans OSS stukje software. Dit is een bedrijf die verwacht dat je de veiligheid in hun handen legt (voor een serieuze vergoeding). Dan zo klooien is schandalig. Als ze hun definitiebestanden gewoon op één systeem hadden geladen in hun testproces, dan was het probleem al niet ontstaan.

CrowdStrike heeft waarschijnlijk alle benodigde certificeringen, maar hun basale testproces was niet op orde. Daarom roep ik ook altijd "compliance is werk voor managers, security is werk voor ontwikkelaars/testers"...

[m_snel]

Dit soort fouten worden juist vaak uitgebuit door hackers. Door berichten te sturen die niet voldoen aan het gewenste formaat.
Je zou van een beveiligsbedrijf verwachten dat ze eerst een check doen of het bestand wel aan de voorwaarden voldoet, voor je het gaat gebruiken.
Verder kun je zo iets natuurlijk ook gewoon afvangen met een fout routine, waarbij je dan het oude configuratie bestand blijft gebruiken.

[BugBoy]

Ik ga er wel vanuit dat CrowdStrike enkel correcte ondertekende definities zal laden. Maar als CrowdStrike zelf een malafide definitie ondertekend, dan wordt die natuurlijk gewoon geladen. Zomaar malafide definities voeren zal denk ik niet kunnen. Als het wel kan, dan is het echt bagger...

[m_snel]

U begrijpt niet precies wat ik bedoel, je kan een certificaat gebruiken maar dat zegt niks over de fout afhandeling van het bestand.
Daar gaat het vaak mis in programma’s en dus ook deze keer.

[BugBoy]

Ah, had ik je bericht verkeerd gelezen. Ik dacht dat je met die "check" juist bedoelde om de handtekening te valideren. Maar ik ben het met je eens. Signing doe je om de oorsprong te valideren (net als een HTTPS certificaat). Dat wil echter enkel zeggen dat de maker bekend is. Niet dat het veilig is om te gebruiken... Daarvoor heb je andere controles nodig en je verwacht bij een partij als CrowdStrike dat die dat zouden doen. Maar dat bleek dus niet (voldoende) het geval te zijn.

[Reactie gewijzigd door BugBoy op 27 oktober 2024 20:00]

[xorpd]

Ik schrijf zelf kernel level software en de 2 principes die ik absoluut noodzakelijk acht zijn:

1. Input validatie, inclusief null pointer en bounds checking, voor ELKE kernel level call.
2. Failing with grace, bij een fout moet de impact op het systeem geminimaliseerd worden.

Crowdstrike heeft overduidelijk beide punten niet op orde.

[BugBoy]

Daarom denk ik ook wel dat Rust een aardige zou zijn voor kernel drivers, maar ik ben me bewust dat dit nogal gevoelig ligt bij de Linux kernel community Ben het helemaal met je eens, maar CrowdStrike had zowel het coderen niet op orde als hun release-proces. Je wilt op allerlei plekken je QA op orde hebben. Net als bij Boeing zie je dat management hier blijkbaar geen oog voor heeft. Focus ligt op sales en marge...

[supersnathan94]

Nouja. Best practise is natuurlijk om er altijd vanuit te gaan dat een lijst oneindig kan zijn of zelfs leeg. Ik verwacht eigenlijk nooit meer een enkele waarde tenzij het echt specifiek nooit meer dan 1 kan zijn, maar heel specifiek maximaal exact 20 is gewoon niet handig.

Er komt namelijk altijd wel een keer dat het er ineens meer dan 20 zijn zoals hier dus is gebeurd. En dan leg je in een half uur letterlijk de halve wereld plat.

En ja met gevoelige software als dit doe je daar ook nog input validation overheen, maar dat kan prima per item in de lijst. En niet de hele lijst in 1 keer dus dan ligt de constraint nog steeds op oneindig.

[roelst1]

Tja, bij Crowdstrike zijn ogenlijk kleine foutjes gemaakt met enorme gevolgen, maar hun opmerkingen richting Delta zijn mogelijk wel terecht. Als Delta door verouderde hardware de fout niet snel kon herstellen, ligt specifiek die fout natuurlijk niet bij Crowdstrike.

[groene henk]

Als je je applicatie gewoon update via een een DevOps pipeline methode (niet een patch installeren, maar gewoon altijd opnieuw), dan heb je dit probleem niet.
Oftewel cursusje Terraform/Ansible nodig bij Delta. Als je alles nog op de oude manier doet (ClickOps) en dat vervolgens ook nog niet automatiseert, dan moet je echt een heleboel backups terugzetten.
Ook sommige mensen denken dat DevOps een geintje is en knippen hun waterfall projectje op in stukken van 2 weken en noemen het dan agile.
Zo te horen hoort Delta zeker bij deze laatste groep. Waarschijnlijk goedkoop ge-outsourced, want we willen de laagste prijs.

[William_H]

CrowdStrike beweert in een reactie aan CNBC dat 'Delta's beweringen zijn gebaseerd op desinformatie' en dat ze 'een gebrek aan begrip aantonen van hoe moderne cybersecurity werkt'. Het bedrijf vindt dat het trage herstel komt doordat Delta zijn 'verouderde IT-infrastructuur' niet heeft gemoderniseerd en dat de schuld niet bij CrowdStrike ligt.

Dat mag CrowdStrike vinden, maar dat gaat over het herstel. Er was geen herstel nodig geweest als CrowdStrike gewoon z'n werk had gedaan. Dit argument gaat Delta altijd winnen ten opzichte van CrowdStrike in een rechtzaak. Het is CrowdStrike die de storing veroorzaakte, en niet Delta.

Overigens, voor de mensen die denken dat dergelijke bedrijven failliet gaan door claims, daar ga ik niet vanuit. De meeste bedrijven hebben daar verzekeringen voor.

[Anoniem: 454358]

En die (aansprakelijkheid )verzekeringen gaan uitkeren als je aantoonbaar fouten hebt gemaakt? Die zijn , zeker in de vs, niet zo van het uitkeren.

[Brupje]

Daar is de verzekering juist voor, als een fout wordt gemaakt. Expres is niet verzekerd, per ongeliluk wel. In ieder geval zolang het binnen de kleine lettertjes valt

[wooha]

Het is daarentegen Delta die een moeilijk herstelbare infrastructuur lijkt te hebben opgezet, vergeleken met andere slachtoffers van dit probleem en best-practices. Dat deel is CrowdStrike niet direct te verwijten en ik kan me niet voorstellen dat ze die volledige schade moeten vergoeden.

Delta gooit het zo te zien op nalatigheid en als ik het goed begrepen heb is er nog een juridisch concept van criminele nalatigheid nodig, voordat een hogere schadevergoeding aan de orde komt dan contractueel is vastgelegd.

Ondanks alle moeilijk, moeilijk verhalen in de CrowdStrike uitleg, kan ik me het toewijzen van nalatigheid heel goed voorstellen.

Toevoeging: wat mij betreft is beide partijen dus nalatigheid te verwijten.

[Reactie gewijzigd door wooha op 27 oktober 2024 15:51]

[BugBoy]

Zo zal Delta het ook brengen natuurlijk, maar helemaal fair is het natuurlijk niet. Als 90% van de bedrijven de zaakjes wel goed voor elkaar hebben en de systemen weer snel operationeel had, dan is het echt wel verwijtbaar dat Delta dat niet heeft.

Bedrijven kunnen zich verzekeren tegen dit soort zaken. Maar als er verwijtbaar is gehandeld, dan zal ook de verzekering niet uitkeren en wordt het een lastig verhaal. Op zich een goede zaak, want anders worden bedrijven veel te slordig. Dat zie je ook bij Boeing, waar geld en management het voor het zeggen hebben en de echte specialisten buiten spel staan. Dat gaat een tijdje goed, maar op een gegeven moment is het onhoudbaar.

[groene henk]

Grote bedrijven zoals Delta dienen een contingency plan hebben. Ze moeten erop voorbereid zijn dat alles kapot kan gaan. In dat plan zaten zeker wat gaten in.
Dit doet me denken aan het log4j probleem 3 jaar geleden. Onze software gebruikte dat ook. Donderdag begint het probleem en vrijdag werd ik door een goede bank (ABN) gebeld om het op te lossen. Vervolgens kwam er 3 weken later een ander groot bedrijf wat de IT allemaal ge-offshored heeft, ons dreigen via een email dat we het log4j-probleem terstond moesten oplossen (wat allang was gebeurd). Op de vragen waarom het nu terstond moet worden opgelost terwijl het al 3 weken een wereld wijd probleem was, kreeg ik natuurlijk geen antwoord.
Contingency is heel erg belangrijk en zelf wettelijk verplicht bij grote bedrijven. Dat wil niet zeggen dat elk groot bedrijf dit goed geregeld heeft.
En ik durf wel te stellen dat het bij Delta niet goed was geregeld.
Kun je dan meteen van alles gaan eisen? Ik vind van niet.

[Reactie gewijzigd door groene henk op 28 oktober 2024 01:01]

[William_H]

Ben het geheel met je eens.
Maar dit speelt in de VS af, angelsaksisch recht en claimcultuur, waar ook anders tegen dit soort claims wordt gekeken. Daar klagen ze je moeder nog aan dat je ooit geboren bent.
Dus ik denk dat dit nog wel eens een interessante casus kan worden.
Het is aan CrowdStrike nu om te bewijzen dat het een zooitje was bij Delta. Daar wens ik ze veel succes mee...

[Blokker_1999]

Tegen dit soort claims ga je jezelf niet snel verzekeren lijkt mij. Dat wordt een onbetaalbare premie.

[William_H]

Algehele bedrijfsaansprakelijkheid?

[CAPSLOCK2000]

Als Delta een gewone consument was dan zou ik de zaak kansloos achten omdat CrowdStrike ongetewijfeld in de voorwaarden heeft staan dat het gebruik van de software op eigen risico is en dat CS nooit aansprakelijk gesteld kan worden voor de gevolgen. Net als iedere andere softwareleverancier.
Maar Delta is groot een bedrijf dus misschien hebben die een contract op maat, maar ik verwacht er weinig van.

Ik vind het interessanter om me af te vragen of Delta of CS iets had kunnen doen om dit te voorkomen, anders "beter testen & geen fouten maken". Het was zo rampzalig omdat al die computers tegelijk uitvielen op precies dezelfde manier. Als de helft van de computers geen CS had gedraaid maar iets anders dan was het probleem niet zo groot geweest. We hebben het wel vaker over de problemen van monocultuur. Als er iets met Windows mis was gegaan was het probleem minstens zo groot geweest.
Maar vanuit het oogpunt van de beheerder is het handiger als al die systemen wel hetzelfde zijn en er overal exact dezelfde software draait.

In de ruimtevaart hebben ze dat probleem ook. Ruimtevaartuigen hebben vaak een hoop onderdelen dubbel of zelfs driedubbel aan boord om storingen op te vangen, maar daar heb je niks aan als alle onderdelen op hetzelfde moment stuk gaan.

De oplossing is dat ze meerdere fabrikanten inschakelen de ze allemaal hetzelfde onderdeel laten ontwikkelen en fabriceren. Ze moeten allemaal aan dezelfde eisen voldoen maar ze hebben hun eigen manier om daar te komen. Dat voorkomt de kans dat alle onderdelen dezelfde structurele fout hebben.
(En als een bedrijf failliet gaat kunnen de andere leveranciers het dichten).
Dat is wel een hoop meer werk bij het ontwikkelen en het kost een hoop geld, maar je krijgt er wel veel zekerheid voor terug.

In de IT heb ik dat principe maar één keer gezien. Dat ging om een organisatie die een LInux-server had én een BSD-server die samen in een actief/passief cluster zaten (een router/firewall-achtig systeem). Als er kritieke fouten gevonden zou worden in het ene OS dan konden ze altijd over stappen op de andere servers. Ik geloof dat het plan was om ook de beheerdersaccounts te splitsen zodat niemand per ongeluk beide servers tegelijk uit kon zetten.

Dat is een hoop gedoe maar als de belangen maar groot genoeg zijn dan is dat de enige manier om dit soort structurele problemen op te lossen. (Niet alle systemen tegelijk patchen zou ook helpen maar dat heeft z'n eigen nadelen).

[DaniëlWW2]

CrowdStrike had zeker iets kunnen doen.
Ze hadden geen deployment rings voor deze updates en lieten hun klanten ook niet doe om dit (simpel) te configureren met de beheersoftware van CrowdStrike. In plaats hiervan werden deze updates gewoon deployed wanneer ze beschikbaar kwamen. Dit is kernel level software waar inmiddels iedereen weet dat als er iets misgaat, je een BSOD krijgt. Dat is een zelfbeschermingsmechanisme in operating systems om meer schade te voorkomen.

Zomaar updates massaal deployen zonder delay, naar software die op kernel level draait, is abject amateurisme. Dit is de absolute basis van ICT beheer. Je deployt nooit zomaar updates naar systemen. Je test, evalueert en deployed in fasen en kijkt of er iets gebeurd. Ideaal gezien heb je ook een fallback scenario voor als iets misgaat.

Je bent als klant zo volledig afhankelijk van CrowdStrike die geen fouten maakt. Tja...
Achteraf werd duidelijk dat CrowdStrike dit in de voorgaande maanden ook al hadden gedaan met Linux systemen. Daar was de impact alleen een stuk beperkter. Er is, vermoed ik, ook een reden waarom zoveel multinationals, CrowdStrike bleken te gebruiken. Ze werden breed aangeraden door consultancies die de materie dus ook niet bleken te begrijpen. Want dit soort EDR/XDR software is echt een mes met twee kanten. Het is eerder noodzakelijk kwaad dan wenselijk. Het is ingrijpend op systemen. Gedeeltelijk qua performance, zeker als je implementatie niet goed is, maar ook gedeeltelijk qua privacy.


Maar Delta lijkt ook wat blaam te treffen.
Want nadat er miljoenen systemen crashte, werd al snel duidelijk welke bedrijven hun ICT op orde hebben en welke niet. De hersteloperatie voor CrowdStrike zal uiteindelijk veelal handwerk zijn geworden vanuit ICT afdelingen die hun weekend vaarwel konden zeggen. Als het langer duurde, dan kan je eigenlijk al de conclusie trekken dat ze geen adequate reactie hadden en/of simpelweg niet het personeel om adequaat te reageren. Ook is het uiteindelijk de verantwoordelijkheid van de afnemende partij om te valideren of ze een dergelijk systeem willen implementeren binnen hun beheerde ICT omgeving. De ICT'ers die hiermee werken, zullen echt wel gezien hebben dat er geen of beperkte controle over updating was. Dat is of niet gecommuniceerd richting management en hoger, of genegeerd door management of hoger.

[Blokker_1999]

Om heel eerlijk te zijn, ik zou op mijn antimalware software ook geen deploument ring wensen. Wanneer er 0-days rondgaan wil ik dat mijn systemen zo snel mogelijk beschermd zijn.

Want stel je even voor dat ineens in je bedrijf alle PCs beginnen crashen. Hoe snel ga jij doorhebben wat de oorzaak is van dat probleem? Dat kan uren duren. Dus ga jij het aandurven om definitie updates van je XDR oplossing met 1 of meerdere dagen uit te stellen? Want wat mij betreft haal je dan net 1 van je belangrijkste verdedigingslinies onderuit.

Voor nieuwe software versies, absoluut. Test het, probeer het. Maar definities die je systeem veilig moeten houden kan je niet over dezelfde kam scheren.

[HKLM_]

Toch is dat ook vanuit Microsoft met hun Defender XDR best practice. Waarbij onderscheid gemaakt
Is tussen, security (3 uur delay) platform (2 days) en engine (2 days) updates voor productie omgevingen.

https://learn.microsoft.c...t-intune-microsoft-update

[DaniëlWW2]

Ik heb het dan ook niet over dagen uitstellen. Eerder een paar uur en gefaseerd laten uitrollen.
De afweging is namelijk een mogelijke zero day kwetsbaarheid die net in die paar uur vertraging geëxploiteerd zou worden vs. het risico dat je systemen omvallen. Zeker met zero day loop je achter de feiten aan. Het kan een kwetsbaarheid zijn die een beveiligingsonderzoeker heeft gevonden in software. Maar het kan ook iets zijn dat al actief misbruikt werd. Dan loop je al tegen de feiten aan. Aardige kans dat als iemand dat wil misbruiken tegen je omgeving, het al gebeurd is. Die paar uur maken dan ook weinig meer uit.

Voor bescherming tegen kwetsbaarheden geld in de regel ook dat je meerdere lagen aan beveiliging probeert te creëren. Ik zou juist niet (alleen) vertrouwen op een antivirusscanner die in de regel de meer complexe bedreigingen, toch niet zal detecteren. Een systeem zoals CrowdStrike aanbied, is dan ook meer dan een antivirusscanner. Het is ook ML/AI gebaseerde process analyse, dat is het EDR/XDR gedeelte en dat is juist bedoeld om complexere bedreigingen te detecteren of zaken die een antivirusscanner heeft gemist. En dan heb je ook nog dingen zoals latteral movement detectie, scanning op verouderde en mogelijk kwetsbare software die je al op je systemen hebt staan of mogelijke aanvalsroutes of kwetsbare OS configuraties.

Het is niet een muur, het is een verdedigingslinie. Dat is ook hard nodig want een beetje goede ransomware ga je helaas niet stoppen met een antivirusscanner. Laat staan hackers die bewust op zoek zijn naar informatie. Nadat de antivirusscanner gepasseerd is, kan een EDR/XDR via process analyse alsnog gedetecteerd worden dat er iets aan de hand is. En een goede EDR/XDR laat je vervolgens ook achterhalen wat mogelijk besmet is. De overtreffende trap hierin is SIEM + SOAR. Dat is alleen een stuk complexer, dekt vaak nog veel meer af, vraagt vaak meer handwerk en vooral ook veel duurder.

En als je toch sneller wil deployen, dan kan je altijd een paar testsystemen configureren die je agressief laat updaten, bijvoorbeeld door die preview updates te laten installeren. Gaan die opeens down, dan weet je dat er iets aan de hand is.

[BugBoy]

CrowdStrike heeft blijkbaar de eigen gemaakte definities op geen enkel systeem getest. Dat vertraagd de deployment van je definities hooguit enkele minuten en had prima gekund met andere testen die parallel draaien. Dat hoeft niet eens echt tijd te kosten. Als consument wil je geen staged deployment van dit sooft definities. CrowdStrike had zijn (basale) testing gewoon op orde moeten hebben.

Ik heb sterk de indruk (speculatie) dat hun software updates wel getest werden, maar dat definities vrijwel ongetest gereleased werden. Dat laatste had ook meer testing nodig gehad. Dit is gewoon weer een wijze les, waarbij ik hoop dat (andere) bedrijven ervan leren...

[groene henk]

Met al mijn software zou ik elke dag een update willen (Ubuntu doet dat wel leuk). Helaas doen vele bedrijven (bv. Windows) dat niet. Dan is het 1 keer per week, dus je krijgt dan gemiddeld 3 dagen later een update.
Dus kudoos voor Crowdstrike en hun systeem. Echter hadden ze beter moeten testen.
Denk niet dat het nog een keer gaat gebeuren.

[MarcelBreugel]

Volgens mij was de hotfix als volgt:
Boot Windows into Safe Mode or the Windows Recovery Environment
Navigate to the C:\Windows\System32\drivers\CrowdStrike directory
Locate the file matching “C-00000291*.sys” and delete it.
Boot the host normally.
Draait dan weer de oude CrowdStrike of is die software helemaal uitgeschakeld? Is alles dan nog veilig?
De C-00000291*.sys update was wel ergens voor nodig, daarom werd die ook uitgerold. Zonder Crowdstrike en zonder die sys-file zijn al je systemen kwetsbaar.

Als je gedwongen zonder adequate beveiling moet werken, dan zit je in een lastig dilemma.
Vooral omdat je niet kunt voorzien wanneer en hoe het opgelost gaat worden door de leverancier.

Elk bedrijf maakt zijn eigen afwegingen en Delta met de kennis van dat moment wellicht de minder slechte keuze.

[StefanDingenout]

Je kan zoveel in je voorwaarden zetten, dat interesseert een rechter heel erg weinig. In Europa dan toch.

[Reactie gewijzigd door StefanDingenout op 27 oktober 2024 15:16]

[BugBoy]

Bij zakelijke contracten is dat net even anders dan bij consumenten contracten. Als je zakelijk alle verantwoordelijkheid uitsluit, dan heb je niet echt een poot op te staan. Maar wellicht had je dan de software niet moeten gaan gebruiken.

[Dreamvoid]

Tsja, daar kon je op wachten natuurlijk. Crowdstrike heeft nog een taaie paar jaar voor de boeg.

[raro007]

Nou ik denk als alle bedrijven hun gaan aanklagen dan kunnen ze alfast falisement aanvragen.

[HerrPino]

Als Delta dit wint gaat CrowdStrike omvallen. Dan gaan andere bedrijven immers hetzelfde doen.

[memphis]

Maar willen ze dat het omvalt gezien ze ook allemaal een beetje afhankelijk zijn van hun software?

[Alfa1970]

Dat is het mooie in software land.
Je bent nooit afhankelijk van maar één partij.
Zeker niet voor zo'n omhooggevallen "antivirus" leverancier.
(Op abstract niveau werkt hun product niet anders dan een antivirus product uit de jaren 90, je hebt een database met signatures, en een engine die gegevens onderschept, tegen het database aanhoudt en aan de hand van een ingestelde policy een beslissing neemt, ja of nee doorlaten).

[[Bc]-=VorteX=-]

Heb je een moderne edr of xdr uberhaupt al eens goed beleken?
Dit soort software doet een heel stuk meer dan data met een signature database vergelijken.
Denk aan de continue procesanalyse met context, het loggen van alle procesacries voor threathunting, machine learning om nieuwe varianten van malware ook te stoppen, remote response functionaliteit als extra basisfuncties.
Daarnaast bieden enkele van dit soort platformen (zoals bijvoorbeeld Crowdstrike), middels dezelfde agent ook functies als device control, data leakage prevention, host-based firewall management, vulnerability management, etc.
Nou boden de antivirus vendors destijds ook steeds meer, maar juist dat basisprincipe (pattern matching met signatures t.o.v. proces- en gedragmonitoring) is behoorlijk verschillend en de reden dat de edr producten zo’n vlucht hebben genomen.

[Alfa1970]

Ik weet exact hoe het werkt, voor sommige producten kan ik je tot op dll niveau vertellen wat die dll exact doet.

De marketing afdeling van dit soort bedrijven doet je van alles geloven, maar als je het abstract bekijkt zijn al die geavanceerde technieken gebaseerd op patronen die herkend moeten worden en aangepakt moeten worden.

Machine-learning -> is niets anders dan patroon herkenning, die patronen moeten vergeleken worden met iets dat in de volksmond een database genoemd wordt. Dat je hier zelf geen policy in kan stellen omdat de producent dit voor je regelt doet niets af aan de feiten.

Data-leak prevention -> een database met patronen van onderdelen van documenten die herkend moeten worden. (HIPPA, credit card nummers, het zijn letterlijk een set van "regex patronen" die in een database staan)
Met die patronen maak je een policy die zaken wel/niet toestaat.

Host-based firewall -> Een dergelijke firewall bevat een database met patronen voor meerdere types bekende netwerk aanvallen. (syn flood bijvoorbeeld).
Met de policy kun je in meer of mindere mate iets blokkeren of toelaten. Dat is naast de "domme" packet filter policies waarbij je een netwerk poort al dan niet blokkeerd.

Vulnerability management -> een database met patronen van bekende kwetsbaarheden.
Je stelt een policy op met wat je wilt herkennen en blokkeren/toestaan.

Device control -> standaard policies waarin je kan kiezen of je een apparaat al dan niet toepast.
Geen patronen database hier anders dan misschien apparaat herkenning, maar goed dat is over het algemeen statisch.

A/v leveranciers innoveren, en dat is heel goed, in principe zijn er geen "slechte" a/v producten meer.
Maar hoeveel ze ook toevoegen, uiteindelijk is het allemaal gebaseerd op hetzelfde principe, het herkennen van patronen en de gebruiker in meer of mindere mate de mogelijkheid geven om iets te doen met die al dan niet herkende patronen door middel van een policy.

[comecme]

Machine-learning -> is niets anders dan patroon herkenning, die patronen moeten vergeleken worden met iets dat in de volksmond een database genoemd wordt

Als je het zo stelt dan is een tool dan ChatGPT ook niet meer dan patroonherkenning met een database.

[Reactie gewijzigd door comecme op 28 oktober 2024 17:14]

[MarcelBreugel]

Omvallen is het doel niet, wel schadevergoeding. Sowieso zou ik denken dat geen enkel bedrijf op deze manier 'een beetje afhankelijk' wil zijn van een leverancier die een killswitch op de bedrijfsvoering in handen heeft.
De kritieke kwetsbaarheid is aangetoond, wat doe je dan?

[Dreamvoid]

Ik denk dat de meeste Crowdstrike gebruikers inmiddels wel bezig zijn met wegmigreren.

[De Vliegmieren]

Denk van niet. Er was eerder een schatting van 10% gebaseerd op interviews met willekeurige CISOs van bestaande CrowdStrike klanten.

Nu zal het natuurlijke verloop ook wel iets van 5-8% zijn, dus als die 10% schatting klopt dan is de impact miniem.

CrowdStrike heeft een grote naam en er is een soort van cultus rondom het bedrijf in de security sector, met vele bewonderaars bij wie ze (bijna) niets verkeerd kunnen doen.

Nu denk ik dat hun imago wel degelijk is aangetast, maar zonder rechtzaken en schikkingen zullen ze absoluut niet omvallen.

[Reactie gewijzigd door De Vliegmieren op 27 oktober 2024 16:19]

[De Vliegmieren]

Als de aanklagende partij sterk staat, doet de verdigende partij meestal een schikkingsvoorstel met voorwaarde dat ze geen schuld bekennen en met een NDA zodat er zo min mogelijk kan worden gebruikt door anderen die ook een rechtzaak overwegen.

[raro007]

Maar als 1 bedrijf schikking kan eisen zullen ze dat met anderen ook moeten doen.

[De Vliegmieren]

Ze moeten helemaal niets - dat is het hele idee van schikken: het zo veel mogelijk voorkomen van precedent werking.

Als anderen juridisch even sterk staan, dan kan dat inderdaad ook leiden tot rechtszaken en schikkingen. De aangeklaagde zal er echter alles aan doen om de bedragen zo laag mogelijk te houden, en een geschatte kostenpost opnemen in de begroting (inzichtelijk bij beursgenoteerde bedrijven).

[Jazco2nd]

Delta is de enige airline die wekenlang problemen ondervond. Bij hun concurrenten was het ergste binnen een dag voorbij en na 3 dagen helemaal opgelost..

Delta kan dus zeker niet Crowdstrike volledig de schuld geven. Crowdstrike heeft zelfs via meerdere wegen extra hulp, gratis, aangeboden die Delta afsloeg.

En de CEO van Delta scheen ook nog eens lekker op vakantie te zijn gebleven of gegaan..

Deze rechtszaak kan nog weleens een nachtmerrie worden voor het merk Delta Airlines.

[rjberg]

Ik vindt het persoonlijk onhandig dat antivirus kennelijk in de kernel moet. Ik snap de redenen, virussen kunnen met kernel toegang zelf ervoor zorgen dat antivirus ze niet ziet. Als je echter zoveel toegang tot het systeem moet hebben om virussen te vinden kun je denk ik beter een soort vm hebben waar alles in draait, en de host van die vm checkt dan om de zoveel tijd het gastsysteem.

Daarnaast kun je waarschijnlijk met dual booten ook scans uitvoeren. Dan hoeft het besturingssysteem niet geladen te worden. Met een hotswappable drive zou je ook zulke scans kunnen doen zonder onderbreking.

[HKLM_]

Dat AV’s in de kernel mogen aanmodderen wilde Microsoft eigenlijk ook helemaal niet maar de European Commission moest zich er in 2009 weer eens mee bemoeien en Microsoft is verplicht dit open te stellen voor andere vendors…

[aikebah]

Omdat microsofts endpoint protection oplossing dat deed moest microsoft het openstellen voor een level playing field (en terecht). Het alternatief zou zijn dat Microsoft zijn eigen endpoint protection software dezelfde limieten oplegt (niks in de kernel) als de externe producten van de concurrentie.

[rjberg]

Ik moest dit even googlen:

https://www.silicon.co.uk...-biggest-it-outage-572752

Ik snap wel waar de EU vandaan kwam. In bepaalde gevallen zou dat nuttig kunnen zijn, maar niet voor een vliegveld.

In principe zouden er sowieso betere manieren moeten zijn. Ik snap dat een persoonlijke virusscanner zoals Norton of Defender op een privé pc dit kan gebruiken, want dan staat er minder op het spel, en wegen de lasten van virtualisatie en RAID en dergelijke niet op tegen de verbeterde bescherming. Maar een vliegveld zou denk ik nog steeds iets gebaseerd op virtualisatie moeten hebben.

Toegegeven, als CrowdStrike hun werk goed deed zou het niet echt uit moeten maken. En ik snap dat een virusscanner installeren waarschijnlijk makkelijker is dan wat ik voor ogen heb vanuit het oogpunt van een klant. Uiteindelijk is alle software die van een ander is een kwestie van vertrouwen, en je kunt niet alles zelf maken.

Overigens vindt ik het jammer dat dit soort systemen antivirussoftware nodig hebben. Antivirussoftware is eigenlijk voor als het al te laat is. Elke code die op zo'n systeem draait zou van te voren gescand en getest moeten zijn, en beide taken vereisen geen antivirus met kernel toegang. Alleen als een virus echt wordt geïnstalleerd is er een probleem waarbij kernel toegang eventueel nodig is, maar in dat geval ben je misschien al de sjaak, want die antivirus is ook niet perfect.

[Reactie gewijzigd door rjberg op 27 oktober 2024 16:15]

[Houtenklaas]

Nee, het ging om "gelijke monniken, gelijke kappen". Als Microsoft daar zelf was uitgebleven, wat dat nooit een verplichting geworden. Kipsimpel verhaal.

[BugBoy]

Stel dat je vanaf een parallel systeem je disken zou scannen, dan zou je veel te laat zijn. Het bestand staat dan al op disk en wellicht ook al een tijdje. Je wilt voorkomen dat zo'n bestand in het geheugen wordt geladen en dat kan alleen op kernel-niveau.

Daarbij geeft het allerlei andere onpraktische neveneffecten vanwege extra load op die disken en bij encryptie wordt het nog veel lastiger. Kernel-mode anti-virus software is echt de beste optie, maar je moet wel zorgen dat je weet wat je doet. En ook al maak je fouten (dat gebeurd gewoon), dan moet je zorgen dat ze gevonden kunnen worden door een test-proces. Dat was hier de cruciale fout. Een basale test om een definitie-file te laden ontbrak blijkbaar.

[rjberg]

Kernel mode scanners zijn volgens mij alleen nodig als er al infectie heeft plaats gevonden. Als een virus nog niet geladen is zou een gewone antivirus het ook moeten zien met realtime scannen, mits de definities up to date zijn. En volgens mij zou voor realtime scans niet per sé kernel toegang nodig moeten zijn.

Als definities worden bijgewerkt zou een extra keer scannen of misschien real time scannen vanuit de kernel sneller kunnen zijn, of in ieder geval goedkoper. Maar dan moet men nog steeds wachten op de definities, en dat duurt ook eigenlijk te lang.

[BugBoy]

Je kan vanuit user-mode niet het laden van een malafide executable voorkomen. Daarom heb je kernel-mode drivers nodig. Dat is ook geen probleem, want er zijn veel meer kernel-mode drivers. Het moet alleen wel stabiel zijn en dat was hier nu net even het probleem. Het laden van externe content in de driver maakt het ook niet makkelijker.

[Geckow]

Duurde nog vrij lang dit. Hamvraag zal vooral zijn of dit vooral verwijtbaar was. Alles is te voorkomen maar niet elke test is commercieel haalbaar. Maar dat er geen simpele end-to-end test was voor updates was echt belachelijk.

[Reactie gewijzigd door Geckow op 27 oktober 2024 13:56]

[Merik]

Er is meer gaande bij dit conflict, dit was de reactie van Microsoft (die later mogelijk ook aangeklaagd wordt door Delta): https://arstechnica.com/t...-after-crowdstrike-snafu/

Microsoft says it has a pretty good idea of why Delta refused its help. "In fact, it is rapidly becoming apparent that Delta likely refused Microsoft's help because the IT system it was most having trouble restoring—its crew-tracking and scheduling system—was being serviced by other technology providers, such as IBM, because it runs on those providers' systems, and not Microsoft Windows or Azure," the letter said.

[Ryunoru]

Dit argument geldt natuurlijk ook voor Delta. Die hadden de update ook gerust eerst kunnen testen op een geisoleerd netwerk alvorens het toe te staan op hun live servers.

[wooha]

Het was geen normale software update, maar bestaande software kon niet overweg met een nieuw detectiebestand. Die bestanden werden automatisch real-time verwerkt nadat CrowdStrike ze beschikbaar stelt. Er bestond wel al een vinkje om een versie achter te lopen op normale software updates. Inmiddels bestaat er ook een instelling voor klantsystemen om de detectiebestanden niet direct te activeren.

[LOTG]

Als ik het zo lees is dat dus iets wat niet goed mogelijk was, door dat crowdstrike dit gewoon pushed ipv dat je jou systeem dat laat installatie wanneer jij dat wilt.

Daarom viel er zo veel bij zo veel bedrijven om, crowdstrike had hier de touwtjes in handen.

[ArcticWolf]

Ja en nee, blijkbaar werd de update dermate hard gepushed dat testen niet eens mogelijk was. Ik heb begrepen van ons IT bedrijf dat wij als overheid instantie de mazzel hebben gehad dat er destijds iemand heel erg op heeft lopen letten en dat de update bij toeval en mazzel niet is uitgerold op al onze laptops.

[WhiteDog]

Iedereen die ooit één serieuze implementatie van CrowdStrike heeft gedaan weet wat voor een rommelbedrijf het is. Met wat VIP-tickets voor het Formule 1 valt het natuurlijk wel goed te verkopen aan CEO's... 😇

[Aalard99]

Ik heb dit nooit gedaan maar ik ben wel erg benieuwd naar een verdere uitleg van je verhaal. Welke ervaringen heb je dat je deze uitspraak doet? Wat maakt CrowdStrike anders dan andere bedrijven in de cybersecurity?

[wiseger]

Crowdstrike dwingt patching naar alle servers tergerlijkertijd af. Dat doen andere niet. Daar kan je week A alle produktie patchen en in week B alle DR.

Het is ook helemaal niet erg om DR servers later van antivirus defenities ed te voorzien. Ze staan standby, niet live.

[Aalard99]

Ja eens. Het lastige in cybersecurity is dat je ook snel wilt kunnen reageren op actieve bedreigingen. Een systeem pas patchen (eigenlijk is dit niet echt een patch maar een update op een database) na een week tegen een acute bedreiging is ook niet wat echt wenselijk is.

Maar eens, binnen een enterprise omgeving wil je wel enige controle kunnen uitvoeren op wanneer patches worden doorgevoerd, zeker als ze een impact kunnen geven van wat we nu hebben meegemaakt met Crowdstrike. Je kan je dan afvragen welk risico groter is, deze patch één of twee dagen later doorvoeren of gelijk doorvoeren. Uiteindelijk had het ook de andere kant op kunnen gaan en dat veel bedrijven door ransomware getroffen waren omdat de patch te traag was uitgerold.

Is dit niet anders dan de meeste beveiligingspakketten werken? Hoe anders is bijvoorbeeld Microsoft Defender voor endpoint?

[Fermion]

Alles is afhankelijk wat er in het contract staat. Ergens in het koop overeenkomst/contract zal ook wel iets staan van eigen verantwoordelijkheid en testen van updates etc. Althans, daar ga ik van uit. Want bij de meeste producten die direct invloed heeft op je productie draai je niet altijd op te latest and the greatest. Maar ik weet het, je wilt je beschermen tegen zero day attacks of anders zo goed mogelijk. Ik zal dit met veel interesse volgen.