DesignSpark Electrical Logolinkedin
Ask a Question

30 Jul 2019, 7:33

Quand l'automatisation classique rencontre le monde étranger de l'informatique : Partie 3

Le grand public utilise souvent les termes « sécurité » et « sûreté » indistinctement. Commençons alors par d'abord expliquer le sens que l'industrie de l'automatisation donne à ces termes :

La sécurité est une condition que vous pouvez établir en assurant la protection contre les dommages involontaires. Un airbag d'automobile est un parfait exemple de dispositif de sécurité, qui évite que le conducteur ne soit projeté contre le pare-brise lorsque le véhicule s'écrase contre un obstacle soudain. 

La sûreté en revanche est la protection contre les intentions nuisibles. Ces types de préjudices sont causés par des actes d'intrusion, d'agression ou de destructions intentionnelles. Un exemple de dispositif de sûreté est un système antidémarrage de voiture, qui protège le propriétaire contre le vol de son véhicule.

En résumé, nous pouvons dire que "la sécurité protège des accidents, tandis que la sûreté protège des délinquants". Voyons à présent ce que cela signifie dans une usine de production en règle générale :

La sûreté a toujours été le domaine des services de sécurité des usines, un domaine qui leur est souvent réservé. Leur tâche est d'empêcher les personnes étrangères à l'usine de pénétrer dans certains endroits, de faire entrer ou sortir des marchandises ou d'altérer les équipements. Aujourd'hui, la protection des usines dépend principalement de la sûreté informatique et, par conséquent, les services informatiques collaborent de plus en plus souvent étroitement avec les services de sécurité. Les intrusions, les abus ou les actes de destruction peuvent être menés beaucoup plus efficacement et à distance en accédant aux réseaux informatiques des usines. La connexion des réseaux des usines à internet donne lieu à de nouvelles problématiques de "cybersécurité". Les dispositifs que l'on appelle "pare-feux" ont l'objectif de bloquer le trafic de données indésirables de franchir les limites de l'usine. La mise en place de zones de sécurité (similaires à des "zones démilitarisées" ou DMZ) séparées par des pare-feu optimise encore ce principe d'encapsulation. D'ailleurs, la protection de votre maison contre les cambriolages pourrait répondre aux mêmes principes : votre maison doit être correctement séparée du monde extérieur grâce à des portes et des fenêtres. Les éléments de valeur nécessitent une protection de plus haut niveau en les enfermant dans une "enveloppe plus profonde" comme un coffre-fort (qui, soit dit en passant, n'est PAS un dispositif de sécurité mais un dispositif de sûreté....).

Traditionnellement, la sécurité des usines a toujours été le domaine des ingénieurs en automatisation et du service Hygiène et Sécurité. C'est également très souvent un domaine qui leur est réservé, en particulier la "sécurité fonctionnelle", qui est complexe et fait appel à des ingénieurs qualifiés (p. ex. CSME). Le processus type permettant d'établir des conditions de sécurité commence par l'analyse des défaillances potentielles. Des méthodes comme l'AMDE (analyse des modes de défaillance et de leurs effets) ou la FTA (analyse par arbre de défaillances) aident les ingénieurs en sécurité à détecter les potentiels risques de défaillance ou d'accident. Les systèmes de notation comme le "RPN" (indice de priorité des risques) participent également à l'évaluation du risque. On commence par énumérer les conditions indésirables (préjudiciables) d'un système, puis on essaie de faire une liste de toutes les causes possibles de ces conditions (défaillances), à quelle fréquence elles sont susceptibles de se produire et comment les détecter. L'étape suivante est alors de planifier les réactions du système ou les moyens d'anticiper les causes. En d'autres termes : il faut planifier des mesures pour empêcher les défaillances.

Pour cela, on ajoute généralement des équipements au système (p. ex. pour rendre certaines fonctions redondantes) ou on utilise certains équipements de sécurité "certifiés" dont le taux de défaillance est faible. Il existe par exemple des versions "sûres" des bus de terrain comme Profibus (appelé ProfiSafe). Le maître et l'esclave (voir partie 2) échangent de façon cyclique des données sur la sécurité via des télégrammes spéciaux. Les télégrammes corrompus peuvent être détectés car les données sont vérifiées par une redondance élevée (CRC). Un dispositif de surveillance supplémentaire à l'intérieur du dispositif de sécurité (esclave) se déclenche et fait basculer l'appareil dans un "état de sécurité" dès que le maître ne reçoit pas de télégramme valide dans un court délai défini.

NE JAMEIS MODIFIER UN SYSTèME SûR EN FONCTIONNEMENT

NE Jamais manquer les mises à jour de sécurité !

L'ajout de nouvelles procédures ou de nouveaux composants dans un système sûr bien établi nécessite toujours une nouvelle analyse et certification de sécurité. Par conséquent, les systèmes de sécurité sont en général être exploités selon le principe consistant à "ne jamais modifier un système en fonctionnement". Les systèmes de sécurité, d'autre part, ont tendance à être exploités en fonction de la demande : "changez vos secrets avant que les pirates puissent les intercepter". Ces stratégies semblent être contradictoires, mais en réalité, les deux domaines parviennent à s'accorder :

Dans l'automatisation, les ingénieurs tentent de dissocier (capsule) les composants système sûrs des éléments "dangereux" (c.-à-d. non approuvés pour une exploitation sûre). Il est donc possible d'ajouter et de modifier certaines parties d'un système à condition de ne pas introduire de nouveaux risques pour la sécurité et tant que cela n'empêche pas les dispositifs de sécurité de prévenir les préjudices. Par exemple, si l'on empêche les ouvriers de toucher les pièces en rotation en arrêtant la rotation dès que le couvercle d'une enceinte de protection est ouvert, il est possible de modifier les pièces n'ayant rien à voir avec la sécurité en dehors ou à l'intérieur de l'enceinte. La modification de l'enceinte, des capteurs qui détectent l'ouverture de l'enceinte, des systèmes électroniques qui arrêtent la rotation ou même de l'entraînement qui provoque la rotation pourrait changer les facteurs de risque et l'analyse de la défaillance. Par conséquent, ces pièces font partie du concept de sécurité. Mais l'ajout d'un capteur qui communique l'état via le cloud n'aurait aucune incidence sur les dispositifs de sécurité empêchant les ouvriers de toucher les pièces en rotation.

En matière de technologie de sécurité, les ingénieurs en informatique ont dû trouver un moyen de passer les frontières des systèmes et d'établir une communication sécurisée entre les systèmes distribués, même sur internet. Le chiffrement a été la solution à ce problème depuis. Le principe est d'envoyer des enveloppes scellées avec des informations codées au lieu d'envoyer des cartes postales depuis votre domicile. Le décodage requiert d'être en possession d'une clé pré-négociée. Bien sûr, les pirates ont toujours pour objectif de contourner ce chiffrement. Une amélioration des méthodes de chiffrement est donc une condition essentielle à la sécurité. Cependant, le chiffrement est beaucoup plus stable que le tout reste d'un système basé sur internet. Les protocoles internet et les outils standards, ou encore les langages comme HTML, Java, etc. ont tendance à être vulnérables. Ils fournissent souvent des portes dérobées imprévues, et les pirates se font un plaisir de les découvrir au quotidien. Par conséquent, la mise à jour régulière de ces composants avec les versions les plus récentes et exemptes de vulnérabilités est essentielle. Tout système connecté à internet sans possibilité de mises à jour de sécurité est une victime idéale pour les pirates.

Alors comment faire face à tout cela quand il s'agit de l'IIoT ? La séparation, le chiffrement et les mises à jour OTA (sans fil) sont des moyens efficaces pour combiner sécurité et sûreté dans l'industrie de l'automatisation.

La séparation peut être réalisée en connectant les systèmes de contrôle et leurs bus internes pour une communication M2M avec un module passerelle. Ce module sépare strictement le trafic des données du côté de l'automatisation du trafic de données sur internet. Celui-ci ne fait jamais partie d'un concept de sécurité et, par conséquent, peut et doit disposer d'un micrologiciel pouvant être mis à jour. Ces mises à jour peuvent rarement être nécessaires (p. ex. en cas de mise à jour des méthodes de chiffrement) ou l'être plus fréquemment, selon le degré d'interopérabilité : par exemple, si la passerelle dispose d'un serveur web intégré, il pourrait y avoir de nombreux moyens encore inconnus d'attaquer le système qui devraient être éliminés dès qu'ils sont découverts.

Mais au lieu d'utiliser une passerelle dédiée (similaire à certains égards à un pare-feu), il est aussi possible de séparer les éléments en utilisant des capteurs spécialisés supplémentaires qui communiquent directement sur internet. Dans les deux scénarios, il est nécessaire de disposer de méthodes de chiffrement et d'un moyen d'authentification pour assurer la cybersécurité. Les services sur le cloud comme AWS ou Azure (pour ne citer que les deux systèmes les plus utilisés) proposent une boîte à outils complète pour l'authentification et le chiffrement côté serveur. Mais quand il s'agit des capteurs ou des passerelles, nous quittons le monde de l'informatique pour entrer dans le monde de l'intégré. Les systèmes ont moins de ressources et de puissance CPU et ont souvent du mal à assumer l'énorme puissance de calcul nécessaire pour les processus de chiffrement. Mais l'industrie des puces électroniques a pris conscience de ce besoin et propose souvent des co-processeurs de chiffrement sur leurs SOC (systèmes sur puce). Il est aussi possible d'utiliser des "puces de chiffrement" spécifiques à la conception système. Le plus grand obstacle pour l'application de méthodes de chiffrement et d'authentification dans les systèmes intégrés est le manque d'ingénieurs en matériel informatique et en logiciels formés et qui sont familiers avec les techniques de programmation intégrée et les méthodes de sécurité informatique. D'autre part, nous avons souvent eu l'occasion de nous entretenir avec des programmeurs qui ne comprenaient pas les difficultés inhérentes à l'extraction des données d'un système de commande industriel ou même d'un système de sécurité. Ils ont tendance à mal considérer le principe de "Ne jamais toucher un système en fonctionnement", et ne respectent pas qu'il s'agit d'une méthode approuvée pour protéger les actifs qui sont souvent en fonctionnement depuis des décennies et non depuis seulement deux ans comme un smartphone ou un serveur.

L'IIoT a un besoin urgent d'une nouvelle culture de coopération et d'éducation entre les ingénieurs en informatique et les ingénieurs en automatisation. Les deux aspects sont essentiels pour I4.0 et, par conséquent, les ingénieurs doivent connaître et respecter l'histoire de chacun et apprendre les uns des autres. Parce que les concepts sont si différents, il est difficile pour un ingénieur en automatisation d'entrer dans le monde de la cybersécurité, mais c'est possible. Les entreprises devraient encourager leurs programmeurs du monde de l'intégré à améliorer leurs compétences en matière de sûreté. Les experts en sûreté informatique doivent essayer d'adapter leur langage pour s'adresser aux ingénieurs du monde de l'intégré comme s'ils étaient des débutants. Il ne faut pas présumer que ces derniers connaissent la signification de "clé privée" ou de "certificat", se montrer compréhensif et expliquer plutôt que se renfrogner.

Dans la dernière partie, à venir bientôt, nous aborderons les solutions open source, et les raisons pour lesquelles nous ne devons pas craindre de partager la propriété intellectuelle lorsque l'automatisation rencontre l'IIoT.

Partie 1 & Partie 2 précédentes

Partie 4 suivante

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (and his MD grade). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.

30 Jul 2019, 7:33

Commentaires