Sensibilisation Sécurité Informatique

Sensibilisation à la sécurité informatique
Méthodologie
Intervenant : Servas Olivier
Réalisation : Octobre /99
Màj: Février 2001 /Décembre 2001 /septembre 2007
Sommaire
Introduction
II. Comparatif des normes
III. Présentation des principales normes
A. EBIOS
B. Melisa
C. Marion
D. Mehari
E. Octave
F. Cramm
IV. Critères de choix
V. Conclusion
© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 2

méthodologie
 la sécurité c'est une chaine, si un maillon
est faible l’ensemble est faible
 Elle doit être vue globalement! "d'employer un

(et un seul) «gourou prêchant des formules
secrètes» et de contraindre les enfants à assister
aux offices ”

méthodologi
e
Vos objectifs ?
 Ce qu'il faut réellement protéger ?
Disproportion des moyens avec ce qu'il faut
protéger
 la sécurité doit avoir un coût raisonnable
”Acheter une super porte blindée et oublier de

fermer la fenêtre" ?

méthodologie
"Rien ne sert ...” "de se payer un super coffre-fort
pour protéger quelques pacotilles et de laisser
l'accès libre à une cave emplies de grands crus
classés! "
"de construire des remparts à la Vauban pour se
protéger de l'aviation! " cela montre que l'on ne
sait pas d'où peuvent venir les attaques
"d'utiliser un marteau pilon pour écraser une
mouche"

L'aspect méthodologie
" Du bon sens ... "Avant d'aborder la technique : la sécurité à 100%
n'existe pas,
Il y a nécessairement compromis entre la valeur du «protégé» et le coût
de la protection,
donc il faut savoir quoi protéger
Il faut oeuvrer à la mise en place de moyens raisonnables, pour que le but
soit suffisamment «dissuasifs».
 Permet de structurer votre démarche pour atteindre les

objectifs qui vous sont fixés.
 Elaboration du cahier des charges au suivi de la solution

mise en œuvre.

méthodologie
 Des préconisations techniques et choix

produits au transfert de compétences vers
les équipes internes chargées de la sécurité,
cela implique :
 des méthodes
 des moyens nécessaires pour parvenir au
résultat.

Centre informatique sécurisé
 les aspects didactiques en aidant le

responsable à se poser les bonnes questions,
 les aspects méthodologique en l'aidant à se
focaliser sur les sujets essentiels et de les
traiter dans le bon ordre.

le projet et les acteurs,
les missions, les besoins et les enjeux du
centre informatique,
les menaces et les parades,
le déroulement du projet,
l'emménagement et la prise en charge du
centre informatique..

Evaluer les risques internes et externes liés à

l’utilisation de l’Internet
Connaître toutes les possibilités d’attaque sur votre réseau

Préserver votre réseau des attaques avec les firewalls
Minimiser vos risques avec les firewalls, l’encryptage,…
Protéger l’intégrité de vos données avec des techniques de “
“chiffrement”

Objectif
Que faire si le pire devait

arriver ?..

Politique de sécurité : Définitions
 Spécifie l’ensemble des lois, règlements et pratiques qui
régissent la façon de gérer, protéger et diffuser les
informations et autres ressources sensibles au sein d’un
système spécifique, d’une organisation
 Une politique de sécurité doit permettre d’exprimer des
exigences
 Confidentialité
 Intégrité
 Disponibilité
 Quelles questions se poser ?
 Quel est le périmètre ? (notion de frontières, de domaine)
 Quelle est la taille du système ?
 Quels sont les objectifs de sécurité ?
 Quels sont les biens à protéger ?
 Quels sont les menaces et attaquants potentiels ?

Politique de sécurité d’un système
 Ensemble des lois, règlements et pratiques qui régissent la
façon dont l’information sensible et les autres ressources
sont gérées, protégées et distribuées à l’intérieur d’un
système spécifique
 Ensemble de règles qui spécifie les autorisations,
interdictions et obligations des acteurs
 Utilisateurs
 Applications
 Nécessité de prendre en compte la notion de « monde
ouvert »
 Inventaire du système d’information
 Classification de l’information
 Identification des domaines de sécurité
 Aspects physiques et organisationnels
 Règles et pratiques

Méthodologie
 Analyses de différentes démarches, normes et

méthodes
 ISO 13335, …, iso 17799 BS7799 …,
 MEHARI (Méthode Harmonisée d’Analyse des RIsques
- CLUSIF), MARION, MELISA, …
 EBIOS (Expression des Besoins et Identification des
Objectifs de Sécurité - DCSSI « Direction Centrale de la
Sécurité des Systèmes d’Information »)
 RSSI + conduire des évaluations de risques
 CRAMM
 Basé sur la méthodologie préférée de l’évaluation des risques du
gouvernement BRITANNIQUE (la BS 7799)

Méthodologie , Norme :
 Norme
 Document de référence fondé sur un consensus couvrant
un large intérêt

Documents de spécification techniques ou autres critères précis
devant être utilisé comme règles, définitions ou encore comme
lignes directrices

Norme = Label de confiance
 Méthode
 Moyen d’arriver au résultat souhaité
 EBIOS (Expression des Besoins et Identification des Objectifs
de Sécurité - DCSSI « Direction Centrale de la Sécurité des
Systèmes d’Information »)

Démarche et Méthodes ISO 13335:
 Composé de 4 Documents

Définition des concept de base
 Information sur l’organisation de l’entité
 Approche d’une gestion des risques
 Guide des mesures préventives
 En cours de révision
 Evolution vers un Standard International
(IS) : ISO/IEC IS 13335 -1, 2 (IT) :
ISO/IEC IT 13335 -3, 4
http://www.ysosecure.com/norme-securite/norme-iso-13335.asp

Norme BS 7799
 Le British Standard 7799 est composé de deux guides :
 ISO/IEC 17799:2000, qui est un catalogue regroupant 36 objectifs de

contrôles, décomposés en 127 mesures, relatives à 10 domaines.
 Les objectifs de contrôles présentent le but à atteindre et ce qu’il faut
entreprendre pour y parvenir. Les mesures expliquent avec plus ou
moins de détails les points à mettre en œuvre
 La BS 7799-2:2002, présente un système de gestion de la sécurité en 4

étapes : Planifier, mettre en œuvre, vérifier, améliorer.
 À travers dix domaines, cette norme

permet de détecter, d'analyser et de diminuer les risques liés à l'information.

BS 7799 / ISO 17799
Politique de sécurité  La norme BS 7799 / Iso 17799 est

Sécurité développée pour créer une structure commune
De l’organisation de sécurité de l'information et ainsi couvrir les
Classification Contrôle d’accès
aspects techniques, administratifs et juridiques.
Et contrôle des actifs
Conformité
Sécurité Sécurité physique

Ressources Humaines Et environnementale
Développement Gestion des communications
Continuité de service
et maintenance et des opérations
Aux travers des domaines de contrôles, cette

Aspect organisationnel
Aspect physique
norme permet de détecter, d'analyser et de
Aspect Technique diminuer les risques liés à l'information.
Source http://www.callio.fr/bs7799
BS 7799 / ISO 17799 décrit les concepts de sécurité " idéaux ",
tandis que BS 7799-2 décrit les concepts de sécurité " incontournables " pour toute organisation voulant être certifiée.

BS 7799 / ISO 17799 en 10 points
1 Management : Politique de sécurité

 Conformité, Prévention, Formation, Implication de la direction, Conséquence de la violation de PS
2 Management : Organisation Interne

 Instance de sécurité, Coordination, Responsabilités, Processus d’autorisation, Conseil de spécialiste
3 Management : Classification et contrôle actifs

 Identification d’un propriétaire (responsable)pour chaque actif, Inventaire des actifs, classification en
fonction des besoins . Exemple : les Actifs applicatifs sont : les progiciels, les logiciels maisons, …
4 Environnement Humain et physique : Sécurité liée aux Personnes

 Culture d’entreprise sur la sécurité, Recrutement, Formation, Signalement des dysfonctionnement et
processus disciplinaire
5 Environnement Humain et physique: Sécurité physique et de l’environnement

 Sécurité physique (différentes zones), matériel (procédures des entrées et sortie), méthode de
suppression de fichiers, et élément de stockage

BS 7799 / ISO 17799 en 10 points … suite
6 Opérationnel : Sécurité de l’exploitation et des réseaux

 Sécurité de l’exploitation : Gestion des évolutions du SI
 Séparation des fonctions : Développement et Exploitation, contrat infogérance, recette
 Sécurité du réseau et des échanges
7 Opérationnel : Contrôle d’accès logique

 Gestion et contrôle des accès, authentification, …
8 Opérationnel : Développement et maintenance des systèmes d’information

Politique sur l’utilisation des mesures cryptographiques, procédures de secours,
validation des données, impératif de sécurité avant développement du SI
9 Opérationnel :Continuité d’activité

Plan de secours : systèmes, réseaux, voix, autre services, unités opérationnelle, …
10 Opérationnel : Gestion de la conformité

Législation Française, conformité nationale et réglementaire
.

MEHARI (Méthode Harmonisée d’Analyse de Risques)
Synoptique de la démarche MEHARI

1983 Méthode MELISA
+
1983 Méthode MARION
=
1993 Méthode MEHARI
 Méthode d’analyse des risques
 Norme: 17799 et 13335
 Logiciel : RISICARE
Le Plan Stratégique de Sécurité (PSS)
Les Plans Opérationnels de Sécurité (POS)
Le Plan Opérationnel d'Entreprise (POE)
https://www.clusif.asso.fr/fr/production/mehari/
la démarche MEHARI
Une approche : D’analyse des risques informatiques en 8 étapes
(DESS 226 Ludovic Blin Université Paris Dauphine)
1. Identifier ce qu’il faut protéger.

2. Identifier les menaces.
3. Identifier les points faibles.
4. Estimer la probabilité des risques.
5. Calculer les prévisions de pertes annuelles pour chaque point faible (P.P.A.).
6. Identifier les mesures protectrices nécessaires.
7. Estimer (statistiquement) la réduction du PPA pour chaque mesure protectrice.
8. Sélectionner les meilleures mesures de protection (rapport prix /réduction du PPA)
Le PPA est calculé par des méthodes mathématiques. On peut citer la méthode basée sur le travail
de Robert Courtney et d’IBM. Cette méthode calcule le PPA en fonction de 2 valeurs V et P,
expression de la valeur du bien protégé et de la probabilité d’une menace, sur une échelle de 1 à 8.
On obtient ces valeur à partir de v :valeur du bien (en unité monétaire) et p : fréquence (en
probabilité par an ), et par les conversions logarithmiques suivantes :
P=3+log103p et V=log10V
Ce qui nous permet de calculer une expression du PPA :
PPA= (0,3) (10P+V-3)

On voit donc qu’il est possible de quantifier les risques avec une précision qui va dépendre des
méthodes employées. Ceci va permettre d’établir des règles de sécurité informatiques cohérentes et
adaptées aux objectifs.

Une approche financière :
Retour sur investissement en sécurité des SI
La problématique de la rentabilité des investissements en sécurité
 Coûts ponctuels: Dépenses de l’ensemble des dispositifs de sécurité et effets consécutif aux incidents
 Coûts récurrents : Dépenses d’exploitations, administration, maintenance et de contrôle de ces
dispositifs
 Coûts tangibles : coût du remplacement, assurance, perte de revenus, ….
 Coûts intangibles : Réputation, perte non chiffrable, Confiance, poursuite juridique, …
 RoSI (Return On Security Investment)

 Dérivé du ROI (Return On Investment), on peut l’interpréter comme le gain financier net d’un projet
en sécurité par rapport a son coût total dans une période donnée.
 Standard de fait publier par FIPS* :

 Prévision de Pertes Annuelles ALE*= Σ Coût i x fréquence de survenance i
 Avec i : incident de sécurité, Σ la somme annuelle des incidents de sécurité prévisibles ayant un coût
et une fréquence de survenance définie
Calcul du ROSI = ALE 1 –ALE 2 - CS

 Avec ALE 1 :Coût du dommage sans mesure de protection, ALE 2 :Coût du dommage avec mesure de
protection et CS :Coût de la solution mise en place.
 URL : https://www.clusif.asso.fr/fr/production/ouvrages/pdf/RoSI.pd
*FIPS: (Federal Information Processing Standards), ALE : (Annual Loss Expectancy),
Cramm (CCTA Risk Analysis and Management
Method)
Phases de la méthode Cramm
•identification de l'existant
•évaluation des menaces et des
vulnérabilités
•choix des remèdes
.
http://www.ysosecure.com/methode-securite/evolution-methodes-securite.asp

Démarche et Méthodes
 Ces méthodes actuelles séparent bien

différentes notions:
Notion informelle
Notion stratégique
Notion de périmètre
Vulnérabilités techniques
Menaces
…
Pour en déduire et évaluer les risques

afin de réaliser ou de prendre des
mesures sécurités.
http://www.ysosecure.com/methode-securite/evolution-methodes-securite.asp

Guide PSSI (Politique de Sécurité de Système d’Information)
Objectif
 Ce guide a pour objectif de fournir un support aux
responsables SSI pour élaborer une politique de sécurité
du ou des systèmes d’information (PSSI) au sein de leur
organisme.
 Ce guide présente une méthode et un ensemble de

principes de sécurité et de références, pour élaborer une
PSSI adaptée à un environnement. Il ne constitue pas
un résultat final qu’un responsable SSI peut recopier.

Composition : quatre sections

 Introduction qui définit la PSSI, son rôle, ses domaines
d’application, sa légitimité et sa place dans l’organisme
pour lequel elle a été élaborée
 Méthodologie qui présente la méthode d’élaboration de
politiques de sécurité ; élaboration qui se déroule en
quatre phases avec pour chacune des recommandations
 Référentiel des principes de sécurité ; seize domaines
sont couverts ; répartis en organisationnels, mise en
œuvre, techniques
 Liste de documents de références (critères d’évaluation,
textes législatifs, normes, codes d’éthiques, notes
complémentaires...)

Schémadirecteur
Schéma directeur
del’organisme
de l’organisme
Enjeux
Méthode
Méthode Principes Objectifs
de de
d’élaboration
d’élaboration sécurité sécurité Méthode
Méthode
depolitique
de politique PSSIglobale
PSSI globale d’analyse
d’analyse
desécurité
de sécurité desrisques
des risques
Règles de
(PSSI)
(PSSI) sécurité
PSSIspécifiques
PSSI spécifiques

PSSI
 Elaboration d’une PSSI avec EBIOS

 Organiser le projet
 Réaliser une étude EBIOS globale
 Extraire les données nécessaires dans l’étude
EBIOS
 Choix des principes de sécurité, rédaction des
règles de sécurité et des notes de synthèses
 Finalisation et validation de la PSSI
 Elaboration et validation du Plan d’action
EBIOS
(Expression des Besoins et Identification des Objectifs de Sécurité)
 Permet d’identifier les besoins de sécurité d’un

système
 Fournit :
 Une démarche
 Des techniques

Un outillage

Des classes de fonctionnalités issues d’ITSEC et à présent des
Critères Communs

EBIOS : Une démarche
 5 étapes pour une démarche complète :
 Étude du contexte
 Expression des besoins de sécurité
 Étude des menaces
 Identification des objectifs de sécurité
 Détermination des exigences de sécurité
 3 étapes dans notre contexte d’une politique de sécurité

EBIOS ® version2.0 : Démonstration de l’outil
Introduction
Fonctionnalités
Etude de sécurité
Synthèse d’étude
Auto formation
Base de connaissances
Administration système
Compléments d’informations

EBIOS ® version2.0 : Introduction
1. Introduction à EBIOS® 2. Fonctionnalités 3. Étude EBIOS® 4.

Synthèse d'étude 5. Etude de cas 6. Bases de connaissances 7.
Administration système 8. Compléments d'information
 Guide de la méthode à télécharger sur le site du SGDN / DCSSI.
 Le but de ce logiciel est de fournir aux experts sécurité un outil pratique leur
permettant de réaliser ces études EBIOS® de manière simple et sans nécessiter
de documents supplémentaires. L'application a de plus été conçue de façon à
s'adapter facilement à l'ensemble des domaines rencontrés (administrations de
l'État, organismes militaires, entreprises...)
 Installation : Le package regroupe les données suivantes : 1. Les binaires
de l'application 2. Une base de connaissances par défaut 3. La machine
virtuelle JAVA spécifique à la plate-forme.
 Utilisation : ebios.exe, sh ebios.sh

EBIOS ® version2.0 : Fonctionnalités
 L'application EBIOS® est décomposée en fonctionnalités distinctes, définissant

chacune une activité (boutons au démarrage de l’application) :
1. La réalisation d'études EBIOS®
2. La création de documents de synthèse d'études
3. L'étude de cas
4. La création de bases de connaissances
5. L'administration des composants du logiciel
 Authentification :
 Administrateur système :
 section Administration système -> Utilisateurs

EBIOS : Etude de sécurité 1/3
Caractéristiques d’une étude

 L'objectif d'une étude EBIOS® réside dans l'appréciation et le
traitement des risques SSI. Elle passe par une étude du contexte,
l'expression des besoins de sécurité, l'étude des menaces,
l'identification des objectifs de sécurité et la détermination des
exigences de sécurité.
 Cette étude est caractérisé par son Nom et Unité, sa Base de
connaissance et le contenu de l’étude (Questionnaires et audités,
étude du contexte, expression des besoins de sécurité, étude des
menaces, identification des objectifs, détermination des exigences de
sécurité et un complément).

 Fonctionnalités d’une étude

 Création, Chargement, Sauvegarde, Migration
 Activités
 Arborescences, Edition (activité et activité validée), validation ( d’une activité ou d’une étape)
 Impression d’une étude : Fonctions, complète, données, contextuelle
 Edition des activités

 Questionnaires et audités
 L'étape "Questionnaires et audités" consiste a recueillir auprès de différentes sources des informations
concernant l'organisme, le système-cible, ou tout autre objet relatif à l'étude en cours.
 Etude du contexte
 L'étape "Étude du contexte" a pour objectif d'identifier globalement le système-cible, de le situer dans son
environnement pour déterminer précisément la cible de l'étude.

 Étude du contexte suite :
1. Etude de l’organisme :Cela consiste à recueillir les éléments significatifs qui caractérisent
l'organisme concerné par le projet de sécurité
2. Etude du système-cible : Elle a pour but de préciser le contexte d'utilisation du système à
concevoir ou existant (système-cible), sujet de l'étude générale.
3. Détermination de la cible de l’Etude:Cette activité a pour but la détermination précise des entités
sur lesquelles s'appuie la réalisation des mesures de sécurité. C'est en effet par rapport à la cible
de l'étude que seront exprimés les objectifs de sécurité.
 Expression des besoins de sécurité : détermination des besoins de sécurité qui sont associés
aux objets sensibles et aux fonctions essentielles de la cible de l'étude (Fiches et synthèse des besoins).
 Etude des menaces : Elle a pour objectif la détermination des menaces pouvant affecter la cible de
l’étude ( Etude des vulnérabilités retenues et détermination des menaces)
 Identification des objectifs : Ils constituent la synthèse des résultats précédents, et ils expriment
ce que doit réaliser la cible de l'étude pour que le système-cible fonctionne de manière sécurisé.
 Détermination des exigences : Le but de cette étape est de sélectionner les exigences de
sécurité, qu'elles soient fonctionnelles ou d'assurance, afin de couvrir les objectifs de sécurité retenus
lors de l'étape précédente.

EBIOS ® version2.0 : Synthèse d’étude
 Création d’un document de synthèse d’étude EBIOS®

 Cette activité permet aux utilisateurs de générer un document de
synthèse regroupant le travail effectué sur l'ensemble d'une étude
EBIOS®. Le format utilisé pour les documents de synthèse varie suivant
les implémentations effectuées au sein du logiciel, le format HTML étant
fourni par défaut.
 Choix de l’étude, de la trame et génération du document

EBIOS ® version2.0 : Auto Formation
 L'auto-formation reprend le principe de la réalisation d'une étude EBIOS® en

proposant à l'utilisateur de suivre la création d'une étude de démonstration déjà
effectuée. Chaque activité de l'étude est accompagnée d'explications afin que
l'utilisateur comprenne les choix réalisés par les auteurs de l'étude et appréhende
l'utilisation des différentes interfaces.
 Etude de démonstration
 Assistant EBIOS®

EBIOS version2.0 : Base de connaissances
 Caractéristique :
 Ces bases de connaissances regroupent un ensemble de données concernant
le métier de la sécurité et exploitables pour remplir une étude. Les bases de
connaissances peuvent différer suivant les secteurs d'activité (civil, militaire...)
ou le contexte d'application du métier de la sécurité. Une base de
connaissances est fournie par défaut au sein du logiciel.
 CAPSEC fournit une étude dans le contexte des unités du CNRS
 Fonctionnalités
 Création, chargement, sauvegarde, migration, modification, importation

EBIOS ® version2.0 : Administration système
 2 types d’utilisateurs ( Auditeur et Administrateur)

Auditeur: Réalisation d'une étude EBIOS® . Création du document de
synthèse . Auto-formation
Administrateur: Réalisation d'une étude EBIOS® . Création du
document de synthèse . Auto-formation . Administration des bases de
connaissances . Administration système
Les Fonctions : Ajout, Modification, Suppression
 Trames de synthèse (documents XML)
 2 types
 Des données brutes au format associé à la trame (HTML, RTF...). Ces
données permettent de définir le contenu général du document de synthèse
 Des éléments 'Export' indiquant l'insertion à cet emplacement de données
provenant de l'étude à synthétiser. A ces éléments sont associés le type de
données à exporter (Questionnaires, contraintes...).
Les Fonctions : Ajout, Modification, Suppression

EBIOS ® version2.0 : Compléments d’informations
 Licence
 LIBRE USAGE L'utilisation et l'installation du logiciel sont libres, sur un
nombre quelconque de machines, avec un nombre quelconque de personnes
l'utilisant en même temps (si le logiciel le supporte) et sans aucune restriction
de lieux, de personnes, de groupes ou de domaines d'application. La loi de
fond applicable sera la loi du donneur de licence.
 CONDITIONS DE DUPLICATION Les copies sont autorisées sur
n'importe quel support sans restriction de nombre ou de personne, à la seule
condition qu'il s'agisse d'une copie intégrale du logiciel.
 Contacts
DIRECTION CENTRALE DE LA SÉCURITÉ DES SYSTÈMES
D'INFORMATION (DCSSI)
51 boulevard de Latour-Maubourg 75700 PARIS 07 SP France
Site HTTP : http://www.ssi.gouv.fr

EBIOS ® version2.0 : Compléments d’informations
 Licence
 LIBRE USAGE L'utilisation et l'installation du logiciel sont libres, sur un
nombre quelconque de machines, avec un nombre quelconque de personnes
l'utilisant en même temps (si le logiciel le supporte) et sans aucune restriction
de lieux, de personnes, de groupes ou de domaines d'application. La loi de
fond applicable sera la loi du donneur de licence.
 CONDITIONS DE DUPLICATION Les copies sont autorisées sur
n'importe quel support sans restriction de nombre ou de personne, à la seule
condition qu'il s'agisse d'une copie intégrale du logiciel.
 Contacts
DIRECTION CENTRALE DE LA SÉCURITÉ DES SYSTÈMES
D'INFORMATION (DCSSI)
51 boulevard de Latour-Maubourg 75700 PARIS 07 SP France
Site HTTP : http://www.ssi.gouv.fr

l'élaboration d'une Politique de Sécurité
Interne (P.S.I.)
 à l'usage du responsable de la sécurité du

système d'information
 Les fondements de la politique de sécurité interne
 La politique de sécurité interne
 Les bases de légitimité pour une politique de sécurité
interne

(P.S.I.)
 à l'usage du responsable de la sécurité du système d'information

 La politique de sécurité interne
 Représentation d'un système d'information et définitions
 Lien entre la politique de sécurité interne et les Critères
d'évaluation de la sécurité des systèmes informatiques (ITSEC)
 Lien entre la politique de sécurité interne et les Lignes directrices
régissant la sécurité des systèmes d'information (document de
l'OCDE)
 Finalités de la politique de sécurité interne
 Champ d'application de la politique de sécurité interne
 Les recommandations pour la mise en œuvre de la politique de
sécurité interne
(P.S.I.)

 Les bases de légitimité pour une politique de sécurité
interne
 Les bases de légitimité reposant sur la déontologie
 Les grands principes d'éthique
 Les codes d'éthique des métiers des technologies de
l'information
 Les bases de légitimité reposant sur la lutte contre les
accidents

(P.S.I.)
 Les bases de légitimité pour une P.S.I
 Les bases de légitimité reposant sur la préservation des intérêts
vitaux de l'État
 Les informations relevant du secret de défense
 La protection du secret et des informations concernant la défense
nationale et la sûreté de l'État
 La sécurité des systèmes d'information qui font l'objet d'une
classification de défense pour eux-mêmes ou pour les
informations traitées
 La protection du secret dans les rapports entre la France et les
états étrangers. La protection du secret et des informations pour
les marchés et autres contrats
 Les instructions techniques particulières pour la lutte contre les
signaux parasites compromettants
(P.S.I.) Les bases de légitimité
 Les informations ne relevant pas du secret de défense
 Les bases de légitimité reposant sur l'arsenal juridique pour la
lutte contre la malveillance
 Les bases de légitimité reposant sur les contrôles technologiques
 Le contrôle étatique dans le domaine de la cryptologie
 Le contrôle consumériste La normalisation La certification
 Les bases de légitimité reposant sur la préservation des intérêts
particuliers de l'organisme
 La mission ou le métier de l'organisme
 La culture de l'organisme
 Les orientations stratégiques et la structure de l'organisme
 Les relations de l'organisme avec son environnement : les contrats
passés avec des tiers Les ressources de l'organisme
l'élaboration d'une Politique de Sécurité
Interne (P.S.I.)
 Principes de sécurité liés à l'information

 Principes de sécurité liés aux biens physiques
 Principes de sécurité liés au personnel
 Principes de sécurité liés au cycle de vie du système
d'information

Comparatif

Critères de choix d'une méthode d'analyse des risques
Critères de choix l'origine géographique de la méthode, la culture du pays
jouant beaucoup sur le fonctionnement interne des entreprises et leur rapport au
risque
 la langue de la méthode, il est essentiel de maîtriser le vocabulaire employé
 l'existence d'outils logiciels en facilitant l'utilisation
 l'existence d'un club d'utilisateurs afin d'avoir un retour d'expériences
 La qualité de la documentation
 la facilité d'utilisation et le pragmatisme de la méthode
• la compatibilité avec une norme nationale ou internationale
• le coût de la mise en oeuvre
• la quantité de moyens humains qu'elle implique et la durée de mobilisation
• la taille de l'entreprise à laquelle elle est adaptée
• le support de la méthode par son auteur, une méthode abandonnée n'offre
plus la possibilité de conseil et de support de la part son éditeur

Critéres : ITSEC
« ITSEC » : CRITÈRES HARMONISÉS POUR

L'ÉVALUATION DE LA SÉCURITÉ DES
SYSTÈMES ET PRODUITS
INFORMATIQUES
Dans le but de favoriser le développement du marché des produits de
sécurité, plusieurs nations européennes (Allemagne, France, Pays-
Bas et Royaume-Uni) ont uni leurs efforts pour mettre au point un
ensemble unique de critères harmonisés pour l'évaluation de la
sécurité des systèmes et produits informatiques. Ces critères sont
destinés aux constructeurs, aux utilisateurs et aux organismes
d'évaluation et de certification prévus ou existants dans ces pays
et, pourquoi pas, dans une plus vaste zone.

Critéres : ITSEC
Ils visent à satisfaire à la fois les besoins des marchés de sécurité

commerciaux et gouvernementaux.
 Ils traitent de la sécurité sous ses trois aspects : confidentialité,
intégrité et disponibilité.
 Dans les ITSEC, le terme cible d'évaluation (Target Of
Evaluation ou TOE) est utilisé pour désigner un système ou

produit particulier soumis à une évaluation de sécurité.
 La partie la plus importante d'une cible de sécurité est, bien sûr,
la définition des fonctions de sécurité qui seront réalisées par

cette TOE l'ensemble de ces fonctions est désigné sous le terme
de fonctionnalité.

Critéres : ITSEC
 Identification et authentification - fonctions destinées à
établir et vérifier l'identité annoncée par un utilisateur.
 Contrôle d'accès - fonctions destinées à contrôler
l'utilisation des ressources et le flux d'informations entre objets,
utilisateurs et processus. Ceci comprend l'administration et la
vérification des droits d'accès.
 Imputabilité (Accountability) - fonctions destinees à enregistrer
l'exercice du droit à effectuer des actions engageant la sécurité
pour pouvoir remonter à leur auteur.
 Audit - fonctions concourant à détecter et investiguer les
événements qui peuvent constituer une menace pour la sécurité.

Critéres : ITSEC
 Réutilisation d'Objet - fonctions contrôlant la
réutilisation des objets supports de données en vue
d'éviter les flux non contrôlés d'informations.
 Fidélité (Accuracy) - fonctions destinées à s'assurer
que les données n'ont pas été modifiées indûment.
 Fiabilité du service - fonctions destinées à s'assurer
que les ressources sont accessibles et disponibles à la
demande d'une entité autorisée (utilisateur ou
processus).

Critéres : ITSEC
 Echange de données - fonctions qui garantissent la

sécurité des données sur les voies de transmission.
 Il n'existe pas de restriction pour spécifier la fonctionnalité dans
une cible de sécurité. On trouve certes, en annexe des ITSEC, 10
classes de fonctionnalités prédéfinies et il est probable que
d'autres classes seront définies plus tard pour répondre à l'attente
du marché à mesure de l'évolution des besoins, mais la
fonctionnalité peut aussi être établie explicitement, ou bien
comme la combinaison de classes de fonctionnalité et de
fonctions additionnelles définies de façon précise, ou encore par
référence à des normes existant par ailleurs.

Critéres : ITSEC
 Un système TI ou un produit TI (issu des

Technologies de l'Information) aura ses exigences
propres pour maintenir la confidentialité, l'intégrité et
la disponibilité. Pour satisfaire à ces exigences, il
implémentera un certain nombre de mesures techniques
de sécurité, appelées dans ce document fonctions
dédiées à la sécurité, qui recouvrent par exemple des
domaines tels que le contrôle d'accès, l'audit et la
reprise sur incident.

Critéres : ITSEC
 Dans ce contexte, la sécurité des TI est caractérisée par : la
confidentialité - prévention d'une divulgation non autorisée de
l'information ; l'intégrité - prévention d'une modification non
autorisée de l'information ; la disponibilité - prévention d'un
déni non autorisé d'accès à l'information ou à des ressources.
 Une confiance appropriée dans ces fonctions sera nécessaire :
dans le présent document, on emploie le terme d'assurance, qu'il
s'agisse de la confiance dans la conformité des fonctions dédiées
à la sécurité (tant du point de vue de leur développement que de
celui de leur exploitation) ou de la confiance dans l'efficacité de
ces fonctions.

Critéres : ITSEC Les sept niveaux d'évaluation :
 Niveau E0 : Ce niveau représente une assurance insuffisante.
 Niveau E1 : A ce niveau, il doit exister une cible de sécurité et une

description informelle de la conception générale de la TOE. Les tests
fonctionnels doivent indiquer que la TOE satisfait à sa cible de sécurité.
 Niveau E2 : Outre les exigences du niveau E1, il doit exister une description
informelle de la conception détaillée. Les éléments de preuve des tests
fonctionnels doivent être évalués. Il doit exister un système de gestion de
configuration et un processus approuvé de diffusion.
 Niveau E3 : En plus des exigences du niveau E2, le code source et/ou les
schémas descriptifs des matériels correspondants aux mécanismes de sécurité
doivent être évalués. Les éléments de preuve des tests de ces mécanismes
doivent être évalués.

Critéres : ITSEC Les sept niveaux d'évaluation :
 Niveau E4 : En plus des exigences du niveau E3, il doit exister un modèle

formel sous-jacent de politique de sécurité supportant la cible d'évaluation.
Les fonctions dédiées à la sécurité, la conception générale et la conception
détaillée doivent être spécifiées en style semi-formel.
 Niveau E5: En plus des exigences du niveau E4, il doit exister une
correspondance étroite entre la conception détaillée et le code source et/ou
les schémas descriptifs des matériels.
 Niveau E6 : En plus des exigences du niveau E5, les fonctions dédiées à la
sécurité ainsi que la conception générale doivent être spécifiées en style
formel de manière cohérente avec le modèle formel sous-jacent de politique
de sécurité.

Les Critères communs (CC)
Les Critères communs (CC) sont une norme

internationale (ISO 15408) portant sur
l’évaluation de produits et systèmes de sécurité
des TI.

Le Livre Orange
 Le National Computer Security Center (NCSC)
a réalisé le document Trusted Computer System
Evaluation Criteria pour servir de base à
l'évaluation des systèmes informatiques. Ses
auteurs qui n'ont pas voulu que le document reste
sur des étagères lui ont mis une couverture orange,
ce qui a conduit à abréger son nom en Livre
Orange.

Le Livre Orange
 Le US Department of Defense l'a
publié en 1985.
 Le Livre Orange n'est pas facile à lire. Il définit quatre
divisions, de la division D (protection minimale) à la
division A (protection vérifiée). À l'intérieur de ces quatre
divisions, il y a en tout sept niveaux. Chaque niveau inclut
tous les critères d'évaluation de sécurité des niveaux
précédentes, si bien que les niveaux sont placés les uns sur
les autres. Chaque niveau est désigné par la lettre de sa
division suivi d'un nombre. Plus le nombre est grand, plus
la sécurité est grande.

Le Livre Orange
 D - Protection minimale
 Un système qui entre dans la division D
ne sera pas classé. Ces systèmes n'ont
fondamentalement pas d'autre sécurité que
la sécurité physique. Les PC fonctionnant
avec MS-DOS, ainsi que les Macintosh,
entrent tous dans cette division.

Le Livre Orange
 C1 - Protection de sécurité
discrétionnaire
 Une sécurité discrétionnaire fait que chaque utilisateur du
système a le parfait contrôle sur les objets qui lui
appartiennent. Il peut restreindre l'accès en lecture, en
écriture, ou en exécution. Les droits et privilèges d'accès
sont basés sur trois catégories d'utilisateurs: le propriétaire,
le groupe et tous les autres. L'utilisateur doit s'identifier à
l'aide d'un nom de «login» et d'un mot de passe. La plupart
des systèmes UNIX sont classés en C1.

Le Livre Orange
 C2 - Protection d'accès contrôlé
 Comme C1 avec, en plus, l'audit et une authentification
améliorée.
 L'audit crée des enregistrements d'événements liés à la
sécurité. L'amélioration d'authentification exige que les
mots de passe chiffrés doivent être cachés aux utilisateurs
non privilégiés. Cacher les mots de passe chiffrés
contribue à empêcher les tentatives de deviner des mots de
passe.

Le Livre Orange
 B1 - Protection de sécurité avec labels
Comme C2 avec, en plus, l'exigence d'une preuve

informelle de la validité du modèle de sécurité.
B1 est le premier niveau qui supporte une sécurité à niveau
multiple. Elle comprend un contrôle d'accès impératif qui
empêche le propriétaire de changer les droits d'accès d'un
objet sous contrôle impératif. Les labels ajoutent des
descriptions plus complètes du niveau de sécurité et de la
catégorie des sujets et objets.

Le Livre Orange
 B2 - La protection structurée
 Comme B1 avec, en plus, l'exigence d'une preuve
formelle de la validité du modèle de sécurité.
 La B2 exige que tout objet ait un label. Les périphériques
peuvent posséder un seul ou plusieurs niveaux de sécurité
et sont capables de préserver les labels des objets sous leur
garde. B2 limite les canaux cachés qui impliquent toujours
une utilisation inappropriée du système en permettant des
moyens indirects de communication entre un sujet
travaillant à un haut niveau avec un autre processus
s'exécutant à un niveau plus bas. Un exemple de B2 est le
système Multics de Honeywell, l'ancêtre et précurseur du
système UNIX.

Le Livre Orange
 B3 - Les domaines de sécurité
 Comme B2 avec, en plus, l'isolement des domaines de
sécurité avec la partie matérielle.
 Le domaine de sécurité peut faire partie de la base de
traitement de confiance. La partie matérielle de la gestion
de mémoire protège le domaine de sécurité de l'accès ou de
la modification par le logiciel opérant dans d'autres
domaines.
 Les systèmes B3 doivent fournir un chemin de
confiance qui garantit à l'utilisateur que le terminal utilisé
est connecté directement au logiciel de confiance.

Le Livre Orange
 A1 - La conception vérifiée
 Comme B3 avec, en plus, l'exigence d'une preuve
mathématique formelle de la validité du modèle de
sécurité.
 Ce classement nécessite également une analyse
formelle des canaux cachés, une spécification formelle au
plus hau niveau, et une distribution de confiance. Très
peu de systèmes atteignent le niveau A1. Le système
SCOMP de Honeywell fait partie de ce groupe sélect.

Le Livre Orange
 Une version intégrale du Livre Orange en
format HTML se trouve à l'adresse
 http://www.radium.ncsc.mil/tpep/library/rai
nbow/5200.28-STD.html.

CLASSES DE FONCTIONNALITE
http://www.scssi.gouv.fr/document/docs/ITSEC/itsec-A.html
Classe de fonctionnalité F-C1

 Objectif : L'exemple de classe F-C1 est
dérivé des exigences fonctionnelles de la

classe C1 du TCSEC américain. Elle offre
un contrôle d'accès discrétionnaire ("besoin
d'en connaître").

Classe de fonctionnalité F-C2

 Objectif : L'exemple de classe F-C2 est dérivé des
exigences fonctionnelles de la classe C2 du TCSEC
américain. Elle offre un contrôle d'accès discrétionnaire
plus fin que la classe C1, en rendant les utilisateurs
individuellement responsables de leurs actions à travers
des procédures d'identification, l'audit des événements
relatifs à la sécurité et l'isolation des ressources.-

Classe de fonctionnalité F-B1

 Objectif
 L'exemple de classe F-B1 est dérivé des exigences
fonctionnelles de la classe B1 du TCSEC américain. En
plus du contrôle d'accès discrétionnaire, elle introduit des
fonctions pour maintenir des marques de sensibilité et les
utilise pour faire respecter un ensemble de règles de
contrôle d'accès par mandats à tous les sujets et à tous les
objets de stockage sous son contrôle. Il est possible
d'attribuer de façon précise un label aux informations
exportées.-


 Objectif
fonctionnelles de la classe B2 du TCSEC

américain. Elle étend le contrôle d'accès par
mandats à tous les sujets et objets et renforce les
exigences d'authentification de la classe B1.-


 Objectif
fonctionnelles des classes B3 et A1 du TCSEC américain.
En plus des fonctions de la classe B2, elle fournit des
fonctions pour permettre la mise en œuvre de rôles
distincts d'administration de la sécurité, et l'audit est
étendu pour signaler les événements touchant à la
sécurité.

 Les cinq exemples de classes de fonctionnalité F-

C1, F-C2, F-B1, F-B2, et F-B3 forment une
hiérarchie puisqu'elles sont issues des exigences
fonctionnelles des classes hiérarchiques du
TCSEC. Dans la description de ces classes, les
parties de chaque classe qui sont nouvelles ou qui
ont été changées par rapport aux classes
précédentes sont imprimées en gras.

 D'autres classes de fonctionnalité basées sur une

hiérarchie pourront être créées dans le futur, par
des organismes de normalisation et des
organisations industrielles, pour aborder d'autres
types d'objectifs de sécurité (par exemple pour
l'intégrité et la disponibilité). En attendant, les
classes F-IN, F-AV, F-DI,F-DC, et F-DX ont été
incluses pour illustrer la large gamme d'exigences
de sécurité qui peuvent être exprimées sous la
forme d'une classe de fonctionnalité prédéfinie

Classe de fonctionnalité F-IN

 Objectif : L'exemple de classe de fonctionnalité F-IN
concerne les TOE pour lesquelles il y a des exigences
élevées d'intégrité pour les données et les programmes.
De telles exigences peuvent être nécessaires par exemple
pour des TOE bases de données.
Classe de fonctionnalité F-AV
 Objectif : La classe de fonctionnalité F-AV impose des
exigences élevées pour la disponibilité d'une TOE
complète ou de fonctions particulières d'une TOE. De
telles exigences sont importantes par exemple pour des
TOE qui contrôlent des processus industriels.

Classe de fonctionnalité F-DI

 Objectif : L'exemple de classe de fonctionnalité F-DI
impose des exigences élevées en ce qui concerne la
préservation de l'intégrité des données au cours de leur
échange.
Classe de fonctionnalité F-DC
 Objectif : L'exemple de classe de fonctionnalité F-DC est
destiné aux TOE très exigeantes en matière de
confidentialité des données au cours de leur échange. Un
équipement cryptographique est un exemple de candidat
pour cette classe.

 Classe de fonctionnalité F-DX

Objectif :
L'exemple de classe de fonctionnalité F-DX est destiné aux
réseaux très exigeants en matière de confidentialité et
d'intégrité des informations à échanger. Par exemple,
cela peut être le cas lorsque des informations sensibles
doivent être échangées à travers des réseaux non
protégés (par exemple des réseaux publics).

Webographie
 http://www.callio.fr/
 https://www.clusif.asso.fr/
 http://www.cramm.com
 http://www.ssi.gouv.fr/fr/dcssi/
 http://www.ysosecure.com
 La Sécurité Informatique DESS 226 Ludovic Blin Université Paris Dauphine
http://memoireonline.free.fr/securiteinfo_ibm.htm
 EBIOS Cyril DEMONCEAUX Elève-Ingénieur Supinfo Paris
Promotion SUPINFO 2004 http://www.supinfo-projects.com/fr/2004/ebios/

Sensibilisation Sécurité Informatique

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sensibilisation Sécurité Informatique

Transféré par

Droits d'auteur :

Formats disponibles

Sensibilisation à la sécurité informatique

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 2

 Elle doit être vue globalement! "d'employer un

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 3

”Acheter une super porte blindée et oublier de

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 4

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 5

 Permet de structurer votre démarche pour atteindre les

 Elaboration du cahier des charges au suivi de la solution

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 6

 Des préconisations techniques et choix

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 7

 les aspects didactiques en aidant le

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 10

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 11

Evaluer les risques internes et externes liés à

Connaître toutes les possibilités d’attaque sur votre réseau

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 12

Que faire si le pire devait

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 13

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 14

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 15

 Analyses de différentes démarches, normes et

gouvernement BRITANNIQUE (la BS 7799)

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 16

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 17

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 18

 ISO/IEC 17799:2000, qui est un catalogue regroupant 36 objectifs de

 La BS 7799-2:2002, présente un système de gestion de la sécurité en 4

 À travers dix domaines, cette norme

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 19

Politique de sécurité  La norme BS 7799 / Iso 17799 est

Sécurité Sécurité physique

Aux travers des domaines de contrôles, cette

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 20

1 Management : Politique de sécurité

2 Management : Organisation Interne

3 Management : Classification et contrôle actifs

4 Environnement Humain et physique : Sécurité liée aux Personnes

5 Environnement Humain et physique: Sécurité physique et de l’environnement

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 21

6 Opérationnel : Sécurité de l’exploitation et des réseaux

7 Opérationnel : Contrôle d’accès logique

8 Opérationnel : Développement et maintenance des systèmes d’information

9 Opérationnel :Continuité d’activité

10 Opérationnel : Gestion de la conformité

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 22

Synoptique de la démarche MEHARI

1. Identifier ce qu’il faut protéger.

PPA= (0,3) (10P+V-3)

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 26

 RoSI (Return On Security Investment)

 Standard de fait publier par FIPS* :

Calcul du ROSI = ALE 1 –ALE 2 - CS

Phases de la méthode Cramm

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 28

 Ces méthodes actuelles séparent bien

Pour en déduire et évaluer les risques

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 29

 Ce guide présente une méthode et un ensemble de

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 30

Composition : quatre sections

© Cours 2005 / O.Servas Sensibilisation à la sécurité Informatique 31