Intégrez la cybersécurité au sein du cycle de vie de la voiture connectée
Un avion contient environ 6,5 millions de lignes de code source. Impressionnant, jusqu'à ce que vous réalisiez que l'automobile moderne, avec une moyenne de 20 millions de lignes de code, a battu l'avion trois fois ! Et à l’heure de la voiture connectée et autonome, la question de la cybersécurité de cette masse conséquente de logiciel devient le sujet primordial de toute la filière.
Sûreté de fonctionnement et cybersécurité dans l’automobile – Le challenge
Au cours des dernières années, l'industrie automobile a mis l’accent, via la création de l'ISO 26262, sur la sécurité fonctionnelle (autrement dit, la sûreté de fonctionnement, ou safety en anglais), mais n’a pas mis autant d’efforts sur la cybersécurité (ou security en anglais), malgré une nouvelle édition de l’ISO 26262 à venir dont c’est notamment l’objet.
Il devient primordial pour l'industrie automobile de rattraper son retard, puisque selon BI Intelligence, le nombre de voitures connectées devrait passer de 36 millions en 2015 à 381 millions en 2020, et alors que des tests continuent à montrer les vulnérabilités de cybersécurité des voitures connectées.
Tout comme pour la sûreté de fonctionnement, le meilleur moyen d’assurer une cybersécurité efficace au sein d’un développement produit, est de l’intégrer au plus tôt dans le cycle de vie, et dans son ensemble.
Pour cela, de nombreuses solutions existent, et elles sont souvent complémentaires, puisqu’aucune solution seule ne peut assurer la cybersécurité d’un produit électronique ou logiciel : « secure element » matériel (intégré à un microcontrôleur par exemple), noyau de séparation ou hyperviseur, secure boot, firewall, secure storage, communication sécurisée…
Et les développeurs logiciels dans tout cela ? Dans la mesure où un nombre important de vulnérabilités logicielles proviennent d’erreurs de codage, ils ont un grand rôle à jouer ! La solution pour eux : mettre en place des méthodologies de qualité du logiciel, telles que celles déjà adoptées dans le monde safety, mais adaptées aux contraintes de cybersécurité.
Il devient primordial pour l'industrie automobile de rattraper son retard, puisque selon BI Intelligence, le nombre de voitures connectées devrait passer de 36 millions en 2015 à 381 millions en 2020, et alors que des tests continuent à montrer les vulnérabilités de cybersécurité des voitures connectées.
Tout comme pour la sûreté de fonctionnement, le meilleur moyen d’assurer une cybersécurité efficace au sein d’un développement produit, est de l’intégrer au plus tôt dans le cycle de vie, et dans son ensemble.
Pour cela, de nombreuses solutions existent, et elles sont souvent complémentaires, puisqu’aucune solution seule ne peut assurer la cybersécurité d’un produit électronique ou logiciel : « secure element » matériel (intégré à un microcontrôleur par exemple), noyau de séparation ou hyperviseur, secure boot, firewall, secure storage, communication sécurisée…
Et les développeurs logiciels dans tout cela ? Dans la mesure où un nombre important de vulnérabilités logicielles proviennent d’erreurs de codage, ils ont un grand rôle à jouer ! La solution pour eux : mettre en place des méthodologies de qualité du logiciel, telles que celles déjà adoptées dans le monde safety, mais adaptées aux contraintes de cybersécurité.
La gestion des exigences, première étape fondamentale d'un cycle de vie logiciel « secure »
Tous les référentiels existants de cybersécurité (IEC 62443 « ISASecure », ISO 15408 « Common Criteria », OWASP, « Top 12 Secure Coding Practices » du CERT, …) s’accordent sur ce point : un cycle de vie logiciel « secure » commence par des exigences de cybersécurité spécifiques présentées par les concepteurs aux développeurs. Elles n'ont de sens que si elles sont unitaires et testables. Leur traçabilité sur tout le cycle de vie logiciel est primordiale afin d’assurer une implémentation correcte et des tests suffisants. De plus, la mesure de la qualité même des exigences (Est-elle correctement rédigée ? Est-elle compréhensible, sans ambiguïté ?) permet souvent de détecter dès le début d’un projet des vulnérabilités potentielles futures !
Utiliser une solution de gestion des exigences comme Visure Requirements facilite grandement l’ensemble de ces points, en automatisant la traçabilité des exigences sur tout un cycle produit, en facilitant leur rédaction et enfin en effectuant des mesure de qualimétrie des exigences.
Utiliser une solution de gestion des exigences comme Visure Requirements facilite grandement l’ensemble de ces points, en automatisant la traçabilité des exigences sur tout un cycle produit, en facilitant leur rédaction et enfin en effectuant des mesure de qualimétrie des exigences.
Adopter des règles de codage secure
Un standard de codage définit des règles visant à limiter certaines possibilités offertes par le langage de programmation utilisé, et pouvant amener ou faciliter l’intrusion d’erreurs.
La référence est le CERT C, qui comporte une centaine de règles pour le développement de systèmes cybersécurisés. Un autre standard, plus concis (46 règles) est l’ISO TS 17961 (aussi appelé « C Secure Coding Rules »), réalisé par le groupe ISO chargé de la normalisation du langage C, et directement inspiré du CERT C. Enfin, le standard MISRA C, à la base plutôt dédié « développement critique safety », intègre dans sa dernière version, le MISRA C:2012 Amendement 1, l’ensemble des règles de codage qui lui manquait pour couvrir complètement le standard C Secure, devenant donc un standard de codage « safe & secure » .
Le choix d’un standard pré-existant, ou la création d’un standard personnalisé, dépend essentiellement de l’objectif de l’équipe de développement (favoriser la sûreté de fonctionnement, la cybersécurité, ou les deux ?), des habitudes de programmation de l’équipe, et des moyens dont elle dispose pour vérifier les non-conformités. Car quiconque écrit du texte dans Word® le sait, quel que soit son niveau d’écrit : sans correcteur automatique ou relecture a posteriori, quelques erreurs d’orthographe, de conjugaison ou de grammaire se glissent inévitablement dans la prose…
Pour cela, utiliser un outil d’analyse statique syntaxique comme LDRArules, contenant l’ensemble des standards de sûreté et de cybersécurité usuels pour les langages C et C++, c’est limiter l’intrusion d’erreurs dans son code, tout en automatisant sa vérification !
La référence est le CERT C, qui comporte une centaine de règles pour le développement de systèmes cybersécurisés. Un autre standard, plus concis (46 règles) est l’ISO TS 17961 (aussi appelé « C Secure Coding Rules »), réalisé par le groupe ISO chargé de la normalisation du langage C, et directement inspiré du CERT C. Enfin, le standard MISRA C, à la base plutôt dédié « développement critique safety », intègre dans sa dernière version, le MISRA C:2012 Amendement 1, l’ensemble des règles de codage qui lui manquait pour couvrir complètement le standard C Secure, devenant donc un standard de codage « safe & secure » .
Le choix d’un standard pré-existant, ou la création d’un standard personnalisé, dépend essentiellement de l’objectif de l’équipe de développement (favoriser la sûreté de fonctionnement, la cybersécurité, ou les deux ?), des habitudes de programmation de l’équipe, et des moyens dont elle dispose pour vérifier les non-conformités. Car quiconque écrit du texte dans Word® le sait, quel que soit son niveau d’écrit : sans correcteur automatique ou relecture a posteriori, quelques erreurs d’orthographe, de conjugaison ou de grammaire se glissent inévitablement dans la prose…
Pour cela, utiliser un outil d’analyse statique syntaxique comme LDRArules, contenant l’ensemble des standards de sûreté et de cybersécurité usuels pour les langages C et C++, c’est limiter l’intrusion d’erreurs dans son code, tout en automatisant sa vérification !
Les erreurs « Runtime », les tainted value et les librairies tierces : les principaux vecteurs d’attaque !
Selon le Common Weakness Enumeration (cwe.mitre.org), parmi les 25 erreurs logicielles les plus dangereuses, se trouvent les injections de code, les erreurs d’authentification / encryption, et enfin, les erreurs runtime comme les classiques dépassements de tableaux / buffer / ...
Limiter ce type d’erreurs est possible via la mise en place de règles de codage appropriées, mais n’est cependant pas suffisant, car ces erreurs sont très dépendantes de l’exécution d’un chemin dans le code source plutôt qu’un autre, ou de la valeur de départ des variables, ce dont ne tiennent pas compte les analyseurs statiques syntaxiques. De plus, les tests dynamiques classiques ne sont pas non plus le meilleur moyen de détecter au plus tôt ces problèmes, car encore faut-il trouver (ou avoir la chance de tomber sur) le bon cas de test qui révèlera l’erreur…
Pour les problèmes runtime, la solution la plus rapide et efficace, et donc la moins couteuse, consiste à utiliser un outil d’analyse statique avancé comme GrammaTech CodeSonar, qui crée un modèle abstrait du code source permettant une analyse de l’ensemble des chemins et valeurs de variables possibles, et remontant des détections d’erreurs runtime comme les dépassements de tableaux, déréférencements de pointeurs nuls, altérations de données, …
GrammaTech CodeSonar permet en plus de détecter les points d’entrées de tainted data dans un code source, c’est-à-dire de données provenant de l’extérieur de l’application et non vérifiées (contenu transitant par un réseau classique, lecture de fichier, variable d’environnement, donnée provenant d’un capteur autonome, …), ainsi que l’analyse de librairies tierces intégrées au produit, et dont le contenu est souvent très vulnérable en terme de cybersécurité !
Limiter ce type d’erreurs est possible via la mise en place de règles de codage appropriées, mais n’est cependant pas suffisant, car ces erreurs sont très dépendantes de l’exécution d’un chemin dans le code source plutôt qu’un autre, ou de la valeur de départ des variables, ce dont ne tiennent pas compte les analyseurs statiques syntaxiques. De plus, les tests dynamiques classiques ne sont pas non plus le meilleur moyen de détecter au plus tôt ces problèmes, car encore faut-il trouver (ou avoir la chance de tomber sur) le bon cas de test qui révèlera l’erreur…
Pour les problèmes runtime, la solution la plus rapide et efficace, et donc la moins couteuse, consiste à utiliser un outil d’analyse statique avancé comme GrammaTech CodeSonar, qui crée un modèle abstrait du code source permettant une analyse de l’ensemble des chemins et valeurs de variables possibles, et remontant des détections d’erreurs runtime comme les dépassements de tableaux, déréférencements de pointeurs nuls, altérations de données, …
GrammaTech CodeSonar permet en plus de détecter les points d’entrées de tainted data dans un code source, c’est-à-dire de données provenant de l’extérieur de l’application et non vérifiées (contenu transitant par un réseau classique, lecture de fichier, variable d’environnement, donnée provenant d’un capteur autonome, …), ainsi que l’analyse de librairies tierces intégrées au produit, et dont le contenu est souvent très vulnérable en terme de cybersécurité !
Modèle abstrait d’un code source par GrammaTech CodeSonar
La couverture structurelle offre la confiance
Les tests dynamiques (tests fonctionnels, fuzz testing, tests unitaires, …) restent indispensables dans toute démarche de cybersécurité. Et lorsqu'il s'agit d'exécuter et de tester du code compilé, l'analyse de la couverture structurelle permet de mesurer l'efficacité du processus de test en identifiant et en mettant en évidence quel code a été testé et quel code ne l'a pas été. Plus les composants logiciels sont critiques en termes de sûreté ou de sécurité, plus l'analyse des niveaux de couverture doit être exigeante, allant de la simple couverture des instructions à la couverture des branches voire MC/DC.
Pour ce faire, LDRAcover instrumente tout code source C/C++/Java/Ada et indique chaque instruction ou branche couverte ou non couverte durant une ou plusieurs exécutions, afin de maximiser la couverture structurelle de vos applications.
La cybersécurité au sein de la voiture connectée ou autonome passe par son intégration au plus tôt dans le cycle de vie, et au niveau du développement logiciel, par la mise en place de méthodologies de développement adaptées aux contraintes de cybersécurité, mais connues et éprouvées au sein de projets safety, ainsi que par la mise en place d’outils automatisant tout ou partie des tâches de vérification.
Pour ce faire, LDRAcover instrumente tout code source C/C++/Java/Ada et indique chaque instruction ou branche couverte ou non couverte durant une ou plusieurs exécutions, afin de maximiser la couverture structurelle de vos applications.
La cybersécurité au sein de la voiture connectée ou autonome passe par son intégration au plus tôt dans le cycle de vie, et au niveau du développement logiciel, par la mise en place de méthodologies de développement adaptées aux contraintes de cybersécurité, mais connues et éprouvées au sein de projets safety, ainsi que par la mise en place d’outils automatisant tout ou partie des tâches de vérification.
Mesure de la couverture structurelle d’un code source, avec indication des branches non parcourues