AUDIT DE SECURITE DE SYSTEME D’INFORMATION
116
N° d’ordre : 09/RS/ TCO UN ECOL DEPAR p AUDIT DE D Soutenu le 26 Mars 2011 à 8h Président :M. ANDRIAMIASY Examinateurs : Mme. RAMAFIARISAONA M Mme. RABEHERIMANANA M. RAKOTONDRAINA Tahi Directeur de mémoire : M. RANDRIARIJAONA Luci Année U NIVERSITE D’ANTANANARIVO ---------------------- LE SUPERIEURE POLYTECHNIQU ----------------------- RTEMENT TELECOMMUNICATI MEMOIRE DE FIN D’ETUDES en vue de l’obtention du DIPLOME d’INGENIEUR Spécialité : Télécommunication Option : Réseaux et Systèmes (R.S) par : RANDRIANARISOA Fy Rajo E SECURITE DE SY D’INFORMATION devant la Commission d’Examen composée Y Zidora Malalatiana A Lyliane ina Ezéchiel ien Elino Universitaire : 2009 /2010 UE ION YSTEME e de :
Transcript of AUDIT DE SECURITE DE SYSTEME D’INFORMATION
N° d’ordre : 09/RS/ TCO
UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT TELECOMMUNICATION
par
AUDIT DE SECURITE DE SYSTEME D’INFORMATION
Soutenu le 26 Mars 2011 à 8h
Président :M. ANDRIAMIASY Zidora Examinateurs :
Mme. RAMAFIARISAONA Malalatiana
Mme. RABEHERIMANANA Lyliane
M. RAKOTONDRAINA Tahina Ezéchiel
Directeur de mémoire :
M. RANDRIARIJAONA Lucien
Année Universitaire
UNIVERSITE D’ANTANANARIVO ----------------------
ECOLE SUPERIEURE POLYTECHNIQUE-----------------------
DEPARTEMENT TELECOMMUNICATION
MEMOIRE DE FIN D’ETUDES en vue de l’obtention
du DIPLOME d’INGENIEUR
Spécialité : Télécommunication
Option : Réseaux et Systèmes (R.S)
par : RANDRIANARISOA Fy Rajo
AUDIT DE SECURITE DE SYSTEME D’INFORMATION
à 8h devant la Commission d’Examen composée de
ANDRIAMIASY Zidora
Mme. RAMAFIARISAONA Malalatiana
me. RABEHERIMANANA Lyliane
RAKOTONDRAINA Tahina Ezéchiel
M. RANDRIARIJAONA Lucien Elino
Année Universitaire : 2009 /2010
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT TELECOMMUNICATION
AUDIT DE SECURITE DE SYSTEME
devant la Commission d’Examen composée de :
REMERCIEMENTS
Nous remercions DIEU tout puissant par sa sainte présence de nous avoir donné la santé, le
courage et la passion durant la formation passée à l’Ecole Supérieure Polytechnique
d’Antananarivo, et de nous avoir accordé sa bénédiction pour la réalisation du présent mémoire.
J’adresse toutes mes reconnaissances et mes vifs remerciement à :
- Monsieur ANDRIANARY Philippe Professeur et Directeur de l’Ecole Supérieure
Polytechnique d’Antananarivo.
- Monsieur RAZAKARIVONY Jules, Maître de conférence et Chef Département
Télécommunication au sein de l’Ecole Supérieure Polytechnique d’Antananarivo de nous
avoir accepté et formé dans son département.
- Monsieur ANDRIAMIASY Zidora, Maître de conférences, Enseignant à l’Ecole
Supérieure Polytechnique d’Antananarivo, pour avoir accepté ma soutenance de
mémoire de fin d’étude et qui malgré ses lourdes responsabilités, me fait l’honneur de
présider le jury de ce mémoire.
- Monsieur RANDRIARIJAONA Lucien Elino, Assistant, Enseignant à l’Ecole
Supérieure Polytechnique d’Antananarivo, Directeur de ce mémoire de fin d’étude pour
le temps qu’il m’a accordé, pour son aide et ses conseils inestimables durant la
préparation de ce travail.
- Tous les membres du jury, également enseignant au sein de l’Ecole Supérieure
Polytechnique d’ Antananarivo, qui ont bien voulu examiner et juger ce travail :
o Madame RAMAFIARISAONA Malalatiana
o Madame RABEHERIMANANA Lyliane
o Monsieur RAKOTONDRAINA Tahina Ezéchiel
Mes vifs remerciements s’adressent également à tous les enseignants au sein du Département
télécommunication ainsi que les enseignants et le personnel de l’Ecole Supérieure
Polytechnique d’Antananarivo qui ont assuré notre formation durant ces cinq années
d’études.
Je n’oublierai pas ma famille pour leur soutien bienveillant et leurs encouragements, pour la
réalisation de ce mémoire, comme en toute circonstance.
Et à tous ceux qui ont contribué de près ou de loin à l’élaboration de ce mémoire.
TABLE DES MATIERES
REMERCIEMENTS ...................................................................................................................................... i
TABLE DES MATIERES ............................................................................................................................ ii
NOTATIONS ................................................................................................................................................ vi
ABREVIATIONS ........................................................................................................................................ vii
INTRODUCTION ......................................................................................................................................... 1
CHAPITRE 1 LES DIFFERENTES NORMES D’AUDIT ......... .............................................................. 2
1.1 Introduction ............................................................................................................................................. 2
1.2 Généralités sur l’audit............................................................................................................................. 2
1.2.1 Définition ...................................................................................................................................... 2
1.2.2 Enjeux ........................................................................................................................................... 2
1.2.3 Typologie d’audit .......................................................................................................................... 3
1.3 L’audit des systèmes d’information ....................................................................................................... 3
1.3.1 Le Système d’information ............................................................................................................. 3
1.3.2 Origine........................................................................................................................................... 4
1.3.3 Objectifs ......................................................................................................................................... 5
1.4 L’audit de sécurité des systèmes d’information ................................................................................... 5
1.4.1 Nécessite d’un audit de sécurité ................................................................................................... 6
1.4.2 Différence entre audit et analyse de risque .................................................................................. 6
1.4.3 Pratique de l’audit ........................................................................................................................ 6
1.4.4 Les normes et les référentiels ....................................................................................................... 9
1.4.5 L’analyse des risques .................................................................................................................. 14
1.4.6 Les principales normes d’audits de sécurité .............................................................................. 15
1.5 Conclusion .............................................................................................................................................. 18
CHAPITRE 2 IT GOUVERNANCE ......................................................................................................... 19
2.1 Introduction ........................................................................................................................................... 19
2.2 Définitions .............................................................................................................................................. 19
2.2.1 Origine étymologique .................................................................................................................. 19
2.2.2 Gouvernance d’entreprise .......................................................................................................... 19
2.2.3 Gouvernance des technologies de l’information ....................................................................... 19
2.3 De la gouvernance d’entreprise à l’IT gouvernance .......................................................................... 20
2.3.1 Paul Sarbanes et Michael G. Oxley ........................................................................................... 20
2.3.2 Les mesures prises par la loi Sarbanes Oxley ............................................................................ 20
2.3.3 Dispositif de corporate gouvernance et son impact sur les ressource IT .................................. 21
2.3.4 Les sections SOX qui concernent les ressources IT .................................................................. 21
2.3.5 Domaines stratégique de l’IT gouvernance ............................................................................... 22
2.4 L’alignement IT ..................................................................................................................................... 23
2.4.1 L’alignement stratégique ............................................................................................................ 24
2.4.2 Alignement sur le business process ............................................................................................ 25
2.5 Les ressources IT ................................................................................................................................... 27
2.5.1 Les niveaux stratégiques de l’TRM ............................................................................................ 27
2.5.2 Management stratégique des ressources IT .............................................................................. 28
2.5.3 Management Proactif des ressources IT ................................................................................... 30
2.6 Les risques IT ........................................................................................................................................ 30
2.6.1 L’identification du risque ........................................................................................................... 30
2.6.2 la gestion du niveau de risque .................................................................................................... 33
2.6.3 Réduire le risque ......................................................................................................................... 34
2.7 La valeur IT ........................................................................................................................................... 36
2.7.1 Les indicateurs T(X)O ................................................................................................................ 36
2.8 Mesure de la performance .................................................................................................................... 38
2.9 Conclusion .............................................................................................................................................. 38
CHAPITRE 3 PRESENTATION DE LA SECURITE DES SYSTEMES D’INFORMATION .......... 39
3.1 Introduction ........................................................................................................................................... 39
3.2 La sécurité des systèmes d’information ............................................................................................... 39
3.2.1 Définition .................................................................................................................................... 39
3.2.2 Différentes approches de la sécurité .......................................................................................... 39
3.2.3 Les différents problèmes de la sécurité ...................................................................................... 39
3.3 La protection physique ......................................................................................................................... 41
3.3.1 Les verrous .................................................................................................................................. 41
3.3.2 Les gardiens de sécurité .............................................................................................................. 43
3.3.3 Les caméras de surveillances ..................................................................................................... 43
3.3.4 Les alarmes et contrôles de détection d’urgences ...................................................................... 44
3.3.5 Chauffage, ventilation, et système de refroidissement .............................................................. 45
3.3.6 Assurance .................................................................................................................................... 45
3.3.7 Sauvegardes périodiques ............................................................................................................ 46
3.3.8 Systèmes d’alimentation ............................................................................................................. 47
3.3.9 Programme de reprise des activités : BRP (Business Resumption Programs) ......................... 47
3.3.10 Administrateur de système de sécurité de remplacement (secours) ........................................ 48
3.4 La protection logique ............................................................................................................................ 48
3.4.1 Conception de la sécurité logique ............................................................................................. 48
3.4.2 Naissance d’un nouveau système ............................................................................................... 49
3.4.3 ID et mots de passes .................................................................................................................... 49
3.4.4 Administration du système de sécurité ....................................................................................... 51
3.4.5 Fraude en ligne ........................................................................................................................... 51
3.4.6 La protection du réseau .............................................................................................................. 52
3.4.7 Protection de données ................................................................................................................. 59
3.5 Conclusion .............................................................................................................................................. 64
CHAPITRE 4 . CobiT (Control objectives for informat ion and Technologies) .................................... 65
4.1 Introduction ........................................................................................................................................... 65
4.2 Présentation générale ............................................................................................................................ 65
4.2.1 Définitions ................................................................................................................................... 65
4.2.2 Historique .................................................................................................................................... 66
4.3 CobiT et l’IT gouvernance .................................................................................................................... 67
4.3.1 L’apport de CobiT ....................................................................................................................... 67
4.3.2 Les cinq axes stratégiques de CobiT .......................................................................................... 68
4.4 Appréhender CobiT .............................................................................................................................. 68
4.4.1 Focalisation sur le métier ........................................................................................................... 69
4.4.2 Orienté processus ........................................................................................................................ 71
4.4.3 Basé sur les contrôles ................................................................................................................. 76
4.5 Le cube CobiT ........................................................................................................................................ 77
4.6 CobiT et l’audit de système d’information ......................................................................................... 77
4.6.1 Le code professionnel d’éthique ................................................................................................. 77
4.6.2 La mission d’audit ...................................................................................................................... 78
4.6.3 L’apport de CobiT ....................................................................................................................... 79
4.6.4 Le contrôle interne ...................................................................................................................... 79
4.7 Les limites de CobiT .............................................................................................................................. 80
4.8 Les documents et les publications autour de CobiT ........................................................................... 80
4.9 Conclusion .............................................................................................................................................. 81
CHAPITRE 5 REALISATION .................................................................................................................. 82
5.1 Introduction ........................................................................................................................................... 82
5.2 Analyse et conception ............................................................................................................................ 82
5.3 Fonctionnement ..................................................................................................................................... 84
5.3.1 Fenêtre principale ....................................................................................................................... 84
5.3.2 Le paramétrage ........................................................................................................................... 85
5.3.3 L’audit ......................................................................................................................................... 88
5.3.4 La consultation ........................................................................................................................... 90
5.4 Conclusion .............................................................................................................................................. 93
CONCLUSION ............................................................................................................................................ 94
ANNEXES .................................................................................................................................................... 95
ANNEXE 1 CODE JAVA ........................................................................................................................... 95
ANNEXE 2 EXEMPLES DE QUESTIONNAIRES D’AUDIT ....... ....................................................... 99
BIBLIOGRAPHIE .................................................................................................................................... 102
RESUME .................................................................................................................................................... 105
NOTATIONS
1. Minuscules latines
n Produit de nombre premiers
2. Majuscules latines
Crypte Message code
Clair Message à coder
Clé C Clé de chiffrement
Clé D Clé de déchiffrement
ABREVIATIONS
ACL Access Control List
AFAI Association Française de l’Audit et du conseil Informatiques
AIS Assocation for Information System
ANSI American National Standards Institute
ANSSI Agence Nationale de Sécurité des Systèmes d’Information
ASIS American Society for Industrial Security
ASL Application Services Library
BSC Balanced Scorecard
CCRA Common Criteria Recognition Arrangement
CE Certificate Authority
CLUSIF Club de la sécurité des Systèmes d’information Français
CLUSIF Club de la sécurité des Systèmes d’information Français
CMMI Capability Maturity Model Integration
COBIT Control Objectives for Information and Technologies
CORBA Common Object Request Broker Architecture
COSO The Committee of Sponsoring Organizations of the Trendway Commission
CPU Central Processing Unit
CRL Certificate Revocation List
DCSSI Direction Centrale des Systèmes d’Information
DES Data Encryption Standard
DMZ DeMilitarized Zone
DSI Directeur des sytèmes d’Information
EA Entreprise Architecture
EIBOS Expression du besoin et Identification des objectifs de sécurités
EJB Entreprise Java Beans
ERP Entreprise Ressource Planning
eTOM enhanced Telecom Operation Map
FBI Federal Bureau of Investigation
FEROS Fiche d’Expression Rationnelle des Objectifs de Sécurité
HIC Hardware Infrastructure Component
HIC Hardware Infrastructure Component
IIA The Institute of Internal auditors
IPSec Internet Protocol Security
ISACA Information Systems Audit and Control Association
ISMS Information Security Management System
ISO International Standard Organization
ISPL Information Services Procurement Library
IT Information Technologies (technologie de l’information)
ITGI IT Governance Institute
ITIL Information Technology Infrastructure Library
ITRM IT Ressource Management
Java RMI Java Remote Method Invocation
L2F Layer 2 Forwarding
L2TP Layer 2 Tunneling Protocol
LSF Loi de Sécurité Financière
MAC Medium Access Control
MARION Méthodologie d’Analyse de Risques Orientée par Niveau
MEHARI Méthode Harmonisée d’Analyse de Risque
MOF Microsoft Process management
MPPC Microsoft Point-to-Point enCryption
MTBF Mean Time Between Failure
NAPT Network Address and Port Translation
NAT Network Address Translation
OMG Object Management Group
OPM3 Organisational Project Management Maturity Model
PAT Port Address Translation
PDA Personal Digital Assistant
PDCA Plan Do Check-Act
PKI Public-Key Infrastructure
PMCDF Project Manager Competency Development Framework
PPTP Point-to-Pont Tunneling Protocol
PSSI Politique de sécurité du Système d’Information
RATS Rough Auditing Tool for Security
RSA Rivest, Shamiret Aldeman
RSSI Responsable de la Sécurité des Systèmes d’Information
SEI Software Engineering Institute
SGSN Secrétariat Général de la défense Nationale
SI Système d’Information
SIC Software Infrastructure Component
SIF système d’Information Financier
SoA Statement of Applicability
SSI Sécurité des Systèmes d’Information
SSL Secure Sokets Layer
TBO Total Benefit of Ownership
TCO Total Cost of Ownership
TRO Total Risk of Ownership
TVO Total Value of Ownership
UPS Uninterruptible Power Supply
VLAN Virtual Local Area Network
VPN Virtual Private Network
1
INTRODUCTION
Le développement de l’informatique au cours de ces dernières années est tout simplement
spectaculaire. Le besoin d’automatisation de l’information a atteint un tel degré d’efficacité
qu’aucune organisation quelle qu’elle soit ne peut plus se passer des services apportés par ce
dernier.
Pour beaucoup d’entreprises l’information et la technologie qui la soutiennent sont leur bien le
plus précieux mais aussi le moins bien compris. Les entreprises qui « réussissent » reconnaissent
les avantages qu’apporte la technologie de l’information et l’utilisent pour générer de la valeur à
leurs parties prenantes.
Ces entreprises comprennent les avantages simples tels que la compréhension et la gestion des
risques associés, la conformité réglementaire et la dépendance critique de nombreux processus de
l’entreprises sur les technologies le l’information.
D’où la nécessité d’un contrôle à la fois exhaustif et impartial de tous les processus afin de les
rendre conforme aux normes ou standards internationales : ce processus s’appelle « l’audit de
système d’information ». Dans le cas du présent mémoire on se concentrera sur « l’audit de
sécurité des systèmes d’informations ».
Pour réussir correctement sa mission l’auditeur devra se référer à des normes, celles-ci lui
serviront de référence. Ces différentes normes, référentiels et méthodes sont développées dans le
premier chapitre de ce présent mémoire avec les quelques divergences entre approche américaine
et française.
Le second chapitre traitera en détails la notion de Gouvernance de système d’information, des
principaux points à considérer pour pouvoir assuré une bonne gouvernance et les conséquences de
l’application de la loi Sabanes-oxley sur les entreprises américaines.
Le troisième chapitre discutera en détails de la notion de sécurité des systèmes d’informations,
notamment la protection physique et logique ainsi que les politiques de sécurité indispensables,
suivi d’une brève introduction sur la cryptographie.
Quant au chapitre quatre il discutera essentiellement du référentiel CobiT, guide indispensable et
incontournable lorsqu’on parle d’audit et de bonne gouvernance.
Enfin le dernier chapitre « réalisation » introduira et expliquera en détails le fonctionnement de
«ISAudit» logiciel d’audit de sécurité de système d’information.
2
CHAPITRE 1
LES DIFFERENTES NORMES D’AUDIT
1.1 Introduction
Avant d’entrer dans les détails des processus d’audit et de la notion de gouvernance d’entreprise il
est important, en premier lieu de bien cerner le problème. Ainsi ce premier chapitre s’étalera sur la
définition des termes mis en jeu : l’audit, l’audit de sécurité, la notion de système d’information.
Il portera également sur les différents objectifs et les types d’audit possibles. Enfin ce chapitre
présentera les différentes normes sur la sécurité des systèmes d’information françaises et
américaines ainsi que les référentiels utilisés par les auditeurs pour accomplir leurs « missions ».
1.2 Généralités sur l’audit
1.2.1 Définition
Le mot audit vient du verbe Latin « audire » qui veut dire « écouter ». Les Romains employaient
ce terme pour designer un contrôle au nom de l’empereur sur la gestion des provinces. Dans la
définition moderne, l’audit est un mot anglais décrivant une activité visant à exécuter un examen
approfondi des domaines d’activité d’une entreprise en vue de les rendre conforme à une norme.
C’est une activité de contrôle qui consiste en une expertise par un agent compétant et impartial et
qui porte un jugement sur l’organisation, la procédure ou une opération quelconque de l’entité à
auditer.
L’audit est surtout un outil d’amélioration car il permet de faire le point sur l’existant (état des
lieux) afin d’en dégager les points faibles ou non conforme (suivant lés référentiel d’audits). Cela
afin de mener par la suite les actions adéquates qui permettront de corriger les écarts et
dysfonctionnements constatés. [1][2]
1.2.2 Enjeux
L'audit est un processus systématique, indépendant et documenté permettant de recueillir des
informations objectives pour déterminer dans quelle mesure les éléments du système cible
satisfont aux exigences des référentiels du domaine concerné.
3
Il s'attache notamment à détecter les anomalies et les risques dans les organismes et les secteurs
d'activité qu'il examine. Auditer une entreprise, un service, c’est écouter les différents acteurs pour
comprendre et faire comprendre le système en place ou à mettre en place. [3]
1.2.3 Typologie d’audit
Dans le cadre d’audit d’entreprise on distingue :
1.2.3.1 L’audit interne
Il est aussi appelé « audit de première partie », c’est un audit réalisé par, ou au nom de l’entreprise
elle-même pour des raisons internes et ils peuvent constituer une base d’auto-déclaration de
conformité. L’audit interne ne fait appel à aucun cabinet ou organisation extérieure lors de
l’exécution du contrôle, il est commandité par les chefs d’entreprises, les différents chefs de
département pour avoir une vision plus transparente du déroulement des activités du secteur
concerné. Cela leur permettra de détecter certaines anomalies et aussi de permettre une
amélioration du secteur en termes de qualité et de fiabilité. [2]
1.2.3.2 L’audit externe
Il est également appelé « audit de seconde ou de tierce partie », ces audits sont réalisés par des
parties, telles que les clients, ayant un intérêt dans l’organisme, ou pour d’autres personne en leur
nom. Les audits de tierce partie sont réalisés par des organismes généralement accrédités qui
fournissent l’enregistrement ou la certification de conformité à des exigences comme celle de
l’ISO 9001 ou 14001 ou nf iso/CEI 27001 relatives aux systèmes de management de la sécurité de
l’information.
1.3 L’audit des systèmes d’information
1.3.1 Le Système d’information
1.3.1.1 Définition
On a l’habitude de désigner par « système d’information » l’ensemble des moyens techniques et
humains qui permet de stocker, de traiter ou de transmettre l’information. Mais pour limiter le
périmètre de notre étude, On dira qu’un système d’information est « tout moyen dont le
4
fonctionnement fait appel d’une façon ou d’une autre à l’électricité et qui est destiné à élaborer,
traiter, stocker, acheminer, présenter ou détruire l’information ». [4][5]
1.3.1.2 Rôle et importance du système d’information au sein de l’entreprise
Le système d’information est le véhicule de la communication dans l’organisation. Il coordonne
grâce à l’information les activités de l’organisation et lui permet ainsi d’atteindre ses objectifs.
Autrement dit si l’entreprise était le corps humain, le système d’information aurait vocation à en
être le système nerveux faisant ainsi acheminer diverses informations recueillies à différents
niveaux à toutes les composantes de l’entreprise.
Les systèmes d’information peuvent jouer un rôle capital dans le succès d’une entreprise.
En effet, les dirigeants d’entreprise sont souvent confrontés à un certain nombre de choix décisifs
(allocations de ressources, choix d’un modèle économique), qui engagent l’entreprise dans le long
terme, afin de dégager un profit durable. Ces choix ne pouvant qu’être faits à partir des données
dont disposent les dirigeants de l’entreprise. D’où l’information possède désormais une valeur
d’autant plus grande qu’elle contribue à l’atteinte des objectifs de l’organisation. Les SI à juste
titre, fournissent l’information dont l’entreprise a besoin pour une exploitation efficiente, une
gestion efficace, et pour l’obtention ou le maintient de son avantage sur les concurrents. [6]
Ainsi bien maîtriser un SI devra :
• Fournir à l’entreprise l’information dont elle a besoin pur une exploitation efficiente, une
gestion efficace, et pour obtenir ou maintenir son avantage sur les concurrents.
• Offrir à l’entreprise les outils pour réaliser ses objectifs stratégiques.
Cependant en cas de mauvaise gestion du système d’information, si le SI n’appuie pas
correctement les objectifs stratégiques ils pourront mettre en jeu le succès voir même la survie de
l’entreprise.
Par conséquent une gestion saine et des contrôles réguliers (audits) des SI sont des éléments
incontournables dans le « succès » de l’entreprise.
1.3.2 Origine
Le Concept d’audit des systèmes d’information est apparu au cours des années 1970 et a pour but
d’évaluer la mise en conformité des processus et méthodes de l’entreprise avec un ensemble de
règles en vigueur (fiscales, juridiques, technologiques…).
5
Cependant l’apparition de la loi financière dès le début des années 1990, ainsi que des nouvelles
exigences réglementaires de types Sarbanes-Oxley, ont eu pour effet de généraliser et de
systématiser la pratique de ces audits.
1.3.3 Objectifs
L’objectif fondamentale de l’audit informatique est toujours le même : vérifier la fiabilité de
l’outil informatique et de son emploi. L’audit permettra de :
• Déterminer la conformité des éléments du système aux exigences spécifiées.
• Permettre à l’entreprise auditée d’améliorer son système et son efficacité.
• Assurer une meilleure sécurité à la fois des informations et des employés utilisateurs.
• Alerter les différents dirigeants sur différente risques que peut encourir l’organisation sur
le point de vue technologie de l’information.
• Obtenir des certifications qui indiqueront aux clients et investisseurs un gage de fiabilité de
sécurité et de maturité de l’entreprise. [7]
1.4 L’audit de sécurité des systèmes d’information
L'audit de sécurité d'un système d'information (SI) est une vue à un instant T de tout ou une partie
du SI, permettant de comparer l'état du SI à un référentiel.
L'audit répertorie les points forts, et surtout les points faibles (vulnérabilités) de tout ou une partie
du système. L'auditeur dresse également une série de recommandations pour supprimer les
vulnérabilités découvertes. L'audit est généralement réalisé conjointement avec une analyse de
risque, et par rapport au référentiel. [8][9]
Le référentiel est généralement constitué par :
• La politique de sécurité du système d'information (PSSI)
• la base documentaire du SI.
• Les réglementations propres à l'entreprise.
• Les textes de loi.
• Les documents de référence dans le domaine de la sécurité informatique
6
1.4.1 Nécessite d’un audit de sécurité
L’audit peut être effectué pour plusieurs buts :
• Réagir à une attaque.
• Se faire une bonne idée du niveau de sécurité du SI.
• Tester la mise en place effective de la PSSI.
• Tester un nouvel équipement.
• Evaluer l’évolution de la sécurité.
Dans tous les cas, il a pour but de « vérifier la sécurité ». Dans le cycle de sécurisation, la
vérification intervient après la réalisation d'une action. Par exemple, lors de la mise en place d'un
nouveau composant dans le SI, il est bon de tester sa sécurité après avoir intégré le composant
dans un environnement de test, et avant sa mise en œuvre effective. La roue de Deming illustre ce
principe.
Le résultat est le rapport d'audit. Celui-ci contient la liste exhaustive des vulnérabilités recensées
par l'auditeur sur le système analysé. Il contient également une liste de recommandations
permettant de supprimer les vulnérabilités trouvées.[10]
1.4.2 Différence entre audit et analyse de risque
L'audit ne doit pas être confondu avec l'analyse de risques. Il ne permet que de trouver les
vulnérabilités, et non de déterminer si celles-ci sont tolérables. Au contraire, l'analyse de risque
permet de dire quel risque sont pris en compte, ou acceptés pour le SI. L'auditeur (le prestataire)
dresse donc des recommandations, que l'audité (le client) suivra, ou ne suivra pas. Le client
déterminera si il suivra les recommandations ou non, en se référant à la politique de sécurité.
1.4.3 Pratique de l’audit
Pour arriver à dresser une liste la plus exhaustive possible des vulnérabilités d'un système,
différentes pratiques existent et sont traditionnellement mises en œuvre.
1.4.3.1 Les interviews
Les interviews sont généralement essentielles à tout audit. Dans le cas où l'organisation du SI est
analysée, ils sont même indispensables. Toutes les personnes ayant un rôle à jouer dans la sécurité
du SI sont à interroger :
7
• Le directeur des systèmes d'information (DSI).
• Le responsable de la sécurité des systèmes d’information (RSSI).
• Les administrateurs.
• Les utilisateurs du système d'information, qu'ils ont un rôle dans la production de
l'entreprise, dans la gestion, ou la simple utilisation des moyens informatiques.
• Tout autre rôle ayant un lien avec la sécurité.
Il est important de formuler les questions avec tact. En effet, interroger des personnes à propos de
leur travail peut faire qu'elles se sentent jugées et les résultats peuvent être faussés. La diplomatie
est donc une compétence essentielle pour la pratique des audits.
1.4.3.2 Les tests d’intrusion
Les tests d'intrusion sont une pratique d'audit technique. On peut diviser les tests d'intrusion en
trois catégories principales : les tests boîte blanche, les tests boîte grise et les tests dits boîte noire.
• Un test boîte noire signifie que la personne effectuant le test se situe dans des conditions
réelles d'une intrusion : le test est effectué de l'extérieur, et l'auditeur dispose d'un
minimum d'informations sur le système d'information. Ce genre de tests débute donc par
l'identification de la cible :
o Collecte d'informations publiques : pages web, informations sur les employés,
entreprise ayant un lien de confiance avec la cible.
o Identification des points de présence sur internet.
o Ecoute du réseau.
• Lors de la réalisation de tests boîte grise, l'auditeur dispose de quelques informations
concernant le système audité. En général, on lui fournit un compte utilisateur. Ceci lui
permet de se placer dans la peau d'un "utilisateur normal".
• Les tests boîte blanche débutent avec toutes ces informations (et beaucoup plus) à
disposition. Ensuite commence la recherche des vulnérabilités, à l'aide de différents tests
techniques, comme par exemple la recherche des ports ouverts, la version des
applications... Différents produits existent pour effectuer ces tests, et certains prévoient
d'automatiser toute une batterie de tests (Nessus, LANguard...).
8
La dernière phase est l'exploitation des vulnérabilités. Des effets indésirables pouvant survenir
(déni de service par exemple), le côté pratique de cette phase n'est pas systématique. Elle consiste
à déterminer les moyens à mettre en œuvre pour compromettre le système à l'aide des
vulnérabilités découvertes. Selon les moyens à mettre en œuvre, le client pourra décider que le
risque associé à la vulnérabilité décelée est négligeable (probabilité d'exploitation faible) ou au
contraire à prendre en compte. Pour prouver la faisabilité de l'exploitation, les auditeurs créent des
programmes qui exploitent la vulnérabilité, appelés exploits.
1.4.3.3 Les relevés de configuration
Il s'agit ici d'analyser profondément les composants du système d'information. Les configurations
sont inspectées dans les moindres détails. Suite à cette observation, la liste des vulnérabilités est
dégagée en comparant le relevé à des configurations réputées sécurisées et à des ensembles de
failles connues.
Tout peut être inspecté, allant de l'architecture du SI aux applications, en passant par les hôtes
(clients et serveurs). Par exemple sur un serveur, on va analyser :
• Le chargeur de démarrage.
• Les mécanismes d'authentification (robustesse des mots de passe, utilisation
d'authentification forte...).
• Le système de fichiers (droits d'accès, utilisation de chiffrement...).
• les services.
• la journalisation.
• la configuration réseau.
• Etc.
1.4.3.4 L’audit de code
Il existe des bases de vulnérabilités très fiables pour les applications répandues. Néanmoins, pour
des applications moins utilisées, ou codées par l'entreprise elle-même, il peut être nécessaire
d'analyser leur sécurité. Si les sources de l'application sont disponibles, il faut lire et comprendre
le code source, pour déceler les problèmes qui peuvent exister. Notamment, les débordements de
tampon (buffer overflow), les bugs de format, ou pour une application web, les vulnérabilités
menant à des injections SQL...
9
L'audit de code est une pratique très fastidieuse et longue. De plus, elle ne permet généralement
pas, en raison de sa complexité, de dresser une liste exhaustive des vulnérabilités du code. Des
méthodes automatiques existent, et permettent de « dégrossir » le travail, avec des outils comme
RATS (Rough Auditing Tool for Security). Mais se reposer uniquement sur ce genre de méthodes
peut nous faire passer à côté de problèmes flagrants pour un humain.
1.4.3.5 Le fuzzing
Pour les applications boite noire, où le code n'est pas disponible, il existe un pendant à l'analyse de
code, qui est le « fuzzing ». Cette technique consiste à analyser le comportement d'une application
en injectant en entrée des données plus ou moins aléatoires, avec des valeurs limites.
Contrairement à l'audit de code qui est une analyse structurelle, le « fuzzing » est une analyse
comportementale d'une application.
1.4.4 Les normes et les référentiels
1.4.4.1 Les principaux référentiels
Quelque soit le domaine d’application, l’audit est intimement associé à la notion de meilleur
pratiques sur le plan éthique, managérial, financier mais aussi environnemental. L’audit des
systèmes d’information n’échappe pas à cette règle. Ce principe de bonne pratique (Best
practicies) est essentiellement basé sur l’enseignement des autres qui permet ainsi de capitaliser
des connaissances vis-à-vis de processus, de méthode et de technologie. [8] [11]
De nombreux travaux en Europe et en Amérique du Nord (sociétés, associations, universités,
instituts) ont élaboré des référentiels (ou cadre) dédiés au monde des technologies de l’information
en se fondant sur le principe des meilleurs pratiques.
• CobiT (Control Objectives for Information and related Technology) de l’ISACA
(Information systems Audit and Control Association) est le référentiel de base des
systèmes d’information et est la référence Américaine en termes d’audit des systèmes
d’information.
• L’ANSSI (Agence Nationale de Sécurité des Systèmes d’Information) est la référence
française en matière de SSI (sécurité des Système d’Information).
10
Le tableau 1.01 suivant montre une légère divergence entre les standards américains avec celles
des normes Françaises :
American
Français
Sarbanes-oxley (SOX) : loi portant sur la réforme de la comptabilité des sociétés cotées et la protection des investisseurs est une nouvelle loi fédérale imposant de nouvelles règles sur la comptabilité et la transparence financière.
LSF (Loi de sécurité financière) : a été adopté par le parlement français afin de renforcer les dispositions légales en matière de gouvernance d’entreprise
ISACA (Information System Audit an Control Association) : d’origine américaine est une association internationale dont l'objectif est d'améliorer les processus et la méthodologie des audits informatiques et des systèmes d'information.
AFAI (Association Française de l’Audit et du conseil Informatiques) : est le chapitre Français de l’ISACA.
IIA (the Institute of Internal auditors) : est un institut dédié à l’établissement de standards professionnels d’audit interne.
IFACI (Institut Français des auditeurs et contrôleurs internes) : est le chapitre Français de l’IIA.
ISSA (Information Systems Security Association) : d’origine américaine est une association internationale à but non lucratif formée par des professionnels des sécurités de SI et qui fournis des sites éducatifs et des publications pour les membres.
CLUSIF (Club de la Sécurité de l’information Français): est une association française d'entreprises et de collectivités réunis en groupes de réflexion et d'échanges autour de différents domaines de la sécurité de l'information : gestion des risques, politiques de sécurité, cybercriminalité, intelligence économique, etc.
Tableau 1.01: Différence entre les normes Françaises et Américaines
a. Comment choisir le référentiel
Pour un auditeur donné, un seul référentiel ou plusieurs référentiels peuvent être utilisés :
Selon le type d’audit, les référentiels sont de natures diverses. Le tableau 1.02 dans la page
suivante indique le référentiel à utiliser pour chaque type d’audit que l’auditeur pourra devra
réaliser lors de sa mission.
11
Types d’audit
Referentiel utilisé
Audit de système
normes, recueil de bonnes pratiques
Audit de processus
fiches process, fiches methodes
Audit de produit/service
spécification technique
Audit de procédure
Procédure, mode opératoire
Tableau 1.02: Référentiel utilisé selon le type d’audit
Etant donné que l’IT gouvernance est intimement lié è l’audit des Systèmes informatiques nous
dresseront une liste des référentiels d’audit et d’IT gouvernance. [12]
b. Référentiels d’audit et de gouvernance des SI
• ASL (Application Services Library)
Développée par l’ASL foundation elle est d’origine Hollandaise, c’est une méthodologie de
management des applicatifs. ASL est un cadre de référence destiné à la gestion des applications
mises en œuvre dans une organisation. Il ne s’agit pas d’un modèle de management de projet, mais
d’un cadre de gestion au niveau des ressources applicatives qu’elles soient existantes ou en projet.
Le modèle est développé pour que les services informatiques garantissent un soutien optimal dans
le fonctionnement de l’entreprise.
ASL se positionne entre ITIL (Information Technology Infrastructure Library), orienté vers le
management des infrastructures et BiSL (Business Information Service Library) orienté vers le
management des systèmes d’information métier. ASL est généralement applicable par les DSI,
indépendamment de la taille de l’organisation.
• CMMI (Capability Maturity Model Integration)
D’origine américaine et développé par l’SEI (Software Engineering Institue), c’est une
méthodologie de management des niveaux de maturité. Le modèle de maturité de capacité intégrée
permet aux entreprises d’optimiser l’efficacité et la qualité des processus mis en œuvre dans une
12
organisation vis-à-vis des ressources IT. L’évaluation de la maturité se fait à partir de l’échelle
comprise entre 1 à 5.
La mise en œuvre de CMMI dans une organisation peut se faire à partir d’une approche étagée ou
continue (Staged or Continuous). L’approche continue permet d’intégrer les niveaux de capacités.
Elle est généralement plus rapide que l’approche Staged. Cependant Staged permet à
l’organisation de se comparer à d’autres.
• CobiT (Control Objectives for Information and Technology)
D’origine américaine et développé par l’ISACA (Information Systems Audit and Control
Association. COBIT est un ensemble de recommandations et de processus permettant d’évaluer
les ressources informatiques. Il s’inscrit dans une logique de contrôle et d’audit.
COBIT est un outil largement utilisé dans la démarche d’IT Gouvernance. Il permet de mettre en
place des contrôles internes au niveau des ressources IT et de réaliser des audits. L’adoption du
COBIT ouvre la voie à la conformité dans le cadre des lois de sécurité financière comme
Sarbanes-Oxley (SOX).
• COSO (The Committee of Sponsoring Organizations of the Trendway Commission)
D’origine américaine et développé par « The Committee of Sponsoring Organizations of the
Trendway Commission », c’est une méthodologie de gestion des risques.
COSO offre un cadre pour la gestion des risques auxquelles une entreprise est naturellement
confrontée. Il renforce la capacité de l’organisation à trouver un équilibre entre les objectifs de
croissance et de rendement et les risques associés.
• eTOM (enhanced Tlecom Operation Map)
D’origine américaine, c’est une méthodologie de modélisation des processus.
Modèle initialement dédié à la modélisation des processus dans le secteur des Telecoms, eTOM
fournit désormais un cadre pour l’ensemble des processus d’une organisation (gestion de produit,
stratégie, RH…)
eTOM Business Process Framework est un référentiel pouvant être utilisé dans le cadre d’une
politique d’urbanisation, notamment au niveau de la cartographie des architectures métiers,
fonctionnelle, applicative et technique.
13
• ISPL (Information Services Procurement Library)
D’origine européenne, c’est une méthodologie de management concernant l’acquisition des
ressources IT.
ISPL propose un ensemble de processus permettant un management efficient de la sous-traitance
et de l’acquisition des services IT (externalisation, infogérance). Il détermine les articulations clés
de la fourniture de services sur le plan du choix, de l’acquisition, de l’évaluation des risques et de
la supervision.
ISPL se positionne entre la gestion de projet et la gestion de service. Il est généralement associé à
la démarche ITIL au niveau du management de services car il offre un cadre de gestion et de
supervision très complet vis-à-vis des tiers responsables de la délivrance de services IT.
• ITIL (Information Technology Infrastructure Library)
D’origine anglaise, c’est une méthodologie de Management des services IT.
ITIL définit une méthode pour le management des services IT. Elle est constituée d’un ensemble
de directives, basées sur les meilleures pratiques.
ITIL doit être mis en œuvre dans le cadre d’une approche globale et pragmatique du management
des infrastructures IT. Les organisations l’utilisent essentiellement au niveau de la délivrance des
services IT et de leurs supports.
• OPM3 (Organisational Project Management Maturity Model)
D’origine américaine, c’est une méthodologie de gestion de projet organisationnel.
OPM3 offre des processus de planification et de gestion stratégique au niveau des portefeuilles de
projets. Il permet d’aligner les projets sur les orientations stratégiques de l’organisation en se
basant sur le modèle de maturité.
PMBOK offre quant à lui un ensemble de processus dédié au management de projet. PMBOK est
reconnu et approuvé par l’institut des normes nationales américaines (American National
Standards Institute, ANSI).
Il est recommandé de mettre en œuvre OPM3 avec PMBOK pour le mangement opérationnel des
projets et PMCDF (Project Manager Competency Development Framework) pour le management
des équipes. C’est un outil clé dans la pratique de l’IT Gouvernance. [11][12]
14
1.4.5 L’analyse des risques
Sans l’analyse des risques, l’utilité d’un audit est limitée. Les méthodes sont essentielles pour
assurer une efficacité aux plans d’action découlant de la politique de sécurité de l’entreprise. La
plupart des entreprises de moyenne et de grande taille déploient, à leur manière, une politique de
sécurité. Qu’elle soit minimaliste ou omniprésente, cette dernière doit être périodiquement auditée,
pour plus de performance et d’efficacité. Pour procéder à ces contrôles réguliers un certain nombre
de méthodes existent, parfois similaires, parfois opposées : [21] [28]
1.4.5.1 MARION (Méthodologie d’Analyse de Risques Orientée par Niveau)
Elaboré par CLUSIF (Club de la sécurité des Systèmes d’information Français). La plus ancienne
des ces méthodes, elle a surtout été appliquée dans les années 1980 et 1990.
L’entreprise auditée se soumet à un certains nombre de questionnaires débouchant sur différents
notes de 0 à 4 (en tout,27 indicateurs répartis en 6 catégories)évaluant sa performance à la fois par
rapport à un standard jugé satisfaisant mais aussi par rapport aux autres entreprises ayant procédé
à l’audit.
• Fonctionnement :
La méthode fonctionne en trois phases :
o Elle réalise tout d’abord un audit de vulnérabilités, aboutissant via des rosaces ou
diagrammes à l’identification des points faibles de la politique de sécurité
o On en découle une analyse des risques (distinction entre risques majeurs et simples)
et une mise en avant des menaces potentielles.
o Partant de là on définit les plans d’actions.
1.4.5.2 MEHARI (Méthode Harmonisée d’Analyse de Risque)
Anticipant les incontournables évolutions que la méthode MARION allait connaitre (ouverture des
réseaux et travail coopératif entre partenaires, clients et fournisseurs), le CLUSIF a publié la
méthode MEHARI.
MEHARI permet ainsi d’apprécier les risques au regard des objectifs fixés par la direction
générale, et non plus seulement par rapport aux niveaux de vulnérabilités donnés.
• Fonctionnement
15
MEHARI s’articule autour de trois plans
o Le plan stratégique de sécurité, qui fixe les objectifs de sécurités et les indicateurs
de mesure et détermine le niveau de gravité des risques encourus.
o Les plans opérationnels de sécurité, qui définissent, par site, les mesures de sécurité
à prendre.
o Le plan opérationnel d’entreprise, axé sur le pilotage stratégique et le suivi
d’indicateur clés.
1.4.5.3 EBIOS (Expression du besoin et Identification des objectifs de sécurités)
Elle a été élaborée par la DCSSI (Direction Centrale des Systèmes d’Information) qui est rattachée
au SGSN (Secrétariat Générale de la Défense nationale), lui-même placé sous l’autorité des
services du Premier ministre.
La méthode se veut un outil de gestion des risques SSI mais aussi de sensibilisation, de
négociation et d’arbitrage.
Les résultats de la méthode EBIOS peuvent être exploités dans le cadre d'une FEROS (Fiche
d'Expression Rationnelle des Objectifs de Sécurité), document créé par la DCSSI (Direction
centrale de la sécurité des systèmes d'information) qui dépend, elle aussi, des services du Premier
Ministre. Ce document est obligatoire pour les systèmes traitant d'informations classées "défense".
Il présente l'ensemble des objectifs de sécurité du système étudié et les risques résiduels, mais
aussi la démarche et l'argumentation qui a permis de les identifier. Ainsi, après avoir extrait
certaines données (système étudié, besoins de sécurité, menaces, risques...) en provenance d'une
étude EBIOS, la fiche FEROS permet de réorganiser et de classer les objectifs de sécurité et de
définir les responsabilités qui doivent - ou ne doivent pas - être engagées. [12][13]
1.4.6 Les principales normes d’audits de sécurité
Plusieurs normes de sécurité des systèmes d’information sont disponibles. Ils constituent des
guides méthodologiques ainsi que les moyens de garantir une démarche de sécurité cohérente.
1.4.6.1 Pourquoi suivre des normes ?
L’ISO a entrepris un vaste effort de rationalisation des travaux existants, donnant naissance à la
série de normes ISO/IEC 27000. Ce nombre correspond à la réservation d’une série de normes
16
relatives à la sécurité. À ce jour, seules les normes 27000, 27001, 27002 et 27006 sont publiées.
Certaines sont obligatoires pour obtenir une certification, les autres ne sont que de simples guides :
• La norme ISO/IEC 27000 présente le vocabulaire et les définitions du domaine de la
sécurité, applicables à chacun des standards.
• La norme ISO/IEC 27001 : décrit la politique du management de la sécurité des systèmes
d’information au sein d’une entreprise qui sert de référence à la certification.
• La norme ISO/IEC 27002 constitue le guide de bonnes pratiques de la sécurité des SI.
• La norme ISO/IEC 27003 a pour vocation d’être un guide d’implémentation
• La norme ISO/IEC 27004 sera un nouveau standard pour le pilotage des indicateurs et des
mesures dans le domaine de la sécurité des SI.
• La norme ISO/IEC 27005 sera un nouveau standard sur le management des risques pour la
sécurité des SI.
• La norme ISO/IEC 27006 résume les exigences applicables aux auditeurs externes dans
leur mission de certification sur l’ISO 27001.
1.4.6.2 La norme ISO/IEC 27001
La norme ISO/IEC 27001, publiée en novembre 2005, définit la politique du management de la
sécurité des SI au sein d’une entreprise. Elle est issue de la spécification BS 7799-2:1999
(Specification for Information Security Management Systems) qui définit les exigences à respecter
pour créer un ISMS (Information Security Management System). Elle spécifie en annexe certains
contrôles de sécurité, tirés de la norme ISO/IEC 17799, dont la mise en œuvre est obligatoire. La
norme ISO 27001 comprend six domaines de processus. [13]
• Réaliser une évaluation des risques liés à la sécurité.
• Gérer les risques identifiés.
• Choisir et mettre en œuvre les contrôles.
• Préparer un SoA (Statement of Applicability).
Comme la norme ISO 9001, l’ISO/IEC 27001 porte autant sur l’existence des dispositions
mises en place, que sur leur efficacité et l’établissement d’une boucle d’amélioration PDCA
(Plan-Do-Check-Act).
17
1.4.6.3 Les normes ISO/IEC 17799 et ISO 27002
La norme ISO/IEC 17799 de 2005, renommée ISO/IEC 27002, spécifie une politique de la
sécurité des systèmes d’information qui se présente comme un guide de bonnes pratiques.
De façon schématique, la démarche de sécurisation du système d’information doit passer par
quatre étapes de définition qui sont :
1. le périmètre à protéger (liste des biens sensibles)
2. la nature des menaces.
3. l’impact sur le système d’information.
4. les mesures de protection à mettre en place.
La norme ISO/IEC 27002 fournit des exemples et des indications sur les niveaux 1 à 3, et liste
pour le niveau 4 une série de mesures à mettre en place. Elle comporte 39 catégories de contrôle et
133 points de vérification répartis en 11 domaines. Tels :
• L’organisation de la sécurité :
• La classification et contrôle des biens.
• La sécurité du personnel.
• La sécurité physique
• la communication et l’exploitation :
• le contrôle d’accès
• l’acquisition, développement et maintenance des systèmes.
• La gestion des incidents.
• Le management de la continuité de service.
• La conformité aux dispositions légales et règlementaire
La norme ISO/IEC 27002 est orientée processus et son application dépasse de ce fait les simples
aspects de la technique informatique. Elle s’intéresse à l’organisation du personnel ainsi qu’aux
problèmes de sécurité physique (accès, locaux…).
1.4.6.4 Les critères communs (ISO/IEC 15408)
La norme ISO/IEC 15408 propose des critères communs d’évaluation de la sécurité des
technologies de l’information (Common Criteria (CC) for Information Technology Security
Evaluation). Elle est destinée avant tout aux industriels du secteur informatique, cette norme
18
permet l’évaluation des produits (matériels, logiciels) au niveau international. Elle définit les
procédures et les mesures techniques mises en place dans le cycle de vie d’un système
d’information pour fournir une base de comparaison sur les caractéristiques de sécurité.
L’accord dit CCRA (Common Criteria Recognition Arrangement) a réuni 7 pays capables de
délivrer des certifications, à savoir l’Allemagne, l’Australie, la Nouvelle-Zélande, le Canada, les
États-Unis, la France et la Grande-Bretagne.
Plusieurs autres pays (Finlande, Grèce, Italie, Israël, Japon, Pays-Bas, Norvège et Espagne) n’ont
pas de structure de certification mais reconnaissent la validité des critères communs (CC). Cet
accord reprend notamment les normes ITSEC en Europe et TCSEC (Livre Orange) aux États-
Unis, et permet de définir et de valider un certain niveau de sécurité à atteindre. [14][21][24]
1.5 Conclusion
Ainsi nous avons définis les différents types et normes d’audits ainsi que les différents référentiels
utilisés par un auditeur lors d’un audit d’entreprise. Cependant nous n’avons pas définis dans
quelle activité ou domaine de l’entreprise l’audit est rattaché, qui en sont ses commanditaires et
quelle évolution au sein de l’organisation de l’entreprise a conduit à introduire cette notion
d’audit. Le chapitre deux qui s’étalera sur l’IT gouvernance nous permettra de répondre a ces
questions.
19
CHAPITRE 2
IT GOUVERNANCE
2.1 Introduction
Après avoir compris ce qu’est l’audit, les raisons et les objectifs de ce dernier, ce chapitre s’étalera
uniquement sur la notion d’IT gouvernance : ses origines, les dispositifs, les lois et les
règlementations qui le régissent. Ensuite nous développerons en détail chacun des domaines
stratégiques de l’IT gouvernance comme : l’alignement stratégique, la gestion de risque, la gestion
des ressources, la mesure de la performance et la valeur délivrée par la technologie de
l’information.
2.2 Définitions
2.2.1 Origine étymologique
Le terme gouvernance dérivé de gouverner est issu du latin « gubernare » qui est emprunté au grec
« kubermâo », ce terme est employé en ancien français comme étant l’art ou la manière de
gouverner.
Dans la définition moderne le terme gouvernance désigne la capacité d’une organisation d’être en
mesure de contrôler, de réguler son propre fonctionnement afin d’éviter les problèmes liés à la
séparation entre les actionnaires et les acteurs. [11]
2.2.2 Gouvernance d’entreprise
La gouvernance d’entreprise est l’ensemble des processus, des règlementations, des lois et des
institutions influant sur la manière dont l’entreprise est dirigée, administrée et contrôlée.
Elle inclut aussi les relations entre les nombreux acteurs impliqués et les objectifs qui gouvernent
l’entreprise.
2.2.3 Gouvernance des technologies de l’information
La gouvernance des technologies de l’information concerne la direction des opérations, les
structures de l’organisation et les processus à mettre en œuvre qui permettent à l’organisation
informatique de supporter et de développer la stratégie et les objectifs de l’organisation.
Cette discipline fait partie de la gouvernance d’entreprise appliquée au domaine des technologies
informatiques et plus généralement des technologies de l’information. [14][15]
20
2.3 De la gouvernance d’entreprise à l’IT gouvernance
2.3.1 Paul Sarbanes et Michael G. Oxley
En décembre 2001, la faillite retentissante d’Enron et les malversations de la part de ses dirigeants
ébranlent le monde économique (faillite évalué à 64 milliards USD).Les dispositifs mis en place
par la NCFRR (National Commission on Fraudulant Financial Reporting) après les multiples
avertissements de la SEC (Securities and Exchange commission) vont conduire les mois suivants à
des faillites encore plus retentissants et tout aussi frauduleuse :
• Global Crossing (faillite évalué à 30.2 Milliard USD)
• Adelphia (faillite évalué à 21.5 Milliard USD)
• Conseco (faillite évalué à 61.1 Milliard USD)
• WorldCom (faillite évalué à 10 Milliard USD pour fraude comptable)
Pour faire face à cette situation qui provoque une crise de confiance sans précédente chez les
investisseurs, les autorités américaines décident alors de reformer leurs antiques dispositifs de
régulation des investissements.
Après un important débat public, Paul Sarbanes, membre du parti démocrate et sénateur du
Maryland, en association avec Michel G. Oxley, membre du parti républicains et siégeant au
congrès, vont coécrire une nouvelle loi de régulation dite de Corporate Gouvernance. Cette loi
imposant aux entreprises des contrôles internes et des rapports détaillés de ces contrôles en
réponse au aux conduites extravagantes des directeurs d’entreprises. [11]
2.3.2 Les mesures prises par la loi Sarbanes Oxley
La loi Sarbanes Oxley s’articule autour de plusieurs mesures phares :
• Responsabilité des dirigeants accrue et renforcement des sanctions pénales à l’encontre
de toutes irrégularités volontaire ou consciente (jusqu’ à 20 ans de prison).
• Meilleure accès à l’information et amélioration de la fiabilité. Les compagnies doivent
justifier auprès de la SEC les principes comptables guidant la présentation des comptes,
les codes de conduite éthiques, etc.
• Mise en place de comités de vérification indépendants, chargés de superviser les
processus de vérification et recevoir les plaintes relative à la comptabilité de l’entreprise,
issues des parties prenantes (actionnaires, collaborateurs).
21
• Instauration d’un organisme de réglementation et de surveillance, le PCAOB (public
Company Accounting Oversight Board) en charge de surveiller les entreprises d’audit
comptable, pouvant enquêter et sanctionner des personnes physique et morales.
Proposée au vote, cette loi est adoptée le 30 juillet 2002 par le congrès américain et ratifiée par le
Président.[15][16]
2.3.3 Dispositif de corporate gouvernance et son impact sur les ressource IT
En imposant un dispositif de gouvernance aux entreprises, la loi Sarbanes-Oxley (SOX) redéfinit
une grande partie des règles de fonctionnement et de gestion des sociétés cotées en bourse.
Figure 2.01 : Dispositif de corporate et son impacte sur les ressources
2.3.4 Les sections SOX qui concernent les ressources IT
La majorité des articles (sections) de la loi Sarbanes-Oxley concernent le contrôle et la régulation
des plus hautes instances d’une organisation. Seuls quatre des 66 articles ont une ramification
directe avec les départements IT.
2.3.4.1 Section 302: corporate responsibility for financial reports
Cette section porte sur la responsabilité de l’entreprise en matière de rapport financier. Le PDG et
le directeur financier doivent certifier l’ensemble des déclarations financières. La gestion des
documents et des enregistrements intégrés dans les systèmes d’informations financiers de l’ERP
(Entreprise Ressource Planning) doivent offrir des protocoles d’audit au niveau de l’ensemble des
22
transactions afin d’avoir une visibilité claire des données financières. Cette section précise en
outre qu’une analyse des carences au niveau des contrôles internes doit être régulièrement et
systématiquement effectuée.
2.3.4.2 Section 404: management’assesment of internal controls
Evaluation de la gestion des contrôles internes. Les sociétés doivent documenter et évaluer
(annuellement) l’ensemble du dispositif de contrôle interne impliqué dans les risques
opérationnels.
Seul un auditeur indépendant et externe à l’entreprise est habilité à certifier que les contrôles sont
documentés et fonctionnent efficacement. Le dispositif de contrôle s’applique à l’ensemble du SIF
(Système d’Information Financier).
2.3.4.3 Section 409 : real-time discolure
La section 409 a pour objet l’information en temps réel. Toute modification significative affectant
des déclarations financières doit être rapportée rapidement (dans un délai inférieure à 48 heures).le
mécanisme de gestion des transactions intégré aux systèmes d’information financier de l’ERP doit
être en mesure de gérer les flux informations entrant dans l’organisation de façon immédiate afin
d’offrir une visibilité et un contrôle en temps réel.
2.3.4.4 Section 1102 : Tampering with a record (altering or destroying data)
Cette section concerne la falsification d’un document (altération ou destruction de données).Elle
prévoit la responsabilité pénale et des sanctions à l’encontre de toutes personnes qui falsifient un
document, par rapport ou d’autres objets avec l’intention d’altérer leur intégrité ou leur
disponibilité. La gestion des documents circulant dans les systèmes d’information financiers doit
offrir des garanties d’intégrité, de complétude et de traçabilité des données. [7][16]
2.3.5 Domaines stratégique de l’IT gouvernance
Le nombre de domaines devant être pris en considération dans le cadre de l’IT gouvernance
suscite encore aujourd’hui débat et n’a pas fait l’objet de consensus. Il existe deux courants de
pensée :
23
• Celui de l’ITGI (IT Governance Institute): filiale de l’ISACA (Information systems Audit
and Control Association), qui dans la publication Board Briefing on IT governance a
identifié cinq domaine stratégique qui ont été repris dans COBIT V4.
• Celui défini par un groupe de chercheurs et d’experts indépendants spécialistes en
gouvernance et management stratégique des systèmes d’information, issu de l’AIS
(Association for Information System) qui propose une version étendue avec huit domaines
stratégiques.[3]
Approche étendue
Approche ITGI
Alignement IT Alignement stratégique Alignement stratégique
Risque IT Gestion de risque Gestion de risqué
Ressources IT Gestion de ressources Gestion de resources
Performance IT Gestion de la performance Mesure de la performance
Valeur IT Valeur financière Valeur délivrée
Contrôle IT Contrôle et audit
Maturité IT Maturité
Management IT Management
Tableau 2.01: Les domaines stratégique de l’IT gouvernance
2.4 L’alignement IT
Les systèmes d’information en charge de supporter l’organisation ont une importance majeure
dans la survie de l’entreprise. De leur efficacité à délivrer des services permettant aux différents
composants de l’entreprise de s’aligner de manière homogène sur les objectifs stratégique de
l’entreprise dépend la performance.
L’alignement stratégique de l’organisation sur le métier est le fait de mettre en cohérence la
stratégie du système d’information (et de la logistique) avec la stratégie de l’entreprise et de le
planifier dans une perspective pluriannuelle.
L’alignement IT prend en compte deux niveaux d’alignement distincts :
24
• L’alignement stratégique.
• L’alignement sur business process.
2.4.1 L’alignement stratégique
Les bénéfices de la politique d’investissement au niveau des technologies de l’information
dépendent de l’alignement des ressources IT sur les objectifs stratégiques de l’entreprise. Si celle-
ci est contrainte de modifier tout ou partie de sa stratégie, cela entraîne un changement de ses
objectifs d’alignement au niveau des ses moyens IT. Cela peut provoquer une variation
significative des bénéfices attendus de l’alignement. L’ampleur de ces variations doit par
conséquent être mesurable de façon non prédictive et non réactive.
La stratégie d’une entreprise doit, pour être efficace, profiter pleinement des avantages que lui
offre la technologie, cela implique au préalable que cette stratégie soit basée sur une logique de la
capitalisation des connaissances, des compétences et des ressources technologiques. Cette
approche entend que le management définisse des stratégies et des objectifs coordonnés afin de
créer des conditions d’alignement favorables. Cette notion de stratégie d’alignement entre la
stratégie d’entreprise et de la gestion des technologies utilisées est illustrée par le modèle de
Tallon et Kraemer dans la figure 2.02.
Figure 2.02 : Modèle de Tallon et Kraemer sur les dimensions d’alignement stratégique
25
2.4.2 Alignement sur le business process
C’est l’alignement des ressources informatiques sur les activités de l’entreprise. Par exemple
l’acquisition d’un nouveau logiciel de mise en page pour le service de communication ou d’un
applicatif de gestion pour le service comptable. Cependant de ce point de vue la complexité vient
du fait de la connaissance des parties en présence, la réalité de la situation, les limites impliquant
les changements et la possibilité s’intervention.
a. Identification des parties en présence
Comme on l’a dit dans le chapitre « un » la gouvernance des systèmes d’information provient
essentiellement des bonnes pratiques, et grâces à des années d’expériences les experts ont défini
les parties en présence comme étant illustré dans la figure 2.03:
• Le management.
• Les métiers.
• Les utilisateurs ;
• Les applicatifs métiers.
• Les processus.
• Les technologies de supports ;
• La finance.
Figure 2.03 : Parties intervenante dans la problématique d’alignement
26
b. image réelle de la situation
Pour disposer d’une image réelle de la situation, l’orientation actuelle se base principalement sur
le retour des services supports (Help Desk). En effet l’activité de support informatique permet
d’identifier et de cartographier les faiblesses des systèmes d’informations tant sur le plan logique
qu’au niveau des structures et des processus, (illustré par la figure 2.04.)
Figure 2.04 : Rôle des services supports dans l’alignement
En associant un ensemble de critères à chaque partie intervenant dans l’alignement, grâce aux
informations collectées par les services de support,il est possible de mettre en place un système de
notation et de délimiter certains seuils. Le tableau 20.2 est un exemple de tableau d’alignement.
Partie Critère Score Objectif Etat
Technologies Capacités serveurs
0.67 0.70 Aligné
Capacité réseaux
0.80 0.82 Aligné
Incidents
0.25 0.1 Surcharge
Pannes
0.23 0.1 Surcharge
Tableau 2.02: Exemple de tableau d’alignement
27
2.5 Les ressources IT
On entend par ressource IT les composantes technologiques qui constituent le SI mais aussi les
hommes qui les utilisent et qui les entretiennent.
L’ ITRM (IT Ressource Management) définit les principes fondamentaux de gestion et de
l’organisation des ressources informatiques dans le cadre de la gouvernance des technologies de
l’information. Son objectif est de mettre en place un ensemble de dispositifs permettant de gérer
l’infrastructure informationnelle afin que cette dernière soutienne et développe de façon optimale
l’activité de l’entreprise et donc de sa capacité à créer de la valeur.
2.5.1 Les niveaux stratégiques de l’ITRM
L’ ITRM est construit sur trois niveaux :
• Stratégique
• Proactif
• Actif
La figure 2.05 explique les liens entre ces trois niveaux stratégiques, la gouvernance et les
objectifs de chacune de ces niveaux.
Figure 2.05 : Organisation de la gestion des ressources
28
2.5.2 Management stratégique des ressources IT
La gestion stratégique des ressources informatiques est orienté « business » c'est-à-dire qu’elle est
basée sur l’activité de l’entreprise.
Elle cherche à délimiter comment les ressources informationnelles doivent être mise en œuvre
pour contribuer efficacement au fonctionnement de l’organisation. Pour cela on utilise le principe
d’architecture d’entreprise EA (Enterprise Architecture) grâce à laquelle la direction informatique
peut adopter une stratégie cohérente vis-à-vis des ressources. La figure 2.06 nous montre en
détails les différents éléments constitutifs de cette EA.
Figure 2.06 : Eléments constituant l’architecture d’entreprise (EA)
2.5.2.2 Entreprise Architecture a Framework (EAF)
EAF a été développé par John A. Zachman en 1987, c’est un modèle qui permet de décrire chaque
élément d’un système d’information.
Ce modèle est une approche matricielle où l’on place sur l’axe verticale le point de vue des acteurs
fondamentaux et sur l’axe horizontale une classification des aspects fondamentaux du système
d’information. Chaque cellule formée par l’intersection d’une ligne et d’une colonne représente un
aspect du système à partir d’un point de vue particulier.
2.5.2.3 Architecture distribuées à base d’objets
On parle d’infrastructure distribuée quand les ressources IT ne sont pas déployées sur un SI
unique mais sur un ensemble de systèmes interconnectés.
Les avantages d’un tel système sont :
• L’accroissement de la disponibilité.
• L’importance de la scalabilité.
• La simplification du déploiement.
29
• Une simplification de la maintenance.
Ce type d’architecture est basée sur le concept de composants objets qui fonctionnent et
communiquent indépendamment de la plateforme qui les héberge.
On parle d’objet métier lorsque les actions sont spécifiques à une activité. Ces objets distribués
communiquent entre eux grâce aux middlewares dont les plus célèbres sont :
• CORBA (Common Object Request Broker Architecture) : c’est une norme de l’OMG
(Object Management Group) qui permet la communication entre objet écrits dans des
langages différents (C++, Java,…).
• Java RMI (Remove Method Invocation) : c’est une technologie développée par Sun
Microsystems pour faire communiquer des objets développés en Java (ex : EJB :
Entreprise Java Beans) distribués sur le réseau.
Le fait de distribuer des objets effectuant des traitements identiques sur des serveurs
interconnectés sur un réseau accroît les ressources disponibles.
Exemple lors d’une demande de traitement qui doit être effectué par deux objets N1 et N2 d’un
serveur donnée, si l’objet N2 est indisponible sur ce serveur alors le système va chercher sur
l’ensemble des autres serveurs des objets similaires.
Figure 2.07 : Accroissement de la disponibilité du système par les systèmes distribuées
30
Dans le cadre de la gouvernance, la garantie de disponibilité est un point fondamental. Les
architectures distribuées bien que complexes à mettre en œuvre répondent à ces exigences et
doivent êtres privilégiées.
2.5.3 Management Proactif des ressources IT
Etre proactif est le fait d’utiliser un ensemble de processus et de moyens pour anticiper un certains
nombre d’évènements. Dans le cadre de management des ressources IT l’entité responsable de
cette démarche proactive est la direction des ressources informatiques.
Le management proactif couvre :
• Les composants matériels du système d’information ou HIC (Hardware Infrastructure
Component).
• Les composants logiques du système d’information ou SIC (Software Infrastructure
Component).
2.6 Les risques IT
Le risque IT comme toute classe de risque a des spécificités propres. Il est assez fréquent dans le
monde informatique de confondre la notion de risque et la notion de sécurité. Dans la démarche
d’IT gouvernance la gestion de risque est considérée comme un domaine stratégique. Ceci
s’explique par le fait que l’entreprise s’appuie intégralement sur des ressources informationnelles
pour atteindre ses objectifs. Le manque de disponibilité partielle ou totale d’un service délivré par
le système d’information est un risque majeur dont l’origine ne relève pas forcément de la
sécurité.
Cependant la gouvernance ne nie pas l’importance de la sécurité mais la positionne en tant que
réponse face à des risques spécifiques clairement identifiés. [1]
2.6.1 L’identification du risque
Les risques potentiels pour un système d’information sont :
• Risque humains
• Risque technologiques
• Risque d’activité
• Risque naturels
31
2.6.1.1 Les risques humains
Le risque humain est de très loin le plus important et le plus dangereux. On estime que de toutes
les catégories confondues la menace humaine, présente sur les infrastructures IT provoque une
perte annuelle de plus de 50 Milliards de dollars pour les seules entreprises américaines. Face à ce
constat, le bureau fédéral d’investigation FBI (Federal Bureau of Investigation) a identifié cinq
types de menace qui sont repartis dans le tableau 2.03.
Type de menace Type de motivation
Type d’action
Espionnage industriel Argent, relations concurrence, projet personnel
Vol d’informations relatives à des processus, des personnels, des données économiques.
Criminalité informatique Conflit, concurrence professionnelle, jalousie, revanche
Destruction d’information, intrusion dans les systèmes, fraude, Blackmail, vol d’informations et d’équipement
Intrusion Curiosité, challenge personnel, argent, revanche, erreur
Recherche d’information, ciblage de personnel, fraude sabotage, vol
Hacker Refus du système, challenge personnel
Vol d’informations, attaque virale, diffusion de code
Terrorisme Conflit religieux, politique ou personnel
Destruction d’information et/ou équipements, pénétration de système, attaque virale, menace sur le personnel
Tableau 2.03: Tableau des principales menaces par ordre d’importance
Cependant il faut préciser que le risque ne se limite pas à des gens malintentionnés. L’erreur
humaine est une source de risque tout aussi importante car ses répercussions peuvent elles aussi
affecter le fonctionnement d’un système donc d’une organisation. Quatre types d’erreur doivent
être pris en compte :
32
• Erreur de compréhension.
• Erreur d’usage.
• Erreur de choix.
• Erreur de conception.
2.6.1.2 Les risques technologiques
Le risque technologique se définit comme le disfonctionnement d’un composant dans une
infrastructure IT pouvant perturber partiellement ou totalement un ou plusieurs services.
En règle générale, les risques techniques sont mieux maîtrisés au niveau des équipements
(hardware) qu’au niveau des applicatifs (software), ceci est dû au fait qu’il existe peu de
composants spécifiques dans les équipements constituant les infrastructures IT.
Le risque IT prend en compte trois paramètres fondamentaux :
• La perte d’intégrité
• La perte de disponibilité
• La perte de confidentialité
2.6.1.3 Les risques d’activité
Ces risques sont engendrés par la nature même de l’activité de l’entreprise, son marché, son
positionnement, son organisation.
La perte de capacité est liée à un accroissement des flux engendrant une saturation au niveau des
moyens de traitement de stockage. Elle affecte le fonctionnement de l’entreprise par un effet de
ralentissement dont la fréquence et l’amplitude augmente avec le temps.
2.6.1.4 Les risques naturels
Les risques climatiques sont les plus importants dans la catégorie des risques naturels.
Les principaux risques sont :
• L’inondation : risque fréquent, en augmentation, potentiellement dévastateur pour les
infrastructures IT.
• La foudre : risque fréquent, en progression, dangereux.
• Le gel : risque lié à la rupture des systèmes de chauffage.
33
• La canicule : risque lié à la rupture des systèmes de refroidissement.
2.6.2 la gestion du niveau de risque
Il existe différentes méthodes pour établir un niveau de risque celle que nous utilisons ici prend en
compte :
• Le taux de probabilité
• Le degré d’impact sur l’infrastructure IT
En fonction de la taille de l’entreprise et de son activité, on peut gérer l’échelle du risque sur une
base de trois valeurs : Faible, moyen, élevée ou de cinq valeurs : Minimum, Faible, Acceptable,
Elevée, Intolérable. Dans tous les cas l’échelle doit être la même pour les deux paramètres en
question.
La classification du risque s’établit sur une échelle de 1 à 100 et se calcule à partir d’une matrice
3x3 ou 5x5 selon le cas.
Pour les échelles à trois valeurs la classification s’effectue de la manière suivante :
• Faible : de 0 à 10
• Moyen : de 11 à 50
• Elevé : de 51 à 100
Le tableau suivant est une matrice de calcul 3*3 pour la classification du risque.
Probabilité Impact Risque faible (10)
Risque moyen (50)
Risque élevée (100)
Faible (0.1) Risque faible (10x0.1=1)
Risque faible (50x0.1=5)
Risque faible (100x0.1=10)
Moyen (0.5) Risque faible (10x0.5=5)
Risque moyen (50x0.5=25)
Risque moyen (100x0.5=50)
Elevée (1) Risque faible (10x1=10)
Risque moyen (50x1=50)
Risque élevé (100x1=100)
Tableau 2.04: Matrice de calcul pour la classification du risque
34
2.6.3 Réduire le risque
L’élimination pure et simple d’un risque est un vieux rêve inaccessible, voilà pourquoi le
traitement du risque est basé sur sa réduction et non sa suppression.
Le but est de diminuer le niveau d’une menace pour que son impacte soit ramené à un niveau
justifiable et tolérable.
Plusieurs facteurs doivent être pris en compte dans une politique de réduction des risques :
• L’hypothèse du risque
• La possibilité d’évitement
• Les moyens de limitation
• La planification du risque
• La supervision et le contrôle
• Le transfert du risque
2.6.3.1 L’hypothèse du risque
Il prend en compte l’identification, l’évaluation et le contexte. Le contexte est défini à partir du
cycle de vie d’un composant. Ces derniers ont un fonctionnement constitué de trois cycle
distincts : le cycle de projet, la transition (installation, suppression, modification), le cycle
d’exploitation. Comme expliqué dans la figure 2.08 suivante.
Figure 2.08 : Niveau de risque spécifique
35
2.6.3.2 Possibilité d’évitement
Elle consiste à mettre en œuvre des solutions permettant de s’affranchir de certains risques
connus. La plupart du temps les solutions d’évitement se trouvent dans le paramétrage des
composants de l’infrastructure IT.
Par exemple : le paramétrage d’un routeur afin d’effectuer un filtrage du trafic entrant et sortant
de l’intranet afin d’éviter tout intrusions.
2.6.3.3 Les moyens de limitations
La limitation part du principe que certains risques ne peuvent êtres évités et que ce faisant il est
indispensable de contenir au maximum leurs conséquences.
Les virus informatiques sont un cas typiques. Par définition le seul moyen de lutter contre est de
disposer d’un antivirus, cependant entre le moment de l’infection et la mise à la disposition de
l’antivirus il existe un temps T au cours duquel il y a un phénomène de contagion potentiellement
dangereux. Les moyens de limitations sont donc indispensables pour protéger l’infrastructure.
Une grande partie de la sécurité informatique est établie sur cette base.
2.6.3.4 La planification du risque
La planification du risque consiste à élaborer des plans de gestion du risque. Ces plans sont relatifs
à certains domaines clé du management des systèmes d’information.
Un plan de gestion de risque contient généralement :
• La description des objectifs visés.
• L’organisation.
• L’évaluation du risque.
• La réduction du risque.
• Le contrôle et le suivi du risque.
• La communication à faire.
• La documentation.
2.6.3.5 L’administration et le contrôle du risque
Etroitement associés à la politique de sécurité. Les procédures de contrôles ont pour objectif de
prévenir les sources de menaces. On distingue deux types de contrôles
36
• Contrôle technique de la sécurité.
• Contrôle de l’administration de la sécurité.
Dans les deux cas il s’agit de dispositifs destinés à administrer les moyens de détection, de
gestion, de restauration et de prévention afin d’éviter toute défaillance dans le système de
protection.
2.6.3.6 Le transfert de risque
Le transfert se fonde sur le principe que dans certains cas il est possible de déplacer un ou
plusieurs risques vers une structure plus adaptée pour les gérer.
Par exemple : si la société A souhaite disposer d’un site internet. Si elle héberge elle-même son
site à partir des ses propres infrastructures elle va devoir gérer les risques que cela implique sur
son système d’information. Cependant si elle décide de faire héberger son serveur dans un Data-
center elle transfèrera les risques liés à l’administration du serveur et supprime de fait ceux liés à
la sécurité de son SI.
2.7 La valeur IT
Contrairement aux valeurs immobiliers qui suit la logique « plus je dépense, plus mon patrimoine
augmente ». Dans la logique de l’IT Gouvernance, la valeur IT cherche à déterminer en quoi les
ressources informatiques contribuent à la performance de l’entreprise. Une société qui dépense
100000 Euros dans ses infrastructures IT peut avoir une valeur bien supérieur à un autre qui
dépense 1 million si elle fourni le même résultat.
2.7.1 Les indicateurs T(X)O
La gamme des indicateurs T(X)O est généralement employés pour évaluer des systèmes existants.
On récence quatre indicateurs :
• TCO : Total Cost of Ownership
• TBO : Total Benefit of Ownership
• TRO : Total Risk of Ownership
• TVO : Total Value of Ownership
Les indicateurs T(X)O prennent en compte les éléments clés constituants les ressources IT au sein
d’une organisation. La mise en œuvre des indicateurs T(X)O s’organise autour de trois étapes
• L’évaluation (audit)
37
• la mesure de la performance (Benchmark)
• le résultat, la recommandation
2.7.1.1 Total Cost of Ownership (TCO)
Le TCO est un indicateur crée et mise au point par le groupe Gartner au milieu des années 80.Il est
sans aucun doute l’un des plus connu et des plus utilisé dans le monde de l’informatique. Il permet
de déterminer avec précision le coût réel d’un composant informatique : serveur, terminal,…
Il part du principe qu’un composant ne se limite pas à son coût d’acquisition mais également des
coûts indirects comme le support utilisateur et le disfonctionnement.
2.7.1.2 Total Benefit of Ownership (TBO)
Le TBO est le premier descendant du TCO. Les constructeurs et éditeurs informatiques ont crée le
TBO en partant du principe que si le TCO leur était défavorable ce nouvel indicateur serait plus
profitable. Malgré ses avantages le TCO est un indicateur qui ne permet pas d’évaluer un
composant car il ne prend pas en compte que le coût de possession et ignore les bénéfices qu’il
apporte.
2.7.1.3 Total Risk of Ownership (TRO)
Le TRO s’inscrit dans la suite logique du TCO et du TBO, il a pour but de compléter ces
indicateurs en introduisant la notion d’évaluation du risque.
• Risque direct : délais, coût, intégrité des données…
• Risque indirect : organisation, production,…
2.7.1.4 Total Value of Ownership (TVO)
Le TVO détermine la valeur à partir du coût, des revenus et des opportunités.
De nombreux DSI estiment que les trois premiers indicateurs sont suffisants pour déterminer un
résultat global fiable GITV (Global IT Value). Ce résulta est facile à déterminer grâce à la
formule 2.01 suivante.
GITV �TBO � TCO
TRO
(2.01)
38
2.8 Mesure de la performance
La gestion de la performance d’un système informatique est un composant clé de la performance
globale d’une organisation. Elle doit s’effectuer à l’intérieur du dispositif de gouvernance pour
que le management soit en mesure de maîtriser les phénomènes d’amortissement réciproques.
Elle s’appuie sur deux principes:
• Le principe de monitoring : analyse des indicateurs clés directs (mesures brutes fournies
directement par les ressources constituant le SI). Pour cela on utilise une gamme d’outils
spécialisés permettant de suivre l’activité de l’ensemble des éléments grâces à des
« metrics » dédiés à:
o La charge d’un serveur.
o L’occupation du réseau.
o le temps de latence.
• Le principe de supervision : est centré sur l’analyse des écarts entre les objectifs à atteindre
et le niveau constaté. Les informations fournies par le monitoring sont analysées en regard
des besoins et des objectifs définis par le management.
2.9 Conclusion
Nous avons donc parlé de la gouvernance des SI, de son origine ainsi que des domaines
stratégiques de l’IT gouvernance. Cependant ceci est incomplet pour effectuer un audit de sécurité
car il faut connaître en détails les mécanismes de sécurité d’une entreprise qui est largement
développée dans le chapitre suivant.
39
CHAPITRE 3
PRESENTATION DE LA SECURITE DES SYSTEMES D’INFORMAT ION
3.1 Introduction
Ayant maintenant une base solide sur ce qu’est l’audit et la gouvernance des systèmes
d’information, ce chapitre traitera la partie sécurité des systèmes d’information. Tout au long ce
dernier nous allons donner la définition de ce qu’on entend par sécurité, les différents problèmes
de la sécurité ainsi que les différents aspects de la sécurité telles que la sécurité physique et la
sécurité logique.
3.2 La sécurité des systèmes d’information
3.2.1 Définition
L’ouverture des réseaux vers l’extérieure de l’entreprise et surtout la multiplication des moyens
d’accès fragilisent le système d’information. Ce dernier devient alors la cible d’attaques qui visent
non seulement à prendre connaissance, à modifier les informations ou à paralyser le système mais
aussi de menaces accidentelles telles que les mauvaises manipulations.
L’ensemble des moyens mis en œuvre pour le protéger se regroupe sous le terme générique de
« sécurité des systèmes d’information ». [17][18]
3.2.2 Différentes approches de la sécurité
Bien que la notion de sécurité soit une vision globale de la protection du système d’information, il
convient de distinguer deux approches de la sécurité :
• La sureté de fonctionnement (safety), concerne l’ensemble des mesures prises et des
moyens utilisés pour se prémunir contre le disfonctionnement du système.
• La sécurité (security), regroupe tous les moyens et les mesures prises pour mettre le
système d’information à l’abri de toute agression.
3.2.3 Les différents problèmes de la sécurité
Les différents problèmes de la sécurité peuvent être classés en cinq grandes catégories :
La confidentialité, l’authentification, l’intégrité, la non-répudiation et le contrôle d’accès. [18]
40
3.2.3.1 La confidentialité
La confidentialité est l’assurance que l’accès à une information du système d’information est
limité aux seules personnes, applications, équipements autorisé à en connaître le contenu. Ici on
doit assurer la protection des données contres les attaques non autorisées.
3.2.3.2 L’authentification
L’authentification permet d’assurer que celui qui se connecte est bien celui qui correspond au nom
indiqué. Autrement dit l’authentification c’est apporter la preuve de son identité à l’entité qui la
réclame. C’est un moyen qui permet de protéger le système contre l’usurpation d’identité et
d’assurer la confidentialité et l’intégrité de l’information.
3.2.3.3 L’intégrité
Cette propriété assure que les données reçues sont exactement celles qui ont été émises par
l’émetteur autorisé. Elles ont pu éventuellement pu être copiées mais aucun bit ne doit avoir été
changé. Elle certifie également que les données n’ont pas été modifiées ou détruites de façon non
autorisée dans les systèmes d’enregistrement.
3.2.3.4 La non-répudiation
Elle assure que le message a bien été envoyé par une source spécifié et a été reçu par un récepteur
spécifié. La non-répudiation est une propriété qui consiste à empêcher le démenti d’une entité
après avoir effectué une opération.
Lors des transactions électroniques la non-répudation permet de déterminer :
• La preuve d’origine : un message envoyé ne peut être démenti par l’émetteur.
• La preuve de réception : un message reçu ne peut être dénié par le récepteur.
Par exemple on peut retrouver la trace d’un appel téléphonique de telle sorte que le récepteur de
l’appel ne puisse répudier cet appel.
41
3.2.3.5 Le contrôle d’accès
Le contrôle d’accès a pour but de prévenir l’accès à des ressources sous des conditions définies et
par des utilisateurs spécifiés.
3.3 La protection physique
3.3.1 Les verrous
La première ligne de défense en matière de protection physique est habituellement réalisée par le
déploiement de divers types de serrures sur les portes à toutes salles informatiques et matériels de
télécommunication. Ces salles incluent la salle de l’ordinateur principale, le câblage et les pièces
où les serveurs de fichiers, passerelles, routeurs, et autres sont installés. [13]
3.3.1.1 Les clés traditionnelles
Les clés classiques sont encore l’un des moyens les plus efficaces pour contrôler l’accès restreint
aux salles. Il est impératifs qu’un membre très fiable de l’organisation, de préférence un agent de
sécurité soit responsable de la délivrance de toutes les clés ainsi que des contrats avec les
fournisseurs lors de l’installation et du remplacement de toutes les serrures. Il doit en ce sens tenir
un inventaire de toutes les clés émises ainsi que de toutes les personnes détenteurs en s’assurant
que les secours sont correctement fixés car d’autres personnes non autorisé risquent d’accéder aux
salles sans avoir l’autorisation.
3.3.1.2 Les badges d’accès électroniques
Les badges électroniques sont des clés permettant d’accéder à des salles protégées, seulement ici,
les serrures sont des lecteurs de cartes électroniques. Le lecteur lit les informations contenues dans
le badge et envoie cette information vers un programme de lecture de carte contenu dans un
microordinateur ou un serveur de fichier situé dans un emplacement sécurisé. Si cette information
est vérifiée dans la table des badges autorisés à entrer alors une commande est envoyée pour
ouvrir le verrou électronique de la porte.
Ces badges présentent de nombreux avantages par rapport aux clés traditionnelles :
• On n’a plus besoin de distribuer des dizaines de clés pour chaque employé.
42
• En cas de perte des badges au lieu de changer les serrures (problème fréquemment
rencontré avec les clés traditionnelles) on peut immédiatement désactiver le badge
perdu.
• Ces badges offrent également la possibilité d’enregistrer les allés et venus de chaque
employé.
• L’accès à certains endroits peut être programmé pour certains temps seulement de la
journée ou de la nuit.
Malgré ces avantages les serrures à badges électroniques montrent certaines défaillances :
• Pour les portes à doubles serrures avec clé et lecteur de carte, la personne possédant la clé
peut pénétrer sans avoir besoin de cartes.
• Une erreur d’ordre humain ou un acte de sabotage volontaire de la part de l’administrateur
du système de sécurité peut être à l’origine d’un accès non autorisé.
• L’application de lecture de carte pourrait contenir des failles de programmations qui
seraient à l’origine de doublure de carte pour une même personne par exemple.
3.3.1.3 Les serrures à code chiffrée
C’est une serrure qui peut être ouverte en tapant un code (chiffre ou mots) secret sur un clavier se
trouvant sur ou près de la porte en question. Avec ce genre de système de sécurité il est important
de changer les codes périodiquement surtout quand des employés viennent à quitter l’entreprise. Il
est aussi indispensable que ces codes soient communiqués aux personnes supposées autorisées à
pénétrer dans les salles protégés.
Cependant ce genre de code est facilement identifiable (date d’anniversaire, prénom, etc …) mais
aussi contrairement aux cartes d’accès il est impossible d’identifier et d’enregistrer les personnes
qui sont entrées ou sorties. Il est donc indispensable d’associer à ce dispositif des caméras de
surveillance ou des gardes de sécurités.
3.3.1.4 Les codes combinés
C’est un système où une personne seule ne doit connaître la totalité du code utilisé pour
déverrouiller le système. Le code peut être divisé en deux, trois ou quatre parties dont chacune
connue de personnes différentes, donc seule la présence toutes ces individus permet d’ accéder
aux équipements ou aux informations sécurisés.
43
3.3.1.5 Les serrures biométriques
C’est un type de serrure qui permet d’authentifier une personne en reconnaissant une ou plusieurs
caractéristiques physiques particulières de l’individu. Par exemple : empreintes digitales, images
faciales, reconnaissance de l’iris, enregistrement de la voix, image de la rétine, …
Ce type de reconnaissance rend certains types de système quasiment infalsifiables, cependant ces
équipements sont très onéreux et difficiles à mettre en œuvre. Ils sont généralement utilisés pour le
contrôle d’accès des salles contenants des équipements ou des informations sensibles.
Pour information les verrous à empreintes digitales sont relativement faciles à contourner, parce
que l'empreinte possède en moyenne entre 25 et 40 points de mesure. Cela contraste avec
l'identification de l'iris, qui a entre 250 et 266 points de mesure. Selon un expert, l'iris est
la partie la plus riche en fonctionnalités et la stabilité de l'anatomie, car il est formé par un
processus naturel de déchirure des tissus dans la partie colorée de l'œil qui crée
un échantillon aléatoire, structure totalement chaotique qui est différent dans chaque œil.
Chacun des contrôles mentionnés ci-dessus peuvent être contournés en utilisant la méthode dite
« piggyback » : méthode qui consiste à ce qu’une personne ayant une autorisation laisse entrer une
personne non autorisée à entrer avec lui dans la zone sécurisé. D’où la nécessité d’avoir des gardes
de sécurité ou des caméras de surveillance.
3.3.2 Les gardiens de sécurité
Les gardiens de sécurité sont un élément important dans l’organisation de la sécurité en générale.
Biens qu’ils ne soient pas de la police, ils sont un moyen de dissuasion contre le vol et d’autres
activités illégales non autorisées. Ils sont aussi très efficaces contre le « piggbacking ». Ils sont
également en charge de la suivie des caméras de surveillance. Les gardes de sécurités peuvent
également servir de témoins lors de la mise en accusation d’un employé ou d’un intrus suspecté
d’accès non autorisé, de vol, ou de possession d’informations confidentielles.
3.3.3 Les caméras de surveillances
Ils forment un contrôle supplémentaire qui peut agir comme un moyen efficace ayant un effet
dissuasif sur les activités non autorisées. Ils fournissent aussi des preuves lors des poursuites des
employés suspectés.
Les caméras de surveillances sont généralement placés dans des endroits stratégiques qui offrent
des vues complètes des portes ou des équipements qu’ils sont censés protéger. Un moniteur pour
chaque caméra vidéo serait optimal. Cependant, dans de nombreux établissements, il y a plus de
44
caméras vidéo que l'espace disponible pour les moniteurs dans le poste de garde. Ces systèmes
sont conçus de telle sorte que les points de vue figurant dans les moniteurs soient des rotations
entre les différents caméras vidéo qui changent périodiquement (par exemple, toutes les 30
secondes). Les procédures de garde de sécurité doivent respecter une observation
des activités dans les moniteurs sur une base régulière.
Pour les systèmes de bandes vidéo, des procédures doivent également être inclues dans le manuel
de garde de sécurité pour veiller à ce que bandes vidéo sont remplacés avant qu'ils ne soient
épuisés. Les bandes complètes doivent être conservées pendant une période raisonnable de temps
dans un endroit sûr hors site. Dans certains systèmes plus sophistiqués les images peuvent être
transmises par voie électronique à l'installation de stockage à distance en mode temps réel afin que
les procédures de sauvegarde, tous les soirs, ne soient plus nécessaires.
3.3.4 Les alarmes et contrôles de détection d’urgences
Les alarmes peuvent êtres déclenchés par la fumée, un incendie ou un certains nombre d’autres
actions spécifiques (par exemple l’ouverture forcée d’une porte).
Les avertisseurs doivent être installés à des endroits stratégiques à travers les installations pour
une raison de sureté et de sécurité. Ils doivent être continuellement sous surveillance électronique,
plus particulièrement les avertisseurs d’incendies doivent être sous la surveillance des gardes.
Les systèmes par aspersion en cas de détection de fumée ou de chaleur trop élevée sont
nécessaires dans la plupart des installations. Mais pour le cas des « data center » ils ne peuvent pas
être situés au dessus des appareils informatiques. Cependant cela dépend de la politique de
sécurité de l’entreprise car en installant des gicleurs dans la salle où sont installés ces
équipements alors:
• La sécurité des employés seraient maximisée
• Le dégât causé par le feu peut être contenu dans un seul endroit évitant ainsi la
propagation du feu et la perte de tous les autres équipements.
• Si les appareils sont assurés alors la perte de ces équipements n’est pas une perte
majeure.
Beaucoup de « data center » sont maintenant équipés de système de prévention sous pression au
gaz halon dans le cas d’incendie. Le halon élimine l’oxygène de l’air supprimant ainsi un
incendie. Le halon est non toxique, se dissipe rapidement et ne laisse pas de résidus. Cependant
45
même si le halon n’endommage pas les équipements il est un danger pour l’environnement car il
détruit la couche d’ozone. Cela explique sa prohibition dans certaines villes.
Les extincteurs sont des éléments simples mais efficaces contre les incendies. Ils doivent être
situés stratégiquement à travers l’installation en particulier dans les zones où les risques
d’incendie sont les plus fortes.
Les alarmes, les gicleurs et les extincteurs doivent être inspectés par des services d’incendies
locaux pour assurer la conformité avec les codes d’incendie.
3.3.5 Chauffage, ventilation, et système de refroidissement
Il est mieux pour les ordinateurs de se trouver dans des endroits frais, sec, et exempt de poussière.
Les ordinateurs portables et les ordinateurs de bureau fonctionnent très bien dans des bureaux
typiques. Ces petits ordinateurs sont refroidis par des ventilateurs internes et ne nécessitent par de
filtre à poussière spéciaux.
Plus l’ordinateur est performante plus il est susceptible de nécessiter un refroidissement spécial et
d’un dépoussiérage. Les gros ordinateurs génèrent des quantités importantes de chaleur, ce qui
demande des systèmes de climatisation spéciale pour maintenir les températures dans les plages
recommandées par le fabricant. Ils exigent également des équipements de déneigement de
poussière spéciale en raison de la quantité importante de turbulence de l'air qu'ils créent.
Il est également indispensable de vérifier périodiquement le système de ventilation car un système
de ventilation défectueux ou mal entretenu peut conduire à la mauvaise santé du personnel. La
canalisation doit également être inspectée et nettoyée si nécessaire. De même comme avec les
filtres de chauffage domestique, les filtres commerciaux devraient être changés sur une base
régulière
3.3.6 Assurance
L’assurance doit être maintenue pour couvrir les matériels informatiques et les logiciels aux coûts
de remplacement et les coûts nécessaires pour recréer les données perdues.
Toutefois la plupart des politiques d'assurance précise que la couverture s'applique aussi
longtemps que certaines procédures soient mises en œuvre. Par exemple, la politique peut exiger
de la société la mise en œuvre quotidienne, hebdomadaire ou mensuelle : des procédures de
sauvegarde pour les logiciels et données .Mais aussi s’assurer que les données soient stockées
dans un emplacement sécurisé hors site. Elle peut également préciser que tous les équipements
46
couverts doivent disposer de procédures de maintenance de routine effectuée conformément aux
spécifications du fabricant.
La police d'assurance doit être examiné pour s'assurer qu'il est en cours et qu’
il couvre tout le matériel informatique, des logiciels et des données au coût de remplacement. Il
convient également de confirmer que le montant de la couverture est suffisante pour que
l'entreprise est n’ait pas à payer pour trop ou peu à l’assurance. Ceci peut être accompli en
examinant les procédures utilisées par le gestionnaire de l'assurance afin de déterminer le montant
de la couverture nécessaire.
3.3.7 Sauvegardes périodiques
Comme mentionné dans la section sur l'assurance, des procédures doivent être en place pour
effectuer des inspections périodiques (quotidiens, hebdomadaires, mensuels), les sauvegardes du
logiciel système, les programmes d’applications, des données ainsi que le stockage et la rotation
du support de sauvegarde (par exemple : bandes magnétique, disques, disques compacts [CD]) à
un endroit sûr hors site.
Des Sauvegardes quotidiennes sont généralement nécessaires que pour les données depuis les
programmes d'application et le logiciel système ne changent pas de manière significative. Les
sauvegardes complètes du système tout entier, y compris le logiciel système, les programmes
d'application, et de données devraient être effectuée chaque semaine ou par mois, selon le nombre
et les types de changements qui ont été faits, surtout à l’issue d’une mise à jour majeure ou
d'importants changements aux paramètres opérationnels et de sécurité d'un système.
L’auditeur devrait visiter l'installation d'entreposage hors site pour évaluer l'adéquation de son
contrôle de sécurité. Si l'installation de stockage hors site est un fournisseur, le contrat devrait
être examiné pour s'assurer que le fournisseur en question s'engage à rembourser l'organisation
cliente des pertes ou des dommages qui se produisent à la suite de vol ou de disparition du support
de sauvegarde sous le contrôle du vendeur. L'auditeur doit également examiner la liste des
personnels travaillant sur le site de restauration pour s'assurer que la liste du personnel énumérés
est correct et que les employés transféré ou retraités ont été supprimés. Il est également
primordiale de tester le bon fonctionnement des sauvegardes effectuées car il se pourrait qu’il y ait
eu erreur lors de l’opération de sauvegarde ou que le disque d’enregistrement est obsolète.
47
3.3.8 Systèmes d’alimentation
Un système d'alimentation d'urgence et un système d'alimentation sans coupure devraient
être conçus dans toutes les installations de traitement de l'information.
Un système d'alimentation d'urgence se compose d'un générateur et les matériels nécessaires pour
fournir une source d’énergie électrique limitée au niveau des secteurs opérationnels critiques d'un
établissement. En cas de coupure ou de baisse critique d’énergie le système d’alimentation de
secours doit s’activer automatiquement.
Un système UPS (Uninterruptible Power Supply) consiste en un arrangement de batteries et des
composants matériels de soutien qui sont configurés pour fournir une tension continue à
l'équipement informatique. Le système UPS agit comme une protection entre la source
d'alimentation externe et l'équipement, de sorte que les pics de courant sont réduits au minimum.
En outre, en cas de perte de puissance primaire, le système UPS continue de fournir l'électricité à
l’équipement jusqu'à ce que le système d'alimentation de secours soit activé.
Lors d'une vérification de la sécurité physique à un centre de traitement de l'information,
une description du système d'alimentation d'urgence et le système UPS doit être préparé. Les
aspects clés des systèmes ont doivent être également testés. Vérifier s’ils ont été bien conçus et
fournis avec des équipements modernes et fiables.
3.3.9 Programme de reprise des activités : BRP (Business Resumption Programs)
Chaque organisation devrait avoir un programme de reprise d'activités après un événement grave à
l’encontre du SI. Ces plans sont parfois appelés programmes de reprise après sinistre mais depuis
peu les BRP sont utilisés après de événements moins graves.
Effectuée d'une manière opportune et appropriée,un BRP devrait inclure au minimum :
• La liste du personnel de toute l’organisation, y compris le contact: numéros de téléphone
(domicile, travail, téléphone cellulaire, téléavertisseur) et l'adresse résidentielle.
• Les sites, les sièges primaires et secondaires où les cadres supérieurs seront convoqués
dans le cas où une catastrophe a rendu l'emplacement du siège principal inutilisable.
• L’identification et le classement des zones opérationnelles en terme de criticité et des
risques.
• Une brève description des évènements à l’origine du BRP.
• Une brève description des opérations qui auront lieu dans chaque domaine.
48
3.3.10 Administrateur de système de sécurité de remplacement (secours)
Octroie du contrôle complet d’un système informatique à une seule personne est l’une des
faiblesses de contrôle les plus courant au sein des organisations. La direction de nombreuses
organisations ne parvient pas à admettre la nécessite et l’urgence de former de manière adéquate
un administrateur de secours. L’administrateur pourrait être impliqué dans un accident ou doit
quitter son travail de façon inattendue, ou se trouver dans un endroit injoignable.
Le résultat est qu’une personne non qualifiée n’est capable de résoudre les problèmes qui peuvent
survenir et l’organisation en question pourrait ne pas être en mesure de rétablir les opérations de
manière adéquate en temps opportun. [19]
3.4 La protection logique
Lors de la conception des systèmes de contrôle de sécurité logique, l’équipe de responsable du
projet doit d’abord être conscient des risques importants auxquels le système peut être exposé. Le
degré de risque aura un impact important sur le type, le nombre et la force des systèmes de
contrôle devant être mis en place. Un système à haut risque justifierait évidemment le temps et les
ressources pour un plus grand nombre de contrôle de sécurité solide d’un système à faible risque.
3.4.1 Conception de la sécurité logique
Les documents d’évaluation de risques effectués par les auditeurs lors de leurs missions d’audit
peuvent être des documents essentiels voire même vitale dans la conception d’un nouveau système
de sécurité. Même si les membres de l’équipe de conception comprend des représentants de touts
les départements concernés (experts dans leurs domaines respectifs). Les auditeurs sont encore les
mieux « avertis » de tous les risques potentiels que peut encourir le système et que l’équipe de
conception pourrait ne pas prendre en considération.
L’exemple le plus courant concerne la maîtrise des activités de l’administrateur du systeme qui
peut sans restriction devenir le « maître » du système. Dans ce genre de cas la responsabilité
revient à l’auditeur de prévenir le reste de l’équipe des risques que peut poser cet administrateur.
Il existe deux techniques de conception pour contrôler ce risque :
• Programmer le système pour exiger un second administrateur pour confirmer chaque opéra
tion (addition, suppression, modification,…). Ce système empêche un administrateur
d’effectuer des opérations illicites, cependant il peut causer des retards opérationnels
significatifs si les deux administrateurs ne sont pas disponibles.
49
• Programmer le système pour enregistrer tous les événements potentiels reliés à la sécurité
du système et mettre en application des procédures par lequel l’enregistrement soit passée
en revue régulièrement pour déceler les activités peu communes ou non autorisées de
préférence par le directeur de l’administrateur de sécurité. L’enregistrement de ces
événements fournirait un audit rétrospectif des activités de l’administrateur, de touts les
autres utilisateurs ainsi que tout tentatives d’intrusion venant de l’extérieur.
3.4.2 Naissance d’un nouveau système
Après la programmation et l’installation du système achevée, un administrateur de la sécurité ou
un technicien d’installation initialise un programme d’exécution pour activer le système pour la
première fois. Le système devra être programmé pour reconnaître une « ID » (Identification)
utilisateur et un mot de passe associé. L’ID utilisateur et mot de passe doit être précisés dans la
documentation du système au cas où le système doit être réinitialisé à une date ultérieure.
Le système devra être programmé pour :
• Que les mots de passe ne soient pas lisibles par l’administrateur du système de sécurité via
une application, ou dans la base de données, ou au niveau du système d’application. Pour
cela le fichier de mots de passe doit être crypté suivant un algorithme relativement sûr. Les
ID utilisateurs et mots de passes doivent rester cryptés lorsqu’ils sont transmis dans tous
les dispositifs de télécommunication et réseaux.
• Permettre à l’administrateur du système divers opérations tels que : programmer les
paramètres de sécurités, créer d’autres ID pour de nouveaux utilisateurs.
• Permettre à l’administrateur d’attribuer un mot de passe d’au moins huit caractères à
chaque nouvel utilisateur ID. D’où lors de la première utilisation de l’utilisateur : le
système l’invite à changer son mot de passe. Ce procédé permet d’empêcher
l'administrateur de la sécurité du système de connaître les mots de passe des utilisateurs(en
supposant que le mot de passe ait été correctement crypté).
3.4.3 ID et mots de passes
l’ID utilisateur et le mot de passe constituent les plus communes et les plus critiques contrôles de
la protection logique. C’est pourquoi ils sont déployés dans presque tous les systèmes
informatiques nécessitant un minimum de sécurité. Sans eux n’importe qui pourrait accéder au
système d’information et effectuer des transactions non autorisés comme : la destruction des
50
données et programmes, relâcher des virus, ajouter, modifier et supprimer des utilisateurs et les
capacités d'accès des utilisateurs, apporter des modifications non autorisées à l'exploitation du
système et paramètres de sécurité ou encore procéder à une myriade d'autres activités indésirables.
Cinq paramètres doivent être pris en compte lors de la conception du système de mots de passe :
• Longueur minimale de mots de passe : le système devrait rejeter tout utilisateur tentant
d’entrer un mot de passe avec moins de caractères que le paramétrage. Exemple : dans la
plupart des systèmes commerciaux une longueur minimale de huit caractères est suffisante.
• Période d’expiration du mot de passe : lorsque la période d'expiration du mot de passe
est écoulée, le système devrait inciter chaque utilisateur d'entrer le « vieux » mot de passe
ainsi qu'un nouveau mot de passe deux fois de suite. Pour la plupart des applications
commerciales, une période d'expiration de mot de passe de 60 jours est suffisante.
• Nombres de tentatives : si le nombre de tentative d’authentification est atteint le système
devra suspendre l’ID utilisateur, c’est-à-dire que cette ID est inutilisable jusqu'à ce qu'un
administrateur de la sécurité système réinitialise l'ID utilisateur vers un statut actif. Il s'agit
d'un excellent contrôle pour empêcher les intrus d'essayer de signer un nombre illimité de
fois. Dans la plupart des cas, la suspension des ID utilisateur se fait après trois essais
consécutifs.
• Périodes de possibilités d’authentification : le système devrait rejeter tout utilisateur qui
tente d'accéder au système pendant les périodes de la journée ou jours de la semaine qui ne
sont pas dans les paramètres. Ce contrôle permet de prévenir les tentatives d'accès non
autorisés pendant les heures non professionnelles par les personnes qui ont un accès
physique à un établissement (par exemple, un dépositaire ou agent de sécurité).
• Périodes d’inactivité autorisée : lorsqu’ un ID utilisateur a été inactif pendant la période
spécifiée dans les paramètres, le système doit enregistrer automatiquement et fermer tous
les fichiers qui sont encore actifs. Il met fin à l’application et déconnecter l’utilisateur. Elle
permet de réduire le risque d'accès non autorisé lorsque les utilisateurs quittent leur poste
de travail et qu’ils oublient ou qu’ils choisissent de ne pas se déconnecter. Une période de
temporisation des sessions de dix minutes ou moins devrait être recommandé.
Malheureusement la simple présence d'ID d'utilisateur et de mots de passe ne garantit pas qu'un
système d'information soit correctement sécurisé. Tous les contrôles de sécurité logique, y compris
51
ceux sur les ID d'utilisateur et les mots de passe, doivent être soigneusement conçues et bien
administrée pour être efficace.
3.4.4 Administration du système de sécurité
L’administration du système de sécurité est le processus par lequel le système d’information est
protégé contre les accès non autorisés, les destructions accidentelles ou intentionnelles de
l’information. Comment le présent système de sécurité est administrée après son implémentation
est aussi cruciale que la conception du système. La majorité des systèmes produits dans le
« monde réel » ont une conception qui n’est pas optimale. Dans certains cas les faiblesses dans la
conception peuvent être contrôlées par le déploiement d’autres systèmes de sécurité de fortunes
disponibles. Dans d’autres cas ces faiblesses ne peuvent être contrôlées. Alors des contrôles de
surveillances et des procédures doivent êtres implémentées pour identifier les violations potentiels
de façon opportune jusqu’à ce que le système soit reprogrammé pour prévoir ces faiblesses.
3.4.5 Fraude en ligne
De nombreux types de fraudes telles que les fraudes de prêt peuvent être couteux pour les
institutions financières. Certaines d’entres elles peuvent prendre des mois ou des années pour
atteindre des proportions importantes, tandis que d’autres exigent à l’auteur beaucoup d’effort à la
préparation des faux documents pour éviter toutes détections tout en continuant d’exercer ses
fonctions normales. Même si la fraude a été exécutée, retirer le fond en espèce est difficile à
exécuter sans se faire remarquer. Par contre les fraudes par « fil » (via le réseau informatique)
peuvent se produire instantanément avec planification préalable ou pas. Par exemple une fraude
électronique peut se produire à partir d’un utilisateur du réseau opportuniste qui constate qu’un
autre utilisateur à laisser son poste de travail sous tension et sans se déconnecter.
Ce qui rend les fraudes en lignes si risquées c’est qu’au bonheur des voleurs, les fonds sont
immédiatement disponibles pour un retrait.
Exemple : une grande banque à l’Est des Etats-Unis est à subit une perte de 1.5 million de dollars
à cause d’un ancien directeur. Il a profité de la situation lorsque la banque avait due éliminer son
système de sécurité lors d’un « downsizing » (migration du système informatique d’un système
d’information centralisé vers un réseau local de micro-ordinateurs en mode clients/serveurs).
[4][20]
52
3.4.6 La protection du réseau
3.4.6.1 Les menaces
Les menaces contre les systèmes visent essentiellement à les rendre inaccessibles ou à les altérer
profondément en performance.
Les attaques peuvent se classer en deux catégories :
• Celles qui visent à prendre connaissance des informations soit pour les exploiter soit pour
les altérer.
• Celles qui visent à paralyser voire détruire les systèmes.
Les attaques sont nombreuses ils vont de la simple usurpation de mots de passe (brute force attack
ou dictionary attack…) à l’introduction de code malicieux (virus) en passant par la mystification
du système (IP spoofing). [17][18]
3.4.6.2 La protection de l’intranet
a. Protection du réseau local en interne
Pour sécuriser le réseau local on se doit d’atteindre deux objectifs :
• Prévention contre les connexions non autorisées par le contrôle d’adresse (Associer un
port du commutateur ou hub avec une adresse MAC (Medium Access Control)) et la
désactivation les prises non utilisés.
• Assurer un cloisonnement du trafic par la constitution de VLAN (Virtual Local Area
Network).
b. Filtrage du trafic par le routeur d’accès
Le moyen le plus simple de protéger un réseau contre les intrusions est le contrôle du trafic par le
routeur d’accès.
Le routeur assure des fonctions de filtrage simple par analyse des adresses sources et destinations.
Cependant le routeur n’opère que sur les données protocolaires de niveau 3 donc ses possibilités
de filtrages sont réduis uniquement aux adresses logiques et le protocole transporté dans le
datagramme.
Les règles de filtrages sont réunies dans des listes ACL (Access Control List). Le tableau 3.01
montre un exemple de règle.
53
Action Protocol Source Destination Commentaire Accept * 195.26.10.0 195.26.11.0 Trafic sortant vers l’établissement de Diego Accept * 195.26.11.0 195.26.10.0 Trafic entrant de l’établissement de Diego Reject * * * *
Tableau 3.01: Exemple de règle de filtrage
Dans cet exemple le filtre n’accepte que deux établissement de l’entreprise, ici si la ligne 3 était en
tête de liste le routeur interdirait tout trafic.
c. La translation d’adresse
La translation d’adresse permet non seulement de contourner la pénurie d’adresse internet mais en
termes de sécurité elle permet de masquer le plan d’adressage de l’entreprise vis-à-vis de
l’extérieur (IP Masquerade).
Il existe deux types de translation :
• La traduction statique : on fait correspondre à une adresse interne du réseau une adresse
externe généralement publique. Ce mode de translation permet de masquer le plan
d’adressage local mais aussi de sécuriser le réseau en n’autorisant que certain station à
accéder à internet. Cependant elle limite le nombre de machines ayant accès à l’extérieur
au nombre d’adresses publiques attribuées.
• La traduction dynamique s’affranchit de cette limite : lorsqu’une machine veut accéder à
l’extérieure, le NAT (Network Address Translation) associe à l’adresse locale interne une
adresse globale interne, ou adresse externe choisie parmi un pool d’adresse mis à
disposition.
Cependant le nombre d’adresses publiques attribuées peut être insuffisant. Le NAPT (Network
Address and Port Translation) permet à plusieurs machines de partager une même adresse
externe par translation de numéro de port. La fonction dite du PAT (Port Address Translation)
autorise plusieurs milliers (65535) de connexions à partager le même adresse IP externe.
d. Les pare-feu (firewall)
Indépendamment des fonctions de routages et de translation d’adresse, chaque paquet reçu est
examiné et la décision d’acceptation ou de rejet est prise en fonction de nombreux critères :
• L’adresse source
• L’adresse destination
54
• Le protocole transporté (ICMP, UDP, TCP…)
• Le port destination
• Le port source
• La valeur de certains flags (SYN, ACK…)
Il existe deux différents modes d’utilisation de pare-feu :
• Le pare-feu à séparation de réseau : il segmente le réseau en deux segments, le réseau
interne et le réseau externe. Il contrôle le trafic et peut réaliser une translation d’adresses
(NAT).
• Le pare-feu au fil de l’eau : il n’effectue aucune séparation du réseau cependant comme le
pare-feu à séparation de réseau, il réalise l’isolement de trafics.
Ces deux types de pare-feu sont illustrés par la figure 3.01 ci-dessous :
Figure 3.01 : Les différents modes d’utilisation de pare-feu
La figure 3.02 illustre les différentes architectures de sécurité envisageables. La mise à disposition
d’un serveur public (service Web, messagerie...) est généralement réalisée par la constitution
d’une zone de sécurité dite DMZ (DeMilitarized Zone). Différentes zones de sécurité peuvent être
constituées, chacune accessible selon des critères spécifiques (filtres). L’utilisation de deux pare-
feu permet de renforcer cette sécurité. Le premier masque le second aux pirates éventuels. En
choisissant les deux pare-feu de marque différente, on améliore encore la sécurité, les
vulnérabilités ou failles de l’un étant différentes de celles de l’autre. La zone démilitarisée
accueillera les différents serveurs accessibles à la fois par le personnel de l’entreprise et par le
monde extérieur. Pour différencier les services offerts et les règles de filtrage, il est possible de
définir plusieurs DMZ, dans ce cas généralement l’une est accessible à tous, et l’autre aux
personnels de l’entreprise. [11]
55
Figure 3.02 : Les différents architecture de sécurité
e. Les passerelles applicatives
Elles sont aussi appelées : Application Layer Gateway ou Proxy Server. Elles effectuent une
double connexion comme le montre la figure 3.03 avec un filtrage au niveau de chaque service
offert, les services internes sont invisibles de l’extérieur.
A l’instar du pare-feu les passerelles applicatives peuvent mémoriser toutes les connexions et en
éditer la liste. Elles peuvent également réaliser des conversions de protocoles.
Figure 3.03 : Filtrage par un proxy-server
56
f. Les codes malicieux
Quelque soit leur nature les logiciels malveillants sont des programmes qui effectuent des actions
malveillantes et qui se propagent rapidement dans le monde.
Un virus est un programme « parasite » qui s’attache à un programme principal dont il modifie
l’environnement de travail avec un objectif généralement destructeur. Les programmes virus ont
aussi la possibilité de se propager de machine en machine directement avec le programme infecté
(copie de programme), mais aujourd’hui de plus en plus par exploitation du carnet d’adresses de la
machine infectée.
Les virus fonctionnent en tâche fond. Lorsqu’une certaine activité est réalisée le virus effectue la
tâche pour laquelle il a été programmé. Les virus peuvent altérer les données, les diffuser vers des
adresses aléatoires ou préprogrammées, modifier le comportement du système allant de
l’instabilité à la paralysie voire à la destruction de certains composants du système (effacement du
bios...).
Des logiciels dits antivirus permettent de se protéger des virus connus. Cependant, malgré les
mises à jour, les « pirates » ont toujours un virus d’avance. La seule parade efficace consiste à
n’échanger des données avec personne et de ne jamais raccorder son ordinateur à un réseau.
3.4.6.3 La protection des accès
Dans les premières années de l’informatique seuls les administrateurs systèmes exigeaient l’accès
à distance du système. Ordinateurs et traitements ont été centralisés et les usagers s’authentifiaient
via un terminal passif pour entrer dans le système.
Aujourd’hui les utilisateurs sont de plus en plus exigeants sur la capacité de s’authentifier à
distance en utilisant des ordinateurs portables, des assistants numériques personnels (PDA), et
certains types de téléphones cellulaires. Ils ont généralement besoin d'accéder au réseau de
l'organisation et, de là, l'accès aux différentes applications. Cette nouvelle capacité du système
permet une meilleure souplesse du système, cependant elle augmente le risque pour le réseau de
l’organisation sur les accès non autorisé, l’entrée grande ouverte des virus informatiques.
L’intrusion via ce système rend toutes les protections physiques obsolètes.
Pour aider à atténuer ces risques un certains nombres de technologies de contrôles d’accès à
distance ont été mises au points :
57
a. Les lignes spécialisées
Ce sont des lignes téléphoniques privés dans le sens que la société de télécommunication ne
permet aux parties externes d’y avoir accès. Les données entres ordinateurs circulent dans les
lignes sans opération de cryptage car il ya moins de risque d’interception.
Les lignes spécialisées louées sont chères mais elles fournissent une amélioration des
performances car il y a moins de trafic externe et il y a une réduction de la nécessité de crypter
tout le trafic interne. Un utilisateur distant doit toujours avoir à s'authentifier au réseau en utilisant
un ID utilisateur et mot de passe au minimum.
b. Le rappel automatique
C’est un témoin dans lequel le modem de l’ordinateur de l’utilisateur distant compose un numéro
de téléphone dédié pour entrer dans le réseau. L’ordinateur central contient une liste des noms
d’utilisateurs et des mots de passe. Si l’ordinateur distant fournit des informations d’identifications
suffisantes (ID et mot de passe) le système d’identification coupe la connexion et rappel le numéro
enregistré. Après succès du rappel automatique l’utilisateur distant doit encore s’authentifier sur le
réseau à l’aide d’un nom d’utilisateur et de mot de passe. Ce type de contrôle permet de prévenir
des accès non autorisé au réseau même si ceux-ci connaissent le numéro de téléphone de
l’ordinateur distant. Ce type de système est très efficace pour des utilisateurs fixes mais l’est
moins pour les utilisateurs en mouvements permanents.
c. SSL (Secure Sokets Layer)
Le SSL est un protocole qui permet une session internet crypté entre l’ordinateur distant et le
serveur du réseau. Normalement l’échange s’effectue sur le numéro de port 443 et utilise un
cryptage à clé publique. Une fois la connexion établie tous les données échangées entre les deux
interlocuteurs sont crypté symétriquement et la force du cryptage dépend de la longueur de la clé
(en général 128 bits). Bien que le SSL crypte les données entre l’ordinateur distant et le réseau il
ne peut pas distinguer que l’ordinateur en question soit autorisé d’accès au réseau ou non. Ainsi
chaque utilisateur doit toujours s’authentifier sur le réseau en utilisant un nom d’utilisateur et un
mot de passe.
58
d. Les VPNs
Les réseaux privés virtuels (VPN) assurent une session internet sécurisée entre le serveur du réseau
et l’ordinateur distant, seulement contrairement aux SSL les VPNs ont besoin pour leurs
déploiement des matériels et logiciels spécifiques. Un serveur passerelle VPN protège le serveur
du réseau et l’ordinateur distant doit posséder l’application client VPN pour établir un tunnel
(encapsulation) de communication sécurisé pour l’échange de données.
Selon le niveau de l’encapsulation, on distingue des tunnels de niveau 2 ou 3 (IPSec), trois
protocoles permettent de réaliser des tunnels de niveau 2.
• L2F (Layer 2 forwarding), d’origine Cisco est un tunnel dit opérateur, il est initialisé par le
fournisseur d’accès ISP (Internet Service Provider) et se termine chez le client par un
équipement spécifique. Le protocole L2F n’assure l’authentification de l’utilisateur qu’à la
connexion et garantit pas la confidentialité des données (pas de chiffrement).
• PPTP (Point-to-Pont Tunneling Protocol) d’origine Microsoft est une technique de tunnel
de bout en bout. La session du client PPP est transportée de bout en bout par une
encapsulation spécifique (GRE Generic Routing Encapsulation). Les datagrammes peuvent
être chiffrés par le protocole d’origine Microsoft MPPC (Microsoft Point-to-Point
enCryption).
• L2TP (Layer 2 Tunneling Protocol), d’origine IEFT, c’est un protocole opérateur, il
autorise les appels outbounds (appels initiés par l’intranet destination), il peut être
conjointement utilisé avec IPSec (Internet Protocol Security) pour chiffrer les données, l’
en-tête IP d’origine comprise.
L’ IPSec est le protocole standard dominant pour l’implémentation des VPNs.
En matière de sécurité le but de l’IPSec est de délivrer :
• Un mécanisme d’authentification pour être sûr de l’authenticité de l’identité de l’émetteur.
• Un mécanisme d’intégrité pour s’assurer que les données n’ont pas été modifiées durant
son transport entre l’émetteur et le récepteur.
• Un mécanisme de confidentialité qui s’assure que les données ne puissent être
compréhensibles que par les deux parties mis en jeu.
En ayant l’avantage d’utiliser les infrastructures internet de part le monde, s’il est bien déployé le
VPN peut fournir d’énormes économies sur le coût, une efficacité importante ainsi que d’autres
avantages pour l’organisation tels que :
59
• Les utilisateurs éloignés peuvent accéder au réseau de leur organisations sans avoir à payer
le prix des appels à longue distance afin d’éviter à l’organisation de payer de factures
exorbitantes.
• Un accès au réseau peut être fait virtuellement quelque soit la place dans le monde.
• Les VPNs peuvent être construit et démantelés durant une période très courte.
• Les VPN peuvent être construit de façon à intégrer des fonctions de cryptages complexes
et de contrôle d’authentification.
• Les VPN sont plus sûrs que les applications qui s’appuient sur le SSL sur le point de vue
sécurité.
• Les connexions sites à sites ne nécessitent plus l’utilisation des lignes louées à prix très
élevées.
3.4.7 Protection de données
3.4.7.1 Cryptographie
Le chiffrement est une technique destinée à rendre les données inintelligibles à un tiers non
autorisés. Le message en clair est codé (chiffré) à l’aide d’une clé de chiffrement et seul le
cryptogramme (message chiffré) est transmis dans le réseau. Le destinataire du message effectue
l’opération inverse à l’aide d’une clé de déchiffrement.
Les techniques de cryptographie permettent de :
• Assurer la confidentialité des données.
• Garantir l’intégrité des données.
• Authentifier l’émetteur des données.
a. Les méthodes de chiffrement symétriques
Dans les systèmes de chiffrement à clé symétrique ou secrète la clé de chiffrement et la clé de
déchiffrement sont identiques et sont convenues par avance par les deux interlocuteurs. Ces clés
sont conservées secrètes. La figure 3.04 illustre l’architecture et le fonctionnement d’un tel
système.
Ici le texte original envoyé par Alice : CESAR (clair) a été crypté en FHDU (cryptogramme) par
la clé de chiffrement, et c’est ce cryptogramme qui transit dans le réseau. A la réception la clé de
déchiffrement permet de retransformer le cryptogramme en message clair (CESAR) qui est affiché
chez Bob.
60
Figure 3.04 : Principe du système à clés symétriques
Les algorithmes utilisent deux techniques :
• La substitution : consiste à remplacer à chaque lettre du clair, une lettre de l’alphabet
obtenu par simple translation (clé secrète dans l’alphabet)
• La transposition : consiste à modifier, selon une loi prédéfinis l’ordre des caractères.
Le DES (Data Encryption Standard) d’origine IBM est l’algorithme de chiffrement le plus connu.
Il consiste en une suite de substitution (DES-S) et une suite de transposition ou permutation
(DES-P) par bloc e 64 bits. Le DES est aujourd’hui facilement cassable. Il est remplacé par le
triple DES (3DES), application de trois DES successivement avec trois clés indépendante sur le
texte en clair.
Ces types d’algorithmes demandent peu de puissance et un temps de calcul court. Cependant, la
découverte de la clé secrète donne accès à l’information. Le principal inconvénient avec les
méthodes de chiffrement symétrique est que le secret (la clé) doit être transmis d’où les risques
d’interception. Ils ne permettent également pas d’identifier l’interlocuteur distant.
b. Les méthodes de chiffrement asymétrique
Pour palier au problème de diffusion de la clé « secrète », les systèmes de chiffrement
asymétriques utilisent deux clés :
• La clé publique connue de tous.
• La clé secrète connue seulement de l’un des correspondants.
Les deux clés sont reliées mathématiquement et le message chiffré avec l’une ne peut être
déchiffré qu’avec l’autre. La figure 3.05 illustre ce mécanisme.
Figure 3.05 : Principe de la cryptographie à clé publique
61
Le système de cryptographie à clé publique la plus répandu est le RSA (Rivest, Shamiret Aldeman)
du nom de ses inventeurs, ce système repose sur l’arithmétique des grands nombres.
• La fonction de chiffrement est de la forme :
Crypte=[ClaircléC modulo n] (3.01)
Où Crypte est le message codé, Clair le message à coder, clé C la clé de chiffrement, n un
produit de nombre premiers.
La fonction de déchiffrement est identique.
Clair=[CryptecléD modulo n] (3.02)
Fondé sur la difficulté de factoriser les nombres premiers, les systèmes à clés publiques permettent
d’assurer la confidentialité des données mais aussi d’authentifier l’émetteur d’un message.
c. L’authentification de l’émetteur
Un message chiffré avec la clé publique n’est déchiffrable qu’à l’aide de la clé privée, cela assure
la confidentialité mais ne permet pas d’authentifier l’auteur du message. L’authentification de
l’émetteur peut être obtenue en chiffrant le message avec la clé secrète et en le déchiffrant avec la
clé publique.
Ce procédé ne garantit pas la confidentialité des messages. Tout possesseur de la clé publique peut
déchiffrer le message, il ne garantit que l’origine (le détenteur de la clé privée), c’est un système
de signature de messages.
d. Protocole d’échange de clés Diffie-Hellman
La cryptographie à clé publique nécessite une puissance de calcul importante. Le DES est entre
100 fois (implémentation logicielle) et 1 000 fois (implémentation hardware) plus rapide que le
RSA. Le protocole d’échange de clés de Diffie-Hellman permet de construire une clé secrète (clef
de session) sans que celle-ci circule sur le réseau. L’initiateur de l’échange transmet à ses
correspondants deux nombres grands et premiers (g, n). Les correspondants déterminent une clé
privée, tenue secrète. Chacun, à partir de g, n et de sa clé secrète (nombres aléatoires A et B)
génère une clé publique et la communique à l’autre. Puis, à partir de sa clé privée, de sa clé
publique et de la clé publique de son correspondant, calcule la clé de session, la figure 3.06 illustre
ce mécanisme.
62
Figure 3.06 : Principe de l’change de Diffie Hellman
e. Contrôle d’intégrité du message
Pour vérifier l’intégrité du message on applique une fonction dite de hachage (hash) au contenu du
message. le résulta obtenu Digest (résumé, sceau…) est joint au message à transmettre, au
destinataire il est recalculé et si le résultat est identique au digest reçu alors le message n’a pas été
altéré. Ce principe est illustré par la figure 3.07.
Figure 3.07 : Principe de détermination du « digest »
Le digest a une longeur de 128 bits (MD2 à MD5, Message Digest X définis par la RFC 1321) ou
de 160 bits (SHA-1, Secure Hash Algorithm).
f. La signature numérique d’un message
En combinant un système de cryptographie et une fonction de hachage, on peut à la fois garantir
l’intégrité du message et son authentification. MAC (Message Authentification Code).
Dans le système à signature symétrique, l’émetteur calcul le digest sur la concaténation du
message (comme dans la figure 3.08), à la réception le destinataire procède de même et si le digest
63
trouvé est identique, c’est que d’une part le message n’a pas été altéré et d’autre part : il a bien été
envoyé par l’autre possesseur de la clé partagée.
Figure 3.08 : Calcul d’une signature numérique symétrique.
Dans les systèmes à clés asymétriques, le digest est calculé sur le message puis chiffré à l’aide de
la clé privé de l’émetteur, le résultat est joint au message envoyé (comme dans la figure 3.09). A
la réception le destinataire calcule le digest du message, déchiffre le digest reçu à l’aide de la clé
publique et si le digest trouvé est identique, c’est que d’une part le message n’a pas été altéré et
d’autre par qu’il a bien été envoyé par le possesseur de la clé publique.
Figure 3.09 :
Figure 3.10 : Calcul d’une signature numérique asymétrique
Les systèmes à signature permettent d’assurer l’authentification (émetteur du message) et
l’intégrité de celui-ci (pas de modification du message). Cependant elle nécessite une puissance de
calcul supérieure et ralentit les échanges de messages.
3.4.7.2 La sécurisation des échanges
a. L’usurpation d’identité
Le problème principal de la cryptographie est la possible intervention d’une tierce personne. Par
exemple si l’entité A veut entrer en relation avec B, A doit demander sa clé publique à B. Cet
échange peut être intercepté par une entité C (un intrus malveillant). De cette manière C peut se
64
substituer à B pour les prochains échanges. Cette attaque est connue sous le nom de « man in the
middle ».
Afin d’éliminer la substitution d’identité, les clés publiques sont disponibles sur un serveur de clés
publiques (annuaire) et donc accessibles à tous les utilisateurs, encore faut-il que la relation clé
publique/possesseur soit confirmée. C’est l’intervention d’un tiers de confiance (CA, Certificate
Authority) qui garantit la correspondance entre une clé publique et son propriétaire par la
délivrance d’un certificat. Le certificat contient l’identifiant d’un utilisateur et sa clé publique, le
certificat est signé avec la clé privée de l’autorité d’authentification. L’autorité de certification
peut être interne à l’entreprise (disponible sur l’intranet) ou être un prestataire de service de
certification.
b. La PKI (Public-Key Infrastructure)
La PKI est un ensemble de protocoles et de services associés qui assurent des clés publiques.
Il doit assurer les fonctions suivantes :
• La génération des clés : il génère deux types de clés, les clés de chiffrements et les clés de
signature numérique des messages.
• L’archivage des clés et des certificats ;
• Délivrance des certificats et clés.
• Gestion des clés de révocation CRL (Certificate Revocation List).
3.5 Conclusion
Ainsi nous avons les différents problèmes de sécurité, ainsi que les différents aspects de la sécurité
comme la sécurité physique et la sécurité logique. Mais connaître les différents aspects de la
sécurité ainsi que les dispositifs qui le composent n’est pas suffisant pour effectuer un audit de
sécurité. Il est indispensable de posséder des cadres de références pour effectuer ce dernier.
Le chapitre quatre traitera en détail le CobiT, le référentiel que l’on a choisi pour effectuer l’audit.
65
CHAPITRE 4 .
CobiT (Control objectives for information and Technologies)
4.1 Introduction
Comme nous l’avons introduit dans le chapitre « un » la réalisation d’un audit de système se base
essentiellement sur un référentiel qui servira de cadre à l’auditeur lors de sa mission. Dans notre
cas nous avons choisi CobiT. Tout au long de ce chapitre nous nous intéresserons aux principes
fondamentaux de CobiT, de son apport dans la gouvernance des SI ainsi que son utilisation lors
d’une mission d’audit. Nous donnerons également des détails sur les processus qui le forment
ainsi que les différents documents et publications autour de CobiT.
4.2 Présentation générale
4.2.1 Définitions
4.2.1.1 ISACA
L’ ISACA (Information System Audit and Control Association) est implanté aux Etats-Unis, dans
l’Illinois. C’est une association internationale dont l’objectif est d’améliorer les processus et la
méthodologie des audits et des systèmes d’information.
Depuis sa création, l’ISACA effectue un nombre très important d’études et de recherches dans le
domaine de l’analyse et des méthodes de contrôle des systèmes d’information. Cette association
compte environs 50000 membres repartis dans 140 pays.
L’ AFAI (Association Française de l’Audit et du conseil Informatique) est le chapitre français de
l’ ISACA qui traduit certaines de ces publications. [6][7]
4.2.1.2 CobiT
CobiT est crée par l’ISACA en 1994. C’est le référentiel principal de gouvernance et d’audit de
système d’information. Il offre un ensemble de moyens très puissants permettant de gérer les
niveaux de contrôle devant être exercé sur les ressources IT afin que ces dernières soutiennent
efficacement la réalisation des objectifs de l’entreprise. Il part du principe que les systèmes
d’information dans une organisation doivent être conçus et mis en œuvre pour délivrer
l’information dans les conditions optimales.
66
En résumé le CobiT est un cadre de référence pour maîtriser la gouvernance des SI dans le temps,
il est fondé sur un ensemble de « bonnes pratiques » collectes auprès d’experts du SI.
Le Cobit est une approche orientée processus : les tâches et activités sont intégrées dans 34
processus établis, ces derniers sont eux-mêmes intégrés dans 4 domaines de processus. [21][22]
4.2.2 Historique
En 1994 le résultat des travaux collectifs réalisés par les principaux acteurs de la profession,
auditeurs internes et externes, fédérés au sein de l’ ISACA (Information System and Control
Association) créent les fondements du CobiT.
Dans ses premières versions, publiées à partir de 1996, CobiT se positionne comme un référentiel
de contrôle. Il décline du domaine IT du COSO (Committee of Sponsoring Organisation of the
Treadway Commisssion), pubié en 1992 et dont l’objectif est d’aider les entreprises à évaluer et à
améliorer leurs systèmes de contrôles internes.
En 1998, création de l’ITGI (Information Technology Governance Institute) par l’ISACA en
réponse à la place de plus en plus importante occupée par les technologies de l’information. En
effet dans la plupart des entreprises, l’un des principaux facteurs de succès réside dans la capacité
des systèmes d’information à apporter à la fois la différentiation stratégique et le support des
activités.
En l’an 2000 après de nombreuses années de recherche à travers de nombreux groupes de travail
répartis dans le monde entier, l’ITGI publie la version V3 du référentiel CobiT. Nouvelle version
qui propose parallèlement à un « guide d’audit », un « guide de management » préfigurant les
versions ultérieures.
En 2002, le congrès américain vote la loi Sarbanes Oxley (SOX). L’application de cette loi se
traduit par un renforcement de contrôles liés aux processus financiers, par exemple la section 404
qui exige un contrôle strict des accès et des autorisations. CobiT a été reconnu comme étant une
réponse à ces nouvelles exigences en termes de contrôle et de gouvernance.
Les dispositions réglementaires telles que SOX et ses déclinaisons : le LSF (Loi de sécurité
Financière, norme Bâle II), IFRS (International Financial Reporting Standards) ont
considérablement renforcé le rôle des auditeurs et ont accélérés la diffusion de CobiT comme
référentiel de contrôle et de gouvernance des SI, si bien que l’ISACA a publié en 2005 la version
4 puis la version 4.1 de CobiT en 2007, en regroupant deux visions : le contrôle et le management
des systèmes d’informations (SI). [21][22]
67
4.3 CobiT et l’IT gouvernance
4.3.1 L’apport de CobiT
Selon CobiT la gouvernance des SI est la responsabilité des dirigeants et du conseil
d’administration. Elle est constituée des structures, de processus de commandement et de
fonctionnement qui conduisent l’informatique de l’entreprise à soutenir les stratégies et les
objectifs de l’entreprise, et à lui permettre de les élargir ».
La figure 4.01 illustre aussi bien la responsabilité de la fonction IT sur les quatre grands domaines
de processus de CobiT (planifier et organiser, délivrer et supporter, surveiller et évaluer, acquérir
et implémenter).
Figure 4.01 : Répartition de la responsabilité de la gouvernance
Le cadre de référence CobiT facilite la mise en place d’une gouvernance des SI en :
• Etablissant un lien entre le système d’information avec les besoins des métiers, c’est
l’alignement stratégique.
• Structurant les activités informatiques selon un modèle des processus largement reconnu.
• Identifiant les principales ressources informatiques à mobiliser (infrastructures,
application, information et personnes) et à les utiliser de façon optimale.
• Définissant les objectifs de contrôle à prendre en compte afin de maîtriser les risques liés
au SI et leurs impactes sur les métiers.
• Apportant des avantages concrets au fonctionnement des processus métiers (efficacité et
efficience). [11][13]
68
4.3.2 Les cinq axes stratégiques de CobiT
En réponse à la volonté d’exercer une bonne gouvernance des SI, CobiT s’attache aux cinq axes
présentés dans la figure 4.02 ci-dessous :
Figure 4.02 : Les cinq axes stratégiques de CobiT
• Strategic Alignement (alignement stratégique)
• Value Delivery (valeur délivrée)
• Resource Management (Management des ressources)
• Risk Management (Gestion des Risques)
• Performance Measurement (Mesure de la performance)
4.4 Appréhender CobiT
En réponse aux besoins des entreprises vis-à-vis de la gouvernance et de l’audit de système
d’information le cadre de CobiT à été créé avec les caractéristiques suivantes:
• Focaliser sur le métier.
• Orienter Processus.
• Baser sur les contrôles.
69
4.4.1 Focalisation sur le métier
L’orientation opérationnelle (métier) est le thème principal de CobiT. Il n’a pas été conçu
uniquement pour être employé par les fournisseurs des services IT, les utilisateurs et les auditeurs,
mais aussi pour fournir un guide d’orientation globale pour la gouvernance et les processus
propres aux métiers.
Afin de fournir les informations dont l’entreprise a besoin pour atteindre ses objectifs, l’entreprise
en question a besoin de gérer, de contrôler et d’investir dans les ressources informatiques en
utilisant un ensemble structuré de processus pour fournir les services nécessaires qui délivreront
les informations nécessaire à l’entreprise. Ce principe est illustré par la figure 4.03.
Figure 4.03 : Principe de CobiT
4.4.1.2 Critères de l’information
Pour satisfaire les objectifs opérationnels de l’entreprise, CobiT prend en compte une riche
segmentation de l’information selon des critères précis. Ces critères correspondent aussi bien au
point de vue de l’auditeur qu’à celui du manager :
• Efficacité : c’est la mesure par laquelle l’information contribue au résultat des processus
métier par rapport aux objectifs fixés. Qualité et pertinence de l’information, distribution
cohérente.
• Efficience : c’est la mesure par laquelle l’information contribue au résultat des processus
métier au meilleur coût, c'est-à-dire la rapidité de délivrance.
• Confidentialité : C’est mesure de la protection de l’information contre la divulgation.
70
• Intégrité : c’est la mesure de l’exactitude de l’information.
• Disponibilité : c‘est la mesure de l’accessibilité et disponibilité l’information à la
demande.
• Conformité : c’est la mesure par laquelle les processus sont en conformité avec les lois,
les règlements et les contrats.
• Fiabilité : c’est la mesure de l’exactitude des informations transmises par le management.
4.4.1.3 Objectifs métier et architecture informatique
Pour que le Système d’information délivre des services pour supporter la stratégie de l’entreprise,
il doit y avoir une description claire des objectifs métiers (par le client) et une bonne
compréhension de « ce qui doit être délivré » par le Système d’information (par le fournisseur). La
figure 2.04 illustre comment la stratégie de l’entreprise (Enterprise Strategy) doit être transcrite
par le métier en objectifs relié aux Technologies de l’information (Business goals for IT). Ces
objectifs définissent les objectifs IT (IT goals) qui à leur tour définissent les ressources IT
(enterprise erchitecture for IT) nécessaires pour bien assurer la part du travail de l’IT dans la
stratégie de l’entreprise.
Figure 4.04 : Définition des objectifs informatiques et de l’architecture du système d’information
71
4.4.1.4 Les ressources informatiques
De la complexité des moyens informatiques, à laquelle les responsables de systèmes d’information
doivent faire face, une segmentation des ressources informatiques devient une nécessitée. Le
CobiT établit quatre catégories de ressources IT dans le cadre de management de systèmes
d’informations :
• Les applications : ce sont les systèmes automatisés et procédures de traitement des
informations.
• Les infrastructures : c’est l’ensemble des technologies et équipements (serveurs, sgbd,
réseau etc.) qui permettent le traitement des applications.
• Les personnes : ce sont les ressources humaines (technicien et ingénieurs) en charge du
management du système d’information.
• Les informations : ce sont les données relatives à l’activité inséré ou fournie par le SI.
4.4.2 Orienté processus
CobiT définis les activités informatiques dans un modèle de processus générique reparti en quatre
domaines :
• Planifier et organiser (PO)
• Acquérir et implémenter (AI)
• Délivrer et supporter (DS)
• Surveiller et évaluer (SE)
Le cadre de COBIT fournit un modèle de processus de référence et un langage commun
qui permet à chaque individu travaillant dans l’entreprise de visualiser et de gérer les activités
liées au système d’information. Intégrer un modèle d'exploitation et un langage commun pour
toutes les parties métier impliqués dans le Système d’Information est l'une des étapes les plus
importantes vers une bonne gouvernance.
CobiT fournit également un cadre pour la mesure et le suivi de la performance, la communication
avec les fournisseurs de services et l'intégration des meilleures pratiques de gestion.
Ces quatre domaines sont reliés entre eux comme le montre la figure 2.05 :
72
Figure 4.05 : Les quatre domaines de CobiT
4.4.2.2 Planifier et organiser
Ce domaine décrit les tactiques et les stratégies permettant d’optimiser la contribution des SI à
atteindre les objectifs métiers de l’entreprise. La réalisation de la vision stratégique doit être
planifiée, communiquée, et gérée suivant des points de vues différentes pour qu’une bonne
organisation ainsi qu’une infrastructure technologique cohérente soient mises en place.
Ce domaine porte généralement sur les questions suivantes :
• Le système d’information et la stratégie opérationnelle sont-ils alignés ?
• L’entreprise exploite-t-elle les ressources informatiques de façon optimale ?
• Toutes les personnes présentes dans l’organisation comprennent-elles les objectifs
informatiques ?
• Est-ce-que les risques sont définis et géré de façons appropriés ?
• La qualité du système d’information est-elle appropriée pour répondre aux besoins
opérationnels de l’organisation.
Les processus de ce domaine sont les suivants :
• PO1- Définir un plan informatique stratégique.
• PO2- Définir l’architecture de l’information.
• PO3- Déterminer l’orientation technologique
• PO4- Définir le processus, l’organisation et l’orientation de travail.
• PO5- Gérer les investissements informatiques.
73
• PO6- Faire connaître les buts et les orientations du management.
• PO7- Gérer les ressources humaines du système d’information.
• PO8- Gérer la qualité.
• PO9- Evaluer et gérer les risques.
• PO10- Gérer les projets.
4.4.2.3 Acquérir et implémenter
Les processus décrits dans ce domaine traitent de l’identification, du développement ou de
l’acquisition des solutions informatiques, de leurs mises en œuvre et de leur intégration aux
processus métiers, ainsi que de la modification et de la maintenance des systèmes existants.
Les processus de ce domaine sont les suivants :
• AI1- Trouver des solutions informatiques.
• AI2- Acquérir des applications et en assurer la maintenance.
• AI3- Acquérir une infrastructure technique et en assurer la maintenance.
• AI4- Faciliter le fonctionnement et l’utilisation.
• AI5- Acquérir des ressources informatiques.
• AI6- Gérer les changements.
• AI7- Installer et valider des solutions et des modifications.
4.4.2.4 Délivrer et supporter
Ce domaine concerne la mise en œuvre des services : exploitation informatique, gestion de la
sécurité, gestion de la continuité de service, assistance aux utilisateurs, gestion des données et des
équipements.
Les principales questions relatives à ce domaine sont les suivants:
• Est-ce-que les services informatiques sont-ils délivrés en conformité avec les besoins
métiers ?
• Les coûts informatiques sont-ils optimisés ?
• La min d’œuvre est-elle capable d’utiliser les systèmes informatiques de manière
productive et en toute sécurité ?
74
• D’adéquats systèmes de confidentialité, d’intégrité et de disponibilité de l’information
sont-ils en place pour la sécurité ?
Les processus de ce domaine sont les suivants :
• DS1- Définir et gérer les niveaux de services.
• DS2- Gérer les services tiers.
• DS3- Gérer la performance et la capacité.
• DS4- Assurer un service continu.
• DS5- Assurer la sécurité des systèmes.
• DS6- Identifier et imputer les coûts.
• DS7- Instruire et former les utilisateurs.
• DS8- Gérer le service d’assistance aux clients et les incidents.
• DS9- Gérer la configuration.
• DS10- Gérer les problèmes.
• DS11- Gérer les données.
• DS12- Gérer l’environnement physique.
• DS13- Gérer l’exploitation.
4.4.2.5 Surveiller et évaluer
Les processus décrits dans ce chapitre traitent de la gestion de la performance, de la surveillance
du contrôle interne, du respect de normes réglementaire et de la gouvernance.
Les principales questions relatives à ce domaine sont les suivants:
• Les problèmes de performance des systèmes informatiques sont-ils identifiés avant qu’il ne
soit trop tard ?
• La direction s’assure-t-elle que les contrôles internes sont efficaces et efficients ?
Les processus de ce domaine sont les suivants :
• SE1- Surveiller et évaluer la performance des SI.
• SE2- Surveiller et évaluer le contrôle interne.
• SE3- S’assurer de la conformité aux obligations externes.
75
• SE4- Mettre en place une gouvernance des SI. [23][24][25][26]
La figure 4.06 présente l’organisation du référentiel CobiT où sont figurés tous les 34 processus.
Figure 4.06 : Organisation du référentiel CobiT
76
4.4.3 Basé sur les contrôles
Les contrôles sont définis comme étant la politique, les procédures, et l’organisation structurelle
désigné pour s’assurer que les objectifs métier soient bien atteints et que les évènement
«indésirables » sont prévenus, détectés , et corrigés.
Les contrôles objectifs fournissent un ensemble complet d’exigence de haut niveau à prendre en
considération par la direction pour le contrôle effectif de chaque processus IT. Ils sont :
• Les rapports des actions de gestion pour accroître la valeur et réduire le risque.
• L’ensemble de la politique, des procédures, des pratiques et de la structure
organisationnelle.
• L’assurance que les objectifs métiers sont atteints et que les évènements indésirables sont
évités détectés et corrigés.
CobiT définit des contrôles pour chacun des 34 processus aussi bien des processus globaux que les
contrôles d’applications.
Pour mieux comprendre le fonctionnement de ces contrôles nous utiliserons l’exemple suivant :
Soit un refroidissement une fois que la température (standard) du système de refroidissement
(processus) est paramétrée, le système vérifie continuellement (comparaison) la température de la
salle (conformation de contrôle) et signal (action) le système de refroidissement de diminuer ou
augmenter la température. La figure 4.07 ci-dessous représente schématiquement ce processus de
contrôle.
Figure 4.07 : Modèle de contrôle
77
4.5 Le cube CobiT
En résumé, les ressources sont gérées par les processus pour atteindre les objectifs informatiques
qui répondent aux besoins de l'entreprise. Il s’agit du principe de base du cadre COBIT illustré le
cube COBIT, figure 4.08.
Figure 4.08 : Le cube CobiT
4.6 CobiT et l’audit de système d’information
CobiT a été et reste le référentiel d’audit de la gouvernance des SI. Son utilisation dans les
missions d’audit est quasi immédiate grâce à sa structure de base, aux nombreuses publications
qui viennent détailler encore les objectifs de contrôle et aux outils proposés sur le marché pour
automatiser les contrôles.
4.6.1 Le code professionnel d’éthique
L’ISACA a établi un code professionnel d’éthique pour cadrer les interventions d’audit de ses
membres. Il s’applique à tous les auditeurs certifiés CISA (Certified Information Systems Auditor),
lesquels s’engagent à respecter les points suivants :
78
• Soutenir la mise en œuvre et encourager la conformité aux standards, aux procédures et
aux contrôles appropriés pour les systèmes d’information.
• Remplir leurs devoirs avec la diligence et la conscience professionnelle appropriées, en
accord avec les standards professionnels et les bonnes pratiques.
• Servir l’intérêt des parties prenantes de manière licite et honnête, tout en observant une
conduite exemplaire, sans s’impliquer dans des actes qui pourraient discréditer la
profession.
• Protéger la propriété et la confidentialité des informations recueillies lors de leurs
missions, à moins qu’une communication ne soit requise par une autorité légale. Ces
informations ne seront pas utilisées pour en tirer un bénéfice personnel, ni communiquées
à des tiers non autorisés.
• Maintenir leur compétence à niveau dans leurs domaines respectifs, et accepter
d’entreprendre uniquement les activités que leur compétence professionnelle permettra de
raisonnablement mener à bien.
• Informer les parties appropriées des résultats des travaux effectués, en communiquant tous
les faits significatifs à connaître.
• Contribuer à la formation des parties prenantes en améliorant leur compréhension de la
sécurité et du contrôle des systèmes d’information.
Cette charte place l’auditeur devant ses responsabilités, lesquelles seront d’autant plus faciles à
respecter qu’il aura une indépendance complète par rapport au périmètre de l’audit. [2]
4.6.2 La mission d’audit
Une mission d’audit part d’une lettre de mission fixant le périmètre de l’audit et les responsabilités
attribuées. Ensuite, l’auditeur doit construire un référentiel d’audit qui établira une transparence
totale entre la mission confiée et les investigations à mener.
CobiT est utilisé comme une base solide de points de contrôle, il permet de sélectionner les
processus critiques et de les évaluer. Il est parfois nécessaire de le compléter en fonction des
spécificités du sujet (pour un audit de sécurité, il conviendra, par exemple, d’ajouter les aspects
propres aux dispositifs de sécurité existants ; il en sera de même pour tout ce qui a trait au
domaine légal et réglementaire). Enfin, CobiT permet à des auditeurs non informaticiens de mener
de façon professionnelle des audits informatiques intégrés aux audits généraux.
79
Les objectifs de contrôle de CobiT constituent une excellente base pour préparer un référentiel
d’audit. Il suffit ensuite, au cas par cas, de les étoffer de tests détaillés en fonction de la spécificité
du périmètre à auditer (ils sont parfois décrits dans des publications spécialisées publiées par
l’ISACA).
4.6.3 L’apport de CobiT
La structure de CobiT offre à l’auditeur une classification très solide :
• Domaines, processus, objectifs de contrôle.
• Critères d’information (efficacité, efficience, confidentialité, intégrité, disponibilité,
conformité et fiabilité).
• ressources (applications, infrastructure, information et personnes).
À cette structure se rattache un détail « générique » pour chaque objectif de contrôle, présenté
comme suit dans le document IT Assurance Guide: Using CobiT :
Objectif de contrôle Inducteur de valeur Inducteurs de risques
Tableau 4.01: représentaion des ojectifs de contrôles
Cette notion de valeur liée à un objectif de contrôle est tout à fait intéressante puisqu’elle étend le
périmètre du contrôle, en incluant non seulement la maîtrise des risques, mais aussi la création de
valeur. [13]
4.6.4 Le contrôle interne
La loi Sarbanes-Oxley et ses déclinaisons, IFRS (International Financial Reporting Standards) et
LSF (Loi sur la sécurité financière), ont mis l’accent sur le contrôle interne et les responsabilités
des dirigeants. Le président de toute société anonyme doit présenter un rapport sur les procédures
de contrôle interne mis en place. Les entreprises ont donc l’obligation de rendre compte des
procédures de contrôle interne et, à ce titre, le système d’information est concerné à trois niveaux :
• la prise en compte de l’informatique comme domaine de gouvernance de l’entreprise.
• les contrôles propres à la fonction informatique, y compris les procédures de sécurité.
• l’insertion de contrôles « embarqués » dans les processus automatisés.
80
Le guide IT « Control Objectives for Sarbanes-Oxley, 2nd édition » peut servir de base à une
approche détaillée de l’évaluation du contrôle interne du système d’information. Il s’appuie sur
CobiT et liste les objectifs de contrôle de la fonction informatique ainsi que les principales
applications informatiques qui supportent les processus de l’entreprise.
4.7 Les limites de CobiT
Même si CobiT est à l’origine un référentiel issu du monde du contrôle interne, il n’a pas pour
vocation de servir de référentiel de certification selon une approche de conformité à des exigences
réglementaires ou contractuelles comme l’ISO 9001, ou d’évaluation de processus comme
l’approche CMMI. En revanche, les objectifs de contrôle de CobiT sont largement utilisés pour
répondre aux exigences de certification ou de contrôle interne comme SOX, Bâle II.
CobiT ne propose pas de modèle de maturité étagé pour une évaluation de la direction des
systèmes d’information. Ainsi, aucun ordre de priorité de mise en œuvre des processus n’est
proposé. CobiT ne propose pas une organisation spécifique liée à la gouvernance des systèmes
d’information d’une entreprise comme le proposent les normes de système de management pour la
filière qualité.
CobiT ne propose pas non plus un enchaînement des activités propres à modéliser les processus de
maîtrise des SI de l’entreprise comme c’est le cas avec ITIL pour la fourniture et le soutien des
services. CobiT ne va pas régler la question de la bonne communication entre la DSI
et les parties prenantes.
Enfin, CobiT n’est pas un outil de conduite de changement miraculeux qui diffuserait une culture
de la mesure de la performance et de l’amélioration. En revanche, son déploiement peut aider le
management à mener une action de changement simultanément.
4.8 Les documents et les publications autour de CobiT
Il existe de très nombreux travaux de recherches et des publications autour de CobiT. Certains
sont particulièrement importants pour compléter le référentiel.
CobiT est organisé en trois niveaux pour appuyer la direction et la fonction conseil, les métiers et
le management des SI ainsi que la gouvernance, la sécurité et le contrôle. Cette organisation des
guides liées au CobiT est représentée par la figure 4.09. Chacun de ces guides est disponible au
sein de l’ISACA sur le site web www.ISACA.org ou de l’AFAI www.AFAI.org en version pdf,
parfois un document peut comporter plusieurs de ces guides. [1]
81
Figure 4.09 : Les différentes publications liées à CobiT
4.9 Conclusion
CobiT est le référentiel incontournable de l’audit de la gouvernance des systèmes d’information.
Sa structure, ses objectifs de contrôle détaillés, les travaux incessants de recherche et les
publications associées en font un outil vivant et reconnu. Cependant il n’a pas pour but de servir
de référentiel de certification selon une approche de conformité à des exigences réglementaires ou
contractuelles comme l’ISO 9001, ou d’évaluation de processus comme l’approche CMMI.
82
CHAPITRE 5
REALISATION
5.1 Introduction
Dans les chapitres précédents les études théoriques nous ont permis de comprendre le
fonctionnement, les différents types et les normes d’audit de sécurité. Elles nous ont également
donné une brève introduction sur les différents dispositifs de sécurité pouvant être rencontré lors
d’un audit.
Ce chapitre a pour but la présentation de «ISAudit», le fonctionnement de ce logiciel et les
différentes possibilités qu’il offre. Logiciel que l’on a codé avec le langage Java en utilisant la
base de donnée Derby.
5.2 Analyse et conception
Le logiciel suit le principe suivant :
• Un audit ne peut s’effectuer que sur une entreprise bien déterminée.
• Chaque entreprise est divisée en plusieurs secteurs : utilisateurs, réseau, protection de
données, protection physiques,....
• Chaque secteur possède plusieurs dispositifs de sécurité que l’on va évaluer.
• A chaque dispositif est associé une ou plusieurs questions qui permettront à l’auditeur
d’affiner son évaluation.
• Une recommandation concerne une entreprise donnée sur un dispositif spécifique.
• On attribue une note à un dispositif après chaque évaluation tout en tenant compte que
cette évaluation concerne une entreprise particulière.
D’où le MCD (Modèle Conceptuel de Données) représenté par la figure 5.01
83
Figure 5.01 : MCD
84
5.3 Fonctionnement
Le logiciel est divisé en deux parties distinctes :
• Le paramétrage.
• L’audit.
5.3.1 Fenêtre principale
La figure 5.02 représente la fenêtre principale de l’application
Figure 5.02 : Fenêtre principale
5.3.2 Le paramétrage
Puisque le logiciel traite essentiellement sur les trois entités suivantes
• Entreprise
• Dispositif
• Questionnaire
Il est nécessaire et primordiale de permettre à l’utilisateur d’effectuer l’opération de bases tels
que : ajouter, modifier, supprimer, lister, … sur ces entités. «
5.3.2.1 La gestion des entreprise
Lorsqu’on clique sur le bouton «
La fenêtre «ListerEntreprise» apparaît, fenêtre qui présente un tableau affichant les différentes
entreprises présentes ainsi que des boutons permettant des opérations sur la base de données. La
figure 5.03 nous montre cette fenêtre «
Figure 5.03 :
85
Puisque le logiciel traite essentiellement sur les trois entités suivantes :
Il est nécessaire et primordiale de permettre à l’utilisateur d’effectuer l’opération de bases tels
pprimer, lister, … sur ces entités. « ISAudit » offre cette possibilité.
La gestion des entreprise
Lorsqu’on clique sur le bouton « entreprise »
La fenêtre «ListerEntreprise» apparaît, fenêtre qui présente un tableau affichant les différentes
entreprises présentes ainsi que des boutons permettant des opérations sur la base de données. La
figure 5.03 nous montre cette fenêtre « ListerEntreprise ».
Figure 5.03 : Gestions des entreprises
Il est nécessaire et primordiale de permettre à l’utilisateur d’effectuer l’opération de bases tels
» offre cette possibilité.
La fenêtre «ListerEntreprise» apparaît, fenêtre qui présente un tableau affichant les différentes
entreprises présentes ainsi que des boutons permettant des opérations sur la base de données. La
5.3.2.2 La gestion des dispositifs
Tout comme la gestion des entreprises on obtient la fenêtre «
bouton présent sur la fenêtre principale
La seule différence entre les deux fenêtres est que
par le secteur auquel appartient le dispositif car comme ce qui était dit dans la conception
dispositif appartient à un secteur.
D’où la disposition de la fenêtre «ListerDispositif
86
La gestion des dispositifs
Tout comme la gestion des entreprises on obtient la fenêtre « ListerDispositif
bouton présent sur la fenêtre principale :
La seule différence entre les deux fenêtres est que pour lister les dispositifs on est obligé de passer
par le secteur auquel appartient le dispositif car comme ce qui était dit dans la conception
dispositif appartient à un secteur.
D’où la disposition de la fenêtre «ListerDispositif » présenté par la figure 5.04
Figure 5.04 : Gestion des dispositifs
ListerDispositif » en cliquant sur un
pour lister les dispositifs on est obligé de passer
par le secteur auquel appartient le dispositif car comme ce qui était dit dans la conception : chaque
r la figure 5.04
5.3.2.3 La gestion des questionnaires
Sans question à poser l’auditeur est dans l’incapacité d’évaluer la performance d’un dispositif de
sécurité. On peut accéder à la lites des questions avec le bouton
la fenêtre principale.
La liste des questionnaires est un peut différent car comme on l’a expliqué dans la partie analyse
et conception : une question doit porter sur un dispositif donné et un dispositif peut posséder un ou
plusieurs questions or chaque dispositif est relié à un et un seul secteur. D’où la d
fenêtre qui dispose d’un combobox de secteur qui permet de lister chaque dispositif dans une liste
et à chaque dispositif que l’on sélectionne dans la liste on obtient les questions relatif dans un
tableau. La figure 5.05 est une image de
suppression, de modification et un bouton quitter.
Figure 5.05 :
87
La gestion des questionnaires
Sans question à poser l’auditeur est dans l’incapacité d’évaluer la performance d’un dispositif de
sécurité. On peut accéder à la lites des questions avec le bouton «question
t un peut différent car comme on l’a expliqué dans la partie analyse
: une question doit porter sur un dispositif donné et un dispositif peut posséder un ou
plusieurs questions or chaque dispositif est relié à un et un seul secteur. D’où la d
fenêtre qui dispose d’un combobox de secteur qui permet de lister chaque dispositif dans une liste
et à chaque dispositif que l’on sélectionne dans la liste on obtient les questions relatif dans un
tableau. La figure 5.05 est une image de cette fenêtre avec les différents boutons d’ajout, de
suppression, de modification et un bouton quitter.
Figure 5.05 : Gestion des questionnaires
Sans question à poser l’auditeur est dans l’incapacité d’évaluer la performance d’un dispositif de
» également présent sur
t un peut différent car comme on l’a expliqué dans la partie analyse
: une question doit porter sur un dispositif donné et un dispositif peut posséder un ou
plusieurs questions or chaque dispositif est relié à un et un seul secteur. D’où la disposition de la
fenêtre qui dispose d’un combobox de secteur qui permet de lister chaque dispositif dans une liste
et à chaque dispositif que l’on sélectionne dans la liste on obtient les questions relatif dans un
cette fenêtre avec les différents boutons d’ajout, de
5.3.3 L’audit
On peut effectuer l’audit proprement dite en cliquant sur le bouton «
principale :
Pour pouvoir effectuer l’opération d’audit il fau
après le clic sur le bouton auditer une fenêtre contenant la liste des entreprise présent dans la base
apparaît, cette fenêtre est étrangement similaire à «
5.06
Figure 5.06 :
Après sélection de l’entreprise à auditer en cliquant sur le bouton «
redirigé vers une fenêtre dit de «
dispositifs : c'est-à-dire de sélectionner uniquement les dispositifs présents dans l’entreprise à
auditer
88
On peut effectuer l’audit proprement dite en cliquant sur le bouton «
r pouvoir effectuer l’opération d’audit il faut d’abord connaître l’entreprise à auditer d’où
après le clic sur le bouton auditer une fenêtre contenant la liste des entreprise présent dans la base
apparaît, cette fenêtre est étrangement similaire à « ListerEntreprise » comme l’indique la figure
Figure 5.06 : Choix de l’entreprise à auditer
Après sélection de l’entreprise à auditer en cliquant sur le bouton « suivant
redirigé vers une fenêtre dit de « Choixdispositif ». Fenêtre qui lui permettra de faire un filtre des
dire de sélectionner uniquement les dispositifs présents dans l’entreprise à
auditer » de la fenêtre
d’abord connaître l’entreprise à auditer d’où
après le clic sur le bouton auditer une fenêtre contenant la liste des entreprise présent dans la base
» comme l’indique la figure
suivant », l’ « auditeur » est
ttra de faire un filtre des
dire de sélectionner uniquement les dispositifs présents dans l’entreprise à
89
L’audit de chaque dispositif se fait dans la fenêtre suivante (figure 5.07):
Figure 5.07 : Fenêtre d’audit
Cette fenêtre est divisée en trois parties :
• Partie 1 : la liste des questions relatif au dispositif sélectionné dans la fenêtre principale.
On fait passer les questions les unes après les autres grâce aux boutons de navigations
(figure 5.08)
Figure 5.08 : Boutons de navigation
• Partie 2 : l’évaluation du dispositif
On attribue une note entre 0 et 100 au dispositif audité et avec la connaissance de la
catégorie de l’entreprise auditée on obtient le niveau du dispositif selon la catégorie de
cette entreprise. Les dispositifs son
o Très élevée
o Elevée
o Moyenne
o Faible
o Très faible
• Partie 3 : la recommandation
C’est l’une des phases les plus cruciales d’un audit, après l’évaluation de l’état des lieux,
l’auditeur devra donner des recommandations aux différents res
permettre d’effectuer des améliorations du système. Dans le présent logiciel
l’ « auditeur » rédigera ses recommandations dans un «
recommandation.
5.3.4 La consultation
Cette partie : accessible par le bouton «
Elle permet d’afficher le résultat d’audit (niveau et recommandation) de chacun des dispositifs
pour chaque entreprise audité précédemment. La figure 5.08 montre la utilisé dans cette
fonctionnalité.
Après le clic sur le bouton « dispositif
On est redirigé vers une autre fenêtre (figure ) qui affiche une liste des dispositifs audité ainsi que
les recommandations associés.
90
: l’évaluation du dispositif :
On attribue une note entre 0 et 100 au dispositif audité et avec la connaissance de la
catégorie de l’entreprise auditée on obtient le niveau du dispositif selon la catégorie de
cette entreprise. Les dispositifs sont notés en cinq niveaux
: la recommandation
C’est l’une des phases les plus cruciales d’un audit, après l’évaluation de l’état des lieux,
l’auditeur devra donner des recommandations aux différents res
permettre d’effectuer des améliorations du système. Dans le présent logiciel
» rédigera ses recommandations dans un « TextField
: accessible par le bouton « consulter »
Elle permet d’afficher le résultat d’audit (niveau et recommandation) de chacun des dispositifs
pour chaque entreprise audité précédemment. La figure 5.08 montre la utilisé dans cette
dispositif »
On est redirigé vers une autre fenêtre (figure ) qui affiche une liste des dispositifs audité ainsi que
les recommandations associés.
On attribue une note entre 0 et 100 au dispositif audité et avec la connaissance de la
catégorie de l’entreprise auditée on obtient le niveau du dispositif selon la catégorie de
C’est l’une des phases les plus cruciales d’un audit, après l’évaluation de l’état des lieux,
l’auditeur devra donner des recommandations aux différents responsables afin de leur
permettre d’effectuer des améliorations du système. Dans le présent logiciel
TextField » sur le panneau
Elle permet d’afficher le résultat d’audit (niveau et recommandation) de chacun des dispositifs
pour chaque entreprise audité précédemment. La figure 5.08 montre la utilisé dans cette
On est redirigé vers une autre fenêtre (figure ) qui affiche une liste des dispositifs audité ainsi que
91
Figure 5.09 : Fenêtre consultation
Figure 5.10 : Fenêtre niveau et recommandation de chaque dispositif
92
En cliquant sur le « Combobox » de la fenêtre principale qui contient la liste des entreprises déjà
audité on obtient :
• La liste des dispositifs ainsi que leur niveau respectifs suivant des codes couleurs :
o Vert pour très élevée.
o Bleu pour élevée
o Gris pour moyenne
o Orange pour faible
o Rouge pour très faible
• Le niveau respectif de chaque secteur déduit des niveaux des dispositifs composant ce
secteur (comme le montre la figure 5.11 suivant)
Figure 5.11 : Résulta de l’entreprise «Test »
93
5.4 Conclusion
Toutes ces fonctionnalités fond de « f » un outil très efficace lors d’un audit de sécurité d’un
système d’information. Il est plus ou moins exhaustif sur la liste des dispositifs et des
questionnaires et est très facile à utiliser. Cependant il est incomplet car un bon logiciel d’audit ne
devrait pas se limiter à l’étude de la sécurité mais propose à l’utilisateur des options qui
définissent le périmètre d’audit (audit de qualité, audit financier,…).
94
CONCLUSION
L’application d’un audit de sécurité des systèmes d’information permet aux différents dirigeants
de déceler les différents points faibles ainsi que tous les points forts des dispositifs de sécurité mis
en place dans l’organisation. Les différentes recommandations dans le rapport d’audit permettent
d’améliorer le niveau de sécurité pour les perspectives à venir de l’organisation auditée.
Ce travail consiste à donner une définition et une base solide à la notion d’audit de sécurité ainsi
que toutes les référentielles utilisés par les auditeurs comme : le CobiT, CMMI,etc.. , les normes
utilisées comme les normes de l’ISO sur la sécurité des systèmes d’information.
Il consiste également à donner une vague notion de la gouvernance des systèmes d’information :
les origines des lois de sécurité financière comme SOX et LSF et des détails sur les cinq grands
domaines de l’IT gouvernance.
Dans la troisième partie du livre on a rencontré une étude plus ou moins détaillées de la notion de
sécurité de système d’information tel que les différents problèmes de la sécurité, la protection
physique et la protection logique et une description plus ou moins générale de la protection du
réseau et de la cryptographie.
Enfin une brève description du référentiel CobiT, sa fonctionnalité, les différents processus qui le
composent, ses avantages et ses limites ainsi que les différents publications autour de ce dernier.
La finalité de ce présent mémoire est l’élaboration d’un logiciel permettant d’évaluer un à un tous
les dispositifs de sécurité présent dans l’entreprise suivant la catégorie de ce dernier, le logiciel
retourne également toutes les recommandations relatives à chaque dispositif audité.
Cependant l’étude effectuée au cour de ce travail ne porte que sur la sécurité des systèmes
d’information, ce qui est très insuffisant si l’on veut cerner toute la richesse de la discipline
d’audit. Pour pouvoir optimiser le fonctionnement d’une entreprise il est nécessaire de prendre en
considération plusieurs domaines par exemple : l’organisation, la qualité, les finances….
Ainsi pour compléter ce travail, des études détaillées sur ces domaines encore inexplorés devront
faire l’objet d’étude et de recherche voire un autre sujet de mémoire.
95
ANNEXES
ANNEXE 1 CODE JAVA : fenêtre principale
package memoire;
import java.awt.Cursor;
import javax.swing.ImageIcon;
import javax.swing.JButton;
import javax.swing.JOptionPane;
public class Auditprin extends javax.swing.JFrame {
/** Creates new form Auditprin */
public Auditprin() {
initComponents();
//propriete de JFrame
this.setResizable(false);
this.setLocation(200,50);
//creation des bouttons
btEntreprise.setToolTipText("Gestion des entreprises");
btEntreprise.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
btDispositif.setToolTipText("Gestion des dispositifs");
btDispositif.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
btQuestionnaire.setToolTipText("Gestion des questionnaraires");
btQuestionnaire.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
btAuditer.setToolTipText("Auditer");
btAuditer.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
btConsultation.setToolTipText("Consultation des reslutas");
btConsultation.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
btQuitter.setToolTipText("Quitter l'application");
btQuitter.setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
96
/** This method is called from within the constructor to
* initialize the form.
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor.
*/
@SuppressWarnings("unchecked")
private void btEntrepriseActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
new ListerEntreprise().setVisible(true);
//.setv;
}
private void btDispositifActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
new ListerDispositif().setVisible(true);
}
private void btQuestionnaireActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
new ListerQuestion().setVisible(true);
}
private void btAuditerActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
new AduitEnt().setVisible(true);
}
private void btConsultationActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
new Consulter().setVisible(true);
}
97
private void btQuitterActionPerformed(java.awt.event.ActionEvent evt) {
String a = null;
// TODO add your handling code here:
if (JOptionPane.showConfirmDialog(this, "Voulez vous vraiment quitter l'application",
"exit", JOptionPane.YES_NO_OPTION)==JOptionPane.YES_OPTION) {
this.setDefaultCloseOperation(this.EXIT_ON_CLOSE);
this.setVisible(false);
}
}
/**
* @param args the command line arguments
*/
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new Auditprin().setVisible(true);
}
});
}
// Variables declaration - do not modify
private javax.swing.JButton btAuditer;
private javax.swing.JButton btConsultation;
private javax.swing.JButton btDispositif;
private javax.swing.JButton btEntreprise;
private javax.swing.JButton btQuestionnaire;
private javax.swing.JButton btQuitter;
private javax.swing.JLabel jLabel1;
private javax.swing.JLabel jLabel3;
private javax.swing.JLabel jLabel4;
private javax.swing.JLabel jLabel5;
98
private javax.swing.JLabel jLabel6;
private javax.swing.JLabel jLabel7;
private javax.swing.JLabel jLabel8;
private javax.swing.JList jList1;
private javax.swing.JList jList2;
private javax.swing.JList jList3;
private javax.swing.JList jList4;
private javax.swing.JList jList5;
private javax.swing.JList jList6;
private javax.swing.JPanel jPanel1;
private javax.swing.JPanel jPanel10;
private javax.swing.JPanel jPanel11;
private javax.swing.JPanel jPanel2;
private javax.swing.JPanel jPanel3;
private javax.swing.JPanel jPanel4;
private javax.swing.JPanel jPanel6;
private javax.swing.JPanel jPanel7;
private javax.swing.JPanel jPanel8;
private javax.swing.JPanel jPanel9;
private javax.swing.JLabel labelCentre;
// End of variables declaration
}
99
ANNEXE 2 EXEMPLES DE QUESTIONNAIRES D’AUDIT
A. Mesures de prévention par identification de l’individu appelant (protection logique)
• Le « maiden password » a-t-il été changé après l’installation du système ?
• Les mots de passes sont-ils affectés individuellement à chaque utilisateur ?
• Les mots de passes sont-ils modifiés régulièrement ?
• Les mots de passes sont-ils suffisamment « sophistiquées », longueur minimum 8
caractères, Combinaison de chiffres et de lettres ?
• Les mots de passes sont-ils masqués à l’écran ?
• Les mots de passes sont-elles cryptés pour que personne ne puisse les lire ?
• Existe-t-il un procédure de suspension automatique du mots de passe après quelques
minutes d’inactivités ?
• Les tentatives d’authentifications concurrentes sont-elles interdites ?
• Des procédures sont-ils en places pour la suppression d’utilisateur ?
• La table de mots de passe est-elle elle-même protégée ?
• Est-il possible de détecter les tentatives d’accès non autorisé ?
• Tout utilisateur est-il déconnecté après plusieurs tentatives infructueuses ?
• Les utilisateurs ont-ils été sensibilisés aux risques qui peuvent découler du prêt de mots de
passe ?
B. Les techniques logicielles de protection
Limiter l’accès à l’environnement informatique aux seules personnes habilitées.
• L’accès aux applications transactionnelles est-il protégé par un mot de passe ?
• L’accès à l’éditeur est-il interdit aux utilisateurs ?
• Le lancement de programme en temps différé est-il protégé par un mot de passe ?
• L’accès aux logiciels système de mise à jour des fichiers est-il strictement réglementé ?
• L’utilisation des outils d’infocentre interdit-elle toute modification des fichiers de
production ?
• Est-il prévu des contrôles d’accès aux données elles-mêmes ?
• Est-il prévu des contrôles d’accès aux bibliothèques ?
• Est-il prévu des contrôles d’accès par volume-disque physique ?
100
• Les contrôles des mots de passe sont-ils gérés dans des tables et non inclus « en dur » dans
les programmes ?
• Le logiciel de gestion des autorisations d’accès permet-il de distinguer entre l’autorisation
de consultation et l’autorisation de mis à jour de données ?
• A-t-on implanté un logiciel de gestion de la sécurité (indépendant du mode d’accès)?
Principes fonctionnels de la gestion des autorisations d’accès
• Existe-t-il un responsable des autorisations d’accès ?
• Les habilitations respectent-elles le principe d’un bon contrôle interne ?
Mesures de prévention d’accès par identification du terminal appelant
• Une procédure d’identification physique de terminaux appelants est-elle prévue?
• Dans l’utilisation des réseaux publics, si cela est possible, des procédures de rappel
automatique de l’appelant sont-elles prévus?
• L’utilisation d’un groupe fermé d’abonné, si cela est possible est-t-elle prévue?
C. Les mesures de prévention d’accès portant sur la forme des données et leur support
de stockage
• Les données les plus sensibles font-elles l’objet d’un chiffrement ?
• Est-il prévu pour certains fichiers ou logiciels extrêmement sensibles qu’ils ne soient
chargés qu’au moment de leur exécution ?
D. Le vol ou la copie de fichiers ou logiciels se trouvant sur un support papier, disques
ou autres
• L’accès au parc des supports de stockages (CD, supports magnétiques,…) est-il
réglementé ?
• Pour les fichiers sensibles évite-t-on des procédures de transfert des supports « par
porteur » ?
• A-t-on inclus dans des fichiers « sensibles » des pièges permettant de vérifier qu’ils n’ont
pas été diffusés à l’extérieur ?
101
• Si nécessaire, des procédures de validation des données sur des fichiers sensibles sont-
elles prévues?
• Une procédure de contrôle spécifique au moment de l’édition d’états « sensibles» est-elle
prévue?
• La destruction systématique après utilisation des états contenant les informations
sensibles est-elle prévue?
102
BIBLIOGRAPHIE
[1] www.wikkipedia.org
[2] Renard J., « Théorie et pratique de l’audit interne », IFACI, Paris, 1997
[3] Faivre C., «Audit de la Micro-Informatique », IFACI, Paris, 1993
[4] Longeon R., « Guide de la sécurité des systèmes d’information », Centre Nationale de la Recherche Scientifique, Paris, 1999
[5] RABEHERIMANANA L., « Système d’Information », Cours I5-TCO, Dép.TCO, E.S.P.A, A.U. :2009-2010
[6] www.imacaudit.com
[7] Kramer J. B., « the CISA Prep Guide », Wiley Publishing, Indiana, 2003
[8] www.journaldunet.com
[9] www.nbs-system.com
[10] www.fortify.com
[11] Georgel F., « IT Gouvernance », Deuxième édition, dunod Paris, 2006
[12] www.bestPracticies.IT
[13] Moisand D., « CobiT », EYROLLES, Paris, 1992
[14] www.commentçamarche.net
[15] Lahti C., « Sarbanes-Oxley IT Complience Using CobiT and Open Source Tools », Syngress, Rockland, 2005
[16] Bloem J., « Making IT governance in a Sarbanes-Oxley World », Wiley Publishing, Indiana, 2006
[17] Servin C., « Réseaux et Télécoms », deuxième edition, Dunod, Paris, 2006
[18] Pujolle G., « Les Réseaux », Eyrolles, Dunod, Paris 2006
[19] Carlier A., « Stratégie appliqué à l’audit des SI », troisième édition, hermes science, Paris, 2006
[20] Champlan J., «Auditing Information System, second edition », Wiley Publishing, Indiana, 2003
103
[21] http://www.isaca.org
[22] http://www.afai.org
[23] ISACA, « CobiT framework », IT Governance institute, USA, 2007
[24] ISACA, « CobiT Control Objectives », IT Governance institute, USA, 2007
[25] ISACA, « CobiT Management Guidelines », IT Governance institute, USA, 2007
[26] ISACA, « CobiT Maturity Models », IT Governance institute, USA, 2007
PAGE DE RENSEIGNEMENT
Nom : RANDRIANARISOA
Prémons : Fy Rajo
Adresse de l’auteur : Lot 11 fm Bis Ambohibao Antehiroka
103 AMBOHIDRATRIMO
Tel : +261 (0) 33 14 029 15
E-mail : [email protected]
Titre du mémoire : « AUDIT DE SECURITE DE SYSTEME D’INFORMATION »
Nombre de pages : 104
Nombres de figures : 36
Nombres de tableaux : 9
Mots clés : audit, sécurité, système d’information
Directeur de mémoire : M.RANDRIARIJAONA Lucien Elino
Tél : +261(0) 32 04 747 95
E-mail : [email protected]
105
RESUME
Dans cet ouvrage, on s’intéresse à l’audit de sécurité des Systèmes d’Information. L’audit est une
activité visant à exécuter un examen approfondis des domaines d’activités d’une entreprise en vue
de les rendre conforme à une norme.
Pour l’effectuer on s’intéresse aux normes et référentiels d’audits, à la notion d’IT Gouvernance et
aux différentes mesures de sécurité à prendre en compte.
Donc ce mémoire nous a permis de mieux comprendre les principes d’audits, sa mise en pratique,
ainsi que les différentes notions à connaître pour pouvoir effectuer une mission d’évaluation dans
des conditions optimales.
ABSTRACT
This work talks about the Information system security auditing. An audit intends to perform a
deep examination of all the areas of a company to make it in conformity with a standard.
To perform an audit we are interested in the auditing standards and guidelines, the concept of IT
Governance and the various security measures to consider.
Then this book enabled us to have a better understand in the basic principles of an audit, its
practices and the useful concept to master to make an evaluation correctly.
