Mehari Report Vue2704

140
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

Transcript of Mehari Report Vue2704

Page 1: Mehari Report Vue2704

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

Page 2: Mehari Report Vue2704

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.

Page 3: Mehari Report Vue2704

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

Page 4: Mehari Report Vue2704

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

Page 5: Mehari Report Vue2704

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

Page 6: Mehari Report Vue2704

6.4 Conclusion .................................................................................................................. 133

CONCLUSION GENERALE ............................................................................................. 134

LISTE DES ACRONYMES ............................................................................................... 136

REFERENCES BIBLIOGRAPHIQUES .......................................................................... 138

Page 7: Mehari Report Vue2704

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

Page 8: Mehari Report Vue2704

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

Page 9: Mehari Report Vue2704

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

Page 10: Mehari Report Vue2704

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.

Page 11: Mehari Report Vue2704

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

Page 12: Mehari Report Vue2704

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

Page 13: Mehari Report Vue2704

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.

Page 14: Mehari Report Vue2704

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

Page 15: Mehari Report Vue2704

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.

Page 16: Mehari Report Vue2704

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

Page 17: Mehari Report Vue2704

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.

Page 18: Mehari Report Vue2704

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

Page 19: Mehari Report Vue2704

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

Page 20: Mehari Report Vue2704

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

Page 21: Mehari Report Vue2704

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.

Page 22: Mehari Report Vue2704

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à

Page 23: Mehari Report Vue2704

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,

Page 24: Mehari Report Vue2704

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

Page 25: Mehari Report Vue2704

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

Page 26: Mehari Report Vue2704

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

Page 27: Mehari Report Vue2704

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.

Page 28: Mehari Report Vue2704

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

Page 29: Mehari Report Vue2704

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.

Page 30: Mehari Report Vue2704

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.

Page 31: Mehari Report Vue2704

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.

Page 32: Mehari Report Vue2704

32

Figure 2.1.Organigramme CIMSP.

Page 33: Mehari Report Vue2704

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.

Page 34: Mehari Report Vue2704

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

Page 35: Mehari Report Vue2704

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

Page 36: Mehari Report Vue2704

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.

Page 37: Mehari Report Vue2704

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

Page 38: Mehari Report Vue2704

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.

Page 39: Mehari Report Vue2704

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

Page 40: Mehari Report Vue2704

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

Page 41: Mehari Report Vue2704

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.

Page 42: Mehari Report Vue2704

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

Page 43: Mehari Report Vue2704

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

Page 44: Mehari Report Vue2704

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é

Page 45: Mehari Report Vue2704

Chapitre 3 Audit Organisationnel et Physique

45

Tableau 3.3.Moyennes des domaines de sécurité et des services.

Page 46: Mehari Report Vue2704

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 ∗ 𝑅𝑖 𝑃𝑖/ 𝑃𝑖

Page 47: Mehari Report Vue2704

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

Page 48: Mehari Report Vue2704

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é

Page 49: Mehari Report Vue2704

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)

Page 50: Mehari Report Vue2704

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

Page 51: Mehari Report Vue2704

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.

Page 52: Mehari Report Vue2704

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.

Page 53: Mehari Report Vue2704

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.

Page 54: Mehari Report Vue2704

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.

Page 55: Mehari Report Vue2704

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.

Page 56: Mehari Report Vue2704

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.

Page 57: Mehari Report Vue2704

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

Page 58: Mehari Report Vue2704

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.

Page 59: Mehari Report Vue2704

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.

Page 60: Mehari Report Vue2704

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.

Page 61: Mehari Report Vue2704

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 :

Page 62: Mehari Report Vue2704

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.

Page 63: Mehari Report Vue2704

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.

Page 64: Mehari Report Vue2704

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.

Page 65: Mehari Report Vue2704

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

Page 66: Mehari Report Vue2704

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.

Page 67: Mehari Report Vue2704

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.

Page 68: Mehari Report Vue2704

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

Page 69: Mehari Report Vue2704

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

Page 70: Mehari Report Vue2704

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

Page 71: Mehari Report Vue2704

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.

Page 72: Mehari Report Vue2704

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

Page 73: Mehari Report Vue2704

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

Page 74: Mehari Report Vue2704

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.

Page 75: Mehari Report Vue2704

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.

Page 76: Mehari Report Vue2704

76

Type

Service Officialisé Responsable description

Dis

ponib

ilit

é

Inté

gri

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

Page 77: Mehari Report Vue2704

77

Type

Service Officialisé Responsable description

Dis

ponib

ilit

é

Inté

gri

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

Page 78: Mehari Report Vue2704

78

Type

Service Officialisé Responsable description

Dis

ponib

ilit

é

Inté

gri

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

Page 79: Mehari Report Vue2704

79

Type

Service Officialisé Responsable description

Dis

ponib

ilit

é

Inté

gri

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

Page 80: Mehari Report Vue2704

80

Type

Service Officialisé Responsable description

Dis

po

nib

ilit

é

Inté

gri

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.

Page 81: Mehari Report Vue2704

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

Page 82: Mehari Report Vue2704

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 :

Page 83: Mehari Report Vue2704

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.

Page 84: Mehari Report Vue2704

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

Page 85: Mehari Report Vue2704

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.

Page 86: Mehari Report Vue2704

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.

Page 87: Mehari Report Vue2704

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é

Page 88: Mehari Report Vue2704

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 :

Page 89: Mehari Report Vue2704

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

Page 90: Mehari Report Vue2704

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

Page 91: Mehari Report Vue2704

91

Figure 4.6.Représentation graphique des besoins des services.

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

Besoin

Page 92: Mehari Report Vue2704

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.

Page 93: Mehari Report Vue2704

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.

Page 94: Mehari Report Vue2704

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.

Page 95: Mehari Report Vue2704

95

Figure 5.1.Architecture globale du CIMSP.

Page 96: Mehari Report Vue2704

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.

Page 97: Mehari Report Vue2704

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.

Page 98: Mehari Report Vue2704

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.

Page 99: Mehari Report Vue2704

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.

Page 100: Mehari Report Vue2704

Chapitre 5 Audit Technique

100

Page 101: Mehari Report Vue2704

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.

Page 102: Mehari Report Vue2704

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

Page 103: Mehari Report Vue2704

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.

Page 104: Mehari Report Vue2704

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.

Page 105: Mehari Report Vue2704

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.

Page 106: Mehari Report Vue2704

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

Page 107: Mehari Report Vue2704

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.

Page 108: Mehari Report Vue2704

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

Page 109: Mehari Report Vue2704

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.

Page 110: Mehari Report Vue2704

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

Page 111: Mehari Report Vue2704

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.

Page 112: Mehari Report Vue2704

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.

Page 113: Mehari Report Vue2704

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

Page 114: Mehari Report Vue2704

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

Page 115: Mehari Report Vue2704

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

Page 116: Mehari Report Vue2704

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

Page 117: Mehari Report Vue2704

Chapitre 5 Audit Technique

117

Page 118: Mehari Report Vue2704

Chapitre 5 Audit technique

118

Page 119: Mehari Report Vue2704

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.

Page 120: Mehari Report Vue2704

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

Page 121: Mehari Report Vue2704

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.

Page 122: Mehari Report Vue2704

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.

Page 123: Mehari Report Vue2704

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.

Page 124: Mehari Report Vue2704

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.

Page 125: Mehari Report Vue2704

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.

Page 126: Mehari Report Vue2704

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.

Page 127: Mehari Report Vue2704

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

Page 128: Mehari Report Vue2704

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.

Page 129: Mehari Report Vue2704

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

Page 130: Mehari Report Vue2704

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

Page 131: Mehari Report Vue2704

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

Page 132: Mehari Report Vue2704

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.

Page 133: Mehari Report Vue2704

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.

Page 134: Mehari Report Vue2704

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

Page 135: Mehari Report Vue2704

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.

Page 136: Mehari Report Vue2704

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

Page 137: Mehari Report Vue2704

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

Page 138: Mehari Report Vue2704

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.

Page 139: Mehari Report Vue2704

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.

Page 140: Mehari Report Vue2704

Les Annexes