"Hvor lang skal en beredskabsplan være?" Dette spørgsmål hører vi tit ude hos vores kunder. Mit svar plejer altid at være: "Så kort som muligt!" For sandheden er, at den perfekte beredskabsplan (hvis den overhovedet findes) skal være tre, nogen gange modstridende, ting på én gang:

Nu har jeg arbejdet med informationssikkerhed i en del år og har set mange forskellige politikker, regler, procedurer, forretningsgange, og andre former for dokumentation på sikkerhedsområdet. Det der virker bedst er, at have en klar, veldefineret opdeling, fx:

1. Politik: Vores ambitionsniveau og mål, hvad vil vi, hvem er omfattet. Bør være kort, gerne højst en side.
2. Regler:  Hvad gør vi, hvad gør vi ikke, hvad vi må og ikke må. Reglerne skal være præcise i forhold til, hvem der skal udføre de forskellige aktiviteter.
3. Procedurer: Sådan-gør-vi-dokumenter.

Effektivitet og produktivitet debatteres i mange sammenhænge. Også når vi taler informationssikkerhed, giver det mening at sikre, at virksomhedens processer fungerer effektivt. Men hvordan måler man om virksomhedens informationssikkerhed er effektiv, og om den udvikler sig i den rigtige retning?

I sidste uge udkom 2013-udgaverne af de udbredte standarder for informationssikkerhed, ISO 27001 og 27002. Det er 8 år siden de sidst blev opdateret, og de nye udgaver indeholder en række forbedringer, som bør interessere virksomheder, der læner sig op ad ISO 27001, eller som skal efterleve den.

ISO 27001 stiller stadig krav til et Information Security Management System (ISMS), som kan oversættes til "ledelsessystem for informationssikkerhed". Kravene falder stadig inden for de samme emner, og den rigtigt gode nyhed er, at virksomhederne har fået større frihed til at vælge, hvordan de i praksis efterlever kravene. Mere funktion, mindre form, som en af mine kollegaer udtrykker det.

Der kan være meget at vinde for forretningen ved cloud computing. Færre omkostninger, bedre effektivitet og højere sikkerhedsniveau er bare nogle af de fordele virksomheder kan få ved at flytte ud i skyen.

Men som med al anden it-outsourcing er der også mange trusler, så før du flytter ud i skyen, er det en god idé at lave en risikovurdering. Du skal beslutte dig for, hvilke data og applikationer du vil anbringe i skyen og hvilken type cloud-tjeneste, der passer til formålet. Du bør naturligvis også risikovurdere den udbyder, du overvejer at benytte.

Sikkerhedsniveauet i skyen afhænger af, hvilken løsning du ønsker at benytte dig af: Software as a Service (SaaS), Platform as a Service (PaaS) eller Infrastructure as a Service (IaaS). Som IaaS-kunde, vil du ofte skulle stå for store dele af sikkerheden selv, hvorimod du som SaaS-kunde i bund og grund abonnerer på udbyderens sikkerhed som en del af pakken.

It-outsourcing kan være en meget positiv oplevelse.

Du kan outsource din it-drift til nogen som har mere erfaring og ekspertise og kan gøre det mere omkostningseffektivt.

Men for at et outsourcing projekt skal lykkes, er du nødt til at have en ordentlig risikostyringsproces. En af de bedre metoder du kan bruge, for at undgå unødige risici, er information security risk management standarden ISO 27005.

Hvis din metode er på plads og en sikkerhedsstrategi er udførligt planlagt og kommunikeret ud til både din organisation og din outsourcing leverandør så har du intet at frygte. Men når det ikke er gjort ordentligt, kan det have en negativ indvirkning på din organisation.

En Trustwave Global Security rapport fra 2013 havde mindre positive nyheder om outsourcing. Rapportens bagmænd konkluderede at ud af 450 globale data sikkerhedsbrist undersøgelser var 63 procent af dem forbundet til en outsourcing leverandør.

Leverandøren ansvarlig for it-system support, udvikling og vedligeholdelse havde negliceret eller introduceret sikkerhedsmangler der nemt kunne udnyttes.

Resultaterne er slående ens med tallene fra en rapport i 2009, bestilt af VanDyke Software og udført af Amplitude Research. De konkluderede at 61 procent af deres 350 respondenter, hvis organisation havde outsourcet it-stillinger, havde oplevet uautoriserede indtrængen mellem 2007 og 2009.

Til sammenligning havde kun 35 procent af firmaerne, der ikke outsourcede, haft problemer med uautoriseret indtrængen.

Ingen bekymringer; træf passende foranstaltninger

Lad ikke de tal skræmme dig. Der er mange professionelle outsourcing leverandører derude.

Mange af de problemer rapporterne fremhæver er forårsaget af fejlkommunikation mellem organisationer og deres leverandører. Skylden kan derfor ikke placeres alene hos leverandøren men bør deles ligeligt af begge parter.

Når it-outsourcing bliver gjort ordentligt er det yderst gavnligt for både dig og din leverandør. Eneste det kræver, er at du træffer de passende foranstaltninger for at sikre en sikker og udbytterig outsourcing oplevelse.

Risikohåndtering (også kaldet risikobehandling eller "risk treatment") indgår i det lidt bredere begreb risikostyring. Før I kan håndtere jeres risici, skal I vide hvad jeres risici er, og derfor skal I først lave en risikovurdering. Metoden, som vi anbefaler her, tager inspiration i relevante standarder, i dette tilfælde ISO 27005, og tilfører nogle praktiske erfaringer og afprøvede teknikker.

Standarder for it-sikkerhed har mindst to kendetegn: De kan kurere eventuelle søvnproblemer og nogle af dem beskriver en relativ perfekt verden hvor de ansvarlige for it-sikkerhed har god tid og hvor der er ressourcer nok til at analysere behov og dokumentere beslutninger. Nu fik jeg måske startet dette indlæg lidt sarkastisk, men jeg er faktisk en relativ stor tilhænger af standarder og "best practice"; der er ingen grund til at genopfinde gode ting. Det med kedeligheden i standarderne kan jeg ikke gøre noget ved sådan direkte, men jeg har nogle forslag til at ansvarlige genveje til it-risikovurderinger, som kan hjælpe med pragmatisk efterlevelse af ISO 27001, den standard med mest medvind i Danmark. Genvejene hjælper dig med at spare tid.

Første genvej hedder ikke alle aktiver. Et aktiv i 27001 er ret bredt defineret som alt der har værdi for organisationen og standarden siger "identificer aktiver inden for scope". Jeg kender ingen virksomheder der har kortlagt samtlige aktiver. Du starter med at vurdere de vigtigste forretningsprocesser, ikke alt muligt andet. Og da slet ikke alt med et ip-nummer, hvis nogen hos jer skulle få den tanke. I kan senere udvide, så de services eller systemer, der understøtter jeres forretningsprocesser også bliver vurderet. Du og dine kollegaer har sikkert allerede en god fornemmelse for hvilke forretningsprocesser, der betyder mest. Genvejen her er et væsentlighedskriterie, så I får færre vurderinger og bruger tiden på de væsentligste.

Anden genvej er ikke alle trusler. Flere risiko-standarder indeholder ret omfattende trusselskataloger. Hvis I selv holder en brainstorm på alt det der kan gå galt, opdager du hurtigt hvorfor trusselskataloger bliver (for) lange. Genvejen her går ud på at I dele aktiverne op i typer, og kortlægge hvilke trusler der har relevans for hvilke aktivtyper. Eksempelvis er det ikke alle typer aktiver der kan brænde. Forretningsprocesser, it-services, logiske servere m.m. brænder ikke. Det er kun de mere fysiske af slagsen, som hardware og bygninger. Og selv inden for de fysiske aktiver kan I lave ansvarlige genveje ved kun at vurdere truslen fra brand på et datacenter, ikke enkeltvis på alt det udstyr der også står i datacenteret. Genvejen her giver færre trusselsvurderinger.

Op- og nedarvning er navnet på tredje genvej. God skik og standarder foreskriver at lave både BIA ("Business Impact Assessments" eller forretningskonsekvensvurderinger) og sandsynlighedsvurderinger. Sidstnævnte udføres ved at estimere jeres aktivers sårbarhed overfor de relevante trusler. I praksis ved jeg, virksomheder har mere end svært ved at lave begge former for vurderinger på rigtigt mange aktiver. Det er vanskeligt at lave sårbarhedsvurdering på fx en forretningsproces og også vanskeligt at lave en forretningskonsekvensvurdering på en server. Løsningen på denne udfordring er at kortlægge afhængigheder mellem aktiverne. I eksemplet skal du skrive på forretningsprocessen hvilke andre aktiver den afhænger af, altså aktiver som understøtter processen. Konsekvensvurderingen laves så "blot" på forretningsprocessen, og sårbarhedsvurderingerne laves "blot" på de understøttende aktiver. Forretningskonsekvensen arves nedad til de understøttende aktiver og sårbarhedsvurderingerne arves opad til forretningsprocessen fra de underliggende systemer. På den måde giver denne genvej færre konsekvensvurderinger og færre sårbarhedsvurderinger samtidigt med at det rent faktisk kan lade sig gøre at udføre de vurderinger, som der er behov for.

Fjerde og sidste genvej hedder overordnede vurderinger først. I en konsekvensvurdering forholder man sig typisk til om en sikkerhedshændelse forventes at påvirke indtægter, omkostninger, image eller kontrakt- og lov-efterlevelse. Fjerde genvej er at vurdere disse forhold samlet, ikke individuelt. Det samme gælder sårbarhedsvurderinger hvor beskyttelsesniveauet for flere trusler kan vurderes samlet. Indrømmet, det er en genvej, og du kan sikkert finde eksperter, der siger at dette ikke er godt nok. Jeg mener, at I efterfølgende får masser af muligheder for at raffinere og vurdere mere detaljeret, på de aktiver hvor det måtte give mening. Derfor er denne genvej helt ansvarlig, især hvis jeres organisation endnu ikke har fået gjort risikovurdering til en tilbagevendende, regelmæssig rutine.

Her er en kort opsummering af genvejene:
1. Ikke alle aktiver
2. Ikke alle trusler
3. Op- og ned-arving
4. Overordnede vurderinger først

Husk at risikovurdering og risikostyring - som alt andet sikkerhed - er en proces, ikke et projekt eller et øjebliksbillede. Den viden kan du bruge til at køre risikovurderingerne lempeligt i begyndelsen og bruge genvejene i stor udstrækning - senere kan du raffinere og præcisere ved fx at medtage flere aktiver, flere trusler, involvere flere personer (flere vurderinger) og/eller lave mere detaljerede vurderinger.

Med disse genveje sparer du tid og/eller kan komme i mål med ISO 27001 efterlevelse med mindre indsats. Helt ansvarligt.

Kan nogle af disse genveje bruges i din organisation, eller har du nogle tips til praktisk risikovurdering, som du vil dele?