Sikkerhed
Ransomware går efter backuppen først — sådan kommer den ikke ind
Angribere sletter backup før de krypterer. Her er hvordan angrebet forløber, hvad uforanderlig backup faktisk beskytter mod, og hvad du kan nå at gøre.
Der er et forudsigeligt mønster i ransomware-angreb mod mindre og mellemstore virksomheder, og det er værd at kende, fordi det afgør, hvilke dele af en backupopsætning der faktisk hjælper. Krypteringen er ikke starten på angrebet. Den er slutningen — og som regel er backuppen allerede væk på det tidspunkt.
Hvorfor rammes backuppen først?
Fordi en fungerende backup fjerner grundlaget for at betale. Angribere har for længst indregnet, at professionelle virksomheder har backup, og derfor er en af de første opgaver efter at have fået fodfæste at finde og neutralisere backupsystemet. Det er ikke et sidespor i angrebet — det er forudsætningen for, at resten virker.
Fremgangsmåden er systematisk. Angriberen leder efter backupkonsollen, der ofte står på et domænemedlem med et navn, der ikke er svært at gætte. Derfra bruges de rettigheder, der allerede er hentet fra en kompromitteret administratorkonto, til at slette opbevaringspolitikker, tømme repositories og fjerne snapshots. Er backuplageret et NAS på samme netværk med en share, serveren kan skrive til, tager krypteringen sig af resten.
Tidsforløbet er den anden ting, der overrasker. Der går sjældent minutter fra første adgang til kryptering. Der går ofte uger, hvor angriberen bevæger sig rundt, samler rettigheder og kortlægger, hvad der er værd at ramme. I den periode kører backuppen videre og gemmer pænt kopier af et miljø, der allerede er kompromitteret. Det er derfor, opbevaringstid er et sikkerhedsspørgsmål og ikke kun et lagerspørgsmål.
Hvad gør en backup modstandsdygtig?
En backup er modstandsdygtig, når den ikke kan slettes af de konti, der styrer produktionsmiljøet. Alt andet — kryptering, hyppighed, komprimering — er sekundært i forhold til det ene spørgsmål: kan en kompromitteret domæneadministrator nå kopien?
Der er tre praktiske måder at bryde den forbindelse på, og de kan kombineres.
Uforanderlig lagring. Kopien låses skrivebeskyttet i en fastsat periode, og låsen håndhæves i lagringslaget. I den periode kan ingen ændre eller slette den — heller ikke backupsoftwaren selv, heller ikke en administrator, heller ikke nogen, der har stjålet begge dele. Det er den stærkeste enkeltforanstaltning, der findes mod ransomware, netop fordi den ikke er afhængig af, at nogen opdager angrebet i tide.
Adskilt adgang. Backupsystemet bør ikke bruge de samme konti som resten af netværket, ikke være medlem af samme domæne, og administratoradgangen bør kræve to faktorer. En kompromitteret Windows-administrator skal ikke automatisk være backupadministrator.
Fysisk eller logisk afkobling. En kopi, der ikke er tilgængelig over netværket i det daglige, kan ikke krypteres over netværket. Det kan være en frakoblet disk eller en cloud-kopi, som produktionsmiljøet ikke har skriveadgang til. Cloud-varianten er den, der holder, når disciplinen svigter — og disciplinen svigter.
| Opsætning | Beskytter mod kryptering af backup? | Svaghed |
|---|---|---|
| NAS på samme netværk, delt mappe | Nej | Nås af enhver konto med skriveadgang |
| NAS med separat konto og snapshots | Delvist | Snapshots kan slettes fra NAS-konsollen |
| Ekstern disk, roteres manuelt | Ja, når den er afbrudt | Afhænger af at nogen husker det |
| Cloud-backup uden uforanderlighed | Delvist | Kompromitteret backupkonto kan slette |
| Cloud-backup med uforanderlig opbevaring | Ja | Kræver at låseperioden er lang nok |
Hvor lang opbevaring kræver ransomware?
Opbevaringen skal dække hele den periode, hvor angriberen kan have været i netværket uopdaget — ellers gendanner du fra en kopi, der allerede indeholder problemet. Det er den enkeltparameter, der oftest er sat for lavt, og den koster ikke meget at rette.
Syv dages historik er nok til at redde en slettet fil. Den er ikke nok til at komme uden om et angreb, der har ligget og forberedt sig i tre uger, fordi alle syv kopier så stammer fra en kompromitteret periode. Genskaber du et system fra en sådan kopi, genskaber du samtidig bagdøren.
For kritiske systemer er 30-90 dage et mere realistisk udgangspunkt, og for filer med lang levetid — kontrakter, tegninger, projektdokumentation — er endnu længere fornuftigt. Prisen for ekstra historik er lavere end de fleste antager, fordi inkrementelle kopier og deduplikering gør, at kopi nummer 60 fylder langt mindre end den første; se hvad online backup koster for, hvordan historik slår igennem på regningen.
Husk samtidig, at ikke alle systemer skal have samme svar. En database med høj skrivefrekvens har brug for hyppige kopier og applikationsbevidste snapshots for overhovedet at være gendannelig; se database-backup. En filserver har brug for lang historik. Det er to forskellige opgaver.
Hvad med data i skyen?
Ransomware kan ikke bryde ind i Microsoft 365 eller Google Workspace direkte, men den behøver heller ikke. Krypteringen sker på en arbejdsstation, og synkroniseringen sørger loyalt for at sende de krypterede filer op i skyen som nye versioner.
Det er værd at forstå, fordi mange betragter skydata som beskyttede pr. definition. SharePoints og OneDrives versionshistorik kan i princippet rulle tilbage til rene versioner, men det skal gøres bibliotek for bibliotek, det kræver at man kender tidspunktet, og hvis angrebet har kørt længe nok til at fortrænge de rene versioner, findes de ikke længere. Hvad Microsoft faktisk gemmer og hvor længe, er gennemgået i artiklen om Microsoft 365-backup.
Den samme mekanik gælder ethvert synkroniseret drev. Har en server et mapped drev til backuplageret, er backuplageret en del af angrebsfladen. Det er hele grunden til, at princippet om en kopi uden for lokationen i 3-2-1-reglen er blevet et krav om en kopi uden for rækkevidde.
Hvad sker der, når det er sket?
Rækkefølgen efter et angreb er isolér, dokumentér, gendan — og gendan aldrig ind i et miljø, du ikke har renset først. Den mest almindelige dyre fejl er at haste en gendannelse igennem, fordi driften står stille, og dermed rulle den kompromitterede tilstand tilbage sammen med data.
I praksis betyder det: afbryd berørte systemer fra netværket, men lad være med at slukke dem, hvis der skal laves teknisk efterforskning, da hukommelsen kan indeholde spor. Log ikke på backupsystemet med konti, der kan være kompromitterede. Anmeld forholdet til politiet. Vurdér, om der er tale om et brud på persondatasikkerheden, som skal anmeldes til Datatilsynet inden for 72 timer — og om virksomheden er omfattet af underretningspligt efter NIS2-reglerne, hvilket er beskrevet i artiklen om NIS2 og backup.
Selve gendannelsen bør ske til rene systemer, i en prioriteret rækkefølge, der er besluttet på forhånd. At beslutte rækkefølgen midt i et angreb koster timer, virksomheden ikke har. Skriv i stedet ned i rolige omgivelser, hvilke fem systemer der skal op først, og hvad de afhænger af. Domænecontroller, økonomisystem og filserver ligger næsten altid øverst; se server-backup og backup af virtuelle maskiner for, hvordan bare metal- og maskingendannelse påvirker den rækkefølge.
Testen er det eneste bevis
En backup, der ikke er gendannet fra, er en hypotese. Det gælder også — måske især — når overvågningen har vist grønt i to år, for de fejl, der ødelægger en gendannelse, viser sig sjældent i jobstatus.
En kvartalsvis test behøver ikke være stor. Gendan en enkelt fil, gendan en hel mappe, og gendan et helt system til et isoleret miljø. Tag tid på hver af delene og skriv tallene ned. Sammenlign dem med, hvad I har lovet forretningen. Første gang er sammenligningen som regel ubehagelig, og det er hele pointen med at lave den, mens der ikke sker noget.
Test samtidig det, ingen tester: at I kan logge på backupsystemet, uden at Active Directory kører. Hvis adgangen til gendannelsen afhænger af det, der er nede, har I ikke en gendannelsesplan — I har en cirkelhenvisning.