
Les problèmes de sécurité de Huawei au Royaume-Uni démontrent la nécessité d'un codage sécurisé
Publié à l'origine dans L'ère de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement autour du support de sécurité continu de Wind River Systems pour son produit de système d'exploitation en temps réel, VxWorks.
Un rapport récent du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus de génie logiciel de Huawei. Alors qu'une grande partie de l'actualité concernant ce rapport critique se concentre sur des problèmes non résolus survenus l'année précédente, le problème le plus dangereux et le plus négligé est l'absence flagrante de directives et de pratiques de codage sécurisé utilisées par Huawei. Mais c'est un problème qui peut être résolu.
Les nouvelles, pour le géant chinois des télécommunications Huawei, ne font qu'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de participer à de futurs travaux gouvernementaux, le Royaume-Uni a davantage accepté le fait que bon nombre des failles sous-jacentes des appareils et du code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Centre d'évaluation de la cybersécurité de Huawei (HCSEC) en 2010 pour évaluer et résoudre les problèmes de sécurité des produits Huawei, et pour produire un rapport annuel à leur sujet. Cependant, cette année, le rapport était particulièrement accablant.
L'attention portée au rapport 2019 de la HCSEC dans les actualités est due en grande partie au fait que pratiquement aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River, qui sera bientôt mise en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera du soutien continu de Wind River Systems), mais celui-ci reste un élément central de la plupart des infrastructures de télécommunications du Royaume-Uni.
Un facteur critique qui semble avoir été négligé par la plupart des médias grand public est ce qui pourrait être un processus fondamentalement interrompu, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de « problèmes techniques importants » liés à la manière dont Huawei gère ses méthodes d'ingénierie internes.
Examinons quelques exemples des problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisées pour aider ses ingénieurs et programmeurs à déployer de nouveaux codes. Ces directives couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues de fonctions et de processus système provenant de bibliothèques fiables, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production Huawei au Royaume-Uni a révélé que ces directives n'étaient jamais communiquées aux programmeurs, ignorées par eux ou simplement non appliquées.
Le rapport a examiné des fonctions spécifiques de gestion de la mémoire dans les applications destinées au public, en l'occurrence un ensemble de babillards électroniques où les utilisateurs étaient invités, en fonction du programme, à ajouter des informations. Étant donné que les zones de saisie par les utilisateurs ne devraient jamais être considérées comme « fiables », il était prévu que ces zones ne contiennent que du code sécurisé, conformément aux directives internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de gestion de la mémoire memcpy (), strcpy () et sprintf () dans ces systèmes de production, connues pour entraîner de graves problèmes de sécurité tels que le débordement de la mémoire tampon depuis 1988 .
Étonnamment, il y a eu 5 000 appels directs de 17 fonctions memcpy () sûres connues, mais également 600 utilisations de 12 variantes non sécurisées. Le ratio était à peu près le même que pour les autres fonctions. Il y a eu 1 400 invocations sécurisées avec strcpy (), mais aussi 400 mauvaises avec des vulnérabilités connues. Et 2 000 utilisations sûres de sprintf () ont été découvertes, contre 200 utilisations dangereuses. Le fait que la plupart des utilisations de ces fonctions aient été sécurisées est une bonne chose, mais cela laisse environ 20 % du code global vulnérable aux attaques connues. Il s'agit d'une zone d'attaque de surface de menace énorme, et elle ne prend en compte que les appels directs des trois fonctions de gestion de la mémoire, et non les cas de leur utilisation indirecte via des pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à présenter des problèmes.
Bien que Huawei ait créé un guide des meilleures pratiques pour ses programmeurs, il est clair qu'il reste encore beaucoup à faire. Définir les attentes en matière de sécurité ne constitue qu'une étape, mais elles ne sont efficaces que si ces directives sont activement suivies et familières à la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de suivre les directives internes de Huawei. Ils doivent faire un pas supplémentaire en démontrant comment coder de manière plus sécurisée en général. Les codeurs doivent être suffisamment formés aux bons modèles de codage (sécurisés) et aux mauvais modèles (non sécurisés) et avoir la responsabilité de mettre en pratique ce que leur entreprise prêche à chaque fois.
De nombreux problèmes de codage spécifiques décrits dans le rapport de la HCSEC sont abordés et appliqués dans le cadre du Secure Code Warrior plateforme, qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais se fier aux entrées des utilisateurs, toujours extraire des fonctions des bibliothèques établies, nettoyer toutes les entrées avant de les transmettre à un serveur et de nombreuses autres pratiques de codage sûres sont constamment démontrés sur la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.
Outre une formation qualifiée, des entreprises comme Huawei pourraient utiliser les solutions DevSecOps. Il ajoute un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées personnalisées selon les directives de sécurité de l'entreprise, agissant en tant que sous-chef du développeur dans la « cuisine » de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un « livre de recettes » contenant des recettes conformes à leurs politiques et facilitant l'exécution des commandes.
L'une des principales leçons à tirer des problèmes de Huawei est que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans ce cas, les directives internes sur les meilleures pratiques se sont révélées être le zhilaohu propre à Huawei ; ce que l'Occident appellerait »un tigre en papier'. C'était un document plein de style, mais sans substance. Pour lui donner un véritable coup de pouce, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe des connaissances et des compétences continues.


Un rapport récent du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus de génie logiciel de Huawei. Mais c'est un problème qui peut être résolu.
Directeur général, président et cofondateur

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.Directeur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.


Publié à l'origine dans L'ère de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement autour du support de sécurité continu de Wind River Systems pour son produit de système d'exploitation en temps réel, VxWorks.
Un rapport récent du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus de génie logiciel de Huawei. Alors qu'une grande partie de l'actualité concernant ce rapport critique se concentre sur des problèmes non résolus survenus l'année précédente, le problème le plus dangereux et le plus négligé est l'absence flagrante de directives et de pratiques de codage sécurisé utilisées par Huawei. Mais c'est un problème qui peut être résolu.
Les nouvelles, pour le géant chinois des télécommunications Huawei, ne font qu'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de participer à de futurs travaux gouvernementaux, le Royaume-Uni a davantage accepté le fait que bon nombre des failles sous-jacentes des appareils et du code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Centre d'évaluation de la cybersécurité de Huawei (HCSEC) en 2010 pour évaluer et résoudre les problèmes de sécurité des produits Huawei, et pour produire un rapport annuel à leur sujet. Cependant, cette année, le rapport était particulièrement accablant.
L'attention portée au rapport 2019 de la HCSEC dans les actualités est due en grande partie au fait que pratiquement aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River, qui sera bientôt mise en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera du soutien continu de Wind River Systems), mais celui-ci reste un élément central de la plupart des infrastructures de télécommunications du Royaume-Uni.
Un facteur critique qui semble avoir été négligé par la plupart des médias grand public est ce qui pourrait être un processus fondamentalement interrompu, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de « problèmes techniques importants » liés à la manière dont Huawei gère ses méthodes d'ingénierie internes.
Examinons quelques exemples des problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisées pour aider ses ingénieurs et programmeurs à déployer de nouveaux codes. Ces directives couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues de fonctions et de processus système provenant de bibliothèques fiables, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production Huawei au Royaume-Uni a révélé que ces directives n'étaient jamais communiquées aux programmeurs, ignorées par eux ou simplement non appliquées.
Le rapport a examiné des fonctions spécifiques de gestion de la mémoire dans les applications destinées au public, en l'occurrence un ensemble de babillards électroniques où les utilisateurs étaient invités, en fonction du programme, à ajouter des informations. Étant donné que les zones de saisie par les utilisateurs ne devraient jamais être considérées comme « fiables », il était prévu que ces zones ne contiennent que du code sécurisé, conformément aux directives internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de gestion de la mémoire memcpy (), strcpy () et sprintf () dans ces systèmes de production, connues pour entraîner de graves problèmes de sécurité tels que le débordement de la mémoire tampon depuis 1988 .
Étonnamment, il y a eu 5 000 appels directs de 17 fonctions memcpy () sûres connues, mais également 600 utilisations de 12 variantes non sécurisées. Le ratio était à peu près le même que pour les autres fonctions. Il y a eu 1 400 invocations sécurisées avec strcpy (), mais aussi 400 mauvaises avec des vulnérabilités connues. Et 2 000 utilisations sûres de sprintf () ont été découvertes, contre 200 utilisations dangereuses. Le fait que la plupart des utilisations de ces fonctions aient été sécurisées est une bonne chose, mais cela laisse environ 20 % du code global vulnérable aux attaques connues. Il s'agit d'une zone d'attaque de surface de menace énorme, et elle ne prend en compte que les appels directs des trois fonctions de gestion de la mémoire, et non les cas de leur utilisation indirecte via des pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à présenter des problèmes.
Bien que Huawei ait créé un guide des meilleures pratiques pour ses programmeurs, il est clair qu'il reste encore beaucoup à faire. Définir les attentes en matière de sécurité ne constitue qu'une étape, mais elles ne sont efficaces que si ces directives sont activement suivies et familières à la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de suivre les directives internes de Huawei. Ils doivent faire un pas supplémentaire en démontrant comment coder de manière plus sécurisée en général. Les codeurs doivent être suffisamment formés aux bons modèles de codage (sécurisés) et aux mauvais modèles (non sécurisés) et avoir la responsabilité de mettre en pratique ce que leur entreprise prêche à chaque fois.
De nombreux problèmes de codage spécifiques décrits dans le rapport de la HCSEC sont abordés et appliqués dans le cadre du Secure Code Warrior plateforme, qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais se fier aux entrées des utilisateurs, toujours extraire des fonctions des bibliothèques établies, nettoyer toutes les entrées avant de les transmettre à un serveur et de nombreuses autres pratiques de codage sûres sont constamment démontrés sur la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.
Outre une formation qualifiée, des entreprises comme Huawei pourraient utiliser les solutions DevSecOps. Il ajoute un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées personnalisées selon les directives de sécurité de l'entreprise, agissant en tant que sous-chef du développeur dans la « cuisine » de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un « livre de recettes » contenant des recettes conformes à leurs politiques et facilitant l'exécution des commandes.
L'une des principales leçons à tirer des problèmes de Huawei est que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans ce cas, les directives internes sur les meilleures pratiques se sont révélées être le zhilaohu propre à Huawei ; ce que l'Occident appellerait »un tigre en papier'. C'était un document plein de style, mais sans substance. Pour lui donner un véritable coup de pouce, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe des connaissances et des compétences continues.

Publié à l'origine dans L'ère de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement autour du support de sécurité continu de Wind River Systems pour son produit de système d'exploitation en temps réel, VxWorks.
Un rapport récent du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus de génie logiciel de Huawei. Alors qu'une grande partie de l'actualité concernant ce rapport critique se concentre sur des problèmes non résolus survenus l'année précédente, le problème le plus dangereux et le plus négligé est l'absence flagrante de directives et de pratiques de codage sécurisé utilisées par Huawei. Mais c'est un problème qui peut être résolu.
Les nouvelles, pour le géant chinois des télécommunications Huawei, ne font qu'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de participer à de futurs travaux gouvernementaux, le Royaume-Uni a davantage accepté le fait que bon nombre des failles sous-jacentes des appareils et du code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Centre d'évaluation de la cybersécurité de Huawei (HCSEC) en 2010 pour évaluer et résoudre les problèmes de sécurité des produits Huawei, et pour produire un rapport annuel à leur sujet. Cependant, cette année, le rapport était particulièrement accablant.
L'attention portée au rapport 2019 de la HCSEC dans les actualités est due en grande partie au fait que pratiquement aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River, qui sera bientôt mise en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera du soutien continu de Wind River Systems), mais celui-ci reste un élément central de la plupart des infrastructures de télécommunications du Royaume-Uni.
Un facteur critique qui semble avoir été négligé par la plupart des médias grand public est ce qui pourrait être un processus fondamentalement interrompu, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de « problèmes techniques importants » liés à la manière dont Huawei gère ses méthodes d'ingénierie internes.
Examinons quelques exemples des problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisées pour aider ses ingénieurs et programmeurs à déployer de nouveaux codes. Ces directives couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues de fonctions et de processus système provenant de bibliothèques fiables, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production Huawei au Royaume-Uni a révélé que ces directives n'étaient jamais communiquées aux programmeurs, ignorées par eux ou simplement non appliquées.
Le rapport a examiné des fonctions spécifiques de gestion de la mémoire dans les applications destinées au public, en l'occurrence un ensemble de babillards électroniques où les utilisateurs étaient invités, en fonction du programme, à ajouter des informations. Étant donné que les zones de saisie par les utilisateurs ne devraient jamais être considérées comme « fiables », il était prévu que ces zones ne contiennent que du code sécurisé, conformément aux directives internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de gestion de la mémoire memcpy (), strcpy () et sprintf () dans ces systèmes de production, connues pour entraîner de graves problèmes de sécurité tels que le débordement de la mémoire tampon depuis 1988 .
Étonnamment, il y a eu 5 000 appels directs de 17 fonctions memcpy () sûres connues, mais également 600 utilisations de 12 variantes non sécurisées. Le ratio était à peu près le même que pour les autres fonctions. Il y a eu 1 400 invocations sécurisées avec strcpy (), mais aussi 400 mauvaises avec des vulnérabilités connues. Et 2 000 utilisations sûres de sprintf () ont été découvertes, contre 200 utilisations dangereuses. Le fait que la plupart des utilisations de ces fonctions aient été sécurisées est une bonne chose, mais cela laisse environ 20 % du code global vulnérable aux attaques connues. Il s'agit d'une zone d'attaque de surface de menace énorme, et elle ne prend en compte que les appels directs des trois fonctions de gestion de la mémoire, et non les cas de leur utilisation indirecte via des pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à présenter des problèmes.
Bien que Huawei ait créé un guide des meilleures pratiques pour ses programmeurs, il est clair qu'il reste encore beaucoup à faire. Définir les attentes en matière de sécurité ne constitue qu'une étape, mais elles ne sont efficaces que si ces directives sont activement suivies et familières à la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de suivre les directives internes de Huawei. Ils doivent faire un pas supplémentaire en démontrant comment coder de manière plus sécurisée en général. Les codeurs doivent être suffisamment formés aux bons modèles de codage (sécurisés) et aux mauvais modèles (non sécurisés) et avoir la responsabilité de mettre en pratique ce que leur entreprise prêche à chaque fois.
De nombreux problèmes de codage spécifiques décrits dans le rapport de la HCSEC sont abordés et appliqués dans le cadre du Secure Code Warrior plateforme, qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais se fier aux entrées des utilisateurs, toujours extraire des fonctions des bibliothèques établies, nettoyer toutes les entrées avant de les transmettre à un serveur et de nombreuses autres pratiques de codage sûres sont constamment démontrés sur la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.
Outre une formation qualifiée, des entreprises comme Huawei pourraient utiliser les solutions DevSecOps. Il ajoute un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées personnalisées selon les directives de sécurité de l'entreprise, agissant en tant que sous-chef du développeur dans la « cuisine » de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un « livre de recettes » contenant des recettes conformes à leurs politiques et facilitant l'exécution des commandes.
L'une des principales leçons à tirer des problèmes de Huawei est que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans ce cas, les directives internes sur les meilleures pratiques se sont révélées être le zhilaohu propre à Huawei ; ce que l'Occident appellerait »un tigre en papier'. C'était un document plein de style, mais sans substance. Pour lui donner un véritable coup de pouce, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe des connaissances et des compétences continues.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.Directeur général, président et cofondateur
Pieter Danhieux est un expert en sécurité mondialement reconnu, avec plus de 12 ans d'expérience en tant que consultant en sécurité et 8 ans en tant qu'instructeur principal pour SANS, enseignant des techniques offensives sur la façon de cibler et d'évaluer les organisations, les systèmes et les individus pour les faiblesses de sécurité. En 2016, il a été reconnu comme l'une des personnes les plus cool d'Australie dans le domaine de la technologie (Business Insider), a reçu le prix du professionnel de la cybersécurité de l'année (AISA - Australian Information Security Association) et détient les certifications GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Publié à l'origine dans L'ère de l'information. Il s'agit d'une version mise à jour qui corrige le positionnement autour du support de sécurité continu de Wind River Systems pour son produit de système d'exploitation en temps réel, VxWorks.
Un rapport récent du centre d'évaluation de la cybersécurité de Huawei au Royaume-Uni a identifié des problèmes de sécurité majeurs dans les processus de génie logiciel de Huawei. Alors qu'une grande partie de l'actualité concernant ce rapport critique se concentre sur des problèmes non résolus survenus l'année précédente, le problème le plus dangereux et le plus négligé est l'absence flagrante de directives et de pratiques de codage sécurisé utilisées par Huawei. Mais c'est un problème qui peut être résolu.
Les nouvelles, pour le géant chinois des télécommunications Huawei, ne font qu'empirer. Alors que les États-Unis ont carrément interdit à l'entreprise de participer à de futurs travaux gouvernementaux, le Royaume-Uni a davantage accepté le fait que bon nombre des failles sous-jacentes des appareils et du code de Huawei peuvent être corrigées. Le Royaume-Uni a créé le Centre d'évaluation de la cybersécurité de Huawei (HCSEC) en 2010 pour évaluer et résoudre les problèmes de sécurité des produits Huawei, et pour produire un rapport annuel à leur sujet. Cependant, cette année, le rapport était particulièrement accablant.
L'attention portée au rapport 2019 de la HCSEC dans les actualités est due en grande partie au fait que pratiquement aucune faille de sécurité de l'année précédente n'a été corrigée. Cela inclut l'utilisation d'une ancienne version du système d'exploitation en temps réel VxWorks de Wind River, qui sera bientôt mise en fin de vie. Huawei a promis de résoudre ce problème (et bénéficiera du soutien continu de Wind River Systems), mais celui-ci reste un élément central de la plupart des infrastructures de télécommunications du Royaume-Uni.
Un facteur critique qui semble avoir été négligé par la plupart des médias grand public est ce qui pourrait être un processus fondamentalement interrompu, existant dans le cadre du développement et du déploiement de nouveaux logiciels et matériels par l'entreprise. Le rapport fait état de « problèmes techniques importants » liés à la manière dont Huawei gère ses méthodes d'ingénierie internes.
Examinons quelques exemples des problèmes techniques décrits dans le rapport. Il faut dire que l'une des meilleures choses que Huawei ait faites a été de créer des directives de codage sécurisées pour aider ses ingénieurs et programmeurs à déployer de nouveaux codes. Ces directives couvrent un large éventail de bonnes pratiques, telles que l'utilisation de versions sûres connues de fonctions et de processus système provenant de bibliothèques fiables, et certainement pas de variantes présentant des vulnérabilités connues. C'est une bonne chose en théorie, mais une évaluation réelle d'un système de production Huawei au Royaume-Uni a révélé que ces directives n'étaient jamais communiquées aux programmeurs, ignorées par eux ou simplement non appliquées.
Le rapport a examiné des fonctions spécifiques de gestion de la mémoire dans les applications destinées au public, en l'occurrence un ensemble de babillards électroniques où les utilisateurs étaient invités, en fonction du programme, à ajouter des informations. Étant donné que les zones de saisie par les utilisateurs ne devraient jamais être considérées comme « fiables », il était prévu que ces zones ne contiennent que du code sécurisé, conformément aux directives internes de Huawei. Plus précisément, les testeurs ont examiné l'invocation directe des fonctions de gestion de la mémoire memcpy (), strcpy () et sprintf () dans ces systèmes de production, connues pour entraîner de graves problèmes de sécurité tels que le débordement de la mémoire tampon depuis 1988 .
Étonnamment, il y a eu 5 000 appels directs de 17 fonctions memcpy () sûres connues, mais également 600 utilisations de 12 variantes non sécurisées. Le ratio était à peu près le même que pour les autres fonctions. Il y a eu 1 400 invocations sécurisées avec strcpy (), mais aussi 400 mauvaises avec des vulnérabilités connues. Et 2 000 utilisations sûres de sprintf () ont été découvertes, contre 200 utilisations dangereuses. Le fait que la plupart des utilisations de ces fonctions aient été sécurisées est une bonne chose, mais cela laisse environ 20 % du code global vulnérable aux attaques connues. Il s'agit d'une zone d'attaque de surface de menace énorme, et elle ne prend en compte que les appels directs des trois fonctions de gestion de la mémoire, et non les cas de leur utilisation indirecte via des pointeurs de fonction. Bien que les auditeurs n'aient examiné que ces fonctions spécifiques, il est peu probable que les trois fonctions de gestion de la mémoire choisies soient les seules à présenter des problèmes.
Bien que Huawei ait créé un guide des meilleures pratiques pour ses programmeurs, il est clair qu'il reste encore beaucoup à faire. Définir les attentes en matière de sécurité ne constitue qu'une étape, mais elles ne sont efficaces que si ces directives sont activement suivies et familières à la cohorte de développement. Huawei pourrait faire des progrès significatifs dans l'amélioration de sa sécurité en s'engageant à former ses programmeurs de manière efficace, et en ne se contentant pas de suivre les directives internes de Huawei. Ils doivent faire un pas supplémentaire en démontrant comment coder de manière plus sécurisée en général. Les codeurs doivent être suffisamment formés aux bons modèles de codage (sécurisés) et aux mauvais modèles (non sécurisés) et avoir la responsabilité de mettre en pratique ce que leur entreprise prêche à chaque fois.
De nombreux problèmes de codage spécifiques décrits dans le rapport de la HCSEC sont abordés et appliqués dans le cadre du Secure Code Warrior plateforme, qui forme les programmeurs et les équipes de cybersécurité à toujours déployer et maintenir un code sécurisé. Des concepts tels que ne jamais se fier aux entrées des utilisateurs, toujours extraire des fonctions des bibliothèques établies, nettoyer toutes les entrées avant de les transmettre à un serveur et de nombreuses autres pratiques de codage sûres sont constamment démontrés sur la plate-forme. Nous examinons également des vulnérabilités très spécifiques et montrons, étape par étape, comment les éviter et les atténuer.
Outre une formation qualifiée, des entreprises comme Huawei pourraient utiliser les solutions DevSecOps. Il ajoute un coaching en temps réel directement dans l'IDE, en utilisant des recettes de codage sécurisées personnalisées selon les directives de sécurité de l'entreprise, agissant en tant que sous-chef du développeur dans la « cuisine » de codage pendant qu'il écrit son code. Une telle approche pourrait aider les programmeurs de Huawei, quel que soit leur niveau de compétence, à écrire un meilleur code et à reconnaître les vulnérabilités potentielles, tout en permettant aux experts en sécurité de Huawei de créer un « livre de recettes » contenant des recettes conformes à leurs politiques et facilitant l'exécution des commandes.
L'une des principales leçons à tirer des problèmes de Huawei est que la création de directives de codage sécurisées n'a aucun sens si les programmeurs ne les connaissent pas ou ne savent tout simplement pas comment suivre les bonnes pratiques de codage. Dans ce cas, les directives internes sur les meilleures pratiques se sont révélées être le zhilaohu propre à Huawei ; ce que l'Occident appellerait »un tigre en papier'. C'était un document plein de style, mais sans substance. Pour lui donner un véritable coup de pouce, il faudrait disposer des bons outils pratiques et d'un véritable programme de formation, qui adopte une approche pratique et développe des connaissances et des compétences continues.
Table des matières
Directeur général, président et cofondateur

Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.




%20(1).avif)
.avif)
