Inom cybersäkerhet finns det vissa sårbarheter som går utöver den tekniska allvarlighetsgraden och blir händelser som präglar hela branschen. Log4Shell år 2021 var en sådan händelse. På senare tid har sårbarheter som sammantaget diskuteras under samlingsbegreppet PHP2Shell åter väckt samma oro hos säkerhetsteam världen över.
I båda fallen sträcker sig lärdomen långt bortom ett CVSS-betyg.
Säkerhetsexperter använder ofta ramverk som CVSS för att prioritera åtgärdsinsatser, och det med rätta. Sårbarheter som får global uppmärksamhet påminner oss dock om att risken inte enbart bestäms av den tekniska allvarlighetsgraden. Den verkliga affärsmässiga påverkan av en sårbarhet påverkas av en kombination av faktorer: hur utbredd den drabbade tekniken är, hur lätt den är att utnyttja, tillgången till offentlig proof-of-concept-kod, exponering på internet och hur snabbt hotaktörer utnyttjar nya attackvektorer.
När dessa faktorer samverkar står organisationer inför en mycket större utmaning än att bara distribuera en patch.
Ett CVSS-betyg ger en viktig teknisk bedömning av en sårbarhet, men det fångar inte upp den fullständiga operativa risken.
Tänk på de frågor som säkerhetsansvariga bör ställa sig när en kritisk sårbarhet avslöjas:
Svaren på dessa frågor ger ofta en mer exakt bild av organisationens risk än själva CVSS-poängen.
Det är just detta som gjorde Log4Shell så omvälvande. Organisationer världen över hade svårt att hantera situationen, inte för att de inte förstod sårbarheten, utan för att de ofta inte visste var den sårbara komponenten hade distribuerats. Dolda beroenden, inbäddad programvara, tredjepartsapplikationer och ofullständiga inventeringar av tillgångar skapade en utmaning när det gällde insyn som varade i veckor och, i vissa fall, månader.
Idag ser vi fortfarande liknande mönster varje gång sårbarheter som är lätta att utnyttja dyker upp.
Säkerhetsramverk utgår ofta från att kritiska sårbarheter bör åtgärdas så snabbt som möjligt. Även om detta är det ideala utfallet förstår alla som arbetar i företagsmiljöer de praktiska realiteterna.
Att åtgärda sårbarheter i verksamhetskritiska system kräver ofta:
Äldre system kan ytterligare komplicera åtgärdsarbetet. I vissa fall kanske inte ens patchar finns tillgängliga omedelbart.
Resultatet blir en vanlig och obekväm situation: sårbarheten är känd, utnyttjande är möjligt, men åtgärderna kan inte genomföras omedelbart.
I detta läge blir organisationens mognad den avgörande faktorn.
När omedelande åtgärder inte är möjliga behöver organisationer alternativa kontroller som minskar exponeringen och bromsar angriparna.
Det är här en stark säkerhetsposition visar sitt värde.
En motståndskraftig organisation bör kunna:
Organisationer kan inte skydda tillgångar som de inte vet att de har.
Omfattande funktioner för tillgångshantering och programvaruinventering ger den insyn som krävs för att snabbt kunna fastställa exponeringen när en uppmärksammad sårbarhet upptäcks.
Förmågan att besvara frågan ”Är vi drabbade?” inom några timmar istället för dagar kan avsevärt minska affärsrisken.
En strategi med flera försvarslager kan avsevärt minska sannolikheten för att en sårbarhet utnyttjas innan permanenta åtgärder har vidtagits.
Exempel på detta är:
Dessa åtgärder kan inte eliminera sårbarheten, men de kan avsevärt minska angriparens möjligheter att utnyttja den.
Organisationer bör utgå från att offentliga utnyttjandeförsök kommer att inledas kort efter att sårbarheten har offentliggjorts.
Av den anledningen måste säkerhetsteamen snabbt ta fram:
Tidig upptäckt kan vara avgörande för om ett intrångsförsök kan stoppas eller om man tvingas hantera en allvarlig säkerhetsincident.
Två mätvärden blir särskilt viktiga vid storskaliga sårbarhetshändelser:
Genomsnittlig tid till upptäckt (MTTD)
och
Genomsnittlig tid till åtgärd (MTTR)
Ju snabbare en organisation kan identifiera misstänkt aktivitet och inleda åtgärder för att begränsa skadan, desto mindre blir den potentiella påverkan.
I många incidenter uppstår den största skadan under de första timmarna efter att säkerhetsbristen utnyttjats. Genom att minska insatstiderna begränsas direkt angriparens vistelsetid och den potentiella störningen av verksamheten.
Vikten av beredskap inför incidenter
En av de viktigaste lärdomarna från Log4Shell var inte av teknisk karaktär utan av operativ karaktär.
Organisationer med väldefinierade incidenthanteringsplaner, beprövade handböcker och tydliga beslutsprocesser kunde reagera betydligt mer effektivt än de som försökte ta fram rutiner mitt under krisen.
Beredskap innebär att ha:
Nästa stora sårbarhet kommer inte att meddelas i förväg. Beredskapen måste redan finnas på plats.
Nästa kritiska sårbarhet är oundviklig.
Oavsett om den kallas Log4Shell, PHP2Shell eller något helt annat kommer organisationer att fortsätta att ställas inför snabbt föränderliga hot som utmanar deras förmåga att reagera.
De mest motståndskraftiga organisationerna är inte nödvändigtvis de som kan installera säkerhetsuppdateringar på alla system omedelbart. Det är de organisationer som förstår sin miljö, kontinuerligt övervakar hotbilden, implementerar effektiva kompensationsåtgärder och agerar beslutsamt när incidenter inträffar.
Frågan är inte om nästa stora sårbarhet kommer att dyka upp.
Frågan är om din organisation är förberedd på att begränsa dess konsekvenser när den väl inträffar.
På Integrity360 förstår vi att sårbarhetshantering inte längre bara handlar om att installera säkerhetsuppdateringar. Det handlar om att hantera risker under hela livscykeln för en säkerhetshändelse.
Genom tjänster som:
Vi hjälper organisationer att stärka sin säkerhetsposition, förbättra insynen i sina miljöer och avsevärt minska tiden för upptäckt och begränsning av incidenter.
När åtgärder inte kan vidtas omedelbart fokuserar vi på att säkerställa att organisationerna har den insyn, övervakning och responskapacitet som krävs för att begränsa angriparnas framgång och upprätthålla den operativa motståndskraften.