Sécuriser l'usine intelligente du futur
Ces dernières années ont été ponctuées de bon nombre de cyberattaques contre des infrastructures industrielles. À l'heure actuelle, ces incidents sont assez rares et leurs conséquences ont été essentiellement économiques, mais supposer qu'ils resteront des actes isolés et sans risques majeurs dans le futur semble être une voie très dangereuse à suivre.
Si certaines cyberattaques ont des objectifs financiers clairs (ransomware ou rançongiciels en français), d’autres sont apparemment sans motif apparent : par jeu ou défi ou dans certains cas pour faire une démonstration des risques à venir tels que les.
L’illustration parfaite est la cyberattaque qui a eu lieu en novembre 2011, lorsque des pirates informatiques ont volé des mots de passe et les ont ensuite utilisés pour accéder à un système SCADA (Supervisory Control And Data Acquisition) appartenant à un service d'eau1. On pense qu'ils ont réussi à détruire une pompe alimentant des milliers de maisons dans une ville américaine de l'Illinois tout simplement en l'allumant et en l'éteignant rapidement.
À la fin de 2014, une aciérie allemande a été la cible d'une cyberattaque similaire lorsque des pirates ont réussi à prendre le contrôle d'un système logiciel SCADA et causé des dommages matériels importants au site2. Les attaquants ont d'abord piraté le réseau du système d’information du site industriel, et l'ont utilisé pour pénétrer dans le logiciel de gestion de production de l'aciérie. De là, ils ont accédé à la plupart des systèmes de contrôle de l'usine et ont ensuite détruit méthodiquement les interfaces homme-machine. Ils ont réussi ainsi à empêcher un haut fourneau d'initier ses réglages de sécurité à temps et ont causé de graves dommages à l'infrastructure.
Ailleurs, les cyberattaques semblent parfois plus motivées politiquement. Le 23 décembre 2015, des attaquants ont accédé à distance à des systèmes SCADA ukrainiens pour couper l'alimentation de 17 sous-stations et refuser l'accès aux lignes téléphoniques de l'entreprise pour retarder la réintégration du courant3. Plusieurs mois avant la coupure du courant, les attaquants avaient commencé à envoyer des courriels d'hameçonnage aux bureaux des compagnies d'électricité ukrainiennes. Une fois ouverts, ces e-mails ont installé des logiciels malveillants. Les pare-feu ont été conçus pour séparer les ordinateurs concernés des systèmes de contrôle de l'alimentation, mais le logiciel malveillant BlackEnergy 3 a permis aux pirates informatiques de rassembler des mots de passe et des connexions permettant de lancer une attaque sur le système SCADA lui-même.
Quelques années plus tôt, en 2010, l'attaque bien documentée de Stuxnet était un exemple sophistiqué de logiciel malveillant qui visait une cible très spécifique et bien protégée, l'usine d'enrichissement d'uranium de Natanz en Iran4. Non seulement l'attaque a atteint sa cible, mais elle a causé des dommages importants sur le site complet et a été qualifiée de «première arme numérique» par les médias.
Quatre exemples de cyberattaques sur des infrastructures essentielles à la sécurité dans quatre secteurs industriels distincts. Malgré leur nature disparate, l'existence d'une voie d'accès d'Internet à un domaine critique pour la sécurité est clairement commune à chacun d'entre eux.
Interopérabilité avec la sûreté et la sécurité
De nos jours, il existe différents référentiels ou frameworks pour guider les ingénieurs devant concevoir, développer et déployer un réseau Internet industriel interopérable, sûr et sécurisé. En particulier, le Industrial Industrial Consortium (IIC) et le groupe de travail Industrie 4.0 ont élaboré des directives et des recommandations sous la forme de l’Architecture de Référence pour L’internet Industriel (Industrial Internet Reference Architecture - IIRA) et du modèle architectural de référence pour l'industrie 4.0 (Reference Architectural Model for Industrie 4.0 - RAMI 4.0). De par la similitude des attributions pour chacun de ces documents, il existe des similarités ainsi que des chevauchements entre ces deux référentiels, comme en témoignent les diverses discussions et coopérations en cours entre ces deux organisations.
Ces deux consortiums reconnaissent qu'une sécurité forte est une exigence essentielle pour l'IoT industriel. En effet, l’IIC a récemment introduit le Cadre de sécurité de l'Internet Industriel (Industriel Internet Security Framework - IISF)5 afin de définir les bonnes pratiques de développement et de conception à cet égard, et comme ces deux groupes travaillent ensemble pour s'aligner dans un certain nombre de domaines, la sécurité a été identifiée comme une question clé.
Le défi de sécurité peut être visualisé par l’exemple d’une usine imaginaire, dans laquelle il y aurait beaucoup de demandes et d’interopérabilité sur son infrastructure et ses systèmes informatiques (de toute nature SI, Contrôle-commande). Les capteurs permettent de collecter des données telles que l'emplacement, la position, la vitesse, la température, la pression, l'état de verrouillage et la vibration de tous les actifs en temps quasi réel aux opérateurs ou organes de contrôle. À un niveau de sécurité plus élevé, les paramètres de gestion et de contrôle du processus industriel voire même les micro-logiciels (firmwares) des équipements peuvent être mis à jour à distance, et ce peut-être en réponse à l’analyse des données collectées, ou suivant des demandes de changement de la production. Et à un autre niveau, ces données sont liées aux chiffres de production et de rentabilité, elles-mêmes agrégées aux données commerciales/marketing/stratégiques et le tout partagé sur d’autres réseaux, fournissant des maux de tête de sécurité d'un genre différent.
La figure 1 montre comment RAMI 4.0 extrait ces considérations dans une matrice tridimensionnelle, composée de couches, d'un cycle de vie et d'un flux de valeur, et de niveaux de hiérarchie.
Si certaines cyberattaques ont des objectifs financiers clairs (ransomware ou rançongiciels en français), d’autres sont apparemment sans motif apparent : par jeu ou défi ou dans certains cas pour faire une démonstration des risques à venir tels que les.
L’illustration parfaite est la cyberattaque qui a eu lieu en novembre 2011, lorsque des pirates informatiques ont volé des mots de passe et les ont ensuite utilisés pour accéder à un système SCADA (Supervisory Control And Data Acquisition) appartenant à un service d'eau1. On pense qu'ils ont réussi à détruire une pompe alimentant des milliers de maisons dans une ville américaine de l'Illinois tout simplement en l'allumant et en l'éteignant rapidement.
À la fin de 2014, une aciérie allemande a été la cible d'une cyberattaque similaire lorsque des pirates ont réussi à prendre le contrôle d'un système logiciel SCADA et causé des dommages matériels importants au site2. Les attaquants ont d'abord piraté le réseau du système d’information du site industriel, et l'ont utilisé pour pénétrer dans le logiciel de gestion de production de l'aciérie. De là, ils ont accédé à la plupart des systèmes de contrôle de l'usine et ont ensuite détruit méthodiquement les interfaces homme-machine. Ils ont réussi ainsi à empêcher un haut fourneau d'initier ses réglages de sécurité à temps et ont causé de graves dommages à l'infrastructure.
Ailleurs, les cyberattaques semblent parfois plus motivées politiquement. Le 23 décembre 2015, des attaquants ont accédé à distance à des systèmes SCADA ukrainiens pour couper l'alimentation de 17 sous-stations et refuser l'accès aux lignes téléphoniques de l'entreprise pour retarder la réintégration du courant3. Plusieurs mois avant la coupure du courant, les attaquants avaient commencé à envoyer des courriels d'hameçonnage aux bureaux des compagnies d'électricité ukrainiennes. Une fois ouverts, ces e-mails ont installé des logiciels malveillants. Les pare-feu ont été conçus pour séparer les ordinateurs concernés des systèmes de contrôle de l'alimentation, mais le logiciel malveillant BlackEnergy 3 a permis aux pirates informatiques de rassembler des mots de passe et des connexions permettant de lancer une attaque sur le système SCADA lui-même.
Quelques années plus tôt, en 2010, l'attaque bien documentée de Stuxnet était un exemple sophistiqué de logiciel malveillant qui visait une cible très spécifique et bien protégée, l'usine d'enrichissement d'uranium de Natanz en Iran4. Non seulement l'attaque a atteint sa cible, mais elle a causé des dommages importants sur le site complet et a été qualifiée de «première arme numérique» par les médias.
Quatre exemples de cyberattaques sur des infrastructures essentielles à la sécurité dans quatre secteurs industriels distincts. Malgré leur nature disparate, l'existence d'une voie d'accès d'Internet à un domaine critique pour la sécurité est clairement commune à chacun d'entre eux.
Interopérabilité avec la sûreté et la sécurité
De nos jours, il existe différents référentiels ou frameworks pour guider les ingénieurs devant concevoir, développer et déployer un réseau Internet industriel interopérable, sûr et sécurisé. En particulier, le Industrial Industrial Consortium (IIC) et le groupe de travail Industrie 4.0 ont élaboré des directives et des recommandations sous la forme de l’Architecture de Référence pour L’internet Industriel (Industrial Internet Reference Architecture - IIRA) et du modèle architectural de référence pour l'industrie 4.0 (Reference Architectural Model for Industrie 4.0 - RAMI 4.0). De par la similitude des attributions pour chacun de ces documents, il existe des similarités ainsi que des chevauchements entre ces deux référentiels, comme en témoignent les diverses discussions et coopérations en cours entre ces deux organisations.
Ces deux consortiums reconnaissent qu'une sécurité forte est une exigence essentielle pour l'IoT industriel. En effet, l’IIC a récemment introduit le Cadre de sécurité de l'Internet Industriel (Industriel Internet Security Framework - IISF)5 afin de définir les bonnes pratiques de développement et de conception à cet égard, et comme ces deux groupes travaillent ensemble pour s'aligner dans un certain nombre de domaines, la sécurité a été identifiée comme une question clé.
Le défi de sécurité peut être visualisé par l’exemple d’une usine imaginaire, dans laquelle il y aurait beaucoup de demandes et d’interopérabilité sur son infrastructure et ses systèmes informatiques (de toute nature SI, Contrôle-commande). Les capteurs permettent de collecter des données telles que l'emplacement, la position, la vitesse, la température, la pression, l'état de verrouillage et la vibration de tous les actifs en temps quasi réel aux opérateurs ou organes de contrôle. À un niveau de sécurité plus élevé, les paramètres de gestion et de contrôle du processus industriel voire même les micro-logiciels (firmwares) des équipements peuvent être mis à jour à distance, et ce peut-être en réponse à l’analyse des données collectées, ou suivant des demandes de changement de la production. Et à un autre niveau, ces données sont liées aux chiffres de production et de rentabilité, elles-mêmes agrégées aux données commerciales/marketing/stratégiques et le tout partagé sur d’autres réseaux, fournissant des maux de tête de sécurité d'un genre différent.
La figure 1 montre comment RAMI 4.0 extrait ces considérations dans une matrice tridimensionnelle, composée de couches, d'un cycle de vie et d'un flux de valeur, et de niveaux de hiérarchie.
Figure 1 Reference architecture model for Industrie 4.0 (RAMI 4.0)6
Ceci est une représentation étonnamment similaire aux «domaines fonctionnels» et aux «points de vue» préférés par le modèle IRA IIRA (Figure 2).
Representation of IIC Functional Domains and Viewpoints
Pour comprendre comment créer des fondations sûres pour l'un ou l'autre de ces schémas, il est important de rappeler que ces deux approches représentent la réunion de deux mondes traditionnellement distincts : celui des systèmes d’informations (Information Technology - IT) et celui des systèmes opérationnels (Operational Technology – OT). Dans l’OT, la sécurité est souvent assurée par la nature même du système, qui est bien souvent isolé et d’architecture exclusive, tandis que la sécurité informatique est axée sur la protection des actifs de l'entreprise. Les relier ensemble expose la sécurité des deux systèmes, simplement parce que cela implique dans chaque cas de fournir un moyen d'accès potentiel de l’un vers l’autre pour lequel ils n'ont pas été conçus.
Il est donc clair que quelles que soient les différences et les similitudes entre les architectures, l'isolement d'un domaine par rapport à un autre est une caractéristique essentielle de toute implémentation pour en garantir la sécurité. En particulier, la compartimentation des données est essentielle, de sorte que ces données ne soient accessibles qu'à ceux qui en ont le droit.
La sécurité des données est donc le point clé pour que l'IIoT (Internet industriel des objets) fonctionne avec succès et en toute sécurité. Par implication, cela signifie que la valeur inhérente du système industriel (ses données) dans sa totalité est créée aux extrémités du système : qu'il s'agisse de la base de données remplie par un comptable ou des données de température lues par un capteur.
Pour que ces deux sources de données différentes ne soient pas compromises, les fondations pour la conception d’un système IIoT doivent fournir des niveaux de sûreté de fonctionnement, de résilience et de fiabilité, ainsi que des niveaux de confidentialité et de sécurité pour protéger le réseau IT. À l'inverse dans ce mariage, le conjoint IT devra élever ses niveaux de résilience et de sûreté au même niveau que sa protection en termes de confidentialité, de sécurité et de fiabilité.
Tout cela pourrait être facilement réalisable si tous ces systèmes interconnectés étaient conçus dès le départ en gardant à l’esprit cette connectivité de bout en bout (et les contraintes qui en découlent). Mais cette approche n’est pas des plus pratiques à mettre en œuvre de par l’extraordinaire hétérogénéité de tous ces systèmes. Une autre approche serait de protéger les points d'extrémité eux-mêmes au moyen d'une passerelle basée sur le principe de séparation de domaines (ou séparation de noyaux).
Principe de la Séparation de noyau
Bien qu'une telle approche soit basée sur des principes qui sont peut-être nouveaux dans le secteur industriel, ce sont en réalité des principes établis depuis longtemps par ailleurs. La technologie de séparation de noyaux protège les informations classifiées dans les systèmes de communication gouvernementaux depuis près d'une décennie et il est intéressant de connaitre les principes fondamentaux qui ont fait le succès de cette technologie.
Le concept de séparation de noyaux a été présenté pour la première fois par John Rushby8 en 1981, qui suggérait que cette approche devrait être "une combinaison de matériel et de logiciel permettant de réaliser plusieurs fonctions sur un ensemble commun de ressources physiques sans interférence mutuelle indésirable". Le bien fondé de cet argument a été si convaincant que le principe de séparation de noyaux constitue le fondement de l'initiative MILS (Multiple Independent Levels of Security).
De même, il y a 30 ans, Saltzer et Schroeder9 ont suggéré que « chaque programme et chaque utilisateur du système devraient fonctionner en utilisant le moins de privilège possible pour accomplir une tâche donnée ». Cette approche du « moindre privilège », simple et de bon sens, devient impérative lorsque des applications de criticité différente sont exécutées à proximité les unes des autres.
Les concepts de séparation de noyaux et de moindre privilège sont donc tous deux centrés sur les avantages de la modularisation, le premier axé sur les ressources et le second sur la fonctionnalité du système - un point que Levin, Irvine et Nguyen ont souligné dans leur article « least privilege in Separation Kernels » 10, où ils ont proposé un amalgame des deux concepts.
La Figure 3 illustre les « Sujets » (entités actives, exécutables) et les « Ressources » superposés aux « blocs » du séparateur de noyaux, permettant une forte granularité de contrôle du flux par sujet et par ressource.
Il est donc clair que quelles que soient les différences et les similitudes entre les architectures, l'isolement d'un domaine par rapport à un autre est une caractéristique essentielle de toute implémentation pour en garantir la sécurité. En particulier, la compartimentation des données est essentielle, de sorte que ces données ne soient accessibles qu'à ceux qui en ont le droit.
La sécurité des données est donc le point clé pour que l'IIoT (Internet industriel des objets) fonctionne avec succès et en toute sécurité. Par implication, cela signifie que la valeur inhérente du système industriel (ses données) dans sa totalité est créée aux extrémités du système : qu'il s'agisse de la base de données remplie par un comptable ou des données de température lues par un capteur.
Pour que ces deux sources de données différentes ne soient pas compromises, les fondations pour la conception d’un système IIoT doivent fournir des niveaux de sûreté de fonctionnement, de résilience et de fiabilité, ainsi que des niveaux de confidentialité et de sécurité pour protéger le réseau IT. À l'inverse dans ce mariage, le conjoint IT devra élever ses niveaux de résilience et de sûreté au même niveau que sa protection en termes de confidentialité, de sécurité et de fiabilité.
Tout cela pourrait être facilement réalisable si tous ces systèmes interconnectés étaient conçus dès le départ en gardant à l’esprit cette connectivité de bout en bout (et les contraintes qui en découlent). Mais cette approche n’est pas des plus pratiques à mettre en œuvre de par l’extraordinaire hétérogénéité de tous ces systèmes. Une autre approche serait de protéger les points d'extrémité eux-mêmes au moyen d'une passerelle basée sur le principe de séparation de domaines (ou séparation de noyaux).
Principe de la Séparation de noyau
Bien qu'une telle approche soit basée sur des principes qui sont peut-être nouveaux dans le secteur industriel, ce sont en réalité des principes établis depuis longtemps par ailleurs. La technologie de séparation de noyaux protège les informations classifiées dans les systèmes de communication gouvernementaux depuis près d'une décennie et il est intéressant de connaitre les principes fondamentaux qui ont fait le succès de cette technologie.
Le concept de séparation de noyaux a été présenté pour la première fois par John Rushby8 en 1981, qui suggérait que cette approche devrait être "une combinaison de matériel et de logiciel permettant de réaliser plusieurs fonctions sur un ensemble commun de ressources physiques sans interférence mutuelle indésirable". Le bien fondé de cet argument a été si convaincant que le principe de séparation de noyaux constitue le fondement de l'initiative MILS (Multiple Independent Levels of Security).
De même, il y a 30 ans, Saltzer et Schroeder9 ont suggéré que « chaque programme et chaque utilisateur du système devraient fonctionner en utilisant le moins de privilège possible pour accomplir une tâche donnée ». Cette approche du « moindre privilège », simple et de bon sens, devient impérative lorsque des applications de criticité différente sont exécutées à proximité les unes des autres.
Les concepts de séparation de noyaux et de moindre privilège sont donc tous deux centrés sur les avantages de la modularisation, le premier axé sur les ressources et le second sur la fonctionnalité du système - un point que Levin, Irvine et Nguyen ont souligné dans leur article « least privilege in Separation Kernels » 10, où ils ont proposé un amalgame des deux concepts.
La Figure 3 illustre les « Sujets » (entités actives, exécutables) et les « Ressources » superposés aux « blocs » du séparateur de noyaux, permettant une forte granularité de contrôle du flux par sujet et par ressource.
Figure 3. La superposition des principes de Moindre Privilège sur des blocs de Séparation de Noyaux résulte en une granularité fine du contrôle de flux par-sujet et par-ressource.
Virtualisation matérielle
Bien que ces principes de séparation de noyaux et du moindre privilège soient établis depuis longtemps, les premières tentatives d'implémentation reposaient sur une couche de virtualisation logicielle qui entraînait des taux de performances discutables qui interdisaient l’exécution d’applications temps réel critiques. Néanmoins c'est bien la popularité de l’utilisation importante du principe de virtualisation logicielle dans le domaine de l'entreprise qui a amené les fabricants de silicium (notamment Intel, AMD et ARM) à augmenter le nombre de cœurs par CPU et à implémenter un support avancé pour la virtualisation par le matériel. Avec l’avènement de ces nouvelles architectures de processeurs, le principe de séparateur de noyaux est passé d'une simple idée théorique à une solution technique utilisable et réellement pratique.
De nos jours il existe plusieurs solutions de séparateurs de noyaux (ou Hyperviseurs) qui cherchent à atteindre des objectifs similaires basés sur des versions de système d’exploitation (OS) modifiées. Cependant, pour fournir un niveau de sécurité maximum, de tels séparateurs de noyaux doivent être basés sur les principes de moindre privilège afin de minimiser les composant dits Trusted Computing Base (TCB) et donc de réduire la surface d'attaque afin d’optimiser la protection fournie par la passerelle.
Éléments du Séparateur de noyaux
Pour mettre cela dans un exemple pratique, considérons une machine outils (un tour) qui génère des données de production (Figure 4). Ces données doivent être partagées, via le Cloud, par des utilisateurs divers, par exemple un ingénieur de production ou de maintenance.
Le « sujet » devant s’interfacer avec le Cloud dans cet exemple peut être un système d'exploitation à usage général, tel que Windows ou Linux. De tels OS peuvent être vulnérables à des attaques potentielles. Mais malgré cela, il est important que les pirates ne puissent pas avoir accès au « sujet » contrôlant la partie opérative (applications exécutée sur un OS temps réel industriel ou en natif sur le processeur) et ce même si la totalité du « sujet » connecté au cloud est compromis.
Bien que ces principes de séparation de noyaux et du moindre privilège soient établis depuis longtemps, les premières tentatives d'implémentation reposaient sur une couche de virtualisation logicielle qui entraînait des taux de performances discutables qui interdisaient l’exécution d’applications temps réel critiques. Néanmoins c'est bien la popularité de l’utilisation importante du principe de virtualisation logicielle dans le domaine de l'entreprise qui a amené les fabricants de silicium (notamment Intel, AMD et ARM) à augmenter le nombre de cœurs par CPU et à implémenter un support avancé pour la virtualisation par le matériel. Avec l’avènement de ces nouvelles architectures de processeurs, le principe de séparateur de noyaux est passé d'une simple idée théorique à une solution technique utilisable et réellement pratique.
De nos jours il existe plusieurs solutions de séparateurs de noyaux (ou Hyperviseurs) qui cherchent à atteindre des objectifs similaires basés sur des versions de système d’exploitation (OS) modifiées. Cependant, pour fournir un niveau de sécurité maximum, de tels séparateurs de noyaux doivent être basés sur les principes de moindre privilège afin de minimiser les composant dits Trusted Computing Base (TCB) et donc de réduire la surface d'attaque afin d’optimiser la protection fournie par la passerelle.
Éléments du Séparateur de noyaux
Pour mettre cela dans un exemple pratique, considérons une machine outils (un tour) qui génère des données de production (Figure 4). Ces données doivent être partagées, via le Cloud, par des utilisateurs divers, par exemple un ingénieur de production ou de maintenance.
Le « sujet » devant s’interfacer avec le Cloud dans cet exemple peut être un système d'exploitation à usage général, tel que Windows ou Linux. De tels OS peuvent être vulnérables à des attaques potentielles. Mais malgré cela, il est important que les pirates ne puissent pas avoir accès au « sujet » contrôlant la partie opérative (applications exécutée sur un OS temps réel industriel ou en natif sur le processeur) et ce même si la totalité du « sujet » connecté au cloud est compromis.
Un séparateur de noyaux implémenté correctement pour respecter les principes du moindre privilège devra disposer de caractéristiques clés pour répondre à un tel scénario :
• Rapidité
Pour obtenir des performances quasi natives, le séparateur de noyaux devra introduire le moins de latence possible et exploiter au maximum les capacités de virtualisation du matériel.
• Empreinte
Devra être la plus petite possible afin de réduire la surface d’attaque du séparateur de noyaux, et ce, en s’assurant que les fonctionnalités des systèmes d'exploitation des sujets tels que les pilotes, les E / S et la gestion des processus sont gérées par les sujets eux-mêmes.
• Simplicité
Le séparateur de noyaux devra permettre la réutilisation des logiciels existants (OS standards du marché) en présentant une "carte mère virtuelle" aux sujets, de sorte que ces sujets puissent être installés et exécutés comme pour une installation native.
• Sécurisé
La configuration statique assurera que le séparateur de noyaux est immuable une fois compilé et déployé, et ce, avec une surface d'attaque la plus faible possible.
Défense contre Stuxnet
L'attaque Stuxnet illustre parfaitement comment cette technologie de séparation de noyaux peut être utilisée pour sécuriser une infrastructure critique contre ce type d’attaques. L'objectif de Stuxnet était d'infecter, puis de manipuler les automates programmables Siemens (PLC) contrôlant et surveillant la vitesse des centrifugeuses qui enrichissent l'uranium en tournant à très haute vitesse. Ces automates n'étant pas connectés directement à Internet, un processus sophistiqué d'infection par logiciel malveillant a été mis en place afin d'obtenir la « charge utile » réelle de la cible afin de mener l'attaque.
Les attaquants ont utilisé des techniques traditionnelles d'infection par logiciel malveillant, telles que les clés USB infectées, pour s'infiltrer et explorer les systèmes sur le réseau sécurisé jusqu'à ce qu'ils trouvent les automates contrôlant les centrifugeuses. Ensuite, le code du virus a été chargé dans ces automates où il a manipulé la vitesse des centrifugeuses jusqu'à leur défaillance.
Un séparateur de noyaux aurait pu être déployé dans l'usine pour arrêter durablement la progression de l'infection alors qu'elle cherche sa cible. Dans ce scénario, l'ordinateur connecté directement aux automates Siemens aurait bénéficié du plus haut niveau de protection, par exemple en désactivant des ports (tels que l'USB) qui pourraient permettre à des fichiers malveillants d'entrer dans ce domaine.
Conclusion
Les cyberattaques ne sont pas un phénomène quotidien dans le domaine industriel, mais leur potentiel de dommages est presque illimité. Les antécédents d'attaques contre des infrastructures aussi diverses que les aciéries, les usines de traitement de l'eau, les installations d'enrichissement d'uranium et les réseaux électriques montrent que la « spécificité » de « l’informatique » utilisée dans les réseaux industriels n'est pas un facteur de protection qui perturbe les pirates.
Historiquement, ce que chacune de ces attaques avait en commun était un point d’accès vulnérable entre les réseaux informatiques connectés vers l’extérieur du site industriel et le réseau opérationnel interne où les systèmes critiques et de sécurité sont connectés. Comme le soulignent à la fois l'IIRA et le RAMI 4.0, ces vulnérabilités sont inhérentes à la jonction de ces deux mondes traditionnellement distincts en termes de technologies de l'information et des opérations.
Le déploiement stratégique des principes de séparation de noyaux permet de contrôler étroitement cette passerelle vitale entre ces deux mondes, et fournit une arme très efficace dans la défense contre les cyberattaques.
• Rapidité
Pour obtenir des performances quasi natives, le séparateur de noyaux devra introduire le moins de latence possible et exploiter au maximum les capacités de virtualisation du matériel.
• Empreinte
Devra être la plus petite possible afin de réduire la surface d’attaque du séparateur de noyaux, et ce, en s’assurant que les fonctionnalités des systèmes d'exploitation des sujets tels que les pilotes, les E / S et la gestion des processus sont gérées par les sujets eux-mêmes.
• Simplicité
Le séparateur de noyaux devra permettre la réutilisation des logiciels existants (OS standards du marché) en présentant une "carte mère virtuelle" aux sujets, de sorte que ces sujets puissent être installés et exécutés comme pour une installation native.
• Sécurisé
La configuration statique assurera que le séparateur de noyaux est immuable une fois compilé et déployé, et ce, avec une surface d'attaque la plus faible possible.
Défense contre Stuxnet
L'attaque Stuxnet illustre parfaitement comment cette technologie de séparation de noyaux peut être utilisée pour sécuriser une infrastructure critique contre ce type d’attaques. L'objectif de Stuxnet était d'infecter, puis de manipuler les automates programmables Siemens (PLC) contrôlant et surveillant la vitesse des centrifugeuses qui enrichissent l'uranium en tournant à très haute vitesse. Ces automates n'étant pas connectés directement à Internet, un processus sophistiqué d'infection par logiciel malveillant a été mis en place afin d'obtenir la « charge utile » réelle de la cible afin de mener l'attaque.
Les attaquants ont utilisé des techniques traditionnelles d'infection par logiciel malveillant, telles que les clés USB infectées, pour s'infiltrer et explorer les systèmes sur le réseau sécurisé jusqu'à ce qu'ils trouvent les automates contrôlant les centrifugeuses. Ensuite, le code du virus a été chargé dans ces automates où il a manipulé la vitesse des centrifugeuses jusqu'à leur défaillance.
Un séparateur de noyaux aurait pu être déployé dans l'usine pour arrêter durablement la progression de l'infection alors qu'elle cherche sa cible. Dans ce scénario, l'ordinateur connecté directement aux automates Siemens aurait bénéficié du plus haut niveau de protection, par exemple en désactivant des ports (tels que l'USB) qui pourraient permettre à des fichiers malveillants d'entrer dans ce domaine.
Conclusion
Les cyberattaques ne sont pas un phénomène quotidien dans le domaine industriel, mais leur potentiel de dommages est presque illimité. Les antécédents d'attaques contre des infrastructures aussi diverses que les aciéries, les usines de traitement de l'eau, les installations d'enrichissement d'uranium et les réseaux électriques montrent que la « spécificité » de « l’informatique » utilisée dans les réseaux industriels n'est pas un facteur de protection qui perturbe les pirates.
Historiquement, ce que chacune de ces attaques avait en commun était un point d’accès vulnérable entre les réseaux informatiques connectés vers l’extérieur du site industriel et le réseau opérationnel interne où les systèmes critiques et de sécurité sont connectés. Comme le soulignent à la fois l'IIRA et le RAMI 4.0, ces vulnérabilités sont inhérentes à la jonction de ces deux mondes traditionnellement distincts en termes de technologies de l'information et des opérations.
Le déploiement stratégique des principes de séparation de noyaux permet de contrôler étroitement cette passerelle vitale entre ces deux mondes, et fournit une arme très efficace dans la défense contre les cyberattaques.
Références :
[1] http://www.bbc.co.uk/news/technology-15817335
2 http://www.bbc.co.uk/news/technology-30575104
3 http://www.bbc.co.uk/news/technology-35686493
4 http://www.bbc.co.uk/timelines/zc6fbk7
7 Industrial Internet consortium – Industrial Internet Reference Architecture version 1.7. 4th June, 2015.
8 Rushby, J. Design and Verification of Secure Systems. Operating Systems Review. 15(5). 1981.
9 Saltzer, J.H. and Schroeder, M.D. The Protection of Information in Operating Systems. Proceedings of the IEEE 63(9):1278-1308. 1975.
10 Levin, T.E., Irvine C.E. and Nguyen T.D. Least Privilege in Separation Kernels. Department of Computer Science, U.S. Naval Postgraduate School. 2004.
[1] http://www.bbc.co.uk/news/technology-15817335
2 http://www.bbc.co.uk/news/technology-30575104
3 http://www.bbc.co.uk/news/technology-35686493
4 http://www.bbc.co.uk/timelines/zc6fbk7
7 Industrial Internet consortium – Industrial Internet Reference Architecture version 1.7. 4th June, 2015.
8 Rushby, J. Design and Verification of Secure Systems. Operating Systems Review. 15(5). 1981.
9 Saltzer, J.H. and Schroeder, M.D. The Protection of Information in Operating Systems. Proceedings of the IEEE 63(9):1278-1308. 1975.
10 Levin, T.E., Irvine C.E. and Nguyen T.D. Least Privilege in Separation Kernels. Department of Computer Science, U.S. Naval Postgraduate School. 2004.