Log4Shell har något förändrats?

Sårbarheten som skakade IT-världen: Log4Shell har något förändrats?

En kritisk tillbakablick och nutidsspaning två år efter IT-krisen

Kommer ni ihåg den 9 december för två år sedan? Det var dagen då världen gick i högsta beredskap på grund av upptäckten av Log4Shell, en av de mest kritiska sårbarheterna någonsin i ett mjukvarusystem. Denna allvarliga sårbarhet i Apache Log4j, ett omfattande använt Java-loggningsramverk, visade sig ha potentialen att påverka nästan varje organisation. Nu, två år senare, låt oss reflektera över vad vi har lärt oss och hur vi kan arbeta för en säkrare framtid inom området för öppen källkod.

Log4Shell kunde potentiellt tillåta angripare att genomföra fjärrstyrda kodexekveringsattacker för att kompromettera drabbade servrar. Detta ledde till en omfattande ansträngning för att patcha system världen över. Trots detta visar en studie från Veracode att många organisationer fortfarande använder sårbara versioner av Log4j. Över en tredjedel av studiens analyserade applikationer använder fortfarande sårbara versioner av Log4j. Många utvecklare uppdaterar fortfarande inte tredjepartsbibliotek efter att de inkluderats i en kodbas, vilket bidrar till utbredd användning av föråldrade versioner. Det finns ett stort behov av förbättrad medvetenhet och resurser för att hantera sårbarheter inom öppen källkod.

Ska vi vara krassa så är resultatet från studien, att en tredjedel fortfarande är sårbara, två år senare, är ett underbetyg till många utvecklingsbolag som saknar processer för att validera vad de ”bakar in” i sina mjukvaror. Det är också ett underbetyg till driftleverantörer och organisationer som i egen driftregi saknar förmåga att uppdatera och patcha system, eller för den delen upptäcka sårbarheter i sina miljöer (patchade eller inte).

Avslutningsvis är det viktigt att understryka att säkerhetsutmaningarna kring öppen källkodsprogramvara inte enbart berör de som direkt använder öppen källkod. Det handlar inte om en enkel uppdelning mellan öppen källkod och kommersiell programvara; verkligheten är betydligt mer komplex. Många kommersiella programvaruprodukter, inklusive de från välkända företag som Oracle, Cisco, RedHat, IBM, VMware och Splunk, liksom molntjänster från Amazon Web Services och Microsoft Azure, bygger på eller integrerar öppen källkodsmoduler som Log4j.

Denna verklighet blev tydlig under Log4Shell-krisen då även dessa produkter och tjänster befanns vara sårbara för samma säkerhetsbrister. Så även om en organisation använder kommersiell programvara, kan den fortfarande vara exponerad för risker som härstammar från underliggande (inbakad) öppen källkod. Detta framhäver behovet av att alla aktörer, oavsett om de använder öppen källkod direkt eller indirekt via kommersiella produkter, måste vara noggranna och proaktiva i sitt arbete med IT-säkerhet.

En väsentlig del av denna säkerhetsåtgärd är att upprätthålla en strikt cyberhygien med tydliga processer för kontinuerlig patchning och sårbarhetsskanning av sin miljö. Organisationer behöver etablera robusta rutiner för att kontinuerligt identifiera och åtgärda sårbarheter. Detta kräver inte bara tekniska verktyg utan också en stark organisationskultur som prioriterar säkerhetsuppdateringar. För de organisationer som inte har resurser eller expertis att hantera dessa processer internt, är det klokt att överväga samarbete med tredjepartsleverantörer som specialiserar sig på cybersäkerhetstjänster. Genom att anlita experthjälp kan organisationer säkerställa att deras system är skyddade mot de senaste hoten och därmed minska sin exponering för potentiella säkerhetsbrister.

Säkerhetsarbetet är ett kontinuerligt ansvar som kräver uppmärksamhet, kunskap och resurser för att effektivt hantera de ständigt föränderliga hotlandskapen inom IT.