Erstatning efter persondatabrud: digitale beviser

Når personoplysninger er blevet lækket, stjålet eller vist til uvedkommende, kan der opstå et civilt erstatningskrav. Kravet kan komme fra de registrerede over for den dataansvarlige, eller fra den dataansvarlige over for en databehandler eller leverandør, hvis sikkerhed svigtede. I begge situationer skal tre ting kunne dokumenteres: at hændelsen skete, hvorfor den skete, og hvad den omfattede.

Grundlaget for kravet er advokatens vurdering. Databeskyttelsesforordningen indeholder en selvstændig regel om erstatning i artikel 82. Denne artikel handler kun om den civile erstatningssag og de digitale beviser i den. Myndighedssporet over for Datatilsynet er et andet forløb, selv om det kan levere materiale til sagen.

Hvem har dataene?

• Den dataansvarlige · Logs, hændelsesrapport, intern analyse, anmeldelse til tilsynet, underretning til de registrerede
• Databehandler eller leverandør · Driftslogs, adgangslogs, sikkerhedsrapporter, kommunikation med den dataansvarlige
• Incident response-firma · Teknisk rapport, tidslinje, sikrede kopier
• Den registrerede · Underretningen, mistænkelige mails og opkald efter bruddet, egne tab
• Forsikringsselskab · Skadeanmeldelse og eventuelle tekniske vurderinger

Den registrerede står svagest med data. De fleste tekniske oplysninger ligger hos den dataansvarlige og dennes leverandører. En dataansvarlig, der har anmeldt bruddet, har normalt dokumenteret en del af forløbet. Den dokumentation kan blive relevant i en senere sag.

Hændelsen: hvad skete der?

Det første spørgsmål er rent faktuelt. Var der uautoriseret adgang, eller blev data fejlagtigt sendt eller gjort tilgængelige? De to situationer giver forskellige spor.

• Uautoriseret adgang: Loginlogs, adgangslogs fra servere og cloudtjenester, logs over dataudtræk og netværksforbindelser.
• Fejlforsendelse: Mailserverens log over modtagere, versioner af den udsendte fil, eventuelle forsøg på tilbagekaldelse.
• Offentlig eksponering: En åben database, en ubeskyttet fildeling eller et link, der kunne findes. Her er spørgsmålet, hvor længe data lå åbent, og om nogen faktisk tilgik dem.

Årsagen: hvorfor skete det?

Årsagen har betydning for, om der er handlet ansvarspådragende, og for fordelingen mellem dataansvarlig og leverandør. Teknisk spørges der typisk:

• Var der kendte sårbarheder, der ikke var lukket?
• Var der tofaktorgodkendelse på de konti, der blev misbrugt?
• Var adgangsrettighederne bredere end nødvendigt?
• Blev der overvåget og reageret på advarsler?
• Svarede sikkerheden til det, der var aftalt i databehandleraftalen?

Data kan vise, hvordan systemet var sat op, og hvad der skete. Om opsætningen var passende i forhold til risikoen, er en vurdering, som skønsmanden kan belyse teknisk, men som retten afgør.

Sikr tilstanden før genopretningen, hvis det overhovedet er muligt. Når systemet er geninstalleret, er sporene efter angrebsvejen ofte væk. → Forsikringssager efter cyberangreb

Omfanget: hvem og hvad blev ramt?

Omfanget er ofte det sværeste at dokumentere og det mest omdiskuterede. Den dataansvarlige kan have opgjort det bredt for en sikkerheds skyld i underretningen. I erstatningssagen kan det være i begge parters interesse at præcisere det.

• Hvilke tabeller, filer eller postkasser blev tilgået?
• Kan det ses, om data blev kopieret ud, eller kun om de var tilgængelige?
• Hvilke kategorier af oplysninger indgik: kontaktoplysninger, CPR-numre, helbred, økonomi, adgangskoder?
• Er de lækkede data senere dukket op offentligt eller i lukkede fora?

Et eksempel: Logs viser adgang til en server, men ikke hvilke filer der blev åbnet. Så kan det ikke ud fra logs alene fastslås, at en bestemt persons oplysninger blev kopieret. Det kan kun siges, at de lå på en server, der blev tilgået. Den forskel kan være afgørende for kravet.

Årsagsforbindelse hos den registrerede

Kræver en registreret erstatning for et konkret tab, fx et misbrug af identitet eller et svindelforsøg, skal tabet kobles til netop dette brud. Det er teknisk vanskeligt, fordi de samme oplysninger kan stamme fra andre lækager.

• Gem mistænkelige mails med fuld header, ikke som videresendte kopier. → Mail-headere: SPF, DKIM og DMARC
• Notér, om henvendelserne bruger oplysninger, der kun fandtes i det konkrete datasæt.
• Dokumentér tidspunkterne i forhold til bruddet.
• Sikr kontoudtog og korrespondance om et eventuelt økonomisk tab.

Data kan sandsynliggøre en forbindelse. De kan sjældent udelukke andre kilder. Jo mere særegne de anvendte oplysninger er, jo stærkere bliver sammenhængen. En henvendelse, der kun bruger navn og mailadresse, siger mindre end en, der gengiver et kundenummer fra netop det lækkede system.

Når klienten er den dataansvarlige

Repræsenterer advokaten den dataansvarlige, er udgangspunktet et andet. Klienten har dataene, og det er klientens dokumentation, der vil blive efterprøvet. Det stiller krav fra første dag.

• Bevar logs og sikrede kopier, også selv om systemet skal genoprettes hurtigt. Aftal med driftsleverandøren, at der tages kopier, før noget slettes eller overskrives.
• Hold teknisk analyse og ansvarsvurdering adskilt. En intern rapport skrevet i hast kan indeholde formuleringer om fejl og forsømmelser, som ikke er gennemtænkt. Overvej, hvem der skriver hvad, og til hvem.
• Dokumentér sikkerhedsniveauet før hændelsen: konfiguration, politikker, opdateringsstatus og tofaktordækning. Det, der ikke er dokumenteret, kan være svært at bevise bagefter.
• Sikr kommunikationen med leverandører. Hvis klienten vil rejse regres mod en databehandler, skal leverandørens rolle i hændelsen kunne vises. → Leverandøren blev hacket

Samme data bruges ofte i flere spor på én gang: tilsynet, forsikringen, de registreredes krav og et eventuelt regreskrav. Det er en fordel, at alle spor bygger på samme sikrede materiale.

Praktisk rækkefølge

Uanset hvilken side klienten er på, er rækkefølgen i det tekniske arbejde nogenlunde den samme:

1. Fastlås tilstanden: sikr logs, konfiguration og berørte systemer, før genopretning eller oprydning sletter spor.
2. Indsaml den dokumentation, der allerede findes: anmeldelser, interne rapporter, korrespondance med leverandører og databehandleraftaler.
3. Fastslå hændelsesforløbet: adgangsvej, tidspunkter og varighed.
4. Afgræns omfanget: hvilke data der var tilgængelige, og hvilke der kan vises at være kopieret.
5. Vurder årsagen ud fra den sikkerhed, der faktisk var på plads på tidspunktet.
6. Saml det i en tidslinje med kildehenvisninger, så den kan bruges i flere spor på én gang.

Rækkefølgen er vigtig, fordi de første trin ikke kan gentages. Et system, der er geninstalleret, kan ikke sikres igen. Trin 3 til 6 kan derimod genbesøges, når der kommer nye oplysninger, fx fra en leverandør eller fra tilsynets sag.

Typiske fejl

• Systemer genoprettes, før angrebsvejen er dokumenteret.
• Logs med kort opbevaringstid slettes, mens parterne forhandler.
• Den incident response-rapport, der foreligger, er lavet til at stoppe angrebet, ikke til at belyse ansvar. Den besvarer derfor ikke sagens spørgsmål.
• Omfanget overtages fra underretningen uden teknisk efterprøvning.
• Den registrerede videresender mistænkelige mails og sletter originalerne.

Spørgsmål til klienten

• Hvornår og hvordan blev bruddet opdaget?
• Hvilke logs findes, og hvor længe gemmes de?
• Hvem har lavet den tekniske analyse, og til hvilket formål?
• Hvad står der i databehandleraftalen om sikkerhed og logning?
• Hvilket tab eller hvilken gene kan dokumenteres, og med hvad?

Spørgsmål til skønsmanden

• “Hvilken adgangsvej er anvendt, og hvornår fandt den første uautoriserede adgang sted?”
• “Kan det ud fra de sikrede logs fastslås, hvilke datasæt der er kopieret ud af systemet, eller alene hvilke der var tilgængelige?”
• “Var der på tidspunktet aktiveret tofaktorgodkendelse på de anvendte konti?”

Opgørelsen af det økonomiske tab er et selvstændigt spørgsmål. → Opgørelse af tab ved datatyveri

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT