Testfrekvens efter risiko: hvorfor NIS2 ikke giver et fast interval

Spørgsmålet “hvor ofte skal vi teste?” har ikke et svar i NIS2-reglerne. De tekster, der handler om sikkerhedstest, lægger hyppigheden på den omfattede enheds risikovurdering og nævner begivenheder, der bør udløse en test, men de sætter ikke et tal på. Kernen er forordning (EU) 2024/2690, bilagets punkt 6.5.2, litra a: behovet for, omfanget af, hyppigheden af og typen af sikkerhedstest fastlægges på grundlag af risikovurderingen.

For en leverandør er det både en frihed og en opgave. Et interval i aftalen er noget, I og kunden vælger, og I bør kunne begrunde det. Teksten er ikke juridisk rådgivning.

Det, kilderne siger om hyppighed

Forordningens punkt 6.5.2, litra a, gælder direkte for de digitale udbydere, forordningen omfatter, og bruges som skabelon af andre. Den knytter hyppighed til risikovurderingen i bilagets punkt 2.1 og nævner hyppighed i samme åndedrag som behov, omfang og type. Ordlyden giver ingen minimumsfrekvens, og den skelner ikke mellem store og små enheder; det gør artikel 2, stk. 2, som beder enhederne tage hensyn til eksponering, størrelse og sandsynligheden for hændelser.

Grundlaget er bemærkningerne til lovens § 6, nr. 6 (lovforslag L 141, s. 92), som taler om at vurdere behovet for tekniske test, ikke om et interval. SAMSIK’s vejledning om foranstaltninger siger, at enheden ud fra en risikovurdering skal definere behovet for og frekvensen af forskellige typer test. Den anbefaler test ved installation, vedligeholdelse og ved opgraderinger eller ændringer, enheden vurderer som væsentlige, og regelmæssige, planlagte test på tværs af organisationen.

ENISA’s vejledning til forordningen, som ikke er bindende, nævner test ved opsætning, efter væsentlige opgraderinger eller ændringer og efter vedligeholdelse, og test af hele enheden med planlagte mellemrum eller ved væsentlige hændelser og ændringer. → ENISA’s tekniske vejledning

Hvor det årlige interval kommer fra

Et kravbilag kan alligevel skrive “årligt”. Det kan have flere forklaringer. Kunden kan have det fra en standard, kunden følger, fra en ældre leverandørpolitik eller fra et ønske om at følge regnskabsåret. ENISA nævner i sin vejledning til punkt 7 om effektivitet, at enheden kan vurdere den samlede effektivitet af alle foranstaltninger årligt, men det er et vejledende eksempel om effektivitetsvurdering, ikke et krav om en årlig penetrationstest.

Et årligt interval er ikke forkert. Det er blot ikke givet af reglerne, og det er derfor rimeligt at spørge, hvad det bygger på, og om det passer til jeres leverance. → Krav om årlig penetrationstest i leverandøraftalen

Det, der bør styre jeres rytme

En risikobaseret hyppighed tager udgangspunkt i forhold, I kan beskrive for kunden:

Ændringstakten · en løsning, der får nye funktioner hver måned, ændrer sig mere mellem to test end en stabil installation.
Eksponeringen · det, der kan nås fra internettet eller fra mange kunder, har en anden risiko end det, der kun bruges internt.
Kundens afhængighed · hvor meget kundens drift eller data afhænger af den del, der testes.
Tidligere fund · mange eller alvorlige fund ved sidste test kan tale for en tættere opfølgning.
Hændelser · en hændelse hos jer eller hos kunden kan være en anledning til at teste igen.

Det betyder også, at forskellige dele af leverancen kan have forskellig rytme. Kundeportalen kan testes oftere end en intern administrationsdel, der sjældent ændres. En sådan opdeling kræver, at I kan forklare grænserne mellem delene, men den gør det lettere at bruge testbudgettet, hvor det giver mest. → Kundens risikovurdering

Begivenheder frem for kalender

Kilderne lægger lige så meget vægt på begivenheder som på faste mellemrum. Test ved idriftsættelse og ved væsentlige ændringer går igen i både SAMSIK’s og ENISA’s tekst. Det kan være mere værd for kunden end en fast dato, fordi testen så ligger, hvor risikoen ændrer sig.

Svagheden ved begivenhedsbaserede test er, at “væsentlig ændring” er et elastisk ord. Uden en definition kan I og kunden være uenige om, hvornår der skulle have været testet. Skriv derfor ind i aftalen, hvad der tæller: fx nye adgangsveje, nye integrationer, skift af platform eller ændringer i den måde, kundens data opbevares på. → Hvad tæller som væsentligt?

Et tænkt eksempel

En leverandør af et system til journalføring i kommunale botilbud skal aftale testfrekvens med en ny kommune. Kommunen foreslår årlig penetrationstest. Leverandøren foreslår i stedet en kombination: en penetrationstest ved idriftsættelse, en ny test ved væsentlige ændringer som defineret i aftalen og mindst én test om året, hvis ingen ændring har udløst en. Dertil sårbarhedsscanninger med faste mellemrum af de dele, kommunens brugere kan nå.

Kommunen får det årlige minimum, den bad om, og samtidig test, hvor risikoen faktisk ændrer sig. Leverandøren får en rytme, der kan begrundes i risiko og genbruges over for andre kommuner.

Undervejs aftaler parterne også, hvem der vurderer, om en ændring er væsentlig. Leverandøren foreslår selv at give besked før hver større release med en kort vurdering, som kommunen kan anfægte. Så ligger initiativet hos den part, der kender ændringen, og kommunen bevarer det sidste ord. → Test ved idriftsættelse af en ny leverance

Mellem testene

Hyppighed handler ikke kun om penetrationstest. Forordningens punkt 6.10.2, litra b, nævner sårbarhedsscanninger med planlagte intervaller, hvor det er relevant. En aftale, der kun beskriver penetrationstestens rytme, siger intet om, hvad der sker i månederne imellem. Kunden kan have et ønske om at vide, at kendte svagheder bliver fundet og håndteret løbende, også når der ikke er en test i gang. → Mellem to penetrationstest

Det skal I lade være med

At skrive, at NIS2 kræver et bestemt interval · det gør reglerne ikke.
At acceptere et interval uden begrundelse · spørg, hvad kunden bygger det på.
At lade “væsentlig ændring” stå udefineret · aftal, hvad der udløser en test.
At give hele leverancen samme rytme · dele med høj risiko kan kræve tættere test.
At glemme de løbende kontroller · scanningerne fylder tiden mellem testene.

Hvad kan og ikke kan konkluderes

Kilderne viser, at hyppigheden skal begrundes i risiko, og at test ved idriftsættelse og væsentlige ændringer anbefales. De viser ikke, at et bestemt interval er tilstrækkeligt eller for meget for jeres leverance. Det beror på kundens vurdering af leverancen og på det, I har skrevet under på. En rytme, I kan begrunde, er lettere at forsvare over for kunden end et tal, der er kopieret fra et andet kravbilag. Kundens myndighed vurderer kundens tilgang, ikke jeres interval. → Et testprogram over flere år