Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "Sikkerhets-problematikk i helsesystemer (en introduksjon) Tor Erlend Fægri, SINTEF."— 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 Sikkerhets- sone Sikkerhets- sone Et vanlig situasjonsbilde DB1DB2 App. 1 App. 2 Konv. Manuellt (brev, fax osv.) Halv-automatisk (f.eks. )

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 Sikkerhetssone Systemarkitektur (ønsket situasjon) PAS EPJ Røngten Patologi DB1DB2DB3 Sikkerhet styrt av: Roller Person/ID Organisasjon Sikkerhets-mekanismer Brukere: Helsepersonell og pasienter

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 SSL/IPsec Systemarkitektur (tenkt løsning) App. x X.509 DB1 App. y DB2 3. Vil gjerne ha tidligere historikk på pasient nn av deg XML-dokument med opplysninger om nn (kryptert) 5. Hent historikk 6. Overfør historikk 1. Informasjon om nn ligger ikke her.. Vurderer pasient nn (f.eks. SOAP over SSL) 2. Autorisasjon (LDAP) 4. Autorisasjon (LDAP) 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 KITH, “Grensesnitt mellom behandlingsretta informasjonssystemer”, april 2000 NST, “Sikkerhetsmodul i IKT-baserte pasient-tjenester”, febr NST, “Sikkerhetsaspekter ved nettbasert tilgang til pasientinformasjon”, mai 2001 KITH, “SESAM: Bruk av digitale signaturer og offentlig nøkkelkryptografi”, febr IETF, “RFC XML signature requirements”, juli 2000


Laste ned ppt "Sikkerhets-problematikk i helsesystemer (en introduksjon) Tor Erlend Fægri, SINTEF."

Liknende presentasjoner


Annonser fra Google