Méthodologie - ipom.free.fripom.free.fr/M2/SECURITE/Cours/MethodologieV2.pdf · " Du bon sens ... "Avant d'aborder la technique : la sécurité à 100% n'existe pas, Il y a nécessairement

Sensibilisation à la sécurité informatique

Méthodologie

Intervenant : Servas OlivierRéalisation : Octobre /99Màj: Février 2001 /Décembre 2001 /septembre 2007

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

IntroductionII. 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

Sommaire


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éthodologie


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"

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.

L'aspect méthodologie


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 normepermet de détecter, d'analyser et de diminuer les risques liés à l'information.


BS 7799 / ISO 17799

Politique de sécurité

SécuritéDe l’organisation

ClassificationEt contrôle des actifs

Conformité

SécuritéRessources Humaines

Contrôle d’accès

Développement et maintenance

Sécurité physiqueEt environnementale

Gestion des communications et des opérations Continuité de service

Aspect organisationnel Aspect physique Aspect Technique

Source http://www.callio.fr/bs7799

La norme BS 7799 / Iso 17799 est développée pour créer une structure commune de sécurité de l'information et ainsi couvrir les aspects techniques, administratifs et juridiques.

Aux travers des domaines de contrôles, cette norme permet de détecter, d'analyser et de diminuer les risques liés à l'information.

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’informationPolitique 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)

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/

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

https://www.clusif.asso.fr/fr/production/mehari/5.asp






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=log10VCe 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),

https://www.clusif.asso.fr/fr/production/ouvrages/pdf/RoSI.pd

https://www.clusif.asso.fr/fr/production/ouvrages/pdf/RoSI.pd


Cramm (CCTA Risk Analysis and Management Method)

http://www.ysosecure.com/methode-securite/evolution-methodes-securite.asp

Phases de la méthode Cramm

•identification de l'existant •évaluation des menaces et des vulnérabilités •choix des remèdes .

http://www.cramm.com/


Démarche et Méthodes

http://www.ysosecure.com/methode-securite/evolution-methodes-securite.asp

Ces méthodes actuelles séparent bien différentes notions:

Notion informelleNotion stratégiqueNotion de périmètreVulnérabilités techniquesMenaces …

Pour en déduire et évaluer les risques afin de réaliser ou de prendre des mesures sécurités.


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...)



PSSI globalePSSI globale

Méthode d’élaboration de politique de sécurité

(PSSI)

Méthode d’élaboration de politique de sécurité

(PSSI)

Principes Principes de de

sécuritésécurité Méthode d’analyse

des risques

Méthode d’analyse

des risques

Objectifs Objectifs de de

sécuritésécurité

Schéma directeur de l’organisme

Schéma directeur de l’organisme

EnjeuxEnjeux

PSSI spécifiques PSSI spécifiques

Règles de Règles de sécuritésécurité


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.

ContactsDIRECTION 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.

ContactsDIRECTION 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'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

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 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.)


à l'usage du responsable de la sécurité du système d'information 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 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

(P.S.I.) Les bases de légitimité


à l'usage du responsable de la sécurité du système d'information

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

l'élaboration d'une Politique de Sécurité Interne (P.S.I.)


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



« 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


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é.

Critéres : ITSEC Les sept niveaux d'évaluation :


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.

Les Critères communs (CC)


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'apublié 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.


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/rainbow/5200.28-STD.html.

Le Livre Orange


CLASSES DE FONCTIONNALITEhttp://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").


CLASSES DE FONCTIONNALITEhttp://www.scssi.gouv.fr/document/docs/ITSEC/itsec-A.html

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.-

CLASSES DE FONCTIONNALITE



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.-



http://www.scssi.gouv.fr/document/docs/ITSEC/itsec-A.html


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-DXObjectif : 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/

http://www.callio.fr/

https://www.clusif.asso.fr/



http://www.ssi.gouv.fr/fr/dcssi/







http://www.ysosecure.com/

http://memoireonline.free.fr/securiteinfo_ibm.htm