Lärdomar kring IT GRC – del 2

Fortsättning på mitt tidigare inlägg om IT GRC, del 1 som finns här.
 
Teknisk lösning
 
Att välja ett mjukvarustöd som matchar den kravbild man har utifrån process och organisation är förstås en framgångsfaktor. Marknaden för GRC-applikationer var, åtminstone för mig, till en början förvirrande! Min analys är att det beror på den stora fragmentering och spridning av olika lösningar som alla kallas IT GRC. Det ska också tilläggas att det finns lösningar för EGRC (Enterprise GRC). En del av de traditionella EGRC-leverantörerna har valt att närma sig IT GRC och lägga till det som en del av sin lösning, men i andra fall har IT GRC-leverantörer lagt till ett paraply i form av EGRC för att komplettera sin lösning. Vissa IT GRC lösningar är mycket tekniknära och kan samla in och analysera viss data från IT-miljön (jfr så kallade SIEM-lösningar, Security Information and Event Management), andra är mer processnära och fokuserar mest på styrning av IT och säkerhet med hjälp av self assessment. Det skiljer sig alltså en hel del när du väl tittar under huven på produkterna samtidigt som alla leverantörer säger att de levererar IT-GRC.
 
I början av 2010 fanns det över 100 lösningar på marknaden som kallades GRC i någon form, så det finns en hel del att välja på!
 
Det gäller förstås, att under arbetets gång, inte glömma bort vad det är man vill lösa och vilket arbetssätt som fungerar i organisationen, även om verktygen man väljer bland har mängder med andra fantastiska egenskaper!
 
IT GRC-applikationer
 
De flesta IT GRC-applikationer jag har stött på hittills har följande grundkomponenter gemensamt:
 •Frågeformulär (för olika typer av egenkontroll)
 •Formulärdata (för hantering av data om risker, revision, incidenter, etc)
 •Workflow-motor
 •Import/export-funktionalitet
 •Rapport-generator
 •Innehåll (i form av standarder och best practice för mätning av compliance, t ex PCI-DSS)
 
Antalet moduler som kan stötta organisationens olika processteg sträcker sig från väldigt tekniknära funktioner såsom import av data från automatiserade sårbarhetsscanningar till avancerade riskbedömningsmetoder.
 
De allra flesta erbjuder förstås också integration mot katalogtjänst för Single-Sign-On. Ofta finns också mer eller mindre färdig integration mot många andra tekniska plattformar som kan tänkas finnas på plats i en större organisation såsom lösningar för hantering av IT-tillgångar, s k Asset Management eller befintliga säkerhetslösningar som antivirusskydd, sårbarhetsscanners, etc.
 
Det finns många fördelar med GRC-applikationer jämfört med att använda Office-paketet för t ex  informationsklassificering, compliancehantering och riskhantering. I mjukvarulösningarna blir det hyffsat enkelt att skapa bryggor mellan stegen i GRC-processen och därmed kunna återanvända resultat från tidigare steg och styra varje delprocess med hjälp av dokumenterade styrprinciper och verksamhetsregler. Det finns också möjligheter att granulärt styra rättigheter till informationen och workflow samt att aggregera och analysera information. Även bra visualisering och tydlig presentation av information är något jag lärt mig att värdesätta mer och mer. En GRC-applikation kan hjälpa till med visualisering av nuläge och målbild för organisationen genom bra möjlighet till uppföljning, rapportfunktioner, trafikljus (rött, gult, grönt), dashboards, trender, aggregering och korrelering av information, Etc.
 
Den allra störta vinsten är kanske ändå att kunna tillämpa ett systematisk arbetssätt (samma metoder, skalor och matriser varje gång) och hantera en stor mängd information över tiden.
 
När det gäller nackdelar skulle jag vilja ta upp kostnaderna för att införa och förvalta GRC-lösningen, men samtidigt påpeka att kostnaderna för att uppnå motsvarande effekter utan ett verktygsstöd skulle på ett par års sikt överstiga investerings- och förvaltningskostnaderna. Vi har ett par gånger (för stora, multinationella bolag) räknat på vad det skulle kosta att göra arbetet utan GRC-applikation och kommit fram till att vi i så fall blir tvungna att utveckla ett GRC-stöd i Excel och lägga ned ett stort antal mantimmar för att komma ens i närheten av effekterna vi får ut med GRC-lösningen. Kan man tänka sig att tumma lite på effekterna/nyttorna blir beräkningen förstås annorlunda.
 
Även förvaltningen av en sådan Excel-lösning blir snabbt väldigt kostsam då vi t ex inte har något innehåll tillhandahållet och uppdaterat av en leverantör.
 
Säkerhetsaspekterna med att hantera den här typen av information (alla sårbarheter och risker i IT-miljön) i Office-paketet kan ju också vara värt att nämna med spridd och oskyddad information som ofta mejlas omkring, med dålig eller ingen spårbarhet, ingen möjlighet till rollbasering, etc.
 
Val av leverantör och lösning
 
Tillbaka till själv projektgenomförandet: När IT GRC-projektet är startat och bemannat är min erfarenhet att det mest lyckade angreppssättet är att genomföra en förstudie där bland annat processkartläggning görs. Om det är en stor organisation som inför IT GRC-lösningen finns nästan alltid projektstyrnings- och utvecklingsprocess och/eller upphandlingsprocess att följa. Vanliga steg brukar vara RFI (Request for Information), RFP (Request for Proposal) och PoC (Proof of Concept). Här gäller det att få med en så tydlig kravbild som möjligt och att inte missa att ställa generella säkerhetskrav bara för att det är en ”säkerhetsprodukt”. Att ha tillgång till kravare och testare är en lyx som ibland förunnats mig, men om inte får man göra det bästa av situationen. Projektet kan lämna ifrån sig en utrullningsplan (beroende på organisationens storlek, IT GRC-processens omfattning, m m). Efter att lösningen implementerats och acceptanstester är genomförda av slutanvändarna och eventuella piloter avklarade kan i normala fall projektet anses avslutat och arbetet med ständiga förbättringar i förvaltningen ta vid.
 
Om det finns tveksamheter kring förvaltningen av både process och applikationsstödet (GRC-verktyget) bör dessa förstås lösas innan det nya arbetssättet sätts i produktion. De flesta större organisationer jag stött på har en förvaltningsmodell (t ex Affärsmässig förvaltningsstyrning PM3) och den brukar gå utmärkt att tillämpa även för förvaltning av processer.
 
Vad blev egentligen resultatet?
 
Vad har då leverats när projektet är klart? Det skulle t ex kunna se ut något i stil med:
 •Processbeskrivning (IT GRC-processen), inklusive aktivitetsnivå och beskrivning av integration med andra processer
 •Roller och ansvar (i IT GRC-processen)
 •Styrande dokument (de riktlinjer, anvisningar, instruktioner som krävs för att styra processen)
 •Arkitekturbeskrivning (lösningen), krav & test (som kan återanvändas i förvaltningen)
 •Implementerat applikationsstöd (IT GRC-applikationen)
 •Förvaltningsorganisation för IT GRC (process och applikation)
 
Förutom resultatet ovan har vi också i projekten jobbat en hel del med nyttoanalys för att kartlägga de mer långsiktiga nyttorna för verksamheten, men det är ett ämne i sig och får nog bli ett separat blogginlägg så småningom.
 
Kritiska framgångsfaktorer
 
De mest kritiska framgångsfaktorerna som jag identifierat i GRC-projekten är:
 •Metodstöd (organisation som stöttar kring de metoder och modeller som ingår i GRC-arbetet)
 •Integration (integration i de normala verksamhetsprocesserna)
 •Automatisering/applikationsstöd (det är svårt att i längden klara detta med Excel och Word)
 •Enkelhet (det måste vara enkelt att förstå och använda)
 
Jaha, mina GRC-vänner. Detta var det hela! Kom gärna med synpunkter och funderingar. Kanske några av er prövat helt andra tillvägagångssätt eller kommit fram till andra slutsatser än jag. Allt är av intresse för mig, så tveka inte att skriva en kommentar eller kontakta mig direkt!

// Annika Biberg
Informationssäkerhetskonsult SAFESIDE SOLUTIONS AB