qui utilise des séquences De Bruijn17 pour les ouvrir à distance. Sur le protocole
Z-Wave, qui est un protocole propriétaire moins connu de l’IoT, B. Fouladi et al. [Fouladi 2013] présentent un outil appelé Z-Force permettant d’intercepter les com- munications de ce protocole. Il montre également la présence d’une vulnérabilité sur l’implémentation du standard cryptographique AES pour des serrures connectées, qui permet l’ouverture à distance de celles-ci. Finalement, sur le protocole DVB- T, un protocole satellitaire utilisé par les télévisions connectées fonctionnant entre les fréquences 475 MHz et 850 MHz, Y. Bachy et al. [Bachy 2019] ont découvert des vulnérabilités permettant d’injecter des messages malveillants ou de prendre le contrôle à distance d’une télévision.
Au travers des attaques présentées ci-dessus, nous voyons toute la difficulté à imaginer une solution de sécurité capable de réaliser de la détection d’intrusion dans le contexte d’environnements connectés. En effet, cette solution doit être en mesure de détecter et/ou de protéger les systèmes vis-à-vis de l’ensemble des at- taques potentielles touchant des protocoles hétérogènes. Il faut donc que celle-ci soit suffisamment générique pour permettre de monitorer ces communications sans-fil très différentes, afin d’identifier des tentatives d’intrusion pouvant survenir sur ces surfaces d’attaques.
1.3
Solutions traditionnelles de sécurité réseau
Il nous faut à présent identifier les architectures existantes qui soient en mesure de réaliser de la détection/protection vis-a-vis des attaques de l’IoT. Pour cela, cette section présente un état de l’art de ces architectures, en identifiant les limites des approches traditionnellement utilisées dans les systèmes informatiques.
Dans le cas des solutions de sécurité réseau, c’est-à-dire cherchant à protéger ces systèmes des tentatives d’intrusions par le biais des communications filaires ou non- filaire, les trois composants principaux sont : le pare-feu ou firewall en anglais, le réseau privé virtuel ou VPN en anglais, et les systèmes de détection ou de prévention d’intrusion ou IDS/IPS en anglais. La problématique ici est de savoir s’il est possible d’utiliser ces solutions traditionnelles dans des environnements connectés, malgré les caractéristiques spécifiques de l’IoT.
1.3.1 Pare-feu
Le pare-feu, ou firewall en anglais, est un composant sécurisé, matériel ou logi- ciel, permettant d’implanter une politique de sécurité réseau. Celle-ci correspond à un ensemble de règles définissant les communications autorisées ou non. Un pare- feu est utilisé pour cloisonner des espaces dans le réseau, par exemple en séparant le réseau interne contenant des données sensibles du réseau externe, par exemple Internet. Il agit donc comme un filtre, qui va autoriser ou non une communication en fonction de son type, de son contenu (s’il n’est pas chiffré), de son destinataire
ou de sa source. L’exemple le plus connu de pare-feu est celui utilisé dans les dis- tributions Linux : iptables, qui permet de filtrer les messages reçus et envoyés sur une machine. Nous identifions 2 types de pare-feu :
— Pare-feu réseau : pare-feu positionné sur le réseau, au centre ou a minima au carrefour des communications de l’environnement qu’il cherche à protéger. L’exemple le plus courant est celui du pare-feu positionné sur le routeur ou sur le point d’accès du domicile, qui voit donc passer l’ensemble des commu- nications locales ainsi que celles entrantes et sortantes.
— Pare-feu personnel : pare-feu personnel positionné sur le système à protéger. Il est donc en mesure de voir tout le trafic produit par le système, ainsi que toutes les communications reçues. Le filtre peut donc rejeter des tentatives d’intrusions ou empêcher la propagation d’une bombe logique à d’autres sys- tèmes du réseau.
Cependant, dans le cas d’environnements connectés, ces types de pare-feu sont très difficiles à mettre en œuvre dans l’état. En effet, l’hétérogénéité des proto- coles utilisés et leur forte évolution rendent complexe l’utilisation d’un pare-feu réseau, puisqu’il n’est pas envisageable d’en proposer un qui soit en mesure d’ana- lyser toutes les communications, tout en restant maintenable. En outre, dans le cas des systèmes interconnectés traditionnels, les protocoles, filaires ou non-filaires, fonctionnent souvent dans un mode centralisé (c’est le cas du Wi-Fi par exemple). Ainsi, les communications passent toutes par un point d’interconnexion équipé d’un pare-feu, qui est à la capacité de les filtrer. Dans le cas des tentatives d’intrusion venant de l’extérieur, un pare-feu serait tout à fait en mesure de protéger les ob- jets connectés accessibles depuis Internet. Par exemple, dans le cas de Mirai, de simples règles interdisant les requêtes de connexion Telnet depuis l’extérieur au- raient suffi à limiter sa propagation. Or, les objets connectés utilisent souvent des protocoles ad hoc, et donc décentralisés. Un seul pare-feu réseau traditionnel serait donc dans l’incapacité de voir l’ensemble des échanges et ne pourrait pas appliquer ses règles de filtrage. Une solution potentielle serait d’utiliser plusieurs pare-feu ré- seaux, chacun dédié à un protocole. Cependant, ce type de solution est à la fois coûteux, contraignant et peu maintenable vis-à-vis des évolutions et du dynamise des environnements connectés.
Le second type de pare-feu est tout aussi inapplicable dans le domaine de l’IoT. En effet, une autre caractéristique importante des objets connectés est celle du minimalisme, imposant un certain nombre de contraintes à ces objets. Un pare-feu personnel intégré à chaque objet est donc difficilement concevable, puisqu’il impose des capacités de calcul et d’analyse suffisantes pour monitorer, analyser et filtrer les communications en entrée et en sortie. En outre, cela imposerait également aux constructeurs de concevoir des objets implémentant dès leur commercialisation ce composant, ce qui est aujourd’hui peu réaliste.
1.3. Solutions traditionnelles de sécurité réseau 33
1.3.2 Réseau Privé Virtuel (VPN)
Le réseau privé virtuel ou VPN en anglais, est un système qui permet d’isoler et de sécuriser les communications entre deux réseaux distants. L’idée est de construire un tunnel entre deux réseaux, dans lequel tout le trafic entrant et sortant de l’un des deux réseaux est échangé par le biais de ce tunnel. En ajoutant de l’authentification forte pour n’accepter des échanges qu’avec des systèmes ou utilisateurs autorisés, les échanges sont sécurisés entre deux systèmes.
Ce mécanisme est notamment utilisé dans l’IoT pour protéger les accès distants aux objets connectés localement au sein d’un environnement connecté. En effet, un utilisateur établissant un VPN depuis un réseau distant vers son réseau local composé d’objets sera considéré comme étant local, et pourra donc contrôler les objets malgré la présence d’un pare-feu ou d’un IDS. Ici aussi, le VPN peut être placé au niveau du réseau, tel que présenté précédemment, ou directement sur un système pour pouvoir s’y connecter de manière sécurisée. Ce deuxième type de VPN est peu applicable aux objets connectés, pour les mêmes raisons que celles énoncées pour les pare-feu personnels. Quant aux VPN réseaux, ils permettent en effet de s’authentifier et de sécuriser les échanges vers un réseau local composé d’objets, et donc est un bon moyen de se protéger des attaques venant de l’extérieur, notamment d’Internet. Cependant, il est inconcevable de mettre en place des VPN pour des objets qui communiquent de manière décentralisée, puisqu’il en faudrait un par objet, voire un par protocole utilisé par l’objet si celui-ci en utilise plusieurs. Dans ce cas, des solutions comme la cryptographie sont plus avantageuses pour établir une communication chiffrée et authentifiée entre deux objets.
1.3.3 Système de Détection/Prévention d’Intrusion (IDS/IPS)
Les derniers composants utilisés dans le cadre de la sécurité réseau sont les systèmes de détection ou de prévention d’intrusion ou IDS/IPS en anglais. Leur objectif est de détecter ou de prévenir des intrusions en analysant les échanges entre ou au sein de systèmes. Pour cela, ces systèmes doivent être en mesure de : capturer ces échanges, d’identifier une attaque dans ces captures et de lever une alerte et/ou d’empêcher la tentative d’intrusion après identification. Nous pouvons également identifié deux types d’IDS/IPS principaux :
— IDS/IPS réseaux : qui surveillent les échanges effectués sur le réseau, aussi appelés NIDS (ou NIPS), qui fonctionnent à l’aide d’une sonde spécifique positionné sur le réseau.
— IDS/IPS hôtes : qui surveillent la sécurité aux niveaux des hôtes, donc direc- tement au sein des systèmes, aussi appelés HIDS (ou HIPS), qui fonctionnent à l’aide d’une ou plusieurs sondes implantée(s) dans les hôtes.
Le type d’IDS/IPS qui nous intéresse dans notre cas est le NIDS, puisque c’est celui qui va permettre de surveiller les communications entre objets connectés dans un environnement. Les HIDS sont souvent utilisés dans les systèmes pour vérifier que des actions effectuées au sein du système n’impactent pas les propriétés de
sécurité, par exemple en vérifiant les fichiers de logs, les appels systèmes effectués ou en vérifiant l’accès à certaines ressources de ce système. Un exemple d’HIDS a été développé au sein du LAAS-CNRS par A. Damien et al. pour les systèmes avioniques [Damien 2018]. Des HIDS pourraient être implémentés dans les objets connectés pour assurer les propriétés de sécurité en interne. Cependant, les mêmes contraintes que précédemment s’appliquent, et seule une collaboration avec les fa- bricants peut permettre la mise en place de ce type de composant. Dans le cas du NIDS, les solutions existantes couvrent souvent les protocoles traditionnels tels que le Wi-Fi, ou des protocoles applicatifs. Or, les nombreux protocoles non-filaires de l’IoT ne sont souvent pas couverts, ou seulement partiellement. Une solution poten- tielle serait d’équiper un NIDS d’un grand nombre de récepteurs adaptés à tous les protocoles de l’IoT. Or, ces protocoles ont tendance à évoluer et de nouveaux appa- raissent et disparaissent dans les environnements, nécessitant des reconfigurations régulières de l’IDS pour pouvoir capturer et monitorer tous les échanges, même ceux ad hoc. De plus, les protocoles propriétaires dont les spécifications sont inconnues au préalable, qui sont caractéristiques de l’IoT, doivent également être observables, pour empêcher des attaques semblables à celles présentées par A. Francillon et al. [Francillon 2011] et S. Kamkar [Kamkar 2015].
Pour répondre aux problématiques de l’IoT, un composant spécifique semblable à un NIDS serait donc une solution intéressante, pourvu que celle-ci soit suffisam- ment générique pour limiter le besoin de reconfiguration et pour pouvoir monitorer tous les protocoles, notamment ceux propriétaires.
Pour l’identification des attaques, deux stratégies différentes sont utilisées : — IDS/IPS à signatures : une attaque est identifiée comme telle si les éléments
de la capture (contenu du paquet, métadonnées) correspondent à la signature d’une attaque connue ou déjà identifiée. Ce mode de fonctionnement est si- milaire à celui des antivirus, qui utilisent une base de signatures d’attaques pour pouvoir identifier une menace potentielle.
— IDS/IPS comportemental : une attaque est identifiée comme telle si les élé- ments de la capture correspondent à un comportement anormal. Dans le cas de ces IDS/IPS, un modèle de comportement normal est établi au préalable, correspondant à l’ensemble des communications considérées comme légitimes, donc sans malveillances. La capture d’une communication est donc comparée à ce modèle, et si celle-ci est sensiblement différente au modèle légitime, cette communication est identifiée comme étant illégitime.
Chaque type d’identification possède ses avantages et ses inconvénients. Les IDS/IPS à signatures sont plus précis, puisqu’ils possèdent une connaissance ex- haustive des attaques identifiées comme telles. Cependant, une attaque n’ayant jamais été rencontrée ou n’étant pas listée dans la base de signatures (c’est le cas des exploitations de vulnérabilités zero-day, correspondant à des vulnérabili- tés non connues) ne sera pas détectée comme étant une attaque. Au contraire, les IDS/IPS comportementaux sont en mesure de détecter des attaques non connues au préalable, puisqu’ils pourront identifier une communication malveillante de ce