Sikkerhets-problematikk i helsesystemer (en introduksjon) Tor Erlend Fægri, SINTEF

Introduksjon Helsevesenet ønsker bedre effektivitet Knapphet på ressurser Bare 1 av 4 timeverk er “pasient-timer” Mer kompliserte prosesser, større forbruk av informasjon Trenger raskere tilgang til informasjon Helsevesenet hindres av IT-systemer som ikke samarbeider Helsepersonell må benytte flere systemer for å finne informasjon eller gjøre oppgavene sine Lite gjenbruk av informasjon mellom systemer

Noen utfordringer (1) Stort antall eksisterende systemer Behov for skalerbare metoder Mange lukkede og proprietære sikkerhetsmekanismer Sikring av applikasjoner, ikke informasjon Dedikerte databaser og/eller programsystemer Få systemer er tilpasset gjenbruk og felles sikkerhets-moduler Ønsker om mobile løsninger, f.eks. hjemme-omsorg Strenge sikkerhetsregler kompliserer integrasjon Datatilsynet krever minst to sikkerhetsbarrierer for systemer som behandler sensitiv informasjon og som også har tilgang til Internett F.eks. brannmur og SSL

Noen utfordringer (2) Endel behandlingsformer omfatter en lang rekke instanser innen helse- og sosialsektoren Øker behovet for informasjonsflyt mellom systemer Nye samarbeidsformer (flere samtidige aktører) Nye forskrifter stiller krav til samhandling om pasienter med langvarige behandlingsbehov Pasienten skal “settes i sentrum” Gjerne hjemmefra eller fra omsorgs-senter

Noen utfordringer (3) Leverandører har ikke vært særlig motiverte for å bygge åpne systemer Få motiverende tiltak “Monopol-tankegang” (men monopolistene snakker gjerne med seg selv..) Store gap mellom løsnings-metoder i offentlig og privat sektor Mange leverandører sikter mot offentlig (dvs. sykehus) ELLER privat (dvs. allmenpraktiserende og spesialister) Systemer representative for de to sektorene har naturlig nok vidt forskjellig syn på skalerbarhet, arkitektur m.v.

Et vanlig situasjonsbilde Sikkerhets- sone Sikkerhets- sone App. 1 App. 2 Konv. DB1 Manuellt (brev, fax osv.) Halv-automatisk (f.eks. e-mail) DB2

Sikkerhetsaspekter Kvalitet og integritet Tilgjengelighet Informasjonen må være korrekt, relevant, tidsriktig og komplett Tilgjengelighet Autoriserte brukere er sikret adgang (aksesskontroll, blålysfunksjonalitet) Konfidensialitet Informasjonen skal ikke være tilgjengelig for uatoriserte brukere (f.eks. regler satt av personvernet) Mer enn tilgjengelighet -1 (bør dekke innbrudd osv.) Informasjonen er dog ikke særlig nyttig hvis den ikke kan deles med noen! Loggføring Kan gi god preventiv effekt

Vurdering av sikkerhetsrisiko (rangert USA, 1997) 1. Internt: Tilfeldige brukerfeil (gjenglemt informasjon, overhørte samtaler osv.) 2. Internt: Nyskjerrighet 3. Internt: Tyveri 4. Internt/eksternt: Brukere i andre deler av organisasjonen benytter informasjon til andre formål enn tiltenkt (f.eks. legemiddelfirma, personal-avd.) 5. Eksternt: Innbrudd

Håndtering av risiko (1) Erfaring tilsier at utdanning og holdingskapende arbeid er effektivt virkemiddel mot mange interne “tilfeldige lekkasjer” Helsepersonell er allerede underlagt strenge etiske retningslinjer ifbm. utdanning og yrkesutførelse Stort problem med dårlige passord (og gule lapper..) Spesielt innen helsevesenet gjelder det å sørge for at brukerne får brukervennlige og fleksible løsninger Høyt tidspress fører over til “slurv” og at IT-relaterte oppgaver nedprioriteres Tungvindte systemer blir ikke brukt

Håndtering av risiko (2) Aksesskontroll (rollebasert for skalerbarhet) Ifbm. myndiggjøring av pasienter trengs funksjonalitet av typen “gi min spesialist mm adgang til all dokumentasjon om meg som omfatter mitt problem pp. Videre ønsker jeg å trekke tilbake alle rettigheter fra min tidligere fastlege ff”. Autentisiering X.509 v3 / LDAP / PKI / SmartCard Kryptering PKI Nettverk beskyttes med IDS(er)

Elektroniske signaturer og kryptografi Den største utfordringen er organisering og implementering av sertifikat-myndighet Helsepersonellregisteret (administrert av Helsetilsynet) inneholder allerede en database over alle personer i Norge med autorisasjon for helse-relatert arbeid Kan bli CA, evt. opptre som en RA for en/flere CA’er Trenger effektive rutiner for å ugyldigjøre sertifikater F.eks. OCSP (Online Certificate Status Protocol), eller Certificate Revokation List (CRL) I tillegg trengs en ekstern TTP for registrering av pasienter og andre involverte utenfor helsenettet Hvis Helsetilsynet opptrer som CA kan sertifikater kryss-sertifiseres mot ekstern CA/TTP.

Systemarkitektur (ønsket situasjon) Brukere: Helsepersonell og pasienter Sikkerhetssone EPJ Patologi PAS Røngten Sikkerhet styrt av: Roller Person/ID Organisasjon Sikkerhets-mekanismer DB1 DB2 DB3

Eksempel: Planbasert samarbeidsjournal for helse og omsorg Prosjekt igangsatt i samarbeid med IT-leverandør, SINTEF og pilot-kunde Finansert via Norges Forskningsråd Mål med prosjektet Finne fram til metoder og løsninger for samarbeid om individuelle planer mellom mange aktører Funksjonalitet for autorisasjon, adgangskontroll og autentisering i distribuerte og heterogene helsesystemer

Systemarkitektur (tenkt løsning) Vurderer pasient nn 3. Vil gjerne ha tidligere historikk på pasient nn av deg SSL/IPsec (f.eks. SOAP over SSL) App. x App. y 6. Overfør historikk 1. Informasjon om nn ligger ikke her.. 5. Hent historikk XML-dokument med opplysninger om nn (kryptert) DB1 DB2 4. Autorisasjon (LDAP) 2. Autorisasjon (LDAP) X.509 Replika #1 Replika #2

Kommentarer Arkitekturen gir oss ikke automatisk informasjons-sentriske systemer Men XML bidrar til å åpne applikasjonene Men hver applikasjon kan utvides med funksjonalitet for å sende fra seg informasjon Sålenge denne informasjonen er godt dokumentert vil hvem som helst kunne ha mulighet til å integrere seg mot applikasjonen Men sikkerheten i kommunikasjonen kan ivaretas Er et godt utgangspunkt for ekperimentering med samhandling mellom helseinformasjonssystemer Trenger i tillegg støtte for lokalisering av informasjon (informasjonstjeneste) Kanskje også i X.500 katalogen?

Åpne spørsmål og kritiske faktorer (arkitektur) Delegerings-mekanismer Håndtering av autentisering på vegne av andre (også på vegne av andre systemer) X.509 støtter såkalt “referrals” Bruker-, rolle- og applikasjonssertifikater Mekanismer for caching (evt. retningslinjer for granularitet) Data-aksess kan bli uforholdsmessig kostbart hvis hver forespørsel må autentiseres via LDAP og X.509 katalog på annen maskin Kanskje ikke alltid mulig pga. sikkerhets-risiko.. Tekniske bindinger til SW-plattform, Microsoft .NET, Java, CORBA etc. F.eks. støtter .NET direkte generering av XML dokumenter fra databasen, mens dette må gjøres mer eksplisitt i andre plattformer

Kritiske faktorer (innføring) Lav terskel for brukerne Hvor mye av sikkerhetfunksjonaliteten kan skjules (og/eller automatiseres) av systemet? Lav kostnad.. Gjenbrukbare komponenter Bred anvendbarhet i flere applikasjoner Hvordan vil standardardiseringsarbeidet for samhandling mellom EPJ, PAS m.v. utvikle seg? XML er valgt som informasjons-format (Helseallmenningen) - men det er teorien.. Trenger enighet innen helsevesenet om sertifikat-autoriteter

Referanser Helseallmenningen, “Felles plattformer og komponenter for helseinformasjonssystemer”, sept. 2000 KITH, “Grensesnitt mellom behandlingsretta informasjonssystemer”, april 2000 NST, “Sikkerhetsmodul i IKT-baserte pasient-tjenester”, febr. 2001 NST, “Sikkerhetsaspekter ved nettbasert tilgang til pasientinformasjon”, mai 2001 KITH, “SESAM: Bruk av digitale signaturer og offentlig nøkkelkryptografi”, febr. 2001 IETF, “RFC 2807 - XML signature requirements”, juli 2000