En kunde har haft et sikkerhedsbrud, og kundens beredskab skriver, at angrebet efter deres foreløbige vurdering kom ind gennem jeres produkt. Årsagen er uafklaret, men påstanden er fremsat, og kunden venter et svar. Hvordan I svarer, hviler på to ting: de oplysninger, der kan afgøre, om produktet var vejen ind, og en kommunikation, der hverken afviser eller indrømmer, før det er afklaret. Den seneste pentest kan hjælpe, men den kan ikke afgøre spørgsmålet.
Påstanden kommer før beviserne
I de første timer efter et brud arbejder kundens beredskab med hypoteser. Jeres produkt kan være peget ud, fordi angriberen brugte en konto i produktet, fordi data fra produktet er set uden for kundens kontrol, eller fordi produktet er det system, der har forbindelse udadtil. Det er gode grunde til at spørge, men ingen af dem viser i sig selv, at der er en svaghed i produktet.
Mulighederne er flere. Produktet kan have en svaghed, som blev udnyttet. En gyldig brugerkonto hos kunden kan være misbrugt. En integration eller en API-nøgle, som kunden selv har oprettet, kan være kompromitteret. Eller produktet kan være uden betydning for hændelsen. Jeres opgave er at hjælpe med at finde ud af hvilken, ikke at vælge den mest bekvemme. → Kundernes eget ansvar
Det første svar
Svar hurtigt, også selv om I intet ved endnu. Et første svar kan indeholde:
- Bekræftelse · at henvendelsen er modtaget og taget alvorligt.
- En navngiven kontakt · én person, som kundens beredskab kan tale med.
- Det næste skridt · hvilke oplysninger I går i gang med at samle, og hvornår kunden hører fra jer igen.
- En anmodning · de oplysninger fra kunden, I har brug for, fx tidsrum og berørte konti.
Skriv ikke, at produktet er sikkert, og skriv ikke, at fejlen må ligge hos kunden. Begge dele er konklusioner, I ikke har grundlag for endnu. → Et fast kontaktpunkt for sikkerhedsspørgsmål
Er kunden omfattet af NIS2, kan kunden have frister for at underrette myndighederne og derfor brug for jeres oplysninger hurtigt. Fristerne og kundens behov er beskrevet på nis2-pentest.dk.
Det, I skal bruge for at vurdere sagen
En vurdering hviler på oplysninger fra begge sider. Fra jer selv:
- Logning i produktet · hvem der var logget ind på kundens konti, hvornår og hvorfra, i det tidsrum kunden nævner.
- Supportadgang · om jeres egne medarbejdere har været inde hos kunden i perioden.
- Ændringer · releases, konfigurationsændringer og ændringer i infrastrukturen omkring tidspunktet.
- Kendte sårbarheder · om der er fund eller meldinger om svagheder, der passer på det, kunden beskriver.
Fra kunden:
- Tidsrum og forløb · hvornår brud og mistænkelig aktivitet blev set.
- Konti og roller · hvilke brugere i produktet der er involveret.
- Integrationer · hvilke API-nøgler, single sign-on-opsætninger og forbindelser kunden selv har lavet.
Aftal med kunden, hvad der må deles, og hvordan. Oplysningerne kan være fortrolige for begge parter. Juridiske spørgsmål om ansvar, forsikring og kontrakt hører hjemme hos jeres egen rådgiver. Teksten her er ikke juridisk rådgivning. → Logning og revisionsspor i produktet
Fælles ansvar i praksis
Et SaaS-produkt har en grænse mellem det, I driver, og det, kunden styrer. Kunden opretter brugere, tildeler roller, opsætter login og forbinder produktet med egne systemer. Er angrebet sket gennem en kundeoprettet konto med et svagt eller lækket password, er produktet vejen, men ikke årsagen.
Det skal I kunne forklare sagligt og med jeres logning som grundlag, ikke som en påstand. Har I beskrevet ansvarsfordelingen på forhånd, fx i dokumentationen til kunden eller i kontrakten, er det lettere at henvise til en fælles forståelse frem for at diskutere den midt i en hændelse.
Hvad den seneste pentest kan og ikke kan sige
Den seneste pentest viser, hvad en tester fandt i et bestemt omfang og en bestemt version på et bestemt tidspunkt. Den kan derfor svare på et smalt spørgsmål: Var den del af produktet, kunden peger på, med i testen, og blev der fundet noget, der ligner det, kunden beskriver?
- Var delen med i omfanget? · hvis ikke, siger testen intet om netop den vej.
- Var der et fund? · og er det rettet og efterprøvet?
- Er versionen den samme? · ændringer siden testen kan have åbnet noget nyt.
Testen kan ikke vise, at produktet ikke var vejen ind. En test finder ikke alt, og den ser ikke på kundens konti, opsætning eller integrationer. Brug den derfor som én oplysning blandt flere, ikke som et forsvar. → Rapporten dækker ikke det modul, kunden køber
Hvornår en ny test giver mening
En ny test er ikke det første, I skal gøre. Den kan ikke fortælle, hvad der skete hos kunden, og den kan forstyrre et igangværende undersøgelsesarbejde. Den giver mening, når der er peget på en konkret del af produktet, som ikke var med i seneste test, eller når der er fundet en svaghed, som er rettet og skal efterprøves.
Omfanget bør så tage udgangspunkt i den vej, sagen har peget på, og i lignende funktioner. Hvis kunderne bagefter vil se dokumentation, er det en anden opgave, som kan tilrettelægges, når årsagen er klarere. → Efter en hændelse hos jer: kunden vil se en ny test
Saglighed, mens årsagen er uafklaret
Hold jer til det, I ved, og sig, hvad I endnu ikke ved. Opdater kunden på de tidspunkter, I har lovet, også når der intet nyt er. Brug samme formuleringer i support, salg og ledelse, så kunden ikke hører tre versioner.
Skal andre kunder have besked? Det afhænger af, hvad der bliver fundet. Er der en svaghed i produktet, kan det berøre flere kunder, og så gælder jeres sædvanlige praksis for sikkerhedsmeddelelser. Er der ingen, er der ingen grund til at skabe uro hos andre.
Det skal I lade være med
- At afvise påstanden i første svar · I ved ikke endnu, hvad der skete.
- At indrømme en fejl, før den er fundet · en forhastet indrømmelse kan være forkert.
- At sende pentestrapporten som bevis på uskyld · den kan ikke bære det.
- At bestille en ny test som første reaktion · saml oplysningerne først.
- At lade flere i organisationen svare kunden · én kontakt, én stemme.
- At glemme kundens frister · kunden kan have brug for jeres oplysninger hurtigt.
Hvad kan og ikke kan konkluderes
Jeres logning og kundens oplysninger kan tilsammen vise, om produktet var vejen ind, og om det skyldtes en svaghed i produktet eller misbrug af en gyldig adgang. Den seneste pentest kan vise, om den pågældende del var testet, og hvad der blev fundet. Ingen af dem afgør ansvaret. Det er et spørgsmål til aftalerne mellem jer og kunden og til jeres rådgivere.
Senest gennemgået: oktober 2026.
Næste skridt
- Sikkerhedsmeddelelse til kunderne om en sårbarhed
- Testen finder noget alvorligt: skal kunderne have besked?
Del af: Artikler om pentestrapporten
Læs også: Supportadgang og administrationsmodul · Integrationer til kundernes systemer
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT
