Krav til informasjonssikkerhet - IKT anskaffelser

Hvilke krav bør du stille til leverandørene, og hvilke krav bør du stille til tjenesten. Bør man stille særskilte krav til skytjenester? Her finner du råd og eksempler på hvilke spørsmål og krav du bør vurdere å stille til informasjonssikkerhet i en anskaffelsesprosess

Publisert: 20. jun 2019, Sist endra: 08. nov 2019

Når man skal stille krav til informasjonssikkerhet i en tjeneste må man gjennomføre en risikovurdering av systemet eller arbeidsprosessen som tjenesten skal inngå i.

Risikoen ved å bruke skytjenester er avhengig av hvilken informasjon som skal behandles og om de egner seg for å behandles i skyen. Hvilke tiltak har leverandøren implementert for å tilfredsstille dine krav til sikkerhet? Vurder om tiltakene er gode nok og hvilken risiko (restrisiko) du kan akseptere.

Krav til leverandør

Eksempel på kvalifikasjonskrav jf. FOA § 16-7

Krav til styringssystem for informasjonssikkerhet, ISO/IEC 27001 eller tilsvarende

ISO 27001 beskriver kravene til et styringssystem for informasjonssikkerhet. Dersom en leverandør etterlever kravene i ISO 27001 kan leverandøren bli sertifisert og få utstedt sertifikat.

Det er leverandørens virksomhet som blir sertifisert, og ikke tjenestene eller produktene som leveres. ISO 27001-sertifisering gir ingen garanti for at tjenestene som leveres er sikre.

Sjekk omfanget/scope for sertifikatet til leverandøren. Dersom den aktuelle tjeneste ikke er dekket av sertifikatet, så sier ikke sertifikatet noe om styringen av sikkerheten knyttet til selve tjenesten.

ISO/IEC 27001 har et tillegg med en referansekatalog med sikkerhetstiltak, Annex A, som benyttes som en sjekkliste. Brukere av standarden kan sammenligne sine valgte sikkerhetstiltak mot listen for å undersøke om noe vesentlig er utelatt. Innholdet i Annex A er hentet fra ISO/IEC 27002.

Forslag til kravtekst

Leverandørens kvalitetssikringsstandard jf FOA § 16-7

Leverandøren skal ha styringssystem for informasjonssikkerhet som tilfredsstiller kravene i ISO 27001 eller tilsvarende. 

Forslag til dokumentasjonskrav

Gyldig ISO 27001-sertifikat eller tilsvarende, eller attest utstedt av uavhengig organ som dokumentasjon for at leverandøren oppfyller kravene etter ISO 27001 eller tilsvarende.

Krav til tjenesten

Risikovurderingen vil avdekke behov for sikkerhetstiltak som du ønsker at leverandøren skal oppfylle. Her finner du eksempler på ulike kilder med forslag til sikkerhetstiltak som kan brukes som krav til informasjonssikkerhet i tjenesten. Husk at det sjelden er et mål å sette krav til alle sikkerhetstiltakene fra en kilde uten tanke på virksomhetens faktiske behov, vurder å hente forslag til tiltak fra flere kilder.

Kravene kan formuleres både som som minimumskrav/må-krav og som tildelingskriterier/bør-krav.

ISO/IEC 27002 eller tilsvarende

Det er viktig at virksomheten har gode prosesser for å gjøre egne vurderinger av risikoer og håndtere disse med riktig valg av sikkerhetstiltak. ISO 27002 beskriver sikkerhetstiltak på ulike områder. For hvert område defineres sikkerhetstiltak med veiledning til hvordan man kan implementere tiltakene.

De ulike områdene er (kapittel i parantes): (5) Information security policies, (6) Organization information security policies, (7) Human resource security, (8) Asset management, (9) Access control, (10) Cryptography, (11) Physical and environmental security, (12) Operations security, (13) Communications security, (14) System acquisition, development and maintenance, (15) Supplier relationships, (16) Information security incident management, (17) Information security aspects of business continuity management og (18) Compliance.

Oversikter som ISO 27002 eller tilsvarende, for eksempel NSMs grunnprinsipper for IKT-sikkerhet, ulike rammeverk, faktaark og veiledere i Norm for informasjonssikkerhet og personvern i helse- og omsorgstjenesten, andre veiledninger fra Difi og Datatilsynet, kan være gode kilder til forslag til sikkerhetstiltak. Husk at det sjelden er et mål å iverksette alle tiltak i en tiltaksbank uten tanke på virksomhetens faktiske behov.

ISO/IEC 27017 eller tilsvarende

ISO 27017 bygger på de samme tiltakene som ISO 27002, men foreslår i tillegg en rekke sikringstiltak for skytjenester.

Det gjelder spesielt kapittel (9) Access control, (12) Operations security, (13)  Communications security, (15) Supplier relations og (18) Compliance som har forslag til ekstra sikringstiltak ved skytjenester.

I tillegg inneholder ISO 27017 et vedlegg, Annex A: Cloud service extended control set.

ISO/IEC 22313 eller tilsvarende

ISO 22313 er en veiledning som bygger på kravene i ISO 22301 om krav til styring og kontroll av kontinuitet i tjenesten, Business Continuity Management Systems (BCMS).

Veiledningen er basert på god internasjonal praksis for PLANLEGGING, ETABLERING, IMPLEMENTERING, DRIFT, OVERVÅKING, GJENNOMGANG, VEDLIKEHOLD og KONTINUERLIG FORBEDRING av et styringssystem som gjør det mulig være forberedt på hendelser som kan forstyrre tjenesten og å kunne være i stand til å respondere når hendelser oppstår for å sikre kontinuerlig drift.

NSMs Grunnprinsipper for IKT-sikkerhet

Grunnprinsippene beskriver hva en virksomhet bør gjøre for å sikre et IKT-system. De beskriver også hvorfor det bør gjøres, men ikke hvordan.

Grunnprinsippene er inndelt i fire kategorier:

1. Identifisere og kartlegge

2. Beskytte

3. Opprettholde og oppdage

4. Håndtere og gjenopprette

NSMs Grunnprinsipper for IKT-sikkerhet versjon 1.1

Normen

Norm for informasjonssikkerhet i personvern i helse- og omsorgstjenesten

Normen er en bransjenorm utarbeidet og forvaltes av organisasjoner og virksomheter i sektoren med sikte på å bidra til tilfredsstillende informasjonssikkerhet og personvern hos den enkelte virksomhet og i sektoren generelt, samt å bidra til at det etableres mekanismer hvor virksomhetene kan ha gjensidig tillit til at øvrige virksomheters behandling av helse- og personopplysninger gjennomføres på et forsvarlig sikkerhetsnivå.

kapittel 5 - Informasjonssikkerhet

- beskriver sentrale sikkerhetstiltak som skal gjennomføres av virksomheter som behandler helse- og personopplysninger. Dette omfatter både dataansvarlige og databehandlere.  Alle sikkerhetstiltak skal være egnede, og velges basert på risikovurderinger. Det kan dermed være nødvendig å gjennomføre mer omfattende tiltak enn det som er beskrevet her.

Last ned Normen

Nedenfor tar vi for oss noen områder hvor man bør vurdere risiko, hvilke tiltak som kan gjøres for å håndtere risikoene og forslag til krav i en kravspesifikasjon. De fleste eksemplene presenteres som BØR-krav/tildelingskriterier, men kan med litt bearbeidelse omskrives til MÅ-krav/minimumskrav.

Lock-In

Risiko

Dersom leverandøren ikke lenger tilfredsstiller dine behov eller gjør endringer i sine produkter eller betingelser som ikke kan aksepteres, må du kanskje bytte leverandør. Da må du på forhånd tenke på en rekke forhold og risikoer dersom du har låst deg til en leverandør (Lock-In).

- Overføring av data: Hvem er ansvarlig for å hente ut data, og hvilket format vil dataene ha, må dataene bearbeides før overføring? Hvor lang tid tar det og hva koster det?

- Overføring av applikasjoner: Det kan være kostbart å omskrive eller rekonfigurere applikasjoner for å kunne kjøres på andre plattformer.

- Overføring av infrastruktur: Alle skyprodusenter (CSP) gjør ting litt forskjellig. Formater på virtuelle maskiner og tilhørende prismodeller varierer mellom ulike leverandører.

- Gjenbruk av Know-how: Kunnskap om verktøy og konfigurering kan sjelden gjenbrukes om du skifter leverandør. Det vil ta tid å tilegne seg samme kunnskapsnivå om ny skyplattform. Nye sertifiseringer må kanskje tas.

Hvordan redusere risiko for Lock-In

- Planlegg tidlig for exit: Allerede når du planlegger for implementering bør du legge en plan for exit og forstå kostnadene ved å bytte CSP. Ikke planlegg for lengre enn et par år for å ivareta fleksibiliteten din.

- Design dine applikasjoner frikoblet fra skyplattform: skyapplikasjonskomponenter bør være så løst knyttet som mulig til applikasjonskomponentene som samhandler med dem. Dette øker fleksibiliteten. 

- Sørg for høy portabilitet av dine data: Unngå proprietær formatering for å maksimere portabiliteten til dine data. Beskriv datamodeller så tydelig som mulig ved å bruke skjemastandarder for å lage detaljert lesbar dokumentasjon. I tillegg bør du sørge for at skyleverandøren din tilbyr deg en måte å trekke ut data enkelt og rimelig.

- Vurder en multi-sky strategi: Du kan bruke en leverandør til prosessering og en annen for datavarehuset, mens du bruker en tredje til din kunstige intelligens. Ved å gå multi-sky blir du mindre avhengig av en leverandør for alle dine behov. En annen fordel er at du kan plukke det beste fra hver skyleverandør slik at du kan implementere "best-of-breed-tjenester" i applikasjonene dine.

- Implementer DevOps verktøy og prosesser: containerteknologi levert av ulike tilbydere bidrar til fjerne avhengigheter til skyleverandørene. De fleste CSPer støtter standard containerformat, som gjør det være enkelt å overføre applikasjonene dine til en ny skyleverandør om nødvendig.

Forslag til tekst i kravspesifikasjon

Beskriv hvilken bistand som ytes i forbindelse med avslutning av avtalen og hvilke aktiviteter med ansvarsmatrise for de ulike aktivitetene dersom Kunden ønsker å flytte Tjenestene. Beskriv hvilke forutsetninger som legges til grunn for slik bistand og hvilke begrensninger som gjelder. Bistanden skal prissettes i Prisbilaget.

Kunden skal beholde eierskapet til Kundens data etter at kontrakten er avsluttet og til data er flyttet og slettet fra tjenesten.

Endring og avlytting av data under overføring

Risiko

Data som overføres via nettverk kan tappes/avlyttes og endres dersom de ikke sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester f.eks. ved bruk av API.

Hvordan redusere risiko for tap eller endring av data under overføring eller avlytting

Beskytte nettverk for å hindre uvedkommende tilgang til data og kryptering for å hindre uvedkommende å lese data.

Forslag til tekst i kravspesifikasjon

Data som overføres via nettverk må sikres. Dette gjelder både data som overføres til og fra tjenesten, internt i tjenesten og data som utveksles med andre tjenester. Beskriv hvordan data under overføring beskyttes, herunder beskyttelse av nettverk og bruk av kryptering.

Datasenterets sikkerhet

Risiko

Uvedkommende kan få tilgang til data, gjøre endringer på systemer og urettmessig fjerne utstyr dersom datasentre ikke er fysisk sikret.

Hvordan redusere risiko for uautorisert adgang til datasenter

Datasenter som benyttes i tjenesten må kunne dokumentere fysisk sikring.

Forslag til tekst i kravspesifikasjon

Beskriv hvilke fysiske sikringstiltak som benyttes i de datasenter som brukes for å levere tjenesten slik at uvedkommende ikke får tilgang til data, systemer og utstyr.

Sikring av lagret informasjon

Risiko

Ofte er det mange ulike aktører som har adgang til en skyleverandørs datasentre, men som ikke skal ha tilgang til dine data. Derfor må dine data være sikret mot uautorisert tilgang.

Hvordan redusere risiko for uautorisert tilgang til dine data

En kombinasjon av fysisk sikring (se "Risiko: Datasenterets sikkerhet") og kryptering av lagrede data.

Du bør kreve at lagrede data skal være kryptert og sikre at håndtering av krypteringsnøkler følger beste praksis , f.eks. å skille nøkkeladministrasjon og bruk av nøkler. Krypteringsnøkler skal ikke lagres i skyen.

Forslag til tekst i kravspesifikasjon

Beskriv hvordan plattform og lagrede data sikres ved bruk av kryptering. Beskriv hvordan krypteringsnøkler håndteres. Hvordan sikrer man skille mellom administrasjon av krypteringsnøkler og bruk av krypteringsnøkler.

Sletting av data

Risiko

Data som skal slettes kan komme på avveie eller gjenskapes dersom leverandør ikke sletter dine data på en sikker og trygg måte. Dette gjelder også dersom leverandøren bytter ut sitt utstyr og flytter dine data over til nytt utstyr, da må leverandøren sikre at dine data ikke blir tilgjengelig på det gamle utstyret.

Hvordan redusere risiko for usikker og ukomplett sletting av data

Leverandøren må kunne dokumentere hvordan han sletter data og hvordan han sikrer at slettede data ikke kommer på avveie eller kan gjenskapes. Den eneste måten å fullstendig slette data på, er å ødelegge lagringsmediet. Det er det vanskelig å få gjennomført siden det ofte er andre kunder som også bruker samme ressurser til sine data.

Forslag til tekst i kravspesifikasjon

Beskriv hvordan du sletter data og sikrer at data som er slettet ikke blir tilgjengelig for andre eller kan gjenskapes. Beskriv også hvordan du sikrer at slettede data ikke blir tilgjengelig ved utskifting og fornyelse av infrastruktur.

Tilgjengelighet

Risiko

Tjenesten kan bli utilgjengelig dersom den ikke er tilstrekkelig robust for å kunne stå imot uønskede hendelser. Uønskede hendelser kan være ondsinnede angrep, tekniske feil og menneskelige feil.

Hvordan redusere risiko for utilgjengelighet og nedetid

Leverandøren må forplikte seg til tilgjengelighet i tjenesten og garantere oppetid. Leverandøren bør også kunne vise til statistikk og historiske data for oppetid/tilgjengelighet.

Du kan også vurdere å be om informasjon om hvordan leverandøren har designet tjenesten for å kunne være robust og sikre oppetid/tilgjengelighet.

Forslag til tekst i kravspesifikasjon

Beskriv den garanterte tilgjengelighet og dokumenter oppetidsgarantien med historiske data. Dersom det brukes ulike tilgjengelighetsgarantier, så skal disse beskrives og hvilke betingelser som gjelder for de ulike garantiene.

Beskriv hvilke tiltak og prosedyrer som er etablert for å sikre tjenestens robusthet og tilgjengelighet.

Separasjon mellom kunder

Risiko

En kunde kan påvirke en annen kundes tjeneste eller data dersom det ikke er tilfredsstillende skille mellom kundene.

Hvordan redusere risiko for at andre kunder skal kunne påvirke tjenesten

Leverandøren må sørge for tilstrekkelig skille mellom kundene sine. Dette kan gjøres ved bruk av anerkjente virtualiseringsteknikker for både prosessering, nettverk og lagring. Man kan også separere kunder ved bruk av operativsystem, webtjenere eller applikasjoner.

Forslag til tekst i kravspesifikasjon

Beskriv hvordan kundenes tjenester og data skilles fra hverandre og hvordan denne separasjonen kan kontrolleres og styres av Kunden.

Endringshåndtering

Risiko

Alle endringer som kan påvirke tjenesten må håndteres for å hindre utilsiktede hendelser. Dette gjelder både utvikling, nyanskaffelser og utskifting av applikasjoner, infrastruktur, nettverk og systemkomponenter.

Hvordan redusere risiko for hendelser ved endringer

Leverandøren må ha prosess for å håndtere endringer. Prosessen skal sikre at endringer som kan påvirke sikkerheten identifiseres og håndteres, og at uautoriserte endringer kan oppdages.

Forslag til tekst i kravspesifikasjon

Beskriv prosessen for endringshåndtering for både utvikling, integrasjoner, applikasjoner, nettverk og systemkomponenter. Beskriv også hvordan endringshåndtering ivaretas i hele verdikjeden for tjenesten. Hvordan sikrer man  at det kun er autoriserte endringer som blir implementert i tjenesten.

Trussel- og sårbarhetsvurderinger

Risiko

Trusselbildet endrer seg kontinuerlig, og derfor er det viktig at leverandøren har en løpende prosess for å identifisere, vurdere og prioritere trusselbildet, samt arbeider aktivt for å begrense sårbarheter.

Hvordan redusere risiko

Leverandøren må holde seg oppdatert på risikobildet, analyserer løpende potensielle trusler og sårbarheter, og ha rutiner for å sikre at det blir gjennomført relevante tiltak.

Forslag til tekst i kravspesifikasjon

Beskriv prosessen for trussel- og sårbarhetsvurderinger. Beskriv også hvordan sårbarheter håndteres og hvilke prosedyrer med tidsrammer som brukes for de ulike typer av sårbarheter.

Sharethis

Hjelp oss å bli bedre

Fant du det du lette etter?

Tilbakemeldinger blir ikke besvart. Gå til siden med kontaktinformasjon hvis du trenger hjelp.

Hjelp oss å bli bedre
*