Cours 1 G.Noël
This commit is contained in:
parent
62b81548a2
commit
85d3328300
384
Cours Audit & Sécurité réseau/Audit réseau - Cours G. Noël.md
Normal file
384
Cours Audit & Sécurité réseau/Audit réseau - Cours G. Noël.md
Normal file
|
@ -0,0 +1,384 @@
|
||||||
|
*#JeSaisPasPourquoiJAiMarquéÇa*
|
||||||
|
|
||||||
|
- iso 15408
|
||||||
|
|
||||||
|
- EBIOS
|
||||||
|
|
||||||
|
- ISO 274/271
|
||||||
|
|
||||||
|
# Introduction
|
||||||
|
|
||||||
|
Définition du Système d'Information : il n'est pas forcément éléectronique et peut être dans toute structure ou organisation qui traite/contrôle/stocke/partage/collecte de l'information.
|
||||||
|
|
||||||
|
Différencier :
|
||||||
|
|
||||||
|
- Data (Élément brut)
|
||||||
|
|
||||||
|
- Information (Référentiel permettant d'interpréter la data)
|
||||||
|
|
||||||
|
- Connaissance (Extrapolation des informations)
|
||||||
|
|
||||||
|
Un SI se schématise autour du concept du traitement comme un bloc : les données y entrent (in), le traitement subit des perturbations et les données en sortent (out) avec de la perte. La sécurisation d'un SI revient à limiter les perturbations et les pertes.
|
||||||
|
|
||||||
|
# L'iso 15408
|
||||||
|
|
||||||
|
ISO = International Standard Irganisation
|
||||||
|
|
||||||
|
La 15408 a été créée pour donner des normes de sécurité à respecter partout.
|
||||||
|
Ainsi, 15 pays (UE, USA, Jpaon, Canada...) partagent des critères communs d'évaluation de sécurité de l'information.
|
||||||
|
|
||||||
|
(ISO 9000: qualité)
|
||||||
|
|
||||||
|
## PPST TOE
|
||||||
|
|
||||||
|
C'est un profil de protection
|
||||||
|
|
||||||
|
- **PP** : Vision de l'utilisateur du SI
|
||||||
|
|
||||||
|
- Use cases - indépendant de toute implémentation
|
||||||
|
|
||||||
|
- Définit les objectifs de sécurité à atteindre via :
|
||||||
|
|
||||||
|
- l'environnement de travail
|
||||||
|
|
||||||
|
- les exigences fonctionnelles
|
||||||
|
|
||||||
|
- **ToE** : Cibles de l'évaluation (ToE)
|
||||||
|
|
||||||
|
- Tout composant du SI pouvant influer sur la sécurité (câbles, procédures...)
|
||||||
|
|
||||||
|
- **ST** : Cible de sécurité
|
||||||
|
|
||||||
|
- Spécification technique de la sécurité
|
||||||
|
|
||||||
|
- Vision des dev/admin/intégrateurs
|
||||||
|
|
||||||
|
- Specifications fonctionnelles
|
||||||
|
|
||||||
|
- Définition des risques et menaces
|
||||||
|
|
||||||
|
- Définition des mesures de sécurité à employer
|
||||||
|
|
||||||
|
Pour faciliter l'implémentation de cet ISO à l'international, on définit des classes de sécurité.
|
||||||
|
Chaque classe a des sous-classes et des sous-sous-classes
|
||||||
|
|
||||||
|
1. Audit Sécu
|
||||||
|
|
||||||
|
Test/attaque du système (via des outils gratuits : Ness/OpenVas)
|
||||||
|
|
||||||
|
2. Communication
|
||||||
|
|
||||||
|
Tous les moyens d'échanger l'information dans l'organisation (même non informatique)
|
||||||
|
|
||||||
|
3. Suppport cryptographique
|
||||||
|
|
||||||
|
Gestion du codage (tout le monde peut décoder) ou du chiffrage (utilisation de clés, symétrie/asymétrie)
|
||||||
|
|
||||||
|
4. Protection de la user data
|
||||||
|
|
||||||
|
Identification : déclarer l'identité != Authentification : vérifier l'identité
|
||||||
|
|
||||||
|
5. Protection de la vie privée
|
||||||
|
|
||||||
|
Tout utilisateur doit être informé qu'on peut récupérer ses infos. Autrement toute la récupération de données est inutilisable légalement.
|
||||||
|
|
||||||
|
6. Protection des ToE
|
||||||
|
|
||||||
|
7. Authentification et Identificxation
|
||||||
|
|
||||||
|
8. Admin Sécu
|
||||||
|
|
||||||
|
9. Utilisation des ressources
|
||||||
|
|
||||||
|
10. Accès ToE
|
||||||
|
|
||||||
|
11. Chemins et canaux de confiance
|
||||||
|
|
||||||
|
**3 grands critères émergent de ces définitions**
|
||||||
|
|
||||||
|
- **Confidentialité** : Les bonnes personnes accèdent à l'information
|
||||||
|
|
||||||
|
- **Disponibilité** : L'accès à l'information est possible
|
||||||
|
|
||||||
|
- **Intégrité** : L'information n'est pas corrompue
|
||||||
|
|
||||||
|
- (en option) **Non répudiation** : Le fait d'avoir toujours une trace - ne pouvoir nier avoir fait quelque chose
|
||||||
|
|
||||||
|
# Implémentations de l'iso
|
||||||
|
|
||||||
|
## MARION
|
||||||
|
|
||||||
|
Méthode d'Analyse des Risques Informatiques et Optimisation par Niveau
|
||||||
|
Fruit de la collaboration entre DGA & CLUSIF dans les années 80
|
||||||
|
Dernière MàJ en 1998
|
||||||
|
|
||||||
|
Il s'agit de 27 indicateurs pour évaluer le niveau global de sécurité du SI, chacun a une note entre 0 et 4.
|
||||||
|
|
||||||
|
On y trouve les concepts de :
|
||||||
|
|
||||||
|
- vulnérabilité : point faible
|
||||||
|
|
||||||
|
- menace : potentiel d'exploitation/de déclenchement du point faible / de l'opportunité
|
||||||
|
|
||||||
|
- risque : impact, probabilité, occurence, proba occurence * score d'impact = score de risque
|
||||||
|
|
||||||
|
Déroulement en 4 phases :
|
||||||
|
|
||||||
|
1. Préparation : définir les limites de l'audit
|
||||||
|
|
||||||
|
- Qu'est-ce qui est évalué ?
|
||||||
|
|
||||||
|
- Dans quelles conditions ?
|
||||||
|
|
||||||
|
- ToE, individus
|
||||||
|
|
||||||
|
2. Audit : on fait l'audit
|
||||||
|
|
||||||
|
3. Analyse : Dépouiller et attribuer des scores aux 27 indicateurs
|
||||||
|
|
||||||
|
- Déterminer lesquels sont mauvais...
|
||||||
|
|
||||||
|
4. Plan d'action : Comment corriger
|
||||||
|
|
||||||
|
L'implémentation est relativement libre
|
||||||
|
|
||||||
|
## MEHARI
|
||||||
|
|
||||||
|
C'est l'évolution de MARION (un peu comme des pokémons)
|
||||||
|
MÉthode Harmonisé d'Analyse des RIsques
|
||||||
|
Issu du CLUSIF
|
||||||
|
Méthode d'analyse quantitative des risques avec des questionnaires pré-définis et de règles de notation des critères
|
||||||
|
|
||||||
|
L'idée de base est qu'on ne fait pas disparaître un risque, on le diminue. Il faut donc
|
||||||
|
|
||||||
|
- accepter l'idée de risque résiduel
|
||||||
|
|
||||||
|
- se dire que le plan d'action n'a pas pour but de faire disparaitre tous les risques
|
||||||
|
|
||||||
|
C'est arrivé pile dans la grande époque de la gestion de projet avec le cycle en V
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# EBIOS
|
||||||
|
|
||||||
|
Évaluation des Besoins et Identification des Objectifs de Sécurité
|
||||||
|
Élaboré par la DGA et repris par le Ministère de l'Intérieur
|
||||||
|
|
||||||
|
5 modules :
|
||||||
|
|
||||||
|
1. Étude du contexte (lié à 2, 3 et 4)
|
||||||
|
|
||||||
|
2. Étude des évènements redoutés (lié à 1 et 4)
|
||||||
|
|
||||||
|
3. Étude des scénarii de menace (lié à 1 et 4)
|
||||||
|
|
||||||
|
4. Étude des risques (lié à 1, 2, 3 et 5)
|
||||||
|
|
||||||
|
5. Mesures de sécurité (lié à 4)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Étude du contexte
|
||||||
|
|
||||||
|
Définir :
|
||||||
|
|
||||||
|
1. Le périmètre
|
||||||
|
|
||||||
|
2. Les acteurs
|
||||||
|
|
||||||
|
3. Le niveau de sécurité
|
||||||
|
|
||||||
|
4. Les biens essentiels : éléments qu'on souhaite fournir (ex: service de messagerie)
|
||||||
|
|
||||||
|
5. Les biens supports : éléments permettant de concrétiser un bien support (ex: serveur Exchange)
|
||||||
|
|
||||||
|
6. Identifier les risques
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Définir le cadre :
|
||||||
|
|
||||||
|
- définir les limites
|
||||||
|
|
||||||
|
- vérifier la légitimité
|
||||||
|
|
||||||
|
- définir les paramètres à prendre en compte
|
||||||
|
|
||||||
|
- définir l'existant
|
||||||
|
|
||||||
|
- définir les sources de menace
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Définir les acteurs. L'outil de définition est l'humain. On remplit un tableau selon la matrice RACI :
|
||||||
|
|
||||||
|
- Responsable
|
||||||
|
|
||||||
|
- Autorité
|
||||||
|
|
||||||
|
- Consulté
|
||||||
|
|
||||||
|
- Informé
|
||||||
|
|
||||||
|
Pour chaque fonctionnalité, on indique le rôle de chaque acteur du projet
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Les fonctionnalités sont liées ensuite aux Biens Essentiels (BE), eux même liés à l'identifiation des acteurs liés, eux même liés aux Bien Supports (BS), eux-même liés à un "propriétaire".
|
||||||
|
|
||||||
|
Différents types de BS : Réseau, Logiciel, Matériel, Personnes, Organisation
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Puis identification des contraintes aux fonctionnalités des BE. Elles peuvent être :
|
||||||
|
|
||||||
|
- techniques
|
||||||
|
|
||||||
|
- humaines
|
||||||
|
|
||||||
|
- conjoncturelles
|
||||||
|
|
||||||
|
- juridiques
|
||||||
|
|
||||||
|
- d'organisation
|
||||||
|
|
||||||
|
- stratégiques
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Lister les éléments de sécurité en place et évaluer leur pertinence "à priori"
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Étudier des sources de menace, il existe pour ça des listes pré-établies de sources. Les grandes catégories :
|
||||||
|
|
||||||
|
- Humaines, naturelles, techniques
|
||||||
|
|
||||||
|
- Compétentes, Non-compétentes
|
||||||
|
|
||||||
|
- Hostiles, Non-hostiles
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Préparer les métriques. pas entre 0&4 comme MARION et MEHARI : on peut choisir nous-même.
|
||||||
|
EBIOS a des métriques par défaut, on peut les changer ou en prendre de nouvelles (pour les besoins métier par exemple). Cela permet :
|
||||||
|
|
||||||
|
- d'évaluer les risques liés à la sécurité
|
||||||
|
|
||||||
|
- de redéfinir la gravité et la vraisemblance d'un risque
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Enfin, déterminer les bien via un listage et une matrice de dépendance entre BE et BS ("Si je touche à tel serveur, ques autres services vont être impactés ?").
|
||||||
|
À chaque fois, on liste les mesures de sécurité mises en place
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Étude des évènements redoutés
|
||||||
|
|
||||||
|
- Déterminer les besoins en sécurité des biens essentiels (CDI)
|
||||||
|
|
||||||
|
- Impacts en cas de non respect (financiers, juridiques, sur l'image de marque, sur tiers...)
|
||||||
|
|
||||||
|
- Identifier les sources de menace
|
||||||
|
|
||||||
|
Tout cela permet de définir un évènement redouté (ex: utilisateur non-averti non hostile, rend indisponible le service de messagerie par flood de spam)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Déterminer et qualifier les évènements redoutés.
|
||||||
|
Il existe des listes préétablies d'évènements redoutés, on peut aussi créer les siens.
|
||||||
|
Il faut étudier ce qui peut mal se passer **sans se foncaliser sur la source**
|
||||||
|
|
||||||
|
En entrée :
|
||||||
|
|
||||||
|
- Liste des biens et éléments de sécurité
|
||||||
|
|
||||||
|
- Échelles de mesure
|
||||||
|
|
||||||
|
- Liste des sources de menace (pas de comment : juste les sources)
|
||||||
|
|
||||||
|
- Liste des évènements pré-établis
|
||||||
|
|
||||||
|
Le but est de déterminer la vraisemblance d'un évènement redouté, puis une classification des évènements du plus au moins grave.
|
||||||
|
|
||||||
|
Ex :
|
||||||
|
|
||||||
|
|
||||||
|
On établit à partir de ça le **palmarès de la phobie des évènements**
|
||||||
|
|
||||||
|
| 3 | - <br/>- |
|
||||||
|
| --- | --------------------------------------- |
|
||||||
|
| 2 | - Impossibilié d'établir un devis<br/>- |
|
||||||
|
| 1 | - <br/>- |
|
||||||
|
| 0 | - <br/>- |
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Étude des scenarii de menace
|
||||||
|
|
||||||
|
- Estimer et identifier les scenarii pouvant amener aux évènements redoutés
|
||||||
|
|
||||||
|
- Quelles sont les vulnérabilités exploitables et quels sont les moyens de les utiliser ?
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Même logique que précédemment, centré sur "comment les choses pourraient mal tourner ?"
|
||||||
|
|
||||||
|
Le tableau est donc plutôt du genre :
|
||||||
|
|
||||||
|
| Scénario | Source | Vraisemblance |
|
||||||
|
| ------------------------------------ | -------------------------------------------------------------- | ------------- |
|
||||||
|
| Menace externe qui rend Wifi indispo | Employé indélicat<br/>Maintenance<br/>Virus<br/>Script-kiddies | 3 forte |
|
||||||
|
|
||||||
|
**Attention** : un évènement redouté (est-ce que c'est grave ?) **!=** un scénario (est-ce qu'il y a des chances que ça arrive ?)
|
||||||
|
|
||||||
|
On établit aussi un palmarès
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Étude des risques
|
||||||
|
|
||||||
|
- Mise en évidence des risques
|
||||||
|
|
||||||
|
- Évaluation - Quantification
|
||||||
|
|
||||||
|
- Détermination des risques à corriger en premier
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Ça consiste à croiser les flux :
|
||||||
|
|
||||||
|
- Quels sont les impacts si évènement arrive ?
|
||||||
|
|
||||||
|
- Quelle vraisemblance pour un scénario menant à cet évènement ?
|
||||||
|
|
||||||
|
- Est-ce grave pour notre entreprise, dnas le périmètre de l'étude ?
|
||||||
|
|
||||||
|
Risque = évènement (score impact) + scénario y amenant (score vraisemblance)
|
||||||
|
|
||||||
|
On a besoin de choisir l'option de traitement des risques :
|
||||||
|
|
||||||
|
- Traiter le risque :
|
||||||
|
|
||||||
|
- Diminuer l'impact
|
||||||
|
|
||||||
|
- Diminuer la vraisemblance
|
||||||
|
|
||||||
|
- Transférer le risque
|
||||||
|
|
||||||
|
- Accepter le risque
|
||||||
|
|
||||||
|
Les risques résiduels sont ensuite acceptables, ou acceptés.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Mesures de sécurité
|
||||||
|
|
||||||
|
- Définition de ce qu'il faut mettre en place et de comment le contrôler
|
||||||
|
|
||||||
|
- Évalutation des risques résiduels
|
||||||
|
|
||||||
|
En gros, qu'est-ce qu'on met en place pour atteindre l'objectif de sécurité visé précédemment ?
|
||||||
|
|
||||||
|
Aboutit à terme sur le lancement du projet et l'évolution du SI.
|
Loading…
Reference in a new issue