Internkontroll – informasjonssikkerhet
Internkontroll/styringssystem (Versjon 1.4)
Internkontroll/styringssystem (Versjon 1.4)
Dette er bakgrunnsstoff («Godt å vite») til hovedaktiviteten Risikovurdering. Målgruppen er de fagansvarlige informasjonssikkerhet som ønsker å sette seg litt grundigere inn i enkelte tema og dermed øke sin bakgrunnskunnskap.
Risikovurderinger er et nyttig verktøy også på systemnivå. Uansett om man anskaffer et ferdig produkt, utvikler et nytt system eller velger en kombinasjon av disse, er det viktig å stille gode sikkerhetskrav. Det samme gjelder dersom man skal anskaffe IT-drifts- eller vedlikeholdstjenester. Hvis man ikke stiller sikkerhetskrav, er det i beste fall flaks som avgjør om sikkerhet er en del av den endelige løsningen. En risikovurdering er et godt utgangspunkt for å stille relevante og dekkende sikkerhetskrav.
Risikovurderingen synliggjør hvilke hendelser systemet kan utsettes for, og gir en prioritet av hvilke hendelser som bør håndteres. Ut fra denne vurderingen utformer man sikkerhetstiltak. Hensikten med sikkerhetstiltakene er å redusere risiko til et akseptabelt nivå. Dersom man skal gjøre en anskaffelse, må sikkerhetstiltakene formuleres som krav til løsningen eller tjenesten som skal anskaffes. Tilsvarende krav må stilles dersom løsningen skal utvikles, vedlikeholdes og driftes internt.
I denne teksten omtaler vi anskaffelser og systemutvikling som foregår internt i en virksomhet, hver for seg. Støttemetodene man kan benytte, er imidlertid de samme. Noen av disse er beskrevet til slutt i denne teksten.
Med IT-anskaffelser mener vi i denne sammenheng anskaffelse av IT-løsninger, IT-vedlikehold og IT-drift. IT-løsninger kan være alt fra hyllevare og standardsystemer med eventuelle tilpasninger til løsninger som er utviklet spesielt for en enkelt kunde. Vedlikehold kan være vedlikehold av alle disse ulike systemene. IT-drift kan være drift av et enkelt system eller hele systemporteføljen til en virksomhet.
For å kunne stille gode sikkerhetskrav til det som skal anskaffes, bør man gjøre en risikovurdering av det området systemet som skal utvikles eller vedlikeholdes skal støtte, eller av områdene som omfattes av driftstjenesten. Skal man for eksempel anskaffe et sak- og arkivsystem og/eller vedlikehold eller drift av et slikt system, har man forhåpentlig god oversikt over informasjonsverdiene som systemet skal behandle, man vet hvilke lover og regler som må overholdes, og man vet hvilke arbeidsprosesser systemet skal understøtte.
I en risikovurdering i forbindelse med en systemanskaffelse ser man for seg hva som kan gå galt, og hvordan systemets ønskede funksjonalitet kan utnyttes eller angripes. En risikovurdering i forbindelse med utsetting av en vedlikeholds- eller driftstjeneste relatert til det samme systemet må legge mer vekt på en driftssituasjon med reelle data i systemet, og hvilke krav man da må stille til leverandøren for at man som kunde kan forsikre seg om at leverandørens rutiner og systemer sikrer at disse dataene blir tilstrekkelig sikkert håndtert. Deretter vurderer man, som vanlig, konsekvens dersom en hendelse inntreffer, og sannsynlighet for at en hendelse oppstår, og gir den aktuelle konsekvensen. Noe risiko kan man leve med, men for det resterende må man utforme sikkerhetskrav til løsningen slik at risikoen håndteres.
Ved en anskaffelse er det å identifisere sikkerhetskrav det samme som å identifisere tiltak i andre sammenhenger. Slik kravstilling er derfor første del av risikohåndteringen. Rent praktisk blir imidlertid identifisering og eventuell utforming av krav oftest utført direkte i forlengelsen av selve risikovurderingen. Vi kommenterer det derfor kort her.
Det er, som alltid, viktig at kravene man kommer frem til, ikke er for detaljerte. De skal si hva løsningen må gjøre, men ikke hvordan. Et eksempel på et godt krav i forbindelse med anskaffelse av sak- og arkivsystem kan være:
Og et altfor detaljert krav er:
I det siste eksempelet låser man løsningen for mye. Den siste typen krav kan kun benyttes dersom hva slags kryptering som skal benyttes fremgår av lovverk, forskrift eller standarder man er pålagt å følge.
Særlig i forbindelse med anskaffelse av IT-drift eller -vedlikehold vil det kunne være relevant å stille krav til leverandørens systemer og prosesser, for eksempel krav om NS-ISO/IEC 27001-sertifisering. Dette vil i så fall være et kvalifikasjonskrav til leverandøren og ikke et krav til løsningen eller til tjenesten du kjøper.
Både når man anskaffer IT-løsninger, -vedlikehold og -drift må man undersøke om det vil være relevant å stille krav som
krav som er avledet av systemets ønskede funksjonalitet, det vil si risikobaserte krav.
Når et nytt system skal utvikles, er det viktig at sikkerhetsaspektet er med fra begynnelsen. På den måten kan man realisere målsettingen om innebygd informasjonssikkerhet. Dette kan oppleves som en stor oppgave i utgangspunktet, men vil over tid medføre færre feil i systemet og generelt bedre kontroll.
Som for anskaffelser tar risikovurderingen utgangspunkt i behov. Man vet hvilke oppgaver eller prosesser systemet skal understøtte. Kanskje har man ikke i utgangspunktet full oversikt over informasjonsverdiene systemet vil forvalte. Man har heller ikke i første omgang full oversikt over systemets funksjonalitet – hvordan behovet skal løses. Det er derfor viktig å presisere at risikovurderinger brukt i systemutvikling er en iterativ prosess. Det handler om risikostyring over tid, både gjennom utviklingsfasen og videre i drift og vedlikehold. Når man vurderer å gjøre en endring, må man også oppdatere og revidere systemets risikovurdering.
Også ved systemutvikling er det å identifisere sikkerhetskrav det samme som å identifisere tiltak i andre sammenhenger. Vi er formelt sett over på første del av risikohåndteringen. Som for anskaffelser blir imidlertid identifiseringen av sikkerhetskrav oftest utført direkte i forlengelsen av selve risikovurderingen.
En kravspesifikasjon for utvikling av et system bør inkludere sikkerhetskrav på følgende områder:
Som beskrevet over er fokuset litt forskjellig ved anskaffelser av ferdige løsninger versus nyutvikling av systemer. Allikevel er det et sett teknikker som i begge tilfeller er nyttige for å finne frem til hendelsesscenariene man skal ta stilling til i en risikovurdering og ved valg av sikkerhetskrav. Disse teknikkene går under fellesnavnet metoder for trusselmodellering. Microsoft er blant de selskap i verden som har jobbet lengst og grundigst med sikkerhet i utvikling av systemer, og trusselmodellering er grunnsteinen de baserer sitt arbeid på.
Trusselmodellering kan gjøres på flere ulike måter, hvorav vi omtaler tre her. Disse tre har litt ulikt utgangspunkt, og hvilken man velger, avhenger av hva man ønsker å analysere. Felles for dem alle er at det handler å se på systemet slik det skal bli, for så å innta angriperens perspektiv og se på hvordan dette kan utnyttes.
Misbrukstilfeller er en variasjon av brukstilfeller. Et brukstilfelle viser hvilken funksjonalitet man ønsker at et system skal ha. Disse kan utvides ved å modellere inn angripere. Poenget er å se systematisk på hvordan ønsket systemfunksjonalitet kan utnyttes av en angriper, og hva man trenger å inkludere av sikkerhetstiltak for å hindre eller begrense effekten av angripers handlinger. Fra disse sikkerhetstiltakene avledes sikkerhetskravene.
Dataflytdiagrammer brukes til å dekomponere et system i dets hovedkomponenter, og analysere informasjonsflyt mellom komponentene. Ofte modellerer man også inn tillitssone, der en tillitssone beskrives med hvilke aktører som har tilgang til denne delen av systemet, og hvor godt beskyttet det er i denne sonen. Dataflytdiagrammer gir en god oversikt over et systems angrepsflate og eksponering. De er også velegnet for å detaljere og dekomponere etter som man får mer informasjon om hvordan systemet bygges.
Angrepstrær tar utgangspunkt i hva en angriper kan ønske å oppnå. Det er en enkel grafisk representasjon av ulike måter en angriper kan oppnå dette målet – ved å utnytte systemer eller mekanismer rundt systemet. I et angrepstre kan man også gjøre en form for risikovurdering direkte, ved å vurdere risikoen for et angrep (en vei til målet), med utgangspunkt i de sikkerhetstiltakene som er implementert. Det handler om å finne de svake punktene. Angrepstrær er også et veldig godt utgangspunkt for å planlegge risikobasert sikkerhetstesting av et system.
────────────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────────────
