7 étapes pour sécuriser les systèmes embarqués connectés

Temps de lecture  : 5 minutes

Suivant les meilleures pratiques associées au shift left, l'approche de test précoce produit un code de haute qualité et améliore la sécurité des appareils embarqués connectés.

Les constructeurs aérospatiaux développant des applications embarquées de plus en plus critiques – contrôle du trafic aérien et autres systèmes électroniques embarqués – ne peuvent pas se permettre de prendre des risques sur la sécurité de leur code logiciel. Ces systèmes connectés présentent de multiples surfaces d’attaque vulnérables aux mauvais acteurs. Se défendre contre de telles attaques peut être une tâche ardue mais nécessaire.

Souvent, les logiciels embarqués critiques en matière de sécurité sont d'abord développés puis testés ultérieurement, créant invariablement un code non sécurisé qui met en danger les personnes et les biens. Une étape clé dans la création de systèmes sécurisés consiste à garantir que la sécurité est intégrée au cycle de vie du développement logiciel conformément à la DO-326, qui comprend la conception, la mise en œuvre, la vérification et la validation en parallèle avec la norme de sécurité fonctionnelle DO-178C pour l'aérospatiale. Ce changement d'approche, consistant à tester tôt, entraîne des coûts inférieurs et moins de maux de tête que les tests réactifs et la sécurisation de la vérification du code ultérieurement. Pour produire un code de haute qualité et améliorer la sécurité de ces appareils embarqués connectés avec cette méthode, tenez compte de ces bonnes pratiques.

Des exigences non documentées entraînent des problèmes de communication et créent des retouches, des modifications et des corrections de bugs, ainsi que des vulnérabilités de sécurité. Pour garantir un développement fluide du projet, toutes les parties du produit et son processus de développement doivent être compris de la même manière par chaque membre de l'équipe. Des exigences fonctionnelles et de sécurité clairement définies contribuent à garantir cela.

L'automatisation facilite le maintien d'une traçabilité bidirectionnelle (vers l'avant et vers l'arrière) dans un environnement de projet en évolution.

La traçabilité amont démontre que toutes les exigences sont reflétées à chaque étape du processus de développement, y compris la mise en œuvre et les tests. L'impact des exigences modifiées ou des cas de test échoués peut être évalué en appliquant une analyse d'impact, qui peut ensuite être traitée. La mise en œuvre qui en résulte peut ensuite être testée à nouveau pour présenter la preuve du respect continu des principes de traçabilité bidirectionnelle.

La traçabilité en amont est tout aussi importante, qui met en évidence le code qui ne répond à aucune des exigences spécifiées. La surveillance, une logique défectueuse, la dérive des fonctionnalités et les méthodes de porte dérobée malveillantes peuvent toutes introduire des vulnérabilités ou des erreurs de sécurité. La traçabilité automatisée peut isoler ce qui est nécessaire et permettre de tester automatiquement uniquement les fonctions concernées.

Le développement de code avec MISRA C entraîne moins d'erreurs de codage car il comporte des règles plus strictes et plus décidables définies sur la base de premiers principes. La capacité d'analyser rapidement et facilement les logiciels en référence aux normes de codage MISRA C peut améliorer la qualité et la cohérence du code et réduire le temps de déploiement. En revanche, lorsque les développeurs doivent appliquer des règles au code de manière rétrospective, le CERT C peut se montrer pragmatique. L'analyse du code par rapport au CERT C identifie les erreurs de programmation courantes derrière la plupart des attaques de sécurité logicielle.

L’application de MISRA C ou CERT C permet d’obtenir un code plus sécurisé. L’application manuelle de telles normes sur une base de code de taille significative n’est pas pratique, c’est pourquoi un outil d’analyse statique est nécessaire pour automatiser le travail.

Dans les secteurs critiques pour la sécurité, ces normes complètent souvent celles axées sur la sécurité fonctionnelle. Par exemple, dans le secteur automobile, le J3061 « Cybersecurity Guidebook for Cyber-Physical Vehicle Systems » (bientôt remplacé par la norme ISO/SAE 21434 « Road Vehicles – Cybersecurity Engineering ») complète la norme de sécurité fonctionnelle automobile ISO 26262. Les outils de développement automatisés peuvent être intégrés aux flux de travail des développeurs pour les systèmes critiques en matière de sécurité et peuvent répondre simultanément aux demandes de sécurité fonctionnelle.

L'analyse statique est un nom collectif pour les régimes de tests impliquant une inspection automatisée du code source. En revanche, l’analyse dynamique implique l’exécution de tout ou partie du code source. L'accent mis par ces techniques sur les problèmes de sécurité aboutit à des tests de sécurité d'analyse statique (ou d'application) (SAST) et à des tests de sécurité d'analyse dynamique (ou d'application) (DAST).

Il existe de grandes variations au sein de ces groupes. Par exemple, les tests d'intrusion, fonctionnels et fuzz sont tous des DAST en boîte noire qui ne nécessitent pas d'accès au code source pour fonctionner. Les DAST en boîte noire complètent les DAST en boîte blanche, qui incluent des tests unitaires, d'intégration et système pour révéler les vulnérabilités du code source de l'application grâce à une analyse dynamique.

Certains outils SAST sont utilisés pour confirmer le respect des normes de codage, garantir que la complexité est minimisée et vérifier que le code est maintenable. D'autres sont utilisés pour vérifier les failles de sécurité, mais uniquement dans la mesure où de telles vérifications sont possibles sur le code source sans environnement d'exécution.

Le DAST en boîte blanche permet de tester le code compilé et exécuté dans l'environnement de développement ou, mieux encore, sur le matériel cible. La couverture du code facilite la confirmation que toutes les exigences de sécurité et autres sont remplies par le code, et que tout le code satisfait à une ou plusieurs exigences. Ces contrôles peuvent même aller jusqu'au niveau du code objet si le système l'exige.

Les tests de robustesse peuvent être utilisés dans l'environnement de tests unitaires pour démontrer que des fonctions spécifiques sont résilientes, que ce soit de manière isolée ou dans le contexte de leur arborescence d'appels. Les techniques de test de fuzz et de boîte noire de pénétration traditionnellement associées à la sécurité des logiciels restent précieuses, mais dans ce contexte, elles sont utilisées pour confirmer et démontrer la robustesse d'un système conçu et développé avec sécurité.

Pour faciliter la création de logiciels embarqués sécurisés, les développeurs doivent avoir accès à des outils de développement logiciel automatisés pour soutenir leur travail tout au long du cycle de vie du développement logiciel – de la traçabilité et de l'ingénierie à l'analyse logicielle statique et dynamique en passant par les tests unitaires et d'intégration. La précision, le déterminisme et les capacités de reporting formel de ces outils répondent aux exigences d'assurance pour le développement de logiciels fiables et critiques pour la sécurité pour les appareils aérospatiaux connectés.

En suivant ces bonnes pratiques associées au shift left, l’approche de test précoce permet de produire du code de haute qualité et d’améliorer la sécurité des appareils embarqués connectés qui ont apporté de tels changements sismiques à l’ensemble du secteur.