LA METHODE EBIOS. 1. Les méthodologies de sécurité 1. ÉVOLUTION DE LA SSI

Transcription

1 LA METHODE EBIOS. ÉVOLUTION DE LA SSI. Généralités 2. CC et autres méthodes d évaluation 3. La méthode EBIOS 3. Etude du contete 3.2 Epression des besoins de sécurité Anas ABOU EL KALAM L évolution de la terminologie : sécurité informatique ; sécurité des systèmes d information ; sécurité de l information ; système de sécurité de l information. La SSI doit être considérée globalement en tenant compte de toutes les ressources ; en étant prise en compte au plus haut niveau hiérarchique ; en étant prise en compte au plus tôt dans la gestion des projets. 2. LE DÉVELOPPEMENT DES MÉTHODES SSI De nouveau besoins : formalisation, retour d epérience uniformisation, standardisation qualité Enrichissement des méthodes de nombreuses méthodes éprouvées approfondissent leurs bases de connaissances, développent les domaines d application, sont complétées par des outils logiciels Multiplication des méthodes adaptées à des domaines ou contetes spécifiques parfois concurrentes (idées divergentes ou raisons commerciales) 3. Les méthodologies de sécurité Mehari, Marion, Melisa, I CAS, CRAMM, BS7799, EBIOS, RFC 244 Réalisées par des utilisateurs ayant des compétences techniques de sécurité ou des groupes de travail Souvent applicables par des prestataires de service sous forme d'audit de sécurité d analyse de risques Base propositions d'actions pour améliorer la situation 4

2 5 Q +, Q [ $- Q 6 Q ' 0%" QQHTI a a Q QQQ HTI Q GNg f Q Q Q 2. Critères communs. Généralités 2. CC et autres méthodes d évaluation 3. La méthode EBIOS fournir au utilisateurs des indications sur les produits de sécurité en terme de «degré de confiance» fonctionnalités processus conception développement Certificat délivré par DCSSI «atteste que l eemplaire du produit ou du système soumis à évaluation répond au caractéristiques de sécurité spécifiées. Il atteste également que l évaluation a été conduite conformément au règles et normes en vigueur, avec la compétence et l impartialité requises» [décret ]. 6 Common Critéria for Information Security Evaluation ISO Critères communs : PARTIE I 2. Critères communs SGJITHIGU PH POMND QJF RPKEH EQ WKSGF PH SPOM LSKG PXM SNM ETH PJOUGH QGNHVT Pays 5 pays reconnaissent ce standard PXM SNM ETH YKG YZ Profil de Protection * + & (!)$ #!$! %!!$' "! PXM SNM KETH \LNHG ]Z \GINO EQ^ ]MOFG QTN Cible de Sécurité "2$' 3""'! 4 "/.! " 0%0 PXM SNM KETH _]LNHG C` Cible d Evaluation # #!$ $'-(;,;!)$;$$$ =-2 7) PP EGH SGJGD EFGHIGJ KGJ PINO EQ PMXGI SM vision utilisateur indépendant de toute implémentation EOTHHGVGH cbqgi KGJTHGHX EGH KGJIO EU ETH KG _]SM C[ 3 parties KGJVGHMIGJ[ea KdLGDU ST EQM ETH[ QTGOF <-!$ % 98 :!;-$ 8! "! 7' &5! "$!$ % % 3""'! "2 3- "; %) 0$ 0! 8$ %' "-$ (- - /"# %,2!! "-$B "3A- % " ' -$ #-$'; eigences fonctionnelles RTNOH EQ objectifs de sécurité,> ")$' 3-$' "-$$ % 0' 0" KMHJNH KG Q^UG cm EQGH EO EH PFOGO QXT QGNOJJTN SGJN SEEJM listes de fonctions de sécurité à remplir SSREOGhM dtnj^j WVG KNTOU EQ bga Fa[ KEFGHIGJ LMJJNOMHIG KGJ PINO PEQ CD techniques employées pour la vérification 7 8

3 Q Q $ $ 9 2. Critères communs : PARTIE II 2. Critères communs : PARTIE I comprend l' eigences fonctionnelles eprimées dans PP ou ST eigences sont réparties suivant classes classes décomposées en familles de composants Tous les produits mettant en œuvre des fonctions de sécurité peuvent être évalués classes (fonctionnalités) WVGJTNV EJNHG PXM SNM ETH KG SMJ PINO PEQ EQTNJ^J YOT KN cible d évaluation /-. 0 / (classe FAU) 7899.: 05; 08: (classe <.==86 56>= 8?6;= (classe FDP) B68 08: /23 /8:: 423 C/2 D. C003; (classe FDP) E/2: F005; F005; 08: ;. (classe FIA)! cible de sécurité spécification de besoin de sécurité -/9 0: 03 08: /2 C; ; (classe FMT) " # vision développeur $ % (voir PP) inclut les spécifications dédiés à la cible d évaluation!* $ '( ) & 0 B68 08: /2 C;G 02=6 0G (classe FPR) B68 08: /23 F8:5 08:3 / /2 JIHC; 25 (classe FPT) / C0K 03; 08: (classe FRU) -55 ML3 JIHC; F/258: 0;:52 0:32 5;:;.N & ' ' ( +, ' (classe FTA) (classe FTP) 2. Critères communs : PARTIE III 2 Critères communs : PARTIE II Définit les critères d'évaluation en termes d'eigences pour le développeur et éléments de preuve que le développeur du produit doit fournir à l évaluateur de tâches pour l'évaluateur. Critères répartis en classes d'assurance puis familles de composants 0 classes(assurances) Eemple : famille de la classe FAI O-EO-P Q=8.6 C23 C/2 F005; 08: H-EO-P R=8.6 F4/C; 0: 0 08: /23; 0S. /23. C003; / I<EO-P <=8.6 C;3= F045 05; 08: -KEO-P CK=8.6 F005; 08: C/2 D. C003; 2.6 EKEO-P 0DCR=8.6 /2: F005; 08: C/2 D. C003; 2.6 <KEO-P T=8.6 CC2 02:. C003; V U Eemple : composants de la famille FIA_UAU ag; C.; /08: C0FD.:=68 /2=68 08: W5 ZJB-C; ag; C.; /08: S0D.:25 C2 / W5 ZJ<-C;332 Zc7-C;332 b23 08: F/258: 0?.6; 08: W5 ZIR-C;332 Q0G6; 038:2 C8 0; 08: W5 2N= ZdR-C;332 R4G2 C8==292: W5 ZRb-C;332 0b. /23 W5 Z7Q-C;332 <.==86 C2 /2G 02 W5 ;.5>5 Q;=68?6;99; 08: C/2 F005; EOW08: -K-P ZYKXEOW08: -K-P Z[KX F005; 08: C/2 D. C003; 2.6;G;: 8. 2;5 F005; 08: 0: F; F0C3 S0; EOWC2 -K-P Z\KXM.3;?2.: EOW0A.2 -K-P Z]KX Q239 45;: /03923 F005; 08: Q239 45;: /03923 F005; 08:9. C 0= EOWC2 -K-P Z^KX Q;6 05; EOW08: -K-P Z_KX4? EOW43 -K-P Z`KX 08:;G =68 F005; H23 W5 ZJH-C;332 3 Z-d-C;332 J3 09; 08: /23G. C: C0S46; 0 43 W5 si l U demande que le produit intègre des mécanismes 2 Z-c-C;332 C/2 D;33.6;:52 W5 c; 0: 2:;:52 d'auth multiples, il faudra inclure dans PP ou ST le composant FIA_UAU.5

4 Q-JY YQ-J6.8= Q-JMYQ-J\ \Q-JMYQ-J6.8= B B B ` ` ` )( `` # _^rrk ` 3. Méthode M.E.L.I.S.A 2. Critères communs : PARTIE III (Méthode d'évaluation de la vulnérabilité résiduelle des systèmes d'informations) Délégation générale à l'armement 985. Cette partie fournit aussi pour chaque niveau d'évaluation (EAL à EAL7 pour Evaluation Assurance Level) l'ensemble des composants d'assurance nécessaire à l'atteinte de ce niveau. MELISA est une méthode d'analyse de vulnérabilités qui fut mise au point par la DGA (Direction Générale des Armements) et qui a été reprise par la société CF6. MELISA S - Confidentialité des données sensibles MELISA P - Pérennité de fonctionnement du système MELISA M - Sécurité micro mini informatique MELISA. R - Sécurité réseau Eemple //29;: 423X d--:238: =;3 C235 Q-C; =8.6 4C>3 C258 / : 23 =;3;:; =8.6 C258 / X 62A. ]Q-J0G2;. M=;6 06 /.: 0G2;.N= 0G:2;.N= 4C.3 C2G /2=62.G23 CF8692 C23= :356 0 L623X ; : : La méthode MARIO Fonctionnement 4. La méthode MARIO «Méthode d'analyse des Risques Informatiques et Optimisation par iveau» DCEFG H?JFI HK MB EJ EFG HIG MNK CMK MOG Questionnaires Pondération Quoi? Thèmes MB MJG HMNKK? PRH? MB E> STJ MUI? indicateurs questionnaires pondérés HC?JG>> MJW EMB HNQ MUI?? HN MBG PRMNK EMB B?V> Phases! XSGJ? YZ préparation " "# \[]^_ abcd ief_gh jf_ iakld m_knhfo^ bkl_ pakll^ $ % & ' C?JFI HK MB EJ XSGJ? qz Audit ar^cr^_^lc^g^l al `_kl `rf `^c akllf imrkn p^g^l ``sn^c MJUI?J XSGJ? tz * Analyse Comment? niveau indicateurs paf ma` i^cr acsn^c ai^l baa_f aklr acsn^cd aghf_ `^ `hk ``^l +! $ & note thèmes XSGJ? uz Plan d'action,# _ e^cd ``^{d wpvflfc^gkv^lc b[f alf ir^l ay^fnc m_nr a` mz ``^baebrfo^_k ~`g ac^^l_kl bkrg a` m akl }fhhkr `^rd imi^or pmjfg akrf ::2707: ;<27.5 ;<9770< 50./-02./ & = 5 &

5 B?? BBBB BB B B B? OKNO A?JK? N> BB GF B BB B BB G> qq 5. MEHARI Comment? règles modes de présentation C MJ>NJ MB MNK C?J IK?GO MF EMB R?K MJ? IK plan de sécurité HHC?>G HM G H?J? BBBGK LH? C? mesures schémas de décision MQ?KO?J CDG MK H?K MF?GI C?J MB E>NK CGK BGIV?V BB? PMV GO MJUI? CMK E>?K CGK BJZ Base MJ MK HIGK HG potentialité du risque MJ MK HIGK impact C?J MB E PMV BT>?J C?J GO MJUI? SGOOIKGQ MJJGK CHH? MJJIGJ MF? MF?? MNK BB?O J 8 HHMG MF?? EOI> MNK 5. La méthode MEHARI Phases Phase : établir plan stratégique de sécurité définition des métriques des risques & objectifs de sécurité, établissement d'une politique de sécurité, établissement d'une charte de management. Phase 2 : établissement de plans opérationnels de sécurité Phase 3 : consolidation des plans opérationnels (global). Plus d info :*! "# $ 20 B SN C? MJ CE? D KG HTJ? C? JUI?J 5. MEHARI : EB SN C? CI MHIJ BBBGK Quoi? MNKUIGK MBG MF? C?J EFG HIG BIK? SGUI?J MBIG MNK facteurs de risque H?JKNIF?GIV H?J modes de objectifs stratégiques MJ?GF?OIK?>N HMB MUI? C? HMB HC? D?K fonctionnement MF?GIONKF?KI MF?GIONKF?KI MKGA M?K MJUI?J IKK Idées de base? analyse des vulnérabilités MJV? BGK B? HM?K?K risques encourus mesures de sécurité vulnérabilité EJ?KO? H NI DG LJ?KO? C? ECI NIKNK MB HG>N HMG EMBBB?K MA>GO CDIKJ MK MJ MBJNJ N K DMK MNK C?O?J BT>?J IJUI DGIK MF?GIO SN MJ M 7 réduire la gravité du risque 5. MEHARI 9

6 " " " " " -. + * +!!, * + (!!#&!!! ( $## (( (!!### "! %!#&'!##$ "!!!!!! EBIOS Melisa Marion Mehari Octave Cramm SPRINT BS 7799 ISO 7799 ISO 3335 ISO 5408 SCORE CALLIO COBRA ISAMM RA2 995 * * * Comparatif des normes DCSSI Gouv Fr Log grat. % ) 2. Généralités 2. CC et autres méthodes d évaluation 3. La méthode EBIOS EBIOS méthode pour l Epression des Besoins et l Identification des Objectifs de Sécurité Vue globale 22 II. La réglementation II.2 Méthode EBIOS : Introduction Lois, décrets Loi 78-7 du 06/0/78 "informatique et liberté" (http://www.cnil.fr/inde.php?id=30) Interministérielle IGI 300 du 2/03/82 "protection du secret" Ministérielle Réglementation Interne Les informations "classifiées de défense" IGI 900 du 20/07/93 Les informations sensibles IGI 90 du 02/03/94 (www.ssi.gouv.fr/fr/reglementation/90/90.pdf ) Méthode d'analyse des risques en SSI Peut être appliquée pour un Système à Concevoir ou Eistant déterminer les actions de sécurité qu'il convient d'entreprendre s inspire des ITSEC (Information Technology Security Evaluation Criteria) input : CdCF (récapitule besoins) output : (objectifs de sécurité) = données pour FEROS (formalisation des objectifs de sécurité). l'élaboration de l'architecture fonctionnelle sécurisée L'IGI 900/SGDN/SSD/DR du 20/07/

7 II.2 Introduction II.2 Introduction Cycle de vie d une solution info spécification des besoins (définir ce que fait le système) conception (définir comment on fait le système) réalisation (faire le système) utilisation (installer et eploiter le système) Conception analyse des besoins eprimés par le maître d'ouvrage dans le CdCF eamen de l'eistant étude des solutions bilan de faisabilité et le choi d'une solution réponse au CdCF formalisé par Spécifications Techniques de Besoin Spécification des besoins définir les services que le système doit rendre déterminer le contete identifie les grands choi (stratégiques, fonctionnels...) relatifs au système concrétisée par le Cahier des Charges Fonctionnel (CdCF) objectifs stratégiques et enjeu du système à concevoir contraintes : solutions, normes, réglementations, coûts, délais, missions du système, limites du système à concevoir grandes fonctions et relations avec l'etérieur identification sous systèmes & interfaces entre ces sous-systèmes 25 Réalisation Acquisition ou développement solution intégration Validation Utilisation installation sur site, eploitation, maintenance 26 II.2 Processus en V II.2 Introduction epression des besoins spécification conception architecturale conception détaillée tests d intégration tests unitaires tests de qualification tests de recette Prise en compte sécurité lors de la spécification des besoins analyser les enjeu d un point de vue de la sécurité poids stratégique du système pour l'organisme impact sécurité système sur sécurité globale de l'organisme pertes maimales que le système peut supporter analyser le contete dans lequel se situe le système / sécurité environnement physique dans lequel va évoluer le système menaces générales pesant sur l'organisme qui abritera le système contraintes de sécurité auquelles le système est soumis définir les besoins intrinsèques de sécurité codage 27 déterminer les objectifs de sécurité pour le système 28

8 II.2 Introduction : les Objectifs de sécurité résultent d'une analyse qui intègre besoins de sécurité initiau, menaces spécifiques vulnérabilités associées au éléments connus ou supposés choi organisationnels retenus doivent se décliner en mesures non techniques de sécurité (physique, organisationnelle) qui constituent les grandes lignes de la politique non technique de sécurité mesures techniques de sécurité eprimant ce qui reste à couvrir par des fonctions techniques au sens ITSEC permet d'estimer le type de fonctionnalité de sécurité que l'on désire obtenir (e.g., une classe de fonctionnalité donnée au sens ITSEC). 29 II.2 Introduction Prise en compte sécurité lors de la Conception choisir les fonctions de sécurité répondant au objectifs de sécurité sélectionner ou spécifier les mécanismes associés consolider la politique de sécurité technique du système définir la politique d'administration de la sécurité définir, le cas échéant : mode dégradé, plan sauvegarde et plan secours Prise en compte sécurité lors de la Réalisation Réaliser (soit même) ou se procurer (produit marché) mécanismes séc les intégrer avec les autres éléments du système effectuer une analyse de vulnérabilité résiduelle. Prise en compte sécurité lors de la Réalisation installer puis configurer mécanismes sécurité sur site d'eploitation validation de la sécurisation globale du système formation des futurs responsables de la sécurité du système. 30 administration, test,sauvegarde, audit II.2 Introduction : phases & docs II.2 Démarche EBIOS Politique de Sécurité nterne (PSI) : définit règles générales de sécurité. se situe en amont du cycle de vie. DSIS : fournit cadre méthodologique pour prise en compte sécurité au cours projet dvpt. (ϕ conception et réalisation) EBIO : activités prise en compte sécurité de la phase de spéc besoins epression objectifs sécurité Epression des besoins de sécurité Étude du contete Objectifs de sécurité Étude des risques EBIOS suit une démarche naturelle et applicable par le futur utilisateur qui permet de: responsabiliser les acteurs formaliser un raisonnement analyser un système eistant rationaliser les objectifs de sécurité au sens des ITSEC ou des CC Fiche d'epression Rationnelle des Objectifs de Sécurité (FEROS) : formalisation objectifs de sécurité Réalisation des Objectifs de Sécurité par le ChOi des Fonctions (ROSCOF) : guide concepteur dans choi fonctions sécurité répondant au objectifs. (ϕ conception après epression objectifs) Guides d'aide à la RéDaction des fournitures pour l'evaluation (GARDE) : pour évaluation ITSEC 3 32

9 II.2 Démarche EBIOS : vue globale objectifs de sécurité! " # $ 34 Étude contete II.3 EBIOS : Les étapes Etude Risques Epression besoins Objectifs sécurité 36 II.2 Démarche EBIOS : vue globale informations fonctions besoins de sécurité vulnérabilités Etude des risques probabilité faisabilité menaces 33 EBIOS méthode pour l Epression des Besoins et l Identification des Objectifs de Sécurité Les étapes 35

10 Plan - II.3 Etape I : Contete - -, Étude contete Epression besoins Etude Risques 3. La méthode EBIOS 3. Étude du contete 3.2 Epression des besoins de sécurité 3.3 Analyse des risques 3.4 Identification des objectifs de sécurité But : Objectifs sécurité globalement précisément Réunir les informations nécessaires à la planification de l étude! " $# % & )* +! * ' ()* " " *. " - " /0 /0! 2 " " " "32 " 37 " ( ( 38 II.3 Etape I : Contete Activité I. : Étude de l'organisme Données en Entrée : Plan stratégique, bilan d activité, charte sécurité Données Sortie : place système dans organisation, liste contraintes Trois activités Étude de l organisme Étude du système cible PRESENTATION ORGANISATION Savoir faire : recueil éléments stratégiques missions (service/destinataire), métiers (techniques, savoir faire employé) valeurs (principes, étique) aes stratégiques (lignes directrices/évolution enjeu) ORGANISATION GENERALE Structure (divisionnelle / fonctionnelle ou matricielle) Organigramme (structure liaison subordination, dépendances) Détermination de la cible de l étude 39 CONTRAINTES Stratégiques : évolution possibles structures/orientations Territoriales : dispersion des sites Conjoncturelles : continuité service même si grèves/crises Structurelle : e.g., structure internationale concilier eigences propres à chaque nation obligations légales et réglementaires relatives au personnel : sensibilisation sécurité, confid. 40 d'ordre calendaire : réorganisation service, nouvelle politique d'ordre budgétaire : mesures sécurité préconisées ont coût qui peut être important.

11 Activité I.2 : Étude du système cible Activité I.2 : Étude Système Cible Dynamique Données en Entrée : relations entre domaines d activité du SI, liens inter-domaines, évolution, priorités, évaluation risques stratégiques Données Sortie : Architecture conceptuelle du SI, relations fonctionnelles avec systèmecible, Définition du "système essentiel" du système-cible, Sélection enjeu ELEMENTS Savoir faire : fonctions, informations, enjeu contribution du système-cible au missions du SI de l'organisme description générale du système-cible (fonctions, traitements, produits), relations fonctionnelles avec le système-cible enjeu du système-cible au sein du SI Caractérisation architecture conceptuelle du SI DÉCOUPAGE EN DOMAINES FONCTIONNELS fonctions : opérationnelles, de support, de contrôle REPRÉSENTATION DES RELATIONS INTER-DOMAINES interactions entre activités : objets supports de l'information, traitements, moyens 4 42 Activité I.2 : Étude Système Cible.Etude du contete->.2.etude du système cible Début Représentation du système-cible dans le SI : DESCRIPTION FONCTIONNELLE DU SYSTÈME-CIBLE préciser pr fonction : résultats attendus, activités à réaliser, entités manipulée CARACTÉRISATION PROCESSUS contraintes informationnelles et organisationnelles : relations, interactions, flu, Sélection des enjeu du système-cible - EVALUATION DES ENJEUX DE POLITIQUE GÉNÉRALE DU SI scénarii d'évolution du SI : cibles organisa.&physiques à moyen&long terme, améliorations, rentabilité, 2 - RECUEIL ÉLÉMENTS DE POLITIQUE DE SÉCURITÉ DU SI priorités, résultats, consignes 3- IDENTIFICATION DES CONTRAINTES d'antériorité, réglementaires, financières, temps, relatives au méthodes, tech. 4- IDENTIFICATION DES EXIGENCES GÉNÉRALES Eigences techniques :fichiers, architecture, progiciels, matériel, réseau, Eigences organisationnelles ; Eploitation : délais, fourniture résultat, services, suivi, plan secours Gestion des développements : outils, organisation à mettre en place 43 Documentation concernant le SI oui Décomposer Décrire l architecture conceptuelle du SI Décomposition Décomposition en sous-systèmes Suite Non Place du système dans l organisme A Caractérisation de l architecture conceptuelle du SI Architecture conceptuelle du système cible dans le SI 44

12 $..(&"$-& Suite A Eemple Représentation des fonctions Documents de politique informatique Définir le système cible Analyse des enjeu du système cible Fin Représentation du système cible Définition du système essentiel Sélection des enjeu Liste des enjeu 45 Fichier des emplois Fichier des rémunérations Notes Enquêtes Analyse Simulation Projet de statut Statistiques Etudes Analyse Statut Decrêt Arrêté 46 Activité I.3 : Détermination de la cible de l'étude But Quoi?.Etude du contete->.3.détermination de la cible de l étude Documentation concernant l organisation des moyens Début Identifier les entités essentielles Caractérisation des moyens du système cible Caractérisation des moyens de la cible de l'étude %&' # $'!" #$ %&' %() #* #$ %&'!&"$+,' #&.)"( #(.& Définition du système essentiel Construire les liens entre - fonction / entité -information / entité Liste des entités Création du tableau des relations fonctions/entités et informations/entités 47 Suite Tableau des liens 48

13 Activité I.3 : Détermination de la cible de l'étude Création tableau Fonctions / Entités et Informations / Entités Eemple Relation entre informations sensibles et entités Matériel Logiciels Réseau Personnel Entité Information Serveur Station... OS Appli.... Ethernet X25... Admin. Ingénieurs Dévs Messagerie Edition de plans Étude du Contete : récapitulatif Plan Objectifs Résultat Actions Prise de connaissance du domaine à étudier Préciser les enjeu du système pour l organisme Réunir les informations nécessaires à la planification de l étude Contraintes et Cible de sécurité connus Étude de l organisme Étude du système cible Détermination de la cible de l étude 3. La méthode EBIOS 3. Étude du contete 3.2 Epression des besoins de sécurité 3.3 Analyse des risques 3.4 Identification des objectifs de sécurité 5 52

14 Etape 2 : Besoins 2. Epression des besoins de sécurité (2/4) _ba`$(%* ]-$(%* ] $ )* -/- ^ _%* $(%* & &'.(#'# '%Q#"% "' & "'# 4== O% )# -"Q * (' & 62 -,"'' )&!' * /, ' )*# '"' ' $#(. )* % &#%((# -,)& +#!"#$% "' (# )' & &&*%#%*'' & = FEGHIJKLJLKEEGLEJMGE FEGHIJKLHILEEGLEJMGE V 0)& [ &&#. Epression besoins sécurité Étude du contete Étude risques sensibilité fonctions et informations besoins de sécurité associés au objets sensibles et au fonctions essentielles de cible étude eprimés par U fonctionnels en Objectifs Résultat Sélectionner les fonctions essentielles et les informations sensibles Faire eprimer les utilisateurs sur les besoins en D, I, C, R Liste validée des besoins de sécurité Objectifs sécurité termes de C D I quantifiés par leurs impacts sur org. Actions Sélection des fonctions et des informations essentielles Epression des besoins sécurité des fonctions et informations sensibles Synthèse du besoin de sécurité Etape II : Besoins Trois activités Sélection info&fnct sensibles Epression besoins sécurité Synthèse besoins sécurité Activité II. : Sélection éléments sensibles DE : DS : responsable User A. Détermination des éléments sensibles «sensibilité :77;<;7 :< (# ' 46 BA82 CD -'P & P :9N -'P )'#%.P B. Création des fiches epression des besoins de sécurité S T S S U R S WJH S X S Y JW H Z \ S S `c$

15 263 = = 9629 = ; = = Fonction/Informations essentiels Classifiées : secret défense Vitales : mission de l'organisme ominatives : loi informatique et liberté Stratégiques : contrats/accords Coûteuses : délai / coût Information mission impossible suite dégradation fcnt traitement secret Fonction 58 otation d'évaluation d'impact Eemple Notation (C & I) dans domaine militaire 38 ;<:92 3 2B :27 3A2<7:27 ;3HCA ;=C 35C 3<4CA F/ :27 J/ L424< M;2?C45 H<4A 3<442B24 C 3567C4 K/ :C5 Eemple Notation pour une organisation!" #$ ' &%$ $ # ( $!" #$ $ )*" + # &,*#" Activité II.2 : Epression besoins sécurité Comment? ><299 < Users 4 9 ;6 4> 26 chaque fonction chaque information Les besoins de sécurité sont indépendants des risques encourus et 82 ; ; 2 < B 9<2>< :926 ==26 intrinsèque des moyens de sécurité mis en : 4?44= > 2 ; =; 4<2 N ; :4= 26 4?2<62 ; 2 < ==< = : ;99 42< 927<2 : Eemple de la sensibilité des objets Commentaires Besoin de sécurité Pertes financières Infraction au lois Image de marque I m p a c Fonction/Information sensible. t Sinistres Inaccessibilité D Destruction Modif. Accidentelle I Modif. Délibérée Divulg. Interne C Divulg. Eterne

16 Eemple d échelle d évaluation des sensibilités Activité II.3 : Synthèse besoins sécurité - «0» la perte du critère est sans conséquence pour l organisme - La perte du critère entraînerait des conséquences défavorables au intérêts de l organisme, - «2» La perte du critère entraînerait des conséquences dommageables au intérêts de l organisme, - «3» La perte du critère entraînerait des conséquences graves au intérêts de l organisme, - «4» La perte du critère entraînerait des conséquences eceptionnellement graves au intérêts de l organisme But Affecter, pour chaque information et/ou sous-fonction, la valeur finale de sensibilité qui résulte de la synthèse des valeurs attribuées par les utilisateurs. L'auditeur reporte les valeurs de sensibilité déterminées par les utilisateurs sur la fiche "synthèse des besoins de sécurité" et détermine la valeur considérée comme la synthèse

17 Plan 3. Risques 3. La méthode EBIOS 3. Étude du contete 3.2 Epression des besoins de sécurité 3.3 Analyse des risques Epression des besoins de sécurité Étude du contete Objectifs de sécurité Étude des risques Quelles sont les menaces? Quelles sont les risques qui peuvent réellement affecter l'organisme? Activités de l'étape 3.4 Identification des objectifs de sécurité Étude des risques (3/4) 3. Étude des menaces génériques Objectifs Résultat Actions Déterminer les risques qui doivent être couverts par les objectifs de sécurité de la cible de l étude Liste validée des risques retenus Étude des menaces génériques Étude des vulnérabilités spécifiques Analyse des risques spécifiques Confrontation des besoins de sécurité au risques spécifiques 67 Les menaces sont sélectionnées à partir d'une liste de menaces génériques relatives à des thèmes : Accidents physiques Événements naturels Pertes des services essentiels Perturbations dues au rayonnements Compromission des informations Défaillance technique Agression physique Fraude Compromission des fonctions Erreurs 68

18 3. Eemple de sélection de menaces génériques 3. Étude de l'impact de la menace Thème menace Cause Accidentelle Délibérée Ludique Avide Origine Stratégique Terroriste Évaluer les impacts des menaces sur la cible de l'étude en affectant une valeur en terme de sévérité (gravité) Une sévérité s'eprime sur une échelle de 0 à 4 où : III Pertes de service VIII Actions illicites Défaillance de la climatisation Perte d'alimentation électrique Perte de moyens de télécom. Piégeage de matériel Piégeage de logiciel - 0 : la menace n'entraîne aucune conséquence - : la menace implique une conséquence faible - 2 : équivaut à une perte moyenne - 3 : signifie une perte importante - 4 : correspond à une perte complète. Abus de droit Usurpation de droit Fraude Eemple de sévérité des menaces pertinentes 3.2 Etude des Vulnérabilités spécifiques Menace 0.Défaillance de la climatisation Sévérité D I C Commentaires Local aéré Définition Une vulnérabilité est une "caractéristique" du système qui peut être eploitée par une menace.perte d'alimentation électrique 0 0 Groupe électrogène disponible 2.Perte de moyens de télécom. 30.Piégeage de matériel 33.Piégeage de logiciel Mission essentielle Menace 33 - Possibilité de créer ou modifier des commandes systèmes - Possibilité d'implanter des programmes pirates - Possibilité de modifier ou changer les applicatifs - Possibilité d'eistence de fonctions cachées 39.Abus de droit 40.Usurpation de droit 42.Fraude Menace 8 - Matériel ayant des éléments permettant l'écoute passive (câblage, prises de conneion...) 7

19 3.2 Caractérisation des vulnérabilités Les vulnérabilités sont caractérisées par leur faisabilité ou leur probabilité. La faisabilité caractérise les vulnérabilités associées au menaces délibérées (intentionnelles) La probabilité caractérise les vulnérabilités associées au menaces accidentelles Faisabilité (F) 0: menace infaisable 0.25: nécessité de moyens très importants des connaissances pointues 0.5: nécessité d'un certain niveau d'epertise ou matériel spécifique 0.75: réalisable avec moyens standards et connaissance de base : menace réalisable par tout public Probabilité (P) 0: menace improbable 0.25: menace faiblement probable 0.5: menace moyennement probable 0.75: menace fortement probable : la menace est certaine Liste des vulnérabilités associée à la menace 33 Menace n 33 Piégeage de logiciel Libellé de la vulnérabilité Possibilité de modifier les applicatifs Possibilité d'implanter des programmes pirates Possibilité d'eistence de fonctions cachées introduite en phase de conception Personnel manipulable Facilité de pénétrer dans les locau Mat & Log 0.5 Réseau interne Site Personnel utilisateur Personnel développeur Organisation Absence de consigne de sécurité Analyse des risques spécifiques Un risque est considéré comme une menace associée à un ensemble de vulnérabilités qui permettent sa réalisation. Il est caractérisé par son : impact direct en (D, I, C) issu de la menace et une faisabilité / probabilité issue des vulnérabilités retenues Chaque risque, ainsi caractérisé doit être eplicité clairement. C'est l'objet de la fiche des risques spécifiques, qui synthétise, pour le système-cible, l'ensemble des risques spécifiques qui le concernent Analyse des risques spécifiques Eemple : Infection par virus provoquée par une disquette d'origine douteuse amené par le personnel. Piégeage logiciel fait par le personnel d'entretien en dehors des heures ouvrables. Les vulnérabilités eploitées se trouvent dans la fiche des vulnérabilités spécifiques. Un risque est référencé par son numéro de menace, et par un numéro d'ordre dans la menace si cela est nécessaire. 76

20 3.2 Analyse des vulnérabilités spécifiques R Libellé du risque Un informaticien développeur a introduit une fonction cachée dans les applicatifs Un informaticien développeur a introduit une fonction cachée dans les logiciels réseau Le personnel utilisateur modifie les applicatifs Un membre du service implante des programmes pirates Un intrus pénètre dans le site pour implanter des programmes pirates F = = = = = Liste des vulnérabilités associée à la menace 33 Menace n 33 Piégeage de logiciel Libellé de la vulnérabilité Possibilité de modifier les applicatifs Possibilité d'implanter des programmes pirates Possibilité d'eistence de fonctions cachées introduite en phase de conception Personnel manipulable Facilité de pénétrer dans les locau Mat & Log 0.5 Réseau interne Site Personnel utilisateur Personnel développeur Organisation Absence de consigne de sécurité Un informaticien développeur a introduit une fonction cachée dans les applicatifs Liste des vulnérabilités associée à la menace 33 Menace n 33 Piégeage de logiciel Libellé de la vulnérabilité Possibilité de modifier les applicatifs Possibilité d'implanter des programmes pirates Possibilité d'eistence de fonctions cachées introduite en phase de conception Personnel manipulable Mat & Log 0.5 Réseau interne Site Personnel utilisateur Personnel développeur Organisation Un informaticien développeur a introduit une fonction cachée dans les logiciels réseau Analyse des risques spécifiques Synthétiser pour le système cible l'ensemble des risques spécifiques qui le concernent N menace N risque Libellé du risque D I C F/P la centrale de clim % Tombe en panne 22 Impact menace F/P vulnérabilité Un utilisateur du CECP diffuse une information sensible par le réseau RTC % Facilité de pénétrer dans les locau 0.5 Absence de consigne de sécurité

21 3.4 Confrontation des risques au besoins 3.4 Confrontation des risques au besoins Le but de cette activité est de retenir les risques qui sont véritablement susceptibles de porter une atteinte au fonctions ou au informations sensibles. La sélection s'effectue par la mise en relation des risques spécifiques avec les besoins de sécurité, pour mettre en évidence l'impact final de la réalisation d'un risque. Actions : détermination pour chaque fonction et info de la liste des risques qui les concernent confrontation des risques au fonctions et informations. réfleion qui est menée lors de cette activité sert également à orienter la décision de partage entre les mesures techniques et non-techniques. La synthèse s'effectue par la rédaction de la liste des risques retenus pour le système cible, classés en catégories représentatives de leur gravité. Les besoins de sécurité ont été eprimés pour les fonctions et les info. La confrontation des besoins au risques consiste à déterminer les liens directs entre les menaces d'une part et les fonctions et informations d'autre part. Fonction K Menaces Menace_ i Besoin (sensibilité) D I C Impact Impact final (sévérité) D I C D I C 3.4 Eemple de confrontation des risques au besoins Plan - Si une sévérité est nulle, alors l'impact réel est nul - Si une sévérité est non nulle, alors l'impact réel est égal à la sensibilité Fonction K Sensibilité Sévérité Impact final Menaces D I C D I C Défaillance de la clim Généralités 2. Réglementation et FEROS 3. La méthode EBIOS 3. Étude du contete 3.2 Epression des besoins de sécurité 3.3 Analyse des risques 3.4 Identification des objectifs de sécurité Un utilisateur du CECP diffuse une

22 4. Identification objectifs de sécurité 4.Identification des objectifs de sécurité (4/4) Epression des besoins de sécurité Étude du contete Étude des risques Que peut faire l'organisme pour que son système soit mieu sécurisé? Activités de l'étape Objectifs DE Résultat eprimer ce que doit réaliser la cible de l'étude pour que le système-cible fonctionne de manière sécurisé. Listes besoins sécurité / risques /contraintes Rédaction de la FEROS/Liste des objectifs de sécurité Objectifs de sécurité Actions choi des fonctionnalités de base en fonction de la politique de sécurité de l'information et du mode d'eploitation du système, sélection des objectifs de sécurité pour le système comprenant fonctionnalités techniques complémentaires choi des contre-mesures non techniques, 85 prise en compte des contraintes/enjeu. 86 Activités 4. Choi du mode d'eploitation des informations Le mode d'eploitation des informations consiste à indiquer comment le système traite, transmet ou conserve des informations de sensibilités différentes pour des utilisateurs de catégories différentes. Catégorie : Le mode d'eploitation eclusif Tous U ont même niveau + besoin commun d'en connaître Catégorie 2: Le mode d'eploitation dominant Tous U ont même niveau + n ont pas tous besoin commun d'en connaître Catégorie 3: Le mode d'eploitation du système multi-niveau U ne sont pas tous habilitées + n ont pas tous besoin commun d'en connaître 87 88

23 4. Choi du mode d'eploitation des informations 4.2 Epression des objectifs de sécurité choi du mode d'eploitation s'effectue après avoir déterminé si : les types de sensibilité des infos (CDI) correspondent à des classifications et si notions d'habilitation eistent. Il convient ensuite de se reporter au tableau suivants pour trouver le type du mode d'eploitation. but : epression complète objectifs de sécurité de la cible de l'étude. s'appuient sur les objectifs de sécurité minimums et prennent en compte les risques et les contraintes Cf. Tableau page 54 (Techniques) Classification maimum des informations Niveau d'habilitation minimum des utilisateurs Niveau d'habilitation minimum des utilisateurs Classification maimum des informations Sans besoin d'en connaître Si sensibilité d'une info C=4 et si tous les users doivent accéder alors habilitation =4 Avec besoin d'en connaître 9 Administrateur Utilisateur Habilitation Niveau d'habilitation minimum des utilisateurs D I C Classification maimum des informations Courrier élect. Compte rendu Sensibilité D I C Classe de fonctionnalité pour la C = F-B, I=F-IN, D=F-Q2