Fra effektivitetskrav til testplan: kobl testen til en bestemt foranstaltning

Et krav som “leverandøren skal dokumentere effektiviteten af sine sikkerhedsforanstaltninger” kan ikke testes, som det står. Det skal først oversættes til noget konkret: hvilken foranstaltning, i hvilket system, og hvilket spørgsmål testen skal svare på. Grundlaget er, at både NIS 2-loven og forordning (EU) 2024/2690 knytter test til en vurdering af foranstaltninger, ikke til systemer i almindelighed.

En testplan, der er bygget sådan, er lettere for kunden at godkende, fordi den viser sammenhængen mellem kravet og testen. Den gør det også lettere at forklare bagefter, hvad resultatet betyder. Teksten er ikke juridisk rådgivning.

Hvorfor en plan og ikke bare en bestilling

Bestiller I en penetrationstest af “hele løsningen”, får I en rapport om de fund, testeren nåede at gøre. Rapporten kan være grundig og alligevel ikke svare på det, kunden spurgte om. Kunden får til gengæld svært ved at se, hvilken af kundens bekymringer rapporten svarer på. En plan, der starter i foranstaltningerne, vender det om: Testen designes til at give svar på bestemte spørgsmål, og rapporten kan læses op imod dem.

Forordningens bilag punkt 6.5.2, litra b, peger i samme retning for de udbydere, den gælder for. Test skal udføres efter en dokumenteret metode, der omfatter de komponenter, en risikoanalyse har udpeget som relevante for sikker drift. Komponenterne vælges altså ud fra risiko, ikke ud fra hvad der er nemt at teste. → Effektivitet af foranstaltninger

Tre spørgsmål til hver linje i planen

Hver linje i planen bør kunne besvare tre spørgsmål:

Hvilken foranstaltning · fx multifaktorlogin, adskillelse mellem kunder eller kontrol med leverandørens fjernadgang. Henvis gerne til kundens egen formulering eller til lovens § 6, stk. 1.
Hvilket system eller hvilken adgangsvej · den konkrete del af leverancen, hvor foranstaltningen skal virke.
Hvilket spørgsmål · det, kunden vil vide, formuleret så testen kan give et ja, et nej eller et “delvist”.

Et eksempel på et spørgsmål: “Kan en bruger hos én kunde se data, der tilhører en anden kunde?” Det er præcist, det kan afprøves, og svaret kan bruges direkte i kundens vurdering.

Fra spørgsmål til testtype

Når spørgsmålet er klart, bliver valget af testtype lettere. Nogle spørgsmål kræver en penetrationstest, fordi de handler om, hvad en angriber kan nå. Andre besvares bedre ved en gennemgang af opsætningen eller ved en sårbarhedsscanning, fordi de handler om, hvorvidt noget er sat op som aftalt. Atter andre kan slet ikke besvares af en test, fx om en procedure følges. → Sårbarhedsscanning eller penetrationstest

Forordningens punkt 7.2 giver en nyttig skabelon til resten af planen. Den nævner, hvad der skal måles, med hvilken metode, hvornår, hvem der måler, hvornår resultaterne vurderes, og hvem der vurderer dem. Bruger I de samme overskrifter, kan kunden genkende strukturen fra sit eget arbejde.

Et tænkt eksempel

En leverandør af et vagtplansystem til en kommune får kravet om at dokumentere effektiviteten. Leverandøren sender en plan med fire linjer:

Multifaktorlogin · på administrationsdelen og kundens brugerlogin. Spørgsmål: kræves anden faktor på alle adgangsveje, der er aftalt? Testtype: penetrationstest. → Multifaktorlogin som NIS2-foranstaltning
Adskillelse mellem kunder · i den fælles database og brugerfladen. Spørgsmål: kan én kommunes brugere nå en anden kommunes data? Testtype: penetrationstest med konti i to testkunder.
Leverandørens supportadgang · til kommunens installation. Spørgsmål: er adgangen begrænset til de aftalte personer og tidsrum? Testtype: gennemgang af opsætning og log. → Jeres supportadgang til kunden
Rettelse af sårbarheder · i løsningens komponenter. Spørgsmål: bliver kendte sårbarheder fundet og håndteret? Testtype: sårbarhedsscanning med faste mellemrum og en log over rettelser.

For hver linje står, hvornår den udføres, hvem der står for den, og hvordan resultatet afleveres. Kommunen kan godkende planen, bede om ændringer eller tilføje en linje. Uanset hvad har begge parter nu et fælles grundlag. Og når testen er udført, kan leverandøren svare linje for linje i stedet for at sende en rapport, kommunen selv skal oversætte.

Det, planen også skal sige

En god plan siger ikke kun, hvad der testes, men også:

Hvad der ikke testes · og hvorfor, så kunden ikke tror, at alt er dækket.
Forudsætninger · testkonti, testmiljø eller produktion, og tilladelse fra parter, der ejer en del af systemet.
Tidspunkt og varighed · især hvis testen kan påvirke drift.
Dokumentation · type, omfang, tidspunkt og resultater for hver test. → Type, omfang, tidspunkt og resultat
Opfølgning · hvad der sker med fund, og hvornår linjen vurderes igen.

Når planen skal bruges over for flere kunder

Har I flere NIS2-kunder, er det fristende at lave én plan til alle. Det kan godt lade sig gøre, hvis planens linjer bygger på de foranstaltninger, der er fælles for leverancen, fx adskillelse mellem kunder eller kontrol med jeres egen adgang. Kundespecifikke linjer kan så lægges til for den enkelte kunde, fx en integration, kun én kunde bruger.

Fordelen er, at hver kunde kan se, hvilke linjer der gælder netop dem, og at I ikke skal teste den samme del flere gange inden for kort tid. Ulempen er, at en fælles plan let bliver for generel. Bevar derfor de tre spørgsmål for hver linje, også de fælles. Et spørgsmål, som ingen kunde har stillet, hører ikke hjemme i planen, og en kunde, der ikke kan finde sit eget spørgsmål, vil sandsynligvis bede om en særskilt test. → Flere NIS2-kunder med forskellige krav

Det skal I lade være med

At starte med testtypen · start med foranstaltningen og spørgsmålet.
At skrive spørgsmål, der ikke kan besvares · “er løsningen sikker?” kan ingen test svare på.
At lade planen dække alt · den skal dække det, kunden er afhængig af.
At glemme de linjer, en test ikke kan besvare · skriv dem med og angiv en anden metode.
At sende planen uden en ansvarlig · hver linje bør have en ejer hos jer.

Hvad kan og ikke kan konkluderes

En testplan bygget på foranstaltninger gør det tydeligt, hvad testresultatet kan bruges til. Den sikrer ikke, at kunden godkender den, og den sikrer ikke, at testen finder alt. Resultatet gælder de spørgsmål, planen stillede, i det omfang og på det tidspunkt, testen blev udført. Spørgsmål, der ikke stod i planen, er ikke besvaret, selv om testen ikke fandt noget. Hvis kunden har et uklart krav, kan planen være det bedste svar. → Når kravet er uklart