Topman CrowdStrike gaat getuigen voor Huis van Afgevaardigden in september

CrowdStrike-topman Adam Meyers gaat getuigen over de wereldwijde storing op 19 juli voor een subcommissie van het Amerikaanse Huis van Afgevaardigden. Het verhoor moet plaatsvinden op 24 september.

Meyers is de senior vice president van Crowdstrikes counter adversary operations-afdeling, die zich onder meer bezighoudt met het ondersteunen en adviseren van cybersecurityteams. Hoewel ceo George Kurtz ook is opgeroepen om te getuigen voor de subcommissie, staat hij niet op de lijst van getuigen, schrijft The Verge. Commissielid Andrew Garbarino hoopt dat de hoorzitting 'een belangrijke gelegenheid is om meer te weten te komen over de stappen die CrowdStrike heeft genomen na de storing om ervoor te zorgen dat dit niet opnieuw gebeurt'.

Op 19 juli werden honderden bedrijven en organisaties wereldwijd getroffen door verbindingsproblemen die werden veroorzaakt door een storing in CrowdStrikes beveiligingssoftware. De storing leidde tot bsod's op Windows-computers, waardoor hele systemen plat kwamen te liggen. Dit had grote gevolgen voor onder andere luchthavens, banken en ziekenhuizen.

Reacties (79)

[A_Trouwborst]

@Harm_H Het product an sich is niet slecht.

Er is helaas een fout gemaakt. Dat kan helaas zelfs zo'n bedrijf overkomen. Je zou kunnen zeggen dat dat niet mag, maar ja dit is precies wat een fout inhoud. Dat kan overal gebeuren.

Jij vertrouwt toch ook verschillende bedrijven die je producten of diensten leveren?

[Reactie gewijzigd door A_Trouwborst op 30 augustus 2024 21:26]

[naaitsab]

Het is niet zo zeer een fout maar een opeenstapeling van fouten en amateuristische QC procedures. Ik begrijp daarom niet zo goed waarom mensen dit blijven downplayen als een 'foutje moet kunnen'. Een foutje op zich moet zeker kunnen want het blijft mensenwerk maar hier is zo veel meer misgegaan dan 'een foutje'. Zowel in de goedkeuring van een ontwerp van de driver die door een definitie update een bootloop kan creëren, de update zelf en de release procedure. Waarbij ze kennelijk blind vertrouwen op een geautomatiseerd testsysteem. Als letterlijk elke Windows machine die de update ontvangt crashed is de gebruikte QC procedure simpelweg niet te verdedigen. Het was niet een samenloop van een hele zeldzame set aan variabelen om de crash te triggeren.

[Reactie gewijzigd door naaitsab op 30 augustus 2024 22:24]

[Blokker_1999]

Ik snap dan weer niet dat er mensen zijn die van mening zijn dat kwaliteitscontrole zo maar elke fout moet kunnen opvangen die er bestaat en dat met goede QA teams er nooit een bug in je software zal zitten. Zo werkt het niet. Je testen zijn maar zo goed als dat je QA team ze kan verzinnen.

Hier is maanden van tevoren een aanpassing gemaakt waardat een bug in zit. De code verwachte 20 parameters te krijgen, maar er was een optie ontstaan voor parameter 21. Die 21ste parameter is in die eerste maanden evenwel altijd een wildcard geweest en werd dus genegeerd. QA heeft er blijkbaar niet aan gedacht om die parameter eens te veranderen naar iets anders dan een wildcard, waarom dat is kunnen wij niet weten.

Er wordt een nieuwe definitie gemaakt met een 21ste parameter. Deze gaat ook zeer snel door de testing, maar het inladen van die parameterfile op zich is niet wat de crash veroorzaakt, dat gebeurt pas van zodra er een IPC call is op het systeem. In een systeem dat door een gebruiker actief gebruikt wordt zullen die calls zeer regelmatig voorkomen, nu is de vraag hoe goed de testsystemen die de nieuwe definities testen daarvoor opgezet zijn.

Dus ja, er spelen daar wel wat variabelen mee, en je moet ze allemaal opvangen.

Jij spreekt van blind vertrouwen op een geautomatiseerd testsysteem. Hoe wil je anders gaan testen de dag van vandaag? Wijzigingen aan het gedrag van software moet gecommuniceerd worden naar je QA team die dan kunnen nagaan hoe ze hun testprocedures kunnen en moeten aanpassen.

Achteraf is het altijd zo eenvoudig om te zeggen dat ze totaal verkeerd zijn, dat dit nooit had mogen gebeuren, om van aan de zijlijn te staan en te zeggen dat je het zelf beter had gedaan. En ja, de fout is moeilijk te verdedigen, maar ze is gebeurd, en daar moet iedereen lessen uit trekken, niet alleen Crowdstrike.

Maar mensen die zeggen dat fouten nooit mogen gebeuren wil ik zo graag uitlachen bij elke fout die ze zelf maken. Want we blijven mensen, en mensen maken fouten. En tenzij fouten opzettelijk gemaakt worden moeten we niet zomaar zoeken naar een schuldige om ons zelf toch maar superieur te voelen door die schuldige af te branden.

[naaitsab]

Ik snap dan weer niet dat er mensen zijn die van mening zijn dat kwaliteitscontrole zo maar elke fout moet kunnen opvangen die er bestaat en dat met goede QA teams er nooit een bug in je software zal zitten. Zo werkt het niet. Je testen zijn maar zo goed als dat je QA team ze kan verzinnen.

Er was hier niet zo veel te verzinnen. Wat ik bedoel met de parameters die hier niet van toepassing waren. Een feit welke je in je uiteenzetting niet benoemt. Het issue was bij elke Windows machine met deze driver. Het was niet een set aan obscure vereiste zoals een oude Windows versie in het Deens, in combinatie met Photoshop CS2, een gebruikersnaam die 4 letters heeft en begint met een P voor de boel crashed. Dat soort dingen valt inderdaad nauwelijks voor te testen. Kijk naar Microsoft en hun patch issues. Zij hebben te maken met miljarden variabelen. Dat ben ik 100% met je eens, roepen op Microsoft is ook altijd erg simpel. Die vlieger gaat in dit verhaal niet op.

Als je QA process een fout die bij elke machine zonder speciale handelingen optreed, doorlaat dan gaat er iets gruwelijk mis in je process. Ze hebben zelf toegegeven dat er een fout zit in hun geautomatiseerde test systeem. Daar is dus wel degelijk bind op vertrouwt, anders was deze update nooit gepust. Buiten mogelijk kwade opzet. Gezien elke actie om maar iets te testen gelijk tot het probleem had geleid, was er in feite geen QA van enige betekenis actief voor deze patch. Als een bedrijf die met kernel level drivers geen degelijke testen uitvoert. Welke daarna door een ander systeem/actie 'kruislings' worden gechecked. Dan is het toch wel droevig gesteld.

Zowel het process om de update te controleren op basale out-of-bounds bugs voor deze naar QA gaat is fout. Dat kan, daar is de QA ook (gedeeltelijk) voor. Het QA process om deze te checken is fout(gevoelig) en er is daarna geen goed functionerend "4-ogen" principe voor iets gepushed wordt. We hebben het hier niet over een zolderkamer softwareboer maar een miljarden bedrijf. Ook daar gebeuren fouten maar dit is een opeenstapeling van grove fouten toegestaan door falende processen. Daar kan je lange epistels over opstellen, dat valt gewoon niet te verdedigen voor een bedrijf die spullen als dit maakt. Ze gaan hier echt een gigantische dobber aan hebben bij de aankomende series van rechtszaken. Daar komen ze echt niet weg met een 'foutje moet kunnen'. Mijn inziens ook volledig terecht als je naar de gevolgen van de opeenstapeling/samenloop van falen kijkt.

[MarcelBreugel]

Als het primaire product van je bedrijf bij een fout kan gaan veroorzaken dat miljoenen werkstations en servers crashen, dan dien je daar alle noodzakelijke voorzorgen voor te implementeren.
Voor Microsoft ook een opdracht om hun 'kernel plugin' leveranciers te dwingen om wijzigingen 'even' te testen voor wereldwijde uitrol.
Als ik in mijn integratiesystemen een update maak, dan verifieer ik vanalles als de kerngebruikers hun testjes doen in de ACC omgeving, met name de correcte syntax van berichten.
Het toevoegen van een 21e parameter in CrowdStrike ging in stappen:
1 eerst de werkelijke executable (sys bestand) uitbreiden om met zowel 20 als 21 parameters te kunnen werken (eigenlijk een workaround)
2 daarna die 21e parameter toevoegen in de sideloaded definitie bestanden
3 later de 20 parameters workaround weghalen uit de executable
Het is niet zo moeilijk, dus mijn grote vraag blijft waar het precies fout ging. Ik kan me best voorstellen dat iemand een versienummertje verkeerd heeft ingevoerd. Was allemaal ook wel te ontdekken met wat simpele testjes.

[Orgel]

Het probleem is juist dat het niet meer simpel is. Het is heel makkelijk om van de zijlijn te gaan schreeuwen dat dit niet had mogen gebeuren maar kijk dan eerst is naar jezelf of jij nooit fouten hebt gemaakt. Iedereen maakt fouten vroeg of laat. Zelfs bij vliegtuigen en apneu apparaten waar direct levens in gevaar kunnen zijn worden fouten gemaakt. Dat het betreffende bedrijf op het matje wordt geroepen is natuurlijk logisch.

[SPee]

En daarom heb je Quality Controle. Hoe belangrijker het product, hoe groter de controle.

Vliegtuigen en apneu apparaten hebben een grote mate van controle op hoe het wordt gemaakt en wat er gebruikt kan/mag worden. Bij vliegtuigen wordt bij wijze van bijgehouden wie een schroefje heeft ingeschroefd en wie dat heeft gecontroleerd.
Het gaat pas mis wanneer die QC niet goed of niet voldoende wordt uitgevoerd.
Zo miste Crowdstrike dat bij "normaal gebruik" hun update zorgde voor een systeemcrash. En zo heeft Boeing problemen omdat ze een QC slecht hebben uitgevoerd. Beide situaties hadden voorkomen kunnen worden als ze wél een goede QC hadden gehad.
Dan kun je echter alsnog in situaties terechtkomen waar je in specifieke situaties een probleem kan hebben. Daar leer je echter van en neem je mee in je QC, zodat het in de toekomst niet meer voorkomt.

[2TheMaks]

Er was hier niet zo veel te verzinnen.

Tja, de 'benefit of hindsight':
Achteraf gezien is het verbijsterend dat dit nooit getest is, maar vooraf was er geen mens die dit ooit voorzien heeft.

Verder was er in dit geval geen sprake van een software-update. Het was de eerste maal dat er een definitie-file gedistribueerd werd die afhankelijk is van een feature die al in de software zou moeten zitten (21 parameters). Op het moment van testen bestonden er geen definitie-files met 21 parameters (hooguit een wildcard als 21e parameter), waarmee de software-update met vlag en wimpel door het QA-proces kwam.

Samenloop van omstandigheden dus: test-input (definitie-file met 21 daadwerkelijke parameters) was niet beschikbaar op het moment dat de software-update getest werd.

[aikebah]

Als functioneel test team van zo'n update zorg je dat je linksom of rechtsom in ieder geval een definitie krijgt met 0 en met 21 ingevulde parameters en liefst nog iets er tussenin, waarbij je ook een scenario hebt om die definities te raken.

[kodak]

Ik snap dan weer niet dat er mensen zijn die van mening zijn dat kwaliteitscontrole zo maar elke fout moet kunnen opvangen

Stellen dat fouten maken echt niet zomaar een excuus is wil niet zeggen dat fouten niet gemaakt mogen worden. De discussie is immers dat het niet zomaar redelijk is fouten te maken.

Dat bij een product of dienst niet alle problemen vooraf kunnen worden voorkomen is duidelijk. Maar we zien keer op keer dat een bedrijf niet zomaar te verwachten problemen voorkomt.

Zo zullen waarschijnlijk belangrijke vragen kunnen zijn waarom het bedrijf het een acceptabel risico vond om massaal uit te rollen in plaats van gefaseerd, of ze de klanten daarvan op de hoogte hebben gebracht, waarom ze dat nu pas lijken te willen wijzigen terwijl ze een enorme verantwoordelijkheid hebben naar duizenden belangrijke klanten en miljoenen mensen.

Hoe meer een bedrijf invloed over anderen neemt om daar flink aan te verdienen, hoe minder excuus er is om risico te nemen wat vooral gevolgen voor miljoenen anderen heeft. En tot nu toe neemt het bedrijf daar niet duidelijk verantwoordelijkheid voor. Ze beweren het vooral te nemen, als het mis is gegaan. Er is veel meer transparantie nodig dan de uitleg die ze tot nu toe geven en het excuus van anderen alsof fouten nu eenmaal niet zomaar te voorkomen zijn.

[Reactie gewijzigd door kodak op 31 augustus 2024 13:10]

[m_snel]

Ik werd ooit aangesproken op mijn houding dat iemand die weinig ervaring had een complex systeem dat verschillende servers en cliënt componenten bevatte in een dag voor de acceptatie in elkaar moest zetten.

Ik gaf aan dat het een onmogelijke zaak was en gaf hem zelfs nog mijn privé nummer.

Mijn manager die geen enkel verstand van zaken had , had mij al vanaf het begin genegeerd. En buiten mijn controle de QA afdeling ingeschakeld.

Toen hij mij de schuld in de schoenen wilde schuiven, heb ik gewoon zijn hele disfunctioneren uit de kast getrokken.

En blijkbaar waren er al veel meer klachten.

Nu waren enkele mensen bij QA eerder collega’s van mij en wel capabel, daar voor zaten ze rolstoelen te ontwerpen voor Doom.

[THM0]

Nou dit. Als je een kernel level driver maakt omdat je daar nou eenmaal moet zitten voor de functie van de software, dan weet elke OS engineer dat je heel zorgvuldig moet werken en hetzelfde voor testen.
Bug in je software? Grote kans op blue-screen, omdat het OS niets anders kan als je code in een ongeldige toestand komt.

Dat je dan zo'n update door het release proces krijgt die in 100% van de gevallen een crash veroorzaakt, dat kán toch niet?

'Compiles on my machine? Ship it!'.

[D0phoofd]

Ja dat was het probleem. Maar ook weer niet. De kerneldriver was namelijk niet veranderd.

Voor een ring-0 driver gaat werken moet die door MS gekeurd en gesigneerd zijn. Maar dat duurde Crowdstrike te lang. Limitatie zorgt voor creativeit. Dus heeft CS een manier gevonden om de werking van hun driver aan te kunnen passen door bepaalde bestanden vanuit userspace te sturen. Zo is heel de Quality Control-stap bij MS overgeslagen en kunnen ze inderdaad sneller shippen (waar ook iets voor te zeggen valt).

MS heeft CS de vinger gegeven en zie het gevolg. Flink gezichtverlies aan weerszijde. Waar juist de QC van Microsoft het had kunnen voorkomen.

Los van dat er blijkbaar een noodzaak is om dergelijke drivers zo in te laden - zou juist in mijn optiek - microsoft moeten voorzien in deze vraag (van ring-0 drivers). eBPF is daar waarschijlijk het antwoord op.

[Aganim]

MS heeft CS de vinger gegeven en zie het gevolg.

Welke vinger? Het probleem is dat MS nooit snel genoeg iedere nieuwe versie zou kunnen goedkeuren. Als er een nieuwe zero day exploit uitkomt moet het bijgewerkte definitiebestand direct de deur uit, dat kan niet wachten tot MS de hele driver door het QC proces heeft gehaald, zeker niet als er wellicht meerdere updates op een dag zijn. Voordat QC is afgerond zou die betreffende versie alweer achterhaald zijn en kan je opnieuw beginnen. Een paar uur vertraging is in dit geval al teveel.

[Reactie gewijzigd door Aganim op 1 september 2024 12:26]

[ByteArray]

Dit is niet de eerste fout die ze gemaakt hebben.

- 19 april 2024, Debian Linux, vergelijkbaar probleem
- 12 mei 2024, Rocky Linux, systeem kon bevriezen
- 4 juni 2024, Red Hat Linux, kernel panics

[Guru Evi]

In de Linux versie kun je echter wel de user space (eBPF) gebruiken ipv een kernel module alsook updates vertragen of niet installeren, heel anders dan de Windows versie. Ik denk dat zowel eBPF alsook niet updaten de 'default' is.

De kernel module installeren etc vind ik maar vies vooral omdat de kernels sneller updaten dan de gemiddelde antivirus zodat je altijd achterloopt als je een DKMS module nodig hebt, ze lopen soms maanden achter zelfs met een nieuwe Ubuntu LTS die vrijgegeven wordt tegen dat Ubuntu 'klaar' is beginnen ze zelf maar met ontwikkeling.

[Reactie gewijzigd door Guru Evi op 30 augustus 2024 22:30]

[_JGC_]

eBPF is een framework waarmee je ook heel veel ellende kan aanrichten. Een van eerder genoemde crashes was juist met Crowdstrike in eBPF mode.
En nee, ik ben ook geen fan van die rare kernelmodules die ze gebruiken, het is altijd kiezen tussen Crowdstrike in RFM of een lekke kernel blijven draaien tot de volgende Crowdstrike update.

[De Vliegmieren]

tsja als het een 'foutje' was dan was dat nog één ding. Echter lijkt het er meer op dat er binnen dat bedrijf wen cultuur heerste van 'dat overkomt ons toch nooit' en vervolgens totaal geen acht slaan op standaard praktijk regels over risico.

Wat er allemaal fout ging zodat die ene dag vele miljarden door het putje ging bij hun klanten:

• geen functionerende interne validatie van payload updates
• geen gefaseerde uitrol van payloads, gewoon alles naar alle klanten tegelijk uitrollen
• geen automatische monitoring van de agent om te kijken of update goed verlopen is. Anders had het niet 1 jur en 18 minuten geduurd en waren er geen 5-10 miljoen endpoints offline gegaan voordat ze de update stopgezet hadden
• klanten niet de mogelijkheid geven zelf te bepalen wanneer ze payload updates installeren/uitrollen
• parser code in de Windows kernel draaien. Waar een simpele bug in een userspace programma tot een programmacrash leidt, gaat hier de hele computer offline met een BSOD
• niets leren van een eerder vergelijkbaar probleem bij uitrol naar hun agent op Debian systemen

waarschijnlijk heb ik dan nog niet eens alles benoemd. Kan je als bedrijf zeggen 'kan iedereen overkomen' en vervolgens beterschap beloven, maar een bedrijfscultuur veranderen gaat nog niet zo simpel. Kijk maar naar Boeing.
Persoonlijk hoop ik dat MS de kerneltoegang dicht gaat metselen zodat deze praktijken niet meer mogelijk zijn in de toekomst.

[m_snel]

Ik vraag me af of de gemelde fout wel echt het gevolg was van intern testen.
Ik heb diverse berichten gelezen over dat een test module niet goed zou functioneren.
Maar er vaak weinig controle op de invoer van data, dus een ongeldig bestand kan opeens opleveren dat iemand je pc overneemt.
Het lijkt me dat hier de validatie van het configuratie bestand, wat niet correct was , de scanner deed crashen.

[RoadXY]

Voor zover ik het begrijp is dat MS al een poging heeft gedaan om kernel toegang dicht te metselen echter is dit door de EU in 2009 tegen gehouden omdat ze bang waren dat Microsoft op die manier met andere producten (bijvoorbeeld Windows Defender) meer rechten had dan de concurrentie:
https://www.theregister.c...ws_crowdstrike_kernel_eu/

[De Vliegmieren]

klopt, maar dat lijkt me redelijk simpel op te lossen door een clausule die een gelijk speelveld verplicht, zonder die directe kernel toegang te vereisen.

[Cambionn]

Nou dit. En elke concurrent had hetzelfde kunnen hebben gebeuren. "Waar mensen werken, worden fouten gemaakt". Dat geld nou eenmaal ook voor kritieke software.

Tuurlijk, dan nog moet er goed geanalyseerd worden waarom dit kon gebeuren en hoe dit te voorkomen is in de toekomst. Ik heb echter niet het idee dat dat niet gebeurd. Maar zelfs met de beste analyses, plannen en processen is dat is geen garantie dat er nooit meer wat mis gaat.

Wat belangrijk is, is wat er gebeurd als het mis gaat. Maar ik heb weinig klachten gehoord over Crowdstrike's afhandeling. Enkel van 1 vliegmaatschappij waar ook weerwoord op kwam dat dat niet het hele verhaal is (en gezien er verder weinig andere verhalen kwamen, neig ik naar het kiezen van Crowdstrike's kant. Hoewel ik niet echt een kant durf te kiezen gezien ik de details niet ken).

[AllanBrek]

Fouten worden en zullen blijven gemaakt worden.

Kan een bedrijf een "foute" update produceren?
Zekers, maar je mag dan verwachten dat er controle mechanismen zijn welke dit detecteren en mitigeren.

In de gehele test procedure was niet 1 mens betrokken. Was dit wel gebeurd dan was direct de impact zichtbaar en was het nooit released.

Als de architectuur anders was geweest, dat de driver in de kernel niet zomaar content uitvoert, dan was dit ook iets gebeurd.

Organisaties moeten hier echt naar gaan kijken in hun cyber resilience strategie want dit probleem is een architectuur probleem en niet "alleen maar een update issue".

[kodak]

Dat fouten gemaakt kunnen worden is het probleem niet. Het gaat er om welk risico ze hebben genomen om wereldwijd bij anderen problemen te veroorzaken.

Hun verdienmodel is winst maken door belangrijk invloed op belangrijke systemen van belangrijke klanten voor vaak belangrijke diensten te hebben. Dus waar een fout hele grote gevolgen heeft of kan hebben.

Tot nu toe toont het bedrijf niet aan waarom ze de fout, met alle mogelijke vormen van veilig ontwerpen, programmeren, testen en gefaseerd uitrollen, kon gebeuren. Ze richten zich vooral op het achteraf schade beperen onder hun voorwaarden. Dan is dit niet zomaar een risico, het is eerder onacceptabel.

[bbr]

1 Fout, maar eentje met flinke gevolgen.
En enkele weken nog een tweede die bijna net zoveel impact had.

Dan is het niet meer dan logisch dat ze op het matje geroepen worden.

[m_snel]

Het was volgens mij niet een fout, ik las hier meerdere reacties dat het eerder al fout ging op Linux .

[bossanova]

Het concept is gewoon een recipe for disaster.

Bedrijven en belangrijke instellingen zijn zelf verantwoordelijk voor hun falen. Dat kun je niet bij een ander neerleggen. Nuts en Utilitietsbedrijven stappen beter over op een oplossing met wat meer beheerslast.

[Verwijderd]

Natuurlijk kan je dat bij een ander neerleggen. Als je iemand duur betaald voor een belangrijke dienst, en ze verprutsen het waardoor jouw bedrijf plat ligt, dan is dat dus de schuld van die it verlener

[THM0]

Die er vervolgens geen aansprakelijkheid voor neemt.

[Netrunner]

Lastige hier is. CEO doet vaak akkoorden tekenen van laag tot laag. De medewerker heeft blaam. CEO is verantwoordelijk voor alle shit en zooi onder zijn gezag of leiderschap plaatsvindt. De medewerker heeft een menselijke fout gemaakt. De straf gaat naar alle waarschijnlijkheid naar CEO + deel van het bestuur. CEO mag antwoord geven op de vragen die zullen komen. Op matje worden geroepen betekent niet 1 op 1 dat er straffen of maatregelen aan verbonden zijn.

[HollowGamer]

Maar wie verprutst het hier precies?

MS die zomaar alles toelaat in ring-0 (zonder enige certificering)? MS dat hun software niet op orde heeft, waardoor de hele wereld allemaal van dit soort tools moet draaien?

Persoonlijk vind ik dat wij ook onze verantwoordelijk moeten nemen. We moeten ons niet afhankelijk maken van Amerikaanse bedrijven, maar investeren in onze bedrijven en tech. (dat kan ook Europees).

[Blokker_1999]

Microsoft laat al heel lang niet meer alles toe zonder certificering. Alles wat in de kernel wordt ingeladen moet digitaal ondertekend zijn. Verder is de Crowdstrike driver ook gewoon goedgekeurd via WHQL waardoor deze ook door de kwaliteitscontrole van Microsoft is geraakt. Dit in tegenstelling tot bijvoorbeeld Linux systemen waar wel iedereen zonder certificering kernel modules kan maken en inladen.

En hoe heeft MS zijn software niet op orde? En wie heeft het dan wel op orde? Want als ik kijk naar CVEs voor macOS of Linux dan komen er daar ook regelmatig leuke dingen voorbij hoor. Denk je nu echt dat die andere systemen onkwetsbaar zijn en in bedrijven zonder endpoint protection mogen draaien?

Waarom zo nodig de schuld bij Microsoft leggen? Waarom zo kwaad op dat bedrijf? Waarom gewoon foute informatie verspreiden?

[HollowGamer]

Verder is de Crowdstrike driver ook gewoon goedgekeurd via WHQL waardoor deze ook door de kwaliteitscontrole van Microsoft is geraakt. Dit in tegenstelling tot bijvoorbeeld Linux systemen waar wel iedereen zonder certificering kernel modules kan maken en inladen.

Geef je in deze zin niet mijn punt al aan? MS heeft geen waterdichte test blijkbaar, en Crowdstrike ook niet.

In tegenstelling tot Linux, zitten de meeste drivers/modules in de kernel, niet daarbovenop. Voordeel is dat je daarmee echt direct met upstream praat, en iemand iets van een source zou zijn. Het zou dan mogelijk wel zijn opgevallen, de filesize was bijvoorbeeld al een goede indicatie.

Overigens laat Linux wel blobs toe. Persoonlijk haat ik die, al kun je er niet omheen (ik moet toch op internet kunnen). Gelukkig heeft Linux in veel gevallen, een simpel command om een kernel-module te blacklisten. Bij Windows mag je van geluk spreken als je safe-mode in komt.

Ik heb (gelukkig) geen ervaring met deze module. Maar denk persoonlijk dat Linus bijvoorbeeld niet echt staat te springen om dit soort oplossingen?

En hoe heeft MS zijn software niet op orde? En wie heeft het dan wel op orde? Want als ik kijk naar CVEs voor macOS of Linux dan komen er daar ook regelmatig leuke dingen voorbij hoor. Denk je nu echt dat die andere systemen onkwetsbaar zijn en in bedrijven zonder endpoint protection mogen draaien?

MS draait op legacy, heel veel legacy. Ja, er is heel veel uit, maar nog altijd niet genoeg. Veel CVEs gaan dan ook over oudere libs, of zelfs nieuwere, waarbij je via een omweg nog op een BitLocker-volume komt.

Zijn andere OS'en onkwetsbaar? Nee, dat geloof ik niet. Zijn ze wel beter ontwikkeld? Ja, dat geloof ik wel.
De Unix standaard heeft een andere filosofie dan de MS standaard. Waarbij Unix echt geeft om scheiden met users/groepen, is dat MS pas veel later de standaard geworden. Iets als UAC, had Linux/MacOS al jaren.

Daarnaast is er in mijn ogen nog een goede reden; Linux-distro hebben package-managers. Die zijn verre van waterdicht (vraag Canonical), maar zijn beter dan niets. Op MacOS hoop ik stiekem dat Apple ooit brew gaat meeleveren als standaard, maar er staat gelukkig al vrij veel in de AppStore, en zoals gezegd heeft Apple ook voor apps (+ erbuiten) een heel permissie systeem (again niet waterdicht, maar toch).

Waarom zo nodig de schuld bij Microsoft leggen? Waarom zo kwaad op dat bedrijf? Waarom gewoon foute informatie verspreiden?

Is het fake of een mening die je minder aanstaat? Ik heb niet veel met MS (buiten VSCode - al is het niet perfect), het is in mijn ogen een typisch Amerikaans bedrijf. Heel veel marketing, veel markshare, en eigenlijk een heel mager product hebben.

Ik heb nu eenmaal meer met Red Hat (Apple vind ik overpriced) of iets kleins als system76, dan een bedrijf als MS of Intel. Misschien omdat ik altijd voor de underdog ben, of misschien te kritisch ben op bedrijven die hun eigen stuff nooit op orde hebben?

[Reactie gewijzigd door HollowGamer op 31 augustus 2024 11:05]

[bossanova]

Het is fundamenteel fout om bij utiliteitsbedrijven een ongecontroleerde afhankelijkheid te creëren van welk bedrijf of instantie dan ook. Degenen die deze software hebben geinstalleerd/geconfigurreerd hebben dit blijkbaar allemaal op 'auto-update' gezet.

Nou kan die CEO wel zijn excuses gaan aanbieden maar dan had 'Bill Gates' of een van zijn opvolgers dat al tig keer moeten doen in het verleden. De verantwoordelijkheid voor die 'auto-update' zetting ligt toch echt bij die afnemers zelf.

Wij draaien onze kritieke infrastructuur ook niet met afhankelijkheid van 1 leverancier. De 'getroffen' afnemers moeten echt eens in de spiegel kijken.

[aikebah]

Degenen die deze software hebben geinstalleerd/geconfigurreerd hebben dit blijkbaar allemaal op 'auto-update' gezet.

Naar ik begrepen heb is dat geen instelling op Crowdstrike (op windows), maar de enig mogelijke modus operandi. Dus als je dan iemand zou willen beschuldigen bij de klant dan is dat degene die de keus heeft gemaakt op Crowdstrike in te zetten voor de endpoint security, niet degene die de software vervolgens moest uitrollen.
Als ik het goed begrepen heb (zit nogal ver van de beslissende partijen af) was precies dat aspect (directe autoupdate zonder eigen controle) bij mijn werkgever een belangrijke reden om geen crowdstrike in te zetten voor de endpoint security.

[Froggle]

Om maar meteen tot het grote probleem te komen. Bedrijven (of Senior management in ieder geval) denken dat alles met een software oplossing is opgelost. Meeste IT bedrijven met senior engineers hadden hun zaakje snel op orde, maar instanties die alles uitbesteden moesten achter aansluiten. Laten dit (vliegvelden, ziekenhuizen) nou net vrij belangrijke organen zijn waar een maatschappelijk probleem ontstaat.

Maar zonder Crowdstrike had alles wel veel vaker plat gelegen of ben je zonder dat je het weet bedrijfsgeheimen aan het versturen.

Wij hebben ondanks dat we er geen grote issues (behalve een drukkere vrijdag) aan overgehouden, maar we zullen vanaf nu toch bij het inrichten van nieuwe systemen dit in het achterhoofd houden. Wellicht niet verkeerd veel meer op VM's te draaien, zodat je sneller een snapshot kan terugzetten.

[Reactie gewijzigd door Froggle op 1 september 2024 07:55]

[m_snel]

Mijn ervaring is dat bedrijven weinig kunnen zonder mensen die gedetacheerd zijn, maar goed u bedoelt waarschijnlijk uitbesteed.

[Froggle]

Ja je hebt helemaal gelijk

[Harm_H]

Ik denk dat de Nederlandse bedrijven en overheden gewoon door blijven gaan met het gebruik van CrowdStrike. Vanwege een cultuur van hypogonadisme. Even klagen en toch accepteren. Slecht release management en slecht testen hoort er gewoon bij.
Of denk je dat bedrijven wel overstag gaan om CrowdStrike producten eruit te halen?

[Reactie gewijzigd door Harm_H op 30 augustus 2024 21:15]

[WillySis]

Er zullen wel bedrijven zijn die zich op het gebruik van CrowdStrike herbezinnen. Die zullen het interview ook met veel belangstelling volgen.
Je kan echter testen wat je wil, maar de kans op een fout kan je nooit helemaal naar nul brengen, hooguit een goede benadering daarvan. Een compilatie om de laatste fout eruit te halen kan bijvoorbeeld al een nieuwe fout introduceren bijvoorbeeld omdat er nu net tijdens die compilatie een kleine stroomonderbreking was die net niet tot een error leidt, maar wel een fout in de software veroorzaakt.

De storing zegt ook niets over de kwaliteit van het product zelf. Alleen dat er dingen misgegaan zijn die niet mis hadden mogen gaan. Bij vliegtuigen gaat alles normaal ook goed en als er wat mis gaat zijn er protocollen om dat op te lossen. Helaas gaat er ondanks alles toch wel eens iets mis, wat dan resulteert in een zeer ongelukkige manier van neerkomen. Toch zien we vliegtuigen als de meest veilige manier van transport. De cijfers ondersteunen dat ook.

[Harm_H]

De vergelijking met vliegtuigen is wel ironisch want ook bij Boeing 737MAX is een fout niet slechts een fout, maar een bedrijfs- en cultuurprobleem.

[WillySis]

Goed opgelet!
Ik had de vergelijking met vliegtuigen ook om die rede gekozen. Zelfs met vliegtuigen kan er een bedrijfsprobleem op de achtergrond meespelen.
In eerste instantie heeft Boeing gewoon veel te veel zelf de certificering mogen doen, wat leidde tot twee neergestorte vliegtuigen vanwege een software fout. De andere fouten zijn puur bedrijfscultuur waar controles niet de prioriteit krijgen die noodzakelijk is. Ondanks de fouten in afgeleverde vliegtuigen leidt dat nog niet tot neerstorten van vliegtuigen. Piloten kunnen de vliegtuigen (met moeite) nog steeds veilig aan de grond zetten.

Ook met software kan je een aantal bugs hebben die in bepaalde gevallen veiligheidsrisico's met zich meebrengen, maar de kans op een catastrofe (zoals het niet opstarten van de systemen) is erg klein.

[SPee]

In eerste instantie heeft Boeing gewoon veel te veel zelf de certificering mogen doen, wat leidde tot twee neergestorte vliegtuigen vanwege een software fout. De andere fouten zijn puur bedrijfscultuur waar controles niet de prioriteit krijgen die noodzakelijk is.

Die software fout is ook ontstaan door die bedrijfscultuur. (Een wijziging kleiner voordoen dan hij is, een cruciaal besturingsonderdeel niet redundant uitvoeren)
Zelf die certificering doen, zou geen probleem zijn als je (als bedrijf) ook belang hecht dat het goed gebeurd. Maar door de bedrijfscultuur was die prioriteit er niet. Dan kun je sjoemelen (en door de bedrijfscultuur was de druk om dat te doen hoog). En doordat je zelf je de certificering mag doen wordt je daarop niet teruggefloten door de controleur.

Ja, dan kun je gewoon wachten op fouten. Die met een andere bedrijfscultuur gewoon voorkomen konden worden. Dus dat is wat mij betreft gewoon nalatigheid.

[WillySis]

De software fout was inderdaad bekend, maar er was wel een oplossing voor bedacht in de vorm van een (optioneel) waarschuwingslampje en een protocol in het handboek. Helaas was de communicatie zo slecht dat slechts enkele mensen van het probleem afwisten.

Zelf testen en zelf certificeren (Wij van WC-eend adviseren .../ slager keurt zijn eigen vlees) heeft altijd risico's. Extra testen en aanpassingen kosten nu eenmaal geld. Vroeg of laat wordt een afweging gemaakt of nog verder testen nog nodig is en of die kosten opwegen tegen het risico van een over het hoofd geziene fout.
Bij beveiligingssoftware gaat het niet anders. Pas als daar externe bedrijven voor moeten worden ingeschakeld wordt het probleem kleiner, maar blijft nog altijd bestaan. Veiligheid is ook nog eens een race tegen de criminaliteit en die blijven naar onbekende zwakheden speuren.

[The Realone]

Wat is precies het nut van nu overstappen op een andere EDR denk je? Naar welk product zou jij overstappen en welke garantie geven die dat zij niet eenzelfde fout maken? Als je Crowdstrike op 18 juli gevraagt had of hun test-strategie op orde was, had je een volmondig ja gekregen. Net als dat je dat had gekregen bij een SentinelOne, CarbonBlack, CyberReason, etc.
Ik denk dat je nu wellicht zelfs beter af bent bij CrowdStrike, want die fout gaat echt niet nogmaals gemaakt worden.

[SunnieNL]

Je zou twee edr’s kunnen gebruiken en de dubbel uitgevoerde systemen kunnen splitsen. Een op de ene edr, het backup systeem op de andere. Enige nadeel: dubbel zo veel werk, al dan niet triple zo veel.

En dat crowdstrike de fout niet nogmaals gaat maken valt maar te bezien. Want echt duidelijk hoe het heeft kunnen gebeuren, waarom ze er zelf niet achterkwamen en hoe ze het in de toekomst gaan voorkomen zijn ze niet. Ook crowdstrike moet aan de kosten denken.

[The Realone]

Twee EDRs is in de meeste gevallen totaal onrealistisch. Afgezien van de kosten zit je dan ook nog eens met 2 verschillende omgevingen, terwijl je juist de prod en backup omgeving in sync wil houden. In theorie kan het, in de praktijk gaat dat niet gauw gebeuren.

En prima als we zeggen dat Crowdstrike wellicht best die fout eens kan maken, maar dan blijft staan dat er geen enkel alternatief is dat diezelfde fout niet kan maken.

[Bosjvd2]

Er is wel degelijk een heel uitgebreid rapport gemaakt over wat er precies is gebeurt en welke stappen ze nemen om dat in de toekomst te voorkomen. En sommige van die stappen zijn reeds uitgevoerd. Er is nu een ring deployment van de content updates waarbij je zelf aan kan geven in welke ring je wilt vallen bijvoorbeeld.

[Blokker_1999]

Twee oplossingen doe je niet snel. Zoals je zelf aangeeft, de kosten gaan dan meer dan verdubbelen, doordat je minder licenties afneemt gaat de unit prijs omhoog. Je security team zal ook groter moeten worden want je hebt ineens 2 platformen te onderhouden en te analyseren.

Want deze platformen beschermen niet alleen je systemen, ze geven je ook inzichten in je systemen, en je analyses ga je dus ineens 2x moeten uitvoeren waardoor corrolaties ook nog eens verloren kunnen gaan of zeer moeilijk worden, tenzij je nog meer investeert in een dienst die de logs van de twee weer kan gaan aggregeren.

[mutsje]

Gebeurd bij talloze bedrijven in Release A is de bug opgelost brengen ze release B uit zit de bug er weer in omdat ze vergeten zijn het door te voeren. Is bij enorm veel software leveranciers zo. Dus om nou crowdstrike vanwege een enorme fuckup eruit te zetten... is een paniek reactie.

[storchaveli]

Word iets als ‘wij van wc eend’

[Lednov]

Nee, het wordt eerder iets dat senatoren vragen gaan stellen over zaken waar ze ab-so-luut geen sjoege van hebben. Als voorgaande hoorzittingen een garantie voor de toekomst zijn... Laat dan maar.

[PhaeTom]

My thoughts exactly. Ik denk dat dit weer hilarische beelden voor sites als 9Gag op gaat leveren. Het klinkt nu heel krachtig, maar we zullen de uitwerking af moeten wachten.

[HollowGamer]

3 dagen praten over niets, garanties, bla bla.

Misschien kan de politiek daar eens kijken na serieuze problemen? Zoals de gezondheidszorg.

[storchaveli]

Amen

[Bergen]

Zelfs bij de hoorzitting van Facebook werden hele domme vragen gesteld, ik zie de hilariteit na deze hoorzitting met smart tegemoet.

[Blokker_1999]

Het zijn domme vragen voor mensen zoals wij. Maar dat is helemaal hoe de gemiddelde persoon op deze aardkloot denkt, en wat zij er van weten. In dat opzicht is het net goed dat zulke vragen ook eens gesteld worden.

Als ik aan jouw vraag hoe het mogelijk is dat een melkkoe jarenlang melk geeft of hoe vaak per dag ze gemolken moet worden, weet jij dan zomaar het antwoord op die vragen? Toch vindt een melboer dat een domme vraag.

Maar diezelfde volksvertegenwoordigers moeten ook beslissingen nemen die belang hebben op die boeren. Zij moeten beslissingen nemen over transport, zij moeten beslissingen nemen over energie, zij moeten beslissingen nemen over financieen.

Begin je in te zien waarom ze onmogelijk alles over alles kunnen weten?

[Bumpy_NL]

Maar je mag wel van volksvertegenwoordigers verwachten dat ze de materie bestuderen. De vragen op zich zijn niet dom, maar het is wel dom om ze daar te stellen.

Hetzelfde zie je terug bij de verhoren van de directeur van de secret service. Vragen in de orde van: "Klopt het dat je versleutelde berichten apps gebruikt?" kwamen daar voorbij. Waarbij het gebruik van versleutelde berichten apps in context als negatief wordt gezien.

[Blokker_1999]

Volksvertegenwoordigers proberen zich te profileren, zeker in de VS, door zich in deze hoorzaken in te werken die veel belangstelling krijgen van het publiek. En vele bereiden zich ook echt voor met enkele goede vragen. Ze hebben uiteindelijk maar enkele minuten spreektijd per vertegenwoordiger. Anderen doen dat niet. En achter beide steekt een strategie achter waarmee zij denken punten te kunnen scoren bij onbesliste kiezers.

Ik vind het zelf ook spijtig dat men altijd weer ditzelfde voorbeeld moet aanhalen als zijnde een generalisatie van hoe het gesteld is met die volksvertegenwoordigers, dat dit ene voorbeeld betekend dat ze allemaal altijd zulke vragen stellen. Maar dat is dus ook niet het geval.

Zoek bijvoorbeeld maar eens op Katie Porter, en hoe zij enkele van Amerika's grootste CEOs het vuur aan de schenen legt in haar bevragingen. Is zij een experte? Absoluut niet.

Het belangrijkste doel van zulke vehroren is uiteindelijk om die volksvertegenwoordigers uit te leggen hoe alles net werkt, en wat goed is, wat slecht is. Je krijgt niet enkel getuigenissen van CEOs, maar ook van onafhankelijke experts. Zij krijgen allemaal een kans om hun visie te geven en om vragen te beantwoorden.

[Bumpy_NL]

Ik sta achter mijn eerder genoemde punt, maar ook achter je kanttekening dat er zeker niet alleen maar domme vragen worden gesteld. Ik probeerde niet te insinueren dat er alleen maar domme vragen worden gesteld of dat de norm is. Het is wel bedroevend als mensen onvoorbereid (domme) vragen gaan stellen in deze setting. Dat veroorzaakt inhoudelijk gezien alleen maar ruis en het volk is daar uiteindelijk niet mee gediend.

[Lord Anubis]

Niet over alles, dat snap iedereen maar als jij iets vertegenwoordigd dan heb je een verantwoordelijkheid en een onderzoeksplicht. We kennen de w’s wie wat waar wanneer waarom. Ze moeten zelf zich daarin/daarmee voorbereiden en in verdiepen om de juiste vragen te stellen zonder geneuzel.

Bestudeer het. Neem een studie erin. Stel je vragen vooraf aan een expert.

[CH4OS]

Tweede Kamerleden houden zich dan ook enkel bezig met hun specialismen. Het is een behoorlijke illusie te denken dat een politiek persoon, van kamerlid tot senator, zich bezig houdt met álle onderwerpen die de revue passeren. Juist om de reden die je schetst; men kan niet alles weten.

[Reactie gewijzigd door CH4OS op 31 augustus 2024 08:08]

[Rinzwind]

Het andere uiterste is ook niet wenselijk: men wil niets weten. Halverwege naar de huisarts een technocratie is zo gek nog niet. De mate van onbenul en termijndenken is van de zotte 🤡 😥

[Blokker_1999]

En dan komt het tot een stemming in de tweede kamer en 95% stemt niet want ze weten helemaal niet waar het over gaat en geen enkele voorstel kan nog aangenomen worden.

[HollowGamer]

Zeker hilarisch, maar ondertussen vraag je af wat we doen op deze planeet.
Of ben ik de enige?

[Siaon]

(DNA) Repliceren? Net als al het andere leven?

[ZeromaNoiS]

Om het maar even plat te slaan.

[Honbrifcl]

Jouw reactie is kort maar zeer filosofisch, ik ben ook de verbinding met de huidige wereld langzaam kwijt. We maken het onszelf zo ingewikkeld en hebben geen plan en overzicht wat we aan het doen zijn. Afhankelijk van complexe technologie die we niet nodig hebben om te overleven, waar altijd wel eens iets fout zal gaan en dan op de bodem moeten uitzoeken waarom, en een schuldige zoeken die moet boeten.
Back to basic lijkt me een betere weg in de toekomst en dan bedoel ik niet Basic...

[StackMySwitchUp]

BASIC?

[Xfade]

waar overheden zich druk om maken terwijl er veel andere dingen zijn waar ze zich niet mee lijken te bemoeien *

[TheekAzzaBreek]

Het zijn niet alleen maar bejaarden en digibeten.

Maar het Huis heeft er verder weinig over te zeggen, het zal vooral een profilerings excercitie zijn.

[Bas Boss]

De vraag is of ze echt verstand van zaken moeten hebben. De geleverde service heeft gigantisch gefaald. Ik zie veel reacties voorbij komen als “kan gebeuren”. Als dat zo is dan neem je bewust een risico, de vraag is of de service ook op die manier wordt verkocht.

[sapphire]

Google maar eens op ‘the internet is a series of tubes’

[theduke1989]

Zal me niet verbazen als die aankomen met mensen die toen ook de ceo van TikTok ondervroegen.