Markedsundersøkelse (RFI) for anskaffelse av Datamodul/ferjedatabank

Leverandøren skal sikre at all aktivitet logges på en slik måte at det er mulig å avdekke sikkerhetshendelser som potensielt bryter med konfidensialitet, integritet, tilgjengelighet og personvern. Loggingen skal minimum inneholde loggingstrategi, loggformater, sikkerhetslogger, sporingslogg, driftslogg og overvåkingslogg.

Det skal være mulig å søke etter logger og sammenstille resultater på tvers av loggkilder for seneste 3 måneder minimum.

Leverandøren skal sørge for gode passordrutiner for å sikre at passord håndteres på en sikker og pålitelig måte. Dette inkluderer passordpolicy, passordlagring, passordhåndtering og passordsikkerhet, inkludert krav om multifaktor autentisering (MFA).

Ekstern tilgang skal ha sikker multi-faktor autentisering aktivert for alle administratorbrukere. Følg anerkjent standard for sikker implementasjon av MFA.

Det skal implementeres multi-faktor autentisering for alle kontoer som er eksternt eksponert.

Statens vegvesen bruker Id-porten som hovedmekanisme for MFA for eksternt eksponerte tjenester. Dersom ikke Id-Porten planlegges brukt, må det sannsynliggjøres at alternativ mekanisme gir tilsvarende sikkerhet.

Tjenesten for autentisering skal konfigureres slik at antall påloggingsforsøk er sterkt begrenset. Ved for mange mislykkede forsøk skal brukerkontoen automatisk bli deaktivert.

Passord skal som hovedregel aldri distribueres via SMS, eller andre ukrypterte kanaler, men opprettes av brukeren i det aktuelle systemet. Dersom det likevel er nødvendig å bruke et førstegangs-, midlertidig passord som må deles med brukeren, skal det midlertidige passordet skal være helt unikt og ha begrenset gyldighet.

Datasentrene skal beskyttes med fysiske sikkerhetsperimetere (gjerder/vakter/overvåkning/låser) og det er kun autoriserte personell som har tilgang.

Statens vegvesen har et sentralt tilgangsstyringssystem som bør benyttes for pålogging av interne brukere og være "Single Signon" (SSO).

Det skal finnes et sentralisert system for å opprette, oppdatere, deaktivere og slette brukerkontoer, fjerne tilganger fra brukerkontoer som er inaktive eller avsluttet og tilbakestille glemte, tapte eller stjålne brukernavn og passord.

Det skal være tydelig definerte grupper eller roller for tilgang til ressurser som for eksempel applikasjoner, datamaskiner, utstyr og nettverk. Rollene skal ha navn og beskrivelser som tydelig angir hva slags rettigheter og tilganger som medlemskap i den aktuelle rollen gir. Det skal om nødvendig opprettes flere roller pr. ressurs slik at prinsippet om begrensning kan gjennomføres og vedlikeholdes effektivt.

Feil og unntak i applikasjonen skal håndteres i koden slik at feil oppdages og kan adresseres raskt og effektivt. Detaljert teknisk informasjon skal ikke presenteres for brukeren, men erstattes av en informativ melding som brukeren kan forholde seg til.

Kildekode skal beskyttes mot uautorisert tilgang og endring gjennom egnet tilgangsstyring og andre nødvendige sikkerhetstiltak.

Alle brukere, programmer og prosesser skal ha så få rettigheter som mulig i systemet (Principle of least privileges). I utgangspunktet skal det ikke være noen rettigheter før det blir gitt eksplisitt (Default deny).

Integrasjoner skal gjøres på en måte som sikrer kontroll på dataflyt, integritet og konfidensialitet ende til ende, forhindrer «man-in-the-middle» angrep, skadelig innhold og utilsiktet kommunikasjonsflyt.

Sensitiv og personlig informasjon, PIN koder og passord bør lagres utenom applikasjonens krypterte og beskyttede lagringsområde beregnet på lagring av sensitiv informasjon. Data skal beskyttes mot lekkasje via skjermdump, minnelekkasje, trådløs overføring (IPC), "screen overlay attacks" og forsøk på datainnbrudd. Se OWASP MASVS V2: Data Storage and Privacy Requirements for detaljert kravliste.

Mobilapplikasjon skal være beskyttet mot debugging, de-kompilering og mot å bli kjørt på en kompromittert enhet ("Rooted"/"jailbraked" device). Styrken på kontrolltiltakene skal være tilpasset trusselnivået og risikoene i applikasjonen. Se OWASP MASVS "Resilience Control Objectives" for mer detaljer.

Virksomhetskritiske og sensitive data bør kun behandles innenfor EU, og dataflyt skal være dokumentert. Se også personvernkravene for personopplysninger.

Statens vegvesens produksjonsdata skal ikke benyttes i, eller kopieres til andre miljøer, eksempelvis for test eller utvikling av andre tjenester uten avtale med SVV. Benytt kun fellestjenester for overføring av data slik at virksomheten alltid har kontroll og sporing av dataoverføringer.

Alle lagringsmedium for operasjonelle data og analytiske data skal være kryptert i henhold til gjeldende standarder. Dette omfatter data i bruk av konfigurasjon, applikasjon og infrastruktur, samt alle data som avledes av disse. Lagringsmedium er alle faste installerte samt virtuelle og mobile lagringsmedium. Lagring på eksterne, flyttbare lagringsmedia som USB og NAS enheter skal forhindres, eller kontrolleres ved at innholdet krypteres. Data krypteres under migrering av den virtuelle maskiner.

Data skal være beskyttet mot uautorisert tilgang og innsyn under opprettelse, transport, behandling og lagring. Strengt beskyttet informasjon skal være kryptert under transport og ved lagring utenfor virksomhetens internt kontrollerte infrastruktur.

Alle lagringsmedia brukt til lagring av SVV sine data skal behandles på en måte som gjør at ikke uvedkommende kan hente ut eller gjenopprette data. Det betyr at lagringsmediet må slettes ved overskriving og gjenbrukes hos SVV. Dersom lagringsmediet skal skiftes ut eller avhendes må det avmagnetiseres eller ødelegges helt før det fysisk forlater SVV sin lokasjon.

Data og konfigurasjoner skal sikkerhetskopieres med jevne mellomrom i henhold til virksomhetens behov. Sikkerhetskopieringen skal være automatisert. Integritetssjekk av sikkerhetskopiene og varsling ved en eventuelt feilet sikkerhetskopiering bør være automatisert. Dersom dataeier ikke har utarbeidet en konkret plan, bør det som minimum tas en daglig sikkerhetskopi av alle data. Hvis sikkerhetskopiering ligger eksternt hos partner eller tredjepart må leverandør vise til avtale og hvordan tredjepart sikrer dataene.

All data med behov for gjenskaping skal speiles mellom et primærsted og et sekundærsted for sikker oppbevaring. Systemeier skal velge en oppbevaringspolicy for sikkerhetskopien fra listen over oppbevaringspolicier i arbeidet med verdivurderingen som bestemmer hvilken oppbevaringstid en sikkerhetskopi skal ha.

Test sikkerhetskopier regelmessig ved å utføre gjenopprettingstest av hele systemer og data i systemet.

Sikkerhetskopier skal oppbevares på en slik måte at de ikke kan slettes av en mulig angriper eller påvirkes av lokale sikkerhetshendelser og ødeleggelser som brann, vannskader, sabotasje eller innbrudd. Det bør være mulig å skrive til backup destinasjon, men ikke endre eller slette. Det bør i tillegg finnes sikkerhetskopier som er lagret på et sted som er totalt frakoblet det øvrige nettverket ("air gap") og som er på an adskilt geografisk lokasjon.

Nettverket skal være beskyttet mot tjenestenektangrep (DDOS).

Det skal inngås nødvendig databehandleravtale etter GDPR for bruk av Tjenesten.

Kundens Data skal ikke lagres, behandles eller gjøres tilgjengelige fra Russland, Kina, Iran eller Nord-Korea. Kravet omfatter blant annet fjernaksess, support, drift, sikkerhetskopiering, gjenoppretting og behandling hos underdatabehandlere. Dersom endringer i nasjonale sikkerhetsvurderinger gjør det nødvendig å utvide listen over stater, skal dette håndteres etter kontraktens bestemmelser om sikkerhet og endringshåndtering.

Leverandøren bes gi en beskrivelse av den geografiske dataflyten for Kundens Data og personopplysninger. Beskrivelsen skal omfatte lagring, behandling, sikkerhetskopiering, support, drift, gjenoppretting og annen tilgang. Alle stater utenfor EU/EØS som data overføres til, eller hvorfra data kan gjøres tilgjengelige, skal navngis. Beskrivelsen skal også omfatte enkeltstående og unntaksvise tilganger og behandling hos underdatabehandlere. Besvarelsen skal ta utgangspunkt i Tjenestens standardkonfigurasjon ved levering til Kunden. Dersom det ikke forekommer overføringer til eller tilganger fra stater utenfor EU/EØS, skal Leverandøren bekrefte dette.

Dersom personopplysninger overføres til eller gjøres tilgjengelige fra stater utenfor EU/EØS, skal Leverandøren redegjøre for overføringsgrunnlaget etter personvernforordningen kapittel V for hver enkelt overføring som er angitt i besvarelsen av PEO-03. Redegjørelsen skal angi involverte rettssubjekter, mottakerstat, behandlingsaktivitet og om overføringen bygger på en adekvansbeslutning, EU-U.S. Data Privacy Framework, standard personvernbestemmelser eller annet lovlig overføringsgrunnlag.

Leverandøren bes beskrive de behandlingsaktivitetene hvor Leverandøren anser seg som selvstendig behandlingsansvarlig eller felles behandlingsansvarlig med Kunden for Kundens Data og personopplysninger. Beskrivelsen bør inneholde formål, kategorier personopplysninger, behandlingsgrunnlag og lagringstid for behandlingsaktivitetene. Dersom Leverandøren anser seg som felles behandlingsansvarlig med Kunden, skal avtale etter personvernforordningen artikkel 26 legges ved. Dersom Leverandøren ikke vil opptre som behandlingsansvarlig eller felles behandlingsansvarlig for Kundens Data og personopplysninger, skal dette bekreftes.

Kundens mal for databehandleravtale er vedlagt som Bilag XX Statens vegvesens databehandleravtale. Dersom Tjenesten forutsetter at Kunden må inngå databehandleravtaler som ikke er basert på Kundens mal, skal Leverandøren legge ved kopi av disse databehandleravtalene. Leverandøren skal tydelig angi og begrunne avvik fra Kundens mal. Avvikene vil bli evaluert ut fra hvilken personvernrisiko og hvilke kontraktsmessige eller praktiske begrensninger de medfører for Kunden.

Leverandøren skal gi en oversikt over underdatabehandlere som skal eller kan benyttes ved levering av Tjenesten. Oversikten skal omfatte hele leverandørkjeden. For hver underdatabehandler skal det oppgis: 1) foretaksnavn og organisasjonsnummer eller tilsvarende identifikasjon, 2) plass i leverandørkjeden, 3) tjenester og behandlingsaktiviteter, 4) kategorier av personopplysninger, 5) behandlings- og lagringslokasjoner og 6) stater hvorfra opplysningene kan gjøres tilgjengelige.

Leverandøren skal beskrive rutiner og mekanismer som sikrer at Kunden til enhver tid har en oppdatert oversikt over underdatabehandlere. Beskrivelsen, herunder varslet, bør medføre at Kunden kan vurdere endringen og eventuelt protestere i samsvar med personvernforordningen artikkel 28 nr. 2 og databehandleravtalen. Leverandøren skal opplyse om varslingsfrist og hvordan eventuelle protester håndteres.

Leverandøren skal beskrive hvordan Tjenesten ivaretar innebygd personvern og personvern som standardinnstilling, jf. personvernforordningen artikkel 25. Beskrivelsen bør særlig redegjøre for hvordan Tjenesten støtter formålsbegrensning, dataminimering, riktighet, lagringsbegrensning, konfidensialitet og ansvarlighet.

Leverandøren skal opplyse om Tjenesten, herunder deler av Tjenesten, benytter KI eller maskinlæring. Dersom KI benyttes, skal Leverandøren opplyse om hvilke funksjoner som benytter KI, formålet med bruken, hvilke personopplysninger og datakilder som benyttes, hvilke modeller eller modelltyper som inngår, og hvilke eksterne leverandører som er involvert. Dersom Tjenesten ikke benytter KI, skal dette bekreftes. Leverandøren skal varsle Kunden før KI-funksjonalitet introduseres eller vesentlig endres.

Kundens Data, personopplysninger, og data som genereres ved Kundens bruk av Tjenesten, skal ikke benyttes til trening, finjustering, evaluering eller annen forbedring av KI-modeller uten særskilt skriftlig avtale med Kunden. Kravet gjelder også behandling hos underdatabehandlere og andre modell- eller tjenesteleverandører.