Tillverkarens skyldigheter I: Riskbedömning och design (centrala artiklar i kapitel II)

Översikt: Tillverkarens skyldigheter i design- och utvecklingsfasen

I den här modulen fokuserar vi på tidiga faser i produktlivscykeln enligt Cyber Resilience Act (CRA), alltså EU:s förordning om cybersäkerhet för produkter med digitala element.

Vi knyter särskilt an till:

• Kapitel II – Tillverkarens skyldigheter (framför allt artiklarna om riskbedömning, säker design och dokumentation)
• Artikel 6 – koppling till de väsentliga cybersäkerhetskraven i bilaga I
• Översiktlig koppling till artikel 31 och bilaga VII (teknisk dokumentation)

Efter modulen ska du kunna:

1. Förklara vad en cybersäkerhetsriskbedömning enligt CRA ska omfatta.
2. Beskriva hur säker design och utveckling påverkar hela produktlivscykeln, inklusive stödperiod.
3. Förstå sambandet mellan riskbedömning, stödperiod (support) och teknisk dokumentation.

> Tidslinje-kontekst (viktigt):

> - CRA antogs på EU-nivå under 2024 och är en förordning (direkt tillämplig i medlemsstaterna).

> - Den ersätter inte NIS2, men kompletterar den med produktkrav.

> - När du läser om äldre direktiv eller standarder: CRA är nu den centrala rättsakten för cybersäkerhetskrav på produkter med digitala element.

Steg 1: Vad menas med cybersäkerhetsriskbedömning enligt CRA?

Enligt CRA måste tillverkaren innan design och utveckling går för långt göra en systematisk cybersäkerhetsriskbedömning för produkten.

I praktiken innebär det att du som tillverkare ska:

1. Identifiera tillgångar:

• Vilka delar av produkten är värdefulla och måste skyddas? (t.ex. användardata, styrfunktioner, anslutningsgränssnitt)

1. Identifiera hot och angripare:

• Vilka typer av attacker är realistiska? (t.ex. ransomware, fjärrangrepp via internet, supply chain-attacker)
• Vilka angripare är relevanta? (script kiddies, cyberkriminella, statligt sponsrade aktörer, insiders)

1. Identifiera sårbarheter:

• I mjukvara (t.ex. osäkra bibliotek, känd sårbarhet i ett open source-paket)
• I hårdvara (t.ex. avsaknad av säkert uppstartsflöde)
• I processer (t.ex. bristande åtkomstkontroll för utvecklare)

1. Bedöma sannolikhet och konsekvens:

• Hur troligt är det att hotet utnyttjar sårbarheten?
• Vilka blir effekterna? (konfidentialitet, integritet, tillgänglighet, säkerhet för användare, samhällspåverkan)

1. Välja riskbehandling:

• Minska (införa kontroller), överföra (t.ex. försäkring), undvika (ändra design), eller i vissa fall acceptera risk (men detta måste vara motiverat och dokumenterat).

Allt detta ska dokumenteras och kopplas till de krav som anges i bilaga I. Riskbedömningen är alltså inte fristående, utan styr vilka tekniska och organisatoriska åtgärder du behöver bygga in i produkten.

Steg 2: Mini-övning – Identifiera cybersäkerhetsrisker

Föreställ dig att du är tillverkare av en smart dörrlåsprodukt som styrs via en mobilapp och är uppkopplad mot molnet.

Uppgift: Skriv (mentalt eller på papper) ned minst 2 risker inom varje kategori nedan:

1. Tillgångar – Vad behöver skyddas?

• Exempel: …

1. Hot – Vilka attacker kan förekomma?

• Exempel: …

1. Sårbarheter – Vad kan göra dessa attacker möjliga?

• Exempel: …

Reflektera sedan:

• Vilken av dessa risker tror du måste hanteras redan i designfasen (inte kan skjutas upp till senare patchar)?
• Hur skulle du kunna koppla denna risk till ett generellt krav i bilaga I (t.ex. krav på skydd mot obehörig åtkomst, säkra uppdateringar, loggning osv.)?

> Tips: Försök att tänka både tekniskt (t.ex. kryptering, autentisering) och organisatoriskt (t.ex. hur utvecklingsteamet hanterar hemligheter/nycklar).

Steg 3: Kopplingen mellan riskbedömning, artikel 6 och bilaga I

I CRA spelar artikel 6 en nyckelroll: den kopplar din riskbedömning till de väsentliga cybersäkerhetskraven i bilaga I.

Förenklat kan man se det så här:

1. Bilaga I = Målbild

• Bilaga I listar vad produkten ska uppnå ur cybersäkerhetssynpunkt (t.ex. skydd mot obehörig åtkomst, säkra uppdateringar, robusthet mot kända sårbarheter, hantering av data osv.).

1. Riskbedömning = Analys av din specifika produkt

• Vilka av dessa krav är mest kritiska för just din produkt?
• Var är riskerna störst, med tanke på användningsområde och hotbild?

1. Artikel 6 = Bro mellan analys och krav

• Artikel 6 kräver att tillverkaren säkerställer överensstämmelse med bilaga I, baserat på resultatet av riskbedömningen.
• Du ska alltså kunna visa hur riskbedömningen lett till specifika designbeslut, t.ex.:
• Val av autentiseringsmetod
• Krypteringsnivå
• Loggnings- och övervakningsfunktioner

1. Praktisk konsekvens

• Det räcker inte att säga: "Vi följer bilaga I".
• Du behöver kunna visa: "Vi identifierade risk X, därför implementerade vi kontroll Y för att uppfylla krav Z i bilaga I".

Den här spårbarheten blir senare viktig när du tar fram teknisk dokumentation (artikel 31/bilaga VII) och vid bedömning av överensstämmelse.

Steg 4: Exempel – Från riskbedömning till designbeslut

Låt oss ta ett förenklat exempel med en uppkopplad industrisensor som skickar data till ett SCADA-system.

1. Riskbedömning (utsnitt)

• Tillgång: Mätdata som styr en kemisk process.
• Hot: Angripare manipulerar mätdata för att orsaka felaktiga styrsignaler.
• Sårbarhet: Kommunikation mellan sensor och styrsystem är okrypterad och utan autentisering.
• Konsekvens: Allvarlig – kan leda till personskada eller miljöskada.

1. Koppling till bilaga I (förenklat, exempel på kravtyper):

• Krav på säker kommunikation (integritet och konfidentialitet)
• Krav på autentisering av komponenter
• Krav på robusthet mot manipulation av data

1. Designbeslut

• Införa krypterad kommunikation (t.ex. TLS) mellan sensor och SCADA.
• Införa ömsesidig autentisering (både sensor och server verifieras).
• Implementera integritetskontroller (t.ex. signering av meddelanden).

1. Dokumentation (översiktligt)

• I riskanalysdokumentet: Beskriv hotet och risknivån.
• I designbeskrivningen: Visa hur protokollet valts, vilka säkerhetsfunktioner som är aktiverade, och varför detta är tillräckligt.
• I teknisk dokumentation: Länka krav i bilaga I → risk → designlösning.

> Poängen: CRA kräver inte en viss teknik, men kräver att du motiverar varför dina val är tillräckliga för att hantera identifierade risker i linje med bilaga I.

Steg 5: Säker design och utveckling – livscykelperspektiv och stödperiod

CRA betonar säker design och utveckling under hela produktlivscykeln, inte bara vid lansering.

Några centrala aspekter:

1. Secure by design

• Säkerhet ska vara inbyggd från början, inte tillagd i efterhand.
• Exempel: välja säkra standardkonfigurationer, minimera attackytan, undvika onödiga funktioner.

1. Secure by default

• Produkten ska vara säker i standardläge utan att användaren måste göra avancerade inställningar.
• Exempel: starka standardinställningar för lösenordspolicy, avstängda onödiga portar.

1. Stödperiod (support period)

• Tillverkaren måste definiera en stödperiod under vilken produkten får:
• Säkerhetsuppdateringar
• Sårbarhetshantering (identifiering, bedömning, patchning)
• Denna period ska vara rimlig i förhållande till produktens förväntade livslängd och användningsområde.

1. Livscykelperspektiv

• Riskbedömningen ska inte bara se på lanseringsögonblicket, utan på:
• Förväntad användningstid
• Möjliga förändringar i hotbilden
• Uppdaterings- och patchstrategi

1. Konsekvens för designbeslut

• Du måste designa uppdateringsmekanismen från början (säker uppdatering, signering, rollback-skydd).
• Du måste planera för resurser (lagring, bandbredd, CPU) så att säkerhetsuppdateringar faktiskt går att distribuera under hela stödperioden.

> Nyckelidé: En produkt som inte kan uppdateras säkert under rimlig tid uppfyller typiskt inte CRA:s krav på säker design och livscykelhantering.

Steg 6: Snabbkontroll – Säker design och stödperiod

Testa din förståelse av kopplingen mellan säker design och stödperiod.

Steg 7: Teknisk dokumentation – översiktlig koppling till artikel 31 och bilaga VII

Även om vi går djupare in på teknisk dokumentation i senare moduler, behöver du redan nu förstå hur riskbedömning och designbeslut ska speglas i dokumentationen.

Enligt artikel 31 och bilaga VII ska den tekniska dokumentationen bland annat innehålla:

1. Allmän beskrivning av produkten

• Funktion, avsedda användningsområden, miljöer där den används.

1. Cybersäkerhetsriskbedömning

• Metod som använts (t.ex. ISO 14971-inspirerad, ISO/IEC 27005, egen metodik)
• Identifierade risker, deras klassning och hur de hanterats.

1. Beskrivning av design- och utvecklingsbeslut

• Arkitekturöversikt (komponenter, gränssnitt, kommunikationsvägar)
• Centrala säkerhetsfunktioner (autentisering, auktorisation, kryptering, loggning, uppdateringsmekanism)
• Hur dessa funktioner svarar mot krav i bilaga I.

1. Information om stödperiod och uppdateringsstrategi

• Hur länge produkten ska få säkerhetsuppdateringar.
• Hur uppdateringar distribueras och verifieras.

1. Spårbarhet

• Koppling mellan: krav i bilaga I → identifierade risker → genomförda åtgärder → testning/verifiering.

> Praktiskt råd: Tänk redan vid första riskworkshopen på hur du ska kunna visa detta i dokumentationen. Det sparar mycket arbete jämfört med att “skriva ikapp” i slutet.

Steg 8: Strukturera din dokumentation – kort övning

Anta att du är projektledare för en ny uppkopplad medicinteknisk mätare för hemmabruk (t.ex. blodtrycksmätare med app).

Uppgift: Skissa (mentalt eller på papper) på en enkel innehållsförteckning för den del av den tekniska dokumentationen som rör cybersäkerhet.

Försök få med:

1. Avsnitt för produktbeskrivning och avsett användningsområde.
2. Avsnitt för cybersäkerhetsriskbedömning.
3. Avsnitt för säker design och arkitektur.
4. Avsnitt för stödperiod och uppdateringsstrategi.
5. Avsnitt för spårbarhet mot bilaga I.

Fundera:

• Var i strukturen skulle du placera referenser till standarder (t.ex. EN/ISO-standarder för informationssäkerhet eller medicinteknik)?
• Hur skulle du märka upp dokumentet så att en granskare lätt ser kopplingen artikel 6 ↔ bilaga I ↔ riskbedömning?

Steg 9: Sambandet riskbedömning – teknisk dokumentation

Kontrollera att du fångat den centrala logiken mellan riskbedömning och dokumentation.

Steg 10: Begreppsrepetition

Använd korten för att repetera nyckelbegrepp från modulen.