Sikkerhedsindustrien mister kollektivt forstanden, når nye sårbarheder opdages i software. OpenSSL er ingen undtagelse, og to nye sårbarheder overvældede nyhedsfeeds i slutningen af oktober og begyndelsen af november 2022. Opdagelse og afsløring er kun begyndelsen på denne uendelige sårbarhedscyklus. Berørte organisationer står over for udbedring, hvilket er særligt smertefuldt for dem, der er i frontlinjen af IT. Sikkerhedsledere skal opretholde en effektiv cybersikkerhedsstrategi for at hjælpe med at filtrere noget af støjen på nye sårbarheder, genkende påvirkninger af forsyningskæder og sikre deres aktiver i overensstemmelse hermed.
Supply Chain-angreb forsvinder ikke
På omkring et års tid har vi lidt under alvorlige sårbarheder i komponenter, bl.a. log4j, Spring Frameworkog OpenSSL. Udnyttelse af ældre sårbarheder ophører heller aldrig fra implementeringer, der er fejlkonfigureret, eller som bruger kendte sårbare afhængigheder. I november 2022 fik offentligheden kendskab til en angrebskampagne mod Federal Civilian Executive Branch (FCEB), som kan tilskrives en statssponsoreret iransk trussel. Denne amerikanske føderale enhed kørte VMware Horizon-infrastruktur, der indeholdt Log4Shell-sårbarheden, som fungerede som den indledende angrebsvektor. FCEB blev ramt af en kompleks angrebskæde, der inkluderede lateral bevægelse, kompromis med legitimationsoplysninger, systemkompromis, netværksvedholdenhed, bypass af slutpunktsbeskyttelse og kryptojacking.
Organisationer kan spørge "hvorfor forbruge OSS overhovedet?" efter sikkerhedshændelser fra sårbare pakker som OpenSSL eller Log4j. Supply chain-angreb fortsætter med at stige, fordi genbrug af komponenter giver "god forretningsmæssig mening" for partnere og leverandører. Vi konstruerer systemer ved at genbruge eksisterende kode i stedet for at bygge fra bunden. Dette er for at reducere ingeniørarbejdet, skalere operationelt og levere hurtigt. Open source-software (OSS) anses generelt for at være troværdig i kraft af den offentlige kontrol, den modtager. Software er dog i konstant forandring, og problemer opstår gennem kodefejl eller forbundne afhængigheder. Nye problemer afdækkes også gennem udvikling af test- og udnyttelsesteknikker.
Håndtering af forsyningskædesårbarheder
Organisationer har brug for passende værktøj og processer for at sikre moderne design. Traditionelle tilgange som f.eks. sårbarhedshåndtering eller tidsmæssige vurderinger kan ikke følge med alene. Forskrifter kan stadig tillade disse tilgange, hvilket fastholder skellet mellem "sikker" og "kompatibel". De fleste organisationer stræber efter at opnå en vis grad af DevOps-modenhed. "Kontinuerlig" og "automatiseret" er almindelige træk ved DevOps-praksis. Sikkerhedsprocesser bør ikke adskille sig. Sikkerhedsledere skal bevare fokus gennem bygge-, leverings- og runtime-faser som en del af deres sikkerhedsstrategi:
- Scan kontinuerligt i CI/CD: Sigt efter at sikre byggepipelines (dvs. skift til venstre), men anerkend, at du ikke vil være i stand til at scanne al kode og indlejret kode. Succes med skift-venstre tilgange er begrænset af scannereffektivitet, korrelation af scanneroutput, automatisering af frigivelsesbeslutninger og scannerafslutning inden for frigivelsesvinduer. Værktøj skal hjælpe med at prioritere risiko for fund. Ikke alle resultater er handlingsrettede, og sårbarheder kan muligvis ikke udnyttes i din arkitektur.
- Scan kontinuerligt under levering: Komponentkompromis og miljøafvigelse sker. Applikationer, infrastruktur og arbejdsbelastninger skal scannes, mens de leveres, hvis noget blev kompromitteret i den digitale forsyningskæde, når det hentes fra registre eller lagre og bootstrappes.
- Scan kontinuerligt i runtime: Runtime-sikkerhed er udgangspunktet for mange sikkerhedsprogrammer, og sikkerhedsovervågning understøtter de fleste cybersikkerhedsbestræbelser. Du har brug for mekanismer, der kan indsamle og korrelere telemetri i alle typer miljøer, dog inklusive cloud-, container- og Kubernetes-miljøer. Indsigt indsamlet i løbet af runtime bør føres tilbage til tidligere bygge- og leveringsstadier. Identitet og serviceinteraktioner
- Prioriter sårbarheder afsløret i runtime: Alle organisationer kæmper med at have tid og ressourcer nok til at scanne og rette alt. Risikobaseret prioritering er grundlæggende for arbejdet med sikkerhedsprogrammer. Interneteksponering er kun én faktor. En anden er sårbarhedens sværhedsgrad, og organisationer fokuserer ofte på problemer med høj og kritisk sværhedsgrad, da de anses for at have størst indflydelse. Denne tilgang kan stadig spilde cyklusser af ingeniør- og sikkerhedsteams, fordi de måske jagter sårbarheder, der aldrig bliver indlæst under kørsel, og som ikke kan udnyttes. Brug runtime-intelligens til at verificere, hvilke pakker der rent faktisk bliver indlæst i kørende applikationer og infrastruktur for at kende den faktiske sikkerhedsrisiko for din organisation.
Vi har oprettet produktspecifik vejledning at styre kunderne gennem det seneste OpenSSL-vanvid.
Den seneste OpenSSL-sårbarhed og Log4Shell minder os om behovet for cybersikkerhedsberedskab og effektiv sikkerhedsstrategi. Vi skal huske, at CVE-ID'er kun er de kendte problemer i offentlig software eller hardware. Mange sårbarheder bliver ikke rapporteret, især svagheder i hjemmelavet kode eller miljømæssige fejlkonfigurationer. Din cybersikkerhedsstrategi skal tage højde for distribueret og forskelligartet teknologi af moderne design. Du har brug for et moderniseret sårbarhedsstyringsprogram, der bruger runtime-indsigt til at prioritere afhjælpningsarbejde for ingeniørteams. Du har også brug for trusselsdetektion og -responsfunktioner, der korrelerer signaler på tværs af miljøer for at undgå overraskelser.
Om forfatteren
.png?width=690&quality=80&format=webply&disable=upscale "Supply Chain Risici fik dig ned? Bevar roen og bliv strategisk!")
Michael Isbitski, direktør for Cybersecurity Strategy hos Sysdig, har forsket i og rådgivet om cybersikkerhed i over fem år. Han er fortrolig med cloud-sikkerhed, containersikkerhed, Kubernetes-sikkerhed, API-sikkerhed, sikkerhedstest, mobilsikkerhed, applikationsbeskyttelse og sikker kontinuerlig levering. Han har vejledt utallige organisationer globalt i deres sikkerhedsinitiativer og støttet deres forretning.
Forud for sin research- og rådgivningserfaring lærte Mike mange hårde lektioner på frontlinjen af IT med over 20 års praktiker- og ledererfaring med fokus på applikationssikkerhed, sårbarhedsstyring, virksomhedsarkitektur og systemudvikling.
