Kontinuitetsplan for IT-avdelingen, UiO
Innledning
Dette dokumentet beskriver metodikk og overordnet arbeidet med kontinuitetsplaner ved IT-avdelingen på UiO.
Relevante standarder
Det finnes en rekke standarder for kontinuitetsplanlegging. SIKT har utarbeidet en veileder for kontinuitetsplanlegging i sektoren, som vi delvis har basert vårt arbeid på. Géant har en veileder for business continuity planning som bygger på erfaringer fra sektoren i EU.
Det finnes en ISO-standard for Business continuity management, ISO 22301, og en NIST-standard NIST-SP800-34 som handler om Contingency planning.
Vi har valgt å basere vårt arbeid på SIKTs og Geants veiledning, med lokale tilpasninger, samt elementer fra ISO- og NIST-standardene der det er relevant.
I tillegg er det en del relevante nasjonale føringer som vi må ta hensyn til. Kunnskapsdepartementet har utarbeidet et styringsdokument for arbeid med sikkerhet og beredskap i sektoren. Dette dokumentet legger også føringer for kontinuitetsplanleggingen.
Det finnes dogså en policy for informasjonssikkerhet og personvern i høyere utdanning og forskning, gitt av rundskriv F-04-20. Denne policyen gir også retningslinjer for kontinuitetsplanlegging. Relevant er også at policyen sier at ledelsessystem for informasjonssikkerhet bør basere seg på anerkjente internasjonale standarder, for eksempel ISO/IEC27001, og denne standarden har også kontroller for kontinuitet. Vårt ledeslsessystem for informasjonssikkerhet bygger på prinsippene i ISO27001-standarden.
Annet relevant arbeid på UiO
Kontinuitetsarbeid har en tett sammenheng med beredskapsarbeid og hendelseshåndtering. Det finnes på UiO etablerte rutiner for beredskapsarbeid, en sentral beredskapsplan og etablerte ansvarsdelegeringer for å sikre beredskap ved større hendelser.
På IT-avdelingen finnes det og rutiner for hendelseshåndtering, og det er både etablert et driftssenter som har ansvar for driftshendelser og en CERT-gruppe som håndterer sikkerhetshendelser.
IT-avdelingen har i dag en systematisk tilnærming til ROS-analyser for systemer og prosesser som avdelingen har ansvar for.
IT-avdelingen har også en etablert plan for beredskapsøvelser, og gjennomfører årlige øvelser.
Vi har allerede en veileder for klassifisering av informasjon på UiO. Det er dog et spørsmål om i hvor stor grad vår informasjon er klassifisert ifølge veilederen, og om vi har kartlagt sammenhengen mellom de ulike IT-systemene våre og hvilken informasjon som lagres der.
Innhold i en kontinuitetsplan
Fra velederen fra eduCSC (SIKT)
«Kontinuitet handler om å kunne opprettholde aktivitet til tross for en uønsket hendelse, og å sørge for at verdiskapingen i et system, en tjeneste eller en arbeidsprosess holdes i gang»
Figur 1: BCM Lifecycle - ISO 22313:2020
Kontinuitetsstyring (Business continuity management) kan best sees som en kontinuerlig prosess, hvor flere steg inngår i prosessen. Iso 22313 har en kontinuerlig prosess som består av business impact analysis og risk management, en kontinuitetsstrategi, etablering av prosedyrer(Figur 1: BCM Lifecycle - ISO 22313:2020).
Figur 2: PDCA-syklus i kontinuitetsplanlegging
Kritikalitetsanalyse
Grunnlaget for en kontinuitetsplan er risikovurdering, verdivurdering og en kritikalitetsanalyse. Risikovurderingen forteller oss hvile usikkerhetsmomenter vi må ta hensyn til, og hva slags scenarier vi må være forberedt på at kan inntreffe. Verdivurderingen forteller oss hva slags informasjon vi har som trenger beskyttelse. Kritikalitetsanalysen forteller oss hvilke systemer vi trenger å beskytte.
Når man ser nærmere på problemstillingen som ligger bak en kritikalitetsanalyse så ser man at det en kompleks problemstilling. Ett enkelt IT-system kan støtte opp under flere av organisasjonens prosesser, og én enkelt prosess kan være avhengig av flere IT-systemer. Ett IT-system kan behandle flere typer informasjon av ulik verdi, og kan være utsatt for flere ulike risikoer. For å gjøre en god analyse av kritikalitet, så krever det derfor en god innsikt i både organisasjonens prosesser, i hvilke data som prosesseres og hvilke risikoer man er utsatt for. Et system kan ha mange eller få brukere, og det kan være et viktig system for mange eller få brukere. Det kan også være slik at et system har ulik kritikalitet i ulike perioder. Et eksempel på dette kan for eksempel være systemer for eksamensavvikling, som vil ha en høy kritikalitet i eksamensperioden, men som godt kan ha lange perioder med utilgjengelighet for eksempel om sommeren.
IT-avdelingen har ansvaret for over 150 ulike IT-systemer av varierende grad av viktighet. I forbindelse med UH-sak er det kartlagt nærmere 400 ulike administrative prosesser ved universitetet, men det er også i tillegg en lang rekke prosesser ved universitetet som ikke passer under paraplyen «administrativ prosess», så det faktiske tallet er nok langt høyere.
Å gjøre en god kartlegging av hvordan alle disse IT-systemene og alle prosessene henger sammen, og deretter rangere de ut fra et kritikalitetsbegrep vil være en omfattende oppgave, som ideelt sett bør involvere tverrfaglige team med både prosesseiere og ekspertise fra IT-siden.
Vi har i stedet valgt en enklere tilnærming, men i vårt rammeverk for kontinuitetsplanlegging har vi også lagt inn et prinsipp om at vi skal jobbe med kontinuerlig forbedring. Tilnærmingen blir dermed at vi gjennomfører en enklere kritikalitetsanalyse som gir oss et utgangspunkt å jobbe videre med. I en revidert versjon av kritikalitetsanalysen vil det være aktuelt å gå mer i dybden på de systemene vi tror er viktigst, og gjøre en grundigere analyse av disse.
Arbeidsgruppe for kritikalitetsanalyse
I Géants veileder skisseres det en enklere prosess for kritikalitetsanalyse, som vi har valgt å bygge vår prosess på. I tillegg har vi tatt med noen elementer fra SIKTs veileder for kontinuitetsplanlegging i denne delen av vår prosess.
I vår prosess har vi en ekspertgruppe med noen få personer fra ulike deler av IT-avdelingen, som sammen går gjennom IT-systemene våre. Systemene rangeres på en skala fra 1-4 på to ulike områder: Hvor kritisk er det for UiO at tjenesten faller bort, og hvor stor økonomisk påvirkning vil det ha for IT-avdelingen at en tjeneste faller bort - altså hvor store økonomiske forpliktelser har vi ovenfor tredjepart. Vi har gjort denne vurderingen på ulike tidsakser: Opp til én dag, opp til én uke og over en uke. Den høyeste verdien fra denne vurderingen avgjør tjenestens kritikalitet, mens tidsaksen avgjør hvor rakst en kontinuitetsplan må kunne gjennomføres.
Vi antar at denne prosessen, selv om den ikke klarer å fange opp alle nyanser, vil gi et tilnærmet riktig resultat, og gi et godt utgangspunkt å jobbe videre med. I en senere fase vil det være naturlig å gå mer i dybden på analyse av de mest kritiske systemene fra den første analysen, se nøyere på avhengigheter, og på hvilke prosesser systemet inngår i, og samarbeide med prosesseiere om en vurdering av kritikalitet for disse.
I vår prosess har vi fokusert på IT-systemer hvor IT-avdelingen har et ansvar for leveransen av tjenesten. Vi har altså ikke gått inn i rene skytjenester som brukes av virksomheten, selv om noen av disse antas å være virksomhetskritiske.
I første runde har vi valgt å jobbe fra topp 5-listen fra kritikalitetsanalysen.
Kritikalitetsanalyse og «Business Impact Analysis»
Analyse av kritikalitet danner grunnlaget for å lage det som kalles «business impact analysis» i de internasjonale standardene.
Den tradisjonelle måten å gjøre det på er å gjøre en «bottom-up» tilnærming, hvor man kartlegger alle organisasjonens prosesser, og ut fra dette kartlegger hvor kritiske de er for organisasjonen, og hvilke konsekvenser bortfall har for virksomheten.
En slik kartlegging vil være ekstremt tidkrevenede i en stor organisasjon, og vi har derfor valgt en omvendt «top-down»-tilnærming, som er tilnærmingen som er anbefalt av Géant, såkalt «LEAN BCM».
I vår prosess gjør gjør vi først en kritikalitetsanalyse som en top-down-øvelse, hvor vi først gjør en overordnet vurdering av tjenestene våre med en gruppe eksperter i organisasjonen.
Denne kritikalitetsanalysen danner grunnlaget for en analyse av konsekvenser for virksomheten.
Man skiller mellom en system-basert og en prossess-basert Business Impact Analysis. I vår analyse fokuserer vi på systemer. En BIA vil forsøke å identifisere prosesser i organisasjonen som er avhengige av systemet, og bestemme maksimal nedetid for systemet. BIA skal også inneholde en ressurskartlegging – hvilke ressurser er avgjørende for å drifte systemet. Dette omfatter både personer, men også avhengigheter av andre systemer.
I løpet av BIA fastsetter man Recovery Time Objective (RTO) – som angir et mål for hvor lang tid man kan bruke til å gjenopprette en tjeneste, samt Recovery Point Objective (RPO), som sier hvor langt tilbake det er tolererbart å miste data. RPO er styrende for systemets backupstrategi, og tilsammen angir RTO hvor lang tid et system er utilgjengelig, og hvilken tilstand det er i når det kommer tilbake i drift.
I et virksomhetsperspektiv er det også vanlig å snakke om MTD – Maximum Tolerable Downtime for en forretningsprosess. RTO skal settes slik at man er godt innenfor denne grensen. Siden vi jobber med systemer og ikke direkte med forretningsprosesser her, så holder vi oss til å RTO og RPO i vår analyse. Vi forsøker imidlertid å holde blikket oppe, og setter disse verdiene basert på vår kjennskap til organisasjonen, eventuelt etter dialog med eiere av de prosesser om benytter et gitt system.
Siden vi gjør en top-down-tilnærming så vil vi starte med en grov rangering av systemene, og analysere de systemene vi anses for å være viktigst. I neste fase vil man i løpet av iterasjoner av kontinuitetsarbeid jobbe med de resterende systemene og prosessene – etter synkende viktighet.
Ledelsesforankring
Vi sikrer forankring i ledelsen ved at:
- Arbeidet med kontinuitetsplanlegging er initiert av IT-direktøren
- Overordnet policy for kontinuitetsplanlegging er vedtatt av IT-direktøren
- Det er satt av ressurser i organisasjonen til å jobbe med kontinuitetsplaner og kontinuitetsplaner er en del av årsplanen, og fremdrift og status rapporteres til universitetsledelsen
Det er utarbeidet en overordnet policy for kontinuitetsplanlegging, som er vedtatt av IT-direktøren. Planen definerer formål, omfang, roller og ansvar for arbeidet med kontinuitetsplanlegging.
I tillegg til den overordnede policyen har dette tjener dette dokumentet som en veiledning i kontinuitetsarbeid ved IT-avdelingen.
Strategi for kontinuitetsarbeid
Det er to viktige elementer i en strategi for kontinuitetsarbeid:
- Forebyggende tiltak
- Gjenopprettingsstrategier.
Forebyggende tiltak bør være en del av en kontinuitetsstrategi, for kostnaden ved å være proaktiv er vanligvis langt lavere enn å håndtere en driftsstans. I alle tilfeller bør strategien inneholde en vurdering av kost/nytte, og det bør ligge en vurdering av risiko i bunn.
For gjenopprettingsstrategier så er det ulike alternativer. Eksempler kan være gjenoppretting fra sikkerhetskopi eller gjenoppretting av tjenesten på en alternativ lokasjon.
Gjenopprettingsstrategien og forebyggende tiltak må være tilpasset hver enkelt tjeneste – ut fra hva som er hensiktsmessig for tjenesten. Det kan være en fordel om strategien utformes under design av tjenesten, og kan ofte med fordel være tett integrert med det tekniske designet av tjenesten.
Under arbeidet med kontinuitetsstrategi må man sikre at strategien er i tråd med overordnet policy for kontinuitetsarbeid, og sikrer kravene som er gitt av BIA. Kontinuitetsplaner for hver tjeneste.
Ut fra strategien utarbeides det en konkret plan hvor strategi og prosedyrer for tjenesten er dokumentert. I planen er det dokumentert
- aktiveringskriterier
- Varslingsprosedyrer
- Prosedyrer for gjenoppretting
- Prosedyrer for normalisering
Planen skal være kort og oversiktlig, for å være håndterbar under en krise. I denne delen er det ikke detaljert utredning om de ulike scenariene e.l, kun fokus på hvordan man rent teknisk har bestemt seg for å gjenopprette og normalisere tjenesten. I tillegg er det beskrevet eskaleringsveier, planer for hvordan man eventuelt erstatter kritisk personale og henvisning til andre relevante planer – spesielt hendelseshåndtering for sikkerhetshendelser, overordnet beredskapsplan og kommunikasjonsplan.
Testing, etablering og øvelser
Etter at de konkrete planene er etablert må det lages en overordnet plan for hvordan man implementer planen i organisasjonen. En god plan for implementering inneholder:
- Opplæring av personell og trening – for eksempel gjennom kurs, dokumentasjon og annen internopplæring
- Øvelser, hvor målet er å validere planen, men også å øke kompetansen i organisasjonen
- Testing av systemkomponenter og prosedyrer, for eksempel test av backup, redundans osv.
- Evaluering av testing, øvelser og opplæring – med dokumentasjon av resultater og læringspunkter.
IT-avdelingen gjennomfører normalt to beredskapsøvelser i løpet av hvert år. Det er naturlig at minst én av disse øvelsene utformes på med tanke på å teste gjennomføringen av kontinuitetsplaner.
I tillegg bør de seksjonene eller teamene som har ansvaret for systemer som er regnet som kritiske ha sine egne tester eller øvelser, hvor de går gjennom de spesifikke punktene i sin kontinuitetsplan, og tester for eksempel backup-prosedyrer eller gjenoppretting av tjenester på alternativ lokasjon.
Kontinuitetsarbeid i sektoren
DSB veileder for kontinuitetsplanlegging
Sikt veileder for kontinuitetsplaner for informasjonssikkerhetshendelser
Sikts veiledere fra cybersikkerhetssenteret
Géants veileder for business continuity planning