Cybersikkerhedsvurdering af produkter: Hvorfor er de fleste sikkerhedsanalyser tilsyneladende korrekte, men i praksis ubrugelige?

I langt de fleste teknologivirksomheder findes der allerede en proces, som kaldes cyberrisikovurdering. Den har typisk form af en omfattende tabel, en kompleks matrix eller et regneark, hvor værdierne “low”, “medium” og “high” dominerer. Dokumentet rummer en lang liste af generiske trusler, korte beskrivelser af potentielle sårbarheder samt et sæt standardkontroller. Formelt set er alt i orden: dokumentet er komplet, underskrevet af ledelsen og arkiveret forsvarligt.

Problemet er, at i ingeniørpraksis ændrer dette dokument absolut ingenting.

Det påvirker ikke arkitekturen for det produkt, der udvikles. Det er ikke styrende for beslutninger om, hvordan opdateringer leveres. Det ændrer ikke modellen for support efter salg og revurderer ikke relationerne til leverandører af komponenter. Det er et dokument, der er korrekt i forhold til compliance, men fuldstændig ligegyldigt for den reelle cybersikkerhed i produkter. Det skyldes dog ikke manglende kompetencer i ingeniør- eller security-teams. Det er et problem, der udspringer af et grundlæggende forkert udgangspunkt.

De fleste traditionelle risikovurderinger starter med spørgsmålet: “Hvilke trusler kan opstå?”. Den nye, regulatoriske tilgang i EU – tydeligt afspejlet i retsakter som Cyber Resilience Act (CRA), de medicinske direktiver (MDR) eller den nye maskinforordning 2023/1230 – tvinger et helt andet perspektiv igennem. Det begynder med spørgsmålet:

Under hvilke anvendelsesforhold kan produktet blive en bærer af risiko for brugeren, systemet eller markedet – og er producenten i stand til at kontrollere denne risiko gennem hele produktets livscyklus?

Det er et grundlæggende paradigmeskifte. Cyberrisikovurdering i en produktkontekst er ikke blot endnu en trusselsanalyse af IT-infrastruktur. Det er heller ikke en penetrationstest eller en mekanisk implementering af retningslinjerne i ISO 27001. Det er en dybdegående analyse af både produktets og producentens evne til at opretholde sikkerhed over tid i et reelt driftsmiljø.

Teknisk sårbarhed vs. produktrisiko – en vigtig sondring i cybersikkerhed

Hvis risikovurderingen skal holde op med blot at være en administrativ tabel og i stedet blive et ingeniørmæssigt beslutningsværktøj, skal vi skarpt adskille to begreber, som alt for ofte forveksles på markedet. Husk: en sårbarhed er ikke det samme som produktrisiko.

• Teknisk sårbarhed er en konkret, identificerbar fejl i software, hardwarekonfiguration eller selve designet. Det kan være mangelfuld datavalidering, et forældet softwarebibliotek eller en svaghed i autentificeringsmekanismen. Sådanne fejl registreres i databaser som CVE-systemet (Common Vulnerabilities and Exposures). Men det er stadig en vurdering, der udelukkende ligger på det tekniske niveau.
• Produktrisiko opstår først, når den nævnte sårbarhed (eller endda dens midlertidige fravær) placeres i de hårde realiteter omkring anvendelsen.

Denne kontekst omfatter en række variabler: driftsmiljøet (åbent netværk eller isoleret), måden produktet integreres med andre systemer på, brugernes adfærd, tilgængeligheden af sikkerhedsopdateringer (såkaldt patch management) samt producentens organisatoriske evne til at reagere på hændelser.

Et produkt kan være uden kendte sårbarheder på lanceringsdagen og alligevel skabe kritisk risiko, hvis producenten ikke har processer for langsigtet support. At forstå denne forskel skaber struktur i hele det ingeniørmæssige arbejde. Det er netop her, den risikobaserede tilgang (risk-based approach) har sit fundament. Sikkerhedsforanstaltninger skal stå mål med de forudsigelige misbrugsscenarier – ikke med en abstrakt liste fra internettet.

Sikkerhedsparadokset: Når beskyttelse øger risikoen i IT og OT

I design af cybersikkerhed antager man ofte, at en ny “hængelås” altid reducerer risikoen. Erfaringen viser, at det nogle gange er præcis omvendt. En foranstaltning, der implementeres uden forståelse for konteksten, skaber nye angrebsvektorer.

1. Stærk autentificering i et industrielt miljø (OT)

Forestil dig, at man indfører multifaktorautentificering (MFA) på en industrimaskine. Set fra et IT-perspektiv er det et forbilledligt skridt, men cybersikkerhed i industriel automation er en helt anden virkelighed. I et fabriksmiljø kører udstyret 24/7, og serviceindgreb sker under tidspres. Når netværket svigter, kan teknikeren ikke autorisere tokenet online. Produktionen står stille. Resultatet? En frustreret kunde slår mekanismen permanent fra og omgår dermed sikkerheden fuldstændigt. En foranstaltning, der skulle beskytte, skabte en massiv operationel risiko.

2. Automatiske opdateringer i medicinsk udstyr (IoMT)

Hurtig udbedring af sårbarheder minimerer eksponeringen for angreb, og i IT-verdenen er det standard. Men i medicinsk udstyr kan en tvungen opdatering midt i en procedure ændre systemets adfærd eller ødelægge kommunikationen med hospitalets netværk. I dette tilfælde skaber den teknologiske beskyttelse en kritisk klinisk og regulatorisk risiko (brud på MDR-certificeringen).

3. Lukning af grænseflader i forbrugerudstyr (IoT)

Producenten fjerner fysisk lokale diagnoseporte fra en smart home-enhed for at gøre det sværere for hackere at få adgang. I praksis begynder autoriserede servicepartnere at fejlfinde via ustabile grænseflader uden kryptering, og avancerede brugere installerer i stor skala modificeret software (custom firmware). Resultatet er, at producenten mister den fulde kontrol over sit eget økosystem.

En reel cyberrisikoanalyse spørger: „Hvordan vil stabiliteten, anvendeligheden og sikkerheden i hele økosystemet ændre sig, når vi tilføjer netop denne mekanisme?”.

De 5 mest almindelige fejl i risikoanalyse af teknologiprodukter

Når eksperter i cybersikkerhed vurderer processer i virksomheder, der bringer elektronik og software på markedet, ser de tilbagevendende mønstre.

1. Kopiering af den korporative IT-model til produktverdenen. Et produkt er ikke et datacenter. Det fungerer i et ukendt miljø, ofte offline, og konfigureres af ikke-specialister. Når man anvender IT-værktøjer til produktanalyse, ender man med at overse nøgleproblemer: enhedens livscyklus og fraværet af tvungne opdateringer.
2. Analyse af abstrakte trusler i stedet for reelle scenarier. At skrive fraser som “uautoriseret adgang” ind i en tabel er analytisk værdiløst. Analysen skal bygge på konkrete forhold: Hvem? Via hvilken grænseflade? Med hvilket formål? Med hvilken effekt?
3. Ignorering af produktets livscyklus (End-of-Life). Risikoanalysen handler typisk om lanceringstidspunktet. I mellemtiden vokser risikoen over tid – open source-biblioteker ældes, og komponentleverandører afslutter support. Uden at indregne en vedligeholdelsesmodel bliver analysen misvisende.
4. Isolation fra udviklingsteamet (R&D). At behandle risikovurdering som en tjekliste før en audit er en direkte vej til katastrofe. Resultaterne skal tilbage til ingeniørerne som hårde arkitekturkrav (Secure by Design).
5. Teknologifetichisme på bekostning af procedurer. Virksomheder investerer formuer i avanceret kryptografi, men ved ikke, hvem i organisationen der har ansvaret for at udsende en sikkerhedsrettelse (patch), når en forsker indrapporterer en sårbarhed (Vulnerability Disclosure Program).

Hvordan gennemfører man en analyse i overensstemmelse med Cyber Resilience Act? 7 ingeniørtrin

Cyberrisikovurdering skal holde op med at være en bureaukratisk byrde. Nedenfor er en markedspraksis, der er på linje med EU-tilgangen (bl.a. CRA-kravene), som operationel model.

1. Definér produktets afgrænsning. Produktet er ikke kun hardware. Det omfatter også mobilapp, cloud, OTA-servere og API-grænseflader.
2. Beskriv den barske virkelighed i brugsmiljøet. Beskriv ikke et laboratoriemiljø. Besvar spørgsmål om den faktiske internetforbindelse, brugernes kompetencer og mulighederne for fysisk adgang til enheden.
3. Identificér misbrugsscenarier (Threat Modeling). Drop generiske lister. Brug gennemprøvede ingeniørmetoder og -værktøjer til risikovurdering for at fokusere på præcise angrebsvektorer tilpasset din branche.
4. Kvantificér ikke-finansielle konsekvenser. Vurdér risikoen for produktionsstop, sundhedsfare eller brud på regulatoriske forpligtelser.
5. Stil spørgsmålet om kontrol. Kan du som producent forebygge, opdage og reagere hurtigt på det identificerede misbrugsscenarie?
6. Design proportionale beskyttelsesmekanismer. Beslutninger om kryptering eller netværksseparation skal følge direkte af svarene fra de foregående trin.
7. Design en vedligeholdelsesproces (Lifecycle). Dokumentér politik for levering af sikkerhedsrettelser, supportperiode samt kommunikationskanaler til kunden.

Opsummering: Hvad bør stå tilbage efter en grundig risikovurdering?

Slutproduktet af en korrekt cybersikkerhedsrisikovurdering af et produkt bør aldrig være et teksttungt digt til auditøren. Arbejdet skal munde ud i håndgribelige artefakter: et klart kort over systemets afgrænsning, faste arkitekturbeslutninger i R&D, et godkendt budget til opdateringspolitikken samt et sammenhængende auditspor, der dokumenterer overensstemmelse med EU-direktiver.

En teknologisk moden organisation spørger ikke længere: „Er vi 100 % sikre?”. I stedet spørger den: „Hvor er vi helt konkret eksponerede, og kan vi styre det over tid?”.

Er dit produkt klar til de nye reguleringer?

Sikkerhed er en proces – ikke et engangscertifikat. Hvis du ikke ønsker, at risikovurderingen i din virksomhed kun bliver til “papirarbejde”, kan det betale sig at arbejde proaktivt. Se, hvordan du i praksis forbereder dit produkt på Cyber Resilience Act (CRA) i årene 2026-2027, før de officielle harmoniserede standarder foreligger.