publier des mises à jour quand le besoin s'en fait sentir ;
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…
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).
mettre à la poubelle les automates des années 90 et 2000 pour repartir sur des bases saines
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".
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 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
Je n'était pas au courant de cas de ce genre, qui sont du coup relativement inquiétant je trouve.
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 ?
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.
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…
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.
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?
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.
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?
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.
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 ?
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 RbN . En réponse à la dépêche État des lieux de la sécurité industrielle. É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)