Forsyningskjederisiko fikk deg ned? Hold deg rolig og bli strategisk!

Sikkerhetsindustrien mister kollektivt vettet når nye sårbarheter oppdages i programvare. OpenSSL er intet unntak, og to nye sårbarheter overveldet nyhetsfeeds i slutten av oktober og begynnelsen av november 2022. Oppdagelse og avsløring er bare begynnelsen på denne uendelige sårbarhetssyklusen. Berørte organisasjoner står overfor utbedring, noe som er spesielt smertefullt for de som er i frontlinjen av IT. Sikkerhetsledere må opprettholde en effektiv cybersikkerhetsstrategi for å hjelpe til med å filtrere noe av støyen på nye sårbarheter, gjenkjenne virkninger på forsyningskjeder og sikre sine eiendeler tilsvarende.

Supply Chain Attacks forsvinner ikke

På omtrent et års tid har vi lidd gjennom alvorlige sårbarheter i komponenter, inkludert log4j, Spring Frameworkog OpenSSL. Utnyttelse av eldre sårbarheter opphører heller aldri fra implementeringer som er feilkonfigurert eller som bruker kjente sårbare avhengigheter. I november 2022 fikk publikum vite om en angrepskampanje mot Federal Civilian Executive Branch (FCEB), som kan tilskrives en statsstøttet iransk trussel. Denne amerikanske føderale enheten kjørte VMware Horizon-infrastruktur som inneholdt Log4Shell-sårbarheten, som fungerte som den første angrepsvektoren. FCEB ble rammet av en kompleks angrepskjede som inkluderte sideveis bevegelse, kompromiss med legitimasjon, systemkompromiss, nettverksutholdenhet, endepunktsbeskyttelse og cryptojacking.

Organisasjoner kan spørre "hvorfor konsumere OSS i det hele tatt?" etter sikkerhetshendelser fra sårbare pakker som OpenSSL eller Log4j. Angrep i forsyningskjeden fortsetter å gå oppover fordi gjenbruk av komponenter gir "god forretningsfornuft" for partnere og leverandører. Vi konstruerer systemer ved å ombruke eksisterende kode i stedet for å bygge fra bunnen av. Dette for å redusere ingeniørarbeid, skalere operativt og levere raskt. Åpen kildekode-programvare (OSS) anses generelt som pålitelig i kraft av den offentlige granskingen den mottar. Imidlertid er programvare i stadig endring, og problemer oppstår gjennom kodefeil eller koblede avhengigheter. Nye problemer avdekkes også gjennom utvikling av test- og utnyttelsesteknikker.

Håndtere forsyningskjedens sårbarheter

Organisasjoner trenger passende verktøy og prosesser for å sikre moderne design. Tradisjonelle tilnærminger som sårbarhetshåndtering eller punkt-i-tidsvurderinger alene kan ikke henge med. Forskrifter kan fortsatt tillate disse tilnærmingene, som opprettholder skillet mellom "sikker" og "kompatibel." De fleste organisasjoner ønsker å oppnå et visst nivå av DevOps-modenhet. "Kontinuerlig" og "automatisert" er vanlige trekk ved DevOps-praksis. Sikkerhetsprosesser bør ikke være forskjellige. Sikkerhetsledere må opprettholde fokus gjennom bygge-, leverings- og kjøretidsfaser som en del av deres sikkerhetsstrategi:

• Kontinuerlig skann i CI/CD: Mål å sikre byggerørledninger (dvs. skift-venstre), men erkjenne at du ikke vil kunne skanne all kode og nestede kode. Suksess med shift-venstre-tilnærminger begrenses av skannereffektivitet, korrelasjon av skannerutdata, automatisering av utgivelsesbeslutninger og skannerfullføring innenfor utgivelsesvinduer. Verktøy skal bidra til å prioritere risiko for funn. Ikke alle funn er handlingsdyktige, og sårbarheter kan kanskje ikke utnyttes i arkitekturen din.

• Skann kontinuerlig under levering: Komponentkompromiss og miljøavvik skjer. Applikasjoner, infrastruktur og arbeidsbelastninger bør skannes mens de leveres i tilfelle noe ble kompromittert i den digitale forsyningskjeden når det hentes fra registre eller depoter og oppstartes.

• Kontinuerlig skann under kjøretid: Kjøretidssikkerhet er utgangspunktet for mange sikkerhetsprogrammer, og sikkerhetsovervåking underbygger de fleste cybersikkerhetstiltak. Du trenger imidlertid mekanismer som kan samle inn og korrelere telemetri i alle typer miljøer, inkludert sky-, container- og Kubernetes-miljøer. Innsikt samlet i løpet av kjøretiden bør føres tilbake til tidligere bygge- og leveringsstadier. Identitet og tjenesteinteraksjoner

• Prioriter sårbarheter som avsløres under kjøring: Alle organisasjoner sliter med å ha nok tid og ressurser til å skanne og fikse alt. Risikobasert prioritering er grunnleggende for sikkerhetsprogramarbeidet. Internetteksponering er bare én faktor. En annen er sårbarhetens alvorlighetsgrad, og organisasjoner fokuserer ofte på problemer med høy og kritisk alvorlighetsgrad siden de anses å ha størst innvirkning. Denne tilnærmingen kan fortsatt kaste bort sykluser av ingeniør- og sikkerhetsteam fordi de kan jakte på sårbarheter som aldri blir lastet under kjøretid og som ikke kan utnyttes. Bruk runtime-intelligens for å verifisere hvilke pakker som faktisk blir lastet inn i kjørende applikasjoner og infrastruktur for å vite den faktiske sikkerhetsrisikoen for organisasjonen din.

Vi har skapt produktspesifikk veiledning for å styre kunder gjennom den nylige OpenSSL-galskapen.

Den nyeste OpenSSL-sårbarheten og Log4Shell minner oss om behovet for cybersikkerhetsberedskap og effektiv sikkerhetsstrategi. Vi må huske at CVE-ID-er bare er de kjente problemene i offentlig programvare eller maskinvare. Mange sårbarheter blir ikke rapportert, spesielt svakheter i hjemmelaget kode eller miljømessige feilkonfigurasjoner. Din cybersikkerhetsstrategi må ta hensyn til distribuert og mangfoldig teknologi med moderne design. Du trenger et modernisert sårbarhetshåndteringsprogram som bruker kjøretidsinnsikt for å prioritere utbedringsarbeid for ingeniørteam. Du trenger også trusseldeteksjon og responsfunksjoner som korrelerer signaler på tvers av miljøer for å unngå overraskelser.

om forfatteren

Michael Isbitski, direktør for Cybersecurity Strategy i Sysdig, har forsket på og gitt råd om nettsikkerhet i over fem år. Han er kjent med skysikkerhet, containersikkerhet, Kubernetes-sikkerhet, API-sikkerhet, sikkerhetstesting, mobilsikkerhet, applikasjonsbeskyttelse og sikker kontinuerlig levering. Han har veiledet utallige organisasjoner globalt i deres sikkerhetsinitiativer og støttet deres virksomhet.

I forkant av sin forskning og rådgivningserfaring, lærte Mike mange harde leksjoner på frontlinjene av IT med over 20 års erfaring fra utøvere og lederskap fokusert på applikasjonssikkerhet, sårbarhetshåndtering, bedriftsarkitektur og systemutvikling.