Veiledning i informasjonssikkerhet ved elektronisk datautveksling (EDI) i helsesektoren

Transkript

1 Veiledning i informasjonssikkerhet ved elektronisk datautveksling (EDI) i helsesektoren 17/3-98 Versjon 1.0 KITH Rapport 5/98 ISBN

2 KITH-rapport Tittel Veiledning i informasjonssikkerhet ved elektronisk datautveksling (EDI) i helsesektoren Forfatter(e) Tor Olav Grøtan Bjarte Aksnes Kenneth R. Iversen Oppdragsgiver(e) Sosial- og helsedepartementet Rapportnummer 5/98 ISBN Godkjent av Kenneth R. Iversen Direktør (konst.) Sammendrag URL ( veiledn_sikker_edi.pdf Dato Antall sider 34 K I T H Kompetansesenter for IT i helsevesenet as Postadresse Sukkerhuset 7005 TRONDHEIM Besøksadresse Sverresgate 15 Telefon Telefaks Epost firmapost@kith.no Foretaksnummer Prosjektnummer Gradering Høringsdokument Vedlegg A til denne rapporten inneholder et forslag til Veiledning i informasjonssikkerhet ved elektroniske datautveksling (EDI) i helsesektoren, som oppfølging av Datatilsynets Retningslinjer for informasjonssikkerhet ved behandling av personopplysninger. Utkastet er fremkommet gjennom et samarbeid mellom Sosial- og helsedepartementet, Statens helsetilsyn, Datatilsynet og KITH, og representerer således en konsensus mellom disse parter, som et utgangspunkt for gjennomføring av en høring av utkastet. Selve rapporten må leses som en bakgrunn for og introduksjon til anbefalingene i selve Veiledningen og står i utgangspunktet for KITHs egen regning, selv om samarbeidspartnere (nevnt ovenfor) har kommet med innspill og synspunkter i utarbeidelsen av denne.

3 Forord Denne rapportens Vedlegg A inneholder Versjon 1.0 av forslag til Veiledning i informajsonssikkerhet ved elektronisk datautveksling (EDI) i helsesektoren. Veiledningen er en anbefalt metode for å oppfylle Datatilsynets Retningslinjer for Informasjonssikkerhet ved behandling av personopplysninger på i det tilfelle at helseinstitusjoner ønsker å kommunisere via EDI. Veiledningen er utarbeidet i samarbeid med Sosial- og helsedepartementet, Statens helsetilsyn og Datatilsynet, og det er intensjonen at Datatilsynet skal kunne legge Veiledningen til grunn for vurdering av søknader fra helseinstitusjoner om dispensasjon til å bruke EDI ved utveksling av sensitive personopplysninger. Veiledningen representerer en anbefalt måte å oppfylle Retningslinjer for informasjonssikkerhet på. Intensjonen er å forenkle Datatilsynets saksbehandling ved vurdering og godkjenning av enkeltsaker på dette området. Det er tatt hensyn til relevante sikkerhetsmessige vurderinger og spesifikasjoner som allerede er utarbeidet i forkant av dette arbeidet. Selve rapporten er utarbeidet av KITH v/tor Olav Grøtan, Kenneth R. Iversen og Bjarte Aksnes. Veiledningen (Vedlegg A) er utarbeidet i samarbeid mellom KITH, Datatilsynet, Sosial- og helsedepartementet og Statens helsetilsyn.

4 Innhold INNLEDNING...1 Hovedprinsipper 1 EDI vs formell epost 2 Behov for fleksibilitet 2 OVERORDNET SIKKERHETSMODELL...4 Signering 4 Kryptering 7 Signerings- og krypteringsnøkler 7 Sikring mot utilsiktet utlevering, innbrudd og angrep 8 Sikkerhetsmodellen 9 UTDYPNING AV SIKKERHETSMODELLEN...11 Funksjonell modell 11 Anvendelse av sikkerhetsmodellen 14 Tillitsmessige krav 15 VEILEDNING : EDI I HELSESEKTOREN...18 Definisjoner 18 Formål 18 Ansvar 18 Sikkerhetsmål 19 Sikkerhetsstrategi 19 Personopplysninger 20 Risikoanalyse 20 Egenkontroll 20 Ledelsens gjennomgang 21 Organisasjon 21 Konfigurasjon 22 Konfigurasjonskontroll 22 Konfigurasjonsendring 22 Administrative og tekniske rutiner 22 Beredskapsplanlegging 22 Personnell 22 Planlegging mht utilsiktet avbrudd 22 Sikkerhetskopiering 23 Avviksbehandling 23 Partnere og leverandører 23 Personellsikkerhet 24 Kompetansekrav 24 Fysisk sikkerhet 24 Systemteknisk sikkerhet 24 Tilgangskontroll 24 Dataoverføring 24 Ødeleggende program 26 Registreringer 26 MELDINGSPROFIL : LABORATORIESVAR...27 Funksjonskrav 27 Tillitskrav 28

5 VEILEDNING: EDI I HELSESEKTOREN Innledning Kapittel 1 Hovedprinsipper Sett fra Datatilsynets side, er hensikten med en veiledning som denne å muliggjøre tilstrekkelig helsefaglig funksjonalitet, samtidig som Datatilsynets krav om informasjonssikkerhet tilfredsstilles. Det er viktig å merke seg at Datatilsynets sikkerhetskrav må oppfylles før helseinstitusjonen kan benytte seg av EDI som omfatter sensitive personopplysninger. Disse kravene fremkommer i Retningslinjer for informasjonssikkerhet ved behandling av personopplysninger. Dette perspektivet på veiledningen kan suppleres med at begrepet helsefaglig funksjonalitet også rommer mange helsefaglig motiverte sikkerhetskrav, som f.eks krav til meldingsinnhold, signeringsprosedyrer, sertifiseringer av avsender/mottaker, etc. Utarbeidelse av en slik veiledning innebærer en vanskelig balansering mellom behovet for en konkret løsningsmåte som kan være til hjelp for brukerne, og en beskrivelse som er generell nok til at den tar høyde for en viss endring i behov og teknologi og ikke utgjør en effektiv blokkering av nødvendig teknologisk utvikling. Som grunnlag for å finne et hensiktsmessig balansepunkt er det derfor å forutsette at veiledningens anvendbarhet kontinuerlig etterprøves og at den oppgraderes når endringer i anvendelse, trusler og teknologi gjør dette nødvendig. Det er også verdt å merke seg at den enkelte virksomhet ved implementering av anbefalingene må konkretisere disse i form av egne rutiner og tekniske løsninger. Et viktig fundament for å finne et hensiktsmessig balansepunkt mellom disse hensyn er derfor å etablere en modell som 1. avgrenser og definerer et karakteristisk sikkerhetsbehov, og risikoforholdene knyttet til dette, 2. gir rammer for et sett av funksjonelle og tillitsmessige krav av både teknisk og administrativ karakter, 3. organiserer og presenterer kravene på en slik måte at det er mulig å utvikle ulike delløsninger og komponenter som ivaretar spesifikke oppgaver, og 4. reflekterer foretrukne tekniske standarder som gjelder innen den aktuelle sektoren (f.eks tekniske standarder for meldingssikring (kryptering, signering) av EDIFACT-meldinger).

6 INNLEDNING I de påfølgende kapitler i denne rapporten vil vi derfor presentere en sikkerhetsmodell som 1. gir rammene for de tekniske kravene (i hovedsak knyttet til dataoverføring) i selve veiledningen, og 2. gir rammene for differensiering og utdyping av kravene i veiledningen, gjennom såkalte meldingsprofiler knyttet til den enkelte EDI melding, som f.eks laboratoriesvar, resept, epikrise etc. EDI vs formell epost Vi legger dessuten til grunn at elektronisk datautveksling (EDI) dreier seg om program-til-program kommunikasjon hvor dataelementer i EDImeldingen er integrert med tilhørende dataelementer i avsender- og mottakerprogrammene (-applikasjonene). Vi legger videre til grunn at formell elektronisk post (e-post) er utveksling av formelle dokumenter hvor det foreligger administrative og tekniske krav til at dokumentutvekslingen er integrert med "autoriserte" applikasjoner hos avsender og mottaker for registrering, kontroll og lagring av kommunikasjonen. Skillet går altså på at et e-postdokument ikke inneholder dataelementer som er integrert med dataelementer i sluttbrukersystemene. Vi vil hevde at EDI og formell e-post ikke skiller seg vesentlig fra hverandre verken sikkerhetsmessig eller funksjonelt, og således kan behandles under ett og samme sikkerhetsregime. Anbefalinger for bruk av formell e-post for overføring av sensitive personopplysninger vil følgelig kunne beskrives med utgangspunkt i denne veiledningen, eventuelt som et supplement til denne. Arbeidet med slike anbefalinger er igangsatt. Behov for fleksibilitet Bruk av EDI i helsesektoren er i sterk utvikling, noe som bl.a er knyttet til sentrale målsettinger i Sosial- og Helsedepartementets handlingsplan "Mer helse for hver bit". Det foregår også et betydelig utviklings- og standardiseringsarbeid i regi av Sosial- og helsedepartementets Standardiseringsprogram, samtidig som det har vært og stadig kommer nye anskaffelsesprosjekter, bl.a i regional regi. Prosjektet "Regionalt Helsenett" i Helseregion III (Vest) har vært spesielt viktig, og erfaringene derfra danner utgangspunkt for tilsvarende satsinger i andre helseregioner. Sikkerhetsløsningene som er tatt fram så langt har vært basert på den teknologi som har vært tilgjengelig, samt praktiske forhold og historikk knyttet til EDI i helsesektoren. Det vil derfor være et løpende behov for å oppdatere sikkerhetsløsningene på basis av ervervet erfaring, og på basis av tilgang på nyere teknologi. 2

7 INNLEDNING Veiledningen avspeiler i stor grad den praksis som foreligger, de behov man ser ut fra erfaring med disse, og ikke minst de behov man ser knyttet til en bredere innføring og bruk av EDI for formell kommunikasjon og saksbehandling i helsesektoren. Samtidig vil de teknologiske løsningene og forutsetningene, f.eks knyttet til kryptering og digital signatur, modnes og utvikles betydelig i tiden som kommer. Det er derfor et klart behov for fleksibilitet i regelverket som tilrettelegger for migrasjonsstrategier. Det er følgelig en forutsetning at 1. Veiledningen oppdateres og utvikles i takt med den teknologiske utviklingen, og i samsvar med de behov som oppstår i helsesektoren innen dette feltet. 2. Helseinstitusjoner gis tilstrekkelig tid og rom for å tilpasse seg veiledningen, herunder utvikle migrasjonsstrategier som er implementerbare under de rådende rammebetingelser. En viktig betingelse for at slike forutsetninger skal være akseptable, er imidlertid at helseinstitusjonene gir EDI - og informasjonssikkerhet i sin alminnelighet - den nødvendige oppmerksomhet og tilstrekkelige ressurser. 3

8 VEILEDNING: EDI I HELSESEKTOREN Overordnet sikkerhetsmodell Kapittel 2 I dette kapitlet introduseres en sikkerhetsmodell som vi mener definerer de viktigste beskyttelsesbehovene knyttet til EDI i helsesektoren. Som bakgrunn for sikkerhetsmodellen skisserer vi først en del grunnleggende funksjoner og risikovurderinger knyttet til (digital) signering, kryptering og andre sentrale sikkerhetsaspekter. Den tradisjonelle signaturens funksjoner Signering Vi vil først minne om noen av den tradisjonelle, håndskrevne signaturens funksjoner som også må legges til grunn for den digitale signaturen 1 : Identifiseringsfunksjon som innebærer at signaturen knytter dokumentet og innholdet til den personen som signerer. Bevisfunksjon som innebærer at dokumenter i rettssaker blir benyttet som bevis for ett eller annet. Det faktum at det foreligger et dokument med en signatur som kan knyttes til en bestemt person kan være utslagsgivende i den enkelte sak. Integritetsfunksjon som innebærer at dokumentets innhold virkelig er det som vedkommendes signatur er ment å være knyttet til. Avslutningsfunksjon som innebærer at en signatur tilkjennegir en avslutning av en prosess som f.eks en medisinsk vurdering av en pasients behov for medikamenter og etterfølgende utfylling av en resept. Kompetansefunksjon som innebærer at vedkommende som har signert har myndighet til å foreta en handling eller treffe beslutninger som blir "bindende" for en eller flere personer (altså ikke nødvendigvis et uttrykk for dyktighet). Det synes i utgangspunktet klart at en digital signatur på et elektronisk dokument (herunder en EDI-melding eller et formelt e-postdokument) kan ivareta de funksjoner som er beskrevet for den tradisjonelle, håndskrevne signaturen. Dette er likevel ikke det sentrale spørsmålet. Det sentrale spørsmålet er å etablere tillit overfor brukere, normgivere og i siste instans rettsapparatet og domstolene til at funksjonene er ivaretatt. 1 Jfr rapporten "Meldingssikkerhet Tiltrodde tredjeparter og digitale signaturer, Del II Rettslige aspekter" fra Norsk EDIPRO,

9 OVERORDNET SIKKERHETSMODELL Her vil konsensus, normer og standarder være av en helt sentral betydning for å etablere denne tilliten. De samme funksjoner som er beskrevet for den tradisjonelle signaturen, kan antakelig ivaretas av andre tekniske foranstaltninger i IT- og kommunikasjonssystemene. Vi er derimot av den klare oppfatning at den digitale signaturen i stor grad forenkler arbeidet med å etablere tillit gjennom konsensus, normkrav og standarder. Vi mener å finne betydelig støtte i dette i de mange juridiske betenkninger og de mange tekniske standarder som i dag foreligger både i Norge og ellers i Europa, m.h.t digitale signaturer. Vi vil derfor legge til grunn at digitale signaturer benyttes for å ivareta de beskrevne funksjoner ved elektronisk dokument- og meldingskommunikasjon i helsesektoren. Vi vil likevel utdype problemstillingen noe. Signaturprosess Som vi vil se under, innebærer utveksling av elektronisk informasjon hvor de signaturfunksjonene som er beskrevet over skal ivaretas, mer enn å ha tillit til den digitale signaturen på den elektroniske meldingen som utveksles. For et papirdokument nedfelles informasjonsinnholdet og signeres det på et fysisk objekt som går (mer eller mindre) fysisk uforandret fra avsender til mottaker og som fortsatt er samme fysiske objekt når mottaker (eller senere en dommer) fortolker innholdet. I en elektronisk sammenheng er situasjonen en annen, samme funksjon kan bare oppnås gjennom 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 noe som samlet sett representerer en samlet og avgrenset mengde informasjon (informasjonsobjekt) som skal signeres og sendes en gitt mottaker. Brukeren vil forholde seg til den visuelle presentasjonen av dette informasjonsobjektet når det genereres og en "signaturhandling" utføres. Dette visuelle informasjonsobjektet, via ulike tekniske prosesser, omformes til en elektronisk dokument eller melding, som påføres den digitale signaturen. (Merk at en digital signatur krever at en melding digitalt må være oversendt til mottaker uforandret ned til hvert enkelt digitale siffer og den innbyrdes rekkefølgen i disse for at en verifikasjon av signaturen skal være vellykket.) Meldingen krypteres, pakkes inn i et utvekslingsformat og oversendes mottaker. Mottaker pakker (den krypterte) meldingen ut, dekrypterer og verifiserer signaturen. Informasjonen i meldingen overføres deretter til mottakers endesystem (som et nytt informasjonsobjekt) før kjeden avsluttes med mottakers aksept av det visuelle 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 av den informasjonen som faktisk signeres. For å oppnå dette er det nødvendig å etablere en tillitskjede knyttet til den signatur- og informasjonsutvekslingsprosessen som ble beskrevet over. 5

10 OVERORDNET SIKKERHETSMODELL Det jeg ser er det jeg signerer! I noen tilfeller vil en slik tillitskjede forutsette at en bruker tar et eprsonlig ansvar for det faktiske innholdet i et elektronisk dokument, f.eks en EDI melding. Et relevant krav til signaturprosessen i avsenders endesystem kan i et slikt tilfelle (populært) formuleres som: Det jeg ser er det jeg signerer! Et tilsvarende krav knyttet til mottaker endesystemet er tilsvarende Det jeg ser er det som ble signert! Disse kravene må igjen avlede krav til avsendersystemets funksjonalitet og (tekniske) tillit når det gjelder koplingen mellom det som faktisk signeres og det som brukeren ser foran seg på skjermen (og tilsvarende til mottakersystemet). Krav til den digitale signaturen må ivareta tilliten i det mellomliggende kommunikasjonssystemet (m.h.t signaturfunksjonene beskrevet over). Den implementerte løsningen må sørge for tilstrekkelig høy tillit til at disse kravene etterleves og samtidig sikre brukervennlig funksjonalitet. Man kan også tenke seg tilfeller der en digital signatur mer eller mindre automatisk påføres en utgående melding, med kun den hensikt å tilkjennegi at innholdet i meldingen, f.eks et laboratoriesvar, er kvalitetssikret i.h.t virksomhetens rutiner. Kravene til signeringsprosedyren vil i et slikt tilfelle være mindre omfattende, samtidig som at signaturens faktiske betydning blir mer avhengig av andre deler av tillitskjeden (f. eks kvalitetssystemet). En viktig moment som etter vår mening understøtter denne "oppdelingen" og herunder bruken av digitale signaturer, er følgende: En ting er at en sluttbruker kan etablere høy tillit til at sitt lokale endesystem i alle ledd ivaretar signaturprosessen. Det vil derimot være vanskeligere å forutsette eller kreve at samme bruker skal ha (eller vil kunne få) samme høye tillit til endesystemet i "andre enden" eller til kommunikasjonssystemet i mellom. Dette er et viktig aspekt å ha i mente videre når sikkerhetsmodellen formuleres. Risikovurderinger I signaturfunksjonene over ligger det innebygd grunnleggende risikovurderinger knyttet til trusler mot og konsekvenser av at funksjonene ikke blir ivaretatt. F.eks at en forfalsket signatur kan påføre skade på vedkommende som enten har mottatt dokumentet eller framstår som påstått underskriver. Et annet eksempel er at en som utfyller og signerer en resept ikke er en lege, med mulig skade for pasienten. Når vi senere skal diskutere funksjonalitet og tillit i.f.m utformingen av veiledningen, må disse underliggende risikovurderingene konkretiseres og utfylles med mer detaljerte risikovurderinger i.f.m de ulike ledd i tillitsskjeden beskrevet over. Disse risikovurderingene vil legitimere kravene som angis, ikke minst grad av tillit som skal kreves (hva er tilstrekkelig høy tillit?), noe som har direkte konsekvenser både i forhold til (også) viktige, men ikke direkte sikkerhetsrelaterte aspekter som brukervennlighet og kostnader. 6

11 OVERORDNET SIKKERHETSMODELL Sikring av konfidensialitet Avgrensninger i forhold til informasjonsflyt Kryptering Når det gjelder krypteringens funksjon er den i utgangspunktet enklere å beskrive og behandle. Primært er krypteringens funksjon å sikre konfidensialiteten til (den sensitive) informasjonen som kommuniseres. I dette ligger det en risikovurdering i forhold til muligheten for uvedkommende skal få tilgang til informasjonen, og den mulige skade på den personen informasjonen omhandler dersom dette skulle skje. I vurderingene av mulighetene for at uvedkommende skal få tilgang til sensitiv informasjon, er det naturlig å se på hvor informasjonen befinner og "beveger" seg og mulighetene for å utøve kontroll hvem som får tilgang de ulike steder. Vi setter her sette avgrensninger på fem "nivåer" (som også er relevante for de andre sikkerhetsmessige faktorene som beskrives over og under konfidensialitet): 1. Avgrensning innen et EDB-system (f.eks et pasientjournalsystem) 2 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 ingen avgrensning. Vi skal ikke gå i dybden på disse aspektene her, men legge til grunn at når det gjelder normer for kryptering, vil vi sette et skille mellom 3 og 4 Informasjon "utenfor husets fire vegger" skal krypteres 3. Informasjon innen husets fire vegger bør ikke krypteres. Det siste er mer pragmatisk begrunnet i andre sentrale sikkerhetsaspekter, nemlig fysisk og logisk kontroll og tilgjengelighet. Vi vil ikke diskutere dette videre her, da det ikke er direkte relevant for hva vi formulerer nedenfor. Vi vil likevel si at kryptering av f.eks interne databaser o.l med f.eks pasientjournaler ut fra dagens teknologi er forbundet med betydelig risiko for at data kan bli utilgjengelig eller tapes p.g.a (uopprettelige) feil som gjør dekryptering (og derved tilgjengeliggjøring) vanskelig eller umulig. Signerings- og krypteringsnøkler Tillit til digitale signaturer og kryptering er sterkt avhengig av tillit til at de kryptografiske nøkler som benyttes i disse tekniske prosessene, blir håndtert og utvekslet på en "sikker måte", d.v.s ikke representerer åpenbare svake ledd i den totale tillitsskjede. 2 Merk at selv her har ikke hvem som helst uten videre rett til tilgang til hvilke som helst sensitive opplysninger. "Need to know" råder! 3 Med mulige unntak for f.eks faste linjer mellom to virksomheter (av typen 3). 7

12 OVERORDNET SIKKERHETSMODELL Vi anser dette for å være tilstrekkelig vurdert, kjent og anerkjent, så vi skal ikke utbrodere dette sikkerhetsaspektet videre. Vi vil likevel komme tilbake til dette aspektet i tilknytning til aspekter som nøkkelsertifikater og smartkortbasert versus programvarebasert sikring av private, hemmelige kryptografiske nøkler m.m. Sikring mot utilsiktet utlevering, innbrudd og angrep De siste sikkerhetsaspektene vi anser som relevante i forhold til Veiledningen, er knyttet til at en tilkopling til et eksternt nettverk (for å realisere den ønskede meldingskommunikasjonen) medfører 1. risiko for at sensitiv informasjon utilsiktet kan utleveres/utsendes til eksterne, uvedkommende (i strid med taushetspliktsregler), 2. risiko for at eksterne, uvedkommende kan "bryte" seg inn i en virksomhets interne nettverk og EDB-systemer, og 3. risiko for at data som "importeres" inn i virksomhetens nettverk og EDB-systemer bringer med seg "ondsinnet programvare" som f.eks datavirus, makrovirus og "trojanske hester". (Såkalte datadrevne angrep.) I forhold til 1, vil EDI gjennom kravene underlegges et hensiktsmessig 4, naturlig og implisitt kontrollregime med hensyn til at kommunikasjonen er knyttet til / integrert med lokale kommunikasjons- og endesystemer som a) skal sikre at kun autoriserte brukere får tilgang å kommunisere, b) at evt mottakere er autoriserte (ikke er uvedkommende) og c) at kommunikasjonen er saklig og legitim, d.v.s er knyttet til formelle og legale prosesser i.f.m pasientbehandling el.l. d) at meldingen transporteres på en sikker måte (f.eks kryptert). I forhold til 2, vil selve tilkoplingspunktet og tilkoplingsformen til det eksterne nettverket underlegges et hensiktsmessig kontrollregime. I forhold til 3, som er det minst "forutsigbare" aspektet, må det primært etableres et kontrollregime som omfatter utvikleres, leverandørers og brukeres (og normgiveres) løpende vurdering av risikoen knyttet til dette aspektet og evt iverksetting av nødvendige, bevisst vurderte og dokumenterte, mottiltak. 4 I forhold til å etablere tilstrekkelig/akseptabelt tillits- og risikonivå. 8

13 OVERORDNET SIKKERHETSMODELL Sikkerhetsmodellen Den sikkerhetsmodellen som presenteres her, representerer en konseptuell forståelse og strukturering av de over omtalte sikkerhetsaspektene ved EDI. Hovedstruktur Som indikert i Figur 4 under, omhandler sikkerhetsmodellen tre hovedelementer: 1. Endesystemsikkerhet som skal sørge for at informasjonsflyten er saklig og legitim i forhold de prosessene og sammenhengene denne inngår i. Autentisering og autorisasjon av brukere i endesystemet, både i forhold til lokal tilgang og til å benytte kommunikasjonstjenester, er eksempler på dette. 2. Meldingssikkerhet som skal ivareta selve meldingstransporten mellom endesystemer (konfidensialitet, integritet, autentisitet, ikkebenekting) 3. Tilkoplingssikkerhet som bl.a skal sikre at tilkoplingspunktet og tilkoplingsformen hindrer innbrudd av uvedkommende fra eksterne nettverk Figur 4 Sikkerhetsmodell (EMT-modell) Avgrensning av virksomheten Endesystemsikkerhet Saklig og legitim informasjonsflyt Sikker håndtering og oppbevaring Meldingssikkerhet Tilkoplingssikkerhet Sikring av tilkoplingspunktet og tilkoplingsformen mot eksternt nettverk Sikring av melding under transport mellom endesystemer Eksternt nettverk Digital signatur Forholdet mellom de sikkerhetsaspektene vi beskrev tidligere i dette kapitlet og inndelingen i sikkerhetsmodellen er ikke nødvendigvis entydig; ulike aspekter kan understøttes av ulike funksjoner med ulik tilknytning til E, M og T. Eksempelvis kan deler av den signaturprosessen vi beskrev i forrige kapittel, herunder også "påføringen" av den digitale signaturen" 9

14 OVERORDNET SIKKERHETSMODELL i varierende grad funksjonelt iverksettes som en del av E eller som en del av M. Hvis signaturen er entydig knyttet til M, må brukeren som signerer ha et grunnlag for å ta det ansvaret som signaturen på meldingen innebærer. Både ansvaret og grunnlaget må være klart definert. Grunnlaget kan f.eks være en (pålagt) inspeksjon av meldingsinnholdet hvorigjennom vedkommende tar et individuelt ansvar (f.eks når en lege signerer en resept). Et annet mulig grunnlag er dokumentasjon fra interne (formelle) rutiner, slik at den som signerer går god for (eksternt) at en intern rutine er fulgt, og at ansvaret for denne er dokumentert og sporbart internt (f.eks ved utsending av visse typer laboratoriesvar fra sykehus). Hvis signaturen er entydig knyttet til E, betyr dette at signaturen er nærmere knyttet til de saksbehandlingprosesser som danner grunnlag for meldingen, og mindre til selve meldingsforsendelsen. Den konkrete utformingen av normene på dette området er avhengig ikke bare av selve EDI-løsningen, men også av de bakenforliggende saksbehandlingssystemene og om de teknologiske forutsetningene for å kunne benytte digital signatur i disse foreligger. Slike spørsmål kan ikke avklares i sin fulle bredde her, og kan heller ikke slås fast en gang for alle i selve veiledningen. Supplerende meldingsprofiler vil dog sette rammer som avgrenser hvordan funksjoner kan "varieres" og realiseres, med ulike krav til dokumentasjon (fra leverandør og brukermiljø) av tillit knyttet til ulike varianter. Normkravene må kunne dekke og "tillate" ulike teknologiske realiseringer! Samsvar med europeisk standardisering Vi vil i denne sammenhengen gjenta vår poengtering av at Veiledningen må kunne dekke og "tillate" ulike teknologiske realiseringer, og at normgiverne må gi slipp på fristelsene til å detaljregulere dette kun ut fra teknologi som til en hver til er kjent eller presentert for normgiverne. Vi viser til den forutgående diskusjonen av dette temaet. Vi vil dessuten nevne at Sikkerhetsmodellen EMT formodentlig også vil bli lagt til grunn i europeisk standardisering på området medisinsk informatikk / sikker kommunikasjon 5 (CEN/TC251/WGIII), og at den anvendes i pågående EU-finansierte telematikkprosjekter på dette området (TrustHealth, SEMRIC), hvor også KITH deltar. 5 Hvor KITH vil lede et konkret utviklingsarbeid i 1998/99. 10

15 VEILEDNING: EDI I HELSESEKTOREN Utdypning av sikkerhetsmodellen Kapittel 3 Vi vil her utdype sikkerhetsmodellen EMT fra forrige kapittel. Modellen favner både funksjonelle og tillitsmessige aspekter. Modellen vil være i samsvar med (overordnede) tekniske krav i veiledningen (Vedlegg A), og vil dessuten kunne anvendes i supplerende meldingsprofiler. Mål og hensikt Scenarier Figur 5 Funksjonelle komponenter Funksjonell modell Modellen tar utgangspunkt i funksjonelle krav. Hver komponent kan assosieres med en bestemt type funksjonalitet, og vi vil forsøke å gi eksempler på dette på generelt grunnlag. Merk også at det til hver funksjonelle komponent - såvel som til helheten - kan stilles tilhørende tillitskrav, f.eks krav til teknisk design eller implementering, eller til analyser og dokumentasjon ved ulike måter å tilfredsstille de funksjonelle kravene på gjennom ulike (kjente og ukjente) tekniske realiseringer. Figur 5 illustrerer de funksjonelle komponenter i sikkerhetsmodellen (E, M og T) som vi anser som nødvendige og tilstrekkelige for meldingsbasert kommunikasjon (EDI og epost). 0. Overordnede prinsipper for informasjonsflyten E Sending 1. Autorisasjon og legitimitet 2. Krav til innhold 12. Lagring av data 3. Adressering 11. Kontroll av innhold 4. Beskyttelsesbehov Mottak M T 5. Signeringsprosedyre 6. DS 10. Signatursjekk 7. Kryptering/dekryptering 8. Postkontorfunksjoner 9. Brannmurfunksjoner Beskrivelse I det følgende gis det en summarisk presentasjon av rollen til hver komponent, i.h.t en kombinert sende- og mottakssekvens. Merk at krav til feilhåndtering fortrinnsvis nedfelles eksplisitt for hver funksjonell komponent.

16 UTDYPNING AV SIKKERHETSMODELLEN 0. Overordnete prinsipper for informasjonsutvekslingen: Mens de underliggende komponentene (f.o.m. 1) beskriver krav rettet mot den faktiske meldingsutvekslingen, vil vi her kunne beskrive de overordnede rammebetingelsene for at dette skal kunne foregå innen en tiltenkt og kontrollert ramme. Dette kan innebære bl.a: Funksjonell beskrivelse av meldingskommunikasjonen som profilen omfatter, dens funksjon og hensikt (herunder forankring og legitimitet). Krav til for- og etterbehandling (f.eks sikkerhetskrav knyttet til behandling av papirutskrifter) Overordnede krav til logging og feilhåndtering Krav om harmonisering eller samordning 6 av sikkerhetspolicyer på sende- og mottakssiden, eventuelt (tillits-)krav knyttet til verifisering av dette (f.eks knyttet til utvekslingsavtaler, eller knyttet til den faktiske meldingsutvekslingen). 1. Autorisasjon og legitimitet: Dette handler både om å kontrollere at brukere er tilstrekkelig autorisert i forhold til applikasjonene som utveksler EDI meldinger, og at de har en legitim rett til å sende og motta den aktuelle meldingstypen. Autorisering kan løses gjennom både eksplisitt kontroll (tilgang til å sende meldingen) og implisitt kontroll (tilgang til en applikasjon). Tiltenkt mottaker må dessuten være "saklig og legitim" i.h.t meldingens innhold og funksjon (f.eks ved elektronisk henvisning til spesialist). Det kan også være nødvendig at mottaker kontrollerer om avsender har en legitim rett til å kreve og forvente at meldingen blir fulgt opp, f.eks når det gjelder resepter og forskrivningsrett for spesielle preparater (f.eks basert på offentlige registre). 2. Krav til innhold: Krav og rammebetingelser for hvilken informasjon som skal og kan inngå i ulike meldinger. Dette kan uttrykkes gjennom funksjonsbeskrivelser og informasjonsmodeller (samt tilhørende implementasjonsguider knyttet til gitte meldingsformater). Innholdet skal først og fremst være tilstrekkelig og fyllestgjørende i forhold til det helsefaglige formålet med meldingen, og ikke inneholde unødig informasjon som i neste omgang medfører unødvendige risikomomenter med tanke på personvernet. 3. Adressering: Rammebetingelsene for valg av adressat (mottaker) for meldingen må beskrives. Skal det være mulig å adressere individer/personer, eller institusjoner? Skal de være predefinerte adressater, eller skal det (kun) være mulig å finne adressater f.eks gjennom HPR 7 6 Policy Bridging 7 Helsepersonellregistret (elektronisk) 12

17 UTDYPNING AV SIKKERHETSMODELLEN eller HIR 8, når disse blir tilgjengelige. Andre begrensninger i adresserommet er også tenkelige. 4. Meldingsbeskyttelse: Behovet for kryptering og signering av meldinger og ulike kvitteringsmeldinger må defineres. Statisk beskyttelse innebærer at behov for f.eks kryptering/signering er forhåndsbestemt for en klasse meldinger. Dynamisk beskyttelse innebærer at behovet må avgjøres for hver enkeltmelding (som f.eks i epost). Ved krav om signering av meldinger/kvitteringer skal både formål og forutsetninger (grunnlag) for påføring av signatur, defineres entydig. Spesielt når det gjelder kvitteringsmeldinger må det avklares om kvitteringen indikerer å ha mottatt, eller å akseptere innholdet. 5. Signeringsprosedyre: Signeringsprosedyren skal ta utgangspunkt i grunnlaget for signaturen, og avklare hvordan dialogen med brukeren skal foregå i prosessen mot en ferdig påført signatur. Hvis en bruker skal kunne signere på vegne av andre eller på vegne av institusjonen, må det foreligge et faktisk grunnlag (f.eks interne logger eller "elektroniske kvitteringer" med mindre innebygd tillit enn en digital signatur) som kan bygges inn i tillitskjeden. Når brukeren tar et mer personlig ansvar må prosedyren sikre at brukeren inspiserer tilstrekkelig av meldingsinnholdet (og evt. relatert informasjon som ikke inngår i meldingen) før signering. Det kan også stilles spesifikke krav som sikrer integriteten mellom det som brukeren ser, og det som i realiteten signeres, jfr "Det jeg ser er det jeg signerer" (hos avsender) og "Det jeg ser er det som er signert" (mot mottaker). 6. Digital signatur: Tekniske krav og spesifikasjoner, krav til bruk av standarder m.v for algoritmer, nøkkelhåndtering etc, knyttet til et spesifikt meldingsformat og syntaks. 7. Kryptering/dekryptering av meldinger: Tekniske krav og spesifikasjoner, krav til bruk av standarder m.v for algoritmer, nøkkelhåndtering etc., knyttet til et spesifikt meldingsformat og syntaks. 8. Meldingstransport (Postkontor): Hovedformålet med denne type funksjonalitet er å sikre den nødvendige tjenestekvalitet for overføring av meldinger, og å unngå å eksponere krypterte meldinger mot en unødvendig stor masse av aktører med potensiell (teoretisk) interesse av å forsøke å knekke krypteringen 9. Aktuelle punkter her er kontroll av rutingsveier (f.eks anbefalte P7-postkasser) og adresseringsrom (-struktur) på meldingstransportnivå mellom enheter, samt krav om autentisering av postkasser og postkontor. Logging av meldingstrafikken er også en mulighet, og tilgjengelighet av denne loggen (i forhold til administratorer, meldingsutstedere etc) bør reguleres. Ved behov for koordinering av sikkerhetspolicyer (jfr pkt 0) kan det (i teorien) bli aktuelt at meldingstrans- 8 Helseinstitusjonsregistret (elektronisk) 9 Krav på dette området vil således - i teorien - kunne knyttes til styrken i den kryptering som avkreves i.h.t pkt 7. 13

18 UTDYPNING AV SIKKERHETSMODELLEN portsystemet forhandler dette før eller i tilknytning til selve meldingsutvekslingen. 9. Brannmurfunksjoner. Krav om filtrering og kontroll av applikasjonsprotokoller og nettverksprotokoller, anrop og oppkopling m.m. Kravene vil variere i.h.t det eksterne trusselbildet. 10. Signatursjekk: Tekniske rutiner for kontroll av gyldig signatur på mottatt melding, herunder bruk av nøkkelsertifikater. 11. Kontroll av innhold: Kriterier for å avgjøre om innholdet i mottatt melding svarer til forventningene. Et slikt krav vil være tett koblet til kravene i pkt 2, og vil være en svært viktig kvalitetskontroll. Det bemerkes imidlertid at en slik kontroll (herunder pkt 2) vil være sterkt avhengig av felles, entydige og hensiktsmessige kodeverk på de aktuelle områdene. 12. Lagring: Lagring og organisering av mottatt informasjon, herunder oppfølging av eventuelle krav til koordinert sikkerhetspolicy. Anvendelse av sikkerhetsmodellen Sikkerhetsmodellen ovenfor danner et grunnlag for en uniform beskrivelse og begrepsanvendelse når det gjelder utformingen av EDI krav. Sikkerhetsmodellen har følgelig en rolle i overgangen fra Retningslinjer for informasjonssikkerhet ved behandling av personopplysninger til Veiledning for bruk av EDI, og for meldingsprofiler som beskriver implementeringen av den enkelte EDI-melding (f.eks resept) på basis av veiledningen. Modellen øker lesbarheten for ulike profiler, og vil ikke minst synliggjøre at mange tekniske komponenter vil kunne brukes eller inngå i ulike profiler. Dette er viktig, ikke minst for leverandørene (og dermed også for kundene!). Lesbarhet, gjenbruk og kvalifisering I en konkret meldingsprofil vil dog hver enkelt komponent fra modellen kunne konkretiseres og kvalifiseres gjennom en mer eksplisitt beskrivelse, uten at dette vil svekke målet om lesbarhet og gjenbruk i vesentlig grad. Merk også at en konkret meldingsesprofil ikke nødvendigvis vil omfatte alle komponentene i modellen. Dette er illustrert i figuren under: 14

19 UTDYPNING AV SIKKERHETSMODELLEN Retningslinjer for for informasjonssikkerhet EMT modell Veiledning ved bruk av EDI Meldingsprofiler Meldings- Meldingsprofileprofiler Implementert løsning Utvilklingshorisont I sin konkrete utforming må profilene også beskrive en "utviklingshorisont" som gjør det mulig for brukerne å utvikle migrasjonsstrategier innen rammen av definerte overgangsordninger. Datatilsynets retningslinjer for informasjonssikkerhet ligger til grunn for hele arbeidet, og der det ikke er gitt spesielle krav i veiledningen for EDI, må retningslinjene følges. Det at punkt er omtalt i veiledningen betyr heller ikke at man kan se bort fra kravene i retningslinjene. Veiledningen er kun ment som en hjelp i å oppfylle kravene gitt i retningslinjene. Tillitsfaktorer Tillitsmessige krav Modellen vil også kunne brukes for å uttrykke tillitsmessige krav knyttet til anbefalt realisering. De fleste tillitskrav vil være generelle, men det vil også bli nødvendig å stille spesifikke krav til komponenter innen modellen. Med tillitsmessige krav menes krav og føringer som styrer hvordan det etableres tillit til de løsninger og produkter som utvikles og tas til anvendelsei. Med (teknisk) tillit (eng: assurance, trust) menes Verifisering av velegnethet [ITSEC: Effectiveness] I hvor stor grad er de beskrevne funksjonelle komponentene velegnet til å ivareta et foreliggende beskyttelsesbehov? Verifisering av korrekthet [ITSEC: Correctness]. I hvor stor grad er tekniske elementer, løsninger eller komponenter korrekt iverksatt og implementert? 15

20 UTDYPNING AV SIKKERHETSMODELLEN Tillit må både etableres og vedlikeholdes Brukernes kompetanse er kritisk Tillitskrav i praksis En á priori teknisk tillit kan skapes både gjennom ekstern evaluering 10 men også leverandørens dokumentasjon og analyser 11. Dessuten må en slik (á priori) tillit opprettholdes gjennom at brukeren og dennes egenkontroll kontinuerlig etterprøver og vurderer forutsetningene for den etablerte tilliten, og da spesielt fokusert på samspillet mellom teknologi og brukere. Dette forutsetter at brukeren i gjennomføringen av sin egenkontroll er kjent med disse forutsetningene, og kan forholde seg til dem fra sitt ståsted. Selv om innholdet i veiledningen og leverandørenes dokumentasjon skal legge mest mulig til rette for dette, er det en forutsetning at kompetansen på brukersiden også styrkes. 12 Brukernes kompetanse, både når det gjelder de tekniske og de regelverksmessige sidene, vil altså være en svært kritisk faktor for å implementere tillit. Eksempler på at uvitenhet og uoppmerksomhet setter sikkerheten i fare finnes. Det er viktig at det treffes tiltak som høyner brukernes bevissthet og kompetanse på dette området. Det må også vurderes hvordan f.eks legekontorer kan organisere seg med tanke på å kjøpe ekstern assistanse for å utøve den nødvendige egenkontroll, f.eks gjennom sine leverandører. Vi vil til slutt peke på at tillitsmessige krav i praksis vil være aktuelle på følgende områder: 1. Analyser og dokumentasjon i forhold til spesifikke problemstillinger (knyttet til både velegnethet og korrekhet) 2. Foretrukne realiseringsmåter basert på antakelser om egenskaper i produkter og systemer som inngår i totalløsningene (knyttet til korrekthet). Segmentering av programsystemer Egen EDI-tjener på legekontor? Når det gjelder pkt 2 så vil slike krav først og fremst gi føringer for en forsvarlig segmentering av uavhengige programsystemer som samhandler, men som ikke kan tillates å forstyrre hverandres funksjon og operasjon. Et eksempel på dette er et legekontor med et legejournalsystem basert på klient-tjener arkitektur, samt en EDI-løsning. I et slikt scenario vil det være et hovedpoeng å sørge for at legejournalsystemet og EDI-systemet bare samhandler gjennom definerte grensesnitt og prosedyrer, uten å påvirke hverandre på noen annen måte. Ved bruk av en tjenermaskin basert på et segmentert operativsystem, f.eks UNIX eller NT, vil det kunne være akseptabelt å kjøre både legejournalsystemets tjenerfunksjoner og EDI-funksjonen på en og samme (fysiske) tjenermaskin. Hvis operativsystemet ikke kan tilby slik sterk segmentering, må segmenteringen skje gjennom at EDI-funksjonen kjøres på en egen fysisk (EDI-) server, og at 10 Også kalt "evaluation assurances" 11 Også kalt "developmental assurances" 12 Denne problemstillingen er velkjent i forbindelse med innføring av internkontroll. Poenget må være å sørge for at brukeren ser seg tjent med å høyne sitt eget kontroll- og sikkerhetsnivå ved bruk av IT og ekstern kommunikasjon 16

21 UTDYPNING AV SIKKERHETSMODELLEN samhandlingen med legejournalsystemet kontrolleres gjennom et nettoperativsystem. Signering og kryptering Tilsvarende behov for segmentering ligger til grunn for krav knyttet til digital signatur (og kryptering). Tillit til sikkerheten i krypterings- og signeringsløsninger hviler generelt sett tungt på tilliten til oppbevaring og beskyttelse av nøkkelmateriell. Behovet for å beskytte krypteringsfunksjonen er en viktig del av motivasjonen for å "segmentere ut" EDIfunksjonen som helhet. Når det gjelder digital signatur er det viktig at den private nøkkelen beskyttes, og at selve signeringsalgoritmen gjennomføres helt nøyaktig. Når signeringsfunksjonen berører arbeidsstasjonen, oppstår et behov for segmentering mellom det generelle programsystemet på denne, og signeringsfunksjonen. I prinsippet kan en arbeidsstasjon basert på sterk segmentering ivareta dette (programvarebasert signering). Det er imidlertid sterke grunner til å benytte smartkort-løsninger. For det første vil en smartkortløsning i seg selv segmentere signeringsfunksjonen fra det øvrige programsystemet på arbeidsstasjonen (og følgelig kunne brukes på mer ordinære arbeidsstasjoner). For det andre vil en smartkortbasert løsning ha en langt bredere anvendelighet, og ikke minst gi større brukermobilitet i en stor organisasjon. Endelig vil tillitskravet knyttet til digital signatur - til en viss grad - være knyttet til signaturens faktiske funksjon for den enkelt melding. Men, det ville vært lite klokt å legge opp slike løsninger (infrastruktur) med utgangspunkt i enkeltmeldinger. Under ideelle (økonomiske) betingelser ville dette hensynet avledet tunge føringer for smartkort løsninger. Under de rådende omstendigheter er det (dessverre) behov for overgangsløsninger også på dette punkt. 17

22 VEILEDNING: EDI I HELSESEKTOREN Veiledning : EDI i helsesektoren Vedlegg A Del I - Innledning Definisjoner EDI - (Electronic Data Interchange) Elektronisk utveksling av data mellom applikasjonssystemer (program-til-program kommunikasjon) EDI-melding: en elektronisk melding som følger en definert EDIsyntaks (f.eks EDIFACT) EDI-infrastruktur: EDI-infrastrukturen består av tjenester som benyttes i forbindelse med EDI-overføringer, som epost (meldingstransport), TTP-tjenester, offisielle adressebøker, brannmurløsninger mm. Formål Dette dokumentet veileder helseinstitusjoner i informasjonssikkerhet ved elektronisk datautveksling (EDI) av sensitive personopplysninger. Veiledningen er en utdypning av Datatilsynets Retningslinjer for informasjonssikkerhet ved behandling av personopplysninger, og bør leses sammen med dette dokumentet. Det er en forutsetning at ingen virksomheter benytter EDI for utveksling av slike opplysninger før de overordnede vilkårene i Retningslinjer for informasjonssikkerhet ved behandling av personopplysninger er oppfyllt. Formålet med EDI-kommunikasjonen er elektronisk utveksling av informasjon fra applikasjon til applikasjon over en felles infrastruktur, herunder bruk av eksterne nettverk. Veiledningen innebærer ingen prinsipielle hindringer for all EDI kommunikasjon til/fra en helseinstitusjon, herunder både sensitiv og ikke sensitiv informasjon, kan benytte seg av en felles (EDI) infrastruktur. Del II - Ledelsens ansvar Ansvar Helseinstitusjonens ledelse har ansvaret for at personopplysningene er tilfredsstillende sikret også ved bruk av EDI.

23 VEILEDNING : EDI I HELSESEKTOREN Dette omfatter også ansvaret for tilfredsstillende sikkerhet i de deler av informasjonssystemet som inngår i EDI-løsningen, herunder etablering av: 1. En organisasjon med klare ansvars og myndighetsforhold i forbindelse med EDI. 2. Nødvendige sikkerhetstiltak i helseinstitusjonens egen infrastruktur for EDI, og for ekstern tilkopling. Ledelsens ansvar omfatter også at det årlig avsettes tilstrekkelige resurser - både personellmessig og økonomisk - til at en effektiv og sikker ekstern EDI-løsning opprettholdes. Dersom slike resurser ikke er tilgjengelig må EDI-løsningene ikke brukes. Sikkerhetsmål Formålet med bruk av EDI skal fremgå av beskrivelsen av helseinstitusjonens sikkerhetsmål. Sikkerhetsmålene for EDI skal formuleres slik at både avsenders og mottakers behov og kriterier for en konfidensiell, autentisk, saklig og legitim meldingsflyt ivaretas. Sikkerhetsmålet skal altså dekke de viktigste sikkerhetsmessige forutsetninger for bruk av EDI, herunder ekstern tilkopling. Dette omfatter: 1. Endesystemsikkerhet, ved at helseinstitusjonen kun benytter EDI når dette er nødvendig for å løse pålagte oppgaver, og at informasjon som overføres ved hjelp av EDI skal være saklig og legitim i forhold til formålet. Bruk av EDI skal følgelig være knyttet til formelle prosesser godkjent av virksomhetens ledelse. 2. Meldingssikkerhet, ved at det iverksettes tiltak for å hindre uautorisert utlevering av sensitiv personinformasjon når EDI benyttes, og ved at den enkelte melding sikres under transport. 3. Tilkoplingssikkerhet, ved at EDI-løsninger som benytter åpne, eksterne nettverk har en sikring mot uautorisert tilgang fra eksterne nettverk, herunder introduksjon av ødeleggende program (virus etc) Beskrivelsen av sikkerhetsmål skal ta utgangspunkt i elementene i denne seksjonen, men må være tilpasset virksomhetens egenart. Sikkerhetsstrategi Beskrivelsen av helseinstitusjonens sikkerhetsstrategi skal angi alle valg og overordnede tiltak nødvendig for benytte EDI i samsvar med sikkerhetsmålet. Sikkerhetsstrategien skal ta utgangspunkt i at: 19

24 VEILEDNING : EDI I HELSESEKTOREN 1. EDI benyttes i samsvar med tjenestlige behov og etter godkjenning fra helseinstitusjonens ledelse. 2. Benyttede meldingsprofiler skal identifiseres og dokumenteres, og være godkjent av helsemyndighetene og Datatilsynet. 3. Det kun er mulig å sende og motta meldinger med adresser helseinstitusjonen på forhånd har godkjent. 4. Meldinger inneholdende sensitive opplysninger krypteres. 5. Det etableres tilfredsstillende tilkoplingssikkerhet eksempelvis ved å benytte en løsning som fremgår av Datatilsynets: Veiledning i informasjonssikkerhet ved helseinstitusjoners tilkopling til eksterne datanett. For mindre virksomheter (f.eks legekontor, apotek) anbefales det å benytte postkontortjenester og -protokoller som ikke krever kontinuerlig oppkopling, dvs at tilkoplingspunktet ikke aksepterer eksterne anrop. 6. Anerkjente løsninger og leverandører benyttes så langt det lar seg gjøre. 7. Det tas i bruk tekniske løsninger (eksempelvis nettverk og operativsystemer) som implementerer tilstrekkelig segmentering av kombinasjonen av EDI-løsning og applikasjonssystem. Med dette utgangspunkt skal sikkerhetsstrategien på overordnet nivå angi ansvars- og myndighetsforhold, forholdet til partnere/leverandører, samt organisatoriske og tekniske sikkerhetstiltak i tilkoplingspunkt og i internt datanettverk/informasjonssystem. Personopplysninger Virksomheten skal utarbeide oversikt over hvilke personopplysninger som overføres vha. EDI. Oversikten skal angi klassifisering av personopplysningene sammen med informasjon om de meldingsprofiler som benyttes. Risikoanalyse Før EDI løsninger tas i bruk for å overføre personopplysninger skal det gjennomføres en risikoanalyse som fokuserer på om de gitte premissene for legitim informasjonsflyt er til stede, og om implementerte sikkerhetstiltak er tilstrekkelige. Egenkontroll Som del av helseinstitusjonens årlige egenkontroll skal arbeidet med EDI gjennomgås for å sikre at besluttet sikkerhetsstrategi etterleves. Denne delen av egenkontrollen omfatter vurdering av 20

25 VEILEDNING : EDI I HELSESEKTOREN 1. faktisk organisering, ansvars- og myndighetsforhold i forhold til besluttet organisering 2. faktisk bruk,av EDI i forhold til besluttede rutiner 3. opplæring og veiledning av brukere 4. effektivitet av besluttede sikkerhetstiltak Egenkontrollen skal også omfatte utprøving av sentrale sikkerhetskomponenter som f.eks postkontor, kryptering/signering og sikkerhetsløsning i kommunikasjonspunkt for ekstern tilkopling, eksempelvis brannvegg. Ledelsens gjennomgang Ved ledelsens årlige gjennomgang skal mål, strategi og organisering som danner grunnlaget for EDI-løsningene vurderes. Denne delen av gjennomgangen skal ha som formål å vurdere om: 1. det er behov for EDI, 2. kommunikasjonstilbudet er tilfredsstillende i forhold til formålet, 3. informasjonssikkerheten er tilfredsstillende, 4. offentlige sikkerhetskrav er ivaretatt, evt. endret. Som underlag for gjennomgangen benyttes resultater fra egenkontroller og risikoanalyser. Del III - Organisering Organisasjon Arbeidet med EDI skal organiseres slik at tilfredsstillende informasjonssikkerhet oppnås, og er koordinert med helseinstitusjonens sikkerhetsarbeid forøvrig. Helseinstitusjonens ledelse skal utpeke en medarbeider med overordnet operativt ansvar for å implementere og vedlikeholde EDI-løsningen. Ansvar og myndighetsforhold skal være avklart slik at brukere som benytter EDI kjenner og følger de fastlagte rutiner som gjelder for slik bruk Ansvar og myndighet for den medarbeider som har det overordnede operative ansvar for å implementere og vedlikeholde EDI-løsningen skal fremgå av stillingsbeskrivelse. Ansvar og myndighet for øvrige medarbeidere som har innvirkning på arbeidet med EDI skal fremgå av stillingsbeskrivelse i den grad dette er nødvendig for å oppnå tilfredsstillende informasjonssikkerhet. 21

26 VEILEDNING : EDI I HELSESEKTOREN Konfigurasjon Konfigurasjonskontroll Utstyr og programvare benyttet i EDI-løsningen skal konfigureres slik at tilfredsstillende informasjonssikkerhet oppnås. Utstyr og programvare skal inngå i helseinstitusjonens konfigurasjonsoversikt. Dette gjelder også utstyr og program benyttet for kryptering, digital signatur o.l. Konfigurasjonsendring Konfigurasjon av utstyr eller program benyttet for EDI skal bare endres gjennom fastlagte rutiner og prosedyrer som gir tilstrekkelig dokumentasjon og sporbarhet, og gjennom dette være underlagt godkjenning fra helseinstitusjonens ledelse. Administrative og tekniske rutiner Arbeidet med EDI skal utføres i henhold til fastlagte rutiner. Slike rutiner skal angi: Tillatt bruk av EDI, herunder rutiner for tilkopling og dataoverføring. Godkjenning og implementering av meldingsprofiler, herunder fjerning av profiler som ikke lenger benyttes. Godkjenning av adresser for mottak og sending - herunder vedlikehold av adresselister - med krav om entydig kopling mellom adresse og fysisk person eller virksomhet. Drift og vedlikehold av utstyr og programmer som benytte i EDIløsningen. Opplæring av brukere og personer som på annen måte har innvirkning på arbeidet med EDI. Beredskapsplanlegging Personnell Helseinstitusjonens ledelse må vurdere behovet for, og eventuelt utpeke stedfortreder for den medarbeider som er gitt det overordnede operative ansvar for å implementere og vedlikeholde EDI-løsningen Planlegging mht utilsiktet avbrudd I den grad EDI er nødvendig for helseinstitusjonens behandling av personopplysninger, skal det utarbeides rutiner for alternative løsninger når normal metode for EDI ikke er tilgjengelig. En slik løsning kan være å 22