Laudit Technique Informatique by Henri Ly [PDF]

Zitiervorschau

L’audit technique informatique

© LAVOISIER, 2005 LAVOISIER

11, rue Lavoisier 75008 Paris

www.hermes-science.com www.lavoisier.fr ISBN 2-7462-1200-5 Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins d’identification et sont des marques de leurs détenteurs respectifs.

Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une part, que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du Code de la propriété intellectuelle.

L’audit technique informatique

Henri Ly

COLLECTIONS SOUS LA DIRECTION DE NICOLAS MANSON

Collection Management et Informatique Collection Etudes et Logiciels Informatiques Collection Nouvelles Technologies Informatiques Collection Synthèses Informatiques CNAM La liste des titres de chaque collection se trouve en fin d’ouvrage.

TABLE DES MATIÈRES

Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Claude PINET

11

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Chapitre 1. Historique et nécessité de l’audit . . . . . . . . . . . . . . . . . . .

15

1.1. Management et système d’information . . . . . . . . . . . . . . . . 1.2. Rappel historique de l’audit . . . . . . . . . . . . . . . . . . . . . . . 1.3. Les différents acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Les besoins et les nécessités d’audit informatique . . . . . . . . . . 1.4.1. Le système d’information et la résistance aux changements 1.4.2. Les postes de coûts et le concept ROI . . . . . . . . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

15 18 20 24 25 26 33

Chapitre 2. Les contextes techniques pour les missions d’audit . . . . . . .

39

2.1. Les contextes techniques . . . . . . . . . . . . . . . . . . . 2.2. Les cycles de vie et les systèmes . . . . . . . . . . . . . . . 2.3. Les référentiels relatifs aux logiciels de qualité . . . . . . 2.3.1. La norme ISO/SPICE 15504 . . . . . . . . . . . . . . 2.3.2. La norme ISO/IEC 12207 . . . . . . . . . . . . . . . . 2.3.3. La norme 9126 relative à l’évaluation des logiciels

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . .

40 45 51 52 54 56

6

L’audit technique informatique

2.4. Classification générique des types d’audit . . . . . . . . . . . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 63

Chapitre 3. Les diverses phases d’une mission d’audit . . . . . . . . . . . . .

67

3.1. Les diverses phases . . . . . . . . . . . . . . . . . . . 3.1.1. Les principales phases et le schéma global . . 3.1.2. L’enquête préliminaire . . . . . . . . . . . . . 3.1.3. Phase de vérification . . . . . . . . . . . . . . . 3.1.4. Phase de restitution et du rapport . . . . . . . 3.2. Les techniques, les outils et la formation . . . . . . 3.3. Exemple et démarche pour les audits qualité d’un service de support . . . . . . . . . . . . . . . . . . . 3.3.1. Phase de pré-audit et de planification (14 %) 3.3.2. Phase de l’enquête préliminaire (25 %) . . . . 3.3.3. Phase de vérification rapide (20 %) . . . . . . 3.3.4. Phase de vérification ou réalisation de l’audit proprement dit (25 %) . . . . . . . . . . . . . . . . . . 3.3.5. Phase de restitution et du rapport (16 %) . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

67 67 69 72 74 77

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

77 78 79 79

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80 81 83

Chapitre 4. Les missions d’audit demandées par la Direction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

4.1. Audit de la politique informatique . . . . . . . . . . . . . . . . . . . . 4.1.1. Audit de la politique d’acquisition en vue de l’informatisation (adéquation des produits verticaux, rentabilité) 4.1.2. Audit des projets et futurs projets (audit de processus de développement) . . . . . . . . . . . . . . . . . 4.2. Audit relatif aux finances de la fonction informatique . . . . . . . . 4.2.1. Audit du budget et du suivi . . . . . . . . . . . . . . . . . . . . . 4.2.2. Audit sur la comptabilité analytique . . . . . . . . . . . . . . . 4.2.3. Audit sur les prestations internes . . . . . . . . . . . . . . . . . 4.2.4. Audit des coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. .

87

. .

87

. . . . . . .

. . . . . . .

90 94 94 95 96 97 101

Table des matières

Chapitre 5. Missions d’audit demandées par la Direction technique/informatique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Audit sur l’utilisation des logiciels (utilisation, licences, piratage) 5.2. Audits de qualité de services et de l’informatique horizontale . . . 5.2.1. La qualité de service des systèmes . . . . . . . . . . . . . . . . 5.2.2. Audit de l’utilisation et de l’exploitation des logiciels horizontaux . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Audit d’un grand centre de serveur ou d’un Business Intelligence Centre . . . . . . . . . . . . . . . . . . . . 5.3.1. Les outils et éléments d’investigation . . . . . . . . . . . . . . 5.3.2. Quelques résultats de l’audit . . . . . . . . . . . . . . . . . . . 5.4. Audit des ressources humaines . . . . . . . . . . . . . . . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

103

. . . . . . . . .

103 106 106

. . .

111

. . . . .

. . . . .

112 114 115 117 121

Chapitre 6. Problème de sécurité et audits associés . . . . . . . . . . . . . . .

123

6.1. Plan de sécurité de l’entreprise . . . . . . . . . . . . . . . . . . . 6.1.1. Plan de sécurité concernant la protection des matériels (surtout les serveurs) et de la salle de stockage correspondante. 6.1.2. Sécurité concernant les fichiers . . . . . . . . . . . . . . . . 6.2. Sécurité dans le domaine des matériels et de la documentation 6.2.1. Sécurité des matériels . . . . . . . . . . . . . . . . . . . . . 6.2.2. La sécurité de la documentation . . . . . . . . . . . . . . . 6.3. La sécurité des supports d’informations (les contenants) . . . . 6.4. Sécurité dans le domaine des fichiers (les contenus, les données et programmes) . . . . . . . . . . . . . . . 6.4.1. Moyens de détection . . . . . . . . . . . . . . . . . . . . . . 6.4.2. Remèdes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5. Audit et sécurité dans le domaine du réseau. . . . . . . . . . . . 6.5.1. Normes de sécurité . . . . . . . . . . . . . . . . . . . . . . . 6.5.2. Systèmes garantissant la sécurité . . . . . . . . . . . . . . . 6.5.3. Centre de contrôle de réseau . . . . . . . . . . . . . . . . . 6.5.4. Surveillance du réseau . . . . . . . . . . . . . . . . . . . . . 6.6. Audit et sécurité des applications Web. . . . . . . . . . . . . . . 6.7. Audit d’un centre à la suite de plusieurs attaques . . . . . . . .

. . . . .

. . . . .

124

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

126 127 128 128 129 130

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

131 133 134 134 135 138 139 143 145 147

8

L’audit technique informatique

6.7.1. Phase de pré-audit et de planification (0,5 jour) 6.7.2. Phase de l’enquête préliminaire (2 jours) . . . . 6.7.3. Phase de vérification rapide (2,5 jours) . . . . . 6.7.4. Phase de vérification ou réalisation de l’audit proprement dit (3,5 jours) . . . . . . . . . . . . . . . . . 6.7.5. Phase de restitution et du rapport (1,5 jour). . . . 6.7.6. Recommandations plus techniques. . . . . . . . . 6.8. Sécurité et droit de l’informatique . . . . . . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

148 149 149

. . . . .

. . . . .

150 151 153 154 159

Chapitre 7. Plans types et exemples de procédures . . . . . . . . . . . . . . .

163

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7.1. Plan type d’un programme de travail . . . . . . . . . . . . . . . . . 7.2. Plan type d’un rapport . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Exemples de procédures d’audit . . . . . . . . . . . . . . . . . . . 7.3.1. Exemple de procédure d’audit interne . . . . . . . . . . . . . 7.3.2. Exemple de procédure d’audit qualité pour la qualification d’un produit logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4. Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1. Annexe 1 : plan type du rapport d’audit . . . . . . . . . . . . 7.4.2. Annexe 2 : exemple des éléments du référentiel . . . . . . . Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

163 165 166 166

. . . . .

. . . . .

. . . . .

. . . . .

170 182 182 183 185

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

187

Annexe 1. Rappel des outils pour les auditeurs . . . . . . . . . . . . . . . . . .

191

A1. Rappel des outils pour les auditeurs . . . . . . . . . . . A1.1. La technique de réunion . . . . . . . . . . . . . . . . . A1.1.1. Les interviews . . . . . . . . . . . . . . . . . . . . A1.1.2. Le questionnaire . . . . . . . . . . . . . . . . . . A1.2. Les autres techniques, les tests et les outils logiciels A1.2.1. Outils de test. . . . . . . . . . . . . . . . . . . . . A1.2.2. Outils (logiciels) . . . . . . . . . . . . . . . . . . A1.2.3. La formation . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

191 191 192 193 193 193 194 195

Table des matières

9

Annexe 2. Démarche pour un plan de sécurité . . . . . . . . . . . . . . . . . .

197

Annexe 3. Fonctions illicites des programmes malveillants . . . . . . . . . .

201

A3. La fonction illicite . . . . . . . . . . . . . . . . . . A3.1. La fonction à déclenchement différé . . . . . . A3.2. La fonction de déplacement . . . . . . . . . . . A3.3. La fonction autoreproductrice . . . . . . . . . . A3.3.1. Définition des programmes dévastateurs A3.3.2. Les virus par ajout . . . . . . . . . . . . . A3.3.3. Les virus par recouvrement . . . . . . . .

. . . . . . .

201 202 202 203 203 204 205

Annexe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

A4. General principles . . . . . . . . . . . . . . . . . A4.1. General objectives of the procedure . . . . . A4.1.1. Application field . . . . . . . . . . . . . A4.1.2. Expected benefits . . . . . . . . . . . . . A4.2. Conditions for application of the procedure A4.2.1. Quality audit Procedure Requirements A4.2.2. Pre-requisites . . . . . . . . . . . . . . . A4.3. Outpout of the quality audit process . . . . . A4.3.1. Quality audit report . . . . . . . . . . . A4.3.2. Recommandations . . . . . . . . . . . . A4.4. Phases of the quality audit procedure . . . . A4.4.1. Diagram of the process . . . . . . . . . A4.4.2. A step by step procedure. . . . . . . . . A4.4.3. Validity . . . . . . . . . . . . . . . . . . . A4.4.4. Modulation. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

209 209 209 209 210 210 211 212 212 212 213 213 215 216 216

Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219

Lexique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

221

PRÉFACE

Il devient impossible de lire un magazine, de regarder la télévision ou d’écouter la radio sans voir ou entendre les sujets concernant Internet en général, l’informatique en particulier ainsi que de leurs problèmes ou déboires : tel opérateur en désarroi, telle société en ligne en faillite, tel système informatique ou serveur attaqué… Par conséquent, force est de constater qu’Internet et l’informatique qui constituent une avancée technologique indéniable possèdent leurs propres faiblesses. Comment pallier ces dernières, comment protéger, détecter les points faibles et vérifier l’adéquation de son système d’information et/ou de ses outils sont les questions actuellement posées par bon nombre de responsables et dirigeants. Comprendre, apprendre, se former et s’informer ne sont-ils pas les « piliers spirituels » et moyens nécessaires pour s’adapter aux nouvelles technologies présentes, naissantes ou futures. Il en est de même pour la surveillance de ces outils tel que l’audit informatique. Ce livre sur la théorie et les pratiques de cette matière applique bien ce principe par une démarche originale comprenant : – un rappel historique et l’origine des concepts d’audit ; – une sensibilisation par l’illustration des exemples et des cas ; – une explication des principes de base et des notions techniques ; – une présentation des solutions avec les différentes approches (conseils et recommandations) ;

12

L’audit technique informatique

– des FAQ et réponses permettant de mieux appréhender les concepts et répondre aux préoccupations des utilisateurs… D’autre part, la démystification d’un sujet complexe, assortie d’exemples et de conseils n’est-elle pas une condition sine qua non pour la compréhension, l’assimilation et l’application ? L’ouvrage d’Henri Ly est bien conforme à cette démarche de démystification des moyens de l’informatique et de l’audit interne et informatique. La conservation du patrimoine informationnel de l’entreprise, donc sa pérennité ne peut se concevoir sans une surveillance et revue accrue de son système d’information et de ses outils informatiques. L’audit informatique est donc un moyen incontournable et nécessaire pour ses dirigeants et ses actionnaires, matière de pratique pour « l’entreprise bien gérée » donc matière de formation et d’apprentissage pour tout cadre informatique ou étudiant en situation professionnelle dans un proche avenir.

Claude PINET Ingénieur expert Membre de l’AFNOR DG de CPI Consulting

AVANT-PROPOS

La connaissance est le début de l’action : l’action, l’accomplissement de la connaissance. Wang Yang Ming – Mandarin et philosophe chinois (1472-1529)

De nombreux théoriciens considèrent que l’entreprise est une « boîte noire » avec, à l’entrée, des flux d’informations, et, à la sortie, des produits finis d’objets et/ou d’informations. Boîte noire complexe pour les uns, dans laquelle tous les éléments doivent être coordonnés, synchronisés et « huilés », organisation fonctionnant dans un environnement imparfaitement connu pour les autres, l’entreprise se doit de fonctionner, survivre, se rendre compétitive et conquérir les marchés au risque de décliner et mourir à terme. Les entreprises ont besoin d’outils, de systèmes d’information et d’informatique de plus en plus complexes. Ces outils doivent être fiables et fonctionner parfaitement au risque de ralentir le processus de production général et de perdre les clients et les marchés. Pour fiabiliser ces moyens, il faut : – diagnostiquer, – vérifier, – contrôler, – prévenir les défaillances, – trouver des moyens correctifs, – formuler des recommandations pour les responsables décisionnels.

14

L’audit technique informatique

Ce sont les rôles des contrôleurs de gestion, de l’inspection, des auditeurs et, particulièrement pour les systèmes d’information et d’informatique, celui des acteurs de l’audit informatique. Ce livre n’a pas pour ambition de présenter une méthode universelle d’audit informatique, mais celle de fournir aux lecteurs : – une définition claire et précise des principaux acteurs, – une démarche, des approches pragmatiques plutôt qu’une méthodologie pure, – des exemples concrets dans des contextes et l’environnement des CTI. (Centres de traitement des informations) sans omettre le rôle de l’auditeur informatique dans chaque cas d’étude, – des exemples d’exercices pour mieux assimiler les définitions et concepts de chaque chapitre, – un lexique récapitulatif des termes utilisés. Si cet ouvrage donne des informations nécessaires à un non-spécialiste pour mieux connaître l’environnement du contrôle et de l’audit et aux vérificateurs ou auditeurs non-informaticiens, un fil conducteur ainsi que des moyens d’aborder le volet audit informatique, son objectif sera atteint.

CHAPITRE 1

Historique et nécessité de l’audit

La rigueur vient toujours au bout de l’obstacle. Léonard de Vinci, peintre, ingénieur et savant italien (1454-1519)

1.1. Management et système d’information En matière de gestion d’entreprise, quelle que soit la nature juridique ou le type d’activité, on peut établir deux principes importants : – aucune entreprise ne peut fonctionner sans un système d’information de gestion, nommé souvent SI de l’entreprise ; – aucune entreprise ne peut survivre et sa pérennité est mise en jeu si elle ne possède pas un bon manager ou un chef d’entreprise compétent. « Manager » consiste à trouver l’adéquation entre les ressources financières, humaines, matérielles et les finalités des projets et des objectifs de son entreprise. Une société a donc besoin d’un bon manager qui sache piloter son « système d’entreprise ». « Piloter » un système, c’est choisir un objectif final (éventuellement composé de plusieurs sous-objectifs ou objectifs d’étapes), définir la meilleure trajectoire, lancer le démarrage puis corriger en permanence les écarts par rapport à la trajectoire et à l’objectif lorsque les informations sur les états de l’environnement et sur le comportement du système montrent que la planification initiale

16

L’audit technique informatique

ne peut être maintenue. En résumé, une activité de pilotage, pour un bon dirigeant, comporte des actions de planification, de programmation, de coordination et de contrôle. Le système d’information de gestion d’une entreprise est formé par l’ensemble des ressources et moyens utilisés pour traiter les « informations » et atteindre son objectif ou ses finalités. A partir des informations internes ou externes de l’entreprise, le système enregistre les diverses opérations, les mémorise, les traite et produit différents types de résultats. Il est à remarquer qu’un système informatique n’est ni un système d’information, ni un système d’information de gestion, il n’est qu’un outil ou moyen de traitement et de compilation d’informations au service des deux autres. Un système d’information peut être considéré comme un langage et un réseau de communication (au sens large) d’une entreprise, d’une organisation, construit consciemment pour représenter de manière fiable et objective, de manière formelle, rapide et économique certains aspects de son activité passée ou à venir. Un système d’information de gestion est un système d’information qui représente une réalité composée d’objets et d’événements. Un objet est un élément mesurable qui vit et qui peut être transformé par un événement. C’est un élément mobile dans l’espace et le temps. Un événement est un fait. Il se produit à un moment, dans un lieu ou à un endroit déterminé. Il se déroule dans un laps de temps et dans un certain lieu. Prenons un exemple : le déclenchement d’une commande d’un client est un événement, l’article commandé est un objet. Une fois l’élément parti, le stock diminue et l’ordinateur peut déclencher un autre événement : imprimer un message signalant que le seuil minimum est atteint par exemple. Les volumes d’informations ne cessent de croître, et l’exigence de ces derniers, en temps réel, ne cesse de s’amplifier depuis ces dernières décennies, d’où l’importance de posséder des outils informatiques

Historique et nécessité de l’audit

17

fiables, cohérents et sécurisés. De ce fait, l’audit informatique a pris de l’ampleur durant ces dernières années. Le noyau du système de gestion d’information qui constitue le « système d’information » est composé d’un ensemble de données élémentaires ou « indicateurs », et de la combinaison de ces derniers pour la conception du ou des « tableaux de bord ». Concernant la notion de concept de système d’information de gestion, nombre d’entreprises, privées ou publiques (dont France Télécom) déterminent et respectent les quatre principes suivants : la rigueur, l’unicité, la fiabilité et la cohérence. Concepts que nous détaillons ci-dessous : – rigueur : une précision et une définition claire des données élémentaires ou indicateurs doivent être appliquées. La circulation d’informations et les délais d’obtention, les méthodologies de saisie (quand, comment, où, par qui) ainsi que celles de calcul et d’agrégation des éléments doivent être bien définis et respectés ; – unicité : l’unicité de la conception d’un indicateur, de son mode de saisie, de son mode de remontée doit être réelle et respectée. Ce concept garantira que les valeurs utilisées par les divers responsables, quel que soit leur lieu d’exercice de gestion et leur niveau de responsabilité sont identiques rendant possible une comparaison des résultats, éléments de base de discussion et d’amélioration ; – fiabilité : la fiabilité des informations transmises doit être garantie. A chaque remontée d’indicateurs, un responsable doit valider les valeurs transmises. On remarque à ce niveau encore, l’importance du rôle des auditeurs internes ; – cohérence : le système d’information se présente comme un ensemble cohérent. Les indicateurs ne doivent pas être redondants et doivent couvrir tous les domaines d’activité. Un domaine est couvert par un ensemble d’indicateurs riche et complexe que l’on doit énumérer et évaluer à sa juste valeur en fonction de son degré d’importance. En effet, le fait d’avoir trop d’informations nuit et ralentit le processus de mise à jour, donc de décision.

18

L’audit technique informatique

C’est dire l’impact du rôle que doivent jouer les vérificateurs, contrôleurs internes ou externes dans la vie de l’entreprise pour la certification et la fiabilisation des informations. Enfin les trois axes d’analyse du système d’information sont : temporel, géographique, par entité ou par nature. 1.2. Rappel historique de l’audit Depuis l’Antiquité, les hommes ont senti la nécessité d’utiliser un véritable système de comptabilité. Par exemple, 2000 ans avant J.-C., les Sumériens (habitants de la Mésopotamie sur le Golfe Persique) avaient un code de la comptabilité qui incluait jusqu’à la comptabilité analytique. Le commerce entre les différents peuples (Romains, Egyptiens, Grecs...) conforta la technique comptable. La nécessité de gérer leur domaine amena l’Eglise et les administrations publiques, au Moyen-Age, à perfectionner le système comptable. Ainsi, le premier trait de comptabilité, en partie double, fut l’œuvre du Frère Lucas Pacioli. Progressivement, le besoin de contrôler les comptes imposés prit de l’ampleur. Les premiers auditeurs seraient les Missi dominici sous Charlemagne et, au XIIIe siècle, dans les cités de Pise et de Venise, des comptables faisaient office d’auditeurs de la municipalité. Il apparaît que les organisations créées sous l’initiative royale, ecclésiastique ou municipale ont contribué au développement de la technique comptable et de l’activité d’audit. Cependant, il faut attendre la fin du XIXe siècle pour voir la naissance des associations de comptables. Ce fut le cas en France avec la création, par décret, de l’Ordre des experts comptables et comptables agréés et de la Compagnie nationale des commissaires aux comptes. Aux Etats-Unis, the Security Act de 1935, loi fondamentale sur le contrôle des comptes des sociétés américaines, impose l’opinion favorable d’un expert comptable indépendant sur tous les comptes et bilans.

Historique et nécessité de l’audit

19

Cette certification ne serait accordée par les experts qu’après de nombreuses vérifications aussi rigoureuses que coûteuses d’où l’idée de contrôle interne avant la « transmission » des documents aux experts externes afin d’alléger les coûts. Ainsi, à l’origine, la fonction d’audit interne fut d’ordre purement comptable. Placés devant le besoin de créer ce contrôle interne, les dirigeants américains cherchaient à tirer le maximum d’avantages pour leur propre compte, et de ce fait les domaines d’investigations des auditeurs internes se trouvaient, élargis surtout vers 1950. L’Institut français des auditeurs et contrôleurs internes créé à Paris en 1965 (l’IFACI), organisme rattaché à l’Institute of Internal Auditors fondée à New York en 1941, a donné la définition suivante « l’audit interne est la révision périodique des instruments dont dispose une direction pour contrôler et gérer l’entreprise ». Compte tenu de l’évolution du métier, l’IFACI – dont le siège qui est à Paris (rue Henri Bergson, 8e) – a été rebaptisé l’Institut français des auditeurs et consultants internes. Cet organisme, qui est chargé de représenter la profession d’audit, a pour mission de promouvoir son développement et de servir les auditeurs et conseillers internes provenant de tous horizons. En ces temps de rigueur et de forte concurrence, les fonctions de contrôle de gestion et d’audit sont mises en valeur et les activités correspondantes sont plus que jamais à l’ordre du jour. L’entreprise doit consolider ses parts de marché actuelles, tout en en conquérant de nouveaux, en s’appuyant sur ses structures, son organisation, ses acquis. Elle doit aussi sécuriser ses systèmes d’information en général, d’information de gestion en particulier, et consolider ses patrimoines et acquisitions... Bref, elle a besoin de plus d’efficacité et de rentabilité. Les dirigeants doivent pouvoir évaluer le système de gestion, vérifier la fiabilité des informations et s’informer par tests de façon intermittente.

20

L’audit technique informatique

Il est à noter qu’actuellement, avec la mondialisation de l’économie et des finances, les audits de diagnostic et de fusion deviennent des activités en croissance et très à la mode. Dans le domaine du contrôle, on trouve des personnes occupant des postes différents et exerçant des fonctions distinctes. Néanmoins, elles sont souvent appelées à travailler ensemble car leurs missions respectives concourent à la bonne marche et à l’expansion de l’entreprise. Le paragraphe suivant permet de détailler les différents acteurs du monde du « contrôle ». 1.3. Les différents acteurs Les mots de contrôle et audit suscitent une certaine appréhension, ils inquiètent et intriguent à la fois. On confond souvent les activités et ces fonctions, d’autant plus que ces dernières, récemment apparues dans l’entreprise, sont mystérieuses et multiformes. En effet, de par sa fonction, un réviseur-comptable doit contrôler les documents comptables, mais un responsable de sécurité devrait aussi exécuter des contrôles et des inspections... Cependant que ce soit un consultant, un contrôleur de gestion, un responsable de sécurité, un auditeur interne, un organisateur ou un réviseur-comptable, il doit avoir une capacité d’écoute et une « envie d’entendre » certaines vérités... Essayons de définir les fonctions de ces acteurs : – l’organisateur est la personne intervenant à la demande de la Direction et a pour mission de proposer une structure avec la définition précise des rôles et responsabilités de chaque élément de la structure ; – le responsable de sécurité a pour mission d’assurer le contrôle et l’inspection des sites afin de détecter les risques éventuels de l’entreprise, c’est-à-dire d’assurer la sécurité physique des individus et du patrimoine. Cette personne a aussi pour mission de vérifier les normes imposées par la législation et le suivi du règlement intérieur établi ;

Historique et nécessité de l’audit

21

– le contrôleur de gestion est, quant à lui, l’assistant de la Direction qui établit des budgets, fait des prévisions et contrôle les réalisations. Il conçoit ou participe à la conception d’un système d’information et en assure le suivi. Il peut exécuter des contrôles internes d’une façon continue, détecter et analyser les écarts ; – l’auditeur interne intervient suivant un planning ou sur ordre de mission. Il prend une « photo », à un instant donné, d’un service, d’une organisation... Il apprécie l’état du contrôle interne (ou effectue un contrôle du système de contrôle interne). Les résultats de ses travaux sont édités dans un rapport comprenant constats et recommandations. Si tout fonctionne correctement, son rapport sera en quelque sorte un satisfecit ; – le réviseur-comptable apprécie la validité des documents issus de la comptabilité qui seront rendus publics : le bilan, le compte des résultats, les informations annexes… Cette personne certifie ces documents dans le délai imposé par la loi ou le marché. Elle fournit en quelque sorte un quitus : c’est le rôle principal du réviseur-comptable externe ; – le consultant est la personne qui subit les lois du marché (de l’offre et de la demande) et possède une spécialité et une compétence reconnues. Il formule des avis et conseils relatifs aux problèmes détectés. On peut citer, par exemple, les consultants administratifs ou comptables ou d’organisation. Nous avons défini les fonctions de ces « différents » acteurs, nous pouvons citer maintenant leurs caractéristiques et qualités communes. Ils doivent posséder des capacités d’organisation, de sens pratique, certaines facilités de contact. Ils doivent pouvoir aussi faire preuve de diplomatie, d’impartialité et enfin avoir des dispositions pour l’analyse et la synthèse. En résumé, ils doivent montrer un sens aigu de l’adaptabilité et une capacité réelle d’écoute. S’ils doivent tous posséder ces qualités humaines (sauf le responsable de sécurité et le réviseur externe peutêtre), il existe néanmoins des différences concernant leur domaine de compétence et leur rattachement hiérarchique : – Direction générale (DG) ;

22

L’audit technique informatique

– Direction financière et comptable (DFC) ; – Direction technique (DT). Les domaines de compétence sont les suivants : a) contrôle comptable ; b) contrôle technique, commercial, comptable, sécurité ; c) diagnostic, avis et conseil ; d) sécurité physique des systèmes et/ou des agents ; e) avis et conseil, planification d’un projet ; f) contrôle des résultats des divers services, consolidation confection des tableaux de bord de suivi. Le tableau 1.1 résume la direction d’attache de chaque acteur ainsi que son domaine d’intervention et de compétence.

Agent

Organisateur

Direction d’attache

Domaine de compétence

DG, DFC (Direction des Finances et comptabilité)

E

DT (Direction technique)

D

Contrôleur de gestion

DG, DFC

F

Auditeur interne

DG, DFC

B

Réviseur comptable

Indépendant

A

Consultant

Indépendant

C

Responsable de sécurité

Tableau 1.1. Direction d’attache et domaine d’intervention

23

Historique et nécessité de l’audit

Points de comparaison

Statut

1. But des travaux

assure les intérêts des actionnaires et tiers, assure les intérêts de la Direction générale liberté concernant le programme d’action, travail en fonction d’une demande planifiée de la Direction

2. Moyens d’action 3. Eléments à contrôler

4. Opération d’investigation

Régularité et sincérité des informations rendues publiques, régularité et sincérité des informations internes Sécurité et conservation du patrimoine d l’entreprise, sécurité des personnes Outils de gestion (adéquation et efficacité) Détection : des fraudes de la non-sincérité des comptes des erreurs (par ex : des bilans, journaux), des gaspillages, des pertes, relevés des omissions relevé des poins faibles ou inadéquation des méthodes ou outils de gestion. Evaluation des manques à gagner

5. Eléments et domaines à contrôler

Les informations comptables (opérations, patrimoine, divers comptes…), les modes d’organisation dans la société, le personnel, les fonctions, les structures, la politique générale de l’entreprise

6 - Les résultats des travaux

Certifications ou émissions des réserves, relevés des fraudes et des délits rapports, notes de synthèse, constats, et les recommandations, conception des fiches de suivie

Auditeur interne

Réviseur externe X

X X X X

X

X X X X

X X X X X X

X X X X

X X

X

X X X

X X X

Tableau 1.2. Différence entre une révision externe et un audit intene

X X

24

L’audit technique informatique

Les rôles des différents acteurs étant définis, il nous importe de définir l’audit interne et l’audit informatique, ainsi qu’un rappel rapide du contexte de travail potentiel des auditeurs informatiques. L’audit interne est une activité indépendante d’appréciation, de contrôle de l’exécution et de l’efficacité des autres contrôles, en vue d’assister la Direction. Pour l’audit informatique, nous préconisons la définition suivante : L’audit informatique est une activité de contrôle du management informatique pour apprécier l’utilisation, l’exécution, l’efficacité et l’adéquation des éléments constitutifs du système informatique ou du système d’information avec l’objectif et l’orientation de l’entreprise. Afin de mieux appréhender la différence entre une révision externe et un audit interne, nous présentons six points de comparaison résumés dans le tableau 1.2 de la page précédente. Il est à remarquer que le service d’audit ou les auditeurs eux-mêmes possèdent une certaine initiative en ce qui concerne le programme d’action, mais pas un réel pouvoir de décision. 1.4. Les besoins et les nécessités d’audit informatique Comme nous l’avons vu, pour les leaders et dirigeants, le besoin d’audit est provoqué par celui d’obtenir le retour des informations sur des organisations mises en place. Cela date de l’Antiquité, mais qu’en est-il pour les éléments justifiant la nécessité et les besoins d’audit informatique ? En fait, on peut identifier cette nécessité et ces besoins d’audit informatique par les trois éléments ci-après : – c’est d’abord dans le cadre du prolongement du développement de la théorie de la révision comptable que l’examen et le contrôle des

Historique et nécessité de l’audit

25

systèmes d’informatique de gestion ont vu le jour. En France, dans les années 1970-1980, le Conseil Supérieur de l’ordre des Experts Comptables a fixé à l’usage de ses membres les principes fondamentaux de révision : « la révision des comptabilités traitées par des moyens informatiques » puis « la révision dans un environnement informatique » (recommandation de révision n°7) ; – les dirigeants ressentent, au fil des années, le besoin d’audit informatique afin de connaître l’impact du changement dû aux introductions de systèmes informatisés dans l’environnement du travail ; – le besoin de connaître les chiffres et le retour des investissements (ROI) avec les divers coûts et les risques encourus. En effet, pour tous les dirigeants, l’analyse des coûts et le ROI sont des indicateurs-clés pour la gestion de leurs entreprises. Dès lors, ces points sont des éléments primordiaux pour les auditeurs car les fonctions informatiques et les systèmes (générant des coûts) font partie de leurs domaines de compétences et d’examen. Effectuons un rapide rappel de ces éléments et de leurs concepts associés. 1.4.1. Le système d’information et la résistance aux changements Avant de détailler ces éléments pour mieux connaître le système d’information de l’entreprise, il nous importe d’appréhender un phénomène, que parfois les auditeurs peuvent rencontrer, appelé la résistance aux changements. En effet, nombre d’organisations rencontrent des problèmes suite à l’implémentation d’une nouvelle technologie en général, et d’un système informatique en particulier. Pire encore, il existe parfois la fourniture de fausses informations ou « sabotage » pendant la phase de pré-étude en vue d’instaurer un nouveau système. La résistance au changement n’est pas un problème nouveau, mais déjà identifié par Michel Crozier, professeur à Paris, à Harvard aux Etats-Unis et fondateur de la sociologie des organisations. Henry Mintzberg, économiste et également professeur aux Etats-unis a également parlé de ce problème. En effet, résumée d’une façon

26

L’audit technique informatique

succincte, la résistance aux changements se caractérise par la peur du transformation du contexte de travail, la peur de la perte du pouvoir, des acquis et par l’appréhension de l’apprentissage des nouveaux systèmes. Ainsi l’opposition envers l’innovation, l’automatisation (première), l’introduction d’un nouveau système d’information et le changement peut être due aux intérêts d’un groupe ou personnels par rapport au statu quo ou par rapport à un système déjà en vigueur. Nous nous permettons de signaler ce phénomène afin de mettre en évidence la raison pour laquelle, parfois, un auditeur informatique ne trouvait pas de failles techniques vis-à-vis d’un nouveau système mis en place, mais un rendement faible, inattendu avec une démotivation et une mauvaise ambiance. Dans ce contexte, il est du devoir de l’auditeur de signaler cet état des choses à la hiérarchie de ce service et à la Direction générale et de ne plus continuer à rechercher les points faibles techniques. La mission est dès lors hors de son domaine de compétence. C’est plutôt un problème sociologique et managériale. Ce n’est plus de l’audit informatique que l’on a besoin mais d’un audit social. De ce fait, le rôle de l’auditeur est le suivant avant de passer toutes les informations à la Direction générale : – identifier la motivation des utilisateurs (vis-à-vis du nouveau système mais non individuelle) ; – identifier s’il existe une stratégie d’adaptation aux changements ; – identifier s’il existe des attentes irréalistes du nouveau système. 1.4.2. Les postes de coûts et le concept ROI 1.4.2.1. Les postes de coûts Le projet d’informatisation d’une entreprise ou la refonte de son système informatique constitue un investissement important. Pour évaluer le coût de l’informatique on peut se poser la question de savoir quelle est la part des ressources que l’on consacre ou que l’on devrait consacrer à la création, au développement et à la maintenance

Historique et nécessité de l’audit

27

du système informatique. On considère que le budget informatique est constitué par un certain nombre de charges. L’évaluation du coût de l’informatique est déterminée suivant deux cas différents. 1ercas : l’entreprise ne possède pas encore les outils informatiques, mais envisage l’automatisation. Ceci est de plus en plus rare, sauf cas particulier des PME ou chez les artisans. Dans ce cas, l’équipe dirigeante doit s’assurer que le coût engendré ne risque pas de mettre en péril l’équilibre financier de l’entreprise. A chaque étape des études de conception du système, on pratique, simule les calculs d’évaluation, et on rectifie au besoin. On peut comparer cela à un pilotage à vue devant aboutir à un objectif qui consiste à instaurer un système conforme aux besoins et aux capacités financières de la société. 2e cas : l’entreprise possède un système informatique. L’évaluation du coût de l’informatique revient à déterminer le budget annuel pour l’informatique en fonction de l’historique et des prévisions liées aux missions que devra accomplir le système. On exprime les montants par poste et par période (trimestrielle, semestrielle...) et à mesure que les dépenses sont connues, il faut calculer les écarts pour contrôler et, éventuellement, procéder à des rectifications. 1.4.2.2. Les diverses charges informatiques de l’entreprise En dehors des charges intrinsèques du matériel et de celles du logiciel, on doit distinguer les charges environnantes : – les charges de premier établissement ; – les charges répétitives ou périodiques. 1.4.2.2.1. Les charges de premier établissement Ce sont les charges qui ne se rencontrent qu’une fois pour une application ou un projet donné. Par exemple :

28

L’audit technique informatique

– le coût de l’étude d’opportunité ; – les dépenses pour la sensibilisation du personnel ; – les coûts de conversion (initiation, formation) ; – les frais de réorganisation partielle ou totale ; – les coûts ou pertes dues à l’interruption des opérations ; – les dépenses de formation du personnel informaticien ou utilisateur ; – le coût d’analyse fonctionnelle ; – le coût d’analyse organique ; – le coût de programmation ; – le coût des essais ; – le coût d’établissement de la documentation. 1.4.2.2.2. Les charges périodiques ou répétitives Ce sont les charges qu’on retrouve de par leur nature, d’exercice en exercice, tant que le système informatique fonctionne. Il convient de remarquer qu’elles sont fonction des configurations choisies au préalable. Exemple : dans un environnement de mini-ordinateurs, lors de la vérification des coûts, il faut tenir compte des charges du personnel d’exploitation existant ainsi que des frais généraux, mais dans un contexte de micro-ordinateurs, les frais généraux sont réduits et, en théorie, les frais de personnel exploitant doivent être inexistants. Ces charges constituent la base d’un budget informatique annuel, appelé aussi budget de fonctionnement. Ce sont : – les charges de personnel ; – les charges de matériel (location, maintenance) ; – les charges locatives des logiciels ; – les charges de fournitures ; – les frais généraux inhérents au système informatique (locaux, climatisation, entretien, assurance).

Historique et nécessité de l’audit

29

D’autre part, il importe de savoir que la comptabilité nous permet, dans le cas d’achat de matériel, de programmes ou progiciels, d’affecter ces dépenses dans des postes à amortir et que certaines d’entre elles, les salaires, les charges de location du matériel ou des programmes par exemple, peuvent être portées directement au compte d’exploitation général. Enfin, dans les centres informatiques, on commence à mettre en valeur le coût des erreurs. Une simple faute d’analyse ou de manipulation peut engendrer des erreurs de traitement qui nécessitent des recherches, des rectifications, des recyclages causant des retards dans la chaîne de traitement. Le budget initial prévu sera alors modifié créant des écarts entre prévisions et réalisations. On appelle aussi ce coût, le coût de la « nonqualité ». Les missions ainsi que les rôles de l’auditeur informatique relatifs aux problèmes de coût seront développés plus loin. Essayons pour l’instant de déterminer les problèmes de retour d’investissement en informatique. 1.4.2.3. Le concept ROI (retour d’investissement) en informatique Le ROI (Return on Investment) ou le RSI en français (retour sur investissement) est une mesure économique utilisée par les dirigeants et responsables pour évaluer l’impact d’une décision. Cette dernière peut être une décision d’investissement ou d’affaire en général. Appliqué en informatique, le ROI reflète la qualité d’un investissement en informatique : investissement en matériel ou en logiciel. A part l’investissement matériel qui peut être considéré comme amortissable par la législation fiscale en matière de comptabilité, il importe de savoir le gain engendré par l’ensemble informatique pour l’entreprise par le calcul et la définition des critères au préalable. Les éléments suivants les plus utilisés sont le temps, les coûts d’acquisition et la satisfaction des utilisateurs (sans compter l’économie du

30

L’audit technique informatique

personnel engendrée par l’automatisation). Les outils pour et résultant d’une démarche ROI sont donc ceux qui permettent de fournir des chiffres importants collectés (les indicateurs clés de performance) et des tableaux de bord synthétiques. La pratique du ROI permet au moins de recouper ces trois éléments : – transparence et visibilité ; – maîtrise des coûts ; – amélioration de la qualité des services et des prestations. Ces éléments permettront alors d’évaluer la qualité de la décision prise. L’évaluation est d’autant plus pertinente que les indicateurs clés reflètent ou rapprochent la réalité contextuelle de l’entreprise. Dans une mission d’audit informatique d’investissement, les rôles de l’auditeur pourraient être les suivants : – vérifier la pertinence des indicateurs clés ; – vérifier la fiabilité des indicateurs recueillis ; – vérifier les bases de comparaison et leur fiabilité ; – contrôler l’exactitude des prestations préconisées dans un contrat de sous-traitance. En effet, bon nombre d’entreprises demandent souvent un support externe concernant l’évaluation de leurs indicateurs de performances (exemple : utilisation des logiciels et des prestations d’une entreprise spécialisée dans le conseil et du calcul de rentabilité et de performance informatique). Ces concepts étant exposés, revenons aux préoccupations techniques pour compléter notre background d’auditeur. Ainsi, afin de pouvoir exécuter des audits informatiques, l’auditeur se devrait de s’informer sur le contexte technique ainsi que sur les méthodes d’analyse et d’approche utilisées pour la conception du système d’information de son entreprise. De ce fait, bien connaître les méthodes, le cycle de vie d’un système, l’analyse de l’existant ainsi que les diverses étapes de l’informatisation, constituent un background important pour les auditeurs en informatique. Surtout si l’intéressé est amené à auditer un projet dans un contexte de vérification de la politique informatique de

Historique et nécessité de l’audit

31

son entreprise. Les chapitres suivants identifient les contextes techniques dans lesquels les auditeurs seront amenés à exercer leur métier et rappellent les concepts de cycle de vie des projets.

Résumé du chapitre 1 Ce chapitre permet aux lecteurs d’appréhender l’historique de l’audit ainsi que la nécessité et les raisons d’être de celui-ci au sein d’une entreprise. Il rappelle aussi les quatre caractéristiques primordiales du système d’information de l’entreprise qui sont la rigueur, l’unicité, la fiabilité et la cohérence. D’autre part, la surveillance des coûts, des budgets ainsi que l’obsession du retour d’investissement sont souvent les principales raisons des demandes d’audits des dirigeants. Néanmoins, il faut aussi noter que l’appréhension des résistances aux changements de la base est une préoccupation managériale. Enfin, ce chapitre identifie également les différents acteurs dans les processus de contrôle et de vérification au sein d’une entreprise.

FOIRE AUX QUESTIONS (CHAPITRE 1)

Dans le but de se familiariser avec les notions acquises, le lecteur pourra par exemple remplir le schéma d’enchaînement des besoins et de la répartition des tâches. Il pourra choisir les éléments adéquats de la liste ci-dessous et les placer dans les différents pavés, sous forme d’un schéma d’enchaînement (sachant que « le losange » représente un test : – mission confiée à l’audit interne ; – pour un dirigeant ; – pour tiers et actionnaires ; – intervention du réviseur externe ; – besoin d’évaluer le système de gestion ; – vérifier la fiabilité des informations ; – s’informer par test. Contraintes : juridique, fournisseurs, concurrences. Objectifs : profits, qualité, services.

34

L’audit technique informatique

Besoin de sécurité, d ’efficacité et de rentabilité de la société

Vérifier la fiabilité de l ’information OUI

Pour un dirigeant

?

Non Pour tiers et actionnaires

Figure 1.1. Schéma d’entraînement

NOTA BENE.– Se référer au chapitre pour l’exercice, sinon, les éléments de réponses sont donnés à la page suivante. Question 1 : quelle est la différence entre un contrôle interne et un audit ? Réponse : le contrôle interne est effectué par les agents de l’entreprise, alors que l’audit peut l’être par un cabinet externe. Le contrôle interne doit être effectué par un agent ou par le contrôleur de gestion d’une manière continue, alors que l’intervention de l’audit dans un service précis est ponctuelle. Si l’entreprise ne possède pas un service d’audit interne, elle peut faire appel à un audit externe. Enfin, il est à remarquer que l’entreprise d’une certaine taille doit d’abord posséder un service de contrôle interne avant la mise en place d’un service d’audit interne.

Foire aux questions

35

Besoin de sécurité, d ’efficacité et de rentabilité de la société Besoin d ’évaluer le système de gestion S ’informer par test Vérifier la fiabilité de l ’information Oui

Pour un dirigeant

?

Non Mission confiée à l ’audit interne

Pour tiers et actionnaires Intervention du réviseur externe

Figure 1.2. Schéma d’entraînement

Question 2 : quel est le rôle de l’auditeur interne comparativement à un contrôleur de gestion dans le cas de la détection d’une erreur de gestion ? Et en particulier en matière de produit logiciel ? Réponse : le rôle de l’audit interne n’est pas de se substituer ou de remplacer un responsable, ni un contrôleur de gestion. Dans ce cas l’audit doit révéler l’erreur au contrôleur de gestion et faire remonter l’information à la Direction générale. En matière de produit logiciel, seul le contrôle après ou avant la conception et/ou l’implantation du nouveau logiciel peut être du ressort de l’auditeur informaticien. Question 3 : s’assurer que l’organisation, les objectifs, les politiques de la société soient conformes aux réglementations en vigueur, est-ce du ressort d’un auditeur ? Et qu’en est-il de la fiabilité des informations qui remontent à la Direction ?

36

L’audit technique informatique

Réponse : les deux rôles cités sont bien ceux de l’auditeur interne. Question 4 : les contrôles de routine ou la détection systématique des fraudes (liées à l’informatique), est-ce du ressort de l’auditeur informatique ? Réponse : 1) La recherche systématique des fraudes ne devrait pas être l’attribution des auditeurs. Elle est plutôt du ressort de la personne responsable de la sécurité (au sein du service informatique) ou à défaut, de l’Inspection générale, par exemple dans une administration (ce terme d’inspection est encore très utilisé dans les administrations et les grandes banques françaises). 2) Les contrôles réguliers ou de routine sont du domaine de compétence du contrôleur de gestion ou à défaut des chefs de service. Ils ne sont en aucun cas celui de l’auditeur. Question 5 : elle est relative aux enjeux et aux risques informatiques. La possession d’un système informatique et d’un système d’information intégré exige un investissement coûteux et ces deux systèmes constituent un patrimoine primordial et vital pour l’entreprise. De par sa nature et son étendue, l’informatique comporte des risques. En fait, quels sont les enjeux directs et les enjeux indirects ? D’autre part, quel est le rôle d’un auditeur en ce qui concerne les risques informatiques ? Réponse : concernant les enjeux, par exemple, en cas d’indisponibilité prolongée d’un centre de calcul, la location du temps de calcul à un service externe est un enjeu direct. La liste ci-dessous constitue les enjeux indirects : – image de marque de la société ; – perte de trésorerie résultant des retards dans l’exécution du traitement des opérations financières ;

Foire aux questions

37

– conflit généré à cause des retards de traitement ou de planification (problème de responsabilité) ; – défaut dans les procédures d’exploitation entraînant l’écrasement des informations ; – vol d’un fichier de l’entreprise. Concernant ce dernier point, ce genre de « délit » n’engendre pas une perte financière directe pour l’entreprise, mais, à terme, le fichier volé pourrait profiter à des concurrents et, de ce fait, les chiffres d’affaires peuvent subir des variations. En effet ce type de perte ne se traduit pas tout de suite au plan comptable dans le compte d’exploitation d’une façon précise. Enfin concernant les risques informatiques, le rôle de l’auditeur est de s’assurer que les systèmes soient dotés d’une protection efficace et que leur utilisation se fasse à bon escient. Il peut également conseiller les démarches et mesures si l’opportunité se présente.

CHAPITRE 2

Les contextes techniques pour les missions d’audit

La seule vraie science est la connaissance des faits.

Georges Louis Leclerc, Comte de Buffon, naturaliste français (1707-1788)

En 500 avant J.-C., Sun Tzu, stratège chinois a écrit L’Art de la guerre, livre de chevet de tous les grands généraux et stratèges, tels Alexandre, Napoléon, Mao, Staline. Sun Tzu écrivit que pour gagner une bataille, il faut d’abord attaquer l’esprit de l’ennemi et connaître le terrain. Ramener à notre contexte, cela peut signifier qu’il est primordial que les auditeurs identifient et prennent connaissance du contexte, de l’environnement, des cycles de vie du logiciel ou projets, les référentiels ainsi que les phases (où ils peuvent contribuer) avant d’auditer et de procéder à des vérifications... Au chapitre précédent, nous avons rappelé l’historique de l’audit, ses raisons d’être et sa nécessité. Maintenant, il nous importe de connaître les contextes techniques, les cycles de vie des produits logiciels et quelques référentiels pour pouvoir appréhender l’audit informatique.

40

L’audit technique informatique

2.1. Les contextes techniques Le monde informatique est en perpétuelle évolution. Du monde des mainframes (des gros systèmes), on est passé à celui des miniinformatiques, puis avec l’apport accru des techniques d’intégrations et de la miniaturisation des composants, on est arrivé actuellement à l’ère des micro-ordinateurs serveurs et PC. L’informatique autrefois, c’était de grosses structures (centres de calcul ou appelés aussi les CTI, centres de traitement) avec une panoplie de personnel : chef de centre, chef d’exploitation (personnage important pour coordonner et planifier les centres fonctionnant en trois/huit), ingénieurs systèmes, agents de traitement… et avec des terminaux directement connectés au mainframe. De nos jours, il existe des structures plus légères avec des PC connectables via les réseaux au centre de serveurs… Cependant, mouvement de balancier ou nécessité, on assiste à un retour des centres de calcul ces dernières années, avec des mainframes et des super ordinateurs, bien entendu avec des possibilités de connexion des PC des utilisateurs via Internet, RTC et réseaux VPN (Virtual Private Networks) utilisant du VNC (Virtual Network Computing). On voit aussi fleurir de nouvelles appellations pour ces centres de traitement ou de calcul tel que « Super Info Centre » ou Business Intelligence Centre (ou BIC, appellation qui commence à apparaître dans la littérature). Lieu saint, parfois ô combien virtuel ! En effet, on ne sait plus où se trouve exactement la localisation des données et des systèmes (en raison de l’infogérance), ni la provenance exacte des réponses à nos requêtes. En effet, quelquefois ces réponses sont issues de la compilation d’un traitement des différentes données extraites à partir des divers SGBD délocalisés. Ainsi, on est capable de fournir aux utilisateurs des informations, certes issues des bases de données de l’entreprise, mais aussi des informations provenant de l’extraction de bases de données externes d’une façon complètement transparente pour l’utilisateur final. L’exemple le plus marquant, c’est le pouvoir de faire du benchmark en temps réel pour nos prises de décision ou d’obtenir des informations complètement en dehors des activités principales même de son entreprise !

Contextes techniques pour les missions d’audit

41

Pour illustrer la complexité technique, nous donnons l’exemple de l’évolution d’un centre d’informatique dans un centre de recherche. En l’espace d’une quinzaine d’années, il est passé d’un centre de type de mainframe à un centre de serveurs correspondant à deux types de technologie complètement différents. Vers les années 1990, ce centre était équipé d’un mainframe IBM de type S390. De 1996, exactement mi 96, à l’année 1998, on a migré les applications vers les serveurs de type mono et biprocesseurs avec des systèmes UNIX. La grosse machine (et ses systèmes d’applications propriétaires) fut démantelée en 1999. Du point de vue de la sauvegarde des données, on était passé des disques durs IBM au système des disques RAID avec un robot de sauvegarde. Actuellement, les serveurs sont de plusieurs types : la majorité sont des quatri-processeurs dont la moitié tourne sous Unix, l’autre sous Linux. Le nombre total des serveurs et stations Unix et Linux s’élève à 156 unités. Il s’agit de processeurs au format slides s’encastrant dans des racks. Du point de vue réseau : le centre a vu évolué ses installations des systèmes de type Token Ring avec Ethernet vers un système de backbone (cœur de réseaux) d’un giga, en passant par le réseau ATM (Asynchronous Transfert Mode) associé à Ethernet. L’ensemble du réseau interne est connecté aux autres centres par des liaisons spécialisées (6 méga). Concernant les applications, on peut citer les suivantes : les applications de type scientifiques et techniques, les bases de données (Oracle, mySQL, SQL Server) et les applications bureautiques utilisant directement des logiciels « Office » du marché avec de nombreux développements associés (développés avec les utilitaires et macros). Le nombre total de serveurs PC Windows est de quarante. Du côté matériel ou hardware, des constructeurs SUN, IBM ont aussi miniaturisé leurs composants et cartes, et, actuellement, il est en vogue d’avoir des lames (UC, d’interfaces…) installées dans des racks pré-câblés formant ainsi des systèmes bladecenters.

42

L’audit technique informatique

D’autre part, il importe que les auditeurs appréhendent aussi les structures et les fonctionnements des infocentres qui connaissent un certain renouveau ces dernières années. Par exemple, parmi les centres d’information, un des plus connus en France est celui du CNRS placé sous la gestion de la direction des systèmes d’information mise en place en avril 1999. Il facilite l’accès des données issues des applications nationales, ainsi que les résultats de leurs analyses. L’accès à cet infocentre est réservé : – aux directions du Secrétariat général ; – aux services des délégations régionales ; – aux départements scientifiques ; – à la direction des études et des programmes ; – aux directions fonctionnelles ; – aux chercheurs et au personnel des laboratoires. En dehors des possibilités de requêtes et de consultation, il permet l’importation et l’exportation des diverses données, par exemple : – l’import journalier de données Labintel (qui se définit comme l’outil d’information sur les activités de recherche et de service des laboratoires et les moyens mis en œuvre), des données concernant les formations, les protocoles… – l’import hebdomadaire de données Brevet, des Notifications et des budgets ; – l’export hebdomadaire des données relatives aux ressources financières CNRS vers Labintel. Enfin, leur environnement technique se compose : – d’interfaces Web pour les postes de travail ; – des modules SAS - Serveur Unix Sun E450 - Système de sécurité SSL (Secure Socket level) ; – de l’outil de mesure d’audience Analog (outil statistique pour les accès et les transactions).

Contextes techniques pour les missions d’audit

43

Actuellement, la notion d’infocentre semble être banalisée, mais, néanmoins, il faut maîtriser ses spécificités pour pourvoir exercer des audits. Quelque soit les structures infocentre ou centres de croissent considérablement avec les opérateurs de chez les FAI – fournisseurs d’accès Internet) pour vérification d’authentification, on trouve souvent par ordinateurs de type SUN avec le système Radius.

serveurs (qui Télécom et l’accès et la exemple des

RADIUS (Remote Authentication Dial-In User Service) est un des systèmes le plus utilisé par les FAI ou les IPS (Internet Service Providers). RADIUS, à chaque connexion d’un utilisateur, vérifie son nom d’utilisateur et son mot de passe avant de passer la main aux systèmes internes de l’IPS. La maintenance et l’évolution des spécifications de RADIUS sont faites par un groupe de travail IETF. En fait, ce dernier est l’acronyme de Internet Engineering Task Force. C’est le principal organisme pour les normes relatives à Internet. Il est composé des opérateurs, des concepteurs, des chercheurs et vendeurs soucieux de l’évolution des architectures, des transactions, de l’utilisation et des opérations sur Internet. De ce fait, par rapport à leurs aînés, les auditeurs en informatique, de nos jours, devraient s’informer et se former d’avantage sur ces types de systèmes et sur les principes et concepts des réseaux. Concernant les missions sur la cohérence, l’intégrité et la fiabilité des données, il importe de connaître les systèmes et architectures des outils de gestion des données cités précédemment. En résumé En tant qu’outil et matériel, un système « infocentre » ainsi que les centres de serveurs offrent des services très différents aux utilisateurs, mais en contrepartie, leur technicité inhérente est de plus en plus complexe. Il est à noter que souvent avec ces centres, on sous-traite l’exploitation et la maintenance : d’où la notion d’infogérance. De ce

44

L’audit technique informatique

fait, auditer ces centres exige une compétence diversifié englobant la connaissance de : – de ces types d’architecture et systèmes cités ; – des principes des traitements coopératifs ; – des principes des architectures client/serveur ; – des différents types d’interfaces ; – des divers types de langages de requêtes ; – des outils de développement (pour les informaticiens) ; – des méthodes et moyens de sous-traitance. D’autre part, il importe de remarquer que, souvent, la notion d’infocentre se couple avec celle d’infogérance. En effet, bon nombre d’entreprises prennent l’option out sourcing, cela pour diverses raisons : manque de compétence interne, manque de ressources techniques, recentrage sur les tâches du métier, économie du budget informatique… Dans ce cas de figure, par expérience, nous observons une croissance de demandes des missions d’audit de la politique informatique par les directions générales. Dès lors, les documents ou procédures tels que cahiers des charges, procédures d’appels d’offres, les tableaux de bord concernant la qualité des services, des systèmes, seront les documents clés pour un auditeur informatique. Enfin, ces quelques conseils généraux suivants peuvent être utiles pour un auditeur interne amené à effectuer une mission d’audit informatique dans une structure infocentre ou un centre de serveurs soumis à gestion externe. Conseils : – distinguer et apprécier les procédures de travail et l’organisation ; – juger et apprécier les normes de sécurité spécifiques de chaque contexte (les protections, les sauvegardes...) du côté infocentre ;

Contextes techniques pour les missions d’audit

45

– évaluer l’évolution des outils de traitement d’information (existe-t-il un planning, un schéma directeur ?) ; – distinguer, juger et apprécier la politique de maintenance du matériel et des applications aussi bien du côté client, que du côté serveur. Un exemple d’audit de ce type de centre ou BIC sera développé au chapitre 5. Passons maintenant en revue les cycles de vie que l’auditeur devrait appréhender pour ses missions d’audit informatique. 2.2. Les cycles de vie et les systèmes Un système informatique ou un système logiciel (appelé souvent par le nom « produit logiciel ») ne peuvent se concevoir sans la notion de projet. Ce dernier pourrait être considéré sous deux angles : – le produit objet du projet, identifié par le système cible avec sa documentation finale ; – le cycle de vie, matérialisé par des étapes successives et les « délivrables » associés conduisant vers le système final. Quelle que soit la méthode choisie, toute conception d’un système est caractérisée principalement par trois cycles : – le cycle de vie du système ; – le cycle de la décision ; – le cycle d’abstraction. Le cycle de vie du système est composé de la manière suivante : – génèse ; – naissance ; – croissance ; – maturité ; – obsolescence ; – mort du système.

46

L’audit technique informatique

Cette dernière est caractérisée d’abord par l’obsolescence (résultats fournis insuffisants) puis par la non-utilisation du système par l’utilisateur. Le cycle de décision est celui où l’on rend compte de l’ensemble des choix durant le cycle de vie. Le cycle d’abstraction est celui où l’on découpe par niveau d’information pour isoler les éléments significatifs.

Analyse de l’existant Dans tout le processus d’un projet informatique, la phase la plus importante est sans conteste celle de l’analyse de l’existant (appelée aussi étude préalable). Il s’agit d’une phase primordiale où une erreur peut enclencher des écarts financiers importants et des pertes de temps considérables (phase où un auditeur informatique peut être sollicité et fournir des critiques constructives, cette phase n’est pas seulement réservée à un nouveau projet), mais elle peut être aussi déclenchée et utilisée lors de la réorganisation d’une nouvelle structure ou lors de la constitution d’un nouveau service. Concernant l’automatisation en général, on peut distinguer des projets d’informatisation (mise en œuvre d’un nouveau système d’informatique, de matériel, de logiciel, ajout de modules spécifiques, des nouvelles fonctionnalités…) et des projets de développement d’un produit logiciel proprement dit. Quoique différentes dans la pratique, ces étapes ont pratiquement les mêmes principes et démarches. Nous présentons d’abord les étapes classiques de l’informatisation avant de passer en revue celles d’un projet de développement logiciel (le produit logiciel) avec les documents et les contrôles de qualités associés.

Contextes techniques pour les missions d’audit

47

Ces derniers pourraient être faits par les auditeurs en informatique mandatés par la Direction générale ou la Direction de l’informatique. Le schéma suivant permet de décrire sommairement toutes les étapes d’un projet d’informatisation et de situer l’analyse de l’existant. Etude préalable → analyse de l’existant PHASE DE CONCEPTION

PHASE DE REALISATION

Etude de conception → choix d’une solution stratégique (Analyse de conception)* Etude fonctionnelle → définition du nouveau système Etude technique → détail technique du système/des options Mise en œuvre du système → choix & mise en œuvre du système Expérimentation → contrôle de qualité du système Exploitation → utilisation du système Maintenance → actualisation, mise à jour, entretien (*) Cette phase est appelée aussi l’étude d’opportunité par certains auteurs ou concepteurs.

Tableau 2.1. Les étapes classiques de l’informatisation

Pour la phase d’analyse de l’existant, l’ordre chronologique des différents stades est : – choix ou définition, diagnostic ; – analyse circuit et critique constructive. Ces sous-étapes (ou stades) cruciales de l’analyse de l’existant seront reprises ultérieurement (voir tableau 2.2 page 49). Le point de départ de ces étapes classiques de l’informatisation provient des besoins et demandes des utilisateurs ; les principaux participants sont les utilisateurs, les organisateurs, les analystes concepteurs. Le produit final de cette phase est le rapport « cible » ou le rapport des objectifs globaux. Ce document sera soumis à l’approbation des divers responsables. Il propose des améliorations possibles quant aux

48

L’audit technique informatique

méthodes de travail, l’estimation des ressources à mettre en œuvre et les limites du projet. Dans cette partie, on définit aussi la compatibilité du projet avec les autres applications et procédures existantes de l’entreprise. A l’instar des étapes précédentes, nous détaillons ici les étapes du cycle de vie correspondantes pour un produit logiciel avec les principaux documents associés. Il est important d’avoir des contrôles qualité à chaque étape, mais néanmoins un auditeur pourrait être amené à y participer. Le détail du tableau 2.2 montre la correspondance entre les diverses étapes et les principaux documents. Le tableau 2.3 permet d’appréhender et de synthétiser les divers éléments correspondants aux étapes cruciales de l’analyse de l’existant, ainsi que des problématiques intéressantes pour les auditeurs. En effet, ces derniers pourraient être amenés à diagnostiquer un système, à analyser les circuits, à apporter des critiques constructives aux décideurs et voire même à les aider dans leur choix. En résumé, la Direction générale ou la Direction informatique peut souhaiter l’intervention d’un auditeur informatique lors de la phase de diagnostic et de critique constructive. En effet avec un « œil neuf », non-impliqué dans la phase d’analyse, faite par l’analyste-concepteur, l’auditeur peut apporter des idées intéressantes sur le rapport élaboré en fin de phase critique (exemple : un tel a fait cela, est-ce sa responsabilité ou est-il le plus apte à le faire ?). D’autre part, pour la phase de diagnostic par exemple, compte tenu de son expérience concernant l’analyse des outils de gestion, des tableaux de bord, des mesures d’indicateur d’activité... l’auditeur peut être un collaborateur contribuant à faire gagner du temps et apporter une aide précieuse et certaine dans la compréhension et l’analyse des divers documents. Ce cas particulier d’aide ou de soutien constitue un audit de diagnostic et de conseil, cas très limité dans une démarche d’audit classique, mais plus fréquent avec l’approche des audits de régularité. Néanmoins ceci démontre le souci de la Direction ou des décideurs d’utiliser les compétences et les expériences d’un auditeur, même dans la phase en amont du projet.

Contextes techniques pour les missions d’audit Etape du cycle de vie Préliminaire

Principaux documents

Cahier des charges

Contrôle Qualité

Revue de ces documents

Appel d’offres Contrat Planification

Document de lancement du projet

Revue de planification

Plan d’assurance qualité Plan de développement Spécification

Dossier de définition des besoins

Revue de spécification

Les exigences d’interface Dossier de tests de validation Conception générale

Dossier de conception générale

Conception détaillée

Dossier de conception détaillée

Codage

Listing ou fichier des programmes

Dossier des tests d’intégration Dossier des tests unitaires

Documentation programme

Tests unitaires

Dossier des tests unitaires

Revue de conception générale Revue de conception détaillée Revue de code Remarque : la vérification pourrait se faire d’une façon automatique avec des logiciels (logiscope par exemple) Revue de tests unitaires

Bilan des tests unitaires Intégration

Dossier de ces tests

Revue d’intégration

Bilan des tests d’intégration Dossiers d’installation et d’exploitation. Recette

Dossier des tests de la validation

Revue de la recette (PV)

Bilan de la recette. Installation/ Diffusion

Cahier d’installation

Exploitation et Maintenance

Dossier de maintenance.

Revue d’installation

Tableau 2.2. Correspondance entre les diverses étapes et les principaux documents

49

50

L’audit technique informatique

Stades

Buts

Problématique, moyens ou outils

Définition du problème, objectifs à atteindre.

Choix ou définition

Problématique à partir des résultats Bilan soulignant des contreperformances, rapport d’un audit externe… Document interne de la DG précisant la nouvelle stratégie, les nouveaux objectifs de la société.

Situer le problème ; réunir les informations ; dresser les points forts et les points faibles.

Organigramme de fonction et structure, indicateurs, mesures d’activité et d’effectifs ; courbe ABC ; procédure de travail, schéma synoptique et circuit (feuilles de circulation, organigramme ou schéma synthétique des fonctions, des services…).

Analyse circuit

Décomposition du problème en éléments modulaires. Examen pour chaque module du contenu de ses documents et de leur circulation.

Divers documents ; imprimés et états existants, tableaux de bord, liste des nouvelles contraintes, conclusion du diagnostic.

Critiques constructives

Examen en vue d’améliorer les circuits, les documents et procédures en fonction des nouveaux objectifs.

Liste des points faibles, méthode QQOPQC : se poser toujours les questions suivant la phrase : qui fait quoi, où, pourquoi, quand et comment.

Diagnostic

Tableau 2.3. Correspondance entre les objectifs des stades et les problématiques, moyens ou outils

En résumé, la Direction générale ou la Direction informatique peut souhaiter l’intervention d’un auditeur informatique lors de la phase de diagnostic et de critique constructive. En effet avec un « œil neuf », non-impliqué dans la phase d’analyse, faite par l’analyste-concepteur, l’auditeur peut apporter des idées intéressantes sur le rapport élaboré en fin de phase critique (exemple : un tel a fait cela, est-ce sa responsabilité ou est-il le plus apte à le faire ?).

Contextes techniques pour les missions d’audit

51

D’autre part, pour la phase de diagnostic par exemple, compte tenu de son expérience concernant l’analyse des outils de gestion, des tableaux de bord, des mesures d’indicateur d’activité... l’auditeur peut être un collaborateur contribuant à faire gagner du temps et apporter une aide précieuse et certaine dans la compréhension et l’analyse des divers documents. Ce cas particulier d’aide ou de soutien constitue un audit de diagnostic et de conseil, cas très limité dans une démarche d’audit classique, mais plus fréquent avec l’approche des audits de régularité. Néanmoins ceci démontre le souci de la Direction ou des décideurs d’utiliser les compétences et les expériences d’un auditeur, même dans la phase en amont du projet. 2.3. Les référentiels relatifs aux logiciels de qualité Dans le contexte de l’ingénierie informatique, c’est-à-dire l’étude globale d’un projet informatique, il existe bon nombre de documents, guides, voire références, afin de bien concevoir, développer et mettre en œuvre la solution. L’objectif, c’est d’atteindre une certaine qualité vérifiable et une traçabilité fiable. C’est pourquoi on parle souvent de « référentiel pour la qualité logiciel » ou simplement « référentiel qualité logiciel ». Que ce soit en amont ou en aval de l’ensemble du processus, un auditeur pourrait se voir demander d’auditer une phase particulière ou l’ensemble du processus, ou simplement la qualité du produit logiciel. De ce fait, il importe de bien connaître les référentiels servant de documents de base de départ pour ces missions informatiques. Nous nous bornons à présenter quelques uns d’entre eux, car l’ensemble des normes existantes relatives aux qualités d’un logiciel ne saurait contenir dans un livre… Nous en développerons certains afin de fournir des repères et un référentiel pour nos lecteurs et/ou auditeurs amenés à exercer ces missions de vérification de la qualité des logiciels : – la norme ISO/SPICE 15504 relative à « l’évaluation des processus logiciels » ;

52

L’audit technique informatique

– la norme ISO/IEC 12207 concernant « le processus du cycle de vie d’un logiciel » ; – la norme 9126 relative à l’évaluation des logiciels. Il existe deux façons d’aborder l’évaluation d’un produit : le principe de la « boîte noire » et celui de la « boîte blanche ». Le premier principe consiste à vérifier la bonne démarche de la conception à la réalisation et/ou à la mise en œuvre du produit ou service. C’est l’approche par processus, où l’on se soucie des processus et non du produit en soi. L’application des versions antérieures de la série des normes ISO 9000 est adéquate à cette démarche. Cependant, compte tenu de la complexité croissante des logiciels et surtout ceux conçus pour les domaines de la sécurité et de la sûreté, cette démarche est insuffisante, voire dangereuse. En effet, elle est incomplète, car on n’a pas « ouvert le capot » afin de regarder de près les codes et y détecter les dysfonctionnements ! Une revue renforcée des codes et le passage à un produit d’analyse de la complexité des lignes des programmes caractérisent l’approche de type boîte blanche. L’omission de cette dernière est un potentiel de risques. Ainsi, on a vu certaines entreprises de développement de services informatiques déposer le bilan quelques années après l’obtention de leur certificat ISO 9001. La démarche de la boîte blanche est donc indispensable pour les logiciels complexes et critiques, en complément de la première approche. De ce fait, il existe beaucoup de documents ou normes qui peuvent se classifier en fonction de l’approche choisie. Nous détaillons ci-après les normes citées précédemment ainsi que leurs contextes d’application. 2.3.1. La norme ISO/SPICE 15504 Cette norme pour l’évaluation des processus logiciels, est constituée par un ensemble de documents publiés par l’AFNOR au dernier trimestre de l’année 1998. C’était à l’époque une norme expérimentale composée de neuf rapports techniques avec un fascicule de documentation d’introduction. Son cadre de référence est dédié aux

Contextes techniques pour les missions d’audit

53

processus identifiant les sociétés possédant des processus « répétables » et « traçables » afin de pouvoir appliquer le principe de capitalisation et de réutilisation. Cette norme a bénéficié des apports des autres concepts et documents provenant des secteurs des télécommunications et de l’industrie des logiciels avec les concepts CMM (Capacity Maturity Model) et de Bootstrap (issu d’un projet européen pour évaluer et améliorer les processus logiciels)… A noter que le CMM est développé par le SEI (Software Engineering Institute de Pittsburgh) sous l’impulsion de la DoD (Department of Defense des Etats-Unis) pour la sélection des fournisseurs. De ce fait, ce modèle englobe aussi une dimension d’aptitude pour la réalisation des évaluations. Ainsi héritant de CMM, SPICE introduit les six niveaux d’évaluation (notés de 0 à 5) suivants : – niveau 0 : processus incomplet. Le processus n’est pas réalisé ou appliqué ; – niveau 1 : le processus est réalisé. Il a qualifié ses objectifs ; – niveau 2 : le processus est bien géré. Toutes les activités planifiées sont faites et toutes les exigences des produits sont identifiées et identifiables ; – niveau 3 : le processus est vraiment établi. La mise en œuvre s’appuie sur des pratiques standardisées ou normalisées. Autrementdit, il pourrait avoir des procédures claires et vérifiables ; – niveau 4 : le processus est prévisible. Les variations ou écarts d’un processus sont mesurés et compris ; les mesures récoltées sont utilisées pour piloter et contrôler le déroulement du processus ; – niveau 5 : le concept d’optimisation du processus est identifié ; l’organisation est capable d’améliorer ses processus et les adapter de façon proactive afin de satisfaire l’évolution des exigences et de s’y adapter. Ainsi, avec cette dimension d’aptitude, les entreprises pourraient demander la certification SPICE via les entreprises accréditées pour ces tâches.

54

L’audit technique informatique

En ce qui concerne la norme même, voici les différents documents qui la composent : – 0 : introduction au référentiel et à son utilisation ; – 1 : concept et guide d’introduction ; – 2 : modèle de références pour les processus ; – 3 : réalisation d’une évaluation ; – 4 : guide pour la réalisation d’une évaluation ; – 5 : modèle d’évaluation et guide des indicateurs ; – 6 : guide de compétence des évaluateurs ; – 7 : guide pour l’amélioration des processus ; – 8 : guide pour la détermination d’aptitude de processus ; – 9 : vocabulaire (utilisé dans le document). Application de la norme en matière d’audit informatique Cette norme ISO/IEC 15504 pourrait être utilisée par les auditeurs amenés à exercer plutôt des audits sur les processus de développement des logiciels. A titre d’exemple, cette norme pourrait être utilisée comme référentiel pour auditer un service de développement et identifier ainsi la progression en matière de qualité, niveau par niveau. Elle pourrait être utilisée comme audit interne pou la préparation de la certification de type SPICE. De ce fait, l’auditeur pourrait jouer le rôle d’audit à blanc pour la préparation à l’examen final par les auditeurs externes accrédités à la méthodologie et aux concepts SPICE. 2.3.2. La norme ISO/IEC 12207 Le développement des projets informatiques est souvent fastidieux et rempli d’écueils, sans compter le dérapage fréquent du temps et des budgets alloués. Il importe donc de structurer et d’harmoniser les différents processus. L’ISO a développé à cet effet la norme ISO/IEC 12207 concernant le « processus du cycle de vie d’un logiciel ». Cette norme décrit et préconise les processus mis en œuvre dans les projets informatiques. Les activités de mise en œuvre, les responsabilités des divers acteurs ou intervenants ainsi que la politique qualité associée sont déployées.

Contextes techniques pour les missions d’audit

55

Voici le plan de la norme, qui est décomposé en sept articles distincts et complémentaires : – article 1 : domaine d’application ; – article 2 : références normatives (les autres documents en liaison avec la norme) ; – article 3 : définitions (des termes utilisés dans le document) ; – article 4 : application de la norme internationale ; – article 5 : les processus de base. Cette section décrit les activités liées au développement (conception, réalisation), à l’exploitation et à la maintenance du logiciel, à savoir le processus d’acquisition, le processus de fourniture, celui de développement, celui d’exploitation et enfin le processus de maintenance ; – article 6 : les processus de support. Cette section décrit tous les processus qui peuvent être regroupés dans un contexte de support. Ils sont au nombre de huit : - le processus de documentation ; - le processus de gestion de configuration ; - le processus d’assurance de la qualité ; - le processus de vérification ; - le processus de validation ; - le processus de revue ; - le processus d’audit ; - le processus de résolution de problèmes. Cette norme rappelle la norme ISO 9000-3 qui met en exergue les processus de la documentation, celui des revues et les actions correctives. En effet, l’ISO 9000-3 est une norme de la série 9000 taillée sur mesure et adaptée pour le logiciel, concernant les spécificités de conception, de réalisation, de livraison et de maintenance des produits logiciels dans l’industrie informatique. Ellemême est composée des six articles suivants : – article 1 domaine d’application ; – article 2 : références normatives ; – article 3 : définitions ; – article 4 : système qualité-cadre ;

56

L’audit technique informatique

– article 5 : système qualité-activités du cycle de vie ; – article 6 : système qualité-activité de soutien. Application de la norme en matière d’audit informatique A l’instar de la norme qualité ISO 9000-3, la norme ISO/IEC 12297 pourrait être utilisée par les auditeurs amenés à exercer des audits sur les processus de développement des logiciels plutôt en termes de contrôle de « boîte noire ». A titre d’exemple, cette norme pourrait être utilisée comme référentiel pour la vérification de la documentation, de la validation ou sur l’audit des services de hot line (processus de résolution de problèmes des clients ou des utilisateurs). 2.3.3. La norme 9126 relative à l’évaluation des logiciels Vis-à-vis des deux normes précédemment citées, la norme 9126 relative à « l’évaluation des produits logiciels » et ayant comme soustitre : « Caractéristiques de qualité et directives d’utilisations » est plus focalisée sur une vérification de type « boîte blanche » car elle n’est pas déterminée par une approche processus. Par définition, une caractéristique qualité (il en existe sept en tout dans ce document) est une qualité intrinsèque provenant d’une exigence. Néanmoins, il faut souligner l’existence et/ou la difficulté de déterminer ou d’avoir des valeurs, des métriques, c’est-à-dire des éléments facilement chiffrables et mesurables (qui représentent les sous-caractéristiques) préconisés pour la vérification. Cette norme est relativement « mince » par rapport aux autres, car elle laisse la liberté totale aux utilisateurs pour le développement de leurs métriques. Beaucoup de critiques ont été formulées à l’encontre de cette liberté qui pourrait amener au foisonnement des métriques non homogènes et non comparables (pour un benchmark par exemple) entre divers acteurs de même niveau. Pour palier ces critiques, il est à noter que les experts ISO travaillent actuellement à une révision complète de cette norme dont le plan est le suivant :

Contextes techniques pour les missions d’audit

57

– 9126 - 1 : modèle qualité ; – 9126 - 2 : métriques externes ; – 9126 - 3 : métriques internes ; – 9126 - 4 : qualité en matière d’utilisation. La nouveauté de cette révision consiste à prendre en compte les cycles de vie du logiciel (de son dynamisme). Ainsi, chaque acteur pourrait identifier et fixer ses métriques en fonction de ses niveaux et activités. Cette clarification détermine les différentes perspectives de chaque acteur dans la chaîne et leurs métriques qui peuvent être différentes : – perspective d’un responsable qualité ; – perspective d’un acheteur ; – perspective d’un développeur ; – perspective d’un mainteneur. Malheureusement, la révision est toujours en cours et seule la première partie est terminée. La norme 9126 actuelle pourrait être utilisée par les auditeurs amenés à vérifier la réalisation d’un logiciel. Sous réserve d’une bonne définition d’un ensemble de métriques au préalable, les auditeurs pourraient l’utiliser comme référentiel et outil de type « boîte blanche ». En effet, les métriques seront bâties en fonction des souscaractéristiques et l’ensemble des sous-caractéristiques détermine les caractéristiques. La norme préconise une revue possible des six principales caractéristiques suivantes : – la capacité fonctionnelle, caractérisée par l’aptitude, l’exactitude, l’interopérabilité, la sécurité et la conformité réglementaire ; – la fiabilité, définie par la maturité, la tolérance aux fautes et la possibilité de récupération ; – la facilité d’utilisation, caractérisée par les compréhension, d’apprentissage et d’exploitation ;

facilités

de

– le rendement, défini par le comportement du produit vis-à-vis du temps, et vis-à-vis des ressources ;

58

L’audit technique informatique

– la maintenabilité déterminée par les facilités d’analyse, de modification, de tests et la stabilité du produit ; – la portabilité, caractérisée par la facilité d’adaptation, la facilité d’installation la conformité aux règles de portabilité et l’interchangeabilité. La norme, en soi, est composée des cinq articles suivants : – article 1 : domaine d’application ; – article 2 : références normatives ; – article 3 : définitions ; – article 4 : caractéristiques de qualité du logiciel. C’est la définition des sept caractéristiques précédentes et des sous caractéristiques associées ; – article 5 : recommandations pour l’emploi des caractéristiques de qualité concernant les trois visions des acteurs : - vue des utilisateurs ; - vue des réalisateurs ; - vue du maître d’ouvrage. Application de la norme en matière d’audit informatique En résumé, cette norme en l’état actuel est applicable pour exécuter un audit plus technique de type « boîte blanche », à condition que les métriques aient été définies au préalable par les concepteurs et les réalisateurs du logiciel. En aucun cas, il n’est du devoir de l’auditeur d’établir les métriques lors de sa mission d’audit. Les auditeurs ne peuvent que conseiller d’en établir s’il s’avère que les métriques n’existent pas encore dans le service audité, ou encore démontrer la pertinence d’une ou de plusieurs métriques. Enfin, nous ne la développons pas en détail mais signalons juste qu’il existe aussi la norme 14598,en anglais, qui pourrait intéresser les évaluateurs et auditeurs en particulier sur les parties 5 et 6 suivantes : – ISO/IEC 14598-5:1998 Software product evaluation - Part 5 : Process for evaluators ; – ISO/IEC 14598-6:2001 Software engineering - Product evaluation Part 6 : Documentation of evaluation modules.

Contextes techniques pour les missions d’audit

59

2.4. Classification générique des types d’audit Après la présentation des contextes techniques et de quelques référentiels, il nous importe d’introduire les typologies d’audit informatique avant de détailler, les diverses phases de l’audit, les spécificités et les rôles que les auditeurs pourront être amenés à jouer.

Les typologies d’audit informatique Dans la pratique, on peut distinguer trois types d’audits classés en rapport avec le degré de finalité, d’importance et de difficulté : a) audit de diagnostic : l’auditeur est appelé à porter un jugement, sur des objectifs ou nouveaux projets et parfois même au niveau de la politique informatique, du schéma directeur existant (il faut distinguer les schémas directeurs concernant la politique du matériel, d’un domaine ou d’informatique) ou sur un « système » existant qui fonctionne mal, dans ce cas des analyses des contre-performances et recommandations sont souhaitées et attendues de la part des auditeurs ; b) audit de régularité (conformité) : à l’instar des vérifications des documents comptables et de la régularité des opérations, en audit informatique, on est amené à vérifier que telle ou telle procédure (ou réglementation) est appliquée, que les transactions informatiques sont régulières ou que les données intégrées dans les ordinateurs sont réelles et cohérentes ; c) audit d’efficacité : l’expérience d’audit et les connaissances techniques informatiques d’une équipe d’audits sont les conditions nécessaires pour ces missions. Une analyse approfondie des méthodes et moyens est nécessaire afin de porter un jugement, étayé sur l’adéquation du fameux couple « objectifs/moyens » (c’est une sorte de contrat de service que le responsable d’un service reçoit de la part de sa hiérarchie, composant l’ensemble de moyens et de ressources pour accomplir ses missions annuelles) avec les objectifs poursuivis en matière de traitement de l’information. Un autre moyen de classement des audits informatiques repose sur la distinction par degrés de difficultés croissants :

60

L’audit technique informatique

– l’audit en milieu informatisé ou d’un environnement informatique ; – l’audit de sécurité d’une façon globale ou d’une application (voir l’exemple de la section 3.3) ; – l’audit informatique système (système autonome ou en réseau). Historiquement, les missions concernant l’audit en milieu informatisé étaient faites par les auditeurs internes ou externes non-spécialistes en informatique. Ce sont les missions que l’on qualifie souvent de missions « autour de l’ordinateur » dans la suite logique des révisions comptables. En effet, en 1975, le Conseil supérieur de l’ordre des experts-comptables et des comptables agréés a fixé les principes fondamentaux pour la « Révision des comptabilités traitées par des moyens informatiques » dans la recommandation de révision numéro 7. Par la suite, ce Conseil a émis un document concernant « la révision dans un environnement informatique », comme déjà signalé précédemment... Par degrés de difficultés, viennent ensuite les missions de type « sécurité » de l’environnement informatique et la sécurité des applications (voir le développement dans le chapitre 6). Enfin, les derniers types de missions nécessitent des spécialistes et des compétences en réseau, du ou des systèmes (ordinateurs, système d’exploitation...) audités. De ce fait un appel aux concours extérieurs est souvent nécessaire quand le champ d’intervention demande des connaissances techniques, spécifiques à un système. De ces précédentes remarques, nous tirons les recommandations suivantes : – l’audit d’efficacité sur les systèmes ou réseaux ne peut être fait que dans l’équipe des spécialistes informatiques (ou avec la collaboration d’un expert externe), autrement, sans concours d’un spécialiste, la mission sera très probablement vouée à l’échec ou à un succès limité. En effet, les recommandations émises par des auditeurs ne peuvent être vagues ou générales face aux spécialistes pointus que sont les analystes, les ingénieurs système ou l’ingénieur réseau d’un service informatique ;

Contextes techniques pour les missions d’audit

61

– les deux premiers types d’audit, par contre, peuvent être effectués par un service d’audit d’une entreprise qui aborde les missions informatiques, ou par un service qui possède une équipe en début d’initiation aux techniques de l’informatique. Résumé du chapitre 2 L’auditeur, qui effectue une mission d’audit informatique, doit posséder une solide formation de gestion et des techniques informatiques. Ce chapitre identifie les éléments de background Ainsi la connaissance du contexte technique actuel, du cycle de vie et des normes relatives à la qualité des logiciels et de leur contexte d’utilisation est nécessaire pour un auditeur, aussi bien pour effectuer des missions d’audit dite de type « boîte noire » que pour des missions de type « boîte blanche ». Il est à remarquer qu’il existe encore d’autres normes pour la qualité du logiciel, mais celles développées dans ce chapitre forment un ensemble minimal de référentiels et d’outils de base de travail pour effectuer des audits informatiques. Enfin, ce chapitre se clôture par la présentation de trois types d’audits classés en rapport avec leur degré de finalité, d’importance et de difficulté, à savoir : l’audit de diagnostic, l’audit de régularité et celui d’efficacité, versus un autre type de classement possible : l’audit fonctionnel et l’audit dit de type opérationnel...

FOIRE AUX QUESTIONS (CHAPITRE 2)

Question 1 : relative à l’audit informatique fonctionnel et à l’audit opérationnel. On classe souvent l’audit informatique en deux catégories : pouvez-vous donner des exemples de chaque catégorie ? Réponse : Audit informatique fonctionnel : les quatre audits suivants peuvent être considérés comme des audits fonctionnels : – audit des études (lors de l’élaboration des cahiers des charges par exemple) ; – audit de la production du service informatique ; – audit de la politique informatique, de la planification des moyens de mise en œuvre ; – audit financier de la fonction informatique, concernant le processus d’investissement. Audit informatique opérationnel : – audit des moyens de traitement et des ressources techniques (logique et physique) ; – audit d’une application (ou de son environnement, de sa décision d’implantation, de la maintenance, de la restitution des états...) ; – audit de la circulation des documents (ou de l’information) et de la documentation ; – audit de la sécurité générale liée à l’informatique.

64

L’audit technique informatique

Question 2 : dans le chapitre précédent, on a aussi effectué un classement par typologie (audit de diagnostic, audit de régularité et audit d’efficacité). Ce classement est-il compatible avec le classement audit fonctionnel/opérationnel ? Réponse : non, il n’existe pas de contradiction. En effet, d’une part, c’est un problème d’angle de vue et d’autre part, il peut exister une combinaison possible, c’est-à-dire que les deux types de classement peuvent être associés. Par exemple, concernant un audit fonctionnel de la production du service informatique, on peut être amené à vérifier que telle ou telle procédure (ou réglementation) est appliquée. Question 3 : la connaissance du cycle de vie est-elle nécessaire pour mener un audit ? Réponse : cette connaissance est primordiale pour auditer un projet et surtout pour examiner la qualité du projet à une phase donnée. Afin d’éviter les déboires, les dépassements des coûts et les écarts (du point de vue fonctionnalité), la Direction générale ou la Direction informatique commande de plus en plus ce genre de missions. En effet, cette stratégie permet souvent d’aboutir à une bonne conception, en adéquation avec les besoins des utilisateurs et le souhait de la Direction. Question 4 : les contextes techniques changent très rapidement. Les auditeurs informatiques doivent-ils connaître et maîtriser coûte que coûte ces évolutions ? Réponse : oui et non. Bien évidemment, il serait souhaitable que l’auditeur maîtrise ces contextes, d’où l’importance du composant « formation » des auditeurs. Néanmoins, en cas de besoin, l’auditeur interne pourrait faire appel à une assistance technique externe pour mener à bien sa mission. Question 5 : en ce qui concerne les référentiels, a-t-on besoin de les connaître pour auditer un logiciel ?

Foire aux questions

65

Réponse : absolument, les référentiels sont des documents de travail importants pour les auditeurs. Comme leur nom l’indique, ils constituent le ou les référentiels auxquels on se réfère pour constater les points forts et le poins faibles. Ce sont en quelque sorte des données en entrée (inputs) obligatoires à prendre en compte par les auditeurs. Question 6 : concernant la matrice ou le tableau 2.2 (de 3 colonnes et 5 lignes, détaillant la correspondance entre les objectifs des stades et les problématiques et moyens), quelles sont les responsabilités des auditeurs et le degré de difficulté des stades ? Réponse : souvent les auditeurs sont sollicités par la Direction qui apprécie leurs compétences, leur discernement et leur « œil neuf » sur les projets ou services. D’autre part, les fonctions des auditeurs qui ne se bornent plus à la vérification, au contrôle ou à l’audit mais s’étendent aussi au domaine du conseil. Leurs responsabilités de « conseillers » s’imposent et se développent de plus en plus. Chaque stade possède une difficulté équivalente, néanmoins le plus délicat pour un auditeur interne est de conseiller le choix et la définition d’une nouvelle stratégie, surtout lorsqu’un rapport négatif a été fourni après l’exécution un audit externe. « Bien analyser le rapport, les points faibles et apporter des solutions nouvelles » seront sans conteste des plus values d’un auditeur et/ou d’un conseiller interne. Question 7 : peut-on avoir un exemple de cohabitation et d’utilisation de deux normes dans un service informatique ? Réponse : oui, la cohabitation de deux normes (de type qualité logiciel) est une possibilité. Par exemple, la norme 9126 peut être pratiquée avec la série d’ISO 9000 (voir la procédure développée dans le chapitre 7). L’application de la norme 9126 est utilisée comme un outil référentiel pour une vérification « de boîte blanche » (analogue à l’ouverture d’un capot pour le contrôle technique) par un laboratoire de tests, tandis que les normes de qualité « classiques » sont utilisées comme référentiel (plutôt pour la vérification de type « boîte noire »).

66

L’audit technique informatique

Dans ce cas, l’utilisation de ces deux normes permet d’éviter un risque potentiel. En effet si l’on applique que les normes de qualité « classiques » et soumettre prématurément un produit logiciel (ou son processus d’élaboration) à la certification ISO Qualité (processus respectés, documentation bien faîte, existences des processus d’actions correctives…) alors que ce produit logiciel pourrait encore contenir beaucoup d’erreurs et d’imperfections…

CHAPITRE 3

Les diverses phases d’une mission d’audit

Ce n’est point dans l’objet que réside le sens des choses, mais dans la démarche. Antoine de Saint-Exupéry, écrivain et aviateur français (1900-1944)

3.1. Les diverses phases 3.1.1. Les principales phases et le schéma global Une mission d’audit est en fait composée de plusieurs phases commençant par une lettre de mission reçue par le service d’audit. La prise en compte de ces éléments ainsi que leur application efficace et adéquate constituent la bonne démarche de l’audit. Le schéma de la figure 3.1 permet d’en appréhender, par une vue générale, le processus. Chaque année, le responsable d’un service d’audit établit avec ses collaborateurs un programme d’intervention en fonction d’un plan d’audit, d’un programme annuel systématique et/ou d’un « portefeuille de missions ». Tous ces éléments constitués à partir des demandes de la Direction générale et/ou des diverses directions et services de la société, déterminent le choix des missions et la politique

68

L’audit technique informatique

de l’audit. Il est à noter que le portefeuille des missions s’agrandit en fonction de la compétence de l’équipe et de l’évolution de l’entreprise. Le responsable d’audit peut fixer les priorités avec un représentant de la Direction générale et arrêter la liste annuelle des missions. Le choix d’un cycle d’audit étant fixé, quelles que soient les missions, elles devront être annoncées par une lettre officielle de la Direction générale adressée aux services audités. Certes, cette phase est protocolaire mais indispensable. Elle déclenche le travail de l’équipe d’audit et amorce le point de départ d’une mission comportant plusieurs phases. Lettre de Mission

Enquête préliminaire

Phase de vérification Non Preuves suff ?

Oui

Rapport

Figure 3.1. Schéma global d’une mission d’audit

Au programme annuel du service d’audit, il peut exister plusieurs types de missions : – missions de type cyclique (deux fois ou une fois par an), par exemple : contrôle des stocks, vérification des indicateurs représentatifs de l’activité d’un service ; – missions spécifiques demandées par la Direction générale ;

Les diverses phases d’une mission d’audit

69

– missions dues à des événements nouveaux non prévisibles dans l’entreprise ou mission d’étude pour un service si celui-ci manque de ressources « personnelles » ou « matérielles » ou n’arrive pas à remplir la tâche qui lui est confiée. Une mission d’audit informatique, à l’instar d’une mission plus classique, peut se décomposer en trois grandes phases, une fois le sujet fixé et les lieux ou services à auditer déterminés : d’abord la phase d’enquête préliminaire, puis celle de la vérification, et enfin la phase dite de « restitution ». La restitution des informations et des remarques auprès des services audités peut être verbale ou écrite. Le premier cas peut se concevoir pour des missions ponctuelles et rapides sans complexité majeure (exemple : audit de diagnostic et attente des résultats pour une prise de décision rapide). 3.1.2. L’enquête préliminaire La définition des objectifs est la base d’une mission réussie. Les objectifs doivent être clairs, précis et en harmonie avec la demande de la Direction générale ou du service demandeur. En aucun cas, les objectifs ne pourront être déviés. D’une part, cela aurait une influence sur l’image de marque du service d’audit (donc une perte de confiance de la part des demandeurs de la mission), et d’autre part, la diminution des demandes de missions se ferait sentir tôt ou tard. En possession de l’ordre de mission, du sujet et des objectifs, les auditeurs peuvent démarrer leur mission. L’enquête préliminaire, point de départ de la mission, dure de quatre à cinq jours environ. Cette durée pourra être allongée si l’entreprise a plusieurs filiales ou agences disparates ou séparées géographiquement. Il serait souhaitable que l’ensemble de l’équipe d’audit affectée à cette mission, participe à l’enquête.

70

L’audit technique informatique

Par exemple, pour une mission d’audit informatique (cas d’une grande ou moyenne entreprise), la composition et la participation des membres suivants sont souhaitées : – chef de mission ou superviseur ; – l’auditeur spécialiste informatique ; – un deuxième auditeur (généraliste) en binôme ; – le chef du service d’audit (éventuellement mais non obligatoire). L’enquête préliminaire se compose généralement de quatre phases : l’analyse du sujet et la définition des objectifs, la préparation (documentation, élaboration des questionnaires...), la prise de contact avec les audités et enfin l’enquête préliminaire proprement dite sur le terrain. Cette dernière, d’une durée au minimum de deux ou trois jours, marque le démarrage d’une mission d’audit. Si la mission s’effectue sur plusieurs sites ou sur plusieurs services ou fonctions disparates, la durée peut alors être rallongée. Il est à noter que cette phase est souvent appelée phase de diagnostic rapide. But de cette phase : – collecter des informations afin de pouvoir dresser un plan de travail ; – étudier la faisabilité par rapport à l’ordre de mission, des objectifs préalablement fixés ; – remettre en cause éventuellement les objectifs (après discussion avec le service demandeur). Par exemple, pour une mission d’audit informatique du traitement des anomalies et limitation des factures erronées chez un opérateur des télécommunications comme précédemment cité, l’enquête préliminaire devra permettre de : – prendre rapidement connaissance des fonctions des divers services en jeu ; – étudier l’organigramme de l’organisation et les relations des services ; – s’informer sur le fonctionnement du centre de traitement ;

Les diverses phases d’une mission d’audit

71

– s’informer sur le volume des factures émises et le nombre de factures erronées ; – inventorier les délais, la fréquence des traitements ; – inventorier les positions de saisie d’information ; – détecter les erreurs probables ou potentielles ; – répertorier les divers types d’anomalies ; – identifier l’impact et les problèmes ressentis par : - les services contentieux, relation clientèle ; - le service d’informatique ; - la Direction générale ou autres directions ou services. A ce stade, il est intéressant de recenser et de définir les divers documents associés : – lettre de mission : c’est une lettre émanant de la Direction générale qui charge le service Audit interne d’une mission spécifique. Ce service présente ce courrier aux services audités lors d’une première réunion de contact. Ce sera le premier document important de la mission ; – thème de mission : présentation synthétique des problèmes et principaux objectifs assignés aux auditeurs par la Direction générale ; – planning ou plan d’approche : c’est un document décrivant la manière et éventuellement les méthodes utilisées pour aborder la mission, le chef de mission peut inclure le budget dans ce document de planification ; – programme de travail : c’est un plan détaillé d’investigation et de vérification concernant les points forts et les points faibles. Ce plan fait référence à des instructions et procédures relatives à la mission. Il doit être approuvé par le superviseur (voir lexique) et communiqué au responsable de l’audit interne ; – mémorandum : ce document est une note de synthèse élaborée après certification de certains faits (voir définition plus détaillée dans le lexique). A titre d’exemple, un plan du programme de travail d’une mission intitulée « Limitation des factures erronées » pour un opérateur sera présenté au chapitre 7.

72

L’audit technique informatique

Enfin, après la phase de l’enquête préliminaire, la phase de vérification s’impose. Nous allons la développer maintenant. 3.1.3. Phase de vérification La phase de vérification doit être menée scrupuleusement en fonction du programme de travail. Elle a pour but de confirmer les points forts ou points faibles supposés ou constatés dans la phase précédente et de chiffrer, éventuellement, les pertes et risques. Cette phase se décompose de la manière suivante : – au préalable, l’établissement du programme de vérification ; – l’étape de vérification sur le terrain, et la recherche des preuves et défaillances ; – le dépouillement et la compilation des résultats obtenus ; – enfin l’exploitation des résultats et la première mise en forme, le classement et la préparation pour l’intégration dans le futur rapport. Dans la plupart des cas, la recherche des preuves est relativement évidente à condition de savoir que chercher et quelles preuves trouver en suivant une démarche préétablie. La vérification doit être menée avec un planning rigoureux établi au préalable compte tenu des divers éléments à auditer dans une mission et de l’emploi du temps des personnes des divers services audités. C’est une phase primordiale de la mission qui a pour objectif de fournir aux auditeurs des preuves concernant les points faibles présumés, et surtout les dysfonctionnements de l’organisation ou des systèmes visités pouvant ainsi mesurer l’impact des conséquences. On peut dissocier deux types de vérifications. a) Les vérifications rapides On peut appeler cette phase, la « vérification de survol ». En effet, elle s’appuie sur les premiers entretiens, l’examen de la documentation, les

Les diverses phases d’une mission d’audit

73

procédures et des vérifications rapides de conformité (par exemple la déclaration de l’existence d’un document lors d’une interview s’avèret-elle exacte avec la documentation sur place). L’objectif est de permettre aux auditeurs de détecter rapidement les points forts et les points faibles. b) Les vérifications approfondies L’objectif de cette phase est d’apporter des preuves pour conforter les éléments recensés dans l’étape précédente et de chiffrer « les dégâts » réels ou potentiels. Les deux schémas suivants permettent de mieux appréhender l’articulation des principales phases d’une mission d’audit et les diverses étapes de la phase même de vérification. Résumons rapidement les étapes : la lettre de mission déclenche la mission d’audit par une enquête préliminaire, suivie de la phase de vérification. La dernière phase concernant l’élaboration du rapport ne peut se déclencher que si toutes les preuves sont considérées comme suffisantes et confirmées. La phase de vérification quant à elle, peut être décomposée en deux sous-phases. Le schéma suivant permet de bien montrer toutes les étapes de cette phase. Il détaille les étapes en amont et en aval de la phase de vérification. Cette dernière est elle-même décomposée en deux processus : les vérifications rapides et les vérifications détaillées. L’organigramme suivant décrit toutes les étapes avant la phase de rapport, appelée aussi phase de restitution.

74

L’audit technique informatique

Etabliss. Plan d ’approche Programme de vérification

Vérifications rapides Non Vérifications détaillées

1

3 BBK sûrs?

Pr

2

Confir.

oui

Dépouillement des résultats Exploitation & Mise en forme

Phase de rapport 1- BBK : venant de l’anglo-saxon (voir la définition du lexique) 2- PR : points de reprise (voir lexique) 3- Confir : confirmation des points de reprise, la demande peut être faite par voie téléphonique. Il est possible de redescendre sur « le terrain » si la réponse n’est pas satisfaisante. Figure 3.2. Organigramme des différentes étapes de l’audit

3.1.4. Phase de restitution et du rapport La dernière phase d’une mission, appelée phase de restitution du rapport d’audit consiste en la préparation, la rédaction et l’édition d’un rapport. Les principales étapes sont : – rédaction d’un projet de rapport ; – la présentation du projet et l’examen des incohérences ou points faibles, la mise en accord avec les audités, puis l’élaboration définitive des recommandations (leur déroulement sera systématiquement suivi ultérieurement, grâce aux fiches de suivi) ;

Les diverses phases d’une mission d’audit

75

– la rédaction du rapport définitif ; – la notification et l’envoi du rapport au service intéressé ; – l’établissement des fiches de suivi et l’envoi de la lettre de clôture de la mission. Le rapport d’audit doit présenter une démonstration neutre, objective et apporter des critiques constructives. C’est un dossier technique qui doit être compréhensible et « lisible » par la hiérarchie ou le High Management qui ne sont pas des spécialistes par rapport au personnel des services audités. Ce document fournit des recommandations en regard des points faibles détectés. Parfois, il peut exister des recommandations qui ne sont pas obligatoires (ou doivent être impérativement suivies), mais étant émises par l’œil neuf d’un service compétent, elles peuvent apporter des améliorations ou autres idées concernant les procédures de travail. Ainsi dans la limite de leurs contraintes et de leurs responsabilités, les services audités sont libres de tenir compte et/ou d’appliquer ces recommandations. Néanmoins, il serait souhaitable que le responsable du service audité argumente le non-suivi de ces recommandations. Bref, ce rapport est le fruit du travail d’une équipe, pour la direction et pour le service audité, dont le but essentiel est de contribuer à l’amélioration et à la bonne marche de l’entreprise. Le rapport final constituant le fruit de deux à trois mois d’enquête de l’équipe est luimême précédé par un pré-rapport. Ce dernier document est appelé aussi « projet de rapport ». Il doit être envoyé aux services audités pour des remarques et/ou des contestations éventuelles. Ce n’est qu’après concertation et accord que le rapport définitif est édité‚ intégrant les remarques et corrections éventuelles. Dès lors, ce dernier pourra être envoyé au demandeur de la mission, à la Direction générale et aux services audités.

76

L’audit technique informatique

Quelques conseils pour le rapport final Le volume et l’épaisseur du rapport sont fonction du thème et des services audités (il n’y a pas de règle fixe). Par exemple, il est évident que la description des dysfonctionnements d’un service d’un département ou d’une division est probablement moins longue que celle du département entier avec ses systèmes informatiques et ses relations avec d’autres entités. Mais d’une manière générale, il est fortement conseillé d’élaborer dans la mesure du possible des rapports inférieurs à 25-30 pages. Au-delà, ils lasseraient le lecteur. Un document de 10 à 20 pages, pouvant relater les procédures, les points faibles, les dysfonctionnements et les recommandations pertinentes pourrait être une bonne moyenne. D’autre part, de la clarté et de la concision sont nécessaires. L’organigramme d’un service au sein du rapport même est à déconseiller. Tout au plus, il se trouvera en annexe. La description des fonctions n’est pas obligatoire, à moins qu’elle soit indispensable pour situer les points faibles et élaborer les recommandations. Enfin, les annexes ne sont pas obligatoires non plus. Elles ne doivent être à leur place que si la justification des recommandations ou la compréhension d’un service et/ou d’une procédure sont utiles, primordiales. D’autre part, elles peuvent contenir des analyses ou des calculs auxquels il est fait allusion dans le rapport. Le plan d’un rapport est fourni en exemple ultérieurement (voir section 7.2). REMARQUE.− D’après les conseils et les termes des professionnels, de l’IFACI (Institut français des auditeurs et consultants internes), les auditeurs devraient dresser un tableau des points forts (PF) et points faibles (pf) apparents, dégagés d’après certaines preuves ou d’après l’intime conviction, et que l’on s’impose professionnellement de vérifier.

Les diverses phases d’une mission d’audit

77

Indépendamment des diverses phases précitées, en regard de ces investigations, il importe de connaître les outils et moyens utilisés par les auditeurs internes. La section 3.2 essaie d’apporter quelques éléments de réponses. 3.2. Les techniques, les outils et la formation Pour effectuer les vérifications ou les enquêtes, un certain nombre de techniques peuvent être utilisées, mais elles possèdent un champ d’action limité et ne peuvent être adaptables dans tous les cas. Le choix d’une technique est fonction du problème à résoudre. D’autre part, en dehors de la formation de base des méthodes d’audit, les auditeurs doivent être sensibilisés aux techniques de traitements de l’information, à la technique de réunion, aux processus d’interviews, à l’élaboration des questionnaires pertinents. Compte tenu de l’existence d’une littérature abondante, nous ne développons pas ces sujets, mais fournissons néanmoins quelques indications dans l’annexe. 3.3. Exemple et démarche pour les audits qualité d’un service de support Pour illustrer les différentes phases détaillées ci-dessus, nous donnons un exemple d’audit concernant un service de support d’une division informatique d’une entreprise. En voici la mission : ayant reçu des plaintes d’utilisateurs concernant les services rendus, la Direction générale mandate un audit sur le processus de support de la division informatique. La lettre de mission est envoyée simultanément à la Division informatique et au responsable d’audit (au mois de mars de l’année N). L’audit était planifié et sera exécuté après les vacances d’été.

78

L’audit technique informatique

Nous développons les éléments correspondants à chaque phase du processus d’audit après la réception de la lettre de mission : – l’enquête préliminaire ; – la phase de vérification ; – la phase de rapport. Mais regardons d’abord le travail du responsable d’audit et les concertations avec ses auditeurs : travaux qui peuvent occuper jusqu’à 15 % du temps total dans une mission d’audit. Cette phase sera nommée « phase de pré-audit et de planification ». 3.3.1. Phase de pré-audit et de planification (14 %) Dans notre cas particulier, il est évident que ce n’est pas une mission planifiée d’avance ou une mission de type cyclique. De ce fait, le responsable d’audit devrait décaler ou refaire son planning annuel prédéfini et effectuer un choix parmi ses ressources disponibles et compétentes en la matière. Il devrait, dès lors, provoquer une ou plusieurs réunions de travail avec son équipe pour discuter l’objet de l’audit et l’affectation des ressources. Après, il devra répondre à la direction générale (DG) et écrire au service audité en mettant en annexe le mandat officiel de la DG. Par expérience, un responsable pourrait identifier le référentiel utilisé et effectuer une esquisse de la démarche qui pourrait être suivie par son équipe. Ainsi après vérification de ses ressources et la possibilité de décaler certaines missions moins importantes, le responsable propose à ses auditeurs les deux points importants suivants : – acceptation de la mission ; – utilisation du référentiel du service audité s’il existe, dans le cas contraire, les auditeurs s’appuieront sur la norme ISO/IEC 12207, en particulier les éléments de l’article 6 pour la vérification concernant le support : - vérifier le processus de documentation de l’équipe de support ; - le processus de gestion de configuration des logiciels utilisés par le support ;

Les diverses phases d’une mission d’audit

79

- le processus d’assurance de la qualité de ce service ; - le processus de revue de ce service ; - le processus de résolution de problèmes du personnel support. 3.3.2. Phase de l’enquête préliminaire (25 %) Elle est composée des quatre sous-phases suivantes : – l’analyse du sujet et la définition de l’objectif ; – la préparation (la documentation, l’élaboration des questionnaires...) ; – la prise des contacts des personnes du service audité ; – l’enquête préliminaire sur le terrain. 3.3.3. Phase de vérification rapide (20 %) Elle est appelée aussi phase de vérification de survol, les bases de nos travaux s’appuient sur : – les premiers entretiens ; – l’existence et l’examen rapide de la documentation, des procédures recueillies sur le terrain et sur les vérifications rapides de conformité. L’objectif est de permettre aux auditeurs de détecter rapidement les points forts et les points faibles. Ainsi, ils devraient dresser un tableau des points forts (PF) et points faibles (pf) apparents, dégagés d’après certaines preuves ou leur intime conviction et s’imposer aussi, professionnellement, d’effectuer plus tard des vérifications plus approfondies. Pour cette mission, nous avons détecté quelques points forts : – l’existence d’une documentation complète des logiciels que le service a la responsabilité de supporter ; – l’existence d’une procédure générique de support fournie à chaque nouvelle personne entrant dans le service ; – un bon taux de couverture du service de support.

80

L’audit technique informatique

Mais aussi quelques points faibles : – une documentation existante, mais non mise à jour ; – un défaut d’harmonisation en matière de traitement des problèmes soulevés par les utilisateurs, soit par téléphone, soit par fiche d’incidents ; – aucun délai (même approximatif) n’est fourni aux utilisateurs ; – un niveau de compétence de l’équipe support disparate. 3.3.4. Phase de vérification ou réalisation de l’audit proprement dit (25 %) Cette phase importante permet aux auditeurs de vérifier tous les éléments minutieusement et en détail, afin de pouvoir apporter les preuves des points forts et des points faibles détectés ou pressentis dans les phases précédentes. Des entretiens approfondis ont eu lieu avec les personnes d’un échantillon établi. Sur un ensemble de vingt-quatre personnes, nous avons constitué une liste de dix-sept personnes travaillant dans diverses tranches de plages horaires. Nous avons une représentativité de plus de 75 %. Ce pourcentage est plus qu’honorable pour une mission d’audit. Les autres personnes de l’équipe étaient soit en congé, soit en formation. Dans notre mission, nous vérifions aussi les divers documents mis à la disposition de chaque membre de l’équipe et vérifions, bien sûr, les dernières versions de la documentation avec celles fournies par le service développeur et par les fournisseurs des logiciels. En cas de doute, il convient de téléphoner à ces derniers et même de demander les dernières documentations. Puis, grâce aux fiches d’incidents recensés, on vérifie la réponse apportée avec la date de clôture d’incidents. Dans un autre service audité, ces mêmes fiches portent le nom de « ticket d’incident ». Quant aux niveaux de compétences disparates des membres de l’équipe, il faut vérifier les dossiers de formation, leurs expériences

Les diverses phases d’une mission d’audit

81

(backgrounds) et comparer les délais des réponses de chaque membre concernant les incidents de même type. Ainsi par ces méthodes, on obtiendra des preuves tangibles et indéniables. A la fin de cette phase, les auditeurs sont en mesure de préparer le pré-rapport avec des éléments complets issus de toutes les phases antérieures. 3.3.5. Phase de restitution et du rapport (16 %) Dans notre mission, cette phase est en fait concrètement décomposée en deux sous phases appelées : « phase de rapport » (8 %) et « phase de finalisation » (8 %). 3.3.5.1. Phase de rapport L’écriture du rapport final (la version 0 que l’on envoie aux services audités) ne peut se concevoir qu’après l’exécution de toutes les phases précédentes. Néanmoins, l’élaboration du plan, de la structure et des grands pavés du pré-rapport (appelé le projet ou draft) peut être débutée beaucoup plus en amont et complétée au fur et à mesure lors du déroulement des phases. 3.3.5.2. Phase de finalisation de la mission Elle comprend : – la présentation du projet et l’examen des incohérences ou points faibles, l’obtention d’un accord avec les audités, puis l’élaboration définitive des recommandations (l’application de ces dernières sera contrôlée ultérieurement grâce aux fiches de suivi) ; – la rédaction du rapport définitif ; – la notification et l’envoi du rapport au service intéressé ; – l’établissement définitif des fiches de suivi et l’envoi de la lettre de clôture de la mission (cette dernière ne sera envoyée aux divers acteurs concernés qu’après réception de l’accusé de réception de notre rapport par les services audités, sans autre demande de modification).

82

L’audit technique informatique

Pour cette mission d’audit qualité d’un service de support, nous avons émis trois fiches de suivi : la première concerne la mise à jour de la documentation technique, la deuxième concerne les fiches d’incident (dans laquelle nous recommandons de fournir un délai approximatif aux utilisateurs) et enfin la dernière est en rapport avec la formation du personnel de support afin d’harmoniser le niveau de compétence de l’équipe. Il est à remarquer que ces fiches de suivi serviront comme input pour une prochaine mission du même genre. Enfin, concernant l’harmonisation en matière de traitement des problèmes soulevés par les utilisateurs, soit par téléphone soit par fiche d’incidents, nous avons émis une recommandation, mais il ne nous semble pas nécessaire d’établir une fiche de suivi. En effet, il suffit d’améliorer la procédure existante (c’est ce qui a été promis par le service audité).

Résumé du chapitre 3 Une mission d’audit se gère comme un projet en soi. Dès lors, il importe d’identifier les différentes phases ainsi que les entrées et sorties (inputs et outputs) correspondants du processus. Après la réception de la lettre de mission, l’équipe d’audit devrait établir la démarche et son programme de travail. Ce chapitre détaille donc les diverses étapes, allant de l’établissement d’un plan d’approche à la phase de restitution constituée par la phase d’élaboration du rapport et la clôture de la mission, en passant par les deux phases de vérification (comprenant les vérifications rapides et les vérifications détaillées). Il se termine par la présentation d’un audit qualité d’un service de support pour illustrer l’approche présentée. A titre d’exemple, une répartition en temps des diverses étapes du processus d’audit est proposée, mais il convient de noter que ceci est purement indicatif. En effet, la répartition réelle est dépendante de chaque projet spécifique.

FOIRE AUX QUESTIONS (CHAPITRE 3)

Question 1 : par faute de temps, peut-on se dispenser de la phase de vérification rapide ? Réponse : surtout pas, car cette phase est primordiale et l’on finirait par le regretter. En effet cette phase est nécessaire pour récolter la documentation et effectuer un premier contact avec les personnes à auditer. Question 2 : lorsqu’un point faible est relevé, il est normal qu’un auditeur le cite dans son rapport, mais peut-il citer le nom de la personne qui a engendré l’erreur ? Réponse : il n’est pas souhaitable d’en citer l’auteur. En effet, quoique responsable de l’erreur, la personne se trouve dans un système ou contexte lui laissant la possibilité de la faire. Il serait donc plus diplomate et professionnel de proposer une recommandation pour éviter de futures erreurs potentielles, plutôt que de citer le nom de la personne. Question 3 : quel est le nombre de jours de formation nécessaires pour un auditeur informaticien de l’entreprise ?

84

L’audit technique informatique

Réponse : il n’y a pas de règles fixes. Il est souhaitable que la formation soit programmée et bien cadrée suivant les besoins. Une semaine de formation est un minimum, la moyenne est plutôt de deux semaines compte tenu de l’évolution rapide des technologies de l’information. Ceci ne tient pas compte des formations supplémentaires à suivre chez les constructeurs lors du changement du système de l’entreprise (si les auditeurs doivent s’impliquer plus dans les audits systèmes et réseaux) (voir aussi l’annexe 1). Question 4 : peut-on découvrir, lors d’une phase de vérification, l’existence dans un service informatique de l’utilisation simultanée de deux normes relatives à la qualité des logiciels ? Réponse : tout à fait, cette découverte n’est pas rare. Cependant l’auditeur doit vérifier que ces deux normes ne sont pas incompatibles. Si elles le sont, il importe de le signaler à la Direction générale ou à la Direction informatique, car c’est aussi le rôle de l’auditeur (voir également la foire aux questions du chapitre précédent - question 7). Question 5 : à quel moment peut-on commencer à établir le plan du rapport ? Réponse : il n’y a pas de règle fixe. Néanmoins le plan, la structure et les grands pavés d’un rapport (plutôt le pré-rapport) sont à établir très en amont. Car ceci permet de fixer la direction du processus. Ce document établi pendant la phase de vérification peut être profitable. En effet, à ce moment, on a plus de visibilité et comme éléments en entrée, on peut citer : – le plan d’approche ; – le programme de vérification ; – quelques éléments obtenus pendant cette phase de vérification…

Foire aux questions

85

Question 6 : les fiches de suivi sont-elles nécessaires ? Réponse : en principe oui. Une mission sans l’élaboration de fiches de suivi identifie une mission d’audit parfaite, sans aucun point faible détecté, ce qui est plutôt rare ! Question 7 : lors de l’exemple précédent, dans le dernier chapitre, une norme est présentée et utilisée, peut-on la combiner avec les préconisations de type CMM lors d’un audit informatique ? Réponse : la réponse est catégorique : non ! En effet, même si les normes ont souvent des philosophies plus ou moins analogues concernant l’évaluation, une utilisation combinée de deux normes techniques (normes demandant des exigences différentes) peut entraîner des confusions pour les audités. Et lors des recommandations, quel référentiel citera-t-on ? D’autre part, le second référentiel CMM prend toute sa valeur lors d’un audit à blanc par les auditeurs internes pour préparer l’entreprise à la première certification CMM ou préparer l’accès à un niveau supérieur.

CHAPITRE 4

Les missions d’audit demandées par la Direction générale

L’énergie usée à atteindre des normes de qualité est inversement proportionnelle au temps restant avant le prochain audit. Olivier Sax, écrivain contemporain.

4.1. Audit de la politique informatique 4.1.1. Audit de la politique d’acquisition en vue de l’informatisation (adéquation des produits verticaux, rentabilité) Pour concevoir un système d’information ou une application et les rendre opérationnels, il existe trois moyens : faire, faire faire ou utiliser un savoir-faire existant. Néanmoins, il faut identifier l’objet souhaité dès le départ et un des documents importants d’identification est le cahier des charges ou le dossier des spécifications. Le cahier des charges est un document contractuel entre le client demandeur d’un service (ou d’acquisition de matériel) et ses fournisseurs. On appelle aussi « cahier des charges » le document

88

L’audit technique informatique

établi entre l’équipe informatique interne d’une entreprise et une SSII à l’occasion d’une sous-traitance. Le demandeur de service peut l’établir seul ou avec le fournisseur de service éventuel. Ce document est primordial, il doit être clair, précis et sans ambiguïté. En effet, à l’occasion de litiges éventuels, il servira de document de base d’une façon légale. Son contenu peut s’établir de la manière suivante. 4.1.1.1. Exemple de cahier des charges Ce plan est donné à titre d’exemple, car il existe de nombreuses dispositions en fonction des documents de chaque entreprise. 1. Définition générale et contexte du problème : – les objectifs ; – les contraintes. 2. Les documents de base : – les divers documents et schémas de circulation ; – les états d’entrée et de sortie (pour une application). 3. Fonctionnalités du futur système : – les traitements ou modules (ou les détails des matériels) ; – les solutions envisagées. 4. Les directives : – les diverses directives ou recommandations ; – les prévisions d’extension (système ouvert). 5. Conclusion et engagement : – rappel des engagements mutuels ; – délai des travaux, planification... Les directives sont parfois destinées à rappeler certaines notions ou préconisations du schéma directeur (s’il existe des écarts, ce sera le rôle du service de contrôle de le signaler), à modifier l’organisation

Missions d’audit demandées par la DG

89

(pour s’adapter au processus d’informatisation par exemple), et les extensions futures éventuelles. La Direction peut demander aux auditeurs de participer à ce processus. Ces derniers peuvent contribuer à veiller à la régularité de la procédure de l’appel d’offres et de l’établissement du cahier des charges. Enfin, il est à remarquer que la vérification de la politique logicielle (harmonisation et compatibilité des logiciels, anti-piratage…) pourrait aussi faire l’objet d’une mission demandée au service de l’audit et confiée aux auditeurs informatiques. 4.1.1.2. Utilisation d’un cahier des charges Cet exemple est extrait d’un cas d’audit réel : lors d’un appel d’offres pour l’extension d’une application, la Direction générale s’aperçoit des demandes excessives de tarification de la part des SSII. Souhaitant comprendre le pourquoi des choses et éventuellement y remédier pour le futur, la Direction charge une mission d’audit. Après interviews des acteurs concernés et consultation des documents existants, l’audit informatique permet de révéler que, dans le cahier des charges, il manque une partie concernant les prévisions d’extension et les engagements mutuels entre la SSII et la société. En fait, l’application était fournie avec un système propriétaire par l’ancienne SSII qui, entre temps, a été absorbée par une grande compagnie ; l’équipe des anciens analystes et développeurs a été dissoute. De cet audit et du rapport qui en a résulté, on retient la recommandation suivante : « Concernant les applications non spécifiques, il serait souhaitable d’utiliser au maximum les équipements et/ou les produits COTS (Commercial-Off-The-Shelf equipment/ product) – produits sur étagères – existants sur le marché. En effet, la maturité de ces produits facilitera la maintenance et l’extension future ».

90

L’audit technique informatique

D’autre part, le rôle de l’auditeur peut consister à fournir des conseils concernant : – le choix d’un produit par comparaison avec les études de CXP par exemple ; – le choix d’un type de produit similaire tel que l’ASP (Active Server pages package) parmi ceux offrant l’application demandée ; – le choix d’une politique de sous-traitance pour des produits verticaux très spécifiques. 4.1.2. Audit des projets et futurs projets (audit de processus de développement) Une mission d’audit d’un nouveau projet d’informatique (ou plutôt d’un processus de développement en cours) peut être souvent demandée par la Direction. L’engagement d’un projet ne peut se concevoir sans l’assurance que quelques grands principes, avant même le début de la réalisation, soient respectés. En effet, un nouveau projet ne doit pas seulement son existence qu’à cause des besoins pressants et urgents des utilisateurs. Il ne se justifie qu’après l’analyse de l’existant et l’étude d’opportunité. Enfin, il doit être piloté et suivi par un comité et/ou un chef de projet qui rendra compte régulièrement aux comités de direction ou aux organes décisionnels de l’entreprise. L’audit informatique peut être sollicité par la Direction pour l’assister, pour confirmer ou infirmer le diagnostic de départ. On voit donc que les rôles de l’auditeur sont : – s’assurer de l’intérêt du nouveau projet ; – s’assurer de l’existence d’une coordination et de l’existence d’une remontée d’information vers les organes de décision ; – s’assurer de la véracité et de la pertinence des points forts et points faibles soulevés ; – veiller aux coûts (s’assurer de l’inexistence des faux frais...), la planification et la régularité du financement. Une remarque importante : après la phase d’analyse de l’existant, on débouche sur celle de l’analyse de conception, étape limite où le

Missions d’audit demandées par la DG

91

service d’audit interne doit conseiller le développement et l’intégration des audits trail (voir lexique) dans les applications. Ces « détecteurs de trace » faciliteront le contrôle, les tests et l’audit ultérieur de la future application. Dans ces contextes, il importe de suivre la démarche suivante pour auditer : 1) identification de la méthode choisie par le comité et/ou responsable de projet : la méthode choisie est primordiale car son adéquation à la situation peut retarder ou faire avancer considérablement un projet d’informatisation. L’expérience de l’équipe vis-à-vis d’elle, l’adhésion et les retours d’expérience sont des questions primordiales à se poser ; 2) prise de conscience des points forts et des points faibles dans le contexte audité : les réponses précédentes permettent de fournir quelques éléments de réponse du diagnostic et d’établir la liste des points faibles ralentissant le projet, après interviews des acteurs concernés et consultations des divers documents existants ; 3) vérification des points faibles : cette phase est très importante car elle permet de vérifier les éléments recueillis précédemment, et ce, avant d’aborder la dernière phase. Tant que tous les éléments ne sont pas vérifiés, les auditeurs ne peuvent émettre les recommandations et conseils ; 4) élaboration des recommandations : cette phase clôture la démarche proposée. Les recommandations justes, précises et pertinentes constitueront les plus-values de la mission d’audit informatique. Nous donnons ci-après un exemple de l’application de cette démarche. Confrontés à une mission d’audit dans un environnement de développement moderne (application pour le Web), les auditeurs ont pour mission de fournir, si possible, des recommandations afin que l’application développée se comporte sans bugs (ou le moins possible) et que les délais de livraison soient respectés.

92

L’audit technique informatique

Tout d’abord, les auditeurs identifient la méthode pratiquée et l’expérience de l’équipe vis-à-vis d’eux, son adhésion au projet, ainsi que l’existence de retours d’expérience. A partir de la documentation existante et des interviews des acteurs concernés, les auditeurs découvrent que la méthode XP (eXtreme Programming) est relativement nouvelle pour l’équipe de développement. Néanmoins, celle-ci est très motivée, mais il s’avère que les codes collectifs dans la bibliothèque logicielle étaient peu nombreux. Les auditeurs découvrent les points forts suivants : – motivation de l’équipe ; – coopération active entre les développeurs et les utilisateurs ; – la méthode est adaptée pour ce type d’application. Cependant, les points faibles sont : – formation à la démarche XP pas encore assurée à tous les développeurs ; – manque de codes collectifs réutilisables ; – mélange des versions de tests associé à un problème de gestion des configurations. La phase de vérification permet de confirmer les éléments trouvés précédemment. En effet, compte tenu du problème de maturité de l’équipe concernant XP et le manque d’outil de gestion de configuration adéquate, les tests et leurs résultats n’étaient ni suivis, ni mis en œuvre d’une manière convenable. La confirmation de nos éléments de diagnostic, après vérification, permet d’élaborer la recommandation suivante : « La formation de toute l’équipe à la méthode XP ainsi que l’apport d’un outil de gestion de configuration devraient améliorer le développement des applications et réduire les délais. Enfin, il est vivement conseillé de simuler les corrections avant de les mettre en exploitation réelle. »

Missions d’audit demandées par la DG

93

En résumé L’objectif de l’audit du processus de développement du logiciel est de fournir à la Direction et/ou au maître d’ouvrage une confirmation de la conformité du processus de développement suivi par l’entité auditée (maître d’œuvre, constructeurs, sous-traitants…) vis-à-vis des dispositions d’Assurance qualité du logiciel, elles-mêmes définies par l’état de l’art, les règlements normatifs ou des spécifications établies au préalable. De ce fait, les éléments suivants doivent être vérifiés par les auditeurs informatiques : – politique de gestion de la qualité du logiciel ; – fonction qualité logiciel (responsabilité et autorité, ressources pour la vérification…) ; – documentation du système qualité logiciel (manuel qualité logiciel, plan qualité logiciel…) ; – management de projet (responsabilité, planning, revues…) ; – contrôle qualité du logiciel (cycle de développement, méthodologie de développement, outil…) ; – activités de gestion de projet (vérification des documents, gestion de configuration, gestion, des modifications, mesure de la qualité…). Des métriques objectives doivent être utilisées pour chacun de ces critères. Ces métriques doivent être définies au préalable et connues par les audités. Ainsi, les résultats de l’audit du processus de développement du logiciel permettent : – d’identifier les données et processus manquants ou incomplets dans le développement en vue d’apporter des recommandations d’amélioration ; – d’évaluer, dans le cadre d’une certification ou d’une qualification du logiciel, les sources potentielles de défaillance de ce dernier ;

94

L’audit technique informatique

– d’évaluer les points forts et les points faibles des acteurs (maître d’œuvre, sous-traitants,…) en terme de processus de développement du logiciel ; – de recommander le choix ultérieur d’un ou plusieurs acteurs pour la maintenance ou la sous-traitance (ex : dans le cadre d’appel d’offres). 4.2. Audit relatif aux finances de la fonction informatique Ce type d’audit est très souvent demandé soit par la Direction générale soit par la Direction financière. En effet, soucieuses des investissements et de leur rentabilité, ces deux directions sont parties prenantes des projets informatiques. Ce type d’audit permet de détecter le fonctionnement correct des démarches budgétaires et de mesurer les écarts financiers. 4.2.1. Audit du budget et du suivi Afin de bien vérifier cette démarche, il importe de distinguer les budgets de fonctionnement de celui des investissements. Rappelons que les premiers types de budgets concernent l’exploitation courante ; les dépenses sont du côté débit du compte d’exploitation informatique dans un système comptable. Quant aux seconds, ils concernent les dépenses en matière d’investissement (achat de matériels, de systèmes, de progiciels…) et de développement de logiciels nécessaires pour les activités de l’entreprise. La séparation de ces deux types de budget est fondamentale, car elle permet de mesurer les équilibres et les adéquations des budgets des postes. L’objectif de l’audit du budget et du suivi est de s’assurer de la fiabilité des mécanismes de prévision et de suivi budgétaires. Dans ce contexte, l’auditeur doit vérifier les points suivants : – l’élaboration du budget concernant chaque chapitre ; – sa structure ; – son évolution ; – son suivi.

Missions d’audit demandées par la DG

95

Autrement dit, il est nécessaire de connaître quand, comment et par qui le budget est élaboré. Il importe aussi de savoir comment il évolue et comment et par qui il est suivi. Le budget est-il vérifié d’une part par des acteurs responsables du service et/ou du projet, et d’autre part, par un contrôleur de gestion interne ou externe ? 4.2.2. Audit sur la comptabilité analytique La comptabilité analytique est indispensable dès lors qu’il y a un besoin accru de détail et que la taille du service informatique croît. En effet, si elle n’est pas légalement exigible, elle est plutôt exigée par la Direction générale et /ou par les actionnaires avertis pour connaître les imputations et les dépenses de chaque poste. Si la taille de l’entreprise est assez grande, le centre ou le service informatique peut alors être considéré comme une division, ou pourquoi pas, un centre de profit et de service. Dès lors, l’établissement d’une comptabilité analytique peut fournir des éléments intéressants pour mener sa stratégie et les analyses ultérieures. Les charges sont alors découpées par nature et divisées en deux ensembles : les charges directes et les charges indirectes. Les charges directes sont celles directement imputables aux applications ou aux projets identifiables et répertoriés, alors que les charges indirectes seront imputables à ces mêmes applications ou projets mais via des sections ou chapitres spécifiques d’abord. Par exemple via les lignes ou codes budgétaires pour les études, les traitements, les postes d’énergie, l’achat des fournitures… Nous n’allons pas rentrer davantage dans les détails d’un système de comptabilité analytique, mais nous allons identifier les objectifs de vérification et les rôles des auditeurs dans ce cadre. Les objectifs dans ce genre de mission sont les suivants : – vérifier l’existence d’une comptabilité analytique adéquate dans le service ;

96

L’audit technique informatique

– analyser le degré de granularité et de détail (est-ce suffisant ? est-ce que la nature et les imputations destinatrices sont bonnes ?). Pour ce faire, le rôle de l’auditeur est : – d’examiner tous les documents relatifs de cette comptabilité ; – vérifier le découpage des charges ; – vérifier leur affectation aux divers projets et/ou applications. En fin de mission, les auditeurs devraient être en mesure de prononcer l’adéquation du système analytique ou éventuellement émettre des recommandations pour l’amélioration du découpage et/ou pour les imputations ultérieures. 4.2.3. Audit sur les prestations internes En général, une direction informatique (DI) fournit des services aux autres directions. Il importe de distinguer les services fournis et les charges relatives. Les méthodes de facturations sont nombreuses et dépendent de la nature des services ; par exemple une distinction doit être faite en fonction des prestations fournies en matière d’exploitation, de maintenance ou pour les études. Dans ce contexte, les rôles de l’auditeur sont les suivants : – vérifier la justesse de la facturation ; – assurer une compréhension facile pour les utilisateurs des directions que la DI facture ; – vérifier la permanence des tarifs ; – veiller à l’harmonisation dans la facturation : à services fournis identiques, la méthode de facturation doit être identique. Il importe que les factures de prestations envoyées aux utilisateurs soient claires, concises et transparentes. Un changement de tarif du prestataire doit être signalé aux services utilisateurs en temps opportun ; par exemple suffisamment à l’avance à ces derniers afin qu’ils puissent eux-mêmes préparer leurs propres budgets de fonctionnement ou d’investissement.

Missions d’audit demandées par la DG

97

4.2.4. Audit des coûts L’audit des coûts informatiques fait partie des outils du management. De ce fait, ce genre de mission est souvent demandé par la Direction générale et/ou par la Direction informatique. Cependant il faut dissocier les coûts d’investissement à ceux de fonctionnement. Ainsi, concernant les coûts de fonctionnement, le rôle de l’auditeur est de : – s’assurer de la rentabilité des systèmes (applications et machines) ; – s’assurer de la maîtrise des coûts par les gestionnaires ; – vérifier que la croissance des coûts est conforme aux prévisions (sinon, rechercher les causes) ; – fournir éventuellement des recommandations ou proposition des solutions d’extension. Les démarches de l’auditeur pour accomplir sa mission sont : – évaluer la facturation interne et externe ; – évaluer la comptabilité analytique ; – calculer les coûts de la non-qualité (évaluer les pertes ou manque à gagner dus aux pannes des systèmes) ; – incorporer les coûts annexes (dépenses exceptionnelles de saisie, de location du matériel pour dépannage...) ; – évaluer la comptabilité des systèmes. Ce point consiste à analyser le temps UC ou CPU (Central Processing Unit), le temps d’utilisation des diverses ressources (disques, imprimantes...) ainsi que l’occupation des espaces disques. Cette démarche permet de surveiller la qualité et la fiabilité des machines, d’éviter les contre-performances et de prévoir l’évolution ; – recenser le nombre d’utilisateurs des systèmes et observer l’évolution ; – recenser l’évolution des coûts (accroissement raisonnable ?). Prenons un exemple pour illustrer ces deux derniers points. Ces données pourront contribuer à l’analyse de l’auditeur. Les deux schémas suivants permettent d’observer et comparer l’évolution des

98

L’audit technique informatique

coûts dans un CTI (centre de traitement d’information) ou dans un centre de serveurs. Le premier graphique montre l’accroissement des volumes d’informations traités durant les trois années N. Le deuxième montre, quant à lui, les coûts durant la même période de temps. 45 40 35 30 25 20 15 10 5 0

Série1

année 1

année 2

année 3

Figure 4.1. Schéma montrant le volume d’informations traitées

700 600 500 400 300 200 100 0 année 1

année 2

année 3

Figure 4.2. Schéma montrant l’évolution des coûts

Une étude comparative peut être intéressante et révéler des erreurs de gestion. En deux ans (entre les années 1 et 3), le volume d’informations à traiter a crû de 30 % :

Missions d’audit demandées par la DG

30 % qui est égale à :

99

40 − 10 100

et le coût a augmenté de 500 % :

600 − 100 100

Or, pour une même période de deux ans (entre les années 0 et 2), le volume d’information a crû de 30 %, pour un delta de coût énorme et non linéaire. On en déduit un accroissement abusif des coûts de fonctionnement (500 %, le coût a donc explosé), si aucune justification tangible ne peut être avancée. Dès lors le rôle de l’auditeur informatique est de rechercher le pourquoi et le comment des choses. Cette étude comparative peut aussi se faire avec l’observation de l’accroissement du nombre des utilisateurs. Une étude multicritères (nombre d’utilisateurs, coût, volumes d’information traités, éléments statistiques du système...) pourrait être faite selon le même principe. Elle pourrait mieux démontrer l’évolution et révéler les points faibles de gestion. Faisant suite à l’audit de ce centre, nous avons émis la recommandation suivante : « Il importe, d’une part, de réduire les coûts en identifiant les surcoûts générés par le suivi mensuel du budget par le responsable informatique et en les rectifiant et d’autre part, de revoir les besoins réels en terme d’états de sortie de listing (outputs listing) avec les utilisateurs ». En effet, lors des interviews des utilisateurs, nous avons découvert le stockage des listings fournis sans réelle utilisation. Ces documents ont été fournis « historiquement et systématiquement » par le service informatique, sans discussion et renégociation avec les utilisateurs.

100

L’audit technique informatique

Résumé du chapitre 4 Les principaux clients demandeurs d’audits informatiques dans les grandes structures sont, sans conteste, les Direction générale et Direction Informatique. Souvent, ce sont les mêmes types de missions qui sont demandés (les missions de type cycliques). Cependant, plutôt soucieux des investissements et de leur ROI (retour sur investissement), la Direction générale, quant à elle, mandate parfois des audits concernant la politique informatique engagée ou vis-à-vis de la politique d’acquisition, ou encore des audits relatifs aux finances de la fonction informatique. Ce chapitre détaille ces principes et fournit des exemples et des recommandations concernant ces types de missions. Ainsi, le dernier exemple exposé, avec deux graphiques, permet de détecter et de montrer aux lecteurs la non-cohérence de l’évolution des coûts par rapport aux volumes d’informations fournis aux utilisateurs. Il va de soi que ces informations intéresseraient au plus haut point une Direction générale.

FOIRE AUX QUESTIONS (CHAPITRE 4)

Question 1 : le cahier des charges est-il un document important pour l’auditeur ? Réponse : ce document est primordial pour l’auditeur. En effet, il permet de détecter l’adéquation des services demandés avec ceux fournis par une société mandatée ou fournisseur. Question 2 : pour un grand projet, quels sont les points importants à identifier dans un cahier des charges ? Réponse : dans un grand projet, un des points importants concerne la clarté des services demandés et le partage des tâches en un certain nombre de lots. Ce dernier processus permet de mieux identifier les tâches accomplies et les délais de livraison afin d’éviter les désaccords éventuels. Question 3 : est-il important pour un auditeur de savoir identifier un budget de fonctionnement et celui d’investissement ? Réponse : il est primordial de savoir dissocier ces deux types de budgets. Trop souvent, une mauvaise imputation alourdit à tort un budget d’investissement. En effet, ce dernier est amortissable

102

L’audit technique informatique

(du point de vue comptable), alors que celui de fonctionnement ne l’est pas. Question 4 : une diminution progressive des investissements informatiques est-elle bénéfique pour l’entreprise ? Que doit faire l’auditeur qui la détecte ? Réponse : la diminution progressive des investissements n’est souvent pas très bénéfique pour l’entreprise. En effet, ceci montre un intérêt décroissant des dirigeants quant au renouvellement des systèmes informatiques en général, et parfois en particulier des logiciels. Ceci est contraire à l’évolution rapide de l’informatique et de la technologie. Après vérification, si tel est le cas, l’auditeur doit tirer la sonnette d’alarme. Question 5 : la vérification des activités de gestion du projet est-elle du ressort des auditeurs ? Réponse : tout à fait, car les activités ainsi que les méthodes utilisées pour gérer les projets conditionnent la réussite de ces derniers. Dès lors, les auditeurs pourraient être amenés à vérifier le bienfait des activités et l’adéquation des méthodes entreprises par les responsables informatiques pour gérer les projets ou services.

CHAPITRE 5

Missions d’audit demandées par la Direction technique/informatique

Evidence… Qui ne demande rien, n’a rien proverbe anonyme

5.1. Audit sur l’utilisation des logiciels (utilisation, licences, piratage) Très souvent, au sein des PME et PMI, le nombre de licences des logiciels utilisés ne correspond pas au contrat avec l’éditeur du dit logiciel. Les raisons évoquées sont souvent des oublis de mises à jour, la croissance du nombre d’utilisateurs ou l’augmentation des coûts des licences (raisons économiques). Or, la loi est très sévère en cette matière, car cette situation est assimilée à un délit répréhensible. Le caractère délictueux est d’autant plus vraisemblable que les logiciels dits horizontaux sont utilisables par les PC banalisés, contrairement aux ordinateurs dédiés et programmés spécifiquement pour la production ou la gestion de production. Pire encore, on constate souvent un piratage des logiciels ou des changements de paramètres des logiciels d’évaluation téléchargés à titre gracieux. Car pour les éditeurs, les clauses sont très strictes.

104

L’audit technique informatique

En voici un exemple, extrait d’un contrat d’utilisation de logiciel associé au contrat de vente : Droits et limites Par la présente, l’entreprise X offre à l’utilisateur un droit d’utilisation du logiciel, non exclusif et non transférable, en respect des conditions suivantes. a) Droits L’utilisateur peut installer et utiliser une copie du logiciel sur un seul ordinateur ; aucune autre copie du logiciel ne doit être faite excepté une de copie de secours. Cette licence logicielle ne peut être partagée ou utilisée simultanément sur des ordinateurs différents. b) Exception Linux En dépit des termes qui précèdent, section précédente, le logiciel exclusif à l’utilisation sur système d’exploitation Linux peut être copié et redistribué à la seule condition que ses fichiers binaires ne soient modifiés d’aucune manière que ce soit (sauf pour la compression et décompression des fichiers). c) Limitations Il est interdit d’effectuer une ingénierie inverse. L’utilisateur n’a pas le droit d’opérer une ingénierie inverse, de décompiler ou désassembler le logiciel, ou encore d’essayer d’obtenir par n’importe quel moyen que ce soit le code source. Il est interdit de séparer les éléments logiciels. Le logiciel dispose d’un brevet unique. Les éléments qui le composent ne doivent en aucun cas être séparés pour être utilisés sur d’autres ordinateurs ou de manière indépendante.

Missions d’audit demandées par la DTI

105

Il est interdit de louer le logiciel. L’utilisateur n’a pas le droit de louer sous quelque forme que ce soit le logiciel à un tiers. D’autre part, la loi sanctionne aussi fortement une personne utilisant une copie. Par exemple l’article L. 122-6 du Code de la propriété intellectuelle stipule que lorsque l’œuvre est un logiciel toute utilisation d’un logiciel non expressément autorisée par l’auteur ou ses « ayants droit » est illicite. Ainsi, si le délit pénal de contrefaçon lui-même est lié à la reproduction illicite du logiciel (ce qui implique qu’un simple utilisateur ne pourra voir sa responsabilité pénale engagée sur ce seul fondement), l’utilisation d’une copie illicite de logiciel devrait, en principe, être suffisante pour engager directement la responsabilité civile de cet utilisateur. Les sanctions financières peuvent aller jusqu’à plus de 76 000 euros (500 000 francs). De ce fait, le rôle de l’auditeur dans une mission d’audit des logiciels est de : – vérifier l’existence d’une documentation complète des produits utilisés ; – vérifier l’adéquation des produits utilisés ; – vérifier l’existence d’un planning de formation des utilisateurs ainsi que le respect de l’exécution de ce planning ; – vérifier l’existence des contrats d’utilisation de logiciels ; – vérifier que le nombre de produits installés correspond à celui décrit dans le document précédent ; – détecter les copies et les logiciels illicitement installés. Enfin, il est opportun de signaler que le respect de la législation est primordial, car parfois une seule sanction financière infligée peut ruiner ou mettre en difficulté les petites PMI et PME.

106

L’audit technique informatique

5.2. Audits de qualité de services et de l’informatique horizontale Le CLUSIF (Le Club des utilisateurs informatiques en France) a publié des chiffres alarmants au niveau de l’Hexagone. En effet, d’après leur récente enquête concernant 608 entreprises et administrations (résultats publiés en 2004), les chiffres relatifs aux risques encourus, aux divers accidents et/ou attaques réalisées permet d’établir la liste suivante : – accidents d’ordre interne : 37 % ; – accidents d’ordre externe : 13 % ; – virus ou vers informatiques : 67 % ; – attaques ciblées : 7 % ; – atteinte à l’image de la société ou du service : 2 % ; – chantages ou fraudes : 1 %. Si l’on additionne les accidents d’ordre interne et externe, on obtient le chiffre de 50 %, ce qui montre l’importance de l’exploitation et de l’utilisation des ordinateurs ainsi que la qualité des services des systèmes. Quant aux derniers chiffres concernant les problèmes de virus et des attaques, nous les traitons ultérieurement. Dès lors, il est opportun d’appréhender d’une part, la qualité de service des systèmes liée à leurs performances et d’autre part, à la mauvaise utilisation et exploitation des produits logiciels horizontaux de l’entreprise. 5.2.1. La qualité de service des systèmes La qualité de service ne peut se concevoir sans une surveillance assidue des systèmes et l’existence de relevés d’incidents. Ces derniers, recensés et complétés au fur et à mesure, forment le journal des incidents. Outil de travail quotidien des exploitants de calculateurs, ce journal révèle des informations intéressantes pour l’audit informatique lors des missions intermittentes.

Missions d’audit demandées par la DTI

107

Un recensement systématique, une centralisation des informations et une consolidation auprès d’un service de statistiques permettraient de dresser des tableaux de bord de suivi de la qualité de service des systèmes informatiques de l’entreprise, à l’échelon local, voire national si la société possède plusieurs unités de calcul, serveurs ou de sites de traitement géographiquement disparates (filiales, agences locales de représentation...). Les pages suivantes donnent un exemple de suivi d’incidents et de qualité de service des systèmes. Ces éléments sont : – le journal des incidents qui peut se définir comme un document de base où l’on relève quotidiennement les événements dans le but de surveiller le système ou le serveur et d’établir les statistiques ; – deux exemples de tableaux de bord décrivant les domaines observés (systèmes informatiques par application) ; – un graphique récapitulant la qualité globale du service en temps réel. REMARQUE.– Par principe déontologique, nous ne fournirons ni les noms des systèmes informatiques, ni ceux des applications. Le « système A » désigne un gros serveur de type IBM ou DPS8 de Bull. Les « systèmes B ou C » désignent les ordinateurs de type Escala de Bull ou HP 9000. Les chiffres ont été élaborés et récoltés durant plusieurs mois et nous ont été fournis lors de l’audit. Le sigle « TMBF » signifie : temps moyen de bon fonctionnement. A partir des journaux d’incidents et des statistiques d’exploitation du centre, le responsable système a pu relever les éléments et établir les deux tableaux de bord suivants : – le premier concerne la QoS (Qualité de service) globale pour les utilisateurs en temps réel et la QoS globale des calculateurs ; – le deuxième concerne la QoS des interventions des constructeurs et les indisponibilités détaillées des trois ordinateurs.

108

L’audit technique informatique

5.2.1.1. Tableau de bord n° 1 Ce tableau de bord se compose des deux éléments ci-dessous. 5.2.1.1.1. Qualité de service global pour l’utilisateur temps réel Principaux indicateurs

Valeur du mois

Taux d’indisponibilité

1,08

Moyenne des 6 derniers mois 1,09

TMBF Utilisateur (en heures)

96,40

99,30

Nb. Moyen d’arrêt/utilisateur

1,91

1,92

Durée moyenne d’un arrêt (en heures)

1,05

1,10

Tableau 5.1. QoS global pour l’utilisateur

Dans les termes anglo-saxons on retrouve souvent le mot « MTBF » (Mean Time Between Failure) (voir lexique). D’une certaine manière, le TMBF est le complément du MTBF. En effet le TMBF est égal au temps total d’observation moyen retranché du MTBF. 5.2.1.1.2. Qualité de service global des calculateurs Principaux indicateurs

Valeur du mois

Moyenne des 6 derniers mois

Taux d’indisponibilité

0,12

0,13

TMBF Utilisateur (en heures)

3,62

2,62

Nb. Moyen d’arrêt/utilisateur

0,27

0,38

Durée moyenne d’un arrêt (en heures)

1,92

1,64

Tableau 5.2. Equipements centraux ayant engendré des arrêts complets pour tous types d’utilisateurs

Missions d’audit demandées par la DTI

109

5.2.1.2. Tableau de bord n° 2 Les éléments indicateurs ci-dessous déterminent la qualité de service des constructeurs et fournisseurs ainsi que le taux d’indisponibilité des ordinateurs. Ils constituent le tableau de bord n° 2. 5.2.1.2.1. Qualité de service d’intervention Les chiffres du tableau ci-dessous concernent toutes les interventions et tous les SAV. Valeur du mois

Moyenne des 6 derniers mois

Délai moyen de relevé (en heures)

7,98

7,42

dont délai d’intervention

6,58

5,42

dont délai de réparation

1,40

2,00

Taux de dépassement des délais (%)

38,54

23,86

Taux d’indisponibilité par rapport au contrat

0,05

0,07

Nombre d’interventions par système observé

0,45

0,64

Principaux indicateurs

Tableau 5.3. Qualité de service d’intervention

5.2.1.2.2. Taux d’indisponibilité des systèmes Pour le système A, le décompte des temps moyens d’arrêts résulte de l’application d’une pondération par application traduisant la dégradation globale du service. Pour les systèmes B et C, seuls les arrêts complets des systèmes sont décomptés. Cette différence est due au fait que pour les deux derniers ordinateurs, on ne travaille qu’en mono-application.

L’audit technique informatique

Système

Valeur du mois

Moyenne des 6 derniers mois

A

2,02

1,38

B

0,24

0,47

C

0,02

0,30

Tableau 5.4. Taux d’indisponibilité des systèmes

Enfin, en comptabilisant par poste d’utilisateur et par mois, le schéma suivant permet de bien voir l’évolution annuelle du taux d’indisponibilité (en %) et du TMBF (taux moyen de bon fonctionnement) en heures. La qualité globale du service temps réel de tous les produits et applications confondus est inversement proportionnel aux taux d’indisponibilité. Dans le schéma ci-dessous, la première série présente les valeurs mensuelles, la seconde représente la valeur de la moyenne glissante du semestre. Ces chiffres étaient recueillis par le responsable système durant une année civile d’exploitation en tenant compte aussi des indisponibilités dues à la maintenance des ordinateurs et des upgrades (mise à jour) des systèmes d’exploitation. De ce fait, les taux paraissent élevés. Mais l’objectif est de rester en dessous de 20 %.

Taux d'indisponibilité d'utilisateurs 25 20 15 10 5 0 Av ril

Fé v

D éc

O ct

Série1 Série2

Ao ût

Ju n

Taux en %

110

Mois

Tableau 5.5. Taux d’indisponibilité d’utilisateurs

Missions d’audit demandées par la DTI

111

Fort de ces informations, le rôle de l’auditeur est de : – s’assurer que les temps d’arrêt des utilisateurs n’ont pas d’impact sur le personnel et les clients de l’entreprise ; – contrôler que les durées moyennes des arrêts des machines ainsi que le nombre d’arrêts restent dans la limite des chiffres fixés dans le contrat de maintenance du sous-traitant ; – vérifier que l’objectif du taux d’indisponibilité est respecté. 5.2.2. Audit de l’utilisation et de l’exploitation des logiciels horizontaux Compte tenu de l’existence sur le marché de nombreux logiciels prêts à utiliser, le développement ad hoc des produits dédiés à une PME ou PMI est de plus en plus rare, surtout en ce qui concerne la gestion administrative, la comptabilité et autres produits de gestion. Dès lors, il suffit que le responsable de l’entreprise et/ou son responsable informatique identifient bien leurs besoins puis choisissent les produits existants et adéquats du marché (concernant le processus de choix, voir ci-dessous). Ceci est d’autant plus vrai pour les progiciels de gestion et/ou d’aide de décision appelés souvent des PGI (produits gestion intégrés) ou des ERP (Entreprise Resources Planning). Ils sont souvent identifiés comme des logiciels ou produits horizontaux. Historiquement par exemple, les progiciels de gestion de paie ont vu le jour dans les années 1970 et furent vendus avec une documentation complète, voire même avec un programme de formation et une assistance technique (d’où la notion de package avec le terme « progiciel »). Au cours des années 1980, d’autres fonctionnalités et modules ont été créés et vendus pour faciliter les tâches des DRH ou de leurs équipes (modules de gestion individualisée pour la formation des employés et pour le recrutement...). Dès les années 1990, avec le rôle accru des DRH et l’avènement des micro-ordinateurs, l’intégration des modules précédents dans un grand progiciel a été perçue comme nécessaire et profitable. Ce phénomène, avec la conjonction du développement fulgurant des nouvelles technologies, a amené un nouveau concept celui du « ERM », Employee Relation Management (ou gestion de la relation employé) à

112

L’audit technique informatique

partir de l’année 2000. Un bon nombre d’éditeurs proposent même la possibilité de gestion via le Web, permettant ainsi une consultation à l’extérieur de l’entreprise. Citons quelques vedettes du marché : ARCOLE RH (de l’éditeur ARES), ORACLE HRMS (d’ORACLE), My SAP RH de SAP... Du point de vue gestion commerciale, le progiciel CAMPUS (Computer Aided Management and Production Unifying System) est reconnu pour ces modules intégrés de gestion des achats, des ventes, de la gestion des stocks, de la facturation ainsi que la fourniture des éléments pour la comptabilité. Cependant, il faut savoir qu’il ne suffit pas d’acquérir un bon produit pour, qu’automatiquement, les problèmes informatiques et de gestion soient résolus. En effet, les audits pratiqués nous montrent souvent des faiblesses concernant le choix adéquat d’un progiciel pour l’entreprise ainsi que sur la formation des utilisateurs. De ce fait, le rôle de l’auditeur, en ce qui concerne l’utilisation et l’exploitation des logiciels horizontaux, lors d’une mission est de vérifier : – l’adéquation entre l’investissement et le besoin de l’entreprise ; – que la formation des utilisateurs vis-à-vis du logiciel horizontal est suffisante pour son exploitation optimum ; – le contrat de maintenance avec l’éditeur ou le fournisseur du produit et services ; – l’interfaçage avec les autres produits existants, par exemple le logiciel de comptabilité…

5.3. Audit d’un grand centre de serveur ou d’un Business Intelligence Centre Pour illustrer nos propos précédents, nous donnons des exemples extraits d’un audit d’un centre de serveur. Ce dernier est dédié à des chercheurs pluridisciplinaires dans le domaine de la recherche pour l’amélioration des réseaux et des trafics. En voici la mission : ayant migré d’un centre classique de mainframe vers un centre de type

Missions d’audit demandées par la DTI

113

serveurs, la Direction générale mandate un audit sur le fonctionnement de ce nouveau Business information Centre, moins d’un an après la migration complète. La lettre de mission est envoyée simultanément à la Division informatique et au responsable d’audit. S’apercevant que la requête est assez vague, ce dernier se réunit avec ses deux auditeurs pressentis pour la mission et propose de redéfinir le sujet avec plus de précision. Ainsi l’intitulé de la mission devient « audit de l’organisation, du fonctionnement et des risques du nouveau centre ». Cette proposition est envoyée à la Direction générale. L’acceptation est parvenue une semaine plus tard (avec un mot de remerciement et de félicitation) au service d’audit. Dans ce genre de mission, l’auditeur doit chercher à comprendre l’organisation des services, le rôle de chaque acteur dans cet environnement, et connaître les documents associés (qui pourraient l’aider dans sa mission). Ceci contribue à trouver les risques endogènes et exogènes du centre. Nous donnons un exemple pour illustrer cette démarche. A l’instar de toutes les missions, le responsable d’audit prévoit un planning avec ses deux auditeurs, comme suit (le nombre total de jours évalué est de 35 jours ouvrables) : – phase de pré-audit et de planification (16 %) ; – phase d’enquête préliminaire (24 %) ; – phase de vérification rapide (18 %) ; – phase de vérification ou réalisation de l’audit proprement dit (26 %) ; – phase de restitution et de rapport (16 %) comprenant : - la phase de rapport (8 %), - la phase de finalisation (8 %). Il convient de remarquer que la phase de pré-audit et de planification (16 %, 5 jours et demi environ) a été un peu plus conséquente par rapport à l’habitude. Ce fait est dû à la redéfinition de l’objectif et à la soumission de ce dernier à l’accord de la Direction générale. Il en est de même pour la phase de réalisation de l’audit proprement dit (26 %).

114

L’audit technique informatique

L’explication découle du fait de la nécessité de vérifier et d’auditer aussi bien le personnel interne, que les sous-traitants. Maintenant, focalisons-nous sur les outils et éléments d’investigation. 5.3.1. Les outils et éléments d’investigation Les outils des auditeurs sont principalement, en dehors de leurs propres méthodes, les documents du centre (dossier d’exploitation, fiches d’incidents, cahier de bord...) et les flow charts ou schémas de circulation des documents établis par eux-mêmes, lors de la mission. Ces schémas permettent ainsi de montrer d’une façon simple le fonctionnement du service et les tâches de chaque acteur ou participant d’un processus. Les autres documents usuels dans ces situations sont le planning général mensuel ou hebdomadaire, le cahier de bord (qui devrait être à jour) des ordinateurs serveurs, les relevés ou journaux d’incidents, le dossier d’exploitation. Ce dernier dossier doit permettre : – de connaître les procédures journalières ou hebdomadaires utilisées ; – d’exécuter les procédures et de connaître la marche à suivre en cas de panne, de reprise ; – d’ajuster les ressources physiques et logiques en service dégradé ; – de connaître les commandes automatiquement exécutées par le système ou la séquence des JCL (voir lexique). De ce fait, le rôle de l’auditeur est de : – s’assurer de l’existence des documents précédemment cités ainsi que de leur bonne tenue (dossiers à jour, éléments inscrits clairs et sans ambiguïté) ; – s’assurer que les plannings soient respectés, et que si un cas de dérapage se présente, il existe des solutions de repli, de reprise lors des défaillances des systèmes ; – s’assurer de l’existence des bonnes méthodes de travail.

Missions d’audit demandées par la DTI

115

5.3.2. Quelques résultats de l’audit Concernant l’organisation et le fonctionnement du nouveau centre, aucun problème majeur n’a été détecté. En effet, le redéploiement des informaticiens internes a été bien planifié (par la Direction générale et la Division informatique) et exécuté. Le responsable et quatre autres personnes restent dans la division pour la supervision, la coordination, les permanences et les relations avec la société de sous-traitance d’infogérance. Sur les quinze autres personnes, cinq postes n’étaient pas remplacés après les départs en retraite et les autres personnes étaient redéployées dans les services administratifs et dans les unités de recherche pour les travaux de soutien et d’assistance aux chercheurs. D’autre part, le contrat étant assez « bien ficelé », il n’y a pas de problèmes importants détectés lors de l’audit effectué au sein de la société d’infogérance et auprès de leur personnel détaché. En résumé, nous présentons quelques points intéressants détectés ainsi que les recommandations associées qui suivent. Points forts : – redéploiement réussi des informaticiens d’un centre de mainframe à la nouvelle structure d’un centre de serveurs ; – contrat d’infogérance « bien ficelé » avec une société externe, cependant ce contrat ne met pas l’accent sur la sécurité d’accès aux informations du centre. Points faibles : – il manque une charte ou un document définissant la politique d’utilisation des ressources et la définition des responsabilités des différents acteurs ; – le contrôle de sécurité d’accès aux informations et aux intrusions n’est pas bien contractualisé. Ainsi, à titre d’illustration, nous proposons deux paragraphes extraits du rapport d’audit : « Il est à noter que la migration progressive d’un centre classique de mainframe vers un centre serveurs de type

116

L’audit technique informatique

d’infogérance a été réussi. Les informaticiens ont été bien redéployés grâce à une formation planifiée et à la redéfinition des rôles. Les personnes parties en retraite ne sont plus remplacées, mais une compensation budgétaire est affectée à une sous-traitance externe ». Pour ce qui concerne les points faibles, nous avons émis les deux recommandations suivantes. Première recommandation : « Etant un centre de recherche pluridisciplinaire et internationale, il serait souhaitable d’établir une charte ou un document définissant la politique d’utilisation des ressources et la définition des responsabilités des différents acteurs ». Le document pouvant être établi suivant le plan suivant : – objectif de la charte ; – contexte général ; – utilisateurs et partenaires ; – droit du centre Business Intelligence Centre (BIC) : 1) le BIC possède le droit de spécifier les systèmes, les logiciels et les bases de données utilisés par le centre de recherche ; 2) il peut refuser toute introduction des systèmes ou nouvelles technologies non cohérents avec la mission du centre de recherche, sa politique ou à l’encontre des droits nationaux et européens ; 3) il peut prendre des mesures administratives, disciplinaires et/ou d’actions légales pour assurer sa politique et sa mission ainsi que le respect des droits nationaux et européens. – droit des utilisateurs ; – responsabilités des utilisateurs. Deuxième recommandation : « Le contrôle de sécurité d’accès aux informations et aux intrusions n’est pas bien contractualisé. Il serait

Missions d’audit demandées par la DTI

117

souhaitable de réactualiser le contrat d’infogérance en ajoutant les éléments détaillés ci-dessous ». La société chargée de l’infogérance devrait mettre en œuvre tous ses moyens pour : – prévenir et détecter les intrusions illicites ; – filtre les accès via le Web ; – posséder les outils d’évaluation des vulnérabilités d’Internet, des systèmes scanners et des wireless scanners ; – posséder les outils d’évaluation et de filtrage des spams concernant les mails ; – renforcer la protection des desktops et des serveurs ; – pratiquer le concept de security management en fournissant des modules de surveillance et de reporting. D’autre part, tous ces préalables n’auront aucun sens s’il n’existe pas un bon encadrement et une bonne équipe. En particulier, la compétence de l’équipe interne doit être prouvée pour gérer la soustraitance et les contrats externes. Enfin, il importe de savoir que souvent le processus d’audit d’un centre BIC ou de serveurs nous amène parfois à pratiquer l’audit des ressources humaines de l’entreprise, qui sera développé dans la section suivante.

5.4. Audit des ressources humaines Des différents types d’audits, un des plus délicats est sans conteste l’audit des ressources humaines. En effet, il met en lumière l’inadéquation de la personne vis-à-vis de son poste, sa démotivation, voire parfois son manque de compétence. Dans notre contexte d’audit informatique, nous ne cernons que les ressources humaines concernant l’utilisation, l’exploitation et/ou le développement du système d’information de l’entreprise. Un auditeur peut fonder son travail sur ces trois hypothèses, concernant l’inadéquation du couple objectif/moyen :

118

L’audit technique informatique

– une mauvaise connaissance ou utilisation du système contribue à un rendement médiocre ; – une mauvaise exploitation du système informatique peut amener à ralentir la capacité du système ; – un mauvais développement contribue à une maintenance difficile ainsi qu’à un probable surcoût. L’objectivité de l’auditeur est primordiale. Il ne doit pas mettre mal à l’aise le service audité. Il n’a pas pour rôle de dénigrer, ni de conseiller de mettre à l’écart ou d’évincer quelqu’un. Ce n’est pas sa mission. Il relate les faits et les disfonctionnements constatés « les faits, rien que les faits ». Il est à remarquer que dans bon nombre de PME et PMI, ce sont souvent des anciens qui « informatisent » leurs services. De l’état « utilisateur », ils sont passés à « informaticiens maison » de par leur connaissance approfondie de la structure et de l’histoire de l’entreprise. Bien entendu, leur savoir est parfois complété par quelques stages de formation rapide. Un autre cas, à l’inverse, concerne les informaticiens professionnels recrutés ultérieurement (après la mise en place des systèmes), mais connaissant moins l’entreprise. Cela peut être source de problèmes, car ils sont souvent boucs émissaires ou cibles de critiques lorsqu’il existe des problèmes informatiques ou lorsque les délais de réponse du système d’information sont trop longs... La formation et l’information sont les deux piliers de la motivation du personnel en général et des informaticiens en particulier. Le personnel technique ne peut se contenter de quelques séminaires, il doit avoir une formation adéquate et étalée dans le temps en fonction de l’évolution du matériel et des logiciels. Sans cela, sa compétence deviendra vite obsolète et la motivation s’estompera peu à peu. La formation doit être complétée par l’existence dans l’entreprise d’une documentation ainsi que de revues à jour. Avant de détailler quelques-uns des rôles de l’auditeur, il importe de savoir quels sont les éléments déclenchant une demande éventuelle

Missions d’audit demandées par la DTI

119

d’un audit de ressources humaines par la Direction générale ou par une direction de production. En effet, il n’y a pas de fumée sans feu comme dit un vieil adage. La liste ci-dessous, loin d’être exhaustive, est néanmoins significative des éléments souvent cités par la Direction : – retard des traitements des commandes via l’informatique ; – états des listings non conformes aux états de stock ; – états des listings non conformes aux documents comptables (qui peuvent être générés par un autre logiciel) ; – discordance entre les informaticiens et les utilisateurs ; – turn over important du personnel informatique. Des constats précédents, on peut déduire les rôles de l’auditeur : – vérifier l’existence d’un contrat de travail adéquat pour le personnel du service informatique ; – vérifier l’existence d’organigrammes clairs et précis ainsi que la définition des fonctions (ou en anglais terms of references) ; – vérifier l’existence des clauses relatives à la non concurrence, à la fidélité, à la déontologie et au secret professionnel ; – vérifier l’existence d’un plan de formation adéquat ; – vérifier l’adéquation des formations demandées vis-à-vis des besoins concernant l’utilisation du système informatique et/ou des logiciels ; – vérifier ou sonder la motivation du personnel. En outre, il peut aussi : – s’assurer de la compétence des agents (en relation avec le plan individuel de formation et les appréciations annuelles) ; – s’assurer que le turn-over n’est pas excessif, qu’il existe une politique du personnel correcte (politique de recrutement, de carrière, de rémunération) ; – s’assurer de l’existence d’une politique d’horaires cohérente (équipes en exploitation normale ou en brigade, pour une permanence...) ;

120

L’audit technique informatique

– s’assurer que seules les personnes concernées et autorisées sont dans la salle machine ou des serveurs ; – s’assurer que les précautions concernant le personnel en soustraitance ou temporaire sont prises. Résumé du chapitre 5 De par sa nature, la Direction technique/informatique émet plutôt des requêtes pour des missions plus spécifiques et plus techniques. De ce fait, les audits tels que ceux concernant la qualité de service, l’utilisation des logiciels ou l’exploitation des centres serveurs, sont les plus fréquemment demandés. Soucieuse de son personnel technique, cette Direction pourrait aussi demander l’audit de ses ressources humaines. Ainsi l’auditeur devrait s’assurer de la compétence de ces personnes aussi bien à travers leurs manières d’exploiter les systèmes et/ou logiciels qu’à travers leur formation continue. Cependant, il n’en demeure pas moins qu’un turn-over anormal démontre souvent l’inadéquation de l’affection des ressources et/ou l’existence d’un malaise au sein d’une unité informatique.

FOIRE AUX QUESTIONS (CHAPITRE 5)

Question 1 : en ce qui concerne un logiciel ERP de l’entreprise, est-il suffisant que deux personnes connaissent bien le produit ? Réponse : le nombre de deux personnes est certes nécessaire, mais pas tout à fait suffisant, un troisième utilisateur maîtrisant un logiciel de type « Entreprise Resources Planning » serait préférable. En effet, on observe souvent dans les PME et PMI que la deuxième personne connaissant le produit tombe parfois malade alors que c’est cette personne qui remplace le titulaire pendant sa période de vacances. Question 2 : concernant un même logiciel, pourquoi n’a t’on pas un même rendement d’une PME à une autre (lenteur ou exploitation non optimale) ? Réponse : le rendement d’un produit mis en exploitation dépend de plusieurs facteurs, dont les deux principaux sont les suivants : Le premier facteur qu’un auditeur peut prendre en considération est le facteur des ressources humaines : les utilisateurs sont-ils bien formés au produit ? Y a-t’il une deuxième personne, voire une troisième connaissant bien toutes les fonctionnalités du produit ?

122

L’audit technique informatique

Le deuxième facteur concerne le processus de paramétrage des logiciels ainsi que du système d’exploitation-hôte. A titre d’exemple, nous avons découvert lors d’un audit, la lenteur d’un ordinateur exploitant un produit logiciel à cause de ses processeurs 16 bits : en effet le produit logiciel était développé avec une machine 32 bits pour des ordinateurs de dernier cri... Question 3 : quels sont les problèmes les plus couramment rencontrés avec les produits PGI (Progiciel de Gestion Intégré) ? Réponse : les problèmes souvent dévoilés par l’audit concernent souvent l’utilisation non optimale du produit, l’incohérence des données (due à des processus de saisies différents) et un bouclage insatisfaisant avec les données comptables de l’entreprise. Question 4 : quels sont les documents importants à vérifier si l’entreprise sous-traite ou fait appel à une infogérance externe ? Réponse : il s’agit sans conteste du cahier des charges et du contrat ou le ToR, « Term of Reference ». Question 5 : quel type de budget important doit-on vérifier dans un cas d’externalisation ? Réponse : le budget de sous-traitance est à vérifier avec soin. Mais, c’est surtout l’accroissement de ce type de budget qui doit être vérifié et justifié ! Par exemple, un accroissement de ce budget conséquent (disons entre 50 et 100 %) d’une année sur l’autre est source de problème. L’auditeur doit alors en chercher les raisons.

CHAPITRE 6

Problème de sécurité et audits associés

Evidence… Aucune sécurité ne peut se concevoir sans un plan. La sécurité est proportionnelle au temps et au budget investi pour établir et exercer ce dernier. L’auteur

L’information est une des ressources primordiales et constitue une partie vitale du patrimoine de l’entreprise. Le problème de sécurité devient donc de plus en plus crucial : sécurité pour la protection des patrimoines et des biens de l’entreprise, pour la protection contre les vols, les sabotages et l’espionnage industriel. Dans de nombreuses PMI ou PME, le poste de sécurité est inexistant parfois, soit par ignorance, soit par manque de crédit. Plus grave, certains dirigeants pensent que « les vols ou accidents n’arrivent qu’aux autres » jusqu’au jour où ils s’aperçoivent que leurs efforts de recherche ou d’investissement pendant des années sont anéantis en quelques heures, voire quelques minutes. Il existe bien souvent des remboursements par les assurances de ces biens volés ou détériorés mais qu’en est-il des préjudices moraux ou des avances technologiques perdues et irrécupérables ?

124

L’audit technique informatique

En effet de nombreuses de PMI ou PME travaillent dans des domaines très pointus pour la défense et la sécurité nationale (parfois même, elles ont des postes de surveillance institués par le ministère de la Défense) ou parfois réalisent plus de 70 % de leur chiffre d’affaires à l’exportation grâce à leur savoir-faire et leur leadership dans une technologie de pointe. N’est-il pas étonnant de savoir qu’en ce début même du XXIe siècle, il existe des unités de recherche d’un des centres parmi les plus prestigieux du monde qui ne possèdent pas, ou peu, de système de protection dans certains calculateurs des chercheurs. Parfois, ces derniers considèrent que la gentillesse et l’intégrité caractérisent toutes les personnes qui travaillent dans la recherche scientifique (chercheur ou non), et que l’espionnage industriel comme le nom l’indique, n’existe que dans l’industrie et non dans les laboratoires en amont du processus industriel ou dans les laboratoires de recherche fondamentale... Un autre exemple : rien qu’en 2003, bon nombre de sites Internet ont été attaqués par les programmes malveillants ou des virus de hackers totalisant une perte évaluée à quelques millions d’euros (perte des chiffres d’affaires, des fichiers clients ou de crédibilités). Sans rentrer dans le détail de chaque cas particulier de sécurité des entreprises, nous nous bornons à étudier les problèmes de sécurité pouvant avoir de l’impact sur l’information en général et plus précisément dans les domaines de matériels, de protections de fichiers et enfin dans celui du réseau, tout en précisant le rôle et les travaux des auditeurs. Commençons d’abord par le plan de sécurité.

6.1. Plan de sécurité de l’entreprise Une étude réalisée récemment révèle que plus de 60 % des entreprises ne possèdent pas de plan de sécurité et /ou dans lesquelles, les responsables informatiques ne sont pas tout à fait conscients des risques encourus. De nombreux interviewés considèrent que leur entreprise a un plan de sécurité dès lors qu’ils possèdent un programme

Problème de sécurité et audits associés

125

d’antivirus ou une sauvegarde hebdomadaire. Or ceci est nécessaire, mais non suffisant ! En fait, qu’entend t’on par risque ? Le risque peut se définir comme un « hasard » que l’on court d’une perte ou d’un dommage. Peut être aussi considéré comme risque, un évènement potentiel engendrant des pertes ou dommages. L’occurrence d’un risque résulte de l’application d’une menace sur une vulnérabilité (voir ce mot dans le lexique). Les menaces pourront être d’origines physiques ou logiques (destruction des fichiers, virus…). L’étude de 2002 révélée en fin 2003 par la CLUSIF démontre que 64 % des entreprises n’ont toujours pas défini de politique de sécurité des systèmes d’information pour contrer les risques. Bon nombre d’entreprises n’intègrent pas la continuité de service invoquant les raisons suivantes : – une politique SSI (sécurité des systèmes d’information) est ou semble onéreuse à mettre en place ; – les entreprises ont du « retard à l’allumage » ; – elles sont en phase de sensibilisation, la démarche s’amorce ; – la réaction de la politique est en cours. Et concernant les virus, un rapport annuel établi par GMV Conseil pour le compte de la CLUSIF dévoile une forte augmentation des infections des virus : de 14,8 % en 2001, le taux d’infection enregistré s’élève à 26,3 % en 2002. Les derniers chiffres pour 2004 montrent un taux supérieur à 30 %. De notre point de vue, une entreprise peut « se vanter » de posséder un plan de sécurité informatique, seulement si elle assimile et pratique une méthode reconnue de type MARION-AP (méthode d’analyse des risques informatiques et d’optimisation par niveau au stade de l’avantprojet) par exemple, ou encore la méthode MEHARI, méthode d’harmonisation des risques (issue de la précédente, mais moins complexe). Et seulement aussi, si elle sensibilise ses utilisateurs de systèmes informatiques et ses employés en général par une formation et une prise de conscience collective.

126

L’audit technique informatique

Cette méthode MARION possède un certain nombre de concepts, un guide de principes et des documents spécifiques ou fiches méthodologiques. C’est une démarche globale comprenant au moins six étapes, de l’analyse des risques à l’étape d’orientation et avant-projet en passant par les étapes d’expression du risque maximum admissible, à l’analyse des moyens de sécurité, à l’évaluation des contraintes et aux choix des moyens. La phase de choix des moyens est primordiale, en effet c’est à ce moment que l’on détermine le budget concernant la protection et la prévention nécessaire. A défaut d’appliquer une méthode commercialisée connue, nous proposons un processus de mise en œuvre d’un plan de sécurité en cinq étapes pour les entreprises (voir annexe 2). En l’absence d’un plan de sécurité informatique (coûteux et lourd à mettre en œuvre surtout pour un environnement de micro-ordinateurs) et pour parer aux urgences, nous préconisons aussi une check-list simplifiée de contrôle et de protection des matériels, de la documentation et de la sécurité (voir ci-après). Ces éléments pourraient être intégrés dans un plan d’action de la politique de sécurité de l’entreprise. 6.1.1. Plan de sécurité concernant la protection des matériels (surtout les serveurs) et de la salle de stockage correspondante Cette partie ne concerne que des services possédant des mainframes et/ou des mini-ordinateurs (cas des très grandes PME et PMI ou grande entreprise et administrations) et exploitant encore dans des salles classiques, des gros disk packs ou des streamers. Par exemple concernant un centre exploitant des ordinateurs pour le contrôle des flux aériens ou des centres de gestions des ordinateurs de type bancaire.

Problème de sécurité et audits associés

127

Accès de la salle : le lieu de stockage des ordinateurs ne doit pas être un lieu de passage non contrôlé (contrôle par badge, par code d’accès), il faut éviter à tout prix le va-et-vient des personnes étrangères au service. Protection de la salle contenant les serveurs de l’entreprise : – pour l’isolation calorifique et l’air conditionné, il faut surveiller de près les contrats d’assistance et de maintenance ; – pour l’alimentation électrique, tester et détecter les coupures, les fréquences de micro-coupures et garder le voltage constant en incorporant des stabilisateurs de courant, des onduleurs, et/ou l’alimentation secourue ; – protection contre l’incendie : vérifier l’existence des extincteurs, des armoires ignifugées, des consignes de sécurité et d’urgence, dans la mesure du possible, il faut préconiser un autre lieu de stockage des fichiers sauvegardés ; – problème de pollution et de poussière : par exemple, parmi une trentaine de facteurs de sécurité, la méthode MARION préconise une petite liste de questions concernant le micro dépoussiérage complet des sites informatiques, de leurs infrastructures (faux-planchers, fauxplafonds et plénum) et du matériel dans la salle d’exploitation. 6.1.2. Sécurité concernant les fichiers Il faut éviter la perte ou la destruction accidentelle des fichiers. De ce fait, il est toujours opportun de procéder à des duplications de ces derniers. Ces copies seront conservées en lieu sûr (armoire ignifugée, fermée à clé, et située dans un autre lieu de stockage). L’ensemble des duplications comprend une version de fichiers fils, pères et grands-pères suivant un planning de sauvegarde. Pour les fichiers programmes, prévoir des procédures de reprise et éventuellement des mots d’accès.

128

L’audit technique informatique

Enfin concernant la protection des informations : – pour la diffusion des résultats ou listings, seules les personnes intéressées doivent en être les destinataires ; – protection des données et des programmes vis-à-vis des personnes étrangères au service (surtout pour les disquettes et CD-ROM ou DVD dans l’environnement micro-ordinateur) ; – protection des postes de saisie des informations (surtout environnement des mini et des gros ordinateurs) : seules les personnes compétentes et autorisées ont le droit d’utiliser ces consoles (vérification par des badges et des mots de passe). Une check-list de sécurité minimum étant fournie, développons quelques cas spécifiques et déterminons les rôles des auditeurs informatiques.

6.2. Sécurité dans le domaine des matériels et de la documentation 6.2.1. Sécurité des matériels Dans le domaine de sécurité des matériels, on néglige souvent le lieu où sont stockés et exploités les matériels ainsi que la documentation technique servant à exploiter les machines et les mots de passe. Ceci est primordial en ce qui concerne les serveurs. A l’instar de tout atelier de production, un atelier, une salle informatique micro-ordinateur en pool, un centre de calcul ou une salle d’exploitation doivent être protégés en accès et les contrôles doivent être systématiques. Les mots de passe ne doivent être connus que par le personnel exploitant et par un groupe restreint (la hiérarchie directe par exemple). Ces passwords doivent être changés avec une fréquence déterminée et les consignes de sécurité doivent être respectées scrupuleusement. En dehors des éléments précédents, un centre de calcul (cas pour les gros ordinateurs, les mainframe ou mini-ordinateurs) doit posséder un

Problème de sécurité et audits associés

129

système d’insonorisation, de climatisation et d’éclairage adéquat sans compter l’ergonomie des postes de travail : des terminaux dédiés aux applications ou des terminaux intelligents, des micro-ordinateurs. Cependant nous conseillons que ces derniers soient démunis des possibilités des périphériques pouvant lire des supports externes (lecteurs des disquettes des CD-ROM, des clés USB) afin d’éviter les apports des virus ou des programmes malsains. Pour éviter les problèmes décrits ci-dessus, lors d’un audit informatique, les tâches de l’auditeur sont les suivantes : – contrôler l’existence des moyens de protection d’accès dans la salle machine. Ceci est encore plus crucial avec les micro-ordinateurs dans la majorité des bureaux d’une entreprise. On ne pense pas au problème de sécurité, jusqu’au jour où l’on s’aperçoit de la disparition de son outil de travail ou de la détérioration des fichiers ou du disque dur ; – contrôler l’existence des normes de sécurité et dans le cas où ces derniers existeraient (établis par le service de sécurité de l’entreprise), son rôle se bornera à vérifier l’application de ses normes ; – contrôler le respect des normes de ventilation et de climatisation préconisées par les constructeurs ou le respect des normes d’ingénierie établies par le bureau des méthodes informatiques. De ce fait, il doit vérifier les feuilles de relevés, le cahier ou le journal de bord des systèmes. Des outils tels que l’hydro-enregistreur, les thermomètres ou les documents des préconisations de sécurité et de protection des constructeurs doivent être consultés. 6.2.2. La sécurité de la documentation Aucune personne ne peut se vanter de connaître à fond un système d’exploitation et de faire fonctionner les machines (surtout en mini ou en mainframe). De ce fait beaucoup de documentation s’éparpille souvent d’une manière inconsidérée, or la conservation en lieu sûr des documents techniques est primordiale : dossiers vitaux pour l’exploitation, pour la compréhension des finalités des systèmes informatiques et des applications (appelées souvent aussi des applicatifs).

130

L’audit technique informatique

Documents certes utiles pour la bonne marche des systèmes, mais aussi nécessaires pour les éventuels saboteurs, pirates ou personnes malveillantes, d’où la nécessité absolue de l’existence et du stockage dans un lieu sûr de ces éléments vitaux. Prenons un exemple : lors d’une enquête, l’équipe d’audit a constaté que les documents ou dossiers techniques sont éparpillés et non indexés par application ou par fonctionnalité. Une recommandation comme la suivante peut alors être formulée dans un rapport. Recommandation : « Dans le but d’assurer la confidentialité de certaines informations, il conviendrait de veiller à limiter la diffusion de certains documents. Par ailleurs, la documentation nécessaire à l’exploitation des calculateurs doit être groupée, indexée et rangée dans des armoires munies d’un dispositif de fermeture renforcée pendant les périodes de non-utilisation. »

6.3. La sécurité des supports d’informations (les contenants) En dehors des disques fixes ou disk packs dont dispose un centre de calcul comme supports importants des gros ordinateurs ou miniordinateurs, il existe aussi des bandes magnétiques, des cartouches ou cardridges, des cassettes et des disques souples pour microordinateurs. La majorité des exploitants prennent des précautions pour les disques ou disk packs (habitude et préconisations des constructeurs, concernant les manipulations et les températures ambiantes...), mais concernant des supports sur bandes (utilisées de plus en plus rarement comme support d’archivage et de sauvegarde des informations) ou cartouches, on est beaucoup moins vigilant. Concernant ces derniers supports, nous n’émettons pas de conseils compte tenu de leur progressive disparition. Néanmoins, les règles ou précautions suivantes concernant les disk packs, les disques CD-ROM ou DVD doivent être suivies.

Problème de sécurité et audits associés

131

Précautions pour ces supports – Eviter les contacts directs sur la surface magnétique. – Remettre toujours les supports magnétiques dans leurs étuis ou pochette après utilisation. – Eviter l’exposition des supports magnétiques au soleil ou auprès de sources de chaleur. – Ne jamais « agrafer » un papier au-dessus avec un trombone. – La température de la salle de stockage doit être surveillée et le rangement des supports doit être fait dans les boîtes, verticalement, à l’abri de la poussière. – Enfin, notons que les CD-ROM ou disquettes s’usent (donnée d’un constructeur : après 50 millions de rotations), des copies ou des duplications sont donc nécessaires. En tant qu’auditeur, nous devons vérifier et soulever les nonconformités vis-à-vis des éléments précédents et émettre au besoin les conseils associés.

6.4. Sécurité dans le domaine des fichiers (les contenus, les données et programmes) La notion de sauvegarde et de protection des fichiers doit entrer dans les mœurs. Chacun de nous n’a t-il pas un jour effacé ou détruit un fichier par inadvertance nécessitant de ce fait de refaire une saisie partielle ou totale entraînant des pertes financières et de temps ? L’auditeur informatique doit être capable de prévoir et détecter amont ce type d’oubli ou de négligence (exemple : s’assurer l’existence des mots de passe et de la prohibition des commandes destruction…) et de conseiller la pratique des procédures sauvegarde.

en de de de

Il doit, en outre, proposer le nombre de versions à archiver, la fréquence de sauvegarde et fixer les périodes de restauration et d’essai des fichiers sauvegardés. En effet la négligence de ce dernier principe peut entraîner de mauvaises surprises.

132

L’audit technique informatique

On pourrait s’apercevoir le jour où l’on aura besoin des supports magnétiques sauvegardés que ces derniers sont illisibles ou incomplets (manque de certains fichiers importants ou des données tronquées...). En ce qui concerne les sabotages et les malveillances, les virus informatiques sont des armes redoutables. Heureusement elles sont identifiées et reconnues ces dernières années. Ces vers, virus ont pour but de détruire les fichiers programmes ou les fichiers de données, de pratiquer le processus de blocage de l’unité centrale ou de la mémoire centrale paralysant ainsi l’exploitation de l’ordinateur. Pour mieux connaître les fonctions illicites de ces vers et virus, le lecteur pourra se référer à l’annexe 3. En prenant en compte les éléments précédents, on peut en déduire le rôle que jouera l’auditeur. Rôle de l’auditeur Concernant ces problèmes de sécurité des fichiers vis-à-vis des risques de spoliation et des virus, le rôle des auditeurs informatiques est primordial. Ces derniers, à chaque mission de ce type, non seulement font des photos instantanées du service audité, mais doivent aussi signaler les risques encourus à la direction, donner des moyens ou conseils de prévention aux utilisateurs ou au personnel du service audité. Nous ne détaillons pas ici les sécurités concernant les gros systèmes ou mainframes (des grandes entreprises). En effet nous supposons que les constructeurs de ces outils proposent des moyens de protection adéquats et que les entreprises possédant ces systèmes informatiques disposent d’une équipe d’exploitants plus étoffée comprenant une cellule de sécurité... Par conséquent, concernant des PME et PMI, un auditeur doit fortement insister et conseiller une bonne prévention, une détection et des remèdes (pour parer contre les problèmes liés aux virus informatiques). Ainsi comme moyen de prévention et pour éviter la contamination, il est souhaitable de ne pas utiliser les programmes de provenance

Problème de sécurité et audits associés

133

inconnue et douteuse, par exemple des programmes dits de domaine public appelés dans le jargon des freeware. Son rôle consiste aussi à fournir des conseils tels qu’utiliser les programmes « vaccins » qui détectent les tentatives d’intrusion (exemple : les produits de Norton, Mc Affee, Virus Detective...) : – vérifier de temps à autre la taille, la date de création des fichiers et comparer les fichiers sur disques durs avec les fichiers sauvegardés ; – faire accepter par les utilisateurs la protection d’accès par mot de passe et la pratique du changement de ces derniers ; – faire demander au constructeur spécifique de chaque système les moyens de sécurité maximale, les programmes de détection de virus et de tentatives d’accès frauduleuses. Enfin, en tant qu’auditeur conseil, nous pouvons aussi essayer de sensibiliser les utilisateurs concernant les moyens de détection et les remèdes suivants. 6.4.1. Moyens de détection Il est opportun que les utilisateurs surveillent le ralentissement du système, la manifestation d’erreurs inexplicables avec un nombre particulièrement élevé de messages d’erreurs, la dégradation des performances du système, la diminution des mémoires vives disponibles, les accès aux périphériques fréquents (pour les microordinateurs, les voyants du lecteur s’allument de manière trop fréquente...) ou les disparitions des ressources fichiers (programmes ou données) et/ou de leurs incohérences. Enfin, pour les machines connectées au réseau, il faut être sensible aux lenteurs d’accès aux ressources communes (imprimante laser ou accès aux serveurs, à Internet...) ou l’observation d’un accroissement important de la charge réseau.

134

L’audit technique informatique

6.4.2. Remèdes Les remèdes sont les suivants : – séparer le système contaminé, le déconnecter du réseau local ; – détecter les fichiers contaminés et les détruire ; – utiliser les programmes anti-virus mais surtout utiliser les versions à jour ; – restaurer à partir des bons fichiers antérieurement sauvegardés. D’autre part, pour une meilleure collaboration et coopération, il serait souhaitable de prévenir toutes les personnes qui possèdent des systèmes informatiques reliés à nos éléments contaminés. Il importe aussi de porter plainte et prévenir le CLUSIF (Club de la sécurité informatique) pour enregistrer ces méfaits et mettre l’information à disposition de la communauté Web. Enfin, compte tenu du développement du Web et des réseaux, il est opportun de détailler les rôles de l’auditeur informatique vis-à-vis de la sécurité des réseaux et des applications fonctionnant sur le Web : sujets que nous aborderons plus loin.

6.5. Audit et sécurité dans le domaine du réseau Le développement des réseaux a pris un essor considérable depuis 25 ans. Au départ, seuls les grands constructeurs pouvaient offrir ces services avec leurs machines : Bull avec le DSA (Distributed System Architecture, IBM avec le SNA (System Network Architecture), DEC avec le DNA (Dec Network Architecture), mais avec le standard et les normes OSI (Open system interconnexion) de l’ISO (Internationnal Standard Organisation), les constructeurs de moindre taille, appliquant ces normes fournissent aussi leurs propres réseaux. Maintenant, on a davantage de possibilités de choix concernant les réseaux d’ordinateurs, il convient par contre d’être plus vigilant en matière de sécurité et de contrôle d’accès.

Problème de sécurité et audits associés

135

Dans ce chapitre, nous présentons successivement les normes de sécurité‚ des réseaux, les outils de contrôle de réseaux puis identifions les rôles des auditeurs sur les missions d’audit de type réseaux. 6.5.1. Normes de sécurité De par sa nature, un réseau informatique permet l’interconnexion de deux ou plusieurs nœuds ou stations de travail. La facilité d’accès ou d’entrée sur un serveur ou calculateur est réelle et de ce fait, il existe des risques d’intrusion dans les applications informatiques. Pour supprimer ces risques inhérents à sa fonction et assurer un certain niveau de sécurité, le réseau doit posséder des moyens d’identification, la faculté de restriction d’accès et la possibilité de transfert d’appel. Le logiciel de gestion doit être conforme aux normes FIPS (voir ci-dessus). 6.5.1.1. Identification de la ligne L’identification est la vérification de l’adresse caractéristique du point d’accès du réseau. Cette identification de la ligne doit être possible à travers l’ensemble du réseau : à travers le réseau intra X du demandeur (réseau dans lequel l’utilisateur est demandeur de connexion au réseau Y), à travers le réseau intra Y du demandé et le réseau supra X. L’identification nécessite donc au préalable un plan de numérotage cohérent au niveau national et des normes standard, des tables d’adressage et des softs (logiciels) de contrôle. Bon nombre d’outils existent sur le marché pour gérer et filtrer l’accès au réseau de l’entreprise. 6.5.1.2. Restriction d’accès En principe, les restrictions d’accès entraînent des cloisonnements très restrictifs, par exemple un groupe de terminaux ou de nœuds pour chaque type d’application. Ces terminaux ne peuvent se connecter aux autres applications de l’entreprise.

136

L’audit technique informatique

Mais une telle approche conduit à une gestion difficile et ne favorise pas la souplesse du réseau. Une option plus réaliste consiste à fractionner le réseau en sous-réseaux : N sous-réseaux de confidentialité correspondant à N niveaux de confidentialité, ou N sous-réseaux spécifiques correspondant à des domaines déterminés (exemple : domaine pour la facturation, pour la gestion technique, pour la comptabilité...). Un secteur de confidentialité permet l’accès à toutes les applications de ce niveau de confidentialité et à toutes les applications des niveaux de confidentialité inférieure. Ramené au matériel physique, un terminal habilité à un niveau de confidentialité donné ne peut accéder qu’aux applications de mêmes niveaux ou de niveaux inférieurs. 6.5.1.3. Transfert d’appel Le transfert d’appel doit permettre de transférer la communication destinée à un serveur ou calculateur vers un autre nœud : serveur ou calculateur du même réseau ou d’un réseau externe (problème de panne et de sécurité, notion de chemin non unique ou sécurisé...). Pour remédier à ce problème, on fait souvent appel au dédoublement des nœuds, des CCV (commutateurs de circuits virtuels) par exemple. Une autre méthode consiste à pratiquer la « triangularisation » ou encore un mélange de ces deux moyens. La notion de « triangularisation » est souvent mentionnée pour la sécurisation des nœuds (ordinateurs et/ou terminaux) : entre deux nœuds A et B importants, il devrait exister un nœud C à partir duquel on puisse joindre A et B. De ce fait, il y aura toujours un moyen technique d’atteindre A et B en cas de panne ou de coupure de la liaison qui relie directement A et B. L’ensemble des deux schémas suivants permet de bien mettre en évidence le principe de sécurisation. Dans le premier, le terminal C (normalement rattaché au centre C), voulant communiquer avec A1 ou travailler sur l’ordinateur A passe

Problème de sécurité et audits associés

137

par la liaison C-B puis B-A. En cas de panne de cette dernière (coupure ou dérangement), la communication sera interrompue ainsi que les travaux en cours. Ce problème sera résolu si l’on applique le principe de triangularisation ou une infrastructure maillée. Par contre la topologie en structure d’étoile est à déconseiller : car si le noeud central tombe en panne, toutes les communications seront interrompues. Dès lors, avec l’application du principe de triangularisation (cas du second schéma), en cas de dérangement de la ligne C-B (ou coupure), le terminal C pourra toujours se connecter au centre A ou communiquer avec les terminaux A1, A2 avec la ligne directe reliant le centre A et le centre C. A titre d’exemple, nous donnons les deux schémas simplifiés. Le premier concerne « l’avant » l’opération de triangularisation (moins sécurisant) et le second « l’après ». Terminal B Terminal A1

Terminal A2

Centre A

Centre B

Terminal A3

Terminal C

Centre C

Figure 6.1. Schéma initial du réseau

Le second montre le principe de triangularisation. Ce schéma montre la configuration après l’opération de sécurisation. Ainsi chaque nœud du réseau est relié au moins à deux nœuds voisins, garantissant ainsi deux chemins de communication.

138

L’audit technique informatique Terminal B Terminal A1

Terminal A2

Centre B

Centre A

Terminal A3

Terminal C

Centre C

Figure 6.2. Le principe de triangularisation

6.5.2. Systèmes garantissant la sécurité Une entreprise ne peut se prévaloir de posséder une sécurité pour son réseau que si elle possède des systèmes automatiques qui peuvent proposer les fonctions suivantes : – assurer la sécurité des échanges effectués sur le réseau X 25 par exemple (protocole du système Transpac) ou GFA (Groupe fermés d’abonnés, c’est-à-dire un réseau privé) ; – gérer et contrôler les accès aux commutateurs ; – gérer et contrôler les accès aux applications. Autrement dit, il faudrait tout un ensemble de systèmes qui possède les deux séries de fonctionnalités ci-dessous : – fonctions assurées pour la sécurité du réseau : - contrôle des droits d’accès de tout opérateur ou toute application engageant un dialogue à travers le réseau ; - authentification des correspondants (mutuellement) lors de chaque session ;

Problème de sécurité et audits associés

139

- vérification de l’intégrité des messages ; - journalisation centralisée des transactions des incidents et des sessions ; – fonctions pour la gestion des dialogues avec les commutateurs : - contrôle des droits d’utilisation des commandes ; - diffusion sélective des éditions vers les terminaux ou les applications suivant les types ; - d’édition (message de routine, édition différée...) ; - journalisation centralisée au niveau de la direction des commandes, des résultats et des éditions. 6.5.3. Centre de contrôle de réseau Un centre de contrôle de gestion appelé aussi centre de gestion a pour fonction d’assurer la supervision des réseaux. La supervision consiste à administrer le réseau en évaluant sa charge pour pouvoir suivre son évolution, à surveiller en temps réel l’état du réseau et de ses éléments (avec une visualisation graphique). De ce fait, un diagnostic précis pourra être fait sur chaque nœud du réseau et sur les équipements annexes tels que les modems, les multiplexeurs... Certains systèmes peuvent surveiller cinquante à cent nœuds. La signalisation d’un élément du réseau est instantanée sur le graphique, la ligne symbolisant la liaison entre les autres éléments change de couleur (en rouge généralement) ou scintille dès qu’une panne se matérialise. Les systèmes de contrôle de réseau proposés sur le marché sont de plus en plus sophistiqués. Cependant, la majorité des fonctions de contrôle ne semble pas être une absolue nécessité. La liste suivante donne un exemple de fonctions utiles.

140

L’audit technique informatique

6.5.3.1. Affectation des unités d’interface de réseau Le contrôleur doit pouvoir affecter un numéro d’appel à tout nouvel utilisateur ou l’utilisateur peut lui-même choisir son propre numéro d’appel. Ce numéro est alors vérifié par le contrôleur, puis inséré dans une table d’adressage. Un contrôleur doit pouvoir, à la demande d’un terminal, rechercher un hôte donné qu’il soit sur le même canal, sur un autre canal ou même sur un réseau local et jouer le rôle d’interface d’identifications entre les deux systèmes. 6.5.3.2. Contrôle du débit des unités d’interface du réseau Un contrôleur doit aussi être en mesure de régler indépendamment la vitesse de transmission de données de chaque unité d’interface en fonction du volume des transmissions à effectuer. 6.5.3.3. Test, codage et attributions des chemins On peut utiliser un centre de distribution de clés pour coder certains parcours entre nœuds. Le système doit être capable de tester les flux et attribuer un autre chemin ou voie en cas d’engorgement. (Rôle sophistiqué comme un commutateur téléphonique ou un PABX, un autocommutateur privé). 6.5.3.4. Configuration Le contrôle de configuration est sans doute la fonction de réseau la plus élémentaire. Il est donc conseillé de gérer des tables et des bibliothèques où seront stockées les adresses des nœuds, les vitesses de transmission et plus généralement toutes les informations utiles. Dans un contexte réseau, le rôle de l’auditeur peut être défini comme suit. Rôle de l’auditeur L’auditeur doit : – vérifier l’existence d’un centre de gestion et de son bon fonctionnement ; – vérifier toutes les potentialités du système et signaler les bugs (erreurs) de logiciel éventuels (à l’aide des journaux ou listings). En

Problème de sécurité et audits associés

141

effet, considérant souvent que globalement le module manquant n’est pas important (surtout si le constructeur le promet dans la version suivante), l’exploitant ne signale pas à sa hiérarchie mais regrette seulement le non-fonctionnement de ce module ; – s’assurer de l’existence de la maintenance adéquate de ce système (avec les contrats de maintenance et fiches de présence). 6.5.3.5. Entretien du réseau A l’instar des autres domaines de maintenance classique informatique, on distingue deux types d’entretien pour les équipements de réseaux : matériel et logiciels. 6.5.3.6. Entretien du matériel Dans ce domaine, on sépare encore en deux types : le préventif et le curatif. 6.5.3.6.1. Entretien préventif périodique Compte tenu du processus de standardisation croissant, il est souhaitable de choisir des fournisseurs qui suivent de très près les normes. L’indépendance éventuelle vis-à-vis du fournisseur est primordiale. C’est dire la primauté de la prévision et la possibilité de pouvoir choisir un autre partenaire si l’ancien fournisseur augmente abusivement les prix, ou si on observe une dégradation de la qualité du service reçu. C’est la notion de non-dépendance et le choix en fonction du critère rapport qualité/prix. Il est à remarquer que dans ce type d’entretien, la tarification pratiquée par les fournisseurs est plutôt forfaitaire. 6.5.3.6.2. Entretien curatif L’entretien curatif consiste à réparer des pièces tombées en panne à un instant donné. Le service de réseaux doit posséder un lot minimum de pièces et la formation du personnel est à négocier auprès des constructeurs. D’où la nécessité, pour le responsable de service d’établir un contrat avec les fournisseurs ou constructeurs. La tarification comporte le déplacement et les coûts suivant les éléments

142

L’audit technique informatique

échangés. De ce fait, il est intéressant de procéder à des appels à candidatures et des appels d’offres périodiques. 6.5.3.7. Entretien des logiciels Il convient de choisir au préalable et dans la mesure du possible des logiciels standard ou ceux qui respectent les caractéristiques suivantes : – l’utilisation des techniques de programmation standard ; – la conception modulaire ; – la qualité de la documentation ; – l’existence de hotlines. On peut choisir par exemple des softs qui répondent aux normes FIPS (Federal information processing standard). La maintenance des softs est à surveiller avec prudence : la diminution du degré de sécurité et la manifestation de nombreux effets inattendus après de petites modifications du logiciel sont, hélas, chose courante. En effet un réseau mis en place relie plusieurs systèmes entre eux et on ne peut prévoir le comportement ni la réaction totale des éléments constituants. La sous-traitance de la maintenance au constructeur est à préconiser si l’équipe interne de l’entreprise ne possède pas une formation très pointue ou n’est pas assez étoffée notamment si le logiciel est commandé et est écrit « sur mesure » par les constructeurs, fournisseurs ou sociétés de service. Par contre si l’équipe interne possède une bonne formation, des documents adéquats et le matériel performant, l’entretien interne présente de nombreux avantages : – solution rapide aux problèmes posés ; – concertation plus facile entre les gestionnaires du réseau et les utilisateurs ; – coût d’entretien réduit ; – disponibilité accrue du réseau pour les contrôles techniques et fonctionnels.

Problème de sécurité et audits associés

143

Pour les problèmes de maintenance, on peut affirmer que lors d’une enquête le rôle de l’auditeur est le suivant : – s’assurer de l’existence d’un contrat de maintenance ; – vérifier le suivi du matériel et le comportement des versions ; – vérifier que ce système de gestion ne peut être « emprunté » ; – s’assurer qu’au moins deux personnes de l’équipe savent utiliser à bon escient le système. Concernant l’acquisition du centre de contrôle de réseaux ou d’autres types de matériel, il peut être demandé à l’auditeur de vérifier pendant, ou a posteriori, le respect des procédures des marchés, des tests constituant les étapes suivantes (les durées sont données à titre indicatif) : – mise en ordre de marche (montage et fonctionnement) ; – vérification d’aptitude de bon fonctionnement (une semaine après) ; – vérification de service régulier deux mois après la vérification d’aptitude) ; – réception provisoire (une semaine au moins après la phase précédente) ; – réception définitive (une semaine après la phase précédente) ; – exemple de recommandation pour améliorer la maintenance externe. Recommandation : « Dans le but d’améliorer la performance de l’application, il serait souhaitable de surveiller les contrats de maintenance annuels et de refaire des négociations éventuelles avec le fournisseur avec les relevés des incidents et des résolutions des problèmes ». 6.5.4. Surveillance du réseau Pour la prévention des pannes et le bon fonctionnement du réseau de l’entreprise, les techniques de surveillance du réseau doivent être mises en œuvre. Ceci est d’autant plus vrai pour une société possédant un gros besoin de communication interne et externe, communication

144

L’audit technique informatique

entre gros ordinateurs ou mini-ordinateurs et éventuellement entre réseaux locaux avec les minis ou mainframes. La surveillance doit être appliquée‚ aux niveaux des nœuds de transit et de commutation ainsi qu’à la sortie de chaque élément constituant l’ensemble du « réseau ». Les principaux éléments à surveiller sont : – les matériels de transmission : - comptabiliser les collisions ; - comptabiliser le nombre de retransmission ; - vérifier les chemins, les circuits, les voies de transmission ; – les matériels de commutation : - vérifier les problèmes d’adressage ; - contrôler les tables de routage : - d’un terminal vers l’hôte (vice versa) ; - de l’hôte vers un autre hôte ; - des passerelles ; - des ponts ; – l’état des équipements : - l’état physique des lignes (ce service peut être demandé à France Télécom) ; - les fréquences d’utilisation et de maintenance ; - l’existence des normes de sécurité ; - l’existence des modes opératoires, d’instruction ; – les sources de retard : vérifier les canaux physiques et logiques (l’unité d’échange dans un environnement informatique). C’est donc le processeur d’entrée/sortie ou input/output exécutant des « programmes » de transfert de communication ainsi que l’affectation des ports ; – vérifier les charges : - voir le nombre d’utilisateurs et de programmes qui s’exécutent ; - vérifier la compatibilité des protocoles ; - vérifier le bon fonctionnement des signalisations d’erreur ; - s’assurer de la cohérence des tailles des paquets d’informations transmis et reçus, les dates de départ et d’arrivée de ces derniers ; - vérifier la disponibilité des nœuds (état des unités centrales, de tables éventuelles ; - les registres ou mémoires stockant l’état des files d’attente...).

Problème de sécurité et audits associés

145

Compte tenu de ces principes de surveillance du réseau, on en déduit les rôles de l’auditeur : – s’assurer que l’équipe réseau ou le responsable effectue toutes les opérations précédentes ; – s’assurer du bon état des équipements et d’un bon contrat de maintenance ; – s’assurer une fréquence normale de vérification et de surveillance des matériels de réseau ; – s’assurer de l’existence d’une structure maillée pour le réseau. Ce rôle est primordial pour une société‚ dite de forte communication (exemple : vente par correspondance, communication interne importante, fournisseur d’accès d’Internet...), en effet le réseau en panne paralyse l’activité totale de l’entreprise, diminue son chiffre d’affaire et ses marges. Enfin, il lui importe aussi d’évaluer les menaces, risques et les failles de vulnérabilités1 possibles des systèmes informatiques de l’entreprise. Il doit aussi s’assurer auprès des responsables la mise en œuvre des firewalls2, l’utilisation des outils de type SATAN3 et la protection des backdoors4.

6.6. Audit et sécurité des applications Web De nos jours, il est inconcevable qu’une entreprise ne soit pas reliée à la toile : communication, présentation de la société, prise et chargement (download) des programmes ou des pages via Internet… Cependant compte tenu du peu d’expérience des programmeurs et de l’insouciance, bon nombre de codes non sécurisés ont été développés pouvant exposer l’entreprise aux piratages et aux malveillances. Récemment en 2004, l’OSWAP (Open Web Application Security), un groupement de travail de fournisseurs de services de sécurité) a publié les fameux top ten des dix vulnérabilités des applications Web : – les requêtes incorrectes (la cohérence des requêtes n’est souvent pas vérifiée) ;

1. 2. 3. 4. Voir ces définitions dans le lexique.

146

L’audit technique informatique

– les contrôles d’accès non valides (trop d’applications donnent ou accordent des droits par défaut aux utilisateurs) ; – gestion de l’authentification et des sessions (le processus d’authentification aux applications Web est souvent négligé ainsi que la fermeture des sessions sous le contrôle seul de l’utilisateur) ; – le cross site scripting (bon nombre de failles d’une application Web permettent l’exécution des codes malveillants) ; – dépassement des tampons mémoire (manque de contrôle au niveau des chaînes de caractères ; ceci entraîne les attaques de buffer overflows : écrasement des pointeurs et d’adresses) ; – problème d’injections (l’application Web est servie comme une passerelle par le hacker ou pirates dont le but est d’attaquer le serveur) ; – messages d’erreurs (les messages renvoyés contiennent trop d’informations sensibles ; – chiffrement (utilisation des chiffrements de type maison et trop d’informations sensibles ne sont même pas chiffrées) ; – déni de service (les applications donnent droit aux utilisateurs d’accéder à trop de ressources) ; – administration non sécurisée (l’administration des systèmes est accessible via le Web). Pour conclure, le président de OSWAP prévoit, en 2004, une recrudescence du déni de service compte tenu du peu de mesures préventives implémentées dans les entreprises. D’autre part, confrontés dans un centre où il existe ces types de problèmes, nos expériences permettent de déduire les rôles qui suivent. Rôle de l’auditeur – Vérifier la cohérence des requêtes. – Vérifier l’existence d’une application pour l’authentification. – Vérifier l’existence des filtrages en input : l’existence des programmes de contrôle et/ou Firewall et l’inexistence des possibilités de gestion des systèmes via le Web ou en mode remote.

Problème de sécurité et audits associés

147

– S’assurer que les informations données en output n’étaient pas des informations sensibles. – S’assurer que le chiffrement est utilisé pour les informations sensibles en output. – Vérifier l’existence d’une classification des utilisateurs ainsi que de leurs droits correspondants. Il importe de savoir que ces types de vérification devraient être effectués par l’administrateur ou l’ingénieur système. Pour illustrer un audit dans ce type de contexte et spécialement d’un centre serveur, nous présentons le cas suivant faisant suite à des attaques.

6.7. Audit d’un centre à la suite de plusieurs attaques Ce cas illustre les démarches effectuées lors d’une mission dans un centre de serveurs concernant les pannes générées par des attaques, nous donnons un exemple d’audit concernant les problèmes et des recommandations pour la protection de ce centre. En voici le contexte : un centre de serveur de Web d’une société a été récemment mis en place (depuis un an et demi). Son principal rôle est de fournir des informations concernant les articles vendus par la société (une grande entreprise, nommée Belcar, négoce d’accessoires de tuning de personnalisation pour des automobiles) via la toile Web aux clients potentiels et aux commerciaux en déplacement (souhaitant montrer aux clients les articles et les prix pratiqués). Le serveur est géré par un jeune administrateur système qui attribue les privilèges en fonction de la catégorie d’utilisateur (liste définie par la Direction qui a donné priorité aux commerciaux). Depuis sa création, le serveur a subi deux pannes graves dues aux attaques. Ainsi deux dépannages ont été sollicités par la société. Cette dernière a payé un ingénieur système consultant externe pour radier les pannes et restaurer le serveur.

148

L’audit technique informatique

Soucieuce de l’avenir de ce centre, la Direction a commandité un audit externe indépendant (fait par notre équipe de consultants) pour exécuter une mission informatique de ce centre. En effet, d’une part, compte tenu des audits cycliques programmés, l’équipe d’audit interne n’a pu accepter la mission et, d’autre part, un défaut de compétence spécifique en est aussi la cause. Nous développons les éléments correspondants à chaque phase du processus d’audit et présenterons ensuite quelques recommandations extraites du rapport final d’audit. La durée globale de la mission est de dix jours ouvrables répartis de la manière suivante. 6.7.1. Phase de pré-audit et de planification (0,5 jour) Malgré notre charge de travail, mais compte tenu de l’intérêt de ce projet, nous avons accepté cette mission intéressante et valorisante. En effet l’objectif est de diagnostiquer, d’analyser et de trouver les failles (facilitant ces attaques génératrices de pannes) et d’émettre les recommandations pertinentes. Par expérience, pour ce genre de mission, il n’existe pas réellement de référentiel, car elle est très technique et exige plutôt un savoir-faire et une pratique en la matière. Compte tenu du background technique de nos auditeurs et de la demande de mission qui est bien ciblée, cette phase de pré-audit et de planification n’occupe que 5 % du temps total réparti pour l’ensemble de la mission. Une première planification permet d’identifier les tâches suivantes : – vérifier le processus de documentation de l’équipe de support ; – analyser les données disponibles relatives à ces pannes et les deux rapports d’incidents ; – vérifier le comportement des logiciels ; – simuler les attaques pour récolter les éléments ; – identifier les points faibles et les failles du système.

Problème de sécurité et audits associés

149

6.7.2. Phase de l’enquête préliminaire (2 jours) Cette phase est de même nature que pour les audits classiques, à savoir qu’elle est répartie en quatre sous-phases qui sont les suivantes : – l’analyse du sujet et définition de l’objectif (pour cette mission, le sujet ainsi que l’objectif sont sans ambiguïté) ; – la préparation (la documentation, l’élaboration des questionnaires...) ; – la prise de contact des personnes du service audité (équipe support et utilisateurs) ; – l’enquête préliminaire sur le terrain (sur les lieux du serveur). 6.7.3. Phase de vérification rapide (2,5 jours) Appelée aussi phase de vérification de survol, les bases de nos travaux s’appuient sur : – les premiers entretiens avec l’administrateur, quelques commerciaux et autres utilisateurs ; – l’existence et l’examen rapide de la documentation, des procédures et des travaux ou notations des deux dépannages externes. Le premier définit une panne de déni de service et le second, un problème de buffer overflow ; – les vérifications rapides de conformité. L’objectif de cette phase est double : d’une part, on devrait analyser et porter un jugement (à travers les interviews recueillies) pour vérifier si les symptômes correspondent bien aux dires des rapports d’intervention et d’autre part, les auditeurs devraient détecter les points forts et les points faibles pressentis. Ainsi, à la fin de cette phase, les auditeurs devraient dresser un tableau des points forts (PF) et points faibles (pf) apparents, dégagés d’après certaines preuves ou d’après l’intime conviction et que l’on s’impose professionnellement d’effectuer des vérifications plus approfondies plus tard.

150

L’audit technique informatique

Pour cette mission, nous avons détecté quelques points forts : – l’existence d’une documentation complète pour la gestion du serveur ; – l’existence d’une procédure de secours. Bon taux de fonctionnement du serveur (couverture du service rendu). Mais aussi quelques points faibles : – la documentation, quoique existante, ne semble pas à jour (concernant l’application qui a posé problème) ; – pas de procédure technique concernant les attaques ; – le niveau de compétence de l’équipe support (l’administrateur et son adjoint) semble disparate et insuffisante. 6.7.4. Phase de vérification ou réalisation de l’audit proprement dit (3,5 jours) Cette phase permet aux auditeurs de vérifier tous les éléments minutieusement et en détail afin de pouvoir apporter les preuves des points forts et de points faibles détectés ou pressentis des phases précédentes. Avec l’accord de la Direction, nous avons provoqué des pannes hors période d’exploitation. Ainsi lors de cette phase, nous avons pu confirmer les deux problèmes pressentis : – panne due au déni de services (DoS, voir lexique) ; – panne due aux problèmes de buffers overflow à cause d’une application nouvellement installée. Les vulnérabilités permettant des attaques de buffer overflow, sont inhérentes aux codes et sont dues généralement aux manques de vérification des bornes des variables. Ce problème est donc dû au module d’une application récemment installée. En effet, on a détecté que le champ qui demande l’utilisateur connecté à distance via le Web n’a pas de limite préconisée. Dans notre mission, nous vérifions aussi les divers documents mis à disposition

Problème de sécurité et audits associés

151

de chaque membre de l’équipe et, bien sûr, l’on vérifie avec le service développeur et avec les fournisseurs des logiciels, les dernières versions de la documentation. Puis grâce aux fiches d’incidents recensées, on vérifie le phénomène d’immobilisation du serveur et la raison. La durée totale d’immobilisation du serveur est de trois jours ouvrables et la perte financière est évaluée (malgré le rattrapage) à 12 000 euros de chiffre d’affaires. Quant aux niveaux de compétences disparates des membres de l’équipe, on vérifie les dossiers de formation, leurs backgrounds, l’administrateur, par exemple, n’avait pas de formation complémentaire en software, il était issu d’une formation hardware et électronique. Ainsi par ces méthodes, on obtiendra des preuves tangibles et indéniables. A la fin de cette phase, les auditeurs sont en mesure de préparer le prérapport avec des éléments complets issus de toutes les phases antérieures. 6.7.5. Phase de restitution et du rapport (1,5 jour) Dans notre mission, cette phase est en fait concrètement décomposée en deux sous-phases appelées : « phase de rapport » et « phase de finalisation ». 6.7.5.1. Phase de rapport L’écriture du rapport final (la version 0 que l’on envoie aux services audités) ne peut se concevoir qu’après l’exécution de toutes les phases précédentes. Néanmoins, l’élaboration du plan, de la structure et des grands pavés du pré-rapport (appelé le projet ou draft) peut être débuté beaucoup plus en amont et complété au fur et à mesure du déroulement des phases.

152

L’audit technique informatique

6.7.5.2. Phase de finalisation de la mission La présentation du projet et l’examen des incohérences ou points faibles, l’obtention d’un accord avec les audités, puis l’élaboration définitive des recommandations (l’application de ces dernières sera contrôlée ultérieurement grâce aux fiches de suivi) : – la rédaction du rapport définitif ; – la notification et l’envoi du rapport au service intéressé ; – l’établissement définitif des fiches de suivi et l’envoi de la lettre de clôture de la mission et la facturation. Pour cette mission d’audit du centre de serveur, nous avons émis quatre fiches de suivi5 : – la première concerne la mise à jour des systèmes et la nécessité de « patcher » avec les éléments fournis par les constructeurs ; – la deuxième est en rapport avec la formation du personnel de support ; une formation plus technique s’avère nécessaire pour parer à tous les problèmes de piratages et des hackers ; – la troisième concerne l’utilisation des outils de prévention tels que CyberCop ou ISS Internet Scanner (il est nécessaire se connaître par la suite si ce service applique la recommandation émise et utilise des outils pour la prévention) ; – la dernière concerne le suivi de les actions de re-paramétrage des routeurs, le filtrage des accès au serveur et la révision des privilèges des utilisateurs. CyberCop6 est un produit commercial qui revendique la réalisation de plus que 40 attaques de déni de service, incluant l’attaque Land, l’attaque Ping, et autres variétés d’attaques. Toutes les potentialités d’attaques disponibles de l’outil peuvent être exécutées simultanément ou individuellement. L’outil présente une description de l’attaque ainsi qu’une suggestion des contre-mesures. 5. Il est à remarquer que ces fiches de suivi serviront comme input pour une prochaine mission du même genre pour les auditeurs internes. 6. Pour plus d’informations concernant les outils et les techniques, veuillez consulter l’ouvrage : La sécurité sur Internet du même auteur aux éditions Hermès Sciences et Lavoisier.

Problème de sécurité et audits associés

153

ISS Internet Scanner : comme pour le cas de CyberCop, ISS Internet Scanner scanne les hôtes pour déterminer si ces derniers sont susceptibles ou favorables aux attaques de DoS. La version 6.2.1 contient 128 attaques, des éléments en commun avec CyberCop. ISS, Internet Scanner apparemment donne plus d’informations sur les attaques que CyberCop et il fournit un meilleur travail quant à la catégorisation des attaques par cible, par exemple pour les serveurs de DNS, les serveurs FTP, les Firewalls, etc. Néanmoins, ISS Internet Scanner fournit lui aussi des descriptions et des contre-mesures pour les divers types d’attaques de déni de service. Enfin, de cet audit et du rapport qui en a résulté, on retient les recommandations qui suivent. 6.7.5.3. Recommandation générale Les attaques de déni de service peuvent causer des dégâts importants et la protection est difficile. Par conséquent, il est urgent, pour les compagnies ou organisations possédant des systèmes critiques et sensibles connectés à Internet, de scanner et de vérifier leur réseau et systèmes. Elles devront être conscientes des risques et devraient minimiser les opportunités des attaques réussies des dénis de services. 6.7.6. Recommandations plus techniques Première recommandation : « afin de minimiser les attaques de type DoS ou DDoS (Distributed DoS), il serait souhaitable de : – concevoir les applications plus robustes (ou tester à fond avant la mise en place) ; – de limiter les bandes passantes ; – de garder à jour les systèmes d’exploitation avec des patchs des constructeurs ; – exécuter juste le nombre nécessaires de services et le trafic nécessaire ; – filtrer les adresses IP. Seconde recommandation : « afin d’éviter les problèmes de buffer overflow, il est souhaitable d’éliminer : – tous les logiciels qui sont vulnérables ;

154

L’audit technique informatique

– tous les ports et services correspondants ; – d’appliquer le patch du fournisseur et installer la dernière version du logiciel ». D’autre part, avant l’installation d’un nouveau logiciel, il serait souhaitable de déterminer sa sensibilité et tester sa vulnérabilité de buffer overflow. Troisième recommandation : « afin de se prémunir contre les attaques externes, il serait souhaitable de re-paramétrer les routeurs, de filtrer les accès au serveur et de revoir les privilèges des utilisateurs ». Avant de clôturer ce chapitre, nous résumons le bilan de cette opération au niveau financier : Pertes financières du CA générées par ces deux problèmes : 12 000 euros (4000 x 3 jours) Appel à des compétences externe pour les dépannages urgents : 2 600 euros Prestation pour un audit externe : 4 000 euros Le montant global s’élève à 18 600 euros HT sans compter une perte possible de l’image de l’entreprise et la nécessité de prévoir une formation plus pointue pour l’équipe de support interne. Enfin, il est à noter que les outils présentés précédemment ne seront pas totalement efficaces pour lutter et démotiver les pirates ou hackers s’il n’existe pas des moyens juridiques forts et dissuasifs que nous développons au chapitre suivant.

6.8. Sécurité et droit de l’informatique Les problèmes de sécurité de l’information, de la propriété et de la protection des logiciels, de la confidentialité, les relations contractuelles ont posé un certain nombre de difficultés avec les textes anciens dont l’interprétation et l’adaptation ne sont pas évidentes. Il y a quelques années encore aux Etats-Unis, la législation en vigueur pour régler les problèmes liés à la confidentialité et les vols de temps de machines

Problème de sécurité et audits associés

155

était celle sur les « sévices et injures envers autrui » et non la loi sur les actes de vol. Actuellement le droit américain a rétabli ce vide juridique. De par le monde, de nombreux fichiers nominatifs sont déviés de leur objectif de départ. On assiste aussi à des cessions ou des ventes de ces fichiers. En France, par la volonté du législateur, une Commission Nationale Informatique et Liberté (CNIL) a été créée pour lutter contre les abus et actuellement bon nombre de projets de lois vont être concrétisés. Cette commission comporte un certain nombre de sous-commissions spécialisées dans des affaires différentes. Il a fallu attendre jusqu’à 1985 (l’informatique existe depuis plus de 25 ans), pour qu’une loi protège les auteurs de logiciels et spécialement ceux de la microinformatique. La loi du 3 juillet 1985 définit la notion de contrefaçon et prescrit les sanctions applicables aux contrefacteurs. A cette époque, la lutte contre le piratage des logiciels est déterminée par les sept articles de cette loi. Actuellement les projets de loi plus adéquats concernant ce genre d’abus et les problèmes de hacking vont être mis en œuvre (voir aussi le chapitre 13 du livre Sécurité Internet et Management Anti-piratage, référencée en annexe). Mais la première loi qui réprime directement la fraude informatique est nommée « Loi Godfrain ». Elle date du 5 janvier 1988. En février 2004, un projet de loi a été adopté par le Sénat dont le but est d’adapter la loi Informatique et Liberté et enterre la distinction entre le public et le privé. Dorénavant, seules les données à caractères sensibles feront l’objet d’une déclaration à la CNIL. Revenons sur ces anciennes lois existantes et les amendes qui étaient exprimées en francs, il faut tenir compte du taux actuel d’un euro qui équivaut à 6,559 francs.

156

L’audit technique informatique

L’article 47 de la loi du 3 juillet 1985 dispose : « Par dérogation au 2 de l’article 41 de la loi 57-298 du 11 mars 1957 précitée, toute reproduction autre que l’établissement d’une copie de sauvegarde par l’utilisateur ainsi que toute utilisation d’un logiciel non expressément autorisée par l’auteur ou ses ayants droit est passible des sanctions prévues par ladite loi ». Désormais la recopie ou la reproduction d’un logiciel constitue un délit de contrefaçon. La seule exception concerne la reproduction d’une copie de sauvegarde pour l’usage personnel de celui à qui la licence est accordée. L’utilisation en dehors des conditions prévues par la licence constitue aussi un délit de contrefaçon (une utilisation qui n’a pas été autorisée par l’auteur ou ses ayants droit). La mise en œuvre des poursuites se fait par la saisie des contrefaçons, puis d’une assignation délivrée à l’intéressé soit devant le tribunal civil, soit devant le tribunal correctionnel. La saisie peut être descriptive ou réelle. Dans le premier cas, l’huissier ou le commissaire ont seulement à saisir deux exemplaires comme preuve. Dans le second cas, ils saisissent la totalité des exemplaires trouvés, néanmoins l’autorisation préalable d’un juge saisi par voie de requête est nécessaire. Au sens de la loi du 3 juillet 1985, les sanctions applicables au délit sont les mêmes que celles prévues par la loi du 11 mars 1957, qui donnent droit au plaignant de faire condamner le contrefacteur tant devant le tribunal civil que le tribunal correctionnel, en effet la contrefaçon en matière de droit d’auteur constitue un délit pénal. Les articles 425, 429 et 323 du Code pénal : Article 425 : toute édition d’écrits, de composition musicale, de dessin, de peinture ou de toute autre production, imprimée ou gravée en entier ou en partie, au mépris des lois et règlements relatifs à la propriété des auteurs, est une contrefaçon, et toute contrefaçon est un délit. La contrefaçon, sur le territoire français, est punie d’un emprisonnement de trois mois à deux ans et d’une amende de 6 000 francs ou de l’une de ces deux peines seulement.

Problème de sécurité et audits associés

157

Article 426 : est également un délit de contrefaçon toute reproduction, de représentation ou diffusion par quelque moyen que ce soit d’une œuvre de l’esprit en violation des droits de l’auteur, tels qu’ils sont définis et réglementés par la loi. Article 323 : concernant l’accès frauduleux dans tout ou partie d’un système de traitement automatisé de données, il est puni d’un an de prison et de 15 245 € d’amende. S’il en résulte une altération, soit des données contenues (suppression ou modification), soit du fonctionnement même du système, les peines prévues sont de deux ans de prison et de 30 490 € d’après l’article 323-1 du code pénal. Quant à l’atteinte volontaire au fonctionnement d’un système de traitement automatisé de données, c’est-à-dire le fait de le fausser ou l’entraver, est puni de trois ans de prison et de 45 735 € d’amende d’après l’article 323-2 du Code pénal. Le fait d’introduire frauduleusement de nouvelles données ou de supprimer ou modifier des données stockées est puni de trois ans de prison et de 45 735 € d’amende d’après l’article 323-3 du Code pénal. De plus, on peut demander l’application du droit civil permettant ainsi de rechercher la responsabilité de l’individu à l’origine de l’infraction afin qu’il puisse être condamné à des dommages et intérêts pour le préjudice subi par la victime en terme de perte de chiffres d’affaires, des commandes, de notoriété... Enfin, il convient de remarquer que la lutte contre les cybercriminels ne pourrait se faire sans la collaboration des techniciens et du législateur. L’auditeur informatique apporte son savoir pour détecter les points faibles et failles, les techniques de parade apportées par les ingénieurs compétents sont nécessaires pour détecter, contrer et piéger les pirates, mais les lois sont indispensables pour les punir et démotiver ces futurs crackers. Ce n’est qu’avec une collaboration étroite de ces acteurs que l’on peut espérer venir à bout de ces criminels en col blanc dans un proche futur... Dans un contexte juridique, il importe d’identifier les rôles suivants de l’auditeur.

158

L’audit technique informatique

Rôle de l’auditeur : – s’assurer d’une bonne politique logiciel de l’entreprise ; – s’assurer qu’il n’existe ni piratages ni contrefaçons pratiqués au sein de l’entreprise ; – s’assurer du respect des lois en vigueur ; – s’assurer de la déclaration auprès de la CNIL des données sensibles ; – vérifier l’existence d’une protection efficace des systèmes (via les réseaux et réseaux périphériques7) contre les pirates. Résumé du chapitre 6 L’information est une des ressources primordiales de l’entreprise et constitue une partie vitale de son patrimoine. Le problème de sécurité devient donc de plus en plus crucial. Les menaces et les risques encourus par l’entreprise sont multiformes et variés. De ce fait, un plan de sécurité est à conseiller pour toute entreprise soucieuse de son patrimoine informationnel et de ses systèmes informatiques. De plus, avec le foisonnement des applications sur le Web et de l’interopérabilité des systèmes et des réseaux, la surveillance et la prévention devraient être des tâches importantes. Lors des audits de sécurité, si les auditeurs repèrent un manque d’outils de détection d’intrusion ou de surveillance, il est de leur devoir de recommander l’utilisation de ces outils et de signaler les risques encourus à la Direction. Cependant, ces outils ne seront pas totalement efficaces pour démotiver les pirates ou malfaiteurs s’il n’existe pas des moyens juridiques forts et dissuasifs. De ce fait les auditeurs devraient aussi connaître un minimum d’éléments juridiques et quelques lois importantes. Ces derniers ont été évoqués à la dernière section de ce chapitre.

7. Voir définition dans le lexique.

FOIRE AUX QUESTIONS (CHAPITRE 6)

Question 1 : concernant une mission de sécurité et/ou de détection d’accès frauduleux aux systèmes, quels sont les documents qu’un auditeur informatique devrait prendre en considération ? Réponse : une procédure de contrôle périodique du responsable informatique sur les matériels et logiciels est nécessaire pour assurer la sécurité du ou des systèmes. Une équipe d’audit chargée d’une mission de sécurité et/ou de détection d’accès frauduleux aux systèmes doit disposer et considérer les documents suivants concernant la détection d’accès frauduleux : – cahier de bord des systèmes ; – dossier de saisie ; – plan de câblage des terminaux ou interfaces ; – cahier d’exploitation ; – procédure de dépannage. Concernant la sécurité du fonctionnement du système : en plus des documents antérieurs, il convient aussi de regarder le planning des révisions des éléments du centre de traitement, les contrats de maintenance et d’assurances.

160

L’audit technique informatique

Question 2 : concernant la sécurité de la documentation : pour assurer la sécurité d’exploitation, la continuité du service ou la détection des fraudes par les tiers, les auditeurs sont amenés à s’assurer de l’existence et du stockage dans un lieu sûr des dossiers vitaux pour l’exploitation et la compréhension des fonctionnalités et finalités des systèmes informatiques et des applications. Lors d’une enquête, l’équipe d’audit a constaté que des dossiers sont éparpillés et non indexés sur les fonctionnalités, quel type de recommandation devrait faire un auditeur ? Réponse : une recommandation doit être de bon sens, l’auditeur devrait préconiser un classement approprié en fonction des fonctionnalités et des modules d’exploitation. En plus, les guides d’utilisateurs doivent être facilement repérables et utilisables. Question 3 : concernant la sécurité des supports d’information : combien d’exemplaires de sauvegarde doit-on préconiser ? Réponse : il serait préférable d’en sauvegarder au moins deux versions, ainsi on aura le fils, le père et le grand-père (jargon informatique). D’autre part, il serait judicieux de vérifier aussi la fréquence des sauvegardes. Un compromis doit être trouvé. En effet, une fréquence trop élevée et non justifiée génère un grand nombre de supports physiques. Question 4 : concernant la sécurité d’accès aux fichiers : en théorie l’accès aux fichiers des applications ne pourrait s’effectuer que par le biais d’une commande ou d’un programme autorisé. Néanmoins, il peut arriver lors d’un dépannage que les informations présentes dans la mémoire centrale soient modifiées. Ces cas sont plus fréquents lors d’une intervention pour l’exploitation : modification de certaines priorités des tâches, mise à niveau du logiciel, modification des tables systèmes... a) En tant qu’auditeur, que devez vous contrôler ? b) Quelles sont les personnes à interviewer et les documents à vérifier ?

Foire aux questions

161

c) Dans un environnement de système de gestion de base de données, des informations stockées dans les fichiers classiques, comme celles qui sont intégrées dans une base de données, doivent être vérifiées par les auditeurs qui s’assurent de leur authenticité, intégrité, pérennité, confidentialité ainsi que de leur disponibilité. Comment définissezvous le terme « dictionnaire de données » et quels sont les éléments à vérifier ? Réponse : a) pour la mise à jour des fichiers des applications, l’auditeur doit vérifier qu’en aucun cas les utilisateurs non informaticiens ne puissent accéder aux fichiers et effectuer les lancements des travaux non tolérés dans le cahier d’exploitation ou les documents de base (dossier d’analyse, procédures de traitement...). Pour les mises à jour des fichiers systèmes par des informaticiens : – s’assurer que ces manœuvres sont consignées sur un cahier de bord, que l’ingénieur et/ou le responsable sont au courant et que tous ces travaux ont reçu leur approbation ; – recenser les statistiques de ces travaux. Un nombre élevé de ces opérations démontre la non-fiabilité du système et l’inadéquation aux besoins d’exploitation : un audit spécifique devrait se faire dans ce cas. b) Les personnes à interviewer sont les ingénieurs systèmes, le responsable informatique (ou système), l’administrateur de réseaux et les exploitants. c) Définition du dictionnaire de données : c’est l’inventaire de toutes les données de l’application. Ces dernières sont classées en trois types : – les données calculées résultantes des règles de calcul ; – les données paramètres ou constantes isolées ; – les données de la base : les données de diverses natures ou d’origines évolutives ou stables que l’on désire conserver dans la base. Question 5 : concernant la sécurité d’accès aux systèmes hébergeant des applications web. Lors d’une vérification, confronté à l’existence

162

L’audit technique informatique

du non-contrôle des droits des utilisateurs accédant aux systèmes (où se trouvent des applications Web) ainsi que la possibilité d’administrer via le Web, en tant qu’auditeur informatique, pouvez vous donner un exemple de recommandation dans un rapport ? Réponse : voici un exemple de recommandation possible. La sécurité d’accès aux systèmes via le Web montre certaines failles et vulnérabilités. Il importe donc de la verrouiller en enlevant la possibilité d’administration externe à travers le Web et de renforcer les contrôles des utilisateurs ainsi que de leurs droits correspondants ». Question 6 : concernant les attaques de déni de service via le Web, quels seront les conseils des auditeurs ? Réponse : les auditeurs pourront conseiller une politique de renforcement de la surveillance associée à l’utilisation des outils tels que CyberCop et ISS Interner Scanner. En effet, la pratique d’un scanning peut amener à détecter les tentatives d’accès frauduleuses des malfaiteurs.

CHAPITRE 7

Plans types et exemples de procédures

« Quand on est jeune, on échafaude un programme de travail dont on s’imagine qu’il durera toute la vie et résistera à n’importe quel cataclysme ». Graham Greene, écrivain anglais (1904-1991). Moralité... « Les principes et structures des programmes de travail sont parfois les mêmes, mais ces derniers doivent être spécifiques et établis en fonction de chaque objectif ». Henri Ly

Ce chapitre se distingue des autres par sa structure. Pouvant être considéré comme un guide, il est plutôt pratique, pragmatique, et opérationnel. En effet, il présente et propose des plans types facilement modifiables et utilisables pour les besoins d’un service d’audit afin d’établir un programme de travail ou pour l’élaboration des procédures. Ces éléments pourront être utilisés directement par les auditeurs. 7.1. Plan type d’un programme de travail Le plan type proposé est un programme de travail évoqué dans le chapitre 1 et concernant une mission informatique (focalisant sur le traitement et les outputs). Cette mission est commanditée par la direction (d’un opérateur des télécommunications en quête des éléments qui ont entraîné des problèmes de facturation. Le titre de la

164

L’audit technique informatique

mission s’intitule : « Limitation des factures erronées ». Cette mission a été demandée suite à des plaintes des clients (anomalies des factures, factures élevées…). Exemple de plan proposé pour un programme de travail A. Rappel des objectifs A.1. Modalité de traitement des états d’anomalies et des factures anormales A.2. Conception des états d’anomalies A.3. Impact des factures anormales sur les réclamations B. Etude des procédures – Mémorandum B.1. Organisation B.2. Traitement de l’information concourant à la facturation B.3. Les contrôles de la facturation : – les états de sortie ; – contrôle au centre de traitement (au niveau de l’exploitation informatique) ; – contrôle dans les agences ou filiales pour les grandes entreprises. B.4. Les réclamations : – au centre de traitement ; – aux agences. C. Principaux points forts et points faibles – Points forts et points faibles du centre de traitement. – Points forts et points faibles des agences. D. Vérifications – Contrôle de la facturation des gros clients. – Contrôle de la facturation des clients ordinaires. – Contrôle des autres prestations facturées. – Contrôle des anomalies des états.

Plans types et exemples de procédures

165

Les annexes éventuelles – L’organigramme du service et les schémas détaillés de la circulation des documents.

7.2. Plan type d’un rapport Comme cela est signalé auparavant, le lecteur trouvera un exemple de plan type issu d’une mission d’audit d’un centre de serveur. La mission s’intitule : « Audit informatique d’un centre de serveurs et détection des risques ». Plan proposé – Introduction (avec rappel de l’ordre de mission). – Contexte d’exploitation du centre des serveurs. – Diagnostic et recommandations. A. Système physique : architecture générale des serveurs et interfaces – Les points forts. – Les points faibles. – Recommandations. B. Systèmes logiciels et les problèmes des ports – Les points forts et les points faibles concernant les logiciels utilisés. – Les points forts et les points faibles concernant les affectations des ports. C. Les autres types de risques – Recommandations. – Conclusion : dans cette partie, les auditeurs devraient préconiser l’application stricte des recommandations compte tenu des risques encourus, ainsi qu’une mise à niveau rapide des procédures.

166

L’audit technique informatique

7.3. Exemples de procédures d’audit Les deux procédures d’audit suivantes sont données à titre d’exemple. Elles sont fournies à titre pédagogique, cependant, les lecteurs pourront puiser des éléments ou s’en inspirer afin d’établir des procédures ad hoc pour leurs entreprises. Le premier exemple concerne une procédure pouvant être utilisée pour deux types d’audit : l’audit qualité et l’audit informatique. En effet, la plupart des entreprises redéploient les auditeurs qualités ou fournissent des informations et formations adéquates à destination des auditeurs internes pour effectuer les audits informatiques. En cas de ressources insuffisantes, l’entreprise pourrait aussi faire appel à de la sous-traitance. Concernant le deuxième exemple, relatif à l’audit qualité pour la qualification d’un produit logiciel, un plan est fourni, ce dernier sera suivi de la procédure en français. Une version anglaise complète sera aussi présentée en annexe (voir annexe 4). En effet, compte tenu du fait que les entreprises sont de plus en plus internationales, un modèle en anglais pourrait donc être utile aux lecteurs. 7.3.1. Exemple de procédure d’audit interne 7.3.1.1. Introduction La SFLP (Société des fournitures des logiciels et progiciels) a adopté une démarche qualité ISO 9001 : 2000. En accord avec cette démarche et avec celle de la politique qualité de l’entreprise, la Direction générale, en collaboration avec le comité de pilotage, a adopté cette procédure proposée par la Direction qualité et lancé les audits internes

Plans types et exemples de procédures

167

DESCRIPTION DU DOCUMENT Titre : Procédure d’audit interne Edition :

Codification Interne : SFLP.DIR.Qual.PRO.03

Edition-date :

V 1.1 04/04/2005

Résumé : l’objectif de cette procédure proposée par la Direction Qualité et approuvée par la direction générale et le Comité de pilotage est de fournir la démarche et le déroulement des audits internes au sein de la SFLP (Société des fournitures des logiciels et progiciels). Les démarches d’audit qualité et d’audit informatique sont similaires, seuls le référentiel et le choix du profil d’auditeur diffèrent. La procédure est donc applicable pour la conduite des deux types d’audit. Mot clés : audit - procédure – auditeur- qualité Author(s) : Nom :

Tel : Direction : service qualité

Fichier électronique Système Serveur central XX

Système des utilisateurs PC sous Windows

Logiciel Word

Approbation du document Edition

Date

Nom, fonction et signature

Direction/service

V 1.1

04/04/2004

Henri Dupont/ / auditeur et auteur du document

DQ*

V 1.1

04/04/2004

Jean Eden / Directeur qualité

DQ*

V 1.1

04/04/2004

Samuel Tonne / Directeur général

DG*

Changements et versions successives Edition

Date

Raison des changements

V 0.1

04/02/2005

Création

V 1.1

04/04/2005

Document final, ajout du diagramme

Pages affectées Tous Page 4

Note : * DQ : Direction qualité, DG : Direction générale Tableau 7.1. Description du document de procédure d’audit interne

NOTA BENE.– Il importe d’établir un sommaire si le document est volumineux.

168

L’audit technique informatique

7.3.1.2. Objectif de la procédure L’objectif de cette procédure proposée par la Direction qualité et approuvé par la Direction générale et le Comité de pilotage est de fournir la démarche et le déroulement des audits internes au sein de la SFST. La démarche d’audit qualité et d’audit informatique sont similaires, seuls le référentiel et le choix du profil d’auditeur diffèrent. Pour les premiers types de mission, les auditeurs du système qualité sont nécessaires, tandis que celui des auditeurs spécialisés dans les systèmes informatiques et d’information est exigible pour les audits informatiques. Néanmoins, en cas de besoin et compte tenu des spécificités, l’audit interne peut être sous-traité. 7.3.1.3. Définition et terminologie A détailler et compléter en fonction des définitions adoptées par l’entreprise : Audit : processus systématique, indépendant et documenté pour obtenir des preuves ou évidences afin d’évaluer objectivement si les critères d’audit ont été remplis. Audit informatique : activité de contrôle du management informatique pour apprécier l’utilisation, l’exécution, l’efficacité et l’adéquation des éléments constitutifs du système informatique ou du système d’information avec l’objectif et l’orientation de l’entreprise. Audit interne : appelé parfois audit de premier parti, il est effectué au nom de l’organisation par le personnel interne ou par la sous-traitance.

Plans types et exemples de procédures

169

Critère d’audit : ce sont des critères politiques, procéduraux et des exigences utilisés comme références. Ils sont définis au préalable avant le déroulement des missions. Ce sont donc des éléments objectifs pour l’évaluation. Plan d’audit ou de travail : plan proposé par les auditeurs à la DQ et aux audités en vue de faciliter la mission et les services audités. 7.3.1.4. Documents de référence A ajouter si nécessaire, en fonction des entreprises et les références ad hoc en fonction des processus. Référentiels pour la qualité – Normes génériques de la série ISO 9000. – Manuel qualité de SFST. – Plan d’assurance qualité de SFST. – ISO 10011-1 :1990, ligne directrice pour l’audit des systèmes qualité – partie 1 : audit. – ISO 10011-1 :1990, ligne directrice pour l’audit des systèmes qualité – partie 2 : critère de qualification pour les auditeurs. – ISO 10011-1 :1990, ligne directrice pour l’audit des systèmes qualité – partie 3 : gestion des programme d’audit. – Référentiels pour l’informatique. – ISO 9000-3 de même principe que la série ISO 9000 pour la qualité, cette norme est adaptée aux spécificités de conception, de réalisation, de livraison et de maintenance des produits logiciels. – ISO/CEI 9126 pour l’évaluation des produits logiciels. – ISO/CEI 12119 pour les progiciels - exigences qualité et essais. – ISO/CEI 12207 pour les processus du cycle de vie. 7.3.1.5. Les documents spécifiques en relation avec cette procédure – Projet de planification. – Lettre de mission.

170

L’audit technique informatique

– Planning des audits. – Rapport d’audit. Les acteurs concernés – Coordinateur qualité. – Directeur qualité. – Auditeurs. – Comité de pilotage. NOTE.– Le comité de pilotage qualité et celui de l’informatique sont souvent distincts, cependant selon la compétence du personnel, un seul type de comité de pilotage pourrait se concevoir. Diagramme de la procédure Le diagramme de la page suivante permet de détailler : – les acteurs concernés ; – leurs actions, leurs responsabilités, leurs participations et la circulation des documents. 7.3.2. Exemple de procédure d’audit qualité pour la qualification d’un produit logiciel Le plan d’une autre procédure est présenté ci-dessous. Ce plan concerne une procédure d’audit qualité pour la qualification (certification interne) des produits logiciels. Nous utilisons le terme certification uniquement s’il s’agit d’un audit de type tierce partie. La procédure complète est fournie à la page suivante. La version anglaise sera présentée en annexe 4.

Plans types et exemples de procédures

Service audité

Auditeur(s)

171

Comité pilotage

Coordinateur /DQ Préparation /proposition pour le management

Participe à la prépa. du planning.

Developer un planning d’audit

Revue commune Proposition du Planning

Non

Approbation ?

oui

Le premier projet sera présenté au comité. Si nécessaire les amendements pourraient se faire via le système des courriers électroniques.

Envoi aux services concernés Prépa. lettre de mission et Envoi aux services concernés

Réception du planning et de la lettre de mission

Analyse du système qualité ou Choix des auditeurs et fourniture du référentiel Validation du Plan Etablissement d’un plan d’audit et soumission au comité

No

Plan de travail ou d’audit Envoi du Plan d’audit

Oui

Conduite de l’audit

Envoi du rapport final (après approbation des audités) Rapport d’audit

Plan d’audit validé?

Enregistrement du rapport Rapport daudit

Cette phase inclut: - la réunion d’ouverture; - l’ audit; - la réunion de clôture avec validation avec les audités ainsi que les diverses versions avant l’accord final du rapport.

Mettre en place un Plan d’action et informer le comité

Suivi et revue Processus Suivant

Figure 7.1. Diagramme relatif à la procédure

Rapport d’audit et plan d’actions

172

L’audit technique informatique

Procédure d’audit qualité pour la qualification d’un produit logiciel Le lecteur trouvera ci-dessous un plan type proposé et la procédure complète dans les pages suivantes. A. Principes généraux A.1. Objectif de la procédure A.1.1. Champ d’application A.1.2. Bénéfices attendus A.2. Référentiels utilisés B. Conditions d’application B.1. Exigences de la procédure d’audit qualité B.2. Les pré-requis B.2.1. Les pré-requis techniques B.2.2. Les pré-requis qualité B.2.3. Les pré-requis administratifs C. Les résultats et documents du processus d’audit C.1. Le rapport C.2. Les recommandations D. Les différentes phases de l’audit qualité D.1. Le diagramme D.2. La procédure étape par étape D.3. La validité D.4. Modulation D.4.1. Expiration d’un produit déjà qualifié D.4.2. Similitude avec un produit déjà qualifié Procédure d’audit qualité (pour un produit de référence ou de test) DG/Qual-Proc-0002 Edition Date d’édition Statut Catégorie

Numéro V1.00 23 oct, 2004 Proposition Guide

Tableau 7.2. Réduction de la première page de couverture

Plans types et exemples de procédures

173

IDENTIFICATION DU DOCUMENT DESCRIPTION DU DOCUMENT Titre du document PROCEDURE D’AUDIT QUALITE NUMERO DE REFERENCE DU DELIVRABLE EDITION :

REFERENCE - INDEX

V1.00

DATE D’EDITION: Résumé

DG/QUAL-PROC-002

23 octobre 2004

Cette procédure d’audit sera appliquée lors d’une demande de qualification pour un produit de référence (logiciel) ou un outil de test. Elle détermine le mode de travail, les conditions et les pré-requis. Elle pourrait aussi être utilisée pour un processus d’acceptation (de recette) d’un produit de référence ou un outil de test.

audit

Qualification

Produit de test

Outil de test

CONTACT PERSON :

Mots clés Approbation

Henri Ly

Produit de référence

TEL : ext : 35 12

DIVISION :

Qualité

TYPE DE DOCUMENT ET STATUT STATUS

CATEGORY

Document de travail

†

Procédure pour la tâche

†

Projet

†

Tache spécifique

;

Version définitive

;

Sous tâche

†

Version mise à jour

†

CLASSIFICATION Diffusion pour le † public Guide ; Restriction †

SAUVEGARDE ELECTRONIQUE INTERNAL REFERENCE NOM : SYSTEME HÔTE MEDIA ARCHIVE via le réseau Type : Domaine PRODUCTION Identification du Média

SOFTWARE(S) MS Office Word 6.0 MS Windows

Tableau 7.3. Procédure complète

174

L’audit technique informatique

Approbation du document Le tableau suivant identifie les autorités qui ont approuvé ce présent document. AUTORITE

NOM ET SIGNATURE

DATE

Responsable du processus de qualification

H. Ly

23 octobre 2004

Responsable d’unité

J.L. Borland

23 octobre 2004

Tableau 7.4. Identification des autorités

Enregistrement des changements du document Le tableau suivant enregistre l’historique complet des éditions successives du document. EDITION

DATE

RAISON DU CHANGEMENT

V0.00

01-07-02

Document initial (projet)

V1.00

23-10-03

Mise à jour du document

SECTIONS PAGES MODIFIEES Toutes les sections Toutes les sections

Tableau 7.5. Historique des différentes éditions du document

Sommaire Identification du document Approbation du document Enregistrement des changements Plan et développement (voir ci-après)

Plans types et exemples de procédures

175

A. Principes généraux A.1. Les objectifs généraux de la procédure Tous les aspects, composants et éléments du système qualité seront examinés. L’objectif principal est de vérifier l’efficacité du système qualité du service audité. L’audit qualité et la qualification technique par une tierce partie, sont les deux composants pour l’approbation et l’obtention du certificat de qualification. A.1.1. Champ d’application La procédure d’audit est associée à la procédure de qualification. Elles seront appliquées pour un produit de référence ou un outil de test et utilisées pour tester la conformité des autres systèmes vis-à-vis d’une norme ou d’un référentiel donné. Cette procédure détermine le mode de travail, ainsi que les conditions et les pré-requis associés. Elle peut être utilisée dans un contexte d’acceptation ou de recette. A.1.2. Bénéfices attendus L’application de cette procédure est considérée comme une méthode incluant une approche qualité permettant : – l’établissement d’une confiance sur ces produits ; – l’amélioration de la qualité de ces produits logiciels et des services ; – la diminution des coûts globaux de ces produits ; – l’amélioration du niveau d’exigence requis ; – la promotion d’une harmonisation progressive des produits utilisés. Tout cela contribue à une excellence technique. A.1.2.1. Référentiel utilisé Tous les termes ou expression utilisés se trouvent dans les documents ci-dessous (les documents du référentiel étant en anglais, nous avons gardé leur titre d’origine) :

176

L’audit technique informatique

– Study Report Qualification and Certification Issues (ref. : PLC.ET1.ST006.000-REP-000) ; – Qualification Procedure (ref..:Policy document 1 Edition: 1.08) ; – ISO 9000 : Quality management systems - Fundamentals and vocabulary (edition date 20/12/2000) ; – ISO 9001 : Quality management Systems - Requirements (edition date 20/12/2000) ; – ISO 9004 : Quality management Systems - Guidelines for performance improvement (edition date 20/12/2000) ; – ISO 19011 : Guidelines for quality and/or environmental management systems auditing (edition date 01/10/2002). B. Conditions d’application de la procédure Avant de soumettre un produit ou un système à la qualification et à l’audit qualité, on ne doit pas perdre de vue le ratio bénéfice vis-à-vis du coût. Cependant l’audit qualité devrait automatiquement être appliquée quand on demande une qualification du produit. B.1. Exigence de la procédure d’audit qualité Un service ou une entreprise devrait être audité dès lors qu’une demande de qualification est demandée pour un produit. L’application doit être exigée pour les cas suivants : – si le produit doit être utilisé comme un produit de référence ou comme un outil de test dans le cadre d’un processus de certification (le produit sera utilisé pour certifier un système) ; – si le produit doit être utilisé par plusieurs services ou Etats membres ; – si le produit doit être utilisé dans plusieurs régions des Etats membres ; – si le produit doit jouer un rôle important au sein des centres régionaux et/ou pour un système central ; – s’il doit jouer un rôle essentiel concernant le contrôle qualité (un outil de test par exemple) pour vérifier un système central ou des systèmes régionaux.

Plans types et exemples de procédures

177

B.2. Pré-requis B.2.1. Pré-requis techniques Le produit doit être vérifié et validé par le développeur et/ou par le fournisseur. Le produit à qualifier pourrait déjà être opérationnel dans un site particulier. En parallèle, la qualification technique (incluant la révision des documents techniques, la vérification des codes…) pourrait être déjà enclenchée par une tierce partie : un laboratoire accrédité. B.2.2. Pré-requis qualité Le demandeur devrait obtenir au préalable soit : – un label ou une attestation (de la part d’une autorité reconnue) ; – un certificat ISO 9001 : 2000 concernant le périmètre incluant la conception et la fabrication du produit ; – une preuve issue d’un audit interne planifié concernant l’organisation et la méthodologie. Dans ce dernier cas, notre audit doit être renforcé. B.2.3. Pré-requis administratifs L’exigence administrative est la même que celle issue de la procédure de qualification, c’est-à-dire que la demande (de qualification) doit être adressée au chef d’unité de qualification en temps opportun dans la période prescrite, au moins deux mois avant la période d’évaluation et au moins quatre mois avant la date espérée pour le jury. D’autre part, le demandeur devrait désigner un correspondent de qualification (le responsable du projet du produit ou le responsable qualité) et allouer un budget pour les dépenses adéquates. C. Résultat du processus d’audit qualité C.1. Rapport d’audit qualité Le principal document résultant de l’audit est le rapport, établi par l’équipe d’audit. Un plan type est donné en annexe. Ce rapport sera fourni aux membres du jury et au service audité. L’équipe d’audit

178

L’audit technique informatique

fournira pour chaque demande de qualification de produit, un rapport spécifique. L’équipe d’audit présentera aussi les éléments détectés durant la réunion du jury de qualification. C.2. Recommandations Si nécessaire, notre équipe d’audit peut émettre des recommandations ou des suggestions. Tous les éléments, donnant un impact négatif au système qualité, doivent être corrigés, suivis et tenus en compte par le service demandeur en adéquation avec les processus correctifs appropriés (plan d’actions). D. Phases définies par la procédure d’audit La procédure d’audit définit un processus cinq étapes. D.1. Diagramme du processus Etape 1 : initialisation

Demande

Formation de l’équipe d’audit

Etape 2 : préparation

Détermination du référentiel

Préparation et planning

Ordonnancement

Plans types et exemples de procédures

179

Etape 3 : audit Plan de travail Réunion de lancement

Révision de la documentation

Interwiews

Synthèse

Etape 4 : phase de restitution d’audit

Evaluation technique (laboratoire)

Ecriture du rapport

Rapport d’audit

Action corrective

Etape 5 : suivi Contrôle et Validation

La section suivante détaille les étapes de la procédure.

Plan d’action

180

L’audit technique informatique

D.2. Une procédure par étape Etape 1 – Initialisation Après réception de la décision de la Direction générale ou des autres directions externes, une équipe d’audit sera constituée ainsi qu’un responsable d’audit pour le projet. Par la suite, le périmètre d’audit ainsi qu’un référentiel sera fixé (un exemple de référentiel est donné en annexe 2). Etape 2 – Préparation Le plan de travail et tous les documents relatifs au processus doivent être préparés par l’équipe d’audit ainsi que la planification de l’audit. Etape 3 – Visite du service audité ou de l’entreprise : – réunion de lancement des travaux ; – revue de la documentation ; – interviews ; – examen du référentiel et comparaison de l’application sur le site ; – détection des non-conformités ; – rapport sommaire. Etape 4 – Rapport d’audit L’équipe d’audit doit établir un rapport. Ce dernier peut être séparé ou intégré dans le rapport d’évaluation technique avec les éléments trouvés issues des tests (possibilité d’un rapport commun). Etape 5 – Suivi Cette étape concerne le suivi global du processus global et focalise sur les actions correctives ou les recommandations émises (plan d’action corrective). Les modifications ou les améliorations prévues doivent être vérifiées par la suite.

Plans types et exemples de procédures

181

D.3. Validité La durée de validité d’un rapport d’audit est la même que celle de l’approbation pour la qualification d’un produit pour une version donnée: trois ans à partir de la date d’approbation. A chaque changement du produit ou système ou de son utilisation hors du même contexte, l’approbation est caduque. D.4. Modulation D.4.1. Expiration de la validité d’un produit déjà qualifié Dans le cas d’expiration de la validité d’un produit déjà qualifié pour une version donnée, un audit doit être réalisé si une demande de requalification est activée. Néanmoins, l’application de cette procédure pourrait être allégée. D.4.2. Similitude avec un produit déjà qualifié Dans le cas d’une nouvelle version (amélioration ou changement mineur) issue d’un produit déjà qualifié dans un changement de contexte ou d’environnement, l’audit qualité n’est pas nécessaire. Concernant un produit de la même catégorie ou du même type de produit déjà qualifié, le processus de qualification pourrait être allégé. Les anciens éléments d’audit pourraient être utilisés si l’environnement ou le contexte n’ont pas été modifiés. Remarque concernant les produits de sûreté et de sécurité Concernant les produits ou systèmes ayant un impact sur la sûreté et la sécurité, la procédure doit être consolidée sur les points suivants : – exiger deux équipes d’audit et deux évaluations techniques effectuées par deux laboratoires accrédités distincts ; – stipuler une analyse comparative avec les rapports d’audits et les évaluations techniques obtenus. Autrement dit, la nécessité d’obtenir des résultats concordants.

182

L’audit technique informatique

7.4. Annexes 7.4.1. Annexe 1 : plan type du rapport d’audit Introduction Concernant la qualification d’un outil de référence logiciel ou d’un outil de test, la procédure de qualification suivante sera utilisée: Document politique 1 numéro d’édition : 1.8 du 22/10/2002. Contexte de l’audit – La présentation des éléments de la société du demandeur. – Les explications et la rationalité concernant les fonctionnalités du produit ou du système seront audités. – La version en cours du logiciel sera examinée. Termes et définitions Partie réservée pour la définition des mots techniques utilisés. Actions d’audit qualité L’audit qualité comprend les diverses actions suivantes : – demander au développeur ou fournisseur les principaux documents concernant le produit ; – demander les documents ou divers certificats du fournisseur ; – faire faire des tests techniques par un laboratoire technique accrédité en vue d’établir un rapport d’évaluation technique ; – examen des divers documents par notre équipe d’audit en vue d’établir un rapport d’audit qualité ; – demander les informations complémentaires et examen de ces éléments si nécessaire ; – rédiger un rapport d’audit qualité. Examen des documents en rapport avec la qualité Les documents concernant le développement et la conception du produit ou du système seront examinés (le référentiel du développement).

Plans types et exemples de procédures

183

Documents de certification Tous les certificats ou preuves (concernant la qualité, document ISO par exemple) concernant le produit et/ou le service seront examinés. Mesures et preuves d’assurance qualité Le rapport et/ou le résultat de l’évaluation technique sera fourni et présenté par un laboratoire indépendant accrédité. Conclusion L’équipe d’audit fournira des recommandations pour la décision du jury de qualification (pour la qualification du produit). 7.4.2. Annexe 2 : exemple des éléments du référentiel – Plan de la gestion des configurations. – Manuel d’installation. – La norme ISO 9126. – Manuel des opérations. – Plan de gestion de projet. – Plan d’assurance qualité. – Documents ou historique détaillant les changements du système. – Description technique, plan de vérification et de validation.

Résumé du chapitre 7 Aucun service technique ne peut fonctionner sans un planning ou sans un programme de travail ni procédure. Il en est de même pour un service d’audit lors des missions. Ce chapitre propose donc un plan type de programme de travail ainsi que quelques procédures. L’avantage de ces exemples c’est qu’ils peuvent être « retaillé » sur mesure pour une utilisation rapide et opérationnelle. Enfin, il importe de souligner que tous les documents ou normes utilisés devraient inscrits comme référentiel dans ces procédures. En effet, l’audité ou les membres de son service peuvent contester les remarques d’un auditeur concernant un point faible si ce dernier ne figure pas dans un document référencé.

FOIRE AUX QUESTIONS (CHAPITRE 7)

Question 1 : quel est le nombre de pages au minimum nécessaires pour un plan de travail ? Réponse : il n’y a pas de règles fixes. Un nombre de pages minimum n’est pas nécessaire, mais la qualité est exigée pour l’établissement d’un plan de travail. En effet, il s’agit du plan de route de l’auditeur pour pouvoir exercer son audit informatique. Un plan de travail bien conçu et « bien ficelé » permet d’avancer très rapidement le processus d’audit. Question 2 : en ce qui concerne les procédures d’audit, doit-on respecter un plan bien déterminé et/ou un certain nombre de pages ? Réponse : la ou les procédures d’audit sont très spécifiquement liées à chaque d’entreprise, quoique le canevas soit pratiquement le même. C’est pourquoi nous avons donné deux exemples dans ce livre. Ces exemples permettront aux initiés d’établir rapidement en cas de besoin une procédure ad hoc. Quand au nombre de pages, il est variable et c’est toujours la qualité et la réalité (concernant les démarches adoptées) qui doivent être les points importants à respecter.

186

L’audit technique informatique

Question 3 : tous les référentiels doivent-ils être cités dans la procédure ? Réponse : la réponse est oui sans hésitation. En effet, l’audité peut contester les remarques d’un auditeur qui cite un point faible ne figurant pas dans la procédure ou dans un document référencé. Question 4 : la page d’identification du document est elle réellement nécessaire dans une procédure ? Réponse : la réponse est oui. En effet, en vertu du principe de la traçabilité, cette page permet d’identifier tous les éléments relatifs à ce document, par exemple, son auteur, son lieu d’archivage, le résumé de la procédure… C’est en quelque sorte la pièce d’identité du document. Question 5 : comment doit-on gérer une procédure d’audit ? Réponse : la gestion des procédures d’un service d’audit est analogue à celle des documents d’une entreprise souhaitant ou se préparant à être certifiée ISO 9001 :2000. C’est-à-dire que toute la traçabilité doit être implicite. La naissance, les modifications des éléments de la procédure et son retrait doivent être suivis et les dates respectives de ces processus doivent être consignées. Question 6 : en quoi consiste le guide TickIT ? Doit-on l’utiliser ? Réponse : la certification TickIT est élaborée par les Anglo-saxons concernant la qualité et le développement du logiciel. En fait, c’est l’adaptation spécifique de l’ancienne norme ISO 9001 pour ce corps de métier. Il n’est pas nécessaire de l’utiliser sauf si l’on vise une certification de ce type. Ce guide comporte trois principales sections: la première pour le client, la seconde pour le fournisseur et enfin la troisième section pour les auditeurs.

CONCLUSION

Dans un contexte fortement automatisé, de plus en plus « Internet » et compte tenu des éléments suivants, les besoins de sécurité ainsi que ceux de conseils et d’audits techniques vont s’accroître d’une façon importante. : – foisonnement de l’informatique, de la bureautique surtout, de la micro-informatique ; – forte croissance des connexions des réseaux ; – besoin élevé de communication des entreprises avec leurs filiales ou avec les autres sociétés implantées dans un futur proche partout en Europe avec le Marché unique. Dans un article de l’Usine nouvelle du 10 mars 2005, à propos des besoins et recrutement des jeunes ingénieurs diplômés (toutes les disciplines confondues), c’est le secteur « Etudes,conseil et audit » qui a été classé en premier. Ce qui paraît contradictoire, alors que ces derniers étaient plutôt formés et préparés pour travailler dans l’industrie ! Cela est d’autant plus contradictoire que les besoins du secteur de traitement de l’information est en troisième position derrière le secteur de l’industrie automobile… Ainsi, via les besoins croissants du secteur conseil/audit, on peut penser que la nécessité de la Direction générale ou des dirigeants de maîtriser leurs systèmes d’information et informatique se ressent de plus en plus face à l’évolution vertigineuse des nouvelles technologies et le besoin croissant d’outils d’aide à la décision. Maîtriser ses outils d’information,

188

L’audit technique informatique

de production et/ou de communication est une condition indispensable pour qu’une entreprise puisse aborder la concurrence et conquérir des parts de marché. Cela ne peut se concevoir sans l’assurance de la performance, de la qualité, de la fiabilité des systèmes utilisés (devenant de plus en plus complexes avec les réseaux et les interconnexions) et de leurs adéquations avec les besoins de l’entreprise. De ce fait le rôle des auditeurs informatiques est double : diagnostiquer, s’assurer (révéler les défauts, failles ou points faibles pouvant nuire à la sécurité et au fonctionnement) et proposer des améliorations, des recommandations aux dirigeants et aux chefs de service. D’autre part, avec l’élargissement de l’Europe et la relance de la dynamique des activités stimulée par les nouvelles technologies ICT (Information and Communication Technologies), en particulier avec le Web et ses outils de communication (Wifi, communication via les mobiles, via les satellites…), le développement des risques techniques et informatiques associés sont des menaces réelles. De ce fait, il est inévitable que le métier d’auditeur spécialisé en informatique et en système d’information soit amené à s’affirmer. Cela se confirme aussi par la presse spécialisée. Dans le magazine 01 Informatique DSI de mai 2005, on peut lire la phrase suivante : « Avec l’ouverture des applications métier sur Internet et l’avènement de nouvelles contraintes réglementaires comme la Loi Sarbanes-Oxley1, la pratique de l’audit du système d’information promet de se développer ». A Bruxelles, conscient des enjeux et des risques liés à la transmission et à l’authentification des informations, une directive européenne (n° 1999/93/CEE) de décembre 1999 a été publiée concernant la réglementation de la signature électronique au niveau communautaire. Dans une entreprise, pour la bonne marche et la protection de son patrimoine, l’audit informatique est devenu un élément incontournable

1. La loi Sarbanes-Oxley qui est adoptée en juillet 2002 faisant suite aux déboires financiers et malversations, par le Congrès américain (appelée aussi SARBOX ou LSO en français) oblige les entreprises à répondre de certaines prérogatives (voir aussi lexique).

Conclusion

189

avec son système « fiable et connectable » aux autres réseaux externes à travers le monde. Cependant, pour bon nombre d’entreprises, auditer et vérifier la sécurité et la sûreté de leur système informatique et de leur système d’information, le problème consiste à trouver cet « acteur informatique » externe ou interne. Constatant la nécessité d’une part, d’un audit informatique et d’autre part, le manque de compétence interne, les responsables ou dirigeants sont souvent amenés à en appeler à des contributions de consultants ou d’auditeurs externes. Mais, il n’en demeure pas moins que la personne responsable de l’informatique de l’entreprise doit comprendre l’enjeu du processus et offrir son entière coopération à ces « auditeurs étrangers » venus d’ailleurs (le personnel de l’entreprise est souvent très méfiant). En effet, il ne doit pas être nos censeurs, mais nos partenaires pour l’amélioration de la qualité, de la sécurité et de l’adéquation de nos outils d’exploitation avec les objectifs de l’entreprise…

ANNEXE 1

Rappel des outils pour les auditeurs

A1. Rappel des outils pour les auditeurs Les auditeurs ont besoin d’être bien formés et de maîtriser certaines techniques pour bien mener leurs missions à terme. Nous ne développons pas ces sujets, seul un bref rappel concernant les éléments clefs est détaillé ci-dessous.

A1.1. La technique de réunion Cette technique demande une préparation sérieuse, de la vigilance et exige un investissement préalable. Elle comporte deux phases : la phase préparatoire et le déroulement proprement dit. La convocation établie puis‚ distribuée aux acteurs concernés peut être considérée comme l’aboutissement de la phase de préparation. Ce document comporte les renseignements suivants : le sujet, le champ d’étude, les objectifs, un plan de réunion, le lieu et l’heure de la séance ainsi que la liste des participants. La réunion doit commencer par une présentation des participants, puis un rappel des objectifs. Il serait souhaitable d’avoir un animateur qui ait

192

L’audit technique informatique

pour rôle de répartir « les temps et les droits de réponse » et d’éviter les conversations en aparté, de nature hors sujet ou ne concernant pas les objectifs préalablement fixés. Enfin, une personne doit être désignée pour l’établissement d’un compte rendu.

A1.1.1. Les interviews L’interview se fait d’une façon individuelle. Cette technique permet de creuser plus et d’obtenir des renseignements « pointus » intéressants et parfois non diffusables en groupe. Elle comporte deux phases : – la préparation d’une liste des thèmes ou d’éléments à demander (le check-list) le choix de l’interlocuteur du service audité, l’établissement des questionnaires (voir infra) constituent la première phase de l’interview ; – la conduite de l’interview doit être menée avec tact et souplesse. En effet d’une part, on perturbe le travail quotidien de l’interlocuteur, d’autre part certaines questions pourront le gêner. Pour mettre à l’aise la personne interviewée, il serait souhaitable de se présenter, lui faire connaître, au préalable, les objectifs de l’entretien et révéler ses contributions éventuelles dans le domaine enquêté par les auditeurs. Rappelons qu’il existe des inconvénients par rapport à la réunion classique : – un nombre potentiel élevé de personnes à interviewer ; – une augmentation de délai pour l’obtention des informations (difficulté pour prendre un rendez-vous) ; – la nécessité de déplacements importants. Autrement dit, toute technique de planification et de prévision budgétaire serait de bon augure. En tout état de cause, quelle que soit la technique choisie, il faut donc établir un plan de visite pour tirer un maximum de profit de ces méthodes de travail. Le plan de visite sera établi en fonction du service audité, de ses contraintes, de la disponibilité des interlocuteurs et de leur hiérarchie.

Annexe 1

193

A1.1.2. Le questionnaire Moins contraignant que les deux techniques précédentes, le questionnaire crée moins d’appréhension et pose moins de problème d’ordre psychologique (le participant est invisible et peut être anonyme). Mais pour le demandeur d’informations, l’utilisation du questionnaire soulève quelques inconvénients. – absence de réponse pour certaines questions ; – retour hors délai, d’où questionnaire non exploitable au bon moment ; – réponses hors sujet ; – non-retour du questionnaire. Pour éviter au maximum ces inconvénients, une préparation minutieuse est nécessaire pour déboucher sur des questions précises, sans ambiguïté, claires et ouvertes (éviter les réponses de type oui ou non). La longueur du questionnaire est primordiale : trop long, il décourage le participant, trop court, l’obtention des informations intéressantes sera difficile. Cependant cet outil n’est pas très fiable et une vérification s’impose ultérieurement : les fournisseurs des réponses ont tendance à maximiser leurs points forts et minimiser leurs points faibles.

A1.2. Les autres techniques, les tests et les outils logiciels A1.2.1. Outils de test – Les tests : technique consistant à prendre un échantillon d’une population ou l’étude exhaustive en cas de besoin ou de doute, et le traiter suivant les méthodes statistiques et/ou probabilistes afin de terminer les résultats en vue de les comparer avec ceux connus ou déjà publiés. Une technique mathématique peut être utilisée pour confirmer une hypothèse est le fameux test de X² (Chi deux). – Les tests de variances et de co-variances sont parfois nécessaires dans certains contextes.

194

L’audit technique informatique

– Les graphes ou les schémas de circulation de document ou d’information : outils permettant d’apprécier de façon synthétique les événements et de révéler les anomalies. – Enfin, concernant l’élaboration du rapport ainsi que des divers documents, il serait souhaitable de maîtriser les outils bureautiques tel que Microsoft Office ou Star Office. La maîtrise d’Excel par exemple ainsi que son système graphique ne seraient que bénéfiques pour les auditeurs pour représenter les chiffres et les données statistiques recueillies. Toutes ces techniques ont pour but de trouver les réponses à certaines questions et/ou de démontrer les points forts ou les points faibles de l’organisation, des procédures... En résumé, l’utilisation des techniques et méthodes maîtrisées permettrait aux auditeurs de « systématiser » les travaux et gagner du temps. Ceci est d’autant plus profitable lorsqu’il existe des feedbacks (retours d’informations des autres audits effectués) d’autres membres pratiquant les mêmes types d’outils.

A1.2.2. Outils (logiciels) La démarche adoptée des auditeurs consiste aussi à connaître et identifier les processus pratiqués. Côté outils informatiques, il existe bon nombre de logiciels tels que IDS Scheer d’IBM, SAP ou OraclePeoplesoft ou celui d’Enablon. Ce dernier permet aux utilisateurs de saisir des informations sur des formulaires électroniques stockés dans un serveur. Ces informations sont ensuite remontées jusqu’à la Direction sous forme de tableaux de bord avec des indicateurs de risque. L’outil conserve tous les types d’informations et les archive. Cette possibilité est très utile pour les auditeurs, surtout dans le cadre de la loi SarbanesOxley (concernant particulièrement les entreprises qui ont des filiales ou agences aux Etats-Unis).

Annexe 1

195

L’éditeur BMC Software quant à lui, propose un outil qui identifie les liens entre les applications et l’infrastructure informatique. De ce fait, les informations en output pourraient être fort utiles pour les auditeurs pour identifier les applications métier touchées en cas de panne et les risques potentiels encourus.

A1.2.3. La formation Afin de pouvoir exécuter avec efficacité les missions qui lui sont confiées, un auditeur devrait pouvoir se former régulièrement et se remettre à niveau. Une formation d’une semaine ou de dix jours n’est pas excessive pour un auditeur informatique confronté à des missions pointues telles que celles concernant les systèmes. Et pour la qualité de ces dernières, cela est même crucial. Nous conseillons de se former auprès des constructeurs adéquats pour les outils techniques. Pour une mise à jour de généraliste, l’IFACI serait également une bonne adresse et aussi l’occasion d’échanger les expériences avec les autres confrères. Il importe de savoir que les formations accordées aux auditeurs constituent un investissement et non un luxe ou une perte de temps. De ce fait, le responsable d’audit interne devrait planifier et consacrer des créneaux de formation aux membres de son équipe en cohérence avec les missions planifiées. Enfin, pour les personnes qui devraient auditer le cœur des systèmes et/ou réseaux, il est important de leur accorder des formations supplémentaires auprès des constructeurs. Dès lors, la durée de l’ensemble de leur formation serait systématiquement allongée.

ANNEXE 2

Démarche pour un plan de sécurité

Dans bon nombre de sites audités, nous détectons l’absence d’un plan de sécurité, en tant qu’auditeur nous pouvons recommander la démarche suivante en cinq points : 1) l’identification des objectifs et la pré-étude ; 2) l’analyse des risques ; 3) l’élaboration d’un plan d’action ; 4) la réalisation des actions ; 5) le suivi et la réactualisation (si nécessaire) du Plan de sécurité. Détaillons-en les différentes étapes. 1re étape L’identification des objectifs et la pré-étude constituent la première phase du processus. Elle est primordiale, car elle permet une prise de conscience générale sur les problèmes de sécurité par les différents acteurs de la Direction, du service informatique, des utilisateurs (leur représentation) et si nécessaire des représentants syndicaux. En effet la sécurité est, et sera, l’affaire de tous.

198

L’audit technique informatique

Elle permet aussi de définir en commun un plan global, associé à la répartition des travaux et responsabilités ainsi que la définition d’un budget (aval de la Direction) et un calendrier prévisionnel (accord de tous les acteurs concernés). 2e étape Cette phase concerne l’analyse des risques. Il faut distinguer l’analyse par domaine. Par exemple, il faut dissocier le domaine des logiciels courants de gestion, celui des applications web ou celui du réseau… L’analyse de l’existant, la pratique du « scoring » (principe de pondération) et la mise au point d’un plan d’amélioration seront les tâches de début de cette étape. Puis l’évaluation des moyens et procédures (ressources, budget, temps), leurs coûts associés et les choix définitifs clôturent cette étape. 3e étape Cette étape détermine l’élaboration d’un plan d’action. Celui-ci ne peut se concevoir qu’à la fin des deux étapes précédentes. En « input», il prendra toutes les informations issues de ces dernières et définit qui fait quoi, pour quand, où (lieu quand un événement se réalise), comment et avec quoi. Ce plan définit un planning rigoureux de chaque tâche associée aux acteurs correspondants. 4e étape A partir du plan précédent, on met en place tous les dispositifs prévus (si c’est la première fois) et on réalise les tâches définies pour et avec les acteurs associés. Cependant il faut noter l’importance du reporting des acteurs. Si un incident se manifeste, on applique stricto sensu le plan d’action. Un bilan est nécessaire après chaque incident et/ou après l’application du plan.

Annexe 2

199

5e étape Cette étape se nomme phase de suivi et de réactualisation du plan de sécurité. En input, elle a besoin des bilans et des documents de reporting de la phase précédente. Elle est importante et nécessaire car elle permet aux services informatiques d’évoluer, de s’adapter et d’élaborer des parades et actions face aux nouvelles menaces, vulnérabilités et aux nouvelles technologies.

ANNEXE 3

Fonctions illicites des programmes malveillants

Cette annexe décrit succinctement les programmes dévastateurs ainsi que leurs diverses fonctions malveillantes et illicites. A3. La fonction illicite Afin de mieux appréhender ces problèmes, il nous semble utile de détailler d’abord les caractéristiques des fonctions illicites ainsi que les programmes destructeurs. La « fonction illicite » est une fonction d’un programme non autorisée, non documentée et qui ne participe en rien aux objectifs officiels du programme ou à une application informatique. En général une fonction illicite : – a un caractère malveillant : la fonction peut avoir un effet destructeur logique (par exemple un effacement logique de fichier), plus rarement un effet destructeur physique (par exemple variations rapides et extrêmes du bras de lecture du disque), un effet inhibiteur (saturation d’un canal I/O, saturation mémoire, bouclage de programme, perturbation du Command Liner Interpreter *) ou un effet purement modificateur. Elle peut, en outre, entraîner le vol ou la

202

L’audit technique informatique

divulgation de données (par exemple, interception de mots de passe lors des modifications) ; – n’est connue que d’un nombre très réduit de personnes : son ou ses concepteurs ; – ne rend service à personne d’autre qu’à son ou ses créateurs ; – s’exécute à l’insu de l’utilisateur. Toute infection utilise une ou plusieurs fonctions illicites. Une fonction illicite peut avoir un effet temporaire (conditionné à certains paramètres internes ou externes) ou permanent. Elle peut en particulier intégrer une fonction d’auto-effacement de certaines traces. Une fonction illicite peut représenter une petite partie d’un programme ou le programme entier : on parle dans ce cas d’usurpation d’identité. Un exemple extrait d’un hebdomadaire spécialisé, il y a quelques années : le programme Stripes.exe sous MS/DOS (système d’exploitation de Microsoft pour micro-ordinateur, compatible IBM) contient une fonction illicite : pendant qu’il affiche à l’écran une figure amusante, tous les mots de passe sont copiés dans un fichier nommé Stripe.bqs.

A3.1. La fonction à déclenchement différé La « fonction à déclenchement différé » est une fonction d’un programme dont l’exécution est différée jusqu’à ce que certaines conditions soit remplies : déclenchement d’événements particuliers ou par l’absence d’événement, ou en fonction d’une date, etc. Un exemple classique de bombe logique à déclenchement différé est celui d’un programmeur qui, pour se prémunir d’un licenciement, insère dans un programme de paye une fonction de destruction de fichiers ou de reformatage des disques durs, dont l’exécution est déclenchée si son nom disparaît du fichier du personnel ou du fichier de paie.

A3.2. La fonction de déplacement La « fonction de déplacement » est une fonction qui déplace un programme ou qui est capable de transférer le programme d’une adresse

Annexe 3

203

à une autre de la mémoire vive (RAM : Random Access Memory) ou de la mémoire de masse d’un ordinateur. Par exemple, le jeu informatique Core wars, où l’on trouve le phénomène de lutte de deux programmes pour acquérir la possession exclusive de la mémoire d’un ordinateur, repose essentiellement sur les fonctions de déplacement.

A3.3. La fonction autoreproductrice Enfin, la « fonction autoreproductrice » est une fonction d’un programme qui possède la faculté de créer une réplique strictement identique du programme et donc d’elle-même (que l’on appelle souvent le phénomène de clonage). Un tel programme est très difficile à éliminer, car il se multiplie rapidement et l’oubli d’un seul exemplaire suffit pour que le système soit de nouveau, à brève échéance, totalement contaminé car chaque copie peut à son tour se reproduire (développement rapide de type exponentiel, même phénomène que les virus dans le corps humain).

A3.3.1. Définition des programmes dévastateurs Les programmes destructeurs ou appelés dévastateurs (quatre types) se différencient par les fonctions qu’ils pratiquent et par leurs définitions : « Un ver est un programme qui se propage dans un ordinateur ou dans un réseau, c’est un produit qui s’insère comme un parasite dans un programme normal d’application ou utilitaire. » Exemple récent : un ver nommé w32/MyDoom se propageant via les mails le 27 janvier 2004, aléatoirement, avait fait quelques centaines de milliers d’infections des ordinateurs privés et ceux des entreprises via Internet. Deux jours après, un tiers des utilisateurs du courrier électronique étaient contaminés dans le monde. Microsoft offrait 250 000 dollars à la personne capable de trouver le ou les auteurs de ce ver. L’émail incite les gens à ouvrir un fichier exécutable avec les informations suivantes : « The message cannot be represented in 7-bits ASCII encoding and has been sent as a binary attachement ».

204

L’audit technique informatique

Autrement dit, l’email précise que le message attaché ne peut être présenté en 7 bits, en ASCII (c’est-à-dire possibilité de lecture normale) et a été envoyé en fichier binaire. Les utilisateurs croyant à la véracité de l’explication ouvrent ce fichier qui n’est en fait que le ver malsain créant le ralentissement de leurs systèmes et polluant leur réseau d’entreprise. Les vers sont des programmes qui ont en plus une possibilité de déplacement, c’est-à-dire un positionnement dans la mémoire centrale ou dans les autres supports d’une façon aléatoire en fonction d’une règle pré-programmée. Les chevaux de Troie sont les premiers programmes malveillants connus dans les environnements informatiques, leur technique consiste à exécuter les fonctions illicites. Puis arrivent les bombes informatiques : programmes ayant les caractéristiques des premiers mais en plus ils peuvent agir à retardement (d’où l’origine de leur nom), en fonction d’une date préprogrammée ou en déclenchement si l’on rentre un mot clef « détonateur » par hasard ou par inadvertance. Enfin les virus sont, chronologiquement, les derniers apparus, outre la possession de toutes les caractéristiques citées précédemment, ils ont la possibilité d’autoreproduction, de création des clones de répliques au sein d’autres programmes. Ils laissent une empreinte sur les programmes contaminés évitant ainsi une double contamination, par contre, ils ne laissent aucune trace sur le système d’exploitation. On peut distinguer deux types de virus par leurs effets et par leurs manières de contaminer les programmes.

A3.3.2. Les virus par ajout Les virus par ajout : comme ce nom l’indique, ils ajoutent des instructions aux divers programmes d’application sans les détruire. A chaque exécution du programme contaminé, le virus s’exécute puis

Annexe 3

205

redonne le contrôle au programme, il agit d’une façon analogue au sous programme ou subroutine. Son point fort : sa détection tardive peut entraîner une possibilité de dégâts importants. Son point faible : la taille des programmes infectés est automatiquement augmentée d’où possibilité de s’apercevoir si l’on contrôle systématiquement les tailles des fichiers et possibilité éventuelle d’y remédier... Un exemple pratique de découvrir la taille des fichiers (dans le système d’exploitation MS-DOS des micros) consiste à taper DIR (directory, listage du répertoire) : cette commande liste la taille ainsi que la date de création des fichiers. Puis, on les compare avec les anciennes listes de sauvegarde.

A3.3.3. Les virus par recouvrement Les virus par recouvrement détruisent une partie des programmes d’application et s’installent au départ dans ces derniers. Enfin ces types de programmes malfaisants se distinguent aussi par leur complexité de création : par exemple pour l’écriture des chevaux de Troie ou des bombes, la connaissance du langage C ou de Pascal est nécessaire et suffisant, mais pour les deux derniers types, la connaissance de l’assembleur du microprocesseur est indispensable. Face à ces problèmes, on peut déduire l’importance et le rôle d’un auditeur.

ANNEXE 4

Quality audit Procedure (for a Reference product or a test tool) DG/QUAL-PROC-0002 Edition Number Edition Date Status Category

V1.00 23 Oct, 2004 Proposed Issue Guideline Document

DOCUMENT IDENTIFICATION SHEET DOCUMENT DESCRIPTION Document Title QUALITY AUDIT PROCEDURE FOR TOOLS QUALIFICATION EWP DELIVERABLE REFERENCE NUMBER REFERENCE - INDEX

EDITION

V1.00

DG/QUAL-PROC-002

EDITION DATE :

23, October 2004

Abstract The audit procedure applies when a qualification process is requested for a reference or test tool or system. It determines working mode as well as conditions and associated prerequisites. It can be used in a acceptance process when applying the qualification procedure for reference product or test tools. Keywords audit

Qualification

Test product

Test Tool

CONTACT PERSON

Henry Ly

Approval

TEL : 35 12

Reference product

DIVISION :

EMS

208

L’audit technique informatique

DOCUMENT STATUS AND TYPE STATUS

CATEGORY

CLASSIFICATION

Working Draft

†

Executive Task

†

General Public

†

Draft

†

Specialist Task

;

RU Document ; Guideline

;

Proposed Issue

†

Lower Layer Task

†

Restricted

†

Released Issue

† ELECTRONIC BACKUP

INTERNAL REFERENCE NAME : HOST SYSTEM

MEDIA

ARCHIVE Network

Type : Domain

SOFTWARE(S) PRODUCT

Media Identification :

MS Office Word 6.0 MS Windows

Document approval The following table identifies all management authorities who have successively approved the present issue of this document. AUTHORITY

NAME AND SIGNATURE

DATE

Qualification Process leader

H. Ly

23, October 2004

Head of Quality Unit

J.L. Borland

23, October 2004

Document change record The following table records the complete history of the successive editions of the present document.

EDITION

DATE

REASON FOR CHANGE

V0.00

01-07-02

Initial document (draft)

All sections

V1.00

23-10-03

Updated document

All sections

SECTIONS PAGES AFFECTED

Annexe 4

209

Table of contents – Document identification sheet. – Document change record. – Table of contents. The same as the French version. A4. General principles A4.1. General objectives of the procedure All aspects, components and topics of the Quality System would be audited. The main goal is to check the efficiency of the quality system of the audited service. Quality audit and technical qualification by a third party laboratory were the two components to get the tool qualification approval and the certificate of qualification.

A4.1.1. Application field The audit procedure is associated with the qualification procedure. That means to be applied to a test product (test tool) or system, i.e. an entity used to test the conformity of other systems with a standard or a given referential. It determines working mode as well as conditions and associated prerequisites. It can be used within the frame of an acceptance process.

A4.1.2. Expected benefits The application of this procedure is a method which is included in a quality approach to allow : – building an established confidence in these products ; – improving the quality of the software products and of their services ;

210

L’audit technique informatique

– decreasing the global cost of these products ; – increasing the requirement level concerning these products ; – promoting a progressive harmonisation of used products ; this aims to achieve technical excellence.

Referential useful to better understanding All terms and expressions used can be found in the following referential : – « Study Report Qualification and (ref. : PLC.ET1.ST006.000-REP-000).

Certification

Issues »

– « Qualification Procedure » (ref. : Policy document 1 Edition : 1.08). – ISO 9000 : Quality management systems – Fundamentals and vocabulary (edition date 20/12/2000). – ISO 9001 : Quality management Systems - Requirements (edition date 20/12/2000). – ISO 9004 : Quality management Systems - Guidelines performance improvement (edition date 20/12/2000).

for

– ISO 19011 : Guidelines for quality and/or environmental management systems auditing (edition date 01/10/2002).

A4.2. Conditions for application of the procedure Before submitting a product or system to the qualification procedure and quality audit procedure, one should not lose sight of the ratio « Interest versus Cost ». However the quality audit procedure will be automatically applied when a qualification is requested.

A4.2.1. Quality audit Procedure Requirements A Service or a firm should be audited if a qualification procedure of a product is required. That means to be applied : – it has to be used as test product (test tool) in the frame of the certification procedure ;

Annexe 4

211

– it is or shall be used by several services and Member States ; – it is or shall be used in several regional centres of several members States ; – it plays or shall play a critical role within a regional centres or a central system ; – it has or shall have an essential role – namely concerning the quality control (a test tool, for example) – vis-à-vis the functioning of a regional centres or a central system ; – it has or shall have an essential role – namely concerning the quality assurance (a production tool, for example) – vis-à-vis the functioning of a regional ATC centres or a central system.

A4.2.2. Pre-requisites A4.2.2.1. Technical pre-requisites The product has to have been duly verified and validated by the developer and/or the supplier. If need be, the product can already be operational on a particular site of Member States. In parallel, the technical qualification (including technical documentation reviews, code checking…) by a third party accredited laboratory should be done.

A4.2.2.2. Quality pre-requisites As it concerns the demander must be already obtain : – label (an accredited label from a recognised authority) ; – ISO 9001 :2000 certificate on the defined perimeter including product design and manufacturing processes (should be applied to the all of supplier body) ; – a proven in-house organisation and methodology with a internal audit planning and methodology. In this case the audit must be strengthened.

212

L’audit technique informatique

A4.2.2.3. Administrative pre-requisites The administrative request is the same pre-requisite defined for the qualification procedure. That means : A request (for qualification) has to be addressed by the requester to the Head of R.U Unit in due form in the prescribed periods, namely at least two months before the beginning of the evaluation work and at least four months before the expected date for the jury. Making this, the demander or requester has to designate a qualification correspondent (Project leader or Quality manager) and to allocate a budget for the procedure expenses.

A4.3. Outpout of the quality audit process A4.3.1. Quality audit report The main output of the quality audit process is the report made by the audit team (a framework of this report is shown in enclosure 1). This report will be given to the member of the qualification jury and to the audited service. A quality audit team will be set up for each product qualification and a report is specific for each qualification process. The audit team will also present the findings during the Jury Qualification Meeting.

A4.3.2. Recommandations Recommendations or suggestions could be also given by our quality audit team if necessary.

Annexe 4

213

All items giving « bad impact » to the quality system must be corrected and followed up and taken into account by the requester and the team in appropriate corrective processes (action plan).

A4.4. Phases of the quality audit procedure The audit procedure defines a process in five steeps.

A4.4.1. Diagram of the process (We give intentionally another format for the diagram vis-à-vis the previous one.) Step 1 : initialisation Supplier Request

AUDIT TEAM DESIGNATION

REFERENTIAL DETERMINATION

Step 2 : preparation PREPARATION AND PLANNING

214

L’audit technique informatique

Step 3 : audit processing Working Plan Schedule

KICK-OF MEETING

DOCUMENTATION REVIEW

INTERVIEWS

SUMMARY

Step 4 : audit reporting Technical evaluation (Laboratory)

AUDIT REPORT WRITTING

Audit Report

Annexe 4

215

Step 5 : follow up Correctives actions

CHECKING AND VALIDATION Action Plan

A4.4.2. A step by step procedure Step 1 : initialization After receiving the Decision of the high management or the external request, a quality audit team will be set up and a team lead designated. The context or environment and the referential will be fixed (an example of the product referential is shown in enclosure 2). Step 2 : preparation Working plan and all relevant documents must be prepared by the audit team and the audit schedule established. Step 3 : visit of audited services or firm Kick-off meeting : – documentation review ; – interviews ; – referential examination / comparison on the site ; – non conformity detection ; – summary report ;

216

L’audit technique informatique

Step 4 : audit report The quality team will establish an audit report. This report could be separated or integrated with the findings after the technical qualification process of the third party laboratory process (Possibility of a common report). Step 5 : follow up The phase consists in the follow up of the global process and focuses on the corrective actions or recommended actions (action plan). The effective set up of modifications and improvements must be checked.

A4.4.3. Validity The validity of an audit report is the same as the qualification approval for a given version of a product. It goes up to three years after the approval date. Any change in the system or if its use in another context automatically cancels the approval.

A4.4.4. Modulation A4.4.4.1. Expiration of the validity of an already qualified product In case of expiration of the validity of a product already qualified in a given version, a audit must be redone as the re-qualification is requested. But the procedure can be lightened and limited.

A4.4.4.2. Similarity with an already qualified product In case of a new version of a product already qualified in a former version, and in case of no changing context or environment the quality audit is not necessary. In case of a product of the same type as an already qualified product, the qualification procedure can be lightened and be based on a part of

Annexe 4

217

former results to focus on differences and in case the context or environment do not change, the quality audit is not necessary. Remark : security and safety products related. In case of a product or system involving security and safety aspects, the procedure has to be strengthened on some points like : – to stipulate two audit teams as well as two technical qualification and testing by two separated accredited third party laboratories ; – to stipulate a comparative analysis of the obtained audit results and technical reports. All results must be consistent. Enclosure 1 Framework of quality audit report Introduction To qualify a software tool, the qualification procedure for test tools (Policy document 1, edition number 1.8, dated 22/10/2002) is used. Context of the audit The presentation about supplier company. The explanation of software tool product or system to be audited. The software number version audited. Terms and definitions The explanations of special words used. Quality audit actions The quality audit has performed in the following actions : – requesting to the supplier for main product documentation ; – requesting to the supplier for certification documents ; – processing technical tests by independent testing laboratory (technical evaluation report) ;

218

L’audit technique informatique

– examining product documentation by our audit team (quality evaluation Report) ; – il necessary, asking for complementary questions to the supplier and examining answers ; – writing down this quality audit report. Quality documents examined The list of product and system development documents examined (product or system development referential). Certification documents The list of ISO documents examined (quality referential). Quality assurance measures The reported conclusions of the technical evaluation processed by the independent laboratory. Conclusion The quality audit team gives a positive/negative statement on this matter for the qualification jury.

Enclosure 2 Example of product referential – Configuration Management Plan. – Installation Manual. – ISO 9126 Quality Statement. – Operator’s Manual. – Project Management Plan. – Quality Assurance Plan. – System Change documents. – Technical description. – Verification and Validation Plan.

BIBLIOGRAPHIE

[BEE 89] de BEELLEFONDS L., Droit de l’informatique et de la télématique, Delmas, Paris, 1989. [FEU 05] FEUJO I., Guide des audits, Editions AFNOR, La Plaine SaintDenis, 2005. [GAV 86] LOUIS-GAVET G., Quelle méthode d’analyse implanter dans votre entreprise ?, Edition A.I.D.E, 1986. [KAE 00] KAEO M., Sécurité des Réseaux, Edition Campus Presse, Paris, 2000. [LAM 01] LAMPRECHT J., ISO 9001 : Commentaires et conseils pratiques, éditions AFNOR, La Plaine Saint-Denis, 2001. [LY 89] LY H., RALAY. G., L’audit informatique, théorie et applications progressives, Pochette de formation, 1989-1990. [LY 91] LY H., L’audit informatique dans un contexte mini et micro, Editions d’Organisation, Paris, 1991. [LY 05] LY H., TRABELSI Z., La sécurité sur Internet, Hermès-Lavoisier, Londres, 2005. [PIN 00] PINET C., La qualité du logiciel, Edition AFNOR, La Plaine SaintDenis, 2000. [PIN 05] PINET C., Processus d’ingénierie du logiciel, Edition Pearson, Paris, 2002. [THO 00] THORIN M., L’audit informatique, Hermès, Paris, 2000.

220

L’audit technique informatique

Revues 01 INFORMATIQUE 01 DSI - Informatique Décision Informatique Documents internes du service d’audit France Télécom 1991: Mission exploratoire pour l’audit informatique, 1991. France Télécom : document SERNIT (Service Informatique de France Télécom) 1989. Revue semestrielle interne de France Télecom.

LEXIQUE

A Avertissement : seuls les termes utilisés dans les études précédentes figurent dans ce lexique. De plus amples définitions devraient figurer dans les dictionnaires spécialisés. AFNOR : (Association française de normalisation localisée en Seine Saint-Denis). C’est une association de Loi 1901 dont le but est de normaliser les termes et les procédés dans différents domaines scientifiques et techniques. Agression : attaque sur une cible susceptible de provoquer un ou plusieurs sinistres. Agresseur : est une personne qui attaque ou craque un système. Cette personne est caractérisée par sa motivation, ses moyens, sa détermination et les faiblesses ou points faibles aperçus (ou faiblesse des risques aperçus). Application : ensemble des moyens logiques et physiques (fichiers, programmes, procédures...) conçus et mis en œuvre pour automatiser une ou des tâches pour et/ou par les utilisateurs. ASP : Active server pages est un package comprenant les facilités et le langage pour le développement des pages et applications pour le Web. Attaquant : autre terme générique, équivalent à l’agresseur ou désignant les pirates, les crakers ou hackers.

222

L’audit technique informatique

Automatisation : transformation d’un procédé, d’un processus ou d’une installation en vue de les rendre automatiques (AFNOR). B Backdoor : ce terme désigne une faille d’un système que l’on peut traduire par port de derrière, porte dérobée ou trappe suivant l’utilisation dans des contextes différents. Elle pourrait aussi être mise en place exprès par les constructeurs ou fournisseurs de service afin de pouvoir accéder au système et reprendre la main pour un dépannage urgent et/ou à distance. Back-up : ensemble de moyens mis en oeuvre pour sauvegarder tout le système sur bande magnétique ou sur cassette par l’intermédiaire du Stremer (cas du micro-ordinateur), et pour restaurer ces informations en cas de besoin. Par extension, un centre back-up est un site de secours à partir duquel on peut redémarrer l’exploitation. Banque de données : (data bank en anglais). Dans un domaine défini, l’ensemble de fichiers structurés pouvant être consultés par divers utilisateurs. Ces fichiers sont gérés soit par un SGF (Système de Gestion de Fichiers classique), soit par un SGBD (Système de Gestion de Base de données). Bastion : un système auquel tous les systèmes ou réseaux étrangers doivent se connecter pour accéder à un système ou un service qui se trouve à l’intérieur du Firewall. Un bastion est un élément constituant du Firewall. C’est le premier élément de contact avec l’extérieur. BBK (Black Blue Key) : mot d’origine anglo-saxonne désignant des points clefs colorés en noirs ou en bleus. En fait, ce sont des bilans brefs mettant en valeur, les points forts (notés BBK+) et les points faibles (notés BBK-). Boot strap : programme amorce. Ce programme est intégré‚ en mémoire morte et a pour but de permettre le chargement du noyau du système d’exploitation (le Moniteur) à partir d’un disque ou d’une disquette. Bugs : les bugs sont des erreurs de programmes. Ce mot a pour origine erreur de programme de système ou de logiciel de base. Par abus de langage, faire un bug correspond à trouver et rectifier l’erreur des instructions dans un programme.

Lexique

223

C Canal : c’est l’unité d’échange dans un environnement informatique. C’est un processeur d’entrée/sortie ou input/output exécutant des « programmes » de transfert. Canal multiplexé : c’est un canal qui peut réaliser plusieurs transferts « simultanément », on peut comparer à une sorte de Time-sharing sur les contrôleurs connectés. Ce type de canal est réservé pour les périphériques classiques plus lents tels que les imprimantes. Canal simple : réservé pour les disques rapides, ce type de canal n’exécute qu’un transfert entre l’accusé du signal SIO et le traitement de l’interruption de fin d’entrée/sortie. Check-list : aide mémoire ou liste d’un questionnaire libre (utiliser pour faire un check : à un contrôle). Command line interpreter : analyseur et interpréteur de lignes de commande (voir noyau du système d’exploitation). Configuration : composition physique et logique d’un ordinateur et des organes périphériques. Cette composition doit être précisée ou déclarée au Moniteur lors de la génération du système. Configurer : faire une génération d’un système, d’un logiciel ou d’un outil adapté avec l’environnement d’exploitation. Cible : actif d’une société ou organisation susceptible d’être visé ou atteint par un sinistre. La cible est souvent fonction de l’attrait, de l’identité de la victime et des vulnérabilités connues. Coupe-feu : voir firewall, pare-feu. D Débugger (un système) : ce terme signifie corriger un système ou un programme compromis soit accidentellement soit suite à une attaque. Discovery Tool : provenant de l’anglais, ce mot qui est utilisé fréquemment dans l’informatique désigne les outils de découverte ou de reconnaissance pour scanner et obtenir les informations des systèmes. Les pirates les utilisent pour détecter leurs systèmes cibles.

224

L’audit technique informatique

Directory : fichier répertoire maître ou l’annuaire système indexant l’emplacement des divers fichiers. Si le directory est corrompu, on ne peut plus accéder aux fichiers. E E-mail : courrier électronique provenant de l’anglais « electronic mail », parfois s’écrit émail. F F.A.I : fournisseur d’accès Internet, on désigne aussi souvent les fournisseurs de portail. Par exemple : Wanaadoo, AOL… Faille : point faible qu’un attaquant pourrait attaquer, voir aussi « failles de vulnérabilité ». Facteur de menace : terme désignant un ensemble ou un couple de cible et d’agresseur. On note souvent de la manière suivante : facteur de menace = couple (cibles(s), agresseur(s)). Failles de vulnérabilité : d’un système (hardware ou software) ou d’un réseau. Elles sont de plusieurs types : organisationnelles, procédurales du personnel, de gestion et/ou d’administration, du logiciel et/ou du matériel… Firewall : appelé aussi coupe-feu, pare-feu, le firewall un ensemble d’éléments dont le rôle est de séparer, analyser, limiter les entrées et sorties indésirables. C’est un ensemble constitué de matériel (routeurs, ponts, ordinateurs) et de logiciels appropriés. Par abus de langage, on utilise ce mot pour désigner un logiciel seulement. H Hôte : système physique (ordinateur) rattaché à un réseau. HTML : Hypertext Macro Language est un langage de développement pour les hypertextes, conçu vers les débuts des années 90. HTTP : Hypertext transfert protocol est un protocole technique servant à transférer les hypertextes, conçu vers le début des années 90.

Lexique

225

I Informatique : définition de l’Association française de normalisation (AFNOR) : ensemble des disciplines scientifiques et techniques spécifiquement applicables en traitement de l’information effectué notamment par des moyens automatiques. Informatisation : processus d’automatisation des activités‚ d’une chaîne de traitement des processus avec des outils informatiques (qui amène souvent des implications sur l’organisation), appelé aussi « automatisation » par abus de langage. Internet : principal composant de la toile mondiale www, développé après elle, à ne pas confondre avec cette dernière, mais par abus de langage on les associe souvent ensemble. J JAVA : est un puissant langage de programmation réseau dont l’initiateur est la firme Sun Microsystems. Java est disponible sur le Web (voir page adresse Web intra). JCL : (d’origine anglo-saxonne signifiant Job Control Language) : langage de commande des tâches ou travaux avec lesquels on exprime les ordres au système d’exploitation pour lancer des programmes et leur mise en correspondance avec les diverses ressources. L LAN : ce terme venant de l’anglais Local Area Network désigne les réseaux locaux internes des entreprises. Logiciel : au départ, ce terme désigne un ensemble de programmes et de procédés pour utiliser et exploiter un ordinateur (logiciel de base). Par extension, on l’utilise pour désigner les programmes d’une application spécifique (ex: logiciel de paie, de comptabilité..). Très souvent par abus de langage, on l’utilise pour désigner un progiciel (ex : logiciel Word). Loi Sarbanes-Oxley : cette loi est adoptée en juillet 2002, faisant suite aux déboires financiers et malversations, par le Congrès américain (appelée aussi SARBOX ou LSO en français). Elle oblige

226

L’audit technique informatique

les entreprises à répondre de certaines prérogatives. Il importe de noter deux éléments importants relatifs à cette loi : – les entreprises non-américaines sont aussi concernées ; – les systèmes d’information sont impliqués à double titre aussi. A savoir, d’une part, dans l’utilisation de l’informatique comme outil de gestion et de contrôle financier et d’autre part dans l’obligation d’assurer la sécurité de ce même système informatique (nouveauté de cette loi). M Mail fake : de faux e-mail avec usurpation d’identité de l’envoyeur. Main-frame : mot d’origine anglo-saxonne de la firme IBM signifiant ordinateur central ou principal. MTBF : Mean Time Between Failures (délai moyen entre les incidents). MTTR : Mean Time To Repair (durée moyenne entre les réparations ou les incidents). Multiprogrammation : (en anglais Multiprogramming) mode d’exploitation d’un ordinateur dans lequel plusieurs programmes utilisateurs sont actifs à la fois, c’est-à-dire chargés en mémoire centrale et exécutables par l’unité de traitement. Multitraitement : (Multi-processing) à ne pas confondre avec le mot précédent. Possibilité d’un système de coordonner et de déclencher le déroulement simultané de plusieurs processus. Pour ce faire ce système doit posséder plusieurs types de processeurs. Menace : conjonction de facteurs susceptibles de favoriser le déclenchement d’une agression (voir aussi facteur de menace). N Noyau du système : appelé souvent moniteur ou noyau système d’exploitation, il comporte un ensemble de routines ou instructions permettant la commande du ou des périphériques appelés BIOS (Basic Input Output System) et un programme exécutif permettant un dialogue sommaire avec l’utilisateur. En fait, il comprend aussi le module d’analyseur des commandes.

Lexique

227

O Operating system : voir système d’exploitation. Overlap : recouvrement (par exemple : recouvrement des réseaux ou des systèmes). P Password : mot de passe, chaîne de caractères indispensables pour accéder à un système, à un fichier. En général le système ne tolère pas plus de trois erreurs ou tentatives d’accès. On dit aussi que le système est contrôlé par une clef d’accès. Path : chemin ou moyen de modification directe du contenu d’un fichier ou d’un programme objet (modification sur un octet ou sur des bits d’un octet). En micro-informatique, dans le langage MS-DOS, ce mot indique le chemin d’accès à un fichier ou à un répertoire (Directory). Patcher : patcher un système est utiliser pour désigner modifier ou apporter une correction du système avec des éléments apportés par l’ingénieur système ou par le fournisseur. Pare-feux : traduit de l’anglais firewall, on appelle aussi les coupefeux (voir le mot Firewall). PERL : ce terme venant de l’anglais (Pratical Extraction and Report language) est très populaire pour la programmation réseau. Exécutable sur plusieurs plates-formes (en particulier sous Unix, Windows NT), le Perl est disponible sur le Web (voir définition cidessous. Processeur : dispositif constitué d’une unité de traitement, des mémoires, des registres et qui permet l’exécution d’un programme et/ou des opérations logiques et arithmétiques. Processus : ensemble de tâches ou fonctions exécutées par un processeur. Progiciel : ensemble complet et document‚ de programmes conçus pour être fournis à plusieurs utilisateurs ou clients en vue d’une même application (définition du JO du 7 décembre 1981).

228

L’audit technique informatique

R Remote : ce terme désigne les éléments distants. Voir exemple cidessous Remote jobs : travaux exécutés à distance ou lancés à distance. Remote système : système distant. Répertoire : voir Directory. Réseau périphérique : appelé aussi réseau DMZ, De-militarized Zone (no man’s land, Zone démilitarisée), le réseau périphérique est un dispositif particulier implémenté (additionnel) entre le réseau extérieur et le réseau que l’on veut protéger. Ressource : d’une manière générale, quand on parle de « ressource » on définit l’ensemble moyen : des ressources physiques ou matérielles et les ressources logicielles. Ressources matérielles : Unité centrale, mémoires centrales ou auxiliaires, périphériques, unité de liaison ou unité d’échange. Ressources logicielles : logiciel exploitation, logiciel de service et/ou logiciel d’application. Restauration : ayant pour origine Restore. Opération inverse de la sauvegarde afin de générer une partie ou la totalité du système lors d’un plantage. On utilise aussi ce terme pour restaurer des fichiers écrasés lors d’une fausse manipulation. Risque : hasard que l’on court d’une perte ou d’un dommage. Peut être aussi considéré comme un évènement potentiel engendrant des pertes ou dommages. L’occurrence d’un risque résulte de l’application d’une menace sur une vulnérabilité (voir ce mot). S SATAN : nom d’un outil d’analyse et de sécurité pour les administrateurs de réseaux venant de l’anglais : Security Administrator Tool for Analyzing Networks conçu par Dan Farmer et Weitse Venema. Script : séquence d’instruction exécutée par un programme ou par des interpréteurs. Exemple : script de Java ou pour Active X.

Lexique

229

SIO : le Start input Output désigne le signal de début d’un processus d’entrée/sortie qu’un canal reçoit. Sinistre : rupture non souhaitée, dégageant des pertes potentielles par rapport à un état antérieur considéré comme stable ou normal. SSH : Secure Shell, le Shell sécurisé préconisé dans l’utilisation des transactions délicates et confidentielles employant les RPC (Remote Procedures Call) pour éviter le piratage. SSF : version française à utiliser obligatoirement car toutes transactions secrètes et utilisant le cryptage doivent être déclarées aux gouvernements. SSL : venant de l’anglais « Secure Socket level », le SSL est un système de cryptage des données entre un navigateur et un serveur Web. Superviseur : (dans un système informatique), c’est l’ensemble des modules du système d’exploitation qui gère le fonctionnement de l’ordinateur et assure le bon déroulement des travaux des utilisateurs. Les fonctions principales du superviseur sont : gestion des ressources physiques, gestion des travaux, des données, des processus, des liens entre les tâches, des anomalies et protection contre diverses erreurs de manipulation ou d’accès aux ressources. Superviseur : (dans un service d’audit), c’est la personne responsable d’une mission d’audit et d’un ou deux auditeurs juniors. Il est le chef de mission qui détermine ou valide le planning, les sites à visiter et gère éventuellement le budget de ladite mission. Système d’exploitation : c’est un ensemble de programmes exprimés en langage machine binaire translatable (non résident) ou absolu (résident) qui sont chargés dans l’ordinateur, et dont l’exécution permet l’exploitation de ses ressources, de traiter automatiquement les programmes utilisateurs. Appelé‚ aussi software ou logiciel de base, dans un cas simple, ce système d’exploitation se réduit à un moniteur de 2 à 5 kilo octets résidant en mémoire morte (surtout dans les microordinateurs).

230

L’audit technique informatique

T Temps partagé : (Time sharing en anglais). Le traitement en temps partagé est le mode d’utilisation d’un ordinateur en temps réel à l’échelle humaine (réponse de l’ordre de quelques secondes). Plusieurs utilisateurs se partagent le service de l’ordinateur dans une même durée de temps. Chaque utilisateur a la sensation que toutes les ressources de la machine lui sont accessibles. Temps réel : (real time en anglais). Le système en temps réel est un système permettant l’exécution rapide de processus et pouvant réagir rapidement lors d’un changement de contexte ou d’un nouvel évènement. L’utilisateur peut agir avec des paramètres en cas de besoin. Système très utilisé dans un contexte de processus industriel. V VNC : issue de l’anglais « Virtuel Network Computing », ce terme désigne les programmes ou utilitaires permettant d’utiliser un réseau virtuel par l’administrateur afin de gérer ses systèmes distants. Vulnérabilité : ensemble de conditions ou failles susceptibles de favoriser la réussite d’une agression peut être vue comme un couple C (cible, agression). W Web : en informatique, ce terme désigne la toile des réseaux. Il est aussi utilisé pour identifier le réseau des documents HTML, reliés entre eux et diffusés sur les différents serveurs de par le monde.

COLLECTION MANAGEMENT

ET INFORMATIQUE

sous la direction de Nicolas Manson

Alain Amghar – Conduite opérationnelle des projets, 2004 Alain Berdugo – Guide du management des SI, 2001 Alain Berdugo – Le maître d’ouvrage du SI, 1997 Alain Berdugo et Pierre Aliphat – Systèmes informatiques de l'entreprise, 1997 Gilles Blanchard et André Vincent– La fonction achat en informatique et télécoms, 1999 Jean-Christophe Bonne et Aldo Maddaloni – Convaincre pour urbaniser le SI, 2004 Jean-Pierre Briffaut – Processus d'entreprise pour la gestion, 2004 Didier Caron – Méthodes objet, 1997 Jean-Pierre Corniou – La société de la connaissance, 2002 Denis Debaecker – PLM — La gestion collaborative du cycle de vie des produits, 2004 Bernard Debauche et Patrick Mégard – BPM, Business Process Management, 2004 Alain Desroches et al. – La gestion des risques, 2003 Tru Dô-Khac – Externalisation des télécoms d’entreprise, 2005 Luc Dorrer – Hommes et projets informatiques, 2004 Philippe Fenoulière – Vers une informatique ouverte, 2004 Philippe Fenoulière – La qualité de l’informatisation, 1996 Franck Franchin et Rodolphe Monnet – Le business de la cybercriminalité, 2005 Jean-François Gautier et Alan Fustec – Informatique de compétition, 1997 Thierry Harlé et Florent Skrabacz – Clés pour la sécurité des SI, 2004 Pierre Jaquet – Les réseaux et l’informatique d'entreprise, 2003

II

Collections sous la direction de Nicolas Manson

Gérard Jean – Urbanisation du business et des SI, 2000 Didier Joliot – Management des SI, 2003 Didier Joliot – Performances des SI, 2003 Henri Kloetzer – La maîtrise d'ouvrage des projets informatiques, 2002 Pierre Laigle – Dictionnaire de l’infogérance, 2000 Jean-Luc Lapon – La direction informatique et le pilotage de l’entreprise, 1999 Bernard Le Roux et al. – Urbanisation et modernisation du SI, 2004 Pierre Maret – Ingénierie des savoir-faire, 1997 Jean-Pierre Meinadier – Le métier d'intégration de systèmes, 2002 Dominique Moisand – CRM, gestion de la relation client, 2002 Pascal Muckenhirn – Le SI décisionnel, 2003 Gilbert Nzeka – La protection des sites informatiques face au hacking, 2005 Jean-Louis Peaucelle – Informatique rentable et mesure des gains, 1997 Dany Provost – An 2000, la transition réussie, 1998 Luc Rubiello – Techniques innovantes en informatique, 1997 Alain Rugy (de) – Management et gestion du parc micro, 1998 Jacques Sassoon – Urbanisation des SI — épuisé, 1998 Pascal Silvestre – Le développement des SI, 1996 Marcel Soberman – Développement rapide d'applications, 1996 Sys-com – La bascule du SI vers l’euro – 2ème édition, 2000 Philippe Tassin – Systèmes d'information et management de crise, 2005 Marc Thorin – L’audit informatique, 2000 Zouheir Trabelsi et Henri Ly – La sécurité sur internet, 2005

Collections sous la direction de Nicolas Manson

III

Jean-Pierre Vickoff – Estimation et architecture des développements Agiles, 2005 Jean-Pierre Vickoff – Systèmes d'information et processus Agiles, 2003

COLLECTION ETUDES

ET

LOGICIELS INFORMATIQUES

sous la direction de Nicolas Manson

Alain Amghar et Frédéric Sitbon – Microsoft Office Project 2003, 2004 Yves Constantinidis – Le logiciel à valeur ajoutée, 2001 Yves Constantinidis – Outils de construction du logiciel, 1998 Erol Giraudy et al. – Le portail Microsoft Sharepoint, 2004 Guy Lapassat – Architecture fonctionnelle des logiciels, 2003 Guy Lapassat – Urbanisme informatique et architectures applicatives, 2003 Jean-Pierre Meinadier – Ingénierie et intégration des systèmes, 1998 Michel Priem – Trafic et performances des réseaux multi-services, 2004 Jacques Printz et al. – Coûts et durée des projets informatiques, 2001 Jacques Printz – Productivité des programmeurs, 2001 Jacques Printz – Puissance et limites des sytèmes informatisés, 1998 Yvon Rastetter – Le logiciel libre dans les entreprises, 2002 Marcel Soberman – Les grilles informatiques, 2003 Sys-com – Stratégie de test e-business, 2001 Spyros Xanthakis et al. – Le test des logiciels, 2000

COLLECTION NOUVELLES

TECHNOLOGIES INFORMATIQUES

sous la direction de Nicolas Manson

Jean-Louis Bénard – Les portails d'entreprise, 2002 Jérôme Besancenot et al. – Les systèmes transactionnels, 1997 Christian Bonjean – Helpdesk, 1999 Jean-Pierre Briffaut – Systèmes d’information en gestion industrielle, 2000 Jean-François Goglin – La cohabitation électronique, 2005 Jean-François Goglin – La construction d'un datawarehouse – 2ème édition, 2001 Jean-François Goglin – Le Datawarehouse, pivot de la relation client, 2001 Jean-François Goglin et Philippe Usclade – Du client-serveur au web-serveur, 1999 Marc Langlois et al. – XML dans les échanges électroniques, 2004 Bernard Manouvrier – EAI, Intégration des applications d'entreprise, 2001 Norbert Paquel et Olivier Bezaut – XML et développement des EDI, 2002 René-Charles Tisseyre – Knowledge Management, 1999

COLLECTION SYNTHÈSE INFORMATIQUES CNAM sous la direction de Nicolas Manson

Florent Bastianello – L’informatique, mémoire de l’entreprise, 1996 Jean-André Biancolin – Temps réel, 1995 Bruno Dardonville – Architecture de Windows NT, 1996 Hervé Guitter – La compression des images numériques, 1995 Renaud Hilleret – Stockage des données distribuées, 1996 Jean-Marc Lê – Les systèmes de télécoms mobiles, 1998 Lionel Mallordy – Répartition d’objets dans les bases de données, 1995 Christophe Pasquier – L'approche objet, 1995 Catherine Pérou – La dépense informatique en France, 1996 Ricardo Ruiz – Systèmes de gestion de bases de données orientés objet, 1997 Laurent Schneider – Logiciels serveurs et outils d’administration pour le web, 1997 Philippe Vetter – Calcul coopérant par passage de messages, 1995 Bernard Weiss – ATM, 1995 Bernard Zignin – Les techniques du multithread, 1996