• Aucun résultat trouvé

3.4 Techniques de sécurité réactives

4.1.1 Hypothèses d’attaque

4.2 Principe de fonctionnement . . . . 80

4.2.1 Emplacement de l’IDS . . . . 80

4.2.2 Fonctionnement général . . . . 81

4.2.3 Synthèse . . . . 85

4.3 Formalisation d’une méthode de corrélation . . . . 85

4.3.1 Automates finis . . . . 86

4.3.2 Génération d’un langage d’attaques . . . . 87

4.4 Évaluation de la complexité . . . . 89

4.4.1 Méthode « naïve » basée sur les AFD . . . . 89

4.4.2 Réduction de la complexité spatiale . . . . 92

4.4.3 Passage à l’échelle . . . . 94

4.5 Énumération des séquences d’attaque minimales . . . . 96

4.6 Conclusion . . . . 98

Comme nous l’avons vu dans le chapitre 2, les réseaux automobiles actuels sont

vulnérables aux attaques. En effet, un attaquant ayant obtenu un accès sur un

réseau embarqué peut alors effectuer des actions de type lecture, interruption,

mo-dification ou fabrication de trames pour atteindre ses objectifs. Comme vu dans le

chapitre 3, la sécurisation des systèmes embarqués est devenue une priorité pour les

constructeurs ; nécessitant la mise en place de politiques de sécurité tenant compte

des spécificités des systèmes embarqués dans les automobiles, tout en considérant

les réseaux automobiles dans leur ensemble. Ainsi, en plus des techniques

préven-tives visant à empêcher un attaquant de pénétrer le réseau, il apparaît également

nécessaire de mettre en place des mécanismes surveillant le réseau « depuis

l’inté-rieur », tels que des systèmes de détection d’intrusion. Or, comme nous l’avons vu

dans le chapitre 1, les solutions de sécurité pour l’automobile doivent tenir compte

des contraintes de compatibilité et d’autonomie, en plus des contraintes générales

liées à la conception de systèmes embarqués.

76

Chapitre 4. Détection d’intrusion pour les réseaux automobiles

embarqués

Dans ce chapitre, nous présentons un système de détection d’intrusions pour les

réseaux automobiles embarqués se basant sur le trafic réseau observé. Ce chapitre

s’agence ainsi :

– La section 4.1 détaille la problématique, nous y décrivons les hypothèses que

nous faisons au sujet des attaquants et présentons les objectifs de notre

sys-tème.

– La section 4.2 décrit le fonctionnement général de notre système de détection

d’intrusion afin de remplir les objectifs définis précédemment.

– Dans la section 4.3, nous formalisons notre méthode de génération de

signa-tures d’attaque à partir de spécifications du système observé.

– Dans la section 4.4, nous évaluons la complexité (spatiale et temporelle) de

notre système et confrontons en ces termes deux implémentations possibles

de détection d’intrusion basées sur les signatures précédemment définies.

– Finalement, nous nous intéressons à la génération de séquences d’attaques

minimales, qui peut s’avérer utile dans le cadre d’analyses forensics.

4.1 Problématique

Comme nous l’avons vu dans le chapitre 2, la littérature comprend désormais

plusieurs exemples documentés d’attaques ciblant les réseaux automobiles

embar-qués (et plus spécifiquement CAN). De telles attaques vont d’une approche en

« boîte noire » [HKD09], visant à découvrir le réseau embarqué et identifier les

trames susceptibles d’être utilisées pour contrôler les ECU ciblés par de futures

at-taques [MV13], à des reprogrammations d’ECU via le réseau [KCR+10]. De plus, en

2011, Checkowayet al.[CMK+11] ont prouvé qu’il était possible d’obtenir un accès

sur le réseau embarqué à distance en exploitant des vulnérabilités présentes dans

les ECU responsables des communications avec l’extérieur. Ce faisant, ils furent

alors capables de reproduire des attaques contre le réseau embarqué décrites dans

[KCR+10], prenant ainsi le contrôle à distance sur les calculateurs embarqués.

4.1.1 Hypothèses d’attaque

Dans le cadre de nos travaux, nous supposons ainsi qu’un attaquant a réussi à

obtenir un accès au réseau interne. Nous supposons alors que celui-ci va chercher à

utiliser cet accès pour poursuivre son attaque contre le véhicule afin de perturber

ou prendre le contrôle d’autres calculateurs accessibles via le réseau interne. Notre

objectif est alors de détecter une attaque en cours en identifiant depuis le réseau des

actions de l’attaquant observables ou des comportements inattendus d’un

(sous)-système, découlant de ces actions. En d’autres termes, nos travaux visent à détecter

une intrusion sur le réseau embarqué et non à identifier les origines de cette intrusion

(attaque à distance, connexion sur le port OBD, sabotage en usine. . . ). Si nous

reprenons la classification présentée dans la section 2.4, nous considérons donc les

attaques interagissant avec le réseau, et entraînant une compromission temporaire

4.1. Problématique 77

ou durable de celui-ci. Les conditions relatives à l’origine de l’intrusion (portée et

lien) ne rentrent pas en considération.

Nous supposons par ailleurs que l’attaquant peut avoir une connaissance avancée

du réseau – telle que son architecture détaillée, ou la signification des données

circulant sur les bus – sur lequel il s’est introduit. Nous considérons finalement que

pour atteindre son objectif, l’attaquant va devoir interagir avec le réseau interne du

véhicule afin de contrôler ou perturber des ECU distincts de son point d’entrée.

En fonction des moyens d’action de l’attaquant, ces attaques peuvent se traduire

de différentes façon sur le réseau. En effet, si l’attaquant possède un contrôle total

sur un ou des ECU émettant normalement les messages concernés par son attaque,

il peut alors contrôler leurs transmissions et choisir précisément quelles trames

se-ront transmises ou non, quel sera leur contenu et à quel moment la transmission

aura lieu. En revanche, s’il contrôle un élément différent de ces ECU sur le réseau,

il ne pourra pas contrôler aussi précisément la transmission de données sur le bus.

Dans ce cas, les trames envoyées par l’attaquant cohabiteront alors sur le bus avec

leurs versions légitimes, toujours émises par les ECU correspondants. L’attaquant

ne peut pas non plus stopper ces transmissions légitimes, à moins de provoquer

un déni de service sur le bus. Les deux cas précédents supposent que l’attaquant

sait précisément ce qu’il doit faire pour mener son attaque à bien. Or, il est bien

entendu également envisageable qu’un attaquant ne possède pas suffisamment de

connaissances à propos du réseau sur lequel il s’est introduit et cherche à en

ap-prendre plus, ou qu’il se trompe. Ses actions peuvent donc également être à l’origine

de trafic incohérent.

Par conséquent, nous pouvons alors distinguer quatre types de comportements

suspects sur le réseau :

1. Les trames ne respectant pas les spécifications du protocole réseau.

Typique-ment, dans le cas de CAN, cela concerne par exemple les trames comportant

un identifiant inconnu, un champ de données de la mauvaise taille, un CRC

incorrect, etc.

2. Des trames (ou séquences de trames) malveillantes émises périodiquement

alors que le trafic légitime correspondant est toujours généré par le système.

Par exemple, un attaquant émet périodiquement une trame commandant

l’ex-tinction des feux de croisement alors que le système émet des trames

deman-dant leur allumage.

3. Des trames ou séquences malveillantes périodiques émises en remplacement

des trames légitimes. Ces dernières ne sont alors plus émises sur le réseau.

4. Des trames ou séquences malveillantes émises ponctuellement, correspondant

à des trames bien formées non périodiques dont l’émission est normalement

conditionnée par un événement donné.

78

Chapitre 4. Détection d’intrusion pour les réseaux automobiles

embarqués