DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

MINISTERE DE L’ENSEIGNEMENT REPUBLIQUE DU CAMEROUN SUPERIEUR 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

Rédigé et présenté par : Hubal PFUMTCHUM

Sous l’encadrement

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

Professionnel 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

La pratique de l’audit informatique dans les banques Page

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

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.



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.



3

S O M M A I R E

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



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



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.



6

PARTIE I - DEMARCHE D’AUDIT INFORMATIQUE DANS LES BANQUES



7

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.



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 :



9

- 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 pour les logiciels (et les procédures

informatiques)



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 La couche logicielle d’un système informatique

DATA

(données)

LOGICIELS (applications)

OS

(système d’exploitation)

LOGICIEL

SYSTEMEEXTERNE

MATERIEL

Les données Ex : Message SWIFT MT100

Les applications Ex : Swift Access

Système d’exploitation Ex : UNIX AIX, Linux, Windows



11

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.



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;



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 :



14

- 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



15

veiller à donner 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



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



17

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



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.



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.



20

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



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



22

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.



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.



25

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



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.



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



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



29

- absence de cartographie des risques

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

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

- 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



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



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…).



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



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.



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



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.



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.



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),



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.



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)



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.



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



42

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



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 ci-

dessous.

ZETA BETA SIGMA GAMA CAT BEAC 0,01% 1,72% 5,23% 0,14% GESTIONNAIRE 1,43% 9,58% 19,77% 11,85% IND STAT 0,03% 46,35% 66,69% 2,54% FORMR JURIDIQUE 0,35% 1,46% 0,83% 0 INTITULE 0,03% 1,20% 0 0 GROUPE D'ACTIVITE 71,38% 79,56% 87,54% 54,58% LIEU NAISSANCE 0 69,56% 70,39% 42,60% ANNEE NAISSANCE 0 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.



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.



45

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



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



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.



47

PARTIE III: ANNEXE



48 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 ? Réponse Oui Non Observation :

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

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

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) ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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 ?



49

Réponse Oui Non Observation :

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) ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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

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 ? Réponse Oui Non Observation :

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) ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :



50

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 ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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é ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :



51

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 Non Observation :

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 Non Observation :

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 ? Réponse Oui Non Observation :

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 ? Réponse Oui Non Observation :

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 Non Observation :



52

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 ? Réponse Oui Non Observation :



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



54

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 insuffisances établies

précédemment ;

Une proposition de solution à mettre en œuvre 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é.



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



56

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



57

la consistance de la méthodologie proposée ainsi que des moyens techniques et

humains à déployer dans l’exercice de l’audit.

Le soumissionnaire devra indiquer, entre autre, les différentes phases de l’audit

qu’il envisage entreprendre au niveau de chaque structure. De même, il indiquera

les actions relatives à chaque phase.

La méthodologie adaptée devra aboutir à l’élaboration d’une solution sécurité

pour leS systèmes d’information et de communication audité.

ARTICLE 8 - DELIVRABLES

Les délivrables sont :

Un rapport d’audit couvrant les différents aspects cités à l’Article 3. Il devra

comprendre en particulier les sections suivantes :

Une section relative à l’audit organisationnel avec les recommandations sur la

politique sécurité existante de l’entreprise et les aspects d’organisation associés.

Au cas où la structure en question ne dispose pas de politique de sécurité, il est

demandé de lui proposer un plan de sécurité tenant compte des spécificités de

l’entreprise et des résultats de l’audit.

Une section relative à l’audit de l’architecture réseau indiquant les vulnérabilités

existantes, leur impact sur la pérennité du système d’information et de

communication de la structure et proposant des recommandations à l’effet

d’arriver à une architecture totalement sécurisée.

Une section relative à l’audit du système d’information recensant les vulnérabilités

relevées dans le dispositif de contrôle d’accès et de supervision de fraude

informatique. Tous les travaux de test et d’analyse devront être consignés. Le

rapport devra comprendre des recommandations précises quant aux mesures à

prendre à court et à moyen termes afin de pallier aux insuffisances constatées

dans le cadre d’une solution globale de sécurité.

Un rapport de synthèse qui contiendra :

● Un relevé exhaustif de toutes les insuffisances et faiblesses constatées ;

● Une proposition de solution englobant tous les aspects de sécurité ;



58

Les recommandations nécessaires à la mise en œuvre de la solution préconisée.



59

ARCHITECTURE DU RESEAU DE LA BANQUE AVANT L’AUDIT



60

ARCHITECTURE RESEAU PROPOSEE



61 SITES INTERNET ET BIBLIOGRAPHIE Sites Internet

1. . Http://www.acadys.fr

2. · Http:// www.sécurité-informatique.enligne-fr.com

3. · Http://banque-de-france.fr

4. · Http:// www.audit-informatique.fr

5. · Http:// www.bibliotique.org

6. · Http:// www.clusif.asso.fr

7. · Http:// www.afai.asso.fr

8. · Http:// www.audit.com

9. · Http:// www.itaudit.org

10. · Http:// www.isaca.org

11. · Http:// www.erp.com

12. · Http:// www.issa.org

13. · Http:// www.ibm.com

Bibliographie

1. Audit et contrôle interne bancaires, Antoine SARDI, Edition AFGES, juillet 2002

2. l’audit informatique de Marc THORING

3. Redhat Magazine

4. Journal login

5. UNIX shell, guide de formation TSOFT troisième tirage, avril 2000

6. le règlement COBAC R-2001/07

Technology

DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE