Cyberangreb: tvisten med IT-leverandøren

Når driften er genoprettet efter et cyberangreb, kommer spørgsmålet om, hvem der bærer tabet. Kunden mener, at IT-leverandøren burde have opdateret systemerne, overvåget dem eller haft en backup, der kunne bruges. Leverandøren mener, at opgaven aldrig var aftalt, at kunden fravalgte tiltag, eller at angrebet kom ind ad en vej, leverandøren ikke havde ansvar for.

Denne side handler om den civile tvist mellem kunde og leverandør. Hvem der stod bag angrebet, er sjældent det, sagen afgøres på. Det afgørende er, hvad leverandøren var forpligtet til, hvad leverandøren faktisk gjorde, og om forskellen har betydning for skaden. Forsikringssiden er beskrevet i Forsikringssager efter cyberangreb, og tvister om persondata i Tvister mellem dataansvarlig og databehandler.

Tre spørgsmål, sagen typisk drejer sig om

1. Pligten. Hvilke sikkerhedsopgaver lå hos leverandøren ifølge aftalen, og hvilke lå hos kunden?
2. Udførelsen. Blev opgaverne udført, og kan det dokumenteres for perioden før angrebet?
3. Sammenhængen. Hvis noget ikke blev gjort, var det så den vej, angrebet kom ind, eller den grund til, at skaden blev større?

Det første spørgsmål er i høj grad juridisk og afgøres af aftaledokumenterne. Det andet og tredje er tekniske og afgøres af logs og systemernes tilstand. Den retlige vurdering af ansvar og ansvarsbegrænsning er advokatens. IT-siden kan belyse, hvad der faktisk skete.

Aftaledokumenterne: hvem skulle gøre hvad?

Ansvarsfordelingen står sjældent ét sted. Den skal typisk samles fra flere dokumenter, og de er ofte ændret undervejs:

• Hovedaftale og bilag · Ydelsesbeskrivelse, servicemål og ansvarsbegrænsning
• Ydelseskatalog eller serviceaftale · Om opdatering, overvågning, backup og test af gendannelse var omfattet
• Tilvalg og fravalg · Om kunden har afslået fx flerfaktorgodkendelse, overvågning uden for arbejdstid eller ekstra backup
• Ændringsaftaler og ordrer · Hvornår ydelser kom til eller faldt bort
• Databehandleraftale · Beskrevne sikkerhedsforanstaltninger, hvis der behandles persondata
• Statusrapporter og møder · Hvad leverandøren har rapporteret og anbefalet, og hvad kunden har svaret
• Fakturaer · Hvilke ydelser der faktisk blev leveret og betalt for

Særligt fravalg er vigtige. Har leverandøren anbefalet et tiltag, og har kunden sagt nej, ligger det ofte i en mail eller et mødereferat og ikke i aftalen. Det modsatte findes også: en ydelse står i aftalen, men er aldrig sat op.

I cloudløsninger er der desuden en fordeling mellem cloududbyderen, leverandøren og kunden. Hvem der skulle slå en bestemt sikkerhedsindstilling til, kan være uklart, hvis aftalen kun henviser til “drift”.

Logs: hvad blev faktisk gjort?

Aftalen viser pligten. Logs og systemdata viser udførelsen. De vigtigste kilder er typisk:

• Opdateringshistorik. Hvornår blev sikkerhedsopdateringer installeret på de relevante servere og enheder, og hvornår var de tilgængelige?
• Backupjob og gendannelsestest. Kørte backup som aftalt, lå en kopi adskilt fra produktionsmiljøet, og blev gendannelse testet?
• Overvågning og alarmer. Kom der advarsler før eller under angrebet, og hvordan blev de håndteret?
• Loginlogs og administratorkonti. Hvem havde administrativ adgang, var flerfaktorgodkendelse slået til, og hvilke konti blev brugt under angrebet?
• Ændringslog og tickets. Hvornår blev indstillinger ændret, og hvad blev meldt og svaret? → Jira, Zendesk og ticketsystemer som bevis
• Fjernadgangsværktøjer. Leverandørens eget værktøj til fjernadgang kan være både et spor og en mulig indgangsvej.

Hvordan logs læses og vurderes, er beskrevet i Sådan læser du en logfil. Det er værd at vide, at logs ofte kun gemmes i en begrænset periode. Mangler de fra tiden før angrebet, kan udførelsen i den periode være svær at dokumentere for begge parter.

Hvem har dataene?

I de fleste sager ligger en stor del af dataene hos leverandøren: overvågningssystemet, ticketsystemet, backupsoftwaren og ofte administratorkontiene. Det er samme situation som i mange andre leverancetvister, men tidspresset er større, fordi systemerne bliver genopbygget hurtigt efter et angreb.

Bed tidligt om, at leverandøren bevarer de relevante data, og afklar, om klienten selv har adgang til eksport. → Bevarelsespligt og litigation hold Ophører samarbejdet efter angrebet, er overgangen til en ny leverandør et kritisk tidspunkt, fordi konti og systemer lukkes. → Exit-bistand og dataudlevering ved ophør

Er klienten leverandøren, gælder det samme omvendt. Leverandørens egne data skal sikres i uændret form, før nogen begynder at udvælge. → Når klienten er IT-leverandøren

Tilstanden før angrebet

Efter et angreb bliver sikkerheden ofte strammet hurtigt. Det er godt, men det kan gøre det vanskeligt at vise, hvordan opsætningen var. Sikr derfor eksport af indstillinger, politikker og konti, før de ændres, og gem ældre rapporter og skærmbilleder af konsoller. Forskellen mellem tilstanden før og efter er ofte selve sagen.

Indgangsvejen og årsagssammenhængen

Incident response-rapporter angiver ofte den mest sandsynlige indgangsvej. Det er en vurdering, ikke nødvendigvis et fund. Er der flere mulige veje ind, kan det have stor betydning, om den manglende opdatering eller den manglende flerfaktorgodkendelse faktisk var den, der blev brugt.

Spørgsmål, der er værd at stille til en sådan rapport:

• Hvilke data bygger konklusionen om indgangsvejen på?
• Er der huller i logs, som gør andre forklaringer mulige?
• Hvem har bestilt rapporten, og er formålet genopretning eller dokumentation?
• Kan de underliggende data udleveres, så en anden sagkyndig kan efterprøve dem?

→ Sådan læser du en IT-sagkyndig rapport

Tabet

Tabet består typisk af genopretning, driftstab, ekstern bistand og eventuelle krav fra kunder. Den tekniske tidslinje kan vise, hvornår systemerne var nede og oppe igen, og om en brugbar backup ville have forkortet nedetiden. → Tidslinjer som bevis

Skøn i tvisten

Kommer sagen for retten eller en voldgiftsret, kan et skøn belyse de tekniske spørgsmål. Gode skønsspørgsmål holder sig til det, der kan måles:

• “Hvornår blev sikkerhedsopdatering [x] installeret på server [y] ifølge opdateringshistorikken?”
• “Viser backuploggen, at der i perioden [a] til [b] blev taget backup som beskrevet i bilag [z]?”
• “Kan skønsmanden ud fra de sikrede logs angive, hvilken konto og hvilken adgangsvej der blev brugt ved den første uautoriserede adgang?”

Spørgsmål om, hvorvidt leverandøren “handlede ansvarspådragende”, hører ikke hjemme i skønstemaet. → Skønsmand i IT-projekter og softwaretvister · Skønsmandens adgang til systemer og data

Typiske fejl

• At geninstallere eller lukke konti, før logs og opsætning er sikret.
• At overse fravalg og anbefalinger i mails og mødereferater.
• At tage incident response-rapportens indgangsvej som et fastslået faktum.
• At vente med at bede leverandøren bevare data, til samarbejdet er ophørt.

Sådan kan Nielco IT bistå

John Nielsen, Nielco IT, er IT-sagkyndig med retssagserfaring og har mere end 30 års erfaring med IT-sikkerhed. Nielco IT sælger ikke produkter og har ingen leverandørpartnerskaber. Opgaven kan være at sikre logs og opsætning, gennemgå en incident response-rapport, holde aftalens sikkerhedsydelser op mod de tekniske data eller hjælpe med at formulere skønsspørgsmål. Rollen i sagen afklares først.

→ IT-sagkyndig for advokater · Send en sag