= Dybdeanalyse

Systemlukninger hos PET, Forsvaret og Politiet: Hvad fortæller en weekend-krise om dansk cybersikkerhed?

← Analyser
teknologi 10 min. læsning

Da kritiske sårbarheder i udbredt software tvang PET, Forsvaret og Politiet til at hastelukke systemer en weekend, afslørede det et strukturelt problem: Danmarks sikkerhedsmyndigheder deler leverandørafhængigheder — og når én revne opstår, rammes alle på én gang.

Konklusion

Weekenden hvor PET, Forsvaret og Politiet simultant lukkede systemer ned, var ikke et uheld. Det var konsekvensen af en grundlæggende arkitektonisk sårbarhed: når centrale sikkerhedsmyndigheder bruger den samme software fra de samme leverandører, bliver én kritisk fejl til et systemisk problem. Hændelsen rejser tre presserende spørgsmål — om hastigheden på sikkerhedsopdateringer, om risikoen ved fælles leverandørafhængighed i kritisk infrastruktur, og om Danmark har de rette processer til at håndtere fremtidens sårbarheder.

Nøglepunkter:

  • Tre centrale sikkerhedsmyndigheder lukkede systemer simultant — et tegn på delt teknologisk afhængighed
  • Kritiske sårbarheder klassificeres internationalt på en skala (CVSS), og de højeste scorer kræver øjeblikkelig handling
  • Forskning peger på, at offentlige myndigheder generelt er for langsomme til at patche kendte sårbarheder
  • Fælles leverandørafhængighed skaber systemiske risici, der rækker ud over den enkelte myndighed
  • Der er solid international erfaring at trække på — men den skal omsættes til konkret dansk praksis

Baggrund

I sommeren 2024 blev det offentligt kendt, at PET (Politiets Efterretningstjeneste), Forsvaret og Politiet alle valgte at lukke systemer ned i en og samme weekend. Årsagen var kritiske sårbarheder i udbredt software — software der bruges bredt i den offentlige sektor og hos private virksomheder verden over.

Ingeniørens artikel beskriver hændelsen som en hastebeslutning truffet som reaktion på alvorlige sikkerhedshuller. Myndighederne valgte proaktivt at lukke ned frem for at risikere, at sårbarhederne blev udnyttet af fjendtlige aktører.

Det lyder måske som et tegn på velfungerende sikkerhedskultur. Og det er delvist sandt. Men billedet er mere komplekst.

For at forstå, hvad der egentlig skete, og hvad det betyder, er det nødvendigt at se på tre lag: den tekniske mekanik bag softwaresårbarheder, den organisatoriske udfordring med at patche kritiske systemer hurtigt nok, og den strukturelle risiko der opstår, når mange myndigheder deler de samme teknologiske fundamenter.

Hvad sker der

Softwaresårbarheder er fejl eller svagheder i kode, der kan udnyttes af angribere til at skaffe sig uautoriseret adgang, forstyrre drift eller stjæle data. De klassificeres internationalt efter CVSS — Common Vulnerability Scoring System — en skala fra 0 til 10, hvor scorer på 9,0 og derover betegnes som "kritiske". En kritisk CVSS-score betyder i praksis, at en angriber potentielt kan overtage et system uden brugerinteraktion og uden særlige forudsætninger.

Når en sådan sårbarhed opdages i software, der bruges af mange organisationer på én gang — som tilfældet typisk er med udbredte serverplatforme, netværksudstyr eller samarbejdsværktøjer — opstår der et kapløb med tiden. Producenten skal udvikle og frigive en patch (en rettelse). Brugerne skal installere den. Jo bredere softwaren er udbredt, jo større er risikoen for, at angribere udnytter hullet, inden rettelsen er rullet ud.

Det er præcis denne mekanik, der satte sig igennem hos de danske myndigheder. Ingeniørens artikel beskriver, hvordan PET, Forsvaret og Politiet valgte den mest konservative løsning: at lukke systemerne ned, mens opdateringer blev installeret. Det afspejler en risikovurdering om, at driftstab i en weekend er at foretrække frem for en potentiel sikkerhedsbrist.

Hvilken konkret software der var tale om, fremgår ikke fuldt ud af den tilgængelige rapportering — og det er ikke overraskende. Myndighederne har legitime grunde til ikke at offentliggøre detaljerede oplysninger om, hvilke systemer der kørte hvad, og hvilke huller der præcist blev lukket. Offentliggørelse af sådanne detaljer kan i sig selv give angribere nyttig information.

De centrale spørgsmål

1. Var reaktionen hurtig nok?

Det fremgår ikke præcist af den tilgængelige information, hvor lang tid der gik fra sårbarhedens offentliggørelse til myndighedernes nedlukning. Det er et afgørende spørgsmål — ikke for at placere skyld, men fordi forskningsmæssigt er tidsvinduet mellem offentliggørelse og udnyttelse af kendte sårbarheder dokumenteret som særdeles snævert.

Forskning i trusselsbilledet for kritisk infrastruktur, herunder Nyonyoh (2025), understreger, at angribere — særligt statslige og organiserede kriminelle aktører — aktivt overvåger offentlige sårbarhedsdatabaser og begynder at scanne efter sårbare systemer inden for timer efter offentliggørelse. Det sætter et systemisk pres på offentlige organisationer, der i sagens natur har mere komplekse beslutnings- og godkendelsesprocesser end private virksomheder.

2. Hvad betyder fælles leverandørafhængighed?

Det mest bemærkelsesværdige ved hændelsen er ikke, at én myndighed lukkede systemer. Det er, at tre lukkede på samme tid. Det er et symptom på en strukturel egenskab ved moderne offentlig IT: myndighederne bruger i høj grad den samme software fra de samme leverandører.

Det er i mange tilfælde fornuftigt — standardisering giver stordriftsfordele, letter samarbejde og reducerer kompleksitet. Men det skaber samtidig det, sikkerhedsforskere kalder et "monokulturproblem": en fejl i ét produkt rammer alle brugere af det produkt på én gang.

Aladiyan (2025) peger i sin analyse af cloud-sikkerhed for offentlige myndigheder på, at koncentration af kritisk infrastruktur hos få leverandører skaber systemiske risici, der rækker ud over den enkelte organisations sikkerhedsperimeter. Når staten konsoliderer sin IT-drift omkring et begrænset antal platforme, flyttes risikoen fra det individuelle til det kollektive niveau.

3. Er patchprocesserne gearet til 2024-trusler?

En patch er teknisk set ikke svær at forstå — det er en opdatering der lukker et sikkerhedshul. Men i store organisationer med komplekse systemer er det sjældent simpelt at rulle opdateringer ud. Systemer er afhængige af hinanden. En opdatering af ét modul kan bryde noget andet. Der skal testes. Der skal godkendes. Der skal planlægges nedetid.

I den private sektor har mange virksomheder investeret massivt i automatiserede patch-styringsværktøjer og kontinuerlige test-miljøer, der kan komprimere processen fra uger til timer. I det offentlige — og særligt i myndigheder med klassificerede systemer — er hastighedsforskellen historisk markant.

Goffer, Uddin og Kaur (2025) dokumenterer i deres analyse af AI-understøttet trusselsdetektion, at den gennemsnitlige offentlige organisation bruger væsentlig længere tid på at implementere sikkerhedsrettelser end den gennemsnitlige private virksomhed, og at dette tidsgab er en af de primære årsager til vellykkede angreb mod offentlig infrastruktur.

Analyse

Det der gik rigtigt

Lad os begynde med det positive: Systemlukningen var en proaktiv beslutning. Myndighederne handlede, inden et angreb var dokumenteret. Det er ikke en selvfølge.

Forskning i ransomware og kritisk infrastruktur viser, at mange organisationer — både offentlige og private — historisk har valgt at lade sårbare systemer køre for at undgå driftstab, og derefter betalt en langt højere pris, når angrebet kom. Nyonyoh (2025) beskriver, hvordan beslutningstagere i offentlige organisationer ofte undervurderer sandsynligheden for angreb og overvurderer omkostningen ved proaktive foranstaltninger — et kognitivt bias med potentielt alvorlige konsekvenser.

At PET, Forsvaret og Politiet valgte nedetid over risiko, er i overensstemmelse med best practice.

Det strukturelle problem

Men hændelsen blotlægger noget dybere. Tre myndigheder, der alle er centrale i Danmarks sikkerhedsarkitektur, var sårbare over for den samme fejl på det samme tidspunkt. Det er ikke et spørgsmål om svigtende kompetence — det er en konsekvens af, hvordan moderne offentlig IT er bygget.

Buchyk og Maievskyi (2025) analyserer i deres model for sikkerhedssoftware i kritisk infrastruktur, at valget af teknologiplatforme ikke kun bør baseres på funktionalitet og pris, men også på leverandørdiversificering som et eksplicit sikkerhedskriterium. Argumentet er, at ensartet teknologistak på tværs af kritiske aktører skaber en "enkelt fejlpunkt" (single point of failure) på sektorniveau — selv når de individuelle organisationers sikkerhed i øvrigt er god.

Det er præcis det scenarie, vi ser tegn på her. Spørgsmålet er ikke, om nogen har begået fejl — det er, om den danske stat har en systematisk tilgang til at afveje gevinsten ved teknologisk standardisering mod risikoen ved monokultur.

Patch-cyklusser og beslutningsstrukturer

Et andet centralt problem er selve patchprocessen. I klassificerede miljøer — og PET og Forsvaret opererer i sådanne — er det ikke muligt bare at trykke "opdater" og lade automatikken gøre arbejdet. Opdateringer skal verificeres, testes og godkendes i en kæde, der er designet til at forebygge, at fjendtlige aktører injicerer skadelig kode via falske opdateringer. Det er en reel trussel, og processen er berettiget.

Men den skaber et paradoks: de myndigheder, der har den højeste sikkerhedsklassificering og dermed det største behov for hurtigt at lukke kritiske huller, har også de mest tunge godkendelsesprocesser for at gøre netop det.

Aladiyan (2025) peger på, at AI-baserede sikkerhedsværktøjer i cloud-miljøer potentielt kan komprimere dette tidsgab ved at automatisere dele af test- og verifikationsprocessen — men understreger samtidig, at implementering af sådanne systemer i klassificerede miljøer kræver en grundig risikovurdering i sig selv.

Der er med andre ord ikke en simpel teknisk løsning. Det kræver organisatorisk og politisk prioritering at bygge processer, der er både hurtige og sikre.

Den internationale kontekst

Danmark er ikke alene med dette problem. Tilsvarende hændelser — hvor nationale sikkerhedsmyndigheder har måttet lukke systemer som reaktion på kritiske sårbarheder — er dokumenteret i USA, Storbritannien, Holland og andre NATO-lande.

Det betyder ikke, at problemet er uløseligt. Det betyder, at der er international erfaring at trække på. NIST (National Institute of Standards and Technology) i USA har udviklet rammer for sårbarhedshåndtering — herunder retningslinjer for patch-prioritering baseret på CVSS-score og eksponering — der kan tilpasses til europæiske offentlige organisationer.

Spørgsmålet er, om danske myndigheder systematisk benchmarker deres processer mod disse standarder, og om der er et koordinerende organ, der kan sikre, at erfaringer fra én myndigheds systemlukninger deles og implementeres på tværs af sektoren.

Hvad vi ikke ved

Det er vigtigt at være ærlig om, hvad vi ikke ved.

Vi kender ikke den præcise software, der var involveret. Vi kender ikke det præcise tidsgab mellem sårbarhedens offentliggørelse og myndighedernes reaktion. Vi ved ikke, om sårbarhederne faktisk blev forsøgt udnyttet i perioden før lukningen. Vi ved ikke, hvilke konkrete processer og systemer der var i drift under nedetiden, eller om der var kritiske opgaver, der ikke kunne løses i weekenden.

Alt dette er relevant for en fuldstændig vurdering — og fraværet af disse oplysninger er i sig selv en del af billedet. Det er forventeligt og i vidt omfang berettiget, at sikkerhedsmyndigheder ikke offentliggør detaljerede tekniske oplysninger om deres infrastruktur. Men det begrænser offentlighedens mulighed for at vurdere, om reaktionen var tilstrækkelig.

Konklusion

Systemlukningen hos PET, Forsvaret og Politiet er et konkret eksempel på, hvad forskere og sikkerhedseksperter har advaret om i årevis: kritisk infrastruktur er sårbar, ikke primært fordi dem, der driver den, er inkompetente, men fordi den er bygget på delte teknologifundamenter, der skaber systemiske risici.

Det er positivt, at myndighederne reagerede proaktivt. Men hændelsen bør ikke lukkes med et "systemet virkede". Den bør udløse en grundigere gennemgang af tre ting:

For det første patch-processerne: Er de hurtige nok i en verden, hvor angribere udnytter kendte sårbarheder inden for timer? Og hvis ikke — hvad kræver det at ændre det i klassificerede miljøer?

For det andet leverandørafhængighed: Har Danmark en eksplicit strategi for at undgå monokultur i kritisk sikkerhedsinfrastruktur? Og hvem har ansvaret for at vedligeholde den strategi?

For det tredje koordinering: Når tre myndigheder lukker systemer i samme weekend, er det et tegn på, at de deler risici. Deler de også erfaringer og løsninger systematisk — eller håndterer de hvert sit?

Disse spørgsmål er ikke retoriske. De har svar — og Folketing, minister og myndigheder har et ansvar for at sikre, at de svar bliver fundet og implementeret, inden næste sårbarhed opdages.

Kilder

= Læs vores metodedokument →