NI LabVIEW et le développement sécurisé dans un SDLC : Framework

​Un cycle de développement logiciel (SDLC) est une méthodologie formelle ou informelle de conception, de création et de maintenance de logiciels (y compris le code intégré au matériel).

​Chaque équipe logicielle a déjà un processus de développement, qu'il soit officiellement documenté ou non. Le développement sécurisé intentionnel ajoute des activités tout au long de ce processus pour réduire les vulnérabilités, améliorer la maintenabilité et réduire le coût de correction des problèmes de sécurité. Les vulnérabilités comprennent non seulement des bugs causés par des défauts de codage, mais aussi des faiblesses causées par des paramètres de configuration de sécurité, des hypothèses de confiance incorrectes et une analyse des risques obsolète.

​Plus la sécurité est traitée tôt dans le SDLC, moins d'efforts et de coûts sont nécessaires pour atteindre le même niveau de sécurité. Ce principe, appelé décalage vers la gauche, est d'une importance cruciale quel que soit le modèle SDLC. Le principe du décalage à gauche est vrai pour tout environnement de développement, y compris LabVIEW, un environnement de développement sécurisé qui peut être utilisé pour développer des applications sécurisées. Une grande partie de la sécurité de l'application terminée dépend du SDLC adopté par l'équipe de développement.

​Remarque importante sur le SDLC et la conformité : La plupart des programmes réglementaires, comme l'European Cyber Resilience Act (CRA), la certification US Cybersecurity Maturity Model (CMMC), la certification UK Defence Cyber (DCC), et d'autres, exigent la preuve qu'un système a été conçu en suivant des pratiques sécurisées comme celles de ce SDLC, mais ces programmes requièrent bien plus qu'un simple SDLC. Pour en savoir plus, reportez-vous à la documentation de ces programmes. 

​Ce guide est fondé principalement sur les principes et les pratiques définis dans la Publication spéciale 800-218 du NIST, Secure Software Development Framework (SSDF), qui fournit un framework technologiquement neutre pour le développement de logiciels sécurisés et qui est largement reconnu comme répondant aux exigences de sécurité des logiciels du gouvernement américain. Chaque pratique SSDF a été interprétée et appliquée spécifiquement aux besoins des équipes de développement LabVIEW, l'accent étant mis sur l'implémentation pratique dans les environnements de test, de mesure, d'automatisation et d'ingénierie.  

​Les recommandations présentées dans ce document ont également été comparées à d'autres frameworks de développement sécurisés établis et aux meilleures pratiques de l'industrie, y compris JKI Security Suite et Microsoft Security Development Lifecycle (SDL), afin d'assurer la cohérence avec les approches éprouvées en matière de sécurité logicielle, de gestion des risques et de protection de la chaîne d'approvisionnement logicielle. L'objectif est de fournir aux organisations LabVIEW une feuille de route pratique pour intégrer la cybersécurité dans leurs processus de développement tout en générant les preuves et la traçabilité de plus en plus requises par les clients, les régulateurs et les programmes d'acquisition gouvernementaux.

​Le processus décrit dans le NIST 800-218 couvre ces quatre domaines du développement logiciel :

1. ​Préparer l'organisation (PO) : les organisations doivent s'assurer que leurs employés, leurs processus et leur technologie sont prêts à développer des logiciels sécurisés au niveau de l'organisation. De nombreuses organisations trouveront que certaines pratiques PO s'appliquent également à des sous-ensembles de leur développement logiciel, comme des groupes de développement individuels ou des projets.
2. ​Protéger le logiciel (PS) : les organisations doivent protéger tous les composants de leur logiciel contre l'altération et l'accès non autorisé.
3. ​Produire des logiciels bien sécurisés (PW) : les organisations devraient produire des logiciels bien sécurisés avec un minimum de vulnérabilités de sécurité dans leurs versions.
4. ​Réagir aux vulnérabilités (RV) : les organisations devraient identifier les vulnérabilités résiduelles dans leurs versions logicielles et réagir de manière appropriée pour corriger ces vulnérabilités et éviter que de telles vulnérabilités ne se reproduisent à l'avenir.

​Dans cet article, nous utilisons ces rubriques pour guider le développement d'un LabVIEW SSDF.

​Avant de commencer le développement, il est important de prendre des mesures pour aider votre équipe à adopter des principes de développement sécurisé, à suivre la formation nécessaire et à établir les processus et les outils qui soutiendront le développement sécurisé. Cette phase comprend la prise de temps pour atteindre les objectifs suivants :

• ​S'assurer que l'organisation a défini et documenté des exigences de sécurité spécifiques.
• ​Former les employés dans chaque rôle pour comprendre ces exigences.
• ​Définir les processus qui seront utilisés pour développer des logiciels sécurisés.
• ​Transférer les exigences de sécurité à tous les sous-traitants ou composants tiers (y compris open source) qui fournissent du code.
• ​Implémenter un outillage pour automatiser les contrôles de sécurité et de qualité.
• ​Protéger le code contre les compromissions extérieures.

Pour les équipes LabVIEW

​Ces exigences sont génériques pour toute équipe de développement logiciel, mais il y a certaines étapes à suivre pour les adapter aux équipes de test, et aux équipes LabVIEW.

​Relations avec l'équipe de sécurité

​De nombreuses équipes de test sont isolées de l’équipe de sécurité de leur entreprise. Coordonnez-vous avec eux pour établir une relation de confiance, afin qu'ils sachent que vous prenez la sécurité au sérieux. Rencontrez votre équipe de sécurité pour comprendre ses exigences en matière de code développé. Montrez-leur vos projets et vos zones de test, et guidez-les tout au long de vos processus. Il est utile pour eux de comprendre le fonctionnement d'un laboratoire de test et de connaître les limites auxquelles vous êtes confrontés. Vos défis seront uniques par rapport aux autres systèmes informatiques, et il est utile que l'équipe de sécurité comprenne ces différences.

​Il est également important que vous compreniez les préoccupations de l'équipe de sécurité. À mesure que vous comprenez quels programmes ils doivent respecter, vous pouvez retracer les mandats de sécurité jusqu'aux exigences et mieux répondre à l'intention du programme initial.

​Suivi des exigences et documentation

​Le suivi des exigences est une partie importante de la préparation de votre équipe à fournir du code sécurisé. Au-delà du simple stockage des exigences, un bon processus de suivi assure la traçabilité de ces exigences. Votre équipe devrait être capable de suivre une exigence tout au long du cycle de vie :

​Définition des exigences → Conception → Implémentation → Test → Correction de défauts → Publication

​Cette traçabilité devient une preuve lors des audits clients, des déclarations de sécurité (comme le CRA), des évaluations (comme le CMMC) ou des examens de la sécurité des fournisseurs.

​Problèmes GitHub + Projets + Jalons est l'approche de suivi des exigences la plus courante pour la plupart des petites équipes. D'autres options de suivi incluent GitLab (avec des niveaux gratuits et payants), Azure DevOps, JIRA et d'autres outils de développement de logiciels professionnels. Ces outils vous permettent de créer des problèmes et de les suivre jusqu'à leur résolution.

​Dans l'outil que vous avez choisi, suivez systématiquement les exigences de sécurité. Chaque exigence devrait répondre aux critères suivants :

• Identifié de manière unique par un numéro d'ID, avec une exigence par ID
• ​Catégorisé par type, comme bug fonctionnel, vulnérabilité de sécurité, problème de performances
• ​Niveau de gravité attribué qui reflète son impact, tel que critique, élevé, moyen ou faible
• ​Suivi de la découverte à la résolution

​Après avoir identifié un outil de suivi des exigences, documentez votre processus pour inclure l'utilisation de ces outils dans votre développement. Utilisez le processus pour le suivi des exigences et des problèmes tout au long du cycle de vie du système. Votre processus peut comprendre les étapes suivantes :

• Attribuer un identificateur unique à chaque exigence ; ne pas combiner les spécifications.
• ​Référencer les ID d'exigence directement dans les documents de conception.
• ​Identifier quels composants d'un diagramme d'architecture répondent à chaque exigence.
• ​Référencer les ID d'exigence dans les commentaires de code, les signets, les étiquettes et la documentation.
• ​Capturer les ID d'exigence dans les validations du dépôt.
• ​Référencer les ID d'exigence dans chaque demande d'extraction et de fusion.
• ​Lier les ID d'exigence aux tests unitaires et s'assurer que toutes les spécifications sont testées.
• ​Répertorier les ID d'exigence dans les résultats de test.
• ​Documenter les ID d'exigence dans les revues de sécurité et de code.
• ​Identifier les ID d'exigence implémentés dans la documentation de la version.
• ​Lier les vulnérabilités aux ID d'exigence affectés, lorsqu'elles sont découvertes.

​Conception pour la validation de la sécurité

​Prévoyez de rendre votre code modulaire. Cette étape est particulièrement utile dans LabVIEW, puisque vous pouvez tester des modules individuels. Au fur et à mesure que vous planifiez votre architecture modulaire, envisagez également de développer des tests unitaires. Ils améliorent la qualité de votre code et fournissent un moyen plus rapide de valider le code après avoir effectué des mises à jour, même après le déploiement du système.  

​En savoir plus sur l'utilisation de NI Unit Test Framework

​Les outils de test de tiers apportent une valeur ajoutée ; par exemple, les produits Caraya et LUnit de JKI étendent les tests logiciels pour les équipes LabVIEW.

​Tiers et sous-traitants

​Définir un processus pour vérifier et approuver le travail sous-traité, les logiciels de tiers et les composants open source. Votre processus devrait inclure la vérification des bases de données publiques telles que Common Vulnerabilities and Exposures (CVE) pour identifier les vulnérabilités connues dans les composants que vous utilisez.

​Si vous utilisez des composants open source, vous devez analyser les vulnérabilités avant d'utiliser le code dans votre application.

​Formation basée sur les rôles

​Définissez des rôles spécifiques dans votre équipe, y compris des rôles spécifiques à la sécurité. Identifiez les responsabilités et l'accès de chacun de ces rôles. Au minimum, définissez des rôles à accès privilégié (admins) distincts des rôles utilisateur (développeurs et opérateurs).

​Créez une formation de sécurité applicable à ces rôles. Assignez la formation aux membres de l'équipe et suivez la formation. Ces dossiers seront utilisés comme preuves dans le cadre d'un examen de certification.

​Envisagez d'utiliser la formation de sécurité NI disponible en ligne : Cours Considérations de sécurité pour les intégrations de systèmes de test.

​Les programmes de certification de l'industrie tels qu'ISC2 fournissent des certifications de niveau introduction peu coûteuses. L'intérêt de ces programmes pour une équipe de test est de fournir un langage commun pour communiquer avec les équipes de sécurité.

​Soutien au leadership

​Une fois que vous avez défini votre SDLC, présentez-le aux dirigeants de l'entreprise et obtenez leur soutien formel. Il devrait être approuvé au moins par le niveau qui approuve le budget de la sécurité, afin de démontrer son engagement envers le programme.

​Gestion des données et étiquettes

​En tant qu'organisation, identifiez les types de données que vous pourriez rencontrer et créez un système d'étiquetage. Vous devriez considérer les types de données suivants :

• ​Données classifiées ou sensibles, si votre organisation est qualifiée pour gérer ce niveau de données.
• ​Informations non classifiées contrôlées (CUI) : ces informations ne sont pas classifiées mais doivent être protégées par la réglementation.
• ​Informations techniques ITAR : ces informations requièrent un traitement particulier pour garantir qu'aucune exportation des informations ne se fasse sans licence.
• ​Données relatives aux réglementations sur l'administration des exportations (EAR), renseignements contrôlés à l'exportation, NOFORN et autres renseignements restreints à l'exportation : ces renseignements nécessitent des contrôles pour empêcher l'accès des étrangers non autorisés conformément aux réglementations applicables en matière d'exportation.
• ​Informations protégées par la société : ces informations comprennent des informations exclusives ou confidentielles qui pourraient nuire à la société si elles étaient rendues publiques.
• ​Informations personnelles identifiables (PII) : ces données sont protégées dans certains pays et territoires et doivent l'être de manière spécifique.
• ​Données publiques : il se peut que vous ayez des données qui sont librement accessibles au public.

​Disposer d'un système clair de gestion et d'étiquetage des données vous permettra de protéger les données de manière appropriée, en appliquant les restrictions appropriées à chaque classification de données. Définir cela comme une organisation avant de commencer le développement de votre système vous fera gagner du temps en appliquant les bons contrôles aux bonnes zones à risque. Le mappage dans les systèmes d'étiquetage existants de l'entreprise et des TI simplifiera la manière dont les systèmes partagent les données entre eux.

​Outils de développement et de sécurité

​Identifiez les versions et configurations des logiciels et des drivers que vous normaliserez pour la sécurité. Pour LabVIEW, identifiez la version que vous allez utiliser pour le développement. Établissez une configuration sécurisée pour vos installations. Vous pouvez suivre le Guide de configuration sécurisée LabVIEW. Vous trouverez d'autres guides de configuration sécurisés sur ni.com/security.

​Pour l'auditabilité et la mise en place rapide de nouveaux systèmes, automatisez la configuration des machines de développement et de construction. Établissez une installation de base et créez une image à partir de cette installation.

​Établissez des outils à utiliser pour les vérifications de sécurité tout au long de votre développement. Vous aurez besoin d'un outil de test de sécurité d'application statique (SAST) pour analyser votre code source sans exécuter le programme afin de trouver des vulnérabilités de sécurité potentielles. Pour le code graphique LabVIEW, nous recommandons la JKI Security Suite, conçue spécifiquement pour fournir une analyse statique du code LabVIEW. Vous pouvez aussi effectuer une analyse manuelle du code statique en recherchant des problèmes de sécurité.

​Les outils SAST sont un outil de sécurité important pour analyser le code à la recherche de vulnérabilités. Les outils de test dynamique de sécurité des applications (DAST) sont également importants et sont utilisés pour analyser le code en cours d'exécution pendant les tests. L'analyse de composition logicielle (SCA) identifie l'utilisation de bibliothèques open source, de paquets de tiers et de composants logiciels et recherche les vulnérabilités connues et les problèmes de licence avec ces composants.

​Il existe de nombreux autres types d'outils utilisés pour rechercher des problèmes de sécurité dans le code. L'outil approprié pour votre projet dépend de votre jeu d'outils, de la nature de votre projet et des types de code que vous utilisez. Au cours de cette phase du cycle de développement sécurisé, il est important de rechercher et d'identifier les outils que votre équipe utilisera.

​Dépôt du code

​Le développement sécurisé nécessite que le code source soit stocké, avec plusieurs versions afin que les équipes puissent revenir aux versions précédentes au cas où quelque chose briserait le code. Dans le cadre de la préparation de l'organisation au développement sécurisé, établir un dépôt de code qui stocke le code, obtient le code pour le développement et maintient le contrôle de version du code source.

​La création de branches dans le dépôt de code facilite le développement parallèle et les versions stables. Définissez les types de branches que vous utiliserez dans votre organisation. Ces types de branche sont standard, mais peuvent être adaptés à vos besoins :

• ​Branche de production : la branche stable principale avec du code prêt pour la production.
• ​Branche de publication : gérer des versions de publication spécifiques, en permettant l'application de correctifs et de correctifs urgents aux versions antérieures tandis que le nouveau développement se poursuit sur la branche principale.
• ​Branche de fonctionnalité : branche temporaire utilisée pour développer de nouvelles fonctionnalités, corriger des bugs ou expérimenter.
• ​Branche de développement : branche destinée à intégrer de nouvelles fonctionnalités avant leur fusion dans la branche de production. Cette branche peut inclure des fonctionnalités en cours et est un point d'intégration pour plusieurs branches de fonctionnalités.

​Utilisez un dépôt qui fournit des contrôles de sécurité appropriés. Assurez-vous que le dépôt conserve un historique complet des fichiers de validation et des changements pour la traçabilité.

​Sécurité des ordinateurs de développement

​Assurez-vous que les ordinateurs utilisés pour développer du code suivent les règles de cybersécurité de base. Ces contrôles de base incluent la protection par mot de passe, la protection contre les codes malveillants et d'autres mesures de cyberhygiène de base. À titre d'exemple de ces contrôles de base, reportez-vous à https://www.acquisition.gov/far/52.204-21.

​Pour la traçabilité, capturez les paramètres de configuration de l'ordinateur utilisé pour développer le système. Les paramètres de configuration à capturer comprennent les exemples suivants :

• Version(s) et architecture du système d'exploitation (par exemple, Windows 10 x64)
• ​Version de LabVIEW (par exemple, LabVIEW 2023 Q3) et architecture (32 bits/64 bits)
• ​Versions des drivers NI (par exemple, NI-DAQmx 23.8, NI-VISA 23.5)
• ​Versions spécifiques des modules complémentaires NI (par exemple, LabVIEW Real-Time Module ou LabVIEW FPGA Module)
• ​Configurations des flux du Gestionnaire de paquets NI et versions clés des paquets
• ​Version du Gestionnaire de paquets de VI NI (VIPM) et fichier VIPC (liste des paquets de VI et versions requis)
• ​Versions de drivers de tiers requises
• ​Versions du moteur d'exécution requises pour le déploiement

​Preuves de sécurité

​La plupart des programmes de sécurité exigeront des preuves que votre équipe a suivi les pratiques établies dans le cadre du SSDF. Établir un dépôt pour suivre les preuves et les tenir à jour tout au long du développement et du déploiement du système. Le système devrait suivre les éléments suivants :

• Dossiers de formation
• ​Modèles de menaces
• ​Évaluations des risques
• ​Enregistrements de revue de code
• ​Résultats du test
• ​SBOM
• ​Résultats du balayage de sécurité
• ​Approbations de publication
• ​Enregistrements des correctifs

​De nombreuses équipes effectuent ces activités de sécurité mais ne peuvent pas prouver qu'elles les ont effectuées. Les équipes de conformité voudront voir les deux : que votre équipe a des processus en place et que vous les suivez. Le regroupement de ces documents simplifiera considérablement les vérifications et les examens de conformité.

​Lorsque l'organisation est prête à développer du code en toute sécurité, la tâche suivante consiste à protéger le logiciel. Cette étape garantit que l'équipe garde le code en sécurité pendant le développement et la publication.

​Pour les équipes LabVIEW

​Protéger le logiciel pendant le processus de développement est essentiel pour tout logiciel, quel que soit le langage de programmation utilisé. Comme les équipes LabVIEW adoptent des outils de workflow professionnels pour le développement de logiciels, elles doivent également adopter des processus et des outils de développement sécurisés.

​Dépôts de code sécurisés

​Utilisez les dépôts de code sécurisés identifiés à la phase précédente pour stocker et gérer votre code. Un bon dépôt fait plus que gérer le code source. Il contient également les exigences, la documentation, les scripts de construction, les artefacts de test et les historiques de versions. Comme le dépôt contient une grande partie du code et du support, il est important d'utiliser un dépôt sécurisé : si le dépôt est compromis, votre logiciel l'est.

​Dans le dépôt, votre branche principale est une ressource critique qui doit être protégée. Votre équipe devrait définir et suivre des règles pour protéger le code. Ces stratégies peuvent inclure les exemples suivants :

• Règles de protection des branches
• ​Revues des demandes d'extraction
• ​Exigences d'approbation
• ​Test automatisé avant la fusion
• ​Validations directes restreintes

​Le dépôt devrait également fournir une traçabilité de la génération d'une exigence, en passant par le développement et la sortie du produit. Certains dépôts permettent la signature de validations (par exemple, dans Git).

​Le dépôt devrait fournir une piste d'audit en conservant un enregistrement des changements logiciels. Qu'est-ce qui a changé, qui l'a changé, pourquoi l'a-t-il changé, qui l'a approuvé et quand a-t-il été publié ? De plus, les images diffusées doivent être sauvegardées dans des archives sécurisées, de sorte que le code puisse être récupéré même si le dépôt est compromis.

​Nomenclature des logiciels (SBOM)

​Un SBOM fournit une liste des logiciels et composants utilisés dans le développement du code. Générer un SBOM dans le cadre du processus de construction garantit que vous disposez d'un journal des composants utilisés dans le code, ce qui simplifie le processus pour identifier et corriger les vulnérabilités.

​À partir de LabVIEW 2026 Q3, vous pouvez générer des SBOM dans le cadre du processus de construction de l'application. Pour en savoir plus, reportez-vous à la rubrique Génération d'une nomenclature des logiciels pour une application autonome.

​Signature de code

​La signature de code permet aux utilisateurs de vérifier que le logiciel a été produit par une organisation connue, qu'il n'a pas été modifié depuis sa sortie et qu'il a été approuvé pour la distribution. Dans une application LabVIEW, la signature de code doit être appliquée aux exécutables, installeurs, paquets de déploiement, DLL, drivers et paquets de mise à jour.

​Vous pouvez signer votre application pendant le processus de construction en suivant ces instructions. Vous pouvez aussi signer des logiciels en utilisant SignTool.exe de Microsoft, ce qui revient à signer n'importe quelle application ou fichier.

​Gestion des secrets

​Les applications requièrent fréquemment des secrets tels que des mots de passe, des clés API, des certificats, des jetons, des clés de chiffrement, des informations d'identification de base de données et de compte de service. Ces secrets donnent accès aux systèmes et aux données et doivent être protégés tout au long du cycle de vie du logiciel.

​Ne mettez jamais en dur les mots de passe, les clés API, les certificats ou les clés de chiffrement directement dans le code source, les fichiers de configuration, les scripts de construction ou les utilitaires de test. Les secrets codés en dur sont difficiles à renouveler, peuvent être copiés dans des dépôts et peuvent être exposés lors de revues de code source, de sauvegardes ou d'ingénierie inverse des applications déployées.

​Stockez les secrets en utilisant un système d'exploitation sécurisé ou un stockage protégé par le matériel dans la mesure du possible. Les options suivantes sont des exemples de stockage sécurisé ou protégé :

• ​Gestionnaire d'identifiants sous Windows
• Microsoft SecretStore
• ​Microsoft CryptProtectData (DPAPI)
• ​Modules de plate-forme de confiance (TPM)
• ​Modules matériels de sécurité (HSM)
• ​Services sécurisés de gestion de secrets dans le cloud

​Appliquer le principe du moindre privilège lors de l'accès aux secrets. Seuls les utilisateurs, les systèmes et les services qui requièrent l'accès à un secret devraient pouvoir le récupérer. Les identifiants administratifs doivent être séparés des identifiants utilisateur et les comptes partagés doivent être évités dans la mesure du possible.

​Les mots de passe, les certificats, les clés API et les clés de chiffrement doivent être remplacés périodiquement conformément à la politique organisationnelle. Établissez un processus qui définit comment les secrets sont générés, où ils sont stockés, qui peut accéder aux secrets et comment les secrets compromis sont révoqués.

​Les systèmes de test utilisent fréquemment des connexions réseau réelles, des bases de données, des services cloud et des instruments. Les équipes de test doivent avoir accès à ces systèmes pendant le test. Dans la mesure du possible, utilisez des identifiants de test dédiés plutôt que des identifiants de production. Des environnements de test distincts réduisent le risque d'exposition des systèmes opérationnels pendant les activités de développement et de validation.

​Cette phase se concentre sur la conception, l'implémentation, le test et la validation de logiciels en toute sécurité. Pour effectuer cette tâche efficacement, une équipe doit évaluer les risques et les exigences liés à l'utilisation prévue du logiciel et concevoir le logiciel en fonction de ces risques. Les meilleures pratiques incluent la réutilisation des composants sécurisés connus dans la mesure du possible, le test pendant le développement et la recherche de vulnérabilités dans le code de développement. Les équipes planifient une utilisation sécurisée, notamment en utilisant des paramètres sécurisés par défaut.

​Pour les équipes LabVIEW

​Les applications de test et de mesure sont confrontées à des défis de sécurité différents des applications logicielles générales. Les équipes LabVIEW sont en mesure de comprendre ces défis et de développer des logiciels qui protégeront contre les attaques ciblées sur leurs applications. LabVIEW fournit un certain nombre de protections de sécurité inhérentes, mais les équipes doivent tenir compte des attaques possibles et préparer une défense contre celles-ci.

​Modélisation des menaces et évaluation des risques

​OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif qui fournit des outils gratuits, des guides et des normes pour aider les gens à construire des logiciels sécurisés. OWASP fournit un guide communautaire de modélisation des menaces ; son modèle propose une série structurée d'étapes pour délimiter votre travail, déterminer les menaces, déterminer les contre-mesures et les mesures d'atténuation, et évaluer votre travail.

​Pour les équipes de test, cela commence par une conversation pour comprendre l'utilisation prévue et les menaces pour le système en cours de développement. La conversation devrait inclure le développeur principal, l'architecte de test, l'ingénieur système, le propriétaire du produit, le représentant de la cybersécurité et le personnel des opérations.

​L'approche OWASP comprend une liste de menaces comprenant la mystification, l'altération, la répudiation, la divulgation d'informations, le déni de service et l'élévation de privilège (STRIDE). Les catégories de menaces STRIDE aident une équipe à prendre en compte tous les types de menaces.

​Les équipes de test devraient tirer parti de leur expérience dans les sessions de brainstorming pour examiner spécifiquement comment les menaces affecteront leurs systèmes dans un environnement de test :

• Qu'est-ce qui pourrait causer une perte de résultats de test et comment se remettrait-on de ce genre de perte ?
• ​Comment quelqu'un pourrait-il corrompre l'étalonnage du système pour que celui-ci génère de mauvaises données ?
• ​Quelqu'un peut-il prendre le contrôle non autorisé d'un des instruments ou périphériques du système ?
• ​Comment un attaquant peut-il causer un arrêt de production via notre système ?

​L'ajout de ces risques spécifiques aux tests aux cybermenaces plus traditionnelles aidera à identifier les stratégies de défense appropriées pour le système de test. La modélisation des menaces devrait produire un ensemble de risques prioritaires et les exigences de sécurité nécessaires pour les atténuer. Ces exigences deviennent des entrées pour les activités de conception et de développement de systèmes décrites dans la section suivante. Les examens périodiques des menaces peuvent aider les équipes à identifier les menaces nouvelles et émergentes au fil du temps et peuvent inclure un examen des problèmes que les menaces précédentes n'avaient pas pris en compte.

​Développement des exigences de sécurité

​La modélisation des menaces identifie les risques pour le système. L'étape suivante consiste à convertir ces risques en exigences de sécurité mesurables qui peuvent être implémentées, testées et suivies tout au long du cycle de vie. Les exigences de sécurité doivent être traitées avec le même niveau de rigueur que les exigences fonctionnelles.

​Une exigence de sécurité définit un contrôle ou un comportement de sécurité que le système doit fournir. Les bonnes exigences de sécurité sont spécifiques, mesurables, testables et traçables. Le tableau suivant montre quelques exemples.

​Les exigences de sécurité doivent être assignées à des identificateurs uniques et faire l'objet d'un suivi au moyen des mêmes outils de gestion des exigences que ceux utilisés pour les exigences fonctionnelles.

​Une exigence de sécurité bien définie doit pouvoir être suivie tout au long du cycle de développement. La traçabilité démontre que les risques identifiés ont été traités et fournit des preuves précieuses lors des audits clients, des évaluations de la sécurité des fournisseurs et des examens réglementaires.

​Les systèmes de test et de mesure ont des exigences de sécurité qui sont souvent négligées dans les projets logiciels d'entreprise. Au fur et à mesure que vous développez des exigences de sécurité, utilisez des catégories de sécurité standard, mais tenez également compte des données suivantes :

• Protection des résultats de test contre toute modification non autorisée
• ​Protection des données d'étalonnage et des procédures d'étalonnage
• ​Protection des configurations d'instruments
• ​Gestion sécurisée des sorties matérielles en cas d'arrêt ou de défaillance
• ​Accès contrôlé à l'édition de séquence et aux modifications de limite de test
• ​Protection des bases de données de production et des dossiers de fabrication
• ​Validation des données reçues d'instruments, de périphériques et d'interfaces réseau externes

​Comme des mesures inexactes et des résultats de test corrompus peuvent avoir des conséquences commerciales importantes, les exigences de sécurité en matière d'intégrité sont souvent aussi importantes que les exigences de confidentialité.

​Construire du code modulaire

​Le code modulaire limite l'impact des défauts et vulnérabilités en isolant les fonctionnalités dans des composants bien définis avec des interfaces contrôlées. Dans une bonne conception modulaire, chaque module n'expose que les fonctions dont les autres modules ont besoin. Cette approche réduit le nombre de points d'entrée et les possibilités d'utilisation abusive. Le code modulaire a aussi l'avantage d'être plus facile à tester, donc il est plus facile d'appliquer et de valider les mises à jour du code.

​Lorsque vous construisez du code modulaire, considérez le principe du moindre privilège. Un module ne devrait avoir que les autorisations requises pour remplir sa fonction. Par exemple, une fonction de communication d'instruments n'a pas besoin d'accéder à une base de données car elle est gérée par un autre module. Évitez de transmettre le descripteur de base de données au module de communication avec l'instrument.

​Au fur et à mesure que les données sont transmises entre les modules, évaluez la confiance de la communication. Le cas échéant, validez la source avant d'accepter des données d'un autre composant.

​Le code modulaire devrait faciliter les examens de sécurité. Chaque module peut être revu, plutôt que de revoir l'ensemble du code à chaque révision. Le réviseur de code n'a pas besoin de comprendre l'ensemble du code pour contribuer à la sécurité d'un seul composant.

​Les modules de code simplifient aussi la réutilisation du code. Un module qui a été développé en toute sécurité et testé peut être réutilisé dans d'autres applications avec la certitude qu'il fonctionne comme prévu.

​Meilleures pratiques LabVIEW

​Établir un ensemble de pratiques exemplaires et les suivre. Vos révisions de code devraient vérifier la conformité à ces pratiques. Bien qu'un examen complet des meilleures pratiques dépasse le cadre du présent document, celles-ci devraient inclure au moins les éléments suivants :

• ​Conditions de concurrence : les conditions de concurrence surviennent lorsque plusieurs chemins d'exécution accèdent à des ressources partagées sans synchronisation appropriée, ce qui conduit à un comportement imprévisible en fonction des variations de cadence. Le code doit être conçu pour s'exécuter de manière prévisible quels que soient la disponibilité et le cadencement des ressources système. Les ressources et variables globales doivent être utilisées avec prudence pour éviter ces conditions. L'accès asynchrone aux ressources partagées requiert des primitives de synchronisation appropriées (notificateurs, occurrences, files d'attente) pour garantir des opérations thread-safe.
• ​Limitation des ressources : une consommation incontrôlée de ressources peut entraîner des blocages logiciels, des plantages du système et une dégradation des performances qui compromet à la fois la sécurité et la fiabilité opérationnelle. Le modèle d'exécution parallèle LabVIEW et la gestion automatique de la mémoire peuvent masquer l'épuisement des ressources jusqu'à ce que les seuils critiques soient dépassés, ce qui rend la limitation proactive essentielle pour maintenir la stabilité du système. Implémentez des mécanismes de limitation spécifiques pour éviter les attaques d'épuisement des ressources et garantir un comportement prévisible du système dans des conditions de charge variables. Les éléments spécifiques à rechercher incluent la protection contre la croissance des tableaux, le contrôle de la fréquence de boucle, la prévention de boucle infinie, les lacunes de connexion réseau, la surveillance de l'utilisation de la mémoire, les opérations sur fichiers, la réactivité de l'IU et les limites de profondeur de file d'attente.
• ​Observabilité : l'observabilité est la capacité de déterminer l'état interne, le comportement et la sécurité d'un système à partir de ses sorties, telles que les journaux, les événements, les statistiques, les alarmes et les enregistrements d'audit. Pour améliorer l'observabilité d'une application, il faut concevoir le système de manière à ce qu'il le fournisse sans exposer d'informations sensibles.
• ​Gestion de la mémoire de base : LabVIEW gère automatiquement la plupart des opérations de gestion de la mémoire. Les développeurs doivent gérer certaines fonctions de mémoire. Pour les boucles critiques aux performances, préallouez de la mémoire pour les tableaux et les structures de données. Passez en revue les paramètres d'exécution du VI pour configurer correctement la réentrance et d'autres paramètres. Fermer explicitement les références de valeurs de données et autres références lorsqu'elles ne sont plus nécessaires. Évitez d'allouer de la mémoire sans limites, comme construire un tableau à l'intérieur d'une boucle sans limites.
• ​Ségrégation et encapsulation des données : concevez des composants avec des interfaces publiques bien définies qui n'exposent que les fonctionnalités minimales requises par les clients. Utilisez une étendue privée pour les données internes avec des méthodes pour forcer l'encapsulation. Les données de classe LabVIEW sont privées ; ne créez pas d'accès directs pour les données qui doivent rester privées. Séparez les fonctionnalités en fonction des responsabilités logiques et contrôlez les niveaux d'accès le cas échéant.
• ​Validation en entrée : validez strictement toutes les données en entrée, en particulier celles provenant de sources externes ou d'utilisateurs, pour garantir la robustesse et l'intégrité du système. La validation d'entrée est un contrôle de sécurité critique qui empêche les données mal formées de compromettre le fonctionnement du système ou de permettre des attaques, protégeant ainsi l'intégrité des données tout au long du traitement.
• ​Gestion d'entiers : sélectionnez des types d'entiers suffisamment grands pour le fonctionnement prévu et la croissance future. LabVIEW propose plusieurs types de données entiers (par exemple, I8, U64) avec des plages et des comportements de débordement différents. Choisissez des types d'entiers en fonction de la valeur maximale attendue et d'une marge de sécurité, pas seulement de la gamme de fonctionnement typique. Passez explicitement en revue les compteurs, les temporisateurs et les accumulateurs pour détecter les conditions de débordement et tester les cas limites.
• ​Interfaces matérielles : fermer, déverrouiller, libérer ou déconnecter des ressources matérielles ou des connexions (par exemple, des tâches DAQmx, des sessions VISA, des références de fichiers) lorsqu'elles ne sont plus activement requises. Configurez les sorties matérielles pour passer à un état connu et sûr à l'arrêt de l'application ou dans des conditions d'erreur.
• ​Gestion des erreurs : implémentez une gestion des erreurs complète conçue pour détecter, gérer et rapporter les défaillances attendues et inattendues. Le cluster d'erreur intégré à LabVIEW facilite cela. Utilisez les fonctions d'erreur pour fusionner les informations sur les erreurs afin de conserver l'erreur d'origine et les erreurs suivantes dans un chemin.
• ​Conception à sûreté intégrée : concevoir des systèmes pour gérer les défaillances de manière sûre, en passant à un état sûr. Cela inclut la conception de l'interface pour qu'elle soit sûre, la validation de toutes les entrées de données, la communication claire de l'état des connexions critiques à l'utilisateur, la définition de procédures pour définir les sorties du matériel à un état sûr connu (par exemple, hors tension ou déconnecté) en cas d'erreur ou d'arrêt. Cela garantit une déconnexion correcte des interfaces matérielles, la mise en œuvre de mécanismes pour vider les tampons de données critiques sur disque en cas d'erreur ou d'arrêt, la fermeture correcte des références de fichiers et la déconnexion du matériel d'acquisition de données et d'autres instruments.
• ​Sécurité du VI Serveur : lorsque vous utilisez le VI Serveur LabVIEW pour le contrôle à distance ou la communication, configurez les paramètres pour limiter la surface d'attaque potentielle et implémentez une identification utilisateur et une gestion des informations d'identification appropriées.
• ​Risques liés à l'exécutable INI VI Serveur : les exécutables construits avec LabVIEW génèrent un fichier INI qui contrôle les autorisations d'exécution, y compris l'accès au VI Serveur. Par exemple, my-app.exe génère my-app.ini dans le même répertoire. Avec de simples modifications de texte et une connaissance de la structure de l'application, les attaquants externes peuvent obtenir un accès non autorisé aux commandes de la face-avant de l'application et potentiellement exécuter des VIs arbitraires. Pour vous en protéger, gérez soigneusement l'emplacement des fichiers et les autorisations de l'application déployée.
• ​Durcissement de la production : les déploiements en production doivent supprimer les artefacts de développement et les capacités de mise au point qui pourraient exposer des informations sensibles ou fournir des chemins d'accès non autorisés. L'environnement de développement visuel LabVIEW facilite l'inclusion par inadvertance de VIs de mise au point, de données de test et d'informations de diagnostic dans les versions de production. Le code stocké dans des dépôts peut aussi être inclus par inadvertance. Supprimez les VIs de mise au point et de test, désactivez la mise au point dans les spécifications de construction de projet, effacez les valeurs par défaut sensibles, supprimez les informations d'identification de test codées en dur et désinfectez les constantes du diagramme pour supprimer les chemins de développement, les noms de serveurs ou d'autres informations, et validez que la gestion des erreurs fonctionne correctement.
• ​Test unitaire : le test unitaire automatisé est fondamental pour vérifier la logique de base, la gestion des données, les interfaces et la gestion des erreurs. Il fournit l'assurance que les composants répondent aux exigences et conservent leur comportement au fur et à mesure que la base de code évolue. Les développeurs devraient créer des tests unitaires en même temps que du code nouveau ou modifié pour soutenir les évaluations continues de la sécurité et du contrôle de la confidentialité tout au long du cycle de développement. Les tests unitaires mettent en œuvre l'évaluation continue de la sécurité, la détection des défaillances et les processus de correction requis par les programmes de conformité, fournissant des preuves de l'exécution des tests et des résultats pour la validation des contrôles de sécurité.

​Utilisez un framework de test unitaire LabVIEW reconnu (NI Unit Test Framework, JKI Caraya ou LUnit). Ces outils permettent aux développeurs de définir les entrées et les sorties et de valider que le code fonctionne correctement. Ceci peut se faire sans exécuter toute l'application, ce qui simplifie la validation du code.

Les tests unitaires protègent les fonctions sensibles, comme le contrôle d'équipements coûteux, car les modules peuvent être testés isolément. Les tests unitaires doivent être conçus pour une exécution reproductible et idéalement intégrés dans un système d'intégration continue (CI) afin de garantir qu'ils s'exécutent automatiquement en cas de changement de code.

​Revues de sécurité

​Les revues de sécurité fréquentes constituent un élément important de l'établissement d'une culture de développement axée sur la sécurité. Les revues permettent aux équipes d'établir des pratiques sécurisées, d'apprendre les unes des autres et de renforcer les processus sécurisés. Les revues de sécurité commencent avant le développement, passant en revue l'architecture et les méthodes prévues. Les revues devraient ensuite se poursuivre tout au long du processus de développement pour s'assurer que le code est développé de manière sécurisée. La fréquence devrait être fonction de la taille du développement ; les revues devraient avoir lieu suffisamment fréquemment pour que les problèmes puissent être corrigés avant qu'un développement important en aval ne se produise. Des revues devraient avoir lieu à chaque requête de fusion, demande d'extraction ou autre événement d'intégration de code important. Des revues planifiées supplémentaires peuvent être appropriées pour les grands projets.

​Les revues de sécurité sont considérablement améliorées lorsqu'une équipe les effectue à partir d'une liste de vérification. Ces listes de vérification devraient être établies par l'organisation et personnalisées au début de chaque projet en fonction de l'analyse des menaces et des risques.

​En plus des revues manuelles du code, effectuez des revues automatisées du code. Si vous utilisez un processus d'intégration continue et de livraison/déploiement continu (CI/CD), ajoutez un balayage de sécurité à votre processus d'admission afin que le code soit scanné à chaque enregistrement de code. Configurez des outils de balayage supplémentaires à exécuter quotidiennement ou hebdomadairement pour détecter les failles de sécurité qui viennent d'être introduites avant qu'elles ne deviennent une partie permanente du code. Utilisez des analyses statiques, des tests unitaires et d'autres outils de balayage de sécurité pour inclure une variété de types de revue.

​Outils de développement

​Dans la mesure du possible, utilisez la dernière version des drivers de logiciels de développement. De nouvelles menaces de sécurité sont identifiées presque quotidiennement, et les développeurs intègrent des correctifs de sécurité dans les correctifs et les nouvelles versions des logiciels. Si vous ne pouvez pas utiliser la dernière version, utilisez des logiciels qui reçoivent encore des mises à jour de sécurité du fournisseur et qui les recevront pendant toute la durée du système.  

​Configurez vos outils pour la sécurité à l'aide des guides de configuration fournis par le fournisseur.

​Consultez la liste des versions de logiciels supportées pour les produits NI

​Trouvez des guides pour les produits NI  

​Test

​Avant de lancer le produit, effectuez des tests en fonction des menaces et des risques identifiés au début du projet. Cette liste peut inclure les tests suivants :

• ​Test dynamique : pendant l'exécution de l'application, testez l'intégralité du logiciel. Les tests dynamiques recherchent les échecs d'authentification, les défauts d'autorisation, les vulnérabilités d'injection, les mauvaises configurations et d'autres façons de planter le programme.
• ​Test par fuzzing : ce test envoie des données inattendues ou mal formées au logiciel. Par exemple, au lieu de définir un point de contrôle à 25 degrés, l'entrée peut être alimentée avec des valeurs comme AAAAAAA... Ou NULL. Ce test est particulièrement utile dans les applications LabVIEW qui communiquent avec des instruments ou des protocoles réseau, pour voir si les entrées provoquent un plantage ou un mauvais comportement de l'instrument.
• ​Test de pénétration : ce test peut être effectué par une équipe interne ou un consultant externe. Dans ce test, un expert tente d'obtenir un accès non autorisé, d'augmenter les privilèges, d'accéder à des données sensibles ou de contourner les contrôles en utilisant l'application. Ces tests sont généralement effectués avant une version majeure ou annuellement, selon le profil de risque du système.

​Comme LabVIEW est un langage de programmation graphique, certains outils de sécurité traditionnels ne peuvent pas tester le code LabVIEW. Les outils tels que JKI Security Suite fournissent des capacités d'analyse statique axées sur la sécurité conçues pour les développeurs LabVIEW, capables de balayer le code LabVIEW et adaptées aux problèmes de sécurité spécifiques d'un langage de programmation graphique.  

​En savoir plus sur JKI Security Suite

​Critères de publication

​Une version ne peut être approuvée que si l'équipe de développement peut démontrer que le modèle de menace a été revu, que les vulnérabilités critiques ont été corrigées, que les tests unitaires ont été appliqués et réussis, que l'analyse statique a été effectuée, qu'un SBOM a été généré, que le code a été revu et que la version a été signée. L'application d'un processus formel de validation de publication permet à la direction de vérifier que les processus ont été suivis et que le logiciel est sécurisé.

​Déploiement et installation sécurisés

​Le développement de logiciels sécurisés n'est qu'une partie du processus. Une application sécurisée peut devenir vulnérable si elle n'est pas déployée correctement ou si les contrôles de sécurité sont supprimés lors de l'installation et de la configuration. Le processus de déploiement doit donc être traité comme faisant partie du cycle de développement sécurisé des logiciels, avec des procédures, des examens et des activités de validation définis avant que les logiciels ne soient mis à la disposition des utilisateurs.

​Configuration par défaut sécurisée

​Les applications doivent être déployées en utilisant des paramètres sécurisés par défaut. Les utilisateurs supposent souvent que les paramètres par défaut représentent la configuration recommandée. Toute option sensible à la sécurité désactivée par défaut peut rester désactivée pendant toute la durée de vie du système.

​Les valeurs par défaut sécurisées peuvent inclure les exemples suivants :

• ​Exiger l'authentification le cas échéant.
• ​Désactiver les ports et services réseau inutilisés.
• ​Activer les communications cryptées par défaut.
• ​Utiliser le principe du moindre privilège.
• ​Désactiver les interfaces de développement et de mise au point dans les versions de production.
• ​Restreindre l'accès aux fonctions de configuration et d'administration.

​Les utilisateurs devraient être tenus d'affaiblir consciemment les paramètres de sécurité plutôt que d'activer manuellement les protections de sécurité.

​Durcissement de la production

​Avant la sortie, supprimez les artefacts et fonctionnalités de développement qui sont utiles pendant le développement mais qui créent des risques inutiles dans les environnements de production. Examinez l'application selon les critères suivants :

• VIs de test
• ​Utilitaires de mise au point
• ​Portes dérobées de diagnostic
• ​Exemples d'identifiants
• ​Mots de passe codés en dur
• ​Noms des serveurs internes
• ​Chemins du système de fichiers
• ​Services inutilisés
• ​Certificats de développement

​Les systèmes de production ne doivent exposer que les fonctionnalités requises pour le faire fonctionner.

​Gestion des comptes et des autorisations

​Passez en revue les autorisations requises par le système et attribuez-les aux rôles appropriés. Les systèmes ne devraient pas accorder de privilèges d'administrateur, sauf s'il existe un besoin opérationnel documenté. Les comptes service ne doivent être configurés qu'avec les autorisations requises pour remplir la fonction prévue. Lorsque vous envisagez des autorisations basées sur des rôles, tenez compte de :

• Comptes administrateurs avec accès privilégié pour des rôles spécifiques
• ​Comptes de service pour la maintenance et les mises à jour
• ​Comptes de base de données pour accéder aux données
• ​Identifiants partagés pour les stations opérateur
• ​Autorisations de fichiers et de dossiers qui restreignent l'accès pour correspondre au profil de menace du système

​Si le système stocke des informations sensibles, vérifiez que les contrôles d'accès protègent ces informations de manière appropriée.

​Configuration de la sécurité réseau

​Documentez toutes les communications réseau requises avant le déploiement. Pour chaque connexion effectuée par le système, considérez :

• ​Quels protocoles utiliser pour transmettre des données
• ​Les numéros de port qui doivent être ouverts via les pare-feux
• ​La direction de chaque flux de communication
• ​Les exigences d'authentification et stockage des informations d'identification
• ​Les exigences de cryptage pour le stockage et la transmission des données
• ​La suppression ou la désactivation des chemins de communication qui ne sont pas requis

​Lorsque les données traversent les limites du réseau, elles doivent être protégées. Pour chaque transmission de données, prenez les précautions suivantes :

• Utilisez TLS ou d'autres protocoles sécurisés.
• ​Minimisez les services exposés.
• ​Limitez les connexions entrantes.
• ​Limitez les communications aux systèmes autorisés dans la mesure du possible.

​Les systèmes de test sont souvent connectés simultanément aux réseaux d'entreprise, aux réseaux de fabrication, aux services cloud et aux instruments. Comprendre et documenter ces limites de confiance est une activité de déploiement importante.

​Gestion des secrets et des informations d'identification

​Les applications requièrent souvent des mots de passe, des clés API, des certificats, des jetons ou des clés de chiffrement. Lorsque vous manipulez ces jetons secrets, veillez à ne pas :

• ​Coder en dur des informations d'identification dans le code source
• ​Stocker les mots de passe dans des fichiers de configuration texte brut
• ​Stocker les clés privées dans des emplacements non sécurisés

​Utilisez plutôt l'un des outils ou technologies suivants :

• ​Gestionnaire d'identifiants sous Windows
• ​Microsoft Secret Store
• ​CryptProtectData (DPAPI)
• ​Modules de plate-forme de confiance (TPM)
• ​Modules matériels de sécurité (HSM)

​Documentez la manière dont les secrets sont créés, stockés, renouvelés, sauvegardés et révoqués. Suivez ce processus.

​Enregistrement et audit

​Les applications doivent enregistrer les événements opérationnels et de sécurité importants. Les événements à enregistrer comprennent les exemples suivants :

• Événements d'authentification utilisateur
• ​Changements de configuration
• ​Mises à jour logicielles
• ​Opérations privilégiées
• ​Défaillances de sécurité
• ​Échecs de connexion réseau
• ​Événements de démarrage et d'arrêt

​Vérifiez que les journaux ne contiennent aucun secret, comme des mots de passe ou des informations personnelles ou confidentielles, car ils peuvent être visibles par des personnes auxquelles ces informations ne sont pas destinées.

​Les journaux aident à corriger les défaillances, à enquêter sur les incidents et à démontrer la conformité aux exigences des clients et de la réglementation.

​Dans la mesure du possible, intégrez les journaux d'application aux mécanismes d'enregistrement de la plate-forme tels que l'Afficheur d'événements Windows ou Linux Syslog pour simplifier la surveillance, les enquêtes sur les incidents et les rapports de conformité. Évaluez si l'envoi des journaux vers un serveur sécurisé améliorera leur protection et leur accessibilité.

​Protégez les journaux d'audit contre tout accès non autorisé et toute modification et définissez leur durée de conservation.

​Approbation de publication

​Avant de publier le logiciel, effectuez une dernière revue de sécurité pour vérifier que l'application répond aux exigences de l'équipe en matière de version. Dans le cadre de cette revue finale, incluez :

• ​Examen et approbation du modèle de menace
• ​Exigences de sécurité implémentées
• ​Tests unitaires réussis
• ​Scans de sécurité terminés
• ​Vulnérabilités critiques corrigées
• ​SBOM généré
• ​Documentation mise à jour
• ​Instructions de déploiement revues
• ​Package de publication signé

​Le processus de publication devrait produire des preuves montrant que ces activités ont été réalisées. Ces dossiers de preuves doivent être protégés contre toute altération après la diffusion afin de maintenir leur intégrité.

​Signature de code et intégrité du paquet

​Les utilisateurs doivent être en mesure de vérifier que les logiciels publiés proviennent de l'organisation attendue et n'ont pas été modifiés depuis leur sortie.

​La signature de code doit être appliquée à tous les types de logiciels suivants :

• ​Exécutables
• ​Installeurs
• ​Drivers
• ​Plug-ins
• ​Bibliothèques
• ​Paquets de déploiement
• ​Mettre à jour les paquets

​La signature de code n'empêche pas les modifications logicielles, mais elle permet de détecter les modifications non autorisées et d'assurer que les logiciels proviennent de l'éditeur attendu.

​Validation du déploiement

​Après l'installation, vérifiez que le système déployé fonctionne en toute sécurité dans l'environnement prévu. Les activités de validation devraient confirmer les fonctionnalités suivantes :

• Les services requis sont en cours d'exécution
• ​Le cryptage fonctionne correctement
• ​Les autorisations utilisateur sont correctes
• ​L'enregistrement est opérationnel
• ​Les sauvegardes fonctionnent
• ​Les contrôles de sécurité restent activés après le déploiement

​La validation de la sécurité doit être effectuée chaque fois que des modifications importantes de configuration sont apportées.

​Preuves de déploiement

​Tenir des dossiers démontrant que le déploiement a été effectué conformément au processus défini. Ces enregistrements comprennent les exemples suivants :

• Procédures de déploiement approuvées
• ​Enregistrements d'installation
• ​Listes de contrôle de la revue de sécurité
• ​Enregistrements de signature de code
• ​SBOM
• ​Résultats du balayage de sécurité
• ​Rapports de validation du déploiement
• ​Approbations de publication

​Ces dossiers fournissent une traçabilité précieuse lors des audits clients, des évaluations fournisseurs, des examens réglementaires et des enquêtes de sécurité interne.

​Une vulnérabilité logicielle est une faiblesse, une faille ou un défaut dans la conception, l'implémentation, la configuration ou les processus opérationnels d'un logiciel qui pourrait être exploité pour compromettre la confidentialité, l'intégrité ou la disponibilité d'un système ou de ses données. Une vulnérabilité peut être identifiée dans le code développé par l'équipe ou dans l'un des composants utilisés dans le logiciel. Comme les vulnérabilités offrent aux acteurs malveillants un moyen d'endommager un système, il est important qu'elles soient corrigées et que les correctifs soient déployés sur les systèmes affectés.

​Pour les équipes LabVIEW

​L'industrie du test doit relever un défi historique pour répondre aux vulnérabilités. De nombreux projets de test sont financés par un modèle de financement initial unique, sans financement pour la maintenance continue des systèmes. Cela signifie que les équipes de test n'ont pas les ressources nécessaires pour mettre à jour les systèmes, même pour fournir des mises à jour de sécurité. Ceci est en conflit direct avec les exigences de sécurité pour maintenir les systèmes à jour.

​Un défi de taille est la quantité de validation requise pour effectuer les mises à jour. Même si les outils logiciels et matériels sont gratuits, une mise à jour peut coûter très cher pour valider le fonctionnement du système comme prévu après la mise à jour.

​Un virage industriel

​À mesure que l'industrie de la sécurité évolue, l'industrie du test doit également commencer à évoluer pour mieux planifier et financer les systèmes de test tout au long de leur cycle de vie. Les équipes de test peuvent prendre certaines mesures pour passer à une approche de gestion du cycle de vie complet, notamment :

• Négocier l'appropriation à long terme du système. Désigner un responsable du système qui est chargé de son cycle de vie et s'assurer que cette responsabilité est transférée lorsque les rôles changent dans l'organisation.
• ​Concevoir votre système pour qu'il soit modulaire. Il est beaucoup plus difficile de mettre à jour du code monolithique volumineux. Le code développé pour être modulaire peut être plus facilement mis à jour et testé sans affecter le code global. Définir la fonction de chaque module de code et l'interface de communication entre les modules.
• ​Construction de tests unitaires avec votre code. Les tests requièrent plus de développement de code, mais ces outils peuvent réduire considérablement les coûts de validation des mises à jour logicielles tout au long de la vie du système.
• ​Travailler avec vos clients et vos gestionnaires pour passer à un état d'esprit de cycle de vie complet. Cela peut signifier qu'il faut financer le projet tout au long de son cycle de vie, ou financer davantage de développement et de validation au début du projet. Les aider à reconnaître que la sécurité est un élément essentiel du projet et qu'elle doit être planifiée.
• ​Établissement d'une phase formelle de maintenance du cycle de vie du système, avec des activités telles que la gestion des défauts, la planification de l'obsolescence, les correctifs de sécurité, les mises à jour de la documentation et le support client. Traiter cette phase de soutien comme une activité d'ingénierie planifiée, et non comme une réflexion a posteriori.
• ​Planifier les mises à niveau technologiques dans le cycle de vie du système. Les intégrer dans le cycle de vie et, si nécessaire, facturer ces rafraîchissements au client à l'avance.
• ​Évaluation des défaillances de sécurité : les vôtres, celles de l'ensemble de l'organisation et celles documentées publiquement. Tirer les enseignements de ces expériences peut aider votre équipe à se préparer à de futures attaques et peut être utilisé pour justifier un investissement dans les efforts de sécurité continus.

​Identification de la vulnérabilité

​Nous annonçons des vulnérabilités dans les produits NI, y compris LabVIEW, drivers et autres logiciels, sur ni.com/security. Les correctifs sont également signalés par le système Common Vulnerabilities and Exposures (CVE). Ces correctifs peuvent corriger des vulnérabilités dans le code logiciel développé par les ingénieurs NI ou dans les composants que nous utilisons. Vous pouvez vous abonner aux notifications de nouveaux correctifs sur ni.com/security.

​Un SBOM peut aussi être utilisé pour automatiser les balayages du logiciel. Si vous générez un SBOM à partir de votre application LabVIEW, vous pouvez configurer un logiciel de balayage pour rechercher les problèmes rapportés dans la base de données CVE et vous en informer. Il existe divers outils d'analyse de composition logicielle (SCA) qui analysent les SBOM et les comparent à la base de données CVE.

​Si votre utilisateur final identifie une vulnérabilité, il peut vous le signaler directement. Si le problème se trouve dans le logiciel NI, vous pouvez le signaler sur ni.com/security.

​Correction de vulnérabilité

​Il est important de prendre au sérieux les rapports de vulnérabilité. Si votre utilisateur rapporte un problème ou si une vulnérabilité est signalée dans votre pile logicielle, analysez la vulnérabilité pour déterminer son impact et sa probabilité d'être exploitée. Ces problèmes dépendent de la nature de la vulnérabilité et de la façon dont vous avez utilisé le composant logiciel concerné. Si vous déterminez que la menace d'exploitation est importante, vous devez mettre à jour votre logiciel et envoyer un correctif à votre utilisateur final.

​Certaines réglementations, comme la loi européenne sur la résilience en matière de cybersécurité (CRA), exigent que vous fournissiez des correctifs de sécurité pendant cinq ans ou plus. Certains contrats peuvent spécifier des engagements de soutien plus ou moins longs. Planifiez ce niveau de support dans votre proposition de projet initiale pour éviter les surprises après la livraison du projet.

​Dans le cadre de votre processus de correction de vulnérabilité, effectuez une analyse des causes profondes de la vulnérabilité afin d'améliorer votre processus de développement et d'éliminer des problèmes similaires dans les projets futurs.

​Le développement sécurisé de logiciels n'est pas une activité distincte effectuée à la fin d'un projet. C'est un ensemble de pratiques intégrées tout au long du cycle de vie d'un système. En adoptant les principes décrits dans ce guide, les équipes LabVIEW peuvent réduire les vulnérabilités, améliorer la maintenance, simplifier les efforts de conformité et mieux protéger les systèmes et les données qui leur sont confiés. La sécurité est un processus et votre équipe va mûrir avec le temps. Commencer maintenant à établir un procédé reproductible et durable qui améliore continuellement la sécurité tout au long de la vie du produit.

• ni.com/security
• Document NIST 800-218
• CVE : Common Vulnerabilities and Exposures (CVE)
• Contrôles de cybersécurité de base, FAR 52.204-21
• Génération de SBOM à partir de LabVIEW
• Utilisation de LabVIEW Unit Test Framework pour le test et la validation de logiciels
• JKI Caraya pour les tests unitaires
• LUnit pour les tests unitaires
• Signature d'applications LabVIEW
• Cours Considérations de sécurité pour les intégrations de systèmes de test
• Guide de configuration sécurisée LabVIEW
• Cycle de vie des produits NI
• JKI Security Suite
• Microsoft SDL
• Initiation à Git
• Modélisation des menaces OWASP