Debatt

Fire ting forverrer dataangrep

Mange skylder på «alvorlige dataangrep», men årsaken til milliontapene er ofte feilhåndtering fra IT-leverandøren selv.

Stadig ser jeg en «fake it 'til you make it»-kultur: Leverandører lover ekspertise de ikke har, setter inn vanlige utviklere og bruker måneder eller år på oppgaver som et Incident Response-team løser på uker, skriver innleggsforfatteren.
Stadig ser jeg en «fake it 'til you make it»-kultur: Leverandører lover ekspertise de ikke har, setter inn vanlige utviklere og bruker måneder eller år på oppgaver som et Incident Response-team løser på uker, skriver innleggsforfatteren. Illustrasjonsfoto: Colourbox
Louise Øverås Nilsen, jurist og ekspert på krisehåndtering av dataangrep
12. mai 2026 - 13:01

Dette debattinnlegget gir uttrykk for skribentens meninger. Innlegg kan sendes til debatt@digi.no.

Skjermene på kontoret er mørke. Økonomisystemet er nede, lønn skal kjøres snart. Men du vet ikke hvem som jobber for deg, for all kontaktinformasjon til de ansatte er låst inne i et kompromittert system. Bedriften din har fått ransomware.

Og «hjelpen» gjør vondt verre. Etter å ha ledet håndteringen av snart 70 dataangrep, ser jeg én ting klart: Milliontapene skyldes ikke «avanserte» hackerangrep. De skyldes dårlige holdninger og inkompetanse i IT-bransjen. Disse fire er verst:

1. Mersalg av IT-driftstjenester

Leverandører foreslår raskt mer serverkapasitet, ny hardware eller cloud-migrering før angrepet er under kontroll. De fokuserer på å gjenopprette fra backup, men disse er ofte infisert.

Det siste du vil møte, er en leverandør som sier «vi jobber med det», mens de håper de kan google seg frem, skriver Louise Øverås Nilsen. <span>Foto: Privat</span>
Det siste du vil møte, er en leverandør som sier «vi jobber med det», mens de håper de kan google seg frem, skriver Louise Øverås Nilsen. Foto: Privat

Slik upselling (mersalg) og fokus på driftstjenester skjer spesielt når leverandøren ikke har kompetanse innenfor håndtering av sikkerhetsbrudd. Istedenfor å be kunden kontakte riktig ekspertise, selger leverandøren det de kjenner til – driftsløsninger.

Konsekvensene er tap av dyrebar tid i en akutt situasjon og at bevismateriale fra gamle systemer «slettes» for å gjøre plass til nytt. Det gir også risiko for at trusselaktøren (hackerne) «tas med videre» til ny maskinvare.

Og man vet fortsatt ikke hvordan trusselaktøren kom inn, så inngangsporten kan i verste fall misbrukes igjen for å komme inn i ny infrastruktur.

Hovedfokus de første 1–2 ukene må være digital etterforskning, sikring av systemene og mitigering av nye angrep. Dette gjøres ved å hente ut logger fra systemer og tjenester, finne initiell angrepsvektor (inngangsporten), spore trusselaktørens aktivitet og avdekke skadevare og bakdører – vor langt tilbake i tid trusselaktøren har hatt tilgang, hvilke backups som er «trygge» å bruke.

Man må forsikre seg om at aktørens aktivitet er kartlagt og at alle tilganger fjernes fra infrastrukturen før man begynner med oppgraderinger eller migrering.

2. Si «Ja, det er vi eksperter på!» og google

Stadig ser jeg en «fake it 'til you make it»-kultur: Leverandører lover ekspertise de ikke har, setter inn vanlige utviklere og bruker måneder eller år på oppgaver som et Incident Response-team løser på uker.

Men compliance-erfaring eller ISO-sertifiseringer er ikke det samme som praktisk erfaring med å stanse aktive angrep. Man kan ikke google seg frem.

3. Tidsestimater som flyttes og flyttes

«Vi ordner det i løpet av dagen»
«Nei, i morgen»
«Angrepet er mer avansert enn forventet – kanskje mandag»
«Det er et veldig sofistikert angrep, vi jobber fortsatt med det»

Det siste du vil møte, er en leverandør som sier «vi jobber med det», mens de håper de kan google seg frem. Dessverre er dette normen.

Tiltakene nevnt i punkt 1 medfører som regel tilnærmet hundre prosent nedetid i 1–2 uker. De fleste virksomheter tåler ca. 10–14 dager planlagt nedetid før de får avbruddstap som ikke kan innhentes.

Effektivitet er spesielt viktig de første 48–72 timene. Sikring og etterforskning må startes asap, og man må planlegge nedetiden og iverksette tapsbegrensende tiltak.

Jeg har aldri sett en IT-leverandør gjøre dette riktig selv. I stedet ser jeg både leverandør og kunden pushe mot å komme tilbake i drift før man vet nok om angrepet og inngangsvektor.

4. Skjuler egne feil

Ingen vil utlevere egne medarbeidere, miste kunden eller ende i erstatningsansvar.

Psykologien er forståelig, men gjør det vanskelig å få tilganger, informasjon om svakheter og mulige angrepsvektorer. Folk pusser på sannheten, sier de ikke vet, vil ikke forklare for mye.

Ofte må jeg snakke med ledelsen hos det rammede selskapet og leverandøren og avtale at man skal samarbeide uten å se på skyld og erstatningskrav.

Generelle råd

Jeg tror ikke nødvendigvis IT-driftsleverandører og skyleverandører vet at konsekvensene av denne praksisen under dataangrep blir så store. Dette er praksis som er kjent i driftsbransjen – og relativt akseptert. Men under dataangrep blir det krise.

Rådet mitt er enkelt: Slutt å anta at dere kan håndtere sikkerhetshendelser som driftshendelser. Dere tar dere vann over hodet. Dette er langt utenfor deres kompetanseområde.

Til leverandører med interne sikkerhetseksperter (ja, også dere på NSM-lista): Man ser seg blind på egne feil og mangler. Og selv om dere er helt redelige på punkt 1–3, er det ikke lett for ansatte å rapportere om egne feil når disse har forårsaket dataangrep.

Dessuten gjør ekspertene dette hver dag, deres «eksperter» gjør forhåpentligvis ikke det – da er noe veldig feil med sikkerheten deres.

Til kunder: Skaff bistand fra et eksternt IT-sikkerhetsselskap som er rendyrket på sikkerhet. Ikke bruk driftsleverandør eller interne ressurser alene.

Ikke stol på at leverandøren snakker sant når de sier de har eksperter, hør hvilket firma de bruker.

Hackere slo til mot IT-selskapets datasenter med et kryptovirus i april 2021. Nå krever de kjempeerstatning av svenskeide Nordlo.
Les også:

Mener svak sikkerhet hos IT-leverandør kostet dem 65 mill.

Kommentarer
Du må være innlogget hos Ifrågasätt for å kommentere. Bruk BankID for automatisk oppretting av brukerkonto. Du kan kommentere under fullt navn eller med kallenavn.