Soutenance mémoire
Dans tout projet de conception d’un système d’information, le processus de développement d’applications commence par une première étape fondamentale qui est la spécification des exigences. Les solutions proposées dans ce domaine divisent les exigences logicielles en deux familles : les exigences fonctionnelles et les exigences non fonctionnelles (Glinz, 2005). Si les exigences fonctionnelles décrivent les fonctions que l’application doit accomplir, les exigences non fonctionnelles se concentrent sur la manière dont ses fonctions sont exécutées. La sécurité est considérée comme une exigence non fonctionnelle.
Ces dernières années, l’expansion des réseaux d’une part et l’importance d’autre part de l’information, ont fortement contribué à ce que les exigences de sécurité jouent un rôle clé dans le développement d’applications ainsi que dans l’amélioration de la fiabilité des processus métiers (Firesmith, 2003b). Cependant, les exigences de sécurité ont pendant longtemps été reléguées à la deuxième place comparativement aux exigences fonctionnelles (Matoussi et Laleau, 2008). Dans le même temps, les organisations sont sujettes à de nombreuses attaques. Le bilan a de quoi inquiéter les entrepreneurs. Selon une étude du cabinet de conseil Pricewaterhouse Coopers (PwC) publiée en octobre 2015, le nombre des attaques informatiques contre des sociétés a augmenté de 38% dans le monde en douze mois. La France est plus particulièrement touchée puisque le nombre de ces attaques y a progressé de 51% en un an, avec 21 incidents par jour .
L’estimation des pertes financières imputables à ces incidents a bondi de 28%, soit 3,7 millions d’euros par entreprise en moyenne, selon la même étude. Les exemples des attaques informatiques de la firme Sony en 2014 aux États-Unis d’Amérique où ceux sur le site de Canal Plus en mars 2016 en France démontrent l’augmentation du nombre d’attaques informatiques. Ils montrent aussi que ces incidents proviennent de différentes sources .
En outre, la dépendance croissante des entreprises vis-à-vis de leur système d’information affaiblit leurs processus métiers. Ce qui génère des exigences de sécurité supplémentaires avec une adaptation spécifique à leurs besoins, et une recherche poussée permettant de veiller à la compatibilité avec l’existant, sur tous les plans. À cet effet, l’ingénierie des exigences de sécurité préoccupe depuis longtemps la communauté des chercheurs et suscite un intérêt particulier en raison des pertes causées par des applications mal sécurisées ou du fait que la sécurité n’était pas intégrée dès le début du cycle de développement ou au motif qu’elle était mal spécifiée.
Selon (Van Lamsweerde,2004), il y a trois raisons qui expliquent ce fait. Tout d’abord, les premières phases du développement des logiciels donnent la priorité à l’élaboration des exigences fonctionnelles au détriment des actifs et des exigences non-fonctionnelles telle que la sécurité en vue d’obtenir un produit qui fonctionne en un court laps de temps. La deuxième raison est l’absence d’un mécanisme constructif et efficace pour l’élaboration d’exigences de sécurité d’une manière complète, cohérente et claire. La troisième raison est l’absence d’une approche précise et bien définie qui permet de produire la conception et l’implémentation des exigences de sécurité tout en assurant une prise en charge correcte de toutes les exigences et en permettant une traçabilité des exigences lors des différentes phases de développement.
Les systèmes d’information (SI) actuels doivent faire face à de nombreuses menaces susceptibles d’exploiter les vulnérabilités des actifs, les menaces sont dues soit à des méthodes d’attaques ou à des agents menaçants de violer les critères de sécurité. Les conséquences sont parfois fatales à l’organisation, mais dans tous les cas des séquelles seront visibles à court et longs termes.
Afin de limiter les impacts résultant des vulnérabilités des actifs, une politique de traitement des risques doit être mise en place, ou chaque exigence de sécurité contribue à couvrir un ou plusieurs traitements du risque ciblant le système d’information.
Contributions principales
Les contributions de notre thèse peuvent être résumées comme suit :
1. Uniformisation du vocabulaire utilisé dans le domaine, permettant une exploitation rationnelle avec le même langage par tous les concernés,
2. Construction d’une ontologie du contexte à partir de la norme ISO/CEI 27000 : 2016,
3. Construction d’une ontologie des actifs à partir des normes, standards, référentiels, méthodes d’analyse des risques et des méthodes de sécurité.
4. Mise en œuvre d’un filtrage pour l’extraction d’informations sous forme de langage naturel en exploitant les connaissances qui peuplent les ontologies des actifs et du contexte ,
5. Constitution d’une liste de scénarios de risques possibles pour un SI à partir de notre état de l’art principal,
6. Formalisation d’un scénario de risque,
7. Construction d’une ontologie des risques à partir de l’existant et l’enrichissement à partir des méthodes d’analyse de risques,
8. Mise en œuvre des fiches de caractérisation des concepts de l’ontologie des risques,
9. Extraction des règles de correspondance à partir des bases de connaissances,
10. Construction d’une ontologie des exigences de sécurité à partir de l’existant et l’enrichissement à partir des méthodes d’élicitation des exigences de sécurité,
11. Modélisation du méta modèle de sécurité,
12. Mise en œuvre et la validation de l’approche.
Terminologies primordiales
Contexte
Bien que le mot « contexte » apparaisse à foison dans l’univers de l’informatique, il ne fait pas l’objet d’une définition unanime. Cela est parfaitement compréhensible étant donné qu’il n’existe pas un contexte déterminé par avance. C’est la raison pour laquelle les définitions du contexte sont nombreuses. Parmi elles, on peut citer (GERAM, 1999) : « le contexte dépend des conditions interdépendantes dans lesquelles un événement, une action, etc. a lieu ». Dans la littérature, la définition la plus usitée est due à (Dey and Abowd, 1999) : « le contexte représente toute information qui peut être utilisée pour caractériser la situation d’une entité. Une entité est une personne, un objet ou un endroit considéré comme pertinent pour l’interaction entre un utilisateur et une application, y compris l’application et l’utilisateur ». En d’autres termes, le contexte peut être décrit comme étant constitué d’un ensemble d’attributs ayant un lien avec une finalité pour laquelle le contexte est utilisé. Pour les linguistes et les chercheurs en langage naturel, le contexte a été utilisé pour interpréter le sens des phrases. Par exemple, si nous disons : « Je tiens à jouer avec ma sœur », il est supposé que ma sœur et moi jouons ensemble et non qu’elle est un jouet. Autrement dit, le contexte social rétrécit l’interprétation correcte d’une expression (Leech, 1981). Il est clair que le contexte peut servir à limiter l’espace de la solution pour des problèmes liés au raisonnement automatique (Brézillon and Abu-Hakima, 1995) ou lorsqu’il y a d’énormes quantités de données. À titre d’exemple, les systèmes de recherche Web filtrent l’information en estimant sa pertinence dans des contextes déterminés d’interprétation, telle que la popularité des pages (Yahoo, Google), les catégories (recherches), les zones géographiques (Algérie), etc.…. En général, dans le domaine de l’informatique, le contexte est généralement lié aux conditions dans lesquelles les utilisateurs sont immergés (poste de travail, réseau, communication, bande passante, sécurité). Pour la sécurité des informations, le contexte joue un rôle primordial, qu’il soit un contexte interne ou un contexte externe. Le risque et les mesures de protection changent d’après le contexte. Exemple : on ne protège pas un serveur de banque comme un simple serveur de messagerie d’une petite entreprise de textile.
Actifs
Pour ce concept, l’unanimité de notre état de l’art donne la même définition qui se résume ainsi : « tout élément représentant de la valeur pour l’organisme » (ISO guide 73, 2009). En d’autres termes, toute ressource qu’elle soit une personne, groupe, relation, bâtiment ou instrument à la disposition de l’entreprise ou de l’organisation pour une utilisation dans un rôle opérationnel ou de soutien (Glossary of security, 2012).
La gestion des risques
La gestion des risques correspond aux activités coordonnées permettant d’orienter et de contrôler un organisme en matière de risque (ISO/CEI 27000, 2016). C’est donc le processus par lequel les organisations identifient, analysent et traitent les risques, quelles que soient leurs natures ou leur origine, mais aussi pour contrôler la probabilité des événements redoutés et réduire au minimum l’impact éventuel de ces événements. la gestion des risques joue un rôle prépondérant, car elle permet aux organisations de prendre les décisions les plus adaptées à leurs besoins de sécurité au regard de leurs moyens (Mayer et al, 2008).
|
Table des matières
INTRODUCTION
Chapitre I
I. Introduction générale
I.1 Contributions principales
I.2 Organisation du mémoire
Chapitre II
II. État de l’art
II.1 Définitions
II.1.1Terminologies primordiales
a. Contexte
b. Actifs
c. La gestion des risques
d. Risque
e.Traitements des risques
f. Exigences de sécurité
g. Guidage
II.2 Analyse des risques : normes, standards, référentiels et méthodologies
II.2.1 Les standards de sécurité
AS/NZS 4360
BS7799
IT-Grundschutz
SS627799- 2
II.2.2 Les normes de sécurité
La norme ISO/CEI 27000
La norme ISO/CEI 27001
La norme ISO/CEI 27002
La norme ISO/CEI 27003
La norme ISO/CEI 27004
La norme ISO/CEI 27005
La norme ISO/CEI 27006
La norme ISO/CEI 27007
Le rapport technique ISO/CEI TR 27008
La norme ISO/CEI 27010
La norme ISO/CEI 27011
La norme ISO/CEI 27013
La norme ISO/CEI 27014
Le rapport technique ISO/CEI TR 27015
Le rapport technique ISO/CEI TR 27016
Le rapport technique ISO/CEI TR 27019
La norme ISO/CEI 27031
La norme ISO/CEI 27035
La norme ISO 27799
La norme ISO 31000
Le rapport technique ISO/TR 31004
La norme ISO/CEI 15408
La norme ISO/CEI 17799
ISO Guide 73: 2009
II.2.3 Les référentiels
COBIT 5
ITIL
Risk IT
II.2.4 Les méthodologies d’analyse des risques
La méthode MAGERIT
La méthode NIST
La méthode OCTAVE
La méthode FAIR
La méthode CORAS
La méthode CRAMM
La méthode EBIOS
La méthode FRAP
La méthode MEHARI
La méthode SRA
La méthode TARA
La méthode ISAMM
La méthode FMECA
La méthode HAZOP
La méthode FTA
II.2.5 Les méthodes d’élicitation des exigences de sécurité
La méthode MSRA
La méthode SQUARE
La méthode SIREN
La méthode IRIS
La méthode MOSIS
La méthode Misuse cases
La méthode Abuse case
La méthode SecureUML
La méthode UMLsec
La méthode KAOS
La méthode SECURE I
La méthode SECURE TROPOS
La méthode GBRAM
La méthode Abuse frames
La méthode SEPP
La méthode SREF
La méthode Tropos Goal-Risk Framework
La méthode ISSRM
La méthode CC
La méthode SREP
II.3 Comparaison
Chapitre III
III. Approche de dérivation des exigences de sécurité à partir de l’analyse des risques
III.1 Notre Approche
III.2 Processus de dérivation des plans d’exigences de sécurité
III.3 En quoi c’est différent des autres approches
III.4 Méta modèle de sécurité
III.5 Description détaillée des différentes étapes de l’approche
III.5.1 Construction des ontologies
III 5.1 Construction des ontologies
i) Conception manuelle
ii) Conception reposant sur des apprentissages
La méthode de KACTUS
La méthode METHONTOLOGY
La méthode On-To-Knowledge
La méthode Neon
III.5.2 Scénarios de construction d’ontologie
III 6 Ontologie des actifs
III.6.1 Etat de l’art pour la construction de l’ontologie des actifs
III.6.2 Construction de notre ontologie des actifs
III.6.2.1 Spécification
III 6.2.2 Acquisition des connaissances
III 6.2.3 Construction
a. Premier niveau de l’ontologie
b. Deuxième niveau de l’ontologie
c. Troisième niveau de l’ontologie
III.7 Ontologie du contexte
III.7.1 Etat de l’art pour la construction de l’ontologie du contexte
III.7.2 Construction de notre ontologie du contexte
III.7.1 Spécification
III 7.2 Acquisition des connaissances
III.7.3 Construction
III 7.4 Intégration
III 7.5 Évaluation
III.8 Ontologie des risques et des exigences de sécurité
III 8.1 Construire les ontologies
III 8.1.1 Spécification
III 8.1.2 Acquisition des connaissances
III 8.1.3 Construction
III 8.1.4 Intégration
III 8.1.5 Évaluation
III 8.2 Ontologie des risques
III 8.3 Ontologie des exigences de sécurité
III.9 Description détaillée des différentes étapes de l’approche
Phase 1 : Analyse du contexte
a. Identification et extraction des éléments du contexte et actifs de l’entreprise
b. Détermination des critères de sécurité associés aux actifs de l’entreprise
Phase 2 : Analyse des risques
a. Identification des scénarios de risques
b. Identification des risques
c. Caractérisation des risques
Phase 3 : Dérivation des exigences de sécurité
a. Dérivation des exigences de sécurité
b. Caractérisation des exigences de sécurité
Chapitre IV
IV. Mise en œuvre et validation de l’approche
IV.1 Introduction
IV.2 Validation des relations taxonomiques
IV.3 Validation du processus de guidage
IV.3.1 Cas d’étude académique
Chapitre V
CONCLUSION
