Développer du code cybersecure et respecter l’ISA / IEC 62443 : comment faire ?
La norme ISA / IEC 62443 (anciennement ISA 99) est un ensemble de normes de processus pour le développement de produits industriels « cybersécurisés ». Elle couvre de nombreux aspects liés à la cybersécurité (mécanismes comme le secure boot, l’authentification, la sécurisation des échanges et des données, la fabrication des produits, …), mais présente aussi un intérêt particulier pour les concepteurs et développeurs de logiciels embarqués, au travers des parties 4-1 et 4-2. Celles-ci définissent un cadre pour la cybersécurité et la défense en profondeur des systèmes industriels, au travers d’une liste de méthodologies de développement et de tests à mettre en œuvre par les équipes logicielles.
La gestion et la traçabilité des exigences, clef de voûte de la cybersécurité
Le développement d’un produit secure-by-design implique de facto une réflexion en amont des problématiques de cybersécurité. La rédaction d’exigences de cybersécurité devient donc indispensable, tout comme la gestion de leur traçabilité au sein de l’ensemble du cycle de vie produit.
Dans ses « Software Development Security Assessment », l’IEC 62443-4-2 demande la mise en place d’une spécification des exigences de cybersécurité, suffisamment détaillée pour s'assurer que la conception puis l'implémentation permettront d'atteindre le niveau d'intégrité requis et d’évaluer la cybersécurité.
Pour cela, il est indiqué que « les exigences de cybersécurité doivent être écrites dans le but d'assurer leur clarté et précision, d’éviter toute ambiguïté et d’être vérifiables par le test ».
L’utilisation d’un outil de gestion des exigences comme Visure Requirements permettant non seulement de gérer les exigences sur l’ensemble d’un cycle de vie produit, de vérifier leur traçabilité, mais aussi de mesurer la qualité de rédaction d’une exigence par la détection d’exigences ambigües, vagues, contradictoires, ayant une double négation, …, facilite grandement cette tâche.
Dans ses « Software Development Security Assessment », l’IEC 62443-4-2 demande la mise en place d’une spécification des exigences de cybersécurité, suffisamment détaillée pour s'assurer que la conception puis l'implémentation permettront d'atteindre le niveau d'intégrité requis et d’évaluer la cybersécurité.
Pour cela, il est indiqué que « les exigences de cybersécurité doivent être écrites dans le but d'assurer leur clarté et précision, d’éviter toute ambiguïté et d’être vérifiables par le test ».
L’utilisation d’un outil de gestion des exigences comme Visure Requirements permettant non seulement de gérer les exigences sur l’ensemble d’un cycle de vie produit, de vérifier leur traçabilité, mais aussi de mesurer la qualité de rédaction d’une exigence par la détection d’exigences ambigües, vagues, contradictoires, ayant une double négation, …, facilite grandement cette tâche.
Les tests dynamiques dans l’IEC 62443
Les techniques de tests logiciels suggérées par l’IEC 62443 sont en partie tirées du livre 3 de la norme de sûreté de fonctionnement des systèmes industriels IEC 61508. En effet, de nombreuses failles logicielles de cybersécurité peuvent être évitées par les bonnes pratiques d’Assurance Qualité Logiciel en vigueur dans les secteurs d’activités développant du code critique.
C’est donc tout naturellement que nous retrouvons au sein de l’IEC 62443 les techniques de tests unitaires et modulaires, la création de cas de tests suivants les classes d’équivalence ou l’analyse des valeurs aux bornes, la mesure de la couverture de code (préconisée à un minimum de 90% de couverture des instructions et des branches pour les Security Level de 2 ou plus), ainsi que les fuzz testing, c’est-à-dire la réalisation de tests aléatoires sur tous les modules récupérant des données externes.
Pour ce faire, l’IEC 62443 recommande la mise en place d’outils automatisant la génération des harnais de test et des cas de tests aléatoires, ainsi que de la mesure de la couverture de code, comme le permettent les outils TBrun et TBeXtreme de la suite d’outils LDRA.
C’est donc tout naturellement que nous retrouvons au sein de l’IEC 62443 les techniques de tests unitaires et modulaires, la création de cas de tests suivants les classes d’équivalence ou l’analyse des valeurs aux bornes, la mesure de la couverture de code (préconisée à un minimum de 90% de couverture des instructions et des branches pour les Security Level de 2 ou plus), ainsi que les fuzz testing, c’est-à-dire la réalisation de tests aléatoires sur tous les modules récupérant des données externes.
Pour ce faire, l’IEC 62443 recommande la mise en place d’outils automatisant la génération des harnais de test et des cas de tests aléatoires, ainsi que de la mesure de la couverture de code, comme le permettent les outils TBrun et TBeXtreme de la suite d’outils LDRA.
Le rôle de l'analyse statique dans le cycle de vie d’un développement secure-by-design
L’IEC 62443 fait spécifiquement référence à l'analyse statique en tant que pratique recommandée en phase de codage et pour l’analyse de code tiers. En effet, elle permet de repérer au plus tôt dans le cycle de développement des erreurs de codage pouvant créer des failles de cybersécurité.
Contrairement aux tests dynamiques, pouvant rapidement devenir pénalisants d’un point de vue temps et donc coût, l'analyse statique est particulièrement adaptée à l'analyse de grandes bases de code et à la détection d'erreurs et d'avertissements significatifs qui indiquent à la fois des problèmes de sécurité et de qualité :
Les outils d’analyse statique comme CodeSonar Source (analyse statique avancée de code source, détection de bugs, d’erreurs runtime et d’injection de commandes, analyse de tainted data) ainsi que LDRA TBvision Statique (règles de codage de sûreté et cybersécurité et métriques de qualité logiciel) automatisent ces vérifications au sein de code C, C++ et Java, représentant un gain de temps notable dans la détection de failles de cybersécurité. Enfin, l’outil CodeSonar Binary permet, quant à lui, la détection des vulnérabilités logicielles et des injections de commande directement au sein d’un binaire x86, x64 ou ARM, sans nécessité de disposer de son code source.
Contrairement aux tests dynamiques, pouvant rapidement devenir pénalisants d’un point de vue temps et donc coût, l'analyse statique est particulièrement adaptée à l'analyse de grandes bases de code et à la détection d'erreurs et d'avertissements significatifs qui indiquent à la fois des problèmes de sécurité et de qualité :
- Règles de codage de cybersécurité : plusieurs standards existent, comme le CERT, spécifiquement destiné à la cybersécurité des langages C, C++ et Java, l’ISO C Secure, standard plus concis pour le langage C et conçu par le groupe chargé de la normalisation du langage C, ainsi que le MISRA C et C++, qui adresse conjointement les problématiques de sûreté et de cybersécurité. Ces normes de codage permettent d’homogénéiser les codes sources par l’application de bonnes pratiques de codage, et donc d’augmenter la robustesse et la cybersécurité du code ;
- Analyse et détection de tainted data (données corrompues) : de nombreux programmes utilisent des données provenant de l’extérieur de l’application (lecture de fichiers ou de bases de données, trames réseaux, variables d’environnements, …) dont la pertinence et la cybersécurité n’est pas assurée. Toute entrée de données constitue une faille de sécurité potentielle si elle n’est pas vérifiée ;
- Détection d’erreurs « Runtime » : selon le CWE, outre les injections de commandes, la vulnérabilité logicielle la plus utilisée pour prendre le contrôle d’un dispositif est… le dépassement de tableau ! Les erreurs « runtime », détectables par les outils d’analyse statique avancée, sont toujours des portes d’entrées de premier choix pour les attaquants ;
- Injections de commandes et SQL : souvent réalisées par des développeurs internes, plusieurs tentatives (dont certaines se sont avérées fructueuses) d’ajout de backdoors ou d’injections de commandes au sein des codes open sources sont connues. Par nature, les logiciels propriétaires sont encore plus vulnérables à ce type de failles, et l’analyse statique constitue un tiers de confiance très efficace pour les détecter ;
- Évaluation de code tiers : l’intégration d’un projet tiers ou d’une librairie, qu’elle soit open source ou commerciale, est toujours un risque supplémentaire en termes de cybersécurité, dans la mesure où vous n’avez pas connaissance des choix d’architecture et d’implémentation effectués. Le risque d’erreurs de codage involontaires (erreurs runtime) voire volontaires (backdoor, injection de commande) n’est jamais nul. Dans ce cadre, l’analyse statique permet, à moindre frais, d’obtenir un état du logiciel tiers, que l’on ait accès au code source (analyse statique du code source) ou non (analyse statique du binaire) !
Les outils d’analyse statique comme CodeSonar Source (analyse statique avancée de code source, détection de bugs, d’erreurs runtime et d’injection de commandes, analyse de tainted data) ainsi que LDRA TBvision Statique (règles de codage de sûreté et cybersécurité et métriques de qualité logiciel) automatisent ces vérifications au sein de code C, C++ et Java, représentant un gain de temps notable dans la détection de failles de cybersécurité. Enfin, l’outil CodeSonar Binary permet, quant à lui, la détection des vulnérabilités logicielles et des injections de commande directement au sein d’un binaire x86, x64 ou ARM, sans nécessité de disposer de son code source.
Contactez-nous pour plus d'informations.
