Sikkerhedstesten

Vi har aldrig haft et sikkerhedsproblem: er det et argument?

Vi har aldrig haft et sikkerhedsproblem: er det et argument?

At virksomheden aldrig har haft et sikkerhedsproblem, er en oplysning om fortiden, ikke en vurdering af, hvordan det står til i dag. Om argumentet holder, afhænger af ét spørgsmål, som ledelsen ikke altid stiller: hvordan ville vi vide det, hvis vi havde haft et? Hvis svaret er, at det formentlig først ville vise sig, når noget gik i stå, siger de rolige år mere om, hvad virksomheden har opdaget, end om hvad der er sket.

Argumentet er forståeligt. En ledelse, der har drevet virksomheden i mange år uden alvorlige hændelser, har grund til at være tilfreds med den måde, tingene er gjort på. Men en god historik er ikke dokumentation, og den kan ikke bruges som svar, når en kunde, en bank eller bestyrelsen spørger, hvordan sikkerheden er undersøgt.

Tre måder at have aldrig haft problemer på

Udsagnet kan dække over tre meget forskellige situationer, og ledelsen kan ikke altid se forskel på dem uden at spørge.

  • Der er ikke sket noget · ingen har forsøgt, eller forsøgene er mislykkedes.
  • Der er sket noget, som ingen har opdaget · en svaghed er udnyttet, uden at det har haft synlige følger endnu.
  • Der er sket noget, som er håndteret uden at nå ledelsen · IT eller leverandøren har løst en mindre hændelse og betragtet det som drift.

Kun den første situation svarer til det, ledelsen forestiller sig. De to andre kan ikke udelukkes ud fra historikken alene, og den tredje betyder, at ledelsens billede kan være mere roligt end virkeligheden.

Fravær af tegn er ikke fravær af svagheder

Den britiske myndighed NCSC skriver i sin vejledning om penetrationstest, at svagheder kan eksistere i lang tid, uden at virksomheden ved det, hvis den ikke undersøger dem. Det er en vigtig pointe for en ledelse, der bygger sin tryghed på, at intet er sket.

En svaghed gør ikke opmærksom på sig selv. Den ligger der, indtil nogen finder den, og den, der finder den først, er ikke nødvendigvis virksomheden selv. Nogle angreb søger bredt efter kendte svagheder i det, der kan nås fra internettet, og rammer, hvor de finder noget. At virksomheden ikke er blevet ramt endnu, kan derfor lige så vel betyde, at ingen har kigget, som at der intet er at finde. → Hvad risikerer vi ved ikke at teste?

Hvad har ændret sig siden de rolige år?

Historikken bliver også mindre værd, jo mere virksomheden har ændret sig. Den IT-opsætning, der gav de rolige år, er måske ikke den, der er i drift i dag.

Tænk på de seneste års ændringer: hjemmearbejde, nye cloudtjenester, flere leverandører med adgang, en ny webshop eller en kundeportal. Hver ændring har åbnet nye veje ind, som ikke fandtes i den periode, historikken bygger på. En tænkt produktionsvirksomhed kan have haft en lukket IT-verden i mange år og så på kort tid fået fjernadgang for leverandører, en portal for forhandlere og et økonomisystem i skyen. Det er stadig den samme virksomhed, men det er ikke den samme risiko. Ledelsen har selv godkendt hver af ændringerne, men ikke nødvendigvis med spørgsmålet om, hvad de betød for den samlede sikkerhed.

Hvorfor argumentet bliver brugt

Ledelsen har ikke nødvendigvis grund til at tvivle på, at der ikke er sket noget. Argumentet kan dukke op, når en test eller en investering i sikkerhed er til diskussion, og der er andre ting, pengene kunne bruges på.

Det er en legitim afvejning. Men den bør træffes på et grundlag, der kan forklares, og “vi har aldrig haft problemer” er ikke et sådant grundlag. Hvis ledelsen vælger ikke at teste, bør det være, fordi den har vurderet risikoen og fundet den acceptabel, ikke fordi historikken har gjort det unødvendigt at tage stilling. Historikken kan heller ikke bruges udadtil. En kunde, der sender et sikkerhedsspørgeskema, kan spørge, hvilke kontroller virksomheden har, og hvornår de sidst er afprøvet. Et svar om, at der aldrig er sket noget, besvarer ikke spørgsmålet og kan få virksomheden til at virke uforberedt. Det samme gælder forsikringen og banken, som vil vide, hvad virksomheden gør, ikke hvad den har været heldig med.

Det samme gælder, hvis argumentet egentlig dækker over en uro for, hvad en test vil vise. → Er det bedre ikke at vide?

Spørgsmål, der giver historikken indhold

I stedet for at afvise argumentet kan ledelsen gøre det brugbart ved at stille nogle opfølgende spørgsmål til IT eller driftsleverandøren.

  1. Hvordan ville vi opdage, hvis nogen havde skaffet sig adgang?
  2. Hvem ser på advarsler og logninger, og hvor ofte når noget op til ledelsen?
  3. Har der været mindre hændelser, som er håndteret uden at blive rapporteret?
  4. Hvornår er sikkerheden sidst undersøgt af nogen uden for den daglige drift?
  5. Hvad er ændret siden da?

Svarene fortæller, om historikken bygger på en virksomhed, der holder øje, eller på en virksomhed, der ikke ville have set noget. Hvis svarene er usikre, er det ikke et tegn på mistillid at bede om mere. → IT siger, at alt er i orden

Det skal I lade være med

  • At bruge historikken som dokumentation · kunder og bestyrelser spørger, hvad der er undersøgt, ikke hvad der er sket.
  • At regne en rolig periode som bevis for, at opsætningen er i orden · svagheder viser sig ikke af sig selv.
  • At se bort fra ændringerne · de rolige år kan stamme fra en anden IT-virkelighed.
  • At antage, at ledelsen ville have hørt om en hændelse · det kræver, at nogen har aftalt, hvornår den skal orienteres.
  • At lade argumentet afslutte diskussionen · brug det som anledning til at spørge videre.

Hvad kan og ikke kan konkluderes

En lang periode uden kendte hændelser kan tyde på, at virksomheden har gjort meget rigtigt, og det er værd at anerkende. Den kan ikke vise, at der ikke findes svagheder, og den kan ikke vise, at ingen har udnyttet dem. En sikkerhedstest kan give et billede af, hvordan de undersøgte dele står i dag, men heller ikke den kan bevise, at der aldrig er sket noget. Hvis ledelsen har mistanke om, at nogen allerede er inde, er det en anden opgave end en almindelig test. → Hvad en test kan svare på

Tjekliste: hvad bygger roen på?

  • ☐ Ved vi, hvordan en hændelse ville blive opdaget?
  • ☐ Er det aftalt, hvornår ledelsen skal orienteres om hændelser?
  • ☐ Kender vi de væsentlige ændringer i IT siden de rolige år?
  • ☐ Er sikkerheden undersøgt af nogen uden for den daglige drift?
  • ☐ Er en beslutning om ikke at teste begrundet i en vurdering af risikoen?

Kilder

  • NCSC (UK), Penetration testing: at svagheder kan eksistere længe uden at blive opdaget, og at test bør ses som en del af den løbende håndtering af svagheder.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til ledelsen

Læs også: Har vi gjort nok? · Testet en gang

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Overvejer ledelsen en sikkerhedstest?

Skriv kort, hvad ledelsen gerne vil have svar på, og hvornår svaret skal bruges. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.