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:
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’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. L’audit informatique
La tâche de l’auditeur est parfaitement
définie quand l’objet et l’aspect le sont. Et elle ne doit pas en déborder. Exemple.–
S’il lui est demandé de vérifier la sécurité d’une application, et qu’il en est
satisfait, il est complètement indifférent de savoir si les résultats en sont
exacts, car c’est une question de fiabilité ; ou qu’ils sont absolument
inutiles, car il s’agit d’adaptation. En effet, l’auditeur ne doit jamais
remettre en cause la finalité de son audit en fonction de ce qui est plus simple,
ou plus intéressant de faire, selon ses goûts. Il est beaucoup plus facile de
formuler cette règle que de l’appliquer : qui n’a tendance à la transgresser, surtout
si des lacunes évidentes mais hors mission se révèlent ?
Les règles sont identiques à celles du
management, sauf une, la faisabilité. En supposant que les moyens attribués
sont suffisants, et s’en assurer fait partie de la négociation préalable, et
que l’auditeur est compétent, la non-faisabilité impliquerait que le système
est incontrôlable, pratiquement par absence
Objectifs et audit informatiques de
documentation. Et alors la conclusion immédiate est qu’il a tous les défauts
possibles. Exemple.– Un cas réel est celui d’une entreprise dont il était
demandé d’examiner la fiabilité du sous-système comptable, avec une prévision
de plusieurs semaines de travail : en quelques heures, l’application écrite en
langage proche de la machine, aucunement documentée, reposant sur un système de
bases de données et un gestionnaire de télécommunications maison, avec un
nombre très réduit d’informaticiens compétents, tous indisponibles (ils étaient
toujours absorbés par la réparation de pannes) devait conclure à la
non-fiabilité et en prime à toutes les observations critiques concernant les
aspects vus plus haut. REGLE.– L’audit informatique est toujours faisable
(contrairement au management de l’informatique).Le travail d’audit peut être
assez complexe, et donc il doit obéir aux mêmes règles que le management, et en
particulier être découpé en fonctions conduisant L’audit informatique de façon
arborescente à un plan avec des étapes significatives de conclusions
partielles. Mais le maillon le plus faible de sa démonstration est bien entendu
celui qui remet tout en cause. Exemple.– Si la mission concerne la sécurité d’une
application de gestion du personnel, l’auditeur peut éluder avec accord du
demandeur les questions de plan et de budget ; il lui faudra examiner à fond
mais sous le seul aspect de sécurité et dans la mesure où ils concernent cette application,
les matériels et logiciels, les ressources humaines, les contrats, les
méthodes, et enfin les réalisations et leur exploitation.
Cela fait, et puisqu’il a examiné tous les
objets concernés selon l’aspect demandé, les conclusions de l’auditeur seront
certaines et inébranlables
Les moyens et actions de l’auditeur doivent
être adaptés exclusivement mais exhaustivement au sujet de l’audit.Cela
implique naturellement l’évolutivité (ouverture de recommandations sur
l’avenir, et non simple Objectifs et audit informatiques constat d’échecs), la
cohérence et la planification des ressources, bien entendu l’exactitude
(fiabilité) des conclusions.
La sécurité de l’audit ne s’applique qu’aux
documents de travail et aux rapports, à leur non-diffusion hors destinataires
autorisés, donc doit aller de soi. L’avancement des travaux doit être logique
comme une démonstration mathématique, donc arborescente dans un sens voisin du
précédent : « pour prouver telle affirmation, il faut s’assurer de tels et tels
faits et pour prouver tel fait, il faut le décomposer en tels et tels points,
etc. ».
Exemple.–
Pour prouver qu’une application de gestion du personnel est sûre, et à supposer
que le demandeur ne soit pas intéressé par un examen de ses finalités ni des
moyens financiers en ce domaine, il faudra examiner les sécurités du matériel
et du logiciel de base, y compris les réseaux, utilisés par cette fonction,
examiner toujours sous le seul angle de la sécurité les diagrammes de
circulation d’information et les responsabilités (fiches de fonction) de chaque
L’audit informatique membre du personnel impliqué, les méthodes et les
programmes sensibles de l’application, les saisies d’informations, les
recyclages d’anomalies, la bibliothèque. Alors seulement l’auditeur pourra
affirmer avoir fait une étude exhaustive et trouvé toutes les failles possibles.
2.2. DEONTOLOGIE
Il s’ensuit que l’auditeur doit obéir, de soi-même car en dehors des
responsabilités juridiques rien ne l’y oblige, à une déontologie certaine.
C’est ainsi qu’il doit :
– s’interdire de cumuler audit et conseil, sur une même question : comment auditer quelque
chose que l’on a conseillé, ou bien recommander de prendre son conseil ?
Pourtant il existe des sociétés proposant simultanément conseil, service et
audit ; l’intérêt de proposer un audit qui recommandera de prendre un conseil
de réalisation, puis le conseil proposant un service, le tout effectué par la
même société, laisse à réfléchir sur l’objectivité dans l’intérêt du client.
On Objectifs et audit informatiques a même vu
un constructeur proposer des audits gratuits, dont la conclusion était assez
attendue ; garantir, même implicitement par simple acceptation d’une tâche,
qu’il a, par lui-même ou grâce à une équipe sur laquelle il peut compter, les compétences
nécessaires ; elles ne sont aucunement Supérieures à celles des réalisateurs,
mais différentes, sur un substrat technique partiellement commun ; il ne s’agit
que d’attitudes, presque purement psychologiques: l’auditeur n’a pas besoin du
souffle ni des connaissances approfondies qu’il faut pour mener à bien une
réalisation, mais il doit être rapide, précis, avec juste les connaissances
ponctuelles nécessaires et suffisantes ;– s’intéresser au système d’information
dans son ensemble, c’est-à-dire pas aux seuls éléments automatisés, ou au contraire à ceux qui ne le sont pas ;–
fournir des conclusions motivées, utiles, sur l’objet et l’aspect, ainsi que la
période de temps qui a dû être considérée, qui ont été les éléments de sa
mission.
Des considérations générales ou non
explicitement justifiées sont irrecevables ; en particulier des termes aussi
vagues que « diagnostic », ou, pire « évaluation »,
L’audit informatique qui suggère une
quantification, sont inacceptables sauf éventuellement dans un contexte précis
;et ce, dans le délai imparti et accepté. Le domaine de la tâche d’un auditeur
est donc très rigoureusement défini en termes d’objets, d’aspects, et de cadre
temporel, et sa démarche est d’une démonstration rigoureuse et exhaustive. Les
sujets d’audit doivent être maintenant évidents. Il a paru naturel d’adopter
une structure par objets ; on aurait pu aussi faire un plan par aspects.
2.3. CONSIDERATIONS SUR L’ERREUR
Si l’erreur n’était pas humaine, il n’y
aurait pas besoin d’auditeur. Or non seulement elle l’est, mais en informatique
les machines sont impitoyables pour la révéler au grand jour. Exemple.–
L’auditeur ne recherche sauf exception que l’erreur, ou plutôt les lacunes de
contrôle où celle-ci peut se glisser. Mais il lui arrive de constater la fraude
ou le sabotage, qui en fait ne sont pas concrètement pires en termes de valeur.
Elle provient de défaillances dans la
représentation de la réalité et la compréhension des observations par : – faute
de connaissance d’interprétation et de représentation ;– faute concernant les
hypothèses déduites (modèle mental inexact, incomplétude ou ambiguïté) et induites
(suppositions erronées) ; – choix des objectifs (contradictoires, hors délais,
superflus, faute de raisonnement) ;– choix
des solutions (saturation mentale, analogie injustifiée, confusion) ;–
réalisation (erreurs de communication, de procédure, de vérification).Et en
informatique, il ne faut compter sur aucune Indulgence, aucune tolérance, dès
lors que la solution est automatisée.
Le principe et ces règles n’auraient pas de
raison d’être exposés s’ils ne pouvaient être mis en œuvre.
Il s’agit donc dans la suite de l’ouvrage
d’examiner leur application, selon le plan précédent de classification des
objets, pris un à un. Pour chacun d’eux, les aspects seront présentés plus ou
moins dans l’ordre pratique défini plus haut, approximation de l’exposé qui
tient au fait qu’il serait sinon trop rigide et ne tiendrait pas assez compte
des priorités relatives à chaque objet particulier. Très souvent il sera écrit que
« tel objet doit présenter tel aspect » ; cela doit être entendu comme«
l’auditeur doit vérifier que tel objet a tel aspect».
Le système d’information doit constituer un
système cohérent, même s’il est
constitué de nombreux objets de natures, voire de localisations différentes.
Définir ses objectifs doit donc précéder les
choix de moyens et actions. C’est un problème complexe à poser clairement, donc
à résoudre parfaitement, mais il faut s’y attacher si l’on ne veut pas laisser
les décisions essentielles dépendre d’objets qui n’ont par nature aucune
finalité propre (sauf les ressources humaines).
La difficulté tient paradoxalement à
l’absence de contrainte générale autre que l’adéquation au monde extérieur, la
liberté étant totale dans le cadre de la politique de l’entreprise, dont le
système d’information n’est qu’un support de réalisation.
Les contraintes précises n’interviendront
qu’ultérieurement, par la disponibilité des moyens et la praticabilité des
actions. Et comme les uns et les autres sont fluctuants, puisque les techniques
et produits changent vite (parfois mais pas toujours par progrès intrinsèque),
la seule méthode rationnelle est d’établir une politique informatique et
de la détailler logiquement en buts par objectifs indépendants des ressources,
puis de classer ceux-ci dans un plan de réalisation étalé dans le temps,
puisque les moyens et actions ne sont presque jamais immédiatement disponibles.
Suivant les contraintes, tel but sera ou non finalement retenu, et s’il l’est,
atteint de telle ou telle façon.
Le Détail n’a pas à être défini au moment de
l’élaboration de la politique informatique ; cependant, si une ressource se
révèle inaccessible, il faut revenir aux Objectifs et audit informatiques La
difficulté tient paradoxalement à l’absence de contrainte générale autre que
l’adéquation au monde extérieur, la liberté étant totale dans le cadre de la politique
de l’entreprise, dont le système d’information n’est qu’un support de
réalisation. Les contraintes précises n’interviendront qu’ultérieurement, par
la disponibilité des moyens et la praticabilité des actions. Et comme les uns
et les autres sont fluctuants, puisque les techniques et produits changent vite
(parfois mais pas toujours par progrès intrinsèque), la seule méthode
rationnelle est d’établir une politique informatique et de la détailler logiquement
en buts par objectifs indépendants des ressources, puis de classer
ceux-ci dans un plan de réalisation étalé dans le temps, puisque les
moyens et actions ne sont presque jamais immédiatement disponibles. Suivant les
contraintes, tel but sera ou non finalement retenu, et s’il l’est, atteint de
telle ou telle façon. Le détail n’a pas à être défini au moment de
l’élaboration de la politique informatique ; cependant, si une ressource se
révèle inaccessible, il faut revenir au
Il a déjà été dit que l’information est un
bien précieux, et portée par un véritable système nerveux ; un animal privé
d’encéphale ne peut survivre qu’un moment sans assistance externe ; et les
outils ne seront jamais en soi l’équivalent d’un encéphale. L’échec historique
du management automatisé était prévisible dès le départ.
2.4. Politique informatique et schéma directeur
Définir la politique informatique n’est
guère technique, le rôle des techniciens n’étant que de réaliser tel ou tel but ou de révéler au
gestionnaire qu’il est irréalisable. Aussi est-il essentiel qu’elle soit
définie par la direction, peut-être avec l’aide d’un service ou d’un conseil
spécialisé en organisation, mais qui n’a pas de pouvoir de décision. Elle doit
être adaptée à la finalité de l’entreprise, donc évolutive et homogène avec les
objectifs de celle-ci, et documentée, donc concrétisée par un écrit. Il n’est
pas essentiel de déterminer d’abord si
elle est faisable, c’est l’analyse ultérieure qui devra répondre à cette
question.
CHAPITRE 3 :
SCHEMA CONCEPTUEL DE L’AUDIT INFORMATIQUE
3.1. PHASES DE L’AUDIT DES SYSTEMES
D’INFORMATIONS
Un audit informatique, audit
des systèmes d'information, se fait selon un schéma en 4 phases :
- Définition précise du plan de travail, récolte d'information,
recherche et schématisation des processus métiers et/ou informatiques à
apprécier, définition des rôles et responsabilités, analyse forces - faiblesses
- .Analyse des processus importants, définition des risques,
évaluation préliminaire des risques, de l'efficacité des contrôles
- Tests des contrôles
- Tests de matérialité.
Un audit informatique, audit
des systèmes d'information ne concerne pas nécessairement la sécurité. En
effet, il peut aussi évaluer des aspects stratégiques ou de qualité des
systèmes d'information. Par exemple, répondre à la question suivante : Est-ce
que les systèmes d'information de l'entreprise répondent efficacement aux
besoins des services métiers ? La démarche est très similaire, en choisissant
et évaluant les processus informatiques proposés par le CobiT qui répondent le
mieux à la demande du client.
3.2. CATEGORISATION D’AUDIT INFORMATQUE
3.2.1. AUDIT DE L'ENVIRONNEMENT INFORMATIQUE
Mission
Evaluer les risques des systèmes d'information nécessaires au
fonctionnement des applications. Par exemple : Sécurité physique, sécurité
logique, sécurité des réseaux, plan de secours.
Livrables
Rapport contenant les faiblesses relevées, leur niveau de risque
et les mesures correctives proposées.
3.2.2. AUDIT D’UNE APPLICATION INFORMATIQUE
MISSION
Evaluer les risques d'une application informatique. La mission
débute par la définition des processus métiers concernés, puis évalue leurs
risques.
LIVRABLES
Rapport contenant les faiblesses relevées, leur niveau de risque
et les mesures correctives proposées.
Assister l'équipe de projet à évaluer les risques lors des
différentes étapes de réalisation d'une application informatique et proposer
des mesures de réduction et de contrôle des risques importants.
Livrables
Mesures proposées de réduction et de contrôle des risques
importants de la nouvelle application informatique.
- Evaluer les
risques des systèmes d'information -
- Installer des contrôles contre les risques identifiés
- Installer des contrôles contre les risques identifiés
Pour assurer la sécurité informatique, sécurité des systèmes
d'information, l'entreprise doit identifier et évaluer les risques
informatiques, risques des systèmes d'information, et installer des mesures de
sécurité organisationnelles, physiques et logiques contre ces risques.
CHAPITRE 4 : POLITIQUE DE SECURITE INFORMATIQUE
Elle procède par
-
la Sécurité
de l'information ;
-
l’Installation
et la gestion de la politique de sécurité des systèmes d'information
Pour ce faire, la nécessité de l'information et le besoin de la
protéger est requise.
4.1. SECURITE DE L’INFORMATION
L'information constitue un des biens ou actifs vitaux du
patrimoine de chaque entreprise. Cette information, par le biais des processus
business, permet à l'entreprise de réaliser ses tâches, de répondre aux
demandes des clients, de comptabiliser ses opérations, etc., bref de
fonctionner selon les exigences de ses dirigeants et des autres parties
prenantes. En outre, l'entreprise doit se conformer aux lois et aux
règlements applicables qui concernent également l'information, par exemple la
loi sur la protection des données, les droits d'auteur et le reporting
financier.
Aussi,
l'entreprise doit-elle protéger son information, de même que les systèmes
d'information nécessaires au traitement de cette information, respectivement de
ses processus business, dans et autour des activités de base suivantes :
Saisie de l'information (input), traitement et enregistrement de l'information,
sortie de l'information (output).
4.2. MESURES DE SECURITE, EVALUATION DES RISQUES ET TABLEAU DE BORD
4.2. MESURES DE SECURITE, EVALUATION DES RISQUES ET TABLEAU DE BORD
Pour protéger efficacement son information (donc également ses
systèmes d'information), l'entreprise doit - en fonction d'une évaluation des
risques - mettre en place des mesures de sécurité (des contrôles) de manière à
assurer l'intégrité, la confidentialité et la disponibilité de
l'information. A ce sujet, la norme ISO , largement reconnue, propose plus de 130
contrôles de sécurité de l'information.
Nous avons développé un tableau
qui permet à une entreprise
d'évaluer ses contrôles et de produire un tableau de bord comme outil efficace
de la politique de sécurité informatique, sécurité des systèmes d'information, sécurité de l’information
La mise en place de mesures de sécurité de l'information n'est pas
une fin en soi, mais un processus servant à établir, installer, appliquer,
revoir, maintenir et améliorer un SGSI (système
de gestion de la sécurité de l'information), ou ISMS (information
security management system) de
l'entreprise, selon la norme ISO.
Le processus décrit ci-dessus vise l'amélioration continue et
dépend directement des volontés de la direction générale, car il s'inscrit dans
le processus général de sécurité de toute l'entreprise et dans le SCI.
Selon la
Chambre Fiduciaire , le SCI est "un outil de gestion
permettant de garantir de manière appropriée à l’entreprise d’atteindre ses
objectifs dans les domaines «Procédures», «Informations», «Protection du
patrimoine» et «Conformité (Compliance)». Le SCI englobe toutes les méthodes et
mesures organisationnelles appliquées, conformément à un plan, par la
direction". Le COSO propose un concept reconnu pour la
mise en place d'un SCI :
La présente Norme internationale établit des lignes directrices et
des principes généraux pour préparer, mettre en oeuvre, entretenir et améliorer
la gestion de la sécurité de l’information, sécurité informatique, au sein d’un
organisme. Les objectifs esquissés dans la présente Norme internationale
fournissent une orientation générale sur les buts acceptés communément dans la
gestion de la sécurité de l’information.
Les objectifs et mesures décrits dans la présente Norme
internationale sont destinés à être mis en œuvre pour répondre aux exigences
identifiées par une évaluation du risque. La présente Norme internationale est
prévue comme base commune et ligne directrice pratique pour élaborer les
référentiels de sécurité de l’organisation, mettre en oeuvre les pratiques
efficaces de la gestion de la sécurité, et participer au développement de la
confiance dans les activités entre organismes.
La présente Norme
internationale contient 11 articles relatifs aux mesures de sécurité, qui
comprennent un total de 39 catégories de sécurité et un article d’introduction
sur l’appréciation et le traitement du risque. Chaque article contient
plusieurs catégories de sécurité principales. Les 11 articles (accompagnés du
nombre de catégories de sécurité principales incluses dans chaque article) sont
les suivants.
1° Politique de sécurité
2° Organisation de la sécurité de l’information
3° Gestion des biens
4° Sécurité liée aux ressources humaines
5° Sécurité physique et environnementale.
6°Gestion opérationnelle et gestion de la communication.
7° Contrôle d’accès.
8° Acquisition, développement et maintenance des systèmes
d’information
9° Gestion des incidents liés à la sécurité de l’information.
10° Gestion de la continuité de l’activité.
11° Conformité.
Dans le but de permettre à
une entreprise d'évaluer sa politique de sécurité des systèmes d'information,
sécurité de l'information, nous avons repris dans un tableau Excel 11
articles et n catégories de la norme ISO.
L'entreprise peut alors :
-
choisir
quels articles et quelles catégories elle veut évaluer, puis
-
évaluer
chaque contrôle des catégories choisies en lui donnant une note entre 1
(contrôle inexistant) et 5 (contrôle installé et testé).
Un tableau final établit
la moyenne des notes par catégorie et par article. L'entreprise peut s'en
servir comme tableau de bord de la politique de sécurité informatique, sécurité
des systèmes d'information, sécurité de l'information.
L'ensemble fournit un très
bon point de départ pour la mise en oeuvre d'un système de gestion de la
sécurité de l'information (SGSI ou ISMS), selon la norme ISO 27001:2005.
CHAPITRE 5 : PLANIFICATION ET
ORGANISATION DANS L’AUDIT INFORMATIQUE
5.1. LE PLAN STRATEGIQUE INFORMATIQUE
Le Plan stratégique informatique requiert ce
qui suit :
- Ne pas poser les bonnes questions au
début du projet
- Croire que l’EC est un nouveau mode de
travail qui permettra de gagner rapidement de l’argent
- Mal cibler les besoins EC des clients
actuels et potentiels
- Oublier que les nouvelles solutions vont
nécessiter des coûts de formation et de maintenance et créer des
impératifs d’adaptation liés aux changements
- Ne pas répondre aux questions clefs de
l'EC dont : Suis-je en mesure de le gérer et de le payer ? Est-ce que l’EC
correspond à mon business ? Est-ce que je pourrai créer des liens
efficaces avec les processus business existants ?
- La stratégie EC n’est pas en accord avec
la stratégie commerciale de l'entreprise
- Développer quelque chose qui est à la
mode, complexe, peut coûter cher et ne fait pas partie de l’expertise de
l'entreprise
- Commencer dès le début par de l’EC, bien
qu’il soit préférable à notre avis de débuter sur Internet par 1) La
présentation de l’entreprise, puis 2) Fournir des informations ciblées aux
clients, et enfin 3) Faire de l’EC, c’est à dire vendre, se faire payer,
livrer, répondre aux réclamations, etc.
- Ne pas considérer que les informations
de l’entreprise sur Internet ont d’autres niveaux de criticité qu’à
l’intérieur de l’entreprise
- Installer des systèmes de types
différents rendant leur gestion et leur maintenance difficile, tout en
augmentant l’instabilité de l’ensemble
- Ne pas séparer efficacement
l'architecture de base de l'architecture Internet
- Considérer les réalisateurs de solutions
EC comme des supermen et ne pas les intégrer efficacement dans
l’organisation de
- Ne pas avoir une vision claire des
objectifs et des ressources humaines et financières nécessaires pour
développer et maintenir l’ensemble
- Ne pas avoir une politique dynamique (et
non statique) de sécurité des informations, incluant l'EC, basée sur
l'évaluation des risques, soutenue ouvertement et financièrement par
- Ne pas afficher clairement sur son site
Internet la politique de protection des informations des clients et des
internautes
- Ne pas avoir une politique de protection
des données des clients respectant les exigences légales des pays avec
lesquels ont fait de l’EC
- Ne pas considérer les risques
d’implications légales de l’EC
- Ne pas suffisamment prendre en
considération les risques de sécurité, de réputation, financiers et
opérationnels des solutions EC pour l’entreprise et pour les clients
- Croire que les dangers viennent surtout
de l’extérieur
- Croire qu’une attaque, c’est quelque
chose de bien visible et immédiatement visible
- Impliquer insuffisamment les
responsables métiers et le service juridique dans le projet EC
- Laisser aux consultants le soin de gérer
le projet EC
- Identifier les solutions automatiques
- Penser à la solution, avant de penser
aux réels besoins de l’entreprise et des clients
- Mal définir les 3 processus critiques EC
: Paiement, livraison et service après-vente
- Croire à des solutions miracles
proposées sur le marché
- Laisser le soin au fournisseur de
répondre à ses propres questions
- Compliquer le tout avec des solutions de
CRM, datamining, etc. avant de s’occuper à stabiliser la base
- Ne pas s’assurer que la nouvelle
solution est réalisable et fournira des mesures automatiques de sécurité
gérant efficacement les risques relevés (risques EC, risques particuliers
à l’entreprise, etc.)
- Pas de schématisation claire des
processus EC end-to-end et du flux transactionnel
- Mal définir les liaisons avec les
processus business existants
- Pensez qu’une fois l’application EC
installée, on peut dormir tranquille
- Ne pas suffisamment tester l’ensemble le
plus près de la réalité
- Tester avec la vision de vouloir
contrôler si ça marche et non de vouloir rechercher ce qui ne marche pas
- Ne pas prévoir que tout changement a un
effet déstabilisant pouvant diminuer fortement et subitement la qualité et
la sécurité du système
Livraison et Support
Définir les
niveaux de service
- Mal définir les niveaux requis de
qualité des différents services (Service Level Agreement) d’EC
- N’être pas en mesure de garantir le
niveau de disponibilité et de sécurité requis, car on n’y pense pas, on ne
sait pas ce que c’est, on ne sait pas comment le définir, on ne sait pas
comment le mettre en place ou on ne sait pas comment le mesurer
- Ne pas pensez qu’un client peut se
brancher sur votre site EC quand vous dormez (décalage horaire), ce qui
implique que ce point doit être analysé lors de la définition des
exigences de disponibilité
Services fournis par les tiers
- Etre mains et pieds liés aux
fournisseurs ou à l’ISP
- Ne pas demander aux prestataires ce
qu’ils garantissent et ce qui se passe s’ils n’arrivent pas à fournir ce
qu’ils ont garanti
- SLA manquent ou pas définis correctement
ou définis par le prestataire pour couvrir surtout ses propres besoins
- Ne pas anticiper des augmentations de
charge ou des surcharges passagères
- Ne pas se poser la question : Après
quelle durée de panne j’aurai de très grosses pertes et après quelle durée
de panne je ne serai plus sur le marché ou ma réputation sera au plus bas
?
- Insuffisamment protéger les informations
des clients
- Penser que les firewalls, les tests
d’intrusion et les antivirus fournissent une garantie suffisante contre
les risques EC
- Ne pas être en mesure de savoir ce qui
se passe ou ce qui s’est passé dans le système, en particulier au niveau
des accès aux ressources sensibles/critiques
- Ne pas être en mesure de répondre à la
question : Combien de fois par jour mon système se fait-il attaquer depuis
l’extérieur et depuis l’intérieur de l’entreprise ?
- N'être pas prêt à réagir correctement à
une alerte importante, réceptionnée à 3h00 du matin
- Ne pas former et sensibiliser les
collaborateurs et les clients aux risques EC et ne pas le leur rappeler
constamment (anciens et nouveaux risques)
- Ne pas pensez
qu’un client EC peut demander de l’assistance ou de l’aide comme un
collaborateur et qu’au téléphone ou via Email on ne peut pas lui dire
n’importe quoi et n’importe comment
5.2. LA PRE EVALUATION OU SELF ASSESSMENT
Désirez-vous
procéder en interne à une pré évaluation de l'efficacité ou de la sécurité de
vos systèmes d'information (SI) ? Désirez-vous sensibiliser votre management
aux aspects d'efficacité ou de sécurité de vos SI ? Désirez-vous démarrer un
concept d'amélioration de l'efficacité ou de la sécurité de vos SI, mais ne
savez-vous pas par quoi commencer ? Alors l'approche de a [a] indic près
d’avoir que nous vous proposons ci-dessous peut très bien répondre à vos demandes.
Objectifs
Réuni autour d'une table, le management effectue une pré
évaluation (self-assessment) des forces et des faiblesses des principaux
processus informatiques de son entreprise. Lors de cette mission, qui dure
environ une journée, nous intervenons uniquement en tant que modérateur,
expliquant l'approche et les divers processus informatiques à évaluer. En
général, nous nous appuyons sur les processus proposés par le CobiT. Mais l'entreprise peut très
bien préférer les domaines et sous domaines d'autres normes, par exemple la
norme ISO/IEC 17799 : 2005.
Résultats
A la fin de la journée, le management dispose d'un document
accepté formellement par toutes les personnes de l'entreprise ayant participé à
la réunion, identifiant les processus informatiques considérés comme peu
importants et ceux devant faire l'objet d'une analyse approfondie.
Cette approche présente le
double avantage d'aboutir à un consensus sur les processus importants pour
l'entreprise et sur leurs niveaux d'efficacité, tels qu'ils sont perçus par
toutes les personnes présentes à cette réunion. Ainsi, les analyses
subséquentes seront plus efficientes, car elles ne se concentreront que sur les
processus essentiels pour l'entreprise.
ASSISTANCE ET
CONSEIL
.
.
Radioscopie des processus informatiques
Désirez-vous une
"photo" à un moment donné de votre système d'information ?
Désirez-vous comparer (benchmarking) vos processus informatiques avec d'autres
(benchmarking) ? Désirez-vous mieux connaître ou apprendre à utiliser le modèle
CobiT ? Alors l'approche que nous
décrivons ci-dessous peut répondre à vos exigences :
Objectifs
Apprécier l'efficacité ou la sécurité des processus informatiques
de l'entreprise et, si demandé par le client, comparer les résultats obtenus
avec ceux d’autres entreprises similaires choisies par le client
Résultats
Rapport contenant les constatations relevées, leur degré de
risque, les résultats des comparaisons avec les autres entreprises et les
mesures d'amélioration proposées
Une mission de radioscopie permet d'obtenir un avis neutre sur les performances des processus informatiques de l'entreprise, en l'occurrence ceux proposés par le modèle CobiT. D'autre part, la comparaison (benchmarking) de certains processus avec ceux d'autres entreprises, fournit des informations très appréciables. C'est toujours le client qui choisit les processus informatiques à apprécier et les entreprises à contacter pour effectuer les comparaisons (benchmark)
5.3. FORMATION
DES UTILISATEURS A LA SECURITE INFORMATIQUE
La formation constitue un
des principaux moyens de sécurité des systèmes d'information, de sécurité
informatique, de sécurité des informations. En effet, la majorité des failles
et incidents de sécurité informatique est due à des erreurs humaines. D'autre
part, la formation seule ne suffit pas. Il faut également s'assurer que les
utilisateurs sont sensibilisés aux risques informatiques et adhérents aux
exigences de sécurité des systèmes d'information. La réussite de ces
objectifs dépend de plusieurs facteurs de succès, dont La Direction générale
doit inclure formellement dans sa politique
de sécurité informatique la formation et la sensibilisation des
utilisateurs aux risques et à la sécurité informatique et aux exigences de
sécurité des systèmes d'information de l'entreprise (directives et procédures
de sécurité des systèmes d'information)
Former également aux exigences de sécurité, les tiers accédant aux
systèmes d'information de l’entreprise, Concevoir une formation générale à la
sécurité informatique et une formation spécifique à chaque fonction.
Concevoir la formation à la sécurité informatique comme un
processus dynamique, ce qui implique de planifier des séances de rappel et
d'adapter la formation en fonction des incidents et des nouveaux risques
Rendre attentifs les utilisateurs sur les conséquences en cas de
non respect des exigences de sécurité des systèmes d'information.
5.4. FORMATION A LA SECURITE ET A L'AUDIT INFORMATIQUE
Nos expériences pratiques (clients et universités) nous
permettent de proposer différentes formations du personnel de l'entreprise à la
sécurité et à l'audit informatique, sécurité et audit des systèmes
d'information :
Formation générale
Formation
et sensibilisation des collaborateurs de l'entreprise à la sécurité
informatique; durée 2 jours par groupe de 10-12 personnes; matin théorie,
après-midi travaux pratiques
RSSI
Formation
du RSSI (responsable de la sécurité des systèmes d'information) de l'entreprise
à ses tâches, dont cahier des charges, organisation et plan de travail, etc.
Lors
de missions
Dans
le cadre d'une mission, par exemple mise en place de la politique de
sécurité des systèmes d'information ou audit
informatique, formation des collaborateurs participant à la
mission, à l'approche et à la méthode utilisées pour réaliser les travaux
confiés.
Formation proposée par des organismes réputés
L'International
Information Systems Security Certification Consortium ou ISC(2) a
développé un examen basé sur l'Information systems security Common Body of
Knowledge (CBK). Cet examen qui dure 6 heures comprend les domaines
suivants : Contrôle des accès, Sécurité de l'exploitation, Chiffrement,
Développement des systèmes et des applications, Plan de secours, Sécurité des
télécommunications et des réseaux, Sécurité de l'architecture, Sécurité
physique, Gestion de la sécurité et Respect des exigences légales.
L'Information
System Audit and Control Association (ISACA) propose chaque année le programme
de certification professionnel Certified Information Systems Auditor (CISA).
L'examen dure 4 heures et comprend les domaines suivants : Gestion,
planification et organisation des systèmes d'information, Infrastructure
technique et opérationnelle, Protection du patrimoine des informations, Plan de
secours, Développement, acquisition, mise en place et tenue à jour des
applications informatiques et Evaluation des processus business et gestion des
risques.
L'Université
de Genève (HEC) propose différentes formations dans le domaine de la sécurité
et de l'audit informatique.
L'Université
de Lausanne, HEC, propose une formation à l'audit informatique dans le
cadre du diplôme MBI/DPIO
CHAPITRE 6 : AUDIT INFORMATIQUE
DANS UNE PEM
La démarche d´audit est la
même, qu´il s´agisse d´un grand compte ou d´une PME. Elle correspond toujours
au besoin de faire faire un diagnostic par un expert indépendant pour établir
un état des lieux, définir des axes d´amélioration et obtenir des
recommandations pour palier les faiblesses constatées. Les PME font le plus
souvent appel à un auditeur pour y voir clair dans une réalité confuse ou
rapportée comme telle, dans un contexte de crise, lorsqu´il y a un problème
dans le système d´information : l´auditeur est un peu le "bobologue"
du système d´information. Et il intervient principalement dans les PME pour
réaliser des audits post-implémentation (par exemple, on a choisi un ERP sans
étude, sans conseil... et cela ne fonctionne pas) et plus rarement pour des
audits de sécurité. Très peu d´audits sont réalisés à titre préventif, ce qui
est bien dommage, car la mise en oeuvre des solutions de rétablissement coûte
plus cher. En général, la techno- structure qui entoure le dirigeant de PME
n´est pas suffisante pour un éclairage pertinent. Il est soumis aux aléas des
marées : presse, copains, collègues... lui fournissent autant d´informations
contradictoires et hors contexte. L´auditeur intervient en tant que mesureur de
risques et propose une hiérarchisation : identification des faiblesses, impact,
solution, risques si les mesures ne sont pas prises.
6.1. COMMENT CHOISIR SON PRESTATAIRE
Tout d´abord il convient de
bien distinguer l´audit du conseil. Et de surtout ne pas faire appel à une même
personne pour effectuer ces deux types de prestations. En effet, l´auditeur
pourrait dans ce cas être amené à se prononcer sur ses propres prestations de
conseil (antérieures) ou à intégrer dans ses recommandations des prestations
qu´il est à même de réaliser, ce qui aboutit évidemment à une situation
malsaine. Deuxième point : ne pas confondre audit et prestation d´avant-vente.
Les intégrateurs proposent bien souvent un "audit" préalable à
l´issue duquel ils feront des recommandations. Celles-ci iront bien souvent -et
c´est compréhensible- dans le sens de leurs propres savoir-faire. Trois critères
majeurs sont donc à retenir:
-l´indépendance, l´intégrité intellectuelle de l´auditeur ;
-son expertise : faites appel à un professionnel du diagnostic ;
- sa capacité à vous remettre des recommandations.
-l´indépendance, l´intégrité intellectuelle de l´auditeur ;
-son expertise : faites appel à un professionnel du diagnostic ;
- sa capacité à vous remettre des recommandations.
6.2. LES PRINCIPALES ETAPES D'UN AUDIT INFORMATIQUE
La première étape consiste à
prendre connaissance de manière extrêmement fine des attentes du client. Il
convient de bien comprendre ses besoins et de les reformuler. Avant de faire
appel à un auditeur, établissez donc avec précision ce que vous attendez de
l´audit. Cette première étape est particulièrement importante dans la mesure où
elle plante le contexte précis dans lequel l´audit va être mené : autant
d´informations qui seront incluses dans le rapport d´audit afin d´en faciliter
l´interprétation, même plusieurs années après sa réalisation.
Ensuite, une lettre de mission sera rédigée. En plus de définir la procédure à venir, elle a deux objectifs
principaux :
- elle est le contrat qui lie l´entreprise et l´auditeur ;
- elle permettra d´informer les différentes personnes impliquées de l´arrivée d´un audit dans l´entreprise. Elle est dans le même temps -auprès des salariés- une légitimation de cet audit par la direction.
- elle est le contrat qui lie l´entreprise et l´auditeur ;
- elle permettra d´informer les différentes personnes impliquées de l´arrivée d´un audit dans l´entreprise. Elle est dans le même temps -auprès des salariés- une légitimation de cet audit par la direction.
Troisième phase : le recueil de
toutes les informations nécessaires pour préparer la mission. Il s´agit de
récolter les éléments relatifs à la culture de l´entreprise, au contexte
général toujours en corrélation avec le système d´information.
Ensuite, des rendez-vous sont organisés avec les personnes concernées.
La cinquième étape consiste en la
solidification de toutes les informations, soit par le croisement des entretiens,
soit éventuellement par des contrôles sur le système avec des logiciels
spécifiques. Par exemple, lors d´un audit d´applications, un audit par les
données est efficace pour contrôler que les données sont bien entrées dans les
applications, qu´elles sont bien traitées par celles-ci et enfin que les
rapports sont générés convenablement.
Enfin, une réunion de synthèse est organisée entre l´auditeur et les personnes intéressées. Il s´agit de
s´assurer ensemble :
- que les questions de l´auditeur ont été bien comprises ;
- que les réponses ont été bien interprétées.
- que les questions de l´auditeur ont été bien comprises ;
- que les réponses ont été bien interprétées.
Le rapport est ensuite rédigé, de plusieurs manières (concis et
plus complet), car il s´adresse en général à plusieurs types de publics. Le
rapport détaillé expliquera les attentes de départ, le contexte, les limites,
les faiblesses constatées, leur importance relative et les solutions. Un
rapport d´audit doit être clair et didactique. En aucun cas il ne doit être
technique : c´est là la différence entre un audit et une mission d´expertise.
6.3. QUE REPRESENTE UN AUDIT
A).EN TERMES DE COUT POUR L'ENTREPRISE
Le coût d´un audit se
calcule en jours/homme. Et beaucoup de variables entrent en ligne de compte,
telles que le nombre de sites concernés ou encore la complexité des problèmes
rencontrés dans le système d´information. Un audit dure au minimum cinq jours,
et cela peut s´étaler sur une période beaucoup plus importante. Aussi, il m´est
difficile de quantifier précisément le coût d´un audit informatique, dans la
mesure où cela recouvre autant de réalités que d´entreprises. Dans tous les
cas, un devis précis doit toujours vous être présenté par votre prestataire
avant le début de la mission.
B) ET EN TERMES D'ECONOMIES
Les économies induites par
un audit informatique peuvent être de plusieurs types :
- une procédure d´audit peut
vous faire réaliser des économies immédiates en mettant le doigt sur des
dépenses inutiles ;
- la réduction des risques
est également source d´économies potentielles. En effet, en préconisant des
sauvegardes régulières par exemple (et donc en vous évitant la perte de
données), l´auditeur vous fait faire potentiellement de grandes économies Avec un prix moyen de la journée à environ
1000 euros, le Groupement national des professionnels de l´informatique (GPNI)
estime le coût global de la procédure entre 500 et 3000 euros.
Aucun commentaire:
Enregistrer un commentaire