Cyber Resilience Act-krav for fastvareteam

En distributør sender e-post og ber om din samsvarserklæring. Den går til salg, som videresender den til produktsjefen, som videresender den til ingeniøravdelingen, der den stopper. Enheten har vært på markedet i fire år. Fastvaren bygges på én ingeniørs maskin. Ingen har en oversikt over hva som er i den, oppdateringsmekanismen ble utelatt fra v1 for å nå en lanseringsdato, og personen som skrev oppstartslasteren, sluttet i 2023.

Ingenting av det var uaktsomt. Det var normalt, og det var helt greit helt frem til det øyeblikket noen i verdikjeden trengte et svar skriftlig.

EU Cyber Resilience Act er det som endret dette. Det er en markedsadgangsforordning, ikke en veiledning for beste sikkerhetspraksis: produkter med digitale elementer som selges inn i EU må oppfylle kravene, og forpliktelsene ligger på produsenten gjennom hele produktets levetid, snarere enn på et sertifikat utstedt én gang.

Denne artikkelen handler om de tekniske konsekvensene — hva CRA-samsvar faktisk endrer ved hvordan fastvare bygges, oppdateres og dokumenteres, og hvordan du vurderer om ditt eget team kan håndtere det ved siden av veikartet. Hvis du er tidligere enn det og fortsatt jobber med hvordan selve programvaren blir bygget, start med utviklingsguide for innebygd programvare.

Hva CRA-samsvar faktisk betyr for en enhetsprodusent

Europakommisjonen beskriver en forordning som dekker tilkoblingsbar maskinvare og programvare — dens egne eksempler strekker seg fra babymonitorer og smartklokker til apper og dataprogrammer — og den legger forpliktelsen på produsentene til å ivareta cybersikkerhet gjennom planlegging, design, utvikling og vedlikehold av produktet, og til å håndtere sårbarheter gjennom hele dets livssyklus. Produkter bærer CE-merking for å vise samsvar, og kategorier med høyere risiko krever tredjepartsvurdering av et teknisk kontrollorgan før de kan selges.

Les det som en ingeniør heller enn som en advokat, og tre ting følger.

Det knytter seg til prosessen, ikke til utgivelsen. «Planlegging, design, utvikling og vedlikehold» er hele livssyklusen. En samsvarsøvelse som kjøres i den siste sprinten før lansering, kan beskrive en prosess; den kan ikke skape en med tilbakevirkende kraft.

Det fortsetter etter levering. Å håndtere sårbarheter gjennom hele livssyklusen betyr at forpliktelsen fortsatt er aktiv for et produkt du solgte for tre år siden. Det er kravet som mest sannsynlig blir undervurdert, fordi det gjør en engangs prosjektkostnad om til en løpende driftskostnad.

Det gjelder det du selger, inkludert det du ikke skrev. En enhet består for det meste av andres kode — et RTOS, en TCP/IP-stakk, et kryptobibliotek, en leverandør-BSP, et dusin åpen kildekode-komponenter hentet inn av byggeprosessen. Plikten til å håndtere sårbarheter skiller ikke mellom koden du skrev og koden du leverte.

De tre datoene som bestemmer timeplanen din

Den midterste datoen er den som overrasker teamene. Rapportering kommer mer enn ett år før hovedforpliktelsene, og rapportering er ikke en dokumentasjonsoppgave — du kan ikke rapportere et aktivt utnyttet sårbarhet i produktet ditt med mindre noe overvåker etter det, noen eier beslutningen, og det finnes en vei til å levere rettelsen. I praksis krever septemberdatoen maskineriet som desemberdatoen 2027 formelt krever.

Ved å jobbe baklengs fra et produkt på en toårig maskinvaresyklus, blir arkitekturbeslutningene som gjør dette rimelig, tatt nå, i utformingen av det du startet i år.

Cyber Resilience Act-kravene som endrer fastvaren din

Fire ting går fra «vi burde» til «vi må», og hver enkelt er en arkitekturbeslutning snarere enn en funksjon.

En signert oppdateringssti som kan feile på en trygg måte

En forpliktelse til å håndtere sårbarheter gjennom et produkts levetid er en forpliktelse til å kunne levere en løsning, noe som betyr at mekanismen for fastvareoppdatering over luften slutter å være valgfri. Det tekniske innholdet er spesifikt: sikker oppstart slik at enheten bare kjører fastvare du har signert, integritetsvalidering på bildefilen, og tilbakerullingsbeskyttelse slik at en halvferdig oppdatering på en enhet i en kundes kjeller etterlater et fungerende produkt i stedet for en murstein. Produkter som allerede er ute i felten uten dette er det vanskelige tilfellet, fordi selve oppdateringsmekanismen må ankomme gjennom en kanal som ennå ikke eksisterer.

En oversikt over hva du faktisk sender

Håndtering av sårbarheter i komponenter du ikke selv har skrevet, krever kunnskap om hvilke komponenter du leverte, i hvilken versjon, i hvilket fastvarebilde, på hvilke enheter. De fleste team kan rekonstruere dette med en ukes innsats, men kan ikke generere det på nytt ved behov – og det er den forskjellen som betyr noe, fordi en sårbarhetsavsløring i et mye brukt bibliotek er et spørsmål du besvarer i løpet av timer, gjentatte ganger, i årevis. Den praktiske testen er om byggeprosessen din produserer den oversikten automatisk, eller om en person setter den sammen.

Sårbarhetshåndtering som en løpende prosess

Noen må overvåke sårbarhetsvarsler opp mot komponentlisten din, vurdere hva som gjelder for produktet ditt, og bestemme hva som skal sendes ut og når. Dette er forpliktelsen som mest av alt endrer formen på et ingeniørteam, fordi den er kontinuerlig og konkurrerer direkte med veikartarbeidet. Det er også den forpliktelsen der det ærlige svaret for mange produktselskaper er at ingen slik prosess eksisterer i dag.

Dokumentasjon som overlever menneskene som skrev den

Samsvar hviler på å kunne vise hvordan produktet ble designet, hva som ble vurdert, og hva som ble besluttet. Det er en annen artefakt enn et arkitekturdiagram tegnet én gang — det er dokumentasjon som holdes oppdatert sammen med koden, noe som er en disiplin snarere enn en leveranse. Innebygd programvare sikkerhetsarbeid har en tendens til å leve i hodene på to personer; dette kravet er det som tvinger det ut av dem.

Hvilke produkter er omfattet, og hvem bærer forpliktelsen

Omfanget er bredere enn de fleste maskinvareteam antar ved første gjennomlesning. Det er ikke begrenset til produkter som markedsføres som sikkerhetsenheter, og det er ikke begrenset til forbruksvarer – testen er om produktet har digitale elementer og kan koble til, noe som dekker det meste av det en produsent av industri-, medisinsk- eller forbrukerutstyr for øyeblikket leverer.

Forpliktelsen ligger hos produsenten. Det er viktig for to situasjoner som stadig dukker opp:

• Du fikk fastvaren bygget av noen andre. Forpliktelsen er fortsatt din. En utviklingskontrakt som slutter ved levering, etterlater deg med et livssyklusansvar uten tilknyttet ingeniørkapasitet, noe som er et omfangsspørsmål å avklare før kontrakten, ikke etter.
• Du selger til EU gjennom en distributør. Kravene må oppfylles gjennom hele verdikjeden, så forespørselen havner til slutt hos ingeniørteamet ditt uansett hvem som solgte enheten.

For produktkategorier med høyere risiko kreves tredjepartsvurdering av et teknisk kontrollorgan før salg, noe som legger til en ekstern avhengighet med sin egen ledetid til en tidsplan som allerede inneholder maskinvare.

Kan teamet ditt håndtere dette internt?

Dette er det virkelige spørsmålet, og det er ikke et spørsmål om kompetanse. De fleste innebygde team kan bygge sikker oppstart og en oppdateringsvei; mange har allerede bygget begge deler. Spørsmålet er kapasitet og kontinuitet, og det løses opp i fire ærlige kontroller.

Kan du regenerere komponentinventaret ditt i dag, på forespørsel? Hvis svaret involverer en person og et regneark, er gapet verktøy, og verktøy er det billigste av de fire gapene å tette.

Har et utplassert produkt en fungerende oppdateringsvei? Hvis ikke, er arbeidet ikke etterlevelsesarbeid — det er et fastvareprosjekt med en endring av oppstartslaster, en signeringsinfrastruktur og en utrullingsplan, og det må planlegges som ett.

Hvem er ansvarlig når en avsløring lander på en fredag? En navngitt person med myndighet til å levere, eller ingen. Dette er et spørsmål om driftsmodell som ingeniørledelsen ikke kan svare på alene.

Hva faller ut av veikartet? Arbeidet er reelt og det er tilbakevendende. En plan som antar at det vil bli absorbert uten å fortrenge noe, er en plan som stille og rolig ikke vil skje.

Der team velger å hente inn hjelp, er det vanligvis for den andre og tredje av disse: et avgrenset prosjekt for å bygge oppdaterings- og signeringsveien inn i et eksisterende produkt, og en prosess noen andre kjører til den er rutine. Der svaret er å ansette eller inngå et bredere samarbeid, gir ledende selskaper for utvikling av innebygd programvare oppsummeringen en sammenligning av elleve firmaer basert på kompetansen hver enkelt faktisk publiserer, inkludert hvilke av dem som oppgir sikker oppstart, OTA og langsiktig vedlikehold som sitt eget arbeid heller enn som en kundes problem.

Custom Firmware Development Services

Hva dette koster, og hvor kostnaden faktisk havner

Det finnes ikke ett enkelt tall, og intervallene som sirkulerer i leverandørmarkedsføring er ikke godt nok kildebelagt til å gjenta. Det som er forutsigbart er hvor hvor kostnaden konsentreres, noe som er mer nyttig når du bygger en forretningssak.

Ettermontering er den dyre kategorien, med god margin. Å legge til en signert oppdateringssti i et produkt som er designet uten en, berører oppstartslasteren, minnekartet, produksjonsprosessen og feltutrullingen. Å bygge det inn i et produkt nå koster en brøkdel av det.

Den tilbakevendende kostnaden er den som blir oversett. Overvåking, triagering og lanseringer av programrettelser fortsetter så lenge produktet selges og støttes. En forretningssak som bare priser det første prosjektet, undervurderer forpliktelsen, og det er den tilbakevendende posten som avgjør om dette absorberes eller tildeles ressurser.

Flåtefragmentering mangedobler alt. Fire maskinvarerevisjoner og tre fastvaregrener betyr at hver rettelse er fire eller flere utgivelser. Å konsolidere varianter er ofte den enkeltmest nyttige tingen et team kan gjøre før forpliktelsene slår inn, og det er en ren ingeniørøvelse uten noe regulatorisk innhold i det hele tatt.

Dokumentasjon er billig når den er kontinuerlig og dyr når den er arkeologisk. Holdt sammen med koden er den en liten skatt per endring. Rekonstruert i etterkant, på en kodebase hvis forfattere har sluttet, er den et prosjekt.

Hvor Crunch-IS passer inn

Vår tjenester for fastvareutvikling bygg oppstartslastere og feltoppdateringsmekanismer med sikker oppstartsverifisering, tilbakerullingsbeskyttelse og integritetsvalidering som standard, og omfangsherding — krypterte kommunikasjoner, sikker lagring, tilgangskontroll, reduksjon av angrepsflate — fra arkitekturstadiet i stedet for etter at produktet fungerer. Det er akkurat det samme settet med beslutninger som denne forskriften nå gjør ikke-valgfrie, og derfor er arbeidet oftere et fastvareprosjekt enn et samsvarsprosjekt.

Den andre halvdelen av det er utgivelsesdisiplin, fordi en forpliktelse til å levere rettelser pålitelig er en forpliktelse til å ha en utgivelsesprosess som ikke selv ødelegger ting. På en styringssystem for telekomnettverk, ombygging rundt renere grenser og en disiplinert utgivelsesprosess reduserte distribusjonsrelaterte problemer med 60 % og forbedret systemets oppetid og pålitelighet med 50 % — den samme evnen, målt på et annet problem.

Konklusjon

Cyber Resilience Act ber ikke enhetsprodusenter om å gjøre noe de bedre innebygde teamene ikke allerede argumenterte for. Det den endrer er at oppdateringsevne, avhengighetssynlighet og en løpende sårbarhetsprosess nå er betingelser for å selge, snarere enn ting man skal finansiere neste år — og at produktene som allerede er ute i felten omfattes sammen med det neste.

De to beslutningene som er verdt å ta nå, er arkitektoniske: design oppdateringsstien inn i det du starter med i år, og gjør komponentinventaret til noe byggeprosessen produserer i stedet for noe en person setter sammen. Begge deler er billigere nå enn på noe senere tidspunkt, og ingen av dem krever at reguleringen er fullstendig avklart før du handler.