Når nettene blir lange – del III
I dette kapittelet tar vi opp tråden fra Digital Sikkerhet 2020 og 2021, og ser nærmere på leveransekjederisiko i forhold til programvare, samt kontinuitetsrisiko i leveranser.
I DIGITAL SIKKERHET 2020 (15) tok vi i artikkelen Når nettene blir lange for første gang tak i leveransekjederisiko, og satte fokus på sikkerhet i leverandørgrensesnittet, kravstilling og hvordan skape insentiver og samhandling for sikkerhet i både leveranser, leverandørorganisasjonen og bakover i leveransekjeden. I Digital Sikkerhet 2021 (16) dykket vi ned i software supply chain risiko. Alle kunne selvsagt ønske seg at temaet sikkerhet i leveransekjeder nå var løst, men vi må konstatere at det fortsatt er høyaktuelt.
Vi ser i år nok en gang risiko relatert til leveransekjeder for programvare og hvordan SBOM bidrar til håndteringen, men ikke er nok. Vi retter også søkelys mot kontinuitetsrisiko i leveransekjeder, et forhold som også er belyst av henholdsvis Forsvars- og Totalberedskapskommisjonen.
Software supply chain
Til tross for et års opphold i temaet leveranse- og leverandørkjedeangrep i Digital sikkerhet, har disse indirekte angrepsvektorene slett ikke dalt i popularitet blant trusselaktørene.
Innenfor software supply chain angrep rapporterer flere kilder om til dels dramatisk økning; f.eks. rapporterer Sonatype i siste utgave av sin «State of the Software Supply Chain» om 633% økning over det siste året. Noe av forklaringen kan ligge i forholdet Veracode belyser i sin State of Software Security rapport, basert på sine observasjoner; «79% of the time, once a library is included, it never gets updated».
Utvalgte angrep fra perioden
Blant større angrep fra den siste perioden kan vi særlig legge merke til, og høste lærdom fra;
Okta
Identitets- og autorisasjonstjenesten Okta Inc. var i skuddlinjen for ikke mindre enn tre leveransekjede-angrep i 2022.
I januar ble en underleverandør av call center og kundebetjeningstjenester, Sitel, kompromittert av utpressingsgruppen Lapsu$, som demonstrerte sin tilgang ved å vise skjermbilder av Oktas interne systemer. Undersøkelser viste at kundedata tilhørende 366 virksomheter, ca 2,5 prosent av Oktas kunder, ble kompromittert. Inngangen var gjennom et tredje selskap, Sykes, som nylig var kjøpt opp av Sitel.
I august ble IP-telefoniselskapet Twilio kompromittert – en tjeneste Okta benyttet for utsending av engangskoder til sine kunder. Et «mindre antall» telefonnummer og engangskoder ble berørt. Disse to første hendelsene peker i retning av krav til, og verifikasjon av, sikkerhet hos leverandører. Det belyser også behovet for sikkerhetsgjennomgang som del av due dilligence ved oppkjøp.
Til sist, i desember, ble deler av Oktas kildekode eksponert for uvedkommende, ved at GitHub kontoen deres ble kompromittert. Om dette siste egentlig er et leveransekjedeangrep er ikke definitivt avklart – det er spekulert i at tilgangen var muliggjort gjennom en av de to foregående hendelsene. Oktas uttalelse om at «Okta does not rely on the confidentiality of its source code for the security of it services.» får vi håpe stemmer – det er slik det skal være. Likevel vil tilgang til kildekode ofte bidra til å lette arbeidet for de som leter etter utnyttbare sårbarheter.
Tyveri av API-nøkler og tilsvarende tokens, skyldes ofte mangelfull applikasjonssikkerhet eller svak håndtering av secrets i applikasjoner, utviklings-, bygg- og testmiljøer.
3CX
I mars ble det kjent at programvare fra IP-telefoniselskapet 3CX var kompromittert, og det er uklart over hvor lang tid, men de første rapportene om avvik hos brukerne – først antatt å være falske positivier – kom ut 22. mars 2023. 3CX sin legitime programvare, i bruk hos over 600.000 selskaper og mer enn 12 millioner daglige sluttbrukere, viste seg å ha fått tilskudd av ondsinnet kode for DLL sideloading. Litt forenklet forklart, er det instruksjoner i installasjonsrutinen, om å hente ekstra kode- bibliotek (DLL) fra en ekstern kilde. Det finnes igjen flere svært omfattende, lærerike og detaljerte tekniske analyser av både skadevaren og angriperens teknikker, som vi ikke skal gjengi her.
3CX-angrepet gir assosiasjoner til Solarwinds-angrepet, og strengt tatt helt tilbake til «APT 1» sine angrep mot managed service providers (MSP-er). Felles for APT1, Solarwinds og en portefølje av mellomliggende kampanjer, er evne og vilje til å bruke leveransekjedeangrep som rammer svært bredt, og dermed også nødvendigvis blir ganske synlige, for å i realiteten kun gå etter noen få utvalgte mål. Det er modus som – sammen med fraværet av økonomisk vinning – peker i retning av etterretningsmotiverte aktører.
Fra et leveransekjedeperspektiv merker vi oss at 3CX-angrepet faktisk var muliggjort gjennom et annet software supply chain angrep, på selskapet Trading Technologies og deres programvare for handel med verdipapirer (såkalte futures), XTrader. Flere analyseselskaper og medier omtaler dette som første gang ett programvare-leveransekjedeangrep har ført til et annet. Den infiserte versjonen av XTrader ble ganske enkelt lastet ned og installert av en ansatt hos 3CX. Det er bred konsensus blant analyseselskaper når XTrader kampanjen og det påfølgende angrepet gjennom 3CX-programvare knyttes til Nord-Koreanske Lazarus Group. XTrader kampanjen rammet flere andre selskaper, inkludert minst to strømselskaper i hhv. USA og Europa. Den bredt anlagte sekundære kampanjen gjennom 3CX, mål i energisektoren og kompromittering av programvare for verdipapirhandel, åpner for spørsmål om angripers motivasjon primært er økonomisk eller geopolitisk. Selv med sterk attribusjon kan det være vanskelig å konkludere, da Lazarus Group operer ut fra begge motiver.
GitHub
I april ble GitHub rammet av en type angrep som har fått betydelig oppsving de siste par årene; tyveri av forskjellige former for «tokens» for autentisering og tilgang. Det kan dreie seg om informasjon i cookies og aksess tokens med begrenset levetid, eller mer langlivede nøkler og sesjons-IDer. I den aktuelle saken lyktes angriper i å tilegne seg OAuth tokens – en form for identifiserende token som benyttes for å kunne gi tilgang over et konfigurerbart tidsrom uten å kreve re-autentisering – utstedt til tredjeparts-integratorene Heroku og TravisCI. Med de stjålne OAuth-tokenene fikk angriperne så tilgang til organisasjoner som bruker Heroku Dashboard og TravisCI produktene.
GitHubs undersøkelser avdekket at angriperne systematisk søkte i nedlastet innhold de fikk tak i, etter ytterligere nøkler og tokens som kunne gi enda flere tilganger. Slik fikk angriperne blant annet tak i en AWS API-nøkkel, som igjen ga dem tilgang til GitHubs Node Package Manager (npm) produksjonsmiljø, men heldigvis uten at de kunne endre på npm-pakker – kun laste ned kode.
Det er flere momenter å legge merke til her. Tyveri av API-nøkler og tilsvarende tokens, skyldes ofte mangelfull applikasjons- sikkerhet eller svak håndtering av «secrets» (tokens, nøkler, m.v.) i applikasjoner, utviklings-, bygg- og testmiljøer. Et annet punkt som gjerne er oversett – både i profesjonell applikasjonsutvikling og – bruk, så vel som når vi som enkeltpersoner autoriserer tredjepartstjenester og apper for tilgang til våre konti på f.eks. sosiale medier – er opprydning og fjerning av gamle tillatelser som ikke lengre er i bruk. Det er rimelig å anta at enkelte virksomheter der Heroku og TravisCI verktøyene var autorisert for tilgang, ikke lenger brukte disse produktene aktivt.
Håndtering og tiltak har også vært gode fra alle involverte parter. GitHub har – uavhengig av hendelsen – utviklet en tjeneste som skanner kode for secrets før den lastes opp til distribusjons- kanaler. I et leveransekjede-perspektiv er det imidlertid grunn til å fremheve varsling og handling. GitHub var tidlig ute med å varsle alle berørte brukere, og både Heroku og TravisCI varslet sine kunder samt iverksatte revokering og ny-utstedelse av tokens og nøkler for sine tjenester. Det sistnevnte er ingen enkel beslutning, da det påvirker tjenestene og kundene, men likevel den rette for å minimere skade og sikkerhetsrisiko.
Fishpig
Du har kanskje ikke hørt om Fishpig før, men denne programvaren for integrasjon mellom den ekstremt populære publiseringsplattformen Wordpress og den svært utbredte netthandelsprogramvaren Magento, er i bruk i over 200.000 nettbutikker. Angriperne kompromitterte Fishpig sine distribusjonsservere, dvs. serverne som kundene henter programvare og oppdateringer fra. De lastet opp modifiserte versjoner av programvaren som infiserte kundenes systemer med Rekoob trojaneren – som gir angriperne en bakdør inn i kundenes systemer. Skadepotensialet er betydelig, da dette er nettbutikker med betalingsfunksjoner, og Magento-baserte nettbutikker har vært et yndet mål for økonomisk motiverte trusselaktører i en årrekke – til dels med store tap.
Det kan være grunn til å stille spørsmål ved sikkerhetsovervåkningen hos Fishpig, da angriperne var inne i om lag 12 uker før det pågående leveransekjedeangrepet ble avdekket (og ikke det faktum at angripere var inne i Fishpig sine systemer). For de teknisk interesserte, finnes flere gode analyser av de mange inkarnasjonene av Linux-trojaneren Rekoob siden den ble observert i sin første versjon i 2015, samt de forskjellige root- kitene og teknikkene som er i bruk for å deployere og skjule den.
Fra et leveransekjedeperspektiv er denne type angrep utfordrende å håndtere for kundene, da angriperne lyktes i å få sin kode inkludert i tilsynelatende autentisk programvare. Mekanismer for automatisk oppdatering – som generelt er å anbefale fra et sikkerhetsståsted – begrenser også i noen grad mulighetene til tiltak som f.eks. kjøring i sikkerhetsinstrumenterte test- og sandkassemiljøer før installasjon i produksjon; tiltak som også vil være for ressurskrevende for mange av de aktuelle kundene. Rekoob er på den annen side en kjent skadevarefamilie, og Endpoint Detection and Response (EDR) verktøy på Linux- serverne vil kunne ha effekt. Det er også viktig å abonnere på, og respondere på, varsler fra sine leverandører. Etter hendelsen har Fishpig utgitt forbilledlig veiledning til berørte kunder – endog verktøy som lar kunder med begrenset kompetanse rydde opp i en kompromittert nettbutikk.
Recursive dependencies – en vedvarende utfordring
Vi ser også at organiseringen av økosystemene av åpen kildekode byr på sikkerhetsmessige utfordringer og mulighetsrom for angripere, blant annet gjennom måten utvikling forholder seg til avhengigheter (dependencies), det vil si kode eller en programvaremodul som en annen kode er avhengig av, og derfor henter inn og inkluderer. Slike dependencies kan i noen økosystemer, som f.eks. npm, være gjentakende i mange lag nedover.
Flere angrepstilnærminger drar nytte av dette, og andre forhold rundt måten utvikling og distribusjon av åpen kildekode er organisert:
Ondsinnede avhengigheter – Event stream hendelsen (17), 2018
I august 2018 publiserte utvikleren «Antonio Macias» parser-biblioteket flatmap stream på npm, og kontaktet ansvarlig utvikler av det mye brukte parser-biblioteket event stream med forslag om å inkludere førstnevnte som en avhengighet (dependency) til sistnevnte. I september slippes neste versjon av event-stream, der flatmap stream koden er inkludert. I oktober oppdateres kodebasen til flatmap stream med ondsinnet kode. Fra dette tidspunktet inneholder også all ny henting av event stream automatisk denne koden.
Event-stream er en populær pakke, og er selv en dependency i minst 3.931 andre pakker. Det reelle målet for angrepet er imidlertid kun ett; den svært populære bitcoin-lommeboken Copay. Koden som ble introdusert i flatmap stream er kun virksom som del av Copay, der den muliggjør tyveri av bitcoins og private nøkler.
Dependency Confusion – Alex Birsan, 2021
Vi omtalte i Digital Sikkerhet 2021, hvordan sikkerhetsforsker Alex Birsan tidlig dette året demonstrerte «dependency confusion» angrep (18):
«En ytterligere faktor, som bidrar til å redusere tid og kost, er dynamisk bruk av tredjeparts-biblioteker som Node, JQuery og Chartbeat. Med dynamisk menes at bibliotekene enten lastes ned når applikasjonen bygges eller når den kjører i en nettleser. På den ene siden medvirker ofte slike biblioteker til sikrere kode, ettersom de ofte hjelper programmerere å «gjøre ting riktig», mens de på den andre siden øker risikoen for å bli kompromittert gjennom leverandørkjeden. Dette ble behørig demonstrert i februar da en sikkerhetsforsker beskrev hvordan han hadde utnyttet denne typen dynamisk nedlastning ved å publisere pakker med konseptuell «skadevare» til forskjellige offentlige rammeverk (npm, RubyGems og PyPI) med samme, eller nesten samme, navn som det flere større teknologiselskaper selv benyttet på sine interne moduler.»
Konsekvensen ble at automatiske byggverktøy hos de aktuelle virksomhetene, lastet inn Birsan’s offentlig publiserte programvarekomponenter med samme navn, i stedet for komponenter fra selskapets private kodebase.
Npm Manifest Confusion attack (19), 2022
Npm pakker har en såkalt «manifest-fil», som inneholder metadata om kodepakken og lister avhengigheter til andre pakker. Den tidligere GitHub-ansatte Darcy Clarke har avdekket at det ikke finnes noen mekanismer som sammenligner den publiserte manifest-filen med den som er inkludert i den tar-komprimerte nedlastbare kodepakken. Mange sikkerhetsverktøy, så vel som menneskelig inspeksjon, vil legge informasjonen i den frittstående manifest-filen til grunn, mens det er den inkluderte som faktisk styrer byggprosessen og hvilke dependencies som faktisk trekkes inn. Dette gir mulighet for at en utgiver eller angriper kan inkludere ondsinnet eller kjent sårbar kode i den inkluderte manifest-filen, mens den frittstående publiserte manifest-filen ikke trenger nevne det.
Repojacking, 2023
Sikkerhetsselskapet Aqua Security publiserte sommeren 2023 informasjon (20) fra en studie av 1,25 millioner kodeprosjekter på GitHub, der de fant at nær 37.000 av dem var sårbare for såkalt repojacking. Teknikken er enkel, og går ut på at trusselaktører registrerer kodeprosjekter med prosjekt- eller brukernavn som ikke lengre er i bruk. Det kan skyldes at brukerkontoen er kansellert, eller at prosjektet bytter navn – uten at alle andre prosjekter som forsøker å hente inn prosjektets kode blir tilsvarende oppdatert. Dette gir mulighet for trusselaktører, som ved å registrere det gamle navnet får mulighet til å publisere kode som andre automatisk henter inn og bruker i sine prosjekter. Aqua Security har bare scannet et lite utvalg, og uttaler at det den reelle angrepsflaten sannsynlig er flere millioner kodeprosjekter – ikke bare de nær 37.000 identifiserte.
Hva sier norske myndigheter?
Norske myndigheter, gjennom rapporter fra PST, NSM og Etterretningstjenesten, har omtalt forskjellige former for trusler og angrep gjennom leveransekjeder. Vi merker oss særlig nedenstående.
PST: Nasjonal trusselvurdering 2023
«I januar 2022 ble Litauen utsatt for en omfattende og sammen- satt reaksjon fra kinesiske myndigheter da landet lot Taiwan få åpne et representasjonskontor i Vilnius. Litauen ble etter hendelsen utsatt for en påvirkningskampanje og flere digitale nettverksoperasjoner. I tillegg ble landet utsatt for omfattende leverandørkjedepress, tjenestestans og andre formelle og uformelle sanksjoner. Samtidig hadde selskaper i Litauen problemer med å få tak i kinesiske deler og komponenter. Kinesiske myndigheter la også press på virksomheter i andre europeiske land for å få dem til å begrense sin handel med selskaper fra Litauen.»
«Det siste året har PST sett at flere statlige etterretningstjenester, eller trusselaktører som opererer på vegne av disse, har gjennomført såkalte verdikjedeangrep. Dette er nettverks- operasjoner rettet mot svake og mer perifere punkt i en virksomhets verdikjede, for eksempel hos underleverandører. Virksomheter med solide datasikkerhetssystemer og -rutiner er sårbare dersom deres underleverandører ikke har tilsvarende sikringstiltak. PST forventer flere nettverksoperasjoner av denne typen i 2023.»
«Statlige aktører benytter et bredt spekter av metoder for å omgå kontrollmekanismer og sikre seg tilgang til teknologi og kunnskap fra norske virksomheter. [...] Virkemidler som falsk dokumentasjon, kompliserte selskapsstrukturer, strå- og frontselskaper og leverandørkjeder vil også benyttes.»
Etterretningstjenesten: Fokus 2023
«Samhandling skaper også sårbarhet. Avhengigheter i forsyningskjeder blottstilles og åpner for utpressing.»
NSM: Risiko 2023
«Selv om en virksomhet har god fysisk og digital sikkerhet, så kan trusselaktører utnytte underleverandører som er langt dårligere sikret for å få tilgang til sine egentlige mål. Dette gjør at vi også må sikre oss godt på flankene.»
«Sikkerheten vår blir ikke bedre enn det svakeste leddet i leverandørkjeden.»
«Lange og uoversiktlige leverandørkjeder utgjør fortsatt en sårbarhet som trusselaktører vet å utnytte. De siste årene har vi sett mange eksempler på at leverandørkjedeangrep mot leverandører av IKT-tjenester med svært store kundebaser får omfattende konsekvenser utenfor det digitale rom ser vi også at trusselaktører utnytter leverandørkjeder for å oppnå tilgang til sine egentlige mål. Når målet er å ramme en stor virksomhet krever det mindre ressurser å angripe en mindre sikker underleverandør eller enkeltpersoner.»
NSM: Sikkerhetsfaglig råd
«Trusselaktører utnytter at funksjoner og infrastruktur i stat og samfunn henger sammen i uoversiktlige verdikjeder. Hendelser som tilsynelatende er rettet mot verdier ett sted i en verdikjede, kan i realiteten være konstruert for å ramme et egentlig mål et annet sted i verdikjeden.»
«Mangelfull oversikt over leverandørkjeder og fravær av sikkerhetskrav til leverandører i anskaffelser og prosjekter åpner muligheten for at trusselaktører bruker anskaffelsesprosesser som virkemiddel for å få tilgang til verdier. Trusselaktører kan dermed ramme virksomheten gjennom leverandører og underleverandører.»
Flere amerikanske etater og byråer har gjort seg bemerket i fremsnakking av behovet for transparens i programvareleveranser og leveransekjede, gjennom bl.a. bruk av SBOM.
Software Bill of Materials (SBOM) er en spesifikasjon av alle komponenter i en programvarepakke. Dette er nå et begrep på alles lepper, men veien hit har vært lang – og det er fortsatt en vei igjen å gå.
SBOM milepæler
Blant milepæler så langt, kan det være grunn til å fremheve:
Oktober 2015: SWID Tags standarden fra NIST publisert som ISO/IEC 19770-2:2015.
Mars 2018: Versjon 1.0 av CycloneDX, en SBOM-standard fra OWASP.
Desember 2020: ISO publiserer «The ISO International Standard for open source license compliance» (ISO/IEC 5230:2020 – Information technology — OpenChain Specification), med krav om en prosess for håndtering av SBOM for levert programvare.
2020/2021: Amerikanske National Telecommunications and Information Administration (NTIA) publiserer betydelig arbeid fra sitt Software Component Transparency initiativ relater til SBOM.
Februar 2021: President Biden signerer Executive Order 14017 on America’s Supply Chain, med krav om SBOM ved føderale anskaffelser.
Mai 2021: President Biden signerer Executive Order 14028 on Improving the Nation’s Cybersecurity med krav om blant annet sikkerhetstesting og sårbarhetshåndtering, og SBOMs rolle i det.
Juli 2021: NIST publiserer sine Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028.
August 2021: Det åpne SBOM-rammeverket SPDX, fra Linux Foundation, blir publisert som standarden ISO/IEC 5962:2021.
April 2023: Versjon 1.0 av SLSA (Supply-Chain Levels for Software Artifacts) rammeverket publiseres av Open Source Security Foundation.
Til tross for at flere bidrag har fått forankring gjennom de inter- nasjonale standardorganisasjonene ISO og IEC, preges denne listen av amerikanske innslag, noe det primært er to grunner til; for det første er teknologibransjen og dens aktører – både på ideell og kommersiell side – i stor grad USA-basert. For det andre er det mye markedsmessig «kjøttvekt» i det når føderal sektor i USA begynner å stille krav til alle sine teknologileverandører, som fører til at effektuering og operasjonalisering av bl.a. EO 14017 og 14028 – gjennom en rekke direktiver og sertifiseringer som vi ikke redegjør for i detalj her – har global effekt ved å tvinge aktuelle leverandører til samsvar. Blant annet i forhold til å sikre sine programvare-utviklingsmiljøer, ha oversikt over sine programvare- leveransekjeder, og kunne dokumentere sine programvareleveranser gjennom SBOM.
Et utvalg aktuelle spesifikasjoner og rammeverk
CSAF: Common Security Advisory Framework (23) (CSAF) er en spesifikasjon fra OASIS for utveksling av strukturerte maskinlesbare sikkerhetsvarsler («Security Advisories»). Overgangen til omforente maskinlesbare strukturer for security advisories, fremfor prosatekst som må utformes og konsumeres av mennesker, er avgjørende for automatisering – både ved generering, men spesielt i forhold til mottak, behandling og videre anvendelse av informasjonen i håndtering av sårbarheter.
VEX: Vulnerability Exploitability eXchange (VEX) er et strukturert format for sårbarhetsinformasjon, mer spesifikt fokusert på å kommunisere hvorvidt en programvare er sårbar for en bestemt sårbarhet, og anbefalinger til håndtering. VEX er en informasjonsprofil i CSAF, men VEX-meldinger kan også være del av andre spesifiserte informasjonsstrukturer, f.eks. CycloneDX.
CycloneDX: OWASP CycloneDX (24) er en omfattende Bill of Materials (BOM) standard som ikke bare spesifiserer en struktur for Software Bill of Materials (SBOM), men også:
Software-as-a-Service Bill of Materials (SaaSBOM),
Hardware Bill of Materials (HBOM),
Operations Bill of Materials (OBOM), og
Vulnerability Disclosure Reports (VDR).
CycloneDX har også en profil for Vulnerability Exploitability eXchange (VEX)
SPDX: Software Packaged Data Exchange (25) er et en åpen standard for SBOM-format; støttet av et konsortium av aktører fra teknologiindustrien. Den er nå også formelt standardisert som ISO/IEC 5962:2021.
SWID: Software Identification (SWID) Tags er et format for å beskrive et software-objekt, og springer ut av software asset inventory og -management tilbake til 2012, da det først ble spesifisert som en ISO-standard. Siste gjeldende formelle standard er ISO/IEC 19770-2:2015. Formatet er del av spesifikasjonene til bl.a. Trusted Computing Group (TCG) og Internet Engineering Task Force (IETF). En SWID tag kan også være del av en CycloneDX SBOM.
SLSA: Supply-chain Levels for Software Artifacts (26) er et sikkerhetsrammeverk for programvaretilvirkning- og distribusjon. Rammeverket omfatter retningslinjer, sjekklister og controller for å motvirke illegitim påvirkning av primært programvarens integritet, i alle ledd fra produksjon til anvendelse. Der SBOM kan sammenlignes med ingredienslisten på matvarer, kan SLSA sammenlignes med retningslinjer for trygg tilvirkning, distribusjon og oppbevaring av næringsmidler.
Vi sier «tilvirkning», og ikke utvikling, da SLSA ikke dekker sikkerhetskvalitet i koden som skrives, men fokuserer på hva som skjer deretter. Rammeverket er til nytte både for produsenter og konsumenter – gjennom å hhv. veilede i og måle god sikkerhetspraksis.
En tydeligere plass i faglige råd
Flere amerikanske etater og byråer har gjort seg bemerket i fremsnakking av behovet for transparens i programvareleveranser og leveransekjede, gjennom bl.a. bruk av SBOM. Det finnes omfattende introduksjons- og opplæringsmateriale hos blant annet National Telecommunications and Information Administration (NTIA) (21) og ikke minst det svært produktive Cybersecurity and Infrastructure Security Agency (CISA) (22), der sistnevnte blant annet uttaler:
«A software bill of materials» (SBOM) has emerged as a key building block in software security and software supply chain risk management. A SBOM is a nested inventory, a list of ingredients that make up software components. The SBOM work has advanced since 2018 as a collaborative community effort, driven by National Telecommunications and Information Administration’s (NTIA) multistakeholder process.
CISA will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases. This website will also be a nexus for the broader set of SBOM resources across the digital ecosystem and around the world.
An SBOM-related concept is the Vulnerability Exploitability eXchange (VEX). A VEX document is an attestation, a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities.»
Også i Europa har SBOM fått økt oppmerksomhet fra myndighets- siden, blant annet fra ENISA, som i sin «Threat Landscape 2022» uttaler:
«It is almost-certain that adversaries will further abuse this lack of visibility into dependencies, as well as the increased complexity and the trust organisations put into their suppliers, to gain a foot- hold within organisations. We need to highlight initiatives such as the Software Bill of Materials (SBOM) that aim at making such things more transparent and auditable. An SBOM-related concept is the Vulnerability Exploitability eXchange (VEX). A VEX document is an attestation, a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities.»
Også i Europa har SBOM fått økt oppmerksomhet fra myndighets- siden, blant annet fra ENISA, som i sin «Threat Landscape 2022» uttaler:
«It is almost certain that adversaries will further abuse this lack of visibility into dependencies, as well as the increased complexity and the trust organisations put into their suppliers, to gain a foot- hold within organisations. We need to highlight initiatives such as the Software Bill of Materials (SBOM) that aim at making such things more transparent and auditable. Gaining visibility into the web of third-party relationships and dependencies is a must.»
ENISA understreker tilsvarende i «Good Practices for Supply Chain Cybersecurity» (vår utheving), og knytter det – i likhet med CISA – til sårbarhetshåndtering:
«The handling of vulnerabilities has two aspects; one aspect is the monitoring of vulnerabilities which leads to an analysis on the vulnerabilities identified up to a patch delivered and deployed. The other aspect is the publishing of advisories, i.e. the vulnerability notifications. A vulnerability notification has the objective to warn product users of critical vulnerabilities and might recommend alternative mitigation measures to minimise the likelihood of an exposure. Tools that support the operators as well as the developers towards this direction are the software bill of materials and Vulnerability Exploitability eXchange concepts, and the Common Security Advisory Framework.»
Fortsatt skepsis – Høna og egget
Samtidig som SBOM, sammen med VEX og CSAF, framsnakkes av både sikkerhetsfolk generelt og premissgivende myndigheter spesielt, finner man fortsatt også en del skepsis. Mange kritikere stiller seg tvilende til verdien av SBOM, all den tid mange av mottakerne ikke har prosesser og verktøy på plass for å nyttiggjøre seg informasjonen. Den strukturerte informasjonen må mottas og integreres i virksomhetens prosesser og systemer, blant annet for asset inventory og sårbarhetshåndtering, for å kunne gi reell verdi. Overføring og prosessering må også ha en verktøystøtte som tilrettelegger for høy grad av automasjon, da informasjonen er dynamisk og oppdateres hyppig. Det er legitimt å stille spørsmål til verdien av å kreve SBOM for all levert programvare, all den tid svært mange virksomheter har store utfordringer med grunnleggende prosessere og verktøy for å vite hva de har (inventory) og håndtere sårbarheter og sårbarhetsinformasjon (vulnerability management). Også sårbarhetsinformasjon må produseres, distribueres og konsumeres på maskinlesbare formater som muliggjør automasjon.
Dette er til dels en klassisk «høna og egget» problemstilling; ingen investerer i verktøy for å håndtere informasjon som ikke finnes; og få ser behov for å stille krav om – eller tilby – informasjon som få har kapasiteter til å nyttiggjøre seg. De aller fleste er imidlertid enige om at kontroll på hva du har og hvilke sårbarheter det inneholder, er en forutsetning for tilstrekkelig digital sikkerhet. Ett sted må man da begynne, og som for høna og egget, finnes det faktisk et svar (27). Også hos programvareprodusentene må det verktøy på plass for å kunne generere SBOM og VEX data på en ressurs- effektiv og agil måte – og også denne verktøystøtten kan ta tid å innføre. Det er derfor ingen grunn til å vente med å stille krav – og imøtekomme dem. Uten krav skjer det ingenting, og vi må vente lenge på både høns og egg. Det må først finnes informasjon å behandle – selv om verktøyene og prosessene for å behandle den optimalt og få maksimal verdi av den ennå mangler i mange virksomheter, og tilsvarende gjenstår å innføre hos mange programvareprodusenter. Vi har ikke råd til å bli stående i status quo. Selv om parallellen til utrulling av hydrogen som drivstoff er lett å se – der få vil bygge fyllestasjoner når det er få kunder, og få vil kjøpe hydrogenbiler når det er få fyllestasjoner – er dagens situasjon i håndtering av programvare og programvaresikkerhet mye mer prekær. Dagens praksis virker ikke, og skalerer ikke. Overgangen til høy automasjonsgrad i utveksling og bruk av informasjon, bør heller sammenlignes med å gå fra hest og kjerre til motordrevne kjøretøy.
Sikring av autentisitet i åpen kildekode – flere initiativer på trappene
Selv om signering av kode og publisering av sjekksummer som kan kontrolleres ved nedlasting er langt fra nytt, har helhetlige og enhetlige løsninger for skalerbar signering og sporbar autentisitet for åpen kildekode vært mangelvare. Dette har ført til at mye bruk av åpen kildekode komponenter i programvareprosjekter enten skjer gjennom tillit på mangelfullt grunnlag, eller avhenger av retrospektiv kontroll ved bruk av tredjepartsverktøy som leter etter «known bad». Signering og sporbar autentisitet for open source komponenter, biblioteker, avbildninger med videre, har derfor fått økende oppmerksomhet. Ett slikt rammeverk er Sigstore (28), med Google, Redhat, Linux Foundation, Chainguard og Purdue University i ryggen.
En annen tilnærming for å komme i forkant, fremfor å lete etter og avdekke ondsinnet påvirkning i etterkant, er tredjeparter
som gjør sikkerhetsverifikasjon av populær åpen kildekode og re-publiserer den i egne distribusjonskanaler. En slik tjeneste som har fått mye oppmerksomhet siden lanseringen i 2022 er Google Assured Open Source Software. Mens Sigstore ivaretar verifiserbar og sporbar opprinnelse og autentisitet, går Google Assured Open Source Software betydelig lengre, med blant annet;
build-prosess og dokumentasjon iht. SLSA-2,
omfattende SBOM for hver pakke, med supplerende informasjon som f.eks. sårbarhetsinformasjon, i SPDX og VEX formatene
fuzzing og sårbarhetstesting
distribusjon fra infrastruktur driftet og sikret av Google.
Kontinuitets- og tilgjengelighetsrisiko i leveransekjedene
Flere hendelser har – til dels sammenfallende – gitt store utfordringer i leveransekontinuitet de siste par årene, og vist en annen type leveransekjederisiko; risikoen for kontinuitets- og tilgjengelighetsbrudd i leveransene. Både samfunnspåvirkningen fra Covid19-pandemien, ett skip fast i Suez-kanalen (30), økt geopolitisk spenning med konflikt på flere arenaer, inkludert handel, og krigsutbrudd i Europa, har hvert på sitt vis bidratt til å påvirke leveransekontinuitet – og synliggjort hvor avhengige og sårbare vi har blitt.
Jakten på effektivitet
Siden opprinnelsen i Japan på 50- og 60-tallet, har just-in-time produksjon bredt om seg som den rette skole for ressurs- og kapitaloptimalisert produksjon. Konseptet, og den nødvendige just-in-time logistikken penetrerer nedover i hele verdikjeden, og har i løpet av 70- til 90-tallet nådd global utbredelse på tvers av bransjer. Kort sagt; ingenting produseres eller leveres til neste ledd i leveransekjeden før det foreligger, eller er bestilt eller prognostisert å foreligge, et konkret behov. Det er få eller ingen buffere; alle prosesser er optimalisert, og lagerhold er ansett å være «waste» (jf. Lean / Kaizen).
Dette gir et stort koordineringsbehov, stor sårbarhet for følge- konsekvenser ved forstyrrelser i ett ledd i leveransekjeden, og ingen av delene blir noe bedre når leverandørleddene blir mer spesialiserte, leverandørene derfor flere, og leveransekjedene stadig dypere og bredere. Det har drevet frem en helt annen dimensjon av risiko i leveransekjeder; leveransekontinuitetsrisiko. Om vi skal definere dette som del av sikkerhetsrisiko kunne sikkert ansporet mang en interessant fag- og semantikkdiskusjon, men det er uansett en risikodimensjon som siden forrige gang vi adresserte leverandør- og leveransekjeder i Digital Sikkerhet, både har manifestert seg og fått økt oppmerksomhet. I kontekst av en stadig tilspisset geopolitisk situasjon, er også kontroll på leveranse av kritiske varer og innsatsfaktorer blitt et «våpen».
Leveransekjeden – del av kontinuitet og resiliens
I Digital Sikkerhet 2022 (31) tok vi, i stor grad basert på erfaringene med forstyrrelser i leveransekjedene og akutte behov som oppstod i Ukraina i ukene og månedene etter invasjonen, til orde for at vi i Norge bør vurdere å opprette buffer-lagre av standard IKT-komponenter. Dette er imidlertid kun ett forslag innenfor – grovt sett – én bransje, og har til dels adresse til norske myndigheter ut fra en refleksjon om at dette er en form for grunnleggende nasjonal ressurs.
For virksomheter generelt, også aktører i kritiske sektorer med grunnleggende nasjonale funksjoner, må imidlertid vurdering av leveransekontinuitetsrisiko, og tiltak for å håndtere den, inngå i den enkelte virksomhets planer for kontinuitet og resiliens.
Dette åpner en Pandoras eske av informasjonsbehov:
Har vi oversikt over våre kritiske innsatsfaktorer og vet vi hvem de kritiske leverandørene er?
Har vi tatt høyde for at også bortfall av innsatsfaktorer som i sin natur fremstår mindre kritiske, likevel kan påføre virksomheten kontinuitetsavbrudd ved bortfall?
Vet vi hvem de kritiske underleverandørene til leverandørene er, og hvor langt ned i kjeden klarer vi å skaffe oss oversikt?
Det motiverer også nytenkning i forhold til potensielle former for tiltak:
Gitt påregnelige scenarier i en uforutsigbar verden med tilspisset geopolitikk, kan det være riktig å binde mer kapital i lagerhold av kritiske komponenter?
Kan vi samarbeide med noen om det? Kanskje til og med konkurrentene? Kan bransjeorganisasjoner spille en rolle i koordinering av felles tiltak?
Klarer vi å få til slikt samarbeid mellom konkurrenter uten å gå på kompromiss med konkurranse- og kartellregler?
Bør vi diversifisere leveransekjeden og spre leveranse- kontinuitetsrisikoen ved å etablere flere alternative leverandører for samme kritiske innsatsfaktorer?
Vet vi da at de to primære leverandørene ikke har de samme kritiske innsatsfaktorene / underleverandørene?
Står den økte sikkerhetsrisikoen som følger av en bredere leveransekjede, der flere leverandører kommer i posisjon som utgangspunkt for leveransekjedeangrep mot oss, i forhold til den reduserte leveransekontinuitetsrisikoen?
Fra Telenor Digital Sikkerhet 2022:
Det bør vurderes om det skal opprettes nasjonale beredskapslagre for standard / «Commercial Off-the- Shelf» IKT-komponenter. Prioriterte produktkategorier og produkter vil trenge en nærmere analyse, men både grunnleggende nettverksutstyr, servere og sluttbruker- utstyr vil være relevant. Beredskapslagrene kan fungere som nasjonal buffer, med kontinuerlig gjennomstrømning. Ordningen må være forpliktende for «medlems-virksomhetene» for å sikre at produktkategoriene ikke holdes på lager i lang tid og blir utdatert. Virksomhetene vi snakker om her er primært offentlige og private eiere av kritisk infrastruktur som understøtter sentrale samfunnsfunksjoner.
Belyst av kommisjonene
Både Forsvarskommisjonen og Totalberedskapskommisjonen legger i sine vurderinger, både generelt og innenfor spesifikke sektorer, stor vekt på beredskap og resiliens. Sårbarheten lange og uoversiktlige leveransekjeder gir i så måte, blir grundig drøftet, med tydelige konklusjoner om behov for styrking og tiltak – primært initiert av, men slett ikke kun i regi av, myndighetsapparatet. Det er også slik at mange kritiske komponenter produseres av svært få geografisk konsentrerte aktører, eller avhengig av innsatsfaktorer (mineraler, m.m.) hvor aktive kilder er geografisk konsentrert. Også sårbarheten som følger av supereffektive just-in-time verdikjeder blir belyst. Blant kommisjonenes tiltak finner vi styrket evne til selvforsyning, buffere og beredskapslagre, leverandørdiversitet for å ha flere ben, og stramme retningslinjer ift. hvilke opprinnelsesland vi skal tørre å eksponere oss mot eller gjøre oss avhengige av leveranser fra.
Fra Totalberedskapskommisjonens rapport (NOU 2023:17) vil vi blant annet fremheve:
«Det er behov for større robusthet med tanke på lagring av kritiske innsatsfaktorer og økt egenberedskap. Vi har bak oss
en lang periode med globalisering og stadig mer effektive, men komplekse internasjonale forsyningskjeder. Dette har gitt oss rimelige handelsvarer. Samtidig har våre egne lagre blitt bygget ned, og på enkelte områder har vi gjort oss avhengige av land og regioner vi ikke har interessefellesskap med.»
«Kina fortsetter å utfordre det vestlige fellesskapet på flere måter. Landet søker å kontrollere strategisk infrastruktur, ressurser og verdikjeder.»
«Pandemien og krigen i Ukraina har synliggjort sårbarheter knyttet til tilgang på kompetanse og materiell. Det er ikke gitt at spesialisert kompetanse og reservedeler alltid er tilgjengelige fra utlandet.»
«Samfunnsfunksjoner blir i økende grad avhengige av lange og uoversiktlige digitale verdikjeder, noe som gjør det mer krevende å ha kontroll på alle involverte aktører og underleverandører. Avhengigheter i flere ledd gir økt risiko for at sårbarheter utnyttes, at digitale tjenester blir utilgjengelige, at uvedkommende får tilgang til sensitivt innhold, og at innhold endres slik at det er usikkert hva som er ekte eller falskt.»
«Den tette koblingen mellom digitale systemer og lange digitale verdikjeder med ofte ukjente avhengigheter til et stort antall aktører, kompliserer arbeidet med digital sikkerhet ytterligere.» «Kommisjonen mener at digitale tjenester er blitt så viktige for å ivareta kritiske samfunnsfunksjoner at myndighetene må ta et større ansvar for sikkerhet gjennom verdikjeder og på tvers av alle samfunnssektorer.»
«For å redusere digitale sårbarheter nasjonalt i kritisk infrastruktur har det samtidig blitt viktigere å avgjøre hvilke land man ikke vil ha materiell fra eller andre former for avhengighet til. Kommisjonen mener at norske myndigheter fremover, i enda større grad, må legge premisser og gi råd med hensyn til hvilke land, teknologier og tjenester som anses å utgjøre en risiko for nasjonal sikkerhet.»
