ISO 27002:2022, Kontrol 8.28 – Sikker kodning

Ejerskab af kontrol 8.28

I betragtning af, at 8.28 kræver udformning og implementering af sikre kodningsprincipper og -procedurer for hele organisationen, bør informationssikkerhedschefen være ansvarlig for at tage passende skridt til overholdelse.

Generel vejledning om overholdelse

Kontrol 8.28 kræver, at organisationer etablerer og implementerer organisationsdækkende processer for sikker kodning, der gælder både softwareprodukter opnået fra eksterne parter og open source-softwarekomponenter.

Ydermere bør organisationer holde sig ajour med udviklingen af ​​sikkerhedstrusler fra den virkelige verden og med de seneste oplysninger om kendte eller potentielle sikkerhedssårbarheder i software. Dette vil gøre det muligt for organisationer at forbedre og implementere robuste sikre softwarekodningsprincipper, der er effektive mod cybertrusler, der udvikler sig.

Supplerende vejledning om planlægning

Sikker softwarekodningsprincipper bør følges både for nye kodningsprojekter og for genbrug af software.

Disse principper bør overholdes både for interne softwareudviklingsaktiviteter og for overførsel af organisationens softwareprodukter eller -tjenester til tredjeparter.

Når organisationer etablerer en plan for sikker kodningsprincipper og fastlægger forudsætningerne for sikker kodning, bør organisationer overholde følgende:

• Organisationer bør fastlægge sikkerhedsforventninger skræddersyet til deres behov og etablere godkendte principper for sikker softwarekodning, der vil gælde for både intern softwareudvikling og outsourcede softwarekomponenter.
• Organisationer bør opdage og dokumentere de mest udbredte og historisk dårlige kodningsdesignpraksis og fejl, der resulterer i kompromittering af informationssikkerhed.
• Organisationer bør etablere og konfigurere softwareudviklingsværktøjer for at sikre sikkerheden for al kode, der oprettes. Et eksempel på sådanne værktøjer er integrerede udviklingsmiljøer (IDE).
• Organisationer bør opnå overholdelse af vejledningen og instruktionerne fra softwareudviklingsværktøjer.
• Organisationer bør gennemgå, vedligeholde og sikkert bruge udviklingsværktøjer såsom compilere.

Supplerende vejledning om sikkerhed under kodning

Sikker kodningspraksis og -procedurer bør tage hensyn til følgende for kodningsprocessen:

• Sikker softwarekodningsprincipper bør skræddersyes til hvert programmeringssprog og anvendte teknikker.
• Implementering af sikre programmeringsteknikker og -metoder såsom testdrevet udvikling og parprogrammering.
• Brug af strukturerede programmeringsmetoder.
• Korrekt kodedokumentation og fjernelse af kodefejl.
• Forbud mod brug af usikre softwarekodningsmetoder såsom ikke-godkendte kodeeksempler eller hårdkodede adgangskoder.

Supplerende vejledning bemærker også, at sikkerhedstest skal udføres både under og efter udviklingen i overensstemmelse med kontrol 8.29.

Inden softwaren tages i brug i live-applikationsmiljøet, bør organisationer overveje følgende:

• Hvad er angrebsfladen?
• Følges princippet om mindste privilegium?
• Gennemføre en analyse af de mest udbredte programmeringsfejl og dokumentere, at disse risici er elimineret.

Supplerende vejledning om gennemgangsprocessen

Efter at koden er taget i brug i produktionsmiljøet

• Opdateringer bør anvendes på en sikker måde.
• Sikkerhedssårbarheder rapporteret i overensstemmelse med kontrol 8.8 bør løses.
• Formodede angreb på informationssystemer og fejl bør registreres, og disse optegnelser bør gennemgås med jævne mellemrum, så der kan foretages passende ændringer af koden.
• Uautoriseret adgang til, brug af eller ændringer af kildekoden bør forhindres via mekanismer såsom administrationsværktøjer.

Når organisationer bruger eksterne værktøjer, bør de tage hensyn til følgende

• Eksterne biblioteker bør overvåges og opdateres med regelmæssige intervaller baseret på deres udgivelsescyklusser.
• Softwarekomponenter skal være omhyggeligt undersøgt, udvalgt og godkendt, især kryptografi- og autentificeringskomponenter.
• Licensering af eksterne komponenter og sikring af deres sikkerhed.
• Software skal spores og vedligeholdes. Desuden skal det sikres, at det kommer fra en pålidelig kilde.
• Udviklingsressourcer bør være tilgængelige på lang sigt.

Når du foretager ændringer i en softwarepakke, bør følgende overvejes

• Risici, der kan opstå som følge af indbyggede kontroller eller kompromittering af integritetsprocesser.
• Om sælgeren giver samtykke til ændringer.
• Om det er muligt at få samtykke fra softwareleverandøren til regelmæssige opdateringer.
• Den sandsynlige indvirkning af at fortsætte vedligeholdelsen af ​​softwaren, der opstår som følge af ændringer.
• Om ændringerne ville være kompatible med andre softwarekomponenter, som bruges af organisationen.

Yderligere vejledning om kontrol 8.28

Organisationer bør sikre, at sikkerhedsrelevant kode bruges, når det er nødvendigt og er modstandsdygtig over for manipulation.

Kontrol 8.28 viser også følgende anbefalinger for sikkerhedsrelevant kode:

• Mens programmer installeret via binær kode inkluderer sikkerhedsrelevant kode, er dette begrænset til de data, der er gemt i selve applikationen.
• Begrebet sikkerhedsrelevant kode er kun nyttigt, når kode køres på en server, der ikke er tilgængelig for brugeren, og den er adskilt fra de processer, der bruger den, og dens data opbevares sikkert i en anden database. For eksempel kan du køre en fortolket kode på en skytjeneste, og adgang til kode kan begrænses til privilegerede administratorer. Det anbefales, at du beskytter disse adgangsrettigheder via metoder såsom just-in-time administratorrettigheder og robuste godkendelsesmekanismer.
• Passende konfigurationer på webservere bør implementeres for at forhindre uautoriseret adgang til og browsing af biblioteket.
• Når du designer applikationskode, bør du starte med den antagelse, at koden er sårbar over for angreb på grund af kodefejl og handlinger fra ondsindede aktører. Du bør designe kritiske applikationer på en måde, så de ikke er sårbare over for interne fejl. For eksempel kan output produceret af en algoritme gennemgås for at sikre, at det overholder sikkerhedskravene, før det kan bruges i kritiske applikationer såsom finansrelaterede applikationer.
• Visse webapplikationer er meget sårbare over for sikkerhedstrusler på grund af dårlig kodningspraksis, såsom databaseinjektion og scriptangreb på tværs af websteder.
• Organisationer bør henvise til ISO/IEC 15408-serien for mere information om IT-sikkerhedsevaluering.

Ændringer og forskelle fra ISO 27002:2013

27002:2022/8.28 er en ny type kontrol.

Hvordan ISMS.online hjælper

Vores platform er udviklet specifikt til dem, der er nye inden for informationssikkerhed eller har brug for en nem måde at lære om ISO 27002 uden at skulle bruge tid på at lære fra bunden eller gennemlæse lange dokumenter.

ISMS.Online er udstyret med alle de værktøjer, der er nødvendige for at opnå overholdelse, inklusive dokumentskabeloner, tjeklister og politikker, som kan tilpasses efter dine behov.

Vil du se, hvordan det fungerer?

Kontakt i dag for book en demo.