SecurityInsider
Le blog des experts sécurité Wavestone

Conférence S4x19: compte-rendu




Voici notre compte-rendu de la conférence S4, dédiée à la sécurité des SI industriels, se tenant à Miami Beach du 14 au 17 janvier.

Vous pouvez également retrouver un compte-rendu de cette conférence dans le podcast NoLimitSecu:




Keynote

Pour lancer la conférence, Dale Peterson nous parle du chemin parcouru. Selon lui, ce n’est que très récemment, en 2015, que le sujet de la sécurité des systèmes industriels a été pris en main. Cela se manifeste notamment par la mise en place, dans la plupart des organisations, d’audits et de suivi de la conformité. Il est devenu commun de suivre le niveau de sécurité de ses systèmes industriels, de s’assurer d’un niveau d’ “hygiène” minimum.
Mais est-ce bien suffisant ? Selon Dale, nous ne sommes pas au sommet de la montagne; ce n’est que le début.

Il faut poser de meilleures questions. Par exemple : Comment réduire l’effort sécurité qui doit être porté par les équipes OT ?

Et c’est bien le thème de cette édition de S4: présenter des idées novatrices, dont certaines pourraient étonner voire choquer, mais qui font réfléchir.

Digital Ghost: Real Time, Active Defense For ICS

Lors de cette présentation, deux intervenats de General Electric présentaient leur vision d’un des concepts de l’industrie 4.0, le Digital Twin

https://twitter.com/lsamain/status/1085183783786037248

Les catalyseurs de croissance majeurs d’aujourd’hui ont d’abord été présentés: transformation digitale, intelligence artificielle, mais aussi la capacité à s’adapter à un marché changeant rapidement. Pour cela, l’exemple d’Amazon a notamment été explicité. Au départ basé sur la capacité à faire des prédictions sur des groupes de personnes (femmes enceintes, célibataires de moins de 25 ans, …), le ciblage commercial s’est recentré sur l’individu. En analysant les parcours d’achat, les recherches, on peut alors proposer des produits d’intérêt pour une personne unique. Pour aller encore plus loin, c’est la notion de programmation neuro-linguistique (PNL) qui est utilisée. On va ainsi proposer à une personne identifiée comme femme enceinte des couches, mais aussi des livres sur la maternité, un appareil photo pour prendre des photos de l’enfant, on anticipe ses envies futures.

Ces notions orientées marketing se reflètent également sur les systèmes industriels: optimisation en continu, prédiction de panne & maintenance prédictive, etc…

Pour cela, GE peut modéliser une copie numérique (Digital Twin) de ces turbines, voire d’une installation d’un client. En modélisant à la fois le processus physique et les SI associés (capteurs, mais aussi supervision du procédé), on peut alors simuler le comportement “normal” et détecter lorsque l’on s’en éloigne. Il devient même possible d’aller plus loin et de réaliser le scénario suivant :
des données incohérentes sont remontées par 6 capteurs sur un ensemble de 15. On utilise alors le Digital Twin et la modélisation du processus pour injecter dans la supervision du procédé les valeurs dérivées des capteurs “sains”.
GE affirme avoir réalisé des simulations et arriver à une fiabilité de plus de 99%.

Bien qu'impressionante et engageante, ce type de simulation ne nous apparaît possible que sur des systèmes très standardisés, et sur des procédés modélisables physiquement. Cette stratégie ne semble pas applicable à tous les domaines industriels, comme le manufacturing par exemple.

Is The Purdue Model Dead? And What's Next?

Le modèle de Purdue a été créé dans les années 1990 pour décrire les architectures d’entreprise, et correspond à la pyramide CIM (Computer Integrated Manufacturing).


Modèle PERA de Purdue
(Albert Jones [Public domain], via Wikimedia Commons)

Le modèle de Purdue est notamment utilisé dans l’ISA95, et définit comme suit les différents niveaux:
  • Niveau 0 — La procédé physique
  • Niveau 1 — Les capteurs et effecteurs
  • Niveau 2 — La supervision et le contrôle du procédé (systèmes SCADA, DCS..)
  • Niveau 3 — MES (Manufacturing Execution System)
  • Niveau 4 — Logique métier,  ERP


Avec l’arrivée de l’industrie 4.0, et par conséquent d’architectures intégrant de plus en plus de services Cloud, l’intérêt et surtout la pertinence de ce modèle peuvent être remis en cause.
Un débat, animé par Dale Peterson, a permi à deux personnes au point de vue opposé d’exposer leur point de vue.
D’un point de vue de l’architecture réseau, le modèle est effectivement bousculé par les récentes innovations et notamment l’adoption de capteurs connectés et du cloud.
Cependant, ce modèle reste pertinent du point de vue conceptuel. On peut citer la gradation dans les échelles de temps à chaque niveau, qui ne change pas : plus on monte dans les niveaux, plus les échelles de temps sont élevées.
On peut donc considérer que la convergence IT/OT n’a pas tué le modèle de Purdue, bien que la représentation graphique ne soit plus réellement pertinente. On peut faire l’analogie avec le modèle OSI de l’ISO : bien que ne reflétant aucunement la réalité technique des communications TCP/IP, il reste utile pour conceptualiser l’encapsulation protocolaire et le fonctionnement global des communications.

Layered Blueprints: A Method for Engineering OT Security

Sarah Fluchs a commencé sa présentation avec la déclaration suivante : “L’ingénierie en sécurité industrielle n’est pas de l’ingénierie.
Et si nous contredisions cette affirmation ?

Les principaux objectifs de sécurité sont la confidentialité et l’intégrité des données mais ce n’est pas du tout pertinent pour les systèmes industriels. En effet, une phrase que l’on entend souvent chez les industriels est la suivante : “Mon usine doit fonctionner”. Les objectifs sont donc imprécis.

L’idée des layered blueprints est de fournir une méthode de sécurité d’un point de vue OT. 4 niveaux doivent être pris en compte :
  • Les fonctions
  • Les risques
  • Les prérequis 
  • L’implémentation

https://twitter.com/JozefSulwinski/status/1085216716483977216


Ces 4 niveaux ont été détaillés lors de la conférence. 
Les fonctions permettent de clarifier les préconditions et les objectifs :
  • Le modèle réseau : un schéma réseau trop détaillé n’est pas nécessaire ; seule une vue globale avec une représentation de chaque type d’équipement est nécessaire
  • L’analyse des communications : la programmation des automates, l’exploitation du procédé industriel, les connexions entre sites distants 

Les risques permettent d’analyser les incertitudes ou les effets sur les objectifs :
  • Identification des incertitudes
  • Évaluation des incertitudes ou analyse des risques 

Les deux derniers niveaux permettent d’apporter les solutions de sécurité :
  • Prérequis : la première étape est de déduire des risques les prérequis en matière de sécurité
  • Implémentation : le seconde étape est de concevoir et implémenter les solutions de sécurité
Afin de mettre en oeuvre ces 4 niveaux, un modèle lisible par des machines est nécessaire. Par ailleurs, il est préférable d’utiliser des outils spécifiques OT.
Finalement, l’ingénierie en sécurité industrielle est une forme d’ingénierie et tout le monde peut y contribuer.

PASTA: Portable Automotive Security Testbed with Adaptability

Tsuyoshi Toyama a présenté “PASTA”, un environnement de démonstration/test de la cybersécurité des systèmes embarqués automobiles.
Le système est contenu dans une mallette aux dimensions standard, et contient plusieurs ECU, des écrans simulant les différents systèmes du véhicule (phares, volant, tachymètre…).




Il est également possible de connecter cette valise à un simulateur de conduite, avec un volant et des pédales, ou via Bluetooth à un modèle réduit de véhicule pour visualiser les actions réalisées.
Bien que développé par des employés de Toyota InfoTech, ce modèle n’a pas pour vocation de simuler un véhicule Toyota. L’ensemble des ECU, et des codes CAN ID utilisés ont été défini spécifiquement pour ce démonstrateur.

Malheureusement, les créateurs de ce kit ne se sont rendu-compte de la difficulté de publier leurs travaux qu’après leur présentation à la BlackHat Europe, et n’ont pas encore obtenu l’autorisation finale.

Persisting In Level 1 - The Building Is Alive

Lors de cette présentation, l’oratrice a exposé sa démarche de recherche pour identifier des vulnérabilités sur les systèmes de gestion technique des bâtiments (caméras, lumières, climatisation, contrôle d’accès…).

L’objectif était de réaliser une attaque permettant de laisser un minimum de traces et de pouvoir persister sur le réseau. Pour cela, une démarche classique a été employée :

  • Recherche d’informations
  • Identification de vulnérabilités
  • Compromission
  • Persistence

Après avoir acheté du matériel représentatif du marché, la société a permis à des étudiants de rechercher des vulnérabilités sur ceux-ci. Plus d’une dizaine de vulnérabilités inconnues ont été identifiées : 

  • Présence d’identifiants en dur dans les firmwares
  • Dépassement de tampon
  • XSS sur les interfaces web
  • Absence d’authentification

On regrettera que cette présentation n’ait pas été faite par une des personnes ayant techniquement identifié les vulnérabilités présentées.

Triton (We Can’t Say)

Cette conférence sur Triton présentée par Julian Gutmanis n’était pas une présentation sur le détail de l’attaque mais plutôt un bilan sur les enseignements de l’attaque et en particulier comment se préparer à des incidents similaires en tant qu’industriel.

https://twitter.com/infowaropcenter/status/1085754071317966848


Une première panne a été détectée en Juin 2017, un samedi soir. Un seul contrôleur a été impacté et le constructeur a été appelé pour enquêter. Aucun incident particulier n’a été détecté et les opérations ont continué.
Deux mois plus tard, en août 2017, un vendredi soir, une nouvelle panne a été détectée, impactant cette fois-ci 6 contrôleurs. Une session RDP inhabituelle a été identifiée ; une équipe de réponse à incident est intervenue et le constructeur a conseillé la mise en oeuvre d’actions de remédiation.

Des actions classiques de réponse à incident ont été réalisées : image de disque, capture réseau, logs, etc. L’attaquant a pu compromettre le réseau industriel en créant un script Python sur la console opérateur et en exploitant un défaut de configuration de la DMZ.

Suite à la phase de réponse à incident, la panique a pris le dessus : l’environnement industriel complet pourrait être compromis et la confiance dans le système était perdue. Des actions de confinement ont ensuite été entreprises pour isoler le système.

Avec le recul, la cible a eu de la chance avec cette attaque mais cela a néanmoins coûté de l’argent et des manques de sécurité ont été identifiés. Notamment, la première investigation n’était pas suffisante et cela a permis à l’attaquant de parfaire son attaque. De plus, les premières actions recommandées par le constructeur ont mis le reste du système dans une position à risque.
A plusieurs points de vue, l’attaque aurait pu être évitée, identifiée ou stoppée plus tôt.

Les points clés à retenir sont les suivants :
  • Il est important de maintenir une culture cyber sécurité : les anomalies doivent être considérées d’un point de vue cyber
  • Il est important de s’assurer que les rôle et responsabilités sont correctement définis
  • Il est important de prévoir un plan de repli en cas d’attaque
  • Le mot de la fin est certainement le plus important : demander de l’aide avant d’en avoir besoin !

AI + Human

L’utilisation massive de l’intelligence artificielle va modifier considérablement la façon dont nous travaillons. De nouveaux postes/métiers et de nouveaux challenges existent pour ce secteur. 

Selon James Wilson, l’intelligence artificielle va pousser la croissance. Cependant il est nécessaire de garder l’humain. L’IA et l’humain ensemble vont permettre d’aller plus loin.  L’exemple du diagnostic médical a été présenté : 92% des diagnostics étaient corrects pour l’IA, 96% pour les humains, et la combinaison des deux permettait d’atteindre 99,5%.

Trois nouveaux métiers collaboratifs vont voir le jour avec l’IA :
  • Trainers : les robots vont devoir être formés (à avoir de l’empathie par exemple). Dans nos secteurs, nous voyons donc apparaître des développeurs de chatbots ou des data scientists. 
  • Explainers : il faut pouvoir comprendre le comportement des IA et s’assurer que ces systèmes ne sont pas des boîtes noires. Ces nouveaux métiers vont permettre d'accroître la confiance dans l’IA.
  • Sustainers : il faudra également être en mesure de maintenir la sécurité de ces systèmes et des postes comme ingénieur en sûreté de l’IA commencent à apparaître.  

Cinq nouveaux challenges vont également devoir être pris en compte :
  • L’IA peut apprendre à écrire son propre code
  • L’IA a la capacité d’imiter une voix humaine en moins de 60 secondes
  • L’IA peut générer des “deep fakes” 
  • L’humain peut tromper l’IA
  • L’IA peut lire dans les pensées

Enfin, l’impératif concernant l’intelligence artificielle est de développer de nouvelles compétences : des compétences techniques, des compétences pour résoudre des problèmes complexes, renforcer la créativité, etc.

Risk, utility and the public good

Selon Eireann Leverett, nous sommes à moment charnière en termes de cyberassurance : les premiers cas vont déterminer ce que ça va devenir mais l’assurance cyber va rester.

On pense souvent qu’on ne peut pas assurer les risques cyber car ils ne sont pas accidentels mais “adversaires”, cependant il existe également des assurances pour d’autres types d’événements adversaires: guerre, terrorisme, kidnapping, piraterie.

On peut quantifier certains risques cyber, par exemple les rançongiciels. On peut aussi calculer quel serait le plus gros DDoS théorique (taille des liens, nombre de réflecteurs DNS, etc.). Et lorsqu’il est possible de quantifier, il est possible d’assurer. 

En Grande Bretagne, il est par exemple possible de s’assurer contre un acte de cyber-terrorisme dans le secteur du nucléaire. 

Debate: Are Specialized OT Tools and Talent Required to Detect Attacks on ICS?

Ce débat, animé par Dale Peterson opposait les deux points de vue :
Steve Miller de FireEye soutenait que des outils ou compétences spécifiques OT n’étaient pas requis pour détecter des attaques sur les systèmes industriels.
Ben Miller de Dragos soutenait le contraire.

L’argument principal de Steve était qu’il n’y a pas réellement d’attaque purement industrielle. L’attaque commence toujours par des éléments IT. Il a notamment parlé du cas Triton où seuls des outils IT ont été utilisés pour l’attaque (sysinternals, nmap, meterpreter, etc.)

Ben assure au contraire que de nombreux outils classiques, comme les scans de vulnérabilités, ne sont pas adaptés pour les systèmes industriels. De plus, de nombreux équipements utilisent des protocoles de communication non standards et parfois même non IP. Il a également utilisé l’exemple de Triton pour montrer que des compétences OT avaient été nécessaires pour comprendre en profondeur l’attaque. 

Il est vrai qu’aujourd’hui, même les SOC IT ne sont pas toujours très efficaces. Peut-être que dans les prochaines années, des SOC OT vont voir le jour et permettre de détecter davantage d’événements de sécurité. 

On peut conclure qu’un détection IT standard efficace permettra sans doute de détecter une attaque (notamment dans ses premières phases), mais que sa compréhension et la réponse à incident ne sera efficace qu’avec des compétences OT et métier.

PLC backdoor in disguise

Lors de cette conférence, le but de Roee Stark n’était pas de montrer les vulnérabilités bien connues des protocoles industriels mais plutôt de montrer comment utiliser des automates exposés pour rebondir sur le réseau, sans modifier le programme de l’automate.

La classe 0x02 (message router) du protocole CIP permet de transférer des paquets entre automates. 
En effet, il a démontré qu’un automate, normalement non accessible via une requête ping, pouvait le devenir en utilisant un message CIP et en indiquant comme relais un automate exposé. Il est donc possible de faire du scan de port en utilisant CIP et ainsi trouver des contrôleurs non exposés, en contournant le filtrage réseau.

Cette fonction n’est pas limitée aux paquets IP. En effet, il existe aussi une classe socket CIP, pour les équipements ne disposant pas d’Ethernet et ne nécessitant aucune authentification.

Cette méthode pourrait être utilisée d’une manière plus offensive et pourrait permettre l’exploitation de vulnérabilités. 

Étant une fonctionnalité de CIP, il n’existe pas de contre mesure simple. Une bonne hygiène réseau permet de se prémunir de ce genre d’attaque en implémentant notamment une liste blanche de routes réseau.

New ICS protocol techniques to detects attacks

Cette session, présentée par Tatsumi Oba, se déroulait sur le “stage 2”, dédié aux conférences plus techniques. Tatsumi nous a présenté les résultats de ses recherches sur la détection d’attaque sur le protocole BACNET/IP. Ce protocole industriel est très fréquemment utilisé dans les domaines du chauffage, de la ventilation et de la climatisation (HVAC). Ce protocole est non-authentifié, et repose sur UDP. Il est donc facile d’usurper l’identité d’un équipement et d’envoyer des commandes arbitraires.
La difficulté principale dans la détection d’une attaque sur ce type de protocole non-authentifié est qu’une attaque va utiliser des commandes légitimes existantes. On ne peut donc pas se contenter de définir une signature pour une attaque.

On se concentrera donc sur la détection d’anomalies plus que d’attaques, via l’apprentissage automatisé. Pour cela, les deux techniques les plus courantes sont les suivantes:
L’analyse du flux de données (taille du paquet, metadonnées), qui se prête mal au protocole BACNET/IP en raison du faible nombre de paquets échangés
L’analyse de la charge utile : on range la charge utilise dans un tableau de bits, on réalise un apprentissage des charges standards et on alerte sur un écart. Cela permet d’éviter les faux positifs mais ne permets pas efficacement de détecter les attaques qui vont envoyer des paquets forgés mais ayant une charge légitime.

La proposition de Tatusmi est d’utiliser une 3ème technique, nommé “payload-sequence based detection”. Le principe est le suivant : dans une utilisation normale du protocole BACNET/IP, on retrouve toujours le même enchaînement de paquets avec des charges utiles semblables. On peut donc détecter une anomalie. Les étapes sont les suivantes :

  • Etape 1 : Extraction de la commande et du contexte, puis calcul de l’éloignement via la distance de Levensthein.
  • Etape 2 : On calcule un “histogramme” représentant la distance entre les charges utiles des paquets d’une séquence
  • Etape 3: On calcule “l’éloignement” entre l’histogramme constaté et le référentiel par la méthode EMD (Earth Mover’s Distance), aussi appelée métrique de Wasserstein 
L’efficacité de cette méthode a ensuite été comparée aux deux précédentes sur les attaques suivantes:
  • Envoi massif de paquets
  • Envoi d’une commande de changement de volume d’air et d’extinction
  • Attaque depuis une adresse IP inconnue
  • Envoi d’une commande avec une valeur extrême
  • Envoi d’une commande inhabituelle

Ce n’est que la combinaison des trois méthodes qui permet de détecter efficacement l’ensemble des attaques.


Truth or Consequence

Une façon simple de représenter un risque est l’équation risque = probabilité * impact. Dans la communauté ICS, l’effort de réduction du risque passe très souvent par la mise en oeuvre de contrôles de sécurité afin de réduire la probabilité. Et si nous étudions les moyens de réduire les impacts ?

Deux méthodes de réduction des risques par la réduction des impacts ont été présentées lors de cette conférence.

Andy Bochman de l’INL utilise le Consequence-driven Cyber-informed Engineering ou CCE. John Cusimano utilise quant à lui le Cyber Process Hazard Analysis ou Cyber-PHA.

Le Cyber-PHA se base sur l’IEC 62443-3-2 et tire partie des méthodes existantes pour les analyses de sûreté. Il s’agit d’une méthode d’identification des risques cyber en 5 étapes :

  • Documentation du système existant, en se basant notamment sur les schémas réseau
  • Identification des vulnérabilités
  • Partitionnement du système
  • Identification des risques
  • Établissement du plan de remédiation


Le CCE est composé de 4 étapes :

  • Priorisation des conséquences ou identification des composants essentiels
  • Partitionnement du système
  • Ciblage basé sur les conséquences ou analyse de la kill chain
  • Établissement du plan de remédiation


Ces deux méthodes sont assez différentes mais reposent toutes les deux sur une étape de partitionnement du système.

Un exemple de réduction du risque par la réduction de l’impact pourrait être de configurer des capteurs en mode lecture seule. Ainsi, même si ces équipements deviennent accessibles, il ne sera pas possible de les reprogrammer à distance.

Fixing CVSS

Ce débat autour de l’intérêt et de l’utilisation du standard de notation de vulnérabilité CVSS part d’un constat partagé par de nombreux membres de la communauté de la sécurité des SI industriels : CVSS est trop complexe et n’est pas utilisable opérationnellement.

Evidemment, on se doit de rappeler que CVSS n’a pas pour objectif de noter un risque, ou un impact potentiel sur un système: il s’agit d’un standard de notation des vulnérabilités, qui sont ensuite à contextualiser pour prendre des décisions informées.

Deux alternatives à CVSS ont été présentées :

RSS : Risk Scoring System

Cette initiative a été financé par les DHS (département de la sécurité intérieure des Etats-Unis d’Amérique) et se décline en trois secteurs : médical, aviation civile, et systèmes d’armes. Il s’agit donc d’une méthodologie de notation des risques, et dont une des convictions est le fait que la notion de probabilité n’est pas quantifiable pour un risque adversaire comme la cybersécurité. Ce sont donc les caractéristiques techniques de la vulnérabilité qui déterminent son ordonnée sur la matrice de risques :


Le site http://riskscoringsystem.com/ présente cette initiative, ainsi que des calculatrices pour noter les risques associés à une vulnérabilité.

TEMSL: Threat, Exposure, Mission, Safety, Loss

Cette alternative pour identifier les actions requises suite à l’identification d’une vulnérabilité séduit par son côté simple. Basé sur un arbre de décision, on obtient en sortie trois priorités:

  • Never: il n’est pas indispensable d’appliquer le patch
  • Next: appliquer le correctif lors de la prochaine campagne de patch
  • Now: appliquer le correctif au plus vite


Malheureusement, la méthodologie détaillée n’est pour le moment pas publiée.





ICS Detection Challenge: Analysis and Results

Cette année, pour la seconde édition du ICS Detection Challenge, seules 3 équipes ont finalement décidé de participer : Dragos, Kaspersky et une équipe open source.
Le challenge a même failli être annulé jusqu’au dernier moment, notamment après l’abandon de Claroty en fin d’année dernière.

La préparation du challenge a nécessité plus de 400 heures de travail, notamment pour anonymiser les captures réseau et injecter des données d’attaques. En tout, plus de 400 Go de données ont été capturées sur une entreprise minière. 

Avec le peu de participants, le déroulé initial du challenge a quelque peu évolué. En effet, la capacité des solutions de détection à inventorier les équipements de l’usine n’a finalement pas été évaluée. Seule la partie détection a été évaluée. De plus, le but initial était de laisser seulement 8h à chaque équipe pour intégrer les données à leurs outils, afin d’évaluer en priorité les capacités de l’outil plus que les compétences d’analyse des équipes. Finalement, chacune des équipes a pu travailler 3-4 jours et fournir une vidéo finale expliquant les résultats de l’analyse.

L’attaque était composée de plusieurs scénarios avec des mouvements sur les réseaux IT, OT et DMZ. Les attaques suivantes pouvaient être trouvées : Stuxnet, Havex, grey energy, Mimikatz, XSS sur des produits Rockwell, DoS sur un automate.

Un des aspects les plus difficiles du challenge était le fait que les participants n’avaient aucune information sur l’environnement (pas d’historique, pas de phase de training comme réalisé habituellement avec les outils de détection).

Concernant les résultats, aucun gagnant n’a été désigné et aucune des deux équipes n’a identifié tous les éléments de l’attaque. Kaspersky a détecté plusieurs incidents de sécurité mais n’a pas su lier les événements entre eux, contrairement à Dragos qui n’a suivi qu’une seule piste mais a su remonter assez loin pour détecter plusieurs éléments infectés.

Une analyse du ICS Detection Challenge par Dale Peterson, ainsi que la vidéo des résultats est accessible ici : https://dale-peterson.com/2019/01/31/post-game-analysis-s4-ics-detection-challenge/ 


Virtualization for PLCs

Cette présentation était tout à fait dans la lignée de la keynote de Dale Perterson et plutôt orientée vers le futur de l’ICS : et si on virtualisait les automates ?

En effet, les soft PLC commencent à faire surface mais sont pour l’instant peu répandus. On peut se demander pourquoi il est intéressant de virtualiser : les coûts sont plus faibles ; la virtualisation apporte plus de flexibilité ; le support et la maintenance sont rendus plus faciles. La virtualisation a également des apports en termes de cybersécurité.  En effet, les machines hébergeant les VMs pourraient être plus durcies que les machines elles-mêmes et on pourrait être plus rassurés d’avoir des objets virtuels autour des composants ICS critiques.

On voit assez régulièrement de la virtualisation pour les niveaux 2 à 5 du modèle de Purdue. Mais pour le niveau 1, les automates industriels, qu’est-il possible de virtualiser ? Il pourrait être possible de virtualiser la CPU, les racks, et également les cartes d’entrées / sorties.

Attention cependant aux problèmes de latence, critiques pour l’OT. Les outils de virtualisation pour automates doivent prendre en compte ces aspects afin d’être viables sur le long terme.

Enfin, pour terminer sa présentation, Austin Scott a évoqué les avantages de la virtualisation pour les constructeurs d’automates. Les contrôleurs étant des équipements relativement chers, on se demande si les constructeurs auraient quelque chose à gagner avec la virtualisation. Néanmoins, cela leur permettrait de mettre l’accent sur la partie software de leurs produits. 

Aucun commentaire:

Enregistrer un commentaire