AUDIT DES SYSTEMES
D’INFORMATION
Présenté par :
SASSA Giquel Thérance
Certifié: COBIT5 – Big Data – Scrum Master – Prince2
OBJECTIFS
Acquérir les fondements de l’audit des systèmes
d’information
Initier les apprenants aux principaux concepts
généraux liés à l’évaluation des SI.
PLAN
I. GENERALITES SUR LES SI
II. DEFINITION DE L’AUDIT DES SI
III. RISQUES LIÉS AUX SI
IV. MISSIONS DES AUDITS SI
V. MÉTHODOLOGIES D’AUDITS DES SI
VI. RÉFÉRENCES ET NORMES
VII. CATÉGORIES D’AUDITS DES SI
VIII.APPROCHE D’AUDIT DES PRINCIPAUX DOMAINES DES SI
IX. FACILITATEURS D’AUDITS DES SI
X. MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
I- GENERALITES SUR LES SI
Les systèmes d'information sont au cœur des industries de
transformation et de production. Il permet l’échange des données
entre les départements/fonctions de l'entreprise.
A travers les réseaux qui ont de plus en plus une architecture
distribuées, le SI est devenu une ressource essentielle dans le domaine
d’activités stratégiques de toutes entreprises.
Son bon fonctionnement contribue à la performance de
l’organisation
I- GENERALITES SUR LES SI
▪ Les SI sont aujourd'hui un support essentiel de l’organisation et le moteur
de son évolution dans un environnement de plus en plus complexe et
mouvant
▪ Le SI est de nos jours reconnu dans la théorie du management
stratégique comme une variable clé de la compétitivité de l'entreprise,
tant sur le court et moyen terme (processus de production) que sur le
long terme (processus d'innovation)
▪ Le système d’information a pour finalité d’offrir un meilleur service aux
utilisateurs et de contribuer à la performance de l’organisation
COMPANY NAME
ABS.COM
I-PutGENERALITES SUR LES SI
a relevant subtitle in this line
Un SI est l’ensemble de ressources (matériel, logiciel,
données, humaine, procédure, etc) structuré pour acquérir,
traiter, mémoriser, transmettre et rendre disponible
l’information (sous forme de données, sons, texte, image,
etc ) dans et entre les organisations
Robert Reix (1934-2006), Systèmes d’information et management des organisations
COMPANY NAME
ABS.COM
I-PutGENERALITES SUR LES SI
a relevant subtitle in this line
Interactions des sous-systèmes à travers des services
COMPANY NAME
ABS.COM
I-Put
GENERALITES
a relevant subtitleSUR
in thisLES
line SI
4- Les SI Standardisé : Caractéristiques
Structure : en couche/urbanisé
Couts : Centre d’investissement pour l’entreprise
Objectifs : Alignement aux orientations de la structure
Contribution : Aide à la productivité des métiers et à la décision
Technique : Tient compte des contraintes technologiques de développement , de
maintenance ou d’exploitation
Sécurité : Politique de securité existante
Réglémentation : Conformité reglementaire interne et externe
Communication : claire les métiers et les services de l’entreprise à travers les SLA
Stockage : Capacité de stockage illimité
Traçabilité : Visibilité
COMPANY NAME
ABS.COM
I-Put
GENERALITES
a relevant subtitleSUR
in thisLES
line SI
L’ensemble des progiciels utilisés dans une
entreprises constitue la partie dématérialisée du
SI
≠
du système informatique de l’entreprise
II- DEFINITION DE L’AUDIT DES SI
Le Petit Larousse définit l’audit comme « une procédure consistant
à s'assurer du caractère complet, sincère et régulier des comptes
d'une entreprise, à s'en porter garant auprès des divers partenaires
intéressés de la firme et, plus généralement, à porter un jugement
sur la qualité et la rigueur de sa gestion. »
L’audit des SI diffère fortement de l’audit financier ou opérationnel,
qui s’intéresse aux risques endémiques dans un secteur donné ou
d’une organisation
II- DEFINITION DE L’AUDIT DES SI
L’audit est une méthode d’évaluation rigoureuse qui possède sa propre
norme : le respect des normes et des standards en matière de maîtrise de
techniques d’audit est décrit dans la norme ISO 19011 appelée « Lignes
directrices pour l’audit des systèmes de management : conseils pour le
management d’un programme d’audit, les activités de l’audit et les
compétences des auditeurs ».
L'audit des systèmes d'information évalue les risques liés à l’environnement
du SI notamment la sécurité (physique, logique, réseau) , la gestion des
changements, les processus, le plan de secours, I’infrastructure, les
données, les projets, etc.
II- DEFINITION DE L’AUDIT DES SI
Un audit régulier des systèmes entre en effet à l’intérieur d’une
démarche qualité continue, pour rester compétitif et atteindre ses
objectifs stratégiques.
L'audit des systèmes d'information évalue les risques liés à
l’environnement du SI notamment la sécurité (physique, logique,
réseau) , la gestion des changements, les processus, le plan de
secours, I’infrastructure, les données, les projet, etc.
III- RISQUES LIES AUX SI
Illustration : Théorie du flocon de neige
Les entreprises A et X opèrent toutes deux dans le secteur des médias. Elles sont
toutes deux exposées à un risque lors du calcul des gains pour les prestations
offertes. L’audit interne s’intéresserait forcément à ce processus.
A utilise un système centralisé de gestion de ses prestations.
X est dotée d’un décentralisée, et chacune des entités utilise son propre système,
sur diverses plateformes. Chacune communique ses données à un système de
consolidation.
L’audit du SI pour la société A différera de celui de la société X en raison des
différences des environnements des SI. Il sera donc difficile d’adopter une
approche générique d’audit des SI
Chaque environnement de SI est unique, et représente donc un ensemble de
risques unique, selon la théorie du flocon de neige.
III-RISQUES LIES AUX SI
Illustration : Théorie du flocon de neige
Plusieurs variable permettent de renforcer la théorie du flocon de
neige à savoir :
▪ La configuration des processus
▪ Le degré de centralisation du système
▪ Le degré de centralisation géographique
▪ Le nombre de serveurs
▪ Le choix des technologies d’infrastructure
▪ Le degré de personnalisation
▪ La structure organisationnelle de la direction en charge des SI.
III- RISQUES LIES AUX SI
Illustration : Théorie du flocon de neige :
Les versions de la technologie utilisée
Le degré et la méthode d’externalisation
La politique de l’entreprise (on conserve tous les e-mails
indéfiniment ou on n’en conserve aucun)
L’environnement d’un SI est propre aux spécificités du SI
L'audit des SI a pour objectif d’identifier, d’évaluer et déterminer
les risques (opérationnels, financiers, de réputation…) associés
aux activités informatiques d'une organisation
III- RISQUES LIES AUX SI
Quelques facteurs liés aux problèmes des SI :
▪ Fiabilité/Disponibilité : le système n’est pas disponible pour utilisation.
▪ Intégrité/Sécurité : accès non autorisé au système
▪ Fiabilité, Conformité/ Intégrité: données incomplètes ou inexactes
▪ Fiabilité/Confidentialité : l’information n’est pas conservée secrète
▪ Fiabilité/Efficacité : le système ne procure pas une fonction voulue ou
attendue
▪ Efficience : le système entraîne une utilisation sous-optimale des
ressources
III - RISQUES LIES AUX SI
Caractéristiques des risques SI : Evolutivité et dynamisme
Puisque l’environnement d’un SI est propre aux spécificités du SI,
chaque organisation présente un profil de risque qui lui est propre.
Selon la loi de Moore de 1965, la densité des données sur un circuit
intégré double tous les 18 mois
Dans les faits, cela signifie que les progrès technologiques sont rapides
et par conséquent, les risques liés aux SI ne sont pas statiques.
Ils évoluent, très souvent d’une année à l’autre selon la pente de
croissance et de l’expansion de la technologie
III - RISQUES LIES AUX SI
Caractéristiques des risques SI : Evolutivité et dynamisme
Pour éviter ce risque, le responsable de l’audit doit :
▪ Reconnaître la nature dynamique du risque lié aux SI et mener
des évaluations indépendantes de ce risque chaque année
▪ Comprendre les plans à court terme de le direction en charge
du SI pour une année donnée et déterminer quelles peuvent en
être les conséquences sur l’évaluation du risque lié à celui-ci
▪ Actualiser l’évaluation du risque d’audit avant de commencer
le prochain audit
▪ surveiller le profil de risque de l’organisation et être prêt à
adapter les procédures d’audit à son évolution.
III - RISQUES LIES AUX SI
Caractéristiques des risques SI : Prolifération
Le responsable de l’audit doit évaluer non pas seulement
chaque risque distinct, mais aussi les interactions entre les
différents risques car l’environnement est vue de manière
architecturale et urbanisée.
Pour éviter la prolifération du risque, il faudrait évaluer les
conséquences des risques à un niveau sur les autres
niveaux et le risque d’une zone sur une autre zone
III - RISQUES LIES AUX SI
Caractéristiques des risques SI : Prolifération
Il s’agit de considérer le risque lié aux SI dans sa
globalité et non isolément par division/direction de
l’entreprise
Supposons les risques A et B identifiés dans des
départements différents. Il se peut que, chaque
risque pris séparément, soit en soi faible, mais
ensemble créent un risque C qui est nettement plus
important que la somme des deux risques initiaux.
III- RISQUES LIES AUX SI
Les catégories de risques SI : Risque pervasif
C’est un risques qui a une incidence sur l’ensemble de
l’entreprise. Il n’est pas circonscrit à un système ou à un
processus spécifique.
Généralement, lorsqu’on est dans une situation de risque
pervasif, il est très difficile de relier son impact métier.
Illustration : une organisation A est reliée à Internet et n’a pas
mis en place de pare-feu. Sur quel département cela a-t-il
une incidence ?
III - RISQUES LIES AUX SI
Les catégories de risques SI : Risque pervasif
C’est un risques qui a une incidence sur l’ensemble de
l’entreprise. Il n’est pas circonscrit à un système ou à un
processus spécifique.
Illustration : une organisation A est reliée à Internet et n’a
pas mis en place de pare-feu. Sur quel compte cela a-t-il
une incidence ?
Potentiellement sur tous et potentiellement sur aucun
III - RISQUES LIES AUX SI
Les catégories de risques SI : Risque « spécifique »
C’est un risque directement lié à un processus spécifique
Le mauvais paramétrage des accès d’un compte n’a de
l’influence que sur le compte en question
Si un audit de SI ne ressort pas les risques spécifiques et
pervasifs, il est probable que cet audit ne couvre pas
correctement les risques auxquels l’organisation est
confrontée
III - RISQUES LIES AUX SI
Les catégories de risques SI : Risque statique
C’est un risque qui n’évolue guère d’une année sur l’autre et
provient généralement du secteur dans lequel l’entreprise
opère.
Illustration: la société X souscrit à un PAAS pour des formation
à distance. Le risque associé est que, si les serveurs ne
fonctionnent plus, la formation cessera jusqu’à ce que les
serveurs soient remis en marche.
C’est un risque globalement valable d’une année sur l’autre
III - RISQUES LIES AUX SI
Les catégories de risques SI : Risque dynamique
C’est un risque qui évolue sans cesse. Il est moins tributaire du
secteur de l’organisation et davantage lié à l’évolution
technologique (cf. la loi de Moore)
Illustration : La découverte d’une faille dans Windows server
2003. Les audits n’ont pas pu détecter la faille jusqu’à ce que le
système présente des faits d’incohérences et que Microsoft
définisse un patch pour y remédier.
Dans ce cas, l’audit devra se concentrer sur le processus mis en
place pour piloter les patchs et mesurer la rapidité avec laquelle
ils sont introduits.
III - RISQUES LIES AUX SI
Les catégories de risques SI : Risque dynamique
C’est un risque qui évolue sans cesse. Il est moins tributaire du
secteur de l’organisation et davantage lié à l’évolution
technologique (cf. la loi de Moore)
Illustration : La découverte d’une faille dans Windows server
2003. Les audits n’ont pas pu détecter la faille jusqu’à ce que le
système présente des faits d’incohérences et que Microsoft
définisse un patch pour y remédier.
Dans ce cas, l’audit devra se concentrer sur le processus mis en
place pour piloter les patchs et mesurer la rapidité avec laquelle
ils sont introduits.
IV- MISSIONS DES AUDITS DES SI
Assister l'équipe de projet à évaluer les risques lors des
différentes étapes de réalisation d'un système
proposer des mesures de réduction et de contrôle des
risques importants dans la réalisation d’un nouveau système
vérifier la qualité des processus de gestion des changements
et de test du nouveau système
Evaluer la qualité des projets SI et non SI de l’organisation
IV- MISSIONS DES AUDITS DES SI
Assister l'équipe de projet à évaluer les risques lors des
différentes étapes de réalisation d'un système
proposer des mesures de réduction et de contrôle des
risques importants dans la réalisation d’un nouveau
système
vérifier la qualité des processus de gestion des
changements et de test du nouveau système
Evaluer la qualité des projets SI et non SI de l’organisation
IV- MISSIONS DES AUDITS DES SI
Assister l'équipe de projet à évaluer les risques lors des différentes
étapes de réalisation d'un système
proposer des mesures de réduction et de contrôle des risques
importants dans la réalisation d’un nouveau système
vérifier la qualité des processus de gestion des changements et de
test du nouveau système
Evaluer la qualité des projets SI et non SI de l’organisation
L'audit des SI a pour objectif d’identifier, d’évaluer et déterminer les
risques (opérationnels, financiers, de réputation…) associés aux
activités informatiques d'une organisation
V - METHODOLOGIES DES AUDITS DES SI
Il est important d'effectuer un pré-diagnostic afin de
préciser les questions/domaines dont l'audit va traiter.
Cela se traduit par l'établissement d'une lettre de mission
qui détaille les principaux points à auditer.
En général, un auditeur des SI utilise plusieurs approches,
selon le domaine audité du SI.
Cependant il existe une méthodologie d’ensemble qui
présente le déroulement pour mener à bien les audits des
SI.
V- METHODOLOGIES DES AUDITS DES SI
▪ Cadrage et planification de la mission
▪ Comprendre l’environnement
▪ Identifier les contrôles clés
▪ Évaluer la conception des contrôles clés
▪ Vérifier l’efficacité
▪ Rendre les conclusions et recommandations
V- METHODOLOGIES DES AUDITS DES SI
1- Cadrage et planification de la mission
Cette phase porte sur l’approche générale des travaux,
le niveau de supervision, les ressources nécessaires pour
la mission, les besoins d’intervenants externes
Cette phase a pour objectif de :
Délimiter le périmètre d’intervention de l’équipe
d’audit. Cela peut être matérialisé par une lettre de
mission , une note interne, une réunion préparatoire à
la mission d’audit ;
V- METHODOLOGIES DES AUDITS DES SI
1- Cadrage et planification de la mission
Définir une approche d’audit et d’organisation des travaux
entre les deux équipes ;
Définir le planning d’intervention ;
Définir les modes de fonctionnement et de communication.
l’auditeur prend connaissance du dossier de l’équipe de
l’audit (stratégie d’audit, rapports d’audit interne, points
d’audit soulevés au cours des précédents audits).
V- METHODOLOGIES DES AUDITS DES SI
2- Comprendre l’environnement
Cette étape vise à recueillir les éléments relatifs au
secteur d’activité, aux caractéristique de l’organisation,
aux éléments de contrôle interne et pertinents pour
l’audit. l’objectif de cette phase est :
▪ de comprendre les risques et les contrôles liés au SI
▪ de comprendre comment le SI contribue à la
productivité de l’organisation
V- METHODOLOGIES DES AUDITS DES SI
Cette phase se fait sur la base de trois aspects notamment :
a- L’organisation de la fonction SI :
➢L’alignement de la stratégie SI à celle de l’entreprise
➢Le mode de gestion et d’organisation de la fonction SI :
Apprécier si la fonction informatique est sous contrôle du
management de l’entreprise
b- Les caractéristiques des systèmes informatiques : L’auditeur
devra se focaliser sur les systèmes clés de façon à identifier les
risques et les contrôles y afférents.
V- METHODOLOGIES DES AUDITS DES SI
Ainsi, il faut documenter l’architecture du matériel et du réseau en
précisant :
▪ Les caractéristiques des systèmes hardware utilisés (leur
architecture, leur procédure de maintenance, les procédures
de leur monitoring) ;
▪ Les caractéristiques des systèmes software (systèmes
d’exploitation, systèmes de communication, systèmes de gestion
des réseaux, de la base des données et de la sécurité, utilitaires).
c-La cartographie des applicatifs : il s’agit d’inventorier les
applications informatiques utilisées dans les processus métier ainsi
que leurs caractéristiques (langage de développement, année de
développement, bases de données et serveurs utilisés, etc
V - METHODOLOGIES DES AUDITS DES SI
3- Identification et évaluation des risques
Cette étape permet d’apprécier l’efficacité du contrôle interne courant
et de détecter les anomalies
4-Identifier les contrôles clés : Il s’agit d’identifier les risques liés au SI et
d’apprécier leur impact. Une fois ces risques recensés, l’auditeur devra
évaluer les contrôles mis en place par l’entreprise pour leur gestion.
5- Evaluer la conception des contrôles clés : Il s’agit d'arriver à dégager
des faits indiscutables qui permettent d’apprécier la couverture et
l’efficacité des points de contrôles. Cette phase est délicate et
compliquée dans la mesure où les informations collectées auprès des
opérationnels ressemblent plus à des opinions qu'à un apport sur les faits
recherchés.
V - METHODOLOGIES DES AUDITS DES SI
6- Vérifier l’efficacité : il s’agit d’apprécier la pertinence des
résultats des points de contrôle mis en place ( gestion de
l’exploitation, gestion de la sécurité, etc).
7- Les tests de procédure et les contrôles de substance : il
s’agit ici de déterminer l’étendue et le calendrier de la mise
en œuvre des procédure au regard des risques identifiés
8- la Communication et le rendu des conclusions
L’auditeur se doit de communiquer avec l’organe de
l’administration en charge du SI et de donner son rendu au
terme de sa mission
VI- RÉFÉRENCES ET NORMES
Le cadre de référence a pour objectif de définir un dispositif de
contrôle efficaces et performants qui permette de maîtriser
efficacement l'activité du SI
L'auditeur se sert des référentiels qui lui permettent d’évaluer la
mise en œuvre des meilleures pratiques liées au SI pour les buts
suivants :
la conformité au cadre normatif (Procédure, lois, règlements…)
la fiabilité (sécurité) du systèmes (équipement, applicatifs…) et
des données
la réalisation et l'optimisation des opérations (traitements)....
VI- RÉFÉRENCES ET NORMES
Entreprises de normalisation
Elles mettent en place des cadres de contrôle qui visent à aider le
management à gérer les risques (sécurité, fiabilité, conformité) et
les investissements SI
ISO : Organisation Internationale de normalisation, créé en 1946
ISACA : Information Systems Audit & Control Association) est
l'association internationale des auditeurs informatiques, créé en
1967 a mis en plusieurs plusieurs référentiels de bonnes pratiques
des SI
SANS: SysAdmin, Audit, Network, Security Institute : pour ce qui est de la
formation et de la sensibilisation à la sécurité des TI
AFAI : Association Française de l'Audit et du conseil Informatique
VI-RÉFÉRENCES ET NORMES
L'auditeur dispose d’une gamme variée de référentiels
qui lui sert de guide selon le domaine audité.
CMMI : Capability maturity model integration
Créé en 1991 par le SEI (Software Engineering Institute)
de l'université Carnegie-Mellon, financé par le DoD
le CMMI est un modèle de bonnes pratiques du génie
logiciel pour appréhender et mesurer la qualité des
services rendus.
Il permet d’évaluer et améliorer les activités des
entreprises d'ingénierie
VI-RÉFÉRENCES ET NORMES
CMMI se décline en trois modèles appelés « constellations » dont
la particularité est qu'ils ont une partie commune (noyau ou core
qui représente environ 60 % des pratiques. Les différences portent
essentiellement sur la catégorie de l’activité
CMMI-DEV pour le développement de systèmes (logiciel ou
autre, modèle publié en août 2006)
CMMI-ACQ pour la maîtrise des activités d'achat (modèle publié
en novembre 2007
CMMI-SVC pour la fourniture de services (modèle publié en
février 2009
VI-RÉFÉRENCES ET NORMES
On distingue :
Les objectifs génériques : CMMI fournit cinq objectifs
génériques et les pratiques associées qui s'appliquent à
tous les domaines de processus.
Les pratiques génériques : les pratiques génériques
appartiennent aux objectifs génériques. Elles doivent
être systématiquement implémentées pour prétendre
atteindre un niveau de maturité ou de capacité
VI-RÉFÉRENCES ET NORMES
Les objectifs spécifiques : les objectifs spécifiques sont
liés à un domaine de processus
Les pratiques spécifiques : elles sont liées à un objectif
spécifique, donc à un domaine de processus
Les produits d'activité : ce sont tous les éléments
générés par un projet (plan de projet, spécification,
cahier de test unitaire, revue par les pairs, etc.)
VI-RÉFÉRENCES ET NORMES
CMMI définit :
une échelle à cinq niveaux de mesure de la
maturité des processus
des indicateurs, nécessaires pour évaluer les
activités menées, par une équipe
l'équipe : peut être un groupe de travail, un ou
plusieurs projets, une société voire une institution
d'État
VI-RÉFÉRENCES ET NORMES
NIVEAU DE MATURITE 1 « Initial » : Il n'y a pas de
description, pas de surveillance, aucune évaluation de
performance et la communication est absente et es
réactions aux incidents se font en mode urgence, sans
identification claire des priorités
NIVEAU DE MATURITE 2 « Managed », (discipline) : Une
discipline est établie et se matérialise essentiellement
par des plans de développement, d'assurance qualité,
de gestion de configuration.
VI-RÉFÉRENCES ET NORMES
NIVEAU DE MATURITE 3 « Defined », (ajusté) : Ce niveau est caractérisé par des lignes
directrices, un plan stratégique, une planification de l'amélioration de
processus, en ligne avec les objectifs d'affaire de l'organisation, la
formalisation des responsabilités et des devoirs des employés.
NIVEAU DE MATURITE 4 « Quantitatively managed », (gestion quantitative) :
caractérisé par le pilotage des processus sur la base d'objectifs quantitatifs
de qualité produit et processus
NIVEAU 5 « Optimizing », (optimisation) : Les processus qui sont gérés
quantitativement pour le pilotage de projet (niveau de maturité 4) sont en
amélioration constante afin d'anticiper les évolutions prévues (besoins clients,
nouvelles technologies…)
VI-RÉFÉRENCES ET NORMES
NIVEAU DE MATURITE 3 « Defined », (ajusté) : Ce niveau est caractérisé par des lignes
directrices, un plan stratégique, une planification de l'amélioration de
processus, en ligne avec les objectifs d'affaire de l'organisation, la
formalisation des responsabilités et des devoirs des employés.
NIVEAU DE MATURITE 4 « Quantitatively managed », (gestion quantitative) :
caractérisé par le pilotage des processus sur la base d'objectifs quantitatifs
de qualité produit et processus
NIVEAU 5 « Optimizing », (optimisation) : Les processus qui sont gérés
quantitativement pour le pilotage de projet (niveau de maturité 4) sont en
amélioration constante afin d'anticiper les évolutions prévues (besoins clients,
nouvelles technologies…)
VI-RÉFÉRENCES ET NORMES
Aperçu du référentiel CMMI
VI-RÉFÉRENCES ET NORMES
ITIL (IT Infrastructure Library)
Conçue sur l’initiative du gouvernement britannique, ITIL couvre
l'essentiel des activités d'exploitation et de production des
services. Il aborde les sujets suivants :
Comment organiser un système d'information ?
Comment améliorer l'efficacité du système d'information ?
Comment réduire les risques ?
Comment augmenter la qualité des services informatiques ?
VI-RÉFÉRENCES ET NORMES
ITIL (IT Infrastructure Library)
ITIL décrit comment on s'assure que le « client » a accès aux
services informatiques appropriés, et comprend :
Le centre de services (service desk)
La gestion des incidents (incident management)
La gestion des problèmes (problème management)
La gestion des changements (change management)
La gestion des mises en production (release management)
La gestion des configurations (configuration management)
VI-RÉFÉRENCES ET NORMES
ITIL couvre six guides principaux :
Service Support : il est consacré aux process
support qui permet la gestion des services ;
Service Delivery : Consacré à la gestion des
services informatiques
Software Asset Management : Ce module
explique en quoi consiste le pilotage d’un
service IT et comment le rendre performant et
efficace
VI-RÉFÉRENCES ET NORMES
Quelques aspects SI abordés par ITIL
Gestion des changements : Mettre en œuvre des
démarches de conduite du changement afin
d'anticiper les effets de bord
Gestion de la continuité des services : Définit et met en
œuvre des délais contractuels pour la reprise après
incident
Gestion des niveaux de service : Définit les SLA et
comment maintenir un certain niveau de qualité de
service grâce à des contrats de service
VI-RÉFÉRENCES ET NORMES
ICT Infrastructure Management : Consacré à l’organisation et aux
outils nécessaires à la fourniture stable des ICT (Information and
Communications Technology) ;
Application Management : C’est un module qui concerne le cycle
de développement et de support d’un logiciel ainsi que l’examen
des services IT ;
Security Management : il est consacré à la sécurité dans les
services informatiques.
VI-RÉFÉRENCES ET NORMES
Quelques aspects SI abordés par ITIL
Gestion des configurations : il décrit comment l'infrastructure doit
être gérée à travers un état des lieux de l'existant et explique
comment le faire évoluer
Gestion des incidents : il explique comment détecter les incidents,
améliorer le délai de résolution des incidents selon leur criticité sur
le fonctionnement de l'entreprise
Gestion des problèmes : Mieux gérer les problèmes récurrents et
mettre en œuvre des solutions de prévention afin de réduire leur
occurrence, voire les supprimer.
VI-RÉFÉRENCES ET NORMES
Aperçu du référentiel ITIL
VI- RÉFÉRENCES ET NORMES
COBIT (Control Objectives for Business and related Technology)
initialement publié en 1994 par l’ISACA (Information Systems Audit and
Control Association), COBIT est l’un des référentiels de contrôle et de
gouvernance des SI. La version 5.0 du CobiT a été publiée en 2012
CobiT est à la base de la Gouvernance et le Management des SI. Il
propose une série d’objectifs de contrôle des SI qui aide le management
à concevoir une politique d’évaluation et de gestion des risques liés aux
SI.
VI-RÉFÉRENCES ET NORMES
Il comprend six domaines d’intervention à savoir :
Executive summary (Synthèse) : Cette partie résume
de la méthodologie CobiT;
Framework (Cadre de Référence) : c’est la partie
explicative des méthodes, des domaines et des
processus) ;
Control objectives (Objectifs de contrôle détaillés) :
ces objectifs sont orientés vers le management et les
équipes responsables des services informatiques) ;
VI- RÉFÉRENCES ET NORMES
Audit guidelines (le guide de l'audit) : décèle, analyse
et explique les failles d'un système et les risques qui en
découlent ainsi que de leur apporter des solutions)
Implementation Tool Set : les outils de la mise en œuvre
du CobiT ;
Management Guidelines (le guide du management) :
Ce guide propose un cadre de 5 degré de pilotage ou
« tableau de bord prospectif (balanced score card) »
VI- RÉFÉRENCES ET NORMES
Il permet le développement d’un système cohérent de règles,
normes et procédures. Les principes de COBIT5 permettent :
de répondre aux besoins de toutes les parties prenantes
de couvrir l'entreprise dans sa globalité
d’appliquer un référentiel unique et intégré ;
de facilité une approche globale ;
de distinguer la gouvernance de la gestion.
Ces principes sont accompagnés de sept facilitateurs ou leviers de
gouvernance qui couvre et soutiennent de bout en bout toutes les
fonctions et tous les processus du SI.
VI-RÉFÉRENCES ET NORMES
COBIT5 dénombre trente-sept processus repartis en 5
domaines.
Evaluer, Diriger et Surveiller (EDS) : Ce domaine comprend cinq
processus. Il permet de s’assurer du respect des grandes règles de
gouvernance ;
Aligner, Planifier et Organiser (APO) : Ce domaine comprend treize
processus. Ce sont les bases de la gestion de l’informatique ;
Bâtir, Acquérir et Implanter (BAI) : Ce domaine comprend dix
processus. Le but de ce domaine est d’améliorer les processus de
définition et de mise en place des applications informatiques ;
VI-RÉFÉRENCES ET NORMES
COBIT5 dénombre trente-sept processus repartis en 5
domaines.
Livrer, Servir et Soutenir (LSS) : Ce domaine comprend six
processus. L’objectif est de perfectionner le
fonctionnement de l’exploitation informatique ;
Surveiller, Evaluer et Mesurer (SEM) : Ce domaine
comprend trois processus. Il détaille les bases du contrôle
des Systèmes d’Information dont le contrôle interne.
VI-RÉFÉRENCES ET NORMES
CobiT Quickstart :
Version simplifiée de CobiT s'adresse principalement aux
PME1 pour lesquelles les techniques informatiques ne
représentent pas un enjeu stratégique mais simplement
un levier dans leur stratégie de croissance.
Il s’interesse à la direction générale en indiquant ce que
l'implantation d'un processus donné va apporter sur les
informations (par exemple sur l'information décisionnelle)
VI-RÉFÉRENCES ET NORMES
Il se repose sur les hypothèses suivantes :
l'infrastructure informatique n'est pas complexe
la taille de l'entreprise, le système d'information
et l'activité sont bien alignés ;
les tâches les plus complexes sont externalisées
la tolérance aux risques est relativement élevée
l'éventail des contrôles est peu étendu ;
la structure de commandement est simple.
VI- RÉFÉRENCES ET NORMES
CobiT Quickstart se base sur les facteurs suivants :
Efficacité : qualité et pertinence de
l'information, distribution cohérente ;
Efficience : rapidité de délivrance ;
Confidentialité : protection contre la divulgation
Intégrité : exactitude de l'information ;
VI-RÉFÉRENCES ET NORMES
CobiT Quickstart s’appuie sur ressources telles que :
le personnel et collaborateurs (internes et
externes)
les applications : ensemble des procédures de
traitement
l'infrastructure : ensemble des installations, Data
Center ;
les données : informations au sens global (format,
structure ;
VI-RÉFÉRENCES ET NORMES
Disponibilité : accessibilité à la demande et
protection (sauvegarde) ;
Conformité : respect des règles et lois ;
Fiabilité : exactitudes des informations
transmises par le management.
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum)
TOGAF est norme utilisée pour la structuration en couche de
l'architecture des SI.
Il permet d’avoir une vue globale des actifs informationnels de la
gouvernance et du management de l’entreprise.
Le framework TOGAF structure le SI en quatre couches qui définissent
une vision spécifique du SI à savoir :
la couche business ;
la couche des données ;
la couche application ;
la couche technologique
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : la couche business
Elle décrit la vision stratégique de l’entreprise, la gouvernance,
l’organisation et l’ensemble des processus métiers clés.
Les activités qui se réfèrent à ces processus doivent être en cohérence
avec les facteurs dont le suivi permettrait de mieux maitriser la
trajectoire et la conduite de l’entreprise. Il s’agit entre autres de :
la vision : elle porte sur la stratégie globale pour atteindre un but,
déclinée en stratégies opérationnelles pour des objectifs et en
schémas directeurs pour les indicateurs de performance ;
la dénombrabilité : les processus, les étapes des processus et les
résultats de chacun doivent être bien définis ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : la couche business
Le pilotage : il consiste à avoir un tableau de bord d’indicateurs
stratégiques et opérationnels de performance ;
le jalonnage : fait référence à des périodes de contrôle et de
recadrage vis-à-vis de la stratégie ;
la subsidiarité : c’est la définition des limites de responsabilités ;
le mode de fonctionnement : il s’agit de l’ensemble des
procédures, des chartes internes, des règlements qui régissent le
fonctionnement de l’organisation.
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche
donnée
Elle fait référence d’une part, à la structure et l’organisation
des données aux niveaux logique et physique, et d’autre
part, aux référentiels des données et la manière dont elles
sont gérées.
L’on distingue deux types de données que sont :
les données référentielles : ce sont des données quasiment
stables, évoluant très peu et nécessaires au fonctionnement
des processus et à la prise de décision.
les données opérationnelles : elles sont volatiles et concernent
les transactions quotidiennes de l’entreprise.
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche donnée
Il est important de pouvoir évaluer la qualité des données afin
de déterminer dans quelle mesure elles demeurent pertinentes
pour l’organisation.
Les facteurs de qualité non exhaustifs ci-après désignent un
ensemble de caractéristiques intrinsèques et fonctionnelles :
La fraicheur : elle permet d’avoir une bonne visibilité sur un fait
ou un évènement à un instant donnée, afin de prendre la
décision adéquate ;
La cohérence : il s’agit de l’homogénéité des données avec
les contraintes de l’organisation ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche donnée
la pertinence : elle représente le degré d’utilité
de la donnée pour une tâche ;
l’exactitude : c’est la variance de la donnée
reçue par rapport à la donnée réellement
représentative ;
la traçabilité : elle permet de suivre le
cheminement des données dans l’organisation ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche application
Elle définit le parc applicatif de l’entreprise, les
interactions entre les applications, les processus
métiers et la couverture fonctionnelle des
applications.
L’objectif est d’harmoniser les échanges dans
l’organisation par la distribution et la réutilisation
des fonctions applicatives.
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche application
Il s’agit de suivre tout flux informationnels des points de
vue fonctionnel, utilisation et maintenance. par des
facteurs de qualité.
Point de vue « fonctionnel » :
Pertinence : c’est la capacité de répondre au
problème de l’entreprise ;
Adéquation : c’est l’adéquation du logiciel à
l’organisation et aux procédures de l’entreprise ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche application
Il s’agit de suivre tout flux informationnels des points de vue
fonctionnel, utilisation et maintenance. par des facteurs de
qualité.
Point de vue « fonctionnel » :
Pertinence : c’est la capacité de répondre au problème de
l’entreprise ;
Adéquation : c’est l’adéquation du logiciel à l’organisation
et aux procédures de l’entreprise ;
Evolutivité : c’est la facilité à ajouter d’autre fonction ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche
application
Point de vue « utilisation »
Maniabilité : aptitude du logiciel à être
convivial et simple d’emploi
Interopérabilité : Aptitude du logiciel à
communiquer ou interagir avec d’autres
système.
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : couche application
Point de vue « maintenance »
Maintenabilité : aptitude avec laquelle on
peut détecter et corriger les erreurs ;
Portabilité : aptitude à fonctionner d’un
logiciel dans un autre environnement ;
VI- RÉFÉRENCES ET NORMES
TOGAF (The Open Group Architecture Forum) : Couche technologique
Elle décrit l’infrastructure logicielle, matérielle et réseau nécessaire au déploiement des données et des
applications.
L’objectif est de s’assurer que les infrastructures obéissent aux facteurs de qualité que sont entre autres :
la normalisation : elle concerne les normes et les standards uniformes, ouverts et reconnus sur lesquels
doivent reposer les infrastructures ;
la modularité : les infrastructures doivent s’organiser en composants autoportants, indépendants,
réutilisables, privilégiant une autonomie fonctionnelle et technique ;
l’écoresponsabilité : les infrastructures technologiques doivent être choisies et gérées de façon à
respecter l'environnement.
L’adoption du principe des 3RV-E (réduire, réutiliser, recycler, Valoriser et Eliminer) est prescrite pour
soutenir le développement durable
VI- RÉFÉRENCES ET NORMES
La structuration en couches par TogaF utilise l’ADM
(Architecture developemnt method) qui est un process
circulaire et itératif représenté par plusieurs phases.
La phase préliminaire
décrit les activité à implémenter pour la mise en place
de l’architecture d’une entreprise
Décrit le rôle de chaque département dans la mise en
place de l’architecture
VI- RÉFÉRENCES ET NORMES
La phase A : Vision de l’architecture
décrit en quoi consiste la phase initiale du cycle de mise
en place de l’architecture
Définit le périmètre des activités de mise en place de
l’architecture, identifie les parties prenantes, les outils de
pilotage du projet et l’approbation de la validation du
projet par l’équipe de pilotage
VI- RÉFÉRENCES ET NORMES
La phase B : Objectif de l’architecture
décrit comment les objectifs du projet de mise en place
de l’architecture sont en cohérence avec la vision de
l’entreprise
La phase C : Systèmes d’Information sur lesquels s’appuie
l’architecture
Décrit les données, les applications et les architectures des
applications
VI- RÉFÉRENCES ET NORMES
La phase D : Les technologies de l’architecture
Décrit l’architecture existante (technologie, données,
application, technologie)
Analyse les écarts entre l’architecture existante et
l’architecture cible
La phase E : Opportunités et solutions
Planification initiale de l’implémentation, identification des livrables
du projet défini dans la phase précédente
VI- RÉFÉRENCES ET NORMES
La phase F : Planification de la migration
Créer un ensemble d’activités détaillées par séquence
de transition pour l’implémentation du plan de migration
La phase G : Implémentation de la Gouvernance
Présente les avantages du modèle architectural implémenté
La phase H : Changement de management
Décrit comment assurer la continuité des services et présente les
nouveaux process de management et s’assure que l’architecture
mise en place répond aux besoins de l’entreprise
Phase de Management
S’assure que chaque phase ne s’écarte pas des objectifs fixés
VI- RÉFÉRENCES ET NORMES
Architecture Developement Method
VI-RÉFÉRENCES ET NORMES
Contenu du cadre des travaux :
Présente le modèle structuré de la conduite des
travaux
Et définit les trois catégories de produits :
Les délivrables
Les artéfacts
blocs
VI-RÉFÉRENCES ET NORMES
Continuum (vue global)
VI-RÉFÉRENCES ET NORMES
The Abu Dhabi IT Architecture & Standards
Framework : C’est un référentiel qui décrit le SI
sur huit niveaux notamment : Métiers, Accès et
présentation, Application, Données, Intégration,
Infrastructure, Sécurité et Exploitation
ISO 27002 : c’est un code de bonnes pratiques en
matière de management de la sécurité des systèmes
d'information ;
VI-RÉFÉRENCES ET NORMES
Val IT : Mis en place par l’ISACA, permet
d'évaluer la création de valeur par projet ou par
portefeuille de projets ;
Risk IT : Mis en place par l’ISACA, a pour but
d'améliorer la maîtrise des risques liés à
l'informatique ;
VII- Catégories d’audits des SI
L’audit des missions généralistes
Il a pour objectif de vérifier la cohérence de la stratégie
numérique à l’activité de l’organisation
Il fournit une approche des implications SI dans les missions-
types de l’organisation
Il permet d’avoir une vue des principaux enjeux, risques
associés, des acteurs à rencontrer des documents à
récupérer et les principales questions à aborder dans l’audit
spécifique
VII - Catégories d’audits des SI
L’audit de l’organisation
Les organisations utilisent quotidiennement les ressources
informatiques (bureautique, applications dédiées, etc) sans être
conscientes que ces ressources sont, désormais, au cœur de leur
performance et indispensables à leur bon fonctionnement.
L’audit de l’organisation tient compte de la relation avec l’
informatique et vérifie comment l’organisation a procédé pour définir
les besoins en ressources informatiques afin de disposer d’un SI
efficient
VII - Catégories d’audits des SI
1- L’audit de l’organisation
L’auditeur devra à cet effet :
▪ Etudier le fonctionnement de la comitologie associée au
pilotage des SI ;
▪ Se demander si les ressources informatiques sont convenables
et dimensionnées conformément aux besoins et la charge de
l’activité ;
▪ vérifier que l’organisation a mis en place le corpus minimal de
politique du SI, politique de sécurité du SI, charte d’utilisation
VII - Catégories d’audits des SI
▪ Rencontrer la direction générale pour mesurer son degré de
sensibilisation au fait informatique et l’organisation qu’elle a
mise en place pour piloter ses SI ;
En définitive, l’auditeur devra porter une appréciation sur :
➢ la capacité de l’organisation à piloter ses ressources informatiques
➢ les enjeux de la valeur du patrimoine numérique
➢ les risques qui pèsent sur les ressources informatiques et le SI
VII- Catégories d’audits des SI
Il devra se procurer :
les politiques SI et de sécurité SI de l’organisation ;
le plan d’occupation au sols (POS) du SI
la liste des responsables de zones fonctionnelles ;
la charte de l’utilisateur des SI à laquelle sont soumis les
membres de l’organisation ;
la liste des processus de l’organisation incluant les SI qui les
supportent ;
la politique RH et de formation
VII - Catégories d’audits des SI
2- L’audit de processus
De plus en plus, les processus des organisation sont pour la plupart
fortement dépendants des outils informatiques. A cet effet, la
performance d’un processus s'avère intimement liée à la qualité des
systèmes informatiques.
l’audit des processus permet donc d’évaluer le niveau de maturité du
processus
Il intègre l’audit des outils informatiques sur lesquels le processus
s’appuie, l’examen des données et les informations manipulées au cours
du déroulement du processus, ainsi que la communication avec les
autres processus.
Catégories d’audits des SI
L’auditeur devra :
étudier à travers les documents qui décrivent le processus
son fonctionnement, les données et informations
manipulées, et les applications et les infrastructures
ressources.
vérifier que la sécurité physique et logique des données, des
informations, des applications et des infrastructures est en
cohérence avec l’analyse des risques du processus.
vérifier la pertinence de l’analyse des risques sur le
processus et ses ressources ;
Catégories d’audits des SI
Etudier le dispositif de contrôle interne destiné à maîtriser le
processus,
Vérifier que les infrastructures (particulièrement réseaux et
serveurs) et les dispositifs d’assistance aux usagers de ces
systèmes sont suffisants pour répondre aux besoins du
processus
Catégories d’audits des SI
2- L’audit de processus
L’auditeur devra rencontrer
la direction générale pour évaluer le mécanisme de
pilotage et contrôle du processus ainsi que leur cohérence
la ou les directions concernées par le processus audité, pour
évaluer le degré de maturité du processus, et étudier
l’organisation qu’elles ont mise en place en vue de définir
et exprimer des besoins informatiques du processus ;
Catégories d’audits des SI
2- L’audit de processus
l’auditeur devra se procurer :
la cartographie des processus ;
la description du processus audité, incluant l’inventaire des données
et informations manipulées et des applications et infrastructures
utilisées
les tableaux de bord de reporting du déroulement et de la
performance des processus ;
la cartographie des données, informations et applications
informatiques de l’organisation ;
Catégories d’audits des SI
la déclinaison des politiques SI et de sécurité SI à l’égard du
processus audité ;
La déclinaison de la charte des utilisateurs à l’égard des
acteurs du processus ;
En définitive, l’auditeur devra porter une appréciation sur
l’efficacité, l’efficience, la sécurité, et la résilience de
l’informatique aux besoins du processus audité
Catégories d’audits des SI
3- L’audit de régularité
L’audit de la régularité porte sur le respect des normes et du corpus
normatif qui impliquent les processus, les infrastructure, les applicatifs,
les données du SI.
Il permet de vérifier que les activités portées par les ressources
informatiques respectent elles-mêmes le cadre normatif à travers les
leurs règles.
L’auditeur devra :
identifier les ressources informatiques utilisées dans le périmètre de son
audit ;
Catégories d’audits des SI
3- L’audit de régularité
vérifier que les ressources sont en elles-mêmes régulières (licences,
respect des règles de conservation des données personnelles, respect
des règles de confidentialité, etc.) ;
vérifier et évaluer la fiabilité des traitements automatiques
conformément au corpus normatif applicable ;
vérifier que la sécurité appliquée à ces ressources, outre le respect
des règles de confidentialité, garantit raisonnablement qu’elles ne
peuvent être utilisées à des fins frauduleuses.
Catégories d’audits des SI
3- L’audit de régularité
L’auditeur devra rencontrer :
Les acteurs stratégiques du périmètre du champ audité
pour évaluer s’ils sont conscients de l’obligation du
fonctionnement du SI dans un cadre normatif et s’assurer
qu’ils respectent et font respecter les corpus normatifs
applicables
les acteurs opérationnels de l’entité/processus audité pour
identifier les ressources utilisées ;
Catégories d’audits des SI
Il devra se procurer :
la cartographie des applications et des systèmes, les
contrats et les licences ;
la description du dispositif de contrôle des règles du cadre
normatif ;
Sur ce point, l’auditeur devra apprécier à la fois sur la valeur
de la contribution de l’informatique à la réglementation des
activités informatiques.
Catégories d’audits des SI
4- Les audits des fonctions externalisées
Les motifs d’ouverture des système informatiques des organisations
vers des systèmes externes sont nombreux. A l’instar des taches liées à
l’administration de serveurs, de données ou d’applications via les
technologies de dématérialisation de l’informatique
Il y a des échanges des données, en temps réel ou non, entre des
parties cocontractants. Le cocontractant a alors la responsabilité de
l’intégrité, de l’accessibilité et de la protection des données.
Cet audit aborde les obligations des parties cocontractantes dans les
prestations des services informatiques
Catégories d’audits des SI
4- Les audits des fonctions externalisées
l’audit des fonctions externalisées a pour objectifs :
D’identifier les données et informations numériques
échangées entre les parties
D’identifier les ressources informatiques matérielles (serveurs,
réseaux, etc.) et applicatives qui y contribuent, ainsi que le
personnel interne et extérieur qui y participe ;
vérifier que le contrôle interne, y compris la résilience,
appliquée aux ressources est en cohérence avec les enjeux
de l’organisation ;
Catégories d’audits des SI
4- Les audits des fonctions externalisées
Vérifier la conformité de l’exécution des prestations conformément au
cadre normatif des services IT de l’organisation ;
Vérifier la conformité de l’exécution des prestations conformément au
marché ;
L’auditeur devra rencontrer :
les acteurs opérationnels de l’organisation chargés des relations
courantes avec le prestataire, pour identifier les ressources
informatiques (informationnelles, matérielles et humaines) concernées
par la prestation externalisée ;
Catégories d’audits des SI
4- Les audits des fonctions externalisées
la direction chargée du SI, pour vérifier qu’elle a validé les échanges
avec le prestataire, y compris le cas échéant, les modalités
d’interconnexion avec les systèmes externes
Les documents à utiliser sont :
les marché(s) qui régissent l’externalisation ;
la description des processus externalisés et de ceux impactés par
l’externalisation
Catégories d’audits des SI
4- Les audits des fonctions externalisées
L’auditeur devra se procurer :
l’inventaire des ressources informatiques utilisées ou impactées par
l’exécution de la prestation externalisée (notamment la cartographie
des applications et des systèmes)
la description du dispositif de suivi et de contrôle interne des
prestations
Sur ce point, l’auditeur devra porter une appréciation sur la qualité de
la prise en compte des prestations externalisées et se prononcer sur les
fragilités éventuelles qui peuvent résulter de l’externalisation,
notamment en termes de irréversibilité, de sécurité et de contrôle
interne.
VIII- APPROCHE D’AUDIT DES SI
Généralement, l’audit des SI se fait dans les champs suivants :
- Gouvernance des TI
- Audit des données
- Audit de la passation de contrats TI
- Audit de la sécurité
L’ensemble est intégré dans les phases de planification,
d’évaluation des contrôles généraux et d’évaluation des
contrôles des applications
VIII- APPROCHE D’AUDIT DES SI
1- La planification
Le Système d’information est considéré comme un ensemble
de parties interdépendantes (structures physiques, personnel,
outils informatiques) qui interagissent afin d’enregistrer, de
contrôler, d’évaluer et de gérer les transactions.
Cette phase permet d'acquérir une compréhension des
procédures, des méthodes, des opérations, des contrôles et
des risques liés au système
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux
Les contrôles généraux ont pour objectif de sauvegarder les données,
protéger les programmes des applications et assurer la continuité des
opérations informatiques en cas d’interruptions imprévues.
C’est le cadre de contrôles de l’ensemble des fonctions du SI.
Les différentes catégories de contrôles généraux sont :
Contrôles organisationnels, Contrôles d’accès physique, Contrôles
d’accès logique, Contrôles environnementaux, Contrôles de
modifications des programmes, Plans de continuité des activités et de
reprise après sinistre
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Contrôles organisationnels
Les contrôles organisationnels sont les politiques, les
procédures et le cadre organisationnel établis pour garantir :
les politiques de ressources humaines et les pratiques de
management saines, la séparation des fonctions
les stratégies de sécurité d’information mises en œuvre qui
permettent de fournir des méthodes pour évaluer
l’efficacité et assurer l’efficience des contrôles
opérationnels
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Contrôles d’accès physique
Les contrôles d’accès physique comprennent les règles et
pratiques pour empêcher l’accès non autorisé et les
interférences avec les services informatiques,
y compris des procédures administratives comme les badges
d’identité pour le personnel, le contrôle des visiteurs, les
mesures physiques telles que les serrures à clé mécaniques et
les serrures électroniques, les caméras et les autres moyens de
limiter l’accès physique aux serveurs et aux autres
infrastructures essentielles.
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Contrôles d’accès logique
Ils portent sur la sécurité intégrée aux systèmes informatiques
pour empêcher tout accès non autorisé aux données afin de
s’assurer que tous les utilisateurs disposent de droits d’accès
limités aux besoins de leurs fonctions.
Ils comprennent les parefeux, antivirus, logiciels de détection
d’intrusions et de programmes malveillants.
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Contrôles environnementaux
Les contrôles environnementaux portent sur les règles, les
pratiques et les conditions établies pour éviter tout dommage
causé par l’instabilité électrique, l’incendie, la poussière,
l’eau, la nourriture, les températures extrêmes ou l’humidité, et
l’électricité statique.
Le but de ces contrôles concerne les espaces dédiés aux
équipements informatiques qui exigent un milieu spécifique.
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Contrôles de modifications des
programmes
ce sont les règles qui visent à garantir que toutes les
modifications apportées à la configuration du système sont
gérées correctement, totalement et en temps utile.
Les mises à niveau et les modifications devraient être dotées
d’un processus officiel pour assurer la journalisation de tous
les changements et permettre la possibilité de faire marche
arrière si des problèmes apparaissent avec la nouvelle
version.
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Plans de continuité des activités et de reprise
après sinistre
Le plan de continuité des activités est une approche globale qui
définit les voies alternatives pour le maintien des processus
opérationnels critiques en cas d’urgence, de catastrophe ou autre
perturbation
Le Plan de reprise après sinistre est la partie du Plans de continuité des
activités qui tient compte des exigences en matière des réseaux
informatiques et des télécommunications.
VIII- APPROCHE D’AUDIT DES SI
2- Les contrôles généraux : Plans de continuité des activités et
de reprise après sinistre
Le plan de continuité et de reprise doit avoir au minimum :
▪ les procédures et les critères pour déterminer quand une
situation est un sinistre
▪ la personne responsable de déterminer le sinistre
▪ Comment déclarer un événement comme étant
officiellement un sinistre et lancer sa mise en œuvre
VIII- APPROCHE D’AUDIT DES SI
3- Les contrôles des applications
L’objectif est de garantir l’intégralité, la fiabilité et l’exactitude
du traitement des données.
Les contrôles des applications sont automatisés dans les
applications du SI afin de contribuer à garantir l’autorisation,
l’intégrité, l’exactitude et la validité des transactions. Ils font
intervenir plusieurs types de contrôles à savoir :
Les contrôles d’entrée : garantissent l’autorisation, la
précision, l’intégralité et la ponctualité des données entrées
dans une application.
VIII- APPROCHE D’AUDIT DES SI
3- Les contrôles des applications
Les contrôles de traitement : garantissent l’exactitude, l’intégralité et
la ponctualité des données au cours des traitements. Par exemple à
l’issue d’une opération de modification des données d’un client,
l’application affiche un message confirmant que le traitement a été
réussi
Les contrôles de sortie : assurent l’intégrité des sorties ainsi que la
diffusion correcte et ponctuelle des sorties produites.
La sortie d’une application peut être l’entrée vers une autre
application. Si tel est le cas, le vérificateur doit rechercher les
contrôles qui garantissent que les sorties sont transférées avec
précision d'une étape de traitement à l’autre
VIII- APPROCHE D’AUDIT DES SI
3- Les contrôles des applications
Les contrôles de traitement : garantissent l’exactitude, l’intégralité et la
ponctualité des données au cours des traitements. Par exemple à l’issue
d’une opération de modification des données d’un client, l’application
affiche un message confirmant que le traitement a été réussi
Les contrôles de sortie : assurent l’intégrité des sorties ainsi que la
diffusion correcte et ponctuelle des sorties produites.
La sortie d’une application peut être l’entrée vers une autre application.
Si tel est le cas, le vérificateur doit rechercher les contrôles qui
garantissent que les sorties sont transférées avec précision d'une étape
de traitement à l’autre
VIII- APPROCHE D’AUDIT DES SI
3- Les contrôles des applications
Une fois que les contrôles ont été identifiés, l’étape suivante de
l’audit est de vérifier leur efficacité.
Il s’agira pour l’auditeur de :
▪ soumettre un ensemble de données de test lesquelles, si
l’application fonctionne correctement, produiront des résultats
connus;
▪ développer des programmes indépendants pour ré-exécuter la
logique de l’application ;
▪ évaluer les résultats de l’application
VIII- APPROCHE D’AUDIT DES SI
3- AUDIT DU PILOTAGE DES SYSTEMES D’INFORMATION
L’objectif de l’audit est d’évaluer la « maturité » informatique de l’Organisation et
l’adéquation du rôle, du positionnement et des objectifs de la DSI avec les enjeux de
l’Organisation.
PC1 : Rôle et positionnement de l'informatique dans l'organisation
- La DSI est-elle rattachée à la DG et présente au COMEX ?
- vérifier que la DSI est une force de proposition et de conseil dans le domaine des
technologies de l’information.
- Vérifier l’existence d’une charte informatique ou de tout autre document définissant
le rôle et le périmètre de responsabilité de la DSI
- Vérifier que les métiers assurent leur rôle de MOA, en prenant en charge des aspects
de pilotage, des processus, de gestion de changement, de sécurité et d’évolutivité
VIII- APPROCHE D’AUDIT DES SI
3- AUDIT DU PILOTAGE DES SYSTEMES D’INFORMATION
PC2 : Planification stratégique
- Prendre connaissance du schéma directeur de l’Organisation et
analyser le plan informatique et la feuille de route du SI
- Prendre connaissance des documents d’urbanisme du SI
- Analyse des procédures de pilotage et de mise à jour du plan
d’occupation des sols (POS)
- analyse du positionnement du rôle des responsables de zones
fonctionnelles, de quartiers fonctionnels et de blocs fonctionnels.
VIII- APPROCHE D’AUDIT DES SI
3- AUDIT DU PILOTAGE DES SYSTEMES D’INFORMATION
PC3 : Budgets et coûts informatiques
- analyse du processus d’élaboration et de validation du budget
(qui, quand, comment) ;
- analyse des outils et procédures de suivi analytique, de contrôle
des coûts, d’analyse des écarts et le cas échéant de
refacturation des utilisateurs ;
- analyse de l’organisation du contrôle de gestion informatique
(existence d’un contrôleur de gestion dédié au sein de la DSI ?)
VIII- APPROCHE D’AUDIT DES SI
3- AUDIT DU PILOTAGE DES SYSTEMES D’INFORMATION
PC4 : Cadre législatif et réglementaire
- Vérifier que les prescriptions légales découle de la loi et sont
connues et respectées
- Vérifier que la loi sur la fraude informatique est connue et que
des mesures préventives ont été prises par :
- les bannières d’accueil des routeurs et serveurs d’accès distant
(de type “ Bienvenue.. ”, “ Welcome ”,…) sont-elles bannies et
remplacées par des messages d’avertissement ?
- effectuer des contrôles sur un échantillon de postes de travail et
contrôler les justificatifs de licences
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC1: Politique de sécurité
- Vérifier l’existence d’une politique de sécurité formalisée avec
une implication de la direction générale et une définition claire
des responsabilités
- Vérifier que l’ensemble des responsables et des employés sont
sensibilisés et informés sur la politique de sécurité
- Vérifier l’existence d’un système de mesure et d’évaluation de
l’efficacité de la gestion de la sécurité de l'information et de
collecte des suggestions d'amélioration.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC2: Organisation de la sécurité
- Vérifier l’existence d’une structure dédiée à la gestion de la
sécurité de l'information : un comité sécurité, un
responsable de la sécurité du système d'information (RSSI) et
des correspondants sécurité dans les unités.
- Vérifier l’existence des procédures d'autorisation de
nouveaux matériels ou logiciels
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC2: Organisation de la sécurité
- Vérifier l’existence des procédures d’accès aux informations de
l'organisation par des tiers notamment le contrôle des accès aux
infrastructures de traitement de l'information ;
- Existence des procédure d’analyse des risques ;
- Existence des mesures de protection de l'information (clause de
confidentialité, transfert de propriété, responsabilités, règles
d'accès physique et logique, restitution ou destruction de
l'information confiée, remplacement de collaborateur )
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC2: Organisation de la sécurité
Vérifier qu'il existe des modalités de réaction aux incidents
de sécurité et aux défauts de fonctionnement :
- Notification des incidents de sécurité ;
- Notification des failles de sécurité ;
- Notification du fonctionnement défectueux de logiciels ;
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC3 : Classification et contrôle des actifs
Vérifier que les actifs sont inventoriés et hiérarchisés par valeur
Vérifier que pour tout actif important, un propriétaire est désigné
et informé de ses responsabilités
Vérifier qu'il existe un système de classification qui définit un
ensemble approprié de niveaux de protection.
Vérifier que chaque actif a fait l'objet d'une étude visant à
déterminer son niveau de classification.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC4 : Sécurité du personnel
Vérifier que les postes et les ressources sont définis :
inclusion de la sécurité dans les responsabilités des postes
sélection du personnel et politique de recrutement ;
accords de confidentialité ;
Vérifier que les utilisateurs sont formés.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC5 : sécurité : gestion des communications et des opérations
Vérifier la documentation des procédures et les responsabilités
opérationnelles.
Contrôler les modifications opérationnelles.
Vérifier l'établissement de procédures de gestion des incidents.
Vérifier l'étude de sécurité en cas de gestion externe des
infrastructures
Vérifier les mesures de protection contre les infections logiques.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC5 : sécurité : gestion des communications et des opérations
Vérifier les sauvegardes des données :
réalisation régulière des copies de sauvegarde des données, des
applications et des paramètres ;
distinguer sauvegarde et archivage ;
déterminer les périodes de conservation des données ;
conserver plusieurs générations de sauvegardes ;
stocker les sauvegarde en lieu sûr ;
tester régulièrement les supports de sauvegarde ;
tester régulièrement les procédures de restauration
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC5 : sécurité : gestion des communications et des opérations
Vérifier les modalités de gestion des supports de données :
tenir en lieu sûr tous les supports amovibles ;
effacer de manière sécurisée le contenu des supports à réutiliser hors de l'organisation ;
établir une procédure de mise au rebut des supports prévoyant leur destruction ;
établir des procédures de manipulation des supports adaptées au niveau de sensibilité de
l'information contenue
Vérifier les mesures de sécurisation des échanges de données :
définition d'accords portant sur les échanges d'informations et de logiciels entre les
organisations ;
sécurité du courrier électronique.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC6 : Conformité
Vérifier la conformité aux exigences légales et réglementaires :
protection des données personnelles ;
respect de la propriété intellectuelle ;
Conservation de l'information
Effectuer des audits de sécurité réguliers :
internes et externes ;
revue systématique et tests empiriques (exemple : test d'intrusion) ;
protection des outils d'audit des systèmes ;
protection des rapports d'audit de sécurité.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC6 : Gestion des identifiants et des mots de passe
Vérifier qu'il y a un seul utilisateur par identifiant
Vérifier que les identifiants inutilisés pendant un certain délai sont révoqués
Vérifier que les règles de bases sont connues et mises en place :
utilisation systématique ;
le titulaire doit être le seul à connaître son mot de passe ;
changement périodique ;
procédures en cas d'inactivation ou de perte.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : . Contrôle des accès
Vérifier la définition et la documentation de la politique de
contrôle d'accès :
exigences de sécurité des applications individuelles de
l'organisation
profils d'accès standard des utilisateurs pour les catégories
communes de travail ;
établissement de règles "tout est interdit sauf" plutôt que "tout est
permis sauf" ;
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : . Contrôle des accès
Vérifier la gestion des accès utilisateurs :
identification unique des utilisateurs (tous les utilisateurs) ;
vérification que l'utilisateur a été autorisé par le propriétaire des informations ;
suppression des droits d'accès d'un utilisateur ayant changé de poste ou quitté l'organisation ;
contrôle périodique et suppression des codes d'identification utilisateurs redondants et des comptes
qui ne sont plus utilisés
non-réaffectation des codes d'identification ;
attribution des privilèges aux individus sur la base de leurs "besoins minimum" par rapport à la fonction
qu'ils remplissent ;
examen régulier des droits d'accès utilisateur.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : . Contrôle des accès
Vérifier l'utilisation de mots de passe et de systèmes de déconnexion
automatique :
tout compte utilisateur doit être protégé par un mot de passe ;
engagement des utilisateurs à :
ne pas divulguer leur mot de passe ;
ne pas écrire leur mot de passe de façon trop évidente ;
ne pas stocker leur mot de passe dans une procédure automatique ;
changer leur mot de passe dès qu'ils le soupçonnent d'être compromis ;
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : Contrôle des accès
contrôler qu'un mot de passe temporaire est envoyé pour la première
utilisation et qu'il est bien changé par l'utilisateur dès la première utilisation ;
contrôler que les mots de passe temporaires sont transmis aux utilisateurs de
manière sûre ;
contrôler que le système impose un changement régulier du mot de passe ;
contrôler que le système impose le choix de mots de passe robustes ;
discipline utilisateur pour la déconnexion ;
la déconnexion doit être automatique en cas d'inactivité prolongée.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : Contrôle des accès
Vérifier le contrôle des accès aux réseaux :
authentification des utilisateurs pour les connexions externes
protection des ports de diagnostic à distance et de
télémaintenance
contrôle des flux (firewalls)
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : Contrôle des accès
Vérifier le contrôle de l'accès aux systèmes d'exploitation :
identification / authentification des utilisateurs ;
limitation du nombre de tentatives infructueuses ;
enregistrement des tentatives infructueuses ;
limitation des jours et heures de connexion ;
affichage de la dernière connexion ;
protection de l'accès aux utilitaires.
Vérifier le contrôle de l'accès aux applications :
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : Contrôle des accès
Vérifier la gestion de l'informatique mobile :
contrôle d'accès aux ordinateurs portables ;
protection des données stockées (chiffrement) ;
protection contre les virus ;
connexions automatiques à distance ;
sensibilisation du personnel doté d'ordinateurs portables :
confidentialité du travail dans les lieux publics ou moyens de transport ;
surveillance du matériel contre le vol ;
espionnage industriel.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC7 : Contrôle des accès
Vérifier les suites données aux incidents :
vérifier les réactions des possesseurs des ordinateurs incidentés ;
vérifier les modalités effectives de remontée de l’information sur l’incident,
ses délais, son parcours, son format ;
vérifier les mesures d’isolement du ou des ordinateurs incidentés ;
vérifier l’effectivité des mesures de communication d’alerte ;
vérifier l’effectivité des mesures d’enquête et de l’exploration menée
pour identifier les failles du système ayant permis l’incident.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC8 : Développement et maintenance des systèmes
Exigences de sécurité des systèmes :
Expression des besoins, contrôle interne;
spécification détaillée des besoins, contrôle interne ;
audit des spécifications ;
recette des fonctionnalités de contrôle interne ;
audit de la recette ;
audit "post mise en place".
Sécurité des systèmes d'application :
validation des données d'entrée : type, limites de valeur, liste de valeurs possibles ;
contrôle des traitements : contrôles de sessions séquentielles, ;
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DE SECURITE
PC8 : Développement et maintenance des systèmes
exhaustivité des traitements ;
validation des données de sortie :
Protocole de recette :
tests systématiques avant le passage en production ;
utilisation d'un environnement différent de l'environnement de production ;
participation des utilisateurs à la recette ;
documentation de la recette et archivage ;
procédure de passage en production lors des maintenances correctives
urgentes (journalisation des actions)
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC1 : Audit de la sécurité et de la fiabilité : analyse des risques associés à
l'organisation
Existe-t-il un comité informatique, présidé par la direction générale et au sein
duquel les directions utilisatrices sont représentées et influentes (stratégie,
contrôle et pilotage,..) ?
Existe-il, au sein de l’organisation, une « politique » relative aux applications,
connue, partagée et mise en œuvre :
couvrant l’ensemble du cycle de vie de l’application (conception, exploitation) ;
favorisant la responsabilisation et l’appropriation par les utilisateurs de leur
système d’information ?
Implémentant la notion de « propriété » d’application
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC1 : Audit de la sécurité et de la fiabilité : analyse des risques associés à l'organisation
Le rôle et les responsabilités des utilisateurs vis-à-vis de l’application sont-ils
clairement identifiés et couvrent-ils l’analyse des risques, la définition des besoins de
sécurité, la gestion des changements et des évolutions, l’administration de
l’application ?
A-t-il été réalisé une analyse des risques, spécifique à l’application, qui a débouché
sur la définition des besoins de sécurité (classification formelle des données et des
traitements en termes de disponibilité, d’intégrité et de confidentialité) ?
Dans le prolongement de l’analyse des risques et de l’expression des besoins de
sécurité, a-t-il été mis en œuvre un contrat de service (SLA) entre l’informatique et la
direction utilisatrice ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à l'application
L'accès aux ressources de l'application (données et transactions) est-il restreint par
un système de gestion d'accès ?
Existe-t-il une procédure de gestion des profils utilisateurs de l'application placée
sous la responsabilité du propriétaire de l’application (procédure de création /
modification et suppression des droits d’accès) ?
Chaque utilisateur possède-t-il un identifiant qui lui est propre ? Vérifier qu’il n’existe
pas de compte « générique »
Le mot de passe associé à l'identifiant permet-il d'assurer une protection d'accès efficace (7
caractères minimum, gestion de l’historique des mots de passe sur 2 ans, contrôle de « trivialité »,
changement trimestriel des mots de passe, etc.) ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à
l'application
L'accès aux données et aux transactions de l’application peut-il être
correctement paramétré en fonction des tâches des utilisateurs ou le
système de confidentialité est-il basé sur le contrôle d’accès aux données ?
La séparation des tâches est-elle respectée dans le paramétrage des profils
?
comparer les droits d’accès avec les fonctions des utilisateurs ;
vérifier l’adéquation entre les droits et les profils ;
vérifier que toutes les personnes ayant des droits d’accès sont toujours dans le
service / l’organisation.
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à l'application
Les procédures de transmission de fichiers en entrée assurent-elles l'exhaustivité et
l'exactitude des informations transmises (contrôles systèmes) ?
Les contrôles mis en œuvre lors de l'intégration des données par fichiers à
l'application sont-ils suffisants et identiques à ceux mis en œuvre dans le cadre
d’une saisie transactionnelle (contrôles applicatifs) ?
Le système prévoit-il de conserver toutes les données rejetées dans un fichier
d'anomalies protégé et de les éditer en vue d'un contrôle et d'un recyclage ?
Les données rejetées sont-elles analysées et corrigées dans des délais raisonnables
et compatibles avec les délais de validation des traitements ?
Les corrections des données rejetées subissent-elles les mêmes contrôles que les
données initiales, et jouissent-elles d'une piste d'audit suffisante ?
L'intégrité et l'exhaustivité des données transmises entre les différents modules de
l'application et/ou à des applications en aval sontelles assurées ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC3: Audit de la sécurité et de la fiabilité : analyse des risques
associés à la fonction informatique
Au sein du service informatique, les tâches relatives au
développement et à l'exploitation de l'application sont-elles
séparées ?
L'équipe en charge de la maintenance (interne ou externe) at-
elle une maîtrise suffisante de l’application et les moyens de la
faire évoluer ?
Existe-t-il une procédure formalisée et standard de maintenance
de l’application validée par l'informatique et la maîtrise
d’ouvrage concernée ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC3: Audit de la sécurité et de la fiabilité : analyse des risques
associés à la fonction informatique
Un logiciel de contrôle de programmes sources et de
programmes exécutables est-il utilisé pour identifier et tracer
toute modification effectuée (piste d'audit) ?
. La gestion des incidents en général et les procédures
d'urgence en particulier sont-elles définies et correctement
documentées ?
Vérifier l’existence et l’application d’un Contrat de Service (SLA)
pour l’application : vérifier que le SLA couvre les besoins de
disponibilité, d’intégrité et de confidentialité de l’application et
de ses données
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC4: Audit d'efficacité et de performance: adéquation de l’application aux
besoins
Le projet s’inscrit-il dans le schéma-directeur du système d’information et ce
dernier est-il aligné avec le schéma directeur de l’organisation ?
Les utilisateurs ont-ils été suffisamment associés à la définition des
spécifications ou au choix de la solution puis aux évolutions successives ?
Les utilisateurs réalisent-ils toutes leurs tâches dans l’application (évaluation
du taux d’automatisation des opérations) ?
L’architecture technique est-elle adaptée et optimisée, notamment les
bases de données (bon dimensionnement des configurations, gestion des
évolutions techniques, personnalisation (tuning) des bases de données, …) ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC5: Audit de l’efficacité et de performance : analyse de la performance et
de la rentabilité
Le projet s’inscrit-il dans le schéma-directeur du système d’information et ce
dernier est-il aligné avec le schéma directeur de l’organisation ?
Les utilisateurs ont-ils été suffisamment associés à la définition des
spécifications ou au choix de la solution puis aux évolutions successives ?
Les utilisateurs réalisent-ils toutes leurs tâches dans l’application (évaluation
du taux d’automatisation des opérations) ?
L’architecture technique est-elle adaptée et optimisée, notamment les
bases de données (bon dimensionnement des configurations, gestion des
évolutions techniques, personnalisation (tuning) des bases de données, …) ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC6: Audit d'efficacité et de performance : analyse de
l'évolutivité/pérennité de l'application
Les technologies utilisées sont-elles conformes aux standards
de l’organisation ?
Le logiciel est-il de conception récente et fondé sur des
technologies portables, non obsolètes et évolutives
(matériel, OS, SGBD, outils de développements, …)
Les technologies utilisées sont-elles matures et suffisamment
répandues sur le marché (Linux, J2EE, .net,..) ?
VIII- APPROCHE D’AUDIT DES SI
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC6 :Audit d'efficacité et de performance : analyse de
l'évolutivité/pérennité de l'application
Les technologies utilisées sont-elles conformes aux standards de
l’organisation ?
Le logiciel est-il de conception récente et fondé sur des technologies
portables, non obsolètes et évolutives (matériel, OS, SGBD, outils de
développements, …)
Les technologies utilisées sont-elles matures et suffisamment
répandues sur le marché (Linux, J2EE, .net,..) ?
Le contrat prévoit-il une clause dite d’ « Escrow Agreement »
permettant de disposer des sources, auprès d’un tiers de confiance,
en cas de défaillance de l’éditeur ?
Les montées de versions sont-elles régulièrement effectuées ?
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC1. Fonction support : audit fiabilité et sécurité
Quelle structure de centre d’assistance (help-desk) (HD) est mise en
place
Existe-t-il une procédure de gestion des demandes, diffusée et
connue des utilisateurs ?
Quelle est la procédure d'escalade mise en place ?
Quelle est la couverture géographique du HD ?
Quelle est la couverture fonctionnelle du HD ?
Un outil est-il implémenté pour la prise d'appel et le suivi des tickets ?
Quelles sont les critères à renseigner pour la qualification des tickets ?
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC1. Fonction support : audit fiabilité et sécurité
Les problèmes sont-ils gérés ? Si oui quel est le processus ?
Les incidents de production de nuit sont-ils saisis aussi dans l'outil
?
Quels sont les comités mis en place pour suivre les incidents et
leur résolution ? Qui participe ? Comment sont suivies les actions
?
Si le HD est externalisé, existe-t-il un contrat de service ?
Quels sont les indicateurs pour suivre le contrat de service ?
Y-a-t-il un planning systématique concernant les mises en
production ?
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC2. Fonction support : audit d'efficacité et de performance
Existe-t-il une aide à la saisie pour la saisie des tickets ?
Existe-t-il des revues qualité pour la saisie des tickets ?
Quelle est la procédure de mise à jour de la base de
connaissance ?
Les appels sont-ils enregistrés ?
Des études de satisfaction sont-elles réalisées auprès des
utilisateurs ?
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC2. Fonction support : audit d'efficacité et de performance
Les certifications (ITIL, ISO, COBIT) sont-elles encouragées au
sein de la DSI, du HD en particulier ?
Interroger le DSI, le responsable HD, des utilisateurs, l'équipe
HD – si possible, participer « à la vie du HD »
Demander la stratégie de formation des utilisateurs et de
l’équipe Help-Desk.
Demander les reportings de suivi
Demander les études de satisfaction
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC2. Fonction support : audit d'efficacité et de performance
Les certifications (ITIL, ISO, COBIT) sont-elles encouragées au
sein de la DSI, du HD en particulier ?
Interroger le DSI, le responsable HD, des utilisateurs, l'équipe
HD – si possible, participer « à la vie du HD »
Demander la stratégie de formation des utilisateurs et de
l’équipe Help-Desk.
Demander les reportings de suivi
Demander les études de satisfaction
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC3. Gestion du parc matériel et logiciel : audit fiabilité et sécurité
Quelle est la procédure de déploiement des mises à jour, d’un
nouveau logiciel ?
Quels sont les outils mis en place pour gérer les versions des logiciels ?
Quels sont les outils mis en place pour gérer le matériel informatique ?
L'installation des PC / portables est-elle faite à partir d'un master
(configuration minimum et standardisée) ?
Existe-t-il un processus spécifique pour le suivi des mises à jour sur les
portables ?
Le déploiement de nouveaux logiciels ou mises à jour est-il possible à
distance ? (utile pour les utilisateurs nomades)
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC3. Gestion du parc matériel et logiciel : audit fiabilité et sécurité
Est-il possible pour le HD de prendre la main à distance ? Si oui,
quelle est la procédure ?
L'inventaire du parc informatique comprend-t-il la localisation
des machines ?
Les logiciels "non officiels" sont-ils répertoriés et suivis ?
Les utilisateurs sont-ils sensibilisés à la sécurité informatique,
notamment à l'installation de logiciel "non officiel" ?
Faire des copies d’écran ou d’extraction des outils de suivi des
mises à jour/déploiement. Vérifier sur les postes utilisateurs les
versions antivirus, firewall, version Windows, version IE
VIII- APPROCHE D’AUDIT DES SI
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC4. Gestion du parc matériel et logiciel : audit d'efficacité et de
performance
Comment est effectué l'inventaire des licences (logiciel, version,
date de mise en production, nombre d'utilisateurs) ?
Outils de type SAM (Software Asset Management) sont-ils
déployés ?
Existe-t-il des revues régulières des licences ?
Existe-t-il une base de données de gestion de configuration de
type CMDB (Configuration Management DataBase)
La DSI est-elle sensibilisée aux enjeux de la maîtrise des licences ?
IX- FACILITATEURS D’AUDITS DES SI
Outils d’analyse de la sécurité
Les outils d’analyse de la sécurité peuvent globalement être répartis en
catégories suivantes :
Outils d’analyse de réseau : Ce sont des logiciels que l’on peut lancer sur un
réseau pour recueillir des informations sur son état.
Les auditeurs SI y font recours pour diverses procédures dont entre autre :
La vérification de l’exactitude des diagrammes de réseau par une cartographie du réseau
d’entreprise
L’identification des dispositifs clés du réseau
La collecte des informations concernant le trafic autorisé sur un réseau
NB : Ia liste des outils les plus utilisés se trouve sur www.insecure.com
IX- FACILITATEURS D’AUDITS DES SI
Outils de piratage
Les outils de piratage offrent une solution automatisée pour vérifier les vulnérabilités des mots de passe
et des identifiant. Ils sont pour les parefeux, les serveurs, les réseaux et les systèmes d’exploitation.
Outils d’analyse de la sécurité des applications
la sécurité des applications doit être conçue et mise au point en parallèle des processus et des
contrôles applicatifs de manière à intégrer un environnement qui inclus tous les processus
management, opérationnel et support)
Ces outil permettent également d’évaluer la séparation des fonctions au sein d’une application
Quelques fournisseurs dans ce domaine sont :
Approva : http://www.approva.net/
LogicalApps : http://www.logicalapps.com/
Q Software : http://www.qsoftware.com/index.htm
Control Solutions International : http://www.csi4sap.com/en/home
IX- FACILITATEURS D’AUDITS DES SI
Outils d’analyse des données
Il permettent de faire des statistiques sur les caractéristiques
des données et d’avoir une vue sur e l’utilisation des données
dans les différents processus
les principaux fournisseurs de ces outils sont :
ACL : http://www.acl.com/Default.aspx?bhcp=1
Idea : http://www.audimation.com/product_feat_ benefits.cfm
Monarch : http://monarch.datawatch.com/
SAS : http://www.sas.com/
IX- FACILITATEURS D’AUDITS DES SI
Logiciel de diagrammes de circulation
Il permet de représenter graphiquement les flux de
transactions pour l’illustration de la circulation des données
à travers les processus
Logiciel de suivi des questions en suspens
Ce type de logiciel permet d’effectuer un suivi des questions restées
en suspens ou des défaillances/anomalie observées mais qui sont en
cours de réparation
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
1- Présentation de la couverture
1. Nom du bureau d’audit y compris le logo
2. Nom de l’organisation auditée y compris le logo
3. Intitulé du document. Exemple: Rapport d’audit du SI de….
4. Nom de l’expert auditeur (celui qui conduit les travaux)
5. La signature de l’expert auditeur
6. Date du document, version le cas échéant
7. Le socle document confidentiel
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
2- Première de couverture
1. Avant propos (clause de confidentialité, de reproduction du
document, l’historique des modifications, le cas échéant )
3-Cadre de la mission
1. Rappeler le cadre de la mission d’audit
2. Indiquer si la présente mission est un audit exhaustif ou audit de suivi
3. Présenter l’objectif de la mission d’audit (Etat de conformité par rapport à un
standard, recommandations, plan d’action)
4. Indiquer, le cas échéant, si la présente mission rentre dans le cadre de la
préparation à la certification ou dans une démarche de conformité
5. Indiquer, la cas échéant, le(s) standard(s) métier de référence par rapport auquel
est réalisée la présente mission d’audit,
6. Indiquer les limites et les contraintes de l’audit
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
4-Termes et définitions
Donner les définitions des termes utilisés dans le présent rapport
5-Références
Indiquer tous les documents de référence utilisés pour la
réalisation de la mission d’audit
6-Présentation de l’organisme audité
1. Présenter brièvement l’organisme audité (création, nombre
d’employés, étendu géographique, missions, services fournis,
parties prenantes, clients, etc)
2. Présenter le champs audité avec les processus y afférents
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
7- Champ d’audit
1. Périmètre géographique (Présenter la liste des département concerné
et à auditer en justifiant leur choix)
2. Description des systèmes d’information
3. Décrire les systèmes d’information des différentes
départements (Composants : serveur, application, base
de données, équipement réseau, solution de sécurité,
d'administration du système d'information)
4. Toute exclusion d'un composant doit être justifiée.
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
7- Champ d’audit
1. Schéma synoptique de l’architecture du réseau(vue
infrastructure)
2. Faire apparaitre les connexions (LAN, WAN, etc), la
segmentation, l’emplacement des composantes du SI, etc…
8- Méthodologie d’audit
1. Décrire en détail la méthodologie d’audit adoptée tout en
établissant la correspondance entre les domaines couverts et les
référentiels d’audit utilisés
2. Présenter les outils (version, licence, fonctionnalité, etc) d’audit
utilisés
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
8- Méthodologie d’audit
3-Présenter l’équipe d’auditeur
4-Présenter l’équipe audité
5-Présenter le planning d’exécution de la mission
d’audit
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
9- Synthèse des résultats de l’audit
1. Rappeler les critères et les standards/référentiels par
rapport auxquels l’audit a été réalisé
2. Rappeler la responsabilité de l’auditeur et les limites de
l’audit (échantillonnage, changements depuis l’audit
3. Rappeler les types et nature de test réalisés pour établir
ces résultats
4. Donner, le cas échéant, une évaluation détaillée de la
réalisation du plan d’action issu de la dernière mission
d’audit
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
9- Synthèse des résultats de l’audit
5-Présenter une synthèse des principales
pratiques identifiées et défaillances
enregistrées lors de l’audit,
6- Présenter une appréciation générale du
domaine audité
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
9- Présentation détaillée des résultats de l’audit
1. Présenter le domaine du référentiel d’audit exploité
2. Présenter la vulnérabilité/le risque
3. Décrire la démarche adoptée d’appréciation des
vulnérabilités/risques
4. Présenter l’appréciation des vulnérabilité/risque
5. Présenter la liste des contrôles/mesures vérifiés considérés
comme critères d’audit
6. Présenter les bonnes pratiques identifiées
7. Donner le conseil/la recommandation
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
10- Plan d’action
1. Organiser par projets les actions/recommandations
associées aux différentes vulnérabilités décelées.
2. Indiquer que le plan d’action est établit en commun
accord avec l’audité
3. Indiquer que le plan d’action prend en considération les
objectifs, les projets en cours et les perspectives de l’audité
4. Faire les estimations sur la base d’un dimensionnement
adéquat des besoins de l’audité (théorie du flocon de
neige), capacités humaines et financières…
11- Liste des annexes
REFERENCES BIBLIOGRAPHIQUES
1. Certification Information Systems Auditor, 27th Edition 2019, ISACA
2. Support de cours de l’audit des systèmes d’information, raphael yende, 2018
3. Management de l’audit des Systèmes d’Information, 2ème édition, Global Technology
Audit Guide, 2013
4. Mesurer la performance du système d’information, David Autissier, 2008
5. Capability Maturity Model Integration (CMMI) – IT Infrastructure Library (ITIL) –
ISO 27001
6. http://www.sei.cmu.edu
7. http://www.itil-officialsite.com
8. http://www.sans.org
9. http://www.opengroup.org