Audit informatique

Préalablement à l'examen des critères, la législation communautaire impose un
travail de recevabilité des demandes d'octroi des certificats. ..... Il en est de même
de la certification ISO 28001: 2007 pour ce qui concerne ...... ISO 27001 : 2005.

Part of the document

PLAN DU COURS CHAPITRE 1 : AUDIT DES SYSTEMES D'INFORMATIONS 2
1.1. INTRODUCTION A L'AUDIT DES SYSTEMES D'INFORMATION 2
1.2. DEFINITION DE L'AUDIT INFORMATIQUE 2
1.3. TYPE D'AUDIT 3
A).L'AUDIT DU BESOIN 3
B).AUDIT DE DECOUVERTE DES CONNAISSANCES 4
CHAPITRE 2. LES PRINCIPES GENERAUX DE L'AUDIT INFORMATIQUE 6
2.1. REGLES D'AUDIT 6
2.2. DEONTOLOGIE 9
2.3. CONSIDERATIONS SUR L'ERREUR 10
2.4. POLITIQUE INFORMATIQUE ET SCHEMA DIRECTEUR 13
CHAPITRE 3 : SCHEMA CONCEPTUEL DE L'AUDIT INFORMATIQUE 14
3.1. PHASES DE L'AUDIT DES SYSTEMES D'INFORMATIONS 14
3.2. CATEGORISATION D'AUDIT INFORMATQUE 14
3.2.1. AUDIT DE L'ENVIRONNEMENT INFORMATIQUE 14
3.2.2. AUDIT D'UNE APPLICATION INFORMATIQUE 15
3.2.3. AUDIT D'UNE APPLICATION EN COURS DE DEVELOPPEMENT 15
3.2.4. AUDIT ET SECURITE INFORMATIQUE 15
CHAPITRE 4 : POLITIQUE DE SECURITE INFORMATIQUE 16
4.1. SECURITE DE L'INFORMATION 16
4.3. PROCESSUS DE SECURITE DE L'INFORMATION 17
4.4. DOMAINE D'APPLICATION (SELON L'ISO) 17
4.5. STRUCTURE DE LA NORME (SELON L'ISO) 18
4.6. TABLEAU DE BORD DE LA POLITIQUE DE SECURIT INFORMATIQUE 18
CHAPITRE 5 : PLANIFICATION ET ORGANISATION DANS L'AUDIT INFORMATIQUE 20
5.1. LE PLAN STRATEGIQUE INFORMATIQUE 20
5.2. LA PRE EVALUATION OU SELF ASSESSMENT 24
5.3. FORMATION DES UTILISATEURS A LA SECURITE INFORMATIQUE 26
5.4. FORMATION A LA SECURITE ET A L'AUDIT INFORMATIQUE 26
CHAPITRE 6 : AUDIT INFORMATIQUE DANS UNE PEM 29
6.1. COMMENT CHOISIR SON PRESTATAIRE 29
6.2. LES PRINCIPALES ETAPES D'UN AUDIT INFORMATIQUE 30
6.3. QUE REPRESENTE UN AUDIT 31
A).EN TERMES DE COUT POUR L'ENTREPRISE 31
B) ET EN TERMES D'ECONOMIES 31
BIBLIOGRAPHIE CHAPITRE 1 : AUDIT DES SYSTEMES D'INFORMATIONS
1.1. INTRODUCTION A L'AUDIT DES SYSTEMES D'INFORMATION
L'audit informatique, l'audit des systèmes d'information évalue les
risques d'un environnement informatique ou d'une application, par exemple,
les salaires ou la facturation. Ces missions se font en choisissant avec le
client les processus métiers à évaluer, de même que les processus CobiT à
évaluer parmi les 34 proposés.
L'audit d'un environnement informatique peut concerner l'évaluation des
risques informatiques de la sécurité physique, de la sécurité logique, de
la gestion des changements, du plan de secours, etc. Ou bien un ensemble de
processus informatiques - ce qui est généralement le cas - pour répondre à
une demande précise du client. Par exemple, apprécier la disponibilité des
informations et des systèmes. Le CobiT permet justement de rechercher quels
processus informatiques répondent le plus efficacement à une telle demande.
Dans le cas de la disponibilité : par exemple la sécurité physique et le
plan de continuité. 1.2. DEFINITION DE L'AUDIT INFORMATIQUE L'audit informatique (appellé aussi audit des systèmes
d'information) est l'évaluation des risques des activités informatiques,
dans le but d'apporter une diminution de ceux-ci et d'améliorer la maîtrise
des systèmes d'information.
L'auditeur se base sur les référentiels suivant:
. COBIT (décrivant le fonctionnement complet d'un service informatique)
. norme ISO 1.3. TYPE D'AUDIT Il existe deux types d'audit informatique
- l'audit du besoin ;
- l'audit de découverte des connaissances. A).L'AUDIT DU BESOIN Comporte deux parties :
. l'analyse de l'existant ;
. la détermination de la cible.
A.L'analyse de l'existant : consiste en un travail de terrain au terme
duquel on formalise la circulation des documents "types" d'un acteur à
l'autre et le traitement que chaque acteur applique à ces documents, à
l'aide de logigrammes (traitements sur les documents) et de représentation
de graphes relationnels (circulation des documents).
La détermination de la cible consiste à repérer :
. les passages "papier - numérique" et "numérique - papier" ;
. les redondances dans le graphe ("formulaires en plusieurs
exemplaires") ;
. les goulots d'étranglement (dispersion des infrastructures, points de
contrôle et validation nécessaires ?) ;
. le découpage en zones, en sous-graphes : les domaines "métier". Ainsi
chaque zone peut être dotée d'un outil spécifique, plutôt qu'un seul
système global "usine à gaz".
Ainsi le résultat de l'audit, généralement élaboré et approuvé
collectivement, peut donner lieu non pas à un projet, mais plusieurs
projets ordonnancés dans une feuille de route. B).AUDIT DE DECOUVERTE DES CONNAISSANCES L'audit de découverte des connaissances consiste à valoriser les
données et connaissances existantes dans l'entreprise. La modélisation
mathématique des bases de données oblige toujours à "perdre" une partie de
l'information, il s'agit de la redécouvrir en "brassant" les données.
Un audit de découverte des connaissances aboutit généralement au
montage d'un système décisionnel, mais également être le prélude à un
système de gestion des connaissances.
L'audit de découverte des connaissances se pratique de la manière
suivante :
. Pas d'objectifs : on ne sait pas ce que l'on va découvrir ;
. Un domaine : on sait sur quels métiers on travaille, donc sur quelles
bases de données ;
. une équipe intégrée : travaille in situ, trois acteurs dont un expert
"métier", un expert "administration informatique" et un fouilleur de
données (voir data mining)
. Le travail se fait par boucle courte de prototypage
. Pour faciliter le brassage des données, on modifie leur format et leur
disposition relative. C'est le "preprocessing" qui prend le plus de
temps
. À l'aide d'algorithmes à apprentissage d'une part, et de
visualisations de données d'autre part, le fouillleur met en évidence
des liens empiriques entre les données
. Les corrélations et liens retenus doivent répondre à trois critères :
inconnu de l'utilisateur, explicable a posteriori et utile. La
démonstration théorique du phénomène est totalement superflue.
. Les connaissances détectées sont formalisées (arbres, graphes,
tableaux, règles, etc.) puis prototypées logiciellement
. La validité des connaissances prototypées est vérifiée grâce à un test
statistique (khi deux, kappa, etc.) sur un jeu de données dit "test
set", différent du jeu ayant servi à l'analyse ("training set")
. Le test set peut être soit externe au training set, soit recalculé à
partir de lui (rééchantillonnage)
. Si le test est passé, le modèle est mis en production
. On recommence le cycle.
Concrètement, l'empilement des modèles, eux-mêmes parfois complexes (arbres
et récursivité) peuvent aboutir à de vrais problèmes d'architecture
informatique :
. Parallélisassions des calculs
. Volumétrie des données
. Charge du réseau, en partie due aux mécanismes de réplication
D'un autre côté, le résultat de calcul issu d'un empilement de modèles peut
aboutir à des résultats particulièrement pertinents et surprenants.
CHAPITRE 2. LES PRINCIPES GENERAUX DE L'AUDIT INFORMATIQUE Le principe et les règles d'audit suivent logiquement ce qui suit :
D' abord, comme dans toute branche de l'activité d'une entreprise,
l'audit doit exister en informatique, et même davantage en fonction des
vulnérabilités et des coûts qu'elle induit. Un audit informatique n'a de
sens que si sa finalité est définie : contrôle fiscal, juridique, expertise
judiciaire, vérification de l'application des intentions de la direction,
examen de l'efficacité ou de la sécurité d'un système, de la fiabilité
d'une application, etc.
Exemple. - Une « évaluation du système informatique», pourtant
souvent proposée commercialement, n'a aucun sens. Le terme implique une
notion de valeur, donc chiffrée, subjectivement avec une référence par
conséquent, alors qu'aucune notation n'a de fondement objectif. Ne sont
fondées que des approches par aspects sur objets, exprimées concrètement
par « tel composant du système, sujet de la mission, présente telles
qualités et tels défauts ».PRINCIPE.- Auditer rationnellement est
expliciter es finalités de l'audit, puis en déduire les moyens
d'investigation jugés nécessaires et suffisants. Pratiquement, c'est
apprécier dans un but précis, et une situation concrète observée (le «
comment »), l'application du principe et des règles (le « pourquoi »). 2.1. REGLES D'AUDIT Quel que soit le type de l'audit (interne ou externe, contractuel
ou légal, etc.), la finalité est toujours de porter un jugement sur le
management du système d'information et l'exécution de ses objectifs.
C'est donc la comparaison entre ce qui est observé (un acte de
management ou d'exécution) et ce que cela devrait être, selon un système de
références. Il est clair que le jugement ne peut se limiter à une
approbation ou plus souvent à une condamnation, qui serait totalement
inutile en soi aux audités, mais préciser ce qu'il aurait fallu faire, et
ce qu'il faudra faire pour corriger les défauts constatés. Exemple.-
Une conclusion peut être que la documentation d'une application est
globalement compréhensible, mais qu'il faut la mettre à jour car elle n'est
plus exactement en phase avec la maintenance de la dernière année, qui a
négligé
Ce point. REGLE.- L'audit informatique consiste à comparer
l'observation d'un ou plusieurs objet(s), selon un ou plusieurs aspects, à
ce qu'il(s) devrai(en)t être, pour porter un jugement et faire des
recommandations. Porter un jugement sur le management du système
d'inform