Vous êtes sur la page 1sur 88

THÈME

ETUDE
Sous ETde :
la direction MISE EN PLACE
Présenté et D’UNE
soutenu par
M. APPLICATION
Haikreo ADJEOUA D’AUDIT AUTOMATIQUEM. AbdDE LA
Azis KABORE
SECURITE
Directeur général de DES SYSTEMES D’INFORMATION
4ITSEC-AFRICA

Octobre 2020

Promotion 2018 - 2020


Étude et mise en place d’une application d’audit automatique de sécurité des SI

AVANT-PROPOS

A la fin de chaque cycle d’enseignement théorique, il est recommandé que l’étudiant effectue
un stage pratique dans une entreprise publique ou privée de son choix en vue d’associer la théorie à
la pratique professionnelle. Les sociétés de télécommunications et d’informatique étant les lieux par
excellence où nous pouvons mieux appendre grâce à leurs maitrises des différents services de
l’informatique, nous avons décidé de porter notre choix sur elles pour notre stage pratique. C’est
ainsi que 4ITSEC-AFRICA a eu cette volonté de nous accepter en son sein durant ces périodes pour
notre formation afin que nous devenions capables d’assumer avec compétence nos futures
responsabilités. Avant tout développement sur cette expérience professionnelle, il apparaît opportun
de commencer ce mémoire par des remerciements à tous ceux qui ont eu la gentillesse de faire de ce
temps un moment très profitable pour nous.

I
Étude et mise en place d’une application d’audit automatique de sécurité des SI

DEDICACES

Je dédie ce mémoire :

A feu mon cher père et à ma chère mère pour toutes leurs bénédictions ;

A mes précieux frère et sœur pour leur soutien ;

Et à tous ceux qui me sont chers.

II
Étude et mise en place d’une application d’audit automatique de sécurité des SI

REMERCIEMENTS

A la fin de mes études et de mon stage, je tiens à remercier dans un premier


temps toute l’équipe pédagogique de l’École Supérieure Multinationale des
Télécommunications (ESMT) et tous les intervenants professionnels responsables
de ma formation d’ingénieur en sécurité des systèmes d’information, pour avoir
assuré la partie théorique et pratique de celle-ci.
Je remercie également :
M. Adamou MOUSSA SALEY, Directeur général de l’ESMT,
M. Jean Marie PREIRA, Responsable pédagogique, pour l’esprit
d’organisation et de rigueur qu’il nous a communiqué tout au long de notre
formation,
M. Oumar BA SAMBA, Responsable du département technique, pour tout son
accompagnement,
M. Herve OUEDRAOGO, pour son soutien,
Monsieur le président du jury et à tous les membres du jury pout le temps
qu’ils ont passé à évaluer mon travail, c’est un grand honneur pour moi,
Mes camarades de la Promotion MPSI 2018-2020, pour les moments agréables
passés ensemble.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance


aux personnes suivantes pour l’expérience enrichissante et pleine d’intérêts
qu’elles m’ont fait vivre durant ces moments de travail :
Dr Aikreo ADJEOUA, Directeur général de 4ITSEC-AFRICA,
Dr Youssef KHLIL, Fondateur de KHLIL IT,
Simplice Arnaud LEGMA, Co-fondateur de Reference NTIC.

A tous ceux, qui, de près ou de loin ont apporté leur contribution pour la réussite
de ce mémoire.

III
Étude et mise en place d’une application d’audit automatique de sécurité des SI

GLOSSAIRE

Abréviation Significations
ACL Acces Control List
s
CERT Computer Emergency Response Team
CISA Certified Information System Auditor
CMMI Capability Maturity Model Integration
COBIT Control Objectives for Information and related Technology
CRUD Create, Read, Update, Delete
CSIRT Computer Security Incident Response Team
DIC Disponibilité, Intégrité, Confidentialité
DNS Domain Name System
DSI Directeur des Systèmes d’Information
EBIOS Expression des Besoins et Identification des Objectifs de Sécurité
ESMT École Supérieure Multinationale des Télécommunications
ITIL Information Technology Infrastructure Library
ISACA Information Systems Audit and Control Association
ISO International Organization for Standardization
MEHARI Méthode Harmonisée d'Analyse des Risques
PC Personnal Computer
RSSI Responsable de la Sécurité des Systèmes d’Information
SI Système d’Information
SMSI Système de Management de la Sécurité des Systèmes
TIC Technologie
d’Informationde l’Information et de la Communication

IV
Étude et mise en place d’une application d’audit automatique de sécurité des SI

LISTE DES FIGURES

FIGURE 1: CYCLE DE VIE D’UN AUDIT.........................................................................................9


FIGURE 2: DÉMARCHE EBIOS..................................................................................................21
FIGURE 3: PHASE MEHARI......................................................................................................24
FIGURE 4: GESTION DIRECTE DES RISQUES...............................................................................28
FIGURE 5PHASE D’AUDIT..........................................................................................................31
FIGURE 6: LIENS ENTRE ISO 27001, ISO 27005 ET ISO 31000..............................................39
FIGURE 7: PROCESSUS DE GESTION DE RISQUE SELON ISO 31000...........................................39
FIGURE 8: GESTION DE RISQUES SELON ISO 27005..................................................................40
FIGURE 9: AUTRES RÉFÉRENTIELS............................................................................................40
FIGURE 10: PROCESSUS DE GESTION DE RISQUE SELON ISO 27005.........................................45
FIGURE 11: APPROCHE D’APPRÉCIATION ET DE TRAITEMENT DES RISQUES.............................46
FIGURE 12: ÉTABLISSEMENT DU CONTEXTE.............................................................................47
FIGURE 13: EXEMPLES VULNÉRABILITÉS/MENACES..................................................................50
FIGURE 14: EXEMPLE D’ESTIMATION DE LA PROBABILITÉ D’OCCURRENCE.............................51
FIGURE 15: EXEMPLE DE MATRICE D’ESTIMATION DU RISQUE.................................................51
FIGURE 16: EXEMPLE D’ESTIMATION DE L’IMPACT (COTATION)..............................................52
FIGURE 17: EXEMPLE D’ESTIMATION DU RISQUE......................................................................52
FIGURE 18: TRAITEMENT DU RISQUE........................................................................................53
FIGURE 19: OPTIONS DE TRAITEMENT DE RISQUE.....................................................................54
FIGURE 20: PLAN DE TRAITEMENT............................................................................................54
FIGURE 21: RISQUES RÉSIDUELS...............................................................................................55
FIGURE 22: ACCEPTATION DU RISQUE......................................................................................55
FIGURE 23: DIAGRAMME DE CLASSE.........................................................................................64
FIGURE 24: DIAGRAMME DE CAS D’UTILISATION.....................................................................66
FIGURE 25: AUTHENTIFICATION................................................................................................68
FIGURE 26: PANEL ADMINISTRATEUR.......................................................................................69
FIGURE 27: AJOUT CLIENT........................................................................................................69
FIGURE 28: LISTE CLIENT..........................................................................................................70
FIGURE 29: AJOUT DE DOMAINE D’ACTIVITÉ............................................................................70
FIGURE 30: LISTE DES DOMAINES D’ACTIVITÉ..........................................................................71
FIGURE 31: INTERFACE AJOUT D’OPÉRATION...........................................................................71
FIGURE 32: LISTE DES OPÉRATIONS..........................................................................................72
FIGURE 33: AJOUT DE QUESTION..............................................................................................72
FIGURE 34: INTERFACE DE CONNEXION ET SECTEUR D’ACTIVITÉ.............................................73
FIGURE 35: INTERFACE RÉPONSES AUX QUESTIONS..................................................................74

V
Étude et mise en place d’une application d’audit automatique de sécurité des SI

SOMMAIRE

INTRODUCTION............................................................................................................................................1
CHAPITRE 1 : CONTEXTE GENERAL..............................................................................2
1.1 PRÉSENTATION DE 4ITSEC-AFRICA.................................................................................................................3
1.2 PRÉSENTATION DU SUJET................................................................................................................................3
CHAPITRE 2 : ETAT DE L’ART..........................................................................................7
2.1 AUDIT DES SYSTÈMES D’INFORMATION..........................................................................................................8
2.2 TYPES D’AUDIT DES SYSTÈMES D’INFORMATION............................................................................................9
2.3 MÉTHODES ET NORMES D’AUDIT DE SÉCURITÉ DES SI.................................................................................11
2.4 MÉTHODES D’AUDIT DE SÉCURITÉ DES SI....................................................................................................19
2.5 DÉMARCHE STANDARD D'AUDIT...................................................................................................................29
2.6 DÉMARCHE DE RÉALISATION D’UN AUDIT DE SÉCURITÉ..............................................................................30
2.7 MOYENS DE COLLECTE.................................................................................................................................34
2.8 MÉTHODOLOGIE D’AUDIT.............................................................................................................................35
2.9 UTILITÉ DES OUTILS D’AUTOMATISATION DES QUESTIONNAIRES D’AUDIT..................................................36
CHAPITRE 3 : GESTION DES RISQUES..........................................................................37
3.1 FONDAMENTAUX ET RÉFÉRENTIELS DE GESTION DES RISQUES....................................................................38
3.2 LES ORIGINES DES RISQUES..........................................................................................................................41
3.3 DÉMARCHE DE GESTION DES RISQUES SELON ISO 27005............................................................................44
3.4 GESTION DES INCIDENTS DE SÉCURITÉ.........................................................................................................56
3.5 MÉTHODOLOGIE DE GESTION DES RISQUES POUR LES DSI...........................................................................58
CHAPITRE 4 : ETUDE, CONCEPTION ET REALISATION DE L’APPLICATION. 61
4.1 ÉTUDE ET SPÉCIFICATION DES BESOINS DU SYSTÈME...................................................................................62
4.2 CONCEPTION.................................................................................................................................................63
4.3 RÉALISATION DE L’APPLICATION..................................................................................................................67
4.4 BENCHMARKING...........................................................................................................................................74
CONCLUSION................................................................................................................................................76
BIBLIOGRAPHIE...................................................................................................................A
WEBOGRAPHIE.....................................................................................................................A
TABLE DES MATIERES.......................................................................................................B

VI
Étude et mise en place d’une application d’audit automatique de sécurité des SI

INTRODUCTION

Dans le nouveau contexte économique, le besoin d’informations sécurisées est de plus en plus
crucial pour les entreprises. Certaines entreprises et institutions, en quête de développement
de leurs activités, cherchent continuellement des informations qui leur permettent de mieux
cerner les variables de leur environnement et de les maîtriser. Ce phénomène a toujours existé
et ne fait qu’évoluer et se moderniser au fil du temps.

Actuellement, si les technologies de l’information et de la communication permettent aux


responsables et dirigeants, d’améliorer et de sécuriser leurs données, ces mêmes technologies
permettent malheureusement à d’autres individus assez doués (comme les HACKERS) d’en
prendre part et de les utiliser illégalement.

Face à cette situation et pour protéger ces précieuses données, des barrières sont mises en
place pour filtrer et bloquer les accès illicites. Toutefois, on se rend compte rapidement que
les méthodes et la nature des attaques des Hackers changent et évoluent sans cesse, obligeant
les institutions à sécuriser leurs systèmes d’information (SI) mis en place.

Le meilleur moyen de suivre la sécurité d’un SI est d’effectuer un audit de sécurité des SI de
façon périodique. L'audit, exercé par un auditeur, est un processus systématique, indépendant
et documenté permettant de recueillir des informations objectives pour déterminer dans quelle
mesure les éléments du système cible satisfont aux exigences des référentiels du domaine
concerné. C’est dans ce contexte que s’inscrit ce projet qui vise à mettre en place un outil
pour automatiser l’audit organisationnel, physique et technique pour les entreprises.

Pour se faire, nous présenterons notre organisme cible, ensuite un état de l’art sur l’audit de
façon générale. Par la suite, nous entamerons notre mission par l’étude de la gestion des
risques et terminerons par l’étude, la conception et la réalisation de l’application.

1
Étude et mise en place d’une application d’audit automatique de sécurité des SI

CHAPITRE 1 : CONTEXTE GENERAL

2
Étude et mise en place d’une application d’audit automatique de sécurité des SI

1.1 Présentation de 4itsec-africa


1.1.1 Historique
Le développement de l’internet a fait émerger une nouvelle forme d’économie : économie
numérique. En effet, tout comme dans la vie réelle, l’économie numérique est gravement
menacée par des personnes malveillantes. Ainsi, il urge pour les gouvernements, les
entreprises ou simplement toute personne de connaitre les enjeux de la sécurité des systèmes
d’information. Faisant suite à ces réflexions, FOR IT SECURITY AFRICA (4itsec-africa) a
été fondé en 2016 dont la vocation est de vulgariser l’acquisition des compétences (en sécurité
de l’information) aux étudiants et de renforcer la capacité des professionnels et enfin
d’accompagner les entreprises au travers des conseils, audit de sécurité des systèmes
d’information et diverses prestations dans le domaine de l’informatique.

1.1.2 Objectifs
4itsec-africa a pour objectifs de :
 Donnez des compétences aux étudiants et renforcer la capacité des professionnels,
 Porter assistances aux entreprises confrontées à des soucis de sécurité,
 Aider les entreprises partenaires à prévenir et réduire considérablement les risques de
sécurité du système d’information,
 Mener des projets d’audit de certification.

1.2 Présentation du sujet


1.2.1 Problématique
L'évolution de la technologie prouve que l'informatique nous est d'une grande importance
dans tous les domaines de la vie. Il est rare aujourd'hui de trouver un organisme qui ne
dispose pas d’infrastructure informatique.
Afin de sécuriser son infrastructure informatique, tout dirigeant d’entreprise doit connaître
précisément son fonctionnement. Grâce à un audit de sécurité informatique, il disposera d’une
analyse de l’existant et de recommandations pour pallier aux potentielles failles. Ainsi on
comprend vite que l’audit de sécurité est quasi obligatoire pour toute entreprise.
Selon la nature de ses activités, la société peut être légalement obligée de réaliser
périodiquement de type d’audit.
Mais certaines entreprises pour plusieurs raisons ne peuvent se permettre la réalisation d’une
telle mission d’audit de sécurité de son système d’information.

3
Étude et mise en place d’une application d’audit automatique de sécurité des SI

En effet, avec les couts très élevés des missions d’audit de sécurité, certaines entreprises
comme les Petites et Moyennes Entreprises (PME), Petites et Moyennes Industries (PMI) et
autres, sont de fois confrontées à des problèmes financiers pour se payer les services d’un
cabinet d’audit ou d’un auditeur expérimenté en sécurité des systèmes d’information.
Aussi, ces entreprises malheureusement manquent au sein de leur effectif de personnel
suffisamment formé pouvant se charger de l’audit de la sécurité de leur système
d’information.
En plus, certaines entreprises n’ont pas à leurs effectifs des informaticiens sur place pour la
gestion de la sécurité de leur système d’information.
Ce qui nous amène à poser un certain nombre de questions face à une telle situation.
Comment rendre l’activité d’audit de sécurité accessible à tout type d’entreprise ?
Comment automatiser à travers une application la tâche d’audit de sécurité ?
Quelle méthode d’audit adopter à cet effet ?
Quelles sont les technologies nécessaires pour la mise en place d’une telle application ?

1.2.2 Objectif général


Pour résoudre les problèmes auxquels sont confrontées les petites et moyennes entreprises de
nos jours pour se payer les services d’un auditeur expérimenté en audit de sécurité, notre
travail de recherche consistera à mettre en place une application desktop utilisable par tout
type d’entreprise pour réaliser de façon automatique la tâche d’audit de sécurité.

1.2.3 Objectifs spécifiques


Pour aboutir à l’objectif général, les objectifs spécifiques suivants, formulés par rapport aux
problèmes spécifiques, doivent être atteints :
- Une application simple d’utilisation avec un design attirant,
- Une application respectant la norme d’audit et suivant une méthode d’audit,
- L’utilisateur doit pouvoir connaitre le niveau de maturité de son système à travers
l’application,
- L’application doit permettre à l’utilisateur de générer un rapport d’audit à la fin de
l’audit.
- Le rapport doit contenir les performants, les perfectibles et des recommandations pour
améliorer le niveau du système.
Les objectifs ainsi déterminés, nous identifierons les hypothèses devant servir de base à notre
étude.

4
Étude et mise en place d’une application d’audit automatique de sécurité des SI

1.2.4 Hypothèses
L'hypothèse est définie comme étant une réponse provisoire aux questions posées dans la
problématique.
Pour répondre aux questions posées, nous émettons plusieurs hypothèses sur lesquelles nous
nous appuierons pour la suite de notre travail.
1re hypothèse : nous proposons le développement d’une application mobile ou desktop
classique d’audit de sécurité qui va proposer un audit physique, organisationnel et technique
de façon générale.
2e hypothèse : nous proposons une simplification des méthodes d’audit accessible et
utilisable par tout type d’entreprise
3e hypothèse : nous proposons la mise en place d’un outil d’auto diagnostic de la sécurité
informatique utilisant l’apprentissage automatique (Machine Learning), et se basant sur la
norme ISO 27005 (gestion des risques) et 31000 (audit), et intégrant les méthodes d’audit
comme EBIOS et MEHARI.

1.2.5 Importance de notre solution


Pour ce faire, des normes-protocoles sont établis dans le cadre de la politique de sécurité
informatique des entreprises, par exemple, antivirus, limitation de l’utilisation et de l’accès au
réseau et à Internet, autorisation et restriction des actions et des fonctions du logiciel et des
utilisateurs, création de profils utilisateurs, établissement de programmes d’activité et
protection des réseaux sans fil, entre autres. Le but de la sécurité informatique est de garantir
la sécurité des accès et des utilisations des informations enregistrées dans les équipements
informatiques, ainsi que du système lui-même, en se protégeant contre d’éventuelles attaques,
en identifiant les vulnérabilités et en appliquant des systèmes de cryptage aux
communications effectuées vers l’extérieur et l’intérieur de l’organisation.

Dans un monde de plus en plus contrôlé par les systèmes informatiques, la cybersécurité a
pris une importance particulière, car les cybermenaces affectent non seulement les
technologies de l’information et de la communication (TIC) et les systèmes d’information des
organisations, mais elles peuvent aussi causer des dommages au monde physique en affectant
les systèmes informatiques qui le contrôlent.
Afin de protéger leurs données, le matériel et les personnes, la plupart des entreprises de
grande taille ou même de dimensions plus modestes, doivent s'assurer de leur sécurité et d'une
protection efficace face aux intrusions physiques ou virtuelles (menaces d'intrusion d'un
réseau de données par Internet…). De même, les risques d'espionnage pouvant mettre
l'entreprise en danger sur le plan commercial et concurrentiel doivent également être
considérés.
Afin de faire face aux problèmes potentiels de sécurité, la plupart des sociétés se dotent d'une
politique de sécurité performante. Qu'elle soit discrète ou plus ostentatoire, la sécurité d'une

5
Étude et mise en place d’une application d’audit automatique de sécurité des SI

entreprise et sa mise en pratique cohérente contre des risques potentiels se doit d'être
contrôlée périodiquement pour s'assurer des performances des systèmes, protocoles et
pratiques de sécurité. C'est à ce moment qu'interviendra l'audit de sécurité.
D'un point de vue global, l'audit de sécurité concerne l'état des lieux d'une entreprise, ses
moyens humains et techniques, son fonctionnement, la conformité de ses installations et son
organisation interne en termes de sécurité et de respect des normes ou règlements. Les
menaces directes et indirectes sont évidemment prises en compte ainsi que l'identification des
points faibles, des valeurs critiques de sécurité et autres dangers potentiels. L'audit de sécurité
consistera dès lors à établir un bilan, une synthèse et des recommandations d'ordre technique
ou de fonctionnement (interne et externe) pour améliorer la sécurité des entreprises.
Dans ce cadre s’installe notre projet, qui consiste à l’automatisation de l’audit organisationnel,
physique et technique permettant ainsi un processus d’audit plus performant. En effet, ce
mémoire s’affiche comme étant un aperçu de notre travail, il est structuré sous la forme de
trois chapitres.
Le premier chapitre est dédié à l’étude du contexte contenant la présentation de la structure
d’accueil et du sujet,
Le deuxième chapitre est dédié à l'état de l'art de l'existant contenant les généralités sur l’audit
informatique, ses méthodes, méthodologies et types,
Le troisième chapitre est consacré au cadre méthodologique de gestion de risque,
Le quatrième et dernier chapitre est dédié à l’étude, la conception et la réalisation de
l’application d’automatisation de l’audit de sécurité.

6
Étude et mise en place d’une application d’audit automatique de sécurité des SI

CHAPITRE 2 : ETAT DE L’ART

7
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.1 Audit des systèmes d’information


2.1.1 Définition d’audit
L’audit informatique (aussi appelé « audit des systèmes d’information ou Information
Technology audit en anglais) consiste en une intervention réalisée par une personne
indépendante interne ou extérieure au service audité, qui permet d’analyser tout ou une partie
d’une organisation informatique, d’établir un constat des points forts et des points faibles et
dégager ainsi les recommandations d’amélioration.
Autrement dit, l'audit informatique peut aussi être défini comme l'évaluation des risques des
activités informatiques, dans le but d'apporter une diminution de ceux-ci et d'améliorer la
maîtrise des systèmes d'information.
L’audit de la sécurité d’un système d’information est indispensable pour toute organisation
qui décide de changements au sein de son système d’information ou de s’assurer de son
fonctionnement optimal.
Comme toute démarche qualité, il nécessite une méthodologie rigoureuse et une
communication idéale au sein de l’équipe.

2.1.2 Rôle et objectifs de l’audit


L'objectif apparent d’un audit est d'améliorer la maîtrise des systèmes d'information d'une
entité. L'objectif réel est d'assurer le niveau de service adéquat aux activités d'une
organisation.
L’audit informatique est une mission, qui ne demande pas de simples auditeurs, puisque ces
derniers doivent avoir de fortes connaissances en informatique, car des notions, ainsi que des
techniques sont à cerner pour comprendre et savoir gérer un processus d’informatisation.
L’audit de sécurité est une mission d’évaluation de conformité par rapport à une politique de
sécurité ou à défaut par rapport à un ensemble de règles de sécurité.
L’objectif principal d’une mission d’audit de sécurité est de répondre aux 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,


 Proposant des actions d’améliorations de niveau de sécurité de l’infrastructure
informatique.
Cependant, l’audit de sécurité peut présenter un aspect préventif. C'est-à-dire qu’il est effectué
de façons périodiques afin que l’organisme puisse prévenir les failles de sécurité. Également,
l’audit peut s’imposer suite à des incidents de sécurité.

8
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.1.3 Cycle de vie d’un audit de la sécurité de l’information


Le processus d’audit de sécurité est un processus répétitif et perpétuel. Il décrit un cycle de
vie qui est schématisé à l’aide de la figure suivante :

Figure 1: Cycle de vie d’un audit

L’audit de sécurité se présente essentiellement suivant deux principales parties comme le


présente le précédent schéma :
 L’audit organisationnel et physique.
 L’audit technique.
La troisième partie concernant l’audit intrusif est optionnelle et peut être également
considérée. Enfin un rapport d’audit est établi à l’issue de ces étapes. Ce rapport présente une
synthèse de l’audit. Il présente également les recommandations à mettre en place pour
corriger les défaillances organisationnelles et techniques constatées.

2.2 Types d’audit des systèmes d’information


2.2.1 Audit organisationnel et physique
Cet audit s’intéresse à l’aspect physique et organisationnel de l’organisme cible à auditer.
Il s’intéresse aux aspects de gestion et d’organisation de la sécurité, sur les plans
organisationnels, humains et physiques.
L’objectif de cet audit est de mesurer la maturité de l’organisation de la sécurité des systèmes
d’information sur la base de référentiels techniques et réglementaires à l’état de l’art et en
accord avec les réglementations et méthodes applicables dans le domaine d’activité du client
(santé, industrie, banque, hébergement, etc.). Cet audit permet avec un regard extérieur
d’identifier les écarts présentant les vulnérabilités majeures du système audité.

9
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Les objectifs visés par cette étape sont donc :


 D’avoir une vue globale de l´état de sécurité du système d´information,
 D´identifier les risques potentiels sur le plan organisationnel.
A l’inverse des audits plus techniques, la réalisation d’un audit organisationnel permet de
prendre un peu de hauteur sur la gestion de la sécurité et de parcourir l’ensemble des mesures
de sécurité en place que ce soit d’un point de vue organisationnel ou techniques. Ce type
d’audit s’adresse aux organismes souhaitant disposer d’une vision globale de leur sécurité sur
l’ensemble ou partie de leur système d’information. La réalisation d’un audit organisationnel
est conseillée dans une démarche d’amélioration de la sécurité. Il permet d’évaluer son niveau
de maturité, d’identifier ses points forts et les axes de progrès prioritaires pour passer à un
niveau supérieur.
L'auditeur utilise plusieurs outils pour effectuer sa mission : organigrammes, cartographies,
grilles d'audit… L'auditeur prend également connaissance de l'environnement extérieur
(concurrence, prestataires externes…).
L'audit organisationnel comprend plusieurs étapes dont les suivantes : définir la mission,
collecter les informations, les analyser et les synthétiser. L'auditeur commence en tenant
compte de la stratégie économiques et des objectifs de l'entreprise.
Après la collecte des informations au niveau interne (organisation des services) et externe, il
examine et diagnostique les points forts et les points faibles de l'entreprise. Il définit ainsi les
modifications nécessaires pour améliorer l'organisation des ressources humaines au sein de
l'entreprise.
C'est pourquoi l'audit peut déboucher sur des mutations, des changements de missions, des
recrutements ou des licenciements.

2.2.2 Audit technique


Les audits techniques permettent d’évaluer le niveau de sécurité par analyse interne des
systèmes en place. On se place dans du court terme, pour mettre à niveau la sécurité dans
l'urgence.
Ils permettent d’étudier les éléments techniques en production dans l’entreprise et d’en valider
le niveau de sécurité. Il s'agit d'une prestation hautement technique, dont la plupart des PME
peuvent très bien se passer. Ce type d’audit est donc destiné aux grandes entreprises.

2.2.3 Relation entre l’audit et l’analyse du risque


2.2.3.1 Le rôle de l’audit interne dans la gestion des risques
L’audit interne est une activité indépendante qui apporte des conseils et une assurance
objective. Concernant le management des risques, son principal rôle consiste à donner au
Conseil l’assurance objective que la gestion des risques est efficace. Des travaux de recherche
ont montré que les membres du conseil et les auditeurs internes s’accordent à dire que les

10
Étude et mise en place d’une application d’audit automatique de sécurité des SI

deux activités d’audit interne les plus porteuses de valeur ajoutée pour les organisations sont
les suivantes : apporter l’assurance objective que les principaux risques sont bien gérés et
apporter l’assurance que le cadre de la gestion des risques et du contrôle interne fonctionne
correctement.
Les principales questions à se poser pour la définition du rôle de l’audit interne sont :
l’activité constitue-t-elle une menace pour l’indépendance et l’objectivité des auditeurs
internes, et peut-elle améliorer la gestion des risques, les contrôles et la gouvernance de
l’organisation ?

2.2.3.2 Principaux rôles de l’audit interne


 Donner une assurance sur les processus de gestion des risques,
 Donner l’assurance que les risques sont bien évalués,
 Évaluer les processus de gestion des risques,
 Évaluer la communication des risques majeurs,
 Examiner la gestion des principaux risques.

2.2.3.3 Rôles légitimes de l’audit interne


 Faciliter l’identification et l’évaluation des risques,
 Accompagner la direction dans sa réaction face aux risques,
 Coordonner les activités de management des risques,
 Consolider le reporting des risques,
 Actualiser et développer le cadre de gestion des risques,
 Promouvoir de la mise en œuvre du management des risques,
 Élaborer une stratégie de gestion des risques à valider par le Conseil.

2.3 Méthodes et normes d’audit de sécurité des SI


2.3.1 Définition des terminologies
Au vu de la confusion que portent souvent les concepts de méthode de sécurité et de norme de
sécurité, nous allons donner une définition à chacun de ces concepts.

2.3.1.1 ISO
International Organization for Standardization en anglais ou Organisation internationale de
normalisation en français, est un organisme de normalisation international composé de
représentants d'organisations nationales de normalisation de 164 pays.

11
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Cette organisation créée en 1947 a pour but de produire des normes internationales dans les
domaines industriels et commerciaux appelées normes ISO. Elles sont utiles aux organisations
industrielles et économiques de tout type, aux gouvernements, aux instances de
réglementation, aux dirigeants de l’économie, aux professionnels de l’évaluation de la
conformité, aux fournisseurs et acheteurs de produits et de services, dans les secteurs tant
public que privé et, en fin de compte, elles servent les intérêts du public en général lorsque
celui-ci agit en qualité de consommateur et utilisateur.
Le secrétariat central de l'ISO est situé à Genève, en Suisse. Il assure aux membres de l'ISO le
soutien administratif et technique, coordonne le programme décentralisé d'élaboration des
normes et procède à leur publication.

2.3.1.2 Méthode
Dans le domaine scientifique, une méthode est un ensemble ordonné de manière logique de
principes, de règles, d'étapes, qui constitue un moyen pour parvenir à un résultat.
En informatique, une méthode est une démarche, un processus ou un ensemble de principes
qui permettent d’appliquer une norme au système d’information de l’entreprise. La méthode
sert aussi à faire un audit qui permet de faire, par exemple, un état de la sécurité du système
d’information. Une méthode est souvent accompagnée d’outils afin d’appuyer son utilisation.
Ils peuvent être disponibles gratuitement auprès des organismes qui les ont produits. Par
exemple la méthode MEHARI propose un outil très important (fichier Microsoft Excel). Le
fichier contient un ensemble de questions et de scénarios. Cette base de connaissance permet
de ressortir toutes les vulnérabilités du système d’information et émet des recommandations
pour y remédier. La plupart des méthodes sont appliquées par des experts en gestion des
risques (EBIOS, MEHARI, OCTAVE…).

2.3.1.3 Norme
Selon le guide ISO/CEI, une norme est « un document de référence approuvé par un
organisme reconnu, et qui fournit pour des usages communs et répétés, des règles, des lignes
directrices ou des caractéristiques, pour des activités, ou leurs résultats, garantissant un niveau
d’ordre optimal dans un contexte donné ».
Les entreprises se font certifier pour prouver qu’elles suivent les recommandations de la
norme. Pour être certifié, il faut, dans un premier temps acheter la norme. Les normes
appliquées à la sécurité des systèmes d’information sont généralement éditées par l’organisme
ISO. Ensuite l’entreprise doit mettre en pratique les recommandations décrites dans la norme.
Généralement, une entreprise peut se faire certifier pour trois raisons :
o Pour une raison commerciale.
Pour certaines entreprises, être certifiées par des normes de qualité par exemple est un gage de
qualité pour les clients et est donc un atout commercial.

12
Étude et mise en place d’une application d’audit automatique de sécurité des SI

o Par obligation.
En industrie aéronautique par exemple, les constructeurs exigent de leurs sous-traitants qu’ils
soient certifiés par certaines normes.
o Il y a aussi des entreprises qui se certifient pour elles-mêmes, pour optimiser leur
processus en interne.

2.3.1.4 Référentiel
Un référentiel est, de manière générale, un ensemble structuré d’information ou encore un
système de référence liée à un champ de connaissance, notamment en vue d'une pratique ou
d'une étude, et dans lequel se trouvent des éléments de définitions, de solutions, de pratiques
ou autres sujets relatifs de ce champ de connaissance.
Dans le domaine des systèmes d'information, le terme de référentiel est employé pour
désigner un ensemble structuré de recommandations ou de bonnes pratiques utilisées pour le
management du système d'information, et constituant un cadre commun aux directions des
systèmes d'information (DSI).
Les référentiels de management du système d'information sont internationaux. Ils sont
généralement orientés vers une problématique particulière :
 Pour la production informatique et l'assistance aux utilisateurs : Information
Technology Infrastructure Library (ITIL) ;
 Pour la gouvernance des systèmes d'information : COBIT ;
 Pour le développement et la maintenance du logiciel : Capability Maturity Model
Integration (CMMI) ; la première version, qui date de 1991, était limitée au génie
logiciel et s'appelait Capability Maturity Model ; le modèle s'est progressivement
étendu à d'autres domaines que le génie logiciel.
 Pour la sécurité des systèmes d'information : ISO/CEI 27001.
Pour chaque audit, un référentiel d’audit est donc défini à l’étape « d’expression de besoin ».
Selon le type d’audit (audit de processus, audit de sécurité, etc.), le référentiel d’audit est
composé d’un standard dont le type dépend du type d’audit.
De plus, par essence même, un audit intégré prend en compte plusieurs référentiels. En effet,
l’audit intégré considère plusieurs thématiques au travers d’un même audit. Chaque
thématique étant soutenue par son référentiel.
Un référentiel peut être standard ou constitué sur mesure selon les spécificités du
commanditaire. Il peut être aussi constitué par expérience. Dans ce dernier cas, les pratiques
de capitalisation sont fort utiles car elles permettent d’enrichir le référentiel en tenant compte
des retours d’expérience des différents audits. Par exemple, pour des audits d’acquisition de
société, un référentiel d’audit a été capitalisé par l’expérience.
Il existe différents référentiels comme :
o CobiT: (Control Objectives for Information and related Technology). C'est le principal
référentiel des auditeurs informatiques ;

13
Étude et mise en place d’une application d’audit automatique de sécurité des SI

o Val IT : permet d'évaluer la création de valeur par projet ou par portefeuille de


projets ;
o Risk IT : a pour but d'améliorer la maîtrise des risques liés à l'informatique ;
NB : Ces trois principaux ci-haut référentiels sont gérés par l’entreprise ISACA (Information
Systems Audit & Control Association) qui est l'association internationale des auditeurs
informatiques, créé en 1967. C’est un cadre de contrôle qui fournit de nombreux supports et
vise à aider le management à gérer les risques (la sécurité, la fiabilité et la conformité) et les
investissements.
Mais on peut aussi utiliser d'autres référentiels comme :
o ISO 27002 : code des bonnes pratiques en matière de management de la sécurité des
systèmes d'information ;
o CMMi : (CapabilityMaturity Model integration) : qui est une démarche d'évaluation de
la qualité de la gestion de projet informatique ;
o ITIL qui est un recueil des bonnes pratiques concernant les niveaux et de support des
services informatiques.

2.3.2 Normes relatives à la sécurité des systèmes d’information


Les normes sont des accords documentés contenant des spécifications techniques ou autres
critères précis destinés à être utilisés systématiquement en tant que règles, lignes directrices
ou définitions de caractéristiques pour assurer que des processus, services, produits et
matériaux sont aptes à leur emploi.

2.3.2.1 ISO/IEC 27001 : SMSI


L'ISO/CEI 27001 est la norme centrale de la famille ISO 2700x, c'est la norme d'exigences
qui définit les conditions pour mettre en œuvre et documenter un SMSI, publiée en octobre
2005 par l'ISO.

2.3.2.1.1 Objectif de la norme


La norme ISO 27001 publiée en octobre 2005 succède à la norme BS 7799-2 de BSI (British
Standards Institution). Elle s’adresse à tous les types d’organismes (entreprises commerciales,
administrations, etc…). La norme ISO/CEI 27001 décrit les exigences pour la mise en place
d'un Système de Management de la Sécurité de l'Information. Le SMSI est destiné à choisir
les mesures de sécurité afin d'assurer la protection des biens sensibles d'une entreprise sur un
périmètre défini. C'est le modèle de qualité PDCA (Plan-Do-Check-Act) qui est recommandé
pour établir un SMSI afin d'assurer une amélioration continue de la sécurité du système
d'information.
La norme dicte également les exigences en matière de mesures de sécurité propres à chaque
organisme, c’est-à-dire que la mesure n’est pas la même d’un organisme à l’autre. Les
mesures doivent être adéquates et proportionnées à l’organisme pour ne pas être ni trop

14
Étude et mise en place d’une application d’audit automatique de sécurité des SI

laxistes ni trop sévères. La norme ISO 27001 intègre aussi le fait que la mise en place d’un
SMSI et d’outils de mesures de sécurité aient pour but de garantir la protection des actifs
informationnels. L’objectif est de protéger les informations de toute perte ou intrusion. Cela
apportera la confiance des parties prenantes.
L'ISO/CEI 27001 définit l'ensemble des contrôles à effectuer pour s'assurer de la pertinence
du SMSI, à l'exploiter et à le faire évoluer. Plus précisément, l'annexe A de la norme est
composée des 133 mesures de sécurité de la norme ISO/CEI 27002 (anciennement ISO/CEI
17799), classées dans 11 sections. Comme pour les normes ISO 9001 et ISO 14001, il est
possible de se faire certifier ISO 27001.

2.3.2.2 ISO 27002 : Code de bonne pratique pour le SMSI


La norme ISO/CEI 27002 est une norme internationale concernant la sécurité de l'information,
publiée en 2005 par l'ISO, dont le titre en français est « Code de bonnes pratiques pour le
management de la sécurité de l’information ».
L'ISO/CEI 27002 est un ensemble de 133 mesures dites « best practices » (bonnes pratiques
en français), destinées à être utilisées par tous ceux qui sont responsables de la mise en place
ou du maintien d'un Système de Management de la Sécurité de l'Information.
La sécurité de l'information est définie au sein de la norme comme la « préservation de la
confidentialité, de l'intégrité et de la disponibilité de l'information ».
Cette norme n'a pas de caractère obligatoire pour les entreprises. Son respect peut toutefois
être mentionné dans un contrat : un prestataire de services pourrait ainsi s'engager à respecter
les pratiques normalisées dans ses relations avec un client.

2.3.2.2.1 Objectif de la norme


ISO/IEC 27002 est plus un code de pratique, qu’une véritable norme ou qu’une spécification
formelle telle que l’ISO/IEC 27001. Elle présente une série de contrôles (39 objectifs de
contrôle) qui suggèrent de tenir compte des risques de sécurité des informations relatives à la
confidentialité, l'intégrité et les aspects de disponibilité. Les entreprises qui adoptent
l'ISO/CEI 27002 doivent évaluer leurs propres risques de sécurité de l'information et
appliquer les contrôles appropriés, en utilisant la norme pour orienter l’entreprise.
La norme ISO 27002 n'est pas une norme au sens habituel du terme. En effet, ce n’est pas une
norme de nature technique, technologique ou orientée produit, ou une méthodologie
d'évaluation d'équipement telle que les critères communs CC/ISO 15408. Elle n’a pas de
caractère d'obligation, elle n’amène pas de certification, ce domaine étant couvert par la
norme ISO/IEC 27001.
Cette norme est issue de la BS 7799-1 (datant de 1995) qui a évolué en ISO 17799 : V2000,
puis en ISO 17799 : V2005. Enfin en 2007, la norme ISO/IEC 17799 : 2005 a été rebaptisée
en ISO 27002 pour s'intégrer dans la suite ISO 2700x, intitulé « Code de bonnes pratiques
pour la gestion de la sécurité de l'information ».
15
Étude et mise en place d’une application d’audit automatique de sécurité des SI

ISO 27002 couvre le sujet de la gestion des risques. Elle donne des directives générales sur la
sélection et l'utilisation de méthodes appropriées pour analyser les risques pour la sécurité des
informations.
Elle est composée 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 (les objectifs de sécurité et les mesures à prendre).
 Chapitres définissant le cadre de la norme :
o Chapitre n°1 : Champ d'application
o Chapitre n°2 : Termes et définitions
o Chapitre n°3 : Structure de la présente norme
o Chapitre n°4 : Évaluation des risques et de traitement
 Les chapitres définissant les objectifs de sécurité et les mesures à prendre
o Chapitre n°5 : Politique de sécurité de l'information
o Chapitre n°6 : Organisation de la sécurité de l'information
o Chapitre n°7 : Gestion des actifs
o Chapitre n°8 : Sécurité liée aux ressources humaines
o Chapitre n°9 : Sécurités physiques et environnementales
o Chapitre n°10 : Exploitation et gestion des communications
o Chapitre n°11 : Contrôle d'accès
o Chapitre n°12 : Acquisition, développement et maintenance des systèmes
d'informations
o Chapitre n°13 : Gestion des incidents
o Chapitre n°14 : Gestion de la continuité d'activité
o Chapitre n°15 : Conformité.

2.3.2.3 ISO/IEC 27005 : Management des risques


La première norme de gestion des risques de la Sécurité des Systèmes d'Information :
l'ISO/CEI 27005. Cette norme est un standard international qui décrit le Système de
Management des risques liés à la Sécurité de l'information.
Certains expliquent que cette norme est en fait une méthode quasi-applicable en se servant des
annexes et en les adaptant à leur contexte. D'ailleurs dans l'enquête 2010 du CLUSIF, 35%
des entreprises qui font analyses de risques déclarent le faire en utilisant la norme ISO 27005.

2.3.2.3.1 Objectif de la norme


La norme ISO 27005 explique en détail comment conduire l'appréciation des risques et le
traitement des risques, dans le cadre de la sécurité de l'information. La norme ISO 27005
propose une méthodologie de gestion des risques en matière d'information dans l'entreprise
conforme à la norme ISO/CEI 27001. La nouvelle norme a donc pour but d’aider à mettre en
œuvre l’ISO/CEI 27001, la norme relative aux systèmes de management de la sécurité de

16
Étude et mise en place d’une application d’audit automatique de sécurité des SI

l’information (SMSI), qui est fondée sur une approche de gestion du risque. Néanmoins, la
norme ISO 27005 peut être utilisée de manière autonome dans différentes situations. La
norme ISO 27005 applique à la gestion de risques le cycle d'amélioration continue PDCA
(Plan, Do, Check, Act) utilisé dans toutes les normes de systèmes de management.
 Plan : Identification des risques, évaluation des risques et définition des actions de
réduction des risques,
 Do : Exécution de ces actions,
 Check : Contrôle du résultat,
 Act : Révision de la politique de traitement des risques selon ces résultats.

2.3.2.3.2Contenu de la norme
La norme ISO/CEI 27005 détaille le processus de gestion de risque dans les chapitres 6 à 12.
Elle est complétée de 6 annexes de référence A à F, nécessaires à la mise en œuvre de la
méthode.
Chapitre 6 : le processus de gestion de risque est expliqué dans son ensemble
Chapitre 7 : établir le contexte de l’analyse des risques
Chapitre 8 : définition de l’appréciation des risques
Chapitre 9 : quatre choix du traitement du risque sont proposés
Chapitre 10 : acceptation du risque
Chapitre 11 : communication du risque
Chapitre 12 : surveillance et réexamen des risques
s
2.3.2.3.3 Démarche de la norme
A cette étape, on définit les critères :
o D’évaluation : seuil de traitement des risques, localement par actif menacé et
globalement, pour toute l'organisation ;
o D’impact : seuil de prise en compte des risques ;
o D’acceptation : seuil d’acceptation des risques ;
Il n’existe pas d’échelles normalisées pour ces critères. L’entreprise doit déterminer une
échelle pertinente en fonction de sa situation. Il faut également définir les champs, les limites
et l’environnement du processus de gestion du risque.

2.3.2.3.4 Appréciation des risques


La première étape consiste à définir le contexte et les éléments qui le composent tels que
l’organisme, le système d’information, les éléments essentiels à protéger les entités qui en
dépendent et les différentes contraintes qui peuvent se présenter.

17
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Ensuite, il est nécessaire d’exprimer les besoins de sécurité des éléments essentiels et,
identifier, caractériser en termes d’opportunités les menaces pesant sur le système
d’information.
Enfin, les risques sont déterminés en confrontant les menaces aux besoins de sécurité. Ces
risques seront analysés et évalués afin de donner des priorités et les ordonnancer par rapport à
leurs critères d'évaluation.

2.3.2.3.5 Traitement du risque


Il s’agit du processus de sélection et de mise en œuvre des mesures. Cela passera tout d’abord
par l’identification des objectifs de sécurité : détermination des modes de traitement et prise
en compte des éléments du contexte. Les objectifs ainsi identifiés constitueront le cahier des
charges du processus de traitement des risques. Ensuite, des exigences de sécurité seront
déterminées afin de satisfaire les objectifs de sécurité et décrire comment traiter les risques.
Pour définir les options de traitement, il faut mettre en adéquation le risque et le coût de
traitement. Il existe quatre options du traitement du risque :
o Le refus où l’évitement : le risque considéré est trop élevé, l’activité amenant le
risque doit être supprimée.
o Le transfert : le risque sera partagé avec une autre entité (un assureur, un sous-
traitant) capable de le gérer.
o La réduction : le risque doit être diminué. Il s’agit d'en réduire l’impact et/ou la
potentialité de manière que le risque soit acceptable.
o Conservation du risque : le risque est maintenu tel quel.

2.3.2.3.6 Acceptation du risque


Il s’agit d’une homologation de sécurité effectuée par une autorité d’homologation désignée
pour une durée déterminée. Cette homologation passe par l’examen d’un dossier de sécurité
dont le contenu doit être défini : objectifs de sécurité, d'une cible de sécurité, politique de
sécurité… La direction générale doit accepter les risques résiduels, donc accepter le plan de
traitement du risque dans son ensemble.

2.3.2.3.7 Communication du risque


Il s’agit d’un échange et un partage régulier d’informations sur les risques entre le
gestionnaire des risques, les décisionnaires et les parties prenantes concernant la gestion du
risque. Cette communication du risque permet de :
o Réduire les incompréhensions avec les décisionnaires
o Obtenir de nouvelles connaissances en sécurité
o Impliquer la responsabilité des décisionnaires

18
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.3.2.3.8 Surveillance et réexamen du risque


Il faut s'assurer que le processus reste pertinent et adapté aux objectifs de sécurité des métiers
de l'organisme. Il faut également identifier les changements nécessitant une réévaluation du
risque ainsi que les nouvelles menaces et vulnérabilités.

2.4 Méthodes d’audit de sécurité des SI


2.4.1 Méthode EBIOS
La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité)
permet d'apprécier et de traiter les risques. Elle fournit également tous les éléments
nécessaires à la communication au sein de l'organisme et vis-à-vis de ses partenaires, ainsi
qu'à la validation du traitement des risques. Elle constitue de ce fait un outil complet de
gestion des risques.

2.4.1.1Gestion des risques avec EBIOS


2.4.1.1.1 L'établissement du contexte
Un contexte bien défini permet de gérer les risques de manière parfaitement appropriée, et
ainsi de réduire les coûts à ce qui est nécessaire et suffisant au regard de la réalité du sujet
étudié.
Pour ce faire, il est essentiel d'appréhender les éléments à prendre en compte dans la
réflexion :
o Le cadre mis en place pour gérer les risques ;
o Les critères à prendre en considération (comment estimer, évaluer et valider le
traitement des risques) ;
o La description du périmètre de l'étude et de son environnement (contexte externe et
interne, contraintes, recensement des biens et de leurs interactions…).
La méthode EBIOS permet d'aborder tous ces points selon le degré de connaissance que l'on a
du sujet étudié. Il sera ensuite possible de l'enrichir, de l'affiner et de l'améliorer à mesure que
la connaissance du sujet s'améliore.

2.4.1.1.2 L'appréciation des risques


Il y a risque de sécurité de l'information dès lors qu'on a conjointement :
o Une source de menace ;
o Une menace ;
o Une vulnérabilité ;
o Un impact.
On peut ainsi comprendre qu'il n'y a plus de risque si l'un de ces facteurs manque. Or, il est
extrêmement difficile, voire dangereux, d'affirmer avec certitude qu'un des facteurs est absent.
Par ailleurs, chacun des facteurs peut contribuer à de nombreux risques différents, qui peuvent
eux-mêmes s'enchaîner et se combiner en scénarios plus complexes, mais tout autant réalistes.
19
Étude et mise en place d’une application d’audit automatique de sécurité des SI

On va donc étudier chacun de ces facteurs, de la manière le plus large possible. On pourra
alors mettre en évidence les facteurs importants, comprendre comment ils peuvent se
combiner, estimer et évaluer (hiérarchiser) les risques. Le principal enjeu reste, par
conséquent, de réussir à obtenir les informations nécessaires qui puissent être considérées
comme fiables. C'est la raison pour laquelle il est extrêmement important de veiller à ce que
ces informations soient obtenues de manière à limiter les biais et à ce que la démarche soit
reproductible.
Pour ce faire, la méthode EBIOS se focalise tout d'abord sur les événements redoutés (sources
de menaces, besoins de sécurité et impacts engendrés en cas de non-respect de ces besoins),
puis sur les différents scénarios de menaces qui peuvent les provoquer (sources de menaces,
menaces et vulnérabilités). Les risques peuvent alors être identifiés en combinant les
événements redoutés et les scénarios de menaces, puis estimés et évalués afin d'obtenir une
liste hiérarchisée selon leur importance.

2.4.1.1.3 Le traitement des risques


Les risques appréciés permettent de prendre des décisions objectives en vue de les maintenir à
un niveau acceptable, compte-tenu des spécificités du contexte.
Pour ce faire, EBIOS permet de choisir le traitement des risques appréciés au travers des
objectifs de sécurité : il est ainsi possible, pour tout ou partie de chaque risque, de le réduire,
de le transférer (partage des pertes), de l'éviter (se mettre en situation où le risque n'existe pas)
ou de le prendre (sans rien faire). Des mesures de sécurité peuvent alors être proposées et
négociées afin de satisfaire ces objectifs.

2.4.1.1.4 La validation du traitement des risques


La manière dont les risques ont été gérés et les risques résiduels subsistants à l'issue du
traitement doivent être validés, si possible formellement, par une autorité responsable du
périmètre de l'étude.
Cette validation, généralement appelée homologation de sécurité, se fait sur la base d'un
dossier dont les éléments sont issus de l'étude réalisée.

2.4.1.1.5 La communication et la concertation relatives aux risques


Obtenir des informations pertinentes, présenter des résultats, faire prendre des décisions,
valider les choix effectués, sensibiliser aux risques et aux mesures de sécurité à appliquer,
correspondent à des activités de communication qui sont réalisées auparavant, pendant et
après l'étude des risques.
Ce processus de communication et concertation relatives aux risques est un facteur crucial de
la réussite de la gestion des risques. Si celle-ci est bien menée, et ce, de manière adaptée à la
culture de l'organisme, elle contribue à l'implication, à la responsabilisation et à la
sensibilisation des acteurs.

20
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Elle crée en outre une synergie autour de la sécurité de l'information, ce qui favorise
grandement le développement d'une véritable culture de sécurité et du risque au sein de
l'organisme.
L'implication des acteurs dans le processus de gestion des risques est nécessaire pour définir
le contexte de manière appropriée, s'assurer de la bonne compréhension et prise en compte des
intérêts des acteurs, rassembler différents domaines d’expertise pour identifier et analyser les
risques, s'assurer de la bonne prise en compte des différents points de vue dans l'évaluation
des risques, faciliter l'identification appropriée des risques, l'application et la prise en charge
sécurisée d'un plan de traitement.
EBIOS propose ainsi des actions de communication à réaliser dans chaque activité de la
démarche.
2.4.1.1.6 La surveillance et la revue des risques
Le cadre mis en place pour gérer les risques, ainsi que les résultats obtenus, doivent être
pertinents et tenus à jour afin de prendre en compte les évolutions du contexte et les
améliorations précédemment identifiées.
Pour ce faire, la méthode EBIOS prévoit les principaux éléments à surveiller lors de la
réalisation de chaque activité et lors de toute évolution du contexte afin de garantir de bons
résultats et de les améliorer en continu.

2.4.1.2 Démarche EBIOS


La méthode formalise une démarche découpée en cinq modules représentés sur la figure
suivante :

21
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 2: Démarche EBIOS

La démarche EBIOS est dite itérative. En effet, il sera fait plusieurs fois appel à chaque
module afin d'en améliorer progressivement le contenu, et la démarche globale sera également
affinée et tenue à jour de manière continue.

Module 1 – Étude du contexte


À l'issue du premier module, qui s'inscrit dans l'établissement du contexte, le cadre de la
gestion des risques, les métriques et le périmètre de l'étude sont parfaitement connus ; les
biens essentiels, les biens supports sur lesquels ils reposent et les paramètres à prendre en
compte dans le traitement des risques sont identifiés.

Module 2 – Étude des événements redoutés


Le second module contribue à l'appréciation des risques. Il permet d'identifier et d'estimer les
besoins de sécurité des biens essentiels (en termes de disponibilité, d'intégrité, de
confidentialité…), ainsi que tous les impacts (sur les missions, sur la sécurité des personnes,
financiers, juridiques, sur l'image, sur l'environnement, sur les tiers et autres…) en cas de non-

22
Étude et mise en place d’une application d’audit automatique de sécurité des SI

respect de ces besoins et les sources de menaces (humaines, environnementales, internes,


externes, accidentelles, délibérées…) susceptibles d'en être à l'origine, ce qui permet de
formuler les événements redoutés.

Module 3 – Étude des scénarios de menaces


Le troisième module s'inscrit aussi dans le cadre de l'appréciation des risques. Il consiste à
identifier et estimer les scénarios qui peuvent engendrer les événements redoutés, et ainsi
composer des risques. Pour ce faire, sont étudiées les menaces que les sources de menaces
peuvent générer et les vulnérabilités exploitables.

Module 4 – Étude des risques


Le quatrième module met en évidence les risques pesant sur l'organisme en confrontant les
événements redoutés aux scénarios de menaces. Il décrit également comment estimer et
évaluer ces risques, et enfin comment identifier les objectifs de sécurité qu'il faudra atteindre
pour les traiter.

Module 5 – Étude des mesures de sécurité


Le cinquième et dernier module s'inscrit dans le cadre du traitement des risques. Il explique
comment spécifier les mesures de sécurité à mettre en œuvre, comment planifier la mise en
œuvre de ces mesures et comment valider le traitement des risques et les risques résiduels.

2.4.2 Méthode MEHARI


Méhari est une méthode d’analyse de risques fondée sur une identification préalable et
générale de situations de risque et sur une méthode d’évaluation de la gravité de chaque
situation, en fonction du contexte et de la situation de chaque entreprise ou organisme.
La méthode d’évaluation de la gravité des risques est basée sur un modèle de risque qui a été
publié pour la première fois en 1992 et dont la pertinence, confirmée par l’expérience, n’est
plus à démontrer.
Les situations de risques, décrites par des scénarios de risque, ainsi que les services de
sécurité à même de réduire les risques, sont décrits dans des bases de connaissance propres à
chaque version de MEHARI. Ces bases contiennent également des questionnaires
d’évaluation des services de sécurité ainsi que l’ensemble des éléments et algorithmes
permettant d’évaluer les risques.
Cette base de connaissance, introduite en 2017, est structurée pour prendre en compte
strictement la révision de la norme ISO 27001 : 2013 dans son diagnostic des vulnérabilités
tout en ajoutant ses objectifs propres d’analyse et de traitement des risques liés à
l’information.

23
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La mise en œuvre de MEHARI Standard est plus légère que pour MEHARI Expert en ce qui
concerne les questionnaires de vulnérabilités et le nombre de scénarios mais apporte un plus
en ce qui concerne l’évolution des risques en fonction des projets décidés et réalisés en
support de la politique de sécurité de l’organisme.
Dans la suite de notre travail, nous nous contenterons de la présentation de MEHARI PRO qui
est adaptée aux petites et moyennes entreprises.
MEHARI consiste à :
 Procéder à l’analyse des enjeux et à la classification des actifs de l’organisation
(DIC) ;
 Procéder à un diagnostic de la qualité des services de sécurité en place (vulnérabilité) ;
 Identifier les scénarios de risques plausibles pouvant altérer la qualité (DIC) ou le
fonctionnement des actifs impliqués ;
 Identifier les mesures de sécurité à mettre en place pour réduire la gravité des risques
non acceptables et décider des actions à entreprendre sur les autres risques ;
 Élaborer un plan d’action priorisant les mesures ayant le plus grand effet sur
l’atténuation des risques.

Le schéma ci-dessous résume la démarche.

Figure 3: Phase MEHARI

Les forces de l’approche actuelle de MEHARI-Pro :


 Simplicité de l’application de la méthode ;
 Rigueur de l’approche méthodologique ;

24
Étude et mise en place d’une application d’audit automatique de sécurité des SI

 Richesse et cohérence de sa base de connaissances qui est une extraction de celle de


MEHARI-EXPERT ;
 Prise en compte des niveaux de qualité des mesures de sécurité pour évaluer les
risques résiduels (en effet, l’efficacité des mesures de sécurité pour réduire les risques
dépend des mécanismes adoptés et de leur robustesse)
 Prise en compte des niveaux d’efficacité d’une mesure de sécurité pour diminuer les
risques (en effet, certaines mesures de sécurité apportent plus de valeur ajoutée) ;
 Facilité, pour un non-spécialiste, de bien analyser les situations et de proposer des
mesures tenant compte de la maturité et de la capacité de l’organisation à mettre en
œuvre les solutions proposées ;
 Simplicité d’illustration de la progression en matière de gestion de risques de
l’organisation.

MEHARI-Pro se caractérise comme suit :


Pour les actifs :
6 actifs de type « données et informations » soit :
 Fichiers informatiques (applicatifs)
 Données informatiques isolées qu’elles soient stockées, temporaires ou en transit
 Fichiers bureautiques
 Courrier électronique
 Documents non informatiques, imprimés ou manuscrits
 Informations publiées ou services accessibles sur un serveur Internet
4 actifs de type « services » soit :
 Services informatiques et de télécommunication
 Équipements mis à la disposition des utilisateurs (ordinateurs, imprimantes locales,
périphériques, interfaces spécifiques, etc.)
 Services offerts sur sites Internet
 Environnement de travail des utilisateurs
Pour les services de sécurité
 43 services de sécurité caractérisés par 377 questions
 74 scénarios de risques répartis comme suit :
 38 scénarios en disponibilité
 15 scénarios en intégrité
 21 scénarios en confidentialité

2.4.2.1 L’analyse des enjeux


Quelles que soient les orientations ou la politique, en matière de sécurité de l’information, il y
a un principe sur lequel tous les gestionnaires s’accordent, c’est celui de la juste proportion
entre les moyens investis dans la sécurité et la hauteur des enjeux de cette même sécurité.
L’objectif de l’analyse des enjeux est de répondre à cette double question :

25
Étude et mise en place d’une application d’audit automatique de sécurité des SI

« Que peut-on redouter et, si cela devait arriver, serait-ce grave ? (L’organisation serait-elle
en mesure d’y faire face ?) »
MEHARI-Pro intègre un module d’analyse des enjeux, qui aboutit à deux types de résultats :
1. Une échelle de valeurs des dysfonctionnements.
2. Une classification des informations et des actifs du système d’information.

2.4.2.2 Échelle de valeurs des dysfonctionnements


La recherche des dysfonctionnements généraux dans les processus opérationnels ou des
événements que l’on peut redouter est une démarche qui s’exerce à partir des activités de
l’organisation. Une telle démarche mène à :
 Une description des types de dysfonctionnements redoutés pouvant affecter la
disponibilité, l’intégrité ou la confidentialité.
 Une définition des paramètres qui influencent la gravité de chaque dysfonctionnement.
L’évaluation des seuils d’impact ou de criticité de ces paramètres qui font passer la gravité
des dysfonctionnements d’un niveau à un autre, cet ensemble de résultats constitue une
échelle de valeurs des dysfonctionnements.

2.4.2.3 Classification des informations et des actifs


Il est d’usage, dans le domaine de la sécurité de l’information, de parler de la classification
des informations et des actifs du système d’information.
Cette classification consiste à définir pour chaque type de processus d’affaires, l’information
indispensable (actif primaire) et, pour chaque information, les systèmes d’information les
supportant (actif de soutien) et, pour chacun des critères de classification (soit la
Disponibilité, l’Intégrité et la Confidentialité), des indicateurs représentatifs de la gravité
d’une atteinte à ce critère pour cette information ou cet actif.
La classification des informations et actifs est la traduction, pour les systèmes d’information,
de l’échelle de valeurs des dysfonctionnements, définie précédemment, en indicateurs de
sensibilité associés aux actifs du système d’information (aussi appelé « Sensibilité DIC »).

2.4.2.4 Expression des enjeux de la sécurité


L’échelle de valeurs des dysfonctionnements et la classification des actifs sont deux manières
distinctes d’exprimer les enjeux de la sécurité.
La première est plus détaillée et fournit plus de renseignements pour des responsables de
sécurité alors que la seconde est plus globale et facilite la communication sur le degré de
sensibilité DIC des actifs, avec moins de précision.

26
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.4.2.5 Les diagnostics des services de sécurité


2.4.2.5.1 Le diagnostic de sécurité
A ce niveau, le modèle de risque prend en compte des « facteurs de réduction de risque » qui
sont concrétisés par l’existence des services de sécurité en place.
Le diagnostic de ces services sera donc, lors de l’analyse des risques, un élément important
d’assurance que les services en place remplissent bien leur rôle, ce qui est essentiel pour
qu’une analyse de risque soit crédible et fiable.
MEHARI-Pro s’appuie sur une base de diagnostic reconnue d’évaluation de la qualité des
mesures de sécurité en place ou planifiées, ce qui en fait une méthode crédible lors de
l’évaluation des risques et de la planification des plans d’action

2.4.2.5.2 L’analyse des risques


L’analyse de risques est citée dans beaucoup d’ouvrages sur la sécurité de l’information, et
notamment dans les normes ISO/IEC de la série 27000, comme devant être la base de
l’expression des besoins de sécurité.
MEHARI propose, depuis plus de 15 ans, une approche structurée du risque3 qui repose sur
quelques éléments simples.
Pour l’essentiel, une situation à risque peut être caractérisée par divers facteurs :
 Des facteurs structurels qui ne dépendent pas des mesures de sécurité, mais du
domaine d’affaires de l’entreprise, de son environnement et de son contexte.
 Des facteurs de réduction de risques qui sont, eux, directement fonction des mesures
de sécurité mises en place.
Précisons simplement qu’une analyse des enjeux est nécessaire pour déterminer la gravité
maximale des conséquences d’une situation à risque, ce qui est typiquement un facteur
structurel, alors que des diagnostics de sécurité sont nécessaires pour évaluer les facteurs de
réduction de risques.
MEHARI-Pro permet d’évaluer ces facteurs et de porter un jugement sur le niveau de risques.
MEHARI s’appuie, pour cela, sur des outils (critères d’appréciation, méthodes de calcul, etc.)
et des bases de connaissances (en particulier pour les diagnostics de sécurité) qui s’avèrent
indispensables en complément du cadre minimum proposé par la norme ISO 27005.

2.4.2.6 L’analyse systématique des situations de risques


Pour répondre à la question « À quels risques l’organisation est-elle exposée et ces risques
sont-ils acceptables ? », une méthode structurée consiste à évaluer toutes les situations de
risque potentielles, à identifier individuellement les plus critiques, puis à décider des actions à
mener afin de les ramener à un niveau acceptable.
MEHARI-Pro permet de réaliser cette analyse et les bases de connaissance ont été
développées afin d’atteindre cet objectif. Dans cette utilisation de MEHARI, l’accent est mis

27
Étude et mise en place d’une application d’audit automatique de sécurité des SI

sur l’assurance que les situations critiques les plus souvent rencontrées ont été prises en
compte et sont bien couvertes par un plan d’action.
Cette méthode s’appuie sur une base de connaissances de situations de risques et sur des
mécanismes d’évaluation des facteurs caractérisant chaque risque et permettant d’en apprécier
le niveau. La méthode fournit, en outre, des aides pour définir les plans de traitement adaptés.

2.4.2.7 Le plan d’action en sécurité de l’information


À l’issue de la phase d’analyse des risques et des prises de décision concernant le traitement
des risques, l’organisation doit statuer sur un certain nombre d’actions à mener qui relève,
selon le type de traitement retenu :
 De la mise en place de services de sécurité, avec pour chacun, un objectif de niveau de
qualité.
 De mesures structurelles visant à réduire certaines expositions aux risques.
 De mesures organisationnelles visant à éviter certains risques.
Ceci étant dit, il doit être clair que toutes ces actions ne seront sans doute pas menées
simultanément ni toutes engagées immédiatement, pour diverses raisons telles que la
limitation des ressources budgétaires, l’indisponibilité des ressources humaines, etc.
Dans ces conditions, la phase d’élaboration des plans d’action doit inclure les étapes suivantes
:
Le choix des objectifs prioritaires, en termes de services de sécurité à mettre en œuvre (ou à
améliorer) et l’optimisation de ce choix reposant sur les risques les plus élevés à atténuer et
sur la capacité de l’organisation à les mettre en œuvre ;
 La transformation des choix de services de sécurité (à implanter ou à améliorer) en
plans d’action concrets ;
 Le choix des mesures structurelles éventuelles et des mesures d’évitement des
risques ;
 La validation des décisions précédentes par la haute direction.

2.4.2.8 Contrôle et pilotage de la gestion directe des risques


Les contrôles à effectuer pour piloter la gestion directe des risques sont multiples et sont
représentés par le schéma suivant :

28
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 4: Gestion directe des risques

Le premier niveau de contrôle à effectuer vise à s’assurer que les mécanismes et solutions de
sécurité planifiés et décidés correspondent bien au niveau de qualité des services retenus et en
phase de traitement des risques.
Le deuxième contrôle est un contrôle de mise en œuvre.

2.4.2.9 Contrôle du niveau de qualité des services retenus


Ce contrôle cherche à savoir comment le personnel technique en charge de définir les
mécanismes et solutions à mettre en œuvre va pouvoir le faire avec une connaissance
suffisante de l’impact de leurs décisions sur le niveau de qualité du service qui sera obtenu
une fois implanter.
Par ailleurs, un contrôle a posteriori sera nécessaire et ce contrôle devra être effectué par du
personnel qui ne sera pas obligatoirement un technicien confirmé et d’expérience.
Cela conduit à la nécessité d’une base d’expertise ou base d’audit des services de sécurité qui
permettra des choix appropriés lors de la phase de définition des mécanismes et des solutions
à mettre en œuvre, d’une part, et un contrôle a posteriori, d’autre part.
Justification de la nécessité d’une base d’audit des services de sécurité
Dans les principes de MEHARI, et bien entendu dans ses bases de connaissances, la qualité
des services de sécurité comprend trois aspects que sont leur efficacité, leur robustesse et leur
mise sous contrôle.
Pour pouvoir vérifier chacun de ces aspects, des questions spécifiques devront être posées.
Il est alors nécessaire qu’il y ait une ligne directrice et un répertoire des questions à poser et
qu’à ces questions soit associé un système de cotation des réponses pour pouvoir qualifier de
manière fiable et reproductive la qualité de chaque service de sécurité.

29
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.4.2.10 Contrôle de la mise en œuvre des services de sécurité


Il est bien clair que la mise en œuvre effective des services de sécurité définis précédemment
devra être contrôlée.
On sera souvent amené à constater des situations dans lesquelles des services de sécurité ont
été partiellement déployés et où leur mise en œuvre n’est pas totalement conforme aux
décisions prises au préalable.
Du point de vue de la gestion des risques la conduite à tenir dans de tels cas est explicitée
dans la documentation d’accompagnement de la méthode.

Pilotage global associé à la gestion des risques


Le pilotage global de la gestion directe des risques ressemble à tout pilotage de projet et
comprend :
 Des indicateurs et un tableau de bord ;
 Un système de rapport ;
 Un système de revue périodique et de prise de décision relative aux actions correctives
nécessaires.

2.5 Démarche standard d'audit


La norme ISO 19011-2002 Lignes directrices pour l'audit des systèmes de management de la
qualité et ou de management environnemental standardise la démarche d’audit avec les étapes
suivantes :

2.5.1 Préparation/initiation
Prise de contact visant à préciser le périmètre de la phase et les outils à utiliser pour la
préparation des opérations de collecte des informations (manuels, procédures, interviews, …).

2.5.2 Exécution/Collecte
Exploitation des documents fournis par le client (fiches techniques, manuel des procédures,
cahier d’architecture, …) s’ils existent, analyse sur site des éléments à étudier et série
d’entretiens menés avec les principaux personnels ressources.

2.5.3 Analyse
Exploitation des informations précédemment collectées dans un contexte global dégagé par
les phases précédentes. Le recours à des sources d’informations externes peut éventuellement
s’avérer nécessaire afin de préciser certains points.

2.5.4 Restitution
Rédaction des documentations et livrables intermédiaires ou finaux soumis au Chef de Projet
du client pour avis avant initiation de la phase suivante. • Respect du principe contradictoire !

30
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Tenue de réunions de pilotage et de restitution afin d'assurer une synergie entre les équipes du
prestataire et du client.

2.5.5 Suivi
L’élaboration du plan d’action suite aux constats, suivi de l'efficacité des actions engagées.

2.6 Démarche de réalisation d’un audit de sécurité


Tel que précédemment évoqué, l’audit de sécurité des systèmes d’information se déroule
généralement suivant deux principales étapes. Cependant il existe une phase tout aussi
importante qui est une phase de préparation. Nous schématisons l’ensemble du processus
d’audit à travers la figure suivante :

Figure 5Phase d’audit

2.6.1 Charte d’audit


Avant de procéder à une mission audit, une chartre d'audit doit être réalisée, elle a pour objet
de définir la fonction de l’audit, les limites et modalités de son interventions, ses
responsabilités ainsi que les principes régissant les relations entre les auditeurs et les audités.
Elle fixe également les qualités professionnelles et morales requises des auditeurs.

2.6.2 Préparation de l’audit


Cette phase est aussi appelée phase de pré-audit. Elle constitue une phase importante pour la
réalisation de l’audit sur terrain. En effet, c’est au cours de cette phase que se dessinent les
grands axes qui devront être suivis lors de l’audit sur terrain

31
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Elle constitue une phase importante pour la réalisation de l’audit sur terrain.
En synthèse on peut dire que cette étape permet de :
 Définir un référentiel de sécurité (dépend des exigence et attentes des responsables du
site audité, type d’audit).
 Élaboration d’un questionnaire d’audit de sécurité à partir du référentiel et des
objectifs de la mission.
 Planification des entretiens et informations de personnes impliquées.

2.6.3 Audit organisationnel et physique


2.6.3.1 Objectif
Dans cette étape, il s’agit de s’intéresser à l’aspect physique et organisationnel de l’organisme
cible, à auditer.
Nous nous intéressons donc aux aspects de gestion et d’organisation de la sécurité, sur les
plans organisationnels, humains et physiques.
Les objectifs visés par cette étape sont donc :
 D’avoir une vue globale de l´état de sécurité du système d´information,
 D´identifier les risques potentiels sur le plan organisationnel.

2.6.3.2 Déroulement
Afin de réaliser cette étape de l’audit, ce volet doit suivre une approche méthodologique qui
s’appuie sur un ensemble de questions. Ce questionnaire préétabli devra tenir compte et
s’adapter aux réalités de l’organisme à auditer. A l’issu de ce questionnaire, et suivant une
métrique, l’auditeur est en mesure d’évaluer les failles et d’apprécier le niveau de maturité en
termes de sécurité de l’organisme, ainsi que la conformité de cet organisme par rapport à la
norme référentielle de l’audit.

2.6.4 Audit technique


2.6.4.1 Objectif
Cette étape de l’audit sur terrain vient en seconde position après celle de l’audit
organisationnel. L’audit technique est réalisé suivant une approche méthodique allant de la
découverte et la reconnaissance du réseau audité jusqu’au sondage des services réseaux actifs
et vulnérables. Cette analyse devra faire apparaître les failles et les risques, les conséquences
d’intrusions ou de manipulations illicites de données.
Au cours de cette phase, l’auditeur pourra également apprécier l’écart avec les réponses
obtenues lors des entretiens. Il sera à même de tester la robustesse de la sécurité du système
d’information et sa capacité à préserver les aspects de confidentialité, d’intégrité, de
disponibilité et d’autorisation.

32
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.6.4.2 Déroulement
L’audit technique sera réalisé selon une succession de phases respectant une approche
méthodique. L’audit technique permet la détection des types de vulnérabilités suivante, à
savoir :

 Les erreurs de programmation et erreurs d’architecture.


 Les erreurs de configurations des composants logiques installés tels que les services
(ports) ouverts sur les machines, la présence de fichiers de configuration installés par
défaut, l’utilisation des comptes utilisateurs par défaut.
 Les problèmes au niveau de trafic réseau (flux ou trafic non répertorié, écoute
réseau...).
 Les problèmes de configuration des équipements d’interconnexion et de contrôle
d’accès réseau.
Les principales phases :
Phase 1 : Audit de l’architecture du système
o Reconnaissance du réseau et de plan d’adressage,
o Sondage des systèmes,
o Sondage réseau,
o Audit des applications.
Phase 2 : Analyse des vulnérabilités
o Analyse des vulnérabilités des serveurs en exploitation,
o Analyse des vulnérabilités des postes de travail.
Phase 3 : Audit de l’architecture de sécurité existante
Cette phase couvre entièrement/partiellement la liste ci-après :
o Audit des firewalls et des règles de filtrage,
o Audit des routeurs et des ACLs (liste de contrôle d’accès),
o Audit des sondes et des passerelles antivirales,
o Audit des stations proxy,
o Audit des serveurs DNS, d’authentification,
o Audit des commutateurs,
o Audit de la politique d’usage de mots de passe.

2.6.5 Test d’intrusion


Cet audit permet d’apprécier le comportement des installations techniques face à des attaques.
Également, il permet de sensibiliser les acteurs (management, équipes sur site, les utilisateurs)
par des rapports illustrant les failles décelées, les tests qui ont été effectués (scénarios et
outils) ainsi que les recommandations pour pallier aux insuffisances identifiées.

33
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.6.6 Rapport d’audit


A la fin des précédentes phases d’audit sur terrain, l’auditeur est invité à rédiger un rapport de
synthèse sur sa mission d’audit. Cette synthèse doit être révélatrice des défaillances
enregistrées. Autant est-il important de déceler un mal, autant il est également important d’y
proposer des solutions. Ainsi, l’auditeur est également invité à proposer des solutions
(recommandations), détaillées, pour pallier aux défauts qu’il aura constatés.
Les recommandations devront inclure au minimum :
 Une étude de la situation existante en termes de sécurité au niveau du site audité, qui
tiendra compte de l’audit organisationnel et physique, ainsi que les éventuelles
vulnérabilités de gestion des composantes du système (réseau, systèmes, applications,
outils de sécurité) et les recommandations correspondantes.
 Les actions détaillées (organisationnelles et techniques) urgentes à mettre en œuvre
dans l’immédiat, pour parer aux défaillances les plus graves, ainsi que la proposition
de la mise à jour ou de l’élaboration de la politique de sécurité à instaurer.

2.7 Moyens de collecte


Une combinaison des techniques suivantes est généralement exploitée afin de collecter les
informations relatives au système d'information nécessaires à l'exécution de l'audit :

2.7.1 Revue documentaire


La prise en compte de la documentation existante, qu'elle soit relative aux procédures
applicables (cahier des procédures, textes législatifs,), à la sécurité (politique de sécurité
interne, audits précédents, plans de sauvegarde, de continuité, …) ou au système (guide de
l'utilisateur, guide de l'administrateur, topologie du système, …), fournie une base de travail
précieuse.
En cas de carence de la documentation existante le consultant se devra de privilégier les autres
méthodes de collecte (visites, entretiens) afin d'y pallier.

2.7.2 Questionnaires
Un ou des questionnaires personnalisés sont conçus en relation avec les services du client afin
de collecter un maximum d'informations sur les procédures, formalisées ou tacites, de gestion
et d'exploitation du système d'information.
Ils peuvent être dérivés des modèles de questionnaires préconisés par les méthodologies
retenues.
Ces questionnaires peuvent soit être transmis aux personnels techniques et utilisateurs (retour
généralement faible et de qualité aléatoire) soit être exploités par l’auditeur lors d'entretiens
sur site.

34
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.7.3 Entretiens
Une série d'entretiens avec les personnels techniques et d'encadrement permet au consultant
de collecter des informations utiles sur le fonctionnement réel du système et sur son
historique.
Des entretiens avec les utilisateurs sont toujours utiles pour évaluer le niveau de satisfaction et
détecter d’éventuelles discordances avec les faits annoncés par les personnels techniques.
N.B. : suivant le type d’audit il est possible de se contenter des déclarations des personnels
interrogés (approche déclarative) ou de vérifier celles - ci. Dans tous les cas les techniques
d’entretiens doivent permettre de détecter les omissions ou approximations.

2.7.4 Visites sur site


Des visites sur les différents sites de l’organisation auditée permet au consultant de collecter
des informations concernant le système d'information et son environnement. Ces visites sur
site sont en outre indispensables afin de caractériser la topologie du système d'information et
de réaliser certains tests manuels ou automatiques.

2.7.5 Tests techniques


Une série de tests sont exécutés sur les différents systèmes et plates-formes constituant le
système informatisé à l'aide de logiciels ou outils spécialisés :

 Audit des applications avec OWASP ZAP


 Logiciels de cartographie de réseaux (NMap, LANsurveyor),
 Logiciels d'analyse de flux réseaux (WildPacket Omnipeek, Wireshark),
 Logiciels d'analyse de vulnérabilités (GFI LANguard NSS, Nessus, Nexpose),
 Logiciels d’exploitation de vulnérabilités (Metasploit, Aircrack-NG, Elcomsoft, Cain
& Abdel, …),
 Outils de mesure électrique (multimètre, mesureur de terre),
 Outil de certification de câblage réseau

2.8 Méthodologie d’audit


La première étape consiste à prendre connaissance de manière extrêmement fine les attentes
du client. Il convient de bien comprendre ses besoins et de les reformuler.
Cette première étape est particulièrement importante dans la mesure où elle plante le contexte
précis dans lequel l´audit va être mené : autant d´informations qui seront incluses dans le
rapport d´audit afin d´en faciliter l´interprétation, même plusieurs années après sa réalisation.
Ensuite, une lettre de mission sera rédigée. En plus de définir la procédure à venir, elle a deux
objectifs principaux :

35
Étude et mise en place d’une application d’audit automatique de sécurité des SI

o Elle est le contrat qui lie l’entreprise et l’auditeur ;


o Elle permettra d´informer les différentes personnes impliquées de l’arrivée d’un audit
dans l´entreprise. Elle est dans le même temps, auprès des salariés, une légitimation de
cet audit par la direction.
Troisième phase : le recueil de toutes les informations nécessaires pour préparer la mission.
Il s´agit de récolter les éléments relatifs à la culture de l´entreprise, au contexte général
toujours en corrélation avec le système d´information. Des rendez-vous sont donc organisés
avec les personnes concernées.
La quatrième phase est la réalisation de la mission, l'audition du système d'information de
l'entreprise peu commencé.
Enfin, une réunion de synthèse est organisée entre l´auditeur et les personnes intéressées. Il s
´agit de s´assurer ensemble :
o Que les questions de l´auditeur ont été bien comprises ;
o Que les réponses ont été bien interprétées.
Le rapport est ensuite rédigé, de plusieurs manières (concis et plus complet), car il s´adresse
en général à plusieurs types de publics.
Le rapport détaillé expliquera les attentes de départ, le contexte, les limites, les faiblesses
constatées, leur importance relative et les solutions.
Un rapport d´audit doit être clair et didactique. En aucun cas il ne doit être technique.

2.9 Utilité des outils d’automatisation des questionnaires


d’audit
L’audit est encore de nos jours une activité manuelle. Avec l’avènement de la transformation
digitale, il est aujourd’hui nécessaire de l’automatiser. La plupart des grandes entreprises, des
banques, assurances et cabinets d'audit utilisent avant tout Excel pour traiter les questionnaires
d'audit et les référentiels de gouvernances de l'entreprise. Ce type de solution individuelle est
utile pour les responsables des risques, l'audit, le RSSI, le responsable qualité, mais nettement
insuffisante pour garantir la cohérence du dispositif de contrôle interne et de la gouvernance
de l'entreprise.

36
Étude et mise en place d’une application d’audit automatique de sécurité des SI

CHAPITRE 3 : GESTION DES RISQUES

37
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.1 Fondamentaux et référentiels de gestion des risques


3.1.1 Fondamentaux de la gestion des risques
Nous présenterons dans cette partie les fondamentaux de la gestion des risques en
informatique.
- Gérer les risques de sécurité des systèmes d’information c’est anticiper le futur
concernant les évènements pouvant porter atteinte à la disponibilité, l’intégrité, la
confidentialité, la preuve sur des actifs informationnels entrainant des conséquences
négatives sur l’organisme.
- Actif : tout ce qui a de la valeur pour une entreprise.
- Typologies des Actifs :
 Les Actifs Primordiaux : Information et les Processus

 Les Actifs Support : Logiciel, Réseau, Matériel, Personnes, Site et

Organisation
- Menace : Cause potentielle d’un incident qui peut engendrer des dommages à un
système ou une organisation (ISO/CEI 27000 : 2009).
Exemples : Infection virale, incendie, espionnage, saturation du système
d’information, corruption de données, abus de droit (habilitation)…
- Vulnérabilité : Faiblesse d’un actif (ou d’une mesure de sécurité) qui peut être
exploitée par une menace (ISO/CEI 27000 : 2009).
Exemples : Présence d’un site en zone inondable, absence de mises à jour de sécurité,
stockage en clair d’un fichier, portabilité, mobilité, politique de mot de passe faible,
absence de procédure, absence de sensibilisation du personnel.
- Risque : Combinaison de la probabilité d'un événement et de ses conséquences
(ISO/CEI 27000 : 2009
- Risque lié à la sécurité de l'information : Possibilité qu'une menace donnée exploite
une vulnérabilité d'un actif ou d'un groupe d'actifs et nuise donc à l'organisation.
(ISO/CEI 27000 : 2009)
- Mesure de sécurité : Moyens de management du risque, y compris les politiques, les
procédures, les lignes directrices, les pratiques ou l'organisation, qui peuvent être de
nature administrative, technique, de management ou juridique (ISO/CEI 27000 :
2009).
- Les contre-mesures : ce sont les procédures ou techniques permettant de résoudre
une vulnérabilité ou de contrer une attaque spécifique (auquel cas il peut exister
d'autres attaques sur la même vulnérabilité).

3.1.2 Référentiels de gestion de risques


La gestion des risques s’appuie sur des référentiels comme ISO 2700, ISO 27005 et ISO
31000.
La figure suivante présente le lien entre ces référentiels

38
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 6: Liens entre ISO 27001, ISO 27005 ET ISO 31000

3.1.2.1 ISO 31000

Figure 7: Processus de gestion de risque selon ISO 31000

39
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.1.2.2 ISO 27005

Figure 8: Gestion de risques selon ISO 27005

Figure 9: Autres référentiels

40
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.2 Les origines des risques


3.2.1 Origine humaine
3.2.1.1 Vol et sabotage de matériel
Les vols portent principalement sur les petits matériels, tels que les ordinateurs portables et les
supports informatiques (disques de serveurs, …). La disparition d’un ordinateur ou d’un
serveur peut être lourde de conséquences au cas où celui-ci n’a pas fait l’objet d’une copie de
sauvegarde récente et complète ou encore lorsque celui-ci contient des données ou
programmes confidentiels.
Dans les grandes gares ou aéroports, il ne se passe pas de journée sans qu’un ou plusieurs
portables ne soient volés. Ces outils des cadres contiennent le plus souvent des données
confidentielles de l’entreprise. Le vol d'un portable peut également permettre de prendre
connaissance des mots de passe et des informations nécessaires pour se connecter au réseau
interne de l'entreprise.
Le sabotage va de l’endommagement d’un appareil isolé aux attentats terroristes détruisant
toute une infrastructure.
L’utilisation de matériels hors standards du marché aggrave les conséquences d’un vol ou
d’un sabotage dans la mesure où l’obtention de matériels de remplacement peut s’avérer plus
difficile. Cette dimension du risque (diminution de sa capacité à réagir) devrait être prise en
compte dans les choix technologiques.

3.2.1.2 Fraudes
La pratique des fraudes est aussi vieille que le monde. L’informatique y a cependant ajouté de
nouvelles dimensions :
 Le montant moyen des fraudes informatiques est sensiblement plus élevé que celui des
fraudes traditionnelles ;
 Le manque d’enregistrements visibles réduit les chances de détection par observation
fortuite ;
 La sécurité est souvent sacrifiée au profit de l’efficience ;
 La complexité de certains systèmes est telle que les utilisateurs ne disposent plus de la
compétence requise pour vérifier l’exactitude des résultats produits ;
 Les contrôles organisationnels classiques (séparation de fonctions et de connaissances,
doubles contrôles, …) ont été négligés lors de l’introduction des nouveaux systèmes ;
 De nombreux systèmes informatiques ont été réalisés sans prendre la sécurité en
compte lors de leur conception ;
 Le personnel technique peut contourner des contrôles essentiels.
Les fraudes informatiques conduisent à des détournements de biens et de fonds. Elles peuvent
également avoir pour conséquence le sabotage du fonctionnement :
 Des exécutants, que l’on induit en erreur (ex. livraison à des clients dont l’insolvabilité
a été masquée, acceptation de risques tarés dans une compagnie d’assurances par
manipulation de l’historique des sinistres, …) ;
 Des gestionnaires, en basant le contrôle de gestion sur des états incorrects, ce qui peut
conduire à ne pas prendre des décisions qui s’imposeraient ou à prendre des décisions
41
Étude et mise en place d’une application d’audit automatique de sécurité des SI

inappropriées qui pourraient avoir des conséquences désastreuses (ex rentabilité des
départements et produits, situations de trésorerie, …).

3.2.1.3 Sabotage immatériel


Le sabotage immatériel concerne l’altération ou la destruction, totale ou partielle, des
données, des programmes ou de leurs sauvegardes. Ses conséquences peuvent être aussi
graves et parfois même davantage que celles d’un sinistre matériel, car il peut provoquer des
destructions en profondeur et avoir pour effet de neutraliser pendant un temps long le
fonctionnement du système informatique.
Le sabotage immatériel recouvre diverses notions :
 La modification non autorisée de programmes ;
 Le cheval de Troie qui est une partie de programme pernicieuse ajoutée à un autre
programme dont le comportement externe paraît normal ;
 Les bombes logiques, qui sortent leurs effets destructeurs de données ou de
programmes lors de la réalisation d’un événement (p.ex. survenance d’une date
particulière, destruction de fichiers lorsque le matricule de l’auteur licencié disparaît
du fichier du personnel…). Une forme particulièrement dommageable de bombe
logique consiste à altérer graduellement un nombre limité d’enregistrements d’une
grande base de données. Lorsque le problème est découvert, parfois au terme de
nombreux mois, il y a fort à parier que l’entreprise ne disposera plus d’aucune copie
de sauvegarde fiable et devra procéder à un contrôle exhaustif et coûteux de l’entièreté
de la base de données ;
 Les virus et vers, fortement médiatisés, qui agissent comme des bombes logiques mais
qui ont, en outre, la faculté de se reproduire et faire perdurer les infections. L’Internet
et le courrier électronique leur ont fourni des voies royales de propagation ;
 Les logiciels espions (« spyware »). Lorsqu'un utilisateur consulte licitement des sites
Internet, il peut lire une page intéressante, mais qui cache des parties malveillantes
permettant à ces dangereux logiciels espions de s'installer dans le poste de travail et de
migrer sur le réseau interne tout en communiquant des informations-clés vers
l'extérieur. Techniquement, ces pages dangereuses sont beaucoup plus difficiles à
détecter que les virus dans les mails.
Le recours intensif à l’Internet a fait apparaître de nouvelles formes d’actes malveillants, dont
voici quelques exemples :
 Le déni de service, qui se traduit par l’indisponibilité d’un site web. Il se provoque en
inondant et en saturant le serveur ou le réseau par une masse énorme de messages
rendant impossible l'accès normal aux ressources. Ces messages proviennent le plus
souvent de réseaux de PC mal protégés, encore appelés « botnets ». Il s’agit de réseaux
de PC « zombies », dont l’auteur malveillant a pris le contrôle. Ces réseaux peuvent
comporter des dizaines de milliers de PC, appartenant bien souvent à des propriétaires,
qui n’ont pas installé les mesures de sécurité élémentaires que sont des logiciels «
firewall » et des logiciels antivirus ;
 Le remplacement de la page d'accueil d’un site web par un renvoi automatique sur le
site d'un concurrent ou sur un site à caractère pornographique ;

42
Étude et mise en place d’une application d’audit automatique de sécurité des SI

 Le renvoi de la page d’accueil vers celle d’un site qui y ressemble très fortement, mais
qui est en fait celui d’une organisation malveillante, qui tentera ainsi de voler des
données personnelles (données d’identité de l’utilisateur, données relatives à des
comptes bancaires ou à des cartes de crédit, mots de passe, etc.) ;
 La modification des prix du catalogue d'une entreprise de vente exclusivement par
Internet ;
 La modification de l'adresse e-mail pour les commandes sur Internet et son
remplacement par l'adresse du concurrent ;
 Le dépôt, dans la boîte d'envoi du système de messagerie d'un service Relations
publiques d'un message annonçant l'ouverture d'une instruction judiciaire à l'encontre
de l'entreprise. Le message devait être envoyé aux agences de presse ;
 Le blocage du central téléphonique (ordinateur) empêchant toutes les communications
téléphoniques intérieures et extérieures. Les techniques de téléphonie par Internet
(VoIP) devront faire l’objet de mesures de protection adéquates.

3.2.1.4 Indiscrétion, détournement d’informations


II s’agit d’actes qui ont pour effet que des personnes non autorisées ont accès aux
informations maintenues par le système informatique. Ces informations peuvent être des
données ou des programmes (correspondances, contrats, secrets industriels, plans
commerciaux, calculs de prix de revient, offres, données personnelles, financières,
médicales…). Au fur et à mesure que des données de plus en plus confidentielles sont
confiées à des ordinateurs, ceux-ci deviennent les cibles privilégiées de cette forme actuelle
d’espionnage industriel.

3.2.1.5 Détournement de logiciels


La copie de logiciels pour ordinateur est une activité qui bat toujours son plein nonobstant les
succès récents de poursuites judiciaires engagées contre les pirates et la diminution de l’attrait
du copiage résultant des baisses de prix consenties par les éditeurs de logiciels.

3.2.2 Greve, départ de personnel stratégique


Le personnel est un maillon indispensable dans la chaîne qui assure le fonctionnement d’un
système d’information. L’indisponibilité, une épidémie ou la disparition d’un membre de
personnel-clé peut provoquer l’arrêt du système et par voie de conséquence celle de toute
l’activité de l’entreprise.

3.2.3 Origine technique


3.2.3.1 Risques matériels
C’est la destruction totale ou partielle d’un ou plusieurs composants d’un système
d’information (matériel informatique ou de communication, supports de données,
environnement tels que locaux, conditionnement d’air, alimentation électrique, installation
téléphonique, …) suite à des événements comme un choc, la coupure de câbles électriques ou
téléphoniques, l’incendie, l’inondation, la foudre, la tempête etc.
43
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.2.3.2 Pannes et dysfonctionnement


Généralement, les interruptions de service consécutives à des pannes sont de courte durée
mais ce n’est pas toujours le cas. Des défaillances de matériel ou de logiciels de base ont
provoqué des arrêts de fonctionnement de serveurs importants s’étendant sur plusieurs jours
ouvrables.
Les interruptions peuvent aussi résulter de pannes dont l’origine est externe à l’entreprise
(réseau téléphonique, alimentation électrique, …).
L’impossibilité d’accéder au réseau Internet peut empêcher une organisation de recevoir ou
d’émettre du courrier électronique ou faire en sorte qu’un site de commerce électronique ne
puisse plus recevoir de commandes.
A ce niveau également, les CEO, les CIO et les CISO seront bien avisés de jauger
régulièrement leur dépendance de la continuité du « réseau des réseaux » et d’envisager des
solutions de continuité alternatives pour leurs processus les plus critiques, dans la mesure du
possible bien entendu.

3.2.4 Origine naturelle


Cette catégorie regroupe tous les sinistres comme les incendies, dégâts des eaux, explosions,
catastrophes naturelles, etc. Certains de ces risques ne peuvent être raisonnablement pris en
compte, d'autres peuvent être prévenus ou combattus (ex incendie), l'informatique n'étant
alors qu'un des aspects du problème. Enfin, des mesures simples permettent de limiter les
conséquences de certains accidents (ex si la salle informatique est située au premier étage, on
évitera la perte du matériel en cas d'inondation, même si celle-ci ne peut être combattue).

3.3 Démarche de gestion des risques selon ISO 27005


Le cadre méthodologique de gestion des risques qui sera présentée dans notre document est
conforme à la norme internationale ISO 27005. L’ISO/IEC 27005 : 2011 fournit des
directives pour la gestion du risque en sécurité de l'information. Ce cadre méthodologique,
soutient les concepts généraux indiqués dans ISO/IEC 27001, il est conçu pour aider à une
mise en œuvre satisfaisante de sécurité de l'information, basée sur une approche de gestion du
risque et orientée « Processus ». La connaissance des concepts, des modèles, des Processus et
des terminologies décrites dans ISO/IEC 27001 et ISO/IEC 27002 est importante pour une
compréhension complète de l'ISO/IEC 27005 : 2011.
Telles que spécifiées dans la norme internationale ISO 27005 : 2011, la figure ci-dessous
décrit les principales activités du processus de gestion du risque.

44
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 10: Processus de gestion de risque selon ISO 27005

45
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Les sous-étapes des différentes activités présentées sur la précédente figure sont les
suivantes :

Figure 11: Approche d’appréciation et de traitement des risques

Le processus de gestion des risques en sécurité de l'information peut être itératif pour les
activités d'appréciation et/ou de traitement des risques. Une approche itérative de conduite de
l'appréciation des risques permet d'approfondir et de préciser l'appréciation à chaque itération.
Cette approche itérative assure un bon équilibre entre la minimisation du temps et des efforts
investis dans l'identification des mesures de sécurité et l'assurance que les risques élevés sont
correctement appréciés.
Le processus de gestion du risque en sécurité de l’information peut être itératif pour les
activités d’appréciation et/ou de traitement du risque. Des itérations sont possibles si :
 L’appréciation des risques n’est pas satisfaisante, la cartographie des risques comporte
des lacunes, des erreurs ou n’est pas suffisamment exhaustive ;
 Les décisions et/ou les actions de traitement de risques identifiées dans le plan
d’action ne sont pas compatibles, sont inadéquates ou les risques résiduels identifiés
ne sont pas validés.

46
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.3.1 Établissement de contexte

L’objectif de cette étape est de cadrer l’étude de l’appréciation des risques à travers plusieurs
éléments dont la vérification du périmètre, des parties intervenantes au niveau de l’étude et la
validation des critères et seuils liés à l’étude.
Lors de cette étape, les résultats attendus sont le domaine d’application, les équipes et
ressources opérationnelles et les critères de l’étude.

Gouvernance SMSI

1.1

Description du contexte
général

1.2
Types de sources et Identification des
menaces (générique)
sources de menaces

1.3

Définition des échelles

1.4 5.1

Définition des critères Critères et échelles de Communication des


risques approuvés
de gestion du risque critères et des échelles

Appréciation du
risque

Figure 12: Établissement du contexte

L’étape de détermination des critères d’évaluation consiste à déterminer les critères de base
nécessaires, pour l’appréciation des risques, et appelle à prendre en considération :
 La valeur stratégique des activités du Processus informationnel métier,
 Le niveau de classification de l’actif informationnel impacté,
 La criticité des actifs en support concernés par ces activités,
 L’importance opérationnelle et métier de la Disponibilité, de la Confidentialité et de
l’Intégrité des informations.

47
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Le tableau ci-dessous présente des critères de valorisation & classification des actifs
informationnels

Niveau Vale Critères de Valorisation et classification


de ur Disponibilité Intégrité
Criticité Confidentialité

INTERRUPTION <= HAUTE


4H CERTIFICATION PROTECTION
Les informations doivent Les Informations sont Le secret
Très
(4) être accessibles en certifiées intègres pendant professionnel est
Critique
permanence et utilisables toute leur durée de vie ou renforcé pendant toute
par tous les services période de validité la durée de vie ou
concernés période de validité
SECRET
JUSTIFICATION
PROFESIONNEL
INTERRUPTION <= 1 L’Information doit rester
Les Informations sont
J intègre durant la période
protégées par le secret
Critique (3) Les informations doivent d’utilisation
professionnel et par la
toujours être fournies pour Toute perte en dehors de
législation sur les
Actifs remplir le service attendu cette période doit être
données à caractère
signalée et corrigée
personnel
INTERRUPTION <=2 à
RESTREINT
3J
SIGNALEMENT/CORR Les informations sont
Une indisponibilité
ECTION diffusées ou
Moyenne (2) momentanée est tolérée,
Toute perte d’Intégrité doit accessibles par des
mais doit être signalée et
être signalée et corrigée populations identifiées
sans conséquence sur le
et contrôlables
service fourni
INTERRUPTION >= 3 PUBLIC
SIGNALEMENT
J Les Informations
Faible (1) Toute perte d’Intégrité doit
Une indisponibilité peuvent être lues par
être signalée
temporaire est acceptable tous.

Le présent tableau est une échelle de valorisation de la vraisemblance, qui est la probabilité
que la cause d’un impact se produise. Si l’évènement est très probable, alors le niveau du
risque va être plus élevé. Le niveau de probabilité devrait se baser sur l’historique des impacts
ou à partir des statistiques disponibles. Ce facteur est essentiel pour la poursuite de l’analyse
du risque car il permet de déterminer l’occurrence du risque.

Valeu Description Description Durée

48
Étude et mise en place d’une application d’audit automatique de sécurité des SI

r
Très peu probable Très peu probable 1 fois tous les 5 ans
1
et plus
Peu probable Peu probable 1 à 2 fois tous les 2
2
ans
Probable Probable 2 mois > 1 fois > 6
3
mois
Très probable Très probable > 1 fois tous les deux
4
mois

3.3.2 Appréciation du risque


L’objectif de cette étape est d’identifier et inscrire les propriétaires d'actifs, les menaces, les
contrôles existants, les vulnérabilités ainsi que leurs conséquences. Une évaluation des
conséquences des incidents et de leur probabilité d’occurrence est effectuée dans cette étape et
permettra l'identification des niveaux de risque.

3.3.2.1 Identification du risque


Identification des actifs
- Actifs primaires et actifs support : Ce sont les actifs primaires (processus et activités
métier, informations) qui sont les plus importants à prendre en considération dans
l’analyse de risque.
L’annexe B.1 de la norme ISO 27005 donne des exemples d’identification des actifs.
Actifs support : matériels, logiciels, réseau, personnel, sites, structure de l’organisme.
- Une échelle granulaire établit une valeur de l’actif telle que :
1 : Négligeable
2 : Faible
3 : Moyen
4 : Élevé
5 : Très élevé
Identification des contrôles de sécurité
Cette phase doit considérer les mesures de contrôle existantes ou prévues (mise en œuvre
projetée). Les contrôles de sécurité de la norme ISO 27002 (ou Annexe A de la norme ISO
27001) peuvent servir de référence.
Si une mesure de contrôle de sécurité n’est pas efficace ou ne fonctionne pas comme prévu,
elle peut elle-même constituer une vulnérabilité.
Identification des vulnérabilités
Les vulnérabilités peuvent :
 Être intrinsèques à l’actif ;
 Être extrinsèques à l’actif ;
 Naitre de la défaillance de la mesure de sécurité censée protéger l’actif.
Identification des impacts (conséquences)
Identifier les impacts des scénarios d’incident en termes de temps perdu, opportunités
perdues, de réputation, d’image, financier, etc.
49
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Les impacts pleuvent être également définis en fonction des critères de sécurité
DICP (Disponibilité, Intégrité, Confidentialité et Preuve).

Figure 13: Exemples vulnérabilités/menaces

3.3.2.2 Analyse du risque


L’analyse du risque considère les causes et les sources de risque, leurs impacts positifs et
négatifs et la probabilité que ces impacts puissent survenir. Les facteurs qui affectent les
impacts et leur probabilité doivent également être pris en charge.
Le risque est fonction des impacts, de la probabilité et des autres attributs du risque, ainsi que
les mesures existantes (efficacité et efficience)
La combinaison des valeurs de la probabilité et des impacts dans la détermination du niveau
de risque est souvent fonction du contexte et de l’environnement.

50
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 14: Exemple d’estimation de la probabilité d’occurrence

Figure 15: Exemple de matrice d’estimation du risque

51
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 16: Exemple d’estimation de l’impact (cotation)

3.3.2.3 Évaluation du risque

L’évaluation doit permettre d’identifier, de quantifier et de prioriser les risques en fonction


des critères d’acceptation. Identifier les menaces, vulnérabilités, probabilité d’occurrence,
impacts de chaque risque associé aux actifs.

Figure 17: Exemple d’estimation du risque

52
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.3.3 Traitement du risque


Le traitement du risque implique de choisir une ou plusieurs options de mesures de sécurité
(réduire, maintenir, éviter ou transférer les risques) pour modifier les risques, et de définir un
plan de traitement du risque.
Ces options sont choisies sur la base du résultat de l’appréciation du risque, du coût prévu de
leur mise en œuvre et de leurs avantages attendus.
Ces 4 options ne s’excluent pas mutuellement.
Exemple : combinaison d’options telles que la réduction de la vraisemblance des risques et de
leurs conséquences et le transfert ou la conservation de tout risque résiduel.

Activité de traitement du Risque Description des Options de


Traitement
 Réduction du risque :
L’organisation décide
d’implémenter des mesures ou de
Appréciation du
risque prendre les moyens nécessaires
pour réduire le risque à un niveau
3.1 acceptable.
Choix des options de
traitement du risque
 Conservation du risque :
3.2
L’organisation accepte le risque
Détermination des calculé et est prête à assumer les
mesures de sécurité conséquences en toute
connaissance de cause.

3.3 3.4

Analyse des risques Elaboration du plan de  Évitement du risque : Le fait de ne


résiduels traitement pas considérer le risque n’est
jamais une bonne solution.
Toutefois, il est parfois possible
Rapport d͛appréciation Plan de traitement du
du risque risque d’éviter le risque en déplaçant
certains actifs de la zone de risque
ou en cessant carrément l’activité
5.3
Communication du plan de d’affaires qui crée des failles de
traitement et des risques sécurité.
résiduels

 Transfert du risque :
Acceptation du l’organisation décide de transférer
risque
le risque, par exemple par le biais
d’une assurance ou via une tierce
partie (fournisseur, sous-traitant).

Figure 18: Traitement du risque

53
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 19: Options de traitement de risque

Le plan de traitement du risque consiste à l’identification, à la planification et


l’implémentation d’activités classées en ordre de priorité, ainsi que l’allocation de ressources
nécessaires. Le focus doit être fait sur le plus grand risque même si d’autres aspects sont
importants pour l’organisation.

Figure 20: Plan de traitement

Évaluation du risque résiduel


Risque résiduel = Risque inhérent – Risque Traité
La valeur de réduction du risque suivant le traitement du risque devra être évaluée, calculée et
documentée afin de s’assurer du respect des critères d’acceptation. C’est pourquoi, il doit être
envisagé la mise en place d’un processus de surveillance et de pilotage des risques résiduels.
Si malgré la mise en place de contrôles, le risque demeure inacceptable, une décision
supplémentaire doit être prise sur la manière de traiter le risque. A ce titre, un ou plusieurs
choix complémentaires de traitement du risque sont à envisager, comme le partage du risque
(assurance ou externalisation) ou d’accepter le risque en connaissance de cause et en toute
objectivité.

54
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 21: Risques résiduels

3.3.4 Acceptation du risque


L’objectif de l’acceptation du risque est de prendre la décision d’accepter les risques et les
responsabilités de cette décision et l’enregistrer formellement.
Il est primordial que la Direction Générale et les propriétaires des risques révisent et
approuvent les plans de traitement du risque et les risques résiduels qui en découlent, ainsi
que la formalisation de tout le processus.
Il est également possible de réviser les critères d’acceptation au regard des retombées de
l’activité ou du coût élevé de maitrise du risque. Sinon les décideurs devront accepter les
risques et surtout les documenter, les justifier et les migrer dans les risques acceptables.
Les résultats attendus à cette étape concernent la liste des risques acceptés avec justification
de ceux qui ne répondent pas aux critères d'acceptation des risques de l'organisation,
validation de la Direction et déclaration d’Applicabilité

Figure 22: Acceptation du risque

55
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.4 Gestion des incidents de sécurité


3.4.1 Gestion de l’après sinistre
La gestion de l’après-sinistre consiste à mener une série d’actions :
- Investiguer l’incident (circonstances, technique utilisée, causes, auteur, dommages) ;
- Prendre les actions permettant à l’organisation de continuer à assumer ses fonctions
vitales dans les meilleurs délais après un sinistre (plan de survie) ;
- Éventuellement, déposer plainte auprès des autorités judiciaires.
- Conserver sous scellés les moyens de preuve et pièces à conviction. La collecte des
preuves est l’affaire de spécialistes, disposant des outils in-forensiques adéquats,
permettant de faire des copies « fidèles » des preuves qui pourront être exploitées de
manière incontestable en justice.
- Prendre les dispositions pour éviter la répétition de l’incident ;
- Mener une campagne d’information pour minimiser l’impact de l’incident sur l’image
de marque de l’entreprise ;
- Réparer l’éventuel dommage causé aux tiers.
Dans la pratique, les crises résultant d’atteintes aux systèmes d’information peuvent être
extrêmement complexes à gérer (ex. bug complexe inconnu). Plus le temps passe, plus
l’impact d’un incident, d’un problème ou d’une crise générale grandira. L’entreprise peut
tenter d’agir préventivement en réunissant, en cas de signes de crise probable, un comité de
gestion préventive de crise. C’est la démarche qui lui coûtera le moins cher car elle lui
donnera une chance d’éviter un sinistre.
Si les signes annonciateurs de crise ne sont pas perceptibles, il faut que le monitoring des
systèmes et de la sécurité soit suffisamment élaboré pour déceler un impact et déclencher les
alertes utiles qui permettront :
- De prendre des mesures conservatoires
- Au management de réunir un comité de crise
- D’instaurer des relais sur le terrain
- De procéder au diagnostic de, d’activer un plan de contournement et de gérer la crise
dans la durée, opérations de retour à la normale incluses.
La démarche concrète de gestion de crise proposée ci-après fait appel à huit processus ou
savoirs interactifs :
 Le savoir tactique et organisationnel (qui fait quoi quand ?) : c’est le rôle du chef de la
cellule de crise. Le pilotage et la coordination opérationnelle sont les clés les plus
critiques pour sortir de la crise. Le pilote doit garder la main sur toutes les actions à
décider.
 Le savoir schématique (qui est capable de schématiser le problème dans son
ensemble ?). Concrètement, il faut faire appel aux personnes compétentes, les réunir
autour de la table de crise, procéder « au tableau » à la schématisation fonctionnelle et
technique de la crise, identifier ce qui fonctionne et ce qui ne fonctionne plus, évaluer
les alternatives de contournement, établir le planning des tâches à réaliser sur la ligne
du temps, etc. Ce schéma va considérablement aider le pilote-tacticien et les équipes
d’intervention. C’est un outil indispensable trop souvent oublié pour définir les actions
de crise à entreprendre.
56
Étude et mise en place d’une application d’audit automatique de sécurité des SI

 Le savoir d’expérience : faire appel aux personnes expérimentées fait gagner un temps
considérable.
 Le savoir méthodologique (à tout niveau du processus de crise, appliquer la bonne
méthode pour ne pas se tromper de chemin et sortir plus sûrement de la crise). La
présente démarche en 8 points est déjà en soi une méthode et est inspirée de
l’expérience de praticiens de la gestion des risques informatiques, mais aussi de celle
provenant d’autres disciplines
 Le savoir procédural, qui suppose que les procédures essentielles de récupération de la
situation soient accessibles en cas de sinistre. Au cas où cela ne suffit pas et cela suffit
rarement dans la réalité, être prêt à activer : 6. un savoir dit de recherche d’information
(rechercher les pièces manquantes de la solution de réparation, de contournement, etc.)
Certains seront plus créatifs que d’autres pour trouver l’information nécessaire.
 Un savoir heuristique : dans certains cas, la sortie d’une crise peut requérir un
ensemble d’opérations itératives du type « essais et erreurs ».
 Un savoir de gestion d’exception : sortir de l’impasse d’un système complètement
bloqué peut parfois être fait en s’écartant des standards, règles et procédures, en
sacrifiant temporairement un flux dans un processus, etc.
Le rôle du chef de la cellule de crise (le « pilote ») sera donc d’arbitrer et d’activer
tactiquement avec le plus grand discernement l’enchaînement de ces 8 savoirs.
Ces 8 savoirs sont autant de solutions possibles. Au plus leur combinaison est judicieuse, au
plus vite l’entreprise sortira de la crise.

3.4.2 Communication de crise


Pour qu’un incident endommage l’image de marque de l’organisation, il faut que d’une part,
cet événement soit connu à l’extérieur et que d’autre part, cette information induise des
réactions négatives auprès de ceux qui en prennent connaissance.
Tout dépendra donc de la manière dont l’entreprise informera son propre personnel, ses
actionnaires, les autorités, les médias, les clients, les concurrents. La manière, éventuellement
tendancieuse, dont la presse informera le public ainsi que les confidences de « gens bien
informés » peuvent représenter un risque considérable.
Un plan d’information des médias doit être disponible pour réagir, sans délai, si besoin en est,
face à n’importe quel incident, permettant ainsi de contrôler les effets négatifs potentiels sur
l’image de marque de l’organisation.
La preuve a été faite qu’un incident, a priori néfaste, pouvait être exploité et transformé en
élément positif de publicité. C’est ainsi qu’un incendie détruisant complètement un centre de
calcul d’un grand constructeur d’ordinateurs, fut mis à profit pour éditer une brochure
illustrée sur les causes, le déroulement et les conséquences du sinistre, ainsi que sur des
recommandations à usage des responsables de centres de calcul.
La communication de crise est un métier à part. Il est recommandé de faire appel à des
agences spécialisées et des professionnels du domaine.

57
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.4.3 Suivi des incidents


Tous les incidents informatiques doivent être signalés immédiatement, certains demandant
une réaction immédiate. Les incidents relevés doivent faire l'objet d'une analyse ; le cas
échéant, par un groupe de personnes désignées à cet effet, encore appelé CSIRT (Computer
Security Incident Response Team).
Un rapport périodique doit être adressé à la direction générale, reprenant non seulement les
aspects statistiques, mais aussi les recommandations nécessaires. Pour se conformer à
certaines politiques en la matière, ces rapports d'incidents doivent être globalisés en
interentreprises (CISRT sectoriels ou nationaux, souvent appelés CERT : Computer
Emergency Response Team) pour qu'ensuite la globalisation nationale puisse contribuer
valablement à une surveillance globale

3.5 Méthodologie de gestion des risques pour les DSI


3.5.1 Percevoir le risque du point de vue global
Du fait de l’omniprésence de l’informatique dans la plupart des activités des entreprises, il va
sans dire que les risques auxquels s’expose une organisation découlent de ceux liés à
l’informatique et à l’infrastructure physique associée. Les hauts dirigeants des entreprises sont
de plus en plus conscients de la nécessité d’une meilleure gestion du risque informatique.
Il n’en reste pas moins qu’aborder la gestion du risque informatique sous l’angle des silos
d’informations rend plus difficile la moindre évolution réelle. Culturellement, les risques
informatiques sont répertoriés en catégories strictes et donc abordés, par exemple, en termes
de disponibilité des systèmes, de sécurité des accès et de plan de reprise d’activité. Cette
vision analytique élude les relations d’interdépendance, ce qui peut provoquer un défaut
d’appréciation du risque global auquel une activité ou un processus métier peut être exposé.
L’importance de cet aspect va bien au-delà des enjeux de protection. Il a un impact important
sur la croissance de l’entreprise.
Une entreprise se doit donc de disposer d’une vue globale et unifiée de l’ensemble des risques
auxquels elle doit faire face, sans exception.
Lorsqu’ils sont capables d’envisager le risque globalement, les responsables informatiques
sont mieux à même de percevoir le lien avec les activités métier. Disposant ainsi d’un point
d’observation omnidirectionnel, ils sont dans une position idéale pour maîtriser l’ensemble
des menaces potentielles qui pèsent sur l’activité. Ils savent dans ce cas réagir à ces menaces
(catastrophes naturelles, actes malveillants, accidents et désordre opérationnel), tout en
percevant simultanément l’ensemble des conséquences éventuelles pour les actifs et les
ressources de l’entreprise (personnel, informations, matériels, logiciels et installations
physiques).

3.5.2 Remettre à plat l’ensemble de la gestion du risque informatique


Manifestement, les Directeurs des Systèmes d’Information sont appelés à adopter une
approche élargie et orientée métier de la gestion du risque informatique. Au final, il s’agit

58
Étude et mise en place d’une application d’audit automatique de sécurité des SI

bien d’un élément essentiel de la mise en cohérence stratégique de la fonction Informatique et


de l’entreprise.
Une approche orientée métier considère les défis relatifs à la gestion du risque informatique
sous l’angle des processus métier. Il s’agit, dans ce cadre, d’identifier les risques en corrélant
les processus de l’entreprise et les risques potentiels liés à l’informatique. L’analyse des
dépendances permet ainsi d’identifier les modalités d’interaction entre les activités métier et
des éléments spécifiques de l’informatique et de l’infrastructure de l’entreprise. En structurant
ensuite les activités informatiques en différentes couches, il est plus facile de revenir aux
causes sous-jacentes relevant de l’informatique. Une des approches consiste à évaluer les
risques informatiques en termes de processus métier et de résultats. Les résultats métier et
leurs risques associés sont identifiés pour chaque processus informatique.
Les risques envisageables dans ce contexte portent sur les durées d’arrêt des systèmes, les
pertes d’informations, les retards de traitements système et les capacités insuffisantes des
ressources.

3.5.3 Créer un cadre structuré de gouvernance


Sans un cadre robuste de gouvernance, il n’y a pas de gestion du risque satisfaisante. Ce cadre
permet de mettre en place les politiques, les contrôles et les règles opérationnelles qui
permettent aux responsables informatiques de gérer les risques et de pondérer leur valeur pour
l’entreprise. Toutefois, pour être efficace à long terme, un cadre de gouvernance doit
s’adapter au contexte évolutif dans lequel opère une entreprise. Des principes de gouvernance
extrêmement sophistiqués existent déjà. Les DSI pourront donc tirer un profit immédiat des
règles et « meilleures pratiques » déjà proposées en matière de gestion du risque
informationnel.
L’ITGI (IT Governance Institute), COBIT (Control Objectives for Information and related
Technology), Val IT de l’ITGI, PRM-IT (Process Reference Model for IT), CBM-BoIT
(Component Business Model for the Business of IT) et Resilient Enterprise Blueprint.
Même si les normes et les démarches mises en avant par chacune de ces méthodologies
diffèrent par leur terminologie, les recommandations qu’elles proposent en matière de gestion
du risque informatique convergent :
 Définir le périmètre de l’analyse du risque. Il s’agit d’identifier les activités métier, les
initiatives et les éléments technologiques et d’infrastructure de l’entreprise qui doivent
être pris en compte dans la démarche de gestion du risque informatique
 Cibler et définir les risques. La démarche consiste à associer chacune des activités
métier à des menaces possibles et à des ressources exposées à des risques.
 Estimer la probabilité de la réalisation d’un risque et son niveau d’impact. Il s’agit de
calculer la probabilité et la gravité d’une atteinte aux activités métier, pour disposer,
au final, d’une vision globale des risques encourus.
 Évaluer les mesures de contrôle. Il s’agit ici de mesurer la qualité des procédures de
contrôle déjà en place pour prévenir, identifier et limiter les risques, en prenant en
compte les coûts par rapport à la valeur créée.
 Apprécier le risque et élaborer les actions et les réponses correspondantes. L’approche
consiste à analyser les risques par rapport à la volonté de l’entreprise, établir les

59
Étude et mise en place d’une application d’audit automatique de sécurité des SI

actions prioritaires de réduction du risque et décider des investissements en fonction


d’une analyse coûts/bénéfices.
 Mettre en œuvre des actions visant à réduire les risques. Cette étape consiste à
développer, tester et mettre en place des plans détaillés de réponse aux risques.
 Assurer un contrôle et un retour d’informations permanents. Il s’agit ici d’assurer la
collecte permanente d’informations concernant les menaces affectant la démarche de
gestion du risque, son impact et son efficacité, puis d’adapter les plans d’action et les
processus de gestion du risque en fonction de ces informations.
 Des processus structurés de ce type favorisent la réactivité des entreprises et leurs
capacités à anticiper sur les menaces, à les analyser et à y répondre. L’obstacle de la
complexité organisationnelle peut toutefois tempérer leur mise en œuvre. La gestion
du risque entre de plus en plus dans les attributions des directeurs des systèmes
d’information. En outre, la plupart de ces menaces appartiennent au périmètre de
contrôle de l’informatique et les DSI sont naturellement appelés à jouer un rôle de
premier plan dans la mise en place de ces processus, en s’engageant dans des actions
consistant à :
 Affecter les financements et les ressources nécessaires aux démarches
d’analyse du risque ;
 Proposer des orientations destinées à favoriser le dialogue entre les différents
intervenants concernés et s’assurer en permanence de la cohérence entre les
objectifs métiers et la conformité avec les politiques de gouvernance de
l’entreprise
 Promouvoir l’amélioration constante des processus.
 Mettre l’accent sur l’intégration accrue de la notion de risque dans la
gouvernance globale de l’entreprise.
 Élaborer des politiques de gestion du risque destinées à accompagner les
activités de l’entreprise.

3.5.4 Le rôle du personnel, de l’organisation et de l’automatisation


À l’évidence, la direction d’une entreprise ne peut que se montrer très favorable à des
programmes de gestion du risque informatique capables de mettre en évidence des menaces
potentielles pour ses activités, tout en proposant des réponses plus souples et moins coûteuses
à ces risques. Les DSI ont ici une opportunité exceptionnelle de réaliser ces objectifs en levant
les obstacles liés au personnel, à l’organisation et à l’automatisation

3.5.5 Optimiser le rapport risques/bénéfices 


Compte tenu du rôle toujours plus stratégique des DSI au sein du comité de direction, les
attentes en matière de gestion du risque informatique sont plus élevées que jamais. Les
directeurs des systèmes d’information se doivent de maîtriser le coût réel des risques
informatiques, ce qui signifie qu’ils doivent connaître parfaitement l’impact de leurs décisions
sur le chiffre d’affaires, la fidélisation des clients et la compétitivité. Dans un monde orienté
sur la création de valeur, la gestion informatique doit se concentrer sur la réalisation du

60
Étude et mise en place d’une application d’audit automatique de sécurité des SI

meilleur résultat en limitant au maximum les risques. C’est ici qu’intervient la notion de
budgétisation du risque.

61
Étude et mise en place d’une application d’audit automatique de sécurité des SI

CHAPITRE 4 : ETUDE, CONCEPTION ET


REALISATION DE L’APPLICATION

62
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Pour bien définir, clarifier les grandes fonctionnalités de notre application, nous allons aborder la
phase d’étude de spécification avant de commencer à coder la partie applicative

Ce chapitre consiste à donner une définition précise des besoins fonctionnels et non fonctionnels ainsi
que les objectifs visés.

4.1 Étude et spécification des besoins du système


L’analyse de la thématique et des différentes problématiques posées par les moyens existants a permis
de dégager les fonctionnalités qu’offre notre application finale. Les contraintes auxquelles est soumis
le système pour sa réalisation et son bon fonctionnement seront décrites par la suite comme étant
besoins non fonctionnels.

4.1.1 Identification des acteurs


 Administrateur :

C'est la personne qui peut manipuler toutes les taches proposées et possibles dans notre application tels
que : la gestion des domaines, des clients, des questions et des opérations.

 Client :

Son rôle principal s’accumule dans la partie consultation de différentes fonctionnalités de


l’application, aussi dans les réponses aux questions qui aboutiront à une génération de rapport d’audit.

4.1.2 Besoins fonctionnels 


 La première étape consiste à introduire les secteurs d’activités,
 Introduire le questionnaire qui contient les différentes opérations de l’audit sécurité,
 Affecter les pondérations relatives à chaque question,
 Implémenter une liste de réponses à proposer pour chaque question qui doit couvrir toutes les
possibilités,
 Pouvoir imprimer les rapports des missions d’audits effectués,
 Un calcul doit être effectué après l’attribution des recommandations qui doivent répondre aux
niveaux de maturité cible défini par le client,
 Création d’une base de connaissance des scenarios et des recommandations.

4.1.3 Besoins non fonctionnels


Après avoir déterminé les besoins fonctionnels, nous citons ci-dessous l’ensemble des contraintes à
respecter pour garantir la performance du notre système.

 La fiabilité

Les informations apportées par l’application doivent être fiables et sûres.

 La simplicité

63
Étude et mise en place d’une application d’audit automatique de sécurité des SI

L’application peut être utilisée d’une manière facile et claire.

 L’ergonomie de l’interface

Les interfaces doivent être simples et conviviales.

 La modularité de l’application

Avoir un code simple facile à maintenir et à comprendre en cas de maintenance ou d’amélioration

 La sécurité

L’application comporte des informations sensibles par rapport à ses clients, donc elle doit respecter les
règles relatives à la sécurité des systèmes informatiques.

4.2 Conception
L’activité de la conception est indispensable afin de faciliter la compréhension de notre système, qui
ébauche vers l’activité de réalisation et d’implémentation.

Nous allons présenter dans cette partie les digrammes de classe et de cas d’utilisation qui expriment à
leur tour de manière générale la structure de notre système, en termes de classe, de cas d’utilisation et
de relations entre elles.

64
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Diagramme de classe

Le diagramme de classe est une description statique du système focalisé sur le concept de classe et
d’association.

Une classe représente un ensemble d’objets qui possèdent des propriétés similaires et des
comportements communs décrivant en terme d‘attributs et d’opérations.

Une association consiste à présenter les liens entre les instances de classe. Les principales classes de
notre application sont :

 Classe Domaine activité : c’est la classe qui contient les différents secteurs d’intervention.
 Classe Opération : c’est la classe qui contient toutes les opérations les plus critiques pour
chaque secteur d’activité.
 Classe Client : c’est la classe qui contient la base de données de chaque client
 Classe Utilisateur : c’est la classe mère dont héritent Client et Administrateur
 Classe Administrateur : c’est la classe qui contient la base de données de l’administrateur
 Classe Questionnaire : c’est la classe qui contient les questions et leurs réponses proposées
aux clients
 Classe Question : c’est la classe qui contient la question
 Classe Activité : c’est la classe qui contient les activités des clients
 Classe Rapport : c’est la classe qui contient les informations du rapport (maturité,
performants, perfectibles, recommandations)

Figure 23: Diagramme de classe

65
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Diagramme de cas d’utilisation


Un acteur est l'idéalisation d'un rôle joué par une personne externe, un processus ou une chose
qui interagit avec l’application. Il se représente par un petit bonhomme avec son nom inscrit
dessous.
Un cas d’utilisation est un service rendu à un acteur. C’est une fonctionnalité de son point de
vue. Un cas d'utilisation se représente par une ellipse contenant le nom du cas, et
optionnellement, au-dessus du nom, un stéréotype.
Dans le tableau suivant nous avons la description fonctionnelle de tous les cas d’utilisation de
notre diagramme.

Acteurs Description Fonctionnelle


Choisir domaine : Le client a la possibilité de choisir le domaine
dans lequel exerce son entreprise
seConnecter : Le client peut se connecter en utilisant ses
identifiants
seDeconnecter : le client peut, une fois connecté, se déconnecter
repondreQuestion : un ensemble de questions sera posé et le client
sera inviter à y répondre à travers une liste de choix déjà existante.
genererRapport : une fois toutes les questions répondues, le client
peut générer son rapport d’audit qui contient une évaluation du
niveau de maturité du système, les performants, les perfectibles du
système et des recommandations pour améliorer le niveau de
sécurité du système.

CRUD=create, read, update, delete


seConnecter : Tout comme le client, l’administrateur peut se
connecter en utilisant ses identifiants
seDeconnecter : L’administrateur peut, une fois connecté, se
déconnecter
CRUDdomaine : L’administrateur peut créer, modifier, mettre à
jour ou encore supprimer un domaine
CRUDoperation : L’administrateur peut créer, modifier, mettre à
jour ou encore supprimer une opération
CRUDclient : L’administrateur peut créer, modifier, mettre à jour
ou encore supprimer un client
CRUDquestion : L’administrateur peut créer, modifier, mettre à
jour ou encore supprimer une question
voirActiviteClient : L’administrateur a le contrôle total de tout ce
qui se passe dans l’application. Il peut voir toutes les activités
qu’effectuent les clients.

66
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 24: Diagramme de cas d’utilisation

4.3 Réalisation de l’application


4.3.1 Environnement de travail
4.3.1.1 Environnement matériel
Pour développer notre application, nous avons utilisé un ordinateur MacBook Pro (Retina, 13-inch,
Early 2015) avec un processeur 2.7 GHz Intel Core i5 double cœur, une mémoire 8 Go 1867 MHz
DDR3.

4.3.1.2 Environnement logiciel

67
Étude et mise en place d’une application d’audit automatique de sécurité des SI

 NetBeans
NetBeans est un environnement de développement intégré (EDI), placé en open source par Sun en juin
2000 sous licence CDDL (Common Development and Distribution License) et GPLv2. En plus de
Java, NetBeans permet la prise en charge native de divers langages tels le C, le C++, le JavaScript, le
XML, le Groovy, le PHP et le HTML, ou d'autres (dont Python et Ruby) par l'ajout de greffons. Il
offre toutes les facilités d'un IDE moderne (éditeur avec coloration syntaxique, projets multi-langage,
refactoring, éditeur graphique d'interfaces et de pages Web).
Compilé en Java, NetBeans est disponible sous Windows, Linux, Solaris (sur x86 et SPARC), Mac OS
X ou sous une version indépendante des systèmes d'exploitation (requérant une machine virtuelle
Java). Un environnement Java Development Kit JDK est requis pour les développements en Java.
NetBeans constitue par ailleurs une plateforme qui permet le développement d'applications spécifiques
(bibliothèque Swing (Java)). L'IDE NetBeans s'appuie sur cette plate-forme.
Dans notre cas, nous avons développé notre application en Java avec le SGBD MySQL.

4.3.2 Les interfaces de l’application


La figure suivante présente l’interface Authentification de l’application. Cette interface est
décomposée en deux champs pour la saisie du nom d’utilisateur (Login) et du mot de passe (Mot de
passe). Ces informations permettront au client et a l’administrateur l’accéder à l’application.

Figure 25: Authentification

68
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La figure suivante présente l’interface de gestion de l’administrateur. Cette interface est accessible par
l’administrateur seul. Il est le seul à avoir tous les droits d’ajout, de modification et de suppression de
tout type de données, que ce soit le CRUD sur Client, domaines, Operations et Questionnaire.

Figure 26: Panel Administrateur

69
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La figure suivante présente l’interface d’ajout de client. Cette interface n’est aussi accessible que par
l’administrateur seulement.

Figure 27: Ajout Client

La figure suivante présente la liste des clients enregistrée. Cette interface n’est aussi accessible que par
l’administrateur seulement.

Figure 28: Liste client

70
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La figure suivante présente l’interface d’ajout de domaine, cette interface est accessible par
l’administrateur seul. Il est le seul à avoir tous les droits d’ajout, de modification et de suppression de
tout type de données.

Figure 29: Ajout de domaine d’activité

La figure suivante présente la liste des domaines d’activité ajoutés. Cette interface n’est aussi
accessible que par l’administrateur seulement.

Figure 30: Liste des domaines d’activité

71
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La figure suivante présente l’interface d’ajout d’opération. Cette interface est accessible par
l’administrateur seul. Il est le seul à avoir tous les droits d’ajout, de modification et de suppression de
tout type de données.

Figure 31: Interface Ajout d’opération

La figure suivante présente la liste des opérations ajoutées. Cette interface n’est aussi accessible que
par l’administrateur seulement.

Figure 32: Liste des opérations

La figure suivante présente l’interface d’ajout de question. Cette interface est accessible par
l’administrateur seul. Il est le seul à avoir tous les droits d’ajout, de modification et de suppression de
tout type de données.

72
Étude et mise en place d’une application d’audit automatique de sécurité des SI

Figure 33: Ajout de question

La figure suivante représente l’interface de connexion de l’utilisateur et celle du choix du secteur


d’activité et le nom de l’entreprise.

Figure 34: Interface de connexion et secteur d’activité

73
Étude et mise en place d’une application d’audit automatique de sécurité des SI

La figure suivante représente l’interface de réponses aux questions d’audit qui seront posées au client
pour évaluer le niveau de maturité du système. En plus faire ressortir les performants, les perfectibles
du système et proposer enfin des recommandations d’amélioration du niveau de sécurité.

Figure 35: Interface réponses aux questions

A la fin des réponses aux questions, le client peut générer le rapport d’audit en cliquant juste
sur le bouton Rapport, le rapport est imprimé au format PDF.

4.4 Benchmarking
Dans cette partie de notre document, nous ferons une présentation de quelques outils existants
proposant l’audit automatique, se rapprochant de notre solution.

4.4.1 Netwrix Auditor


Netwrix Auditor vous permet de contrôler tout ce qu'il se passe dans votre environnement
informatique hybride. En fournissant des informations exploitables sur les modifications,
l'accès et les configurations, Netwrix Auditor vous permet de minimiser les risques
informatiques, de détecter les menaces de manière proactive, de réduire le temps consacré à
l'audit des modifications et à la configuration des bases de données, de résoudre les problèmes
des utilisateurs plus efficacement et de vous libérer plus rapidement des auditeurs

74
Étude et mise en place d’une application d’audit automatique de sécurité des SI

4.4.2 Gensuite
Le logiciel primé de gestion d'audit Gensuite simplifie les processus d'inspection d'audit de
conformité réglementaire grâce à une approche collaborative numérique. Répondez aux
exigences réglementaires, de certification et de programme à l'aide d'une suite d'outils d'audit,
d'inspection et de suivi des mesures correctives avec des informations intégrées sur les
tendances. Offrant des fonctionnalités mobiles ainsi qu'une collaboration facile entre
collègues, Gensuite simplifie la création de processus d'audit efficaces.

4.4.3 StandardFusion
StandardFusion est une plateforme GRC cloud conçue pour rendre vos audits internes de
sécurité des informations (ISO 27001, SOC2, PCIDSS, FedRAMP, etc.) simples et
accessibles. StandardFusion est une application web moderne conçue pour aider les
entreprises à gérer les risques opérationnels, garantir leur conformité aux normes et suivre les
meilleures pratiques rapidement et facilement.

4.4.4 TeamMate + Audit


TeamMate Audit est un système de gestion d'audit complet conçu pour aider les auditeurs et
les responsables du département d'audit à gérer tous les aspects du processus d'audit.
TeamMate permet à votre institution d'identifier les risques et de créer des rapports
d'évaluation, de planifier des projets et d'allouer des ressources, de capturer le temps et les
dépenses, de suivre les audits et les problèmes, de créer et de gérer les audits via une base de
données électronique avancée.

4.4.5 Safesite
Plateforme de gestion de la sécurité mobile (web et application) permettant aux utilisateurs
d'enregistrer, de communiquer et de résoudre les problèmes sur le terrain en temps réel.

4.4.6 Particularité de notre solution


Il existe plusieurs outils proposant la simplification de la tâche d’audit. Notre solution diffère
de celles-ci de par ses fonctionnalités (audit automatique de la sécurité, appréciations du
niveau de maturité du système, génération de rapport d’audit) et de ses perspectives
d’amélioration.

75
Étude et mise en place d’une application d’audit automatique de sécurité des SI

CONCLUSION

Notre projet intitulé « Étude et mise en place d’une application d’audit automatique de la
sécurité des systèmes d’information » consiste à la conception et la réalisation d’une
application qui permet de réaliser la tâche d’audit organisationnel, physique et technique.
Au terme de ce projet de fin d’études, nous tenons à souligner que sa réalisation était d’un très
grand bénéfique pour nous car cela a été une bonne occasion pour nous de consolider nos
connaissances théoriques dans le domaine de l’audit et la gestion de risques.
Le mémoire mentionne toutes les étapes traversées pour arriver au résultat attendu. Il a fallu
dans un premier temps recenser les différents besoins existants, nous avons identifié les
différentes exigences du futur afin de les prendre en compte.
Il est évidement assumé que ce projet n’est pas une œuvre parfaite en raison des circonstances
exceptionnelles liées à la pandémie de covid-19 qui a obligé la fermeture des lieux de travail
et des entreprises suite à la propagation de la pandémie, et bien que nous fumes invités de
réaliser le projet en télétravail, cela nous a empêché de participer à des missions d’audit avec
4itsec-africa mais cependant nous avons participé à des missions spéciales d’audit des
systèmes d’information, de rédaction de politique de sécurité et de charte informatique avec
KHLIL IT.
Cette application pourrait être améliorée et enrichie par l’ajout de plus de secteurs d’activités
existant sur le marché comme le secteur hospitalier, logistique/transport, services aux
entreprises et agroalimentaire. Aussi nous projetons l’étendre en intégrant le test intrusif dans
l’application ainsi que d’autre secteur des systèmes d’information. Enfin nous prévoyons
rendre l’application intelligente en intégrant le Machine Learning.

76
Étude et mise en place d’une application d’audit automatique de sécurité des SI

BIBLIOGRAPHIE

[B1] BLOCH Laurent (2016), « Sécurité informatique », Ed Eyrolles, pp 187, 189,


191,200, 201.

[B2] HALLÉPÉE Didier (2013), « Conduite et maîtrise de l'audit informatique », Les


écrivains de Fondcombe, pp 67,68,71.

[B3] THORIN Marc (2000), « L'audit informatique », Hermès – Lavoisier, pp


13,112,113, 167,181.

[B4] BILET Virginie, FELIDJ Christophe, LIOTTIER Miguel (2020), « Management


des systèmes d'information - DSCG 5 », Management des risques, Dunod, pp.223-247.

[B5] HIARD Vincent (2016), « Audit des sites web », Eni Editions, pp.178-187.

[B6] SALAUN Jean-Michel (1993), « Les sciences de l’information en question, le


point de vue du lecteur », Réseaux, mars-avril, n° 58.pp. 9-25.

A
Étude et mise en place d’une application d’audit automatique de sécurité des SI

WEBOGRAPHIE

[W1] Sécurité numérique, sur le site ANSSI (Agence nationale de la sécurité des
systèmes d’information). Consulté le 21 avril 2020 à 15h34.
https://www.ssi.gouv.fr/particulier/formations/secnumacademie/

[W2] Audit de cyber sécurité, sur le site de Connectalk. Consulté le 19 mai 2020 à
19h11.
https://www.connectalk.com/wp-content/uploads/Audit-de-cyberse%CC%81curite
%CC%81-E%CC%81tude-de-cas.pdf

[W3] Guide d’audit de sécurité des systèmes d’information, sur le site de Tresor.
Consulté le 31 aout 2020 à 16h17.
https://www.tresor.gouv.qc.ca/fileadmin/PDF/ressources_informationnelles/securite_i
nformation/audit_securite_information.pdf

[W4] Maitrisez l'un des référentiels IT les plus complets : Audit, performance,
maturité de tous les processus IT sur le site de Udemy. Consulté le 09 septembre 2020
à 20h18.

https://www.udemy.com/course/maitrisez-cobit-prise-en-mains-avancee/

B
Étude et mise en place d’une application d’audit automatique de sécurité des SI

TABLE DES MATIERES

DEDICACES............................................................................................................................II
REMERCIEMENTS..............................................................................................................III
GLOSSAIRE...........................................................................................................................IV
LISTE DES FIGURES............................................................................................................V
SOMMAIRE...........................................................................................................................VI
INTRODUCTION....................................................................................................................1
CHAPITRE 1 : CONTEXTE GENERAL..............................................................................2
1.1 PRÉ SENTATION DE 4ITSEC-AFRICA........................................................................................................................................... 3
1.1.1 Historique......................................................................................................................................................................... 3
1.1.2 Objectifs............................................................................................................................................................................ 3
1.2 PRÉ SENTATION DU SUJET........................................................................................................................................................... 3
1.2.1 Problématique................................................................................................................................................................ 3
1.2.2 Objectif général.............................................................................................................................................................. 4
1.2.3 Objectifs spécifiques.................................................................................................................................................... 4
1.2.4 Hypothèses...................................................................................................................................................................... 5
1.2.5 Importance de notre solution................................................................................................................................... 5
CHAPITRE 2 : ETAT DE L’ART..........................................................................................7
2.1 AUDIT DES SYSTÈ MES D’INFORMATION.................................................................................................................................... 8
2.1.1 Définition d’audit........................................................................................................................................................... 8
2.1.2 Rô le et objectifs de l’audit.......................................................................................................................................... 8
2.1.3 Cycle de vie d’un audit de la sécurité de l’information...................................................................................8
2.2 TYPES D’AUDIT DES SYSTÈ MES D’INFORMATION..................................................................................................................... 9
2.2.1 Audit organisationnel et physique......................................................................................................................... 9
2.2.2 Audit technique........................................................................................................................................................... 10
2.2.3 Relation entre l’audit et l’analyse du risque..................................................................................................... 10
2.2.3.1 Le rô le de l’audit interne dans la gestion des risques....................................................................................................10
2.2.3.2 Principaux rô les de l’audit interne..........................................................................................................................................11
2.2.3.3 Rô les légitimes de l’audit interne............................................................................................................................................11
2.3 MÉ THODES ET NORMES D’AUDIT DE SÉ CURITÉ DES SI........................................................................................................ 11
2.3.1 Définition des terminologies.................................................................................................................................. 11
2.3.1.1 ISO...........................................................................................................................................................................................................11
2.3.1.2 Méthode...............................................................................................................................................................................................12
2.3.1.3 Norme....................................................................................................................................................................................................12
2.3.1.4 Référentiel...........................................................................................................................................................................................13
2.3.2 Normes relatives à la sécurité des systèmes d’information......................................................................14
2.3.2.1 ISO/IEC 27001 : SMSI....................................................................................................................................................................14
2.3.2.2 ISO 27002 : Code de bonne pratique pour le SMSI..........................................................................................................15
2.3.2.3 ISO/IEC 27005 : Management des risques..........................................................................................................................16
2.4 MÉ THODES D’AUDIT DE SÉ CURITÉ DES SI............................................................................................................................. 19
2.4.1 Méthode EBIOS............................................................................................................................................................ 19
2.4.1.1Gestion des risques avec EBIOS.................................................................................................................................................19
2.4.1.2 Démarche EBIOS..............................................................................................................................................................................21
2.4.2 Méthode MEHARI....................................................................................................................................................... 23
2.4.2.1 L’analyse des enjeux.......................................................................................................................................................................25

B
Étude et mise en place d’une application d’audit automatique de sécurité des SI

2.4.2.2 É chelle de valeurs des dysfonctionnements.......................................................................................................................25


2.4.2.3 Classification des informations et des actifs......................................................................................................................26
2.4.2.4 Expression des enjeux de la sécurité.....................................................................................................................................26
2.4.2.5 Les diagnostics des services de sécurité..............................................................................................................................26
2.4.2.6 L’analyse systématique des situations de risques...........................................................................................................27
2.4.2.7 Le plan d’action en sécurité de l’information.....................................................................................................................27
2.4.2.8 Contrô le et pilotage de la gestion directe des risques...................................................................................................28
2.4.2.9 Contrô le du niveau de qualité des services retenus.......................................................................................................28
2.4.2.10 Contrô le de la mise en œuvre des services de sécurité..............................................................................................29
2.5 DÉ MARCHE STANDARD D'AUDIT............................................................................................................................................. 29
2.5.1 Préparation/initiation.............................................................................................................................................. 30
2.5.2 Exécution/Collecte..................................................................................................................................................... 30
2.5.3 Analyse............................................................................................................................................................................ 30
2.5.4 Restitution..................................................................................................................................................................... 30
2.5.5 Suivi................................................................................................................................................................................. 30
2.6 DÉ MARCHE DE RÉ ALISATION D’UN AUDIT DE SÉ CURITÉ ...................................................................................................... 30
2.6.1 Charte d’audit............................................................................................................................................................... 31
2.6.2 Préparation de l’audit............................................................................................................................................... 31
2.6.3 Audit organisationnel et physique....................................................................................................................... 31
2.6.3.1 Objectif..................................................................................................................................................................................................31
2.6.3.2 Déroulement......................................................................................................................................................................................32
2.6.4 Audit technique........................................................................................................................................................... 32
2.6.4.1 Objectif..................................................................................................................................................................................................32
2.6.4.2 Déroulement......................................................................................................................................................................................32
2.6.5 Test d’intrusion........................................................................................................................................................... 33
2.6.6 Rapport d’audit............................................................................................................................................................ 33
2.7 MOYENS DE COLLECTE............................................................................................................................................................. 34
2.7.1 Revue documentaire................................................................................................................................................. 34
2.7.2 Questionnaires............................................................................................................................................................. 34
2.7.3 Entretiens...................................................................................................................................................................... 34
2.7.4 Visites sur site.............................................................................................................................................................. 34
2.7.5 Tests techniques......................................................................................................................................................... 35
2.8 MÉ THODOLOGIE D’AUDIT......................................................................................................................................................... 35
2.9 UTILITÉ DES OUTILS D’AUTOMATISATION DES QUESTIONNAIRES D’AUDIT.......................................................................36
CHAPITRE 3 : GESTION DES RISQUES.........................................................................37
3.1 FONDAMENTAUX ET RÉ FÉ RENTIELS DE GESTION DES RISQUES.......................................................................................... 38
3.1.1 Fondamentaux de la gestion des risques.......................................................................................................... 38
3.1.2 Référentiels de gestion de risques....................................................................................................................... 38
3.1.2.1 ISO 31000............................................................................................................................................................................................39
3.1.2.2 ISO 27005............................................................................................................................................................................................40
3.2 LES ORIGINES DES RISQUES...................................................................................................................................................... 41
3.2.1 Origine humaine.......................................................................................................................................................... 41
3.2.1.1 Vol et sabotage de matériel.........................................................................................................................................................41
3.2.1.2 Fraudes.................................................................................................................................................................................................41
3.2.1.3 Sabotage immatériel......................................................................................................................................................................42
3.2.1.4 Indiscrétion, détournement d’informations.......................................................................................................................43
3.2.1.5 Détournement de logiciels..........................................................................................................................................................43
3.2.2 Greve, départ de personnel stratégique............................................................................................................ 43
3.2.3 Origine technique....................................................................................................................................................... 43
3.2.3.1 Risques matériels............................................................................................................................................................................43
3.2.3.2 Pannes et dysfonctionnement...................................................................................................................................................44
3.2.4 Origine naturelle......................................................................................................................................................... 44
3.3 DÉ MARCHE DE GESTION DES RISQUES SELON ISO 27005................................................................................................. 44
3.3.1 É tablissement de contexte...................................................................................................................................... 47
3.3.2 Appréciation du risque............................................................................................................................................. 49
3.3.2.1 Identification du risque................................................................................................................................................................49
3.3.2.2 Analyse du risque............................................................................................................................................................................50
3.3.2.3 É valuation du risque......................................................................................................................................................................52
3.3.3 Traitement du risque................................................................................................................................................ 53
3.3.4 Acceptation du risque............................................................................................................................................... 55
C
Étude et mise en place d’une application d’audit automatique de sécurité des SI

3.4 GESTION DES INCIDENTS DE SÉ CURITÉ .................................................................................................................................. 56


3.4.1 Gestion de l’après sinistre....................................................................................................................................... 56
3.4.2 Communication de crise.......................................................................................................................................... 57
3.4.3 Suivi des incidents...................................................................................................................................................... 58
3.5 MÉ THODOLOGIE DE GESTION DES RISQUES POUR LES DSI................................................................................................. 58
3.5.1 Percevoir le risque du point de vue global....................................................................................................... 58
3.5.2 Remettre à plat l’ensemble de la gestion du risque informatique...........................................................58
3.5.3 Créer un cadre structuré de gouvernance........................................................................................................ 59
3.5.4 Le rô le du personnel, de l’organisation et de l’automatisation................................................................60
3.5.5 Optimiser le rapport risques/bénéfices............................................................................................................ 60
CHAPITRE 4 : ETUDE, CONCEPTION ET REALISATION DE L’APPLICATION. 61
4.1 É TUDE ET SPÉ CIFICATION DES BESOINS DU SYSTÈ ME.......................................................................................................... 62
4.1.1 Identification des acteurs........................................................................................................................................ 62
4.1.2 Besoins fonctionnels................................................................................................................................................. 62
4.1.3 Besoins non fonctionnels......................................................................................................................................... 62
4.2 CONCEPTION.............................................................................................................................................................................. 63
4.3 RÉ ALISATION DE L’APPLICATION............................................................................................................................................ 67
4.3.1 Environnement de travail....................................................................................................................................... 67
4.3.1.1 Environnement matériel..............................................................................................................................................................67
4.3.1.2 Environnement logiciel.................................................................................................................................................................67
4.3.2 Les interfaces de l’application............................................................................................................................... 67
4.4 BENCHMARKING........................................................................................................................................................................ 74
4.4.1 Netwrix Auditor.......................................................................................................................................................... 74
4.4.2 Gensuite.......................................................................................................................................................................... 75
4.4.3 StandardFusion........................................................................................................................................................... 75
4.4.4 TeamMate + Audit...................................................................................................................................................... 75
4.4.5 Safesite............................................................................................................................................................................ 75
4.4.6 Particularité de notre solution.............................................................................................................................. 75
CONCLUSION.......................................................................................................................76
BIBLIOGRAPHIE...................................................................................................................A
WEBOGRAPHIE....................................................................................................................A
TABLE DES MATIERES.......................................................................................................B

Vous aimerez peut-être aussi