Sécurité des systèmes cyber-physiques

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 Łódź, 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].

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.

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 la plage d'adresses ip allouée à ces voitures, puis le constructeur automobile a rappelé 1,4 million de véhicules pour une mise à jour du logiciel[15].

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 IEEE 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 IEEE 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 IEEE 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.

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 Dyne. 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 Tbit/s[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 par 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].

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[27]. 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[28].

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[29].

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 importants
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.

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[30].

Comme pour les ICS, les enjeux de sécurité sont variés. Une étude de l'université d'Aalborg[31] é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[32] :

L'utilisateur

Qui peut essayer d'extraire des secrets de l'objet, ou d'activer des fonctionnalités sans autorisation.

Le fabricant

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.

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 capteurs sont déployés dans des lieux faciles d'accès.

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

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.

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 fabricant 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[34] - [35].

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[36].

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é[37].

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[38].

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[39].

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[40].

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[41].

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[42].

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[43].

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[44].

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[45].

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é[46].

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[40].

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[47].

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[48]. 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.

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 destiné à 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[49] :

- 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.

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[50].

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[51].

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[50].

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é[52] - [53].

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[54]. 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é[55].

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[56]. 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[57].

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.

• (en) R. Langner, « Stuxnet : Dissecting a Cyberwarfare Weapon », IEEE Security & Privacy, vol. 9, no. 3,‎ 6-7 2011, p. 49-51 (DOI 10.1109/MSP.2011.67)
• (en) A. W. Atamli et A. Martin « Threat-Based Security Analysis for the Internet of Things » (septembre 2014) (DOI 10.1109/SIoT.2014.10)
  —2014 International Workshop on Secure Internet of Things
  — « (ibid.) », dans 2014 International Workshop on Secure Internet of Things, p. 35–43

• (en) T. K. Buennemeyer, M. Gora, R. C. Marchany et J. G. Tront, « Battery Exhaustion Attack Detection with Small Handheld Mobile Computers », 2007 IEEE International Conference on Portable Information Devices,‎ mai 2007, p. 1-5 (DOI 10.1109/PORTABLE.2007.35)
• (en) Institute for Science and International Security, « Stuxnet Malware and Natanz : Update of ISIS December 22, 2010 Report », 16 février 2011

• (en) Eric J. Byres, Matthew Franz et Darrin Miller « The Use of Attack Trees in Assessing Vulnerabilities in SCADA Systems » (CiteSeer^x 10.1.1.466.1887)
  — Institute for Electrical and Electronics Engineers, International Infrastructure Survivability Workshop (Lisbonne, 5-8 décembre 2004)
• (en) Ruijin Zhua, Baofeng Zhanga, Junjie Maoa, Quanxin Zhangb et Yu-an Tanb, « A methodology for determining the image base of ARM-based industrial control system firmware », International Journal of Critical Infrastructure Protection,‎ 28 novembre 2016 (DOI 10.1016/j.ijcip.2016.12.002)
• (en) Joseph Weiss, Protecting industrial control systems from electronic threats, 2010 (lire en ligne)
• (en) Jill Slay et Michael Miller, « Lessons learned from the Maroochy water breach », International Federation for Information Processing, Volume 253, Critical Infrastructure Protection,‎ 2008, p. 73-82 (ISBN 978-0-387-75461-1, lire en ligne)
• (en) MITRE et Joe Weiss, « Malicious Control System Cyber Security Attack Case Study - Maroochy Water Service, Australia », 23 juillet 2008
• (en) Alvaro A. Cárdenas, Saurabh Amin et Shankar Sastry, « Research Challenges for the Security of Control Systems », 2008
• (en) Ferdinand Brasser, Kasper B. Rasmussen, Ahmad-Reza Sadeghi et Gene Tsudik « Remote Attestation for Low-End Embedded Devices : the Prover’s Perspective » (DOI 10.1145/2897937.2898083, lire en ligne) [PDF]
  —53rd Annual Design Automation Conference (Juin 2016)

• (en) « TrustLite », sur www.trust.informatik.tu-darmstadt.de (consulté le 5 décembre 2016)

• (en) Charlie Miller et Chris Valasek, « Remote Exploitation of an Unaltered Passenger Vehicle », août 2015

• (en) Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno et al. « Experimental Security Analysis of a Modern Automobile » (16 mai 2010) (DOI 10.1109/SP.2010.34, lire en ligne)
  —IEEE Symposium on Security and Privacy (Oakland, CA, USA, 16-19 mai 2010)
  — « (ibid.) », dans 2010 IEEE Symposium on Security and Privacy, IEEE, 2010 (ISBN 978-1-4244-6894-2), p. 447-462

• (en) Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Karl Koscher, Alexei Czeskis, Franziska Roesner et Tadayoshi Kohno « Comprehensive Experimental Analyses of Automotive Attack Surfaces » (2011) (lire en ligne)
  — « (ibid.) », dans SEC'11 Proceedings of the 20th USENIX conference on Security, p. 6-6

• (en) Sandeep Nair Narayanan, Sudip Mittal et Anupam Joshi, « Using Data Analytics to Detect Anomalous States in Vehicles », arxiv,‎ décembre 2015 (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,‎ 4 janvier 2012, 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 », .,‎ janvier 2013 (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,‎ décembre 2013, 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,‎ janvier 2013, 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),‎ juillet 2016 (ISSN 2161-5330, lire en ligne)

• (en) Robert Miller, « MWR Labs Whitepaper LoRa Security », MWR Labs Whitepaper,‎ 22 mars 2016 (lire en ligne)

• (en) Andy Greenberg, « Hackers Cut Cities' Power », forbes,‎ 18 janvier 2008 (lire en ligne)
• (en) Sachin Babar, Parikshit Mahalle, Antonietta Stango, Neeli Prasad et Ramjee Prasad, « Proposed Security Model and Threat Taxonomy for the Internet of Things », Communications in Computer and Information Science,‎ 2010, p. 420-429 (ISBN 978-3-642-14478-3, DOI 10.1007/978-3-642-14478-3_42, lire en ligne)
• (en) Adam Reziouk, Arnaud Lebrun et Jonathan-Christofer Demay, « Auditing 6LoWPAN Networks Using Standard Penetration Testing Tools », DEFCON,‎ 2016 (lire en ligne)
• (en) S. Park, K. Kim, W. Haddad, S. Chakrabarti et J. Laganier, « 6lowpan security analysis », 16 septembre 2011
• (en) Naveen Sastry et David Wagner, « Security Considerations for IEEE 15.4 Networks », Wise'04,‎ 1^er octobre 2004 (lire en ligne)
• (en) Kai Zhao et Lina Ge, « A Survey on the Internet of Things Security », IEEE CPS,‎ octobre-décembre 2013, p. 663-667 (DOI 10.1109/CIS.2013.145, lire en ligne)
  Secure IOT.
• (en) Robert MITCHELL et Chen ING-RAY, « A Survey of Intrusion Detection Techniques for Cyber-Physical Systems », ACM Computing Surveys,‎ avril 2014 (DOI 10.1145/2542049)
• (en) Bonnie Zhu et Shankar Sastry « SCADA-specific Intrusion Detection/Prevention Systems : A Survey and Taxonomy »
  —First Workshop on Secure Control Systems (SCS) (Stockholm, 12 avril 2010)
• (en) Safety Research & Strategies, Inc, « Toyota Unintended Acceleration and the Big Bowl of “Spaghetti” Code », 7 novembre 2013
• (en) « Intrusion detection software lowers Internet of Things (IoT) risk », sur controleng.com, 06/24/2015

• (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, n^o 9,‎ 1^er septembre 2012, p. 1189–1212 (ISSN 1099-1131, DOI 10.1002/dac.2356, lire en ligne, consulté le 5 décembre 2016)

• (en) « A Pattern Matching Model for Misuse Intrusion Detection » (consulté le 6 décembre 2016)

• (en) Chirag Modi, Dhiren Patel, Bhavesh Borisaniya, Hiren Patel, Avi Patel et Muttukrishnan Rajarajan, « A survey of intrusion detection techniques in Cloud », sciencedirect,‎ janvier 2013 (lire en ligne)

• (en) Ericson, « Cellular networks for massive IoT », Uen 284 23-3278,‎ janvier 2016 (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,‎ décembre 2015 (ISBN 978-92-9204-141-0, DOI 10.2824/360120, lire en ligne)

• (en) Ovidiu Vermesan et Peter Friess, Internet of Things – From Research and Innovation to Market Deployment, River Publishers, 2014, 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,‎ 11 (lire en ligne)

• (en) « Name - IERC_Position_Paper_IoT_Governance_Privacy_Security_Final.pdf » (consulté le 5 décembre 2016)

• (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, n^o 12,‎ 1^er décembre 2014, p. 2728–2742 (ISSN 1939-0122, DOI 10.1002/sec.795, lire en ligne, consulté le 5 décembre 2016)

• (en) Shahid Raza, Linus Wallgren et Thiemo Voigt, « SVELTE : Real-time intrusion detection in the Internet of Things », Ad Hoc Networks, vol. 11, n^o 8,‎ novembre 2013, p. 2661–2674 (ISSN 1570-8705, DOI 10.1016/j.adhoc.2013.04.014, lire en ligne, consulté le 6 décembre 2016)

• (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),‎ 2014, 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 & Dependability for Cyber Vehicles,‎ 2013, 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,‎ 2016, 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, 2014 (lire en ligne)
• (en) Sheetal Kalra et Sandeep K. Sood, « Secure authentication scheme for IoT and cloud servers », Pervasive and Mobile Computing, vol. 24,‎ 2015, p. 210-223 (ISSN 1574-1192, DOI 10.1016/j.pmcj.2015.08.001, lire en ligne)

• (en) John Leyden, « Polish teen derails tram after hacking train network », The Register,‎ 11 janvier 2008 (lire en ligne)
• (en) Graeme Baker, « Schoolboy hacks into city's tram system », The Telegraph,‎ 11 janvier 2008 (lire en ligne)
• (en) David E., « Obama Order Sped Up Wave of Cyberattacks Against Iran », New York Times,‎ 1^er juin 2012 (lire en ligne)
• (en) Ellen Nakashima et Joby Warrick, « Stuxnet was work of U.S. and Israeli experts, officials say », Washington Post,‎ 2 juin 2012 (lire en ligne)
• Ludovic APVRILLE et Letitia LI, « Sécurité des véhicules connectées et/ou autonomes », misc,‎ septembre 2016 (lire en ligne)
• OVH, « La goutte DDoS n'a pas fait déborder le VAC », 5 octobre 2016
• (en) Zeek Muratovic, « Mirai Detection / Mitigation », 5 octobre 2015
• (en) Mary-Ann Russon, « How to stop the Mirai botnet : Can blocking Port 23 fight further DDoS attacks? », 3 novembre 2016

• Institut national des hautes études de la sécurité et de la justice, « La Loi de Programmation militaire appliquée à La CyberséCurité », juillet 2015
• Agence nationale de la sécurité des systèmes d'information, « La cybersécurité des systèmes industriels »
• Agence nationale de la sécurité des systèmes d'information, « Sécurité industrielle : Méthode de classification et mesures principales », janvier 2014
• Agence nationale de la sécurité des systèmes d'information, « Sécurité industrielle : Mesures détaillées », janvier 2014
• (en) The International Society of Automation, « Industrial Automation and Control Systems Security »
• (en) National Institute of Standards and Technology, « Framework for Improving Critical Infrastructure Cybersecurity », 12 février 2014
• (en) National Institute of Standards and Technology, « Guide to Industrial Control Systems (ICS) Security - revision 2 », mai 2015
• (en) National Institute of Standards and Technology, « Guide to Industrial Control Systems (ICS) Security », juin 2011
• (en) National Institute of Standards and Technology, « Guide to Intrusion Detection and Prevention Systems », février 2007
• (en) National Institute of Standards and Technology, « Systems Security Engineering », novembre 2016

• (en) EVITA, « E-safety vehicle intrusion protected applications »
• (en) CERT, « Heightened DDoS Threat Posed by Mirai and Other Botnets », 14 octobre 2016

• (en) IEEE Computer Society, « Part 15.4 : Low-Rate Wireless Personal Area Networks (LR-WPANs) », 1^er octobre 2003

• (en) « Contiki-IDS »
• (en) « QuickDraw (règles SNORT pour Modbus) »
• (en) « EMERALD : Event Monitoring Enabling Responses to Anomalous Live Disturbances »
• (en) FUJITSU, « SHE Secure Hardware Extension »
• (en) SIEMENS, « Anti-virus Solutions for Control Centers »