Risikovurdering av TSD Tjenester for Sensitive Data

Transkript

1 Risikovurdering av TSD Tjenester for Sensitive Data Version Espen Grøndahl IT- sikkerhetssjef UiO

2 1. INNLEDNING BAKGRUNN AVGRENSING LØSNINGSBESKRIVELSE BESKYTTELSESBEHOV GJENNOMFØRING METODE DELTAKERE AKSEPTKRITERIER VURDERINGSSKALA RISIKOELEMENTER MED ET PRODUKT MELLOM 1 OG 4: RISIKOELEMENTER MED ET PRODUKT MELLOM 4 OG 8: RISIKOELEMENTER MED ET PRODUKT MELLOM 8 OG 16: BESKRIVELSE OG VURDERING AV ENKELT RISIKOELEMENTER... 6 RISIKO RISIKO RISIKO RISIKO RISIKO RISIKO VURDERING OG VIDERE OPPFØLGING KONKLUSJON VEDLEGG... 9

3 1. Innledning TSD Tjenester for Sensitive Data er utviklet ved USIT ved UiO i perioden Det baserer seg på en pilot TSD 1.0 som ble laget Systemet har hatt som målsetning å lage et sikkert miljø som tilfredsstiller alle lovkrav med tanke på sikring av sensitive data. Det er primært sensitive forskningsdata innen helsesektoren som er i målgruppen, men også andre data som krever ekstra beskyttelse. Dette dokumentet er andre versjon av risikovurderingen og tar utgangspunkt i slik løsningen foreligger i midten av februar Det har blitt endret på mindre detaljer i systemet, samt at vi har utbedret noen av punktene i kategori [4-8]. Det var dermed et behov for en ny risikovurdering. Ytterligere endringer som endrer vesentlig på vurderinger i dette dokumentet vil utløse behov for ny eller oppdatert vurdering. 2. Bakgrunn Etter flere års pilot og utvikling er TSD i full produksjon. Denne risikovurderingen er den andre generelle vurderingen av hele løsningen slik den ser ut våren 2015, og vil være grunnlaget for den lovpålagte risikovurderingen som hver enkelt prosjektansvarlig vil måtte foreta før de tar i bruk løsningen for lagring og behandling av sensitive personopplysninger. 3. Avgrensing Denne risikovurderingen tar for seg TSD og dets hovedbestanddeler, samt omliggende infrastruktur der denne er har direkte eller indirekte påvirkning på løsningen. Den dykker ikke ned i enkeltdetaljer på de enkelte komponentene, med mindre det er viktig for å beskrive det totale risikobildet. Den tar heller ikke for seg risikoer knyttet til enkeltprosjekter som skal benytte løsningen, men tar utgangspunkt i et generelt bruksmønster. Prosjekter som tar i bruk løsningen må supplere med egne vurderinger av forhold som er spesifikke for deres prosjekter. Vurderingen skiller ikke på sensitivitet for data hos de enkelte prosjektene, men legger til grunn at data er av den mest sensitive art.

4 4. Løsningsbeskrivelse For nærmere beskrivelse av løsningen se vedlagt Whitepaper TSD samt mer detaljert system og komponent dokumentasjon på TSDs nettsider. Ikke alle detaljer ligger åpnet, men kan fremvises på forespørsel. Grunnprinsippet i løsningen er å lage et fysisk og logisk lukket nett, med sterk konfigurasjonskontroll og stor grad av automatisering på innsiden. Innsiden skal inneholde et mini UiO, med lagring, infrastruktur for å sette opp X antall linux og windows maskiner for prosjekter, et eget frikoblet Windows Active Directory for bruker- og gruppe - styring. Det vil også være maskiner for å kunne drifte og overvåke maskinene på innsiden. Maskinene på innsiden vil ikke kunne kommunisere med andre maskiner på UiO eller på internett. Den eneste trafikken som tillates ut fra nettet er logg og driftsdata, samt spesifikke åpninger for å innhente lisenser og oppdatering av software. Brukerne kommuniserer med løsningen via å opprette en kryptert tunnel til en gateway maskin. Pålogging foregår vha. brukernavn/passord og engangskode. Brukere vil ha en konto pr. prosjekt de er med i for å forhindre dataflyt mellom prosjekter. Brukerne vil i første omgang benytte RDP og SPICE protokollene over denne krypterte tunnelen. Her vil muligheter for klipp og lim, mapping av lokal disk, deling av usb og printer osv. være skrudd av. Datatransport ut og inn av løsningen går via en fil- sluse. Dette er løsning med to maskiner som står koblet sammen med en egen dedikert link mellom seg, og et delt dataområde som deles ut fra maskinen på innsiden. Filslusen gjør det mulig å styre hvem som kan laste data inn, hvem som kan laste data ut samt loggføre filnavn og evt. innhold/sjekksum av data. Den er også satt opp på en slik måte at et evt. innbrudd på den ytterste maskinen skal ha minimale konsekvenser for den totale sikkerheten i løsningen. All bruk av løsningen både for brukere og systemadministratorer skal kreve to- faktor autentisering. Det benyttes personlige driftskonti så langt det er teknisk mulig. Der det ikke er mulig så finnes annen sporing som kan kobles til enkeltpersoner på driftsavdelingen. 5. Beskyttelsesbehov Data som skal lagres og behandles i løsningen har ulikt beskyttelsesbehov. En vurderer dette ofte langs tre akser. Konfidensialitet sikring av at ingen andre enn de som har rettmessig behov får tilgang til data. Integritet sikring av at data eller kode ikke manipuleres eller endres utilsiktet. Tilgjengelighet sikre at data er tilgjengelig for rett person til rett tid.

5 Data som behandles i TSD vil i første omgang kreve høy grad av konfidensialitet og integritet. Tilgjengelighet vil også være viktig i den forstand at rett person skal ha tilgang til rett data, men det vil ikke være snakk om løsninger som krever oppetid 24x7. Dette kan endres for eksempel hvis det kommer inn løsninger som benyttes i pasientbehandling el.l. En slik endring vil kreve en ny vurdering og kanskje endring av komponenter i løsningen. 6. Gjennomføring 6.1 Metode Risikovurderingen er gjennomført etter metodikk som er benyttet ved USIT tidligere. Den er basert på tradisjonell innsamling av risikoelementer som vurderes ut fra sannsynlighet og konsekvens. Risikovurderingen er gjennomført ved å ta utgangspunkt i den tekniske løsningen og dokumentasjon som finnes av denne for så finne risikoelementer som kan true konfidensialitet, tilgjengelighet eller integritet for løsningen. Risikoelementer er tatt frem vha. brainstorming og ut fra vurderinger som gjort i design og utviklingsfasen av løsningen. Disse er så vurdert ift. sannsynlighet og konsekvens. 6.2 Deltakere Vurderingen er foretatt av: Espen Grøndahl IT- sikkerhetssjef Gard O Sundby Thommasen prosjektleder Petter Reinholtsen prosjektdeltaker Erik Vestheim - prosjektdeltaker Martin Benoninsen prosjektdeltaker Helge Hauglin storage- core USIT 7. Akseptkriterier Sikkerhet vil alltid være en vurdering og en balanse mellom funksjonalitet og sikringstiltak. Noen risikoer vil være ønskelige å akseptere for å få en funksjonalitet som brukerne ønsker, og ikke minst som gjør at brukerne benytter løsningen fremfor å velge å ikke forske, eller velger å behandle data andre steder uten tilstrekkelig sikring.

6 I en løsning med så høy grad av sikkerhet som det vi tilstreber i TSD så vil det være få risikoer vi vil akseptere. Løsningen skal ikke feile på en slik måte at sensitive data eksponeres utilsiktet. Hvis løsningen feiler så er det viktigere at løsningen opprettholder konfidensialitet og integritet enn tilgjengelighet. Dette vil bli vektlagt i vurderingen av risikoelementer. 7.1 Vurderingsskala Risikoelementene blir vurdert på en skal fra 1-4 på sannsynlighet, og 1-4 på konsekvens. Der en 1 er lav sannsynlighet, eller liten eller ingen konsekvens. 4 er svært sannsynlig og svært alvorlig konsekvens. 7.2 Risikoelementer med et produkt mellom 1 og 4: Dette er risikoelementer som kan aksepteres enten som de er, eller med enkle risikoreduserende tiltak eller rutiner. 7.3 Risikoelementer med et produkt mellom 4 og 8: Dette er risikoelementer som må vurderes. De kan aksepteres i produksjon hvis de er kortvarige og risikoreduserende tiltak er planlagt. 7.4 Risikoelementer med et produkt mellom 8 og 16: Dette er uakseptable risikoer. De vil i de fleste tilfeller bety produksjonsstans eller at det må kompenseres med manuelle kontroller og rutiner til risikoen er redusert. 8. Beskrivelse og vurdering av enkelt risikoelementer Risikoelementene er listet opp i vedlagt excel fil. De er nummeret med løpenummer. Her følger en beskrivelse og vurdering av elementer som krever risikoreduserende tiltak eller spesiell oppmerksomhet. Risiko 20 Risiko 20 kommer av at det er avdekket tekniske svakheter i adgangskontrollsystemet ved UiO. Det er svakheter som går både på design og drift/vedlikehold av løsningen og av data i løsningen. Utbedring av adgangssystemet er i gang, men dette vil kunne ta noe tid så det er anmodet om ekstra sikring inntil dette utbedringen er ferdigstilt. Foreslått tiltak er ekstra sikring på dør til to datahaller som huser hhv. lagringsløsningen og virtualliseringsløsningen for TSD

7 Dette punktet ansees ikke som lukket før ekstra sikring er på plass, men vi finner risiko i punktet til å være tilstrekkelig lav for full produksjon. Risiko 22 Administrasjon av lagringen som er delt ut til TSD fra sentral HDS ved UIO er nå flyttet på innsiden av TSDs brannmur med egne EVS er og HNAS- hoder. LUNs for TSD (blokklagringen i bunn) er kun presentert for diskhodene innenfor TSDs brannmur. Nåværende løsning ses som svært godt sikret i forhold til opprinnelig produksjonsløsning. Risiko for vellykkede angrep fra utsiden av TSD for å få tak i data på TSD lagringen, uten tilgang til to- faktor koden for TSD, anses som svært lav. Risikoelementet er nedgradert til tolererbart nivå. Risiko 21 Det er nå helt egen og dedikert nettinfrastruktur mellom lagringsløsningen og TSD, det er nå ingen vei fra vanlig UIO nett uten to- faktorbeskyttelse inn på nett- utstyret mellom lagringsenheten og der lagringen presenteres for prosjektene i TSD, selv ikke via network- management nettet. Dette ble muliggjort når vi fikk dedikerte EVS er og HNAS hoder til TSD. Riskoelementet er nedgradert til tolererbart nivå. Risiko 19 Løsningen benytter mye ny teknologi og er skreddersydd for å dekke dette konkrete behovet. Det gjør at vi har liten erfaring med hvordan dette vil være i drift i storskala. Det vil også være mange prosjekter som skal inn i startfasen, da mange har stått på vent lenge. Dette innebærer at konkrete behov eller endringer gjort for enkelt prosjekter kan endre sikkerheten for hele løsningen. For å imøtegå denne risikoen foreslåes det etablering av et endringsråd for TSD som godkjenner og vurderer alle endringer. Endringsrådet er opprettet i forbindelse med oppstarten av Tjenestegruppen for TSD, og trer i kraft samtidig med Tjenestegruppen medio mars Sammensetningen er : - Espen Grøndahl (IT- sikkerhetssjef UIO) - Gard Thomassen TSD - Maria F. Iozzi TSD tjenestegruppeleder - Anders Winger har møterett Seksjonsleder Klientnær drift

8 - Kjetil Kirkebø har møterett Seksjonsleder Grunndrift Vi jobber også med å redusere mengden spesialtilpasninger og vil ha som prinsipp at spesialtilpasninger ikke skal innføres. Risikoelementet er nedgradert til tolererbart nivå. Risiko 16 Overvåkning er nå på plass for alle linux- adm- servere i TSD, og er i ferd med å bli rullet ut for alle linux prosjektmaskiner og alle windows servere (adm + prosjekter). Overvåkningen benytter USITs nye fillogg (Nivlheim) som ble spesialutviklet med TSD som premissgiver. Videre benyttes Zabbix som overvåkningsmotor og overvåkningsdata fra TSD leveres ut til Zabbix på utsiden av TSD ved hjelp av proxy. Det ansees som svært lite sannsynlig at prosjektdata kan eksporteres via denne prosessen siden overvåkningssystemet ikke har tilgang til prosjektdata og vice versa. Prosessen initialiseres fra innsiden av TSD. TSD har nå overvåkning av diskfyllninggrad og at viktige maskiner og prosesser (for eksempel backuptjenesten) i TSD fungerer og kjører som de skal. Tilsvarende overvåkning rulles nå ut for windowsservere i TSD. Fremdeles vises det til at det er for lite overvåkning av Cerebrum- prosessene (sync av ny brukerinfo) i TSD. Riskoelementet er nedgradert til tolererbart nivå. Risiko 13 Denne risikoen kommer primært av at ved siden av lagringsløsningen så er backupsystemet det eneste stedet data vil være lagret. Data vil være kryptert med TSM s innebygde kryptering ( AES ) så et innbrudd på backupsystemet alene vil ikke medføre datalekkasje. Men sammen med en lekkasje av krypteringsnøkler så vil det være svært alvorlig. Mottiltaket mot dette er å ha gode rutiner for håndtering av backupnøkler. Vi anser dette som gjennomført i TSD.. Det er skapt forståelse av at hvor mye verdi og risiko som ligger i hvert enkelt av passordene. I startfasen vil nøkkelsetting av backup og produksjon av passord kun utføres av en person i restore- core ved USIT og/eller IT- sikkerhetssjef UiO. Rutiner for dette er nå på plass og velfungerende. Nøkler oppbevares kun på en spesiell maskin i TSD der backuptjenesten kjører, en maskin kun et fåtall personer ved USIT har tilgang til. Kopi oppbevares i USITs safe, også der underlagt svært begrenset tilgang.

9 Riskoelementet er nedgradert til tolererbart nivå. 9. Vurdering og videre oppfølging Risiko 20 er eneste risiko som ansees som et viktig punkt å adressere raskt. Ut over dette er alle punkt på forrige versjon av risikovurderingen nå utbedret på en slik måte at risikoen er kommet ned på et akseptabelt nivå. 10. Konklusjon Vår vurdering er at TSD har lukket alle alvorlige risikoelementene, med ett unntak. Unntaket er vurdert slik at det har høy prioritet for utbedring, men at det ikke påvirker pågående produksjon. Løsningen er designet fra starten av for å ha meget høyt sikkerhetsnivå og det er ved denne gjennomgangen ingen kjente svakheter eller bakveier inn i systemet. TSD har også etablert et system for avvikshåndtering. Saker rapporteres og legges i et arkiv slik at vi lettere kan se på trender og forebygge fremtidige tilsvarende problemer. Alvorlige avvik vil bli rapportert til sluttbrukere. 11. Vedlegg A. Whitepaper TSD B. Risikoelementer TSD Avviksrapportering på plass Macroer RPM