ISO 27002:2022, Kontroll 8.28 – Sikker koding

Eierskap til kontroll 8.28

Tatt i betraktning at 8.28 krever utforming og implementering av organisasjonsomfattende sikre kodingsprinsipper og -prosedyrer, bør informasjonssikkerhetssjefen være ansvarlig for å ta passende skritt for samsvar.

Generell veiledning om samsvar

Kontroll 8.28 krever at organisasjoner etablerer og implementerer organisasjonsomfattende prosesser for sikker koding som gjelder både programvareprodukter hentet fra eksterne parter og programvarekomponenter med åpen kildekode.

I tillegg bør organisasjoner holde seg oppdatert med nye sikkerhetstrusler i den virkelige verden og med den nyeste informasjonen om kjente eller potensielle sikkerhetssårbarheter i programvaren. Dette vil gjøre det mulig for organisasjoner å forbedre og implementere robuste kodeprinsipper for sikker programvare som er effektive mot nye cybertrusler.

Utfyllende veiledning om planlegging

Sikker programvarekodingsprinsipper bør følges både for nye kodeprosjekter og for gjenbruk av programvare.

Disse prinsippene bør følges både for interne programvareutviklingsaktiviteter og for overføring av organisasjonens programvareprodukter eller tjenester til tredjeparter.

Ved etablering av en plan for sikker koding og fastsettelse av forutsetninger for sikker koding, bør organisasjoner overholde følgende:

• Organisasjoner bør fastsette sikkerhetsforventninger skreddersydd til deres behov og etablere godkjente prinsipper for sikker programvarekoding som vil gjelde både intern programvareutvikling og outsourcede programvarekomponenter.
• Organisasjoner bør oppdage og dokumentere de mest utbredte og historisk dårlige kodedesignpraksisene og feilene som resulterer i kompromittering av informasjonssikkerhet.
• Organisasjoner bør sette på plass og konfigurere programvareutviklingsverktøy for å sikre sikkerheten til all kode som lages. Et eksempel på slike verktøy er integrerte utviklingsmiljøer (IDE).
• Organisasjoner bør oppnå samsvar med veiledningen og instruksjonene gitt av programvareutviklingsverktøy.
• Organisasjoner bør gjennomgå, vedlikeholde og sikkert bruke utviklingsverktøy som kompilatorer.

Supplerende veiledning om sikkerhet under koding

Sikker kodingspraksis og prosedyrer bør ta hensyn til følgende for kodingsprosessen:

• Sikker programvarekodingsprinsipper bør skreddersys til hvert programmeringsspråk og teknikk som brukes.
• Utplassering av sikre programmeringsteknikker og metoder som testdrevet utvikling og parprogrammering.
• Bruk av strukturerte programmeringsmetoder.
• Riktig kodedokumentasjon og fjerning av kodefeil.
• Forbud mot bruk av usikre programvarekodingsmetoder som ikke-godkjente kodeeksempler eller hardkodede passord.

Supplerende veiledning bemerker også at sikkerhetstesting bør utføres både under og etter utviklingen i henhold til Kontroll 8.29.

Før programvaren tas i bruk i live-applikasjonsmiljøet, bør organisasjoner vurdere følgende:

• Hva er angrepsflaten?
• Følges prinsippet om minste privilegium?
• Gjennomføre en analyse av de mest utbredte programmeringsfeilene og dokumentere at disse risikoene er eliminert.

Supplerende veiledning om gjennomgangsprosess

Etter at koden er tatt i bruk i produksjonsmiljøet

• Oppdateringer bør brukes på en sikker måte.
• Sikkerhetssårbarheter rapportert i tråd med kontroll 8.8 bør løses.
• Mistenkte angrep på informasjonssystemer og feil bør registreres, og disse postene bør gjennomgås med jevne mellomrom, slik at passende endringer i koden kan gjøres.
• Uautorisert tilgang til, bruk av eller endringer i kildekoden bør forhindres via mekanismer som administrasjonsverktøy.

Når organisasjoner bruker eksterne verktøy, bør de ta hensyn til følgende

• Eksterne biblioteker bør overvåkes og oppdateres med jevne mellomrom basert på utgivelsessyklusene deres.
• Programvarekomponenter bør kontrolleres, velges og autoriseres nøye, spesielt kryptografi- og autentiseringskomponenter.
• Lisensering av eksterne komponenter og sikring av deres sikkerhet.
• Programvare bør spores og vedlikeholdes. Videre må det sikres at det kommer fra en pålitelig kilde.
• Utviklingsressurser bør være tilgjengelig på lang sikt.

Når du gjør endringer i en programvarepakke, bør følgende vurderes

• Risikoer som kan oppstå på grunn av innebygde kontroller eller kompromittering av integritetsprosesser.
• Hvorvidt leverandøren gir samtykke til endringer.
• Om det er mulig å få samtykke fra programvareleverandøren for regelmessige oppdateringer.
• Den sannsynlige virkningen av å fortsette vedlikeholdet av programvaren som oppstår som følge av endringer.
• Om endringene vil være kompatible med andre programvarekomponenter som brukes av organisasjonen.

Ytterligere veiledning om kontroll 8.28

Organisasjoner bør sørge for at sikkerhetsrelevant kode brukes når det er nødvendig og er motstandsdyktig mot tukling.

Kontroll 8.28 viser også følgende anbefalinger for sikkerhetsrelevant kode:

• Mens programmer installert via binær kode inkluderer sikkerhetsrelevant kode, er dette begrenset til dataene som er lagret i selve applikasjonen.
• Konseptet med sikkerhetsrelevant kode er bare nyttig når koden kjøres på en server som ikke er tilgjengelig for brukeren og den er adskilt fra prosessene som bruker den og dens data holdes sikkert i en annen database. Du kan for eksempel kjøre en tolket kode på en skytjeneste og tilgang til kode kan begrenses til privilegerte administratorer. Det anbefales at du beskytter disse tilgangsrettighetene via metoder som just-in-time administratorrettigheter og robuste autentiseringsmekanismer.
• Passende konfigurasjoner på webservere bør implementeres for å forhindre uautorisert tilgang til og surfing i katalogen.
• Når du designer applikasjonskode, bør du starte med antagelsen om at koden er sårbar for angrep på grunn av kodefeil og handlinger fra ondsinnede aktører. Du bør designe kritiske applikasjoner på en måte som ikke er sårbare for interne feil. For eksempel kan utdataene som produseres av en algoritme gjennomgås for å sikre at den samsvarer med sikkerhetskravene før den kan brukes i kritiske applikasjoner som finansrelaterte applikasjoner.
• Enkelte nettapplikasjoner er svært sårbare for sikkerhetstrusler på grunn av dårlig kodingspraksis som databaseinjeksjon og skriptangrep på tvers av nettsteder.
• Organisasjoner bør henvise til ISO/IEC 15408-serien for mer informasjon om IT-sikkerhetsevaluering.

Endringer og forskjeller fra ISO 27002:2013

27002:2022/8.28 er en ny type kontroll.

Hvordan ISMS.online hjelper

Plattformen vår er utviklet spesielt for de som er nye innen informasjonssikkerhet eller trenger en enkel måte å lære om ISO 27002 uten å måtte bruke tid på å lære fra bunnen av eller lese gjennom lange dokumenter.

ISMS.Online er utstyrt med alle verktøyene som trengs for å oppnå samsvar, inkludert dokumentmaler, sjekklister og retningslinjer som kan tilpasses etter dine behov.

Vil du se hvordan det fungerer?

Ta kontakt i dag for å bestill en demo.