Cyber Resilience Act: CE-märkning för programvara

Inbyggnadsvärlden är full av prylar med undermålig säkerhet. Bilar som kan fjärrstyras och webbkameror med ”admin” som standardlösenord är bara några exempel. En kommande EU-förordning om Cyberresiliens vill råda bot på detta genom att tvinga tillverkarna att dels prioritera säkerheten, dels ta ansvar när de misslyckas.

CRA ett problem för öppen källkod

Utvecklare av öppen källkod är skeptiska till Cyber Resilience Act i sin nuvarande form, berättar konsulten Olle E. Johansson som har lång erfarenhet av öppen källkodsutveckling. Öppen kod är förvisso undantagen från kraven i CRA, men undantaget gäller inte om koden ingår i en produkt eller tjänst som tillhandahålls kommersiellt.

– Det är många utvecklare som har inkomster från till exempel support eller konsulttjänster kring sin kod. Det kan bli svårt för dem att dra gränsen mellan vad som faller under CRA och vad som inte gör det, säger han.

Electronic Frontier Foundation har framfört liknande synpunkter, och påpekar att öppen källkodsutvecklare riskerar att hamna i domstol om någon hittar säkerhetshål i deras kod.

Förordningen, som är mer känd under sitt engelska namn Cyber Resilience Act (CRA), är en utvidgning av EU:s CE-märkning till att även täcka programkod och den vilar i huvudsak på två ben. Tillverkare av produkter som innehåller programkod – och vilka gör inte det idag? – ska ha koll på vilken kod som ingår i produkten och varifrån de olika programmodulerna kommer; en ”Software bill of materials”. Dessutom måste tillverkaren informera sina kunder om en sårbarhet i koden upptäcks, och även uppdatera programvaran för att täppa igen sårbarheten. Sådana säkerhetsuppdateringar ska tillverkaren hålla med under minst fem år, räknat från försäljningsdatum.

Lägg därtill en allmän portalparagraf om att säkerhetstänket måste finnas med redan när en produkt konstrueras och att allt ska levereras med säkra standardinställningar – inga fler inloggningar med ”admin” och blankt lösenord, alltså – och du har en ganska bra bild av vad Cyber Resilience Act innehåller.

Vissa typer av produkter är undantagna från CRA, som till exempel medicinska och militära system som har sina egna regelverk. Öppen källkod undantas också generellt, men med ett undantag som har fått kritik från flera håll: om den öppna källkoden ingår i en produkt eller tjänst som tillhandahålls kommersiellt lyder den under CRA. Vi återkommer till det.

Även om CRA är relativt enkel att förstå kan det bli komplicerat att följa regelverket. På ett seminarium den 30 maj som arrangerades av programvaruföretagens branschorganisation Swedsoft berättade Rikard Jarl, Business Information Security Officer på SKF, hur hans företag förbereder sig för CRA. Och han började med att förklara att det till stor del handlar om att skifta perspektiv.

– Historiskt sett har IT-säkerhet handlat om att skydda det egna företaget. Med CRA hamnar vi istället i ett läge där vi ska säkra våra produkter, och i förlängningen skydda våra kunder mot IT-attacker.

Det ställer stora krav på ökad öppenhet och kommunikation från SKF.

– Vi får mycket större krav på oss när det gäller kommunikation till kunder och allmänhet. Vi kommer dessutom behöva etablera kanaler för rapportering till myndigheter som Enisa på EU-nivå, och med tiden säkerligen också nationella CRA-myndigheter, säger Rikard Jarl.

Han spaltar upp CRA-kraven i två grupper. Kommunikation med myndigheter och allmänhet hamnar i den grupp som bör hanteras på ledningsnivå, liksom till exempel systematisk rapportering av incidenter. För produktutvecklarna handlar det dels om att se till att en säkerhetsanalys görs redan från början och att säkerhetstänk och -krav följer med genom hela processen, dels att den tekniska dokumentationen inklusive materiallistan (bill of materials) ska hållas tillgänglig och uppdaterad under hela produktens livslängd. Helst ska också programvaran i produkten kunna uppdateras automatiskt, ett krav som kanske inte blir så lätt att leva upp till i exempelvis industrimiljö eller ett fordon.

De tre klasserna

Cyber Resilience Act delar in produkter i tre klasser. I ”Default” hamnar i princip all konsumentelektronik, och för den klassen är det tillräckligt att tillverkaren själv intygar att produkten följer kraven. ”Critical Class II” är avsedd för IoT-produkter som är tänkta att användas i tillämpningar som omfattas av EU:s NIS2-direktiv, dvs särskilt säkerhetskänsliga branscher som energi och transport, och för dessa krävs att en fristående part certifierar produkten. I mellangruppen, ”Critical Class I”, återfinns övriga IoT-produkter och här kan tillverkaren endera certifiera produkten eller hänvisa till att man följer en relevant EU-standard.

Den som tillhandahåller en produkt som faller under CRA har hela ansvaret gentemot köparen, även för eventuell programkod man har hämtat in utifrån. För ett företag som SKF innebär det att man behöver ha avtal som binder underleverantörerna till samma regelverk. Och om det inte finns någon att skriva avtal med, som ofta kan vara fallet när det gäller öppen källkod, måste man testa.

– Vi behöver absolut förbereda oss för att hantera storskalig testning av komponenter vi tar in utifrån, säger Rikard Jarl.

I skrivande stund är CRA ute på remiss. Som förslaget ser ut nu innehåller det två viktiga tidsgränser: inom 12 månader efter att lagen har trätt i kraft ska företagen ha processer på plats för att rapportera om sårbarheter i sina produkter, och inom 24 månader ska de leva upp till samtliga krav.

Belöningen för att följa reglerna i CRA blir ett CE-märke på produkten. Priset för att inte följa dem kan bli högt, man kan få böter på upp till det högsta av 15 miljoner euro eller 2,5 procent av årsomsättningen.