Aucun traitement de données et d'informations ne peut se faire sans logiciel. Le développement de logiciels se concentre principalement sur le fonctionnement d'algorithmes spécifiques à une tâche. Cependant, il est désormais bien connu qu'un code de programme mal écrit donne souvent lieu à des problèmes de sécurité, tels qu'un mauvais contrôle d'accès, une injection SQL, une gestion de session et une authentification incorrectes, des scripts intersites, etc.

Les normes de sécurité de l'information actualisées ISO/IEC 27002 et ISO/IEC 27001:2022 soulignent la grande importance des pratiques de codage sécurisées. En tant que nouvelle mesure de sécurité de l'information (contrôle), les principes de "codage sécurisé" dans le développement de logiciels entrent dans le catalogue des mesures de l'annexe A de la norme ISO/IEC 27001. Découvrez l'importance de cette mesure pour votre sécurité de l'information et ce qu'elle signifie pour les futurs audits dans notre article de blog.

Vulnérabilités dans le code

Les logiciels d'exploitation, les logiciels d'application ou les microprogrammes d'un système embarqué sont des composants élémentaires de toute infrastructure numérique. Cependant, l'accélération croissante et la pression du temps dans les projets de numérisation conduisent souvent à négliger les aspects impératifs de la sécurité de l'information. Les exigences en matière de développement de logiciels sont généralement axées sur les fonctions et mettent l'accent sur les aspects constructifs, de sorte que la vision destructrice des vulnérabilités potentielles en matière de sécurité est généralement en contradiction avec les objectifs de développement réels : de nombreux programmeurs n'ont tout simplement pas une vision structurée et affinée de la cybersécurité.

Dans ces conditions, les équipes de développement éprouvent des difficultés à revoir et à sécuriser en permanence le codage de leurs logiciels, comme en témoignent les nombreuses vulnérabilités que la société à but non lucratif MITRE Corporation publie chaque année dans sa liste CVE ( Common Vulnerabilities and Exposures). Les correctifs de sécurité régulièrement apportés par les fabricants de logiciels, même les plus connus, témoignent du travail de Sisyphe que représente la correction des bogues liés à la sécurité, sans parler de leur identification avant leur mise sur le marché.

Le code source ouvert - un cas particulier

Lorsqu'ils codent des logiciels qu'ils ont eux-mêmes développés, les programmeurs aiment recourir à des bibliothèques et à des modules open source. Les avantages pratiques sont évidents : ne pas avoir à réinventer la roue bénéficie de ce coup de pouce technologique, d'un développement rapide, de coûts de développement réduits, d'une plus grande transparence grâce au code source ouvert, et d'une plus grande interopérabilité grâce à des normes et des interfaces ouvertes.

On dit aussi souvent que le code source ouvert offre un haut degré de sécurité parce qu'il a été validé par de nombreux utilisateurs et que l'intelligence en essaim de la communauté du code source ouvert permet de corriger les bogues rapidement et efficacement.

Dans la pratique, cette confiance doit maintenant être différenciée et évaluée de manière critique. L'exemple le plus sérieux est la faille de sécurité Log4Shell, découverte en novembre 2021, dans la bibliothèque de logs Log4J, largement utilisée pour les applications Java. Vous avez peut-être entendu parler du niveau d'alerte rouge émis par l'Office fédéral allemand de la sécurité de l'information (BSI) pour Log4Shell. La bibliothèque Log4J, distribuée en tant que quasi-standard de travail fiable par 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 maintenues fournit implicitement des fonctionnalités puissantes dont un développeur importateur n'a souvent pas conscience dans son propre développement, mais qui peuvent être exploitées par des attaquants.

Un autre facteur d'insécurité des composants open source est ce que l'on appelle les attaques de la chaîne d'approvisionnement, c'est-à-dire les vulnérabilités intégrées intentionnellement par des personnes malveillantes qui se font passer pour des membres de la communauté open source et qui aident à développer le code. Une telle vulnérabilité est un moyen extrêmement efficace pour les pirates d'attaquer un grand nombre d'organisations utilisatrices en aval. Il n'est donc pas étonnant que ce vecteur d'attaque se développe rapidement : une étude de Sonatype a révélé une augmentation de 650 % entre 2020 et 2021.

CTA picture for FAQ ISO 27001
Loading...

ISO/IEC 27001:2022 Q&A

La nouvelle norme de sécurité de l'information: 38 questions et réponses

Ce qu'il faut savoir sur la "nouvelle norme" en matière de sécurité de l'information.

  • En quoi consistent les nouveaux contrôles ?
  • Quand devons-nous passer à la nouvelle norme ?
  • Où puis-je trouver une liste des correspondances entre l'ancienne et la nouvelle norme ?
  •  ... ainsi que 35 autres questions !

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

Afin de garantir une assurance opportune du 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é" en tant que nouveau contrôle 8.28 dans les nouvelles normes ISO/IEC 27002 et ISO/IEC 27001:2022, Annexe A. L'objectif de la mesure technique pour le codage sécurisé est la protection préventive des logiciels.

Dès le stade de l'écriture, un niveau minimum de sécurité est créé sur la base d'exigences procédurales, ce qui réduit le nombre de failles de sécurité potentielles dans le logiciel. Le cadre réglementaire pour la création de codes sécurisés doit être appliqué de manière globale, tant au code des programmes propriétaires qu'aux logiciels de tiers et aux sources ouvertes. Les principes importants pour la mise en œuvre sont la sécurité dès la conception et le moindre privilège, qui doivent également être pris en compte lors du codage.

Principes de codage sécurisé

Dans la mesure 8.28, les principes de chiffrement sécurisé sont mentionnés à plusieurs reprises. De nombreuses organisations et instituts qui publient régulièrement des guides et des bonnes pratiques en matière de codage sécurisé donnent des indications sur ce qu'ils pourraient être. Il s'agit notamment des Secure Coding Practices de la fondation OWASP, des Secure Coding Standards du Computer Emergency Response Team (CERT) du Software Engineering Institute (SEI) et du catalogue des mesures de sécurité des applications web du BSI allemand. Malgré la diversité des sources, les élaborations présentent de nombreux parallèles, par exemple en ce qui concerne les points suivants :

  • Validation de l'entrée des données
  • Sécurité de l'authentification et de la gestion des mots de passe
  • Contrôle d'accès sécurisé
  • Code simple et transparent
  • Mesures et composants cryptographiques testés durablement
  • Traitement et enregistrement des erreurs
  • 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 parties : "Planification et précodage", "Pendant le chiffrement" et "Vérification et maintenance".

webinar-dqs-junger-mann-mit-headset-sitzt-vor-einem-laptop
Loading...

Regardez-le maintenant: ce qui change avec la nouvelle norme ISO/IEC 27001:2022

La nouvelle version de la norme ISO/IEC 27001, adaptée aux risques informatiques actuels, a été publiée le 25 octobre 2022. Qu'est-ce que cela signifie pour les utilisateurs de la norme ? Dans l'enregistrement de notre webinaire gratuit, vous en apprendrez plus sur

  • Les nouveautés de l'ISO/IEC 27001:2022 - Cadre et Annexe A
  • ISO/IEC 27002:2022-02 - structure, contenu, attributs et hashtags
  • Le calendrier de la transition et les prochaines étapes

Planification et précodage

Le développement de nouveaux codes et la réutilisation de codes nécessitent l'application de principes de codage sécurisés, que le code soit écrit pour un logiciel interne ou pour des produits et services externes. Cela nécessite l'évaluation des attentes spécifiques de l'organisation et la définition préalable de principes reconnus. En outre, les actions recommandées pour la planification et le précodage tiennent compte des pratiques et erreurs de codage connues, courantes et historiques, qui peuvent entraîner des vulnérabilités.

La configuration des outils de développement, tels que les environnements de développement intégrés (IDE) basés sur des règles, devrait imposer la création d'un code sécurisé. La qualification des développeurs et leur connaissance des architectures et des normes de programmation sécurisées revêtent une importance cruciale. L'inclusion d'une expertise en matière de sécurité de l'information dans l'équipe de développement est naturelle.

Pendant le processus de codage

Au cours du processus de codage, les pratiques de codage et les techniques de programmation structurées jouent un rôle primordial, en tenant compte du cas d'utilisation spécifique et de ses besoins en matière de sécurité. Les techniques de conception peu sûres - par exemple les mots de passe en dur - devraient être systématiquement bannies. Le code doit être correctement documenté et revu afin d'éliminer au mieux les failles de sécurité. L'examen du code devrait avoir lieu à la fois pendant et après le développement, par le biais de tests statiques de sécurité des applications (SAST) ou d'autres méthodes similaires. Les méthodes de test statique soutiennent l'approche "shift left" ("tester tôt et souvent") en se déplaçant vers la gauche dans le cycle de vie en testant tôt le code visible pour la conformité aux règles.

Cela permet d'identifier rapidement le code infecté, les connexions à des fichiers ou à des classes d'objets spécifiques, ou les lacunes au niveau de l'application qui peuvent être exploitées pour une interaction non détectée avec des programmes tiers en tant que vulnérabilités exploitables. Avant le déploiement du logiciel, le contrôle 8.28 exige une évaluation des surfaces d'attaque et l'application du principe du moindre privilège. L'analyse des erreurs de programmation les plus courantes et la documentation de leur correction doivent être évaluées.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen
Loading...

Cela pourrait vous intéresser également:

Détection et prévention dans la gestion de la sécurité de l'information

Vérification et maintenance

Même après la mise en service du logiciel, la question du codage sécurisé reste d'actualité. Cela comprend à la fois les mises à jour sécurisées et les vérifications des vulnérabilités connues dans le code propriétaire. En outre, les erreurs et les attaques présumées doivent être documentées afin que les ajustements nécessaires puissent être effectués rapidement. Dans tous les cas, l'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 contient également des instructions explicites concernant l'utilisation d'outils et de bibliothèques externes, tels que les logiciels libres. Ces composants de code doivent être gérés, mis à jour et conservés dans des inventaires. Cela peut se faire, par exemple, au moyen d'une nomenclature logicielle (Software Bill of Material - SBOM). Un SBOM est un enregistrement formel et structuré des progiciels et des bibliothèques et de leurs interrelations au sein de la chaîne d'approvisionnement, en particulier pour assurer le suivi du code réutilisé et des composants open source. Le SBOM favorise la maintenabilité des logiciels et les mises à jour de sécurité ciblées.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Certification selon la norme ISO 27001

De quels efforts devez-vous tenir compte pour faire certifier votre SMSI selon la norme ISO 27001 ? Obtenez des informations gratuites et sans engagement.

Nous nous réjouissons d'en discuter avec vous.

Conclusion

Un code sécurisé est une base élémentaire pour arrêter les attaques potentielles. Le nouveau Contrôle 8.28 tient compte de cette idée de longue date et renforce le rôle clé du codage sécurisé dans la sécurité de l'information. Cependant, comme il comprend un grand nombre de recommandations de mesures détaillées et qu'il est techniquement exigeant, sa mise en œuvre nécessitera un effort relativement important - ce qui doit être pris en compte dès le stade de la planification.

Grâce à la vision professionnelle de nos auditeurs expérimentés, nous vous soutenons dans la mise en œuvre conforme de la mesure. Grâce à notre expertise de plus de 35 ans en matière d'audit et de certification, nous sommes votre interlocuteur idéal et nous nous ferons un plaisir de vous aider dans le domaine 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. Les utilisateurs doivent donc respecter les échéances et les délais de transition suivants :

Préparation à la certification ISO/IEC 27001:2022

  • Prévue à partir de mai 2023 (selon l'organisme allemand d'accréditation GmbH (DAkkS)).

Date limite pour les audits initiaux/de recertification selon l'"ancienne" norme ISO 27001:2013

  • Après le 31 octobre 2023, DQS n'effectuera plus que des audits initiaux et de recertification selon la nouvelle norme ISO/IEC 27001:2022.

Transition de tous les certificats existants de l'"ancienne" norme ISO/IEC 27001:2013 vers la nouvelle norme ISO/IEC 27001:2022

  • Une période de transition de trois ans est prévue à partir du 31 octobre 2022.
  • Les certificats délivrés conformément à la norme ISO/IEC 27001:2013 ou DIN EN ISO/IEC 27001:2017 resteront valables jusqu'au 31 octobre 2025 au plus tard, ou devront être retirés à cette date.

DQS: Simply leveraging Quality.

Les périodes de transition donnent aux entreprises suffisamment de temps pour adapter leur SMSI aux nouvelles exigences et obtenir la certification. Toutefois, il ne faut pas sous-estimer la durée et les efforts de l'ensemble du processus de changement, surtout si vous ne disposez pas d'un personnel suffisamment spécialisé. Si vous voulez mettre toutes les chances de votre côté, vous devez vous attaquer au 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 en certification, forts de plus de 35 ans d'expérience, nous vous aiderons volontiers à évaluer votre statut actuel, éventuellement dans le cadre d'un audit delta. Nos nombreux auditeurs expérimentés vous informeront des changements les plus importants et de leur pertinence pour votre organisation. Nous discuterons ensemble de votre potentiel d'amélioration et vous soutiendrons jusqu'à ce que vous receviez votre nouveau certificat. Profitez de notre compétence en matière de sécurité de l'information ! Nous nous réjouissons d'ores et déjà de votre visite.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

En savoir plus?

Prenez contact avec nous !

Sans engagement et gratuitement.

Auteur
Markus Jegelka

Expert DQS pour les systèmes de gestion de la sécurité de l'information (SGSI) et auditeur de longue date pour les normes ISO 9001, ISO/IEC 27001 et le catalogue de sécurité informatique conformément au paragraphe 11.1a de la loi allemande sur l'industrie de l'énergie (EnWG).

Loading...