Ivareta sikkerhet i anskaffelses- og utviklingsprosesser

Neste

Ivareta sikkerhet i anskaffelses- og utviklingsprosesser

Målet med prinsippet: Sikkerhet er en integrert del av prosessene for anskaffelse og utvikling og virksomheten minimerer risiko for at nye IKT-produkter og IKT-tjenester innfører konfigurasjonsmessige og arkitekturmessige sårbarheter.

Hvorfor er dette viktig?

IKT-sikkerhet er viktig i alle IKT-produkter og IKT-tjenester, ikke kun ved anskaffelse av rene sikkerhetsprodukter som en brannmur. Dersom en virksomhet anskaffer IKT-produkter og IKTtjenester som har svak sikkerhet eller som ikke integrerer godt med virksomhetens øvrig sikkerhetsarkitektur og eksisterende IKT-produkter, kan dette øke sårbarheten og redusere sikkerhetsnivået i IKT-systemet.

Dersom virksomheten mangler gode prosesser for utvikling, test, verifisering og implementering vil sannsynligheten være stor for at sårbarhetene ikke blir oppdaget. Kostnaden ved å rette opp i dette i etterkant er ofte høyere enn kostnaden ved gode forberedelser.

Anbefalte tiltak: Ivareta sikkerhet i anskaffelses- og utviklingsprosesser

Anbefalte tiltak: Ivareta sikkerhet i anskaffelses- og utviklingsprosesser
ID	Beskrivelse
	Anskaffelse av IKT-produkter
2.1.1	Integrer sikkerhet i virksomhetens prosess for anskaffelser. Fastsett krav til IKT-sikkerhet ved anskaffelse av alle IKT-produkter og IKT-tjenester, se prinsipp 2.2 - Etabler en sikker IKT-arkitektur. Inkluder sikkerhet i hele livsløpet fra anskaffelse til avhending.
2.1.2	Kjøp moderne og oppdatert maskin- og programvare slik at nyere sikkerhetsfunksjonalitet er innebygd. Sørg for a) å kun benytte IKT-produkter som støttes og mottar sikkerhetsoppdateringer fra leverandør b) å kun anskaffe IKT-produkter som inneholder nyere sikkerhetsfunksjonalitet og protokoller og c) at eldre IKT-produkter fases ut. d) Der det er hensiktsmessig bør man be leverandør (som kjenner IKT-produktet best) i) å informere om risikoer og sårbarheter produktet kan utsettes for og ii) spesifisere nærmere hvordan IKT-produktet kan sikkerhetsherdes og beskyttes.
2.1.3	Foretrekk IKT-produkter som er sertifiserte og evaluert av en tiltrodd tredjepart. Et eksempel på et sertifiseringsregime er Common Criteria4.
2.1.4	Reduser risiko for målrettet manipulasjon av IKT-produkter i leverandørkjeden. a) Virksomheter bør vurdere risiko for om de kan bli utsatt for slike målrettede angrep. b) Be nasjonale forhandlere/importører vise diskresjon, og ikke videreformidle for mye kundeinformasjon, f.eks. kundenavn, hvordan produktet skal benyttes, hvem som skal benytte produktet, hvor produktet skal benyttes. c) Beskytt produktintegritet til fysiske produkter (i dialog med nasjonale forhandlere/importører) så tidlig som mulig i leverandørkjeden. Produkter bør inspiseres av alle nasjonale ledd (også hos kunden før produksjonssetting) for brutte forseglinger og oppbevares slik at kun et begrenset sett av personell har fysisk adgang. d) Programvare-produkter bør kun lastes ned fra leverandørens offisielle webside (kun via https). Virksomheten bør oppbevare all installasjonsprogramvare i fil-mapper hvor kun installasjonsansvarlig har skriverettigheter. e) Leverandørers fysiske adgang ifm. vedlikehold av IKT-produkter bør reguleres og kontrolleres.
	Utvikling og test mht. egen programvareutvikling
2.1.5	Benytt en metode for sikker utvikling av programvare for å redusere sårbarhetene i programvaren. Dette inkluderer: a) Hensiktsmessig planlegging, inkludert virksomhetens behov, rammebetingelser, IKT-sikkerhets hensyn og behov for opplæring av personell. b) Analyse av brukerbehov, inkludert IKT-sikkerhetskrav. c) Design av programvare basert på fastsatte krav, d) Utvikling av programvaren, inkludert sikker koding og testing (se 2.1.6 og 2.1.7). e) Implementasjon og idriftsetting av programvaren. f) Sikkerhetsmessig forvaltning av programvaren, bl.a. i) planlegge for gjennomføring og distribusjon av sikkerhetsoppdateringer og ii) planlegge støtte for nyere og mer tidsriktig sikkerhetsfunksjonalitet.
2.1.6	Benytt separate miljøer for utvikling, test og produksjon slik at operative virksomhetsprosesser og data ikke blir påvirket ved feil i utviklings- og testløp. Vurder også soneinndeling som beskrevet i tiltak 2.2.3. Sensitive produksjonsdata bør bare benyttes på utviklings- og testmiljø som er sikret.
2.1.7	Gjennomfør tilstrekkelig med testing gjennom hele utviklingsprosessen. Gjør dette slik at feil, sårbarheter og mangler rettes opp før idriftsetting. a) Dette inkluderer test av at sikkerhetsfunksjonalitet fra forskjellige berørte IKT-produkter fungerer godt sammen, ref. prinsipp 2.2 - Etabler en sikker IKT-arkitektur, samt enhetstesting, integrasjonstesting, systemtest, akseptansetest, pilottest, inntrengingstest(prinsipp 0) og stresstest. b) Utfør kontroll på at kun tillate handlinger virker samt stikkprøver på at andre handlinger blir avvist.
2.1.8	Vedlikehold programvarekode som utvikles/benyttes i virksomheten. a) Ha en utviklingsprosess som inneholder metodisk sikkerhetsvurdering av koden. b) Vær spesielt oppmerksom på kode som har spesiell betydning for sikkerheten, f.eks. kode for i) tilgangskontroll, ii) kryptering av trafikk, iii) logging, iv) «parsing» av bruker-input, v) «buffer overflow», med mer. Se [2] og [9]. c) Ved bruk av offentlig tilgjengelig kode («open source») og kommersielle «toolkits» bør virksomheten regelmessig (fortrinnsvis automatisk) sjekke for nye versjoner. d) Ved bruk av DevOps/DevSecOps bør også sikkerhetssjekk av egen kode automatiseres der det er hensiktsmessig. Spesielt sikkerhetsrelevant kode (ref. forrige punkt) bør kvalitetssikres.
	Tjenesteutsetting - herunder bruk av skytjenester
2.1.9	Ta ansvar for virksomhetens sikkerhet også ved tjenesteutsetting. Dette inkluderer å a) ha oversikt og kontroll på hele livsløpet til tjenesten(e) som skal settes ut, b) ivareta behovet for bestillerkompetanse (f.eks. forvaltning-, administrasjon- og ITarkitekturkompetanse) gjennom hele livsløpet til tjenesteutsettingen c) gjennomføre gode risikovurderinger som inkluderer IKT og hensyntar hele livsløpet, d) utarbeide et kravdokument for alle faser av tjenesteutsettingen hvor krav kan verifiseres, e) avtaler om tjenesteutsetting av IKT-tjenester og endringer i slike avtaler skal behandles i henhold til virksomhetens fullmaktsstruktur. Se også kapittel I - Bruk av tjenesteutsetting og skytjenester og [1]. Det understrekes at virksomhetens ansvar for sikkerheten ikke forsvinner selv om man tjenesteutsetter. Virksomheten har et ansvar uavhengig av hvem som utfører de forskjellige oppgavene.
2.1.10	Undersøk sikkerheten hos tjenesteleverandør ved tjenesteutsetting. Det bør som minimum undersøkes om leverandøren: a) har et etablert styringssystem for informasjonssikkerhet og eventuelt sertifisering i henhold til internasjonale standarder, for eksempel ISO/IEC 27001:2017. b) gir innsyn i sikkerhetsarkitekturen som benyttes for å levere tjenesten. c) har utviklingsplaner for fremtidig sikkerhetsfunksjonalitet i tjenestene i tråd med utvikling i teknologi og trusselbildet over tid. d) har en oversikt over hvem som skal ha innsyn i virksomhetens informasjon, hvor og hvordan denne skal behandles og lagres samt grad av mekanismer for segregering fra andre kunder. e) har sikkerhetsfunksjonalitet som tilfredsstiller virksomhetens behov. f) har sikkerhetsovervåkning for å avdekke sikkerhetshendelser som kan påvirke virksomheten. g) har rutiner for hendelseshåndtering og avviks- og sikkerhetsrapportering. h) har krise- og beredskapsplaner som skal harmonisere med virksomhetens egne planer. i) har godkjenningsprosedyrer for bruk av underleverandører og deres bruk av underleverandører. j) har spesifisert hvilke aktiviteter som skal utføres ved terminering av kontrakten, blant annet tilbakeføring/flytting/sletting av virksomhetens informasjon. Les mer i NSMs rapporter om tjenesteutsetting, se [1].

Utdypende informasjon

DevOps/DevSecOps er begreper som er blitt stadig mer aktuelt ifm. utvikling av programvare, kanskje spesielt i forbindelse med tjenester. I korthet går det ut på å utføre kodeendringer som påføres et system i produksjon relativt raskt uten tradisjonelle prosesser med adskillelse som nevnt i 2.1.6. Av navnet ser man at det tradisjonelle skillet på utvikling («Development») og drift («Operations») viskes ut, ofte også organisatorisk. Dersom virksomheten benytter DevOps bør man være ekstra påpasselig med at det ikke innføres sårbarheter som kan påvirke forretningsprosesser. Akkurat som utvikling og drift blir mer automatisert, så bør sikkerhetsprosedyrene for å identifisere programvarekode med sårbarheter også i økende grad automatiseres. Som minimum bør man være mer grundig med kode som har spesiell betydning for sikkerheten.