Management de l’auditdes systèmes d’information

2ème édition

Janvier 2013

Copyright © 2013 par l’Institute of Internal Auditors, 247 Maitland Ave., Altamonte Springs, Floride, 32701-4201,États-Unis. Tous droits réservés. Imprimé aux États-Unis. Aucune partie de cette publication ne peut être reproduite,stockée dans un système de consultation ou transmise sous quelque forme que ce soit, ni par aucun moyen (électro-nique, mécanique, reprographie, enregistrement ou autre) sans autorisation écrite préalable de l’éditeur.

L’IIA publie ce document à titre informatif et pédagogique. Cette publication entend donner des informations, maisne se substitue en aucun cas à un conseil juridique ou comptable. L’IIA ne fournit pas ce type de service et ne garantit,par la publication de ce document, aucun résultat juridique ou comptable. En cas de problèmes juridiques ou comp-tables, il convient de recourir à l’assistance de professionnels.

Contenu

3

Résumé ............................................................................................................................................................. 4

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

2. Stratégie « métier », processus et projets ............................................................................................ 7

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

4. Approche fondée sur les risques ........................................................................................................ 12

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

6. Savoir-faire et compétences ............................................................................................................... 14

7. Réaliser des missions d'audit des SI .................................................................................................. 15

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

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

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

Annexe A : Normes de référence ................................................................................................................. 21

Annexe B : Modèles d'architecture des SI ................................................................................................... 22

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

Résumé

4

Résumé

Les systèmes d’information (SI) ont une influenceomniprésente sur l'audit interne. L’émergence denouveaux risques implique de repenser les procé-dures pour gérer ces risques de façon adéquate. Leprocessus d'audit des SI n’est globalement pas dif-férent de celui d’autres travaux d'audit : l’auditeurplanifie la mission, identifie et documente lescontrôles pertinents, vérifie l’efficacité de laconception et du fonctionnement de ces contrôles,en tire les conclusions et rédige son rapport. Lesresponsables de l'audit interne (RAI) rendentrégulièrement compte des conclusions des mis-sions d'audit des SI aux principales parties pre-nantes telles que le Conseil, la direction générale,le directeur des systèmes d'information, les régu-lateurs et les auditeurs externes. Ce guide a pourobjectif d'aider les RAI à planifier et à gérer les tra-vaux d'audit avec une efficacité et une efficienceaccrues en analysant comment :

• Déterminer les domaines nécessitant desressources en audit des SI. Quelles sont lesmissions qui nécessiteront l'intervention despécialistes en audit des SI ? A la lumière deslignes directrices exposées dans ce document,le RAI devrait être à même de planifier lerecours à des auditeurs des SI pour une cou-verture adéquate de périmètre à auditer. Lesressources en audit des SI sont généralementrares, alors que la demande est forte. Définirles besoins en audit des SI permet au RAI d’as-surer la réalisation des missions planifiéesdans ce domaine. Quelle que soit la taille deséquipes d'audit interne, il reste primordial dedisposer des compétences adéquates pour lestravaux d'audit spécifiques. Celles-ci peuventexister en interne ou être recherchées enexterne, selon les capacités de l'organisation.

• Évaluer les risques liés aux SI. Les risquesliés aux SI évoluent continuellement deconcert avec la technologie. Certains sont liésà la technologie elle-même et d'autres à lamanière dont elle est utilisée. Ce guide aide leRAI à comprendre comment identifier et éva-luer au mieux les risques relatifs aux SI. Ainsi,

les ressources de l’audit des SI pourront serecentrer sur les domaines qui présentent leplus de valeur ajoutée pour l’organisation.

• Réaliser des travaux d'audit des SI. Du faitde la prolifération et de la complexité des SI, ildevient indispensable de disposer de procé-dures d'audit des SI appropriées, qui peuventêtre intégrées aux audits de routine des opéra-tions et des processus afin de gérer les risquesspécifiques identifiés durant la phase de pla-nification. L’audit effectué d’après des listes devérification ou sur la base d’une enquête estinsuffisant.

En outre, le guide donne au RAI des indicationssur l'éventail de compétences que les auditeursdes SI devraient posséder pour apporter desconnaissances et une expertise suffisantes à lafonction d'audit, ainsi que des outils pour aiderl'auditeur à effectuer les tests liés aux SI et pourrépondre à des attentes spécifiques concernant lesrapports. Ce guide a pour objectif de donner desinformations pragmatiques et claires, ainsi que desrecommandations spécifiques qu'un RAI peutmettre en œuvre immédiatement. Ce guide veilleà fournir des critères qu’un RAI peut utiliser pourévaluer la maturité des capacités en audit des SI ets'assurer que les travaux de l'équipe d'auditinterne correspondent à un haut niveau d’exi-gence.

GTAG – Introduction

5

1. Introduction

Les risques auxquels est confrontée l’organisation,les types d’audits à effectuer, les modalités de prio-risation dans l’univers d’audit et la manière de for-muler des constats pertinents sont autant depréoccupations des RAI. Ce guide pratique d’auditdes technologies de l’information (GTAG) est des-tiné aux RAI et aux personnes chargées de lasupervision des missions d’audit des SI et des testsdes SI intégrés dans d'autres missions.

Il a pour vocation de les aider à répondre auxquestions stratégiques concernant la planification,l’exécution et les rapports sur les travaux d’auditdes SI. Il étudie les aspects fondamentaux ainsique les nouveaux enjeux. Une évaluation annuelledes risques réalisée dans le cadre de l'élaborationdu plan d'audit qui ne couvre pas les risques infor-matiques serait considérée comme déficiente (voirles Normes 1210.A3, 1220.A2 et 2110.A2). L'auditinterne devrait tenir compte de trois aspects :

• Un taux important de dispositifs de contrôleinterne clé pour l’organisation sont suscepti-bles de reposer sur un système informatisé. Parexemple : la politique d’une organisation pré-cise qu’avant de régler la facture d’un fournis-seur, il convient de procéder à une triplevérification de cohérence (three way watch),entre un bon de commande, un bon de livrai-son et une facture. Dans le passé, un employérapprochait physiquement les documents, lesagrafait et les classait. Aujourd’hui, le progicielde gestion intégré (ERP) procède automati-quement à ces rapprochements sur la base derègles préconfigurées, et de niveaux de tolé-rance. Les écarts sont automatiquement enre-gistrés dans des comptes prévus à cet effet.Pour auditer efficacement ce contrôle, l'audi-teur peut avoir besoin d’accéder aux paramè-tres de configuration des systèmes ERP, ce quifait appel à des compétences techniques quene possèdent pas tous les auditeurs.

• Les organisations doivent comprendre lesrisques stratégiques induits par les environne-ments complexes des SI. L'adoption des SI

comme facilitateur pour les métiers modifierales risques stratégiques d'une organisation.Celle-ci doit comprendre ce changement etprendre les mesures appropriées pour gérerces risques.

• Le développement des contrôles généraux desSI et des contrôles applicatifs devrait gérerconvenablement les risques relatifs aux SI. Lescontrôles des SI doivent protéger efficacementles activités d'une organisation et garantir quesa compétitivité n'est pas affectée ; les sys-tèmes défectueux risquent de nuire fortementà la réputation. Par exemple : considérons leprocessus automatisé décrit ci-dessus, danslequel le bon de commande arriverait via unsite Internet et serait transmis directement àl’entrepôt par le progiciel ERP. Si un clientcommande par erreur 100 palettes au lieu de100 unités et que l’organisation a entièrementintégré ses processus dans l’ERP ; il est possi-ble que le système vérifie le stock, constatequ’il n’y a pas 100 palettes disponibles, révisele plan de production afin de produire 100palettes et envoie automatiquement des bonsde commande pour des matières premières vial’échange de données informatisées (ElectronicData Interchange, EDI). Sans les contrôles pré-ventifs ad hoc, cette erreur risquerait de ne pasêtre détectée avant la réception des biens parle client.

Une des difficultés les plus fréquentes est de com-prendre les liens entre contrôles des SI, reportingfinancier, fraudes, activités, conformité et autresdomaines clés. C’est relativement facile lorsquevous évaluez des contrôles dans le cadre d’un sys-tème applicatif (par exemple, les paramètres de latriple vérification de cohérence évoquée ci-dessus). Ça l'est nettement moins lorsque vousévaluez des technologies connexes qui peuventavoir un impact bien plus important sur l'organi-sation que les contrôles propres à une seule appli-cation ou un seul processus.

Supposons par exemple qu’une organisationémette des paiements électroniques qu’elle envoieà ses fournisseurs. Ces paiements sont acheminés

GTAG – Introduction

6

par voie électronique vers des comptes bancairessur la base des numéros de routage SWIFT (Societyfor Worldwide Interbank Financial Telecommunica-tion) pour chaque compte fournisseur. Tous lesnuméros de l’Automated Clearing House (ACH)sont stockés quelque part dans une table du sys-tème de base de données de l’organisation. Unadministrateur de base de données, quiconqueayant un droit d'accès à la base de données, ou desindividus sans droit d'accès mais possédant lescompétences techniques leur permettant d'accé-der à la base de données peuvent modifier chaqueentrée de cette table pour y faire figurer le numéroACH de leur propre compte bancaire. Dès qu'unpaiement électronique est traité, les fonds sontcrédités sur le compte bancaire du contrevenant.Une telle manipulation contournerait tous lesmécanismes de sécurité, de contrôle et de pisted’audit en place au sein du processus et de l’ap-plication.

Dans le scénario ci-dessus, il est facile de com-prendre comment la défaillance d’un contrôle auniveau de la base de données peut produiredavantage de dégâts qu’une défaillance au niveaudes paramètres de la triple vérification de cohé-rence. La probabilité et l'impact potentiel desrisques inhérents à l'environnement des SIdevraient donc être soigneusement pris en comptedans le cadre de l'évaluation annuelle des risques.

GTAG – Stratégie « métier », processus et projets

7

2. Stratégie « métier »,processus et projets

La stratégie « métier », facteur déterminant pouridentifier l'univers d'audit, est à prendre encompte impérativement lors de l'évaluation desrisques. La stratégie « métier » 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 cettestratégie et le rôle de la technologie dans l'organi-sation, ainsi que les interactions entre les deux.L'un des outils pouvant être utilisé par le RAI pourévaluer la stratégie « métier » d'une organisationet son influence sur les travaux d'audit des SI estle GTAG 11 : Élaboration d'un plan d’audit des SI.Ce guide donne aux RAI des informations sur lacompréhension de l'environnement des SI de l'or-ganisation dans un contexte opérationnel.

Les composantes des SI figurant à la section 3 faci-litent l’explication des relations entre les activitésopérationnelles et l'infrastructure des SI, et l’iden-tification du volet informatique d’autres domainesidentifiés dans l'univers d'audit lors de l’évaluationdes risques.

Une cartographie étendue peut permettre d’iden-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é identifiés. Ceprocessus de cartographie aidera le RAI à évaluerles risques relatifs aux SI et les seuils de toléranceau sein de l'organisation, et donne une perspectivepertinente sur les risques non identifiés, quidevrait être communiquée à la direction généraleet au management des SI.

Généralement, les ressources spécialisées de l'au-dit interne peuvent être sollicitées pour donnerune assurance quant à la réalisation d’étapes deprojets informatiques. Le RAI devrait évaluer leniveau de compétences et de connaissances requispour réaliser ces travaux et affecter les ressourcesappropriées. Dans certains cas, une expertiseexterne est nécessaire. Pour plus de détails, se réfé-rer au GTAG 12 : Audit des projets SI.

GTAG – Infrastructure et processus SI

8

3. Infrastructure etprocessus SI

1. Définition des SI

L'une des difficultés auxquelles un RAI estconfronté lorsqu'il détermine l'implication des res-sources d'audit informatiques est d’appréhenderles usages du SI dans l’organisation. Le téléphoneet les messageries vocales en font-ils partie ? Lessystèmes d'accès et d'identification, ainsi que lessystèmes de sécurité physique devraient-ils êtreinclus ? Et que faire si ces derniers sont externali-sés ? Voici quelques-unes des questions auxquellesil faut répondre lorsqu’il s’agit de déterminer com-ment allouer ses ressources d’audit des SI.

Les SI sont spécifiques à chaque organisation.Deux organisations opérant dans le même secteurpeuvent avoir des environnements de SI très dif-férents. Même au sein d'une même organisation,les contrôles peuvent être centralisés, décentralisésou les deux à la fois. Les ordinateurs portables, lesréseaux sociaux et le cloud repoussent les fron-tières d'un contrôle centralisé et introduisent desrisques et des facteurs spécifiques.

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

sont intégrées à des procédures et des processusmanuels et certaines peuvent être envisagées iso-lément. Il existe des risques informatiques danschaque domaine de l'organisation, et ils varientconsidérablement. Pirater le site Internet d'uneorganisation et détourner un paiement électro-nique sont, par exemple, des risques très différentspour l'organisation.

2. Tenir compte de chaque niveau duSI

Pour un audit des SI efficace, il est nécessaired’étudier et de classer par ordre de priorité lesrisques inhérents à chaque niveau du SI et d’yallouer les ressources d’audit en fonction de cesrisques. Si le volet SI du plan d’audit ne prévoitpas une évaluation de chacun des niveaux, il estprobable que le plan d’audit dans son ensemblene traite pas correctement les risques liés aux SI.

Dans certains cas, il peut se révéler utile de traitertous les niveaux sur plusieurs années, en faisantun focus particulier chaque année, au lieu de cou-vrir tous les niveaux sur une seule année. Les planspar roulement allant au-delà de trois ans peuventêtre inadéquats en raison de la rapidité des chan-gements qui s’opèrent dans l’environnement desSI.

Management des SI

Infrastructure technique

Fournisseurs

Systèmesd’exploitation

Base dedonnées Développement

interne d’unesolution

transactionnelle

Solutiontransactionnelle

génériquecorrespondant à

l’o$re d’unprestataire externe

Solutiontransactionnelle

customisée par unprestataire externe

Logiciel desupport /assistance

Centre de données

Processus des SI

Réseaux

Clients

InternetApplications

Figure 1

GTAG – Infrastructure et processus SI

9

Quelles ressources allouer à chaque niveau? Aquelles fins ? La réponse à ces questions délicatesdevrait naturellement découler des processusd’évaluation des risques, du jugement profession-nel et d’une analyse stratégique. Au-delà de l’al-location précise des ressources, il s’agit des’assurer que tous les niveaux du SI sont pris encompte.

3. Quels sont les niveaux àconsidérer ?

Le SI d’une organisation peut-être illustré selon lafigure 1.

Chaque organisation est différente, mais cettereprésentation aidera à identifier les processus clésdes SI dans la plupart des organisations. D'autresmodèles d'architecture des SI peuvent être envi-sagés et sont référencés à l'Annexe A.

Les Technologies de l'information et de la commu-nication (TIC) peuvent être appréhendées à traversles principaux niveaux suivants :• le management des systèmes d’information, • l’infrastructure technique, • les applications,• les connexions externes.

(Cf. figure 2)

4. Management des systèmesd’information

Le management des SI concerne les personnes, lesrègles, les procédures et les processus qui gèrentles services et les installations des SI. L'intégritédu traitement et des données repose sur les tâchesspécifiques régulièrement réalisées par le person-nel administratif. En conséquence, cette compo-sante englobe la surveillance, la programmation,la planification, la gestion des fournisseurs, la ges-tion des problèmes et des incidents, la gestion deschangements, la gestion des projets informatiques,le plan de continuité d'activité, la gestion de lasécurité, la gouvernance des SI, etc.

Ces fonctions relèvent de processus métier. L'ap-proche d'audit sera donc similaire à une missionclassique. L’auditeur considèrera les acteurs etleurs tâches, plutôt que la configuration d’un sys-tème technique. Néanmoins, dans certains cas, lagestion des processus porte sur les installationstechniques que l'audit devra prendre en considé-ration. De même, certains contrôles peuventnécessiter des compétences spécialisées. En prin-cipe, les compétences d'un auditeur interne expé-rimenté seront suffisantes.

Risque opérationnel / stratégique

Objectifs opérationnels

Processus métier

Infrastructure

Assurance

ObjectifsProcédure

Application

TIC

Risques inhérentsau processus

Informationsopérationnelles

Objectifs

Procédure

Application

TIC

Risques inhérentsau processus

Informationsopérationnelles

Figure 2

Attention : ce graphique ne définit pas des catégoriesdu plan d’audit des SI. La planification des missionsd'audit des SI peut être organisée en fonction des pro-cessus de l'organisation, ou conformément à un cadrestandard. Ce graphique a pour objectif d'aider àexpliciter les liens entre les SI et l'organisation et às’assurer que des ressources d'audit sont allouées àchaque niveau. L’organisation d'audits spécifiques estlaissée à l’appréciation du responsable de l’auditinterne.

GTAG – Infrastructure et processus SI

10

5. Infrastructure technique

L’infrastructure technique sous-tend, soutient lesprincipales applications métier et facilite leur miseen œuvre. En règle générale, ce niveau com-prend : • Les systèmes 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 gérés par lesystème d'exploitation. Les actions engagéesau niveau du système d’exploitation parvien-nent en général à contourner la plupart desdispositifs de sécurité et des contrôles existantau niveau du processus.

• Les fichiers et les bases de données –Toutesles données électroniques de l’organisation,critiques ou autres, sont contenues dans desfichiers qui peuvent faire partie d'une base dedonnées. Les bases de données (qui peuventêtre un seul fichier ou un groupe de fichiers)comprennent des tables contenant des don-nées, des relations entre des données élémen-taires et des index de données élémentaires. Laflexibilité des structures d'une base de donnéesexplique qu'elles soient utilisées pour la plu-part des traitements opérationnels et desapplications de remontée d'informations. Cesbases sont par exemple Oracle, MS SQLServer et DB2. Les actions engagées au niveaudes bases de données tendent également àcontourner la plupart des contrôles qui exis-tent au niveau du processus.

• Réseaux – Pour que les données circulentdans une organisation, il faut qu’elles dispo-sent d’un vecteur, qui peut être un câble, unefibre optique ou un système sans fil. Le réseause compose d'éléments physiques tels que descâbles, des appareils qui gèrent le trafic sur leréseau, comme les commutateurs, les routeursou les pare-feux, et des programmes qui com-mandent la circulation des données. L’intégritédu réseau joue un rôle important dansl’exhaustivité et l’exactitude des données d’uneorganisation. Par exemple, lorsque l'agent d’unentrepôt prépare l’expédition d’un produit enscannant un code-barres, la transaction est

enregistrée dans le Grand Livre en passant parle réseau où elle est traitée. Mais que se pro-duit-il si elle ne passe pas par le réseau ? Quese passe-t-il si elle est modifiée en cours deroute, ou disparaît complètement ? Commentl’organisation le saurait-elle ?

• Centres de données – L'équipement infor-matique est situé dans des centres de donnéeset des salles des serveurs, qui constituent l'in-frastructure physique et assurent, la sécuritéphysique et environnementale permettant deprotéger l'infrastructure technique et les appli-cations.

Les audits de l'infrastructure technique sont axéssur la revue des paramètres de configuration tech-nique en association avec les processus de gestiony afférents.

6. Applications

Les applications métier sont des programmes quiexécutent des tâches spécifiques liées aux activitésde l’organisation. Elles font partie intégrante duprocessus métier et ne peuvent être considéréesséparément des processus qu'elles soutiennent.Les applications appartiennent généralement àdeux catégories : • 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-pôts.

• Les logiciels support sont des logiciels spécia-lisés qui facilitent les activités métier mais netraitent généralement pas les transactions. Ilsservent par exemple au stockage des données,à la messagerie électronique, à la télécopie, àla veille stratégique (business intelligence), à lagestion électronique des documents (GED) età la conception.

Alors que les solutions transactionnelles consti-tuent généralement l’essentiel de l’effort d’audit,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 contrôlent des machines peuvent éga-lement être soumis à des risques importants.

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

7. Connexions externes

Le réseau de l’organisation ne fonctionne pas iso-lément. Il est quasiment toujours connecté à denombreux autres réseaux externes. Internet estcelui qui vient le premier à l’esprit, mais trop sou-vent, les auditeurs commettent l’erreur de ne pasaller au-delà.

En réalité, il est fort probable que le réseau de l'en-treprise soit connecté à de nombreux autresréseaux (dont le cloud et les logiciels des presta-taires de services). Par exemple : l’organisationopère-t-elle via un échange de données informa-tisées (EDI) ? Si tel est le cas, son réseau est cer-tainement connecté à celui d’un prestataire d’EDI,ou peut-être directement au réseau d’un parte-naire commercial. L’organisation externalise-t-ellesa fonction de stockage ? Si oui, les deux réseauxsont aussi probablement reliés. Les risques asso-ciés aux réseaux d'autres organisations et lescontrôles y afférents sont différents de ceux appli-cables aux connexions Internet.

Dans la mesure où les organisations continuentd’automatiser leurs processus clés, les tiers ont deplus en plus accès à leur réseau, souvent via Inter-net. Prenons par exemple la possibilité de vérifierle solde d’un compte bancaire ou l’état d’avance-ment d’une expédition. Les clients qui utilisent cesfonctions entrent probablement dans le réseauinterne de ces entreprises via Internet.

Du fait que l’organisation ne maîtrise pas lesréseaux extérieurs, les communications provenant(ou transmises vers) des réseaux externesdevraient être rigoureusement contrôlées et sur-veillées en fonction du risque qu'elles représentent

pour l'organisation. Il peut être difficile de définirdes procédures d'audit des SI pour gérer ce risquecar l'organisation ne peut auditer que ce qu'ellecontrôle. Il est donc primordial d'auditer au mini-mum les points d'entrée et de sortie.

GTAG – Approche fondée sur les risques

12

4. Approche fondée sur lesrisques

Toutes les dimensions de la gestion d’un serviced’audit interne reposent sur une approche fondéesur 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 inhérents aux SI.

L'évaluation des risques relatifs aux SI réalisée parl’audit interne permet d’identifier des missionsd'audit spécifiques à plus forte valeur ajoutéepotentielle pour la période considérée. Les risquesrelatifs aux SI ne nécessitent pas de méthodologiedistincte. Il est important d'utiliser la mêmeméthodologie pour tous les types de risques afinde veiller à l'homogénéité du processus d'évalua-tion pour l'ensemble de la fonction d'auditinterne.

Les risques sont généralement exprimés en termesde combinaison d’impact et de probabilité d’oc-currence d’un évènement. Il est souvent difficiled’évaluer exactement les risques, notamment pourles séries d'événements 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 données) – et il n'estpas nécessaire de connaître le cheminement desévénements qui en seraient à l'origine, ni la pro-babilité d'occurrence – pour savoir qu'il faut êtreattentif au risque.

Il est souvent possible de définir des critères quis'appliquent à tous les types de risques liés aux SI,mais se manifestent différemment. Par exemple,l'exposition potentielle peut être appréhendée pardes indicateurs d’envergure ou de criticité opéra-tionnelle. Par exemple, le nombre d'applicationssous-tendues par un centre de données pourraitêtre indicatif de son niveau de criticité (éventuel-lement pondéré en fonction de son importance),et le nombre de serveurs qu'il héberge peut éven-tuellement caractériser sa taille. La taille d'unprojet, en revanche, se mesure à son budget, et sa

criticité opérationnelle au nombre d'entités fonc-tionnant à l'aide de l'application. Le nombre d'in-cidents recensés ou les projets menés à bien parl'organisation peuvent mesurer la probabilité d'oc-currence.

Outre la collecte de données, 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 parl’organisation. Aussi l'évaluation des risques doit-elle être fréquemment mise à jour. Ceci est parfai-tement illustré par l'importance croissante desproblématiques de protection de la vie privéedécoulant de l'existence et de l'utilisation desréseaux sociaux. Pour une description plus détail-lée de cette problématique, vous pouvez consulterle Guide pratique de l'IIA, L’audit des risques d’at-teinte à la vie privée.

Enfin, pour une description plus détaillée de l'éva-luation des risques relatifs aux SI, vous pouvezconsulter le GTAG 11 : Élaboration d'un plan d’auditdes SI.

GTAG – Univers d'audit

13

5. Univers d'audit

Pour constituer les bases de l'allocation et de laprévision des ressources en audit des SI et pourassurer la couverture nécessaire à la fournitured’une assurance raisonnable concernant lesrisques relatifs aux SI, les domaines impliquant desSI et nécessitant des compétences spécialisées enaudit des SI devraient être identifiés dans l'universd'audit.

Il ne devrait pas y avoir d'univers d'audit des SIdistinct. Les travaux d'audit des SI devraient êtreintégrés à l'univers d'audit global car les SI et lesprocessus métier qu'ils sous-tendent sont forte-ment interdépendants. Par exemple, les applica-tions informatiques métier feront généralementpartie de l'univers d'audit global à l'intérieur d'unprocessus métier. La structuration de l'universd'audit devrait permettre un regroupement partype d'audit et donc une identification des mis-sions nécessitant des compétences spécialisées(par exemple, l'audit des applications et des pro-cessus des SI).

Pour les processus de regroupement/structuration,on s'appuie généralement sur la structure utiliséepar le management des SI, qui figure habituelle-ment dans la stratégie des SI. Idéalement, cettestructure est basée sur des référentiels tels queCOBIT, ITIL, COSO (pour de plus amples détails,voir la section 7), etc.

Dans une organisation complexe, un univers d'au-dit très détaillé peut facilement comporter des mil-liers d'éléments relatifs aux SI. Cet univers d'auditsera alors difficile à gérer car sa production, sa miseà jour, et l'évaluation des risques pour tous les élé-ments nécessiteront des efforts importants. Enrevanche, si les éléments relatifs aux SI sont tropgénéraux, ils ne pourront sans doute pas servir debase à l'élaboration du plan d'audit.

Voici quelques principes importants qui devraientêtre suivis lors du développement des composantsSI de l'univers d'audit :• Veiller à l'exhaustivité en intégrant les élé-

ments pertinents, notamment ceux qui peu-

vent ne pas être évidents (par exemple les acti-vités externalisées telles que les prestataires deservices à l'étranger, des éléments opération-nels très importants sur le plan des SI et lesprocessus métier automatisés).

• Lors du processus de mise à jour, mettre l'ac-cent sur les thèmes nouveaux et émergents.Citons par exemple le cloud computing, lesmédias sociaux ou l'utilisation d'appareilsmobiles.

• L'univers d'audit ne devrait pas être tenusecret, mais doit être partagé avec les partiesprenantes concernées (par exemple le mana-gement des SI et d'autres fonctions) afin defavoriser la communication de données et desuggestions d'amélioration.

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

GTAG – Savoir-faire et compétences

14

6. Savoir-faire etcompétences

Une thématique récurrente dans de nombreusesorganisations, concerne l’écart entre d’une partl'utilisation des systèmes informatiques et ladépendance des organisations à leur égard, etd’autre part, les ressources utilisées pour identifieret gérer les risques découlant de ces technologies.Il est donc primordial que la fonction d'auditinterne tienne compte des systèmes d'informationlorsqu'elle évalue les processus de gouvernance,de management des risques et de contrôle.

Pour gérer ces risques, un RAI doit veiller à ce queson équipe possède les compétences requises. Ceciest préconisé par le Code de déontologie du Cadre deRéférence International des Pratiques Professionnellesde l'audit interne (CRIPP) de l'IIA, qui exige que lesauditeurs internes effectuent uniquement des ser-vices pour lesquels ils possèdent les connais-sances, les compétences et l'expérience requises,ainsi que par la Norme 1210 : Les auditeurs internesdoivent posséder les connaissances, le savoir-faire etles autres compétences nécessaires à l'exercice de leursresponsabilités individuelles. La fonction d'auditinterne devrait posséder ou obtenir, collective-ment, les connaissances, le savoir-faire et autrescompétences nécessaires. L'IIA propose un réfé-rentiel des compétences qui aide à identifier lescompétences nécessaires à l'exécution des activitésd'audit interne.

Le RAI devrait obtenir l'avis et l'assistance de per-sonnes qualifiées si le service d'audit interne nepossède pas les connaissances, le savoir-faire et lesautres compétences nécessaires pour s'acquitterde tout ou partie d'un audit des SI. Les ressourcesaffectées à la réalisation des missions planifiéesont un rôle critique. Par exemple, les compétencesrequises pour auditer la configuration d’un pare-feu sont très différentes de celles nécessaires pourauditer les tables dans une base de données. Pourune mission donnée requérant telles ou tellescompétences, il est donc essentiel de trouver l’au-

diteur adéquat. Le RAI doit savoir qu'aucun audi-teur ne peut effectuer tous les travaux d'audit desSI et que souvent, certaines missions nécessitentplutôt des compétences concernant des applica-tions et d'autres missions nécessiteront des audi-teurs plus compétents en matière d'infrastructure.

Par conséquent, un RAI qui a une bonne appré-hension de l’univers d’audit, des risques généréspar l'utilisation des SI, ainsi que des compétencesen audit des SI dont il dispose, devrait être à mêmede cibler les efforts de recrutement et de formationen conséquence. En l'absence du savoir-faire etdes compétences informatiques nécessaires, ou s'ilest décidé de ne pas former ou embaucher de col-laborateurs possédant ces compétences, le RAIpeut faire appel à un prestataire de services externepour étoffer ou compléter l'équipe d'audit interne(sous-traitance ou co-sourcing)1.

Pour s'acquitter des responsabilités relatives à l’au-dit des SI, le RAI devrait se poser des questionsclés concernant la gestion des compétences 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é identifiés ?

• Existe-t-il une vue d'ensemble de l'éventaildes compétences nécessaires pour auditerl'usage des SI de l'organisation et les compé-tences déjà 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 possèdent-ils la forma-tion, les certifications et l'expérience 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 adéquate aux auditeurs pour appré-hender l’usage du SI, les risques y afférents etles modalités d’audit appropriés ?

1 Pour de plus amples détails, voir la MPA 1210.A1-1 : Recours à des prestataires externes.

GTAG – Réaliser des missions d'audit des SI

15

7. Réaliser des missionsd'audit des SI

Le déroulement de missions d'audit des SI n’estgénéralement pas différent de celui d’autres mis-sions. L’auditeur planifie, identifie et documenteles contrôles pertinents, vérifie l’efficacité de laconception et du fonctionnement de ces contrôles,en tire des conclusions et rédige son rapport.Puisque la plupart des responsables de l’auditinterne connaissent bien ce processus général, iln’est pas rappelé ici. Toutefois, le RAI doit connaî-tre et gérer certaines problématiques 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 probablementaudités exclusivement par des spécialistes des SI(principalement ceux qui sont axés sur l'infrastruc-ture tels que les centres de données, les réseaux,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 chaîne devaleur, incluant les métiers et les SI, apportera leplus grand bénéfice. Ces types de missionsdevraient se concentrer sur les objectifs opération-nels et tous les risques (dont ceux relatifs aux SI)doivent être évalués selon cette perspective. Cetexercice peut être difficile, mais également trèspositif car il permet de cerner les liens de dépen-dance du métier vis-à-vis des SI. Par exemple, siles missions d'audit des SI révèlent qu'il n'existepas de plan de continuité d'activité, les auditeursdes SI et les auditeurs opérationnels peuvent col-laborer pour décrire l'impact de la durée de l'in-terruption anticipé dans le scénario de crise pourle métier (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 spécifiques, l'atten-tion de l’audit interne devrait être centrée sur lacollaboration pour obtenir des résultats optimaux.

2. Cadres de référence et normes

L’une des difficultés que rencontrent les auditeurslorsqu’ils effectuent un audit des SI est la détermi-nation d’un référentiel. La plupart des organisa-tions n’ont pas élaboré de références de contrôledes SI pour toutes les applications et technologies.L’évolution rapide de la technologie pourraitrendre ces références rapidement obsolètes etdonc inutiles.

Un RAI devrait avoir une série d’objectifs decontrôle des SI, et devrait pouvoir trouver un cadrede référence approprié même s’il n’est pas à 100%adapté à son environnement.

3. COSO et COBIT

Où un RAI peut-il trouver une série cohérented’objectifs de contrôle des SI ? Les cadres de réfé-rence Contrôle interne et management des risques del’entreprise du Committee of Sponsoring Organiza-tions of the Treadway Commission (COSO) consti-tuent des sources d'information fréquemmentconsultées, mais ils ne sont pas spécifiquementaxés sur les SI. L’environnement de contrôle repo-sant sur le COSO devrait être complété par desobjectifs de contrôle des SI plus détaillés, qui per-mettront d’évaluer plus efficacement l’environne-ment de contrôle des SI. Il existe un certainnombre de possibilités à cet égard.

Le CobiT (Control Objectives for Information andrelated Technology), initialement publié en 1994 parl’ISACA (Information Systems Audit and ControlAssociation), est l’un des référentiels de contrôle etde gouvernance des SI couramment utilisé. La ver-sion 5.0 du CobiT a été publiée en 2012. Le CobiTn'a pas pour vocation de concurrencer le COSOou d'autres référentiels, mais peut être utilisé pourles compléter en les enrichissant avec des objectifsde contrôle des SI plus ciblés.

GTAG – Réaliser des missions d'audit des SI

16

4. Règles, normes et procédures

Un référentiel comme le CobiT propose une séried’objectifs de contrôle des SI communémentadmis, qui aide le management à concevoir unepolitique d’évaluation et de gestion des risques liésaux SI. Le management se sert généralement d’untel référentiel pour le développement d’un sys-tème cohérent de règles, normes et procéduresrelatives aux SI. L'Annexe A donne une vue d'en-semble des sources pertinentes pour les règles, lesnormes et les procédures.

GTAG – Rapports

17

8. Rapports

Comme pour tous les autres travaux d'auditinterne, les RAI rendent compte régulièrement desrésultats des missions d'audit des SI aux princi-pales parties prenantes telles que le Conseil1, ladirection générale, le directeur des systèmes d'in-formation, les régulateurs et les auditeurs externes.Pour des lignes directrices plus détaillées sur lafaçon 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 hiérarchiques plus élevésque ceux qui sont interviewés ou qui exécutent lescontrôles. Il est donc nécessaire de communiquerprécisément et clairement les informations les plusimportantes, de façon à ce que les constats ou lesenjeux soient compris et que le managementpuisse réagir. Il est inutile d'effectuer un audit dequalité si le management ne met pas en œuvre desplans d'action efficaces pour gérer les probléma-tiques et les risques identifiés. Le management nes'intéresse généralement pas aux détails du pro-cessus d'audit. Il souhaite connaître les défail-lances, leurs conséquences potentielles et lesmesures à prendre pour y remédier.

Lorsqu'il effectue une mission, l'auditeur internedevrait s'efforcer d'avoir une perspective globale.La plupart des organisations étant dépendantesdes SI, les rapports sur les risques et les contrôlesrelatifs aux SI devraient faire partie des activitésd'assurance du RAI. Si des processus SI et l'infra-structure SI peuvent (et peut-être devraient pourdes raisons d'efficacité) être audités séparément,en règle générale, l'audit de l'ensemble de lachaîne de valeur (dont les métiers et les SI) appor-tera le plus grand bénéfice. Ces types d'audit peu-vent être nettement plus axés sur les risquesopérationnels, qui sont plus facilement communi-

qués au management que les risques relatifs auxSI. Les risques relatifs aux SI débouchent in finesur des risques opérationnels, 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 réseaux sans fil, à un audit del’architecture et de la conception des réseaux oubien à une revue de la conception d’une applica-tion électronique ? Si les missions sont ainsi dis-sociées, il y a fort à parier que les constatsporteront sur des détails pour chaque technologie.Pour certains publics, cette approche pourrait êtreappropriée, mais le Conseil ou la direction géné-rale pourraient ne pas s'intéresser ou comprendreles détails des questions techniques. Ils veulentgénéralement que les constats d'audit soient reliésaux problématiques opérationnelles. En consé-quence, les travaux d'audit des SI doivent s'inté-grer aux travaux des auditeurs de processus /opérationnels / financiers et aux procédures qu'ilsmettent en œuvre. Ceci est particulièrement vraidans les environnements comportant des applica-tions ERP importantes, dont les systèmes compor-tent un grand nombre de contrôles clés deprocessus. N'oublions pas que dans certains cas,l'audit de composants centraux de l'infrastructuretels que les centres de données ou les réseaux sansfil sera difficile ; il sera donc pertinent d'auditerindividuellement ces domaines. Toutefois, lesrisques identifiés durant la mission doivent êtretraduits en langage opérationnel et en risquesmétier.

Les rapports devraient être rédigés pour des lec-teurs avertis, mais qui ne possèdent peut-être pasd'expérience spécifique dans le domaine audité, etle message ne doit être ni délayé ni noyé dans unlangage technique. L'objectif du RAI est de pré-senter un message clair, compréhensible 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 activités et de la gestion de l'organisation. Habituellement, le Conseil (par exemple, un conseil d’administration,un conseil de surveillance ou un organe délibérant) comprend des administrateurs indépendants. Si une telle instance n’existe pas, le terme « Conseil »,utilisé dans les Normes, peut désigner le dirigeant de l’organisation. Le terme « Conseil » peut renvoyer au comité d’audit auquel l’organe de gouver-nance a délégué certaines fonctions. »

GTAG – Outils d’audit

18

9. Outils d'audit

Les RAI devraient chercher à utiliser des outilset/ou des techniques pour accroître l'efficience etl'efficacité de l'audit. En règle générale, les outilsd'audit requièrent un investissement, si bien quele RAI devrait soigneusement évaluer le rapportcoût/avantages de toute solution avant de s’yengager. Les outils d’audit peuvent être répartis endeux catégories : les facilitateurs d’audit (qui nesont pas abordés ici), qui viennent en support duprocessus global d’audit (par exemple un outil degestion des documents de travail électroniques), etles outils de tests : outils qui automatisent la réa-lisation des tests d’audit (comme les outils d’ana-lyse des données et les techniques d’audit assistépar ordinateur).

1. Outils de tests des SI

Les outils de tests permettent d’automatiser destâches d’audit chronophages, comme l’examen devastes bases de données. En outre, le recours à unoutil pour exécuter des procédures d’audit confèreune certaine cohérence. Par exemple, si un outil estutilisé pour évaluer la configuration de la sécuritéd’un serveur, tous les serveurs testés au moyen decet outil seront évalués par rapport aux mêmes cri-tères. Exécuter ces procédures manuellementlaisse du champ à une interprétation de la part del’auditeur. Enfin, l’utilisation de ces outils permetaux auditeurs de tester la totalité d’une base dedonnées, et non un simple échantillon de transac-tions, d’où un niveau d’assurance bien supérieur.

Les RAI devraient savoir que les mêmes considé-rations s'appliquent tant à l'acquisition d'outilsd'audit des SI qu’au choix de n'importe quel autreoutil opérationnel (par exemple fonctionnalité,support).

Outils d’analyse de la sécurité

Un vaste ensemble d’outils permettent d’examinerdifférentes catégories de dispositifs et/ou d’utilisa-teurs, et de déceler les expositions à des risquesliés à la sécurité. Il existe de nombreux types

d'analyse de la sécurité, les principaux étant lesoutils d'analyse de réseau :

Outils d’analyse de réseau – Ces outils sont desprogrammes logiciels qui peuvent être lancés surun réseau pour y recueillir des informations. Clas-siquement, les pirates informatiques utilisent cetype d’outils au début d’une attaque afin de déter-miner la structure du réseau. Les auditeurs des SIpeuvent y recourir pour diverses procédures d’au-dit, notamment : • La vérification de l’exactitude des diagrammes

de réseau par une cartographie du réseau,• L’identification des dispositifs clés du réseau

qui appellent une attention supplémentaire dela part des auditeurs,

• La collecte des informations concernant letrafic autorisé sur un réseau (étayant directe-ment le processus d’évaluation des risques liésaux SI).

Outils d'évaluation de la vulnérabilité

La plupart des technologies, lorsqu’elles ne sontpas personnalisées, souffrent d’un certain nombrede vulnérabilités standard, comme l’existenced’identifiants, de mots de passe ou de paramètrespar défaut. Ces outils d'évaluation offrent unesolution automatisée pour vérifier ces vulnérabili-tés.

Ces outils peuvent être utilisés pour les pare-feux,les serveurs, les réseaux et les systèmes d’exploi-tation. Nombre de ces outils sont « prêts à utili-ser » (« plug and go ») : l’auditeur les branche surtout ce qu’il souhaite analyser, et l'outil produit unrapport des vulnérabilités identifiées.

Il est important que l’auditeur exploite ce typed’outils pour plusieurs raisons, notamment parceque ce sont les outils qu’un pirate informatiqueutiliserait pour monter une attaque contre l’orga-nisation. Néanmoins, il convient de les utiliseravec vigilance car certains de ces outils sont poten-tiellement dangereux et peuvent compromettrel’intégrité des systèmes qu’ils scannent. L’auditeurdevrait examiner avec le responsable de la sécuritél’utilisation qu’il prévoit de faire de ces outils et

GTAG – Outils d’audit

19

coordonner les tests avec le management des SIafin de veiller à ce que le calendrier des tests n’af-fecte pas la production. Dans certains cas, le res-ponsable de la sécurité ou les administrateurssystèmes emploient déjà régulièrement certains deces outils dans le cadre des processus de gestiondes systèmes. Si tel est le cas, il peut être envisagéd’exploiter ces résultats dans les travaux d'auditdes SI, s’ils sont correctement conçus et exécutés.

Outils d’analyse des applicatifs de sécurité

Bon nombre d'applications intégrées comportentdes outils d'analyse de la sécurité en fonction derègles préconfigurées. Ces outils peuvent égale-ment évaluer la séparation des fonctions au seind’une application. Le RAI devrait être conscient dufait que la plupart de ces outils sont assortis d’unensemble de règles préconfigurées ou proposéespar le fournisseur comme relevant des « meilleurespratiques ».

GTAG – Conclusion

20

10. Conclusion

L’apparition de nouveaux risques liés à la techno-logie impose de repenser les procédures pour biengérer ces risques. Il ne fait aucun doute qu'au coursdes 15 dernières années, la technologie a modifiéla nature de la fonction d’audit interne.Aujourd’hui, les RAI devraient s’interroger sur lesrisques auxquels est confrontée l’organisation, lestypes d’audits à effectuer, les modalités de priori-sation dans l’univers d’audit et sur la manière decommuniquer des constats pertinents au Conseilet à la direction générale.

La stratégie métier guide la définition de l'universd'audit et l'évaluation des risques. Elle détermineles éléments importants pour le Conseil et lemanagement, et les domaines dans lesquels lesactivités sont susceptibles de changer. Il est doncimportant que le RAI comprenne tant la stratégiemétier que le rôle des SI dans l'organisation etl'impact qu'ils ont l'un sur l'autre.

Lorsque le RAI cartographie les activités de l'or-ganisation et son infrastructure, il peut observer defaçon privilégiée l'impact des différentes relationsentre les SI et les métiers. Les projets SI sont sou-vent des éléments clés du changement, dans lesorganisations, et le mécanisme utilisé par le mana-gement pour mettre en œuvre la stratégie opéra-tionnelle.

Les difficultés auxquelles un RAI est initialementconfronté lorsqu'il développe les composantes SIdu plan d'audit concernent l'identification desactivités SI au sein de l'organisation. Sachant queles environnements des SI sont très diversifiés, unRAI peut chercher à définir les SI en termes decomposantes. Chaque composante est différenteet importante à la fois. L'utilisation d'uneapproche fondée sur les risques est un conceptgénéral qui s'applique à quasiment toutes les acti-vités d'audit interne. L'univers d'audit devrait tenircompte des SI car il existe des interdépendancesimportantes entre les SI et les métiers.

Pour gérer ces risques, un RAI doit veiller à ce queson équipe possède les compétences requises. En

outre, les RAI devraient chercher à utiliser desoutils et/ou des techniques pour accroître l'effi-cience et l'efficacité de l'audit. Comme pour n'im-porte quel outil, les outils d'audit requièrent uninvestissement en temps et en ressources, si bienque le RAI devrait soigneusement évaluer le rap-port coût/avantages de toute solution avant de s’yengager.

Enfin, le processus pour réaliser une mission rela-tive aux risques SI n’est généralement pas différentde celui d’autres travaux d'audit : l’auditeur plani-fie la mission, identifie et documente les contrôlespertinents, vérifie l’efficacité de la conception et dufonctionnement de ces contrôles, en tire desconclusions et rédige son rapport. De même, lesRAI rendent compte régulièrement des résultatsdes travaux d'audit des SI aux principales partiesprenantes telles que le Conseil, la direction géné-rale, le directeur des systèmes d'information, lesrégulateurs et les auditeurs externes.

GTAG – Annexe A : Normes de référence

21

Annexe A : Normes deréférence

Les normes citées ci-après peuvent être prises enconsidération :

ISO 27001 – ISO 27001/ISO 17799 – L’Organisa-tion internationale de normalisation (ISO) a éditéune norme générique sur la sécurité des SI recon-nue à l’échelle internationale. Il s’agissait audépart d’une norme britannique (BS 7799), qui aété transformée en norme ISO et qui est désor-mais connue sous l’appellation ISO 27001. Elleprésente les bonnes pratiques communémentadmises concernant la gestion de la sécurité des SIet constitue un document de référence 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 l’université Carnegie Mellon a élaboré leconcept de Capability Maturity Models (CMM,modèles de maturité des capacités) relatifs à dif-férents processus au sein d’une organisation,notamment en ce qui concerne le déploiement delogiciels. L'approche la plus récente 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 série complète de publications offrantdes informations détaillées sur le contrôle de lasécurité 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 normesénoncent des bonnes pratiques qui peuvent êtreutilisées dans tous les secteurs.

http://csrc.nist.gov

SysAdmin, Audit, Network, Security (SANS)Institute – Source d’information parmi les plusfiables pour ce qui est de la formation et de la sen-sibilisation à la sécurité des SI, le SANS Institutepublie de nombreux documents traitant des diffé-rents aspects de la sécurité pour diverses techno-logies. Les publications du SANS exposent uncertain nombre de critères incontournables auregard desquels l’auditeur des SI peut effectuerson audit.

http://www.sans.org

IT Infrastructure Library (ITIL) – L'ITIL est l'ap-proche la plus généralement admise de la gestiondes services des SI dans le monde. L'ITIL donneun ensemble homogène de meilleures pratiquestirées 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 sécurité et lecontrôle applicables à la technologie qu’ils produi-sent. SAP, par exemple, édite un guide sur la sécu-rité qui énonce des recommandations détailléespour la sécurité et les contrôles de l’applicationSAP ERP. Souvent, ces normes fournisseurs neprennent pas en compte la sécurité et le contrôleau même niveau que, par exemple, une publica-tion NIST, mais elles donnent une bonne base dedépart. Les RAI devraient donc vérifier auprès desfournisseurs de systèmes critiques pour les mis-sions si des normes spécifiques sont disponibles.Dans bien des cas, les fournisseurs n’ont rienpublié, mais le groupe d’utilisateurs associé à cettetechnologie a édité une ou des publication(s) (parexemple les différents groupes d’utilisateurs deSAP aux États-Unis).

GTAG – Annexe B : Modèles d'architecture des SI

22

Annexe B : Modèlesd'architecture des SI

Les modèles d'architecture des SI et les référencespouvant être pris en compte sont :

The Abu Dhabi IT Architecture & StandardsFramework – Basé sur un référentiel comportanthuit niveaux, il couvre tous les aspects d'un envi-ronnement des SI notamment : Métiers, Accès etprésentation, Application, Données, Intégration,Infrastructure, Sécurité et Exploitation.

http://adsic.abudhabi.ae

AndroMDA – Des applications modernes sontconstruites à l'aide de plusieurs composantsconnectés les uns aux autres, chacun d'entre euxayant une fonctionnalité spécifique. Les compo-sants qui effectuent des fonctions similaires sontgénéralement regroupés en niveaux. Ces niveauxsont organisés en pile dans laquelle les compo-sants d'un niveau utilisent les services de compo-sants d'un niveau inférieur. Un composant dansun niveau donné utilisera généralement la fonc-tionnalité d'autres composants de son propreniveau ou de niveaux inférieurs.

http://www.andromda.org

TOGAF® – The Open Group Architecture Foruma développé et maintient le TOGAF, une normereconnue au niveau mondial en matière 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

RéviseursMarie-Elisabeth Albert, CIABéatrice Ki-Zerbo, CIAGilles Trolez

A PROPOS DE L’INSTITUTE OF INTERNAL AUDITORS

Fondé en 1941, The Institute of Internal Auditors (IIA) est une organisation professionnelle internationale dont lesiège mondial se situe à Altamonte Springs, en Floride, aux États-Unis. L’Institute of Internal Auditors est la voixmondiale, une autorité reconnue, un leader incontesté et le principal défenseur de la profession d’auditeur interne.C’est également un acteur de premier plan pour la formation des auditeurs internes. Il est représenté en Francepar l’IFACI.

A PROPOS DES GUIDES PRATIQUES

Les guides pratiques détaillent la réalisation des activités d’audit interne. Ils contiennent des processus et des pro-cédures, tels que les outils et techniques, les programmes et les approches pas-à-pas, et donnent des exemples delivrables. Les guides pratiques s’inscrivent dans le Cadre de référence international des pratiques professionnellesde l'audit interne de l’Institute of Internal Auditors. Ces guides pratiques relèvent de la catégorie des dispositionsfortement recommandées. La conformité à ces guides pratiques n’est donc pas obligatoire, mais fortement recom-mandée. Ces guides ont été officiellement révisés et approuvés par l’IIA.Le Global Technologies Audit Guide (GTAG) est un type de guide pratique qui aborde, dans un langage courant,une question d’actualité liée à la gestion, au contrôle ou à la sécurité des technologies de l’information.Pour de plus amples informations sur les documents de référence proposés par l’Institute, vous pouvez consulternotre site Web, www.theiia.org.guidance ou www.ifaci.com.

AVERTISSEMENT

L’Institute of Internal Auditors publie ce document à titre informatif et pédagogique. Cette ligne directrice n’a pasvocation à apporter de réponses définitives à des cas précis, et doit uniquement servir de guide. L’Institute ofInternal Auditors vous recommande de toujours solliciter un expert indépendant pour avoir un avis dans chaquesituation. L’Institute dégage sa responsabilité pour les cas où des lecteurs se fieraient exclusivement à ce guide.

COPYRIGHT

Le copyright de ce guide pratique est détenu par l’Institute of Internal Auditors et par l’IFACI pour sa version fran-çaise. Pour l’autorisation de reproduction, prière de contacter l’Institute of Internal Auditors à l’adresseguidance@theiia.org ou l’IFACI à l’adresse recherche@ifaci.com.

The Institute of Internal Auditors IFACI247 Maitland Avenue, Altamonte Springs 98bis, Boulevard HaussmannFlorida 32701, États-Unis 75008 PARIS, FranceTéléphone : +1 407 937 1100 Téléphone : 01 40 08 48 00Télécopie : 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