OT et IoT

Oui, à partir de l'offre Pro. NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm par capture passive sur un port SPAN ou TAP. Les équipements classés OT ne sont jamais interrogés activement : aucun risque pour les automates (API/PLC) ni les systèmes SCADA.

Oui, avec une surveillance passive : le capteur lit une copie du trafic sur un port SPAN ou un TAP et n'envoie jamais rien aux automates. NetSenX fonctionne ainsi à partir de l'offre Pro et ne sonde jamais activement les équipements classés OT.

Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm, à partir d'une capture passive, dans l'offre Pro et au-delà.

Aucune appliance NetSenX n'est nécessaire : l'agent est un logiciel qui tourne sur l'hôte de votre choix. Un agent relié à un port SPAN ou TAP observe tout le segment et compte pour un seul appareil.

NIS2 vise les entités de secteurs comme l'énergie, les transports, l'eau potable, la santé et la fabrication de certains produits (annexes I et II de la directive (UE) 2022/2555). Les mesures de son article 21 portent sur les réseaux et systèmes d'information qu'une entité utilise pour ses activités, ce qui peut inclure l'OT. Vérifiez le périmètre auprès de votre autorité nationale.

La surveillance passive ne le peut pas : elle écoute seulement une copie du trafic et n'envoie jamais rien aux automates. Le balayage actif est une autre affaire : certains automates programmables et unités de télétransmission anciens plantent, redémarrent ou passent en défaut lorsqu'un outil de découverte ou un scanner de vulnérabilités les interroge, et c'est pourquoi beaucoup d'usines tiennent les scanners à l'écart du réseau de contrôle-commande. Prenez la copie sur un port SPAN d'un commutateur industriel ou sur un TAP réseau passif, et vérifiez auprès du fabricant du commutateur que la recopie ne surchargera pas un vieux modèle. NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm par capture passive, à partir de l'offre Pro, et ne sonde jamais activement les équipements classés OT. Rien n'est installé sur les automates et aucun de leurs réglages ne change.

Oui. Caméras, imprimantes, contrôleurs de porte, écrans et capteurs sont souvent anciens, rarement mis à jour et impossibles à équiper d'un agent, ce qui en fait une porte d'entrée fréquente et une bonne cachette pour un attaquant déjà présent. Commencez par les étapes gratuites : recensez-les, changez les mots de passe par défaut, mettez à jour le micrologiciel, désactivez les fonctions cloud inutilisées et placez-les sur un segment réseau dédié, avec des règles qui n'autorisent que le nécessaire. La surveillance vous dit ensuite si ces règles tiennent. Un capteur sur ce segment voit leur trafic sans toucher aux appareils ; NetSenX détecte leur balayage, leur beaconing et leurs volumes sortants inhabituels, dans chaque offre, et la carte réseau liste les appareils qu'il voit communiquer. Un appareil muet, ou placé sur un segment non recopié, reste hors de vue.

Moindre, mais oui. Un réseau local virtuel (VLAN) séparé n'aide que si les règles entre lui et le reste du réseau sont strictes, or caméras et enregistreurs reçoivent souvent de larges exceptions pour que le personnel puisse regarder les images depuis n'importe quel PC ou téléphone. Ils ont aussi souvent besoin d'Internet pour leurs applications et mises à jour, ce qui constitue également une sortie pour un attaquant. N'autorisez que le poste de visualisation ou le serveur vidéo à joindre les caméras, empêchez le VLAN des caméras d'atteindre tout le reste, bloquez l'accès Internet dont elles n'ont pas besoin, changez les mots de passe par défaut et mettez à jour le micrologiciel. Un capteur sur ce VLAN voit leur trafic ; NetSenX détecte leur balayage, leur beaconing et leurs volumes sortants inhabituels, dans chaque offre, si bien qu'une caméra qui se met à contacter de nouvelles destinations se remarque.

En surveillant le trafic vers et depuis les automates, car un automate programmable (API) ne tient pratiquement aucun journal de sécurité. Les signaux utiles sont simples : une écriture ou un téléchargement de programme depuis un ordinateur qui n'est pas votre poste d'ingénierie, un ordre d'arrêt ou de démarrage imprévu, des PC de bureau qui parlent directement aux automates, et une activité la nuit ou le week-end quand personne ne travaille sur la ligne. Commencez par les étapes gratuites : listez les postes autorisés à programmer chaque automate, vérifiez que le réseau bureautique n'atteint pas le réseau de contrôle-commande et laissez les sélecteurs de mode en position RUN lorsque votre matériel en possède. À partir de l'offre Pro, NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm depuis un port SPAN ou TAP et émet quatre types d'alertes OT : écritures non autorisées, trafic franchissant les niveaux du réseau de l'usine, activité OT hors des heures de travail et commandes S7comm. Il ne sonde jamais les automates et ne voit ni les liaisons série ni les segments non recopiés.

Parce qu'il n'a ni authentification ni chiffrement : tout équipement qui peut joindre un automate Modbus/TCP peut lire ses valeurs et, sauf si l'automate le limite lui-même, écrire dans ses bobines et registres. Modbus a été conçu en 1979 pour des liaisons série entre équipements de confiance, bien avant que les réseaux de contrôle-commande soient reliés aux réseaux bureautiques et à Internet. Une variante sécurisée avec TLS existe, mais peu d'équipements installés la prennent en charge. En pratique, on protège Modbus de l'extérieur : le port 502 ne doit pas être exposé sur Internet, seuls des hôtes d'ingénierie et SCADA désignés doivent atteindre les automates, et toute protection en écriture offerte par l'automate mérite d'être utilisée. Comme le trafic n'est pas chiffré, un capteur passif peut lire quel poste lit ou écrit sur quel automate. NetSenX le fait à partir de l'offre Pro et alerte lorsqu'un hôte non autorisé envoie une écriture ; il ne modifie pas le protocole et ne bloque pas la commande.

Il vous faut un outil qui lit le protocole industriel sur le réseau et sait quels hôtes ont le droit d'écrire, car l'automate accepte normalement l'écriture sans broncher et ne journalise rien. Notez d'abord quels postes doivent pouvoir modifier un réglage : en général une ou deux stations d'ingénierie et les serveurs SCADA ou IHM. Faites ensuite respecter cette liste par le réseau là où c'est possible, avec des règles de pare-feu qui ne laissent que ces hôtes joindre les automates. La surveillance couvre ce que les règles laissent passer : un portable branché sur la ligne, un PC de bureau avec une route oubliée, un logiciel malveillant sur un poste autorisé. À partir de l'offre Pro, NetSenX lit les requêtes d'écriture par capture passive sur un port SPAN ou TAP et alerte lorsqu'une écriture provient d'un hôte non autorisé, en indiquant la source, l'automate, la fonction et l'heure. Il n'enregistre ni la valeur écrite ni la personne au clavier.

Celles qui signifient qu'un changement a eu lieu dans le procédé : une écriture ou un téléchargement de programme depuis un ordinateur inattendu, un automate arrêté, démarré ou passé dans un autre mode, du trafic bureautique qui atteint le niveau contrôle-commande, et tout cela en dehors des heures de travail. Ces événements sont rares en fonctionnement normal, chacun mérite donc un appel à la personne responsable de la ligne. Les alertes sur les volumes ou les nouvelles destinations comptent aussi, mais côté informatique, là où commencent la plupart des attaques contre les usines. Décidez à l'avance qui reçoit les alertes OT, en combien de temps quelqu'un les regarde, et que personne ne déconnecte un poste de production sans l'accord du chef d'équipe, car une coupure brutale peut coûter plus que l'alerte. À partir de l'offre Pro, NetSenX émet précisément ces alertes OT : écritures non autorisées, trafic franchissant les niveaux du réseau de l'usine, activité OT hors des heures de travail et commandes S7comm, en plus des alertes de beaconing, balayage, mouvement latéral et volume sortant inhabituel qu'il émet sur toutes les offres.

En combinant un relevé des moments où vos ingénieurs travaillent réellement sur les automates avec un capteur qui voit les téléchargements de programme et les écritures sur le réseau. Un changement de programme à 2 h un dimanche ne prouve pas une attaque, car la maintenance a souvent lieu ligne arrêtée, mais quelqu'un doit pouvoir l'expliquer le lendemain matin. Tenez un registre des modifications simple avec les fenêtres de maintenance prévues, comparez-le avec ce que montre le réseau, et conservez hors ligne une copie validée du programme de chaque automate pour pouvoir comparer et restaurer. Certains automates savent aussi signaler une modification de programme au SCADA. À partir de l'offre Pro, NetSenX signale l'activité OT hors des heures de travail et décode les requêtes S7comm, par exemple le téléchargement d'un bloc de programme avec son nom, depuis un port SPAN ou TAP. Il ne lit pas le contenu du programme et ne compare pas les versions ; c'est le rôle de votre logiciel d'ingénierie.

Oui, lorsque l'ordre d'arrêt passe sur le réseau en S7comm, le protocole qu'utilisent les automates Siemens S7 pour la programmation et le diagnostic. S7comm n'est pas chiffré, si bien qu'un capteur passif qui reçoit une copie du trafic peut décoder la requête comme un arrêt, avec l'ordinateur qui l'a envoyée et l'heure. Un arrêt fait avec le sélecteur ou le panneau de l'automate lui-même ne passe jamais par le réseau, aucun capteur ne le voit donc. Les automates récents peuvent utiliser un successeur protégé, S7comm-plus ; interrogez-nous avant de compter sur NetSenX pour ce trafic. À partir de l'offre Pro, NetSenX décode les requêtes S7comm en noms de commandes, comme l'arrêt de l'automate, l'écriture d'une variable ou le téléchargement d'un bloc de programme, et émet une alerte de commande S7comm depuis un port SPAN ou TAP, sans rien envoyer à l'automate. Il informe vos ingénieurs ; il ne bloque pas la commande.

Elle peut montrer quel ordinateur a envoyé l'écriture et quand, ce qui suffit généralement pour retrouver la personne. La plupart des protocoles industriels ne transportent aucun nom d'utilisateur, le réseau ne connaît donc que l'adresse source. Le lien avec une personne se fait grâce à la traçabilité de l'IHM ou du SCADA, au journal du logiciel d'ingénierie et au planning des équipes. Pour que ce soit possible plus tard, donnez à chaque poste d'ingénierie une adresse fixe, exigez des connexions nominatives sur les IHM et le SCADA et conservez leurs journaux aussi longtemps que vos enregistrements qualité. À partir de l'offre Pro, NetSenX lit les écritures par capture passive sur un port SPAN ou TAP et, lorsque l'auteur n'est pas autorisé à écrire, émet une alerte avec l'hôte source, l'automate, le code de fonction et l'heure. Il n'enregistre pas la valeur écrite et n'identifie jamais une personne : il observe des appareils et des connexions, pas des personnes.

Non. NetSenX enregistre qu'une écriture a eu lieu, depuis quel hôte, vers quel automate, avec quel code de fonction et à quelle heure, mais ni la valeur écrite ni le contenu d'un bloc de programme. C'est une limite voulue : les valeurs de procédé et les programmes sont votre savoir-faire, et une alerte a besoin du qui et du quand, pas de la recette. Si vous avez besoin des valeurs, par exemple pour reconstituer un lot défectueux, elles viennent de l'historian, de la traçabilité du SCADA ou de l'IHM, ou du diagnostic de l'automate. Préparez-le avant d'en avoir besoin : vérifiez combien de temps votre historian conserve les données et si les modifications faites sur l'IHM sont journalisées avec un nom d'utilisateur. NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm par capture passive, à partir de l'offre Pro, et n'envoie jamais rien aux équipements.

Oui, comme une source de preuve parmi d'autres. Une alerte OT indique qu'un automate a reçu une écriture d'un hôte non autorisé, une commande S7comm ou du trafic hors des heures de travail, avec l'hôte source, l'automate et l'heure. Placez-la sur une chronologie à côté des données de l'historian, de la traçabilité de l'IHM, du cahier de quart et des rapports de maintenance, et vous pourrez en général préciser quand et d'où est venu un changement. Assurez-vous que les horloges concordent, car quelques minutes d'écart entre systèmes rendent une chronologie trompeuse. Gardez aussi en tête ce que les alertes ne couvrent pas : une écriture autorisée pendant le quart ne déclenche aucune alerte, la traçabilité de l'IHM reste donc votre trace des changements courants. NetSenX conserve les alertes pendant la durée d'historique de votre offre ; vous les consultez dans le tableau de bord, par l'API à partir de l'offre Pro ou dans votre SIEM à partir de l'offre Business. Elles ne contiennent aucune valeur écrite et ne nomment personne.

Non. NetSenX lit cinq protocoles industriels, Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm, mais il n'existe pas d'alerte d'anomalie propre à chaque protocole, par exemple pour un polling Modbus inhabituel ou un trafic BACnet étrange. Ses alertes OT sont de quatre types qui s'appliquent à tout ce qu'il lit : une écriture vers un automate depuis un hôte non autorisé, un trafic qui franchit les niveaux du réseau de l'usine, une activité OT hors des heures de travail et des commandes S7comm comme un arrêt ou un téléchargement de programme. Les détections générales surveillent en plus les mêmes hôtes : beaconing, balayage, mouvement latéral et volume sortant inhabituel. Si votre analyse de risques exige une détection d'anomalies approfondie et spécifique à un protocole, par exemple pour la téléconduite d'un gestionnaire de réseau, demandez-nous ce qui est couvert avant de vous y fier, ou utilisez un outil OT spécialisé à côté de NetSenX. Les fonctions OT sont disponibles à partir de l'offre Pro.

Non. NetSenX écoute une copie du trafic et informe vos ingénieurs ; il n'est pas placé sur le chemin des paquets, il ne peut donc en supprimer aucun, et il n'agit jamais sur le procédé. C'est voulu : un équipement en ligne qui bloque des commandes industrielles peut arrêter une ligne par erreur, et NetSenX n'est pas un système de sécurité fonctionnelle. La protection contre les commandes dangereuses vient d'autres couches : un pare-feu entre zones qui n'autorise que des hôtes désignés, la protection en écriture et les sélecteurs de mode des automates, et un système instrumenté de sécurité indépendant du réseau de contrôle-commande. Ce que NetSenX apporte, à partir de l'offre Pro, c'est l'alerte quand un hôte qui ne devrait pas écrire le fait, quand un automate reçoit une commande S7comm comme un arrêt, ou quand du trafic OT apparaît la nuit, pour que quelqu'un vérifie avant le début du quart suivant.

Pas aujourd'hui. NetSenX lit cinq protocoles industriels par capture passive, à partir de l'offre Pro : Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm. Le reste du trafic industriel d'un segment surveillé reste visible sous forme de connexions entre hôtes : le beaconing, le balayage, le mouvement latéral et le volume sortant inhabituel s'appliquent toujours, et la carte réseau liste toujours les appareils. Ce qui manque, c'est le décodage des commandes de ce protocole, si bien que les alertes OT sur les écritures et les commandes ne le couvrent pas. Si votre usine fonctionne surtout en PROFINET, en OPC UA ou avec le protocole de téléconduite IEC 60870-5-104, dites-le-nous avant d'acheter et demandez ce qui serait couvert sur votre réseau, ou associez NetSenX à un outil qui décode ces protocoles. Mieux vaut le savoir maintenant que découvrir la lacune pendant un audit.

Non. Un capteur réseau voit le trafic Ethernet et IP qui lui est recopié. Les liaisons série comme Modbus RTU sur RS-485, Profibus DP et les autres bus de terrain n'atteignent jamais Ethernet, leurs commandes sont donc hors de sa vue. Il voit en revanche la passerelle qui fait la traduction entre Ethernet et le bus série : qui lui parle, quand et à quelle fréquence. Dans beaucoup d'usines, c'est un signal utile, car quiconque veut atteindre un équipement série depuis le réseau doit passer par cette passerelle. Recensez vos passerelles, protégez-les comme des automates et recopiez le segment sur lequel elles se trouvent. NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm par capture passive, à partir de l'offre Pro. Côté série, appuyez-vous sur le diagnostic des automates eux-mêmes et sur des armoires fermées à clé.

Cela signifie que le capteur n'envoie jamais un paquet à un équipement classé OT : aucun balayage de découverte, aucun balayage de ports, aucune requête de protocole, aucune tentative de connexion. Il lit seulement une copie du trafic que vos systèmes échangent déjà, prise sur un port SPAN ou un TAP réseau. Les outils actifs fonctionnent autrement : ils posent des questions à chaque équipement, et certains automates, unités de télétransmission et IHM anciens réagissent mal aux requêtes inattendues, du ralentissement au plantage. Pour un directeur d'usine, cela veut dire concrètement que la mise en service de NetSenX n'ajoute aucun trafic au réseau de contrôle-commande et ne peut pas changer l'état d'un automate, si bien qu'aucune fenêtre de maintenance n'est nécessaire sur les automates eux-mêmes. La contrepartie : un capteur passif ne connaît que ce que les équipements disent. Un automate qui ne communique jamais sur un segment recopié n'est pas vu. La surveillance OT est disponible à partir de l'offre Pro.

Non. La surveillance passive ne demande aucun logiciel, aucune modification de configuration ni de micrologiciel sur les automates, les IHM ou les variateurs. Le changement se fait sur le réseau : un port SPAN (miroir) sur un commutateur administrable, ou un TAP passif sur un câble, envoie une copie du trafic à un petit ordinateur qui fait tourner le capteur. Préparez ce changement comme tout autre sur le réseau de production : validez-le avec l'ingénieur OT, vérifiez que le commutateur peut recopier les ports nécessaires sans surcharge et faites-le pendant une fenêtre de maintenance si vos règles l'exigent. Décidez ensuite où se trouve l'hôte du capteur et comment il envoie ses alertes, idéalement par une règle de pare-feu qui n'autorise que cela. Avec NetSenX, l'agent tourne sur un hôte Linux de votre choix et lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm à partir de l'offre Pro ; un agent sur un port miroir compte pour un seul appareil.

Utilisez un TAP réseau, ou ajoutez un commutateur administrable là où vous avez besoin de visibilité. Les commutateurs non administrables, fréquents dans les armoires de machines, ne savent pas recopier le trafic. Un TAP est un petit boîtier inséré sur un câble, par exemple la liaison entre le commutateur de ligne et le cœur de réseau de l'usine, qui copie le trafic dans les deux sens vers un port de surveillance sans être visible sur le réseau. Beaucoup de modèles maintiennent la liaison même en cas de coupure d'alimentation ; vérifiez-le pour celui que vous achetez. Choisissez la liaison qui transporte le trafic le plus important pour vous : entre bureau et production, ou entre les serveurs SCADA et les automates. Le trafic entre deux équipements branchés sur le même commutateur non administrable ne passe jamais par cette liaison et reste invisible. NetSenX fonctionne sur un port SPAN ou sur un TAP ; un agent y compte pour un seul appareil, et les protocoles OT sont lus à partir de l'offre Pro.

Oui. Tout ce que la machine fait sur le réseau peut être observé de l'extérieur, à partir d'une copie de son trafic prise sur un port SPAN ou un TAP. C'est l'approche habituelle pour les automates, les IHM, les bancs d'essai, les dispositifs médicaux et tout système dont le fournisseur interdit les modifications ou y lie sa garantie. Vous voyez son comportement : avec quels hôtes il communique, à quelles heures, quelle quantité de données et, pour les protocoles industriels décodés, ce qu'il demande aux automates. Vous ne voyez pas ce qui se passe à l'intérieur : fichiers, processus et connexions locales restent cachés, tout comme le trafic des liaisons non recopiées. NetSenX fonctionne ainsi : un agent sur un port miroir observe tout le segment et compte pour un seul appareil. Le beaconing, le balayage, le mouvement latéral et le volume sortant inhabituel sont détectés sur toutes les offres ; les protocoles et alertes OT viennent avec l'offre Pro.

Oui. La plupart des attaques qui arrêtent la production commencent dans le réseau bureautique, par un e-mail, un mot de passe volé ou l'accès d'un prestataire, et un réseau à plat les laisse atteindre directement les automates. Séparer ne veut pas forcément dire isoler physiquement. La conception habituelle place un pare-feu entre bureau et production, avec une petite zone démilitarisée (DMZ) entre les deux pour les systèmes dont les deux côtés ont besoin, comme une copie de l'historian, un serveur de correctifs ou la passerelle d'accès distant, et sans connexion directe d'un PC de bureau vers un automate. Commencez par lister les flux dont la production a réellement besoin, n'autorisez qu'eux et journalisez ce qui est refusé. Vérifiez ensuite que la séparation tient en pratique, car les exceptions s'accumulent. À partir de l'offre Pro, NetSenX émet une alerte lorsque du trafic franchit les niveaux du réseau de l'usine, par exemple d'un poste de bureau directement vers un automate, depuis un port SPAN ou TAP.

Le modèle Purdue est une architecture de référence qui range les systèmes d'une usine par niveaux : le procédé physique et ses capteurs en bas, les automates au-dessus, puis les systèmes de supervision comme les IHM et le SCADA, ensuite l'exploitation du site avec l'historian et la planification de production, et le réseau de gestion tout en haut. La règle qui compte est que chaque niveau communique surtout avec ses voisins et que le trafic entre gestion et production passe par une frontière contrôlée, généralement une DMZ. Un trafic qui saute des niveaux, comme un PC de bureau qui parle directement à un automate, est soit une erreur de conception, soit quelque chose qu'un attaquant utilise, et c'est l'un des signaux d'alerte les plus nets en OT. Beaucoup d'usines réelles ne collent pas parfaitement au modèle, et ce n'est pas grave ; l'important est de savoir quels passages sont voulus. À partir de l'offre Pro, NetSenX signale le trafic qui franchit les niveaux Purdue, par capture passive.

Testez, puis observez. Pour le test, prenez un portable de bureau ordinaire et, avec l'accord de l'ingénieur OT, essayez d'ouvrir une connexion vers l'adresse et le port d'un automate ainsi que vers les serveurs IHM et SCADA ; utilisez un simple test de connexion, jamais un scanner, face à des équipements de production. Passez en revue les règles du pare-feu entre bureau et production à la recherche d'autorisations trop larges et de vieilles exceptions que personne ne sait expliquer. Observez ensuite le trafic réel pendant quelques semaines, car les chemins qui comptent sont souvent les oubliés : un PC avec une carte réseau dans chaque réseau, le VPN d'un prestataire qui aboutit en production, un pont sans fil. À partir de l'offre Pro, NetSenX signale le trafic qui franchit les niveaux du réseau de l'usine, comme un poste de bureau qui atteint un automate, de sorte qu'un chemin qui ne devrait pas exister apparaît dès sa première utilisation. Un chemin qui existe mais n'est jamais emprunté reste invisible pour tout capteur passif.

Oui, et c'est la façon la plus courante dont un incident cyber arrête la production, même quand les machines elles-mêmes sont intactes. Les lignes dépendent de systèmes informatiques pour les commandes, les recettes, les étiquettes, les expéditions et les enregistrements qualité ; quand l'ERP, le serveur d'étiquettes ou les partages de fichiers sont chiffrés, beaucoup d'usines préfèrent s'arrêter plutôt que produire sans traçabilité. D'autres arrêtent la production par précaution le temps de savoir jusqu'où l'attaquant est allé. Protéger la production commence donc côté informatique : listez les systèmes dont chaque ligne a besoin, prévoyez comment fonctionner une journée sans eux, gardez des sauvegardes hors ligne de ces systèmes et testez leur restauration. NetSenX surveille, sur toutes les offres, les étapes côté informatique qui précèdent le chiffrement : beaconing, balayage, mouvement latéral et volume sortant inhabituel. À partir de l'offre Pro, il affiche le trafic OT dans le même tableau de bord. Il n'arrête pas les rançongiciels ; il vous donne le temps d'agir.

Traitez-les comme des visiteurs munis d'une clé : admis pour une intervention, par un port connu, et observés tant qu'ils sont là. Convenez avec chaque constructeur de machines et intégrateur du portable qui peut se connecter, où et pour quoi faire. Donnez-leur un port ou un VLAN de maintenance dédié qui n'atteint que leur machine, plutôt que n'importe quelle prise libre du commutateur de ligne, et désactivez ce port une fois l'intervention terminée. Demandez que le portable soit contrôlé contre les logiciels malveillants avant branchement, ou prêtez-leur un portable de l'entreprise équipé du logiciel d'ingénierie, ce que beaucoup d'usines préfèrent. Tenez un court registre des visites : qui, quand, quelle machine. Côté réseau, le portable apparaît comme un nouvel appareil sur la carte réseau de NetSenX, sur toutes les offres, et s'il balaie le réseau ou se met à parler à de nombreux hôtes, les alertes de balayage et de mouvement latéral se déclenchent. À partir de l'offre Pro, une écriture vers un automate depuis un hôte non autorisé déclenche une alerte OT.

Oui, si le segment utilisé par le portable est recopié vers un capteur : chacune de ses connexions est passée par le réseau et peut être listée ensuite d'après son adresse. Cela répond à la question que directeurs d'usine et auditeurs posent après une visite : le portable n'a-t-il touché que la machine pour laquelle il est venu ? Facilitez-vous la tâche en donnant aux visiteurs des adresses d'une plage connue ou un VLAN de maintenance dédié, pour que leur trafic se distingue facilement du vôtre. Sur la carte réseau de NetSenX, sur toutes les offres, le portable apparaît comme un appareil avec les hôtes auxquels il a parlé et ses dates de première et dernière apparition. À partir de l'offre Pro, NetSenX décode aussi Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm, si bien que les écritures d'un hôte non autorisé et les commandes S7comm déclenchent des alertes OT. Une connexion passée par le routeur 4G du constructeur ou par un commutateur non recopié dans la machine ne traverse jamais votre réseau surveillé et n'est pas vue.

Par un point d'entrée unique et contrôlé qui vous appartient, activé seulement quand il le faut. Concrètement : une passerelle d'accès distant ou un serveur de rebond dans la DMZ entre bureau et production, une authentification multifacteur pour chaque compte fournisseur, un compte nominatif par technicien plutôt qu'un compte partagé, un accès limité aux machines que ce fournisseur entretient, des sessions ouvertes sur demande puis refermées, et des journaux ou enregistrements de ce qui a été fait. Une fois ce chemin en place, retirez les outils permanents des fournisseurs, comme les applications de bureau à distance sur les IHM et les routeurs 4G dans les armoires. NIS2 attend aussi des mesures de sécurité de la chaîne d'approvisionnement : inscrivez donc ces règles dans les contrats. Sur le réseau, une session fournisseur apparaît comme des connexions de la passerelle vers la production ; NetSenX y détecte balayage et mouvement latéral sur toutes les offres et, à partir de l'offre Pro, les écritures d'hôtes non autorisés. NetSenX ne décide pas qui obtient un accès ; c'est votre passerelle qui le fait.

Oui. Un routeur cellulaire installé pour la télémaintenance relie la machine à Internet par le réseau mobile, en contournant entièrement votre pare-feu, si bien qu'aucune de vos règles, aucun journal ni aucun contrôle VPN ne s'y applique. Si le portail du fournisseur ou le routeur lui-même est compromis, ou si son mot de passe par défaut n'a jamais été changé, un attaquant arrive sur votre réseau de production. Beaucoup de ces routeurs ne figurent sur aucun schéma, parce qu'ils sont arrivés avec la machine. Demandez par écrit à chaque fournisseur de machines si son équipement contient un modem ou un routeur cellulaire, inspectez les armoires, puis retirez-le, laissez-le éteint jusqu'à ce qu'une session de maintenance soit planifiée, ou remplacez-le par votre propre chemin d'accès distant contrôlé. Un capteur réseau ne peut pas voir la liaison 4G elle-même, puisque ce trafic ne traverse jamais votre réseau ; il voit seulement le côté LAN du routeur, si ce segment lui est recopié.

En regardant à la fois les armoires et le réseau. Physiquement : ouvrez les armoires des machines lors du prochain arrêt programmé et cherchez de petits routeurs, modems et antennes, et demandez à chaque fournisseur la liste des équipements de communication de ses machines. Sur le réseau : cherchez les appareils qui se comportent comme des passerelles, par exemple une machine dont le trafic part vers une adresse qui n'est pas votre routeur, un appareil qui distribue ses propres adresses, ou un hôte qui reçoit des connexions de l'extérieur à des moments où personne de chez vous n'en a lancé. Un appareil qui figure sur votre carte réseau mais sur aucun schéma mérite une question. La carte réseau de NetSenX, sur toutes les offres, liste les appareils qu'il voit communiquer sur les segments surveillés avec leurs dates de première et dernière apparition, et les appareils qui appellent l'extérieur à intervalles réguliers sont signalés comme beaconing. Un routeur qui ne parle que par sa liaison cellulaire et reste muet sur votre LAN ne se trouve pas depuis le réseau ; c'est l'inspection des armoires qui le trouve.

En l'entourant de protections, puisque vous ne pouvez pas le corriger. Pupitres opérateur, IHM et ordinateurs de bancs d'essai tournent souvent sur un système d'exploitation que l'éditeur ne prend plus en charge, et le fournisseur de la machine interdit toute modification. Retirez-le de tout réseau dont il n'a pas besoin, bloquez son accès à Internet, n'autorisez que les connexions nécessaires vers les automates et serveurs avec lesquels il travaille, désactivez les ports USB et les services inutiles si le fournisseur le permet, utilisez une liste blanche d'applications si l'éditeur la prend en charge, et gardez une image testée pour pouvoir le reconstruire. Demandez au fournisseur une voie de migration et consignez le risque résiduel. Surveillez-le ensuite depuis le réseau, puisque rien ne peut y être installé : NetSenX voit ses connexions depuis un port SPAN ou TAP et détecte beaconing, balayage, mouvement latéral et volume sortant inhabituel sur toutes les offres et, à partir de l'offre Pro, les écritures vers les automates depuis des hôtes non autorisés. Il ne voit pas ce qui s'exécute à l'intérieur du PC.

C'est une mesure qui réduit un risque qu'on ne peut pas supprimer à la source. Quand un automate ne peut pas être mis à jour, n'a pas de mot de passe ou tourne sur un système obsolète, on le protège de l'extérieur : segmentation et règles de pare-feu pour que seuls des hôtes désignés l'atteignent, aucun accès Internet, un chemin d'accès distant contrôlé, des armoires fermées, des sauvegardes hors ligne des programmes et configurations, et une surveillance qui signale quand la protection est contournée. Les auditeurs qui travaillent avec l'IEC 62443 ou la gestion des risques de NIS2 attendent en général que ces mesures soient documentées : quel risque, quelle mesure, qui en est responsable et comment vous vérifiez qu'elle fonctionne toujours. La surveillance est la partie qui produit cette preuve de vérification. NetSenX peut la fournir : depuis un port SPAN ou TAP, il montre qui communique avec le système ancien et, à partir de l'offre Pro, émet des alertes OT pour les écritures non autorisées, le trafic franchissant les niveaux du réseau de l'usine, l'activité hors des heures de travail et les commandes S7comm.

En combinant trois sources passives : ce que disent vos documents, ce que savent vos outils d'ingénierie et ce que montre le réseau. Commencez par les schémas, les fichiers de projet d'ingénierie, qui listent chaque automate, variateur et module d'entrées/sorties déportées configurés, et la documentation fournisseur de chaque machine. Parcourez ensuite l'usine : armoires, pupitres, sites distants. Ajoutez enfin ce que montre le trafic : un capteur passif sur un port miroir voit chaque appareil qui communique sur ce segment, y compris ceux que personne n'a notés. Pour chaque actif, consignez son adresse, sa fonction, son responsable, sa version de micrologiciel et s'il peut être mis à jour. La carte réseau de NetSenX, sur toutes les offres, liste les appareils vus sur les segments surveillés avec les noms qu'ils annoncent et leurs dates de première et dernière apparition, et à partir de l'offre Pro NetSenX lit Modbus/TCP, DNP3, BACnet/IP, EtherNet/IP et S7comm. Il ne sonde jamais les équipements OT et ne relève donc pas les versions de micrologiciel ; vos outils d'ingénierie les fournissent.

Ceux qui ne communiquent pas sur un segment recopié. Cela comprend les équipements muets la plupart du temps, comme un automate de réserve ou un module qui ne répond qu'à un maître que vous ne voyez pas ; les équipements sur des bus de terrain série comme Modbus RTU ou Profibus ; ceux qui se trouvent derrière un commutateur non administrable dont le trafic n'atteint jamais la liaison recopiée ; les machines qui ne communiquent que par leur propre routeur cellulaire ; et les sites distants sans capteur. La surveillance passive voit aussi moins de choses dans les protocoles chiffrés et ne peut pas lire une version de micrologiciel que l'équipement n'annonce pas. Comblez ces lacunes par une visite de terrain, les fichiers de projet d'ingénierie et, si l'usine l'accepte, une interrogation soigneusement planifiée avec les outils du fabricant pendant une fenêtre de maintenance. NetSenX est uniquement passif : sa carte réseau montre ce qui communique sur les segments surveillés, et rien de plus.

En général d'un par segment réseau que vous voulez observer sur chaque site, soit le plus souvent un à trois par usine. Le nombre dépend des endroits où le trafic peut être copié : un port SPAN sur le commutateur de cœur d'une usine voit souvent le trafic entre bureau et production et entre les serveurs SCADA et les commutateurs de ligne, alors que le trafic interne au commutateur d'une machine demande un capteur ou un TAP plus près d'elle. Commencez par la frontière entre bureau et production de chaque usine, puis ajoutez les segments où les automates sont programmés. Chaque usine a besoin d'un petit hôte pour le capteur et d'un moyen d'envoyer les alertes vers l'extérieur. Avec NetSenX, chaque agent sur un port SPAN ou TAP compte pour un seul appareil pour tout le segment qu'il observe, toutes les usines apparaissent dans un même tableau de bord, et les protocoles OT sont lus à partir de l'offre Pro. La page des tarifs indique combien d'appareils chaque offre comprend.

Oui, si quelqu'un a le temps de les faire vivre. Il existe des outils open source matures de surveillance réseau capables de lire plusieurs protocoles industriels depuis un port SPAN. Le coût n'est pas la licence mais le travail : installer et mettre à jour les capteurs, écrire ou ajuster des règles pour votre usine, stocker les journaux, construire des tableaux de bord et surtout avoir quelqu'un qui regarde les alertes. Dans une usine dotée d'un ingénieur OT qui aime ce travail, cela peut être un bon début. Si personne n'a ce temps, les journaux s'accumulent sans être lus, ce qui donne l'impression d'une surveillance sans son résultat. NetSenX est l'alternative gérée : un agent sur un port SPAN ou TAP, des alertes expliquées en langage clair et les protocoles OT à partir de l'offre Pro, sans règles à entretenir de votre côté. Quel que soit votre choix, commencez par la frontière entre bureau et production.

L'IEC 62443 est une série de normes internationales sur la sécurité des systèmes d'automatisation et de contrôle industriels. Elle couvre le programme de sécurité de l'exploitant, les obligations des intégrateurs et prestataires, les exigences pour un système entier découpé en zones et conduits, et les exigences pour les produits eux-mêmes, avec des niveaux de sécurité qui décrivent face à quel attaquant une zone doit tenir. Elle est volontaire : la loi n'oblige pas un fabricant ordinaire à se faire certifier, mais clients, assureurs et auditeurs s'en servent de plus en plus comme référence, et son approche par zones et conduits est une manière pratique d'organiser les mesures de gestion des risques NIS2 dans une usine. Pas besoin de certification pour en tirer parti : découpez l'usine en zones, recensez les conduits entre elles et décidez de ce que chacun peut transporter. La surveillance vérifie ensuite les conduits en pratique. NetSenX peut apporter cette preuve : à partir de l'offre Pro, il lit les protocoles industriels de façon passive et signale le trafic qui franchit les niveaux du réseau de l'usine.

En général la preuve que la détection existe, couvre les bons endroits et débouche sur des actions : quels segments OT sont surveillés et comment, quels types d'événements sont détectés, qui examine les alertes et en combien de temps, des exemples d'alertes traitées avec la décision prise, et la durée de conservation des enregistrements. En Allemagne, l'Office fédéral de la sécurité des technologies de l'information (BSI) a publié des orientations sur les systèmes de détection d'attaques destinées aux opérateurs d'infrastructures critiques, que les auditeurs utilisent souvent comme référence ; d'autres pays ont leurs propres attentes, renseignez-vous auprès de votre autorité nationale. Une liste d'outils ne suffit pas : les auditeurs cherchent un processus qui fonctionne. Une carte réseau avec dates de première et dernière apparition, des alertes horodatées et vos notes sur chaque décision rendent ce processus visible. NetSenX conserve les alertes pendant la durée d'historique de votre offre et ajoute, à partir de l'offre Pro, des alertes OT sur les écritures non autorisées, le trafic entre niveaux, l'activité hors des heures de travail et les commandes S7comm. Il ne vous certifie pas et ne remplace pas le jugement de l'auditeur.

Oui, et un risque sous-estimé. Chauffage, ventilation, éclairage, ascenseurs et contrôle d'accès fonctionnent aujourd'hui sur des contrôleurs en réseau, souvent en BACnet/IP, avec un accès distant pour la société de maintenance et une application cloud pour le gestionnaire du site. Ils sont rarement mis à jour, gardent souvent leurs mots de passe par défaut et sont généralement gérés par une autre équipe ou un prestataire externe plutôt que par l'informatique. Un attaquant peut s'en servir pour perturber le bâtiment, ou comme point d'appui discret vers le réseau bureautique si les deux ne sont pas séparés. Demandez à votre prestataire où le système se connecte, qui dispose d'un accès distant et comment, et placez les contrôleurs du bâtiment sur un segment réseau dédié, avec un accès Internet limité à ce dont le fabricant a réellement besoin. NetSenX lit BACnet/IP par capture passive à partir de l'offre Pro et détecte, sur toutes les offres, le beaconing, le balayage et le volume sortant inhabituel de ces contrôleurs. Il n'existe pas d'alerte d'anomalie BACnet distincte.

Oui, si les deux partagent un réseau ou si les règles entre eux sont lâches. Les systèmes du bâtiment sont souvent installés par un prestataire sur les mêmes commutateurs et la même plage d'adresses que le bureau, ou avec une route pratique pour que le gestionnaire du site ouvre le logiciel de supervision sur un PC de bureau. Un attaquant qui entre par l'accès distant du système du bâtiment ou par un contrôleur mal protégé peut alors atteindre les ordinateurs du bureau comme s'il était à l'intérieur. Vérifiez où se trouvent les contrôleurs du bâtiment et leur serveur, s'ils peuvent joindre les postes du bureau et si ces postes peuvent les joindre ; en général, seul un poste de supervision en a besoin. Séparez-les par un pare-feu ou un VLAN aux règles strictes, et faites passer l'accès distant du prestataire par votre propre passerelle. Sur un segment surveillé, NetSenX détecte sur toutes les offres le balayage et le mouvement latéral d'un contrôleur du bâtiment vers les postes du bureau, de sorte qu'un contrôleur qui se met à explorer le réseau se remarque.

Cela peut l'être, mais vous devez savoir pourquoi. Beaucoup d'enregistreurs de caméras gardent une connexion permanente avec le cloud du fabricant pour que l'application mobile affiche les images sans ouvrir de port sur votre routeur, et ces serveurs peuvent se trouver dans un autre pays ou sur un autre continent. Cette connexion est aussi un canal d'accès distant que vous n'avez jamais configuré, géré par un tiers, et les enregistreurs anciens ont un long historique de failles de sécurité. Demandez à l'installateur ou consultez la documentation du fabricant pour savoir de quel service il s'agit, décidez si vous avez vraiment besoin de la consultation à distance et, sinon, désactivez la fonction cloud et bloquez l'accès Internet de l'enregistreur. Si vous en avez besoin, maintenez le micrologiciel à jour et changez les mots de passe par défaut. NetSenX montre les destinations de l'enregistreur depuis un port SPAN ou TAP et détecte le beaconing et le volume sortant inhabituel sur toutes les offres, de sorte qu'un enregistreur qui envoie soudain bien plus que d'habitude se remarque. Accepter ou non le cloud du fabricant reste votre décision.

Il peut l'être. Téléviseurs connectés, écrans de visioconférence et panneaux de réservation de salles fonctionnent avec leur propre système d'exploitation, contactent le fabricant pour des mises à jour, des applications et de la publicité, et sont rarement mis à jour une fois installés. Sur le réseau bureautique, ils côtoient les portables qu'on y projette, et certains ont des micros et des caméras. L'essentiel de ce trafic va vers les services du fabricant, mais on ne peut pas le savoir de l'extérieur sans regarder. Désactivez les fonctions inutilisées, comme la commande vocale, les boutiques d'applications et les statistiques de visionnage, mettez à jour le micrologiciel et déplacez les écrans vers un réseau séparé pour les équipements, avec un accès Internet limité au nécessaire et sans accès aux postes du bureau. Les portables peuvent alors partager leur écran par câble ou via un boîtier de diffusion sur ce réseau. NetSenX observe ces appareils sans aucun logiciel installé dessus, depuis un port SPAN ou TAP, et détecte le beaconing, le balayage et le volume sortant inhabituel sur toutes les offres.

En général pour des raisons ordinaires : mises à jour du micrologiciel, remontée du niveau de toner et des compteurs au fournisseur, impression dans le cloud et numérisation vers le cloud. Les contrats d'impression gérée incluent souvent cette remontée, demandez donc à votre fournisseur ce que l'imprimante envoie et où. Le risque, c'est que les imprimantes sont de vrais ordinateurs avec un logiciel ancien, des pages d'administration aux mots de passe par défaut et des copies de documents numérisés, et que personne ne les surveille. Vérifiez dans les réglages les fonctions cloud et à distance que vous n'utilisez pas et désactivez-les, mettez à jour le micrologiciel, définissez un mot de passe administrateur et limitez l'accès Internet aux services du fournisseur. Une imprimante qui se met à contacter de nombreuses adresses internes, ou de nouvelles destinations à l'extérieur, mérite un coup d'œil le jour même. NetSenX voit les imprimantes depuis un port SPAN ou TAP sans logiciel installé dessus, les liste sur la carte réseau et détecte balayage, beaconing et volume sortant inhabituel sur toutes les offres.

Surtout par la conception du réseau, car ces appareils ne peuvent pas faire tourner de logiciel de sécurité. Placez les lecteurs portables, les imprimantes d'étiquettes, les contrôleurs de convoyeurs et le Wi-Fi de l'entrepôt sur un segment réseau dédié qui n'atteint que le serveur de gestion d'entrepôt et les imprimantes nécessaires, pas les PC du bureau ni Internet en général. Utilisez un réseau Wi-Fi distinct avec une authentification par appareil ou par certificat plutôt qu'un mot de passe partagé que connaît chaque ancien intérimaire, maintenez à jour le système et les applications des terminaux via leur outil de gestion, et verrouillez-les sur l'application d'entrepôt. Retirez les appareils que le fabricant ne met plus à jour. Surveillez ensuite le segment, car un seul terminal compromis sur un réseau d'entrepôt à plat peut atteindre tout le reste. NetSenX surveille le segment avec un seul agent sur un port SPAN ou TAP : la carte réseau liste les appareils, et le balayage, le beaconing et le volume sortant inhabituel sont détectés sur toutes les offres.

Non. NetSenX compte les agents que vous faites tourner, pas les appareils qu'ils observent. Un agent sur un port SPAN ou TAP compte pour un seul appareil pour tout le segment qu'il surveille : quarante lecteurs portables, les imprimantes d'étiquettes et le contrôleur du convoyeur sur un même segment recopié sont couverts par ce seul agent. Un agent installé directement sur un serveur ou un portable compte aussi pour un appareil et observe cet hôte. La question à se poser est donc combien de segments vous voulez surveiller et où vous pouvez copier leur trafic, pas combien d'appareils vous possédez. Un entrepôt doté de son propre commutateur a généralement besoin d'un agent à cet endroit. Les terminaux reliés à des bornes Wi-Fi branchées sur ce commutateur sont vus quand leur trafic passe par le port recopié. La page des tarifs indique la limite d'appareils de chaque offre, à partir de l'offre Free.

Depuis le réseau, comme pour les équipements industriels. Analyseurs, appareils d'imagerie, pompes à perfusion et instruments de laboratoire tournent souvent sur d'anciens systèmes que le fabricant certifie et vous interdit de modifier, un agent n'est donc pas envisageable. Placez-les sur un segment réseau dédié qui n'atteint que les systèmes auxquels ils transmettent, comme le système d'information du laboratoire ou l'archive d'images, bloquez l'accès Internet inutile et faites passer la télémaintenance de chaque fabricant par votre propre passerelle. Un capteur sur un port SPAN ou TAP de ce segment voit alors leurs connexions sans les toucher. NetSenX liste les appareils sur la carte réseau et détecte le beaconing, le balayage, le mouvement latéral et le volume sortant inhabituel sur toutes les offres. Il ne décode pas les protocoles médicaux comme HL7 ou DICOM et ne déchiffre jamais le trafic. Avant de l'activer, demandez à votre délégué à la protection des données comment cette surveillance s'inscrit dans votre registre des traitements.