Sikkerhets-problematikk i helsesystemer (en introduksjon)

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

2. 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

3. 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

4. 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

5. 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.

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

7. Sikkerhetsaspekter • Kvalitet og integritet • 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

8. 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

9. 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

10. 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)

11. 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.

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

13. 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

14. Systemarkitektur (tenkt løsning) 3. Vil gjerne ha tidligere historikk på pasient nn av deg Vurderer pasient nn 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

15. 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?

16. Åpne spørsmålog 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

17. 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

18. 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