Hvordan takle oppdateringer for CRA

Om forfatteren:

George Grey er Teknologidirektør i Qualcomm Technologies International, Ltd., og medlem av Foundries.io team.

– CRA fremstår som en av de største tekniske og organisatoriske utfordringene produsenter som markedsfører innvevde enheter i Europa står overfor. Loven trådte i kraft 10. desember 2024, og mange av hovedforpliktelsene vil gjelde for OEM-er tre år senere, fra 11. desember 2027.

Oppdateringer sentralt

Et avgjørende element i en OEMs innsats for samsvar med CRA-krav er muligheten til å oppdatere en enhets programvare for å beskytte den mot nye cybertrusler, og spesielt for å reagere på offisielle varsler om vanlige sårbarheter og eksponeringer (CVE). Selv om maskinvarekomponentene i et sikkerhetskompatibelt system – enheter som en Hardware Security Module (HSM) eller Trusted Platform Module (TPM) – er godt forstått av OEM-er i dag, er prosessen med å opprettholde sikkerhetsbeskyttelsen av innvevd programvare og distribuere programvareoppdateringer til enheter i felten ny og ukjent for mange.

Grunn til bekymring?

Det er forståelig at temaet programvareoppdatering vekker en viss bekymring: Det er på flere måter en kompleks og vanskelig funksjon å håndtere. Faktisk er dette et område der Foundries.io har levert teknologi og støtte til produsenter av innvevde enheter i mange år. Etter vår mening er det ingen grunn til at noen OEM skal være bekymret over kravene til programvareoppdatering fra CRA. Men utrullingen av lovgivningen har vist at selv om mye av prosessen kan strømlinjeformes og automatiseres, har bransjen ennå ikke fylt gapet når det gjelder å tilby noen viktige verktøy og hjelpeprogrammer som ville lette byrden av CRA-samsvar betydelig.

Hvordan CRA krever at programvareoppdateringer håndteres

Ifølge EU er formålet med CRA å «beskytte forbrukere og bedrifter som kjøper programvare- eller maskinvareprodukter med en digital komponent». CRA tar tak i det utilstrekkelige nivået av cybersikkerhet i mange produkter, og mangelen på rettidige sikkerhetsoppdateringer for produkter og programvare (se figur 1). Loven tar sikte på å oppnå sine mål ved å legge nye forpliktelser på et produkts produsent og forhandlere. Spesielt krever loven at «produsenter sørger for støtte i løpet av produktenes livssyklus».

Livslang forpliktelse

Forbi er dagene da en produsent av elektronikkprodukter kunne sende et produkt fra fabrikken og deretter glemme at det noen gang eksisterte: En forpliktelse til å opprettholde beskyttelse mot trusselen fra cyberangrep fortsetter nå lenge etter at enheten er sendt til sluttbrukeren.

Loven kodifiserer denne fortsatte sikkerhetsforpliktelsen på ulike måter, hvorav de viktigste er:

• Håndtere sårbarheter identifisert i gjeldende CVE-varsler etter forsendelse
• Opprettholde en obligatorisk programvareliste (SBOM) for hver produksjonsenhet, for å muliggjøre effektiv CVE-sporing
• Rette sårbarheter «uten forsinkelse»
• Teste og gjennomgå produktsikkerheten regelmessig
• Ha en policy for avsløring av sårbarheter
• Distribuer rettelser/oppdateringer på en sikker måte «i tide» og gratis til sluttbrukeren.

SBOM

Så OEM-en har nå en plikt til å lage en oversikt, eller SBOM, over alle programvarekomponentene i hver produksjonsenhet som sendes fra fabrikken, å vedlikeholde og oppdatere SBOM-en for å ta hensyn til endringer i en enhets kodebase som følge av oppdateringer og oppdateringer, å vite når noen del av enhetens kodebase er utsatt for en kjent sårbarhet, og å raskt fikse sårbarheten og distribuere rettelsen gratis til brukere (se figur 2).

Verdien av vedlikeholdsinfrastruktur for å støtte livstidsoppdatering

Kodebasen til dagens tilkoblede innvevde enheter, spesielt de som er basert på et Linux-operativsystem, er stor og kompleks: den består ofte av hundrevis eller tusenvis av separate komponenter fra kommersielle og åpen kildekode-tredjeparter, samt proprietær programvare. Det er nesten alltid upraktisk å sette sammen en oversikt over disse komponentene manuelt: Det trengs et system for å automatisere SBOM-generering under utvikling, i produksjon og etter forsendelse av hver produktvariant.

Omfattende

Kompleksiteten strekker seg til sikkerhetsfunksjoner som sikker oppstart, autentisering og kryptografisk beskyttelse av data og programvareoppdateringer. Registreringer av hemmelige nøkler som er unike for hver produksjonsenhet må lagres og administreres sikkert. Administrasjon av offentlig nøkkelinfrastruktur (PKI) er et viktig element i en OEMs tilnærming til samsvar med CRA-krav.

Flåtestyring

I tillegg trenger OEM-er et system for flåtestyring av enheter i felten: Dette gir et grunnlag for levering og distribusjon av riktige oppdateringspakker for hver enkelt enhet. Et effektivt flåtestyringssystem gir en sikkerhetsfokusert oversikt over alle enheter som sendes til kunder (bortsett fra de som er kjent for å være utrangert), hver merket med en unik sikker ID. Dette kan bidra til å beskytte flåten mot risikoen for at en cyberangriper introduserer en forfalsket enhet i flåten i et forsøk på for eksempel å få tilgang til kritiske hemmeligheter eller kode.

Systematisk tilnærming

Disse funksjonene krever en systematisk tilnærming til logging, lagring og administrasjon av data enhet-for-enhet og ende-til-ende, fra utvikling gjennom produksjon til vedlikehold etter forsendelse. Fordi alle disse funksjonene underbygger samsvar med CRA, har innføringen av denne europeiske forskriften gitt OEM-er ekstra drivkraft til å distribuere et formelt DevOps-rammeverk – den typen system som FoundriesFactory- plattformen fra Foundries.io er et eksempel på (se figur 3).

Enhver slik plattform bør tilby et integrert sett med verktøy og verktøy for å sørge for:

• PKI-administrasjon
• SBOM-generering og -vedlikehold
• Flåteadministrasjon
• En CI/CD-flyt for å støtte rask utvikling og distribusjon av feilrettinger og oppdateringer
• Utvikling, levering og distribusjon av oppdateringer støttet av sterke sikkerhetsfunksjoner

Ved å innføre et slikt rammeverk i starten av en ny produktutvikling, og bruke det som grunnlag for livssyklusstyring, kan OEM-er automatisere, effektivisere og forenkle enhetsstyring og sikkerhetsprosesser som ellers ville være ekstremt komplekse, tidkrevende og utsatt for menneskelige feil.

De manglende brikkene i samsvars-puslespillet

Et velprøvd DevOps-rammeverk kan være nødvendig for alle unntatt de minste OEM-ene for å håndtere sin innsats for samsvar med CRA-regler, men det er ikke tilstrekkelig. Andre verktøy og systemer er nødvendige, men dessverre finnes det ennå ikke effektive verktøy med åpen kildekode for noen av de viktigste elementene i samsvarsoppgaven. To hull er spesielt slående:

• For sporing av CVE-eksponering

• For dokumentasjon og revisjon av samsvarstiltak

CVE-sjekkere

Dagens CVE-sjekkere har en tendens til å være primitive: de gir for mange positive resultater. Dette er fordi de rett og slett matcher navnet og beskrivelsen av en programvarepakke identifisert i en CVE-melding med navnet og beskrivelsen av programvaren i en enhets SBOM. Men dette er ikke det samme som å identifisere en spesifikk sårbarhet. En CVE-melding vil normalt gjelde en spesifikk del eller deler av et programvareprodukts kodebase; resten av kodebasen er ikke i faresonen.

Så hvis en innvevd enhet bare bruker en del av produktet til å implementere en spesifikk funksjon, og ikke inneholder den sårbare delen av kodebasen, vil det ikke være behov for å opprette og distribuere en løsning for den. Men en enkel CVE-sjekker vil uansett flagge enheten som sårbar hvis den bruker noen del av en programvarepakke som er navngitt i et CVE-varsel.

Trenger bedre verktøy

Dette understreker behovet for mer sofistikerte verktøy, som kan skanne en enhets kildekode og finne samsvar med sårbar kode identifisert i et CVE-varsel. Det er grunn til å være optimistisk med tanke på at den nye tilgjengeligheten av avanserte AI-modeller kan danne grunnlaget for et slikt verktøy i fremtiden.

Rapportering

Det andre hullet i verktøysettet for samsvar er et system som støtter rapportering og revisjon. CRA ilegger høye bøter knyttet til størrelsen på produktprodusenten for manglende samsvar. Dette bør sterkt motivere OEM-er til å demonstrere hvordan de har overholdt lovens vilkår, med henvisning til hver eneste produksjonsenhet i feltet.

Akkurat som SBOM-verktøyet i programvare som FoundriesFactory-plattformen automatiserer genereringen av en liste over programvarekomponenter enhet for enhet, må et effektivt verktøy for samsvarsrapportering føre oversikt over de rapporterte eksponeringene og de iverksatte rettelsene, enhet for enhet.

Åpen kildekode

Ideelt sett vil verktøyene for å fylle begge disse hullene komme fra åpen kildekode-miljøet, og få bred nok adopsjon til å bli standardiserte. Der standard åpen kildekode-løsninger finnes, tjener bransjen på å unngå behovet for at flere selskaper må finne opp hjulet på nytt, og ved å dele felles læring og erfaringer.

Den positive sirkelen av standardisering med åpen kildekode er grunnen til at FoundriesFactory-plattformen, for eksempel, tok i bruk The Update Framework (TUF) som sitt verktøy for sikkerhetsfokusert levering og distribusjon av programvareoppdateringer. Mange andre elementer på FoundriesFactory-plattformen har et åpen kildekode-grunnlag av samme grunn.

Programvareoppdatering: en prosess, ikke en pakke

Under presset om å kreve samsvar med CRA-forskriftene, sliter OEM-produsenter nå med vanskelighetene med programvareoppdatering. De erfarer at programvareoppdateringer er et avgjørende element i deres samsvarsarbeid, men at programvareoppdatering ikke bare handler om oppdateringspakken: et helt system med enhetsovervåking, sikkerhet, flåtestyring og programvaredistribusjonsfunksjoner underbygger evnen til å reagere raskt på en ny sårbarhet eller eksponering.

Velprøvd rammeverk

Mange OEM-er vil dra nytte av å bygge oppdateringsinfrastrukturen sin på et velprøvd DevOps-rammeverk, som vil gi et solid og automatisert grunnlag for å identifisere og vedlikeholde produksjonsenheter i felten på en sikkerhetsrik måte, slik at de kan levere riktig oppdateringspakke til riktig enhet til riktig tid.