Impact de la sécurité sur les systèmes de test automatisés

Imaginez-vous dans ce scénario bien trop familier pour ceux qui travaillent dans l'industrie manufacturière. Votre téléphone sonne à 2h15 du matin, vous sortant du sommeil. La conversation qui s’ensuit vous informe d'un événement qui requiert votre attention de toute urgence.

La chaîne de production C a été arrêtée au milieu d'une série à cause de la défaillance de deux automates programmables (PLC) utilisés dans le système de test de production en fin de chaîne pour assurer la qualité du produit. Le centre de contrôle de fabrication a perdu la communication avec les PLC 30 minutes auparavant et ne peut pas déterminer s’ils sont maintenant dans un état fiable pour les remettre en ligne. Trois incidents de ce type se sont déjà produits ce mois-ci, et maintenant un quatrième ? Cette fois, cependant, votre équipe de fabrication était préparée et déplace la production dans une usine adjacente ayant un excédent de capacité. Avec un peu d’espoir, cela contribuera à réduire les pertes nettes de production.

Comme on a pu le découvrir quelques jours plus tard, ces défaillances étaient le résultat d'un incident de cybersécurité. Cependant il ne s’agissait pas d'une attaque externe, mais d'un « tir allié ». Le service informatique a récemment mis en place des analyses qui s’exécutent chaque soir sur tous les appareils en réseau pour évaluer leur sécurité. Les équipements de test étaient auparavant exemptés de la plupart des protocoles informatiques, mais l’équipe dirigeante a modifié cette politique car ils ne pouvaient plus tolérer les risques de cybersécurité sur les appareils réseau non surveillés. En raison des algorithmes logiciels rudimentaires sur le PLC, probablement développés des décennies avant que les logiciels de sécurité n'existent, les analyses de sécurité quotidiennes ont submergé les deux PLC avec plus de paquets réseau qu'ils ne pouvaient en gérer et ont déclenché une réponse de défaillance : arrêt.

Les enjeux clés

La tendance à appliquer des pratiques de sécurité informatique aux systèmes de test est logique pour plusieurs raisons, notamment la multiplication des incidents de cybersécurité qui exploitent des périphériques réseau non surveillés. Aucun PDG ne veut se retrouver dans la position du PDG de Target, dont les systèmes de point de vente ont été compromis par une attaque provenant des contrôleurs des systèmes de chauffage et de ventilation. De même, aucun dirigeant ne peut supporter l'impact économique d'importantes pertes de production si les équipements de test venaient à être attaqués par les systèmes informatiques de l'entreprise.

Une autre raison pour laquelle cette tendance est logique est que les pratiques et la technologie de sécurité pour les systèmes informatiques généralistes sont plus matures. Pour protéger les systèmes et détecter s’ils sont compromis, le personnel de sécurité informatique dispose d'une gamme d'options allant des scanners de découverte réseau et de la technologie de détection d'intrusion, aux antivirus de bureau et aux agents de surveillance. La réponse naturelle consiste à étendre la couverture de ces meilleures pratiques et technologies de sécurité aux systèmes et dispositifs de test à usage spécial, en particulier lorsque ces pratiques sont utilisées pour se conformer à une norme réglementée telle que la norme NIST SP 800-171.

Toutefois, cette tendance n'a catégoriquement pas de sens pour au moins deux raisons. La première, les systèmes de test informatiques tolèrent moins les changements de configuration, même minimes. Les utilisateurs de systèmes informatiques peuvent tolérer des temps d'arrêt et ne même pas percevoir les différences de performances des applications, mais les systèmes de test à usage spécial (en particulier ceux utilisés en production) ne peuvent souvent pas les tolérer. Même de petits changements dans les caractéristiques de performance à cause d'un correctif de sécurité ou d'une nouvelle fonctionnalité de sécurité peuvent affecter négativement les résultats des tests ou même la qualité des données de test collectées. Par ailleurs, même de courts temps d’arrêt dans les systèmes de test en production peuvent avoir un impact financier important sur les revenus d’une organisation.

Deuxièmement, les systèmes de test ont souvent des besoins de sécurité uniques. Ils exécutent généralement des logiciels de test spécialisés qui ne sont pas utilisés sur d'autres ordinateurs de l'organisation, et ils sont équipés de périphériques spéciaux qui ne sont pas pris en compte par les technologies de sécurité informatique standard. Par exemple, les périphériques de test qui nécessitent un étalonnage pour fournir des mesures précises peuvent dégrader ou même compromettre la qualité des tests si leurs données d'étalonnage sont modifiées par malveillance ou par inadvertance. Appliquer aveuglément des pratiques de sécurité informatique à ces systèmes de test peut donner lieu à un faux sentiment de sécurité simplement parce qu’elles ne traitent pas les risques uniques de cybersécurité de ces systèmes de test.

Ce que vous pouvez faire 

L'approche privilégiée pour la sécurité des équipements de test comporte deux éléments clés. Tout d'abord, utilisez les données pour déterminer quelles mesures de sécurité informatique vous adoptez pour votre système de test et dans quelle mesure vous les appliquez. Vous disposez ainsi des informations nécessaires pour impliquer le personnel de sécurité informatique dans l’évaluation et la gestion des risques. Ensuite, complétez ces mesures de sécurité informatique par des fonctionnalités de sécurité spécifiques au système de test afin de gérer les risques uniques. Cela comble les lacunes que les pratiques standard de sécurité informatique ne peuvent pas couvrir.

Vous pouvez consulter le rapport annuel Data Breach Investigations Report (DBIR) de Verizon comme source de données. Dans ce rapport, Verizon analyse les données recueillies sur les violations de la cybersécurité divulguées au cours de l’année civile précédente. Une partie du DBIR 2016 de Verizon contient une analyse des cyberattaques actives qui s’en prennent aux vulnérabilités corrigées par les principaux fournisseurs de logiciels. Les hackers utilisent une technique qui tire parti du décalage entre la publication d’un correctif par un fournisseur et son installation sur un ordinateur. En rétro-compilant le correctif du fournisseur pour découvrir où se trouve la vulnérabilité dans le logiciel non corrigé, le hacker transforme alors un exploit en une arme pour jouer sur cette vulnérabilité. Les hackers commencent activement leur exploitation dans les deux à sept jours calendaires suivant la publication d'un correctif, en se concentrant fortement sur les principaux fournisseurs de logiciels.

Vous pouvez utiliser ces données pour prendre des décisions plus précises concernant les risques liés à la correction de vos systèmes de test. Pour réduire vos risques, commencez par installer les correctifs de sécurité dans les sept jours suivant leur publication. Cela signifie que vous devez surveiller les notifications des fournisseurs de logiciels, évaluer l'applicabilité des correctifs et requalifier rapidement les systèmes concernés. Ensuite, minimisez les logiciels installés sur vos systèmes de test. Le temps passé à le faire en amont sera rapidement amorti par la réduction des coûts de correction et de requalification. Ces étapes sont particulièrement importantes pour les systèmes de tests à haut risque tels que ceux utilisés dans la fabrication ou la production.

Le deuxième élément clé consiste à utiliser des fonctionnalités de sécurité propres aux fournisseurs. Par exemple, étant donné à quel point les données d'étalonnage, les paramètres de test et les séquences de test sont cruciaux pour maintenir la qualité des tests, vous pouvez utiliser des technologies telles que la surveillance de l'intégrité des fichiers et les fonctionnalités d'intégrité d'étalonnage spécifiquement configurées pour votre système de test et ses composants. De même, vous pouvez consulter la documentation de sécurité de vos fournisseurs de systèmes de test pour guider vos décisions d'achat, de conception et de déploiement de systèmes de test vers des options offrant une meilleure sécurité.

Questions à poser à votre fournisseur de systèmes de test

Dans quelle mesure votre logiciel est-il compatible avec les fonctionnalités de sécurité du système d’exploitation Windows ?

NI teste la compatibilité de ses logiciels avec les fonctionnalités de sécurité de Windows afin que vous puissiez les activer selon vos besoins dans votre environnement. Vous pouvez exécuter tous les logiciels d'application NI avec des privilèges utilisateur standard.

Puis-je supprimer en toute sécurité le composant logiciel « X » pour réduire mon risque de sécurité ?

Avec les installateurs de logiciels NI, vous pouvez personnaliser l'installation afin de pouvoir installer uniquement les produits dont vous avez besoin tout en vous assurant d'avoir toutes les dépendances nécessaires. En outre, les applications NI vous donnent la possibilité de créer vos propres installeurs personnalisés afin que vous puissiez déployer votre application avec l'environnement d'exécution et les dépendances minimales.

Quelles garanties supplémentaires puis-je utiliser pour protéger les logiciels de test et mes applications de test ?

Vous pouvez trouver des outils de surveillance de l'intégrité des fichiers sur le marché. NI évalue actuellement ces types d'outils pour déterminer comment ils pourraient être configurés pour fonctionner avec les logiciels NI. Contactez NI pour plus de détails.

Où puis-je trouver des informations sur la sécurité de vos logiciels et de votre matériel ?

NI fournit de la documentation sur les ports et protocoles réseau, les services Windows, le nettoyage de la mémoire et les mises à jour de sécurité critiques.

L’annonce de logiciels malveillants (malwares) qui visaient les systèmes de contrôle industriels a créé la surprise en 2014. Ce n'était pas le fait de hackers pénétrant à distance les défenses d'une usine particulière ou d'agents secrets installant des logiciels malveillants dans une raffinerie. En fait, le logiciel malveillant avait été installé par le biais d’un logiciel d’un fournisseur qui contenait un cheval de Troie.

La campagne a été surnommée à l’origine « Energetic Bear » parce qu’elle ciblait les centrales électriques et qu’on pensait qu’elle provenait de Russie. L’un des aspects de la campagne concernait la chaîne d’approvisionnement. Ils ont attaqué trois fournisseurs de logiciels différents ; pour ces trois fournisseurs, le logiciel du système de contrôle industriel pouvait être téléchargé par les clients depuis le site Web. Lorsque les hackers ont eu accès aux fichiers sur le site Web, ils ont modifié l’installeur du logiciel du fournisseur légitime en y insérant un logiciel malveillant, puis ont enregistré le fichier à son emplacement d'origine sur le site Web. Ce n'était qu'une question de temps avant que les clients ne téléchargent le cheval de Troie et l'installent. L'impact économique pour les fournisseurs de logiciels et leurs clients est inconnu.

Dans un cas plus sophistiqué, Kaspersky Labs a découvert en 2010 que les disques durs commerciaux de plusieurs fournisseurs dans leur chaîne d’approvisionnement étaient compromis, et ceci depuis 2005. Ils ont découvert un firmware intégré dans les contrôleurs de disque dur qui semblait faire fonctionner le disque dur normalement. Cependant, il stockait secrètement une copie de ce qu'il considérait être des informations sensibles dans des zones inutilisées de la mémoire non volatile contenant le firmware. Comme le firmware modifié n'avait aucune capacité de communication externe, on pourrait en conclure qu'un opérateur recueillerait le disque dur après sa mise hors service pour récupérer les informations sensibles. Remarquez que les informations sensibles seraient récupérables même si le contenu du disque dur était nettoyé avant élimination.

Les enjeux clés

La compromission du site Web avec la campagne Energetic Bear indique que l’intégrité d’un système de test (ou de tout système) repose sur l’intégrité de ses composants tout au long de leur cycle de vie. À chaque fois que les composants changent de mains ou qu’ils stagnent au même endroit pendant une période prolongée, il existe un risque qu’ils soient compromis. La mise en place d'une chaîne de contrôle claire est vitale, et les garanties visant à protéger et à détecter un composant compromis à chaque étape le sont tout autant.

La découverte de la compromission du disque dur de Kaspersky indique que les hackers affinés de ce monde sont prêts à s’introduire dans le processus de développement d'un fournisseur pour accéder au code source non publié du fournisseur. Dans ce cas, le code source volé du fournisseur a été utilisé pour créer des variantes entièrement installables et fonctionnelles qui ont été installées dans les disques durs compromis bien après l'achat et la mise en service des disques durs.

Aucun aspect d'un produit n'est à l’abri d’une chaîne d'approvisionnement compromise. N'importe quel installeur, même pour des plug-ins ou des compléments logiciels apparemment insignifiants, pourrait avoir été compromis par la campagne Energetic Bear. Il en va de même pour le firmware apparemment insignifiant dans les contrôleurs de disque dur, qui permettait des mises à jour de certains champs sans vérifications de sécurité strictes.

Vous devez comprendre les compromis entre la diversité des fournisseurs et la standardisation dans la gestion des risques liés à la cybersécurité. La diversification a l’avantage de réduire le risque de compromission à l’échelle du système en raison de la compromission d’un composant d’un fournisseur. Mais en contrepartie, cette diversification engendre des coûts de viabilité liés à la formation du personnel sur plusieurs types d’équipement et à la gestion de toutes les relations avec les fournisseurs . La standardisation réduit ces coûts de viabilité, mais elle comporte un risque accru de compromission à l'échelle du système.

Ce que vous pouvez faire 

La standardisation présente tant d'avantages en terme de coûts qu'il est difficile de justifier la diversité des fournisseurs, sauf dans des scénarios à haut risque. L’approche la plus réalisable implique la standardisation des fournisseurs, où l’évaluation de la sécurité de la chaîne d’approvisionnement du fournisseur constitue une part importante des critères de décision.

La plupart ont déjà des fournisseurs sur lesquels ils se sont alignés. Dans ce cas, le fournisseur et vous-même avez tout intérêt à maintenir la relation. La chose la plus importante que vous puissiez faire pour assurer la sécurité de la chaîne d’approvisionnement est de discuter avec vos fournisseurs. Interrogez-les sur leur chaîne d’approvisionnement et demandez-leur ce qu'ils font pour protéger l'intégrité de leurs produits tout au long de leurs processus de développement, de fabrication et d'exécution des commandes. Tout ce que vous pourrez apprendre sur les faiblesses de leurs processus peuvent contribuer à réduire le risque de compromission de votre chaîne d’approvisionnement et aider vos fournisseurs à renforcer leur sécurité. Sans ce dialogue, les deux parties risquent de prendre des décisions non éclairées.

Outre la prévention, assurez-vous que le dialogue avec vos fournisseurs comprend des moyens de détecter quand une compromission a eu lieu. Tout système de sécurité peut être compromis avec suffisamment de motivation et de ressources. Assurez-vous qu'il y a suffisamment de vérifications dans le système pour détecter s’il a été compromis et qu'il y a des instructions claires sur la façon de réagir. Dans un cas comme celui de la compromission du site Web d’Energetic Bear, la dernière étape du mécanisme de détection pourrait être un contrôle de la signature numérique de l’installateur. Mais ce mécanisme de détection doit être jumelé à des procédures et une formation appropriées qui aboutissent à l’abandon de l’installation et la création d’un ticket auprès du support technique. Dans un cas comme celui de la compromission du firmware du disque dur, une enquête sur la conception de la mise à jour du firmware du fournisseur révélerait une lacune de protection sans aucun moyen de vérifier l'intégrité du firmware installé.

Questions à poser à votre fournisseur de systèmes de test

Comment puis-je vérifier que le logiciel que je reçois de votre part est légitime ?

NI signe numériquement tous ses installeurs de logiciels Windows afin que vous (et Windows) puissiez vérifier qu'ils proviennent de NI et n'ont pas été altérés. En outre, NI offre une solution de livraison de logiciels sécurisée qui ajoute une assurance physique à la livraison de logiciels. Pour la livraison sécurisée des logiciels, NI utilise un emballage scellé, témoignant de son intégrité, et un envoi traçable des logiciels sur des disques optiques, ainsi qu’un disque de validation livré indépendamment pour vérifier l'intégrité du fichier du logiciel dans l'autre paquet.

Comment protégez-vous votre chaîne d'approvisionnement contre les pièces contrefaites et les composants modifiés ?

NI suit des pratiques de qualité rigoureuses concernant l’approvisionnement en pièces et la façon dont le produit final est assemblé. NI vérifie les antécédents du personnel impliqué dans la fabrication et les tests, et dispose de mécanismes régulateurs pour s’assurer que vous recevez un produit de haute qualité. Contactez NI pour plus de détails.

Comment puis-je vérifier que personne n'a falsifié les données d'étalonnage de mon matériel ?

Les modules matériels NI nécessitent un mot de passe pour apporter des modifications aux données d'étalonnage à long terme. Gérez ce mot de passe avec la même diligence que celle que vous appliquez à votre mot de passe Windows. NI développe actuellement une fonctionnalité d'intégrité de l'étalonnage pour certains modules matériels. Cette fonctionnalité vous permettrait de vérifier que les données d'étalonnage à long terme n'ont pas changé depuis leur étalonnage certifié.

Comment vos produits prennent-ils en charge la diversification des fournisseurs ?

Dans mesure du possible, NI respecte les normes de l’industrie afin de fournir l’interopérabilité la plus large avec les produits d’autres fournisseurs. Par exemple, les produits NI sont conformes aux normes de communication PCI, PXI, IEEE, IETF et ISO/IEC et utilisent des technologies standard de l'industrie telles que IVI et OPC-UA. NI participe également à bon nombre de ces comités de normalisation.

La fuite par Edward Snowden d’une large quantité de données de surveillance classifiées de la National Security Agency est la cause la plus probable d'une attention accrue portée à la menace d’initié. Ses actions ont engendré des pertes économiques estimées entre 22 et 35 milliards de dollars pour l'industrie technologique américaine, en raison de la méfiance dans la technologie américaine qui en a résulté. Mais ce n’est pas le premier cas de menace interne.

Timothy Lloyd d'Omega Engineering est devenu tristement célèbre pour ses activités d'initié en 1996. À l’époque, Microsoft Windows 95 était la dernière technologie en date, et la cybersécurité était rarement (voire jamais) abordée par les médias grand public. Ce que Timothy Lloyd a pu accomplir en tant qu'initié privilégié était stupéfiant pour l'époque. Il travaillait sur le site de fabrication comme administrateur système. Lorsqu'il a appris qu'il serait licencié, il a installé une bombe à retardement logicielle qui a systématiquement supprimé tous les logiciels de fabrication des systèmes sous son contrôle. La « bombe à retardement » s’est déclenchée lorsque le premier administrateur s’est connecté au réseau le lendemain du licenciement de Lloyd. L'impact économique de cet événement pour Omega Engineering s'est élevé à plusieurs millions de dollars et la perte de 80 emplois. Cela a failli acculer l'entreprise à la faillite.

Les enjeux clés

Les questions clés dans ce domaine sont multiformes et constituent toujours un sujet de recherche important. Il s'agit notamment d'être attentif à toute personne ayant accès à des systèmes de tests critiques, quel que soit son statut d'employé ou de sous-traitant. Cela implique également une identification claire des aspects les plus critiques de l'entreprise et des personnes jouant un rôle dans ces aspects de l'entreprise et de la façon dont l'autorité est répartie entre eux. Les solutions impliquent généralement un degré important de surveillance comportementale, ce qui peut affecter négativement la confiance interpersonnelle nécessaire à l'efficacité opérationnelle.

Les menaces internes sont des événements à faible probabilité mais à fort impact, une affirmation que soutient le DBIR 2016 de Verizon. Sur plus de 64 000 incidents de cybersécurité en 2015, seuls 172 impliquaient un abus de privilèges par un initié. Plus de 75 % des menaces internes ont été commis seuls, sans aide extérieure ni collusion interne avec un autre initié.

Ce que vous pouvez faire

À l'exception des systèmes à haute criticité, il est préférable de s'attaquer à la menace interne après d’être occupé des éléments de bases décrits dans les tendances précédentes. Ces autres tendances indiquent les façons les plus probables de compromettre vos systèmes de test.

Toutefois, pour les systèmes à haute criticité, abordez dès que possible la menace interne dans le processus de conception. Après avoir identifié les aspects les plus sensibles ou les plus critiques du système, concevez une solution de gestion des privilèges qui sépare les tâches en au moins deux rôles qu'une seule et même personne ne peut occuper, et empêchez toute tentative d'attribuer les deux tâches à un seul rôle. Selon les données du DBIR de Verizon, cela fait passer les probabilités en votre faveur de la tranche 77 % (action d’une seule personne) à celle de 8 % (action collective).

Question à poser à votre fournisseur de systèmes de test 

Comment protégez-vous le code source de vos logiciels en interne ?

NI implémente de nombreuses couches de protection pour son code source logiciel : NI exige des noms d'utilisateur et des mots de passe uniques pour apporter des modifications, limite l'accès de la société aux seuls groupes d'ingénierie impliqués dans le développement, et examine périodiquement les listes de contrôle d'accès. Les groupes d'ingénieurs choisissent de restreindre les modifications de code aux membres de la liste de contrôle d'accès ou d'autoriser les modifications de code provenant de non-membres. Pour les groupes qui autorisent les modifications de code de la part de non-membres, NI exige des notifications de ces changements de code source et une revue du code par un membre du groupe.

Répondre aux besoins de cybersécurité d'un système de test est complexe. Cela peut soit s'enliser dans une infinité de risques de sécurité potentiels, soit ne jamais démarrer parce que cela semble insurmontable. En réalité, il est impossible d’atteindre la sécurité parfaite car, avec suffisamment de ressources et de temps, chaque solution peut théoriquement être compromise. Plutôt que de vous enferrer dans l’un des extrêmes, commencez par hiérarchiser les problèmes en fonction de scénarios réalistes et abordez d'abord les questions les plus importantes, en faisant preuve de bon sens, au fur et à mesure.

Commencez par établir un consensus parmi les personnes concernées (par exemple, votre direction, votre équipe, votre personnel de sécurité informatique et vos fournisseurs) sur l'importance pour tous de faire face aux menaces à la sécurité. Ce point de départ a également l'avantage de sensibiliser l'ensemble du personnel concerné à la nature des menaces à la cybersécurité et à l'impact négatif potentiel des incidents de sécurité sur leur succès mutuel. Ensuite, allouez du temps et de l'argent spécifiquement pour les projets relatifs à la cybersécurité, ainsi que la formation et la technologie. Étant donné que les menaces de cybersécurité pesant sur les systèmes de test sont réelles et représentent un risque financier pour votre organisation, une allocation des ressources de l’organisation doit être consacrée à l’évaluation et à la satisfaction des besoins en matière de cybersécurité. Après une évaluation réaliste de la façon dont les menaces de cybersécurité peuvent avoir un impact sur vos opérations, affectez une quantité proportionnelle de vos ressources pour répondre à ces besoins.

• En savoir plus sur la sécurité à NI 
• En savoir plus sur les meilleures pratiques pour construire un système de test 
• Configurer un système de test