Ofte blir sikkerhet sett på som en ekstra kostnad. En sikkerhetsansvarlig som prøver å sanke støtte hos ledelsen for investering i sikkerhetstiltak må argumentere for en positiv avkastning på investeringen (ROI). Dette blir vanskelig hvis man ikke kan vise til noen sikkerhetshendelser – da kan det tvert i mot se ut som om investeringene var overdrevet eller direkte bortkastet. Pussig nok er dette aldri en problemstilling i HMS-verdenen, men dette kan forklares ut fra samfunnets vilje til å bruke mye penger hvis det kan redde livet til et eneste menneske. Som sikkerhetseksperter er det vår utfordring å i stedet presentere sikkerhet som en muliggjører, snarere enn en ren kostnad. Det finnes noen eksempler hvor sikkerhetshendelser har ført til et fornyet fokus på informasjonssikkerhet; i 2001 ble det amerikanske innenriksdepartementet koblet fra internett etter en rettskjennelse som følge av en rettsak med utspring i en sikkerhetshendelse. Dette førte til en fullstendig omorgansering av intern sikkerhetspraksis i dette departementet, og sikkerhet ble muliggjøreren som gjorde det mulig å koble departementet opp mot internett igjen.
En liknende variant er “vi har ikke råd til å vente på sikkerhet”, som ofte manifesterer seg i utsagn som “vi må bare få det til å virke først, deretter kan vi se på sikkerheten”. Dette resulterer i ettermontert (bolt-on) i stedet for innebygd (built-in) sikkerhet, som medfører at eventuelle fundamentale arkitektoniske sikkerhetsfeil ikke fanges opp tidlig i utviklingsprosessen (hvis de fanges opp i det hele tatt), noe som igjen enten fører til a) et sluttprodukt med sikkerhetsfeil eller b) forsinkelser og økte kostnader når oppdagede feil krever fundamentale endringer og betydelig merarbeid .
Til og med i tilfeller hvor alle er enige i at sikkerhet er nødvendig, kan eksterne påvirkninger motvirke et godt resultat. I en distribuert utviklingsorganisasjon venter ikke programmererne nødvendigvis på at sikkerhetskravene er ferdige før de setter i gang med å implementere moduler, noe som kan resultere i et sluttprodukt med gapende sikkerhetshull. I store EU-prosjekter kan man også oppleve at enkelte partnere fokuserer mer på å utvide eksisterende løsninger (fra tidligere prosjekter) enn å lage ting fra grunnen av, noe som medfører at enhver sentralisert prosess rundt sikkerhetskrav er dømt til å mislykkes, siden partnerne det gjelder allerede “vet” hva de skal lage, og ikke “trenger” ytterligere føringer fra sikkerhetskrav. Dette forteller meg at vi må fokusere enda mer på sikkerhet i smidig utvikling, fortrinnsvis slik at “vanlige” utviklere er ansvarlige for å etablere sikkerhetskrav for egne komponenter. Vi har allerede kommet med noen bidrag på dette feltet, men det er helt klart behov for mer forskning på temaet.
Denne teksten er basert på min Dr.Philos.-avhandling Security in Critical Information Infrastructures