Codage pour la sécurité renouvelable

Article
11/05/2024

Important

Il s’agit de la documentation Azure Sphere (héritée). Azure Sphere (hérité) prend sa retraite le 27 septembre 2027 et les utilisateurs doivent migrer vers Azure Sphere (intégré) pour l’instant. Utilisez le sélecteur de version situé au-dessus du TOC pour afficher la documentation Azure Sphere (intégrée).

La prise en charge de la sécurité renouvelable est l’une des sept propriétés des appareils hautement sécurisés. Dans Azure Sphere, cela signifie que tous les logiciels sur l’appareil, y compris vos propres applications, peuvent être mis à jour en fonction des besoins pour résoudre les vulnérabilités nouvellement découvertes. La sécurité est la raison pour laquelle Azure Sphere existe, et il ne peut pas être souligné trop souvent que maintenir la sécurité de votre appareil à tout moment est primordiale. Il n’est pas possible d’écrire du code complètement sécurisé, mais avec de bonnes pratiques de codage, une diligence extrême pour répondre aux vulnérabilités nouvellement découvertes et un engagement à la sécurité renouvelable, vous pouvez vous assurer que votre code d’application de haut niveau est aussi sécurisé que possible. Le modèle d’isolation d’application Azure Sphere fournit un certain nombre de fonctionnalités pour garantir ce qui suit :

Toutes les applications doivent être signées correctement avant de pouvoir être installées ou exécutées.
Seules les fonctionnalités matérielles et les adresses Internet spécifiées dans le fichier manifeste d’application de l’application sont accessibles par l’application.
Les API fournies par le Kit de développement logiciel (SDK) Azure Sphere incluent un sous-ensemble beaucoup réduit de la bibliothèque C standard, omettant des trous de sécurité potentiels tels que les comptes d’utilisateur et l’accès shell.
Les applications de système d’exploitation et de client Azure Sphere peuvent être mises à jour en toute sécurité à l’aide du service de sécurité Azure Sphere, car les problèmes de sécurité sont identifiés et résolus.

Toutefois, la signature de code et la réduction de la surface d’attaque ne vous prennent que jusqu’à présent. En suivant un ensemble de bonnes pratiques pour le développement de logiciels sécurisés, vous pouvez vous assurer que les applications que vous signez sont aussi sécurisées que possible. Cet article décrit certains des outils utilisés par l’équipe Azure Sphere dans ses propres pratiques de développement.

Planifier des déploiements réguliers

Le système d’exploitation Azure Sphere et le Kit de développement logiciel (SDK) Azure Sphere sont mis à jour au moins tous les trimestres. Vous devez prévoir une planification similaire pour les déploiements de vos propres applications.

Vérifiez que votre chaîne d’outils reste à jour

Le système d’exploitation et le SDK Azure Sphere constituent une grande partie de la chaîne d’outils Azure Sphere, mais vous pouvez avoir d’autres composants que vous gérez séparément. Veillez à vérifier régulièrement les mises à jour de ces composants.

Les vulnérabilités et les expositions courantes sont des rapports publics utilisés pour décrire une vulnérabilité de sécurité dans un système, notamment dans Azure Sphere. Les mises à jour du système d’exploitation Azure Sphere répondent régulièrement aux EV et aident à sécuriser vos appareils. Si possible, incluez des vérifications pour les cvEs dans vos pipelines de build. Les sites de signet tels que la page d’accueil CISA qui effectuent le suivi des mises à jour de sécurité. Regénérer et redéployer vos applications à mesure que vous mettez à jour votre chaîne d’outils.

Propager et respecter les normes de codage

Le code conforme à une norme connue est plus facile à gérer, plus facile à examiner et plus facile à tester. Il existe des normes de codage publiquement disponibles pour C. MISRA est bien établi et CERT a également une norme de codage pour C. En plus de ces normes de base, nous vous recommandons d’utiliser le cycle de vie du développement de la sécurité dans la mesure du possible.

Vérifiez que vous compilez avec des indicateurs de sécurité essentiels

Toutes les applications Azure Sphere sont créées avec des compilateurs de langage C à partir de la collection de compilateurs Gnu (GCC). Le compilateur C, gcc, fournit des centaines d’indicateurs de compilateur et d’éditeur de liens. Dans Azure Sphere, les indicateurs suivants sont utilisés par défaut :

-fstack-protector-strong: génère du code pour vous protéger contre les attaques de fracasser la pile.
pie: génère des exécutables indépendants de la position.
fPIC: génère du code indépendant de la position.

L’indicateur -fstack-protector-all offre plus de protection que -fstack-protector-strong, mais augmente l’utilisation de la pile de mémoire. En raison de la mémoire limitée sur le matériel Azure Sphere actuel, -fstack-protector-all n’est pas utilisée par défaut.

Azure Sphere utilise également un certain nombre d’indicateurs d’avertissement : ceux-ci peuvent être utilisés pour identifier les problèmes liés à votre code pendant la compilation, qui peuvent être résolus avant le déploiement :

-Wall -Wswitch -Wempty-body -Wconversion -Wreturn-type -Wparentheses -Wno-format -Wuninitialized -Wunreachable-code -Wunused-function -Wunused-value -Wunused-variable -Wstrict-prototypes -Wno-pointer-sign -Werror=implicit-function-declaration

Pour plus de sécurité ou -Wl,-z,now -Wl,-z,relro peut être ajouté, mais encore une fois, ceux-ci ne sont pas utilisés par défaut, car ils provoquent une utilisation supplémentaire de la mémoire.

Passer en revue tout le code

Les révisions de code sont un outil simple mais efficace pour garantir un code de haute qualité. Nous vous recommandons d’extraire aucun code sans révision de code d’un réviseur qualifié. Les révisions de code un-à-un, dans lesquelles un développeur parcoure le nouveau code avec un autre développeur, aident souvent le développeur d’origine à clarifier la pensée qui entrait dans la production du code. Cela peut révéler des faiblesses de conception ou des points de branche manqués même sans entrée du développeur de révision.

Utiliser des tests automatisés

Les frameworks de test automatisés tels que gtest vous permettent d’exécuter des suites de fonctions de test chaque fois qu’un projet est généré. Une bonne pratique consiste à s’assurer que tout le code archivé doit être accompagné d’au moins une fonction de test ; plus est généralement mieux. Les types importants de test sont les suivants :

Les tests unitaires de base exécutent chaque élément de code pour vérifier qu’il fonctionne comme prévu. Les cas de test doivent être conçus pour tester le code aux bords ; les cas d’angle et de bord sont généralement une source fructueuse de bogues.
Fuzz teste le code en fournissant une entrée inattendue de différents types pour garantir que la fonction répond de manière appropriée.
Les tests d’intrusion sont utiles pour identifier les vulnérabilités qui permettent aux attaquants de pénétrer dans l’application.

Utiliser des analyseurs de code statiques

Les analyseurs de code statiques peuvent vous aider à trouver un certain nombre de problèmes de code courants. La plupart se concentrent sur des types d’erreurs spécifiques. Les outils gratuits et open source suivants sont parmi ceux utilisés par l’équipe de développement Azure Sphere et certains utilisateurs d’Azure Sphere :

L’exécution de certains de ces outils peut nécessiter la recompilation de votre application (ou des parties de celui-ci) pour un autre système d’exploitation cible.

Supprimer le code inutile

Le Kit de développement logiciel (SDK) Azure Sphere fournit une version supprimée des bibliothèques de développement C standard ; dans la mesure du possible, vous devez rechercher des opportunités de supprimer votre propre code à ses éléments essentiels. Moins de lignes de code sont disponibles, la plus petite surface d’attaque est disponible pour les menaces potentielles. Les avertissements relatifs au code inaccessible ou inutilisé peuvent être utilisés pour identifier le code inutiles.

Partager via