DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

MINISTERE DE L’ENSEIGNEMENT
SUPERIEUR

REPUBLIQUE DU CAMEROUN
Paix – Travail – Patrie

----------------

---------

UNIVERSITE DE DOUALA
------------------FACULTE DES SCIENCES-MIAGE
---------------

Mémoire de fin d’études pour l’obtention de la Maîtrise
d’Informatique et du titre d’Ingénieur Maître MIAGE

LA PRATIQUE DE L’AUDIT
INFORMATIQUE DANS LES BANQUES

Rédigé et présenté par :

Hubal PFUMTCHUM
Sous l’encadrement
Académique

Professionnel

YVES SOSTS
Enseignant à IRISA
Spécialiste en intégration des
solutions

Marc KEOU NGASSA
Expert comptable diplômé agrée CEMAC
Associé - gérant de Universal Consulting
Spécialiste de l’audit des Banques

Année Académique 2004 - 2005

La pratique de l’audit informatique dans les banques

Page 1

AVERTISSEMENT
Si les aspects techniques mentionnés dans ce rapport peuvent devenir obsolètes,
les concepts fondamentaux abordés restent valides. Le lecteur pourra actualiser
son information en consultant les sites Internet des éditeurs des différents produits
répertoriés.
Conformément aux usages, nous avons laissé en anglais un certain nombre de
termes du langage technique.

Rapport de stage rédigé par Hubal PFUMTCHUM
MIAGE 2006


Page 2

REMERCIEMENT
Nous aurions failli à la tradition si nous n’associons pas à

ce travail

des

remerciements à ceux qui ont contribué à sa réalisation.
Nous remercions le Pr Maurice TCHUENTE pour l’idée qu’il a eu à initier le
programme MIAGE.
Notre remerciement va également à Mr Marc KEOU NGASSA, associé gérant de
Universal Consulting pour son assistance tout au long des travaux et à monsieur
YVES SOST pour ses commentaires.
Nous sommes reconnaissant envers la faculté des sciences

et l’ESSEC de

l’université de Douala, les enseignants de l’Université de Rennes1 de l’IFSIC et
d’IRISA en France.
Nous avons une pensée favorable à tous ceux qui ont cru à notre jeune
formation en donnant l’occasion aux étudiant MIAGE d’effectuer des stages
dans leurs entreprises. Qu’ils en soient remerciés.

MIAGE 2006


Page 3

SOMMAIRE
AVERTISSEMENT ................................................................................................................................................................................................ 1
REMERCIEMENT ................................................................................................................................................................................................ 2
RESUME ............................................................................................................................................................................................................. 5
PARTIE I - DEMARCHE D’AUDIT INFORMATIQUE DANS LES BANQUES ..................................................................................................... 6
I – INTRODUCTION ........................................................................................................................................................................................... 7
II – LA PRATIQUE DE L’AUDIT ........................................................................................................................................................................... 8
2.1 Définition

......................................................................................................................................................................... 8

2.2 Les objectifs de l’audit

......................................................................................................................................................................... 8

III – L’AUDIT INFORMATQIUE ........................................................................................................................................................................... 8
3.1 Définition

......................................................................................................................................................................... 8

3.2 Le système informatique ......................................................................................................................................................................... 9
3.2.1 Définition .................................................................................................................................................................................. 9
3.2.2 Cartographie d’un système informatique ......................................................................................................................... 10
3.2.3 Les risques informatiques ..................................................................................................................................................... 11
VI – LA PRATIQUE DE L’AUDIT INFORMATIQUE DANS LES BANQUES ....................................................................................................... 11
4.1 L’informatique bancaire : l’apport des nouvelles technologies ..................................................................................................... 11
4.2 Les risques informatiques dans les banques ....................................................................................................................................... 12
4.2.1 Vol et diffusion non autorisée de données confidentielles.............................................................................................. 12
4.2.2 Erreurs ..................................................................................................................................................................................... 13
4.2.3 Fraudes .................................................................................................................................................................................. 13
4.2.4. Accidents "naturels" ............................................................................................................................................................. 15
4.2.5 Défaillance matérielle ou logicielle .................................................................................................................................... 15
4.2.6 Planification inefficace ....................................................................................................................................................... 16
4.2.7 Attaque et sabotage ........................................................................................................................................................... 18
4.3 Démarche proposée pour la pratique l’audit informatique bancaire ......................................................................................... 20
PARTIE II : MISE EN ŒUVRE DE LA DEMARCHE POUR L’AUDIT DU SYSTEME INFORMATIQUE DE BANK AFRICA ................................ 25
I – RAPPELS DES TRAVAUX A EFFECTUER .................................................................................................................................................... 26
II - LES TRAVAUX EFFECTUES .......................................................................................................................................................................... 26
A - AUDIT DE L’ORGANISATION .................................................................................................................................................................. 28
1. Etape1 : prise de connaissance générale ............................................................................................................................................ 28
2. Etape2 : Prise de connaissance du PSS ................................................................................................................................................. 28
3. Etape 3 : appréciation du dispositif de contrôle du risque informatique ........................................................................................ 28

MIAGE 2006


Page 4

4. Etape 4 : Constat et Recommandation ................................................................................................................................................ 29
4.1 Les principaux constats : sécurité physique ........................................................................................................................ 29
4.2 Les principaux constats : sécurité logique ........................................................................................................................... 30
4.3 Les recommandations ............................................................................................................................................................ 30
B - AUDIT DE L’ARCHITECTURE RESEAU........................................................................................................................................................ 32
Etape1 : prise de connaissance générale ................................................................................................................................................ 32
2. Etape2 : Prise de connaissance du PSS ................................................................................................................................................. 33
3. Etape 3 : appréciation du dispositif de contrôle du risque informatique ........................................................................................ 33
3.1 Examen de la configuration du routeur AGS+ ..................................................................................................................... 33
3.2 Examen de la configuration du routeur DLink DI-614 .......................................................................................................... 34
3.3 Examen de la configuration du serveur ISA ......................................................................................................................... 35
3.4 Examen de la configuration du serveur d’antivirus TrendMicro Officescan Corporate V. 7.0 ...................................... 35
4. Etape 4 : Les principaux constats et recommandations ................................................................................................................... 35
4.1 Les constats .............................................................................................................................................................................. 35
4.2 Les recommandations ............................................................................................................................................................ 37
C - AUDIT DE LA BASE DE DONNEES DES CLIENTS ..................................................................................................................................... 40
EXAMEN DE LA BASE DE DONNEES ............................................................................................................................................................. 40
1. L’existant

....................................................................................................................................................................... 40

2. Démarche

....................................................................................................................................................................... 40

3. les constats

....................................................................................................................................................................... 41

Examen de quelques dossiers physiques .................................................................................................................................................. 43
o

LEVEL BANK INTERNATIONAL TCHAD S.A ...................................................................................................................................... 43

o

COMPAGNIE WALLEM POUR LE TRANSPORT .............................................................................................................................. 45

4. Les recommandations

....................................................................................................................................................................... 45

CONSLUSION .................................................................................................................................................................................................. 47
PARTIE III: ANNEXE.......................................................................................................................................................................................... 47
QUESTIONNAIRE DES RISQUES INFORMATIQUES ........................................................................................................................................ 48
THEMES DE REFERENCES DE LA MISSION D’AUDIT .................................................................................................................................... 53
ARCHITECTURE DU RESEAU DE LA BANQUE AVANT L’AUDIT .................................................................................................................... 59
ARCHITECTURE RESEAU PROPOSEE ........................................................................................................................................................... 60
SITES INTERNET ET BIBLIOGRAPHIE ................................................................................................................................................................ 61

MIAGE 2006


Page 5

RESUME
Dans le souci de professionnaliser les enseignements au Cameroun et de répondre
ainsi à la demande en cadre informatique dans les entreprises, il existe depuis
2003 à l’Université de Douala, la MIAGE, formation de niveau BAC+5 préparant les
étudiants au titre d’ingénieur Maître en informatique.
A la fin de cette formation initiée par le Professeur Maurice TCHUENTE, les étudiants
ont l’obligation de soutenir un rapport de stage effectué en entreprise, devant un
jury constitué des enseignants et des professionnels de d’informatique. Nous avons
effectué le notre dans le cabinet Universal Consulting.
Universal Consulting est un cabinet de conseil, d’audit et d’expertise comptable
installé à Douala au Cameroun. Travaillant pour le compte de ses clients
constitués notamment des banques et des projets financés par les bailleurs de
fonds, il apporte une approche internationale pour trouver des solutions aux
problèmes locaux. Dans cette optique, il a développé plusieurs concepts
novateurs dans la profession

au Cameroun, parmi lesquels l’utilisation de

l’informatique en appui à l’audit. C’est autour de ce concept que nous avons
effectué notre stage de fin de formation, lequel nous a permis d’expérimenter les
concepts théoriques de l’école en milieu professionnel.
Ces travaux nous ont permis de proposer une démarche, des méthodes et des
techniques appropriées pour la pratique de l’audit informatique dans les banques.
De peur de rester trop théorique, nous avons mis en exergue cette technique pour
auditer l’organisation, l’architecture du réseau informatique et la basse de
données de la banque « BANK AFRICA » dans le cadre d’une mission d’audit
effectuée par le cabinet Universal Consulting.

MIAGE 2006


Page 6

PARTIE I - DEMARCHE D’AUDIT INFORMATIQUE DANS LES BANQUES

MIAGE 2006


I – INTRODUCTION
Le développement de l’informatique et la prolifération des services autour de ce
concept ont fragilisé de manière considérable les modes de travail dans plusieurs
secteurs

d’activités et notamment le secteur bancaire. En outre, avec

l’avènement de la monétique et du e-banking, les banques ont désormais
l’obligation de disposer d’un système informatique fiable afin de participer au jeu
de la concurrence. Pour disposer d’un système alliant

robustesse, fiabilité et

tolérance aux pannes, les banques se doivent de se doter des outils performants,
mais surtout de faire vérifier en permanence l’état de leur système informatique,
ce contrôle qui leur donnera l’assurance sur le degré de maîtrise des opérations
et

l’optimisation

des

systèmes, des

conseils

pour

corriger

les

éventuels

dysfonctionnements identifiés, afin de créer la valeur ajoutée. On dit alors que le
système informatique de la banque doit faire l’objet d’audit régulier.
La pratique de l’audit informatique dans les banques nécessite alors des
compétences plurielles, une compréhension de l’activité bancaire et surtout la
maîtrise de la logique des systèmes informatiques et services dérivés. Fort de cela,
il

est

généralement

recommandé

pour

cet

exercice,

une

approche

méthodologique et une démarche appropriée propre à l’audit des systèmes
informatiques dans les banques.
Notre travail consistera à proposer une démarche méthodique assortie de
quelques diligences pour la pratique de l’audit informatique dans les banques en
respectant les normes de l’art. Il sera articulé autour de trois parties, une première
dans laquelle nous présenterons la pratique de l’audit, la pratique de l’audit
informatique et enfin de l’audit informatique dans les banques. Dans la deuxième
partie, nous mettrons en exergue cette démarche pour une mission d’audit
informatique dans une banque sud-saharienne. La troisième partie sera le cadre
des différentes annexes.

MIAGE 2006


Page 8

II – LA PRATIQUE DE L’AUDIT
2.1 Définition
L’audit est une activité indépendante et objective qui donne à une organisation
une assurance sur le degré de maîtrise de ses opérations, lui apporte ses conseils
pour améliorer son fonctionnement et contribue à créer de la valeur ajoutée. Il
aide également l’organisation à atteindre ses objectifs de manière efficiente en
apportant une démarche systématique et méthodique pour évaluer l’efficacité
de la gestion des risques. En somme, l’audit peut être considéré aujourd’hui
comme la gestion des risques.
2.2 Les objectifs de l’audit
Les objectifs de l’audit de manière générale seront d’émettre une opinion ou de
formuler des recommandations sur

un dispositif de gestion des risques en

effectuant des diligences conformes aux normes de la profession. Ceci suppose
une appréciation générale des risques liés à l’activité.

III – L’AUDIT INFORMATQIUE
3.1 Définition
Comme tout audit, l’audit informatique est une activité indépendante consistant
à évaluer un dispositif mis en place pour faire face aux risques informatiques. Ceci
suppose une bonne identification des principaux risques informatiques.
L’audit informatique possède deux niveaux de complexité, dans la mesure où l’on
n’est toujours pas certain de la fiabilité des systèmes informatiques, bien que ce
soit ces systèmes qui vont nous fournir des informations qui seront à la bases de nos
constats et recommandations. C’est pour cette raison que la pratique de l’audit
informatique doit nécessiter une polyvalence toute particulière, la compréhension
de l’activité de base et une bonne connaissance des systèmes informatiques car
l’informatique n’étant qu’un outil utilisé dans une activité. On peut à ce niveau se
poser deux questions fondamentales :

MIAGE 2006


-

Comment évaluer un outil de production dont on ne connait pas la logique qui
sous-tend son fonctionnement ?

-

Comment formuler les recommandations sur une activité seulement à base de
quelques outils de production, sans connaître intimement cette activité ?

Ces deux questions sont à la base de l’audit informatique. Il est vital pour un
auditeur informatique de bien connaître la logique des traitements automatisés, et
de les appliquer sur une activité, qui utilise l’informatique comme outil de travail
(production). L’auditeur informatique doit être à mesure de lire et de comprendre
un message d’erreur, ou alors d’établir par exemple la différence qui existe entre
une base de données, une application et un système d’exploitation, ou encore
entre un progiciel et un logiciel. Il doit également pouvoir faire la différence entre
un message bloquant (contrôle bloquant) et un message d’erreur d’exploitation
(erreur de saisie). En somme, l’auditeur doit bien connaître les éléments d’un
système informatique afin de prétendre évaluer leurs risques.
3.2 Le système informatique
3.2.1 Définition
Le système informatique se définit comme un ensemble de matériel, de logiciel et
de système externe qui travaillent de manière interdépendante pour transformer
les données et les restituer aux utilisateurs sous forme d’informations. Il apparaît
naturel que pour évaluer le risque d’un système informatique, il faudrait s’intéresser
aux risques attachés aux éléments qui le compose.
De manière générale, on s’intéressera aux risques physiques (risques liés aux
matériels) et aux risques logiques (risques liés aux logiciels et aux procédures), car
l’informatique étant lui-même divisé en deux partie, à savoir la partie HADWARE
pour le matériel et la partie SOFTWARE
informatiques)

MIAGE 2006

pour les logiciels (et les procédures


Page 10

3.2.2 Cartographie d’un système informatique
Pour mieux comprendre

le système informatique, nous avons matérialisé une

cartographie d’un système informatique et une vision réduite de la partie logique
de l’informatique, vision qui doit orienter un auditeur informatique tout au long
d’une mission d’audit informatique.

Cartographie d’un système informatique

MATERIEL

LOGICIEL

SYSTEME
EXTERNE

La couche logicielle d’un système informatique

DATA
(données)
LOGICIELS
(applications)
OS
(système
d’exploitation)

MIAGE 2006

Les données

Ex : Message SWIFT MT100

Les applications

Ex : Swift Access

Système d’exploitation

Ex : UNIX AIX, Linux, Windows


3.2.3 Les risques informatiques
Les risques informatiques peuvent se présenter de deux formes, les risques
physiques et les risques logiques dus à la défaillance logicielle ou des procédures.
Ces deux catégories de risques peuvent encore se décliner en plusieurs autres
types en fonction de la spécificité de l’activité. Nous allons apprécier les risques
informatiques dans les banques.

VI – LA PRATIQUE DE L’AUDIT INFORMATIQUE DANS LES BANQUES
4.1 L’informatique bancaire : l’apport des nouvelles technologies
La

vitesse

de

l’innovation

technologique

liée

aux

ordinateurs

et

aux

télécommunications, ces dernières années, et l’intégration de nouveaux produits
nécessitant des traitements automatisés

rendent les banques de plus en plus

dépendantes de la fiabilité et de la stabilité de leurs systèmes informatiques. S’il est
vrai que les banques ont toujours été exposées à des risques tels qu’erreurs et
fraudes, leur importance et la fréquence de leur souvenance se sont accrues de
manière considérable ces dernières années. En outre, avec la forte informatisation
de

l’activité

bancaire

découlant

de

l’essor

des

nouvelles

technologies

(monétique, e-banking, SWIFT,…) la banque est devenue très dépendante de son
système informatique. Les types de risques qui caractérisent un environnement
informatique et les procédures de sécurité et de contrôle nécessaires requièrent
une attention particulière. On examinera ici les catégories suivantes de risques:
diffusion non autorisée d’informations, erreurs, fraudes, interruption de l’activité par
suite d’une défaillance du matériel ou du logiciel, planification inefficace et
risques liés aux opérations d’informatique individuelle.

MIAGE 2006


Page 12

4.2 Les risques informatiques dans les banques
4.2.1 Vol et diffusion non autorisée de données confidentielles
La plupart des informations bancaires sont créées par traitement informatique ou
liées directement à ce dernier. Les données et documents sont généralement
acheminés à l’intérieur d’une banque ou entre une banque et ses correspondants
et clients par des réseaux publics de communication (lignes téléphoniques et
satellites, par exemple). Un grand nombre d’usagers, dont les employés et clients
des banques, peuvent accéder directement à ces informations par l’intermédiaire
de terminaux via internet et de téléphones informatiques (téléphones WAP). Tout
en améliorant les services à la clientèle et les opérations internes, ces activités ont
accru les risques d’erreur et d’utilisation abusive des informations des banques.
Une grande partie de ces informations sont confidentielles; elles pourraient nuire
aux relations avec la clientèle ainsi qu’à la réputation de l’établissement et
entraîner des demandes de dommages et intérêts si elles tombaient entre de
mauvaises mains. On peut citer parmi ces informations l’historique de certains
comptes clients (hommes d’affaires, hommes politiques, …). La création et le
stockage de la correspondance et des stratégies bancaires s’effectuent
également par traitement informatique. Le danger particulier que représente la
divulgation d’informations confidentielles avec les systèmes informatiques, par
rapport aux systèmes manuels, réside dans le fait que l’on peut prélever plus
facilement, et sous une forme pouvant être traitée par ordinateur (telles que
copies sur bande ou disquette), une quantité importante d’informations et que
l’accès non autorisé peut intervenir sans laisser de traces. Il convient donc de
mettre en place des procédures adéquates de sécurité et de contrôle pour
protéger la banque. C’est en fonction du degré de risque encouru par
l’établissement et de l’incidence des pertes (ou de la diffusion non autorisée
d’informations) qu’il faut fixer le niveau de contrôle requis.
Les contrôles techniques effectués aux fins de la sécurité de l’information
pourraient inclure:


le chiffrement, processus par lequel le texte en clair est converti en une série
de symboles dénués de sens;

MIAGE 2006




Page 13

l’utilisation de codes d’authentification des messages, qui protègent contre
toute altération non autorisée les transactions électroniques de données au
cours de la transmission ou du stockage;



le recours au logiciel d’application de mesures de sécurité, en vue de
restreindre

l’accès

aux

données, fichiers, programmes, utilitaires

et

commandes de systèmes informatiques. De tels systèmes permettent de
contrôler l’accès par utilisateur, par transaction et par terminal.
Avec ces dispositifs, les violations ou tentatives de violation de la sécurité doivent
être automatiquement identifiés.
4.2.2 Erreurs
Les erreurs se produisent en général lors de l’entrée des données ainsi que durant
le développement et la modification des programmes. Des erreurs importantes
peuvent également se glisser au cours de la conception des systèmes, des
procédures routinières de gestion des systèmes (procédures d’exploitation des
systèmes) et de l’utilisation des programmes spéciaux destinés à corriger d’autres
erreurs. Les erreurs sont habituellement imputables à une défaillance humaine, et
très rarement aux composants électroniques ou mécaniques internes. Elles
peuvent aussi être introduites dans les programmes de logiciel lorsque ces derniers
sont «personnalisés» et adaptés aux besoins d’un utilisateur particulier
4.2.3 Fraudes
Les flux de données bancaires sont considérés comme des instructions qui
donnent lieu à des traitements spécifiques (interprétation des messages SWIFT et
des logs d’erreur) qui complexifie le contrôle interne, ouvrant ainsi les portes aux
fraudes. Les fraudes réussies ne se traduisent pas seulement par une perte
financière directe pour l’établissement; elles portent aussi atteinte, lorsque les
médias en prennent connaissance, à la confiance placée à l’établissement et le
système bancaire en général. Vu les nombreuses possibilités d’accès aux
documents informatiques, les risques de fraude sont multiples. On peut citer à titre
d’exemple :
MIAGE 2006


-

introduction de transactions non autorisées dans le système informatique;

-

modification non autorisée des programmes lors d’opérations courantes de
développement

et

de

maintenance,

de

sorte

que

ceux-ci

risquent

d’engendrer automatiquement des transactions frauduleuses, de ne pas tenir
compte des tests de contrôle effectués sur certains comptes ou d’éliminer
l’enregistrement de transactions spécifiques;
-

utilisation des programmes spéciaux pour modifier sans autorisation des
documents informatiques en contournant les dispositifs normaux de contrôle et
les pistes de vérification intégrées dans les systèmes informatiques;

-

extraction physique des fichiers d’un ordinateur, qui seront modifiés ailleurs par
insertion de transactions ou de soldes frauduleux avant d’être remis en place
pour le traitement (injection sql par exemple dans une base de données) avant
lancement du batch de fin de journée(traitement de fin de journée);

-

introduction ou interception aux fins de leur modification de transactions lors
de leur transmission par l’intermédiaire des réseaux de télécommunications
(écoute et capture de flux IP sur un réseau).

À l’heure actuelle, on assiste à la mise en place de nouvelles formes de paiement
qui permettent à des tiers d’initier des paiements au moyen d’un simple ordinateur
équipé d’un navigateur web et connecté à Internet (e-commerce, e-banking). La
probabilité que se produisent ces types de fraudes par le biais d’un accès non
autorisé aux systèmes de télécommunications devient de plus en plus importante.
La plupart des systèmes bancaires comportent des dispositifs de contrôle et
fournissent des informations destinées à faciliter la prévention ou la détection de
ces types de fraudes (base de données d’incident avec leurs signatures).
Toutefois, ces informations courent, elles aussi, le risque d’être manipulées par des
personnes ayant accès aux terminaux ou aux fichiers informatiques (SSP : service
storage provider dans le cadre d’outsourcing ou externalisation). Pour mettre sur
pied des systèmes de contrôle interne efficaces, il est essentiel de déterminer tous
les points vulnérables de chaque système. Les programmes et données sensibles
doivent être protégés contre des modifications non autorisées. Il faut également
MIAGE 2006


veiller à donner

Page 15

une formation adéquate au personnel oeuvrant dans les

domaines sensibles et à répartir convenablement les tâches.
4.2.4. Accidents "naturels"
Cette catégorie regroupe tous les risques comme les incendies, dégâts des eaux,
explosions, catastrophes naturelles, etc. Certains de ces risques ne peuvent être
raisonnablement pris en compte (ex. effondrement causé par la présence d'une
ancienne carrière souterraine), d'autres peuvent être prévenus ou combattus par
des dispositifs adéquats, l'informatique n'étant alors qu'un des aspects du
problème. Enfin, des mesures simples permettent de limiter les conséquences de
certains risques (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).
En outre, il convient de souscrire une police d’assurance pour les équipements
informatiques critiques (les différents serveurs par exemple).
4.2.5 Défaillance matérielle ou logicielle
Les systèmes informatiques sont constitués, au niveau du matériel comme du
logiciel, de multiples éléments et la défaillance de l’un d’entre eux suffit pour
bloquer tout le système. Ces éléments sont souvent concentrés en un seul ou en
un nombre limité d’endroits, ce qui en accroît la vulnérabilité. Le remède classique
contre une panne du système consistait auparavant à revenir aux procédés
manuels que le système informatique avait remplacés. Dans la plupart des cas,
cette façon de procéder n’est plus réaliste et peu de banques pourraient
fonctionner sans systèmes informatiques. Le traitement et la fourniture de
l’information au moyen d’une technologie améliorée ont accru la dépendance
des utilisateurs à l’égard de la disponibilité et de la fiabilité des systèmes
automatisés. La disponibilité continue du système d’information d’une banque fait
partie intégrante d’une prise de décisions efficace. Lorsque les systèmes
informatiques sont hors d’usage, les effets préjudiciables qui en résultent pour les
services bancaires en temps réel aux clients sont immédiats et prennent
rapidement des proportions alarmantes. Les retards s’accumulent et, si la
défaillance dure plusieurs heures, les conséquences peuvent êtres lourdes. Ces
MIAGE 2006


Page 16

effets sont particulièrement dévastateurs dans le cas des systèmes électroniques
et de paiement, ceux notamment qui garantissent un règlement le jour même,
lorsque les bénéficiaires sont tributaires de la réception de fonds pour faire face à
leurs engagements. Les coûts engendrés par une panne sérieuse des systèmes
peuvent dépasser de loin les frais de remplacement du matériel, des données ou
du logiciel endommagés.
L’existence de plans de secours efficaces peut permettre aux banques de réduire
l’incidence des problèmes d’exploitation de ce genre. Ces plans devraient
prolonger la disponibilité du système informatique d’une banque. Ils devraient
comporter des dispositions pour la poursuite de l’activité et des procédures de
relance en cas d’interruption ou de dysfonctionnement des systèmes, c’est-à-dire
un dispositif de sauvegarde complète du système (OS, Application et données)
hors site de production et identique à l’environnement de productions, ainsi que
des procédures informatiques régulièrement mises à jour. Les plans de secours
devraient être testés périodiquement pour s’assurer que leur efficacité demeure
intacte. Une banque qui opte pour l’outsourcing ou l’externalisation de son
système informatique devrait veiller à ce que les plans de secours de ces services
complètent les siens.

4.2.6 Planification inefficace
Une

planification optimale est d’une importance capitale. L’efficacité et la

qualité des services bancaires sont désormais tellement tributaires des systèmes
informatiques que toute défaillance dans la planification, l’acquisition et
l’installation de nouveaux systèmes peut avoir de sévères conséquences pour la
banque. Toute défaillance dans l’installation de nouveaux systèmes et la fourniture
de nouveaux services peut pénaliser lourdement une banque par rapport à ses
concurrents. Ce fût le cas pour une banque du sud qui après avoir développé un
module d’interrogation des comptes via Internet s’était précipitée à mettre en
ligne sans avoir testé les différentes fonctionnalités par les spécialistes de la
sécurité sur internet.

Vingt quatre heures seulement après sa mise en ligne,

certains clients vicieux avaient réussi à modifier leur solde dans le système en
MIAGE 2006


exploitant une faille de ce nouveau système. En effet, dans le répertoire
d’installation de l’application se trouvait le module de gestion des comptes
encore en évaluation et était accessible depuis internet. Il suffisait de lancer un
browser Internet et de taper l’adresse http://www.banquepirate.com/ pour
accéder au module de consultation du solde et d’ajouter un petit check à la
fin(http://www.banquepirate.com/check)

pour

tomber

sur

l’interface

de

modification du solde.
Pour garder l’anonymat, on a remplacé le domaine de la banque victime par un
nom de domaine aléatoire, à

savoir « banquepirate.com ». Les dégâts furent

énormes pour la banque. Inversement, l’informatisation à outrance, dans les cas
notamment où les avantages sont faibles, s’est souvent révélée erronée du point
de vue des coûts. Quelques établissements financiers ont rencontré de sérieux
problèmes en essayant d’introduire des systèmes hautement intégrés. C’est par
exemple le cas d’une coopérative qui opte pour un progiciel de gestion intégrée
des banques commerciales. Ce cas n’est qu’un exemple isolé parmi tant d’autre.
Dans certains cas, le coût, le temps et les ressources en personnel nécessaire pour
assurer le succès d’une installation de systèmes intégrés ont été sous-estimés. Des
projets développés pendant de nombreuses années ont dû être abandonnés
avec des coûts énormes.
Étant donné la complexité des systèmes informatiques et leur incidence sur
l’ensemble de l’organisation, il importe que la direction générale

s’engage à

assurer le succès de chaque projet. Ceci passe par une bonne définition du cahier
de charges et le respect du cycle de vie d’un du génie logiciel à savoir :
-

Expression des besoins

-

Rédaction d’un cahier de charge

-

Etude de faisabilité

-

Conception et réalisation

-

Test

-

Mise en production

-

Evolution du produit

MIAGE 2006


Page 18

Toute organisation devrait attacher une grande attention à la planification
(stratégique) à long terme des systèmes informatiques, à l’équipement, à la
détermination des spécifications des systèmes, et évidement au choix des
fournisseurs de solutions et à la conduite du projet. On constate que 75% de
projet informatique se voit souvent leur budget complètement épuisé alors que le
projet est encore dans la phase de la conception, ce qui suppose que l’étude de
faisabilité était erronée.
4.2.7 Attaque et sabotage
Dans cette catégorie, on range les risques informatiques quoique inconnus des
non informaticiens, mais extrêmement répandus de nos jours. Nous allons
découvrir quelques attaques informatiques relèvant du domaine de l’informatique
pur, mais donc la compréhension des risques attachés relève du bon sens et de
l’esprit critique, celui que devrait avoir tout auditeur.


Le cheval de Troie programme malveillant d’apparence anodine (jeu, petit
utilitaire...) qui, une fois installé dans un ordinateur, peut causer des dégâts
comme un virus classique, ou permettre de prendre le contrôle à distance de
la machine.



La backdoor (porte arrière) est un point d’entrée dans un programme ou un
système, plus ou moins secret. C’est généralement le recours pour débloquer
un code d’accès perdu ou pour contrôler les données lors du debuggage.
Malheureusement, c’est aussi l’un des points d’entrée des hackers (pirate
informatique), lorsqu’ils en découvrent l’existence. Le hacker peut également
créer lui-même cette porte pour l'utiliser dans un deuxième temps.



Le sniffing : c'est écouter une ligne de transmission par laquelle transitent des
données pour les récupérer à la volée. Cette technique peut-être utilisée en
interne pour le debuggage ou de manière abusive par un pirate cherchant,
par exemple, à se procurer des mots de passe.

MIAGE 2006




Page 19

Le spoofing : c'est une technique d’intrusion dans les systèmes informatiques
consistant à envoyer à un serveur d’une entreprise, des messages (paquets)
semblant provenir d'une adresse IP

connue par le firewall (adresse interne

existante autorisée). Pour que la communication ne s’établisse pas avec la
machine possédant réellement cette adresse, le hacker doit dans le même
temps rendre cette machine injoignable pour avoir le temps d’intercepter les
codes de communication et établir la liaison pirate.


L'attaque par rebond est menée via un autre ordinateur qui se trouve
involontairement complice et qui expédie les messages d'attaque à la victime,
masquant ainsi l'identité du véritable agresseur.



L'attaque par le milieu consiste pour un hacker à se placer entre deux
ordinateurs en communication et se faire passer pour un afin d'obtenir le mot
de passe de l'autre. Dès lors, il peut se retourner vers le premier avec un mot de
passe valide et l'attaquer réellement.



Le déni de service est une attaque cherchant à rendre un ordinateur hors
service en le submergeant de trafic inutile. Par exemple, un serveur
entièrement occupé à répondre à des fausses demandes de connexion.
Plusieurs machines peuvent être à l'origine de cette attaque (généralement à
l’insu de leur propriétaire).



Le war-driving dans le cas des réseaux Wi-Fi, consiste à circuler dans la ville
avec un ordinateur portable ou un PDA (ordinateur de poche) équipé d’une
carte réseau Wi-Fi pour repérer et pénétrer dans les réseaux locaux mal
protégés.

MIAGE 2006


4.3 Démarche proposée pour la pratique l’audit informatique bancaire

Prise de connaissance
générale

Prise de connaissance du plan
stratégique de sécurité (PSS)

Appréciation du dispositif
de contrôle des risques
informatiques

Constats et
recommandations

Réunion de synthèse
avec la direction de la
banque

MIAGE 2006


Page 21

La particularité de l’audit informatique dans un environnement bancaire nécessite
une méthodologie appropriée. Nous venons d’élaborer une liste quoique non
exhaustive des risques informatiques que pourraient faire face une banque.
Maintenant, nous allons mettre en œuvre une démarche méthodique qui nous
permettra d’apprécier le dispositif de contrôle mis en place pour faire face à ces
risques. La démarche retenue s’articule sur cinq étapes. Le prélude à tout audit
informatique est la définition des processus sensibles dans les banques de
manières générales.
Les processus suivants peuvent être retenus :
-

La sécurité physique

-

La sécurité logique

-

La sécurité des réseaux (LAN et WAN)

-

La planification et continuité des activités

-

Les ressources humaines

-

La stratégie informatique

-

La tolérance aux pannes

-

Activités opérationnelles

-

Méthodes, normes et documentation

-

Les sauvegardes

-

Méthodologie de développement des projets

-

Gestion des risques informatiques

EXPLICITATION DE LA DEMARCHEPROPOSEE
Etape 1 : prise de connaissance générale
Cette étape a pour but de permettre aux membres de l'équipe d'acquérir une
connaissance détaillée des caractéristiques de la banque et des fonctions à
auditer. Elle s'effectuera à travers les entretiens avec les opérationnels pour
identifier nos principaux interlocuteurs tout au long de la mission. C’est également

MIAGE 2006


l’occasion pour les opérationnels de préciser s’ils ont des points sur lesquels ils
aimeraient qu’une attention particulière soit portée.
Généralement dans les missions d’audit informatiques, les opérationnels peuvent
souhaiter qu’on regarde de très près la configuration d’un routeur que de perdre
le temps sur la formalisation des requêtes pour la détection des suspens dans les
comptes des correspondants par exemple ou encore la vérification des logs SWIFT
pour détecter éventuellement les PDE (Possible Duplicate Emission)
Etape 2 : Prise de connaissance du plan stratégique de sécurité
Le plan stratégique de sécurité est élaboré par la direction générale. Il pour but
de fixer les objectifs de la banque en terme de sécurité. C’est la référence des
unités opérationnelles pour ce qui est des décisions à prendre en terme de
sécurité. Le niveau de sécurité informatique devrait tenir compte de ce plan.
Etape 3 : appréciation du dispositif de contrôle du risque informatique
Il est question ici de prendre connaissance des dispositifs mise en place en
prévention des risques informatiques. Nous apprécierons ce dispositif souvent
(organisationnel

et

méthodologique)

en

exploitant

notre

questionnaire

informatique de contrôle des risques.
A l’issus de cette phase, les points forts et les points faibles du dispositif de contrôle
des risques informatiques seront identifiés.
Les points forts seront testés pour s’assurer du caractère effectif des contrôles alors
que des recommandations seront formulées sur les points faibles.
Etape 4 : Constats et recommandations
Cette phase consiste à élaborer des tableaux de constat/recommandation au
regard de l’appréciation du dispositif de contrôle des risques apprécié à l’étape 3.
Cette partie constitue d’ailleurs la première mouture du tableau de constats et
recommandations du rapport projet qui sera présenté en réunion de synthèse
avec la direction générale.
MIAGE 2006


Page 23

Etape 5 Réunion de synthèse avec la direction
Il s’agit d’une réunion au cour de la quelle l’auditeur présente la synthèse des
travaux effectués et notamment émet un rapport projet contenant les principaux
constats et les recommandations.

MIAGE 2006


Page 25

PARTIE II : MISE EN ŒUVRE DE LA DEMARCHE POUR L’AUDIT DU SYSTEME
INFORMATIQUE DE BANK AFRICA

MIAGE 2006


Page 26

I – RAPPELS DES TRAVAUX A EFFECTUER

D’après les termes de références (voir annexe), les travaux porteraient notamment
sur :
-

l’audit de l’organisation

-

l’audit de l’architecture du réseau

-

l’audit de la base de données

II - LES TRAVAUX EFFECTUES
AFRICA BANK est une banque commerciale de l’Afrique tropicale offrant les
services bancaires classiques :
● Collecte des dépôts clientèle
● Octroi de crédit à la clientèle
Elle dispose de quatre agences (ZETA, BETA, GAMA et SIGMA) et opère sur un
système informatique en architecture décentralisée. Dans cette configuration, les
données des agences sont acheminées au site central par l’artifice de
l’intégration des fichiers avant traitement de fin de journée.
Ces dernières années, son système informatique a connu des pannes récurrentes.
C’est dans le but de faire face à cette situation que la Direction Générale avait
commandité un audit donc les recommandations aideraient à corriger les
problèmes actuels et surtout mettre en place des dispositifs pour éviter que cette
situation ne se reproduise dans le futur.
Pour ce faire, la banque «BANK AFRICA » avait sollicité le cabinet Universal
Consulting, cabinet dans lequel nous avons effectué notre stage. J’ai donc
participé à toutes les phases cette mission d’audit en qualité de chef de mission.

MIAGE 2006


Page 27

Etant donné la densité des travaux à effectuer, nous avons trouvé opportun de les
diviser en trois grands lots et pour chaque lot, nous mettrons en exergue la
démarche présentée ci-dessus.
Ce découpage faisait ressortir les lots suivants:
A. Lot 1 : Audit de l’organisation
B. Lot 2 : Audit de l’architecture réseau
C. Lot 3 : Audit de la base de données des clients

MIAGE 2006


Page 28

A - AUDIT DE L’ORGANISATION
Comme le précisait les termes de références, il est question d’évaluer la politique
de sécurité de la banque et de proposer les recommandations adéquates pour la
mise en place d’une politique sécuritaire de pointe. On s’intéressera aussi bien à la
sécurité physique qu’à la sécurité logique.
1. Etape1 : prise de connaissance générale
Nous avons pris des rendez-vous avec quelques responsables stratégique de la
banque pour voir si la gestion de la sécurité informatique était intégrée dans le
plan stratégique de la banque. Nous nous sommes notamment entretenu avec le
Directeur Général Adjoint, le Directeur Financier, le Directeur informatique et le
Contrôleur Général. Dans cette phase, nous avons exploité notre questionnaire de
contrôle interne dans les banques (voir annexe)
2. Etape2 : Prise de connaissance du PSS
Nous nous sommes entretenus avec le Directeur Informatique (DI) à défaut d’un
responsable de la sécurité des systèmes informatiques (RSSI). Nous avons effectués
quelques tests de cohérences sur la plate forme de production en rapprochant
certains indicateurs obtenus de l’entretien et de ceux réellement en exploitation.
Par exemple, en réponse à la question de savoir si la banque avait un antivirus, et
comment étaient effectuées les mises à jour, le DI nous a répondu qu’il se faisait
automatiquement via la LiveUpdate. Après vérification, nous avons constaté que
le module LiveUpdate était mal configuré et que la dernière mise à jour datait
d’environ deux (02) ans.
3. Etape 3 : appréciation du dispositif de contrôle du risque informatique
Le dispositif de contrôle de la sécurité est fortement défaillant. En effet, nous avons
les constatations suivantes pendant notre audit :
-

absence de plan de continuité des activités

-

absence de recueil des risques informatiques dans les banques

MIAGE 2006


-

absence de cartographie des risques

-

absence d’une base de données incident / risque

-

absence de plan stratégique de la sécurité

-

Page 29

absence de RSSI.

4. Etape 4 : Constats et Recommandations
4.1 Les principaux constats : sécurité physique
● Un système de contrôle d’accès défaillant
Le système de contrôle d’accès dans les salles serveurs de la banque ne
fonctionne plus. Dans cette situation, toute personne étrangère ou non à la
banque peut se retrouver dans cette salle sans être identifiée.
● Système d’identification obsolète
le système d’identification permettant d’enregistrer dans une base de données
tous les personnes entrant et sortant dans la banque (en dehors des clients) est
implémenté sur une machine Windows 95 et reliée au réseau de la banque et à
internet. Ce système est source de plusieurs vulnérabilités et constitue une porte
d’entrée des spywares et chevaux de Troie dans la banque.
● Reprise électrique très lente en cas de coupure
La banque dispose d’un groupe électrogène pour faire face aux coupures
intempestives du courant mais celui-ci ne se met pas automatiquement en
marche après la coupure du courant. Cette situation peut provoquer des
incidents de traitements informatiques préjudiciables à la banque, comme la
corruption de certaines tables dans la base de données si des traitements
portaient sur les données de ces tables.
● Absence de contrat d’assurance couvrant les équipements sensibles
Les serveurs de production et autre équipent sensibles de la banque ne sont pas
couverts par des contrats d’assurance. En cas d’incident informatique mettant

MIAGE 2006


Page 30

hors d’usage ces serveurs, la banque éprouvera de difficultés financières pour leur
remplacement.
4.2 Les principaux constats : sécurité logique
● Les comptes utilisateurs génériques
Les comptes utilisateurs sur les serveurs de la banque sont génériques,
généralement sous la forme PrénomAnnéeDeNaissance et donc facile à casser
ou à deviner dès lors qu’on connaît un peut l’utilisateur.
En outre le compte administrateur du serveur central est connu de tous les
informaticiens et utilisé généralement pour toutes les taches d’administrations.
Cette situation peut entraîner des

risques graves en cas d’une mauvaise

manipulation ; en effet l’utilisation du compte root sur les systèmes UNIX requiert
une certaine vigilance car ses actions sont irréversibles.
● Protection anti-virale légère
Le logiciel anti-virus utilisé dans le parc informatique n’est pas régulièrement mis à
jour et sa configuration ne couvre pas l’ensemble du parc informatique.
● Politique de gestion des ressources Internet insatisfaisant
La revue du cache Internet sur les machines de guichet montre qu’elles sont
connectées à Internet et que les sites visités dans la plupart sont des sites aux
contenus réservés aux adultes. Ces machines sont également utilisées pour
télécharger des contenus vidéo, relativement gourmand en bande passante.

4.3 Les recommandations
Il est recommandé de redéfinir la stratégie informatique. Cette nouvelle stratégie
devrait intégrer les procédures informatiques qu’il faudrait rédiger pour toutes les
tâches effectuées à la Direction Informatique. Ces procédures doivent être
rédigées et appliquées par l'informatique. L'ensemble des procédures doit aboutir
à un référentiel pour s'assurer du contrôle des opérations informatiques et de leur
MIAGE 2006


Page 31

pérennité. Il est à préciser que les procédures doivent préciser les champs
d'application, les acteurs, les tâches, les documents utilisés et les contrôles à
entreprendre (y compris certains modes opératoires).
Les procédures qui doivent être envisagées concernent :
● les opérations d'exploitation informatique (consignes d'exploitation, suivi de la
production, identification des anomalies, mise en production de programmes,
gestion des sauvegardes, etc…)
● les procédures de développement et de maintenance (processus de
validation des demandes utilisateurs, développement d'applications et
documentation des analyses et des manuels, gestion des maintenances,
etc…),
● les procédures d'administration de la sécurité (création - modification suppression de profils et de droits,

identification et suivi des incidents de

sécurité, revue des sécurités systèmes et applicatives, etc…).

MIAGE 2006


Page 32

B - AUDIT DE L’ARCHITECTURE RESEAU
Comme le précisait les termes de références, Il s’agit de procéder à une analyse
très fine de l’infrastructure réseau du système d’information touchant le
paramétrage et la configuration des équipements et logiciels de filtrage, de
détection et de refoulement mis en place.
Etape1 : prise de connaissance générale
Nous avons pris des rendez-vous avec quelques responsables Directeur
informatique pour disposer de l’architecture réseau de la banque. De cet
entretien il ressort que le réseau de la banque se présente de la manière suivante :
3 sous réseaux de classe C (192.168.1.0, 192.168.2.0, 192.168.3.0)
Le réseau 192.168.1.0 : réseau Front office, constitué des poste de guichet et autre
postes de commercial. Il se connecte au réseau 192.168.2.0 (réseau back-office)
par l’intermédiaire d’un routeur « DLink DI-614 ». Ce réseau abrite le progiciel « Delta
Bank » spécialisé dans la gestion des banques commerciales.

Le réseau 192.168.3.0 (réseau étude) quant à lui est dédié à la formation et aux
tests des différentes applications avant la mise en production.
Un routeur AGS+ relie la banque à Internet avec des règles bien définies.
Matériel


8 switchs CISCO 10/100 Mbps



3 routeurs
− 1 CISCO
− 2 DLink (DI-604 et DI-614)



Une baie de brassage

Logiciel


Un logiciel antivirus



Un logiciel de vidéo surveillance



Le logiciel ISA de Microsoft

MIAGE 2006


Page 33

2. Etape2 : Prise de connaissance du PSS
Nous nous sommes entretenus avec le Directeur Informatique (DI) pour apprécier
la stratégie de la banque en matière de sécurité informatique. Pendant cet
entretien, nous avons

rempli le questionnaire d’identification des risques

informatiques.
Nous avons enfin procédé à l’examen de la configuration de quelques
équipements.
3. Etape 3 : appréciation du dispositif de contrôle du risque informatique
Nous avons examiné tour à tour :

● la configuration du routeur CISCO AGS+
● la configuration du routeur DLink DI -614
● la configuration du serveur ISA
● la configuration du serveur antivirus TrendMicro Officescan Corporate V. 7.0
3.1 Examen de la configuration du routeur AGS+
Rappelons que le routeur AGS+ a pour principale fonction de gérer les connexions
Internet initiées à partir de la banque. Pour cette raison, la connaissance de la
configuration du réseau interne et externe est fondamentale.
Les différentes règles à implémenter sont les suivantes :
● Toutes les machines doivent pouvoir aller sur Internet sauf celles du
reseau192.168.1.0
● Toutes les requêtes provenant d’Internet doivent être redirigé sur le port 80 du
serveur de e-banking (192.168.2.45)
● Aucune autre machine ne doit pouvoir se connecter à Internet
Il s’agit des règles qu’on devrait retrouver en principe dans le fichier de
configuration du routeur CISCO AGS+.
Dans la configuration actuelle du routeur, nous avons identifiés quelques
instructions qui montrent que la configuration du routeur n’est pas en adéquation
avec les règles éditées par la Direction informatique.
MIAGE 2006


Page 34

####################################################
no routing ip
ip route 192.168.0.0 255.255.255.0 195.93.33.233
####################################################
Explication :
no routing ip désactive le routage sur le routeur .
Dans cette configuration, il est impossible que les machines puissent aller sur
internet.
ip route 192.168.0.0 255 .255.255.0 195.93.33.233
Cette règle spécifie que toutes les hôtes d’un réseau de classe C « 192.168.0.0 »
doivent pouvoir traverser le routeur.
Dans l’hypothèse ou le routage était activé, le routeur devrait laisser traverser
toutes les machines de la classe C, et donc un véritable relais internet.
3.2 Examen de la configuration du routeur DLink DI-614
Il s’agit d’un routeur utilisant la technologie wifi (réseau sans fil)
Le service d’accès distant est activé sur ce routeur et lorsqu’un examine sa
configuration, on se rend compte qu’aucune disposition de contrôle d’accès au
réseau n’est activée. En outre, le service DHCP est activé dessus.
Dans cette configuration, n’importe quel client DHCP, peut obtenir du routeur une
adresse ip et infiltrer le réseau de la banque, notamment accéder à la base de
données des clients et comptes.
Nous avons exploité cette faille pour obtenir une connexion sur la base de
données du site central à partir d’un café situé à 100 mètres de la banque. Il nous
a suffi tout simplement d’activer la carte wifi de notre portable en mode client
DHCP et quelques temps après, nous avons reçu une adresse ce qui nous a permis
de nous connecter sur la base de données de la banque.
Le service de contrôle d’accès par filtrage au niveau IP et MAC n’est pas activé.

MIAGE 2006


Page 35

3.3 Examen de la configuration du serveur ISA
Le serveur ISA est utilisé pour rationaliser et sécuriser le trafic internet. Pour cette
raison, il se place entre le routeur et le réseau interne.
Pendant nos travaux, nous avons constaté que les modules suivants n’étaient pas
correctement configurés:
● Inspecteur d’état
● Filtre des paquets
● Détecteur d’intrusion
● Cache web
3.4 Examen de la configuration du serveur d’antivirus TrendMicro Officescan
Corporate V. 7.0
Les clients TrendMicro ne sont pas bien configurés dans l’ensemble. Pour la
plupart, la stratégie de mise à jour n’est pas précisée.
Au niveau du serveur, le live update est activé pour aller rechercher les mises à
jour sur Internet et distribuer sur les machines du réseau interne.
4. Etape 4 : Les principaux constats et recommandations
4.1 Les constats
● Configuration arbitraire du Routeur Cisco AGS+
La configuration du routeur Cisco AGS+ n’est pas conforme avec les règles de
sécurité définies au niveau de la Direction Informatique. En effet, les règles de
sécurité retenues précisent que seules les machines du réseau 192.168.2.0 et
192.168.3.0 doivent pouvoir aller sur internet. Il s’agit du réseau back office et le
réseau étude. Or, les règles implémentées dans l’AGS+ autorisent tous les paquets
issus d’un réseau de la classe C à traverser le routeur et d’aller sur Internet, par
conséquent, toues les hôtes du réseau front office, back office et étude peuvent
aller sur Internet dans une telle configuration.

MIAGE 2006


Page 36

● Blocage du service de routage sur l’AGS+
L’instruction « no routing ip » dans le fichier de configuration du routeur spécifie
que le routage des paquets IP est désactivé, et par conséquent, l’AGS+ ne peut
pas router les paquets IP qui lui sont envoyé.
● Configuration du routeur DLink DI-614 n’intégrant pas la sécurité
L’examen de la configuration du routeur DLink DI-614 montre que la fonctionnalité
wifi est activée et qu’aucun dispositif n’est mis en place pour prémunir la banque
du wardriving. Il s’agit d’une technique qui consiste à scanner les réseaux WLAN
non sécurisés en circulant dans son voisinage avec du matériel préparer pour la
détection.
● Service ISA mal configuré
En examinant la configuration du serveur ISA, nous avons constaté que les services
essentiels de cette solution n’étaient pas mises en place et que pour celles qui
étaient mises en places, elles sont pour la plupart mal configurées.
il s’agit pour les services non configurés de :
● Inspecteur d’état
● Filtre des paquets
● Détecteur d’intrusion
● Cache web
Dans cette configuration, il est impossible de contrôler le flux des paquets IP vers et
depuis le serveur ISA, de détecter les intrusions dans le réseau par une alerte du
serveur ISA ou alors d’exploiter la fonctionnalité Proxy cache de ISA. En effet, ISA
peut aussi être utilisé comme un mandataire internet.
● planification inefficace de l’antivirus TrendMicro Officescan Corporate V. 7.0
La configuration actuelle de l’antivirus n’est pas optimale. Il apparaît dans sa
configuration actuelle plusieurs indicateurs tel que live update donc la
configuration n’est pas régulièrement revue.

MIAGE 2006


Page 37

4.2 Les recommandations
Au regard du nombre considérable de constats effectués au niveau de
l’architecture réseau de la banque, il est impératif de prendre dans un délai
raisonnable des dispositions appropriées.
● La redéfinition de l’architecture réseau
L’architecture réseau de la banque dans sa configuration actuelle doit être revue.
Étant donné que certains services de la banque doivent être accessible de
l’extérieur de la banque, il nous semble indiqué une architecture de sous réseau
en DMZ. Cette architecture permet de sécuriser fortement le réseau avec des
moyens simples (filtrage principalement) en imposant un chemin précis aux
différents flux.

Elle permettra en outre de limiter les dégâts consécutifs à une

intrusion en limitant au maximum la capacité d’actions de l’intrus, mais aussi
l’utilisation de nos ressources pour attaquer un autre réseau (attaque du milieu).
Le réseau formation

sera adressé en DHCP pour faciliter l’administration tant

disque celui du front office et du back office sera en adressage statique car étant
considéré comme critique et au regard aussi du nombre réduit d’hôte qui le
constituent.
● La reconfiguration des différents routeurs
Les routeurs DLink DI-614 et CISCO AGS+ doivent être reconfigurés. En prélude à
ce travail, il est impératif de définir l’ensemble des règles à implémenter sur
chaque routeur. Ces règles correspondent aux trafics envisagés.

Pour ce qui est du routeur DLink DI-614, il faudra impérativement :
-

désactiver la diffusion du SSID et activer le masquage du SSID,

-

changer les paramètres par défaut du routeur (le SSID, les mots de passe,
l’adresse IP etc.),

-

activer le contrôle d’accès au niveau MAC et IP (le mieux est d’activer
les deux),

MIAGE 2006


Page 38

-

activer le chiffrement (de 128- ou de 256-bits),

-

éviter l’utilisation des clés secrètes WEP faciles à deviner,

-

vérifier si les employés n’installent pas des Access Point sans autorisation,

-

sécuriser le routeur contre un accès physique

● La reconfiguration du serveur ISA
Le serveur ISA doit être impérativement reconfiguré pour intégrer la nouvelle
stratégie en matière de sécurité informatique dans la banque. Dans sa nouvelle
configuration, tout comme pour les routeurs, il est indispensable de définir le trafic
souhaité et donc de formuler les règles appropriés. Pour les services inutiles, il
faudra impérativement les désactiver en bloquant les ports appropriés.
Après la configuration du serveur ISA, il faudra déployer le client ISA (client firewall)
sur toutes les machines de la banque.
Dans un souci de rationaliser la consommation de la bande passante, il faudra
définir des groupes et des plages horaires pour gérer la convexion à Internet. Nous
avons identifiés quelques scénarios qui peuvent être retenus pour la configuration
d’ISA Server 2000
● Activer le filtrage dynamique de paquets et la détection des intrusions pour
tous les types d’attaques reconnues par ISA Server.
● Paramétrer des alertes en cas d’intrusion (mail à l’administrateur)
● Activer les filtres d’applications de données, comme le filtre SMTP
● Configuration des stratégies d’accès à Internet
● Configurations des clients ISA


Configuration des clients Proxy



Configuration des clients SecureNAT



Configuration des clients Firewall

Avec cette configuration, il sera introduit une couche réseau supplémentaire sur le
réseau de la banque qui

augmente le niveau de sécurité. En outre les

applications gourmandes en bande passante seront inopérantes car bloquées.
MIAGE 2006


Page 39

De même, les horaires d’accès à Internet seront définies se qui permettra de
libérer la bande passante pendant les heures de production. Les applications
comme le SWIFT et le hotline seront prioritaires.
La détection d’intrusion permettra d’identifier les attaques sur le système et alerter
l’administrateur par message électronique ou par le déclenchement d’un autre
processus qui peut soit arrêter le système ou certains services. Ceci permettra à
l’administrateur d’être informé des nouveaux types d’attaques et d’envisager des
solutions adéquates en temps réel.
Le cache Web intégré dans le serveur ISA procurera un temps réponse aux
requêtes HTTP plus rapide et des économies de la bande passante réseau.
● La revue des mises à jour de l’antivirus TrendMicro Officescan Corporate V. 7.0
La planification des mises à jour de cet antivirus étant manifestement inefficace, il
convient de la revoir et de définir une périodicité pour la vérification des
fonctionnalités du module de mise à jour du serveur. Enfin, il faudra uniformiser la
méthode de mise à jour sur tous les postes clients en indiquant que le serveur de
mise à jour est le 192.168.2.46 (serveur antivirus)

MIAGE 2006


Page 40

C - AUDIT DE LA BASE DE DONNEES DES CLIENTS
EXAMEN DE LA BASE DE DONNEES
1. L’existant
Dans cette phase, nous avons regroupé les étapes une à trois en une seule. Elle a
consisté à la prise de connaissance de l’environnement.
Il ressort des différents entretiens que la base de données à examiner se trouve sur
un serveur ayant les caractéristiques suivantes :
● OS

: AIX 4.3

● SGBDR

: INFORMIX IDS 7.4

● APPLICATION

: PROGICIEL DELTA BANK V 7.4.4

2. Démarche
Précisons qu’il s’agissait du serveur de production de la banque.
Comme le précisait les termes de références, il faut examiner les tables client et
compte du site central et donc de la production.
Conscient qu’en travaillant directement sur la production on pourrait augmenter
la charge du serveur et ralentir la vitesse de traitement, nous avons effectué une
copie de la base de données de production que nous avons installé sur le serveur
de test pour disposer d’un environnement identique à celui de la production.
Nous avons ensuite commencé l’exécution des requêtes sur la base de donnés du
site central.
Nous avons enfin procédé à la revue de quelques dossiers physique des clients.

MIAGE 2006


Page 41

3. les constats
En examinant la base de données du site central, nous avons fait les constats
suivants :
● Des clients sur la base de données du site central sans secteur d’activité
L’un des paramètres utilisés par les interlocuteurs des établissement de crédit
(BEAC, COBAC, CNC, …) est le secteur d’activité de la clientèle.

Cette

information est d’autant plus importante que la BEAC a défini un ensemble de
secteur d’activité (table des secteurs d’activité BEAC) permettant lors de la
création d’un client dans une banque de le rattacher systématiquement à un
secteur d’activité.
En exécutant la requête de sélection des clients, secteur d’activité et
nationalité BEAC, nous avons fait les constats suivants :
● 6 200 clients sur 16 121 soit 38.58% dont la zone secteur d’activité n’est pas
renseignée ;
● certaines entreprises privées nationales sont classés dans le secteur
d’activité « particulier »; c’est notamment le cas du client CONST/BTP,
entreprise bien connue dans la banque ;
● des administrations publiques nationales et étrangères sont classées dans le
secteur d’activité « particulier ». C’est notamment l’ambassade du Nigeria
et l’ambassade du Tchad au Burkina Faso.
Au regard de ces cas identifiés, il apparaît que l’affectation des clients à un
secteur d’activité n’a pas répondu au dispositif réglementaire tel que prévu par
la BEAC

MIAGE 2006


● Certains codes et libellés catégories BEAC de l’agence ZETA non- conformes
au dispositif règlementaire BEAC
L’un des critères de ventilation des opérations avec la clientèle est la catégorie
banque centrale. Il s’agit donc d’une information d’une importance capitale
pour une confection optimale du CERBER.
Dans l’optique d’uniformiser les différentes catégories BEAC, la BEAC a conçu
une tableau de deux colonnes (code et libellé) reprenant sur chaque ligne le
code et la catégorie BEAC associée. Il est précisé que chaque code est
systématiquement rattaché à une et une seule catégorie.
Or la revue de la table catégorie BEAC de la base de données de l’agence de
N’djamena obtenue par extraction informatique fait ressortir :
● la catégorie BEAC « ADMINSTRATION PUBLIQUE » ne figure pas dans la table
des catégories communiquée par la BEAC, bien que enregistrée en double
« code 2111 et 2112 » dans la table catégorie BEAC de la Banque.
● les

catégories

BEAC

« ADMINSITRATION

PUBLIQUE

CENTRALE »

et

« ADMINISTRATION PUBLIQUE LOCALE » n’existent pas dans la table des
catégories BEAC de l’agence ZETE.
Au regard de ce qui précède, Il y a lieu de s’interroger sur la confection du
CERBER dans la mesure où il nous emble que l’un des critères de ventilation des
informations dans les états CERBER est bien la catégorie BEAC.
● Certaines informations de la

base de données du site central divergent de

celles des agences.
Après les mises à jour effectuées sur la base de données du site central par le
secrétariat des engagements au mois d’octobre 2005, un travail de vérification
a été fait par le CTI à la demande du Contrôle Général.

MIAGE 2006


Page 43

A ce propos, des requêtes de sélection des attributs catégorie BEAC, forme
juridique, code intitulé et groupe d’activité ont été exécutées sur les tables des
clients aussi bien en agence que sur le site central.
En analysant les résultats des requêtes conçues lors de ces travaux, il ressort
que certaines informations sur le site central sont différentes de celles se trouvant
en agence bien que portant sur les mêmes clients
Le cas le plus significatif porte sur l’attribut groupe d’activité où nous relevons :
● 71,38 % de clients de ZETA
● 29% de clients de BETA
● 35% de clients de SIGMA
● 36 % de clients de GAMA
qui ont des attributs groupe d’activité différent de ceux du site central.
En conséquence, il apparaît que les données entres les agences et le site central
ne sont pas systématiquement cohérentes, comme indiquées dans le tableau cidessous.
ZETA
CAT BEAC
GESTIONNAIRE
IND STAT
FORMR JURIDIQUE
INTITULE
GROUPE D'ACTIVITE
LIEU NAISSANCE
ANNEE NAISSANCE

0,01%
1,43%
0,03%
0,35%
0,03%
71,38%
0
0

BETA
SIGMA
GAMA
1,72%
5,23%
0,14%
9,58%
19,77%
11,85%
46,35%
66,69%
2,54%
1,46%
0,83%
0
1,20%
0
0
79,56%
87,54%
54,58%
69,56%
70,39%
42,60%
58,67%
2,99%
36,53%

Examen de quelques dossiers physiques
o LEVEL BANK INTERNATIONAL S.A
La revue du dossier d’ouverture de compte du client LEVEL BANK INTERNATIONAL
S.A indique qu’il s’agit d’une banque en création.

MIAGE 2006


-

Page 44

L’ouverture du compte d’une banque en formation suppose du point de vue
de la profession bancaire :
● un questionnaire anti blanchiment, ce qui ne figure pas dans le dossier,
● un agrément, ce dont nous ne disposons pas,
● un récepicé de dépôt de dossier à la BEAC

-

S’agissant d’une banque, le chapitre « 371 » dans lequel son compte est logé
n’est pas approprié. Dans l’hypothèse d’une société en formation fusse-t-elle
une banque, son compte devrait être ouvert dans le chapitre « 374 ».

-

S’agissant d’une société en formation, le compte est ouvert pour souscrire au
capital de la société en création. Les consultations auprès du département
juridique et contentieux indiquent du point de vue juridique, l’article 393 de
l’acte uniforme portant sur les sociétés commerciales et GIE stipule que « les
fonds provenant de la souscription des actions en numéraire sont déposés par
les personnes qui les ont reçus, pour le compte de la société en formation, soit
chez un notaire, soit dans une banque domiciliée dans l’Etat partie du siège de
la société en formation, sur un compte spécial ouvert au nom de cette
société… » Par ailleurs, l’article 398 de l’acte uniforme de l’OHADA sur les
sociétés et GIE dispose que « le retrait des fonds provenant des souscriptions en
numéraires ne peut avoir lieu qu’après l’immatriculation de la société au
registre de commerce… »

et par conséquent il est bloqué jusqu’à la

constitution effective de la société. Or, nous constatons qu’un chéquier a été
délivré et une opération de retrait effectuée.
-

Au vue du dossier, l’on note l’absence des fiches de mise à jour client et
compte, pire encore le carton de signature n’est ni visé du chef d’agence,
moins encore du chef de guichet.

Au regard de tout ce qui précède, il apparaît que l’ouverture de ce compte ne
s’est pas déroulé dans des conditions satisfaisantes.

MIAGE 2006


o COMPAGNIE WALLEM POUR LE TRANSPORT
Il s’agirait d’une société en formation. Seules figurent dans ce dossier une
demande manuscrite signée probablement du gérant et une copie de sa pièce
d’identité. Cette demande est bien visée par le chef d’agence et le gestionnaire.
La fiche d’ouverture de compte n’est même pas remplie, seuls figurent le numéro
du compte et le nom du client. Aucune signature des mandataires sociaux n’y
figure.
Cependant, on constate des mouvements sur le compte, et un crédit moyen
terme à concurrence de FCFA 100 millions qui à été consenti à ce client.
S’il s’agissait effectivement d’une société en création, les remarques portant sur le
cas LEVEL BANK INTERNATIONAL lui serait applicable. En tout état de cause, cette
situation regorge de nombreux facteurs de risques et constitue une entorse à la
procédure d’ouverture de compte.

4. Les recommandations
Au regard du nombre important des anomalies et des incohérences constatées
dans la base des données client et compte, il est impératif de prendre dans les
plus brefs délais, un certain nombre de dispositions :


Améliorer les procédures existantes

Repréciser

les

procédures

sur

certains

aspects,

renforcer

les

contrôles

hiérarchiques après les saisies ainsi que le contrôle du service administratif et
financier portant sur les attributs comptables. Il est indispensable que ces
procédures soient strictement appliquées et la vérification de leur application
dans le cadre d’un contrôle permanent.


Correction des anomalies

Procéder à la correction de toutes les anomalies issues des requêtes. Ces
corrections auront pour effet immédiat d’améliorer la qualité des reporting
(CERBER, centrale de risques, etc.)
MIAGE 2006


Page 46

A cet effet, il est indiqué de constituer une TASK FORCE pour procéder aux
corrections des anomalies et incohérences identifiées. Il s’agira entre autre de
procéder à la mise à jour de la table catégorie banque centrale à l’agence de
GAMA et SIGMA à partir de celle du site central.


Instruire une mission d’audit par la Direction d’Audit Interne

Fort de ces insuffisances, nous recommandons d’étendre le champ d’investigation
de la revue des dossiers physiques par l’instruction d’une mission de contrôle
portant de manière générale sur tous les dossiers d’ouverture de compte. Cette
mission dont le champ d’investigation devrait couvrir tout le réseau de « BANK
AFRICA » aura notamment pour objectif de :
-

vérifier le contenu des dossiers

-

s’assurer de la nature des informations qui y figurent

-

s’assurer de la compatibilité de ces informations par rapport aux bases
de données

-

procéder à un audit complet des bases de données du site central et
des différentes agences pour détecter toutes les anomalies et
d’appliquer les corrections nécessaires avant d’envisager le passage en
système centralisé.

Par ailleurs, nous suggérons qu’il soit procédé à la fiabilisation de la base de
données des agences et du site central et qu’après chaque opération de
migration informatique, qu’il soit mis en oeuvre un test substantif permettant de
s’assurer que la base de données du site central est la « résultante » de celle des
différentes agences.


Renforcer les contrôles bloquants dans Delta Bank

Il serait judicieux de passer en revue les différents écrans de mise à jour clients/
compte (environ 7 écrans) afin d’identifier les champs obligatoires et optionnels
pour instaurer des contrôles bloquant supplémentaires.


Suivi

Instaurer les mécanismes de suivi (chef de guichet, chef d’agence, responsable
administratif et financier et contrôle général).

MIAGE 2006


Page 47

CONSLUSION
Au terme de nos travaux réalisés à Universal Consulting portant sur « la pratique
de l’audit informatique dans les banques », nous espérons avoir apporté notre
modeste contribution à une meilleure compréhension de ce sujet, de plus en plus
d’actualité.
Conscient de l’importance du sujet, nous avons d’abord dans une première partie
présenter l’ensemble des outils théoriques pour la pratique de l’audit informatique
dans une banque et dans une deuxième, nous avons mis en exergue ces outils et
technique dans le cadre de l’audit informatique de BANK AFRICA.
A la fin des travaux, il faut souligner que la démarche proposée devrait être
actualisée avec l’évolution de l’informatique ce qui rendra de plus en plus
spécifique la pratique de l’audit informatique dans les banques.

MIAGE 2006


PARTIE III: ANNEXE

MIAGE 2006

Page 47


QUESTIONNAIRE DES RISQUES INFORMATIQUES
1) Appréciation générale de la sécurité de l’entreprise
Question A: Votre établissement est-il sensible aux risques (et aux conséquences) liées à
l'informatique ?
Observation :

Réponse  Oui

 Non

Question B: Pour vous, l’informatique est-elle un facteur stratégique de pérennité et de
développement de votre activité ?
Observation :

Réponse  Oui

 Non

Question C : connaissez-vous des méthodes d’évaluation des risques informatiques (MEHARI,
MARION)?
Observation :

Réponse  Oui

 Non

Question D: Au cours des 3 dernières années, votre établissement a-t-il subi un préjudice,
conséquence
'un dommage informatique (accident matériel ou applicatif, erreurs ou
malveillance) ?

Observation :

Réponse  Oui

 Non

2) Organisation générale
Question 1: Existe-t-il un Comité Permanent chargé des problèmes liés à la sécurité, composé de
représentants de la Direction Générale, de la Direction de l'Organisation et de l'Informatique, de
représentants des fonctions utilisateurs, audit interne, juridique et assurances se réunissant au
moins 4 fois par an ?
Observation :

Réponse  Oui

 Non

Question 2: Y-a-t-il eu une étude sur la vulnérabilité de l'entreprise face à différents risques
physiques ou non physiques incluant le risque informatique au cours des 3 dernières années,
donnant lieu à un rapport écrit ?
MIAGE 2006


Observation :

Réponse  Oui

 Non

Question 3: Cette étude a-t-elle entraîné la mise en place d'un Plan de Sauvegarde de
l'entreprise (mesures conservatoires incluant celles financières) ?

Observation :

Réponse  Oui

 Non

Question 4: La fonction "Sécurité informatique" dispose-t-elle d'un poste spécifique sur
l'organigramme avec un rattachement hiérarchique élevé assorti d'une définition de poste
précisant les responsabilités et l'affectation d'un budget spécifique ?

Observation :

Réponse  Oui

 Non

Question 5: Y-a-t-il un responsable de la Sécurité Générale (bâtiments, environnement, accès) ?
Observation :

Réponse  Oui

 Non

Question 6: Le choix des garanties des polices d'assurances en matière informatique est-il le
résultat d'une étude spécifique conduite en commun avec la Direction de l'Informatique ?
Observation :

Réponse  Oui

 Non

Question 7: Le(s) Système(s) Informatique(s) est-il couvert par un contrat incluant :
-

les dommages matériels,
la reconstitution des médias,
d'autres contrats liés au précédent (Globale Informatique, Spécifique
détournement, Multirisques professionnelles) ?

Observation :

Réponse  Oui

 Non

Question 8: Existe-t-il un "propriétaire des informations" par fonction, responsable de l'évaluation,
de la définition et la révision périodique des règles, et des procédures et autorisations d'utilisation
des informations ?
Observation :
MIAGE 2006

Réponse  Oui

 Non


Question 9: Y-a-t-il une étude particulière, lors de la conception des applications, sur le choix des
contrôles automatisés et utilisateurs en amont et en aval de l'informatique ?

Observation :

Réponse  Oui

 Non

Question 10: Cette étude prend-elle en compte les critères d'analyse et de réduction des risques
issus d'informations ou de traitements classés comme stratégiques ?

Observation :

Réponse  Oui

 Non

Question 11: Y-a-t-il une analyse des comptes comptables sensibles au moins 2 fois par an, les
résultats étant consignés dans un rapport ?

Observation :

Réponse  Oui

 Non

Question 12: Existe-t-il un règlement écrit précisant les responsabilités des personnes et la
procédure de signature selon le type de document traité ?

Observation :

Réponse  Oui

 Non

Question 13: A-t-on pris en compte la possibilité de destruction d'informations stratégiques sur
support informatique et en a-t-on déduit des procédures systématiques de rétention des
documents de base qui pourrait servir à leur reconstitution ?

Observation :

Réponse  Oui

 Non

Question 14: S'il existe un service d'Audit interne, a-t-il des compétences pour exercer le contrôle
de la fonction informatique ?
Observation :
MIAGE 2006

Réponse  Oui

 Non


3) Protection incendie
Question 15: Pour le bâtiment renfermant des locaux informatiques et administratifs, y a-t-il eu une
étude spécifique du risque incendie prenant en compte les aspects protection et prévention
avec un suivi des recommandations prescrites ?
Réponse  Oui

Observation :

 Non

4) Dégâts des eaux
Question 16: Y a-t-il eu des études contrôlées périodiquement (suivies d'effets) par un organisme
spécialisé sur les dangers présentés par l'eau sur les salles des ordinateurs et les matériels
d'environnement ?
Réponse  Oui

Observation :

 Non

5) Amélioration de la fiabilité de fonctionnement
Question 17: Y a-t-il un système complémentaire (groupe électrogène) et un système de
régulation (onduleur) de l'alimentation électrique ?

Observation :

Réponse  Oui

 Non

Question 18: Y a-t-il une redondance réelle locale des unités centrales des ordinateurs et des
organes stratégiques (contrôleurs) et repose-t-elle sur un plan de basculement écrit ?

Observation :

Réponse  Oui

 Non

Question 19: Dans le cas d'un sauvetage exhaustif de toutes les applications a-t-on étudié les
besoins globaux, la planification de la charge et les contraintes techniques et organisationnelles
?
Réponse  Oui
Observation :

MIAGE 2006

 Non


6) Procédures de secours
Question 19: Existe-t-il un plan de sauvetage total des données et programmes vitales pour
l’entreprise ?
Réponse  Oui
 Non
Observation :

Question 20: Dans le cas d'un sauvetage partiel ou en mode dégradé, a-t-on étudié le choix des
applications à reprendre en fonction de leur degré stratégique ?
Réponse  Oui

 Non

Observation :

7) Le personnel informatique
Question 21: La formation du personnel informatique (hors saisie de données), en moyenne sur les
3 dernières années, est-elle supérieure à 5 jours par an et par personne ?
Réponse  Oui

 Non

Observation :

Question 21: Y a-t-il une répartition, un contrôle et un suivi des tâches stratégiques et/ou
confidentielles ?
Observation :

Réponse  Oui

MIAGE 2006

 Non


Page 53

THEMES DE REFERENCES DE LA MISSION D’AUDIT
ARTICLE 1 - OBJET DE LA CONSULTATION OU APPEL D’OFFRE
Le Maître d’Ouvrage se propose de lancer une consultation ou appel d’offre pour
l’audit sécurité de systèmes d’information et de communication de la banque.
La mission d’audit objet de cette consultation ou appel d’offre devra concerner
aussi bien les aspects physiques et organisationnels que les aspects informationnels
des systèmes d’information et de communication. Cette mission devra donc cibler
tous les aspects touchant à la sécurité des systèmes d’information et des réseaux
de communication véhiculant ces informations.
Plus précisément, cette mission devra couvrir les aspects de contrôle d’accès à
l’information et aux réseaux. Elle devra évaluer, suite à des simulations et des essais
réels, la vulnérabilité des mécanismes et des outils matériels et logiciels de
protection contre toutes les formes de fraude et d’attaques connues par les
spécialistes du domaine au moment où l’audit est conduit. L’on cite à titre
d’exemples : les intrusions, les attaques virales, les infiltrations, les fausses identités
et les dénis de service. L’audit devra également évaluer la fiabilité des
mécanismes d’authentification des usagers.
Il devra comprendre, sans se limiter aux aspects suivants :
La politique de sécurité,
La protection contre les virus,
La protection contre les intrusions,
La journalisation des évènements,
La gestion de comptes et des mots de passe,
La configuration des pare-feu (Firewall),
Le chiffrement,
L’authentification,
Le plan de secours ou de continuité.
MIAGE 2006


La mission d’audit objet de cette consultation ou appel d’offre devra donc
aboutir à une évaluation précise des mécanismes et outils de sécurité
présentement implémentés dans les systèmes audités dans le cadre de ce
marché Elle devra indiquer clairement et sans équivoque toutes les failles de
sécurité recensées à l’issue de l’audit et proposer une solution de sécurité tout en
indiquant clairement les actions et les mesures à entreprendre en vue d’assurer la
sécurisation de l’ensemble des systèmes d’information audités aussi bien sur le
plan physique (sécurité de l’environnement) que sur les plans organisationnel
(procédures d’exploitation, structures administratives dédiées à la sécurité, suivi et
pilotage internes, etc.) et informationnel (logiciels et équipements réseaux
spécifiques à la sécurité, dispositifs et accessoires, etc).
ARTICLE 2 - ETENDUE DU TRAVAIL
Cette

consultation

ou

appel

d’offre

concerne

des

prestations

d’audit

sanctionnées par un ou plusieurs rapports dans lesquels on présentera
Une évaluation de la vulnérabilité du système d’information audité. L’évaluation
sera sanctionnée par un état exhaustif des failles et des anomalies décelées ;
Les

recommandations

à

suivre

pour

pallier

les

en

œuvre

insuffisances

établies

précédemment ;
Une

proposition

de

solution

à

mettre

conformément

aux

recommandations préétablies.
Les systèmes d’information avec toutes leurs composantes, y compris les aspects
de contrôle d’accès, de sauvegarde des données, de la continuité de service,
des fraudes internes et tout autre aspect touchant à la sécurité du système.
Le réseau de communication au travers duquel le système d’information est
accessible .
Partant du principe que la sécurité est d’abord une question d’organisation, la
mission d’audit devra approfondir cet aspect et relever toutes les failles
organisationnelles quant à l’existence ou pas : de plan de sécurité, d’une structure
chargée de la sécurité informatique, d’une charte comportant des consignes de
sécurité pour les usagers, et de guides de sécurité.
MIAGE 2006


Page 55

Elle devra également couvrir les aspects d’architecture, de configuration et de
technologies réseau. Ces aspects, ayant un impact direct sur la sécurité, devront
être étudiés, évalués et consignés dans le rapport d’audit. Les risques menaçant
la pérennité de l’activité de la structure devront être précisées et justifiés dans le
rapport d’audit.
Dans une seconde phase, la mission d’audit devra s’orienter vers le système
d’information proprement dit. Cette partie de l’audit devra aboutir à une
évaluation des mécanismes implémentés dans le système d’information pour le
contrôle d’accès, l’identification et l’authentification des utilisateurs dans l’objectif
de détecter les sources potentielles de fraudes informatiques et les vulnérabilités
du système d’information
ARTICLE 3 - TRAVAIL DEMANDE
Les prestations d’audit objet de cette consultation ou appel d’offre couvriront
donc les aspects suivants :
A. L’organisation
B. L’architecture du réseau
C. Le système d’information
Le rapport d’audit devra couvrir ces aspects. Ce rapport devra être élaboré sur la
base d’études de terrain. Le personnel d’audit devra se déplacer sur les lieux de la
structure à auditer et procéder à des tests réels sans mettre en cause la continuité
du service du système audité et ce en vue de dégager les écarts entre les
procédures de sécurité supposées être appliquées et celles réellement en
application.
L’adjudicataire devra solliciter auprès de la structure à auditer toute information
rendue nécessaire pour l’exercice de sa mission. En cas de difficulté il pourra faire
recours au Maître d’Ouvrage. Ce recours devra être formulé par écrit et en temps
opportun pour permettre au Maître d’Ouvrage d’intervenir efficacement.
ARTICLE 4 - AUDIT ORGANISATION

MIAGE 2006


Il s’agit, pour ce volet, d’évaluer la politique de sécurité de la structure objet de
l’audit et de proposer les recommandations adéquates pour la mise en place
d’une politique sécuritaire de pointe. On s’intéressera aussi bien à la sécurité
logique que physique du système d’information et de communication.
ARTICLE 5 - AUDIT ARCHITECTURE
Ce volet concerne l’audit de l’architecture réseau. Il s’agit de procéder à une
analyse très fine de l’infrastructure réseau du système d’information touchant le
paramétrage et la configuration des équipements et logiciels de filtrage, de
détection et de refoulement mis en place. Cette analyse devra faire apparaître le
résultat des tentatives d’intrusion, de contamination par des virus, de fraude,
d’accès illicites ou mal-intentionnées, et de toute autre forme d’attaque conduite
dans le cadre de cette mission.
ARTICLE 6 - AUDIT DE LA BASE DE DONNES
Ce volet concerne l’audit du système d’information proprement dit. La mission
d’audit devra comprendre des opérations de simulation d’attaques, d’intrusions,
de cracking (craquage) de mots de passe, de piratage et de vols d’informations.
Ceci dans l’objectif d’apprécier la robustesse du

système d’information et sa

capacité à préserver l’intégrité de ses bases de données. On entend par
robustesse, la capacité du système d’information à maintenir sa fonctionnalité
totale et à assurer aux usagers la disponibilité de tous les services avec des
performances acceptables.
Le rapport d’audit devra consigner le résultat de ces tentatives et présenter une
indication précise de l’impact des vulnérabilités recensées sur la confidentialité,
l’intégrité et la sûreté du fonctionnement du système d’information et la manière
de les combler.
ARTICLE 7 – METHODOLOGIE ET CONDUITE DU PROJET
Le soumissionnaire devra indiquer, clairement dans son offre, la méthodologie
d’audit envisagée. Le Maître d’Ouvrage tiendra compte dans son évaluation de

MIAGE 2006

DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

Similaire à DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE (20)

DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE