Typiske fejl ved outsourcing af it-sikkerhed – og hvordan I undgår dem

Den mest almindelige fejl ved outsourcing af it-sikkerhed er at tro, at sikkerheden er "købt", når kontrakten er underskrevet. I praksis opstår problemerne i overgangene: enheder, der aldrig fik agenten installeret, alarmer, der sendes til en mailboks, ingen læser, en leverandør, der ikke må gribe ind, og en ledelse, der ikke ved, hvad aftalen dækker. Denne guide beskriver de mønstre, der går igen, og hvad I gør for at undgå dem. Mønstrene er generiske – de beskriver ikke bestemte virksomheder.

Guiden hører under faldgruber og officielle kilder.

Fejl 1: Huller i dækningen

Mønster: Agenten blev rullet ud på alle bærbare, men ikke på den gamle server i kælderen, der kører lønsystemet, eller på den virtuelle server i skyen, som en konsulent satte op. Angriberen kommer ind præcis der.

Modtræk:

• Lav en aktivliste, før aftalen starter, og sammenlign den med leverandørens liste over dækkede enheder.
• Kræv en månedlig liste over enheder, der ikke har rapporteret i over 7 dage.
• Gør det til en fast rutine, at nye enheder og cloudkonti meldes til leverandøren.

Fejl 2: Alarmerne lander ingen steder

Mønster: Leverandøren sender alarmer til en fælles mailadresse, som ingen overvåger om natten. Eller I får så mange lavprioritets-alarmer, at de kritiske drukner (alarmtræthed).

Modtræk:

• Aftal telefonisk eskalering for kritiske alarmer, med en vagtliste hos jer.
• Bed leverandøren filtrere og prioritere, så I kun får det, I skal handle på.
• Mål på antal eskalerede alarmer pr. måned og på, hvor mange der var reelle.

Fejl 3: Leverandøren må ikke handle

Mønster: Analytikeren ser kl. 3 om natten, at en server begynder at kryptere filer, men aftalen siger, at servere kun må isoleres efter godkendelse. Kontaktpersonen tager ikke telefonen. Kl. 7 er det for sent.

Modtræk: Lav en responsmatrix med forhåndsgodkendte handlinger og en reserveperson, der kan godkende resten. Se SLA og kontraktspørgsmål.

Fejl 4: Kun endepunkter overvåges

Mønster: MDR dækker computere og servere, men angrebet starter med en overtaget e-mailkonto og en falsk betalingsanmodning. Ingen computer blev inficeret, så ingen alarm.

Modtræk: Sørg for, at e-mail og identitet er dækket – med to-faktor-login for alle og overvågning af usædvanlige logins og videresendelsesregler. Se MDR og SOC som service.

Fejl 5: Backup er ikke en del af aftalen

Mønster: Overvågningen fungerer, men da et angreb alligevel lykkes, viser det sig, at backuppen lå på samme netværk og blev krypteret.

Modtræk: Klarlæg, hvem der ejer backup – MSSP'en, it-partneren eller jer selv. Kræv en kopi, angriberen ikke kan slette, og test gendannelse mindst én gang om året.

Fejl 6: Ingen ejer internt

Mønster: Aftalen blev indgået af en tidligere it-chef. Ingen læser de månedlige rapporter, og anbefalinger fra kvartalsmøderne bliver aldrig ført ud i livet.

Modtræk:

• Udpeg en intern ejer af leverandørforholdet med tid afsat.
• Lav en kort kvartalsstatus til ledelsen. Er I omfattet af NIS2, skal ledelsen alligevel godkende og føre tilsyn med foranstaltningerne (§ 7).

Fejl 7: Prisen vokser i det stille

Mønster: Antallet af enheder og logdata vokser, og prisen stiger hver måned, uden at nogen har besluttet det. Eller der betales for enheder, der for længst er kasseret.

Modtræk: Gennemgå fakturaen mod aktivlisten hvert kvartal. Aftal loft for logvolumen. Regn konsekvensen af fornyelse med prisstignings- og momsberegneren.

Fejl 8: Forsikringens krav er ikke mødt

Mønster: Forsikringen forudsatte to-faktor-login på alle konti med fjernadgang. En servicekonto havde det ikke. Det kan give diskussion om dækningen.

Modtræk: Læg forsikringens krav ind i kravlisten til leverandøren. Se cyberforsikring og krav.

Oversigt: fejl og modtræk

Øvelsesscenarie: brug det til en skrivebordsøvelse

Scenariet er opdigtet og beskriver ikke en virkelig virksomhed. Gennemgå det med ledelsen og leverandøren, og spørg ved hvert trin: Ville vi opdage det? Hvem ville handle? Forestil jer en virksomhed med 50 ansatte, der har købt MDR. Efter seks måneder går en medarbejder på en falsk loginside, og angriberen logger ind i e-mailen fra udlandet. MDR'en dækker kun endepunkter, så ingen alarm udløses. Angriberen opretter en regel, der videresender fakturaer, og sender en falsk betalingsanmodning til en kunde. Det opdages først, da kunden ringer.

Hvad der kunne have forhindret det: beskyttelse af identitet (usædvanligt login fra udlandet), to-faktor-login, der modstår phishing, og awareness-træning. Lærdommen er ikke, at MDR var et dårligt valg, men at dækningen ikke passede til risikoen.

Ofte stillede spørgsmål

Hvordan tjekker vi, om leverandøren faktisk overvåger?

Bed om en kontrolleret test: I udløser en ufarlig testalarm (efter aftale) og måler, hvor hurtigt leverandøren reagerer. Mange leverandører har en standardprocedure for det.

Hvem har ansvaret, hvis leverandøren overser et angreb?

Det afhænger af kontrakten og omstændighederne. De fleste aftaler begrænser leverandørens ansvar. Over for myndigheder og kunder er det typisk jeres virksomhed, der står til ansvar.

Hvor ofte skal aftalen gennemgås?

Mindst én gang om året og ved større ændringer, fx nye systemer, opkøb eller flytning.

Kilder

• SikkerDigital – 9 råd og hjælp, når skaden er sket
• Styrelsen for Samfundssikkerhed – trusselsvurderinger og vejledninger
• Retsinformation – NIS2-loven § 7 om ledelsens ansvar