Detta är en artikel i en serie om CIS Controls version 7 och denna artikel handlar om förmågan att spara och återläsa backuper. Detta är en sådan där åtgärd som många gånger är införd (i olika utsträckning) men som väldigt sällan testas ordentligt. Ni har en backup, men fungerar den att återställa? Och så finns det ju många olika typer av backuper. Det är svårt (som det så många gånger är) att skriva uttömmande om denna åtgärd, men betrakta denna artikel som initial och vägledande.
Nyckelinsikter
- Backuper är bra, återläsningstester är bättre.
- Det går inte att prioritera allt på en gång.
- Schablonvärde på vad ett givet IT-system tillför organisationen som grund för att mäta kostnaden om data försvinner.
- Börja enkelt, köp en NAS.
Inledning
Backuper. Det talas ofta om backuper. Den där självklarheten som alla vet att man ska ha, men som tyvärr många gånger införs nästan helt planlöst. Allt är viktigt, allt behöver backas upp. För mindre företag kanske det räcker med en NAS som alla datorer ansluts till. Men så fort storleken på företaget växer blir problembilden allt mer komplicerad. Databaser, virtualiseringskluster, kod, konfigurationer, offsite lagring, geografisk redundans, multipla datacenter osv osv. Backuper är en mycket mer komplicerad åtgärd än “att backa upp data”.
Om CIS-åtgärden
CIS-åtgärden består av totalt fem övergripande åtgärder och omfattar följande:
- Säkerställ återkommande och automatiska backuper
- Genomför fullständiga system-backuper
- Testa backuperna
- Skydda backuper
- Säkerställ att åtminstone backuper finns på ett ställe dit operativ-system inte har läs/skriv-rättigheter
Som alltid med CIS är det enkelt att summera saker i punktform, men själva genomförandet är avsevärt mycket mer komplicerat. Men det har jag redan sagt och känner att jag upprepar mig själv.
Åtgärdens målsättning
Målsättningen med åtgärden är uppenbar. I händelse av att data förloras ska du kunna återläsa det data som förlorats. Du vill kunna återläsa snabbt och minimera skillnaden mellan vad som förlorades och vad som återläses. Lättare sagt än gjort.
Införandet
Innan införandet av backuper förutsätter jag att ni har en relativt god förståelse för vad er organisation absolut inte kan förlora. Det handlar inte om att prioritera allt, det är inte rimligt. Det är rimligt att börja med sådana data som absolut inte får förloras. Vilka är det? Kanske är det uppenbart, kanske inte.
Steg 1 - Avgör mognad
Mognadsnivån ska inte ses som definitiv. Det är ett enklare försök att ge er själva en förståelse för ungefär vart ni står. Tanken är egentligen att mognadsnivån för samtliga CIS-åtgärder ska sammanställas så att ni får en överblick på vilka områden som ska prioriteras. Jag ser inte att mognadsnivån är direkt relevant för själva införandet.
| Mognadsnivå | Kriteria |
|---|---|
| Ingen förmåga | Backuper kanske finns, eller kanske inte. Vi har ingen direkt koll på vilka data som skyddas, vilka som går att återläsa, vad som testats och hur och när backuper genomförs. Det finns en del att göra. |
| Partiell förmåga | Vi har identifierat vilka system som är viktiga för oss, vi genomför backuper men måste erkänna att vi sällan testar om dessa faktiskt går att återläsa och att det fungerar vid återläsning. |
| God förmåga | De viktigaste systemen backas upp återkommande och automatiskt. Vi gör även automatiska återläsningstester regelbundet och planerar även för geografisk redundans av backuper. |
Steg 2 - Påbörja införande
Nåväl. Införandet, hur gör vi? Vad ska vi tänka på? Ett rimligt första steg är att konstatera eller klura ut vilka data som absolut inte går att förlora. Detta är antagligen något av ett detektivarbete. Det är inte alltid uppenbart. Det kanske finns något som hela organisationen lever på. En router-konfiguration går att klara sig utan, det är bara att börja om… däremot är svårare att klara sig utan en central filserver, eller ett CRM. Har ni ett databashotell med flera “kunder” (applikationer, tjänster osv.) kan det kanske vara vettigt att börja där.
Någonstans blir det också väsentligt att ha en backup-strategi. Kanske innebär denna strategi att när ni kommer i kontakt med nya data (nytt system som ska utvecklas, upphandlas etc.) konstaterar ni om systemet är “känsligt” ur ett minut/timme/dag/vecka-perspektiv. Kanske innebär det att vissa system inte inkluderas i backup, utan endast omfattas av en lokal snapshot. Vad vet jag. Men en backup-strategi brukar oftast bli aktuell i större organisationer med bredd på data, och när antalet system/applikationer närmare sig hundratalet.
- Se till att ni börjar… vänta inte.
- Identifiera vilka system, data eller information som ni absolut inte klarar er utan. Lätt för mig att skriva, men svårt att genomföra. Kanske uppenbart, kanske inte.
- Börja enkelt. Köp en NAS, kör en “bra” raid, koppla upp den mot nätverket och se till att dumpa databaser och automatiskt flytta över dit.
- Återläs, testa så att det verkligen fungerar som ni tänkt. Det räcker inte med att ni tror att ni har gjort en backup. En backup är gjord när den också har återställts och konstaterats fungera.
- Dokumentera vilka system, tjänster, applikationer, data och information som är inkluderade i backuperna och relevanta detaljer som när backuper tas, frekvens och när de senast testades.
Easy peasy. Lätt som en plätt…
Steg 3 - Mäta effektivitet
Som alltid är det svårt att mäta effektivitet för säkerhetsåtgärder. Men en utgångspunkt kan vara att försöka sätta ett monetärt värde på backuperna. Exempelvis kostnaden för nedtid mellan systemkrasch och återläsning. Inte enkelt att sätta värde på, men lite längre ner försöker jag ge lite inspiration.
För att mäta effektivitet skulle jag säga att följande kan vara vettigt:
- Har ni identifierat “viktiga” källor som rimligen bör backas upp? Besvaras med Ja eller Nej.
- Hur många av dessa backas upp? Notera antal.
- Hur många av de som backas upp är testade att fungera vid återläsning? Noter antal.
- Scenario: System X kraschar, hur lång tid tar det innan ni har återläst och fått igång systemet igen? Notera tid.
För (2) gäller en enkel beräkning om att 2/9 ger en mognad/effektivitet om cirka 22%.
För (3) gäller ungefär samma beräkning men istället utifrån procentsats från (2). Om 50% av systemen som backas upp testas regelbundet får ni en mognad/effektivitet om 22% * 50%, alltså 11%.
För (4) skulle ni, om ni kan, sätta ett schablonvärde på nedtid för systemet. Ni tar sedan detta schablonvärde och multiplicerar med timmarna det tog att återställa systemet. Kostnaden anger er effektivitet. Desto lägre, desto högre mognad/effektivitet i backuperna.
Räkna ut schablonvärde
Innan du läser det här förvänta dig en viss rörighet. Det är inte helt enkelt att följa mitt resonemang. Nog varning.
Kanske skulle det gå att räkna ut ett schablonvärde så här:
Antag att ni har en omsättning på 100 miljoner kr om året. Antag vidare att ni denna omsättning indirekt eller direkt är helt beroende av IT. Så i worst-case, ingen IT fungerar, så är omsättningen 0. IT hjälper er alltså att generera omsättningen.
Antag vidare att ni har 12 system som är fullständigt kritiska för att IT fungerar. 1 system representerar alltså 8,3 miljoner i omsättning, eller (100/12)…
Ett schablonvärde skulle således kunna vara 8,3 dividerat med antalet dagar per år (8,3/365) vilket ger en kostnad om 22 000 kr per dag i kostnader.
Är ett system nere i 12h skulle det således innebära en kostnad om 11 000 kr. Skulle samtliga 12 system vara nere i 24h blir kostnaden således 132 000 kr.
Aja. Se det som inspiration till hur ni eventuellt skulle kunna räkna ut ett värde på backuperna och genom det en viss möjlighet att sätta ett värde på effektiviteten i dessa.
Sammanfattning
Backuper. Vi talar ofta om vikten av dessa, men kanske inte riktigt ger det den kärlek det skulle behöva få. Backuper börjar med att identifiera vad som faktiskt är kritiskt, allt kan inte prioriteras. Därefter anser jag att det viktiga är att börja. Skaffa en NAS och börja lasta över backuper. Men också, testa. Huruvida det är bättre att backa upp massor och hoppas att det fungerar, eller backa upp ett fåtal system men som man faktiskt får någon slags garanti på att det fungerar…
Backuper är ett omfattande arbete och det finns mängder med fallgropar och komplexitet. Vid osäkerhet kan det som alltid vara värt att kontakta en “rådgivare” någon som har byggt erfarenhet genom flertalet misstag och nu förhoppningsvis har förståelse för detaljerna.