mehari report vue2704
Post on 09-Feb-2016
302 Views
Preview:
TRANSCRIPT
Dédicace
A mes chers parents,
Que j’aime le plus et qui m’ont donné tous, que dieu les protègent
Ma chère sœur et mon cher frère,
Je vous remercie pour votre aide et votre patience
A mon cher fiancé,
Dont je ne trouve pas les mots pour lui exprimer ma gratitude, pour sa
patience et ses encouragements
A mes amis,
A tous ceux qui m’ont aidé à réaliser ce projet
Remerciements
Je tiens à remercier particulièrement Monsieur Yassine KHLIFI qui m’a encadré tout
au long de ce mastère pour sa grande disponibilité, pour l’intérêt qu’il a porté pour ce travail
et pour son aide permanente et aussi pour ses compétences scientifiques et ses qualités
humaines tout au long de ce travail.
Mes plus vifs remerciements s’adressent aussi à mon encadreur au sein du centre
informatique du ministère de la santé publique, Monsieur Faouzi LAROUCHI pour son
bienveillance, son soutien et ses conseils qui m’ont été d’un grand secours durant ce stage.
Qu’il soit aussi remercié pour sa gentillesse, pour les nombreux encouragements qu’il m’a
prodiguée.
Je souhaite aussi exprimer toute ma reconnaissance à Monsieur Faouzi DAHMEN dont ses
conseils et ses encouragements m’ont été d’une grande motivation.
Je suis très reconnaissante à Monsieur Makrem BOUABDALLAH et Monsieur Brahim
HAMDI pour leurs supports et leur aide.
Je tiens également à exprimer mes vifs respects à tous les personnels de l'institut supérieur de
Gestion de Tunis (ISG), et aux enseignants pour leurs efforts fournis durant mes études.
Enfin, tous les membres du CIMSP sont associés à mes remerciements. Qu’ils ne me tiennent
pas rigueur de ne pas pouvoir tous les citer. J’espère que toutes les personnes avec lesquelles
j’ai eu le plaisir de travailler savent à quel point je leur suis reconnaissante.
Table des matières
TABLE DES FIGURES ........................................................................................................... 7
LISTE DES TABLEAUX ........................................................................................................ 8
INTRODUCTION GENERALE ............................................................................................. 9
CHAPITRE 1 ......................................................................................................................... 11
CONCEPTS GENERAUX DE LA SECURITE ................................................................. 11
1.1 Introduction ................................................................................................................. 11
1.2 La sécurité informatique............................................................................................. 11 1.2.1 Sécurité de l’information ........................................................................................... 11
1.2.2 Sécurité des systèmes d’information ......................................................................... 12
1.2.3 Etude des risques ....................................................................................................... 13
1.2.4 Objectif de la sécurité ................................................................................................ 16
1.2.5 Politique de sécurité (PSSI)....................................................................................... 16
1.3 Audit informatique ...................................................................................................... 19 1.3.1 Notion d’audit ........................................................................................................... 19
1.3.2 Types d’audit ............................................................................................................. 20
1.3.3 L’objectif de l’audit ................................................................................................... 20
1.3.4 Les normes et les méthodes d’audit .......................................................................... 21
1.4 Analyse et discussion ................................................................................................... 25
1.5 Choix de la méthode MEHARI .................................................................................. 26
1.6 Conclusion .................................................................................................................... 27
CHAPITRE 2 ......................................................................................................................... 28
ETUDE DE L’EXISTANT ................................................................................................... 28
2.1 Introduction ................................................................................................................. 28
2.2 Présentation du CIMSP .............................................................................................. 28 2.2.1 Présentation générale du CIMSP ............................................................................... 28
2.2.2 Missions du CIMSP .................................................................................................. 28
2.2.3 Organisation du CIMSP ............................................................................................ 29
2.3 Présentation de l’architecture réseau du CIMSP ..................................................... 33 2.3.1 Architecture du réseau nationale de santé ................................................................. 33
2.3.2 Architecture locale des établissements de santé ........................................................ 35
2.3.3 Le Backbone CIMSP ................................................................................................. 36
2.4 L’existant en matière de sécurité ............................................................................... 36
2.5 Conclusion .................................................................................................................... 38
CHAPITRE 3 ......................................................................................................................... 39
AUDIT ORGANISATIONNEL ET PHYSIQUE ............................................................... 39
3.1 Introduction ................................................................................................................. 39
3.2 Objectifs ....................................................................................................................... 39
3.3 Approche adoptée ........................................................................................................ 39
3.4 Détermination des personnes à interroger ................................................................ 40
3.5 Analyse de questionnaire d’audit ............................................................................... 40
3.5.1 Elaboration du schéma d’audit .................................................................................. 40
3.5.2 Evaluation de la qualité des services basées sur les questionnaires MEHARI ...... 41
3.5.3 La synthèse par domaines de sécurité ....................................................................... 44
3.6 La convergence vers la norme ISO 17799 ................................................................. 46
3.6.1 Le niveau de maturité par principe ........................................................................... 46
3.6.2 Niveau de maturité par chapitre ................................................................................ 48
3.6.3 Représentation graphique .......................................................................................... 49
3.7 Synthèse des vulnérabilités ......................................................................................... 49
3.8 Conclusion .................................................................................................................... 56
CHAPITRE 4 ......................................................................................................................... 57
ANALYSE DES RISQUES ................................................................................................... 57
4.1 Introduction ................................................................................................................. 57
4.2 Présentation de la méthode d’analyse de risques ..................................................... 57
4.3 Analyse des risques suite à une analyse des enjeux .................................................. 57 4.3.1 Utilité d’une analyse des enjeux ................................................................................ 58
4.3.2 Objectifs de l’analyse des enjeux .............................................................................. 58
4.3.3 Expression des enjeux : Echelle de valeur des dysfonctionnements et classification 58
4.3.4 Gravité des dysfonctionnements majeurs .................................................................. 81
4.4 Analyse des risques à partir des bases de connaissance de MEHARI .................... 82
4.4.1 Le scénario de risque ................................................................................................. 82
4.4.2 Analyse d’un scénario de risque ................................................................................ 82
4.5 Conclusion .................................................................................................................... 92
CHAPITRE 5 ......................................................................................................................... 93
AUDIT TECHNIQUE ........................................................................................................... 93
5.1 Introduction ................................................................................................................. 93
5.2 Outils d’audit utilisés .................................................................................................. 93
5.3 Description de la salle machine .................................................................................. 94
5.4 Audit de l’architecture réseau .................................................................................... 94 5.4.1 Reconnaissance du réseau et du plan d’adressage ..................................................... 97
5.4.2 Sondage des systèmes ............................................................................................... 99
5.4.3 Sondage des services réseau .................................................................................... 103
5.4.4 Sondage des flux réseau .......................................................................................... 104
5.5 Audit des vulnérabilités ............................................................................................ 105 5.5.1 Audit des vulnérabilités intrusif interne .................................................................. 106
5.5.2 Audit de vulnérabilités intrusif externe ................................................................... 110
5.6 Audit de l’architecture de la sécurité existante ...................................................... 110 5.6.1 Audit du pare-feu et des règles de filtrages ............................................................. 110
5.6.2 Audit des routeurs ................................................................................................... 112
5.7 Audit des systèmes et des applications .................................................................... 114 5.7.1 Audit LOTUS NOTES ............................................................................................ 114
5.7.2 Audit système d’exploitation UNIX ....................................................................... 115
5.8 Conclusion .................................................................................................................. 119
CHAPITRE 6 ....................................................................................................................... 120
RECOMMANDATIONS ET PLAN D’ACTION ............................................................. 120
6.1 Introduction ............................................................................................................... 120
6.2 Les recommandations ............................................................................................... 120 6.2.1 Recommandations organisationnelles et physiques ................................................ 120
6.2.2 Recommandations techniques ................................................................................. 127
6.3 Plan d’action .............................................................................................................. 129
6.4 Conclusion .................................................................................................................. 133
CONCLUSION GENERALE ............................................................................................. 134
LISTE DES ACRONYMES ............................................................................................... 136
REFERENCES BIBLIOGRAPHIQUES .......................................................................... 138
Table des Figures
Figure 1.1.Place de la PSSI dans le référentiel documentaire. ................................................................. 18
Figure 2.1.Organigramme CIMSP. ....................................................................................................... 32
Figure 2.2.Réseau national du CIMSP. ................................................................................................. 33
Figure 2.3.Architecture globale du réseau national de la santé. ............................................................ 34
Figure 2.4.Architecture du réseau local d’un établissement de la santé. ............................................... 35
Figure 3.1.Représentation graphique des domaines MEHARI et leurs moyennes. .............................. 44
Figure 3.2.Représentation graphique du niveau de maturité. ................................................................ 49
Figure 4.1.Processus d'analyse des enjeux. ........................................................................................... 59
Figure 4.2.Processus d'analyse des risques. .......................................................................................... 82
Figure 4.3.Les mesures de la potentialité. ............................................................................................. 85
Figure 4.4.Les mesures de l'impact. ...................................................................................................... 88
Figure 4.5.Grille d'évaluation de la gravité. .......................................................................................... 89
Figure 4.6.Représentation graphique des besoins des services. ............................................................ 91
Figure 5.1.Architecture globale du CIMSP. .......................................................................................... 95
Figure 5.2.Cartographie du réseau interne du CIMSP. ......................................................................... 97
Figure 5.3.Image écran de configuration réseau au niveau du poste. .................................................... 99
Figure 5.4.Répartitions systèmes d'exploitation. ................................................................................... 99
Figure 5.5.Sondage GFI LanGuard. .................................................................................................... 101
Figure 5.6.Répartition du service NETBIOS sur les postes du CIMSP. ............................................. 102
Figure 5.7.Capture écran des partages réseau. .................................................................................... 102
Figure 5.8.Capture écran des fichiers partagés non protégés. ............................................................. 103
Figure 5.9.Scan Nmap. ........................................................................................................................ 104
Figure 5.10.Capture écran du trafic réseau. ......................................................................................... 105
Figure 5.11.Les pourcentages des vulnérabilités. ................................................................................ 106
Figure 5.12.Synthèse des vulnérabilités. ............................................................................................. 106
Figure 5. 13.Pourcentage des vulnérabilités. ....................................................................................... 107
Figure 5.14.Synthèse des vulnérabilités. ............................................................................................. 108
Figure 5.15.Pourcentage des vulnérabilités. ........................................................................................ 109
Figure 5.16.Synthèse des vulnérabilités. ............................................................................................. 109
Liste des Tableaux
Tableau 3.1.Schéma d'audit. .................................................................................................................. 41
Tableau 3.2.Questionnaire MEHARI. ................................................................................................... 42
Tableau 3.3.Moyennes des domaines de sécurité et des services. ......................................................... 45
Tableau 3.4.Niveau de maturité par principe. ....................................................................................... 48
Tableau 3.5.Niveau de maturité par chapitre. ........................................................................................ 48
Tableau 4. 1.Processus majeurs du CIMSP. .......................................................................................... 60
Tableau 4. 2.Processus et activités du DERSS. ..................................................................................... 67
Tableau 4.3.Dysfonctionnements et conséquences des activités de la DERSS. .................................... 70
Tableau 4. 4.Echelle de valeurs des dysfonctionnements globale. ........................................................ 74
Tableau 4. 5.Classification globale des ressources. ............................................................................. 80
Tableau 4.6.Evaluation de la gravité. .................................................................................................... 81
Tableau 4.7.Exposition naturelle. .......................................................................................................... 84
Tableau 4.8.Impact intrinsèque. ............................................................................................................ 87
Tableau 4.9.Priorités des besoins des services. ..................................................................................... 90
Tableau 5.1.Le plan d'adressage IP. ...................................................................................................... 98
Tableau 5. 2.Description des routeurs du CIMSP. .............................................................................. 113
Tableau 5.3.Liste de contrôle LOTUS NOTES................................................................................... 115
Tableau 5. 4..Liste de contrôle du système d’exploitation UNIX. ....................................................... 119
Tableau 6.1.Plan d'action. ................................................................................................................... 132
Introduction générale
9
Introduction générale
Toute entreprise, département d’entreprise, organisation, association, doit son
existence à son système d’information (SI) qui font désormais partie intégrante du leurs
fonctionnement. Un constat aujourd’hui, est que les SI sont de plus en plus ouverts au monde
extérieur, les équipements informatiques et de communication possèdent des capacités de
communication énormes. En parallèle, il y a eu un développement immense des nouvelles
menaces, telles que les virus et outils d’attaques, qui exploitant les failles de l’introduction
rapides des nouvelles technologies. Ces failles rendent vulnérables les différents composants
du SI et peuvent avoir des effets négatifs sur le bon fonctionnement et la rentabilité de
l’organisme. Mais les organismes qui réussissent sont celles qui comprennent et gèrent les
risques associés à la mise en œuvre de ces nouvelles technologies. Alors, la sécurité du SI
devient le principe sur lequel doit se baser toute organisation informatique. D’où le besoin de
faire appel à l’audit informatique pour maintenir la sécurité des SI.
L’audit de sécurité du SI vise à donner une cartographie complète des vulnérabilités et à
valider les moyens de protection mis en œuvre sur les plans organisationnels, procéduraux et
techniques, au regard de la politique de sécurité. Autrement dit, l’audit permet d’examiner une
situation et réaliser un bilan précis de l’existant sans prendre en considérations les mesures de
protection existantes. Actuellement en Tunisie, toute organisme est tenue par une obligation
légale à mener des missions d’audit conformément à l’article 5 de la loi tunisienne n°2004-5
du 3 février 2004, relative à la sécurité informatique qui stipule que les systèmes
informatiques et les réseaux des diverses entreprises publiques doivent être soumis à un
régime d’audit obligatoire et périodique de la sécurité informatique. Conscient de
l’importance de l’audit de sécurité du SI, le centre informatique du ministère de la santé
publique (CIMSP) s’oriente à auditer son système en vue de déceler les vulnérabilités et les
limites sur les plans organisationnels, physique et technique, et d’identifier les solutions et les
mesures correctives nécessaires.
Ce travail d’audit est organisé en 6 chapitres : Dans le premier chapitre, on va présenter les
concepts de base des SI ainsi que les risques qui menacent ces systèmes. Ce chapitre
contiendra aussi une introduction du concept d’audit informatique avec les méthodes et les
normes d’audit les plus connues et exploitées. Une étude comparative des méthodes
présentées sera élaborée afin de choisir la méthode la plus adéquate à la mission d’audit de
CIMSP. Dans le deuxième chapitre, on va focaliser la présentation de l’organisme d’accueil
Introduction générale
10
en mettant l’accent sur les missions exercées par son organisation générale, son architecture
du réseau nationale et l’architecture locale des établissements de santé sous tutelle. Enfin, ce
chapitre sera clôturé par une présentation des mesures de sécurité appliquées au sein du centre
dont leur existence ne sera pas prise en considération puisqu’ils vont être audités durant la
phase d’audit organisationnel et physique. Le troisième chapitre représente le point de départ
de cette mission d’audit étant donné qu’il met l’accent sur la première phase d’audit de
sécurité à savoir l’audit organisationnel et physique. Suite l’orientation issue de l’étude
comparative, la méthode MEHARI sera appliquée dans ce travail d’audit. En effet, des
entretiens et des réunions avec les responsables et le personnel du CIMSP seront établies
autour des domaines de sécurité afin déceler les vulnérabilités au sein du SI du centre. Vue
que la méthode MEHARI donne la main de converger vers la norme ISO 17799/27002, on va
déterminer le niveau de maturité de notre système audité selon l’échelle internationales à
partir du ‘Scoring’ ISO que cette méthode accorde. Le quatrième chapitre s’intéresse à
l’analyse de risques qui peut être menée avec deux approches complémentaires selon la
méthode MEHARI. Une analyse des risques directe à partir d’une analyse des enjeux du
centre et une analyse des risques selon les bases de connaissance de MEHARI. D’abord, on
va analyser le travail selon ces deux approches pour arriver à la fin à une analyse rigoureuse et
détailler des risques encouru par le centre. Dans le cinquième chapitre, on va essayer de
recenser les vulnérabilités et les failles d’ordre technique en auditant l’architecture du système
à savoir reconnaissance du réseau et du plan d’adressage, sondage des systèmes, contrôle
d’accès, sondage des services réseaux, et sondage des flux réseau. Ensuite, on va identifier les
vulnérabilités au niveau des composants du réseau audité tels que les serveurs et les postes de
travail. Sachant que dans l’étape d’audit de l’architecture de sécurité existante, on va auditer
plusieurs équipements tels que les pare-feux et les routeurs ainsi que plusieurs systèmes à
savoir le système de messagerie interne, Lotus notes, et du système d’exploitation Unix.
Après ces deux phases d’audits primordiaux, on va clôturer ce travail par la phase des
recommandations et du plan d’action. Les recommandations intéressent l’ordre
organisationnel, physique et technique afin de pallier aux défaillances identifiées au sein de
l’entreprise d’accueil. Alors que le plan d’action va présenter les opérations indispensables
pour le centre dont elles seront classées selon les priorités, et les moyens financiers et
humaines disponibles.
Chapitre 1 Concepts généraux de la sécurité
11
Chapitre 1
Concepts généraux de la sécurité
1.1 Introduction
Le concept de la sécurité s'applique à toute information. En fait, la sécurité concerne la
protection des actifs de valeur contre la perte, la divulgation ou les dégâts. Dans ce contexte,
les actifs de valeur sont les données ou les informations stockées, traitées, partagées,
transmises ou extraites à partir d'un support électronique. Les données ou les informations
doivent être protégées contre les menaces qui conduisent à la perte, l'inaccessibilité,
l'altération ou la divulgation inappropriée. La protection est obtenue au moyen d'un ensemble
de couches de parades techniques ou non techniques, telles que des mesures de sécurité
physique, des contrôles de bases, l'identification des utilisateurs, les mots de passe, les cartes à
puce, les techniques biométriques, pare-feu,…etc. La sécurité s'applique à toute information
en plus le concept de sécurité se résume à l'objectif de sécurité. Dans ce chapitre, on va
présenter les concepts généraux de la sécurité, la sécurité de l’information et la sécurité des
systèmes d’information ainsi les risques qui menacent les systèmes d’information. De même,
on va survoler les concepts de base d’audit informatique, ses normes et ses méthodes. Enfin,
une étude comparative des méthodes d’audit présentées sera élaborée suivi d’une discussion
afin de s’orienter vers une méthode d’audit efficace et adaptée à notre système d’information.
1.2 La sécurité informatique
La sécurité informatique comprend deux grands domaines qui sont la sécurité de
l’information et la sécurité des systèmes d’information. Dans cette section, on va essayer de
détailler chacun de ces domaines.
1.2.1 Sécurité de l’information
L’information est un actif aussi important que les actifs liés au système de production
classique à savoir actifs physiques, actifs financiers, actifs sociaux,….etc. L’information en
générale se présente sous trois formes sont les suivantes : les données, les connaissances et les
messages. D’habitude, ce sont ‘les actifs traditionnels’ qui sont protégés, la sécurité de
Chapitre 1 Concepts généraux de la sécurité
12
l’information n’est généralement garantie que de manière partielle et peu coordonnée dans les
entreprises et les organismes. La sécurité de l’information est définie comme étant un
dispositif global dont la mise en œuvre assure que l’information sera partagée d’une façon qui
garantit un niveau approprié de protection.
1.2.2 Sécurité des systèmes d’information
Avant de définir la sécurité des SI, il est primordial de définir un système
d’information. Plusieurs définitions SI existaient pour cela, on va essayer de présenter dans
ce qui suit une panoplie de définitions.
‘SI est l’ensemble des moyens techniques et humains qui permet de stocker, de
traiter ou de transmettre l’information ’ [1].
‘SI est tout moyen dont le fonctionnement fait appel d’une façon ou d’une autre à
l’électricité et qui est destiné à élaborer, traiter, stocker, acheminer, présenter ou détruire
l’information’ [2].
‘SI est une infrastructure de gestion électronique de l’information ’ [3].
‘SI est un ensemble d’ordinateurs et un ensemble de réseaux de communication’ [4].
1.2.2.1 Les composantes du système d’information
Un SI repose sur les éléments, fonctions et informations, qui constituent la valeur
ajoutée du SI pour l’organisme. Un inventaire permet de connaitre son environnement et
suppose un recensement exhaustif et précis. Ils sont les suivants :
Le matériel : les postes de travail, les serveurs, les routeurs, les systèmes
d’impression,…etc.
Les logiciels : les systèmes techniques, les systèmes bureautiques, les systèmes
administratifs et de gestion, les systèmes d’exploitation, les systèmes de
sécurité,…etc.
Les données : les données techniques, les données de gestion et les sauvegardes,…etc.
Le personnel : les utilisateurs identifiés, les administrateurs (informaticien ou
équivalent) et les stagiaires,…etc.
La documentation : les procédures d’installation, les procédures de restauration, la
politique sécurité de l’entreprise, le plan de sécurité et le plan de câblage,…etc.
Les SI sont devenus de nos jours indispensables à toute organisation moderne. Au
cœur du bon fonctionnement des entreprises et des grands corps de l’Etat, ils
Chapitre 1 Concepts généraux de la sécurité
13
constituent une cible d’attaques informatiques privilégiée (par virus, intrusions,
usurpation d’identité,…etc.) dont l’impact peut être extrêmement préjudiciable à
l’’organisation. En plus, la divulgation des secrets industriels, d’un savoir-faire ou
d’informations commerciales menace la vie même d’une entreprise et affecte ses
résultats financiers. D’où le besoin vital de mettre en œuvre un ensemble de moyens
pour minimiser la vulnérabilité d’un système contre ces menaces accidentelles ou
intentionnelles, autrement dit contre les risques informatiques.
1.2.3 Etude des risques
Le risque peut être défini comme étant la menace que représente l’exploitation d’une
vulnérabilité du système. Il s’agit donc de minimiser les risques inhérents au fonctionnement
d’un système d’information.
Vulnérabilité : elle signifie une faiblesse de sécurité. Cette faiblesse peut être logique, c.-
à-d. elle peut découler d’une mauvaise configuration d’une ou plusieurs composantes du
système ou d’une erreur de programmation qui peut être exploitée afin de nuire à
l’application, ou physique, qui peut avoir comme origine une insuffisance de moyens de
protection physique, comme laisser la porte du salle serveur ouverte et ne pas même
utilisé des moyens de surveillance.
Menace : elle est un danger qui existe dans l’environnement d’un système
indépendamment de celui-ci: accident, erreur et malveillance. La menace désigne
l’exploitation d’une faiblesse de sécurité par un attaquant, qu’il soit interne ou externe à
l’organisme. Ainsi, elle est l’ensemble des actions de l’environnement d’un système
entraînant l’incohérence dans la confidentialité, l’intégrité ou la disponibilité des services
et des biens. La menace est la résultante d’actions et opérations du fait d’autrui de plus
elle est indépendante de la protection dont se doter.
Les pannes et les erreurs non intentionnelles sont les suivantes:
pannes/dysfonctionnements du matériel.
pannes/dysfonctionnements du logiciel de base.
erreurs d’exploitation, oubli de sauvegarde, écrasement de fichiers.
erreurs de manipulation des informations.
erreurs de saisie, erreur de transmission, erreur d’utilisation.
erreur de conception des applications.
erreur d’implémentation.
Chapitre 1 Concepts généraux de la sécurité
14
Les menaces intentionnelles : l’ensemble d’action malveillante qui constitue la plus
grosse partie du risque qui devrait être l’objet principal des mesures de protection.
Les menaces passives : détournement des données, à savoir l’écoute et les
indiscrétions, par exemple l’espionnage industriel, l’espionnage commercial,
violations déontologiques et détournement des logiciels.
Les menaces actives : c’est toute forme de modification des informations.
Autre menaces : tout ce qui peut entrainer des pertes financières dans une société telle
que pertes associées à l’organisation et à la gestion des personnels ainsi départ de
personnels stratégiques et grèves.
Le risque : il est représenté par la probabilité qu’une menace particulière puisse exploiter une
vulnérabilité donnée du système. Traiter le risque, c’est prendre en compte les menaces et les
vulnérabilités.
Une information présente une certaine vulnérabilité, on lui assure un niveau de protection, qui
a un certain coût. L’écart entre la menace virtuelle et son niveau de protection correspond au
risque qui peut être accepté ou résiduel.
1.2.3.1 Types de risque
Les risques que peuvent avoir un SI peuvent être regroupés sous trois types sont les
suivants:
Accidents : ce type de risque peut être causé par des problèmes physiques ou des
mauvais fonctionnements des systèmes exemples tels que coupure de courant,
incendies, inondation, usurpations matérielles et panne de composants matériels.
Faute : ce type de risque peut être causé par des erreurs d’administration, des erreurs
de conceptions ou des erreurs de transmission,…etc.
Malveillance : ce type de risque peut être engendré par les risques de détournement
d’information ou la révélation d’un secret. On peut citer comme exemple un écouteur
de réseau qui veut capter un mot de passe et les menaces prévenant des pirates.
1.2.3.2 Les attaques
Une attaque est une entrave volontaire portant atteinte aux ressources informatiques et
résultantes d’une activité humaine.
Destruction par virus : c’est un programme de taille limitée qui possède la faculté de
s’introduire dans un programme hôte, et de s’auto-reproduire chaque fois que celui-ci
Chapitre 1 Concepts généraux de la sécurité
15
démarre. Son but est généralement de détruire ou de falsifier des fichiers de données
ou des fichiers de système d’exploitation.
Destruction par ver : c’est un programme malicieux qui a la faculté de se déplacer à
travers un réseau qu’il cherche à perturber en le rendant indisponible.
Destruction par bombe logicielles : il s’agit d’un programme indépendant dont le rôle
est de relâcher dans un système, à une date donnée ou à l’occurrence d’un événement
particulier, le programme de type ver (Worm) ou autre qu’il contient.
Intrusion par cheval de Troie : il s’agit de placer un programme dans un système de
façon à fournir un accès ultérieur privilégié et incontrôlable.
Intrusion par portes dérobées : le concepteur d’un programme peut laisser un accès lui
permettant de s’introduire dans le système à l’insu de tout contrôle.
Intrusion par Spoofing de paquets : usurpation d’adresses IP autorisées en prenant la
place d’une machine de confiance.
Espionnage des liaisons ou analyse de trafic : la capture des données circulant sur le
réseau permet d’intercepter les mots de passe.
Intrusion par bogues logiciels : les vulnérabilités des produits sont très vite connues.
Exploitation d’accès non sécurisés : on ne compte plus les utilisateurs sans mot de
passe ou très simple à deviner.
Refus d’accès, saturation de services (déni de service) : le « Distributed Denial of
Service » (DDoS) consiste à rendre une ressource inaccessible par saturation ou par
destruction. Cette attaque est souvent réalisée par un envoi massif de requêtes. Deux
techniques d’attaques communément appelées Smurf et Syn Flood sont possibles.
L’une comme l’autre consistent à inonder de demandes de connections l’ordinateur,
appelé serveur, permettant d’accéder à un site internet. Dans la technique du Syn
Flood, ces demandes sont assorties d’une adresse d’origine qui est fausse, ce que les
experts appellent le Spoofing, augmentant la confusion du serveur, suivi de son
engorgement voire de son arrêt.
Surveillance des messageries d’entreprises : le système d’information de l’entreprise
set de plus en plus lié à la messagerie d’entreprise.
Exploitation des fichiers de logs : l’analyse des fichiers de données révèle souvent de
précieux renseignements. Certains de ces fichiers gardent des traces de l’activité
réseau.
Chapitre 1 Concepts généraux de la sécurité
16
Man in the middle : technique qui consiste à se placer entre deux clients pour
intercepter, lire, modifier et effacer les données échangées.
1.2.4 Objectif de la sécurité
La sécurité des SI a pour objectif de protéger les intérêts de ceux qui dépendent des SI,
à savoir les entreprises et les organismes, et de communication qui délivrent l'information à sa
destination, contre les préjudices imputables à des défauts de disponibilité, de confidentialité,
et d'intégrité. La sécurité des SI vise alors à appliquer des mesures proportionnées aux risques
pouvant peser sur la confidentialité de l’information, son intégrité, sa disponibilité, la
possibilité d’en authentifier la source et de la signer.
La confidentialité : il s’agit de garantir que l’accès aux données n’est pas possible que
pour les personnes autorisées à les connaitre.
L’intégrité : il s’agit de garantir que les fonctions et les données sensibles ne sont pas
altérées ou modifié et conservent toute leur pertinence.
La disponibilité : il s’agit de garantir qu’une source sera accessible au moment précis
où quelqu’un souhaitera s’en servir.
L’authentification : a pour but de vérifier qu’une entité est bien celle qu’elle prétend
être.
La non-répudiation : vise à interdire à une entité de pouvoir nier avoir pris part à une
action.
Afin d’atteindre ces objectifs de sécurité, il est nécessaire de mettre en œuvre une politique de
sécurité, applicable à l’ensemble des entités à l’intérieur d’un domaine géographique ou
fonctionnel qui explicitera l’ensemble des règles et des recommandations pour protéger les
ressources et les informations contre tout préjudice et également prévoir le cas de la faillite de
la protection.
1.2.5 Politique de sécurité (PSSI)
Parmi toutes les tâches qui incombent aux responsables de la sécurité des systèmes
d’information (RSSI) dans les organismes privés ou publics, celle qui consiste à bâtir une
politique de sécurité cohérente prenant compte des aspects humains, organisationnels et
juridiques est certainement la plus difficile. Déterminer une politique de sécurité, c’est définir
des objectifs (ce qu’il faut protéger), des procédures. La PSSI est le document de référence
définissant les objectifs poursuivis en matière de sécurité et les moyens mis en œuvre pour les
Chapitre 1 Concepts généraux de la sécurité
17
assurer. Elle définit un certain nombre de règles, de procédures et de bonnes pratiques
permettant d'assurer un niveau de sécurité conforme aux besoins de l'organisation.
Un tel document doit nécessairement être conduit comme un véritable projet associant des
représentants des utilisateurs et conduit au plus haut niveau de la hiérarchie, afin qu'il soit
accepté par tous. Lorsque la rédaction de la politique de sécurité est terminée, les clauses
concernant le personnel doivent leur être communiquées, afin de donner à la politique de
sécurité le maximum d'impact. Il est important de définir correctement les règles du modèle:
ce qui est autorisé et ce qui ne l’est pas (il est interdit de lire le courrier de son voisin sans y
être invité, même si celui-ci n’a pas su le protéger correctement,…etc.). Il est absurde mais on
le voit souvent de vouloir verrouiller les entrées, définir des interdictions alors qu’on n’a pas
su définir les règles auxquelles devraient se référer ces actions. La politique de sécurité est
élaborée comme suit : une analyse des menaces potentielles ou réelles, ensuite l’identification
et l’analyse des vulnérabilités (audit, contrôle qualité,…etc.).
Elle se réalise par :
l’intégration d’outils et de services de sécurité système ou réseau (audit, contrôle
d’accès identification, logiciel antivirus, systèmes experts et noyau de sécurité,…etc.).
la validation logiciel/système (techniques formelles, analyse qualimétrie, tests
statiques et dynamiques,…etc.).
l’évaluation et la certification des systèmes et des produits.
La sécurité ne doit pas rester statique car toute défense peut être contournée; c’est pourquoi
une bonne politique de sécurité comprend toujours deux volets:
La sécurité à priori ou plus précisément politique dite ‘passive’ : c’est le blindage
du système. Elle se caractérise par l’élaboration d’une politique de sécurité
explicite, une organisation adaptée à cette politique, des procédures des méthodes
de travail, des techniques et des outils,…etc.
La sécurité à posteriori ou plus clairement politique dite ‘active’ : c’est la défense
‘en profondeur’ dont elle consiste à mettre en place plusieurs processus telles que:
Surveiller les moyens de protection pour contrôler leur efficacité (mais aussi
l’efficacité de la politique de sécurité)
Détecter les attaques et les mauvaises configurations en enregistrant les accès
aux services sensibles, en mettant en place des automatismes de détection
d’intrusion,…etc.
Chapitre 1 Concepts généraux de la sécurité
18
Répondre par des actions correctives: arrêt de session, reconfiguration
dynamique des systèmes de contrôle d’accès et enregistrement des sessions
Mettre en place des leurres.
1.2.5.1 Place de la PSSI dans le référentiel documentaire
La PSSI est un élément de la politique générale de l'organisme et elle est en accord
avec le schéma directeur du SI et la stratégie de sécurité de l'information. La figure 1.1 met
en relief l'interférence du schéma directeur de l’organisme avec la PSSI globale ainsi que la
dérivation en politiques spécifiques.
Figure 1.1.Place de la PSSI dans le référentiel documentaire.
Bien qu’elle puisse concerner l’ensemble des systèmes d’information de l’organisme, elle
peut également être restreinte à un système d’information particulier, par exemple lié à un
métier de l’organisme ou à un système transversal tel que messagerie et intranet…etc. Dans ce
cas, il peut exister plusieurs PSSI dans un organisme ou une entreprise et elles devront être
cohérentes entre elles. Cette cohérence est assurée grâce à la formalisation d’une PSSI globale
ou plus précisément objet du présent guide. Les autres politiques sont alors des déclinaisons
de la PSSI dans un environnement métier ou technique particulière, pour des instances
spécialisées ou des cas particuliers. Pour élaborer une PSSI adaptée à l’organisme, il est
recommandé de réaliser une analyse des risques spécifiques au contexte afin d’en ajuster les
règles de sécurité.
Chapitre 1 Concepts généraux de la sécurité
19
1.3 Audit informatique
Historiquement, l’audit a envahi tous les domaines de la vie professionnelle à savoir,
économique, gestion, social et politique,…etc. l’audit de la sécurité informatique est une
technique relativement récente et qui vient d’être ornementé suite à l’adoption de plusieurs
normes de sécurité à l’échelle internationale depuis les années 90. Ces normes constituent un
label de confiance pour les entreprises leurs permettant des échanges de données en toute
sécurité.
1.3.1 Notion d’audit
L’audit informatique est un examen d’un SI, en tout ou partie, pour porter un jugement
sur celui-ci. Il consiste généralement à s’appuyer sur un tiers de confiance, plus précisément
généralement une société spécialisée en sécurité informatique, afin de valider les moyens de
protection mis en œuvre, au regard de la politique de sécurité. Un audit de sécurité
informatique est réalisé selon une approche bien définie et identifiée selon la collaboration des
audités c.à.d. les sites sur lesquels on applique l’audit.
Audit ‘Boite blanche’ : Un audit ‘ boite blanche’ est un audit de sécurité dont les
informations sont fournies par le client. Il permet de réaliser d’une manière totalement
transparente, une vue complète de la sécurité mise en place sur les plans technique et
organisationnel.
Audit ‘Boite noire’ : A l’inverse de l’audit ‘boite blanche’, l’audit ‘boite noire’ est un
audit de sécurité qui se fait à l’aveuglette. Le client ne donne pas d’informations
concernant son SI. Concrètement, un audit boite noire permet d’avoir une vue
complète de la sécurité sur le plan technique.
1.3.1.1 Phases d’audit sécurité informatique
La mission d’audit est subdivisée, principalement, en deux phases sont les suivantes :
L’audit organisationnel physique : il représente une approche méthodologique basée
sur une batterie de questions préétabli qu’on doit avoir les bonnes réponses après une
série de réunions avec les responsables. Ces questions doivent aboutir à une évaluation
indépendante et pragmatique des failles et des risques encourus au niveau du SI. Le
jeu de question, qui peut être énoncé, est de type : Qui s´occupe des sauvegardes ?
Comment sont-elles planifiées ? Qui a accès à la salle des serveurs ? Combien de jeux
de clés existe-t-il ? Qui les détient ? Qu´est-il prévu en cas de panne de courant ? Ces
Chapitre 1 Concepts généraux de la sécurité
20
questions sont classées par thèmes ou par domaine de sécurité à savoir sécurité
physique, contrôle d´accès, pannes et erreurs humaines,...etc. On n’est pas appelé à
créer ses propres questions mais plutôt d’utiliser celles qui proviennent des normes et
des méthodes reconnues à l’échelle internationale afin de suivre une méthodologie
formelle.
L’audit technique : il correspond à une suite logique de l’audit organisationnel qui sert
à découvrir les failles grâce à un ensemble de tests. En pratique, un audit technique
concerne les composants du système d’information. Il s’agit d’une validation d’une
architecture de sécurité, tests de vulnérabilités internes et/ou externe, validation du
code, tels que faille dans une application web, contrôle d’accès trivial…etc., et
validation de la sécurité d’un nouveau périmètre, à savoir un firewall, un site business,
d’un extranet et d’un accès Internet d’un système VPN.
Dans une approche idéale, l’audit technique suit une étude organisationnelle et physique
permettant d’avoir une vue globale de l’état de sécurité du système d’information et
d’identifier les risques potentiels. Ce n’est qu’après que l’on peut passer à la recherche de
vulnérabilités ou les tests intrusifs, internes et externes, qui peuvent analyser le niveau de
protection de l’infrastructure face aux attaques notamment celles qui exploitent des failles
logicielles connues.
1.3.2 Types d’audit
On distingue trois types d’audit sont les suivantes :
L’audit de vérification : il détermine la situation dans laquelle se trouve le SI plus
précisément l’organisation, la configuration, l’exploitation, les compétences, les
protocoles utilisés,…etc.
L’audit d’agrément : il permet de vérifier dans quelles mesures le système
d’information, les règles de contrôle interne et les moyens techniques sont conformes
à un référentiel prédéfini selon des normes et des méthodologies.
L’audit intrusif : il cherche à connaitre les failles du SI, à savoir accès aux serveurs,
politique des mots de passe,…etc., et les moyens de prévention et de protection mis en
place.
1.3.3 L’objectif de l’audit
Quel que soit le type de l’audit, interne ou externe, contractuel ou légal,…etc., la
finalité est toujours de porter un jugement sur le management du SI et l’exécution de ses
Chapitre 1 Concepts généraux de la sécurité
21
objectifs. Des audits sont nécessaires suite à la mise en place initiale d'une politique de
sécurité, puis régulièrement pour s'assurer que les mesures de sécurité sont mises à niveau et
que les usages restent conformes aux procédures. Il consiste encore à répondre aux
préoccupations concrètes de l’entreprise, notamment de ses besoins en sécurité, en
déterminant les déviations par rapport aux bonnes pratiques et en proposant des actions
d'amélioration du niveau de sécurité de son infrastructure informatique.
1.3.4 Les normes et les méthodes d’audit
Parmi toutes les tâches qui incombent aux R.S.S.I dans les organismes privés ou
publics, celle qui consiste à bâtir une politique des sécurité cohérente prenant en compte les
aspects humains, organisationnels et juridiques est certainement la plus difficile. Une telle
politique doit se baser sur une méthode bien spécifique. En effet, il existe de nombreuses
normes et méthodes sue les quelles se basent les missions d’audit de la sécurité des SI mais il
avait toujours une confusion entre norme et méthode pourtant le choix d’une ou plusieurs
normes et méthodes d’organisation ou d’évaluation de la sécurité s’avère indispensable pour
mettre en place une politique de sécurité cohérente, homogène et efficace au sein d’une
entreprise, a fortiori lorsqu’il s’agit d’un groupe décentralisé, multi métiers et international.
Une norme, organisationnelle ou technique, a un objet souvent très vaste et s’appuie
généralement sur des concepts ou des notions générales. Le champ d’application de chaque
concept doit alors être précisé pour que la norme puisse être appliquée efficacement [5]. Par
contre une méthode est un moyen d’arriver efficacement à un résultat souhaité et précis. Ce
souhait étant souvent formulé dans une norme, on voit que souvent la méthode sera l’outil
utilisé pour satisfaire à une norme [6].
1.3.4.1 Pourquoi choisir une norme ou une méthode ?
Le choix d’une norme ou d’une méthode de sécurité présente un certain nombre
d’avantages ; ce choix permet d’obtenir une vision globale et cohérente de la sécurité, de
fournir un référentiel et des concepts communs à tous les acteurs, de même, il permet d’avoir
un cadre commun pour gérer les risques, de proposer des parades adaptées aux risques, et
enfin d’améliorer la sensibilisation des utilisateurs.
Chapitre 1 Concepts généraux de la sécurité
22
1.3.4.2 Les méthodes d’audit
Dans cette sous-section, on va focaliser la présentation des méthodes d’audit les plus
répondues à savoir les méthodes EBIOS, MARION, MEHARI et CRAMM ainsi que le
référentiel COBIT.
a) Méthode EBIOS
EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) est une
méthode établie par la DCSSI (Direction Centrale de la Sécurité des Systèmes d'Information)
pour identifier les besoins de sécurité d'un SI. La DCSSI la présente comme un outil
d'arbitrage au sein des directions générales. Elle s'organise en 4 étapes principales sont les
suivantes :
Étude du contexte,
Expression des besoins,
Étude des risques,
Identification des objectifs de sécurité.
Elle se présente sous la forme d'une brochure téléchargeable et d'un logiciel dont l'obtention
est gratuite [7].
b) Référentiel COBIT
Bien connu des membres de l'ISACA, le référentiel de gouvernance des systèmes
d'information COBIT couvre une bonne partie des domaines de l'ISO 17799. COBIT étant à
vocation plus large, il gère l'information au travers un grand nombre de ‘critères’ à savoir
l’efficacité, efficience, confidentialité, intégrité, disponibilité, conformité et fiabilité. En
regard, l'ISO 17999 se limite à la confidentialité, l'intégrité la disponibilité et la conformité
[8].
c) MARION
La méthode MARION est une Méthodologie d’Analyse de Risques Informatiques
Orientée par Niveaux. Il s’agit d’une méthodologie d’audit, qui, comme son nom l’indique,
permet d’évaluer le niveau de sécurité d’une entreprise (les risques) au travers de
questionnaires pondérés donnant des indicateurs sous la forme de notes dans différents thèmes
concourant à la sécurité. L’objectif est d’obtenir une vision de l’entreprise auditée à la fois par
rapport à un niveau jugé « correct », et d’autre part par rapport aux entreprises ayant déjà
Chapitre 1 Concepts généraux de la sécurité
23
répondu au même questionnaire. Le niveau de sécurité est évalué suivant 27 indicateurs
répartis en 6 grands thèmes, chacun d’eux se voyant attribuer une note de 0 à 4, le niveau 3
étant le niveau à atteindre pour assurer une sécurité jugée correcte. A l’issue de cette analyse,
une analyse de risque plus détaillée est réalisée afin d’identifier les risques (menaces et
vulnérabilités) qui pèsent sur l’entreprise. La méthode se déroule en 4 phases distinctes sont
les suivantes:
Préparation : Durant cette phase, les objectifs de sécurité sont définis ainsi que le
champ d’action et le découpage fonctionnel permettant de mieux dérouler la méthode
par la suite.
Audit des vulnérabilités : cette phase voit le déroulement des questionnaires ainsi que
le recensement des contraintes propres à l’organisme.
Analyse des risques : cette phase voit l’exploitation des résultats précédente et permet
d’effectuer une ségrégation des risques en Risques Majeurs (RM) et Risques Simples
(RS).
Plan d’action : Durant cette ultime phase, une analyse des moyens à mettre en œuvre
est réalisée afin d’atteindre la note ‘3’, objectif de sécurité de la méthode, suite aux
questionnaires, les tâches sont ordonnancées, on indique le degré d’amélioration à
apporter et l’on effectue un chiffrage du coût de la mise en conformité [9].
d) CRAMM
C’est une méthode de gestion du risque imposé par le gouvernement britannique. Elle
est exhaustif contenant plus de 3000 points de contrôle et donc adaptée à de grosses
entreprises [10].
e) MEHARI
La méthode MEHARI (MEthode Harmonisée d'Analyse de RIsques) est proposée par
le CLUSIF (Club de la Sécurité des Systèmes d'Information Français). Elle est destinée à
permettre l'évaluation des risques mais également le contrôle et la gestion de la sécurité de
l'Entreprise sur court, moyen et long terme, quelle que soit la répartition géographique du
système d'information. La méthode MEHARI s'articule sur 3 types de plans :
Le PSS (Plan Stratégique de Sécurité) qui fixe les objectifs de sécurité et les métriques
et qualifie le niveau de gravité des risques encourus,
Chapitre 1 Concepts généraux de la sécurité
24
Les POS (Plans Opérationnels de Sécurité) qui déterminent, par site ou entité
géographique et les mesures de sécurité à mettre en place tout en assurant la cohérence
des actions choisies.
Le POE (Plan Opérationnel d'Entreprise) qui permet le pilotage de la sécurité au
niveau stratégique par la mise en place d'indicateurs et la remontée d'informations sur
les scénarios les plus critiques. MEHARI remplace MARION qui n'est plus
développée [11].
1.3.4.3 Les normes
Nous allons présenter quelques référentiels normatifs d’audit, la norme ISO17799, ISO
13335, ISO 27001 et ISO 27002.
a) ISO 17799
Le standard ISO 17799 est un ensemble de recommandations pour la gestion de la
sécurité de l'information issu de la norme britannique BS7799 (British Standard). Il couvre
autant les aspects techniques, administratifs que juridiques et peut être utilisé par n'importe
quel organisme quelque soit son activité et sa dimension. Ces aspects sont regroupés en dix
grandes thématiques [12].
b) ISO 13335
C’est un guide pour la gestion de la sécurité du réseau. Il est centré sur les principes de
la gestion de sécurité du réseau et sur la minière dont les organisations peuvent établir un
cadre pour protéger et gérer la sécurité des systèmes de technologies de l’information (TI)
[13].
c) ISO 27001
‘Specification for information Security management Systems’, élaborée par le British
Standard Institute (c’est la partie 2 du BS 7799). Elle explique comment appliquer ISO 17799
et impose une démarche pour l’établissement des phases d’implémentation, d’évaluation, de
maintenance et d’amélioration d’un système de management de la sécurité de l’information.
[14].
Chapitre 1 Concepts généraux de la sécurité
25
d) ISO 27002
La norme ISO/CEI 27002 est une norme internationale concernant la sécurité de
l'information, publiée en 2005 par l'ISO, intitulé ‘Code de bonnes pratiques pour la gestion de
la sécurité de l'information’. La norme ISO/CEI 27002 est composé de 15 chapitres dont 4
premiers introduisent la norme et les 11 chapitres suivants composés de 39 rubriques et 133
mesures dites ‘best practices’ qui couvrent le management de la sécurité aussi bien dans ses
aspects stratégiques que dans ses aspects opérationnels en réunissant les objectifs de sécurité
et les mesures à prendre [15].
1.4 Analyse et discussion
Dans ce qui précède, une étude bibliographique a été menée où on a présenté quelques
méthodologies d’audit de sécurité afin de choisir une méthode, en se basant sur des critères,
adapté aux objectifs de cette mission. Les critères de choix d’une méthode d’analyse des
risques sont très variés. Sachant qu’on peut fonder ce choix sur plusieurs critères objectifs à
savoir la facilité d’utilisation de la méthode, la complexité de son pragmatisme, sa
compatibilité avec les normes nationale ou internationale, son coût de mise en œuvre, la taille
de l’entreprise ou l’environnement de son implémentation en plus la langue de la méthode.
Car il est essentiel de maitriser le vocabulaire employé, la qualité de la documentation fournie
avec la méthode. De plus, ce choix peut se baser sur la popularité de la méthode puis qu’une
méthode très connue offre base solide de personnels qualifiés pour la mettre en œuvre.
Il existe environ 200 méthodes de gestion des risques dont plus de 80% sont abandonnées
comme les méthodes MELISA et MARION ou bien elles sont confidentielles. On a cité
précédemment les méthodes les plus utilisées et les plus répondues mais la question qui se
pose parmi ces méthodes quelle est la meilleure? La réponse dépend surtout du type de
l’entité audité et son domaine d’activité qui entrera en ligne de compte pour le choix de la
méthode appropriée. En effet, on peut choisir une méthode selon la nature du résultat
attendue puisque les méthodes d’analyse des risques peuvent avoir une approche qualitative
ou quantitative, ou une combinaison des deux en fonction des circonstances. L’estimation
qualitative utilise une échelle d’attributs qualificatifs pour décrire l’amplitude des
conséquences possibles, qui peuvent être faible, moyenne ou haute, et la probabilité que ces
conséquences surviennent. L’avantage majeur de l’estimation qualitative réside dans sa
compréhension aisée par tous les membres du personnel d’une organisation alors que son
inconvénient principal reste la dépendance au choix initial subjectif de l’échelle de
Chapitre 1 Concepts généraux de la sécurité
26
qualification. Quant l’estimation quantitative, elle utilise une échelle de valeurs numériques
pour évaluer les conséquences ainsi que la probabilité de leur survenance à l’aide de diverses
sources de données.
Mais chaque méthode a ses propres caractéristiques qui nous mène à choisir une méthode A et
non pas la méthode B. La méthode EBIOS, par exemple, malgré qu’elle est une méthode
d’analyse des risques, elle ne fournit pas de recommandations ni de solutions immédiates aux
problèmes de sécurité. Elle ne possède pas une démarche quantitative qui nous permet de
valoriser et mesurer le degré de risque pour arriver à le minimiser. EBIOS ne possède pas un
outil de contrôle et d’évaluation de la méthode, c’est une démarche lourde et difficile à utiliser
car elle distingue peu l’opérationnel ou les actifs de l’organisation du reste de l’organisation.
COBIT est un référentiel de bonnes pratiques pour cela elle n’est classifiée pas comme une
méthode. Il est plus orienté à la gouvernance des SI qu’au processus d’analyse des risques. En
plus, il ne possède pas de support logiciel ni une base de connaissance qui comporte les
questionnaires. La méthode MARION est très ancienne, elle a été abandonnée en 1980 au
profit de la méthode MEHARI. La méthode CRAMM est connue par son exhaustivité et sa
lourdeur, et elle est réservée aux grandes entreprises puisqu’elle recourt à près de 3000 points
de contrôle. Chacune des méthodes d’audit possède ses points forts et ses points faibles mais
dans ce qui suit on va choisir la méthode la plus répondue et la plus adapté pour notre mission
d’audit.
1.5 Choix de la méthode MEHARI
Retenir une norme ou une méthode est un choix souvent structuré et durable pour
l’entreprise concernant le coût, les ressources et l’organisation. L’entreprise doit faire au
préalable une analyse fine des ses besoins, de l’adéquation des méthodes existantes à ses
besoins et de ses ressources disponibles. Certaines entreprises préfèrent au contraire
développé des méthodologies plus spécifiques ou mieux adaptées à leurs besoins mais aussi
plus difficiles à entretenir et à faire évoluer. Selon notre contexte de travail et en tenant
compte de la spécificité du centre Informatique du Ministère de la Santé Publique (CIMSP),
on a choisi la méthode MEHARI pour notre mission d’audit vu que cette méthode est une
démarche qui fournit un cadre méthodologique, des techniques, des outils et des bases de
connaissances pour analyser et classifier les enjeux majeurs. En premier lieu, elle nous permet
d’étudier les vulnérabilités, réduire la gravité des risques et piloter la sécurité de
l’information. Le choix de cette méthode non pas parce qu’elle est la ‘bonne’ méthode de
management plutôt parce qu’elle a une démarche qui intègre tout le nécessaire. Cette
Chapitre 1 Concepts généraux de la sécurité
27
démarche permet d’étudier le contexte de l’entreprise à savoir ses enjeux, sa taille, son
organisation centralisée ou décentralisée, son caractère national ou international.
MEHARI comporte une riche palette de situations de risques et les moyens convenables pour
réduire leur gravité. Ceci nous mène à dire que la documentation MEHARI est complète et
modulaire vue la disponibilité de ses guides ou de ses manuels. Sa boite à outils et sa riche
base de connaissance sont bâtis pour permettre une analyse précise des risques dans des
différents contextes d’entreprises. C’est une méthode adaptable, souple de plus elle donne la
possibilité de décomposer le périmètre à étudier en fonction de plusieurs paramètres tel que
la criticité des données et des types de systèmes afin de se focaliser sur les environnements les
plus sensibles. Elle est structurée, compatible avec les modèles de gouvernance des risques et
respecte les aspects réglementaires et les contrôles ISO.
1.6 Conclusion
Dans ce chapitre, on a présenté les principaux concepts de base dans le domaine de
la sécurité informatique. D’abord, on a définie la sécurité de l’information et la sécurité des
systèmes d’informations. Ensuite, on a détaillé les principaux menaces et risques de la
sécurité, les objectifs de la sécurité et le but de mettre en place une politique de sécurité. En
plus, on a identifié la notion d’audit, ses objectifs et ses méthodes les plus connus. De même,
on a élaboré une étude comparative où on a analysé et discuté les normes, les méthodes, les
référentiels, ses avantages et ses inconvénients. Cette comparaison nous a permis de choisir la
méthode MEHARI selon les critères de base et selon les orientations de l’entreprise d’accueil.
Chapitre2 Etude de l’Existant
28
Chapitre 2
Etude de l’existant
2.1 Introduction
Dans ce chapitre, on va tout d’abord présenter l’organisme d’accueil, ses missions et
son organisation générale ainsi que l’architecture globale de son réseau national. Ensuite, on
va mettre l’accent sur son architecture locale des établissements de santé publique rattachés,
dont ils intègrent le Backbone national. Enfin, on va essayer d’identifier les mesures de
sécurité mise en place au sein de ce centre.
2.2 Présentation du CIMSP
Dans cette section, on va présenter l’établissement d’accueil, ses missions et son
organisation. Sachant que cette présentation comporte une description de toutes les directions
vitale du centre ainsi qu’une représentation de son organigramme.
2.2.1 Présentation générale du CIMSP
Cette mission d’audit se déroule au sein du CIMSP dont le siège social situé au 1, rue
de Liberia 1002 Tunis belvédère qui est un établissement public à caractère industriel et
commercial, doté de la personnalité civile et de l’autonomie financière. Il est crée en 1992 par
la loi N° 92-19 du 3 février 1992. Il est placé sous la tutelle du ministère de la santé publique.
Actuellement, il compte environ 134 employés répartis en ingénieurs, analystes et techniciens
supérieurs, ainsi que de personnel administratif. Le CIMSP, réputé commerçant dans ses
relations avec les tiers, est régi par la législation commerciale. D’où il est chargé de
l’élaboration et de la mise en œuvre du plan informatique du ministère de la santé publique et
des établissements sous tutelle.
2.2.2 Missions du CIMSP
Depuis l’année 1994, le Ministère de la Santé Publique (MSP) a entamé le projet de la
réforme hospitalière qui consiste essentiellement à moderniser les méthodes de gestion des
hôpitaux universitaires et ceci par leur conversion en Etablissement Public de Santé (EPS)
ayant leur autonomie financière et par l’utilisation des nouvelles technologies de l’information
Chapitre 2 Etude de l’Existant
29
et de communication. Le CIMSP a joué le rôle du maître d’œuvre dans ce projet. Ainsi, le
centre est chargé de mettre en place le système d’information hospitalier en assurant toutes les
étapes depuis l’étude jusqu’à la maintenance.
Etude, développement, installation et maintenance des applications du système
d’information hospitalier. En effet, depuis 1994 le Ministère de la Santé Publique a
entamé le projet de la réforme hospitalière qui consiste essentiellement à moderniser
les méthodes de gestion des hôpitaux universitaires et ceci par leur conversion en EPS
ayant leur autonomie financière et par l’utilisation des nouvelles technologies de
l’information et de communication. Le CIMSP a joué le rôle du maître d’œuvre dans
ce projet et il est chargé de mettre en place le système d’information hospitalier en
assurant toutes les étapes depuis l’étude jusqu’à la maintenance.
Exploitation et maintenance des réseaux et du matériel informatique du réseau national
de la santé (RNS). Le CIMSP est chargé d’administrer le réseau national de la santé en
veillant à sa bonne exploitation et en le protégeant contre les dangers internes et
externes. A l’état actuel, environ 60 établissements sont connectés au CIMSP via des
lignes spécialisées dont le débit allait de 64 Kbits/s à 4 Mo/s.
Formation dans les domaines de l’Internet et de la bureautique du personnel œuvrant
dans le secteur de la santé publique.
Fournisseur des services Internet du secteur de la santé publique. En plus des services
Internet (navigation, email), le CIMSP offre aux institutions de recherche relevant du
Ministère de la Santé Publique des accès haut débit (45 Mbits/s) aux réseaux de
recherche (GEANT, EUMEDCONNECT), aux revues de recherche électroniques et
aux bases de données spécialisées. D’autre part, le CIMSP a pu mettre en œuvre un
certain nombre de projets de télémédecine dont notamment la télé-radiologie, la télé-
pathologie, la visioconférence, etc.
2.2.3 Organisation du CIMSP
L'organisation générale du CIMP comprend plusieurs structures à savoir :
La Direction Générale représentée par son Directeur Général qui est chargée
notamment de présider le conseil d’établissement et d’assurer la direction
administrative, financière et technique.
L’unité d’audit interne : Elle est récemment construite. Elle est chargée d’évaluer et de
maintenir le niveau de qualité et de sécurité des services du CIMSP.
Chapitre 2 Etude de l’Existant
30
L’unité de formation : Elle a pour mission d’élaborer et mettre en exécution un plan de
formation spécifique, dans le domaine de l'informatique sanitaire, à l'intention des
personnels administratifs et médicaux concernées.
L’unité de contrôle de gestion : cette unité est chargée de la gestion budgétaire du
centre.
La Direction des Etudes et de Développements Informatiques (DEDI) : Elle est
chargée d’assurer les tâches suivantes :
Mettre en œuvre et actualiser les dispositions prévues dans le plan informatique et
veiller en particulier à son harmonisation avec les besoins d'autres départements ou
organismes concernés.
Elaborer des standards pour la conception, la réalisation et l'actualisation des
procédures et des logiciels de gestion informatisés dans les différentes structures
publiques de la santé.
Concevoir, mettre en place et gérer les banques de données et les statistiques
sanitaires nationales et particulièrement les données concernant la carte sanitaire.
Direction de l’exploitation, des réseaux, de la sécurité et de soutien (DERSS). Elle a
pour mission d’effectuer les tâches suivantes :
Veiller à l'optimisation des investissements et de l'exploitation des équipements et
des logiciels informatiques acquis par le MSP et des établissements sous tutelle. La
DERSS doit particulièrement veiller à l'homogénéité et à l'efficience de ces
équipements et logiciels et en assurer l'exploitation et la maintenance.
Identifier et couvrir les besoins du MSP et des établissements sous tutelle en
matière de traitement automatique des informations.
Assurer l'homogénéité, la fiabilité, la sécurité et la confidentialité du système
d'information des structures publiques de santé.
Donner des conseils et fournir des services en matière d'informatique hospitalière à
tout autre organisme sanitaire, public ou privé, national ou étranger, moyennant
rémunération.
La Direction des Affaires Administratives et Financières (DAAF) est chargée de la
gestion des ressources humaines, matérielles et financières du centre.
Chapitre 2 Etude de l’Existant
31
La figure 2.1 illustre l’organigramme du CIMSP sur lequel s’articule son système
organisationnel. Cette structure représente la nouvelle version qui est en cours de mise en
place dans la CIMSP depuis quelques mois.
32
Figure 2.1.Organigramme CIMSP.
Chapitre 2 Etude de l’Existant
33
2.3 Présentation de l’architecture réseau du CIMSP
L’architecture du réseau global du CIMSP est composée de deux types à savoir
l’architecture du réseau nationale de santé et l’architecture locale des établissements de santé.
Cette architecture globale intègre des liens avec le Backbone national qui relie le CIMSP avec
les établissements de santé.
2.3.1 Architecture du réseau nationale de santé
La figure 2.2 présente une vue globale sur le réseau national de la santé administré par
le CIMSP.
Figure 2.2.Réseau national du CIMSP.
Le service Réseaux du CIMSP gère l’infrastructure en matière des réseaux dont dispose les
établissements relevant du MSP. Cette infrastructure est composée essentiellement des
réseaux étendus (WAN) en étoile constituée d’environ 160 sites. Le CIMSP gère tout le trafic
échangé entre les différentes structures publiques de la santé puisque toutes les connexions
sont supervisées par le centre qui assure la gestion des connexions à haut débit. En effet, le
RNS est administré par le CIMSP, essentiellement par le service réseaux.
Chapitre 2 Etude de l’Existant
34
Ce réseau national connecte plusieurs établissements incluant le MSP, en plus le CIMSP est le
Fournisseur de Services Internet (FSI) à ses clients, qui sont les institutions relevant du
Ministère de la santé public, via l’Agence Tunisienne de l’Internet (ATI) par six lignes
spécialisées de 1 Mbps chacune. Le CIMSP propose différents types de connexions aux
établissements sanitaires. Le choix se fait selon la localisation géographique de
l’établissement ainsi que l’étendu de son réseau en terme de machines connectées.
La liaison spécialisée (LS) : Les différentes institutions sont reliées au CIMSP via des
LS. Ce type de liaison permet de disposer d'un réseau de communication permanent.
De même, il permet d'échanger tous type de données par un canal unique
exclusivement réservé à la santé public. Ce trafic peut être des données informatiques,
photo, vidéo (visioconférence), et fax…etc.
Tout le trafic du RNS passe par le CIMSP, on distingue trois types de trafic :
Le trafic destiné à Internet : Navigation, Mail, visioconférence,...etc.
Le trafic destiné aux partenaires : Applications CNI (Centre National
d'Informatique), Applications TTN (Tunisie Trade Net), ...etc.
Le trafic interne : Applications CIMSP, Administration à distance des
équipements réseaux (Serveurs, routeurs, switchs, ...), diffusion de données,
Workflow, ...etc.
Dans la figure 2.3, on présente une vue globale de l’architecture du RNS et des liaisons avec
les partenaires qui sont l’ATI et le CNI.
CIMSP
Etablissement de santé
CNI
ATI
Etablissement de santé
Internet
Vers Internet (via ATI)
Vers partenaire
BackBone Nationale (BBN)
Vers CIMSP (via BBN)
Vers CIMSP (via BBN)
Vers CIMSP (via BBN)
Vers établissements (via BBN)
Figure 2.3.Architecture globale du réseau national de la santé.
Chapitre 2 Etude de l’Existant
35
2.3.2 Architecture locale des établissements de santé
Les réseaux locaux sont installés dans la plupart des établissements de santé, mais la
taille varie d'un établissement à un autre (de quelques hôtes à des centaines de hôtes) selon la
catégorie de l'établissement (Centre Hospitalier Universitaire, Institut National, Hôpital
Régional, Hôpital de Circonscription, Direction Régionale de la Santé, Centre de la Santé de
Base, Groupement de la Santé de Base, Ecole Supérieure des Sciences et Techniques de la
Santé, Ecole des Infirmiers,…etc.). Dans un centre de santé de base, par exemple, on trouve
un simple commutateur qui assure la communication entre 3 ordinateurs, alors que dans un
Centre Hospitalier Universitaire des répartiteurs et sous répartiteurs sont interconnectés par
des fibres optiques dont chaque sous répartiteur est composé de plusieurs commutateurs.
Dans la figure 2.4, on présente l’architecture type d’un réseau local d’un établissement de la
santé publique.
Sous répartiteur
Sous répartiteur
Répartiteur Général
Routeur (Cisco)
Modem
LS vers CIMSPSous répartiteur
PC
Hôtes
Serveurs (Applications, proxy, ..)
Hôtes
Hôtes
Figure 2.4.Architecture du réseau local d’un établissement de la santé.
Chapitre 2 Etude de l’Existant
36
2.3.3 Le Backbone CIMSP
Le BackBone est la partie centrale du réseau du centre qui permet de relier les différents
établissements au CIMSP. Le réseau du BackBone est composée de 7 nœuds couvrants tout le
territoire national.
2.3.3.1 Présentation
Le CIMSP est le fournisseur accès Internet (FAI) des établissements de la santé. Il
offre en particulier les services mail et navigation. Et comme tous les FAI de la Tunisie, le
CIMSP est lié à l’ATI par des LS de capacité 64 Kb/s pour le service mail et 2 autres de
1Mb/s chacune pour la navigation et les autres services. D’autre part des LS dont le débit
varie selon le type de connexion assurant le lien entre les établissements de santé au Backbone
du CIMSP.
2.3.3.2 Types de liaisons
On distingue 2 types de liaison LS au Backbone CIMSP sont les suivantes :
Des établissements sont liés directement au CIMSP tels que le siège du Ministère de la
santé, CHU Charles Nicolle, CHU Rabta, Institut Pasteur,…etc. Dans les deux
extrémités la LS est raccordée à un modem puis à un routeur.
D’autres sont liés via le BackBone National (BBN) c’est réseau national composé de 9
nœuds et couvre le territoire tunisien. Chaque établissement est relié avec une LS au
BBN d’au moins 64 Kb/s. De même le CIMSP est lié au BBN aussi par une LS de
1Mb/s. Sur demande de CIMSP, les techniciens de la TUNISIE TELECOM font le
routage de ces LS sur celle du CIMSP.
2.4 L’existant en matière de sécurité
Suite à une analyse documentaire et aux différents entretiens avec les responsables, on
a pu identifier un certains nombres d’actions de sécurité internes existantes à savoir:
Le Centre dispose d’une salle technique relativement sécurisée regroupant les
infrastructures sensibles (serveurs, routeurs,…etc.) en délimitant les accès seulement
aux personnes ayant droits.
Existence d’un serveur antivirus constamment mis à jour permettant la protection de
tous les postes de travail.
Chapitre 2 Etude de l’Existant
37
Une intégration en entrée et en sortie d’anti-virus et d’anti-spam au niveau de la
messagerie.
Des pare-feu centraux redondants sont mis en place.
Existence des zones démilitarisée (DMZ) hébergeant les serveurs proxy, web,…etc.
Des règles de filtrages ont été spécifiées au niveau du pare-feu et des listes de contrôle
d’accès ont été arrêtées au niveau des routeurs.
Certains types d’anomalies et d’incidents d’exploitation sont consignés dans une base
de données.
Existence d’un comité restreint de sécurité qui s’occupe essentiellement de
l’installation de l’antivirus, des clients VPN et de l’outil ssh au niveau des hôpitaux.
Existence d’un inventaire partiel des ressources (équipement seulement).
Le personnel du site est informé partiellement de ses droits et devoirs en matière de
sécurité du SI.
Existence des "Access Control List" (ACL) au niveau des proxy.
Existence d’un groupe électrogène pour alimenter la salle technique en cas de coupure
de l’électricité.
Existence des extincteurs d’incendies au niveau de la salle machine.
Existence des détecteurs d’humidité au niveau de la salle machine
Utilisation exclusive des commutateurs au lieu des concentrateurs.
Existence d'un inventaire partiel des ressources (équipement seulement).
Actuellement les administrateurs du CIMSP utilisent des outils divers et hétérogènes pour la
supervision et l’administration des équipements du Réseau National de la Santé. Ils utilisent
aussi fréquemment la ligne de commande (Ping, Telnet, SSH,…etc.) sous Windows, linux et
d’autres systèmes d’exploitation. Parmi les outils utilisés actuellement :
OSSIM : c’est une solution open source offrant une infrastructure pour le monitoring
temps réel de la sécurité réseau (détection d’intrusion et analyses statistiques). Ses
objectifs sont ; de fournir une plateforme centralisée, fournir une console
d’organisation et d’améliorer la détection et l’affichage des alarmes de sécurité.
OSSEC : c’est un détecteur d’intrusion de type HIDS (Host-Based Intrusion Detection
System), il est l’un des HIDS les plus utilisés, très facile d’accès tant pour
l’installation que pour l’utilisation.
NINO : c’est une solution de gestion de réseau pour contrôler des routeurs, des
commutateurs, des serveurs et des applications de RNS. En utilisant la surveillance en
Chapitre 2 Etude de l’Existant
38
temps réel, l'Evénement surveillant et rapportant la santé et le statut du réseau peut être
surveillé. NINO est une solution basée par le Web. Il emploie le protocole SNMP. Il
tourne sur un serveur Web et peut être accédé par n'importe quel ordinateur avec un
web browser. NINO provient du monde d’Unix, c’est un paquetage contenant des
modules en Perl sur le serveur et les applets Java pour l’interfaçage. Il emploie un
serveur Web pour prendre soin de l'interface utilisateur. Les services de NINO sont
des processus de fond pour prendre soin de la surveillance et de la manipulation
d'événement.
Les services de NINO sont employés pour recevoir des captures de SNMP et pour
collecter et surveiller les données. Toutes les captures sont stockées comme
événements dans la base de données. Tous les événements peuvent également être
traités en utilisant « event action ». Toutes les données de surveillance sont stockées
et peuvent être employées pour créer des rapports, des graphiques ou des vues de
statut.
MRTG : Multi Router Trafic Grapher (MRTG) est un logiciel développé sous licence
GNU/GPL. Ce logiciel permet de créer des graphiques sur le trafic réseau. Il utilise le
protocole SNMP pour interroger des équipements réseaux tels que des routeurs,
commutateurs, ou bien encore des serveurs.
Syslog-ng : Syslog-ng (syslog next generation) est un logiciel gratuit de collecte de
journaux systèmes fonctionnant sur des systèmes tels que Linux, IBM-AIX, Sun
SOLARIS, HP-UX, FreeBSD,…
PuTTY : C’est un client SSH, Telnet, rlogin, et TCP. Il offre la possibilité de se
connecter de manière sécurisée à un serveur depuis un PC. Tout le trafic est encrypté
et les informations de login (username/password) ne peuvent pas être interceptées par
un tiers. Il était à l'origine disponible uniquement pour Windows, mais il est à présent
porté sur diverses plateformes Unix (et non-officiellement sur d'autres plateformes).
C’est un logiciel open source, sous une licence de type MIT.
2.5 Conclusion
Dans ce chapitre, on a tout d’abord décrit l’environnement de déroulement de notre
mission d’audit. On a commencé par une présentation du CIMSP en focalisant ses missions,
son organisation. Ensuite, on a présenté l’architecture de son réseau national ainsi que son
architecture locale de ses établissements de santé dont on a parlé du BackBone national de
santé. Enfin, nous avons décrit les différentes mesures de sécurité existante dans le centre.
Chapitre 3 Audit Organisationnel et Physique
39
Chapitre 3
Audit Organisationnel et Physique
3.1 Introduction
Le SI est généralement défini par l’ensemble des données et des ressources
matérielles et logicielles de l’entreprise permettant le stockage et l’échange des données. Ce
SI représente un patrimoine essentiel de l’entreprise qui nécessite d’être protégé. Le point de
départ de ce travail d’audit consiste à déterminer des personnes à interroger pour l’analyse
du questionnaire basé sur la méthode MEHARI. Ensuite, on va essayer de déterminer le
niveau de maturité par rapport à la norme ISO 17799 : 2005. Enfin, on va s’orienter à
l’identification des vulnérabilités du système audité.
3.2 Objectifs
L'objectif d'un audit organisationnel de sécurité est d'établir un état des lieux complet
et objectif du niveau de sécurité du SI du DERSS sur les plans organisationnels, procéduraux
et technologiques et de déterminer les déviations par rapport aux bonnes pratiques des
normes ISO. Cette phase d’audit est basée sur un questionnaire normalisé de la méthode
choisie en se référant à la base de connaissance MEHARI. Ce questionnaire est complété par
les personnes concernées du domaine audité, liées au périmètre de sécurité.
3.3 Approche adoptée
L’approche qui sera adoptée consiste à mesurer le niveau de maturité par rapport à la
norme ISO17799 : 2005 ou 27002 en se basant sur la méthode MEHARI [16] qui s’inspire
de cette norme. Cette méthode définie ‘ des domaines de responsabilités’ numérotés de 1 à
12, on va utiliser 9 domaines de sécurité pour couvrir notre périmètre audité. Ces domaines
sont les suivants :
L’organisation
La sécurité physique des sites
La sécurité physique des locaux
L’architecture et la continuité de service du réseau étendu intersites
L’architecture et la continuité de service des réseaux locaux
L’exploitation des réseaux
Chapitre 3 Audit Organisationnel et Physique
40
L’architecture système et la sécurité logique
L’environnement de travail
Les aspects juridiques et réglementaires.
Après, on va déterminer le niveau de maturité selon la norme ISO 17799 renommé 27002.
Cette dernière comporte 11 chapitres où chaque chapitre présente un thème de sécurité dans
lequel sont exposés des objectifs de contrôles et des recommandations sur les mesures de
sécurité à mettre en œuvre, et les contrôles à implémenter.
3.4 Détermination des personnes à interroger
On retient des types d’utilisateurs bien distincts pour la DERSS, qui correspondent
aux différents types de personnes rencontrés. Ceci permet d’interroger les personnes selon
leur domaine de connaissances et selon le périmètre d’audit : les directeurs, les ingénieurs, les
analystes, ressources humaines et les ouvriers.
3.5 Analyse de questionnaire d’audit
On retient le questionnaire d’après la base de connaissance de MEHARI, ce
questionnaire est divisé en 9 domaines cités précédemment. Dans cette section, on va
présenter le schéma d’audit de notre système. Ensuite on va décrire les composants du
questionnaire en matière de service et sous service. Enfin on va analyser les résultats du
questionnaire établi au sein du CIMSP.
3.5.1 Elaboration du schéma d’audit
Avant même d’engager le processus d’analyse et d’évaluation des services de
sécurité, la première question à poser est celle d’identifier les solutions distinctes à analyser
ou à auditer. C’est le but de ce que MEHARI appelé le ‘plan d’audit’ ou ‘schéma d’audit’.
Chapitre 3 Audit Organisationnel et Physique
41
Tableau 3.1.Schéma d'audit.
3.5.2 Evaluation de la qualité des services basées sur les questionnaires
MEHARI
Les questionnaires comprennent un lot de questions auxquelles il est demandé de
répondre par oui (1) ou par non (0) en se basant sur des conventions de cotation et de
pondération qu’on va les étudier ultérieurement. L’exemple ci-dessous est un extrait du
questionnaire relatif au domaine la sécurité des systèmes et de leur architecture. Chaque
domaine comporte plusieurs services et chaque service comporte plusieurs sous domaines.
Les questions de chaque sous service sont axées sur 3 mesures à savoir des questions axées
sur l’efficacité des mesures de sécurité, des questions basées sur la robustesse des mesures de
sécurité et des questions axées sur le contrôle ou l’audit des fonctionnalités attendues du
service.
Chapitre 3 Audit Organisationnel et Physique
42
Tableau 3.2.Questionnaire MEHARI.
3.5.2.1 Les services de sécurité
Dans cette sous section, on va définir les services et les sous services de sécurité selon
la méthode MEHARI. Chaque domaine de sécurité est composé de plusieurs services et
chaque service est constitué de plusieurs sous services.
a) Définition des services 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. Dans la figure 3.2 du questionnaire, on identifie ‘07A contrôle
d’accès aux systèmes et application’ comme service.
b) Définition des sous-services de sécurité
La fonction assurée par un service de sécurité peut, elle même, nécessiter plusieurs
éléments complémentaires, que l’on pourrait considérer comme des ‘sous-fonctions’. Un
service de sécurité peut ainsi lui-même être constitué de plusieurs autres services de sécurité
pour répondre à un besoin ou une finalité déterminée. Chacun des constituants est un sous-
service de sécurité du service en question. Dans la figure 3.2, le sous service est ‘07A01
Gestion des profils d’accès’.
Chapitre 3 Audit Organisationnel et Physique
43
c) Qualité d’un service de sécurité
Nous évaluerons un service de sécurité en faisant une ‘mesure globale ‘ de sa qualité,
cette mesure globale évalue 3 paramètres sont les suivants :
L’efficacité du service : l’efficacité mesure la capacité du service à assurer
effectivement la fonction demandée face à des acteurs ayant plus ou moins de forces
ou des circonstances plus ou moins courantes.
La robustesse du service : La robustesse d’un service mesure sa capacité à résister aux
actions ou événements se traduisant par le contournement ou l’inhibition du
fonctionnement attendu tels que interruption volontaire ou arrêt de l’équipement
assurant le service, panne non détecté, contournement du contrôle par une voie
détournée, altération des fonctionnalités,…etc.
Mise sous contrôle du service: mesure la capacité de l’organisme à garantir la
permanence dans le temps des fonctions du service : permanence des paramétrages
décidés, application effective des procédures, maintien de la pertinence et de la
cohérence.
3.5.2.2 Système de pondération des questions
Certaines questions ont traité des mesures ayant un certain rôle, au sens où elles
contribuent à la qualité de service sans, pour autant, que leur mise en œuvre soit
indispensable. Alors, en vue de calculer la qualité de service, une pondération classique de
ces mesures reflète bien cette notion de contribution. Dans ce cas, certaines mesures, plus
importantes que d’autres, ont des poids différents et la base de connaissance MEHARI
indique les poids à chaque question.
La moyenne pondérée est alors un simple cumul des poids des mesures actives (pour
lesquelles il a été répondu affirmativement), ramené à la somme des poids possibles et normé
sur une échelle de 0 à 4.
Soit 𝑅𝑖 la réponse à la question i, 𝑃𝑖 le poids de la question i, 𝑀𝑝 la moyenne pondérée. En
effet, 𝑀𝑝 sera exprimée par l’expression suivante :
𝑀𝑝 = 4 ∗ 𝑅𝑖𝑃𝑖 / 𝑃𝑖
Si on applique cette expression sur l’exemple ci-dessus, on aura 𝑀𝑝 égale à :
La 𝑀𝑝= 4*(1*2+1*4+1*4+1*4) / 26
D’où, la qualité de service est exprimée par Q = 𝑀𝑝 = 2.15
Chapitre 3 Audit Organisationnel et Physique
44
3.5.3 La synthèse par domaines de sécurité
Le graphique suivant est la représentation globale des résultats du tableau ci-après, il
schématise les 9 domaines de sécurité de la méthode MEHRI ainsi que leurs moyennes.
Figure 3.1.Représentation graphique des domaines MEHARI et leurs moyennes.
On remarque que la moyenne pondérée n’a pas dépassée le 1.67 dans le domaine sécurité des
systèmes et de leur architecture. En effet, 5 domaines de sécurité n’ont pas atteints une
moyenne de 1. Ces domaines sont l’organisation de la sécurité, la sécurité des locaux, le
réseau étendu, l’exploitation des réseaux et la protection de l’environnement de travail.
0
1
2
3
4
01 Organisation de la sécurité
02 Sécurité des sites et des bâtiments
03 Sécurité des locaux
04 Réseau étendu (intersites)
05 Réseau local (LAN)06 Exploitation des réseaux
07 Sécurité des systèmes et de leur architecture
11 Protection de l'environnement de travail
12 Juridique et Réglementaire
Domaine
Moyenne pondéré
Chapitre 3 Audit Organisationnel et Physique
45
Tableau 3.3.Moyennes des domaines de sécurité et des services.
Chapitre 3 Audit Organisationnel et Physique
46
Les résultats sont constitués des questionnaires remplis, avec les commentaires et les
moyennes calculées des différents domaines et services.
3.6 La convergence vers la norme ISO 17799
Afin d’établir une liaison avec la norme Iso 17799 : 2005, on s’oriente à déduire d’un
diagnostic MEHARI, une évaluation de la conformité aux pratiques de l’ISO qui est possible
avec la version 2 de 2007 de MEHARI vue qu’elle permet l’élaboration de tels indicateurs
par l’incorporation dans la base de connaissances de nouvelles questions adoptées aux
pratiques recommandées et par des formules de calcul du degré de conformité à chaque
contrôle cité dans la norme ISO . Cette phase consiste à déterminer le niveau de maturité par
rapport à la norme et à percevoir les vulnérabilités auxquelles le SI est exposé. Le
questionnaire est représenté au sein de l’annexe 1.
3.6.1 Le niveau de maturité par principe
On a extrait depuis le questionnaire MEHARI, les 11 chapitres de la norme ISO suivants:
Politique de sécurité de l'information
Organisation de sécurité de l'information
Gestion des actifs
Sécurité liée aux ressources humaines
Sécurités physiques et environnementales
Exploitation et gestion des communications
Contrôle d'accès
Acquisition, développement et maintenance des systèmes d'informations
Gestion des incidents
Gestion de la continuité d'activité
Conformité.
Le niveau de maturité par principe selon la méthode exploitée est exprimé par l’expression
suivante :
𝑀𝑝 = 4 ∗ 𝑅𝑖 𝑃𝑖/ 𝑃𝑖
Chapitre 3 Audit Organisationnel et Physique
47
Niveau (de 0 à 4)
0
5.1 Politique de sécurité de l'information 0
0.445
6.1 Organisation interne 0 .45
6.2 Tiers 0.44
0
7.1 Responsabilités relatives aux biens 0
7.2 Classification des informations 0
1,55
8.1 Avant le recrutement 3.33
8.3 Fin ou modification de contrat 0
1.65
9.1 Zones sécurisées 1.62
9.2 Sécurité du matériel 1.68
0.767
10.3 Planification et acceptation du système 2
10.4 Protection contre les codes malveillant et mobile 0.4
10.5 Sauvegarde 1
10.6 Gestion de la sécurité des réseaux 1.33
10.7 Manipulation des supports 0
10.8 Échange des informations 0.8
10.10 Surveillance 1.14
1.32
11.1 Exigences métier relatives au contrôle d'accès 1.14
11.2 Gestion de l'accès utilisateur 1.51
11.3 Responsabilités utilisateurs 0.88
11.4 Contrôle d'accès au réseau 2.01
11.5 Contrôle d'accès au système d'exploitation 2.37
11.6 Contrôle d'accès aux applications et à l'information 1.33
11.7 Informatique mobile et télétravail 0
10 Gestion de l'exploitation et des télécommunications
11 Contrôle d'accès
6 Organisation de la sécurité de l'information
7 Gestion des biens
9 Sécurité physique et environnementale
Chapitre
5 Politique de sécurité
8 Sécurité liée aux ressources humaines
Chapitre 3 Audit Organisationnel et Physique
48
Tableau 3.4.Niveau de maturité par principe.
3.6.2 Niveau de maturité par chapitre
Après avoir calculé les moyennes associées aux différents principes, on va procéder à
l’évaluation des moyennes pondérées par chapitre. On a obtenue le niveau de maturité pour
chaque chapitre de la norme qui représente une valeur chiffrée entre 0 et 4. La formule
utilisée est la suivante :
Niveau de maturité par chapitre= 𝑁𝑖𝑣𝑒𝑎𝑢 𝑑𝑒 𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑒 /𝑛𝑜𝑚𝑏𝑟𝑒 𝑑𝑒 𝑝𝑟𝑖𝑛𝑐𝑖𝑝𝑒𝑠
Tableau 3.5.Niveau de maturité par chapitre.
De la même façon, on peut effectuer un calcul du niveau de maturité globale en se basant sur
l’expression suivante :
1.165
12.3 Mesures cryptographiques 1
12.4 Sécurité des fichiers système 1.33
0
13.1 Signalement des événements et des failles liés à la sécurité de
l'information
0
13.2 Gestion des améliorations et incidents liés à la sécurité de l'information 0
0
14.1 Aspects de la sécurité de l'information en matière de gestion de la
continuité de l'activité
0
0.24
15.1 Conformité avec les exigences légales 0.73
15.2 Conformité avec les politiques et normes de sécurité et conformité
technique
0
15.3 Prises en compte de l'audit du système d'information 0
15 Conformité
12 Acquisition, développement et maintenance des systèmes
13 Gestion des incidents liés à la sécurité de l'information
14 Gestion du plan de continuité de l'activité
Chapitre 3 Audit Organisationnel et Physique
49
Niveau de maturité goba = Niveau de maturité par chapitre /Nombre de chapitre
Le niveau de maturité globale = 0.648
3.6.3 Représentation graphique
La figure 3.2 montre la représentation graphique des différents chapitres avec leurs
moyennes, sous forme d’une rosace des différents niveaux de maturité.
Figure 3.2.Représentation graphique du niveau de maturité.
Le seuil de maturité définit par la norme n’est pas atteint dans tous les chapitres. En effet, 4
chapitres ont un niveau de maturité qui est égal à 0. Ces chapitres sont la politique de
sécurité, la gestion des biens, la gestion des incidents liés à la sécurité de l’information et la
gestion du plan de continuité de l’activité. Ce qui nous mène à conclure que la sécurité au
sein du CIMSP est sous évalué et ne possède pas l’importance qu’elle doit avoir au sein de
toute organisation.
3.7 Synthèse des vulnérabilités
Suite à cette analyse, on va déterminer les vulnérabilités du système étudié pour les
différents chapitres de la norme.
0
1
2
3
4
Politique de sécurité
Organisation de la sécurité de l'information
Gestion des biens
Sécurité liée aux ressources humaines
Sécurité physique et environnementale
Gestion de l'exploitation et des
télécommunications Contrôle d'accès
Acquisition, développement et maintenance
des systèmes d'information
Gestion des incidents liés à la sécurité de
l'information
Gestion du plan de continuité de l'activité
Conformité
chapitre
Niveau (de 0 à 4)
Chapitre 3 Audit Organisationnel et Physique
50
Politique de sécurité
On remarque l’absence d’une politique de sécurité formelle et disponible pour tout le
personnel du centre.
Organisation de la sécurité du système d'information
Le management de l'entreprise n’est pas impliqué dans l'organisation de la sécurité de
l'information, 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.
Inexistence de la fonction de responsable de sécurité RSSI avec délégation formelle de
la direction général.
Absence des lignes directrices d’attribution des rôles et des responsabilités pour la
sécurité de l’information.
Absence d’une méthodologie et un processus relatifs à la sécurité de l’information.
L’absence d’une charte informatique précisant les exigences d’utilisation pour tous les
personnels du centre.
Absence des moyens de contrôle relatifs à l'usage d'équipements personnels
Absence de note précisant les devoirs et responsabilités du personnel et les obligations
légales, réglementaires ou contractuelles.
Absence d’une veille technologique en matière de sécurité.
Absence de sensibilisation en matière de la sécurité de l’information.
Absence de formation sur les problèmes de sécurité.
Absence des clauses de 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.
Gestion des biens (des actifs)
Inexistence d’un inventaire complet et à jour des différentes ressources.
Absence d’un processus d’attribution de la propriété à chaque information et moyens
de traitement de l’information à un personnel défini de centre.
Manque des lignes directrices pour la classification des informations en termes de
valeur, d’exigences légales, de sensibilité et de criticité.
Chapitre 3 Audit Organisationnel et Physique
51
Inexistence d’une classification des ressources basées sur les 3 axes : Disponibilité,
Intégrité et Confidentialité.
Existence des équipements qui ne sont pas couverts par un contrat de maintenance.
Sécurité liée aux ressources humaines
Absence d’une note précisant les devoirs et responsabilités du personnel.
Absence d’un programme de sensibilisation du personnel aux risques d'accident,
d'erreur et de malveillance relatifs au traitement de l'information.
Absence d’un programme de formation du personnel aux règles et mesures générales
de protection de l'information.
Le processus disciplinaire en cas de manquement aux règles de sécurité ou de
violation de procédure n’est pas appliqué.
Absence de procédures pour garantir que tout les informations pertinentes soient
transfert au centre et correctement effacés du matériels lors de la sortie du personnel.
Sécurité physique et environnementale
Absence des systèmes automatiques de contrôle d'accès au site placés sous contrôle
permanent.
L’inexistence d’un système opérationnel de détection des intrusions sur le site relié à
un poste permanent de surveillance.
Les droits d'accès permanents ou semi-permanents, notamment pour une durée
déterminée, aux locaux sensibles ne sont pas définis par rapport à des "profils" types
prenant en compte la fonction et le statut, plus précisément pour le personnel
d'exploitation informatique ou Télécom, personnels des services généraux ou de
sécurité, pompiers, prestataires de maintenance ou d'entretien, fournisseurs de
services, stagiaires, et visiteurs,…etc.
Absence des procédures spécifiques de contrôle pour chaque type de prestataire
extérieur au service amené à intervenir dans les bureaux tels que sociétés de
maintenance, personnel de nettoyage,…etc. (avoir un badge spécifique, présence d'un
accompagnateur, autorisation préalable indiquant le nom de l'intervenant,….etc).
Absence d’un poste de surveillance pour les détecteurs d'humidité à proximité des
ressources sensibles notamment la salle machine.
Chapitre 3 Audit Organisationnel et Physique
52
Absence d’une analyse systématique et approfondie de tous les risques d'incendie ou
d’inondation ou de tous les risques environnementaux envisageables pour le site
considéré.
L’inexistence d’un système de détection automatique d’incendie pour l’ensemble du
bâtiment.
L’inexistence de moyens de contrôle contre la pénétration dans les locaux sensibles
avec des moyens d'enregistrement photo, vidéo ou audio.
Pour les locaux sensibles, le centre n’utilise pas un système complémentaire de
vidéosurveillance cohérent et complet contrôlant tous les mouvements de personnes à
l'intérieur des locaux sensibles et permettant de détecter des anomalies dans les
comportements.
Il n’existe pas une procédure décrivant en détail les opérations à mener, avant appel à
la maintenance, pour empêcher que celle-ci ait accès aux données critiques (clés de
chiffrement ou de protection de réseau, configurations des équipements de
sécurité,…etc.).
Il n’existe pas une procédure et une clause contractuelle vis-à-vis du personnel de
maintenance (interne et externe), spécifiant que tout support ayant contenu des
informations sensibles doit être détruit en cas de mise au rebut.
Les personnes susceptibles de travailler en dehors des locaux de l'entreprise ne
reçoivent pas une sensibilisation et une formation sur les mesures à appliquer pour
protéger les documents utilisés, leurs systèmes et les données qu'ils contiennent.
Un système anti-intrusion n’est pas implanté.
Gestion de l’exploitation et des télécommunications
La non réalisation d’une revue formelle des nouvelles fonctionnalités (ou des
changements de fonctionnalités) liées à un nouveau logiciel ou équipement ou à une
nouvelle version et des risques éventuels.
Les paramétrages de sécurité et règles de configuration (suppression de tout compte
générique, changement de tout mot de passe générique, fermeture de tout port non
explicitement demandé et autorisé, paramétrages du contrôle des droits et de
l'authentification, contrôles des tables de routage,…etc.) ne sont pas définis dans une
procédure.
Chapitre 3 Audit Organisationnel et Physique
53
Les actions à mener par le management en cas d'attaque par des codes malveillants
tel que les alerte, le déclenchement de processus de gestion de crise,…etc. ne sont pas
définis.
Il n’existe pas un plan de sauvegarde, couvrant l'ensemble des configurations du
réseau étendu, définissant les objets à sauvegarder et la fréquence des sauvegardes.
Il n’existe pas un document définissant les règles générales à appliquer en ce qui
concerne la protection des moyens et supports de stockage, de traitement et de
transport de l'information tel que les équipements de réseau et de travail, les systèmes,
les applications, les données,…etc. et les conditions requises pour l'attribution, la
gestion et le contrôle des droits d'accès.
Il n’existe pas un document définissant les règles à appliquer en ce qui concerne
l'exploitation des ressources informatiques tel que les réseaux, les serveurs,…etc., des
services de communication électronique.
Il n’existe pas un document définissant les procédures de sécurité additionnelles à
appliquer en ce qui concerne le télétravail.
Pas de mis en place un service de signature électronique.
Absence d’une analyse approfondie des événements ou succession d'événements
pouvant avoir un impact sur la sécurité tel que les connexions refusées, les routages,
les reconfigurations, les évolutions de performances, les accès à des informations ou
des outils sensibles,…etc.
Absence d’une surveillance en temps réel ou déclanchement d’alerte, contre tout
accès illicite sur le réseau étendu, par le personnel.
Il n’existe pas un archivage de tous les éléments ayant permis de détecter une
anomalie ou un incident.
Pas de Traitement des incidents du réseau étendu et réseau local.
Il n’existe pas une équipe accessible en permanence, chargée de recueillir les appels
liés au réseau étendu et de signaler et d'enregistrer tous les incidents.
Les procédures d’exploitation, sauvegarde ne sont pas documentées, tenues à jour et
disponibles pour tous les utilisateurs concernés.
Absence de processus de séparation des tâches pour réduire les occasions de
modification ou de mauvais usage non autorisé ou involontaire des biens du centre.
Absence des procédures pour la gestion des supports amovibles.
La sécurité des informations et des logiciels échangés au sein du centre n’est pas
maintient.
Chapitre 3 Audit Organisationnel et Physique
54
Contrôle d’accès
Inexistence d’une procédure formelle et écrite d’enregistrement et de désinscription
des utilisateurs destinée à accorder et à supprimer l’accès à tous les systèmes et
services d’information.
Absence d’une politique, de gestion des droits d’accès au réseau local, de gestion des
droits privilégiés sur les équipements du réseau et de gestion des droits d’accès aux
zones de bureaux, s’appuyant sur une analyse préalable des exigences de sécurité.
L’attribution de mots de passe n’est pas réalisée dans le cadre d’un processus formel.
Absence des bonnes pratiques de sécurité lors de la sélection et de l’utilisation de
mots de passe par les utilisateurs.
Manque d’une politique formelle du bureau propre pour les documents papier et les
supports de stockage amovibles, et une politique de l’écran vide par le verrouillage
de l’écran par un mot de passe pour les moyens de traitement de l’information.
Absence d’une procédure de gestion des profils.
Absence d’une note ou document mis à la disposition du management précisant les
devoirs et responsabilités du personnel quant à l'utilisation, la conservation et
l'archivage des informations et à la protection du secret.
Absence d’un document définissant les règles à appliquer en ce qui concerne
l'exploitation des ressources informatiques des services de communication
électronique.
Le processus de présentation par l'utilisateur de son authentifiant ne garantit pas son
inviolabilité.
Absence d'une liste précise, tenue à jour, et d’un contrôle des paramétrages de sécurité
et règles de configuration avant toute mise en exploitation d'une nouvelle version d’un
logiciel.
Acquisition, développement et maintenance des systèmes d’information
Les liens permanents et les échanges de données, qui devant être protégés par des
solutions de chiffrement au niveau du réseau étendu, ne sont pas définis.
Absence des procédures pour contrôler l’installation du logiciel sur les systèmes en
exploitation.
Chapitre 3 Audit Organisationnel et Physique
55
Gestion des incidents liés à la sécurité de l’information
Absence des règles de notification des incidents et failles liés à la sécurité de
l’information permettant la mise en œuvre d’une action corrective, dans les meilleurs
délais.
Absence d’un système de ‘Reporting’ des incidents liés à la sécurité de l’information.
Absence de la définition des responsabilités et des procédures fournissant rapidement
des solutions effectives aux incidents de sécurité.
Absence d’un service spécialement chargé de l'archivage et de la protection des pièces
devant être conservées en tant que preuves, des éléments pouvant servir de
justificatifs ou des archives patrimoniales.
Gestion du plan de continuité de l’activité
Les plans de continuité destinés à maintenir ou à restaurer l’exploitation et à assurer la
disponibilité des informations au niveau et dans les délais requis suite à une
interruption ou une panne affectant les processus métier cruciaux ne sont pas définis.
Absence d’une analyse de la criticité des différentes activités pour mettre en évidence
les besoins de continuité de service.
Conformité
Absence des procédures appropriées visant à garantir la conformité avec les
exigences légales, réglementaires et contractuelles concernant l’utilisation des
logiciels propriétaires
Manque des procédures pour protéger les enregistrements importants de la perte,
destruction et falsification conformément aux exigences légales, réglementaires et
aux exigences métier.
Absence d’un document précisant les exigences, les responsabilités et les procédures
à appliquer afin de protéger les archives importantes du centre.
Absence d’un document définissant les règles générales à appliquer en ce qui
concerne la protection des sites vis-à-vis de l’extérieur, les conditions requises pour
accéder à chaque site depuis l’extérieur et la protection des locaux sensibles.
Absence d’un document définissant les règles à appliquer en ce qui concerne la
protection des moyens et supports de stockage.
Chapitre 3 Audit Organisationnel et Physique
56
Absence d’un document définissant les règles à appliquer en ce qui concerne
l’exploitation des ressources informatiques.
Absence d’une vérification de la conformité technique (des tests périodiques de
pénétration du réseau et des audits techniques spécialisés approfondis).
3.8 Conclusion
Dans ce chapitre, on a essayé de présenter les différentes étapes de l’audit
organisationnel et physique. D’abord, on a commencé par la réalisation du questionnaire
approprié qui est constitué de 9 domaines de sécurité. Ensuite, on a passé vers la norme ISO
17799 : 2005 pour déterminer le niveau de maturité du système audité. Enfin, en se basant sur
une analyse des questionnaires et des résultats fournis, on a pu dégager les vulnérabilités
identifiées au niveau du système audité. Dans le chapitre suivant, on va focaliser l’étape
d’analyse des risques.
Chapitre 4 Analyse des risques
57
Chapitre 4
Analyse des risques
4.1 Introduction
Le concept de risque n’est pas clair ni universellement reconnu alors pour cette raison
qu’on ne parle plus de concept de risque mais plutôt de concept de scénarios de risque ou
situation de risque. Dans ce chapitre, on va procéder sur deux approches d’analyse des
risques : la première consiste à analyser les situations des risques à partir de l’échelle de
valeurs des dysfonctionnements et la deuxième consiste à sélectionner automatiquement les
situations des risques en s’appuyant sur les bases de connaissance de MEHARI. Ces deux
approches sont complémentaires : la première fera ressortir les scénarios dont les
conséquences seront plus proches des activités de l’entreprise et la deuxième qui est plus
générique et exhaustive fera ressortir des scénarios qui peuvent passé inaperçu par une
approche directe. On va commencer par la représentation de la méthode d’analyse des risques
ensuite détailler chacune de ces deux approches.
4.2 Présentation de la méthode d’analyse de risques
MEHARI est une méthode d’analyse de risques mise au point par la commission
« Méthodes » du CLUSIF. Elle bénéfice des résultats des études et recherche menées soit au
sein, soit à l’extérieur des diverses commissions du CLUSIF, soit dans d’autres organismes
en France ou à l’étranger. Elle est universelle, indépendante des organisations et des outils
informatiques, matériels et logiciels installés, MEHARI peut répondre aux besoins
d’organisations complexes reposant sur des structures de management et informatiques
décentralisées et peut s’appliquer également efficacement à des activités simples et très
centralisées. On va utiliser MEHARI par ses concepts pour analyser les divers risques qui
peuvent mettre en danger le système d’information du CIMSP.
4.3 Analyse des risques suite à une analyse des enjeux
Dans tous les actes de management, la question des enjeux se pose, dés qu’il y a un
choix entre plusieurs actions possibles. En matière de la sécurité informatique, au lieu qu’on
cherche à optimiser les gains, l’objectif est de chercher à minimiser les risques de pertes. Les
enjeux de la sécurité ne sont pas d’accroitre les opportunités de gains mains de limiter les
Chapitre 4 Analyse des risques
58
possibilités de pertes. C’est dire que les enjeux de la sécurité sont vus comme des
conséquences d’événements venant perturber le fonctionnement voulu de l’entreprise ou de
l’organisme. Alors, le souci majeur des managers de sécurité est de réaliser la juste
proportion entre les moyens investis dans la sécurité et la hauteur des enjeux de cette même
sécurité. C’est dire, qu’il est fondamental d’avoir une connaissance des enjeux de la sécurité
et qu’une analyse des enjeux mérite un très haut niveau de priorité et une méthode
d’évaluation rigoureuse comme la méthode MEHARI.
4.3.1 Utilité d’une analyse des enjeux
Procéder à une analyse des enjeux est le plus souvent nécessaire, voire essentielle. La
double question qu’on a déjà citée ci-dessus doit être posée chaque fois qu’une réflexion est
engagée dans une réflexion sur la conduite à tenir pour être sélectif dans les moyens à mettre
en œuvre et ne pas engager des dépenses là ou les enjeux sont faibles, pour éviter des
contraintes inutiles aux managers, pour définir les priorités et pour répondre à l’inévitable
question des dirigeants en face d’un budget de sécurité : « est-ce bien nécessaire ? » [17].
4.3.2 Objectifs de l’analyse des enjeux
L’objectif principal d’une analyse des enjeux est de répondre à cette double question :
« Que peut-on redouter et, si cela devrait arriver, serait-ce grave ? ».
4.3.3 Expression des enjeux : Echelle de valeur des dysfonctionnements et
classification
La phase de l’expression des enjeux se traduit par deux principaux éléments qui
synthétisent le processus d’évaluation des éléments majeurs du CIMSP. Ces deux sont :
Une échelle de valeur des dysfonctionnements potentiels.
Une classification formelle des ressources du système d’information.
La démarche MEHARI consiste à une analyse des activités et donc des processus de
l’entreprise ou de l’organisme, d’en déduire les dysfonctionnements qui peuvent être
redoutés, puis d’évaluer en quoi ces dysfonctionnements peuvent être plus au moins graves,
avant d’effectuer, éventuellement, la classification proprement dite des informations et
ressources du système d’information, selon la figure 4.1.
Chapitre 4 Analyse des risques
59
Figure 4.1.Processus d'analyse des enjeux.
4.3.3.1 Echelle de valeurs des dysfonctionnements
L’objectif de cette phase est de déterminer une échelle de valeurs des
dysfonctionnements significatifs des activités du centre. Cette analyse se déroule en quatre
étapes qui sont l’identification des activités majeurs et de leurs finalités, l’identification des
dysfonctionnements redoutés de chaque activité, l’évaluation du niveau de gravité de ces
dysfonctionnements activité par activité et enfin la détermination et la validation d’une
échelle de valeurs globale au niveau de l’entité.
a) L’identification des activités majeures et leurs finalités
le CIMSP, comme on a présenté dans le chapitre précédent, est composé de quatre
grandes directions qui sont la DG, la DEDI, la DERSS et la DAAF. Le tableau 4.1
représente les processus majeurs de chaque direction et une description de chaque processus
comme ils sont définis dans les documents du centre.
Chapitre 4 Analyse des risques
60
Processus majeurs du CIMSP
Domaine Processus Description
DG (direction générale) Il n’y a pas de processus
prédéfini mais des
missions.
-présider le conseil de l’établissement et assurer
l’homogénéité entre les différentes directions.
DEDI (direction d’étude
et de développement
informatique)
-conception et
développement des
applications informatiques
PRR/01
-Ce processus a pour objectif de maîtriser et suivre les
activités de conception et de développement des applications
informatiques.
DERSS (direction de
l’exploitation, des
réseaux, de la sécurité
et de soutien)
-installation et assistance
des utilisateurs PRR/02
-Ce processus a pour objectif de fournir et mettre en place les
Applications développées et testées par le CIMSP au profit
des utilisateurs des établissements de la santé et d'assurer le
suivi d'exploitation.
-assistance sur site
PRR/10
-Ce processus fait du correspondant le point de contact
unique entre les utilisateurs du système informatique du site
hospitalier et la direction d’exploitation du CIMSP de façon à
garantir un support de premier niveau pour l’exploitation de
l’infrastructure informatique et un relais pour les supports de
niveaux supérieurs.
-étude technique
concernant les réseaux et
les équipements
informatiques PRS/04
-Ce processus concerne l’assistance, le conseil, les études
techniques relatives aux réseaux et aux acquisitions des
équipements informatiques, ainsi que leurs mise en place et
leurs exploitation sur le compte du centre informatique et des
établissements relevant du ministère de la santé publique.
-maintenance technique
des équipements
informatiques PRS/03
-Ce processus concerne la maintenance technique des
équipements du centre informatique et des établissements
relevant du ministère de la santé publique et ceci à l’atelier du
CIMSP, par télémaintenance ou bien sur site.
-gestion des accès internet
PRR/03
-ce processus a pour objet de répondre aux demandes des
clients portant sur l’accès à l’internet.
DAAF (direction des
affaires administratifs et
financières)
-approvisionnement
PRS/02
-l’objectif de ce processus est de définir les activités relatives
aux fournisseurs d’approvisionnement.
-gestion des ressources
humaines PRS/01
-l’objectif de ce processus est de définir les activités relatives
à la GRH.
Tableau 4. 1.Processus majeurs du CIMSP.
Chapitre 4 Analyse des risques
61
Suite à une demande du responsable, mon système cible où on va réaliser notre audit, va être
la direction de l’exploitation, des réseaux, de la sécurité et de soutien (DERSS) alors, les
processus majeurs et les activités ainsi que leurs description, sont illustrés dans le tableau ci
dessous :
62
Division Processus DERSS Code Activités Description de l’activité
Division de
l’exploitation et
gestion des sites
-assistance sur site
PRC /101
-affectation du correspondant au site
-assurer une proximité de services au site hôte de façon à veiller
de plus près à l’exécution du contrat de niveaux de service et à
fournir une assistance (intervention physique ou
téléphoniquement) aux abonnés via un point de contact unique et
ce, pour toute question ou problème concernant l’utilisation et le
fonctionnement des produits du CIMSP.
PRC/102
-gestion de l’annuaire des utilisateurs
- Identification des clients effectifs, et de leurs droits d’accès aux
fonctionnalités du système informatisé en vue d’optimiser la
répartition des ressources entre différents utilisateurs et en vue de
leur inculquer la politique de sécurité qui gouvernera l’utilisation
des équipements informatiques et qui limitera les accès à ceux
qui en ont un réel besoin, de façon à bien définir les
responsabilités de chacun des acteurs du système et de mettre à
jour, si nécessaire, le niveau et les règles de sécurité de
l’établissement.
PRC/103
-gestion administrative des postes de travail
-Identification, documentation, contrôle, communication et
validation des caractéristiques fonctionnelles et techniques des
postes de travail exploités sur le site en vue d’assurer
l’optimisation de leur utilisation et de maîtriser les coûts de leur
exploitation en offrant une base solide pour la gestion des
incidents, des problèmes et des changements.
PRC/104
-gestion technique des postes de travail
- Standardisation et optimisation des outils techniques
(sauvegarde, sécurité, système d’exploitation, licences éditeurs,
contrats de maintenance, administration à distance …) en vue de
maintenir l’intégrité du système, assurer la continuité de service
et organiser la maintenance préventive et curative du parc.
PRC/105 -gestion des documents sur site
- Identification, classification communication et archivage des
documents faisant partie de l’infrastructure informatique du site.
PRC/106 -sauvegarde de données
-Mettre à l'abri les données vitales et les copies des fichiers les
plus importants du système, en dehors de celui-ci, en application
de la stratégie de sauvegarde énoncée dans le document décrivant
la politique de sécurité retenue pour le site, et ce, pour garantir
l'intégrité, la disponibilité, la protection des données et leur
restauration en cas de sinistre
PRC/107 -pilotage logique et sécurité physique
- Veiller à la sécurité physique de la salle des serveurs et des
locaux techniques annexes, composants vitaux et vulnérables du
réseau local du site, pour assurer son bon fonctionnement et ses
interconnections.
63
Division Processus DERSS Code Activités Description de l’activité
PRC/108
-identification des besoins utilisateurs
- Démarche exploratoire centrée sur les clients avec une attitude
d’écoute afin de bien les comprendre et d’identifier leurs besoins
implicites ou non déclarés pour préparer les futures offre du
CIMSP et pour faire évoluer celles existantes dans une démarche
d’amélioration continue.
PRC/109 -gestion des appels
- Fournir un point de contact unique pour la prise en compte des
demandes de tous les utilisateurs et ce, afin de leur permettre de
tirer le meilleur des services informatiques.
PRC/110 -gestion des incidents
- Restauration, aussi rapide que possible, du service normal sur
site tout en minimisant les effets négatifs sur la bonne marche
des processus métier impactés et en identifiant les non-
conformités dans la fourniture des services rendus aux
utilisateurs. PRC/111 -gestion des escalades
- Etablissement des règles de diffusion et de routage de
l’information relative à une demande utilisateur pour permettre
aux personnes désignées, en fonction du niveau d’urgence de la
demande, de suivre l’évolution de la situation et de prendre les
décision nécessaires et adéquates pour l’amélioration de la
réactivité et pour une complémentarité à l’assistance de premier
niveau.
PRC/112 -gestion des changements
- Gérer efficacement et rapidement tous les changements
affectant les éléments de la configuration informatique, afin d’en
minimiser les impacts négatifs et conséquences sur les processus
métier et d’absorber les changements de ces derniers en
favorisant l’alignement avec les besoins utilisateurs et en
réduisant la probabilité d’apparition des incidents.
PRC/113 -élaboration d’une enquête de satisfaction
clients
- Recueil des commentaires, jugement et perceptions des
utilisateurs dans un site quant aux services informatiques
fournies par le CIMSP.
PRC/114
-revue mensuelle des niveaux de service
- Suivi périodique des indicateurs de performances du service
desk et du degré de conformité au contrat des niveaux de service.
-maintenance technique des
équipements informatiques.
PRC/16 -analyse des demandes
-la demande du client doit être analysée avant l’autorisation de
l’intervention, afin de filtrer et de réduire les activités inutiles ou
interdites et pour appliquer la politique du CIMSP en matière de
service surtout concernant les conventions avec les
établissements sous-tutelles.
64
Division Processus DERSS Code Activités Description de l’activité
PRC/17 -intervention curative
-description des démarches appliquées par la CIMSP en matière
d’exécution des interventions curatives internes par l’équipe du
CIMSP ou externes par des sous-traitants, et ceci, sur les
équipements du parc informatique du CIMSP ou bien des parcs
informatiques des établissements sous-tutelles, l’intervention
peut être sur site du client, par télémaintenance ou bien à l’atelier
du CIMSP
PRC/18
-intervention préventive
-description des démarchés appliquées par le CIMSP en matière
d’exécution des interventions préventives internes par l’équipe
du CIMSP ou externe par des sous-traitants, sur les équipements
du parc informatique du CIMSP ou bien des parcs des
établissements sous-tutelles, l’intervention peut être sur site du
client, par télémaintenance ou bien au siège du CIMSP.
-installation et assistance des utilisateurs PRC/11
-assistance des utilisateurs - elle permet de préciser les différents types de relations entre
les établissements de santé et le CIMSP. Le CIMSP assure
l'assistance auprès des utilisateurs par le biais des correspondants
informatique, ces derniers disposent des outils de communication
informatique ou classique. Cette procédure a pour objectif la
généralisation des usages des services informatiques et plus
généralement d’accompagner le changement.
PRC/12 -évaluation des services CIMSP
- L’objectif de la procédure «Evaluation des services CIMSP» est
d’évaluer la qualité des services informatiques au niveau des
Etablissements sanitaires.
PRC/32 -tests de validation des applications
- Le test a pour objectifs de détecter d'éventuels écarts entre le
comportement attendu et le comportement observé au cours des
tests, ce qui élimine un grand nombre des anomalies présentes
dans le logiciel et d'obtenir la confiance nécessaire avant
l'utilisation opérationnelle.
PRC/10 -installation des applications informatiques.
- elle a pour objectif d’accompagner le changement et
notamment les modifications apportées aux applications pour une
meilleure exploitation du système d’information.
Elle définie la relation entre les différents services de la direction
d’exploitation et de la maintenance, le service de formation et la
direction d’étude et de développement Informatique.
65
Division Processus DERSS Code Activités Description de l’activité
Division de soutien
technique et de
maintenance
-étude technique concernant les réseaux
et les équipements informatiques.
-maintenance technique des
équipements informatiques
PRC/16 -analyse des demandes
-la demande du client doit être analysée avant l’autorisation de
l’intervention, afin de filtrer et de réduire les activités inutiles ou
interdites et pour appliquer la politique du CIMSP en matière de
service surtout concernant les conventions avec les
établissements sous-tutelles.
PRC/17
-intervention curative
-description des démarches appliquées par la CIMSP en matière
d’exécution des interventions curatives internes par l’équipe du
CIMSP ou externes par des sous-traitants, et ceci, sur les
équipements du parc informatique du CIMSP ou bien des parcs
informatiques des établissements sous-tutelles, l’intervention
peut être sur site du client, par télémaintenance ou bien à l’atelier
du CIMSP
PRC/18
-intervention préventive
-description des démarchés appliquées par le CIMSP en matière
d’exécution des interventions préventives internes par l’équipe
du CIMSP ou externe par des sous-traitants, sur les équipements
du parc informatique du CIMSP ou bien des parcs des
établissements sous-tutelles, l’intervention peut être sur site du
client, par télémaintenance ou bien au siège du CIMSP.
Division des
réseaux et de la
sécurité
-étude technique concernant les réseaux
et les équipements informatiques.
-maintenance technique des
équipements informatiques.
PRC/16 -analyse des demandes
-la demande du client doit être analysée avant l’autorisation de
l’intervention, afin de filtrer et de réduire les activités inutiles ou
interdites et pour appliquer la politique du CIMSP en matière de
service surtout concernant les conventions avec les
établissements sous-tutelles.
PRC/17 -intervention curative
-description des démarches appliquées par la CIMSP en matière
d’exécution des interventions curatives internes par l’équipe du
CIMSP ou externes par des sous-traitants, et ceci, sur les
équipements du parc informatique du CIMSP ou bien des parcs
informatiques des établissements sous-tutelles, l’intervention
peut être sur site du client, par télémaintenance ou bien à l’atelier
du CIMSP
66
Division Processus DERSS Code Activités Description de l’activité
PRC/18 -intervention préventive -description des démarchés appliquées par le CIMSP en matière
d’exécution des interventions préventives internes par l’équipe
du CIMSP ou externe par des sous-traitants, sur les équipements
du parc informatique du CIMSP ou bien des parcs des
établissements sous-tutelles, l’intervention peut être sur site du
client, par télémaintenance ou bien au siège du CIMSP.
-Gestion des accès internet. PRC/31
-Gestion des pannes réseaux
-assurer la gestion internet pour répondre aux exigences des
clients dans les brefs délais.
PRC/13
-établissement des conventions pour l’accès à
internet et email
-établir un contrat avec l’établissement pour lui fournir des
services internet et email.
PRC/14
-gestion des comptes internet et email
-création, modification et remplacement des comptes internet et
email.
PRC/15 -configuration des comptes internet et email -configuration des nouveaux comptes internet et email sur les
équipements.
Non Définis
Non Définis
Non Définis
-Etude de l’architecture réseau
-L’étude consiste à déterminer l’architecture réseau à mettre en
place et les différents équipements associés.
cette étape peut se faire pour la configuration d’une nouvelle
connexion ou la correction des failles de sécurité ou l’ajout d’un
composant réseau.
-Supervision réseau
-Il s’agit de s’assurer du bon fonctionnement des équipements et
service réseaux.
Cette activité se fait quotidiennement, en cas de détection
d’anomalie l’équipe intervient pour la maintenance.
-Supervision sécurité réseau
-La sécurité concerne deux aspects :
Mise en place de la politique de la sécurité
Supervision de la sécurité
Assurer la sécurité des services et des données échangées entre
les utilisateurs (l’intégrité, la confidentialité et la disponibilité).
-Assistance technique
-Résolution des problèmes d’accès aux services fournis
-Suivi des projets télémédecine -Suivi des projets télémédecine
-Maintenance matériel réseau
-La maintenance regroupe les actions de dépannage et de
réparation, de réglage, de révision, de contrôle et de vérification
des équipements matériels et immatériels.
67
Division Processus DERSS Code Activités Description de l’activité
-Configuration (conception) et mise en place de
l’architecture réseau
-Il s’agit de la mise en place effective de l’architecture déjà
étudiée au niveau de l’activité « Etude de l’architecture réseau ».
c’est la mise en place des solutions de communication.
Cette étape peut se faire soit à distance (chez l’utilisateur) soit au
centre.
elle comporte l’étude, le suivi et validation de câblage.
Tableau 4. 2.Processus et activités du DERSS.
Chapitre 4 Analyse des risques
68
RQ : le tableau 4.3 comporte les activités formelles du centre, ces activités sont rédigées dans
des procédures écrites mais ca n’empêche qu’il existe des activités qui sont pratiquées
réellement dans la division de réseau et de la sécurité qui sont pas couvertes par les
procédures officielles du CIMSP, ils appartiennent à aucun processus des processus de la
DERSS (Non Définis), et des activités qui sont documentés mais qui sont pas respectées.
b) L’identification des dysfonctionnements et les conséquences de chaque
activité
Activité Dysfonctionnements Conséquences
-Sauvegarde des
données
-Inaccessibilité des données
-Inaccessibilité du logiciel de
sauvegarde
-Manque du matériel
-Risque de perte de données vitale
-Pilotage logique et
sécurité physique
-Indisponibilité de l’accès internet
-Inaccessibilité à la salle machine
et aux serveurs
-Mécontentement des clients
-Affectation du
correspondant au site
-Indisponibilité du correspondant
sur site
-Perte de savoir –faire
-Gestion des incidents -Application non disponible
-Documentation inexacte
-Perte de la fiche d’incident
-Glissement de l’activité et
mécontentement des clients.
-Gestion des
escalades
-Application non disponible
-Indisponibilité ou manque de
connaissance ou d’expérience du
niveau en cours.
-Retarde de prise en charge et
de réponse et mécontentement
des clients
-Revue mensuelle des
niveaux de service
-Absence d’un planning
-Services non maitrisé et
divulgation des secrets
professionnels
-Gestion
administrative des
postes clients
-Indisponibilité d’une base de
données de gestion des
configurations
-Parc non maitrisé, intervention
sur des postes non déclarés et
non respect des procédures
formelles
Chapitre 4 Analyse des Risques
69
-Installation des
applications
informatiques
-Manque de ressource humaine
pour effectuer les installations
-Absence d’un planning
-Mécontentement des clients
-Tests et validation
des applications
-Absence d’un planning
-Inaccessibilité du produit à tester
-Absence d’une fiche de livraison
pour test
-Mécontentement des clients
-Assistance des
utilisateurs
-Indisponibilité du réseau
téléphonique
-Mécontentement des clients et
abandonnement de l’application
-Supervision réseau -Indisponibilité des outils de
supervision
-Absence du personnel
correspondant ou surcharge par
une autre activité
-problème de connectivité (LS
CIMSP/BBN en panne)
-Problème d’électricité
-Interruption de l’activité de
supervisionQQQA
-Etude de
l’architecture réseau
-Manque des personnels qualifiés
pour faire l’étude
-Absence des moyens de
transport vers le site
-Manque des données (exemple
absence du plan du site)
-Interruption de l’activité de
l’étude
-Deux conséquences : Faire un
travail supplémentaire (établir
un nouveau plan) et par
conséquent perte du temps et
perte d’argent (faire recours à
un cabinet externe)
-Configuration et
mise en place de
l’architecture réseau
-Manque de matériels ou logiciels
-Problème avec le facteur externe
(problème LS Télécom)
-Non-conformité du cahier de
charge
-Indisponibilité d’outil
-Absence des moyens de
transport vers le site
-Absence de coordination entre
CIMSP et le client
-Architecture établie mais
manquante
-Architecture non mise en place
-Supervision sécurité
réseau
-Manque de conscience côté
utilisateurs
-Indisponibilité des moyens de
sécurité
-Manque de procédure de sécurité
-Arrêt des équipements et des
logiciels de sécurité
-Arrêt des services non protéger
(Internet, email)
-Continuité des services sans
protection
-Assistance technique -Pas de disponibilité des outils de
communication fiables
-Manque de compétences
-Insatisfaction du client
Chapitre 4 Analyse des Risques
70
-Manque de personnel
-Suivi des projets
télémédecine
-Panne connexion externe
-Panne unité centrale
-Panne logiciel
-Problème d’interconnexion entre
la station et les équipements
médicaux
-Manque des équipements
médicaux
-Manque des équipements
informatiques (caméra, IP,…etc.)
-L’activité télémédecine est
interrompue qui engendre un
arrêt de transfert de fichier
-Pas de nouveaux examens à
enregistrer
-Pas de visioconférence
-Gestion des pannes
réseau
-Indisponibilité de l’application
gestion des pannes
-Indisponibilité du personnel
-Pas d’enregistrement des
nouvelles pannes
-Maintenance matériel
réseau
-Problème de compréhension des
réclamations
-Dépendance de partenaire
(problème de localisation des
pannes
-Problème non résolu
Tableau 4.3.Dysfonctionnements et conséquences des activités de la DERSS.
c) Échelle de valeurs des dysfonctionnements globale au niveau de la DERSS
La dernière étape dans l’élaboration de l’échelle de valeurs des dysfonctionnements,
n’est que le rassemblement de tous les dysfonctionnements dans un tableau récapitulatif de
l’ensemble des dysfonctionnements et de seuils de criticité de toutes les activités de la
DERSS. MEHARI distingue quatre niveaux de gravité ou de criticité, noté de 1 à 4, dont les
définitions générales sont définies ci-après :
Niveau 4 vital : A ce niveau, le dysfonctionnement redouté est extrêmement grave et
met en danger l’existence même ou la survie de l’entité ou de l’une de ses activités
majeurs. Si un tel dysfonctionnement survient, l’ensemble du personnel est concerné
et peut se sentir menacé dans son emploi. Pour des organismes dont la fonction ne
saurait être remise en cause, en particulier les services publics, ce niveau de gravité
peut remettre en question l’existence du service et le redéploiement de la fonction dans
d’autres services ou ministères.
Niveau 3 très grave : Il s’agit là des dysfonctionnements très graves au niveau de
l’entité, sans que son avenir soit compromis. A ce niveau de gravité, l’ensemble ou
une grande partie du personnel concerné dans ses relations sociales et ses conditions
de travail. Mais sans risque direct pour son emploi. En termes financiers, cela peut
Chapitre 4 Analyse des Risques
71
amputer significativement le résultat de l’exercice, sans que les actionnaires se
dégagent massivement. En termes d’image, on considérera souvent à ce niveau une
perte d’image dommageable qu’il faudra plusieurs mois à remonté ; même si l’impact
financier ne peut être évolué avec précision.
Niveau 2 important : Il s’agit là de dysfonctionnements ayant un impact notable au
niveau des opérations de l’entité, de ses résultats ou de son image, amis restant
globalement supportables. Seule une partie limitée du personnel serait très impliquée
dans le traitement des conséquences du dysfonctionnement avec un impact significatif
sur les conditions de travail.
Niveau 1 non significatif : A ce niveau, les dommages encourus n’ont pratiquement pas
d’impact sur les résultats de l’entité ni sur son image, même si certains personnes sont
fortement impliquées dans le rétablissement de la situation d’origine.
72
Sous processus Dysfonctionnements Gravité
-sauvegarde des données
-destruction des données
Non significatif Important Très grave Vital
-Effacement des données récentes
(moins d’un mois)
-Effacement des données d’un
mois
-Effacement des données
d’une année
-Effacement de
tout
l’historique
-inaccessibilité au logiciel de
sauvegarde
-indisponibilité du logiciel de
sauvegarde <1 jour
-Indisponibilité du logiciel de
sauvegarde<1semaine
-Indisponibilité du logiciel
de sauvegarde durant
1 mois
-Indisponibilité
du logiciel de
sauvegarde
>moins
-manque du matériel
-pendant quelques jours -pendant plus qu’une semaine
-Pilotage logique et sécurité physique -indisponibilité de l’accès
internet
-Indisponibilité temporaire de l’accès
internet
-Indisponibilité du réseau
WAN pour plus de 1 jour
-inaccessibilité à la salle machine
et aux serveurs
-indisponibilité des serveurs pour
quelques heures
-indisponibilité des serveurs
pour un jour
-indisponibilité des
serveurs pour plus qu’un
jour
-affectation du correspondant au site -indisponibilité du correspondant
sur site
-Indisponibilité durant moins de 1
jour
-Indisponibilité>1jour
-Gestion des incidents -application indisponible
-Indisponibilité <1jour -Indisponibilité de
l’application des incidents
pour 1 semaine
-Indisponibilité
de l’application
des incidents
pour 1 mois
-documentation inexacte
-indisponibilité du service pendant
une période de temps
-perte de la fiche d’incident -indisponibilité du service pendant
une période de temps
-Gestion des escalades
- application indisponible
-Indisponibilité <1jour
-Indisponibilité de
l’application des incidents
pour 1 semaine
-Indisponibilité
de l’application
des incidents
pour 1 mois
73
Sous processus Dysfonctionnements Gravité
-indisponibilité ou manque de
connaissance ou d’expérience du
niveau en cours.
-retard d’intervention ne dépasse pas
une heure
-retard qui dépasse un mois
-Gestion administrative des postes clients -indisponibilité d’une base de
données de gestion des
configurations
-manque de suivi pendant des mois -Manque de suivi pendant des
années
-installation des applications informatiques -manque de ressource humaine
pour effectuer les installations
-retard pour 1 ou 2 jours
-absence d’un planning -retard pour 1 ou 2 jours
-revue mensuelle des niveaux de service -Absence d’un planning -manque d’évaluation des niveaux de
service pour un mois
-manque d’évaluation pour
une année
-tests et validation des applications -absence d’un planning -retarder l’activité de test
-inaccessibilité du produit à
tester
-défaut de conformité du produit
-absence d’une fiche de livraison
pour test
-retarder l’activité de test pour une
autre fois
-assistance des utilisateurs -indisponibilité du réseau
téléphonique
-indisponibilité du réseau
téléphonique
-gestion des comptes internet et email
-Dépassement du délai -délai< 3jours
-délai> 3jours -délai>1mois
-Problème d’accès aux BD -Inaccessible pendant <1 jour
-Entre 1 jour et 3 jours -délai> 3jours
-Pas d’envoi des login et PW aux
clients
-délai< 3 jours -délai> 3 jours -délai> 1 mois
-gestion des pannes réseau -Pas d’enregistrement des
nouvelles pannes
-période<30 jours et il y’ a pas des
pannes critiques -période>30 jours, La liste
des pannes pendant ce mois
n’est pas identifier par
conséquent, les pannes
critiques ne seront plus traiter
à temps
-supervision réseau
-Indisponibilité des outils
-Indisponibilité des fichiers log>1
mois
-Un outil est hors service
pendant 1 jour
-Toutes les applications
sont est hors service >1 j
74
Sous processus Dysfonctionnements Gravité
-Absence de personnel ou
surcharge
-délai= > 2 jours -délai>1semaine
-Pb de connectivité
-délai= > 1jour -délai= >2 jours
-Pb matériel -délai= > 1jour -délai= >2 jours
-suivi des projets télémédecine -Interruption de l’activité -En cas de non urgence -En cas d’urgence
-Pas de nouveaux examens
enregistrés
-En cas de non urgence -En cas de non urgence
-Configuration (conception) et mise en place de
l’architecture réseau
-Retard de l’établissement de
l’architecture
-période<1 semaine -période>10 jours -période>30 jours
-La non-conformité avec
l’architecture étudiée
-période<1 jour -période> 1 jour si la
configuration de la sécurité
est non conforme
-période> 10 jours si
configuration de la sécurité
est non conforme
-maintenance matériel réseau -Retard dans la maintenance qui
entraine un retard dans les
services correspondants
-période> 1 jour + il n’y a pas d’arrêt
au niveau des services
-période> 5 jours + arrêt des
services importants
-période>30 jours quelque
soit le service
- sécurité des réseaux -Indisponibilité des moyens de
sécurité
-Arrêt des services non protégés
(Internet, email)
-Arrêt des services de sécurité au
niveau d’un poste de travail (antivirus
désinstallé, firewall désactivé …)
-Arrêt des services de sécurité
pour un établissement c.à.d.
manque d’ACL au niveau du
routeur
-Arrêt de la sécurité
globale (au niveau du
centre) <1min
-Continuité des services sans
protection
-Continuité pour les
postes de travail >1jour
-assistance technique -Le non satisfaction du client -Nbre de clients non satisfaits <5% du
Nbre total
Nbre de clients<50% -Nbre de clients>50% -Nbre de
clients=100%
Tableau 4. 4.Echelle de valeurs des dysfonctionnements globale.
Chapitre 4 Analyse des risques
75
4.3.3.2 Classification des ressources du système d’information
Après l’élaboration de l’échelle de valeurs des dysfonctionnements, qui représente le
résultat principal de l’analyse des enjeux de la sécurité puisqu’il est directement lié aux
processus et aux activités fondamentales de la DERSS, on va passer à l’identification et la
classification des ressources du système. On a identifié les ressources selon le service ou la
direction où ils sont exploités, si ce logiciel ou cette application est officialisé ou pas, la
personne qui est responsable de cette ressource, et enfin sa description. Ces ressources sont
soit des ressources logicielles, soit des ressources matérielles : des serveurs ou des routeurs.
Après, on a classé les ressources selon les trois critères de classification de l’information qui
sont la disponibilité, l’intégrité et la confidentialité. L’échelle de classification varie de 1 à 4.
76
Type
Service Officialisé Responsable description
Dis
ponib
ilit
é
Inté
gri
té
Con
fiden
tial
ité
Ressources logicielles
CVS test DERSS Oui Faouzi ben Dahmen 4 4 3
CVS web DERSS Oui Faouzi ben Dahmen 4 4 3
GLPI Gestion des sites Oui Houssem Hajri GLPI(Gestionnaire libre
de parc informatique) est
un logiciel de gestion de
parc informatique et de
gestion des services
d'assistance.
4 4 3
Gestion des Congés Exploitation Oui Romdhane Khoueja C’est une application qui
gère les congés du
personnel du CIMSP.
2 2 2
OSSEC Réseau Non Wajih Zouaoui C’est un système de
détection d’intrusions.
4 4 2
OSSIM Réseau Non Wajih Zouaoui C’est un système de
management de sécurité
de l’information, il
permet l’administration
du réseau.
4 4 2
PhpMyadmin Exploitation Non Romdhane Khoueja Gérer les bases de
données de toutes les
applications du CIMSP.
4 4 3
Centreon Sécurité Oui Faouzi Laarouchi Un logiciel de
surveillance et de
supervision réseau, fondé
sur le moteur de
récupération
d'information libre
Nagios.
4 4 3
77
Type
Service Officialisé Responsable description
Dis
ponib
ilit
é
Inté
gri
té
Confi
den
tial
ité
Nagios Sécurité Oui Faouzi Laarouchi Une application
permettant la
surveillance système et
réseau. Elle surveille les
hôtes et services
spécifiés, alertant lorsque
les systèmes vont mal et
quand ils vont mieux
4 4 2
Back UP pc Exploitation Non Romdhane Khoueja Un logiciel libre de
sauvegardes
informatiques. Il est
utilisé pour sauvegarder
sur disque un ensemble
de postes clients et de
serveurs.
4 4 2
Syslog NG Réseau Non Wajih Zouaoui Syslog-ng est une
implémentation du
protocole syslog pour les
architectures de type
UNIX.
4 4 3
Nino Réseau Non Wajih Zouaoui Supervision réseau 4 4 3
Gestion des pannes Réseau Oui Makram
Bouabdallah
Gérer les pannes réseaux 2 2 3
Gestion des comptes Réseau Oui Makram
Bouabdallah
Gérer les comptes e-
mails et internet
4 4 4
Gestion des stratégies Réseau Oui Makram
Bouabdallah
Gérer les stratégies de
sauvegarde
4 4 3
GMAO Maintenance Oui Adel Tmar Gestion de la
Maintenance
Assistée par Ordinateur
3 3 2
78
Type
Service Officialisé Responsable description
Dis
ponib
ilit
é
Inté
gri
té
Confi
den
tial
ité
CAPEX Télémédecine Non Wajih Zouaoui Assurer les
fonctionnalités de
télémédecine.
2 2 2
MRTG Réseau Non Multi Router Trafic
Grapher : créer des
graphiques sur le trafic
réseau en utilisant le
protocole SNMP pour
interroger des
équipements réseaux.
Ressource matérielles
Serveurs
Serveur POP Réseau Oui Makram
Bouabdallah
Serveur de messagerie
principal, contenant les
boîtes e-mail et la base
de données des
utilisateurs.
4 4 4
Serveur POP secondaire Réseau Oui Makram
Bouabdallah
Serveur de messagerie
secondaire, contenant les
boîtes e-mail et la base
de données des
utilisateurs.
2 2 2
Serveur SMTP entrant
Réseau Oui Makram
Bouabdallah
Réception et filtrage des
emails.
3 3 3
Serveur antivirus
CIMSP
DERSS Oui Neji Chihaoui Serveur antivirus local. 2 2 1
79
Type
Service Officialisé Responsable description
Dis
ponib
ilit
é
Inté
gri
té
Confi
den
tial
ité
Serveur WSUS DERSS Oui Neji Chihaoui Serveur de mise à jour
Microsoft (contient les
correctifs et les services
pack pour les produits
Microsoft).
2 2 2
Serveur antivirus HC DERSS Oui Neji Chihaoui Serveur antivirus pour
les sites distants.
2 2 1
Serveur CVS DERSS Oui Faouzi Laarouchi Serveur de versions. 4 4 4
Serveur OSSIM Réseau Non Wajih Zouaoui Serveur de supervision
de sécurité du réseau de
la santé.
3 3 2
Serveur NINO + Syslog
Réseau Non Wajih Zouaoui Serveur de supervision
du réseau RNS + serveur
Syslog NG.
3 2 3
Serveur proxy central 2 Réseau Oui Brahim Hamdi Proxy pour les
établissements de la
santé + Authentification
Mysql + journal des
accès
3 3 2
Serveur proxy central 3 Réseau Oui Brahim Hamdi Proxy pour les
établissements de la
santé + Authentification
Mysql + journal des
accès
3 3 2
Serveur proxy CIMSP Réseau Oui Brahim Hamdi Proxy pour les
établissements de la
santé + Authentification
Mysql + journal des
accès
3 3 3
80
Type
Service Officialisé Responsable description
Dis
po
nib
ilit
é
Inté
gri
té
Confi
den
tial
ité
Serveur de test des
applications
DERSS Oui Romdhan Khouaja Applications pour la
DEM et contrôle des
états des serveurs clients.
4 4 2
Serveur des
applications
d’exploitation
DERSS Oui Houssem Hajri Applications
d’exploitation et
contrôle des états des
serveurs clients et les
tests applicatives + la
sauvegarde
4 4 2
Site web (apache) +
GLPI
DERSS Oui Houssem Hajri Sites web + bases des
données + GLPI et ses
bases de données.
3 3 2
App_CIMSP DERSS Oui Zied Dhouib Les applications du
bureau d’ordre et DAAF
4 4 3
Routeurs
Routeur Clients Réseau Makram
Bouabdallah
Permet l’interconnexion
entre le CIMSP et les
clients distants (LS).
4 4
Routeur ATI Réseau Makram
Bouabdallah
Garantit l’interconnexion
entre le CIMSP et l’ATI.
4 4
Routeur CNI Réseau Makram
Bouabdallah
Garantit l’interconnexion
entre le CIMSP et le
CNI.
4 4
Routeur LAN CIMSP Réseau Makram
Bouabdallah
Garantit le bon
fonctionnement du LAN
de la CIMSP.
4 4
Tableau 4. 5.Classification globale des ressources.
Chapitre 4 Analyse des risques
81
4.3.4 Gravité des dysfonctionnements majeurs
Afin d’évaluer la gravité des dysfonctionnements déjà déterminé, on a identifié les
dysfonctionnements ayant un impact de 3 ou 4 et on a déterminé la potentialité de ces derniers
à partir d’un entretien avec les responsables de chaque service.
Tableau 4.6.Evaluation de la gravité.
Dysfonctionnement P I G
Dépassement du délai de création des comptes pour une période
supérieur à un mois
1 3 2
Problème d’accès aux BD pour une période supérieur à 3jours 1 3 2
Pas d’envoi des login et PW aux clients pour une période supérieur à
un mois
1 3 2
Indisponibilité des outils : Toutes les applications sont hors service
pour une période supérieur à 1 jour
2 3 3
Absence de personnel ou surcharge pour une période supérieur à une
semaine
1 3 2
Problème de connectivité pour une période supérieur ou égal à 2 jours 3 3 3
Problème matériel pour une période supérieur ou égal à 2 jours 3 3 3
Retard de l’établissement de l’architecture pour une période supérieur
à 30 jours
2 3 3
La non-conformité avec l’architecture étudiée pour une période
supérieur à 10 jours si configuration de la sécurité est non-conforme
2 3 3
Indisponibilité des moyens de sécurité 2 3 3
Arrêt des services non protégés (Internet, email) : Arrêt de la sécurité
globale (au niveau du centre) pour une période inférieure à 1minute
3 3 3
Continuité des services sans protection : Continuité pour les postes de
travail pour une période supérieur à 1jour
3 3 3
Le non satisfaction du client pour un nombre de clients pour un
Nombre supérieur à 50%
1 3 2
Le non satisfaction du client pour un nombre de clients égal à 100% 1 4 2
Interruption de l’activité de télémédecine : En cas d’urgence 2 3 3
Pas de nouveaux examens enregistrés : En cas d’urgence 2 3 3
Retard dans la maintenance qui entraine un retard dans les services
correspondants pour une période supérieur à 30 jours quelque soit le
service
1 3 2
L’indisponibilité de l’application des incidents pour un mois 2 3 3
La panne des serveurs pour plus de 1 jour 3 3 3
Indisponibilité du logiciel de sauvegarde pour plus de 1 mois
2 4 3
Destruction de toutes les données 2 4 3
Chapitre 4 Analyse des risques
82
4.4 Analyse des risques à partir des bases de connaissance de MEHARI
Le processus d’analyse d’une situation de risque comprend une démarche de base, on
peut résumer cette démarche par les lignes suivantes :
Chaque situation de risque peut être évaluée par une potentialité intrinsèque et un
impact intrinsèque, en absence de toute mesure de sécurité. Ces deux derniers sont
évaluables.
Des mesures de sécurité peuvent venir réduire ce risque par des mesures significatives
de réduction de risque. Ces mesures d’atténuation de risque sont évaluables.
A partir de ces éléments, on va déterminer la potentialité et l’impact résiduel et d’en
déduire une gravité de risque. La figure 4.2 présente ces différentes étapes [18].
Figure 4.2.Processus d'analyse des risques.
4.4.1 Le scénario de risque
Un scénario de risque est la description d’un dysfonctionnement et de la manière dont
ce dysfonctionnement peut survenir. Le dysfonctionnement comprend lui-même un sinistre,
c’est-à dire des détériorations directes et des conséquences indirectes de ce sinistre.
4.4.2 Analyse d’un scénario de risque
L'objectif de cette analyse est d’évaluer deux paramètres caractéristiques du risque
encouru par l’entreprise ou l’organisme dans l'hypothèse d'occurrence d'un tel scénario. Ces
paramètres sont les suivants :
Chapitre 4 Analyse des risques
83
La potentialité du risque qui représente, en quelque sorte, sa probabilité d'occurrence,
bien que cette occurrence ne soit pas modélisable en termes de probabilité. Cette
potentialité est fonction du contexte et des mesures de sécurité en place.
L'impact du risque sur l'entreprise représente la gravité des conséquences directes et
indirectes qui découleraient de l'occurrence du risque.
4.4.2.1 Evaluation de la potentialité d’un scénario de risque
L’objectif est de répondre à cette simple question : ‘L’occurrence du risque analysé,
c’est-à-dire le fait que le scénario se déroule jusqu’au moment où il y a un sinistre réel, est-
elle plus ou moins probable ?’. L’évaluation de la potentialité sera faite en fonction de deux
paramètres qui sont l’exposition naturelle ou la potentialité intrinsèque et deux autres facteurs de
réduction de risque qui sont le facteur dissuasif et le facteur préventif. Alors, on va évaluer cette
potentialité 3 choses qui sont :
L’exposition naturelle à la situation de risque ;
Le risque pris par les auteurs ;
Les conditions de survenance du scénario.
a) L’exposition naturelle
Ce facteur diffère d’une entreprise à une autre pour plusieurs raisons : L’activité de
l’entreprise, son contexte économique, social, géographique, ce qui fait que chacune est plus
ou moins exposée à chaque type de risque. On évalue l’exposition naturelle en absence de
toute mesure de sécurité. Le tableau 4.7 de l’exposition naturelle représente l’évaluation des
certains événements qui sont : les accidents, les actes volontaires malveillants, les actes
volontaires non malveillants et les erreurs. Chaque type d’événement comporte plusieurs
événements qu’on a évalué la potentialité de leur survenance d’une échelle de 1 à 4.
Chapitre 4 Analyse des risques
84
Tableau 4.7.Exposition naturelle.
P=1
Très
improbable
P=2
Plutôt
improbable
P=3
Plutôt
probable
P=4
Très
probable Stat
us-E
xpo
AccidentsAC01 Court-circuit au niveau du câblage ou d'un équipement. x 3
AC02 Chute de la foudre x 3
AC03 Incendie naissant dans les locaux : corbeille à papier, cendrier, etc. X 2
AC04 Accidents dus à l'eau ou à des liquides (fuite d'une canalisation, liquides
renversés accidentellement, etc.).
X 2
AC05 Inondation causée par une canalisation percée ou crevée X 2
AC06 Inondation causée par la crue d'une rivière ou une remontée de la nappe
phréatique
x 1
AC07 Inondation causée par l'extinction d'un incendie voisin, X 2
AC08 Coupure d'énergie de longue durée pour une cause extérieure x 3
AC09 Indisponibilité totale des locaux : Interdiction d'accès décidée par la
préfecture (risque de pollution, d'émeute, etc.)
x 1
AC10 Disparition de personnel stratégique x 3
AC11 Panne d'un équipement de servitude (alimentation électrique, climatisation,
etc.)
x 3
AC12 Panne matérielle d'un équipement informatique ou télécom x 4
AC13 Défaillance matérielle d'un équipement informatique ou télécom impossible
à résoudre par la maintenance, ou indisponibilité du prestataire
x 1
AC14 Blocage applicatif ou système impossible à résoudre par la maintenance,
pour cause de disparition de la SSII ou du fournisseur.
x 3
AC15 Saturation accidentelle de ressources X 3
AC16 Accident d'exploitation conduisant à une altération de données X 3
AC17 Effacement de données ou de configurations, par un virus X 3
AC18 Perte accidentelle de f ichiers de données par un automate X 3
AC19 Perte accidentelle de f ichiers de données par vieillissement, pollution, X 2
AC20 Perte accidentelle de f ichiers de données due à une panne d'équipement
(crash de disque dur)
x 4
Actes volontaires malveillantsMA01 Vandalisme depuis l'extérieur : tir d'armes légères ou lancement de
projectiles depuis la rue,
x 1
MA02 Vandalisme intérieur : petit vandalisme par des personnes autorisées à
pénétrer dans l'établissement (personnel, sous-traitants, etc.).
x 1
MA03 Terrorisme sabotage par des agents extérieurs : explosifs déposés à
proximité des locaux sensibles,
X 1
MA04 Saturation répétitive malveillante de moyens informatiques par un groupe
d'utilisateurs
X 2
MA05 Saturation du réseau par un ver x 3
MA06 Effacement volontaire (direct ou indirect) de support de logiciel x 3
MA07 Altération malveillante (directe ou indirecte) des fonctionnalités d'un logiciel
ou d'une fonction d'un programme bureautique (Excel ou Access)
x 2
MA08 Entrée de données faussée ou manipulation de données X 3
MA09 Accès volontaire à des données ou informations partielles et divulgation X 3
MA10 Détournement de f ichiers ou vol de support de données X 3
MA11 Effacement volontaire (direct ou indirect), vol ou destruction de support de
programmes ou de données
X 3
MA12 Vol de micro-ordinateur portable en dehors des locaux de l'entreprise. x 4
MA13 Effacement malveillant de configurations réseau x 3
MA14 Effacement malveillant de configurations applicatives ou systèmes X 2
MA15 Détournement de code source de programmes X 2
MA16 Espionnage étatique ou de maffias (demandant de très gros moyens) X 1
MA17 Vol d'équipement informatique ou télécom, à l'intérieur des locaux X 3
Actes volontaires non malveillantsAV01 Absence de personnel d'exploitation : grève du personnel d'exploitation X 2
AV02 Départ de personnel stratégique X 3
AV03 Pénétration du SI d'une tierce société, par du personnel interne ou non X 3
AV04 Utilisation de logiciels sans licence X 3
ErreursER01 Dégradation involontaire de performances, à l'occasion d'une opération de
maintenance
x 3
ER02 Effacement accidentel de logiciel par erreur humaine X 3
ER03 Altération accidentelle des données pendant la maintenance X 3
ER04 Erreur pendant le processus de saisie, X 4
ER05 Bug dans un logiciel système, un middlew are ou un progiciel X 4
ER06 Bug dans un logiciel applicatif X 4
ER07 Erreur lors de la modif ication de fonctions de feuilles de calcul ou de
macro-instructions,
X 3
Évaluation de l'exposition naturelle
Évaluation de la potentialité des événements suivants
Chapitre 4 Analyse des risques
85
b) Le risque pris par les auteurs
La deuxième question à se poser est limitée aux scénarios résultant d’une action
volontaire menée par une personne physique, action pouvant représenter un risque pour son
auteur. Il s’agit, en particulier, de toutes les actions volontaires, malveillantes ou non, nuisibles
pour l’entreprise ou pouvant être considérées comme nuisibles par l’entreprise. Le risque pris par
l’auteur peut être un frein à son action. Il s’agit donc de s’interroger sur l’existence de facteurs
pouvant freiner la volonté d’agir des acteurs potentiels. Ces facteurs là sont les facteurs dissuasifs
ils sont représentées au sein de l’annexe 2.
c) Les conditions de survenance
La troisième et dernière question à se poser est relative aux conditions dans lesquels le
scénario peut se dérouler et au caractère plus ou moins trivial de ces conditions. Le
déclenchement d'un scénario de risque n'aboutira à un sinistre réel que si certaines conditions
sont réunies. Plus ces conditions sont triviales, plus le risque est grand. Il s’agit donc de
s’interroger sur l’existence des actions ou facteurs génératrices de réduction de risque. Ces
facteurs là sont les facteurs préventifs sont représentées au sein de l’annexe 2. La figure 4.3
représente les facteurs de la Potentialité.
Figure 4.3.Les mesures de la potentialité.
La Potentialité est ainsi une évaluation globale d’un niveau de probabilité, qui tient compte
d’une potentialité intrinsèque, mesurée par l’exposition naturelle, et de deux facteurs de
réduction du risque, la dissuasion et la prévention. On utilise pour cette évaluation les grilles
de la base des connaissances MEHARI.
Chapitre 4 Analyse des risques
86
4.4.2.2 Evaluation de l’impact d’un scénario de risque
L’objectif est ici de répondre à cette simple question : « Si le risque analysé se produit,
quelle sera la gravité finale de ses conséquences ? » Beaucoup de facteurs peuvent jouer pour
rendre plus ou moins graves les conséquences du risque, son impact. Evaluer l’impact d’un
scénario de risque consiste à analyser :
L’impact intrinsèque ;
L’atténuation des conséquences directes du risque par son confinement ;
L’atténuation des conséquences indirectes par des mesures palliatives ;
Le transfert du risque sur des tiers.
a) L’impact intrinsèque
Lors d'une analyse de risque MEHARI, il est fait appel à la notion d'impact intrinsèque
d'un scénario qui est l'évaluation des conséquences de l'occurrence du risque,
indépendamment de toute mesure de sécurité. On a évalué l’impact intrinsèque directement
suite à un entretien avec les responsables, cette évaluation est une évaluation maximaliste des
conséquences du risque, en dehors de toute mesure de sécurité. Le tableau 4.8 présente
l’impact intrinsèque.
b) Les mesures de confinement ou de protection
Ces mesures visent à limiter le risque et ses conséquences les plus ‘directes’. Il s’agit
donc de s’interroger sur l’existence de facteurs pouvant limiter la gravité des conséquences
directes du risque, dans l’espace ou dans le temps, et ceci en référence à la gravité maximale
évaluée auparavant. Il existe des mesures génératrices de réduction de risque qui sont des
mesures de confinement, appelées aussi mesures de protection. Ces mesures sont le plus
souvent des mesures de détection/réaction. Les valeurs numériques sont représentées au sein
de l’annexe 2.
c) Les mesures palliatives
Ces mesures visent à limiter le risque et ses conséquences les plus ‘indirectes’. Il s’agit
donc de s’interroger sur les réactions possibles, une fois le risque constaté. Il existe des
mesures génératrices de réduction des conséquences indirectes du risque qui sont les mesures
palliatives. Les valeurs numériques sont représentées au sein de l’annexe 2.
Chapitre 4 Analyse des risques
87
d) Les mesures de récupération
Ces mesures visent à limiter les pertes finales en transférant une partie sur des tiers, il
peut s’agir de l’assurance ou au recours en justice par exemple. Les valeurs numériques sont
indiquées au sein de l’annexe 2.
Tableau 4.8.Impact intrinsèque.
Classification des données, informations et éléments d'infrastructure D I C
D01 Fichiers de données ou bases de données applicatives 4 4 4
D02 Fichiers bureautiques partagés 3 3 3
D03 Fichiers bureautiques personnels 3 3 3
D04 Informations écrites ou imprimées détenues par les utilisateurs, archives personnelles 3 3
D05 Listings ou états imprimés des applications informatiques 3
D06 Messages échangés, écrans applicatifs (données partielles) 4 4 4
D07 Courrier et télécopies 3 4 4
D08 Archives patrimoniales ou ayant valeur de preuve 2
D09 Données et informations publiées sur des sites publics ou internes 3 4 4
R01 Équipements et câblage du réseau étendu (systèmes réseau avec leurs logiciels) 3 3
R02 Équipements et câblage des réseaux locaux (systèmes réseau avec leurs logiciels) 3 3
R03 Données de configuration du réseau étendu 3 4 3
R04 Données de configuration des réseaux locaux 2 3 3
S01 Systèmes centraux, serveurs applicatifs et équipements périphériques centraux, serveurs
de fichiers partagés
3
4
S02 Fichiers de configuration des systèmes et serveurs 3 4 3
S03 Systèmes terminaux mis à la disposition des utilisateurs (PC, imprimantes locales,
périphériques, interfaces spécifiques, etc.) 3
A01 Application logicielle ou progicielle, middleware (code exécutable) 3 4 3
A02 Code source 3 4 4
A03 Fichiers des configurations applicatives 3 3 3
A04 Progiciels spécifiques utilisateurs 2
3 3 2
E01 Environnement de travail des utilisateurs 3
E02 Équipements de télécommunication orale ou analogique 3 3
I01 Ensemble des installations d'une salle informatique et télécom 3
Impacts intrinsèques ne dépendant pas de la classification d'une ressource Indisponibilité du personnel
P01 Équipes de spécialistes métiers 3
P02 Personnel d'exploitation 3
C01 Non conformité à la loi ou aux réglementations relatives à la protection de la vie privée 1
C02 Non conformité à la loi ou aux réglementations relatives aux contrôles financiers 1
C03 Non conformité à la loi ou aux réglementations relatives à la propriété intellectuelle 1
C04 Non conformité à la loi relative à la protection des systèmes informatisés 1
C05 Non conformité aux réglementations relatives à la sécurité des personnes et à la
protection de l'environnement
1
Non conformité à la loi ou à la réglementation (NC)
Données et informations
Infrastructure informatique et télécom
Infrastructure générale
Non Conformité
Chapitre 4 Analyse des risques
88
L’impact est ainsi une évaluation globale d’un niveau de conséquences qui tient
compte de l’impact intrinsèque et de trois facteurs d’atténuation du risque, la protection, la
palliation et la récupération. On utilise pour cette évaluation les grilles de la base de
connaissance MEHARI. La figure 4.4 représente les facteurs de l’impact.
Figure 4.4.Les mesures de l'impact.
4.4.2.3 Evaluation de la gravité
La gravité du scénario ou de la situation de risque résulte à la fois de sa potentialité et
de son impact. Il ne s’agit pas d’une opération mathématique entre ces deux valeurs mais d’un
simple jugement sur le caractère acceptable ou non de la situation. G est la gravité globale
évaluée par la grille en fonction de l’impact (I) et de la potentialité (P), une G de 4 correspond à
un risque insupportable, une gravité de 3 à un risque inadmissible et les gravités inférieures à des
risques tolérés. On définie trois types de risques à savoir les risques insupportables, qui
devraient faire l’objet de mesures d’urgence, en dehors de tout cycle budgétaire. Les risques
inadmissibles qui devraient être réduits ou éliminés à une échéance à déterminer, donc à
prendre en compte dans une planification, par exemple dans un plan de sécurité. Et
dernièrement Les risques tolérés. Les deux premières catégories correspondent à ce que nous
avons appelé les risques inacceptables.
G est la gravité globale évaluée par la grille en fonction de l’impact (I) et de la
potentialité (P), une gravité de 4 correspond à un risque insupportable, une gravité de 3 à un
risque inadmissible et les gravités inférieures à des risques tolérés. Les calculs de la gravité de
chaque scénario sont représentés au sein de l’annexe 2. La grille d’acceptabilité des risques
utilisé et validé selon les besoins du centre est la suivante :
Chapitre 4 Analyse des risques
89
Figure 4.5.Grille d'évaluation de la gravité.
4.4.2.4 Expression des besoins de sécurité
L’expression des besoins de sécurité consiste à évaluer des besoins consolidés et à les
classer, après avoir évalué la gravité des scénarios de risque en s’appuyant sur une analyse de
l’état des services de sécurité. Cette étape est basée sur la définition des besoins des services
décrite ci après.
a) Les besoins de service
Un besoin de service de sécurité est établi pour chaque scénario, en s’appuyant sur les
principes suivants :
Besoin de service relatif à un scénario donné.
Un service de sécurité donné peut avoir un effet sur la gravité d'un scénario.
Si tel est le cas, il est considéré qu'il existe, pour ce service, et du fait de ce scénario, un
besoin de service. Quantitativement, ce besoin de service sera d’autant plus important que :
Son influence (traduite par son coefficient d’influence), pour ce scénario, sera forte ;
La gravité du scénario considéré sera élevée ;
La qualité actuelle du service sera faible.
Ainsi, pour un service i face à un scénario k, le besoin de service sera calculé par la formule
suivante :
𝐵𝑆𝑖𝑘 = 𝑒𝑖𝑘 .𝑏𝐺𝑘 . (4 − 𝑖)
Dans laquelle :
𝐵𝑆𝑖𝑘 = Besoin de service pour le service i face au scénario k
𝑒𝑖𝑘 = Coefficient d’influence du service i pour le scénario k
b = Base générale paramétrable
𝐺𝑘 = Gravité du scénario k
Chapitre 4 Analyse des risques
90
𝜎𝑖 = Qualité du service i ; [(4-𝜎𝑖) en étant donc le complément à 4]
b) La synthèse des besoins de service
La synthèse des besoins du service 𝐵𝑆𝑖 , pour un service i donné, sera évaluée par
simple sommation :
𝐵𝑆𝑖 = 𝐵𝑆𝑖𝑘𝑘
Tableau 4.9.Priorités des besoins des services.
Contrôle d'accès aux locaux sensibles 1687459,84
Contrôle des droits d'administration 1329489,92
Protection de l'information écrite ou échangée (téléphone, messagerie) 930611,2
Sécurité des données lors des échanges et des communications sur le réseau local 785607,68
Assurances 661504
Paramétrage et contrôle des configurations matérielles et logicielles 603914,24
Sécurité des données lors des échanges et des communications 524288
Contrôle des accès aux zones de bureaux 442368
Contrôle d'accès aux systèmes et applications 430858,24
Continuité de service de l'environnement de travail 425328,64
Contrôle, détection et traitement des incidents du réseau local 334936,96
Sécurité des procédures d'exploitation 312616,96
Sécurité de l'architecture réseau et continuité du service 237332,48
Contrôle, détection et traitement des incidents sur le réseau étendu 234946,56
Contrôles d'accès sur le réseau local de "données" 223833,6
Confinement des environnements 209715,2
Contrôle des connexions sur le réseau étendu 135987,2
Sécurité de l'architecture du réseau local 130905,6
Protection des postes de travail 119664,64
Contrôle d'accès physique au site et aux bâtiments 85483,52
Gestion et enregistrement des traces 76195,84
Sécurité de l'architecture 53248
Sécurité incendie 52362,24
Sécurité contre les dégâts des eaux 47810,56
Services généraux 31006,72
Continuité de l'activité 16384
Protection de la propriété intellectuelle 967,68
Respect de la législation concernant les rapports avec le personnel et avec des tiers 512
Gestion des ressources humaines 0
91
Figure 4.6.Représentation graphique des besoins des services.
0
200000
400000
600000
800000
1000000
1200000
1400000
1600000
1800000
Besoin
Chapitre 4 Analyse des risques
92
Cette représentation graphique représente les besoins des 29 services de
sécurité d’après la méthode MEHARI, les services les plus prioritaires ont un score
plus grand, alors le R.S.S.I doit regarder en premier lieu ceux qui ont des grands
valeurs. Ceux-ci méritent plus d’entretien. D’après nos résultats d’audit, les services
contrôle d’accès aux locaux sensibles a un score de 1687459.84 c’est le service le plus
vulnérable pour le CIMSP dans la phase d’audit organisationnel et physique.
4.5 Conclusion
Dans ce chapitre, on a conclu la phase de l’analyse des risques. Pendant cette phase,
on a adopté deux approches complémentaires : une se base sur une analyse des risques suite à
une analyse des enjeux du CIMSP et l’autre se base sur la base de connaissances de
MEHARI. Dans la première, on a analysé les risques à partir d’une analyse des enjeux. Cette
analyse a été réalisée suivant une échelle de valeur des dysfonctionnements à partir de
laquelle on a sélectionné les dysfonctionnements les plus importants pour évaluer leurs
gravités suite à une évaluation de la potentialité et de l’impact. Dans la deuxième approche,
on a analysé les risques en se basant sur la base de connaissance de MEHARI. On a aussi
évalué la potentialité et l’impact ensuite la gravité des risques déjà sélectionnés à partir de la
base. Après cette étape, on a exprimé les besoins de sécurité des services pour exposer les
services ayant plus de besoins en matière de sécurité et qui méritent une mise en œuvre des
mesures correctives pour neutraliser ce besoin.
Chapitre 5 Audit Technique
93
Chapitre 5
Audit Technique
5.1 Introduction
Après la phase de l’audit organisationnel et physique, on va entamer la phase de l’audit
technique qui permet d’avoir une vue globale de l’état de sécurité du SI afin d’identifier les
vulnérabilités et les failles qu’il contient. D’abord, on va essayer d’auditer l’architecture du
système en focalisant la reconnaissance du réseau et du plan d’adressage, le sondage des
systèmes, le sondage des services et des flux réseau et le sondage des flux réseau, de tester.
Ensuite, on va passer à l’audit des vulnérabilités internes et/ou externe, et l’architecture de
sécurité existante. Enfin, on va auditer la messagerie interne Lotus notes et le système
d’exploitation Unix.
5.2 Outils d’audit utilisés
Durant l’audit technique, on a utilisé une panoplie d’outils ; on a sélectionné parmi
plusieurs outils disponibles ceux qui répondent mieux à nos besoins. Pour la cartographie du
réseau, nous avons choisi NetCrunch 5 qui est un outil permettant de détecter
automatiquement et identifier les serveurs et les périphériques utilisant le SNMP et les ajouter
aux cartes logiques et physiques. Il permet également de signaler l’état d’un nœud spécifique
du réseau. Cet outil se distingue par des fonctionnalités supplémentaires comme par exemple
la supervision directe de l’état du nœud (s’il est connecté ou pas) et selon son emplacement
locale. Pour le sondage système, on a choisi GFI Languard, cet outil est le plus connu et le
plus utilisé pour ce type de sondage. On a utilisé GFI Languard pour effectuer un audit rapide
de sécurité sur le réseau en utilisant la résolution Netbios et DNS des adresses IP car il
regroupe des informations enregistrées sur les postes de travail telles que les noms
d’utilisateurs, le système d’exploitation, les sessions en cours, les services installés, les
vulnérabilités,…etc.
Pour le sondage des services réseau, on a choisi Nmap qui est un scanner de ports conçu pour
détecter les ports ouverts, les services hébergés et les informations sur le système
d'exploitation d'un ordinateur distant. On a choisi ce logiciel parce qu’il est devenu une
référence pour les administrateurs réseaux, car l'audit des résultats de Nmap fournit des
indications sur la sécurité d'un réseau en plus, il est libre et gratuit et c'est le meilleur outil
pour accomplir cette phase d’audit.
Chapitre 5 Audit technique
94
Pour le sondage des flux réseau, on a choisi Wireshark qui est outil permettant d’effectuer
des captures sur les flux réseau ainsi qu’une analyse du trafic. Pour l’audit des vulnérabilités,
on a choisi l’outil Retina qui est reconnu comme le scanner de vulnérabilité le plus rapide. Il
est capable d'analyser toutes les machines du réseau, tous les types de systèmes
d'exploitation, les périphériques en réseau. Il identifie les points faibles et les corrige par des
recommandations. Retina est capable de repérer non seulement les déficiences répertoriées
mais également certaines qui ne le sont pas encore. Cet outil se distingue par une interface
simple à manipuler, des rapports des vulnérabilités et des recommandations complets ainsi
que des statistiques et des représentations graphiques significatives.
5.3 Description de la salle machine
La salle machine se situe au rez-de chaussée, elle est accessible que par les personnes
autorisés via un scan de leurs empreintes digitale. A l’intérieur de la salle, le poste
d’administration est séparé du reste de la salle par un séparateur en verre qui assure un
environnement climatique adéquat pour les équipements réseaux et les serveurs qui se
trouvent à l’intérieur. La pièce comporte 6 grandes armoires d’équipements et des serveurs,
un bloc de climatisation, deux onduleurs dont chacun possède deux batteries et deux autres
climatiseurs qui ne fonctionnent qu’en cas de panne du bloc de climatisation. Le sol de la
salle est couvert par des faux planchers qui facilitent le passage des câbles courants. Il existe
aussi un détecteur d’humidité et un système d’extinction d’incendie.
5.4 Audit de l’architecture réseau
L’audit de l’architecture réseau comprend les étapes suivantes, commençant par la
reconnaissance du réseau et du plan d’adressage puis le sondage des systèmes et finalement
terminent le sondage des services et des flux réseaux. Avant de détailler les différents
éléments de cette étape, voici la figure 5.1 qui représente l’architecture globale du réseau
incluant les différentes composantes du réseau avec les marques des équipements.
95
Figure 5.1.Architecture globale du CIMSP.
Chapitre 5 Audit Technique
96
Description de l’architecture : la figure 5.1 décrit l’architecture globale du réseau CIMSP.
Le centre utilise le réseau Ethernet dont la topologie est en étoile. Le firewall est redondant,
ils sont les deux des produits Cisco PIX 525. Le CIMSP utilise les six pattes du firewall
reliant les différents sous réseaux. On va décrire les différentes pattes une par une. Le premier
lien est la patte de ‘outside’, elle relie l’ATI et les clients ADSL au centre. Ces clients sont
reliés au firewall à travers un commutateur HP 2524, ce dernier est relié à un autre
commutateur Cisco ME 3400 niveau 3, qui connecte l’ATI à travers une connexion fibre
optique de 34Mb/s et la sonde IDS du centre. La deuxième patte est la patte partenaires, elle
relie la CNI par un routeur Cisco 2600 et une connexion LS de 2 Mb/s, à travers un
commutateur CATALYST 3060 G de niveau 3. La troisième patte est la patte messagerie, elle
relie la première zone démilitarisée (DMZ), qui contient tous les serveurs messagerie, au
firewall à travers un commutateur HUAWEI S3525 de niveau 2. Ces serveurs sont les
serveurs POP, le serveur POPs, le serveur SMTP et le serveur SMTPin.ils sont tous des
produits DELL Power Edge 2600. La quatrième patte est la patte publique, elle relie la
deuxième DMZ au firewall à travers le commutateur CATALYST. Cette zone contient les 2
serveurs web sur les quels ils sont hébergés les 2 portails du centre, l’un est un DELL Power
Edge 2850 et l’autre est un HP Protant DL 300 GS, elle contient aussi les 2 proxy qui sont
dédiés aux clients CIMSP et qui sont les 2 des produits de Siemens RX 200, de plus elle
comprend 2 serveurs DNS qui sont des produits DELL Precision, 2 serveurs RASIDON, un
serveur d’application GLPI et un serveur Antivirus qui est un Siemens RX 200.La cinquième
patte est la patte d’administration, elle relie le poste d’administrateur au firewall à travers un
commutateur HUAIWEI S3525 de niveau 2. La sixième et la dernière patte est la patte clients,
elle relie le LAN du CIMSP et les établissements sanitaires. Le LAN est relié par le routeur
NAT, qui est un Cisco 2800, au firewall à travers le commutateur CATALYST. Il existe des
établissements sanitaires qui sont connectés au centre par le BackBone à travers un routeur
HUAIWEI 3600 Series et à travers aussi une connexion fibre optique par le commutateur
Cisco ME 3400 qui est lui-même relié au commutateur CATALYST et d’autre qui sont reliés
par des LS de 2Mb/s au routeur Cisco AS 5400. Le BackBone est composé de 7 nœuds
couvrants tout le territoire national. Enfin, il existe 2 VLANs niveau 1 gérés par le
commutateur HUAIWEI S3525et 7 VLANs niveau 3 gérés par le commutateur CATALYST
3060G.
Chapitre 5 Audit Technique
97
5.4.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éseaux, seront identifiés. Alors, on va 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, on commence par un recueil des données concernant les
équipements inventoriés. Par la suite on utilise des outils de découverte automatique de la
topologie du réseau pour la détection des stations de travail, des routeurs et du pare feu. Pour
ce faire on utilise les outils suivants qui permettent de connaitre le plan d’adressage IP et de
déterminer la topologie du réseau. Voici la cartographie du réseau interne du CIMSP ayant le
plan d’adressage 172.20.0.XXX par l’outil AdRem NetCrunch 5 qu’on l’a déjà présenté dans
la section outils d’audit utilisés.
Figure 5.2.Cartographie du réseau interne du CIMSP.
Chapitre 5 Audit Technique
98
Analyse : Suite au résultat du scan avec l’outil Netcrunch, on constate que le CIMSP utilise
l’adresse 193.95.84.XXX de la classe C pour la connexion publique et utilise l’adressage
réseau privé 10.94.0.XXX de la classe A et l’adresse 172.20.0.XXX de la classe B qui sont les
adresses du réseau interne du CIMSP. On remarque que les noms des machines (PC) sont
significatifs c.-à-d. chaque machine prend le nom du personne qu’il utilise (Nom
machine=Nom personne). De plus, on a remarqué l’inexistence d’un un serveur de domaine
pour permettant la gestion des comptes utilisateurs.
Afin d’Identifier des limites de découpage, le tableau 5.1 présente les six pattes du firewall,
les masques réseaux et les adresses débuts et les adresses fin.
Les pattes firewall Les masques
réseaux
@ broadcast @1er
hôte @ dernier hôte
Patte1 : Outside
ATI
193.95.84.224/29 193.95.84.XXX 193.95.84.225 193.95.84.230
Patte2 : Partenaires CNI 10.94.0.3/22 10.94.0.XXX 10.94.0.1 10.94.3.0
Patte3 : Messagerie 193.95.84.16/29 193.95.84.XXX 193.95.84.17 193.95.84.22
Patte4 : Publique 193.95.84.0/28 193.95.84.XXX 193.95.84.1 193.95.84.14
Patte5 : Admin 172.16.1.100/24 172.16.1.XXX 172.16.1.0 172.16.1.254
Patte6 : Clients
LAN CIMSP
193.95.84.205/28
172.20.0.0/23
193.95.84.XXX
172.20.0.XXX
193.95.84.217
172.20.0.1
193.95.84.205
172.20.0.254
Tableau 5.1.Le plan d'adressage IP.
On signale à cet égard, que la configuration réseau au niveau des postes n’est pas protégée
contre les modifications. En effet, chaque utilisateur peut changer son adresse ce qui peut
générer des conflits d’adresses. Des attaques de type IP Spoofing peuvent être facilement
menées et générer un déni du service; il suffit de remplacer l’adresse IP du poste par celle
d’un équipement critique comme les routeurs, les serveurs,…etc. Cette attaque permet la
dégradation des performances de l’équipement concerné voir même son arrêt complet.
Chapitre 5 Audit Technique
99
Figure 5.3.Image écran de configuration réseau au niveau du poste.
5.4.2 Sondage des systèmes
Cette étape consiste à auditer les stations connectées au réseau afin de déterminer les
noms des machines qui sont les noms des utilisateurs, leurs adresses IP ainsi que le système
installé et leur version. La figure 5.4 montre que 95% des systèmes d’exploitation sont des
Windows hors que 5% est divisé entre les utilisateurs de Unix, qui sont les administrateurs
réseau et les administrateurs systèmes ainsi il est installé sur quelques serveurs du CIMSP.
Figure 5.4.Répartitions systèmes d'exploitation.
On a réalisé le sondage système pour toutes les stations connectées au réseau du CIMSP. Pour
ce scan on a utilisé l’outil GFI Languard.
Chapitre 5 Audit Technique
100
Chapitre 5 Audit Technique
101
Figure 5.5.Sondage GFI LanGuard.
On a constaté que la majorité des machines du réseau CIMSP sont vulnérable et surtout
au niveau protection et correctives système. Puisque après ce scan, on a pu déterminer
les noms des machines qui sont dans la plupart du temps les noms des utilisateurs, leurs
adresses IP ainsi que le système d’exploitation installé. C’est grâce au service NetBIOS
qui activé sur 80% des machines, que on a pu avoir toutes ces informations. Ce service
est réservé à la résolution des noms et les ouvertures de sessions. Le NetBIOS permet de
faire la correspondance entre l’adresse IP et le nom de la machine qui est parfois le nom
de l’utilisateur lui même.
Chapitre 5 Audit Technique
102
Figure 5.6.Répartition du service NETBIOS sur les postes du CIMSP.
5.4.2.1 Partage des fichiers
Le contrôle d’accès étant insuffisant sur les serveurs et les postes de travail
spécifiquement fortement sur les partages, les utilisateurs peuvent supprimer des fichiers
contenant des informations sensibles ; les répertoires de travail partagés sur les postes de
travail ou les serveurs, sans que l’on puisse identifier la personne à l'origine de cet acte.
Figure 5.7.Capture écran des partages réseau.
Il n’existe pas une politique d’accès aux partages, l’accès à ces fichiers n’est pas protégé par
mot de passe dans la plupart des postes de travail. La figure 5.7 représente des documents
Chapitre 5 Audit Technique
103
critiques et confidentielles qui sont partagés et non protégés ; un accès complets en lecture,
écriture et suppression sur chaque élément partagés.
Figure 5.8.Capture écran des fichiers partagés non protégés.
5.4.2.2 Politique de sauvegarde et de restauration
A l’heure actuelle, la politique de sauvegarde est insuffisante. Les données privatives
des utilisateurs ne sont pas sauvegardées. Il n’existe pas une procédure et outils de sauvegarde
des données des utilisateurs. Chaque poste de travail est dépositaire d’un certain nombre de
fichiers critiques qui ne sont pas sauvegardés. De plus, on remarque l’absence d’une politique
de restauration des données des serveurs ainsi que la vérification des cartouches de
sauvegarde n’est pas réalisée à la fin de chaque opération.
5.4.3 Sondage des services réseau
Le but de cette étape est l’identification des services actifs sur le réseau ce qui permet
de savoir les ports ouverts des équipements audités. Cette étape permet de relier chaque port
ouvert à un service et à un protocole ainsi d’identifier les partages réseau. D’après le
responsable réseau, on a su que chaque serveur est la responsabilité d’une seule personne qui
doit effectuer l’audit des ports ouverts selon ses besoins et non pas d’une façon formalisée.
Chapitre 5 Audit Technique
104
L’outil de scan utilisé est Nmap qu’on a déjà présenté. La figure 5.9 est un exemple d’un
rapport Nmap.
Figure 5.9.Scan Nmap.
D’après le résultat des balayages des ports, on a constaté au niveau serveur antivirus CIMSP
que le port 445, qui représente une porte d'accès potentielle aux systèmes qui sont mal
protégés, est ouvert et non utilisé et le port 12345 qui est utilisé pour la configuration de la
communication du serveur antivirus trend et les postes clients est ouvert. Ce port doit être
bloqué car il est aussi utilisé par le cheval de Troie Netbus. Au niveau proxy CIMSP, le port
XHX (10000) est ouvert en principe ce port est utilisé par un cheval de Troie (backdoor). De
plus, le port TELNET ouvert sur le serveur ministère et le port 25 : SMTP est ouvert dans la
plupart des serveurs. Ce port doit être désactivé s’il n’est pas utilisé. Le port 119 pour NEWS
est ouvert dans la plupart des serveurs donc il faut le désactiver s’il n’est pas utilisé aussi.
Le port 5802 pour Y3KRAT et 6006 pour BadBlood sont des Trojans, ils sont ouverts au
niveau serveur sauvegarde et le port 513 pour rlogin est ouvert au niveau serveur sauvegarde
et au niveau du serveur ministère car ce protocole est cible des attaques de type IP Spoofing.
D’autres ports il faudra décider de leur utilité: 135 (tcp and udp), 137 (udp), 138 (udp) et 139
(tcp).
5.4.4 Sondage des flux réseau
On va analyser le trafic au niveau du réseau dont l’objectif de reconnaître les
protocoles et les services prédominant au niveau du réseau. Cette analyse permet aussi de
récupérer plusieurs autres informations à caractère confidentiel circulant dans le réseau en
clair. Dans cette section, on utilise les outils Wireshark pour intercepter les flux de données.
Chapitre 5 Audit Technique
105
Figure 5.10.Capture écran du trafic réseau.
On a pu identifier l’existence de plusieurs protocoles actifs superflus qui génèrent des
informations gratuites et qui pourraient être exploitées par des personnes malintentionnées
pour mener des attaques. Les protocoles identifiés sont les suivants:
Cisco Discovery Protocol (CDP) : Il est utilisé pour obtenir des adresses des
périphériques voisins et découvrir leur plate-forme. CDP peut aussi être utilisé pour
voir des informations sur les interfaces qu’un routeur utilise.
Internetwork Packet Exchange (IPX) : il est employé pour transférer l'information sur
des réseaux qui fonctionnent avec le système d'exploitation NetWare.
Spanning Tree Protocol (STP) : il permet d’apporter une solution à la suppression des
boucles dans les réseaux pontés et par extension dans les VLANs.
Le protocole SNMP « le nom de la communauté Public » est activé. Il est utilisé pour
la surveillance du réseau, Un attaquant peut utiliser ce service réseau pour obtenir des
informations précieuses au sujet dues systèmes internes, tel que les informations sur
les équipements réseaux et les connections en cours.
5.5 Audit des vulnérabilités
Au cours de cette étape, on va s’intéresser à l’analyse des vulnérabilités (intrusif
interne et intrusif externe) au niveau de tous les composants du réseau audité, via un ensemble
d’outils d’exploration automatique et par l’édification d’une analyse ciblée du réseau. Il s’agit
d’identifier les éventuelles vulnérabilités de chaque serveur ou de chaque équipement afin de
trouver la parade efficace.
Chapitre 5 Audit Technique
106
5.5.1 Audit des vulnérabilités intrusif interne
L’audit de vulnérabilités intrusif interne permet de mesurer les vulnérabilités des
composants du réseau les plus sensibles. Cette phase comprend une analyse des vulnérabilités
des équipements de communication en exploitation qui sont le serveur d’exploitation et le
serveur CVS, et une analyse des vulnérabilités des postes de travail visant l’ensemble des
postes des utilisateurs du réseau audité. L’outil utilisé dans ce scan est Retina.
5.5.1.1 Audit des serveurs
Nous allons présenter les vulnérabilités au niveau du serveur d’exploitation :
Figure 5.11.Les pourcentages des vulnérabilités.
37.50% , équivalent à 12, est le pourcentage des informations d’audit et le pourcentage des
vulnérabilités avec un niveau de risque moyen, 18.75%, équivalent à 6, représente le
pourcentage des vulnérabilités avec un niveau de risque bas et 6.25%, équivalent à 2,
représente les vulnérabilités avec un haut niveau de risque.
Figure 5.12.Synthèse des vulnérabilités.
Cet extrait représente les 18 vulnérabilités retrouvées sur le serveur d’exploitation, on va
décrire 4 vulnérabilités selon leurs degrés de gravité.
Chapitre 5 Audit Technique
107
La vulnérabilité numéro 2 : Il s'agit d'une vérification d'information. Retina a détecté la
version 1.1 du protocole HTTP sur le système cible.
La vulnérabilité numéro 17 : Le compte administrateur sur le système cible n'est pas
renommé. Renommer le compte, permet de le rendre un peu plus difficile pour les
personnes non autorisées de deviner la combinaison de nom d'utilisateur et le mot de
passe privilégiés. Cette vulnérabilité est de faible gravité.
La vulnérabilité numéro 3 : La version 2 du Secure Sockets Layer (SSL) a été détectée.
Ce protocole est connu par des faiblesses cryptographiques ainsi que d'autres
vulnérabilités exploitables. Cette vulnérabilité est de moyenne gravité.
La vulnérabilité numéro 16 : De Multiples vulnérabilités non spécifiées ont été
identifiées dans Samba qui pourrait être exploités pour exécuter des codes arbitraires
ou pour provoquer le démon en panne. Cette vulnérabilité est d’un haut niveau de
gravité.
Nous allons présenter les vulnérabilités au niveau du serveur CVS :
Figure 5. 13.Pourcentage des vulnérabilités.
49.37% , équivalent à 39, est le pourcentage des informations d’audit, 22.78% ,équivalent à
18, représente le pourcentage des vulnérabilités avec un niveau de risque moyen, 17.72%,
équivalent à 14, représente le pourcentage des vulnérabilités avec un niveau de risque bas et
10.13%, équivalent à 8, représente les vulnérabilités avec un haut niveau de risque. Voici les
20 premiers vulnérabilités.
Chapitre 5 Audit Technique
108
Figure 5.14.Synthèse des vulnérabilités.
Cet extrait représente les 20 vulnérabilités retrouvées sur le serveur CVS, on va décrire 4
vulnérabilités selon leurs degrés de gravité.
La vulnérabilité numéro 2 : Il s'agit d'une vérification d'information. Retina a détecté la
version 1.0 du protocole HTTP sur le système cible.
La vulnérabilité numéro 3 : Retina a trouvé sur cette hôte, une partition anonyme et
accessible. Note: Linux / Unix qui exécute Samba sont également touchés par cette
notification. Cette vulnérabilité est de faible niveau de gravité.
La vulnérabilité numéro 14 : L'âge maximal de mot de passe est le nombre maximum
de jours avant que le mot de passe de l’utilisateur expire. Il est recommandé aux
utilisateurs de changer leur mot de passe au moins une fois tous les 60 jours. Cette
vulnérabilité est d’un niveau de gravité moyen.
La vulnérabilité numéro 10 : Un débordement de tampon existe dans le module
mod_rewrite d'Apache qui est utilisé pour les demandes fondées sur des expressions
régulières. Un débordement de tampon existe dans le traitement des requêtes LDAP
qui peut permettre à un attaquant anonyme d’exploiter un système à distance et
exécuter du code arbitraire. Cette vulnérabilité est d’un haut niveau de gravité.
Chapitre 5 Audit Technique
109
5.5.1.2 Audit des postes de travail
Figure 5.15.Pourcentage des vulnérabilités.
7.69%, équivalent à une seule information d’audit, 30.77% ,équivalent à 4, représente le
pourcentage des vulnérabilités avec un niveau de risque bas, 23.08%, équivalent à 3,
représente le pourcentage des vulnérabilités avec un niveau de risque moyen et 38.46%,
équivalent à 5, représente les vulnérabilités avec un haut niveau de risque. Voici les 13
vulnérabilités analysés par Retina.
Figure 5.16.Synthèse des vulnérabilités.
Cet extrait représente les 13 vulnérabilités retrouvées sur un poste de travail, on va décrire 4
vulnérabilités selon leurs degrés de gravité.
La vulnérabilité numéro 1 : Il s'agit d'une vérification d'information. Le service (FTP) a
été détecté en cours d'exécution sur le poste scanné. FTP envoie les noms d’utilisateur,
les mots de passe et les données non cryptées. Ce service n’est pas utilisé par le centre
mais il est ouvert sur quelques postes, il fallait s’assurer de son utilité.
La vulnérabilité numéro 5 : la commande VRFY peut conduire un attaquant distant à
récupérer le premier et le dernier nom enregistré à n’importe quel compte e-mail
donné. Cela peut aider un attaquant à faire des attaques de type social engineering.
Chapitre 5 Audit Technique
110
La vulnérabilité numéro 6 : Le service Telnet est activé sur ce poste de travail. Ce
service permet à un utilisateur distant de se connecter à une machine. Il envoie tous les
noms d'utilisateur, mots de passe et les données non cryptées. Cependant, il peut être
exploité pour réaliser des attaques complexes de type DoS. Le centre utilise le
protocole ssh pour les connexions à distance pour plus de sécurité mais cette politique
n’est pas appliquée sur les postes de travail des simples utilisateurs, elle n’est appliqué
que pour les serveurs et les postes des administrateurs. Cette vulnérabilité est de
moyenne gravité.
La vulnérabilité numéro 10 : Il existe plusieurs versions d’OpenSSH sur ce poste qui
peuvent entraîner un dépassement d'entier et d'élévation de privilèges. Un attaquant
peut utiliser cette vulnérabilité pour obtenir un accès administrateur à distance à
n'importe quel serveur utilisant OpenSSH. Cette vulnérabilité est d’un haut niveau de
gravité.
5.5.2 Audit de vulnérabilités intrusif externe
Le but de cet audit est de tester la résistance de l’architecture technique de sécurité
face aux éventuelles attaques, en opérant dans des conditions analogues à celles dont
disposerait une personne mal intentionnée ayant des connaissances sur le système
d’information du centre. L’objectif de cette phase est d’identifier pour chaque vulnérabilité le
type des applications et des services actifs ainsi que le niveau des mises à jour des systèmes
d’exploitation. Pour réaliser ce type de test, on a utilisé le framework Metasploit.
5.6 Audit de l’architecture de la sécurité existante
L’objectif de cette phase est d’examiner l’architecture technique déployée et de
mesurer la conformité des configurations équipements réseaux, pare-feu, routeurs,…etc. avec
la politique de sécurité définie et les règles de l’art en la matière. On va commencer tout
d’abord par l’audit du pare-feu et des règles de filtrages ensuite on va auditer les routeurs.
5.6.1 Audit du pare-feu et des règles de filtrages
Un pare-feu est une structure destinée à empêcher un intrus de la traverser. Ils sont
conçus pour protéger un réseau local privé de l'Internet. En effet, chaque ordinateur connecté
à Internet est susceptible d'être victime d'une intrusion pouvant compromettre l'intégrité du
système, ou permettre de voler ou d'altérer des données. Chaque pare-feu possède des règles
Chapitre 5 Audit Technique
111
de filtrages qui permettent de gérer l’accès ; accepter ceux qui sont autorisés et rejeter ceux
qui ne sont pas.
5.6.1.1 Description du pare-feu
Le pare feu implémenté dans le CIMSP est un Cisco PIX, il est considéré comme le
produit le plus performant, occupe la première place du marché. A ce titre, il est le produit
phare de Cisco en matière de sécurité depuis 1996. Installé sur un réseau, le PIX détermine si
le trafic est autorisé, dans un sens ou dans l’autre. Le cas échéant, il active la connexion ;
celle-ci aura un impact quasiment nul sur les performances du réseau. Les données d’un trafic
non autorisé sont détruites. Le PIX se base donc sur les couches 3 et 4 du modèle OSI et peut
assurer le suivi des échanges et utilise l'ASA (Adaptive Security Algorithm) pour ce filtrage
dynamique. Si les paquets d'une communication sont acceptés alors les paquets suivants de
cette communication seront acceptés implicitement. Il peut aussi contrôler l'accès de
différentes applications, services et protocoles et protège votre réseau contre les attaques
connues et courantes. Ce pare-feu gère également le VPN (IKE et IPSec). On peut ainsi créer
des tunnels VPN entre sites. Le Cisco PIX 525 est équipé d’un processeur AMD SC520
cadencé à 600 Mhz. Il dispose de 256 Mo de mémoire vive et d’une mémoire flash de 16 Mo.
Au niveau des interfaces de connexion, le PIX 525 supporte 8 interfaces au maximum et
possède 2 ports Ethernet pour la connexion externe et un commutateur 10/100 ou 10 VLAN
pour le réseau interne.
5.6.1.2 Les règles de filtrages
On a pu consulter les règles de filtrages du pare-feu et selon notre analyse, on constate
que les règles sont divisés en des règles pour l’accès internet, des règles pour l’accès à la zone
DMZ, des règles pour l’accès en interne, des règles pour l’accès au messagerie et des règles
pour l’accès au proxy et enfin, des règles pour l’accès au CNI. Il est bien clair que le nombre
des règles est grand vu que le réseau du CIMSP est très étendu mais ce critère peu agir sur la
performance du pare-feu et ainsi la performance de tout le réseau. On a remarqué aussi
l’existence de quelques règles d’accès pour le serveur RADIUS qui n’est plus utilisé dans
l’architecture réseau du CIMSP ce qui nous mène à dire que ces règles de filtrages ne sont
pas tester régulièrement pour mettre à jour en cas de changement ou de modification.
Chapitre 5 Audit Technique
112
5.6.1.3 Analyse de la liste de contrôle du pare-feu
Pour notre audit pare-feu, on a exploité une liste de contrôle présenté en annexe 3 qui
est spécifique pour les pare-feu CISCO. On va analyser les réponses que le responsable nous
a fournies. Le pare-feu autorise les requêtes ICMP indépendamment des adresses IP source et
destination. Le protocole ICMP permet de collecter des informations sur la topologie du
réseau et sur les équipements de communication. La règle que le pare-feu applique est la
suivante ‘access-list distant_dmz_access_in permit icmp any any’. En ce qui concerne les
logs, nous avons su que qu’ils ne sont pas analysés périodiquement, ils peuvent être révisés
seulement en cas de suspections d’une attaque. De cet effet, les traces des connexions sur le
pare-feu ne sont pas enregistrées. Le PIX 525 ne contient pas des outils pour l’analyse des
audits et la génération des rapports de plus les mises à jour et les derniers patchs ne sont pas
automatiquement téléchargés des sites web du constructeur. Le responsable sur le pare-feu
n’applique pas une procédure pour la vérification des ports ouverts pour déterminer ceux qui
sont utilisés et ceux qui doivent être fermés. Un tel test doit être effectué s’il existe un
contrôle d’intégrité automatisé du pare-feu. Mais au coté de tous ces insuffisances, le pare-feu
primaire du CIMSP est secouru par un autre secondaire qui, en cas de panne du premier,
prend la relève sans interrompre les connexions qui sont établis. Il permet aussi de protéger
tout le trafic destiné aux adresses internes et protège les connexions TCP à distance à travers
la surveillance du bit d’acquittement.
Sa configuration nous permet de connaitre quels serveurs sont sur quelle interface en
s’assurant du bon acheminement du trafic. Son administration peut être éffectué de deux
manière ; à distance par la console de PUTTY et par une interface web qui est facile à gérer
et bien sécurisée.
5.6.2 Audit des routeurs
Généralement, les routeurs sont des éléments physiques qui ont, pour fonction
principale, de prendre un paquet et de le renvoyer au bon endroit en fonction de la destination
finale. On va décrire tout d’abord les différents routeurs qui existe au sein du CIMSP ensuite
on va analyser la liste de contrôle qui vise à recenser les vulnérabilités des routeurs.
Chapitre 5 Audit Technique
113
5.6.2.1 Description des routeurs
L’architecture du CIMSP comporte 4 routeurs qui sont des produits CISCO et un autre
qui est de type HUAIWEI 3600. Ce tableau decrit les différents types de routeur au sein du
CIMSP.
Marque Description
CISCOAS
5300
L'AS5300 est généralement configuré avec 128 Mo de DRAM (maximum) et 16 Mo de
Flash (32 Mo disponibles). Il ya deux ports Ethernet - un 10 et un 10/100. L'AS5300 peut
également être configuré en tant que personne / unité téléphonique. Encore une fois, une
PRI carte est installée dans la fente en bas, et dialup transporteur cartes (AS53-CC-DMM
pour un maximum de 120 modems à haute densité de mica ou AS53-CC-DM jusqu'à 60
modems à faible densité de mica avec jusqu'à 60 ports).
CISCOAS
5400
Cisco série AS5400 est compatible avec tous les types de ports et offre des services de
télécopie, sans fil, voix et données à tout moment. la passerelle AS5400 joue à la fois le
rôle de serveur d'accès distant et de passerelle vocale.
CISCO 2800 La gamme Cisco 2800 supporte la plupart Assurant notamment l’interconnexion de sites
distants à haut débit sur des connexions wan T1/E1 ou xDSL. De plus, ces routeurs
disposent de fonctions de cryptage matérielles directement embarquées sur la carte mère et
ainsi que des emplacements pour des DSP Voix. Ainsi ils disposent en option d’un
système de prévention des intrusions (IPS), de fonctions de pare-feu à inspection d’états,
du support de la téléphonie et de la messagerie vocale. L’architecture de la gamme Cisco
2800 a été spécifiquement conçue pour répondre aux besoins croissants des sites distants
d’entreprise et des PME / PMI en matière d’applications, La gamme Cisco 2800 offre
l’éventail d’options de connectivité le plus large de l’industrie avec des caractéristiques de
disponibilité et de fiabilité à la pointe de la technologie.
CISCO 2600
Series
Cisco 2600 séries est un routeur interarmées modulaire d'accès qui fournit des
configurations flexibles de LAN et de WAN, des options multiples de sécurité, et une
gamme des processeurs à rendement élevé. Avec plus de 70 modules et interfaces de
réseau, l'architecture modulaire de Cisco 2600 séries permet à des interfaces d'être
facilement améliorées pour l'expansion de réseau.
HUAIWEI
3600 Series
Routeurs 3600 modulaire (dénommé R2600/3600 série ci-après) sont développées
indépendamment par Huawei pour les réseaux d'entreprise. Ils peuvent être utilisés
comme routeurs de base en moyenne et de petite taille Intranets, ou comme des serveurs
d'accès à certaines sections principales. Il supporte la sauvegarde mutuelle entre ces
réseaux comme DDN, X.25, PSTN, RNIS et relais de trames. Ils fournirent la solution au
bureau de haute densité à distance. Il supporte un maximum de 112 utilisateurs de modems
analogiques ou 28 utilisateurs de modems ISDN BRI.
Tableau 5. 2.Description des routeurs du CIMSP.
5.6.2.2 Analyse de la liste de contrôle des routeurs
Pour notre audit des routeurs, on a exploité une liste de contrôle présenté en annexe 4
qui est spécifique pour les routeurs de type CISCO. On va analyser les réponses que le
Chapitre 5 Audit Technique
114
responsable nous a fournies. Les routeurs et tous les équipements réseau se situent dans la
salle machine. Cette salle est protégé physiquement et logiquement avec limitation d’accès,
toute personne responsable d’un équipement dans la salle machine a le droit d’y accédé suite à
un analyse de l’empreinte digitale. La salle machine est protégé des interférences
magnétiques et électrostatiques. La gestion des routeurs se fait à travers les lignes de
commandes. En ce qui concerne la documentation, le centre ne possède pas les procédures de
gestion et les changements de configuration des routeurs. Les logs des routeurs ne sont ni
révisés ni contrôlés périodiquement, ils ne sont contrôlées que lorsque si c’est nécessaire et ils
ne sont pas archivés. La cartographie du réseau n’est pas à jour, il y a une carte des sites
distants mais en interne non mais les emplacements des routeurs et des équipements réseau
sont indiqués dans l’architecture réseau du CIMSP. Pour l’administration des routeurs, il
existe deux administrateurs qui ont le droit de faire des modifications. Les changements faits
à partir du réseau ne sont faits que par un contrôle de mot de passe mais ces mots de passe ne
sont pas changés régulièrement. L’administration se fait via le protocole sécurisé SSH avec
authentification des utilisateurs à distance.
La version logicielle du routeur n’est pas suivie, et les mises à jour ne sont pas faites
régulièrement, la dernière version stable à été téléchargé il y a 3 mois. Tous les comptes et
mots de passe par défaut sont supprimés, et on a créée 15 autres comptes par niveau. Les
routeurs sont vulnérables aux attaques de type SYN Flood et de type smurf malgré que les
ports auxiliaires, toute interface inutilisée, les protocoles Finger et ARP sont tous désactivé
sur le routeur.
5.7 Audit des systèmes et des applications
Dans cette section, on s’intéresse à la sécurité des systèmes suivants qu’on juge les
plus critiques pour le centre et qui sont dans notre périmètre d’audit :
Système de messagerie interne LOTUS NOTES
Système d’exploitation UNIX
A cet effet, on a élaboré un ensemble des listes de contrôles concernant la messagerie
interne Lotus Notes et l’Unix.
5.7.1 Audit LOTUS NOTES
Le LOTUS NOTES est l’outil qu’utilise le centre pour le partage de ses données. C’est
un logiciel de travail collaboratif qui gère les courriers et les données du tout le personnel du
centre dans le but d’optimiser le travail et améliorer la communication. La liste de contrôle
Chapitre 5 Audit Technique
115
suivante vérifie quelques contrôles dans la version mise en place qui est la version 7 en
s’assurant de la conformité de celles-ci par rapport aux règles standards de configuration et
d’utilisation.
Tableau 5.3.Liste de contrôle LOTUS NOTES.
5.7.2 Audit système d’exploitation UNIX
On a audité le système d’exploitation Unix à fin de savoir est ce que ils le ont bien
maitrisé au niveau de sécurité. Le système utilisé est SUSE, on a pu contacter l’administrateur
système pour répondre aux questions d’une liste de contrôle proposé dans le tableau 5.3.
N° Critère Contrôle Conformité Remarque
1 Sécurité du ID
File
Est-ce que le contrôle du ID File et des mots de
passe est maintenu correctement?
Oui nombre de
caractères et
complexité de
mot de passe
2 Expiration des ID
File
Tous les ID des fichiers doivent expirer dans
deux ans.
Oui Sauf en cas de
modification et
d’exception
3 Restriction de
l’utilisation des
iNOTES
Utilisation des iNOTES seulemen t quand les
ordinateurs à distance sont sécurisés
Non
4 Logiciels de
backup
Vérifier si l’opération de backup inclut les
fichiers ouverts
Non Il n’ya pas de
backup
5 Disponibilité des
UPS (
Unterruptable
Power Supplier)
Vérifier si le serveur est conne cté à un UPS Non
6 Suppression de
tous les services et
tâches inutiles
Arrêt de tous les services inutiles et suppression
de tous les logiciels non reliés à Lotus Notes
Oui
7 SMTP relaying est
sécurisé
Notes.ini vérifier
SMTPMTA_REJECT_RELAYS=1
SMTP_OCH_REJECT_SMTP_ORIGINATED_
MESSAGES=1
SMTPMTA_RELAY_FORWARDS=1
Oui
8 Cryptage Utilisation de S/MIME Oui
9 Port de cryptage Activation du port de cryptage pour tous les
ports
Non
10 Anti -Virus La messagerie doit être protégée par un anti -
virus
Oui
11 Mise à jour Vérifier les dernières mises à jour du Lotus et du
système d’exploitation
Non
12 Robustesse du
système
d’exploitation
Vérifier les bonnes pratiques au niveau de l’OS Oui
13 Eviter les conflits
de réplication
Vérifier la revue de s réplications de logs des
conflits par l’administrateur
Non
14 Duplication de
bases de données
Les réplications multiples de bases de données
ne doivent pas être stockées dans un seul serveur
Domino.
Non Un seul serveur
existe
15 Maintenance des
utilisateurs
Suppression des utilisateurs qui n’ont plus le
droit d’accès. La liste des utilisateurs doit être
maintenue à jour.
Oui
16 Robustesse des
mots de passe
Vérifier que les mots de passe doivent avoir au
moins 8 caractères
Non 4 caractères
17 Listes d’accès Toutes les bases de données doivent avoir leurs
propres listes d’accès
Oui
18 Accès au niveau
OS
Vérifier si l e contrôle d’accès est implémenté
au niveau du système d’exploitation
Oui
19 Utilisation des
noms complets
Vérifier que d es noms complets sont toujours
utilisés
Oui
20 Restriction pour la
création des bases
de données
La création des bases de données doit être
restreinte pour des utilisateurs spécifiques.
Non
21 Revue du contrôle
d’accès aux
fichiers
importants
Le contrôle d’accès aux fichiers suivants doit
être revu : LOG.NSF, STATREP.NSF,
ADMIN4.NSF, EVENTS4.NSF,
CERTLOG.NSF, NAMES.NSF ?
Oui
Pour
l’administrateur
Chapitre 5 Audit Technique
116
Cette liste comprend des commandes à exécuter afin de vérifier leurs conformités par rapport
aux mesures de sécurité.
Chapitre 5 Audit Technique
117
Chapitre 5 Audit technique
118
Chapitre 5 Audit Technique
119
Tableau 5. 4..Liste de contrôle du système d’exploitation UNIX.
5.8 Conclusion
Ce chapitre s’est étalé sur la phase de l’audit technique en se basant sur des outils de scan
pour évaluer le niveau de sécurité des composants du réseau du CIMSP. On a tout d’abord
audité l’architecture du système qui englobe le plan d’adressage, l’architecture réseau, le
sondage des systèmes et le sondage des services et des flux réseau. Ensuite, on a essayé de
détecter les vulnérabilités des serveurs et des postes de travail appartenant au réseau du centre
afin d’identifier les failles qui peuvent affaiblir le réseau. Après, nous nous sommes
concentrés sur le pare-feu et les routeurs pour auditer l’architecture de sécurité. Finalement,
l’audit applicatif a été consacré pour l’audit du système de messagerie interne LOTUS
NOTES et pour le système d’exploitation UNIX.
Chapitre6 Recommandations et Plan d’action
120
Chapitre 6
Recommandations et Plan d’action
6.1 Introduction
Après avoir terminé l’évaluation technique, on va essayer de déceler les failles de
sécurité et les vulnérabilités des différents composants du système d’information. Dans ce
chapitre, on va orienter les propositions à des recommandations d’ordre organisationnel
physique et d’ordre technique pour pallier aux insuffisances. La mise en place de ces
recommandations peut être faite progressivement selon le degré d’urgence et la disponibilité
des ressources humaines et budgétaires. Pour cette raison, on va focalise la mise en place d’un
plan d’action pour la mise en œuvre de quelques recommandations proposées.
6.2 Les recommandations
Les recommandations sont d’ordre organisationnel, physique et technique. Mais il
existe d’autres qui sont d’ordre stratégique ; on a constaté durant notre mission d’audit que les
processus métiers et les procédures du centre ne sont pas tous formaliser car les processus et
les procédures écrites existantes dans le CIMSP ne couvrent pas la totalité des activités
réellement exercés surtout celle du service réseau. Il est recommandé aussi d’utiliser des
indicateurs de sécurité qui visent à vérifier que les objectifs de sécurité sont atteints et que la
direction générale doit les fixer auparavant, ces indicateurs doivent être adaptés au contexte de
centre. Un exemple d’indicateurs de sécurité fourni par l’ISO 27001 est en proposé en
annexe5.
6.2.1 Recommandations organisationnelles et physiques
Dans cette section, on propose les recommandations organisationnelles et physiques
réparties par thème suivant la norme ISO 17799. Il est recommandé de les mettre œuvre pour
pallier aux insuffisances.
6.2.1.1 Politique de sécurité
Le CIMSP est tenu d’élaborer sa propre politique de sécurité qui doit être approuvée
par la direction, distribuée et publiée à tout le personnel. Chaque employé doit signer et
respecter les termes indiqués dans la documentation de la politique. Le centre possède dune
charte informatique qui n’est communiqué que pour les correspondants des établissements
Chapitre 6 Recommandations et Plan d’action
121
sanitaires et elle est inexistante pour le personnel du CIMSP. Le message qui doit être délivré
à travers la politique de sécurité et la charte informatique est que toute violation de la
confidentialité est un délit punissable selon le degré de sa gravité.
6.2.1.2 Organisation de la sécurité du système d'information
L’organisation de la sécurité consiste à assurer le développement, l’implémentation et
la mise à jour des politiques et des procédures de sécurité. Pour gérer la sécurité, il est
conseillé de prendre en compte les recommandations suivantes :
Un audit sécurité du système d’information doit être réalisé périodiquement et
systématiquement au moins une fois par an.
Une unité de sécurité du système d’information doit être crée et doit être rattachée à la
direction générale. De plus, un responsable de sécurité du système d’information (RSSI) doit
être nommé. Ce dernier aura le rôle d’établir le lien entre son équipe de travail et tous les
autres employés du centre pour avoir des conseils et des informations de tous les services. Il
est chargé de l’élaboration de la politique de sécurité et de définir des règles clairs et
applicables. Il doit s’assurer de leur bonne diffusion, leur compréhension et contrôler leurs
mises en œuvre. Les responsabilités de l’unité de sécurité du système d’information sont les
suivantes ; de suivre et contrôler le respect de la politique de sécurité, de développer un
programme de formation et de sensibilisation du personnel en vue de la sécurité et de la
protection des données et enfin de coordonner toutes les activités reliées à la sécurité
informatique.
Constituer un comité de sécurité du système d’information composé par les responsables de
toutes les directions du centre et dont le RSSI aura un rôle pivot. Chaque responsable va être
le délégué du RSSI pour mettre en œuvre la politique de sécurité et veiller à son respect dans
sa direction.
Le RSSI est tenu d’élaborer un tableau de bord de sécurité pour permettre aux décideurs
d’avoir une idée claire sur la situation à l’aide des indicateurs pertinents facilitant la prise des
décisions adéquates en un temps opportun.
L’utilisation des tableaux de bord pour visualiser le niveau de sécurité du centre.
Le centre doit disposer d'une veille technologique adaptée à ses environnements et à ses
enjeux, avoir par exemple un suivi des vulnérabilités et des correctifs.
Chapitre 6 Recommandations et Plan d’action
122
6.2.1.3 Gestion des biens (des actifs)
Un inventaire global des biens et ressources, y compris les licences associées,
permettant au moins d' identifier les éléments sensibles et vitaux doit être dressé.
Une classification des ressources et des informations doit être effectué selon les trois critères
suivants ; la disponibilité, l’intégrité et la confidentialité.
Le centre doit présenter aux employés une formation appropriée sur l'utilisation des outils
notamment à la mise en production de nouveaux outils pour garantir la bonne utilisation des
ressources.
Les dispositifs de stockage contenant des informations sensibles qui sont physiquement
détruits doivent être effacés de façon sécurisée.
Le câblage électrique et de télécommunication transmettant des données ou supportant des
services d'information doit être protégé contre les dommages.
Le matériel doit être protégé contre les pannes de courant ou les autres anomalies
électriques.
Le matériel doit être entretenu conformément aux instructions du fabricant et/ou aux
procédures documentées afin d'assurer sa disponibilité et son intégrité continues.
6.2.1.4 Sécurité liée aux ressources humaines
Le personnel est tenu à respecter la politique de sécurité que le centre va la mettre en œuvre.
A cet effet, une mise à niveau des employés dans le domaine de la sécurité de l’information
doit être menée en planifiant des cycles de formation périodiques interne et externe du centre
et en organisant des programmes de sensibilisation qui devront expliquer les méthodes de
protection de l’information surtout celle qui sont critiques tel que les login et les mots de
passe.
Le personnel du centre doit être conscient de sa responsabilité envers le CIMSP en cas de
violation de la sécurité, il doit assimiler les conséquences de ses actions.
La comité de sécurité est tenu à noter et à reporter toute faille de sécurité observée ou
soupçonnée dans les systèmes ou les services ou toute menace à laquelle ces derniers
seraient exposés.
Les mesures disciplinaires pour violation de la politique de sécurité et des procédures de
sécurité doivent être communiquées à tous les employés.
Chapitre 6 Recommandations et Plan d’action
123
Une séparation des tâches est nécessaire dans le service réseau, chaque individu doit avoir
ses propres tâches à exécuter.
Le service réseau a besoin des nouvelles compétences ; une équipe pour la surveillance
réseau doit être envisagée, Une équipe pour la sécurité réseau doit être envisagée.
6.2.1.5 Sécurité physique et environnementale
La protection physique couvre la protection des ordinateurs, des immeubles, des
équipements, de toute sorte d’accident ou des intrusions. D’après notre audit organisationnel
et physique, nous avons déduit que le service ‘contrôle d’accès aux locaux sensibles’ est le
service qui a le plus grand besoin en matière de sécurité alors les actions suivantes doivent
être misent en œuvre :
Une politique d’accès aux immeubles doit être rédigée et confirmer par la direction générale
et elle doit être appliquée conformément aux règles de la politique de sécurité.
Le contrôle d’accès effectué par le responsable d’accueil, doit être documenté dans des
feuilles et exporter vers une base de données chaque jour pour conserver l’archive des visites.
Les employés ainsi que les visiteurs doivent porter une carte d’identité visible tel que les
badges durant leur existence au centre afin de pouvoir déterminer qui provient du centre ou
qui vient de l’extérieur.
La visite n’est réellement terminée que lorsqu’on s’est assuré que tous les visiteurs sont à
l’extérieur du centre.
Un tiers ayant apporté du matériel ou des supports doit sortir des locaux avec le même
matériel ou un récépissé signé par matériel en plus ou en moins.
Il est recommandé d’installer des caméras de surveillance dans les locaux sensible du centre
particulièrement la salle machine.
Mettre en place un poste de surveillance pour les détecteurs d'humidité à proximité de la
salle machine.
Installer des détecteurs de fumée dans les bureaux du centre.
Il est recommandé de préserver une salle équipé pour les stagiaires du centre pour ne pas
déranger les employés pendant leur période de stage.
La salle de formation nécessite des actions de maintenance urgente car elle présente un
danger pour les personnes qui y accède et pour les équipements informatique qu’elle contient.
Chapitre 6 Recommandations et Plan d’action
124
6.2.1.6 Gestion de l’exploitation et des télécommunications
La réalisation systématiquement d’une revue formelle des nouvelles fonctionnalités ou des
changements de fonctionnalités liées à un nouveau logiciel ou équipement ou à une nouvelle
version et des risques éventuels.
Définir une procédure pour les paramétrages de sécurité et les règles de configuration te que
la suppression de tout compte générique, le changement de tout mot de passe générique, la
fermeture de tout port non explicitement demandé et autorisé, les paramétrages du contrôle
des droits et de l'authentification, le contrôle des tables de routage,…etc.
Etablir un plan de sauvegarde couvrant l'ensemble des configurations du réseau étendu,
définissant les objets à sauvegarder et la fréquence des sauvegardes.
Mise en place un service de signature électronique.
Documenter les procédures d’exploitation, de sauvegarde et ils doivent être tenues à jour et
disponibles pour tous les utilisateurs concernés.
Mettre en place un processus de séparation des tâches pour réduire les occasions de
modification ou de mauvais usage non autorisé ou involontaire des biens du centre.
Sécuriser les échanges d’information et des logiciels.
Des mesures de maîtrise, de détection et de prévention doivent être mises en œuvre afin de
fournir une protection contre les logiciels malveillants.
La gestion des supports informatiques amovibles, tels que les bandes, les disques les
cassettes et les rapports imprimés doivent être maîtrisée.
Une politique doit être élaborée pour l’utilisation du courrier électronique et des
mesures de maîtrise doivent être mises en place afin de réduire les risques de sécurité
créés par le courrier électronique.
Des procédures et des mesures de maîtrise doivent être en place pour protéger
l’échange d’informations par des moyens de communication vocale, par télécopie et vidéo.
6.2.1.7 Contrôle d’accès
Mettre à la disposition des utilisateurs un guide de bonnes pratiques en gestion des mots de
passe.
L’attribution des mots de passe doit être maîtrisée par un processus de gestion
Officiel ; de cet effet, une déclaration de non divulgation de mot de passe doit être signée par
les utilisateurs.
Chapitre 6 Recommandations et Plan d’action
125
Les systèmes de gestion des mots de passe doivent fournir une fonction interactive efficace
qui assure la qualité des mots de passe ; pas de mots de passe trop courts ou trop simples, pas
de réutilisation de mots de passe précédents,...etc.
La politique de mot de passe doit imposer un changement périodique.
Informer les employés des pratiques de sécurité des équipements qui sont les serveurs et les
postes de travail laissés sans surveillance ; à titre d’exemple :
Fermer la salle machine si elle n’est pas occupée par personne.
Instaurer un délai de déconnexion automatique après une période d’inactivité
Instaurer une limite de temps pour la connexion
Désactiver les périphériques de démarrage autres que ceux autorisés
La politique d’accès au réseau doit être définie et documentée comme des procédures pour
protéger l’accès aux équipements actifs du réseau, les protocoles, les applications, les
systèmes, les services réseaux,…etc.
Mettre en place un système basé sur le protocole KERBEROS qui permet l’authentification
sécurisée des utilisateurs et le single sign on (SSO) qui consiste à utiliser un seul mot de passe
pour accéder à tous les services réseaux.
Une politique sur l'utilisation des commandes cryptographiques pour la protection des
informations doit être élaborée et suivie.
Des signatures numériques doivent être utilisées pour protéger l'authenticité et l'intégrité de
l'information électronique.
6.2.1.8 Acquisition, développement et maintenance des systèmes d’information
Les installations, les matériels et les logiciels du système d'information ainsi que ceux qui
assurent la protection du système d'information et la fourniture des services essentiels doivent
être maintenus et testés régulièrement.
Mettre en place des procédures pour contrôler l’installation du logiciel sur les systèmes en
exploitation.
Des vérifications de validation doivent être incorporées dans les systèmes afin de détecter
toute altération des données traitées.
Une maîtrise doit être appliquée sur l’implantation de logiciels sur les systèmes
opérationnels.
Chapitre 6 Recommandations et Plan d’action
126
L’achat, l’utilisation et la modification des logiciels doivent être maîtrisés et contrôlés afin
de les protéger contre la possibilité d’introduction de voies secrètes.
6.2.1.9 Gestion des incidents liés à la sécurité de l’information
Il est primordial de faire une classification des incidents de sécurité allant de plus critiques
aux plus simples. Un incident est considéré comme critique s’il empêche la poursuite d’une
ou de plusieurs activités extrêmement cruciales pour le fonctionnement du centre. Dans des
autres circonstances l’incident peut être classé comme simple s’il touche seulement un groupe
d’utilisateurs dont les activités ne sont pas critiques pour le bon fonctionnement de
l’organisme.
Des responsabilités et des procédures de gestion des incidents doivent être établies de façon
à assurer une réaction rapide, efficace et ordonnées aux incidents de sécurité.
Il faut mettre en place des mécanismes permettant de quantifier et surveiller les différents
types d’incidents liés à la sécurité de l’information ainsi que leurs coûts associés.
Constituer un archive sur disque ou sur cassette par exemple de tous les éléments ayant
permis de détecter une anomalie ou un incident.
6.2.1.10 Gestion du plan de continuité de l’activité
Un processus doit être mis en place pour assurer le développement et la maintenance
de la continuité de service. Pour se faire, le centre est appelé à réaliser un plan de continuité
ou un plan de secours informatique doit être mise en œuvre alors le processus doit commencer
par la rédaction d’un cahier des charges du plan de secours informatique. Les actions
suivantes doivent être réalisées :
Identifier les processus métiers critiques
Identifier les menaces qui pourraient causer des interruptions aux principaux
métiers
Evaluer l’impact ou les conséquences sur les processus métiers
Identifier les ressources et les dépendances
Evaluer les risques et la fréquence des pannes
Etablir les priorités à partir des risques et impacts recensés par l’analyse de
risque.
Chapitre 6 Recommandations et Plan d’action
127
6.2.1.11 Conformité
Afin d’éviter des infractions d’ordre légal, réglementaire ou contractuel, le centre doit
se plier aux lois et aux règlements internes. A cet effet, il doit s’assurer de la conformité de
l’utilisation des systèmes et des applications à la politique de sécurité qui va être établi. Pour
cela il faut mettre en place des procédures de déroulement des audits et de contrôle pour
surveiller les éventuelles violations de la. En ce qui concerne les logiciels, le centre doit aussi
acquérir des logiciels uniquement à partir de sources connues et réputées afin de s’assurer du
respect du droit de reproduction.
6.2.2 Recommandations techniques
Dans cette section, on va proposer des recommandations d’ordre techniques à mettre
en œuvre pour pallier aux insuffisances. La mise en place de ces recommandations peut être
faite progressivement selon le degré d’urgence et la disponibilité des ressources humaines et
budgétaires.
6.2.2.1 Exploitation du réseau
Le plan d’adressage doit être révisé afin d’organiser les postes dans des sous réseau séparés
selon l’organisation hiérarchique des services, pour la protection et l’isolement des systèmes
sensibles alors les sous-réseaux fonctionnels indépendants doivent être segmentés.
Il est recommandé de renforcer les mécanismes d’authentification/identification au réseau
local par une vérification de la correspondance entre l’adresse IP et l’adresse MAC.
Un serveur de domaine doit être mise en place pour gérer les utilisateurs du réseau interne
du CIMSP vue qu’il faut assurer la transparence entre les directions et les départements
opérationnelles, étant donnée que certaines informations sur des postes de travail sensibles
sont critiques et sont exposées aux risques des intrusions internes.
Choisir des plages d’adresse non limité pour pouvoir intégrer plusieurs machine afin
d’envisager l’extension du réseau du centre.
Mettre en place un réseau WIFI pour minimiser les couts et assurer la mobilité.
Minimisation des protocoles et services, seulement le minimum suffisant de protocoles et de
services réseau doit être permis sur chaque système (FTP et TELNET doivent être fermés).
Certains services en activité sur les stations (serveurs et routeurs) ne sont pas recensés, il est
recommandé de les désactivé très vite. Donc il faudra décider de leur utilité et de s’assurer
Chapitre 6 Recommandations et Plan d’action
128
périodiquement de l’absence de failles des versions des outils les exploitant, tel que à titre
d’exemple : http, https, SNMP, 135 (tcp and udp), 137 (udp), 138 (udp), 139 (tcp) et 445 (tcp
& udp).
Il est recommandé d’éviter les partages inutiles et d’appliquer les règles de contrôle d’accès
et de mettre en place une politique d’authentification afin de garantir la confidentialité,
l’intégrité et la disponibilité de données.
Mise en place d’une stratégie de sécurité sur les postes de travail minimisant les risques de
vandalisme et les erreurs de manipulation.
Un inventaire à jour des systèmes et de leur configuration doit être élaboré, mis à jour à
chaque modification des systèmes ou des configurations et diffusé aux acteurs ayant besoin
d'en connaître.
Des journaux d'audit où sont enregistrés les exceptions et les autres événements relatifs à la
sécurité doivent être produits et tenus pendant une période convenue de façon à faciliter les
enquêtes futures et le contrôle des mesures de maîtrise des accès.
Toute modification des configurations matérielles ou logicielles doit prendre en compte la
compatibilité avec le reste du système d'information et les anciennes sauvegardes ou archives
et prévoir une procédure de retour arrière en cas d'anomalie.
Les supports d’archivage doivent être conservés dans des coffres forts afin de les protégés.
Les accès aux systèmes doivent être journalisées avec si possible et au minimum l'identité
de l'utilisateur, le système concerné et la date et l'heure de l'accès.
De mettre en place une stratégie de sauvegarde et de restitution des données formellement
décrite et de vérifier le bon fonctionnement des supports de sauvegarde après chaque cycle de
ce dernier.
Mise en place d’une sonde IPS : Un outil de détection d’attaques doit être installé pour
détecter les attaques et les intrusions sur les différents points d’entrée du réseau.
6.2.2.2 Les recommandations du Pare-feu
Le pare-feu doit permettre un filtrage au niveau application pour bloquer tout détournement
par un administrateur ou un utilisateur non privilégié du système utilisant des commandes de
haute priorité.
Il est recommandé d’archiver les journaux de log du pare-feu, les contrôlés et les audités
régulièrement.
Les requêtes ICMP doivent être bloquées.
Chapitre 6 Recommandations et Plan d’action
129
Les mises à jour doivent se faire régulièrement et automatiquement à partir du site du
constructeur.
Toutes les modifications de configuration du pare-feu doivent être documentés et conservés
dans un endroit sécurisé afin d’assurer la continuité de travail.
Les règles de filtrage doivent être à jour et testés contre les attaques.
Un audit de pare-feu doit être effectué régulièrement.
6.2.2.3 Les recommandations des routeurs
Enregistrement des tentatives d’accès aux routeurs.
Il est recommandé d’archiver les journaux de log des routeurs, les contrôlés et les audités
régulièrement.
Toutes les modifications de configuration des routeurs doivent être documentés et conservés
dans un endroit sécurisé afin d’assurer la continuité de travail.
Les mises à jour doivent se faire régulièrement et automatiquement à partir du site du
constructeur.
6.2.2.4 Les recommandations du système de messagerie interne
Mise en place d’une politique de gestion des mots de passe.
Planification des cycles de formation pour la certification Lotus Notes au profil des
administrateurs.
6.2.2.5 Recommandation du système d’exploitation UNIX
Il est nécessaire de faire des sauvegardes système régulièrement.
Des tests périodiques de restauration de données doivent être établis à partir des
supports de sauvegarde.
Restriction d’accès au système à partir de la console seulement pour l’administrateur.
Utilisation de la même version pour faciliter la mise à jour et éviter l’incompatibilité des
données puisque il y a deux versions utilisées
6.3 Plan d’action
La mise en place d’un plan d’action permet à l’entreprise d’atteindre ses objectifs en
matière de sécurité. Le plan d’action est un regroupement des différentes opérations qu’il faut
Chapitre 6 Recommandations et Plan d’action
130
réaliser. Généralement un plan d’action s’étale sur 3 ans puisqu’on on ne peut pas tout mettre
en place simultanément. Pour cela on doit définir des priorités et pour pouvoir définir des
priorités on doit avoir un critère de choix. Les critères de choix qui seront utilisés sont les
suivants : Coût, l’importance et le degré de gravité des vulnérabilités découverte lors de
l’audit. Alors que, les priorités exploitées sont ventilées comme suit : court terme (C), moyen
terme (M), et long terme (L).
Domaine Code Recommandations Priorité
Stratégique 1.1 -Formaliser tous les processus métiers du CIMSP
dans des procédures surtout ceux du service réseau.
L
1.2 -Fixer les objectifs de sécurité et le paramétrage des
risques dans des grilles et des tables standards.
C
1.3 -Planifier des audites sécurité du système
d’information au moins une fois par an.
C
Organisationnel
2.1 -Rédiger un document de politique de sécurité qui
doit contenir les directives, les procédures, les
règles organisationnelles et techniques, ayant pour
objectif la protection du système d’information du
centre.
C
2.2 -Diffuser le document pour tout le personnel du
centre.
C
2.3 -Nomination d’un responsable de sécurité du
système d’information.
C
2.4 -Diffuser la charte de sécurité informatique pour
tout le personnel du centre.
C
Chapitre 6 Recommandations et Plan d’action
131
2.5 -Réaliser un inventaire complet de toutes les
ressources et procéder à une classification de ces
ressources sur les 3 critères suivants : disponibilité,
confidentialité et intégrité.
M
2.6 -Designer, dans un document formalisé, un
responsable pour chaque ressource.
M
Physique
3.1 -Renforcer le contrôle d’accès surtout à la salle
machine.
M
3.2 -Mettre en place un processus d’identification pour
les visiteurs ainsi que les employés basé sur les
badges.
C
3.3 -Automatiser l’archivage des visites dans une base
de données pour avoir une trace de tous les accès au
centre
M
3.4 -Installer des caméras de surveillance dans la salle
machine
M
3.5 -Préparer une salle équipée pour les stagiaires. M
3.6 -Réparer la salle de formation. C
Continuité 4.1 -Rédiger un plan de secours informatique. L
4.2 -Créer un registre et une base de données pour
consigner les anomalies et les incidents de sécurité.
C
Logique 5.1 -Créer des profils utilisateurs. C
5.2 -Elaboration des procédures pour le contrôle
d’accès.
C
5.3 -Définir un time out pour les sessions inactives. C
Chapitre 6 Recommandations et Plan d’action
132
Personnel
6.1 -Organiser des cycles de formation et de
sensibilisation en matière de sécurité pour tout le
personnel du centre.
M
6.2 -Informer le personnel, par un document signé de
leur part, des différents textes de lois qui définissent
leurs droits et devoirs envers le centre en matière de
sécurité.
M
6.3 -Planifier les formations nécessaires pour le RSSI. M
6.4 -Recruter les compétences nécessaires pour
maintenir le système d’information.
C
Applicative 7.1 -Définir une procédure pour l’analyse,
l’exploitation et l’archivage des logs.
C
7.2 -Acquérir une application d’analyse des logs. C
Exploitation 8.1 -Mise en place des mécanismes de cryptographie
pour la protection des données sensibles transmises
sur le réseau.
C
8.2 -Elaboration des procédures d’échange
d’information et de logiciel entre les employés.
M
8.3 -Mettre en place une politique de sauvegarde des
données sensibles sur les postes de travail
C
8.4 -Mettre en place une politique de restauration des
données.
C
8.5 -Protéger les bandes de sauvegarde dans un endroit
adéquat.
C
Tableau 6.1.Plan d'action.
Chapitre 6 Recommandations et Plan d’action
133
6.4 Conclusion
Ce chapitre est la clôture de cette mission d’audit. On a présenté les recommandations
organisationnelles et physiques selon les chapitres de la norme ISO 17799 ou 27002. Ensuite
les recommandations techniques. Après on a proposé un plan d’action qui regroupe les
recommandations qu’on trouve prioritaire, selon des critères de choix, pour les mettre en
œuvre.
Conclusion générale
134
Conclusion générale
Dans ce travail, on s’est intéressé de la sécurité du système d’information du centre
informatique de ministère de la santé publique à travers l’audit de sécurité qu’on a mené.
L’audit c’est étalé sur deux principales phases ; l’audit organisationnel physique et l’audit
technique et sur 6 chapitres. Avant d’entamer la première phase, on a présenté tout d’abord les
concepts de base de la sécurité qui sont le S ainsi les risques qui menacent ces systèmes,
l’audit informatique ; les méthodes et les normes les plus connus après on a réalisé une étude
comparative pour arriver au choix de notre méthode d’audit selon des critères bien définis. En
ce qui suit, on a étudié le contexte de notre mission d’audit, on a focalisé l’organisme
d’accueil et on a analysé l’existant en matière d’architecture réseau et les mesures de sécurité
mis en œuvre.
La première phase d’audit a consisté à analyser en premier lieu les enjeux du centre
pour arriver à identifié les risques en ce qui suit, ensuite on a montré les vulnérabilités du
système à partir des questionnaires et des entretiens effectués avec les personnes concernés.
Ces deux premières étapes nous ont mené à l’analyse des risques qu’on l’a réalisé à partir des
enjeux du centre et à partir de la base de connaissance de MEHARI pour arriver au résultat
que le centre a un énorme besoin dans la majorité des services de sécurité.
La deuxième phase d’audit a consisté à étudier les défaillances d’ordre technique.
Durant cette phase, on a utilisé plusieurs outils de sondage et de scan pour identifier les
vulnérabilités techniques qui touchent l’architecture du système à savoir les vulnérabilités au
niveau du plan d’adressage, au niveau du système, au niveau des partages de données et au
niveau de la politique de sauvegarde et de restauration. Après on a analysé les vulnérabilités
qui touchent aux services et aux flux réseaux et enfin les vulnérabilités au sein des
équipements sensibles comme les serveurs, le pare-feu, les routeurs et même les systèmes.
Les résultats finales de ces deux phases, nous ont guidé à formuler des
recommandations organisationnelles, physiques et techniques et à proposer un plan d’action
dans le but d’atténuer les vulnérabilités et les risques encourus.
En conséquence, ce travail présente de très nombreuses perspectives. En se limitant
aux perspectives immédiates, on propose que la direction générale planifie un audit de
sécurité en interne effectuer par un responsable de sécurité de système d’information. Comme
la sécurité au niveau du centre est fortement liée à celle de ces clients qui sont les
établissements hospitaliers, il est nécessaire de planifier des missions d’audit au sein de ces
Conclusion générale
135
établissements afin d’évaluer le niveau de sécurité du système d’information de tout le
système.
Pour les perspectives à long terme, on propose la mise en place d’un système de
management de sécurité de l’information (SMSI) qui est un ensemble d’éléments interactifs
permettant à un organisme d’établir ses objectifs de sécurité, sa politique de sécurité,
d’atteindre ses objectifs et d’appliquer sa politique dans le but d’obtenir la certification
ISO/IEC 27001 qui atteste que la sécurité des systèmes d’information a été sérieusement prise
en compte et que l'entreprise s'est engagée dans une démarche d'amélioration constante.
L’ISO 27001 permet de fournir un modèle pour mettre en place et gérer un SMSI vu que
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. De plus il est cohérent avec des autres systèmes
comme le système de management de qualité, de la sécurité des conditions de travail,…etc.
La mise en place d’un SMSI est un processus qui peut être parcouru tout au long d’une thèse
professionnelle.
Liste des acronymes
SI Système d’Information
DDOS Destributed Denial of Service
RSSI Responsable Sécurité des Système d’Information
PSSI Politique de Sécurité du Système d’Information
EBIOS Expression des Besoins et Identification des Objectifs de Sécurité
DCSSI Direction Centrale de la Sécurité des Systèmes d’Information
COBIT Control Objectives for Information and Related Technology
ISACA
Information Systems Audit and Control Association
ISO International Organization for Standardization
MARION Méthodologie d’analyse de Risques Informatiques Orienté par Niveaux
RM Risques Majeurs
RS Risques Simples
CRAMM CCTA Risk Analysis and Management Method
MEHARI MEthode Harmonisée d’Analyse de Risques
CLUSIF Club de la Sécurité des Systèmes d’Information Français
PSS Plan Stratégique de Sécurité
POS Plans Opérationnels de Sécurité
POE Plan Opérationnel d’Entreprise
TI Technologies de l’Information
BS British Standard
MSP Ministère de la Santé Publique
EPS Etablissement Public de Santé
RNS Réseau National de la Santé
DMZ Zone Démilitarisée
ACL Access Control List
DEDI Direction des Etudes et de Développement Informatiques
DERSS Direction de l’Exploitation, des Réseaux, de la Sécurité et de Soutien
DAAF Direction des Affaires Administratives et Financières
FSI Fournisseurs de Services Internet
ATI Agence Tunisienne de l’Internet
LS Lignes Spécialisées
CNI Centre National d’Informatique
TTN Tunisie Trade Net
137
BBN BackBone National
OSSIM Open Source Security Information Management.
HIDS Host Based Intrusion Detection System
OSSEC Office of State Security and Emergency Coordination
MRTG Multi Router Trafic Graphe
Syslog-ng Syslog next generation
I Impact
P Potentialité
G Gravité
SMTP Simple Mail Transfer Protocol
TELNET TErminaL NETwork
TCP Transmission Control Protocol
UDP User Datagram Protocol
CDP Cisco Discovery Protocol
IPX Internetwork Packet Exchange
STP Spanning Tree Protocol
SNMP Simple Network Management Protocol
SSL Secure Sockets Layer
HTTP Hypertext Transfer Protocol
LDAP Lightweight Directory Access Protocol
FTP File Transfer Protocol
DoS Denial-of-Service
SSH Secure Shell
ICMP Internet Control Message Protocol
ARP Address Resolution Protocol
SSO Single Sign On
HTTPs Hypertext Transfer Protocol Secure
SMSI Système de management de la sécurité de l'information
138
Références bibliographiques
[1]. Manager la sécurité de l’information, La revue n° 85 - Février 2007
[http://www.afai.asso.fr/public/doc/335.pdf] Nov. 2009.
[2]. Guide de la sécurité des systèmes d’information [http://www.sg.cnrs.fr/FSD/securite-
systemes/documentations_pdf/securite_systemes/guide.pdf]
[3]. Sécurité des systèmes d’information
[http://www.universalis.fr/encyclopedie/SC02007/SYSTEMES_D_INFO.pdf] Nov. 2009.
[4]. Sécurité des systèmes d’information
[http://www.universalis.fr/encyclopedie/SC02007/SYSTEMES_D_INFO.pdf] Nov. 2009.
[5]. Pourquoi des normes ISO de sécurité de l’information ? [http://www.ysosecure.com/norme-
securite/pourquoi-norme-securite.asp] Nov. 2009.
[6]. Pourquoi des normes ISO de sécurité de l’information ?
[http://www.ysosecure.com/norme-securite/pourquoi-norme-securite.asp] Nov. 2009.
[7]. Sécurité des informations, normes BS 7799, ISO 17799, ISO 27001, EBIOS, MEHARI
[http://www.guideinformatique.com/fichesecurite_des_informations_normes_bs_7799_iso_17
799_iso_27001-441.htm] Nov. 2009.
[8]. Sécurité des informations, normes BS 7799, ISO 17799, ISO 27001, EBIOS, MEHARI
[http://www.guideinformatique.com/fichesecurite_des_informations_normes_bs_7799_iso_17
799_iso_27001-441.htm] Nov. 2009.
[9]. Normes de sécurité : les méthodes d'analyse des risques
[http://cyberzoide.developpez.com/securite/methodes-analyse-risques/] Nov. 2009.
[10]. Normes de sécurité : les méthodes d'analyse des risques
[http://cyberzoide.developpez.com/securite/methodes-analyse-risques/] Nov. 2009.
[11]. Sécurité des informations, normes BS 7799, ISO 17799, ISO 27001, EBIOS, MEHARI
[http://www.guideinformatique.com/fichesecurite_des_informations_normes_bs_7799_iso_17
799_iso_27001-441.htm] Nov. 2009.
[12]. Rappel sur les normes et méthodes en matière de Sécurité des Systèmes d’Information, La
revue n° 85 - Février 2007 [http://www.afai.asso.fr/public/doc/337.pdf] Nov. 2009.
[13]. Rappel sur les normes et méthodes en matière de Sécurité des Systèmes d’Information, La
revue n° 85 - Février 2007 [http://www.afai.asso.fr/public/doc/337.pdf] Nov. 2009.
[14]. Rappel sur les normes et méthodes en matière de Sécurité des Systèmes d’Information, La
revue n° 85 - Février 2007 [http://www.afai.asso.fr/public/doc/337.pdf] Nov. 2009.
139
[15]. Rappel sur les normes et méthodes en matière de Sécurité des Systèmes d’Information, La
revue n° 85 - Février 2007 [http://www.afai.asso.fr/public/doc/337.pdf] Nov. 2009.
[16]. Guide du diagnostic de l’état des services de sécurité
[http://www.clusif.fr/fr/production/ouvrages/pdf/MEHARI-2007-Vulnerabilites.pdf] Jan. 2010.
[17]. Guide de l’analyse des enjeux et de la classification
[http://www.clusif.fr/fr/production/ouvrages/pdf/MEHARI-2007-V2-Enjeux.pdf] Jan. 2010.
[18]. Guide de l’analyse des risques [http://www.clusif.fr/fr/production/ouvrages/pdf/MEHARI-
2007-Anarisk.pdf] Fév. 2010.
Les Annexes
top related