HAL Id: tel-02351769
https://hal.univ-lorraine.fr/tel-02351769
Submitted on 6 Nov 2019
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Orchestration et vérification de fonctions de sécurité pour des environnements intelligents
Nicolas Schnepf
To cite this version:
Nicolas Schnepf. Orchestration et vérification de fonctions de sécurité pour des environnements in-
telligents. Réseaux et télécommunications [cs.NI]. Université de Lorraine, 2019. Français. �NNT :
2019LORR0088�. �tel-02351769�
AVERTISSEMENT
Ce document est le fruit d'un long travail approuvé par le jury de soutenance et mis à disposition de l'ensemble de la communauté universitaire élargie.
Il est soumis à la propriété intellectuelle de l'auteur. Ceci implique une obligation de citation et de référencement lors de l’utilisation de ce document.
D'autre part, toute contrefaçon, plagiat, reproduction illicite encourt une poursuite pénale.
Contact : [email protected]
LIENS
Code de la Propriété Intellectuelle. articles L 122. 4
Code de la Propriété Intellectuelle. articles L 335.2- L 335.10 http://www.cfcopies.com/V2/leg/leg_droi.php
http://www.culture.gouv.fr/culture/infos-pratiques/droits/protection.htm
Ecole doctorale IAEM Lorraine´
Orchestration et v´ erification de fonctions de s´ ecurit´ e pour des
environnements intelligents
TH` ESE
pr´ esent´ ee et soutenue publiquement le 30 septembre 2019 pour l’obtention du
Doctorat de l’Universit´ e de Lorraine
(mention informatique)
par
Nicolas Schnepf
Composition du jury
Rapporteurs : Christine Choppy, Professeur, LIPN, Universit´ e Paris 13, France Stefano Secci, Professeur, CNAM, France
Examinateurs : Sandrine Vaton, Professeur, IMT Atlantique, France Fran¸ cois Charoy, Professeur, Score - Loria, France
Stephan Merz, Directeur de recherche, Veridis - Loria, France Remi Badonnel, Maˆıtre de conf´ erences, Resist - Loria, France Invit´ e : Abdelkader Lahmadi, Maˆıtre de conf´ erences, Resist - Loria, France
Laboratoire Lorrain de Recherche en Informatique et ses Applications — UMR 7503
Remerciements
En premier lieu, je tiens à remercier mes maîtres de thèse pour leur patience et leurs conseils
tout au long des travaux de cette thèse. Je tiens également à remercier les rapporteurs pour leur
travail de relecture de ce manuscrit. Je tiens aussi à remercier les instances de l’école doctorale
IAEM pour leur accompagnement dans toutes les démarches administratives relatives au bon
déroulement de la thèse. Je tiens enfin à remercier Pascal Fontaine pour sa figure décrivant
l’architecture d’un SMT solver illustrant cette méthode dans le chapitre relatif à l’état de l’art.
Table des matières
Chapitre 1
Introduction 1
1.1 Contexte de notre travail de recherche . . . . 1
1.1.1 Sécurité des environnements intelligents . . . . 1
1.1.2 Chaînes de fonctions de sécurité . . . . 2
1.2 Défis et problématique . . . . 3
1.2.1 Défis liés à l’orchestration de chaînes de fonctions de sécurité . . . . 4
1.2.2 Problématique relative à cette thèse . . . . 4
1.3 Plan de la thèse . . . . 5
Chapitre 2 Etat de l’art 9 2.1 Sécurité des équipements intelligents . . . . 9
2.1.1 Menaces réseau contre les équipements intelligents . . . . 9
2.1.2 Système de permissions des environnements Android . . . . 11
2.1.3 Profilage du comportement d’applications Android . . . . 12
2.1.4 Synthèse des travaux existants et limites . . . . 14
2.2 Programmabilité des réseaux pour la sécurité . . . . 14
2.2.1 Réseaux programmables SDN . . . . 14
2.2.2 Langages pour la programmation de contrôleurs SDN . . . . 16
2.2.3 Virtualisation de fonctions de sécurité . . . . 18
2.2.4 Chaînage de fonctions de sécurité . . . . 19
2.2.5 Synthèse des travaux existants et limites . . . . 21
2.3 Méthodes de vérification formelle . . . . 21
2.3.1 Méthodes de model checking . . . . 22
2.3.2 Méthodes de SMT solving . . . . 23
2.3.3 Méthodes de programmation linéaire . . . . 24
2.3.4 Applications de méthodes formelles . . . . 25
2.3.5 Synthèse des travaux existants et limites . . . . 29
2.4 Résumé . . . . 30
Chapitre 3 Orchestration pour la protection d’applications Android 33 3.1 Architecture réseau de notre approche d’orchestration . . . . 33
3.1.1 Insertion de l’orchestrateur dans le réseau . . . . 33
3.1.2 Relation entre l’orchestrateur et les équipements intelligents . . . . 34
3.1.3 Relation entre l’orchestrateur et les chaînes de fonctions de sécurité . . . 35
3.1.4 Relation entre l’orchestrateur et le réseau SDN . . . . 36
3.2 Architecture logicielle de notre orchestrateur . . . . 37
3.3 Apprentissage du comportement réseau d’applications . . . . 38
3.3.1 Collecte des données relatives aux flux réseau . . . . 38
3.3.2 Stratégies d’agrégation des flux réseau . . . . 39
3.3.3 Algorithme de construction du modèle de comportement réseau d’une ap- plication Android . . . . 40
3.3.4 Exemples d’automates . . . . 40
3.4 Prototype et résultats expérimentaux . . . . 42
3.4.1 Prototypage . . . . 43
3.4.2 Evaluation de la simplicité des automates . . . . 43
3.4.3 Evaluation de la précision des automates . . . . 45
3.5 Résumé . . . . 46
Chapitre 4 Synthèse de chaînes de fonctions de sécurité 49 4.1 Construction du modèle logique d’une application . . . . 49
4.1.1 Définitions et rappels concernant les flux réseau . . . . 49
4.1.2 Caractérisation logique du comportement d’une application . . . . 50
4.2 Construction de la chaîne associée à une application . . . . 51
4.2.1 Modèle logique des chaînes de fonctions de sécurité . . . . 52
4.2.2 Système d’inférence de la spécification logique d’une chaîne de fonctions de sécurité . . . . 52
4.2.3 Traduction de la chaîne en pyretic . . . . 53
4.2.4 Reprise de l’exemple de l’application Pokemon Go . . . . 53
4.3 Propriétés de correction des chaînes générées . . . . 54
4.3.1 Routage des paquets . . . . 54
4.3.2 Absence d’obscurcissement et cohérence . . . . 55
4.4 Introduction du problème de factorisation . . . . 56
4.4.1 Modèle des chaînes de fonctions de sécurité dans une approche orientée objet . . . . 56
4.4.2 Approches naïves pour la résolution du problème de factorisation . . . . . 56
4.4.3 Exemple de factorisation de chaînes de fonctions de sécurité . . . . 57
4.5 Algorithme de factorisation . . . . 58
4.5.1 Factorisation des fonctions de sécurité . . . . 59
4.5.2 Factorisation des chaînes . . . . 59
4.5.3 Reprise de l’exemple de factorisation . . . . 59
4.6 Prototype et résultats expérimentaux . . . . 60
4.6.1 Prototypage . . . . 60
4.6.2 Complexité des chaînes de sécurité . . . . 61
4.6.3 Surcoût de la composition de chaînes . . . . 61
4.6.4 Précision des chaînes de sécurité . . . . 62
4.7 Résumé . . . . 64
Chapitre 5 Vérification automatique de chaînes de fonctions de sécurité 67 5.1 Approche pour la vérification formelle de chaînes de fonctions de sécurité . . . . 67
5.1.1 Stratégie de vérification . . . . 67
5.1.2 Architecture supportant la vérification . . . . 68
5.2 Traduction des chaînes en modèles formels . . . . 69
5.2.1 Algorithme de traduction vers un modèle vérifiable par SMT solving . . . 69
5.2.2 Algorithme de traduction vers un modèle vérifiable par model checking . 70 5.3 Prototype et résultats expérimentaux . . . . 72
5.3.1 Prototypage . . . . 72
5.3.2 Impact de la taille de l’automate de contrôle sur les performances de vé- rification . . . . 73
5.3.3 Impact de la largeur et de la longueur des chaînes sur les performances de vérification . . . . 75
5.3.4 Impact du nombre de propriétés à vérifier sur les performances de vérification 78 5.4 Résumé . . . . 79
Chapitre 6 Placement et déploiement de chaînes de fonctions de sécurité 81 6.1 Modèle de placement . . . . 81
6.1.1 Motivation du problème . . . . 81
6.1.2 Stratégies d’abstraction du modèle de placement . . . . 82
6.1.3 Variables du problème de placement de chaînes de fonctions de sécurité . 83 6.1.4 Modèle des contraintes . . . . 84
6.1.5 Objectifs d’optimisation . . . . 85
6.2 Intégration du modèle de placement dans l’architecture d’orchestration . . . . 86
6.2.1 Architecture du module d’optimisation . . . . 86
6.2.2 Placement des règles d’une chaîne de fonctions de sécurité . . . . 87
6.3 Prototype et résultats expérimentaux . . . . 88
6.3.1 Implémentation et prototype . . . . 88
6.3.2 Influence du nombre de chemins . . . . 89
6.3.3 Influence du nombre d’agrégats de destinations . . . . 89
6.4 Résumé . . . . 90
Chapitre 7 Conclusions et perspectives 93 7.1 Bilan des travaux de la thèse . . . . 93
7.2 Liste des publications relatives à cette thèse . . . . 94
7.3 Réponses apportées à la problématique . . . . 95
7.3.1 Orchestration de fonctions réseau . . . . 95
7.3.2 Vérification formelle de chaînes de sécurité . . . . 95
7.3.3 Optimisation du déploiement des chaînes de sécurité . . . . 96
7.4 Perspectives de recherche . . . . 96
7.4.1 Amélioration de la détection de comportements malveillants . . . . 96
7.4.2 Exploitation et intégration de nouvelles méthodes formelles . . . . 96
7.4.3 Performances des chaînes de fonctions de sécurité . . . . 97 Annexe A
Spécification SMTlib d’une politique de pare-feux distribués 99 Annexe B
Spécification nuXmv d’une politique de pare-feux distribués 101
Bibliographie 103
Table des figures
1.1 Diagramme des relations entre les chapitres de contributions de la thèse . . . . . 7
2.1 Tableau de synthèse des approches relatifs à la sécurité des environnements intel- ligents (protection des applications Android) . . . . 13
2.2 Schéma de l’architecture SDN (www.opennetworking.org) . . . . 15
2.3 Tableau de synthèse des travaux sur la programmabilité réseau et la virtualisation de la sécurité dans le réseau . . . . 20
2.4 Architecture d’un SMT solver . . . . 24
2.5 Tableau de synthèse des travaux sur les méthodes formelles . . . . 31
3.1 Intégration de notre orchestrateur au sein de l’architecture d’un réseau SDN . . . 34
3.2 Architecture de notre orchestrateur de chaînes de fonctions de sécurité . . . . 37
3.3 Architecture interne du module de synthèse de chaînes de fonctions de sécurité . 38 3.4 Descriptif des applications considérées dans le cadre de nos travaux . . . . 39
3.5 Automate obtenu par Synoptic pour l’application considérée . . . . 42
3.6 Automate obtenu par Invarimint pour l’application considérée . . . . 43
3.7 Automate obtenu par notre approche pour l’application considérée . . . . 43
3.8 Diagramme de classes décrivant le prototype de notre orchestrateur . . . . 44
3.9 Simplicité des automates générés avec les méthodes considérées . . . . 44
3.10 Impact de l’abstraction sur les ports sur la simplicité des automates . . . . 45
3.11 Précision des automates basés sur les orgnames . . . . 45
3.12 Précision des automates basée sur les adresses IP . . . . 46
4.1 Illustration du problème de factorisation . . . . 57
4.2 Exemple d’une chaîne de sécurité générée pour protéger une application Android donnée . . . . 58
4.3 Extrait d’une chaîne de sécurité résultant d’une composition parallèle . . . . 58
4.4 Extrait d’une chaîne de sécurité obtenue par application de la composition par factorisation . . . . 60
4.5 Caractéristiques des chaînes de fonctions de sécurité générées pour chaque appli- cation. . . . 60
4.6 Diagramme des classes du langage de propriétés utilisé par notre orchestrateur . 61 4.7 Diagramme des classes du module de génération de chaînes de fonctions de sécurité 62 4.8 Diagramme des classes implantant les chaînes et les fonctions de sécurité . . . . . 63
4.9 Nombre de règles des différentes approches de composition . . . . 63
4.10 Temps total pour les approches de composition groupée et par factorisation . . . 64
4.11 Précision de la chaîne générée pour chaque application . . . . 64
5.1 Diagramme d’interactions entre les différents composants de notre module de
vérification . . . . 68
5.2 Automate du plan de données pour l’exemple jouet . . . . 71
5.3 Diagramme des classes de notre module de vérification de chaînes de sécurité . . 73
5.4 Diagramme des classes de notre langage de propriétés pour les chaînes de sécurité 74 5.5 Temps de réponse en fonction de la taille de l’automate de contrôle . . . . 74
5.6 Consommation mémoire en fonction de la taille de l’automate de contrôle . . . . 75
5.7 Temps de réponse en fonction de la largeur de la chaîne à vérifier . . . . 76
5.8 Consommation mémoire en fonction de la largeur de la chaîne à vérifier . . . . . 76
5.9 Temps de réponse en fonction de la longueur de la chaîne à vérifier . . . . 77
5.10 Consommation mémoire en fonction de la longueur de la chaîne à vérifier . . . . 77
5.11 Temps de réponse de nuXmv vs. à la fois la largeur et la longueur . . . . 78
5.12 Performance de nuXmv vs. nombre de propriétés devant être validées . . . . 79
6.1 Topologie réseau pour l’exemple de placement . . . . 82
6.2 Caractéristiques des chemins de la topologie exemple . . . . 83
6.3 Architecture pour l’optimisation de chaînes de fonctions de sécurité . . . . 87
6.4 Diagramme des classes de notre module d’optimisation de chaînes de sécurité . . 88
6.5 Influence du nombre de chemins sur le temps de réponse . . . . 89
6.6 Influence du nombre de chemins sur la consommation mémoire . . . . 90
6.7 Influence du nombre d’agrégats de destinations sur le temps de réponse . . . . . 91
6.8 Influence du nombre d’agrégats de destinations sur la consommation mémoire . . 91
1
Introduction
Ce chapitre a pour vocation d’introduire le questionnement propre à cette thèse portant sur l’orchestration et la vérification de fonctions de sécurité pour des environnements intelligents.
Nous commençons par présenter le contexte de notre travail, à savoir la protection des environ- nements intelligents. Nous définissons également le concept de chaînes de fonctions de sécurité, et son usage dans ce cadre. Nous présentons ensuite les différents défis liés à l’orchestration de fonctions de sécurité, avant de décrire la problématique spécifique de la présente thèse et les trois axes sur lesquels elle s’articule. Finalement, nous terminons ce chapitre par l’annonce du plan du reste de ce manuscrit, qui suit la structure induite par les questionnements introduits dans ce chapitre.
1.1 Contexte de notre travail de recherche
Notre travail porte sur la protection d’environnements intelligents, et plus particulièrement les smartphones et tablettes. De manière générale, ces environnements peuvent être définis comme des équipements pouvant offrir des fonctionnalités proches de celles de postes fixes, tout en n’en ayant pas les mêmes ressources en termes de batterie ou de puissance de calcul.
La protection de ces équipements est de ce fait difficile à implanter. Le recours à des méthodes de chaînage de fonctions de sécurité, qui peuvent être externalisées dans le cloud, offre des perspectives intéressantes à cet égard.
1.1.1 Sécurité des environnements intelligents
La protection des environnements intelligents est un enjeu majeur pour la cyber-sécurité.
Comme indiqué précédemment, nous nous intéressons plus spécifiquement aux équipements mo- biles à ressources limitées, que sont les smartphones et tablettes. En particulier, Android est devenu le premier système d’exploitation pour ces équipements avec 85,1 % de part du marché des smartphones en 2018 [58]. Le nombre d’applications disponibles sur les marchés correspon- dants, par exemple le Google Play Store, est marqué par une croissance exponentielle qui souligne la popularité de cette plateforme. Ceci introduit également des problèmes de sécurité du fait des applications malveillantes pouvant servir de vecteurs d’attaques [67]. En 2018, plus de 3 mil- lions d’applications malveillantes ont été repéré sur les marchés dédiés au système d’exploitation Android [50], ce qui souligne bien l’enjeu en terme de cyber-sécurité.
Les menaces pesant sur les équipements intelligents sont de plusieurs natures. On rencontre,
en premier lieu, les applications qui collectent les données personnelles des utilisateurs, avant de
les transmettre frauduleusement à des serveurs externes. Plusieurs cas de worms ont également été identifiés, il s’agit le cas échéant d’applications capables de s’auto-répliquer au travers d’un réseau en exploitant les vulnérabilités des systèmes d’exploitation. Ce mode d’infection des équipements intelligents peut par exemple être utilisé afin de les transformer en machines zombies en vue de les enrôler dans un botnet, un réseau de machines corrompues. De tels réseaux peuvent ensuite être utilisés afin de pratiquer des attaques de dénis de service, ou des scans de ports à large échelle. Finalement, on repère aussi de nombreux cas de rançonwares dans lesquels une application va chiffrer le contenu d’un équipement et proposer le déchiffrement moyennant une certaine somme de laquelle l’utilisateur devra s’acquitter.
Le développement de ces menaces peut s’expliquer par plusieurs facteurs. D’abord, il est important de souligner l’insuffisance des méthodes dites préventives actuellement déployées au niveau des marchés (e.g. Google Play Store). Ces méthodes consistent à valider la sûreté et la sécurité d’une application à partir des interfaces logicielles qu’elle propose ainsi qu’au travers d’exécutions symboliques ou simulées en environnements contrôlés. Ces méthodes permettent ainsi de détecter des applications potentiellement malveillantes pour les utilisateurs. Néanmoins, au regard des chiffres cités plus haut, il ressort clairement que : si elles sont nécessaires, elles sont loin d’être suffisantes pour assurer la protection de ces environnements. La première limita- tion propre aux méthodes dites préventives provient du fait qu’elles procèdent à une validation automatisée et standardisée des applications, et qu’à ce titre certaines failles peuvent échapper à leur vigilance. En outre, les méthodes dites préventives permettent la détection d’applications constatées comme malveillantes, lors de leur mise à disposition sur les marchés. En revanche, dans le cas où la partie malveillante se trouve comme souvent être dissimulée dans une mise à jour, elles restent inopérantes. Enfin, dans le cas où l’utilisateur aurait installé une application provenant d’une autre source que les marchés dédiés ou dans le cas où plusieurs applications distinctes s’associeraient en vue de l’exécution d’une manoeuvre malveillante, les méthodes pré- ventives s’avèrent démunies, d’où la nécessité de les compléter par des méthodes réactives qui assurent la protection des équipements intelligents pendant leur exécution.
Dans ce contexte, le déploiement de fonctions de sécurité telles que des pare-feux ou des antivirus, peut s’opérer directement sur lesdits équipements. Cette proposition découle de la supposition partiellement étayée dans les faits que les équipements intelligents sont des formes d’ordinateurs portatifs offrant les mêmes services que leurs homologues fixes. Il semble naturel de protéger ces deux types d’équipements de la même manière. Il est ainsi possible de télécharger la version mobile de nombreux services de sécurité, tels que les antivirus connus du marché, pour assurer la protection de son smartphone ou de sa tablette. Néanmoins, cette approche souffre de limitations propres de ces environnements. En effet, l’usage de méthodes traditionnelles est rendue difficile par les fortes contraintes en termes de batterie et de CPU de ces équipements.
Le déploiement d’antivirus ou de pare-feux dédiés sur les smartphones et les tablettes risque premièrement de fortement dégrader l’expérience des utilisateurs, en limitant drastiquement le temps d’utilisation qu’ils pourront en attendre, ou en introduisant de fortes latences dans l’exé- cution des traitements attendus. En outre, le déploiement de fonctions de sécurité directement sur les équipements intelligents pose aussi la difficulté liée au fait qu’elle requiert le téléchar- gement de services auquel l’utilisateur doit se fier au risque qu’il s’agisse en fait d’applications malveillantes, comme décrit ci-dessus.
1.1.2 Chaînes de fonctions de sécurité
Les travaux relatifs au concept de chaînes de fonctions de sécurité s’inscrivent dans le cadre
plus large de la recherche sur la programmabilité et la virtualisation de fonctions réseau [26].
1.2. Défis et problématique Ces méthodes visent à proposer différentes fonctions réseau assurant des tâches de sécurité ou de gestion comme des services logiciels indépendamment de leur implantation physique.
Cette approche vise à déléguer l’allocation de fonctions réseau à des orchestrateurs logiciels afin de rendre ces aspects de configuration transparents pour les utilisateurs du réseau. De telles fonctions réseau virtualisées sont couramment appelées VNF pour Virtualized Network Functions. Les middleboxes sont un équivalent hardware des VNFs, il s’agit d’équipements réseau qu’un opérateur peut composer pour assurer certains services, notamment en sécurité.
C’est dans ce contexte qu’a été proposée l’utilisation de chaînes de sécurité pour la protection des environnements intelligents [56, 57, 76]. Ces chaînes sont des compositions dynamiques de fonctions de sécurité, telles que des pare-feux, des systèmes de détection d’intrusion (IDS), ou des services de prévention de fuite de données [62, 77, 103]. Ces fonctions de sécurité sont virtualisées et exposées comme des middleboxes [38, 9] au sein d’un réseau. La construction de chaînes de fonctions de sécurité peut ainsi être vue comme un service assuré par les fournisseurs de réseau à leurs abonnés. Les fonctions de sécurité peuvent ainsi être composées dynamiquement afin de constituer une ou plusieurs chaînes de fonctions de sécurité pouvant être utilisées pour la pro- tection de systèmes critiques. Ces chaînes de fonctions de sécurité peuvent être dynamiquement construites à la demande des utilisateurs et être proposées comme un service cloud.
Plus précisément, les tâches de construction, d’optimisation et de déploiement de chaînes de fonctions de sécurité peuvent être centralisées et automatisées par un orchestrateur dédié.
Cet orchestrateur sera alors contacté par tous les utilisateurs nécessitant une chaîne de fonction de sécurité pour assurer leur protection. En fonction de l’état du réseau, l’orchestrateur pourra alors soit construire une nouvelle chaîne répondant aux besoins du nouvel utilisateur, soit mettre à jour une chaîne existante soit rediriger l’utilisateur vers une de ces chaînes. Pour assurer un tel service, un orchestrateur de chaînes de fonctions de sécurité doit être en mesure d’identifier les besoins particuliers d’un utilisateur, de construire la chaîne correspondante et d’en optimiser le placement avant de la déployer effectivement dans le réseau.
Toutefois, le principal inconvénient des chaînes de fonctions de sécurité réside dans leur grande complexité structurelle ainsi que dans leur dynamique qui risquent d’introduire des er- reurs de configuration dans le réseau, par exemple des règles associant des actions contradictoire pour le même traffic. En effet, les différentes fonctions de sécurité utilisées dans le déploiement de chaînes de sécurité présentent des interfaces souvent fort différentes et l’harmonisation de leurs configurations n’est pas un problème trivial. Pour répondre à cela, plusieurs approches ont été proposées dont le recours à des méthodes formelles pour permettre la validation des chaînes avant leur déploiement : ces méthodes permettent en effet la validation de systèmes critiques en travaillant sur une représentation abstraite de leur comportement. Le principal inconvénient de ces méthodes réside dans leur complexité algorithmique qui requiert un travail attentif afin de permettre leur application dans un contexte d’orchestration.
1.2 Défis et problématique
L’utilisation des technologies associées aux chaînes de fonctions de sécurité soulève des pro-
blèmes multiples. La virtualisation a été proposée comme une alternative à l’utilisation des
middleboxes, difficiles à gérer et souvent propriétaires. Toutefois, l’utilisation d’un composant
logiciel en lieu et place d’un équipement matériel propre n’est pas sans introduire de nouveaux
défis. Nous présentons ici les défis propres à l’orchestration de fonctions de sécurité dans le ré-
seau. Nous décrivons ensuite notre approche pour la composition, la validation et l’optimisation
automatiques de chaînes de telles fonctions en environnement Software Defined Network (SDN).
1.2.1 Défis liés à l’orchestration de chaînes de fonctions de sécurité
Un premier défi porte sur l’administration des fonctions virtualisées dans le contexte d’une architecture opérateur. En effet, les fournisseurs de réseau sont intéressés par la possibilité d’op- timiser leur service à moindre coût de déploiement. Il est cependant à craindre que l’introduction des solutions de virtualisation, plus flexibles, introduisent aussi une plus grande complexité dans la gestion du réseau. Un intérêt grandissant autour des technologies clouds est celui de réseau en tant que service : l’idée est de pouvoir fournir des services à la demande aux utilisateurs.
Dans un tel contexte, on peut légitimement se poser la question de la faisabilité d’une telle approche, fournir un service à la demande de chaque utilisateur pouvant sembler difficilement envisageable d’un point de vue logistique. S’il n’est effectivement pas possible de satisfaire in- dividuellement toutes les demandes, alors peut-être serait-il possible de les factoriser afin de les traiter collectivement.
Un second défi touche à la résilience des technologies de virtualisation : en effet, comme nous l’avons vu plus haut le déploiement de multiples fonctions de sécurité configurées en lien les unes avec les autres risque d’introduire des erreurs dans le réseau. Les approches basées sur des tests unitaires ne sont pas suffisantes pour permettre la validation de systèmes complexes tels que les chaînes de fonctions virtualisées. En effet, leur structure essentiellement dynamique les rend difficile à valider par l’exécution d’une série de tests statiques, les erreurs n’ayant pas lieu à chaque exécution. Il est en outre complexe de valider l’absence de contradictions des règles d’une chaîne par application de tests unitaires, le résultat des tests pouvant correspondre au comportement attendu, alors que le programme de la chaîne comporte bel et bien une incohé- rence. Peut-être les méthodes formelles peuvent permettre de contourner ces difficultés, si tel est le cas alors il reste encore la problématique de leurs performances. En effet, garantir et optimiser une validation en temps réel, c’est-à-dire sans interrompre l’exécution du réseau, des chaînes de fonctions de sécurité sur la base de méthodes de vérification formelle est un enjeu important. La composition et le déploiement des chaînes de sécurité doivent être assurés à chaque fois qu’un équipement le demande. Il est donc nécessaire d’intégrer les méthodes de vérification formelle dans un cycle d’exploitation en temps réel, afin de assurer les besoins en termes de validation.
Un dernier défi important concerne les performances des technologies de virtualisation elles- mêmes. En effet, l’introduction de composants logiciels dans le réseau en lieu des composants matériels risque d’être à l’origine d’une plus grande complexité de gestion. Cette problématique influe directement sur les performances liées au déploiement de fonctions virtualisées : en effet, l’efficacité des réseaux dépend grandement de leur capacité à fournir de très hautes qualités de service en termes de bande passante et de temps de réponse. Dans ce contexte, on peut légitimement se poser la question de l’impact des technologies de virtualisation, non plus sur le déploiement, mais sur l’utilisateur final, l’utilisation de composants logiciels risque en effet d’apporter des délais dégradant la qualité du service, voire même d’introduire des failles de sécurité supplémentaires.
1.2.2 Problématique relative à cette thèse
Notre travail dans le cadre de cette thèse se focalise sur l’application et l’exploitation des
méthodes formelles telles que le model checking, le SMT solving ou la programmation logique
pour une orchestration plus sûre des fonctions de sécurité en environnement SDN. En particulier,
les chaînes de sécurité ainsi construites peuvent être utilisées en vue d’assurer la protection
d’équipements intelligents. Cet objectif peut être structuré autour de trois axes principaux :
la conception d’un orchestrateur dédié à la construction des chaînes de fonctions de sécurité,
1.3. Plan de la thèse l’intégration de méthodes de vérification automatique dans cette architecture, pour permettre la validation des chaînes en temps réel, et enfin les méthodes qui peuvent être employées en vue d’optimiser le déploiement des chaînes de fonctions de sécurité dans le réseau.
Le premier axe porte sur la conception architecturale d’un orchestrateur en charge de la gestion des chaînes. Le but que nous avons assigné pour notre orchestrateur est de permettre le déploiement dynamique de chaînes de fonctions de sécurité pour protéger des smartphones et tablettes dont les ressources sont relativement restreintes. Dans ce contexte, notre orchestrateur se doit d’assurer des performances satisfaisantes en termes de sécurité et de temps de réponse, un souci tout particulier doit être attaché à cet aspect dans la conception de son architecture. Le déploiement de notre orchestrateur au sein du réseau, ainsi que ses interactions avec les diverses entités le constituant seront également discutées ultérieurement dans ce mémoire.
Le second axe est celui de l’intégration de méthodes formelles comme un support à notre orchestrateur. Comme nous l’avons déjà brièvement évoqué, les méthodes formelles offrent de grandes opportunités en vue de la validation de systèmes complexes, tels que les chaînes de fonctions de sécurité, mais peuvent également être d’une très forte complexité algorithmique, qui en restreint souvent l’application en temps réel. La caractérisation des chaînes de fonctions de sécurité et des diverses propriétés devant être validées au travers des méthodes formelles seront abordées ultérieurement dans ce mémoire. Nous nous intéresserons notamment à l’identification des méthodes offrant les meilleures performances en vue d’assurer la validation des chaînes de sécurité en temps réel.
Enfin, le dernier axe de notre travail tient aux possibilités en termes d’optimisation des chaînes avant leur déploiement. La capacité des réseaux n’étant pas illimitée, il est en effet es- sentiel d’assurer que le déploiement des chaînes de sécurité n’induit pas de surcoûts excessifs au niveau des opérations devant être réalisées. Deux aspects principaux seront examinés, premiè- rement la minimisation du nombre de fonctions de sécurité à déployer, avec éventuellement leur factorisation au sein d’un ensemble de chaînes. Le second aspect traitera de l’optimisation de leur placement en fonction de différents paramètres contextuels induits par le réseau.
1.3 Plan de la thèse
La présente thèse s’organise en fonction des axes de recherche décrits dans la section pré- cédente. L’axe relatif à la conception d’un orchestrateur en charge de la gestion des chaînes de fonctions de sécurité est abordé dans le chapitre 3 qui traite en particulier de l’apprentissage du comportement des applications en vue de construire les chaînes correspondantes. L’axe relatif à l’exploitation de méthodes formelles pour la validation à l’exécution desdites chaînes de fonc- tions de sécurité est traité dans les chapitres 4 et 5. Finalement, l’axe relatif à l’optimisation du déploiement des chaînes de fonctions de sécurité est abordé dans le chapitre 6.
Le chapitre 2 fait tout d’abord un état de l’art des travaux liés à la présente thèse. En particulier, il décrit les travaux concernant la sécurité des réseaux, et plus particulièrement celle des équipements intelligents. Il présente ensuite les travaux relatifs aux technologies de réseaux programmables (SDN), et à celles de virtualisation et de middleboxes. Le chapitre décrit également les travaux existants en matière de méthodes formelles, et plus spécifiquement à leur application à la validation de chaînes de fonctions de sécurité. Nous abordons également les différents travaux traitant de l’apprentissage automatique de processus et de protocoles réseau, ainsi que des méthodes permettant la résolution de problèmes d’optimisation.
Le chapitre 3 présente l’architecture générale de notre orchestrateur et son intégration au
sein d’un réseau SDN. Il détaille les différents modules impliqués dans la génération et la gestion
des chaînes, et offre ainsi un fil conducteur qui sera utile au lecteur pour comprendre la logique des chapitres suivants, placés dans l’ordre des traitements de notre orchestrateur. Ce chapitre décrit en particulier l’apprentissage du comportement réseau d’applications Android. En par- ticulier, il présente le type d’automates markoviens que nous avons retenu pour représenter le comportement des applications, ainsi que les informations à partir desquelles ces modèles sont construits. Le chapitre se termine par le comparatif de notre approche avec d’autres méthodes analogues et présente les avantages induits par notre processus d’apprentissage dans le contexte d’application Android décrites par des flux réseau.
Le chapitre 4 détaille notre approche de synthèse formelle de chaînes de fonctions de sécu- rité. Elle s’appuie sur les automates markoviens décrits au chapitre 3, à partir desquels nous construisons une spécification logique des besoins de sécurité. Cette spécification est ensuite uti- lisée par un système d’inférence basé sur des clauses de Horn pour générer la chaîne de fonctions de sécurité dédiée à une application Android. Nous faisons la preuve de plusieurs propriétés ainsi garanties par lesdites chaînes. Le chapitre 4 présente également comment de telles chaînes peuvent être factorisées afin de en minimiser le coût de déploiement. Finalement, il se termine en décrivant les résultats expérimentaux que nous avons obtenus en générant les chaînes associées à un ensemble d’applications données, et en comparant différentes méthodes de factorisation.
Le chapitre 5 aborde notre approche de vérification automatique de chaînes, couvrant à la fois la vérification du plan de contrôle et du plan de données. Il présente les composants que nous proposons pour assurer une telle vérification, reposant notamment sur des méthodes de traduction automatique pour convertir la spécification haut niveau des chaînes de fonctions de sécurité, en modèles formels pouvant être vérifiés automatiquement par des solvers dédiés. Ce chapitre présente les différents types de modélisation que nous avons appréhendés, notamment les représentations basées sur des méthodes de model checking et de SMT solving, et compare les performances apportées par ces différentes méthodes pour la vérification automatique de chaînes de sécurité.
Le chapitre 6 indique ensuite le résultat de nos travaux touchant au placement de chaînes de fonctions de sécurité dans un contexte SDN. Ce chapitre commence par motiver le problème en détaillant la difficulté du placement des chaînes dans un réseau présentant certaines contraintes, puis introduit deux abstractions permettant la simplification du modèle. Il se poursuit en dé- taillant les divers éléments relatifs au modèle de placement, notamment ses paramètres et ses variables, ses contraintes et ses objectifs. Le chapitre inclut le comparatif des performances assurées par différents outils dédiés à l’optimisation formelle. Nous discutons finalement les ré- sultats observés après avoir simulé le déploiement de nos chaînes de fonctions de sécurité avec le simulateur de réseau SDN MiniNet.
Enfin, le chapitre 7 est dédié aux conclusions de notre travail dans le cadre de cette thèse.
Il commence par résumer les contributions, puis apporte une réponse aux questionnements liées à la problématique. Le chapitre se termine sur la présentation de différentes perspectives de recherche. En particulier, il pourrait être d’un vif intérêt d’étendre la spécification des règles que nous utilisons pour configurer les chaînes de fonctions de sécurité, ainsi que les méthodes de détection auxquelles nous avons eues recours.
La figure 1.1 présente les relations entre les différents chapitres de contributions décrits dans
ce mémoire (hors chapitre 2 consacré à l’état de l’art). Le chapitre 3 constitue le point de
départ de notre approche d’orchestration. Il est ensuite possible d’aborder le chapitre 4 dans
le cas d’une approche où les chaînes sont générées automatiquement à partir des automates
markoviens décrivant le comportement des applications, puis factorisées pour minimiser l’impact
de leur déploiement sur le réseau. Il est également possible d’aborder le chapitre 5 dans lequel
une chaîne peut être spécifiée manuellement par un opérateur réseau sans recours à des méthodes
1.3. Plan de la thèse de synthèse. Le chapitre 6 clôt notre démarche d’orchestration en apportant les éléments relatifs au placement des règles d’une chaîne avant son déploiement ainsi que l’évaluation du surcoût ainsi induit.
Chapitre 3 : Orchestration
Chapitre 4 : Synthèse Chapitre 5 : Vérification
Chapitre 6 : Placement
générer les chaînes vérifier (spécification opérateur)
vérifier (chaînes générées) optimiser les chaînes
Figure 1.1 – Diagramme des relations entre les chapitres de contributions de la thèse
2
Etat de l’art
De nombreux travaux ont d’or et déjà été menés dans les différents domaines que nous ex- plorons dans le cadre de ce mémoire. Ce chapitre présente les travaux relatifs au contexte de notre étude, en particulier les travaux portant sur la sécurité des réseaux, et plus particulière- ment celle des environnements intelligents, les travaux relatifs aux solutions s’appuyant sur la programmabilité et virtualisation réseau, et enfin les travaux relatifs aux différentes méthodes formelles que nous avons utilisées au cours de la thèse.
2.1 Sécurité des équipements intelligents
Comme indiqué en introduction le but de notre travail est d’assurer la protection d’équi- pements intelligents, tels que des smartphones ou des tablettes, en particulier les équipements gérés par le système d’exploitation Android. Nous présentons ici les travaux relatifs aux menaces ciblant ces équipements, ainsi que ceux relatifs aux solutions qui ont été proposées pour y remé- dier. Notre étude s’articule en plusieurs volets suivant la classification définie dans [99], à savoir d’abord la sécurité au niveau du réseau, ensuite les travaux relatifs aux permissions du système Android, et finalement les techniques de profilage des applications en vue de leur sécurisation.
2.1.1 Menaces réseau contre les équipements intelligents
Notre travail se concentre plus particulièrement sur la protection des équipements intelligents au niveau du réseau. Dans [67] sont présentées plusieurs des difficultés liées au domaine, en particulier les hautes contraintes en termes de batterie et de processeur. Des problématiques plus étroitement liées à la protection d’équipements Android sont présentées dans [39], en particulier les problèmes liés à l’explosion d’applications malveillantes sur les marchés dédiés. Ces travaux ne proposent toutefois pas eux-mêmes de solutions, ils se limitent à faire un récapitulatif des travaux existants concernant les menaces visant ces environnements.
Les équipements intelligents sont la cible de plusieurs types d’attaques telles que par exemple
des dénis de service, des scans de ports, des worms ou encore des botnets, comme indiqué
dans [67]. Une attaque par déni de service (DoS, Denial of Service) est caractérisée par une ou
un ensemble de machine(s) ciblant une victime pour l’empêcher d’assurer un service [52]. Dans
notre contexte, nous considérons des attaques par DoS que l’on peut observer d’un point de vue
réseau, c’est-à-dire produisant des modifications anormales du traffic en partance ou à desti-
nation d’un certain équipement. Un exemple d’une telle attaque est l’attaque SYN flood, dans
laquelle un grand nombre de paquets SYN sont envoyés à un hôte, afin de déborder la pile TCP
avec des centaines de connexions qui ne seront jamais refermées. Dans une attaque par scan de ports (ou port scanning), une application initie un grand nombre de connexions avec les ports d’une ou de plusieurs machine(s) afin de détecter les ports ouverts. Nous considérons des scans de ports comparables à ceux générés par le scanner de ports nmap disponible sur les plateformes linux standards. Un ver (ou worm) est un programme qui peut s’exécuter indépendamment tout en consommant les ressources de son hôte afin de se maintenir, et peut répliquer une version complètement exécutable de lui-même vers d’autres machines [71]. Les worms se répliquent en exploitant les vulnérabilités d’applications et systèmes d’exploitation, ou par des méthodes d’in- génierie sociale. Dans cette thèse nous considérons des worms qui scannent un certain port sur de nombreuses machines, afin de exploiter une certaine vulnérabilité sur des systèmes d’exploi- tation. Un bot (potentiellement) malveillant est un programme installé sur un système afin de l’utiliser automatiquement ou semi-automatiquement en vue d’exécuter des tâches, potentielle- ment sous le contrôle d’un administrateur distant, appelé bot master [14]. La détection de tels botnets est un domaine de recherche à part entière du fait de leurs architectures complexes et de la diversité de leurs implémentations. Il existe en particulier des botnets communiquant sur la base de requêtes http difficilement identifiables d’un point de vue réseau ou encore des botnets exploitant une architecture pair à pair dans laquelle les bots se relayent les messages du bot master de proche en proche. Dans le cadre de notre travail nous nous limiterons au cas de bots pouvant être détectés sur la base du fort volume de trafic qu’ils échangent avec leur contrôleur ou potentiellement par l’utilisation de protocoles réseau inhabituels dans un certain contexte.
Ces différentes attaques peuvent être détectées au niveau des paquets réseaux qu’elles gé- nèrent ou bien au niveau des flux comme indiqué dans [98]. D’après le RFC 5101 [27], les flux réseau peuvent être définis comme “des collections de paquets IP passant par un certain point d’observation dans le réseau pendant un certain intervalle de temps”. Ils sont générale- ment décrits par différentes propriétés telles que les adresses IP source et destination (srcaddr et dstaddr ), les ports source et destination (srcport et dstport), leur protocole réseau (protocol), et leur nombres de paquets et d’octets (packets et bytes). Dans notre contexte ils sont collec- tés directement sur les équipements [68], et sont étendus avec un timestamp (timestamp) et le nom de l’application qui les a produits (appname). La limitation de ces travaux relatifs aux flux réseau est qu’ils ne prennent pas en compte la modélisation des données transmises lors d’une communication et qu’ils doivent donc être complétés par des travaux appréhendant ces problématiques, par exemple via le système de permissions Android. Comme indiqué dans [98]
la recherche sur les flux réseaux requiert la constitution de volumineux datasets contenant de nombreuses traces décrivant le comportement malveillant ou non d’hôtes et d’applications. De semblables datasets ont été proposés par des chercheurs du domaine public, par exemple le CTU13 présenté dans [49] qui contient de nombreuses traces de botnets générées au sein d’un réseau universitaire. Néanmoins la constitution de nouveaux datasets contenant des traces de DoS, de scans de ports ou encore de worms reste un enjeu pour la recherche en ces domaines.
Enfin il est également nécessaire de présenter les attaques par fuite de données qui constituent
une autre menace sérieuse contre les équipements intelligents. Ces attaques visent à violer la
confidentialité de certaines données privées d’un utilisateur en les transmettant sans son accord
à un tiers malfaisant. Dans [83], les auteurs proposent une approche permettant la détection
de fuites des données privées d’un utilisateur via l’observation des flux réseau générés par une
application. Toutefois, dans les contextes où la majeure partie du trafic émis peut être chiffrée
avec l’usage du protocole HTTPS, il devient difficile d’utiliser de telles méthodologies. Il convient
donc d’avoir recours à d’autres moyens pour identifier de potentielles fuites de données.
2.1. Sécurité des équipements intelligents
2.1.2 Système de permissions des environnements Android
L’utilisation du système d’exploitation Android est régi par de nombreuses applications qu’un utilisateur peut installer via le Google Play Store, ou bien directement via leurs exécutables.
Les droits accordés à ces applications sur les diverses ressources de l’équipement, telles que par exemple la connexion à Internet ou l’utilisation de l’appareil photo sont régis par un système de permissions dédiées. Les permissions requises par une application sont spécifiées dans un fichier de manifest incorporé à l’archive contenant l’exécutable. Cette archive peut également contenir d’autres fichiers de méta-données tels que des images utilisées par l’application. Comme indiqué dans [99], la protection d’applications Android demande l’examen des permissions demandées. Le système d’exploitation Android repose en effet sur un système de permissions qui permettent de restreindre l’accès à certaines ressources critiques en termes de sécurité tel que par exemple l’appareil photo ou la liste des contacts d’un utilisateur. Bien que détaillé par diverses documentations techniques [1], le système de permissions d’Android reste source de nombreuses erreurs du fait de son peu de lisibilité. Plusieurs travaux ont été proposés pour permettre une meilleure lisibilité des permissions régissant l’activité des applications Android.
Dans [10], les auteurs proposent une approche faisant l’association entre les permissions déclarées par le système de sécurité d’Android et les méthodes déclarées dans l’API
1correspondante. Cette approche permet la surveillance du comportement d’applications et en particulier la détection d’accès frauduleux aux données d’un utilisateur, toutefois il reste à déplorer que cette approche ne prenne pas en compte la protection au niveau réseau. En effet l’obtention de la permission internet par une application Android lui ouvre un plein accès à cette ressource et ne permet pas en soi d’identifier de potentiels comportements malveillants.
L’une des principales règles conditionnant le développement d’applications sûres est le res- pect du principe de moindre privilège : dans [81], les auteurs proposent une approche visant à identifier des applications sur-privilégiées. Cette approche propose de faire l’association entre les permissions déclarées par une application et les appels de méthode effectivement identifiés dans le binaire de ladite application. Ce travail a été évalué de manière préventive sur un large ensemble d’applications disponibles sur le Google play store. La conclusion des auteurs est que malgré les efforts mis en oeuvre environ un tiers des applications actuellement déployées au ni- veau des marchés bénéficient de trop grands privilèges. Toutefois ils ne proposent pas de solution remédiant à ce problème ou permettant aux utilisateurs ayant installé lesdites applications de se prémunir d’éventuels comportements malveillants. Plusieurs travaux couvrent également l’ana- lyse du comportement d’applications Android en vue de détecter des comportements malveillants liés à la demande de certaines permissions. Dans [7], les auteurs proposent une approche visant à détecter la collusion d’applications en vue d’accomplir des actions malveillantes qui n’auraient pas été possibles si les permissions qu’elles déclarent n’avaient été déclarées que par l’une d’entre elles, par exemple extruder des données privées du carnet d’adresse et les transmettre à un ser- veur distant via une autre application. On peut néanmoins déplorer le fait que ce travail ne couvre pas tous les aspects de communications Android, par exemple la communication via des content sets dédiés. De même, les travaux présentés dans [51] tendent à permettre l’identification d’applications malveillantes dont le comportement dévie de celui attendu au vue des permissions et du comportement qu’elles déclarent. Cette approche se base sur le descriptif des applications fournis par le développeur, ainsi que sur le comportement réellement observé lors de l’exécution de ladite application en environnement protégé. Appliqué sur un ensemble de 22500 applications Android, le prototype détaillé dans cette approche identifia 56% de nouveaux virus sans disposer d’aucun modèle préalable en vue de cette détection.
1. Application Programming Interface
