Lärdomar från arbete med IT-GRC – del 1

Det här inlägget har jag delat upp i två delar eftersom det blev längre än jag först hade tänkt! I den första delen beskriver jag erfarenheter och funderingar kring förändringsarbete ur ett säkerhetsperspektiv, innehåll i IT GRC-processen, integration i verksamhetsprocesserna, metoder och modeller samt organisation. I del 2 går jag in mer på tekniska lösning, val av leverantör, mjukvara och införande.

Under cirka fyra års tid har jag och min kollega Niklas arbetat med olika former GRC (Governance, Risk and Compliance), vilket jag tycker egentligen bara är ytterligare en förkortning på något som många av oss inom säkerhetsområdet jobbat med mycket längre än så.

Lite nyare är väl däremot stöd i form av mjukvara för att hantera styrning, riskhantering och compliance. Detta mjukvarustöd har också möjliggjort aggregering av information och analyser som tidigare kunde vara svåra och resurskrävande att lyckas med. Jag tror också att det för många av oss blir det tydligare kopplingar och en bättre logik i hela säkerhetsarbetet när vi sätter samman de olika processer som finns inom säkerhetsområdet, t ex informationsklassificering, riskhantering och incidenthantering och tydliggör exakt vad som är input och output från processerna.

Mjukvara kan, under rätt förutsättningar, ge möjlighet till ett mer effektivt och systematiskt arbete. Jag tror vi är många som försökt och försöker ro runt åtminstone delar av en GRC-process med hjälp av endast Microsoft Office. Men visst är detta svårt i en större organisation då både krav- och hotbilden ständigt förändras. När det gäller it är it-miljön dessutom ofta både komplex och ständigt växande, vilket också bidrar till att nyttan av mjukvarustöd blir stor.

Som i de allra flesta fall går det inte lösa problem eller införa reella förbättringar genom att bara köpa och införa ett verktyg…

Av den erfarenhet jag fått kring att arbeta med IT-styrning, compliance och riskhantering vill jag dela med mig av några grundkomponenter som bör ingå i ett IT GRC-koncept:

• Processer (arbetssätt)
• Organisation (roller, funktioner och ansvar)
• Teknisk lösning (i alla fall för medelstora och stora organisationer)

Säkerhet i förändring

I en större organisation är min erfarenhet också att detta arbete bör ske i projektform på samma sätt som de flesta förändringsprojekt drivs idag. Det krävs ledningsbeslut, styrning och resurser för att få ordning på detta! En mindre bra erfarenhet jag har i bagaget är när större förändringar av säkerhetsarbetet inte sker i de normala förändringsprocesserna (såsom projektstyrning och utvecklingsprocess) utan istället försöker organisationen genomföra förändringen ”på sidan om”, vilket jag tycker endast bidrar till att säkerhetsarbetet får låg status och ses som något konstigt och udda.

Viktigt att fundera över är förstås också vilken typ av organisation man befinner sig i – är angreppssättet ”Top-Down” eller ”Bottom-Up”. Är it endast en kategori bland flera andra eller IT GRC är drivande? Inget av dessa angreppssätt behöver vara direkt dåligt, men viktigt att tänka helhet oavsett varifrån arbetet drivs.

”Alice : Åt vilket håll ska jag gå?
Katten : Det beror på vart du vill komma?
Alice : Det spelar ingen roll.
Katten : Då spelar det heller ingen roll åt vilket håll Du går.”

Processer 

När det gäller att angripa processkartläggning ser jag främst följande två huvuddelar:

• ”IT GRC-processen”: Hur jobbar man idag? Hur vill man jobba de närmaste åren? Vilka delar ska ingå i GRC-processen initialt? Hur vill man jobba i ett längre tidsperspektiv?
• Verksamhetens normala processer: Vilka verksamhetsprocesser ska man integrera i?

Komponenter i IT GRC-processen

Vad ska man då välja för delkomponenter i sin IT GRC-process? Kanske genomför man redan mycket arbetet manuellt och det blir då naturligt att bara lyfta in det i applikationen och kanske endast göra mindre förbättringar? Kanske vill man passa på att genomföra en större förändring och införa ett nytt arbetssätt?

Exempel på vanliga komponenter är: Policyhantering, informationsklassificering, compliance-hantering, riskhantering och internrevision (IT-revision). Det går ju också utmärkt att lägga till andra delar såsom t ex kontinuitetsplanering. Min erfarenhet hittills pekar dock på att man bör välja ett fåtal av dessa processteg (t ex de som ger störst effekt i ett inledningsskede) att ingå i förändringsprojektet.

Samtidigt bör man förstås ha en plan för var man vill landa i slutändan, men omfattningen av projektet bör hållas ned för bättre förutsättningar att lyckas och snabbt komma igång med åtminstone de delar organisationen bedömt som viktigast. Detta för att undvika att välja fel mjukvarulösning samt för att hitta effektiva ”quick wins”.

Integration i IT-verksamhetens processer

En lärdom är att ha med sig i projektet att de flesta medarbetare inom IT-organisationen INTE arbetar i någon GRC-process (eller IT-säkerhetsprocess). De arbetar inom utveckling, förvaltning, drift/operations, etc. Detta innebär att integration i IT-verksamhetens normala processer blir en helt avgörande framgångsfaktor.

När vi tittar på verksamhetens normala processer (i det här fallet IT-verksamhetens normala processer) är det för att på bästa sätt kunna integrera IT GRC-stegen. Utan integration faller den typen av styrnings- och säkerhetsarbete oftast platt till marken med låg användning eller blir väldigt personberoende (i form att man förlitar sig på någon eller några ”eldsjälar” i organisationen). Det blir ingen eller väldigt låg utväxling på den investering man gjort.

Metoder och modeller

Efter att ha enats om vilka delar som ska ingå i GRC-processen och hur integrationen ska se ut brukar det vara dags att och sätta ned foten kring metoder och modeller. Exakt hur ska informationsklassificeringen göras (om den inte görs idag eller om befintlig metod ska förbättras). Samma gäller övriga steg. En mängd frågeställningar måste penetreras och lösningar tas fram: Vilka skalor ska användas? Hur ska klassningen påverka övriga steg i processen? En erfarenhet här är att även om organisationen tror sig ha samsyn kring både hur styrning fungerar och den borde fungera, så finns det inte bara en sanning!

Organisation

Dokumenterade roller och funktioner med tydligt ansvar är en förutsättning för att processer ska fungera väl. IT GRC är inget undantag utan tvärtom är det min erfarenhet att det är extremt viktigt – inte minst i organisationer där mognaden kring t ex riskhantering är låg.

Exempel på vanliga roller i en IT GRC-process kan t ex vara systemförvaltare och systemägare eller IT-projektledare och beställare. Sedan finns ju också en mängd specialistroller för vilka en IT GRC-process kan vara viktig, t ex risk manager, compliance-ansvarig, säkerhetsspecialister, etc. Som exempel på viktiga funktioner vill jag nämna några som jag stött på i form av ledningsgrupper (t ex IT-ledningen), olika typer av beslutsfattande råd (informationssäkerhetsråd, riskråd, complianceråd), osv. Varje organisation har sina specifika förutsättningar och resurser.

Om det går att knyta IT GRC-processen till befintliga, fungerande beslutsvägar och funktioner är det en stark rekommendation.

När arbetssätt (inklusive processintegration), funktioner, roller och ansvar är hyffsat tydligt är det dags för lite magi i projektet! Mjukvarulösningen som ska stötta det nya arbetssättet. Fortsättning följer i del 2….

// Annika Biberg
Informationssäkerhetskonsult SAFESIDE SOLUTIONS AB