Beruflich Dokumente
Kultur Dokumente
LA PRATIQUE DE L’AUDIT
INFORMATIQUE DANS LES BANQUES
Académique Professionnel
AVERTISSEMENT
REMERCIEMENT
Nous aurions failli à la tradition si nous n’associons pas à ce travail des
remerciements à ceux qui ont contribué à sa réalisation.
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.
SOMMAIRE
AVERTISSEMENT ................................................................................................................................................................................................ 1
REMERCIEMENT ................................................................................................................................................................................................ 2
RESUME ............................................................................................................................................................................................................. 5
I – INTRODUCTION ........................................................................................................................................................................................... 7
PARTIE II : MISE EN ŒUVRE DE LA DEMARCHE POUR L’AUDIT DU SYSTEME INFORMATIQUE DE BANK AFRICA ................................ 25
1. L’existant ....................................................................................................................................................................... 40
2. Démarche ....................................................................................................................................................................... 40
CONSLUSION .................................................................................................................................................................................................. 47
RESUME
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.
I – INTRODUCTION
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.
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 :
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.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)
MATERIEL LOGICIEL
SYSTEME
EXTERNE
OS
(système Système d’exploitation
Ex : UNIX AIX, Linux, Windows
d’exploitation)
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 :
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.
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.
Prise de connaissance
générale
Appréciation du dispositif
de contrôle des risques
informatiques
Constats et
recommandations
Réunion de synthèse
avec la direction de la
banque
EXPLICITATION DE LA DEMARCHEPROPOSEE
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
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.
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
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.
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.
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.
Logiciel
Un logiciel antivirus
Un logiciel de vidéo surveillance
Le logiciel ISA de Microsoft
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.
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
####################################################
no routing ip
ip route 192.168.0.0 255.255.255.0 195.93.33.233
####################################################
Explication :
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.
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
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.
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.
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
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.
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 :
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.
- 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 ».
- 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.
4. Les recommandations
Suivi
Instaurer les mécanismes de suivi (chef de guichet, chef d’agence, responsable
administratif et financier et contrôle général).
CONSLUSION
Question A: Votre établissement est-il sensible aux risques (et aux conséquences) liées à
l'informatique ?
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) ?
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 ?
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 ?
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) ?
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 ?
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 ?
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 ?
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 ?
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é ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
?
Observation :
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 ?
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 ?
Observation :
Question 21: Y a-t-il une répartition, un contrôle et un suivi des tâches stratégiques et/ou
confidentielles ?
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.
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 8 - DELIVRABLES
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
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