Håndbok for informasjonssikkerhet i informasjonsnett dokumenter/KITH...NFR-ININ-S ISBN 82-7846-048-5 Dato 18.05.1998 Antall sider 35 Kvalitetssikret av Hans Jørgen Varfjell Gradering

Håndbok forinformasjonssikkerhet

i informasjonsnett

KITH Rapport 7/98ISBN 82-7846-048-5

ForprosjektrapportNFR-prosjekt 119410/250

18. mai 1998

KITH-rapportTittel

Håndbok for informasjonssikkerhet iinformasjonsnett

Forprosjektrapport

Forfatter(e)

Kenneth R. Iversen (KITH) ogJon Ølnes (Norsk Regnesentral)

Oppdragsgiver(e)

Norges forskningsråd, NIN-programmet

Kompetansesenter for ITi helsevesenet AS

Postadresse

Sukkerhuset7005 Trondheim

Besøksadresse

Sverresgt 15

Telefon

73 59 86 00

Telefaks

73 59 86 11

Epost

[email protected]

Foretaksnummer

959 925 496Rapportnummer

KITH R 7/98URL

http://www.kith.no/rapportarkiv/inin_s_forprosjekt.pdfProsjektnummer

NFR-ININ-SISBN

82-7846-048-5Dato

18.05.1998Antall sider

35Kvalitetssikret av

Hans Jørgen VarfjellGradering

ÅpenGodkjent av

Kenneth R. Iversen /Sign./Direktør (kst.)Sammendrag

Rapporten inneholder delresultater fra forprosjektet "Håndbok for informasjonssikkerhet iinformasjonsnett" som er gjennomført i regi av ININ-programmet under Norges forsknings-råd. Det foreslås iverksatt et hovedprosjekt for utvikling av en Web-basert håndbok/ veile-der/ informasjonsbørs med det formål å gi informasjon, råd, veiledning o.a på området in-formasjonssikkerhet, primært for demonstratorprosjektene i NIN, men også mer generelt tilaktører som planlegger eller er i ferd med å knytte seg til eller å etablere informasjonsnett.Det skisseres også en gjennomføringsplan for et slikt hovedprosjekt.

Som et grunnlag for arbeidet med utviklingen av den Web-baserte håndboken, skisseres detinnledningsvis en modell for informasjonssikkerhet i informasjonsnett. Videre diskuteressikkerhetsarkitekturer for informasjonsnett og et eksempel på en arkitektmodell beskrives.

Det skisseres også en tiltaksplan som prosjekter med formål å tilkople virksomheter til elleretablere informasjonsnett, kan benytte for å tilnærme seg utfordringene ved hensiktsmessi-ge og tilstrekkelige sikringstiltak.

Det gis også en del definisjoner på sentrale begreper som det børe være en felles forståelseav innen rammene av NIN-programmet, og som kan inngå i håndboken i en utvidet, merfyllestgjørende versjon.

Til slutt gis det en summarisk oversikt over norske kompetansemiljøer innen området somkan involveres aktivt i arbeidet med håndboken gjennom å dele erfaringer og kompetansemed andre via Web-en.

mailto:[email protected]

http://www.kith.no/rapportarkiv/inin_s_forprosjekt.pdf

Innhold

BAKGRUNN ..................................................................................... 1SIKKERHETSMODELL OG -ARKITEKTUR .............................................. 2

Sikkerhetsmodell 2Sikkerhetsarkitektur 4Sikkerhetsdomener 5Mennesker, utstyr og programvare i domener 6

TILNÆRMINGSMÅTE FOR SIKRINGSTILTAK .......................................... 9Sikkerhetstiltak gir gevinster 9Faktorer for en vellykket satsing 10Plan for informasjonssikkerhet (skisse) 10

Fase 1 11Fase 2 12Fase 3 14

SKISSE AV PLAN FOR HOVEDPROSJEKT ........................................... 15Formål og format 15Håndbokens innhold 16Gjennomføring av hovedprosjekt 17

Fase 1 Detaljplanlegging 17Fase 2 Gjennomføring 17Tid og ressurser 18

NOEN SENTRALE BEGREPER ........................................................... 19NORSKE KOMPETANSEMILJØER ...................................................... 24

Kompetansemiljøer 24Forskningsinstitutter o.l 24Sikkerhetsevaluering o.l 24Faglige interesseorganisasjoner o.l 25Forvaltningsorganer o.l 25Standardiseringsorganisasjoner o.l 25TTP-tjenesteleverandører m.m 25Andre 25Leverandører 26

LITT OM SIGNERING OG KRYPTERING ............................................... 27Signering 27Kryptering 30Signerings- og krypteringsnøkler 31Sikring mot utilsiktet utlevering, innbrudd og angrep 31

N

I

N

I I

I N F O R M A S J O N S S I K K E R H E TF O R I N F O R M A S J O N S N E T T

1

Behovet for informasjonssikkerhet blir stadig mer åpenbart oggode teknologiske løsninger tilbys på stadig flere problemom-råder. Dessverre synes ikke bevisstheten og kunnskapen omhvordan en skal gripe an arbeidet med å etablere tilstrekkeliginformasjonssikkerhet å være like god.

Både gode og ikke fullt så gode brannmurer, krypteringsløsninger ogandre tekniske sikkerhetsløsninger tilbys av stadig flere forhandlere ogselskaper som har sikkerhet som en sentral del av sin portefølje. På denandre siden er det stadig flere virksomheter som kjøper slike løsninger.Det hører derimot med til historien at mange nok søker slike løsningerbåde for sent og uten å ha lagt et nødvendig grunnlag for å gjøre de rettevalgene for egen virksomhet, bl.a gjennom å ha etablert en sikkerhetspo-licy for sin virksomhet. Den stadig raskere utviklingen av Internett ogulike nettjenester gir betydelige utfordringer og muligheter for alle typervirksomheter, ikke minst når det gjelder å ivareta informasjonssikkerhe-ten for egen virksomhet. Brannmur er svaret mange gir, men hva eregentlig spørsmålet?

Innen rammene av NFR-programmet NIN (Nasjonalt InformasjonsNett)er bevisstheten generelt god fordi sikkerhetsaspekter har blitt poengtertfra et tidlig tidspunkt, men også her råder en del usikkerhet og forvirring:

Hva menes egentlig med sikkerhet – eller informasjonssikkerhet? Hvabetyr begrepene, noen brukes i andre "stammespråk" med andre betyd-ninger? Hvorfor og hvordan skulle vi gjøre noe med sikkerhet i vårt pro-sjekt? Dette er spørsmål som er reist, og som så langt ikke er dekkendebesvart.

I forprosjektrapporten for ININ (infrastruktur for NIN), avlevert oktober1996, ble det foreslått å iverksette et prosjekt "som på et praktisk nivå[kan] initiere og støtte prosessen som er nødvendig for at NIN-demonstratorene får implementert løsninger med sikringstiltak tilpassetformålet". Videre: "Det skal utarbeides en veiledende håndbok der sy-stematiske, organisatoriske, administrative og tekniske forhold som måivaretas, blir adressert".

Denne rapporten er et resultat fra det forprosjektet som ble etablert for åutrede grunnlaget for et evt hovedprosjekt som kan utarbeide en slik vei-leder for NIN-demonstratorene.

Kapittel

1Bakgrunn


2

Dette kapitlet skisserer en sikkerhetsmodell som vil bli lagt tilgrunn i forprosjektet. Formålet med modellen er å tydeliggjørede ulike aspektene som må vektlegges for å etablere informa-sjonssikkerhet i informasjonsnett. Kapitlet framhever også be-hovet for å beskrive en sikkerhetsarkitektur ved etablering avinformasjonsnett, enten dette er interne nett som koples til In-ternett og eller til bransjenett el.l.

Sikkerhetsmodell 1

Sikkerhetsmodellen som her beskrives, legger til grunn at de sikkerhets-messige hovedmålene er å verne virksomhetens informasjon mot konfi-densialitetsbrudd, manglende integritet/kvalitet eller manglende tilgjen-gelighet av informasjon (KIT-egenskapene). Den legger videre til grunnat hovedtruslene mot virksomheter som knytter seg til eksterne, åpneinformasjonsnett (f.eks Internett) er knyttet til:

• innbrudd fra eksternt nett med sikte på å tilegne seg eller endre/slette(sensitiv) informasjon eller forstyrre integriteten i sikkerhetsløsninge-ne

• uautorisert (utilsiktet eller tilsiktet) utlevering av sensitive opplysnin-ger ved bruk av de aktuelle tjenestene

• datadrevne angrep (virus, trojanske hester og andre "overraskelser"som overbelastning ("spamming") o.l) som følge av ordinær (tilsiktet)informasjonsflyt, eller som følge av feil bruk av informasjonssystemerog kommunikasjonstjenester

• sikkerhetsbrudd under overføring, f.eks at sensitivt innhold i epostleses av uvedkommende eller at meldinger endres, legges til (forfals-ket) eller slettes av uvedkommende under overføring.

Sikkerhetsmodellen som legges til grunn i dette forprosjektet er skissert iFigur 1 under. Poenget med modellen er å poengtere at ved tilkopling tilusikre nett eller sammenkopling av nett (hvorav minst ett anses å væreusikkert) bør fokuset rettes mot (minst) tre hovedaspekter som kreverulike typer sikkerhetstiltak. 1 Sentrale begreper er definert i Vedlegg A.

Sikkerhetsmodell og-arkitektur

Kapittel

2

S I K K E R H E T S M O D E L L O G - A R K I T E K T U R

3

Avgrensning av virksomheten/nettet

EndesystemsikkerhetSaklig og legitim informasjonsflyt

Sikker håndtering og oppbevaringObjektsikkerhet

Kommunikasjonssikkerhet

Tilkoplingssikkerhet

Sikring av tilkoplingspunktetog tilkoplingsformen mot eksternt nettverk

Sikring av kommunikasjonmellom endesystemer

"Eksternt" nettverk

Det er i modellen forutsatt at det er gjort en avgrensing av virksomheten,organisatorisk, logisk og teknisk (og i en del tilfeller også fysisk). Poen-get med den noe markante muren som avgrenser virksomheten er at detmå eksistere kun ett organisatorisk/logisk tilkoplingspunkt, om enn gjer-ne delt i ulike tekniske og fysiske installasjoner, men underlagt en (etfelles sett av) sikkerhetspolicy og sikkerhetsorganisasjon.

Som indikert i Figur 1, omhandler sikkerhetsmodellen tre hovedelemen-ter:

1. Endesystemsikkerhet som skal sørge for at informasjonsflyten er sak-lig og legitim i forhold de prosessene og sammenhengene denne inn-går i. Autentisering og autorisasjon av brukere i endesystemet, både iforhold til lokal tilgang og til å benytte kommunikasjonstjenester, ereksempler på dette. Systemintegriteten til endesystemene må være i-varetatt. Objektsikkerhet, d.v.s sikring av informasjonsobjekter i ende-systemene som også gir sikring av objektene under kommunikasjon eret annet eksempel.

2. Kommunikasjonssikkerhet som skal ivareta selve kommunikasjonenmellom endesystemer (konfidensialitet, integritet, autentisitet, ikkebe-nekting). Vi skiller her mellom sikkerhet i meldingsbasert kommuni-kasjon ("store-and-forward") og direktekoplet kommunikasjon (ende-systemene kommuniserer direkte på applikasjonsnivå).

3. Tilkoplingssikkerhet som primært skal sikre at tilkoplingspunktet ogtilkoplingsformen hindrer innbrudd av uvedkommende fra eksterne

Figur 1Sikkerhetsmodell for

tilkopling til ellersammenkopling av

usikre nett


4

nettverk, samt sikring mot datadrevne angrep. Sikringstiltak mot data-virus o.l bør også inngå som en del av endesystemsikkerheten.

SikkerhetsarkitekturIKT-arkitektur, logisk nettarkitektur, sikkerhetsarkitektur. Dette er be-greper som benyttes på svært ulike måter av ulike aktører og i ulikesammenhenger.

I dette forprosjektet legger vi til grunn at begrepet arkitektur generelt(innen rammene av IKT-systemer) omfatter metoder og konsepter for åbeskrive (bl.a i form av "tegninger" og modeller) de strukturer og ram-mer som er tilstrekkelige og hensiktsmessige for å realisere de funksjo-ner, den sikkerheten eller det som ellers ønskes oppnådd og som er be-skrevet i ulike former for kravspesifikasjoner. Beskrivelsen skal gi etklart inntrykk av helheten, men skal likevel også gi inntrykk av hva somskal realiseres og hva resultatet blir og samtidig gi klare føringer for denfaktiske realiseringen.

2

Sikkerhetsarkitektur er i denne sammenhengen metoder og konsepter forå beskrive strukturer og rammer som er tilstrekkelige og hensiktsmessigefor å realisere informasjonssikkerheten. Kravspesifikasjonen er i dennesammenhengen den sikkerhetspolicyen som skal legges til grunn (seneste kapittel).

Sikkerhetsarkitekturer for informasjonsnett må ta utgangspunkt i beskyt-telsesbehovet til informasjonen som lagres og kommuniseres i nettet, iavgrensede virksomheter tilkoplet nettet, i avgrensede og sikrede deler avnettet eller i usikrede deler av nettet (alt avhengig av de sikkerhetspoli-cyene som er lagt til grunn).

Beskyttelsesbehovet vil som vi skal se nærmere på i neste kapittel, væreuensartet og være opphav til klassifisering av informasjon i.h.t beskyttel-sesbehov og til avgrensninger (sikkerhetsdomener) i virksomhetene ognettet ut fra hvordan informasjonen er avgrenset/utbredt , hvordan denspres og kommuniseres og de sikkerhetstiltak og -mekanismer som erlagt til grunn.

I tegningen i Figur 2 har vi gitt en beskrivelse av en virksomhet tilkopletet eksternt usikret nett. Informasjonen er klassifisert som enten {sensitivog kritisk} eller {ikke-sensitiv og ikke-kritisk} (jfr Vedlegg A). {Sensitivog kritisk} informasjon er beskyttet ved ulike sikkerhetstiltak og -mekanismer og er logisk avgrenset fra øvrige deler av virksomheten (ogmot det eksterne nettet), o.s.v.

2 Merk skillet mellom arkitektur, arkitekttegning og modell, som eksisterer i like stor grad forbygging av IKT-systemer som for husbygging.


5

Eksterne nettverkInternett

Ikke-sensitivIkke-kritisk

SensitivKritisk

Sterk autentiseringUtleveringssikring

Kryptering/signeringSikring av tjenestekvalitet

Enkelautentisering

LogisksegmenteringOffentlige

ressurser

Ikke-sensitiveressurser

Sensitiveressurser

Logisksegmentering

SikkerhetsdomenerEn sikkerhetsarkitektur vil alltid være basert på en avgrensning, en inn-deling av systemet (virksomheten, nettet) inn i forskjellige sikkerhetsdo-mener, med potensielt forskjellige sikkerhetspolicyer, for beskyttelse avinformasjon med forskjellige beskyttelsesbehov. I tillegg må en definerenår, hvordan og under hvilke betingelser informasjon kan utveksles /deles mellom forskjellige domener. Det er klart at informasjon som kre-ver en viss beskyttelse i ett domene, må være garantert minst sammebeskyttelse hvis den tilgjengeliggjøres innen et annet domene.

Domenestrukturer i denne sammenhengen har tre utgangspunkt:

• Eierskap til informasjonen, dvs. organisatorisk,

• Informasjonens sensitivitet, der det er ønskelig å ha egne domener forspesielt sensitiv informasjon,

• Anvendelsen av informasjonen, der det kan være ønskelig å ha in-formasjon som hører sammen, i samme domene.

Når det gjelder organisatoriske domener, blir øverste nivå sikkerhetsdo-mener de organisasjonene / bedriftene som skal være med. På dette nivå-et må det defineres overordnede regler for organisasjonenes informa-sjonssikkerhet, ansvaret for sikkerhetspolicy må plasseres, og organisa-sjonenes sikkerhetsorganisasjon må etableres.

Dersom problemet med informasjon med forskjellig beskyttelsesbehovskal være praktisk håndterbart, er det nødvendig å definere et forholdsvislite antall beskyttelsesklasser, og tilordne informasjon sensitivitets- ogkritikalitetsnivå i henhold til disse. Dette tilsvarer gradering / klassifise-ring av informasjonen. Tilsvarende kan tjenester i nettverk graderes /klassifiseres etter den informasjonen de tilgjengeliggjør. En kan da defi-nere rammeverk ("skjeletter av sikkerhetspolicyer") for informasjon ogtjenester relatert til forskjellige graderinger / klassifiseringer. Et hoved-prosjekt (se kapittel 4) vil typisk ha dette som et viktig punkt."

Figur 2Arkitektskisse for

informasjonssikkerhet


6

For de aller fleste organisasjoner må det defineres underdomener meddelegering av ansvar. Et underdomene kan igjen ha et organisatoriskutgangspunkt, f.eks forskjellige avdelinger eller enheter. Dette vil oftefalle sammen med anvendelsen av informasjonen, f.eks på et sykehus derdet vil være egne domener for administrasjonen og for pasientinforma-sjon, noe som både avspeiler organisasjon og anvendelse. Anvendelses-domener kan imidlertid også gå på tvers av organisatoriske domener,som f.eks en intranettløsning for hele organisasjonen, eller en ekstra-nettløsning som omfatter flere organisasjoner. Merk at fra et sikkerhets-synspunkt bør enhver informasjon defineres til å ha en og bare en eier.

Innenfor både organisatoriske og anvendelsesorienterte sikkerhets-domener trengs det en ytterligere strukturering basert på informasjonenssensitivitet og/eller kritikalitet. Sikkerhetspolicy for et domene må væresterk nok til å beskytte den mest sensitive informasjonen innen domenet,men strenge sikkerhetstiltak er dyre, og sikkerhet bør avpasses til behovetter kost/nytte vurderinger. Det er derfor ofte ønskelig å skille særligsensitiv informasjon ut i egne domener, og definere egne tiltak for be-skyttelse av denne. Det kan også være ønskelig å skille ut egne domenerfor (mer eller mindre) åpen informasjon.

Sikkerhetspolicyen for et underdomene må ta utgangspunkt i organisa-sjonens sikkerhetspolicy, og så forsterke denne etter behov. Policy for etunderdomene må være sterk nok til å beskytte den mest sensitive infor-masjonen som inngår i domenet. I tillegg må det defineres regler forhvordan informasjon kan utveksles med andre domener, både internt iegen organisasjon, og eksternt.

Mennesker, utstyr og programvare i domenerSom det går fram av avsnittet over, er informasjonen det viktigste ut-gangspunktet for domeneinndeling. Dette er imidlertid ikke tilstrekkelig.Et domene må forholde seg til alle elementer som må inkluderes i detssikkerhetspolicy, som utstyr og programvare, fysiske lokaler, menneskerog organisatoriske rutiner, jfr Figur 3 som viser noe av denne helheten.For et informasjonsnettverk som omfatter informasjon av høyst forskjel-lig sensitivitet, utgjør dette det største problemet som må løses. Utstyr /programvare og mennesker kan sies å tilhøre flere sikkerhetsdomener,med forskjellige sikkerhetspolicyer, som til og med kan være i konfliktmed hverandre.


7

sikkerhetskrav

fysisk beskyttelse

personalforvaltning

teknisk/logiskbeskyttelse

konfigurasjons-kontroll

sertifisering

driftsforvaltning

autorisering

Den enkleste løsningen på dette problemet er å kreve separat utstyr forforskjellige formål, slik at det alltid er klart for menneskene hvilket re-gelverk de er underlagt, og slik at konflikt mellom forskjellige domenerunngås. Slike løsninger brukes en del i dag, f.eks ved separate nettverkfor intern og ekstern bruk, jfr sykehus og Internett. For særlig sensitivinformasjon kan dette være nødvendig også på lang sikt, men dette er endyr (ekstra utstyr) og lite brukervennlig løsning.

En annen løsning er å bruke utstyr som er spesielt tilpasset bruk for be-handling av informasjon av varierende sensitivitet, og der systemet ga-ranterer at det ikke skal oppstå konflikt mellom forskjellige domener.Dette vil være utstyr som tilfredsstiller Datatilsynets krav til "delt EDB-system". "Compartment mode" arbeidsstasjoner

3 er i bruk f.eks i Forsva-

ret for slike formål. Problemene med en slik løsning er igjen pris (dyrtutstyr), brukervennlighet, og fleksibilitet. Endring av systemkonfigura-sjon er meget vanskelig for denne typen utstyr, spesielt ved evaluering avsikkerhetsnivået etter formelle kriterier som TCSEC

4 eller ITSEC

5 (se

nedenfor).

Det vil være en stor fordel dersom en kan klare å komme fram til ret-ningslinjer som, under visse betingelser, muliggjør bruk av noenlundestandard utstyr og programvare, eventuelt med tilleggsprogramvare. I etslikt tilfelle vil ikke systemet kunne hindre en konflikt, f.eks en lekkasje

3 Arbeidsstasjoner som håndterer både gradering (sikkerhetsmerking) og "need-to-know" (infor-masjonsmerking) etter militære mål.

4 Trusted Computer System Evaluation Criteria. Sikkerhetsmessige evalueringskriterier utgitt avUSAs forsvarsdepartement.

5 Information Technology Security Evaluation Criteria. EUs sikkerhetsmessige evalueringskrite-rier.

Figur 3Sikkerhetskrav må

dekke et vidt spekter avtiltaksområder


8

av informasjon fra et domene med høy sikkerhet til et med mindre sik-kerhet. Isteden må en basere seg på mer tiltro til menneskene. Disse vilvære underlagt sine autorisasjoner, men de vil kunne ha muligheter til ågå ut over disse autorisasjonene. Selv om systemet ikke kan hindre bru-kerne, bør det være bygget opp slik at det er mest mulig klart for bruker-ne hvilken policy de er underlagt for en gitt type informasjon, og hva deer tillatt og ikke tillatt å gjøre med denne. Feilsituasjoner skal i størstmulig grad skyldes bevisst misbruk av autorisasjoner, og i minst muliggrad uaktsom bruk. Logging av aktiviteter blir ekstra viktig i et slikt sy-stem. Et systems sikkerhetsregler, som innloggingsprosedyrer, må væredefinert i henhold til den mest sensitive informasjonen som det skal be-handle.

Det er mulig at en for stor grad av tiltro til menneskene er urealistisk,men enklere løsninger enn dedikerte systemer og spesialutstyr vil væreen stor fordel.


9

Dette kapitlet beskriver en grov skisse for hvordan prosjekterfor tilkopling til eller etablering av informasjonsnett bør til-nærme seg utfordringene ved hensiktsmessige og tilstrekkeligesikringstiltak. Vi starte med å peke på de gevinster man kanoppnå ved å etablere en nødvendig og tilstrekkelig informa-sjonssikkerhet

Kapitlet er ment som en (tekstlig) forsmak på hva en evt "Web-baserthåndbok for informasjonssikkerhet i informasjonsnett" kan inneholde ogfokusere på.

Sikkerhetstiltak gir gevinsterHvorfor skal ledelsen i virksomheter satse ressurser på informasjonssik-kerhet? I tabellen nedenfor rekapitulerer vi kort de gevinster ledelsenkan forvente å få ut av en slik investering, både m.h.t det vi kan kalle"utgift til inntekts ervervelse" � og "utgift til utgifts besparelse" �.

� Bedre forståelse for informasjonens betydning generelt oginformasjons- og kommunikasjonsteknologiens betydning spe-sielt.

� Mer motiverte brukere av IKT-systemene.

� Bedret informasjonsgrunnlag for både planlegging, styring,kvalitetssikring og "forretningsprosesser" generelt.

� Økt tiltro til informasjonsforvaltningen fra eiere, ansatte,"kunder" og allmennheten generelt.

� Bedre, mer kostnadseffektiv og mer kontinuerlig utnyttelse avIKT-systemene.

� Konkurransefortrinn.

� Forhindre økonomiske utgifter6 som følge av virksom-

hetsavbrudd eller tap av informasjon/utstyr.

6

F.eks knyttet til den betydelige ekstrainnsatsen som er nødvendig for å drive forsvarlig utentilgang til de IKT-systemer en har blitt så avhengig av.

Tilnærmingsmåte forsikrin gstiltak

Kapittel

3

T I L N Æ R M I N G S M Å T E F O R S I K R I N G S T I L T A K

10

� Forhindre tapte inntekter7 som følge av virksomhetsavbrudd

eller tap av informasjon/utstyr.

� Forhindre at informasjon om virksomheten gjøres tilgjengeligfor uautoriserte personer

� Forhindre andre negative konsekvenser som negativ media-omtale, erstatningskrav, etc.

Faktorer for en vellykket satsingErfaringer fra Norge og Europa ellers viser at følgende faktorer er sværtviktige for vellykket etablering og vedlikehold av informasjonssikkerhet:

1. Det må være etablert en god forståelse i organisasjonen generelt ogledelsen spesielt for hva som er grunnlaget for og formålet med de u-like delene av informasjonsbehandlingen i virksomheten. Det må ogsåvære en klar bevissthet om hvilke trusler og sårbarheter som er knyttettil informasjonsbehandlingen.

2. Sikkerhetspolicyer, sikkerhetsstrategier, og organiseringen av sikker-hetsarbeidet må være orientert mot og understøtte kjernevirksomhetenog føres an av personer i tilknytning til denne.

3. Det må under hele prosessen være klar og synlig støtte og deltakelsefra ledelsen.

4. Kunnskap og bevissthet om informasjonssikkerhet må effektivt ogmålrettet bibringes i første rekke til alle ledere i virksomheten og der-etter til andre ansatte.

5. Utfyllende opplæring og veiledning om gjeldende sikkerhetspolicy mågis regelmessig til alle ansatte. Veiledning må også gis utenforståendesom utfører arbeid på vegne av virksomheten.

6. Etablering av hensiktsmessige og effektive rapporteringsveier utenomorganisasjonens ordinære rapporteringsveier.

7. Regelmessig evaluering, testing og revisjon av alle strategier og tiltak.

Plan for informasjonssikkerhet (skisse)Vi vil her skissere en plan for etablering og vedlikehold av informasjons-sikkerhet generelt og knyttet til etableringen av, tilkoplingen til elleribruktaken av informasjonsnett spesielt, jfr Figur 4. Vi tar utgangspunkt ivirksomheten(e) som skal inngå i informasjonsnettet.

7

F.eks tap av kunder.


11

Hva er gjort tidligere?Kartlegg!

Sikkerhet fra dag 1

Risikofaktorer og sikkerhetsmål? Beskriv og forankre!

Hva er beskyttelsesbehovet?Beskriv og forankre!

Sikkerhetsdomener?Beskriv og forankre!

Overordnet sikkerhetspolicy

Tiltaksplan og ressurser

Systemvise sikkerhetspolicyer

Sikkerhetsorganisasjon

Fas

e 1

Fas

e 2

… organisatoriske

Iverksette tiltak..

… tekniske/logiske

… personellmessige

… fysiske

Fas

e 3

Fase 1

Prosessen med å etablere tilstrekkelig og nødvendig informasjonssikker-het må starte forut for eller fra starten av en nettetablering, gjerne organi-sert som et delprosjekt (uavhengig av faktisk organisering, omtalt som"sikkerhetsprosjektet"), men som uansett skal legge klare føringer fornettetableringen eller -bruken som helhet. Dersom det likevel foreligger

Figur 4Plan for etablering av

informasjonssikkerhet

Sikkerhet fra dag 1


12

en nettetablering der sikkerhetsprosessen ikke har vært gjennomført påen tilfredsstillende måte, må denne prosessen gjennomføres i ettertid.Erfaringer viser at det å "legge til" sikkerhet til et eksisterende systemofte er ressurskrevende og vanskelig, og gir dårligere resultat enn nårsikkerhet er tatt hensyn til helt fra planleggingsfasen.

Dersom det ikke allerede er gjennomført sikkerhetstiltak i virksomhe-ten(e) forut for nettetableringen, dokumentert i en sikkerhetspolicy, måsikkerhetsprosjektet omfatte alle deler av virksomhetens informasjonssy-stemer som berøres av nettetableringen (som i mange tilfeller utgjør helevirksomheten). Finnes det en sikkerhetspolicy og iverksatte sikkerhets-tiltak, må disse gjennomgås på nytt i samme omfang i lys av nettetable-ringen.

Første del av "sikkerhetsprosjektet" bør ha som mål å beskrive og sank-sjonere (d.v.s være forstått og akseptert av ledelsen) hva som er omfangetav og formålet med selve informasjonsbehandlingen i virksomheten ge-nerelt og i forbindelse med nettetableringen spesielt. Hva slags informa-sjon? Sensitivitet og kritikalitet til informasjon og nettjenester? (Grade-ring?) Hva er beskyttelsesbehovet?

I neste fase bør det gjøres opp en status over dagens situasjon når detgjelder sikkerhet i informasjonsbehandlingen, samt å skape en felles for-ståelse for situasjonen. Hvilke risikofaktorer (trusler og sårbarheter) kanidentifiseres (risikovurdering)? Hva er sikkerhetsmålene (tiltak veid oppmot risiki og kostnader ved tiltak)?

Ulike beskyttelsesbehov og risikofaktorer i ulike deler av nettet og/ellervirksomhetene gir opphav til ulike sikkerhetsdomener med ulike sikker-hetspolicyer, gjerne med en felles overordnet sikkerhetspolicy for infor-masjonsnettet som helhet.

Fase 2

I denne fasen er det spesielt viktig å sikre en forankring hos ledelsen, slikat en er sikker på at den nødvendige organisering og de nødvendige res-surser for å gjennomføre prosessen etableres og gjøres tilgjengelig. Meddette som grunnlag bør det settes opp en konkret tiltaksplan for det vide-re arbeidet med informasjonssikkerheten.

Neste steg bør være å dokumentere "funnene" og beslutningene i enoverordnet sikkerhetspolicy for informasjonsnettet og de berørte deleneav de tilknyttede virksomhetene. Arbeidet må koordineres med virksom-hetens evt overordnede strategier og annen relevant virksomhetsplanleg-ging. Dersom det finnes en IKT-strategi for virksomhetene, må det ogsåtas utgangspunkt i disse. Dette kan definitivt også være en anledning til åavdekke behovet for en revisjon av gjeldende IKT-strategier. Det er vik-tig at det skapes en bred aksept av og forståelse for policydokumentet;dette innebærer opplæring, bevisstgjøring og motivering, samt bruker-

Hva er gjort tidligere?

Hva erbeskyttelsesbehovet?

Risikofaktorer?Sikkerhetsmål?

Sikkerhetsdomener?

Ledelsesforankrettiltaksplan

Sikkerhetspolicy!


13

medvirkning i utarbeidingen, evt også krav om tilslutning til policyen fravirksomhetene ved tilknytning til nettet.

Dato: Utarbeidet av: Godkjent av: Versjon:13.01.97 <> <> 1.0

OVERORDNET POLICY FOR INFORMASJONSSIKKERHET

Strategiutvikling og organisering

MålMålet for sikker informasjonsbehandling ved <> er å (1):• Sikre informasjonens konfidensialitet. Konfidensialitet innebærer at informasjon ikke avdekkes (gjøres

tilgjengelig) for andre enn de som har et rettmessig behov for å lese informasjonen.• Sikre informasjonens integritet og kvalitet. Med kvalitet forstår vi at informasjonen er korrekt, relevant,

tidsriktig og komplett. Integritet innebærer også at informasjon ikke er endret eller slettet på en måte somikke er autorisert, og som reduserer kvaliteten.

• Sikre informasjonens tilgjengelighet. Med tilgjengelighet mener vi at autoriserte personer skal få tilgang tilden informasjon det er behov for, når det er nødvendig.

Definisjoner• Med informasjon menes i denne sammenheng alle typer informasjon som vedrører <>, altså både sykehus,

forskning og administrasjon, og både muntlig, skriftlig og elektronisk informasjon.• Med personidentifiserbar helseinformasjon menes informasjon om pasienter som er koblet sammen med

pasientens fulle navn og eller fødsels / personnummer.• Med anonymisert helseinformasjon menes informasjon om enkeltpasienter der disses identifikasjon er

fjernet (anonymisert).• Med pasient - uspesifikk helseinformasjon menes generell helseinformasjon av typen prosedyrer,

retningslinjer, skriftlig pasientinformasjon m.v.

AnsvarSikker informasjonsbehandling er et ledelsesansvar. Gjennom utarbeidelsen av en sikkerhetsstrategi har ledelsenen mulighet til å sette sikkerheten på dagsordenen, og gi sin støtte til arbeidet med informasjonssikkerhet iorganisasjonen (3).

SikkerhetsorganisasjonenSikkerhetsorganisasjonen skal forvalte og styre organiseringen av arbeidet med sikker informasjonsbehandling,og skal i størst mulig grad spille på og bestå av personer og ressurser som til daglig har sine gjøremål iadministrasjon, stab og kjernevirksomhet. Målet bør være å etablere en lærende organisasjon hvor sikkerinformasjonsbehandling inngår som en naturlig og sentral del av organisasjonskulturen.

Sikkerhetsorganisasjonen ved <> skal bestå av følgende roller:• Strategisk IT-ledelse (toppledelsen)• Ansvarlig for informasjonssikkerhet (Informasjonssikkerhetsansvarlig)• IT-sikkerhetsansvarlig• Kvalitetssjef• Systemeiere (Linjeledelse/avdelingsledelse)• Ansvarlig for den medisinske journal (sjefslege)• Representant fra Medisinsk bibliotek• Evt representanter for profesjons-/fagforeninger

For å sette en sikkerhetspolicy ut i livet, er det nødvendig å organiserevirksomhetene og informasjonsnettet på en måte som gjør den enkeltevirksomhet i stand til å tilegne og tilpasse seg policyen. Roller må define-res, delansvar og oppgaver må delegeres. Det bør uansett etableres ensikkerhetsorganisering som er i stand til å ivareta og utvikle informa-sjonssikkerheten, uansett om dette utgjøres av en person eller en meromfattende organisering. Ikke minst er det viktig at det skapes og "vedli-keholdes" en forståelse og delaktighet i forhold til sikkerhetstiltakene inettet/virksomhetene.

Figur 5Eksempel på (deler av)et policydokument (foren virkelig virksomhet)

Sikkerhetsorganisasjon!


14

Når den mer overordnede sikkerhetspolicyen er på plass, gjelder det å fåsatt denne ut i livet i virksomheten. Her bør det etableres systemvise sik-kerhetspolicyer for de viktigste berørte informasjonssystemene og/ellernettjenestene / -anvendelsene. Dette innebærer en konkretisering av ad-ministrative, systemtekniske og fysiske tiltak og mekanismer for de spe-sifikke IKT-systemene, ned til et relativt detaljert nivå. Hva er nødvendi-ge og tilstrekkelige tiltak på nettnivå, på applikasjonsnivå, på brukernivåo.s.v.

Etter at denne prosessen er gjennomført bør man ha oppnådd et nødven-dig grunnlag for informasjonssikkerheten, men dersom ikke policyene ogtiltakene jevnlig følges opp og revideres, vil de fort komme i utakt medendringer i nettutviklingen, informasjonsbehandlingen og/eller-teknologien.

"Sikkerhetsprosjekter" må, som nettetableringer generelt, skaleres medhensyn til ambisjonsnivå, sikkerhetsmål og tiltak. Det er derimot slik atet sikkerhetsprosjekt alltid er nødvendig å gjennomføre!

Fase 3

(Detaljerte) sikkerhetstiltak må utredes og iverksettes, både fysiske, tek-nologiske, personellmessige og administrative. Mer om dette i den fak-tiske håndboken…

Intet varer evig, ei heller den sikkerhetsmessige verdien og nytten av depolicyer og tiltak som en gang gjennomføres. Jevnlig revisjon av risiki,policyer og tiltak er derfor nødvendig. Hvordan dette kan håndteres hen-siktsmessig og dynamisk er en sentral del av en effektiv sikkerhetsorga-nisering, noe den faktiske håndboken vil beskrive i mer detaljer…

Systemvisesikkerhetspolicyer


15

Kapitlet skisserer en plan for et hovedprosjekt for utarbeidelseav en "Web-basert håndbok for informasjonssikkerhet i infor-masjonsnett". Håndboken kan være virtuell i den forstand atulike relevante miljøer selv kan legge inn informasjon om fagli-ge tema, om seg selv og sine erfaringer o.s.v, som så gjøres til-gjengelig for andre via en form for redaksjon.

Formål og formatFormålet med hovedprosjektet bør være å utarbeide en Web-basert hånd-bok/ veileder/ informasjonsbørs for informasjonssikkerhet i informa-sjonsnett. Videre bør formålet med håndboken være å gi informasjon,råd, veiledning o.a på området informasjonssikkerhet primært for demon-stratorprosjektene i NIN, men også mer generelt til aktører som planleg-ger eller er i ferd med å knytte seg til eller å etablere informasjonsnett.Ved å vektlegge at håndboken skal være Web-basert, kan en slik "hånd-bok" være løpende oppdatert m.h.t både teknologi, erfaringer, oversiktero.a som naturlig vil inngå i håndboken. Samtidig kan ulike relevanteaktører legge inn informasjon om faglige tema, om seg selv og sine erfa-ringer o.s.v via et enkelt Web-grensesnitt, for så å gjøres raskt tilgjenge-lig for andre via en form for redaksjon.

En slik håndbok og informasjonsbørs kan også være kimen til et "virtueltinstitutt for informasjonssikkerhet" som kan omfatte flere og mer omfat-tende informasjonstjenester på område, samt også direkte involvering avpersonressurser i ulike kompetansemiljøer. Dette er dog ikke vurdertinnen rammen av forprosjektet og heller ikke realitetsvurdert i denneplanskissen for hovedprosjektet.

En Web-basert "håndbok" vil i utgangspunktet bare være tilgjengelig "pånettet". Vi ønsker en "ekte" Web-bok, d.v.s at boken vil skrives for Web-aksess, og ikke bare være en papirbok som er tilgjengelig over nettet.Dette innebærer at det er usannsynlig at boken vil egne seg for en full-stendig utskrift på papir.

Samtidig er det klart at utvalgte deler av boken både kan og bør produse-res i en form som kan skrives ut, bl.a fordi det kan være tungvint å lesemye tekst på en skjerm.

Skisse av plan forhovedprosjekt

Kapittel

4

Web-basert, elektroniskinformasjonsbørs

Virtuelt institutt?

Noe på papir

S K I S S E A V P L A N F O R H O V E D P R O S J E K T

16

Håndbokens innholdViktigere enn formatet er selvfølgelig innholdet i håndboken. Håndbokenskal i større grad enn å være en lærebok, være en dokumentsamling, ensamling av relevant informasjon om temaet som er systematisk tilrette-lagt og løpende oppdatert for å gi den tilgjengelighet til problemstillinge-ne som målgruppen er opptatt av å få. En dekkende og oppdatert FAQ(Frequently asked questions) bør bygges opp som en del av håndboken.Enkle maler eller scenarier for planlegging og oppfølging av sikkerhets-opplegg, rettet mot NIN-demonstratorene, bør også inngå.

Dette innebærer at f.eks mer "standard, teknisk" sikkerhetsinformasjon iminst mulig grad skal produseres som (ny) tekst, men at det knyttes len-ker til slik informasjon i den grad den er tilgjengelig. Håndboken i segselv og produksjonen av denne vil således ha fokus på, som nevnt, sy-stematikken og pedagogikken i framstillingsformen.

Presentasjonsformen og systematikken i håndboken er tenkt lagt opp utfra (videreutviklingen av) den sikkerhetsmodell og -arkitektur, samt den"handlingsplanen" som skisseres i forprosjektet.

Sikkerhetshåndboken bør ha et innhold som dekker (minst) følgendebrukeraspekter ved informasjonsnett:

• Etablere sikker tilkopling til Internett. (Beskytte interne nett og interninformasjon ved tilkopling til eksterne nett)

• Etablere intranett og ekstranett (herunder bransjenett o.l)

• Bruke tjenester og informasjon over intranett og/eller Internett.

• Tilby tjenester og informasjon over Internett.

• Beskytte informasjon som overføres.

• Sikkerhetstjenester i nett (TTP-tjenester m.m)

Ut fra formålet over vil vi foreslå en god del fokusering på områder somikke vanligvis blir trukket fram innen informasjonssikkerhet:

• "Ingen bruk eller etablering av nett uten sikkerhetspolicy." Uansettmening om Internett og Internett-teknologiene kan gi tilstrekkelig sik-kerhet eller ikke, så er en ting sikkert: Uten en sikkerhetspolicy for sinvirksomhet kan sikkerheten aldri bli tilstrekkelig fordi en ikke har noereferansepunkt å måle sikkerhetstiltak o.l opp mot.

• Sikkerhet integrert i prosjektplanlegging fra begynnelsen av – det eren meget vanlig feil at prosjektplaner legges og systemdesign og im-plementasjon gjøres uten tanke for sikkerhet, og at en så i ettertid for-søker "å sikre" resultatet.

Ikke lærebok, menpedagogisk tilrettelagt

dokumentsamling

Brukeraspekter

Fokus i en håndbok


17

• Behovet for administrasjon og vedlikehold av sikkerhetsløsninger -f.eks må en brannmur som i utgangspunktet er vurdert som sikker nok,også bli konfigurert og vedlikeholdt på en måte som opprettholdersikkerheten i tilstrekkelig grad.

• Behovet for opplæring og motivasjon av brukerne m.h.t å ivareta sik-kerheten. Flere undersøkelser i Europa og USA dokumenterer at util-siktede hendelser utført av egne ansatte, ofte med basis i mangelfullopplæring og motivasjon, klart dominerer m.h.t sikkerhetsbrudd. Eteksempel er utilsiktet utlevering av sensitiv informasjon via vedlegg iepost.

• Forholdet til tjenestekvalitet, som spesielt er viktig for informasjonmed høy kritikalitet.

• Forholdet mellom sikkerhet, sikkerhetsorganisasjon og organisasjo-nens kvalitetsarbeid, særlig for drift og administrasjon av sikkerheten,men også for å sikre integritet og tilgjengelighet (til en viss grad ogsåkonfidensialitet) av informasjon.

• Diskusjon om fornuftige metoder for å evaluere (sertifisere, revidere)sikkerhet i en organisasjon og i et informasjonsnett.

• Krav til kompetanse for å etablere, og ikke minst vedlikeholde, sik-kerheten i en organisasjon og i et informasjonsnett.

• Tydeliggjøring av skillet mellom sikkerhetsfunksjonalitet og -tillit.

Gjennomføring av hovedprosjekt

Fase 1 Detaljplanlegging

Målet med den forberedende fasen er å detaljplanlegge gjennomføringenav hovedprosjektet. Et delmål kan være å etablere en referansegruppe(NIN-ekstern) for prosjektet.

Fase 2 Gjennomføring

Følgende delprosjekter bør gjennomføres:

1. Innholdsutvikling og -oppdatering. Utvikling av nytt innhold ogidentifisering av "eksterne" kilder som kan knyttes opp. Løpendeoppdatering av innhold i prosjektets levetid.

2. Web-tilrettelegging. Strukturering og tilrettelegging av innhold, pro-duksjon av Web-sider.

3. Brukerkontakt og -tjenester. Etablere kontakt mot aktører (både NIN-prosjekter og andre aktører) som kan bidra med informasjonsinnhold,enten nytt (f.eks beskrivelse av seg selv og sine tjenester og erfarin-


18

ger) eller via lenker. Løpende "brukerevaluering" av innhold og pre-sentasjonsform som utvikles. Under dette delprosjektet er det ogsåmulig å yte kvalitetssikringstjenester overfor de ulike NIN-prosjektene (ut over det som er gjort i dette forprosjektet) m.h.t pla-ner for og evt iverksetting av sikkerhetstiltak i prosjektene

Tid og ressurser

Hovedprosjektet bør iverksettes så snart som mulig, realistisk i løpet avmai måned. Det bør løpe ut 1999. Detaljplanleggingen bør være gjen-nomført innen utgangen av juni 1998. En første "offisiell" prøveversjonbør foreligge innen utgangen av 1998.

Prosjektet bør etableres med en rimelig bredt sammensatt prosjektgrup-pen, evt bestående av en mindre, mer "hardtarbeidende" kjerne. Breddenvil sikre bredden også i innholdet, mens kjernen vil sikre tilstrekkeligfokusering og framdrift.

Kostnadene knyttet til de ulike aktivitetene er ikke forsøkt beregnet idette forprosjektet. Foruten NFR, bør finansiering også kunne søkes hosandre interessenter, f.eks Forvaltningsnettprosjektet, OilHUB.

N O E N S E N T R A L E B E G R E P E R

19

I dette vedlegget definerer vi en del sentrale begreper som erlagt til grunn i forprosjektrapporten. Dette vedlegget er tenkt ådanne basisen i en "definisjonskatalog" for informasjonssik-kerhet som bør være en del av den håndboken som foran i rap-porten foreslås utarbeidet. Således er ikke listen over begreperment å være uttømmende i denne omgang. Merk at formåletikke er "universell" konsensus om begrepene, men at vi i detminste bør kunne komme fram til en anbefaling og enighet in-nen rammene av NIN/ININ.

Vi vil i vår lille vandring i begrepsavklaringenes navn ta utgangspunkt iinformasjonen og informasjonssystemene som skal beskyttes, og dervedogså ta utgangspunkt i begrepet informasjonssikkerhet. Videre er be-grepene trukket fram i en rekkefølge som er noenlunde konform med dentilnærmingsmåten som i kapittel 4 ble anbefalt for realisering av informa-sjonssikkerhet i informasjonsnett.

Informasjonssikkerhet (information security): totaliteten av or-ganisatoriske tiltak og tekniske mekanismer som sikrer informa-sjonens og informasjonssystemenes konfidensialitet, integritet,tilgjengelighet og sporbarhet i henhold til gjeldende informasjons-sikkerhetspolicy.

Konfidensialitet (confidentiality): det at (sensitiv) informasjonikke avdekkes overfor uvedkommende entiteter

8 på en uautorisert

måte.

Integritet (integrity): det at informasjon er ekte, korrekt og opp-datert og ikke lagt til, endret eller slettet på en uautorisert måte.(Innenfor integritet kan vi også definere autentisitet: det at infor-masjon er ekte, d.v.s ikke er endret eller lagt til på en uautorisertmåte. Vi vil derimot ikke benytte dette begrepet.)

Tilgjengelighet (availability): det at informasjon er tilgjengeligfor autoriserte entiteter når og der det er behov for det.

Sporbarhet (accountability): det at alle sikkerhetsrelaterte hen-delser i informasjonssystemet i ettertid kan oppdages og knyttes

8 Brukere, prosesser, programmer o.l

Vedlegg

ANoen sentralebegreper


20

til en bestemt entitet og til den informasjon som er involvert ihendelsen.

Konfidensialitet, integritet, tilgjengelighet og sporbarhet forkortes KITS idet følgende.

Autorisasjon (authorisation): det at en entitet har gitte rettigheter(privilegier) i forhold til en avgrenset mengde informasjon ellerdeler av et informasjonssystem.

Rettigheter (privileges): omfatter rett (tillatelse) til å lese, skrive,opprette, endre og slette informasjon, samt å utføre gitte handlin-ger i informasjonssystemet, som potensielt kan føre til sikkerhets-brudd for KITS.

Informasjonssikkerhet er primært, men ikke entydig knyttet til in-fostrukturnivået i referansemodellen. På nivået over (Anvendelser) vil vilikevel benytte begreper som er knyttet til hvorfor informasjon skal sik-res: Sikker informasjonsbehandling (secure information management),personvern (privacy), rettssikkerhet (legal protection), forretningssik-kerhet (business process security).

Når det gjelder nivået under infostrukturnivået (Teknisk infrastruktur) erdet igjen andre begreper som bør benyttes, da knyttet primært til de tek-nologiske aspektene ved informasjonssikkerhet: IT-sikkerhet (IT secu-rity), klient-tjener-sikkerhet (client-server security), databasesikker-het (database security), kommunikasjonssikkerhet (communicationsecurity) etc.

IT-sikkerhet : totaliteten av organisatoriske tiltak og tekniske mekanis-mer som sikrer at IT-systemene understøtter informasjonssikkerhetensom definert i gjeldende informasjonssikkerhetspolicy. IT-sikkerhet inn-befatter også Systemintegritet: det at et IT-system (maskin- og pro-gramvare m.m) virker som spesifisert, og uten utilsiktede sikkerhetsmes-sige bivirkninger.

Merk at vi unngår begrepet "datasikkerhet" som vi anser som synonymtmed IT-sikkerhet.

"Hos oss er informasjonssikkerheten tilstrekkelig ivaretatt". Informa-sjonssikkerhet benyttes i dagligtale ofte som et tilstandsbegrep. Selv omdette ikke er helt i tråd med vår definisjon, ser vi ikke noe i veien for enslik bruk av begrepet, dersom vi presiserer at dette må fortolkes som at"de tekniske og organisatoriske tiltak og mekanismer som er iverksattanses som tilstrekkelige i forhold til å ivareta gjeldende sikkerhetspolicy

9

(som også omfatter gjeldende lover og regler).

9 Når vi i det følgende skriver kun "sikkerhet…", er dette alltid i betydningen "informasjons-sikkerhet…".


21

Sikkerhetspolicy (security policy): en dokumentert og av virk-somhetens ledelse sanksjonert beskrivelse av mål, retningslinjer,prosedyrer, oppgaver og ansvar for hvordan informa-sjonssikkerheten skal etableres og vedlikeholdes i hele eller av-grensede deler av virksomheten.

For å kunne etablere en sikkerhetspolicy må virksomheten ha en forme-ning om "verdien" av den informasjonen som virksomheten behandler,lagrer og kommuniserer. I sammenheng med en slik "verdisetting", kaninformasjonen skilles i ulike kategorier avhengig av informasjonens sen-sitivitet og kritikalitet .

Sensitivitet (sensitivity): egenskap ved informasjon, definert aven kompetent autoritet, knyttet til i hvor stor grad sikkerhetsbruddi forhold til konfidensialitet og integritet kan føre til skade for denperson eller virksomhet informasjonen omhandler eller eies av.

Kritikalitet (criticality): egenskap ved informasjon, definert av enkompetent autoritet, knyttet til i hvor stor grad sikkerhetsbrudd iforhold til integritet og tilgjengelighet kan føre til skade for denperson eller virksomhet informasjonen omhandler eller eies av.

Sikkerhetsbrudd (security breach): realisering av trusler som haren virkning i form av at KITS ikke er ivaretatt i henhold til gjel-dende sikkerhetspolicy.

Informasjonen kan videre graderes ut fra potensielt skadeomfang vedsikkerhetsbrudd i forhold til KITS: F.eks kan informasjon graderes Sen-sitiv, ikke-sensitiv, kritisk og ikke-kritisk. Informasjon kan være bådesensitiv og kritisk. Forsvaret opererer med egne graderinger m.h.t sensi-tivitet, jfr Sikkerhets- og beskyttelsesinstruksene.

Merk at sensitivitet og kritikalitet er både tids- og kontekstavhengigestørrelser. To informasjonselementer som hver for seg verken er sensitiveeller kritiske, kan satt sammen (aggregert) være både sensitiv og kritisk,f.eks "Identitet" og "Blodsmitte" versus "Identitet; Blodsmitte".

I definisjonen av sikkerhetspolicy er det angitt at policyen er avgrenset("… hvordan informasjonssikkerhet skal etableres og vedlikeholdes ihele eller avgrensede deler av virksomheten"). Denne avgrensningen avvirkeområdet til en sikkerhetspolicy kalles et sikkerhetsdomene.

Sikkerhetsdomene (security domain): en logisk, organisatoriskeller fysisk avgrensning som er omfattet av en og samme sikker-hetspolicy, og som utgjør en uniform og konsistent avgrensning utfra informasjonens beskyttelsesbehov i forhold til KITS, og somer underlagt en og samme sikkerhetsautoritet.

Sikkerhetsautoritet (security authority): person eller gruppe avpersoner som har ansvar for definisjon, innføring og vedlikeholdav en sikkerhetspolicy for et sikkerhetsdomene.


22

Gradering av informasjon avstedkommer et beskyttelsesbehov for infor-masjon og informasjonssystemene. Beskyttelsesbehovet defineres gjen-nom en risikovurdering (-analyse) og beskrives ut fra tiltak og meka-nismer som skal iverksettes for å sikre informasjon og informasjonssy-stemer.

Risikovurdering (risk assessment): en systematisk gjennomgangav virksomhetens informasjon og informasjonssystemer med siktepå å få dokumentert trusler, sårbarheter og virkninger i forhold tilsikkerhetsbrudd.

Risiko (risk): muligheten for at en eller flere trusler eksisterersom kan utnytte sårbarheter i virksomhetens informasjonssyste-mer.

Trussel (threat): en potensiell hendelse som dersom den opptrerkan føre til sikkerhetsbrudd og derved mulig skade.

Sårbarhet (vulnerability): svakheter ved virksomhetens informa-sjonssystemer og de fysiske og organisatoriske omgivelsene tildisse som kan føre til at trusler kan realiseres med høyere sann-synlighet eller med større virkning enn om svakhetene ikke var tilstede.

Sikkerhetsbrudd knyttet til informasjonens sensitivitet og kritikalitetomfatter:

Avdekking (disclosure): uautorisert tilgjengeliggjøring (i tolk-bar/forståelig form) av sensitiv informasjon.

Kompromittering (compromise): uautorisert endring eller slet-ting av sensitiv og/eller kritisk informasjon.

Tilgangssperring (denial of service): uautorisert hindring av til-gang til kritisk informasjon eller av utførelsen av tidskritiske ope-rasjoner.

Til vurdering av skadeomfang må det også knyttes et verdimål for senereå kunne vurdere hvor store kostnader som kan eller bør knyttes til muligetiltak og mekanismer.

Tiltak og mekanismer kan ses i forhold til to dimensjoner, virkning oganvendelsesområde. I forhold til virkning, kan sikkerhetstiltak og-mekanismer være forebyggende (fjerne trusler eller redusere sannsyn-ligheten for realisering av trusler), avskjærende (hindre at realisertetrusler fører til skadevirkninger) og/eller opprettende (reparerer virknin-gene slik at skade ikke oppstår). I forhold til anvendelsesområde, kansikkerhetstiltak og -mekanismer være fysiske, logiske (systemtekniske)eller administrative (organisatoriske, personellmessige).

Logisk sikkerhetstiltak omfatter:


23

Autentisering (authentication): det å verifisere påstått identitet(brukeridentitet, meldingsopphav o.l) til en entitet.

Tilgangskontroll (access control): det å sikre at kun autoriserteentiteter kan få tilgang til ressurser (informasjon, programmer,operasjoner o.l) i et informasjonssystem.

Når tiltak og mekanismer skal implementeres og iverksettes, skilles detmellom sikkerhetsmessig funksjonalitet og tillit.

(Sikkerhetsmessig) funksjonalitet (security functionality): orga-niseringen, struktureringen og virkningen av iverksatte tiltak ogmekanismer.

(Sikkerhetsmessig) tillit (security assurance): mål for a) funksjo-nalitetens hensiktsmessighet/egnethet i forhold til de sikkerhets-mål som er definert for de ulike funksjonene og b) funksjonalite-tens korrekthet i forhold til gitte krav eller spesifikasjoner.


24

Det videre arbeid med informasjonssikkerhet i informasjons-nett innen rammene av NIN bør ha et bredest mulig grunnlag.Forprosjektet har derfor gjennomført en summarisk kartleg-ging av norske miljøer med formelle roller eller relevant kom-petanse og erfaring innen temaet. Kartleggingen er ikke ment åvære uttømmende, men kan være utgangspunktet for en merdekkende og løpende oppdatert "informasjonsbørs" på detteområdet, som en del av den Web-baserte håndboken som fore-slås utarbeidet i et evt hovedprosjekt (se kapittel 5). Informa-sjonsbørsen kan med fordel også omfatte informasjon om rele-vante prosjekter, standardiseringsaktiviteter, regelverk o.s.v.

KompetansemiljøerOversikten er i denne omgang summarisk og inneholder ikke beskrivel-ser av de ulike aktørene, annet enn eksempelvis for Forskningsinstitutte-ne o.l. I en evt Web-basert håndbok kan aktører som ønsker å være med ien slik oversikt, selv inviteres til å bringe fram beskrivelse av sin virk-somhet relatert til informasjonssikkerhet og evt lenker til egne Web-sider.

Forskningsinstitutter o.l

SINTEF; Kryptografi, generell informasjonssikkerhet

Norsk regnesentral; Generell informasjonssikkerhet, sikker elektroniskhandel, TTP-tjenester

Telenor FOU; Sikkerhetstjenester i nett, kryptografi, generell informa-sjonssikkerhet

NTNU, Inst for telematikk; Evalueringskriterier, standardisering, under-visning

Sikkerhetsevaluering o.l

Systemsikkerhet as

Berdal-Strømme as

Norske kompetanse-miljøer

Vedlegg

B

N O R S K E K O M P E T A N S E M I L J Ø E R

25

Faglige interesseorganisasjoner o.l

Næringslivets sikkerhetsorganisasjon

Den norske dataforening (DND), faggruppe for informasjonssikkerhet

IT-sikkerhetsforum (ISF)

Norsk kryptoforum

Forvaltningsorganer o.l

Datatilsynet

Forsvarets overkommando / Sikkerhetsstaben (FO/S)

Kredittilsynet

Post- og teletilsynet

Statsministerens kontor

Statskonsult

Nærings- og handelsdepartementet

Arbeids- og administrasjonsdepartementet

Statens forvaltningstjeneste

Relevante fagdepartementer med ansvar på egne regelområder

Rådet for IT-sikkerhet

Standardiseringsorganisasjoner o.l

Bankenes standardiseringskontor

Norsk EDIPRO

Norsk teknologistandardisering (NTS)

TTP-tjenesteleverandører m.m

Telenor

Posten SDS

UNINETT

Andre

Norges bank

Bankenes betalingssentral

N O R S K E K O M P E T A N S E M I L J Ø E R

26

Fellesdata

Norsk Hydro

Statoil

Alcatel Telecom Norway

Kongsberg Informasjonskontroll

Kompetansesenter for IT i helsevesenet as (KITH)

Leverandører

Ingen nevnt, ingen glemt?


27

Som et eksempel på tekst som kan inngå i håndboken tar vimed noe om signering og kryptering av informasjon som skallagres på eller overføres over usikre medier. Teksten er hentetfra en KITH-rapport.

SigneringVi vil først minne om noen av den tradisjonelle, håndskrevne signaturensfunksjoner som også må legges til grunn for den digitale signaturen

10:

• Identifiseringsfunksjon som innebærer at signaturen knytter doku-mentet og innholdet til den personen som signerer.

• Bevisfunksjon som innebærer at dokumenter i rettssaker blir benyttetsom bevis for ett eller annet. Det faktum at det foreligger et dokumentmed en signatur som kan knyttes til en bestemt person kan være ut-slagsgivende i den enkelte sak.

• Integritetsfunksjon som innebærer at dokumentets innhold virkelig erdet som vedkommendes signatur er ment å være knyttet til.

• Avslutningsfunksjon som innebærer at en signatur tilkjennegir en av-slutning av en prosess som f.eks en medisinsk vurdering av en pasi-ents behov for medikamenter og etterfølgende utfylling av en resept.

• Kompetansefunksjon som innebærer at vedkommende som har signerthar myndighet til å foreta en handling eller treffe beslutninger som blir"bindende" for en eller flere personer (altså ikke nødvendigvis et ut-trykk for dyktighet).

Det synes i utgangspunktet klart at en digital signatur på et elektroniskdokument (herunder en EDI-melding eller et formelt e-postdokument)kan ivareta de funksjoner som er beskrevet for den tradisjonelle, hånd-skrevne signaturen. Dette er likevel ikke det sentrale spørsmålet. Detsentrale spørsmålet er å etablere tillit overfor brukere, normgivere og isiste instans rettsapparatet og domstolene til at funksjonene er ivaretatt.

10

Jfr rapporten "Meldingssikkerhet – Tiltrodde tredjeparter og digitale signaturer, Del II Rettsligeaspekter" fra Norsk EDIPRO, 7.12.94.

Litt om signering ogkrypterin g

Vedlegg

C

Den tradisjonellesignaturens funksjoner

28

Her vil konsensus, normer og standarder være av en helt sentral betyd-ning for å etablere denne tilliten.

De samme funksjoner som er beskrevet for den tradisjonelle signaturen,kan antakelig ivaretas av andre tekniske foranstaltninger i IT- og kom-munikasjonssystemene. Vi er derimot av den klare oppfatning at dendigitale signaturen i stor grad forenkler arbeidet med å etablere tillitgjennom konsensus, normkrav og standarder. Vi mener å finne betydeligstøtte i dette i de mange juridiske betenkninger og de mange tekniskestandarder som i dag foreligger både i Norge og ellers i Europa, m.h.tdigitale signaturer. Vi vil derfor legge til grunn at digitale signaturerbenyttes for å ivareta de beskrevne funksjoner ved elektronisk dokument-og meldingskommunikasjon i helsesektoren. Vi vil likevel utdype pro-blemstillingen noe.

Som vi vil se under, innebærer utveksling av elektronisk informasjonhvor de signaturfunksjonene som er beskrevet over skal ivaretas, mer ennå ha tillit til den digitale signaturen på den elektroniske meldingen somutveksles. For et papirdokument nedfelles informasjonsinnholdet og sig-neres det på et fysisk objekt som går (mer eller mindre) fysisk uforandretfra avsender til mottaker og som fortsatt er samme fysiske objekt nårmottaker (eller senere en dommer) fortolker innholdet. I en elektronisksammenheng er situasjonen en annen, samme funksjon kan bare oppnåsgjennom en rekke steg i en "signaturprosess" som involverer avsender,mottaker og flere ulike tekniske funksjoner i mellom disse.

Denne prosessen starter med at avsender i sitt endesystem registrerer noesom samlet sett representerer en samlet og avgrenset mengde informa-sjon (informasjonsobjekt) som skal signeres og sendes en gitt mottaker.Brukeren vil forholde seg til den visuelle presentasjonen av dette infor-masjonsobjektet når det genereres og en "signaturhandling" utføres.Dette visuelle informasjonsobjektet, via ulike tekniske prosesser, omfor-mes til en elektronisk dokument eller melding, som påføres den digitalesignaturen. (Merk at en digital signatur krever at en melding digitalt måvære oversendt til mottaker uforandret – ned til hvert enkelt digitale sif-fer og den innbyrdes rekkefølgen i disse – for at en verifikasjon av sig-naturen skal være vellykket.) Meldingen krypteres, pakkes inn i et ut-vekslingsformat og oversendes mottaker. Mottaker pakker (den krypter-te) meldingen ut, dekrypterer og verifiserer signaturen. Informasjonen imeldingen overføres deretter til mottakers endesystem (som et nytt in-formasjonsobjekt) før kjeden avsluttes med mottakers aksept av det visu-elle informasjonsobjektet generert av mottakers endesystem.

Et basis brukerkrav ved (digital) signering er ut fra dette at brukeren måha tillit til at hun er innforstått med og kjenner innholdet og omfanget avden informasjonen som faktisk signeres. For å oppnå dette er det nød-vendig å etablere en tillitskjede knyttet til den signatur- og informasjons-utvekslingsprosessen som ble beskrevet over.

Signaturprosess

29

I noen tilfeller vil en slik tillitskjede forutsette at en bruker tar et person-lig ansvar for det faktiske innholdet i et elektronisk dokument, f.eks enEDI melding. Et relevant krav til signaturprosessen i avsenders endesy-stem kan i et slikt tilfelle (populært) formuleres som: Det jeg ser er detjeg signerer! Et tilsvarende krav knyttet til mottaker endesystemet ertilsvarende Det jeg ser er det som ble signert!

Disse kravene må igjen avlede krav til avsendersystemets funksjonalitetog (tekniske) tillit når det gjelder koplingen mellom det som faktisk sig-neres og det som brukeren ser foran seg på skjermen (og tilsvarende tilmottakersystemet). Krav til den digitale signaturen må ivareta tilliten idet mellomliggende kommunikasjonssystemet (m.h.t signaturfunksjone-ne beskrevet over). Den implementerte løsningen må sørge for tilstrekke-lig høy tillit til at disse kravene etterleves og samtidig sikre brukervenn-lig funksjonalitet.

Man kan også tenke seg tilfeller der en digital signatur mer eller mindreautomatisk påføres en utgående melding, med kun den hensikt å tilkjen-negi at innholdet i meldingen, f.eks et laboratoriesvar, er kvalitetssikreti.h.t virksomhetens rutiner. Kravene til signeringsprosedyren vil i et slikttilfelle være mindre omfattende, samtidig som at signaturens faktiskebetydning blir mer avhengig av andre deler av tillitskjeden (f.eks kvali-tetssystemet).

En viktig moment som etter vår mening understøtter denne "oppdelin-gen" og herunder bruken av digitale signaturer, er følgende: En ting er aten sluttbruker kan etablere høy tillit til at sitt lokale endesystem i alleledd ivaretar signaturprosessen. Det vil derimot være vanskeligere å for-utsette eller kreve at samme bruker skal ha (eller vil kunne få) sammehøye tillit til endesystemet i "andre enden" eller til kommunikasjonssy-stemet i mellom. Dette er et viktig aspekt å ha i mente videre når sikker-hetsmodellen formuleres.

I signaturfunksjonene over ligger det innebygd grunnleggende risikovur-deringer knyttet til trusler mot og konsekvenser av at funksjonene ikkeblir ivaretatt. F.eks at en forfalsket signatur kan påføre skade på ved-kommende som enten har mottatt dokumentet eller framstår som påståttunderskriver. Et annet eksempel er at en som utfyller og signerer en re-sept ikke er en lege, med mulig skade for pasienten.

Når vi senere skal diskutere funksjonalitet og tillit i.f.m utformingen avveiledningen, må disse underliggende risikovurderingene konkretiseresog utfylles med mer detaljerte risikovurderinger i.f.m de ulike ledd i til-litsskjeden beskrevet over. Disse risikovurderingene vil legitimere kra-vene som angis, ikke minst grad av tillit som skal kreves (hva er tilstrek-kelig høy tillit?), noe som har direkte konsekvenser både i forhold til(også) viktige, men ikke direkte sikkerhetsrelaterte aspekter som bruker-vennlighet og kostnader.

Det jeg ser erdet jeg signerer!

Risikovurderinger

30

KrypteringNår det gjelder krypteringens funksjon er den i utgangspunktet enklere åbeskrive og behandle. Primært er krypteringens funksjon å sikre konfi-densialiteten til (den sensitive) informasjonen som kommuniseres. I detteligger det en risikovurdering i forhold til muligheten for uvedkommendeskal få tilgang til informasjonen, og den mulige skade på den personeninformasjonen omhandler dersom dette skulle skje.

(Merk dog at kryptering ikke tjener noen større hensikt om sensitiv in-formasjon overføres kryptert til en mottaker som kan dekryptere infor-masjonen, men som ikke er autorisert til å behandle den sensitive infor-masjonen. Dette er forhold som tilgangskontrollmekanismene i det av-sendende systemet må håndtere, i den grad det ikke blir overlatt til bru-kerne å avgjøre dette.)

I vurderingene av mulighetene for at uvedkommende skal få tilgang tilsensitiv informasjon, er det naturlig å se på hvor informasjonen befinnerog "beveger" seg og mulighetene for å utøve kontroll hvem som får til-gang de ulike steder. Vi setter her sette avgrensninger på fem "nivåer"(som også er relevante for de andre sikkerhetsmessige faktorene sombeskrives over og under konfidensialitet):

1. Avgrensning innen et EDB-system (f.eks et pasientjournalsystem)11

2. Avgrensning innen et "sensitivt" domene innen en virksomhet

3. Avgrensning innen en virksomhet (innen "husets fire vegger")

4. Avgrensning innen et åpent, eksternt nettverk – d.v.s essensielt ingenavgrensning.

Vi skal ikke gå i dybden på disse aspektene her, men legge til grunn atnår det gjelder normer for kryptering, vil vi sette et skille mellom 3 og 4Informasjon "utenfor husets fire vegger" skal krypteres

12. Informasjon

innen husets fire vegger bør ikke krypteres.

Det siste er mer pragmatisk begrunnet i andre sentrale sikkerhetsaspek-ter, nemlig fysisk og logisk kontroll og tilgjengelighet. Vi vil ikke disku-tere dette videre her, da det ikke er direkte relevant for hva vi formulerernedenfor. Vi vil likevel si at kryptering av f.eks interne databaser o.l medf.eks pasientjournaler ut fra dagens teknologi er forbundet med betydeligrisiko for at data kan bli utilgjengelig eller tapes p.g.a (uopprettelige) feilsom gjør dekryptering (og derved tilgjengeliggjøring) vanskelig ellerumulig.

11

Merk at selv her har ikke hvem som helst uten videre rett til tilgang til hvilke som helst sensiti-ve opplysninger. "Need-to-know" råder!

12 Med mulige unntak for f.eks faste linjer mellom to virksomheter (av typen 3).

Sikring avkonfidensialitet

Avgrensninger i forholdtil informasjonsflyt

31

Signerings- og krypteringsnøklerTillit til digitale signaturer og kryptering er sterkt avhengig av tillit til atde kryptografiske nøkler som benyttes i disse tekniske prosessene, blirhåndtert og utvekslet på en "sikker måte", d.v.s ikke representerer åpen-bare svake ledd i den totale tillitsskjede.

Vi anser dette for å være tilstrekkelig vurdert, kjent og anerkjent, så viskal ikke utbrodere dette sikkerhetsaspektet videre. Vi vil likevel kommetilbake til dette aspektet i tilknytning til aspekter som nøkkelsertifikaterog smartkortbasert versus programvarebasert sikring av private, hemme-lige kryptografiske nøkler m.m.

Sikring mot utilsiktet utlevering, innbrudd ogangrepDe siste sikkerhetsaspektene vi anser som relevante i forhold til Veiled-ningen, er knyttet til at en tilkopling til et eksternt nettverk (for å realise-re den ønskede meldingskommunikasjonen) medfører

1. risiko for at sensitiv informasjon utilsiktet kan utleveres/utsendes tileksterne, uvedkommende (i strid med taushetspliktsregler),

2. risiko for at eksterne, uvedkommende kan "bryte" seg inn i en virk-somhets interne nettverk og EDB-systemer, og

3. risiko for at data som "importeres" inn i virksomhetens nettverk ogEDB-systemer bringer med seg "ondsinnet programvare" som f.eksdatavirus, makrovirus og "trojanske hester". (Såkalte datadrevne an-grep.)

I forhold til 1, vil EDI gjennom kravene underlegges et hensiktsmessig13,

naturlig og implisitt kontrollregime med hensyn til at kommunikasjonener knyttet til / integrert med lokale kommunikasjons- og endesystemersom

�� skal sikre at kun autoriserte brukere får tilgang å kommunisere,

�� at evt mottakere er autoriserte (ikke er uvedkommende) og

�� at kommunikasjonen er saklig og legitim, d.v.s er knyttet til formelleog legale prosesser i.f.m pasientbehandling el.l.

�� at meldingen transporteres på en sikker måte (f.eks kryptert).

I forhold til 2, vil selve tilkoplingspunktet og tilkoplingsformen til deteksterne nettverket underlegges et hensiktsmessig kontrollregime.

13

I forhold til å etablere tilstrekkelig/akseptabelt tillits- og risikonivå.

32

I forhold til 3, som er det minst "forutsigbare" aspektet, må det primærtetableres et kontrollregime som omfatter utvikleres, leverandørers ogbrukeres løpende vurdering av risikoen knyttet til dette aspektet og evtiverksetting av nødvendige, bevisst vurderte og dokumenterte, mottiltak.

Documents

Håndbok for informasjonssikkerhet i informasjonsnett dokumenter/KITH...NFR-ININ-S ISBN 82-7846-048-5 Dato 18.05.1998 Antall sider 35 Kvalitetssikret av Hans Jørgen Varfjell Gradering