Afhængigheder af afhængigheder: Den kritiske udfordring ved at styre softwareforsyningskæderisiko
Indholdsfortegnelse:
Software styrer verden. Det holder fly på himlen, hospitaler kørende og sikrer, at det globale finansielle system aldrig går glip af et beat. Men i stigende grad bygges disse applikationer ved hjælp af open source-kodekomponenter fra forskellige forskellige kilder. Kompleksitet er den nye normal, uanset om det er proprietær software eller skræddersyede hjemmelavede apps. Og kompleksitet er sikkerhedens fjende.
De komplekse forhold mellem komponenter og den lethed, hvormed trusselsaktører kan indsætte malware i opstrømskode, bør være en årsag til bekymring for sikkerhedschefer. Wake-up calls er kommet tykt og hurtigt over de seneste år. Det er tid til at finde en effektiv måde styre softwareforsyningskæden risiko.
Sådan fungerer softwareforsyningskæden
Forsyningskæder er de kritiske veje, via hvilke råmaterialer og komponenter ledes, før de samles, sælges og bruges. I den digitale verden er sådanne komponenter ofte bedre opfattet som tjenester leveret fra leverandør til kunde. Som vi diskuteret i en tidligere artikel, er disse tjenesteudbydere et stadig mere populært mål for angreb, fordi trusselsaktører kan generere en god RoI. Angreb én outsourcer af forretningsprocesser eller IT-servicegigant, og de har mulighed for at stjæle data fra og/eller afpresse en potentielt stor pulje af downstream-kunder.
En softwareforsyningskæde ligner hinanden, men i dette tilfælde omfatter systemet de komponenter, kodebiblioteker, værktøjer og processer, der kræves for at bygge software. Ved at kompromittere en enkelt komponent, eller endda en hel applikation, kan angribere potentielt påvirke enhver udvikler eller organisation, der bruger den pågældende software/komponent.
Hvor er risikoen?
Software kører måske verden, men hvad går der præcist til at bygge de applikationer, der driver alt fra e-handelsplatforme til kritiske forretnings-ERP-systemer? I stigende grad er det open source-komponenter. EN Sonatype rapport anslår, at alene i 2022 lavede udviklere 3.1 billioner anmodninger om sådanne komponenter fra de fire bedste open source-økosystemer: Java, JavaScript, Python og .NET. Tegningen er, at ved at downloade disse forudbyggede pakker kan udviklere fremskynde time-to-market og hjælpe virksomheden med at reagere hurtigere på hurtigt skiftende markedsefterspørgsel. Det hævdes at 80 % af koden i moderne applikationer kommer fra allerede eksisterende open source-software.
Udfordringen er, at disse komponenter - eller open source "afhængigheder" - ofte indeholder sårbarheder. Ifølge Sonatype blev 1.2 milliarder sårbare afhængigheder downloadet hver måned sidste år. Hvis de uforvarende downloades, kan de medføre risiko for at blive udnyttet af trusselsaktører på et senere tidspunkt. Ifølge Linux Foundation, indeholder det gennemsnitlige applikationsudviklingsprojekt 49 sårbarheder på tværs af 80 direkte afhængigheder.
Endnu værre er indirekte eller transitive afhængigheder, som Sonatype hævder tegner sig for seks ud af hver syvende projektsårbarhed. Disse afhængigheder er sværere at spore, da de reelt er de biblioteker og pakker, som direkte afhængigheder kalder – med andre ord afhængigheders afhængigheder. Som et resultat er det ikke umiddelbart indlysende, at en bestemt applikation bruger dem. Det kan skjule sårbarheder under et ekstra lag af sløring.
Et eksempel på det er den berygtede Log4j sårbarheder. Log4j er et lidet kendt, men populært logningsværktøj, der bruges af over 35,000 Java-softwarepakker. En patch til en kritisk (CVSSS 10.0) sårbarhed i værktøjet blev frigivet i slutningen af december 2021. Men på grund af dens udbredte brug på tværs af Java open source-økosystemet, var det ekstremt vanskeligt for mange organisationer definitivt at finde og lappe alle forekomster af Log4j i deres miljø. Ifølge Google, var de mest påvirkede Java-pakker sårbare, fordi Log4j var en svær at finde transitiv afhængighed.
"Jo dybere sårbarheden er i en afhængighedskæde, jo flere trin kræves der for at blive rettet," tilføjede den.
Desværre spildte trusselsaktører ingen tid på at udnytte fejlen. Ifølge Tele Danmark Mobil, en tredjedel (32%) af scanningen for sårbarheden i udsatte systemer sidste år skete i løbet af de første 30 dage efter offentliggørelsen.
Ud over udfordringen med at finde og lappe sårbarheder i open source-komponenter, har organisationer den ekstra hovedpine af ondsindede pakker, der sendes til open source-lagre af trusselsaktører. Sonatype hævder at have registreret en 633% årlig stigning i sådanne pakker i 2022, til over 88,000 kendte tilfælde.
En anden trussel: Proprietær software
Risikoen for softwareforsyningskæden er dog ikke begrænset til open source. Proprietære kommercielle produkter kan indeholde sårbarheder, som angreb kan udnytte og regelmæssigt er. De kan også omfatte buggy open source komponenter og værktøjer, ligesom Log4j. Faktisk kan meget lidt kode, der eksisterer i dag, virkelig beskrives som "proprietær", ifølge Sonatypes direktør for udvikleradvokat, Steve Poole.
"Som et resultat har forbrugere af tilsyneladende proprietære applikationer en falsk følelse af sikkerhed, og kan derfor ubevidst være sårbare," siger han til ISMS.online.
I mere sofistikerede angreb, såsom SolarWinds-kampagnen, kan trusselsaktører endda kompromittere leverandørens eget it-miljø og indsætte malware i legitime softwareopdateringer. Dette gjorde det muligt for russiske statsagenter at kompromittere flere amerikanske regeringsdepartementer.
"Enhver form for software kan blive kompromitteret. Hovedproblemet er en uberettiget implicit tillid til den software,” argumenterer Udo Schneider, sikkerhedsevangelist Europe hos Trend Micro.
Samuel Barfoot, sikkerhedsteamleder hos Checkmarx, siger, at softwareleverandørens modenhed og ISO-akkreditering er afgørende.
"Selvom selve softwaren måske ikke er designet til at forårsage skade, hvis den infiltreres, kan den bruges til at lække information," siger han til ISMS.online. "Når de flytter til skyen, står organisationer også over for risici relateret til leverandørkontrol, support, backup og systemtilgængelighed i tilfælde af et hack eller udfald. Sælgerens modenhed er afgørende for at afbøde disse risici gennem beredskab og hensættelser."
Synlighed er det første skridt mod håndtering af risici
Uanset om de beskæftiger sig med proprietær eller open source-kode, skal organisationer, der ønsker at mindske risikoen i softwareforsyningskæden, først få indsigt i "dårlige" komponenter og underkomponenter, ifølge Trend Micros Schneider. Dette kan opnås ved at anmode om en softwarestykliste (SBOM).
"En SBOM for en softwareartefakt (bibliotek, eksekverbar eller endda container) indeholder en afhængighedsgraf, hvor alle anvendte software (under-)komponenter er angivet, inklusive et nøjagtigt versionsnummer. SBOM'er kan genereres direkte fra kilden inden for en CI/CD pipeline eller senere på 'døde' artefakter såsom eksekverbare filer eller endda containere,” forklarer han.
"Dette er især nyttigt for proprietær software, hvor leverandøren normalt ikke leverer SBOM'er. I jurisdiktioner/vertikaler, hvor leverandører skal levere en SBOM, kan de løbende kontrolleres mod kendte sårbarheder, hvilket giver et opdateret grundlag for mulig handling."
Sonatypes Poole tilføjer, at organisationer også bør vurdere leverandørens sikkerhedsposition, og være særlig opmærksom på kvaliteten af deres sårbarhedsrapporteringsprocesser.
For open source-komponenter bør organisationer køre et program med løbende evaluering af open source-komponenter, patching/opdatering omgående, hvor det er nødvendigt for at afværge hurtig udnyttelse, hævder han. Software Composition Analysis (SCA) værktøjer kan også hjælpe ved at opdage, hvad der er inde i produkter eller komponenter.
"Men det sofistikerede i SCA-værktøjet skal matche og overstige de dårlige aktørers, ellers står organisationen over for den reelle risiko for et angreb via en uopdaget vektor," advarer han.
"Til sidst, tag udviklere med i folden ved at uddanne dem i, hvordan moderne cyberangreb sker, og hvad sikre kodningsprincipper er, og lær dem om deres ansvar i begyndelsen af softwareforsyningskæden - deres umiddelbare valg og handlinger har konsekvenser."
Start med en ISMS
Trend Micros Schneider hævder, at en informationssikkerhedsstyringssystem (ISMS) kan være en fantastisk måde at mindske risikoen for softwareforsyningskæden på løbende.
"Ved at føre data fra SBOM-værktøjer, beriget med distributionsdata, ind i et ISMS, er det muligt at vurdere bedre og dokumentere sikkerhedsstillingen og dermed den samlede risiko for hele systemet, hvoraf software kun er en del," forklarer han. "Når det bruges som grundlag for at mindske risikoen og dokumentere de handlinger, der er truffet, giver dette i princippet langt bedre sikkerhed end manuel sporing af softwareaktiver."
En tjekliste til styring af softwareforsyningskæderisiko:
- Anmod om en SBOM
- Vurder proprietære softwareleverandører (især deres sårbarhedsrapportering)
- Brug SCA-værktøjer til at få indsigt i softwarekomponenter
- Scan kontinuerligt for sårbarheder og patch omgående
- Uddan udviklere om vigtigheden af design-sikkerhed
- Overvej at indføre SBOM-data i et ISMS til holistisk risikostyring
Find ud af, hvordan ISMS.online-løsningen muliggør en enkel, sikker og bæredygtig tilgang til forsyningskæderisikostyring og informationsstyring med ISO 27001 og over 100 andre globale rammer.
