Risikovurdering - hvad bruger vi dem til?

Af Jakob Holm Hansen, Senior Security Advisor hos Neupart / KMD

Det er efterhånden blevet god praksis at lave risikovurderinger - eller i hvert fald erkende, at man bør lave dem.

Alt for ofte ser vi desværre, at virksomheder bare udfører risikovurderinger for at efterkomme et eller andet compliance-krav (revision, kontrakt, lovgivning m.v.). Hvis man er heldig, får man endda ressourcer til at gennemføre dem en gang om året. 

Man gennemfører sin risikovurdering, taler med sin organisation og laver en fin rapport til sidst. Og så er "projektet" afsluttet. Men det er en fejl at se risikovurdering som et projekt. Risikovurdering skal være en proces. En proces der er tilbagevendende og kontinuerligt justeret.

I ISO27001-standarden er risikovurdering en dynamo for sikkerhedsarbejdet

» Det er vores risikovurdering, der er udgangspunktet og den trækker tråde ud i hele vores ISMS
» Det er vores risikohåndteringsplan, vi skal anvende til at udvælge de rigtige sikkerhedsforanstaltninger i vores virksomhed
» Det er vores risikovurdering, der er med til at sikre ledelsesforankring og identificere forretningens krav

Og hvordan gør vi så det? 

Vi må tage et aktivt valg om at anvende risikovurderingen. Vi må ændre vores kultur omkring risikovurderingen.

Helt konkret skal man, som en del af risikovurderingen, gøre følgende:

• Fastlægge "risk acceptance criteria", eller risikoappetit - altså hvor meget risiko er vi villig til at acceptere før vi skal handle
• Beslutte kriterier for hvornår vi skal risikovurdere, f.eks. når vi får nye systemer eller ændrer i infrastrukturen - med andre ord er det en dynamisk proces, og ikke bare noget vi skal gøre én gang årligt
• Evaluere vores resultater - ligger vores risici over eller under vores risikoappetit?
• Håndtere vores risici - når vi har fundet nogle risici der ligger ud over vores risikoappetit, så skal vi gøre noget ved det!

Håndtering af risici

Eller "risk treatment" som det hedder i ISO27001/5, er den del af processen, der bringer risikovurderingens resultat ind i resten af vores ledelsessystem for informationssikkerhed.

Når vi skal håndtere identificerede risici, der ligger over vores risikoappetit, gør vi følgende:

1. Vi definerer hvad vi vil gøre ved risikoen
• Reducér risikoen - flere sikkerhedstiltag, større sikkerhed, nye regler
• Eliminér risikoen - vi nedlægger systemet eller processen der resulterer i risikoen
• Overfør risikoen - forsikring ift. risikoen, outsourcing til tredjepart
• Acceptér risikoen - det er for dyrt at gøre noget ved risikoen, så ledelsen accepterer den
2. Vi etablerer handlingsplaner for de risici, vi har besluttet at gøre noget ved
• Hvad skal der gøres (se pkt. 1)?
• Hvem er ansvarlig?
• Hvornår er deadline?
• Hvor høj er prioriteten?
3. Vi følger op på handlingsplanerne
• Har de ansvarlige lavet deres arbejde?
• Hvor kan vi se resultatet?
4. Vi følger op på vores risici
• Opdatering af risikovurdering der hvor vi har gennemført handlingsplaner
• Er risiko forøget?
• Er risiko dalet?
• Kan vi stadig acceptere de risici vi har accepteret?

Hvis vi anvender eller efterlever ISO27001, så vil de risici vi har identificeret samt de identificerede handlingsplaner, skulle kunne linkes over til vores "Statement of Applicability". Derved sikrer vi også en rød tråd hele vejen ned til vores sikringstiltag og kontrolmål.

Risikohåndteringen kan blandt andet også stille krav til, hvordan vi implementerer:

• Beredskabsplaner
• Awareness
• Intern audit
• Metrikker
• Håndtering af sikkerhedshændelser
• etc.

Afslutningsvis vil jeg huske jer på, at risikovurdering ikke er noget I skal lave for jeres revisors skyld, det er noget I skal lave for jeres egen skyld. For det er et utroligt vigtigt og stærkt værktøj til at implementere jeres informationssikkerhed med. Så brug det!

Øvrige ressourcer

Vejledning i risikostyring
Et af de styrende elementer i ISO 27001 er kravet om, at informationssikkerheden 
baseres på de reelle risici, organisationer er udsat for. Samlet set kaldes denne aktivitet 
for risikostyring. Neuparts 8-siders vejledning til risikostyring er udarbejdet med udgangspunkt i standarden for Risk Management, ISO 27005. Du kan hente den her


Læs desuden om, hvordan KMD Secure ISMS hjælper dig med effektive risikovurderinger og risikohåndtering,  og med at få styr på sikkerhedsopgaverne

PS KMD Secure ISMS er det nye navn for SecureAware, løsningen som Neupart har udviklet.

De næste ofre efter Nets / IBM / Se & Hør-sagen

Efter den massive omtale af datalækagen, hvor en tidligere IBM ansat er anklaget for at sende oplysninger om kendte fra Nets til Se & Hør, er der mange virksomheder der med god grund tænker "Kan noget tilsvarende ske for os?" og som er ved at træffe ekstra forholdsregler. Hvordan kan vi undgå at det sker for os? Hvor meget sikkerhed er det rimeligt og fornuftigt at indføre?

Hvis den anklagede dømmes, er der tale om en kriminel medarbejder (IBM) og kriminel ekstern konsulent (Nets). Kan man undgå det? Typiske forebyggende forholdsregler er baggrundscheck, ren straffeattest, måske en sikkerhedsgodkendelse m.m. Jeg tror ikke disse redskaber havde kunnet afværge den aktuelle datalækage. Og hvis man indfører for meget af den slags tiltag, laver man en formentlig unødvendig og måske skadelig mistænkeliggørelse af personer, man hellere skal have et godt arbejdsforhold til.

Men der er andre for sagen aktuelle områder, hvor jeg vurderer at flere - måske mange (?) - virksomheder bør overveje om de gør tilstrækkeligt:

1. Brugerstyring: Tildeler vi for mange rettigheder til medarbejdere og konsulenter i forhold til hvad der er nødvendigt? Rydder vi op efter os når nogle skifter job internt eller forlader os? Især vigtigt i forbindelse med it-folk, der får privilegeret adgang.
2. Logning: Kan vi med rimelig sandsynlighed opdage hvis en betroet medarbejder misbruger sin adgang? Logning og overvågning skal doseres rigtigt efter behov. Behov er oftere til stede, når der er tale om privilegeret adgang.  
3. Reaktion på revisionsrapporter: Hvis der påpeges svagheder eller det der er værre, reagerer vi så på det? Har vi en proces, der sikrer opfølgning?
4. Reaktion på sikkerhedshændelser: Hvis der sker noget eller kunder gør os opmærksomme på et problem, reagerer vi så på det? Og igen: Har vi en proces, der sikrer opfølgning?

Om ovenstående generelle vurderinger også holder hos jer kommer selvfølgelig an på hvem "I" er - det kræver en mere individuel vurdering. Har jeg glemt nogle tiltag I kan kigge på?

Min kollega Gaffri Johnson er gået mere i dybden med emnet i dette indlæg.

Nets-sagen - kan vi overhovedet undgå lignende sager?

Af Gaffri Johnson, Neupart

Det er typisk eksempler i udlandet vi hører om, når snakken falder på datalækager og misbrug af følsomme data. I Danmark har vi ikke set mange større sager - det har oftest været mindre lækagesager og de fleste har omhandlet personer i det politiske liv.

Risikomæssigt vil det derfor være nærliggende at tro, at det ikke er disse typer af trusler, danske virksomheder  skal bruge kræfter på at imødekomme. Men spørgsmålet er, om den menneskelige faktor ikke altid vil være det svageste led i forhold til de tiltag virksomheder gør for at indføre den rette mængde informationssikkerhed.

“Medarbejdere vil i et vist omfang altid være jokeren og derfor også en oplagt  angrebsvektor”

Det er min påstand, at det er nemmere at regulere informationssikkerheden med tekniske og procesmæssige tiltag end at kontrollere medarbejdere. Det er faktorer såsom manglende viden og motivation - hvad enten det er politiske, økonomiske eller andre motiver, der driver medarbejdere, bevidst eller ubevidst. Medarbejdere vil derfor i et vist omfang altid være jokeren. Og derfor også en oplagt angrebsvektor for dem der ønsker at få fat på data uanset om det er den kulørte presse, konkurrenter, eller folk der ønsker at foretage industrispionage, politisk motiverede handlinger såsom APT-hændelser (Advanced Persistent Threats*), økonomisk kriminalitet eller terrorvirksomhed.

I kraft af at vi bliver bedre og bedre til at beskytte os med softwareunderstøttede løsninger, og flere virksomheder læner sig op af diverse sikkerhedsstandarder eller bliver certificeret, vil den menneskelige faktor blive et mere interessant mål eller potentiel angrebsvektor.

“Se og Hør udnytter akilleshælen og den sværest kontrollerbare faktor i informationssikkerhed, nemlig medarbejderen”

Afdækningen af de aktuelle hændelser hos Nets og IBM viser, at rejseselskaber og hospitalsvæsenet også er involveret i datalækager. Se og Hør er bl.a. blevet tippet flere gange om kendte menneskers rejsevaner og hospitalsbesøg. Se og Hør udnytter akilleshælen og den sværest kontrollerbare faktor i informationssikkerhed, nemlig medarbejderen.

Hvis Se og Hør har mulighed for at få fat i disse oplysninger, hvad holder så kriminelle fra at benytte tilsvarende metoder til økonomisk kriminalitet eller industrispionage? Jeg tror, at virksomheder må erkende, at det ikke er muligt at forhindre lignende sager i at opstå. Det er en del af de risici man må acceptere. Hvis man vil forsøge at lukke helt ned for muligheden for datalækage, vil det næsten gøre det umuligt at drive forretning. 

“En balanceret og pragmatisk tilgang er mest effektiv”

Det vil derfor altid være en balanceret og pragmatisk tilgang, der er mest effektiv. Virksomheder må derfor altid acceptere en rest-risiko, forstå implikationerne ved denne rest-risiko og planlægge derefter. 

Det vil nok undre mange, at virksomheder som Nets og IBM, der i høj grad er med til at formidle og administrere den digitale kritiske infrastruktur, ikke i højere grad selv har formået at skabe tillid omkring deres sikkerhed. Og mange vil ligeledes undre sig over at sikkerhedsrevisioner - omfattende revisorerklæringer og PCI DSS audits, ikke har formået at afdække den dårlige arbejdskultur og de smuthuller, der blev benyttet.

Sådan mindskes risiciene og konsekvenserne, hvis uheldet skulle være ude

Baseret på den tilgængelige viden - med forbehold da vi ikke kender de præcise omstændigheder, følger her vores bud på processer, der kan være med til at mindske risiciene for datalækage.

a)  Uheldig medarbejderadfærd
Ifølge flere kilder var det ikke unormalt, at medarbejdere lavede opslag i kreditkorttransaktioner for at følge med i ægtefællers eller kæresters transaktioner. Dette vidner om en uhensigtsmæssig arbejdskultur.

• Informationssikkerhedsfunktionen og ledelsen har et ansvar for at specificere adfærdsregler og normer samt at forankre disse. De bør også have tilstrækkelig indsigt i virksomhedens arbejdskultur til, at de kan fange uhensigtsmæssig adfærd inden det bliver et problem.

b)  Rolle og rettighedsstyring
Hvis ikke adgange til systemer er veldefineret, risikerer en virksomhed at medarbejdere har adgang til systemer og data, de ikke bør have adgang til.

• Roller og rettigheder bør forankres i forhold til de opgaver de enkelte medarbejdere udfører. Princippet ”on a need-to-know basis” bør gennemsyre adgangsprocesserne til alle de kritiske systemer. 
• Profiler skal altid være personhenførbare. 
• Principper for funktionsadskillelse skal være beskrevet og implementeret for alle kritiske systemer. 
• Virksomheden skal have et overblik over alle kritiske systemer, hvor data befinder sig (i transit, lagret og behandlet). 

c)  Håndtering af medarbejdere med udvidet rettigheder
Nets-hændelsen viser med al tydelighed, at processerne omkring administratoradgange ikke har været helt på plads. Det er essentielt at disse roller er lagdelte og opfylder nogle basale sikkerhedskrav:

• Profiler med udvidede rettigheder har alt for ofte for mange rettigheder på tværs af alle systemer. ”On a need-to-know princippet” bør også omfatte profiler med udvidede rettigheder, fx. administratorroller og tilsvarende. Rettighederne bør tilpasses de specifikke administrative opgaver, de udfører.
• Alle administratorer skal være underlagt logning af deres egne handlinger på kritiske systemer.
• Administratorer skal fx. ikke kunne oprette, ændre eller slette andre privilegerede brugere. Det bør håndteres som en del af IAM-processen og af særskilte funktioner i virksomheden. Igen bør princippet om funktionsadskillelse gælde.
• Profiler med udvidede rettigheder må ikke have adgang til at kunne ændre logindstillinger for system- og brugeraktivitet. Rettigheder til disse funktioner bør håndteres af en særskilt profil.

d)  Hændelsesstyring og it-beredskabet 
Mangelfulde processer for hændelsesstyring og it-beredskabet kan være afgørende for at minimere skader forbundet med sikkerhedshændelser. En effektiv og struktureret proces for hændelsesstyring er også med til at øge sandsynligheden for et vellykket efterforskningsarbejde i kølvandet på en sikkerhedshændelse.

• Der skal være etableret en hændelsesstyringsproces der bl.a. indeholder konkrete beskrivelser og procedurer for eskaleringen frem til en evt. aktivering af beredskabsplanen.
• En virksomhed der håndterer personfølsomme oplysninger skal desuden have indarbejdet hensyn til disse i deres hændelsesstyringsprocesser og beredskabet. Der skal desuden foreligge en klar og præcis kommunikationsstrategi. 
• Beredskabsplanen skal være med til at sikre en hurtig genoprettelse af ydelser, men også tilliden til virksomheden. Der har været flere hændelser i 2014 med bl.a. Nets og Rejsekort, hvor kommunikationsdelen af deres beredskab ikke har været skarp nok, hvilket har resulteret i en generel mistro til deres evne til at drive virksomhed. Ineffektiv hændelsesstyring og beredskab risikerer at skabe et troværdighedsproblem og vil få virksomheder til at fremstå uprofessionelle.

e)  Ekstern it-sikkerhedsrevision
Både Nets og IBM får gennemført en it-revision og IBM får udarbejdet en ISAE 3402** omhandlende Nets driftsforhold. Desuden bliver begge virksomheder udsat for en PCI DSS audit. Alligevel har ingen af disse formået at identificere væsentlige sårbarheder eller mangler. Det viser sig desuden, at Finanstilsynet ikke har tjekket Nets i fire år. I forhold til den vigtige rolle de har for samfundet kan det måske undre, at der ikke har været mere fokus på ekstern kontrol af informationssikkerheden.

Hvor meget værdi kan vi overhovedet tillægge en revisionserklæring og har den nok pondus? Hvis den ikke formår at identificere væsentlige svagheder eller dens observationer ikke bliver synliggjort i tilstrækkelig grad, hvor meget tillid kan vi så have til disse? For mange virksomheder og kunder har fejlagtigt sat lighedstegn mellem it-revision/outsourcing-erklæringer og informationssikkerhed, hvilket er en misforståelse. Deres formål har fra starten været at understøtte den finansielle revision og ikke haft fokus på holistisk informationssikkerhed.

• Den eksterne sikkerhedsrevision bør i højere grad begynde at fokusere på processer, adfærd og awareness. Der er større risici forbundet med disse forhold end fx. en manglende test af backup eller en fejlet change management kontrol. 
• Vi skal derfor væk fra den revisionsprægede checkliste kontrol og i højere grad basere sikkerhedsrevisionen på en risikobetragtning med fokus på de elementer, der er relevante i forhold til informationssikkerhed.
• Det samme kan siges om PCI DSS. Med den seneste version (3.0) er der kommet lidt mere fokus på interne sikkerhedsprocesser og medarbejderadfærd, men måske stadigvæk ikke nok. PCI-audits har en tendens til at fokusere meget på kontrollerne omkring systemudvikling, netværkssikkerhed, penetrationstest og logisk adskillelse af kortdata-miljøer fra andre netværk. Og har måske for lidt fokus på rettigheder, roller, medarbejderadfærd og awareness.

------
*Advanced Persistent Threats: I høj grad koordinerede angreb på specifikke mål som brancher, enkeltvirksomheder, presse og kritisk infrastruktur. Er typisk enten politisk motiveret eller omhandler industrispionage. Der bliver ofte benyttet avancerede angrebstyper og det sker på flere simultane angrebsvektorer. Tidligere hændelser indikerer, at angrebene kan være statssponsorerede.

**ISAE 3402 type 2 erklæring (tidligere RS 3411) dækker over erklæringsopgaver, der forholder sig til udvalgte kontroller hos en serviceleverandør, der vedrører ydelser, som er relevante for en virksomheds interne kontroller for regnskabsaflæggelse. Oftest vil det være de ”generelle it-kontroller” baseret på best practices fra den amerikanske revisorforening AICPA. Men kontrollerne kan også være nogle specifikke kunden udvælger sammen med revisionen for at give det mest retvisende billede af it-kontrolmiljøet hos kunden. I det omfang en kunde ønsker det, kan Cobit eller ISO 27002 rammeværket også inddrages.

Om forfatteren: Gaffri Johnson er Senior Security Advisor hos Neupart A/S og udfører sikkerhedsrådgivning om bl.a. ISO 27001 og it-risikovurderinger. 

Den ny ISO 27001 er udkommet: Vejledning til Statement of Applicability (SoA-dokument)

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.

Risikostyring = Risikovurdering + Risikohåndtering

Risikostyring har nu en endnu mere central placering i virksomhedens ISMS. Risikostyring består i al væsentlighed af en proces for risikovurdering og en proces for risikohåndtering (risk treatment).

Road to SoA - and beyond

I den ny ISO 27001, såvel som i den gamle, findes et centralt dokument, der hedder Statement of Applicability (SoA). Det er nyt, at SoA'en skal være tæt forbundet med jeres proces for risikohåndtering, og det er nyt at I skal udpege risikoejere, som godkender jeres risikohåndtering og jeres risikovillighed, også kaldet risiko-appetit.

SoA beskriver hvilke tiltag (controls på engelsk), der indgår i jeres ISMS. Det er nyt, at I skal begrunde både tilvalg og fravalg; en fin forbedring af standarden.  Da SoA er eller bliver så centralt et dokument i jeres ISMS, har Neupart lavet en gratis vejledning til, hvordan I mest effektivt kan lave jeres SoA.


HER KAN DU HENTE SOA VEJLEDNINGEN - registrering er ikke nødvendig.


Her finder du flere ISO 27001 ressourcer:

SecureAware ISMS-værktøj
Webinar om hvordan du laver en SoA
Webinar om risikovurdering
Webinar om risikohåndtering
Live Demo Webinar: Værktøj til risikovurdering og-håndtering
Seminar om den ny ISO 27001
Blogpost om hvordan ny ISO 27001 påvirker jeres risikostyring

Om forfatteren: Lars Neupart er stifter af Neupart og vil gerne fortælle dig at SecureAware = effektiv it-sikkerhedsledelse. Følg ham på Twitter.

PS: Klik her for at følge os på LinkedIn.