Tredjepartsverifikasjon IKT

Transkript

1 Helsebygg Midt-Norge Side: 1 av 19 Tredjepartsverifikasjon IKT Fase 2: Verifikasjon av leverandørens design utført av Capgemini

2 Helsebygg Midt-Norge Side: 2 av 19 Versjonshistorie Versjon Dato Endring Draftversjon sendt HBMN (KOS) Versjon etter gjennomgang av HBMN (KOS) 0.9a Mindre korreksjoner 0.9b Oppdatert etter kommentarer fra HBMN (AOS) 0.9c Mindre oppdateringer etter intern gjennomgang Oppdatert etter kommentarer fra HBMN Vurdering i rapport for fase 1 kap som ikke gjelder tilbudsfasen er flyttet til kap Oppdatert etter kommentarer fra Telenor og HBMN Gjennomgang og revisjon Dato Navn Rolle Karl Oscar Sandvik HMS- og kvalitetssjef HBMN Arve-Olav Solumsmo Informasjonssjef HBMN Børge Godhavn Prosjektleder HBMN Tore Indreråk IKT sjef HBMN Tore Nordmark Telenor Børge Godhavn og Tore Indreråk HBMN

3 Helsebygg Midt-Norge Side: 3 av 19 Sammendrag I den andre fasen av oppdraget ønsker Styret i Helsebygg Midt-Norge å få verifisert om design og konsept blir videreutviklet av leverandøren og i dette var tro mot Helsebyggs visjon om sikkerhet og godhet. Verifikasjonen har fokus på B6 Datanett som er et underpunkt til Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. (Forkortelser er definert i kapittel 1.1.) I sammendraget er svarene gitt på kortform med symboler etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik I fase 2 (av 3) besvares følgende spørsmål, knyttet til verifikasjon av leverandørens design: 1. Stemmer beskrevet design/arkitektur/konsept med funksjonsspesifikasjonen? Svar: Dokumentasjonen viser at beskrevet design/arkitektur/konsept stemmer med funksjonsspesifikasjonen i betydningen at det foreligger design av samtlige krav i B6. Vi er likevel av den oppfatning at designet av kravet til tilgjengelighet kunne vært gitt en mer omfattende beskrivelse samt begrunnelse. 2. Vil beskrevet løsning gi en god og driftssikker implementering i et operativt sykehus? Svar: Beskrevet løsning kan gi en god og driftsikker implementering i et operativt sykehus, selv om det i denne fasen av prosjektet mangler driftdesign av noen ITIL prosesser. Dette er mangler som vi forutsetter kommer på plass av en leverandør som ønsker å basere sin drift på ITILs rammeverk. 3. Hvilke risikoer er forbundet med de foreslåtte løsningene - hvor sårbar er løsningen? Svar: Dokumentasjonen viser at kartlegging av risiko og sårbarhet ble gjennomført hos de forskjellige partene. De viktigste områdene ble avdekket og noen områder ble behandlet formelt, andre områder mindre formelt. Informasjon om risiko og sårbarhet fra leverandøren Telenor til HBMN og videre til St. Olavs Hospital har ikke vært tilstrekkelig, selv om St. Olavs Hospital hadde et selvstendig ansvar for å vurdere risiko og sårbarhet for løsningen. Behovet for oppdatering av beredskapsplaner hos St. Olavs Hospital var avdekket i prosjektet, men forståelsen for å gjennomføre dette ville vært mye større med bedre informasjon om risiko i løsningen.

4 Helsebygg Midt-Norge Side: av 19 Innhold 1. Innledning Forkortelser Fremgangsmåte Spørsmål i fase Stemmer beskrevet design/arkitektur/konsept med funksjonsspesifikasjonen? Vil beskrevet løsning gi en god og driftssikker implementering i et operativt sykehus? Hvilke risikoer er forbundet med de foreslåtte løsningene - hvor sårbar er løsningen? Kartlegging og oppfølging av risiko og sårbarhet for løsningen Gjennomgang av risiko sett i forhold til design av nettverket...19

5 Helsebygg Midt-Norge Side: 5 av Innledning Innledning i Rapport for fase 1 beskriver bakgrunn for verifikasjonen, faseinndeling og omfang. I den andre fasen av oppdraget ønsker Styret i Helsebygg Midt-Norge å få verifisert om design og konsept blir videreutviklet av leverandøren og i dette var tro mot Helsebyggs visjon om sikkerhet og godhet. Verifikasjonen har fokus på B6 Datanett som er et underpunkt til Infrastruktur for IKT og St. Olavs Hospital som er den brukeren med størst krav til datanettet. Med fase 2 forstår vi perioden etter signering av kontrakt til leverandørens design av løsningen er overlevert Helsebygg Midt-Norge. I fase 2 (av 3) besvares følgende spørsmål knyttet til verifikasjon av leverandørens design: 1. Stemmer beskrevet design/arkitektur/konsept med funksjonsspesifikasjonen? 2. Vil beskrevet løsning gi en god og driftssikker implementering i et operativt sykehus? 3. Hvilke risikoer er forbundet med de foreslåtte løsningene - hvor sårbar er løsningen? 1.1 Forkortelser Liste over viktige forkortelser i dokumentet: FAT Factory Acceptance Test FDR Final Design Review HBMN Helsebygg Midt-Norge IKT Informasjons og Kommunikasjonsteknologi IT Informasjonsteknologi ITIL IT Infrastructure Library MTBF Mean Time Between Failures MTTR Mean Time To Repair NMS Network Management System PDR Preliminary design review POC Proof of concept ROS Risiko og Sårbarhet SAT Site Acceptance Test SPOF Single point of failure

6 Helsebygg Midt-Norge Side: 6 av Fremgangsmåte For å besvare spørsmålene som reises har vi benyttet dokumentasjon som ble benytte som input til prosessene (eksempelvis HBMNs krav til datanettet for det nye universitetssykehuset) og dokumentasjon som ble produsert i prosessene (eksempelvis) leverandørens FDR (Final Design Review). Vi har også hatt møter og telefonsamtaler med personer fra HBMN, Telenor og St. Olavs Hospital. Spørsmålene angitt i innledningen behandles i neste kapittel i rekkefølge med. bl.a. angivelse av dokumentasjonskilde, svaret og kortversjon av svaret. Som underlag for vurderingen i fase 2 har vi hatt tilgang til følgende dokumentasjon: Kontraktsdokumenter; PDR (Preliminary design review) og FDR (Final design review) dokumenter; Møtereferater og statusrapporter. Vi har konsentrert innsatsen rundt dokumenter relatert til datanettverk og drift. Enkelte av spørsmålene kan være overlappende. Dette fører til at samme argumentasjon kan benyttes til å besvare flere spørsmål. Til å besvare spørsmålene har vi benyttet følgende mal: Kilde: er det formelle navnet på dokumentasjonen vi legger til grunn for å besvare spørsmålet. Dersom vi har benyttet møter eller telefoner, gies det informasjon om det her. Dersom det finnes annen relevant dokumentasjon, ønsker vi en tilbakemelding om dette og hvor denne dokumentasjonen kan finnes; svar på spørsmålet; Svar: er kortversjon av svaret. Rapporten beskriver avvik som er avdekket i gjennomgangen. Avvik defineres som manglende samsvar med visjon, strategi, design eller leveranse. I sammendraget er svarene gitt på kortform etter følgende skala: - Ingen avvik - Mindre avvik - Større avvik Rapportene omhandler i hovedsak avvik. Forhold der ingen avvik er avdekket, beskrives normalt ikke. Gjennomgangen er basert på stikkprøver. Det er derfor ikke sikkert at alle forhold er avdekket. Rapporten bør leses med dette i minne. Sluttrapporten vil inneholde forslag til tiltak basert på avvikene.

7 Helsebygg Midt-Norge Side: 7 av Spørsmål i fase Stemmer beskrevet design/arkitektur/konsept med funksjonsspesifikasjonen? Kilder: [ Infrastruktur for IKT Bilag B6, Datanett, kontrakten, 1]; [ B02-FDR Overordnet beskrivelse.doc, 2]; [ B6-PDR Nettverk Vedlegg 2.doc; 3]; [ B6-PDR Nettverk.doc, ]; [ B12-PDR Katalogtjeneste.doc, 5]; [ B3-PDR-Drift.doc, 6]; [ B3-SLA rapport januar 06_oppdatert.doc, 7]; [ B3-SLA rapport FEBRUAR 06.doc, 8]; [ B3-SLA rapport MARS_ doc, 9]; [ B3-SLA rapport_april_revidert_06.doc, 10]; [ B3-Revidert _SLA rapport_mai_06.doc, 11]; [Kravsporing_Intern_Sortert_B_PDR.rtf, 12]; [ B06-FDR Vedlegg 2 Sporing.doc, 13]; [ B06-FDR Vedlegg 1 Kravtabeller.doc, 1]; [ B06-FDR Datanett Nettverk og Trådløst nettverk.doc, 15]; [B6 DATANETT Kravtabell.doc i kontrakten, 16]; [ B3-FDR Drift v2.0.doc, 17]; [Mail fra KC 25/10-06 til FLA, 18]; [ MR-FSAT B doc, 19]; [ B06-FDR Datanett Sikkerhet.doc, 20]. Innledningsvis ønsker vi å presisere vår forståelse av begrepet «stemmer» i spørsmålet som skal besvares. Leverandørens design/arkitektur /konsept «stemmer» med funksjonsspesifikasjonen til HBMN dersom leverandøren har en dokumentert «design» av alle krav beskrevet av HBMN i [1]. Designet iht. til leverandør [2], beskriver en løsning som vil tilfredsstille alle omforente krav slik disse ble dokumentert i kravsporingsprosessen [13].. Vår kildematerialet er deler av PDR og FDR leveransen begrenset til datanettet (B6.1 Nettverk; B6.2 Trådløst nettverk; B6.3 System for drift, overvåkning og administrasjon i [1]). Iht. kapittel 2.1 i [2] inneholder denne leveransen for hvert system en design av systemet i tillegg til et dokument per system for kravsporing og en kravtabell. Iht. IKT sjefen i HBMN består designleveransen av PDR dokumenter og FDR dokumenter. FDR dokumenter er bare utarbeidet dersom det var nødvendig med justering av PDR dokumenter. Iht. til leverandøren var leverandøren pålagt å levere FDR. PDR var en preversjon av design og FDR er endelig design. Vi har fått informasjon om at PDR dokumentet for nettverk [3] henviser til design av samtlige 1 B6 krav, eller at det gies en kommentar der hvor nærmere design ikke er nødvendig. PDR dokumentet for nettverk [3] refererer til design i PDR for nettverk [], PDR for katalogtjeneste [5], PDR dokument av drift [6] og SLA rapporter [7; 11]. 1 I vår versjon av [3] forekommer K uten henvisning eller kommentar.

8 Helsebygg Midt-Norge Side: 8 av 19 For design av K vises det PDR dokument av drift [6] og SLA rapporter. Tanken bak dette er, etter vår forståelse, at designet av dette kravet skal være beskrevet i [6] og SLA rapportene benyttes til å dokumentere at kravet er oppfylt. Vi kan ikke se at [6] gir en design av hvordan dette kravet er tenkt realisert. I kapittel i refererte dokument [6] legges det vekt på betydningen av driften hvor det bl.a. heter: Kravene (til pålitelighet, tilgjengelighet og overlevelsesevne) søkes oppnådd ved hjelp av omfattende overvåkning, vaktordning, vedlikeholdsavtaler med leverandør og onsite reservedelslager. Kravsporingstabellen [12] dokumenterer saksbehandlingen av åpne saker. Med utgangspunkt i de krav som henviser til et design i FDR, har vi foretatt enkelte stikkprøver. Tabellen under oppsummerer våre observasjoner. Vår generelle kommentar til leverandørens bruk av referanser er at en referanse bør i størst mulig grad begrense antall sider som må leses igjennom for å finne teksten som beskriver designet. Nr. Krav ID Krav Henvisning (PDR) Henvisning (FDR) Våre observasjoner vedr. FDR henvisningene K6.1-3 Følgende opplisting viser noen av de viktigste overordnede krav som stilles til datanettet: 1 K6.1-3 (1) 1 Datanettet skal være basert på standardiserte og åpne løsninger. Kapittel Design i FDR dokumentet for B06 [15] består av 29 sider. Vi savner en referanse som begrenser antall sider som må leses igjennom for å finne teksten som beskriver designet. Vi savner en tabellarisk oppstilling av hvilke internasjonale standarder/industristandarder som er benyttet i løsningen. 2 K6.1-3 (2) 2 Løsningen skal være fleksibel og framtidsrettet, men samtidig moden på installasjonstidspunktet. Begrepet «moden» er et sentralt begrep som benyttes i et antall av dokumenter fra HBMN. Det er derfor rimelig å forvente at begrepet «moden» også ville blitt benyttet i [15] i en beskrivelse av dette designet. Det er det ikke. 3 K6.1-3 (3) 3 Løsningen skal være slik at det ikke er noe single point of failure i hele strukturen helt ut til kantsvitsj i kommunikasjonsrom. nettverk kap.7 Vi savner en kort begrunnelse av hvorfor leverandørens bruk av redundans medfører at det ikke er noe «single point of failure i løsningen helt ut til kantsvitsjene i kommunikasjonsrommet. Iht. leverandøren vil dersom hele kapittel leses og dersom det som er beskrevet og skissert er forstått, vil man se at kravet er dekket. K6.1-3 () Sikkerhet skal være ivaretatt i henhold til Nettverkssikkerhetsarkitekturen (NVSA), og skal være implementert slik at nettet i størst mulig grad tilfredsstiller de ytelseskrav som stilles fra brukerne..10, sikkerhet kap sikkerhet kap i [20] Referansen er sannsynligvis ment å være 7 Sikkerhet i [15]. Kapittel heter Design. Formålet med NVSA er å beskrive den gjeldende Nettverkssikkerhetsarkitektur (med fokus på St. Olavs Hospital/DMF og Helsebygg Midt-Norge) som ivaretar kravene til informasjonssikkerhet innenfor områdene: Konfidensialitet, dvs. hindre uvedkommende i å få innsyn til informasjon de ikke skal ha tilgang til; Integritet, dvs. sikre at informasjon utilsiktet blir endret Tilgjengelighet, dvs. at informasjon er tilgjengelig for brukerne når de trenger det. Vi savner derfor en oversikt som viser med utgangspunkt i sikkerhetstjenestene konfidensialitet, integritet og tilgjengelighet hvilke sikkerhetsmekanismer, produkter og 2 Det tilbudte systemet skal inneha 99,999 % tilgjengelighet innenfor tidsintervall på en måned.

9 Helsebygg Midt-Norge Side: 9 av 19 Nr. Krav ID Krav Henvisning (PDR) 5 K6.1-3 (5) 5 Deler av nettet skal kunne modifiseres eller byttes ut uten at det innvirker på hele nettet. 6 K6.1-3 (6) 6 Kapasitet i nettet må kunne allokeres etter behov og økes uten strukturelle endringer..3.3 Henvisning (FDR) Våre observasjoner vedr. FDR henvisningene løsninger som var planlagt benyttet i nettverket. Vi har vanskeligheter med å finne en dekkende beskrivelse i kapittel Design som forklarer at nettet kan vedlikeholdes uten at dette innvirker på hele nettet. Derimot er formuleringen benyttet i [16] dekkende: «Dersom SpanningTreeblir benyttet som redundansmekanisme for hele nettet vil dette ikke kunne oppfylles. Telenor s design bruker routing og routingprotokoll for redundans på LAG 3(OSPF), og dette kravet oppfylles. Se forøvrig punkt [K6.1-30]». Leverandørens kommentar til dette punktet er: Ved å les kap, ser man at OSPF benyttes ergo er vårt forbehold i kravtabellen også innarbeidet i designet for å ivareta kravet. Sannsynligvis ville Oppgraderingsplan for HBMN i [15] være en mer presis referanse. 7 K6.1-3 (7) 1 Det skal være mulig å tilby nye/endrede tjenester, protokoller og grensesnitt (spesielt for endeutstyr) etterhvert som brukerne stiller krav om det. nettverk kap, sikkerhet kap nettverk kap, sikkerhet kap sikkerhet kap referer til kapittel i B06-FDR Datanett Sikkerhet [20]. 8 K6.1-3 (8) 2 Nettet skal kunne overføre sanntidsapplikasjoner som for eksempel IP-telefoni og distribusjon av TV/underholdning , 9.7, 9.8 Vi finner ikke dette beskrevet i [15]. Kapittel 5.2 Systemkomponenter i [2] FDR B2 Overordnet beskrivelse, vil sannsynligvis være en mer presis referanse. Leverandørens kommentar til dette punktet er: Funksjonene som trengs for å realisere dette er beskrevet i nevnte dokument (qos, multicast). 9 K6.1-3 (9) 3 Strukturen i nettløsningen må være slik at IT-systemløsninger (brukere av nettløsning) kan endres uten at det har innvirkning på nettløsningen. Upresis referanse. 10 K6.1-3 (10) Det skal være mulig å utvikle nettet mot nye standarder og teknologier. nettverk kap.15 Upresis referanse. 11 K6.1-3 (11) 5 Nettverksløsningen skal tilfredsstille strenge krav til redundans, tilgjengelighet og pålitelighet (det stilles oppetidskrav/pålitelighetskrav til alle deler av nettet). nettverk kap.7, ,.1.9, sik Sikkerhet.2 Kapittel.2 heter Løsningskomponenter ikke Sikkerhet. Referansene er sannsynligvis ment å være.1.2;.2.1.3; ; ; ; og.3.2 Leverandørens kommentar til dette punktet er: Summen av kolonne pdr og fdr er ment å gi svaret på kravet. Det presiseres at med sikkerhet.2 menes dokument B06- FDR Datanett Sikkerhet.doc. 12 K6.1-3 (12) 6 Nettet skal automatisk foreta omkobling til alternative traséer ved brudd i forbindelser i stigenett og stamnett..1.8.,.1.9 Referansene er sannsynligvis ment å være ;.2.1. med underkapitler om load balancing og reruting. Kravet K i Kravtabellen [] lyder som følger: Kravene som stilles til det trådbundne nettet er i mange henseende også relevante for det trådløse datanettet. Tilbyder skal gå gjennom kravene/spørsmålene i kap. B6.1.3 og besvare de som er relevante for det trådløse utstyret.

10 Helsebygg Midt-Norge Side: 10 av 19 Vår forståelse av dette er at kravene for det trådbundne nettet K6.1-1,, K i [1] som er relevante for det trådløse datanettet, skal også besvares. Vi er i ettertid informert [18; 19] at om at K6.1, K6.2. og K6.3 kravene som også er relevante for trådløst utstyr er oppfylt og at designen av kravene forligger. Svar: Dokumentasjonen viser at beskrevet design/arkitektur/konsept stemmer med funksjonsspesifikasjonen i betydningen at det foreligger design av samtlige krav i B6. Vi er likevel av den oppfatning at designet av kravet til tilgjengelighet kunne vært gitt en mer omfattende beskrivelse samt begrunnelse.

11 Helsebygg Midt-Norge Side: 11 av Vil beskrevet løsning gi en god og driftssikker implementering i et operativt sykehus? Kilder: [ B06-FDR Datanett Nettverk og Trådløst nettverk.doc, 1]; [ Infrastruktur for IKT Bilag B6, Datanett, kontrakten, 2]; [ Infrastruktur for IKT Bilag B3 Drift, kontrakten, 3]; [ B3-PDR-Drift.doc, ]; [ B3-FDR Drift v1.0.doc, 5]; [M8 beskrivelse av entreprenørens drift fram til overtakelse, 6]; [ B3-FDR Drift v2.0.doc, 7] Revisjonshåndteringen for B3-FDR Drift v2.0 [7] fra gjør at det oppfattes som et mye nyere dokument enn M8-dokumentasjonen fra Med «beskrevet løsning» forstår vi leverandørens PDR og FDR som overlevert til HBMN. Vi forutsetter her at HBMN gjennom sin funksjonsspesifikasjon har definert sine krav til en «god og driftssikker løsning». Kravene vil derfor være B6 kravene og B3 kravene i kontrakten. Oppgaven er derfor å sammenligne disse (relevante) kravene (til en god og driftsikker løsning) med leverandørens design av kravene (B06 FDR Nettverk og Trådløst nettverk [1]; B3 FDR Drift [5,7]). I kapittel 3.1 er leverandørens design av B6 kravene beskrevet. I dette kapitlet følger en gjennomgang av leverandørens design av B3 kravene. B3 Drift [3] i kontrakten innholder ikke krav merket med [Kx.y-n]. Det foreligger derfor etter hva vi kan se 3, heller ikke en kravtabell som viser korrespondansen mellom kravene til HBMN og leverandørens design av disse kravene. FDR Drift v2.0.doc [7] beskriver «design av overordnet driftsløsning for leveransen IKT Infrastruktur». Leverandøren har lagt ITILs rammeverk til grunn for å beskrive rutiner i driftsløsningen bl.a. ut fra følgende årsaker: ITIL (Information Technology Infrastructure Library) er en metode for å organisere datasystem og nettverksdrift. ITIL definerer arbeidet (prosessene) og grensesnittet mellom dem; det tilbyr et standardisert rammeverk rundt drift, og flere prosesser under ITIL understøttes av overvåkingsverktøy; bygger på et kvalitetssystem som er satt sammen av prosesser og prosedyrer. Vi støtter opp om bruken av ITILs rammeverk ( som den mest anerkjente og aksepterte «best practise» innen IT service management. ITIL som er inneholdt i ISO 20000, består av følgende prosesser: Service Management (reaktiv drift) fokuserer på at brukerne av IT teknologi har løpende tilgang på nødvendige IT baserte funksjoner/tjenester for støtte av virksomhetsprosessene: o Service desk o Incident management 3 Arkivet B3-FDR Drift [5] inneholder bare en prosjekteringsrapport og leverandørens FDR B3 driftsrapport.

12 Helsebygg Midt-Norge Side: 12 av 19 o Problem management o Configuration management o Change management o Release management Service Delivery (proaktiv drift) fokuserer på nødvendige forebyggende prosesser for at IT teknologien skal kunne gi forventet støtte til brukerne av denne IT teknologien: o Service level management o Capacity management o IT service continuity management o Availability management o Financial management for IT services Leverandøren har lagt ITIL tilgrunn i sin design av drift. Vi etterlyser derfor design av samtlige ITIL prosesser i B3-FDR Drift v2.0.doc, [7]. M8 [6] inneholder heller ikke design av samtlige ITIL prosesser. Leverandøren har lagt vekt på Service management og, etter hva vi skjønner, for eksempel unnlatt og beskrive IT service continuity management og Availability management. Vi savner også designet av en ITIL basert driftsorganisasjon som viser hvem gjør hva, hvem bidrar/deltar og hvem som er ansvarlig for godkjenning. FDR ble gjennomført til Driftsdokumentasjonen var ikke en del av leveransen, men ble først levert ved M8 [6] Ideelt sett burde driftsdokumentasjonen vært utarbeidet samtidig med designdokumentasjonen. Svar: Beskrevet løsning kan gi en god og driftsikker implementering i et operativt sykehus, selv om det i denne fasen av prosjektet mangler driftdesign av noen ITIL prosesser. Dette er mangler som vi forutsetter kommer på plass av en leverandør som ønsker å basere sin drift på ITILs rammeverk.

13 Helsebygg Midt-Norge Side: 13 av Hvilke risikoer er forbundet med de foreslåtte løsningene - hvor sårbar er løsningen? Kilder: [ R.08.RA-072 Sikkerhetsgjennomgang overordnet forsyning Tele og IT.doc ( ), 1] [Katastrofeplan for interne kriser og ulykker - overordnet del (v. 1.0)( ), 2] [Katastrofeplan for interne kriser og ulykker - aksjonsplaner (v. 1.2) ( ), 3] [Kick-off_00329_usikkerhet.xls ( ), ] [Prosjekthåndbok v0.9.doc ( ),5] [ B02-FDR Vedlegg 08 Sikkerhet og risikoanalyse.doc ( ), 6] [Rapport beredskap KB rev 01.pdf ( ),7] [Eval. Lab Rapport Kopi k2000 u.off.doc ( ), 8] [Evaluering Innflytting Ibruktakelse kopi K 2000 u off.doc ( ), 9] [Evaluering Innflytting Nevro Rapport versjon 0.1 K 2000.doc ( ), 10] [Ukentlige statusrapporter til , 11] [Månedlige statusrapporter til , 12] [Møtereferat IKT-råd for perioden til , 13] [Møtereferat kontraktsmøter for perioden til , 1] [ R.07.RA-01 Systemrevisjon Telenor.doc ( ), 15] [Forespørselen: B3 - Drift.doc, 16] [Kontrakten: B3 Opsjon Drift Beskrivelse v 1.0.doc, 17] [Møte med Beredskapsleder Håkon Gammelsæther, St. Olavs Hospital, , 18] [Møte med Stig Østensen, Telenor og Lars Ove Sæther, HP , 19] [RAPPORT ROS Flytting byggefase 1 rev 01.doc, ( ), 20] [2006 Sikkerhetsgjennomgang flytting til nevro ost pdf, 21]; [Rapport Sikkerhetsgjennomgang labsenter rev pdf, 22]; [Rapport Sikkerhetsgjennomgang kv-barnsenteret pdf, 23]; [Rapport Sikkerhetsgjennomgang Nevrosenteret del2 rev pdf, 2] Besvarelsen av spørsmålet er delt i 2; 1) Kartlegging og oppfølging av risiko og sårbarhet for løsningen og 2) Gjennomgang av risiko sett i forhold til design av nettverket Kartlegging og oppfølging av risiko og sårbarhet for løsningen Rapport for fase 1 kapittel beskriver viktige krav til god praksis innenfor risiko og sårbarhetsanalyser (ROS-analyser). Et forventet resultat fra Risiko og sårbarhetshåndtering vil være input til utarbeidelse eller oppdatering av beredskapsplaner. Vi kan forvente at ROS-analyser ble gjennomført og/eller oppdatert ved følgende tidspunkt i prosjektet: 1. Ved utarbeidelse av forespørsel 2. Ved evaluering av tilbud 3. Sammen med valgt leverandør i kontraktsfasen. Ved PDR 5. Ved FDR

14 Helsebygg Midt-Norge Side: 1 av Ved FAT 7. Ved SAT 8. Før idriftsettelse (prøvedrift) 9. Før innflytting 10. Ved endringer i krav eller design Punkt 1, 2 og 3 er behandlet i rapport for fase 1. I løpet av arbeidet med fase 2 er følgende dokumentasjon fremskaffet og vurdert: Tidspunkt : Ved PDR Ved oppstart av prosjekt, Kick-off_00329_usikkerhet []: Regnearket lister opp en del risikoer for prosjektet, prosjektgjennomføring og løsningen, men har få forslag til tiltak og ingen definerte ansvarlige eller frister for oppfølging. Risikoer knyttet til teknologi: Usikkerheter med beskrivelse Sans Kons Tiltak Mange nye produkter (teknologi i front) H L Noen uprøvde løsninger H L Tidlig testing av risikoelementer, fallback Feil i design - som får katastrofale konsekvenser L H Prosjekthåndbok [5] sier: Månedlig analyse av usikkerhet Med utgangspunkt i kartlegging gjort i kick-off, vil det gjøres detaljerte analyser pr. leveranseområde. Disse analysene vil oppdateres regelmessig. Status på tiltak for å håndtere usikkerhet vil implementeres som en del av den månedlige statusrapporteringen. Risikoelementer identifisert i anbudsprosessen Blant de viktigste risikoelementer som ble identifisert var følgende i uprioritert rekkefølge: (utdrag) Undervurderer vi implementering av ny teknologi i brukermiljøene? Løsningene som prosjektet skal levere er kritiske for liv og død I følge Leverandøren ble kartleggingen i [] tatt videre inn i dokument [6]. Se vurdering av dette under tidspunkt 5. Dokumentasjonen [],[5] viser hvordan kartlegging av risiko i prosjektet ble gjennomført frem til PDR. Dette ansees for å være akseptabelt under forutsetning av at ytterligere kartlegging og håndtering av risiko gjennomføres i perioden frem mot FDR. Tidspunkt 5: Ved FDR I dokument B02 Overordnet beskrivelse - Vedlegg 08 Sikkerhet og risikoanalyse [6] er risikoanalyse dokumentert. Her er flere av punktene i analysen ikke kommentert. Dette vises ved eksempel i tabellene nedenfor Telefoni# 3,,5,6,8 og Nettverk# 3,8,9,10,35,36.

15 Helsebygg Midt-Norge Side: 15 av 19 Spesielt alvorlig er det når det også gjelder hendelser med stor konsekvens der risiko er vurdert til middels. Dette vises ved eksempel i tabellene nedenfor Telefoni# 6,8 og Nettverk# 8,9,10,36. Rapporten inneholder flere forslag til tiltak, men det er ikke funnet spor av at disse tiltakene er fulgt opp i form av aksjonslister og statusrapporter. Dokumentet er heller ikke oppdatert i leveransen As built dokumentasjon. Eksempler på hendelser: Telefoni # Tilstand (årsak) Konsekvens (følge) Sanns. Kons. Risiko Reduksjon/tiltak 3 Strømbrudd hele sykehuset Telefonsystemet vil fungere så Lite Liten Lav lenge UPS leverer strøm. sannsynlig Rest risiko Strømbrudd i kommunikasjonsrom Som for #3 Lite sannsynlig Liten Lav 5 Kjøling i serverrom Utstyr i aktuellt serverrom kan bli utilgjengelige Lite sannsynlig Liten Lav 6 Nedetid på nettverk sentralt Telefonisystem er avhengig av nettverk og vil således være ute. Lite sannsynlig Svært stor Middels 7 Nedetid på kantswitch Del av telefonisystem som er tilknyttet aktuell kantswitch vil være nede Sannsynlig Middels Middels Bruke GSMtelefon som backup (Opsjon) Lav 8 Nedetid på WLAN Trådløs IP-telefoni er ute Sannsynlig Stor Middels Nettverk # Tilstand (årsak) Konsekvens (følge) S K BR Reduksjon/tiltak 1 Strømbrudd i et datarom Tjenester som ikke er dublert bortfaller. Lite sannsynlig Liten Lav Rest risiko 2 Strømbrudd i koblingsrom 3 Strømbrudd på et senter Senteret misterer ca 1/ av nettet Hele senteret blir uttilgjengelig Sannsynlig Middels Middels Kritiske systemene tenker redundans i forhold til to koblingsrom Lite Liten Lav sannsynlig Middels 5 Kjøling svikter i et datarom 6 Manglende fysisk sikkerhet Switcher og servere går ned på grunn av varme Sannsynlig Middels Middels Mobile vifter som kan plasseres ut i nødstilfeller(opsjon) Utstyr blir sabotert, stjålet. Sannsynlig Middels Middels Lav 7 Kabelbrudd i kulvert mellom lab og forsyning 8 Tap av forbindelse mellom St. Olav og DMF/NTNU/HIST 9 Tap av forbindelse mellom St. Olav og Norsk Helsenett 10 Tap av forbindelse mellom St. Olav og "gammel" St. Olav I verste fall mister du hele kommunikasjonen Har konsekvens for brukerne av nettet Alle intern brukere mister kontakten til fellestjenester og Internett Alle brukere på ny infrastruktur vil miste forbindelsen til tjenester i gammelt nett 35 Hardware feil Deler av nettverket blir utilgjengelige 36 Software feil Deler av nettverket blir utilgjengelige Lite sannsynlig Stor Middels Sørg for at fiberføringer går i alternative kulverter Sannsynlig Middels Middels Sannsynlig Middels Middels Sannsynlig Middels Middels Sannsynlig Liten Lav Sannsynlig Middels Middels Middels

16 Helsebygg Midt-Norge Side: 16 av 19 Risikoanalysen som danner grunnlag for dokumentet [6] ble gjennoført med representanter fra leverandør, HBMN og St. Olavs Hospital. Innholdet skulle derfor være kjent for alle parter. Leverandøren hadde ansvaret for å ta dokumentet videre som en del av leveransen. Månedsrapport Oktober [12]: *) Risikoanalysen som fremkom i FDR bearbeides videre og vil bli gjenstand for tiltak, overvåking og oppfølging. Månedsrapport November [12]: *) Risikoanalysen som fremkom i FDR er konvertert over til en database. Gjennomgås og oppdateres i forhold til tiltak, overvåking og oppfølging. Vil også bli oppdatert etter hvert som risikoanalyse for implementering ferdigstilles. I møte [19] kom det frem at all risiko ble tatt inn i en Risikodatabase og oppfølging av tekniske risikoer ble videreført i designfasen. Dokumentasjon av dette har ikke vært tilgjengelig for eksterne. Det fins ikke spor etter håndtering av eksemplet ovenfor i Statusrapporter og referater fra kontraktsmøter. Det ble i møtet bekreftet at saken ikke er behandlet som egen risiko videre. Vi antar at flere av punktene uten forslag til tiltak i [5] ikke er behandlet videre i kommunikasjonen mellom Telenor og HBMN. Vi mener at Telenor i denne fasen ikke i tilstrekkelig grad påpekte for HBMN og St. Olavs Hospital at leveransen hadde risiko som skulle vært håndtert i beredskapsplaner. I møtet kom det også frem at Telenor ikke hadde vært proaktiv nok i forhold til dette. Saken ble først ordentlig tatt opp ved kontraktsforhandlinger om drift med Hemit fra august til desember Konsekvensen av dette vil ikke bli vurdert ytterligere i denne gjennomgangen. HBMN gjennomførte en Systemrevisjon [15] av Telenor Det var ingen avvik/observasjoner relatert til ROS. Etter vår mening burde mangler ved ROS-arbeidet blitt avdekket. Tidspunkt 6: Ved SAT Det er ikke funnet ROS dokumentasjon. Tidspunkt 7: Før idriftsettelse (prøvedrift) Det er ikke funnet ROS dokumentasjon. Tidspunkt 8: Før innflytting Overordnet ROS-analyse [20] ble gjennomført for flytteprosjektet i desember Denne inneholder bl.a. en sjekkliste som må benyttes før innflytting. Risikoanalysen fokuserer på at alt skal virke som planlagt og opplæring må være gjennomført før innflytting. Det ble gjennomført Sikkerhetsgjennomganger før innflytting i sentrene ref [21],[22],[23],[2]. Her er risiko rundt IKT behandlet, men i hovedsak gjelder dette test av at alt virker som forutsatt. Tester av avvikssituasjoner og evaluering av konsekvens ved bortfall av data og telefoni er i liten grad behandlet. Det er imidlertid i løpet av gjennomgangene avdekket behov for backup av kommunikasjon ved at det er kjøpt inn mobiltelefoner og analoge fasttelefoner for utplassering på sentrale steder. Eksempel på forslag til tiltak i rapport for Nevro-senteret [2]: TELEFONI: Alle kritiske scenarier må tas inn i prøvedrift, testes og trenes. INTEGRASJON: Testing: Vurder behov for revidering av beredskapsplan på grunnlag av ibruktagelse av nye lokaler.

17 Helsebygg Midt-Norge Side: 17 av 19 St. Olavs Hospital gjennomførte en Beredskapsanalyse før innflytting/ibruktakelse på Kvinne- Barnsenteret [7]: Analysen hadde følgende hensikt: Danne grunnlag for den beredskap som skal etableres i forhold til uønskede hendelser umiddelbart før, under og umiddelbart etter flytting. Rapporten beskriver 2 scenarier i forhold til datanettverk og telefoni Scenarie 1. Svikt i IP-telefoni Scenarie. Svikt i data-system. - og kommer med forslag til tiltak basert på disse: Nr Forslag til tiltak Ansvarlig Frist 1 Feil og mangler i Plan for interne kriser og ulykker må rettes. 2 Varslingsrutine og prosedyrer for interne kriser og ulykker må gjøres kjent både for ansatte og for personell som er aktuelle for utkalling. 5 Hvis mobiltelefoner skal være backup for IP-telefoni, må det etableres lister med disse telefonnummerene (Det bør vurderes å ha et mobilnummer for hver avdeling, samt til kritisk nøkkelpersonell). Det må gå tydelig frem hvem som tar beslutning om overgang til reservesystem. Ved overgang til mobiltelefoni, må AMK varsles, og det må iverksettes varsling til øvrige deler av sykehuset, samt til sentralbordet. Rutinene må beskrives. 6 Det har tidligere vært en direktelinje mellom enkelte avdelinger og AMK: Det må undersøkes om dette videreføres i nytt senter. Systemet vil i så fall kunne fungere som en reservemulighet for å få tak i AMK, da dette er analoge linjer. 10 Etablere manuelle rutiner for svikt i enkelt-applikasjoner på IT der dette er mulig. Scenario med svikt i både data og telefoni er ikke behandlet i rapporten. Ingen av tiltakene har fått tildelt ansvarlig og frist for gjennomføring. Intern Katastrofeplan [2],[3] for St. Olavs Hospital (sist oppdatert ), er tilgjengelig på intranett og i egen perm. Utdrag fra Katastrofeplan - aksjonsplaner [3]: Svikt i telekommunikasjonssystemer. Dersom det oppstår svikt i telekommunikasjonslinjer finnes følgende beredskaps-prosedyre: Stentofon kan benyttes som backup for telefon for tilkalling av personell og akutt hjelp. Reservetelefoner, ved de enheter som har installert slike (se vedlegg), kan benyttes dersom både telefon og stentofon er ute av drift. Dersom alle kommunikasjonslinjer svikter, må det etableres manuell kurertjeneste for å sikre medisinsk forsvarlig drift. St. Olavs Hospital har serviceavtale med Telenor dersom det oppstår svikt i telenettet. Dersom svikt skyldes svikt i kraftforsyning, vil dette bli utbedret av Almenteknisk avdeling Svikt i sentrale IT systemer (utdrag) Enhetsledelsen har ansvar for at enheten har tilstrekkelig manuelle rutiner for å takle bortfall av sentrale ITsystemer Revisjon (utdrag) Sykehusets ledelse er ansvarlig for at planen settes i verk og at den revideres. Planen skal som et minimum revideres annethvert år, og i tillegg revideres ved større organisatoriske eller funksjonelle endringer.

18 Helsebygg Midt-Norge Side: 18 av 19.. Det er en forutsetning at alle avdelinger/funksjoner som omfattes av denne planen, også har utarbeidet avdelingsinterne planer som klart og detaljert beskriver hvilke oppgaver avdelingen/funksjonen har i en katastrofesituasjon, hvordan de skal utføres og av hvem. Den avdelingsinterne delen av planen skal til en hver tid være oppdatert mhp. organisasjon, tilgjengelige ressurser og bygningstekniske forhold. Avdelingsledelsen er ansvarlig for at dette oppfylles Øvelser og opplæring (utdrag) Sykehusledelsen har ansvar for at det drives opplæring og arrangeres øvelser slik at organisasjonen er forberedt på å fungere som skissert i Plan for kriser og interne ulykker. Det skal arrangeres katastrofeøvelser 2 ganger pr. år. Avdelingsledelsen er ansvarlig for intern opplæring i henhold til denne planen slik at hver enkelt medarbeider kjenner sin funksjon og får den nødvendige opplæring Basert på [2],[3] har St. Olavs Hospital et eget ansvar for å oppdatere beredskapsplaner og gjennomføre katastrofeøvelser. Den interne Katastrofeplanen er ikke oppdatert i forhold til ny infrastruktur. Forslag til tiltak om dette i [1] og [7] er ikke gjennomført. St. Olavs Hospital har dermed heller ikke gjennomført øvelser for å håndtere total svikt i tele- og datasystemet basert på ny infrastruktur. Verken sykehusets ledelse eller avdelingsledelse har fulgt opp sitt ansvar for revisjon av katastrofeplaner. I møte [18] ble det bekreftet at katastrofeplanene ikke var oppdatert. Evalueringrapporter etter flytting for Labsenteret [8], Kvinne-Barnsenteret [9] og Nevrosenterert [10] viser at St. Olavs Hospital vurderte risikoen som akseptabel ved innflytting, men at beredskap i forhold til IKT løsningen måtte forbedres og Feil og mangler i Plan for interne kriser og ulykker må rettes. Risiko for at både data og telefonsystemer skulle svikte er ikke behandlet. Tidspunkt 9: Ved endringer i krav eller design Vi har gjennomgått ukentlige statusrapporter [11], månedlige statusrapporter [12], møtereferater fra IKT-råd [13] og referater fra kontraktsmøter [1]. Det er gjennomført ROS-analyser for forskjellige forhold som er avdekket i håndtering av risikoområder. Det er ikke funnet spor etter oppfølging av risikoer som f.eks nedetid for nettverket. Ut fra dette kan man anta at risiko som må håndteres i en beredskapsplan ikke er godt nok behandlet i prosjektet. Leverandøren Telenor har som profesjonell part ikke sørget for oppfølging, HBMN har som mottaker ikke fulgt opp manglende ROS-analyser, slik at St. Olavs Hospital ville hatt et enda større trykk på seg for å oppdatere beredskapsplaner. Andre viktige risikoområder som ikke er behandlet: Drift av løsningen [16] var en opsjon i forespørselen og hadde få konkrete krav. Det var opp til tilbyder å beskrive hvordan de ville løse drift. [S.1-2] Tilbyder skal gi sin vurdering av de responstider som er skissert, og konsekvensene av å endre dem i den ene eller andre retning. I Telenors tilbud på opsjon drift [17], som ble tatt inn i kontrakten, ble ett av forslagene til responstid kommenter som følger: For hovedsystem vil en utbedringstid på 60 min være dårligere enn krav til 99% oppetid i løsningen.

19 Helsebygg Midt-Norge Side: 19 av 19 Det er ikke funnet spor etter vurdering av hvilken innvirkning den endelige driftsavtalens responstid ved drifts-ustabilitet ville ha for tilgjengeligheten av nettverket. En ROS-analyse ville kunne ytterligere påvirket behovet for kartlegging av St. Olavs Hospitals krav til løsningen og oppdatering av beredskapsplaner for å håndtere ny infrastruktur. Med utgangspunkt i St. Olavs Hospitals kritiske virksomhetsprosesser (eks. bruk av pasientkritiske system), burde det vært gjort en analyse av hva er konsekvensene for disse ved alvorlige driftforstyrrelser eller katastrofer, og hvilke løsninger er planlagt å eksistere for å reetablere normal driftsituasjon innenfor akseptable tidsgrenser. Vi savner også beskrivelse av alvorlige driftsituasjons scenarier og katastrofe scenarier som løsningen skal kunne ta høyde for og som leverandøren burde inkludert i sin design. Oppsummering: IKT prosjektet: Kartlegging av teknisk risiko er kun utført systematisk i forbindelse med FDR. Oppfølging av forslag til tiltak på en systematisk måte i form at aksjonslister med tidsfrister og ansvarlige og rapportering av status er ikke gjennomført. Flere risikoer har ikke forslag til tiltak. Noen av disse skulle vært kommunisert til brukerne for å kunne håndteres ved beredskapstiltak. Innflyttingsprosjektene: ROS-analyser er gjennomført. Analysene har fokusert på at alt skulle være testet og virke før innflytting. Det er bare i liten grad vurdert tiltak som sikrer backup ved utfall av telefoni og datanettverk. Beredskapsplaner er ikke oppdatert i forhold til ny infrastruktur Svar: Dokumentasjonen viser at kartlegging av risiko og sårbarhet ble gjennomført hos de forskjellige partene. De viktigste områdene ble avdekket og noen områder ble behandlet formelt, andre områder mindre formelt. Informasjon om risiko og sårbarhet for løsningen fra leverandøren Telenor til HBMN og videre til St. Olavs Hospital har ikke vært tilstrekkelig, selv om St. Olavs Hospital hadde et selvstendig ansvar for å vurdere risiko og sårbarhet for løsningen. Behovet for oppdatering av beredskapsplaner hos St. Olavs Hospital var avdekket i prosjektet, men forståelsen for å gjennomføre dette ville vært mye større med bedre informasjon om risiko i løsningen Gjennomgang av risiko sett i forhold til design av nettverket Datametrix har utarbeidet en egen rapport som vurderer tilgjengelig og risiko for nettverket. Denne vil være vedlegg til rapport for fase 3.