Cybervigilance et confiance numérique: La cybersécurité à l'ère du Cloud et des objets connectés 9781784056087, 9781784066086, 1784056081

Table of contents :
Cover
Table des matières
Introduction
Chapitre 1. La Cyber Threat Intelligenceet son évolution
Chapitre 2. Systèmes de gestion de la confiance :une étude rétrospectivesur la confiance numérique
Chapitre 3. Risques d’attaques réseaux
Chapitre 4. Aperçu analytique du flux d’informationset protection des données privéesdans les systèmes Android
Liste des auteurs
Index

Citation preview

Tounsi.qxp_Mise en page 1 25/07/2019 12:21 Page 1

Cybervigilance et confiance numérique présente les avancées récentes en matière de renseignement sur la cybermenace, de gestion de la confiance et d’analyse des risques. Il décrit les approches, en matière de renseignement et de cybervigilance, qui permettent de réduire l’écart technique et tactique entre les méthodes d’attaques avancées et celles de défense. En plus de la gestion de confiance, cet ouvrage propose une synthèse comparative des différentes méthodes d’analyse de risque dans les réseaux et illustre leur intérêt sur un cas d’usage concret. Enfin, il offre une solution fondée sur un mécanisme d’altération des données qui permet de détecter et de bloquer les fuites de données sensibles des utilisateurs des systèmes Android.

La coordonnatrice Docteure de l’IMT Atlantique (ex-Télécom Bretagne), Wiem Tounsi est consultante experte en cybersécurité chez Orange Cyberdefense. Ses travaux actuels portent sur la gouvernance, le risque et la conformité.

e d i t i on s editions

Z(7ib7i4-AFGAIH(

Cybervigilance et confiance numérique la cybersécurité à l’ère du Cloud et des objets connectés

Cybervigilance et confiance numérique

Les cybermenaces sont désormais nombreuses et sophistiquées et les cybercriminels infiltrent des organisations de secteurs de plus en plus variés. Les entreprises n’ont d’autre choix que de se doter d’outils et de mécanismes de sécurité efficaces, afin de devancer les cybercriminels et de se prémunir contre les attaques.

sous la direction de Wiem Tounsi

COLLECTION RÉSEAUX ET TÉLÉCOMMUNICATIONS

e d i t i on s editions

sous la direction de

Wiem Tounsi

e d i t i on s editions

Cybervigilance et confiance numérique

First published 2019 in Great Britain by ISTE Editions Ltd.

Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers, or in the case of reprographic reproduction in accordance with the terms and licenses issued by the CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the undermentioned address: ISTE Editions Ltd 27-37 St George’s Road London SW19 4EU UK

© ISTE Editions Ltd 2019 The rights of the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.

British Library Cataloguing-in-Publication Data A CIP record for this book is available from the British Library ISBN: 978-1-78405-608-7 (print) ISBN: 978-1-78406-608-6 (e-book)

Printed and bound in Great Britain by CPI Group (UK) Ltd., Croydon, Surrey CR0 4YY, September 2019

Cybervigilance et confiance numérique la cybersécurité à l’ère du Cloud et des objets connectés

sous la direction de

Wiem Tounsi

editions

Collection dirigée par Guy Pujolle

Table des matières

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wiem TOUNSI

1

Chapitre 1. La Cyber Threat Intelligence et son évolution . . . . . . Wiem TOUNSI

3

1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Contexte général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Menaces de nouvelle génération . . . . . . . . . . . . . . . . . . . 1.2.1.1. Menaces persistantes avancées (Advanced Persistant Threats, APT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1.2. Menaces polymorphes . . . . . . . . . . . . . . . . . . . . . . 1.2.1.3. Menaces zero-day . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1.4. Menaces composites . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. Structures et modèles analytiques . . . . . . . . . . . . . . . . . . 1.2.2.1. Étapes de la perspective défensive de la kill chain . . . . . 1.2.2.2. Le modèle Diamond de l’analyse d’intrusion . . . . . . . . 1.3. Cyber Threat Intelligence (CTI) . . . . . . . . . . . . . . . . . . . . . . 1.3.1. Sources de la Cyber Threat Intelligence . . . . . . . . . . . . . . 1.3.2. Sous-domaines de la Cyber Threat Intelligence . . . . . . . . . . 1.3.3. Renseignement technique sur les menaces (Technical Threat Intelligence, TTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Problèmes de partage des renseignements sur les menaces . . . . . . . 1.5.1. Avantages du partage des renseignements sur les menaces pour l’apprentissage collectif . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2. Raisons de ne pas partager les renseignements sur les menaces .

. . .

3 5 6

. . . . . . . . . .

6 6 7 7 8 8 10 11 11 13

. . .

15 16 18

. .

18 19

vi

Cybervigilance et confiance numérique

1.6. Limites du renseignement technique sur les menaces . . . . . . . . . . 1.6.1. La quantité avant la qualité . . . . . . . . . . . . . . . . . . . . . . 1.6.2. Limites propres aux indicateurs de compromission (IOC) . . . . 1.6.2.1. Indicateurs liés au réseau . . . . . . . . . . . . . . . . . . . . 1.6.2.2. Indicateurs basés sur l’hôte : indicateurs sur les malwares 1.6.2.3. Indicateurs liés aux courriers électroniques . . . . . . . . . 1.7. Bibliothèques ou plateformes de Cyber Threat Intelligence . . . . . . 1.7.1. Avantages des bibliothèques de Cyber Threat Intelligence basées sur le Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.2. Réticence à utiliser les services du Cloud . . . . . . . . . . . . . . 1.8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1. L’insuffisance de partager rapidement. . . . . . . . . . . . . . . . 1.8.2. Réduire la quantité de flux d’indicateurs de compromission. . . 1.8.3. Confiance dans le partage des indicateurs de compromission . . 1.8.4. Normes pour la représentation et le partage de la Cyber Threat Intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.5. Bibliothèques de Cyber Threat Intelligence basées sur le Cloud pour la connaissance collective et l’immunité . . . . . . . . . . . . . . . 1.8.5.1. Utilisation de solutions de Cloud privé/communautaire . . 1.8.5.2. Être conscient des principales préoccupations en matière de sécurité sur le Cloud . . . . . . . . . . . . . . . . . . . 1.9. Évaluation des outils de renseignement technique sur les menaces . . 1.9.1. Présentation des outils sélectionnés . . . . . . . . . . . . . . . . . 1.9.2. Discussion comparative . . . . . . . . . . . . . . . . . . . . . . . . 1.10. Conclusion et travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . 1.11. Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

23 23 24 24 26 27 27

. . . . . .

28 29 29 29 30 32

.

34

. .

36 36

. . . . . .

37 38 39 40 42 44

Chapitre 2. Systèmes de gestion de la confiance : une étude rétrospective sur la confiance numérique . . . . . . . . . Reda YAICH 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2.2. Définition de la confiance . . . . . . . . . . . . . 2.3. Genèse des systèmes de gestion de la confiance 2.3.1. Modèle de contrôle d’accès . . . . . . . . . 2.3.2. Contrôle d’accès basé sur l’identité . . . . 2.3.3. Contrôle d’accès basé sur le réseau . . . . 2.3.4. Contrôle d’accès basé sur les rôles . . . . . 2.3.5. Contrôle d’accès basé sur l’organisation . 2.3.6. Contrôle d’accès basé sur les attributs . . . 2.4. Gestion de la confiance . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

53 . . . . . . . . . .

53 54 56 56 57 59 60 61 62 64

Table des matières

2.4.1. Définition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2. Système de gestion de la confiance . . . . . . . . . . . . . . . . 2.4.3. Fondations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3.1. Identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3.2. Politiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3.3. Moteur de confiance . . . . . . . . . . . . . . . . . . . . . . 2.4.4. Négociation automatisée de la confiance . . . . . . . . . . . . . 2.5. Classification des systèmes de gestion de la confiance . . . . . . . . 2.5.1. Systèmes de gestion de la confiance basés sur l’autorisation . 2.5.2. Systèmes de gestion de la confiance basés sur les rôles . . . . 2.5.3. Systèmes automatisés de négociation de la confiance . . . . . 2.6. Gestion de la confiance dans les infrastructures de Cloud Computing . 2.6.1. Modèles de confiance basés sur les identifiants . . . . . . . . . 2.6.2. Modèles de confiance basés sur les Service Level Agreements (SLA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3. Modèles de confiance basés sur la rétroaction . . . . . . . . . . 2.6.4. Modèles de confiance basés sur la prévision . . . . . . . . . . . 2.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8. Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

. . . . . . . . . . . . .

. . . . . . . . . . . . .

64 65 66 66 68 70 72 73 74 79 82 90 91

. . . . .

. . . . .

91 92 93 93 94

Chapitre 3. Risques d’attaques réseaux . . . . . . . . . . . . . . . . . . Kamel KAROUI 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Théorie du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Définition des termes du risque . . . . . . . . . . . . . . . . . . . . 3.2.2. Présentation des principales méthodes du risque . . . . . . . . . 3.2.2.1. EBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.2. Méhari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.3. Octave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3. Comparatif des principales méthodes . . . . . . . . . . . . . . . . 3.3. Analyse du risque des systèmes d’information (SI) dans le contexte des réseaux informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Établissement du contexte . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.1. Ressources à protéger . . . . . . . . . . . . . . . . . . . . . . 3.3.1.2. Modèle du risque . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1.3. Classification du risque . . . . . . . . . . . . . . . . . . . . . 3.3.2. Appréciation des risques . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2.1. Méthode de l’alternance de bits pour l’agrégation des valeurs de criticité . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2.2. Appréciation de l’impact . . . . . . . . . . . . . . . . . . . . 3.3.2.3. Appréciation de la probabilité d’occurrence . . . . . . . . . 3.3.2.4. Appréciation globale des risques. . . . . . . . . . . . . . . .

105 . . . . . . . .

105 107 107 109 110 112 114 115

. . . . . .

119 119 119 121 123 125

. . . .

126 127 129 130

viii

Cybervigilance et confiance numérique

3.3.3. Traitement du risque . . . . . . . . . . . . . . . 3.3.3.1. Amélioration des paramètres du risque . 3.3.4. Acceptation du risque . . . . . . . . . . . . . . 3.3.5. Communication du risque . . . . . . . . . . . . 3.3.6. Surveillance du risque . . . . . . . . . . . . . . 3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Bibliographie . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Chapitre 4. Aperçu analytique du flux d’informations et protection des données privées dans les systèmes Android . . Mariem GRAA 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Flux d’informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Flux explicites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Flux implicites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3. Canaux cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Data tainting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Approche de l’interprète . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Approche basée sur l’architecture . . . . . . . . . . . . . . . . 4.3.3. Analyse statique des données taguées . . . . . . . . . . . . . . 4.3.4. Analyse dynamique des données taguées . . . . . . . . . . . . 4.4. Protection des données privées dans les systèmes Android . . . . . 4.4.1. Approche du contrôle d’accès. . . . . . . . . . . . . . . . . . . 4.4.1.1. Approche politique basée sur des règles . . . . . . . . . 4.4.1.2. Approche de prévention de l’élévation des privilèges . 4.4.2. Prévention des fuites de données privées . . . . . . . . . . . . 4.4.2.1. Falsification des informations sensibles . . . . . . . . . 4.4.2.2. Analyse statique des applications Android . . . . . . . . 4.4.2.3. Analyse dynamique des applications Android . . . . . . 4.4.3. Approches des bibliothèques natives . . . . . . . . . . . . . . 4.5. Détection des flux de contrôle . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Approches techniques du flux de contrôle . . . . . . . . . . . 4.5.2. Approches formelles du flux de contrôle . . . . . . . . . . . . 4.6. Gestion des flux explicites et de contrôle en code Java et en code natif des applications Android . . . . . . . . . . . . . . . . . . 4.6.1. Spécification formelle du problème d’under-tainting . . . . . 4.6.1.1. Définition syntaxique des connecteurs {⇒, →, ←, ⊕} 4.6.1.2. Définition sémantique des connecteurs {→, ←, ⊕} . . 4.6.2. Solution formelle du problème d’under-tainting. . . . . . . . 4.6.2.1. Notations, définitions et théorèmes . . . . . . . . . . . .

132 132 134 135 136 136 137

139

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

140 141 141 141 142 143 143 144 144 145 147 147 148 149 151 151 152 153 155 157 158 159

. . . . . .

. . . . . .

. . . . . .

161 161 162 162 163 163

Table des matières

4.6.2.2. Preuve des règles de propagation des tags . . . . . . . . 4.6.2.3. L’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2.4. Preuve de la correction de l’algorithme . . . . . . . . . . 4.6.2.5. Preuve de correction de Dependency_Algorithm . . . . 4.6.2.6. Étapes de base dans Dependency_Algorithm . . . . . . 4.6.2.7. Preuve de correction de Set_Context_Taint . . . . . . . 4.6.2.8. Preuve de correction de Taint_Assigned_Variable . . . 4.6.2.9. Preuve de la complétude de l’algorithme . . . . . . . . . 4.6.2.10. Complexité temporelle de l’algorithme . . . . . . . . . 4.6.3. Conception du système . . . . . . . . . . . . . . . . . . . . . . . 4.6.4. Gestion des flux explicites et de contrôle dans le code Java des applications Android . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4.1. Composant d’analyse statique . . . . . . . . . . . . . . . 4.6.4.2. Composant d’analyse dynamique . . . . . . . . . . . . . 4.6.4.3. Traitement des exceptions . . . . . . . . . . . . . . . . . 4.6.5. Gestion des flux explicites et de contrôle dans le code natif des applications Android . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.5.1. Traceur d’instructions natives des tags . . . . . . . . . . 4.6.5.2. Fonctions de commutation de contexte . . . . . . . . . . 4.6.5.3. Information Kernel . . . . . . . . . . . . . . . . . . . . . . 4.6.5.4. Native Taint sink . . . . . . . . . . . . . . . . . . . . . . . 4.6.6. Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6.1. Efficacité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6.2. Faux négatifs . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6.3. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.6.4. Faux positifs . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7. Protection contre les attaques d’obfuscation de code basées sur les dépendances de contrôle dans les systèmes Android . . 4.7.1. Définition de l’obfuscation du code . . . . . . . . . . . . . . . 4.7.2. Types d’obfuscations liés au programme . . . . . . . . . . . . 4.7.3. Techniques d’obfuscation . . . . . . . . . . . . . . . . . . . . . 4.7.4. Obfuscation de code dans le système Android . . . . . . . . . 4.7.5. Modèle d’attaque . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.6. Attaques d’obfuscation de code. . . . . . . . . . . . . . . . . . 4.7.7. Détection d’attaques d’obfuscation de code . . . . . . . . . . 4.7.8. Tests d’attaque d’obfuscation de code . . . . . . . . . . . . . . 4.8. Détection d’attaques de canaux auxiliaires basées sur le tag des données dans les systèmes Android . . . . . . . . . . . . . 4.8.1. Modèle de menace cible . . . . . . . . . . . . . . . . . . . . . . 4.8.2. Attaques dans les canaux latéraux . . . . . . . . . . . . . . . .

ix

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

166 169 169 169 170 171 171 171 172 172

. . . .

. . . .

. . . .

174 174 175 176

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

177 177 179 180 180 180 181 183 183 184 184

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

185 185 186 186 187 188 189 191 192

. . . . . . . . .

196 197 198

x

Cybervigilance et confiance numérique

4.8.2.1. Attaque de synchronisation . . . . . . . . . . . . . . 4.8.2.2. Attaque de mémoire cache . . . . . . . . . . . . . . 4.8.2.3. Attaque de pixel bitmap . . . . . . . . . . . . . . . . 4.8.2.4. Attaque de métadonnées . . . . . . . . . . . . . . . 4.8.2.5. Attaque de longueur de fichier . . . . . . . . . . . . 4.8.2.6. Attaque de la longueur du clipboard . . . . . . . . 4.8.2.7. Attaque de processeur graphique . . . . . . . . . . 4.8.3. Règles de propagation pour détecter les attaques par canal auxiliaire . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3.1. Règle de propagation du canal auxiliaire de synchronisation . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3.2. Règle de propagation du canal auxiliaire du mémoire cache . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3.3. Règle de propagation des métadonnées . . . . . . . 4.8.3.4. Règle de propagation GPU . . . . . . . . . . . . . . 4.8.4. Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.4.1. Détection d’attaques de synchronisation . . . . . . 4.8.4.2. Détection d’attaques de mémoire cache . . . . . . 4.8.4.3. Détection d’attaques de métadonnées . . . . . . . . 4.8.4.4. Processeur graphique pour la détection d’attaques 4.8.5. Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.5.1. Efficacité . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.5.2. Faux positifs . . . . . . . . . . . . . . . . . . . . . . . 4.8.5.3. Performance . . . . . . . . . . . . . . . . . . . . . . . 4.9. Suivi du flux d’informations dans les approches des systèmes Android : résumé . . . . . . . . . . . . . . . . . . . . . 4.10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11. Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

198 199 199 199 200 200 200

. . . . . .

201

. . . . . .

201

. . . . . . . . . . . .

. . . . . . . . . . . .

201 202 202 203 204 204 204 204 205 205 206 206

. . . . . . . . . . . . . . . . . .

207 212 213

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . .

Liste des auteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

225

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

227

Introduction

Cet ouvrage aborde en premier le sujet de la Cyber Threat Intelligence ou ce qu’on appelle le renseignement sur les cybermenaces. La Cyber Threat Intelligence est un moyen de défense et un savoir fondé sur des données probantes pour réduire l’écart entre les attaques avancées et les moyens de défense de l’organisation afin d’aider à la prise de décisions spécifiques ou d’éclairer l’ensemble des risques. Le chapitre 1 classe les types de Cyber Threat Intelligence existants et établit des distinctions entre eux, en mettant particulièrement l’accent sur les renseignements sur les menaces de nature technique ainsi que sur les dernières recherches, tendances et normes émergentes. En cybersécurité, le partage d’informations est primordial pour une gestion efficace et collective des menaces et des vulnérabilités. Cependant, et compte tenu du caractère sensible de ces informations, les organisations sont souvent réticentes à les partager avec leurs pairs lorsqu’elles ne se trouvent pas dans un environnement fiable. Le recours à la confiance, combinée à de nouveaux services du Cloud, constitue actuellement une solution pour améliorer la réponse collective aux nouvelles menaces. Pour approfondir cette approche, le chapitre 2 traite de la confiance numérique et identifie les mécanismes qui sous-tendent les systèmes de gestion de la confiance. Il introduit les concepts de base de gestion de la confiance, classe et analyse plusieurs systèmes de gestion de la confiance. Ce chapitre montre comment les concepts de gestion de la confiance sont utilisés dans les systèmes récents pour relever les nouveaux défis posés par le Cloud Computing. Lorsque les menaces ne sont pas bien traitées, toute vulnérabilité peut être exploitée et générer des coûts pour l’entreprise. Ces coûts peuvent être de nature humaine, technique et financière. Ainsi, pour faire face à ces menaces, une approche Introduction rédigée par Wiem TOUNSI.

2

Cybervigilance et confiance numérique

préventive visant à analyser les risques est primordiale. C’est l’objet du chapitre 3 qui présente une méthode complète d’analyse des risques des systèmes d’information déployée sur différents réseaux. Cette méthode est applicable aux extensions des normes et méthodes de gestion des risques existantes tout en se basant sur celles-ci. Enfin, une approche de détection basée sur l’analyse dynamique et statique est définie dans le chapitre 4 pour défendre les données sensibles des utilisateurs mobiles, contre les attaques de flux d’informations lancées par des applications tierces. Une approche formelle et technique basée sur un mécanisme de marquage des données est proposée pour gérer les flux de contrôle dans le code Java et le code natif des applications et pour résoudre le problème d’undertainting, notamment dans les systèmes Android.

Chapitre 1

La Cyber Threat Intelligence et son évolution

1.1. Introduction Les cyberattaques d’aujourd’hui ont changé de forme, de fonction et de degré de sophistication au cours des dernières années. Ces cyberattaques ne sont plus le seul fait de pirates informatiques ou de voyous en ligne. Réalisées par des acteurs de la menace, bien financés et bien organisés, les cyberattaques sont passées du simple piratage à des attaques avancées pour des fins lucratives, financières ou pour des gains politiques. Dans ce but, les attaques conçues pour les méfaits ont été remplacées par des attaques dynamiques, furtives et persistantes, connues sous le nom de menaces persistantes avancées (Advanced Persistant Threats, APT). La première raison en est la complexité des nouvelles technologies. Au fur et à mesure qu’un système devient plus complexe, il devient moins sûr, ce qui permet à l’attaquant de trouver plus facilement des faiblesses dans le système, rendant la tâche plus difficile au défenseur pour sécuriser ce système (Schneier 2000). En conséquence, les attaquants ont l’avantage du premier coup, en essayant de nouvelles attaques en premier, alors que les défenseurs ont l’inconvénient d’être dans une position constante de réponse, par exemple en proposant un meilleur logiciel antivirus pour combattre les nouveaux malwares (logiciels malveillants) et un meilleur système de détection des intrusions pour détecter les activités malveillantes. Malgré des dépenses annuelles de plus 20 milliards de dollars pour la défense traditionnelle (Piper 2013), les entreprises sont confrontées à cette nouvelle génération de cyberattaques, qui contournent facilement les défenses traditionnelles telles que les pare-feu traditionnels et de nouvelle génération, les systèmes de prévention des intrusions, les antivirus et les passerelles de sécurité. Ces défenses reposent en grande partie sur des signatures de logiciels malveillants statiques Chapitre rédigé par Wiem TOUNSI.

4

Cybervigilance et confiance numérique

ou des listes de technologies de filtrage, ce qui les rend extrêmement vulnérables à des menaces en constante évolution qui exploitent des vulnérabilités inconnues de type zero-day. Cela nécessite une nouvelle catégorie d’outils de prévention des menaces adaptés à la nature complexe de celles-ci et des attaques de la nouvelle génération. Cela mène à ce que l’on appelle communément la Cyber Threat Intelligence (CTI) ou le renseignement sur la cybermenace. La CTI signifie des connaissances fondées sur des données probantes représentant des menaces qui peuvent éclairer les décisions. Il s’agit d’une défense actionnable pour réduire l’écart entre les attaques avancées et les moyens de défense de l’organisation. Nous nous concentrons plus particulièrement sur les renseignements techniques sur les menaces ou Technical Threat Intelligence (TTI), qui devient rapidement une priorité commerciale de plus en plus importante (Chismon et Ruks 2015), car cette catégorie est immédiatement exploitable et est plus facilement quantifiable par rapport aux autres sous-catégories de CTI. La TTI est aussi l’intelligence la plus partagée, en raison de sa standardisation facile (Yamakawa 2014). Avec la TTI, nous pouvons alimenter des pare-feu, des passerelles, des informations de sécurité et de gestion d’événements (SIEM) ou d’autres outils de différents types avec ce qu’on appelle des indicateurs de compromission (IOC) (Verizon 2015). Ces IOC sont une forme de traces laissées par les attaquants, pouvant être des payloads, des liens ou des adresses IP malveillants. Nous pouvons également intégrer les IOC dans un index consultable ou simplement les exploiter pour la visualisation et les tableaux de bord en sécurité. Malgré sa prévalence, la TTI pose de nombreux problèmes. Il s’agit principalement de la qualité des IOC (durée de vie des adresses IP, signatures des malwares de la même famille) et des dépôts massifs de données sur les menaces fournies par les bases de données des fournisseurs qui surchargent leurs consommateurs de données qui ne sont pas toujours utiles. Dans de nombreux cas, les flux de menaces peuvent simplement équivaloir à des signatures rapidement générées qui n’atteignent toujours pas les attaquants. Par exemple, certaines charges utiles, URL et adresses IP malveillantes, sont si éphémères qu’elles ne peuvent être utilisées qu’une seule fois dans le cas d’une véritable attaque ciblée. À ce jour, peu d’analyses ont été réalisées sur les différentes sous-catégories de CTI et plus particulièrement sur la TTI. En outre, très peu d’études ont été menées sur la manière dont les nouvelles techniques et tendances tentent de surmonter les problèmes de la TTI. La plupart de la documentation existante révèle des rapports techniques exposant des statistiques périodiques sur l’utilisation de la CTI (Ponemon 2015 ; Shackleford 2015 ; Shackleford 2016), ainsi que des études empiriques intéressantes sur des techniques spécifiques d’analyse des menaces (Ahrend et al. 2016 ; Sillaber et al. 2016).

La Cyber Threat Intelligence et son évolution

5

Afin d’élaborer des stratégies de défense efficaces, les organisations peuvent gagner du temps et éviter les confusions si elles commencent à définir ce qu’est réellement la Cyber Threat Intelligence, comment l’utiliser et atténuer ses problèmes étant donné ses différentes sous-catégories. Ce chapitre vise à donner une idée claire de la CTI et de la façon dont la littérature la subdivise compte tenu de ses multiples sources, des méthodes de collecte, de la durée de vie de l’information et de la personne qui consomme les renseignements obtenus. Il aide à classer les catégories existantes de la CTI et à faire des distinctions entre elles afin de mieux les exploiter. Par exemple, étant donné la courte durée de vie des indicateurs de la TTI, il est important de déterminer pendant combien de temps ces indicateurs pourraient être utiles. Nous nous concentrons particulièrement sur les questions relatives à la TTI et sur les nouveaux travaux de recherche, les tendances et les normes visant à atténuer ces problèmes. Enfin, nous évaluons les outils de renseignements sur les menaces les plus populaires, qu’il s’agisse de logiciels libres ou de logiciels gratuits. Grâce à notre analyse, nous constatons que (1) contrairement à ce que l’on pense généralement, le partage rapide de la TTI n’est pas suffisant pour éviter des attaques ciblées ; (2) la confiance est essentielle pour un partage efficace de l’information sur les menaces entre les organisations ; (3) le partage de l’information sur les menaces améliore la confiance et la coordination pour une réponse collective aux nouvelles menaces ; (4) un format commun normalisé pour le partage de la CTI minimise le risque de perdre la qualité des données sur les menaces, qui permet aux solutions analytiques automatiques de générer de meilleurs résultats sur de grands volumes de TTI. 1.2. Contexte général Les menaces de la nouvelle génération ne sont plus des virus, des chevaux de Troie et des vers dont les signatures sont connues des défenses traditionnelles. Même les attaques d’ingénierie sociale et d’hameçonnage sont maintenant classées comme traditionnelles. Les menaces de nouvelle génération sont multi-vecteurs (c’est-à-dire qu’elles peuvent utiliser plusieurs vecteurs ou canaux de propagation tels que le Web, le courrier électronique et les applications) et multi-étapes (c’est-à-dire qu’elles peuvent infiltrer les réseaux et se déplacer latéralement dans le réseau) (FireEye Inc. 2012). Ces attaques multi-vecteurs et multi-étapes échappent facilement aux défenses de sécurité traditionnelles, qui sont généralement mises en place pour inspecter chaque vecteur d’attaque comme un chemin séparé et chaque étape comme

6

Cybervigilance et confiance numérique

un événement indépendant. Ainsi, elles ne considèrent pas et n’analysent pas l’attaque comme une série orchestrée de cyber incidents. 1.2.1. Menaces de nouvelle génération Pour mener à bien les attaques de nouvelle génération, les attaquants sont armés des dernières vulnérabilités de type zero-day et des techniques d’ingénierie sociale. Ils utilisent des tactiques avancées telles que les menaces polymorphes et les menaces mixtes (Piper 2013), qui sont personnalisées pour paraître inconnues des outils basés sur les signatures et suffisamment authentiques pour contourner les filtres antispam. Pour plus de détails, une taxonomie exhaustive du paysage des menaces a été établie par l’ENISA (Agence européenne chargée de la sécurité des réseaux et de l’information) au début de l’année 2017 (ENISA 2017). Dans la section suivante, nous donnons quelques exemples de ces menaces de nouvelle génération. 1.2.1.1. Menaces persistantes avancées (Advanced Persistant Threats, APT) Les APT sont des exemples de menaces à plusieurs vecteurs et à plusieurs étapes. Elles sont définies comme des attaques réseau sophistiquées (Piper 2013 ; FireEye Inc. 2014) dans lesquelles un attaquant continue d’essayer jusqu’à ce qu’il accède à un réseau et reste non détecté pendant une longue période. L’intention d’une APT est de voler des données plutôt que de causer des dommages au réseau. Les APT ciblent des organisations dans des secteurs à forte valeur ajoutée, tels que les agences gouvernementales et les industries financières. 1.2.1.2. Menaces polymorphes Les menaces polymorphes se trouvent à travers des virus, des vers ou des chevaux de Troie qui changent constamment (« morph ») (Piper 2013), ce qui rend presque impossible leur détection par des défenses basées sur des signatures. L’évolution des menaces polymorphes peut se produire de différentes manières (par exemple, via le changement du nom de fichier et la compression de ce fichier). Malgré l’apparition changeante du code dans une menace polymorphe après chaque mutation, la fonction essentielle reste généralement la même. Par exemple, un logiciel malveillant destiné à agir en tant qu’enregistreur de frappe continuera à exécuter cette fonction même si sa signature a changé. L’évolution des menaces polymorphes les a rendues presque impossibles à détecter à l’aide de défenses basées sur des signatures. Les fournisseurs qui fabriquent des produits de sécurité basés sur les signatures se voient créer et distribuer constamment de nouvelles signatures de menaces alors que les clients se trouvent à déployer constamment les signatures fournies par leurs fournisseurs de sécurité, s’agissant pourtant de la même menace. C’est un cercle vicieux qui profite à l’attaquant.

La Cyber Threat Intelligence et son évolution

7

1.2.1.3. Menaces zero-day Les menaces zero-day sont des cybermenaces sur une vulnérabilité publiquement inconnue d’un système d’exploitation ou d’une application. Elles sont ainsi nommées parce que l’attaque a été lancée le « jour zéro » ou avant que le public n’ait pris conscience de la vulnérabilité et, dans de nombreux cas, avant même que le vendeur ne le sache (Piper 2013). Dans certains cas, le fournisseur est déjà au courant de la vulnérabilité, mais ne l’a pas divulguée publiquement parce que la vulnérabilité n’a pas encore été corrigée. Les attaques des vulnérabilités zero-day sont extrêmement efficaces parce qu’elles peuvent passer inaperçues pendant de longues périodes (c’està-dire des mois, voire des années), et lorsqu’elles sont finalement identifiées, la correction de la vulnérabilité prend encore des jours, voire des semaines. 1.2.1.4. Menaces composites Les cyberattaques peuvent être classées comme attaques syntaxiques ou sémantiques. Une combinaison de ces deux approches est connue sous le nom d’attaque composite ou d’attaque mixte (Choo et al. 2007). Les attaques syntaxiques exploitent les vulnérabilités techniques des logiciels et/ou du matériel, par exemple une installation malveillante pour voler des données, tandis que les attaques sémantiques exploitent les vulnérabilités sociales pour obtenir des informations personnelles, par exemple des sollicitations frauduleuses. Au cours des dernières années, des progrès ont été constatés en utilisant les deux approches pour réaliser des attaques composites : utiliser un outil technique pour faciliter l’ingénierie sociale afin d’obtenir des informations privilégiées, ou utiliser un moyen d’ingénierie sociale pour réaliser une attaque technique afin de causer un préjudice aux hôtes du réseau. Les attaques composites comprennent les attaques de phishing ou d’hameçonnage (également appelées escroqueries en ligne) qui utilisent fréquemment des emails pour envoyer à des victimes soigneusement sélectionnées un message d’apparence plausible comprenant une pièce jointe malveillante ciblant une vulnérabilité zero-day. L’hameçonnage est positionné dans les trois premières étapes de la chaîne kill chain (section 1.2.2.1). Les attaques par hameçonnage sont donc des messages falsifiés et souvent forgés pour paraître provenir d’organisations légitimes, en particulier des services bancaires et financiers, visant à tromper les victimes en les incitant à divulguer leurs informations financières et/ou personnelles. Ceci peut-être aussi en incitant les victimes à télécharger des fichiers malveillants, afin de faciliter d’autres attaques (par exemple, vol d’identité, fraude par carte de crédit, ransomeware (Kaspersky Lab, Intel Security 2017)). Lorsque l’attaque se concentre sur un nombre limité de destinataires auxquels un message hautement personnalisé est envoyé, la technique est appelée spear phishing. L’hameçonnage abuse surtout de l’information trouvée dans les médias sociaux (Fadilpasic 2016). Les attaquants sont toujours à la recherche de nouveaux vecteurs d’attaque pour l’hameçonnage, y compris sur les

8

Cybervigilance et confiance numérique

appareils mobiles intelligents. De tels appareils sont de plus en plus utilisés pour accéder et stocker des comptes et services sensibles (Choo 2011). Évidemment, la morphologie de l’attaque est différente selon le scénario visé. Ainsi, la cybercriminalité peut utiliser l’APT furtif pour voler la propriété intellectuelle, tandis que la cyberguerre utilise des botnets pour exécuter des attaques par déni de service (DDoS) (Skopik et al. 2016). 1.2.2. Structures et modèles analytiques Certaines structures analytiques fournissent un cadre de réflexion sur les attaques et les adversaires pour permettre aux défenseurs de prendre des mesures décisives plus rapidement. Par exemple, nous nommons la perspective défensive de la kill chain (Hutchins et al. 2011) et le modèle Diamond utilisé pour suivre les groupes d’attaques dans le temps. D’autres structures normalisées sont élaborées dans la section 8.4. 1.2.2.1. Étapes de la perspective défensive de la kill chain La kill chain, développée pour la première fois par Lockheed Martin en 2011 (Hutchins et al. 2011), est une séquence d’étapes nécessaires pour qu’un attaquant réussisse à infiltrer un réseau et à en exfiltrer les données (Barraco 2014). En interrompant une attaque de cette manière, les défenseurs peuvent vérifier dans quelle phase ou étape elle se trouve et déployer les contre-mesures appropriées.

Figure 1.1. Étapes typiques d’une attaque sophistiquée projetée sur la kill chain de Lookheed Martin

– Reconnaissance et armement : la reconnaissance consiste en la recherche, l’identification et la sélection de cibles, souvent en parcourant des sites web (par exemple, des actes de conférences, des listes de diffusion et des relations sociales), en déroulant des PDF ou en apprenant la structure interne de l’organisation cible.

La Cyber Threat Intelligence et son évolution

9

L’armement ou militarisation est réalisée par l’élaboration d’un plan d’attaque fondé sur les possibilités d’exploitation. – Livraison : il s’agit de la transmission de l’arme à l’environnement visé. Il s’agit souvent d’une attaque mixte diffusée par différents vecteurs comme le Web ou l’email, celui-ci contenant des URL malveillantes (c’est-à-dire une attaque d’hameçonnage). Qu’il s’agisse d’un email avec une pièce jointe malveillante ou d’un lien vers un site web compromis ou une requête HTTP contenant du code d’injection SQL, c’est la phase critique où la charge utile est livrée à sa cible. – Exploitation : le plus souvent, l’exploitation cible une application ou une vulnérabilité du système d’exploitation, mais elle peut exploiter les utilisateurs eux-mêmes ou exploiter une fonctionnalité du système d’exploitation qui exécute automatiquement un code. – Installation et persistance : un seul exploit se traduit par plusieurs infections sur le même système. Un plus grand nombre de charges utiles exécutables de malware tels les enregistreurs de frappe de touches (key loggers), les craqueurs de mots de passe et les portes dérobées (via des chevaux de Troie) pourraient alors être téléchargés et installés. Les attaquants ont mis en place à ce stade des mécanismes de contrôle à long terme pour maintenir la persistance dans le système. – Commande et contrôle (C&C) : dès que le malware est installé, un point de contrôle des défenses organisationnelles est établi. Une fois que ses permissions sont levées, le malware établit la communication avec l’un de ses serveurs C&C pour obtenir des instructions supplémentaires. Le malware peut également se répliquer et se déguiser pour éviter les scans, éteindre des antivirus, ou rester dormant pendant des jours ou des semaines, en utilisant une stratégie lente et cachée pour échapper à la détection. En utilisant des rappels (callback) du réseau de confiance, les communications malveillantes sont autorisées à travers un pare-feu et peuvent pénétrer les différentes couches du réseau. – Exfiltration des données : les données acquises à partir de serveurs infectés sont exfiltrées via des fichiers chiffrés sur un protocole couramment autorisé, par exemple FTP ou HTTP, vers un serveur externe compromis contrôlé par l’attaquant. Les violations de l’intégrité ou de la disponibilité des données sont également des objectifs potentiels. – Se propager latéralement : l’attaquant travaille pour aller au-delà du système unique et établit un contrôle à long terme dans le réseau ciblé. Le malware ou logiciel malveillant avancé recherche les lecteurs mappés sur les systèmes infectés et peut ensuite se propager latéralement dans les partages de fichiers réseau.

10

Cybervigilance et confiance numérique

Généralement, si vous êtes capable de gérer et d’arrêter une attaque à l’étape de l’exploitation à l’aide de cette structure, vous pouvez être sûr que rien n’a été installé sur les systèmes ciblés et qu’il n’est peut-être pas nécessaire de déclencher une activité complète de réponse aux incidents. La kill chain est un bon moyen de défendre les systèmes contre les attaques, mais elle a certaines limites. L’une des grandes critiques de ce modèle est qu’il ne tient pas compte de la façon dont de nombreuses attaques modernes fonctionnent. Mais même avec ces limites, la kill chain est un bon point de départ pour discuter des attaques et trouver à quel stade elles peuvent être arrêtées et analysées. 1.2.2.2. Le modèle Diamond de l’analyse d’intrusion Le modèle Diamond a été créé en 2013 au Center for Cyber Intelligence Analysis and Threat Research (CCIATR). Il est utilisé pour suivre les groupes adverses au fil du temps plutôt que l’évolution des attaques individuelles. La forme la plus simple du modèle Diamond est illustrée à la figure 1.2.

Figure 1.2. Le modèle Diamond de l’analyse d’intrusion

Le modèle Diamond classe les différents éléments d’une attaque. Le Diamond d’un adversaire ou d’un groupe n’est pas statique, mais évolue à mesure que l’adversaire change d’infrastructure et de cibles et modifie ses TTP (techniques, tactiques et procédures). Le modèle Diamond aide les défenseurs à suivre un adversaire, les victimes, les capacités de l’adversaire et l’infrastructure qu’il utilise. Chaque point sur le Diamond est un point de pivot que les défenseurs peuvent utiliser pendant une enquête pour relier un aspect d’une attaque aux autres (Pace et al. 2018).

La Cyber Threat Intelligence et son évolution

11

Un grand avantage du modèle Diamond est sa flexibilité et son extensibilité. Il est possible d’ajouter différents aspects d’une attaque sous le point approprié sur le Diamond pour créer des profils complexes de différents groupes d’attaques. Ces aspects d’une attaque comprennent : phase, résultat, direction, méthodologie et ressources. Ce modèle exige du temps et des ressources. Certains aspects du modèle, en particulier l’infrastructure, changent rapidement. Si le Diamond d’un adversaire n’est pas constamment mis à jour, il y a un risque de travailler avec des informations périmées. 1.3. Cyber Threat Intelligence (CTI) La Cyber Threat Intelligence (CTI), aussi appelée renseignement sur les cybermenaces, est un ensemble de connaissances fondées sur des données probantes au sujet des menaces qui peuvent éclairer les décisions (McMillan 2013), dans le but de prévenir une attaque ou de réduire la période entre la compromission et la détection. La CTI peut aussi être une information qui, au lieu d’aider à prendre des décisions spécifiques, aide à éclairer le paysage du risque (Chismon et Ruks 2015). D’autres définitions existent, par exemple, dans Steele (2014) et Dalziel (2014). Une définition plus rigoureuse (Dalziel 2014) affirme que la CTI est une information qui devrait être pertinente (c’est-à-dire potentiellement liée à l’organisation et/ou à ses objectifs), réalisable (c’est-à-dire suffisamment spécifique pour susciter une réponse, une action ou une décision) et valable (c’est-à-dire que l’information doit contribuer à tout résultat opérationnel utile). La CTI soutient différentes activités, à savoir les opérations de sécurité, la réponse aux incidents, la gestion des vulnérabilités et des risques, l’analyse des risques et la prévention de la fraude (Pace et al. (2018)). Enfin, selon les activités prévues, les sources de la CTI peuvent différer. 1.3.1. Sources de la Cyber Threat Intelligence La CTI peut être générée à partir d’informations recueillies auprès de diverses sources (Holland et al. 2013). Il s’agit généralement de sources internes (c’est-à-dire les journaux de pare-feu et de routeur ou d’autres capteurs locaux, comme les honeypots, qui sont des groupes de systèmes informatiques interactifs généralement connectés à Internet et configurés pour piéger les attaquants) ou de sources externes, comme les sources parrainées par le gouvernement (par exemple, les organismes d’application de la loi, les organismes de sécurité nationale), des sources de l’industrie (c’est-à-dire les partenaires d’affaires), des sources de renseignements à source ouverte (Open Source Intelligence, OSINT), c’est-à-dire les sources de menaces publiques

12

Cybervigilance et confiance numérique

comme Dshield (2017), ZeuS Tracker (2017), les médias sociaux et les forums du Web obscur (darkweb), enfin, des sources commerciales (c’est-à-dire les flux de menaces payants, les fournisseurs de CTI). Les sources externes pourraient fournir des informations structurées ou non structurées, alors que les sources internes sont connues pour fournir des informations structurées car elles sont générées par des outils techniques. Les sources structurées sont techniques, c’est-à-dire toute information provenant de bases de données sur les vulnérabilités ou des flux de données sur les menaces qui sont analysables et digestibles par les machines ; leur traitement est donc simple. Les sources non structurées sont tout ce qui est produit par le langage naturel, comme ce que l’on trouve dans les médias sociaux, les discussions dans les forums clandestins, les communications avec un pair ou le Web obscur. Ils ont besoin de techniques de traitement du langage naturel et d’apprentissage automatique pour produire de l’intelligence. Le tableau 1.1 présente ces sources avec les technologies requises pour traiter l’information et la transformer en renseignement. Sources internes

Exemples

Sources externes

Structurées (principalement)

Structurées

Non structurées

Journaux de pare-feu et de routeur, honeypots (pots de miels)

Bases de données sur les vulnérabilités, listes noires et listes blanches des IP, flux de données sur les menaces

Forums, sites d’actualités, médias sociaux, darkweb

Racleurs/Analyseur de flux de données web (Web scraper/parser)

Collection : crawlers, analyseurs de flux/Web. Traitement : traitement du langage naturel (Naturel Language Processing, NPL), techniques d’apprentissage automatique

Technologies Analyseur de flux de de collecte données (feed parser) et de traitement

Tableau 1.1. Sources de la CTI

Après la collecte et le traitement de l’information sur les menaces, plusieurs initiatives encouragent le partage de ces informations, comme les équipes de réponse à incidents et les différentes coopérations internationales (CERT, FIRST, TF-CSIRT)

La Cyber Threat Intelligence et son évolution

13

(Skopik et al. 2016), ainsi que les centres de partage et d’analyse des informations (ISACs) (ENISA 2015). 1.3.2. Sous-domaines de la Cyber Threat Intelligence Compte tenu des différentes sources du renseignement sur les menaces et des activités qui les utilisent, il est utile d’avoir des subdivisions pour mieux gérer l’information recueillie et concentrer les efforts. La CTI peut être catégorisée en sousdomaines. Ahrend et al. (2016) divisent la CTI en pratiques formelles et informelles pour découvrir et utiliser les connaissances tacites entre collaborateurs. Cela dépend de la forme d’interaction entre collaborateurs. Gundert (2014) et Hugh (2016) classent la CTI comme stratégique et opérationnelle selon la forme d’analyse utilisée pour la produire. Dans Chismon et Ruks (2015) et Korstanje (2016), un modèle plus raffiné divise la CTI ou le renseignement sur les menaces en quatre domaines distincts : renseignement stratégique, renseignement opérationnel, renseignement tactique et renseignement technique. Cette subdivision est aussi appelée les quatre niveaux d’analyse du renseignement (Steele 2007b). À l’origine, elle a été utilisée dans un contexte militaire comme modèle d’analyse des facteurs expéditionnaires qui distingue ces quatre niveaux (Steele 2007a). Dans ce qui suit, notre étude s’intéresse à la dernière subdivision. Le tableau 1.2 résume les quatre domaines : – le renseignement stratégique sur les menaces ou la CTI stratégique est une information de haut niveau consommée par les décideurs. L’objectif est d’aider les stratèges à comprendre les risques actuels et à identifier d’autres risques dont ils ne sont pas encore conscients. Il pourrait couvrir l’impact financier de la cyberactivité ou les tendances des attaques, les données historiques ou les prévisions concernant les futures menaces. Par conséquent, un conseil d’administration doit cibler les attaques possibles, afin d’évaluer les risques et de répartir les efforts et le budget pour atténuer ces éventuelles attaques. La CTI stratégique prend généralement la forme de rapports, de séances d’information ou de conversations ; – le renseignement sur les menaces opérationnelles ou la CTI opérationnelle est le renseignement sur des attaques imminentes contre l’organisation. Il est d’abord utilisé par le personnel de sécurité de haut niveau, par exemple les responsables de la sécurité ou les chefs des équipes de réponse à incident (Chismon et Ruks 2015). Cela les aide à prévoir quand et où les attaques auront lieu ; – le renseignement tactique sur les menaces ou la CTI tactique concerne les informations sur la manière dont les acteurs de la menace mènent des attaques (Chismon et Ruks 2015), ce qu’on appelle aussi tactiques, techniques et procédures.

14

Cybervigilance et confiance numérique

La CTI tactique est utilisée par les intervenants en cas d’incident pour s’assurer que leurs moyens de défense sont prêts à intervenir. Par exemple, la compréhension de l’outillage et de la méthodologie de l’attaquant est un renseignement tactique qui pourrait inciter les défenseurs à changer de politique. Le renseignement tactique est souvent obtenu en lisant la presse technique ou des livres blancs, en communiquant avec des pairs d’autres organisations pour savoir ce que font les attaquants, ou en achetant auprès d’un fournisseur un flux de renseignements de ce type ; – le renseignement sur les menaces techniques ou la CTI technique (TTI) est le renseignement le plus souvent consommé par les outils techniques (Chismon et Ruks 2015). La TTI alimente généralement les fonctions d’enquête ou de surveillance d’une organisation, par exemple des pare-feu et des dispositifs de filtrage du courrier, en bloquant les tentatives de connexion à des serveurs suspects. La TTI sert également pour les outils analytiques, ou simplement pour la visualisation et les tableaux de bord. Par exemple, après avoir inclus des indicateurs de compromission (IOC) dans l’infrastructure défensive d’une organisation, comme des pare-feu et des dispositifs de filtrage du courrier, les attaques historiques peuvent être détectées en cherchant dans les journaux des connexions ou des binaires précédemment observés (Chismon et Ruks 2015).

Niveau

Stratégique

Opérationnel

Tactique

Technique

Élevé

Élevé

Proche

Proche

Le conseil d’administration

Audience

Défenseurs

Personnel du centre Cadres supérieurs d’opérations de de la sécurité ; sécurité ; équipe architectes de réponse à incident

Informations Tactiques, Indicateurs de haut niveau Détails des attaques techniques et sur l’évolution de compromission spécifiques entrantes procédures des des risques (IOC) attaquants et menaces

Contenu

Calendrier de mise en œuvre

Long terme

Court terme

Long terme

Immédiate

Tableau 1.2. Sous-domaines de la Cyber Threat Intelligence

La Cyber Threat Intelligence et son évolution

15

D’après leurs définitions, les renseignements stratégiques et tactiques sur les menaces sont utiles pour une utilisation à long terme, tandis que les renseignements opérationnels et techniques sur les menaces sont faits pour une utilisation à court terme/immédiate. Dans le cas où les IOC techniques sont destinés à une utilisation à court terme, une question clé est la suivante : combien de temps pouvons-nous espérer que ces indicateurs demeurent utiles ? Dans la section suivante, nous traiterons plus en détail le renseignement technique sur les menaces, connu aussi comme la Technical Threat Intelligence (TTI). 1.3.3. Renseignement technique sur les menaces (Technical Threat Intelligence, TTI) Les défenseurs doivent non seulement être conscients des acteurs de la menace et de la nature des attaques auxquelles ils sont confrontés, mais aussi des données fondamentales associées à ces cyberattaques, connues sous le nom d’indicateurs de compromission (Indicators of Compromise, IOC). Les IOC sont étroitement liés aux TTI, mais ils sont souvent confondus avec le renseignement. Les IOC sont un aspect qui permet la production du renseignement et d’une décision à prendre. Les flux des IOC ne sont que des données. Ce n’est qu’en réalisant une analyse à l’aide des données internes pertinentes pour l’organisation corrélées aux IOC, qu’une décision ou une action peut être prise à la suite de tout incident (Dalziel 2014). Les IOC sont généralement de trois natures distinctes (Ray 2015) : – indicateurs sur le réseau se trouvent à travers les URL et les noms de domaine utilisés pour les attaques de type Commande et Contrôle (C&C) et la diffusion de malwares via des liens. Il peut s’agir d’adresses IP précédemment détectées pour des attaques de serveurs distants, de botnets ou des attaques DDoS. Cependant, ce type d’IOC a une courte durée de vie car les acteurs de la menace passent d’un serveur compromis à un autre. De plus, avec le développement des services d’hébergement sur le Cloud, ce ne sont plus seulement les serveurs compromis qui sont utilisés pour réaliser des attaques, mais aussi les adresses IP légitimes appartenant aux grandes entreprises ; – indicateurs basés sur l’hôte peuvent être trouvés par l’analyse d’un ordinateur infecté. Il peut s’agir de noms de logiciels malveillants et de documents de leurre ou de hach de fichiers d’un logiciel malveillant faisant l’objet d’une enquête. Les indicateurs de logiciels malveillants les plus couramment proposés sont les hach MD5 ou SHA-1 des binaires (Chismon et Ruks 2015). Les bibliothèques de liens dynamiques (DLL) sont aussi souvent ciblées, car les attaquants remplacent les fichiers système Windows pour s’assurer que leur charge utile s’exécute chaque fois que Windows démarre. Les clés de registre peuvent être ajoutées par un code malveillant, et des clés spécifiques

16

Cybervigilance et confiance numérique

peuvent être modifiées dans les paramètres de registre de l’ordinateur pour permettre la persistance. Il s’agit d’une technique couramment utilisée par les auteurs de logiciels malveillants lors de la création de chevaux de Troie (Ray 2015) ; – indicateurs liés au courrier électronique sont généralement créés lorsque les attaquants utilisent des services de courrier électronique gratuits pour envoyer des emails d’ingénierie sociale à des organisations et des individus ciblés. L’adresse email source et l’objet de l’email sont créés à partir d’adresses qui semblent appartenir à des personnes reconnaissables ou mettre en évidence des événements d’actualité pour créer des lignes d’objet d’email intrigantes, souvent avec pièces jointes et liens. Les adresses IP X-originating and X-forwarding sont des en-têtes d’email identifiant l’adresse IP d’origine (1) d’un client se connectant à un serveur de messagerie, et (2) d’un client se connectant à un serveur web via un proxy HTTP ou un répartiteur de charge, respectivement. La surveillance de ces adresses IP, lorsqu’elles sont disponibles, fournit des informations supplémentaires sur les attaquants. Le spam est le principal moyen de transport des URL malveillantes et des logiciels malveillants. Ceux-ci sont ensuite emballés sous forme de spam et de messages d’hameçonnage Les attaques d’hameçonnage falsifient les messages d’organisations légitimes pour tromper les victimes et les amener à divulguer leurs informations financières et/ou personnelles ou à télécharger des fichiers malveillants, afin de faciliter d’autres attaques. Le spam est principalement distribué par de grands réseaux de robots spammeurs (c’est-à-dire des dispositifs qui sont repris et forment un large réseau de zombies adhérant à des serveurs C&C (ENISA 2017)). Des méthodes d’obscurcissement (Symantec 2016) ont été observées en 2015 et se sont poursuivies en 2016 pour échapper à la détection de ce type d’attaque. Ces méthodes pourraient être l’expédition de quantités massives de spam à une large gamme d’adresses IP pour réduire l’efficacité des filtres antispam ou l’utilisation de symboles alphanumériques et de caractères UTF-8 pour coder des URL malveillantes. 1.4. Travaux connexes Les cybermenaces et les attaques sont actuellement l’un des phénomènes les plus discutés dans l’industrie informatique et dans les médias en général (iSight Partners 2014). La figure 1.3(a) montre des résultats provenant de Google sur la notion de « Threat Intelligence », dans la cyberactivité en général et en particulier en termes de publications de recherche, et la figure 1.3(b) montre des résultats depuis Google sur la notion « indicators of compromise » dans le paysage de la menace en général et pour les publications de recherche en particulier, au cours des dix dernières années. Ces chiffres sont relevés année par année. Même si l’on constate un intérêt exponentiel pour les renseignements sur les menaces et les domaines des IOC, nous observons un

La Cyber Threat Intelligence et son évolution

17

écart entre l’évolution des activités des renseignements sur les cybermenaces et les travaux de recherche connexes.

Figure 1.3. Tendance des renseignements sur les menaces et des indicateurs de compromission dans la cyberactivité durant ces dix dernières années

En réalité, derrière ces chiffres, on trouve un grand nombre de fournisseurs de renseignements sur les menaces et de documents consultatifs qui décrivent des produits et des activités très différents sous la bannière de Cyber Threat Intelligence. La même conclusion s’applique à la catégorie TTI via les indicateurs de compromission. Cependant, peu de travaux de recherche ont été menés pour examiner et identifier les caractéristiques de la CTI et de ses problèmes connexes. Il convient également de noter qu’au cours des dernières années, d’importants progrès ont été réalisés dans ce domaine.

18

Cybervigilance et confiance numérique

En ce qui concerne les études connexes à notre travail, la plupart d’entre elles montrent chaque année de nouvelles tendances et statistiques pertinentes pour l’intelligence stratégique (Ponemon 2015 ; Shackleford 2015 ; Shackleford 2016). Du côté de la recherche, un important corpus de travail a été dédié aux questions de partage du renseignement sur les menaces (Moriarty 2011 ; Barnum 2014 ; Burger et al. 2014 ; Ring 2014 ; Skopik et al. 2016). De nombreuses lignes directrices, meilleures pratiques et résumés sur les normes et techniques de partage existantes ont été publiés (par exemple Johnson et al. 2016). En revanche, moins de recherches ont été consacrées à des domaines tels que les problèmes des TTI et les moyens de les atténuer. Ce travail complète le travail de recherche susmentionné en séparant les catégories de CTI. Il analyse spécifiquement les problèmes de CTI technique (TTI) par type (c’est-à-dire les problèmes de quantité d’informations par rapport à la qualité et les limitations spécifiques liées à chaque type d’IOC). Ensuite, il montre comment les atténuer. Ce chapitre étudie également les raisons pour lesquelles on ne partage pas les informations sur les menaces avec ses pairs et présente des solutions pour partager ces informations en évitant les risques d’attaque ou les risques commerciaux pour les entreprises. Nous montrons comment une représentation standardisée commune de TTI améliore la qualité de l’information sur les menaces, ce qui améliore les résultats des solutions d’analyse automatisée sur de grands volumes de TTI souffrant de nonuniformité et de redondance. Enfin, nous évaluons les outils TTI qui visent à partager les renseignements sur les menaces entre les organisations. Dans la section 1.5, nous commençons par décrire les principales raisons pour lesquelles les organisations ne partagent pas la CTI. 1.5. Problèmes de partage des renseignements sur les menaces Les avantages du partage collectif et de l’apprentissage à partir d’informations étendues et partagées sur les menaces sont indéniables. Pourtant, diverses barrières limitent les possibilités de coopération. Dans cette section, nous détaillons certains de ces avantages et exposons les raisons pour lesquelles on ne partage pas l’information sur les menaces. 1.5.1. Avantages du partage des renseignements sur les menaces pour l’apprentissage collectif De nombreuses organisations et de nombreux participants s’entendent aujourd’hui sur l’importance du partage de l’information sur les menaces pour de nombreuses

La Cyber Threat Intelligence et son évolution

19

raisons. Premièrement, il a été démontré que l’échange de données sur les menaces critiques permet de prévenir les cyberattaques potentielles et d’atténuer les attaques en cours et les risques futurs. Selon le Bipartisan Policy Center (2012), les principaux analystes de la cybercriminalité reconnaissent que le partage public-privé d’information en ligne peut accélérer l’identification et la détection des menaces. Ainsi, si les organisations sont capables de trouver un intrus dans ses phases actives, elles ont plus de chances d’arrêter l’attaquant avant que les données ne soient volées (Zurkus 2015). En outre, le partage des menaces (threat sharing) est un moyen effectif dans la lutte contre la cybercriminalité s’il est correctement développé (Peretti 2014 ; Ponemon 2014). Dans Gilligan et al. (2014), une étude sur l’économie de la cybersécurité a identifié un certain nombre de « principes d’investissement » que les organisations peuvent utiliser dans le développement de programmes de sécurité des données avec un bénéfice économique élevé. L’un de ces principes est la participation à de multiples échanges d’informations sur la cybersécurité. Les avantages du partage comprennent également une meilleure connaissance de la situation du paysage de la menace, une meilleure compréhension des acteurs de la menace et de leurs TTP (tactique, technique et procédures), et une plus grande agilité pour se défendre contre les menaces en évolution (Zheng et Lewis 2015). C’est ce qui ressort d’une enquête récente (Ponemon 2015), qui a interrogé 692 informaticiens et spécialistes de la sécurité informatique dans divers secteurs d’activité. Les résultats révèlent qu’il est de plus en plus reconnu que l’échange de renseignements sur les menaces peut améliorer la posture de sécurité et la connaissance de la situation d’une organisation. Plus généralement, le partage des menaces améliore la coordination pour un apprentissage collectif et une réponse aux nouvelles menaces et réduit la probabilité d’effets en cascade sur l’ensemble d’un système, d’une industrie, d’un ou plusieurs secteurs (Zheng et Lewis 2015). De nombreuses attaques ne visent pas une seule organisation isolément, mais un certain nombre d’organisations, souvent dans le même secteur (Chismon et Ruks 2015). Par exemple, une entreprise peut être endommagée lorsque les ordinateurs d’une entreprise concurrente sont attaqués, car les informations volées peuvent souvent être utilisées contre d’autres organisations du même secteur. 1.5.2. Raisons de ne pas partager les renseignements sur les menaces Malgré les avantages évidents de l’échange de renseignements sur les menaces, on observe une réticence à signaler les atteintes à la sécurité. La question a été sérieusement soulignée au niveau paneuropéen lorsque l’ENISA, la principale agence de cybersécurité de l’UE, a publié un rapport en 2013 (ENISA 2013), capitalisant intentionnellement le mot « PARTAGE ». Le rapport avertissait environ 200 CERT majeures en Europe que « la complexité croissante des cyberattaques exige un partage

20

Cybervigilance et confiance numérique

plus efficace de l’information » et que les organisations n’étaient pas vraiment impliquées dans ce processus. Dans son dernier rapport sur le paysage des menaces publié début 2017 (ENISA 2017), l’ENISA continue de recommander le partage d’informations comme vecteur d’atténuation des malwares. Les auteurs recommandent l’élaboration de méthodes d’identification et le partage des modus operandi sans divulguer d’informations concurrentielles. En réalité, de nombreuses préoccupations découragent la participation à une telle initiative de partage. Nous identifions par ordre d’importance dix raisons principales de ne pas partager l’information sur les menaces. Elles sont donc résumées dans le tableau 1.3. 1

Crainte d’une publicité négative

(Richards 2009 ; Choo 2011 ; Peretti 2014 ; Chismon et Ruks 2015)

2

Règles juridiques, questions relatives à la protection de la vie privée

(ENISA 2013 ; Peretti 2014 ; Murdoch et Leaver 2015 ; Skopik et al. 2016)

3

Problèmes de qualité

(ENISA 2013 ; Ring 2014 ; Ponemon 2015 ; Sillaber et al. 2016)

4

Participants non fiables

(ENISA 2013 ; Murdoch et Leaver 2015 ; Ponemon 2015)

5

Estimation que l’incident ne vaut pas la peine d’être partagé

(Choo 2011 ; Ring 2014 ; Chismon et Ruks 2015)

6

Questions budgétaires

(Ring 2014 ; Skopik et al. 2016)

7

Instinct naturel de ne pas partager

(Ring 2014)

8

Évolution de la nature des cyberattaques

(Ring 2014)

9

Ignorance de l’organisation victime d’un cyberincident

(Choo 2011)

10

Estimation qu’il y a peu de chances que les poursuites aboutissent

(Choo 2011)

Tableau 1.3. Raisons de ne pas partager

La Cyber Threat Intelligence et son évolution

21

La crainte d’une publicité négative est l’une des principales raisons de ne pas partager l’information sur les menaces, ce qui pourrait entraîner un désavantage concurrentiel (Richards 2009 ; Choo 2011 ; Peretti 2014 ; Chismon et Ruks 2015). Par exemple, les concurrents pourraient utiliser l’information contre une organisation victime. Dans certains secteurs, même une rumeur de compromis peut influencer les décisions d’achat ou les évaluations du marché (Bipartisan Policy Center 2012). Les règles juridiques et les questions de protection de la vie privée sont également citées parmi les raisons les plus importantes de ne pas partager (ENISA 2013 ; Peretti 2014 ; Murdoch et Leaver 2015 ; Skopik et al. 2016). Les organisations peuvent hésiter à signaler un incident parce qu’elles sont souvent incertaines quant au type d’information qui peut être échangé pour éviter les questions juridiques concernant la protection des données de la vie privée. Dans le même pays, les règles juridiques peuvent ne pas être les mêmes pour les équipes coopérantes. L’affiliation à un secteur spécifique, par exemple, peut forcer le respect de réglementations spécifiques (ENISA 2006). En ce qui concerne la coopération internationale, la confiance entre les équipes coopérantes lors du traitement d’informations sensibles est la plupart du temps empêchée par les réglementations internationales qui limitent l’échange et l’utilisation de ces informations. Les équipes travaillant dans différents pays doivent se conformer à des environnements juridiques différents. Cette question influe sur la façon dont les équipes fournissent leurs services et traitent certains types d’attaques, ce qui limite les possibilités de coopération, voire rend la coopération impossible (Skopik et al. 2016). Les problèmes de qualité sont l’un des obstacles les plus courants à un échange efficace d’informations, selon différentes enquêtes réalisées sur les CERT et autres organisations similaires (ENISA 2013 ; Ring 2014 ; Ponemon 2015 ; Sillaber et al. 2016). La qualité des données comprend la pertinence, l’actualité, l’exactitude, la comparabilité, la cohérence et la clarté. Par exemple, de nombreuses personnes interrogées signalent qu’une grande partie de ce qui est partagé est le plus souvent ancien et ne peut pas, par conséquent, donner lieu à une action. L’information n’est pas non plus suffisamment spécifique pour faciliter le processus de prise de décision. Les participants non fiables sont également cités dans des enquêtes récentes (ENISA 2013 ; Murdoch et Leaver 2015 ; Ponemon 2015) parmi les obstacles cruciaux à une communication efficace entre organisations. Certaines personnes interrogées à l’ENISA (2013) ont souligné que la confiance est minée lorsque seulement quelques parties sont actives dans un programme de partage, sans obtenir beaucoup en retour des autres parties. Murdoch et Leaver (2015) expliquent que la nécessité pour les utilisateurs de garder l’anonymat en partageant des informations sur les menaces est en conflit avec le fait de s’assurer que les destinataires continuent d’avoir confiance en

22

Cybervigilance et confiance numérique

l’information lorsque la source est inconnue. Ceci constitue alors un obstacle à la participation à une plateforme de partage de renseignements sur la menace. Certaines personnes interrogées à l’ENISA (2013) ont souligné que la confiance est minée lorsque seulement quelques parties sont actives dans un programme de partage, sans obtenir beaucoup en retour des autres parties. Murdoch et Leaver (2015) expliquent que le conflit lié à la nécessité pour les utilisateurs de garder l’anonymat tout en s’assurant que les destinataires continuent d’avoir confiance en l’information (c’est-à-dire même lorsque la source est inconnue) est un obstacle à la participation à une plateforme de partage de renseignements sur la menace. Le fait de croire que l’incident ne vaut pas la peine d’être partagé est aussi souvent mentionné (Choo 2011 ; Ring 2014 ; Chismon et Ruks 2015). Les organisations victimes traitent simplement l’incident en interne en croyant qu’il n’est pas assez grave pour justifier qu’il soit signalé à une partie externe, y compris les organismes d’application de la loi et autres organismes compétents. Les questions budgétaires sont des raisons de limiter l’établissement d’un niveau de coopération profitable (Ring 2014 ; Skopik et al. 2016). Certaines personnes interrogées ont déclaré que les renseignements qualifiés sur les menaces en temps réel sont généralement coûteux à recevoir ou à partager. Ils pensent que ces renseignements sont principalement dédiés aux grandes organisations. Pourtant, les fournisseurs tiers offrent généralement un rabais à leurs abonnés à la plateforme CTI pour leur volonté de partager des informations sur les menaces en plus de leur consommation (Piper 2013). L’instinct naturel des organisations de ne pas partager est un autre problème qui freine le partage (Ring 2014). Dans certaines organisations, il y existe encore la culture de blâme (c’est-à-dire que si quelque chose arrive, alors c’est évidemment la faute de quelqu’un et il/elle doit en payer le prix). Ainsi, les gens sont naturellement réticents à annoncer très largement un incident. La nature changeante des cyberattaques, qui sont de plus en plus personnalisées, est mise en évidence (Ring 2014). Même si les organisations réussissent à partager des données sur une attaque, surtout lorsque ces organisations sont ciblées par un adversaire donné (voir l’exercice Waking Shark II (Keeling 2013)), la question des attaques personnalisées ne permet pas une bonne défense/prévention. Les besoins en matière d’intelligence sont dans ce cas différents. L’ignorance de l’organisation victime d’un cyberincident est une autre raison de ne pas partager l’information sur la menace (Choo 2011). Lorsqu’on leur a posé la question,

La Cyber Threat Intelligence et son évolution

23

les analystes ont indiqué qu’ils n’avaient jamais vécu de tels incidents. Pourtant, l’organisation a été attaquée une ou plusieurs fois. Le fait de croire qu’il y a peu de chances que les poursuites aboutissent (Choo 2011) décourage les organisations de signaler un incident aux organismes d’application de la loi et autres organismes compétents. Il convient de noter que certaines de ces préoccupations ont été apaisées par de récentes mesures gouvernementales (Peretti 2014) via des règles juridiques plus souples. Toutefois, dans tous les cas, les organisations devraient comprendre les risques potentiels associés à l’échange de CTI et prendre des mesures pour atténuer ces risques. La bonne nouvelle, c’est que les organisations font des progrès dans le partage des renseignements sur les menaces. La question est maintenant de savoir quelle est l’utilité de ces renseignements techniques sur les menaces partagées (threat sharing) et pendant combien de temps resteront-elles utiles d’être signalées ou bloquées par les moyens de sécurité ? 1.6. Limites du renseignement technique sur les menaces Alors qu’il y a dix ans, personne d’autre que les organismes gouvernementaux ne parlait de CTI, comme le montre la figure 1.3, les organisations qui cherchent à obtenir des renseignements techniques TTI sont maintenant submergées par une quantité massive de données sur les menaces (Chismon et Ruks 2015 ; Zurkus 2015), ce qui les place face à l’énorme défi de déterminer ce qui est réellement pertinent. Ainsi, un problème de quantité s’est développé. 1.6.1. La quantité avant la qualité La plupart des équipes de sécurité ne peuvent pas utiliser les données de menace qui les concernent d’une manière profitable parce qu’il y en a tout simplement beaucoup. Le déversement quotidien d’indicateurs jugés suspects sur Internet fournit des informations sur près de 250 millions d’indicateurs de compromission par jour (Trost 2014). La puissance cérébrale nécessaire pour analyser les données de menace à la vitesse à laquelle elles sont produites n’est donc pas humainement possible (Zurkus 2015). L’actualité de l’information est également très importante lorsqu’il s’agit de se protéger contre les attaquants agressifs et les exploits des zero-day. Selon Ponemon (2013), 57 % des professionnels de l’informatique interrogés déclarent qu’actuellement, les renseignements sur les menaces à la disposition de leurs

24

Cybervigilance et confiance numérique

entreprises sont souvent dépassés, ce qui les empêche de comprendre les motivations, stratégies et tactiques actuelles des attaquants et de les localiser. Dans une enquête plus récente menée auprès de professionnels des IT (Ponemon 2014), les auteurs signalent que la plupart des informations sur les menaces reçues par les professionnels des IT n’étaient pas suffisamment précises ou opportunes (c’est-à-dire qu’elles ne pouvaient faire l’objet d’une action ou mesure de sécurité) pour répondre aux besoins perçus. Enfin, selon une enquête plus récente (Ponemon 2015), les renseignements sur les menaces doivent être opportuns et faciles à prioriser. Dans cette dernière enquête, 66 % des répondants qui ne sont que quelque peu ou pas du tout satisfaits par les approches actuelles expliquent que l’information n’est pas opportune. D’autre part, 46 % se plaignent que l’information sur les menaces n’est pas classée selon les types de menaces. C’est ce qu’a démontré Ring (2014) en expliquant que les renseignements de qualité sur les menaces en temps réel sont généralement coûteux ; autrement, la plupart des produits commerciaux et de source ouverte disponibles ne sont pas assez efficaces ou ne fournissent pas de renseignements à jour. 1.6.2. Limites propres aux indicateurs de compromission (IOC) Examinons maintenant plus en détail les limites de chaque type d’indicateur de compromission tel que catégorisé à la section 1.3.3. Ces types d’IOC connus comme TTI sont les suivants : indicateurs liés au réseau, indicateurs basés sur l’hôte et indicateurs liés au courrier électronique. 1.6.2.1. Indicateurs liés au réseau Un certain nombre d’indicateurs de compromission liés au réseau peut être collecté en tant que TTI (section 1.3.3). Dans certains cas, les attaquants utilisent différents nœuds du réseau pour attaquer une victime ciblée. Dans d’autres cas, ils utilisent le même nœud pour plusieurs victimes. Ainsi, une adresse IP qui a été observée fonctionnant comme un nœud C&C (Command and Control) peut être un indicateur utile à partager (section 1.2.2.1 pour plus de détails). Cependant, les attaquants utilisent souvent des adresses IP différentes, changeant les nœuds C&C au fur et à mesure qu’ils sont découverts ou lorsque les ordinateurs victimes deviennent indisponibles. En ce qui concerne les noms de domaine, un logiciel malveillant tentera de se connecter à un nom de domaine, qui pourra alors être dirigé vers l’adresse IP que l’attaquant utilise actuellement. Il est également considéré comme un indicateur utile lorsqu’un logiciel malveillant utilise un domaine codé en dur. Cependant, il est assez courant pour les logiciels malveillants d’utiliser un algorithme de génération de domaine pour éviter d’avoir à se connecter deux fois au même domaine. Dans un tel cas, un nom de domaine a peu de valeur en tant qu’IOC (Chismon et Ruks 2015). Un détail frappant dans le rapport de Verizon (2015) illustre la valeur de ces indicateurs.

La Cyber Threat Intelligence et son évolution

25

Les expériences les plus importantes menées dans ce rapport consistent à déterminer (1) l’unicité cumulative des adresses IP (c’est-à-dire le chevauchement entre les flux d’adresses IP), (2) le temps nécessaire pour qu’une attaque se propage d’une victime à une autre et (3) la validité temporelle de l’adresse IP. 1.6.2.1.1. Observations sur l’unicité cumulative Pendant six mois, Niddel (Pinto et Sieira 2015) a combiné les mises à jour quotidiennes de 54 sources différentes d’adresses IP et de noms de domaine considérés comme malveillants par leur agrégateur de flux TIQ-Test (Niddel Corp. 2014). L’entreprise a ensuite procédé à une agrégation cumulative (c’est-à-dire que si deux flux différents mentionnaient le même indicateur au cours de la période expérimentale de six mois, ils seraient considérés comme se chevauchant sur cet indicateur spécifique). Pour ajouter un certain contexte aux flux d’indicateurs recueillis, Niddel les a séparés en groupes de flux entrants (c’est-à-dire des informations sur les sources réalisant des activités de scan et de spam/hameçonnage) et de flux sortants (c’est-àdire des informations sur les destinations qui servent soit à exploiter des kits ou des binaires de malware, soit même des emplacements des serveurs C&C). Les résultats montrent un chevauchement significatif seulement dans les flux entrants, ce qui est en quelque sorte prévisible, car chaque flux est examiné et scanné en permanence. Cependant, bien que chaque flux soit généralement soumis aux mêmes menaces, le chevauchement dans les flux sortants est étonnamment faible, même avec une longue période d’exposition de six mois. Ce résultat suggère que soit les attaquants utilisent un grand nombre d’adresses IP (c’est-à-dire que les organisations auraient besoin d’avoir accès à tous les indicateurs de TTI pour que l’information soit utile, ce qui est une tâche très difficile), soit seulement une minorité des adresses IP contenues dans les flux ont une valeur de renseignement. Il est probable que la vérité est un mélange des deux explications (voir l’expérience dans les observations de validité temporelle). 1.6.2.1.2. Observations sur le temps de propagation Les expériences sur les attaques observées par RiskAnalytics (Verizon 2015) montrent des résultats assez intéressants et stimulants : 75 % des attaques se propagent de la victime 0 à la victime 1 en 24 heures et plus de 40 % touchent la deuxième organisation en moins d’une heure. Ces conclusions ont exercé une forte pression sur la communauté de la sécurité pour qu’elle collecte, examine et distribue les IOC très rapidement afin d’optimiser une préparation collective. Supposons que les indicateurs sont partagés assez rapidement pour aider les victimes potentielles subséquentes. La prochaine question à laquelle il faut répondre est celle de savoir pendant combien de temps on peut s’attendre à ce que ces indicateurs restent valides (c’est-à-dire malveillants, actifs et méritent d’être signalés ou bloqués).

26

Cyb bervigilance et confiance c numérrique

1.6.2.1.3. Observations sur la va alidité temporelle RiskA Analytics a éttudié la questtion de la vallidité des adreesses IP. La figure 1.4 montre laa durée pendaant laquelle la plupart des ad dresses IP sonnt restées sur laa liste des blocs/aleertes. L’observvation sur la fiigure 1.4 est liimitée à sept jours de flux dd’adresses IP « malvveillantes » dee destination (cc’est-à-dire à partir p d’un fluxx sortant).

Figu ure 1.4. Nomb bre d’indicateu urs par jour tel qu’observé ch hez Verizon (2 2015) dans au u moins un flu ux d’IOC

Bien que certainees adresses IP P restent valiides comme étant « malveeillantes » pendant un certain teemps, la pluppart ne durentt même pas un jour. Ces résultats concordeent bien avecc les observattions sur l’un nicité cumulaative de Nidddel, où le chevauchhement des fllux sortants esst très faible. Selon Verizoon (2015), cess résultats reflètent un besoin urrgent de partaage rapide : « Théoriquemeent, le plus raapidement vous parrtagerez, le pluus possible voous arrêterez une u attaque. » Rappelons quu’il s’agit de résultats provenant d’une source de données qu ui est axée surr des menaces de nature mple, le brutef eforcing et less exploits opportunniste, voluminneuse et volattile (par exem d’applicaations web), plutôt p que surr des attaquess ciblées et pllus lentes. Daans le cas d’attaquees ciblées, il n’est n pas toujouurs utile de paartager les IOC C plus rapidem ment (voir discussioon dans la secttion 1.8). 1.6.2.2. Indicateurs basés sur l’h hôte : indicatteurs sur les malwares Une sophisticationn croissante daans l’évolution n des logicielss malveillants dits aussi malwarees a été constattée (Choo 20111). Sachant qu ue les logiciells malveillantss modifiés ne nécesssitent pas beeaucoup de compétences ou o de ressourrces, les attaqquants les

La Cyber Threat Intelligence et son évolution

27

réutilisent pour rester en tête de l’industrie anti-malware et des professionnels de la sécurité. Ils adaptent leurs « produits » au fil du temps, en utilisant différentes techniques d’obscurcissement. Il suffit simplement de changer un seul bit dans le binaire du logiciel malveillant, et un hachage différent du malware sera obtenu. Les attaquants peuvent utiliser des outils open source et faire des modifications plus complexes pour changer les hachages. Le kit de création de logiciels malveillants Zeus est un exemple de boîte à outils facile à utiliser. Il peut être acheté ou trouvé gratuitement sur certains forums clandestins (Falliere et Chien 2009) avec des instructions détaillées sur la façon d’utiliser ce kit. Toute personne, y compris une personne ayant des compétences limitées en programmation ou en piratage informatique, peut utiliser ces kits pour créer des logiciels malveillants sophistiqués ou les adapter à ses propres besoins et lancer des attaques avancées. Une étude réalisée par Symantec (Fossi et al. 2010) a montré près de 90 000 variantes uniques de la boîte à outils de base Zeus en 2009, qui était la deuxième famille de nouveaux codes malveillants la plus observée dans la région Asie-Pacifique/Japon cette année-là. La disponibilité généralisée d’une telle boîte à outils facilite la cybercriminalité. Par conséquent, il y a une augmentation marquée du nombre de cyberattaquants amateurs qui gagnent de l’argent de poche en distribuant des spams ou en vendant des identifiants et informations volés (Choo 2011). Les indicateurs tels que les clés de registre créées ou les artefacts de fichiers peuvent être plus utiles pour la CTI, car ils sont moins souvent modifiés par les attaquants, même s’il est toujours possible de donner aux fichiers déposés une composante aléatoire ou pseudo-aléatoire dans leurs noms. 1.6.2.3. Indicateurs liés aux courriers électroniques Un grand nombre d’attaques commencent par une attaque d’hameçonnage ou de spear phishing, contenant soit un exploit de document, soit simplement un malware déguisé en quelque chose de bénin. Ainsi, les indicateurs liés au courrier électronique peuvent fournir des renseignements utiles sur les menaces. Les attaquants s’assurent souvent que les emails sont ciblés ou génériques (Choo 2011). Il sera moins utile de partager des flux généralistes de sujets de spam que des détails sur les emails d’hameçonnage envoyés à des organisations spécifiques. 1.7. Bibliothèques ou plateformes de Cyber Threat Intelligence Un concept apparu récemment est l’utilisation de bibliothèques de CTI, aussi appelées plateformes de renseignements sur les menaces (Poputa-Clean et Stingley 2015). Les plateformes de renseignements sur les menaces produisent des données et de l’information que les analystes humains peuvent utiliser pour produire des renseignements exploitables sur les menaces (RecordedFuture 2017). Ces bibliothèques résolvent

28

Cybervigilance et confiance numérique

les problèmes de collecte et de stockage des TTI et facilitent le partage avec d’autres organisations dans le domaine de la CTI. Elles permettent également à une organisation de détecter les attaques dans les journaux et les captures de paquets. Ces bibliothèques stockent notamment des indicateurs et recherchent des liens entre eux (Chismon et Ruks 2015). Il s’agit généralement de grands dépôts d’archives qui utilisent souvent des technologies de Big Data (par exemple, pour l’analyse de graphiques et les entrepôts de données) pour établir des liens entre les types de TTI, ce qui permet une réaction plus rapide aux menaces détectées, suivie de l’enregistrement des IOC pour les données historiques. La bibliothèque de CTI pourrait être considérée comme le système de référence des IOC (Poputa-Clean et Stingley 2015) puisqu’elle permet au défenseur non seulement de suivre un événement observable (par exemple la somme de contrôle d’un fichier ou d’une signature), mais aussi de l’enrichir (par exemple par des métadonnées sur le fichier, des notes, des compagnies utilisant le fichier lui-même et sa source). Ainsi, la sécurité de l’organisation ne dépend plus du fait d’avoir déjà vu la menace auparavant. L’organisation peut ainsi évaluer n’importe quel trafic provenant de la base de connaissance collective (Williamson 2016) de toutes les menaces qui l’ont précédé. 1.7.1. Avantages des bibliothèques de Cyber Threat Intelligence basées sur le Cloud Le Cloud est considéré comme l’endroit idéal pour héberger la bibliothèque de CTI, car le Cloud offre des capacités de calcul, de stockage et de distribution pour prendre en charge les gros traitements de données utilisés par cette bibliothèque. La bibliothèque de CTI fait partie d’un système de renseignements sur les menaces dans le Cloud (Lightcyber 2016), qui est constamment mis à jour avec les récentes données des IOC. Le résultat attendu est qu’une fois qu’une entité a détecté une nouvelle menace dans son état d’attaque initial, toutes les autres entités connectées au système sont protégées en quelques minutes. Beaucoup appellent ce phénomène, l’immunité collective (Piper 2013). Cependant, les organisations devraient définir le modèle de déploiement dans le Cloud qu’elles veulent utiliser pour être en sécurité et en confiance. Qu’elles soient privées ou publiques, les bibliothèques de menaces automatisent à long terme certaines activités d’analyse (Trost 2014). Leurs avantages se manifestent au bout de quelques mois ou années, lorsque les organisations peuvent automatiser l’ingénierie inverse en utilisant des techniques d’apprentissage automatique. Par exemple, ces bibliothèques permettent d’avoir des informations associées à un groupe donné d’attaquants et de donner son évolution, ou de savoir si les attaquants apprennent de leurs erreurs, ou de savoir si les attaquants changent leur TTP et de construire un profil d’attaquant. De plus, ces bibliothèques permettent un usage opérationnel, ce qui aide à définir les meilleures métriques en déterminant quelle est la

La Cyber Threat Intelligence et son évolution

29

meilleure source de CTI pour l’organisation (c’est-à-dire les sources privées, les sources commerciales, OSINT) et qui donne le meilleur pool d’informations pour y consacrer du temps et des ressources. Aujourd’hui, plusieurs projets open source et entreprises commerciales gagnent en popularité en tant que plateformes de TTI spécifiquement, car ils offrent un stockage plus organisé des IOC et un contexte amélioré autour des alertes (Poputa-Clean et Stingley 2015). Les bibliothèques open source de renseignements les plus importantes sont évaluées à la section 1.9. 1.7.2. Réticence à utiliser les services du Cloud Il est difficile de nier les avantages des services du Cloud pour héberger des données et des réseaux de renseignements sur les menaces. Toutefois, de nombreuses entreprises sont encore mal à l’aise avec l’idée d’une infrastructure dans le Cloud. Même si certains fournisseurs publics de Cloud dédient une infrastructure et des services à leurs clients, offrant un Cloud privé virtuel, ces entreprises veulent stocker leurs données liées à la CTI dans un data center privé où elles contrôlent à tout moment où leurs données résident et avec qui elles sont partagées. Certaines organisations, telles que celles des secteurs de la santé et des services financiers, traitent des données qui nécessitent une sécurité plus avancée que ce que les fournisseurs de Cloud peuvent offrir. Certaines ont aussi un problème de visibilité. Dans ce cas, l’intégration d’une solution de Cloud privé interne facilite la connexion et l’interaction avec d’autres organisations. Cela pourrait être considéré comme une simple extension du data center de l’entreprise qui permet aux données internes et externes sur les menaces (c’est-à-dire OSINT, autres partenaires) d’ajouter un contexte et une pertinence à l’IOC, tandis que les données les plus sensibles restent protégées derrière le pare-feu de l’entreprise. Enfin, les problèmes de confiance restent souvent les plus difficiles à surmonter pour les responsables informatiques lorsqu’il s’agit de décider s’il convient ou non d’intégrer la CTI dans une solution Cloud gérée par un fournisseur tiers. En fait, la confiance est difficile à quantifier. Cela dépend des besoins spécifiques de l’organisation, de la réputation globale et de la localisation du fournisseur de Cloud (par exemple, européen ou non, pour des raisons réglementaires), et des types d’accords du niveau de service à avoir (OrbIT-Peaple 2016). 1.8. Discussion 1.8.1. L’insuffisance de partager rapidement Comme nous l’avons vu précédemment, une variété de fournisseurs de sécurité notamment de logiciels libres proposent un large assortiment de flux des derniers

30

Cybervigilance et confiance numérique

indicateurs de compromission (Williamson 2016). L’idée qui sous-tend ces flux d’IOC est généralement la même. Alors que les pirates informatiques agissent de plus en plus rapidement, les fournisseurs de sécurité trouvent un moyen de regrouper et de partager rapidement les IOC des menaces les plus récemment identifiées (threat sharing). L’actualité (fraîcheur) de l’information sur les menaces est très importante lorsqu’il s’agit de se protéger contre les attaques agressives et les exploits des vulnérabilités zeroday, mais dans de nombreux cas, les flux de menaces de la TTI peuvent simplement équivaloir à des signatures partagées rapidement qui ne parviennent toujours pas à identifier une attaque. En fait, l’un des principaux freins pour une couverture complète des IOC est qu’il est relativement simple pour un attaquant de cibler une organisation spécifique d’une manière qui garantit l’absence d’indicateurs préexistants. Par exemple, des indicateurs spécifiques sur le réseau ne peuvent être utilisés qu’une seule fois dans le cas d’une véritable attaque ciblée. En outre, un pourcentage élevé de logiciels malveillants exploitant des brèches est propre à l’organisation infectée (Shackleford 2015 ; Verizon 2015). De toute évidence, si un IOC n’est utilisé qu’une seule fois, comme dans le cas d’attaques ciblées, un partage plus rapide de ces IOC ne résoudra pas à lui seul le problème. En fait, les attaques ciblées nécessitent également une défense ciblée (Chismon et Ruks 2015). Pour se défendre contre cette nouvelle tendance aux attaques personnalisées, les entreprises doivent se concentrer non seulement sur la collecte et le partage des données sur les menaces dans l’ensemble de leur secteur d’activité, mais aussi sur leur analyse individuelle des menaces et leur réaction aux incidents (Ring 2014). Évidemment, ils ne peuvent pas se protéger s’ils ne savent pas contre quoi ils se protègent et qui sont leurs adversaires (Pepper 2015 ; Zurkus 2015). Pour répondre à ce besoin, un audit interne devrait être effectué régulièrement afin de comprendre les vulnérabilités internes et externes de l’organisation. L’objectif est de mettre en évidence des hypothèses sur ce que l’attaquant peut faire afin d’obtenir une réponse initiale, et anticiper cela en investiguant sur les outils internes et les attaques spécifiques. 1.8.2. Réduire la quantité de flux d’indicateurs de compromission L’autre préoccupation importante concerne les grandes quantités d’IOC vendues en tant que TTI qui manquent d’informations contextuelles. Certes, tout ce qui mène à la découverte d’un incident en vaut la peine, mais dans la plupart des cas, le contexte est essentiel. Le contexte supplémentaire inclut le rôle de l’indicateur de compromission, l’étape de l’attaque dans la structure de kill chain, l’origine du MD5, la famille du malware et/ou le groupe d’adversaires (Trost 2014). Par exemple, l’ajout du contexte dans lequel les attaques précédemment détectées ont eu lieu permet à un public plus large de se doter d’une capacité défensive. Le cœur du problème est que la grande majorité de l’information incluse dans les flux d’IOC est faite pour répondre à une

La Cyber Threat Intelligence et son évolution

31

question et pour un test ou situation particulière. Si la question est modifiée, les données ne seront plus utiles (Williamson 2016). Dans ce cas, l’indicateur est atomique et n’a aucune valeur à être partagé et enrichi avec d’autres. Face à ce défi, les solutions suivantes pourraient être envisagées. Les équipes de sécurité doivent contextualiser les données sur les IOC qu’elles recueillent avec les vulnérabilités et les faiblesses internes spécifiques (Bellis 2015). Pour ce faire, ils doivent sélectionner les données qu’ils collectent ou construire/sous-traiter des plateformes d’analyse pour faire face à la quantité de données. Il y a des équipes dévouées et massives, qui « nettoient les résultats du net », examinent les attaques ciblées, analysent la cible et essaient de trouver des associations. Ce processus peut également être automatisé à l’aide de techniques d’intelligence artificielle. Par exemple, les approches de traitement du langage naturel (NLP) sont utilisées pour extraire et filtrer uniquement les informations pertinentes depuis des sources de données non structurées, alors que les approches d’apprentissage automatique (machine learning) sont utilisées pour construire une base de connaissances qui sera capable d’inférer de nouvelles relations (c’est-à-dire des associations) entre les entités existantes ou de prédire de nouveaux événements. Dans le même ordre d’idées, il est suggéré dans Ring (2014) d’utiliser des services de sécurité managés (Managed Security Services), car un nombre croissant d’organisations commencent à externaliser cette activité. En ce qui concerne l’énorme flux de variantes de malwares qui accèdent aux réseaux et aux systèmes informatiques ou qui atteignent les honeypots (pots de miel) des organisations, il est impossible de les traiter individuellement. Il est essentiel d’identifier les mutations des variantes de ces malwares afin de reconnaître celles qui appartiennent à la même famille. La science des données et les modèles d’apprentissage automatique cherchent à offrir de toutes nouvelles techniques de rechercher ces logiciels malveillants. Au lieu d’adopter une approche 1 pour 1 où chaque IOC de malware est associé à une signature, les modèles de science des données analysent un grand nombre de malwares, pour apprendre ce qu’ils ont en commun. Ces méthodes d’analyse, de détection, de classification et de clustering des logiciels malveillants devraient être soit automatisées, soit conçues de manière à permettre une automatisation future (Ghanaei et al. 2016). En ce qui concerne les nouveaux travaux de recherche, Ghanaei et al. (2016) proposent une méthode d’apprentissage supervisé basée sur des statistiques pour classer les nouvelles variantes de malwares dans leurs familles connexes de logiciels malveillants. Dans le même ordre d’idées, VirusBattle (Miles et al. 2014) est un prototype qui utilise des analyses de malwares de pointe pour découvrir automatiquement les interrelations entre les instances de ces logiciels malveillants. Cette solution analyse les interrelations entre les malwares sur de nombreux types d’artefacts, y compris les binaires, les codes, les comportements dynamiques et les métadonnées des malwares. Le résultat est un

32

Cybervigilance et confiance numérique

graphique d’interrelation des malwares. Cuckoo (Guarnieri et al. 2016) et Malheur (Rieck 2013) sont des plateformes open source bien connues qui automatisent l’analyse de fichiers malveillants dans un environnement Sandbox. Cuckoo utilise à la fois une analyse statique (analyse binaire ou de code) et une analyse dynamique (analyse comportementale) (Oktavianto et Muhardianto 2013) alors que Malheur utilise une analyse dynamique. Pour identifier une famille de malwares à l’aide de Cuckoo, on peut créer des signatures personnalisées qui peuvent être exécutées contre les résultats d’une analyse afin d’identifier un modèle prédéfini qui pourrait représenter un comportement malveillant particulier. Pour ce faire, un spécialiste doit examiner les résultats et classer les échantillons analysés. Par ailleurs, Malheur utilise l’apprentissage automatique pour collecter des données d’analyse comportementale dans les rapports de Sandbox et classe les malwares en groupes similaires appelés clusters (Rieck et al. 2011). Malheur s’appuie sur le concept d’analyse dynamique, ce qui signifie que les binaires des malwares sont collectés dans la nature, puis exécutés. L’exécution de chaque binaire malveillant donne lieu à un rapport de comportement enregistré. Malheur analyse ces rapports pour la découverte et la discrimination des classes de malwares à l’aide de l’apprentissage automatique. Des Sandbox publics bien connus tels que Cuckoo et Malheur sont désormais hautement détectables par les malwares qu’ils analysent (Issa 2012 ; Ferrand 2015). Une fois que ces systèmes sont rendus publics, les auteurs de malware tentent de se protéger et d’échapper à la détection en vérifiant s’ils se trouvent dans un environnement émulé ou réel (par exemple, en vérifiant le temps d’exécution). Pour faire face à ce problème, de nouvelles recherches sont en cours. Par exemple, dans Ferrand (2015), l’auteur montre qu’avec quelques modifications et astuces sur Cuckoo et la machine virtuelle, il est possible d’empêcher les malwares de détecter s’ils sont analysés, ou du moins de rendre cette détection difficile. 1.8.3. Confiance dans le partage des indicateurs de compromission Un partage efficace exige la confiance. Étant donné que les informations partagées sur les menaces peuvent être sensibles (par exemple, révéler qu’une organisation a été attaquée), les organisations hésiteront à partager ces indicateurs de compromission lorsqu’elles ne se trouvent pas dans un environnement de confiance. Des études menées sur le coût économique du partage des données de sécurité ont démontré que le partage peut entraîner une perte dans le marché due à une publicité négative (Campbell et al. 2003 ; Cavusoglu et al. 2004). Pour éviter de telles conséquences, les techniques de contrôle d’accès granulé et contextuel sont essentielles pour protéger la confidentialité et la vie privée des données (Tounsi et al. 2013). Les données sur les menaces partagées pourraient également être contaminées par des activités malveillantes et contenir des informations erronées. Dans un tel cas, l’établissement de la confiance

La Cyber Threat Intelligence et son évolution

33

nécessite au moins l’authentification des transmissions et le chiffrement du contenu. Enfin, pour éviter les conséquences de la révélation d’identité, le partage anonyme est une autre solution qui offre aux participants un canal de communication anonyme. Dans un travail récent (Dunning et Kresman 2013), les auteurs ont développé un algorithme pour partager anonymement des données privées entre les participants. La confiance est également importante à un autre niveau. Il n’est généralement pas d’utilité de permettre aux acteurs de la menace d’apprendre ce que vous savez d’eux, de crainte qu’ils ne changent leurs méthodes. Ainsi, des groupes fermés et de confiance peuvent permettre un partage de connaissances plus renforcé qui ne serait pas envisageable autrement. En général, plus un groupe peut faire confiance à ses membres et à la sécurité de l’information au sein du groupe, plus le partage tend à être efficace (Chismon et Ruks 2015). Toutefois, un certain niveau de confiance dans le groupe doit être garanti. Si un participant estime que la consommation de l’information sur la menace est supérieure au taux de partage sur le réseau, la motivation à partager l’information diminuera rapidement. Pour résoudre ce problème, des travaux de recherche ont été entrepris. Dans Cascella (2008), l’approche de la théorie des jeux utilisant le dilemme du prisonnier est utilisée pour modéliser les interactions des nœuds rationnels et égoïstes dans les systèmes distribués. L’étude montre qu’en adoptant un système de réputation, il est possible de distinguer les bons joueurs (partageurs d’IOC) et les mauvais joueurs (consommateurs d’IOC). Seredynski et al. (2007) proposent un mécanisme de sanction qui prend la décision de rejeter ou de transférer des paquets basé sur un algorithme génétique dans un environnement évolutif. L’objectif est de renforcer la confiance entre plusieurs nœuds transmettant des paquets de données. Toutefois, dans les mécanismes de partage volontaire des IOC, le recours aux sanctions et aux punitions ne serait pas très intéressant. D’autres recherches ont montré qu’au lieu de punir, encourager un bon comportement augmente la probabilité que les participants soient plus impliqués dans un programme de partage à long terme. Par exemple, le fait de donner aux participants dans un réseau donné une approbation sociale peut impacter significativement le comportement coopératif (Cook et al. 2013). Il est également démontré que la participation des organisations au processus d’assurance de la qualité améliore la coopération entre les participants et augmente le niveau de confiance (Gerspacher et Lemieux 2010). Enfin, Furnell et ses co-auteurs (2007) concluent qu’il est possible d’obtenir un avantage concurrentiel de production de CTI pour toute partie utilisant le mieux les facteurs sociaux, notamment les relations humaines, sociales et organisationnelles qui sont pour la plupart inexplorées dans un programme de recherche en sécurité informatique. Par exemple, en supposant que les interactions face à face se produisent généralement dans un environnement de confiance (MITRE Corporation 2012), les contacts humains individuels peuvent être l’une des sources

34

Cybervigilance et confiance numérique

d’information sur les menaces les plus simples, tout en étant efficaces et fiables (Chismon et Ruks 2015). 1.8.4. Normes pour la représentation et le partage de la Cyber Threat Intelligence Le partage des connaissances en matière de sécurité entre experts est une contremesure essentielle aux attaques sophistiquées récentes, et les organisations peuvent bénéficier de l’expérience d’autres organisations pour construire un savoir collectif (Williamson 2016). Les organisations ont traditionnellement partagé l’information sur les menaces à l’aide de solutions ponctuelles ad hoc comme les appels téléphoniques, les emails chiffrés ou les systèmes de ticketing. Plus récemment, elles ont utilisé des portails et des blogs, une tendance à créer des communautés interconnectées avec des plateformes associées pour échanger de l’information sur les menaces de façon semi-automatique (Sillaber et al. 2016). L’analyse sémantique latente (LSA) (Landauer et al. 1998) a été utilisée pour trouver des sujets sémantiquement liés dans un corpus de blogs web. Des mots-clés importants de chaque sujet sont assignés à des mesures quantitatives par le biais d’une LSA probabiliste (PLSA) (Hofmann 1999). Les résultats prouvent l’efficacité de cette approche pour rechercher les actualités relatives à la sécurité dans les blogs web massifs. Cependant, cette approche est limitée en raison de la limitation des blogs web à représenter les scénarios de menace en temps réel et de façon structurée. Li et ses collaborateurs (2007) se concentrent sur le problème de l’identification des menaces réelles lorsque les données de sécurité du réseau sont gérées sur des sites répartis. Les auteurs proposent plusieurs moyens de trouver des corrélations entre les alertes provenant de composants distribués. La principale limite de ce travail est une fois de plus le manque de normalisation, car les données d’alerte doivent être converties en une représentation uniforme étant donné les multiples sources d’information des TTI. Un concept qui a émergé est l’utilisation de bibliothèques de CTI, aussi appelées plateformes de renseignements sur les menaces (Poputa-Clean et Stingley 2015). Ces bibliothèques ont été conçues pour résoudre les problèmes de collecte et de stockage des TTI et pour faciliter le partage des informations sur les menaces avec d’autres organisations. Toutefois, l’automatisation et la collecte efficaces à partir d’un ensemble diversifié de produits et de systèmes exigent une autre fois une représentation structurée et normalisée de l’information sur les menaces (Barnum 2014 ; Wagner et al. 2016), qui devrait être expressive, souple, extensible, exploitable par la machine et lisible par l’homme (Barnum 2014 ; Heckman et al. 2015). Plusieurs efforts ont été déployés pour faciliter le partage de l’information sur les menaces d’une manière normalisée. IODEF (Incident Object Description Exchange

La Cyber Threat Intelligence et son évolution

35

Format) (Danyliw et al. 2007), RID (Real-time Inter-network Defense) (Moriarty 2012), STIX (Structured Threat Information eXpression), TAXII (Trusted Automated eXchange of Indicator Information) (Barnum 2014), OpenIOC (Open Incident of Compromise) (Mandiant 2017), CybOX (Cyber Observable Expression) (MITRE 2017e), VERIS (Vocabulary for Event Recording and Incident Sharing) (Verizon 2017), CAPEC (Common Attack Pattern Enumeration and Classification) (MITRE 2017c), MAEC (Malware Attribution and Enumeration Characterization) (MITRE 2017b) et ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) (MITRE 2017a) sont des exemples populaires de ces efforts de normalisation. Malgré ces initiatives de normalisation, une enquête intéressante de SANS (Shackleford 2015) indique qu’en 2015, seulement 38 % des organisations utilisaient les données de CTI dans des formats standards ou à travers des boîtes à outils open source bien connues. Afin de choisir la bonne norme pour un cas d’utilisation particulier, Burger et ses collaborateurs (2014) fournissent un cadre agonistique dans lequel les normes peuvent être évaluées et validées. Dans ce qui suit, nous examinons brièvement les normes susmentionnées. STIX et TAXII sont apparus comme des initiatives d’amélioration de l’IODEF et du RID, où le RID et TAXII sont respectivement les protocoles de transport de l’IODEF et du STIX. Anciennement développés par la société MITRE, STIX et TAXII sont parrainés par le bureau de la cybersécurité et des communications du Department of Homeland Security (DHS). Ils ont été introduits pour combiner les données humaines et les données machine afin de partager l’information. Aujourd’hui, STIX est une norme couramment utilisée même si sa mise en œuvre est très complexe (Kampanakis 2014). STIX est modulaire et peut intégrer efficacement d’autres normes (Burger et al. 2014). L’architecture STIX est composée de huit concepts de base de cybermenaces : campagnes, indicateurs, observables, TTP (tactiques, techniques et procédures), incidents, ThreatActors, ExploitTargets et lignes de conduite. STIX peut intégrer CybOX, IODEF et certaines extensions OpenIOC, en plus d’XML namespaces, des extensions pour les règles YARA (Google Inc. et al. 2017), les règles de Snort (The Snort Team 2017) et les liaisons non XML, non-XML buindings (c’est-à-dire en utilisant JSON). STIX utilise CybOX comme représentation des observables. CybOX est un schéma pour la spécification, la capture et la caractérisation d’événements opérationnels observables. STIX peut également inclure IODEF à la place de l’extension IncidentType et OpenIOC à la place de CybOX, pour exprimer des modèles d’indicateurs non standards. Les espaces de noms XML que STIX peut intégrer sont MITRE CAPEC, MAEC et ATT&CK, pour n’en citer que quelques-uns. Les attributs du schéma CAPEC caractérisent la façon dont les cybermenaces sont exécutées et fournissent des moyens de se défendre contre ces menaces. Le schéma MAEC fournit un langage normalisé sur les

36

Cybervigilance et confiance numérique

logiciels malveillants basé sur les artefacts, les comportements et les modèles d’attaque. ATT&CK a été publié comme une structure de techniques d’adversaire post-compromis (Strom 2016). Il décrit des modèles pour caractériser le comportement d’un adversaire sur le réseau et les points finaux pour atteindre ses objectifs. Étant donné que CAPEC énumère une gamme de modèles d’attaque tout au long du cycle de vie de la cyberattaque (c’est-à-dire pas seulement les techniques utilisées pendant la période postcompromis), les références CAPEC ID sont ajoutées aux descriptions des modèles d’attaque dans ATT&CK. Pour les chercheurs de malwares utilisant YARA pour l’analyse d’expressions régulières ou pour les communautés dont l’intérêt est la détection d’intrusion utilisant Snort, STIX supporte des extensions pour YARA et les règles Snort (Kampanakis 2014). YARA est un moteur et un langage d’analyse (scan) de fichiers et de blocs de mémoire. Lorsqu’une règle correspond à un modèle ou une expression régulière, YARA présume de classer le sujet en fonction du comportement de la règle. Snort est un analyseur de paquets open source avec l’intelligence de faire correspondre des ensembles de règles et déclencher des actions lorsqu’il y a des correspondances d’expressions (Burger et al. 2014). Enfin, le système VERIS est une caractérisation des cyberincidents après leur survenance. Il est destiné à l’analyse des tendances stratégiques, à la gestion des risques et aux mesures. Ces multiples efforts pour obtenir différentes ontologies de données pour le partage de l’information sur les menaces ne sont pas sans inconvénients. Ces ontologies se chevauchent souvent et n’offrent pas de solution à l’ensemble de la communauté (Burger et al. 2014). Il pourrait y avoir des dédoublements et des lacunes dans les ontologies de l’information sur les menaces dans différentes communautés, ce qui mènerait à une duplication des efforts des participants pour une collaboration efficace. Il est donc nécessaire que les participants disposent d’un langage et d’un ensemble d’outils communs pour faciliter le partage et l’analyse des menaces. 1.8.5. Bibliothèques de Cyber Threat Intelligence basées sur le Cloud pour la connaissance collective et l’immunité 1.8.5.1. Utilisation de solutions de Cloud privé/communautaire Il n’y a pas de bonne ou de mauvaise réponse lorsque vous choisissez de maintenir la CTI dans le Cloud via un fournisseur tiers ou dans une solution collaborative privée. Les organisations peuvent trouver que certaines données de renseignements sur les menaces ont peu d’impact et sont relativement faciles à transférer dans le Cloud, alors que d’autres données plus critiques peuvent être mieux conservées sur place. Tout dépend de l’activité de l’organisation, des données qu’elle possède et du degré d’aisance avec lequel la tierce partie gère le risque de fuite de données.

La Cyber Threat Intelligence et son évolution

37

Le choix pourrait également se justifier pour des raisons financières. Le Cloud privé nécessite souvent d’importants investissements en capital qui couvrent la gestion de tous les systèmes, les applications de correctifs (patching) et les futures mises à niveau du matériel et logiciel qui sont autrement pris en charge par le fournisseur de la solution de Cloud public. Face à ce problème, la CTI basée sur le Cloud communautaire pourrait être la meilleure solution, car chaque organisation membre d’un Cloud communautaire peut héberger une partie, ou des applications, que toutes les organisations d’une communauté peuvent exploiter. Toutefois, il convient de noter que le déploiement du Cloud communautaire nécessite une relation profonde et à long terme entre les multiples organisations participantes afin de construire, de gouverner et d’opérer à partir d’un Cloud communautaire (Bond 2015). Enfin, de nombreux responsables techniques (Ellison 2014) préconisent un modèle hybride pour générer la CTI ou le renseignement lorsque les deux (Cloud privé et public) coexistent (Rouse 2015). Dans un tel cas, plusieurs fournisseurs de services privés/communautaires et/ou publics dans le Cloud pourraient s’interconnecter. 1.8.5.2. Être conscient des principales préoccupations en matière de sécurité sur le Cloud Certaines organisations de sécurité ont publié les résultats de leurs recherches sur les principaux problèmes de sécurité liés au Cloud afin d’aider les entreprises intéressées à rejoindre le Cloud et le stockage de données de sécurité. L’objectif est de les encourager à prendre une décision tout en étant pleinement conscients des risques associés. Cela encourage également les nouveaux clients à poser les questions appropriées et à envisager d’obtenir une évaluation de sécurité d’un tiers neutre avant de s’engager auprès d’un fournisseur de service Cloud (Khorshed et al. 2012). Depuis juin 2008, la firme de sécurité Gartner a publié un rapport (Heiser et Nicolett 2008) dans lequel elle identifie sept problèmes de sécurité spécifiques que les clients devraient soulever avec les fournisseurs avant de choisir un service basé sur le Cloud. Les problèmes spécifiques sont l’accès privilégié des utilisateurs, la conformité réglementaire, la localisation des données, la ségrégation des données, la récupération, le soutien aux enquêtes et la viabilité à long terme. En novembre 2009, l’Agence européenne chargée de la sécurité des réseaux et de l’information (ENISA) a publié un autre document de recherche sur les risques et les recommandations en matière de Cloud Computing (Catteddu et Hogben 2009), qui est jusqu’ici référencé par de nombreuses organisations et certifications (Cloud Security Alliance 2017a). Le document énumère huit risques importants et spécifiques au Cloud, à savoir : la perte de gouvernance, le verrouillage, l’échec de l’isolation, les risques de non-conformité, la compromission de l’interface de gestion, la protection

38

Cybervigilance et confiance numérique

des données, la suppression des données non sécurisée ou incomplète et les acteurs initiés malveillants. Le document a également discuté de la gestion des risques et formulé des recommandations. La Cloud Security Alliance (CSA) a publié, par l’intermédiaire du groupe de travail sur les principales menaces (Top Threats Working Group), ses plus récentes conclusions de recherche sur les principales menaces du Cloud en février 2016 (Cloud Security Alliance 2016). L’objectif est de fournir aux organisations une compréhension à jour et éclairée par des experts des problèmes de sécurité dans le Cloud afin d’identifier les principaux risques et de prendre des décisions éclairées en matière de gestion des risques concernant les stratégies d’adoption du Cloud. Dans la récente édition de leur rapport, les experts ont identifié les douze problèmes critiques suivants en matière de sécurité dans le Cloud, classés par ordre de gravité (suivant les résultats de leur enquête) : violations de données, identification faible, gestion des identifiants et des accès, API non sécurisées, vulnérabilité des systèmes et des applications, détournement de comptes, acteurs initiés malveillants, menaces permanentes avancées (APT), perte de données, diligence raisonnable insuffisante, abus et utilisation malsaine des services en Cloud, déni de service et problèmes de technologies partagées. Enfin, en décembre 2017, la CSA a publié la version 4.0 de ses lignes directrices sur la sécurité dans le Cloud, dans laquelle quatorze domaines de préoccupation sont identifiés et classés en six modules (Cloud Security Alliance 2017b). Il s’agit de : concepts et architectures du Cloud Computing ; la gouvernance et la gestion des risques d’entreprise ; les questions juridiques, les contrats et la découverte électronique ; la conformité et la gestion des audits ; la gouvernance de l’information ; le plan de gestion et la continuité d’activités ; la sécurité des infrastructures ; la virtualisation et les conteneurs ; la réponse aux incidents ; la sécurité applicative ; la sécurité des données et le chiffrement ; les identités, droits et gestion des accès ; la sécurité comme un service et les technologies connexes. Les documents sont rapidement devenus le catalogue standard de l’industrie des meilleures pratiques en matière de Cloud Computing sécurisé. L’objectif de tous ces travaux de recherche est d’aider les fournisseurs de Cloud Computing ainsi que leurs clients potentiels à identifier les risques majeurs et se décider de participer ou non à un programme de renseignement sur les menaces hebergé dans le Cloud, et à se protéger de manière proactive de ces risques. 1.9. Évaluation des outils de renseignement technique sur les menaces Maintenant que les organisations ont trouvé des moyens de recueillir d’énormes quantités d’informations à partir d’une grande variété de sources en utilisant des bibliothèques de menaces, elles ont besoin d’outils pour gérer le flux d’informations et

La Cyber Threat Intelligence et son évolution

39

le convertir en connaissances et en actions. Bien que les outils de CTI existants aient besoin d’être plus sophistiqués (Shackleford 2016), ils ont pu atteindre un niveau de maturité qui permet aux organisations de commencer à filtrer et partager l’information efficacement (Brown et al. 2015). Il existe plusieurs projets open source et entreprises commerciales qui offrent des produits permettant d’accéder aux renseignements sur les menaces et spécifiquement aux indicateurs de compromission, quand il d’agit d’information technique. Ces solutions visent principalement l’agrégation de contenu et la recherche collaborative comme IBM X-Force Exchange (IBM 2017), Alien-vault OTX Pulse (AlienVault 2007), Recorded Future (Pace et al. 2018) et Crowdstrike intelligence exchange (CrowdStrike Inc. 2014). D’autres solutions visent à fournir des options de gestion avancées des renseignements avec la possibilité d’avoir des instances privées. Il s’agit notamment d’EclecticIQ (ElecticIQ 2017), Threat-stream (Anomali 2017), ThreatQuotient (ThreatQuotient 2017), ThreatConnect (Threatconnect 2017), MISP (Andre et al. 2011), CRITS (MITRE 2017d), Soltra Edge (Soltra 2017), CIF v3 (également appelé beardedavenger) (CSIRT Gadgets 2016), IntelMQ (CERT/ CSIRT européens 2014) et Hippocampe (CERT Banque de France 2017). Nous nous concentrons sur les récents outils open source qui offrent des options de gestion avancées, notamment IntelMQ, Hippocampe et Threatelligence (Phillips 2014). Cette évaluation complète la discussion comparative précédente dans Tounsi et Rais (2018), où l’on trouve d’autres outils gratuits et/ou open source. 1.9.1. Présentation des outils sélectionnés Certains des outils susmentionnés ont commencé à gagner en popularité car ils promettent un stockage plus organisé des IOC et une analyse puissante de ces derniers. Nous citons comme exemples IntelMQ, Hippocampe et Threatelligence. Ces outils sont présentés et évalués selon différentes dimensions fonctionnelles (section 1.9.2). Les informations techniques relatives à ces outils proviennent de diverses sources : sites d’outils officiels, livres blancs, articles de recherche et interactions en direct avec certains des auteurs des outils. IntelMQ (European CERTs/CSIRTs 2014) est issu d’une initiative communautaire appelée IHAP (Incident Handling Automation Project) qui a été conceptuellement conçue par les unités CERT européennes lors de plusieurs événements InfoSec en 2014. La solution a été conçue pour les CERT afin d’améliorer les processus de traitement des incidents, en utilisant un protocole de file d’attente des messages, pour collecter et traiter les flux hétérogènes d’IOC, les tweets et les infos des pastebins (une

40

Cybervigilance et confiance numérique

application web permettant aux utilisateurs de mettre en ligne et publiquement du texte, habituellement des extraits de code source). Hippocampe (CERT Banque de France 2017) est un projet open source publié en 2016 par le CERT de la Banque de France. Il regroupe les flux provenant d’Internet dans un cluster ElasticSearch. Il permet aux organisations de l’interroger facilement via une API REST ou une interface web (Web User Interface). Il est basé sur un script Python qui récupère les URL correspondant aux flux d’IOC, les analyse et les indexe. Il s’inscrit dans le cadre du projet The Hive qui est conçu pour faciliter la vie des équipes SOC, CSIRT, CERT et de tout professionnel de la sécurité de l’information confronté à des incidents de sécurité. Threatelligence (Phillips 2014) est un collecteur d’informations sur les cybermenaces simple de conception, utilisant ElasticSearch, Kibana et Python. Il a été créé en 2014 par un développeur professionnel très impliqué dans la cybersécurité. Il récupère les données des IOC de diverses sources publiques ou personnalisées dans ElasticSearch tout en les enrichissant légèrement (c’est-à-dire en recherchant des lieux géographiques). Il met automatiquement à jour les flux et essaie d’améliorer les données pour les tableaux de bord. Les tableaux de bord construits à l’aide de Kibana sont utilisés pour afficher les données et faciliter les recherches. 1.9.2. Discussion comparative La maturation du marché encourage tous les fournisseurs de CTI et les initiatives open source à adopter un ensemble commun de fonctionnalités. Les caractéristiques importantes comprennent (Poputa-Clean et Stingley 2015) : (1) l’intégration avec d’autres outils de sécurité (par exemple via une API) ; (2) l’enrichissement des données (c’est-à-dire la possibilité d’intégrer d’autres plateformes de renseignement, par exemple MISP (Malware Information Sharing Platform) (Andre et al. 2011)) ; (3) l’intégration avec les autres outils créés par le même fournisseur et (4) l’existence de fonctions de partage de la CTI. Compte tenu des critères susmentionnés, nous axons notre évaluation sur la présence d’une API web, l’indexation avec MISP (en tant que flux OSINT de plus en plus standardisé), l’interaction avec d’autres outils du même fournisseur, le stockage et la mise à jour des IOC et les capacités d’avoir une interface web pour l’utilisateur (Web User Interface). Le tableau 1.4 résume cette évaluation.

La Cyber Threat Intelligence et son évolution

41

Critères/Outil

Hippocampe

IntelMQ

Threatelligence

État d’avancement du projet

Jeune Actif depuis 2016

Mature Actif depuis 2014

Jeune Inactif depuis 2014

Langue principale

Python

Python

Python

API web intégrée

Oui, disponible pour récupérer les IOC

Non

Non

Indexation du MISP

Non, pris en charge, mais dans la feuille de route

Un « Collector Robot » pour MISP est disponible

Non

Interaction avec d’autres produits du même fournisseur

Fonctionne parfaitement avec Cortex (analyseur CTI) et The Hive (outil de réponse aux incidents)

Non

Non

Aucune base de données requise : Utilise ElasticSearch : Stockage des IOC

– les IOC sont sauvegardés dans ElasticSearch ; – les IOC sont organisés par source de flux.

– utilisation de Redis1 pour mémoriser les données ; – les IOC sont stockés dans un fichier JSON par défaut. Chaque IOC d’une source correspond à un enregistrement JSON dans le fichier2.

Utilise ElasticSearch : – les IOC sont sauvegardés dans ElasticSearch ; – les IOC sont organisés par type d’attaque.

42

Cybervigilance et confiance numérique

Critères/Outil

Hippocampe

Mise à jour des IOC

Met à jour le champ « dernière apparition », si un ancien enregistrement de l’IOC apparaît de nouveau dans la base de données. Si un nouvel IOC est listé par deux sources de flux, l’IOC sera ajouté à ElasticSearch pour chaque flux

IntelMQ

Threatelligence

Ce n’est pas clair. Le bot « Deduplicator » pourrait filtrer tous les doublons IOC

S’il existe un même ancien IOC dans la base de données, il sera écrasé et un nouvel ajout sera considéré. Il n’y a pas de champ « première apparition » et « dernière apparition »

– Affiche les collecteurs – Affiche les IOC par type ou par flux Existence d’une interface web pour l’utilisateur

– Affiche l’état de fonctionnement de chaque collecteur de flux (dernière heure de fonctionnement, somme de tous les IOC obtenus, somme des nouveaux IOC)

– Montre un graphique des relations entre les IOC – Autorise l’ajout ou la suppression de robots avec l’interface utilisateur

Non appliqué

– Permet la surveillance et le contrôle des robots (démarrage, arrêt, rechargement, redémarrage, configuration)

1. https://redis.io/. 2. IntelMQ offre d’autres choix de stockage, tels que ElasticSearch et PostgreSQL. Tableau 1.4. Évaluation des outils de renseignement sur les menaces

1.10. Conclusion et travaux futurs Au fur et à mesure que les organisations se transforment numériquement et s’ouvrent vers le Cloud, les indicateurs de compromission (IOC) évoluent également. Ainsi, l’impact de la cybersécurité sur une organisation dépasse les limites classiques du domaine informatique technique. L’accès aux données, leurs liens avec les comptes

La Cyber Threat Intelligence et son évolution

43

de messagerie, les applications web et les documents stockés sur une variété de plateformes et d’appareils mobiles augmentent le besoin d’une organisation de protéger ses données. Nous avons vu que la Cyber Threat Intelligence (CTI), appelée le renseignement sur les cybermenaces, présente de nombreux avantages en ce qui a trait au soutien de plusieurs activités de sécurité. Découvrir des cyberattaques secrètes et de nouveaux logiciels malveillants (dits malwares), émettre des alertes précoces et distribuer de manière sélective les données relatives aux menaces ne sont que quelques-uns de ces avantages. Nous avons défini la CTI et montré la façon dont la littérature la subdivise. Nous nous sommes concentrés sur la Technical Threat Intelligence (TTI), qui est la forme de CTI la plus consommée à travers des IOC, ainsi que les principaux problèmes qui s’y rapportent. Nous avons constaté que, d’une part, l’actualité de l’information est très importante pour se protéger contre les exploits des vulnérabilités de type zero-day, et, d’autre part, le partage rapide des IOC n’est pas suffisant lorsqu’il s’agit d’attaques ciblées, car les indicateurs de compromission liés au réseau et à l’hôte ne sont utilisés qu’une seule fois par l’attaquant dans une véritable attaque ciblée. Dans ce cas, des défenses ciblées par les équipes de sécurité sont également à prévoir durant la collecte et le filtrage des données sur les menaces en se concentrant sur les vulnérabilités et les faiblesses internes de l’organisation à protéger. Nous avons examiné les nouveaux travaux de recherche, les tendances et les normes en vigueur afin d’atténuer les problèmes liés aux TTI et nous avons exposé les stratégies de partage les plus répandues, fondées sur la confiance et l’anonymat, afin que les organisations participantes puissent dépasser les risques de fuites d’information et de pertes commerciales. De toute évidence, plus un groupe peut faire confiance à ses membres, plus le partage d’informations sur les menaces tend à être efficace. Toutefois, avant de mettre en place une communauté de coo-pération interentreprises, il vaut la peine de tenir compte de certains facteurs communs liés aux processus opérationnels, à la stabilité et à la politique de coopération. Enfin, comme les données sur la sécurité sont partagées entre les participants, agrégées à partir de différentes sources et reliées à d’autres données déjà présentes dans les ensembles de données, la probabilité d’erreurs pourrait augmenter. Par conséquent, un format normalisé d’IOC et un vocabulaire commun pour la saisie de données supplémentaires minimisent les risques de perte de la qualité des données et permettent de meilleurs résultats quant à l’analyse automatisée des grands volumes de données de menace. Bien que la précision, le temps et l’extensibilité demeurent un besoin ultime pour la production d’IOC exploitables, les méthodes de collecte, de traitement et d’analyse de toutes sortes de renseignements ont toujours reposé en grande partie sur la capacité des humains à comprendre les références, à filtrer le bruit et à prendre une décision quant aux mesures à réaliser. La prolifération actuelle des cyberattaques sophistiquées et, par conséquent, le nombre considérable d’indicateurs de compromission fait qu’il est primordial d’automatiser au moins la collecte et le traitement des informations,

44

Cybervigilance et confiance numérique

compte tenu de la diversité des sources de données sur les menaces. L’intelligence artificielle est le meilleur candidat pour atteindre cet objectif, en particulier après l’avènement du Cloud qui a rendu l’accès aux capacités des super-calculateurs abordable et a ouvert la porte à l’intelligence artificielle appliquée pour résoudre des problèmes de plus en plus complexes. 1.11. Bibliographie Abuse.ch. (2017). Zeus Tracker [Online]. Available: https://zeustracker.abuse.ch [Accessed January 2017]. Ahrend, J.M., Jirotka, M., and Jones, K. (2016). On the collaborative practices of cyber threat intelligence analysts to develop and utilize tacit Threat and Defence Knowledge. International Conference on Cyber Situational Awareness, Data Analytics and Assessment (CyberSA), IEEE, 1–10. AlienVault (2007). AlienVault open threat exchange. [Online]. Available: https://www. alienvault.com/open-threat-exchange [Accessed January 2017]. Andre, D., Dereszowski, A., Dulaunoy, A., Iklody, A., Vandeplas, C., and Vinot, R. (2011). MISP: Malware Information Sharing Platform [Online]. Available: http://www. misp-project.org/ [Accessed January 2017]. Anomali (2017). [Online]. Available: https://www.anomali.com/product/threatstream [Accessed January 2017]. Barnum, S. (2014) Standardizing cyber threat intelligence information with the structured threat information expression (STIX). MITRE Corporation, 11, 1–22. Barraco, L. (2014). Defend like an attacker: Applying the cyber kill chain, [Online]. Available: www.alienvault.com/blogs/security-essentials/defend-like-an-attacker-applyingthe-cyber-kill-chain. Bellis, E. (2015). The problem with your threat intelligence. White paper, Kenna Security, July. Bipartisan Policy Center (2012). Cyber security task force: Public-private infor-mation sharing, National Security Program, July. Bond, J. (2015). Planning and Architecture. In The Enterprise Cloud [Online]. O’Reilly Media, Inc. Available: https://www.safaribooksonline.com/library/view/the-enter prise-Cloud/9781491907832/ch01.html.

Cette bibliographie est identique à celle de l’ouvrage correspondant en anglais publié par ISTE.

La Cyber Threat Intelligence et son évolution

45

Brown, S., Gommers, J., and Serrano, O. (2015). From cyber security information sharing to threat management. Proceedings of the 2nd ACM Workshop on Information Sharing and Collaborative Security, ACM, pp. 43–49. Burger, E.W., Goodman, M.D., Kampanakis, P., and Zhu, K.A. (2014). Taxonomy model for cyber threat intelligence information exchange technologies. Proceedings of the 2014 ACM Workshop on Information Sharing & Collaborative Security, ACM, pp. 51–60. Campbell, K., Gordon, L.A., Loeb, M.P., and Zhou, L. (2003). The economic cost of publicly announced information security breaches: Empirical evidence from the stock market. Journal of Computer Security, 11(3), 431–448. Cascella, R.G. (2008). The “value” of reputation in peer-to-peer networks. 5th IEEE Consumer Communications and Networking Conference, CCNC 2008, IEEE, 516–520. Catteddu, D. and Hogben, G. (2009). Benefits, risks and recommendations for information security. European Network and Information Security, November. Cavusoglu, H., Cavusoglu, H., and Raghunathan, S. (2004). How should we disclose software vulnerabilities. Proceedings of Workshop on Information Technology and Systems, pp. 243–248. CERT Banque de France (2017). Hippocampe [Online]. Available: https://github. com/TheHive-Project/Hippocampe [Accessed April 2018]. Chismon, D. and Ruks, M. (2015). Threat intelligence: Collecting, analysing, evaluating. MWR Infosecurity, UK Cert, United Kingdom. Choo, K.-K.R. (2011). The cyber threat landscape: Challenges and future research directions. Computers & Security, 30(8), 719–731. Choo, K.-K.R., Smith, R.G., and McCusker, R. (2007). Future Directions in Technology-enabled Crime: 2007–09. Australian Institute of Criminology, Canberra, Australia. Cloud Security Alliance (2016). The treacherous 12 – Cloud computing top threats in 2016 [Online]. Available: https://downloads.Cloudsecurityalliance.org/assets/ research/top-threats/Treacherous-12_Cloud-Computing_Top-Threats.pdf. Cloud Security Alliance (2017a). Certificate of Cloud security knowledge [Online]. Available: https://Cloudsecurityalliance.org/education/ccsk. Cloud Security Alliance (2017b). Security guidance for critical areas of focus in Cloud computing v4.0 [Online]. Available: https://downloads. Cloudsecurityalliance.org/ assets/research/security-guidance/security-guidance-v4-FINAL.pdf.

46

Cybervigilance et confiance numérique

Cook, K.S., Cheshire, C., Rice, E.R., and Nakagawa, S. (2013). Social exchange Theory. In Handbook of Social Psychology, DeLamater, J. and Ward, A. (eds). Springer. CrowdStrike, Inc. (2014). CSIX: CrowdStrike Intelligence Exchange [Online]. Available: https://www.crowdstrike.com/products/falcon-intelligence/. CSIRT Gadgets. (2016). Bearded-avenger (CIF v3) [Online]. Available: http:// csirtgadgets.org/bearded-avenger [Accessed February 2017]. Dalziel, H. (2014). How to Define and Build an Effective Cyber Threat Intelligence Capability. Syngress Publishing. Danyliw, R., Meijer, J., and Demchenko, Y. (2007). The Incident Object Description Exchange Format (IODEF). Internet Engineering Task Force (IETF), RFC-5070. Dshield (2017). [Online]. Available: https://www.dshield.org [Accessed January 2017]. Dunning, L.A. and Kresman, R. (2013). Privacy preserving data sharing with anonymous ID assignment. IEEE Transactions on Information Forensics and Security, 8(2), 402–413. ElecticIQ (2017). EclecticIQ Platform [Online]. Available: https://www.eclecticiq. com/platform [Accessed January 2017]. Ellison, L. (2014). Oracle Cloud and Your Datacenter Coexist. Oracle Media Network. ENISA: European Union Agency for Network and Information Security (2006). CERT cooperation and its further facilitation by relevant stakeholders. ENISA: European Union Agency for Network and Information Security (2013). Detect, SHARE, Protect – Solutions for improving threat data exchange among CERTs. ENISA: European Union Agency for Network and Information (2015). Cyber security information sharing: An overview of regulatory and non-regulatory approaches [Online]. Available: https://www.enisa.europa.eu/publications/cybersecurity-infor mation-sharing/at_download/fullReport. ENISA: European Union Agency for Network and Information (2017). ENISA threat landscape report 2016–15 top cyber threats and trends. European CERTs/CSIRTs (2014). IntelMQ [Online]. Available: https://github.com/ certtools/intelmq [Accessed April 2018]. Fadilpasic, S. (September 2016). Social media still an important tool for phishing. White paper, ITProPortal. Falliere, N. and Chien, E. (2009). Zeus: King of the bots. Symantec Security Response. Available: https://www.symantec.com/content/dam/symantec/docs/securitycenter/white-papers/security-response-zeus-king-of-bots-09-en.pdf.

La Cyber Threat Intelligence et son évolution

47

Ferrand, O. (2015). How to detect the cuckoo sandbox and to strengthen it? Journal of Computer Virology and Hacking Techniques, 11(1), 51–58. FireEye Inc. (2012). Advanced targeted attacks – How to protect against the next generation of cyber attacks. Technical report. FireEye Inc. (2014). Taking a lean-forward approach to combat today’s cyber attacks. Technical report. Fossi, M., Turner, D., Johnson, E., Mack, T., Adams, T., Blackbird, J., Entwisle, S., Graveland, B., McKinney, D., Mulcahy, J., and Wueest, C. (2010). Symantec global internet security threat report trends for 2009. White paper, symantec enterprise security, 15. Furnell, S., Clarke, N., Beznosov, K., and Beznosova, O. (2007). On the imbalance of the security problem space and its expected consequences. Information Management & Computer Security, 15(5), 420–431. Gerspacher, N. and Lemieux, F. (2010). A market-oriented explanation of the expansion of the role of Europol: Filling the demand for criminal intelligence through entrepreneurial initiatives. International Police Cooperation: Emerging Issues, Theory and Practice. Willan Publishing, Culompton. Ghanaei, V., Iliopoulos, C.S., and Overill, R.E. (2016). Statistical approach towards malware classification and detection. SAI Computing Conference, IEEE, pp. 1093–1099. Gilligan, J., Heitkamp, K., Dix, R., Palmer, C., Sorenson, J., Conway, T., Varley, W., Gagnon, G., Lentz, R., Venables, P., Paller, A., Lute, J.H., and Reeder, F. (2014). The economics of cybersecurity part II: Extending the cyber-security framework. Technical report, Armed Forces Communications and Electronics Association Cyber Committee. Google Inc., Bengen, H., Metz, J., Buehlmann, S., and Alvarez Yara V.M. (2017). [Online]. Available: http://virustotal.github.io/yara [Accessed July 2017]. Guarnieri, C., Tanasi, A., Bremer, J., and Schloesser, M. (2016). Cuckoo sandbox [Online]. Available: https://www.cuckoosandbox.org. Gundert, L. (2014). Producing a world-class threat intelligence capability. White paper, Recorded Future. Heckman, K.E., Stech, F.J., Thomas, R.K., Schmoker, B., and Tsow, A.W., (2015). Cyber Denial, Deception and Counter Deception. Springer.

48

Cybervigilance et confiance numérique

Heiser, J. and Nicolett, M. (2008). Assessing the security risks of Cloud computing [Online]. Available: https://www.gartner.com/doc/685308/assessing-security-risksCloud-computing. Hofmann, T. (1999). Probabilistic latent semantic indexing. Proceedings of the 22nd Annual International ACM SIGIR Conference on Research and Development in Information Retrieval, ACM, pp. 50–57. Holland R., Balaouras S., and Mak K. (2013). Five steps to build an effective threat intelligence capability. Forrester Research, Inc. Hugh, P. (2016). What is threat intelligence? Definition and examples [Online]. Available: https://www.recordedfuture.com/threat-intelligence-definition. Hutchins, E.M., Cloppert, M.J., and Amin, R.M. (2011). Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains. Leading Issues in Information Warfare & Security Research, 1, 80. IBM (2017). X-Force exchange [Online]. Available: https://exchange.xforce. ibmCloud.com [Accessed January 2017]. iSightPartners (2014). What is cyber threat intelligence and why do I need it? iSIGHT Partners, Inc. Issa, A. (2012). Anti-virtual machines and emulations. Journal in Computer Virology, 8(4), 141–149. Johnson, C.S., Badger, M.L., Waltermire, D.A., Snyder, J., and Skorupka, C. (2016). Guide to cyber threat information sharing. Technical report, NIST Special Publication. Kampanakis, P. (2014). Security automation and threat information-sharing options. IEEE Security & Privacy, 12(5), 42–51. Keeling, C. (2013). Waking Shark II – Desktop cyber exercise – Report to participants. Technical report. Khorshed, M.T., Ali, A.S., and Wasimi, S.A. (2012). A survey on gaps, threat remediation challenges and some thoughts for proactive attack detection in Cloud computing. Future Generation Computer Systems, 28(6), 833–851. Korstanje, M.E. (2016). Threat mitigation and detection of cyber warfare and terrorism activities. Advances in Information Security, Privacy, and Ethics (AISPE) 2016. Landauer, T.K., Foltz, P.W., and Laham, D. (1998). An introduction to latent semantic analysis. Discourse Processes, 25(2–3), 259–284.

La Cyber Threat Intelligence et son évolution

49

Li, Z.-T., Lei, J., Wang, L., Li, D., and Ma, Y.-M. (2007). Towards identifying true threat from network security data. Pacific-Asia Workshop on Intelligence and Security Informatics, Springer. Lightcyber (2016) Cloud based threat intelligence [Online]. Available: http://lightcyber. com/glossary/Cloud-based-threat-intelligence [Accessed January 2017]. Mandiant (2017) OpenIOC [Online]. Available: http://www.openioc.org [Accessed July 2017]. McMillan, R. (2013). Definition: Threat Intelligence. Gartner. Miles, C., Lakhotia, A., LeDoux, C., Newsom, A., and Notani, V. (2014). VirusBattle: State-of-the-art malware analysis for better cyber threat intelligence. 2014 7th International Symposium on Resilient Control Systems (ISRCS), IEEE, pp. 1–6. MITRE (2012). Cyber information-sharing models: An overview. Case no. 11-4486. MITRE (2017a). ATT&CK: Adversarial Tactics, Techniques & Common Knowledge [Online]. Available: https://attack.mitre.org/wiki/Main_Page [Accessed July 2017]. MITRE (2017b). MAEC: Malware Attribute Enumeration and Characterization [Online]. Available: https://maec.mitre.org [Accessed July 2017]. MITRE (2017c). CAPEC: Common Attack Pattern Enumeration and Classification [Online]. Available: https://capec.mitre.org [Accessed July 2017]. MITRE (2017d). CRITS: Collaborative Research Into Threats [Online]. Available: https://crits.github.io/ [Accessed January 2017]. MITRE (2017e). Cyber Observable eXpression [Online]. Available: http://cyboxproject. github.io [Accessed July 2017]. Moriarty, K.M. (2011). Incident coordination. IEEE Security & Privacy, 9(6), 71–75. Moriarty, K.M. (2012). Real-time inter-network defense (RID). Internet Engineering Task Force (IETF), RFC-6545. Murdoch, S., and Leaver, N. (2015) Anonymity vs. trust in cyber-security collaboration. Proceedings of the 2nd ACM Workshop on Information Sharing and Collaborative Security, ACM, pp. 27–29. National High Tech Crime Unit of the Netherlands police, Europol’s European Cybercrime Centre, Kaspersky Lab, Intel Security (2017). No more ransom project [Online]. Available: https://www.nomoreransom.org/index.html [Accessed July 2017].

50

Cybervigilance et confiance numérique

Niddel Corp (2014). TIQ-Test – Threat Intelligence Quotient Test [Online]. Available: https://github.com/mlsecproject/tiq-test. Oktavianto, D. and Muhardianto, I. (2013). Cuckoo Malware Analysis. Packt Publishing Ltd. OrbITPeaple (2016). Migrating oracle databases to database Cloud service. Pace, C., Barysevich, A., Gundert, L., Liska, A., McDaniel, M., and Wetzel, J., (2018). A Practical Guide for Security Teams to Unlocking the Power of Intelligence. Cyber Edge Press. Pepper, C. (2015). Applied threat intelligence. Technical report, Securosis. Peretti, K. (2014). Cyber threat intelligence: To share or not to share – What are the real concerns? Privacy and security report, Bureau of National Affairs. Phillips, G. (2014). Threatelligence v0.1 [Online]. Available: https://github.com/syphon 1c/Threatelligence. Pinto, A. and Sieira, A. (2015). Data-driven threat intelligence: Useful methods and measurements for handling indicators. 27th Annual FIRST Conference, June. Piper, S. (2013). Definitive Guide to Next Generation Threat Protection. CyberEdge Group, LLC. Ponemon (2013). Live threat intelligence impact report 2013. Technical report. Ponemon (2014). Exchanging cyber threat intelligence: There has to be a better way. Technical report. Ponemon (2015). Second annual study on exchanging cyber threat intelligence: There has to be a better way. Technical report. Poputa-Clean, P. and Stingley, M. (2015). Automated defense – Using threat intelligence to augment security [Online]. SANS Institute InfoSec Reading Room. Available: https://www.sans.org/reading-room/whitepapers/threats/automated-defense-threatintelligence-augment-35692. Ray, J. (2015). Understanding the Threat Landscape: Indicators of Compromise (IOCs). Verisign. RecordedFuture (2017). Threat intelligence, information, and data: What is the difference? [Online]. Available: https://www.recordedfuture.com/threat-intelligencedata/. Richards, K. (2009). The Australian Business Assessment of Computer User Security (ABACUS): A National Survey. Australian Institute of Criminology.

La Cyber Threat Intelligence et son évolution

51

Rieck, K. (2013). Malheur [Online]. Available: http://www.mlsec.org/malheur. Rieck, K., Trinius, P., Willems, C., and Holz, T. (2011). Automatic analysis of malware behavior using machine learning. Journal of Computer Security, 19(4), 639–668. Ring, T. (2014). Threat intelligence: Why people don’t share. Computer Fraud & Security, 2014(3), 5–9. Rouse, M. (2015). Hybrid Cloud [Online]. TechTarget. Sauerwein, C., Sillaber, C., Mussmann, A., and Breu, R. (2017). Threat intelligence sharing platforms: An exploratory study of software vendors and research perspectives. Towards Thought Leadership in Digital Transformation: 13. Internationale Tagung Wirtschaftsinformatik [Online]. Available: http://aisel.aisnet.org/wi 2017/track08/paper/3. Schneier, B. (2000). Software complexity and security [Online]. Crypto-Gram. Seredynski, M., Bouvry, P., and Klopotek, M.A. (2007). Modelling the evolution of cooperative behavior in ad hoc networks using a game based model. IEEE Symposium on Computational Intelligence and Games, 2007, pp. 96–103. Shackleford, D. (2015). Who’s using cyberthreat intelligence and how? – A SANS Survey. Technical report, SANS Insitute. Shackleford, D. (2016). The SANS state of cyber threat intelligence survey: CTI important and maturing. Technical report, SANS Institute. Sillaber, C., Sauerwein, C., Mussmann, A., and Breu, R. (2016). Data quality challenges and future research directions in threat intelligence sharing practice. Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security, ACM, pp. 65–70. Skopik, F., Settanni, G., and Fiedler, R. (2016). A problem shared is a problem halved: A survey on the dimensions of collective cyber defense through security information sharing. Computers & Security, 60, 154–176. Soltra (2017). Soltra Edge [Online]. Available: http://www.soltra.com/en [Accessed January 2017]. Steele, R.D. (2007a). Open source intelligence. In Handbook of Intelligence Studies. Johnson, L.K. (ed.), Routledge. Steele, R.D. (2007b). Open source intelligence. In Strategic Intelligence. Johnson, L.K. (ed.). Praeger. Steele, R.D. (2014). Applied collective intelligence: Human-centric holistic analytics, true cost economics, and open source everything. Spanda Journal, 2, 127–137.

52

Cybervigilance et confiance numérique

Strom, B. (2016). ATT&CK Gaining Ground [Online]. Available: https://www.mitre. org/capabilities/cybersecurity/overview/cybersecurity-blog/attck%E2%84%A2gaining-ground. Symantec. (2016). Internet security threat report. Technical report. The Snort team (2017). Snort [Online]. Available: https://www.snort.org [Accessed July 2017]. Threatconnect (2017). Threatconnect platform [Online]. Available: https://www. threatconnect.com/platform [Accessed January 2017]. ThreatQuotient (2017). THREATQ [Online]. Available: https://www.threatq.com/ threatq [Accessed January 2017]. Tounsi, W. and Rais, H. (2018). A survey on technical threat intelligence in the age of sophisticated cyber-attacks. Computers & Security, 72, 212–233 [Online]. Available: http://www. sciencedirect.com/science/article/pii/S0167404817301839. Tounsi, W., Cuppens-Boulahia, N., Cuppens, F., and Garcia-Alfaro, J. (2013). Finegrained privacy control for the RFID middleware of EPCGlobal networks. Proceedings of the Fifth International Conference on Management of Emergent Digital EcoSystems, ACM, pp. 60–67. Trost, R. (2014). Threat intelligence library: A new revolutionary technology to enhance the SOC battle rhythm! Briefing, Blackhat-Webcast. Verizon (2015). Data breach investigations report. Technical report. Verizon (2017). Vocabulary for event recording and incident sharing [Online]. Available: http://veriscommunity.net [Accessed July 2017]. Wagner, C., Dulaunoy, A., Wagener, G., and Iklody, A. (2016). MISP: The design and implementation of a collaborative threat intelligence sharing platform. Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security, ACM, pp. 49–56. Williamson, W. (2016). Distinguishing threat intelligence from threat data [Online]. Security Week. Available: http://www.securityweek.com/distinguishing-threatintelligence-threat-data. Yamakawa, N. (2014). Threat intelligence climbs the ladder of enterprise proliferation. Technical report, 451 Research. Zheng, D.E. and Lewis, J.A. (2015). Cyber threat information sharing – recommendations for congress and the administration. Report Center for Strategic and International Studies (CSIS), Strategic Technologies Program. Zurkus, K. (2015). Threat intelligence needs to grow up. White paper, CSOfromIDG.

Chapitre 2

Systèmes de gestion de la confiance : une étude rétrospective sur la confiance numérique

2.1. Introduction L’évolution de la communication des systèmes autonomes vers des systèmes ouverts et décentralisés a poussé la recherche à penser au-delà de la sécurité. En effet, les étonnantes avancées récentes des systèmes et réseaux informatiques ont stimulé l’utilisation d’Internet, en particulier via les appareils mobiles. Cette nouvelle omniprésence d’Internet a permis à des milliards1 de personnes, réparties dans le monde entier, d’intensifier leur utilisation en créant, partageant et interagissant de multiples façons entre systèmes ouverts et décentralisés. Plus que toute autre forme d’interaction, la collaboration repose sur le partage des ressources, de l’information et des connaissances, ce qui fait de la sécurité un enjeu crucial (Renzl 2008 ; Casimir et al. 2012). Le concept de confiance a été reconnu comme un facteur d’interaction dans les situations de risque et d’incertitude (Jøsang et al. 2007 ; Yaich et al. 2013). Sur la base de ce concept, plusieurs systèmes de gestion de confiance ont été proposés en intelligence artificielle distribuée et en sécurité. Au départ, le concept de systèmes de gestion de la confiance (Blaze et al. 1996, 1999b) a été introduit par des chercheurs travaillant dans le domaine du contrôle d’accès en ce qui concerne les mécanismes qui

Chapitre rédigé par Reda YAICH. 1. Liste des communautés virtuelles comptant plus de 100 millions d’utilisateurs actifs : http://en.wikipedia.org/wiki/List_of_virtual_communities_with_more_more_100_million_active users.

54

Cybervigilance et confiance numérique

utilisent des identifiants et des politiques pour exprimer la délégation des droits, en fonction des relations de confiance ad hoc existantes. Dans cette approche, ce sont les propriétaires des ressources, et non les administrateurs de sécurité, qui sont responsables de spécifier pour qui et quand l’accès peut être accordé. Par conséquent, le rôle d’un système de gestion de la confiance consiste à évaluer si les politiques et les identifiants spécifiés nous permettent d’établir une relation de confiance (matérialisée par la chaîne de délégation) entre le propriétaire des ressources et le demandeur de ressources. Ce chapitre vise à analyser la confiance numérique et à identifier les mécanismes qui sous-tendent les systèmes de gestion de la confiance. Nous passons également en revue les différents modèles et systèmes qui ont été proposés dans la discipline au cours de la dernière décennie. Premièrement, dans la section 2.2, nous tentons de donner une définition claire de la confiance et de clarifier comment ce concept devrait être compris tout au long du présent chapitre. Ensuite, dans la section 2.3, nous proposons une vue historique de l’évolution de ces systèmes du contrôle d’accès vers un système de gestion de confiance. À partir de cette première caractérisation, nous présentons au lecteur en section 2.4 les concepts fondamentaux qui sous-tendent cette approche. La section 2.5 comprend une enquête dans laquelle les systèmes de gestion de la confiance les plus pertinents sont présentés en donnant un aperçu des systèmes existants. Les systèmes sont présentés chronologiquement afin de souligner la contribution apportée par chaque système par rapport à ses prédécesseurs. Les systèmes sont également structurés en regroupant des systèmes similaires en trois catégories : basés sur les autorisations, basés sur les rôles et basés sur la négociation. Cette section est suivie de la section 2.6 avec les applications récentes des systèmes de gestion de la confiance dans les infrastructures en Cloud. Enfin, la section 2.7 conclut ce chapitre. 2.2. Définition de la confiance Dans le monde réel comme dans le monde virtuel, la confiance constitue un concept fondamental pour les humains, sans lequel ils ne peuvent ni agir ni interagir. Il n’est donc pas surprenant qu’au cours des dernières décennies, la confiance ait reçu beaucoup d’attention de la part de plusieurs disciplines. À cette fin, une section de définition semble essentielle afin de clarifier son sens. Selon Gambetta (Gambetta 2000) : « La confiance (ou, symétriquement, la méfiance) est un niveau particulier de la probabilité subjective avec laquelle un agent évalue qu’un autre agent ou groupe d’agents va effectuer une action donnée, à la fois

Systèmes de gestion de la confiance

55

avant de pouvoir suivre cette action (ou indépendamment de sa capacité à la suivre) et dans un contexte où elle affecte sa propre action. » Tout d’abord, nous notons ici que Gambetta, qui est sociologue, a conceptualisé la confiance comme un concept mathématique, rendant sa définition plus concrète. En outre, l’expression « un niveau particulier » utilisée dans la définition signifie que, pour Gambetta, la confiance peut être en quelque sorte quantifiable. Selon Gambetta, 0 signifie une méfiance totale et 1 signifie une confiance totale. De plus, cette définition explicite l’idée que la confiance est subjective et introduit la spécificité de la confiance : la confiance est faite à l’égard d’une action spécifique à accomplir. Cette définition tient compte de l’incertitude induite par le comportement du partenaire en interaction, sans laquelle il n’y aurait pas besoin de confiance. En outre, Gambetta déclare que « si nous avions la chance d’avoir une capacité informatique illimitée pour prévoir toutes les éventualités possibles dans les contrats exécutoires, la confiance ne serait pas un problème ». Par cette déclaration, Gambetta souligne le fait que la confiance implique de prendre des décisions dans des situations complexes difficiles à saisir pour l’esprit humain. La nature complexe des situations de confiance est encore renforcée par la définition donnée par Luhmann (Luhmann 1990). Selon Luhmann, « la complexité du monde futur est réduite par l’acte de confiance ». Luhmann aborde la confiance d’un point de vue sociologique en établissant un lien entre l’utilisation de la confiance et les interactions entre les sociétés et en remettant en question l’existence de la société sans confiance (Marsh 1994 ; Lamsal 2001). Il considère la confiance comme l’un des « mécanismes internes les plus importants pour réduire la complexité ». Cependant, les auteurs ont défini la complexité en termes très abstraits, même s’ils l’ont généralement utilisée en référence à des situations incertaines. Dans un contexte informatique, McKnight (Mcknight et Chervany 1996) définit la confiance comme « la mesure dans laquelle une partie est prête à dépendre de quelque chose ou de quelqu’un dans une situation donnée avec un sentiment relatif de sécurité, même si des conséquences négatives sont possibles ». Selon Grandison et Sloman, la confiance est « la croyance ferme dans la compétence d’une entité à agir de manière sûre et fiable dans un contexte donné ». Enfin, selon Falcone et Castelfranchi, la confiance est utilisée comme « fondement mental et contrepartie de la délégation » (Falcone et Castelfranchi 2001). Par conséquent, les auteurs considèrent la délégation comme une action, prenant cet état mental comme un intrant. Chacune des définitions ci-dessus fait progresser notre compréhension de la confiance et fournit des éléments de base importants pour la définition de ce concept. Cependant, aucun d’entre eux ne correspond parfaitement à notre conceptualisation de

56

Cybervigilance et confiance numérique

la confiance. À la lumière des définitions ci-dessus, nous définissons la confiance comme suit : DÉFINITION 2.1. Confiance.– La décision délibérée d’un(e) individu/entité A (appelé(e) fiduciaire) d’être dans une situation de vulnérabilité vis-à-vis du comportement d’un(e) individu/entité B (appelé(e) curateur) par rapport à une question X (c’est-àdire une question de confiance) et dans un contexte C. 2.3. Genèse des systèmes de gestion de la confiance La gestion de la confiance trouve ses racines dans la sécurité et plus particulièrement dans le contrôle d’accès. Le contrôle d’accès (AC) est le mécanisme traditionnel par lequel les applications logicielles (à l’origine les systèmes d’exploitation) répondent à la question (ou demande) : « L’entité identifiée comme étant S peut-elle manipuler l’objet O via l’action A ? » Ici, le verbe « pouvoir » doit être compris en termes de droits et non en termes de capacités. De plus, comme nous pouvons le constater, cette question peut être facilement contextualisée en ce qui concerne la question de la fiducie : « Puis-je faire assez confiance à S pour lui permettre d’exécuter l’action A sur l’objet O ? » Dans cette section, nous présentons les différents modèles qui ont été proposés pour répondre à ces questions. Toutefois, avant de poursuivre, nous présentons la terminologie de base sur laquelle nous nous appuierons dans nos descriptions. 2.3.1. Modèle de contrôle d’accès Le contrôle d’accès est le mécanisme utilisé par les applications pour déterminer qui sera autorisé à manipuler les ressources locales. Le modèle abstrait du mécanisme de contrôle d’accès est illustré à la figure 2.1, où : – la demande (request) représente le type d’interaction pour lequel une autorisation est demandée (par exemple, lecture, utilisation ou connexion) ; – le sujet (subject), souvent appelé « le principal », est l’entité abstraite (un humain, un programme ou un agent artificiel) nécessitant une autorisation ; – l’objet2 (object) est l’artefact abstrait représentant la ressource avec laquelle le demandeur veut interagir (par exemple, un fichier ou un service) ;

2. Dans la suite de ce chapitre, nous utiliserons de façon interchangeable les termes « sujet » et « principal ». Nous le ferons aussi pour les concepts de « ressource » et d’« objet ».

Systèmes de gesstion de la confiance

57

– le mécanisme (m mechanism) est e le schéma qui déterminne si le deman andeur est mandée. autorisé à effectuer l’innteraction dem

Figurre 2.1. Un modèle de contrô ôle d’accès de e base (source : ad dapté de (Geno ovese 2012))

Ainsii, le mécanism me de contrôle d’accès joue le rôle de gardde pour la mannipulation des ressoources localess sensibles. Il détermine sii un demandeeur devrait ouu non être autorisé à manipuler laa ressource quu’il a demandéée. La spécificcation des infoormations sur la baase desquelles un demandeuur peut être au utorisé représeente une autorrisation et est générralement codéée dans une politique p de contrôle c d’accès. Compte teenu de la nature des d politiques utilisées pouur préciser less permissions, un large évventail de mécanism mes ont été prroposés au couurs des dernièrres décennies pour p régler le problème du contrrôle d’accès. Ces mécanissmes peuventt toutefois êttre regroupés en cinq et sur les catégoriees : basés sur l’identité, l sur le réseau, sur les rôles, sur l’organisation l attributs. Les sections suivantes donnnent un aperçu u de la façon dont d chaque m mécanisme c d’acccès. aborde laa question du contrôle 2.3.2. Contrôle C d’ac ccès basé sur s l’identité é Le prroblème générral du contrôle d’accès est so ouvent divisé en e deux sous-pproblèmes principauux : l’authentiffication et l’aautorisation. L’authentificati L on vise à proouver que l’identitéé revendiquée par p un mandannt est authentique, tandis quue l’autorisationn tente de déterminner s’il existe une autorisaation permettan nt à cette ideentité de mannipuler la ressourcee demandée, ett comment cettte manipulatio on peut-elle êtrre effectuée. Le contrôle d’accès basé b sur l’identtité (IBAC) a utilisé u impliciteement un moddèle mondial feermé, dans lequel lees utilisateurs et les ressourcces sont a priiori connus. Dans D ces hypoothèses, le problèmee de l’autorisaation se réduitt à celui de l’’authentificatioon. Par conséqquent, les autorisatiions d’accès à une ressouurce sont direcctement assocciées à l’idenntifiant du principall (par exemple, nom d’utilisaateur, ouverturre de session ou clé publiquee), comme le montree la figure 2.2. L’accès à la ressource (obj bject dans la fiigure 2.1) n’esst possible que lorsqqu’une telle asssociation existee.

58

Cybervigilance et confiance numérique

Figure 2.2. Un modèle abstrait de l’IBAC

Dans ce cas, l’information utilisée dans la politique est l’identité du principal qui demande l’accès à la ressource. Par conséquent, ces modèles sont dits basés sur l’identité. Un exemple concret est la mise en œuvre à l’aide de listes de contrôle d’accès (ACL). Les ACL sont la forme la plus ancienne et la plus élémentaire de contrôle d’accès que l’on trouve couramment dans les systèmes d’exploitation tels que UNIX. Les ACL sont des listes de mandataires et des mesures que chaque mandataire est autorisé à prendre à l’égard de la ressource. Ici, les politiques de contrôle d’accès représentent les règles qui déterminent s’il existe une association entre le mandataire et une autorisation. De façon générale, une permission est un triplet (s, o, a), indiquant qu’un utilisateur s est autorisé à effectuer une action a sur un objet o. Soit S l’ensemble des utilisateurs du système, O l’ensemble des objets et A l’ensemble des actions possibles. Les politiques de contrôle d’accès représentent une fonction f : S × O → A. Par conséquent, f (s, o) détermine la liste des actions que le sujet s est autorisé à effectuer sur l’objet o. Le tableau 2.1 illustre (sous forme de matrice A = |S| × |O|) la liste de contrôle d’accès d’un système où S = {s1, s2, s3}, O = {o1, o2, o3} et A = {a1, a2, a3} (El Houri 2010). Sujet

o1

o2

o3

s1

a 1, a 2, -

a2

a2

s2

a 2, a 2

−

−

s3

a 1, a 1, a 2

a 1, a 2

a 1, a 2

Tableau 2.1. Exemple d’une liste de contrôles d’accès

Les modèles IBAC sont très faciles à mettre en œuvre et à utiliser. Cependant, de telles approches ne peuvent pas être mises à l’échelle lorsque le nombre d’utilisateurs

Systèmes de gestion de la confiance

59

augmente (Yuan et Tong 2005). De plus, les décisions de contrôle d’accès ne sont liées à aucune caractéristique de la ressource, objet de l’application métier, rendant ces approches très vulnérables aux attaques (les ACL sont faciles à corrompre) et à l’usurpation d’identité (Chen 2011). 2.3.3. Contrôle d’accès basé sur le réseau Contrairement aux modèles IBAC, les modèles de contrôle d’accès en réseau (LBAC) (également appelés modèles de contrôle d’accès obligatoire ou modèles d’accès fondés sur les treillis) sont déployés lorsque l’accès à un objet dépend de ses caractéristiques et de celles du sujet, et non de la volonté de son propriétaire (c’est-àdire ACL) (Sandhu 1993). Les caractéristiques des sujets et des objets sont représentées par des étiquettes de sécurité (ou niveaux) qui sont affectées aux utilisateurs et aux ressources du système. Les étiquettes des objets reflètent la mesure dans laquelle une ressource est sensible, tandis que l’étiquette d’un sujet reflète la catégorie d’objets à laquelle il est autorisé à accéder. Les systèmes dans lesquels les modèles LBAC sont mis en œuvre sont souvent appelés systèmes de sécurité multiniveaux, car les étiquettes utilisées dans ces systèmes représentent un ordre partiel (par exemple, top secret, secret, confidentiel et non classifié), qui est supposé former un réseau. En LBAC, le processus de contrôle d’accès est réduit au contrôle du flux de données. Par exemple, un accès en lecture à une ressource est représenté comme un flux de données de l’objet vers le sujet, tandis qu’un accès en écriture représente un flux de données du sujet vers l’objet. Par conséquent, lorsqu’il est utilisé à des fins de confidentialité, le modèle LBAC a pour objectif de garantir que les données provenant d’un objet de niveau supérieur ne sont jamais transmises aux sujets de niveau inférieur et que les données provenant de sujets de niveau supérieur ne sont jamais transmises aux objets de niveau inférieur. En résumé, l’étiquette d’un sujet doit être au moins aussi haute que l’étiquette de l’objet qu’il veut lire, et pour écrire sur un objet, l’étiquette doit être au moins aussi haute que celle du sujet (Chen 2011). Ces deux principes de sécurité sont ci-après, respectivement, appelés « pas de réévaluation » et « pas de dépréciation », comme illustré à la figure 2.3. Le modèle Bell-LaPadula est le modèle le plus connu pour la mise en œuvre de la LBAC. Il a été utilisé dans des applications militaires et commerciales ainsi que pour mettre en œuvre les mécanismes de sécurité dans les systèmes d’exploitation Multics. La principale limite des modèles LBAC est leur manque de flexibilité et d’évolutivité. En effet, les modèles fondés sur les treillis sont assez efficaces et restent relativement gérables dans des systèmes avec un petit nombre d’étiquettes.

60

Cyb bervigilance et confiance c numérrique

Figure 2.3. Modèle M de con ntrôle d’accès basé sur un ré éseau abstraitt

2.3.4. Contrôle C d’ac ccès basé sur s les rôles s Les modèles m de l’IIBAC et de laa LBAC préseentent des lacuunes considéraables : les modèles LBAC sont clairement troop rigides, alo ors que les modèles m IBAC sont très difficiless à maintenir et à administrer (Becker 2005). Cette constatation a amené plusieurss chercheurs, au a début des années a 1990, à chercher d’autres modèlees comme les modèèles de contrôôle d’accès bassé sur les rôlees (RBAC) (S Sandhu et al. 11996). Le développpement de la RBAC R a été motivé m par le fait que, danss la plupart dees cas, les ressourcees sensibles n’appartenaieent généralem ment pas auxx utilisateurss mais à l’institutiion où ces uttilisateurs occcupent un em mploi (Becker 2005 ; Yao 20004). Par conséqueent, les élémeents clés des modèles RBA AC sont les sujets, les rôlles et les autorisattions, comme l’illustre l la figgure 2.4.

Figure 2.4. Modèle M de basse de contrôle e d’accès basé é sur les rôles (source : ad dapté de (Geno ovese 2012))

La poolitique représsente ici une reelation d’affecctation qui assoocie les utilisaateurs aux rôles qu’’ils détiennentt et les rôles auux autorisation ns qui leur sonnt accordées. Ainsi, les rôles repprésentent une couche interm médiaire entree les sujets et les permissionns, ce qui

Systèmes de gestion de la confiance

61

fait de RBAC un mécanisme de contrôle d’accès évolutif et réduit considérablement la complexité des spécifications et de l’administration des politiques de contrôle d’accès lorsque le roulement du sujet est très élevé. Lorsqu’un sujet rejoint ou quitte le système, seul le lien entre l’identifiant utilisateur et le rôle doit être mis à jour. Les sujets se voient attribuer des rôles en fonction de leurs postes de travail et/ou missions au sein de l’entreprise, qualifications ou compétences au sein de l’institution, tandis que les permissions sont associées aux rôles en fonction des activités et objectifs de l’institution. RBAC a reçu au cours des vingt dernières années une attention qui a donné lieu à la création d’une famille entière de modèles (Sandhu et al. 1996 ; Nyanchama et Osborn 1999 ; Sandhu et al. 2000 ; Ferraiolo et al. 2001 ; Li et al. 2002 ; Dimmock et al. 2004 ; Boella et van der Torre 2005 ; Wang et Varadharajan 2007 ; Finin et al. 2008 ; Ferraiolo et Kuhn 2009). Cependant, la plupart des chercheurs seraient d’accord sur le fait que RBAC0 est le modèle de base (Becker 2005 ; Chen 2011). RBAC0 est le modèle principal et le plus simple. RBAC1 étend RBAC0 avec la possibilité de spécifier des hiérarchies de rôles, en introduisant l’héritage de permissions entre les rôles. RBAC2 étend RBAC1 avec des contraintes pour imposer la séparation des tâches, tandis que RBAC3 est une combinaison de RBAC1 et RBAC2. 2.3.5. Contrôle d’accès basé sur l’organisation Le contrôle d’accès basé sur l’organisation (OrBAC) et le RBAC ont de nombreux aspects similaires ; par exemple, dans les deux approches, le concept d’un rôle est central. Par conséquent, la plupart des chercheurs décrivent OrBAC comme une extension de RBAC (Kalam et al. 2003). OrBAC vise à détailler les permissions qui sont utilisées en termes abstraits au sein de RBAC. En effet, les politiques de la RBAC définissent la correspondance entre les identités et les rôles. Ensuite, sur la base de ces politiques, le mécanisme de contrôle d’accès accorde des permissions aux sujets en fonction du rôle auquel ils sont rattachés. Par conséquent, l’interprétation des permissions demeure la responsabilité de l’administrateur et peut être très complexe à effectuer ; par exemple, le regroupement de droits similaires, la prévention de droits inadéquats et la gestion des rôles conflictuels sont quelques-uns des principaux problèmes à régler (Kalam et Deswarte 2006). Le concept principal d’OrBAC est l’organisation des entités. La spécification de la politique est entièrement paramétrée par l’organisation. Elle se caractérise par un haut niveau d’abstraction. Au lieu de modéliser la politique en utilisant les concepts concrets et liés à la mise en œuvre du sujet, de l’action et de l’objet, le modèle OrBAC suggère de raisonner avec les rôles attribués aux sujets, aux actions ou aux objets dans l’organisation. Ainsi, un sujet est résumé en rôle, qui est un ensemble de sujets

62

Cybervigilance et confiance numérique

auxquels s’applique la même règle de sécurité. De même, une activité et une vue sont, respectivement, un ensemble d’actions et d’objets auxquels s’applique la même règle de sécurité. La figure 2.5 décrit le modèle OrBAC, qui introduit deux niveaux de sécurité (concret et abstrait). OrBAC définit le concept de contexte. C’est une condition qui doit être remplie pour activer une règle de sécurité. Une politique mixte peut être proposée dans OrBAC, qui définit quatre types d’accès : autorisation, interdiction, obligation et recommandation.

Figure 2.5. Le modèle OrBAC

2.3.6. Contrôle d’accès basé sur les attributs L’idée principale des modèles de contrôle d’accès par attributs (ABAC) est d’utiliser des politiques qui s’appuient sur les caractéristiques des personnes autorisées plutôt que sur leur identité, leur rôle ou leurs autorisations pour délivrer des permissions (Yuan et Tong 2005 ; Lee 2008). Ces politiques sont ensuite satisfaites par la divulgation des identifiants émis par des tiers certificateurs d’attributs (par exemple, organismes, entreprises et institutions). Par conséquent, les sujets peuvent

Systèmes de gesstion de la confiance

63

avoir acccès aux ressouurces sans être préalablemen nt connus de l’administrateuur système (ou du prropriétaire dess ressources), comme c l’illusttre la figure 2.6.

F Figure 2.6. Mo odèle de contrrôle d’accès ba asé sur des atttributs abstraiits

Contrrairement auxx politiques IBAC, I LBAC C et RBAC, les politiquees ABAC peuvent définir les peermissions en fonction de toute caractérristique pertinnente. Les caractéristiques apparttiennent aux trois catégories suivantes (Yuuan et Tong 20005) : – attrributs de sujeet : les sujets sont s les entitéés qui demanddent l’accès auux objets. Chaque sujet s peut êtree caractérisé par un ensemblle d’attributs sans s référencee explicite à son ideentité. Dans laa littérature de l’ABAC, pressque toute l’innformation quii peut être associée à un sujet estt considérée comme un attrribut. Ces attriibuts peuvent inclure le nom du sujet, son rôlee, son affiliatioon, son adressse, son âge, ettc. En fait, l’iddentité du sujet peuut aussi être coonsidérée comm me un attribut ; – attrributs d’objett : les objets sont s des resso ources que lee sujet veut m manipuler. Comme les sujets, less ressources ont des propriéétés qui sont aussi a appeléess attributs dans le modèle m ABAC C. Les attributts de ressourcees sont égalem ment importannts dans la décision de contrôle d’accès d car ilss peuvent affeecter le type de d permission accordée (par exem mple, une leccture sur un fiichier texte n’’a pas la mêm me conséquencce qu’une exécutionn sur un progrramme). Les attributs a de la ressource peuuvent inclure lle nom de la ressouurce, son typee (fichier textte, image, serrvice, etc.), lee propriétaire, etc. Ces données sont générallement renduees publiques et peuvent être extraites automatiquementt des métadonnnées ;

64

Cybervigilance et confiance numérique

– attributs de contexte : l’environnement, ou plus généralement le contexte dans lequel s’inscrit l’interaction, a été longtemps ignoré par la communauté de la sécurité. Dans les approches précédentes, les permissions sont attachées aux individus (IBAC), aux rôles (RBAC) ou aux étiquettes (LBAC) et infèrent la même autorisation tant que l’artefact auquel elles sont attachées reste valide (ou à moins qu’elles soient révoquées par l’administrateur système). Ainsi, le contexte de l’interaction n’affecte jamais la décision de contrôle d’accès, alors que les attributs d’environnement, tels que l’heure, la date et les menaces, sont pertinents pour appliquer la politique de contrôle d’accès. 2.4. Gestion de la confiance Dans cette section, nous présentons l’approche de gestion de la confiance qui découle des travaux de Blaze et de ses collègues (Blaze et al. 1996, 1999a), qui ont tenté d’aborder les limites des modèles traditionnels de contrôle d’accès mentionnés ci-dessus en ce qui concerne les limites de distribution et de décentralisation. Dans la suite de cette section, nous définirons d’abord le concept de gestion de la confiance, puis, nous présenterons les principaux concepts sur lesquels repose cette approche. 2.4.1. Définition La gestion de la confiance a été définie par Blaze et ses collègues comme « une approche unifiée pour spécifier et interpréter les politiques de sécurité, les identifiants, les relations qui permettent l’autorisation directe des actions critiques pour la sécurité » (Blaze et al. 1996, 1999a). La principale nouveauté de l’approche introduite par Blaze et al. est qu’ils ont unifié les concepts de politique de sécurité, d’identifiants et d’autorisation sous le concept de gestion de confiance. Cependant, leur définition n’est pas très intuitive et trop abstraite pour expliquer ce qu’est réellement la gestion de la confiance. Selon Jøsang, la gestion de la confiance est « l’activité de collecte, de codification, d’analyse et de présentation d’éléments de preuve pertinents en matière de sécurité dans le but de procéder à des évaluations et de prendre des décisions concernant les transactions électroniques » (Jøsang 2007 ; Jøsang et al. 2007). Bien qu’elle soit plus large et plus intuitive, cette définition a été critiquée par Grandison dans sa thèse de doctorat pour être trop spécifique à un domaine (c’est-à-dire le commerce électronique) (Grandison 2003). Néanmoins, Grandison l’a réutilisée pour définir la gestion de la confiance comme « l’activité de collecte, d’encodage, d’analyse et de présentation de preuves relatives à la compétence, l’honnêteté, la sécurité ou la fiabilité dans le but de faire des évaluations et des décisions concernant les relations de

Systèmes de gestion de la confiance

65

confiance pour les applications Internet » (Grandison 2003 ; Grandison et Sloman 2003). Le principal inconvénient de la définition de Grandison est que l’auteur a limité la nature des preuves sur lesquelles la relation de confiance peut être établie. De plus, Grandison a utilisé le verbe « recueillir » comme preuve, alors que certains éléments de preuve ne peuvent être recueillis, mais devraient être demandés (par exemple, les titres de compétence). Par conséquent, nous préférons adapter les définitions ci-dessus afin d’obtenir celle qui correspond le mieux à notre compréhension de la gestion de la confiance. DÉFINITION 2.2. Gestion de la confiance.– L’activité automatisée de collecte, de demande, de fourniture et d’analyse de renseignements dans le but de prendre des décisions de confiance (par exemple, contrôle d’accès, délégation et collaboration) en fonction des politiques. Le principal aspect que nous soulignons dans cette définition est la nature automatisée du processus de gestion de la confiance. C’est l’exigence d’automatisation qui rend la question de la gestion de la confiance complexe et qui nécessite tant d’investigations (section 2.5). De plus, nous avons utilisé le terme « information » plutôt que « preuve » afin de nous conformer à l’analyse que nous avons faite précédemment. Enfin, nous généralisons l’objectif de la gestion de la confiance aux décisions de confiance plutôt que de nous concentrer sur les relations de confiance. De notre point de vue, une relation implique une certaine continuité dans le temps, tandis qu’une décision de confiance reflète mieux la nature dynamique de la confiance. 2.4.2. Système de gestion de la confiance Les systèmes de gestion de la confiance (TMS) ont été conçus à l’origine pour résoudre le problème de décider si une demande d’exécution d’une action potentiellement nuisible sur une ressource sensible est conforme à la politique de contrôle d’accès (Blaze et al. 1996, 1999a). Néanmoins, ces systèmes sont actuellement utilisés de façon plus large pour évaluer si une décision de confiance est conforme ou non à la politique. DÉFINITION 2.3. Système de gestion de la confiance.– Un système abstrait qui traite une représentation symbolique d’une relation de confiance du point de vue de l’automatisation des décisions de confiance. Dans la définition ci-dessus, la « représentation symbolique de la confiance » fait référence aux concepts d’identifiants et de politiques par lesquels l’émetteur déclare

66

Cybervigilance et confiance numérique

qu’il fait confiance à l’entité à laquelle la déclaration est applicable. En fait, cette confiance n’est pas générique ; ainsi, dans la plupart des cas, l’énoncé porte sur une question précise (par exemple, la lecture d’un document). La représentation symbolique des relations de confiance peut être illustrée au mieux par l’expérience quotidienne des billets (Wikipédia 2013). Le ticket (disons un ticket de tramway) peut être considéré comme un symbole de confiance entre la société de tramway et le détenteur du ticket. Le titre de transport sert de preuve que le titulaire a payé le voyage et par conséquent qu’il a le droit de monter dans le tramway. Une fois acheté, le billet peut être remis ultérieurement à quelqu’un d’autre, transférant ainsi la relation de confiance. Dans le tramway, seul le billet sera vérifié et non l’identité du titulaire. Concrètement, dans l’exemple ci-dessus, le ticket illustre l’importance de l’identification pendant que l’inspecteur du tramway applique la politique (ce qui est assez simple ici). Ainsi, un système de gestion de la confiance vise à relier le demandeur et la demande par le biais d’une relation de confiance sur la base de laquelle une décision de confiance peut être prise. À cette fin, les systèmes de gestion de la confiance fournissent un langage pour la spécification des politiques et des identifiants et un moteur de gestion de la confiance (pour faire court) qui évalue si les identifiants fournis respectent la politique spécifiée. 2.4.3. Fondations Comme illustré dans la section précédente, les systèmes de gestion de la confiance sont rendus possibles grâce à l’introduction d’identifiants, de politiques et de moteurs de confiance (Nejdl et al. 2004 ; Lee et al. 2009 ; Ryutov et al. 2005 ; Winsborough et Li 2006 ; Galinović 2010). Ces trois composantes sont présentées dans les sections suivantes. 2.4.3.1. Identifiants Les identifiants (ou identifiants numériques) représentent la contrepartie des identifiants sur papier que nous utilisons dans le monde réel (par exemple, passeport, permis de conduire ou carte d’étudiant). Il s’agit de documents ou de messages numériques qui sont certifiés (c’est-à-dire signés) par les autorités de certification. Ils permettent l’authentification de l’utilisateur mais peuvent également fournir des informations supplémentaires telles que les attributs de l’utilisateur (section 2.3.6), les adhésions ou les droits. Blaze, dans son jargon de gestion de la confiance, a défini l’identifiant comme « un message signé qui permet à un mandant de déléguer une partie de son propre pouvoir de poser des actes à d’autres mandants ». C’est cette

Systèmes de gestion de la confiance

67

définition que nous utilisons comme base dans ce chapitre. Par exemple, un « certificat » de clé publique est un exemple d’identifiant. Les infrastructures à clé publique (ICP) ont été systématiquement utilisées par les systèmes de gestion de la confiance pour créer, distribuer, valider, stocker et révoquer les identifiants. Dans ce qui suit, nous passons en revue deux approches importantes de l’ICP, soit celles des autorités de certification (AC) et de la certification croisée (CC) (Linn 2000). L’approche des autorités de certification repose sur la confiance qui existe entre une personne et l’organisation/institution représentant l’autorité de certification, tandis que l’approche de la certification croisée s’appuie sur l’expérience des autres. Nous illustrons ces deux approches par deux mises en œuvre concrètes, qui sont, respectivement, X.509 et PGP. 2.4.3.1.1. Autorités de certification : X.509 X.509 est une norme largement utilisée pour la gestion des identifiants. En règle générale, un certificat X.509 contient (sans toutefois s’y limiter) les informations suivantes : nom de l’émetteur, nom du sujet, identificateur de l’algorithme de signature (par exemple RSA et DSA), période de validité et informations facultatives, qui peuvent être une paire attribut-valeur (Samarati et Vimercati 2001). Dans X.509, le processus de gestion de la certification fait intervenir plusieurs entités : les autorités de certification (CA), qui sont les entités qui délivrent et révoquent les certificats ; les autorités d’enregistrement (RA), qui se portent garantes de la liaison des clés publiques et des dépôts, qui stockent et rendent disponibles les certificats et les listes de révocation de certificats (CRL) ; les détenteurs et clients. Le processus de certification commence lorsque le titulaire du certificat demande un certificat à l’autorité d’enregistrement. Le RA vérifie l’identité du futur titulaire et/ou les attributs pour lesquels il souhaite être certifié (par exemple, dans le cas des capacités de conduite, le RA vérifie si l’entité possède un permis de conduire dans la vie réelle). Après cette étape, le RA transmet la demande au CA, qui signe le certificat après avoir vérifié que le RA a réellement approuvé la demande. Ensuite, le CA envoie une copie du certificat aux dépôts afin que les clients qui veulent communiquer avec le demandeur puissent obtenir la clé publique. De même, lorsqu’un certificat doit être révoqué (par exemple, lorsqu’une clé a été compromise), le CA met à jour les référentiels et ajoute une entrée à la liste de révocation. Les autorités de certification sont organisées de manière hiérarchique ; le CA racine certifie les autres CA, qui à leur tour certifient les autres CA ou le simple demandeur. Ces questions représentent l’aspect le plus controversé de X.509 car les CA racines sont des entités autocertifiées (Yu 2003 ; Conrad et al. 2012).

68

Cybervigilance et confiance numérique

2.4.3.1.2. Certification croisée : PGP PGP (Pretty Good Privacy) est une infrastructure à clé publique qui a été initialement conçue pour garantir l’authenticité, l’intégrité et la non-répudiation des données échangées. Bien qu’elle puisse chiffrer n’importe quel type de données, PGP a été le plus souvent utilisée pour l’échange d’emails. Contrairement à X.509, dans PGP, chaque utilisateur peut générer une paire (clé publique, clé privée), qui est associée à son identité unique. Cependant, les clés sont utilisées indépendamment de l’identité de l’utilisateur ; ainsi, PGP garantit l’authenticité, l’intégrité et la nonrépudiation tout en préservant la confidentialité de l’identité individuelle (c’est-à-dire la confidentialité). Un certificat PGP comprend (sans toutefois s’y limiter) les informations suivantes : le titulaire du certificat, les informations relatives au titulaire (par exemple, nom, pièce d’identité, email et photo), la signature numérique du titulaire, la période de validité et l’algorithme de chiffrement. Grâce aux informations du titulaire, un certificat PGP unique peut contenir plusieurs informations, qui peuvent être certifiées via la même clé (Yu 2003). Dans PGP, chacun peut librement délivrer et certifier ses propres certificats. De cette façon, chacun peut agir en tant qu’autorité de certification. Ainsi, chacun peut certifier les clés publiques des autres (PGP appelle ce mécanisme introduction), rendant les questions de confiance centrales pour PGP. Par conséquent, PGP s’appuie sur un « réseau de confiance », qui est le réseau créé par les personnes qui se présentent mutuellement leurs clés. Pour ce faire, PGP utilise deux mesures distinctes : une mesure quantitative (la validité de la clé) et une autre qualitative (le niveau de confiance d’une clé). Dans PGP, un utilisateur fait toujours confiance à sa propre clé, rendant le niveau de cette clé ultime. Les autres niveaux utilisés dans PGP sont complets, marginaux, inconnus et non fiables (par ordre décroissant de niveau de confiance). De même, la validité d’une clé peut être valide, marginalement valide ou invalide. Le nombre de personnes qui signent la clé publique détermine sa validité, tandis que le niveau de confiance d’une clé est déterminé par recommandation. Plus on fait confiance à une clé, moins elle nécessite de validité pour être acceptée (Gerck 2000 ; Prohic 2005). 2.4.3.2. Politiques Les politiques ont été largement utilisées dans la documentation informatique (par exemple, systèmes d’information, systèmes de sécurité et systèmes multi-agents). Au départ, des politiques ont été introduites en informatique pour automatiser les tâches et les prises de décision (par exemple, instructions de traitement par lots). Cependant, de nos jours, la motivation principale pour utiliser les politiques est de faire en sorte que

Systèmes de gestion de la confiance

69

les systèmes soutiennent un comportement dynamique et adaptatif. Les politiques permettent à un système de changer son comportement sans être arrêté. En dépit de leur utilisation abondante dans la littérature, le concept de politiques est encore difficile à définir et les définitions fournies sont soit trop génériques, soit trop spécifiques à un domaine. Par exemple, Sloman a défini les politiques comme des « règles régissant les choix de comportement d’un système » (Sloman 1994). Bien que cette définition saisisse le sens d’une politique générale, elle n’aborde pas son rôle, qui est de préciser les circonstances dans lesquelles les choix sont faits (en réaction à quelles conditions). De plus, cette définition réduit la forme d’une politique à un ensemble de règles et exclut donc bon nombre des approches qui ne reposent pas sur des règles (section 2.5). Récemment, De Coi et Olmedilla ont déclaré que « les politiques précisent qui est autorisé à effectuer quelle action sur quel objet selon les propriétés du demandeur et de l’objet ainsi que les paramètres de l’action et les facteurs environnementaux » (De Coi et Olmedilla 2008). Cette définition explicite l’approche ABAC et couvre donc de facto les politiques IBAC, LBAC, RBAC et OrBAC. Toutefois, cette définition limite la portée d’une politique aux situations dans lesquelles une demande d’accès doit être évaluée. Par conséquent, cette définition ne saurait être utilisée pour décrire des situations dans lesquelles une décision n’est pas simplement une décision de contrôle d’accès (par exemple, délégation). Afin d’éviter tout malentendu, nous clarifions le sens de la politique de confiance et la définissons comme suit. DÉFINITION 2.4. Politique.– Une politique est un énoncé qui précise dans quelles conditions on peut faire confiance à une entité (humaine ou artificielle) pour une question particulière (par exemple, action de ressources et délégation de tâches). En ce qui concerne la définition 2.1, une politique représente l’expression des conditions dans lesquelles la personne A prend délibérément la décision de faire confiance à B. Ainsi, selon nous, le rôle d’une politique est double : (i) elle permet à A d’exprimer la politique sur laquelle s’appuiera son système de gestion fiduciaire et (ii) elle est utilisée comme langage commun que A et B utiliseront pour échanger leurs conditions de confiance respectives. À la lumière de cela, le rôle du langage de spécification de la politique est primordial. Le langage fournit la syntaxe de base pour exprimer les conditions qui représentent les éléments constitutifs d’une politique. Les langages de spécification peuvent être plus ou moins verbaux et peuvent avoir une base formelle forte ou faible. Ainsi, selon la nature du langage de spécification de la politique, les politiques se répartissent en trois catégories : informelle, semi-formelle et formelle. Dans ce chapitre, nous limitons notre attention aux politiques formelles qui peuvent être comprises à la fois par des agents artificiels et humains. Dans la

70

Cybervigilance et confiance numérique

section 2.5, nous présentons les principaux langages de spécification de politiques qui ont été proposés au cours des quinze dernières années. 2.4.3.3. Moteur de confiance L’objectif du moteur de confiance est d’évaluer si les identifiants fournis par le demandeur sont valides et s’ils respectent la politique spécifiée. Il est important de noter que les systèmes de gestion de la confiance ne sont pas responsables des décisions relatives à la confiance. C’est toujours l’humain ou l’application utilisant le TMS qui décide s’il faut effectivement faire confiance au demandeur ou non3. Par conséquent, le principal avantage de l’utilisation d’un TMS est de décharger les applications des tâches complexes et fastidieuses que sont la vérification des identifiants et l’évaluation des politiques. La figure 2.7 illustre ce principe et montre le fonctionnement de base d’un système de gestion de la confiance.

Figure 2.7. Illustration du fonctionnement d’un système de gestion de la confiance

Dans la figure 2.7, l’application A invoque le système de gestion de la confiance pour déterminer si l’application B peut être autorisée à effectuer une opération sur une ressource. À cette fin, l’application A fournit au TMS sa politique locale pour la ressource concernée par la demande et les identifiants fournis par l’application B. Le TMS produit une réponse sur la base de laquelle l’application A décide d’accepter ou de refuser la demande de B.

3. L’étude de la façon dont les décisions relatives à la confiance sont prises n’entre pas dans le cadre du présent chapitre.

Systèmes de gestion de la confiance

71

Figure 2.8. Modes de fonctionnement d’un système de gestion de la confiance

Selon leur degré de sophistication, les systèmes de gestion de la confiance peuvent fournir plus ou moins de fonctionnalités. Dans notre travail, nous sommes particulièrement intéressés par le TMS qui fournit des réponses détaillées. La figure 2.8 illustre le degré de sophistication qu’un TMS peut atteindre en fournissant plus ou moins d’éléments dans ses réponses. D’après le type d’information fournie par le TMS, Seamons et ses collègues ont identifié deux modes de fonctionnement des systèmes de gestion de la confiance (Seamons et al. 2002). Dans notre travail, nous distinguons quatre modes, qui se résument comme suit : – mode 1 : dans ce mode, le TMS produit une réponse booléenne (confiance/ aucune confiance) qui indique si les identifiants fournis satisfont à la politique ; – mode 2 : en plus de la réponse booléenne, dans ce mode, le TMS fournit une justification, lorsque la demande est refusée, qui indique quelles conditions de la politique les identifiants fournis n’ont pas pu satisfaire ; – mode 3 : dans ce mode, le TMS fournit une réponse, une justification et une explication lorsque la politique est satisfaite. L’explication contient tous les identifiants qui satisfont à la politique ; – mode 4 : ce dernier mode étend le troisième mode car il fournit une explication détaillée. L’explication détaillée est obtenue en fournissant tous les sous-ensembles d’identifiants qui satisfont aux exigences de la politique.

72

Cybervigilance et confiance numérique

Les modes 1 et 2 sont souvent utilisés par le propriétaire de la ressource pour vérifier si les identifiants fournis par son interlocuteur satisfont à sa politique, tandis que les modes 3 et 4 sont utilisés par le demandeur pour déterminer si les identifiants qu’il possède (et quel sous-ensemble de justificatifs) satisfont la politique déclarée par le propriétaire de la ressource. Ces derniers modes ont été particulièrement introduits dans le contexte de la négociation de la confiance que nous aborderons dans la section suivante. 2.4.4. Négociation automatisée de la confiance La négociation automatisée de la confiance (ATN) est une approche de gestion de la confiance dans laquelle la confiance s’établit par la divulgation graduelle, itérative et mutuelle des identifiants et des politiques de contrôle d’accès (Yu 2003 ; Ryutov et al. 2005). Contrairement aux systèmes traditionnels de gestion de la confiance présentés dans la section précédente, l’approche de négociation automatisée de la confiance considère les identifiants comme des ressources de première classe qui devraient être protégées par des politiques de diffusion dédiées. Par conséquent, les systèmes ATN offrent aux utilisateurs un contrôle plus fin et plus souple sur la divulgation des données potentiellement sensibles transmises par leurs identifiants (Ryutov et al. 2005 ; Yagüe 2006 ; Lee 2008). Cependant, la négociation fait généralement référence au processus par lequel les agents peuvent s’entendre sur des questions d’intérêt commun (Parsons et Wooldridge 2002). Nous adaptons cette définition bien établie à l’adaptation négociée des politiques de confiance. DÉFINITION 2.5. Négociation automatisée de la confiance.– La négociation automatisée de confiance est un processus itératif au cours duquel deux agents en interaction parviennent à un accord sur les identifiants qu‘ils sont prêts à divulguer pour gagner la confiance de l’autre. L’introduction de la négociation fiduciaire présente plusieurs avantages. Premièrement, elle reflète mieux la nature asymétrique de la confiance. Cela nous permet également d’établir une confiance bilatérale puisque les deux participants à une interaction peuvent demander des identifiants l’un à l’autre. Enfin, cela nous permet d’avoir une gestion de la confiance plus flexible puisque la confiance s’établit graduellement et progressivement. La recherche sur la négociation de la confiance s’est principalement concentrée autour de deux problématiques : (a) faire en sorte que les négociations aboutissent et (b) faire en sorte que les négociations réussissent. La première question traite des conditions de la négociation sur la confiance, tandis que la seconde porte sur les stratégies de négociation sur la confiance. Les exigences sont en

Systèmes de gestion de la confiance

73

outre divisées en exigences relatives aux systèmes de gestion de la confiance et en exigences relatives aux langages de spécification des politiques. La négociation de la confiance est intrinsèquement un processus axé sur la stratégie, car le choix fait par l’individu influe sur le nombre d’identifiants qu’il délivre et le temps qu’il faut pour accomplir cette tâche (Lee 2008). Par conséquent, les recherches récentes dans le domaine de la négociation de la confiance se sont principalement concentrées sur la proposition de stratégies et de protocoles de négociation efficaces et optimisés. En général, cependant, les stratégies de négociation mises en œuvre se répartissent en trois catégories : les stratégies enthousiaste, parcimonieuse et prudente (Grandison 2003) : – stratégie enthousiaste : dans la stratégie enthousiaste, les participants à la négociation adoptent une position naïve dans laquelle ils divulguent presque tous les identifiants qu‘ils possèdent. La négociation est considérée comme réussie lorsque chaque participant a reçu suffisamment d’identifiants pour être assuré de l’interaction dans laquelle il est engagé. Le principal avantage de cette stratégie est qu’elle n’exige pas l’utilisation de politiques de libération et qu’elle minimise le temps de négociation (Ardagna et al. 2007). Cependant, cette stratégie augmente le nombre d’identifiants divulgués et, par conséquent, les données sensibles divulguées ; – stratégie parcimonieuse : avec cette stratégie, les participants n’échangent que les demandes d’identifiants (aucun identifiant n’est délivré) et essaient de trouver une séquence possible de divulgation des identifiants qui peut mener à une négociation réussie (Grandison 2003). De plus, dans la stratégie parcimonieuse, seuls les identifiants qui sont explicitement demandés sont libérés. Contrairement à la stratégie enthousiaste, la stratégie parcimonieuse minimise l’exposition des identifiants mais augmente considérablement le temps de négociation sans aucune garantie de succès ; – stratégie prudente : il s’agit d’un mélange des deux stratégies ci-dessus. Une stratégie avide est appliquée aux identifiants qui ne sont pas sensibles, et une stratégie parcimonieuse est utilisée pour les identifiants sensibles. Cette stratégie s’est avérée plus efficace que les autres stratégies dans les situations où la négociation implique la divulgation d’identifiants sensibles et non sensibles (Yu et al. 2000). 2.5. Classification des systèmes de gestion de la confiance Étant donné la multiplicité des systèmes de gestion de la confiance4, on peut soutenir qu’une comparaison entre eux n’est ni possible ni souhaitable. Cependant, 4. D’après la liste des enquêtes consacrées à ce sujet, par exemple (Grandison 2003 ; Yu 2003 ; Yao 2004 ; Ruohomaa et Kutvonen 2005 ; Gray 2006 ; Yagüe 2006 ; Bandara et al. 2007 ;

74

Cybervigilance et confiance numérique

nous pensons que d’un point de vue plus élevé et avec un bon niveau d’abstraction, une comparaison de tous ces systèmes n’est pas seulement possible, mais qu’elle vaut aussi la peine d’être réalisée. Dans la présente section, nous passons en revue une sélection de systèmes de gestion de la confiance. Ces systèmes sont divisés en systèmes décentralisés de gestion de la confiance (DTM) et en systèmes automatisés de négociation de la confiance. Les systèmes DTM sont en outre divisés en TMS basés sur les autorisations (ABTMS) et TMS basés sur les rôles. Ces systèmes sont présentés dans l’ordre chronologique de leur publication. Nous pensons que le respect de cette causalité chronologique aide le lecteur à comprendre les éléments clés qui ont motivé la contribution de chaque système. Chaque système est décrit en fonction des concepts clés de gestion de la confiance que nous avons présentés ci-dessus, à savoir les identifiants, les politiques et les moteurs de confiance. En ce qui concerne les identifiants, nous nous intéressons à la nature de l’information utilisée par chaque système pour obtenir la confiance et au formalisme utilisé pour l’exprimer. Pour les politiques, nous nous concentrerons sur le type, la sémantique, l’expressivité et la flexibilité du formalisme utilisé pour représenter les politiques. Enfin, pour les moteurs de confiance, nous mettrons l’accent sur la capacité de négociation et le mode de réponse. 2.5.1. Systèmes de gestion de la confiance basés sur l’autorisation La catégorie des TMS basés sur les autorisations concerne les systèmes qui ont été les pionniers de l’approche de gestion de la confiance. Si la plupart de ces systèmes sont aujourd’hui considérés comme obsolètes, les mécanismes qu’ils proposent restent valables et sont à la base de la plupart des systèmes modernes de gestion de la confiance. Ils héritent des modèles de l’IBAC et de l’ABAC. Ils construisent une chaîne de confiance afin d’associer le détenteur d’un justificatif à l’autorisation pour laquelle on peut lui faire confiance. PolicyMaker (Blaze et al. 1996) PolicyMaker est la première application estampillée en tant que système de gestion de confiance. Ce système introduit le concept d’identifiants et de politiques programmables au moyen d’un langage d’assertion. La syntaxe d’une affirmation est : Source ASSERTS Subject WHERE Filter

[2.1]

Fernandez-Gago et al. 2007 ; Jøsang 2007 ; Jøsang 2007 ; Jøsang et al. 2007 ; Krukow et al. 2008 ; Artz et Gil 2010 ; Braghin 2011 ; Saadi et al. 2011 ; Liu 2011 ; Firdhous et al. 2012).

Systèmes de gestion de la confiance

75

La syntaxe ci-dessus peut être utilisée pour spécifier à la fois les identifiants et les politiques. Ici, l’énoncé représente un identifiant par lequel une source autorise un sujet à effectuer des actions qui sont acceptées par le filtre (c’est-à-dire un programme interprété). La principale différence entre un identifiant et une politique est que, dans les politiques, le terme « politique » (policy) est toujours utilisé comme source de l’affirmation. Par exemple, nous pouvons utiliser l’assertion donnée ci-dessous pour autoriser l’entité détenant la clé publique « rsa:123 » à accéder à toutes les ressources partagées entre la communauté. policy ASSERTS ‘‘rsa:123’’ WHERE filter to access all shared resources

[2.2]

Dans PolicyMaker, une assertion (qu’il s’agisse d’un identifiant ou d’une politique) est utilisée pour indiquer que la source (ou l’application locale dans le cas d’une politique) fait confiance au détenteur de clé pour effectuer les actions acceptées par le filtre. Cependant, le formalisme utilisé pour chiffrer les clés est laissé à l’application en utilisant PolicyMaker, donc PolicyMaker est générique par rapport au schéma de chiffrement des clés. La sémantique des opérations et l’exécution des décisions d’évaluation de la confiance sont également laissées à l’application. En règle générale, l’application fournit au moteur de confiance PolicyMaker un ensemble d’actions demandées, un ensemble d’identifiants et une politique. L’objectif de PolicyMaker est de vérifier si les identifiants forment une chaîne de délégation grâce à laquelle l’action peut être liée à la clé des clés. PolicyMaker répond ensuite par une réponse (« Trust » ou « False ») et c’est à l’application d’interpréter cette réponse et de prendre la décision appropriée. Le fonctionnement du moteur PolicyMaker est similaire à l’architecture décrite dans la figure 2.7 (section 2.4.2). PolicyMaker n’est pas favorable à la négociation. Les politiques sont évaluées de manière statique et indépendante du contexte. Enfin, PolicyMaker ne peut pas être utilisé pour gérer des ressources appartenant à plus d’une personne. Dans PolicyMaker, le choix du langage de spécification de la politique est laissé ouvert, ce qui rend l’évaluation de la politique indécidable dans la plupart des cas (Grandison 2003). KeyNote (Blaze et al. 1999b), son successeur, surmonte cet inconvénient et impose que les politiques soient écrites dans une langue spécifique. KeyNote effectue également la vérification cryptographique, qui a été laissée à l’application dans PolicyMaker. REFEREE (Chu et al. 1997) REFEREE (Rule-controlled Environment For Evaluation of Rules and Everything Else) est un système de gestion de confiance commun W3C et AT&T utilisé pour le

76

Cybervigilance et confiance numérique

contrôle d’accès aux documents web. Le système a été développé sur la base de l’architecture PolicyMaker, mais le fonctionnement du système est différent. Ici, les fournisseurs de ressources (c’est-à-dire les auteurs de contenu web) tentent de gagner la confiance du consommateur de ressources (c’est-à-dire le visiteur du site). Le système était essentiellement utilisé pour empêcher les mineurs d’accéder à des contenus illégaux. Le système utilise les labels PICS (Platform for Internet Content Selection) comme identifiants que le moteur de confiance REFEREE (un plug-in de navigateur) évalue en fonction d’une politique locale. Profiles-0.92 est un langage de politique basé sur des règles qui a été conçu pour REFEREE. Comme l’illustre l’encadré 2.1, chaque politique est une « s-expression » qui est évaluée de haut en bas. (((invoke "load-label" STATEMENT-LIST URL "http://www.emse.fr/") (false-if-unknown (match (("load-label" *) (service "http://www.emse.fr/CA.html") * (ratings (RESTRICT > trust 2))))) STATEMENT-LIST)) Encadré 2.1. Exemple d’une politique spécifiée dans Profiles-0.92 (source : adapté de (Chu et al. 1997))

Cette politique stipule que tout document ayant une étiquette (certifiée par l’EMSE) avec une cote de confiance supérieure à 2 peut être consulté par l’utilisateur. La correspondance entre les étiquettes et les conditions spécifiées dans la politique est purement syntaxique. Il appartient donc à l’application et à l’institution étiqueteuse de définir sa sémantique. Le moteur de confiance REFEREE évalue la politique ci-dessus en deux étapes. Tout d’abord, il essaie de trouver et de télécharger les étiquettes fournies par le serveur, dont l’URL a été spécifiée dans la politique. Ensuite, un filtrage par motifs est lancé pour trouver une étiquette avec une note de confiance. Si la cote est supérieure à 2, le résultat de l’évaluation est vrai, sinon, le résultat est faux et si aucune étiquette n’est trouvée, le résultat est inconnu. Ainsi, le moteur de confiance REFEREE met en œuvre une logique à trois valeurs, notamment pour la gestion de la signification de l’inconnu (Chu et al. 1997 ; Grandison 2003).

Systèmes de gestion de la confiance

77

Binder (DeTreville 2002) Binder est le premier système de gestion de la confiance qui utilise un langage logique (DeTreville 2002). La particularité de Binder réside dans sa spécification explicite de la délégation de droits par l’extension de Datalog avec la construction says (Ceri et al. 1989). Dans le classeur, les identifiants représentent les clés que les détenteurs utilisent pour signer les assertions de délégation. Ensuite, des politiques sont utilisées pour filtrer ces affirmations et les mettre en correspondance avec leurs auteurs. Le langage de spécification proposé dans Binder nous permet d’exprimer deux types de déclarations : les croyances et les politiques. Par exemple, la déclaration suivante est utilisée par un individu A pour déclarer qu’un autre individu B est digne de confiance pour rejoindre sa communauté et pour lire ses dossiers personnels. can(B, read, MyFile). can(B, join, MyCommunity). can(X, join, MyCommunity) :-Y says trust(Y,X), can(Y,join,MyCommunity) Encadré 2.2. Exemples de déclarations Binder (croyances et politiques)

Cet exemple illustre également la déclaration des politiques dans Binder. Dans cet exemple, la politique stipule que si A fait confiance à un individu Y pour rejoindre sa communauté et que Y fait confiance à un autre individu X, ce dernier peut également faire confiance pour rejoindre la communauté. Il convient de noter dans la présente politique l’utilisation de la construction says. Le rôle du moteur de confiance Binder est d’évaluer les politiques par rapport aux affirmations locales (c’est-à-dire les croyances) et aux affirmations faites par d’autres (c’est-à-dire les croyances des autres). La principale nouveauté du système réside dans l’ajout de construction says à chaque fois qu’une assertion est reçue d’autres personnes. En effet, chaque fois qu’une personne envoie une assertion, le moteur de confiance Binder transforme cette assertion en un certificat, qui est signé avec la clé privée de l’émetteur. Ensuite, ces assertions sont envoyées à d’autres moteurs Binder afin de prendre des décisions de confiance. Lorsqu’une assertion est reçue, Binder vérifie la validité du certificat et cite automatiquement l’assertion avec la construction « says » pour les distinguer des assertions locales. SULTAN (Grandison 2003) SULTAN (Simple Universal Logic-based Trust Analysis) est un TMS qui a été proposé pour la spécification et l’analyse des relations de confiance et de recommandation (Grandison 2003). Dans SULTAN, les identifiants représentent des

78

Cybervigilance et confiance numérique

déclarations certifiées sur l’identité, la qualification, l’évaluation des risques, l’expérience ou les recommandations. Le système est doté d’un langage de spécification des politiques dans lequel les politiques sont utilisées pour spécifier deux types de politiques : les politiques de confiance/méfiance et les politiques de recommandation positive/négative. En fait, les politiques de confiance correspondent au sens classique des politiques utilisées ici, tandis que les politiques de recommandation sont des énoncés par lesquels les individus font des recommandations aux autres. Dans ce qui suit, nous fournissons la syntaxe utilisée pour spécifier les deux types de politiques : PolicyName: trust(Tr, Te, As, L) ← Cs

[2.3]

La politique ci-dessus représente une politique de confiance en vertu de laquelle un fiduciant (Tr) fait confiance (ou ne fait pas confiance) dans une certaine mesure (L – le niveau de confiance) à un fiduciaire (Te) relativement à un ensemble de mesures (As) et si les conditions tiennent (Cs). De même, la politique de recommandation définie ciaprès précise que l’entité établissant la recommandation (Rr) recommande à un niveau de recommandation (L) l’agent recommandé (Re) pour effectuer l’action (As) si les conditions (Cs) se maintiennent. PolicyName: recommend(Rr, Re, As, L) ← Cs

[2.4]

Le moteur de confiance SULTAN est chargé de collecter les informations nécessaires à l’évaluation de la politique, de prendre des décisions concernant les relations de confiance et de surveiller l’environnement dans la perspective de réévaluer les relations de confiance existantes. Ponder (Damianou et al. 2001) Ponder n’est qu’un langage de politique pour lequel il n’y avait pas de système de gestion de la confiance associé (Damianou et al. 2001). Ponder est le premier langage de politique orienté objet qui adopte une approche basée sur les rôles. Néanmoins, bon nombre des caractéristiques proposées par ce langage ont inspiré d’autres systèmes, ce qui explique notre motivation à le revoir. Ponder est un langage déclaratif, qui peut être utilisé pour la spécification de quatre types de politiques, à savoir l’autorisation, l’obligation, le réfrènement et la délégation. Ponder a été le pionnier de l’utilisation d’une approche déontique, réutilisée plus tard par d’autres langues comme le Rei (Kagal et al. 2003) et le KAos (Uszok et al. 2003, 2004). De plus, la principale nouveauté de Ponder réside dans les constructions qu’il fournit pour la mise à jour, l’organisation et le traitement des politiques d’exécution en fonction du contexte de l’environnement. L’exemple suivant est une instanciation d’un type de politique d’autorisation positive appelé droits (rights). La politique spécifie que les membres (members, les

Systèmes de gestion de la confiance

79

sujets de la politique) peuvent modifier les objets cibles de type fichier qui sont stockés dans l’espace commun de la communauté com : type auth+ rights(member, target com) {action modify() ; }

[2.5]

Un autre aspect intéressant des politiques de Ponder réside dans le fait que les sujets et les objets auxquels une politique s’applique peuvent être regroupés. Dans l’exemple ci-dessus, la politique concerne tous les membres de la communauté et tous les dossiers, ce qui rend la factorisation des droits implicite et plus efficace que ce qui peut être exprimé dans les modèles RBAC ou tout autre système de gestion de confiance basé sur les rôles. De plus, les auteurs supposent que leur langage est flexible, évolutif et extensible ; flexible dans la mesure où il nous permet de réutiliser les politiques puisqu’il nous permet de créer de nombreuses instances d’une même politique pour de nombreuses conditions différentes ; évolutif dans la mesure où il permet la définition de politiques composites et extensible dans la mesure où il accepte la définition de nouveaux types de politiques qui peuvent être considérés comme des sous-classes des politiques existantes, grâce à une approche orientée objet. Toutefois, en raison de l’absence de mise en œuvre, aucune de ces propriétés ne s’est avérée valide. Récemment, Ponder a été repensé, en tant que Ponder2, pour augmenter la fonctionnalité des politiques d’autorisation (par exemple, des opérateurs pour tous les objets gérés ont été ajoutés). Contrairement à la version précédente, conçue pour la gestion générale des réseaux et des systèmes, Ponder2 a été conçu comme un cadre entièrement extensible qui peut être utilisé à différentes échelles : des petits appareils embarqués aux services complexes et aux organisations virtuelles. 2.5.2. Systèmes de gestion de la confiance basés sur les rôles Dans les TMS basés sur les autorisations, la délégation de pouvoir est utilisée de façon très restrictive. Par exemple, dans PolicyMaker, un membre de la communauté ne peut pas simplement spécifier que « tous les membres de ma communauté peuvent accéder à mes ressources ». Dans ces systèmes, la solution serait que le membre de la communauté délègue le droit aux membres qu’il connaît et autorise ces membres à déléguer davantage le droit à chaque membre qu’il connaît. Cette approche rend la décision relative à la confiance complexe et difficile à gérer et à contrôler (par exemple, un membre peut déléguer ce droit à des non-membres). En réponse, une nouvelle génération de systèmes de gestion de la confiance basés sur les rôles qui tirent parti de la force de la RBAC et des approches de gestion de la confiance a été utilisée. De RBAC, les TMS basés sur les rôles empruntent le concept

80

Cybervigilance et confiance numérique

de rôle, et de la gestion de confiance, ils empruntent la délégation et la certification des identifiants distribués. L’utilisation combinée des rôles et de la gestion distribuée des identifiants rend ces systèmes pratiques pour les systèmes à grande échelle tels que les communautés virtuelles. IBM Trust Establishment (Herzberg et al. 2000) IBM Trust Establishment (IBM-TE) est un système de gestion de la confiance basé sur les rôles développé par IBM pour les applications e-commerce. L’objectif principal d’IBM-TE est d’associer les détenteurs d’identifiants à des groupes. Les identifiants sont spécifiés dans un langage générique, mais le système fournit des mécanismes de transcodage pour gérer X.509. Les identifiants sont utilisés pour authentifier les utilisateurs, tandis que les politiques sont utilisées pour exprimer des restrictions sur la façon dont un détenteur d’identifiants pourrait appartenir à un groupe. Les groupes sont utilisés dans le sens de rôles, qui sont mappés aux autorisations (section 2.3.4). IBM-TE est livré avec un langage de spécification de politique basé sur XML appelé Trust Policy Language (TPL). Un exemple illustrant la syntaxe TPL est donné dans l’encadré 2.3.





1



Encadré 2.3. Un fragment d’une politique TPL spécifiant une règle d’adhésion

Systèmes de gestion de la confiance

81

La politique ci-dessus est utilisée pour ajouter un nouveau membre au groupe « Communauté » (rôle). La politique stipule qu’un nouveau membre peut être admis s’il peut fournir deux recommandations des membres existants. Pour cela, deux balises XML sont utilisées : inclusion et fonction. La balise d’inclusion définit les identifiants que le demandeur doit fournir (par exemple, deux identifiants de recommandation), tandis que la balise de fonction nous permet de définir des conditions supplémentaires par rapport aux identifiants demandés (par exemple, les recommandations doivent être supérieures à, GT, 1). Le moteur de confiance traite les identifiants de manière traditionnelle. En même temps que sa demande, le demandeur fournit l’ensemble des identifiants qu’il possède. Ces identifiants sont ensuite évalués par le moteur pour déterminer le groupe auquel le demandeur peut être rattaché (Herzberg et al. 2000). Cadre de gestion de la confiance basé sur les rôles (Li et al. 2002) Le cadre de gestion de la confiance basé sur les rôles (RT) a d’abord été conçu pour appuyer la prise de décisions en matière de confiance dans des environnements de collaboration (Li et al. 2002). Dans RT, les rôles sont représentés sous forme d’attributs, de sorte qu’une personne est considérée comme appartenant à un rôle si elle possède un justificatif dans lequel l’identificateur de rôle est spécifié. Contrairement à IBM-TE, RT utilise une extension de Datalog (Ceri et al. 1989) pour représenter à la fois les identifiants et les politiques. Dans RT, les termes identifiant et politique sont utilisés de façon interchangeable. Cependant, RT utilise le terme certificat en référence à la signification des titres de compétence que nous utilisons. Le formalisme utilisé pour spécifier les certificats n’a pas été défini, mais certaines approches ont prouvé la compatibilité de la RT avec X.509 et PGP et tout mécanisme de certification utilisant PKI. La syntaxe utilisée pour spécifier les politiques est définie comme suit : Com.evaluator(?X ) ← Com.recommender(?X ) ∧ Com.Member

[2.6]

La politique ci-dessus stipule que tout membre de la communauté qui a recommandé un autre membre est autorisé à l’évaluer. Le langage de spécification de la politique de RT se décline en cinq versions : RT0, RT1, RT2, RTT et RTD (Li et al. 2002). RT0 est le langage de base qui supporte les hiérarchies de rôles, la délégation des pouvoirs sur les rôles, l’intersection des rôles et la délégation des pouvoirs basée sur les attributs. RT1 ajoute à RT0 la possibilité d’ajouter des paramètres aux rôles (par exemple, dans la politique précédente, l’évaluateur et les rôles de recommandation sont dotés de paramètres), et RT2 ajoute aux objets logiques RT1. Ils représentent un moyen de regrouper (logiquement) les ressources des modes d’accès afin de faciliter la spécification des politiques. La RTT ajoute des seuils aux rôles, tandis que la RTD

82

Cybervigilance et confiance numérique

prend en charge la délégation de l’activation des rôles (c’est-à-dire les rôles qui ne sont actifs que dans un contexte spécifique). Cassandra (Becker et Sewell 2004) Cassandra est un TMS qui vise à permettre aux individus impliqués dans des systèmes potentiellement à grande échelle (par exemple les systèmes P2P) de partager leurs ressources respectives sous réserve des politiques locales (Becker et Sewell 2004). Le système a été principalement déployé dans le contexte du contrôle d’accès aux dossiers de santé électroniques. Cassandra est basé sur les rôles et supporte les références X.509. Les politiques de Cassandra sont exprimées dans un langage basé sur le Datalog avec des contraintes (Ceri et al. 1989). Par exemple, une politique peut stipuler qu’une personne A peut déléguer le rôle de modérateur tant qu’elle s’engage à assumer le rôle d’administrateur. Cette politique est spécifiée à l’aide du constructeur canActivate() comme suit : canActivate(B, moderator) ← hasActivated(A, admin)

[2.7]

Cassandra offre des mécanismes de délégation souples qui facilitent la spécification explicite des longueurs de délégation (Becker et Sewell 2004 ; De Coi et Olmedilla 2008). En outre, Cassandra propose un mécanisme de révocation des rôles, y compris la révocation des rôles en cascade (par exemple, si une personne est révoquée de son rôle, toutes les personnes auxquelles elle a délégué le rôle sont également révoquées). Enfin, le langage de politique de Cassandra facilite la spécification des hiérarchies de rôles. Le moteur de confiance Cassandra n’est disponible qu’en tant qu’implémentation de preuve de concept dans OCaml. La caractéristique principale du moteur est la mise en œuvre de la sémantique des politiques de Cassandra pour leur évaluation. 2.5.3. Systèmes automatisés de négociation de la confiance Dans la gestion de la confiance, une décision de confiance vient après un processus d’interaction complexe, où les parties échangent des politiques et des identifiants. Traditionnellement, au début de TMS, la confiance est établie de manière unidirectionnelle : le propriétaire de la ressource est présumé avoir la confiance du demandeur. Par conséquent, avant de manipuler la ressource, le demandeur doit fournir ses identifiants pour savoir si sa demande est acceptée ou non. De ce fait, si la demande n’était pas acceptée, le demandeur aurait inutilement divulgué ses identifiants (qui contiennent des données sensibles telles que son identité, son âge ou son adresse). Partant, pour des raisons de protection de la vie privée, une telle approche n’est pas acceptable. À cette fin, plusieurs TMS basés sur la négociation ont été proposés.

Systèmes de gestion de la confiance

83

TrustBuilder (Yu et al. 2003) TrustBuilder a été le premier TMS à introduire le concept de négociation de la confiance. TrustBuilder utilise des certificats X.509 et des politiques TPL (section 2.5.1.1). Les auteurs ont également réutilisé le moteur IBM-TE pour l’évaluation des politiques. Par conséquent, TrustBuilder peut être considéré comme une extension d’IBM-TE pour inclure des fonctionnalités de négociation. La principale nouveauté de ce système réside dans sa gestion rationnelle de la divulgation des identifiants. Pour ce faire, le moteur de confiance est doté d’un module de négociation dans lequel des stratégies sont utilisées pour déterminer la divulgation sécuritaire des identifiants pour les deux parties impliquées dans l’interaction.

Figure 2.9. Architecture du TMS TrustBuilder

Comme l’illustre la figure 2.9, le moteur TrustBuilder est divisé en trois sousmodules : module de vérification des identifiants, module de négociation et module de vérification de conformité. L’élément central de cette architecture est le module de négociation qui est responsable de l’application des stratégies de négociation. L’objectif d’une stratégie de négociation est de minimiser la divulgation des identifiants. Pour ce faire, TrustBuilder évalue de façon itérative la politique de l’interlocuteur et l’ensemble des identifiants locaux pour calculer l’ensemble minimal des identifiants qui satisfont à cette politique (figure 2.9). Récemment, Lee et ses collègues ont proposé une extension de TrustBuilder qu’ils ont appelée TrustBuilder2 (Lee et al. 2009). Cette extension vise à doter le TMS de quatre fonctionnalités principales : la prise en charge de langages de politiques arbitraires, la

84

Cybervigilance et confiance numérique

prise en charge de formats d’identifiants arbitraires, l’intégration de stratégies de négociation interchangeables et une gestion flexible des politiques et des identifiants. Fidelis (Yao 2004) Fidelis est un TMS issu du projet d’architecture d’autorisation distribué par OASIS (Open Architecture for Secure, Interworking Services). Fidelis utilise les clés X.509 et PGP comme identifiants, et les politiques et identifiants sont systématiquement spécifiés par des entités distinctes. Fidelis distingue deux types d’entités : les principes simples et les principes composites. Les principes simples sont en fait des clés publiques, tandis que les principes composites sont des groupes de clés publiques (par exemple, groupes ou communautés). Le langage de politiques Fidelis (FPL) est l’élément central du système. Le langage est capable d’exprimer des recommandations et des déclarations de confiance. La syntaxe de la langue est présentée dans l’exemple suivant. any-statement: ind -> statement asserts any-statement: self -> statement where ind == 0x14ba9b925 || ind == 0x5918b01a ||... Encadré 2.4. Une politique de délégation à l’aveugle dans Fidelis

Cette politique représente un type particulier de politique de délégation, appelée « délégation à l’aveugle ». Elle est utilisée pour établir la confiance « aveugle » d’un individu et affirmer toutes les affirmations faites par d’autres individus. Dans cet exemple, le groupe de personnes de confiance est limité par la variable ind. En plus de la LFP, les auteurs ont élaboré un cadre de négociation de la confiance dans lequel des métapolitiques sont utilisées pour préciser les politiques de négociation. Les métapolitiques sont conçues pour exprimer quatre types de conditions quant au moment où un titre de compétence peut être divulgué : l’information sur le principal désigné, l’information contextuelle, l’information axée sur la confiance et l’exclusion mutuelle (Yao 2004). Par exemple, la métapolitique suivante est utilisée pour divulguer l’état de fiducie T2(a, b) : self -> p (qui sert ici d’identifiant) lors de la négociation avec le détenteur de clés 0xb258d29f. negotiator(): self -> 0xb258d29f grants disclose(T2(a, b): self->p) Encadré 2.5. Une métapolitique de divulgation des identifiants dans Fidelis

Systèmes de gestion de la confiance

85

Fidelis ne gère pas les stratégies de négociation standards. Ainsi, la propriété de terminaison n’est pas garantie, ce qui rend l’évaluation d’une politique indécidable dans de nombreuses situations. Enfin, Fidelis fait la distinction entre les politiques statiques et les politiques en direct. Les politiques statiques ne dépendent pas des variables d’environnement (par exemple, la date et l’heure) à évaluer, tandis que les politiques en direct doivent être interrogées dynamiquement et adaptées à chaque requête. Néanmoins, les politiques en direct n’ont été utilisées que dans le contexte de la négociation telle que présentée ci-dessus et aucun mécanisme d’adaptation n’a été proposé, comme la description peut le suggérer. Trust-X (Bertino et al. 2003) Trust-X est un TMS qui a été conçu pour la négociation de la confiance dans les systèmes d’égal à égal (Bertino et al. 2003, 2004). Il est construit sur deux blocs : les profils X et X-TNL. Les profils X sont des structures de données utilisées pour stocker les identifiants des utilisateurs ainsi que des déclarations non certifiées contenant des informations les concernant (par exemple, âge, adresse postale et adresse). X-TNL signifie langage de négociation de la confiance basé sur XML. X-TNL a été développé pour la spécification des certificats Trust-X et des politiques de divulgation.



//employee number[@code=Rental Car.requestCode]

/.../[position=driver]



Encadré 2.6. Exemple de spécification de politique X-TNL

86

Cybervigilance et confiance numérique

Le code dans l’encadré 2.6 montre un exemple de politique X-TNL définie par une agence de location de voitures. L’agence s’adresse aux conducteurs de la société Corrier, qui fait partie de l’agence pour louer des voitures sans payer. Cette politique peut être satisfaite en fournissant un identifiant, qui est également spécifié à l’aide du X-TNL. La syntaxe d’un identifiant est décrite dans l’exemple fourni dans l’encadré 2.7.

Olivia White

Grange Wood 69 Dublin

Driver

Encadré 2.7. Exemple de profil X-TNL

Le moteur Trust-X fournit un mécanisme de gestion des négociations. La principale stratégie utilisée dans Trust-X consiste à publier des stratégies visant à réduire au minimum la divulgation des identifiants. Par conséquent, seules les lettres de créance nécessaires au succès d’une négociation sont effectivement divulguées (Squicciarini et al. 2007). Trust-X a donc recours à une stratégie prudente (section 2.4.4). Le principal aspect novateur proposé dans Trust-X consiste à utiliser des billets de confiance. Les billets de confiance sont émis à l’issue d’une négociation réussie. Ces billets peuvent ensuite être utilisés lors de négociations ultérieures pour accélérer le processus au cas où la négociation porterait sur la même ressource. De plus, Trust-X fournit un mécanisme pour protéger les politiques sensibles. Les politiques sont triées logiquement afin que la satisfaction d’une politique soit la condition préalable à la divulgation des politiques subséquentes. Récemment, Braghin (2011) a proposé une extension intéressante dans laquelle le cadre est utilisé pour gérer les négociations entre des groupes d’individus au lieu de les organiser seulement entre deux individus.

Systèmes de gestion de la confiance

87

XACML Le XML Access Control Markup Language (XACML) (Humenn 2003 ; Cover 2007) est une architecture générique de gestion de la confiance. Même si dans la plupart des travaux les certificats X.509 sont utilisés avec XACML. Ce cadre accepte n’importe quel format d’identifiants et est donc générique en ce qui concerne les identifiants. XACML est également un langage normalisé et interopérable de spécification de politiques pour exprimer et échanger des politiques à l’aide du XML. La syntaxe d’une règle XACML est définie comme suit :



urn:oasis:names:tc:xacml:1.0:subject:subject-id

urn:emc:edn:samples:xacml:resource:resource-owner



Encadré 2.8. Une simple politique « propriétaire » en XACML

La politique ci-dessus stipule que n’importe qui peut faire n’importe quoi avec ses propres dossiers. Par conséquent, dans XACML, les éléments constitutifs de la politique sont des règles. Chaque règle est composée de trois composantes principales : une cible, une condition et un effet (encadré 2.8). La cible définit la portée de la règle (c’est-à-dire le sujet, les actions et les ressources auxquelles la règle

88

Cybervigilance et confiance numérique

s’applique) ; la condition précise les restrictions sur les attributs du sujet et définit l’applicabilité de la règle et l’effet est soit un permis (la règle est alors appelée une règle de permis) ou un refus (la règle est ensuite appelée une règle de refus). Lorsqu’une demande atteint l’objectif de la règle et satisfait à la condition de la règle, la règle est appliquée et la décision spécifiée dans l’effet est construite. Sinon, la règle n’est pas applicable et la demande donne la décision NotApplicable (Li et al. 2009). Les politiques regroupent les règles qui se rapportent à la même cible et les politiques définissent les groupes de politiques qui se rapportent à la même cible. L’architecture du moteur de confiance est composée de plusieurs points, chacun représentant un module distinct : le point de décision politique (PDP) est le noyau de l’architecture où les politiques sont évaluées et les décisions prises ; le point d’application des politiques (PEP) est le point où les décisions sont appliquées (par exemple, l’émission d’une autorisation) ; le point d’extraction des politiques (PRP) est le point où les politiques sont sélectionnées et extraites des dépôts ; le point d’information sur les politiques (PIP) est le point où les renseignements sont recueillis dans la perspective de l’évaluation des politiques ; et le point d’administration des politiques (PAP) est le point où les politiques sont administrées (par exemple, spécifiées, actualisées, activées ou désactivées). Typiquement, le fonctionnement du moteur XACML peut être résumé comme suit. Le demandeur envoie une demande au PEP (généralement l’application utilisant le TMS), qui est ensuite envoyée au PDP, qui extrait les politiques applicables en utilisant le PRP. On demande ensuite au PIP de recueillir et de récupérer les identifiants requis pour l’évaluation de la politique. Pour cela, le PIP interagit avec le demandeur, les ressources et l’environnement pour extraire les attributs de chaque entité. Sur la base de ces données, le PDP évalue la politique et fournit une réponse ainsi qu’une obligation facultative. Ce résultat est transmis au PEP qui applique l’obligation et donne accès au demandeur si l’évaluation est positive. Récemment, Abi Haidar et al. (Abi Haidar et al. 2008) ont utilisé un profil RBAC étendu de XACML dans le contexte de XeNA (la négociation XACML d’accès), un cadre de négociation d’accès. XeNA réunit la négociation pour l’établissement de la confiance et la gestion du contrôle d’accès au sein d’une même architecture. Le moteur de confiance XeNA est basé sur TrustBuilder2 étendu pour supporter les politiques de contrôle d’accès et de négociation XACML. ATNAC (Ryutov et al. 2005) Adaptive Trust Negotiation and Access Control (ATNAC) est un TMS intégré qui combine deux systèmes existants : GAA-API et TrustBuilder (déjà présenté précédemment dans la section 2.5.2). GAA-API est un système générique d’autorisation et de

Systèmes de gestion de la confiance

89

contrôle d’accès qui saisit de façon dynamique les exigences de sécurité changeantes du système. Le système utilise les identifiants X.509 pour transmettre les informations entre les partenaires de négociation. ATNAC utilise TPL pour exprimer des politiques de confiance qui, en plus des propriétés du partenaire, font explicitement référence au niveau de suspicion du contexte (SL). Dans l’ATNAC, plusieurs politiques sont spécifiées et utilisées pour protéger la même ressource. La principale nouveauté du système réside donc dans le moteur de confiance qui surveille le niveau de suspicion de l’environnement (grâce à GAAI-API) et adapte la politique choisie en fonction de ce niveau de suspicion. Ce mécanisme est utilisé en ATNAC pour fournir une négociation de la confiance adaptative afin de contrer les attaques malveillantes.

Faible

Niveau de suspicion Moyen

R1 R2

En toute liberté

En toute liberté

En toute liberté

En toute liberté

En toute liberté

R3

En toute liberté

C1

C1 C1 et C2

Élevé

Tableau 2.2. Exemple de politiques utilisées dans ATNAC (source : adapté de (Ryutov et al. 2005))

Le tableau 2.2 illustre l’approche adaptative préconisée par l’ATNAC. Dans cet exemple, la ressource R1 n’est pas sensible et est donc divulguée indépendamment du niveau de suspicion. En revanche, R3 peut être librement divulgué dans le contexte d’une SL faible, qui exige un titre C1 lorsque la SL est moyenne, mais exige à la fois C1 et C2 lorsque la SL est élevée. PROTUNE (Bonatti et al. 2008) Le cadre Provisional Trust Negotiation (PROTUNE) est un système qui fournit des fonctions de gestion et de négociation de la confiance distribuée (Bonatti et Olmedilla 2005 ; Bonatti et al. 2008) aux services web. Le cadre PROTUNE fournit (a) un langage de gestion de la confiance, (b) un méta-langage déclaratif pour guider les décisions concernant la divulgation de l’information, (c) un mécanisme de négociation qui applique la sémantique du méta-langage, (d) une approche ontologique générale pour appuyer l’extension du langage politique et (e) un mécanisme avancé d’explication de politique qui peut indiquer les réponses « pourquoi », « pourquoi pas » et « comment » qui sont importantes pendant un processus de négociation. L’une des principales avancées de PROTUNE réside dans l’utilisation des déclarations et des identifiants au cours du processus d’évaluation des politiques. Les déclarations sont l’équivalent non signé des identifiants. Elles peuvent également être considérées comme des affirmations qui ne sont pas signées par une autorité de certification.

90

Cybervigilance et confiance numérique

Cependant, la partie la plus novatrice du projet reste le langage de spécification de la politique, qui combine le contrôle d’accès et les règles d’affaires de type provisoire. Dans PROTUNE, les politiques sont spécifiées en utilisant le langage de règles défini dans Bonatti et Olmedilla (2005). Le langage est basé sur des règles de programme logique étendues avec une syntaxe orientée objet5. allow(X,access(Resource)) :goodReputation(X), validID(C). validID(C) :credential(identity, C[subject:X]). goodReputation(X) :declaration(Y,X,reputation(R)), Y!= X, R > 50. Encadré 2.9. Exemple de politique d’accès PROTUNE

La politique PROTUNE ci-dessus stipule qu’une personne doit fournir un identifiant valide prouvant son identité et qu’elle doit avoir une bonne réputation pour obtenir l’accès à une ressource. Ce genre de politique s’appelle la politique d’accès. De même, PROTUNE met en œuvre des politiques de négociation au moyen de politiques de libération, qui précisent les conditions dans lesquelles un identifiant peut être délivré. Un exemple de cette ressource est fourni dans l’encadré 2.10. allow(release(credential(C[type:identity]))) :credential(ta, Cred[issuer:’Trusted Authories’]). Encadré 2.10. Exemple d’une politique de diffusion de PROTUNE

Cette politique stipule que les identifiants ne peuvent être divulgués qu’aux personnes qui fournissent un identifiant prouvant qu’elles appartiennent au groupe « Autorités de confiance ». 2.6. Gestion de la confiance dans les infrastructures de Cloud Computing Dans la présente section, nous examinons un exemple d’application récente des mécanismes de gestion de confiance. Nous sommes particulièrement intéressés par la 5. A.at: v signifie que l’individu A a l’attribut at et que cet attribut a la valeur v. Cette expression est en fait une abréviation du prédicat logique at(A, v).

Systèmes de gestion de la confiance

91

révision des modèles de confiance dans les infrastructures de Cloud Computing. La confiance dans le Cloud Computing a été abordée dans la littérature sous deux angles différents : le consommateur de services du Cloud (CSC) et le fournisseur de services de Cloud (CSP). Dans cette section, nous classons les approches existantes selon les deux perspectives. 2.6.1. Modèles de confiance basés sur les identifiants Ces modèles s’inspirent de l’approche préconisée dans les systèmes DTM présentés précédemment (section 2.5.1). Dans ces modèles, la confiance s’établit entre le CSP et le CSC à l’aide d’identifiants (c’est-à-dire certificats et/ou clés) délivrés par des tiers de confiance ou des autorités de certification. Une entité A fait confiance à une autre entité B si et seulement si elle reçoit les identifiants adéquats pour construire une chaîne de confiance qui relie B à A. Ce modèle reproduit l’approche du Web of Trust (WoT), dans laquelle chaque membre se porte garant l’un pour l’autre (AbdulRahman 1997 ; Abdul-Rahman et Hailes 2000). 2.6.2. Modèles de confiance basés sur les Service Level Agreements (SLA) Dans Noor et Sheng (2011), les auteurs ont proposé le cadre Trust as a Service (TaaS), dans lequel ils ont introduit un modèle de crédibilité adaptative qui distingue les rétroactions de confiance crédibles des rétroactions malveillantes en tenant compte de la capacité des consommateurs de services en Cloud et du consensus majoritaire de leurs réactions. Dans ce travail, la confiance a été abordée du point de vue des utilisateurs. Dans Habib et al. (2011), les auteurs proposent un modèle multifaces pour gérer la confiance dans les marchés du Cloud Computing. Le modèle recueille plusieurs attributs pour évaluer la fiabilité d’un fournisseur de services de Cloud. Ces attributs correspondent aux objectifs de niveau de service définis dans les SLA actifs. L’information en retour est également recueillie auprès de différentes sources et utilisée en même temps que les mesures des SLA pour obtenir une note de confiance pour chaque CSO. Les auteurs se réfèrent au CAIQ (Consensus Assessments Initiative Questionnaire)6 comme moyen d’extraire des informations sur la conformité aux SLA. Dans le modèle JRTM (Joint Risk and Trust Model) développé dans le cadre de l’A4Cloud (Accountability for Cloud) (Cayirci 2013), les données statistiques (c’est-àdire les preuves et indicateurs) collectées auprès de services tiers (c’est-à-dire un fournisseur TaaS) sont accumulées et calculées pour estimer la confiance qu’un client 6. https://Cloudsecurityalliance.org/articles/ccm-caiq-v3-0-1-soft-launch/.

92

Cybervigilance et confiance numérique

Cloud place sur un fournisseur de services Cloud spécifique. Le modèle s’appuie sur l’évaluation des risques liés à la sécurité et à la protection de la vie privée des services de Cloud pour obtenir une mesure de confiance. L’information utilisée comprend, par exemple, des statistiques sur le nombre d’incidents liés à la sécurité et à la protection de la vie privée auxquels le CSP a été soumis. 2.6.3. Modèles de confiance basés sur la rétroaction Dans ces modèles, la confiance se fonde sur les rétroactions, les cotes et les opinions que le CSP et le CSC expriment en fonction de leurs expériences passées l’un envers l’autre. Dans ces modèles, chaque entité (CSP et CSC) est responsable de la collecte, du traitement et du partage d’une mesure de réputation. En général, les rétroactions sont exprimées en fonction des paramètres commerciaux (par exemple, QoS) et de sécurité. Ainsi, l’objet d’une rétroaction peut être n’importe quelle propriété sur laquelle le CSP et le CSC peuvent s’évaluer mutuellement. Les retours d’information sont plus généralement comparés à la réputation. Toutefois, les modèles utilisés dans les modèles de confiance basés sur la réputation sont comparables au modèle utilisé pour la gestion de la rétroaction. La réputation est l’évaluation sociale d’un groupe, d’une communauté ou d’une société d’agents envers la fiabilité d’un individu (Sabater et Sierra 2001). Dans le DAI, et plus particulièrement dans les systèmes multi-agents, la réputation a été considérée comme une dimension substantielle de la confiance (Jøsang et Ismail 2002). Dans ce qui suit, nous passons en revue quelques modèles de réputation prédominants. ReGreT (Sabater et Sierra 2001) est un modèle de confiance et de réputation décentralisé bien connu pour le commerce électronique. Proposé par Sabater et Sierra en 2001, l’objectif principal de ReGreT était de faire des évaluations de confiance plus précises. Pour ce faire, les auteurs ont utilisé trois facteurs sur la base desquels la confiance a été calculée : l’expérience directe, la réputation mondiale et une réputation ontologique fine, qui définit les valeurs de réputation pour chaque caractère de l’individu utilisant l’ontologie. Dans ReGreT, le réseau auquel appartient l’agent est utilisé pour évaluer la crédibilité des informations fournies par chaque agent. Les relations sociales sont présentées sous la forme de règles floues, qui sont ensuite utilisées pour déterminer si l’information fournie par un témoin doit être prise en compte ou non. Jøsang (Jøsang et Ismail 2002) a proposé un modèle de réputation (appelé système de réputation bêta) pour la prise de décision dans le contexte des transactions électroniques. Les auteurs ont utilisé le concept de fiabilité ainsi que la probabilité de succès pour déterminer la fiabilité d’un partenaire. La fiabilité d’une personne est

Systèmes de gestion de la confiance

93

évaluée de façon directe et indirecte. La fiabilité directe est calculée sur la base des connaissances préalables sur le partenaire, tandis que la fiabilité indirecte est donnée sur recommandation d’autres tiers de confiance. La fiabilité indirecte est ensuite calculée en faisant la moyenne de toutes les recommandations pondérées par le degré de confiance du recommandataire. Ensuite, cette valeur est combinée avec la fiabilité directe afin d’obtenir un degré de confiance. Une fois ce degré de confiance obtenu, il forme une croyance qui est décrite comme un ensemble de propositions floues telles que « A croit que B est très digne de confiance ». FIRE (Huynh et al. 2006) est un autre modèle important conçu par Huynh et ses collègues pour les systèmes multi-agents. Ils calculent la confiance à partir des expériences passées, du rôle de l’agent, de sa réputation et d’une sorte de réputation certifiée. Les rôles servent à déterminer dans quelle mesure on peut faire confiance à un agent qui occupe une certaine position dans la société. L’idée principale est que la confiance dépend de l’accomplissement du rôle attribué à l’agent. En outre, les auteurs font une distinction entre la réputation des témoins et la réputation certifiée. La réputation certifiée est une réputation qui vient d’un témoin certifié et vraisemblablement digne de confiance, alors que la réputation normale vient de chaque agent de la société. 2.6.4. Modèles de confiance basés sur la prévision Dans Xie et al. (2013), les auteurs ont défini un modèle de prévision basé sur la similarité. Les entités (c’est-à-dire les utilisateurs et les fournisseurs de services de Cloud) sont représentées au moyen d’un vecteur de capacités et d’intérêts. Plus ces vecteurs sont similaires, plus la confiance peut s’établir entre eux. Dans Habib et al. (2011), les auteurs ont présenté un modèle de confiance basé sur le comportement, dans lequel la valeur de confiance dépend du comportement attendu du fournisseur de Cloud Computing. Le comportement du fournisseur est évalué en fonction d’attributs spécifiques tels que les mesures de sécurité, la conformité et le support client. Là encore, les auteurs se concentrent sur le point de vue de l’utilisateur qui essaie de choisir le meilleur fournisseur. 2.7. Conclusion Dans ce chapitre, nous avons présenté les concepts de base de la gestion de la confiance. Nous avons également examiné et analysé plusieurs systèmes de gestion de la confiance que nous avons classés selon les composantes de base des systèmes de gestion de la confiance, à savoir les identifiants, les politiques et les moteurs de confiance. Dans la dernière section, nous avons présenté comment ces concepts ont été utilisés dans les systèmes récents pour relever les nouveaux défis posés par l’informatique de Cloud.

94

Cybervigilance et confiance numérique

Tous les systèmes examinés s’appuient sur les identifiants dans leur processus de gestion de la confiance. Les pouvoirs sont utilisés entre les fiduciaires et les curateurs pour échanger des informations sur la base desquelles la confiance peut être établie. À cet égard, les identifiants sont essentiellement utilisés comme moyen d’instaurer la confiance entre des personnes qui se connaissent peu. En termes d’information, les systèmes sont divisés en trois catégories. Dans la première catégorie, les systèmes utilisent des identifiants pour prendre en charge l’authentification. Ces systèmes héritent des modèles de l’IBAC et utilisent des identifiants pour communiquer l’identité du détenteur (généralement une clé). D’autres systèmes tels que PolicyMaker utilisent des identifiants pour représenter une délégation de droits. Enfin, la dernière génération de TMS (par exemple TrustBuilder) utilise des identifiants fins, dans lesquels tous les attributs du titulaire peuvent être représentés (par exemple, âge, adresse, droits et rôles). Ces systèmes héritent d’ABAC et soulèvent la question de la confidentialité des identifiants, qui a motivé les systèmes de gestion de la confiance pour la négociation. Pour ce qui est de l’expressivité de l’état, tous les langages de politique examinés se déroulent de la même façon. Des conditions sont énoncées pour fixer des valeurs minimales qui sont acceptées pour chaque information. Ensuite, les politiques sont exprimées par une conjonction ou une disjonction de ces conditions. Cette approche a une expressivité limitée, car toutes les conditions énoncées dans une politique sont considérées comme étant d’égale importance. De plus, de nombreux langages de politique que nous avons examinés ont adopté une évaluation binaire : soit toutes les conditions sont considérées comme satisfaites, soit le système considère qu’aucune ne l’est (par exemple, TMS traditionnels). À cet égard, les systèmes de négociation de la confiance (TrustBuilder, Trust-X et PROTUNE) sont plus flexibles car l’évaluation de la politique est réalisée progressivement. Cependant, aucun système étudié ne gère l’évaluation partielle des politiques. Cette propriété rendrait possible le calcul du degré de satisfaction d’une politique même quand l’évaluation de toutes les conditions, incluses dans celle-ci, n’est pas possible. 2.8. Bibliographie Abdul-Rahman, A. (1997). The PGP Trust Model EDI-Forum. The Journal of Electronic Commerce, 10(3), 27–31.

Cette bibliographie est identique à celle de l’ouvrage correspondant en anglais publié par ISTE.

Systèmes de gestion de la confiance

95

Abdul-Rahman, A. and Hailes, S. (2000). Supporting trust in virtual communities. In Proceedings of the 33rd Hawaii International Conference on System Sciences Volume 6, HICSS ‘00, Washington, DC. IEEE Computer Society. p. 6007. ISBN 0z695-0493-0. Available: http://dl.acm.org/citation.cfm?id=820262.820322. Abi Haidar, D., Cuppens-Boulahia, N., Cuppens, F., and Debar, H. (2008). XeNA: An access negotiation framework using XACML. Annals of Telecommunications, 64 (1–2), 155–169. ISSN 0003-4347. doi: 10.1007/s12243-008-0050-5. Available: http://link.springer.com/10.1007/s12243-008-0050-5. Ardagna, C.A., Damiani, E., Capitani di Vimercati, S., Foresti, S., and Samarati, P. (2007). Trust management. In Security, Privacy, and Trust in Modern Data Management, Data-Centric Systems and Applications, Petković, M. and Jonker, W. (eds). Springer, Berlin, Heidelberg, pp. 103–117. ISBN 978-3-540-69860-9. doi: 10.1007/978-3-540-69861-6_8. Available: http://dx.doi.org/10.1007/978-3-54069861-6_8. Artz, D. and Gil, Y. (2010). A survey of trust in computer science and the Semantic Web. Web Semantics: Science, Services and Agents on the World Wide Web, 5(2), 58–71. ISSN 15708268. doi: 10.1016/j.websem.2007.03.002. Available: http://linking hub.elsevier.com/retrieve/pii/S1570826807000133. Bandara, A., Damianou, N., Lupu, E., Sloman, M., and Dulay, N. (2007). Policy-based management. In Handbook of Network and System Administration, Bergstra, J., and Burgess, M. (eds). Elsevier Science. Becker, M.Y. (2005). Cassandra: Flexible trust management and its application to electronic health records. Technical Report UCAM-CL-TR-648, University of Cambridge. Becker, M.Y. and Sewell, P. (2004). Cassandra: Distributed access control policies with tunable expressiveness. In Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY ‘04, Washington, DC. IEEE Computer Society. ISBN 0-7695-2141-X. Available: http://dl.acm.org/citation. cfm?id=998684.1006922. Bertino, E., Ferrari, E., and Squicciarini, A. (2003). X -tnl: An xml-based language for trust negotiations. In Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY ‘03, Washington, DC. IEEE Computer Society. ISBN 0-7695-1933-4. Available: http://dl.acm.org /citation.cfm?id=826036.826848.

96

Cybervigilance et confiance numérique

Bertino, E., Ferrari, E., and Squicciarini, A.C. (2004). Trust-x: A peer-to-peer framework for trust establishment. IEEE Trans. on Knowl. and Data Eng., 16(7), 827–842. ISSN 1041-4347. doi: 10.1109/TKDE.2004.1318565. Available: http://dx.doi. org/10.1109/TKDE.2004.1318565. Blaze, M., Feigenbaum, J., and Lacy, J. (1996). Decentralized trust management. In Proceedings of the 1996 IEEE Symposium on Security and Privacy, SP ‘96, Washington, DC. IEEE Computer Society. ISBN 0-8186-7417-2. Available: http://dl.acm.org/citation.cfm?id=525080.884248. Blaze, M., Feigenbaum, J., Ioannidis, J., and Keromytis, A.D. (1999a). The role of trust management in distributed systems security. In Secure Internet Programming, Vitek, J. and Jensen C.D. (eds). Springer-Verlag, London, pp. 185–210. ISBN 3-54066130-1. Available: http://dl.acm.org/citation.cfm?id=380171.380186. Blaze, M., Feigenbaum, J., and Keromytis, A. (1999b). Keynote: Trust management for public-key infrastructures. In Security Protocols, vol. 1550 of Lecture Notes in Computer Science, Christianson, B., Crispo, B., Harbison, W., and Roe, M. (eds). Springer Berlin Heidelberg. pp. 59–63. ISBN 978-3-540-65663-0. doi: 10.1007/3540-49135-X_9. Available: http://dx.doi.org/10.1007/3-540-49135-X_9. Boella, G. and van der Torre, L. (2005). Role-based rights in artificial social systems. In Proceedings of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology, IAT ‘05, Washington, DC. IEEE Computer Society. pp. 516–519. ISBN 0-7695-2416-8. doi: 10.1109/IAT.2005.123. Available: http://dx.doi.org/10.1109/ IAT.2005.123. Bonatti, P. and Olmedilla, D. (2005). Driving and monitoring provisional trust negotiation with metapolicies. In Proceedings of the Sixth IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY ‘05, Washington, DC. IEEE Computer Society. pp. 14–23. ISBN 0-7695-2265-3. doi: 10.1109/POLICY.2005.13. Available: http://dx.doi.org/10.1109/POLICY.2005.13. Bonatti, P., Juri, L., Olmedilla, D., and Sauro, L. (2008). Policy-driven negotiations and explanations: Exploiting logic-programming for trust management, privacy & security. Logic Programming, pp. 779–784. Available: http://link.springer.com/ chapter/10.1007/978-3-540-89982-2_76. Braghin, S. (2011). Advanced languages and techniques for trust negotiation. PhD Thesis, University of Insubria. Casimir, G., Lee, K., and Loon, M. (2012). Knowledge sharing: Influences of trust, commitment and cost. Journal of Knowledge Management, 16, 740–753. doi:10.1108/13673271211262781.

Systèmes de gestion de la confiance

97

Cayirci, E. (2013). A joint trust and risk model for msaas mashups. In Simulation Conference (WSC), 2013 Winter, December, pp. 1347–1358. doi:10.1109/WSC. 2013.6721521. Ceri, S., Gottlob, G., and Tanca, L. (1989). What you always wanted to know about datalog (and never dared to ask). IEEE Trans. on Knowl. and Data Eng., 1(1), 146– 166. ISSN 1041-4347. doi: 10.1109/69.43410. Available: http://dx.doi.org/ 10.1109/69.43410. Chen, L. (2011). Analyzing and developing role-based access control models. PhD Thesis, Royal Holloway, University of London. Available: http://digirep.rhul. ac.uk/file/817519d1-0731-c09f-1522-e36433db3d2c/1/liangcheng.pdf. Chu, Y.-H., Feigenbaum, J., LaMacchia, B., Resnick, P., and Strauss, M. (1997). Referee: Trust management for web applications. World Wide Web J., 2(3), 127– 139. ISSN 1085-2301. Available: http://dl.acm.org/citation.cfm?id=275079.275092. Conrad, E., Misenar, S., and Feldman, J. (2012). CISSP Study Guide. Syngress. Cover, R. (2007). Extensible Access Control Markup Language (XACML). Available: http://xml.coverpages.org/xacml.html. Damianou, N., Dulay, N., Lupu, E., and Sloman, M. (2001). The ponder policy specification language. In Proceedings of the International Workshop on Policies for Distributed Systems and Networks, POLICY ‘01, London. Springer-Verlag. pp. 18– 38. ISBN 3-540-41610-2. Available: http://dl.acm.org/citation.cfm? id=64 6962.712108. De Coi, J.L. and Olmedilla, D. (2008). A review of trust management, security and privacy policy languages. In SECRYPT 2008, Proceedings of the International Conference on Security and Cryptography, Porto, Portugal, July 26–29, 2008, INSTICC Press, pp. 483–490. DeTreville, J. (2002). Binder, a logic-based security language. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, SP ‘02, Washington, DC. IEEE Computer Society. ISBN 0-7695-1543-6. Available: http://dl.acm.org/citation. cfm?id=829514.830540. Dimmock, N., Belokosztolszki, A., Eyers, D., Bacon, J., and Moody, K. (2004). Using trust and risk in role-based access control policies. In Proceedings of the Ninth ACM Symposium on Access Control Models and Technologies, SACMAT ‘04, New York, NY. pp. 156–162. ISBN 1-58113-872-5. doi: 10.1145/990036.990062. Available: http://doi.acm.org/10.1145/990036.990062. El Houri, M. (2010). A formal model to express dynamic policies access control and trust negotiation a distributed environment. PhD Thesis, Paul Sabatier University.

98

Cybervigilance et confiance numérique

Falcone, R. and Castelfranchi, C. (2001). Social trust: A cognitive approach. In Trust and Deception in Virtual Societies, Castelfranchi, C. and Tan, Y.-H. (eds). Kluwer Academic Publishers, Norwell, MA. pp. 55–90. ISBN 0-7923-6919-X. Available: http://dl.acm.org/citation.cfm?id=379153.379157. Fernandez-Gago, M.C., Roman, R., and Lopez, J. (2007). A survey on the applicability of trust management systems for wireless sensor networks. In Third International Workshop on Security, Privacy and Trust in Pervasive and Ubiquitous Computing (SecPerU 2007). IEEE, July. pp. 25–30. ISBN 0-7695-2863-5. doi: 10.1109/ SECPERU.2007.3. Available: http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm? arnumber=4279766. Ferraiolo, D.F. and Kuhn, D.R. (2009). Role-based access controls. arXiv preprint arXiv:0903.2171, pp. 554–563. Available: http://arxiv.org/abs/0903.2171. Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., and Chandramouli, R. (2001). Proposed NIST standard for role-based access control. ACM Transactions on Information and System Security, 4(3), 224–274. ISSN 10949224. doi: 10.1145/ 501978.501980. Available: http://portal.acm.org/citation.cfm?doid=501978. 501980. Finin, T., Joshi, A., Kagal, L., Niu, J., Sandhu, R., Winsborough, W., and Thuraisingham, B. (2008). Rowlbac: Representing role based access control in owl. In Proceedings of the 13th ACM symposium on Access control models and technologies, SACMAT ‘08, New York, NY. ACM. pp. 73–82. ISBN 978-1-60558129-3. doi: 10.1145/1377836.1377849. Available: http://doi.acm.org/10.1145/ 1377836.1377849. Firdhous, M., Ghazali, O., and Hassan, S. (2012). Trust management in Cloud computing: A critical review. International Journal on Advances in ICT for Emerging Regions (ICTer), 4(2). Galinović, A. (2010). Automated trust negotiation models. In Proceedings of the 33rd International Convention, MIPRO, pp. 1197–1202. Gambetta, D. (2000). Can we trust trust? In Trust: Making and Breaking Cooperative Relations, Chapter 13, Gambetta, D. (ed.). Department of Sociology, University of Oxford. pp. 213–237. Available: http://citeseerx.ist.psu.edu/viewdoc/download? doi=10.1.1.24.5695&rep=rep1&type=pdf. Genovese, V. (2012). Modalities in access control: Logics, proof-theory and applications. PhD Thesis, University of Luxembourg and University of Torino. Gerck, E. (2000). Overview of certification systems: X.509, ca, pgp and skip. Technical Report, Meta-Certificate Group. Available: http://rustie.thebell.net/papers/certover. pdf.

Systèmes de gestion de la confiance

99

Grandison, T.W.A. (2003). Trust management for internet applications. PhD Thesis, Imperial College of Science, Technology and Medicine, University of London. Available: http://www.doc.ic.ac.uk/~mss/Papers/Grandison-phd.pdf. Grandison, T.W.A. and Sloman, M. (2003). Trust management tools for internet applications. In Proceedings of the 1st International Conference on Trust Management, iTrust’03, Berlin, Heidelberg. Springer-Verlag. pp. 91–107. ISBN 3540-40224-1. Available: http://dl.acm.org/citation.cfm?id=1759008.1759015. Gray, E. (2006). A trust-based reputation management system. PhD Thesis, Department of Computer Science, Trinity College Dublin. Available: https://www.tara.tcd.ie/ handle/2262/24260. Habib, S., Ries, S., and Muhlhauser, M. (2011). Towards a trust management system for Cloud computing. In Trust, Security and Privacy in Computing and Communications (TrustCom), 2011 IEEE 10th International Conference, November, pp. 933–939. doi: 10.1109/TrustCom.2011.129. Herzberg, A., Mass, Y., Michaeli, J., Ravid, Y., and Naor, D. (2000). Access control meets public key infrastructure, or: Assigning roles to strangers. In Proceedings of the 2000 IEEE Symposium on Security and Privacy, SP ‘00, Washington, DC. IEEE Computer Society. ISBN 0-7695-0665-8. Available: http://dl.acm.org/citation.cfm? id=882494.884417. Humenn, P. (2003). The formal semantics of XACML. Technical Report, Syracuse University. Available: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10. 1.1.152. 8864&rep=rep1&type=pdf. Huynh, T.D., Jennings, N.R., and Shadbolt, N.R. (2006). An integrated trust and reputation model for open multi-agent systems. Autonomous Agents and MultiAgent Systems, 13(2), 119–154. ISSN 1387-2532. doi: 10.1007/s10458-005-6825-4. Available: http://dx.doi.org/10.1007/s10458-005-6825-4. Jøsang, A. (2007). Trust and reputation systems. In Foundations of Security Analysis and Design IV, Aldini, A. and Gorrieri, R. (eds). Springer-Verlag, Berlin, Heidelberg. pp. 209–245. ISBN 3-540-74809-1, 978-3-540-74809-0. Available: http://dl.acm. org/citation.cfm?id=1793914.1793923. Jøsang, A. and Ismail, R. (2002). The beta reputation system. In Proceedings of the 15th Bled Electronic Commerce Conference, vol. 160, pp. 324–337. doi: 10.1.1.60.5461. Jøsang, A., Ismail, R., and Boyd, C. (2007). A survey of trust and reputation systems for online service provision. Decision Support Systems, 43(2), 618–644. ISSN 01679236. doi: 10.1016/j.dss.2005.05.019. Available: http://linkinghub.elsevier. com/retrieve/pii/S0167923605000849.

100

Cybervigilance et confiance numérique

Kagal, L., Finin, T., and Joshi, A. (2003). A policy based approach to security for the semantic web. In The Semantic Web ISWC 2003, vol. 2870 of Lecture Notes in Computer Science, Fensel, D., Sycara, K., and Mylopoulos, J. (eds). Springer, Berlin, Heidelberg. pp. 402–418. ISBN 978-3-540-20362-9. doi: 10.1007/978-3-540-397182_26. Available: http://dx.doi.org/10.1007/978-3-540-39718-2_26. Kalam, A.A.E. and Deswarte, Y. (2006). Multi-OrBAC: A new access control model for distributed, heterogeneous and collaborative systems. In 8th International Symposium on System and Information Security (SSI’2006), Sao Paulo, Brazil, 8–10 November. Available: http://homepages.laas.fr/deswarte/ Publications/06427.pdf. Kalam, A.A.E., Benferhat, S., Miège, A., Baida, R.E., Cuppens, F., Saurel, C., Balbiani, P., Deswarte, Y., and Trouessin, G. (2003). Organization based access control. In Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY ‘03, Washington, DC. IEEE Computer Society. ISBN 0-7695-1933-4. Available: http://dl.acm.org/citation.cfm?id=826036.826869. Krukow, K., Nielsen, M., and Sassone, V. (2008). Trust models in ubiquitous computing. Philosophical Transactions of the Royal Society, 366(1881), 3781–3793. doi: 10.1098/rsta.2008.0134. Available: http://rsta.royalsocietypublishing.org/ content/366/1881/3781.short. Lamsal, P. (2001). Understanding trust and security. Technical Report, Department of Computer Science, University of Helsinki, Finland. Lee, A.J. (2008). Towards practical and secure decentralize attribute-based authorisation systems. PhD Thesis, University of Illinois. Lee, A.J., Winslett, M., and Perano, K.J. (2009). Trustbuilder2: A reconfigurable framework for trust negotiation. In Trust Management III, vol. 300 of IFIP Advances in Information and Communication Technology, Ferrari, E., Li, N., Bertino, E., and Karabulut, Y. (eds). Springer, Berlin, Heidelberg. pp. 176–195. ISBN 978-3-64202055-1. doi: 10.1007/978-3-642-02056-8_12. Available: http://dx.doi.org/10.1007/ 978-3-642-02056-8_12. Li, N., Mitchell, J.C., and Winsborough, W.H. (2002). Design of a role-based trust management framework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, SP ‘02, Washington, DC. IEEE Computer Society. ISBN 0-7695-15436. Available: http://dl.acm.org/citation.cfm? id=829514.830539. Li, N., Wang, Q., Qardaji, W., Bertino, E., Rao, P., Lobo, J., and Lin, D. (2009). Access control policy combining: Theory meets practice. In Proceedings of the 14th ACM Symposium on Access Control Models and Technologies, SACMAT ‘09, New York, NY. ACM. pp. 135–144. ISBN 978-1-60558-537-6. doi: 10.1145/1542207.1542229. Available: http://doi.acm.org/10.1145/1542207.1542229.

Systèmes de gestion de la confiance

101

Linn, J. (2000). Trust models and management in public-key infrastructures. Technical Report, RSA Laboratories. Available: http://storage.jak-stik.ac.id/ rsasecurity/PKI Paper.pdf. Liu, W.W. (2011). Trust management and accountability for internet security. PhD Thesis, Department of Computer Science, Florida State University. Available: http://etd.lib.fsu.edu/theses/available/etd-07222011-212723/. Luhmann, N. (1990). Familiarity, confidence, trust: Problems and alternatives. In Trust: Making and Breaking Cooperative Relations. Basil Blackwell. pp. 15–35. Marsh, S. (1994). Formalising trust as a computational concept. PhD Thesis, Department of Computing Science and Mathematics, University of Stirling. Available: http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:Formali sing+Trust+as+a+Computational+Concept#0. Mcknight, D.H. and Chervany, N.L. (1996). The Meanings of trust. Technical Report 612, University of Minnesota. Nejdl, W., Olmedilla, D., and Winslett, M. (2004). Peertrust: Automated trust negotiation for peers on the semantic web. In Secure Data Management, vol. 3178 of Lecture Notes in Computer Science, Jonker, W. and Petković, M. (eds). Springer, Berlin, Heidelberg. pp. 118–132. ISBN 978-3-540-22983-4. doi: 10.1007/978-3-54030073-1_9. Available: http://dx.doi.org/10.1007/978-3-540-30073-1_9. Noor, T.H. and Sheng, Q.Z. (2011). Trust as a service: A framework for trust management in Cloud environments. In Proceedings of the 12th International Conference on Web Information System Engineering, WISE’11, Berlin, Heidelberg. Springer-Verlag. pp. 314–321. ISBN 978-3-642-24433-9. Available: http://dl. acm.org/citation.cfm?id=2050963.2050992. Nyanchama, M. and Osborn, S. (1999). The role graph model and conflict of interest. ACM Transactions on Information and System Security, 2(1), 3–33. ISSN 10949224. doi: 10.1145/300830.300832. Available: http://portal.acm.org/citation.cfm?doid= 300830.300832. Parsons, S. and Wooldridge, M. (2002). Game theory and decision theory in multiagent systems. Autonomous Agents and Multi-Agent Systems, 5(3), 243–254. Available: http://link.springer.com/article/10.1023/A%3A1015575522401. Prohic, N. (2005). Public Key Infrastructures – PGP vs. X. 509. In INFOTECH Seminar Advanced Communication Services (ACS). Available: http://www.linecity.de/ INFOTECH_ACS_SS05/acs5_top6_paper.pdf.

102

Cybervigilance et confiance numérique

Renzl, B. (2008). Trust in management and knowledge sharing: The mediating effects of fear and knowledge documentation. Omega, 36(2), 206–220. ISSN 0305-0483. doi: http://dx.doi.org/10.1016/j.omega.2006.06.005. Special Issue on Knowledge Management and Organizational Learning. Ruohomaa, S. and Kutvonen, L. (2005). Trust management survey. In Trust Management, vol. 3477 of Lecture Notes in Computer Science, Herrmann, P., Issarny, V., and Shiu, S. (eds). Springer, Berlin, Heidelberg. pp. 77–92. ISBN 978-3-540-26042-4. doi: 10.1007/11429760_6. Available: http://dx.doi.org/10.1007/ 11429760_6. Ryutov, T., Zhou, L., Neuman, C., Leithead, T., and Seamons, K.E. (2005). Adaptive trust negotiation and access control. In Proceedings of the Tenth ACM Symposium on Access Control Models and Technologies, SACMAT ‘05, New York, NY. ACM. pp. 139–146. ISBN 1-59593-045-0. doi: 10.1145/1063979.1064004. Available: http://doi.acm.org/10.1145/1063979.1064004. Saadi, R., Rahaman, M., Issarny, V., and Toninelli, A. (2011). Composing trust models towards interoperable trust management. Trust Management V, 358, 51–66. Available: http://link.springer.com/chapter/10.1007/978-3-642-22200-9_7. Sabater, J. and Sierra, C. (2001). Regret: Reputation in gregarious societies. In Proceedings of the Fifth International Conference on Autonomous Agents, AGENTS ‘01, New York, NY. ACM. pp. 194–195. ISBN 1-58113-326-X. doi: 10.1145/375735.376110. Available: http://doi.acm.org/10.1145/375735.376110. Samarati, P. and Vimercati, S.D.C.d. (2001). Access control: Policies, models, and mechanisms. In Revised versions of lectures given during the IFIP WG 1.7 International School on Foundations of Security Analysis and Design on Foundations of Security Analysis and Design: Tutorial Lectures, FOSAD ‘00, London. Springer-Verlag. pp. 137–196. ISBN 3-540-42896-8. Available: http://dl.acm.org/citation.cfm?id=646206.683112. Sandhu, R. (1993). Lattice-based access control models. Computer, 26(11), 9–19. ISSN 0018-9162. doi: 10.1109/2.241422. Available: http://dx.doi.org/10.1109/2.241422. Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. (1996). Role-based access control models. Computer, 29(2), 38–47. doi: 10.1109/2.485845. Available: http://iee explore.ieee.org/xpls/abs_all.jsp?arnumber=485845. Sandhu, R., Ferraiolo, D., and Kuhn, R. (2000). The NIST model for role-based access control: Towards a unified standard. In Proceedings of the Fifth ACM Workshop on Role-based Access Control, RBAC ‘00, New York, NY. ACM. pp. 47–63. ISBN 158113-259-X. doi: 10.1145/344287.344301. Available: http://doi.acm.org/10.1145/ 344287.344301.

Systèmes de gestion de la confiance

103

Seamons, K., Winslett, M., Yu, T., Smith, B., Child, E., Jacobson, J., Mills, H., and Yu, L. (2002). Requirements for policy languages for trust negotiation. In Proceedings of the 3rd International Workshop on Policies for Distributed Systems and Networks (POLICY’02), POLICY ‘02, Washington, DC. IEEE Computer Society. ISBN 0-7695-1611-4. Available: http://dl.acm.org/citation.cfm?id=863632.883487. Sloman, M. (1994). Policy driven management for distributed systems. Journal of Network and System Management, 2(4). Squicciarini, A., Bertino, E., Ferrari, E., Paci, F., and Thuraisingham, B. (2007). Pptrustx: A system for privacy preserving trust negotiations. ACM Trans. Inf. Syst. Secur., 10(3). ISSN 1094-9224. doi: 10.1145/1266977.1266981. Available: http://doi.acm.org/10.1145/1266977.1266981. Uszok, A., Bradshaw, J., Jeffers, R., Suri, N., Hayes, P., Breedy, M., Bunch, L., Johnson, M., Kulkarni, S., and Lott, J. (2003). Kaos policy and domain services: Toward a description-logic approach to policy representation, deconfliction, and enforcement. In Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks, POLICY ‘03, Washington, DC. IEEE Computer Society. ISBN 0-7695-1933-4. Available: http://dl.acm.org/citation.cfm?id=826036.826850. Uszok, A., Bradshaw, J.M., Johnson, M., Jeffers, R., Tate, A., Dalton, J., and Aitken, S. (2004). Kaos policy management for semantic web services. IEEE Intel Ligent Systems, 19(4), 32–41. ISSN 1541-1672. doi: 10.1109/MIS.2004.31. Available: http://dx.doi.org/10.1109/MIS.2004.31. Wang, Y. and Varadharajan, V. (2007). Role-based recommendation and trust evaluation. In The 9th IEEE International Conference on E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-commerce and E-services (CEC-EEE 2007). IEEE, July. pp. 278–288. ISBN 0-7695-2913-5. doi: 10.1109/CEC-EEE.2007.83. Available: http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=4285225. Wikipedia (2013). Trust management (information system). Available: http://en. wikipedia.org/wiki/Trust_management. Winsborough, W.H. and Li, N. (2006). Safety in automated trust negotiation. ACM Trans. Inf. Syst. Secur., 9(3), 352–390. ISSN 1094-9224. doi: 10.1145/ 1178618.1178623. Available: http://doi.acm.org/10.1145/1178618.1178623. Xie, F., Chen, Z., Xu, H., Feng, X., and Hou, Q. (2013). Tst: Threshold based similarity transitivity method in collaborative filtering with Cloud computing. Tsinghua Science and Technology, 18(3), 318–327. doi: 10.1109/TST.2013.6522590.

104

Cybervigilance et confiance numérique

Yagüe, M. (2006). Survey on xml-based policy languages for open environments. Journal of Information Assurance and Security, 1, 11–20. Available: http://www.softcomputing.net/jias/a2.pdf. Yaich, R., Boissier, O., Picard, G., and Jaillon, P. (2013). Adaptiveness and social compliance in trust management within virtual communities. Web Intelligence and Agent Systems, 11(4), 315–338. Yao, W. (2004). Trust management for widely distributed systems. Technical Report UCAM-CL-TR-608, University of Cambridge Computer Laboratory. Yu, T. (2003). Automated trust establishment in open systems. PhD Thesis, University of Illinois at Urbana-Champaign, Champaign, IL. AAI3102006. Yu, T., Ma, X., and Winslett, M. (2000). Prunes: An efficient and complete strategy for automated trust negotiation over the internet. In Proceedings of the 7th ACM Conference on Computer and Communications Security, CCS ‘00, New York, NY. ACM. pp. 210–219. ISBN 1-58113-203-4. doi: 10.1145/352600.352633. Available: http://doi.acm.org/10.1145/352600.352633. Yu, T., Winslett, M., and Seamons, K.E. (2003). Supporting structured credentials and sensitive policies through interoperable strategies for automated trust negotiation. ACM Transactions on Information and System Security, 6(1), 1–42. ISSN 10949224. doi: 10.1145/605434.605435. Available: http://portal.acm.org/citation.cfm? doid=60 5434.605435. Yuan, E. and Tong, J. (2005). Attributed based access control (ABAC) for Web services. In IEEE International Conference on Web Services (ICWS’05). IEEE. ISBN 0-76952409-5. doi: 10.1109/ICWS.2005.25.

Chapitre 3

Risques d’attaques réseaux

3.1. Introduction La sécurisation des systèmes d’information (SI) d’entreprise est une tâche vitale, complexe et difficile à entreprendre. Certaines menaces sur le SI, si elles se concrétisent, peuvent être fatidiques pour l’entreprise. Ces menaces visent à altérer l’un des principaux attributs de sécurité : l’intégrité, l’authenticité, la disponibilité et la confidentialité. D’une façon plus simple, elles peuvent porter atteinte à la disponibilité des systèmes et des données, détruire, corrompre ou falsifier les données, voler ou espionner les données confidentielles, essayer d’utiliser illicitement le système ou le réseau, user le système compromis pour attaquer d’autres cibles. Les menaces peuvent produire des impacts qui engendrent différents coûts à l’entreprise : humains, technique et financiers. Comme exemple d’impacts, on peut citer : perte de confidentialité de données sensibles, indisponibilité des infrastructures et des données, dommages pour le patrimoine intellectuel, perte de notoriété, etc. Les risques de telles menaces peuvent se réaliser si les SI et les réseaux qui les supportent présentent des vulnérabilités. Généralement, le risque peut être décrit par une fonction à deux paramètres : probabilité d’occurrence et impact de la menace. Comme fonction largement utilisée, on peut citer la fonction produit de l’impact et de la probabilité d’occurrence : Risque = Impact × Probabilité d’occurrence La sécurité des SI d’entreprise est de plus en plus abordée à l’aide d’approches basées sur l’analyse des risques. Ces approches peuvent réduire considérablement l’impact des menaces dues aux vulnérabilités des SI. La sécurité des SI et l’analyse de

Chapitre rédigé par Kamel KAROUI.

106

Cybervigilance et confiance numérique

risque ont fait l’objet de plusieurs normes dont voici une récapitulation (Bloch et al. 2007) : – ISO 27001 : système de management de la sécurité des systèmes d’information SMSI ; – ISO 27000 : vocabulaire de la sécurité des systèmes d’information SSI ; – ISO 27002 (ex-17799) : mesures de sécurité ; – ISO 27003 : implémentation du SMSI ; – ISO 27004 : indicateurs de suivi du SMSI ; – ISO 27005 : évaluation et traitement du risque ; – ISO 27006 : certification du SMSI ; – ISO 27007 : audit du SMSI. De rares méthodes d’appréciation de risque de SI prennent en considération la sécurité des réseaux, leurs architectures et leurs différents composants. Parmi ces méthodes, on peut citer (Pons 2014) : les graphes d’attaque, la méthode CHASSIS, la méthode BDMP, etc. Ces méthodes, bien qu’elles puissent être très utiles comme indicateurs de risque, sont plus ou moins simples et ne peuvent pas être considérées comme des méthodes complètes d’analyse de risque. L’objectif de ce chapitre est donc de faire une synthèse de la sécurité des SI du point de vue risque en intégrant la dimension réseau et ses différentes menaces, c’està-dire proposer une méthode complète d’analyse de risque des SI déployés sur les réseaux. Cette méthode est applicable et elle est inspirée des normes de gestion de risque existantes. Après l’introduction, la deuxième section permet au lecteur de se familiariser avec les définitions et la terminologie du risque. Elle abordera aussi les principales méthodologies existantes telles que EBIOS, Méhari ou encore Octave. Cette section se termine par une comparaison de ces méthodes. Dans la troisième section, nous étudions l’analyse du risque dans le contexte des réseaux informatiques. Dans cette section, nous essayerons de proposer une méthodologie détaillée et pratique pour illustrer les différentes phases proposées par la norme ISO 27005 (Bahtit et Regragui 2012). Nous appliquerons notre méthodologie sur le cas de l’architecture réseau d’une entreprise e-commerce. Enfin, nous terminerons par une brève conclusion où nous récapitulerons les normes, méthodologies et processus présentés au cours de ce chapitre.

Risques d’attaques réseaux

107

3.2. Théorie du risque Dans cette section, nous définirons les principaux termes associés à l’analyse de risque (SGDN 2017). Par la suite, nous présenterons les principales méthodologies de l’analyse de risque. 3.2.1. Définition des termes du risque Dans ce qui suit, nous définirons les termes fréquemment utilisés dans la gestion de risque. La figure 3.1 montre la relation existante entre les différents termes utilisés dans la gestion de risque.

Figure 3.1. Terminologie du risque

– Actifs : ressource matérielle, logicielle ou tout simplement information qui peut avoir une importance particulière dans un système d’information. – Importance des actifs : chaque actif a une certaine valeur matérielle et/ou morale et/ou sentimentale, etc. Cette valeur est associée aux actifs et est appelée importance de la ressource ou de l’actif. Certains actifs sont vitaux tandis que d’autres sont optionnels pour le bon fonctionnement du système d’information d’une entreprise. L’importance est prédéfinie par les responsables des systèmes d’information. – Responsables des SI : par responsables, on désigne tous les acteurs des SI d’une entreprise pouvant, d’une part, évaluer l’importance des actifs et, d’autre part, prendre des décisions concernant la sécurisation du SI et de ses actifs les plus importants contre les éventuelles menaces.

108

Cybervigilance et confiance numérique

– Menaces : les menaces représentent la possibilité de voir une source ou un agent de menaces porter une atteinte physique, logique ou morale aux ressources d’un SI. Une menace réellement mise en œuvre est appelée attaque. Une attaque réussie est appelée intrusion. Les menaces peuvent être classées de différentes manières : accidentelles/délibérées, passives/actives, etc. – Sources de menaces ou agent de menaces ou facteur de risques : toutes entités pouvant constituer une menace contre les actifs du SI. Les sources peuvent être classées de différentes manières : internes/externes, malveillantes/non malveillantes, automatiques/manuelles, etc. La source peut aussi être qualifiée de délibérée, si elle est provoquée délibérément par un attaquant, ou non délibérée si elle apparaît spontanément à la suite de l’utilisation normale du SI (par exemple, une défaillance du logiciel). – Vulnérabilités : faiblesse ou faille dans les procédures de sécurité, les contrôles administratifs ou les contrôles internes d’un système, qui pourrait être exploitée par une source de menaces pour corrompre le SI, c’est-à-dire porter atteinte à la confidentialité, à l’intégrité et à la disponibilité du SI. – Impact : estimation de l’ensemble des conséquences matérielles, logiques ou morales que le système d’information peut subir à la suite de la concrétisation d’une menace (avènement d’une attaque réussie). – Contre-mesures : ensemble de mesures de sécurité adoptées par l’entreprise pour empêcher une menace de se concrétiser. – Politique de sécurité : dispositif global dont la mise en œuvre assure que le SI est sécurisé contre les menaces et l’utilisation malveillante des actifs de l’entreprise. – Risque : possibilité qu’une menace particulière exploite les vulnérabilités d’un ou de plusieurs actifs pour porter préjudice au SI d’une entreprise. Le risque peut donc être considéré comme une fonction multi-variables qui dépend de la probabilité d’occurrence (ou vraisemblance), de l’impact et des contre-mesures adoptées par une entreprise pour faire face à une menace donnée. Cette fonction est donc proportionnelle à la probabilité d’occurrence et l’impact d’une menace, c’est-à-dire que plus la probabilité d’occurrence et l’impact augmentent, plus cette fonction augmente. En revanche, elle est inversement proportionnelle aux contre-mesures, c’est-à-dire que plus les contre-mesures sont efficaces, plus cette fonction diminue. – Vraisemblance ou probabilité d’occurrence d’une menace : estimation de la possibilité ou de la probabilité qu’une menace soit exploitée concrètement pour devenir une attaque contre le SI d’une entreprise. – Gestion de risques : appelée aussi analyse de risques. La gestion des risques est définie par l’ISO (Bahtit et Regragui 2012) comme l’ensemble des activités

Risques d’attaques réseaux

109

coordonnées visant à diriger et piloter un organisme vis-à-vis du risque. On dégage généralement trois finalités de la gestion des risques : - améliorer la sécurisation d’un SI ; - justifier le budget alloué à la sécurisation d’un SI ; - prouver la crédibilité d’un SI. 3.2.2. Présentation des principales méthodes du risque La gestion du risque est principalement décrite dans la norme ISO 27005 (Bahtit et Regragui 2012) qui étaye les concepts généraux spécifiés dans la norme ISO 27001(Brenner 2007). Une norme est un document de référence établi pour décrire formellement une problématique industrielle ou économique. La norme ISO 27005 énonce toutes les étapes du processus de gestion de risque utilisées dans le cadre de la sécurisation des systèmes d’information. Elle explique comment conduire, apprécier, traiter les risques encourus par les SI. Elle donne aussi les consignes génériques pour remédier aux risques de sécurité de l’information. Cette norme distingue notamment les notions d’appréciation, d’analyse, d’identification, d’estimation et d’évaluation du risque. L’ISO 27005 peut être utilisée comme guide par le responsable de la sécurité des SI. Elle décrit le processus de gestion du risque depuis l’établissement du contexte à la surveillance des risques, en passant par l’appréciation et le traitement des risques. D’après cette norme, le processus de gestion du risque en sécurité de l’information se compose des phases suivantes : – établissement du contexte : permet de définir les critères d’évaluation, d’impact et du niveau d’acceptation du risque des SI (phase 1) ; – appréciation des risques : permet d’analyser et d’évaluer les risques d’un SI afin de les ordonnancer par rapport aux critères d’évaluation fixés à la phase 1 (phase 2) ; – traitement du risque : processus de mise en œuvre des mesures de sécurité à entreprendre face aux risques de sécurité des SI. Cette phase tient compte des priorités et de l’ordonnancement de risque adoptés à la phase 2 (phase 3) ; – acceptation des risques : approbation par les responsables ou par une autorité d’homologation désignée des choix effectués lors du traitement du risque (phase 4) ; – communication du risque : processus régulier qui permet de partager avec les acteurs concernés l’information sur les risques définie dans les phases précédentes (phase 5) ; – surveillance des risques : cette phase permet de contrôler et d’assurer l’adaptation et la pertinence des mesures de sécurité adoptées face aux risques. Elle tient compte des objectifs de sécurité fixés par l’entreprise (phase 6).

110

Cybervigilance et confiance numérique

Les principales phases de la norme 27005 ne se basent pas sur des méthodes particulières ou sur un processus détaillé qui montre comment appliquer ces phases. En revanche, une méthode est un ensemble d’activités ordonnées permettant d’atteindre efficacement un résultat précis et souhaité sans nécessairement se baser sur un document de référence consensuel comme une norme. Normes et méthodes sont donc complémentaires et il est préférable de les associer de façon que la méthode soit utilisée pour mettre en œuvre la norme. Ainsi, pour mettre en œuvre efficacement la norme ISO 27005, il faut s’appuyer sur une méthode de gestion des risques telles que Méhari, Octave, EBIOS… C’est aux entreprises de choisir d’adopter la norme 27005 plutôt qu’une autre. Dans les sections suivantes, nous présenterons quelques méthodes de gestion ou d’analyse de risque. 3.2.2.1. EBIOS Expression des besoins et identification des objectifs de sécurité ou EBIOS (Défense nationale 2010) est une méthode d’analyse de risques. Elle a été créée en 1995 par la DCSSI (Direction centrale de la sécurité des systèmes d’information) du ministère de la Défense de France (Vasquez et al. 2012). EBIOS a été mise à jour en 2010 par l’Agence nationale de la sécurité des systèmes d’information (Vasquez et al. 2012) et le Club EBIOS. Cette mise à jour permet de prendre en considération les retours d’expérience et les évolutions des normes. EBIOS peut servir à l’organisation de deux manières complémentaires : l’identification des risques d’un SI et la proposition d’une politique de sécurité adaptée aux besoins. La méthode EBIOS est constituée des cinq étapes suivantes (figure 3.2) : – étude du contexte : permet d’identifier le système d’information cible de l’étude. Elle permet de délimiter les limites de l’étude de risque : présentation de l’entreprise, architecture du système d’information, contraintes techniques et réglementaires, enjeux commerciaux. Elle étudie aussi des détails concernant les équipements, les logiciels et l’organisation humaine de l’entreprise (étape 1) ; – expression des besoins : au cours de cette étape, les utilisateurs du SI (identifiés à l’étape 1) expriment leurs besoins de sécurité en fonction des impacts qu’ils jugent inacceptables (étape 2) ; – étude des menaces : comme son nom l’indique, cette étape permet d’identifier les menaces du SI en fonction de son architecture technique. Cette étape nécessite l’intervention de spécialistes pour dresser la liste des vulnérabilités du SI et des menaces qu’ils peuvent engendrer en fonction du matériel utilisé, de l’architecture du réseau et des logiciels employés. Le recensement des vulnérabilités doit être aussi exhaustif que possible. Il doit être indépendant de l’origine (humaine, matérielle, environnementale, etc.), de la cause (intentionnelle, accidentelle, etc.) des vulnérabilités ;

Risques d’attaques réseaux

111

– identification des objectifs de sécurité : cette étape permet de confronter les besoins de sécurité recensés à l’étape d’expression des besoins aux vulnérabilités et menaces identifiées à l’étape d’étude des menaces. Le résultat d’une telle confrontation produit une liste des risques du SI contre lesquels on doit se protéger et qui sera utilisée pour rédiger un cahier des charges de sécurité. Le cahier des charges exprimera les choix qui doivent être adoptés pour contrecarrer les menaces en fonction des exigences de sécurité ; – détermination des exigences de sécurité : cette dernière étape permet de définir la stratégie de gestion du risque que l’entreprise adoptera. Elle fixera dans un plan de risque la stratégie à adopter pour chaque risque (accepter, réduire ou refuser). En effet, une entreprise ne dispose généralement pas d’assez de ressources pour faire face à tous les types de risque recensés. Pour cela, elle classe par priorité les risques recensés dans l’étape précédente. Pour des raisons économiques et stratégiques, certains risques doivent être ignorés car, d’une part, le coût de la protection est exorbitant et, d’autre part, la probabilité d’apparition et les impacts sont finalement considérés comme non significatifs. Étude du contexte

Expression des besoins de sécurité

Étude des menaces

Identification des objectifs de sécurité

Détermination des exigences de sécurité

Figure 3.2. Démarche EBIOS globale (source : (Culioli et al. 2009))

On peut donc dire qu’EBIOS permet de construire une politique de sécurité en fonction d’une analyse de risques qui repose sur le contexte de l’entreprise et des vulnérabilités liées à son SI. De plus, pour faciliter son application, la méthode EBIOS propose l’utilisation d’un logiciel libre qui permet l’application de la méthodologie explicitée ci-avant. Le logiciel permet d’automatiser la création des documents de synthèse. Parallèlement, le logiciel se connecte à une base de connaissances pour profiter de la description prédéfinie d’un ensemble de vulnérabilités spécifiques, de contraintes de sécurité, de méthodes d’attaques. Cette base de connaissances peut être facilement enrichie (retours d’expérience) via le logiciel.

112

Cybervigilance et confiance numérique

3.2.2.2. Méhari Méthode harmonisée d’analyse de risques ou Méhari (Syalim et al. 2009) est une méthode de gestion de risques utilisée par de nombreuses entreprises publiques et privées. Elle répond pleinement aux lignes directrices de la norme ISO 31000 (Purdy 2010). Méhari apporte une démarche centrée sur les besoins de continuité d’activité de l’entreprise et utilise un guide méthodologique pour fournir des livrables types. L’approche utilisée par cette méthode se base sur celle de deux autres méthodes qui ne sont plus utilisées, Melisa et Marion (Eloff et al. 1993). Méhari est maintenue par le CLUSIF (Club de la sécurité des systèmes d’information français) via son groupe de travail dédié à la maintenance de cette méthode. Indépendamment de la démarche de sécurité choisie par une entreprise, l’application de la méthode Méhari passe par les activités génériques suivantes (figure 3.3) : – analyse des enjeux de la sécurité : cette activité consiste à rassembler, pour chaque ressource importante du SI (matériels, logiciels, informations), les types de dysfonctionnements ou vulnérabilités redoutés. Ensuite, les effets ou impacts de ces vulnérabilités sur la ressource sont classés par rapport : - aux trois attributs de base de la sécurité que sont la confidentialité, l’intégrité et la disponibilité ; - à la cause qui peut être accidentelle, malveillante, ou due à une vulnérabilité du SI ; - aux conséquences ou aux impacts de ces dysfonctionnements qui peuvent être financières, techniques ou autres sur l’entreprise ; – audit des services de sécurité : vérification et contrôle du bon fonctionnement et de l’efficacité des services de sécurité du SI pour éventuellement déduire les vulnérabilités non énoncées dans l’activité précédente ; – détection des situations de risques : pour chaque menace de sécurité, cette activité consiste à prendre en considération les probabilités d’occurrence et les impacts potentiels, ainsi que les services de sécurité pour contrecarrer cette menace, pour déduire la gravité du risque associé. Dans Méhari, l’application des activités précédentes a pour objectifs de produire les trois livrables appelés aussi les plans suivants (figure 3.3) : – PSS ou plan stratégique de sécurité : c’est dans ce livrable qu’on fixe les objectifs de sécurité ainsi que les méthodes et métriques permettant d’évaluer le degré d’accomplissement de ces objectifs. Ainsi, c’est dans ce plan qu’on évalue les risques auxquels l’entreprise fait face et la politique de sécurité que celle-ci devra adopter pour la sécurisation de son SI ;

Risques d’attaques réseaux

113

– POS ou plans opérationnels de sécurité : un plan est défini pour chaque ressource importante du SI liée à un risque de sécurité donné. Il a pour objectif d’évaluer les mesures de sécurité existantes ou qui doivent être mises en place pour contrecarrer une menace. Pour définir ces mesures, on élabore des scénarios permettant de mettre en œuvre ces menaces et on analyse la réaction des services du SI. Les scénarios seront liés à des vulnérabilités si la réaction des services de sécurité est inadéquate ou insuffisante pour contrecarrer ces situations. Ces plans permettent donc de cerner les vulnérabilités du SI. Cela permet à l’entreprise d’auditer ses capacités de sécurité, d’évaluer correctement les risques et d’identifier les besoins en matière de sécurité ; – POE ou plan opérationnel d’entreprise : ce plan peut être assimilé à un tableau de bord. Il permet de contrôler et d’assurer le suivi de la sécurité globale du SI de l’entreprise. Ceci se fait en se basant sur les indicateurs des risques identifiés et en contrôlant les pires scénarios de menaces dangereuses (probabilité, impact) dont il faut se protéger. En définitive, Méhari se base sur un ensemble d’activités et d’audits du SI qui permettent l’élaboration d’une politique de sécurité. Cette politique est destinée à contrecarrer les menaces, pallier les vulnérabilités extraites dans les plans opérationnels de sécurité et assurer un niveau acceptable de sécurité qui doit correspondre à celui présenté dans le plan stratégique de sécurité (figure 3.3). Pour atteindre ces objectifs, la méthodologie Méhari se base sur des guides, des bases de connaissances et des processus d’évaluation quantitative : – des guides : - guide de classification des ressources sensibles ; - guide d’audit des services de sécurité ; - guide d’analyse de risque ; - guide d’élaboration des objectifs de sécurité ; – des bases de connaissances : - base des services de sécurité ; - base d’audit des services de sécurité ; - base de scénarios de risque ; - base d’analyse des scénarios de risque en fonction des services de sécurité effectifs ; - base d’analyse des scénarios de risque par évaluation directe des facteurs de risque ; – des processus d’évaluation quantitative :

114

Cybervigilance et confiance numérique

- évaluation de la qualité des services de sécurité ; - évaluation des facteurs de risque ; - évaluation de la potentialité et de l’impact d’un scénario de risque ; - évaluation du degré de gravité d’un risque.

Analyse des enjeux – Classification Audit des services de sécurité

Détection des risques critiques Analyse des situations de risque

Plans d’action basés sur l’audit des vulnérabilités

Plans d’action basés sur l’analyse des risques

Gestion des risques des projets

Plans d’action basés sur l’analyse des enjeux

Figure 3.3. Schéma général de la méthode Méhari (source : (Ghazouani et al. 2014))

3.2.2.3. Octave Operationally Critical Threat, Asset, and Vulnerability Evaluation ou Octave (Alberts et Dorofee 2002) est une méthode qui a été proposée initialement pour les grandes entreprises. Elle a été développée en 1999 par le Software Engineering Institute (SEI) de la Carnegie Mellon University à travers son programme CERT. Actuellement, Octave dispose de trois versions : Octave (plus de 300 employés), Octave-S (moins de 100 employés) et Octave-Allegro (version allégée d’Octave) (Caralli et al. 2007). OctaveAllegro a pour objectif de permettre à une petite structure de réaliser l’analyse des risques de son SI en se basant sur une équipe pluridisciplinaire comprenant des membres de tous les services de l’entreprise. L’application d’Octave permet aux membres responsables d’améliorer leur connaissance de l’entreprise et de partager les connaissances sur les bonnes pratiques de sécurité. Octave décrit en détail les étapes et fournit des outils pratiques d’analyse de risques tels que les feuilles de calcul des risques et les questionnaires. L’efficacité de la méthode Octave lui a permis d’être assez répandue en Amérique du Nord. Octave a pour objectifs la sécurisation des ressources et la gestion du

Risques d’attaques réseaux

115

personnel de l’entreprise du point de vue technique et organisationnel. La méthode Octave est constituée principalement des trois phases ou vues suivantes précédées par une étape de préparation (figure 3.4) : – vue organisationnelle : étude des besoins de sécurité des ressources de l’entreprise. Cette phase vise à recenser les actifs et les menaces de sécurité qui mettent en péril le bon fonctionnement de chaque entité de l’entreprise. Elle associe aux ressources et menaces, les vulnérabilités de l’entreprise étoffées par des scénarios de risques menaçant ces ressources. Ceci mène à déduire les besoins de sécurité relatifs à chaque ressource par rapport aux objectifs de sécurité imposés par la direction et les mesures actuelles adoptées par l’entreprise ; – vue technique : étude des vulnérabilités et identification des constituants techniques correspondant à chaque ressource (identifiés dans la vue organisationnelle). C’est dans cette phase que les ressources prioritaires sont identifiées et auditées pour déterminer leurs vulnérabilités ; – développement de la stratégie et du plan de sécurité appelé aussi stratégie de sécurité : évaluation des risques identifiés dans les vues précédentes et proposition des contre-mesures qui permettent de les atténuer. C’est dans cette phase qu’on élabore et planifie un plan de réduction de risques.

Figure 3.4. Phases de la méthode Octave (source : (Bou Nassar 2012))

3.2.3. Comparatif des principales méthodes Chacune des méthodes d’analyse de risque présente des spécificités et des différences (ANSI 2014). Ces méthodes partagent aussi les points communs suivants :

116

Cybervigilance et confiance numérique

– une démarche méthodologique : ces méthodes se basent sur des processus constitués de phases et d’activités ordonnées. Ces phases ont pour objectifs d’identifier les risques et les ressources importantes de l’entreprise et de décider des contre-mesures appropriées ; – des documents de référence : ces méthodes aident les différents intervenants de l’analyse de risques en leur proposant un document de référence qui liste et classifie les ressources de l’entreprise. À chaque ressource, on associe les menaces et les vulnérabilités qui lui sont propres. Ces méthodes d’analyse de risques présentent également des différences qui peuvent mener au choix de l’une ou de l’autre. Ces différences peuvent être classées selon les critères suivants (ANSI 2014) : – la langue : la langue et le vocabulaire utilisé par une méthode d’analyse de risques sont très importants pour bien comprendre et mieux utiliser une méthode ; – les outils et la base de connaissances : chaque méthode d’analyse de risques possède des outils et une base de connaissances qui permettent de faciliter l’utilisation de la méthode ; – la documentation : la complexité d’une méthode d’analyse de risques peut être atténuée par la qualité de la documentation accompagnant la méthode ; – la pérennité : cet attribut rassemble les critères de permanence, de stabilité et de continuité de la méthode d’analyse de risques. Ces critères sont importants pour le choix d’une méthode plutôt qu’une autre. C’est l’assurance que l’éditeur met à jour et améliore sa méthode régulièrement ; – la compatibilité : la méthode d’analyse de risques doit être cohérente et sans contradictions avec des normes internationales ; – le retour d’expérience : l’expérience acquise à la suite de l’utilisation d’une méthode devrait être utilisée pour l’enrichir. Cela peut être un avantage et peut pousser à choisir une méthode plutôt qu’une autre ; – la complexité de mise en œuvre : la facilité d’utilisation d’une méthode est un critère qui peut faire sa force. Ce critère dépend non seulement de la méthodologie adoptée par la méthode, mais aussi d’autres attributs tels que la langue, les outils, la documentation, le retour d’expérience, etc. Ci-après, nous présentons un tableau comparatif des méthodes présentées auparavant (ANSI 2014). Ce tableau se base sur les critères cités précédemment. Nous pouvons remarquer, par exemple, que seuls EBIOS et Méhari sont compatibles à la norme ISO 27005.

Documentation

Outils

Fonctionnalités Complexité de mise en œuvre

La mise en œuvre de cette méthode est facilitée par la − Analyse des risques mise à disposition des EBIOS − Maturité SSI : la DCSSI met utilisateurs de bases de connaissances riches et qu’on à disposition un document Riche, disponible en Langue : peut enrichir, d’un logiciel décrivant une approche téléchargement gratuit Logiciel EBIOS 2010, français libre et gratuit permettant de méthodologique pour sur : http://www.ssi. disponible en téléchargement Pays : France simplifier l’application et déterminer le niveau adéquat gratuit sur : https://adull Conformité : gouv.fr/fr/guide s-etd’automatiser la création des de maturité de la sécurité des bonnespratiques/outils act.net/projects/ebios2010/ ISO 31000, documents de synthèse. Par systèmes d’information -methodologiques/ 27001, ailleurs, un club d’utilisateurs (http://www.ssi.gouv.fr/IMG/ 27005 pdf/maturitessi- methode-2007- EBIOS a été créé en 2003 et constitue une communauté 11-02.pdf) d’experts permettant le partage des expériences − Analyse des risques Un premier niveau d’outils La mise en œuvre de Méhari ne Méhari est directement inclus dans la − Tableau de bord peut être conduite qu’en base de connaissances de la Langue : − Indicateurs Maturité SSI : la conjonction avec un logiciel ou méthode, en utilisant les français, méthode donne des indications des feuilles de calculs dédiées. Riche, disponible en formules Excel et Le démarrage de l’analyse anglais, de maturité de la capacité de OpenOffice. Un manuel de nécessite une adaptation un peu l’organisation à gérer la allemand, etc. téléchargement gratuit sur : https://clusif.fr/medias/ référence, qui est gratuit, compliquée de « la base de sécurité de l’information sous Pays : France mehari/ explique son utilisation. Il est connaissances ». Par ailleurs, toutes ses formes. Elle permet Conformité : possible d’adapter la base de de mesurer le niveau de une version « Méhari-Pro », qui ISO 27001, données de connaissances vise principalement les petites maturité de la sécurité des 27002, aux domaines spécifiques de systèmes d’information à ou moyennes organisations, 27005 l’activité, au niveau de privées ou publiques, est travers plusieurs indicateurs

Critères Méthodes

Risques d’attaques réseaux 117

Langue : anglais Pays : ÉtatsUnis Conformité : ISO 31010

Octave

Critères Méthodes maturité, à la portée et à la taille de l’entreprise. Par ailleurs, plusieurs efforts indépendants sont fournis pour développer des outils supplémentaires comme RISICARE, développé par BUCSA et qui est le plus conforme et complet

Outils Complexité de mise en œuvre disponible sur : http://www.clusif. asso.fr/fr/production/mehari/ presentation.asp

Les méthodes Octave sont conçues pour être utilisées par de petites équipes, interdisciplinaires, du personnel de l’organisation, le recours à des experts externes pour des activités spécifiques est parfois nécessaire

Fonctionnalités (par exemple : l’efficacité, la résilience, les aspects de continuité)

− Analyse des risques − Tableau de bord − Indicateurs Maturité SSI : la méthode donne des indications de maturité de la capacité de l’organisation à gérer la sécurité de l’information sous toutes ses formes. Elle permet de mesurer le niveau de maturité de la sécurité des systèmes d’information à travers plusieurs indicateurs (par exemple : l’efficacité, la résilience, les aspects de continuité)

Tableau 3.1. Tableau comparatif des méthodes d’analyse de risque (source : (ANSI 2014))

Catalogue de pratiques de sécurité et d’autres documents sont disponibles en Logiciel payant téléchargement gratuit sur http://www.cert.org/ resilience/productsservices/octave/index.cfm

Documentation

118 Cybervigilance et confiance numérique

Risques d’attaques réseaux

119

3.3. Analyse du risque des systèmes d’information (SI) dans le contexte des réseaux informatiques Les systèmes d’informations se basent généralement sur des architectures distribuées permettant l’exploitation en réseau du SI des différents utilisateurs de l’entreprise : clients, utilisateurs internes, fournisseurs, décideurs, partenaires et/ou agents d’administration. Le travail en réseau et les échanges entre les différents intervenants peuvent engendrer de nouvelles vulnérabilités du système d’information de l’entreprise. La sécurité des réseaux est donc une composante primordiale de la sécurité des systèmes d’information. Dans cette section, nous allons adopter l’approche de gestion des risques proposée par l’ISO 27005 et l’appliquer aux systèmes d’informations (SI) déployés sur des réseaux informatiques. Nous rappelons que cette norme est une approche générique qui ne donne aucune méthodologie spécifique de gestion des risques liés à la sécurité des SI et des réseaux. Nous rappelons également que l’ISO 27005 propose une approche générique de gestion de risques basée sur six phases (section 3.2.2) : établissement du contexte, appréciation des risques, traitement du risque, acceptation des risques, communication du risque, surveillance des risques. Dans les sections suivantes, nous détaillerons les différentes étapes de notre méthodologie (Karoui 2016) de l’analyse de risque des SI déployés dans les réseaux informatiques. Nous adopterons la démarche en six étapes de la norme 27005. Nous expliciterons chacune de ces étapes et nous l’appliquerons sur le cas d’une entreprise d’e-commerce qui peut faire face à une attaque DDoS sur son réseau informatique et particulièrement sur son serveur web. Le choix de cet exemple sert à démontrer l’utilité du processus de gestion de risque de SI dans un contexte réseau. 3.3.1. Établissement du contexte Un SI déployé dans un réseau est associé à plusieurs ressources matérielles et logicielles importantes qu’il faut protéger contre d’éventuelles cyberattaques. La protection de ces ressources peut être entamée par une analyse des risques auxquels ces ressources sont exposées. Dans la plupart des travaux sur le risque (OWASP 2018a ; WEF 2012 ; ENISA 2013), le risque se base sur deux paramètres principaux : l’impact et la probabilité d’occurrence des menaces ou des attaques. Dans cette section, nous présenterons les ressources à protéger, les paramètres du risque et la classification qu’on adoptera dans l’analyse de risque. 3.3.1.1. Ressources à protéger Un SI déployé dans un réseau est constitué d’une multitude de ressources et de composants ayant chacun une importance particulière dans l’entreprise. La complexité

120

Cybervigilance et confiance numérique

et le nombre de ces composants rendent utopique la protection complète du SI. Pour cela, on agira par priorité pour pouvoir protéger les ressources les plus importantes. On commencera par recenser et classer les ressources et les composants par rapport à leur importance pour l’entreprise. Par la suite, pour chacune de ces ressources, on essayera de recenser les menaces auxquelles elle peut faire face. 3.3.1.1.1. Recensement des ressources Le système d’information est un ensemble organisé de ressources qui permet de collecter, stocker, traiter et distribuer de l’information. Les composants les plus importants d’un SI sont les applications, les serveurs et les bases de données. Pour sécuriser ces composants, il ne suffit pas de les protéger directement, il faut aussi protéger les technologies sous-jacentes qui les supportent et qui supportent les échanges nécessaires au fonctionnement normal du SI. La figure 3.5 résume ceci pour des applications web. 3.3.1.1.2. Menaces contre les ressources Pour chaque ressource importante de l’entreprise, on essaye de recenser les menaces qui peuvent altérer son fonctionnement. Si on prend, par exemple, le cas d’une entreprise e-commerce, le site web est d’une importance capitale pour l’entreprise. En effet, l’aspect financier de l’entreprise dépend en grande partie des ventes et des opérations financières effectuées à travers le site web. D’après la figure 3.5, les attaques sont de différents types. Dans ce qui suit, nous présenterons les menaces en les divisant en trois catégories : applicatives, réseaux et hôtes. Nous donnerons, pour chacune de ces trois catégories, quelques exemples de menaces pouvant affecter le bon fonctionnement du site web de vente online d’une entreprise e-commerce : – menaces applicatives : ce sont l’ensemble des menaces qui peuvent altérer les applications ou les sites web d’une entreprise (Charpentier et Torstenson 2013). Ces menaces incluent celles sur les bases de données, les serveurs d’application et les serveurs de base de données. Le document (OWASP 2018b) donne une liste des dix attaques les plus répandues sur les applications web et les contre-mesures possibles. Parmi ces attaques, on peut citer : Injection, Broken Authentication, Sensitive Data Exposure, XML External Entities (XXE), Broken Access Control, Security Misconfiguration, Cross Site Scripting (XSS), Insecure Deserialization, Using Components with Known Vulnerabilities, Insufficient Logging, HHTP flood DDoS, etc. (Charpentier et Torstenson 2013) ; – menaces réseaux : il existe deux types d’équipements réseaux. Le premier type, composé des équipements tels que les routeurs ou les commutateurs, sert à acheminer les données d’un point à un autre du réseau. Le second type, composé des équipements de sécurité tels que les pare-feux, les IDS, les IPS, sert à sécuriser les échanges. Un

.

Risques d’attaques réseaux

121

équipement réseau manquant, mal configuré ou mal placé, peut engendrer des vulnérabilités exploitables par un attaquant. Les vulnérabilités courantes incluent de faibles paramètres d’installation, un contrôle d’accès non adapté et des équipements non mis à jour par rapport aux derniers correctifs de sécurité. Le rapport de Microsoft (Microsoft 2018) évoque les principaux types de menaces suivants : Information gathering, Sniffing, Spoofing, Session hijacking, Denial of service, etc. ; – menaces hôtes : l’hôte est le point terminal d’un réseau. À partir de l’hôte, on peut demander, bénéficier, ou mettre à jour un service réseau. Si un hôte est compromis, il peut provoquer non seulement un mauvais accès au SI, mais il risque aussi de compromettre le SI dans son ensemble. D’après Burke (2018), il peut y avoir plusieurs types de menaces tels que : Malware, Password attacks, Arbitrary code execution, Unauthorised access, Privilege escalation, Backdoor attacks, Physical security threat.

Figure 3.5. Différentes classes d’attaques sur une application web d’un SI

3.3.1.2. Modèle du risque Pour la représentation des paramètres du risque, nous allons nous inspirer de l’approche présentée par OWASP (OWASP 2018a). Dans ce travail, le risque est modélisé par rapport à ces deux paramètres principaux : l’impact et la probabilité d’occurrence des menaces. Chacun de ces deux paramètres est modélisé sous forme d’une hiérarchie de facteurs. Nous appellerons modèle, toute disposition particulière de cette hiérarchie de facteurs. Dans ce qui suit, nous présenterons les deux modèles associés aux paramètres impact et probabilité d’occurrence d’une menace. 3.3.1.2.1. Modèle de l’impact Les impacts d’une attaque sur un SI peuvent être classés en deux catégories (OWASP 2018a) : les impacts sur les affaires de l’entreprise et les impacts techniques.

122

Cybervigilance et confiance numérique

Les impacts sur les affaires sont à leur tour décomposés en plusieurs sous-attributs ou facteurs : secrets, finances et réputations. D’un autre coté, les impacts techniques sont composés des facteurs suivants : confidentialité, intégrité, disponibilité et comptabilité. Cette hiérarchie d’attributs et de facteurs de l’impact peut être représentée par l’arbre de la figure 3.6. La liste de ces attributs et facteurs peut changer d’une institution à l’autre et d’un contexte à l’autre. Pour un niveau donné de l’arbre de l’impact, plus d’importance peut être attribué à un facteur ou attribut plutôt qu’à un autre. Un spécialiste du risque peut accorder plus d’importance à l’attribut impact d’affaires plutôt qu’à l’impact technique. De même, les facteurs des impacts d’affaires peuvent être classés par importance comme suit : financier, réputation et secrets. Nous supposons que l’importance suit un ordre strict (c’est-à-dire quels attributs ou facteurs ne peuvent pas avoir la même importance). L’importance est indépendante des menaces. Dans l’arbre de l’impact, l’importance est associée à l’ensemble des descendants directs d’un nœud (nœuds frères), indépendamment des autres nœuds. Notre notion d’importance est l’équivalent des coefficients de la fonction moyenne pondérée utilisée dans plusieurs travaux d’estimation de l’impact tels que OWASP 2018a. Nous appellerons « modèle de l’impact » l’arbre d’impact trié suivant l’importance choisie des nœuds. La figure 3.6 illustre un modèle de l’impact où, dans le premier niveau, l’impact affaire est considéré comme prioritaire par rapport à l’impact technique. Lors de l’évaluation de l’impact, l’utilisation d’un même modèle évite d’obtenir plusieurs résultats différents pour un même contexte. Plusieurs autres avantages peuvent découler de l’utilisation des modèles. 3.3.1.2.2. Modèle de la probabilité d’occurrence Les attributs ou facteurs caractérisant la probabilité d’occurrence d’une attaque peuvent être classés en deux catégories (OWASP 2018a) : agent de menaces et vulnérabilités. L’attribut agents de menaces est composé de plusieurs facteurs : connaissances, motivation, taille, opportunité. L’attribut vulnérabilité est composé des facteurs suivants : facilité d’exploitation, facilité de découverte, consciences, systèmes de détection. Cette hiérarchie des attributs et des facteurs de la probabilité d’occurrence peut être représentée par l’arbre de la figure 3.6. La liste de ces attributs et facteurs peut changer d’une institution à l’autre. De la même façon, on ordonnera les attributs et les facteurs du paramètre probabilité d’occurrence suivant leurs importances. Nous appellerons « modèle de probabilité d’occurrence » l’arbre de probabilité d’occurrence trié suivant l’importance choisie des nœuds. La figure 3.6 illustre un modèle de probabilité d’occurrence. Lors

Risques d’attaques réseaux

123

de l’évaluation de probabilité d’occurrence, l’utilisation d’un même modèle évite d’obtenir plusieurs résultats différents pour un même contexte.

Figure 3.6. Modèles des paramètres « impact » et probabilité d’occurrence

3.3.1.3. Classification du risque Nous proposons d’utiliser une échelle de classification du risque et de ces paramètres composée de quatre classes ordonnées (de la meilleure à la pire) comme suit (figure 3.7) : bas, moyen, élevé et critique.

Critique

Élevé

Moyen

Bas

Figure 3.7. Classification du risque proposée

3.3.1.3.1. Classification des paramètres du risque La classification adoptée sera celle présentée dans la figure 3.7. Si l’on note I l’impact et O la probabilité d’occurrence, nous décomposerons les valeurs de chacun de ces deux paramètres en classes en divisant leurs intervalles de valeurs respectifs en

124

Cybervigilance et confiance numérique

sous-intervalles. La décomposition en sous-intervalles est effectuée en utilisant des valeurs limites pour chaque paramètre. Ces valeurs limites ou seuils sont choisis au départ. Soit, par exemple, le paramètre I dont les valeurs appartiennent à un intervalle [0, Imax], on choisit trois valeurs seuils de I : SIB, SIM et SIE associés aux classes bas, moyen, élevé et critique. On obtiendra ainsi quatre classes que l’on notera I++, I+-, I-+ et I--. Ces classes sont issues de la décomposition suivante (figure 3.8) : I++ si 0 ≤ I < SIB I+- si SIB ≤ I < SIM I-+ si SIM ≤ I < SIE I-- si SIE ≤ I ≤ Imax La même démarche sera adoptée pour le paramètre O. On choisit trois valeurs seuils de O : SOB, SOM et SOE, nous obtiendrons ainsi la classification présentée dans la figure 3.8.

Figure 3.8. Classification de l’impact et de la probabilité d’occurrence

3.3.1.3.2. Classification du risque Une fois l’impact et la probabilité d’occurrence classés, on peut utiliser ceci pour catégoriser le risque. Pour cela, on définira deux classes globales seuils CGSI et CGSO associées aux deux paramètres I et O. CGSI ou CGSO représente la classe seuil de I ou

Risques d’attaques réseaux

125

de O que le responsable de l’analyse de risque juge acceptable (par exemple CGSI = I+-). Ces deux classes globales seuils vont diviser les valeurs de I (ou de O) en deux catégories qu’on notera I+ (ou O+) et I- (ou O-) définies comme suit : – I+ (ou O+) si classe de I (ou O) est égale ou meilleure que CGSI (resp. CGSO) ; – I- (ou O-) si classe de I (ou O) est pire que CGSI (resp. CGSO). Les classes de I et de O ainsi obtenues vont nous servir à classer le risque. On aura quatre possibilités représentant les quatre classes du risque suivantes : – classe 1 notée I+O+ : c’est la classe où l’impact appartient à I+ et l’occurrence à O ; +

– classe 2 notée I+O- : c’est la classe où l’impact appartient à I+ et l’occurrence à O- ; – classe 3 notée I-O+ : c’est la classe où l’impact appartient à I- et l’occurrence à O+ ; – classe 4 notée I-O- : c’est la classe où l’impact appartient à I- et l’occurrence à O-. Pour donner une meilleure signification à cette classification de risque, nous pouvons ordonner ces classes de la meilleure à la pire. La meilleure et la pire classes seront respectivement I+O+ et I-O-. En revanche, pour discriminer entre les classes I+Oet I-O+, il faut qu’un responsable décide quel paramètre du risque est prioritaire. Par exemple, si l’on considère que I est prioritaire, on aura le classement ordonné figure 3.9.

Figure 3.9. Classification du risque

3.3.2. Appréciation des risques Lors de l’étape d’établissement du contexte, nous avons proposé de représenter chacun de ces paramètres sous forme d’un arbre d’attributs et de facteurs (figure 3.6). Pour estimer la valeur de l’un des paramètres du risque, nous commencerons par attribuer une valeur de criticité à ces facteurs représentés par les feuilles de l’arbre. La valeur de criticité qu’on attribuera sera soit 0 (en binaire 00) si la criticité de ce facteur est basse, soit 1 (en binaire 01) si la criticité est moyenne, soit 2 (en binaire 10) si la

126

Cyybervigilance et confiance numé érique

criticité est e élevée, soiit 3 (en binairre 11) si la criiticité est très élevée ou crittique. Les valeurs de d criticité des facteurs serront agrégées au niveau du nœud père ett ainsi de suite jusqqu’à atteindre la racine de l’’arbre. La valeeur obtenue auu niveau de la racine est celle quii représente la l criticité duu paramètre du d risque. La méthode utilisée pour agréger les l valeurs de criticité des facteurs fa est app pelée méthodee de l’alternannce de bits (Karoui 2016). 2 Dans ce qui suit, nous commeencerons par introduire la méthode d’alternaance de bits, puis p nous monntrerons comm ment l’utiliser pour l’apprécciation de l’impact,, de la probabiilité d’occurrennce, et finalem ment du risque. 3.3.2.1. Méthode de d l’alternancce de bits pour p l’agréga ation des valeurs de criticité Cettee méthode est basée sur un algorithme biinaire qui perm met d’agréger plusieurs valeurs de d facteurs poour construire une métriquee unique. La particularité p dd’une telle métriquee est qu’elle est réversible. Au besoin, ellle permet de restituer les vvaleurs de criticité des d constituannts ou facteurs utilisés pour construire c la métrique. m La méthode m d’alterrnance de bitss consiste à ag gréger des mots binaires repprésentant la criticitté des facteurrs dans une sééquence uniqu ue représentannt une métriquue unique. L’agrégaation tient en considération l’importance des facteurs. Elle est accoomplie en alternantt les séquencess de bits des facteurs f du plu us important au a moins impoortant. La figure 3.10 montre le cas c de l’agrégaation de quatree facteurs F1 = ‘10’ (criticitté élevée), F2 = ‘11’ (criticité crittique), F3 = ‘001’ (criticité moyenne), m F4 = ‘00’ (criticiité basse), F3 etF4. En apppliquant l’alterrnance de on prenddra comme orddre d’importannce : F1, F2,F bits à F1, F2, F3 et F4, on obtieent la séquen nce M=‘110000110’, dont la valeur équivalennte en décimal est198 (figurre 3.10).

Figure 3.10. 3 Alternanc ce de bits

Risques d’attaques réseaux

127

La méthode de l’alternance de bits est réversible. À partir d’une séquence binaire (associée à une valeur décimale), si on connaît le modèle, c’est-à-dire le nombre de facteurs, leur ordre d’importance et leurs tailles respectives, on peut les restituer. L’inversion est un processus itératif qui lit bit par bit la séquence unique et affecte le bit lu, à tour de rôle (selon l’importance), à l’un des facteurs. Ceci est répété jusqu’à la fin de la séquence. Si on reprend la séquence précédente M =‘11000110’,lors de la première itération, le premier bit 1 est affecté à F1=‘1’, le deuxième bit 1 à F2=‘1’, le troisième bit 0 à F3=‘0’ et le quatrième bit 0 à F4=‘0’. Dans la seconde et dernière itération, le cinquième bit 0 est affecté à F1=‘10’, le sixième bit 1 à F2=‘11’, le septième bit 1 à F3=‘01’, et finalement le huitième bit 0 à F4=‘00’. 3.3.2.2. Appréciation de l’impact Après avoir expliqué la méthode de l’alternance de bits, nous allons montrer maintenant comment l’étendre pour l’utiliser dans l’estimation du paramètre impact. L’appréciation de l’impact se fera pour chaque ressource importante de l’entreprise et pour chacune des menaces qui s’y rapportent. Le modèle de l’impact est un arbre constitué de la racine (niveau 0) plus deux niveaux (niveau 1 et niveau 2). On commencera par appliquer la méthode de l’alternance de bits au niveau 2, c’est-à-dire au niveau des feuilles. L’agrégation se fait uniquement au niveau des nœuds appartenant au même nœud parent. Les résultats obtenus sont remontés au niveau 1 où, à leur tour, ils seront agrégés et remontés à la racine. Si l’on représente par AB() la fonction de l’alternance de bits et si on l’applique au modèle de l’impact de la figure 3.6, cela reviendra à exécuter la fonction : AB(AB(F1,1 ; F1,2 ; F1,3) ; AB(F2,1 ; F2,2 ; F2,3; F2,4)) La séquence obtenue est traduite en une valeur décimale. Cette valeur est comparée à la valeur maximale pour avoir une idée de l’ampleur de l’impact. Étude de cas Nous prenons le cas d’une entreprise d’e-commerce, dont le réseau est composé de trois zones (figure 3.11) : le LAN, la DMZ et une zone de paiement sécurisé. Les trois zones sont protégées par un firewall à l’entrée du réseau. La zone DMZ contient tous les serveurs accessibles de l’extérieur de l’entreprise dont un serveur web qui est d’une importance particulière pour l’entreprise. À travers ce serveur, on accède au site web de vente en ligne de l’entreprise. La zone de paiement est protégée par un IPS. Nous étudions le cas d’une menace d’attaque applicative du genre http flood sur le serveur web de l’entreprise.

128

Cybervigilance et confiance numérique

Figure 3.11. Architecture du réseau de l’entreprise d’e-commerce

Une telle attaque peut avoir des répercussions très néfastes sur l’entreprise. Dans ce qui suit, nous utiliserons notre modèle du risque pour estimer l’impact d’une telle attaque sur le serveur web de l’entreprise. Pour cela, nous commençons d’abord par donner des valeurs de criticité aux facteurs du modèle d’impact (figure 3.6) comme suit : – financier (F1,1) : cette attaque va provoquer l’arrêt du serveur web pendant la période de l’attaque. Elle aura donc un impact financier très grave. Pour cela, on affecte la valeur critique ‘11’ à ce facteur ; – réputation (F1,2) : dans un monde de concurrence vorace, une telle attaque aura un impact important sur la réputation de l’entreprise. Pour cela, on affecte la valeur critique ‘11’ à ce facteur ; – secret (F1,3) : cette attaque ne va pas toucher aux secrets de l’entreprise. Elle aura donc peu d’impact sur les secrets de l’entreprise. Pour cela, on affecte la valeur basse ‘00’ à ce facteur ;

Risques d’attaques réseaux

129

– intégrité (F2,1) : cette attaque ne va pas toucher à l’intégrité des données de l’entreprise. Elle n’aura pas d’impact sur l’entreprise. Pour cela, on affecte la valeur basse ‘00’ à ce facteur ; – disponibilité (F2,2) : cette attaque va provoquer une indisponibilité du site de l’entreprise. Pour cela, on affecte la valeur critique ‘11’ à ce facteur ; – confidentialité (F2,3) : cette attaque ne va pas toucher la confidentialité des données de l’entreprise. Pour cela, on affecte la valeur basse ‘00’ à ce facteur ; – comptabilité (F2,4) : cette attaque ne va pas toucher la comptabilité. Pour cela, on affecte la valeur basse ‘00’ à ce facteur. L’application de notre méthode sur l’arbre du modèle de l’impact avec ces valeurs de criticité consiste à remplacer les valeurs dans la fonction : AB(AB(F1,1 ; F1,2 ; F1,3) ; AB(F2,1 ; F2,2 ; F2,3; F2,4)) = AB(AB(‘11’ ;’11’ ;’00’) ;(‘00’ ;’11’ ;’00’ ;’00’)) = ‘10110010100100’ En traduisant cette séquence en valeur décimale, nous obtenons une valeur d’impact de 11 428. Si l’on compare cette valeur avec la valeur maximale 16 383 (correspondant à la séquence ‘11111111111111’), on déduit que cette valeur de l’impact est assez élevée. 3.3.2.3. Appréciation de la probabilité d’occurrence L’application de la méthode de l’alternance de bits pour estimer le paramètre probabilité d’occurrence est similaire à celle du paramètre impact. Si l’on applique la fonction AB() au niveau du modèle de probabilité d’occurrence de la figure 3.6, cela reviendra à évaluer la fonction : AB(AB(F1,1 ; F1,2 ; F1,3; F1,4) ; AB(F2,1 ; F2,2 ; F2,3; F2,4)) Étude de cas Dans ce qui suit, nous utiliserons notre modèle du risque pour estimer la probabilité d’occurrence de l’attaque http flood sur le serveur web de l’entreprise présentée auparavant (section 3.3.1.2.2). Comme pour l’impact, nous donnerons des valeurs de criticité aux facteurs de probabilité d’occurrence (figure 3.6) : – systèmes de détection (F1,1) : cette attaque ne peut pas être interceptée par les équipements de sécurité du réseau de l’entreprise qui se résument en un firewall. Pour cela, on lui affecte la valeur critique ‘11’ ;

130

Cybervigilance et confiance numérique

– consciences (F1,2) : on suppose que les responsables de l’entreprise ne sont pas complètement conscients de la gravité de cette menace. Pour cela, on lui affecte une valeur de criticité assez élevée’10’ ; – facilité de découverte (F1,3) : cette vulnérabilité n’est pas très difficile à découvrir. Il suffit de scanner les ports ouverts ou tout simplement d’entamer l’attaque pour savoir si le serveur web est vulnérable ou pas. Pour cela, on lui affecte la valeur critique ‘11’ ; – facilité d’exploitation (F1,4) : cette vulnérabilité est très facile à exploiter. Pour cela, on lui affecte la valeur critique ‘11’ ; – connaissance (F2,1) : cette attaque ne demande pas de connaissances aigus de l’attaquant. Pour cela, on affecte la valeur critique ‘11’ à ce facteur ; – opportunité (F2,2) : ce facteur représente les ressources et les opportunités nécessaires pour effectuer une telle attaque. Puisque cette attaque nécessite un minimum de ressources, on affectera la valeur critique ‘11’ à ce facteur ; – motivation (F2,3) : on suppose que l’entreprise a beaucoup de concurrents et donc il y a une motivation élevée pour nuire aux activités de l’entreprise. Pour cela, on affecte la valeur de criticité assez élevée ‘10’ à ce facteur ; – taille (F2,4) : on suppose que la taille ou le nombre de personnes voulant faire une telle attaque est assez élevé. Pour cela, on affecte la valeur de criticité assez élevée ‘10’ à ce facteur. L’application de notre méthode sur l’arbre de probabilité d’occurrence avec ces valeurs de criticité consiste à remplacer les valeurs dans la fonction : AB(AB(F1,1 ; F1,2 ; F1,3; F1,4 ) ; AB(F2,1 ; F2,2 ; F2,3; F2,4)) = AB(AB(‘11’ ;’10’ ;’11’ ; ‘11’) ;(‘11’ ;’11’ ;’10’ ;’10’)) = ‘1111111111011010’ En traduisant cette séquence en valeur décimale, nous aurons une valeur de probabilité d’occurrence de65 498. Si l’on compare cette valeur à la valeur maximale 65 535 correspondant à la séquence ‘1111111111111111’, on peut déduire qu’elle est critique. 3.3.2.4. Appréciation globale des risques Comme décrit dans la section relative à l’établissement du contexte (section 3.3.1), pour pouvoir apprécier le risque, on doit passer par la classification des paramètres impact et probabilité d’occurrence.

Risques d’attaques réseaux

131

3.3.2.4.1. Classification de l’impact Pour classer l’impact, nous devons diviser l’intervalle de valeurs de l’impact en quatre sous-intervalles représentant chacun une classe de l’impact. Cette classification nécessite l’utilisation des seuils des classes d’impact (section 3.3.1.3.1) : SIB, SIM et SIE. Dans cette section, nous adopterons la stratégie de division de l’intervalle de valeurs de l’impact en quatre sous-intervalles de tailles à peu près équivalentes. Dans notre cas, sachant que la valeur d’impact appartient à l’intervalle [0..16383], nous aurons donc les classes I++ pour l’intervalle [0..4096[, I-+ pour l’intervalle [4096..8192[, I+- pour l’intervalle [8192..12288[, et I-- pour l’intervalle [12288..16383]. En se référant à l’étude de cas présentée dans la section 3.3.2.2, la valeur de l’impact qui est de 11 428 appartient à la classe élevée I--. 3.3.2.4.2. Classification de la probabilité d’occurrence Pour le classement du paramètre probabilité d’occurrence, nous adopterons la même stratégie que pour l’impact. Nous diviserons l’intervalle de valeurs de la probabilité d’occurrence en quatre sous-intervalles de tailles presque équivalentes. Sachant que la valeur maximale de la probabilité d’occurrence est de 65 535, nous aurons donc les classes O++ pour l’intervalle [0..16384[, O-+ pour l’intervalle [16384..32768[, O+- pour l’intervalle [32768..48152[, et O-- pour l’intervalle [48152..65535]. Pour notre étude de cas de la section 3.3.2.2, la valeur de la probabilité d’occurrence qui est de 65 498 appartient à la classe critique O-. 3.3.2.4.3. Appréciation du risque Après avoir classé l’impact et la probabilité d’occurrence, nous pouvons maintenant passer à l’appréciation du risque. Pour cela, les décideurs doivent spécifier deux classes globales seuils CGSI et CGSO associées aux deux paramètres I et O (section 3.3.1.3.2). Ces classes globales seuils définissent les classes de valeurs de I (resp. de O) qui sont jugées acceptables. Par exemple, si l’on fixe CGSI = I++ et CGSO = O++, nous aurons les valeurs acceptables de I (classe I+) appartenant à l’intervalle [0..4096[et celles dans l’intervalle [4096..16383] appartiennent à la classe I-. De même, pour O, les valeurs dans [0..16384[ appartiennent à O+ et celles dans l’intervalle [16384..65535] appartiennent à la classe O-. De cette manière, nous obtenons la classification présentée dans la section 3.3.1.3.2 (figure 3.9). Pour notre étude de la section 3.3.2.2, la valeur de I = 11 428 appartient à la classe Iet O = 65 498 appartient à la classe O-. Ce qui nous donne la pire classe de risque I-O-.

132

Cybervigilance et confiance numérique

3.3.3. Traitement du risque Pour définir les actions à entreprendre pour traiter le risque, il faut non seulement prendre en considération les valeurs du risque et de ses deux paramètres, mais aussi les coûts de leur traitement éventuel. Il existe quatre alternatives du traitement du risque : a) le risque doit être éliminé et donc des activités de correction doivent être entreprises quel que soit le coût ; b) le risque est ingérable au niveau de cette entité et les données seront transmises à une autre entité pour le gérer ; c) le risque doit diminuer en réduisant ces impacts et sa probabilité d’occurrence ; d) le niveau du risque est acceptable. En analysant les résultats d’appréciation du risque obtenus dans notre étude de cas (section 3.3.2.4), nous constatons que les valeurs de I, de O, ainsi que la classe du risque sont élevées. Pour le traitement du risque, nous considérons que nous avons choisi la troisième alternative, c’est-à-dire les responsables de l’entreprise décident que le risque lié à la menace http flood sur leur serveur web doit diminuer. Pour cela, on doit essayer de réduire ses impacts et sa probabilité d’occurrence. 3.3.3.1. Amélioration des paramètres du risque Pour réduire les valeurs de l’impact et la probabilité d’occurrence d’une menace sur une ressource importante de l’entreprise, il faut s’attaquer en premier aux facteurs qui altèrent leurs valeurs respectives. Nous supposons que celui qui a pour mission de traiter le risque ou de réduire la valeur de ces deux paramètres n’est pas celui qui les a calculés et qu’il ne dispose que des valeurs globales de ces paramètres et non celles de leurs facteurs respectifs. Il doit donc commencer par découvrir les facteurs causant la défaillance de ces paramètres. Pour atteindre cet objectif, nous nous baserons sur deux faits. Le premier est qu’on a utilisé des modèles d’impact et de probabilité d’occurrence où tous les attributs et facteurs sont connus et ordonnés par importance. Le second fait est que nous utilisons la méthode de l’alternance de bit (AB) qui est complètement inversible. 3.3.3.1.1. Restitution des facteurs des paramètres du risque La méthode d’agrégation AB permet, à partir d’une valeur unique de l’impact ou de la probabilité d’occurrence, de retrouver la valeur de criticité de ces facteurs. L’inversion se fait à partir d’une fonction inverse d’AB() notée AB-1(). L’inversion de la séquence binaire I se fera en trois étapes : a) AB-1(M) produira M1 et M2 qui représentent les séquences respectives des attributs du deuxième niveau de l’arbre, c’est-à-dire affaire et technique pour le modèle de

Risques d’attaques réseaux

133

l’impact et vulnérabilité et agent de menace pour la probabilité d’occurrence. Dans notre étude de cas, l’impact M1 sera égal à ‘110110’ et M2 à ‘01000100’. Pour la probabilité d’occurrence, M1 sera égal à ‘11111011’ et M2 à ‘11111100’ ; b) AB-1(M1) produira les facteurs de M1. Pour l’impact, ces facteurs sont ceux de l’attribut affaire : financier (F1,1), réputation (F1,2), et secret (F1,3). Pour la probabilité d’occurrence, ces facteurs sont ceux de l’attribut vulnérabilités : systèmes de détection (F1,1), consciences (F1,2), facilité de découverte (F1,3)et facilité d’exploitation (F1,4). Dans l’étude de cas, pour le paramètre impact, la criticité des facteurs sera : F1,1=‘11’, F1,2=‘11’, et F1,3=‘00’. Pour le paramètre probabilité d’occurrence, la criticité des facteurs sera : F1,1=‘11’, F1,2=‘10’, F1,3=‘11’ et F1,4=‘11’ ; c) AB-1(M2) produira les facteurs de M2 qui sont pour l’impact et pour son attribut technique : intégrité (F2,1), disponibilité (F2,2), confidentialité (F2,3) et comptabilité (F2,4). Pour la probabilité d’occurrence, cela concerne son attribut agent de menace et les facteurs : connaissance, opportunité, motivation et taille. Dans l’étude de cas, F2,1=‘00’, F2,2=‘11’, F2,3=‘00’ , et F2,4=‘00’. 3.3.3.1.2. Amélioration des facteurs du risque Parmi l’ensemble de facteurs dont la valeur est élevée, nous allons choisir un sousensemble de facteurs sur lesquels on peut agir pour améliorer le risque. Par exemple, pour la probabilité d’occurrence, on peut agir sur les facteurs relatifs à l’attribut vulnérabilité et non sur l’agent de menaces. Ceci car l’agent de menaces est un attribut externe qu’on ne peut pas nécessairement modifier. En revanche, les vulnérabilités sont des caractéristiques du SI et du réseau que l’on peut traiter. Si l’on reprend notre étude de cas et les valeurs de criticité de l’attribut vulnérabilités qu’on a restitué, on remarque que pratiquement tous les facteurs de l’attribut vulnérabilités ont des valeurs très élevées : systèmes de détection (F1,1=‘11), consciences (F1,2=‘10’), facilité de découverte (F1,3=‘11’) et facilité d’exploitation (F1,4=‘11’). Pour illustrer le processus d’amélioration de ces facteurs, prenons par exemple le cas de l’amélioration du facteur systèmes de détection (F1,1=‘11’) qui est très important pour l’architecture réseau de l’entreprise et ses équipements de sécurité. En se référant à la figure 3.11, nous constatons que les équipements de sécurité déployés ne sont pas capables de stopper ou de réduire une attaque du type http flood. En effet, le seul équipement de sécurité qui protège l’accès au serveur web de l’entreprise (dans la DMZ) est le firewall d’entrée du réseau. Cet équipement est un équipement de filtrage du niveau réseau et transport et n’est pas capable de stopper une attaque applicative. Pour cela, nous proposons une architecture plus sécurisée du réseau représentée par la figure 3.12. Dans cette nouvelle architecture, nous proposons de rajouter au niveau de la

134

Cybervigilance et confiance numérique

DMZ, un WAF (Web Application Firewall) pour stopper les attaques applicatives, un équilibreur de charge (Load Balancer) qui permet, si jamais une attaque DDoS réussit à s’introduire à travers le WAF, de ne pas bloquer automatiquement le serveur puisqu’il y a partage de charge entre plusieurs serveurs web équivalents, et enfin, un IDS, qui travaille en arrière-plan, pour détecter d’autres scénarios d’attaques. En déployant ces nouveaux équipements, la protection du serveur web contre les attaques http flood est presque assurée. Pour cela, si l’on reprend l’évaluation de la probabilité d’occurrence, nous utiliserons une valeur de criticité basse ‘00’ au facteur systèmes de détection. Si on suppose qu’on ne modifie que ce paramètre, on aura une probabilité d’occurrence représentée par la séquence binaire ‘0111111101011010’ et donc une valeur décimale de 32 602. Si l’on fixe CGSO = O-+ et CGSI = I-+, en comparant à la valeur initiale de 65 498 qui appartient à la classe O-, on a réussi à travers notre nouvelle valeur à améliorer la classe à O+. Ceci améliore la classification du risque de I-O- à I-O+.

Routeur

Zone privée de paiement par carte

Firewall DMZ

Figure 3.12. Architecture sécurisée du réseau

3.3.4. Acceptation du risque Les activités d’appréciation, de traitement et d’acceptation du risque peuvent être considérées comme un processus itératif dont la condition d’arrêt est l’acceptation du

Risques d’attaques réseaux

135

niveau de risque (figure 3.13). Sachant qu’un niveau de risque égal à 0 est généralement impossible à atteindre.

Appréciation du risque

Figure 3.13. Processus d’analyse de risque

L’activité de décision d’accepter ou non le niveau du risque d’un SI est fait par des décideurs en fonction de la gravité d’une menace, de l’importance de la ressource à protéger et des moyens de l’entreprise. Les décideurs peuvent définir pour chaque menace sur une ressource le seuil d’acceptabilité du risque, ce seuil est noté SAR. Par rapport à la figure 3.9, SAR peut être l’une des classes I+O+, I+O-, I-O+ ou I-O-. Dans notre étude de cas, on peut par exemple fixer SAR= I+O-. Dans ce cas, on est en dessous du niveau de risque acceptable puisque la classe du risque est I-O+. 3.3.5. Communication du risque Pour pouvoir communiquer et échanger l’expertise acquise à travers ce processus d’analyse de risque, on doit penser à un système d’archivage qui peut être exploité par les différents intervenants du risque de l’entreprise. On peut penser à une base de données contenant deux tables principales : la table des ressources importantes de l’entreprise et la table des menaces. L’index de la table des ressources peut être exploité dans la table des menaces pour rechercher les menaces liées à cette ressource. La table des menaces contient les champs suivants : index de la menace, description de la menace, ressource cible de l’entreprise, I, CGSI (section 3.3.1.3.2), O, CGSO (section 3.3.1.3.2), SAR (section 3.3.4). Si l’on reprend cette table de menaces

136

Cybervigilance et confiance numérique

dans le contexte de notre étude de cas, pour l’attaque http flood, on aura l’enregistrement : Index de la menace = IndexHttp_flood, Description de la menace = « ……. », Ressource cible de l’entreprise = IndexServeur_web, I = 65498, CGSI = 8, O = 32602, CGSO = 32768, SAR = I+OEn consultant cet enregistrement, nous pouvons voir que O appartient à O+ puisque sa valeur est inférieure à CGSO, tandis que I appartient à I- puisque sa valeur est supérieure à CGSI. La classe du risque est I-O+, elle est en dessous de la classe SAR=I+O-, on doit donc reprendre le processus de traitement du risque. 3.3.6. Surveillance du risque Lors de l’exploitation du SI, plusieurs défaillances fonctionnelles peuvent apparaître. Ceci oblige les décideurs à introduire des changements et des mises à jour au SI. Ces interventions, bien que nécessaires, peuvent induire de nouvelles menaces ou accentuer les risques de menaces existantes. De plus, les différentes sondes (telles que les IDS) du réseau et l’analyse des logs des équipements de sécurité peuvent détecter de nouvelles menaces. L’analyse de risque ne doit donc pas se terminer à la suite du déploiement initial du SI, mais doit se poursuivre et être aux aguets des changements et ajouts de nouveaux risques. Cette activité continue de surveillance et de vigilance fait partie intégrante de l’analyse de risque et s’appelle la surveillance des risques. La surveillance des risques a d’autres objectifs tels que s’assurer que le processus d’analyse de risque reste pertinent et adapté aux objectifs de sécurité de l’entreprise. Par exemple, pour affiner l’analyse de risque, on peut décider d’ajouter ou de modifier un facteur du modèle d’impact ou de probabilité d’occurrence. 3.4. Conclusion Dans un premier temps, nous avons présenté au lecteur la problématique de la sécurisation des SI à travers l’analyse de risque. Nous l’avons familiarisé aux spécificités du risque. Nous avons présenté le vocabulaire technique ainsi que les définitions associées. Nous avons également présenté certaines des plus importantes méthodologies traitant de l’analyse de risque et avons proposé les attributs qui permettent de les comparer. Dans un second temps, nous avons consacré une section pour montrer comment analyser le risque des SI dans un contexte réseau. Nous avons présenté une méthodologie structurée sur la base des différentes phases de la norme 27005. Nous

Risques d’attaques réseaux

137

avons illustré cette méthodologie en l’appliquant sur une étude de cas relative au risque d’attaques applicatives sur le site web d’une entreprise d’e-commerce. Cela permettra au lecteur d’approfondir ses connaissances sur le sujet et d’avoir des bases qui lui permettront de faire des études plus poussées. 3.5. Bibliographie Alberts, C.J. and Dorofee, A. (2002). Managing Information Security Risks: The OCTAVE Approach. Addison-Wesley Longman Publishing Co., Boston. ANSI (2014). Comparatif des méthodes d’audit et d’analyse des risques. Available: https://www. nacs.tn/fr/documents/comparatif_methodes_Audit_AR.pdf, accessed February 22, 2018. Bahtit, H. and Regragui, B. (2012). Modélisation des processus de la norme ISO 27005. National Days of Network Security and Systems (JNS2). IEEE, 1-6. Bloch, L., Wolfhugel, C., Queinnec, C., Makarévitch, N. and Schauer, H. (2007). Sécurité informatique. Principes et méthodes. Eyrolles, Paris. Bou Nassar, P. (2012). Gestion de la sécurité dans une infrastructure de services dynamique: Une approche par gestion des risques. PhDThesis, Lyon, INSA. Brenner, J. (2007). ISO 27001: Risk Management and Compliance. Risk Management, 54(1), 24. Burke, I. and Mouton, F. (2018). Ethical Hacking, CSIR, Available: https%3A% 2F%2Fwww. snode.com%2Fsnode%2Fwp-content%2Fuploads%2F2017%2F04% 2FEthical-Hacking.pdf. Caralli, R.A., Stevens, J.F., Young, L.R. and Wilson, W.R.(2007). Introducing Octave Allegro: Improving the Information Security Risk Assessment Process. CarnegieMellon University, Pittsburgh. Charpentier, J.E. and Torstenson, O. (2013). Web Application Security. Network Project. Available: http://hh.diva-portal.org/smash/get/diva2:610574/FULLTEXT01.pdf, accessed February 22, 2018. Culioli, M., Libes, M., Mouthuy, T., and Kourilsky. M. (2009). Elaboration d’une PSSI au sein d’une unité propre du CNRS: Utilisation de la méthode EBIOS. Available: https://2009.jres.org/planning_files/article/pdf/100.pdf, accessed February 22, 2018. Défense Nationale, Secrétariat Général (2010). EBIOS-Expression des Besoins et Identification des Objectifs de Sécurité, Méthode de Gestion des risques. Report, Agence nationale de la sécurité des systèmes d’information, Paris. Eloff, J.H., Labuschagne, L., and Badenhorst, K.P. (1993). Acomparative framework for risk analysis methods. Computers & Security, 12(6), 597–603. Cette bibliographie est identique à celle de l’ouvrage correspondant en anglais publié par ISTE.

138

Cybervigilance et confiance numérique

ENISA. (2013). ENISA ThreatLandscape.Report, ENISA, Heraklion. Available: http:// www. enisa.europa.eu/activities/risk-management/evolving-threat-environment/enisathreat-landscape-mid-year-2013/at_download/fullReport, accessedFebruary 22, 2018. Ghazouani, M., Faris, S., Medromi, H., and Sayouti, A. (2014). Information security risk assessment – A practical approach with a mathematical formulation of risk. International Journal of Computer Applications, 103(8). Karoui, K. (2016). Security novel risk assessment framework based on reversible metrics: A case study of DDoSattacks on an E‐commerce web server. International Journal of Network Management, 26(6), 553–578. Microsoft (2018). Improving Web Application Security: Threats and Countermeasures. Report. Available: http://www.microsoft.com/downloads/details.aspx? FamilyID=E9C4BAA-AF88-4AA5-88D4-ODEA898C31B9&displaylang=en, accessed February 22, 2018. OWASP (2018a). The OWASP Risk Rating Methodology. Available: https:// www.owasp.org/index. php/OWASP_Risk_Rating_Methodology, accessed February 22, 2018. OWASP (2018b). Top 10. The Ten Most Critical Web Application Security Risks, Available: https:// www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29. pdf.pdf, accessed February 23, 2018. Pons, F. (2014). Etude actuarielle du cyber-risque. Master’s dissertation, Institut des Actuaires, France. Available: http://www.ressources-actuarielles.net/EXT/ISFA/122602.nsf/d512ad5b 22d73cc1c1257052003f1aed/ecd55020616719e1c1257dda002ae1fe/ $FILE/PONS%20Florian.pdf, accessed February 22, 2018. Purdy, G. (2010). ISO 31000: 2009 – setting a new standard for risk management. RiskAnalysis, 30(6), 881–886. SGDN, Direction Centrale De La Sécurité Des Systèmes D’information Sous-Direction Des Opérations Bureau Conseil. (2017). Guide pour l’élaboration d’une politique de sécurité de système d’information : PSSI Section 3 : Principes de sécurité. Available : https://www. ssi.gouv.fr/uploads/IMG/pdf/pssi-section3-principes-2004-03-03.pdf, accessed December 12, 2017. Syalim, A., Hori, Y., and Sakurai, K. (2009). Comparison of risk analysis methods: Mehari, magerit, NIST800-30 and Microsoft’s security management guide. IEEE International Conference on Availability, Reliability and Security. ARES’09, 726– 731. Vasquez, M., Lammari, N., Comyn-Wattiau, I., and Akoka J. (2012). De l’analyse des risques à l’expression des exigences de sécurité des systèmes d’information. Inforsid, Montpellier, France, 337–362. WEF (2012). Risk and responsibility in a hyperconnected world: pathways to global cyber resilience. Available: http://www3.weforum.org/docs/WEF_IT_Pathways ToGlobalCyberResilience_Report_2012.pdf, accessed February 22, 2018.

Chapitre 4

Aperçu analytique du flux d’informations et protection des données privées dans les systèmes Android

Les applications tierces malveillantes peuvent laisser échapper des données personnelles stockées dans le système Android en exploitant les dépendances de contrôle. Le mécanisme de suivi des flux d’informations nous permet de protéger les données sensibles. Il est basé sur la technique de data tainting (dit aussi « marquage de données ») qui est une fonction utilisée pour contrôler la manipulation des données privées et dans laquelle les données entrées par l’utilisateur sont marquées par un tag (dit aussi « marqueur ») qui se propage à toutes les données dérivées de cette entrée. Dans ce chapitre, nous étudions et discutons les différents mécanismes utilisés pour protéger les données sensibles dans les systèmes Android. Ces mécanismes ne peuvent pas détecter les flux de contrôle. Cela peut causer un problème d’under-tainting et donc une incapacité à détecter une fuite d’informations sensibles. Nous proposons une approche formelle et technique basée sur des mécanismes de data tainting combinant l’analyse dynamique et statique pour suivre les flux de contrôle dans le code java et natif des applications et pour résoudre le problème d’under-tainting dans les systèmes Android. Nous montrons que notre approche peut résister aux attaques d’obfuscation du code qui exploitent la propagation de marques à travers les flux de contrôle pour divulguer des informations sensibles. Nous propageons la marque dans les canaux auxiliaires comme le timing, la mémoire cache et le processeur graphique ainsi que dans les métadonnées pour détecter les attaques des canaux auxiliaires logiciels qui tentent de contourner les mécanismes de détection basés sur l’analyse dynamique des données taguées (dynamic taint analysis).

Chapitre rédigé par Mariem GRAA.

140

Cybervigilance et confiance numérique

4.1. Introduction Les appareils Android représentent 80,7 % des ventes mondiales de smartphones sur la plupart des marchés dans le monde (Gartner 2016). Pour rendre les smartphones plus amusants et utiles, les utilisateurs téléchargent généralement des applications tierces. Le développement des applications Android a connu une croissance rapide. En mai 2016, 65 milliards d’applications avaient été téléchargées depuis Google Play Statista (2016). Ces applications sont souvent utilisées pour capturer, stocker, manipuler et accéder à des données sensibles. Dans une étude présentée lors de la conférence Black Hat, Daswani (Wilson, juillet 2011) a analysé le comportement réel de 10 000 applications Android et a montré que plus de 800 d’entre elles provoquent la fuite des données personnelles vers un serveur non autorisé. Il est donc nécessaire de prévoir des mécanismes de sécurité adéquats pour contrôler la manipulation des données à caractère personnel. Le mécanisme de suivi des flux d’informations est utilisé pour surveiller la propagation des données sensibles dans les systèmes Android et pour assurer la sécurité contre les attaques de logiciels malveillants. Le mécanisme de suivi du flux d’informations utilise la technique de data tainting, qui consiste à associer un tag aux données sensibles, puis à propager le tag aux données qui en dépendent pour suivre le flux d’informations dans le programme. Il est utilisé pour la détection des vulnérabilités et la protection des données sensibles. Cependant, cette technique ne détecte pas les flux de contrôle, ce qui peut causer un problème d’undertainting, c’est-à-dire que certaines valeurs doivent être taguées, mais ne le sont pas. Cela peut entraîner l’échec de la détection d’une fuite d’informations sensibles. Ainsi, les applications malveillantes peuvent contourner le système Android et obtenir des informations confidentielles grâce à des flux de contrôle. Dans ce chapitre, nous donnons un aperçu analytique des flux d’informations dans les systèmes Android. Nous proposons une amélioration de l’analyse dynamique qui propage la taint (le marquage) tout au long des dépendances de contrôle pour suivre les flux de contrôle dans le système d’exploitation Google Android. Nous utilisons une approche hybride qui combine et bénéficie des avantages des analyses statiques et dynamiques pour protéger les données sensibles contre les attaques de flux d’informations lancées par des applications tierces. Nous commençons par catégoriser, à la section 4.2, les flux d’informations. Comme le mécanisme de data tainting sert à suivre le flux d’information et à protéger les données sensibles, nous décrivons plus en détail les travaux fondés sur le data tainting à la section 4.3. Nous étudions les travaux relatifs à la sécurité des systèmes Android dans la section 4.4. Nous constatons que ces travaux ne permettent pas de détecter les attaques de flux de contrôle qui peuvent causer un problème d’under-tainting (faux négatif). Ce problème peut provoquer une fuite de données sensibles. Nous présentons à la section 4.5 des solutions basées sur des mécanismes de data tainting et une approche hybride qui combine l’analyse

Aperçu analytique du flux d’informations

141

dynamique et statique pour résoudre ce problème. Nous proposons une approche formelle et technique qui nous permet de gérer les flux de contrôle en code java et en code natif et de résoudre le problème d’under-tainting dans la section 4.6. Nous montrons que notre approche peut résister aux attaques d’obfuscation de code qui exploitent la propagation du tag tout au long des flux de contrôle pour divulguer des informations sensibles dans le système Android dans la section 4.7. Nous proposons une amélioration de notre approche pour détecter les attaques de canaux auxiliaires logicielles qui tentent de contourner les mécanismes de détection basés sur l’analyse dynamique des data tainting dans la section 4.8. Nous comparons les approches de suivi des flux d’informations dans les systèmes Android dans la section 4.9. Enfin, la section 4.10 conclut ce chapitre. 4.2. Flux d’informations Le flux d’informations est le transfert d’informations entre les objets dans un processus donné. Cela peut causer des fuites d’informations sensibles. Par conséquent, tous les flux ne sont pas autorisés. Les flux d’informations se présentent sous différentes formes (canaux). Deux types de flux sont définis : les flux explicites et implicites (Denning 1976). 4.2.1. Flux explicites 1.int x; 2.int y;; 3.x:=y Figure 4.1. Exemple d’un flux explicite

Le flux d’informations explicite est la forme la plus simple de flux d’informations qui se produit lorsque les données sont explicitement affectées à des emplacements de mémoire ou à des variables. Voici un exemple qui montre un transfert explicite d’une valeur de y vers x. Contrairement aux flux implicites, les flux explicites sont faciles à détecter car nous devons justifier, suivre et donner les raisons des affectations explicites. 4.2.2. Flux implicites Les flux implicites se produisent dans la structure de flux de contrôle du programme. Lorsqu’une instruction de branche conditionnelle est exécutée, des

142

Cybervigilance et confiance numérique

informations sur la condition sont propagées dans chaque branche. Dans les flux implicites (flux de contrôle) présentés à la figure 4.2, il n’y a pas de transfert direct de valeur de x à y. Cependant, lorsque le code est exécuté, y contiendra la valeur de x. 1.boolean x; 2.boolean y; 3.if ( x== true) 4. y = true; 5. else 6. y = false; 7.return(y);

Figure 4.2. Exemple d’un flux implicite

Les appels de fonction, les boucles et les instructions goto, les instructions switch et les exceptions représentent d’autres mécanismes de contrôle. Le canal caché le plus important est le flux implicite, mais il y a d’autres canaux cachés que nous présenterons dans ce qui suit. 4.2.3. Canaux cachés Les canaux cachés (Sabelfeld et Myers 2003) comprennent : – les canaux de synchronisation qui fuient les informations à travers le temps auquel un événement se produit ; – les canaux de terminaison qui fuient l’information par le biais de la nonterminaison du calcul ; – les canaux d’épuisement des ressources qui font fuir l’information par l’épuisement d’une ressource limitée ; – les canaux de consommation d’énergie qui fuient l’information par le biais de la consommation d’énergie ; – les canaux de fréquence des processeurs qui fuient l’information par des changements de fréquence ; – l’espace libre sur les canaux du système de fichiers qui fuient des informations sur l’utilisation du système de fichiers des autres applications en se basant sur le nombre de blocs libres ; – les canaux probabilistes qui diffusent de l’information en modifiant la distribution de probabilité des données observables.

Aperçu analytique du flux d’informations

143

4.3. Data tainting Le data tainting est un mécanisme utilisé pour tracer la façon dont les données se propagent dans un système. Le principe de ce mécanisme est de « colorer » (taguer) certaines données d’un programme et d’étendre le tag ensuite à d’autres objets liés à ces données en fonction de l’exécution du programme. Il est principalement utilisé pour la détection des vulnérabilités, la protection des données sensibles et, plus récemment, pour l’analyse des logiciels malveillants binaires. Pour détecter les vulnérabilités, les transactions sensibles doivent être surveillées afin de s’assurer qu’elles ne contiennent pas de données externes. Les trois opérations considérées comme sensibles sont l’exécution d’une commande, la lecture ou l’écriture d’un fichier et la modification du flux de contrôle. La surveillance de la mise en œuvre d’un programme est nécessaire pour propager la coloration des données et détecter les vulnérabilités. Les méthodes pour assurer ce suivi comprennent l’analyse statique pendant la compilation et l’analyse dynamique pendant l’exécution. Le data tainting est implémenté dans les interprètes et dans les simulateurs de système pour analyser les données sensibles. 4.3.1. Approche de l’interprète L’un des travaux les plus connus sur le data tainting est le mode de tainting de Perl (Wall 2000). Perl est un langage interprété qui marque explicitement toutes les données externes comme taguées et empêche leur utilisation dans des fonctions sensibles qui affectent le système local, comme l’exécution de commandes locales, la création et l’écriture de fichiers et l’envoi de données sur le réseau. Le langage de programmation Ruby (Hunt et Thomas 2000) présente un mécanisme de vérification de tag mais avec des niveaux de marquage plus fins que Perl. Il dispose de cinq niveaux de sécurité allant de 0 à 4, à chaque niveau, différents contrôles de sécurité sont effectués. Vogt et al. (2007) mettent en œuvre un mécanisme de data tainting dans un interpréteur Javascript pour détecter et prévenir les vulnérabilités des scripts intersites. RESIN (Yip et al. 2009) suit les applications de données développées par un langage d’exécution, comme l’interpréteur Python ou PHP pour prévenir les attaques d’applications web. Xu et al. (2006) implémentent une analyse fine des données taguées dans l’interpréteur PHP pour détecter les attaques par injection SQL. L’une des limites des approches de marquage basées sur l’interpréteur est qu’elles ne peuvent protéger contre les vulnérabilités que dans le code source spécifique au langage.

144

Cybervigilance et confiance numérique

4.3.2. Approche basée sur l’architecture Chow et al. (2004) ont mis au point un outil basé sur la simulation de systèmes complets appelé TaintBochs pour mesurer la durée de vie des données. TaintBochs suit la propagation des données sensibles à l’aide du mécanisme de marquage au niveau matériel. Les auteurs effectuent une simulation dans laquelle les données sensibles sont identifiées comme taguées. Ensuite, les données de simulation sont analysées par le framework d’analyse. Minos (Crandall et al. 2006) propose une extension matérielle qui modifie l’architecture et le système d’exploitation pour suivre l’intégrité des données. Il ajoute un bit d’intégrité au mot de mémoire au niveau de la mémoire physique. Ce bit est activé lorsque les données sont écrites par le noyau dans l’espace mémoire d’un processus utilisateur. Minos met en œuvre la politique lowwatermark de Biba (1977) pour protéger le flux de contrôle lorsqu’un programme déplace des données et les utilise pour des opérations. Suh et al. (2004) modifient le cœur du processeur en mettant en œuvre le suivi dynamique des informations et la vérification des étiquettes de sécurité. Ils corrompent les entrées provenant de canaux potentiellement malveillants et suivent les flux d’informations fallacieuses afin de prévenir les attaques de logiciels malveillants. RIFLE (Vachharajani et al. 2004) traduit un programme binaire en une exécution binaire, sur une architecture processeur, qui prend en charge la sécurité des flux d’informations. La traduction binaire convertit tous les flux implicites en flux explicites pour suivre tous les flux d’informations par des mécanismes dynamiques. Le système d’exploitation utilise les étiquettes définies par l’architecture RIFLE pour s’assurer qu’aucun flux illégal ne se produit. Sapper (Li et al. 2014) présente un langage de description du matériel pour la conception de composants matériels critiques pour la sécurité. Il utilise l’analyse statique au moment de la compilation pour insérer automatiquement des contrôles dynamiques dans le matériel résultant qui appliquent de manière prouvée une politique de flux d’informations donnée au moment de l’exécution. Cependant, il exige de l’utilisateur qu’il redessine le matériel en utilisant un nouveau langage. La limite de ces approches basées sur l’architecture est qu’elles nécessitent des modifications matérielles et ne peuvent donc pas être utilisées directement avec les systèmes actuels. 4.3.3. Analyse statique des données taguées L’analyse statique des données taguées nous permet d’analyser le code sans l’exécuter. Cette analyse examine le code du programme et recherche les failles dans le codage des applications. En général, elle est utilisée pour trouver des bogues des portes dérobées ou tout autre code malveillant. Dans la plupart des cas, cette analyse nécessite le code source, qui n’est pas toujours disponible. De plus, ce n’est pas suffisant

Aperçu analytique du flux d’informations

145

pour la numérisation. Un outil d’analyse statique plus récent analyse le code binaire au lieu du code source pour rendre le test logiciel plus efficace et complet. L’analyse statique des données taguées est utilisée dans l’analyseur statique Splint d’Evans (Evans et Larochelle 2002) et Cqual (Zhang et al. 2002) pour détecter les bogues des programmes C. Les données d’entrée sont annotées avec tainted et nontainted pour trouver les vulnérabilités de sécurité telles que les vulnérabilités du format de chaîne et les débordements de tampon. Shankar et al. (2001) utilisent Cqual pour détecter les bogues de format de chaîne dans les programmes C au moment de la compilation. L’inconvénient majeur de l’approche basée sur l’analyse statique de Splint et Cqual est qu’elle nécessite un accès au code source. Denning (Denning 1976 ; Denning et Denning 1977) définit un mécanisme de certification à l’aide d’un modèle en treillis à la phase d’analyse statique de la compilation. Le mécanisme de certification Denning détermine la cohérence du flux de données, avec la relation de flux des classes de sécurité spécifiée par le programmeur. JFlow (Myers 1999) est une extension du langage Java. Il implémente des annotations de flux d’informations contrôlées statiquement pour éviter les fuites d’informations à travers les canaux de stockage. SFlow (Huang et al. 2014) est une analyse des données taguées basée sur le type pour les applications web Java afin de sécuriser le flux d’informations. Les programmeurs n’ajoutent que quelques annotations pour spécifier les sources et les puits, et l’analyse d’inférence déduit une erreur de type concret ou de type rapport, indiquant des violations du flux d’informations. Les approches d’analyse statique ont certaines limites en raison de problèmes d’indécidabilité (Landi 1992). Elles ne peuvent jamais savoir si l’exécution d’un programme spécifique pour une entrée donnée prendra fin. Une autre limitation des outils d’analyse statique est le fait qu’ils signalent des problèmes qui ne sont pas vraiment des bogues dans le code, c’est-à-dire qu’ils identifient des comportements d’erreur qui ne peuvent pas vraiment se produire dans n’importe quelle exécution du programme (faux positifs) (Chess et McGraw 2004). 4.3.4. Analyse dynamique des données taguées Contrairement à l’analyse statique des données taguées, l’analyse dynamique de ces données est effectuée au moment de l’exécution. Elle nous permet de tester et d’évaluer un programme en exécutant du code. L’objectif de cette analyse est de détecter les vulnérabilités potentielles en matière de sécurité. Elle ne nécessite pas d’accès au code source et trace un code binaire pour comprendre le comportement du système. De nombreux outils d’analyse dynamique des données taguées sont basés sur l’instrumentation de code binaire pour déterminer comment l’information circule dans le programme. TaintCheck (Newsome et Song 2005) utilise l’outil Valgrind (Nethercote

146

Cybervigilance et confiance numérique

et Seward 2003) pour instrumenter le code et effectuer une analyse dynamique des données taguées au niveau binaire. Il associe le tag aux données d’entrée provenant d’une source non fiable. Ensuite, il suit la manipulation des données dans les instructions pour propager le tag au résultat. TaintCheck nous permet de détecter les attaques overwrite telles que les cibles de saut qui incluent les adresses de retour, les pointeurs de fonction ou les décalages de pointeur de fonction et les attaques de chaîne de format. Pour détecter les attaques de cibles de saut, TaintCheck vérifie si des données taguées sont utilisées comme cible de saut avant chaque instruction de saut UCode. Il vérifie également si les données taguées sont utilisées comme argument de chaîne de format pour la famille printf des fonctions de bibliothèque standard pour détecter les attaques de chaînes de format. TaintTrace (Cheng et al. 2006) protège les systèmes contre les exploits de sécurité tels que les chaînes de format et les débordements de tampon. Il utilise l’instrumentation de code pour tracer dynamiquement la propagation des données taguées. TaintTrace est plus efficace que TaintCheck parce qu’il met en œuvre un certain nombre d’optimisations pour réduire l’overhead. LIFT (Qin et al. 2006) est un système logiciel de suivi des flux d’informations qui réduit l’overhead en utilisant des optimisations et des instruments binaires dynamiques. LIFT nous permet de détecter les attaques de sécurité qui corrompent les données de contrôle, telles que les adresses de retour et les pointeurs de fonction. Haldar et al. (2005) utilisent l’instrumentation du code binaire pour implémenter la propagation des tags dans la machine virtuelle Java. Ils instrumentent des classes Java pour définir des sources non fiables et des puits sensibles. Ils marquent les chaînes de caractères comme taguées et propagent le tag aux chaînes de caractères qui en dépendent. Une exception est soulevée lorsqu’une chaîne de caractère taguée est utilisée dans une méthode définie comme un taint sink. Yin et al. (2007) proposent un prototype de bout en bout appelé Panorama pour la détection et l’analyse des logiciels malveillants. Ils exécutent une série de tests automatisés pour générer des événements qui introduisent des informations sensibles dans le système client. Pour surveiller la façon dont les informations sensibles se propagent dans le système, ils effectuent un suivi des flux d’informations fines à l’échelle du système. Ils génèrent un graphe de tag pour définir diverses stratégies spécifiant le comportement caractéristique de différents types de logiciels malveillants. Hauser et al. (2012) étendent Blare, un moniteur de flux d’informations au niveau du système d’exploitation, pour mettre en œuvre une approche permettant de détecter les violations de confidentialité. Ils définissent une politique de confidentialité basée sur un marquage dynamique des données (George et al. 2009). Ils associent les étiquettes aux informations sensibles et définissent les informations qui peuvent quitter le système local par le biais d’échanges en réseau. Les approches d’analyse dynamique des données taguées précédentes instrumentent le code d’application pour tracer et maintenir l’information sur la propagation.

Aperçu analytique du flux d’informations

147

Elles souffrent donc d’une surcharge de performance importante qui n’encourage pas leur utilisation dans les applications en temps réel. Plus récemment, Cox (2016) a amélioré l’analyse dynamique des données taguées dans la JVM et réduit les surcharges de performance en diminuant les instructions d’instrumentations du programme. La principale limite de toutes les méthodes d’analyse dynamique des données taguées est qu’elles ne détectent pas les flux de contrôle (Volpano 1999). Nous nous concentrons dans ce qui suit sur la sécurité des systèmes Android et étudions les différents mécanismes utilisés pour protéger les données privées des utilisateurs. 4.4. Protection des données privées dans les systèmes Android Le nombre d’applications disponibles dans le Google Play Store a été évalué à 2,6 millions d’applications en décembre 2018, après avoir dépassé 1 million en juillet 2013 (Statista 2018). Les applications de smartphones tiers ont accès à des données sensibles et peuvent compromettre la confidentialité et l’intégrité des smartphones. Plusieurs travaux ont été proposés pour sécuriser les systèmes d’exploitation mobiles. Nous présentons d’abord des approches qui nous permettent de contrôler l’accès aux données, puis nous nous concentrons sur des approches utilisant le mécanisme de suivi du flux d’informations pour prévenir la fuite de données privées. 4.4.1. Approche du contrôle d’accès Selon Android Police, toute application installée sur les téléphones HTC qui se connecte à Internet peut accéder aux adresses email, aux positions GPS, aux numéros de téléphone et autres informations privées (Klimas 2011). Les applications Android peuvent utiliser des permissions excessives pour accéder aux données de l’utilisateur. AhnLab a analysé 178 applications Android en utilisant AhnLab Mobile Smart Defense. L’analyse montre que 42,6 % de toutes les applications examinées nécessitent des permissions excessives pour l’accès aux informations sur le téléphone et 39,3 % demandent des permissions excessives pour l’accès aux informations de localisation, suivies par l’autorisation d’accès aux informations personnelles à 33,1 % et informations de chargement de téléphone à 8,4 % (AhnLab 2012). Les autorisations excessives d’accès aux données de l’utilisateur peuvent provoquer la fuite des informations privées. Nous présentons ci-dessous des approches utilisant des politiques basées sur des règles pour contrôler l’accès aux données et des travaux sur la prévention des attaques d’élévation de privilèges.

148

Cybervigilance et confiance numérique

4.4.1.1. Approche politique basée sur des règles De nombreux travaux basés sur de nouveaux langages de politique ont été proposés pour améliorer la protection des systèmes de téléphones intelligents. Le service de sécurité Kirin pour Android (Enck et al. 2009) effectue une certification légère des applications afin d’assurer un service de sécurité pour Android lors de l’installation. La certification Kirin est basée sur des règles de sécurité correspondant à des propriétés indésirables dans des configurations de sécurité associées à des applications. La politique Kirin contrôle les permissions des applications en vérifiant la cohérence des permissions demandées par les applications et la politique de système. Kirin ne peut pas prendre de décisions sur les mesures de sécurité locales prises par les applications ; il souffre donc de faux positifs. Comme Kirin ne prend pas en compte les politiques d’exécution, le framework Secure Application Interaction (SAINT) (Ongtang et al. 2012) étend l’architecture de sécurité Android existante avec une politique d’installation qui définit l’attribution des permissions aux applications, et une politique d’exécution qui contrôle l’interaction des composants logiciels dans le framework middleware Android. La politique de Saint est définie par les développeurs d’applications, ce qui peut conduire à ne pas prendre en compte toutes les menaces de sécurité. En outre, SAINT ne peut pas contrôler le flux de données de la communication interprocessus. Nauman et al. (2010) présentent Apex, une extension du framework de permissions Android, qui restreint l’utilisation des ressources des téléphones par les applications. Il permet à l’utilisateur d’accorder et de refuser des permissions aux applications en imposant des contraintes d’exécution sur l’utilisation des ressources sensibles. Le modèle de Nauman et al. est significativement différent de celui de Kirin (Enck et al. 2009) puisqu’il est centré sur l’utilisateur. Il permet à l’utilisateur d’accorder des permissions sur son appareil plutôt que d’automatiser les décisions basées sur les politiques des propriétaires distants. Conti et al. (2011) incluent le concept de contrôle d’accès contextuel dans les smartphones. Ils mettent en œuvre CrePE (Context-related Policy Enforcing) qui applique des politiques contextuelles fines. Le contexte dépend de l’état de certaines variables et de l’interaction entre l’utilisateur et le smartphone. CrePE permet à l’utilisateur et à des tiers de confiance de définir et d’activer des politiques au moment de l’exécution. Il propose une solution, basée sur des contraintes environnementales, pour limiter les permissions d’une application en activant/désactivant des fonctionnalités. Cependant, il ne traite pas des attaques d’élévation des privilèges car il ne se concentre pas sur l’utilisation des permissions transitives dans les différentes applications. Backes et al. (2012) étendent le système de permission d’Android pour prévenir les comportements malveillants. Ils proposent AppGuard, qui applique une politique de sécurité fine. Il prévient les vulnérabilités du système d’exploitation et des applications tierces. Il nous permet de révoquer les attributs de permissions dynamiques

Aperçu analytique du flux d’informations

149

aux applications malveillantes pour protéger le système Android des attaques du monde réel. Aurasium (Xu et al. 2012) contrôle l’exécution des applications pour protéger les données privées. Il recon-ditionne les applications non fiables pour gérer le bac à sable au niveau de l’utilisateur et l’application des politiques. Le concept de sécurité par contrat (SxC) (Desmet et al. 2008) est utilisé pour sécuriser les applications mobiles non fiables. Il consiste à définir un contrat de sécurité pour l’application et à faire correspondre ces contrats avec les politiques des téléphones. Ceci nous permet de vérifier que l’application ne violera pas la politique contractuelle. EasyGuard (Ren et al. 2016) fournit automati-quement un contrôle d’accès adaptatif lorsque le contexte spécifique est détecté selon les politiques préconfigurées. L’approche politique fondée sur des règles exige la définition et le maintien des règles de la politique. Les développeurs d’applications définissent ces règles de la politique, ce qui peut conduire à ne pas prendre en compte toutes les menaces de sécurité. CoDRA (Thanigaivelan et al. 2017) est un système de contrôle d’accès pour Android qui offre la possibilité d’appliquer différentes configurations de politiques à différents niveaux de fonctionnement du système pour protéger les ressources ouvertes, par exemple, les capteurs par utilisateur grâce à son intégration du support multi-utilisateurs dans Android. Apex (Nauman et al. 2010) est une autre solution qui permet aux utilisateurs de spécifier des politiques pour se protéger des applications malveillantes. Toutefois, il est difficile d’élaborer des politiques utiles et utilisables. 4.4.1.2. Approche de prévention de l’élévation des privilèges L’approche de prévention de l’élévation des privilèges est définie au niveau de l’application et du noyau Android pour protéger le système Android des attaques d’élévation des privilèges. L’inspection IPC (Felt et al. 2011) est un mécanisme de système d’exploitation qui protège les applications du système Android du risque de redélégation de permission introduit par la communication inter-applications. Pour éviter la redélégation de la permission, Felt et al. (2011) réduisent les privilèges d’une application dans le cas de communication avec une application moins privilégiée. Cela permet au système de permission d’empêcher un appel privilégié de l’API par l’administrateur lorsque l’application influencée n’a pas suffisamment d’autorisation. Cependant, l’inspection de la communication inter-processus ne peut pas empêcher les attaques de collusion lancées par des développeurs malveillants et les attaques par des canaux cachés. En outre, l’inspection IPC ne peut pas déterminer le contexte de la source de l’appel. Pour remédier à ce problème, QUIRE (Dietz et al. 2011) assure la sécurité des applications locales et distantes communiquant par IPC (inter-procedural communication) et RPC (remote procedural communication) respectivement. Cette sécurité est basée sur la chaîne d’appel et la source des données des requêtes. Il permet aux applications d’observer toute la chaîne d’appel associée à la demande par des IPC annotés et de choisir les privilèges réduits de ses appelants. Fragkaki et al. (2012)

150

Cybervigilance et confiance numérique

mettent en œuvre Sorbet, un système d’application qui nous permet de préciser les politiques de protection de la vie privée et d’intégrité des données. Sorbet améliore les systèmes de permissions Android existants en implémentant des mécanismes à grain grossier pour protéger les applications contre l’élévation des privilèges et les flux d’informations indésirables. Pour remédier aux failles de l’implémentation Android de la délégation de permissions, Sorbet offre aux développeurs la possibilité de spécifier les contraintes qui limitent la durée de vie et la portée de la redélégation des permissions déléguées. Bugiel et al. (2011) proposent XManDroid pour détecter et prévenir les attaques d’élévation de privilèges au niveau des applications au moment de l’exécution. Ils analysent dynamiquement les communications entre les applications Android pour vérifier si elles respectent les règles de sécurité imposées par la politique système. L’inconvénient majeur de cette approche est qu’elle ne peut pas détecter des sous-ensembles de canaux cachés tels que les fréquences des processeurs de canaux de synchronisation et l’espace libre sur les systèmes de fichiers. De plus, il signale des résultats faussement positifs lorsque deux applications non malveillantes tentent de partager des données légitimes. L’approche d’élévation des privilèges est implémentée dans le noyau Android. Shabtai et al. (2010) reconfigurent et déploient un noyau Android qui supporte SELinux pour protéger le système contre les attaques d’élévation de privilèges. SELinux applique le contrôle d’accès de bas niveau sur les processus Linux critiques qui fonctionnent sous des utilisateurs privilégiés. SELinux présente une politique complexe qui rend plus difficile d’agir en tant qu’administrateur sur un appareil mobile. De plus, il manque un mécanisme de coordination entre le noyau Linux et le middleware Android. L’Android (Lange et al. 2011) assure l’intégrité du noyau lorsqu’un téléphone est rooté en encapsulant le système d’exploitation du smartphone dans une machine virtuelle. Ceci fournit un environnement isolé pour l’exécution sécurisée des applications. Puisque L4Android et SELinux fonctionnent au niveau du noyau, ils ne peuvent pas empêcher les attaques d’élévation de privilèges au niveau des applications. DroidAuditor (Heuser et al. 2016) analyse le comportement des applications sur de vrais appareils Android et génère une représentation graphique qui permet aux utilisateurs de développer une compréhension intuitive des applications internes. Il nous permet de détecter les attaques d’élévation des privilèges de la couche applicative, telles que les attaques confused deputy et les attaques de collusion. Ces approches de contrôle d’accès, bien que mettant en œuvre des systèmes de permission et un fort isolement entre les applications, se sont avérées insuffisantes dans la pratique. Elles contrôlent l’accès aux informations sensibles mais n’assurent pas la sécurité de bout en bout car elles ne suivent pas la propagation des données sensibles dans l’application. Les approches fondées sur la falsification d’informations sensibles, l’analyse statique et l’analyse dynamique ont permis de remédier à ces faiblesses en utilisant le suivi des flux d’informations et le développement d’outils pour prévenir les fuites de données.

Aperçu analytique du flux d’informations

151

4.4.2. Prévention des fuites de données privées Les applications tierces peuvent diffuser des informations privées sans l’autorisation des utilisateurs de smartphones. Les recherches de la Duke University, de la Pennsylvania State University et d’Intel Labs montrent que la moitié des 30 applications gratuites populaires du marché Android envoient des informations sensibles aux publicitaires, y compris la localisation GPS de l’utilisateur et son numéro de téléphone (Wilson 2010). De plus, dans une étude présentée à la conférence Black Hat, Daswani a analysé le comportement en temps réel de 10 000 applications Android et a montré que 80 % des applications provoquent la fuite du code IMEI (Kerner 2011). Cole et Waugh (Cole et Waugh 2012) affirment que 50 applications gratuites les plus populaires divulguent des données comme les listes de contacts aux publicitaires. Nous présentons dans les travaux suivants basés sur la falsification d’informations sensibles, l’analyse statique et l’analyse dynamique pour prévenir les fuites de données sensibles. 4.4.2.1. Falsification des informations sensibles Une solution pour résoudre le problème de sécurité des fuites d’applications de données pour smartphone consiste à fournir des informations fausses ou « fictives » aux applications. Ce mécanisme est réalisé en remplaçant les données privées par de fausses informations dans le flux de données. TISSA (Zhou et al. 2011) met en œuvre un nouveau mode de confidentialité pour protéger les données privées des applications Android malveillantes. Ce mode de confidentialité permet à l’utilisateur d’installer des applications non fiables mais de contrôler son accès à différents types d’informations privées. L’outil TISSA comprend trois composantes principales : le fournisseur de contenu des paramètres de confidentialité, le gestionnaire des paramètres de confidentialité et les composantes de protection de la vie privée. L’application envoie une demande d’accès aux données privées à un composant de fournisseur de contenu qui lance une requête au fournisseur de contenu de paramètres de confidentialité pour vérifier les paramètres de confidentialité actuels de l’application. Si l’accès à l’application n’est pas autorisé, le paramètre de confidentialité renvoie un résultat vide, une information anonyme ou un faux résultat. AppFence (Hornyack et al. 2011) limite l’accès des applications Android aux données sensibles. Il améliore l’environnement d’exécution Android pour implémenter deux contrôles de confidentialité : (1) substituer les données sensibles auxquelles l’utilisateur ne veut pas que les applications aient accès par des fausses données et (2) bloquer les communications réseau lors de l’envoi des données sensibles taguées. MockDroid (Beresford et al. 2011) révoque l’accès des applications à des ressources particulières. Il permet à l’utilisateur de fournir de fausses données aux applications. Il réduit les fonctionnalités des applications en fournissant des ressources vides ou indisponibles.

152

Cybervigilance et confiance numérique

L’approche de la falsification d’informations sensibles fournit des informations « fictives » aux applications au lieu de données privées. Cette approche permet d’éviter les fuites d’informations privées par des applications Android non fiables. Cependant, donner de fausses informations privées peut perturber l’exécution des applications. 4.4.2.2. Analyse statique des applications Android L’analyse statique des applications mobiles permet de détecter les fuites de données sensibles et les comportements dangereux. Chin et al. (2011) présentent Com Droid, un outil qui peut être utilisé par les développeurs pour analyser statiquement le code DEX (fichiers Dalvik Executable avant leur installation sur un appareil) des applications tierces sous Android. Ils désassemblent les fichiers DEX des applications et analysent la sortie désassemblée pour détecter des vulnérabilités potentielles des composants et des intentions comme les vulnérabilités de communication interapplications. Une des limites de ComDroid est qu’il ne fait pas de distinction entre les chemins à travers les instructions if et switch. Cela peut conduire à de faux négatifs. SCANDROID (Fuchs et al. 2009) facilite la certification automatisée de la sécurité des applications Android. Il analyse statiquement les flux de données en code Java pour les applications Android. Sur la base de ces flux, SCANDROID vérifie la conformité des accès requis avec les spécifications de sécurité et applique le contrôle d’accès. L’une des limites de cette approche d’analyse est qu’elle ne peut pas être appliquée immédiatement aux applications packagées sur les appareils Android. Enck et al. (2011) conçoivent et implémentent le décompilateur Dalvik « ded », dédié à l’analyse des sources Java d’une application Android Market. L’extraction du décompilateur se fait en trois étapes : reciblage, optimisation et décompilation. Ils identifient les constantes de classe et de méthode et les variables dans la phase de reciblage. Ensuite, ils font l’optimisation du bytecode et décompilent les fichiers de classe reciblés. Leur analyse est basée sur des tests automatisés et des inspections manuelles. Une limitation du décompilateur ded est qu’il nécessite que le code source Java soit disponible pour détecter les vulnérabilités potentielles. SCANDAL (Kim et al. 2012) est un outil automatique qui effectue des analyses statiques pour détecter les fuites de données dans les applications Android. Il convertit le bytecode Dalvik des applications Android en un langage intermédiaire formellement défini. Il utilise une interprétation abstraite pour détecter les flux dangereux. La limitation de SCANDAL est qu’il génère un grand nombre de faux positifs. AppIntent (Yang et al. 2013) fournit la séquence d’événements qui mène à la transmission de données sensibles sous la forme d’une séquence de manipulations de l’interface utilisateur. Il analyse statiquement l’application cible pour identifier les chemins d’exécution possibles menant à la transmission de données sensibles. Ces chemins sont utilisés pour générer toutes les séquences d’événements possibles en considérant le graphe d’appel et le modèle d’exécution Android. Il conçoit une nouvelle technique, l’exécution symbolique

Aperçu analytique du flux d’informations

153

des contraintes d’espace événementiel, pour distinguer la transmission intentionnelle et la transmission non intentionnelle. AppIntent facilite la discrimination selon que la transmission de données sensibles est destinée à l’utilisateur ou non, mais il ne traite pas les transmissions de données qui ne sont pas déclenchées par des séquences de manipulations de l’interface graphique. AndroidLeaks (Gibler et al. 2012) crée un graphe d’appel du code d’une application, puis effectue une analyse statique pour identifier les fuites potentielles des informations personnelles dans les applications Android. Il définit un ensemble de mappages entre les méthodes des API Android et les permissions dont elles ont besoin pour s’exécuter en utilisant des techniques statiques. Un sous-ensemble de mapping est utilisé comme source et puits de données privées pour l’analyse des flux d’informations. LeakMiner (Yang et Yang 2012) utilise l’analyse statique des données taguées pour détecter les fuites d’informations avant que les applications ne soient distribuées aux utilisateurs, afin que les applications malveillantes puissent être retirées du marché avant leur téléchargement. Il transforme les fichiers apk des applications Android en bytecode Java et propage le tag aux données qui dépendent des informations sensibles en se basant sur le graphe d’appel pour identifier les chemins de fuite des données possibles. LeakMiner produit un grand nombre de faux positifs dus à une information de contexte insuffisante. FlowDroid (Arzt et al. 2014) est un outil d’analyse statique des données taguées qui analyse automatiquement le bytecode et les fichiers de configuration des applications Android à la recherche de fuites de données sensibles. Il prend en considération le contexte pour analyser les flux d’informations. Il utilise des techniques basées sur l’apprentissage automatique pour identifier les sources et les puits associés aux informations sensibles dans l’API Android. FlowDroid ne détecte pas l’attaque lorsque l’attaquant obfusque le code et utilise des flux implicites pour masquer les fuites de données. Comnoid (Dhavale et Lokhande 2016) est basé sur FlowDroid et il est capable d’analyser la communication inter-applications. DroidSafe (Gordon et al. 2015) est un outil d’analyse de flux d’informations statiques qui signale les fuites potentielles d’informations sensibles dans les applications Android. Il utilise des analyses des points non sensibles au flux et des flux d’informations pour prendre en compte tous les ordres d’événements d’exécution possibles que les rappels asynchrones peuvent déclencher. DroidSafe analyse à la fois Intent et RPC. Il est efficace pour suivre les flux de données explicites, mais il ne détecte pas les fuites de données sensibles via des canaux auxiliaires ou des flux implicites. Les approches d’analyse statique mises en œuvre dans les smartphones nous permettent de détecter les fuites de données, mais elles ne peuvent pas capturer toutes les configurations d’exécution et les entrées. 4.4.2.3. Analyse dynamique des applications Android De nombreux travaux basés sur l’analyse dynamique sont implémentés dans les smartphones pour détecter et prévenir les fuites de données privées.

154

Cybervigilance et confiance numérique

TaintDroid (Enck et al. 2010) améliore le système Android embarqué sur des smartphones pour contrôler l’utilisation des données confidentielles par des applications tierces. Il surveille le comportement de l’application pour déterminer quand les informations confidentielles quittent le système. Il met en œuvre l’analyse dynamique des données taguées pour suivre les dépendances de l’information. Premièrement, il définit une source sensible. Toutes les données d’entrée sont taguées selon leur source. Ensuite, TaintDroid suit la propagation des données taguées au niveau de l’instruction. La propagation des tags s’effectue en exécutant le code natif sans instrumentation. Pour minimiser l’overhead de communication interprocessus (IPC), il analyse les messages entre les applications et les fichiers. Enfin, des vulnérabilités peuvent être détectées lorsque des données taguées sont utilisées dans un taint sink (interface réseau). Taint Droid adresse différents défis spécifiques aux smartphones comme les ressources limitées. Les tags sont stockés à côté des variables correspondantes sur la pile d’exécution interne, et il définit un tag par tableau pour minimiser l’overhead. TaintDroid est utilisé par MockDroid (Beresford et al. 2011) et TISSA (Zhou et al. 2011) pour évaluer leur efficacité. AppFence est une extension de Taintdroid qui détecte et bloque l’envoi des données privées en dehors du système. AndroTaint (Shankar et al. 2017) est un framework de détection des logiciels malveillants basé sur l’analyse dynamique des données taguées utilisée pour identifier les fuites d’informations dans les systèmes Android en deux phases : la première phase est une phase de formation pour l’extraction de caractéristiques et la seconde phase est une phase d’analyse pour le marquage automatique des données. Les approches d’analyse dynamique définies dans les smartphones tels que TaintDroid, AndroTaint et AppFence suivent le flux d’informations en temps réel et contrôlent la gestion des données privées. Cependant, ils ne propagent pas le tag le long des dépendances de contrôle. Cela peut causer un problème de sous-marquage (undertainting) : certaines valeurs doivent être marquées comme taguées, mais ne le sont pas. Ce problème entraîne l’échec de la détection d’une fuite d’informations sensibles.

Figure 4.3. Attaque utilisant une dépendance de contrôle indirecte

Aperçu analytique du flux d’informations

155

Considérons l’attaque illustrée à la figure 4.3, les variables x et y sont toutes deux initialisées à false. Sur la ligne 4, l’attaquant teste l’entrée de l’utilisateur pour une valeur spécifique. Supposons que l’attaquant a eu de la chance et que le test était positif. Dans ce cas, la ligne 5 est exécutée, en modifiant x à vrai et x n’est pas tagué car TaintDroid ne propage pas le tag le long des dépendances de contrôle. La variable y conserve sa valeur faux, puisque l’assignation à la ligne 7 n’est pas exécutée et y n’est pas tagué. Comme x et y ne sont pas taguées, elles seront envoyées sur le réseau sans être détectées. Comme y n’a pas été modifiée, elle informe l’attaquant de la valeur du contact privé de l’utilisateur. Ainsi, un attaquant peut contourner un système Android en exploitant les flux de contrôle. Une limitation significative de ces approches d’analyse dynamique des données taguées implémentées dans les systèmes Android est qu’elles ne suivent que les flux explicites au niveau du code Java et qu’elles ne traitent pas les bibliothèques natives qui peuvent contenir des données sensibles. Par conséquent, un attaquant peut exploiter ce code natif pour obtenir des informations privées. Notre objectif est d’améliorer l’approche TaintDroid en suivant les flux de contrôle dans le code java et natif des applications Android pour résoudre le problème d’undertainting. Dans ce qui suit, nous étudierons les systèmes existants qui contrôlent l’exécution du code natif. 4.4.3. Approches des bibliothèques natives Fedler et al. (2013) affirment que tous les exploits racine locaux actuels sont exclusivement implémentés sous forme de code natif et peuvent être téléchargés et exécutés dynamiquement par n’importe quelle application. Comme l’absence de mécanismes de contrôle pour l’exécution du code natif constitue une menace majeure pour la sécurité des appareils Android, Fedler et al. proposent des mécanismes pour contrôler l’exécution du code natif. Certains travaux ont été entrepris pour prendre en compte les bibliothèques natives dans les applications Android. DroidRanger (Zhou et al. 2012) enregistre tous les appels aux API du framework Android pour le code Java chargé dynamiquement et leurs arguments pour fournir des informations sémantiques riches sur le comportement d’une application. Pour le code natif chargé dynamiquement, il collecte les appels système effectués par le code natif à l’aide d’un module noyau qui capture la table des appels système dans le noyau (Linux). Pour analyser les applications potentiellement nuisibles pour la plate-forme Android, AASandbox (Blasing et al. 2010) surveille les appels système et les appels des bibliothèques.

156

Cybervigilance et confiance numérique

Figure 4.4. Attaque exploitant le code natif basé sur des dépendances de contrôle

Paranoid (Portokalidis et al. 2010) et Crowdroid (Burguera et al. 2011) interceptent les appels système et traitent les signaux. L’analyseur dynamique présenté dans Spreitzenbarth et al. (2013) trace les codes inclus dans les objets partagés natifs, ceux inclus avec l’application via le NDK et ceux fournis avec Android en interceptant les appels de bibliothèque d’une application contrôlée. CopperDroid (Reina et al. 2013) instrumente l’émulateur Android pour permettre le suivi des appels système et supporter une analyse centrée sur les appels système. DroidScope (Yan et Yin 2012), un moteur d’analyse des logiciels malveillants Android basé sur l’émulation, est utilisé pour analyser les composants Java et natifs des applications Android. Il implémente plusieurs outils d’analyse pour collecter des traces détaillées d’instructions natives et Dalvik, l’activité au niveau de l’API du profil et le suivi des fuites d’informations à travers les composants Java et natifs en utilisant l’analyse des données taguées. L’une des limites du DroidScope est qu’il engendre des overhead élevés. DROIT (Wang et Shieh 2015) est un système de suivi des données taguées basé sur l’émulation. Il suit le flux de données au niveau de l’objet Java et fait de l’instrumentation au niveau des instructions lorsque le code natif sera exécuté. DROIT est conçu pour profiler le comportement du programme. Ainsi, le programme est considéré comme la source de marquage. Au contraire, dans TaintDroid, les données du programme présentent les sources de marquage. Le NDroid (Qian et al. 2014) étend TaintDroid pour suivre le flux explicite dans le code natif. L’inconvénient majeur de toutes les approches qui considèrent les bibliothèques natives est qu’elles ne propagent pas le tag dans les flux de contrôle, ce qui peut causer un problème d’under-tainting. Considérons l’exemple de la figure 4.5 qui présente un problème d’under-tainting en code natif Android. Le programme malveillant écrit en code Java (figure 4.4) permet de récupérer l’identifiant du téléphone et de le transmettre en argument à une fonction native (écrite en C). Dans le code natif présenté dans la figure 4.5, l’attaquant compare chaque caractère des données privées avec les symboles dans la table Ascii (TabAsc). La variable Z contient la valeur des données privées, mais elle n’est pas

Aperçu analytique du flux d’informations

157

taguée par les systèmes d’analyse dynamique existants. TaintDroid marque la valeur de retour d’une fonction JNI si un argument de la fonction est tagué. Dans ce cas, la fonction native ne retourne pas de valeur. NDroid ne propage pas le tag tout au long des flux de contrôle dans le code natif. Ainsi, la variable Z est envoyée par l’interface java native JNI sans qu’aucun avertissement ne soit signalé. Dans cet exemple, le taint sink (interface réseau) est défini dans le code natif. Par conséquent, la variable Z est envoyée à travers la connexion réseau (Send_Data(Z)) en dehors du système. L’approche citée dans Enck et al. (2010) n’implémente pas de taint sink dans le code natif. Cependant, NDroid instrumente les bibliothèques natives pour définir le taint sink. Comme la variable Z envoyée par la connexion réseau n’est pas taguée, la fuite de cette donnée ne peut pas être détectée.

Figure 4.5. Fonction malveillante native

Le taint sink peut être défini dans le code Java. Dans ce cas, un autre programme Java recherche les informations sensibles à partir du code natif, ou la méthode native appelle et transmet les informations sensibles au code Java. Ensuite, les données seront envoyées à partir du code Java. Comme ces données ne sont pas taguées, elles seront envoyées sans avertissement. Nous étudions les approches existantes suivantes qui nous permettent de gérer les flux de contrôle. Ces approches proposent des solutions au problème d’under-tainting. 4.5. Détection des flux de contrôle Les analyses statiques et dynamiques présentent toutes deux des avantages et des inconvénients. L’analyse statique présente des limitations dues à des problèmes

158

Cybervigilance et confiance numérique

d’indécidabilité, mais elle nous permet de suivre toutes les branches d’exécution d’un programme. Dans le cas de l’analyse dynamique, il n’est pas possible de détecter tous les flux d’informations car le marquage dynamique ne se produit que le long de la branche qui est effectivement exécutée. Cela peut causer un problème d’undertainting. Ce problème peut être résolu en utilisant une approche hybride qui combine et bénéficie des avantages des analyses statiques et dynamiques. Nous présentons ci-après les approches techniques et formelles qui nous permettent de détecter les flux de contrôle et de résoudre le problème d’under-tainting. 4.5.1. Approches techniques du flux de contrôle De nombreux ouvrages existent dans la littérature pour suivre les flux d’informations. Dytan (Clause et al. 2007) nous permet d’effectuer un data tainting basé sur les flux explicites et de contrôle. Pour suivre les flux de contrôle, Dytan analyse le code binaire et construit le graphe de flot de contrôle (CFG) pour détecter les dépendances de contrôle. En se basant sur le CFG, Dytan marque les variables dans la structure conditionnelle. Pour suivre les flux de données, Dytan identifie les opérandes source et destination en fonction de l’instruction mnémonique. Ensuite, il combine les tags associés aux opérandes sources et les associe aux opérandes de destination. La principale limite de cette approche est qu’elle génère de nombreux faux positifs. BitBlaze (Song et al. 2008) met en œuvre une approche hybride combinant des techniques d’analyse statique et dynamique des données taguées pour suivre les flux implicites et explicites. DTA++ (Kang et al. 2011), basé sur l’approche BitBlaze, améliore l’analyse dynamique des données taguées pour limiter le problème d’undertainting. L’approche DTA++ se déroule en deux phases : d’abord, une phase hors ligne, qui recherche les branches qui causent un problème d’under-tainting et génère des règles de propagation DTA+++ puis une phase en ligne, qui effectue la propagation des tags en utilisant ces règles pour améliorer l’analyse dynamique et résoudre le problème d’under-tainting. L’approche DTA++ sélectionne plus de branches que Dytan pour réduire l’over-tainting. Cependant, la DTA++ n’est évaluée que sur des applications bénignes, mais les programmes malveillants dans lesquels un adversaire utilise des flux implicites pour contourner l’analyse ne sont pas traités. De plus, DTA++ n’est pas implémenté dans les applications embarquées. Trishul (Nair et al. 2008) est un système de contrôle des flux d’informations. Il est implémenté dans une machine virtuelle Java pour sécuriser l’exécution des applications Java par le suivi des flux de données dans l’environnement. Il ne nécessite pas de modification du noyau du système d’exploitation car il analyse le bytecode d’une application en cours d’exécution. Trishul est basé sur l’approche hybride pour gérer correctement les flux implicites en utilisant le programme compilé plutôt que le code source au moment du

Aperçu analytique du flux d’informations

159

chargement. Trishul identifie correctement les flux implicites d’informations pour détecter les fuites d’informations sensibles. Il résout le problème d’under-tainting en mettant à jour le tag de la condition et en maintenant une liste d’affectations dans un bloc de base de graphe de flot de contrôle pour traiter les branches non exécutées. Les approches susmentionnées nous permettent de gérer les flux de contrôle, mais elles n’ont pas encore été adaptées et implémentées dans les systèmes Android. Gilbert et al. (2011) présentent une vision pour la mise en œuvre d’une approche dynamique permettant de contrôler l’utilisation d’informations sensibles par une application et de vérifier les comportements suspects. Leur solution est basée sur une approche d’exécution mixte qui combine l’exécution symbolique et concrète pour explorer les différents chemins d’une application tierce spécifique. Pour analyser les applications, ils proposent AppInspector, un service de validation de la sécurité qui nous permet de suivre les actions ainsi que les flux explicites et implicites. Mongiov et al. (2015) proposent une nouvelle approche hybride qui combine des analyses statiques et dynamiques des flux de données pour détecter les fuites de données dans les applications Java. Leur approche minimise l’overhead en calculant un ensemble minimal de « points d’application » qui doivent être surveillés et injecte du code de contrôle sur l’application cible. Nous nous sommes inspirés de ces travaux antérieurs et proposons une solution basée sur une approche hybride qui combine des analyses statiques et dynamiques pour détecter les flux de contrôle et résoudre le problème d’under-tainting dans les systèmes Android. Nous présentons ci-après une approche formelle fondée sur un modèle formel de détection des flux de contrôle. 4.5.2. Approches formelles du flux de contrôle La Data Mark Machine (Fenton 1974) est un modèle abstrait proposé par Fenton pour gérer les flux de contrôle. Fenton associe une classe de sécurité à un compteur de programme p et définit une matrice d’interaction pour suivre les données dans le système. L’opérateur de combinaison de classes « ⊕ » spécifie le résultat de classe de toute fonction binaire sur les valeurs des classes d’opérandes. Pour chaque objet y, définit y une classe de sécurité qui est affectée à y. Une relation de flux « → » entre une paire de classes de sécurité A et B signifie que « les informations de la classe A sont autorisées à circuler en classe B ». Lorsqu’une instruction S est conditionnée par la valeur de k variables de condition c1, . … ck, alors p est réglé sur p = c1 ⊕ . . . ⊕

ck pour illustrer le flux d’informations de contrôle. Fenton suit également le flux explicite : si S représente un flux explicite des objets a1, .... an à un objet b, alors le

160

Cybervigilance et confiance numérique

mécanisme d’exécution des instructions vérifie que a1 ⊕ . . . ⊕ an ⊕ p → b . Fenton prouve l’exactitude de son modèle en termes de flux d’informations. Il affirme que son mécanisme assure la sécurité de tous les flux implicites (Fenton 1973). Cependant, la Data Mark Machine ne prend pas en compte le flux implicite lorsque la branche n’est pas exécutée car elle est basée sur un mécanisme d’exécution.

Figure 4.6. Exemple de flux implicite

L’exemple du flux implicite présenté à la figure 4.6 proposé par Fenton (1974) présente un problème d’under-tainting. La première branche n’est pas suivie (a = true), mais elle contient des informations qui sont ensuite divulguées en utilisant le suivant si. Ainsi, à la fin de l’exécution, b atteint la valeur de a, alors que b a. De nombreuses solutions sont proposées pour résoudre le problème d’under-tainting. Fenton (1973) et Gat et Saal (1975) proposent une solution qui restaure la valeur et la classe des objets modifiés pendant l’exécution d’une structure conditionnelle à la valeur et la classe de sécurité qu’elle avait avant d’entrer dans la branche. Toutefois, dans la pratique, le code d’application existant ne modifie pas les structures de contrôle pour tenir compte des fuites de flux d’informations. De plus, l’approche de Gat et Saal est basée sur une architecture matérielle spécialisée pour contrôler le flux d’informations et elle est difficile à mettre en œuvre. Par ailleurs, l’approche de Fenton n’a jamais été mise en œuvre. Aries (Brown et Knight Jr 2001) propose une solution qui interdit l’écriture à un emplacement particulier d’une branche lorsque la classe de sécurité associée à cet emplacement est égale ou moins restrictive que la classe de sécurité de p. Considérant l’exemple montré dans la figure 4.6, le programme ne peut écrire à c car la classe de sécurité de c (Low) est inférieure ou égale à celle de p (Low ⇐ p ). L’approche d’Aries est restreinte parce qu’elle est basée uniquement sur des classes de haute et de basse sécurité et qu’elle empêcherait de nombreuses applications de s’exécuter correctement (Beres et Dalton 2003). Le modèle Bell-LaPadula (Bell et LaPadula 1976) définit la sécurité à plusieurs niveaux. Il associe le niveau de sécurité aux sujets et aux objets pour indiquer leur sensibilité ou leur habilitation. Il considère que la circulation de l’information d’un niveau de sécurité élevée à un niveau de sécurité inférieure est illégale.

Aperçu analytique du flux d’informations

161

Denning (1975) améliore le mécanisme d’exécution utilisé par Fenton avec un mécanisme de temps de compilation pour résoudre le problème d’under-tainting. Denning propose d’insérer des instructions de mise à jour au moment de la compilation, que la branche soit prise ou non. Compte tenu de l’exemple de la figure 4.6, une instruction est ajoutée à la fin du code de bloc if (!a)c = true pour mettre à jour c à p (= a). La solution de Denning reflète exactement le flux d’informations. Cependant, cette solution est basée sur des arguments informels en faveur du bien-fondé du mécanisme du temps de compilation (Denning et Denning 1977). Nous nous inspirons de l’approche Denning, mais nous effectuons la mise à jour de classe requise lorsque les méthodes Java sont invoquées, car nous suivons les applications Java au lieu de les mettre à jour au moment de la compilation. Nous définissons un ensemble de règles de propagation formellement correctes et complètes pour résoudre le problème d’under-tainting. Les travaux précédents présentent des solutions techniques et formelles pour détecter le flux de contrôle et résoudre le problème d’under-tainting. Cependant, ils ne sont pas implémentés dans les systèmes Android. Ainsi, pour sécuriser un processus de fonctionnement des systèmes Android, nous proposons d’empêcher l’exécution du code malveillant en surveillant les transferts à travers les flux de contrôle dans un programme. Ensuite, nous montrons que cette approche est efficace pour détecter les attaques de flux de contrôle et résoudre le problème d’under-tainting. 4.6. Gestion des flux explicites et de contrôle en code Java et en code natif des applications Android Dans cette section, nous spécifions formellement le problème d’under-tainting. Comme solution, nous fournissons un algorithme basé sur un ensemble de règles formellement définies qui décrivent la propagation des tags. Nous prouvons la complétude de ces règles ainsi que la correction et la complétude de l’algorithme. Enfin, nous présentons notre solution technique qui propage le tag le long des dépendances de contrôle en utilisant deux règles de propagation. 4.6.1. Spécification formelle du problème d’under-tainting Nous spécifions formellement le problème d’under-tainting en se basant sur le modèle de flux d’informations de Denning. Il définit un modèle de flux d’informations comme suit (Denning 1976) : F M = < N, P, SC, ⊕, →>

162

Cybervigilance et confiance numérique

où N est un ensemble d’objets de stockage logique (fichiers, variables de programme, etc.), P est un ensemble de processus qui sont exécutés par les agents actifs responsables de tous les flux d’informations et SC est un ensemble de classes de sécurité qui sont affectées aux objets dans N. SC est fini et a une limite inférieure L attachée aux objets en N par défaut. L’opérateur de combinaison de classes « ⊕ » spécifie le résultat de classe de n’importe quelle fonction binaire avec des classes d’opérandes. Une relation de flux « → » entre les paires de classes de sécurité A et B signifie que « les informations de la classe A sont autorisées à circuler dans la classe B ». Un modèle de flux FM est sûr si, et seulement si, l’exécution d’une séquence d’opérations ne peut produire un flux qui viole la relation « → ». Nous nous inspirons du modèle de flux d’informations de Denning pour préciser formellement l’under-tainting. Cependant, nous affectons le tag aux objets au lieu d’affecter des classes de sécurité. Ainsi, la classe combinant l’opérateur « ⊕ » est utilisée dans notre spécification formelle pour combiner les tags des objets. 4.6.1.1. Définition syntaxique des connecteurs {⇒, →, ←, ⊕} Nous utilisons la syntaxe suivante pour spécifier formellement l’under-tainting (A et B sont deux formules logiques et x et y sont deux variables) : – A ⇒ B : si A alors B ; – x → y : flux d’informations de l’objet x à l’objet y ; – x ← y : la valeur de y est affectée à x ; – Taint(x) ⊕ Taint(y) : spécifie le résultat de la combinaison des tags. 4.6.1.2. Définition sémantique des connecteurs {→, ←, ⊕} – Le connecteur → est réflexif : si x est une variable, alors x → x. – Le connecteur → est transitif : x, y et z sont trois variables : si (x → y) ∧ (y → z), alors x → z. – Le connecteur ← est réflexif : si x est une variable, alors x ← x. – Le connecteur ← est transitif : x, y et z sont trois variables : si (x ← y) ∧ (y ← z), alors x ← z. – Les connecteurs → et ← ne sont pas symétriques. – La relation ⊕ est commutative : Taint(x) ⊕ Taint(y) = Taint(y) ⊕ Taint(x). – La relation ⊕ est associative : Taint(x) ⊕(Taint(y) ⊕Taint(z))) = (Taint(x) ⊕Taint(y)) ⊕ Taint(z).

Aperçu analytique du flux d’informations

163

DÉFINITION 4.1. Under-tainting.– Nous avons une situation d’under-tainting quand x dépend d’une condition, la valeur de x est assignée dans la branche conditionnelle et la condition est taguée mais x n’est pas tagué. Formellement, il y a under-tainting lorsqu’il y a une variable x et une condition de formule telle que : IsAssigned(x, y) ∧ Dépendance(x, condition)

∧Tainted(condition) ∧ ¬Tainted(x)

[4.1]

où : – IsAssigned(x, y) associe à x la valeur de y : def

IsAssigned(x, y) ≡ (x ← y) – Dependency(x,condition) définit un flux d’informations de condition à x quand x dépend de la condition : def

Dependance(x,condition) ( ≡ condition → x) 4.6.2. Solution formelle du problème d’under-tainting Nous spécifions un ensemble de règles formellement définies qui décrivent la propagation des tags. Nous prouvons la complétude de ces règles. Ensuite, nous fournissons un algorithme pour résoudre le problème d’under-tainting basé sur ces règles. Puis, nous analysons certaines propriétés importantes de notre algorithme telles que la complétude et la correction. 4.6.2.1. Notations, définitions et théorèmes DÉFINITION 4.2. Graphe direct.– Un graphique direct G = (V,E) se compose d’un ensemble fini V de sommets et d’un ensemble E de paires ordonnées (v,w) de sommets distincts, appelés arêtes. Si (v,w) est une arête, alors w est un successeur de v et v est un prédécesseur de w. DÉFINITION 4.3. Graphe direct complet.– Un graphe direct complet est un graphe direct simple G = (V,E) tel que toutes les paires de sommets distincts en G sont reliées par une seule arête. Par conséquent, pour chaque paire de sommets distincts, (x,y) ou (y,x) (mais pas les deux) est en E. DÉFINITION 4.4. Graphe de flot de contrôle.– Un graphe de flot de contrôle G = (V, E, r) est un graphe direct d (V, E) avec un sommet de sortie et un sommet d’entrée r

164

Cybervigilance et confiance numérique

distingués, de sorte que pour tout sommet v ∈ V il y a un chemin de r à v. Les nœuds de graphe de flot de contrôle représentent les blocs de base, et les arêtes représentent les chemins du flux de contrôle. Le concept de postdominateurs et d’arbre de domination est utilisé pour déterminer les dépendances des blocs dans le graphe de flot de contrôle. DÉFINITION 4.5. Dominateur.– Un sommet v domine un autre sommet w ≠ v dans G si chaque chemin de r à w contient v. DÉFINITION 4.6. Postdominateur.– Un nœud v est postdominé par un nœud w dans G si chaque chemin de v vers le sommet de sortie contient w. THÉORÈME 4.1. – Chaque sommet d’un graphe de flot G = (V,E ,r) sauf r a un dominateur immédiat unique. Les arêtes {(idom(w),w)|w ∈ V - {r}}} forment un arbre direct enraciné à r, appelé arbre de domination de G, de sorte que v domine w si et seulement si v est un ancêtre propre de w dans l’arbre de domination (Lowry et Medlock 1969 ; Aho et Ullman 1972). Le calcul des postdominateurs dans le graphe de flot de contrôle est équivalent au calcul des dominateurs (Aho et al. 1986) dans le graphe de flot de contrôle inverse. Les dominateurs du graphe inverse peuvent être calculés rapidement en utilisant un algorithme rapide (Lengauer et Tarjan 1979) ou un algorithme à temps linéaire (Georgiadis et Tarjan 2004) pour construire l’arbre de domination. En utilisant ces algorithmes, nous pouvons déterminer l’arbre de postdomination d’un graphe. DÉFINITION 4.7. Dépendance de contrôle.– Soit G un graphe de flot de contrôle. Soit X et Y des nœuds dans G. Y est en dépendance de contrôle avec X notée Dependency(X ,Y) si : 1) il existe un chemin direct P de X à Y avec n’importe quel Z dans P (excluant X et Y) postdominé par Y et ; 2) X n’est pas postdominé par Y. Étant donné l’arbre de postdomination, Ferrante et al. (1987) déterminent les dépendances de contrôle en examinant certaines arêtes du graphe de flot de contrôle et en étiquetant des nœuds sur les chemins d’arborescence correspondants. DÉFINITION 4.8. Context_Taint.– Soit G un graphe de flot de contrôle. Soit X et Y des blocs de base dans G. Si Y est en dépendence de contrôle de X qui contient la Condition, alors nous assignons à Y un Context_Taint avec Context_Taint(Y) = Taint(Condition).

Aperçu analytique du flux d’informations

165

Nous utilisons le théorème de complétude pour prouver la complétude des règles de propagation des tags, nous utilisons le théorème de correction pour prouver cette complétude de gauche à droite, et nous utilisons le théorème de compacité et le théorème 4.2 pour prouver de droite à gauche. Ces théorèmes sont donnés ci-dessous (Hedman 2004 pour la preuve) : – théorème de complétude : pour toute phrase G et tout ensemble de phrases Ƒ, Ƒ ⊨ G si et seulement si Ƒ ⊢ G ; – théorème de correction : pour toute formule G et tout ensemble de formules Ƒ, si

Ƒ ⊢ G, alors Ƒ ⊨ G ; – théorème de la compacité : soit un ensemble de formules Ƒ. Ƒest insatisfaisable si et seulement si un sous-ensemble fini d’éléments Ƒ est insatisfaisable. DÉFINITION 4.9. Formule CNF.– Une formule F est sous forme conjonctive normale (CNF) si c’est une conjonction de disjonctions de littéraux. C’est-à-dire : n

m

F   (  Li , j )  i 1 j 1

dans laquelle chaque Li, j est soit une formule atomique, soit une négation de formule atomique. THÉORÈME 4.2. – Soit F et G des formules de logique du premier ordre. Soit H la formule du CNF obtenue en appliquant l’algorithme du CNF (Hedman 2004) à la formule F ∧ ¬G. Soit Res∗(H) l’ensemble des clauses qui peuvent être dérivées de H en utilisant des résolvants. Les éléments suivants sont équivalents : 1) F ⊨ G ; 2) F ⊢ G ; 3) Ø∈ Res∗(H). Voici les règles de propagation des tags. Considérons les axiomes suivants : (x → y) ⇒ (Taint(y) ← Taint(x))

[4.2]

166

Cybervigilance et confiance numérique

( x  y )  ( y  x)

[4.3]

(Taint(x) ← Taint(y)) ∧ (Taint(x) ← Taint(z)) ⇒ (Taint(x) ← Taint(y) ⊕ Taint(z))

[4.4]

THÉORÈME 4.3. Nous considérons que Context_Taint est le tag de la condition. Pour résoudre le problème d’under-tainting, nous utilisons les deux règles qui décrivent la politique de propagation des tags : – règle 1 : si la valeur de x est modifiée et que x dépend de la condition et que la branche est prise, alors nous appliquerons la règle suivante pour marquer x : Is modified ( x)  Dependency( x, condition)  BranchTaken(br, conditionalstatement ) Taint ( x)  Context_Taint  Taint (explicit flowstatement )

où le prédicat BranchTaken(br, conditionalstatement) spécifie que la branche br dans le conditionalstatement est exécutée. Par conséquent, un flux explicite contenant x est exécuté. IsModified (x, explicitflowstatement) associe à x le résultat d’une instruction de flux explicite (instruction d’affectation) : def

Is modified(x)  assigned(x, explicitflowstatement) – règle 2 : si la valeur de y est affectée à x et x dépend de la condition et que la branche br de l’instruction conditionnelle n’est pas prise (x ne dépend que du flux implicite et ne dépend pas du flux explicite), alors nous appliquerons la règle suivante à x : Is assigned ( x, y)  Dependency( x, condition)  BranchTaken(br, conditionalstatement ) Taint ( x) Taint ( x)  Context _ Taint

4.6.2.2. Preuve des règles de propagation des tags Pour prouver la complétude des règles de propagation des tags, nous utilisons les règles de base citées dans le tableau 4.1 pour les dérivations.

Aperçu analytique du flux d’informations

Principe

Conclusion

Nom

G est en Ƒ

Ƒ ⊢G

Hypothèse

Ƒ ⊢ G et Ƒ ⊂ Ƒ ’

Ƒ ’⊢G

Monotonicité

Ƒ ⊢ F, Ƒ ⊢ G

Ƒ ⊢ (F ∧ G)

∧-Introduction

Ƒ ⊢ (F ∧ G)

Ƒ ⊢ (G ∧ F )

∧-Symétrie

167

Tableau 4.1. Règles de base pour les dérivations

Nous commençons par prouver la complétude de la première règle. Nous supposons que Ƒ ={IsModified(x,explicitflowstatement), Dependency(x, condition), BranchTaken(br,conditionalstatement)} et G = Taint(x) ← Context_ Taint ⊕ Taint(explicitflowstatement). Nous prouvons la correction, de gauche à droite, par induction. Si Ƒ ⊢ G, alors il y a une preuve formelle concluante avec Ƒ ⊢ G (tableau 4.2). Soit M un modèle arbitraire de Ƒ, nous allons démontrer que M ⊨ G. G est déduit par modus ponens de Gj, Gj → G, alors par induction, M ⊨ Gj et M ⊨ Gj → G ce qui donne M ⊨ G. À l’inverse, supposons que Ƒ ⊨ G, alors Ƒ ∪ ¬G est insatisfaisable. Par compacité, un sous-ensemble fini de Ƒ ∪ ¬G est insatisfaisable. Ainsi, il existe un Ƒ0 ⊂ Ƒ tel que Ƒ0 ∪ ¬G est insatisfaisable et, de manière équivalente, Ƒ0 ⊨ G. Puisque Ƒ0 est fini, on peut appliquer le théorème 4.2 pour obtenir Ƒ0 ⊢ G. Enfin, Ƒ ⊢ G par Monotonicité. „ Nous allons maintenant prouver la complétude de la deuxième règle. Nous supposons à nouveau que Ƒ = {IsAssigned(x,y), Dependency(x,condition), ¬BranchTaken(br,conditionalstatement)} et G = Taint(x) ← Taint(x) ⊕ Context_ Taint. Comme pour la première règle, nous prouvons la correction par induction. Si Ƒ ⊢ G, alors il y a une preuve formelle concluant avec Ƒ ⊢ G (tableau 4.3). Soit M un modèle arbitraire de Ƒ, nous allons démontrer que M ⊨ G. G est déduit par modus ponens de Gj, Gj → G, alors par induction, M ⊨ Gj et M ⊨ Gj → G ce qui donne M ⊨ G.

168

Cybervigilance et confiance numérique

Déclaration

Justification

1. (condition → x) ⊢ (Taint(x) ← Taint(condition))

Axiome (2)

2. (condition → x) ⊢ (Taint(x) ← Context_Taint)

Taint(condition) = Context_Taint

3. Ƒ ⊢ (Taint(x) ← ContextTaint)

Monotonicité appliquée à 2

4. (x ← explicit flowstatement) ⊢ (explicit flowstatement → x) 5. (x ← explicit flowstatement) ⊢ (Taint(x) ← Taint(explicit flowstatement)) 6. Ƒ ⊢ (Taint(x) ← Taint(explicit flowstatement)) 7. Ƒ ⊢ ((Taint(x) ← Context_Taint)∧ (Taint(x) ← Taint(explicit flowstatement)))

Axiome (3)

Axiome (2) Monotonicité appliquée à 5 ∧‐Introduction s’applique à 3 et 6 Modus ponens

8. Ƒ ⊢ G

Tableau 4.2. Preuve formelle de la première règle

Déclaration

Justification

1. (condition → x) ⊢ (Taint(x) ← Taint(condition))

Axiome (2)

2. (condition → x) ⊢ (Taint(x) ← Context_Taint)

Taint(condition) = Context_Taint

3. Ƒ ⊢ (Taint(x) ← Context_Taint)

Monotonicité appliquée à 2

4. x ⊢ (x ← x)

La relation ← est réflexive

5. Ƒ ⊢ (x ← x)

Monotonicité appliquée à 3

6. (x ← x) ⊢ (Taint(x) ← Taint(x))

Axiome (2)

7. Ƒ ⊢ (Taint(x) ← Taint(x))

Modus ponens appliqué à 5 et 6

8. Ƒ ⊢ ((Taint(x) ← Context_Taint)∧ (Taint(x) ← Taint(x))) 9. Ƒ ⊢ ((Taint(x) ← Taint(x))∧ (Taint(x) ← Context_Taint)) 10. Ƒ ⊢ G

∧‐Introduction appliquée à 3 et 7 ∧‐Symétrie appliquée à 8 Modus ponens

Tableau 4.3. Preuve formelle de la deuxième règle

Aperçu analytique du flux d’informations

169

À l’inverse, supposons que Ƒ ⊨ G. Alors Ƒ ∪ ¬G est insatisfaisable. Par compacité, un sous-ensemble fini de Ƒ ∪ ¬G est insatisfaisable. Ainsi, il existe un Ƒ0 ⊂ Ƒ tel que Ƒ0 ∪ ¬G est insatisfaisable et, de manière équivalente, Ƒ0 ⊨ G. Puisque Ƒ0 est fini, on peut appliquer le théorème 4.2 pour obtenir Ƒ0 ⊢ G. Enfin, Ƒ ⊢ G par monotonicité.

4.6.2.3. L’algorithme L’algorithme de marquage que nous proposons, Taint_Algorithm, nous permet de résoudre le problème d’under-tainting. Il prend en entrée un graphe de flot de contrôle d’un programme binaire. Dans ce graphe, les nœuds représentent un ensemble d’instructions correspondant à des blocs de base. Tout d’abord, il détermine la dépendance de contrôle des différents blocs du graphe à l’aide de Dependency_Algorithm (Ferrante et al. 1987). Ensuite, nous analysons la Dependency_List générée par Dependency_Algorithm et nous définissons le context taint des blocs pour inclure le tag de la condition qui dépend de l’exécution de la branche conditionnelle. Enfin, en utilisant le contexte taint et les deux règles de propagation, nous marquerons toutes les variables auxquelles une valeur est assignée dans la branche conditionnelle.

Algorithme 4.1. Taint_Algorithm (Control flow graph G)

4.6.2.4. Preuve de la correction de l’algorithme Nous voulons prouver la correction de l’algorithme de Taint_Algorithm. Supposons que le graphe de flot de contrôle est correct (Amighi et al. 2012). La preuve se compose de trois étapes : d’abord prouver que Dependency_Algorithm est correct, ensuite prouver que Set_Context_Taint est correct et enfin prouver que Taint_Assigned_Variable est correct. Chaque étape repose sur le résultat de l’étape précédente.

4.6.2.5. Preuve de correction de Dependency_Algorithm L’algorithme Dependency_Algorithm est défini par Ferrante et al. (1987) pour déterminer la dépendance des blocs dans le graphe. Cet algorithme prend comme

170

Cybervigilance et confiance numérique

entrée l’arbre de postdomination pour un graphe de flot de contrôle augmenté (ACFG). Ferrante et al. ajoutent au graphe de flot de contrôle un nœud prédicat spécial ENTRY, qui a une arête marqué « T » allant au nœud START et une autre arête marqué « F » allant au nœud STOP. ENTRY correspond à la condition externe qui déclenche l’exécution du programme. L’arbre de postdomination de l’ACFG peut être créé en utilisant les algorithmes définis dans Georgiadis et Tarjan (2004) et Lengauer et Tarjan (1979). Ces algorithmes se sont prouvés corrects.

4.6.2.6. Étapes de base dans Dependency_Algorithm Étant donné l’arbre de postdomination, Ferrante et al. (1987) déterminent les dépendances de contrôle comme suit : – trouver S, un ensemble de toutes les arêtes (A,B) de l’ACFG de sorte que B ne soit pas un ancêtre de A dans l’arbre de postdomination (c’est-à-dire que B ne postdomine pas A) ; – pour chaque arête (A,B) dans S, trouvez L, le plut petit ancêtre commun de A et B dans l’arbre de postdomination. AFFIRMATION. – Soit L est A ou L est le parent de A dans l’arbre de postdomination. Ferrante et al. examinent ces deux cas pour L et montrent qu’une méthode de marquage de l’arbre de postdomination avec les dépendances de contrôle appropriées convient aux deux cas : – cas 1 : L = parent de A. Tous les nœuds de l’arbre de postdomination sur le chemin de L à B, y compris B mais pas L, doivent être en dépendance de contrôle de A; – cas 2 : L = A. Tous les nœuds de l’arbre de postdomination sur le chemin de A à B, y compris A et B, doivent être en dépendance de contrôle de A. Étant donné (A,B) dans S et son L correspondant, l’algorithme défini par Ferrante et al. parcourt l’arbre de postdomination en arrière de B jusqu’à atteindre L et marque tous les nœuds visités ; marquer L seulement si L = A. Les instructions représentant tous les nœuds marqués sont en dépendance de contrôle de A avec l’étiquette de l’arête (A,B). Ils prouvent que la correction de la construction découle directement de la définition de la dépendance de contrôle (section 4.6.2). Si l’on se réfère à cette définition, pour tout nœud M sur le chemin de l’arbre de postdomination de (mais non compris) L à B, (1) il y a un chemin de A à M dans le

Aperçu analytique du flux d’informations

171

graphe de flot de contrôle qui se compose de nœuds postdominés par M, et (2) A n’est pas postdominé par M. La condition (1) est vraie parce que l’arête (A, B) nous donne un chemin vers B, et B est postdominé par M. La condition (2) est vraie parce que A est soit L, auquel cas il postdomine M, soit A est un fils de L non sur le chemin de L à B. Nous pouvons donc conclure que Dependency_Algorithm est correct.

4.6.2.7. Preuve de correction de Set_Context_Taint Nous incluons le tag de la condition dans le taint contexte des blocs dépendants. Comme le tag de la condition est valide, l’opération d’inclusion est également valide. Nous pouvons conclure que Set_Context_Taint est correct.

4.6.2.8. Preuve de correction de Taint_Assigned_Variable Nous utilisons les deux règles de propagation pour marquer les variables auxquelles une valeur est assignée. Nous avons prouvé la complétude des deux règles de propagation de la section 4.6.2 ; nous pouvons donc conclure que Taint_Assigned_ Variable est complète. Par conséquent, nous pouvons conclure à la complétude de Taint_Algorithm.

4.6.2.9. Preuve de la complétude de l’algorithme Supposons que le graphe de flot de contrôle est complet (définition 4.3). Pour prouver la complétude de Taint_Algorithm, nous prouverons la complétude de Dependency_Algorithm et de la Taint_Assigned_Variable. Dependency_Algorithm prend comme entrée l’arbre de postdomination du graphe de flot de contrôle. L’arbre de postdomination peut être construit en utilisant l’algorithme complet défini dans Georgiadis et Tarjan (2004). Dependency_Algorithm est basé sur l’ensemble des plus petits ancêtres communs (L) de A et B dans l’arbre de postdomination pour chaque arête (A, B) dans S. Selon la valeur de L, Ferrante et al. (1987) définissent deux cas pour déterminer la dépendance du contrôle. Pour prouver la complétude de Dependency_Algorithm, nous montrons que Ferrante et al. prouvent qu’il n’existe pas d’autre valeur de L (A comme parent ou A lui-même) à considérer. PREUVE. Supposons que X est le parent de A dans l’arbre de postdomination. Par conséquent, X n’est pas B parce que B n’est pas un ancêtre de A dans l’arbre de postdomination (par construction de S). Ferrante et al. effectuent une preuve de raisonnement par l’absurde pour démontrer que X postdomine B. Si ce n’est pas le cas, il y aurait un chemin de B à STOP qui ne contient pas X. Cependant, en ajoutant l’arête (A,B) à ce chemin, un chemin de A à STOP ne passe pas par X (puisque, par construction, X n’est pas B). Ceci contredit le fait que X postdomine

172

Cybervigilance et confiance numérique

A. Ainsi, X postdomine B et il doit être un ancêtre de B dans l’arbre de postdomination. Si X, postdominateur immédiat de A, post dominate B, alors le plus petit ancêtre commun de A et B dans l’arbre de postdomination doit être X ou A lui-même.„ Comme il n’existe que deux valeurs de L, il n’existe pas d’autre cas pour calculer la dépendance de contrôle. Le cas 2 traite la dépendance de boucle, et toutes les autres dépendances sont déterminées selon le cas 1. Ainsi, Dependency_Algorithm est complet. Nous avons prouvé la complétude des deux règles de propagation dans la section 4.6.2 ; nous pouvons donc conclure que Taint_Assigned_Variable est complet. Par conséquent, nous pouvons conclure à la complétude de l’algorithme de marquage.

4.6.2.10. Complexité temporelle de l’algorithme Dependency_Algorithm fonctionne avec une complexité temporelle de O(N2) au maximum, où N est le nombre de nœuds dans le graphe de flot de contrôle. Johnson et Pingali (1993) ont proposé un algorithme de temps linéaire pour calculer les dépendances de contrôle, mais aucune preuve de correction de cet algorithme n’a été donnée. Pour chaque (X,Y) examiné dans Dependency_List, la modification de taint contexte et le marquage des variables peuvent être effectués en temps constant O(N). Ainsi, Taint_Algorithm nécessite un temps linéaire utilisant l’algorithme défini dans Johnson et Pingali (1993) et au maximum O(N2) utilisant l’algorithme de Ferrante et al.

4.6.3. Conception du système Notre approche nous permet de suivre les flux d’informations (flux explicites et de contrôle) dans le code Java et natives des applications Android pour détecter les fuites de données sensibles. Elle améliore le système TaintDroid basé sur l’analyse dynamique pour contrôler la manipulation des données privées par des applications Android tierces. Tout d’abord, nous attribuons un tag aux données sensibles. Ensuite, nous suivons la propagation des données taguées dans les composants Java. Nous émettons des rapports d’avertissement lorsque les données taguées sont divulguées par des applications malveillantes. Comme TaintDroid ne peut pas détecter les flux de contrôle, nous combinons les analyses statiques et dynamiques des données taguées pour résoudre le problème d’under-tainting. L’analyse statique est utilisée pour détecter les dépendances de contrôle et pour avoir une vue d’ensemble de toutes les branches conditionnelles du programme.

Aperçu analytique du flux d’informations

173

Nous utilisons l’information fournie par l’analyse statique pour propager le tag le long de toutes les dépendances de contrôle dans la phase d’analyse dynamique. Les composants colorés en gris (figure 4.7) présentent le module Java Taint Instruction Tracer implémenté dans la machine virtuelle Dalvik pour le suivi des flux d’informations au niveau Java. Pour assurer la bonne propagation du code natif, nous implémentons le module Native Taint Instruction Tracer (figure 4.7) qui instrumente les instructions ARM/ Thumb. De plus, nous utilisons l’analyse statique pour énumérer les flux d’informations (flux de contrôle) pour toutes les méthodes JNI.

Figure 4.7. Architecture modifiée pour gérer le flux de contrôle en code natif

De plus, lorsqu’une fonction native est invoquée dans TaintDroid, le tag correspondant n’est pas stocké dans la pile d’exécution native. Il ne gère donc pas correctement les tags lorsque le contexte (Java et natif) change. Par conséquent, nous définissons le module Fonctions de commutation de contexte (figure 4.7). Ce module instrumente les fonctions liées à JNI, par lesquelles l’information circule entre le contexte Java et le contexte natif pour maintenir les tags entre les deux contextes. De plus, nous implémentons le module Native Taint sink (figure 4.7) qui intercepte un appel système sélectionné. Enfin, nous implémentons le module du noyau

174

Cybervigilance et confiance numérique

d’information qui permet d’obtenir des informations du noyau Android Linux sur les processus et la mémoire. Nous détaillons ces modules dans la section suivante.

4.6.4. Gestion des flux explicites et de contrôle dans le code Java des applications Android Notre module Java Taint Instruction Tracer a deux composants principaux : le composant StaticAnalysis et le composant DynamicAnalysis (figure 4.8). Nous implémentons notre approche proposée dans le système d’exploitation TaintDroid. Nous ajoutons un composant d’analyse statique dans le vérificateur de machine virtuelle Dalvik qui analyse statiquement les instructions du code Dex d’une application tierce au moment du chargement. De plus, nous modifions l’interpréteur de machine virtuelle Dalvik pour intégrer le composant DynamicAnalysis. Nous implémentons les deux règles de propagation des tags en utilisant des méthodes natives.

Figure 4.8. Notre architecture d’approche

4.6.4.1. Composant d’analyse statique La vérification statique est effectuée dans le fichier DexVerify.c. Dans ce fichier, il y a trois niveaux de vérification : niveau classe, niveau méthode et niveau instruction. Afin d’ajouter le composant d’analyse statique, DexVerify.c est modifié en ajoutant trois fonctions : contextAnalysisBeginAnalyze, contextAnalysisControlFlowInstruction et contextAnalysisEndAnalyze dans la fonction verifyInstructions. Dans la fonction contextAnalysisBeginAnalyze, nous initialisons des variables globales pour l’analyse de la méthode. Ensuite, nous vérifions les instructions de la méthode. Lorsque des instructions de flux de contrôle (if, switch, goto, catch, etc.) sont détectées, la fonction contextAnalysisControlFlowInstruction est appelée pour signaler une instruction de saut. Cette fonction prend comme arguments d’entrée le compteur

Aperçu analytique du flux d’informations

175

de programme pc, pc_target, la longueur et le type de bloc. Le pc_target présente la cible de saut s’il s’agit d’une instruction de saut ou le nombre de cas s’il s’agit d’une instruction de commutation (switch). Dans cette fonction, nous créons un bloc de base, ou plusieurs si des branches forward ont été définies à la fin de la liste des blocs de base. Ensuite, nous spécifions la cible des blocs de base. De plus, nous créons un BitmapBits pour le suivi des dépendances conditionnelles. Lorsque nous réalisons l’analyse d’une méthode, nous appelons la fonction contextAnalysisisEndAnalyze pour créer le graphe de flot de contrôle (CFG). Un CFG est composé de blocs de base et des arêtes. Nous ajoutons le dernier bloc de base dans la liste des blocs de base. Nous appelons la fonction dumpGraph qui utilise cette liste pour déterminer les blocs du graphe. Les blocs de base représentent les nœuds du graphe. Les arêtes dirigées représentent les sauts dans le flux de contrôle. Les arêtes du CFG sont définies à l’aide de la structure BitmapBits. BitmapBits est composé de bits. La modification de tous les bits indique que les branches dans la structure conditionnelle sont fusionnées et que le bloc de base n’est pas contrôlé par la condition. Lorsqu’un bit est modifié, le bloc de base dépend de la condition. Le bloc de base représente l’instruction conditionnelle lorsqu’aucun bit n’est modifié. Nous stockons le graphe de flot de contrôle au format graphviz (Research 2016) dans le répertoire de données (data directory) du smartphone.

4.6.4.2. Composant d’analyse dynamique L’analyse dynamique est effectuée au moment de l’exécution en instrumentant l’interpréteur de machine virtuelle Dalvik. Le composant DynamicAnalysis utilise les informations fournies par le composant StaticAnalysis telles que BitmapBits. BitmapBits nous permet de détecter les dépendances entre la condition et les variables dans les blocs de base du graphe. Nous assignons un context_taint à chaque bloc de base, qui inclut le tag de la condition dont dépend le bloc. En faisant référence à BitmapBits, nous définissons le context_taint de chaque bloc de base. Nous com-mençons par les branches qui ne sont pas prises. Le composant StaticAnalysis fournit le type et le nombre d’instructions dans ces branches (en bloc de base). Ensuite, nous forçons le processeur à marquer les variables auxquelles une valeur est assignée dans ces instructions. Pour marquer ces variables, nous utilisons le context_taint du bloc de base contenant ces variables et nous appliquons la deuxième règle définie à la section 4.6.2. Nous comparons les arguments dans la condition en utilisant l’instruction suivante : res_cmp=((s4)GET_REGISTER(vsrc1)_cmp(s4)GET_REGISTER(vsrc2)). Sur la base du résultat de la comparaison, nous vérifions si la branche est prise ou non. Nous combinons les tags des différentes variables de la condition comme suit : SET_ REGISTER_TAINT (vdst, (GET_REGISTER_TAINT (vsrc1)|GET_REGISTER_TAINT

176

Cybervigilance et confiance numérique

(vsrc2)) pour obtenir Context_Taint. Si res_cmp n’est pas nul, alors la branche n’est pas prise. Ainsi, nous ajustons le compteur ordinal pour pointer vers la première instruction de la branche en utilisant la fonction ADJUST_PC(2). Sinon, c’est la deuxième branche (sinon) qui n’est pas prise ; ainsi, nous ajustons le compteur ordinal pour pointer vers la première instruction dans cette branche en utilisant la fonction ADJUST_PC(br), où br représente le pointeur de branche. Nous instrumentons différentes instructions dans l’interpréteur pour traiter les instructions conditionnelles. Pour chaque instruction, nous vérifions s’il s’agit d’une instruction conditionnelle ou non. Ensuite, nous testons si la condition est taguée (Context_Taint n’est pas nul). Dans ce cas, nous marquerons la variable à laquelle nous associons une valeur (registre de destination) comme suit : SET_REGISTER_TAINT (vdst, (GET_ REGISTER_TAINT (vsrc1)| GET_REGISTER_TAINT (vsrc2)|taintcond)). Si la branche conditionnelle contient plusieurs instructions, alors nous vérifions à chaque fois que (pc_start < pc) et (pc < pc_end) pour traiter toutes les instructions (nous incrémentons le compteur ordinal lorsque nous exécutons une instruction). Dans le cas des boucles for et while, nous procédons de la même manière, mais nous testons si la condition est toujours vraie ou non à chaque itération. Nous suivons un traitement spécial aux instructions switch. Nous considérons tous les cas et toutes les instructions qui sont définies dans les instructions switch. Notez que nous ne faisons marquer les variables et ne modifions pas leurs valeurs. Une fois que nous traitons toutes les branches non prises, nous restaurons le compteur ordinal pour traiter les branches prises. Nous assignons des tags aux variables modifiées dans cette branche en utilisant la première règle présentée dans la section 4.6.2. Nous modifions les méthodes natives de TaintDroid pour implémenter les deux règles qui propagent le tag dans le flux de contrôle.

4.6.4.3. Traitement des exceptions TaintDroid ne propage pas le tag dans les exceptions utilisées dans le flux de contrôle. Ainsi, un attaquant peut réussir à divulguer des informations sensibles en lançant des exceptions pour contrôler le flux. Pour cette raison, nous traitons les exceptions afin d’éviter les fuites d’informations. Le bloc catch dépend du type d’objet d’exception soulevé dans l’instruction throw. Si le type d’exception lancée est répertorié dans un bloc catch, l’exception est transmise au bloc catch. Par conséquent, une arête est ajoutée dans le CFG de l’instruction throw au bloc catch pour indiquer que l’instruction throw va transférer un flux de contrôle au bloc catch approprié. Si une exception se produit, alors le contexte taint actuel et le tag de l’exception sont

Aperçu analytique du flux d’informations

177

stockés. Les variables assignées dans l’un des blocs catch seront taguées en fonction du tag de l’exception. Chaque bloc catch a une entrée dans le contexte taint à cet effet. 4.6.5. Gestion des flux explicites et de contrôle dans le code natif des applications Android Le système Android fonctionne sur un émulateur QEMU (Wiki 2015), qui fournit des informations sur toutes les instructions ARM/Thumb Android générées (figure 4.7). Ainsi, nous avons apporté un certain nombre de modifications à QEMU pour gérer le code natif des applications Android. Nous définissons quatre modules : (1) le module Native Taint Instruction Tracer qui traite les flux explicites et les contrôle au niveau natif ; (2) le module Context Switching Functions ; (3) le module Native Taint sink et (4) le module Information Kernel. 4.6.5.1. Traceur d’instructions natives des tags Le module Native Taint Instruction Tracer est composé (1) d’une composante de flux explicite qui suit les flux directs et (2) d’une composante de contrôle qui suit les flux indirects au niveau natif. Nous instrumentons les instructions ARM/Thumb des bibliothèques natives invoquées par les applications Android pour propager le tag dans un flux explicite. Nous traitons des opérations unitaires, binaires et de mouvement (move instruction). Pour ces opérations, nous ajoutons des instructions de propagation des tags qui attribuent au registre de destination (Rd) la combinaison de tous les tags des registres sources (Rn,Rm). Nous propageons les tags dans les flux explicites en se basant sur les règles de flux de données présentées dans le tableau 4.4. #imm représente le nombre immédiat avec une valeur de tag nulle. t(M[addr]) est le tag de la mémoire à l’adresse addr qui est calculée en utilisant Rn et #imm (Cal(Rn, #imm)). LDM et STM représentent respectivement les instructions de chargement et de stockage. L’opérateur « ⊕ » est utilisé pour combiner les tags d’objets. L’opérateur « ⊗ » indique une opération binaire entre deux registres. Les figures 4.9 et 4.10 présentent le code d’instrumentation pour gérer le flux explicite, respectivement, des opérations de mouvement et des opérations binaires. Il est plus difficile de gérer les flux de contrôle car il est nécessaire de détecter toutes les branches conditionnelles. Ainsi, pour suivre le flux de contrôle au niveau natif, nous utilisons une analyse statique qui vérifie les instructions des méthodes natives au moment du chargement. Cette analyse est basée sur les graphes de flot de contrôle (Aho et al. 1986 ; Allen 1970), qui sont analysés pour déterminer les branches dans la structure conditionnelle.

178

Cybervigilance et confiance numérique

Tableau 4.4. Logique explicite de propagation du flux

Le graphe de flot de contrôle est composé de nœuds qui représentent les blocs de base et des arêtes dirigées qui représentent les sauts dans le flux de contrôle. Un bloc de base est affecté à chaque branche du flux de contrôle. Nous détectons le flux des dépendances à la condition des blocs dans le graphe en utilisant le BitmapBits, qui est un tableau de bits. La modification de tous les bits indique que les branches sont fusionnées et que le bloc de base ne dépend pas de la condition. Lorsqu’un bit est modifié, le bloc de base dépend de la condition. Le bloc de base représente l’instruction conditionnelle lorsqu’aucun bit n’est modifié.

Figure 4.9. Instrumenter l’instruction I_MOV pour propager les tags dans les flux de contrôle

De plus, nous détectons l’affectation de variables dans un bloc de base du graphe de flot de contrôle. Lorsque nous exécutons les méthodes natives, nous marquons ces variables si la condition est taguée. Pour ce faire, nous utilisons l’analyse dynamique et nous instrumentons les instructions conditionnelles des bibliothèques natives tierces (figures 4.9 et 4.10 pour les instructions de mouvement et binaires, respectivement,

Aperçu analytique du flux d’informations

179

dans une branche conditionnelle). Cette analyse utilise les informations fournies par l’analyse statique, telles que BitmapBits, pour détecter les dépendances à la condition des blocs dans le graphe et l’affectation des variables. Ensuite, nous définissons un context taint qui représente le tag de condition. Nous marquons les variables modifiées qui existent dans l’instruction conditionnelle selon les règles de propagation des tags définies et prouvées dans la section précédente. Si la branche est prise, alors Taint(x) = ContextTaint ⊕ Taint(explicitflowstatement).

Figure 4.10. Instrumentation T_THUMB_3REG instruction pour propager les tags dans les flux de contrôle

4.6.5.2. Fonctions de commutation de contexte Lorsque le contexte passe de Java à natif, nous stockons les tags dans la pile d’exécution native pour suivre le flux d’informations au niveau natif. Le module « Fonctions de commutation de contexte » instrumente les fonctions liées au JNI qui assurent la commutation entre les deux contextes. Ces fonctions permettent au code Java d’invoquer du code natif. Nous interceptons l’appel JNI (dvmCallJNIMethod) pour détecter les méthodes natives invoquées. Ensuite, nous assignons à chaque méthode native invoquée une structure SourcePolicy où sont stockés les tags des arguments de cette méthode. Enfin, nous ajoutons des tags aux registres et mémoires de contexte natifs correspondants. De plus, ces fonctions permettent au code natif d’appeler des méthodes Java via la fonction « dvmCallMethod ». Nous sauvegardons les tags dans les registres shadow et la mémoire au niveau natif et les utilisons pour définir les tags dans la pile de la machine virtuelle Dalvik lorsque les codes natifs invoquent des codes Java en utilisant la méthode « dvmInterpret ». De plus, nous maintenons le tag d’un nouvel objet Java qui peut être créé dans les codes natifs grâce aux fonctions JNI. Nous instrumentons aussi des fonctions qui permettent au code natif d’accéder aux champs des objets (objects’ fields) Java afin d’assigner un tag à ces champs d’objets. Enfin, nous

180

Cybervigilance et confiance numérique

marquons les exceptions lancées par le code natif pour communiquer avec le code Java en instrumentant des fonctions telles que « ThrowNew », « initException », « dvmCall Method » et « dvmInterpret ».

4.6.5.3. Information Kernel Le module Information Kernel fournit des informations sur les processus et les mémoires maps du noyau Android Linux. Nous utilisons la technique d’introspection de la machine virtuelle décrite dans Droidscope pour reconstruire la vue au niveau de l’OS. L’émulateur QEMU désassemble et traduit un bloc d’instructions de base des invités (guest instruction) en une représentation intermédiaire appelée TCG (Tiny Code Generator). Ensuite, il compile le bloc de code TCG en un bloc d’instructions hôte et le stocke dans un cache de code. Pour extraire les informations au niveau du système d’exploitation (processus en cours d’exécution et mémoire maps), nous instrumentons les blocs de code traduits et ajoutons des instructions TCG lors de la phase de traduction du code. The Weather Channel; Cestos; Solitaire; Babble; Manga Browser; Box2D∗; Libgdx∗; Knocking; Coupons; QQPhoneBook∗; Fruit Ninja∗; Bump; Traffic Jam; Find It∗; Hearts; Blackjack; Alchemy; Horoscope; Bubble Burst Free; Wisdom Quotes Lite; Paper Toss∗; ePhone∗; Classic Simon Free; Astrid; Angry Birds∗; Subway Surfer∗; Layar; Cocos2D∗; Unity∗; Trapster; ProBasketBall; Grindr∗; HeyWire∗; Wertago; Dastelefonbuch∗; RingTones; Yellow Pages; Contact Analyzer; Hike∗; TextPlus∗ Figure 4.11. Applications analysées par des tiers

4.6.5.4. Native Taint sink Les données sensibles peuvent être divulguées par le code natif. Il est donc nécessaire de mettre en place un taint sink au niveau natif. Le module Native Taint sink permet d’intercepter un appel système sélectionné pour détecter la fuite d’informations privées. Pour faire des appels système, nous utilisons l’instruction service zero svc#0. Ainsi, nous instrumentons cette instruction pour obtenir des informations sur les appels système. Nous interceptons les fichiers ouverts (fopen), fermés (fclose), lus (fread), écrits (fwrite, fput c, fputs) et les appels système de connexions (send, sendto) pour implémenter les puits natifs.

4.6.6. Évaluation Dans cette section, nous évaluons l’efficacité et les performances de notre approche. Tout d’abord, nous analysons les applications Android les plus populaires à l’aide de

Aperçu analytique du flux d’informations

181

notre système. Ensuite, nous évaluons notre approche à l’aide de CF-Bench. Nous utilisons un ordinateur portable Dell (Latitude E6420) avec un noyau i5 @ 2,6 GHz et 4 Go de RAM fonctionnant sous Debian 7. Des expériences ont été réalisées sur un émulateur Android version 4.1 fonctionnant sur l’ordinateur portable.

4.6.6.1. Efficacité Nous téléchargeons et analysons 40 applications Android gratuites et fréquemment utilisées sur le Google Play Store (figure 4.11). Ces applications accèdent et traitent des données privées telles que la localisation, les contacts, l’état du téléphone, les photos et les SMS. Comme le montre la figure 4.11, 16 applications (marquées d’un *) invoquent des bibliothèques natives. Nous utilisons l’outil dex2jar (Google 2015) pour traduire les fichiers dex de différentes applications en fichiers jar. Ensuite, nous utilisons jd-gui (Java 2015) pour obtenir le code source Java qui sera analysé. Pour le code natif, nous désassemblons le code objet des bibliothèques et nous obtenons les mnémoniques de l’assembleur pour les instructions machine en exécutant objdump (partie de GNU Binutils ; sourceware 2015). Nous avons constaté que 23 applications Android (tableau 4.5) fuitent les données privées par le biais des flux d’informations : – 6 applications utilisent un flux explicite dans le contexte Java et provoquent la fuite d’informations sensibles telles que la localisation, des informations sur l’état du téléphone, le contact et les photos ; Java context Application Wisdom Quotes Lite

Explicit flow

Control flow

Native context Explicit flow

Control flow

x

Type of leaked data L, P

The Weather Channel

x

L

Knocking

x

L, Ca, P

Coupons

x

L, Ca, P x

QQPhoneBook Fruit Ninja Find It

x

Horoscope

x

Paper Toss

x

Co, SMS x

Co

x

L, P L, P

x

L, P

182

Cybervigilance et confiance numérique

Java context Application

Explicit flow

Control flow

Control flow

x

ePhone Astrid

Native context Explicit flow

Type of leaked data Co

x

L, P x

Angry Birds

x

Subway Surfer

L L

Layar

x

L, Ca, P

Trapster

x

L, Ca, P x

Grindr

x

HeyWire Wertago

x

Dastelefonbuch

x

RingTones Yellow Pages

L, SMS L, SMS L, Co, P

x

x

L, Co, P L, Co, P

x

L, Co, P

Hike

x

L, SMS

TextPlus

x

L, SMS

L : localisation ; Ca : caméra ; Co : contacts ; P : état du téléphone ; SMS : messages Tableau 4.5. Les applications tierces qui fuient des données sensibles par le biais de flux d’informations

– 8 applications utilisent le flux de contrôle dans le contexte Java et provoquent la fuite d’informations sensibles telles que la localisation, l’état du téléphone, les contacts et les photos ; – 2 applications utilisent un flux explicite dans un contexte natif et provoquent la fuite d’informations sensibles telles que les contacts et les SMS ; – 10 applications utilisent le flux de contrôle dans un contexte natif et provoquent la fuite d’informations sensibles telles que la localisation, l’état du téléphone, les contacts et les SMS. La plupart de ces applications appartiennent à la catégorie des jeux (Fruit Ninja, Angry Birds, Subway Surfer) et à la catégorie communication (Grindr, HeyWire, Hike, TextPlus). Ces 10 applications n’ont été détectées que par notre approche. TaintDroid détecte 26 % des applications malveillantes qui provoquent des fuites de données sensibles, NDroid et Droidscope 35 %, Graa et al. (2014) 61 % et notre approche détecte toutes les applications. Par conséquent, notre approche identifie plus d’applications malveillantes que les approches existantes dans les systèmes Android.

Aperçu analytique du flux d’informations

183

4.6.6.2. Faux négatifs TaintDroid, grâce à sa simple politique de marquage JNI, génère 74 %, NDroid 65 %, Droidscope 65 % et l’approche de Graa et al. (2014) 39 % de faux négatifs. Notre approche résout le problème d’under-tainting. On a réussi à propager les tags dans les instructions de contrôle aux niveaux Java et natif et à détecter les fuites de données sensibles taguées qui sont signalées dans les messages d’alerte.

4.6.6.3. Performance Pour évaluer la performance de notre approche, nous étudions l’overhead d’analyse statique et dynamique. Nous effectuons l’analyse statique au moment du chargement et de la vérification. Notre approche ajoute 37 % et 30 % d’overhead par rapport au système non modifié, respectivement, au moment du chargement et de la vérification. Ceci est dû à la vérification des instructions de la méthode et à la construction des graphes de flot de contrôle utilisés pour détecter les flux de contrôle. Nous utilisons CF-Bench (Bench 2011), qui est un outil de benchmarking CPU et mémoire, pour évaluer l’overhead de notre approche. Nous avons choisi CF-Bench parce qu’il produit un score assez stable et teste les performances du code natif.

Figure 4.12. Résultats de CF-Bench de notre approche de suivi des données taguées

184

Cybervigilance et confiance numérique

Comme le montre la figure 4.12, notre approche subit en moyenne un ralentissement de 14,9 fois. Ce temps de surcharge est plus grand que le résultat du NDroid (5,45 fois le ralentissement) parce que nous propageons les tags dans les branches conditionnelles aux niveaux Java et natif. Ce temps de surcharge est supérieur au résultat du Droidscope (11 fois le ralentissement) réalisé sur une machine réelle et non dans un émulateur Google Android qui est prohibitivement lent. Bien que l’approche proposée ait une perte en temps d’exécution, elle donne des résultats de détection plus précis que le NDroid et le Droidscope.

4.6.6.4. Faux positifs Notre approche génère 30 % de faux positifs. Nous avons détecté des fuites d’IMSI et d’IMEI qui étaient réellement utilisées comme paramètres de configuration dans le smartphone. Par conséquent, nous ne pouvons pas considérer ces applications comme malveillantes.

4.6.7. Discussion Cavallaro et al. (2008) décrivent des techniques d’évasion qui peuvent facilement contourner l’analyse dynamique des flux d’informations. Ces attaques d’évasion peuvent utiliser des dépendances de contrôle. Ils démontrent qu’un auteur de logiciels malveillants peut propager une quantité arbitrairement importante d’informations grâce à des dépendances de contrôle. Cavallaro et al. voient qu’il est nécessaire de raisonner sur les affectations qui ont lieu au niveau des branches de programme non exécutées. Nous appliquons le même principe dans nos règles de propagation des tags. Malheureusement, cela entraînera un problème d’over-tainting (faux positifs). Le problème a été abordé dans Kang et al. (2011) et Bao et al. (2010) mais n’a pas été résolu. Kang et al. (2011) utilisent une technique de diagnostic pour sélectionner les branches qui pourraient être responsables de l’over-tainting et ne propager les tags que le long de ces branches afin de réduire l’over-tainting. Cependant, même avec la DTA++, il y a des faux positifs qui se produisent. Bao et al. (2010) définissent le concept de dépendance de contrôle strict (SCD) et introduisent sa sémantique. Ils utilisent une analyse statique pour identifier les branches prédicats qui donnent lieu à des SCD. Ils ne tiennent pas compte de toutes les dépendances de contrôle pour réduire le nombre de faux positifs. Leur implémentation donne des résultats similaires à DTA++ dans de nombreux cas, mais elle est basée sur la syntaxe d’une expression de comparaison. À l’inverse, DTA++ utilise une condition de niveau sémantique plus générale et plus précise, implémentée par exécution symbolique. Nous avons montré dans la section 4.6.6 que notre approche génère des faux positifs significatifs. Cependant, elle offre plus de sécurité parce que toutes les

Aperçu analytique du flux d’informations

185

données confidentielles sont taguées. Par conséquent, les informations sensibles ne peuvent pas être divulguées. Nous sommes intéressés à résoudre le problème d’undertainting parce que nous considérons que les faux négatifs sont beaucoup plus dangereux que les faux positifs, car les premiers peuvent conduire à une fuite de données. Il est possible de réduire le problème d’over-tainting en prenant en compte les règles d’experts (expert rules). Aussi, nous pouvons demander à l’utilisateur au moment où les données sensibles vont être divulguées d’autoriser ou non la transmission des données à l’extérieur du système.

4.7. Protection contre les attaques d’obfuscation de code basées sur les dépendances de contrôle dans les systèmes Android Dans cette section, nous montrons comment notre approche peut résister aux attaques d’obfuscation du code basées sur les dépendances de contrôle dans le système Android. Nous utilisons les règles qui définissent la propagation des tags présentées dans la section 4.6.2 pour éviter ces attaques d’obfuscation du code.

4.7.1. Définition de l’obfuscation du code En général, l’obfuscation consiste à rendre quelque chose plus difficile à comprendre. Collberg et al. (1997, 1998) définissent le processus d’obfuscation comme la transformation d’un programme d’ordinateur en un programme qui a le même comportement mais qui est beaucoup plus difficile à comprendre. DÉFINITION 4.10. Transformation d’obfuscation.– Soit Γ(P) un programme, obtenu par transformation du programme P. Γ est une transformation d’obfuscation, si Γ(P) a le même comportement observable que P. De plus, Γ doit appliquer les deux conditions suivantes : – si le programme P ne s’arrête pas ou se termine avec une condition d’erreur, alors Γ(P) peut ou non s’arrêter ; – sinon P se termine et Γ(P) doit se terminer et produire la même sortie que P. DÉFINITION 4.11. Formules complexes.– Si le programme P et Γ(P) sont identiques mais Γ(P) contient plus de propriétés q que P, alors Γ(P) est plus complexe que P. Selon la définition 4.10, une transformation d’obfuscation ajoute plus de propriétés q au programme initial pour augmenter son obfuscation.

186

Cybervigilance et confiance numérique

4.7.2. Types d’obfuscations liés au programme Les transformations d’obfuscation peuvent être classées dans les quatre catégories suivantes et peuvent affecter de nombreuses parties d’un programme (Collberg et al. 1997) : – la structure source et/ou binaire ; – l’obfuscation du contrôle (structure du flux de contrôle) ; – l’obfuscation des données (structures de données locales et globales) ; – l’obfuscation préventif utilisé pour se protéger contre les décompilateurs et les débogueurs. Les obfuscations du programme peuvent être effectuées à différents niveaux : – l’obfuscation layout, qui transforme un code source en un autre code source illisible par l’homme ; – l’obfuscation de niveau intermédiaire, qui transforme un programme au niveau de la représentation intermédiaire (RI) ; – l’obfuscation binaire, qui est effectuée au niveau binaire pour obscurcir la disposition et contrôler le flux du code binaire. Dans ce chapitre, nous nous concentrons uniquement sur l’obfuscation binaire.

4.7.3. Techniques d’obfuscation Plusieurs techniques spécifiques sont utilisées pour obscurcir un programme, comme décrit plus en détail dans Wroblewski (2002) : – le stockage et l’encodage d’obfuscations qui modifient la représentation des variables : diviser les variables, promouvoir les scalaires en objets, convertir les données statiques en procédures, modifier l’encodage et changer une variable locale en variable globale ; – l’obfuscation de l’agrégation qui fusionne les données indépendantes et sépare les données dépendantes : fusionne les variables scalaires, modifie les relations d’héritage et sépare ou fusionne les tableaux ; – l’obfuscation de l’ordre : réorganise les variables, les méthodes et les tableaux. Il existe trois groupes de méthodes d’obfuscation au niveau des flux de contrôle (Wroblewski 2002) :

Aperçu analytique du flux d’informations

187

– les méthodes d’obfuscation par calcul qui modifient la structure du flux de contrôle. Par exemple, l’extension de la condition de boucle (comme l’ajout de conditions qui ne changent pas le comportement d’un programme) ; – les méthodes d’agrégation d’obfuscation qui divisent et fusionnent des fragments de code. Par exemple, les méthodes en ligne qui consistent à insérer le code complet de la fonction lorsque la fonction est appelée, plutôt que de générer un appel de fonction ; – les méthodes d’obfuscation ordonnée qui réorganisent l’ordre des blocs, des boucles et des expressions, tout en préservant les dépendances. Dans la section 4.7.5, nous décrivons notre modèle d’attaque d’obfuscation basé sur des techniques de stockage et d’encodage d’obfuscation et des méthodes de calcul d’obfuscation.

4.7.4. Obfuscation de code dans le système Android Les techniques d’obfuscation sont utilisées dans la plateforme Android pour protéger les applications contre la rétro-ingénierie (Schulz 2012). Afin d’obtenir cette protection, les méthodes d’obfuscation telles que la manipulation des identificateurs et l’obfuscation des chaînes de caractères modifient le bytecode pendant l’exécution et réduisent les méta-informations dans les applications. Le code obtenu est difficile à analyser et complique l’obtention d’informations sur l’application et ses fonctionnalités. Les identificateurs sont des noms pour les paquets, les classes, les méthodes et les champs. La manipulation d’identificateur est le fait de remplacer tout identificateur par une représentation de chaîne vide de sens tout en maintenant la cohérence (la sémantique du code source). Ces chaînes ne contiennent aucune information sur l’objet ou son comportement. La méthode d’obfuscation de chaîne consiste à transformer une chaîne arbitraire en une autre chaîne à l’aide d’une fonction d’inversion injective (fonction xor ou chiffrement). Cette méthode réduit la quantité de méta-informations extractibles. Cependant, elle est détectée par l’analyse dynamique. ProGuard (Lafortune 2006), un outil open-source, est intégré dans le système de compilation Android. Il est appliqué pour obscurcir le code des applications Android en supprimant le code inutilisé et en renommant les méthodes, champs et classes. Le code qui en résulte est beaucoup plus difficile à recomposer. Allatori (Smardec 2017) est un obfuscateur Java développé par la société russe Smardec. Il est utilisé pour protéger les applications Android et pour se protéger de l’ingénierie inverse du code. Il offre des méthodes de protection comme l’obfuscation des flux, l’obfuscation des noms, l’obfuscation des informations de débogage et le

188

Cyybervigilance et confiance numé érique

chiffrem ment des chaînees. Enfin, Allaatori est égalem ment conçu poour réduire la ttaille et le temps dee traitement dees applicationss Android. Il est e plus puissaant que ProGuuard, mais il n’empêêche pas un annalyste de désaassembler unee application Android. A Cavaallaro et al. (20008) affirmentt que l’obfuscaation du code peut p être utilissée par les développpeurs de logiciiels malveillannts pour éviterr la détection. Cavallaro et aal. (2007) décrivennt des techniqques dynamiqques anti-tain nt qui peuvennt être utilissées pour obscurcirr le code et poour divulguer des d données seensibles. Nouss étudions ci-aaprès les technniques d’obfusscation utiliséees dans le conntexte des logiciels malveillants qui q peuvent faacilement conttourner l’analyyse dynamiquee des flux d’inform mations pour évviter la détecttion des fuites de données privées p dans lee système Android..

4.7.5. Modèle M d’atta aque Le prrocessus d’anaalyse dynamiqque de data tain nting est résum mé à la figure 44.13.

Figure 4.13.. Procédé d’an nalyse dynam mique des donn nées taguées sans attaque a d’obfu uscation

Tout d’abord, le syystème de suivvi dynamique des tags com mme TaintDroid attribue des tags aux données sensibles s (idenntification de l’appareil, conntacts, SMS/M MMS) (2). Ensuite, il suit la proopagation des données tagu uées (3). Enfinn, il émet dess rapports d’avertisssement lorsquue les donnéees taguées so ont divulguées par des appplications malveillaantes. Cela peeut être détectéé lorsque des données d sensiibles sont utiliisées dans un taint sink s (interfacee réseau) (6).

Aperçu analytique du flux d’informations

189

Considérons le modèle d’attaque présenté à la figure 4.14. L’application tierce est installée par l’utilisateur du smartphone (1). Ensuite, il fonctionnera sous un système de suivi dynamique des données taguées pour détecter la transmission d’informations privées au réseau. Ces informations sont taguées par le système de suivi dynamique des données taguées (2). Le développeur de l’application malveillante exploite les limites du système de suivi dynamique des données taguées tel que TaintDroid. Les règles de propagation des tags définies dans ce système ne peuvent pas propager les tags dans les flux de contrôle. Le développeur interfère dans le niveau de propagation des tags et utilise des techniques d’obfuscation (ajout de flux de contrôle et codage de code) pour tromper le mécanisme de marquage. Ils éliminent le tag des données sensibles qui devraient être taguées (4). La fuite de ces données n’est donc pas détectée (5).

Figure 4.14. Modèle d’attaque contre l’analyse dynamique des données taguées

Ensuite, nous présentons différents exemples d’attaques d’obfuscation de code basées sur des flux de contrôle qu’un système de suivi dynamique des données taguées, tel que TaintDroid, ne peut détecter.

4.7.6. Attaques d’obfuscation de code Sarwar et al. (2013) introduisent les attaques de contrôle de flux qui provoquent la fuite de données taguées. Ils évaluent expérimentalement les taux de succès de ces attaques pour contourner le suivi des données taguées avec TaintDroid. Nous présentons dans cette section des exemples de ces attaques d’obfuscation de code basées sur des dépendances de contrôle que TaintDroid ne peut détecter. Le tag ne se

190

Cybervigilance et confiance numérique

propage pas dans les instructions de flux de contrôle. L’attaquant exploite des variables non taguées qui devraient être taguées pour divulguer des données privées. L’algorithme 4.2 présente la première attaque. La variable X contient les données privées. L’attaquant obscurcit le code et essaie d’obtenir chaque caractère de X en le comparant avec les symboles s dans AsciiTable. Il stocke le bon caractère fondé en Y. À la fin de la boucle, l’attaquant réussit à connaître la valeur correcte des données privées stockées en Y. La variable Y n’est pas taguée car TaintDroid ne propage pas les tags dans les flux de contrôle. Ainsi, Y est envoyée par le réseau sans être détectée. L’algorithme 4.3 présente la deuxième attaque. L’attaquant enregistre les données privées dans la variable X. Ensuite, il lit chaque caractère de X et le convertit en entier. Dans la boucle suivante, il essaie de trouver la valeur de l’entier en incrémentant y. Il convertit l’entier en caractère et concatène tous les caractères de Y pour trouver la valeur de X. Ainsi, Y contient la valeur Private_Data, mais elle n’est pas taguée car TaintDroid ne traite pas le flux de contrôle. Par conséquent, l’attaquant réussit à faire fuir la valeur Private_Data sans aucun rapport d’avertissement.

Algorithme 4.2. Attaque d’obfuscation du code 1

Algorithme 4.3. Attaque d’obfuscation du code 2

Aperçu analytique du flux d’informations

191

L’algorithme 4.4 présente une attaque d’obfuscation de code basée sur une exception. La variable n contient une valeur d’un entier qui correspond à la conversion d’un caractère de données privées. L’attaquant lève une exception n fois dans le bloc « try ». Il gère l’exception levée dans le bloc catch en incrémentant y pour obtenir la valeur correcte de chaque caractère dans Private_Data. En concaténant les caractères, Y contient la valeur de la donnée privée et il n’est pas tagué car TaintDroid ne gère pas les exceptions utilisées dans le flux de contrôle. Ainsi, un attaquant peut réussir à divulguer des informations sensibles en lançant des exceptions pour contrôler le flux. Nous montrons, dans ce qui suit, comment notre approche peut détecter avec succès ces attaques d’obfuscation de code.

Algorithme 4.4. Attaque d’obfuscation du code 3

4.7.7. Détection d’attaques d’obfuscation de code Pour lancer des attaques d’obfuscation de code, l’attaquant exploite des variables non taguées qui doivent être taguées. Il y a donc un problème d’under-tainting, défini à la section 4.6.1. Nous utilisons des règles qui décrivent la propagation des tags présentée dans la section 4.6.2 pour la résoudre et détecter les attaques d’obfuscation de code basées sur les dépendances de contrôle. En utilisant ces règles, toutes les variables auxquelles une valeur est assignée dans la branche conditionnelle sont taguées, que la branche soit prise ou non. Le tag de ces variables reflète la dépendance à une condition. Considérons la première attaque d’obfuscation de code. La variable x est taguée parce qu’elle appartient à la chaîne de caractères X qui est taguée. Ainsi, la condition (x == TabAsc[ j]) est taguée. Notre système nous permet de propager le tag dans le flux de contrôle. En utilisant la première règle, Y est taguée et Taint(Y) = Taint(x ==

192

Cybervigilance et confiance numérique

TabAsc[ j]) ⊕ Taint(Y + TabAsc[ j]). Ainsi, la fuite de Y qui contient la valeur des données privées est détectée par notre approche. Dans la deuxième attaque d’obfuscation de code, l’attaquant tente d’obtenir des informations secrètes X. La variable x est taguée car elle appartient à la chaîne de caractères X, qui est taguée. Le résultat n de la conversion de x en entier est tagué. Ainsi, la condition (j = 0 à n) est taguée. En utilisant la première règle, y est taguée et Taint(y) = Taint(j = 0 à n) ⊕ Taint(y + 1). Dans la première boucle, la condition x ∈ X est taguée. Nous appliquons la première règle, Y est taguée et Taint(Y) = Taint(x ∈ X) ⊕ Taint(Y + (char)y). Ainsi, l’attaquant ne peut pas réussir cette attaque d’obfuscation de code détectée en utilisant notre approche. Dans la troisième attaque d’obfuscation de code, l’attaquant exploite l’exception pour lancer des attaques d’obfuscation de code et pour divulguer des données sensibles. L’exception est marquée, et son tag dépend de la condition de temps y < n. De plus, la condition de temps (y < n) est taguée parce que la variable n qui correspond à la conversion d’un caractère en données privées est taguée. Ensuite, on propage le tag de l’exception dans le bloc catch. Nous appliquons la première règle pour marquer y. Nous obtenons Taint(y) = Taint(exception) ⊕ Taint(y + 1). Enfin, la chaîne Y, qui contient les données privées, est taguée et Taint(Y) = Taint(x ∈ X) ⊕ Taint(Y + (char)y). Ainsi, un attaquant ne peut pas divulguer des informations sensibles en lançant des exceptions pour contrôler le flux.

4.7.8. Tests d’attaque d’obfuscation de code Nous avons mis en œuvre et exécuté les trois attaques d’obfuscation de code basées sur les dépendances de contrôle présentées à la section 4.7.6 pour tester l’efficacité de notre approche et pour détecter ces attaques. Nous avons testé ces attaques à l’aide d’un appareil mobile Nexus One fonctionnant sous Android OS version 2.3 modifié pour suivre les flux de contrôle. Nous utilisons l’outil Traceview pour évaluer la performance de ces attaques. Nous présentons à la fois les temps inclusif et exclusif. Le temps exclusif est le temps passé dans la méthode. Le temps inclusif est le temps passé dans la méthode plus le temps passé dans toute fonction appelée. Nous installons l’application TaintDroidNotify pour activer les notifications sur l’appareil en cas de fuite de données taguées. Considérons la première attaque de code obfuscaté (figure 4.15). La première boucle sert à remplir la table des caractères ASCII. L’attaquant essaie d’obtenir les

Aperçu analytique du flux d’informations

193

données privées (nom du contact utilisateur = « Graa Mariem ») en les comparant avec les symboles de la table ASCII dans la deuxième boucle. Le tag du nom du contact utilisateur est ((u4)0 × 00000002).

Figure 4.15. Attaque d’obfuscation du code 1

La variable x est taguée parce qu’elle appartient à la chaîne de caractères taguée X. Ainsi, la condition (x == TabAsc[j]) est taguée. Notre système nous permet de propager le tag dans le flux de contrôle. En utilisant la première règle, Y est tagué et Taint(Y) = Taint(x == TabAsc[j]) ⊕ Taint(Y + TabAsc[j]). Nous montrons dans le fichier journal donné à la figure 4.16(a) que Y est tagué et qu’il a le même tag que le nom du contact utilisateur. Une notification apparaît, signalant la fuite de Y qui contient la valeur des données privées. L’exécution du premier algorithme prend 88 ms en Inclusive CPU Time en utilisant TaintDroid modifié pour suivre les flux de contrôle et 36 ms en Android non modifié. La figure 4.17 illustre la deuxième attaque d’obfuscation de code. L’attaquant tente d’obtenir une information secrète X qui est le code IMEI du smartphone. Le tag de l’IMEI est ((u4)0 × 00000400). La variable x est taguée parce qu’elle appartient à la chaîne de caractères X, qui est taguée. Le résultat n de la conversion de x en entier est tagué. Ainsi, la condition (j = 0 à n) est taguée. En utilisant la première règle, y est

194

Cybervigilance et confiance numérique

taguée et Taint(y) = Taint(j = 0 à n) ⊕ Taint(y + 1). Dans la première boucle, la condition x ∈ X est taguée. Nous appliquons la première règle, Y est taguée et Taint(Y) = Taint(x ∈ X) ⊕ Taint(Y + (char)y). Ce résultat est indiqué dans le fichier journal illustré à la figure 4.16(b). La fuite de données privées est présentée dans la notification. L’exécution du second algorithme prend 101 ms en tant que Exclusive CPU Time en utilisant TaintDroid modifié pour suivre les flux de contrôle et 20 ms en Android non modifié. Le temps d’exécution dans notre approche est plus important car il inclut le temps de propagation des tags dans les flux de contrôle.

(a)

(b)

(c) Figure 4.16. Fichiers journaux des attaques d’obfuscation du code

Figure 4.17. Attaque d’obfuscation du code 2

Aperçu analytique du flux d’informations

195

La troisième attaque d’obfuscation de code est illustrée à la figure 4.18. L’attaquant exploite l’exception pour lancer des attaques d’obfuscation de code et pour divulguer des données sensibles (numéro de téléphone). La division par zéro lance une ArithmeticException. Cette exception est marquée et son tag dépend de la condition de boucle while y < n. De plus, la condition de boucle while (y < n) est taguée parce que la variable n qui correspond à la conversion d’un caractère dans Phone_Number est taguée. TaintDroid n’assigne pas de tag à l’exception. Nous attribuons le tag à l’exception (Taint_Exception = ((u4)0 × 00010000)). Ensuite, nous propageons le tag de l’exception dans le bloc catch. Nous appliquons la première règle pour marquer y. Nous obtenons Taint(y) = Taint(exception) ⊕ Taint(y + 1). Enfin, la chaîne Y, qui contient les données privées, est taguée et Taint(Y) = Taint(x ∈ X) ⊕ Taint(Y + (char)y). Dans le fichier journal illustré à la figure 4.16(c), nous montrons que le tag de Y est la combinaison du tag de l’exception (((u4)0 × 00010000)) et du tag du numéro de téléphone ((u4)0 × 00000008)). Un message d’avertissement apparaît indiquant la fuite d’informations sensibles. L’exécution du troisième algorithme prend 1 385 ms en temps CPU inclus en utilisant TaintDroid modifié pour suivre les flux de contrôle et 1 437 ms en Android non modifié. Cette différence est due à la propagation des tags dans le flux de contrôle. La taille des graphes de flot de contrôle obtenus des trois algorithmes est d’environ 1 200 octets.

Figure 4.18. Attaque d’obfuscation du code 3

196

Cybervigilance et confiance numérique

4.8. Détection d’attaques de canaux auxiliaires basées sur le tag des données dans les systèmes Android Les applications malveillantes visent à voler des données personnelles qui sont stockées dans l’appareil ou potentiellement disponibles par des canaux auxiliaires tels que les canaux de synchronisation et de stockage. Les attaques par canaux auxiliaires (Cai et Chen 2011 ; Schlegel et al. 2011 ; Jana et Shmatikov 2012) exploitent l’utilisation des médias pour déduire des informations privées (SMS, contacts, localisation, numéro de téléphone, photos, etc.) en analysant les canaux auxiliaires. Sarwar et al. (Babil et al. 2013) proposent des attaques de canal auxiliaire telles que le timing de bypass, le cache bitmap, les métadonnées et les attaques de propriétés graphiques qui créent des variables non taguées à partir d’objets tagués pour contourner la technique de sécurité de l’analyse dynamique des données taguées. Kim et al. (2015) utilisent une attaque de mémoire bitmap d’écran proposée par Sarwar et al. pour définir un système de collecte qui récupère des informations sensibles par le biais d’une image de capture d’écran. Le modèle de sécurité Android est basé sur l’application de sandboxing, la signature d’application et un modèle de permission. L’attaque de canal auxiliaire s’exécute dans son propre processus, avec sa propre instance de la machine virtuelle Dalvik. Elle accède aux canaux auxiliaires qui sont un média public. Par conséquent, la technique d’application de sandboxing ne permet pas de détecter ces attaques. L’application malveillante qui implémente les attaques de canal auxiliaire est signée numériquement avec un certificat. Elle peut donc être installée sur des systèmes Android. Le système de permission Android standard contrôle l’accès aux données sensibles mais n’assure pas la sécurité de bout en bout car il ne suit pas le flux d’informations par les canaux auxiliaires. Comme les mécanismes de sécurité de base d’Android ne peuvent pas détecter les attaques par canal auxiliaire, de nouvelles approches qui étendent l’OS Android ont été proposées. XManDroid (Bugiel et al. 2011), un framework de sécurité, étend le mécanisme de surveillance d’Android pour détecter les attaques par canal auxiliaire telles que Soundcomber. Cependant, il ne peut pas détecter un sous-ensemble de canaux auxiliaires tels que le canal de synchronisation, la fréquence du processeur et l’espace libre sur le système de fichiers. TaintDroid (Enck et al. 2010), une extension de la plateforme de téléphonie mobile Android, utilise l’analyse dynamique des données taguées pour détecter une attaque directe de tampon (direct buffer). L’approche d’analyse dynamique (Enck et al. 2010 ; Hornyack et al. 2011 ; Spreitzenbarth et al. 2015) définie dans les smartphones ne permet pas de détecter les attaques par canal auxiliaire des logiciels présentés dans Babil et al. (2013) et Kim et al. (2015). Ainsi, nous modifions le système d’exploitation Android pour détecter les attaques par canal

Aperçu analytique du flux d’informations

197

auxiliaire des logiciels qui tentent de contourner les mécanismes de détection basés sur l’analyse dynamique des données taguées. Nous propageons le tag dans le timing, la mémoire cache et les canaux GPU et dans les métadonnées en utilisant des règles de propagation des tags. Nous présentons une classe des attaques par canal auxiliaire que TaintDroid ne peut pas détecter.

4.8.1. Modèle de menace cible Considérons le modèle d’attaque présenté à la figure 4.19. Le but de l’adversaire est d’extraire des données sensibles du système tiers Android. Il développe une application malveillante qui sera exécutée sur ce système et envoie des données sensibles via le réseau vers un système que l’adversaire contrôle. Nous supposons que l’utilisateur du smartphone installe l’application malveillante sur son téléphone.

Figure 4.19. Modèle d’attaque cible

De plus, nous supposons qu’il utilise un système dynamique de suivi des données taguées tel que TaintDroid. Par conséquent, l’application malveillante sera exécutée sous ce système. L’adversaire exploite la limitation du mécanisme d’analyse dynamique des données taguées qui ne peut pas propager le tag dans des canaux auxiliaires. Il interfère dans le niveau de propagation des tags et enlève le tag des données

198

Cybervigilance et confiance numérique

sensibles qui devraient être taguées. Par conséquent, ces données seront divulguées sans être détectées. Ensuite, nous présentons différents exemples d’attaques par canal auxiliaire qu’un système de suivi dynamique tel que TaintDroid ne peut détecter.

4.8.2. Attaques dans les canaux latéraux Sarwar et al. (Babil et al. 2013) présentent des attaques de type canal auxiliaire telles que les attaques de type bypass timing, bitmap cache, métadonnées et propriétés graphiques en utilisant un support qui pourrait être exploité par le mécanisme de contrôle des tags pour extraire des données sensibles. Ils testent et évaluent le taux de succès et le temps de ces attaques avec le système TaintDroid. Nous sommes intéressés par ces attaques car ce sont les plus importantes attaques non détectées présentées par Sarwar et al., les autres attaques étant déjà détectées (Graa et al. 2014). Nous présentons dans cette section des exemples de ces attaques par canal auxiliaire.

4.8.2.1. Attaque de synchronisation L’attaque de synchronisation (timing attack) est un exemple d’attaque de canal auxiliaire dans lequel l’attaquant tente de compromettre un système cryptographique en analysant le temps pris pour obtenir des informations sur les clés. Un concept similaire peut être utilisé pour faire fuir des données taguées lors de l’exécution d’un programme avec une approche d’analyse des données taguées. L’algorithme 4.5 présente l’attaque temporelle dans le système de suivi des tags. Cette attaque exploite l’horloge du système qui n’est pas taguée. La fonction sleep() suspend l’exécution du programme en cours jusqu’à ce que le délai d’attente, qui dépend de la valeur d’une variable taguée, soit expiré. Par conséquent, la différence entre les lectures de temps avant et après une période d’attente indique la valeur des données sensibles. Cette différence n’est pas taguée parce qu’il n’y a pas de propagation des tags dans l’horloge du système. Par conséquent, il peut être affecté à la variable de sortie sans qu’il soit tagué et envoyé à travers le réseau sans être détecté.

Algorithme 4.5. Timing Attack

Aperçu analytique du flux d’informations

199

4.8.2.2. Attaque de mémoire cache L’attaque de mémoire cache est un autre exemple d’attaque de canal auxiliaire qui peut être utilisé pour extraire des données sensibles. Cette attaque exploite le fait que la sortie graphique peut être obtenue à partir d’un cache de l’écran actuellement affiché. L’algorithme 4.6 présente l’attaque du cache bitmap. Le widget graphique contient les données privées. L’attaquant l’extrait avec succès de la mémoire cache bitmap sans aucun rapport d’avertissement car le tag ne se propage pas dans la mémoire cache. Il envoie les données bitmap au Cloud et utilise les techniques de reconnaissance optique de caractères (OCR) (Kay 2007) pour lire la valeur des données sensibles.

Algorithme 4.6. Bitmap Cache Attack

4.8.2.3. Attaque de pixel bitmap Un attaquant peut extraire des données privées en exploitant les pixels du cache bitmap comme indiqué dans l’algorithme 4.7. Il modifie un pixel arbitrairement choisi pour représenter la valeur des données privées. Ensuite, il lit la valeur contenue dans ce pixel à des coordonnées spécifiques.

Algorithme 4.7. Bitmap Pixel Attack

4.8.2.4. Attaque de métadonnées Les systèmes d’analyse des données taguées tels que TaintDroid associent le tag à l’objet contenant des données sensibles. Cependant, ces systèmes ne propagent pas le tag à la taille de l’objet. Nous présentons des attaques par canal auxiliaire qui exploitent les métadonnées pour éviter le suivi des tags.

200

Cybervigilance et confiance numérique

4.8.2.5. Attaque de longueur de fichier Comme la taille du fichier n’est pas taguée, un attaquant peut exploiter ces métadonnées pour faire fuir des données sensibles, comme le montre l’algorithme 4.8. Chaque caractère des données privées est représenté par une taille de fichier arbitraire. Un octet est écrit dans un fichier jusqu’à ce que sa taille soit égale à la valeur des données privées du caractère. Ensuite, l’attaquant obtient la taille du fichier, qui correspond aux données sensibles sans aucun rapport d’avertissement.

Algorithme 4.8. File Lengh Attack

4.8.2.6. Attaque de la longueur du clipboard Une attaque similaire à l’attaque de la longueur du fichier peut être exécutée si une application a besoin d’un clipboard pour échanger des données. Dans l’attaque de la longueur du clipboard, la taille du fichier est remplacée par la taille du contenu du clipboard, comme le montre l’algorithme 4.9.

Algorithme 4.9. Clipboard Lengh Attack

4.8.2.7. Attaque de processeur graphique Nous sommes intéressés par une classe d’attaques de processeur graphique qui exploite les propriétés d’un élément graphique pour contourner le mécanisme de suivi des tags.

Aperçu analytique du flux d’informations

201

Par exemple, dans l’attaque text scaling présentée dans l’algorithme 4.10, l’attaquant associe la valeur des données privées à une propriété arbitraire d’un widget graphique (the scaling). Ensuite, il extrait et envoie cette propriété à travers le réseau.

Algorithme 4.10. Text Scaling Attack

4.8.3. Règles de propagation pour détecter les attaques par canal auxiliaire Notre approche est basée sur l’analyse dynamique des données taguées pour détecter les attaques par canal auxiliaire comme celles présentées dans la section 4.8.2. Nous spécifions un ensemble de règles formellement définies qui propagent le tag dans différents canaux auxiliaires pour détecter les fuites de données sensibles.

4.8.3.1. Règle de propagation du canal auxiliaire de synchronisation L’attaque de synchronisation exploite l’horloge du système, qui n’est pas taguée. L’attaquant lit l’horloge système après la période d’attente. Nous définissons Timing Context_Taint, qui est activé lorsque l’argument (arg) de la fonction Sleep() est tagué. Sleep(arg) ∧ Istainted(arg) ⇒ Activate (Timing_Context_Taint) Dans ce cas, nous propageons le tag dans le canal auxiliaire de synchronisation. Par conséquent, l’horloge du système est taguée et l’attaquant ne peut pas divulguer des informations sensibles par le canal auxiliaire de synchronisation. Isactivated(Timing_Contex_Taint) ⇒ Taint(system clock)

4.8.3.2. Règle de propagation du canal auxiliaire du mémoire cache L’attaque de cache bitmap exploite la mémoire cache de l’écran actuellement affiché. L’attaquant capture le cache bitmap d’un objet graphique contenant des données privées. Nous définissons Bitmap_Context_Taint, qui est activé lorsque l’objet graphique est tagué. Istainted(graphical object) ⇒ Activate(Bitmap_Context_Taint)

202

Cybervigilance et confiance numérique

Dans ce cas, nous propageons le tag dans le canal auxiliaire du cache bitmap et associons le tag à l’objet bitmap. Isactivated(Bitmap_Context_Taint) ⇒ Taint(Bitmap) Pour l’attaque des pixels bitmap, l’attaquant exploite les pixels du cache bitmap qui sont modifiés pour obtenir la valeur des données privées. Nous définissons Pixels_Context_Taint, qui est activé lorsque le paramètre argument de la fonction pixel est tagué. Par conséquent, un pixel arbitrairement choisi est modifié pour représenter la valeur des données privées. setPixel(arg) ∧ Istainted(arg) ⇒ Activate (Pixels_Context_Taint) Dans ce cas, nous assignons un tag à la valeur de retour de la fonction getPixel(). Isactivated(Pixels_Context_Taint) ⇒ Taint(return_getPixel) En utilisant ces règles de propagation des canaux auxiliaires de la mémoire cache, l’attaquant ne peut pas divulguer des informations sensibles à travers la mémoire cache bitmap.

4.8.3.3. Règle de propagation des métadonnées Les attaques de métadonnées exploitent la taille de l’objet qui n’est pas taguée. Nous définissons Meta_Data_Context_Taint, qui est activé lorsque l’application reçoit des données privées. get_private_data() ⇒ Activate (Meta_Data_Context_Taint) Dans ce cas, nous définissons la règle de propagation des métadonnées et associons le tag à la valeur de retour de la méthode length(). Isactivated(Meta_Data_Context_Taint) ⇒ Taint(length_object) Par conséquent, en appliquant la règle de propagation des métadonnées, l’attaquant ne peut pas divulguer des informations sensibles en utilisant des métadonnées.

4.8.3.4. Règle de propagation GPU La classe des attaques de processeur graphique considérée exploite les propriétés des éléments graphiques. L’attaquant associe une propriété arbitraire d’un widget graphique à la valeur des données privées. Par conséquent, nous définissons GPU_

Aperçu analytique du flux d’informations

203

Context__Taint, qui est activé lorsquee le paramètree argument de la fonction seetProperty est taguéé. seetProperty(arg rg) ∧ Istaintedd(arg) ⇒ Activvate (GPU_Coontext_Taint) Danss ce cas, nous assignons a un tag t à la fonctio on getPropertyy() pour empêcher cette attaque. Issactivated(GP PU_Context_T Taint) ⇒ Taintt(getProperty(()) En utilisant u la règgle de propagaation GPU, l’attaquant ne peut p pas divuulguer des informattions sensibles en exploitant les propriétés des éléments graphiques.

4.8.4. Mise M en œuv vre Nouss modifions le l système TaintDroid T po our mettre enn œuvre les rrègles de propagattion des tags définies danns la section n 4.8.3. La figgure 4.20 préésente les composaants modifiés (composants ( b bleus) pour déttecter les attaqques par canal auxiliaire dans le système s TaintD Droid. Nous modifions m la machine m virtuellle Dalvik pouur détecter les attaquues de synchroonisation. Nouus implémento ons les règles de d propagationn du GPU et de la mémoire m cachhe au niveau du d framework k pour préveniir le cache bitm tmap et la classe d’’attaques GPU U. Nous instrum mentons les bibliothèques b d base (core libraries) de pour assoocier le tag auxx métadonnéees.

Fig gure 4.20. Less composants s modifiés (ble eus) po our détecter le es attaques de e canal auxilia aire

204

Cybervigilance et confiance numérique

4.8.4.1. Détection d’attaques de synchronisation La fonction VMT hread_sleep(constu4 ∗ args, JValue ∗ pResult) dans le code natif de la machine virtuelle Dalvik suspend l’exécution du thread courant pendant une durée qui correspond à la valeur d’une variable taguée. Ensuite, l’attaquant lit l’horloge système après la période d’attente. Nous testons l’argument de VMT hread_ sleep() pour implémenter Timing_Context_Taint. Nous modifions la fonction current TimeMillis(constu4 ∗ args, JValue ∗ pResult) dans le code natif de la machine virtuelle Dalvik pour propager le tag dans l’horloge système si Timing_Context_Taint est activé. Par conséquent, la différence entre les temps avant et après une période d’attente qui indique la valeur des données sensibles est taguée.

4.8.4.2. Détection d’attaques de mémoire cache Nous vérifions si l’objet graphique contient une donnée privée pour implémenter le GPU_Taint_Context. Tous les objets graphiques définis dans le framework Android étendent la vue (view). Par conséquent, nous vérifions si la vue est taguée. La fonction getDrawingCache() de la classe de vue crée et retourne un objet bitmap qui contient les données privées. Par conséquent, nous marquons la valeur de retour de la fonction getDrawingCache() si le GPU_Taint_Context est activé. Pour l’attaque des pixels bitmap, le bitmap est d’abord créé puis modifié en exploitant les pixels du cache bitmap. Nous vérifions si le paramètre argument de la fonction pixel définie dans la classe bitmap (package graphique) est tagué pour implémenter Pixels_Taint_Context. Dans ce cas, nous assignons un tag à la valeur de retour de la fonction getPixel() dans la classe bitmap.

4.8.4.3. Détection d’attaques de métadonnées TaintDroid associe un tag à la source d’une donnée privée qui permet d’acquérir des informations sensibles (capteurs à faible bande passante, par exemple les géomètres et les accéléromètres ; capteurs à bande passante élevée, par exemple les microphones et les caméras ; bases de données, par exemple les répertoires et les messages SMS ; les identificateurs de téléphone, par exemple les identificateurs de cartes SIM (IMSI, ICC-ID) et le code IMEI). Dans chaque source taguée, nous implémentons Meta_Data_Context_Taint, qui est activé si des données privées sont acquises. Pour détecter la classe de métadonnées des attaques, nous associons le tag à la valeur de retour de la méthode length() au niveau libcore dans les classes File et String si Meta_Data_Context_Taint est activé.

4.8.4.4. Processeur graphique pour la détection d’attaques Pour lancer la classe d’attaques considérées du processeur graphique, l’attaquant associe une valeur des données privées à une propriété arbitraire d’un widget graphique. Par conséquent, nous vérifions si le paramètre argument de la fonction

Aperçu analytique du flux d’informations

205

SetProperty (SetTextScalingValue) de la classe widget graphique est tagué pour implémenter GPU_Taint_Context. Ensuite, nous marquons la valeur de retour de getProperty(fonction GetTextScaling Value) si GPU_Taint_Context est activé pour empêcher cette attaque.

4.8.5. Évaluation Nous installons notre système dans un appareil mobile Nexus 4 sous Android OS version 4.3. Nous analysons un certain nombre d’applications Android pour tester l’efficacité de notre approche. Ensuite, nous évaluons les faux positifs qui pourraient se produire. Nous étudions l’overhead de notre approche de suivi des données taguées à l’aide de benchmarks standard.

4.8.5.1. Efficacité Pour évaluer l’efficacité de notre approche, nous analysons les 100 applications Android gratuites les plus populaires téléchargées depuis Android Market (Android 2017). Ces applications sont classées dans les catégories suivantes : jeux, achat, information sur les appareils, activités sociales, outils, météo, musique et audio, maps et navigation, photographie, productivité, mode de vie, références, voyages, sports et divertissement. Nous observons que toutes les applications utilisent le canal de cache bitmap, 50 % utilisent le canal de synchronisation, 30 % utilisent le canal GPU (obtenir et définir les propriétés graphiques) et 20 % utilisent les métadonnées (tailles des fichiers et du clipboard). Nous avons constaté que 66 % de ces applications manipulent des données confidentielles. Notre approche a réussi à propager le tag dans les canaux auxiliaires et à détecter les fuites de données sensibles taguées en vérifiant le contenu des paquets réseau envoyés par les applications.

(a)

(b)

(c)

Figure 4.21. Fuite de données privées à travers les canaux auxiliaires du cache bitmap

206

Cybervigilance et confiance numérique

Nous avons constaté que 35 % des applications divulguaient des données privées par le biais de canaux auxiliaires de synchronisation et de cache bitmap. Par exemple, l’application IMEI prend et envoie une capture d’écran des informations IMEI à travers le réseau en exploitant le canal auxiliaire cache bitmap (figure 4.21(a)). D’autres applications copient les informations de la carte SIM et de l’appareil depuis l’écran au clipboard et les envoient via le réseau, SMS ou bluetooth en utilisant le canal auxiliaire cache bitmap (figure 4.21(c)). Certaines applications amènent le drawing cache à divulguer implicitement des données privées. Par exemple, l’application IMEI Analyzer permet au drawing cache d’envoyer implicitement l’IMEI hors du smartphone (figure 4.21(b)). Les applications de jeux ont implicitement divulgué l’ID des appareils à travers le canal auxiliaire de synchronisation au moment du partage des scores. De plus, nous avons implémenté et détecté avec succès la classe d’attaques des canaux auxiliaires présentée dans la section 4.8.2.

4.8.5.2. Faux positifs Nous avons constaté que 35 des 100 applications Android testées ont divulgué des données sensibles par des canaux auxiliaires. Nous avons détecté trois informations de l‘appareil (ID Android, numéro de série de l’appareil, modèle de l’appareil, numéro de téléphone, etc.) qui sont envoyées à l’extérieur de l’appareil. De plus, nous avons détecté que l’IMEI est transmis à l’extérieur du smartphone par deux formes différentes (numérique et par une autre application qui fait une capture d’écran de l’IMEI). De plus, nous avons détecté quatre vulnérabilités de fuite d’informations de la carte SIM (SIM provider’s country, SIM Contacts, SimState, etc.). Comme l’utilisateur reçoit ces informations par e-mail, SMS ou bluetooth, nous ne pouvons pas traiter ces applications comme des applications malveillantes. Par conséquent, notre approche génère 9 % de faux positifs.

4.8.5.3. Performance Nous utilisons le CaffeineMark (Corporation 1997) pour étudier l’overhead de notre approche. Les scores de CaffeineMark correspondent approximativement au nombre d’instructions Java exécutées par seconde et ne dépendent pas significativement de la quantité de mémoire dans le système ou de la vitesse des disques durs de l’ordinateur ou de la connexion Internet. La figure 4.22 présente les résultats du temps d’exécution d’un Java microbenchmark. Le système Android non modifié avait un score global de 8 401 instructions Java exécutées par seconde, et le système TaintDroid mesurait 6 610 instructions Java exécutées par seconde. Par conséquent, TaintDroid a une surcharge de 21 % par rapport au système Android non modifié. Notre approche génère un score global de 5 873 instructions Java exécutées par seconde. Par conséquent, notre approche a une surcharge de 9 % par rapport au système TaintDroid. Elle ralentit la vitesse d’exécution parce que

Aperçu analytique du flux d’informations

207

nous propageons le tag dans les canaux auxiliaires. Cependant, l’overhead généré par notre approche est acceptable par rapport à celui obtenu par TaintDroid.

Figure 4.22. Microbenchmark de l’overhead Java

4.9. Suivi du flux d’informations dans les approches des systèmes Android : résumé Dans cette section, nous discutons les approches qui assurent le suivi du flux d’informations dans les systèmes Android. Les caractéristiques sur lesquelles nous nous sommes basés pour faire cette comparaison sont résumées dans le tableau 4.6. Nous notons que la plupart des approches d’analyse statique (Fuchs et al. 2009 ; Enck et al. 2011 ; Kim et al. 2012 ; Arzt et al. 2014 ; Gibler et al. 2012 ; Dhavale et Lokhande 2016) peuvent suivre les flux explicites et de contrôle mais elles ne prennent pas en compte l’obfuscation de code et les attaques par canal auxiliaire. De plus, ces systèmes d’analyse statique génèrent un nombre élevé de faux positifs. Nous avons constaté que les approches d’analyse dynamique des données taguées (Enck et al. 2010 ; Hornyack et al. 2011 ; Yan et Yin 2012 ; Shankar et al. 2017 ; Qian et al. 2014 ; Wang et Shieh 2015) ne détectent que le flux explicite en Java ou en code natif mais pas le flux de contrôle. Par conséquent, ils ne peuvent pas détecter l’obfuscation du code et les attaques de canal auxiliaire basées sur les dépendances de contrôle dans les systèmes Android et ils génèrent de faux négatifs. De plus, nous notons que la plupart des approches hybrides (Spreitzenbarth et al. 2015 ; Graa et al. 2016) ne peuvent pas détecter les attaques par canal auxiliaire. Dans ce chapitre, l’approche que nous proposons permet de suivre et de contrôler les flux explicites dans le code java et natif des applications android. De plus, nous pouvons détecter l’obfuscation du code et les attaques par canal auxiliaire en utilisant des règles de propagation des tags.

Technique

S.A.

S.A.

S.A.

S.T.A.

S.T.A.

Système

ScanDoid (Fuchs et al. 2009)

ded (Enck et al. 2011)

ScanDal (Kim et al. 2012)

AndroidLeaks (Gibler et al. 2012)

LeakMiner (Yang et Yang 2012)

Année

2009

2011

2012

2012

2012

Interprétation abstraite + Analyse insensible au trajet + Analyse contextuelle + Analyses sensibles insensibles des flux Créez un graphe d’appel + Une analyse de reachability + Mappage des permissions Identification des données sensibles + Construction d’un graphe d’appel et analyse des pointeurs Flux explicite

Flux explicite et de contrôle

Flux explicite et de contrôle

Flux explicite et de contrôle

Flux explicite et de contrôle

Extraire les spécifications de sécurité + Contrôle des flux de données + Certification de sécurité Tests automatisés et inspection manuelle

Flux de données

Description

Code Java

Code Java

Code Java

Code Java

Code Java

Code Java ou code natif

Non testé

Non testé

Non testé

Non détecté

Non testé

Détecter l’obfuscation et les attaques par canal auxiliaire

Faux positifs

Faux positifs

Faux positifs

Faux négatifs et positifs

Non évalué

Faux +/-

208 Cybervigilance et confiance numérique

Technique

S.T.A.

S.T.A.

S.T.A.

D.T.A.

D.T.A.

Système

FlowDroid (Arzt et al. 2014)

DroidSafe (Gordon et al. 2015)

Comnoid (Dhavale et Lokhande 2016)

TaintDroid (Enck et al. 2010)

AppFence (Hornyack et al. 2011)

Année

2014

2015

2016

2010

2011

Contexte de rappel de modèle, événements du cycle de vie, flux de données, instanciations d’objets en tas, méthodes natives et aliasing Basé sur FlowDroid + Analyse de la communication interapplications Analyse dynamique des données taguées + Exploitation de l’environnement d’exécution virtuelle d’Android + Surveillance du comportement de l’application Android Analyse dynamique des données taguées + Substitution de données shadow + Blocage des transmissions réseau

Modélisation du cycle de vie complet d’Android

Description

Flux explicite

Flux explicite

Flux explicite et de contrôle

Flux explicite

Flux explicite et de contrôle

Flux de données

Code Java

Code Java

Java et code natif

Java et code natif

Java et code natif

Code Java ou code natif

Non détecté

Non détecté

Non testé

Non détecté

Exclus

Détecter l’obfuscation et les attaques par canal auxiliaire

Faux négatifs

Faux positifs et faux négatifs

Non évalué

Faux positifs

Faux positifs

Faux +/-

Aperçu analytique du flux d’informations 209

Technique

S.T.A. + D.T.A.

D.T.A.

D.T.A.

D.T.A.

D.T.A.

Système

(Graa et al. 2012 ; Graa et al. 2014)

AndroTaint (Shankar et al. 2017)

DroidScope (Yan et Yin 2012)

NDroid (Qian et al. 2014)

Droit (Wang et Shieh 2015)

Année

2014

2017

2012

2014

2015

Commutation entre le niveau objet et le niveau d’instruction

– La phase de formation pour l’extraction caractéristique – La phase d’analyse pour l’étiquetage et le marquage automatiques Reconstruction des informations de niveau OS et DVM Virtualisation + Traceur d’instructions + DVM + Intercepter les bibliothèques systèmes + Propagation des tags

Règles de propagation des tags + Suivi des flux d’information

Description

Flux explicite

Flux explicite

Flux explicite

Flux explicite

Flux explicite et de contrôle

Flux de données

Java et code natif

Java et code natif

Java et code natif

Java et code natif

Code Java

Code Java ou code natif

Non détecté

Non détecté

Non détecté

Non détecté

Les attaques de code d’obfuscation détectées

Détecter l’obfuscation et les attaques par canal auxiliaire

Faux négatifs et faux positifs

Faux négatifs

Non testé

Moins de faux positifs et de faux négatifs

Faux positifs

Faux +/-

210 Cybervigilance et confiance numérique

S.T.A. + D.T.A.

S.T.A. + D.T.A.

S.T.A. + D.T.A.

D.T.A.

DroidBox (Spreitzenbarth et al. 2015)

Approche de (Graa et al. 2016)

TaintMan (You et al. 2017)

Approche de (Graa et al. 2017)

2015

2016

2017

2017

Flux explicites et de contrôle

Instrumentation statique + Reconstruction d’un nouvel environnement d’exécution + Analyse au temps d’exécution Flux explicite et de contrôle

Flux explicites et de contrôle

Basé sur l’approche de Graa et al. 2014 + Instrumenter les bibliothèques natives + Intercepter les appels JNI + Introspection de la machine virtuelle + Intercepter les appels systèmes sélectionnés

Règles de propagation au niveau des canaux auxiliaires

Flux explicite et de contrôle

Flux de données

Sandbox, marquage, techniques d’apprentissage machine

Description

Code Java

Code Java

Java et code natif

Java et code natif

Code Java ou code natif

Détection d’attaques par les canaux auxiliaires

Non testé

Les attaques de code d’obfuscation détectées

Détecter l’obfuscation et les attaques par canal auxiliaire Attaques d’obfuscation détectées

Tableau 4.6. Comparaison des approches de suivi de flux d’informations dans les systèmes Android

Technique

Système

Année

Faux positifs

Pas de faux positifs

Faux positifs

Faux positifs

Faux +/-

Aperçu analytique du flux d’informations 211

212

Cybervigilance et confiance numérique

4.10. Conclusion Les systèmes Android utilisent des données de nature sensible. De nombreux mécanismes sont définis pour contrôler l’accès et la manipulation des informations privées. Nous avons présenté une vue d’ensemble et une analyse des approches, techniques et mécanismes actuels utilisés pour assurer les propriétés de sécurité des systèmes Android. Nous observons que la sécurité du système Android est un domaine d’intérêt et de recherche en plein essor. Nous remarquons que les applications tierces sont responsables de la plupart des attaques dans les systèmes Android. Ces applications utilisent des permissions excessives, d’élévation de privilèges et des bibliothèques de publicité pour accéder aux données privées. Les approches de contrôle d’accès définissent les règles de politique. Toutefois, il est difficile d’élaborer des politiques utiles et utilisables. Par conséquent, les travaux de recherche doivent trouver un équilibre entre la sécurité et la facilité d’utilisation. Ces approches contrôlent l’accès aux informations sensibles mais n’assurent pas la sécurité de bout en bout car elles ne suivent pas la propagation des données entrées par l’utilisateur dans l’application. Les applications tierces exploitent le flux d’informations pour obtenir des données privées. L’approche basée sur la falsification d’informations sensibles donne de fausses informations privées. Cela peut perturber l’exécution des applications. Une amélioration possible serait de fournir plus d’informations contextuelles pour justifier le besoin d’accès et aider les utilisateurs à prendre la décision. Les approches d’analyse statique et dynamique des données taguées implémentées dans les systèmes Android nous permettent de détecter les fuites de données. Ces techniques sont utiles mais ont des limites. Les approches d’analyse dynamique des données taguées telles que Taintdroid et AppFence suivent le flux d’informations en temps réel et contrôlent le traitement des données privées. Cependant, elles ne peuvent pas détecter les flux de contrôle et elles sont limitées par leur évolutivité. Ces approches et la plupart des approches d’analyse statique ne peuvent pas détecter les attaques d’obfuscation de code basées sur les dépendances de contrôle dans les systèmes Android. Par conséquent, les approches hybrides améliorent l’analyse dynamique des données taguées en propageant les tags le long des dépendances de contrôle en utilisant l’analyse statique dans les systèmes Android. La plupart des approches de suivi de flux d’informations ne gèrent pas le code natif. Nous avons montré dans ce chapitre que les applications Android malveillantes peuvent exploiter du code natif pour divulguer des données sensibles. De plus, ces approches ne propagent pas les tags dans les canaux auxiliaires. Ainsi, un attaquant

Aperçu analytique du flux d’informations

213

peut utiliser un canal auxiliaire pour obtenir des informations privées. Dans ce chapitre, nous avons proposé une approche qui utilise l’analyse statique pour guider l’analyse dynamique dans les systèmes Android. Nous avons suivi le flux d’informations dans le code java et natif des applications Android. Grâce à notre approche, nous avons pu détecter l’obfuscation du code et les attaques par canal auxiliaire qui exploitent le flux de contrôle pour obtenir des informations sensibles.

4.11. Bibliographie AhnLab, I. (2012). Ahnlab reports the analysis of the best apps in the android market. Available: http://www.businesswire.com/news/home/20120430005670/en/AhnLab Reports-Analysis-Apps-Android-Market. Aho, A.V. and Ullman, J.D. (1972). The Theory of Parsing, Translation, and Compiling. Prentice-Hall, Inc. Aho, A.V., Sethi, R., and Ullman, J.D. (1986). Compilers: Principles, Techniques, and Tools. Addison-Wesley Longman Publishing Co., Inc., Boston, MA. Allen, F.E. (1970). Control flow analysis. ACM Sigplan Notices, 5(7), 1–19. Amighi, A., de Carvalho Gomes, P., Gurov, D., and Huisman, M. (2012). Provably correct control-flow graphs from java programs with exceptions. Formal Verication of Object-oriented Software, Volume 26 of Karlsruhe Reports in Informatics, October 2011. Karlsruhe Institute of Technology, Germany, pp. 31–48. Android (2017). Android. Available: http://www.android.com/. Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., Le Traon, Y., Octeau, D., and McDaniel, P. (2014). Flowdroid: precise context, flow, field, objectsensitive and lifecycle-aware taint analysis for android apps. Proceedings of the 35th Annual ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2014). ACM, pp. 259–269. Babil, G.S., Mehani, O., Boreli, R., and Kaafar, M.-A. (2013). On the effectiveness of dynamic taint analysis for protecting against private information leaks on androidbased devices. 2013 International Conference on Security and Cryptography (SECRYPT). IEEE, pp. 1–8. Backes, M., Gerling, S., Hammer, C., Maffei, M., and Styp-Rekowsky, P. (2012). Appguard-real-time policy enforcement for third-party applications. Universitats- und Landesbibliothek, Postfach 151141, 66041 Saarbracken, Technical Report, Available: http://scidok.sulb.uni-saarland.de/volltexte/2012/4902. Cette bibliographie est identique à celle de l’ouvrage correspondant en anglais publié par ISTE.

214

Cybervigilance et confiance numérique

Bao, T., Zheng, Y., Lin, Z., Zhang, X., and Xu, D. (2010). Strict control dependence and its effect on dynamic information flow analyses. Proceedings of the 19th International Symposium on Software Testing and Analysis. ACM, pp. 13–24. Bell, D.E. and LaPadula, L.J. (1976). Secure computer system: unified exposition and multics interpretation, Technical report, DTIC Document. Available: http://bench.chainfire.eu/. Beres, Y. and Dalton, C. (2003). Dynamic label binding at run-time. Proceedings of the 2003 Workshop on New Security Paradigms. ACM, pp. 39–46. Beresford, A.R., Rice, A., Skehin, N., and Sohan, R. (2011). Mockdroid: trading privacy for application functionality on smartphones. Proceedings of the 12th Workshop on Mobile Computing Systems and Applications. ACM, pp. 49–54. Biba, K.J. (1977). Integrity considerations for secure computer systems, Technical report, DTIC Document. Blasing, T., Batyuk, L., Schmidt, A.-D., Camtepe, S.A., and Albayrak, S. (2010). An android application sandbox system for suspicious software detection. 2010 5th International Conference on Malicious and Unwanted Software (MALWARE). IEEE, pp. 55–62. Brown, J. and Knight Jr, T. (2001). A minimal trusted computing base for dynamically ensuring secure information flow. Project Aries TM-015. Technical report, MIT. Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., and Sadeghi, A.-R. (2011). Xman-droid: a new android evolution to mitigate privilege escalation attacks. Technische Universität Darmstadt, Technical Report TR-2011-04. Burguera, I., Zurutuza, U., and Nadjm-Tehrani, S. (2011). Crowdroid: behaviourbased malware detection system for android. Proceedings of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. ACM, pp. 15–26. Cai, L. and Chen, H. (2011). Touchlogger: inferring keystrokes on touch screen from smartphone motion. HotSec, 11, 9–9. Cavallaro, L., Saxena, P., and Sekar, R. (2007). Anti-taint-analysis: Practical Evasion Techniques Against Information Flow Based Malware Defense. Stony Brook University, Stony Brook, New York. Cavallaro, L., Saxena, P., and Sekar, R. (2008). On the limits of information flow techniques for malware analysis and containment. Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, pp. 143–163.

Aperçu analytique du flux d’informations

215

Cheng, W., Zhao, Q., Yu, B., and Hiroshige, S. (2006). Tainttrace: efficient flow tracing with dynamic binary rewriting. Proceedings. 11th IEEE Symposium on Computers and Communications (ISCC’06). IEEE, pp. 749–754. Chess, B. and McGraw, G. (2004). Static analysis for security. Security & Privacy, IEEE, 2(6), 76–79. Chin, E., Felt, A.P., Greenwood, K., and Wagner, D. (2011). Analyzing interapplication communication in android. Proceedings of the 9th International Conference on Mobile Systems, Applications, and Services. ACM, pp. 239–252. Chow, J., Pfaff, B., Garfinkel, T., Christopher, K., and Rosenblum, M. (2004). Understanding data lifetime via whole system simulation. Proceedings of the 13th Conference on USENIX Security Symposium Volume 13, SSYM’04. USENIX Association, Berkeley, CA, pp. 22–22. Clause, J., Li, W., and Orso, A. (2007). Dytan: a generic dynamic taint analysis framework. Proceedings of the 2007 International Symposium on Software Testing and Analysis. ACM, pp. 196–206. Cole, R. and Waugh, R. (2012). Top ‘free Android apps’ secretly leak users’ private contact listsʼ to advertising companies. Available: http://www.dailymail.co.uk/ sciencetech/article-2110599/. Collberg, C., Thomborson, C., and Low, D. (1997). A taxonomy of obfuscating transformations, Technical report, Department of Computer Science, University of Auckland, New Zealand. Collberg, C., Thomborson, C., and Low, D. (1998). Manufacturing cheap, resilient, and stealthy opaque constructs. Proceedings of the 25th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. ACM, pp. 184–196. Conti, M., Nguyen, V., and Crispo, B. (2011). Crepe: context-related policy enforcement for android. Proceedings of the 13th International Conference on Information Security (Berlin, Heidelberg, 2011), ISC’10, Springer-Verlag, pp. 331–345. Corporation, P.S. (1997). Caffeinemark 3.0. Available: http://www.benchmarkhq. ru/cm30/. Cox, J. (2016). Improved partial instrumentation for dynamic taint analysis in the JVM, PhD thesis, University of California, Los Angeles. Crandall, J.R., Wu, S.F., and Chong, F.T. (2006). Minos: architectural support for protecting control data. ACM Transactions on Architecture and Code Optimization (TACO), 3(4), 359–389.

216

Cybervigilance et confiance numérique

Denning, D. (1975). Secure information flow in computer systems, PhD thesis, Purdue University, Indiana. Denning, D. (1976). A lattice model of secure information flow. Communications of the ACM, 19(5), 236–243. Denning, D. and Denning, P. (1977). Certification of programs for secure information flow. Communications of the ACM, 20(7), 504–513. Desmet, L., Joosen, W., Massacci, F., Philippaerts, P., Piessens, F., Siahaan, I., and Vanoverberghe, D. (2008). Security-by-contract on the net platform. Information Security Technical Report, 13(1), 25–32. Dhavale, S. and Lokhande, B. (2016). Comnoid: information leakage detection using data flow analysis on android devices. International Journal of Computer Applications, 134(7), 15–20. Dietz, M., Shekhar, S., Pisetsky, Y., Shu, A., and Wallach, D.S. (2011). Quire: lightweight provenance for smart phone operating systems. Proceedings of the 20th USENIX Security Symposium, USENIX Security ‘11. USENIX Security Symposium, p. 3. Enck, W., Gilbert, P., Chun, B., Cox, L., Jung, J., McDaniel, P., and Sheth, A. (2010). Taintdroid: an information-flow tracking system for realtime privacy monitoring on smartphones. Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation. USENIX Association, pp. 1–6. Enck, W., Ongtang, M., and McDaniel, P. (2009). On lightweight mobile phone application certification. Proceedings of the 16th ACM Conference on Computer and Communications Security. ACM, pp. 235–245. Enck, W., Octeau, D., McDaniel, P., and Chaudhuri, S. (2011). A study of android application security. Proceedings of the 20th USENIX Security Symposium. USENIX Association, August 2011. USENIX Association, p. 2. Evans, D. and Larochelle, D. (2002). Improving security using extensible lightweight static analysis. Software, IEEE, 19(1), 42–51. Fedler, R., Kulicke, M., and Schütte, J. (2013). Native code execution control for attack mitigation on android. Proceedings of the Third ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. ACM, pp. 15–20. Felt, A.P., Wang, H.J., Moshchuk, A., Hanna, S., and Chin, E. (2011). Permission re-delegation: attacks and defenses. Proceedings of the 20th USENIX Security Symposium. USENIX Security Symposium, pp. 22–37.

Aperçu analytique du flux d’informations

217

Fenton, J. (1973). Information protection systems, PhD thesis, University of Cambridge. Fenton, J. (1974). Memoryless subsystem. Computer Journal, 17(2), 143–147. Ferrante, J., Ottenstein, K.J., and Warren, J.D. (1987). The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems (TOPLAS), 9(3), 319–349. Fragkaki, E., Bauer, L., Jia, L., and Swasey, D. (2012). Modeling and enhancing android’s permission system, ESORICS, pp. 1–18. Fuchs, A.P., Chaudhuri, A., and Foster, J.S. (2009). Scandroid: Automated Security Certification of Android Applications. University of Maryland. Gartner (2016). Gartner says worldwide smartphone sales grew 3.9 percent in first quarter of 2016. Available: http://www.gartner.com/newsroom/id/3323017. Gat, I. and Saal, H. (1975). Memoryless execution: a programmers viewpoint. IBM Israeli Scientific Center, IBM tech. rep. 025. George, L., Viet Triem Tong, V., and Mé, L. (2009). Blare tools: a policy-based intrusion detection system automatically set by the security policy. Recent Advances in Intrusion Detection. Springer, pp. 355–356. Georgiadis, L. and Tarjan, R.E. (2004). Finding dominators revisited. Proceedings of the Fifteenth Annual ACM-SIAM Symposium on Discrete Algorithms. Society for Industrial and Applied Mathematics, pp. 869–878. Gibler, C., Crussell, J., Erickson, J., and Chen, H. (2012). Androidleaks: automatically detecting potential privacy leaks in android applications on a large scale. Trust, 12, 291–307. Gilbert, P., Chun, B.-G., Cox, L.P., and Jung, J. (2011). Vision: automated security validation of mobile apps at app markets. Proceedings of the Second International Workshop on Mobile Cloud Computing and Services. ACM, pp. 21–26. Google (2015). dex2jar. Available: http://code.google.com/p/dex2jar/. Gordon, M.I., Kim, D., Perkins, J.H., Gilham, L., Nguyen, N., and Rinard, M.C. (2015). Information flow analysis of android applications in droidsafe. Proceeding of the Network and Distributed System Security Symposium (NDSS). The Internet Society. NDSS, p. 110. Graa, M., Cuppens-Boulahia, N., Cuppens, F., and Cavalli, A. (2012). Detecting control flow in Smarphones: combining static and dynamic analyses. CSS 2012: The 4th International Symposium on Cyberspace Safety and Security, pp. 33–47.

218

Cybervigilance et confiance numérique

Graa, M., Boulahia, N.C., Cuppens, F., and Cavalliy, A. (2014). Protection against code obfuscation attacks based on control dependencies in android systems. 2014 IEEE Eighth International Conference on Software Security and Reliability-Companion (SERE-C). IEEE, pp. 149–157. Graa, M., Cuppens-Boulahia, N., Cuppens, F., and Lanet, J.-L. (2016). Tracking explicit and control flows in Java and native Android apps code. ICISSP 2016: 2nd International Conference on Information Systems Security and Privacy. ICISSP, pp. 307–316. Graa, M., Cuppens-Boulahia, N., Cuppens, F., Moussaileb, R., and Lanet, J.-L. (2017). Detection of side channel attacks based on data tainting in Android systems. IFIP SEC 2017: 32nd International Conference on ICT Systems Security and Privacy Protection. Vol. 502 IFIPAICT, pp. 1–14. Haldar, V., Chandra, D., and Franz, M. (2005). Dynamic taint propagation for java. 21st Annual Computer Security Applications Conference. IEEE, p. 9. Hauser, C., Tronel, F., Reid, J., and Fidge, C. (2012). A taint marking approach to confidentiality violation detection, Proceedings of the 10th Australasian Information Security Conference (AISC 2012). Vol. 125, Australian Computer Society. Hedman, S. (2004). A First Course in Logic: an Introduction to Model Theory, Proof Theory, Computability, and Complexity. Oxford University Press, Oxford and New York. Heuser, S., Negro, M., Pendyala, P.K., and Sadeghi, A.-R. (2016). Droidauditor: forensic analysis of application-layer privilege escalation attacks on android. Proceedings of the 20th International Conference on Financial Cryptography and Data Security. TU Darmstadt, Springer, pp. 260–268. Hornyack, P., Han, S., Jung, J., Schechter, S., and Wetherall, D. (2011). These aren’t the droids you’re looking for: retrofitting android to protect data from imperious applications. Proceedings of the 18th ACM Conference on Computer and Communications Security. ACM, pp. 639–652. Huang, W., Dong, Y., and Milanova, A. (2014). Type-based taint analysis for java web applications. FASE, pp. 140–154. Hunt, A. and Thomas, D. (2000). Programming Ruby: the Pragmatic Programmer’s Guide. Vol. 2. Addison-Wesley Professional, New York. Jana, S. and Shmatikov, V. (2012). Memento: learning secrets from process footprints. 2012 IEEE Symposium on Security and Privacy. IEEE, pp. 143–157.

Aperçu analytique du flux d’informations

219

Java (2015). Java decompiler. Available: http://jd.benow.ca/. Johnson, R. and Pingali, K. (1993). Dependence-based program analysis, ACM SigPlan Notices. Vol. 28, ACM, pp. 78–89. Kang, M., McCamant, S., Poosankam, P., and Song, D. (2011). Dta++: dynamic taint analysis with targeted control-flow propagation. Proceedings of the 18th Annual Network and Distributed System Security Symposium. San Diego, CA. Kay, A. (2007). Tesseract: an open-source optical character recognition engine. Linux Journal, 2007(159), 2. Kerner, S.M. (2011). Android leaking private info. Available: http://www. esecurityplanet.com/trends/article.php/3938056/AndroidLeaking-Private-Info. Kim, J., Yoon, Y., Yi, K., and Shin, J. (2012). Scandal: static analyzer for detecting privacy leaks in android applications. MoST: Mobile Security Technologies, Chen, H., Koved, L., and Wallach, D.S. (eds). IEEE, Los Alamitos, CA. Kim, Y.-K., Yoon, H.-J., and Lee, M.-H. (2015). Stealthy information leakage from android smartphone through screenshot and ocr. International Conference on Chemical, Material and Food Engineering. Atlantis Press. Klimas, L. (2011). Video shows how htc android phones leak private info. Available: http://www.theblaze.com/stories/2011/10/03/video-shows-how-htc-androidphonesleak-private-info-left-and-right/. Lafortune, E. (2006). Proguard. Available: http://proguard.sourceforge.net. Landi, W. (1992). Undecidability of static analysis. ACM Letters on Programming Languages and Systems (LOPLAS), 1(4), 323–337. Lange, M., Liebergeld, S., Lackorzynski, A., Warg, A., and Peter, M. (2011). L4android: a generic operating system framework for secure smartphones, Proceedings of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices. ACM, pp. 39–50. Lengauer, T. and Tarjan, R.E. (1979). A fast algorithm for finding dominators in a flowgraph. ACM Transactions on Programming Languages and Systems (TOPLAS), 1(1), 121–141. Li, X., Kashyap, V., Oberg, J.K., Tiwari, M., Rajarathinam, V.R., Kastner, R., Sherwood, T., Hardekopf, B., and Chong, F.T. (2014). Sapper: a language for hardware-level security policy enforcement. ACM SIGARCH Computer Architecture News. Vol. 42, ACM, pp. 97–112.

220

Cybervigilance et confiance numérique

Lowry, E.S. and Medlock, C.W. (1969). Object code optimization. Commun. ACM, 12(1), 13–22. Mongiovi, M., Giannone, G., Fornaia, A., Pappalardo, G., and Tramontana, E. (2015). Combining static and dynamic data flow analysis: a hybrid approach for detecting data leaks in java applications. Proceedings of the 30th Annual ACM Symposium on Applied Computing. ACM, pp. 1573–1579. Myers, A. (1999). Jflow: practical mostly-static information flow control. Proceedings of the 26th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. ACM, pp. 228–241. Nair, S., Simpson, P., Crispo, B., and Tanenbaum, A. (2008). A virtual machine based information flow control system for policy enforcement. Electronic Notes in Theoretical Computer Science, 197(1), 3–16. Nauman, M., Khan, S., and Zhang, X. (2010). Apex: extending android permission model and enforcement with user-defined runtime constraints. Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security. ACM, pp. 328–332. Nethercote, N. and Seward, J. (2003). Valgrind: a program supervision framework. Electronic Notes in Theoretical Computer Science, 89(2), 44–66. Newsome, J. and Song, D. (2005). Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software. Proceedings of the 12th Annual Network and Distributed System Security Symposium (NDSS ʼ05). Ongtang, M., McLaughlin, S., Enck, W., and McDaniel, P. (2012). Semantically rich application-centric security in android. Security and Communication Networks, 5(6), 658–673. Portokalidis, G., Homburg, P., Anagnostakis, K., and Bos, H. (2010). Paranoid android: versatile protection for smartphones. Proceedings of the 26th Annual Computer Security Applications Conference. ACM, pp. 347–356. Qian, C., Luo, X., Shao, Y., and Chan, A.T. (2014). On tracking information flows through jni in android applications. 2014 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, pp. 180–191. Qin, F., Wang, C., Li, Z., Kim, H., Zhou, Y., and Wu, Y. (2006). Lift: a lowoverhead practical information flow tracking system for detecting security attacks. Proceedings of the 39th Annual IEEE/ACM International Symposium on Microarchitecture. IEEE Computer Society, pp. 135–148.

Aperçu analytique du flux d’informations

221

Reina, A., Fattori, A., and Cavallaro, L. (2013). A system call-centric analysis and stimulation technique to automatically reconstruct android malware behaviors. Proceeding of the Sixth European Workshop on System Security (EUROSEC). Prague, Czech Republic. Ren, B., Liu, C., Cheng, B., Hong, S., Zhao, S., and Chen, J. (2016). Easyguard: enhanced context-aware adaptive access control system for android platform: poster. Proceedings of the 22nd Annual International Conference on Mobile Computing and Networking. ACM, pp. 458–459. Research, A. (2016). Graphviz. Available: http://www.graphviz.org/. Sabelfeld, A. and Myers, A. (2003). Language-based information-flow security. IEEE Journal on Selected Areas in Communications, 21(1), 5–19. Sarwar, G., Mehani, O., Boreli, R., and Kaafar, D. (2013). On the effectiveness of dynamic taint analysis for protecting against private information leaks on android (SECRYPT). Proceedings of the 10th International Conference on Security and Cryptography, pp. 461–467. Schlegel, R., Zhang, K., Zhou, X.-Y., Intwala, M., Kapadia, A., and Wang, X. (2011). Soundcomber: a stealthy and context-aware sound trojan for smartphones. NDSS, 11, 17–33. Schulz, P. (2012). Code protection in android. Technical report, University of Bonn, Germany. Shabtai, A., Fledel, Y., and Elovici, Y. (2010). Securing android-powered mobile devices using selinux. Security & Privacy, IEEE, 8(3), 36–44. Shankar, U., Talwar, K., Foster, J.S., and Wagner, D. (2001). Detecting format string vulnerabilities with type qualifiers. USENIX Security Symposium, pp. 201–220. Shankar, V.G., Somani, G., Gaur, M.S., Laxmi, V., and Conti, M. (2017). Androtaint: an efficient android malware detection framework using dynamic taint analysis. Asia Security and Privacy (ISEASP), 2017 ISEA. IEEE, pp. 1–13. Smardec (2017). Allatori obfuscator. Available: http://www.allatori.com/doc.html. Song, D., Brumley, D., Yin, H., Caballero, J., Jager, I., Kang, M., Liang, Z., Newsome, J., Poosankam, P., and Saxena, P. (2008). Bitblaze: a new approach to computer security via binary analysis. Information Systems Security, pp. 1–25. Sourceware (2015). Objdump. Available: https://sourceware.org/binutils/docs/binutils/ objdump.html.

222

Cybervigilance et confiance numérique

Spreitzenbarth, M., Freiling, F., Echtler, F., Schreck, T., and Hoffmann, J. (2013). Mobile-sandbox: having a deeper look into android applications. Proceedings of the 28th Annual ACM Symposium on Applied Computing. ACM, pp. 1808–1815. Spreitzenbarth, M., Schreck, T., Echtler, F., Arp, D., and Hoffmann, J. (2015). Mobilesandbox: combining static and dynamic analysis with machine-learning techniques. International Journal of Information Security, 14(2), 141–153. Statistica (2016). Cumulative number of apps downloaded from the Google Play as of May 2016 (in billions). Avaialble: http://www.statista.com/statistics/281106/ number-of-android-app-downloads-from-google-play/. Statistics (2018). Number of available applications in the Google Play Store from December 2009 to December (2018). Available: https://www.statista.com/ statistics/266210/number-of-available-applications-in-the-google-play-store/. Suh, G., Lee, J., Zhang, D., and Devadas, S. (2004). Secure program execution via dynamic information flow tracking. ACM SIGPLAN Notices. Vol. 39, ACM, pp. 85–96. Thanigaivelan, N.K., Nigussie, E., Hakkala, A., Virtanen, S., and Isoaho, J. (2017). Codra: context-based dynamically reconfigurable access control system for android. Journal of Network and Computer Applications, 101(2018), 1–17. Vachharajani, N., Bridges, M.J., Chang, J., Rangan, R., Ottoni, G., Blome, J.A., Reis, G.A., Vachharajani, M., and August, D.I. (2004). Rifle: an architectural framework for user-centric information-flow security. 37th International Symposium on Microarchitecture, 2004. MICRO-37 2004. IEEE, pp. 243–254. Vogt, P., Nentwich, F., Jovanovic, N., Kirda, E., Kruegel, C., and Vigna, G. (2007). Cross site scripting prevention with dynamic data tainting and static analysis. NDSS’07, Vol. 42, Citeseer. Volpano, D. (1999). Safety versus Secrecy. Springer, London, UK. Wall, L. (2000). Programming Perl. 3rd edition, O’Reilly & Associates, Inc., Sebastopol, CA. Wang, C. and Shieh, S.W. (2015). Droit: dynamic alternation of dual-level tainting for malware analysis. Journal of Information Science and Engineering, 31, 111–129. Wiki (2015). Qemu open source processor emulator. Available: http://wiki.qemu. org/Main_Page/.

Aperçu analytique du flux d’informations

223

Wilson, D. (2010). Many android apps send your private information to advertisers. Available: http://news.techeye.net/mobile/many-android-apps-send-your-privateinfor mation-to-advertisers. Wilson, T. (2011). Many android apps leaking private information. Available: http://www.informationweek.com/security/mobile/many-android-appsleakingprivate-inform/231002162. Wroblewski, G. (2002). General method of program code obfuscation (draft), PhD thesis, Citeseer. Xu, R., Saϊdi, H., and Anderson, R. (2012). Aurasium: practical policy enforcement for android applications. Proceedings of the 21st USENIX Security Symposium. USENIX Association, pp. 27–27. Xu, W., Bhatkar, E., and Sekar, R. (2006). Taint-enhanced policy enforcement: a practical approach to defeat a wide range of attacks. 15th USENIX Security Symposium. pp. 121–136. Yan, L.-K. and Yin, H. (2012). Droidscope: seamlessly reconstructing the os and dalvik semantic views for dynamic android malware analysis. USENIX Security Symposium. pp. 569–584. Yang, Z. and Yang, M. (2012). Leakminer: detect information leakage on android with static taint analysis. 2012 Third World Congress on Software Engineering (WCSE). IEEE, pp. 101–104. Yang, Z., Yang, M., Zhang, Y., Gu, G., Ning, P., and Wang, X.S. (2013). Appintent: analyzing sensitive data transmission in android for privacy leakage detection. Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security. ACM, pp. 1043–1054. Yin, H., Song, D., Egele, M., Kruegel, C., and Kirda, E. (2007). Panorama: capturing system-wide information flow for malware detection and analysis. Proceedings of the 14th ACM Conference on Computer and Communications Security. ACM. pp. 116–127. Yip, A., Wang, X., Zeldovich, N., and Kaashoek, M.F. (2009). Improving application security with data flow assertions. Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles. ACM, pp. 291–304. You, W., Liang, B., Shi, W., Wang, P., and Zhang, X. (2017). Taintman: an ART-compatible dynamic taint analysis framework on unmodified and non-rooted android devices. IEEE Transactions on Dependable and Secure Computing. Available: doi.ieeecomputersociety.org/10.1109/TDSC.2017. 2740169.

224

Cybervigilance et confiance numérique

Zhang, X., Edwards, A., and Jaeger, T. (2002). Using cqual for static analysis of authorization hook placement. Proceedings of the 11th USENIX Security Symposium, pp. 33–48. Zhou, Y., Zhang, X., Jiang, X., and Freeh, V. (2011). Taming information-stealing smartphone applications (on android). International Conference on Trust and Trustworthy Computing. Springer, pp. 93–107. Zhou, Y., Wang, Z., Zhou, W., and Jiang, X. (2012). Hey, you, get off of my market: detecting malicious apps in official and alternative android markets. NDSS, pp. 50–52.

Liste des auteurs

Mariem GRAA IMT Atlantique Rennes

Kamel KAROUI INSAT Université de Carthage Tunisie

Wiem TOUNSI Consultante Paris

Reda YAICH IRT SystemX Palaiseau

Index

A

D, F

analyse des risques, 11 dynamique, 139, 143, 146, 150, 151, 153-155, 157-159, 172, 175, 178, 187-189, 196, 197, 201, 207, 212 des données teintées, 154 hybride, 140, 158, 159, 207, 212 attaque d’obfuscation, 141, 185-191, 193, 207-211 des canaux auxiliaires, 139, 141, 153, 196-199, 201-203, 205211, 213 Distributed Denial of Service (DDoS), 119, 120, 134 autorisation, 54, 56, 57, 62, 64, 66, 68, 74, 75, 78, 79, 81, 84, 88

décentralisation, 53, 64, 74 fiabilité, 55 fuite d’informations sensibles, 139142, 145, 147, 150-154, 156, 157, 159, 160, 172, 176, 180-185, 188, 189, 191-194, 198, 200-203, 205, 206, 212

C certificats/certification, 62, 66-68, 76, 77, 80, 81, 85, 87, 89, 91, 93 contrôle d’accès, 53, 54, 56-65, 69, 72, 82, 88, 90 cyberattaques, 119 cybercriminalité, 8, 19

I identifiants, 54, 62, 64, 65-67, 70-75, 77, 78, 80-86, 88-91, 93, 94 indicateurs de compromission (IOC), 4, 15-18, 24, 28, 29, 31, 41-43 interdiction, 62

L, M, N leakage of sensitive information, 192 malware, 3, 4, 6, 7, 9, 15, 16, 20, 24-27, 30-32, 36, 43 menaces impacts, 105, 112, 121 probabilités d’occurrence, 112 négociation, 54, 72-75, 82-86, 88-90, 94

228

Cybervigilance et confiance numérique

O, P obligation, 62, 78, 88 ontologies, 36 permission, 57, 58, 60-64, 88 politiques, 58, 61-66, 68-90, 93, 94 de contrôle d’accès, 57 privacy, 68, 77, 82, 92, 94

R règles, 58, 62, 69, 76, 80, 87, 90, 92 réputation, 29, 32, 33 risque(s), 53, 78, 91 gestion, 2, 36, 38, 108-110, 114, 119

T, U, V threat sharing, 19, 23, 30, 33 under-tainting, 140, 155, 156, 158, 160-163, 166, 169, 172, 183, 191 violation de la confidentialité, 146