Forstå de forskellige typer af beredskabsplaner

Det er ofte helt uklart, hvad man overhovedet mener med "it-beredskab", når man har en dialog om emnet.

‍

Mange steder blander man rundt i forskellige termer og definitioner, og det er heller ikke godt hjulpet af, at de forskellige standarder også bruger termerne forskelligt.

‍

Derfor har vi udarbejdet denne model, som skaber overblik over beredskabets elementer.

Lad os tale dig igennem modellen, og vi starter nedefra:

‍

Forudsætningerne for et godt beredskab

Felterne i bunden af modellen er virksomhedens grundlæggende forudsætninger for at beredskabet skal kunne fungere i praksis, og ikke blot være en organisatorisk øvelse. Dette fundament bør bestå af:

‍

6. Tekniske reetableringsplaner (Technical Recovery Plans/Disaster Recovery Plans)

Disse planer angiver en konkret trinvis opskrift på hvordan man reeablerer et system og hvilke forudsætninger, såsom licenser, backup, rettigheder m.m., der er nødvendige for at gennemføre reetableringen.

‍

Planerne skal kun indeholde de essentielle oplysninger som er nødvendige for reetablering, og skal ikke forveksles med systemdokumentation. Hvis I får brug for ekstern konsulentbistand til reetableringen, så skal denne plan indeholde de oplysninger som konsulenten har behov for, for at kunne udføre arbejdet.

‍

Planerne skal naturligvis placeres et sted, hvor man stadig kan komme til dem, selv hvis infrastrukturen er utilgængelig. Disse planer anvendes også under almindelige driftsnedbrud hvor systemer skal genskabes, og er altså ikke forbeholdt en krise.

‍

7. Scenariebaserede handlingsplaner

For at imødegå et forudsigeligt scenarie som vil påvirke flere systemer samtidig, kan man beskrive et handlingsmønster som er godt til den specifikke situation. Det er det du ser i en førstehjælpsbog, hvor der er en sekvens af handlinger som er forskellige for f.eks. brandsår og drukneulykker.

‍

Det er almindeligt at have en scenariebaseret handlingsplan for ransomware angreb. Den beskriver det reaktionsmønster som I har aftalt, med specifikke forberedte handlinger som kan modvirke at situationen udvikler sig negativt.

Kan f.eks. beskrive hvordan et netværk hurtigt opdeles i segmenter (også kaldet ø-drift) eller dele af netværket lukkes ned.

‍

En scenariebaseret handlingsplan kan automatiseret som scripts der udfører handlingerne hurtigt, da reaktionen skal kunne gennemføres inden for få minutter. Der bør være ledelsesmæssig godkendelse af disse planer, da de ofte påvirker virksomhedens aktiviteter dramatisk, og vil iværksætte en eller flere forretningsmæssige beredskabsplaner.

‍

8. Prioritering og afhængigheder

Hvis systemer skal reetableres, så vil det ske efter et ”kø-system” som it-afdelingen driver. Her reetablerer man først it-infrastruktur og derefter de systemer som er en forudsætning for at resten af systemerne kan fungere. Forretningen kan ud fra deres prioritering af systemernes vigtighed bede om at få reetableret i en bestemt rækkefølge som kan forberedes.

‍

Det gøres ofte på baggrund af en vurdering af de forretningsmæssige konsekvenser (betegnes Business Impact Assessment, BIA). Det er en forudsætning for, at man tager fat i de vigtigste systemer og services først, og at kritiske forretningsgange hurtigst muligt bliver reetableret.

‍

Da der ofte er flere forretningsområder, så skal de ansvarlige for forretningsområderne blive indbyrdes enige om deres prioriteringer, så der ikke er interne konflikter i en beredskabssituation. Denne rækkefølge kan naturligvis ændres i situationen, men det er langt hurtigere end at starte uden noget.

‍

Afhængigheder mellem systemer og services kan være sværere at afdække, hvis man ikke har en meget vedligeholdt CMDB (Configuration Management Database). Hvis det ikke er velbeskrevet, så er det en fordel at udarbejde nogle enkle skitser som viser grundlæggende afhængigheder, da det hjælper med at træffe beslutninger i en krise, og påvirker rækkefølgen af reetableringen.

‍

9. Robust design og arkitektur

En del af de problemer som et nedbrud eller et cyber-angreb medfører, kan reduceres på forhånd med et robust design af arkitektur og systemer. Man bør tilstræbe, at der er en sammenhæng mellem den kritikalitet et system vurderes at have og den robusthed der er i designet.

‍

Det er ofte en økonomisk vurdering, da det er kostbart at have redundante systemer.

Eksempler på robust design er redundante systemer, dublerede services, segmenteret netværk, backup designet til krise-reetablering og anvendelse af cloudservices som kan køre uafhængigt af on-premise systemer.

‍

10. Alternative Services er it-funktionens plan B

De forretningsmæssige beredskabsplaner vil beskrive de ønsker der er til nøddrift, og dette bygger på nogle alternative services som skal fungere i hverdagen, så de er klar i krisen.

‍

Det kan være en alternativ kommunikationsplatform eller daglige datadumps som kan sikre forretningens fortsatte drift. Disse services kan være ”sovende” indtil der er behov for dem og skal igen være uafhængige af eget netværk.

‍

Svarer til at man før i tiden printede lister ud hver dag, så de kunne bruges i en krise. Det kan man stadig, men tiden er løbet lidt fra denne tilgang, da det for ressourcekrævende og ofte ikke løser alle de behov man har.

‍

Den daglige drift

De blå felter er de områder, der hører til virksomhedens daglige drift. Hele dette område har den formål at sørge for, at en hændelse ikke udvikler sig til en krise.

‍

5. Driftsdelen (operations) består af:

• Forretningsprocesser er den almindelige forretningsdrift. Hvis den bliver udfordret, kan man iværksætte de forretningsmæssige beredskabsplaner (Business Continuity).
• Processer for almindelige hændelser (Incident Process) er et almindeligt og ofte lokalt problem. Det kan eksempelvis være at en medarbejders computer ikke fungerer.
• Processer for store hændelser (Major Incident Process) kan eksempelvis være når mange computere i selskabet ikke fungerer, eller flere kritiske systemer er ramt.

I venstre side af modellen kan du se en skala fra ét til fem. Det er en skala for hændelsens alvorlighed hvor 1 er det mest kritiske. Det mest alvorlige i en IT-driftsorganisation betegnes Major Incident. En eller flere Major Incidents vil ofte trække på alle de ressourcer som en it-afdeling har til rådighed, og betyde at det normale serviceniveau falder mærkbart.

‍

Når der sker en alvorlig hændelse, så går it-afdelingen straks i gang med at prøve at løse problemet med alle tænkelige midler. Kan det ikke lade sig gøre, så trykkes der på knappen og beredskabsledelsen går ind og overtager krisestyringen. Det sparer tid, at varsle beredskabsledelsen ved alle major incidents.

‍

Det vil typisk være en it-chef i virksomheden, der har it-kriseleder-rollen, og dermed beslutter om der er en beredskabssituation.

‍

Krisestyring og beredskabsledelse

Disse felter, handler om den del af beredskabet, som indløses i det sekund en hændelse er gået over og er blevet en krise. Herunder ligger områderne:

‍

2. It-kriseledelse (It Crisis Management)

Dette er it-afdelingens kriseledelse og er et lag ovenpå Major Incident arbejdet. Har køres der et war-room med klar rollefordeling og struktureret ledelse. Der tilføres ofte flere ressourcer og iværksættes beslutninger med et forberedt mandat.

‍

Det er her det store overblik holdes og der vil ofte være roller her som HR, Kommunikation, Koordinering, Forretningsledelse og Faciliteter.

‍

Her koordineres de langsigtede indsatser som prioriteres og kommunikeres til alle interessenter. It-kriseledelsen kan indhente støtte fra specialister udefra til at håndtere situationen og tager også ansvar for de afvigelser der vil være til politikker og retningslinjer.

‍

3. Opretholdelse af it nøddrift (It Service Continuity)

Dette for mange et næsten ukendt begreb og kan kun defineres og iværksættes i tæt samarbejde med forretningsledelsen. Nøddrift er ikke det samme som redundans, men vil ofte være alternative systemer eller dataudtræk som gøres tilgængelige på andre måder. Det kan være et regneark der er klar til at erstatte kvalitetsstyringssystemer, hvis de går ned.

‍

Det er ofte få data, der er behov for at lede sin virksomhed videre i en krise, men det er enormt vigtige data. Det kan godt være at man kan udlevere varer fra et lager med kuglepen og en blok, men det vil tage rigtig lang til at få disse data importeret, når systemerne er tilbage.

‍

Derfor er en alternativ digital løsning ofte bedre.

‍

4. Forretningsberedskab (Business Continuity)

Disse planer beskriver hvordan virksomheden kører videre, hvis man pludselig står uden sine it-systemer, eller andre afgørende ressourcer. Disse planer udarbejdes ikke af it-afdelingen men af medarbejderne som kender arbejdsprocesserne.

‍

De kender deres eget områdes daglige rutiner, behov og regler. Det er ofte dem der er ansvarlige for processer og forretningsområder som står for udarbejdelsen af de forretningsmæssige beredskabsplaner.

‍

Ofte bliver business continuity brugt som en paraply-beskrivelse for beredskab. Men det er bare ét område af det samlede beredskab, og uanset hvad du kalder det, så vær specifik.

‍

1. Overordnet krisestyring (Corporate Crisis Management)

Dette er hele organisationens kriseledelse. Hvis it er nede, kan det trække hele virksomheden ned, og så er hele virksomheden i krise. Så løser it-kriseledelsen, med it-direktøren i spidsen it-krisen, mens den overordnede kriseledelse varetages her. Her er det oftest CEO'en der sidder som kriseleder.

‍

Denne plan er ikke afgrænset til it-hændelser, men kan også rumme krig, ekstremt vejr, pandemier og lignende. Dog vil en it-beredskabshændelse meget ofte aktiverer hele virksomhedens beredskab, og derfor er det vigtigt, at der er et tæt og velfungerende samarbejde mellem de to krisestabe.

‍

Test af planerne

Alle planerne bør testes regelmæssigt med scenarier som er realistiske og udfordrende. Planerne skal testes individuelt for at gøre afprøvningen så konkret som mulig.

‍

Det er en god idé at udarbejde en testplan som strækker sig over tre år, så det ofte ikke er muligt at teste alle planer inden for 12 måneder.

‍

Afprøvningen af planerne skal være tilpasset et specifikt formål og have et passende ambitionsniveau. Det er vigtigt at der kommer konkret læring ud af afprøvningerne, og derfor kan man med fordel lægge en testplan som stiger i kompleksitet i takt med at man bliver bedre.

‍

Det kunne være i disse trin:

1. Peer-review af planen. Hvis dine kollegaer ikke forstår planen, så skal den sikkert rettes til. Planen læses igennem og tilpasses af en med tilstrækkelig faglig viden.
2. Scenariebaseret simulering. Planen afprøves i en simuleret hændelse som er tilpasset virksomheden. Handlinger begrænset til at være beskrivende og iværksættes ikke.
3. Teknisk afprøvning. Her prøves de dele af planen af, som ikke vil påvirke virksomhedens drift negativt. Det kan være en test af SMS-krisekommunikation, det kan være failover af enkelte redundante systemer eller kontakt til leverandører.
4. Drift afprøvning. Her prøves et scenarie af så tæt på virkeligheden som muligt. Systemer reetableres, samarbejdspartnere kontaktes og medarbejdere kan endda evalueres som en del af en brandøvelse. Dette er forbundet med væsentlige omkostninger og risici, og planlægges derfor grundigt i god tid forinden. Ofte vil elementerne i en live afprøvning være testet på niveau 3 inden de medtages i øvelsen.

Gode råd – og de menneskelige aspekter

Når en krise opstår, er det oftest nødvendigt at styre slagets gang med et militært mindset.

Der skal løbes stærkt. Beslutninger skal tages med hård og hurtig hånd, og medarbejderne bliver nødt til at yde en ekstra indsats. Derfor, skal man også have et øje på det menneskelige aspekt i krisen.

‍

Ofte bliver folk gennem et angreb presset meget hårdt igennem lang tid, måske døgnet rundt, og derfor kan de ikke mere på et tidspunkt. HR-funktionen vil spille en vigtig rolle i at varetage medarbejdernes trivsel, og forebygge stress og dårligt arbejdsklima. Det er også vigtigt at huske på, at de fleste medarbejdere ikke har en kontraktlig forpligtigelse til at arbejde ekstraordinært i en krise, og derfor skal håndteres med omtanke.

‍

Demant og Mærsk er eksempler på virksomheder, hvor et cyberangreb ramte og varede i flere måneder, og hvor nogle systemer aldrig kom til tilbage. Medarbejderne glemmer heller ikke hvor hårdt det var at være en del af hændelsen, og håndteringen bliver en del af virksomheden fremtidige image.

‍

Læg IKKE skinnerne mens toget kører

Det bør være selvsagt, at beredskabet skal være etableret inden et cyberangreb opstår. At bygge sit beredskab tager tid, og dét har du ikke meget af, når du bliver angrebet.

‍

Den tid der lægges i forberedelse og udarbejdelse af planer, den tages direkte ud af tiden til reetablering efter et cyberangreb. Det er ofte svære beslutningerne som skal træffes under et voldsomt tidspres, og det er bedre at have taget disse diskussioner inden hændelsen indtræffer. På den måde kan tempoet under et cyberangreb sættes op og der er mindre utryghed, da man kan holde sig til nogle kendte rammer.

‍

Hvis du vil søge inspiration til et godt beredskab, så se i retning af Forsvaret, Redningsberedskabet eller almindelig Førstehjælp. Her er metoder som er afprøvet i livstruende situationer, og tilpasset gennem generationer. Brug deres operationelle erfaringer og læg mærke til hvor enkelt og kortfattet metoderne ofte er.

Anbefalinger til inspirerende læsestof:

‍

·         The Checklist Manifesto, Atul Gawande

·         Battle Mind. At præstere under pres, Merete Wedell-Weddelsborg

·         Almindelig førstehjælp, Sundhed.dk

·         Forsvarets 5 punkts befaling, Forsvarsakademiet.

‍