Hvilke systemer forventer NIS2‑kunden testet? Leverancen som udgangspunkt

Et krav om “penetrationstest af jeres systemer” kan læses, som om hele virksomheden skal testes. Reglerne, kravet bygger på, handler dog om kundens sikkerhed og om de risici, jeres leverance udgør for kunden. Udgangspunktet for omfanget er derfor de systemer, kunden er afhængig af, eller som kan påvirke kundens net, data og drift. Det kan være færre systemer end hele jeres miljø, men også andre end dem, I selv ville have valgt.

Det følgende er en måde at finde de systemer på. Kunden kan have sin egen afgrænsning, og den bør I kende, før testen bestilles. Teksten er ikke juridisk rådgivning.

Hvorfor leverancen er udgangspunktet

NIS 2-lovens § 6, stk. 1, handler om de net- og informationssystemer, som den omfattede enhed anvender til sine operationer eller til at levere sine tjenester. Nr. 4 om forsyningskædesikkerhed angår forholdet mellem enheden og dens direkte leverandører. Kravet til jer er altså afledt af kundens behov for at styre risikoen ved jeres leverance.

SAMSIK’s vejledning om foranstaltninger, afsnit 4, siger det tydeligt: procedurerne for leverandørstyring gælder i det omfang, leverandørernes ydelser kan påvirke sikkerheden i de ydelser, der gør enheden omfattet af loven. Vejledningen om anvendelsesområdet, afsnit 8, taler om de risici, som den modtagne leverance udgør. → Kundens risikovurdering

Hvad forordningen siger om komponenter

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for en række digitale udbydere som cloud, datacentre, DNS og administrerede tjenester. Er I selv en sådan udbyder, gælder punkterne for jeres egne systemer. Er I det ikke, kan kunden bruge dem som inspiration til, hvad der kan kræves af jer.

Bilagets punkt 6.5.2, litra b, siger, at sikkerhedstest skal omfatte de komponenter, der i en risikoanalyse er udpeget som relevante for sikker drift. Punkt 5.1.4, litra f, taler om sårbarheder, der udgør en risiko for den omfattede enheds systemer. Begge formuleringer peger på det, der har betydning for kunden, ikke på alt, I ejer.

Det betyder ikke, at omfanget altid bliver lille. En leverandør, der har administratoradgang til kundens net, kan have flere relevante komponenter end en leverandør af et selvstændigt system. Det afgørende er, hvad der kan påvirke kundens sikkerhed, og den vurdering kan pege på systemer, I ikke selv tænker på som en del af leverancen, fx den maskine, jeres teknikere bruger til fjernsupport. → Administrationsværktøjer

Kortlæg det, kunden er afhængig af

En praktisk kortlægning tager udgangspunkt i, hvor jeres leverance møder kunden. Mulige berøringsflader er:

Kundevendte løsninger · portaler og applikationer, kundens medarbejdere eller borgere logger ind på.
Jeres adgang til kunden · supportadgang, fjernvedligeholdelse og de konti, I bruger hos kunden.
Forbindelser · integrationer, API’er og filoverførsler mellem jer og kunden.
Administrationen · de værktøjer, I drifter og overvåger kundens løsning med.
Leveringsvejen · opdateringer og software, I sender ind i kundens miljø.
Data hos jer · de systemer, hvor kundens data opbevares, behandles eller sikkerhedskopieres.
Platforme under jer · hosting og cloud, leverancen kører på.

For hver berøringsflade kan I spørge: hvad sker der hos kunden, hvis den bliver misbrugt? Svaret afgør, hvor tungt den skal vægte i testen. Kortlægningen kan genbruges fra de oplysninger, kunden har bedt om til sit leverandørregister, og den kan genbruges igen over for den næste kunde. → Jeres supportadgang til kunden

Systemer uden direkte forbindelse til kunden

Nogle af jeres systemer har ingen direkte forbindelse til kunden, men kan alligevel påvirke leverancen. Hvis jeres udviklere bruger den samme identitetsløsning til kontoret og til produktionsmiljøet, kan et kompromitteret kontor føre videre til kundens data. Det taler for, at testen også ser på adskillelsen mellem jeres interne net og leverancen, uden at hele kontornettet nødvendigvis skal testes i dybden.

Omvendt kan et regnskabssystem uden forbindelse til leverancen som udgangspunkt holdes ude. Begrundelsen skal blot kunne forklares, hvis kunden spørger. Skriv den derfor ind i testplanen, så den følger med dokumentationen til kunden og ikke kun findes i en mail. → Hele virksomheden eller kun leverancen?

Grænsen mod kundens og andres systemer

Leverancens berøringsflader kan ende hos kunden selv eller hos en tredjepart. Den del af supportadgangen, der ligger i kundens net, er kundens system, og den kan I ikke teste uden kundens tilladelse. Den platform, løsningen kører på, ejes måske af en hostingpartner, som har sine egne regler for test. Kortlægningen bør derfor også vise, hvem der ejer hvert led, så testens omfang kan aftales med de rigtige parter. → Afgrænsning mod kundens eget miljø

Et tænkt eksempel

En leverandør af et system til kommunernes hjemmepleje får et krav om “test af leverandørens IT-miljø”. Leverandøren kortlægger berøringsfladerne: plejepersonalets webadgang, integrationen til kommunens fagsystem, supportadgangen til kommunens servere, administrationsportalen og den cloudplatform, systemet kører på.

Leverandøren foreslår en test af webadgangen, integrationen, administrationsportalen og supportadgangens del hos leverandøren. Adskillelsen mellem kontornettet og produktionsmiljøet tages med i begrænset omfang. Cloudplatformens egen del dækkes af platformens dokumentation, mens leverandørens opsætning testes. Leverandøren sender kortlægningen med som bilag, så kommunen kan se, hvilke dele der er taget med, og hvorfor de øvrige er udeladt. Det gør det også lettere at forklare omfanget, hvis kommunens egen revision eller tilsyn senere spørger til leverandørens test. Kommunen godkender planen og beder om, at den del af supportadgangen, der ligger hos kommunen, tages med i en senere test aftalt med kommunens IT.

Det skal I lade være med

At teste hele virksomheden for at være sikre · omfanget bør følge kundens afhængighed.
At udelade det, der er besværligt · supportadgang og administrationsværktøjer kan være de vigtigste.
At glemme vejene imellem · fælles identiteter kan forbinde systemer, der ser adskilte ud.
At teste kundens systemer uden tilladelse · det kræver kundens skriftlige accept.
At lade afgrænsningen stå uden begrundelse · kunden skal kunne se, hvorfor noget er udeladt.

Hvad kan og ikke kan konkluderes

En test, der er afgrænset til de systemer, kunden er afhængig af, kan vise, hvordan netop de holdt på testtidspunktet. Den siger intet om systemer uden for omfanget, og en god afgrænsning kan ikke gøre et bredt krav i aftalen smallere, hvis kunden ikke er enig. Reglerne giver ikke en liste over systemer, der skal testes. Den liste skal I og kunden nå frem til sammen, ud fra kundens vurdering af jeres leverance. → Integrationer og dataudveksling