Certaines industries comme la pharmaceutique, la chimie ou l’agroalimentaire dépendent d’équipements de laboratoire, en particulier pour des besoins de contrôle qualité, R&D ou analyses chimiques. Certains de ces équipements sont essentiels au maintien des opérations et à la conformité réglementaire (i.e. en milieu pharmaceutique pour le contrôle qualité des matières premières et des produits finis pour la libération des lots, ou encore la production de rapports réglementaires). Leur disponibilité et leur fiabilité constituent donc des enjeux majeurs pour ces entreprises. Cependant, ces dispositifs, initialement conçus pour fonctionner de manière isolée, sont désormais de plus en plus connectés afin d’améliorer l’efficacité opérationnelle grâce, entre autres, à la collecte automatisée des données et à l’harmonisation des méthodes d’analyse entre les différents sites.

Ces besoins opérationnels ont conduit à une utilisation généralisée des systèmes de gestion des informations de laboratoire (LIMS). Les LIMS offrent un large éventail d’applications concrètes : dans les environnements pharmaceutiques, ils gèrent les dossiers analytiques des lots, surveillent les paramètres de qualité et assurent une traçabilité complète pour les audits réglementaires. Dans le domaine des analyses environnementales, les LIMS facilitent la collecte, la validation et la production de rapports sur les données de terrain, réduisant ainsi les erreurs manuelles. Dans les laboratoires de sécurité alimentaire, ils automatisent la génération de rapports de conformité et déclenchent des alertes lorsque les seuils de contamination sont dépassés.

Centraliser la gestion des équipements de laboratoire au travers des LIMS nécessite leur mise en réseau, même lorsque cela n’avait pas été initialement prévu par les fabricants. Cette connectivité accrue entraîne de nouveaux défis de cybersécurité, car de nombreux systèmes de laboratoire reposent sur des technologies obsolètes, augmentant ainsi la surface d’attaque.

Systèmes obsolètes : Un risque de sécurité croissant

De nombreux équipements de laboratoire fonctionnent encore avec des systèmes d’exploitation propriétaires ou obsolètes (par exemple, Windows XP) qui ne bénéficient plus de mises à jour de sécurité. Ces systèmes hérités sont vulnérables à des failles connues et ne peuvent pas être patchés facilement.

Au-delà de l’obsolescence des systèmes souvent constatée, ces équipements font rarement l’objet de publication de correctifs ou patchs de la part de leurs fabricants, malgré leur cycle de vie long. Une fois en production, la mise à jour de ces systèmes représente également des enjeux, en particulier à la gouvernance — en particulier, la détermination des équipes responsables de la mise à jour.

La plupart des instruments de laboratoire disposent de capacités de sécurité intégrées limitées. Ils reposent souvent sur des protocoles de communication non sécurisés ou obsolètes — tels que HTTP, FTP ou SMBv1/v2 — ou sont déployés avec de mauvaises pratiques de configuration qui affaiblissent encore davantage leur posture de sécurité. Bien que les modèles plus récents prennent en charge des standards plus sûrs comme OPC UA ou SFTP, ces fonctionnalités ne sont pas toujours activées ni correctement configurées.

Figure 1 : Architecture réseau type en milieu pharmaceutique.

La gestion des identités et des accès constitue un autre défi majeur dans les environnements de laboratoire. De nombreux instruments ne reposent pas sur des mécanismes d’authentification ou alors nécessitent l’utilisation de comptes locaux ou partagés. Ces systèmes sont rarement compatibles avec des annuaires centralisés via des protocoles comme LDAP, ce qui complique l’application de politiques de sécurité cohérentes entre les sites. D’un point de vue opérationnel, l’authentification peut sembler superflue, mais combinée à des systèmes d’exploitation obsolètes, des protocoles de communication non sécurisés et un contrôle d’accès limité, ces faiblesses transforment les appareils de laboratoire en points d’entrée faciles pour les cyberattaques.

À mesure que les laboratoires interconnectent de plus en plus leurs instruments avec les LIMS, les solutions d’analyse Cloud et les systèmes centralisés d’historisation des données, ce manque d’hygiène de sécurité expose non seulement les équipements directement, mais met également en danger le reste du réseau d’entreprise.

Sécuriser les systèmes de laboratoire grâce à l’isolation et aux passerelles réseaux

Lorsque les équipements de laboratoire ne peuvent pas être sécurisés en raison de leurs limitations inhérentes, il est essentiel de réduire leur exposition autant que possible. Cela implique de placer ces dispositifs derrière des systèmes intermédiaires sécurisés — tels que des passerelles ou des postes de travail dédiés — et de définir des zones réseaux spécifiques afin de limiter la surface d’exposition en cas de compromission. En segmentant le réseau et en filtrant les flux de données, il devient possible de mieux contenir les compromissions potentielles et de limiter leur impact sur les autres systèmes critiques.

Trois solutions clés peuvent renforcer la sécurité dans ce contexte :

• Mise en place de postes de travail équipés d’outils de cybersécurité pour assurer la compatibilité entre les équipements de laboratoire et les réseaux sécurisés. Cette approche est particulièrement efficace lorsque des postes de travail modernes servent d’intermédiaires, en assurant une transmission sécurisée des données et en permettant leur surveillance. Cette solution est en réalité une des manières les plus utilisées pour gérer les équipements de laboratoire et manipuler les données qu’ils génèrent.
• Isolation des équipements de laboratoire par rapport aux environnements réseaux plus larges afin de limiter leur exposition. Cette approche étend les pratiques standards de segmentation réseau aux systèmes de laboratoire, en contrôlant leur exposition sans les isoler complètement, tout en maintenant les flux de données nécessaires aux opérations. Elle est peu coûteuse et facile à déployer, ce qui la rend particulièrement adaptée aux systèmes anciens qui ne peuvent pas être mis à jour.
• Déploiement d’équipements « Edge » pour la traduction des protocoles et l’isolation réseau. Ces dispositifs sont particulièrement efficaces dans les environnements nécessitant un échange de données en temps réel entre des systèmes incompatibles.

Figure 2 : Architecture réseau pharmaceutique intégrant des mesures de protection des équipements de laboratoire.

Bien que ces solutions contribuent à sécuriser les environnements industriels, elles introduisent également de nouveaux défis, tels que la gestion des correctifs et la responsabilité des équipements — des facteurs cruciaux pour maintenir la sécurité à long terme. Il s’agit de réponses à une situation initialement non sécurisée et, par conséquent, elles ne sont pas parfaites : par exemple, l’utilisation de postes de travail comme passerelles constitue une bonne pratique, mais nécessite la mise à jour des systèmes, la gestion du cycle de vie, et peut impliquer des coûts supplémentaires ainsi qu’une empreinte accrue dans les salles serveurs (besoin accru d’infrastructure).

Le choix de la solution pour atténuer les risques de cybersécurité doit être en adéquation avec les contraintes techniques et le contexte opérationnel de l’organisation. Quelques pratiques courantes permettent d’illustrer la diversité des stratégies :

• L’isolation des équipements de laboratoire dans un VLAN dédié reste une première étape efficace. Cependant, même les systèmes segmentés doivent utiliser des protocoles de communication sécurisés afin de garantir l’intégrité des données et d’empêcher tout accès non autorisé.
• La mise en place des équipements « Edge » offre une couche de protection supplémentaire. Cependant, ils présentent leurs propres défis, notamment en ce qui concerne la responsabilité organisationnelle, ainsi que la gestion et la maintenance.
• Le déploiement de postes de travail équipés d’outils de cybersécurité qui font souvent office de passerelles par défaut, convertissant les données en formats pouvant être lus et traités — que ce soit par les LIMS, les plateformes cloud ou les bases de données internes. Cette configuration est courante et reste sécurisée tant que le poste est correctement administré et durci, afin de ne pas devenir un point de défaillance ou d’introduire une surface d’attaque supplémentaire. La mise en place de cette couche intermédiaire est idéale, mais elle nécessite le développement ou l’intégration de mécanismes de traduction fiables, parfois non pris en charge par le fournisseur.

Conclusion : Renforcer la cybersécurité en environnement de laboratoire

Dans les industries concernées, garantir l’intégrité des données, la qualité du produit final et la sécurité des consommateurs reste une priorité majeure. Cependant, à mesure que les laboratoires deviennent de plus en plus numérisés et interconnectés, de nouveaux cas d’usage émergent, remettant en question les architectures et les modèles opérationnels traditionnels. Cette évolution exige une approche de cybersécurité plus complète et globale — intégrant des mesures techniques, une maturité des processus et une gouvernance claire à l’échelle de l’ensemble de l’écosystème laboratoire.

La mise en œuvre d’un processus de cybersécurité « by design » tout au long du cycle de vie des projets semble essentielle — non seulement pour anticiper les risques cyber au plus tôt, mais aussi pour aider les équipes métiers à intégrer la sécurité de manière fluide dans leurs opérations.

Néanmoins, le Cyber Resilience Act (CRA) vient renforcer la cybersécurité des produits numériques au sein de l’Union Européenne aussi bien pour les fabricants de produits, que les importateurs ou distributeurs de ces produits.

Pour aller plus loin : Cyber Resilience Act : Une révolution qui redéfinit la sécurité des produits et transforme l’écosystème – RiskInsight

Cet article Protéger les instruments connectés : un enjeu croissant pour les laboratoires est apparu en premier sur RiskInsight.

En 2024, on estimait le nombre d’appareils IoT connectés dans le monde à environ 18 milliards, soit plus de deux fois la population mondiale. Des alarmes connectées aux ascenseurs intelligents, en passant par les capteurs industriels ou les dispositifs médicaux, ces technologies rythment désormais notre quotidien. 

Les récentes avancées dans le domaine de l’IoT ont transformé la façon dont nous interagissons avec les objets connectés. Conçus pour être intuitifs, ils sont accessibles sans expertise spécifique. Les connexions entre ces derniers, souvent sans fil, passent presqu’inaperçues aux yeux des utilisateurs. Pourtant, derrière cette apparente simplicité se cachent des protocoles de communication élaborés dont MQTT fait partie.   

En raison de sa popularité et de sa présence croissante au sein d’opérations sensibles, MQTT fait depuis plusieurs années l’objet de recherches quant aux risques liés à son utilisation. Nous nous intéresserons ici à son fonctionnement, ses vulnérabilités potentielles ainsi qu’aux bonnes pratiques permettant d’assurer la sécurité des communications. 

MQTT et les raisons de sa popularité 

Les forces de ce protocole 

Développé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom), l’objectif derrière la conception de MQTT était de fournir une solution légère, efficace, avec une faible consommation d’énergie et de bande passante pour surveiller des oléoducs isolés dans le désert par le biais d’une liaison satellitaire. 

Si MQTT s’est aujourd’hui établi comme une référence pour la transmission de données IoT, c’est précisément pour ces propriétés fondamentales. Ce protocole est par ailleurs fréquemment utilisé pour la remontée de données provenant de capteurs ou d’objets connectés vers des plateformes Cloud. 

Figure 1 – Caractéristiques principales de MQTT 

Son fonctionnement

Définitions des termes clés 

Client MQTT : Un dispositif échangeant des informations. 

Broker MQTT : Une entité intermédiaire permettant à des clients MQTT de communiquer et par laquelle tous les messages MQTT transitent. En particulier, le broker reçoit les messages publiés et les distribue aux destinataires concernés (les abonnés au topic correspondant). 

Topic : Une chaine de caractères permettant de filtrer et d’organiser les messages selon une structure hiérarchique. Lorsqu’un client publie un message, il l’associe à un topic. 

Publish/Subscribe : Modèle dérivé du Client/Serveur classique pour lequel les demandes ne sont pas initiées par un client demandant des ressources à un serveur mais par un serveur envoyant régulièrement des mises à jour à des clients sans sollicitation active. 

MQTT est un protocole de communication « Machine à Machine » ou M2M qui opère selon un modèle Publish/Subscribe ce qui permet une grande souplesse dans son implémentation. 

Les clients MQTT peuvent endosser le rôle de publisher, subscriber ou les deux.   

Afin de recevoir les informations dont ils ont besoin, les subscribers s’abonnent à des rubriques ou topics (1), généralement organisés de manière hiérarchique au sein du broker (ex. Maison/Chambre/…). Dès lors qu’un publisher aura émis un message destiné aux abonnés de ce topic (2), ils seront notifiés par le broker (3).    

De ce fait, les clients MQTT ne sont pas contraints de partager un même réseau, ni d’être actifs au même moment et ne nécessitent pas de synchronisation entre eux.  

Figure 2 – Illustration d’une architecture MQTT simplifiée 

Par ailleurs, MQTT propose un mécanisme de « Qualité de Service » de ses messages permettant d’adapter les communications aux exigences de l’application. Il est ainsi capable, par exemple, de garantir la livraison des messages en cas de connexion instable. Les clients MQTT peuvent sélectionner un niveau parmi trois de « QoS » pour la distribution de leurs messages : 

• QoS 0 « Au plus une fois » – Le message sera distribué une fois ou pas distribué du tout, sans accusé de réception. 
• QoS 1 « Au moins une fois » – Le message sera distribué périodiquement tant que l’expéditeur n’aura pas reçu d’accusé de réception. 
• QoS 2 « Une seule fois » – Le message est garanti d’être distribué et une seule fois. 

Le niveau de « QoS » choisi a également une incidence sur la durée de stockage du message localement auprès de l’expéditeur et du destinataire. 

Cette architecture permet d’établir des communications décentralisées et extensibles (scalable). Ces caractéristiques s’avèrent particulièrement avantageuses dans le domaine de l’IoT où la flexibilité est essentielle pour répondre à la diversité des cas d’usage. Elles expliquent également pourquoi MQTT dépasse largement le cadre de l’IoT et trouve des applications dans de nombreux autres environnements tels que la télémétrie et la surveillance industrielle. 

MQTT est-il vulnérable ? 

A l’instar de nombreux autres protocoles de communication, MQTT n’est pas sécurisé par défaut. Bien que la plupart de ses implémentations intègrent à présent des solutions de sécurité robustes, certaines faiblesses et erreurs de configurations persistent, rendant les systèmes vulnérables. 

Pour souligner ces notions, nous nous intéresserons à un exemple standard d’utilisation de ce protocole en milieu industriel. 

Figure 3 – Illustration d’un exemple d’utilisation industrielle de MQTT 

Dans ce scénario, tous les systèmes représentés contiennent un client MQTT permettant de souscrire ou de s’abonner à des topics et de communiquer avec le broker « on-premise ». Les communications MQTT ne sont pas chiffrées et il n’y aucune authentification du broker ou des clients, laissant la possibilité à un attaquant d’accéder aux données de production échangées en clair ou de transmettre des ordres aux équipements en usurpant l’identité du broker ou de l’un de ces clients. 

Comment se protéger ? 

Pour se protéger efficacement contre ces risques, le broker et les clients MQTT doivent être déployés et configurés avec vigilance. Nous proposons ici différentes étapes de sécurisation afin d’assurer la confidentialité, l’intégrité, l’authenticité et la disponibilité des communications de bout en bout. 

Sécurisation du broker MQTT 

Activation du chiffrement par défaut des communications 

Lorsque le port 8883 est l’unique port MQTT défini, les tentatives de communication non-chiffrées sur le broker sont rejetées. Par ailleurs, il est essentiel que le broker ait accès à un certificat ainsi qu’une clé privée valides et que la suite cryptographique utilisée soit sécurisée (par exemple TLS 1.2 ou 1.3).  

Figure 4 – Activation du chiffrement sur un broker MQTT Mosquitto par le biais d’un fichier de configuration 

De nombreux dispositifs IoT ont une faible capacité de calcul et peu de ressources, ajouter des mécanismes tels que TLS peut représenter une surcharge importante. 

Mise en place d’une authentification des clients et d’un contrôle de leurs droits d’accès 

MQTT permet l’authentification des clients se connectant à un broker, via des méthodes courantes telles que l’utilisation d’un nom d’utilisateur et d’un mot de passe (avec un fichier de mot de passe associé) et la vérification du certificat du client, validé par une autorité de certification (le broker devant disposer du certificat de cette autorité). Certains brokers permettent également l’utilisation de solutions d’authentification externes. 

Afin de restreindre l’abonnement ou la publication sur certains topics par les clients, une logique d’Access Control List ou ACL peut être ajoutée.

Figure 5 – Ajout d’une authentification par certificat et mot de passe avec un contrôle d’accès sur un broker MQTT Mosquitto 

Une gestion rigoureuse des topics est essentielle pour prévenir les fuites de données et limiter les risques de compromission du broker. L’utilisation des wildcards # et + doit être attentivement surveillée, car une configuration trop permissive permettrait à un attaquant d’accéder à tous les échanges en cours. 

Déploiement de mesures de protection du broker  

Une rapide recherche sur le moteur Shodan révèle l’exposition de milliers de brokers MQTT sur Internet souvent laissés dans leur configuration par défaut, dont les utilisateurs ignorent l’existence ou les implications. Il est donc primordial de protéger le broker de menaces à la fois internes et externes en appliquant de bonnes pratiques de sécurité, telles que la mise à jour régulière du système ou la restriction du nombre de requêtes et connexions simultanées, pour prévenir les attaques par déni de service et garantir sa disponibilité. 

Sécurisation des clients MQTT 

Activation du chiffrement des communications 

Afin de se connecter sur le broker, les clients devront utiliser le port 8883 et posséder un certificat ainsi qu’une clé privée valides auquel cas la connexion sera rejetée.   

Figure 6 – Connexion chiffrée sur un client MQTT Paho 

L’utilisation de certificats auto-signés pour la connexion au broker est fortement déconseillée car ces derniers peuvent être facilement substitués. 

Mise en place d’une authentification du broker (authentification mutuelle) 

En plus de l’authentification des clients, MQTT permet l’authentification du broker via la vérification de l’autorité de certification ayant signé son certificat, assurant ainsi une authentification mutuelle (mTLS) et la sécurité des communications. 

Figure 7 – Authentification du broker sur un client MQTT Paho 

Déploiement de mesures de protection du client 

En cas de compromission d’un client MQTT, un attaquant pourrait accéder à des nombreuses informations en fonction de la configuration du broker ciblé. C’est pourquoi les clients et leurs secrets doivent aussi être protégés par l’application de bonnes pratiques de sécurité sur la machine hôte du client et sur le contenu des échanges (ajout de mécanismes anti-rejeu sur les requêtes par exemple).  

Quel futur pour MQTT ? 

Malgré sa maturité, MQTT demeure un protocole en évolution et intègre progressivement des fonctionnalités innovantes afin de répondre aux exigences croissantes des environnements connectés. Dans un contexte où la demande pour des communications fiables, sécurisées et à faible consommation d’énergie ne cesse d’augmenter, il est vraisemblable que les cas d’utilisation de MQTT continueront de se multiplier au cours des années à venir.

Cet article La sécurité du protocole MQTT est apparu en premier sur RiskInsight.

Cependant, cette évolution met en lumière les problématiques de cybersécurité spécifiques à ces systèmes, poussant les entreprises du secteur industriel à mener des réflexions sur la sécurisation de ces usages. 

Quelles opportunités sont amenées par l’Intelligence Artificielle dans le secteur industriel ?  

Quelles opportunités l’Intelligence Artificielle apporte-t-elle ? Et quels sont les éventuels risques de cybersécurité que cela apporte ?  

IA & Industrie 

Pour mieux comprendre l’étendue des possibilités offertes par ces technologies, Wavestone a établi le Radar des cas d’usages de l’IA générative pour les opérations 2024, répertoriant les tendances d’utilisation observées chez ses clients industriels, ainsi que d’autres cas d’usage susceptibles de se développer dans les prochaines années :  

Figure 1 – Radar des cas d’usages d’IA générative pour les opérations 

Wavestone a identifié 4 typologies d’usage (aide à la prise de décision, amélioration d’outils et de processus, génération de documents, assistance à la réalisation de tâches) impactant plusieurs fonctions industrielles (production, qualité, maintenance, gestion des stocks, chaîne d’approvisionnement, etc.).

Figure 2 – Typologies d’usage d’IA générative pour les opérations 

Voici quelques exemples concrets illustrant comment ces technologies s’intègrent aux opérations de divers secteurs, ce qu’elles apportent, tout en mentionnant les impacts que peuvent engendrer des cyberattaques sur ces systèmes : 

Figure 3 – Cas d’usage d’IA existants dans le secteur industriel 

Ces systèmes permettent d’obtenir des avantages technologiques et stratégiques, des gains financiers ou de temps non négligeables.  

Néanmoins, l’intégration de ces technologies peut ouvrir la porte à de nouveaux risques qui doivent être pris en compte par les entreprises. 

Cyber risques de l’IA 

Comment un attaquant peut-il compromettre ces systèmes ? 

Il existe plusieurs catégories d’attaques spécifiques à l’IA, toutes exploitant des failles présentes dans les différentes phases du cycle de vie de ces modèles, offrant une large surface d’attaque :  

Figure 4 – Cycle de vie d’un modèle d’IA : attaques possibles 

La majorité de ces attaques cherchent à détourner l’IA de son usage prévu. Les objectifs peuvent être d’en extraire des informations confidentielles, ou encore de lui faire exécuter des actions non autorisées, compromettant ainsi la sécurité et l’intégrité des systèmes. 

Pour comprendre ces attaques dans les détails, nos experts ont illustré des méthodes par évasion et par oracle dans un article dédié au sujet. 

Qu’en est-il de ces risques pour les entreprises industrielles ?  

En réalité, les risques liés à l’IA dans l’industrie varient considérablement selon le secteur et l’utilisation qui en est faite. 

Pour mener des attaques par oracle, manipulation et injection de prompt contre une IA, il est nécessaire de pouvoir interagir avec elle en lui fournissant des données d’entrée. Cela est possible avec certaines IA génératives, comme ChatGPT, qui nécessitent des requêtes textuelles. En revanche, d’autres systèmes, tels que ceux utilisés pour la maintenance prédictive (solutions permettant d’anticiper et de prévenir les pannes d’équipements), ne dépendent pas d’instructions humaines pour fonctionner, rendant les interactions plus complexes. De plus, les types de données d’entrée de ces systèmes sont souvent très spécifiques, difficiles à obtenir, et à manipuler. 

Des attaques par empoisonnement des données d’entraînement pourraient être réalisées sur ces systèmes. Cependant, cela nécessiterait d’abord de s’introduire dans les SI, comprendre en profondeur le fonctionnement de l’IA, puis de tenter d’altérer son comportement, sans garantie de succès. De plus, les entreprises dotées d’un bon niveau de cybersécurité disposent déjà de contre-mesures et de moyens de protection, réduisant considérablement les chances de réussite d’une telle attaque. 

En comparaison, d’autres méthodes ne ciblant pas spécifiquement l’IA sont plus simples à mettre en place et peuvent augmenter les chances d’un attaquant de causer des dommages à une entreprise. 

Toutefois, d’autres applications de l’IA sont vulnérables à ces types d’attaques. Par exemple, un assistant utilisant de l’IA générative, avec lequel un humain peut interagir, est susceptible de subir des manipulations ou des injections de données.  

Voici un exemple de scénario d’attaque sur l’assistant à la production de vaccins présenté en Figure 3. 

Contexte du cas d’usage 

Les employés écrivent leur demande à l’assistant et y joignent les spécifications du vaccin à produire. Celui-ci lance l’analyse et, à l’aide d’un module RAG (permet à l’IA de disposer de données supplémentaires sans réentrainement), croise ces informations avec la base de données de l’entreprise. Enfin, l’assistant retourne aux employés un fichier d’instructions pour les machines qu’ils peuvent directement pour lancer une production.  

Scénario d’attaque 

Figure 5 – Kill chain scénario d’attaque sur assistant à la production de vaccins 

Les suites d’un cas de vol de secrets industriels comme celui-ci peuvent-être la revente de ces informations à des concurrents, ou encore leur divulgation publique, pouvant entraîner d’importantes conséquences financières et sur la réputation de l’entreprise. Cependant, des mesures de sécurité classiques de gestion des accès permettent de réduire le risque de subir ce type d’attaque. 

En outre, bien que certaines applications de l’IA soient vulnérables à de nouvelles attaques, des mesures de sécurité spécifiques et adaptées aux faiblesses de chaque système permettent de maintenir une protection efficace. 

Alors que faut-il retenir ?  

En fin de compte, les risques associés aux technologies d’IA ne sont pas fondamentalement nouveaux. 

Bien que certains systèmes d’IA soient sensibles à de nouvelles attaques, les principes de cybersécurité permettant de s’en protéger et de limiter les impacts restent inchangés. 

Il reste donc essentiel d’adopter une approche par les risques et d’intégrer la sécurité dès la conception de toute application d’IA (cybersecurity by design).  

Cet article Intelligence artificielle, industrie, risques cyber : où en sommes-nous ? est apparu en premier sur RiskInsight.