Codage sécurisé - Défis de la sécurité de l'information

• Failles de sécurité dans le code
• Attaques contre le code open source et la chaîne d’approvisionnement
• Contrôle de la sécurité de l'information 8.28 codage sécurisé
• Principes du codage sécurisé
• Conclusion
• Révision de la norme ISO 27001 : Que signifie la mise à jour pour votre certification ?
• DQS - Tirer simplement parti de la sécurité .

Failles de sécurité dans le code

Les logiciels de système d'exploitation, les logiciels d'application ou les micrologiciels d'un système embarqué sont des composants élémentaires de toute infrastructure numérique. Cependant, l’accélération croissante et la pression des délais dans les projets de numérisation conduisent souvent à négliger les aspects impératifs de la sécurité de l’information. Les exigences de développement d'un logiciel sont généralement centrées sur les fonctions et mettent l'accent sur les aspects constructifs, de sorte que la vision destructrice des failles de sécurité potentielles est pour la plupart diamétralement opposée aux objectifs de développement réels : de nombreux programmeurs n'ont tout simplement pas non plus une vision structurée et précise de la cybersécurité.

Dans ces conditions, les équipes de développement ont du mal à réviser en permanence et à sécuriser de manière cohérente le codage de leurs logiciels, comme en témoignent les nombreuses vulnérabilités que l'association à but non lucratif MITRE Corporation publie chaque année dans son CVE (Vulnérabilités et expositions courantes). Les correctifs de sécurité réguliers, même chez les fabricants de logiciels les plus connus, sont un indicateur de la tâche de Sisyphe consistant à corriger les bogues liés à la sécurité, sans parler de les identifier avant même leur lancement sur le marché.

Code open source – un cas particulier

Lors du codage de logiciels auto-développés, les programmeurs aiment recourir à des bibliothèques et des modules open source. Les avantages pratiques sont évidents : si vous n'avez pas à réinventer la roue encore et encore, vous bénéficiez de cette avancée technologique, d'un développement rapide, de coûts de développement réduits, d'une plus grande transparence grâce au code open source et d'une plus grande interopérabilité grâce aux normes et interfaces ouvertes. .

On dit aussi souvent que le code open source offre un haut degré de sécurité car le code a été validé par de nombreux utilisateurs et l'intelligence en essaim de la communauté open source permet une correction rapide et efficace des bugs.

En pratique, cette confiance doit désormais être évaluée de manière différenciée et critique. L'exemple le plus grave est la vulnérabilité de sécurité Zero Day Log4Shell dans la bibliothèque de journalisation largement utilisée Log4J pour les applications Java, découverte en novembre 2021. Vous avez peut-être entendu parler du niveau d'alerte rouge émis par l'Office fédéral allemand pour la sécurité de l'information (BSI). ) pour Log4Shell. La bibliothèque Log4J, distribuée en tant que quasi-standard fiable via la Fondation Apache, s'est imposée dans de nombreux systèmes depuis 2013, y compris dans des services Web bien connus tels qu'Amazon AWS.

La complexité de ces bibliothèques bien développées et également entretenues fournit implicitement de puissantes fonctionnalités dont un développeur importateur ignore souvent dans son propre nouveau développement combiné, mais qui peuvent être exploitées par des attaquants.

Un autre facteur d'insécurité des composants open source sont les attaques dites de la chaîne d'approvisionnement, c'est-à-dire les vulnérabilités intégrées intentionnelles par des acteurs malveillants qui se font passer pour des membres de la communauté open source et aident au développement du code. Une telle vulnérabilité constitue un moyen extrêmement efficace pour les pirates informatiques d’attaquer un grand nombre d’organisations d’utilisateurs en aval. Il n’est donc pas étonnant que ce vecteur d’attaque se développe rapidement : Etude Sonatype a diagnostiqué une augmentation de 650 % en comparant 2020 et 2021.

Contrôle de la sécurité de l'information 8.28 codage sécurisé

Afin de garantir dans les délais le processus de développement de logiciels, l'Organisation internationale de normalisation (ISO - comité ISO/IEC JTC 1/SC 27) a inclus le « codage sécurisé » comme nouveau contrôle 8.28 dans la nouvelle norme ISO/IEC 27002 et ISO/CEI 27001:2022 , normes de l'annexe A. La mesure technique de codage sécurisé a pour objectif la protection préventive des logiciels.

Un niveau minimum de sécurité est créé dès la phase d'écriture sur la base de règles de procédure, minimisant ainsi le nombre de failles de sécurité potentielles dans le logiciel. Le cadre réglementaire pour la génération sécurisée de code doit être appliqué de manière globale tant au code de programme de l'entreprise qu'aux logiciels de tiers et de sources open source. Les principes notables de mise en œuvre sont La sécurité dès la conception et le moindre privilège, qui doit également être pris en compte dans le codage.

Principes du codage sécurisé

La mesure 8.28 aborde à plusieurs reprises les principes dits du codage sécurisé. Des conseils sur ce que cela pourrait être sont fournis par de nombreuses organisations et instituts qui publient régulièrement des guides et des bonnes pratiques pour un codage sécurisé. Il s'agit notamment, par exemple, du Pratiques de codage sécurisées de la Fondation OWASP, la Normes de codage sécurisées de le Computer Emergency Response Team (CERT) de l'Institut de génie logiciel (SEI) et le catalogue de mesures du BSI allemand pour la sécurité des applications Web. Malgré les différentes sources, les élaborations montrent de nombreux parallèles, par exemple en ce qui concerne les points suivants :

• Validation de la saisie des données
• Sécuriser l'authentification et la gestion des mots de passe
• Contrôle d'accès sécurisé
• Code simple et transparent
• Mesures et composants cryptographiques testés de manière durable
• Gestion des erreurs et journalisation
• Protection des données
• Modélisation des menaces

Dans la norme ISO/ISO 27002:2022, les actions recommandées pour le contrôle 8.28 sont divisées en trois sections : « Planification et précodage », « Pendant le codage » et « Vérification et maintenance », dont le contenu principal est décrit ci-dessous.

Planification et précodage

Le développement de nouveaux codes et leur réutilisation nécessitent l'application de principes de codage sécurisé, que le code soit écrit pour des logiciels internes ou pour des produits et services externes. Cela nécessite une évaluation préalable des attentes spécifiques à l’organisation et la définition de principes reconnus. De plus, les actions recommandées pour la planification et le précodage tiennent compte des pratiques de codage courantes et historiques connues et des erreurs susceptibles de conduire à des vulnérabilités.

La configuration des outils de développement, tels que les outils de développement basés sur des règles dans les environnements de développement intégrés (IDE), doit imposer la création de code sécurisé. La qualification des développeurs et leur familiarité avec les architectures sécurisées et les normes de programmation sont tout à fait cruciales. L’inclusion d’une expertise en sécurité de l’information dans l’équipe de développement va de soi.

Pendant le processus de codage

Au cours du processus de codage, les pratiques de codage et les techniques de programmation structurée jouent un rôle primordial, en tenant compte du cas d'utilisation spécifique et de ses besoins de sécurité. Les techniques de conception non sécurisées – par exemple les mots de passe codés en dur – devraient être systématiquement interdites. Le code doit être correctement documenté et révisé pour éliminer au mieux les bogues liés à la sécurité. La révision du code doit avoir lieu pendant et après le développement, via des tests de sécurité des applications statiques (SAST) ou similaire. Les méthodes de tests statiques prennent en charge l'approche de décalage vers la gauche (« tester tôt et souvent ») en se déplaçant vers la gauche dans le cycle de vie en testant le code visible pour vérifier sa conformité aux règles de manière précoce.

Cela permet une identification précoce du code corrompu, des connexions à des fichiers ou des classes d'objets spécifiques, ou des lacunes au niveau de l'application qui peuvent être exploitées pour une interaction inaperçue avec des programmes tiers en tant que vulnérabilités exploitables. Avant la mise en service du logiciel, Control 8.28 nécessite une évaluation des surfaces d'attaque et la mise en œuvre du principe du moindre privilège. L'analyse effectuée des erreurs de programmation les plus courantes et la documentation de leur correction doivent être évaluées.

Vérification et maintenance

Même après la mise en service du logiciel, le thème du codage sécurisé reste d’actualité. Cela inclut des mises à jour sécurisées ainsi que des vérifications des vulnérabilités connues dans son code. De plus, les erreurs et les attaques suspectées doivent être documentées afin que les ajustements nécessaires puissent être effectués rapidement. Dans tous les cas, tout accès non autorisé au code source doit être empêché de manière fiable par des outils appropriés.

Code source ouvert

Dans le domaine de la vérification et de la maintenance, la mesure 8.28 énumère en outre des instructions explicites pour l'utilisation d'outils et de bibliothèques externes, tels que les logiciels open source. Ces composants de code doivent être gérés, mis à jour et maintenus dans des inventaires. Cela peut être fait, par exemple, via une nomenclature logicielle (SBOM). Un SBOM est un enregistrement formel et structuré des packages et bibliothèques d'un logiciel et de leurs relations les uns avec les autres et au sein de la chaîne d'approvisionnement, en particulier pour garder une trace du code réutilisé et des composants open source. Le SBOM prend en charge la maintenabilité logicielle et les mises à jour de sécurité ciblées.

Conclusion

Le code sécurisé constitue une base élémentaire pour stopper les attaques potentielles. Le nouveau Control 8.28 prend en compte cette idée de longue date et met à niveau le rôle clé du codage sécurisé dans son importance pour la sécurité des informations. Cependant, étant donné que la mesure comprend un grand nombre de recommandations d'action détaillées et qu'elle est techniquement exigeante, sa mise en œuvre nécessitera un niveau d'effort relativement élevé - il convient d'en tenir compte dès la phase de planification.

Avec l’avis professionnel de nos auditeurs expérimentés, nous vous accompagnons dans la mise en œuvre conforme de la mesure. Forts de notre expertise en matière d'audit et de certification de plus de 35 ans, nous sommes votre interlocuteur idéal et serons heureux de vous aider sur le thème de la sécurité de l'information et de la certification selon les normes ISO/IEC 27001:2022.

Révision de la norme ISO 27001 : Que signifie la mise à jour pour votre certification ?

La norme ISO/IEC 27001:2022 a été publiée le 25 octobre 2022. Cela entraîne les délais et délais suivants pour la transition des utilisateurs :

Date limite pour les audits initiaux/recertifications selon « l'ancienne » ISO 27001:2013

• Après le 30 avril 2024, DQS réalisera des audits initiaux et de recertification uniquement selon la nouvelle norme ISO/IEC 27001:2022.

Transition de tous les certificats existants selon « l'ancienne » ISO/IEC 27001:2013 vers la nouvelle ISO/IEC 27001:2022

• Il y a une période de transition de 3 ans à compter du 31 octobre 2022
• Les certificats délivrés selon ISO/IEC 27001:2013 ou DIN EN ISO/IEC 27001:2017 sont valables jusqu'au 31 octobre 2025 au plus tard ou doivent être retirés à cette date.

DQS : exploiter simplement la sécurité.

En raison des périodes de transition, les entreprises disposent de suffisamment de temps pour adapter leur SMSI aux nouvelles exigences et le faire certifier. Cependant, la durée et les efforts de l'ensemble du processus de changement ne doivent pas être sous-estimés, surtout si vous ne disposez pas de suffisamment de personnel spécialisé. Si vous voulez être prudent, vous devez régler le problème le plus tôt possible et faire appel à des spécialistes expérimentés si nécessaire.

En tant qu'experts en audit et certification avec plus de 35 ans d'expertise, nous serons heureux de vous aider à évaluer votre statut actuel, éventuellement dans le cadre d'un audit delta. Renseignez-vous auprès de nos nombreux auditeurs expérimentés sur les changements les plus importants et leur pertinence pour votre organisation. Nous discuterons ensemble de votre potentiel d’amélioration et vous accompagnerons jusqu’à ce que vous receviez votre nouveau certificat. Profitez de notre compétence en sécurité de l’information ! Nous avons hâte d'avoir de tes nouvelles.