ISO 27002:2022, Controle 8.28 – Veilige codering

Eigendom van zeggenschap 8.28

Gezien het feit dat 8.28 het ontwerp en de implementatie van veilige coderingsprincipes en -procedures voor de hele organisatie vereist, moet de Chief Information Security Officer verantwoordelijk zijn voor het nemen van passende stappen voor naleving.

Algemene richtlijnen voor naleving

Controle 8.28 vereist dat organisaties organisatiebrede processen voor veilige codering opzetten en implementeren die van toepassing zijn op zowel softwareproducten verkregen van externe partijen als op open source softwarecomponenten.

Bovendien moeten organisaties op de hoogte blijven van zich ontwikkelende beveiligingsbedreigingen in de echte wereld en van de meest recente informatie over bekende of potentiële kwetsbaarheden in de softwarebeveiliging. Dit zal organisaties in staat stellen robuuste, veilige softwarecoderingsprincipes te verbeteren en te implementeren die effectief zijn tegen zich ontwikkelende cyberdreigingen.

Aanvullend richtsnoer voor planning

De principes voor veilige softwarecodering moeten worden gevolgd, zowel voor nieuwe codeerprojecten als voor hergebruik van software.

Deze principes moeten worden nageleefd, zowel voor interne softwareontwikkelingsactiviteiten als voor de overdracht van de softwareproducten of -diensten van de organisatie aan derden.

Bij het opstellen van een plan voor veilige coderingsprincipes en het bepalen van de voorwaarden voor veilige codering moeten organisaties aan het volgende voldoen:

• Organisaties moeten beveiligingsverwachtingen bepalen die zijn afgestemd op hun behoeften en goedgekeurde principes vaststellen voor veilige softwarecodering die van toepassing zijn op zowel interne softwareontwikkeling als uitbestede softwarecomponenten.
• Organisaties moeten de meest voorkomende en historische slechte codeerontwerppraktijken en fouten die resulteren in een compromittering van de informatiebeveiliging, opsporen en documenteren.
• Organisaties moeten softwareontwikkelingstools opzetten en configureren om de veiligheid van alle gecreëerde code te garanderen. Een voorbeeld van dergelijke tools zijn geïntegreerde ontwikkelomgevingen (IDE).
• Organisaties moeten ervoor zorgen dat de richtlijnen en instructies van softwareontwikkeltools worden nageleefd.
• Organisaties moeten ontwikkelingstools zoals compilers beoordelen, onderhouden en veilig gebruiken.

Aanvullende richtlijnen voor beveiliging tijdens het coderen

Bij veilige codeerpraktijken en -procedures moet bij het codeerproces rekening worden gehouden met het volgende:

• De principes van veilige softwarecodering moeten worden afgestemd op elke gebruikte programmeertaal en -techniek.
• Inzet van veilige programmeertechnieken en -methoden, zoals testgestuurde ontwikkeling en pair programming.
• Gebruik van gestructureerde programmeermethoden.
• Goede codedocumentatie en verwijdering van codedefecten.
• Verbod op het gebruik van onveilige softwarecoderingsmethoden, zoals niet-goedgekeurde codevoorbeelden of hardgecodeerde wachtwoorden.

In de aanvullende richtlijnen wordt ook opgemerkt dat beveiligingstests zowel tijdens als na de ontwikkeling moeten worden uitgevoerd in overeenstemming met Controle 8.29.

Voordat organisaties de software daadwerkelijk gaan gebruiken in de live applicatieomgeving, moeten ze het volgende overwegen:

• Wat is het aanvalsoppervlak?
• Wordt het beginsel van de minste privileges gevolgd?
• Het uitvoeren van een analyse van de meest voorkomende programmeerfouten en het documenteren dat deze risico's zijn geëlimineerd.

Aanvullend richtsnoer voor het beoordelingsproces

Nadat de code in gebruik is genomen in de productieomgeving

• Updates moeten op een veilige manier worden toegepast.
• Kwetsbaarheden in de beveiliging die worden gemeld in overeenstemming met Controle 8.8 moeten worden aangepakt.
• Vermoedelijke aanvallen op informatiesystemen en fouten moeten worden vastgelegd en deze gegevens moeten met regelmatige tussenpozen worden beoordeeld, zodat passende wijzigingen in de code kunnen worden aangebracht.
• Ongeautoriseerde toegang tot, gebruik van of wijzigingen in de broncode moeten worden voorkomen via mechanismen zoals beheertools.

Wanneer organisaties externe tools gebruiken, moeten ze rekening houden met het volgende

• Externe bibliotheken moeten regelmatig worden gecontroleerd en bijgewerkt op basis van hun releasecycli.
• Softwarecomponenten moeten zorgvuldig worden doorgelicht, geselecteerd en geautoriseerd, met name cryptografie- en authenticatiecomponenten.
• Licentieverlening voor externe componenten en waarborgen van de veiligheid ervan.
• Software moet worden gevolgd en onderhouden. Bovendien moet ervoor worden gezorgd dat de gegevens afkomstig zijn van een betrouwbare bron.
• Ontwikkelingsmiddelen moeten voor de lange termijn beschikbaar zijn.

Wanneer u wijzigingen aanbrengt in een softwarepakket, moet u rekening houden met het volgende

• Risico's die kunnen voortvloeien uit ingebouwde controles of het in gevaar brengen van integriteitsprocessen.
• Of de leverancier toestemming geeft voor wijzigingen.
• Of het mogelijk is om toestemming te krijgen van de softwareleverancier voor regelmatige updates.
• De waarschijnlijke impact van het voortzetten van het onderhoud van de software die voortvloeit uit veranderingen.
• Of de wijzigingen compatibel zouden zijn met andere softwarecomponenten die door de organisatie worden gebruikt.

Aanvullend richtsnoer voor controle 8.28

Organisaties moeten ervoor zorgen dat veiligheidsrelevante code wordt gebruikt wanneer dit nodig is en bestand is tegen manipulatie.

Control 8.28 vermeldt ook de volgende aanbevelingen voor beveiligingsrelevante code:

• Hoewel programma's die via binaire code zijn geïnstalleerd, beveiligingsrelevante code bevatten, is dit beperkt tot de gegevens die in de applicatie zelf zijn opgeslagen.
• Het concept van beveiligingsrelevante code is alleen nuttig wanneer de code wordt uitgevoerd op een server die niet toegankelijk is voor de gebruiker, gescheiden is van de processen die er gebruik van maken en de gegevens ervan veilig in een andere database worden bewaard. U kunt bijvoorbeeld een geïnterpreteerde code uitvoeren op een cloudservice en de toegang tot code kan worden beperkt tot bevoorrechte beheerders. Het wordt aanbevolen dat u deze toegangsrechten beschermt via methoden zoals just-in-time beheerdersrechten en robuuste authenticatiemechanismen.
• Er moeten geschikte configuraties op webservers worden geïmplementeerd om ongeoorloofde toegang tot en bladeren door de directory te voorkomen.
• Bij het ontwerpen van applicatiecode moet u ervan uitgaan dat de code kwetsbaar is voor aanvallen als gevolg van codeerfouten en acties van kwaadwillende actoren. U moet kritische applicaties zo ontwerpen dat ze niet kwetsbaar zijn voor interne fouten. De output die door een algoritme wordt geproduceerd, kan bijvoorbeeld worden beoordeeld om er zeker van te zijn dat het voldoet aan de beveiligingsvereisten voordat het kan worden gebruikt in kritische toepassingen zoals financiële toepassingen.
• Bepaalde webapplicaties zijn zeer kwetsbaar voor veiligheidsrisico's als gevolg van slechte codeerpraktijken zoals database-injectie en cross-site scripting-aanvallen.
• Organisaties moeten de ISO/IEC 15408-serie raadplegen voor meer informatie over IT-beveiligingsevaluatie.

Wijzigingen en verschillen ten opzichte van ISO 27002:2013

27002:2022/8.28 is een nieuw type besturing.

Hoe ISMS.online helpt

Ons platform is speciaal ontwikkeld voor degenen die nieuw zijn op het gebied van informatiebeveiliging of een gemakkelijke manier nodig hebben om ISO 27002 te leren kennen zonder tijd te hoeven besteden aan het helemaal opnieuw leren of het doorlezen van lange documenten.

ISMS.Online wordt geleverd met alle tools die nodig zijn om naleving te bereiken, inclusief documentsjablonen, checklists en beleid dat kan worden aangepast aan uw behoeften.

Wilt u zien hoe het werkt?

Neem vandaag nog contact op met boek een demo.