Cybersäkerhetsriskbedömning av produkter: Varför är de flesta säkerhetsanalyser till synes korrekta, men i praktiken oanvändbara?

I de allra flesta teknikföretag finns redan en process som kallas cyberriskbedömning. Den tar oftast formen av en omfattande tabell, en komplicerad matris eller ett kalkylark där värden som “low”, “medium” och “high” dominerar. Dokumentet innehåller en lång lista med generiska hot, korta beskrivningar av potentiella sårbarheter samt en uppsättning standardiserade kontrollåtgärder. Formellt sett stämmer allt: dokumentet är komplett, undertecknat av ledningen och säkert arkiverat.

Problemet är att i ingenjörspraktiken förändrar det här dokumentet absolut ingenting.

Det påverkar inte arkitekturen för den produkt som utvecklas. Det styr inte beslut om hur uppdateringar ska levereras. Det förändrar inte modellen för eftermarknadssupport och omprövar inte relationerna med komponentleverantörer. Det är ett dokument som fungerar ur ett compliance-perspektiv, men som är helt irrelevant för verklig produktsäkerhet inom cybersäkerhet. Det beror dock inte på bristande kompetens i ingenjörs- eller säkerhetsteam. Det är ett problem som bottnar i en fundamentalt felaktig utgångspunkt.

De flesta traditionella riskanalyser börjar med frågan: “Vilka hot kan uppstå?”. Samtidigt tvingar EU:s nya, regulatoriska angreppssätt – tydligt i rättsakter som Cyber Resilience Act (CRA), medicinska direktiv (MDR) eller den nya maskinförordningen 2023/1230 – fram ett helt annat perspektiv. Det börjar med frågan:

Under vilka användningsförhållanden kan produkten bli en bärare av risk för användaren, systemet eller marknaden – och kan tillverkaren kontrollera den risken under hela produktens livscykel?

Det är en grundläggande paradigmskiftning. Cyberriskbedömning i produktkontext är inte bara ännu en hotanalys av IT-infrastruktur. Det är inte heller ett penetrationstest eller ett mekaniskt införande av riktlinjerna i ISO 27001. Det är en djupgående analys av både produktens och tillverkarens förmåga att upprätthålla säkerhet över tid, i en verklig driftsmiljö.

Teknisk sårbarhet och produktrisk – en viktig distinktion inom cybersäkerhet

För att riskbedömningen ska sluta vara enbart en administrativ tabell och i stället bli ett ingenjörsmässigt beslutsunderlag måste vi tydligt skilja mellan två begrepp som ofta blandas ihop på marknaden. Kom ihåg: sårbarhet är inte samma sak som produktrisk.

• Teknisk sårbarhet är ett konkret, identifierbart fel i programvara, hårdvarukonfiguration eller själva konstruktionen. Det kan handla om bristfällig datavalidering, ett föråldrat programbibliotek eller en lucka i autentiseringsmekanismen. Sådana fel registreras i databaser som CVE-systemet (Common Vulnerabilities and Exposures). Men det är fortfarande en bedömning på enbart teknisk nivå.
• Produktrisk uppstår först när den nämnda sårbarheten (eller till och med dess tillfälliga frånvaro) sätts in i användningens hårda verklighet.

Den här kontexten omfattar en rad variabler: driftsmiljö (öppet eller isolerat nät), hur produkten integreras med andra system, användarbeteenden, tillgång till säkerhetsuppdateringar (s.k. patch management) samt tillverkarens organisatoriska förmåga att hantera incidenter.

En produkt kan sakna kända sårbarheter på lanseringsdagen och ändå skapa kritisk risk om tillverkaren saknar processer för långsiktigt stöd. Att förstå skillnaden strukturerar hela ingenjörsarbetet. Det är just detta som ligger till grund för ett riskbaserat angreppssätt (risk-based approach). Säkerhetsåtgärder måste vara proportionerliga mot förutsebara missbruksscenarier, inte mot en abstrakt lista från internet.

Säkerhetsparadoxen: När skydd ökar risken i IT och OT

Vid utformning av cybersäkerhet antar man ofta att en ny “hänglås”-åtgärd alltid minskar risken. Praktiken visar att det ibland är precis tvärtom. En åtgärd som införs utan förståelse för sammanhanget skapar nya hotvektorer.

1. Stark autentisering i industriell miljö (OT)

Föreställ dig att man inför multifaktorautentisering (MFA) på en industrimaskin. Ur IT-perspektiv är det ett föredömligt steg, men cybersäkerhet i industriell automation är en helt annan verklighet. I fabriksmiljö går utrustningen 24/7 och serviceinsatser sker under tidspress. När nätet fallerar kan teknikern inte auktorisera en token online. Produktionen står still. Resultatet? En frustrerad kund stänger av funktionen permanent och kringgår därmed skyddet helt. Åtgärden som skulle skydda skapade en betydande operativ risk.

2. Automatiska uppdateringar i medicintekniska produkter (IoMT)

Snabb patchning av sårbarheter minimerar exponeringen för attacker, vilket är standard i IT-världen. Men i medicinteknik kan en tvingad uppdatering mitt under en pågående procedur ändra systemets beteende eller slå ut kommunikationen med sjukhusnätet. I ett sådant fall skapar ett tekniskt skydd en kritisk klinisk och regulatorisk risk (brott mot MDR-certifieringen).

3. Stängning av gränssnitt i konsumentutrustning (IoT)

Tillverkaren tar fysiskt bort lokala diagnostikportar från en smart hem-enhet för att försvåra åtkomst för hackare. I praktiken börjar auktoriserade serviceverkstäder felsöka via instabila gränssnitt utan kryptering, och avancerade användare installerar i stor skala modifierad programvara (custom firmware). Resultatet blir att tillverkaren helt tappar kontrollen över sitt eget ekosystem.

En verklig cyberriskanalys frågar: ”Hur förändras stabiliteten, användbarheten och säkerheten i hela ekosystemet när vi lägger till just den här mekanismen?”.

De 5 vanligaste misstagen i riskanalys av tekniska produkter

När experter på cybersäkerhet granskar processer i företag som lanserar elektronik och mjukvara ser de återkommande mönster.

1. Att kopiera den korporativa IT-modellen till produktvärlden. En produkt är inte ett serverrum. Den fungerar i en okänd miljö, ofta offline, och konfigureras av lekmän. När man applicerar IT-verktyg på produktanalys slutar det med att man missar nyckelfrågor: enhetens livscykel och avsaknaden av tvingande uppdateringar.
2. Analys av abstrakta hot i stället för verkliga scenarier. Att fylla en tabell med fraser som ”obehörig åtkomst” är analytiskt värdelöst. Analysen måste bygga på konkreta förutsättningar: Vem? Via vilket gränssnitt? I vilket syfte? Med vilken effekt?
3. Att ignorera produktens livscykel (End-of-Life). Riskanalysen handlar oftast om lanseringsögonblicket. Samtidigt ökar risken över tid – open-source-bibliotek åldras och komponentleverantörer avslutar support. Utan att ta hänsyn till en förvaltningsmodell blir analysen missvisande.
4. Isolering från utvecklingsteamet (R&D). Att behandla riskbedömning som en checklista inför en revision är en rak väg mot katastrof. Resultaten måste tillbaka till ingenjörerna som tydliga arkitekturkrav (Secure by Design).
5. Teknikfetischism på bekostnad av processer. Företag investerar enorma summor i avancerad kryptografi, men vet inte vem i organisationen som ansvarar för att släppa en säkerhetskorrigering (patch) efter att en forskare rapporterat en sårbarhet (Vulnerability Disclosure Program).

Hur genomför man en analys i linje med Cyber Resilience Act? 7 ingenjörsmässiga steg

Cyberriskbedömning måste sluta vara en byråkratisk börda. Nedan följer en marknadsnära operativ modell i linje med EU:s angreppssätt (bl.a. kraven i CRA).

1. Definiera produktens gränser. Produkten är inte bara hårdvara. Den omfattar även mobilapp, moln, OTA-servrar och API-gränssnitt.
2. Beskriv den brutala verkligheten i användningsmiljön. Beskriv inte en laboratoriemiljö. Svara på frågor om faktisk internetanslutning, användarnas kompetens och möjligheterna till fysisk åtkomst till enheten.
3. Identifiera missbruksscenarier (Threat Modeling). Välj bort generiska listor. Använd beprövade ingenjörsmetoder och verktyg för riskuppskattning för att fokusera på precisa attackvektorer anpassade till din bransch.
4. Kvantifiera icke-finansiella konsekvenser. Bedöm risken för produktionsstopp, hot mot hälsa eller bristande uppfyllelse av regulatoriska skyldigheter.
5. Ställ frågan om kontroll. Kan du som tillverkare förebygga, upptäcka och snabbt reagera på det identifierade missbruksscenariot?
6. Utforma proportionerliga skyddsmekanismer. Beslut om kryptering eller nätverksseparering måste följa direkt av svaren från de föregående stegen.
7. Utforma en förvaltningsprocess (Lifecycle). Dokumentera policy för leverans av säkerhetspatchar, supportperiod samt kommunikationskanaler med kunden.

Sammanfattning: Vad ska finnas kvar efter en gedigen riskbedömning?

Slutprodukten av en korrekt riskbedömning av produktens cybersäkerhet ska aldrig vara en texttät dikt för revisorn. Arbetet måste resultera i konkreta artefakter: en tydlig karta över systemgränserna, tydliga arkitekturbeslut i R&D, en godkänd budget för uppdateringspolicy samt ett sammanhängande revisionsspår som visar efterlevnad av EU-direktiv.

En tekniskt mogen organisation frågar inte längre: ”Är vi 100% säkra?”. I stället frågar den: ”Var exakt är vi exponerade och kan vi hantera det över tid?”.

Är din produkt redo för nya regler?

Säkerhet är en process, inte ett engångscertifikat. Om du inte vill att riskbedömningen i ditt företag bara ska bli “pappersarbete” är det värt att arbeta proaktivt. Se hur du i praktiken förbereder en produkt för Cyber Resilience Act (CRA) under åren 2026-2027, innan officiella harmoniserade standarder finns på plats.