Framgångsfaktorer för säkerhet i it-projekt

Att vid en sista inspektion innan inflyttning i ett nybyggt hus få höra en besiktningsman säga att alla fönster måste bytas ut för att klara ljudnivån från gatan, att stommen måste förstärkas för att klara vikten av snö och att grunden inte är byggd enligt gällande byggnormer är nog ett relativt ovanligt scenario inom byggbranschen. Inom IT branschen är motsvarande scenario däremot mer regel än undantag.

Kan säkerhet appliceras i slutet av ett projekt?

Det är en vanlig uppfattning att det gör det. Dessutom mäts ofta projekten på framförallt budget och leveransdatum. Har projektet då inte haft med säkerhetskompetens från start hamnar det i en situation där oförutsedda aktiviteter identifieras i slutet av projektet. Det leder till onödiga förseningar och kostnadsökningar. Som referens till byggbranschen igen är det som att bygga ett hus och installera el och vatten först efter att ytskikten i huset är färdiga. Du tvingas alltså ofta att riva upp arbete som redan gjorts, men hade du planerat rätt från början så hade det kunnat installeras utan att något annat arbete hade behövt fördyras.

Säkerhet är ett kvalitetskrav som många andra och alla dessa krav tillgodoses absolut bäst så tidigt som möjligt.

Styrande eller rådgivande?

Hur projekt och olika organisationer skall förhålla sig till IT-säkerhetskrav är en fråga jag har upplevt vara ett vanligt förekommande föremål för diskussion. Är säkerhetskraven styrande och tillåts stoppa ett projekt eller skall de anses vara informativa och endast vägleda projektet till en potentiellt säkrare miljö?

Jag anser att rätt utfört behöver inte säkerhet vara styrande. Rätt utförd säkerhet innebär att rätt beslutsfattare får rätt beslutsunderlag i rätt tid och därmed fattar rätt beslut. Här är det viktigt att komma ihåg att även säkerhetsarbetet i sig tar tid och därför kan inte alltid svar på frågor levereras på stående fot. Beslutet fattas genom en avvägning mellan kostnader om risker faller ut gentemot kostnader för att förhindra risken helt eller delvis. Kostnader om risken faller ut är allt från incidenthanteringskostnader, produktionsbortfall, värde på förlorat intellectual property, böter, stämningar, förlorat värde i varumärket och förlorat börsvärde. De två sista kan vara astronomiskt höga om det är lagar som inte följs. Retail-företaget Target i USA, till exempel, förlorade kreditkortsinformation som drabbade 70 miljoner personer. De direkta kostnaderna för Target för att hantera incidenten översteg 160 miljoner dollar. Varken skadestånd, varumärkesskada eller böter ingår i det beloppet. Jag gissar, inte helt överraskande, på att Targets beslutsfattare inte haft tillgång till rätt beslutsunderlag vad gäller IT-säkerhet…

Vad kostar det att inte ha med säkerheten i tid?
Det förra stycket hamrade in ordet ”rätt”. Det är det som är utmaningen. Ett projekt består av kompletterande kompetenser. Om något kompetensområde saknas kan beslutsunderlaget bli obalanserat och då kan beslutsfattare tvingas att fatta mindre bra beslut för att det där och då är rätt relativt situationen. Projektet har då misslyckats att leverera kvalitet i sitt arbete. Kostnaden för den sårbarhet som denna kvalitetsförsämring medför uppmärksammas mycket sällan och döljer sig ofta i statistik eller publiceras inte alls.

Finns det regleringar att förhålla sig till, t.ex. personuppgiftslagen (PUL), eller Payment Card Industry (PCI) krav så behandlas ofta även dessa på samma sätt. Men min erfarenhet är att när en reglering ligger bakom ett krav är kostnaden om risken faller ut signifikant högre än annars och att det därför oftare är värt att mitigera risken. Avsikten är givetvis att följa alla lagar men beroende på vilken typ av verksamhet det är så finns det olika tidsaspekter på hur snabbt dessa måste följas.

Hur får man som IT-säkerhetsresurs detta att bli verklighet?

För det första, om inte IT-säkerhet är en prioriterad fråga från ledningen där IT-chefen får tydliga direktiv uppifrån jobbar du i en rejäl uppförsbacke. Men även om ledningen är medveten om effekterna av rätt säkerhet och pekar med hela handen kan det vara en utmaning. IT-säkerhetsarkitektens roll är ofta att navigera mellan verksamhetens krav på nyttor och funktion med de existerande ramverk för informations- och IT-säkerhet. Det är viktigt att vi då ser vår roll som rådgivare för att hitta bästa lösningen för verksamhet kontra eventuell skadekostnad kontra investeringskostnaden för skyddet.

Därför måste vi som IT-säkerhetsarkitekter försöka hitta en retorik som fungerar, som förklarar och underbygger vikten av rätt säkerhet. En metod kan vara att använda riskanalyser för att ta fram underlag som bevis. Vilka är de möjliga konsekvenserna, vilka kostnader kan de medföra, hur sannolika är de? Ännu starkare argument är statistik inom organisationen, om den är tillgänglig, eller omvärldsbevakning. Just omvärldsbevakning och att dra paralleller till händelser i andra organisationer konkretiserar hoten och tar lyssnaren bort ifrån det abstrakta. Det gör det lättare för den som lyssnar att ta emot informationen du förmedlar och reducerar risken att en värdering uppfattas som godtycklig.

Men även om det är viktigt att vi kan anpassa oss och möta våra kollegors frågor och funderingar så är det ytterst IT-chefens ansvar att se till att alla resurser i IT-organisationen arbetar så effektivt som möjligt.

Säkerhet i projekt – integrerat i projektet eller som isolerat arbete?

Säkerhetskompetens skall vara med i projektet hela vägen tills implementationen är klar. Då har organisationen bättre möjligheter att säkerställa att säkerhetslösningarna är kostnadseffektiva. Organisationen spar alltså pengar på att få råd vid varje beslutspunkt eftersom alla beslut då beaktar alla kvalitetskrav och risken att arbete behöver göras om eller ineffektiva lösningar implementeras minimeras.

Alltså - Enligt min erfarenhet ser jag tre stora framgångsfaktorer för att IT-säkerheten skall hanteras på ett bra sätt i ett projekt:

1.Se till att era IT-säkerhetsarkitekter är med från början så slipper du besiktningsmannen som upplyser om att taket måste rivas.

2.Integrera säkerheten i projektmetodiken och i utvecklingsprocessens olika steg och beslutspunkter. Marknadsför även vad säkerheten tillför. Ta fram rätt beslutsunderlag.

3.Använd rätt retorik, konsekvensbedömningar, risk, etc. Underbygg dina argument väl och se till att ni pratar samma språk.

// Jesper Andersson

Informationssäkerhetskonsult på SAFESIDE SOLUTIONS AB