ISO 27002:2022 – Contrôle 8.28 – Codage sécurisé

Qu'est-ce que la norme ISO 27002:2022 Contrôle 8.28 sur le codage sécurisé ?

De mauvaises pratiques de codage telles qu'une validation d'entrée incorrecte et une génération de clé faible peuvent exposer les systèmes d'information à des vulnérabilités de sécurité et entraîner des cyberattaques et la compromission d'informations sensibles.

Par exemple, dans le fameux Incident de bug Heartbleed, les pirates ont exploité une validation incorrecte des entrées dans le code pour accéder à plus de 4 millions de données de patients.

Par conséquent, les organisations doivent veiller à ce que les principes de codage sécurisé soient suivis afin que de mauvaises pratiques de codage n’entraînent pas de failles de sécurité.

Objectif du contrôle 8.28

Control 8.28 permet aux organisations de prévenir les risques de sécurité et les vulnérabilités pouvant résulter de mauvaises pratiques de codage de logiciels en concevant, en mettant en œuvre et en révisant les principes de codage de logiciels sécurisés appropriés.

Attributs Table de contrôle 8.28

Control 8.28 est un type de contrôle préventif qui aide les organisations à maintenir la sécurité des réseaux, des systèmes et des applications en éliminant les risques pouvant découler d'un code logiciel mal conçu.

Propriété du contrôle 8.28

Étant donné que l'article 8.28 exige la conception et la mise en œuvre de principes et de procédures de codage sécurisé à l'échelle de l'organisation, le responsable de la sécurité de l'information devrait être responsable de prendre les mesures appropriées pour assurer la conformité.

Orientations générales sur la conformité

Le contrôle 8.28 exige que les organisations établissent et mettent en œuvre des processus à l'échelle de l'organisation pour un codage sécurisé qui s'applique à la fois aux produits logiciels obtenus auprès de parties externes et aux composants logiciels open source.

En outre, les organisations doivent se tenir informées de l’évolution des menaces de sécurité réelles et des informations les plus récentes sur les vulnérabilités de sécurité logicielles connues ou potentielles. Cela permettra aux organisations d’améliorer et de mettre en œuvre des principes de codage de logiciels sécurisés et efficaces contre l’évolution des cybermenaces.

Orientations supplémentaires sur la planification

Les principes de codage sécurisé des logiciels doivent être suivis à la fois pour les nouveaux projets de codage et pour les opérations de réutilisation de logiciels.

Ces principes doivent être respectés à la fois pour les activités de développement de logiciels internes et pour le transfert des produits ou services logiciels de l'organisation à des tiers.

Lors de l’établissement d’un plan pour les principes de codage sécurisé et de la détermination des conditions préalables au codage sécurisé, les organisations doivent se conformer aux éléments suivants :

• Les organisations doivent déterminer les attentes en matière de sécurité adaptées à leurs besoins et établir des principes approuvés pour le codage logiciel sécurisé qui s'appliqueront à la fois au développement logiciel interne et aux composants logiciels externalisés.
• Les organisations doivent détecter et documenter les mauvaises pratiques et erreurs de conception de codage les plus répandues et historiques qui entraînent une compromission de la sécurité des informations.
• Les organisations doivent mettre en place et configurer des outils de développement logiciel pour garantir la sécurité de tout le code créé. Un exemple de tels outils est celui des environnements de développement intégrés (IDE).
• Les organisations doivent se conformer aux conseils et instructions fournis par les outils de développement logiciel.
• Les organisations doivent examiner, maintenir et utiliser en toute sécurité les outils de développement tels que les compilateurs.

Conseils supplémentaires sur la sécurité pendant le codage

Les pratiques et procédures de codage sécurisé doivent prendre en compte les éléments suivants pour le processus de codage :

• Les principes de codage de logiciels sécurisés doivent être adaptés à chaque langage de programmation et techniques utilisés.
• Déploiement de techniques et méthodes de programmation sécurisées telles que le développement piloté par les tests et la programmation en binôme.
• Utilisation de méthodes de programmation structurées.
• Documentation appropriée du code et suppression des défauts du code.
• Interdiction d'utiliser des méthodes de codage de logiciels non sécurisées telles que des échantillons de code non approuvés ou des mots de passe codés en dur.

Les instructions supplémentaires indiquent également que les tests de sécurité doivent être effectués pendant et après le développement conformément au contrôle 8.29.

Avant d'utiliser réellement le logiciel dans l'environnement d'application en direct, les organisations doivent prendre en compte les éléments suivants :

• Quelle est la surface d’attaque ?
• Le principe du moindre privilège est-il respecté ?
• Effectuer une analyse des erreurs de programmation les plus répandues et documenter que ces risques ont été éliminés.

Orientations supplémentaires sur le processus d'examen

Une fois le code mis en œuvre dans l'environnement de production

• Les mises à jour doivent être appliquées de manière sécurisée.
• Les vulnérabilités de sécurité signalées conformément au contrôle 8.8 doivent être corrigées.
• Les attaques suspectées contre les systèmes d'information et les erreurs doivent être enregistrées et ces enregistrements doivent être examinés à intervalles réguliers afin que les modifications appropriées puissent être apportées au code.
• L'accès non autorisé, l'utilisation ou les modifications du code source doivent être empêchés via des mécanismes tels que des outils de gestion.

Lorsque les organisations utilisent des outils externes, elles doivent prendre en compte les éléments suivants

• Les bibliothèques externes doivent être surveillées et mises à jour à intervalles réguliers en fonction de leurs cycles de publication.
• Les composants logiciels doivent être soigneusement vérifiés, sélectionnés et autorisés, en particulier les composants de cryptographie et d'authentification.
• Licence des composants externes et garantie de leur sécurité.
• Le logiciel doit être suivi et entretenu. De plus, il faut s'assurer qu'il provient d'une source fiable.
• Les ressources de développement doivent être disponibles à long terme.

Lorsque vous apportez des modifications à un progiciel, les éléments suivants doivent être pris en compte

• Risques pouvant découler de contrôles intégrés ou de compromission des processus d’intégrité.
• Si le vendeur donne son consentement aux modifications.
• S'il est possible d'obtenir le consentement du fournisseur de logiciels pour des mises à jour régulières.
• L'impact probable de la maintenance du logiciel qui découle des modifications.
• Si les modifications seraient compatibles avec d'autres composants logiciels utilisés par l'organisation.

Conseils supplémentaires sur le contrôle 8.28

Les organisations doivent s’assurer que le code pertinent pour la sécurité est utilisé lorsque cela est nécessaire et qu’il résiste à la falsification.

Control 8.28 répertorie également les recommandations suivantes pour le code pertinent pour la sécurité :

• Bien que les programmes installés via un code binaire incluent du code lié à la sécurité, celui-ci est limité aux données stockées dans l'application elle-même.
• Le concept de code pertinent pour la sécurité n'est utile que lorsque le code est exécuté sur un serveur qui n'est pas accessible à l'utilisateur et qu'il est séparé des processus qui l'utilisent et que ses données sont conservées en toute sécurité dans une autre base de données. Par exemple, vous pouvez exécuter un code interprété sur un service cloud et l'accès au code peut être restreint aux administrateurs privilégiés. Il est recommandé de protéger ces droits d'accès via des méthodes telles que des privilèges d'administrateur juste à temps et des mécanismes d'authentification robustes.
• Des configurations appropriées sur les serveurs Web doivent être mises en œuvre pour empêcher l'accès et la navigation non autorisés dans le répertoire.
• Lors de la conception du code d’une application, vous devez partir de l’hypothèse que le code est vulnérable aux attaques dues à des erreurs de codage et aux actions d’acteurs malveillants. Vous devez concevoir les applications critiques de manière à ce qu'elles ne soient pas vulnérables aux pannes internes. Par exemple, le résultat produit par un algorithme peut être examiné pour garantir qu'il est conforme aux exigences de sécurité avant de pouvoir être utilisé dans des applications critiques telles que des applications liées à la finance.
• Certaines applications Web sont très vulnérables aux menaces de sécurité en raison de mauvaises pratiques de codage telles que l'injection de bases de données et les attaques de scripts intersites.
• Les organisations doivent se référer à la série ISO/IEC 15408 pour plus d'informations sur l'évaluation de la sécurité informatique.

Modifications et différences par rapport à la norme ISO 27002:2013

27002:2022/8.28 est un nouveau type de contrôle.

Nouveaux contrôles ISO 27002

Comment ISMS.online vous aide

Notre plateforme a été développée spécifiquement pour ceux qui débutent dans le domaine de la sécurité de l'information ou qui ont besoin d'un moyen simple de se familiariser avec la norme ISO 27002 sans avoir à passer du temps à apprendre à partir de zéro ou à lire de longs documents.

ISMS.Online est équipé de tous les outils nécessaires pour assurer la conformité, notamment des modèles de documents, des listes de contrôle et des politiques qui peuvent être personnalisées en fonction de vos besoins.

Vous voulez voir comment ça marche?

Contactez-nous dès aujourd'hui pour réserver une démo.