La méthode EBIOS Expression des Besoins et Identification des Objectifs de Sécurité Bonjour Présentation méthode de gestion des risques informatiques.

Présentation au sujet: "La méthode EBIOS Expression des Besoins et Identification des Objectifs de Sécurité Bonjour Présentation méthode de gestion des risques informatiques."— Transcription de la présentation:

1 La méthode EBIOS Expression des Besoins et Identification des Objectifs de Sécurité
Bonjour Présentation méthode de gestion des risques informatiques baptisée « EBIOS » Signifie « Epression des Besoins et Identification des Objectifs de Sécurité » Exposé réalisé en commun par un groupe de 9 étudiants Trois étudiants viendront tour à tour présenter le résultat de l’étude (X, Y et Z) Ingénieurs 2000 – ULMV – IR3 – 21/01/2007 L. Andriet – F. Bidet – I. Boelle – V. Boistuaud A. Bruneau – J. Dastugue – M. Douis – F. Fraux – J. Herr

2 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d'apprécier et de traiter les risques relatifs à la sécurité des systèmes d'information (SSI). Elle permet aussi de communiquer à leur sujet au sein de l'organisme et vis-à-vis de ses partenaires afin de contribuer au processus de gestion des risques SSI.

3 Origines d’EBIOS Part d’une initiative Gouvernementale
Rédigée par la DCSSI Recommandé/Imposé par la SGDN Prévenir les risques informatiques Eviter les pertes financières Garantir la continuité des activités Protéger les informations Protéger contre les attaques Assurer le respect des lois et règlements Qui l’a créée ? DCSSI => Direction Central des Services de Sécurité Informatique ? Dans sa mission d'assistance à la maîtrise d'ouvrage, la DCSSI développe et met en oeuvre la méthode EBIOS®. Elle recommande ainsi le logiciel EBIOS® qui facilite la mise en oeuvre des analyses de risques SSI. La DCSSI reste également à la disposition des utilisateurs pour tout autre conseil de mise en oeuvre. SGDN => Secrétariat Général à la Défense Nationale Objectif premier est de prévenir les risques liés à l’informatique et aux Systèmes d’Informations

4 Une méthode… Modulaire Détermination et prévention des risques
S’adapte à tout SI quel que soit sa taille Compétences acquises au fil du temps Se réalise en 4 étapes + résultat Détermination et prévention des risques Détermination des besoins spécifiques Détection des risques potentiels Obtention d’un plan d’action Simplifie les communications inter services Le plan d’action définit les relations C’est une méthode modulaire qui peut s’appliquer quelle que soit la taille du SI étudié (une application, un SI interne d’entreprise, ou le SI complet d’une entreprise). Pas obligé d’acquérir toutes les compétences dès le début (permet évolutions et applications dans petites entreprises) Elle permet de prévenir les risques informatiques, en cernant les besoins, les dangers, et en participant à la rédaction d’un plan permettant de prévenir les risques réels par rapport aux enjeux. Permet de simplifier les relations inter services, on ne perd pas de temps, on sait qui fait quoi

5 … pour les entreprises Toute entreprise possédant/concevant un S.I.
Taux important d’adoption dans le public CNAM (Assurance Maladie) France Telecom GIE Carte Bleue Ministères (presque tous) Imposé pour certains traitement Données classifiées défense Libre d’utilisation dans les autres cas Toute entreprise possédant un Système d’Information est concernée. Utilisé par de nombreux organismes gouvernementaux ou non, mais essentiellement gouvernemental. Tout SI manipulant des données classées défense nationale sont obligés de l’utiliser. A noter aussi, de nombreux prestataires proposent leurs services dans ce domaine (Alcatel CIT, Thales Security Systems…) Chaque entreprise peut être libre de l’appliquer ou non, si cela répond à ses besoins. Globalement le taux d’adoption est faible en entreprise autre que dans le secteur public.

6 … clairement définie … Mise en œuvre encadrée
Principes généraux de la méthode Guides des meilleures pratiques Outil d’aide à la mise en œuvre Possibilité de contacter un consultant

7 … avec un vocabulaire uniforme
Bien ressource ayant une valeur pour l’organisme Entité un bien de type organisation, site, personnel, matériel, réseau, logiciel, système Element essentiel Information ou fonction ayant un besoin de sécurité non nul Elément menaçant Action ou élément ayant des conséquences négatives

8 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode

9 Les étapes directrices
L’étude du contexte L’expression des besoins de sécurité L’étude des menaces L’expression des objectifs de sécurité La détermination des exigences de sécurité L’étude du contexte Un SI repose sur des éléments essentiels. Ces éléments sont liés à un ensemble d’entités de différents types : matériels, logiciels, réseaux, organisations, personnels et sites. L’expression des besoins de sécurité Chaque élément essentiel a un besoin de sécurité. Ce besoin s’exprime selon différents critères tels que la disponibilité, l’intégrité et la confidentialité. L’étude des menaces Par ailleurs, chaque organisme est exposé à diverses menaces, de par son environnement naturel, sa culture, son image, son domaine... Chaque entité possède des vulnérabilités qui pourront être exploitées par les éléments menaçants selon chaque méthode d’attaque. L’expression des objectifs de sécurité Un élément menaçant peut affecter des éléments essentiels en exploitant les vulnérabilités des entités sur lesquelles ils reposent avec une méthode d’attaque particulière. Les objectifs de sécurité consistent à couvrir les vulnérabilités. La détermination des exigences de sécurité L’équipe de mise en oeuvre de la démarche doit spécifier les fonctionnalités de sécurité attendues. Elle démontre la couverture des objectifs par ces exigences fonctionnelles. Elle doit enfin spécifier les exigences d’assurance qui permettent d’obtenir le niveau de confiance requis, pour le démontrer.

10 La démarche globale EBIOS fournit une méthode permettant de construire une politique de sécurité en fonction d'une analyse des risques qui repose sur le contexte de l'entreprise et des vulnérabilités liées à son SI. La démarche est donc commune à tous, mais les résultats de chaque étape sont personnalisés en fonction du contexte ciblé.

11 Étape 1 L’étude du contexte Objectif : cibler le système d’information
Plusieurs étapes : L'étude du contexte permet d'identifier quel SI est la cible de l'étude. Cette étape délimite le périmètre de l'étude : La présentation de l'entreprise, L’ architecture du SI, Les contraintes techniques et réglementaires, Les enjeux commerciaux. Mais est aussi étudié le détail des équipements, des logiciels et de l'organisation humaine de l'entreprise. Cette étape se compose de trois sous-étapes : l’Etude de l’organisme : présentation de l'entreprise, Étude détaillée de l’organisation humaine de l’entreprise, enjeux commerciaux. L’Etude du système cible technique et fonctionnelle : architecture du système d'information, Etude détaillée des équipements et logiciels. La détermination de la cible de l’étude de sécurité : contraintes techniques et réglementaires,

12 Étape 2 L’expression des besoins de sécurité
Estime les critères de risque Détermine les critères de risque L'expression des besoins de sécurité permet d'estimer les risques et de définir les critères de risque. Les utilisateurs du SI expriment durant cette étape leurs besoins de sécurité en fonction des impacts qu'ils jugent inacceptables. Si les besoins ne sont pas respectés, l’organisme en sera impacté. Cet impact peut revêtir différentes formes : pertes financières, atteinte au bon déroulement des activités, atteinte à l’image de marque, atteinte à la sécurité des personnels, atteinte à la sécurité des données, pollution (impact environnemental) ...

13 Étape 3 L’étude des menaces
Défini les risques en fonction de l’architecture technique du système d’information Une menace peut être caractérisée selon son type (naturel, humain ou environnemental) et selon sa cause (accidentelle ou délibérée). Elle peut employer diverses méthodes d’attaque qu’il convient alors d’identifier. Une méthode d’attaque est caractérisée par les critères de sécurité (disponibilité, intégrité, confidentialité...) qu’elle peut affecter et par les éléments menaçants susceptibles de l’utiliser. Chaque entité possède des vulnérabilités qui pourront être exploitées par les éléments menaçants selon chaque méthode d’attaque. L'étude des menaces permet d'identifier les risques en fonction non plus des besoins des utilisateurs mais en fonction de l'architecture technique du système d'information. Ainsi la liste des vulnérabilités et des types d'attaques est dressée en fonction des matériels, de l'architecture réseau et des logiciels employés. Et ce, quelles que soient leur origine (humaine, matérielle, environnementale) et leur cause (accidentelle, délibérée).

14 Activité 3.1 – Etude des origines des menaces
Pré-requis : 1.2 Entrée Liste des enjeux du système-cible Actions Lister les méthodes d'attaque pertinentes Caractériser les méthodes d'attaque et les éléments menaçants Ajouter une valeur représentant le potentiel d'attaque de l'élément menaçant Sortie Liste des origines des menaces (méthodes d'attaque et éléments menaçants) Liste des méthodes d'attaque non retenues et justifications But: Sélectionner les méthodes d’attaque qui sont pertinentes pour le système cible -> IDENTIFICATION DES SOURCES Recensées par un expert sécurité Lister les méthodes d’attaques: utiliser le guide « Outillage pour l'appréciation des risques SSI  » Chaque méthode d’attaque caractérisée par les critères de sécurité qu’elles peuvent affecter - disponibilité (information disponible) - intégrité (information non modifiée) - confidentialité (information sûr) Et associées à des éléments menaçants de type NATUREL, HUMAIN ou ENVIRONNEMENTAL et ACCIDENTEL ou DELIBEREE Méthodes d’attaques: -> Sinistres physiques (dégâts des eaux, incendie… ) -> Pertes de service essentiels(climatisation, alimentation) -> Pannes, Actions illicites (matériel, logiciel, altération des données) -> Compromissions des informations: espionnage à distance, écoute passive, informations sans garantie de l’origine -> potentiel d’attaque pour chaque élément pour faciliter la détermination de la résistance des mécanismes pour les objectifs et exigences de sécurité

15 Activité 3.2 – Étude des vulnérabilités
Pré-requis : 1.3 et 3.1 Entrée Liste des entités Liste des origines des menaces (méthodes d'attaque et éléments menaçants) Actions Identifier les vulnérabilités des entités selon les méthodes d'attaque Estimer éventuellement le niveau des vulnérabilités Sortie Liste des vulnérabilités retenues et de leur niveau Identifier les vulnérabilités pour chaque entité par rapport aux méthodes d’attaques: utiliser le guide « Outillage pour l'appréciation des risques SSI  » Recensées par un expert sécurité - entités matériels: Absence de protection contre les perturbations électriques fragilités absence d’inventaire le matériel est connecté à des réseaux externes - logiciels: absence de dispositif de protège écran en cas d’inactivité pas ou peu de mot de passe d’accès au système ou à l’application possibilité d’ajout d’un logiciel d’écoute type cheval de Troie consommation inutile des ressources - réseau: les équipements sont accessibles à tous les équipements sont connectés à des réseaux externes - personnel: méconnaissance des mesures de sécurité obtention d’un avantage à la divulgation d’information, à la revente d’un matériel absence de soutien de la direction à l’application de la politique de sécurité - site: proximité d’une source de rayonnements électromagnétiques site placé dans une zone inondable … - système (circulation en clair des informations, le dispositif permet le téléchargement…)

16 Activité 3.3 – Formalisation des menaces
Pré-requis : 3.1 et 3.2 Entrée Liste des origines des menaces (méthodes d'attaque et éléments menaçants) Liste des vulnérabilités retenues et de leur niveau Actions Formuler explicitement les menaces Hiérarchiser éventuellement les menaces selon leur opportunité Sortie Liste des menaces retenues Association entre les méthodes d’attaques et les vulnérabilités pour déterminer les menaces pouvant affecter le système-cible. A la fin -> vision exhaustive des menaces réelles pesant sur le système Opportunité -> selon le niveau des vulnérabilités exploitées par les éléments menaçants

17 Étape 4 L’expression des objectifs de sécurité
Mettre en évidence les risques contre lesquels le SI doit être protégé L'identification des objectifs de sécurité confronte les besoins de sécurité exprimés et les menaces identifiées afin de mettre en évidence les risques contre lesquels le SI doit être protégé. Ces objectifs vont former un cahier des charges de sécurité qui traduira le choix fait sur le niveau de résistance aux menaces en fonction des exigences de sécurité. Un élément menaçant peut affecter des éléments essentiels en exploitant les vulnérabilités des entités sur lesquelles ils reposent avec une méthode d’attaque particulière. Les objectifs de sécurité consistent à couvrir les vulnérabilités. Il est inutile de protéger ce qui n’est pas exposé. On note aussi que plus le potentiel d’attaque est important et plus le niveau des objectifs de sécurité sera important.

18 Activité 4.1 – Confrontation des menaces aux besoins
Pré-requis : 1.3, 2.2 et 3.3 Entrée Tableau entités / éléments Fiche de synthèse des besoins de sécurité Liste des menaces retenues Actions Déterminer les risques (menaces versus besoin de sécurité) Formuler explicitement les risques Hiérarchiser les risques (impacts sur éléments essentiels / opportunité des menaces) Mettre en évidence les risques non retenus Sortie Liste hiérarchisée des risques Liste des risques résiduels

19 Activité 4.2 – Formalisation des objectifs de sécurité
Pré-requis : 1.1, 1.2, 2.4 et 4.1 Entrée Liste des hypothèses, des règles de sécurité, des contraintes, des références réglementaires Choix du mode d’exploitation de sécurité Liste hiérarchisée des risques Actions Lister les objectifs de sécurité Justifier la complétude de la couverture, des hypothèses, des règles de sécurité Mettre en évidence les défauts de couvertures Sortie Liste des objectifs de sécurité Liste des risques résiduels

20 Activité 4.3 – Détermination des niveaux de sécurité
Pré-requis : 3.3 et 4.2 Entrée Liste des objectifs de sécurité Liste des menaces retenues Actions Déterminer le niveau de résistance adéquat pour chaque objectif de sécurité Choisir le niveau des exigences d'assurance Sortie Liste des objectifs de sécurité avec le niveau de résistance Liste des risques résiduels Choix du niveau des exigences d'assurance

21 Étape 5 La détermination des exigences de sécurité
Détermine les limites en termes d’exigences de sécurité. La détermination des exigences de sécurité permet de déterminer jusqu'où on devra aller dans les exigences de sécurité. Il est évident qu'une entreprise ne peut faire face à tout type de risques, certains doivent être acceptés afin que le coût de la protection ne soit pas exhorbitant. C'est notamment la stratégie de gestion du risque tel que cela est défini dans un plan de risque qui sera déterminé ici : accepter, réduire ou refuser un risque. Cette stratégie est décidée en fonction du coût des conséquences du risque et de sa probabilité de survenue. La justification argumentée de ces exigences donne l'assurance d'une juste évaluation.

22 Activité 5.1 – Détermination des exigences de sécurité fonctionnelles
Pré-requis : 4.3 Entrée Liste des objectifs de sécurité avec le niveau de résistance Actions Lister les exigences de sécurité fonctionnelles Justifier la complétude de la couverture des objectifs de sécurité Mettre en évidence les éventuels défauts de couverture Classer les exigences de sécurité fonctionnelles (système-cible / l'environnement du système-cible) Sortie Liste des exigences de sécurité fonctionnelles justifiées Liste des risques résiduels

23 Activité 5.2 – Détermination des exigences de sécurité d'assurance
Pré-requis : 4.3 Entrée Choix du niveau des exigences d'assurance Actions Lister les exigences de sécurité d’assurance Liste des risques résiduels Sortie Liste des exigences de sécurité d’assurance

24 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode

25 Exemple de bonnes pratiques
Conception d’un nouveau SI SI : Ensemble de logiciels, matériels, personnels, locaux Intérêts de EBIOS: Plan de travail: conception, validation Adéquation des ressources aux besoins Politique de sécurité claire et réaliste

26 Concevoir un SI Plan de travail Étape 1: Étude du contexte
Étude de la politique de sécurité Basée sur le référentiel de l’organisme Sous la responsabilité du MO validée par le plus haut niveau hiérarchique Étude du système cible (spécifications) Corrigée lorsque les spécifications évoluent

27 Concevoir un SI Étape 2: Expression des besoins de sécurité
Rédaction et synthèse des besoins Basée sur l’étude de l’étape 1 En partenariat entre MO, décideurs et utilisateurs Étape 3: Étude des menaces Étude des menaces particulières Sous la responsabilité du MO Validée par le plus haut niveau hiérarchique Étude des vulnérabilités Corrigée lorsque les spécifications évoluent

28 Concevoir un SI Étape 4: Identification des objectifs
Confrontation des menaces aux besoins Formulation et hiérarchisation des risques Sous la responsabilité de la MO Étape 5: Détermination des exigences Détermination des exigences fonctionnelles Responsabilités, mesures Qualité de la sécurité (par domaine précis) Par la MOE

29 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode

30 Le logiciel EBIOS Distribué sous Licence GNU GPL Multi-plateformes
Code source pas encore rendu public Multi-plateformes Linux, Windows, Solaris… Assister les utilisateurs d’EBIOS Stocke les contextes, risques, besoins Donne accès à une base de connaissances Risques courants Attaques courantes Risques fréquents

31 Interface principale

32 Etudier le contexte [Etape 1]
Audit et étude du contexte : Création de questionnaires : Connaitre l’entreprise et son SI Création de questionnaires : Identifier dans quel environnement on évolue Identifier l’entité que l’on a audité Identifier les contraintes que l’on doit respecter Environnementales, budgétaires, calendaire Identifier les différents réglements à respecter CNIL Identifier dans quel partie du SI on va intervenir Répertorier l’ensemble des éléments du SI 32

33 Exprimer les besoins [Etape 2]
Expression des besoins Identifier les besoins de sécurité de chacun des éléments essentiels caractérisent ce que veut protéger l'organisme. 33

34 Identifier les risques [Etape 3]
Identification des menaces Décrire les différentes menaces auxquelles la cible peut être confrontée Nous allons nous intéresser aux menaces pouvant affecter la cible de l’étude. déterminer les méthodes d'attaques et les éléments menaçants qui pèsent sur la cible puis les vulnérabilités associées exploitables. 34

35 Identifier les objectifs [Etape 4]
Identification des objectifs de sécurité déterminer la possibilité pour les menaces identifiées d'affecter réellement les éléments essentiels et d'impacter l'organisme D'une part, nous avons formalisé l'expression des besoins de sécurité, qui caractérisent ce que veut protéger l'organisme D'autre part, nous avons identifié les menaces qui pèsent sur l'organisme. Nous allons maintenant déterminer la possibilité pour les menaces identifiées d'affecter réellement les éléments essentiels et d'impacter l'organisme. Il s'agit des risques. L'ensemble des risques, des hypothèses et des règles de sécurité devra être parfaitement couvert par des objectifs de sécurité, en tenant compte des contraintes et autres éléments du contexte. Ils expriment ce que doit réaliser la cible pour que son système fonctionne de manière sécurisée. 35

36 Déterminer les exigences [Etape 5]
Détermination des exigences de sécurités vérifier la bonne couverture des objectifs de sécurité.

37 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode

38 Exemple de cas d’utilisation
Contexte L’organisme : PME, douzaine d’employés Stratégie : Utilisation de nouvelles technologies Consolidation de l’image de marque

39 Plan de l’exposé Introduction à EBIOS Principes de la méthode EBIOS
Recommandations et Bonnes pratiques Le logiciel d’assistance à l’évaluation EBIOS Exemples de cas d’utilisation Conclusions sur la méthode

40 Conslusions [1] Avantages d’EBIOS Solution complète par étapes
Définit clairement Acteurs, Rôles Interactions Vocabulaire Logiciel d’assistance à la mise en œuvre Base de connaissance intégrée Eprouvée par la DGA

41 Conclusions [2] Inconvénients d’EBIOS EBIOS ne peut être utilisé seul
Pas de recommandations sécuritaires Pas de méthode d’audit/évaluation Validation interne Oublis potentiels Risque d’évaluation incorrecte des risques Vocabulaire légèrement différent EBIOS ne peut être utilisé seul

42 Conclusions [3] Pistes complémentaires
Possibilité de faire appel à un prestataire Alcatel CIT Thales Security Systems Utilisation avec des recommandations externes ISO 27002 OWASP… Audit externe par société de sécurité Permet de garantir la fiabilité des résultats

43 Bibliographie Sources http://www.securiteinfo.com/conseils/ebios.shtml