Optez pour une voie plus rapide et plus intelligente vers l'automatisation des tests C/C++ pilotée par l'IA. Découvrez comment >>
3 façons pratiques de pérenniser vos appareils IoT
L'Internet des objets n'a cessé d'évoluer, mais comment s'assurer qu'il respecte les normes de sécurité et de sûreté ? Voici trois façons de vous assurer que vos appareils IoT intégrés répondent aux futures normes de sécurité et de conformité.
L'Internet des objets n'a cessé d'évoluer, mais comment s'assurer qu'il respecte les normes de sécurité et de sûreté ? Voici trois façons de vous assurer que vos appareils IoT intégrés répondent aux futures normes de sécurité et de conformité.
Malgré le potentiel des appareils embarqués dans le contexte de l'IdO, de nombreux appareils ne sont actuellement pas tenus de se conformer aux normes de sûreté ou de sécurité. Mais dans le monde Agile du développement IoT, les exigences de conformité peuvent venir beaucoup plus tard, une fois que le code a déjà été écrit et testé. Alors, comment préparer l'avenir de vos appareils IoT embarqués?
Le terme Internet des objets (IoT) fait référence à un système d'appareils, de composants ou de services connectés au réseau qui publient et/ou consomment des données. Applications IoT font désormais partie intégrante de notre vie : des robots industriels et instruments chirurgicaux aux voitures autonomes et aux drones volants de manière autonome. Aujourd’hui, bon nombre de ces appareils peuvent déjà avoir un impact sur la sécurité, la confidentialité et la sécurité de leurs utilisateurs. Dans certains cas, le coût d’une panne est mortel, il est donc essentiel de construire ces appareils conformément aux normes en vigueur.
S'il est préférable d'intégrer les activités de conformité dès le début de la conception logicielle, il est bien connu que des processus de développement rigoureux (surtout sans automatisation) peuvent impacter les délais de mise sur le marché. Rares sont les développeurs qui apprécient effectuer des tests supplémentaires et documenter la traçabilité en dehors des heures de travail habituelles. Les équipes pragmatiques, agiles et dynamiques ne peuvent donc souvent pas se permettre de perdre leur élan en intégrant la conformité au planning sous prétexte qu'elles pourraient en avoir besoin ultérieurement. Au lieu de cela, de nombreuses équipes choisissent de « franchir le pas quand elles le pourront ».
Malheureusement, il n'existe pas de solution miracle ni de solution miracle permettant de rendre rétroactivement un code conforme. Ces organisations apprennent à leurs dépens que le coût de la mise en conformité en fin de projet est bien supérieur au coût de développement du produit initial fonctionnel.
Alors, quelles actions à faible impact pouvez-vous prendre aujourd'hui pour vous préparer à satisfaire les exigences de conformité strictes de demain?
Il est important de comprendre où en est votre projet en ce momentL’ montant de la dette technique est le coût d'une refonte potentielle due à la complexité du code combinée à toute norme de codage restante et aux violations de sécurité qui existent actuellement dans le code. Cette dette est due au nettoyage, à la correction et aux tests ultérieurs du code. L'une des façons de bien comprendre où en est un projet aujourd'hui est d'utiliser l'analyse de code statique automatisée. L'analyse statique donne un aperçu de la qualité et de la sécurité d'une base de code et énumère les violations des normes de codage, le cas échéant.
Malheureusement, de nombreuses équipes développant des applications embarquées en C et C ++ s'appuient toujours sur leur compilateur ou sur des revues de code manuelles pour détecter les problèmes, au lieu d'adopter une analyse statique. Certaines équipes ont du mal à adopter des outils d'analyse statique pour diverses raisons, comme les trouver bruyantes et difficiles à utiliser (cela ne devrait pas être un problème si vous apprenez à bien démarrer) ou à défaut de l'intégrer dans le processus de développement quotidien en raison de problèmes quotidiens urgents. Une perception (erronée) courante est que le temps passé à déterminer quelles violations méritent d'être corrigées est supérieur à la valeur de la correction réelle.
Mais nous constatons que les équipes qui ont adopté un petit ensemble de règles critiques et obligatoires ont passé beaucoup moins de temps à retravailler le code face à des audits de sécurité fonctionnelle plus tard dans le projet. Il est beaucoup plus facile de créer des systèmes sûrs et sécurisés à partir de zéro en intégrant la sécurité en implémentant, par exemple, les directives de codage sécurisé CERT C. Vous pouvez commencer petit. CERT dispose d'un système de hiérarchisation sophistiqué (utilisant la gravité, la probabilité et le coût de la correction, chacun en 3 niveaux, 27 niveaux au total), et si vous utilisez les outils Parasoft, vous pouvez facilement afficher l'état de la conformité dans un tableau de bord préconfiguré.
L'analyse statique aide également les organisations à comprendre leur dette technique en collectant des points de données qui aident la direction à respecter la sûreté et la sécurité. Les gestionnaires peuvent facilement évaluer les questions importantes, telles que:
Certaines normes nécessitent de mesurer la complexité cyclomatique, pour la maintenir en dessous d'un certain seuil. Les métriques de complexité peuvent également être utilisées pour estimer un effort de test - par exemple, le nombre de cas de test dont vous avez besoin pour démontrer une couverture de niveau de branche à 100% pour se conformer à la norme CEI 61508 SIL 2 sera proportionnel à la complexité cyclomatique McCabe d'une fonction.
Voici un exemple d'un tableau de bord montrant la conformité MISRA d'un projet dans Parasoft DTP, le hub de reporting et d'analyse de Parasoft:
Et voici la même chose pour CERT C:
La valeur de voir les métriques de code peut aider à exposer des zones plus complexes pour une révision de code supplémentaire et à surveiller dans quelle mesure ces zones sont couvertes par les tests. Voici un exemple de tableau de bord des mesures:
Vous pouvez donc commencer par les bases. Une fois que l'équipe maîtrise la gestion des erreurs les plus critiques, vous pouvez élargir l'étendue des violations des normes. Toutes les règles ne sont pas immuables ; il est donc important de déterminer celles qui sont incluses ou non dans la norme de codage du projet. Au minimum, l'adoption des règles obligatoires de quelques normes de codage clés (par exemple, les règles obligatoires MISRA ou les règles CERT C) facilite l'argumentation future en matière de sûreté et de sécurité d'un appareil connecté.
La plupart des ingénieurs pragmatiques s'accordent à dire que créer aveuglément des tests unitaires pour toutes vos fonctions n'offre pas un bon retour sur investissement. Cependant, si votre équipe a accès à un cadre de tests unitaires Dans le cadre du sandbox du projet, il s'agit d'un investissement précieux. Les tests unitaires peuvent être utilisés intelligemment lorsque les ingénieurs estiment devoir tester isolément certains algorithmes complexes ou certaines manipulations de données. Le développement de tests unitaires présente également un intérêt considérable : nous avons constaté dans les organisations que la simple écriture et l'exécution d'un test unitaire renforcent la robustesse et la conception du code.
Lorsque des exigences de sécurité ou de conformité se posent, une organisation peut rapidement intensifier l'effort de test unitaire en ajoutant temporairement des membres du personnel. Mais pour faire évoluer rapidement cet effort, le cadre et le processus de test unitaire doivent déjà être compris et documentés au cours du projet. Les caractéristiques communes d'un cadre de test unitaire évolutif en tenant compte de la conformité future sont les suivantes:
La clé à retenir est de déployer toutes les techniques de test requises par une future norme de sécurité, mais à une échelle minimale. Il est plus facile pour cela d'évoluer quand et si un besoin de certification apparaît plutôt que de repartir de zéro.
L'architecture des systèmes embarqués exige de prendre en compte de nombreux critères : simplicité, portabilité, maintenabilité, évolutivité et fiabilité, tout en conciliant latence, débit, consommation d'énergie et contraintes de taille. Lors de l'architecture d'un système potentiellement connecté à un vaste écosystème IoT, de nombreuses équipes négligent ces priorités. sécurité et Sécurité sur certains de ces autres facteurs de qualité.
Pour faciliter la conformité future en matière de sécurité (et suivre les bonnes pratiques architecturales), vous pouvez séparer les composants dans le temps et dans l'espace. Par exemple, vous pouvez concevoir un système dans lequel toutes les opérations critiques sont exécutées sur un processeur dédié séparé, tout en exécutant toutes les opérations non critiques sur un autre - offrant ainsi une séparation physique. Une autre option consiste à utiliser un hyperviseur de noyau de séparation et des concepts de micro-noyau. Il existe d'autres options disponibles, mais la clé est d'adopter des approches architecturales clés séparation des préoccupations, défense en profondeur, et séparation pour criticité mixte le plus tôt possible. Ces approches réduisent non seulement la quantité de travail requise pour se conformer aux normes de sûreté et de sécurité, mais elles améliorent également la qualité et la résilience de l'application. Par exemple, voici quelques moyens d'isoler le code critique:
La séparation des fonctions critiques des fonctions non critiques réduit la portée des efforts de vérification futurs pour démontrer la conformité.
De nombreux appareils de périphérie de l'écosystème IoT fournissent des services critiques susceptibles de relever de futures normes de sûreté et de sécurité. Bien entendu, essayer de se conformer aux exigences des normes, sans savoir si c'est nécessaire ou non, n'est pas une stratégie rentable. Pour se préparer à l'avenir, les organisations peuvent adopter des techniques de conception clés, des approches de test unitaire et des outils d'analyse statique, et collecter des mesures pour répondre aux besoins futurs. Les équipes logicielles peuvent adopter ces approches de manière transparente dans leurs processus existants si elles ont été lancées suffisamment tôt. Commencer tôt avec la bonne approche qui peut être mise à l'échelle plus tard pour éviter la nécessité d'un effort presque herculéen pour mettre le code logiciel en conformité lorsqu'il a été développé, testé et déployé.
« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Tous droits réservés.
