Samme hvor gjerne vi måtte ønske oss sikre systemer, så er det i praksis umulig å forhindre alle sikkerhetsfeil. Man har begrenset med tid, penger og ekspertise, og man trenger systemer som er enkle å bruke og vedlikeholde. Spørsmålet man da trenger svar på er hvor mye sikkerhet man skal ha, og hvor man skal satse de sikkerhetsressursene man har.
Det finnes generelt to hovedtilnærminger til å bestemme hvilket nivå man skal legge seg på angående sikkerhet, og hvilke tiltak man skal prioritere:
- en risiko-basert tilnærming
- overholdelse av regler og god praksis (compliance)
Disse er ikke i direkte motsetning. Som eksempel så vil man gjerne ta hensyn til regler og god praksis i vurdering av risiko, og god praksis innebærer gjerne at man har oversikt over risiko. Men hvilken av disse hovedtilnærmingene man vektlegger sterkest påvirker hvordan man jobber med sikkerhet, og de har begge sine fordeler og ulemper. Kort sagt så vil en risiko-basert tilnærming være bedre for å oppnå kostnadseffektiv sikkerhet, men det krever mer kompetanse enn om man går for sjekkliste-versjonen av sikkerhet. Vi vil nå forklare dette nærmere.
Risikovurderinger er ofte anbefalt som utgangspunkt for arbeidet med informasjonssikkerhet, og ISO/IEC 27001 er intet unntak. Om man kjenner sine sårbarheter, trusler og risiko kan man gjøre bedre beslutninger angående hvor mye og hvilken sikkerhet man trenger. Men mange synes det er vanskelig å vurdere sannsynlighet og konsekvens for ulike hendelser, og forstå hva som faktisk kan skje i systemene. Nå må det sies at med den kompetansen som er tilgjengelig nå så går det ikke an å vise hva som er “riktig” vurdering av risiko. Istedet for å satse på “to streker under svaret”, må man stole på at man med god oversikt og forståelse for sikkerhet klarer å identifisere de viktigste tingene. Men hva om man ikke har slik kompetanse, kan man da satse på at man tar gode sikkerhetsbeslutninger basert på risikovurderinger gjort på sviktende grunnlag?
Sjekklister gjør det lettere å oppnå et minimum av beskyttelse uten å måtte forstå alt det intrikate rundt hvordan man oppnår god informasjonssikkerhet – enten det gjelder en virksomhet eller et programvare-produkt. Det å redusere behovet for sikkerhetskompetanse har stor verdi, spesielt for virksomheter med lite ressurser på informasjonssikkerhet. Det finnes flere generelle og bransjespesifikke sjekklister og oversikt over god praksis man kan benytte. To utvalgte norske eksempler knyttet til informasjonssikkerhet er Normen i helsesektoren og retningslinje 104 for olje og gass. Vi har tidligere skrevet om McGraw sine fortsatt gyldige prinsipper for programvaresikkerhet, og vet at det er mange som benytter OWASP sin top 10 liste over sårbarheter for å gi retning til programvaresikkerhetsarbeidet. Om man følger slike sjekklister får man hjelp til å velge ut hva man skal prioritere, man vet at man gjør tiltak som er vanlige også blant andre virksomheter, og man kan vise til at man følger gitte anbefalinger – både overfor kunder og tilsyn, og om det skulle skje en hendelse. Det er imidlertid noen farer man bør være klar over om man velger en sjekkliste-basert tilnærming til sikkerhet:
- Det finnes ikke noen “one-size-fits-all” for sikkerhet. Ulike organisasjoner og ulik programvare har forskjellig behov for sikkerhet, og om man slavisk følger en sjekkliste vil man sannsynligvis gjøre gode tiltak, men kanskje ikke de viktigste eller mest kostnadseffektive.
- Man øves ikke opp i å tenke på forretningsbehov og hvilken rolle sikkerhet spiller i den forbindelse. Det å delta i risikoanalyse er en super måte å øke sikkerhetsbevissthet og sikkerhetskompetanse på blant nøkkelpersoner i bedriften. Bevissthet om forretningsbehov er viktig for å treffe gode tiltak og å sikre at sikkerhet blir sett på som viktig blant ledelsen i virksomheten.
- Trusselbildet endrer seg stadig. Dermed kan sjekklister fort bli utdaterte. Samtidig har man et behov for å kunne reagere fornuftig på disse endringer, og det krever en kompetanse og bevissthet om sikkerhet som man ikke nødvendigvis bygger om man baserer seg kun på sjekklister.
Mange standarder anbefaler en slags kombinasjon av disse to tilnærmingsmetodene. Et eksempel er (nok en gang) ISO/IEC 27001. Denne standarden er sentrert rundt risikovurderinger, samtidig som det kreves at virksomheter beskriver hvordan de forholder seg til en lang liste av referansetiltak (statement of applicability). Normen og retningslinje 104 som er nevnt lenger oppe i innlegget inneholder risikoanalyse som et av flere sjekkliste-punkter. Tidligere har vi for kraftbransjen utarbeidet en rekke sjekklister som kan benyttes som input i gjennomføringen av en risikoanalyse.
Hvilken tilnærming man velger må virksomheter selv bestemme, basert på ressurser og kompetanse. Men på generelt grunnlag vil vi anbefale at man går mot en mer risiko-basert tilnærming. Vi anbefaler at man gjør risikovurderinger, men det betyr ikke at man skal forkaste sjekklister. Om man ønsker å starte med en mer sjekkliste-basert tilnærming til sikkerhet kan man øve opp risikovurderings-evnen ved å stille spørsmål knyttet til sjekklistene: Hvilket sikkerhetsproblem er det vi adresserer med dette sjekkliste-tiltaket? Vil det gi bedre sikkerhet for våre viktige verdier? Hvilke ulemper vil tiltaket medføre for virksomheten? Finnes det andre måter å løse samme problem på som er mer hensiktsmessige for oss?
Vi på SINTEF jobber risiko-basert med sikkerhet på mange ulike fronter. Som sikkerhetsforskere er risiko en sentral del av det meste av arbeidet vi gjør, og vi må stadig spørre oss selv hva som er god nok sikkerhet i prosjektene vi deltar i. Et eksempel på et prosjekt der vurdering av risiko er svært sentralt er prosjektet inSecurance som ser på cyber-forsikring og dens rolle som en mekanisme for risiko-overføring. Her er risikovurderinger sentralt både for forsikringsselskap og forsikringstaker. Et annet eksempel er prosjektet SoS-Agile som omhandler sikkerhet i smidig programvareutvikling. Vi jobber her blant annet med metoder for hvordan jobbe risiko-basert med sikkerhet knyttet til ulike utviklingsaktiviteter. Vi tar også regelmessig oppdrag fra virksomheter som ønsker hjelp til å gjennomføre risikovurderinger eller ønsker å få en tredjepartsvurdering av risiko knyttet til produkter de har.
Vi har tidligere skrevet mye om risikovurdering og det å jobbe risikobasert her på bloggen. De som vil lese mer kan se på følgende innlegg:
- ISO 27001: Styringssystem for informasjonssikkerhet
- Forsikre eller ikke?
- Støtte til risikoanalyse av AMS og tilgrensende systemer
- Noen kjappe anbefalinger om risikoanalyse
- Risikovurderinger – hvordan kan vi gjøre dette bedre?
- Ja, men hva er risikoen for det?
Deler av argumentasjonen i dette innlegget er basert på boken “Security Risk Management – Building an Information Security Risk Management Program from the Ground Up” av Evan Wheeler.