VEDLEGG 7 SIKKERHET 1. KRAV TIL SIKRING AV DATAFILER VED OVERFØRING TIL/FRA BANKEN

Transkript

1 VEDLEGG 7 SIKKERHET 1. KRAV TIL SIKRING AV DATAFILER VED OVERFØRING TIL/FRA BANKEN 1.1 Sikkerhetskravene bygger på at det til enhver tid skal være et 1 til 1-forhold mellom det som er registrert i Virksomhetens økonomisystem og i Bankens systemer. Dette skal for henholdsvis inn- og utbetalinger oppnås ved de rutinene som er omtalt i Vedlegg 1 og 2. For å sikre integriteten og autentisiteten til Filene som utveksles mellom Banken og Virksomheten, skal de beskyttes ved hjelp av forsegling (elektronisk signatur). Dette gjelder uavhengig av på hvilken måte Filen utveksles. Kravet om forsegling gjelder for Filer som inneholder Betalingsoppdrag og stoppeoppdrag til Banken. Kravet kan også gjelde for Filer som inneholder informasjon fra Banken til Virksomheten om innbetalinger (Konteringsdata) og for Filer med avregningsoppdrag fra Banken til Norges Bank. Det forutsettes at kryptering. elektronisk identifisering og sikkerehtsløsninger er i samsvar med gjeldende krav for offentlig sektor og felles kravspsifikasjon for PKI i offentlig sektor. 1.2 Forseglingen skal skje ved å legge ved en digital signatur basert på innholdet som skal beskyttes mot ikke-autorisert endring. Den digitale signaturen genereres ved å beregne en kontrollsum (hash-verdi) basert på innholdet i Filen, som så krypteres med en krypteringsnøkkel og legges ved på avsatt felt på slutten av Filen. Et Betalings-/stoppeoppdrag (Batch) skal enten forsegles fortløpende etter hvert som rekordene i oppdraget genereres, eller ved at genereringen av oppdraget avsluttes ved at systemet automatisk og umiddelbart starter forseglingsprosessen. I all hovedsak vil én Fil være lik et Betalings-/stoppeoppdrag. I de tilfellene en Fil inneholder flere oppdrag, skal hvert oppdrag forsegles fortløpende eller umiddelbart etter at det er generert. Seglet skal omfatte alle rekorder i Filen fra startrekord til og med rekorden før den rekorden som skal inneholde seglet (dersom seglet ligger i samme Fil). Unntak for seglberegning kan gjøres for norsk tegnsett (æ, ø, å) og eventuelle spesialtegn. De tegnene som tas med i beregningen av seglet, skal representere faste verdier og være uavhengig av det tegnsettet som nyttes på den maskinen som genererer seglet. 1.3 Beskyttelsesmekanismene bør være basert på åpne standarder. Det er krypteringsnøklene og algoritmene som skal gi den nødvendige beskyttelse, ikke hemmelighold av sikkerhetsmekanismen i seg selv. 1

2 Nøkler brukt til kryptering kan være symmetriske eller asymmetriske, eller kombinasjoner av disse. Normalt vil løsninger der asymmetriske nøkler og/eller digitale sertifikater inngår som en del av løsningen, ansees som det mest hensiktsmessige. Sikkerheten i hash- og krypteringsalgoritmer som benyttes, skal kunne dokumenteres av Banken. Algoritmene må støtte nøkkellengder og hash-verdilengder som er tilstrekkelige til å oppnå ønsket sikkerhetsnivå. Symmetrisk kryptering, eksempelvis SIGILL el.l., brukt til forsegling av datafiler anses å være en de facto standard blant norske banker. Nøkkeladministrasjon skal være basert på ett av følgende alternativer: en til en-forhold der Banken og Virksomheten selv håndterer sine nøkler en Public Key Infrastructure (PKI) basert på bruk av digitale sertifikater For at en PKI-løsning skal kunne benyttes ved leveranser under Avtalen, må Banken dokumentere at løsningen gir tilstrekkelig: teknisk sikkerhet klarhet i ansvar, roller, rutiner og prosedyrer. Dette skal ikke bare gjelde de tekniske løsninger, men også ansvaret for selve betalingstransaksjonen oppfyllelse av relevante standarder god nok interoperabilitet og kommersiell tilgjengelighet av maskin- og programvare 1.4 Forsegling med bruk av SIGILL-metoden el.l. innebærer en symmetrisk kryptering. Den hemmelige nøkkelen lages derfor i par hvor Virksomheten skal ha den ene nøkkelen og Banken den andre. Det skal til enhver tid minimum benyttes 2 hemmelige nøkkelpar; ett par som nyttes når det er Virksomheten som forsegler og Banken som kontrollerer, og ett par når Banken forsegler og Virksomheten kontrollerer. Virksomhet og Banken vil normalt ha ansvaret for minimum ett hemmelig nøkkelpar hver. Banken kan etter avtale med Virksomheten ha ansvar for begge nøkkelparene. Dette ansvaret omfatter produksjon og forsendelse av initiell nøkkel og reservenøkler og styring av skifte av reservenøkkel. Initiell nøkkel: Ved første gangs bruk skal den hemmelige nøkkelen utveksles manuelt mellom partene og legges manuelt inn i systemene både hos Virksomheten og hos Banken. Den initielle nøkkelen samt en reservenøkkel skal utveksles mellom partene i lukket konvolutt, adressert til den som skal legge nøkkelen(e) inn i systemet. Dersom konvolutten som inneholder nøklene skal sendes fram pr. post, skal den sendes rekommandert. Når den hemmelige nøkkelen er lagt inn i systemet hos Banken, skal den ikke kunne hentes fram igjen/vises i klartekst i noe skjermbilde. 2

3 Lagring av hemmelig nøkkel: Banken skal oppbevare sin hemmelige nøkkel i kryptert form. Eventuelt kan annen oppbevaringsmåte nyttes forutsatt at Banken kan godtgjøre tilsvarende sikkerhetsnivå som ved kryptering. Bytte av hemmelig nøkkel: En hemmelig nøkkel skal bare kunne nyttes til å forsegle én gang, og bytte av den hemmelige nøkkelen skal skje automatisk. Den parten som nytter en hemmelig nøkkel til å forsegle et oppdrag, skal automatisk lage et tilfeldig tall (slumptall) som skal sendes med som en del av oppdraget. Dette slumptallet skal både avsender og mottaker av oppdraget (Batch) nytte til å lage en ny hemmelig nøkkel. Den nye hemmelige nøkkelen skal erstatte den nøkkelen som nettopp ble brukt, og skal nyttes ved forsegling av det neste oppdraget som krever forsegling. Banken skal avvise Betalings-/stoppeoppdraget dersom det ikke inneholder opplysninger (bl.a. slumptallet) som gir grunnlag for beregning av ny nøkkel. Feil ved kontroll av seglet, bruk av reservenøkkel: Dersom det ved kontrollen av et forseglet oppdrag blir avdekket feil i forseglingen, skal avsenderen av oppdraget underrettes om dette i Mottaksreturen og oppdraget forkastes. Før det forkastede oppdraget kan forsøkes laget på nytt av avsenderen, må både avsender og mottaker bytte den hemmelige nøkkelen. Både avsender og mottaker skal ha samme hemmelig nøkkel i reserve som tas i bruk i slike tilfeller. Den parten som nytter en hemmelig nøkkel til å forsegle et oppdrag som så sendes den andre parten, har ansvaret for at partene også har utvekslet en hemmelig nøkkel i reserve. Nødvendige reservenøkler kan utveksles og oppbevares av partene i lukket, forseglet konvolutt. Dersom partene utveksler reservenøkler pr. post, må den forseglede konvolutten som inneholder reservenøkkelen legges i et nytt omslag og den bør sendes rekommandert. En slik konvolutt skal bare kunne inneholde én hemmelig reservenøkkel. Banken skal utarbeide egen rutine for en sikker oppbevaring av konvolutter som inneholder reservenøkler og en prosedyre for når og hvordan en slik reservenøkkel tas i bruk, samt prosedyre for produksjon og forsendelse av ny reservenøkkel. Reservenøklene kan også oppbevares elektronisk, dersom de lagres like sikkert som de hemmelige nøklene som er i bruk. Det skal etableres sikre rutiner for når og hvordan en elektronisk lagret reservenøkkel, tas i bruk. Etter at reservenøkkelen er lagt inn av begge parter, må senderen av datafilen (oppdraget) generere Filen på nytt og sende den. 2. KRAV TIL SIKKERHET I BANKENS BEDRIFTSTERMINALSYSTEMER 2.1 Banken skal i sitt bedriftsterminalsystem ha en sikkerhetsløsning hvor brukerne i Virksomheten kan defineres med bl.a. følgende rettigheter: 3

4 lese informasjon om stoppoppdrag og ikke-utbetalte Betalingsoppdrag som også viser om en Transaksjon eventuelt er forkastet (ikke-godkjent), autorisert eller stoppet autorisere Betalingsoppdrag, jf. Vedlegg 2 punkt 5 stoppe Betalingsoppdrag, jf. Vedlegg 2 punkt 7.1 lese kontoopplysninger, jf. Vedlegg 4 punkt 1.5 Det skal ikke gis tilgang til on-line remittering av Betalingsoppdrag. Kontroll mot fullmaktsregisteret skal skje automatisk. Sikkerhetsløsningen skal således bl.a. sikre at bare de som skal ha adgang til systemet kan logge seg på, og at bare de som har slik fullmakt kan autorisere Betalingsoppdrag. Det skal foreligge en skriftlig avtale mellom Virksomheten og Banken. Avtalen skal regulere hvilke personer i Virksomheten som skal ha hvilke brukerrettigheter i systemet. Banken har ansvaret for at den enkelte brukerens rettigheter til enhver tid er korrekt registrert og tilgangsbeskyttet i Bedriftsterminaler. Banken skal sørge for at tilknytningen er åpen for alminnelig bruk i Virksomhetens ordinære arbeidstid. 2.2 Ved pålogging til Bedriftsterminaler skal det som et minimum nyttes brukeridentifikasjon og et passord som endres dynamisk ved bruk av passordkort. Alternativt kan det nyttes annen autentisering dersom denne gir minimum samme sikkerhet. Hver fullmaktshaver og/eller bruker i Virksomheten skal da motta et passordkort (eller tilsvarende) fra Banken. Passordkort skal sendes rekommandert adressert til brukeren eller utleveres direkte til brukeren. For å kunne bruke et passordkort skal det måtte "åpnes" ved hjelp av en personlig kode (PIN-kode). 2.3 Ved Autorisasjon av Betalingsoppdrag, skal hvert oppdrag autoriseres via Bedriftsterminalen av en person i Virksomheten med slik fullmakt (alternativt av to personer jf. punkt Vedlegg 2 punkt 5). Autoriseringen skal logges, jf. dette Vedlegg punkt 3. Pålogging til bedriftsterminalsystemet og Autorisasjon av Betalingsoppdrag skal skje som to sekvenser slik at pålogging og Autorisasjon skjer ved bruk av hvert sitt unike passord. 2.4 Automatisk avlogging For å sikre mot uautorisert bruk av Bedriftsterminalen, skal systemet hos Banken automatisk logge av en pålogget bruker, dersom Banken ikke mottar noen kommandoer fra brukeren innenfor en tidsperiode på maksimalt 15 minutter. 4

5 3. KRAV TIL LOGGING 3.1 Banken skal logge innholdet i alle Betalingsoppdrag og stoppeoppdrag som Banken mottar, samt logge on-line stoppeinformasjon på en slik måte at nødvendige data kan hentes fram ved eventuelle uoverensstemmelser mellom Virksomheten og Banken. Bankens journalfunksjon (juridiske logg) skal også minimum registrere når ulike brukere har logget seg inn og ut av bedriftsterminalsystemet. Ved Autorisasjon av Betalingsoppdrag skal følgende data logges: Unike verdier for Betalingsoppdraget, dato, klokkeslett, hvem som autoriserte og at den som autoriserte ble korrekt identifisert ved et dynamisk passord generert av vedkommendes passordkort, eller identifisert ved bruk av en annen autentiseringsmetode med tilsvarende sikkerhet. Virksomheten skal på anmodning kunne få utskrift av de lagrede dataene for å etterprøve hvem som har utført Autorisasjonen. Dersom systempersonell med vidtgående brukeradgang ("superbrukere") av produksjonsmessige årsaker er nødt til å foreta oppretting direkte i Bankens produksjonssystem, og i den sammenhengen eventuelt nytte spesielle verktøy, skal det logges brukernavn, tidspunkt, før- og etterverdier av de dataene som prosesseres på statens vegne, og eventuelle referanser til dokumentasjon som legitimerer endringene. Slike loggposter, og loggfiler hvis postene splittes opp i flere filer, skal nummereres fortløpende. 5