DEMARCHE AUDIT INFORMATIQUE DANS UNE BANQUE - RAPPORT DE STAGE

  • 7,247 views
Uploaded on

Rapport de fin de formation MIAGE avec pour thème la pratique de l'audit informatique dans les banques

Rapport de fin de formation MIAGE avec pour thème la pratique de l'audit informatique dans les banques

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
7,247
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
447
Comments
2
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. MINISTERE DE L’ENSEIGNEMENT SUPERIEUR REPUBLIQUE DU CAMEROUN Paix – Travail – Patrie ---------------- --------- UNIVERSITE DE DOUALA ------------------FACULTE DES SCIENCES-MIAGE --------------- Mémoire de fin d’études pour l’obtention de la Maîtrise d’Informatique et du titre d’Ingénieur Maître MIAGE LA PRATIQUE DE L’AUDIT INFORMATIQUE DANS LES BANQUES Rédigé et présenté par : Hubal PFUMTCHUM Sous l’encadrement Académique Professionnel YVES SOSTS Enseignant à IRISA Spécialiste en intégration des solutions Marc KEOU NGASSA Expert comptable diplômé agrée CEMAC Associé - gérant de Universal Consulting Spécialiste de l’audit des Banques Année Académique 2004 - 2005
  • 2. La pratique de l’audit informatique dans les banques Page 1 AVERTISSEMENT Si les aspects techniques mentionnés dans ce rapport peuvent devenir obsolètes, les concepts fondamentaux abordés restent valides. Le lecteur pourra actualiser son information en consultant les sites Internet des éditeurs des différents produits répertoriés. Conformément aux usages, nous avons laissé en anglais un certain nombre de termes du langage technique. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 3. La pratique de l’audit informatique dans les banques Page 2 REMERCIEMENT Nous aurions failli à la tradition si nous n’associons pas à ce travail des remerciements à ceux qui ont contribué à sa réalisation. Nous remercions le Pr Maurice TCHUENTE pour l’idée qu’il a eu à initier le programme MIAGE. Notre remerciement va également à Mr Marc KEOU NGASSA, associé gérant de Universal Consulting pour son assistance tout au long des travaux et à monsieur YVES SOST pour ses commentaires. Nous sommes reconnaissant envers la faculté des sciences et l’ESSEC de l’université de Douala, les enseignants de l’Université de Rennes1 de l’IFSIC et d’IRISA en France. Nous avons une pensée favorable à tous ceux qui ont cru à notre jeune formation en donnant l’occasion aux étudiant MIAGE d’effectuer des stages dans leurs entreprises. Qu’ils en soient remerciés. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 4. La pratique de l’audit informatique dans les banques Page 3 SOMMAIRE AVERTISSEMENT ................................................................................................................................................................................................ 1 REMERCIEMENT ................................................................................................................................................................................................ 2 RESUME ............................................................................................................................................................................................................. 5 PARTIE I - DEMARCHE D’AUDIT INFORMATIQUE DANS LES BANQUES ..................................................................................................... 6 I – INTRODUCTION ........................................................................................................................................................................................... 7 II – LA PRATIQUE DE L’AUDIT ........................................................................................................................................................................... 8 2.1 Définition ......................................................................................................................................................................... 8 2.2 Les objectifs de l’audit ......................................................................................................................................................................... 8 III – L’AUDIT INFORMATQIUE ........................................................................................................................................................................... 8 3.1 Définition ......................................................................................................................................................................... 8 3.2 Le système informatique ......................................................................................................................................................................... 9 3.2.1 Définition .................................................................................................................................................................................. 9 3.2.2 Cartographie d’un système informatique ......................................................................................................................... 10 3.2.3 Les risques informatiques ..................................................................................................................................................... 11 VI – LA PRATIQUE DE L’AUDIT INFORMATIQUE DANS LES BANQUES ....................................................................................................... 11 4.1 L’informatique bancaire : l’apport des nouvelles technologies ..................................................................................................... 11 4.2 Les risques informatiques dans les banques ....................................................................................................................................... 12 4.2.1 Vol et diffusion non autorisée de données confidentielles.............................................................................................. 12 4.2.2 Erreurs ..................................................................................................................................................................................... 13 4.2.3 Fraudes .................................................................................................................................................................................. 13 4.2.4. Accidents "naturels" ............................................................................................................................................................. 15 4.2.5 Défaillance matérielle ou logicielle .................................................................................................................................... 15 4.2.6 Planification inefficace ....................................................................................................................................................... 16 4.2.7 Attaque et sabotage ........................................................................................................................................................... 18 4.3 Démarche proposée pour la pratique l’audit informatique bancaire ......................................................................................... 20 PARTIE II : MISE EN ŒUVRE DE LA DEMARCHE POUR L’AUDIT DU SYSTEME INFORMATIQUE DE BANK AFRICA ................................ 25 I – RAPPELS DES TRAVAUX A EFFECTUER .................................................................................................................................................... 26 II - LES TRAVAUX EFFECTUES .......................................................................................................................................................................... 26 A - AUDIT DE L’ORGANISATION .................................................................................................................................................................. 28 1. Etape1 : prise de connaissance générale ............................................................................................................................................ 28 2. Etape2 : Prise de connaissance du PSS ................................................................................................................................................. 28 3. Etape 3 : appréciation du dispositif de contrôle du risque informatique ........................................................................................ 28 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 5. La pratique de l’audit informatique dans les banques Page 4 4. Etape 4 : Constat et Recommandation ................................................................................................................................................ 29 4.1 Les principaux constats : sécurité physique ........................................................................................................................ 29 4.2 Les principaux constats : sécurité logique ........................................................................................................................... 30 4.3 Les recommandations ............................................................................................................................................................ 30 B - AUDIT DE L’ARCHITECTURE RESEAU........................................................................................................................................................ 32 Etape1 : prise de connaissance générale ................................................................................................................................................ 32 2. Etape2 : Prise de connaissance du PSS ................................................................................................................................................. 33 3. Etape 3 : appréciation du dispositif de contrôle du risque informatique ........................................................................................ 33 3.1 Examen de la configuration du routeur AGS+ ..................................................................................................................... 33 3.2 Examen de la configuration du routeur DLink DI-614 .......................................................................................................... 34 3.3 Examen de la configuration du serveur ISA ......................................................................................................................... 35 3.4 Examen de la configuration du serveur d’antivirus TrendMicro Officescan Corporate V. 7.0 ...................................... 35 4. Etape 4 : Les principaux constats et recommandations ................................................................................................................... 35 4.1 Les constats .............................................................................................................................................................................. 35 4.2 Les recommandations ............................................................................................................................................................ 37 C - AUDIT DE LA BASE DE DONNEES DES CLIENTS ..................................................................................................................................... 40 EXAMEN DE LA BASE DE DONNEES ............................................................................................................................................................. 40 1. L’existant ....................................................................................................................................................................... 40 2. Démarche ....................................................................................................................................................................... 40 3. les constats ....................................................................................................................................................................... 41 Examen de quelques dossiers physiques .................................................................................................................................................. 43 o LEVEL BANK INTERNATIONAL TCHAD S.A ...................................................................................................................................... 43 o COMPAGNIE WALLEM POUR LE TRANSPORT .............................................................................................................................. 45 4. Les recommandations ....................................................................................................................................................................... 45 CONSLUSION .................................................................................................................................................................................................. 47 PARTIE III: ANNEXE.......................................................................................................................................................................................... 47 QUESTIONNAIRE DES RISQUES INFORMATIQUES ........................................................................................................................................ 48 THEMES DE REFERENCES DE LA MISSION D’AUDIT .................................................................................................................................... 53 ARCHITECTURE DU RESEAU DE LA BANQUE AVANT L’AUDIT .................................................................................................................... 59 ARCHITECTURE RESEAU PROPOSEE ........................................................................................................................................................... 60 SITES INTERNET ET BIBLIOGRAPHIE ................................................................................................................................................................ 61 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 6. La pratique de l’audit informatique dans les banques Page 5 RESUME Dans le souci de professionnaliser les enseignements au Cameroun et de répondre ainsi à la demande en cadre informatique dans les entreprises, il existe depuis 2003 à l’Université de Douala, la MIAGE, formation de niveau BAC+5 préparant les étudiants au titre d’ingénieur Maître en informatique. A la fin de cette formation initiée par le Professeur Maurice TCHUENTE, les étudiants ont l’obligation de soutenir un rapport de stage effectué en entreprise, devant un jury constitué des enseignants et des professionnels de d’informatique. Nous avons effectué le notre dans le cabinet Universal Consulting. Universal Consulting est un cabinet de conseil, d’audit et d’expertise comptable installé à Douala au Cameroun. Travaillant pour le compte de ses clients constitués notamment des banques et des projets financés par les bailleurs de fonds, il apporte une approche internationale pour trouver des solutions aux problèmes locaux. Dans cette optique, il a développé plusieurs concepts novateurs dans la profession au Cameroun, parmi lesquels l’utilisation de l’informatique en appui à l’audit. C’est autour de ce concept que nous avons effectué notre stage de fin de formation, lequel nous a permis d’expérimenter les concepts théoriques de l’école en milieu professionnel. Ces travaux nous ont permis de proposer une démarche, des méthodes et des techniques appropriées pour la pratique de l’audit informatique dans les banques. De peur de rester trop théorique, nous avons mis en exergue cette technique pour auditer l’organisation, l’architecture du réseau informatique et la basse de données de la banque « BANK AFRICA » dans le cadre d’une mission d’audit effectuée par le cabinet Universal Consulting. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 7. La pratique de l’audit informatique dans les banques Page 6 PARTIE I - DEMARCHE D’AUDIT INFORMATIQUE DANS LES BANQUES Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 8. Page 7 La pratique de l’audit informatique dans les banques 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. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 9. La pratique de l’audit informatique dans les banques Page 8 II – LA PRATIQUE DE L’AUDIT 2.1 Définition L’audit est une activité indépendante et objective qui donne à une organisation une assurance sur le degré de maîtrise de ses opérations, lui apporte ses conseils pour améliorer son fonctionnement et contribue à créer de la valeur ajoutée. Il aide également l’organisation à atteindre ses objectifs de manière efficiente en apportant une démarche systématique et méthodique pour évaluer l’efficacité de la gestion des risques. En somme, l’audit peut être considéré aujourd’hui comme la gestion des risques. 2.2 Les objectifs de l’audit Les objectifs de l’audit de manière générale seront d’émettre une opinion ou de formuler des recommandations sur un dispositif de gestion des risques en effectuant des diligences conformes aux normes de la profession. Ceci suppose une appréciation générale des risques liés à l’activité. III – L’AUDIT INFORMATQIUE 3.1 Définition Comme tout audit, l’audit informatique est une activité indépendante consistant à évaluer un dispositif mis en place pour faire face aux risques informatiques. Ceci suppose une bonne identification des principaux risques informatiques. L’audit informatique possède deux niveaux de complexité, dans la mesure où l’on n’est toujours pas certain de la fiabilité des systèmes informatiques, bien que ce soit ces systèmes qui vont nous fournir des informations qui seront à la bases de nos constats et recommandations. C’est pour cette raison que la pratique de l’audit informatique doit nécessiter une polyvalence toute particulière, la compréhension de l’activité de base et une bonne connaissance des systèmes informatiques car l’informatique n’étant qu’un outil utilisé dans une activité. On peut à ce niveau se poser deux questions fondamentales : Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 10. Page 9 La pratique de l’audit informatique dans les banques - Comment évaluer un outil de production dont on ne connait pas la logique qui sous-tend son fonctionnement ? - Comment formuler les recommandations sur une activité seulement à base de quelques outils de production, sans connaître intimement cette activité ? Ces deux questions sont à la base de l’audit informatique. Il est vital pour un auditeur informatique de bien connaître la logique des traitements automatisés, et de les appliquer sur une activité, qui utilise l’informatique comme outil de travail (production). L’auditeur informatique doit être à mesure de lire et de comprendre un message d’erreur, ou alors d’établir par exemple la différence qui existe entre une base de données, une application et un système d’exploitation, ou encore entre un progiciel et un logiciel. Il doit également pouvoir faire la différence entre un message bloquant (contrôle bloquant) et un message d’erreur d’exploitation (erreur de saisie). En somme, l’auditeur doit bien connaître les éléments d’un système informatique afin de prétendre évaluer leurs risques. 3.2 Le système informatique 3.2.1 Définition Le système informatique se définit comme un ensemble de matériel, de logiciel et de système externe qui travaillent de manière interdépendante pour transformer les données et les restituer aux utilisateurs sous forme d’informations. Il apparaît naturel que pour évaluer le risque d’un système informatique, il faudrait s’intéresser aux risques attachés aux éléments qui le compose. De manière générale, on s’intéressera aux risques physiques (risques liés aux matériels) et aux risques logiques (risques liés aux logiciels et aux procédures), car l’informatique étant lui-même divisé en deux partie, à savoir la partie HADWARE pour le matériel et la partie SOFTWARE informatiques) Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 pour les logiciels (et les procédures
  • 11. La pratique de l’audit informatique dans les banques Page 10 3.2.2 Cartographie d’un système informatique Pour mieux comprendre le système informatique, nous avons matérialisé une cartographie d’un système informatique et une vision réduite de la partie logique de l’informatique, vision qui doit orienter un auditeur informatique tout au long d’une mission d’audit informatique. Cartographie d’un système informatique MATERIEL LOGICIEL SYSTEME EXTERNE La couche logicielle d’un système informatique DATA (données) LOGICIELS (applications) OS (système d’exploitation) Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Les données Ex : Message SWIFT MT100 Les applications Ex : Swift Access Système d’exploitation Ex : UNIX AIX, Linux, Windows
  • 12. Page 11 La pratique de l’audit informatique dans les banques 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. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 13. La pratique de l’audit informatique dans les banques Page 12 4.2 Les risques informatiques dans les banques 4.2.1 Vol et diffusion non autorisée de données confidentielles La plupart des informations bancaires sont créées par traitement informatique ou liées directement à ce dernier. Les données et documents sont généralement acheminés à l’intérieur d’une banque ou entre une banque et ses correspondants et clients par des réseaux publics de communication (lignes téléphoniques et satellites, par exemple). Un grand nombre d’usagers, dont les employés et clients des banques, peuvent accéder directement à ces informations par l’intermédiaire de terminaux via internet et de téléphones informatiques (téléphones WAP). Tout en améliorant les services à la clientèle et les opérations internes, ces activités ont accru les risques d’erreur et d’utilisation abusive des informations des banques. Une grande partie de ces informations sont confidentielles; elles pourraient nuire aux relations avec la clientèle ainsi qu’à la réputation de l’établissement et entraîner des demandes de dommages et intérêts si elles tombaient entre de mauvaises mains. On peut citer parmi ces informations l’historique de certains comptes clients (hommes d’affaires, hommes politiques, …). La création et le stockage de la correspondance et des stratégies bancaires s’effectuent également par traitement informatique. Le danger particulier que représente la divulgation d’informations confidentielles avec les systèmes informatiques, par rapport aux systèmes manuels, réside dans le fait que l’on peut prélever plus facilement, et sous une forme pouvant être traitée par ordinateur (telles que copies sur bande ou disquette), une quantité importante d’informations et que l’accès non autorisé peut intervenir sans laisser de traces. Il convient donc de mettre en place des procédures adéquates de sécurité et de contrôle pour protéger la banque. C’est en fonction du degré de risque encouru par l’établissement et de l’incidence des pertes (ou de la diffusion non autorisée d’informations) qu’il faut fixer le niveau de contrôle requis. Les contrôles techniques effectués aux fins de la sécurité de l’information pourraient inclure:  le chiffrement, processus par lequel le texte en clair est converti en une série de symboles dénués de sens; Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 14. La pratique de l’audit informatique dans les banques  Page 13 l’utilisation de codes d’authentification des messages, qui protègent contre toute altération non autorisée les transactions électroniques de données au cours de la transmission ou du stockage;  le recours au logiciel d’application de mesures de sécurité, en vue de restreindre l’accès aux données, fichiers, programmes, utilitaires et commandes de systèmes informatiques. De tels systèmes permettent de contrôler l’accès par utilisateur, par transaction et par terminal. Avec ces dispositifs, les violations ou tentatives de violation de la sécurité doivent être automatiquement identifiés. 4.2.2 Erreurs Les erreurs se produisent en général lors de l’entrée des données ainsi que durant le développement et la modification des programmes. Des erreurs importantes peuvent également se glisser au cours de la conception des systèmes, des procédures routinières de gestion des systèmes (procédures d’exploitation des systèmes) et de l’utilisation des programmes spéciaux destinés à corriger d’autres erreurs. Les erreurs sont habituellement imputables à une défaillance humaine, et très rarement aux composants électroniques ou mécaniques internes. Elles peuvent aussi être introduites dans les programmes de logiciel lorsque ces derniers sont «personnalisés» et adaptés aux besoins d’un utilisateur particulier 4.2.3 Fraudes Les flux de données bancaires sont considérés comme des instructions qui donnent lieu à des traitements spécifiques (interprétation des messages SWIFT et des logs d’erreur) qui complexifie le contrôle interne, ouvrant ainsi les portes aux fraudes. Les fraudes réussies ne se traduisent pas seulement par une perte financière directe pour l’établissement; elles portent aussi atteinte, lorsque les médias en prennent connaissance, à la confiance placée à l’établissement et le système bancaire en général. Vu les nombreuses possibilités d’accès aux documents informatiques, les risques de fraude sont multiples. On peut citer à titre d’exemple : Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 15. Page 14 La pratique de l’audit informatique dans les banques - 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 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 16. La pratique de l’audit informatique dans les banques veiller à donner Page 15 une formation adéquate au personnel oeuvrant dans les domaines sensibles et à répartir convenablement les tâches. 4.2.4. Accidents "naturels" Cette catégorie regroupe tous les risques comme les incendies, dégâts des eaux, explosions, catastrophes naturelles, etc. Certains de ces risques ne peuvent être raisonnablement pris en compte (ex. effondrement causé par la présence d'une ancienne carrière souterraine), d'autres peuvent être prévenus ou combattus par des dispositifs adéquats, l'informatique n'étant alors qu'un des aspects du problème. Enfin, des mesures simples permettent de limiter les conséquences de certains risques (ex. si la salle informatique est située au premier étage, on évitera la perte du matériel en cas d'inondation, même si celle-ci ne peut être combattue). En outre, il convient de souscrire une police d’assurance pour les équipements informatiques critiques (les différents serveurs par exemple). 4.2.5 Défaillance matérielle ou logicielle Les systèmes informatiques sont constitués, au niveau du matériel comme du logiciel, de multiples éléments et la défaillance de l’un d’entre eux suffit pour bloquer tout le système. Ces éléments sont souvent concentrés en un seul ou en un nombre limité d’endroits, ce qui en accroît la vulnérabilité. Le remède classique contre une panne du système consistait auparavant à revenir aux procédés manuels que le système informatique avait remplacés. Dans la plupart des cas, cette façon de procéder n’est plus réaliste et peu de banques pourraient fonctionner sans systèmes informatiques. Le traitement et la fourniture de l’information au moyen d’une technologie améliorée ont accru la dépendance des utilisateurs à l’égard de la disponibilité et de la fiabilité des systèmes automatisés. La disponibilité continue du système d’information d’une banque fait partie intégrante d’une prise de décisions efficace. Lorsque les systèmes informatiques sont hors d’usage, les effets préjudiciables qui en résultent pour les services bancaires en temps réel aux clients sont immédiats et prennent rapidement des proportions alarmantes. Les retards s’accumulent et, si la défaillance dure plusieurs heures, les conséquences peuvent êtres lourdes. Ces Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 17. La pratique de l’audit informatique dans les banques Page 16 effets sont particulièrement dévastateurs dans le cas des systèmes électroniques et de paiement, ceux notamment qui garantissent un règlement le jour même, lorsque les bénéficiaires sont tributaires de la réception de fonds pour faire face à leurs engagements. Les coûts engendrés par une panne sérieuse des systèmes peuvent dépasser de loin les frais de remplacement du matériel, des données ou du logiciel endommagés. L’existence de plans de secours efficaces peut permettre aux banques de réduire l’incidence des problèmes d’exploitation de ce genre. Ces plans devraient prolonger la disponibilité du système informatique d’une banque. Ils devraient comporter des dispositions pour la poursuite de l’activité et des procédures de relance en cas d’interruption ou de dysfonctionnement des systèmes, c’est-à-dire un dispositif de sauvegarde complète du système (OS, Application et données) hors site de production et identique à l’environnement de productions, ainsi que des procédures informatiques régulièrement mises à jour. Les plans de secours devraient être testés périodiquement pour s’assurer que leur efficacité demeure intacte. Une banque qui opte pour l’outsourcing ou l’externalisation de son système informatique devrait veiller à ce que les plans de secours de ces services complètent les siens. 4.2.6 Planification inefficace Une planification optimale est d’une importance capitale. L’efficacité et la qualité des services bancaires sont désormais tellement tributaires des systèmes informatiques que toute défaillance dans la planification, l’acquisition et l’installation de nouveaux systèmes peut avoir de sévères conséquences pour la banque. Toute défaillance dans l’installation de nouveaux systèmes et la fourniture de nouveaux services peut pénaliser lourdement une banque par rapport à ses concurrents. Ce fût le cas pour une banque du sud qui après avoir développé un module d’interrogation des comptes via Internet s’était précipitée à mettre en ligne sans avoir testé les différentes fonctionnalités par les spécialistes de la sécurité sur internet. Vingt quatre heures seulement après sa mise en ligne, certains clients vicieux avaient réussi à modifier leur solde dans le système en Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 18. Page 17 La pratique de l’audit informatique dans les banques 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 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 19. La pratique de l’audit informatique dans les banques Page 18 Toute organisation devrait attacher une grande attention à la planification (stratégique) à long terme des systèmes informatiques, à l’équipement, à la détermination des spécifications des systèmes, et évidement au choix des fournisseurs de solutions et à la conduite du projet. On constate que 75% de projet informatique se voit souvent leur budget complètement épuisé alors que le projet est encore dans la phase de la conception, ce qui suppose que l’étude de faisabilité était erronée. 4.2.7 Attaque et sabotage Dans cette catégorie, on range les risques informatiques quoique inconnus des non informaticiens, mais extrêmement répandus de nos jours. Nous allons découvrir quelques attaques informatiques relèvant du domaine de l’informatique pur, mais donc la compréhension des risques attachés relève du bon sens et de l’esprit critique, celui que devrait avoir tout auditeur.  Le cheval de Troie programme malveillant d’apparence anodine (jeu, petit utilitaire...) qui, une fois installé dans un ordinateur, peut causer des dégâts comme un virus classique, ou permettre de prendre le contrôle à distance de la machine.  La backdoor (porte arrière) est un point d’entrée dans un programme ou un système, plus ou moins secret. C’est généralement le recours pour débloquer un code d’accès perdu ou pour contrôler les données lors du debuggage. Malheureusement, c’est aussi l’un des points d’entrée des hackers (pirate informatique), lorsqu’ils en découvrent l’existence. Le hacker peut également créer lui-même cette porte pour l'utiliser dans un deuxième temps.  Le sniffing : c'est écouter une ligne de transmission par laquelle transitent des données pour les récupérer à la volée. Cette technique peut-être utilisée en interne pour le debuggage ou de manière abusive par un pirate cherchant, par exemple, à se procurer des mots de passe. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 20. La pratique de l’audit informatique dans les banques  Page 19 Le spoofing : c'est une technique d’intrusion dans les systèmes informatiques consistant à envoyer à un serveur d’une entreprise, des messages (paquets) semblant provenir d'une adresse IP connue par le firewall (adresse interne existante autorisée). Pour que la communication ne s’établisse pas avec la machine possédant réellement cette adresse, le hacker doit dans le même temps rendre cette machine injoignable pour avoir le temps d’intercepter les codes de communication et établir la liaison pirate.  L'attaque par rebond est menée via un autre ordinateur qui se trouve involontairement complice et qui expédie les messages d'attaque à la victime, masquant ainsi l'identité du véritable agresseur.  L'attaque par le milieu consiste pour un hacker à se placer entre deux ordinateurs en communication et se faire passer pour un afin d'obtenir le mot de passe de l'autre. Dès lors, il peut se retourner vers le premier avec un mot de passe valide et l'attaquer réellement.  Le déni de service est une attaque cherchant à rendre un ordinateur hors service en le submergeant de trafic inutile. Par exemple, un serveur entièrement occupé à répondre à des fausses demandes de connexion. Plusieurs machines peuvent être à l'origine de cette attaque (généralement à l’insu de leur propriétaire).  Le war-driving dans le cas des réseaux Wi-Fi, consiste à circuler dans la ville avec un ordinateur portable ou un PDA (ordinateur de poche) équipé d’une carte réseau Wi-Fi pour repérer et pénétrer dans les réseaux locaux mal protégés. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 21. Page 20 La pratique de l’audit informatique dans les banques 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 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 22. La pratique de l’audit informatique dans les banques Page 21 La particularité de l’audit informatique dans un environnement bancaire nécessite une méthodologie appropriée. Nous venons d’élaborer une liste quoique non exhaustive des risques informatiques que pourraient faire face une banque. Maintenant, nous allons mettre en œuvre une démarche méthodique qui nous permettra d’apprécier le dispositif de contrôle mis en place pour faire face à ces risques. La démarche retenue s’articule sur cinq étapes. Le prélude à tout audit informatique est la définition des processus sensibles dans les banques de manières générales. Les processus suivants peuvent être retenus : - La sécurité physique - La sécurité logique - La sécurité des réseaux (LAN et WAN) - La planification et continuité des activités - Les ressources humaines - La stratégie informatique - La tolérance aux pannes - Activités opérationnelles - Méthodes, normes et documentation - Les sauvegardes - Méthodologie de développement des projets - Gestion des risques informatiques EXPLICITATION DE LA DEMARCHEPROPOSEE Etape 1 : prise de connaissance générale Cette étape a pour but de permettre aux membres de l'équipe d'acquérir une connaissance détaillée des caractéristiques de la banque et des fonctions à auditer. Elle s'effectuera à travers les entretiens avec les opérationnels pour identifier nos principaux interlocuteurs tout au long de la mission. C’est également Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 23. Page 22 La pratique de l’audit informatique dans les banques 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. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 24. La pratique de l’audit informatique dans les banques Page 23 Etape 5 Réunion de synthèse avec la direction Il s’agit d’une réunion au cour de la quelle l’auditeur présente la synthèse des travaux effectués et notamment émet un rapport projet contenant les principaux constats et les recommandations. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 25. La pratique de l’audit informatique dans les banques Page 25 PARTIE II : MISE EN ŒUVRE DE LA DEMARCHE POUR L’AUDIT DU SYSTEME INFORMATIQUE DE BANK AFRICA Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 26. La pratique de l’audit informatique dans les banques Page 26 I – RAPPELS DES TRAVAUX A EFFECTUER D’après les termes de références (voir annexe), les travaux porteraient notamment sur : - l’audit de l’organisation - l’audit de l’architecture du réseau - l’audit de la base de données II - LES TRAVAUX EFFECTUES AFRICA BANK est une banque commerciale de l’Afrique tropicale offrant les services bancaires classiques : ● Collecte des dépôts clientèle ● Octroi de crédit à la clientèle Elle dispose de quatre agences (ZETA, BETA, GAMA et SIGMA) et opère sur un système informatique en architecture décentralisée. Dans cette configuration, les données des agences sont acheminées au site central par l’artifice de l’intégration des fichiers avant traitement de fin de journée. Ces dernières années, son système informatique a connu des pannes récurrentes. C’est dans le but de faire face à cette situation que la Direction Générale avait commandité un audit donc les recommandations aideraient à corriger les problèmes actuels et surtout mettre en place des dispositifs pour éviter que cette situation ne se reproduise dans le futur. Pour ce faire, la banque «BANK AFRICA » avait sollicité le cabinet Universal Consulting, cabinet dans lequel nous avons effectué notre stage. J’ai donc participé à toutes les phases cette mission d’audit en qualité de chef de mission. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 27. La pratique de l’audit informatique dans les banques Page 27 Etant donné la densité des travaux à effectuer, nous avons trouvé opportun de les diviser en trois grands lots et pour chaque lot, nous mettrons en exergue la démarche présentée ci-dessus. Ce découpage faisait ressortir les lots suivants: A. Lot 1 : Audit de l’organisation B. Lot 2 : Audit de l’architecture réseau C. Lot 3 : Audit de la base de données des clients Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 28. La pratique de l’audit informatique dans les banques Page 28 A - AUDIT DE L’ORGANISATION Comme le précisait les termes de références, il est question d’évaluer la politique de sécurité de la banque et de proposer les recommandations adéquates pour la mise en place d’une politique sécuritaire de pointe. On s’intéressera aussi bien à la sécurité physique qu’à la sécurité logique. 1. Etape1 : prise de connaissance générale Nous avons pris des rendez-vous avec quelques responsables stratégique de la banque pour voir si la gestion de la sécurité informatique était intégrée dans le plan stratégique de la banque. Nous nous sommes notamment entretenu avec le Directeur Général Adjoint, le Directeur Financier, le Directeur informatique et le Contrôleur Général. Dans cette phase, nous avons exploité notre questionnaire de contrôle interne dans les banques (voir annexe) 2. Etape2 : Prise de connaissance du PSS Nous nous sommes entretenus avec le Directeur Informatique (DI) à défaut d’un responsable de la sécurité des systèmes informatiques (RSSI). Nous avons effectués quelques tests de cohérences sur la plate forme de production en rapprochant certains indicateurs obtenus de l’entretien et de ceux réellement en exploitation. Par exemple, en réponse à la question de savoir si la banque avait un antivirus, et comment étaient effectuées les mises à jour, le DI nous a répondu qu’il se faisait automatiquement via la LiveUpdate. Après vérification, nous avons constaté que le module LiveUpdate était mal configuré et que la dernière mise à jour datait d’environ deux (02) ans. 3. Etape 3 : appréciation du dispositif de contrôle du risque informatique Le dispositif de contrôle de la sécurité est fortement défaillant. En effet, nous avons les constatations suivantes pendant notre audit : - absence de plan de continuité des activités - absence de recueil des risques informatiques dans les banques Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 29. La pratique de l’audit informatique dans les banques - absence de cartographie des risques - absence d’une base de données incident / risque - absence de plan stratégique de la sécurité - Page 29 absence de RSSI. 4. Etape 4 : Constats et Recommandations 4.1 Les principaux constats : sécurité physique ● Un système de contrôle d’accès défaillant Le système de contrôle d’accès dans les salles serveurs de la banque ne fonctionne plus. Dans cette situation, toute personne étrangère ou non à la banque peut se retrouver dans cette salle sans être identifiée. ● Système d’identification obsolète le système d’identification permettant d’enregistrer dans une base de données tous les personnes entrant et sortant dans la banque (en dehors des clients) est implémenté sur une machine Windows 95 et reliée au réseau de la banque et à internet. Ce système est source de plusieurs vulnérabilités et constitue une porte d’entrée des spywares et chevaux de Troie dans la banque. ● Reprise électrique très lente en cas de coupure La banque dispose d’un groupe électrogène pour faire face aux coupures intempestives du courant mais celui-ci ne se met pas automatiquement en marche après la coupure du courant. Cette situation peut provoquer des incidents de traitements informatiques préjudiciables à la banque, comme la corruption de certaines tables dans la base de données si des traitements portaient sur les données de ces tables. ● Absence de contrat d’assurance couvrant les équipements sensibles Les serveurs de production et autre équipent sensibles de la banque ne sont pas couverts par des contrats d’assurance. En cas d’incident informatique mettant Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 30. La pratique de l’audit informatique dans les banques Page 30 hors d’usage ces serveurs, la banque éprouvera de difficultés financières pour leur remplacement. 4.2 Les principaux constats : sécurité logique ● Les comptes utilisateurs génériques Les comptes utilisateurs sur les serveurs de la banque sont génériques, généralement sous la forme PrénomAnnéeDeNaissance et donc facile à casser ou à deviner dès lors qu’on connaît un peut l’utilisateur. En outre le compte administrateur du serveur central est connu de tous les informaticiens et utilisé généralement pour toutes les taches d’administrations. Cette situation peut entraîner des risques graves en cas d’une mauvaise manipulation ; en effet l’utilisation du compte root sur les systèmes UNIX requiert une certaine vigilance car ses actions sont irréversibles. ● Protection anti-virale légère Le logiciel anti-virus utilisé dans le parc informatique n’est pas régulièrement mis à jour et sa configuration ne couvre pas l’ensemble du parc informatique. ● Politique de gestion des ressources Internet insatisfaisant La revue du cache Internet sur les machines de guichet montre qu’elles sont connectées à Internet et que les sites visités dans la plupart sont des sites aux contenus réservés aux adultes. Ces machines sont également utilisées pour télécharger des contenus vidéo, relativement gourmand en bande passante. 4.3 Les recommandations Il est recommandé de redéfinir la stratégie informatique. Cette nouvelle stratégie devrait intégrer les procédures informatiques qu’il faudrait rédiger pour toutes les tâches effectuées à la Direction Informatique. Ces procédures doivent être rédigées et appliquées par l'informatique. L'ensemble des procédures doit aboutir à un référentiel pour s'assurer du contrôle des opérations informatiques et de leur Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 31. La pratique de l’audit informatique dans les banques Page 31 pérennité. Il est à préciser que les procédures doivent préciser les champs d'application, les acteurs, les tâches, les documents utilisés et les contrôles à entreprendre (y compris certains modes opératoires). Les procédures qui doivent être envisagées concernent : ● les opérations d'exploitation informatique (consignes d'exploitation, suivi de la production, identification des anomalies, mise en production de programmes, gestion des sauvegardes, etc…) ● les procédures de développement et de maintenance (processus de validation des demandes utilisateurs, développement d'applications et documentation des analyses et des manuels, gestion des maintenances, etc…), ● les procédures d'administration de la sécurité (création - modification suppression de profils et de droits, identification et suivi des incidents de sécurité, revue des sécurités systèmes et applicatives, etc…). Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 32. La pratique de l’audit informatique dans les banques Page 32 B - AUDIT DE L’ARCHITECTURE RESEAU Comme le précisait les termes de références, Il s’agit de procéder à une analyse très fine de l’infrastructure réseau du système d’information touchant le paramétrage et la configuration des équipements et logiciels de filtrage, de détection et de refoulement mis en place. Etape1 : prise de connaissance générale Nous avons pris des rendez-vous avec quelques responsables Directeur informatique pour disposer de l’architecture réseau de la banque. De cet entretien il ressort que le réseau de la banque se présente de la manière suivante : 3 sous réseaux de classe C (192.168.1.0, 192.168.2.0, 192.168.3.0) Le réseau 192.168.1.0 : réseau Front office, constitué des poste de guichet et autre postes de commercial. Il se connecte au réseau 192.168.2.0 (réseau back-office) par l’intermédiaire d’un routeur « DLink DI-614 ». Ce réseau abrite le progiciel « Delta Bank » spécialisé dans la gestion des banques commerciales. Le réseau 192.168.3.0 (réseau étude) quant à lui est dédié à la formation et aux tests des différentes applications avant la mise en production. Un routeur AGS+ relie la banque à Internet avec des règles bien définies. Matériel  8 switchs CISCO 10/100 Mbps  3 routeurs − 1 CISCO − 2 DLink (DI-604 et DI-614)  Une baie de brassage Logiciel  Un logiciel antivirus  Un logiciel de vidéo surveillance  Le logiciel ISA de Microsoft Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 33. La pratique de l’audit informatique dans les banques Page 33 2. Etape2 : Prise de connaissance du PSS Nous nous sommes entretenus avec le Directeur Informatique (DI) pour apprécier la stratégie de la banque en matière de sécurité informatique. Pendant cet entretien, nous avons rempli le questionnaire d’identification des risques informatiques. Nous avons enfin procédé à l’examen de la configuration de quelques équipements. 3. Etape 3 : appréciation du dispositif de contrôle du risque informatique Nous avons examiné tour à tour : ● la configuration du routeur CISCO AGS+ ● la configuration du routeur DLink DI -614 ● la configuration du serveur ISA ● la configuration du serveur antivirus TrendMicro Officescan Corporate V. 7.0 3.1 Examen de la configuration du routeur AGS+ Rappelons que le routeur AGS+ a pour principale fonction de gérer les connexions Internet initiées à partir de la banque. Pour cette raison, la connaissance de la configuration du réseau interne et externe est fondamentale. Les différentes règles à implémenter sont les suivantes : ● Toutes les machines doivent pouvoir aller sur Internet sauf celles du reseau192.168.1.0 ● Toutes les requêtes provenant d’Internet doivent être redirigé sur le port 80 du serveur de e-banking (192.168.2.45) ● Aucune autre machine ne doit pouvoir se connecter à Internet Il s’agit des règles qu’on devrait retrouver en principe dans le fichier de configuration du routeur CISCO AGS+. Dans la configuration actuelle du routeur, nous avons identifiés quelques instructions qui montrent que la configuration du routeur n’est pas en adéquation avec les règles éditées par la Direction informatique. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 34. La pratique de l’audit informatique dans les banques Page 34 #################################################### no routing ip ip route 192.168.0.0 255.255.255.0 195.93.33.233 #################################################### Explication : no routing ip désactive le routage sur le routeur . Dans cette configuration, il est impossible que les machines puissent aller sur internet. ip route 192.168.0.0 255 .255.255.0 195.93.33.233 Cette règle spécifie que toutes les hôtes d’un réseau de classe C « 192.168.0.0 » doivent pouvoir traverser le routeur. Dans l’hypothèse ou le routage était activé, le routeur devrait laisser traverser toutes les machines de la classe C, et donc un véritable relais internet. 3.2 Examen de la configuration du routeur DLink DI-614 Il s’agit d’un routeur utilisant la technologie wifi (réseau sans fil) Le service d’accès distant est activé sur ce routeur et lorsqu’un examine sa configuration, on se rend compte qu’aucune disposition de contrôle d’accès au réseau n’est activée. En outre, le service DHCP est activé dessus. Dans cette configuration, n’importe quel client DHCP, peut obtenir du routeur une adresse ip et infiltrer le réseau de la banque, notamment accéder à la base de données des clients et comptes. Nous avons exploité cette faille pour obtenir une connexion sur la base de données du site central à partir d’un café situé à 100 mètres de la banque. Il nous a suffi tout simplement d’activer la carte wifi de notre portable en mode client DHCP et quelques temps après, nous avons reçu une adresse ce qui nous a permis de nous connecter sur la base de données de la banque. Le service de contrôle d’accès par filtrage au niveau IP et MAC n’est pas activé. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 35. La pratique de l’audit informatique dans les banques Page 35 3.3 Examen de la configuration du serveur ISA Le serveur ISA est utilisé pour rationaliser et sécuriser le trafic internet. Pour cette raison, il se place entre le routeur et le réseau interne. Pendant nos travaux, nous avons constaté que les modules suivants n’étaient pas correctement configurés: ● Inspecteur d’état ● Filtre des paquets ● Détecteur d’intrusion ● Cache web 3.4 Examen de la configuration du serveur d’antivirus TrendMicro Officescan Corporate V. 7.0 Les clients TrendMicro ne sont pas bien configurés dans l’ensemble. Pour la plupart, la stratégie de mise à jour n’est pas précisée. Au niveau du serveur, le live update est activé pour aller rechercher les mises à jour sur Internet et distribuer sur les machines du réseau interne. 4. Etape 4 : Les principaux constats et recommandations 4.1 Les constats ● Configuration arbitraire du Routeur Cisco AGS+ La configuration du routeur Cisco AGS+ n’est pas conforme avec les règles de sécurité définies au niveau de la Direction Informatique. En effet, les règles de sécurité retenues précisent que seules les machines du réseau 192.168.2.0 et 192.168.3.0 doivent pouvoir aller sur internet. Il s’agit du réseau back office et le réseau étude. Or, les règles implémentées dans l’AGS+ autorisent tous les paquets issus d’un réseau de la classe C à traverser le routeur et d’aller sur Internet, par conséquent, toues les hôtes du réseau front office, back office et étude peuvent aller sur Internet dans une telle configuration. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 36. La pratique de l’audit informatique dans les banques Page 36 ● Blocage du service de routage sur l’AGS+ L’instruction « no routing ip » dans le fichier de configuration du routeur spécifie que le routage des paquets IP est désactivé, et par conséquent, l’AGS+ ne peut pas router les paquets IP qui lui sont envoyé. ● Configuration du routeur DLink DI-614 n’intégrant pas la sécurité L’examen de la configuration du routeur DLink DI-614 montre que la fonctionnalité wifi est activée et qu’aucun dispositif n’est mis en place pour prémunir la banque du wardriving. Il s’agit d’une technique qui consiste à scanner les réseaux WLAN non sécurisés en circulant dans son voisinage avec du matériel préparer pour la détection. ● Service ISA mal configuré En examinant la configuration du serveur ISA, nous avons constaté que les services essentiels de cette solution n’étaient pas mises en place et que pour celles qui étaient mises en places, elles sont pour la plupart mal configurées. il s’agit pour les services non configurés de : ● Inspecteur d’état ● Filtre des paquets ● Détecteur d’intrusion ● Cache web Dans cette configuration, il est impossible de contrôler le flux des paquets IP vers et depuis le serveur ISA, de détecter les intrusions dans le réseau par une alerte du serveur ISA ou alors d’exploiter la fonctionnalité Proxy cache de ISA. En effet, ISA peut aussi être utilisé comme un mandataire internet. ● planification inefficace de l’antivirus TrendMicro Officescan Corporate V. 7.0 La configuration actuelle de l’antivirus n’est pas optimale. Il apparaît dans sa configuration actuelle plusieurs indicateurs tel que live update donc la configuration n’est pas régulièrement revue. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 37. La pratique de l’audit informatique dans les banques Page 37 4.2 Les recommandations Au regard du nombre considérable de constats effectués au niveau de l’architecture réseau de la banque, il est impératif de prendre dans un délai raisonnable des dispositions appropriées. ● La redéfinition de l’architecture réseau L’architecture réseau de la banque dans sa configuration actuelle doit être revue. Étant donné que certains services de la banque doivent être accessible de l’extérieur de la banque, il nous semble indiqué une architecture de sous réseau en DMZ. Cette architecture permet de sécuriser fortement le réseau avec des moyens simples (filtrage principalement) en imposant un chemin précis aux différents flux. Elle permettra en outre de limiter les dégâts consécutifs à une intrusion en limitant au maximum la capacité d’actions de l’intrus, mais aussi l’utilisation de nos ressources pour attaquer un autre réseau (attaque du milieu). Le réseau formation sera adressé en DHCP pour faciliter l’administration tant disque celui du front office et du back office sera en adressage statique car étant considéré comme critique et au regard aussi du nombre réduit d’hôte qui le constituent. ● La reconfiguration des différents routeurs Les routeurs DLink DI-614 et CISCO AGS+ doivent être reconfigurés. En prélude à ce travail, il est impératif de définir l’ensemble des règles à implémenter sur chaque routeur. Ces règles correspondent aux trafics envisagés. Pour ce qui est du routeur DLink DI-614, il faudra impérativement : - désactiver la diffusion du SSID et activer le masquage du SSID, - changer les paramètres par défaut du routeur (le SSID, les mots de passe, l’adresse IP etc.), - activer le contrôle d’accès au niveau MAC et IP (le mieux est d’activer les deux), Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 38. La pratique de l’audit informatique dans les banques Page 38 - activer le chiffrement (de 128- ou de 256-bits), - éviter l’utilisation des clés secrètes WEP faciles à deviner, - vérifier si les employés n’installent pas des Access Point sans autorisation, - sécuriser le routeur contre un accès physique ● La reconfiguration du serveur ISA Le serveur ISA doit être impérativement reconfiguré pour intégrer la nouvelle stratégie en matière de sécurité informatique dans la banque. Dans sa nouvelle configuration, tout comme pour les routeurs, il est indispensable de définir le trafic souhaité et donc de formuler les règles appropriés. Pour les services inutiles, il faudra impérativement les désactiver en bloquant les ports appropriés. Après la configuration du serveur ISA, il faudra déployer le client ISA (client firewall) sur toutes les machines de la banque. Dans un souci de rationaliser la consommation de la bande passante, il faudra définir des groupes et des plages horaires pour gérer la convexion à Internet. Nous avons identifiés quelques scénarios qui peuvent être retenus pour la configuration d’ISA Server 2000 ● Activer le filtrage dynamique de paquets et la détection des intrusions pour tous les types d’attaques reconnues par ISA Server. ● Paramétrer des alertes en cas d’intrusion (mail à l’administrateur) ● Activer les filtres d’applications de données, comme le filtre SMTP ● Configuration des stratégies d’accès à Internet ● Configurations des clients ISA  Configuration des clients Proxy  Configuration des clients SecureNAT  Configuration des clients Firewall Avec cette configuration, il sera introduit une couche réseau supplémentaire sur le réseau de la banque qui augmente le niveau de sécurité. En outre les applications gourmandes en bande passante seront inopérantes car bloquées. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 39. La pratique de l’audit informatique dans les banques Page 39 De même, les horaires d’accès à Internet seront définies se qui permettra de libérer la bande passante pendant les heures de production. Les applications comme le SWIFT et le hotline seront prioritaires. La détection d’intrusion permettra d’identifier les attaques sur le système et alerter l’administrateur par message électronique ou par le déclenchement d’un autre processus qui peut soit arrêter le système ou certains services. Ceci permettra à l’administrateur d’être informé des nouveaux types d’attaques et d’envisager des solutions adéquates en temps réel. Le cache Web intégré dans le serveur ISA procurera un temps réponse aux requêtes HTTP plus rapide et des économies de la bande passante réseau. ● La revue des mises à jour de l’antivirus TrendMicro Officescan Corporate V. 7.0 La planification des mises à jour de cet antivirus étant manifestement inefficace, il convient de la revoir et de définir une périodicité pour la vérification des fonctionnalités du module de mise à jour du serveur. Enfin, il faudra uniformiser la méthode de mise à jour sur tous les postes clients en indiquant que le serveur de mise à jour est le 192.168.2.46 (serveur antivirus) Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 40. La pratique de l’audit informatique dans les banques Page 40 C - AUDIT DE LA BASE DE DONNEES DES CLIENTS EXAMEN DE LA BASE DE DONNEES 1. L’existant Dans cette phase, nous avons regroupé les étapes une à trois en une seule. Elle a consisté à la prise de connaissance de l’environnement. Il ressort des différents entretiens que la base de données à examiner se trouve sur un serveur ayant les caractéristiques suivantes : ● OS : AIX 4.3 ● SGBDR : INFORMIX IDS 7.4 ● APPLICATION : PROGICIEL DELTA BANK V 7.4.4 2. Démarche Précisons qu’il s’agissait du serveur de production de la banque. Comme le précisait les termes de références, il faut examiner les tables client et compte du site central et donc de la production. Conscient qu’en travaillant directement sur la production on pourrait augmenter la charge du serveur et ralentir la vitesse de traitement, nous avons effectué une copie de la base de données de production que nous avons installé sur le serveur de test pour disposer d’un environnement identique à celui de la production. Nous avons ensuite commencé l’exécution des requêtes sur la base de donnés du site central. Nous avons enfin procédé à la revue de quelques dossiers physique des clients. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 41. La pratique de l’audit informatique dans les banques Page 41 3. les constats En examinant la base de données du site central, nous avons fait les constats suivants : ● Des clients sur la base de données du site central sans secteur d’activité L’un des paramètres utilisés par les interlocuteurs des établissement de crédit (BEAC, COBAC, CNC, …) est le secteur d’activité de la clientèle. Cette information est d’autant plus importante que la BEAC a défini un ensemble de secteur d’activité (table des secteurs d’activité BEAC) permettant lors de la création d’un client dans une banque de le rattacher systématiquement à un secteur d’activité. En exécutant la requête de sélection des clients, secteur d’activité et nationalité BEAC, nous avons fait les constats suivants : ● 6 200 clients sur 16 121 soit 38.58% dont la zone secteur d’activité n’est pas renseignée ; ● certaines entreprises privées nationales sont classés dans le secteur d’activité « particulier »; c’est notamment le cas du client CONST/BTP, entreprise bien connue dans la banque ; ● des administrations publiques nationales et étrangères sont classées dans le secteur d’activité « particulier ». C’est notamment l’ambassade du Nigeria et l’ambassade du Tchad au Burkina Faso. Au regard de ces cas identifiés, il apparaît que l’affectation des clients à un secteur d’activité n’a pas répondu au dispositif réglementaire tel que prévu par la BEAC Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 42. Page 42 La pratique de l’audit informatique dans les banques ● 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. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 43. La pratique de l’audit informatique dans les banques Page 43 A ce propos, des requêtes de sélection des attributs catégorie BEAC, forme juridique, code intitulé et groupe d’activité ont été exécutées sur les tables des clients aussi bien en agence que sur le site central. En analysant les résultats des requêtes conçues lors de ces travaux, il ressort que certaines informations sur le site central sont différentes de celles se trouvant en agence bien que portant sur les mêmes clients Le cas le plus significatif porte sur l’attribut groupe d’activité où nous relevons : ● 71,38 % de clients de ZETA ● 29% de clients de BETA ● 35% de clients de SIGMA ● 36 % de clients de GAMA qui ont des attributs groupe d’activité différent de ceux du site central. En conséquence, il apparaît que les données entres les agences et le site central ne sont pas systématiquement cohérentes, comme indiquées dans le tableau cidessous. ZETA CAT BEAC GESTIONNAIRE IND STAT FORMR JURIDIQUE INTITULE GROUPE D'ACTIVITE LIEU NAISSANCE ANNEE NAISSANCE 0,01% 1,43% 0,03% 0,35% 0,03% 71,38% 0 0 BETA SIGMA GAMA 1,72% 5,23% 0,14% 9,58% 19,77% 11,85% 46,35% 66,69% 2,54% 1,46% 0,83% 0 1,20% 0 0 79,56% 87,54% 54,58% 69,56% 70,39% 42,60% 58,67% 2,99% 36,53% Examen de quelques dossiers physiques o LEVEL BANK INTERNATIONAL S.A La revue du dossier d’ouverture de compte du client LEVEL BANK INTERNATIONAL S.A indique qu’il s’agit d’une banque en création. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 44. La pratique de l’audit informatique dans les banques - Page 44 L’ouverture du compte d’une banque en formation suppose du point de vue de la profession bancaire : ● un questionnaire anti blanchiment, ce qui ne figure pas dans le dossier, ● un agrément, ce dont nous ne disposons pas, ● un récepicé de dépôt de dossier à la BEAC - S’agissant d’une banque, le chapitre « 371 » dans lequel son compte est logé n’est pas approprié. Dans l’hypothèse d’une société en formation fusse-t-elle une banque, son compte devrait être ouvert dans le chapitre « 374 ». - S’agissant d’une société en formation, le compte est ouvert pour souscrire au capital de la société en création. Les consultations auprès du département juridique et contentieux indiquent du point de vue juridique, l’article 393 de l’acte uniforme portant sur les sociétés commerciales et GIE stipule que « les fonds provenant de la souscription des actions en numéraire sont déposés par les personnes qui les ont reçus, pour le compte de la société en formation, soit chez un notaire, soit dans une banque domiciliée dans l’Etat partie du siège de la société en formation, sur un compte spécial ouvert au nom de cette société… » Par ailleurs, l’article 398 de l’acte uniforme de l’OHADA sur les sociétés et GIE dispose que « le retrait des fonds provenant des souscriptions en numéraires ne peut avoir lieu qu’après l’immatriculation de la société au registre de commerce… » et par conséquent il est bloqué jusqu’à la constitution effective de la société. Or, nous constatons qu’un chéquier a été délivré et une opération de retrait effectuée. - Au vue du dossier, l’on note l’absence des fiches de mise à jour client et compte, pire encore le carton de signature n’est ni visé du chef d’agence, moins encore du chef de guichet. Au regard de tout ce qui précède, il apparaît que l’ouverture de ce compte ne s’est pas déroulé dans des conditions satisfaisantes. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 45. Page 45 La pratique de l’audit informatique dans les banques 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.) Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 46. La pratique de l’audit informatique dans les banques Page 46 A cet effet, il est indiqué de constituer une TASK FORCE pour procéder aux corrections des anomalies et incohérences identifiées. Il s’agira entre autre de procéder à la mise à jour de la table catégorie banque centrale à l’agence de GAMA et SIGMA à partir de celle du site central.  Instruire une mission d’audit par la Direction d’Audit Interne Fort de ces insuffisances, nous recommandons d’étendre le champ d’investigation de la revue des dossiers physiques par l’instruction d’une mission de contrôle portant de manière générale sur tous les dossiers d’ouverture de compte. Cette mission dont le champ d’investigation devrait couvrir tout le réseau de « BANK AFRICA » aura notamment pour objectif de : - vérifier le contenu des dossiers - s’assurer de la nature des informations qui y figurent - s’assurer de la compatibilité de ces informations par rapport aux bases de données - procéder à un audit complet des bases de données du site central et des différentes agences pour détecter toutes les anomalies et d’appliquer les corrections nécessaires avant d’envisager le passage en système centralisé. Par ailleurs, nous suggérons qu’il soit procédé à la fiabilisation de la base de données des agences et du site central et qu’après chaque opération de migration informatique, qu’il soit mis en oeuvre un test substantif permettant de s’assurer que la base de données du site central est la « résultante » de celle des différentes agences.  Renforcer les contrôles bloquants dans Delta Bank Il serait judicieux de passer en revue les différents écrans de mise à jour clients/ compte (environ 7 écrans) afin d’identifier les champs obligatoires et optionnels pour instaurer des contrôles bloquant supplémentaires.  Suivi Instaurer les mécanismes de suivi (chef de guichet, chef d’agence, responsable administratif et financier et contrôle général). Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 47. La pratique de l’audit informatique dans les banques Page 47 CONSLUSION Au terme de nos travaux réalisés à Universal Consulting portant sur « la pratique de l’audit informatique dans les banques », nous espérons avoir apporté notre modeste contribution à une meilleure compréhension de ce sujet, de plus en plus d’actualité. Conscient de l’importance du sujet, nous avons d’abord dans une première partie présenter l’ensemble des outils théoriques pour la pratique de l’audit informatique dans une banque et dans une deuxième, nous avons mis en exergue ces outils et technique dans le cadre de l’audit informatique de BANK AFRICA. A la fin des travaux, il faut souligner que la démarche proposée devrait être actualisée avec l’évolution de l’informatique ce qui rendra de plus en plus spécifique la pratique de l’audit informatique dans les banques. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 48. La pratique de l’audit informatique dans les banques PARTIE III: ANNEXE Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Page 47
  • 49. Page 48 La pratique de l’audit informatique dans les banques QUESTIONNAIRE DES RISQUES INFORMATIQUES 1) Appréciation générale de la sécurité de l’entreprise Question A: Votre établissement est-il sensible aux risques (et aux conséquences) liées à l'informatique ? Observation : Réponse  Oui  Non Question B: Pour vous, l’informatique est-elle un facteur stratégique de pérennité et de développement de votre activité ? Observation : Réponse  Oui  Non Question C : connaissez-vous des méthodes d’évaluation des risques informatiques (MEHARI, MARION)? Observation : Réponse  Oui  Non Question D: Au cours des 3 dernières années, votre établissement a-t-il subi un préjudice, conséquence 'un dommage informatique (accident matériel ou applicatif, erreurs ou malveillance) ? Observation : Réponse  Oui  Non 2) Organisation générale Question 1: Existe-t-il un Comité Permanent chargé des problèmes liés à la sécurité, composé de représentants de la Direction Générale, de la Direction de l'Organisation et de l'Informatique, de représentants des fonctions utilisateurs, audit interne, juridique et assurances se réunissant au moins 4 fois par an ? Observation : Réponse  Oui  Non Question 2: Y-a-t-il eu une étude sur la vulnérabilité de l'entreprise face à différents risques physiques ou non physiques incluant le risque informatique au cours des 3 dernières années, donnant lieu à un rapport écrit ? Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 50. Page 49 La pratique de l’audit informatique dans les banques Observation : Réponse  Oui  Non Question 3: Cette étude a-t-elle entraîné la mise en place d'un Plan de Sauvegarde de l'entreprise (mesures conservatoires incluant celles financières) ? Observation : Réponse  Oui  Non Question 4: La fonction "Sécurité informatique" dispose-t-elle d'un poste spécifique sur l'organigramme avec un rattachement hiérarchique élevé assorti d'une définition de poste précisant les responsabilités et l'affectation d'un budget spécifique ? Observation : Réponse  Oui  Non Question 5: Y-a-t-il un responsable de la Sécurité Générale (bâtiments, environnement, accès) ? Observation : Réponse  Oui  Non Question 6: Le choix des garanties des polices d'assurances en matière informatique est-il le résultat d'une étude spécifique conduite en commun avec la Direction de l'Informatique ? Observation : Réponse  Oui  Non Question 7: Le(s) Système(s) Informatique(s) est-il couvert par un contrat incluant : - les dommages matériels, la reconstitution des médias, d'autres contrats liés au précédent (Globale Informatique, Spécifique détournement, Multirisques professionnelles) ? Observation : Réponse  Oui  Non Question 8: Existe-t-il un "propriétaire des informations" par fonction, responsable de l'évaluation, de la définition et la révision périodique des règles, et des procédures et autorisations d'utilisation des informations ? Observation : Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Réponse  Oui  Non
  • 51. Page 50 La pratique de l’audit informatique dans les banques Question 9: Y-a-t-il une étude particulière, lors de la conception des applications, sur le choix des contrôles automatisés et utilisateurs en amont et en aval de l'informatique ? Observation : Réponse  Oui  Non Question 10: Cette étude prend-elle en compte les critères d'analyse et de réduction des risques issus d'informations ou de traitements classés comme stratégiques ? Observation : Réponse  Oui  Non Question 11: Y-a-t-il une analyse des comptes comptables sensibles au moins 2 fois par an, les résultats étant consignés dans un rapport ? Observation : Réponse  Oui  Non Question 12: Existe-t-il un règlement écrit précisant les responsabilités des personnes et la procédure de signature selon le type de document traité ? Observation : Réponse  Oui  Non Question 13: A-t-on pris en compte la possibilité de destruction d'informations stratégiques sur support informatique et en a-t-on déduit des procédures systématiques de rétention des documents de base qui pourrait servir à leur reconstitution ? Observation : Réponse  Oui  Non Question 14: S'il existe un service d'Audit interne, a-t-il des compétences pour exercer le contrôle de la fonction informatique ? Observation : Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Réponse  Oui  Non
  • 52. Page 51 La pratique de l’audit informatique dans les banques 3) Protection incendie Question 15: Pour le bâtiment renfermant des locaux informatiques et administratifs, y a-t-il eu une étude spécifique du risque incendie prenant en compte les aspects protection et prévention avec un suivi des recommandations prescrites ? Réponse  Oui Observation :  Non 4) Dégâts des eaux Question 16: Y a-t-il eu des études contrôlées périodiquement (suivies d'effets) par un organisme spécialisé sur les dangers présentés par l'eau sur les salles des ordinateurs et les matériels d'environnement ? Réponse  Oui Observation :  Non 5) Amélioration de la fiabilité de fonctionnement Question 17: Y a-t-il un système complémentaire (groupe électrogène) et un système de régulation (onduleur) de l'alimentation électrique ? Observation : Réponse  Oui  Non Question 18: Y a-t-il une redondance réelle locale des unités centrales des ordinateurs et des organes stratégiques (contrôleurs) et repose-t-elle sur un plan de basculement écrit ? Observation : Réponse  Oui  Non Question 19: Dans le cas d'un sauvetage exhaustif de toutes les applications a-t-on étudié les besoins globaux, la planification de la charge et les contraintes techniques et organisationnelles ? Réponse  Oui Observation : Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006  Non
  • 53. Page 52 La pratique de l’audit informatique dans les banques 6) Procédures de secours Question 19: Existe-t-il un plan de sauvetage total des données et programmes vitales pour l’entreprise ? Réponse  Oui  Non Observation : Question 20: Dans le cas d'un sauvetage partiel ou en mode dégradé, a-t-on étudié le choix des applications à reprendre en fonction de leur degré stratégique ? Réponse  Oui  Non Observation : 7) Le personnel informatique Question 21: La formation du personnel informatique (hors saisie de données), en moyenne sur les 3 dernières années, est-elle supérieure à 5 jours par an et par personne ? Réponse  Oui  Non Observation : Question 21: Y a-t-il une répartition, un contrôle et un suivi des tâches stratégiques et/ou confidentielles ? Observation : Réponse  Oui Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006  Non
  • 54. La pratique de l’audit informatique dans les banques Page 53 THEMES DE REFERENCES DE LA MISSION D’AUDIT ARTICLE 1 - OBJET DE LA CONSULTATION OU APPEL D’OFFRE Le Maître d’Ouvrage se propose de lancer une consultation ou appel d’offre pour l’audit sécurité de systèmes d’information et de communication de la banque. La mission d’audit objet de cette consultation ou appel d’offre devra concerner aussi bien les aspects physiques et organisationnels que les aspects informationnels des systèmes d’information et de communication. Cette mission devra donc cibler tous les aspects touchant à la sécurité des systèmes d’information et des réseaux de communication véhiculant ces informations. Plus précisément, cette mission devra couvrir les aspects de contrôle d’accès à l’information et aux réseaux. Elle devra évaluer, suite à des simulations et des essais réels, la vulnérabilité des mécanismes et des outils matériels et logiciels de protection contre toutes les formes de fraude et d’attaques connues par les spécialistes du domaine au moment où l’audit est conduit. L’on cite à titre d’exemples : les intrusions, les attaques virales, les infiltrations, les fausses identités et les dénis de service. L’audit devra également évaluer la fiabilité des mécanismes d’authentification des usagers. Il devra comprendre, sans se limiter aux aspects suivants : La politique de sécurité, La protection contre les virus, La protection contre les intrusions, La journalisation des évènements, La gestion de comptes et des mots de passe, La configuration des pare-feu (Firewall), Le chiffrement, L’authentification, Le plan de secours ou de continuité. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 55. Page 54 La pratique de l’audit informatique dans les banques La mission d’audit objet de cette consultation ou appel d’offre devra donc aboutir à une évaluation précise des mécanismes et outils de sécurité présentement implémentés dans les systèmes audités dans le cadre de ce marché Elle devra indiquer clairement et sans équivoque toutes les failles de sécurité recensées à l’issue de l’audit et proposer une solution de sécurité tout en indiquant clairement les actions et les mesures à entreprendre en vue d’assurer la sécurisation de l’ensemble des systèmes d’information audités aussi bien sur le plan physique (sécurité de l’environnement) que sur les plans organisationnel (procédures d’exploitation, structures administratives dédiées à la sécurité, suivi et pilotage internes, etc.) et informationnel (logiciels et équipements réseaux spécifiques à la sécurité, dispositifs et accessoires, etc). ARTICLE 2 - ETENDUE DU TRAVAIL Cette consultation ou appel d’offre concerne des prestations d’audit sanctionnées par un ou plusieurs rapports dans lesquels on présentera Une évaluation de la vulnérabilité du système d’information audité. L’évaluation sera sanctionnée par un état exhaustif des failles et des anomalies décelées ; Les recommandations à suivre pour pallier les en œuvre insuffisances établies précédemment ; Une proposition de solution à mettre conformément aux recommandations préétablies. Les systèmes d’information avec toutes leurs composantes, y compris les aspects de contrôle d’accès, de sauvegarde des données, de la continuité de service, des fraudes internes et tout autre aspect touchant à la sécurité du système. Le réseau de communication au travers duquel le système d’information est accessible . Partant du principe que la sécurité est d’abord une question d’organisation, la mission d’audit devra approfondir cet aspect et relever toutes les failles organisationnelles quant à l’existence ou pas : de plan de sécurité, d’une structure chargée de la sécurité informatique, d’une charte comportant des consignes de sécurité pour les usagers, et de guides de sécurité. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 56. La pratique de l’audit informatique dans les banques Page 55 Elle devra également couvrir les aspects d’architecture, de configuration et de technologies réseau. Ces aspects, ayant un impact direct sur la sécurité, devront être étudiés, évalués et consignés dans le rapport d’audit. Les risques menaçant la pérennité de l’activité de la structure devront être précisées et justifiés dans le rapport d’audit. Dans une seconde phase, la mission d’audit devra s’orienter vers le système d’information proprement dit. Cette partie de l’audit devra aboutir à une évaluation des mécanismes implémentés dans le système d’information pour le contrôle d’accès, l’identification et l’authentification des utilisateurs dans l’objectif de détecter les sources potentielles de fraudes informatiques et les vulnérabilités du système d’information ARTICLE 3 - TRAVAIL DEMANDE Les prestations d’audit objet de cette consultation ou appel d’offre couvriront donc les aspects suivants : A. L’organisation B. L’architecture du réseau C. Le système d’information Le rapport d’audit devra couvrir ces aspects. Ce rapport devra être élaboré sur la base d’études de terrain. Le personnel d’audit devra se déplacer sur les lieux de la structure à auditer et procéder à des tests réels sans mettre en cause la continuité du service du système audité et ce en vue de dégager les écarts entre les procédures de sécurité supposées être appliquées et celles réellement en application. L’adjudicataire devra solliciter auprès de la structure à auditer toute information rendue nécessaire pour l’exercice de sa mission. En cas de difficulté il pourra faire recours au Maître d’Ouvrage. Ce recours devra être formulé par écrit et en temps opportun pour permettre au Maître d’Ouvrage d’intervenir efficacement. ARTICLE 4 - AUDIT ORGANISATION Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 57. Page 56 La pratique de l’audit informatique dans les banques 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 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 58. La pratique de l’audit informatique dans les banques Page 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é ; Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 59. La pratique de l’audit informatique dans les banques Page 58 Les recommandations nécessaires à la mise en œuvre de la solution préconisée. Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006
  • 60. La pratique de l’audit informatique dans les banques ARCHITECTURE DU RESEAU DE LA BANQUE AVANT L’AUDIT Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Page 59
  • 61. La pratique de l’audit informatique dans les banques ARCHITECTURE RESEAU PROPOSEE Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006 Page 60
  • 62. La pratique de l’audit informatique dans les banques Page 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 Rapport de stage rédigé par Hubal PFUMTCHUM MIAGE 2006