En stor kunde kan skrive, at en almindelig penetrationstest ikke er nok, og spørge til red teaming, scenariebaseret test eller deltagelse i kundens egen øvelse. Før I svarer, skal I vide, hvad kunden faktisk beder om: en mere omfattende test af jeres produkt, eller at jeres produkt indgår i en øvelse, kunden selv står for. De to kræver noget meget forskelligt af jer. Svaret hviler på kravets ordlyd, på kundens egne regler og på hensynet til jeres øvrige kunder.
Hvad kunden kan mene
Ordene bruges ikke ens, så spørg, før I antager noget. Bag et krav om mere end en pentest kan der ligge:
- En bredere test af produktet · flere moduler, flere roller eller en længere testperiode, men stadig en penetrationstest med jeres omfang.
- En scenariebaseret test · testen tager udgangspunkt i et bestemt mål, fx at få adgang til en anden kundes data, frem for at gennemgå hele produktet.
- Kundens egen red teaming · kunden afprøver sin samlede evne til at opdage og reagere, og jeres produkt eller jeres adgang til kundens systemer kan være en mulig vej ind.
- Et regulatorisk krav · kunden er en finansiel virksomhed, og kravet kommer fra reglerne om trusselsbaseret test.
De tre første kan I tale om ud fra jeres egne regler for test. Det sidste har sin egen ramme. → Kunden vil se scope eller deltage
Red teaming er kundens øvelse, ikke jeres rapport
En red teaming-øvelse afprøver en organisation, ikke et produkt. Hvis kunden vil red teame sig selv, er det kundens øvelse, kundens mål og kundens rapport. Jeres rolle kan være at give tilladelse til, at jeres produkt eller jeres forbindelse til kunden indgår, og at sikre, at det sker uden at ramme andre.
Det betyder også, at resultatet sjældent kan bruges som dokumentation over for jeres andre kunder. Den rapport, de skal have, er stadig jeres egen penetrationstest af produktet. Har kunden bedt om en bredere eller scenariebaseret test af selve produktet, er det derimod en opgave, I selv kan bestille og eje. Så kan resultatet indgå i jeres dokumentation på samme måde som den årlige test, hvis rapporten beskriver omfang, mål og forudsætninger tydeligt. → Bestil til kundebrug Forskellen på red teaming og pentest, og hvordan en øvelse planlægges, er beskrevet på red-teaming.dk.
Når kunden er en finansiel virksomhed
DORA, forordning (EU) 2022/2554, pålægger visse finansielle virksomheder at gennemføre trusselsbaserede penetrationstest (TLPT) efter artikel 26. Hvis tredjepartsudbydere af IKT-tjenester indgår i testens omfang, skal den finansielle virksomhed efter artikel 26, stk. 3, sikre deres deltagelse og har det fulde ansvar for at overholde forordningen.
Artikel 26, stk. 4, åbner for en samlet test, hvis deltagelse kan forventes at påvirke kvaliteten eller sikkerheden af de tjenester, udbyderen leverer til kunder uden for forordningens område, eller fortroligheden af deres data. Så kan udbyderen selv indgå aftale med en ekstern tester om en samlet test under ledelse af en udpeget finansiel virksomhed. For IKT-tjenester, der understøtter kritiske eller vigtige funktioner, skal kontrakten efter artikel 30, stk. 3, litra d, rumme en forpligtelse for udbyderen til at deltage i og samarbejde fuldt ud om kundens TLPT.
Om jeres tjeneste understøtter en kritisk eller vigtig funktion hos kunden, er kundens vurdering. Spørg kunden direkte, og læs kontraktudkastet med det for øje. Bemærk også, at reglerne om TLPT gælder bestemte finansielle virksomheder, ikke enhver kunde i finanssektoren. Teksten er ikke juridisk rådgivning. → Kunden er en finansiel virksomhed
Hvad I skal aftale, hvis jeres produkt er med
Hvis kundens øvelse eller test skal omfatte jeres produkt, skal rammerne være på plads, før den begynder:
- Omfang · hvilke dele af produktet og hvilke forbindelser til kunden der må indgå.
- Tidsrum · hvornår øvelsen foregår, så I kan skelne den fra et rigtigt angreb.
- Kontakt · hvem hos jer der kender til øvelsen og kan stoppe den, hvis noget går galt.
- Grænser · hvad der ikke må ske, fx belastning af tjenesten eller adgang til andre kunders data.
- Fund · hvordan I får besked om svagheder i jeres produkt, og hvem der ejer oplysningerne.
- Ansvar · hvem der bærer følgerne, hvis øvelsen skader driften.
Mange af punkterne findes allerede i jeres testpolitik for kunder. Brug den som udgangspunkt, og tilføj det, der er særligt for en øvelse, hvor ikke alle hos jer må kende til den på forhånd. → Testpolitik for kunder · → Ansvar ved kundens test
Hensynet til de andre kunder
I et produkt, flere kunder deler, kan en øvelse for én kunde ramme alle. Det er jeres ansvar at sige nej til de dele, der kan påvirke andre, eller at foreslå et afgrænset miljø. DORA nævner selv hensynet til udbyderens kunder uden for forordningens område som grund til en samlet test. Det kan bruges som argument, når en kunde vil have mere adgang, end I kan give. → Kundens test i et delt miljø
Et tænkt eksempel
En regional bank bruger et softwarehus’ system til håndtering af kundeklager. Banken skriver, at systemet kan indgå i en kommende trusselsbaseret test. Softwarehuset spørger, om systemet understøtter en kritisk eller vigtig funktion hos banken, og beder om at se den del af kontrakten, der handler om test. Det aftales, at kun bankens egen kunde i systemet må indgå, at en navngiven person hos softwarehuset kender tidsrummet, og at fund i produktet meldes til softwarehuset under fortrolighed.
Det skal I lade være med
- Sige ja, før I ved, hvad kunden mener · spørg ind til kravet.
- Lade en øvelse ramme andre kunder · afgræns eller sig nej.
- Bruge kundens rapport som jeres dokumentation · den handler om kunden.
- Overse DORA-bestemmelserne i kontrakten · læs dem, før I skriver under.
- Undlade en kontakt hos jer · nogen skal kunne stoppe øvelsen.
Hvad kan og ikke kan konkluderes
En afklaring af kravet viser, om kunden ønsker en bredere test af jeres produkt eller jeres deltagelse i sin egen øvelse. Den afgør ikke, om kundens regler kræver noget bestemt af jer. Det står i kundens kontrakt og i de regler, kunden er underlagt. En øvelse, hvor jeres produkt indgår uden fund, siger heller ikke, at produktet er grundigt testet. Øvelsen havde et andet mål, og den gik måske kun en enkelt vej gennem produktet. Den kan derfor ikke stå i stedet for jeres egen test.
Tjekliste til kravet
- ☐ Er det afklaret, hvad kunden mener med mere end en pentest?
- ☐ Er det klart, om kunden er omfattet af DORA og TLPT?
- ☐ Er omfang, tidsrum og kontakt aftalt?
- ☐ Er hensynet til andre kunder sikret?
- ☐ Er det aftalt, hvordan fund i produktet når jer?
- ☐ Er ansvaret ved skade beskrevet?
Kilder
- DORA, forordning (EU) 2022/2554: artikel 26, stk. 3 og 4, om tredjepartsudbyderes deltagelse i TLPT og samlet test; artikel 30, stk. 3, litra d, om udbyderens forpligtelse til at deltage i og samarbejde om kundens TLPT.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Kunden vil selv teste jeres produkt · Hvad skal med i en penetrationstest af et SaaS-produkt?
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT