Management de lauditdes systmes dinformation

2me dition

Janvier 2013

Copyright 2013 par lInstitute of Internal Auditors, 247 Maitland Ave., Altamonte Springs, Floride, 32701-4201,tats-Unis. Tous droits rservs. Imprim aux tats-Unis. Aucune partie de cette publication ne peut tre reproduite,stocke dans un systme de consultation ou transmise sous quelque forme que ce soit, ni par aucun moyen (lectro-nique, mcanique, reprographie, enregistrement ou autre) sans autorisation crite pralable de lditeur.

LIIA publie ce document titre informatif et pdagogique. Cette publication entend donner des informations, maisne se substitue en aucun cas un conseil juridique ou comptable. LIIA ne fournit pas ce type de service et ne garantit,par la publication de ce document, aucun rsultat juridique ou comptable. En cas de problmes juridiques ou comp-tables, il convient de recourir lassistance de professionnels.

Contenu

3

Rsum ............................................................................................................................................................. 4

1. Introduction ........................................................................................................................................... 5

2. Stratgie mtier , processus et projets ............................................................................................ 7

3. Infrastructure et processus SI ............................................................................................................... 8

4. Approche fonde sur les risques ........................................................................................................ 12

5. Univers d'audit .................................................................................................................................... 13

6. Savoir-faire et comptences ............................................................................................................... 14

7. Raliser des missions d'audit des SI .................................................................................................. 15

8. Rapports ............................................................................................................................................... 17

9. Outils d'audit ....................................................................................................................................... 18

10. Conclusion ........................................................................................................................................... 20

Annexe A : Normes de rfrence ................................................................................................................. 21

Annexe B : Modles d'architecture des SI ................................................................................................... 22

Auteurs et relecteurs ..................................................................................................................................... 23

Rsum

4

Rsum

Les systmes dinformation (SI) ont une influenceomniprsente sur l'audit interne. Lmergence denouveaux risques implique de repenser les proc-dures pour grer ces risques de faon adquate. Leprocessus d'audit des SI nest globalement pas dif-frent de celui dautres travaux d'audit : lauditeurplanifie la mission, identifie et documente lescontrles pertinents, vrifie lefficacit de laconception et du fonctionnement de ces contrles,en tire les conclusions et rdige son rapport. Lesresponsables de l'audit interne (RAI) rendentrgulirement compte des conclusions des mis-sions d'audit des SI aux principales parties pre-nantes telles que le Conseil, la direction gnrale,le directeur des systmes d'information, les rgu-lateurs et les auditeurs externes. Ce guide a pourobjectif d'aider les RAI planifier et grer les tra-vaux d'audit avec une efficacit et une efficienceaccrues en analysant comment :

Dterminer les domaines ncessitant desressources en audit des SI. Quelles sont lesmissions qui ncessiteront l'intervention despcialistes en audit des SI ? A la lumire deslignes directrices exposes dans ce document,le RAI devrait tre mme de planifier lerecours des auditeurs des SI pour une cou-verture adquate de primtre auditer. Lesressources en audit des SI sont gnralementrares, alors que la demande est forte. Dfinirles besoins en audit des SI permet au RAI das-surer la ralisation des missions planifiesdans ce domaine. Quelle que soit la taille desquipes d'audit interne, il reste primordial dedisposer des comptences adquates pour lestravaux d'audit spcifiques. Celles-ci peuventexister en interne ou tre recherches enexterne, selon les capacits de l'organisation.

valuer les risques lis aux SI. Les risqueslis aux SI voluent continuellement deconcert avec la technologie. Certains sont lis la technologie elle-mme et d'autres lamanire dont elle est utilise. Ce guide aide leRAI comprendre comment identifier et va-luer au mieux les risques relatifs aux SI. Ainsi,

les ressources de laudit des SI pourront serecentrer sur les domaines qui prsentent leplus de valeur ajoute pour lorganisation.

Raliser des travaux d'audit des SI. Du faitde la prolifration et de la complexit des SI, ildevient indispensable de disposer de proc-dures d'audit des SI appropries, qui peuventtre intgres aux audits de routine des opra-tions et des processus afin de grer les risquesspcifiques identifis durant la phase de pla-nification. Laudit effectu daprs des listes devrification ou sur la base dune enqute estinsuffisant.

En outre, le guide donne au RAI des indicationssur l'ventail de comptences que les auditeursdes SI devraient possder pour apporter desconnaissances et une expertise suffisantes lafonction d'audit, ainsi que des outils pour aiderl'auditeur effectuer les tests lis aux SI et pourrpondre des attentes spcifiques concernant lesrapports. Ce guide a pour objectif de donner desinformations pragmatiques et claires, ainsi que desrecommandations spcifiques qu'un RAI peutmettre en uvre immdiatement. Ce guide veille fournir des critres quun RAI peut utiliser pourvaluer la maturit des capacits en audit des SI ets'assurer que les travaux de l'quipe d'auditinterne correspondent un haut niveau dexi-gence.

GTAG Introduction

5

1. Introduction

Les risques auxquels est confronte lorganisation,les types daudits effectuer, les modalits de prio-risation dans lunivers daudit et la manire de for-muler des constats pertinents sont autant deproccupations des RAI. Ce guide pratique dauditdes technologies de linformation (GTAG) est des-tin aux RAI et aux personnes charges de lasupervision des missions daudit des SI et des testsdes SI intgrs dans d'autres missions.

Il a pour vocation de les aider rpondre auxquestions stratgiques concernant la planification,lexcution et les rapports sur les travaux dauditdes SI. Il tudie les aspects fondamentaux ainsique les nouveaux enjeux. Une valuation annuelledes risques ralise dans le cadre de l'laborationdu plan d'audit qui ne couvre pas les risques infor-matiques serait considre comme dficiente (voirles Normes 1210.A3, 1220.A2 et 2110.A2). L'auditinterne devrait tenir compte de trois aspects :

Un taux important de dispositifs de contrleinterne cl pour lorganisation sont suscepti-bles de reposer sur un systme informatis. Parexemple : la politique dune organisation pr-cise quavant de rgler la facture dun fournis-seur, il convient de procder une triplevrification de cohrence (three way watch),entre un bon de commande, un bon de livrai-son et une facture. Dans le pass, un employrapprochait physiquement les documents, lesagrafait et les classait. Aujourdhui, le progicielde gestion intgr (ERP) procde automati-quement ces rapprochements sur la base dergles prconfigures, et de niveaux de tol-rance. Les carts sont automatiquement enre-gistrs dans des comptes prvus cet effet.Pour auditer efficacement ce contrle, l'audi-teur peut avoir besoin daccder aux param-tres de configuration des systmes ERP, ce quifait appel des comptences techniques quene possdent pas tous les auditeurs.

Les organisations doivent comprendre lesrisques stratgiques induits par les environne-ments complexes des SI. L'adoption des SI

comme facilitateur pour les mtiers modifierales risques stratgiques d'une organisation.Celle-ci doit comprendre ce changement etprendre les mesures appropries pour grerces risques.

Le dveloppement des contrles gnraux desSI et des contrles applicatifs devrait grerconvenablement les risques relatifs aux SI. Lescontrles des SI doivent protger efficacementles activits d'une organisation et garantir quesa comptitivit n'est pas affecte ; les sys-tmes dfectueux risquent de nuire fortement la rputation. Par exemple : considrons leprocessus automatis dcrit ci-dessus, danslequel le bon de commande arriverait via unsite Internet et serait transmis directement lentrept par le progiciel ERP. Si un clientcommande par erreur 100 palettes au lieu de100 units et que lorganisation a entirementintgr ses processus dans lERP ; il est possi-ble que le systme vrifie le stock, constatequil ny a pas 100 palettes disponibles, rvisele plan de production afin de produire 100palettes et envoie automatiquement des bonsde commande pour des matires premires vialchange de donnes informatises (ElectronicData Interchange, EDI). Sans les contrles pr-ventifs ad hoc, cette erreur risquerait de ne pastre dtecte avant la rception des biens parle client.

Une des difficults les plus frquentes est de com-prendre les liens entre contrles des SI, reportingfinancier, fraudes, activits, conformit et autresdomaines cls. Cest relativement facile lorsquevous valuez des contrles dans le cadre dun sys-tme applicatif (par exemple, les paramtres de latriple vrification de cohrence voque ci-dessus). a l'est nettement moins lorsque vousvaluez des technologies connexes qui peuventavoir un impact bien plus important sur l'organi-sation que les contrles propres une seule appli-cation ou un seul processus.

Supposons par exemple quune organisationmette des paiements lectroniques quelle envoie ses fournisseurs. Ces paiements sont achemins

GTAG Introduction

6

par voie lectronique vers des comptes bancairessur la base des numros de routage SWIFT (Societyfor Worldwide Interbank Financial Telecommunica-tion) pour chaque compte fournisseur. Tous lesnumros de lAutomated Clearing House (ACH)sont stocks quelque part dans une table du sys-tme de base de donnes de lorganisation. Unadministrateur de base de donnes, quiconqueayant un droit d'accs la base de donnes, ou desindividus sans droit d'accs mais possdant lescomptences techniques leur permettant d'acc-der la base de donnes peuvent modifier chaqueentre de cette table pour y faire figurer le numroACH de leur propre compte bancaire. Ds qu'unpaiement lectronique est trait, les fonds sontcrdits sur le compte bancaire du contrevenant.Une telle manipulation contournerait tous lesmcanismes de scurit, de contrle et de pistedaudit en place au sein du processus et de lap-plication.

Dans le scnario ci-dessus, il est facile de com-prendre comment la dfaillance dun contrle auniveau de la base de donnes peut produiredavantage de dgts quune dfaillance au niveaudes paramtres de la triple vrification de coh-rence. La probabilit et l'impact potentiel desrisques inhrents l'environnement des SIdevraient donc tre soigneusement pris en comptedans le cadre de l'valuation annuelle des risques.

GTAG Stratgie mtier , processus et projets

7

2. Stratgie mtier ,processus et projets

La stratgie mtier , facteur dterminant pouridentifier l'univers d'audit, est prendre encompte imprativement lors de l'valuation desrisques. La stratgie mtier articule les objectifsde l'organisation et les moyens mettre en uvrepour les atteindre. Il est important que le RAI et lemanagement de l'audit interne comprennent cettestratgie et le rle de la technologie dans l'organi-sation, ainsi que les interactions entre les deux.L'un des outils pouvant tre utilis par le RAI pourvaluer la stratgie mtier d'une organisationet son influence sur les travaux d'audit des SI estle GTAG 11 : laboration d'un plan daudit des SI.Ce guide donne aux RAI des informations sur lacomprhension de l'environnement des SI de l'or-ganisation dans un contexte oprationnel.

Les composantes des SI figurant la section 3 faci-litent lexplication des relations entre les activitsoprationnelles et l'infrastructure des SI, et liden-tification du volet informatique dautres domainesidentifis dans l'univers d'audit lors de lvaluationdes risques.

Une cartographie tendue peut permettre diden-tifier les domaines critiques tels que l'infrastruc-ture, les applications, les processus et les liens (tantinternes qu'externes) pouvant tre soumis desrisques qui n'avaient pas encore t identifis. Ceprocessus de cartographie aidera le RAI valuerles risques relatifs aux SI et les seuils de tolranceau sein de l'organisation, et donne une perspectivepertinente sur les risques non identifis, quidevrait tre communique la direction gnraleet au management des SI.

Gnralement, les ressources spcialises de l'au-dit interne peuvent tre sollicites pour donnerune assurance quant la ralisation dtapes deprojets informatiques. Le RAI devrait valuer leniveau de comptences et de connaissances requispour raliser ces travaux et affecter les ressourcesappropries. Dans certains cas, une expertiseexterne est ncessaire. Pour plus de dtails, se rf-rer au GTAG 12 : Audit des projets SI.

GTAG Infrastructure et processus SI

8

3. Infrastructure etprocessus SI

1. Dfinition des SI

L'une des difficults auxquelles un RAI estconfront lorsqu'il dtermine l'implication des res-sources d'audit informatiques est dapprhenderles usages du SI dans lorganisation. Le tlphoneet les messageries vocales en font-ils partie ? Lessystmes d'accs et d'identification, ainsi que lessystmes de scurit physique devraient-ils treinclus ? Et que faire si ces derniers sont externali-ss ? Voici quelques-unes des questions auxquellesil faut rpondre lorsquil sagit de dterminer com-ment allouer ses ressources daudit des SI.

Les SI sont spcifiques chaque organisation.Deux organisations oprant dans le mme secteurpeuvent avoir des environnements de SI trs dif-frents. Mme au sein d'une mme organisation,les contrles peuvent tre centraliss, dcentralissou les deux la fois. Les ordinateurs portables, lesrseaux sociaux et le cloud repoussent les fron-tires d'un contrle centralis et introduisent desrisques et des facteurs spcifiques.

Cette section aidera les RAI envisager les SI ausein d'une organisation. Certaines composantes

sont intgres des procdures et des processusmanuels et certaines peuvent tre envisages iso-lment. Il existe des risques informatiques danschaque domaine de l'organisation, et ils varientconsidrablement. Pirater le site Internet d'uneorganisation et dtourner un paiement lectro-nique sont, par exemple, des risques trs diffrentspour l'organisation.

2. Tenir compte de chaque niveau duSI

Pour un audit des SI efficace, il est ncessairedtudier et de classer par ordre de priorit lesrisques inhrents chaque niveau du SI et dyallouer les ressources daudit en fonction de cesrisques. Si le volet SI du plan daudit ne prvoitpas une valuation de chacun des niveaux, il estprobable que le plan daudit dans son ensemblene traite pas correctement les risques lis aux SI.

Dans certains cas, il peut se rvler utile de traitertous les niveaux sur plusieurs annes, en faisantun focus particulier chaque anne, au lieu de cou-vrir tous les niveaux sur une seule anne. Les planspar roulement allant au-del de trois ans peuventtre inadquats en raison de la rapidit des chan-gements qui soprent dans lenvironnement desSI.

Management des SI

Infrastructure technique

Fournisseurs

Systmesdexploitation

Base dedonnes Dveloppement

interne dunesolution

transactionnelle

Solutiontransactionnelle

gnriquecorrespondant

lo$re dunprestataire externe

Solutiontransactionnelle

customise par unprestataire externe

Logiciel desupport /assistance

Centre de donnes

Processus des SI

Rseaux

Clients

InternetApplications

Figure 1

GTAG Infrastructure et processus SI

9

Quelles ressources allouer chaque niveau? Aquelles fins ? La rponse ces questions dlicatesdevrait naturellement dcouler des processusdvaluation des risques, du jugement profession-nel et dune analyse stratgique. Au-del de lal-location prcise des ressources, il sagit desassurer que tous les niveaux du SI sont pris encompte.

3. Quels sont les niveaux considrer ?

Le SI dune organisation peut-tre illustr selon lafigure 1.

Chaque organisation est diffrente, mais cettereprsentation aidera identifier les processus clsdes SI dans la plupart des organisations. D'autresmodles d'architecture des SI peuvent tre envi-sags et sont rfrencs l'Annexe A.

Les Technologies de l'information et de la commu-nication (TIC) peuvent tre apprhendes traversles principaux niveaux suivants : le management des systmes dinformation, linfrastructure technique, les applications, les connexions externes.

(Cf. figure 2)

4. Management des systmesdinformation

Le management des SI concerne les personnes, lesrgles, les procdures et les processus qui grentles services et les installations des SI. L'intgritdu traitement et des donnes repose sur les tchesspcifiques rgulirement ralises par le person-nel administratif. En consquence, cette compo-sante englobe la surveillance, la programmation,la planification, la gestion des fournisseurs, la ges-tion des problmes et des incidents, la gestion deschangements, la gestion des projets informatiques,le plan de continuit d'activit, la gestion de lascurit, la gouvernance des SI, etc.

Ces fonctions relvent de processus mtier. L'ap-proche d'audit sera donc similaire une missionclassique. Lauditeur considrera les acteurs etleurs tches, plutt que la configuration dun sys-tme technique. Nanmoins, dans certains cas, lagestion des processus porte sur les installationstechniques que l'audit devra prendre en consid-ration. De mme, certains contrles peuventncessiter des comptences spcialises. En prin-cipe, les comptences d'un auditeur interne exp-riment seront suffisantes.

Risque oprationnel / stratgique

Objectifs oprationnels

Processus mtier

Infrastructure

Assurance

ObjectifsProcdure

Application

TIC

Risques inhrentsau processus

Informationsoprationnelles

Objectifs

Procdure

Application

TIC

Risques inhrentsau processus

Informationsoprationnelles

Figure 2

Attention : ce graphique ne dfinit pas des catgoriesdu plan daudit des SI. La planification des missionsd'audit des SI peut tre organise en fonction des pro-cessus de l'organisation, ou conformment un cadrestandard. Ce graphique a pour objectif d'aider expliciter les liens entre les SI et l'organisation et sassurer que des ressources d'audit sont alloues chaque niveau. Lorganisation d'audits spcifiques estlaisse lapprciation du responsable de lauditinterne.

GTAG Infrastructure et processus SI

10

5. Infrastructure technique

Linfrastructure technique sous-tend, soutient lesprincipales applications mtier et facilite leur miseen uvre. En rgle gnrale, ce niveau com-prend : Les systmes d'exploitation L'ensemble

des programmes qui assurent le fonctionne-ment des ordinateurs. Citons par exempleZ/OS, UNIX, Windows, et OS/400. Tous lesprogrammes et les fichiers sont grs par lesystme d'exploitation. Les actions engagesau niveau du systme dexploitation parvien-nent en gnral contourner la plupart desdispositifs de scurit et des contrles existantau niveau du processus.

Les fichiers et les bases de donnes Toutesles donnes lectroniques de lorganisation,critiques ou autres, sont contenues dans desfichiers qui peuvent faire partie d'une base dedonnes. Les bases de donnes (qui peuventtre un seul fichier ou un groupe de fichiers)comprennent des tables contenant des don-nes, des relations entre des donnes lmen-taires et des index de donnes lmentaires. Laflexibilit des structures d'une base de donnesexplique qu'elles soient utilises pour la plu-part des traitements oprationnels et desapplications de remonte d'informations. Cesbases sont par exemple Oracle, MS SQLServer et DB2. Les actions engages au niveaudes bases de donnes tendent galement contourner la plupart des contrles qui exis-tent au niveau du processus.

Rseaux Pour que les donnes circulentdans une organisation, il faut quelles dispo-sent dun vecteur, qui peut tre un cble, unefibre optique ou un systme sans fil. Le rseause compose d'lments physiques tels que descbles, des appareils qui grent le trafic sur lerseau, comme les commutateurs, les routeursou les pare-feux, et des programmes qui com-mandent la circulation des donnes. Lintgritdu rseau joue un rle important danslexhaustivit et lexactitude des donnes duneorganisation. Par exemple, lorsque l'agent dunentrept prpare lexpdition dun produit enscannant un code-barres, la transaction est

enregistre dans le Grand Livre en passant parle rseau o elle est traite. Mais que se pro-duit-il si elle ne passe pas par le rseau ? Quese passe-t-il si elle est modifie en cours deroute, ou disparat compltement ? Commentlorganisation le saurait-elle ?

Centres de donnes L'quipement infor-matique est situ dans des centres de donneset des salles des serveurs, qui constituent l'in-frastructure physique et assurent, la scuritphysique et environnementale permettant deprotger l'infrastructure technique et les appli-cations.

Les audits de l'infrastructure technique sont axssur la revue des paramtres de configuration tech-nique en association avec les processus de gestiony affrents.

6. Applications

Les applications mtier sont des programmes quiexcutent des tches spcifiques lies aux activitsde lorganisation. Elles font partie intgrante duprocessus mtier et ne peuvent tre considressparment des processus qu'elles soutiennent.Les applications appartiennent gnralement deux catgories : Les solutions transactionnelles sont principa-

lement des logiciels qui traitent et enregistrentles transactions, par exemple des logiciels detraitement des bons de commande, de saisiedans le Grand Livre et de gestion des entre-pts.

Les logiciels support sont des logiciels spcia-liss qui facilitent les activits mtier mais netraitent gnralement pas les transactions. Ilsservent par exemple au stockage des donnes, la messagerie lectronique, la tlcopie, la veille stratgique (business intelligence), lagestion lectronique des documents (GED) et la conception.

Alors que les solutions transactionnelles consti-tuent gnralement lessentiel de leffort daudit,certains logiciels support tels que ceux qui vien-nent en appui du reporting externe ou les appli-

GTAG Infrastructure et processus SI

11

cations qui contrlent des machines peuvent ga-lement tre soumis des risques importants.

L'audit interne doit valuer continuellement lesrisques mergents pour l'organisation et identifierla rponse d'audit requise. Les connaissances sp-cialises requises pour certains aspects des SI peu-vent rendre ce processus complexe.

7. Connexions externes

Le rseau de lorganisation ne fonctionne pas iso-lment. Il est quasiment toujours connect denombreux autres rseaux externes. Internet estcelui qui vient le premier lesprit, mais trop sou-vent, les auditeurs commettent lerreur de ne pasaller au-del.

En ralit, il est fort probable que le rseau de l'en-treprise soit connect de nombreux autresrseaux (dont le cloud et les logiciels des presta-taires de services). Par exemple : lorganisationopre-t-elle via un change de donnes informa-tises (EDI) ? Si tel est le cas, son rseau est cer-tainement connect celui dun prestataire dEDI,ou peut-tre directement au rseau dun parte-naire commercial. Lorganisation externalise-t-ellesa fonction de stockage ? Si oui, les deux rseauxsont aussi probablement relis. Les risques asso-cis aux rseaux d'autres organisations et lescontrles y affrents sont diffrents de ceux appli-cables aux connexions Internet.

Dans la mesure o les organisations continuentdautomatiser leurs processus cls, les tiers ont deplus en plus accs leur rseau, souvent via Inter-net. Prenons par exemple la possibilit de vrifierle solde dun compte bancaire ou ltat davance-ment dune expdition. Les clients qui utilisent cesfonctions entrent probablement dans le rseauinterne de ces entreprises via Internet.

Du fait que lorganisation ne matrise pas lesrseaux extrieurs, les communications provenant(ou transmises vers) des rseaux externesdevraient tre rigoureusement contrles et sur-veilles en fonction du risque qu'elles reprsentent

pour l'organisation. Il peut tre difficile de dfinirdes procdures d'audit des SI pour grer ce risquecar l'organisation ne peut auditer que ce qu'ellecontrle. Il est donc primordial d'auditer au mini-mum les points d'entre et de sortie.

GTAG Approche fonde sur les risques

12

4. Approche fonde sur lesrisques

Toutes les dimensions de la gestion dun servicedaudit interne reposent sur une approche fondesur les risques, notamment l'laboration et lemaintien des programmes d'audit, la gestion desressources humaines et la conduite des missions.Cette section se concentre sur la partie de l'va-luation des risques inhrents aux SI.

L'valuation des risques relatifs aux SI ralise parlaudit interne permet didentifier des missionsd'audit spcifiques plus forte valeur ajoutepotentielle pour la priode considre. Les risquesrelatifs aux SI ne ncessitent pas de mthodologiedistincte. Il est important d'utiliser la mmemthodologie pour tous les types de risques afinde veiller l'homognit du processus d'valua-tion pour l'ensemble de la fonction d'auditinterne.

Les risques sont gnralement exprims en termesde combinaison dimpact et de probabilit doc-currence dun vnement. Il est souvent difficiledvaluer exactement les risques, notamment pourles sries d'vnements peu probables. Les jour-naux d'erreurs et les statistiques donnent des l-ments utiles pour ces valuations. Dans certainscas, l'examen des impacts est suffisant (par exem-ple la perte d'un centre de donnes) et il n'estpas ncessaire de connatre le cheminement desvnements qui en seraient l'origine, ni la pro-babilit d'occurrence pour savoir qu'il faut treattentif au risque.

Il est souvent possible de dfinir des critres quis'appliquent tous les types de risques lis aux SI,mais se manifestent diffremment. Par exemple,l'exposition potentielle peut tre apprhende pardes indicateurs denvergure ou de criticit opra-tionnelle. Par exemple, le nombre d'applicationssous-tendues par un centre de donnes pourraittre indicatif de son niveau de criticit (ventuel-lement pondr en fonction de son importance),et le nombre de serveurs qu'il hberge peut ven-tuellement caractriser sa taille. La taille d'unprojet, en revanche, se mesure son budget, et sa

criticit oprationnelle au nombre d'entits fonc-tionnant l'aide de l'application. Le nombre d'in-cidents recenss ou les projets mens bien parl'organisation peuvent mesurer la probabilit d'oc-currence.

Outre la collecte de donnes, la conduite d'entre-tiens avec les principales parties prenantes tellesque le management des SI, le management op-rationnel et les experts constitue galement unesource importante pour l'valuation des risquesrelatifs aux SI. Les interviews peuvent aider quantifier les risques difficiles mesurer directe-ment.

Il est primordial de tenir compte de l'volutionrapide de la technologie et de son utilisation parlorganisation. Aussi l'valuation des risques doit-elle tre frquemment mise jour. Ceci est parfai-tement illustr par l'importance croissante desproblmatiques de protection de la vie privedcoulant de l'existence et de l'utilisation desrseaux sociaux. Pour une description plus dtail-le de cette problmatique, vous pouvez consulterle Guide pratique de l'IIA, Laudit des risques dat-teinte la vie prive.

Enfin, pour une description plus dtaille de l'va-luation des risques relatifs aux SI, vous pouvezconsulter le GTAG 11 : laboration d'un plan dauditdes SI.

GTAG Univers d'audit

13

5. Univers d'audit

Pour constituer les bases de l'allocation et de laprvision des ressources en audit des SI et pourassurer la couverture ncessaire la fournituredune assurance raisonnable concernant lesrisques relatifs aux SI, les domaines impliquant desSI et ncessitant des comptences spcialises enaudit des SI devraient tre identifis dans l'universd'audit.

Il ne devrait pas y avoir d'univers d'audit des SIdistinct. Les travaux d'audit des SI devraient treintgrs l'univers d'audit global car les SI et lesprocessus mtier qu'ils sous-tendent sont forte-ment interdpendants. Par exemple, les applica-tions informatiques mtier feront gnralementpartie de l'univers d'audit global l'intrieur d'unprocessus mtier. La structuration de l'universd'audit devrait permettre un regroupement partype d'audit et donc une identification des mis-sions ncessitant des comptences spcialises(par exemple, l'audit des applications et des pro-cessus des SI).

Pour les processus de regroupement/structuration,on s'appuie gnralement sur la structure utilisepar le management des SI, qui figure habituelle-ment dans la stratgie des SI. Idalement, cettestructure est base sur des rfrentiels tels queCOBIT, ITIL, COSO (pour de plus amples dtails,voir la section 7), etc.

Dans une organisation complexe, un univers d'au-dit trs dtaill peut facilement comporter des mil-liers d'lments relatifs aux SI. Cet univers d'auditsera alors difficile grer car sa production, sa mise jour, et l'valuation des risques pour tous les l-ments ncessiteront des efforts importants. Enrevanche, si les lments relatifs aux SI sont tropgnraux, ils ne pourront sans doute pas servir debase l'laboration du plan d'audit.

Voici quelques principes importants qui devraienttre suivis lors du dveloppement des composantsSI de l'univers d'audit : Veiller l'exhaustivit en intgrant les l-

ments pertinents, notamment ceux qui peu-

vent ne pas tre vidents (par exemple les acti-vits externalises telles que les prestataires deservices l'tranger, des lments opration-nels trs importants sur le plan des SI et lesprocessus mtier automatiss).

Lors du processus de mise jour, mettre l'ac-cent sur les thmes nouveaux et mergents.Citons par exemple le cloud computing, lesmdias sociaux ou l'utilisation d'appareilsmobiles.

L'univers d'audit ne devrait pas tre tenusecret, mais doit tre partag avec les partiesprenantes concernes (par exemple le mana-gement des SI et d'autres fonctions) afin defavoriser la communication de donnes et desuggestions d'amlioration.

Pour de plus amples informations, voir le GTAG11 : laboration d'un plan daudit des SI.

GTAG Savoir-faire et comptences

14

6. Savoir-faire etcomptences

Une thmatique rcurrente dans de nombreusesorganisations, concerne lcart entre dune partl'utilisation des systmes informatiques et ladpendance des organisations leur gard, etdautre part, les ressources utilises pour identifieret grer les risques dcoulant de ces technologies.Il est donc primordial que la fonction d'auditinterne tienne compte des systmes d'informationlorsqu'elle value les processus de gouvernance,de management des risques et de contrle.

Pour grer ces risques, un RAI doit veiller ce queson quipe possde les comptences requises. Ceciest prconis par le Code de dontologie du Cadre deRfrence International des Pratiques Professionnellesde l'audit interne (CRIPP) de l'IIA, qui exige que lesauditeurs internes effectuent uniquement des ser-vices pour lesquels ils possdent les connais-sances, les comptences et l'exprience requises,ainsi que par la Norme 1210 : Les auditeurs internesdoivent possder les connaissances, le savoir-faire etles autres comptences ncessaires l'exercice de leursresponsabilits individuelles. La fonction d'auditinterne devrait possder ou obtenir, collective-ment, les connaissances, le savoir-faire et autrescomptences ncessaires. L'IIA propose un rf-rentiel des comptences qui aide identifier lescomptences ncessaires l'excution des activitsd'audit interne.

Le RAI devrait obtenir l'avis et l'assistance de per-sonnes qualifies si le service d'audit interne nepossde pas les connaissances, le savoir-faire et lesautres comptences ncessaires pour s'acquitterde tout ou partie d'un audit des SI. Les ressourcesaffectes la ralisation des missions planifiesont un rle critique. Par exemple, les comptencesrequises pour auditer la configuration dun pare-feu sont trs diffrentes de celles ncessaires pourauditer les tables dans une base de donnes. Pourune mission donne requrant telles ou tellescomptences, il est donc essentiel de trouver lau-

diteur adquat. Le RAI doit savoir qu'aucun audi-teur ne peut effectuer tous les travaux d'audit desSI et que souvent, certaines missions ncessitentplutt des comptences concernant des applica-tions et d'autres missions ncessiteront des audi-teurs plus comptents en matire d'infrastructure.

Par consquent, un RAI qui a une bonne appr-hension de lunivers daudit, des risques gnrspar l'utilisation des SI, ainsi que des comptencesen audit des SI dont il dispose, devrait tre mmede cibler les efforts de recrutement et de formationen consquence. En l'absence du savoir-faire etdes comptences informatiques ncessaires, ou s'ilest dcid de ne pas former ou embaucher de col-laborateurs possdant ces comptences, le RAIpeut faire appel un prestataire de services externepour toffer ou complter l'quipe d'audit interne(sous-traitance ou co-sourcing)1.

Pour s'acquitter des responsabilits relatives lau-dit des SI, le RAI devrait se poser des questionscls concernant la gestion des comptences et dusavoir-faire des auditeurs : Toutes les composantes des SI de l'organisa-

tion sont-ils inclus dans le processus de plani-fication et tous les domaines haut risqueont-ils t identifis ?

Existe-t-il une vue d'ensemble de l'ventaildes comptences ncessaires pour auditerl'usage des SI de l'organisation et les comp-tences dj disponibles ?

Le service d'audit dispose-t-il d'une politiquesur la gestion des connaissances manquantes(par exemple recrutement, sous-traitance ouco-sourcing) ?

Les auditeurs des SI possdent-ils la forma-tion, les certifications et l'exprience requises ?Si ce n'est pas le cas, le service d'audit internea-t-il mis en place un plan pour pallier cemanque ?

Le service d'audit interne dispense-t-il la for-mation adquate aux auditeurs pour appr-hender lusage du SI, les risques y affrents etles modalits daudit appropris ?

1 Pour de plus amples dtails, voir la MPA 1210.A1-1 : Recours des prestataires externes.

GTAG Raliser des missions d'audit des SI

15

7. Raliser des missionsd'audit des SI

Le droulement de missions d'audit des SI nestgnralement pas diffrent de celui dautres mis-sions. Lauditeur planifie, identifie et documenteles contrles pertinents, vrifie lefficacit de laconception et du fonctionnement de ces contrles,en tire des conclusions et rdige son rapport.Puisque la plupart des responsables de lauditinterne connaissent bien ce processus gnral, ilnest pas rappel ici. Toutefois, le RAI doit conna-tre et grer certaines problmatiques relatives auxmissions d'audit des SI.

1. Collaboration entre auditeurs desSI et autres auditeurs

Lorsqu'il effectue une mission, l'audit internedevrait s'efforcer d'avoir une perspective globale.Certains domaines des SI seront probablementaudits exclusivement par des spcialistes des SI(principalement ceux qui sont axs sur l'infrastruc-ture tels que les centres de donnes, les rseaux,ou les processus des SI comme les services d'as-sistance) ; en revanche, pour les revues des appli-cations, l'audit de l'ensemble de la chane devaleur, incluant les mtiers et les SI, apportera leplus grand bnfice. Ces types de missionsdevraient se concentrer sur les objectifs opration-nels et tous les risques (dont ceux relatifs aux SI)doivent tre valus selon cette perspective. Cetexercice peut tre difficile, mais galement trspositif car il permet de cerner les liens de dpen-dance du mtier vis--vis des SI. Par exemple, siles missions d'audit des SI rvlent qu'il n'existepas de plan de continuit d'activit, les auditeursdes SI et les auditeurs oprationnels peuvent col-laborer pour dcrire l'impact de la dure de l'in-terruption anticip dans le scnario de crise pourle mtier (par exemple, en termes de baisse de laproduction, retards dans le paiement des salaires,impossibilit de vendre des produits). Peu importequi est responsable des audits spcifiques, l'atten-tion de laudit interne devrait tre centre sur lacollaboration pour obtenir des rsultats optimaux.

2. Cadres de rfrence et normes

Lune des difficults que rencontrent les auditeurslorsquils effectuent un audit des SI est la dtermi-nation dun rfrentiel. La plupart des organisa-tions nont pas labor de rfrences de contrledes SI pour toutes les applications et technologies.Lvolution rapide de la technologie pourraitrendre ces rfrences rapidement obsoltes etdonc inutiles.

Un RAI devrait avoir une srie dobjectifs decontrle des SI, et devrait pouvoir trouver un cadrede rfrence appropri mme sil nest pas 100%adapt son environnement.

3. COSO et COBIT

O un RAI peut-il trouver une srie cohrentedobjectifs de contrle des SI ? Les cadres de rf-rence Contrle interne et management des risques delentreprise du Committee of Sponsoring Organiza-tions of the Treadway Commission (COSO) consti-tuent des sources d'information frquemmentconsultes, mais ils ne sont pas spcifiquementaxs sur les SI. Lenvironnement de contrle repo-sant sur le COSO devrait tre complt par desobjectifs de contrle des SI plus dtaills, qui per-mettront dvaluer plus efficacement lenvironne-ment de contrle des SI. Il existe un certainnombre de possibilits cet gard.

Le CobiT (Control Objectives for Information andrelated Technology), initialement publi en 1994 parlISACA (Information Systems Audit and ControlAssociation), est lun des rfrentiels de contrle etde gouvernance des SI couramment utilis. La ver-sion 5.0 du CobiT a t publie en 2012. Le CobiTn'a pas pour vocation de concurrencer le COSOou d'autres rfrentiels, mais peut tre utilis pourles complter en les enrichissant avec des objectifsde contrle des SI plus cibls.

GTAG Raliser des missions d'audit des SI

16

4. Rgles, normes et procdures

Un rfrentiel comme le CobiT propose une sriedobjectifs de contrle des SI communmentadmis, qui aide le management concevoir unepolitique dvaluation et de gestion des risques lisaux SI. Le management se sert gnralement duntel rfrentiel pour le dveloppement dun sys-tme cohrent de rgles, normes et procduresrelatives aux SI. L'Annexe A donne une vue d'en-semble des sources pertinentes pour les rgles, lesnormes et les procdures.

GTAG Rapports

17

8. Rapports

Comme pour tous les autres travaux d'auditinterne, les RAI rendent compte rgulirement desrsultats des missions d'audit des SI aux princi-pales parties prenantes telles que le Conseil1, ladirection gnrale, le directeur des systmes d'in-formation, les rgulateurs et les auditeurs externes.Pour des lignes directrices plus dtailles sur lafaon de communiquer avec les principales partiesprenantes, voir le guide pratique de l'IIA, Interac-tion with the board.

Les destinataires des rapports d'audit peuventappartenir des niveaux hirarchiques plus levsque ceux qui sont interviews ou qui excutent lescontrles. Il est donc ncessaire de communiquerprcisment et clairement les informations les plusimportantes, de faon ce que les constats ou lesenjeux soient compris et que le managementpuisse ragir. Il est inutile d'effectuer un audit dequalit si le management ne met pas en uvre desplans d'action efficaces pour grer les problma-tiques et les risques identifis. Le management nes'intresse gnralement pas aux dtails du pro-cessus d'audit. Il souhaite connatre les dfail-lances, leurs consquences potentielles et lesmesures prendre pour y remdier.

Lorsqu'il effectue une mission, l'auditeur internedevrait s'efforcer d'avoir une perspective globale.La plupart des organisations tant dpendantesdes SI, les rapports sur les risques et les contrlesrelatifs aux SI devraient faire partie des activitsd'assurance du RAI. Si des processus SI et l'infra-structure SI peuvent (et peut-tre devraient pourdes raisons d'efficacit) tre audits sparment,en rgle gnrale, l'audit de l'ensemble de lachane de valeur (dont les mtiers et les SI) appor-tera le plus grand bnfice. Ces types d'audit peu-vent tre nettement plus axs sur les risquesoprationnels, qui sont plus facilement communi-

qus au management que les risques relatifs auxSI. Les risques relatifs aux SI dbouchent in finesur des risques oprationnels, mais le lien entre lesdeux n'est pas toujours clair.

Un certain nombre de questions concernant lacommunication se posent : Convient-il de proc-der un audit des rseaux sans fil, un audit delarchitecture et de la conception des rseaux oubien une revue de la conception dune applica-tion lectronique ? Si les missions sont ainsi dis-socies, il y a fort parier que les constatsporteront sur des dtails pour chaque technologie.Pour certains publics, cette approche pourrait treapproprie, mais le Conseil ou la direction gn-rale pourraient ne pas s'intresser ou comprendreles dtails des questions techniques. Ils veulentgnralement que les constats d'audit soient relisaux problmatiques oprationnelles. En cons-quence, les travaux d'audit des SI doivent s'int-grer aux travaux des auditeurs de processus /oprationnels / financiers et aux procdures qu'ilsmettent en uvre. Ceci est particulirement vraidans les environnements comportant des applica-tions ERP importantes, dont les systmes compor-tent un grand nombre de contrles cls deprocessus. N'oublions pas que dans certains cas,l'audit de composants centraux de l'infrastructuretels que les centres de donnes ou les rseaux sansfil sera difficile ; il sera donc pertinent d'auditerindividuellement ces domaines. Toutefois, lesrisques identifis durant la mission doivent tretraduits en langage oprationnel et en risquesmtier.

Les rapports devraient tre rdigs pour des lec-teurs avertis, mais qui ne possdent peut-tre pasd'exprience spcifique dans le domaine audit, etle message ne doit tre ni dlay ni noy dans unlangage technique. L'objectif du RAI est de pr-senter un message clair, comprhensible et qui-libr.

1 Le terme Conseil est utilis au sens donn dans le glossaire des Normes, savoir : Le niveau le plus lev des organes de gouvernance, responsabledu pilotage, et/ou de la surveillance des activits et de la gestion de l'organisation. Habituellement, le Conseil (par exemple, un conseil dadministration,un conseil de surveillance ou un organe dlibrant) comprend des administrateurs indpendants. Si une telle instance nexiste pas, le terme Conseil ,utilis dans les Normes, peut dsigner le dirigeant de lorganisation. Le terme Conseil peut renvoyer au comit daudit auquel lorgane de gouver-nance a dlgu certaines fonctions.

GTAG Outils daudit

18

9. Outils d'audit

Les RAI devraient chercher utiliser des outilset/ou des techniques pour accrotre l'efficience etl'efficacit de l'audit. En rgle gnrale, les outilsd'audit requirent un investissement, si bien quele RAI devrait soigneusement valuer le rapportcot/avantages de toute solution avant de syengager. Les outils daudit peuvent tre rpartis endeux catgories : les facilitateurs daudit (qui nesont pas abords ici), qui viennent en support duprocessus global daudit (par exemple un outil degestion des documents de travail lectroniques), etles outils de tests : outils qui automatisent la ra-lisation des tests daudit (comme les outils dana-lyse des donnes et les techniques daudit assistpar ordinateur).

1. Outils de tests des SI

Les outils de tests permettent dautomatiser destches daudit chronophages, comme lexamen devastes bases de donnes. En outre, le recours unoutil pour excuter des procdures daudit confreune certaine cohrence. Par exemple, si un outil estutilis pour valuer la configuration de la scuritdun serveur, tous les serveurs tests au moyen decet outil seront valus par rapport aux mmes cri-tres. Excuter ces procdures manuellementlaisse du champ une interprtation de la part delauditeur. Enfin, lutilisation de ces outils permetaux auditeurs de tester la totalit dune base dedonnes, et non un simple chantillon de transac-tions, do un niveau dassurance bien suprieur.

Les RAI devraient savoir que les mmes consid-rations s'appliquent tant l'acquisition d'outilsd'audit des SI quau choix de n'importe quel autreoutil oprationnel (par exemple fonctionnalit,support).

Outils danalyse de la scurit

Un vaste ensemble doutils permettent dexaminerdiffrentes catgories de dispositifs et/ou dutilisa-teurs, et de dceler les expositions des risqueslis la scurit. Il existe de nombreux types

d'analyse de la scurit, les principaux tant lesoutils d'analyse de rseau :

Outils danalyse de rseau Ces outils sont desprogrammes logiciels qui peuvent tre lancs surun rseau pour y recueillir des informations. Clas-siquement, les pirates informatiques utilisent cetype doutils au dbut dune attaque afin de dter-miner la structure du rseau. Les auditeurs des SIpeuvent y recourir pour diverses procdures dau-dit, notamment : La vrification de lexactitude des diagrammes

de rseau par une cartographie du rseau, Lidentification des dispositifs cls du rseau

qui appellent une attention supplmentaire dela part des auditeurs,

La collecte des informations concernant letrafic autoris sur un rseau (tayant directe-ment le processus dvaluation des risques lisaux SI).

Outils d'valuation de la vulnrabilit

La plupart des technologies, lorsquelles ne sontpas personnalises, souffrent dun certain nombrede vulnrabilits standard, comme lexistencedidentifiants, de mots de passe ou de paramtrespar dfaut. Ces outils d'valuation offrent unesolution automatise pour vrifier ces vulnrabili-ts.

Ces outils peuvent tre utiliss pour les pare-feux,les serveurs, les rseaux et les systmes dexploi-tation. Nombre de ces outils sont prts utili-ser ( plug and go ) : lauditeur les branche surtout ce quil souhaite analyser, et l'outil produit unrapport des vulnrabilits identifies.

Il est important que lauditeur exploite ce typedoutils pour plusieurs raisons, notamment parceque ce sont les outils quun pirate informatiqueutiliserait pour monter une attaque contre lorga-nisation. Nanmoins, il convient de les utiliseravec vigilance car certains de ces outils sont poten-tiellement dangereux et peuvent compromettrelintgrit des systmes quils scannent. Lauditeurdevrait examiner avec le responsable de la scuritlutilisation quil prvoit de faire de ces outils et

GTAG Outils daudit

19

coordonner les tests avec le management des SIafin de veiller ce que le calendrier des tests naf-fecte pas la production. Dans certains cas, le res-ponsable de la scurit ou les administrateurssystmes emploient dj rgulirement certains deces outils dans le cadre des processus de gestiondes systmes. Si tel est le cas, il peut tre envisagdexploiter ces rsultats dans les travaux d'auditdes SI, sils sont correctement conus et excuts.

Outils danalyse des applicatifs de scurit

Bon nombre d'applications intgres comportentdes outils d'analyse de la scurit en fonction dergles prconfigures. Ces outils peuvent gale-ment valuer la sparation des fonctions au seindune application. Le RAI devrait tre conscient dufait que la plupart de ces outils sont assortis dunensemble de rgles prconfigures ou proposespar le fournisseur comme relevant des meilleurespratiques .

GTAG Conclusion

20

10. Conclusion

Lapparition de nouveaux risques lis la techno-logie impose de repenser les procdures pour biengrer ces risques. Il ne fait aucun doute qu'au coursdes 15 dernires annes, la technologie a modifila nature de la fonction daudit interne.Aujourdhui, les RAI devraient sinterroger sur lesrisques auxquels est confronte lorganisation, lestypes daudits effectuer, les modalits de priori-sation dans lunivers daudit et sur la manire decommuniquer des constats pertinents au Conseilet la direction gnrale.

La stratgie mtier guide la dfinition de l'universd'audit et l'valuation des risques. Elle dtermineles lments importants pour le Conseil et lemanagement, et les domaines dans lesquels lesactivits sont susceptibles de changer. Il est doncimportant que le RAI comprenne tant la stratgiemtier que le rle des SI dans l'organisation etl'impact qu'ils ont l'un sur l'autre.

Lorsque le RAI cartographie les activits de l'or-ganisation et son infrastructure, il peut observer defaon privilgie l'impact des diffrentes relationsentre les SI et les mtiers. Les projets SI sont sou-vent des lments cls du changement, dans lesorganisations, et le mcanisme utilis par le mana-gement pour mettre en uvre la stratgie opra-tionnelle.

Les difficults auxquelles un RAI est initialementconfront lorsqu'il dveloppe les composantes SIdu plan d'audit concernent l'identification desactivits SI au sein de l'organisation. Sachant queles environnements des SI sont trs diversifis, unRAI peut chercher dfinir les SI en termes decomposantes. Chaque composante est diffrenteet importante la fois. L'utilisation d'uneapproche fonde sur les risques est un conceptgnral qui s'applique quasiment toutes les acti-vits d'audit interne. L'univers d'audit devrait tenircompte des SI car il existe des interdpendancesimportantes entre les SI et les mtiers.

Pour grer ces risques, un RAI doit veiller ce queson quipe possde les comptences requises. En

outre, les RAI devraient chercher utiliser desoutils et/ou des techniques pour accrotre l'effi-cience et l'efficacit de l'audit. Comme pour n'im-porte quel outil, les outils d'audit requirent uninvestissement en temps et en ressources, si bienque le RAI devrait soigneusement valuer le rap-port cot/avantages de toute solution avant de syengager.

Enfin, le processus pour raliser une mission rela-tive aux risques SI nest gnralement pas diffrentde celui dautres travaux d'audit : lauditeur plani-fie la mission, identifie et documente les contrlespertinents, vrifie lefficacit de la conception et dufonctionnement de ces contrles, en tire desconclusions et rdige son rapport. De mme, lesRAI rendent compte rgulirement des rsultatsdes travaux d'audit des SI aux principales partiesprenantes telles que le Conseil, la direction gn-rale, le directeur des systmes d'information, lesrgulateurs et les auditeurs externes.

GTAG Annexe A : Normes de rfrence

21

Annexe A : Normes derfrence

Les normes cites ci-aprs peuvent tre prises enconsidration :

ISO 27001 ISO 27001/ISO 17799 LOrganisa-tion internationale de normalisation (ISO) a ditune norme gnrique sur la scurit des SI recon-nue lchelle internationale. Il sagissait audpart dune norme britannique (BS 7799), qui at transforme en norme ISO et qui est dsor-mais connue sous lappellation ISO 27001. Elleprsente les bonnes pratiques communmentadmises concernant la gestion de la scurit des SIet constitue un document de rfrence utile partir duquel les auditeurs des SI peuvent mener bien leurs missions.

http://www.iso.org

Capability Maturity Model Integration(CMMI) Le Software Engineering Institute (SEI)de luniversit Carnegie Mellon a labor leconcept de Capability Maturity Models (CMM,modles de maturit des capacits) relatifs dif-frents processus au sein dune organisation,notamment en ce qui concerne le dploiement delogiciels. L'approche la plus rcente est CMMI.

http://www.sei.cmu.edu

United States Computer Security ResourceCenter Le United States Computer SecurityResource Center est une division du National Ins-titute of Standards and Technology (NIST) qui pro-pose une srie complte de publications offrantdes informations dtailles sur le contrle de lascurit des SI. Parmi ses publications, citons Guidelines for Securing Wireless Local Area Net-works (WLAN) et Guidelines on Security andPrivacy in Public Cloud Computing. Ces normesnoncent des bonnes pratiques qui peuvent treutilises dans tous les secteurs.

http://csrc.nist.gov

SysAdmin, Audit, Network, Security (SANS)Institute Source dinformation parmi les plusfiables pour ce qui est de la formation et de la sen-sibilisation la scurit des SI, le SANS Institutepublie de nombreux documents traitant des diff-rents aspects de la scurit pour diverses techno-logies. Les publications du SANS exposent uncertain nombre de critres incontournables auregard desquels lauditeur des SI peut effectuerson audit.

http://www.sans.org

IT Infrastructure Library (ITIL) L'ITIL est l'ap-proche la plus gnralement admise de la gestiondes services des SI dans le monde. L'ITIL donneun ensemble homogne de meilleures pratiquestires des secteurs public et priv l'chelle inter-nationale.

http://www.itil-officialsite.com

Normes propres aux fournisseurs De nom-breux fournisseurs de solutions technologiquespublient des recommandations sur la scurit et lecontrle applicables la technologie quils produi-sent. SAP, par exemple, dite un guide sur la scu-rit qui nonce des recommandations dtaillespour la scurit et les contrles de lapplicationSAP ERP. Souvent, ces normes fournisseurs neprennent pas en compte la scurit et le contrleau mme niveau que, par exemple, une publica-tion NIST, mais elles donnent une bonne base dedpart. Les RAI devraient donc vrifier auprs desfournisseurs de systmes critiques pour les mis-sions si des normes spcifiques sont disponibles.Dans bien des cas, les fournisseurs nont rienpubli, mais le groupe dutilisateurs associ cettetechnologie a dit une ou des publication(s) (parexemple les diffrents groupes dutilisateurs deSAP aux tats-Unis).

GTAG Annexe B : Modles d'architecture des SI

22

Annexe B : Modlesd'architecture des SI

Les modles d'architecture des SI et les rfrencespouvant tre pris en compte sont :

The Abu Dhabi IT Architecture & StandardsFramework Bas sur un rfrentiel comportanthuit niveaux, il couvre tous les aspects d'un envi-ronnement des SI notamment : Mtiers, Accs etprsentation, Application, Donnes, Intgration,Infrastructure, Scurit et Exploitation.

http://adsic.abudhabi.ae

AndroMDA Des applications modernes sontconstruites l'aide de plusieurs composantsconnects les uns aux autres, chacun d'entre euxayant une fonctionnalit spcifique. Les compo-sants qui effectuent des fonctions similaires sontgnralement regroups en niveaux. Ces niveauxsont organiss en pile dans laquelle les compo-sants d'un niveau utilisent les services de compo-sants d'un niveau infrieur. Un composant dansun niveau donn utilisera gnralement la fonc-tionnalit d'autres composants de son propreniveau ou de niveaux infrieurs.

http://www.andromda.org

TOGAF The Open Group Architecture Foruma dvelopp et maintient le TOGAF, une normereconnue au niveau mondial en matire d'archi-tecture d'entreprise.

http://www.opengroup.org

GTAG Auteurs et relecteurs

23

Auteurs et relecteursAuteursStephen Coates, CIA, CGAP, CISAMax Haege Rune Johannessen, CIA , CCSA, CRMA , CISAJacques Lourens, CIA , CISA, CGEIT , CRISCCesar L. Martinez, CIA , CGAP

RelecteursSteve Hunt, CIA , CRMA , CISA, CGEITSteve Jameson, CIA , CCSA, CFSA, CRMA

RviseursMarie-Elisabeth Albert, CIABatrice Ki-Zerbo, CIAGilles Trolez

A PROPOS DE LINSTITUTE OF INTERNAL AUDITORS

Fond en 1941, The Institute of Internal Auditors (IIA) est une organisation professionnelle internationale dont lesige mondial se situe Altamonte Springs, en Floride, aux tats-Unis. LInstitute of Internal Auditors est la voixmondiale, une autorit reconnue, un leader incontest et le principal dfenseur de la profession dauditeur interne.Cest galement un acteur de premier plan pour la formation des auditeurs internes. Il est reprsent en Francepar lIFACI.

A PROPOS DES GUIDES PRATIQUES

Les guides pratiques dtaillent la ralisation des activits daudit interne. Ils contiennent des processus et des pro-cdures, tels que les outils et techniques, les programmes et les approches pas--pas, et donnent des exemples delivrables. Les guides pratiques sinscrivent dans le Cadre de rfrence international des pratiques professionnellesde l'audit interne de lInstitute of Internal Auditors. Ces guides pratiques relvent de la catgorie des dispositionsfortement recommandes. La conformit ces guides pratiques nest donc pas obligatoire, mais fortement recom-mande. Ces guides ont t officiellement rviss et approuvs par lIIA.Le Global Technologies Audit Guide (GTAG) est un type de guide pratique qui aborde, dans un langage courant,une question dactualit lie la gestion, au contrle ou la scurit des technologies de linformation.Pour de plus amples informations sur les documents de rfrence proposs par lInstitute, vous pouvez consulternotre site Web, www.theiia.org.guidance ou www.ifaci.com.

AVERTISSEMENT

LInstitute of Internal Auditors publie ce document titre informatif et pdagogique. Cette ligne directrice na pasvocation apporter de rponses dfinitives des cas prcis, et doit uniquement servir de guide. LInstitute ofInternal Auditors vous recommande de toujours solliciter un expert indpendant pour avoir un avis dans chaquesituation. LInstitute dgage sa responsabilit pour les cas o des lecteurs se fieraient exclusivement ce guide.

COPYRIGHT

Le copyright de ce guide pratique est dtenu par lInstitute of Internal Auditors et par lIFACI pour sa version fran-aise. Pour lautorisation de reproduction, prire de contacter lInstitute of Internal Auditors ladresseguidance@theiia.org ou lIFACI ladresse recherche@ifaci.com.

The Institute of Internal Auditors IFACI247 Maitland Avenue, Altamonte Springs 98bis, Boulevard HaussmannFlorida 32701, tats-Unis 75008 PARIS, FranceTlphone : +1 407 937 1100 Tlphone : 01 40 08 48 00Tlcopie : 1 407 937 1101 Fax : 01 40 08 48 20Site Web : www.theiia.org Site Web : www.ifaci.comCourrier lectronique : guidance@theiia.org Courrier lectronique : recherche@ifaci.com

ContenuRsum1. Introduction2. Stratgie mtier , processus et projets3. Infrastructure et processus SI4. Approche fonde sur les risques5. Univers d'audit6. Savoir-faire et comptences7. Raliser des missions d'audit des SI8. Rapports9. Outils d'audit10. ConclusionAnnexe A : Normes de rfrenceAnnexe B : Modles d'architecture des SIAuteurs et relecteurs