Sécurité des systèmes cyber-physiques

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Les systèmes cyber-physiques, historiquement utilisés dans les systèmes de contrôles industriels, se sont répandus dans des produits grand publics au sein de l'internet des objets. Ils sont l'objet d'attaques qui peuvent causer des impacts matériels et humains. Leur sécurité rencontre des problématiques spécifiques, différentes de celles posées par les systèmes informatiques traditionnels. Les propriétés de sécurité attendues varient fortement suivant l'usage qui est fait de la technologie, et les attaquants contre lesquels on souhaite la protéger. La protection de ces systèmes repose sur un ensemble de pratiques qui vont de la segmentation du réseau à la validation des éléments embarqués présents à sa périphérie. Des technologies de détection et de prévention d'intrusion sont développées spécialement pour ces systèmes, en tenant compte des particularités des usages et des protocoles mis en œuvre.

Illustration des menaces[modifier | modifier le code]

Les technologies de l'automatisation sont destinées à des usages très divers. Elles ont d'abord été largement utilisées dans les systèmes de contrôle industriels, puis se sont répandues à des usages plus courants, parfois regroupés sous l'appellation Internet des objets. Comme tous les systèmes informatiques, ces technologies peuvent faire l'objet d'attaques, de nature et d'impact variés. Dans le passé, de nombreux systèmes industriels en ont été la cible. En 2016, les usages de l'internet des objets par des particuliers sont en plein essor, et peu d'attaques sur ces systèmes ont été recensées. De nombreux travaux sont cependant menés afin d'accompagner leur développement et de prévenir des risques que leur rapide expansion peut impliquer.

Industrie[modifier | modifier le code]

Les sites industriels ont massivement recours aux technologies de l'automatisation. Ces technologies sont souvent regroupées au sein de systèmes SCADA. Elles se composent généralement de trois types d'éléments : Des dispositifs embarqués, utilisés pour la télémesure ou l'opération des machines; des serveurs qui récoltent les données et pilotent les contrôleurs; et des clients qui sont utilisés par les administrateurs humains. Le bon fonctionnement de ces infrastructures peut être vital pour le maintien de l'activité et la prévention des accidents. Les protocoles utilisés sont nombreux et souvent propriétaires. Ils ont rarement été conçus pour être connectés à un réseau accessible de l'extérieur, et comportent donc peu de sécurité[1],[2], ce qui les rend vulnérables à des intrusions[3].

Ces attaques peuvent parfois être menées par un individu isolé. En 2000, un ancien contractant du centre de traitement des eaux de Maroochy provoqua le déversement d'un million de litres d'eaux non traitées dans les cours d'eau de la région[4]. Il utilisa un équipement radio volé à son employeur pour désactiver les alarmes des stations de pompage et détraquer leur fonctionnement[5]. En 2008, un collégien utilisa "une télécommande de télévision modifiée" infrarouge pour prendre le contrôle des aiguillages du réseau de tramway de Lodz, faisant dérailler quatre tramways[6],[7].

Elles ont également été utilisées dans le cadre d'opérations militaires. En 2010, le virus Stuxnet, développé par les armées américaines et israéliennes[8],[9] fut utilisé contre la centrale de Natanz en Iran. Selon un rapport de l'Institute for Science and International Security (en), il causa la destruction d'un millier de centrifugeuses[10],[8]. La centrale étant isolée d'internet, les différentes versions du programme furent introduites au moyen de clés usb. Stuxnet reprogrammait les contrôleurs Siemens des centrifugeuse, et faisait varier la vitesse de rotation. Lorsqu'une attaque était en cours, le contrôleur remontait de fausses informations au système SCADA, qui était donc incapable de détecter l'attaque[11].

Les entreprises exploitant des infrastructures industrielles peuvent également être victimes d'extorsion. Selon Alan Paller cité par le journal Forbes en 2008, ces installations sont régulièrement la cible d'attaques auxquelles font suite des demandes de rançon[12].

Internet des objets[modifier | modifier le code]

Des systèmes de contrôle aux fonctions similaires à ceux utilisés dans l'industrie sont désormais répandus dans des usages destinés à un grand public.

Ces usages sont parfois catalogués au sein de l'internet des objets. Ce concept représente la grande diversité d'objets connectés qui peuvent être connectés à internet, directement ou indirectement. Pour s'intéresser à la sécurité des objets connectés, on peut choisir de distinguer ceux qui communiquent directement avec internet, et ceux qui utilisent des technologies machine à machine. Comme dans les systèmes industriels, beaucoup de cas d'usage font intervenir ces deux modes de communication.

Ces objets sont souvent minimalistes, conçus pour accomplir une tâche simple au coût le plus bas possible. Ils disposent donc d'une mémoire et d'une capacité de calcul très limitée, et n’intègrent pas de défense avancée contre les attaques. Une fois mis sur le marché, il est difficile d'y ajouter des protections supplémentaires.

Véhicules[modifier | modifier le code]

Les véhicules sont un bon exemple d'objets connectés. Ils comportent quasiment toujours des unités de commande électronique (UCE). Ces UCE servent à capter des informations : Jauge de carburant; pression des pneus; température; vitesse; détection de collision, et commander des actionneurs : lampes; electrovannes; ABS; etc. L'interconnexion de ces modules se fait généralement sur un bus standard CAN. Les voitures modernes sont également souvent équipées d'un ordinateur de bord qui fournit différents fonctionnalités au conducteur : affichage d'informations sur la conduite, lecteur multimédia, GPS, etc. Ces ordinateurs de bord peuvent être accessibles à distance, par exemple via le bluetooth ou un réseau cellulaire.

En 2010, une équipe des universités de Washington et San Diego a recensé les risques induits par un composant capable de communiquer sur le bus CAN d'une voiture. Ils ont montré que malgré l'authentification nécessaire pour certaines actions critiques, un composant CAN malicieux posait de sérieux risques sur une auto en fonctionnement, en étant par exemple capable de manipuler le système de freinage ou d'éteindre son moteur[13]. Des doutes ont été émis sur la faisabilité réelle d'une telle attaque, dont la démonstration avait requis un accès physique à la voiture par plusieurs experts. Dans un second article, ils ont donc présenté une étude exhaustive de la surface d'attaque permettant une prise de contrôle du système informatique de la voiture cible[14]. Ils proposent une classification des vecteurs d'intrusion : accès physique direct; accès physique indirect; sans-fil courte portée; sans-fil longue portée. Pour chacun des vecteurs, ils présentent une ou plusieurs méthodes permettant l'exécution de code arbitraire en exploitant des failles logicielles.

En 2015, Charlie Miller et Chris Valasek ont présenté les résultats de leur étude d'un Jeep Cherokee. Ils ont découvert que le système multimédia Harman Uconnect de ces véhicules exposait une interface D-Bus sur un port tcp accessible via le réseau cellulaire Sprint. Il était dès lors possible d'exécuter des commandes arbitraires à distance sur le système d'exploitation du véhicule. Ce système multimédia fonctionne sur une puce OMAP qui n'est pas directement connectée au bus CAN de la voiture, mais peut communiquer avec une puce d'entrée-sortie reliée au bus CAN. Les deux chercheurs ont montré qu'il était possible de reprogrammer cette puce pour envoyer des paquets CAN arbitraires et causer les mêmes risques que ceux présentés dans les papiers précédent, par exemple désactiver les freins et le système anti-collision. Pour corriger le problème, dans un premier temps l'opérateur Sprint a bloqué le port vulnérable sur tout le range utilisé par les voitures, puis le constructeur automobile a rappelé 1,4 million de véhicules pour une mise à jour du logiciel[15].

Réseaux de capteurs sans fil[modifier | modifier le code]

Les réseaux de capteurs sans fil permettent le déploiement de petits capteurs contraints en ressources. Ils communiquent au moyen de technologies radio basse consommation sur des réseaux WPAN et peuvent être agencés selon une technologie en étoile, maillée, ou hybride. La norme IEE 802.15.4 propose un standard pour les couches PHY et MAC. Il est utilisé dans beaucoup d'implémentations propriétaires. Des normes existent également pour les couches supérieures, comme ZigBee destiné aux réseaux personnels, ou 6LoWPAN, qui permet la compatibilité IPV6 en ajoutant une passerelle réseau.

La spécification 802.15.4 de 2003 propose plusieurs modes de chiffrement, et indique pour chacun s'ils permettent le contrôle d'accès; le chiffrement des données; l'intégrité; et la séquentialité[16]. Cette classification n'est pas toujours pertinente, car l'implémentation de la norme est complexe, et une erreur peut facilement compromettre les propriétés anti rejeu et d'intégrité[17],[18]. Le provisionnement des clés n'est pas couvert par la norme, et doit donc être défini adéquatement par ceux qui implémentent une solution 802.15.4 en fonction des propriétés de sécurité souhaitées.

Les réseaux de capteurs sans fil peuvent être sujets à des vulnérabilités génériques inhérentes à leur système de routage.

Retour d'anciennes vulnérabilités[modifier | modifier le code]

S'agissant d'internet des objets, il existe des usages qui ne font pas intervenir de technologies spécifiques, mais "connectent" simplement des objets au réseau, en leur associant un système - souvent de type UNIX - qui est relié à internet par des moyens conventionnels. Dans bien des cas, les systèmes d'exploitation qu'ils utilisent sont très mal sécurisés comparé aux systèmes d'exploitation qui tournent sur les serveurs ou les postes de travail[19]. Ils peuvent donc constituer une cible de choix pour des attaquants.

En 2016, un cas notable se produit avec la formation du botnet MIRAI, qui prend le contrôle de milliers de NAS et de caméras IP en se connectant sur leur port telnet avec les identifiants par défaut. Pour s'étendre, le ver balaye en permanence le web à la recherche de machines vulnérables. Il est utilisé pour mener des attaques en déni de service, notamment sur les sociétés OVH et Dyn. Selon Octave Klaba, directeur général d'OVH, l'attaque qu'ils ont subi mettait à contribution près de 150 000 machines, et représentait un trafic supérieur à 1.5 Tbps[20].

Pour mitiger ce type de menaces, le CERT propose deux solutions complémentaires : les administrateurs de systèmes d'information sensibles doivent les rendre plus résistants aux attaques en déni de service, et les acheteurs d'un équipement devraient personnellement s'assurer de sa sécurité avant de le connecter à internet[21]. Les organisations qui supervisent leur parc de machines peuvent également se prémunir de ces attaques, en surveillant l'activité des ports telnet, ou en utilisant un système de gestion de parc ou un scanner de vulnérabilités capable de détecter un service configuré avec les identifiants par défaut[22].

Catégorisation des menaces[modifier | modifier le code]

Article général Pour un article plus général, voir Sécurité des systèmes d'information.

Les systèmes de contrôle industriels ou les objets connectés jouent des rôles divers, souvent très différents de ceux des systèmes informatiques classiques. Pour chaque usage, les propriétés de sécurité requises doivent être identifiées avant de choisir une solution technique. Les méthodes de catégorisation de la sécurité des SI[note 1] peuvent être appliquées aux ICS[note 2].

Dans les systèmes industriels[modifier | modifier le code]

When studying the possible security vulnerabilities, it is easy to get caught in a trap of trying to address issues that are technically interesting, but are ultimately of low risk to the system.

— Eric J. Byres, [23],[24]

« Quand on étudie les potentielles failles de sécurité, on peut facilement être pris au piège d'essayer de régler des problèmes qui sont techniquement intéressants, mais finalement d'un faible risque pour le système. »

— [23],[24]

Directives gouvernementales[modifier | modifier le code]

Le guide NIST 800-82 fournit des indications pour sécuriser les systèmes de contrôle industriel. Il propose une identification des risques et des solutions pour les mitiger. Les menaces sont distinguées en quatre catégories : adverses, accidentelles, structurelles, environnementales. La stratégie de gestion des risques doit traiter tous ces aspects. Les risques adverses doivent être correctement évalués en tenant compte du coût d'une attaque et de l'apparition de nouvelles vulnérabilités.

Dans les ICS, la hiérarchie des risques est souvent différente de celle des autres systèmes. La confidentialité, primordiale pour les postes de travail, est souvent peu importante dans les systèmes industriels, car l'information transmise a peu de valeur[25]. En revanche, une atteinte à la disponibilité du système ou à son intégrité peut causer d'importants dommages humains ou matériels. C'est donc ces deux propriétés qui sont recherchées en priorité dans un système industriel[26].

Parmi les systèmes industriels, l'ANSSI distingue trois classes de mesures cumulatives de sécurité informatique. Elle propose une nomenclature des risques et de leur impact[27].

L'impact est classé de un à cinq, d'insignifiant à catastrophique, pour chacune des catégories suivantes : impact humains; environnementaux; consécutifs à l'arrêt du service.

Une classification des attaquants est présentée :

  1. Non ciblé : virus, robots, etc.
  2. Hobbyiste : Peu de moyens, pas forcément d'intention de nuire
  3. Attaquant isolé : Peu de moyens mais déterminé
  4. Organisation privée : Moyens conséquents
  5. Organisation étatique : Moyens illimités

L'ANSSI considère que tout système industriel peut être exposé à des attaquants de niveau 3.

Le niveau de connectivité du système industriel est classifié :

  1. Isolé : Complètement fermé
  2. Connecté à un système de gestion : Aucune opération n'est permise depuis l'extérieur du système d'information de gestion
  3. Utilisation de technologies sans fil : Ces technologies sont sujettes à des attaques difficiles à prévenir sur leur disponibilité
  4. Communique avec l'extérieur : Par exemple avec un autre site, ou le système d'un sous traitant
  5. Communique avec l'extérieur au moyen d'une infrastructure publique : Comme niveau 4, mais sur un réseau non dédié

Trois classes de fonctionnalités des systèmes sont dérivées de la pyramide du CIM :

  1. Minimaux : capteurs, actionneurs, pupitres, etc. (CIM 0-1)
  2. Complexes : Systèmes SCADA (CIM 0-2)
  3. Très complexes : Tout le reste, par exemple les solutions constructeur complexes

Le niveau d'accessibilité du personnel est pris en compte :

  1. Autorisés, habilités et contrôlés
  2. Autorisés et habilités : Certaines opérations ne sont pas tracées
  3. Autorisés : Pas de vérification particulière sur les intervenants autorisés
  4. Non autorisés : Des actions non autorisées sont possibles.

Une note d'exposition est dérivée des niveaux de connectivité et de fonctionnalité. La classe du système de chaque système peut être approximée en fonction des notes assignées aux différents critères.

Arbre d'attaque[modifier | modifier le code]

Article détaillé : en :Attack tree.

Pour évaluer les conséquences d'une intrusion, on peut élaborer des arbres d'attaque. Cette méthode, applicable aux systèmes industriels, permet d'identifier les différentes étapes nécessaires à l'attaque d'un système, et de visualiser les conséquences de sa compromission. On peut alors prendre des mesures préventives pour protéger les parties les plus critiques de l'infrastructure[28].

Dans les objets connectés[modifier | modifier le code]

Comme pour les ICS, les enjeux de sécurité sont variés. Une étude de l'université d'Aalborg[29] énumère les propriétés suivantes : Résilience; authentification des données; contrôle d'accès; vie privée; identification des utilisateurs; stockage sécurisé; gestion d'identité; sécurité des communications; disponibilité; sécurisation de l'accès au réseau; sécurisation de la propriété intellectuelle; résistance aux modifications.

Ahmad W. Atamli, de l'université d'Oxford, propose une classification des attaquants[30] :

L'utilisateur 
Qui peut essayer d'extraire des secrets de l'objet, ou d'activer des fonctionnalités sans autorisation.
Le fabriquant 
Qui peut introduire - volontairement ou non - des vulnérabilités permettant de compromettre la vie privée de l'utilisateur, ou d'autres objets connectés.
Un adversaire externe 
Qui peut essayer de récolter des informations ou de les falsifier, pour divers motifs.

Problèmes de sécurité lié à la collection des données[modifier | modifier le code]

Les nœuds de capteurs sont très hétérogènes et ont généralement une structure et un processeur simple (mémoire très limitée, une faible capacité de calcul, une grande autonomie et un bas coût) ce qui limite leur capacité d’avoir des systèmes de sécurité et de défense avancés.

L'équipement principal de la couche de perception inclut RFID, Zigbee, Lora, Sigfox, et différents types de capteurs. Après la collecte des informations, ces données sont principalement transmises via un réseau dans fil. Les signaux sont exposés dans des lieux publics. S'il n'y a pas de mesures efficaces pour assurer leur protection, ces signaux pourront être surveillés, interceptés, modifiés et rejoués facilement. La majorité des capteur sont déployés dans des lieux faciles d'accès.

Sur la couche de perception, Kai Zhao énumère les risques suivants[31] :

Capture d'un nœud 
Un attaquant peut facilement contrôler un nœud comme un passerelle réseau. Il pourrait en extraire des informations critique, par exemple des secrets cryptographiques sur lesquels reposent la confidentialité et l'intégrité du réseau.
Faux nœud et donnés malveillantes 
L'attaquant peut brancher un équipement malicieux sur le réseau, et l'infecter par des informations erronées, cet équipement peut noyer les autres nœuds par des informations inutiles ce qui affecte leur autonomie.
Attaque par déni de service 
Atteinte à la disponibilité du service
Attaque temporelle 
Extraction de secrets cryptographiques par analyse du temps d'exécution de ces routines.
Attaque sur le routage 
Exploitation du protocole de routage pour créer de fausses routes, pour causer la perte de données; injecter des messages d'erreurs, ou augmenter la latence réseau.
Attaque par rejeu 
Rejeu de messages préalablement observés, par exemple pour contourner certains mécanismes d'authentification.
Attaque par canal auxiliaire 
Extraction de secrets cryptographiques par mesure du temps d'exécution, de la consommation électrique, ou des émanations électromagnétiques.
Problème de l'authentification massive de nœuds 
Toutes les difficultés induites par la gestion de l'authentification dans des réseaux comportant un très grand nombre de nœuds.

Contremesures[modifier | modifier le code]

Contraintes spécifiques aux systèmes industriels[modifier | modifier le code]

La sécurisation d'une architecture industrielle existante pose différents problèmes qui ne sont pas tous techniques. D'abord, l'infrastructure n'est pas toujours pleinement maitrisée par ses exploitants : les installations peuvent être en partie exploitées par des intervenants extérieurs ou bien partagées par plusieurs organisations; les installations peuvent être mal connues et leur connaissance disparaître avec les anciens employés; des sites peuvent être dispersés géographiquement et difficilement accessibles. Par ailleurs, la modification des équipements peut être empêchée pour différentes raisons. Le contrat avec le fabriquant peut simplement l'interdire ou ne pas en assurer la garantie; les homologations risquent d'être perdues; des règles spécifiques au secteur complexifier cette tâche; il n'existe parfois aucun environnement de test[32],[33].

Les protocoles utilisés dans l'industrie n'ont souvent pas été conçus pour être connectés à d'autres réseaux. Ils ont été pensés pour un environnement de confiance, et ne comportent donc souvent aucune authentification. Les installations sont souvent configurées avec les identifiants par défaut. L'intégration de ces systèmes dans les usages des années 2010, qui tendent vers plus d'interconnexion pose problème et il est donc conseillé de les isoler le plus possible des autres réseaux[34].

L'utilisation de technologies sans-fil pose des problèmes spécifiques. Le plus évident est posé par les points d'accès wifi qui peuvent constituer un point d'entrée de choix. Il est donc nécessaire de protéger par un pare-feu l'interconnexion de ce genre de point d'accès avec les autres réseaux. Ensuite, l'écoute passive est souvent possible à longue distance, ce qui n'est pas souhaitable. Dans le cas de protocoles mal sécurisés, les attaques sur l'intégrité sont également facilitées. Enfin, il est très difficile de protéger la disponibilité du canal physique de ces communications. Pour cette raison, l'ANSSI réserve leur usage au strict nécessaire, et l'interdit totalement pour les liaisons ayant un besoin critique de disponibilité[35].

Contraintes spécifiques aux systèmes embarqués[modifier | modifier le code]

L'informatique embarquée et les objets connectés présentent différentes faiblesses spécifiques. On cite souvent le challenge que représente l'implémentation de cryptographie forte sur des systèmes ne disposant que de quelques kilo-octets de mémoire vive, et de faibles capacités de calcul. Cela nécessite l'utilisation de solutions adaptées, par exemple en utilisant de la cryptographie sur les courbes elliptiques qui permet l'implémentation d'une cryptographie asymétrique forte, utilisant des clés relativement courtes et des calcul peu coûteux[36].

L'énergie disponible doit également être économisée, ce qui pose des difficultés lorsqu'on souhaite implémenter du chiffrement, ou utiliser des mécanismes d'authentifications couteux en ressources réseau. Certains de ces systèmes sont jetables et fonctionnent sur une batterie non rechargeable. Dans ce cas, l'objet peut être visé par des attaques qui épuiseraient prématurément sa batterie[37].

L'intégrité physique de ces dispositifs n'est pas toujours assurée, et ils peuvent être déplacés ou modifiés par des intervenants non autorisés.

Les micrologiciels des systèmes embarqués, souvent propriétaires, sont presque toujours programmés avec des langages bas niveau, et peuvent contenir des failles logicielles. De plus les mitigations d'exploit existantes sont rarement utilisées, afin de préserver les performances[38].

Architecture[modifier | modifier le code]

Défense en profondeur[modifier | modifier le code]

Article détaillé : Défense en profondeur.

La maitrise de l'architecture est indispensable, et sa sécurisation doit être prévue dès son élaboration. Le système doit être cartographié, et les sous-systèmes qui le composent évalués séparément. Il faut ensuite maîtriser l'interconnexion en justifiant chaque liaison. L'utilisation de pare-feux est indispensable sur tous les points d'interconnexion à l'extérieur, et selon l'importance du système, peut être également requise sur les jonctions internes.

Un système moins critique ne devrait pas transmettre vers un système plus critique. Dans ce cas, l'utilisation de liens unidirectionnels (en) peut être exigée par les autorités d'homologation[39].

Sécurité matérielle des objets connectés[modifier | modifier le code]

Avec les objets connectés, certaines attaques impliquent un accès physique de l'attaquant. Elles peuvent viser à extraire des secrets de l'objet, ou à falsifier les informations qu'ils transmet.

Pour permettre l'authentification des objets communicants et assurer la confidentialité de leurs échanges, un provisionnement des clés est nécessaire, et cette procédure est rarement couverte par la spécification. La solidité des implémentations varie donc. La protection des secrets cryptographiques repose sur l'informatique de confiance et la sécurité matérielle des cartes à puce[40].

Un capteur connecté - qui mesure des grandeurs physiques et les transmet - peut être attaqué physiquement pour falsifier les informations remontées. En effet, même si les données envoyées sont authentifiées par un méchanisme de chiffrement, le canal entre le capteur et l'unité cryptographique ne l'est pas forcément. Dans ce cas, un attaquant peut simplement interférer avec le signal du capteur. Pour contrer ce type de menaces, il existe des capteurs qui couplent dans un même composant le système de mesure, et une unité de confiance chargée de l'authentification des données[41].

Sécurité logicielle[modifier | modifier le code]

Article général Pour un article plus général, voir Durcissement (informatique).

La sécurité des firmwares posent des problèmes spécifiques :

Gestion des privilèges 
Les firmwares sont très souvent développés en considérant un environnement de confiance. Cependant ils opèrent sur des réseaux qui peuvent être accessibles depuis l'extérieur, ou le devenir au gré de l'évolution de l'architecture. Des interfaces sensibles peuvent être exposées, et être mises à profit par un attaquant; directement pour effectuer des actions non autorisées; ou pour rebondir, et attaquer d'autres parties du système[42].
Mise à jour 
Dans certains dispositifs, aucun système de mise à jour du firmware n'est prévue. Dans ce cas, les failles ne peuvent pas être corrigées. Lorsqu'ils existent, les systèmes de mise à jour peuvent présenter des risques. Si la validité du firmware n'est pas - ou mal - vérifiée, un attaquant peut totalement reprogrammer le contrôleur[43].
Complexité 
Des langages de programmation bas niveau sont majoritairement utilisés dans les systèmes embarqués. Avec ces langages, les erreurs de programmation peuvent créer des vulnérabilités exploitables. Les firmwares peuvent être développés au cours d'une longue période. Leur complexité peut augmenter, et rendre très difficile la validation de leur sécurité[44].
Protections absentes 
Les méthodes de mitigation d'exploit utilisées dans les ordinateurs sont moins répandues dans les systèmes embarqués. Certaines protections qui pourraient facilement être implémentées ne sont pas toujours présentes, notamment le Stack-smashing protector et l'Address space layout randomization (ASLR). D'autres comme la Data Execution Prevention (DEP) reposent sur des fonctionnalités qui ne sont pas disponibles sur tous les microcontrôleurs. Des protections basiques, contre le brute-force de mot de passe par exemple, ne sont pas forcément présentes[38].

Des bonnes pratiques de développement augmentent considérablement la sécurité des firmwares. Les interfaces inutiles doivent être éliminées. Les fonctionnalités sensibles, comme la mise à jour, ne doivent pas être accessibles sur un réseau peu fiable. Les mises à jour peuvent être signées numériquement. Une bonne qualité du code facilite son audit, et assure la maintenabilité. Quand c'est possible, les protections logicielles doivent être utilisées.

Les mitigations d'exploit existantes peuvent être repensées pour les systèmes embarqués. Par exemple, Petteri Mäki de l'université de Turku, Finlande, propose une méthode similaire à l'ASLR, mais qui randomise l'image au moment de la compilation[45].

Au niveau des opérateurs de réseau[modifier | modifier le code]

Avec l'internet des objets, des systèmes très mal sécurisés sont exposés directement au monde extérieur. Le cas du botnet MIRAI a montré que rassemblés au sein d'un large botnet, de telles machines peuvent créer des dommages considérables. On peut difficilement attendre de chaque possesseur d'un NAS ou d'une caméra IP qu'il assure de la sécurité de son équipement. Pour bloquer l'expansion de MIRAI, certains experts ont donc proposé que les fournisseurs d'accès internet bloquent le port telnet, utilisé par le botnet pour se propager[46]. Un tel blocage au niveau de l'opérateur s'est déjà vu : En France, certains opérateurs bloquent déjà le port SMTP, pour empêcher l'envoi de pourriels par des machines infectées.

Ces mesures peuvent être décidées en urgence : Après les publications sur les failles des Jeep Cherokee, la première mesure prise a été le blocage des ports incriminés au niveau de l'opérateur Sprint.

Systèmes de détection et de prévention d'intrusion[modifier | modifier le code]

Article général Pour un article plus général, voir Système de prévention d'intrusion.
Article général Pour un article plus général, voir Système de détection d'intrusion.

S'agissant de détection d'intrusion, les systèmes industriels présentent des différences avec les technologies traditionnelles de l'information. Les méthodes mises en œuvre dans les IDS[note 3] standard s'adaptent mal à ces spécificités. Pour être utile, un IDS dédié à la protection des ICS doit donc être spécifiquement adapté à ces environnements. Mitchell et Chen identifient quatre principales caractéristiques devant être prises en compte[47] :

- Les informations échangées représentent des processus physiques. On peut donc évaluer leur validité en utilisant les lois de la physique.

- Les systèmes de contrôle peuvent être en boucles fermées. Cela induit une stabilité supplémentaire dans leur comportement, qu'on peut utiliser pour les spécifier.

- Pour causer un impact critique, les adversaires peuvent mobiliser des attaques zero-day élaborées. Les IDS standards rencontrent majoritairement des attaques connues.

- Les technologies utilisées sont souvent anciennes et hétérogènes. Les systèmes de détection doivent supporter des protocoles variés. La dispositifs embarqués sont assez simples et il est donc envisageable de modéliser précisément le comportement de chaque élément.

Deux principaux rôles collaborent dans un IDS : La collecte d'informations, et l'analyse qui en est faite.

Collecte[modifier | modifier le code]

La collecte peut être faite par les hôtes (HIDS) ou sur le réseau (NIDS). Pour se protéger de toutes les menaces, il peut être nécessaire d'utiliser les deux systèmes conjointement.

Les HIDS sont déployés directement sur les nœuds. Ils partagent certaines caractéristiques avec les antivirus répandus sur les PC. En contrepartie d'une moins bonne portabilité, ils permettent la mise en œuvre de méthodes de détection spécifiques à chaque OS. Ils ont accès à des éléments invisibles de l'extérieur, comme la liste des processus s'exécutant sur le système; et le système de fichier. Ils peuvent faire toute la détection d'intrusion, ou collaborer avec un IDS tiers auquel ils transmettent des données choisies. Dans le cadre de grands réseaux décentralisés, tels que les smart-grids, ils permettent de distribuer la charge de la supervision du système. Ils présentent l'inconvénient de présenter un coût en resources sur chaque nœud, pour l'analyse et le stockage des évènements. De plus, lorsqu'un nœud est compromis, un attaquant évolué peut modifier le comportement du HIDS pour désactiver ses contremesures, et falsifier les informations sauvegardées ou remontées[48].

Des IDS hybrides très simples peuvent limiter grandement l'exposition d'un dispositif : un HIDS minimaliste est embarqué sur l'hôte, et remonte des alertes très simples à un IDS déporté. Ces informations peuvent être par exemple : le nombre de tentatives d'authentification; une connexion provenant d'une nouvelle adresse ip; l'utilisation de la bande passante; la détection d'un scan de ports[49].

Les NIDS ont l'avantage de ne nécessiter aucune ressource supplémentaire sur les nœuds du réseau pour l'analyse ou le stockage des évènements. Ils peuvent étudier le réseau dans sa totalité, et corréler des évènements provenant de plusieurs sources. Ils ont cependant accès à moins d'information, et ne peuvent pas forcément capturer les données échangées entre chaque nœud du réseau[48].

Analyse[modifier | modifier le code]

Analyse par signature 

Cette méthode vise à détecter des attaques connues. Elle nécessite une banque de connaissance qu'il faut maintenir régulièrement à jour. Cette méthode provoque très peu de faux négatifs, et nécessite peu de capacités de calcul. Elle est donc pratique à mettre en œuvre. Elle ne peut cependant détecter que des attaques connues, et est ainsi totalement inefficace contre les attaques zero day. Elle n'est pas suffisante si le système peut être la cible d'un attaquant évolué[50],[51].

Analyse comportementale 

Cette technique consiste à modéliser le fonctionnement du système, pour ensuite détecter des évènements anormaux qui ne satisfont pas ce modèle. La modélisation peut être faite par apprentissage artificiel, ou en utilisant une spécification prédéfinie. Le comportement des systèmes industriels est souvent régulier, régi par des interactions identifiables, et déterministe dans le temps. On peut donc les représenter de manière très fidèle. Cette méthode permet d'obtenir des IDS très sensibles, capables de détecter des attaques inconnues. Cependant ils peuvent entrainer des faux positifs ce qui les rend plus complexes à manier[52]. L'apprentissage artificiel du modèle peut être complexe : il y a de nombreuses méthodes de modélisation et d'apprentissage. Il faut donc choisir une méthode adaptée, lui fournir des entrées adéquates, et la paramétrer correctement. La modélisation par apprentissage artificiel est toutefois plus simple que l'analyse comportementale par spécification. La spécification est une représentation formelle qui doit être réalisée par des experts dotés d'une connaissance profonde du système. Cette tâche est très complexe, des erreurs sont possibles. Ces IDS peuvent atteindre un niveau d'efficacité très élevé si la spécification est de bonne qualité[53].

Les modèles comportementaux peuvent être modélisés sous diverses formes, comme les automates finis déterministes ou les modèles de Markov cachés[54]. De nombreuses techniques de régression ou de partitionnement peuvent être utilisées pour l'apprentissage, par exemple les K-moyennes, des réseaux de neurones, les machines à vecteurs de support, ou des méthodes de régression non paramétrique[55].

SIEM[modifier | modifier le code]

Les opérateurs d'infrastructures industrielles utilisent des systèmes de journalisation, qui peuvent être imposés par des normes sectorielles ou spécifiques aux infrastructures critiques. Un SIEM peut être utilisé pour regrouper les évènements. Cela permet de détecter des intrusions, ou de mieux en comprendre les effets, en corrélant les informations issues de sources hétérogènes.

Bibliographie[modifier | modifier le code]

Articles[modifier | modifier le code]

  • (en) R. Langner, « Stuxnet : Dissecting a Cyberwarfare Weapon », IEEE Security & Privacy, vol. 9, no. 3,‎ , p. 49-51 (DOI 10.1109/MSP.2011.67)
  • (en) A. W. Atamli et A. Martin (2014-09) « Threat-Based Security Analysis for the Internet of Things » in 2014 International Workshop on Secure Internet of Things. 2014 International Workshop on Secure Internet of Things: 35–43 (DOI:10.1109/SIoT.2014.10). 
  • (en) « TrustLite », sur www.trust.informatik.tu-darmstadt.de (consulté le 5 décembre 2016)
  • (en) Sandeep Nair Narayanan, Sudip Mittal et Anupam Joshi, « Using Data Analytics to Detect Anomalous States in Vehicles », arxiv,‎ (lire en ligne)
  • (en) Thomas H. Morris, Bryan A. Jones, Rayford B. Vaughn et Yoginder S. Dandass, « A Retrofit Network Intrusion Detection System for MODBUS RTU and ASCII Industrial Control Systems », 2012 45th Hawaii International Conference on System Sciences,‎ , p. 2338 (DOI 10.1109/HICSS.2012.78, lire en ligne)
  • (en) Thomas H. Morris, Bryan A. Jones, Rayford B. Vaughn et Yoginder S. Dandass, « Deterministic Intrusion Detection Rules for MODBUS Protocols », .,‎ (ISSN 1530-1605, lire en ligne)
  • (en) Rafael Ramos Regis Barbosaa, Ramin Sadrea et Aiko Prasb, « Flow whitelisting in SCADA networks », International Journal of Critical Infrastructure Protection Volume 6, Issues 3–4,‎ , p. 150-158 (DOI 10.1016/j.ijcip.2013.08.003)
  • (en) Niv Goldenberg et Avishai Wool, « Accurate modeling of Modbus/TCP for intrusion detection in SCADA systems », International Journal of Critical Infrastructure Protection,‎ , p. 63-75 (lire en ligne)
  • (en) Bilal Al Baalbaki, Jesus Pacheco, Cihan Tunc, Salim Hariri et Youssif Al-Nashif, « Anomaly Behavior Analysis System for ZigBee in smart buildings », 2015 IEEE/ACS 12th International Conference of Computer Systems and Applications (AICCSA),‎ (ISSN 2161-5330, lire en ligne)
  • (en) Robert Miller, « MWR Labs Whitepaper LoRa Security », MWR Labs Whitepaper,‎ (lire en ligne)
  • (en) Anhtuan Le, Jonathan Loo, Aboubaker Lasebae, Mahdi Aiash et Yuan Luo, « 6LoWPAN : a study on QoS security threats and countermeasures using intrusion detection system approach », International Journal of Communication Systems, vol. 25, no 9,‎ , p. 1189–1212 (ISSN 1099-1131, DOI 10.1002/dac.2356, lire en ligne)
  • (en) Chirag Modi, Dhiren Patel, Bhavesh Borisaniya, Hiren Patel, Avi Patel et Muttukrishnan Rajarajan, « A survey of intrusion detection techniques in Cloud », sciencedirect,‎ (lire en ligne)
  • (en) Ericson, « Cellular networks for massive IoT », Uen 284 23-3278,‎ (lire en ligne)
  • (en) Dr. Cédric LÉVY-BENCHETON (ENISA), Ms. Eleni DARRA (ENISA), Mr. Guillaume TÉTU (Trusted labs), Dr. Guillaume DUFAY (Trusted Labs) et Dr. Mouhannad ALATTAR (Trusted Labs), « Security and Resilience of Smart Home Environments Good practices and recommendations », European Union Agency For Network And Information Security,‎ (ISBN 978-92-9204-141-0, DOI 10.2824/360120, lire en ligne)
  • (en) Ovidiu Vermesan, Internet of Things – From Research and Innovation to Market Deployment, River Publishers, , 351 p. (ISBN 978-87-93102-94-1, lire en ligne)
  • (en) Xu Li, Rongxing Lu, Xiaohui Liang, Xuemin (Sherman) Shen, Jiming Chen et Xiaodong Lin, « Smart Community : An Internet of Things Application », dz,‎ (lire en ligne)
  • (en) Jan Henrik Ziegeldorf, Oscar Garcia Morchon et Klaus Wehrle, « Privacy in the Internet of Things : threats and challenges », Security and Communication Networks, vol. 7, no 12,‎ , p. 2728–2742 (ISSN 1939-0122, DOI 10.1002/sec.795, lire en ligne)
  • (en) Andrei Costin, Jonas Zaddach, Aurelien Francillon et Davide Balzarott, « A Large-Scale Analysis of the Security of Embedded Firmwares », 23rd USENIX Security Symposium (USENIX Security 14),‎ , p. 95-110 (ISBN 978-1-931971-15-7, lire en ligne)
  • (en) Arun Kanuparthi, Ramesh Karri et Sateesh Addepalli, « Hardware and Embedded Security in the Context of Internet of Things », Proceedings of the 2013 ACM Workshop on Security, Privacy \&\#38; Dependability for Cyber Vehicles,‎ , p. 61-64 (ISBN 978-1-4503-2487-8, DOI 10.1145/2517968.2517976)
  • (en) Petteri Mäki, Sampsa Rauti, Shohreh Hosseinzadeh, Lauri Koivunen et Ville Leppänen, « Interface Diversification in IoT Operating Systems », Proceedings of the 9th International Conference on Utility and Cloud Computing,‎ , p. 304-309 (ISBN 978-1-4503-4616-0, DOI 10.1145/2996890.3007877)
  • (en) Silvia Gil Casals, Risk assessment and intrusion detection for airbone networks, (lire en ligne)
  • (en) Sheetal Kalra et Sandeep K. Sood, « Secure authentication scheme for IoT and cloud servers », Pervasive and Mobile Computing, vol. 24,‎ , p. 210-223 (ISSN 1574-1192, DOI 10.1016/j.pmcj.2015.08.001, lire en ligne)

Divers[modifier | modifier le code]

Standards et recommandations[modifier | modifier le code]

Implémentations[modifier | modifier le code]

Références[modifier | modifier le code]

  1. Joseph Weiss 2010, p. 29
  2. Eric J. Byres 2004, p. 1
  3. Alvaro A. Cárdenas 2008
  4. Jill Slay 2008, p. 3
  5. Marshall Abrahms 2008
  6. John Leyden 2008
  7. Graeme Baker 2008
  8. a et b David E. Sanger 2012
  9. Ellen Nakashima 2011
  10. ISIS 2010
  11. R. Langner 2011
  12. Andy Greenberg 2008
  13. Karl Koscher 2010
  14. Stephen Checkoway 2011
  15. Charlie Miller 2015
  16. IEEE Computer Society 2003, p. 168
  17. Naveen Sastry 2004
  18. Adam Reziouk 2016
  19. Jonas Zaddach 2014, p. 95
  20. OVH 2016
  21. CERT 2016
  22. Zeek Muratovic 2015
  23. National Institute of Standards and Technology 2011, p. 3-3
  24. Eric J. Byres 2004, p. 3.1
  25. S. Park 2011, p. 15
  26. National Institute of Standards and Technology 2011, p. C-1
  27. Agence nationale de la sécurité des systèmes d'information 2014, p. 25
  28. Eric J. Byres 2004
  29. Sachin Babar 2010
  30. A. W. Atamli 2014, p. 41
  31. Kai Zhao 2013, p. 664
  32. National Institute of Standards and Technology 2015, p. 2-14
  33. Agence Nationale de la Sécurité des Systèmes d'Information 2014, p. 9
  34. National Institute of Standards and Technology 2015, p. 5-2
  35. Agence Nationale de la Sécurité des Systèmes d'Information 2014, p. 67
  36. Sheetal Kalra 2015, p. 210
  37. T. K. Buennemeyer 2007, p. 1
  38. a et b Stephen Checkoway 2011, p. 14
  39. Agence Nationale de la Sécurité des Systèmes d'Information 2014, p. 17
  40. EVITA 2009
  41. Kanuparthi 2013
  42. Charlie Miller 2015, p. 29
  43. Charlie Miller 2015, p. 48
  44. Safety Research & Strategies, Inc 2013
  45. Petteri Mäki 2016
  46. Mary-Ann Russon 2016
  47. Mitchell 2014, p. 5
  48. a et b Mitchell 2014, p. 8
  49. controleng.com 2015
  50. Mitchell 2014, p. 23
  51. Bonnie Zhu 2010, p. 14
  52. Bonnie Zhu 2010, p. 6
  53. Mitchell 2014, p. 7
  54. Niv Goldenberg 2010
  55. Silvia Gil Casals 2014, p. 85

Notes[modifier | modifier le code]

  1. Systèmes d'information
  2. Industrial control systems : Systèmes de contrôle industriel
  3. Intrusion detection system : Système de détection d'intrusion