Depuis la découverte de Stuxnet en juin 2010 et son analyse, les experts se sont aperçu que certaines des failles utilisées par le malware étaient inconnues (0-day) et de très haut niveau, et que certaines autres étaient au contraire connues et relativement triviales, cette dernière catégorie est majoritairement représentée parmi celles affectant les systèmes SCADA Siemens WinCC (Supervisory Control And Data Acquisition, télésurveillance et acquisition de données).
Depuis, beaucoup de personnes se sont intéressées à la sécurité des systèmes de contrôle industriel au sens large. Les systèmes SCADA sont dorénavant bien connus pour être vulnérables mais ils ne sont pas les seuls.
Le monde de la sécurité informatique découvre depuis peu ce que beaucoup de gens savent déjà, les systèmes de contrôle industriel sont de vraies passoires et la mise en péril d'un processus industriel est relativement simple.
Sommaire
- Systèmes de contrôle industriel
- Des mauvaises habitudes, la réalité du terrain
- Un monde de failles
- La jungle du web
- Des automates qui font le café
- La réponse des acteurs
- Que faire ?
- Conclusion
Systèmes de contrôle industriel
Par systèmes de contrôle industriel (en anglais ICS pour Industrial Control System), on désigne les systèmes qui dans l'industrie permettent de contrôler certains processus industriels, ces systèmes permettent par exemple de contrôler les actionneurs sur une ligne de fabrication, de piloter des installations ou de réguler des procédés…
Ces systèmes doivent répondre à un certain nombre de contraintes liées à leur nature telles que la sûreté de fonctionnement, le temps réel, la disponibilité 24/7, un environnement contraignant, des utilisateurs non spécialisés en informatique…
Les motivations pour un attaquant de s'attaquer à un système de contrôle industriels peuvent être multiples :
- éroder la sûreté de fonctionnement de la ligne de fabrication afin de ralentir ou saboter un processus ;
- voler le programme d'un système de contrôle à des fins d'espionnage.
Bases
Les systèmes de contrôle industriels répondent bien évidement à une certaine théorie. À l'instar du modèle OSI pour les réseaux informatiques, les concepteurs de ces systèmes ont leur propre pseudo-modèle :
+---+-----------------+
| 3 | Supervision |
+---+-----------------+
| 2 | Automatisme |
+---+-----------------+
| 1 | Terrain/bus |
+---+-----------------+
La couche terrain désigne la couche physique, là où les divers bus industriels se situent, on y retrouve notamment des technologies telles que ModBus¹, Ethercat¹, CAN… C'est sur ces réseaux que sont connectés les divers actionneurs d'une chaîne de fabrication.
La couche automatisme est la couche où s'exerce la pseudo-intelligence de ces réseaux ; les automates, connectés aux réseaux sus-cités sont les chefs d'orchestre, ils commandent les actionneurs suivant un ordre bien défini et suivant diverses conditions.
La couche supervision est quant à elle celle qui est la plus liée à l'informatique, elle permet, via un ordinateur connecté sur le réseau de terrain ou sur l'automate de récolter diverses informations sur l’exécution du processus, ces informations remontent alors via des protocoles tels que OPC¹ ou SCADA¹ vers des logiciels de supervision dédiés tels que PcVue¹ ou Panorama¹. On est donc loin de la supervision classique connue des administrateurs réseaux via SNMP et des logiciels de la famille de Nagios.
Viennent à côté les logiciels de configuration qui permettent de programmer les automates afin de leur faire réaliser les opérations voulues, ces configurations sont la plupart du temps réalisées grâce à des langages de programmation propres à chaque automate. Ensuite, la programmation est chargée soit en envoyant un binaire du programme, soit en reflashant tout le microcode/firmware de l'automate via USB ou autres.
Le point qui fâche quant à la plupart de ces logiciels, automates et protocoles est qu'ils sont propriétaires et sont pour la plupart la définition même du bloatware. Certaines implémentations sont très douteuses, notoirement buggées, et on va le voir, très faciles à défaire d'un point de vue sécurité.
¹ : technologies connues comme vulnérables
Nécessité du couplage avec les systèmes de gestion
On pourrait se dire qu'isoler les systèmes incriminés sur des réseaux physiques dédiés devrait suffire à les rendre moins vulnérables. Malheureusement, ce n'est pas si simple, la prédisposition des utilisateurs à se servir de clé USB rompt souvent cet isolement, de nombreux exemples sont là pour le prouver ; en outre, les grands progiciels du marché cherchent actuellement à étendre leurs champs d'actions afin d'englober également la partie production, ceci doit permettre d'ajuster au plus près la production d'un bien à sa demande. Les décideurs pressés sont friands de ce genre de fonctionnalités afin de pouvoir être encore plus pressés. Il faut donc composer avec cette contrainte.
On constate donc qu'un isolement n'est pas souhaité et serait de toute façon faillible ; ce rapprochement est très récent et certaines habitudes des utilisateurs ne sont plus du tout adaptées aux nouvelles contraintes entraînées par ces nouvelles interconnexions.
Des mauvaises habitudes, la réalité du terrain
On constate que de nombreuses mauvaises habitudes existent tant de la part des concepteurs/installateurs que des exploitants.
Certains installateurs ont tout d'abord comme habitude de connecter les automates qu'ils installent à l'Internet afin de pouvoir intervenir rapidement dessus en cas de besoin. Des recherches sur Shodan HQ avec les noms de marques d'automates révèlent plusieurs milliers d'unités connectées à l'Internet et sans doutes vulnérables tout autour du monde. Il faut noter que certains exploitants ne sont pas au courant que leurs systèmes sont ainsi connectés à l'Internet.
La seconde mauvaise habitude est l'utilisation de couples identifiant/mot de passe très faibles tel que : admin/1234 ou admin/00 ou 01/01…
Certains postes de supervision ont également un utilisateur qui est continuellement connecté et sur lequel n'importe qui peut donc intervenir en bien ou en mal.
Il s'agit là d'un florilège de mauvaises pratiques, cette liste n'est pas exhaustive ; mais par contre, tous les éléments de cette liste peuvent facilement être retrouvés sur un seul et même système de gestion.
Un monde de failles
En plus de toutes ces mauvaises pratiques, les technologies employées sont vulnérables. Un hacker italien, Luigi Auriemma, s'est intéressé de près au sujet, mais face à l'ampleur de l'insécurité, il s'est fixé une règle : lorsqu'il trouve 6 failles sur un automate ou un logiciel, il passe à un autre et ne passe pas plus de deux jours d'investigation par automate/logiciel. Le résultat est impressionnant, des dizaines de produits sont devenus vulnérables !
On constate grâce à ses travaux et grâce aux travaux des autres hackers que toutes les couches des systèmes de gestion sont impactés : les réseaux sont parfois perméables, les automates peuvent manifestement être tous compromis car dotés d'architectures trop anciennes, et les outils de supervision sont également faillibles. Un attaquant a donc une surface d'attaque potentiellement très grande à exploiter.
Quelques logiciels de configuration sont également touchés, pour ne rien arranger.
La jungle du web
Ajouté à cela, les constructeurs ont eux aussi succombé à la mode du web (pas 2.0 néanmoins) et proposent presque tous des serveurs web sur leurs automates afin de les administrer.
L'interface web permet divers niveaux de contrôle suivant les marques allant de la modification du code s'exécutant sur l'automate à la simple activation d'options.
Ces serveurs web sont bien souvent de piètre qualité, utilisant des technologies telles qu'ActiveX, Flash et consort. Les pages HTML sont de très mauvaise qualité généralement.
On constate qu'une grande part des failles divulguées concernent ces serveurs web. Ces serveurs web ne sont pas toujours désactivables, et leur utilité est très limitée ; les installateurs leur préfèrent souvent le logiciel de configuration pour des raisons d'ergonomie.
Ces serveurs web sont donc un vecteur d'attaque très important alors qu'ils ne sont que très peu utilisés par les installateurs et les exploitants, une personne malintentionnée et techniquement douée arrivera par contre à faire des choses très poussées avec ce même serveur web.
En prime, certains automates ne proposent pas de page d'authentification en HTTPS pour l'administration de ces automates, seule une authentification en HTTP est possible (qui est parfois utilisée au travers du grand Ternet), négligence des concepteurs ou incapacité à implémenter une pile SSL valide sur leur matériel spécifique ?
Des automates qui font le café
Certaines marques telles que Wago essaient d'être les plus généralistes possibles : quatre langages de programmation différents, un très large panel de protocoles pris en charge ; on peut raisonnablement s'inquiéter de la nécessité de toutes ces fonctionnalités qui élargissent la surface d'attaque et le nombre de bugs possibles.
Cette même marque s'est également démarquée via la révélation d'une porte dérobée dans certains de ces automates, cette backdoor est maintenant publique.
La réponse des acteurs
Les failles « Forever Day »
Face à cet afflux de rapport de vulnérabilités, les constructeurs réagissent de diverses façons : beaucoup ne communiquent pas, certains assument même publiquement qu'ils ne vont pas publier de correctif. C'est par exemple le cas d'ABB qui a annoncé qu'ils n'allaient pas corriger une vulnérabilité affectant toute une gamme de produit SCADA car considérée en fin de vie, mais malgré tout toujours très utilisée dans l'industrie.
Au delà des failles qui ne seront jamais corrigées, certains exploitants ne peuvent mettre à jour certains automates car les programmes qu'ils exécutent ont besoin de certaines failles pour fonctionner (cas de la synchronisation de deux automates grâce à la lecture/écriture de la mémoire de l'un dans l'autre par exemple).
On est donc confronté à des mises en œuvre de processus qui seront vulnérables tant qu'elles seront en fonctionnement du fait de ces problématiques.
Les constructeurs inconscients
Les constructeurs n'ayant pas encore été touchés par une vulnérabilité se cantonnent quant à eux à croire en la sécurité de leurs produits ; certains tels que WIT vont même jusqu'à vanter sur les salons la sécurité en avançant des points tels que le coté propriétaire du système, tout en présentant en toute confiance des pages web d'authentification en HTTP depuis l'Internet…
Certaines réponses sont aussi très maladroites, le fabricant américain Tridium a récemment répondu à une faille de type directory traversal permettant de récupérer le fichier /etc/passwd de ses automates Niagara JACE à travers l'interface web en changeant simplement l'emplacement du fichier incriminé, ce qui n'a bien sûr pas changé quoi que ce soit au problème.
Que faire ?
Pour les admins réseaux
Les administrateurs réseaux doivent auditer tous leurs réseaux, des automates peuvent se cacher dans des endroits improbables (gestion de la ventilation ou autre) et isoler les équipements en question ; il faut aussi bien s'assurer qu'aucun automate ne soit connecté à Internet de quelque manière que ce soit.
Les postes de supervision sont tout aussi sensibles et doivent subir le même traitement. Une politique de gestion des droits très fine par utilisateur doit être mise place afin de répondre de manière efficace aux différents problèmes exposés plus haut.
Des outils tels que metasploit et nessus sont régulièrement mis à jour avec les nouveaux exploits, donc vous pouvez les utiliser (avec précaution tout de même sur les systèmes en production), des scripts nmap sont également de la partie.
Pour les exploitants de systèmes
La responsabilité des exploitants est de demander un audit complet du réseau et notamment de la partie production. Ils peuvent également faire inclure dans leur contrat de support avec les installateurs une clause pour être averti des failles affectant les produits qu'ils ont en exploitation.
Pour les concepteurs de systèmes de contrôle
Les concepteurs sont ceux qui ont le plus de travail, certains constructeurs avouent sans rougir ne pas avoir mis à jour leurs produits depuis plusieurs années, ce qui fera autant de retard à rattraper.
Les conseils qui peuvent leur être prodigués sont nombreux mais on peut déjà citer :
- publier des mises à jour quand le besoin s'en fait sentir ;
- mettre à la poubelle les automates des années 90 et 2000 pour repartir sur des bases saines ;
- reléguer la partie basse du logiciel à des spécialistes en employant des noyaux reconnus tel FreeRT, Linux, QNX ou autres qui savent implémenter correctement des protections et qui permettent de réutiliser des composants plus haut niveau tels que des piles SSL valables ou des interfaces SSH correctement implémentées ;
- ne pas implémenter des serveur web partout et se contenter des protocoles déjà reconnus ;
- publier des mises-à-jour quand le besoin s'en fait sentir ;
- être compatible avec SNMP v3 ;
- ne pas installer de porte dérobée.
Conclusion
Vous l'aurez compris, le bilan est loin d'être rose.
Les systèmes de contrôle industriels étant des systèmes ayant des durées de vie très importantes (jusqu'à 15 ans), on est en droit de s'inquiéter actuellement de leur sécurisation, afin d'éviter les problèmes dans les années à venir.
Ces systèmes de contrôles se retrouvent partout, et ils se retrouvent employés dans de nombreux autres domaines, où si ce ne sont pas les mêmes systèmes, les mêmes erreurs de conception sont réalisées…
Par exemple, dans le célèbre fast-food au clown, les bornes de commande « commande facile » sont vulnérables à une série de tapotement alterné sur les coins de l'écran tactile de la page d'accueil suivie d'un PIN à quatre chiffres, permettant d'accéder à une interface… très intéressante (NdM.: nous avons retiré une partie des infos détaillant la faille).
Aller plus loin
- Blog Securid (372 clics)
- Blog de Luigi Alummi (130 clics)
- Référentiels de sécurité qui vont bien (310 clics)
# Petite correction
Posté par Olivier Abad . Évalué à 9.
L'article est très intéressant.
Une petite remarque toutefois, dans le paragraphe "Bases" : OPC est bien un protocole (enfin une famille de protocoles), mais SCADA non. C'est une catégorie de produits (PcVue et Panorama sont des SCADA).
Il existe beaucoup d'autres protocoles utilisés par les SCADA. Pour ceux que je connais, dans mon domaine (l'électricité), on trouve principalement :
* IEC 60870-5 et IEC 61850 pour la communication avec les automates ;
* TASE.2 pour les échanges inter-SCADA.
Les spécifications IEC ne sont hélas pas accessibles librement…
[^] # Re: Petite correction
Posté par let antibarbie = xp <- xp - 1 . Évalué à 8.
Si je peux compléter les différentes les familles de protocoles, on peut trouver, avec différents degrés de sécurité :
les protocoles haut niveau comme OPC-DA, OPC-UA, BACnet, KNX, SNMP (nb: excepté SNMPv3, on les retrouve souvent utilisés sans aucune sécurité en pratique : la priorité étant que ça fonctionne, les exploitants et les intégrateurs n'en ont rien à cirer du méchant h4xor qui se connecte au réseau, et en général ça fonctionne sur un réseau coupé du reste du monde en se disant que ça ne risque rien)
Des protocoles d'échange fichier, où typiquement un fichier type CSV est échangé par FTP, HTTP, NFS, CIFS, ou autre protocole de transfert de fichier.
Les protocoles traditionnels (sans sécurité) comme LON, modbus/TCP, modbus/RTU
des échanges par web services (ça vient de plus en plus à la mode)
des échanges par base de données SQL interposées
Les protocoles constructeur, alors là on se lâche, c'est tout et n'importe quoi, quelques dérivés anecdotiques non standard du modbus/jbus façon "personnalisée", et niveau sécurité.. rien du tout.
Par contre, les protocoles typiques "électricité", "batiment" (GTB) ou "chauffage" (GTC) sont typiquement utilisés dans leur domaine et pratiquement pas ailleurs. Personnellement j'ai constaté un cloisonnement vraiment très prononcé à ce niveau.
Pour ce qui est du "vivement mettre à la poubelle les automates existants", je rigole ! Un industriel, même s'il doit acheter un module de remplacement hors de prix (i.e. Siemens majore les factures à l'ancienneté), paiera le remplacement de la pièce plutôt que la mise à jour du site. La mise à la poubelle coûte très cher en ingénierie, en temps de mise à l'arrêt, tests et corrections de problèmes.
La règle semble être on le peut plus claire : on ne touche pas à un système qui fonctionne.
Aujourd'hui on a encore des clients qui ont 4 ou 5 générations d'automates complètement différents sur un même site, qui ont entre 20 et 1 ans d'âge, tout constructeurs, protocoles et liaisons physiques mélangées!
Concernant Wago, je ne suis pas fondamentalement d'accord avec les commentaires : d'expérience, la surface d'exposition est complètement paramétrable, et leurs produits sont simples et efficaces à utilise (après l'atelier de configuration est basé sur Cimetrics : c'est de la m…. ce driver, ils auraient dû faire ça en natif). (nb: je travaille pas pour Wago)
troll: Vivement que BACnet mette tout le monde d'accord.. et qu'on dégage une bonne fois pour toutes ces abominations d'OPC !
[^] # Re: Petite correction
Posté par RbN . Évalué à 2.
Merci à vous deux pour ces précisions utiles.
Moi aussi, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Cette phrase était surtout là pour énoncer mon souhait d'en finir avec les automates n'ayant été conçu avec aucunes notion de sécurité alors que ça deviens vital pour cette industrie.
Concernant les produits Wago, je reconnais ne pas les connaître suffisamment, peut être pourras tu m'éclairer : comment se passe la désactivation d'une fonctionnalité/module ? Je me souviens seulement avoir vu des personnes en configurer avec CoDeSys qui lui est troué maintenant.
[^] # Re: Petite correction
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Je n'ai pas une vision exhaustive de toute leur gamme de produits, mais tu achètes un contrôleur suivant le besoin principal et tu as une bécane qui utilise les protocoles (en client ou en serveur) : HTTP, BOOTP, DHCP, SNMP, NTP, MODBUS/TCP, MODBUS/RTU, KNX.
(nb: pas certain que cette combinaison exacte existe, mais c'est à peu près l'idée).
Après tu peux tout activer ou désactiver comme bon te semble (e.g. via l'interface web). Probablement c'est également disponible dans CodeSys mais je t'avoue que je bosse plus du coté SCADA que du coté automate—faudrait que je cuisine mes collègues ou le commercial Wago.
[^] # Re: Petite correction
Posté par RbN . Évalué à 3.
Aie !
Sans compter que cela implique que tout soit en mémoire quelque part, ce qui permet le rop : http://en.wikipedia.org/wiki/Return-oriented_programming
[^] # Re: Petite correction
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
+1 pour le lien sur le ROP
[^] # Re: Petite correction
Posté par RbN . Évalué à 1.
Juste pour le plaisir du troll, quand on voit les limitations de protocoles tels que KNX, DALI, LON … qui sont pour certains très spécifiques, je pense que c'est normal de voir ce cloisonnement.
Et concernant BACnet, je ne suis pas pour le moment convaincu, j'ai l'impression que quelque chose cloche avec ce protocole. Je laisse donc le temps passer pour voir ce qui va se passer, beaucoup d'acteurs se tournent vers lui (et c'est peut-être cela justement, ça provoque trop l'unanimité …).
[^] # Re: Petite correction
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Certes, BACnet a quelques lacunes au niveau "structure objet théorique" notamment (dans les implémentations en pratique, pas dans la norme qui permet de structurer les objets), et les objets de type uniquement "informatique" (date, heure, chaine, entier, booléen) viennent à peine d'être ajoutés dans la norme.
mais grosso-modo, pour du suivi d'usine, de process, de batiments, ou de chauffage, c'est plus efficace et fonctionnel que SNMP ou OPC-DA, il y a des (une?) implémentations open-source, et c'est indépendant du constructeur, et ça supporte également de multiples supports physique, et vu la taille de la norme, énormément plus simple que OPC-UA.
Evidemment, la norme est payante mais 100$ pour une boite c'est peanuts, et Steve Kargs a une super implémentation (http://bacnet.sourceforge.net/) GPL-avec-exception qui permet de coller du BACnet dans à peu près n'importe quel truc embarqué.
# un petit point vue...
Posté par Geo Vah . Évalué à 9.
Tout a fait, est-ce que le client va accepter un mise a jour de son installation? un arret pourrait lui couter beaucoup… Le client serait ok pour faire une mise a jour de securite si celle-ci ne modifie rien, si la mise a jour de securite est incluse dans une mise a jour globale, ca devient bcp plus difficile de convaincre…
Ok, mais ca ne marche que lors que l'on met a jour son usine ou bien lors de la construction d'une nouvelle usine. En industrie, il y a regulierement le "jusque ici tout va bien". Je connais certains cas de figure ou le client a fait des stocks de PLC qui ne sont plus produit ni supporte mais qui permette de remplacer le materiel défectueux tres rapidement…
15ans une duree de vie? pour la partie soft oui, pour la partie materiel, je n'en suis pas sur du tout, je parierais meme sur un peu plus - exemple d'une usine de production de verre avec une duree de vie de 21ans (3 gros arrets prevus tous les 7 ans), je ne suis pas sur qu'ils s'amusent a changer le materiel et tout reconfigurer….
Linux, tu oublies, je suis pas sur qu'un industriel va vouloir distribuer le code source lorsqu'il va fournir un materiel… Dans mes souvenirs, QNX ou bien WinRiver sont utilises.
Que penses-tu du protocole REST ? (attention abus de protocole versus REST, mais bon je force un peu pour voir ta reaction).
Que penses-tu de la contrainte venant de l"IT ou seul le port 80 et HTTP sont autorisé a travers le firewall ?
Que penses-tu de la notion de webservice qui semble etre la demande venant de client pour pouvoir recuperer tres facilement des informations pour la partie IT/business ?
être compatible avec SNMP v3
ne pas installer de porte dérobée.
Ca parait evident non ? j'estime la meme chose de n'importe quel logiciel ?
Le monde industriel avait l'habitude d'etre sur un reseau dedie pour divers raisons et se retrouve maintenant connecte a internet. Cette ouverture se passe mal, la partie industrie a du mal a suivre la partie IT et inversement: pour deployer un patch dans une usine pour un PLC ou un SCADA, ca prend en general 6 mois, le temps d'ajoute ca dans leplanning, d'avoir les personnes internes et l'integrateur systeme sur place, d'avoir une solution de replis dans le cas d'avoir Murphy parmis les invites…
Maintenant il semblerait que le point initial soit de connaitre son reseaux. si personne ne sait ce qu'il y a sur son reseaux, sa topologie et les differents serveurs, le hack n'en sera que plus facile.
Avoir un outil centralise - je supprime un utilisateur (sous traitant ou demission) et cet utilisateur n'a plus aucun access a mon installation est plutot crucial non? Mais est-ce que je vais authorise quelqu'un de l'IT a venir touche mon process industriel et la partie safety qui va avec?
On passe de plus en plus a un j'ai reseau IT,j'achete des PLC, un SCADA a je veux une solution complete pour ma nouvelle usine ?
Ne pas oublier la partie social engineering, et surtout que cherche un pirate a faire sur ce type de reseaux? Generalement, recuperer les informations de production se passera plus par un soft de plus haut niveau, le but initial serait plus de faire tomber la partie supervision et donc d'interrompre la production ou "juste" de faire produire des yahourts sans lait…
Les histoires a la stuxnet, je dirais que c'est une exception ?
[^] # Re: un petit point vue...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"Les histoires a la stuxnet, je dirais que c'est une exception ?"
Les premiers virus PC qui "détruisaient" était surtout là pour le fun du concepteur.
Le nombre de virus a explosé avec la monétisation du phénomène (botnet, etc…). Il suffit qu'un rigolo trouve une méthode simple de faire de l'argent avec ces failles pour qu'elles deviennent très utilisé rapidement.
"La première sécurité est la liberté"
[^] # Re: un petit point vue...
Posté par RbN . Évalué à 2.
Et c'est là que les constructeurs doivent comprendre que modulariser leurs systèmes serait un plus, les mises à jour peuvent être distribuée et appliquée plus facilement et rapidement dans ce cas. Bien que certaines mises à jour impliqueront toujours une interruption de service, ce seront aux exploitants et aux intégrateurs de déterminer si cette mise à jour et interruption est nécessaire (de la même façon que le font de nombreux administrateurs systèmes sur leurs serveurs dans le cas d'une maj noyau).
Comme je le disais dans un autre commentaire, je parle pour les constructeurs d'automates, pas pour les exploitants. Je suis parfaitement conscient qu'un exploitant ne peux se permettre de mettre en panne une chaine de production parfaitement fonctionnelle juste pour suivre mes lubies.
Je n'était pas au courant de cas de ce genre, qui sont du coup relativement inquiétant je trouve.
Dans l'ordre :
REST : tout dépend ce qu'on veut en faire, si c'est pour de la configuration, clairement non, trop risqué, si c'est pour de la remontée d'information sur la production, oui cela est sans doute envisageable.
Port 80 et cie. : les pare-feu interdisent généralement cela vers l'extérieur, ce qui est dans notre cas bien vu que l'automate n'a rien à aller voir à l'extérieur dans l'idéal. En interne à l'entreprise, souvent beaucoup de protocoles peuvent être mis en œuvre, et autant en profiter à mon humble avis. (et puis bon, si seul le port 80 est autorisé vers l'extérieur, mauvais IT, changer IT ;)
Webservice : pour les outils de BI et consort, vu que tous ces outils veulent mettre leur nez dans la production, la plupart intègrent un grand nombre de connecteurs pour aller parler à tout le monde, autant en profiter (et vu que tous veulent contrôler le monde, les nouveaux connecteurs arrivent vite).
D'une manière générale, je suis plutôt inquiet quand je voit la complexité et les failles apportées par les choses du port 80 pour le peu de gain par rapport à un protocole qui offrirait les mêmes possibilités sans vouloir être généraliste comme le web.
Oui, et c'est bien là le problème, autant faciliter autant que possible le déploiment de ces patch et cela se passe sur le système des automates pour la plupart des cas. Si la mise à jour est si complexe, c'est aussi parce que l'automate n'intègre rien de semblable à un apt-get. Les processus de mise à jour sont beaucoup trop lourds.
Gérer finnement les permissions des divers utilisateurs est mon avis une meilleure solution, surtout si cela peut éviter une architecture centralisée qui apporte ses faiblesses elle aussi.
Si la partie safety passe par une bonne gestion de la sécurité au sens informatique du terme (et on sait que les deux sont liés) cela est nécessaire, maintenant, je sais que certaines personnes seront contre le fait qu'on touche à leurs systèmes de production, ce qui est un cas relativement classique au final. Je pense sincèrement que ces personnes ont des choses à apprendre concernant la sécurité informatique.
Stuxnet, oui, mais il s'agit là d'une attaque d'une envergure peu commune.
Maintenant, comme le dit Nicolas Boulay, la plupart des attaques actuelles sont faites pour le fun actuellement (un adolescent polonais à fait dérailler un train sans trop comprendre ce qu'il faisait il y a quelques années), mais qui sait ce que les cyber-mafias et autre vont inventer pour monétiser les interruptions de production ou les vols d'informations ?
(concernant les yaourts, j'opterais pour enlever les conservateurs, plus néfaste et vicieux pour le producteur et plus discret, retirer le lait conduirais à un surplus de stock conséquent en quelques heures)
[^] # Re: un petit point vue...
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
Un coté optimiste, dans la plupart de gros cahiers des charges récents, on observe une planification très poussées des systèmes (sécurité, SLA, mises à jour, volumétrie, IOPS), les mentalités seraient-elles entrain d'évoluer dans le bon sens ?
Un coté pessimiste est que la tendance est à coupler le SCADA avec le reste de l'infrastructure IT (voire l'ERP, et autres outils de management!!). Donc on gagne sur la gestion centralisée des utilisateurs, mais on oublie le cloisonnement des réseaux industriels et de gestion : le SCADA devient alors la porte d'entrée pour les hackers vers la partie industrielle. Une cible de choix.
[^] # Re: un petit point vue...
Posté par Geo Vah . Évalué à 1.
En fait, pour les durees de vie, tout depend de ton process. Si c'est un process continue, il est extrement difficile de l'arreter sans penalite financiere.
L'usine de production de verre, un arret = nettoyage du four pour retirer le verre solidifie par une equipe specialise… usine de traitement d'eau et de distribution pour la ville, de gestion de transport de gaz, petrole (oleoduc…) ca devient difficile de considerer un arret non planifie.
L'update via un systeme apt-get est une solution technique, a l'heure d'aujourd'hui je penses que rien ne l'empeche techniquement… Sauf que comme dit precedemment, tu ne vas pas déployé comme ca une mise a jour.
Le probleme de l'update pour moi n'est pas le deploiement mais etre sur que ton systeme COMPLET va fonctionne apres la mise a jour: p-e que ton PLC va etre a jour mais p-e pour x raisons, un probleme de communication via CANopen ou vers les SCADAs va se produire. Dans le cas d'une usine, j'espere que tu consideres le systeme assez complexe pour que ce soit un risque avec une certaine probabilite ;)
Tu vas vouloir d'abord tester en lab que tout fonctionne bien…
Je n'ai aucun doute la dessus… maintenant avec IEC61850 et la partie securite qui va avec, tu commences a avoir un bon gros bousin avec des acces distants, utilisateur centralise pour la partie process, IT et business, on passe dans un autre niveau et j'ai l'impression, que comme dit dans un autre commentaire, je ne suis pas sur que tout le monde veut faire cet investissement.
# Durée de vie
Posté par let antibarbie = xp <- xp - 1 . Évalué à 3.
Pour la durée de vie :
en télégestion
on reçoit encore de temps en temps des appels de clients avec des systèmes de plus de 20 ans qui fonctionnent sans trop de problème (avec des cartes exotiques de communications sur bus ISA !). Bien évidemment, plus aucun support technique n'est possible dans ces situations, et aucune sécurité n'a été mise en place à l'époque.
Cela n'a pas l'air d'inquiéter les exploitants qui jouent la carte du moindre coût. (nb: on l'observe au niveau informatique : la redondance a parfois déjà joué son rôle à plusieurs niveaux, les disques RAID à moitié bousillés et les machines redondantes déjà grillées depuis longtemps). Bref, c'est plutôt folklorique dans les usines en France (heureusement ce n'est pas non plus une généralité).
Le risque au niveau sécurité, principalement un vol de données d'exploitation, accessibles à distance et consultées en clair et sans mot de passe.
dans les usines et dans le contrôle anti-pollution
tu as également des systèmes qui perdurent depuis plus de 15 ans, et qui sont régulièrement patchés pour coller aux normes, mais on ne voit aucune évolution des automatismes ni des systèmes informatiques, et certainement pas au niveau de la sécurité.
Le risque reste cependant limité, piratage par un concurrent pour que la DREAL ferme l'usine ou pénalise financièrement l'exploitant (?).
en production
Il y a aussi un certain nombre de groupes qui suivent les préconisation des constructeurs, et profitent d'une amélioration de l'usine pour effectuer les mises à jour des automates.. mais dans ce que j'ai pu constater ces dix dernières années, ça reste tout de même une minorité.
Pour l'anecdote, on a environ une fois par mois des responsables de maintenance, qui appellent paniqués pour savoir si on peut dépanner leur unique automate grillé (souvent obsolète) et nécessaire à la production de l'usine..
# tres tres souvent obsolète
Posté par hitmanu . Évalué à 1.
j'ai eu a faire l'entretien de l'unique ordinateur sous windows 3.11 avec carte ISA memoire edo (un 386) nécessaire à la production de l'entreprise, après avoir téléphoner au concepteur du progiciel utiliser par l'entreprise, toute la chaîne devais être changer, 150000 euro pour une trieuse de poireau ca fait mal. ;)
les progiciels propriétaire coute tres chère au entreprise puisqu'il sont prévue de fonctionner sur un temps tres cours et devienne obsolète (pas d'évolution possible).
il existe pourtant la possibilité d'utiliser le libre pour faire fonctionner de vieux système et pourtant les entreprise continu a faire le choix du proprio et ce plaigne que l on ne peut plus les dépanner a moindre couts.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: tres tres souvent obsolète
Posté par droopy191 . Évalué à 2.
Le problème est bien souvent le matériel. Dernier exemple en tete, une enceinte climatique de labo qui est pilotée par un pc ( pentium, carte d’acquisition sur bus isa, tournant sous dos). Le PC se mettait en sécurité et rendait inopérant l'enceinte. Le fournisseur avait encore du stock pour remplacer, 4000 EUR pièce, mais ca vaut mieux que de remplacer tout le système !
Ca c'est bien fini, un bete ventilo de proc à 5EUR, jusqu'a une vraie panne ou il faudra passer à la caisse.
Dans les process industriels, le problème n'est en général pas l'automate en premier. C'est plutot les "accessoires": pc de supervision, capteurs qui ont évolué et qui nécessite de retoucher à l'automate. Meme si ce n'est pas du libre, l'accès aux sources est indispensable pour pouvoir faire ce genre de modifs.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: tres tres souvent obsolète
Posté par droopy191 . Évalué à 2.
L'accès aux sources permet d'adapter le logiciel à un nouveau matériel si l'ancien ne se fabrique plus. Les specs seraient sur le principe suffisantes, mais la il s'agit de réparer/adapter, pas de partir de la feuille blanche.
Quand à virtualiser un capteur ( camera, pression, mouvement… ), la je ne vous suis pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: tres tres souvent obsolète
Posté par Marotte ⛧ . Évalué à 1.
Il y a combien de temps ?
Pas que je doute qu'il existe encore de telle configuration dans certaines entreprises, mais par curiosité :)
Moi en tant que prestataire je verrais ça comme une aubaine. Un SI qui tourne sur un 386 c'est pas très compliqué d'isoler les besoins et de fournir une solution à base d'un PC moderne et d'utilitaires libres ad-hoc…
[^] # Re: tres tres souvent obsolète
Posté par hitmanu . Évalué à 4.
c'était en janvier 2011 et pour la virtualisation sur du libre, je lui ai deja proposer mais ils ont préférer s'en remettre au vendeur proprio qui leur propose un dépannage sur site pendant deux année apres installation du matériel neuf.
aller comprendre pour quoi.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: tres tres souvent obsolète
Posté par Anonyme . Évalué à 4.
mauvaise gestion du risque ? Le risque fait peur. Je passe mon temps a essayer de convaincre qu'une modification ou mis a jour n'a pas de risque. Si je commence a parler de risque adieu ma modification qui permettra de gagner plein de sous. Ou la mis a jour qui permettra de gagner du temps.
Je déporte le risque sur moi :), jusqu’à présent je n'ai jamais eu de probleme, mais cela peu arrivé. Le gain est assez énorme par rapport a la probabilité que cela foire.
Une fois avec un technicien nous avons attendu que le staff soit en rtt + vacances pour effectuer une amélioration que personne ne voulait voir, à cause du risque de couper la production pendant un temps incertain. Le gain était de 30 minute de production en plus par jour \o/. Personne n'a rien vu, mais tous le monde étais satisfait que les chiffres augmentent grâce au management de la nouvelle direction.
[^] # Re: tres tres souvent obsolète
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Personne n'a vu la mise à jour après coup ?
"La première sécurité est la liberté"
[^] # Re: tres tres souvent obsolète
Posté par Anonyme . Évalué à 2.
non, juste que cela marchait mieux, mais 30mn/j sur 16h de production c'est assez peu pour que cela se remarque. C'est le problème pour convaincre, prendre le risque pour pas grand choses /j, quand je parlais en années je pense que je perdais mes interlocuteurs assez rapidement.
# Et la disponibilité ?
Posté par OlivierA . Évalué à -3.
J'ai pas lu tous les commentaires, mais il ne me semble pas que le problème de disponibilité ait été abordé ?
Est ce qu'il y a des modèles de (haute) disponibilité sur les automates ?
Sinon la domotique Linux commence à émerger: domotique mais pour avoir regardé il y a quelques mois c'est encore dans le registre de la béta.
[^] # Re: Et la disponibilité ?
Posté par porki . Évalué à 2.
La disponibilité a été abordée plusieurs fois :) (cf. arrêt de la chaîne de production, coupure non-programmée, ect).
Est ce qu'il y a des modèles de (haute) disponibilité sur les automates ?
Comme les simples PC, la haute disponibilité se retrouve sur plusieurs points : sur l'architecture de l'automate lui-même (redondance des alimentations, redondance des cartes de communication, …) et sur l'architecture de l'ensemble (automates en doubles, double réseau informatique / bus de terrain, …). Évidemment, si tu as une vanne motorisée qui ne peut être actionnée (partie "commande") que par un seul automate, c'est alors sur l'architecture de ton processus indus qu'il faut agir (par exemple, construire 2 chemins de vapeurs pour aller du point A au point B, avec aucune vanne commune aux deux chemins). Pour le "contrôle", on peut parfois agir sur une redondance des mesures : on sait qu'une cuve est remplie lorsque le poids de celle-ci atteint X kg mais aussi que le flotteur atteint une hauteur de y cm. Si un capteur (ou l'automate auquel le capteur est relié) ne remonte pas l'info, alors l'autre capteur apporte l'information permettant de continuer à faire tourner le processus industriel. Dans ce dernier cas, c'est assez complexe car il faut rajouter des mécanismes d'élection : si 2 infos contradictoires, dois-je tout arrêter ou prendre l'information la plus prudente ou prendre l'information la plus plausible ?
Je ne me suis pas allé plus loin que la lecture de quelques docs concernant la domotique sous Linux, pourtant j'avais cru voir qu'il y avait pas mal de choses bien aboutie …
[^] # Re: Et la disponibilité ?
Posté par OlivierA . Évalué à -2.
Ok, merci pour les précisions,
La gestion de la disponibilité se fait comment ? Par développement spécifique sur firmware ou sur OS, ou par des produits sur étagères (gestion des redondances réseaux, heartbeat …). Il y a des choses sous Linux pour la disponibilité (http://www.linux-ha.org/)
Pour la domotique j'attends d'emménager pour tester :)…
[^] # Re: Et la disponibilité ?
Posté par porki . Évalué à 3.
On peut dire que très souvent l'automate est très loin du PC que tu as à la maison ou au travail. On est plutôt à charger des firmwares ou des programmes très spécifiques, fournis par le constructeur, sur du matériel spécialisé. On n'est pas à installer un Linux sur un PC avec comme seule carte exotique, la carte graphique NVidia. Donc si tu penses acheter un "automate", y installer un Linux avec hearthbeat, VRRPD, watchdog et y coller 2-3 scripts shells de ton cru, c'est que l'on ne parle pas du même "automate".
Les niveau 1 et 2 sont des mondes très particuliers où tu ne peux pas bidouiller les firmwares sans être très calé techniquement. Tu peux essayer d'ajouter des services en ajoutant des matériels tiers, mais ce n'est pas toujours possible car la marge de manœuvre laissée par le constructeur d'automate est généralement assez faible.
En revanche, le niveau 3 est de plus en plus tourné vers les technos IP récentes, donc tu peux espérer mettre en place les technos dont tu parles.
[^] # Re: Et la disponibilité ?
Posté par OlivierA . Évalué à -4.
Oui, je sais bien que bien souvent le hardware est un développement spécifique, donc difficile d'en trouver les drivers sur Internet :), le reverse engineering est souvent la seule possibilité d'ailleurs.
Mais d'un point de vue robotique, automate, on voit des choses dans le commerce qui doivent pouvoir être exploités sur une base de plateforme Linux (http://www.conrad.fr/. J'avais remarqué des petits drones volants pilotés à partir d'un Iphone …
Mais pour l'instant ce n'est pas mon métier, je m'intéresse juste …
Mon métier porte plutôt sur l'impact d'un logiciel sur la société comme par exemple Facebook, Twitter, Google
# la domotique Linux commence à émerger
Posté par hitmanu . Évalué à 0. Dernière modification le 08 août 2012 à 22:23.
si les entreprises étaient moins frileuses concernant ces grands changements, la domotique sous linux aurait été bien plus avancée aujourd'hui, il y a 25 ans je me souviens que les machines outils utilisaient le cobol, aujourd'hui les proprios ont pris une place importante dans tous les domaines, on peut espérer que le libre prenne la relève demain si quelques entreprises en font une bonne pub.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: la domotique Linux commence à émerger
Posté par Marotte ⛧ . Évalué à 3.
-1 pour les fautes :/ Il y en a trop.
[^] # Re: la domotique Linux commence à émerger
Posté par BAud (site web personnel) . Évalué à 6.
Nous avons réussi à aider (et motiver) Beretta_Vexee à une époque (dysorthographie importante… bien moindre 5 ans après), ici c'est une méconnaissance des pluriels, ça devrait pouvoir s'arranger par une relecture attentive - tourner son clavier 7 fois avant d'appuyer sur prévisualiser puis se relire - et un peu d'encouragement :)
[^] # Re: la domotique Linux commence à émerger
Posté par Marotte ⛧ . Évalué à 2.
Tin, ya des tites fourmis qui corrigent les fautes des commentaires sur linuxfr.org :)
[^] # Re: la domotique Linux commence à émerger
Posté par hitmanu . Évalué à -2.
désoler pour les faute d'orthographe je n'ai pas ete un élève tres douée a l'école (le première des dernier),
alors je me rattrape dans d'autre langage. ;)
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
# milieu excessivement fermé ?
Posté par Firwen (site web personnel) . Évalué à 6.
Ce qui m'a toujours étonné dans le milieu industriel, c'est le coté excessivement fermé/propriétaire de la chose.
On déploie des solutions siemens/téléméca manipulables que par le soft éditeur, dans un language souvent pas portable (ST, ladder)
sur des bus proprio ( profibus << ), supervisé par encore un/des soft proprio bien souvent avec un PC sur Windows 2000/XP proprio….
Il n'est pas très étonnant de voir le milieu effrayé par les mise à jour dans une magnifique usine à gaz pareil:
- la marge de manœuvre des techniciens en cas de mise à jour foireuse est quasiment null et le risque n'en vaut pas la chandelle.
- la portabilité du code d'une solution à l'autre est un cauchemar pour 20k raisons : bus pas compatible, supervision par compatible, code tout simplement pas portable.
- le 3/4 du temps dans les "GROS" milieu industrielle le code a été généré par un générateur,… et patché 20 x depuis : résultat plus personne n'ose y toucher car PERSONNE ne le comprend.
- le coté souvent périmé des technos, fait que si tu veux changer 2% de l'installation, tu dois finalement changer 60% de l'installation.
Ce qui me désespère encore plus, c'est que rien mais strictement RIEN niveau technique dans ce secteure st impossible à faire avec un ensemble driver / OS / languages OSS….
[^] # Re: milieu excessivement fermé ?
Posté par Anonyme . Évalué à 3.
Voilà, les langages sont comme ils sont mais le matériel est tellement varié et l'univers dans lequel va évoluer notre code/grafcet est tellement restreint que, comme dit dans l'article, il faudrait tout jeter à la poubelle, laisser ceux qui savent faire de la sécurité faire de la sécurité et repartir sur du vrai neuf.
Mais même en formation de toute façon, la qualité du code est mise de côté. « vous verrez ça sur le tas » ouais, mais en fait non, sur le tas c'est une catastrophe parce que tout le monde a fait sur le tas et avec une formation pourrie, ou avec énormément de manquements et où ne nous dit même pas ce qu'il y a dans cet article (pourtant c'est très rapide à lire).
En fait, je pense que c'est le « on est jamais mieux servi que par soi-même » des entreprises de conception d'automates/logiciels poussé à l’extrême. Du coup… ça finit par dé-servir.
[^] # Re: milieu excessivement fermé ?
Posté par OlivierA . Évalué à -4.
Le problème vient du modèle économique et du modèle organisationnel, sociologique. On a d'une part des dirigeants qui ne conçoivent l'économie qu'en terme de prédation et d'autre part une organisation industrielle qui échappe à la rationalisation par les gouvernements successifs.
Ce qui se traduit par le fait que tous les geeks de LinuxFR sont en esclavage en sociétés de service :)
hehe
# SSL
Posté par Krunch (site web personnel) . Évalué à 3.
Présenter une interface HTTPS ne se résume pas à installer {Open,ya,Polar}SSL ou même à écrire une pile SSL/TLS valide. Il faut aussi un certificat qui corresponde au nom d'hôte via lequel l'interface est exposé. Ce qui signifie qu'il faut une intégration spécifique du côté de l'exploitant qui n'a pas forcément une infrastructure de clef publique en place.
Bon après, je sais pas si c'est la raison principale pour laquelle ces composants n'authentifient pas leur flux réseaux mais personnellement je préfère du HTTP en clair que du HTTPS mal fait qui donne une fausse impression de sécurité.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.