NIS2-pentest

Mellem to penetrationstest: hvad kunden kan forvente af løbende kontroller

Mellem to penetrationstest: hvad kunden kan forvente af løbende kontroller

Mellem to penetrationstest kan der gå måneder, og i den tid ændrer leverancen sig, nye sårbarheder bliver kendt, og opdateringer bliver installeret eller udskudt. En NIS2-kunde kan derfor spørge, hvad I gør i mellemtiden. Svaret ligger i de løbende kontroller: overvågning af sårbarhedsoplysninger, scanninger med planlagte mellemrum, opdateringer inden for en rimelig tid og en procedure for de fund, der ikke kan vente.

Kontrollerne erstatter ikke testen, og testen erstatter ikke dem. De svarer på forskellige spørgsmål. Teksten er ikke juridisk rådgivning.

Hvad reglerne nævner mellem testene

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for de digitale udbydere, den nævner, fx udbydere af cloud, datacentre og administrerede tjenester. Andre NIS2-kunder kan bruge den som opslagsværk, når de formulerer leverandørkrav. Bilagets punkt 6.10.2 siger, at enheden skal:

  • Overvåge oplysninger · om sårbarheder gennem passende kanaler, fx meddelelser fra CSIRT’er, myndigheder eller leverandører (litra a).
  • Scanne · med planlagte intervaller, hvor det er relevant, og dokumentere resultaterne (litra b).
  • Afhjælpe · sårbarheder af kritisk betydning for driften uden unødig forsinkelse (litra c).
  • Forbinde håndteringen · med ændringsstyring, patchstyring, risikostyring og hændelseshåndtering (litra d).

Punkt 6.6.1 tilføjer, at sikkerhedspatches skal anvendes inden for en rimelig periode, og punkt 6.10.3 siger, at en sårbarhed enten skal have en plan for afhjælpning eller en dokumenteret begrundelse for, at den ikke kræver det. Forordningen sætter ikke tal på intervallerne.

Hvorfor kunden spørger jer

Punkt 5.1.4, litra f, nævner en forpligtelse for leverandører til at håndtere sårbarheder, der udgør en risiko for kundens systemer, som noget, der kan stå i kontrakten. Punkt 5.1.7, litra a, beder kunden overvåge rapporter om serviceleveranceaftalerne, hvor det er relevant. ENISA’s tekniske vejledning, som ikke er bindende, anbefaler at sikre, at leverandører og tjenesteudbydere rapporterer sårbarheder i deres systemer, produkter eller tjenester, der udgør en risiko for enheden.

For kunden er det også et spørgsmål om timing. En sårbarhed, der bliver offentliggjort dagen efter jeres test, står ikke i rapporten, men den kan ramme kundens data længe før næste test. Derfor vil nogle kunder hellere høre om jeres rutine end se endnu en rapport.

Kundens spørgsmål om løbende kontroller kan altså være en del af kundens opfølgning på leverandøraftalen, ikke en mistillid til testen. → Pligt til at håndtere sårbarheder i aftalen

Det, en løbende kontrol kan og ikke kan

En scanning kan finde kendte svagheder og forkerte opsætninger, som allerede er beskrevet i offentlige kataloger. Den kan køre med korte mellemrum og afsløre, at en opdatering mangler, kort efter at sårbarheden er offentliggjort. Den kan ikke vurdere, om en kombination af små svagheder åbner en vej ind, eller om rettighedsmodellen i jeres løsning kan misbruges. Det er netop det, en penetrationstest er bedre til.

Overvågning af sårbarhedsoplysninger kan fange problemer i tredjepartskomponenter, før de bliver udnyttet. Den kræver, at I ved, hvilke komponenter der indgår i leverancen. Uden en opdateret oversigt over komponenter er overvågningen blind for netop de dele, der ikke står på listen. → Sårbarhedsscanning eller penetrationstest

Det, kunden kan forvente

Hvad der er rimeligt, afhænger af aftalen og af kundens vurdering af jeres leverance. Som udgangspunkt for en drøftelse kan I tilbyde kunden indblik i:

  • Scanningsrytmen · hvilke dele af leverancen der scannes, og med hvilket mellemrum.
  • Kilderne til sårbarhedsoplysninger · hvordan I holder jer orienteret om komponenter, I bruger.
  • Opdateringsprocessen · hvordan I vurderer og installerer opdateringer, og hvordan undtagelser begrundes.
  • Kritiske fund · hvordan I håndterer en kritisk sårbarhed, og hvornår kunden får besked.
  • Statusrapporten · en periodisk oversigt over åbne og lukkede fund fra både scanninger og test.

ENISA’s vejledning nævner også scanninger efter væsentlige hændelser eller ændringer, ikke kun efter kalenderen. Det giver mening at koble en ekstra scanning til jeres ændringsstyring, så en ny version eller en ny adgangsvej bliver kontrolleret, inden den har været i drift længe. Kunden kan så se, at kontrollerne følger leverancen og ikke kun årets gang.

Pas på med at love frister, I ikke kan holde. Hvis kunden har en frist i aftalen, skal jeres proces kunne leve op til den, også i en ferieuge. → Kritiske fund skal afhjælpes

Når scanning ikke passer til miljøet

Ikke alle dele af en leverance tåler aktive scanninger. SAMSIK’s vejledning om foranstaltninger advarer i afsnit 6.b om, at aktive scanninger af OT-miljøer kan medføre forstyrrelser eller nedetid. Leverer I udstyr eller software til produktion, forsyning eller anlægsdrift, skal kontrollerne mellem testene tilpasses: fx overvågning af sårbarhedsoplysninger for de konkrete komponenter, gennemgang af opsætninger og aftalte servicevinduer. → Produktionsudstyr og OT

Et tænkt eksempel

En leverandør af et lagerstyringssystem til en fødevareproducent har en årlig penetrationstest i aftalen. Ved det kvartalsvise statusmøde spørger producenten, hvad der sker mellem testene.

Leverandøren viser en oversigt: de dele af systemet, der kan nås udefra, scannes hver måned, og resultaterne gemmes. Komponentlisten gennemgås mod offentlige sårbarhedsoplysninger hver uge. To fund fra seneste scanning er lukket, ét er udskudt med en begrundelse, og producenten får en kort status hvert kvartal. Producenten beder om, at en kritisk sårbarhed i en komponent, systemet bruger, fremover meldes inden for den frist, der allerede står i aftalen, også selv om den ikke er udnyttet. Leverandøren tilføjer det til proceduren.

Det skal I lade være med

  • At lade testen stå alene · uden løbende kontroller er rapporten hurtigt forældet.
  • At kalde en scanning for en penetrationstest · de to svarer på forskellige spørgsmål.
  • At scanne uden at følge op · en rapport, ingen læser, er ikke en kontrol.
  • At glemme komponentlisten · overvågning kræver, at I ved, hvad der indgår.
  • At love frister, I ikke kan holde · aftal en proces, der virker i praksis.

Hvad kan og ikke kan konkluderes

Løbende kontroller viser kunden, at kendte svagheder bliver fundet og håndteret mellem testene. De viser ikke, at leverancen kan modstå et målrettet forsøg, og de dækker kun det, scanningerne og overvågningen faktisk omfatter. Sammen med testen giver de et bedre billede end hver for sig. Hvordan kunden vægter dem, afhænger af kundens vurdering af jer. Generel viden om scanning og test står på penetrationtest.dk. → Et testprogram over flere år

Tjekliste til kontrollerne mellem testene

  • ☐ Er det klart, hvilke dele af leverancen der scannes, og hvor ofte?
  • ☐ Har I en opdateret liste over komponenter, der overvåges?
  • ☐ Er der en procedure for kritiske sårbarheder med besked til kunden?
  • ☐ Er undtagelser fra opdateringer begrundet skriftligt?
  • ☐ Får kunden en periodisk status på åbne og lukkede fund?
  • ☐ Er kontrollerne tilpasset dele, der ikke tåler aktiv scanning?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om NIS2 og penetrationstest

Læs også: Sårbarheder, som andre melder til jer · Fund i tredjepartskomponenter

→ 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

Har en kunde stillet NIS2‑krav?

Fortæl kort, hvad kunden har bedt om, og hvornår kunden skal have svar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.