Jeres produkt er indgangen i kundens leverandørscenarie

Et red team, der skal efterligne en modstander, kan vælge at komme ind gennem en leverandør, fordi leverandøren har en betroet plads i kundens miljø. Er I et softwarehus, kan kundens hold bede om at bruge jeres produkt, jeres opdateringer eller jeres supportadgang som vejen ind. Svaret hviler på én skelnen: det, der kun findes hos kunden, kan som udgangspunkt indgå efter aftale med jer, mens det, der deles med jeres andre kunder, skal holdes ude af produktionen og afprøves i et testmiljø eller som en antagelse.

Kundens side af scenariet, set fra den sikkerhedsfunktion, der planlægger det, er beskrevet for sig. → Leverandørscenariet

Hvorfor kunden vælger jeres produkt

MITRE ATT&CK, en offentligt tilgængelig vidensbase over modstanderes adfærd, beskriver forsyningskædekompromittering som en teknik, hvor en modstander manipulerer produkter eller måden, de leveres på, herunder mekanismer til opdatering og distribution. Den beskriver også misbrug af betroede relationer, hvor en modstander bruger en tredjepart, der har adgang til målet. Det er de mønstre, kundens hold vil afprøve, om kunden kan opdage. → MITRE ATT&CK i red teaming

Kunden kan også have en pligt i baggrunden. NIS2-direktivets artikel 21, stk. 3, kræver, at omfattede enheder tager hensyn til de sårbarheder, der er specifikke for hver direkte leverandør, og til kvaliteten af leverandørernes produkter og cybersikkerhedspraksis, herunder deres sikre udviklingsprocedurer.

De veje, kunden kan spørge om

Del jeres produkt op efter, hvad holdet vil bruge:

Installationen hos kunden · produktet kører i kundens eget miljø eller i kundens egen del af jeres løsning.
Integrationer · forbindelser og nøgler, der binder jeres produkt sammen med kundens andre systemer.
Supportadgangen · den fjernadgang, jeres medarbejdere bruger til at hjælpe kunden.
Supportfunktionen · jeres medarbejdere, som holdet kan forsøge at narre til at nulstille eller udvide en adgang.
Opdateringskanalen · den vej, nye versioner når frem til kunden og til alle andre kunder.
Udviklingsmiljøet · de systemer, hvor jeres kode bygges og signeres.

De første fire kan afgrænses til kunden. De sidste to er fælles for alle jeres kunder. Kører produktet som en tjeneste, som flere kunder deler, er grænsen sværere at trække, fordi kundens del ligger i de samme systemer som de andres. Så skal holdets handlinger holdes inden for kundens egen del, og alt, der kan påvirke tjenesten for andre, er udelukket.

Det, I kan acceptere

Installationen hos kunden og kundens egne integrationer kan indgå, når I har givet skriftlig tilladelse og kender tidsrummet. Supportadgangen kan afprøves fra kundens side: holdet undersøger, hvor langt den adgang rækker hos kunden, uden at gå ind i jeres systemer.

Supportfunktionen er sværere. Her er det jeres medarbejdere, der bliver kontaktet, og det kræver jeres tilladelse og en aftale om, hvem der må kontaktes, og hvad holdet må bede om. Hvordan en skjult øvelse mod jer skal rammes ind, er beskrevet for sig. → Kunden vil red teame jer

Det, der hører til i et testmiljø

Opdateringskanalen og udviklingsmiljøet bør ikke indgå i produktionen. En manipuleret opdatering, også en harmløs, når ikke kun kunden, men alle, der henter den version. Det er jeres andre kunder, der bærer risikoen, og de har ikke sagt ja.

Der er to måder at give kunden noget alligevel:

Et testmiljø · I stiller en kopi af opdateringskanalen til rådighed, som kun leverer til kundens testinstallation.
En antagelse · scenariet begynder, som om en manipuleret opdatering allerede er nået frem hos kunden. Holdet starter derfra, og kunden afprøver, om forsvaret opdager, hvad der sker bagefter. → Assumed breach som udgangspunkt

Den anden måde kan være nok for kunden, fordi spørgsmålet er, om kunden opdager misbruget, ikke om jeres byggeproces kan manipuleres. Det sidste er jeres eget spørgsmål og hører hjemme i jeres egne test.

Hvem hos jer der skal vide besked

Når jeres produkt er vejen ind, er jeres egne folk også en del af det, kunden måler, især hvis jeres support eller drift overvåger brugen af supportadgangen. Udpeg én kontaktperson, der kender tidsrummet og kan tale med kundens white team, og hold kredsen lille. Personen skal kunne afgøre, om usædvanlig aktivitet i kundens installation eller i supportadgangen er holdets, før jeres folk spærrer adgangen eller giver andre kunder besked. → Med i kundens red team-øvelse

Aftal også, hvad der sker, hvis jeres support opdager holdet. Det er et resultat for kunden, ikke en fejl, og jeres medarbejdere skal have at vide bagefter, at de gjorde det rigtige.

Fund i produktet

Finder kundens hold en svaghed i selve produktet, angår den alle jeres kunder. Aftal, at fund i produktet meldes til jer straks og fortroligt, og at I ejer opfølgningen. Aftal også, hvordan kunden beskriver fundet i sin rapport, så rapporten ikke bliver en vejledning i at angribe jeres andre kunder, hvis den deles videre i kundens organisation.

Cyber Resilience Act, forordning (EU) 2024/2847, gælder for produkter med digitale elementer og finder i det væsentlige anvendelse fra den 11. december 2027, mens artikel 14 om fabrikanters indberetning gælder fra den 11. september 2026. Artikel 14 handler om aktivt udnyttede sårbarheder, og artikel 3, nr. 42, definerer dem som sårbarheder, som en ondsindet aktør har udnyttet uden tilladelse fra systemejeren. Om et fund fra en godkendt øvelse kan udløse pligter efter forordningen, og om jeres produkt overhovedet er omfattet, må jeres rådgiver vurdere. Hvordan et softwarehus dokumenterer sine egne test over for kunderne, er beskrevet på pentestrapport.dk.

Det skal I lade være med

At tillade en manipuleret opdatering i produktion · den rammer alle kunder.
At lade kundens tilladelse dække jeres supportfunktion · medarbejderne er jeres.
At afvise uden alternativ · et testmiljø eller en antagelse kan dække behovet.
At lade fund i produktet blive i kundens rapport · I skal have dem straks.
At blande kundens øvelse sammen med jeres egne test · byggeprocessen er jeres spørgsmål.

Hvad kan og ikke kan konkluderes

Et scenarie med jeres produkt som indgang kan vise, om kunden opdager misbrug af en betroet leverandør. Det kan også give jer fund i produktet og i supporten. Det viser ikke, at jeres opdateringskanal eller udviklingsmiljø er sikkert, medmindre de blev afprøvet, og et testmiljø svarer kun til produktionen i det omfang, det er en tro kopi. Teksten er ikke juridisk rådgivning. → Ansvar ved kundens red team

Tjekliste, når kunden vil bruge jeres produkt

☐ Er vejene delt op i kundens egne og de fælles?
☐ Har I givet skriftlig tilladelse til det, der kun er kundens?
☐ Er supportfunktionen med, og er medarbejderhensyn aftalt?
☐ Holdes opdateringskanal og udviklingsmiljø ude af produktionen?
☐ Har I tilbudt et testmiljø eller en antagelse?
☐ Meldes fund i produktet til jer straks?

Kilder

MITRE ATT&CK, Supply Chain Compromise (T1195): manipulation af produkter og leveringsmekanismer, herunder opdatering og distribution.
MITRE ATT&CK, Trusted Relationship (T1199): misbrug af tredjeparter med adgang til målet.
NIS2-direktivet, direktiv (EU) 2022/2555: artikel 21, stk. 3, om hensyn til leverandørers sårbarheder, produkter og sikre udviklingsprocedurer.
Cyber Resilience Act, forordning (EU) 2024/2847: artikel 3, nr. 42, artikel 14 og artikel 71 om anvendelsesdatoer.

Senest gennemgået: oktober 2026.