Hele virksomheden eller kun leverancen? Når kunden spørger bredt

Et leverandørkrav kan være formuleret, som om hele leverandørens IT skal penetrationstestes: kontornet, mail, bogholderi og den løsning, kunden faktisk køber. Svaret hviler på, hvad kundens egne regler handler om. De handler om risikoen for kundens net- og informationssystemer, og derfor er leverancen og alt, der kan påvirke den, det naturlige udgangspunkt for testen. Resten af virksomheden hører kun med, hvor den har forbindelse til leverancen.

Det betyder ikke, at kontornettet altid kan holdes ude. Det betyder, at I kan bede kunden om at begrunde den brede formulering, og at I kan foreslå en afgrænsning, der følger kundens risiko frem for jeres organisationsdiagram. Teksten er ikke juridisk rådgivning, og kundens aftale går forud.

Hvorfor kravet kan være skrevet bredt

En kunde med mange leverandører kan bruge én skabelon til alle. Skabelonen skal dække både driftsleverandøren med administratoradgang og leverandøren af et fagsystem, der aldrig rører kundens net. Det er lettere at skrive “virksomhedens IT-miljø” end at beskrive hver leverance for sig.

Den brede formulering er derfor ikke nødvendigvis en bevidst beslutning om at teste jeres lønsystem. Den er et udtryk for, at kunden ikke har taget stilling til, hvor jeres leverance begynder og slutter. Det er dér, I kan hjælpe. → Hvilke systemer forventer kunden testet?

Hvad reglerne retter sig mod

NIS 2-lovens § 6, stk. 1, handler om foranstaltninger for de net- og informationssystemer, som den omfattede enhed bruger til sine operationer eller til at levere sine tjenester. Nr. 4 er forsyningskædesikkerhed, herunder forholdet til direkte leverandører og tjenesteudbydere. Direktivets artikel 21, stk. 3, taler om de sårbarheder, der er specifikke for hver direkte leverandør.

Styrelsen for Samfundssikkerhed (SAMSIK) skriver i vejledningen om anvendelsesområdet, afsnit 8, at den omfattede enhed skal vurdere de risici, som den modtagne leverance udgør, og at det kan føre til forholdsmæssige krav til leverandøren. Vejledningen om foranstaltninger, afsnit 4, anbefaler en risikobaseret tilgang, hvor kravene står i forhold til den specifikke leverances betydning. Begge steder er det leverancen, der er målestokken. → Kundens risikovurdering

Hvor kontornettet alligevel hører med

En afgrænsning til leverancen er kun troværdig, hvis den medtager de veje, hvorpå jeres almindelige IT kan nå kunden. Det kan være:

Arbejdspladserne, der bruges til support · de computere, hvorfra jeres medarbejdere logger på hos kunden eller i jeres løsning.
Identiteter og administratorkonti · hvis samme brugerkatalog styrer både kontoret og leverancen, er det en del af leverancen.
Administrations- og fjernværktøjer · det værktøj, der bruges til at drifte kunden, kan være mere kritisk end løsningen selv. → Administrationsværktøjer
Mail og filudveksling · de kanaler, kundens oplysninger går igennem.
Udviklings- og byggemiljøet · hvis kode til kundens løsning bygges og frigives derfra.

Systemer, der hverken har adgang til kunden, rummer kundens data eller kan ændre leverancen, kan I som regel argumentere for at holde ude. Det gælder fx økonomisystem, intranet og gæstenet, så længe de er adskilt fra resten.

Argumenter for en afgrænsning

Når I foreslår at teste leverancen frem for hele virksomheden, står forslaget stærkest, hvis det bygger på kundens egne begreber:

Kundens risiko · testen skal belyse det, der kan ramme kundens systemer. Et fund på jeres gæstenet siger lidt om den risiko.
Forholdsmæssighed · loven bruger selv ordene passende og forholdsmæssige. En test af hele virksomheden kan være ude af proportion med en lille leverance. → Forholdsmæssige krav
Brugbar dokumentation · en rapport om leverancen kan kunden lægge direkte ind i sin vurdering. En rapport om alt kræver, at kunden selv sorterer.
Dybde frem for bredde · med samme indsats kan en afgrænset test gå grundigere til værks på det, der betyder noget for kunden.

Send forslaget skriftligt med en kort beskrivelse af leverancen, de forbindelser til jeres øvrige IT, I har medtaget, og det, I foreslår at holde ude med begrundelse. → Send kunden en plan for testen

Når kunden fastholder hele virksomheden

Nogle kunder fastholder kravet. Det kan skyldes, at leverancen reelt er hele jeres forretning, fx hvis I drifter kundens IT, eller at kunden har en politik, der ikke kan ændres for én leverandør. Så har I tre muligheder: acceptere kravet, forhandle tidspunkt og trin, eller tilbyde en test i to dele, hvor leverancen testes først og grundigst og resten mere overordnet.

Hvad det betyder for omfanget og prisen, afhænger af antallet af systemer, adresser og brugere. Bed om et overslag ud fra begge afgrænsninger, så forskellen kan forklares for kunden; se pris og tilbud. Hvis I er en lille virksomhed med få systemer, kan forskellen være mindre, end kravet lyder til. → Lille leverandør: et rimeligt omfang

Et tænkt eksempel

En leverandør af et vagtplanssystem til en region får et krav om “årlig penetrationstest af leverandørens IT-miljø”. Systemet kører i en cloudplatform, medarbejderne supporterer fra deres bærbare computere, og administratorerne logger ind med de samme konti som på kontoret.

Leverandøren foreslår at teste vagtplanssystemet, supportadgangen og brugerkataloget med administratorkontiene, men ikke økonomisystemet og mødelokalernes skærme. Forslaget beskriver hvorfor. Regionen accepterer, men beder om, at bærbare computere med supportadgang kommer med. Det er en rimelig tilføjelse, fordi de er en vej ind i leverancen.

Det skal I lade være med

At afvise kravet uden et alternativ · kunden har brug for et svar, der kan bruges i vurderingen.
At afgrænse til selve applikationen alene · supportadgang og administratorkonti kan være den største risiko for kunden.
At holde systemer ude, fordi de er svære at teste · begrundelsen skal være, at de ikke berører kunden.
At love, at resten af virksomheden er sikker · det, der ikke er testet, er ikke dokumenteret.
At acceptere hele virksomheden uden at aftale form · kunden skal vide, hvilke dele af rapporten der angår leverancen.

Hvad kan og ikke kan konkluderes

En test afgrænset til leverancen kan dokumentere, hvad der blev fundet i de systemer og adgange, der har forbindelse til kunden. Den kan ikke sige noget om dele af virksomheden, der ikke var med, og den kan ikke vise, at adskillelsen mellem kontoret og leverancen holder overalt, medmindre det netop var en del af testen. Om afgrænsningen er tilstrækkelig, er kundens vurdering. Ændrer leverancen sig senere, fx med en ny integration eller en ny type adgang, skal afgrænsningen tages op igen, før den næste test bestilles.