Manuel de Procédures D'audit de Sécurité2

2014
Manuel de procédures
d’audit de sécurité d’un
Système d’information
NDONGMO TONZEU ALEX L.

Grid Engineering SARL
Manuel de procédures d’audit de sécurité d’un Système d’information
AVANT PROPOS
 Le présent manuel décrit l'organisation, les procédures d’audit de sécurité d’un

système d’information. La mise en place des procédures formalisées répond aux
objectifs ci-après :
 Mettre à la disposition du responsable du Projet, un outil de référence à la
fois opérationnel et pédagogique pour la conduite des missions d’audit.
 Rendre plus productif l’équipe et responsabiliser davantage les auditeurs
dans l'accomplissement des tâches respectives par une définition précise des
objectifs visés à chaque phase du processus d’audit.
 Si les aspects techniques mentionnés dans ce document peuvent devenir obsolètes,

les concepts fondamentaux abordés restent valides. Le lecteur pourra actualiser son
information en consultant les sites Internet des éditeurs des différents outils
(référentiel, méthodes, logiciels…) répertoriés.
 Conformément aux usages, nous avons laissé en anglais un certain nombre de

termes du langage technique.
1
SOMMAIRE
AVANT PROPOS............................................................................................................................ 1
LISTE DES FIGURES........................................................................................................................ 5
LISTE DES TABLEAUX .................................................................................................................... 6
LISTE DES SIGLES ET ABREVIATIONS .............................................................................................. 7
INTRODUCTION: CONTEXTE .......................................................................................................... 9
PARTIE I : DESCRITION DU MANUEL ................................................................................ 10
I.1 OBJECTIFS DU MANUEL ................................................................................................................ 11

I.2 ORGANISATION DU MANUEL ....................................................................................................... 11
I.3 MISE A JOUR DU MANUEL ............................................................................................................ 12
I.3.1 Modification des procédures ................................................................................................ 12
I.3.2 Responsabilités de la tenue de la mise à jour du manuel ..................................................... 12
I.3.3 Méthodologie de mise à jour ................................................................................................ 13
PARTIE II : AUDIT DE SECURITE DES SYSTEMES D’INFORMATION AU CAMEROUN

.................................................................................................................................................. 14
II.1 C’EST QUOI L’AUDIT DE SECURITE D’UN SI ?................................................................................ 15

II.2 QUEL EST LE CADRE JURIDIQUE QUI REGIT CETTE ACTIVITE ? ..................................................... 15
II.3 POURQUOI FAUT-IL AUDITER LES SI ?.......................................................................................... 16
II.4 QU’EST-CE QU’IL FAUT AUDITER ?............................................................................................... 16
II.5 QUI DOIT AUDITER ? .................................................................................................................... 17
II.5.1 Rôle de l’ANTIC..................................................................................................................... 17
II.5.2 Rôle des auditeurs externes ................................................................................................. 18
II.6 COMMENT EST FACTUREE UNE MISSION D’AUDIT ? ................................................................... 18
PARTIE III : REFERENTIELS D’AUDIT DE SECURITE DES SI ......................................... 19
III.1 INTRODUCTION .......................................................................................................................... 20

III.2 DEFINITIONS ............................................................................................................................... 20
III.2.1 L’ISO (Organisation Internationale de Normalisation) ....................................................... 20
III.2.2 Les méthodes ...................................................................................................................... 21
III.2.3 Les normes .......................................................................................................................... 21
III.3 HISTORIQUE DES NORMES SUR LA SECURITE DE L’INFORMATION ............................................ 22
2
III.4 LA SUITE DES NORMES ISO 2700X .............................................................................................. 24

III.5 LES SYSTEMES DE MANAGEMENT .............................................................................................. 30
III.5.1 Le principe des systèmes de management ......................................................................... 30
III.5.2 Les principaux systèmes de management .......................................................................... 31
III.5.3 L’apport des systèmes de management ............................................................................. 32
III.5.4 Les Systèmes de Management de la Sécurité de l'Information (SMSI) ............................... 33
III.6 LA NORME ISO/CEI 27001 SELON LE MODELE PDCA .................................................................. 34
III.6.1 Définitions (le modèle PDCA) .............................................................................................. 34
III.6.2 La première phase du modèle PDCA : la phase « Plan »..................................................... 35
A. Politique et périmètre du SMSI ............................................................................................ 36
B. Appréciation des risques ...................................................................................................... 36
C. Traitement des risques ......................................................................................................... 45
D. Sélection des mesures de sécurité....................................................................................... 46
III.6.3 Phase « Do » ....................................................................................................................... 46
A. Plan de traitement ............................................................................................................... 47
B. Choix des indicateurs ........................................................................................................... 47
C. Formation et sensibilisation des collaborateurs .................................................................. 47
D. Maintenance du SMSI .......................................................................................................... 48
III.6.4 La phase « Check » .............................................................................................................. 48
A. Les audits internes ............................................................................................................... 48
B. Les contrôles internes .......................................................................................................... 49
C. Revues de direction .............................................................................................................. 49
III.6.5 La phase « Act » .................................................................................................................. 49
A. Actions correctives ............................................................................................................... 49
B. Actions préventives .............................................................................................................. 49
C. Actions d’améliorations....................................................................................................... 50
PARTIE IV : DEMARCHE DE REALISATION D’UNE MISSION D’AUDIT DE SECURITE

.................................................................................................................................................. 51
IV.1 CYCLE DE VIE DE L’AUDIT DE SECURITE D’UN SI.......................................................................... 52

IV.1.1 Description .......................................................................................................................... 53
IV.1.2 Intérêts................................................................................................................................ 53
IV.2 PROCESSUS DE REALISATION D’UNE MISSION D’AUDIT ............................................................ 54
IV.2.1 PREPARATION DE L’AUDIT .................................................................................................. 55
3
A. Objectifs ............................................................................................................................... 55
B. Préparation de la mission ..................................................................................................... 55
C. Détermination des référentiels ............................................................................................ 56
D. Organisation de l’audit......................................................................................................... 56
E. Le périmètre de l’audit : ....................................................................................................... 57
F. Les documents à demander ................................................................................................. 57
G. Personnes à rencontrer et agenda ...................................................................................... 58
H. Durée de la mission.............................................................................................................. 58
I. Préparation des auditeurs ..................................................................................................... 58
IV.2.2 AUDIT NIVEAU 1 : AUDIT ORGANISATIONNEL ET PHYSIQUE ............................................ 61
A. Objectifs ............................................................................................................................... 61
B. Déroulement ........................................................................................................................ 62
IV.2.3 AUDIT NIVEAU 2 : AUDIT TECHNIQUE ................................................................................ 73
A. Objectifs ............................................................................................................................... 73
B. Déroulement ........................................................................................................................ 74
IV.2.4 PHASE DE TESTS INTRUSION............................................................................................... 86
A. Objectifs, avantages et limites des tests d’intrusion ........................................................... 87
B. Types de test d’intrusion ...................................................................................................... 89
IV.2.5 PHASE DE SYSNTHESE ET RECOMMANDATIONS (LE RAPPORT D’AUDIT) .......................... 96
A. Analyse et évaluation des risques (cf. MEHARI) .................................................................. 97
B. Le rapport d’audit................................................................................................................. 97
IV.2.6 LA PHASE D’ACCOMPAGNEMENT POST-AUDIT................................................................ 102
A. Objectifs ............................................................................................................................. 102
B. Déroulement ...................................................................................................................... 102
ANNEXES ...............................................................................................................................105
ANNEXE 1 : QUESTIONNAIRE D’AUDIT ..................................................................................................... 105

ANNEXE 2 : INSTALLATION DE KALI ......................................................................................................... 134
ANNEXE 3 : ANALYSE DE FLUX D’UN RESEAU AVEC WIRESHARK. .................................................................. 142
ANNEXE 4 : ANALYSE DE VULNERABILITE AVEC NESSUS. ............................................................................. 150
ANNEXE 5 : TEST D’INTRUSION AVEC ARMITAGE ....................................................................................... 164
BIBLIOGRAPHIE...................................................................................................................................... 173
4
Liste des Figures

Figure 1: Résumé des normes ISO 2700X .............................................................................................. 30
Figure 2: Le processus du système de management ............................................................................ 31
Figure 3: Le modèle «PDCA » ................................................................................................................ 34
Figure 4: Processus de déroulement de la phase « Plan » .................................................................... 36
Figure 5: Le processus d’appréciation des risques ................................................................................ 37
Figure 6: Les cinq modules de la méthode EBIOS ........................................... Erreur ! Signet non défini.
Figure 7: Enjeux critiques + Vulnérabilités fortes = Risques inacceptables .......................................... 40
Figure 8: La démarche MEHARI ............................................................................................................. 45
Figure 9: Cycle de vie d’audit de sécurité.............................................................................................. 52
Figure 10: Processus d’audit.................................................................................................................. 55
Figure 11: interface d’accueil de Kali .................................................................................................... 77
5
Liste des Tableaux

Tableau 1: Historique des normes en matière de sécurité de l’information ........................................ 24
Tableau 2: Principaux référentiels de systèmes de management ........................................................ 32
Tableau 3: Outils d'audit technique ...................................................................................................... 76
Tableau 4: tableau d’accompagnement post audit............................................................................. 104
6
Liste des sigles et abréviations

ACL: Access Control List
AESC: American Engineering Standards Committee
AFNOR: Association Française de Normalisation
ANSSI: Agence Nationale de la Sécurité des Systèmes d’Information
ANTIC : Agence Nationale des Technologies de l’Information et de la

Communication
ARP: Address Resolution Protocol
ASA: American Standards Association
BSI: British Standards Institute
CEI : Commission Electrotechnique Internationale
CEN : Comité Européen de Normalisation
CLUSIF: Club de la Sécurité de l’Information Français
CMM: Capability Maturity Model
DNS: Domain Name System
EBIOS : Expression des Besoin et Identification des Objectifs Spécifique
HIDS: Host Intrusion Detection System
HTTP: HyperText Transfer Protocol
IEEE: Institute of Electrical and Electronics Engineers
IP: Internet Protocol
IPS: Intrusion Prevention System
ISO : organisation internationale de normalisation
JTC : Joint Technical Committee
MEHARI: Méthode Harmonisée d’Analyse des Risques.
NDIS: Network Intrusion Detection System
7
Nmap: Network Mapper
OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation
OHSAS: Occupational Health and Safety Assessment Series
PCAP: Packet Capture
PDCA: « Plan » « Do » « Act » « Check »
POP: Post Office Protocol
RATS: Rough Auditing Tool for Security
RSSI: Responsable de Sécurité du Système d’Information
SGSI : Système de Gestion de la Sécurité de l’information
SI : Système d’Information
SMQ : Système de Management de la Qualité
SMSI : Système de Management de la Sécurité de l’Information
SMTP: Simple Mail Transfer Protocol
SoA: Statement of Applicability
SSH: Secure Shell
TCP: Transmission Control Protocol
TELNET: TELecommunication NETwork
UDP: User Datagram Protocol
VLAN: Virtual Local Area Network
8
INTRODUCTION: CONTEXTE
Afin de protéger leurs données, le matériel et les personnes, la plupart des entreprises
de grande taille ou même de dimensions plus modestes, doivent s'assurer de leur
sécurité et d'une protection efficace face aux intrusions (menaces d'intrusion d'un
réseau de données par l’Internet par exemple …). De même, les risques d'espionnage
industriel pouvant mettre l'entreprise en danger sur le plan commercial et concurrentiel
doivent également être considérés.
Qu'elle soit discrète ou plus ostentatoire, la sécurité d'une entreprise et sa mise en

pratique cohérente contre des risques potentiels se doit d'être contrôlée périodiquement
pour s'assurer des performances des systèmes, protocoles et pratiques de sécurité.
Pour répondre à cet impératif, chaque entreprise doit effectuer périodiquement un audit
de sécurité de son système d’information (SI) afin de disposer d’un état des lieux, de
mettre en évidence les forces et les faiblesses de sa configuration actuelle, et
d’identifier les actions correctives à mettre en œuvre. Cela devra se faire en suivant un
plan détaillé c’est-à-dire une démarche d’audit de sécurité adapté aux systèmes
d’information qui sont en constante évolution.
Ce document présente la démarche à suivre pour mener à bien une mission d’audit de
sécurité d’un système d’information au Cameroun, les référentiels sur lesquelles il faut
s’appuyer, ainsi que les différents outils logiciels pouvant être utilisés.
9
PARTIE I : DESCRITION DU MANUEL
10
I.1 OBJECTIFS DU MANUEL
Ce manuel de procédures formalise le processus d’audit de sécurité d’un système

d’information. Il a pour objectifs de :
 Respecter (et faire respecter) la réglementation en vigueur,

 Décrire les procédures à mettre en œuvre par l’ensemble de l’équipe d’auditeurs
ainsi que les tâches qui incombent à chaque membre,
 Améliorer le contrôle et la qualité de l'organisation de la sécurité des systèmes
d’information,
 Fiabiliser l'information sur la sécurité informatique publiée,
 Améliorer les systèmes d’information,
 Utiliser de façon optimale, pour la meilleure efficacité de l'action engagée,
l’ensemble des moyens mis en œuvre tels que:
o les moyens humains,
o les moyens matériels,
o les moyens financiers.
I.2 ORGANISATION DU MANUEL
 Partie I : DESCRIPTION DU MANUEL
En tant que première partie, elle présente l’organisation du manuel. Celui – ci est
structuré de manière à faciliter l’exploitation et la mise à jour afin de l’adapter à
l’évolution tant de l’organisation du projet que des procédures formalisées.
 Partie II : AUDIT DES SI AU CAMEROUN
La deuxième partie porte sur le contexte légal qui entoure l’activité d’audit de sécurité
des SI au Cameroun.
 Partie III : REFERENTIEL D’AUDIT DE SECURITE

11
Le but de cette partie est de permettre à l’utilisateur de mieux appréhender les concepts
de management (et donc d’audit) de la sécurité des systèmes d’information.
 Partie IV : DEMARCHE DE REALISATION D’UNE MISSION D’AUDIT

DE SECURITE
C’est la partie la plus importante du manuel de procédures. En effet c’est dans cette
partie que l’on décrit tout le processus d’audit tout en précisant la norme, la méthode et
l’outil logiciel utilisés à chaque étape.
I.3 MISE A JOUR DU MANUEL
I.3.1 Modification des procédures
La mise à jour du présent manuel est aussi importante que sa mise en place. S'il n'est
pas mis à jour régulièrement et si chaque exemplaire ne subit pas la mise à jour, il perd
de son efficacité. Une liste des détenteurs du manuel sera maintenue par le Directeur
du Projet pour permettre la mise à jour de tous les exemplaires chaque fois qu’une
mise à jour sera opérée.
La mise à jour du manuel peut être motivée par :
 Les modifications des systèmes et procédures dans le but d'améliorer les

procédures existantes pour faire face à des situations nouvelles,
 des changements rendus nécessaires par l'application des textes et décrets
concernant les lois et règles en vigueur au Cameroun,
 les rapports des missions d’audit et les réalités du terrain,
 les propositions d’améliorations des procédures décrites en rapport avec
l’utilisation d’un outil, d’une norme ou d’une méthode plus efficace.
I.3.2 Responsabilités de la tenue de la mise à jour du manuel
12
La responsabilité de la tenue et la mise à jour du manuel de procédures incombe au

Directeur du Projet. Il décide en outre des copies à mettre à la disposition du
personnel. La décision de modification des procédures existantes est prise sur son
initiative.
I.3.3 Méthodologie de mise à jour
Lorsque la décision de modification de procédures existantes est envisagée, le

Directeur du Projet convoque une réunion à laquelle doivent participer tous les agents
susceptibles d'être concernés par ces modifications.
Cette réunion doit débattre de l’opportunité de la modification proposée et des

solutions à adopter. A l'issue de cette réunion un procès-verbal est établi indiquant les
éléments suivants :
 Les parties devant être modifiées,

 les raisons pour lesquelles les modifications sont demandées,
 les principes des modifications à apporter,
 la personne chargée de rédiger les nouvelles données à inclure dans le manuel.
La personne chargée de la rédaction des nouvelles procédures les soumet au Directeur

du Projet qui y apporte les éventuelles modifications qu'il juge nécessaire pour arrêter
le texte définitif.
Apres adoption du texte définitif portant sur les modifications apportées au manuel,
l'Unité de Coordination du Projet (UCP) se charge de distribuer les nouvelles parties
du manuel aux intéressés. Un secrétariat doit tenir un registre permettant de suivre la
mise à jour de chaque copie du manuel.
La personne chargée de la distribution des nouvelles parties du manuel note dans le

registre la date de transmission de la nouvelle partie aux intéressés ainsi que les
références correspondantes.
13
PARTIE II : AUDIT DE SECURITE DES SYSTEMES D’INFORMATION

AU CAMEROUN
14
II.1 C’EST QUOI L’AUDIT DE SECURITE D’UN SI ?
La loi N°2010/012 du 21 décembre 2010 relative à la Cybersécurité et à la

Cybercriminalité au Cameroun définit l’audit de sécurité comme un examen
méthodique des composantes et des acteurs de la sécurité, de la politique, des mesures,
des solutions, des procédures et des moyens mis en œuvre par une organisation, pour
sécuriser son environnement et effectuer des contrôles de conformité de son système
d’information.
II.2 QUEL EST LE CADRE JURIDIQUE QUI REGIT CETTE ACTIVITE ?
L’activité d’audit de sécurité des systèmes d’information est régit par les textes
suivants :
 La loi N°2010/012 du 21 décembre 2010 relative à la cybersécurité et à la

cybercriminalité au Cameroun qui fixe le cadre légal de l’activité d’audit de
sécurité en ses articles 7, 13, 14, 32 et 61 :
 Le décret N°2012/1643/PM du 14 juin 2012 fixant les conditions et les
modalités d’audit obligatoire des réseaux de communications électroniques et
des systèmes d’information ;
 L’arrêté conjoint N°00000013/MINPOSTEL/MINFI du 10 mai 2013 fixant les
montants et les modalités de paiement des frais perçus par l’ANTIC (Agence
Nationale des Technologies de l’Information et de la Communication) ;
 La décision N°00000094/MINPOSTEL du 30 mai 2013 fixant les frais d’audit
de sécurité des réseaux de communications électroniques et des systèmes
d’information ;
 La décision N°00000122/MINPOSTEL du 27 juin 2013 fixant les modalités
d’organisation et de fonctionnement de la Commission chargée d’émettre des
avis sur les demandes d’agrément pour l’exercice de l’activité d’expert auditeur
dans le domaine de la sécurité des réseaux de communications électroniques et
des systèmes d’information.
15
Tous ces textes sont disponibles par téléchargement gratuit à l’adresse suivante :
http://antic.cm/index.php/textesreglementaires.
II.3 POURQUOI FAUT-IL AUDITER LES SI ?
L’audit de sécurité est une mission d’évaluation de conformité par rapport à une
politique de sécurité ou à défaut par rapport à un ensemble de règles de sécurité.
L’objectif principal d’une mission d’audit de sécurité est de répondre aux besoins de
sécurité informatique d’une organisation, en :
 vérifiant la conformité du SI aux standards de sécurité définis, c’est-à-dire en

déterminant les déviations de ce système par rapport aux bonnes pratiques ;
 déterminant et en évaluant les risques et les failles de sécurité ;
 déterminant les origines et les causes d’un incident lié à l’infrastructure
informatique ;
 proposant des actions d’améliorations du niveau de sécurité du SI.
Toutefois, l’audit de sécurité peut présenter un aspect préventif. C'est-à-dire qu’il est
effectué de façons périodiques afin de permettre à l’organisme de prévenir les failles
de sécurité ; ou alors, l’audit peut s’imposer suite à des incidents de sécurité.
II.4 QU’EST-CE QU’IL FAUT AUDITER ?
Les audits de sécurité au Cameroun concernent principalement les systèmes

d’information et les réseaux de communication électronique des administrations
publiques, des prestataires de services de communications électroniques tels que les
fournisseurs d’accès Internet et les opérateurs de téléphonie, et plus généralement, les
entreprises procédant au traitement automatisé des données personnelles de leurs
clients dans le cadre de la fourniture des services via les réseaux de communications
électroniques ouverts au public.
16
On distingue dans ce cas, quatre (04) catégories de structures à auditer:
 Les Administrations Publiques ;

 Les Etablissements Publics Administratifs et Entreprises à capital public ;
 Les Opérateurs de Télécommunications et les Fournisseurs d’Accès Internet ;
 Les Etablissements de Crédits et de micro-finances.
Cependant il est à noter que les applications spécifiques utilisées en matière de défense
et de sécurité nationale sont exemptées d’audit de sécurité.
II.5 QUI DOIT AUDITER ?
Les principaux acteurs intervenant dans la réalisation des missions d’audit sont
l’ANTIC et les auditeurs externes (personnes morales et/ou personnes physiques)
ayant préalablement reçus un agrément délivré par l’ANTIC. Leurs attributions sont
définies de la manière suivante :
II.5.1 Rôle de l’ANTIC
Conformément à la loi N°2010/012 du 21 décembre 2010, les attributions de l’ANTIC

relatives à l’audit de sécurité sont :
 établir annuellement un planning des audits de sécurité qu’elle communique

aux organismes concernés ;
 définir le Cahier de Charges des auditeurs ;
 élaborer un modèle de Termes de Référence d’une opération d’audit ;
 élaborer les référentiels d’audit ;
 accréditer les auditeurs externes ;
 procéder à l’audit des administrations Publiques ;
 s’assurer de la régularité des missions d’audit des Administrations et
Organismes publics ;
17
 examiner la conformité des rapports des auditeurs externes suivant les

procédures élaborées ;
 fixer le délai de réalisation d’une mission d’audit et définir les sanctions en cas
de non-respect du délai fixé ;
 procéder à une vérification sur le terrain de l’effectivité d’une mission d’audit
après étude du rapport fourni par un auditeur externe ;
 fixer les conditions de rejet des rapports de mission d’audit ;
 veiller à la mise en œuvre par la structure auditée des recommandations et
propositions mentionnées dans le rapport d’audit.
II.5.2 Rôle des auditeurs externes
Les auditeurs externes sont chargés de :
 assurer l’audit des SI des structures qui leurs sont confiées par l’ANTIC et
formuler des recommandations destinées à remédier aux failles de sécurité
relevées ;
 assurer un suivi post-audit afin d’accompagner la structure auditée dans la mise
en œuvre des solutions proposées.
II.6 COMMENT EST FACTUREE UNE MISSION D’AUDIT ?
Conformément à l’article 4 alinéa 2 du décret N°2012/1643/PM du 14 juin 2012, qui

dispose que les frais d’audit de sécurité sont supportés par les organismes audités,
fixés sur la base des montants du barème officiel, du nombre d’auditeur par équipe et
de la durée de la mission.
18
PARTIE III : REFERENTIELS D’AUDIT DE SECURITE DES SI
19
III.1 INTRODUCTION
Les relations entre entreprises ou administrations rendent nécessaire la définition de

référentiels communs. Dans ce contexte, plusieurs méthodes et normes se présentent
pour assurer les relations de la sécurité des systèmes d’information. Cependant, les
concepts de méthode de sécurité et de norme de sécurité portent souvent à confusion.
Dans cette partie, nous allons tout d’abord tenter de définir chacun de ces concepts,
ensuite nous présenterons les normes et méthodes liées au concept d’audit de Sécurité
d’un SI.
III.2 DEFINITIONS
III.2.1 L’ISO (Organisation Internationale de Normalisation)
L’ISO est le fruit d’une collaboration entre différents organismes de normalisation

nationaux. Au début du 20ème siècle, L’American Institute of Electrical Engineer
(Aujourd’hui appelé Institute of Electrical and Electronics Engineers ou IEEE) invite
quatre autres instituts professionnels pour constituer une première organisation
nationale, l’AESC (American Engineering Standards Committee) qui aura pour
objectif de publier des standards industriels communs avant de prendre le nom d’ASA
(American Standards Association) et d’établir des procédures standardisées pour la
production militaire pendant la seconde guerre mondiale. En 1947, l’ASA, le BSI
(British Standards Institute), l’AFNOR (Association Française de Normalisation) et les
organisations de normalisation de 22 autres pays fondent l’Organisation Internationale
de Normalisation (ISO).
A ce jour, l’ISO regroupe 157 pays membres, et coopère avec les autres organismes de
normalisation comme le CEN (Comité européen de normalisation) ou la Commission
Electronique Internationale (CEI). En 1987, l’ISO et le CEI créent le Joint Technical
Committee (JTC1) pour la normalisation des Technologies de l’Information (TI). Le
JTC1 allie les compétences de l’ISO en matière de langage de programmation
20
et codage de l’information avec celles du CEI qui traitent du matériel tel que les
microprocesseurs.
Le JTC1 est composé de plusieurs comités techniques qui traitent de sujets tels que la
biométrie, la téléinformatique, les interfaces utilisateurs ou encore les techniques de
sécurité de l’information relatives aux normes de la série ISO/CEI 2700x.
III.2.2 Les méthodes
Une méthode est une démarche, un processus ou un ensemble de principes qui

permettent d’appliquer une norme au système d’information de l’entreprise. La
méthode sert aussi à faire un audit qui permettra d’obtenir, par exemple, un état de la
sécurité du système d’information. Une méthode est souvent accompagnée d’outils
afin d’appuyer son utilisation. Ils peuvent être disponibles gratuitement auprès des
organismes qui les ont produits. Par exemple la méthode MEHARI, que nous verrons
plus loin, propose un outil (fichier Microsoft Excel). Le fichier contient un ensemble
de questions et de scénarios. Cette base de connaissance permet de ressortir toutes les
vulnérabilités du système d’information et émet des recommandations pour y
remédier. La plupart des méthodes sont appliquées par des experts en gestion des
risques (EBIOS, MEHARI…).
III.2.3 Les normes
Une norme est, selon le guide ISO/CEI, « un document de référence approuvé par
un organisme reconnu, et qui fournit pour des usages communs et répétés, des
règles, des lignes directrices ou des caractéristiques, pour des activités, ou leurs
résultats, garantissant un niveau d’ordre optimal dans un contexte donné ».
Les entreprises se font certifier pour prouver qu’elles suivent les recommandations de
la norme. Pour être certifié, il faut, dans un premier temps acheter la norme. Les
normes appliquées à la sécurité des systèmes d’information sont généralement
éditées par l’organisme ISO. Ensuite l’entreprise doit mettre en pratique les
recommandations décrites dans la norme.
21
Généralement, une entreprise peut se faire certifier pour trois raisons :
 Pour une raison commerciale. Pour certaines entreprises, être certifiées par des
normes de qualité par exemple est un gage de qualité pour les clients et est donc
un atout commercial.
 Par obligation. En industrie aéronautique par exemple, les constructeurs exigent
de leurs sous-traitants qu’ils soient certifiés par certaines normes.
 Il y a aussi des entreprises qui se certifient pour elles-mêmes, pour optimiser
leur processus en interne.
III.3 HISTORIQUE DES NORMES SUR LA SECURITE DE

L’INFORMATION
Au cours des vingt dernières années les normes liées à la sécurité de l’information ont
évolué ou ont été remplacées. Ces changements rendent difficile une bonne
compréhension du sujet. Un rappel historique de l’évolution de ces normes permet de
clarifier la situation normative en matière de sécurité de l’information.
Au début des années 90, de grandes entreprises britanniques se concertent pour

établir des mesures visant à sécuriser leurs échanges commerciaux en ligne. Le résultat
de cette collaboration servit de référence en la matière pour d’autres entreprises qui
souhaitaient mettre en œuvre ces mesures. Cette initiative privée fut appuyée par le
Département des Transports et de l’Industrie britannique qui supervisa la
rédaction au format du BSI, d’une première version de projet de norme de gestion de
la sécurité de l’information.
En 1991, un projet nommé «best practices» qui signifie code de bonnes pratiques,
préconise la formalisation d’une politique de sécurité de l’information. Cette politique
de sécurité doit intégrer au minimum huit points «stratégique et opérationnel» ainsi
qu’une mise à jour régulière de la politique.
22
En 1995, le BSI publie la norme BS 7799 qui intègre dix chapitres réunissant plus de
100 mesures détaillées de sécurité de l’information, potentiellement applicables selon
l’organisme concerné.
En 1998, la norme BS 7799 change de numérotation et devient la norme BS 7799-1.

Elle est complétée par la norme BS 7799-2 qui précise les exigences auxquelles doit
répondre un organisme pour mettre en place une politique de sécurité de l’information.
Cette nouvelle norme est fondée sur une approche de la maîtrise des risques et sur le
principe du management de la sécurité de l’information.
En 2000, la norme BS 7799-1, devient la norme de référence internationale pour les

organismes souhaitant renforcer leur sécurité de l’information. Après avoir suivi un
processus de concertation au niveau international et quelques ajouts, l’ISO lui
attribue un nouveau nom, ISO/IEC 17799: 2000.
En 2002, le BSI fait évoluer la norme BS 7799-2 en s’inspirant des normes ISO
9001:2000 et ISO 14001: 1996. La norme adopte définitivement une approche de
management de la sécurité de l’information.
En 2005, l’ISO/CEI adopte la norme BS 7799-2 sous la référence ISO/CEI 27001:

2005 en y apportant quelques modifications pour se rapprocher le plus possible
du principe de «système de management » développé par les normes ISO 9001 et ISO
14001. L’ISO/IEC 27001: 2005 spécifie les exigences pour la mise en place d’un
SMSI (Système de Management de la Sécurité de l’Information).
En 2007, dans un souci de clarification, l’ISO renomme la norme ISO/IEC

17799:2005 en changeant sa numérotation pour ISO/IEC 27002. La norme se greffe à
la famille des normes ISO/IEC 2700x toujours en développement.
Aujourd’hui les organismes disposent de deux normes qui se sont imposées comme
références des SMSI, l’ISO/CEI 27001 qui décrit les exigences pour la mise en place
d'un Système de Management de la Sécurité de l’Information et l’ISO/CEI 27002 qui
23
regroupe un ensemble de bonnes pratiques «best practices» pour la gestion de la

sécurité de l'information.
Le tableau suivant résume cet historique.
Année Norme Traite des SMSI Remplace la norme

1995 BS 7799:1995 Non
1998 BS 7799-2:1998 Oui
2000 ISO 17799:2000 Non BS 7799 :1995
2002 BS 7799-2:2002 Oui BS 7799-2 :1998
2005 ISO 17799:2005 Non ISO 17799 :2000
2005 ISO 27001:2005 Oui BS 7799-2 :2002
2007 ISO 27002 Non ISO 17799 :2005
Tableau 1: Historique des normes en matière de sécurité de l’information
III.4 LA SUITE DES NORMES ISO 2700X
ISO/IEC 27000 : Systèmes de management de la sécurité de l'information – Vue

d'ensemble et vocabulaire
Aussi connue sous le nom de Famille des standards SMSI ou ISO27k, elle comprend
les normes de sécurité de l'information publiées conjointement par
l'Organisation internationale de normalisation (ISO) et la Commission
électrotechnique internationale (CEI, ou IEC en anglais).
La suite contient des recommandations des meilleures pratiques en management de la

sécurité de l'information, pour l'initialisation, l'implémentation ou le maintien de
systèmes de management de la sécurité de l'information (SMSI, ou ISMS en
anglais), ainsi qu'un nombre croissant de normes liées au SMSI.
 ISO/CEI 27000 : Systèmes de management de la sécurité de l'information -

Vue d'ensemble et vocabulaire
 ISO/CEI 27001 : Systèmes de management de la sécurité de l'information –
Exigences
 ISO/CEI 27002 : Code de bonne pratique pour le management de la
sécurité de l'information
24
 ISO/CEI 27003 : Lignes directrices pour la mise en œuvre du

système de management de la sécurité de l'information
 ISO/CEI 27004 : Management de la sécurité de l'information – Mesurage
 ISO/CEI 27005 : Gestion des risques liés à la sécurité de l'information
 ISO/CEI 27006 : Exigences pour les organismes procédant à l'audit et
à la certification des systèmes de management de la sécurité de l'information
 ISO/CEI 27007 : Lignes directrices pour l'audit des systèmes de management
de la sécurité de l'information.
ISO/CEI 27001: Systèmes de management de la sécurité de l'information -

Exigences
L'ISO/CEI 27001 est la norme centrale de la famille ISO 2700X, c'est la norme
d'exigences qui définit les conditions pour mettre en œuvre et documenter un SMSI,
publiée en octobre 2005 par l'ISO.
Objectifs
La norme ISO 27001 s’adresse à tous les types d’organismes (entreprises

commerciales, administrations, etc…). Elle décrit les exigences pour la mise en place
d'un Système de Management de la Sécurité de l'Information. Le SMSI est destiné à
choisir les mesures de sécurité afin d'assurer la protection des biens sensibles d'une
entreprise sur un périmètre défini. C'est le modèle de qualité PDCA (Plan-Do-Check-
Act) qui est recommandé pour établir un SMSI afin d'assurer une amélioration
continue de la sécurité du SI.
La norme dicte également les exigences en matières de mesures de sécurité propres à

chaque organisme, c’est-à-dire que la mesure n’est pas la même d’un organisme à
l’autre. Les mesures doivent être adéquates et proportionnées à l’organisme pour ne
pas être ni trop laxistes ni trop sévères. La norme ISO 27001 intègre aussi le fait que la
mise en place d’un SMSI et d’outils de mesures de sécurité ait pour but de
garantir la protection des actifs informationnels. L’objectif est de protéger les
25
informations de toute perte ou intrusion dans le but d’apporter la confiance des

parties prenantes.
L'ISO/CEI 27001 définit l'ensemble des contrôles à effectuer servant : à s'assurer de la

pertinence du SMSI, à l'exploiter et à le faire évoluer. Plus précisément, l'annexe A de
la norme est composée des 133 mesures de sécurité de la norme ISO/CEI 27002,
classées dans 11 sections. Comme pour les normes ISO 9001 et ISO 14001, il est
possible de se faire certifier ISO 27001.
ISO/CEI 27002 : Code de bonne pratique pour le management de la sécurité de

l'information
La norme ISO/CEI 27002 est une norme internationale concernant la sécurité de

l'information, publiée en 2005 par l'ISO, dont le titre en français est Code de bonnes
pratiques pour le management de la sécurité de l’information. C’est un ensemble de
133 mesures dites « best practices » (bonnes pratiques en français), destinées à être
utilisées par tous ceux qui sont responsables de la mise en place ou du maintien d'un
Système de Management de la Sécurité de l'Information.
La sécurité de l'information y est définie comme la « préservation de la

confidentialité, de l'intégrité et de la disponibilité de l'information ».
Cette norme n'a pas de caractère obligatoire pour les entreprises. Son respect peut
toutefois être mentionné dans un contrat : un prestataire de services pourrait ainsi
s'engager à respecter les pratiques normalisées dans ses relations avec un client.
Objectifs
ISO/IEC 27002 est plus un code de bonne pratique, qu’une véritable norme ou qu’une
spécification formelle telle que l’ISO/IEC 27001. Elle présente une série de contrôles
(39 objectifs de contrôle) qui suggèrent de tenir compte des risques de sécurité des
informations relatives à la confidentialité, l'intégrité et les aspects de disponibilité. Les
entreprises qui adoptent l'ISO/CEI 27002 doivent évaluer leurs propres risques de
26
sécurité de l'information et appliquer les contrôles appropriés, en utilisant la

norme pour s’orienter .
ISO 27002 n'est pas une norme au sens habituel du terme. En effet, ce n’est pas une
norme de nature technique, technologique ou orientée produit, ou une méthodologie
d'évaluation d'équipement telle que les critères communs CC/ISO 15408. Elle n’a
pas de caractère d'obligation, elle n’amène pas de certification, ce domaine étant
couvert par la norme ISO/IEC 27001.
ISO/CEI 27003 : Lignes directrices pour la mise en œuvre du système de

management de la sécurité de l'information
La norme ISO/CEI 27003 fournit une approche orientée processus pour la réussite de
la mise en œuvre d’un SMSI conformément à l’ISO 27001.
Objectifs
Le but de l'ISO/CEI 27003 est de fournir une aide et des conseils pour mettre en œuvre
un Système de Management de la Sécurité de l'Information.
ISO/IEC 27003 donne des orientations sur la conception d'une norme ISO/IEC 27001-
SGSI conforme, conduisant à l'ouverture d'un SMSI (mise en œuvre du projet). Il
décrit le processus du SMSI et la spécification de conception, du début jusqu'à la
production des plans d'exécution des projets, couvrant la préparation et la planification
des activités préalables à la mise en œuvre effective, et en tenant compte des éléments
clés tels que:
 L’approbation de la direction et l'autorisation définitive de procéder

à l'exécution des projets;
 La détermination de la portée et la définition des limites en termes de TIC et les
lieux physiques;
 L'évaluation des risques de sécurité de l'information et de la planification des
traitements de risque appropriés, le cas échéant en définissant des exigences de
contrôle de sécurité de l'information;
27
 La conception du SMSI;
 La planification du projet mise en œuvre.
ISO/CEI 27004 : Management de la sécurité de l'information - Mesurage
La norme ISO/CEI 27004 couvre les mesures de management de sécurité de

l'information, généralement connues comme les mesures de sécurité. Élaborée par
l’ISO et la Commission électrotechnique internationale (CEI). Son nom
complet est : Technologie de l'information - Techniques de sécurité - Management de
la sécurité de l'information -- Mesurage.
Objectifs
Le but de cette norme est d'aider les organisations à mesurer, à rapporter et donc
d'améliorer systématiquement l'efficacité de leurs systèmes de gestion de sécurité de
l'information (SGSI).
ISO/CEI 27005 : Gestion des risques liés à la sécurité de l'information
La première norme de gestion des risques de la Sécurité des Systèmes d'Information :

l'ISO/CEI 27005. Cette norme est un standard international qui décrit le Système de
Management des risques liés à la Sécurité de l'information.
Certains experts expliquent que cette norme est en fait une méthode quasi-applicable
en se servant des annexes et en les adaptant à leur contexte. D'ailleurs dans l'enquête
en 2010 du CLUSIF (Club de la Sécurité de l’Information en France), 35% des
entreprises qui font une analyse de risques déclarent le faire en utilisant la norme ISO
27005.
Objectifs
La norme ISO 27005 explique en détail comment conduire l'appréciation et le

traitement des risques, dans le cadre de la sécurité de l'information. Elle propose une
méthodologie de gestion des risques en matière d'information dans l'entreprise
28
conformément à la norme ISO/CEI 27001. Cette norme a donc pour but d’aider à
mettre en œuvre l’ISO/CEI 27001, la norme relative aux systèmes de management de
la sécurité de l’information (SMSI), qui est fondée sur une approche de gestion du
risque. Néanmoins, la norme ISO 27005 peut être utilisée de manière autonome dans
différentes situations. Et elle applique à la gestion de risques le cycle d'amélioration
continue PDCA (Plan, Do, Check, Act) utilisé dans toutes les normes de systèmes de
management.
ISO/CEI 27006 : Exigences pour les organismes procédant à l'audit et à la

certification des systèmes de management de la sécurité de l'information
ISO/CEI 27006 est un standard de sécurité de l'information publié conjointement par

l'ISO et la CEI, afin de fixer les exigences pour les organismes réalisant l'audit et la
certification d’un SMSI.
Objectifs
Son but est de fournir les prérequis pour les organismes d'audit et de certification à la
norme ISO 27001 pour les Systèmes de Management de la Sécurité de
l'Information. Cette norme a été remise à jour en 2011 et porte la référence ISO/IEC
27006.
ISO/CEI 27007 : Lignes directrices pour l'audit des systèmes de management de

la sécurité de l'information
Cette norme fournit les lignes directrices pour les audits des systèmes de
management de la sécurité de l'information, ainsi que des conseils sur la compétence
des auditeurs des SMSI. Elle inclue aussi les lignes directrices contenues dans
la norme ISO 19011.
29
Figure 1: Résumé des normes ISO 2700X
III.5 LES SYSTEMES DE MANAGEMENT
III.5.1 Le principe des systèmes de management
Le principe de système de management n’est pas un nouveau concept ... Il

concerne historiquement le monde de la qualité, surtout dans le domaine des services
et de l’industrie. Qui n’a jamais vu un papier à en-tête avec un petit logo « certifié ISO
9001. La norme ISO 9001 précise les exigences auxquelles il faut répondre pour
mettre en place un système de management de la qualité (SMQ).
Comment définir un système de management ?
La norme ISO 9000 (à ne pas confondre avec l’ISO 9001 que nous venons
d’évoquer) apporte une réponse à cette question en définissant les principes de la
qualité. C’est ainsi que dans la rubrique intitulée « Système de management », il est dit
qu’un système de management est un système permettant :
 d’établir une politique ;
30
 d’établir des objectifs ;

 et d’atteindre ces objectifs.
Nous pouvons ainsi dire qu’un système de management est un ensemble de mesures
organisationnelles et techniques visant à atteindre un objectif et, une fois celui-ci
atteint, à s’y tenir, voire à le dépasser.
Figure 2: Le processus du système de management
III.5.2 Les principaux systèmes de management
Les systèmes de management ne se cantonnent pas uniquement de la qualité. Ils

concernent des domaines très variés comme l’environnement, les services
informatiques, la sécurité de l’information, la sécurité alimentaire ou encore la santé.
Le tableau ci-après donne un aperçu non exhaustif des principaux référentiels de

systèmes de management.
Référentiel Domaine
ISO 9001 Qualité
ISO 14001 Environnement
ISO 27001 Sécurité de l’information
31
ISO 20000 Services informatiques

ISO 22000 Sécurité alimentaire
OHSAS 18001 Santé/Sécurité du personnel
Tableau 2: Principaux référentiels de systèmes de management
Nous constatons que la majorité de ces référentiels sont normalisés par l’ISO).
Cependant, d’autres organismes privés ou nationaux peuvent proposer leurs propres
référentiels. La dernière ligne de cette liste montre, en effet, que l’ISO n’a pas le
monopole des systèmes de management, puisque la norme relative à la sécurité du
personnel au travail (OHSAS 18001) n’est pas spécifiée par l’ISO.
III.5.3 L’apport des systèmes de management
Les propriétés que nous venons de décrire donnent de bonnes raisons de penser que la
mise en place et l’exploitation d’un système de management n’est pas un projet facile
à mener. Il faut commencer par fixer des politiques, formaliser les procédures par écrit
et mener à bien des audits réguliers. Ces opérations sont loin d’être transparentes.
Souvent lourdes à implémenter, leur coût humain et financier n’est pas négligeable.
Dans ces conditions, il est légitime de se demander ce qui justifie un tel
investissement. Quels bénéfices concrets pouvons-nous en espérer ?
Premier apport : l’adoption de bonnes pratiques
Les systèmes de management se basent sur des guides de bonnes pratiques dans le
domaine qui les concerne (qualité, sécurité, environnement, etc.). Ainsi, celui qui se
lance dans la mise en place d’un système de management est quasiment obligé
d’adopter ces bonnes pratiques.
Deuxième apport : l’augmentation de la fiabilité
L’adoption de bonnes pratiques a pour conséquence directe, à court ou moyen terme,

l’augmentation de la fiabilité. Ceci est principalement dû au fait que les systèmes de
management imposent la mise en place de mécanismes d’amélioration continue,
favorisant la capitalisation sur les retours d’expérience.
32
Troisième apport : la confiance
C’est la principale raison d’avoir un système de management car ce dernier fournit la

confiance envers les parties prenantes. Qu’entendons-nous par parties prenantes ? Il
s’agit de toute personne, groupe ou instance envers laquelle l’entreprise doit rendre des
comptes (Par exemple : Les actionnaires, Les autorités de tutelle, Les clients, Les
fournisseurs, Les partenaires, etc.). En fait, nous oublions trop souvent que la
confiance est le vecteur qui permet toute relation entre un client et un fournisseur.
Autant dire qu’il n’y aurait aucune activité économique sans la confiance.
III.5.4 Les Systèmes de Management de la Sécurité de l'Information (SMSI)
Nous avons parlé de la partie SM (système de management) du SMSI. Intéressons-

nous désormais de la partie SI (sécurité de l’information).
Le principal objectif d’un SMSI est de faire en sorte de préserver la confidentialité,

l’intégrité et la disponibilité pour les informations les plus sensibles de l’entreprise. La
norme ISO 27001 insiste sur ces notions. Ces derniers sont formellement définis dans
la norme ISO 13335-1.
Le SMSI est cohérent avec les autres systèmes de management, notamment avec les
systèmes de management de la qualité, de la sécurité des conditions de travail, et de
l’environnement. Il inclut donc au minimum :
 des éléments documentaires (politique, description des objectifs, cartographie

des processus impactés, des activités de sécurité, et des mesures),
 la description de la méthode d’analyse des risques utilisée,
 les processus impliqués dans la mise en œuvre de la sécurité de l’information,
 les responsabilités relatives à la sécurité de l’information,
 les ressources nécessaires à sa mise en œuvre,
 les activités relatives à la sécurité de l’information,
 les enregistrements issus des activités relatives à la sécurité de l’information,
 les (relevés de) mesures prises sur les processus,
33
 les actions relatives à l’amélioration de la sécurité de l’information.
L’existence d’un SMSI dans l’organisme permet de renforcer la confiance dans le

mode de gestion de la sécurité de l’information.
III.6 LA NORME ISO/CEI 27001 SELON LE MODELE PDCA
III.6.1 Définitions (le modèle PDCA)
Les systèmes de management fonctionnent selon un modèle en quatre temps appelé «

PDCA », pour Plan, Do, Check, Act.
1. Phase Plan : dire ce que l’on va faire dans un domaine particulier (qualité,
environnement, sécurité, etc.).
2. Phase Do : faire ce que l’on a dit dans ce domaine.
3. Phase Check : vérifier qu’il n’y a pas d’écart entre ce que l’on a dit et ce que l’on a
fait.
4. Phase Act : entreprendre des actions correctives pour régler tout écart qui aurait été
constaté précédemment.
Les termes français pour nommer le modèle PDCA pourraient être « Planification », «
Action », « Vérification » et « Correction ».
Figure 3: Le modèle «PDCA »
34
Ce modèle présente deux propriétés principales : il est cyclique et fractal.
 Caractère cyclique : C’est ce cycle Plan, Do, Check, Act qui permet
d’atteindre les objectifs (de sécurité, de qualité, d’environnement ou autre) fixés
par le système de management. En revanche, que se passe-t-il une fois que
l’objectif a été atteint ? Un nouveau cycle doit être entrepris. C’est pour cela
que l’on peut voir une flèche (figure en haut) entre la phase Act et la phase
Plan. Cette flèche permet à l’entreprise non seulement d’atteindre ses objectifs,
mais aussi de s’y tenir dans la durée. Un système de management est donc un
processus qui tourne indéfiniment.
 Caractère fractal : Quelle que soit l’échelle à laquelle on observe les systèmes
de management, on doit retrouver le modèle Plan, Do, Check, Act.
III.6.2 La première phase du modèle PDCA : la phase « Plan »
Elle consiste à fixer les objectifs du SMSI en suivant quatre grandes étapes, la
politique et le périmètre du SMSI, l’appréciation des risques, le traitement des risques
décidé en tenant compte des risques résiduels et la sélection des mesures de
sécurité présentées dans le SoA (Statement of Applicability : un document sous forme
de tableau qui énumère les mesures de sécurité du SMSI ainsi que celles non
appliquées).
35
Figure 4: Processus de déroulement de la phase « Plan »
A. Politique et périmètre du SMSI
La première étape consiste à définir la politique et le périmètre du SMSI. La politique

est là pour préciser le niveau de sécurité qui sera appliqué au sein du périmètre du
SMSI. La norme ne fixe pas d’exigences sur le périmètre, il peut être restreint ou
couvrir l’ensemble des activités de l’organisme. L’objectif est d’y inclure les activités
pour lesquelles les parties prenantes exigent un certain niveau de confiance.
B. Appréciation des risques
La deuxième étape concerne un des points les plus importants de l’ISO/CEI 27001,
l’appréciation des risques. Le problème de l’appréciation des risques n’est pas
nouveau et est traité par de nombreuses méthodes développées dans différents secteurs
privés, académiques et agences gouvernementales. Certaines méthodes sont très
répandues dans les organismes. En France, les plus connues sont EBIOS et MEHARI,
aux Etats- Unis, OCTAVE. L’ISO/CEI propose aussi une méthode, la norme ISO/CEI
27005. Cette norme ne fait que fixer un cahier des charges spécifiant chacune des
étapes clefs de l’appréciation des risques.
Dans les points suivants nous détaillerons le processus d’appréciation des risques
avant de donner deux exemples de méthodes parmi les plus connues.
36
B.1 Processus d’appréciation des risques :
Le processus d’appréciation des risques se déroule en sept étapes, illustrées dans figure
ci-dessous.
Identification des actifs
Identification des propriétaires d'actifs
Identification des vulnérabilités
Identification des menaces
Identification des impacts
Evaluation de la vraisemblance
Estimation des niveaux de risque
Figure 5: Le processus d’appréciation des risques
La première étape consiste à dresser une liste de tous les actifs qui ont une
importance en matière d’information au sein du SMSI. On distingue généralement six
catégories d’actifs.
 Matériel, pour tous les équipements réseau et système.

 Physique, pour les bureaux, lieux de production, de livraisons.
 Logiciel, pour les bases de données, fichiers, les systèmes d’exploitation.
 Humain, pour tous les collaborateurs de l’organisme.
 Documents, pour les documents papier, manuels d’utilisation.
 Immatériel, pour le savoir-faire de l’organisme.
37
La deuxième étape vise à attribuer pour chaque actif d’information un « propriétaire

». La norme définit le propriétaire comme étant la personne qui connaît le mieux la
valeur et les conséquences d’une compromission en termes de disponibilité,
d’intégrité et de confidentialité de l’actif.
La troisième étape est l’identification des vulnérabilités des actifs recensés. La

vulnérabilité est la propriété intrinsèque du bien qui l’expose aux menaces. A titre
d’exemple, un ordinateur portable est vulnérable au vol mais sa vulnérabilité n’est pas
le vol mais sa portabilité. Dans ce cas l’identification de la vulnérabilité est la
portabilité.
La quatrième étape est l’identification des menaces qui pèsent sur les actifs
d’information précédemment recensés. Si l’on reprend l’exemple de l’ordinateur
portable, la menace est dans ce cas le vol.
La cinquième étape vise à évaluer l’impact d’une perte de la confidentialité, de la

disponibilité ou de l’intégrité sur les actifs. Pour mesurer cet impact on peut par
exemple utiliser une matrice des risques, la norme n’impose aucun critère de mesure.
La sixième étape demande d’évaluer la vraisemblance des précédentes étapes du

processus en plaçant dans leur contexte les actifs. Il s’agit par exemple de considérer
les mesures de sécurité déjà en vigueur dans l’organisme. Si l’ordinateur portable
possède une clef d’authentification, un cryptage de ses données ou un accès VPN pour
travailler, alors la vraisemblance d’observer un impact sur la confidentialité, la
disponibilité ou l’intégrité de ses données est limitée.
La septième étape consiste à attribuer une note finale reflétant les risques pour
chacun des actifs d’information. La norme n’impose aucune formule, on peut par
exemple utiliser un code couleur (rouge pour un niveau de risque très élevé, orange
pour moyen et vert pour faible.
Dans le point suivant, nous présentons deux méthodes connues et largement

employées par les organismes pour l’appréciation des risques de leur SMSI.
38
B.2 Méthode d’appréciation des risques
En 2004, une étude du CLUSIF (Club de la Sécurité de l’Information Français)

dénombrait plus de deux cents méthodes d’appréciation des risques. Nous allons
parler d’une méthode parmi les plus célèbres à savoir : MEHARI.
LA METHODE MEHARI
La méthode MEHARI (Méthode Harmonisée d’Analyse de Risques) a été développée

dans les années 1990 par le CLUSIF (Club de la Sécurité de l'Information Français). A
l’origine, cette méthode ne traitait que de l’analyse des risques. Elle a évolué pour
permettre une gestion de la sécurité de l’organisme dans un environnement ouvert et
géographiquement réparti.
MEHARI a été adoptée par des milliers d’organismes à travers le monde et reste la
méthode la plus utilisée en France, en particulier dans l'industrie. L’utilisation et la
distribution de son logiciel sont libres. En outre, certaines bases de connaissances sont
disponibles et une étude illustre la méthode pour faciliter son utilisation.
MEHARI repose sur des scénarios de risques qui permettent d’identifier les risques
potentiels au sein de l’organisme. Elle est définie comme une boîte à outils conçue
pour la gestion de la sécurité. En fonction des besoins, des choix d’orientation, de
politique de l'organisation ou simplement des circonstances, la méthode veille à ce
qu'une solution d’appréciation des risques appropriée puisse être élaborée. La méthode
est présentée sous la forme d'un ensemble que l'on appelle modules, centrés sur
l'évaluation des risques et leur gestion.
1. Principe de fonctionnement
La méthode MEHARI prend avant tout en compte les informations de l’entreprise afin
de développer un plan afin de mieux définir les points à protéger dans l’entreprise.
Ainsi, MEHARI permettra à l'entreprise de définir :
 Un plan stratégique de sécurité

 Un plan opérationnel de sécurité par site ou entité
39
 Un plan opérationnel d'entreprise

 Le traitement d'une famille de scénarios ou d'un scénario particulier
 Le traitement d'un risque spécifique (Accident, Erreur, Malveillance)
 Le traitement d'un critère de sécurité (Disponibilité, Intégrité, Confidentialité)
MEHARI, conjugue la rigueur d'une analyse des risques liés formellement au niveau
de vulnérabilité du SI, à l'adaptabilité de la gravité des risques étudiés. En effet, la
présence ou l'absence de mesures de sécurité va réduire ou non, soit la potentialité de
survenance d'un sinistre, soit son impact.
L'interaction de ces types de mesures concoure à réduire la gravité du risque jusqu'au

niveau choisi.
Figure 6: Enjeux critiques + Vulnérabilités fortes = Risques inacceptables
Cette expression très simple signifie que le management de la sécurité a pour objectif
fondamental d'éviter de se trouver dans une situation telle que des vulnérabilités fortes
pourraient être exploitées et conduire à des sinistres très critiques pour l'entreprise ou
l'organisation qui en est victime.
Les phases de la méthode MEHARI sont les suivantes :
 Phase 1 : établissement d'un plan stratégique de sécurité (global) qui fournit

notamment :
 la définition des métriques des risques et la fixation des objectifs de sécurité,
40
 la reconnaissance et la détermination des valeurs de l'entreprise,

 l'établissement d'une politique de sécurité pour l’entreprise, l'établissement
d'une charte de management.
 Phase 2 : établissement de plans opérationnels de sécurité réalisés par les
différentes unités de l'entreprise
 Phase 3 : consolidation des plans opérationnels (Plan global).
Ces différentes étapes seront détaillées par la suite : étude des modalités et des moyens
à mettre en œuvre.
2. Mise en place de la méthode
MEHARI se présente comme un ensemble cohérent d’outils et de méthodes de

management de la sécurité, fondés sur l’analyse des risques. Les deux aspects
fondamentaux de MEHARI sont le modèle de risque (qualitatif et quantitatif) et les
modèles de management de la sécurité basés sur l’analyse de risque. MEHARI vise à
donner des outils et des méthodes pour sélectionner les mesures de sécurité les plus
pertinentes pour une entreprise donnée.
Les différentes phases ont pour objectif d’établir le contexte d’entreprise, d’identifier
les actifs et les menaces, d’analyser les risques et enfin de définir les mesures de
sécurité (traitement du risque).
 Plan stratégique
C’est le plan qui examinera l’entreprise sur un aspect général. Les aspects qui seront
pris en compte lors de cette analyse, sont : la classification des ressources de
l’entreprise, l’ensemble des risques existants, et ses objectifs en terme de sécurité.
 Première étape : mettre en avant les risques possibles
Lors de l’audit, répertorier les risques pouvant pénaliser l’activité de l’entreprise.

Ensuite pour chacun des risques détectés on définit :
41
 Son potentiel : c'est-à-dire la capacité de destruction. C’est pour cela que

l’on mettra en place des tests ou plus précisément des scénarios qui
permettent de se mettre en situation et d’évaluer ce potentiel.
 Son impact : en clair, une fois la catastrophe arrivée concrètement, on
mesure l’ampleur des dégâts réels.
 Sa gravité : déterminer si vraiment les dégâts sont des handicapants
pour l’entreprise et son fonctionnement.
 Deuxième étape : limite d’acceptabilité
De part ces caractéristiques nous allons ensuite mettre en place une échelle pour le
degré d’acceptabilité non seulement sur le plan de la gravité mais aussi du temps.
Combien de temps l’entreprise pourra être dans cet handicape sans que cela devienne
dangereux pour sa survie.
 Troisième étape : les ressources de l’entreprise
Lors de cette étape nous définirons en fait les valeurs de l’entreprise, quels services
génèrent le plus de chiffre d’affaire, ou sont vitaux pour le fonctionnement de la
société.
 Quatrième étape : solution et indicateurs
C’est l’étape finale, c’est lors de celle-ci que l’on mettra en place dans un premier
temps les indicateurs afin de prévenir au maximum l’arrivée d’une catastrophe , que
l’on regroupera toutes les informations que l’on a pu récupérer et qu’on les analysera
de façon globale afin de pouvoir mettre en œuvre des solutions : règles de sécurité et
de responsabilité. Les solutions s’appliquent sur plusieurs niveaux :
Ce découpage permet un regroupement des mesures en six grandes familles :
42
 Les mesures structurelles qui jouent sur la structure même du SI, pour
éviter certaines agressions ou en limiter la gravité.
 Les mesures dissuasives qui permettent, dans le cas d'agresseurs humains,
d'éviter qu'ils mettent à exécution la menace potentielle en déclenchant
l'agression.
 Les mesures préventives : celles qui permettent d'empêcher les
détériorations ou d'éviter qu'une agression n'atteigne des ressources du SI.
 Les mesures de protection qui, sans empêcher les détériorations,
permettent tout au moins d'en limiter l'ampleur.
 Les mesures palliatives qui agissent une fois les détériorations accomplies,
et qui permettent, d'une part d'en limiter les conséquences au niveau de
l'entreprise, d'autre part de restaurer les ressources détériorées pour retrouver
l'état initial.
 Les mesures de récupération qui visent à récupérer une partie du préjudice
subi par transfert des pertes sur des tiers, par le biais des assurances ou de
dommages et intérêts consécutifs à des actions en justice, dans le cas
d'agresseurs humains.
 Plan opérationnel de sécurité

 Spécifier le domaine et les outils : élaboration des scénarios, périmètre et
niveau de détail, validation de la classification
 Auditer le niveau de sécurité : audit des services et sous services, consolidation
au niveau des cellules
 Evaluer la gravité des scénarios : Détermination Potentialité/ Impact/ Gravité
 Exprimer les besoins de sécurité : mesures générales et spécifiques
 Planifier les actions de sécurité : mesures spécifiques et prioritaires, autres
mesures hiérarchisées.
43
 Plan opérationnel d’entreprise
Dans cette étape il s’agit fondamentalement de mettre en place des scénarios sur les
impacts et les conséquences que peuvent avoir ces sinistres sur le bon
fonctionnement de l’entreprise. Cette partie conclue la boucle de l’application de la
méthode Méhari par la mise en place d’un outil permettant le suivi des opérations à
effectuer afin d’améliorer la sécurité de la société.
Pour que cette stratégie soit couronnée de succès il est nécessaire de s’assurer que :
 Elle est connue et comprise par la Direction et le personnel de l’entreprise ;

 Elle est pilotée et sa mise en œuvre est assurée et mesurée ;
 Elle reste pertinente dans le temps ;
 Elle se décline en objectifs stratégiques reliés à des objectifs tactiques
(ensemble des initiatives, projets, processus et organisation) qui forment un tout
cohérent et contribuent pleinement à l’atteinte de la couverture des risques
 Elle est financée et que les budgets sont affectés avec l’assurance de leur
meilleure contribution au succès de cette stratégie
Bénéfices :
 Les objectifs poursuivis par la stratégie de sécurité sont conformes à ceux de

l'entreprise.
 Impact sur l'image véhiculée par la SSI.
 Pilotage et mesure dans la durée de la stratégie de sécurité sur l'ensemble de ses
aspects, en privilégiant le caractère stratège du RSSI (Responsable de la
Sécurité du Système d’Information).
 Intégration des aspects stratégiques et opérationnels
 La démarche MEHARI
Elle peut être résumée par le schéma suivant :
44
Indicateur
tableau de
bord
Plan Plan
opérationnel stratégique
d'entreprise de sécurité
Scénario plan Objectifs

d'action métriques
Plan
opérationnel
de sécurité
Figure 7: La démarche MEHARI
C. Traitement des risques
La troisième étape concerne le choix du traitement des risques. L’ISO/CEI 27001 a

identifié quatre (04) traitements possibles du risque, l’acceptation, l’évitement, le
transfert et la réduction.
 « Accepter » le risque revient à ne déployer aucune mesure de sécurité autre

que celles déjà en place. Cette décision peut être justifiée si le vol de données
dans un cas précis n’a pas d’impact sur l’organisme.
 « Eviter » le risque consiste à supprimer par exemple l’activité ou le matériel
offrant un risque.
 « Transférer » un risque par souscription d’une assurance ou par sous-
traitance. Ces moyens de transfert du risque sont souvent employés quand
l’organisme ne peut ou ne souhaite pas mettre en place les mesures de
sécurité qui permettraient de le réduire.
45
 « Réduire » le risque consiste à prendre des mesures techniques

et organisationnelles pour ramener à un niveau acceptable le risque. C’est le
traitement le plus courant.
Il existe d’autres traitements du risque possibles mais pour être en conformité avec la
norme, il faut en priorité considérer ceux que nous venons de citer.
Après avoir sélectionné le traitement et mis en place les mesures de sécurité, un risque
peut persister. Il convient de traiter ce risque comme les autres c'est-à-dire, l’accepter,
l’éviter, le transférer ou le réduire.
D. Sélection des mesures de sécurité
L’étape 4 est la dernière étape de la phase « Plan » du modèle PDCA, elle consiste à
sélectionner les mesures de sécurité. La norme ISO/CEI 27001 propose dans son
annexe A, 133 mesures de sécurité réparties sur onze (11) chapitres. A ce stade, le
travail consiste à dresser un tableau SoA dans lequel figurent les 133 mesures qu’il
faut déclarer applicables ou non applicables, pour réduire les risques pour le SMSI.
Notons que les 133 mesures proposées par l’ISO/CEI 27001 répertorient presque tout
ce qui peut être entrepris en matière de sécurité de l’information cependant, cette liste
ne comporte pas d’exemples ni d’explications sur le déploiement des mesures à
entreprendre. L’ISO/CEI 27002 répond en partie à ce besoin en fournissant une série
de préconisations et d’exemples techniques et organisationnels qui couvrent la
liste de l’ISO/CEI 27001.
Après avoir choisie la politique et le périmètre du SMSI, appréciés et traités les

risques, et sélectionnées les 133 mesures de sécurité dans le tableau SoA, il faut mettre
en œuvre les objectifs fixés de la phase « Plan » du PDCA. Il s’agit de la phase « Do »
du PDCA.
III.6.3 Phase « Do »
Cette phase consiste à décrire la mise en œuvre des mesures de sécurité

sélectionnées dans le SoA à travers quatre étapes.
46
A. Plan de traitement
Il faut premièrement gérer l’interdépendance des actions à entreprendre. Certaines

mesures sont partiellement ou déjà en place, d’autres doivent être intégralement
déployées ou nécessitent la mise en œuvre d’une autre action avant de pouvoir être
lancées. Ce travail revient à établir un plan de traitement qui peut être assimilé à de la
gestion de projet. Une fois ce travail effectué, il faut déployer les mesures de sécurité
en suivant le plan de traitement.
Par la suite, le responsable de projet doit définir des « mesures d’efficacité » pour
contrôler le bon fonctionnement du SMSI.
B. Choix des indicateurs
Ce point consiste à mettre en place des indicateurs de performance pour vérifier

l’efficacité des mesures de sécurité ainsi que des indicateurs de conformité pour
contrôler la conformité du SMSI. Trouver de bons indicateurs n’est pas une tâche
facile.
La norme ne préconise pas d’indicateurs précis à utiliser mais l’ISO/CEI 27004

propose une démarche qui peut aider à les sélectionner.
L’étape suivante concerne la sensibilisation des collaborateurs aux principes de la

sécurité de l’information.
C. Formation et sensibilisation des collaborateurs
Nous avons vu que les mesures de sécurité couvrent de nombreux domaines allant de
la sécurité organisationnelle à la sécurité physique, en passant par la sécurité des
systèmes réseaux etc. Les collaborateurs doivent maîtriser les outils de sécurité
déployés dans les domaines très variés. Une formation du personnel peut s’avérer
nécessaire.
47
La sensibilisation à la sécurité du SI concerne tous les collaborateurs. Elle peut débuter

par un rappel des engagements de leur entreprise en matière de sécurité et se
poursuivre par une liste de conseils tels que le respect de certaines règles de sécurité
pour les mots de passe et l’environnement de travail.
D. Maintenance du SMSI
La maintenance consiste à garantir le bon fonctionnement de chacun des processus du

SMSI et vérifier que leur documentation est à jour. Cela permet à l’auditeur
externe de contrôler la gestion du SMSI. Il est à noter que tous les systèmes de
management ISO sont concernés par la maintenance.
A ce stade de l’avancement du SMSI, les mesures identifiées du SoA fonctionnent, les

indicateurs sont implémentés et les collaborateurs de l’organisme formés et
sensibilisés à la sécurité du SI, nous pouvons poursuivre avec la phase « Check » du
PDCA.
III.6.4 La phase « Check »
La phase « Check » du PDCA concerne les moyens de contrôle à mettre en place pour
assurer «l’efficacité » du SMSI et sa « conformité » au cahier des charges de la norme
ISO/CEI 27001. Pour répondre à ces deux exigences de la norme, les organismes
emploient le contrôle et les audits internes ainsi que les revues de direction.
A. Les audits internes
L’audit interne peut s’organiser avec le personnel de l’organisme ou être sous-traité à

un cabinet conseil. Si l’audit est confié à un collaborateur, il ne faut pas que ce dernier
puisse auditer un processus dans lequel il est impliqué au niveau de sa mise en œuvre
ou de son exploitation. L’audit a pour but de contrôler la conformité et l’efficacité du
SMSI en recherchant les écarts entre la documentation du système (enregistrement,
procédures, etc.) et les activités de l’organisme. La norme exige que la méthode
utilisée pour l’audit soit documentée dans une procédure et que les rapports soient
enregistrés pour être utilisés lors des revues de direction.
48
B. Les contrôles internes
L’objectif du contrôle interne est de s’assurer au quotidien que les collaborateurs

appliquent correctement leurs procédures. Contrairement à l’audit interne qui est
planifié longtemps à l’avance, les contrôles internes doivent être inopinés.
C. Revues de direction
La revue est une réunion annuelle qui permet aux dirigeants de l’organisme
d’analyser les événements qui se sont déroulés sur l’année en cours. Les points passés
en revue sont généralement :
 les résultats des audits,

 le retour des parties prenantes,
 l’état des lieux sur les actions préventives et correctives,
 les menaces mal appréhendées lors de l’appréciation des risques,
 l’interprétation des indicateurs et les changements survenus dans l’organisme.
A partir de ces informations la direction peut fixer de nouveaux objectifs et allouer de

nouvelles ressources (financières, humaines et matérielles).
Les contrôles de la phase « Check » peuvent faire apparaître des dysfonctionnements

du SMSI. Cela peut être un écart entre les exigences de la norme et le système de
management ou des mesures de sécurité inefficaces ou non respectés.
C’est dans la phase « Act » du PDCA que l’on réduit les dysfonctionnements par des
actions correctives, préventives ou d’améliorations.
III.6.5 La phase « Act »
A. Actions correctives
On intervient de manière « corrective » lorsqu’un dysfonctionnement ou un écart est

constaté. On agit premièrement sur les effets pour corriger cet écart ou
dysfonctionnement, puis sur les causes pour éviter qu’ils ne se répètent.
B. Actions préventives
49
On emploie des actions préventives quand une situation à risque est détectée. On agit
sur les causes avant que l’écart ou le dysfonctionnement ne se produisent.
C. Actions d’améliorations
Les actions d’améliorations ont pour objectif l’amélioration de la performance du

SMSI. Les résultats des différentes actions doivent être enregistrés et communiqués
aux parties prenantes. Ces actions contribuent à rendre plus efficace et performant le
SMSI.
50
PARTIE IV : DEMARCHE DE REALISATION D’UNE MISSION

D’AUDIT DE SECURITE
51
IV.1 CYCLE DE VIE DE L’AUDIT DE SECURITE D’UN SI
Essentiellement, l’audit de sécurité est désigné comme étant l’outil de contrôle pour
vérifier que les moyens et procédures mis en œuvre pour la protection d’un SI, sont
efficaces ou le cas échéant, en relever leurs faiblesses. Les moyens et les procédures de
protection du SI étant définis dans la politique de sécurité, l’audit de sécurité est aussi
appelé audit de la politique de sécurité. Il est utile de relever que le procédé d’audit de
sécurité à travers les méthodes d’analyse et de gestion des risques peut également être
utilisé pour aboutir à une politique de sécurité.
Le processus d’audit de sécurité est un processus répétitif et indéfectible. Il décrit un

cycle de vie pouvant être schématisé de la manière suivante :
Système d’information
audité Identification
Audit des
vulnérabilités
organisationnel
d’ordre
et physique organisationnel
et physique
Détection
Test Audit automatisée des
technique vulnérabilités et
d’intrusion
des failles connues
Identification des
vulnérabilités
Figure 8: Cycle de vie d’audit de sécurité
L’audit de sécurité d’un SI se présente essentiellement suivant deux parties comme le

présente la figure 9 :
 L’audit organisationnel et physique.

 L’audit technique.
52
Une troisième partie optionnelle, mais fortement recomendée peut être également
considérée. Il s’agit du test d’intrusion encore appelé audit intrusif. Enfin un rapport
d’audit est établi à l’issue de ces étapes. Ce rapport présente une synthèse de l’audit
ainsi que les recommandations à mettre en place pour corriger les défaillances
organisationnelles et techniques constatées. Une présentation plus détaillée de ces
étapes d’audit sera effectuée dans la partie suivante.
IV.1.1 Description
Il est très important de rappeler qu’en aucun cas l’audit de sécurité ne doit se résumer
à l’une de ses actions la plus simple, la recherche active des failles, à l’aide de
scanners de vulnérabilités, qui effectuent les recherches sur la base d’attaques connues
et qui ne détectent donc que les failles connues. Cette fonction de l’audit effectue des
tests de vulnérabilités d’un point donné du réseau contrôlé tandis qu’une autre fonction
de l’audit, à savoir les tests d’intrusion, sont pratiqués depuis l’extérieur. Ces derniers
ne peuvent mettre en évidence que des intrusions possibles à travers des vulnérabilités
identifiées et il est très fréquent, là aussi, que des failles potentielles ne soient pas
décelées.
Seul un audit purement technique, qui, à l’issue d’une véritable étude inspectera
l’architecture du réseau de télécommunication et informatique ainsi que le système
d’information, pourra assurer que le système ne présente pas de failles pouvant être
exploitées ou au contraire, le SI est sujet à des failles qu’il faut combler.
Cet audit est généralement pratiqué après l’audit organisationnel qui identifie les
risques et mesure tout élément critique, métier et informatique, et confronte les
pratiques de sécurité existantes à la réalité du terrain. D’ailleurs l'audit de sécurité se
doit d'être organisationnel, puis technique. C’est cette approche que les professionnels
de la sécurité informatique qualifient d’audit de sécurité. Elle permet d’apprécier la
sécurité d’une manière générale en tenant compte de la sécurité physique,
organisationnelle, logique, informatique et métier.
IV.1.2 Intérêts
53
Bien que souvent sa nécessité soit méconnue, l'audit est indispensable pour toute
entreprise, quel que soit sa taille, dès lors que celle-ci utilise des SI. Sa première mise
en pratique doit normalement s’effectuer lors de la conception du SI afin d’aboutir au
Choix des solutions techniques y compris les solutions de sécurité et déboucher dans le
même temps sur une politique de sécurité.
Ensuite l’audit est nécessaire à la mise en place initiale de la politique de sécurité des
systèmes d’information (PSSI). Ceci pour contrôler l'efficacité des moyens et
procédures mis en œuvre et que la PSSI est correctement appliquée, ou, le cas échéant,
en relever les insuffisances.
L’audit de sécurité doit ensuite être effectué assez régulièrement pour s’assurer que les
usages restent conformes à la réglementation édictée par la PSSI, mais surtout pour
s’assurer que les mesures de sécurité sont mises à niveau à chaque détection d’une
nouvelle vulnérabilité et que les mises à jour des failles et des logiciels sont
continuellement réalisées.
IV.2 PROCESSUS DE REALISATION D’UNE MISSION D’AUDIT
Comme nous l’avons mentionné précédemment, l’audit de sécurité des systèmes

d’information se déroule suivant deux principales étapes. Cependant il existe d’autres
phases toutes aussi importantes, avant et après les deux principales phases d’audit.
L’ensemble du processus d’audit peut être schématisé à travers la figure suivante :
54
Préparation de l'audit
Audit organisationnel et physique
Audit technique
Test d'intrusion
Rapport d'audit(Synthèse et recommandation)
Phase d'accompagnement post-audit
Figure 9: Processus d’audit
IV.2.1 PREPARATION DE L’AUDIT

Cette phase est aussi appelée phase de pré-audit. Elle constitue une phase importante
pour la réalisation de l’audit sur terrain. En effet, c’est au cours de cette phase que se
dessinent les grands axes qui devront être suivis lors de l’audit sur terrain.
A. Objectifs
En somme, cette étape permet de :
 Définir les champs d’étude et le périmètre de la mission,

 Définir un référentiel de sécurité (dépend des exigences et attentes des
responsables du site audité, type d’audit),
 D’élaborer une batterie de questionnaires par rapport au référentiel défini à
partir des exigences et des attentes des responsables du site audité,
 Définir un planning de réalisation de la mission (planification des entretiens,
informations de personnes impliquées, estimation de la durée de chaque tâche
…)
B. Préparation de la mission
55
Elle se manifeste par des rencontres entre auditeurs et responsables de la structure à

auditer. Au cours de ces entretiens, les espérances et les exigences des responsables
vis-à-vis de l’audit devront être exprimées. L’audité devra donner les informations et
les autorisations nécessaires à la réalisation de l’audit. Aussi, le planning de
réalisation de la mission de l’audit doit être fixé.
C. Détermination des référentiels
Il s’agit de fixer les normes et méthodes à utiliser pour mettre en œuvre l’audit. Elles
doivent être déterminées en accord avec le responsable qui doit préciser quelles sont
les exigences de son entreprise.
Le référentiel est pour la plus part du temps, l’un des référentiels normatifs (type ISO
par exemple), mais peut aussi être propre à l’entreprise.
L’auditeur doit avant toute chose prendre connaissance du référentiel et l’intégrer dans
sa méthode d’audit.
Quelques exemples de référentiels :
 ISO/IEC 27001- ISO/IEC 27002

 Référentiel de méthode d’analyse de risque : EBIOS, MEHARI, ISO/IEC
27005, COBIT
 Règlement interne et politique de sécurité de l’entreprise.
Voir partie B.2 pour le choix des référentiels du document.
D. Organisation de l’audit
La qualité de l’organisation dépend en grande partie du choix ou de la préparation d’un

guide d’audit qui permettra à l’auditeur ainsi qu’à toute son équipe de gagner
énormément en temps.
Avant de commencer un audit, l’auditeur doit se renseigner sur les conditions d’accès
au site (engagement de confidentialité, habilitation diverse, demandes d’accès
préalable, lettre de mission, contrat …)
56
Conseils
Il est souhaitable pour un auditeur de demander un interlocuteur privilégié sur le site

audité, qui sera le facilitateur pour la prise de rendez-vous et les autorisations d’accès.
Il sera utile pour préciser le nom des personnes à rencontrer.
Il est fortement recommandé de réaliser les audits à plusieurs auditeurs :
 Pour regrouper les constats et les réponses

 Pour optimiser le temps d’inspection du site
 Pour se répartir les tâches (à tour de rôle, un conduit l’entretien, l’autre prend
les notes)
 Pour assurer une formation continue des apprentis (associer de préférence un
junior et un sénior)
 Pour faciliter la rédaction du rapport.
E. Le périmètre de l’audit :
Déterminer par rapport aux exigences et aux attentes de l’entreprise, quel entité du
système peut être contrôlée :
 L’ensemble du site : ça peut être tout le bâtiment, ou alors une ou plusieurs

salles, un ou plusieurs département…
 L’infrastructure informatique : Quels serveurs, postes de travail, routeurs,
commutateurs, logiciels (pare-feu, antivirus ...) Caméras, imprimantes, scanners
…?
 Le personnel : qui peut – on interroger, ou alors qui doit – on interroger ?
 La documentation : quels documents analyser ?
F. Les documents à demander
La plus part des documents seront à consulter sur place. Voici une liste de documents à
demander (à consulter sur place ou avant l’arrivée sur le site) :
57
 Les plans de masse : câblage, dispositif du système de sécurité incendie,

caméras …
 Les procédures : politiques de sécurité, contrôle d’accès, traitement des
alarmes, consignes de sécurités, gestion des incidents …
 Les contrats de maintenance de site et de l’infrastructure informatique
 Les autres documents : l’architecture du système d’information, la charte
d’utilisation du système d’information, l’organigramme, les rapports des audits
précédents, la liste des serveurs, la liste des principales applications …
Tous ces documents doivent être fournis par l’entreprise s’ils existent.
G. Personnes à rencontrer et agenda
Le choix des personnes à rencontrer ne doit pas se porter uniquement sur les
responsables, mais également sur les exécutants : le chef de centre qui est
l’interlocuteur privilégié et qui va demander à ses équipes de bien répondre aux
auditeurs, les responsables des salles, les responsables des services…
Faire un tableau : interlocuteur, sujet, lieu et heure de rendez-vous, adresse (Email,

téléphone…) à fournir à l’organisateur des entretiens (qui peut être l’auditeur lui-
même)
Avoir un interlocuteur unique qui organise les rendez-vous, qui récupère les
documents et les preuves demandés.
H. Durée de la mission
Selon le degré de granularité, le périmètre du SI, le nombre de documents à

examiner, le nombre d’entretien et de contrôle, la disponibilité des intervenants …
La durée d’un audit de sécurité peut aller de plusieurs jours à plusieurs semaines.
I. Préparation des auditeurs
58
Profil des auditeurs
Le profil minimum que doit avoir un auditeur :
 Avoir le niveau de formation nécessaire : compétences en tant qu’auditeur,

compétences dans les différents domaines de l’informatique (notamment la
sécurité et le réseau, les systèmes d’information)
 Eviter les conflits d’intérêts et s’astreindre au secret professionnel (déontologie)
 Choisir les équipes d’auditeur de préférence avec au moins un expert du
domaine et un auditeur confirmé
 Etre pédagogue c’est-à-dire apte à enseigner
 Etc.
La conduite d’une mission d’audit nécessite des qualités humaines requises en

management :
 Qualité d’écoute
 Gestion du temps
 Compétences en conduite d’entretiens et de réunions
 Curiosité
 Force de conviction, mise en confiance, voire talent de négociation.
 Gestion du stress, de la pression et des conflits.
 Etc.
Les contraintes de temps et la non-coopération de certains audités nécessite de telles

qualités relationnelles et professionnelles.
Tâche des auditeurs
Avant de réaliser leur mission, les auditeurs doivent s’assurer qu’ils possèdent tous les
outils et les informations nécessaires à son bon déroulement.
La première étape pour les auditeurs consiste à étudier de manière fine la

documentation remise par l’entité auditée pour avoir une première idée des
59
équipements rencontrés (type des serveurs, architecture utilisée, logiciels mis en place,
etc.). Une politique de sécurité des systèmes d’information (PSSI) formalisée ou une
étude de risques serait vraiment utile à l’auditeur afin d’adapter finement l’audit à
l’entité, mais il est plus rare d’en rencontrer. Ces documents sont pourtant signes d’un
premier niveau de maturité en Sécurité des SI.
Ensuite, les auditeurs installent sur leurs machines les différents outils qui leur seront
utiles pour réaliser l’audit. Il peut arriver que le périmètre des audits ait tendance à ne
pas être figé, et qu’ils pourront être amenés à auditer des systèmes qui n’étaient pas
prévus initialement. Leur « boîte à outils » devra donc être la plus complète possible.
Pour ce faire, la capitalisation est essentielle. Un moyen pratique de la réaliser est de

disposer d’un serveur central, localisé dans les locaux de l’équipe d’auditeurs, qui
recensera les différents outils d’audits à utiliser ainsi que les méthodes et les normes
des auditeurs. Ce serveur et son contenu doit cependant être maintenu (et mise à jour)
régulièrement afin de maintenir les compétences et connaissances du bureau. En
particulier, les différents auditeurs peuvent se focaliser sur leurs domaines de
prédilection et écrire des fiches ou guides qu’ils pourront ensuite mettre à disposition
de l’ensemble de l’équipe. Cette méthode permet d’approfondir des domaines, de
pérenniser les compétences et de faire bénéficier l’équipe de ces compétences.
Un autre point essentiel pour les auditeurs est de sécuriser leurs machines de manière
approfondie. En effet, si celles-ci étaient volées, les données sensibles de l’audit
contenues sur ces machines ne doivent pas pouvoir être récupérées par une tierce
personne. Pour les mêmes raisons, les machines ne doivent pas pouvoir être
compromises via une attaque à cause d’un défaut de sécurisation (typiquement un mot
de passe trop faible ou une mise à jour oubliée).
Matériel d’un auditeur :
 Un PC portable standard,
 un câble droit, un croiseur/décroiseur (petit adaptateur permettant de changer un
câble droit en croisé et réciproquement),
60
 un hub (ou concentrateur),

 une clé USB (sécurisé),
 un live-CD : ce dernier est en fait un système d’exploitation complet, bootable,
tenant sur un CD. En mettant ce CD dans une machine, et en démarrant avec, la
machine va lire ce CD et démarrer directement le système d’exploitation s’y
trouvant. Un des live-CDs les plus connus dédié à l’audit, contenant de
nombreux outils déjà préinstallés et permettant de réaliser directement un audit
est « Kali Linux »
IV.2.2 AUDIT NIVEAU 1 : AUDIT ORGANISATIONNEL ET

PHYSIQUE
A. Objectifs
Cette première phase de l’audit permet d’avoir une vision qualitative et quantitative
des différents facteurs de la sécurité informatique du site audité et dídentifier les
points critiques du système dínformation. En d’autre terme, cette étape permet d’avoir
une vue globale de l´état de sécurité du système dínformation et d’identifier les
risques potentiels sur le plan organisationnel, physique et humain.
A cette étape, il faudra :
 Élaborer un questionnaire d’audit sécurité à partir du référentiel défini

précédemment et des objectifs de la mission (NB : il est préférable que cette
partie soit traitée lors de la phase de préparation de l’audit)
 A partir du questionnaire, interviewer les acteurs importants du SI relativement
aux différentes procédures en vigueur dans la structure (organigramme, charte
informatique, politique de sécurité, règlement intérieur, procédure d’acquisition
et de maintenance du parc informatique, procédure de configuration
d’équipements et logiciels, plan de secours en cas d’incident et post incident,
référentiel de développement d’application …) ;
61
 Evaluer la conformité des différents documents aux procédures réellement

exécutées ;
 Faire une évaluation complète de l’organisation générale de la sécurité :
(réglementation, procédures, personnel), la sécurité physique des locaux (lutte
anti-incendie, contrôle des accès, sauvegarde et archivage des documents),
l'exploitation et administration du SI (sauvegarde et archivage des données,
continuité du service, journalisation ), les réseaux et télécoms (matériel
(routeurs, modems, autocommutateur..), contrôle des accès logiques, lignes et
transmission), les systèmes (poste de travail, serveur, logiciels de base, solution
antivirale) et les applications (méthodes de développement, procédures de tests
et de maintenance ...). Cette évaluation devra s’appuyer sur des référentiels
privés (ceux du client) ou publics (ISO 27002).
 Etudier la localité et le bâtiment abritant la structure (architecture, qualité de la
construction, type de porte, type de matériaux).
B. Déroulement
L’approche repose sur des interviews et sur une étude de l’existant (avec des visites de
sites, des analyses documentaires et des revues de paramétrage). Cette approche,
méthodologique, devra s’appuyer sur un ensemble de questions. Ce questionnaire
préétabli devra tenir compte et s’adapter aux réalités de l’organisme à auditer. A l’issu
de ce questionnaire, et suivant une métrique, l’auditeur est en mesure d’évaluer les
failles et d’apprécier le niveau de maturité en termes de sécurité de l’organisme, ainsi
que la conformité de cet organisme par rapport à la norme référentielle de l’audit.
B.1 Choix des référentiels (préparation de l’audit)
62
B.1.1 La norme : ISO/CEI 27002 : 2005
Pour mener à bien cette étape, le choix du référentiel s’est porté sur la norme ISO/CEI
27002 : 2005 car elle permet d’atteindre tous les objectifs de sécurité fixés par
l’ANTIC sur le plan organisationnel et physique d’un audit. De plus se conformer à la
norme ISO/CEI 27002 apporte à l’organisme un certain nombre d’avantage dans
plusieurs domaines :
 Organisation : une méthodologie de sécurité structurée et reconnue

internationalement ; image positive auprès des actionnaires lorsque l'entreprise
tend à maîtriser ses risques pour maximiser ses profits
 Conformité : la norme insiste sur la nécessité d'identifier toutes les lois et
réglementations s'appliquant à l'entreprise et la mise en œuvre de processus
adaptés pour identifier et suivre les obligations permet de prouver au moins la
volonté de conformité, ce qui tend à diminuer les amendes en cas de non-
conformité
 Gestion des risques : la norme insiste dans ses chapitres d’introduction sur la
nécessité de réaliser une analyse de risques périodiquement et définit dans les
domaines « politique de sécurité » et « organisation de la sécurité », les
pratiques à mettre en œuvre pour gérer les risques mis en lumière par l’analyse
de risque. Ceci permet une meilleure connaissance des risques et donc une
meilleure allocation des ressources permettant d’améliorer la fiabilité du
système.
 Finances : une diminution potentielle des tarifs d’assurance contre les risques
informatiques. Associant une meilleure maîtrise des risques, une meilleure
gestion des incidents et une meilleure allocation des ressources, la mise en
place d’un SMSI s’appuyant sur les normes ISO 27001 et 27002 permet une
meilleure maîtrise des coûts de la sécurité des systèmes d’informations.
 Crédibilité et confiance : la mise en place d'une politique de sécurité et des
moyens associés donne une image rassurante pour les partenaires et les clients,
notamment sur la protection des données personnelles.
63
 Ressources humaines : s'appuyer sur une norme permet de mieux faire passer
les messages de sensibilisation, notamment auprès des populations techniques.
Cette norme est disponible sur le site de l’Organisme International de Normalisation :

http://www.iso.org/iso/fr/home/store.htm
B.1.2 La méthode d’analyse de risque : MEHARI
1. Définitions
Service de sécurité :
Un « service de sécurité » est une réponse à un besoin de sécurité, exprimée en

termes génériques et fonctionnels décrivant la finalité du service, généralement en
référence à certains types de menaces.
Un service de sécurité décrit une fonction de sécurité. Cette fonction est indépendante
des mécanismes et solutions concrètes permettant la réalisation effective du service.
Exemple : le « contrôle d’accès » est un service dont la finalité ou fonction, décrite

implicitement par son titre, est de contrôler les accès, c’est – à – dire de ne laisser
passer que les personnes autorisées.
Mécanisme de sécurité :
Un « mécanisme » est une manière particulière d’assurer, totalement ou partiellement,

la fonction du service ou du sous – service. Il peut s’agir de procédure spécifique,
d’algorithme, de technologie, etc.
Par exemple pour le service d’authentification qui est un sous – service du service de
contrôle d’accès, les mécanismes possibles (pour l’authentification au système
d’information) sont les mots de passe, les systèmes biométrique, les processus
reposant sur des algorithmes contenus dans des cartes à puces.
Solution de sécurité :
64
Une « solution de sécurité » est la réalisation concrète d’un mécanisme de sécurité et

comprend les matériels et logiciels nécessaires à son déploiement, les procédures de
déploiement et de support opérationnel ainsi que les structures organisationnelles
nécessaires.
Typologie des services de sécurité :
Certains services peuvent être considérés comme des mesures générales, d’autres
comme des services techniques :
 Les mesures générales sont des mesures de sécurité reconnues comme utiles,
voire nécessaires, à la sécurité des systèmes d’information, mais dont l’effet se
situe davantage au plan de l’organisation, du pilotage de la sécurité ou de la
sensibilisation, sans influence directe sur les situations de risques précises.
 Les services techniques ont un rôle précis, une finalité directe et un effet
immédiat sur certaines situations de risque qu’il est possible de préciser.
2. Arguments
Le choix de méhari a été principalement basé sur le fait que cette méthode intègre des
questionnaires de diagnostic approfondi des mesures de sécurité qui permettent
d’évaluer le niveau de qualité des mécanismes et solutions mis en place pour réduire
les risques. Un diagnostic approfondi de ces services de sécurité organisés par
domaines constitue, lors de l’analyse de risque, un élément important d’assurance que
les services remplissent bien leur rôle, ce qui est essentiel pour qu’une analyse de
risque soit crédible et fiable.
Par ailleurs, l’utilisation du module de diagnostic de sécurité de la méthode méhari

présente plusieurs avantages à savoir :
 Le processus d’audit par le diagnostic de l’état des services de sécurité est

relativement simple : on déclenche un diagnostic (à l’aide du questionnaire) et
on détecte tous les services qui n’ont pas un niveau de qualité suffisant.
65
 Le module de diagnostic s’appuie, en pratique sur une base de connaissance

des services de sécurité (appelée Manuel de référence des services de sécurité)
qui décrit, pour chaque service, la finalité (ce qu’il fait), à quoi il sert (ce contre
quoi il lutte), les mécanismes et solutions supports du service et les éléments à
prendre en compte pour évaluer la qualité du service. De plus cette base
d’expertise peut être employée directement pour bâtir un « Référentiel de
sécurité » qui contiendra et décrira l’ensemble des règles et instructions de
sécurité à respecter dans l’entreprise ou l’organisme audité.
Les questionnaires de diagnostic couvrent ainsi, outre les systèmes d’information

et de communication, l’organisation générale, la protection générale des sites,
l’environnement de travail des utilisateurs et les aspects réglementaires et
juridiques. De ce fait, ils offrent une vision large et cohérente de la sécurité,
utilisable dans différentes approches et différents contextes, avec une progressivité
dans la profondeur d’analyse permettant de les utiliser à tous les stades de maturité
de la sécurité dans une entreprise.
Pour plus d’information sur l’utilisation de la méthode méhari, consulter la page :

https://www.clusif.asso.fr/fr/production/ouvrages/type.asp?id=METHODES
B.2 Le questionnaire et les interviews
L’élaboration d’un questionnaire d’audit (appelé schéma d’audit par la méthode

MEHARI) apparait parfois comme quelque chose de compliqué. Pourtant, ce n’est rien
d’autre que la prise en compte de solutions différentes ou de contextes différents.
Pour répondre au mieux aux exigences d’un schéma d’audit, le questionnaire proposé
par ce document c’est inspiré du questionnaire de diagnostic de l’état des services de
sécurité de la méthode MEHARI, en tenant compte uniquement des points de contrôle
de la norme ISO 27002 : 2005. De ce fait, il sera organisé selon les différents
domaines de sécurité de la norme et structuré comme suit :
66
 Une colonne pour la numérotation : la numérotation est la même que celle de

la norme.
 Une colonne pour les questions : une question pour un point de contrôle de la
norme, ce qui fait 133 questions pour les 133 points de contrôles de la norme.
 Une colonne pour la cotation : le système de cotation servira à évaluer la
qualité de processus mise en œuvre par la structure audité pour chaque point de
contrôle de la norme. (Ce système de cotation sera expliqué dans la prochaine
partie)
 Une colonne pour le coefficient : ce coefficient reflète à la fois le type de
question et le degré de maturité en sécurité auquel elle s’adresse.
La première partie du coefficient est une lettre : E, R, ou C
 E désigne une question ayant trait à l’efficacité du service

 R désigne une question ayant trait à la robustesse du service
 C désigne une question ayant trait à sa mise sous contrôle (à sa
permanence).
La deuxième partie du coefficient est un chiffre en relation avec le degré de

maturité de l’entité pour lequel la question est pertinente : 1, 2, 3 (3 uniquement
pour les questions relatives à l’efficacité du service) :
 1 désigne une question basique à laquelle toute entreprise doit répondre quel
que soit son degré de maturité.
 2 désigne un degré de maturité moyen (entreprise ou organisme ayant déjà
bien avancé en sécurité, mais devant encore progresser)
 3 représente des questions qui ne sont pertinentes que pour des entités
totalement matures.
Il est ainsi possible d’exclure du questionnaire les questions ayant trait à la mise sous
contrôle ou les questions de niveau trop élevé pour un audit de survol.
67
 Et enfin, une colonne pour les commentaires : En ce qui concerne l’usage des
questionnaires papiers qui servent de support aux interviews, il peut arriver que
les réponses à l’aide du système de cotation, dans certains cas, pose des
difficultés. Il importe alors de garder une colonne « Commentaires » dans
laquelle la réponse précise sera notée.
Pour ce qui est du déroulement des interviews, il serait convenable de distinguer des
responsables (personne à interroger) pour chaque domaine de sécurité de la norme,
c’est – à – dire que par exemple pour le « domaine 8 : Sécurité liée aux ressources
humaines », il serait convenable d’interroger le responsable des ressources humaines
de la structure audité. Par ailleurs, Il est à noter que, pour les entités plus petites par
exemple, il peut y avoir un responsable pour plusieurs domaines. Cependant, s’il y a
plusieurs responsables pour un seul domaine, il serait convenable d’interroger les
différents responsables séparément et de recueillir une moyenne pour leurs réponses
différentes à une même question. Cette stratégie a pour but d’obtenir des résultats plus
crédibles et plus efficaces.
Pour plus d’informations sur l’élaboration d’un questionnaire de diagnostic, se référé

au document intitulé « Guide de diagnostic de l’état des services de sécurité » de
MEHARI 2010.
B.3 Le traitement du questionnaire
Après la validation des Questionnaires, les réponses choisies seront introduites dans
l’outil « AUDITSec » pour permettre l’automatisation du traitement du questionnaire.
 Objectif de l’outil de sécurité AUDITSec
En utilisant l’outil de sécurité AUDITSec pour chacun des 11 domaines de sécurité

d’ISO 27002 l’auditeur peut estimer :
 l'état actuel de l'entreprise : où elle se situe aujourd'hui ;

 l'état actuel du marché : la comparaison ;
 l'ambition de l'entreprise : où elle veut se situer ;
68
 la trajectoire de croissance requise entre les situations en cours et les

situations cibles.
L'audit répertorie les points forts, et surtout les points faibles (vulnérabilités) de
tout ou partie du domaine visé.
AUDITSec donne des présentations graphiques, sous la forme d’un diagramme

de Kiviat, pour chacun des domaines.
 Mode d’opération
AUDITSec utilise un fichier Excel sans aucune macro, et de simples calculs dans
des champs protégés. L’utilisateur entre des valeurs uniquement dans les champs
permis.
Le fichier Excel contient 12 onglets représentant les 11 domaines de sécurité d’ISO

27002. Notez que les domaines portent les chiffres de 5 à 15 et que les onglets
suivent l’ordre des domaines. Le 1er onglet est une sorte de tableau de bord
regroupant les valeurs entrées dans chaque onglet.
 Instructions
 Étape 1
Une fois entré dans le fichier, vous êtes invité à entrer des valeurs dans la colonne
C en réponse au contrôle de chacun des domaines, en commençant à l’onglet
Domaine 5 (bas de page). Il faut faire de même pour chaque onglet suivant. Il y a
11 onglets en tout, représentant chacun des domaines.
L’utilisateur doit entrer une valeur de 0 à 5 en se basant sur un des éléments de

réponse ci-dessous. Il est à noter que ces valeurs proviennent du Capability
Maturity Model (CMM), en français un modèle de référence de maturité.
69
0 – Inexistant : Absence totale de processus identifiables. L’entreprise n’a même

pas pris conscience qu’il s’agissait d’un problème à étudier.
1 – Initial : On constate que l’entreprise a pris conscience de l’existence du

problème et de la nécessité de l’étudier. Il n’existe toutefois aucun processus
standardisé, mais des démarches dans ce sens tendent à être entreprises
individuellement ou cas par cas. L’approche globale du management n’est pas
organisée.
2 – Reproductible : Des processus se sont développés jusqu’au stade où des

personnes différentes exécutant la même tâche utilisent des procédures similaires.
Il n’y a pas de formation organisée ni de communication des procédures standard et
la responsabilité est laissée à l’individu. On se repose beaucoup sur les
connaissances individuelles, d’où un risque d’erreurs.
3 – Défini : On a standardisé, documenté et communiqué des processus via des

séances de formation. Ces processus doivent impérativement être suivis ; toutefois,
des écarts seront probablement constatés. Concernant les procédures elles –
mêmes, elles ne sont pas sophistiquées mais formalisent des pratiques existantes.
4 – Géré : La direction contrôle et mesure la conformité aux procédures et agit

lorsque certains processus semblent ne pas fonctionner correctement. Les processus
sont en constante amélioration et correspondent à une bonne pratique.
L’automatisation et les outils sont utilisés d’une manière limitée ou partielle.
5 – Optimal : Les processus ont atteint le niveau des bonnes pratiques, suite à une
amélioration constante et à la comparaison avec d’autres entreprises (Modèles de
Maturité). L’informatique est utilisée comme moyen intégré d’automatiser le flux
des tâches, offrant des outils qui permettent d’améliorer la qualité et l’efficacité et
de rendre l’entreprise rapidement adaptable.
Afin, d’aider l’utilisateur, il y a une définition détaillée pour chaque mesure qui
permettra d’avoir plus de détails afin de donner la meilleure réponse possible.
70
Les bonnes pratiques laissent croire qu’une valeur globale pour chacun des 11
domaines située entre 2 et 4 est acceptable.
Important
Note (a) : Si le contrôle d’un domaine n’est pas pertinent dans votre contexte, le
champ doit être vide. De cette façon, le contrôle ne sera pas comptabilisé dans le
calcul final.
Note (b) : Dans le tableau de bord, le domaine sera en couleur rouge inversée
indiquant que ce domaine n’a pas de contrôle applicable. Par exemple, le Domaine
6 a un total de neuf (9) contrôles applicables. On peut y voir que deux (02)
contrôles sont inapplicables.
Au fur et à mesure que les valeurs sont entrées, un diagramme se crée, donnant
une photographie de l ‘état actuel du point de vue de la sécurité pour le domaine
visé. En parallèle, le diagramme se met à jour dans l’onglet principal (Domaine 1
(Global)) qui représente le tableau de bord de tous les domaines.
 Étape 2
Une fois tous les onglets complétés, vous devez aller à l’onglet principal.
Tableau de bord – Domaine 1 Global
La colonne A indique le nombre de contrôles applicables pour chaque domaine

visé en lien avec ISO 27002.
71
La colonne B indique le nombre de contrôles qui ne s'appliquent pas dans un

domaine en particulier. (Représente la valeur vide).
La colonne C indique les titres pour les 11 domaines de sécurité selon la norme
ISO 27002.
La colonne D donne la valeur globale pour chaque domaine. Ce calcul se fait

automatiquement selon les valeurs entrées de 0 à 5. Si jamais le symbole suivant
apparaît : « #DIV/0 » , cela signifie que le calcul ne peut se faire parce qu’il n’y a
aucun contrôle sélectionné, donc aucune valeur 0 à 5 dans le domaine applicable.
En conséquence, ce code d'erreur est tout à fait pertinent.
La colonne F représente le pourcentage de conformité par rapport à l’ISO 27002.
Dans la colonne G, l'utilisateur est invité à entrer quelle cote il désire comme
objectif pour une certaine période. Cette valeur doit être fixée par le responsable
du site. Cette note doit être un chiffre entier entre 1 et 5.
Exemple : Si la colonne D possède une valeur de 2 alors à la colonne G la valeur

maximale suggérée serait de 3 et non supérieure à 3. Il faut en effet être réaliste car
plus la valeur dans la colonne G est élevée, plus les coûts d’implantations des
mesures de sécurité seront élevés par la même occasion.
La colonne H convertit en pourcentage la valeur entrée dans la colonne G et

indique en % la valeur que désire obtenir l’organisation pour une période.
La colonne I donne le pourcentage de l’état actuel de la sécurité en conformité

avec ISO 27002.
La colonne J donne le pourcentage cible visé pour la période.
 Les Diagrammes de Kiviat
72
Les rosaces permettront de données des courbes pour chaque domaine visé.
Portrait actuel : indique l’état de la sécurité au moment de la compilation des

données.
Portrait cible : indique en rouge l’état actuel de la sécurité plus, en vert la cible
que désire atteindre l’organisme.
L’outil AUDITSec et son guide d’utilisation sont disponibles à l’adresse suivante :

http://www.mag-securs.com/News/tabid/62/id/28502/Un-outil-pour-audit-ISO-
27002.aspx
IV.2.3 AUDIT NIVEAU 2 : AUDIT TECHNIQUE

Il s’agit de procéder à une analyse très fine sur le plan logique des infrastructures
sécuritaires du système d’information de l’entreprise à auditer. On évaluera les
éléments suivants au travers d’outils et référentiels d’audit (fiches techniques):
ordinateurs, onduleurs, routeurs, IPS, HIDS, NIDS, Switch, pare-feu, imprimantes,
copieurs, etc.
A. Objectifs
La phase d’audit technique vient en seconde position après celle de l’audit

Organisationnel et physique. Elle est réalisé suivant une succession de phase
respectant une approche méthodique allant de la découverte et la reconnaissance du
réseau audité jusqu’au sondage des services réseaux actifs et vulnérables.
Cette analyse a pour but de faire apparaître les failles et les risques, les conséquences
d’intrusions ou de manipulations illicites de données, en permettant la détection des
types de vulnérabilités suivantes :
 Les erreurs de programmation et erreurs d’architecture.

 Les erreurs de configurations des composants logiques installés tels que les
services (ports) ouverts sur les machines, la présence de fichiers de
73
configuration installés par défaut, l’utilisation des comptes utilisateurs par

défaut.
 Les problèmes au niveau du trafic réseau (flux ou trafic non répertorié, écoute
réseau,...).
 Les problèmes de configuration des équipements d’interconnexion et de
contrôle d’accès réseau.
Au cours de cette phase, l’auditeur pourra également apprécier l’écart entre les
réponses obtenues lors des entretiens et les réalités du terrain. Il sera à même de tester
la robustesse de la sécurité du système d’information et sa capacité à préserver les
aspects de confidentialité, d’intégrité, de disponibilité et d’autorisation.
Cependant, l’auditeur doit veiller à ce que les tests réalisés ne mettent pas en cause la
continuité de service du système audité.
B. Déroulement
B.1 Environnement
Cet audit s’applique aux environnements suivants :
 Réseau d’accès Internet, réseau d’interconnexion intersites,

 Serveurs internes du site audité et les postes sensibles du LAN (Local Area
Network),
 Systèmes critiques spécifiques,
 Composants et équipements actifs de l’infrastructure réseau du site audité (pare-
feu, routeurs, commutateurs, etc…)
B.2 Principales phases
Phase 1 : Audit de l’architecture du système
 Reconnaissance du réseau et de plan d’adressage,

 Sondage des systèmes et des services réseau,
 Audit des applications.
74
Phase 2 : Analyse des vulnérabilités
 Analyse des vulnérabilités des serveurs en exploitation,

 Analyse des vulnérabilités des postes de travail.
Phase 3 : Audit de l’architecture de sécurité existante
Cette phase couvre entièrement/partiellement la liste ci-après :
 Audit des firewalls et des règles de filtrage,

 Audit des routeurs et des ACLs (Liste de contrôle d’accès),
 Audit des sondes et des passerelles antivirales,
 Audit des stations proxy,
 Audit des serveurs DNS, d’authentification,
 Audit des commutateurs,
 Audit de la politique d’usage de mots de passe.
B.3 Les outils
Compte tenu des objectifs escomptés et de l’environnement lors de cette étape, leurs
aboutissements ne sont possibles que par l’utilisation de différents outils. Chaque outil
commercial qui devra être utilisé, doit bénéficier d’une licence d’utilisation en bonne
et due forme. Egalement les outils disponibles dans le monde du logiciel libre sont
admis.
L’ensemble des outils utilisés doit couvrir entièrement/partiellement la liste non

exhaustive des catégories du tableau suivant :
Catégories Outils open source (contenu

dans Kali linux)
Outils de sondage et de reconnaissance du réseau. Zenmap, nmap …
Outils de test automatique de vulnérabilités du Nikto, Nessus, metasploit …
réseau et de test d’intrusion.
75
Outils spécialisés dans l’audit des équipements Fragroute, Nessus …

réseau (routeurs, switchs).
Outils spécialisés dans l’audit des systèmes Nmap, zenmap, Nessus …
d’exploitation.
Outils d’analyse et d’interception de flux réseaux. Wireshark …
Outils de test de la solidité des objets John, hydra …

d’authentification (fichiers de mots clés).
Outils de test de la solidité des outils de sécurité fragrouter, netmask, intrace,
réseau (firewalls, IDS, outils d’authentification). Nessus …
Tableau 3: Outils d'audit technique
Chacun des outils à utiliser devra faire l’objet d’une présentation de leurs
caractéristiques et fonctionnalités aux responsables de l’organisme audité pour les
rassurer sur l’utilisation de ces outils.
 Kali Linux
Kali Linux est une distribution Linux sortie le 13 mars 2013, basée sur Debian et qui a
pris la succession de Backtrack
L'objectif de Kali Linux est de fournir une distribution regroupant l'ensemble des
outils nécessaires aux tests de sécurité d'un système d'information. Kali est à l’heure
actuelle la distribution la plus aboutie en matière de sécurité informatique. Ce système
se qualifie tant par le nombre impressionnant d’outils que par sa qualité reconnu par
les professionnels. C’est pourquoi, Kali Linux a été élu comme étant la première
distribution de sécurité.
La figure suivante montre l’interface d’accueil de Kali Linux 1.0.4 :
76
Figure 10: interface d’accueil de Kali
Utilisation
Kali Linux comprend environ 300 outils d’audit de sécurité et est disponible sous
forme de live DVD. Il est également possible de l'installer sur un disque dur, sur une
clé USB, ou encore de mettre en place un démarrage PXE. Il est également possible de
construire son propre DVD en utilisant les scripts Debian live-build.
Installation
Cf. annexe 2
Pour plus d’information sur l’utilisation de kali linux, consulter les pages
 Site web officiel : http://www.kali.org/

 Documentation : http://www.kali.org/official-documentation/
B.4 Description des phases
77
B.4.1 Audit de l’architecture du système
Cette étape constitue la première étape dans la phase de l’audit technique car pour
évaluer le niveau de sécurité d’un réseau il faut d’abord le connaître. Elle consiste en
la découverte de différentes architectures (physique et logique) du réseau audité.
1. Reconnaissance du réseau et du plan d’adressage
L'inspection du réseau est un point de départ, lors duquel la topologie, ainsi que les
hôtes et les équipements réseau seront identifiés.
Durant cette étape, il faudra procéder à une inspection du réseau afin de déterminer sa
topologie, d’identifier les hôtes connectés et les équipements réseau. Pour réaliser cette
tâche, il faut commencer par un recueil des données concernant les équipements
inventoriés.
L’outil utilisé pour l'identification de la topologie réseau peut être nmap(ou

zenmap) :
Présentation de Nmap
Nmap (“Network Mapper”) est un outil open source d'exploration réseau et d'audit de
sécurité. Il a été conçu pour rapidement scanner de grands réseaux, mais il fonctionne
aussi très bien sur des cibles plus petites. C’est un outil très efficace qui permet de
scanner les ports, l’exploration réseau et obtenir des informations sur le système
d’exploitation d’un ordinateur distant, ce logiciel est de plus en plus utilise par les
administrateurs réseaux car l’audit des résultats de Nmap fournit des indications bien
précise d’un réseau.
Zenmap est une interface graphique multiplateforme pour nmap... Pour plus
d’information sur son utilisation, consulter la page :
http://nmap.org/book/zenmap.html
Topologie d’un réseau avec zenmap
78
Cet outil a pour objectif d’être à la fois utile pour les utilisateurs avancés et facile à
prendre en main pour les débutants et permet de faire un premier pas dans le monde de
l’audit réseau.
Avec Zenmap il est possible de lancer un scan d’un réseau avec un seul clic de souris!
Zenmap est très facile à prendre en main, il n’a besoin que de 2 paramètres:
 La cible: une adresse IP, une plage IP ou un réseau

 Le profile (type de profil préenregistré pour les options de Nmap) : laisser le
profile sur « intense scan » ou pour aller plus vite choisir le profil « quick
traceroute » pour l’affichage de la topologie du réseau.
Le menu « Topologie » de Zenmap est fort pratique et permet d’avoir visuellement la

topologie du réseau:
79
Pour plus de détail sur la topologie d’un réseau avec zenmap, consulter la page :
http://nmap.org/book/zenmap-topology.html
2. Sondage des systèmes et des services réseaux
L’objectif de cette étape est l’identification des systèmes d’exploitation (des postes
utilisateurs, des serveurs de donnée et d’application en exploitation) et des services
réseau, qui permettra de connaitre les ports ouverts des équipements audités. Il est
également possible d’analyser le trafic, de reconnaître les protocoles et les services
prédominant au niveau du réseau.
Pour réaliser cette étape, il faudra utiliser des outils qui permettent d’identifier les
Systèmes d’exploitation, les services ouverts, les patches manquants et d’autres
informations utiles.
Utilisation de zenmap :
Il suffit d’exécuter un scan par défaut (avec le profil « intensive scan ») en ajoutant
l’option –O pour la détection des OS.
80
Pour plus d’information sur les options de nmap, consulter la page :

http://nmap.org/man/fr/index.html
2.1 Identification des systèmes d’exploitation (OS : operating system)
Cette étape consiste à faire un balayage systématique des ports avec des options de
détection des systèmes d ‘exploitation pour avoir la liste des OS au niveau des stations
de l’ensemble du réseau audité.
Les informations concernant cette partie peuvent être recueillies sur la plateforme de
zenmap à la fin du scan.
2.2 Identification des services réseaux
Il s’agit de déterminer les services offerts par les serveurs et les postes de travail qui
peuvent être une source de vulnérabilité.
zenmap.
2.3 Identification des ports ouverts

Cette partie consiste à recenser tous les ports ouverts sur le réseau présentant des
risques de vulnérabilité.
zenmap.
2.4 Identification des flux réseaux

Cette étape concerne l’analyse du trafic, l’identification des principaux flux, protocoles
et applications, le taux d'utilisation ainsi que les flux inter-stations et les protocoles
superflus qui génèrent des informations gratuites qui pourraient être exploitées par des
personnes malintentionnées pour mener des attaques.
81
L’outil utilisé pour cette étape peut être wireshark :
Présentation de wireshark :
Wireshark est un logiciel d'analyse réseau (sniffer) permettant de visualiser l'ensemble

des données transitant sur la machine qui l'exécute, et d'obtenir des informations
sur les protocoles applicatifs utilisés. Les octets sont capturés en utilisant la librairie
réseau PCAP, puis regroupés en blocs d'informations et analysés par le logiciel.
Analyse réseau avec wireshark
(Voir annexe 3)
2.5 Identification des partages réseaux
L’objectif de cette étape est d’identifier les partages réseaux existant (partages
administratifs et partages cachés par défaut) sur les serveurs et les équipements
critiques, car les partages administratifs par défaut peuvent être exploités par un intrus
pour avoir le contrôle total d’une machine.
Pour afficher les partages administratifs par défaut sur les OS Windows, procéder de la
manière suivante :
 Dans le Panneau de configuration, cliquez sur Systèmes et sécurité > Outils

d'administration > Gestion de l'ordinateur.
 Développez Dossiers partagés, puis cliquez sur Partages.
 Enfin sur chaque dossier suivi du signe « $ » faire un clic droit puis choisir arrêter
le partage.
3. Audit des applications
Cette étape de l’audit technique ne représente pas un audit détaillé des applications.
Toutefois, il s’agit de déceler certaines anomalies au niveau opérationnelle des
applications critiques (le plus souvent les applications web) au sein de
l’environnement du travail du système audité.
82
Les outils les plus utilisés pour ce genre de tache sont : Burpsuite, Webscarab, nikto …
B.4.2 Analyse des vulnérabilités
L’analyse des vulnérabilités consiste à utiliser des outils de recherche de vulnérabilités

qui testent la résistance du système face aux failles connues stockées dans leurs bases
de connaissance. Cette phase est très importante car elle sert d’entrée pour la phase de
test d’intrusion.
Pour mener à bien cette phase, nous utiliserons le logiciel Nessus :
Description de Nessus
Nessus est un outil multiplateforme, scanner de vulnérabilité conçu pour les

administrateurs de réseau qui vous permet d'inspecter, sans dépendre d'un des
systèmes d'exploitation utilisés sur les machines (serveurs, postes utilisateurs), toutes
les failles de sécurité qui pourraient survenir sur un réseau. Ceci inclut entre autre :
 les services vulnérables à des attaques permettant la prise de contrôle de la

machine, l'accès à des informations sensibles (lecture de fichiers confidentiels
par exemple), des dénis de service...
 les fautes de configuration (relais de messagerie ouvert par exemple)
 les patchs de sécurité non appliqués, que les failles corrigées soient
exploitables ou non dans la configuration testée
 les mots de passe par défaut, quelques mots de passe communs, et l'absence de
mots de passe sur certains comptes systèmes. Nessus peut aussi appeler le
programme externe Hydra pour tester la force des mots de passe à l'aide d'un
dictionnaire.
 les services jugés faibles (on suggère par exemple de remplacer Telnet par
SSH)
 les dénis de service contre la pile TCP/IP
Il accomplit cette tâche en détectant la présence d'une série de vulnérabilités déjà

connues qui forment l'énorme base de données de plugiciels du programme.
83
L'utilisateur peut définir des politiques de sécurité selon ses besoins et procéder afin de
ne pas affecter le réseau sur lequel il travaille - par exemple, l'analyse des
vulnérabilités d'un système Unix sur un réseau Microsoft Windows.
Nessus est un produit commercial diffusé par la société TENABLE Network Security.
Il peut toutefois être utilisé gratuitement avec une base des vulnérabilités dont la mise
à jour est décalée d'une semaine.
Test de vulnérabilité avec Nessus
(Voir annexe 4)
1. Analyse des vulnérabilités des serveurs en exploitation
Cette analyse devra cibler une liste de serveurs jugés sensible par le client. Cependant,
il est recommandé d’analyser l’ensemble des serveurs du réseau audité. Tout dépend
du périmètre de l’audit et du temps disponible.
2. Analyse des vulnérabilités des postes de travail
Pareil pour les postes utilisateurs, il faudra faire une analyse de tous les postes de
travail du réseau audité ou d’un ensemble de postes jugés sensibles par l’organisme.
B.4.3 Audit de l’architecture de sécurité existante
L’objectif de cette étape est d’expertiser l’architecture technique déployée et de

vérifier les configurations des équipements réseaux avec la politique de sécurité
définie et les règles de l’art en la matière.
Le logiciel NESSUS offre des fonctionnalités de scan de vulnérabilité des équipements

de l’architecture de sécurité déployé sur un réseau (scan des firewalls, scan des
routeurs, scan des commutateurs …).
84
1. Analyse des firewalls et des règles de filtrage
En général, le rôle du firewall consiste à contrôler l’accès au système selon une

politique spécifique adapté. Cette étape consiste à déterminer si le firewall fonctionne
correctement. La démarche adoptée consiste donc à :
 Vérifier la configuration, les failles renfermées par la version installée, les

mises à jour ;
 Vérifier les règles de filtrage (TCP/UDP filtering, Firewalking) ;
 Vérifier les mécanismes de log (Historique des évènements).
 Enfin comparer les paramètres de configurations relevés aux paramètres de
configurations réputés efficaces (en terme de sécurité).
Pour plus d’information sur les audits de firewalls, vous pouvez consulter le
document : Firewall Auditing de Sean K. LOWDER ([email protected]).
2. Analyse des routeurs et des ACLs (Liste de contrôle d’accès)
La démarche adoptée consiste entre autre à :
 Vérifier le type du routeur et sa configuration, ainsi que les failles éventuelle

de version ;
 Vérifier la conformité des ACLs envers la politique de la sécurité du site audité
(Audit des ACLs) ;
 Vérifier la résistance des routeurs contre les attaques DOS (attaque par déni de
service).
 Enfin comparer les paramètres de configurations relevés aux paramètres de
configurations réputés efficaces (en terme de sécurité).
3. Analyse des commutateurs,
La démarche adoptée consiste à :
85
 Réaliser des simulations par des essais d’attaques par des outils d’écoute
réseaux (sniffers) au niveau des différents segments de la configuration en
VLAN ;
 Vérifier de la résistance des commutateurs (switch) contre les attaques expertes
de type MAC Flood et ARP poisoning (Arpspoof) ;
 Réaliser des simulations par des essais d’attaques par des outils d’interception
de flux évolués (interception du contenu des flux HTTP, SMTP, POP).
Pour plus d’indication concernant la réalisation de cette étape, voir : utilisation de

Metasploit dans la partie : Phase de test d’intrusion.
4. Analyse des systèmes de détection d’intrusion
Cette étape consiste surtout à :
 Tester par des scans et méthodes d’attaques diversifiés et des essais de

simulation (par flood, fausses attaques simultanées, fragmentation, scans lents)
afin de déduire les possibilités de l’IDS à détecter les attaques ;
 Vérifier les mécanismes de journalisation (log) de la Sonde ;
 Vérifier les performances de la sonde
5. Analyse de la politique d’usage de mots de passe
Cette étape consiste à contrôler la résistance des mots de passe utilisés dans le système
d’information (mots de passe utilisateurs, serveurs, administrateurs …)
L’un des logiciels les plus utilisés pour tester la force des mots de passes est Hydra qui
est intégré dans le logiciel NESSUS.
IV.2.4 PHASE DE TESTS D’INTRUSION

Les tests d'intrusion (en anglais penetration tests, en abrégés pen tests) consistent à
éprouver les moyens de protection d'un système d'information en essayant de
s'introduire dans le système en situation réelle grâce aux informations recueillies lors
86
d’une analyse des vulnérabilités du système. Cette phase suit donc la phase d’audit
technique.
A. Objectifs, avantages et limites des tests d’intrusion
Les principes de réalisation des tests d’intrusion présentent, par rapport à d’autres
méthodes de sécurité, des avantages, mais aussi des limites. Il convient donc de bien
mesurer ces insuffisances, et de les mettre en perspective avec les objectifs que l’on
veut atteindre.
A.1 Objectifs pouvant être satisfait par les tests d’intrusion : avantages
Mettre à l’épreuve la sécurité d’un système et confirmer sa résistance à un

certain niveau d’attaque
Les tests d’intrusion peuvent en effet être comparés à certaines méthodes de

qualification du monde industriel (résistance de coffre-fort, endurance des moteurs
d’avions) où l’on vérifie que le mécanisme testé résiste pendant un certain temps à des
attaques ou des agressions d’un niveau défini. Dans le cas des tests d’intrusion, le
résultat se réduit à savoir si le système testé a résisté aux attaques pendant le temps
imparti (varie de un à plusieurs jours). Si tel est le cas, alors on peut supposer que la
plupart des attaques n’iront pas aussi loin.
Cette attaque a l’avantage de permettre de tirer des enseignements d’un test qui
échoue, c’est-à-dire pour lesquels aucune intrusion n’a pu être réalisée dans le laps de
temps imparti. On peut donc supposer que la sécurité existante est adaptée au niveau
de risque accepté. Il convient de définir très précisément, avant le test, la durée du test
et ce qui sera considéré comme une intrusion afin de pouvoir tirer précisément des
enseignements en matière de résistance à l’intrusion.
Sensibiliser les acteurs du système d’information (management, informaticiens,

utilisateurs…)
Les tests d’intrusions sont particulièrement efficaces pour sensibiliser les acteurs. En
effet, par rapport à des méthodes d’analyse de la sécurité un audit technique par
87
exemple, le test d’intrusion, s’il « réussit » permet de disposer d’arguments de poids

pour inciter les acteurs à prendre conscience des risques. Il peut même être envisagé de
récolter des « preuves » pour convaincre les plus récalcitrants. Les tests d’intrusion
permettent également d’illustrer les problèmes de sécurité issus d’interactions
complexes et non prévues, interactions qui sont parfois difficiles à appréhender lors
d’audits de sécurité se focalisant sur des points de contrôle « atomiques ».
Toutefois, il faut considérer le risque que les d’intrusion n’aboutissent pas à des
résultats concluants. Dans ce cas-là, le pouvoir de sensibilisation des acteurs devient
inexistant. Au contraire, certains peuvent croire, à la robustesse du système.
A.2 Objectifs ne pouvant être satisfaits par des tests d’intrusion : Limites
L’assurance qu’un système informatique est sécurisé
Un test d’intrusion ne peut constituer la preuve de la sécurité d’un environnement. Si

aucune vulnérabilité significative n’est mise en évidence lors des tests, il est
impossible de prétendre que le système audité est sécurisé. En effet, on ne peut exclure
que les testeurs n’aient pas identifié certaines vulnérabilités existantes, par manque de
connaissance ou de moyens, ou parce que ces vulnérabilités ne peuvent pas être mises
en évidence directement dans les conditions des tests d’intrusion. On ne peut pas non
plus exclure que, dans le future, des vulnérabilités apparaissent au sein des briques
logicielles constituants l’environnement ou que son paramétrage de sécurité soit
modifié.
Pour obtenir un niveau d’assurance suffisant sur la sécurité d’un environnement

informatique, il est plus légitime de réaliser un audit de sécurité, qui prend notamment
en compte les aspects procéduraux et organisationnels, en plus des questions
techniques.
88
Identifier exhaustivement les vulnérabilités de sécurité d’un environnement.
Comme les autres méthodes, un test d’intrusion ne permet pas d’être certain que
toutes les vulnérabilités existantes au sein d’un SI seront identifiées. Une fois une
vulnérabilité identifiée sur un système et utilisée pour en prendre le contrôle, une
personne réalisant un test d’intrusion aura tendance à s’occuper d’un autre système,
sans tenter d’identifier d’autres vulnérabilités sur le système dont elle vient de prendre
le contrôle. Or il est tout à fait possible que plusieurs vulnérabilités de sécurité
existent sur ce système. Par ailleurs, un test d’intrusion ne permet en général pas de
détecter d’éventuelles vulnérabilités dans les couches de protections au-delà de la
première couche présentant un niveau de sécurité suffisant.
B. Types de test d’intrusion
On distingue généralement deux méthodes de test d’intrusion distinctes :
 La méthode dite « boîte noire » (en anglais « black box ») encore appelé test
intrusif externe : consiste à essayer d'infiltrer le réseau sans aucune
connaissance du système, le plus souvent à travers le réseau internet ;
 La méthode dite « boîte blanche » (en anglais « white box »), aussi appelé test
intrusif interne : consiste à tenter de s'introduire dans le système en ayant
connaissance de l'ensemble du système, afin d'éprouver au maximum la
sécurité du réseau.
B.1 Test intrusif externe
B.1.1 Déroulement
L’objectif d’une telle mission est d’évaluer le risque qu’une personne malveillante
puisse s’introduire dans le réseau informatique interne de l’entreprise audité via son
réseau d’interconnexion à internet.
89
Il est très souvent recommandé qu’une mission de ce genre soit réalisée par une société
de service proposant ce type de prestation. Cependant, elle peut aussi être initiée et
réalisée par le propriétaire ou le responsable légal de la structure concernée par ce test
d’intrusion, par exemple dans le cas où l’entreprise aurait externalisé ses serveurs. Dès
lors, l’entreprise, le prestataire de service et l’éventuel hébergeur doivent analyser avec
une attention particulière, le contexte organisationnel autour du SI objet du contrat des
tests d’intrusion ; en particulier, les engagements doivent correspondre au périmètre
réel de responsabilité des acteurs engagés.
Ce type de mission peut débuter sans informations préalable provenant du demandeur

(responsable du site audité ou responsable de l’audit). De manière générale, le
déroulement d’une mission de test d’intrusion de type « boite noire » depuis internet
comporte trois phases principales :
Phase 1 : Découvertes initiales
L’objectif de cette phase est de rechercher des informations significatives permettant

de découvrir puis de valider le périmètre de l’intrusion.
Dans un premier temps, le prestataire s’attache à cerner la connectivité internet du

demandeur. Afin de mener à bien cette recherche, il consulte diverses bases de
données publiques sur internet (notamment les enregistrements Whois) pour identifier
les plans de nommage, d’adressage et le ou les fournisseurs d’accès utilisé par
l’entreprise. Il vérifie par ailleurs l’appartenance des adresses IP concernées par les
tests d’intrusion. Il complète sa recherche via de nombreuses sources de données
publiques, site Web du demandeur, les forums, les serveurs de news, etc. Ces
informations fournissent éventuellement des informations complémentaires sur les
éléments réseaux et logiciels qui sont détenus par l’entreprise.
Le résultat de cette phase permet d’identifier la présence de l’entreprise perçue depuis

le réseau Internet. Il est recommandé de faire valider ces informations par le
demandeur afin de poursuivre cette phase d’exploration. Cette validation, permet
d’engager le demandeur (face au contrat) et d’informer le prestataire qui est ainsi
90
certain que les éléments qu’il va tester par la suite sont bien des éléments appartenant
au demandeur et sont bien inclus dans la couverture du contrat.
Puis le prestataire passe à l’identification de la topologie du réseau de l’entreprise vue

depuis internet. Pour cela, il identifie les machines accessibles à partir d’internet à
l’aide d’outils faiblement intrusifs (type DNS et reverse DNS, transfert de zone,
traceroute, ping, etc.). Ensuite il détermine les caractéristiques et les rôles de ces
machines afin de comprendre la topologie du réseau et des éléments cibles qui sont
identifiables depuis Internet. Il aura ainsi une représentation graphique de cette
topologie du réseau et des éléments cibles qui sont identifiables depuis internet.
A la fin de cette phase, il est recommandé que le prestataire communique au

demandeur les résultats de sa découverte du réseau (schéma de la topologie du réseau
vu depuis le réseau internet). Le demandeur valide ensuite le périmètre à couvrir par le
prestataire en phase 2.
Phase 2 : Recherche d’informations et de vulnérabilités
L’objectif de cette phase est de rechercher des vulnérabilités potentielles sur les
machines identifiées dans le périmètre de la phase 1.
Pour chacune des machines présentes dans le périmètre de raccordement à internet, le

prestataire complète sa recherche par des techniques plus intrusives qui permettent
d’identifier l’ensemble des services actifs sur ces éléments, d’analyser les
configurations des éléments, etc.
Le résultat de cette recherche permet de mettre en évidence un certain nombre de

vulnérabilités potentielles qui pourraient exister sur les machines cibles et qui
pourraient être exploitées pour s’y introduire : version ou correctif non à jour,
configuration incomplète, etc.
Etape de validation : lorsque le prestataire découvre une vulnérabilité majeure pouvant

porter atteinte à la disponibilité ou à l’intégrité des données de l’entreprise, il est
91
recommandé qu’il en fasse part à celle-ci. Sans un accord formel de cette dernière, le
prestataire ne doit pas exploiter ce type de vulnérabilité.
Phase 3 : Exploitation des vulnérabilités et intrusion
L’objectif de cette phase est d’exploiter les vulnérabilités identifiées lors de la phase 2,
dans le but de s’introduire sur les machines de l’entreprise à partir de l’accès internet.
Cette phase est la plus technique. En effet, le prestataire teste et tente d’exploiter les
vulnérabilités mise en évidence lors de la phase précédente. Dans le cas d’une
intrusion logique sur un serveur. Il doit prouver l’intrusion, soit :
 En fournissant au demandeur des informations confidentielles sur le système

d’information, en accord avec les objectifs et les obligations contractuelles.
 En démontrant qu’il a pu écrire ou modifier des données, par le dépôt d’un
fichier particulier par exemple.
Cette phase n’aboutit pas automatiquement à la prise de contrôle total d’un ou de

plusieurs éléments du SI. En effet le prestataire pet simplement obtenir des
privilèges lui permettant de rebondir et de poursuivre l’intrusion vers le réseau
interne – à condition de ne pas sortir du périmètre défini contractuellement – en
reproduisant le schéma utilisé depuis internet : processus d’analyse du nouvel
environnement, d’énumération puis d’exploitation des vulnérabilités, etc.
Remarque :
Cette phase peut également être simulée à l’aide d’outils spécialisés permettant
d’effectuer des tests d’intrusions sur un environnement informatique depuis le réseau
internet : la version payante du logiciel NESSUS est l’un des meilleurs dans le
domaine.
B.1.2 Mesures à prendre du côté du demandeur
92
Il est recommandé que le demandeur prenne en compte certaines pratiques qui

permettent de s’assurer de la meilleure adéquation des résultats de la mission avec les
objectifs de l’entreprise. Ces mesures ont notamment pour objectifs :
 D’analyser l’expérience professionnelle du prestataire.

 De s’assurer de la qualité du déroulement et du résultat de la prestation.
 D’obtenir une bonne intégration des résultats avec les objectifs de l’entreprise.
Exemples de mesures à prendre avant de lancer une mission de ce type :
 Définir l’objectif et les conditions de validation de l’objectif.

 Nommer un unique coordinateur interne et un coordinateur chez le prestataire
pour assurer la relation entre l’organisme audité et le prestataire. Ces
coordinateurs peuvent être accompagnés par des personnes de différentes
compétences techniques afin de s’assurer du bon déroulement de la mission.
 Informer les acteurs internes de l’entreprise que des tests d’intrusion sont
parfois réalisés au cours de l’année.
 Exiger un contrat signé entre les prestataires et les éventuels hébergeurs
concernés par les tests, en incluant éventuellement la couverture des risques par
une société d’assurance.
Exemples de mesures à prendre pour s’assurer de la compétence professionnelle

du prestataire :
 Demander si le prestataire possède un Code d’Ethique formalisé et respecté.

 Demander la typologie des attaques qui seront réalisées et la liste des outils
potentiellement utilisés.
 Demander une liste de références de mission précédentes dans le domaine des
tests d’intrusion.
 Demander le CV des intervenants ainsi que leur rôle dans la mission et le temps
qu’ils y passeront.
93
 Demander les moyens dont dispose le prestataire. Par exemple dans le cas d’un
laboratoire de test d’intrusion, visiter éventuellement ce laboratoire.
Exemples de mesures à prendre pour cadrer la mission :
 Définir les moyens auxquels le prestataire peut recourir.

 Définir une date de début et de fin de prestation.
 Définir les étapes intermédiaires de validation des différentes phases de la
prestation afin de bien maitriser le déroulement de la prestation.
 Préciser le respect de certaines dates et plages horaires lors des actions du
prestataire suivant la charge de certaines ressources du SI.
 Assurer la traçabilité (journalisation) des actions du prestataire en s’assurant
que le prestataire fournira des renseignements horodatés de l’ensemble des
actions qu’il a menées.
Exemples de mesures à prendre pour préciser la rédaction du rapport :
 Définir le contenu du rapport : par exemple la synthèse doit être

compréhensible par la Direction Générale, les descriptions techniques sont
reportés en annexe, le corps du rapport doit appeler l’ensemble des
vulnérabilités classées par niveau de risque, etc.
 Définir le niveau de granularité de description du test en précisant notamment la
méthode utilisée, le résultat obtenu, les risques éventuels et les
recommandations à apporter.
 Exiger une qualité de rédaction en français (ou en anglais) si la diffusion du
rapport final concerne des personnes non techniques.
Exemples de mesures à prendre pour valoriser les résultats de la mission :
 Les rapports de pré – validation et final doivent être classifiés « confidentiel ».

 Définir et formaliser au sein du rapport final, la liste des destinataires du
rapport.
94
 Demander au prestataire de fournir un tableau de bord des résultats des tests si

ces tests couvrent de nombreux points d’accès dans le SI.
 Analyser les conclusions du rapport et réévaluer les risques en fonction des
risques réels de l’entreprise : par exemple pour déclarer qu’un accès à des
données doit être classé critique pour l’entreprise il faut par avance avoir réalisé
une classification des données accédées et avoir défini un propriétaire des
données afin de l’avertir.
Pour plus de détails concernant cette partie (test intrusif externe), ce référer au
document : Test d’intrusion, mars 2004, du CLUSIF disponible en téléchargement
gratuit sur la page suivante : https://www.clusif.asso.fr/fr/production/documents.
B.2 Test intrusif interne
B.2.1 Déroulement
Cette mission peut être réalisée par l’équipe qui réalise l’audit de sécurité du SI. Une
telle démarche doit nécessairement être réalisée avec l'accord (par écrit de préférence)
du responsable de l'entreprise, dans la mesure où elle peut aboutir à des dégâts
éventuels et étant donné que les méthodes mises en œuvre sont interdites par la loi en
l'absence de l'autorisation du propriétaire du système. Un test d'intrusion interne,
lorsqu'il met en évidence une faille, est un bon moyen de sensibiliser les acteurs d'un
projet. Cette phase de l’audit reste donc très importante. En effet, elle permet de faire
prendre conscience aux responsables de la gravité de leurs vulnérabilités, face aux
attaques d’un esprit malveillant interne à l’organisme. Elle permet également de
donner un aperçu de l’ampleur des conséquences néfastes qui pourraient advenir dans
le cas où un esprit malveillant venait à exploiter leurs vulnérabilités.
Pour l’accomplissement de cette étape, il s’agira pour l’auditeur de jouer le rôle de

l’attaquant étant à l’intérieur de l’organisme. Puis il devra se baser sur un ensemble
d’outils, en l’occurrence une plateforme d’attaque, les résultats de Nessus et zenmap,
des exploits et des payload afin de mener à bien chaque attaque.
L’une des plateformes d’attaque la plus utilisé est : Metasploit (ou Armitage).
95
B.2.2 Utilisation de Metasploit avec Armitage
Description
Metasploit est une plateforme d'attaque, open source, basée sur l'utilisation d'exploits
afin d’exécuter un code arbitraire sur un hôte distant. Chaque exploit est composé de
payload. Ces derniers sont les codes qui sont exécutés pour permettre le succès de
l’exploit. Le lancement d’une attaque à partir de Metasploit s’effectue en choisissant
l’exploit, le payload puis la cible de l’attaque.
Armitage est une interface graphique pour Metasploit, développée en Java (donc
multiplateforme) qui permet de visualiser les équipements cibles, les exploits
recommandés et les fonctionnalités avancées du Framework Metasploit.
Test d’intrusion avec Armitage :
(Voir annexe 5)
IV.2.5 PHASE DE SYSNTHESE ET RECOMMANDATIONS

(LE RAPPORT D’AUDIT)
Elle commence à la fin des précédentes phases d’audit et l’auditeur est invité à rédiger
un rapport de synthèse sur sa mission d’audit. Cette synthèse doit être révélatrice des
défaillances décelées (classées par ordre de niveaux de gravité d’impact de
préférence). Autant est-il important de déceler un mal, autant il est également
important d’y proposer des solutions. Ainsi, l’auditeur est également invité à proposer
des solutions (recommandations), détaillées, pour pallier aux défauts qu’il aura
constatés.
96
A. Analyse et évaluation des risques (cf. MEHARI)
Après avoir identifié toutes les failles de sécurité organisationnelles, physiques et

techniques, il s’agit de suivre une approche méthodologique pour évaluer les risques
encourus et leurs impacts sur la sécurité de la structure auditée.
Cette phase de l’audit peut être réalisée après chaque niveau important de l’audit,
c’est-à-dire à la fin de l’audit organisationnel et physique, puis à la fin de l’audit
technique et du test d’intrusion. Toutefois il est fortement recommandé de faire une
dernière analyse et évaluation globale des risques à la fin de toutes les investigations (à
la fin de la mission d’audit).
B. Le rapport d’audit
B.1 Objectifs
L’objectif principal d’un rapport d’audit est de fournir des recommandations détaillées
sur le plan organisationnel et physique ainsi que sur le plan technique de l’audit. De ce
fait, ces recommandations devront inclure au minimum :
 Une étude de la situation existante en termes de sécurité au niveau du site

audité, qui tiendra compte de l’audit organisationnel et physique, ainsi que des
éventuelles vulnérabilités de gestion des composantes du système (réseau,
systèmes, applications, outils de sécurité) et les recommandations
correspondantes ;
 Les actions détaillées (organisationnelles et techniques) urgentes à mettre en
œuvre dans l’immédiat, pour parer aux défaillances les plus graves, ainsi que la
proposition de la mise à jour ou de l’élaboration de la politique de sécurité à
instaurer.
97
B.2 Recommandations : Comment rédiger un rapport en 5 points ?
Le rapport d’audit va finaliser votre mission d’audit. Il s’agit de faire un travail de

synthèse de l’ensemble des informations que vous avez collectées (prise de notes)
durant la mission.
1er – Recenser l’ensemble des points forts de la SSI
En balayant l’ensemble de vos notes, vous allez très rapidement faire la liste de tous
les points forts que vous avez identifiés pendant les entretiens avec les audités et les
investigations menées.
Par rapport aux objectifs de la mission et de ce que vous avez vécu, faites toutefois un
tri dans les points forts afin de ne conserver que ceux qui permettront de valoriser les
bonnes pratiques de l’organisation. Regroupez-les par étapes et par thèmes :
 Audit organisationnel et physique : politique de sécurité, organisation de la

sécurité …
 Audit technique : Sondage des services réseaux, analyse des services
vulnérables …
 Audit intrusif : interne, externe …
Ils représentent les « bonnes pratiques » de l’organisation. Cela valorise directement

l’implication du personnel dans l’amélioration continue de la performance de
l’entreprise. Il est important de rappeler que l’entreprise puisse maintenir ces points
forts dans le temps. Ils constituent les verrous de l’organisation.
Comment formuler un point fort ?
Ecrivez le point fort sous la forme d’une affirmation appuyée par des faits constatés,
comme par exemple :
 Sécurité physique et environnementale : La zone sensible qu’est la salle serveur

bénéficie d’une sécurité toute particulière, et ce à travers l’accès qui y est très
réservé. En effet pour protéger cette salle de toutes malveillances physiques,
98
l’accès est protégé par une clé que seulement trois personnes possèdent. Elles
sont les seules habilitées à y pénétrer.
2e – Recenser l’ensemble des points faibles de la SSI
Les points faibles sont des risques que vous avez identifiés et qui pourraient devenir de
futures non conformités si l’entreprise n’entreprend pas d’actions préventives pour
éliminer les causes potentielles. Regroupez-les par étape puis par ordre de niveau de
gravité d’impact
Les points faibles seront revus automatiquement lors du prochain audit afin de
s’assurer de leur prise en compte effective.
Comment formuler un point faible ?
Utilisez tout simplement la formulation « attention » en complétant avec les faits

pouvant apparaître, si le risque se présente en réalité, comme par exemple :
 Attention à ne pas oublier de soumettre le personnel à des séances de

formations pour les sensibiliser sur l’importance de la sécurité de l’information
et leur inculquer les notions de bonnes exploitations des technologies de
l’information.
3e – Recenser l’ensemble des non-conformités
Une non-conformité est un écart par rapport à une exigence. Cette dernière pourra être
une exigence d’une norme (exemple : ISO/CEI 27002), une exigence interne à
l’entreprise ou une exigence légale / réglementaire.
Toute non-conformité nécessite une action corrective de la part de l’entreprise. Une

action corrective est une méthodologie s’appuyant nécessairement sur la recherche de
causes. Les actions mises en œuvre et mesurées en termes d’efficacité, seront à valider
par l’auditeur.
Comment formuler une non-conformité ?
99
Ecrire une non-conformité demande à décrire les faits constatés : Qui? Quoi? Où?
Quand? Comment? Combien?
Attention à ne pas faire de jugement de valeur. Vous devez absolument écrire que des
faits afin que la situation de non-conformité soit non contestable.
Il faut ensuite rattacher les faits à une exigence, comme vu précédemment : exigence
d’une norme, exigence interne ou exigence légale / réglementaire. Si vous n’arrivez
pas à associer une exigence, c’est que vous n’êtes aucunement face à une non-
conformité !
Vous avez peut être mis en évidence un point faible ou une opportunité d’amélioration.
Dans les deux cas, revoyez sa formulation.
Si vous avez pu rattacher vos faits à une exigence, vous avez bien mis en évidence une
non-conformité.
4e – Recenser l’ensemble des recommandations
En balayant l’ensemble de vos notes, vous allez très rapidement faire la liste de toutes
les recommandations que vous avez identifiées pendant la mission. Regroupez-les par
étape et par thème.
Comment formuler une recommandation ?
Commencez avec un « verbe à l’infinitif + recommandation» complété éventuellement

avec les gains qualitatifs, comme par exemples :
 Fermer les ports non utiliser car ils peuvent être exploités à tout moment par les
attaquants comme porte d'entrée dans le système.
Le verbe à l’infinitif traduit une action à faire.
5e – Faire une conclusion de votre rapport d’audit
S’il fallait retenir qu’un seul point fort, retenez-en en rapport avec :
100
 Les performances qualitatives obtenues

 Le pilotage de l’activité
 La capacité d’amélioration
Rappelez les enjeux liés aux points faibles et aux non conformités :
Mettre en place les actions correctives et préventives permettant d’éliminer la cause

première de la non-conformité.
Traiter une non-conformité, un point faible (risque de non-conformité) ou une

recommandation sont trois manières différentes de faire progresser l’organisation. Peu
importe le vocabulaire, le tout est de faire avancer les choses!
En conclusion
Le rapport d’audit est une photographie d’un processus, d’une activité ou de tout le
système de management.
Il n’existe pas de rapport « type », le fait de ne pas suivre ces instructions ne vous
empêche pas de produire un rapport de qualité.
L’essentiel est que la qualité de votre rapport, au sens valeur ajoutée apportée à vos «
clients », doit permettre aux audités d’améliorer leur organisation.
Cette qualité de rapport est le résultat de votre processus d’audit, qui s’appuie sur :
 Le choix ou la préparation d’un guide d’audit

 La pertinence de vos entretiens (les bonnes questions à poser) et de vos
investigations.
 La technique utilisée pour les prises de notes
La recette d’un bon rapport d’audit est bien d’avoir suffisamment de « matière » à
exploiter, sachant que la technique de prise de notes vous facilitera le travail de
collecte des informations utiles à votre travail de synthèse.
101
IV.2.6 LA PHASE D’ACCOMPAGNEMENT POST-AUDIT

A. Objectifs
Cet accompagnement est réalisé par l’auditeur et consiste à offrir optionnellement à la

structure auditée, les ressources pour l’accompagner durant les trois (03) mois suivant
l’audit. L’étendue de l’accompagnement peut inclure l’examen de l’efficacité des
premières mesures urgentes mises en œuvre et toute autre action jugée utile par
l’auditeur.
B. Déroulement
Lors de cette phase, l’auditeur pourrait proposer au responsable du site audité, une
série d’actions utiles à exécuter pendant o3 mois dans le but d’optimiser la sécurité du
système d’information. Cette série d’actions peut être représenté sur un tableau de la
manière suivante :
 Indications : Cocher pour remplir le tableau :
Actions 1er mois 2e mois 3e mois

Mettre en œuvre un
système de
management de la
sécurité de
l’information
Elaborer et mettre
en œuvre une
politique de
sécurité suivant la
norme ISO/CEI
27000
Mettre en place un
102
système de
prévention et de
détection
d’intrusion
Création de comité
de sécurité du
Système
d’information
Organiser les
sessions de
sensibilisation du
personnel visant la
nécessité de la
sécurité du système
et les mesures de
protection
Maintenir tous les
logiciels clés du
système
d’information
(serveurs
d’application,
serveurs web,
serveurs de base de
données …) à jour
Installer des
caméras de
103
surveillance pour
protéger les locaux
sensibles du site
Tableau 4: tableau d’accompagnement post audit
104
Annexes
Annexe 1 : Questionnaire d’audit
Numéro Question/contrôle Cote Coef Commentaires

5 Politique de Sécurité
5.1 Politique de sécurité de l’information
5.1.1 Existe-t-il un document décrivant la E1
politique de sécurité des systèmes
d'information et, en particulier, les principes
d'organisation, de gestion et de pilotage de
la sécurité (rôles et responsabilités) ainsi
que les principes fondamentaux structurant
le management de la sécurité de
l'information ?
5.1.2 Cette politique de sécurité est-elle revue à E2
intervalles réguliers ou lors de changements
significatifs, afin d'assurer le maintien de sa
pertinence et de son efficacité ?
6 Organisation de la sécurité de
l’information
6.1 Organisation interne
6.1.1 Le management de l'entreprise est-il E2
impliqué dans l'organisation de la sécurité
de l'information et, en particulier dans
l'élaboration et l'approbation de la politique
de sécurité, la définition des responsabilités,
l'allocation de ressources et le contrôle de
l'efficacité des mesures prises ?
6.1.2 A-t-on défini dans le détail la structure et E2
105
l'organisation de la gestion de la sécurité :

RSSI et correspondants ou responsables
locaux… et cette structure est-elle
opérationnelle ?
6.1.3 A-t-on clairement défini les rôles respectifs E2
des responsables de la sécurité, des
responsables opérationnels et des
responsables fonctionnels de domaines
(propriétaires ou détenteurs d'information)
dans la prise de décision finale, ainsi que les
processus d’arbitrage ?
6.1.4 A-t-on défini et mis en place des moyens de E2
contrôle relatifs à l'usage des moyens de
traitement de l’information ? (paramétrages
spécifiques des systèmes d'exploitation,
systèmes de filtrage, contrôle des accès aux
équipements, etc...)
6.1.5 Existe-t-il, dans les contrats (avec le E2
personnel, les stagiaires, intérimaires,
prestataires …) ou dans le règlement
intérieur, une clause précisant l'obligation
de respecter l'ensemble des règles de
sécurité en vigueur ?
6.1.6 Maintient-on des contacts avec les autorités E2
pouvant être concernées par la sécurité de
l'information et les situations de crise
(Police, Services de renseignements,
Administration judiciaire, Pompiers,
Services publics, etc....) ?
106
6.1.7 Assure-t-on une veille technologique en E2

matière de sécurité (participation à des
cercles, associations, congrès...) ?
6.1.8 Existe-t-il une procédure de mise à jour des R1
notes d'organisation relatives à la sécurité
des systèmes d'information en fonction des
évolutions de structures ou à intervalles
planifiés ?
6.2 Tiers
6.2.1 A-t-on analysé les risques liés aux accès de E2
personnel tiers (prestataires …) au système
d'information ou aux locaux contenant de
l'information et défini en conséquence les
mesures de sécurité nécessaires ?
6.2.2 A-t-on analysé les risques liés aux accès des E2
clients ou du public au système
d'information (ou à une partie du système
d'information) ou aux locaux contenant de
l'information et défini en conséquences les
mesures de sécurité nécessaires ?
6.2.3 A-t-on défini l'ensemble des clauses de E2
sécurité que devrait comprendre tout accord
signé avec un tiers impliquant un accès au
système d'information ou aux locaux
contenant de l'information ?
Le système d'information incluant les divers
supports d'information ou moyens de
traitement, transport et communication de
l'information.
107
7 Gestion des biens

7.1 Responsabilités relatives aux biens
7.1.1 A-t-on défini les types de bien (actif) devant E2
être identifiés et inventoriés ?
Les actifs peuvent être des informations
(bases de données, fichiers, contrats et
accords, documentation, manuels,
procédures, plans, archives, etc.), des
logiciels (applications, firmware,
middleware, outils et utilitaires, etc.), des
équipements matériels (ordinateurs,
équipements de réseau, media, etc.), des
services et servitudes (énergie, chauffage,
climatisation, etc.), des personnes ou du
savoir-faire, des actifs intangibles tels que
la réputation ou l'image.
7.1.2 A-t-on désigné pour chaque actif identifié et E2
inventorié un "propriétaire" de cet actif ?
Un propriétaire est la personne ou l'entité
désignée pour assumer la responsabilité du
développement, de la maintenance, de
l'exploitation, de l'utilisation et de la
sécurité de cet actif. Le terme de
propriétaire ne signifie pas que la personne
ou l'entité détient un droit de propriété sur
cet actif.
7.1.3 A-t-on défini et documenté, pour chaque E2
actif, les règles d'utilisation acceptables ?
108
Ceci implique, en particulier, de définir

l'usage privé qu'un collaborateur peut faire
d'un actif de l'entreprise.
7.2 Classification des informations
7.2.1 A-t-on effectué une classification des E2
informations (documents, données, fichiers,
bases de données, etc.) en fonction de
l'impact
qu'un sinistre touchant ces informations
aurait sur l'entreprise ?
7.2.2 Ce schéma de classification définit-il le E2
marquage des différents types de ressources
en fonction de leur classification ?
8 Sécurité liée aux ressources humaines

8.1 Avant le recrutement
8.1.1 Y a-t-il une procédure d'information E2
préliminaire auprès du personnel (interne ou
contracté), en ce qui concerne ses devoirs et
responsabilités et les exigences de sécurité
de la fonction, avant tout changement
d'affectation ou embauche ?
8.1.2 Y a-t-il un recueil d'informations à E2
l'embauche de personnel pouvant être
amené à travailler sur des tâches sensibles ?
8.1.3 Une note précisant les devoirs et E2
responsabilités du personnel, a-t-elle été
diffusée à l'ensemble des collaborateurs (y
compris les intérimaires, stagiaires, etc.) de
109
telle sorte qu'ils ne puissent nier en avoir eu

connaissance ?
8.2 Pendant la durée du contrat
8.2.1 Le management a-t-il la responsabilité de E2
s'assurer que le personnel, le personnel sous
contrat ou les tiers respectent les politiques
et procédures de sécurité de l'organisation ?
8.2.2 Existe-t-il un programme de sensibilisation E2
du personnel aux risques d'accident, d'erreur
et de malveillance relatifs au traitement
de l'information ?
8.2.3 Le processus disciplinaire en cas de E3
manquement aux règles de sécurité ou de
violation de procédure est-il formalisé ?
8.3 Fin ou modification de contrat
8.3.1 Les devoirs et responsabilités du E2
management lors de la cessation ou d'un
changement d'activité d'un collaborateur
(interne ou sous contrat) sont-ils définis et
précisés dans une procédure ou document
communiqué à l'ensemble des managers ?
8.3.2 Les règles concernant le retour à l'entreprise E2
ou à l'organisation des biens confiés au
personnel, lors de cessation ou de
changement d'activité, sont-elles clairement
définies et précisées au management ?
8.3.3 Existe – il une procédure (ou le document E2
équivalent) couvrant la remise en cause et la
suppression de tous les droits d'accès aux
110
diverses parties du système d'information ?
9 Sécurité physique et environnementale

9.1 Zones sécurisées
9.1.1 Le site est-il complètement clos par une E1
enceinte difficile à franchir ?
S'il s'agit d'un immeuble sur la voie
publique, pour être considéré comme clos,
toutes les fenêtres du rez-de-chaussée
doivent être bloquées fermées et toutes les
voies d'accès doivent être prises en compte
(garages ou sous-sols, toiture, etc.).
9.1.2 Contrôle-t-on de manière globale le E1
mouvement des visiteurs et des prestataires
occasionnels (bon horodaté à l'arrivée et au
départ, signature de la personne visitée,
etc.) ?
9.1.3 L'ensemble des locaux classifiés comme E2
sensibles sont-ils situés tous dans des zones
non accessibles par le public ?
9.1.4 A – t – on mise en place des mesures de E2
protections contre les risque
environnementaux envisageable pour le
site ?
9.1.5 Utilise-t-on un système de contrôle d'accès E2
systématique et/ou de surveillance des
locaux sensibles ?
9.1.6 Des mécanismes spécifiques de contrôle E2
d'accès ont-ils été mis en œuvre pour les
111
zones de livraison/chargement depuis

l’extérieur jusqu’à l’intérieur du site ?
9.2 Sécurité du matériel
9.2.1 Les installations sont-elles faites avec un E2
souci de protection physique ?
Accès protégé, absence de vue directe
externe sur les équipements, absence de
menaces physiques diverses, continuité de
l'alimentation électrique, conditions
climatiques, protection contre la foudre,
protection contre la poussière, etc.
9.2.2 Existe – t – il des mesures mise en places E2
pour la protection des services
généraux ? (qualité et continuité de la
fourniture d’énergie, système de
climatisation, etc.)
9.2.3 Le câblage électrique et de E2
télécommunication est-il protégé contre les
risques courants d’accident ?
(par exemple par la mise en œuvre de
goulottes protégées, encoffrement des
chemins de câble….)
9.2.4 Existe – t – il des procédures de gestion de
la maintenance du matériel ? (contrat de
maintenance, conservation de toutes les
traces de maintenance, etc.)
9.2.5 A-t-on établi une politique de sécurité et des E1
recommandations relatives au travail en
dehors des locaux de l'entreprise ?
112
Les recommandations et directives

devraient traiter des précautions à prendre
aussi bien dans des situations de travail à
domicile, qu'en déplacement ou dans les
transports publics et couvrir la protection
des micro-ordinateurs portables, l'utilisation
pare-feu et de l'antivirus à jour, les
connexions à des réseaux publics ou tiers,
les précautions à prendre concernant les
documents écrits, les messageries
instantanées et les conversations
téléphoniques et orales.
9.2.6 Existe-t-il une procédure de vérification et E3
de suppression des données avant mise au
rebut ou recyclage des supports ?
9.2.7 Existe-t-il des règles concernant la sortie E2
des actifs (autorisations préalables,
personnes autorisées, enregistrement de la
sortie et de la rentrée, effacement des
données inutiles, etc.) ?
10 Gestion de l’exploitation et des

télécommunications
10.1 Procédures et responsabilités liées à
l’exploitation
10.1.1 Les procédures opérationnelles E2
d'exploitation sont-elles documentées et
maintenues à jour ?
10.1.2 Les décisions de changements majeurs des E1
113
équipements et systèmes font-elles l'objet

de procédures de contrôle (enregistrement,
planification, approbation formelle,
communication à l'ensemble des personnes
concernées, etc.) ?
10.1.3 A-t-on défini, au sein de la production E1
informatique, des profils correspondant à
chaque type d'activité (administration
systèmes, administration d'équipement de
sécurité, pilotage de la production,
opérations de gestion de supports et
sauvegardes, etc.) ?
10.1.4 Les environnements de développement et E2
de test sont-ils séparés des environnements
opérationnels ?
10.2 Gestion de la prestation de service par un
tiers
10.2.1 S'assure-t-on que les prestataires ou E2
fournisseurs de services télécoms ont
effectivement prévu les dispositions
nécessaires pour être à même d'assurer les
prestations de services comme convenues
dans l’accord ?
10.2.2 Le respect des clauses de sécurité, par les C1
prestataires ou fournisseurs, fait-il l'objet de
revues régulières ?
10.2.3 Tout changement dans les relations
contractuelles (obligations diverses, niveaux
de service, etc.) fait-il l'objet d'une analyse
114
des
risques potentiels ?
10.3 Planification et acceptation du système
10.3.1 Les décisions de changement s'appuient- E2
elles sur des analyses de la capacité des
nouveaux équipements et systèmes à
assurer la charge requise en fonction des
évolutions des demandes prévisibles ?
10.3.2 Les mesures de sécurité décidées pour E2
remédier aux nouveaux risques mis en
évidence par un nouveau système font-elles
l'objet de contrôles et de test formels avant
mise en exploitation ?
10.4 Protection contre les codes malveillant et
mobile
10.4.1 A-t-on défini une politique afin de lutter
contre les risques d'attaque par des codes
malveillants (virus, chevaux de Troie, vers,
etc.): interdiction d'utiliser des logiciels non
préalablement autorisés, mesures de
protection lors de la récupération de fichiers
via des réseaux externes, revues de logiciels
installés, etc. ?
10.4.2 A-t-on défini une politique et des mesures E2
de protection pour lutter contre des codes
mobiles (applets, contrôles ActiveX,
etc.)non autorisés (blocage ou contrôle de
l'environnement dans lequel ces codes
s'exécutent, contrôle des ressources
115
accessibles par les codes mobiles,

authentification de l'émetteur, etc.) ?
10.5 Sauvegarde
10.5.1 A-t-on établi un plan de sauvegarde, E1
couvrant l'ensemble des configurations du
réseau étendu, définissant les objets à
sauvegarder et la fréquence des sauvegardes
?
10.6 Gestion de la sécurité des réseaux
10.6.1 A-t-on fait une analyse approfondie des E2
événements ou successions d'événements
menés avec des droits d'administration et
pouvant avoir un impact sur la sécurité des
réseaux (configuration des systèmes de
sécurité, accès à des informations sensibles,
utilisation d'outils sensibles, téléchargement
ou modification d'outils d'administration,
etc.) ?
10.6.2 Les niveaux de services ont-ils été identifiés E2
pour chaque service réseau ?
Les niveaux de services comprennent non
seulement le service rendu aux utilisateurs,
mais aussi les dispositifs de sécurité
nécessaires et les obligations des parties
prenantes.
10.7 Manipulation des supports
10.7.1 Les procédures et instructions de sécurité E1
précisent-elles les règles de protection
applicables aux documents et aux supports
116
d'information situés dans les bureaux (quel

que soit la nature du support) ?
10.7.2 Existe-t-il une procédure garantissant, en E2
cas de mise au rebut, la non divulgation des
informations sensibles jusqu'à la destruction
de leur support ?
10.7.3 Existe-t-il un document définissant les E2
règles générales à appliquer en ce qui
concerne la manipulation de l’information
et la prise en compte de la sécurité dans la
gestion des informations ?
10.7.4 Les documents de référence (documents R1
systèmes) sont-ils protégés contre tout accès
indu ou illicite, par des mécanismes forts ?
10.8 Échange des informations
concerne la protection des moyens et
supports de stockage, de traitement et de
transport de l'information (équipements de
réseau et de travail, systèmes, applications,
données, media, etc.) et les conditions
requises pour l'attribution, la gestion et le
contrôle des droits d'accès ?
10.8.2 A-t-on analysé les risques liés aux transferts E2
d'informations ou de logiciels avec un tiers,
et formalisé contractuellement les
procédures, responsabilités et obligations de
chacune des parties ?
117
10.8.3 Lors du transfert de données sensibles sur E2

support informatique pour stockage externe,
existe-t-il une procédure imposant des
conteneurs haute sécurité et des convoyeurs
accrédités par l'entreprise ?
10.8.4 A-t-on mis en place un service de E2
messagerie électronique chiffrée ?
10.8.5 Existe-t-il une politique de sécurité propre E1
aux autres échanges électroniques
d'information (conférence téléphonique,
travail coopératif, partage de documents,
services FTP, messagerie instantanée, etc.)
définissant les précautions d'emploi et
mesures de sécurité à mettre en œuvre ?
10.9 Services de commerce électronique
10.9.1 A-t-on analysé les exigences de sécurité E2
spécifiques au commerce électronique et
défini en conséquence les protections
nécessaires ?
spécifiques aux transactions effectuées en
ligne et défini en conséquence les
protections nécessaires ?
spécifiques à la mise à disposition du public
d'informations et défini en conséquence les
protections nécessaires ?
10.10 Surveillance
10.10.1 Les règles spécifiant les accès à journaliser E2
118
et enregistrer couvrent-elles les éléments

essentiels pour une investigation en cas
d'anomalie ?
Ces règles devraient spécifier pour chaque
type d'accès (système, SGBD, etc.) les
éléments fondamentaux à enregistrer, par
exemple l'identifiant, le service ou
l'application demandée, la date et l'heure, le
point d'appel s'il est connu, etc.
10.10.2 A-t-on analysé les événements ou E2
succession d'événements pouvant être
révélateurs de comportements anormaux ou
d'actions illicites sur le réseau étendu et en
a-t-on déduit des points ou indicateurs de
surveillance ?
10.10.3 Les enregistrements ou les synthèses sont- E2
ils protégés contre toute altération ou
destruction ?
10.10.4 Enregistre-t-on tous les événements E2
(journalisation) ou successions
d’évènements menés avec des droits
d'administration et pouvant avoir un impact
sur la sécurité des réseaux, ainsi que tous
les paramètres utiles à leur analyse
ultérieure ?
10.10.5 Y a-t-il une équipe (hot line) chargée de E1
recueillir les appels liés au réseau (local et
étendu) et de signaler et d'enregistrer tous
les incidents ?
119
10.10.6 Existe – t – il un document (ou une E3

procédure) imposant la mise en place d'un
dispositif de synchronisation avec un
référentiel de temps
précis ?
11 Contrôle d’accès
11.1 Exigences métier relatives au contrôle
d’accès
11.1.1 A-t-on établi une politique de gestion des E1
droits d'accès relatif à l’exploitation et à la
sécurité du site, s'appuyant sur une analyse
préalable des exigences de sécurité, basées
sur les enjeux de l'activité ?
11.2 Gestion de l’accès utilisateur
11.2.1 Existe-t-il des procédures formelles E2
d'enregistrement et de révocation des
utilisateurs ?
11.2.2 Le processus d'attribution (ou modification R1
ou retrait) de droits privilégiés à un
individu est-il strictement contrôlé ?
Un contrôle strict requiert une
reconnaissance formelle de la signature
(électronique ou non) du demandeur, qu'il
existe un contrôle d'accès très renforcé pour
pouvoir attribuer ou modifier de tels droits,
et que les modifications d'attributions de
droits privilégiés soient journalisées et
auditées.
120
11.2.3 Le processus de définition ou de E2

modification de l'authentifiant supportant le
contrôle d'accès pour les accès internes
vérifie-t-il le respect d'un ensemble de
règles permettant d'avoir confiance dans sa
solidité intrinsèque ?
Dans le cas de mots de passe : longueur
suffisante (8 caractères ou +), mélange
obligatoire de types de caractères,
changement
fréquent (<1 mois), impossibilité de
réemployer un mot de passe ancien, test de
non trivialité fait en relation avec un
dictionnaire, interdiction des "standards
systèmes", des prénoms, de l'anagramme de
l'identifiant, de dates, etc.
Dans le cas de certificats ou
d'authentification reposant sur des
mécanismes cryptologiques, processus de
génération évalué ou reconnu
publiquement, clés de chiffrement de
longueur suffisante, etc.
11.2.4 Y a-t-il un audit régulier, au moins une fois C1
par an, de l'ensemble des droits attribués à
chaque profil d'accès et des procédures de
gestion des profils ?
11.3 Responsabilités utilisateurs
11.3.1 Existe – t – il un document précisant les E2
devoirs et responsabilités du personnel
quant à l'utilisation et la protection des
121
moyens d'authentification (mots de passe,

clés, tokens, badges, etc.) mis à sa
disposition ?
11.3.2 Les devoirs et responsabilités du personnel
précisent-ils la conduite à tenir lorsque le
poste est laissé vacant (fermeture de
session, log off, écran de veille,
verrouillage, etc.) ?
règles générales à appliquer au quotidien
dans la gestion de l'environnement de
travail (documents, bureau propre, micro-
informatique, téléphone, fax, etc.) ?
11.4 Contrôle d’accès au réseau
règles à appliquer en ce qui concerne
l'exploitation des ressources informatiques
(réseaux, serveurs, etc.), des services de
communication électronique et des réseaux
sans fil ?
concerne la protection du SI vis-à-vis de
l'extérieur, les conditions requises pour
accéder à chaque partie du SI depuis
l'extérieur et la protection des locaux
sensibles ?
11.4.3 Pour les connexions qui l'exigent, y a-t-il E3
une identification de l'équipement appelant
122
(adresse MAC, adresse IP, etc.) en

association avec des règles de contrôle
d'accès ?
11.4.4 En cas de télémaintenance, y a-t-il une E2
procédure d'authentification forte du centre
de télémaintenance ? Pour la protection des
ports de diagnostics et de configuration à
distance
11.4.5 Existe-t-il un document (ou une procédure) E2
définissant les règles générales à appliquer
en ce qui concerne la protection du réseau
interne vis-à-vis de l'extérieur, les
conditions requises pour accéder depuis
l'extérieur au réseau interne et
réciproquement et les cloisonnements
internes entre sous-réseaux ?
11.4.6 A-t-on défini un ensemble de règles pour E2
qu'une entité puisse être connectée au
réseau étendu considéré comme un espace
de confiance ?
Ces règles devront définir les mesures de
sécurité logique devant protéger les
équipements de réseau et les équipements
de sécurité et préciser les filtrages à mettre
en place pour contrôler les accès entrants
aussi bien que pour les accès sortants
11.4.7 Procède-t-on régulièrement à une revue des C1
connexions autorisées (standards et non
standards) et de leur pertinence ?
123
11.5 Contrôle d’accès au système

d’exploitation
11.5.1 Le processus de connexion (login) est-il E3
sécurisé ?
Un processus de connexion sécurisé ne
devrait donner aucune information avant
achèvement satisfaisant du processus, ne
pas afficher le mot de passe ou
l'authentifiant, afficher la date et l'heure de
la dernière connexion, afficher les
éventuelles tentatives de connexion ayant
échoué, etc.
11.5.2 Tout accès à un système requiert-il la E1
présentation d'un identifiant (sujette à une
authentification) reconnu par ledit système
?
L'authentification systématique requiert que
ce processus soit effectivement mis en
œuvre pour l'ensemble des sous-systèmes
(moniteur de télétraitement, SGBD,
traitements par lots, etc.) et pour toutes les
demandes d'accès en provenance des
applications ainsi que pour toutes les voies
et ports d'accès, y compris depuis des ports
réservés tels que la télémaintenance
éventuelle.
11.5.3 Le processus de distribution ou de E1
changement de l'authentifiant garantit-il que
seul le titulaire de l'identifiant peut y avoir
accès (diffusion initiale confidentielle,
124
changement de mot de passe sous le seul

contrôle de l'utilisateur, etc.) ?
11.5.4 Les outils ou utilitaires sensibles E2
(administration des privilèges, gestion des
configurations, sauvegardes, copies,
reprises à chaud, etc.) sont-ils recensés de
manière exhaustive et contrôlés pour
chaque type de profil ?
11.5.5 Y a-t-il une dévalidation automatique de la E3
session de l'utilisateur, en cas d'absence
d'échange après un délai défini, nécessitant
une nouvelle identification -
authentification ?
11.5.6 Les profils d’accès aux données E3
applicatives permettent-ils également de
définir des créneaux horaires pour les
connexions, et des calendriers de travail
(heures début et fin de journée, week-end,
vacances, etc.) ?
11.6 Contrôle d’accès aux applications et à
l’information
11.6.1 La procédure d'attribution des autorisations E1
d'accès nécessite-t-elle l'accord formel de
la hiérarchie (à un niveau suffisant) ?
11.6.2 En a-t-on déduit des mesures d'isolement E2
(physique et logique) appropriées pour les
systèmes ou équipements sensible ?
Ces mesures peuvent couvrir par exemple la
séparation des centres hébergeant des
125
serveurs sensibles d'autres serveurs et/ou

des applications sur différents serveurs.
11.7 Informatique mobile et télétravail
procédures de sécurité additionnelles à
appliquer en ce qui concerne l'informatique
mobile et le télétravail ?
11.7.2 A-t-on établi une politique de sécurité et des E1
recommandations relatives au travail en
dehors des locaux de l'entreprise ?
Les recommandations et directives
devraient traiter des précautions à prendre
aussi bien dans des situations de travail à
domicile, qu'en déplacement ou dans les
transports publics et couvrir la protection
des micro-ordinateurs portables, l'utilisation
du pare-feu et de l'antivirus à jour, les
connexions à des réseaux publics ou tiers,
les précautions à prendre concernant les
documents écrits, les messageries
instantanées et les conversations
téléphoniques et orales.
12 Acquisition, développement et
maintenance des systèmes d’information
12.1 Exigences de sécurité applicables aux
systèmes d’information
12.1.1 Procède-t-on systématiquement, dès la E1
phase de spécification de projets, à une
126
analyse des dysfonctionnements pouvant

être induits par le SI (l'application ou les
applications mises en place) ?
Notes : Un projet peut consister en la mise
en place d'un progiciel métier, autant que
résulter de développements internes.
Les dysfonctionnements à analyser doivent
l'être à deux niveaux : au niveau de l'activité
de l'entreprise et de ses processus
opérationnels (les fonctionnalités nouvelles
ou au contraire supprimées apportent-elles
des risques nouveaux ?) et au niveau de
l'architecture informatique (infrastructure,
systèmes opératoires, middleware,
applications, données : cette nouvelle
architecture apporte-t-elle des risques
nouveaux ?).
12.2 Bon fonctionnement des applications
12.2.1 Les données sensibles font-elles l'objet d'un E1
autocontrôle formel (par la personne
assurant la saisie) ou d’un contrôle de saisie
indépendant (par une autre personne) ?
12.2.2 Lors de la conception ou de la mise en E2
œuvre des applications, procède-t-on à une
étude détaillée des défaillances de
traitement pouvant donner lieu à des pertes
d'intégrité ?
12.2.3 A-t-on défini les échanges de données ou E2
transactions sensibles devant être protégés
par des solutions de scellement et mis-en
127
place de telles solutions au niveau applicatif

?
12.2.4 A-t-on analysé, avec les utilisateurs, les E1
contrôles qu'il serait souhaitable de faire
pour vérifier la cohérence des données après
traitement par les processus applicatifs
(introduction de variables de contrôle,
ratios, évolution et comparaison avant et
après traitements, etc.) et a-t-on mis en
place les contrôles correspondants dans les
applications ?
12.3 Mesures cryptographiques
12.3.1 A-t-on défini les données sensibles, liens E2
permanents et les échanges de données
devant être protégés par des solutions de
chiffrement et mis en place de telles
solutions au niveau des parties adéquates du
SI (réseau, serveurs, postes utilisateur, etc.)
?
12.3.2 La procédure et les mécanismes de E3
conservation, de distribution et d'échange de
clés, et plus généralement de gestion des
clés, offrent-ils des garanties de solidité
dignes de confiance et ont-ils été approuvés
par le RSSI ?
12.4 Sécurité des fichiers système
12.4.1 Une revue formelle des nouvelles E2
fonctionnalités (ou des changements de
fonctionnalités) liées à un changement
128
majeur de logiciel ou d'équipement est-elle

systématiquement réalisée, avec le concours
de la fonction sécurité informatique ?
12.4.2 Les informations d'exploitation utilisées sur E2
une application d'essai sont-elles contrôlées
et protégées lors de la phase d’essai ?
12.4.3 Les codes sources et la documentation font- E2
ils l'objet d'une procédure de gestion d'accès
stricte précisant, en fonction des phases de
développement, les profils ayant accès à ces
éléments ainsi que les conditions de
stockage et de contrôle d'accès
correspondantes ?
Une procédure et des conditions de gestion
d'accès strictes doivent permettre de
garantir que tout accès au code ou à la
documentation est fait par une personne
autorisée dans des conditions autorisées.
12.5 Sécurité en matière de développement et
d’assistance technique
12.5.1 Tout changement (ou demande de E2
changement) relative à une partie du SI
(applications, équipements) fait-elle l'objet
d'une procédure de revue formelle
(demandeur, justification, processus de
décision) ?
12.5.2 À l'occasion de modification des systèmes E2
d'exploitation, procède-t-on à une revue et à
des tests de l'impact de ces modifications
129
sur les applications ?

12.5.3 En cas de modification de progiciels E2
applique-t-on un contrôle strict de ces
modifications ?
12.5.4 A-t-on envisagé, lors des études de risques, E3
les possibilités de fuite d'information par
des canaux cachés et mis en place des
contrôles adaptés ?
12.5.5 Lorsque le développement logiciel est sous- E2
traité, a-t-on pris soin de mettre sur pieds
des procédures d’encadrement et de
contrôle du code développé ?
12.6 Gestion des vulnérabilités techniques
12.6.1 Les versions de systèmes et les correctifs à E2
apporter, ainsi que les paramétrages, sont-
ils régulièrement mis à jour en fonction de
l'état des connaissances ?
Ceci devrait se faire en relation avec un
organisme expert (audits spécialisés,
abonnement à un centre de service,
consultation
régulière des avis des experts, etc.).
13 Gestion des incidents liés à la sécurité de

l’information
13.1 Signalement des événements et des failles
liés à la sécurité de l’information
13.1.1 Y a-t-il un système de déclaration des E1
incidents auprès des correspondants du
130
RSSI avec une synthèse de ces incidents

transmise au RSSI ?
13.1.2 Existe – t – il des règles et mesures précises E2
sur les processus de reporting des incidents
et des anomalies constatées, ainsi que sur
les comportements adaptés ?
13.2 Gestion des améliorations et incidents liés
à la sécurité de l’information
13.2.1 Les responsabilités et les procédures sont- E2
elles établies afin de fournir rapidement des
solutions effectives aux incidents de
sécurité ?
13.2.2 La typologie et la description des incidents E2
sont-elles enregistrées dans une base
permettant un enrichissement progressif
ainsi qu'un accès sélectif facile pour
effectuer le traitement et le suivi des divers
incidents ?
13.2.3 La collecte de preuves est-elle réalisée E2
chaque fois qu'une action juridique doit être
envisagée ?
14 Gestion du plan de continuité de l’activité

14.1 Aspects de la sécurité de l’information en
matière de gestion de la continuité de
l’activité
14.1.1 Existe-t-il des processus, régulièrement mis E2
en œuvre, d'analyse des risques, liés à
l'information, pouvant conduire à une
131
interruption des activités de l'entreprise,

débouchant sur une définition des exigences
de sécurité, des responsabilités, des
procédures à appliquer et moyens à mettre
en œuvre afin de permettre l'élaboration des
plans de continuité ?
14.1.2 A-t-on analysé la criticité des différentes E1
activités pour mettre en évidence les
besoins de continuité de service ?
Une analyse approfondie suppose que l'on
établisse une liste de scénarios d'incidents et
qu'on en analyse toutes les conséquences
prévisibles.
14.1.3 A-t-on déduit, d'une analyse de criticité, des E1
Plans de Continuité d'Activité (PCA) pour
chaque activité critique ?
14.1.4 A-t-on déduit d'une analyse de criticité une E2
architecture de redondance ou de systèmes
miroirs au niveau des réseaux ou
équipements pouvant être critiques ?
14.1.5 Y a-t-il un responsable en charge de C1
l’élaboration, du suivi et des tests des plans
de continuité des services ?
15 Conformité
15.1 Conformité avec les exigences légales
15.1.1 L'ensemble des exigences réglementaires, E2
contractuelles, et légales a-t-il été
explicitement identifié et son application
132
par l'organisation figure-t-elle dans un

document tenu à jour ?
15.1.2 Procède-t-on à des contrôles fréquents E2
visant à vérifier que les logiciels installés
sont conformes aux logiciels déclarés ou
qu'ils possèdent une licence en règle ?
15.1.3 Existe-t-il un document précisant les E2
exigences, les responsabilités et les
procédures à appliquer afin de protéger les
archives importantes pour l'organisation ?
15.1.4 Existe-t-il une politique et des directives E2

précises en matière de protection des
renseignements personnels (PRP) ?
15.1.5 Les devoirs et responsabilités du personnel E2
quant à l'utilisation des moyens de
traitement de l’information sont-ils précisés
dans une note ou document mis à la
disposition de tout utilisateur du SI de telle
sorte qu’il ne puisse nier en avoir eu
connaissance ?
15.1.6 Existe-t-il un document regroupant E2
l'ensemble des dispositions légales ou
réglementaires relatives à l'utilisation de
moyens cryptographiques ?
15.2 Conformité avec les politiques et normes
de sécurité et conformité technique
15.2.1 Les managers (ou responsables) s'assurent- R1
ils et doivent-ils rendre compte, de la
133
conformité du comportement de leurs

collaborateurs aux politiques et standards en
vigueur ?
15.2.2 Procède-t-on à des tests périodiques de C1
pénétration du réseau et à des audits
techniques spécialisés approfondis ?
15.3 Prises en compte de l’audit du système
d’information
15.3.1 Les règles concernant les audits menés sur E2
les réseaux, les procédures et
responsabilités associées, sont-elles définies
et documentées ?
Les limites à apporter concernent les types
d'accès aux équipements, les contrôles et les
traitements admis, l'effacement des données
sensibles obtenues, le marquage de
certaines opérations, ... ainsi que
l'habilitation des personnes réalisant l'audit.
15.3.2 Les outils d'audit sont-ils protégés afin E2
d'éviter toute utilisation indue ou
malveillante ?
Ceci s'applique, en particulier, aux tests de
pénétration et aux évaluations de
vulnérabilité.
Annexe 2 : Installation de Kali
Ce tutoriel va vous permettre d’installer Kali linux. Il peut être utilisé pour une
installation « en dur » (directement sur le disque dur de votre ordinateur) ou lors de la
création d’une machine virtuelle.
134
Cette installation est basée sur le système de machine virtuelle VMware.
 Choisissez « Graphical Install » pour bénéficier de menus graphique et appuyer

sur [ENTRER].
 Choisissez votre langue (moi j’ai choisi « French -Français ») puis cliquer sur «
Continue ».
135
 Choisissez votre situation géographique (moi j’ai choisi « France ») puis cliquer
sur « Continuer ».
 Choisir la configuration de votre clavier (moi j’ai choisi Français car j’ai un
clavier azerty) puis cliquer sur « Continuer ».
136
 Indiquer le nom de votre machine sur le réseau (évitez de personnaliser) puis

cliquer sur « Continuer ».
 Cliquer sur « Continuer »
137
 Indiquer puis confirmer un mot de passe puis cliquer sur « Continuer ».
 Partitionner le disque dur (moi j’ai laissé « Assisté – utiliser un disque entier »)
puis cliquer sur « Continuer »
Vous pouvez faire d’autres choix en fonction de vos besoins. Le LVM (Logical
Volume Manager) chiffré peut être utile en cas de pertes du PC mais diminuera
les performances de votre matériel.
138
 Choisissez le disque dur sur lequel vous désirez procéder à l’installation (en
ayant pris soin de faire une sauvegarde de vos données sensibles au préalable)
puis cliquer sur « Continuer ».
 Laisser « Tout dans une seule partition » puis cliquer sur « Continuer ».
139
 Cliquer sur « Terminer le partitionnement et appliquer les changements » puis

 Cliquer sur « Oui » pour confirmer vos réglages sur le partitionnement des
disques puis cliquer sur « Continuer ».
140
 Cliquer sur « Non » (vous pourrez mette à jour les outils plus tard) puis cliquer
 Cliquer sur « Continuer » : pour installer le programme de démarrage GRUB

sur un disque dur.
141
 Retirer votre CD ou clé USB de votre PC (si c’est une machine virtuelle ne
faites rien) puis cliquer sur « Continuer ».
Votre PC redémarre. Félicitations ! Vous venez d’installer kali linux.
Annexe 3 : Analyse de flux d’un réseau avec Wireshark.
Lancement de Wireshark
Wireshark permet d'analyser un trafic enregistré dans un fichier annexe, mais

également et surtout le trafic en direct sur des interfaces réseau. Cette seconde fonction
nécessite de posséder les droits administrateurs, ou d'appartenir à un groupe possédant
ces droits.
142
Figure 1: fenêtre d'ouverture de Wireshark
L'utilitaire s'ouvre sur l'interface présentée en Figure 1, découpée en quatre zones :
(1) liste des interfaces et lancement rapide d'une capture
(2) Aide sur la capture de paquets
(3) Analyse d'une capture précédente enregistrée sur fichier
(4) Aide online et manuel utilisateur
(5) Barre d’icone
(6) Barre de filtre
Capture des trames sur le réseau
La principale utilisation que nous ferons de Wireshark consistera en la capture de

trames réseau en live. Les trois premiers boutons de la barre d'icônes permettent une
telle capture, et sont des raccourcis aux éléments présentés dans le menu « capture »
Pour lancer une capture live, plusieurs méthodes s'offrent à nous, parmi lesquelles :
➔ Cliquer directement sur l'interface désirée listée dans la zone (1) de Figure 1. On
cliquera par exemple sur le bouton « Start » associé au lien eth0 pour lancer la
capture
143
➔ Cliquer sur le premier icône de la barre des icônes intitulé liste des interfaces de
captures disponibles. Une fenêtre s'ouvre (Figure 2), il nous suffit alors de cliquer sur
le bouton « Start » de l'interface de notre choix pour lancer la capture sur cette
interface.
Figure 2: Liste des interfaces, menu « capture / interfaces », ou premier icône
➔ Cliquer sur le 3eme icône de la barre des icônes en partant de la gauche pour lancer
directement une capture sur l'ensemble des interfaces.
Une fois lancée, la capture peut être interrompue en cliquant sur le 4ème bouton de la
barre d'icônes (en partant de la gauche). Ce bouton n'est actif uniquement lors
d'une capture. Lorsqu'une capture est active, le logiciel présente l'interface de
l'analyseur (Figure 3). Cette interface reste ensuite visible lorsque la capture est
arrêtée.
144
Figure 3: interface de l'analyseur
L'interface de l'analyseur est découpée en trois zones :
• Zone supérieure, numérotée (1) sur Figure 3 : liste l'ensemble des paquets capturés
• Zone centrale, numérotée (2) sur Figure 3 : affiche le détail d'un paquet sélectionné
dans la liste des paquets de la zone supérieure. Les informations présentées y sont de
loin les plus pertinentes, puisqu'il est possible de visualiser aisément les différents en-
têtes résultant de l'encapsulation d'un message.
• Zone inférieure, numérotée (3) sur Figure 3 : présente l'ensemble du paquet sous
forme octale et ASCII. Ces octets contiennent les en-têtes des différentes couches de
l'architecture TCP/IP ainsi que les données transmises par le processus à l'origine du
message.
Analyse d'un paquet
Encapsulation d'un paquet
Lorsqu'un paquet est sélectionné, la zone centrale permet de visualiser

clairement les différentes couches d'encapsulation du paquet. Par exemple si l'on
sélectionne un paquet de type UDP, la zone centrale pourrait afficher quelque chose de
145
similaire à ce qui est présenté sur Figure 4. Les 5 entrées présentées correspondent à
différentes encapsulations, ordonnées de la couche la plus basse à la couche la plus
haute :
1. Données sur le média de capture : Wire = filaire sur Figure 4
2. Trame relative à la couche liaison de donnée : Ethernet II sur Figure 4
3. Paquet relatif à la couche réseau : Internet Protocol sur Figure 4
4. Datagramme relatif à la couche transport : User Datagram Protocol sur Figure 4
5. Données de l'application : regroupe généralement les couches session,

présentation, application.
Figure 4:Encapsulation d'un paquet UDP, zone centrale de l'analyseur.
Détail de chaque niveau d'encapsulation
Pour tout item correspondant à un niveau d'encapsulation, un clic sur le triangle en

début de ligne permet de dérouler l'en-tête afin de voir l'ensemble des champs le
composant. Certains champs peuvent également être déroulés. Sur l'exemple
présenté en Figure 5, nous avons étendu les entrées correspondant aux couches
réseau, transport et application en cliquant sur les triangles correspondants.
Nous pouvons voir entre autre que :
• Le paquet est de type IP v4 : ref (2) sur Figure 5
• Le type de données de ce paquet IP est un datagramme UDP : ref (5) sur Figure 5
• L’IP de la machine source est 193.52.236.243 : ref (6) sur Figure 5
146
Figure 5: Visualisation détaillée des en-têtes d'un paquet
• L’IP de la machine destination est 193.52.236.247 : ref (7) sur Figure 5
Nous pouvons également faire un point sur la taille des données et des en-têtes à
différents niveaux d'encapsulation :
• La taille des données envoyée par le processus est de 23 octets : ref (9) sur
Figure 5
• La taille totale du datagramme UDP est de 31 octets - ref (8) sur Figure 5 - .
Cette valeur est la somme entre la taille réelle des données (23 octets) et 8
octets d'en-tête du paquet (8 étant une valeur fixe pour un paquet UDP)
• La taille des en-têtes du paquet IP est de 20 octets : ref (3) sur Figure 5
• Le paquet IP contient en en-tête (20 octets) ainsi que le datagramme UDP (31
octets). Sa taille totale est de 51 octets, taille rappelée en ref (4) sur Figure 5
• La taille totale du paquet IP est de (flèche). Cette valeur somme la taille du

paquet UDP à la taille de l'en-tête IP.
147
• Si l'on ajoute 12 octets d'en-tête pour la couche Ethernet II (taille fixe), la

taille totale de la trame est de 65 octets, comme présentée en ref (1) sur Figure
5.
Notons ainsi que pour transférer 23 octets de données brutes, il nous a fallu
transférer au total 65 octets (en fait il nous a même fallu transférer des octets
supplémentaires avant la trame Ethernet. Ces octets seront ici passés sous
silence).
Visualisation octale de la trame
La zone inférieure permet de visualiser la trame capturée sous forme octale. Un

clic sur n'importe lequel des niveaux d'encapsulation permet de visualiser la
portion d'octets correspondante dans la zone inférieure de l'analyseur.
Pour n'importe quel niveau, un clic sur une valeur de champs permet de visualiser
la portion d'octets correspondant à cette valeur dans le paquet au niveau de la zone
inférieure de l'analyseur. Réciproquement, un clic sur un octet quelconque affiche
le champ correspondant dans la zone centrale. Ainsi dans l'exemple présenté en
figure 5, un clic sur le champ « Source » de la couche réseau - voir réf (6) sur
Figure 5 - mettra en évidence dans la zone inférieure les octets codant cette source
- voir réf (10) sur Figure 5 - et réciproquement.
Signalons enfin qu'il est possible de visualiser les données transmises dans ce
datagramme UDP. En cliquant sur l'entrée « Data » de la zone centrale, les
octets correspondants mais également leur codage ASCII seraient mis en évidence
dans la zone inférieure. En examinant ce codage ASCII, il est parfois très facile de
décoder les messages. Si l'on examine les derniers caractères ASCII représentant
le message - ref (11) sur Figure 5 - on devine aisément que le message envoyé était
« test d'envoi de message ».
Filtrage de paquets
Principe et mise en place d'un filtre

148
L'intégralité des paquets capturés est listée dans la zone supérieure de l'analyseur. Il
est souvent utile de filtrer les paquets à capturer, afin de pouvoir visualiser
correctement un certain type de paquets seulement. Wireshark permet de filtrer les
paquets à capturer en fonction des informations des différentes couches
d'encapsulation.
La mise en place d'un filtre s'effectue par le biais d'une règle de filtre à définir dans la
zone « filtre » de l'analyseur. Une règle de filtre est constituée d'un ensemble de tests
d'expressions impliquant des noms de champs et des valeurs. Un paquet n'est alors
listé qu'à la condition qu'il satisfasse les conditions du filtre. L'ensemble des champs
utilisables dans l'établissement des règles est listé dans la fenêtre pop-up accessible en
cliquant sur le bouton « expression ». Les règles peuvent être élaborées en
sélectionnant les champs à partir de cette fenêtre, ou en les écrivant directement dans
la zone de filtre. Un ensemble de filtres prédéfinis est accessible en cliquant sur le
bouton « filter ». Cette liste de filtres peut être complétée d'entrées enregistrées. Une
fois le filtre défini, il ne faut pas oublier de l'appliquer avec le bouton « Apply ».
Quelques filtres
Nous terminerons ce tutoriel en énonçant quelques filtres possibles :
Désignation Filtre associé

Segments TCP uniquement tcp
Paquets relatifs à TCP uniquement ip.proto == 0x06
Adresse ip 192.168.0.1 ou 192.168.1.5 ip.addr == 192.168.0.1 || ip.addr == 192.168.1.5
Trafic HTTP uniquement http
Segment TCP sauf sur port 80 tcp && !(tcp.port == 80)
Address Ethernet 00:FF:12:34:AE:FF eth.addr == 00:FF:12:34:AE:FF
Trafic 192.168.0.1 vers 197.168.10.5 ip.src == 192.168.0.1 && ip.dst == 197.168.10.5

Trafic UDP entre ports 40 et 67 udp && udp.port >= 40 && udp.port <=67
Trafic MSN tcp && tcp.port ==1863
Benoit Darties 5/5 [email protected]
149
Pour plus d’information sur l’utilisation de wireshark, consulter le site officiel :

http://www.wireshark.org.
Annexe 4 : Analyse de vulnérabilité avec Nessus.
Ce tutoriel décrit de manière brève comment installer, configurer et utiliser l'interface

utilisateur (IU) de Nessus version 5 de Tenable Network Security, sur un système
Debian notamment Kali linux. Pour plus d’informations, veuillez consulter les guides
d’installation et de configuration de Nessus 5 disponible à la page suivante :
http://www.tenable.com/products/nessus/documentation
L'IU Nessus est une interface basée sur le Web du scanner de vulnérabilité Nessus.
Pour utiliser le client, il est nécessaire d'avoir déployé un scanner Nessus opérationnel
et d'être familiarisé avec son utilisation.
Installation et configuration
Configuration requise
Tenable recommande au minimum une mémoire de 2 Go pour utiliser Nessus. Pour

effectuer des scans plus importants de plusieurs réseaux, une mémoire d'au moins 3
Go est recommandée, mais jusqu'à 4 Go peuvent être nécessaires pour des tâches plus
intenses comme les pistes d'audit ou la création de rapports PDF.
Un processeur Pentium 3 fonctionnant à 2 GHz ou plus est recommandé. Il est

préférable de déployer Nessus sur les systèmes 64 bits. Le système doit posséder au
moins 30 Go d'espace libre sur le disque dur pour Nessus et les données de scan
générées.
Avant d'installer Nessus sur Unix/Linux, plusieurs bibliothèques sont requises. De

nombreux systèmes d'exploitation les installent par défaut et, en général, elles ne
nécessitent pas d'installation séparée :
150
 zlib
 GNU C Library (c'est-à-dire libc)
 Oracle Java (rapports PDF uniquement)
Remarque : Java doit être installé sur l'hôte avant Nessus. Si Java est installé
après, il faudra réinstaller Nessus.
Installation du serveur
Téléchargez la dernière version de Nessus depuis

http://www.nessus.org/products/nessus/nessus-download-agreement
Utilisez l'une des commandes appropriées ci-dessous qui correspond à la version de

Debian exécutée :
#dpkg -i Nessus-5.0.1 –debian6_i386.deb

#dpkg -i Nessus-5.0.1 –debian6_amd64.deb
À l'issue de l'installation, démarrez le démon nessusd en suivant les instructions de la

section suivante. Une fois Nessus installé, vous devez visiter l'URL de scanner fournie
pour terminer le processus d'enregistrement.
NB : Les installations Unix peuvent fournir une URL contenant un nom d'hôte
relatif qui ne figure pas dans le DNS (par exemple, http://mybox:8834/). Si le nom
d'hôte ne figure pas dans le DNS, vous devez vous connecter au serveur Nessus à
l'aide d'une adresse IP ou d'un nom DNS valide.
À l'issue de ce processus, il est recommandé d'authentifier et de personnaliser les

options de configuration pour votre environnement, en suivant les instructions de la
section « Enregistrement des feeds et configuration de l'interface graphique ».
Nessus doit être installé dans /opt/nessus. Toutefois, si /opt/nessus est un lien
symbolique symlink vers un autre emplacement, il est acceptable.
Démarrer le démon Nessus
151
Démarrez le service Nessus en tant qu'utilisateur root avec la commande suivante :
#/opt/nessus/sbin/nessus-service -D
Si vous souhaitez supprimer le message de la commande, utilisez l'option « -q »

comme suit :
#/opt/nessus/sbin/nessus-service -q -D
Vous pouvez aussi démarrer Nessus en utilisant la commande suivante, selon la

plateforme du système d'exploitation :
#/etc/init.d/nessusd start
Passez à la section « Enregistrement des feeds et configuration de l'interface graphique

» pour installer le code d'activation des plugins.
Arrêter le démon Nessus
Si vous devez arrêter le service nessusd pour une raison quelconque, la commande
suivante arrête Nessus et arrête brusquement tout scan en cours :
#killall nessusd
Il est recommandé d'utiliser plutôt le script d'arrêt, plus graduel, fourni pas votre
système d'exploitation :
#/etc/init.d/nessusd stop
Enregistrement des feeds et configuration de l'interface graphique
Cette section décrit comment configurer le serveur Nessus 5. À partir de Nessus 5, les
options de configuration initiales telles que les options proxy et la fourniture d'un code
d'activation sont effectuées via un processus Web. Après l'installation de Nessus, vous
avez, pour des raisons de sécurité, six heures pour terminer le processus
d'enregistrement. Si l'enregistrement n'est pas terminé à l'issue de ce délai, redémarrez
nessusd et redémarrez le processus d'enregistrement.
152
Si l'installation du logiciel n'ouvre pas votre navigateur Web à la page de

configuration, vous pouvez charger un navigateur et aller à http://[Nessus Server
IP]:8834/WelcomeToNessus-Install/welcome. (Ou à l'URL fournie au cours du
processus d'installation) pour démarrer le processus. Remarque : Les installations Unix
peuvent fournir une URL contenant un nom d'hôte relatif qui ne figure pas dans le
DNS (par exemple, http://mybox:8834/). Si le nom d'hôte ne figure pas dans le DNS,
vous devez vous connecter au serveur Nessus à l'aide d'une adresse IP ou d'un nom
DNS valide.
L'écran initial sert à avertir que tout le trafic à destination de l'interface graphique
Nessus transite par SSL (HTTPS). Lorsque vous vous connectez pour la première fois
au serveur Web Nessus, votre navigateur affiche un type d'erreur donné qui indique
que la connexion n'est pas une connexion de confiance en raison d'un certificat SSL
auto-signé. Pour la première connexion, acceptez le certificat pour poursuivre la
configuration. Les instructions à suivre pour installer un certificat personnalisé sont
traitées dans la suite de ce document, à la section « Configuration de Nessus avec un
certificat SSL personnalisé ».
NB : En raison de l'implémentation technique des certificats SSL, il n'est pas

possible de livrer avec Nessus un certificat de confiance pour les navigateurs.
153
Pour éviter cet avertissement, vous devez utiliser un certificat personnalisé

propre à votre organisation.
Suivant le navigateur utilisé, une boîte de dialogue supplémentaire peut s'afficher pour
vous permettre d'accepter le certificat :
Une fois le certificat accepté, vous serez redirigé vers l'écran d'enregistrement initial
qui démarre les étapes détaillées :
154
La première étape consiste à créer un compte pour le serveur Nessus. Le compte initial
sera un administrateur. Ce compte peut accéder aux commandes d'exécution sur le
système d'exploitation sous-jacent de l'installation Nessus ; il doit donc être considéré
de la même façon que tout autre compte d'administrateur :
L'écran suivant demande un code d'activation des plugins et vous permet de configurer
des paramètres de proxy en option.
155
NB : Si vous n'enregistrez pas votre copie de Nessus, vous ne recevrez pas les
nouveaux plugins et vous ne pourrez pas démarrer le serveur Nessus. Remarque :
Le code d'activation n'est pas sensible à la casse.
Si votre serveur Nessus se trouve sur un réseau qui utilise un proxy pour communiquer
avec Internet, cliquez sur « Optional Proxy Settings » (Paramètres de proxy
facultatifs) pour entrer les informations pertinentes. Les paramètres de proxy peuvent
être ajoutés à tout moment à l'issue de l'installation.
156
Une fois que la configuration du code d'activation et des paramètres de proxy

facultatifs est terminée, cliquez sur « Next » (Suivant) pour enregistrer votre scanner :
À l'issue de l'enregistrement, Nessus doit télécharger les plugins à partir de Tenable.

Ce processus peut prendre plusieurs minutes car il transfère une importante quantité de
données vers la machine, il vérifie l'intégrité des fichiers et il les compile dans une
base de données interne :
157
NB : Après l'enregistrement initial, Nessus télécharge et compile en arrière-plan

les plugins obtenus à partir du port 443 de plugins.nessus.org, plugins-
customers.nessus.org ou plugins-us.nessus.org.
Une fois que les plugins ont été téléchargés et compilés, l'interface graphique Nessus
s'initialise et le serveur Nessus démarre :
Après l'initialisation, Nessus est prêt pour utilisation ! Utilisez les identifiants
administratifs créés au cours de l'installation pour vous connecter à l'interface Nessus
et vérifier l'accès.
158
Fonctionnement
Nessus fournit une interface simple mais performante pour gérer l'activité de scan des
vulnérabilités.
Connexion à l'interface graphique Nessus
Pour lancer l'interface graphique Nessus, procédez comme suit :
 Ouvrez le navigateur Internet choisi.

 Saisissez https://[server IP]:8834/flash.html dans la barre de navigation.
NB : Veillez à vous connecter à l'interface utilisateur par HTTPS, car les

connexions HTTP non cryptées ne sont pas compatibles.
Après, confirmer une exception par le navigateur s’il y en a une, et un écran de

démarrage s'affichera comme suit :
Identifiez-vous en utilisant un compte et un mot de passe créés précédemment au cours

de l'installation. Si l'identification réussit, l'IU affiche les menus permettant de créer
les stratégies, d'exécuter les scans et de parcourir les rapports :
159
Création et lancement d'un scan
Vous pouvez créer un nouveau scan en cliquant sur l'option « Scans » dans la barre de
menu du haut, puis en cliquant sur le bouton « + Add » (Ajouter) à droite. L'écran «
Add Scan » (Ajouter scan) s'affiche comme suit :
Cinq champs servent à saisir le scan cible :
 Name (Nom) – définit le nom qui sera affiché dans l'IU Nessus pour identifier
le scan.
 Type – choisissez « Run Now » (Exécuter immédiatement- exécuter
immédiatement le scan après soumission).
 Policy (Stratégie) – sélectionnez une stratégie que le scan utilisera pour régler
les paramètres contrôlant le comportement de scan du serveur Nessus.
160
 Scan Targets (Cibles de scan) – les cibles peuvent être saisies selon les
adresses IP simples (par exemple 192.168.0.1), une plage IP (par exemple
192.168.0.1-192.168.0.255), un sous-réseau avec notation CIDR (par exemple
192.168.0.0/24) ou un hôte résolvable (par exemple www.nessus.org).
 Targets File (Fichier cibles) – un fichier texte avec une liste d'hôtes peut être
importé en cliquant sur « Browse… » (Parcourir) et en sélectionnant un
fichier sur l'ordinateur local.
NB : Le fichier des hôtes doit être formaté comme texte ASCII avec un hôte par
ligne, sans aucun espace ou ligne supplémentaire. Le codage Unicode/UTF-8 n'est
pas accepté.
Après avoir saisi les informations sur le scan, cliquez sur « Submit » (Soumettre).
Après la soumission, le scan commence immédiatement si « Run Now » (Exécuter
immédiatement) a été sélectionné, avant que l'affichage ne revienne à la page générale
« Scans ».
Une fois qu'un scan est lancé, la liste « Scans » affiche une liste de tous les scans en
cours d'exécution, en pause ou sauvegardés comme modèles, ainsi que des
informations de base sur les scans. Lorsque vous sélectionnez un scan spécifique dans
la liste, les boutons d'action en haut à droite permettent de parcourir (« Browse ») les
résultats du scan en cours, de mettre en pause (« Pause ») et de reprendre (« Resume
») le scan ou encore d'arrêter (« Stop ») et de supprimer (« Delete ») le scan
complètement. Les utilisateurs peuvent aussi éditer (« Edit ») les scans sauvegardés
comme modèles.
Lorsqu'un scan est terminé (pour une raison quelconque), il est supprimé de la liste «
Scans » et peut être examiné sur l'onglet « Reports » (Rapports).
161
Si un scan est sauvegardé comme modèle, il apparaît dans la liste des scans comme tel
et attendra d'être lancé.
Le rapport
Avec la version Nessus 5, les utilisateurs peuvent créer leurs propres rapports par
chapitres : Vulnerability Centric, Host Centric, Compliance ou Compliance Executive.
Le format HTML est toujours pris en charge par défaut ; cependant, si Java est installé
sur l'hôte scanné, il est également possible d'exporter des rapports au format PDF. En
utilisant les filtres de rapport et les fonctions d'exportation, les utilisateurs peuvent
créer les rapports dynamiques de leur choix au lieu de les sélectionner à partir d'une
liste spécifique.
Si vous cliquez sur l'onglet « Reports » (Rapports) dans la barre de menu en haut de
l'interface, la liste des scans en cours d'exécution et terminés s'affiche :
162
L'écran « Reports » (Rapports) joue le rôle de point central pour l'affichage, la

comparaison, le téléchargement et le téléchargement en amont des résultats du scan.
Utilisez la touche « Maj » ou « Ctrl » pour sélectionner plusieurs rapports à la fois.
Naviguer
Pour parcourir les résultats d'un scan, sélectionnez un nom dans la liste « Reports »
(Rapports) et cliquez sur « Browse » (Parcourir). Ceci permet d'afficher les résultats en
naviguant vers les vulnérabilités ou les hôtes, en affichant les ports et les informations
de vulnérabilités spécifiques. La vue par défaut est le résumé des vulnérabilités, qui
présente chaque vulnérabilité détectée par ordre de gravité :
Si des erreurs surviennent au cours du scan, un texte de notation apparaît à côté de la

date d'achèvement (« Completed »). Cliquez sur l'erreur pour afficher d'autres
informations :
163
Dans la vue « Vulnerability Summary » (Résumé des vulnérabilités), l'utilisateur

peut supprimer du rapport les vulnérabilités de son choix. Lorsqu'il sélectionne une
vulnérabilité, des informations supplémentaires comme le ou les ports et le ou les
hôtes affectés s'affichent, de même que des informations techniques sur la
vulnérabilité. L'option « Remove Vulnerability » (Supprimer la vulnérabilité),
disponible en haut à droite, permet de supprimer la vulnérabilité sélectionnée.
Annexe 5 : Test d’intrusion avec Armitage
Avant-propos
Ce tutoriel donne juste un aperçu plus ou moins détaillés des étapes de l’utilisation
d’Armitage pour réaliser un test d’intrusion sur une machine dans un contexte précis.
La phase de test d’intrusion dépend des vulnérabilités décelées lors de la phase
d’analyse de vulnérabilité. Pour plus d’information sur l’utilisation de Metasploit et
Armitage pour les tests d’intrusions, et ses différents exploits, veuillez consulter les
liens suivants :
http://www.fastandeasyhacking.com/manual;
https://community.rapid7.com/docs/DOC-2227.
Description du processus
164
Commencez par mettre la liste des exploits à jours :
msfupdate
Ensuite si vous lancez MySQL vous aurez un message comme quoi il faut le mettre à
jour ou qu'il n'a pas été arrêté proprement :
Si vous lancez le service Metasploit community/pro, tout se déroule sans problème :
165
Vous devriez voir quelque chose qui ressemble à ceci:
Pour la démarrer Armitage, il faut tout simplement allez dans le menu "Applications -
> Kali Linux -> Exploitation Tools -> Network Exploitation -> Armitage".
166
Et ensuite cliquer sur "Connect" dans fenêtre qui s'affiche :
Cette fois il y a une alerte qui dit que le serveur RPC n'est pas en cours d'exécution et
n'accepte pas de connexion. L'alerte demande si l'on désire que l'on lance le server
RPC pour nous :
Une fenêtre de progression s'affiche longuement :
Nous voici devant la fenêtre d'utilisation d'Armitage :
167
Nous allons à présent scanner les machines présente sur un petit réseau créé pour
l’occasion :
Pour cela il suffit de rentrer l'adresse de tout le réseau :
192.168.1.0 pour signifier que tout le réseau sera scanné et /24 pour toutes les machines
168
Une fois le scan complet, Il est suggéré d'utiliser l'outil de recherche pour trouver des
exploits :
Nous voyons à présent toutes les machines connecté sur le réseau local :
Nous allons à présent chercher dans la base de données les attaques disponibles pour le
réseau :
Allez dans le menu "Attacks" puis sélectionnez "Find Attacks" :
169
Une fois la recherche finie, une alerte vous indique qu'un menu est à présent
disponible au clic droit sur la cible :
Une fois dans ce menu nous pouvons visualiser les exploits et checker ceux-ci, ce qui
est conseillé.
Nous allons dans un premier temps checker les exploits smb :
Nous découvrons que la cible n'est pas exploitable.
170
Nous allons tester la faille ms03_026_dcom :
Dans la fenêtre de configuration de l'exploit, nous remarquons que seules les machines
jusqu'à Windows 2003 sont faillibles :
Ce qui nous est confirmé une fois l'attaque lancée.
Nous procédons de même avec la faille ms10_061_spoolss :
Dans celle-ci nous voyons qu'elle affecte toutes les versions de Windows :
171
Mais nous voyons que les mises à jour ont comblé la faille entre temps, ou que la suite
de sécurité (firewall et anti-virus) présente sur la machine a fait son travail.
Conclusion
Ces tests permettent juste de vérifier rapidement si la machine testée est faillible ou
non aux exploits connu. Malheureusement cela ne veut pas dire qu'elle n'est pas
vulnérable aux faille dites 0day ou à un comportement utilisateur risqué.
http://fr.wikipedia.org/wiki/ISO/CEI_27002
172
Bibliographie
Ouvrages Spécialisées :
 Chantale Pineault ADMA, Présentation de l’ISO 27001 et du modèle PDCA,

Québec, Août 2011.
 Organisation internationale de normalisation, ISO/CEI 27002 : Technologies de
l’information – Technique de sécurité – Code de bonne pratique pour la gestion de
la sécurité de l’information, NORME INTERNATIONALE, première édition,
2005.
 Equipe Analyse, Mini-Rapport d’Audit basé sur la méthode d’analyse MEHARI,
Projet Réseau Sécurité, 2007.
 CLUSIF, Aider les auditeurs pour les revues de sécurité physique, LES
DOSSIERS TECHNIQUES, 2011.
 CLUSIF, MEHARI 2010 : Guide du diagnostic de l’état des services de sécurité,
METHODES, Janvier 2010.
 CLUSIF, Test d’intrusion, Document Technique, Mars 2004.
 Éric Clairvoyant, Guide d’utilisation de l’outil d’audit de sécurité, version 1.6, Mai
2011.
 François VERGEZ – AFAI, Panorama général des normes et outils d’audit, 2013.
 Chantale Pineault, Présentation de l’ISO 27001 et du modèle PDCA, AGRM -
Protection de l’information, Québec, Août 2011.
Mémoires :
 Abbes RHARRAB : Audit Sécurité des Systèmes d’Information, Mémoire de Projet

de Fin d’Etudes, Université Mohammed V Agdal, Faculté des Sciences Rabat,
2010.
 Maïmouna TIEMA : Conception d’un manuel de procédures du cycle information
comptable du PLS, Mémoire de fin d’étude, Centre Africain d’étude Supérieur en
Gestion, Institut Supérieur de Comptabilité de Banque et de Finance, 2009.
173
 Ayari Amani : Audit de Sécurité du Système Informatique de MTIC, Mémoire de

stage de fin d’étude, Université Virtuel de Tunis, 2014.
Support de cours :
 Dr. Ala Eddine BAROUNI, Cours d’Audit de la Sécurité Informatique.
Webographie :
 http://www.qualiblog.fr/documentation/quelques-conseils-pour-rediger-une-
procedure-efficace
 http://www.antic.cm/index.php/cybersecurite/9-securite/246-laudit-de-securite
 http://fr.wikipedia.org/wiki/Audit_de_securite
 http://fr.wikipedia.org/wiki/ISO/CEI_27002
 http://fr.wikipedia.org/wiki/Kali_linux
 http://fr.wikipedia.org/wiki/Nessus
 http://www.coyotus.com/viewtopic.php?id=418
 www.ameliorationcontinue.fr/rapport-audit
 http://www.institut-numerique.org/i-demarche-delaboration-dun-manuel-de-
procedures-51e903d47f09f
 http://www.memoireonline.com/10/12/6356/m_elaboration-de-la-procedure-de-
gestion-de-cartes-Cas-de-la-Banque-Atlantique-Cte-dIvoire3.html
174

Manuel de Procédures D'audit de Sécurité2

Transféré par

Droits d'auteur :

Formats disponibles

Manuel de Procédures D'audit de Sécurité2

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

Manuel de Procédures D'audit de Sécurité2

Transféré par

Droits d'auteur :

Formats disponibles

2014

NDONGMO TONZEU ALEX L.

 Le présent manuel décrit l'organisation, les procédures d’audit de sécurité d’un

 Si les aspects techniques mentionnés dans ce document peuvent devenir obsolètes,

 Conformément aux usages, nous avons laissé en anglais un certain nombre de

LISTE DES FIGURES........................................................................................................................ 5

LISTE DES TABLEAUX .................................................................................................................... 6

LISTE DES SIGLES ET ABREVIATIONS .............................................................................................. 7

INTRODUCTION: CONTEXTE .......................................................................................................... 9

PARTIE I : DESCRITION DU MANUEL ................................................................................ 10

I.1 OBJECTIFS DU MANUEL ................................................................................................................ 11

PARTIE II : AUDIT DE SECURITE DES SYSTEMES D’INFORMATION AU CAMEROUN

II.1 C’EST QUOI L’AUDIT DE SECURITE D’UN SI ?................................................................................ 15

PARTIE III : REFERENTIELS D’AUDIT DE SECURITE DES SI ......................................... 19

III.1 INTRODUCTION .......................................................................................................................... 20

III.4 LA SUITE DES NORMES ISO 2700X .............................................................................................. 24

PARTIE IV : DEMARCHE DE REALISATION D’UNE MISSION D’AUDIT DE SECURITE

IV.1 CYCLE DE VIE DE L’AUDIT DE SECURITE D’UN SI.......................................................................... 52

ANNEXE 1 : QUESTIONNAIRE D’AUDIT ..................................................................................................... 105

Liste des Figures

Liste des Tableaux

Liste des sigles et abréviations

AESC: American Engineering Standards Committee

AFNOR: Association Française de Normalisation

ANSSI: Agence Nationale de la Sécurité des Systèmes d’Information

ANTIC : Agence Nationale des Technologies de l’Information et de la

ARP: Address Resolution Protocol

ASA: American Standards Association

BSI: British Standards Institute

CEI : Commission Electrotechnique Internationale

CEN : Comité Européen de Normalisation

CLUSIF: Club de la Sécurité de l’Information Français

CMM: Capability Maturity Model

DNS: Domain Name System

EBIOS : Expression des Besoin et Identification des Objectifs Spécifique

HIDS: Host Intrusion Detection System

HTTP: HyperText Transfer Protocol

IEEE: Institute of Electrical and Electronics Engineers

IP: Internet Protocol

IPS: Intrusion Prevention System

ISO : organisation internationale de normalisation

JTC : Joint Technical Committee

MEHARI: Méthode Harmonisée d’Analyse des Risques.

NDIS: Network Intrusion Detection System

Nmap: Network Mapper

OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation

OHSAS: Occupational Health and Safety Assessment Series

PCAP: Packet Capture

PDCA: « Plan » « Do » « Act » « Check »

POP: Post Office Protocol

RATS: Rough Auditing Tool for Security

RSSI: Responsable de Sécurité du Système d’Information

SGSI : Système de Gestion de la Sécurité de l’information

SMQ : Système de Management de la Qualité

SMSI : Système de Management de la Sécurité de l’Information

SMTP: Simple Mail Transfer Protocol

SoA: Statement of Applicability

SSH: Secure Shell

TCP: Transmission Control Protocol