Risikovurdering av Ny Felles Publiseringsløsning 2.0

Transkript

1 Prosedyre IT-risikovurdering Versjon SP/ Risikovurdering av Ny Felles Publiseringsløsning 2.0 Løsning Ny felles publiseringsløsning 2.0 Utarbeidet av Ingvild Fasting og Geir Hovind, Sykehuspartner, Ketil Heggtveit, Secode Delprosjekt Hovedprosjekt Prosjektleder Visar Beqiri, 1 Kartlegging Introduksjon Begrunnelse for endring Avgrensninger Systembeskrivelse Arkitektur Teknologi Sikkerhetsmekanismer Dataflyt Aktører Tilganger Informasjonsaktiva Databehandling Identifisere tekniske sårbarheter, andre svakheter og tilhørende trusselscenarioer Vurdering Risikohåndtering Aksepterte hendelser Hendelser med definerte tiltak Kapittel 5 Appendix... 25

2 1 Kartlegging 1.1 Introduksjon Denne risikovurderingen har 3 fokusområder: a) risiko som følge av åpning for å overvåke løsning i et eksternt miljø b) risiko ved bruk (roller, rettigheter, godkjenningsprosesser mv) c) risiko for kompromittering av løsningen (teknisk svakheter, configurasjon og lignende) Punkt a og b dekkes i denne risikovurderingen. Punkt c dekkes også i risikovurderingen, og av en gjennomført penetrasjonstest. Rapporten finnes som eget vedlegg, og hovedkonklusjonene er presentert i appendix, i kapittel 5. Vurderingen baseres på følgende fremlagte dokumentasjon: Funksjonelt løsningsdesign, versjon 0.5, datert Teknisk løsningsdesign, versjon 0.4, datert Teknisk løsningsdesign, arbeidsversjon mottatt Forprosjektanalyse, versjon 1.3, datert Prosjektdirektiv, versjon 1.1, datert Penetrasjonstest Sykehuspartner, versjon 1.0, datert Om løsningen (formål og hensikt) Felles Publiseringsløsning (FPL) er en felles regional løsning for publisering av innhold på internett. Sykehuspartner forvalter og tilbyr løsningen til det enkelte helseforetak. FPL 2.0 er en oppgradert løsning på ny plattform, med større grad av standardisering og modernisering av utseende og innhold. Løsningen må fortsatt forholde seg til de krav og føringer som stilles i HOD rammeverket for nettbasert kommunikasjon. Anskaffelsen av FPL har som hovedformål å gi tilhørende helseforetak et felles verktøy for publisering. Løsningen er basert på et nasjonalt rammeverk. Ny FPL planlegges basert på SharePoint 2013 med drift i nettsky, levert av Windows Azure. For ytterligere begrunnelse for hensikt og formål, henvises det til forprosjektanalyse og prosjektdirektiv Begrunnelse for endring FPL driftes i dag av Norsk Helsenett og har vært vedlikeholdt av Evry. Sykehuspartner forvalter og tilbyr løsningen til det enkelte foretak. 12 foretak benytter løsningen (inkludert Sykehuspartner og Sykehusapotekene). Siden løsningen ble satt i drift har det oppstått store utfordringer med ytelse og ustabilt driftsmiljø, manglende miljøer for verifisering av endringer før produksjonssetting og en rekke feil i den egenutviklede delen av løsningen, spesielt i integrasjonen mot 3.parts produktene. Løsningen har også vist seg å ikke være så fleksibel som forventet. Videre er løsningen med Microsofts skytjenester valgt for å få en mer kostnadseffektiv løsning. En oppgradert Sharepoint-løsning fra Sykehuspartner forventes da å gi følgende fordeler: Redusere reelle kostnader for drift og applikasjonsforvaltning Øke stabilitet og ytelse på løsningen Kraftig forbedret brukeropplevelse for redaktører Økt bruker opplevelse for besøkende brukere med økt ytelse og stabilitet. I tillegg mer oppdatert og høyere kvalitet på innholdet, mer helhetlig og oppdatert design Bedre støtte for universell utforming Avgrensninger RoS-analysen forholder seg til prosjektets avgrensninger. Følgende avgrensninger er identifisert for prosjektet: Eksisterende design for FPL 1.0 er retningsgivende for FPL 2.0 (denne risikovurderingen), da en full redesign av løsningen er utenfor omfanget av prosjektet. 2

3 Det redaksjonelle ansvaret ligger hos HF ene, og er ikke SP sitt ansvar. Risiko knyttet til mulig feil bruk vil likevel bli påpekt, og foretakene må vurdere rutiner for å kompensere for slike feil. Det er ingen integrasjon mot andre fagsystemer per i dag, kun drifts- og overvåkningstilgang (dette vurderes spesielt) Det skal kun lagres åpen informasjon i løsningen, dvs klassifiseringsnivå 1 (kontekst 1) informasjon. Det anses derfor heller ikke som nødvendig å etablere noen databehandleravtale Den merkantile avtalen med Microsoft vurderes ikke. Tilgjengelighet blir likevel adressert, men kravet er lavt, og det gjøres derfor ingen kontroll av om teknisk realisering dekker behovet. Det gjøres likevel en teknisk sikkerhetstest for å se om miljøet i skyen kan innebære en trussel mot drift og overvåknings-miljøet i SP 1.2 Systembeskrivelse Risikovurderingen ser design og systembeskrivelsen i lys av informasjonssikkerhet. Dette betyr at design blir vurdert opp mot hvordan løsningen er klassifisert innen de tre områdene konfidensialitet, integritet og tilgjengelighet. Konfidensialitet, integritet og tilgjengelighet blir klassifisert på en skala fra 1 til 4, der klasse 4 er mest kritisk. (Dette i motsetning til SLA-nivå for tilgjengelighet som bruker motsatt skala fra 3 til 1). Ekstranett har konfidensialitet og integritet i klasse 1, dvs. åpen informasjon. Løsningen hostes av Microsoft, og katastrofer håndteres i henhold til SLA for de forskjellige tjenestene og avtalen mellom Windows Azure og Sykehuspartner. Tjenesten vil ikke være tilgjengelig ved brudd på internettlinjer. Den generelle skytjenesten er mer tilgjengelig enn en intern tjeneste fordi den kan nås fra alle som har tilgang til internett, og fra ulike enheter og plattformer enn den interne. Nedetiden til en skytjeneste er nesten lik null. Løsningen er videre ikke tenkt brukt som en skredside, og kravene til tilgjengelighet er derfor ikke kritiske. Tilgjengelighet i løsningen er klassifisert som 3 ikke kritisk Arkitektur FPL 2.0 er basert på SharePoint 2013 og kjøres i Microsoft sine skytjenester. Løsningen driftes i virtuelle servere i Windows Azure IaaS (Infrastructure as a Service). Den nye løsningen settes opp som en høytilgjengelig løsning, etter ny beste praksis for oppsett av SharePoint-farmer. Løsningen består av en SharePoint-komponent og en Office Web Applications komponent. Office Web Apps gir visning av Office dokumenter i nettleser. Funksjonaliteten brukes for forhåndsvisning i søk, tilgjengeliggjøre for mobile enheter, osv. SharePoint-arkitekturen er en typisk trelags-arkitektur: Front end lag, som betjener brukerne Applikasjonslag for indeksering og andre backend-operasjoner Datalag, som er et sett SQL databaser Løsningen settes opp slik at den forholdsvis enkelt kan flyttes til en eventuell privat skytjeneste. 3

4 En skisse over arkitekturen vises under i figur 1, hentet fra teknisk løsningsdesign, arbeidsversjon. Den nye løsningen baserer seg i stor grad på metadata for å klassifisere innhold i løsningen og gi alternative navigasjonsmuligheter for brukerne. Metadata legger på ekstra informasjon om hver artikkel, men har flere bruksområder og betydning. Videre er det tre dimensjoner av kontroll av metadata: Nasjonalt styrt: Utenfor HSØ sin kontroll, felles for alle foretakene, Eks MeSH Regionalt styrt: Kontrollert i fellesskap i HSØ, felles for alle foretakene Lokalt styrt: Kontrollert av hvert enkelt foretak. Kan ikke deles. Mer utfyllende informasjon om arkitektur og teknologi finnes i designdokumentene, bl.a.: Funksjonelt løsningsdesign Teknisk løsningsdesign 4

5 SCOM gateway Discovery probe Teknologi Produksjonsmiljøet er segmentert i ulike deler, som vist i figur 2, hentet fra teknisk løsningsdesign, arbeidsversjon. Anonyme brukere fra internett Helseforetak Redaktører fra kjente nett HTTP Port 80 Internett HTTP Port Internett HTTPS Port Listener for Publiserings-admin HTTP Port 80 HTTP Port 80 HTTPS Port 443 Front-end servers..... Publiserings-admin DNS FPLprodOWA..... Batch-processing and application servers FPLprodAdmin DNS Brukerkatalog FPLprod All databases Alle maskiner FPLprodSQL FPLProd subnet HTTP-protokoll HTTPS-protokoll Intern nettverkstrafikk i FPL RDP port 335 SCOM monitorering port 5273 Ukjent CloudService Virtuelt subnet?? VPN tunnel Windows Azure Lastbalanserer Listener Sykehuspartner DIGIPLEX Bruker-forvaltning Drift Overvåking System Center Operations Manager 5

6 Miljøer og Windows Azure Løsningen vi i sin helhet plasseres i Azure IaaS, uten kobling tilbake til Sykehuspartners nettverk på det tidspunktet løsningen etableres. Det kan på et senere etableres en slik kobling om dette er ønskelig. Som standard er Azure IaaS et lukket miljø med minimalt tilganger. Tjenestene er tilgjengelig via pålogging på Windows Azure portalen. Abonnementet er beskyttet av brannmur, osv som del av Windows Azure tjenesten. Løsningen vil bestå av fire miljøer, Produksjon, QA, Test og Utvikling. Disse fire miljøene vil etableres i hvert sitt Azure underabonnement. Dette gjøres for å holde miljøene adskilt med separate tilganger og for å kunne måle forbruk av tjenester pr miljø. Hovedabonnement Underabonnement Produksjon Underabonnement QA Underabonnement Test Underabonnement Utvikling Figur 4: Abonnement struktur (teknisk løsningsdesign) Hvert enkelt vil ha sin separate infrastruktur med katalog-, navne-, database- og publiseringstjenester. Dette muliggjør total separasjon av miljøene slik at miljøene ikke påvirker hverandre. Produksjonsmiljøet QA Testmiljøet Utviklingsmiljøet Opplæringsmiljøet Vil kjøre kontinuerlig fra systemtest og fremover Kjører fra systemtest og fremover, kan stoppes når det ikke er i bruk Brukes i prosjektperioden, og vil i større grad være avslått i etterkant Brukes i prosjektperioden, men vil nedskaleres etter prosjektet og i stor grad være avslått Foreslås som en del av produksjonsmiljøet For mer informasjon om infrastruktur og Windows Azure henvises til kildedokumenter Sikkerhetsmekanismer Brukerhåndtering Brukeridentiteter lagres i egen brukerkatalog i løsningen i Windows Azure abonnementet. En egen Active Directory benyttes for brukerkatalogen. Opprettelse og håndtering av brukere med informasjon og passord forvaltes av applikasjonsforvaltning. Alle endringer meldes inn. Det er ingen selvbetjening på passordbytte, men følger samme prosess som i FPL 1.0 hos NHN. Autentisering (Authentication) håndteres av Active Directory. Autorisering håndteres av SharePoint

7 Redaktørpålogging Redaktører logger seg på via egen URL (eksempel ) over en kryptert kobling (HTTPS). Det er kun pålogging fra klienter i godkjente nett som får adgang til å logge på. Godkjente nett verifiseres ved hjelp IP-adresse til klienten. Liste over godkjente nett konfigureres i Windows Azure abonnementet (Access Controll Lists). Redaktørene logger seg på og arbeider på en egen server, uavhengig av de anonyme brukerne. En skisse av redaktørpålogging vises under i figur 5 (teknisk løsningsdesign, arbeidsversjon): Helseforetak OUS CloudService HTTP-protokoll HTTPS-protokoll Intern nettverkstrafikk i FPL AHUS Virtuelt subnet RDP port 335 SCOM monitorering port 5273 Redaktører fra kjente nett Windows Azure Ukjent VPN til foretak SIKT Lastbalanserer Listener HTTPS Port 443 1x Innlandet Internett Listener for Publiserings-admin Listener for Publiserings-admin SAP HTTPS Port 443 Internett VPN Publiserings-admin Hjemmekontor DNS FPLprodAdmin DNS Brukerkatalog Nummerering av behandlingsløp: FPLProd subnet 1x Bruker tilgang fra interne nett Tilgang begrenses utfra IP-adresser på avsender. Konfigurasjon av IP-adresser utføres i Windows Azure på «listener». 7

8 Brukerforvaltning Brukerforvaltning utføres av forvalter i administrative applikasjoner. Forvalter logger seg på brukerkatalogen ved hjelp av RDP (Remote Desktop) via en VPN-tunnel til Windows Azure abonnementet. Arbeid mot brukerkatalogen er ikke eksponert mot internett. Brukerhåndtering er vist i figur 6 (teknisk løsningsdesign, arbeidsversjon). DNS DNS Brukerkatalog FPLProd subnet VPN tunnel HTTP-protokoll HTTPS-protokoll Intern nettverkstrafikk i FPL RDP port 335 SCOM monitorering port 5273 Ukjent CloudService Virtuelt subnet Sykehuspartner DIGIPLEX Bruker-forvaltning Windows Azure Lastbalanserer Listener Dataflyt Det er ingen integrasjon med andre løsninger eller fagsystemer i denne fasen utover drifts- og overvåkningstilgang Aktører Aktører i dette prosjektet er: Sykehuspartner (Prosjektgruppe) Helse Sør-Øst (Bestiller) 8

9 Microsoft (Leverandør) Tilganger Opprettelse og håndtering av brukere med informasjon og passord forvaltes av applikasjonsforvaltning. Alle endringer meldes inn. Det er ingen selvbetjening på passordbytte, men følger samme prosess som i FPL 1.0 hos NHN. Autentisering håndteres av Active Directory. Autorisering håndteres av SharePoint Redaktørtilgang tildeles på generelt nivå og følges opp av Sykehuspartner, nærmere bestemt applikasjonsforvalter for FPL-løsningen. I tillegg vil det være foretakenes ansvar å spesifisere evt brudd på rettigheter og tildeling av spesielle rettigheter. Dette følger tilsvarende rettighetsnivåer og administrering som i dagens løsning. Nye brukere/endring i eksisterende brukere meldes via Min Sykehuspartner / brukerstøtte Informasjonsaktiva Løsningen klassifiseres i sone 1, som åpen informasjon. Det vil derfor ikke være noe krav om skille mellom helseforetakene. Krav til tilgjengelighet i henhold til kritikalitet/viktighet er vurdert som 3 ikke kritisk Databehandling Løsningen inneholder kun nivå 1 informasjon, og det anses derfor ikke som nødvendig med en egen databehandleravtale med Microsoft. 9

10 2 Identifisere tekniske sårbarheter, andre svakheter og tilhørende trusselscenarioer Tekniske sårbarheter og andre svakheter må identifiseres for å kunne avgjøre sannsynligheten for at en hendelse inntreffer. Andre svakheter er av ikke-teknisk art og har årsak i menneskelige, miljømessige eller organisatoriske forhold. Trusselkilder som er aktuelle her er for eksempel miljømessige sårbarheter eller personer med god hensikt. Et trusselscenario er en beskrivelse av hvordan en sårbarhet/svakhet kan utnyttes. Ved å utarbeide trusselscenarioer dokumenterer man hvordan sårbarheter som danner et trusselscenario kan føre til at en hendelse inntreffer. Et trusselscenario kan være basert på en eller flere sårbarheter, og en sårbarhet kan danne grunnlag for ett eller flere trusselscenarioer. Tekniske sårbarheter og andre svakheter må identifiseres for å kunne avgjøre sannsynligheten for at en hendelse inntreffer. Tabellen under er sortert etter de tre områdene beskrevet innledningsvis: a) risiko som følge av åpning for å overvåke løsning i et eksternt miljø b) risiko ved bruk (roller, rettigheter, godkjenningsprosesser mv) c) risiko for kompromittering av løsningen (teknisk svakheter, configurasjon og lignende) # Område Sårbarheter / andre svakheter Mulige trusselscenarioer/mulige konsekvenser 1. a) Lokal overvåkingsnode 2. a) Mangel på lokal brannmur 1 Alle servere i FPL løsningen skal overvåkes og sender overvåkningsdata til node lokalt i LAN. Trussel er dersom denne overvåkningsnoden kan medføre kompromittering av SP miljø. 2 Mangel på lokal brannmur (i HF) fører til eksponering av lokale tjenester i Azuremiljøet. 3. b) Vanskelig kontroll/overvåkning av informasjon som legges ut 3 Informasjon i kontekst 2, 3 eller 4 kan legges ut uten at det blir oppdaget. Dette kan føre til brudd på konfidensialitet, da løsningen ellers kun skal inneholde åpen informasjon. 4. b) Mulighet til å endre i 4 10

11 # Område Sårbarheter / andre svakheter Mulige trusselscenarioer/mulige konsekvenser 5. b) dokumenter uten at det oppdages Manglende tilrettelegging for universell utforming Ved manglende dokumentkontroll kan uønskede og uautoriserte endringer bli gjennomført. Kan føre til brudd på integritet, konfidensialitet og sporing. 5 Ved manglende støtte for universell utforming i den redaksjonelle prosessen og støtte i teknisk løsning kan medføre at forskriften ikke ivaretas, jfr (trådte i kraft 1. juli 2013) 6. b) Manglende tilgangskontroll 6 Manglende oversikt over gyldige brukere og hvem som skal ha tilgang, uautorisert publisering på vegne av andre HF enn man skal ha rettigheter til. 7 b) Utilstrekkelig administrasjon av Windows Azure abonnement 7 Private Windows Live ID brukes for administrering av Windows Azure abonnementet, øker sannsynligheten for kompromittering 8. b) og c) 9 b) og c) 10. b) og c) 11 c) Ikke oppdatert eller manglende antiviruskontroll Brukernavn og passord til web redaktører Overføring av informasjon ved migrering fra gammel tjeneste Mangelfull herding og patching av servere i FPL 2.0 miljøet 8 Infiserte maskiner hos web-redaktører kan spre malvare til FPL miljøet uten at det oppdages Manglende passord policy for webredaktørene kan føre til kompromittering 9.2 Ukryptert pålogging eksponerer brukernavn og passord Utfordringer ved å hente informasjon fra eksisterende database, tid og kostnad øker. 90 % gjøres automatisk, 10 % manuelt Informasjon som ikke skal være med blir med over fra gammel database, eks i kontekst 3 og Mangelfull herding og patching kan eksponere serverne for sikkerhetssvakheter som ikke lett lar seg detektere 11

12 # Område Sårbarheter / andre svakheter Mulige trusselscenarioer/mulige konsekvenser 12 c) 13 c) 14 c) Fjerntilgang av servere i Windows Azure miljøet Uautorisert tilgang til applikasjonen Informasjonssikkerhet ved lagring i nettskyen (hentet fra Cloud Security Alliance (CSA)- guide, versjon 3.0) 12 Servere blir ikke installert etter SP s interne rutiner 13.1 Remote Desk Top tilgjengelig over internett 13.2 Powershell tilgjengelig via HTTP 13 Feilkonfigurasjon av web-redaktørenes tilgang, feil i programvare eller feil i FPL applikasjonen kan medføre uautoriserte brukere får tilgang til å endre på data innhold i FPL applikasjonen Leverandørens infrastruktur oppfyller ikke norske lovkrav Adminbrukere hos cloudleverandør får uønsket tilgang til sensitiv informasjon for virksomheten 14.3 Manglende kontroll på fysisk lokasjon 14.4 Manglende bruk av skillemekanismer hos skyleverandør 14.5 Tjenesten slutter å virke og data går tapt på grunn av manglende backup/restore hos leverandør 14.6 Manglende tilgang til data ved undersøkelse av hendelser, f.eks. logger 14.7 Skyleverandør går konkurs eller blir kjøpt opp, kan føre til tap av data/manglende tilgang til data Penetrasjons- og sikkerhetstesten avdekket videre enkelte svakheter som bør adresseres før produksjonssetting. Disse svakhetene vil ikke bli gjort gjenstand for nivå på risiko, men det vil bli presentert foreslåtte tiltak i kapittel 4.2, med henvisning til rapportens hovedkonklusjoner i kapittel 5, og rapporten i sin helhet i vedlegg. Mange tilgjengelige tjenester RDP tjenesten tilgjengelig fra Internett Selvsignerte sertifikater Svake kryptonøkkler 12

13 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 3 Vurdering Se forklaring, inkludert tabeller for beregning av sannsynlighet og konsekvens i dokumentet Metodikk for risikovurdering. Risiko beregnes som produktet av sannsynlighet og konsekvens. All risiko over 6 ligger utenfor akseptkriterier. Begrunnelse må gis konkret mot hvert trusselscenario, slik at det er mulig å følge hva som er sikret tilstrekkelig og hvorfor. 1 Lokal overvåkningsnode Tilgang til SP s driftssenter og interne servere Full kompromittering av Sykehuspartner. K, I,T Sannsynligheten vurderes svært lav fordi trafikken kun skal initieres fra SP. 2 Mangel på lokal brannmur Ved mangel på brannmur eksponeres tjenester på lokalnettet. En kompromittert maskin har lettere tilgang på andre maskiner K Sannsynligheten vurderes svært lav da lokale brannmurer skal etableres. 3 Vanskelig kontroll/overvåkning av informasjon som legges ut Informasjon i kontekst 2, 3 eller 4 legges ut uten å bli oppdaget. Brudd på konfidensialitet, sensitiv informasjon gjøres tilgjengelig. K Ved utilstrekkelig kontroll og veiledning i hvilken informasjon som er hvilken kontekst er det vurdert forholdsvis sannsynlig at sensitiv informasjon kan bli delt. Planlagt håndtert i Data Loss Prevention Prosjektet (løsning ikke realisert). JA 01 13

14 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 4 Mulighet til å endre i dokumenter uten at det oppdages Manipulasjon av informasjon, uønskede og uautoriserte endringer gjennomføres. Brudd på integritet og konfidensialitet, og sporing. K, I, S Konsekvensen er satt ut ifra et worstcase scenario, der endringene skjer i dokumenter av stor betydning. Løsningen har i dag en etablert håndtering for versjonshistorikk, og sannsynligheten for brudd er derfor vurdert lav. 5 Manglende tilrettelegging for universell utforming Tilsyn fra DIFI, anmerkning. Lovpålagt fra 1. juli Ikke en risiko for informasjonssikkerhet men generelt ved at forskriften ikke oppfylles Prosjektet vil ivareta kravet til universell utforming. Pt under testing, og inngår som del av akseptansetest. Risiko anses derfor som ivaretatt. 6 Manglende tilgangskontroll av publikasjonsrettigheter Manglende oversikt over gyldige brukere og hvem som skal ha tilgang. Konsekvensen kan være at brukere uten et legitimt behov får, og beholder tilgang til å publisere etc. K Det er foretakenes eget ansvar å tildele og forvalte spesielle rettigheter, på generelt nivå bestemmes dette av Sykehuspartner. Redaktørrollene følges opp av applikasjonsforvalter. Følger de samme rettighetsnivåene og administering som i dagens løsning. 14

15 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 7 Utilstrekkelig administrasjon av Windows Azure abonnement Administrasjon av Windows Azuremiljøet utføres med windows live ID som tilhører personlige brukere. Personlige brukere brukt i forbindelse med arbeide kan utsette miljøet for en risiko ved at passord ikke er like godt beskyttet. Kan føre til brudd på konfidensialitet og integritet. K, I Vurdert lav da SP etablererer dedikerte Windows Live ID for tjenesten. Konsekvensen ville potensielt vært tilgang til andre servere i Azure-miljøet. 8 Ikke oppdatert eller manglende antiviruskontroll Spredning av malvare på nettverket Kan føre til virusinfiserte maskiner, kan føre til kompromittering av alle handlinger. K, T Konsekvensen vurderes høy da man kan risikere full brukertilgang ved kompromittering. Sannsynligheten vurderes forholdsvis lav da rutiner for antiviruskontroll forventes implementert. Inntil verifisert ivaretatt settes risiko til 8. JA Manglende passord policy (passord policy til web-redaktørene) Uautorisert tilgang til brukernavn og passord, som gir tilgang til applikasjonen Mulighet for tilgang til publisering, brudd på konfidensialitet og integritet K, I Sannsynligheten vurderes lav da det kun er dedikerte maskiner hos HF ene som kan logge seg på. Konsekvensen er potensielt høy da en kompromittering vil gi redaktørtilgang. 15

16 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 9.2 Manglende kryptering på webredaktører Web-redaktørens brukernavn og passord går i klartekst mellom STHF og eksterne virksomheter (herunder inkludert Betanien Hospital). Dersom brukernavn og passord ikke beskyttes tilstrekkelig vil andre kunne logge seg på og publisere/endre informasjon dersom uvedkommende utfører man-in-the-middle angrep. K, I, Sannsynligheten vurderes lav da påloggingen skal skje kryptert (kun tillate pålogging via HTTPS, ingen redirect fra port 80). Konsekvensen er potensielt høy da en kompromittering vil gi redaktørtilgang Overføring av informasjon ved migrering fra gammel tjeneste Utfordringer ved å hente informasjon fra eksisterende database, 90 % gjøres automatisk, 10 % manuelt. Tid og kostnad øker dersom den automatiske migreringen ikke er tilfredsstillende Sannsynligheten er vurdert forholdsvis lav da den gitte migreringsplanen skal fange opp nødvendig behov. 16

17 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 10.2 Overføring av informasjon ved migrering fra gammel tjeneste Informasjon som ikke skal være med blir med over fra gammel database, eks intern informasjon i kontekst 2. Ved mangel på manuell kontroll kan HF spesifikk informasjon (kontekst 2 intern informasjon) overføres til den nye løsningen. K Konsekvensen er vurdert forholdsvis lav da løsningen ikke skal inneholde person- eller virksomhetssensitiv informasjon. 11 Mangelfull herding og patching av servere i FPL2.0 miljøet Mangelfull herding og patching av servere kan eksponere serverne for sikkerhetssvakheter som ikke lett lar seg detektere. Mangelfull herding fører til økt eksponering av servere. Mangelfull patching fører til økt risiko for kompromittering. Kan medføre uønsket publisering, spredning av skadevare osv, med tap av omdømme Vurderes i utgangspunktet som lav, da herding og patching av servere antas håndtert gjennom SP sine interne rutiner for drift av servere. Men siden dette er en eksternt eksponert tjeneste bør det iverksettes tiltak som regelmessig verifiserer at løsningen ikke inneholder svakheter eller sårbarheter som kan utnyttes. Sikkerhetstest har påvist manglende patcher, se vedlegg for anbefalte tiltak. JA 03 17

18 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 12.1 Fjerntilgang av servere i Windows Azure miljøet Remote DeskTop tilgjengelig fra SP driftssenter Fjernadministrasjon av FPL2.0 miljøet fra andre steder enn SP s driftssenter RDP tjenesten til windows servere kan administreres fra hvor som helst, noe som kan medføre eksponering av brukernavn og passord til brukeren Administrator har potensielt full tilgang til serveren, konsekvensen blir da full kompromittering, og vurderes høy. Sannsynlighet er lav fordi kun dedikerte driftsmaskiner har tilgang til RDP-tjenesten i Azure Fjerntilgang av servere i Windows Azure miljøet Powershell tilgjengelig fra dedikerte driftsmaskiner hos SP (Powershell er Windows sin metode for remote administrering av serveren). Dersom Powershell brukes ukryptert kan uvedkommende få tilgang til brukernavn og passord. K Administrator har potensielt full tilgang til serveren, konsekvensen blir da full kompromittering, og vurderes høy. Sannsynlighet er lav fordi kun dedikerte driftsmaskiner har tilgang til Powershell-tjenesten i Azure. 18

19 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 13 Uautorisert tilgang til applikasjonen Feilkonfigurasjon av web-redaktørenes tilgang, feil i programvare eller feil i FPL applikasjonen kan medføre at uautoriserte brukere får tilgang til å endre på data innhold i FPL applikasjonen. Uautorisert tilgang til løsningen / applikasjonen (kompromittering) kan medføre uønsket publisering, spredning av skadevare osv, med tap av omdømme K, I Det er planlagt gjennomført en penetrasjonstest av løsning som del av pilot. Endringer i FPL løsningen vil kunne introdusere svakheter og feilkonfigurasjoner. Det bør utføres regelmessige pentester av FPL løsningen, spesielt etter større oppgraderinger v løsningen. JA Usikker informasjonssikkerhet ved lagring i nettskyen (hentet fra CSA-guide, versjon 3.0) Leverandørens infrastruktur oppfyller ikke norske lovkrav. Brudd på lovkrav K Sykehuspartner er pålagt å behandle data etter norsk lov. Gjennomført møte med leverandør viser svært lav risiko for lovbrudd. Løsningen er heller ikke ment å inneholde helse- eller personopplsyninger 15.2 Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Adminbrukere hos cloudleverandør får uønsket tilgang til sensitiv informasjon for virksomheten. Brudd på regime for tilgangsstyring K Konsekvensen er vurdert forholdsvis lav da løsningen ikke skal inneholde helse- eller personopplysninger. 19

20 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 15.3 Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Manglende kontroll på fysisk lokasjon Manglende kontroll på hvor data befinner seg K, T Må løses kontraktuelt da dette ligger implisitt ved valg av en public cloud. Siden løsningen ikke skal inneholde helse- eller personopplysninger er ikke lagring utenfor EU tema Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Manglende bruk av skillemekanismer hos skyleverandør. Uønsket deling av data, andre kunder av skyleverandøren kan potensielt få tilgang på data. K, T Konsekvensen er vurdert forholdsvis lav da løsningen ikke skal helse- eller personopplysninger 15.5 Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Tjenesten slutter å virke og data går tapt på grunn av manglende backup/restore hos leverandør Potensielt datatap T Sannsynligheten vurderes lav, da sikkerhetskopier legges på lagring i skyen og kopieres lokalt inn til Sykehuspartner Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Manglende tilgang til data ved undersøkelse av hendelser, for eksempel logger Manglende evne til å finne rotårsak til hendelser K, T Vurderes lavt da logging er ivaretatt gjennom AD og SharePoint. Konsekvensen settes lav da hendelsen forventes å inntreffe sjelden. 20

21 Tiltak Utenfor akseptkriterier Begrunnelse Risiko (S x Ko) Konsekvens (Ko) Sannsynlighet (S) KITS Mulige virkninger Mulig hendelse Sårbarheter # 15.7 Usikker informasjonssikkerhet ved lagring i nettskyen(hentet fra CSA-guide, versjon 3.0) Skyleverandør går konkurs eller blir kjøpt opp, kan føre til tap av data / manglende tilgang til data. Potensielt datatap og tjenesten vil ikke lengre være tilgjengelig T Sannsynligheten vurderes lav, da sikkerhetskopier legges på lagring i skyen og kopieres lokalt inn til Sykehuspartner. 21

22 4 Risikohåndtering Risiko kan enten aksepteres, unngås eller reduseres. Å akseptere risiko må alltid begrunnes. Risiko skal bare aksepteres dersom den er innenfor akseptkriteriene. Å unngå risiko vil si å unngå de aktivitetene som medfører risiko. Konsekvensen av dette må forklares, for eksempel hvordan man kan oppnå samme resultat eller målsetting med andre aktiviteter, eller om man aksepterer at man ikke oppnår noen resultater eller målsettinger. For å redusere risiko, må man vite hvilke tiltak som er mulige. Det finnes primært tre kategorier av tiltak: oppdagende, forhindrende eller gjenopprettende. Når man skal identifisere mulige tiltak, gir det ofte et godt resultat å lete etter mulige tiltak innen alle tre kategorier. Ett enkelt tiltak kan ofte adressere flere sårbarheter, for eksempel overvåkning av nettverket for ulike sårbarheter. Oversikt over dette er en viktig del av vurderingen, fordi det er en del av kost-/nyttevurderingen å avgjøre hvilke tiltak som gir mest for pengene. I tabellen nedenfor vurderes hvordan risikoen identifisert i forrige kapittel skal håndteres. For risiko som håndteres ved å redusere risiko, beskrives det nedenfor hva som kan gjøres, og hvilke sårbarheter som adresseres. Dette er viktig for å vurdere kost/nytteverdien av hvert tiltak. 4.1 Aksepterte hendelser Risiko innenfor akseptkriterier er sårbarhetene med en vurdering lavere enn 6. Se kapittel 3. 22

23 4.2 Hendelser med definerte tiltak Tiltak # ID Risiko (0 16) Beskrivelse av risiko Beskrivelse av tiltak Status Ansvar og tidsfrist Informasjon i kontekst 2, 3 eller 4 legges ut uten å bli oppdaget. Innføre rutiner for sjekk av informasjon. Prosjektet bør vurdere å utarbeide felles rutiner som HF ene skal følge ved publisering. Helseforetaket Spredning av malware Videreutvikle rutiner for å forhindre spredning. Tjenesteansvarlig & 13 6 Mangelfull herding og patching og sårbarheter i applikasjonen Når tjenesten er overlevert til produksjon bør det inngås avtale med ekstern part som gjør en regelmessig sårbarhetsvurdering, eksempelvis en gang per kvartal, eller ved endringer. Tjenesteansvarlig Se vedlegg, kapittel Mange tilgjengelige tjenester Se vedlegg, kapittel 4 Prosjektet, før produksjonssetting RDP tjenesten tilgjengelig fra Internett Se vedlegg, kapittel 4 Prosjektet, før produksjonssetting Selvsignerte sertifikater Se vedlegg, kapittel 5.1 Prosjektet, før produksjonssetting 07 Svake kryptonøkler (sertifikat) Se vedlegg, kapittel 5.1 Prosjektet, før produksjonssetting 23

24 4.3 Konklusjon Det er identifisert 3 direkte tiltak basert på 14 forskjellige bekymringer. I tillegg er det foreslått flere tiltak etter gjennomført penetrasjonstest, beskrevet nærmere i penetrasjonstestrapporten. Ingen av de identifiserte tiltakene er uakseptable, men de nevnte risikopunktene må adresseres av helseforetakene, som selv må bestemme hvorvidt disse faller innenfor akseptabel risiko, og evt. hvilke tiltak (om noen) helseforetakene velger å iverksette. Risikovurderingen er behandlet i regionalt sikkerhetsråd, og er godkjent. 24

25 Kapittel 5 Appendix Sammendrag av penetrasjonstestrapport NTT Com Security har utført en penetrasjonstest av Felles Publiserings Løsning (FPL) på vegne av Sykehuspartner AS. Hensikten med en penetrasjonstest er å finne sikkerhetssvakheter i infrastruktur og applikasjoner før uvedkommende oppdager og utnytter dem (det være seg en inntrenger eller en utro tjener). De mest alvorlige funnene i denne penetrasjonstesten er: Mange tilgjengelige tjenester RDP tjenesten tilgjengelig fra Internett Selvsignerte sertifikater Svake kryptonøkkler Det er avdekket at FPL infrastrukturen eksponerer flere tjenester på Internett enn det som er nødvendig. FPL løsningen skal i utgangspunktet kun eksponere HTTP tjenesten til alle på Internett. HTTPS trafikk skal kun være tilgjengelig fra webredaktører fra helsenettet og tjenesten remote Powershell skal kun være tilgjengelig fra enkelte dedikerte servere hos Sykehuspartner. Remote Powershell brukes til fjernadministrasjon av en server. Remote Desktop Protocol (RDP) er tilgjengelig over Internett. RDP er gjort tilgjengelig fra Internett som en midlertidig løsning til VPN forforbindelsen fra Sykehuspartners sitt driftssenter til FPL er tatt i bruk. RDP tjenester har endel sikkerhetssårbarheter og bør oppdateres med alle tilgjengelige oppdateringer. I tillegg bør det også opprettes en aksessliste over maskiner som kan koble seg opp mot denne tjenesten. Det er benyttet selvsignerte sertifikater på publiseringsløsningens web tjeneste. Det gjør at brukerne ikke vil kunne sjekke at det brukte sertifikater tilhører Sykehuspartner og en angriper kan utføre et "man-in-the-middle". Brukeren vil få opp en advarsel om at sertifikatet ikke er utstedt av en gyldig CA, men denne feilmeldingen kommer hver gang en logger på. NTT Com Security anbefaler å bruke sertifikater fra godkjente CAer. Det bør brukes lengere nøkler når der genereres sertifikater for at det ikke skal være lett å utføre 'brutte force' angrep av sertifikatet. 25

26 Testene fra Sykehuspartners driftssenter mot FPL løsningen over VPN koblingen er ikke testet, da det ikke var mulig å sende trafikk over VPN inn til FPL løsningne. NTT Com Security anser sikkerhetsnivået i de testede nettverkssegementene til Sykehuspartner som over middels og anbefaler å implementere de nevnte tiltakene i denne rapporten. Det må påpekes at en penetrasjonstest aldri vil avdekke alle mulige sårbarheter i et nettverk. Om testingen ikke lyktes i å gjennomtrenge eller angripe de eksisterende sikkerhetstiltak, kan det likevel ikke garanteres at andre eksterne eller interne angrep ikke vil lykkes eller at uautorisert tilgang ikke kan skje. Hele tiden avdekkes det nye svakheter i operativsystemer og annen programvare. Utnyttelsen av slike svakheter vil kunne bli oppdaget i et godt konfigurert IDS/IDP system. 26