Cyber Resilience Act-krav til firmware-teams

En distributør sender en e-mail og beder om jeres overensstemmelseserklæring. Den går til salg, som videresender den til produktchefen, som videresender den til ingeniørafdelingen, hvor den stopper. Enheden har været på markedet i fire år. Firmwaren bygges på én ingeniørs maskine. Ingen har en oversigt over, hvad der er i den, opdateringsmekanismen blev skåret fra i v1 for at nå en lanceringsdato, og personen, der skrev bootloaderen, rejste i 2023.

Intet af det var uagtsomt. Det var normalt, og det var helt fint lige indtil det øjeblik, hvor nogen i værdikæden havde brug for et svar på skrift.

EU’s Cyber Resilience Act er det, der ændrede det. Det er en markedsadgangsforordning, ikke en vejledning i bedste praksis for sikkerhed: produkter med digitale elementer, der sælges i EU, skal opfylde dens krav, og forpligtelserne ligger hos producenten gennem hele produktets levetid frem for på et certifikat, der udstedes én gang.

Denne artikel handler om de tekniske konsekvenser — hvad CRA-overholdelse faktisk ændrer ved, hvordan firmware bygges, opdateres og dokumenteres, og hvordan man vurderer, om dit eget team kan rumme det sideløbende med køreplanen. Hvis du er tidligere end det og stadig er ved at finde ud af, hvordan selve softwaren bliver bygget, så start med udviklingsguide til indlejret software.

Hvad CRA-overholdelse faktisk betyder for en enhedsproducent

Europa-Kommissionen beskriver en forordning, der dækker forbindbar hardware og software — dens egne eksempler spænder fra babyalarmer og smartwatches til apps og computerprogrammer — og den pålægger producenterne forpligtelsen til at håndtere cybersikkerhed gennem planlægning, design, udvikling og vedligeholdelse af produktet samt til at håndtere sårbarheder gennem hele dets livscyklus. Produkter bærer CE-mærkning for at vise overensstemmelse, og kategorier med højere risiko kræver tredjepartsvurdering af et bemyndiget organ, før de kan sælges.

Læs det som ingeniør snarere end som advokat, og tre ting følger heraf.

Den knytter sig til processen, ikke til udgivelsen. “Planlægning, design, udvikling og vedligeholdelse” er hele livscyklussen. En overensstemmelsesøvelse, der køres i den sidste sprint før lanceringen, kan beskrive en proces; den kan ikke skabe en med tilbagevirkende kraft.

Det fortsætter efter forsendelse. Håndtering af sårbarheder gennem hele livscyklussen betyder, at forpligtelsen stadig er aktiv på et produkt, du solgte for tre år siden. Det er det krav, der mest sandsynligt bliver undervurderet, fordi det omdanner en engangsprojektomkostning til en løbende driftsomkostning.

Det gælder for det, du sælger, inklusive det, du ikke har skrevet. En enhed består for det meste af andres kode — et RTOS, en TCP/IP-stak, et krypteringsbibliotek, en leverandør-BSP, et dusin open source-komponenter trukket ind af builden. Forpligtelsen til at håndtere sårbarheder skelner ikke mellem den kode, du har skrevet, og den kode, du har leveret.

De Tre Datoer, Der Fastlægger Din Tidsplan

Den midterste dato er den, der overrasker teams. Rapportering ankommer mere end et år før hovedforpligtelserne, og rapportering er ikke en dokumentationsopgave — du kan ikke rapportere en aktivt udnyttet sårbarhed i dit produkt, medmindre noget holder øje med det, nogen ejer beslutningen, og der er en vej til at udsende rettelsen. I praksis kræver september-datoen det maskineri, som december 2027-datoen formelt kræver.

Ved at arbejde baglæns fra et produkt på en toårig hardwarecyklus træffes de arkitekturbeslutninger, der gør dette overkommeligt, nu, i designet af hvad end du startede i år.

Cyber Resilience Act-kravene, der ændrer din firmware

Fire ting rykker fra “vi bør” til “vi skal”, og hver af dem er en arkitekturbeslutning snarere end en funktion.

En signeret opdateringssti, der kan fejle sikkert

En forpligtelse til at håndtere sårbarheder over et produkts levetid er en forpligtelse til at kunne levere en rettelse, hvilket betyder, at mekanismen til firmware-opdatering over luften ikke længere er valgfri. Det tekniske indhold er specifikt: secure boot, så enheden kun kører firmware, du har signeret, integritetsvalidering af imaget, og rollback-beskyttelse, så en halvt anvendt opdatering på en enhed i en kundes kælder efterlader et fungerende produkt frem for en mursten. Produkter, der allerede er i marken uden dette, er den svære sag, fordi selve opdateringsmekanismen skal ankomme gennem en kanal, der endnu ikke findes.

En opgørelse over hvad du rent faktisk sender

Håndtering af sårbarheder i komponenter, du ikke selv har skrevet, kræver, at du ved, hvilke komponenter du har leveret, i hvilken version, i hvilket firmware-image, på hvilke enheder. De fleste teams kan rekonstruere dette med en uges arbejde, men kan ikke regenerere det efter behov — og det er den forskel, der betyder noget, for en sårbarhedsoffentliggørelse i et bredt anvendt bibliotek er et spørgsmål, du besvarer på få timer, gentagne gange, i årevis. Den praktiske test er, om din build producerer denne oversigt automatisk, eller om en person samler den.

Håndtering af sårbarheder som en løbende proces

Nogen er nødt til at holde øje med sårbarhedsmeddelelser i forhold til din komponentliste, sortere hvad der gælder for dit produkt, og beslutte hvad der skal udsendes og hvornår. Dette er den forpligtelse, der mest ændrer formen på et ingeniørteam, fordi den er kontinuerlig og konkurrerer direkte med roadmap-arbejde. Det er også den, hvor det ærlige svar for mange produktvirksomheder er, at ingen sådan proces eksisterer i dag.

Dokumentation, der overlever de mennesker, som skrev den

Overensstemmelse hviler på at kunne vise, hvordan produktet blev designet, hvad der blev vurderet, og hvad der blev besluttet. Det er en anden artefakt end et arkitekturdiagram, der tegnes én gang — det er dokumentation, der holdes opdateret sammen med koden, hvilket er en disciplin snarere end en leverance. Indlejret software sikkerhedsarbejde har en tendens til at leve i hovederne på to personer; dette krav er det, der tvinger det ud af dem.

Hvilke produkter er omfattet, og hvem bærer forpligtelsen

Omfanget er bredere, end de fleste hardwareteams antager ved første gennemlæsning. Det er ikke begrænset til produkter, der markedsføres som sikkerhedsenheder, og det er ikke begrænset til forbrugervarer — testen er, om produktet har digitale elementer og kan oprette forbindelse, hvilket dækker det meste af, hvad en producent af industri-, medicinsk eller forbrugerudstyr i øjeblikket leverer.

Forpligtelsen ligger hos producenten. Det har betydning for to situationer, der opstår konstant:

• Du fik firmwaren bygget af en anden. Forpligtelsen er stadig din. En udviklingskontrakt, der slutter ved levering, efterlader dig med en livscyklusforpligtelse uden nogen ingeniørkapacitet knyttet til den, hvilket er et afgrænsningsspørgsmål, der skal afklares før kontrakten, ikke efter.
• Du sælger til EU gennem en distributør. Kravene skal opfyldes på tværs af værdikæden, så anmodningen når til sidst frem til dit ingeniørteam, uanset hvem der solgte enheden.

For produktkategorier med højere risiko kræves der en tredjepartsvurdering foretaget af et bemyndiget organ, før salg kan finde sted, hvilket tilføjer en ekstern afhængighed med sin egen leveringstid til en tidsplan, der allerede indeholder hardware.

Kan dit team håndtere dette internt?

Dette er det egentlige spørgsmål, og det er ikke et spørgsmål om kompetence. De fleste embedded-teams kan bygge secure boot og en opdateringssti; mange har allerede bygget begge dele. Spørgsmålet er kapacitet og kontinuitet, og det opløses i fire ærlige tjek.

Kan du regenerere din komponentopgørelse i dag, efter behov? Hvis svaret involverer en person og et regneark, er problemet værktøjer, og værktøjer er den billigste af de fire mangler at lukke.

Har et produkt i felten en fungerende opdateringssti? Hvis ikke, er arbejdet ikke overholdelsesarbejde — det er et firmwareprojekt med en bootloader-ændring, en signeringsinfrastruktur og en udrulningsplan, og det skal planlægges som sådan.

Hvem står med ansvaret, når en offentliggørelse lander en fredag? En navngiven person med bemyndigelse til at levere, eller ingen. Dette er et spørgsmål om driftsmodel, som teknisk ledelse ikke kan besvare alene.

Hvad ryger af køreplanen? Arbejdet er reelt, og det er tilbagevendende. En plan, der antager, at det vil blive absorberet uden at fortrænge noget, er en plan, der stille og roligt ikke vil ske.

Når teams vælger at hente hjælp ind, er det som regel til de sidste to af disse: et afgrænset projekt til at bygge opdaterings- og signeringsstien ind i et eksisterende produkt, og en proces, som en anden kører, indtil den er rutine. Hvor svaret er at ansætte eller at indgå et bredere partnerskab, sammenligner førende virksomheder inden for udvikling af indlejret software oversigten elleve firmaer på den kapacitet, hver enkelt faktisk offentliggør, herunder hvilke af dem der nævner sikker opstart, OTA og langsigtet vedligeholdelse som deres eget arbejde snarere end som en kundes problem.

Custom Firmware Development Services

Hvad Dette Koster, og Hvor Omkostningen Faktisk Lander

Der findes ikke et enkelt tal, og de intervaller, der cirkulerer i leverandørmarkedsføring, er ikke tilstrækkeligt kildehenvist til at gentage. Hvad der er forudsigeligt, er hvor hvor omkostningerne koncentreres, hvilket er mere nyttigt, når du opbygger en forretningscase.

Eftermontering er den dyre kategori, med stor margin. At tilføje en signeret opdateringssti til et produkt, der er designet uden en, berører bootloaderen, hukommelseskortet, fremstillingsprocessen og udrulningen i marken. At bygge det ind i et produkt nu koster en brøkdel af det.

Den tilbagevendende omkostning er den, der bliver overset. Overvågning, triagering og patch-udgivelser fortsætter, så længe produktet sælges og understøttes. En forretningsanalyse, der kun prissætter det første projekt, undervurderer forpligtelsen, og det er den tilbagevendende post, der afgør, om dette absorberes eller ressourceallokeres.

Flådefragmentering mangedobler alt. Fire hardwarerevisioner og tre firmwaregrene betyder, at hver rettelse er fire eller flere udgivelser. Konsolidering af varianter er ofte det mest nyttige, et team kan gøre, før forpligtelserne bider, og det er en ren ingeniørmæssig øvelse uden noget regulatorisk indhold overhovedet.

Dokumentation er billig, når den er kontinuerlig, og dyr, når den er arkæologisk. Holdt sammen med koden er det en lille skat pr. ændring. Rekonstrueret bagefter, på en kodebase hvis forfattere er rejst, er det et projekt.

Where Crunch-IS Fits

Vores firmwareudviklingstjenester bygger bootloadere og feltopdateringsmekanismer med sikker boot-verifikation, rollback-beskyttelse og integritetsvalidering som standard og omfangshærdning — krypteret kommunikation, sikker lagring, adgangskontrol, reduktion af angrebsflade — fra arkitekturstadiet frem for efter at produktet virker. Det er den samme række beslutninger, som denne forordning nu gør ikke-valgfri, hvilket er grunden til, at arbejdet oftere er et firmwareprojekt end et compliance-projekt.

Den anden halvdel af det er udgivelsesdisciplin, fordi en forpligtelse til at levere rettelser pålideligt er en forpligtelse til at have en udgivelsesproces, der ikke selv ødelægger ting. På en telekommunikationsnetværks-administrationssystem, ved at genopbygge omkring renere grænser og en disciplineret udgivelsesproces reducerede implementeringsrelaterede problemer med 60% og forbedrede systemets oppetid og pålidelighed med 50% — den samme evne, målt på et andet problem.

Konklusion

Cyber Resilience Act beder ikke enhedsproducenter om at gøre noget, som de bedre embedded-teams ikke allerede argumenterede for. Det, den ændrer, er, at opdateringskapacitet, afhængighedssynlighed og en løbende sårbarhedsproces nu er betingelser for at sælge frem for ting, der skal finansieres næste år — og at de produkter, der allerede er ude i marken, er omfattet sammen med det næste.

De to beslutninger, der er værd at træffe nu, er arkitektoniske: design opdateringsstien ind i det, du starter på i år, og gør din komponentopgørelse til noget, som builden producerer, frem for noget, en person samler. Begge dele er billigere nu end på noget senere tidspunkt, og ingen af dem kræver, at reguleringen er fuldt afklaret, før du handler.