Försörjningskedjans risker fick dig ner? Håll dig lugn och bli strategisk!

Säkerhetsbranschen tappar kollektivt förståndet när nya sårbarheter upptäcks i mjukvara. OpenSSL är inget undantag, och två nya sårbarheter överväldigade nyhetsflöden i slutet av oktober och början av november 2022. Upptäckt och avslöjande är bara början på denna oändliga sårbarhetscykel. Berörda organisationer ställs inför åtgärdande, vilket är särskilt smärtsamt för dem som står i frontlinjen inom IT. Säkerhetsledare måste upprätthålla en effektiv cybersäkerhetsstrategi för att hjälpa till att filtrera bort en del av bruset på nya sårbarheter, känna igen effekterna på försörjningskedjor och säkra deras tillgångar därefter.

Supply Chain Attacker försvinner inte

På ungefär ett år har vi drabbats av allvarliga sårbarheter i komponenter, inklusive log4j, Vårramaoch OpenSSL. Utnyttjande av äldre sårbarheter upphör heller aldrig från implementeringar som är felkonfigurerade eller som använder kända sårbara beroenden. I november 2022 fick allmänheten veta om en attackkampanj mot Federal Civilian Executive Branch (FCEB), hänförlig till ett statligt sponsrat iranskt hot. Denna amerikanska federala enhet körde VMware Horizon-infrastruktur som innehöll Log4Shell-sårbarheten, som fungerade som den initiala attackvektorn. FCEB drabbades av en komplex attackkedja som inkluderade laterala rörelser, kompromiss med autentiseringsuppgifter, systemkompromiss, nätverksbeständighet, bypass av slutpunktsskydd och kryptojackning.

Organisationer kan fråga sig "varför konsumerar OSS överhuvudtaget?" efter säkerhetsincidenter från sårbara paket som OpenSSL eller Log4j. Supply chain attacker fortsätter att trenda uppåt eftersom återanvändning av komponenter är "bra affärsmässigt meningsfullt" för partners och leverantörer. Vi konstruerar system genom att återanvända befintlig kod istället för att bygga från grunden. Detta för att minska ingenjörsarbetet, skala operativt och leverera snabbt. Programvara med öppen källkod (OSS) anses allmänt vara pålitlig på grund av den offentliga granskning som den får. Men mjukvaran förändras hela tiden och problem uppstår genom kodningsfel eller kopplade beroenden. Nya problem upptäcks också genom utveckling av test- och exploateringstekniker.

Ta itu med sårbarheter i försörjningskedjan

Organisationer behöver lämpliga verktyg och processer för att säkra modern design. Enbart traditionella tillvägagångssätt som sårbarhetshantering eller tidpunktsbedömningar kan inte hänga med. Regler kan fortfarande tillåta dessa tillvägagångssätt, vilket vidmakthåller klyftan mellan "säkert" och "kompatibelt". De flesta organisationer strävar efter att få en viss nivå av DevOps-mognad. "Kontinuerlig" och "automatiserad" är vanliga egenskaper hos DevOps-praxis. Säkerhetsprocesser bör inte skilja sig åt. Säkerhetsledare måste behålla fokus under hela bygg-, leverans- och körtidsfaserna som en del av deras säkerhetsstrategi:

• Skanna kontinuerligt i CI/CD: Sikta på att säkra byggledningar (dvs. skift åt vänster) men erkänn att du inte kommer att kunna skanna all kod och kapslad kod. Framgång med skift-vänster-metoder begränsas av skannerns effektivitet, korrelation av skannerutdata, automatisering av beslut om frisläppande och skannerns slutförande inom releasefönster. Verktyg bör hjälpa till att prioritera risker för fynd. Alla fynd är inte handlingsbara och sårbarheter kanske inte kan utnyttjas i din arkitektur.

• Skanna kontinuerligt under leverans: Komponentkompromisser och miljöavvikelser inträffar. Applikationer, infrastruktur och arbetsbelastningar bör skannas när de levereras ifall något äventyras i den digitala försörjningskedjan när de hämtas från register eller arkiv och bootstraps.

• Skanna kontinuerligt under körning: Runtime-säkerhet är utgångspunkten för många säkerhetsprogram, och säkerhetsövervakning stöder de flesta cybersäkerhetsinsatser. Du behöver mekanismer som kan samla in och korrelera telemetri i alla typer av miljöer, dock, inklusive moln-, container- och Kubernetes-miljöer. Insikter som samlats in under körning bör återkopplas till tidigare bygg- och leveransstadier. Identitet och serviceinteraktioner

• Prioritera sårbarheter som exponeras under körning: Alla organisationer kämpar med att ha tillräckligt med tid och resurser för att skanna och fixa allt. Riskbaserad prioritering är grundläggande för säkerhetsprogramarbetet. Internetexponering är bara en faktor. En annan är sårbarhetens svårighetsgrad, och organisationer fokuserar ofta på frågor med hög och kritisk svårighetsgrad eftersom de anses ha störst effekt. Det här tillvägagångssättet kan fortfarande slösa cykler av ingenjörs- och säkerhetsteam eftersom de kan jaga sårbarheter som aldrig laddas under körning och som inte går att utnyttja. Använd runtime-intelligens för att verifiera vilka paket som faktiskt laddas i körande applikationer och infrastruktur för att veta den faktiska säkerhetsrisken för din organisation.

Vi har skapat produktspecifik vägledning att styra kunder genom den senaste OpenSSL-galenskapen.

Den senaste OpenSSL-sårbarheten och Log4Shell påminner oss om behovet av cybersäkerhetsberedskap och effektiv säkerhetsstrategi. Vi måste komma ihåg att CVE-ID bara är de kända problemen i offentlig mjukvara eller hårdvara. Många sårbarheter rapporteras inte, särskilt svagheter i egentillverkad kod eller miljöfel. Din cybersäkerhetsstrategi måste ta hänsyn till distribuerad och mångsidig teknologi av modern design. Du behöver ett moderniserat sårbarhetshanteringsprogram som använder runtime-insikter för att prioritera saneringsarbete för ingenjörsteam. Du behöver också hotdetektering och svarsfunktioner som korrelerar signaler mellan miljöer för att undvika överraskningar.

Om författaren

Michael Isbitski, direktör för Cybersecurity Strategy på Sysdig, har forskat och givit råd om cybersäkerhet i över fem år. Han är bevandrad i molnsäkerhet, containersäkerhet, Kubernetes-säkerhet, API-säkerhet, säkerhetstestning, mobilsäkerhet, applikationsskydd och säker kontinuerlig leverans. Han har väglett otaliga organisationer globalt i deras säkerhetsinitiativ och stödja deras verksamhet.

Före sin forsknings- och rådgivningserfarenhet lärde Mike sig många hårda lektioner på frontlinjen av IT med över 20 års erfarenhet av praktiker och ledarskap fokuserad på applikationssäkerhet, sårbarhetshantering, företagsarkitektur och systemteknik.