Sikkerhets-problematikk i helsesystemer (en introduksjon)

Presentasjon om: "Sikkerhets-problematikk i helsesystemer (en introduksjon)"— Utskrift av presentasjonen:

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. 1 App. 2 Konv. DB1 Manuellt (brev, fax osv.) Halv-automatisk (f.eks. ) DB2

7 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

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

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

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å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

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 XML signature requirements”, juli 2000