Solutions traditionnelles de sécurité réseau

qui utilise des séquences De Bruijn

17

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 ouVPN en anglais, et les systèmes de détection ou de prévention

d’intrusion ouIDS/IPSen 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 ouVPN 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ésHIDS (ouHIPS), 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 dispaappa-raissent 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

Dans le document Détection d'intrusion dans des environnements connectés sans-fil par l'analyse des activités radio (Page 44-48)