Den 19 juli påverkades flygtrafik, betalsystem, banker, börser med flera. Det var inte en cyberattack som många först trodde, utan tvärtom, sett till hotaktören. Det var Crowdstrikes programvara Falcon, som paradoxalt nog ska bidra till robustare system, som kraschade miljontals Windowsdatorer världen över. Ett problem som behövde avhjälpas manuellt vilket gjorde att det tog lång tid att återställa alla system.
Givetvis väcks frågor hur Crowdstrike testar sina mjukvarureleaser. Crowdstrike uttrycker i sin Root Cause Analysis rapport att de ska förbättra testverksamheten. Jag kan tycka att det är förvånande att en bugg som resulterade i en ”out-of-bound memory read” inte upptäcktes i den redan existerande testproceduren.
I kölvattnet har diskussioner väckts om det är rimligt att mjukvaror ska ha den åtkomst till operativsystemet som Falcon och en rad andra liknande mjukvaror använder sig av. Egentligen är det förvånansvärt att det inte har inträffat fler incidenter givet den ständiga uppdateringen som sker av den här typen av mjukvaror för att efter bästa förmåga hindra att sårbarheter utnyttjas. Det är trots allt en vardaglig risk som merparten accepterar givet att sannolikheten är näst in till obefintlig för att det som inträffat inträffar, men konsekvensen talar nu sitt tydliga språk.
Hur många har med detta som en risk i sin riskanalys? Min erfarenhet säger att de allra flesta gör riskanalyser på nivån att man är orolig för skadlig kod och att mitigeringen av risken är att implementera antivirus. En konsekvens av den nu inträffade incidenten är att drabbade organisationer blev i plötsligt behov av en mängd fotfolk för att råda bot. Finns den förmågan?
Givetvis kommer en incident likt denna att inträffa igen. Givetvis kommer också andra typer av incidenter att inträffa som kräver mänsklig handpåläggning. Lärdomen här är att rusta sig för även för det.
Givet att alla inte använder Falcon så blev inte spridningen större än till Crowdstrikes kunder som använder Falcon. Idén om att samla så många ägg som möjligt i samma korg, från samma tillverkare, vad gäller programvaror som ska bidra till en robustare tillvaro kan diskuteras. Den som har en linje att diversifiera sina insatser, och därmed även riskerna i organisationen, får inte alltid gehör för den linjen. Det finns skäl att ånyo fundera över riskaptiten som har ett betydligt bredare perspektiv än den nu aktuella incidenten.
Vilka andra överraskningar står runt hörnet? Givetvis har ingen av oss en äkta spåkula. Riskanalys är den metoden som lagstiftaren påkallar för att minimera risken att det oönskade inträffar, och när det oönskade händer rusta organisationen för att minimera skadan. Crowdstrike incidenten visade tydligt att även andras problem snabbt kan bli era problem.
Se inte riskanalysen som en check-in-the-box-övning, utan det är metoden och verktyget som rustar er inför framtidens utmaningar. Vi vet redan nu att vi står inför stora utmaningar som att gamla kryptoalgoritmer som RSA hastigt vittrar med kvantdatorernas intåg. Det är inte längre en fråga om, utan när det händer. Den 13 augusti annonserade NIST de första tre finalisterna av Post-Quantum Encryption Standards i ett led att ersätta RSA med flera algoritmer.
Jag tror få ligger sömnlösa inför just detta faktum utan tänker att detta är någon annans problem och att det löser sig med tiden. Att leva med risker är definitivt ett sätt att hantera risk och det är inget fel med det så länge det är medvetna beslut som tas.
Thomas Nilsson
