Testvindue hos MSP’en: når mange kunders drift påvirkes samtidig

Når en driftsleverandør lader sin fælles platform teste, er det ikke kun leverandørens egen drift, der er i spil. Alle kunder, der hænger på platformen, kan mærke det, hvis noget går galt. Planlægningen hviler derfor på to ting: de aftaler, I har med kunderne om drift og besked, og de krav til dokumenteret testmetode, som NIS2-kunder og forordning (EU) 2024/2690 lægger op til. Svaret er et testvindue, som kunderne kender, med en klar vej til at stoppe.

Testen af platformen er jeres beslutning, men konsekvenserne er fælles. Teksten er ikke juridisk rådgivning.

Hvorfor testvinduet ikke kun er jeres sag

En test af et enkelt kundemiljø rammer én kunde, som selv har sagt ja. En test af den fælles platform rammer fjernadministration, overvågning, backup og identitetsløsning, som alle kunder er afhængige af. Selv en forsigtig test kan give forsinkelser, låste konti eller alarmer hos kunderne. → Delte platforme hos MSP’en

NIS2-kunder har desuden selv krav om at kunne håndtere hændelser. En uforklaret alarm eller en afbrydelse hos en vigtig leverandør kan sætte kundens egen hændelsesvurdering i gang. Er kunden varslet, kan kunden hurtigt se, at det skyldes en planlagt test. → Fund eller hændelse

Hvad reglerne lægger op til

Forordning 2024/2690 gælder bl.a. udbydere af administrerede tjenester og administrerede sikkerhedstjenester. Bilagets punkt 6.5.2, litra b, siger, at sikkerhedstest udføres efter en dokumenteret testmetode, og litra c, at testens type, omfang, tid og resultater dokumenteres. Punkt 6.4.2 kræver, at ændringer af systemer i drift testes og vurderes for deres mulige virkninger, før de gennemføres.

Punkt 6.4 handler om ændringer, ikke om penetrationstest. Men tankegangen er den samme: en aktivitet, der kan påvirke driften, planlægges, vurderes og dokumenteres. Er I selv omfattet af forordningen, er testvinduet en del af den dokumenterede metode. Er I ikke, kan kunderne stadig spørge efter det samme. → Forordningen og MSP’en

Vælg tidspunktet ud fra kunderne

Det rigtige tidspunkt afhænger af, hvem der bruger platformen hvornår. En kunde med døgndrift har ikke et roligt tidspunkt om natten. En kunde med kontortid kan bedre tåle en forstyrrelse uden for arbejdstid, men så skal der også være folk klar hos jer.

Overvej disse forhold, før testvinduet fastlægges:

Kundernes driftsmønstre · hvilke kunder der har døgndrift, sæsontoppe eller faste kørsler som lønkørsel og fakturering.
Jeres bemanding · at teknikere og en beslutningstager er til stede, mens testen kører.
Planlagt vedligeholdelse · at testen ikke falder sammen med opdateringer, der gør det svært at se årsagen til en fejl.
Kundernes egne aftaler · servicevinduer, I allerede har aftalt, og som kunderne er vant til.

penetrationtest.dk beskriver generelt afvejningen mellem test i og uden for arbejdstid. Her handler det om, at afvejningen skal gå op for flere kunder på én gang.

Et alternativ er at dele testen op. Dele af platformen, som kun nogle kunder bruger, kan testes i hvert sit vindue, så færre kunder er berørt ad gangen. Det giver flere vinduer at varsle, men hver varsling bliver mere præcis, og en forstyrrelse rammer færre. Fælles dele som identitetsløsning og fjernadministration kan ikke deles op på samme måde og kræver derfor den bredeste varsling.

Varsling af kunderne

En varsling til kunderne skal være kort og konkret. Den bør sige, hvornår testen foregår, hvilke dele af platformen der testes, hvad kunden kan opleve, og hvem kunden kontakter, hvis noget ser forkert ud. Den behøver ikke sige, hvad der testes i detaljer, og den skal ikke nævne andre kunder.

Nogle kunder kan have krav i aftalen om varsel før ændringer eller planlagte afbrydelser. Læs aftalerne igennem, og brug den længste frist, der gælder for en berørt kunde. Har en kunde sin egen overvågning eller sikkerhedstjeneste, kan det være nødvendigt at give dem besked direkte, så en alarm ikke bliver eskaleret som en hændelse. → Hvem hos kunden skal have besked?

Stop og tilbagevenden

Aftal med testeren, før testen begynder, hvornår den stopper. Kriterierne kan være en kunde, der melder om nedetid, en tjeneste på platformen, der holder op med at svare, eller en uventet adgang til et kundemiljø, der ligger uden for aftalen. Det skal også stå, hvem der kan stoppe testen, og hvordan den person kan nås i hele vinduet.

Når testen er slut, giver I kunderne en kort besked om, at vinduet er lukket. Har en kunde været påvirket, får den kunde en forklaring og en vurdering af, om noget skal følges op. Varslingen, stopkriterierne og beskeden bagefter er alle dokumentation, I kan bruge, når en kunde spørger, hvordan testen blev gennemført.

Et tænkt eksempel

En driftsleverandør med kunder inden for detailhandel, sundhed og produktion vil teste sin fælles identitetsløsning og sit værktøj til fjernadministration. To af kunderne har døgndrift, og en af dem har sin egen sikkerhedstjeneste, der overvåger login. Leverandøren lægger testen på to formiddage midt i ugen, hvor leverandørens egne teknikere er på arbejde, og varsler alle berørte kunder skriftligt med den frist, der står i den strengeste aftale.

Sikkerhedstjenesten hos den ene kunde får besked direkte med testerens afsenderadresser og tidsrummet. Testeren og leverandøren aftaler, at testen stopper, hvis en kunde melder om problemer med login. Første formiddag melder en kunde om langsomme opslag, testen sættes på pause i en halv time, og årsagen viser sig at være en planlagt opdatering hos kunden selv. Kunderne får en kort besked, da vinduet lukkes, og den berørte kunde får en forklaring.

Det skal I lade være med

At teste den fælles platform uden at varsle kunderne · en uforklaret forstyrrelse kan blive behandlet som en hændelse.
At vælge tidspunkt ud fra jeres egen kalender alene · kundernes drift afgør, hvornår det er mindst skadeligt.
At lade testvinduet stå åbent uden bemanding · ingen kan reagere, hvis noget går galt.
At nævne andre kunder i varslingen · hver kunde skal kun kende sin egen del.
At undlade stopkriterier · testeren skal vide, hvornår testen afbrydes.

Hvad kan og ikke kan konkluderes

Et veltilrettelagt testvindue kan vise kunderne, at testen var planlagt, varslet og kontrolleret, og det kan forklare forstyrrelser, der opstod undervejs. Det siger intet om testens resultat og garanterer ikke, at ingen kunde mærker noget. Den enkelte kunde vurderer selv, om varslingen og dokumentationen passer til kundens aftale.