Hva er ISO 27002:2022 Control 8.28 on Secure Coding?
Dårlig kodingspraksis som feilaktig validering av inndata og svak nøkkelgenerering kan utsette informasjonssystemer for sikkerhetssårbarheter og resultere i cyberangrep og kompromittering av sensitive informasjonsressurser.
For eksempel i det beryktede Hjerteblødningsfeil, hackere utnyttet feilaktig inndatavalidering i koden for å få tilgang til mer enn 4 millioner pasientdata.
Derfor bør organisasjoner sørge for at sikre kodingsprinsipper følges slik at dårlig kodingspraksis ikke fører til sikkerhetssårbarheter.
Formål med kontroll 8.28
Kontroll 8.28 gjør det mulig for organisasjoner å forhindre sikkerhetsrisikoer og sårbarheter som kan oppstå som følge av dårlig programvarekodingspraksis ved å designe, implementere og gjennomgå passende kodeprinsipper for sikker programvare.
Attributttabell for kontroll 8.28
Kontroll 8.28 er en forebyggende type kontroll som hjelper organisasjoner å opprettholde sikkerheten til nettverk, systemer og applikasjoner ved å eliminere risikoer som kan oppstå på grunn av dårlig utformet programvarekode.
| Kontrolltype | Informasjonssikkerhetsegenskaper | Konsepter for cybersikkerhet | Operasjonelle evner | Sikkerhetsdomener |
|---|---|---|---|---|
| #Forebyggende | #Konfidensialitet | #Beskytte | #Applikasjonssikkerhet | #Beskyttelse |
| #Integritet | #System- og nettverkssikkerhet | |||
| #Tilgjengelighet |
ISO 27001 gjort enkelt
Et forsprang på 81 % fra dag én
Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på. Alt du trenger å gjøre er å fylle ut de tomme feltene.
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.
Frigjør deg fra et fjell av regneark
Bygg inn, utvid og skaler samsvarsstyringen din uten rot. IO gir deg robustheten og selvtilliten til å vokse sikkert.
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.
Administrer all samsvarskontroll, alt på ett sted
ISMS.online støtter over 100 standarder og forskrifter, og gir deg én enkelt plattform for alle dine samsvarsbehov.
Endringer og forskjeller fra ISO 27002:2013
27002:2022/8.28 er en ny type kontroll.
Nye ISO 27002 kontroller
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 5.7 | NEW | Trusselintelligens |
| 5.23 | NEW | Informasjonssikkerhet for bruk av skytjenester |
| 5.30 | NEW | IKT-beredskap for forretningskontinuitet |
| 7.4 | NEW | Fysisk sikkerhetsovervåking |
| 8.9 | NEW | Konfigurasjonsstyring |
| 8.10 | NEW | Sletting av informasjon |
| 8.11 | NEW | Datamaskering |
| 8.12 | NEW | Forebygging av datalekkasje |
| 8.16 | NEW | Overvåking av aktiviteter |
| 8.23 | NEW | Web-filtrering |
| 8.28 | NEW | Sikker koding |
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 6.1 | 07.1.1 | Screening |
| 6.2 | 07.1.2 | Vilkår og betingelser for ansettelsen |
| 6.3 | 07.2.2 | Informasjonssikkerhetsbevissthet, utdanning og opplæring |
| 6.4 | 07.2.3 | Disiplinær prosess |
| 6.5 | 07.3.1 | Ansvar etter oppsigelse eller endring av arbeidsforhold |
| 6.6 | 13.2.4 | Avtaler om konfidensialitet eller taushetsplikt |
| 6.7 | 06.2.2 | Fjernarbeid |
| 6.8 | 16.1.2, 16.1.3 | Informasjonssikkerhet hendelsesrapportering |
| ISO/IEC 27002:2022 kontrollidentifikator | ISO/IEC 27002:2013 kontrollidentifikator | Kontrollnavn |
|---|---|---|
| 7.1 | 11.1.1 | Fysiske sikkerhetsomkretser |
| 7.2 | 11.1.2, 11.1.6 | Fysisk inngang |
| 7.3 | 11.1.3 | Sikring av kontorer, rom og fasiliteter |
| 7.4 | NEW | Fysisk sikkerhetsovervåking |
| 7.5 | 11.1.4 | Beskyttelse mot fysiske og miljømessige trusler |
| 7.6 | 11.1.5 | Arbeid i sikre områder |
| 7.7 | 11.2.9 | Oversiktlig skrivebord og oversiktlig skjerm |
| 7.8 | 11.2.1 | Utstyrsplassering og beskyttelse |
| 7.9 | 11.2.6 | Sikkerhet av eiendeler utenfor lokaler |
| 7.10 | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | Lagringsmedier |
| 7.11 | 11.2.2 | Støtteverktøy |
| 7.12 | 11.2.3 | Kablingssikkerhet |
| 7.13 | 11.2.4 | Vedlikehold av utstyr |
| 7.14 | 11.2.7 | Sikker avhending eller gjenbruk av utstyr |
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.
