Aucun traitement de données et d'informations ne peut fonctionner sans logiciel. Le développement de logiciels se concentre principalement sur le fonctionnement spécifique des algorithmes. Toutefois, il est désormais bien connu qu'une mauvaise écriture du code du programme entraîne souvent des problèmes de sécurité, tels qu'un contrôle d'accès défectueux, une injection SQL, un management et une authentification incorrectes des sessions, des scripts intersites, etc.

La grande importance des pratiques de codage sécurisé est soulignée dans les normes actualisées de sécurité de l'information ISO/IEC 27002 et ISO/IEC 27001:2022. En tant que nouvelle mesure de sécurité de l'information (contrôle), les principes du "codage sécurisé" dans le développement de logiciels entrent dans le catalogue des mesures de l'annexe A de l'ISO/CEI 27001. Lisez l'importance de cette mesure pour votre sécurité de l'information et ce que cela signifie pour les audits futurs dans notre article de blog.

Les failles de sécurité dans le code

Le logiciel du système d'exploitation, le logiciel d'application ou le micrologiciel 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 des logiciels sont généralement centré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 le plus souvent diamétralement opposée aux objectifs réels de développement : de nombreux programmeurs n'ont tout simplement pas non plus une vision structurée et aiguisée de la cybersécurité.

Dans ces conditions, les équipes de développement ont du mal à revoir et à sécuriser en permanence le codage de leurs logiciels, comme en témoignent les nombreuses vulnérabilités que l'organisation à but non lucratif MITRE Corporation publie chaque année dans sa liste CVE (Common Vulnerabilities and Exposures). Les correctifs de sécurité apportés régulièrement par des fabricants de logiciels, même bien connus, témoignent de la tâche sisyphéenne consistant à éliminer les bogues liés à la sécurité, sans parler de leur identification avant même leur lancement sur le marché.

Code source ouvert - un cas particulier

Lorsqu'ils codent un logiciel qu'ils ont développé eux-mêmes, les programmeurs utilisent volontiers des bibliothèques et des modules open source. Les avantages pratiques sont évidents : si vous ne devez pas réinventer la roue encore et encore, vous bénéficiez d'un coup de pouce technologique, d'un développement plus rapide, d'une réduction des coûts de développement, d'une plus grande transparence grâce au code source ouvert et d'une plus grande interopérabilité grâce aux normes et interfaces ouvertes.

On dit aussi souvent que le code issu de l'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 Log4J, largement utilisée pour les applications Java, qui a été découverte en novembre 2021. 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 fonctionnant de manière fiable via la Fondation Apache, s'est établie dans de nombreux systèmes depuis 2013 - y compris des services Web bien connus comme Amazon AWS.

La complexité de ces bibliothèques bien développées et également entretenues fournit implicitement des fonctionnalités puissantes dont un développeur importateur n'est souvent pas conscient 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 est ce qu'on appelle les attaques de la chaîne d'approvisionnement, c'est-à-dire les vulnérabilités intégrées intentionnellement par des acteurs malveillants qui se font passer pour des membres de la communauté open source et participent au développement du 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 connaisse une croissance rapide : une étude de Sonatype a diagnostiqué une augmentation de 650 % en comparant 2020 et 2021.

neue-iso-iec-27001-2022-blog-dqs-projektmanager unterhalten sich bei benutzung eines tablets in einer zentrale
Loading...

Intéressant aussi :

La nouvelle norme ISO/IEC 27001:2022 - principaux changements

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

Afin de sauvegarder le processus de développement de logiciels en temps opportun, 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 les nouvelles normes ISO/IEC 27002 et ISO/IEC 27001:2022, annexe A. L'objectif de la mesure technique de codage sécurisé est la protection préventive des logiciels.

Un niveau minimal de sécurité est créé dès la phase d'écriture sur la base de règles procédurales, ce qui permet de minimiser le nombre de failles de sécurité potentielles dans le logiciel. Le cadre réglementaire pour la génération d'un code sécurisé doit être appliqué de manière holistique tant au code de programme propre à l'entreprise qu'aux logiciels provenant de tiers et de sources ouvertes. Les principes notables à mettre en œuvre sont la sécurité par la conception et le moindre privilège, qui doivent également être pris en compte dans le codage.

Principes de codage sécurisé

La mesure 8.28 aborde à plusieurs reprises les principes de codage sécurisé. De nombreuses organisations et instituts, qui publient régulièrement des guides et des bonnes pratiques en matière de codage sécurisé, fournissent des indications sur ce que pourraient être ces principes. Il s'agit, par exemple, des pratiques de codage sécurisé de la fondation OWASP, des normes de codage sécurisé de la Computer Emergency Response Team (CERT) du Software Engineering Institute (SEI) et du catalogue de mesures pour la sécurité des applications Web du BSI allemand. Malgré les différentes sources, les élaborations présentent de nombreux parallèles, par exemple en ce qui concerne les points suivants :

  • Validation de la saisie des données
  • Sécurisation de l'authentification et management 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
  • Traitement et journalisation 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 sections, "Planification et précodage", "Pendant le codage" et "Vérification et maintenance", dont les contenus essentiels sont présentés ci-dessous.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen
Loading...

Cela pourrait vous intéresser également :

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

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 à 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 des erreurs de codage connues, courantes et historiques, qui pourraient entraîner des vulnérabilités.

La configuration des outils de développement, tels que ceux basés sur des règles dans les environnements de développement intégrés (IDE), devrait permettre de renforcer la création d'un code sécurisé. La qualification des développeurs et leur familiarité avec les architectures et les normes de programmation sécurisées sont tout aussi importantes. 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

Pendant le 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 en matière de sécurité. Les techniques de conception non sécurisées - par exemple, les mots de passe codés en dur - doivent être systématiquement interdites. Le code doit être documenté et révisé de manière adéquate afin d'éliminer au mieux les bogues liés à la sécurité. L'examen du code doit avoir lieu 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 de déplacement vers la gauche ("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 altéré, 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 inaperçue avec des programmes tiers en tant que vulnérabilités exploitables. Avant la mise en service 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 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 les mises à jour sécurisées ainsi que la vérification des vulnérabilités connues dans son code. En outre, les erreurs et les attaques suspectes 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 énumère en outre des instructions explicites pour 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 maintenus dans des inventaires. Cela peut être fait, par exemple, via une nomenclature logicielle (SBOM). Un SBOM est un enregistrement formel et structuré des paquets et des bibliothèques d'un logiciel et de leurs relations entre eux et 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.

marque de questions-réponses sur des cubes en bois sur une table
Loading...

Certification selon la norme ISO 27001

Quels efforts devez-vous consentir pour faire certifier votre SMSI selon la norme ISO 27001 ? Informez-vous gratuitement et sans engagement.

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

Conclusion

Un code sécurisé est une base élémentaire pour mettre un terme aux attaques potentielles. Le nouveau contrôle 8.28 tient compte de cette constatation faite depuis longtemps et revalorise le rôle clé du codage sécurisé dans son importance pour la sécurité de l'information. 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 impliquera un niveau d'effort comparativement élevé - ceci devrait être pris en compte dès la phase de planification.

Grâce au regard professionnel de nos auditeurs expérimentés, nous vous soutenons dans la mise en œuvre conforme de la mesure. Forts de 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 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 cette mise à jour pour votre certification ?

La norme ISO/IEC 27001:2022 a été publiée le 25 octobre 2022. Il en résulte les échéances et délais suivants pour la transition des utilisateurs :

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

  • Attendu à partir en mai 2023 (en fonction de l'organisme d'accréditation allemand GmbH (DAkkS)).

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

  • Après le 31 octobre 2023, DQS réalisera des audits initiaux et de recertification uniquement 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

  • Il y a une période de transition de trois ans à partir du 31 octobre 2022.
  • Les certificats émis selon 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.

Grâce aux périodes de transition, les entreprises disposent de suffisamment de temps pour adapter leur SMSI conformément aux nouvelles exigences et le faire certifier. Toutefois, il ne faut pas sous-estimer la durée et l'effort de l'ensemble du processus de changement - surtout si vous ne disposez pas de suffisamment de personnel spécialisé. Si vous voulez être du bon côté, vous devriez vous occuper du problème le plus tôt possible et faire appel à des spécialistes expérimentés si nécessaire.

En tant qu'experts de l'audit et de la certification, forts de plus de 35 ans d'expertise, nous sommes heureux de vous aider à évaluer votre statut actuel, peut-être dans le cadre d'un audit delta. Découvrez auprès de nos nombreux auditeurs expérimentés les changements les plus importants et 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 sommes impatients de vous entendre.

marque de questions-réponses sur des cubes en bois sur une table
Loading...

Des questions ?

Contactez nous !

Sans engagement et gratuitement.

Auteur
Markus Jegelka

Expert DQS pour les systèmes de management de la sécurité de l'information (ISMS) 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 le secteur de l'énergie (EnWG).

Loading...