Et testprogram over flere år, som kunden kan følge

Hver enkelt penetrationstest giver et billede af ét tidspunkt og ét omfang. En NIS2-kunde, der skal følge op på sine leverandører år efter år, har brug for at se mere: hvilke dele af leverancen der bliver testet hvornår, hvordan testtyperne skifter, og om fundene bliver færre eller mindre alvorlige. Det svar giver et testprogram, der strækker sig over flere år og bliver revideret, når leverancen ændrer sig.

Programmet er ikke et krav, der står ordret i NIS 2-loven. Men det er en praktisk måde at vise kunden, at testene hænger sammen med en risikovurdering. Teksten er ikke juridisk rådgivning.

Hvor ideen om et program kommer fra

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, blandt andre cloud, datacentre og udbydere af administrerede tjenester. Bilagets punkt 6.5.1 kræver en politik og procedurer for sikkerhedstest, punkt 6.5.2 lader risikovurderingen afgøre behov, omfang, hyppighed og type, og punkt 6.5.3 siger, at politikken skal gennemgås med planlagte mellemrum.

ENISA’s tekniske vejledning til forordningen er ikke bindende, men den kan forklare kunders formuleringer. Til punkt 6.5.1 anbefaler den et testprogram, der passer til enhedens størrelse, kompleksitet og modenhed. Til punkt 6.5.2 foreslår den at vælge mellem flere slags test over tid, fx sårbarhedsvurderinger, penetrationstest, kodegennemgang og red teaming.

SAMSIK’s vejledning om foranstaltninger, som henvender sig til alle sektorer under NIS 2-loven, siger i afsnit 6.b, at der bør gennemføres regelmæssige og planlagte tekniske test på tværs af organisationen samt ved væsentlige ændringer. → Kunden vil se jeres testpolitik

Hvad et program bør rumme

Et program, kunden kan følge, kan beskrives på få sider. Det bør som minimum sige:

Områderne · de dele af leverancen, kunden er afhængig af, opdelt efter risiko.
Rytmen · hvilke områder der testes hvert år, og hvilke der skiftes ind over en periode.
Testtyperne · hvornår der bruges penetrationstest, scanning, kodegennemgang eller anden afprøvning.
Udløserne · de ændringer og hændelser, der fremskynder en test uden for planen.
Opfølgningen · hvordan fund lukkes, og hvordan kunden får status.
Revisionen · hvornår programmet selv gennemgås, og hvem der godkender ændringer.

Programmet er ikke en kalender, der kan krydses af. Det er en plan med en begrundelse, der kan ændres, når risikoen gør det. → Testfrekvens efter risiko

Rotation mellem områder og testtyper

Få leverandører har råd til at teste alt hvert år, og det er heller ikke nødvendigt for at vise kunden, at sikkerheden afprøves. Et program over tre år kan fx lade den kundevendte løsning og supportadgangen indgå hvert år, mens integrationer, administrationsværktøjer og udviklingskæden skiftes ind på skift. Scanninger kører imellem, så kendte svagheder ikke venter på næste test.

Skiftet mellem testtyper kan også planlægges. Et år kan fokus være at finde svagheder bredt, et andet år at gå i dybden med rettigheder og adskillelse mellem kunder, og et tredje år kan en kodegennemgang supplere testen af et nyt modul. Variationen giver kunden et bredere billede end tre ens test. → Sårbarhedsscanning eller penetrationstest

Sådan deler I programmet med kunden

Kunden har ikke nødvendigvis brug for hele programmet med alle interne detaljer. Det, kunden kan bruge, er en oversigt over, hvilke dele af kundens leverance programmet dækker, hvornår de testes, og hvordan status bliver rapporteret. Det kan passe ind i kundens årlige opfølgning på leverandører, hvor programmet kan erstatte en række enkeltstående spørgsmål.

Har I flere NIS2-kunder, er programmet også en måde at give dem samme svar. Hver kunde kan få et uddrag, der viser deres del, mens det fælles program ligger fast. Det mindsker risikoen for, at I lover forskellige ting til forskellige kunder. → Flere kunder med forskellige krav

Dele, som andre tester for jer

En leverance kan hvile på en hostingpartner, en cloudplatform eller en driftsleverandør. Programmet bør også sige, hvordan de dele er dækket, selv om I ikke selv bestiller testen. Det kan være platformens egen dokumentation, en rapport fra partnerens test eller en aftale om, at jeres test må omfatte den del, partneren driver for jer.

Det vigtige er, at kunden kan se, hvor jeres ansvar slutter, og hvad I gør for at følge op på resten. Et program, der kun beskriver jeres egen kode, men tier om den platform, kundens data ligger på, efterlader et hul, kunden kan spørge til. Skriv også, hvornår I sidst har fået dokumentation fra partneren, og hvornår I forventer den næste. → Hvem tester hvad i en lagdelt leverance?

Et tænkt eksempel

En leverandør af et system til drift af vandværkers målere har fire forsyningskunder. Hver kunde har bedt om dokumentation for test, men på forskellige tidspunkter og med forskelligt omfang. Leverandøren skriver et program over tre år.

Webportalen, hvor forsyningernes medarbejdere arbejder, testes hvert forår. Forbindelsen til målerne og opdateringskanalen testes i år to, med særlig forsigtighed, fordi driften af anlæggene ikke må forstyrres. Administrationsværktøjet testes i år tre. Ved væsentlige ændringer fremrykkes testen af den berørte del. Hvert efterår sender leverandøren en status til alle fire kunder: hvad der er testet, hvilke fund der er lukket, og hvad der står for tur.

Efter første år viser det sig, at portalen ændres oftere end planlagt. Leverandøren reviderer derfor programmet og indfører en ekstra test efter hver større release. Ændringen begrundes over for kunderne i den samme statusmail.

Det skal I lade være med

At kalde en liste over datoer et program · uden begrundelse i risiko er det blot en kalender.
At skubbe de svære områder til år tre hvert år · rotationen skal faktisk gennemføres.
At lade programmet stå uændret · leverancen ændrer sig, og programmet skal følge med.
At love kunden mere, end programmet rummer · uddraget til kunden skal svare til det, I gør.
At glemme opfølgningen · et program uden status på fund viser ikke udvikling.

Hvad kan og ikke kan konkluderes

Et testprogram viser kunden, at I planlægger afprøvning ud fra risiko og over tid, og at fund følges op. Det viser ikke, at de dele, der endnu ikke er testet, er sikre, og det kan ikke i sig selv opfylde kundens krav, hvis kunden har aftalt noget andet med jer. ENISA’s anbefaling om et program er vejledende. Kunden og kundens myndighed afgør, om kundens samlede tilgang til leverandører er tilstrækkelig. → Kundens løbende opfølgning