CARACTERISATION DE L’ENVIRONNEMENT DU SYSTEME ET PRESENTATION DE L’APPROCHE

Télécharger le fichier pdf d’un mémoire de fin d’études

Les ITSEC

Les ITSEC sont le résultat de l’harmonisation de travaux réalisés au sein de quatre pays européens : l’Allemagne, la France, les Pays-Bas et le Royaume- Uni [ITS 91]. La différence essentielle que l’on peut noter entre le livre orange et les ITSEC est la distinction entre fonctionnalité et assurance. En effet, les ITSEC définissent un certain nombre de classes de fonctionnalité d’une part et un certain nombre de classes d’assurance d’autre part. Une classe de fonctionnalité décrit les mécanismes qu’un système doit mettre en œuvre pour être évalué à ce niveau de fonctionnalité. Une classe d’assurance permet, elle, de décrire l’ensemble des justifications et preuves qu’un système doit apporter pour montrer qu’il implémente réellement les fonctionnalités qu’il prétend assurer. Les classes d’assurance sont au nombre de six (E1 à E6). Parmi les classes de fonctionnalité, on retrouve les classes (F-C1, F -C2, F- B1, F- B2, F-B3) correspondant aux classes C1 à B3 définies dans les TCSEC.
Les ITSEC utilisent le terme cible d’évaluation (Target Of Evaluation ou TOE). Le contenu d’une TOE comprend : une politique de sécurité, une spécification des fonctions requises dédiées à la sécurité, une définition des mécanismes de sécurité requis et le niveau d’évaluation visé. Les ITSEM (Information Technology Security Evaluation Manual) ont été publiés dans leur première version en 1993. Ils décrivent une méthodologie pour mener les évaluations relatives aux critères ITSEC [ITS 93].

Les Critères Communs

Les CC, harmonisation des CTCPEC, des ITSEC et des TCSEC, contiennent deux parties bien séparées comme les ITSEC : fonctionnalité et assurance. De même que dans les ITSEC, les CC définissent une cible d’évaluation, appelée TOE, qui désigne le système ou le produit à évaluer, et la cible de sécurité, appelée ST (Security Target), qui contient les objectifs de sécurité d’une TOE particulière et qui spécifie les fonctionnalités et les assurances offertes par la TOE afin de remplir ces objectifs. La cible de sécurité pour une TOE représente la base d’entente entre évaluateurs et développeurs. Une cible de sécurité peut contenir les exigences d’un ou de plusieurs profils de protection prédéfinis. Une des différences entre ITSEC et CC réside dans l’existence de ces profils de protection qui avaient auparavant été introduits dans les critères fédéraux des Etats- Unis [FC 92]. Un profil de protection définit un ensemble d’exigences de sécurité et d’objectifs, indépendants d’une quelconque implémentation, pour une catégorie de TOE. L’intérêt des profils de protection est double : 1) un développeur peut inclure dans une cible de sécurité un ou plusieurs profils de protection ; 2) un client désirant utiliser un système ou un produit peut également demander à ce que son système corresponde à un profil de protection particulier, ceci lui évitant de donner une liste exhaustive de fonctionnalités et assurances qu’il exige du système ou du produit. Une partie importante des CC est donc consacrée à la présentation détaillée de profils de protection prédéfinis. Cette notion de profil de protection représente la volonté américaine qui consiste à préférer évaluer des systèmes qui entrent dans le cadre de profils connus. Le cas d’un système ne cadrant pas exactement avec un profil connu conduit simplement à l’élaboration d’un nouveau profil. La tendance européenne serait plutôt de définir systématiquement une TOE et ses exigences de sécurité et d’évaluer cette TOE sans s’appuyer nécessairement sur des profils prédéfinis. Les CC tentent de réaliser un compromis entre ces deux positions.

Les normes ISO

La norme ISO 17799 de sécurité a été publiée dans sa première version en 2000. Une seconde version a été publiée en 2005. Ce document s’adresse tout d’abord aux responsables de la sécurité et aux directions informatiques quel que soit le secteur d’activité. Il a pour but de définir des objectifs et des recommandations à propos de la sécurité des systèmes d’information [CLU 03]. Un premier « code de bonnes pratiques », défini par plusieurs grandes entreprises britanniques (Shell, British Telecom, Midland Bank et Mark&Spencer), sur la base de leur expérience, est à l’origine de cette norme. Ce premier document est publié en 1993 par le British Standard Institute. Plusieurs versions de ce document se succèdent jusqu’au BS 7799:1999, dont la première partie est standardisée en 2000 pour devenir ISO 17799:2000. Elle est révisée par la suite et publiée à nouveau en 2005 sous le nom de ISO 17799:2005. Elle fournit la matière nécessaire à la bonne gestion de la sécurité au sein de l’entreprise en abordant les thématiques suivantes [ISO 00] :
• la politique de sécurité ;
• l’organisation de la sécurité ;
• la classification et le contrôle des biens ;
• la sécurité et les ressources humaines ;
• la sécurité physique ;
• la gestion des opérations et des communications ;
• les contrôles d’accès ;
• le développement et la maintenance des systèmes ;
• la gestion de la continuité d’activité ;
• la conformité et la réglementation interne et externe.
Face aux problèmes de sécurité informatique, de nombreuses entreprises cherchent à obtenir la certification relative à cette norme : en 2005, 25% des entreprises interrogées pour le Security Survey d’Ernst & Young [ERN 05] étaient certifiées ISO 17799 et 30% envisageaient de l’obtenir. Dans un nouveau système de numérotation mis en place récemment, cette norme a rejoint la famille des normes ISO 27000 [ISO 08] (dont la première norme est présentée dans le paragraphe suivant) en étant renommée ISO 27002.
La norme ISO 27001 est issue de la seconde partie de la norme britannique BS 7799 présentée dans le paragraphe précédente. Sa première et unique version sort en 2005. La norme ISO 27001 s’intéresse au Service Général du Système d’Information en permettant des audits internes et une amélioration du système de gestion de la sécurité. En appliquant en permanence des méthodes d’analyse de risque, incorporées dans le modèle de processus PDCA (Planifier – Faire – Vérifier – Agir), elle permet un meilleur cadre de gestion qui rend possible les pratiques de contrôle de la norme ISO 17799:2005.

Les méthodes d’analyses de risques

Il existe de nombreuses méthodes d’analyses de risques, et ce pour de nombreux domaines. Outre le domaine de la sécurité des systèmes d’information que nous abordons ici, les domaines de la santé, de l’alimentaire ou encore les domaines industriels ont recours à des analyses de risques. Bien que ces domaines soient très variés, la démarche générale d’une analyse de risque peut se résumer dans les trois étapes suivantes :
• Identifier les menaces auxquelles devra faire face le système ou l’organisation (quels types d’attaquants, mais aussi quels phénomènes physiques : incendie, inondation, intrusion…) ;
• Identifier les vulnérabilités du système ou de l’organisation face à ces menaces ;
• Estimer les conséquences qui résulteraient de la réalisation des menaces et de l’exploitation des vulnérabilités.
On qualifie de risque un événement redouté auquel sera attribuée une fréquence de réalisation et une conséquence [DAC 94]. Les risques sont donc évalués à partir d’une estimation de la fréquence de réalisation des menaces et des conséquences [ABG 04].
En France, il existe plusieurs méthodes d’analyse de risques dédiées aux systèmes d’information. MARION (Méthodologie d’Analyse de Risques Informatiques Orientés par Niveaux) a été développée en 1980 par l’Assemblée Plénière des Sociétés d’Assurance Incendie et Risque Divers. Sa dernière mise à jour date de 1998. MELISA a été développée pour la Délégation Générale de l’Armement, mais MELISA et MARION étant relativement anciennes, ces deux méthodes ne sont plus très utilisées.
Plus récemment, d’autres méthodes ont été développées. MEHARI (MEthode Harmonisée d’Analyse de Risques), développée par le CLUb de la Sécurité des systèmes d’Information Français en 1995. Cette méthode a été mise à jour en février 2007. La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité), développée par la Direction Centrale pour la Sécurité des Systèmes d’Information, a vu le jour en 1995.
Enfin, plusieurs méthodes d’analyse de risques ont été développées à l’étranger ou dans le secteur français privé. Parmi elles, on retrouve Octave (Operationally Critical Threat, Asset, and Vulnerability Evaluation) développée en 1999 par le Software Engineering Institute (USA) ou encore SCORE.
Nombre de ces méthodes, comme MEHARI9, fournissent des mesures telles que l’impact global d’une attaque. Cependant, ces mesures, sont tantôt appelées quantitatives, tantôt qualitatives. Dans le paragraphe suivant, nous nous interrogeons sur cette terminologie.

Du qualitatif au quantitatif

Les approches d’évaluation de la sécurité par critères permettent une évaluation de la sécurité dès la phase de conception et d’implémentation du système. Elles permettent d’inclure des politiques de sécurité en donnant au concepteur des directives pour assurer certaines propriétés de sécurité. Cependant, les évaluations fournies par les normes ISO et les méthodes d’analyse de risques découlent d’un processus long ne permettant pas une évaluation régulière et un suivi de l’évolution du niveau de sécurité du système. De plus, les mesures résultant de ces évaluations ne permettent pas de comparer des systèmes entre eux ou le même système à deux instants d’évaluation différents. Ces mesures ont été définies comme des mesures qualitatives. Une mesure qualitative ne permet pas de quantifier une distance à un objectif. Pour ces raisons, des études cherchant à étudier la quantification de la sécurité en mode opérationnel ont vu le jour. Cependant, il faut se poser la question suivante : où se situe la frontière entre mesure qualitative et mesure quantitative ? La frontière semble à ce jour toujours un peu floue. En effet, dans [LAP 95], il est défini que, dans le contexte de la sûreté de fonctionnement, une évaluation ordinale était qualifiée de qualitative et une évaluation probabiliste de quantitative, alors que les deux types d’évaluation sont qualifiées de quantitatives dans le contexte de la sécurité. Cependant, les mesures issues des critères ou des normes ISO sont pourtant citées comme étant des mesures qualitatives par de nombreuses approches [DAC 94, ALA 07, WAN 05]. Dans [JAQ 07], l’auteur va même plus loin en affirmant que ce ne sont pas des mesures. La frontière entre les notions de mesure qualitative et mesure quantitative. Associer ces notions à des échelles de mesure, présentées dans la partie 2.1, permet de ne pas laisser d’ambiguïté.
Ainsi, dans ce mémoire, nous nous baserons sur la définition simple qui est qu’une mesure qualitative est une mesure dont les valeurs traduisent l’appartenance à une classe. On peut associer, comme le fait [LAP 95] l’échelle ordinale aux mesures qualitatives. Les mesures se référant aux échelles d’intervalles, de ratio et absolue sont donc des mesures quantitatives. L’échelle nominale, ne permettant pas l’opération de comparaison, n’apparaît pas suffisamment contrainte pour être prise en compte dans notre approche.

Les événements du cycle de vie considérés

Parmi les événements cités par les définitions rencontrées, quels sont ceux qui composent le cycle de vie de la vulnérabilité tel que nous allons l’utiliser ? Notre but est de produire un modèle paramétrable qui soit aussi générique que possible tout en ne dépassant pas un certain degré de complexité.
Une de nos exigences est donc que les étapes du cycle de vie de la vulnérabilité que nous considérons doivent être ordonnées dans le temps pour maintenir des repères temporels aisément utilisables. Cet ordre doit être valide quelque soit la vulnérabilité considérée pour s’adapter au désir de généricité de l’approche. De ces études sur le cycle de vie d’une vulnérabilité, nous pouvons tirer la conclusion que quatre événements sont capitaux pour caractériser le cycle de vie d’une vulnérabilité. Ce sont :
• la découverte de la vulnérabilité ;
• la publication de la vulnérabilité ;
• la publication du correctif de la vulnérabilité ;
• l’apparition du kit d’exploitation.

PRESENTATION DE L’APPROCHE

Nous avons pu remarquer l’importance de la phase d’exploitation de la vulnérabilité, présente dans chacun des travaux que nous avons cités. Cependant, nous avons pu remarquer également que cette phase d’exploitation était considérée à plusieurs moments différents dans les approches décrites. Il apparaît donc que cette phase d’exploitation de la vulnérabilité ne peut pas être datée et ordonnée dans le temps relativement aux autres événements. En effet, la phase d’exploitation peut très bien intervenir dès la vulnérabilité découverte, ou, à l’extrême inverse, bien après la publication du correctif. De plus, il nous apparaît nécessaire d’étudier l’impact de cet événement sur la population des attaquants. Nous choississons donc de décrire cet événement du cycle de vie de la vulnérabilité dans la section consacrée à la population des attaquants (cf partie 3).
Les trois moments de la vie d’une vulnérabilité que sont la découverte, la publication et la publication du correctif sont des instants importants de par l’impact qu’ils ont sur l’état de connaissance de l’existence la vulnérabilité, et comment cette connaissance est susceptible de se propager. Les termes appropriés à ces événements peuvent être soumis à interprétation, c’est pourquoi nous précisons leur sens par les définitions suivantes.

La découverte de la vulnérabilité

Nous définissons la découverte de la vulnérabilité comme l’instant où la vulnérabilité est découverte pour la première fois sachant que 1) la vulnérabilité existe et 2) le composant vulnérable est disponible à l’utilisation. Cette découverte peut être faite par une personne malveillante ou non malveillante. Cet événement traduit l’instant à partir duquel au moins une personne connaît l’existence de la vulnérabilité. Dans [FRE 09], cet événement est défini comme le premier instant où la vulnérabilité est considéré comme étant la source d’un risque potentiel pour la sécurité des systèmes d’information. Cette définition est en accord avec la nôtre.

La publication de la vulnérabilité

Nous avons vu que l’événement de publication de la vulnérabilité semble être un événement central du cycle de vie de la vulnérabilité. Preuve en est que chacun des cycles de vie que nous avons étudiés évoque cet événement quand d’autres ne sont évoqués que par une faible proportion des auteurs (cf. tableau 2.1). De plus, cet événement signifie qu’il est possible à tout un chacun de connaître la vulnérabilité, que l’on soit malveillant ou non. L’occurrence de cet événement possède donc l’avantage majeur de permettre aux utilisateurs et administrateurs de système de se montrer plus vigilants lorsqu’ils ont connaissance de l’existence de la vulnérabilité. La publication peut être considérée comme une forme de pression pour une publication rapide du correctif par le producteur du composant vulnérable [FRE 09].
Cependant, l’événement de publication de la vulnérabilité a aussi la conséquence néfaste de permettre aux attaquants d’avoir connaissance de la vulnérabilité et de mettre à profit cette connaissance pour perpétrer des attaques en l’exploitant.
Ces deux conséquences donnent une dimension particulière au phénomène de publication de la vulnérabilité. Il arrive ainsi que les producteurs du composant vulnérable cherchent à retarder le plus possible la publication de la vulnérabilité afin d’écourter le plus possible le laps de temps entre la publication de la vulnérabilité et la mise à disposition du correctif.
Par ces conséquences importantes, l’événement de publication de la vulnérabilité représente donc un événement déterminant dans le cycle de vie de la vulnérabilité. D’après [FRE 09], il peut se définir comme le premier instant où il existe une information validée à propos de la vulnérabilité qui soit accessible au public. Nous adhérons à cette définition et spécifions les caractéristiques suivantes :
• l’information sur la vulnérabilité est disponible librement ;
• l’information sur la vulnérabilité est publiées par une source reconnue large ;
• la vulnérabilité a fait l’objet d’une analyse par des experts.
Cette définition se distingue de celle énoncée dans [FRE 09] car nous n’exigeons pas que la source soit indépendante et l’analyse des experts n’a pas nécessairement besoin d’avoir fait l’objet d’une évaluatin du niveau de risques de la vulnérabilité. En effet, les sites des producteurs des composants vulnérables semblent également être une source correcte pour la publication de vulnérabilités. Par exemple une société comme Microsoft diffuse de façon régulière (le premier mardi du mois) les correctifs liés aux vulnérabilités de son système d’exploitation et des logiciels qu’elle propose.
Il représente donc l’instant de publication officielle de la vulnérabilité par le producteur du composant vulnérable ou par un centre d’alerte et de recensement de vulnérabilités comme CVE [CVE].

La publication du correctif de la vulnérabilité

Enfin, l’événement de publication du correctif de la vulnérabilité a lieu lorsque ce dernier 1) existe et 2) est disponible et accessible par tous les utilisateurs via les sources considérées pour la publication de la vulnérabilité. L’événement de publication du correctif peut avoir lieu de manière simultanée avec l’événement de publication de la vulnérabilité. Dès lors que le correctif est disponible, l’administrateur a la possibilité de supprimer ou masquer la vulnérabilité du composant vulnérable de son système.
Ces trois événements sont donc incontournables. Etudions maintenant les autres événements évoqués par certaines des approches existantes.
découverte de publication de publication
la vulnérabilité la vulnérabilité du correctif
La naissance de la vulnérabilité est également un élément important, évoqué par la majorité des approches. Cependant, plus que l’événement de naissance de la vulnérabilité, il apparaît comme important le fait qu’elle existe.
Certains événements sont abordés par les définitions de cycle de vie de la vulnérabilité que nous avons évoquées, tels que la notion de connaissance d’une vulnérabilité par le grand public. Il est difficile de quantifier cet événement et de savoir quand il a lieu : quelle proportion de la population faut- il considérer pour pouvoir considérer que la vulnérabilité est connue du grand public ? Il apparaît difficile de quantifier cette notion dans le temps. De plus, une vulnérabilité est connue du grand public lorsque le phénomène d’attaque qui lui est lié devient important. Nous ne considérons donc pas cette phase comme pertinente dans le cadre que nous considérons.
Il en est de même pour les événements associés au correctif décrits dans l’approche de [FIS 03], ainsi que pour le phénomène de mort de la vulnérabilité [ARB 00, JON 07]. De plus cet événement de mort de la vulnérabilité ne nous paraît pas pertinent pour notre approche : en effet, comment affirmer qu’une vulnérabilité n’existe plus si on considère plus qu’un système unique ? Cela signifie qu’il n’existe plus aucun composant affecté par cette vulnérabilité. Il semble difficile de pouvoir affirmer l’occurrence d’un tel événement autant que d’en définir l’instant d’occurrence.
Enfin, le phénomène de redécouverte de la vulnérabilité décrit dans [FIS 03] n’est pas une étape obligatoire de cycle de vie de la vulnérabilité. Pour cette raison, nous n’en tenons pas compte. Notre cycle de vie de la vulnérabilité comporte donc trois événements distincts et ordonnés dans le temps, comme illustré sur la figure 2.2.

La population des attaquants

Caractérisation et influence sur le système

La population des attaquants est le deuxième facteur environnemental que nous considérons. Cependant, qui sont ces attaquants et comment pouvons-nous caractériser leurs actions et leur comportement ? La population des attaquants n’est pas homogène. Dans [CER 05, ROG 06], les auteurs proposent une classification à deux dimensions des attaquants en tenant compte de leur motivation et de leur degré de compétence. Les motivations d’un attaquant à vouloir exploiter une vulnérabilité peuvent être très diverses. Plusieurs motivations possibles sont évoquées dans les profils définis dans [CER 05] :
• Le jeu ou le défi : la recherche de performance ;
• La vengeance ;
• Le vol à des fins spéculatives : on peut considérer soit le vol de fonds financiers, soit le vol d’informations confidentielles à des fins de vente à la concurrence ou de chantage.
Ces différentes motivations sont incluses dans les sept classes d’attaquants définies, mais peuvent être considérées uniquement sur une échelle nominale. De plus, l’auteur ne fournit pas la proportion d’attaquants associée à chaque classe. Cela ne permet pas de prendre en considération une ou plusieurs classes majoritaires dans la population des attaquants, ni de considérer une des motivations évoquées comme une caractéristique exploitable et évaluable quantitativement.
Les approches décrites dans [DAC 96, MCQ 06] se concentrent davantage sur les compétences de l’attaquant en considérant un degré qualitatif de compétence ou en le reliant au nombre de vulnérabilités que celui-ci sait exploiter. Dans ces deux approches, chaque classe d’attaquant est considérée séparément : la proportion de chaque classe de populations d’attaquants n’a donc pas besoin d’être évaluée.
Enfin, dans [ALA 07], l’auteur ne considère que deux catégories d’attaquants : les script kiddies et les black hats. Les premiers sont décrits comme des attaquants novices, utilisant des kits d’exploitation disponibles dans la communauté. Les seconds sont des experts qui mettent au point les outils utilisés par les premiers.
Nous appelons « kit d’exploitation » ce qui permet à un attaquant d’exploiter une vulnérabilité sans avoir « besoin de comprendre » ce qu’il fait. Nous citons par exemple les méthodes dites « recettes de cuisine » qui expliquent pas à pas les commandes à taper par l’attaquant, les scripts prêts à exécuter, les outils, etc. Cette notion correspond à celle évoquée par le terme anglais exploit. D’après les observations obtenues par l’étude décrite dans [ALA 07], il apparaît que les attaquants novices (script kiddies) sont considérablement plus nombreux que les experts (black hats). Ces attaquants novices ont besoin de posséder le kit d’exploitation pour pouvoir exploiter la vulnérabilité associée. L’existence de ce kit d’exploitation va donc avoir une influence importante sur le nombre d’attaquants susceptibles d’exploiter la vulnérabilité. Cette observation est validée par les données fournies par [RAM 07]. Dans cet article, les auteurs comparent les données récoltées par le projet Leurré.com [LEU] aux dates de parution du kit d’exploitation sous la forme des plugins d’attaque de l’outil metasploit 12 [MET]. Ils constatent une augmentation très importante des attaques exploitant une certaine vulnérabilité aux instants précédant et suivant l’apparition du plugin contenant le script d’attaque de l’outil metasploit. Cette étude met donc en évidence l’importance du phénomène d’attaque utilisant un kit d’exploitation. Mais elle met également en évidence le nombre très faible d’attaques avant la parution du kit d’exploitation.
Ce résultat illustre l’utilisation importante de ces kits d’exploitation sans lesquels de nombreux attaquants n’auraient sans doute pas les compétences nécessaires pour exploiter la vulnérabilités. Cette conclusion semble cohérente avec les résultats de l’étude détaillée dans [ALA 07] qui met en avant la très forte proportion d’attaquants novices par rapport aux attaquants experts.
Ces études mettent donc en avant l’importance de l’événement de mise au point d’un kit d’exploitation par la population d’attaquants. Cette parution du kit d’exploitation permet aux nombreux attaquants novices d’exploiter la vulnérabilité sans parfois même avoir à comprendre l’attaque elle-même. Il est donc capital de prendre cet événement en considération car il implique une augmentation très significative du nombre d’attaques, jusqu’alors là issues d’attaquants experts et qui peut être en comparaison négligeable.
Pouvoir caractériser plus en détail le comportement de la population d’attaquants permettrait de considérer d’autres paramètres permettant ainsi d’affiner les mesures quantitatives que nous tentons de mettre au point. Cependant, les données restent peu nombreuses, dues à la difficulté d’observer cette population.

Table des matières

INTRODUCTION
CHAPITRE 1 : HISTORIQUE DES MESURES DANS LE DOMAINE DE LA SECURITE
1 LA SECURITE-IMMUNITE
1.1 La sûreté de fonctionnement : concepts et définitions
1.1.1 Définition de base et attributs
1.1.2 Notions de faute, erreur et défaillance
1.1.3 Les moyens pour la sûreté de fonctionnement
1.1.4 Le concept de résilience
1.2 La sécurité : le domaine des malveillances
1.2.1 Les attributs de la sécurité
1.2.2 Terminologie dans le domaine de la sécurité
1.2.3 Les moyens pour la sécurité
1.2.4 La prévention des fautes
2 EVALUATION DE LA SECURITE
2.1 Sens de la mesure
2.2 Premiers besoins, premières approches : l’évaluation qualitative
2.2.1 CC et normes ISO
2.2.2 Les méthodes d’analyses de risques
2.2.3 Du qualitatif au quantitatif
2.3 Méthodes d’évaluation en mode opérationnel
2.3.1 Les évaluations expérimentales
2.3.2 Les évaluations basées sur des modèles
2.4 Conclusion
CHAPITRE 2 : CARACTERISATION DE L’ENVIRONNEMENT DU SYSTEME ET PRESENTATION DE L’APPROCHE
1 CADRE DE L’APPROCHE : LES TYPES DE VULNERABILITES
1.1 Définition de la vulnérabilité : rappels et analyse
1.2 Cadre choisi
2 LE CYCLE DE VIE DE LA VULNERABILITE
2.1 Définitions et études existantes
2.2 Les événements du cycle de vie considérés
2.2.1 La découverte de la vulnérabilité
2.2.2 La publication de la vulnérabilité
2.2.3 La publication du correctif de la vulnérabilité
3 LA POPULATION DES ATTAQUANTS
3.1 Caractérisation et influence sur le système
3.2 Interdépendance avec le cycle de vie – Scénarios de fonctionnement
3.3 L’existence de l’événement de « proof of concept »
4 LE COMPORTEMENT DE L’ADMINISTRATEUR
4.1 Intérêt
4.2 Choix comme paramètre d’étude
4.3 Actions de l’administrateur
4.4 Etudes existantes et quantification
4.5 Influences mutuelles entre facteurs environnementaux
5 MESURE DE LA ZONE DE HAUT RISQUE : UNE PREMIERE MESURE SIMPLE
6 DEFINITION DES MESURES ENVISAGEES
6.1 Choix de mesures déterministes ou probabilistes
6.2 Définition des mesures
6.2.1 Probabilité d’être dans un état compromis : PPC(t)
6.2.2 Probabilité de compromission : PC(t)
6.2.3 Probabilité de compromission non réparée : PCNR(t)
6.2.4 Probabilité de système sûr : PS(t)
7 CONCLUSION
CHAPITRE 3 : MODELISATION ET PRINCIPE DE MESURE
1 CHOIX DE L’APPROCHE : UNE VULNERABILITE PAR MODELE
2 CHOIX DE REPRESENTATION
2.1 Description des besoins et choix du formalisme
2.2 Rappel et description du formalisme des SAN
3 MODELISATION DU PROCESSUS D’EXPLOITATION D’UNE VULNERABILITE
3.1 Le cycle de vie de la vulnérabilité
3.2 La modélisation du comportement de l’attaquant
3.3 Modélisation des interdépendances entre cycle de vie et comportement de l’attaquant
3.3.1 Scénario de découverte non malveillante
3.3.2 Scénario de découverte malveillante
3.4 Modélisation de l’état du système et de l’action de l’administrateur
3.4.1 Description des états fondamentaux
3.4.2 Détail de la modélisation
3.5 Modélisation des deux scénarios
4 DEFINITION DES MESURES DANS LE CADRE DU MODELE
5 VALIDATION ET RESOLUTION
5.1 Premières étapes du fonctionnement de l’outil Möbius
5.1.1 L’éditeur du modèle
5.1.2 Le processus de mesure
5.2 Premières simulations
5.2.1 Choix de la vulnérabilité
5.2.2 Paramètres du modèle
5.2.3 Préparation des simulations
5.2.4 Résultats et analyses
5.2.5 Rapport entre coût et maintien du niveau de sécurité
6 CONCLUSION
CHAPITRE 4 : CARACTERISATION DES EVENEMENTS ET EXPERIMENTATIONS
1 CARACTERISATION DES EVENEMENTS
1.1 Caractérisation des événements du cycle de vie et de la mise au point du kit D’exploitation
1.1.1 Approches pour la caractérisation des événements du cycle de vie
1.1.2 Caractérisation des événements par l’analyse d’une base de données
1.2 Conclusion de l’étude des vulnérabilités
2 EXPERIMENTATIONS
2.1 Préparation du paramétrage
2.1.1 Paramétrage du cycle de vie et de l’apparition du kit d’exploitation
2.1.2 Paramétrage des actions sur le système
2.1.3 Résultats
3 CONCLUSION
CHAPITRE 5 : EXTENSION DU MODELE A PLUSIEURS VULNERABILITES
1 EXTENSION POUR PLUSIEURS VULNERABILITES
1.1 Etude de l’apparition des nouvelles vulnérabilités
1.2 Les interactions entre actions sur le système
1.2.1 L’influence d’une compromission du système
1.2.2 L’influence de l’application d’un correctif
2 EXPERIMENTATIONS
2.1 Présentation de la simulation
2.1.1 Paramétrage de la vulnérabilité de degré de gravité C3
2.1.2 Paramétrage de la vulnérabilité de degré de gravité C2
2.2 Résultats des simulations
2.2.1 Evolution de l’état du système dans le modèle de processus d’exploitation de vulnérabilité de degré de gravité C3
2.2.2 Evolution de l’état du système dans le modèle de processus d’exploitation de vulnérabilité de degré de gravité C2
3 CONCLUSION
CONCLUSION
BIBLIOGRAPHIE

Télécharger le rapport complet