Digitaliseringsdirektoratet
Internkontroll/styringssystem (Versjon 1.5)
Internkontroll/styringssystem (Versjon 1.5)
Sikkerhetstiltak er sentralt innen informasjonssikkerhet. Denne artikkelen inneholder grunnleggende fagkunnskap om sikkerhetstiltak. Dette er bakgrunnsstoff («Godt å vite») til hovedaktiviteten Risikohåndtering.
Et tiltak er noe som iverksettes for å oppnå noe – nå et mål eller oppfylle et krav. Innen informasjonssikkerhet og annen risikostyring iverksetter vi tiltak for å unngå, dele eller redusere risiko.
Noen tiltak er engangstiltak og andre er varige tiltak. Varige tiltak som etableres for å endre eller redusere risiko, kan vi kalle risikomodifiserende eller risikoreduserende tiltak. Ofte benytter vi bare kortformen tiltak her også.
På engelsk er det vanlig å bruke begrepet control for slike varige tiltak for å redusere risiko. Begrepet blir også ofte brukt mer spesifikt som security control og information security control. Dette tilsvarer de norske begrepene sikkerhetstiltak og informasjonssikkerhetstiltak.
Begrepene control og tiltak benyttes på tvers av disipliner for internkontroll og håndtering av risiko. Det er for eksempel vanlig å benytte privacy control for personverntiltak. Man kan også kalle mesteparten av innholdet i ISO/IEC 27001 bortsett fra Annex A for management controls – tiltak for effektiv risikostyring. Et eksempel er risikostyringsprosessene som benyttes i virksomheten. Dette kan kalles ledelsestiltak, systemrettede tiltak eller styringstiltak på norsk.
Tiltak innenfor forskjellige deler av en virksomhets helhetlige internkontroll kan overlappe og virke sammen på forskjellig vis. Brannsikring som HMS-tiltak som skal sikre liv og helse, kan være sammenfallende med sikkerhetstiltak som skal sikre informasjonssystemer mot brann.
Noen tiltak er veldig spesifikke og påvirker en risiko direkte. Andre påvirker flere risikoer indirekte eller i mindre grad. Dette omtales som control precision på engelsk.
Informasjonssikkerhetstiltak er tiltak som etableres for å håndtere risiko knyttet til konfidensialitet, integritet og tilgjengelighet i informasjonsbehandling.
I denne veiledningen benytter vi begrepet sikkerhetstiltak. Man kan argumentere for at informasjonssikkerhetstiltak ville være et mer presist og korrekt begrep, men kortformen er godt innarbeidet og forståelig for de fleste.
Begrepet sikringstiltak benyttes i mange sammenhenger synonymt med sikkerhetstiltak.
Et sikkerhetstiltak er noe som etableres for å virke over tid. Det er relatert til sikkerhet og etablert for å redusere eller på annen måte modifisere risiko. Det kan dokumenteres og stå på en liste eller inngå i en oversikt over en virksomhets etablerte sikkerhetstiltak, og man bør kunne peke på en navngitt person eller funksjon som har ansvaret for å forvalte og forbedre tiltaket.
En del av de tiltakene som iverksettes for å håndtere risiko, bærer preg av å være engangstiltak. Man utfører noe, og så er man ferdig. Dersom man velger å unngå risiko ved å slutte å utføre oppgaven som var opphavet til risikoen, så vil man kunne kalle beslutningen om å slutte med oppgaven for et engangstiltak. Vi kan også ha engangstiltak når vi snakker om å redusere risiko. Her er et eksempel:
Risikovurdering av et informasjonssystem viser høy risiko for flere uønskede hendelser på grunn av høy sårbarhet fordi et stort antall kjente sårbarheter varslet av programvareleverandører ikke er patchet. Tiltak: installere sikkerhetspatcher på systemet.
Dette er et engangstiltak. I dette eksempelet vil tiltaket redusere risiko på kort sikt, mens det på lengre sikt må antas å ha liten verdi, etter som nye tekniske sårbarheter blir avdekket og gjort kjent.
Det vil være mer hensiktsmessig å få på plass gode prosesser for kontinuerlig oppfølging av kjente tekniske sårbarheter i programvare og utstyr som virksomheten benytter. Det er da også et slikt varig tiltak du finner i referansekatalogen i ISO/IEC 27001 Annex A.
I vårt enkle eksempel vil umiddelbar patching også være aktuelt – som strakstiltak for å redusere sårbarheten og i påvente av andre varige tiltak.
Når det er snakk om å redusere risiko ved innføring av sikkerhetstiltak er det som regel slike varige tiltak som benyttes. Stort sett alle sikkerhetstiltak i anerkjente tiltaksbanker er av denne typen.
Sikkerhetstiltak har forskjellige virkeområder – området hvor tiltaket har effekt.
Noen tiltak inngår i sentrale prosesser som gjelder for hele virksomheten, andre tiltak etableres for ett bestemt informasjonssystem. Tiltak kan etableres for en bestemt arbeidsoppgave, for en organisatorisk enhet, eller for å sikre en bestemt fysisk lokasjon.
Det er viktig at man er bevisst hvilket virkeområde et tiltak har. Det kan være uheldig om man tror et tiltak har effekt et sted dersom det ikke har det, og det vil være fornuftig å bruke ressurser på tiltak bare der det er behov for dem.
Det er ikke alltid enkelt å kommunisere rundt begrepene tiltak og control. Det oppstår forvirring ettersom noen bruker en direkte fornorskning av control til kontroll – andre finner det mer naturlig med oversetting til tiltak. Begrepet kontroll benyttes i blant om en spesifikk type tiltak – kontrolltiltak – og ikke som et generelt varig tiltak for å redusere risiko, som begrepet control i denne sammenhengen egentlig betyr.
En annen årsak til forvirring er at vi på norsk ofte benytter ordet tiltak i en bredere sammenheng enn control. Vi bruker begrepet tiltak for
I tillegg bruker vi begrepet tiltak om større sammensatte prosjekt, for eksempel for å forbedre en rekke av våre eksisterende sikkerhetstiltak. Slike forbedringstiltak, eller forbedringsprosjekter, kan både bestå av etablering av nye sikkerhetstiltak og utbedring av eksisterende sikkerhetstiltak – eller avvikling av sikkerhetstiltak.
Vi anbefaler at man er bevisst denne varierende bruken av begrepet tiltak på norsk, og at man spesielt er tydelig i kommunikasjonen rundt valg og etablering av varige sikkerhetstiltak.
Flere anerkjente standarder for styring og kontroll med informasjonssikkerhet benytter sammenfallende definisjoner av security control. Vi ser her kort på to av disse, slik at de kan ses i sammenheng med vår bruk av begrepet sikkerhetstiltak.
ISO/IEC 27001 beskriver bruk av security controls for behandling av informasjonssikkerhetsrisiko. Security control er en godt innarbeidet faguttrykk på engelsk, og benyttes i samme betydning i de fleste anerkjente standarder og rammeverk på informasjonssikkerhetsområdet.
ISO/IEC 27000:
control: measure that is modifying risk Note 1 to entry: Controls include any process, policy, device, practice, or other actions which modify risk. Note 2 to entry: It is possible that controls not always exert the intended or assumed modifying effect.
Legg merke til at ISOs definisjon i utgangspunktet kan leses slik at den inkluderer engangstiltak, mens referansekatalogen med sikkerhetstiltak i Annex A peker på varige tiltak.
ISO benytter begrepet control for behandling av risiko i alle sine risikostyringsstandarder, på tvers av disipliner. Security control betegner de tiltakene som behandler informasjonssikkerhetsrisiko. I 27000-serien benytter ISO i noen tilfeller information security control.
(National Institute of Standards and Technology) NIST SP 800-53 rev 4 Appendix B:
Security control: A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.
Det som tydeliggjøres av NISTs definisjon, er at en virksomhet etablerer sikkerhetstiltak både for å behandle risiko etter egne vurderinger, og for å imøtekomme pålagte krav. Det finnes tilfeller hvor lovverk og avtalemessige forhold stiller spesifikke krav til sikkerhetstiltak — tiltak som skal etableres uavhengig av virksomhetens egen vurdering av risiko.
Det finnes flere måter å gruppere eller kategorisere sikkerhetstiltak på – i forskjellige dimensjoner. Dette kan være nyttig i flere sammenhenger – spesielt når man i risikohåndteringen skal vurdere hvilke tiltak som vil være mest hensiktsmessige og kostnadseffektive for å modifisere en konkret risiko.
En kan skille mellom tiltak som har som formål å forebygge uønskede hendelser, tiltak som skal oppdage og avdekke hendelser, og tiltak som skal benyttes i respons på hendelser som er under utvikling eller har funnet sted.
Et eksempel på slik gruppering er:
Dette er en grovsortering, og det er ikke uvanlig at ett tiltak bidrar på tvers av disse kategoriene.
Virksomheter bør regne med at de kommer til å få hendelser som kan påvirke informasjonssikkerheten. Mange regner også med at de allerede er utsatt for sikkerhetshendelser som de ennå ikke har oppdaget, for eksempel ved at angripere har tilgang til nettverk og systemer. Det kan være nyttig å se på hvordan man bruker ressursene sine. Brukes de primært til å forsøke å forebygge hendelser? Eller er man også i stand til å oppdage og håndtere hendelsene på en god måte? Det siste kan i mange tilfeller være mer kostnadseffektivt enn å ha ambisjon om å hindre alt, og styre det meste av ressurser inn på det. Dette er viktige aspekter å ha med seg når man i risikohåndteringen vurderer hvor hensiktsmessige forskjellige sikkerhetstiltak er.
Det er også mulig å gruppere tiltak etter type. For eksempel slik:
Disse tiltakstypene over er generelle, og ikke spesielle for informasjonssikkerhet. De er relevante for alle områder man ønsker at virksomhetens samlede internkontroll skal dekke. Ett tiltak kan virke inn på flere internkontrollområder.
I risikohåndteringen er det å tenke på tiltakstyper nyttig i forbindelse med den innledende refleksjonen over hvilke typer tiltak som er hensiktsmessig å velge, før man går ned på detaljerte tiltak.
En tredje nyttig gruppering kan være tiltaksområde. Dette er "familier" av sikkerhetstiltak som henger sammen, ofte knyttet til en felles tiltaksleverandørs ansvarsområde.
Inndelingen kan gjøres på forskjellige måter. På overordnet nivå kan én slik inndeling være:
Mange virksomheter vil ha ansvarlige for sikkerhetstiltak innenfor en rekke av disse områdene. Vi kaller dem tiltaksleverandører. De kan være interne eller eksterne. Dersom de er eksterne, vil en virksomhet normalt ha en person eller organisatorisk enhet internt som fungerer som et bindeledd mot de eksterne. Dette er spesielt vanlig ved utkontraktering av områder som IKT-drift og bygningsdrift.
I tillegg vil de som eier arbeidsoppgaven eller informasjonssystemet, selv kunne være ansvarlig for sikkerhetstiltak på flere av tiltaksområdene.
En annen måte å gruppere sikkerhetstiltak på er etter sikkerhetsmål.
Bruk av sikkerhetsmål kan lette kommunikasjonen mellom risikoeiere og tiltaksleverandører. Risikoeiere kan i sin håndtering av risiko utforme behov eller krav på et overordnet nivå. Behovene blir utformet som sikkerhetsmål for tiltaksområder. Tiltaksleverandører foreslår og tilbyr konkrete sikkerhetstiltak for å understøtte sikkerhetsmålene.
Ved slik bruk av sikkerhetsmål bør man merke seg forskjellen på virksomhetens overordnede mål for informasjonssikkerhet og de sikkerhetsmål som etableres for ulike tiltaksområder. De førstnevnte bør være nedfelt i virksomhetens policy for informasjonssikkerhet, og gir sammen med kriterier for å akseptere risiko en retning for alt informasjonssikkerhetsarbeidet. Sikkerhetsmål for ulike tiltaksområder kan benyttes som et redskap på veien mellom risikovurderinger og detaljerte sikkerhetstiltak.
Sikkerhetsmål kan defineres for bestemte funksjoner og nivå i en virksomhet. Jf. ISO/IEC 27001:2013 6.2.
Tiltaksbanker grupperer tiltak på forskjellige måter – tiltaksområder, sikkerhetsmål og forskjellige andre strukturer benyttes. Dersom en virksomhet gjennomførende benytter en bestemt tiltaksbank, kan det være hensiktsmessig å sortere virksomhetens tiltak på samme måte som i tiltaksbanken.
En virksomhet bør ha tilstrekkelig dokumentasjon av sikkerhetstiltak. Hva som er tilstrekkelig dokumentasjon, vil variere. Organisasjoner av forskjellig størrelse og kompleksitet på virksomhetsprosesser og IKT-systemer vil ha forskjellige behov.
Element som kan inngå i slik dokumentasjon, er f.eks.:
Dersom tiltaket er hentet fra en ekstern tiltaksbank, kan det være fornuftig å dokumentere en referanse til denne. Det kan være nyttig når man følger med på oppdateringer av tiltaksbanken. Det kan også være nyttig for å ha et felles referansepunkt i kommunikasjon med andre.
Sikkerhetstiltak kan være snevre og detaljerte, eller mer overordnet.
Se f.eks. tiltakene i Annex A i ISO/IEC 27001 – de varierer i detaljeringsgrad. A.12.2.1 Controls against malware kan anses for å være på tilsvarende nivå som A.12.4 Logging and monitoring. Men sistnevnte er en samlebetegnelse for fire understøttende sikkerhetstiltak, hvorav A.12.4.4 Clock synchronisation kan sies å være ganske detaljert.
Det er i det hele tatt mange måter å beskrive sikkerhetstiltak på – både i måten man deler opp i forskjellige sikkerhetstiltak, og detaljeringsgraden man legger opp til.
Risikoeiere og tiltaksleverandører vil ha forskjellige behov for dokumentasjon av sikkerhetstiltak. Disse behovene kan skisseres slik:
Risikoeier
Tiltaksleverandør
God kommunikasjon om risiko og sikkerhetstiltak mellom risikoeiere og tiltaksleverandører er viktig for å få velfungerende forvaltning av sikkerhetstiltakene. Man bør gjøre en vurdering av hvilke behov man har i virksomheten, og sørge for at en har tilstrekkelig og hensiktsmessig dokumentasjon av sikkerhetstiltak. Legg spesiell vekt på å få på plass beskrivelser som kommuniserer godt til risikoeiere som skal ta beslutninger om håndtering av risiko.
En måte å håndtere de forskjellige behovene for dokumentasjon og kommunikasjon kan være å dokumentere sikkerhetstiltakene i form av overordnede tiltak og detaljtiltak.
Et veldig enkelt eksempel som kan illustrere en slik inndeling er det overordnede tiltaket Adgangskontroll, med en del detaljtiltak under:
Ved å gjøre en slik inndeling kan en ha ulike varianter av samme overordnede tiltak, med ulik tiltaksstyrke, hvor forskjellen er detaljtiltakene som inngår i det overordnede tiltaket.
Et eksempel på dette kan illustreres slik:
Beskrivelsen i dette eksempelet kan være tilstrekkelig for å dekke behovet til de fleste risikoeierne i en virksomhet. Når det er behov for å gå ned i detaljene – for eksempel i forbindelse med analyse av spesifikke risikoer – kan tiltaksleverandøren bidra med nødvendige detaljer og ekspertise.
────────────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────────────
