CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

___________________

MEMOIRE

présenté en vue d'obtenir

le DIPLOME D'INGENIEUR CNAM

SPECIALITE : Ingénierie des Systèmes d’Information

par

René THIEL

___________________

Mission d’analyse des risques

Soutenu le 11 janvier 2017

_________________

JURY

PRESIDENT : Michel Crucianu, Pr Cnam

MEMBRES : Nicolas Travers, MdC Cnam

Nicolas Trèves, PAST Cnam
Elisabeth Métais, Pr Cnam (Tuteur Cnam)
Olivier Mesnil, Manager Excellence IT (Tuteur Sopra Steria)

Page 1 sur 145

 Remerciements
Tout d’abord, je tiens à remercier les membres du CNAM de Paris, en particulier M. Jacky Akoka,
Professeur émérite, dont les enseignements on sut m’atteindre bien au-delà de l’unité
d’enseignement pour laquelle je m’étais historiquement inscrit.
Je tiens également à remercier Mme Élisabeth Métais pour le temps qu’elle m’a accordé afin que,
comme elle le dit si facilement, je puisse obtenir plus de dix à ma soutenance.
De manière plus générale, je tiens également à remercier tous les intervenants que j’ai pu croiser
durant mes dix années sur les bancs du CNAM, comme l’excellent maitre ITIL M. Pascal Coquelet qui
arrivait à dispenser un court pratique là ou d’autres se seraient limité à la théorie, ou comme M. Eric
Abouchakra qui a sur égailler mes soir, mes weekends et mes vacances en me faisant travailler à un
projet d’urbanisation du SI.
Comme aime à le dire M. Akoka, après tout, on a que ce que l’on mérite. Je suis donc heureux de me
présenter à vous afin d’obtenir peut-être mon troisième titre au CNAM, celui d’ingénieur.
Je remercie aussi ma société, Sopra Steria, pour m’avoir permis de concrétiser ce mémoire, l’agence
Défense et Sécurité pour m’avoir accueilli et plus particulièrement M. Jean Luc Gibernon, Directeur,
pour m’avoir recruté en connaissance de cause et M. Olivier Mesnil, Manager, qui a pris à chaque
fois beaucoup de plaisir, j’en suis sûr, à relire les quelques pages de ce mémoire.

Page 2 sur 145

 Table des matières

Remerciements ................................................................................................................. 2
Table des matières ............................................................................................................ 3
Introduction ...................................................................................................................... 6
1 Présentation de l’entreprise .............................................................................................. 6
1.1 Choix de l’entreprise ......................................................................................................................... 6
1.2 Présentation de mes missions ......................................................................................................... 11

2 Construction de ce mémoire ............................................................................................ 12

Problématique générale.................................................................................................. 14
3 Contexte général ............................................................................................................. 14
3.1 Le système d’information ................................................................................................................ 14
3.2 La sécurité de l’information ............................................................................................................ 14

4 Contexte de la mission .................................................................................................... 15

4.1 Objectif de la mission ...................................................................................................................... 15
4.2 Organisation du projet .................................................................................................................... 15
4.3 Les enjeux du projet et de l’application .......................................................................................... 16

Analyse des besoins ........................................................................................................ 19

5 À quoi sert la Sécurité des Systèmes d’Information ? ........................................................ 19
6 Les objectifs de la sécurité ............................................................................................... 19
7 Comment atteindre les objectifs en termes de DICP ?....................................................... 20
8 Les coûts de la sécurité ? ................................................................................................. 20

Réalisation de la mission ................................................................................................. 23

9 Définition du cadre de la gestion des risques .................................................................... 24
9.1 Les risques internes aux entreprises et organismes ....................................................................... 30
9.2 Les attaques externes aux entreprises et organismes .................................................................... 34
9.3 Panorama d’attaques techniques ................................................................................................... 38
9.4 Petit panorama d’attaques qui ont eu lieux .................................................................................... 41

10 Préparer les métriques ................................................................................................ 42

10.1 Les métriques utilisées .................................................................................................................... 43

11 Identifier les biens ....................................................................................................... 52

11.1 Les biens essentiels ......................................................................................................................... 53
11.2 Les biens supports ........................................................................................................................... 54
11.3 Présentation des mesures de sécurité déjà en place ...................................................................... 57

12 Apprécier les événements redoutés ............................................................................. 58

12.1 Événements redoutés par gravité ................................................................................................... 65

13 Apprécier les scénarios de menaces ............................................................................. 66

Page 3 sur 145

 14 Apprécier les risques.................................................................................................... 72
15 Identifier les objectifs de sécurité................................................................................. 78
15.1 Les solutions .................................................................................................................................... 79

16 Formaliser les mesures de sécurité à mettre en œuvre ................................................. 97

16.1 Mesures de sécurité complémentaires ........................................................................................... 97

17 Exemple de mise en œuvre d’une mesure de sécurité dans le cadre de notre étude de cas
110

Bilan de la mission .........................................................................................................113

18 Matrice des risques nets .............................................................................................114

Conclusion .....................................................................................................................116
Bibliographie .................................................................................................................119
Glossaire........................................................................................................................122
Liste des abréviations.....................................................................................................131
Table de annexes ...........................................................................................................134
Annexe 1 - Recommandations de sécurité pour la mise en œuvre d’un système de journalisation
N°DAT-NT-012/ANSSI/SDE/NP ...............................................................................................134
Annexe 2 - Menaces standards EBIOS:2010 ............................................................................136

Liste des figures .............................................................................................................142

Liste des tableaux ..........................................................................................................144

Page 4 sur 145

Introduction

Page 5 sur 145

 Introduction
1 Présentation de l’entreprise
1.1 Choix de l’entreprise
Alors que j’avais arrêté de travailler afin de réaliser ma dernière année d’étude au CNAM et
notamment mon mémoire probatoire et plusieurs unités d’enseignement qui demandaient un fort
investissement, M. Jacky Akoka m’a conseillé, constatant que la fin du cursus approchait, de me
mettre en quête d’une nouvelle entreprise au sein de laquelle je pourrais réaliser mon mémoire.
J’ai donc intégré Sopra Steria en avril 2015, en CDI, alors que je ne demandais au prime abord qu’à
réaliser un stage. J’ai donc été affecté sur leur site de Montreuil, tour Orion et j’ai intégré la division
Défense & Sécurité du groupe, plus précisément, l’agence SIA - SIOC qui travaille pour le ministère de
la Défense. Au sein de l’agence, j’ai intégré l’équipe SSI en tant que consultant sénior en cyber
sécurité et ma position de consultant a fait que mes missions ne se sont pas limitées pas à cet unique
client.
J’ai été orienté vers le domaine de la sécurité des systèmes d’information en 2008, alors que j’étais
encore militaire tout simplement par affectation de la part de la direction des ressources humaines
de l’Armée de Terre (DRHAT [1]). C’est un domaine dans lequel je me suis spécialisé au fil des années,
accompagnant ainsi des clients grands compte ainsi que des organismes gouvernementaux dans leur
démarche de sécurité. Rejoindre Sopra Steria et œuvrer à nouveau à la sécurité de mon pays m’a
donc semblé tout à fait approprié.
Depuis mon intégration à la société, j’ai effectué plusieurs missions toujours liées à la sécurité des
systèmes d’information pour différents ministères. C’est une de ces missions qui vous sera présentée
au sein de ce rapport. Pour des questions de confidentialité un ensemble d’informations ont été soit
modifiées dans une volonté d’anonymisation, soit supprimées afin que le mémoire en lui-même ne
soit pas marqué confidentiel et puisse ainsi profiter aux futurs ingénieurs. Ainsi, les différentes
missions que j’ai réalisées pour Sopra Steria m’ont permises d’élargir mon point de vue et
d’appliquer des compétences que je n’avais jusqu’alors pas pu mettre en œuvre ce qui m’a permis de
m’améliorer.

1.1.1 Historique de l’entreprise

1.1.1.1 Histoire
Sopra Steria Group est né de la fusion fin 2014 de deux des plus anciennes Entreprises de Services du
Numérique (ESN) françaises, Sopra et Steria, fondées respectivement en 1968 et 1969 et marquées
toutes deux par un fort esprit entrepreneurial ainsi qu’un grand sens de l’engagement collectif au
service de ses clients.
Aujourd’hui, le Groupe Sopra Steria s’affirme comme un des leaders européens de la transformation
numérique. En 2015, coté au SBF 120, il réalise un chiffre d’affaires de 3,6 milliards d’euros et
rassemble plus de 38 000 salariés dans plus de 20 pays.

1.1.1.2 Organisation du groupe

Sopra Steria est organisé sur 4 niveaux :

Page 6 sur 145

  NIVEAU 1 : LA DIRECTION GÉNÉRALE - La Direction générale est représentée par le
Directeur général et les Directeurs généraux adjoints. Le Comité Exécutif (le COMEX) est
composé de la Direction générale et des Directeurs des grandes entités opérationnelles et
fonctionnelles.

 NIVEAU 2 : LES FILIALES OU PAYS - Ce sont les grandes entités opérationnelles. Leur
périmètre correspond soit :
o au métier (conseil et intégration de systèmes, édition de solutions métier, gestion
d’infrastructures, cyber sécurité et exécution des processus métier (BPS : Business
Process Services)) ;
o à la géographie (pays).

 NIVEAU 3 : LA DIVISION - Chaque pays ou filiale est constitué de divisions suivant deux
critères possibles :
o le secteur économique ;
o la géographie (régions).

 NIVEAU 4 : LES AGENCES - Chaque division regroupe des agences qui constituent les unités
économiques de base de l’organisation. Elles fonctionnent en centres de profit et disposent
d’une réelle autonomie. Le pilotage commercial et Ressources Humaines se fait de façon
hebdomadaire et le pilotage économique (compte d’exploitation et budget) est suivi
mensuellement.

1.1.2 Le secteur d’activité

Sopra Steria propose l’un des portefeuilles d’offres les plus complets du marché : conseil et
intégration de systèmes, édition de solutions métiers et technologiques, gestion d’infrastructures,
cyber sécurité et exécution de processus métier. La figure ci-dessous met en évidence la part de
chaque offre dans le chiffre d’affaires.

Page 7 sur 145

 Figure 1 : Part des offres dans le Chiffre d’Affaires Sopra Steria

1.1.2.1 Activités
L’entreprise Sopra Steria a donc quatre principaux types d’activités qui sont décrits ci-dessous.

1.1.2.2 Conseil et intégration de systèmes

Le conseil est un accompagnement qui consiste pour l’essentiel à appréhender les enjeux métiers des
clients au travers d’une forte expertise sectorielle puis à concevoir des trajectoires de transformation
(processus métier, urbanisation du SI, conduite du changement…) leur permettant de tirer le meilleur
parti des nouvelles technologies numériques.
L’offre d’Intégration de systèmes du Groupe adresse à la fois les enjeux d’obsolescence et de
modernisation du système d’information en garantissant flexibilité optimale et création de valeur.
Les équipes de Sopra Steria accompagnent leurs clients (Orange, SNCF ou BforBank par exemple)
dans la mise en œuvre de projets en mode agile et industrialisé.

1.1.2.3 Cyber sécurité

Sopra Steria propose une offre en réponse à trois enjeux majeurs de la Cyber sécurité :

 Prévention : principalement des activités de conseil autour de l’analyse de risques, la mise

en place et le pilotage d’une stratégie de sécurité, l’aide à la gouvernance, la conformité
réglementaire ou technique, les audits de sécurité ;
 Protection : déploiement de solutions de protection des identités (Identity and Access
Management), des données (chiffrement, authentification forte, Data Leakage Protection) et
des transactions (Public Key Infrastructure) ;
 Détection & Réaction : mise en place d’une « tour de contrôle » pour la gestion en temps
réel des incidents (Security Incident Event Management & Security Operations Centre),
l’investigation en cas d’attaque avérée (forensics), la gestion de crise et la veille.

Page 8 sur 145

1.1.2.4 Gestion des infrastructures informatiques
Sopra Steria assure tout ou partie de l’exploitation des infrastructures informatiques en délivrant des
prestations telles que :
 Le service desk : assistance technique et métier auprès des utilisateurs ou des help desks
client.
 La supervision des infrastructures systèmes et réseaux.
 L’administration et l’exploitation des infrastructures systèmes et réseaux
 L’hébergement des infrastructures au sein de data centers.
 Le service cloud : l’intégration des services Cloud (IaaS [2], PaaS [3], SaaS [4]) dans
l’écosystème de l’entreprise.

1.1.2.5 Solutions métier

Sopra Steria met son expertise métier au service de ses clients à travers des solutions packagées dans
trois domaines : la Banque, les Ressources Humaines et l’Immobilier. Le Groupe adapte et déploie ses
solutions applicatives pour proposer à ses clients des logiciels performants, en harmonie avec le
développement de leur entreprise et à l’état de l’art en matière de technologies de l’information, de
savoir-faire et d’expertise.

En complément, la figure ci-dessous montre la répartition des activités du groupe dans les différents
domaines du marché des Entreprises de Services Numériques (ESN).

Figure 2 : Répartition des activités du groupe dans les différents domaines du marché des ESN

1.1.2.6 France et Monde

Sopra Steria est surtout implanté en France et en Europe, mais continue de son expansion dans le
Monde entier. La figure ci-dessous, très complète, montre la répartition des collaborateurs Sopra
Steria et du Chiffre d’Affaires sur le Monde, non sans montrer une certaine corrélation.

Page 9 sur 145

 Figure 3 : Répartition des collaborateurs et du chiffre d’affaires sur le Monde

1.1.3 Division défense et sécurité

Comprenant plusieurs agences (dont l’agence 194 dans laquelle je travaille), la Division défense et
sécurité est en charge des projets pour le compte du Ministère de la Défense et du Ministère de
l’Intérieur.
Les projets concernent par exemple le système de paie de l’armée, les systèmes d’information (SI)
des approvisionnements des produits de santé ou les SI des permis de conduire.

1.1.4 Projet SIA

Le projet Système d’Information des Armées (SIA), sur lequel je travaille également, est attribué à
une agence dédiée au sein de Sopra Steria : l’agence 194 - SIA - SIOC. C’est un projet majeur et
important sur le long terme, le contrat initial étant prévu sur une dizaine d’années.

1.1.4.1 Contexte et enjeux du projet

L’évolution des structures de commandement, qui renforce le caractère interarmées des
engagements français, et les objectifs de réduction des coûts ont conduit le ministère de la Défense à
entreprendre la rationalisation des SI des armées (Air, Terre, Marine). L’objectif est d’aboutir, en
2017, à un SI opérationnel pleinement interarmées, appelé SIA. L’enjeu du programme SIA est triple :
 Au plan opérationnel : passer d’une logique de milieu à une logique de fonctions, avec un
esprit de simplification pour l’utilisateur opérationnel, pour l’exploitant et pour le décideur.
 Au plan de l’organisation du ministère : maîtriser le coût global de la fonction « systèmes
d'information et de communication » (SIC) et de structurer l’interopérabilité.
 Au plan de la maturité technique du système : rationaliser le parc applicatif, maintenir le
système à l’état de l’art technologique et lui donner la capacité d’accueillir des applications
tierces.

Page 10 sur 145

1.1.4.2 Mission et valeur ajoutée de Sopra Steria
S’appuyant sur son savoir-faire d’éditeur, Sopra Steria est architecte-intégrateur du programme SIA.

 en tant qu’architecte : définition du schéma directeur et de l’architecture d’ensemble du

SIA, mise en cohérence des SIOC, accroissement de l’interopérabilité des systèmes,
standardisation.
 en tant qu’intégrateur : organisation, outils, règles, référentiels techniques communs aux
sous-systèmes, intégration des sous-systèmes et composants réalisés par des MOI Tiers,
livraison d’un système cohérent aux forces par le biais de configurations types du SIA,
préparation et plan de déploiement avec MCO/MCS.
De plus, Sopra Steria a créé le « SIA LAB », un espace où les PME sont invitées à présenter leurs
produits innovants susceptibles d’être intégrés dans le programme SIA.

1.1.4.3 Bénéfices pour le client

Pour le Ministère de la Défense, les bénéfices sont multiples :
 mise en cohérence des SIOC (SI Opérationnels et de Commandement) visant la réduction
des coûts de possession, l’optimisation du soutien et des services aux utilisateurs ;
 accroissement de l’interopérabilité des systèmes, standardisation de processus ;
 transformation et valorisation du patrimoine du système d’information des armées.

1.2 Présentation de mes missions

Depuis mon arrivée au sein du groupe, j’ai participé à plusieurs missions, toutes différentes.
Certaines ont été de courtes durées, pour d’autres je suis encore sur le sujet et biens sur d’autres
missions viennent de débuter fin 2016 et vont se poursuivre en 2017.
Je ne parlerais dans le paragraphe suivant que des projets majeurs et non confidentiel sur lesquels je
suis ou j’ai été employé.
A mon arrivée au sein du groupe j’ai été affecté au programme SIA précédemment cité et j’ai débuté
en étant le référent fonctionnel et technique d’un composant de supervision de la sécurité à
destination des armées. Je suis aujourd’hui plus particulièrement responsable du processus de
conformité sécurité du programme SIA et je participe en tant qu’expert sécurité à l’élaboration de la
stratégie de surveillance des configurations. D’autre part, j’ai élaboré et je porte l’offre d’audit
sécurité du pôle cyber, j’ai eu donc le plaisir de tenir le rôle de responsable d’équipe d’audit pour le
compte du ministère de l’intérieur pour qui j’ai réalisé 6 audits en 2016 répartis sur toute la France.
Pour finir, je suis toujours le responsable sécurité d’un projet qui consiste à développer et à mettre
en place une application de gestion pour un ministère. C’est dans le cadre de cette dernière mission
qui vous sera présentée au sein de ce mémoire que j’ai réalisé ma mission d’analyse de risque. Cette
mission n’est pas officiellement terminée à ce jour étant donné que le poste de responsable sécurité
est maintenu durant toute la vie du projet. Toutefois, ce rôle prévoit un ensemble de tâches à
réaliser bien différentes en fonction de l’avancement du projet. Ainsi, le projet est aujourd’hui très
avancé ce qui me permettra de vous présenter bout à bout, les objectifs de ma mission et les
résultats de cette dernière.

Page 11 sur 145

Parmi les objectifs majeurs de cette mission on peut compter la réalisation d’un plan d’assurance
sécurité dont je ne parlerai pas au sein de ce mémoire car il s’agit avant tout d’un document qui
traite de qualité et d’une analyse de risque qui fera l’objet de toute notre attention et qui a été
l’objet de mon étude. En effet, cette analyse de risque est le cœur du dossier de sécurité de
l’application. Pour que le projet puisse être validé et mis en production, cette analyse de risque est
obligatoire et ses résultats sont jugés par la direction du client. Si l’analyse et ses conclusions sont
jugées valides alors l’application pourra être mise en production, on parlera d’homologation, si ce
n’est pas le cas la mise en production de l’application est repoussée voir même le projet peut être
remis en cause. Il faut voir cette étape comme une validation stratégique, l’analyse de risque fait
donc partie des livrables dits structurant pouvant remettre en cause le projet, en opposition aux
livrables opérationnels (processus, procédures).

2 Construction de ce mémoire
Ce mémoire est partagé en 6 grands chapitres, le premier est l’introduction, qui comprend la
présentation de l’entreprise et qui présente la construction de se mémoire. Le second présente la
problématique générale et les objectifs de la mission. Le troisième chapitre est l’analyse des besoins,
il est lié aux enjeux généraux et aux objectifs de sécurité. Le quatrième chapitre détaille la réalisation
de la mission alors que le cinquième chapitre présente le bilan de la mission. Le dernier chapitre
quant à lui propose une conclusion à ce mémoire.
Afin de traiter la problématique nous partagerons donc ce mémoire selon le modèle ci-dessous en
suivant le fil conducteur qui nous est imposé par la nature de la mission :

1 – Introduction

2 – Problématique générale

3 – Analyse des besoins

4 – Réalisation de la mission

5 – Bilan de la mission

6 - Conclusion

Tableau 1 : Construction du mémoire

L’objectif premier d’une étude sécurité est de donner une vision globale des risques de sécurité
pesant sur un périmètre donné. L’analyse de risque, objet de la mission et de ce mémoire qui vous
sera présentée tout au long de ce mémoire constitue un fil conducteur fort car elle a été réalisé en se
basant et en adaptant la méthode d’analyse de risque EBIOS:2010 proposée par l’ANSSI [5]. Nous
respecterons notamment durant cette mission les principes du Référentiel Général de Sécurité (RGS
V2 - [6]) Français ainsi que l’ISO 27002:2013(fr) [7].

Page 12 sur 145

Problématique générale

Page 13 sur 145

 Problématique générale
Notre société est aujourd’hui totalement informatisée. L’espace, la planète, notre corps, tout est
connectable mais surtout de plus en plus connecté car de la faisabilité à la réalisation il n’y avait
qu’un pas à franchir et il a été franchi. Il n’y a plus un seul endroit sur la surface de la terre qui ne
puisse être photographié par satellite. Le cliché est alors traité par un analyste qui en dégagera des
données, de l’information et peut être même un renseignement. Ces informations doivent être
gérées et quelles que soient nos domaines d’activités, nous sommes confrontés directement à ces
systèmes d’information.
Les problèmes de sécurité sont monnaies courantes, allant du vol de numéros de cartes de crédit de
particuliers, à la découverte de virus de plus en plus destructeurs qui s’attaquent aujourd’hui au
secteur industriel faisant ainsi planer sur nous tous un risque historique.
Ainsi il nous est nécessaire de mettre au point des méthodes et des techniques pouvant réduire
considérablement ces risques. La Cyber sécurité tente d’apporter une réponse appropriée à ces
menaces.
Avant de présenter les objectifs de la mission qui m’a été confiée, il est nécessaire de préciser les
connaissances et méthodes qui m’ont été nécessaires à la réalisation de cette mission. Nous
aborderons donc de nombreux thèmes incontournables tel que la sécurité de l’information, la
sécurité physique, la sécurité informatique et nous tenterons de réunir au sein de ce document un
condensé de connaissances qu’il est nécessaire de d’acquérir en tant qu’ingénieur puis de
développer, avant de pouvoir prétendre aborder la mission et la sécurisation à proprement parler.
Le choix d’une protection adéquate pour les systèmes d’information est essentiel et compliqué. Rien
ne se décide au hasard, il faut s’armer de méthodes. Il est nécessaire de bien connaître son
environnement, les objectifs de l’entreprise ou de l’organisme et les technologies qui lui sont
disponibles. Mettre en place une politique de sécurité efficace représente un long travail d’étude et
de choix, devant apporter la plus grande protection possible aux systèmes d’information.

3 Contexte général
3.1 Le système d’information
Dans ce mémoire, nous évoquerons le « système d’information » comme un moyen dont le
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 des informations.

3.2 La sécurité de l’information

Il s’agit de tous les éléments intervenant dans le traitement des données qui sont susceptibles de
connaître des défaillances qui menacent la sécurité du système d’information. La sécurité
informatique est l'ensemble des moyens mis en œuvre pour minimiser la vulnérabilité d'un système
contre des menaces accidentelles ou intentionnelles.

Page 14 sur 145

4 Contexte de la mission
4.1 Objectif de la mission
L’objectif de la mission est de réaliser l’analyse de risques de l’application de gestion de Contrats
Immobiliers, mise en place par l’état français.
L’objectif premier de l’étude est de donner une vision globale des risques de sécurité pesant sur
l’application et de proposer des mesures de couvertures pour les principaux risques identifiés.
L’analyse de risques a été réalisée en s’inspirant de la méthode d’analyse de risque de l’ANSSI
EBIOS:2010.
Le second objectif de l’analyse de risque est de contribuer à l’homologation de l’application suivant
le RGS (Référentiel Général de Sécurité).
Dans le cadre de cette mission je tiens le rôle de Responsable Sécurité pour Sopra Steria. J’ai pour
objectif de :

 collecter l’ensemble des informations nécessaires à l’étude, le référentiel documentaire

ainsi constitué est stocké sur un espace au sein d’un espace dédié au projet ;
 rencontrer les personnes impliquées dans l’étude notamment pour l’identification et la
description des biens supports, l’identification des vulnérabilités, l’établissement des
sources de menaces, l’établissement des scénarios de menaces ;
 synthétiser les résultats des étapes de l’analyse de risque ;
 soumettre, à chaque grande étape les documents produits à la direction du client et à ses
experts en sécurité pour validation.

À l’issue de l’étude le livrable attendu est un Dossier de Sécurité sur l’application comprenant :
 le contexte de l’étude ;
 la liste des biens essentiels et supports relatifs au périmètre de l’étude avec leurs relations ;
 la liste des sources de menaces considérées pour l’étude ;
 la liste des vulnérabilités identifiées sur les biens supports et des mesures de sécurité
contribuant à les diminuer ;
 les scénarios de menaces ;
 la description des risques non acceptables ;
 les objectifs de sécurité (au sens EBIOS:2010) ;
 les exigences de couvertures préconisées pour les risques non acceptables.

4.2 Organisation du projet

L’analyse de risques a été réalisée et pilotée par Sopra Steria, en l’occurrence par moi-même, pour le
compte de la direction d’un ministère.

Page 15 sur 145

Comme évoqué dans le paragraphe précédent, la méthodologie utilisée pour mener l’étude est
conforme EBIOS:2010 ce qui était exigé par le client.
Les mesures de sécurité proposées devaient également s'appuyer sur les 2 référentiels que sont l'ISO
27002 (v2013) d'une part et le RGS v2.0 d'autre part, celui-ci étant prévalant dans l'optique de
l'homologation RGS de l’application.

Les entretiens suivants ont été réalisés pour l’étude :

 équipe SSI ;
 équipes clients ;
 équipes techniques Sopra Steria;
 équipes fonctionnelles Sopra Steria.

Les sources d’information qui ont été utilisées à l’initialisation de l’étude sont :

 les CCTP ;
 le mémoire Technique de réponse à appel d’offre de Sopra Steria ;
 les processus et procédures de sécurité du client ;
 la politique de sécurité du client ;

4.3 Les enjeux du projet et de l’application

Par application on entend l’architecture technique et fonctionnelle de l’application (les choix de
technologies, les vulnérabilités induites aux niveaux technique et fonctionnel, les mesures et
fonctionnalités de sécurité implémentées, …).
La mise en place d’un outil de gestion des contrats en remplacement d’une ancienne application
constitue un levier pour poursuivre et amplifier la modernisation de la gestion immobilière de l’État.
La nouvelle application met à la disposition des utilisateurs un outil accessible, intégré au système
d’information de l’état et intégrant une couverture fonctionnelle enrichie. L’application est ouverte
sur le pilotage et la diffusion d’une Gestion Électronique des Documents (GED).

Les enjeux de la mise en place de l’application se structurent autour de cinq directions principales :

 l’apport de nouvelles fonctionnalités et l’amélioration du périmètre fonctionnel

actuellement géré dans l’ancien outil ;
 l’intégration d’une dimension pilotage avec la possibilité de s’appuyer sur des restitutions
standards et de disposer de requêtes ad-hoc pour l’analyse et la prise de décisions ;
 l’intégration dans l’architecture applicative du cœur du système d’information de l’état avec
une mise à disposition exhaustive et des informations entre les modules ;

Page 16 sur 145

 une gestion des référentiels garantissant l’exactitude des données avec un module
demeurant référentiel maître pour les données de patrimoine et un autre devenant le
référentiel maître pour les données d’occupation,
 un outil unique et fédérateur pour l’ensemble des utilisateurs dans un environnement
complexe avec : environ 600 utilisateurs représentants de l’État : des utilisateurs en central,
des Services Locaux (SLD) en déconcentré, des Responsables de l’État et entre 600 et 2 000
utilisateurs ministériels pour :
o consulter des données et des restitutions sur les processus de gestion ;
o intervenir en création ou modification sur des processus de gestion ;
o intervenir en création ou modification sur des processus de gestion exécutés.

Page 17 sur 145

Analyse des besoins

Page 18 sur 145

 Analyse des besoins
Nous parlons de plus en plus de sécurité de l’information, de cyber sécurité et de lutte informatique
défensive mais dans quel but ? Concrètement à quoi sert la sécurité ? Certainement pas à empêcher
les attaques, mais surement à ralentir le mouvement et à en diminuer le périmètre et la portée.

5 À quoi sert la Sécurité des Systèmes d’Information ?

Question récurrente à tous les niveaux hiérarchiques : que nous apporte la sécurité informatique ?
En dehors d’être un centre de coût pour les structures. La meilleure réponse qu’il m’a été donné,
c’est le référentiel de bonnes pratiques ITIL [8] qui nous l’apporte et elle commence par une
question.
À quoi sert le système d’information ?
Le système d’information nous rend un service, il apporte de la valeur aux entreprises et aux
organismes. Mais pour créer ou apporter de la valeur deux choses sont nécessaires, l’utilité et la
garantie.
Un logiciel de paie est utile, il facilite la gestion des paies du personnel, mais si son fonctionnement
n’est pas garanti, à minima à chaque fin de mois, il perd de son utilité et le logiciel n’apporte donc
plus aucune valeur.
Il est donc nécessaire d’avoir des garanties et c’est là que la sécurité du système d’information
intervient.

6 Les objectifs de la sécurité

La sécurité informatique vise à assurer plusieurs objectifs, regroupés en quatre grandes familles [9]:
 la Disponibilité, elle doit permettre l’accessibilité aux données à n’importe quel moment.
Pour une entreprise, les retards dus à l’incapacité d’effectuer un traitement dans les délais
peuvent donner lieu à des pénalités dans le cas de livraisons, voir la perte de clients face au
non-respect des engagements ;
 l’Intégrité, elle garantit que les données n’ont subi aucune détérioration ou modification à
l’insu de leur propriétaire ou utilisateur. Ces altérations peuvent amener à des conséquences
diverses, telles que la corruption d’informations et l’ajout d’informations supplémentaires et
le coût de reconstruction des données que cela implique ;
 la Confidentialité, elle consiste à rendre l’information accessible par les personnes autorisées
à y accéder seulement. Le vol d’informations sensibles peut être fatal à une entreprise, tant
vis à vis de la concurrence que de l’image renvoyée par la société.
 la Preuve ou Trace (logs), outre l’utilité technique, une bonne gestion des traces permet
l’identification, l’investigation et la conformité légale.

Dans le cadre de ma mission, l’application repose sur une architecture Web, cette dernière doit donc
disposer de garanties afin de pouvoir assurer de sa Disponibilité, son Intégrité, sa Confidentialité et
de pouvoir administrer une Preuve. On notera que pour avoir une réelle identification, il faut qu’il y

Page 19 sur 145

ait authentification. Il faut être certain des identités (émettrices ou réceptrices), afin de garantir les
communications et afin de garantir leur non répudiation, de se protéger contre la négation. La
traçabilité permet quant à elle de garder un historique des évènements, une imputabilité et de nos
jours la traçabilité est omniprésente et généralisées aux actes les plus communs (Cf. CNIL).

7 Comment atteindre les objectifs en termes de DICP ?

Il nous faut garder en mémoire trois critères lorsque l’on a la responsabilité d’un système
d’information et que l’on souhaite le garantir en termes de DICP.

Prévention Détection Réaction

Figure 4 : Les trois grandes responsabilités du RSSI

À tout moment de ce mémoire on pourra se situer et dire si ce que l’on entreprend participe à la
Prévention, à la Détection ou à la Réaction face aux risques.
La sécurité est un voyage pas une destination [10].
La mission qui m’a été confiée consiste en une analyse de risques. Il s’agit donc d’étudier et de
Prévenir l’occurrence de risques que l’on arrivera à identifier, ou du moins à en réduire la portée et
l’impact sur le système à protéger.
Lorsque l’on parle de lutte informatique défensive il s’agit d’un travail en profondeur dans le sens ou
une succession de mesures doivent être prévues afin de lutter de manière plus ou moins active à la
défense du système d’information. Ainsi ce qui est prévu sera détecté et l’on saura comment réagir
ou comment réagira le système face à cet événement.
La sécurité du système d’information doit être, une réponse adaptée. Elle doit permettre de protéger
les ressources sensibles des menaces redoutées et ceci dans la limite des moyens disponibles. Sa
prise en compte dès la phase de faisabilité du système d’information est primordiale (Prévention).
La sécurité du SI doit être un élément de la Politique générale de la Sécurité Informatique (PSI) de
l’entreprise (Prévention).
La sécurité du système d’intervention, nécessite une documentation organisationnelle et technique
et doit évoluer continuellement en fonction d’une veille technologique permanente (Prévention).

8 Les coûts de la sécurité ?

Parlons en immédiatement, la sécurisation d'un système d'information peut représenter des coûts
très importants. Le cout de la sécurité est parfois difficilement chiffrable, mais ce qui est sûr c’est
qu’un incident de sécurité amène un préjudice financier élevé, ne serait-ce qu’en termes d’image vis-
à-vis des clients et des usagers des services de l’entreprise ou de l’organisme concerné.
Pour les professionnels, la sécurité des informations est partout, or sa justification en termes
économiques peut être difficile du fait du mode de prise de décision très orienté « retour sur
investissement » de surcroit à court terme, mais la sécurité fait partie des besoins non fonctionnels
qu’il est vital d’adresser.

Page 20 sur 145

Ne rien protéger ne coûte rien, du moins tant que la sphère publique n’est pas au courant des
différents incidents que subit de manière certaine l’organisme. Mettre en place des moyens de
sécurité, de supervision, c’est avant tout être capable de détecter un certain nombre d’évènements
unitaires mais que souhaite-t’ont réellement les détecter ?
En effet, celui qui ne détecte aucun incident de sécurité n’a évidemment aucun incident de sécurité à
gérer et sur lequel communiquer. Ce n’est pas sans raison si l’État Français pense à imposer aux
opérateurs d’importance vitale (OIV) la déclaration de leurs sinistres informatiques.
Il est donc très important d’évaluer les risques et les coûts associés pour traiter les menaces qui
pèsent sur les entreprises et les États.
De la même manière, se protéger de tout entraîne un coût extrêmement élevé et devient souvent
ingérable par les équipes en place. Le risque c’est que la situation soit pire qu’elle ne l’était
auparavant.
La définition d’une politique de sécurité (Prévention), son application et son amélioration est une
lourde tâche. Il est important de rappeler que la sécurité vise à identifier et à réduire les risques, elle
ne les supprime pas. Ainsi on pourra choisir à l’issue d’une analyse de risque de Réduire, Transférer,
Supprimer ou Accepter un risque et le rapport bénéfice sur investissement est un déterminant
majeur.
Afin d’aider les structures à gérer ces risques il existe aujourd’hui des normes spécifiques tel que
l’ISO 27005, qui aide à mettre en place les processus, ainsi que le référentiel documentaire
nécessaire au traitement réfléchi des risques qui pèsent sur les systèmes d’informations. Cette
norme s’intègre parfaitement à une démarche qualité itérative de type PDCA [11] et est donc
conforme ISO 9001 [12], ISO 27001 [13], ISO 20000 [14] et bien sûr au référentiel ITIL. Dans la
réalisation de ma mission je me suis basé sur tous les référentiels, bonnes pratiques, méthodes et
normes à ma disposition et tel qu’étudié dans des unités d’enseignements tel que NFE2019 qui reste
l’unité d’enseignement qui m’a le plus préparée à mon métier actuel.

Page 21 sur 145

Réalisation de la mission

Page 22 sur 145

 Réalisation de la mission
Les menaces susceptibles d’affecter un système informatique sont nombreuses et variées. Que ce
soit accidentel ou intentionnel, que la menace soit interne à la structure visée ou externe, les
menaces sont légions. De plus, ces menaces pèsent à tous les niveaux, depuis l’accès physique aux
systèmes, jusqu’à l’intrusion par l’intermédiaire d’internet.
Des méthodes et référentiels existent, en fonction des risques à traiter. En sécurité des systèmes
d’information on retiendra : la méthode EBIOS déjà régulièrement cité au sein de ce mémoire, la
méthode MEHARI [15], la démarche ISO 27001 et son annexe A détaillée dans l’ISO 27002 ainsi que la
démarche générale de l’ISO 27005 [16]. Je vous propose en annexe 2, un panel de menaces plutôt
standards que j’ai réalisé selon la méthode EBIOS:2010 afin de m’aider dans ma mission.
Les activités EBIOS:2010 peuvent se résumer simplement par le tableau que j’ai réalisé et que je vous
présente ci-dessous, elles ont été adaptées à la constitution de ce mémoire afin d’avoir un plan le
plus clair possible. Ce travail a été présenté dans l’analyse de risque livrée au client.
Pour mener à bien une analyse de risque, l’organisation suivante que j’ai proposé fait partie des
meilleures pratiques :

supports/mesures de sécurité
métiers/utilisateurs
Responsables biens
Activités EBIOS
Le Commanditaire

Représentants
Le Réalisateur

Activité 1.1 – Définir le cadre de la gestion des risques A R / /

Activité 1.2 – Préparer les métriques A R / /

Activité 1.3 – Identifier les biens A R C C

Activité 2.1 – Apprécier les événements redoutés A R C /

Activité 3.1 – Apprécier les scénarios de menaces A R / C

Activité 4.1 – Apprécier les risques A R / /

Activité 4.2 – Identifier les objectifs de sécurité A R / /

Activité 5.1 – Formaliser les mesures de sécurité à mettre en œuvre A R / C

Hors scope de l’analyse de

Activité 5.2 – Mettre en œuvre les mesures de sécurité risque mais un exemple est
donné en §17
Tableau 2 : RACI de l’analyse de risques

Page 23 sur 145

Explications :
R : Réalisateur (celui qui réalise) ;
A : Approbateur (celui qui approuve ou non l’action qui a été réalisée) ;
C : Consulté (ceux que l’on peut faire participer sans qu’il n’ait les responsabilités liées aux autres
fonctions) ;
I : Informé (ceux que l’on souhaite tenir informé sans qu’il n’ait de responsabilités).
Dans le cadre d’une analyse de risques le réalisateur doit conformément à la mission qui m’a été
confiée effectuer l’ensemble des tâches suivantes :

 collecter l’ensemble des informations nécessaires à l’étude, constituer le référentiel

documentaire de l’analyse et le stocker au sein du répertoire aux droits d’accès adéquat ;
 rencontrer les personnes impliquées dans l’étude notamment pour l’identification et la
description des biens supports, l’identification des vulnérabilités, l’établissement des
sources de menaces, l’établissement des scénarios de menaces ;
 synthétiser les résultats des étapes de l’étude EBIOS ;
 soumettre, à chaque grande étape les documents produits au client pour validation.

À l’issue de l’étude le livrable attendu est un Dossier de Sécurité sur l’application comprenant :

 le contexte de l’étude ;
 la liste des biens essentiels et supports relatifs au périmètre de l’étude avec leurs relations ;
 la liste des sources de menaces considérées pour l’étude ;
 la liste des vulnérabilités identifiées sur les biens supports et des mesures de sécurité
contribuant à les diminuer ;
 les scénarios de menaces ;
 la description des risques non acceptables ;
 les objectifs de sécurité (au sens EBIOS:2010) ;
 les exigences de couvertures préconisées pour les risques non acceptables.

9 Définition du cadre de la gestion des risques

Pour réaliser ma mission j’ai dû me poser beaucoup de questions et faire un grand travail de
recherche afin de compléter mes connaissances. Pourquoi vouloir réaliser une analyse de risque et y
associé un plan de traitement des risques ? Tout simplement car on nous veut du mal,
intentionnellement c’est sûr, mais également par négligence. De qui s’agit-il ? Pour répondre à ces
questions, il faut faire un état des lieux et réaliser une typologie de l’attaquant. Il s’agit là d’une des
premières tâches que j’ai dû réaliser.
L’IAEA (International Atomic Energy Agency) a publié en 2011 une typologie de l’attaquant efficace
[17], assez efficace pour être encore reprise de nos jours par les entreprises et organismes qui
souhaitent typer les profils à risques qui s’intéressent à leurs structures et intégrer cette typologie à
leur réflexion.

Page 24 sur 145

J’ai réalisé pour mon client une adaptation de la typologie originale de l’IAEA que je vous propose
dans le tableau ci-dessous, la version originale en anglais a été interprétée. Des méthodes comme
EBIOS proposent également d’identifier les sources de menaces j’en proposerai une adaptation plus
loin dans ce mémoire, mais une typologie de l’attaquant comme celle proposée ci-dessous comporte
des informations supplémentaires (outils, motivations). Les outils sont d’ailleurs nombreux et seront
détaillés au sein de ce chapitre car pour pouvoir se protéger il faut connaitre les risques encourus et
j’ai donc réalisé à travail de recherche afin de remplir au mieux ma mission.

Un aperçu des attaques :

 accès physique ;
 interception de communication ;
 dénis de service ;
 intrusions ;
 ingénierie sociale (social engineering) ;
 trappes ;
 attaques par rebond ;
 les maliciels ;
 les virus, mutant, polymorphes, les rétrovirus, les virus de secteur d’amorçage, les virus trans-
applicatifs (ou virus macro) ;
 les vers ;
 les HOAX (canular) ;
 les chevaux de Troie (backdoor) ;
 les bombes logiques ;
 les espiogiciels (spyware) ;
 les enregistreurs de frappe (keyloggers) ;
 les pollupostages, pourriels (spam) ;
 les techniques d’hameçonnage (phishing) ;
 les supports de stockage piégés tel que les clés USB ;
 écoute passive, d’un téléphone, d’un réseau, interception d’ondes, lecture de documents,
d’écrans ;
 défaillances des SI à l’intrusion, a la prise de contrôle, sabotage, erreurs.

Page 25 sur 145

 Attaquants Ressources Temps Outils Motivation

Tableau 1 Menaces internes

Dispose d'accès existants, à la connaissance des

architectures, des programmes et du système Le vol d'informations commerciales, de
Dispose de ressources, élevées
Connaissance possible d'identifiants (Couple login / secrets de la technologie,
Pratique une ingénierie sociale facilitée
Variable, mais généralement le temps consacré Mots de passe) d'informations sur le personnels
Agent secret A accès au système jusqu'à un certain niveau
ne pourra pas se quantifier en heures A la possibilité d'insérer des portes dérobées et / ou Gain économique (informations à
Dispose de la documentation du système et
des chevaux de Troie (spécifiquement conçus) vendre à des concurrents)
d'un centre d'expertise
A la possibilité de soutien de la part d'experts Chantage
extérieurs

Dispose d'accès existants, à la connaissance des Revanche, le chaos

Dispose de ressources, moyennes à élevées
architectures de programmation et du système Le vol d'informations commerciales
Employé / A accès au système jusqu'à un certain niveau
Variable, mais généralement le temps consacré Connaissance possible des mots de passe existant Embarrasser l'employeur / Embarrasser
Utilisateur Dispose de la documentation du système et
ne pourra pas se quantifier en heures Possibilité d'insérer des outils ou scripts préconçus d'autres employés
mécontent pour certains d'une expertise sur les affaires et
(potentiellement des outils plus élaborés si Dégrader l'image publique, altérer la
les opérations systèmes
compétences informatique spécifiques) confiance

Tableau 2 Menaces externes

Compétences variables mais généralement

Un statut fun
Pirate limitées Dispose généralement de scripts et d'outils
Beaucoup de temps mais pas très patient L'opportunité
récréatif Peu de connaissance du système en dehors de Certains développent leurs propres outils
Des exploitations faciles
l'information du public

Les ressources sont limitées mais peuvent être

Pensent être chargés d'une mission
soutenus financièrement par des canaux
Les attaques peuvent être ciblées sur certains Les compétences informatiques sont disponibles dont la cause est supérieure
Militants secrets
événements (fêtes, élections, déplacements de Le soutien éventuel d'une communauté de pirates Influencer l'opinion publique sur des
divers Accès aux outils de la cybercommunauté
VIP, déplacements de matériaux…) Ingénierie sociale questions spécifiques
Peu de connaissances du système en dehors de
Entraver les opérations d'affaires
l'information du public

Page 26 sur 145

Attaquants Ressources Temps Outils Motivation

La connaissance possible des mots de passe

Revanche, le chaos
Des ressources limitées si non engagé au sein existant
Ancien Le vol d'informations commerciales
d'un grand groupe de personnes Peut utiliser d'anciens accès si la gestion des
employé / Variable et dépend d'une association à un Embarrasser l'employeur / Embarrasser
Possède encore le système de documentation habilitations est mal gérée
Utilisateur groupe de personnes d'autres employés
Peut utiliser son ancien accès si la gestion des Peut avoir créé ou mis en place un système de
mécontents Dégrader l'image publique, altérer la
habilitations est mal gérée porte dérobée
confiance
Ingénierie sociale

Chantage, extorsion (gain financier), vol

Scripts, outils
Joue sur les finances, la perception et
Crime Ressources élevées Peut employer des pirates
Variable mais principalement du court terme les craintes dans les affaires
organisé Emploi d'experts Peut employer d'anciens / ou d'actuels employés
Information pour la vente (techniques,
Ingénierie sociale
commerciale ou personnelles)

Ressources élevées et expertise élevée

Des équipes formées, des cybers experts La construction d'accès pour des
Activités de collecte de renseignement
États Variable Des outils sophistiqués actions ultérieures
Possibilité de formation / D'exploitation et
Peuvent employer d'anciens ou d'actuels salariés Vol de technologies
expérience sur le système

La collecte du renseignement
Scripts, outils La construction d'accès pour des
Compétences variables
Peut employer des pirates informatique à louer actions postérieures
Terroristes Possibilité de formation / d'exploitation, Beaucoup de temps, très patient
Peut employer d'anciens / ou d'actuels employés Chaos
expérience sur le système
Ingénierie sociale Vengeance
Opinion publique d'impact (crainte)

Tableau 3 : Typologie de l'attaquant

Page 27 sur 145

Dans le cadre de la mission qui m’a été confiée j’ai sélectionné les sources de menace au sein de la base de
connaissance de la méthode EBIOS conformément aux consignes. Comme le veut le processus à chaque étape les
experts SSI du client valide les propositions faites par le Responsable Sécurité du projet.
Voici donc les sources de menaces retenues pour l’étude avec leur typologie (au sens EBIOS:2010) et leur description
dans le contexte de l’application sont les suivantes :

Type N° Sources de menaces Sélection Dénomination / justification si non retenue

Personnel interne avec des droits utilisateurs simples ou sans droits

1 Interne, malveillante, avec Oui particuliers sur l’application, personnel du data centre sans droits
de faibles capacités physiques et logiques sur les équipements

Exploitants, développeurs, personnel interne avec des droits élevés dans

Interne, malveillante, avec l'application, équipe support, personnel du data centre avec des droits
2 Oui
des capacités importantes physiques et /ou logiques sur les équipements, équipe interne support
flux

3 Interne, malveillante, avec Oui Administrateur technique interne

des capacités illimitées
Humaines &
malveillantes
Externe, malveillante, avec Utilisateurs de l’application avec des droits standards, autres utilisateurs
4 Oui
de faibles capacités du réseau, utilisateurs des applications satellites

Externe, malveillante, avec Hackers, utilisateurs avec des droits élevés (ex : valideurs, …), concurrent
5 Oui
des capacités importantes d'un autre client du data centre.

6 Externe, malveillante, avec Oui Gouvernement étranger, terroristes, groupes mafieux.

des capacités illimitées

Interne, sans intention de Personnels du data centre non affectés à l'environnement L’application
7 nuire, avec de faibles Oui
(intervention sur clim/courant secouru/arrivées télécom/…).
capacités

Exploitants, développeurs, personnel interne avec des droits élevés dans

Interne, sans intention de l'application, équipe support, sous-traitant du data centre avec des droits
8 nuire, avec des capacités Oui
physiques et ou logiques sur les équipements, équipe interne support flux,
importantes auditeurs commandités

Humaines & Interne, sans intention de

9 nuire, avec des capacités Oui Administrateur technique
accidentelles
illimitées

Externe, sans intention de

10 nuire, avec de faibles Oui Utilisateurs de l’application avec des droits standards
capacités

Externe, sans intention de Utilisateur de l’application avec des droits élevés, auditeurs tiers
11 nuire, avec des capacités Oui commandité, l'hébergeur (ex : entreprise réalisant des travaux dans la
importantes zone du data centre…).

Page 28 sur 145

 Type N° Sources de menaces Sélection Dénomination / justification si non retenue

Externe, sans intention de Non exposé à ce type de menace (activité industrielles susceptibles de
12 nuire, avec des capacités Non
provoquer des sinistres majeurs, explosions dans le voisinage…)
illimitées

13 Code malveillant d'origine Oui Malware non ciblé

inconnue

Usure naturelle, phénomènes météorologiques ou climatiques

14 Phénomène naturel Oui
imprévisibles mais récurrents : foudre, canicule, tempête…

Non humaines 15 Catastrophe naturelle ou Oui Le data centre de Vauban est situé dans une zone inondable
sanitaire

Non exposé à ce type de menace. (rongeurs, animaux dangereux pour

16 Activité animale Non
l'homme)

Incendie, inondation due à une rupture de canalisation, problème de

17 Événement interne Oui
climatisation, grève, défaillance technique, accident d'une personne…

Tableau 4 : Sources de menaces considérées pour l’analyse de risque

Page 29 sur 145

9.1 Les risques internes aux entreprises et organismes
Le réalisateur de l’analyse de risque est conscient dès le début de sa mission des risques encourus par les
entreprises et organismes pour lesquels il intervient. Ainsi, il garde en tête un ensemble de risques mais
n’oriente pas les personnes qu’il interroge durant sa mission et suit le déroulement de la méthode
d’analyse de risque qu’il a proposé à son client afin de ne pas fausser les résultats obtenus notamment
auprès des représentants métier. Pour se faire j’ai adopté ainsi une posture indépendante que l’on peut
comparer à la posture d’auditeur tel que présentée au sein de la norme ISO 19011 [18].
Les sous-chapitres qui vont suivre tracent les connaissances qu’il m’a été nécessaire soit d’acquérir soit de
développer pour mener à bien ma mission. Tout ingénieur à qui il est demandé de réaliser une mission
d’analyse de risque doit acquérir les connaissances macroscopiques suivantes car elles sont un préalable au
bon déroulement de la méthode d’analyse de risque.
Pour être pertinent et apporter une plus-value dans le cadre d’une analyse de risque il faut s’être forgé une
grande connaissance du sujet.

9.1.1 Les risques physiques

N’oublions pas avant toute chose de penser à la sécurité physique car la sécurité informatique n’a pas
toujours été la réponse par excellence face aux risques encourus. Un ordinateur connecté sans surveillance
est une porte ouverte sur des données confidentielles dont le vol ou la perte pourraient être critique. Lors
de la disparition de matériel, il ne suffit pas de prendre en compte la simple valeur matérielle des éléments
à remplacer, mais également le coût de reconstitution des données qui ont été perdues. Cette notion
représente un impact financier beaucoup plus élevé, tant par la non disponibilité de l’information que par
le temps nécessaire à sa restauration.
Qu’ils soient dus à des actes malveillants ou des accidents, les risques physiques encourus pourraient être
classifiés en trois grandes catégories :
 les destructions ;
 les pannes ;
 les vols.
Les équipements informatiques restent fragiles et sensibles à leur environnement. Les destructions
peuvent être liées à des risques accidentels, tels que les incendies, une explosion, inondation ou la foudre,
de même que certains dysfonctionnements et pannes. L’erreur humaine peut également entraîner de
graves conséquences (chocs, introduction de corps étrangers…) tout comme une mauvaise utilisation (oubli
de sauvegarde, écrasement de fichiers ou erreur d'utilisation…). Des actes de sabotage doivent aussi être
envisagés, dans le cas de destruction volontaire de ressources informatiques, mais l’acte malveillant le plus
courant envers le matériel informatique reste le vol d’équipement ou de données. La disparition
d’informations contenues sur un disque dur peut avoir des conséquences désastreuses pour une
entreprise, les ordinateurs portables étant particulièrement vulnérables face à cette menace, car ils
peuvent facilement être volés.

9.1.2 La confidentialité, notamment sur internet

La connexion d’une entreprise à internet représente l’ouverture de son système d’information sur
l’extérieur, ouvrant la porte à toutes les formes d’agressions. Mais la menace peut également venir de
l’intérieur, par les informations que les utilisateurs vont divulguer. Fournir des informations personnelles
sur un site internet par l’intermédiaire d’un formulaire (nom, adresse, numéro de carte de crédit, numéro

Page 30 sur 145

de sécurité sociale…) représente un risque potentiel. Ces informations peuvent être vendues pour des
opérations commerciales, ou être utilisées pour usurper une identité.
Les cookies stockés sur une machine sont une source de renseignements qui pose des problèmes de
confidentialité. Ces petits fichiers textes placés sur le disque dur de l'ordinateur permettent de garder la
trace des utilisateurs d’internet. Ils peuvent contenir, outre des informations concernant les visites de sites
internet, des données personnelles de l'utilisateur, telles que son nom ou son mot de passe. Ce n’est pas
anodin si la loi impose désormais aux responsables de sites et aux fournisseurs de solutions d'informer les
internautes et de recueillir leur consentement avant l'insertion de cookies ou autres traceurs. En France, la
CNIL qui est en charge de veiller à ce que l’informatique soit au service des citoyens et qu’il ne soit porté
atteinte ni à l’identité humaine, ni aux droits de l’homme, ni à la vie privée, ni aux libertés individuelles ou
publiques, réalise un travail primordial.
De manière générale, les utilisateurs ne connaissent pas l'usage des données qui sont récupérés à leur insu.
De même, l'adresse IP affectée à l'ordinateur connecté à internet permet de suivre la machine à travers les
sites visités. Il est ainsi possible de déterminer le parcours d’une personne sur la toile. L’anonymat n’est pas
non plus garanti lors de l’envoi de courrier électronique. Le destinataire peut ainsi facilement récupérer
l’adresse de l’expéditeur. Toujours en France, la CNIL met à disposition de tous, un outil de visualisation qui
identifie en temps réel les cookies qui transmettent des informations à d'autres sites, cet outil c’est
« Cookieviz ».

9.1.3 La divulgation

La divulgation d’informations internes à l’entreprise peut être malveillante mais elle peut également être
involontaire de la part des utilisateurs. Les pirates peuvent utiliser ce moyen pour se procurer des
renseignements précieux, on parle de « social engineering ». Cette méthode repose sur les points faibles
des personnes en relation avec le système informatique. Le but est de les piéger afin de leur faire révéler
leur mot de passe, non pas directement, mais via des informations qui pourraient s’avérer intéressantes
afin de découvrir ce mot de passe.
Une attaque directe pourrait consister à se faire faire passer pour un technicien, mentionnant qu’il a besoin
urgemment du mot de passe de l’utilisateur pour l’administration du système. Couplée à cette situation
d’urgence, cette technique ne laisse pas à l’utilisateur le temps de la réflexion (Technique de la contrainte
de temps). Une autre forme de « social engineering » consiste à deviner le mot de passe utilisateur à partir
des informations qu’il sème. Les pirates cherchent alors à obtenir le maximum de renseignements sur le
possesseur de la machine, d’où l’importance de ne pas choisir de mots de passe en rapport avec soi-même.
Ces méfaits sont commis par téléphone, mais ils peuvent également être menés par lettre, par contact
direct ou par courrier électronique. Pour cette solution, le pirate peut alors maquiller l’adresse source afin
de se faire passer pour l’interlocuteur qu’il désire.

9.1.4 Les infections

Les infections informatiques concernent les menaces engendrées par l’exécution d’un programme ou
l’ouverture d’un fichier corrompu sur une machine. Cette exécution entraîne alors l’installation d’un
programme malveillant. La plupart des infections est transmise par internet, généralement par les pièces
jointes du courrier électronique ou par des téléchargements. Ces programmes malveillants peuvent
appartenir à une des trois catégories suivantes :
 les virus ;
 les chevaux de Troie ;

Page 31 sur 145

  les vers.

9.1.4.1 Les virus

Un virus est un programme dont la fonction première est de se répliquer en incluant des copies de lui-
même dans différents éléments du système. Cette seule caractéristique permet de classer un programme
dans la famille des virus. Ceux-ci doivent obligatoirement être exécutés pour infecter la machine cible.
Leurs conséquences dévastatrices viennent des actions qu’ils exécutent en plus de leur fonction de
propagation. Ces actions peuvent être inoffensives, telles que l’apparition de messages à l’écran, ou
beaucoup plus graves, comme l’effacement ou l’altération de données.
Mais la gravité d’un virus n’est pas fonction de la rapidité de son action. En effet, un virus trop violent
détruisant immédiatement le support de données n’aura que peu de chances de survivre et peu de
conséquences face à une bonne politique de sauvegarde. En revanche, un virus agissant de manière
progressive pourra passer inaperçu suffisamment longtemps pour créer des dégâts irréversibles et rendre
les sauvegardes réalisées avant la contamination, obsolètes.
Les virus peuvent être classés suivant leur mode de propagation et leurs cibles :
- Les virus systèmes sont stockés dans la zone amorce d'un disque. Ce type de virus est chargé au
démarrage de la machine et réside alors en mémoire. La propagation de ce type de virus s’effectue lors du
démarrage d’une machine contenant une disquette contaminée. Les P.C. démarrant par défaut sous « A: »,
le code infecté du secteur d’amorce de la disquette contaminera celui du disque dur.
- Les virus de fichiers s'attachent à un exécutable (com, exe, bin, sys…) en modifiant la séquence des
instructions du programme ou en le remplaçant. Ces virus sont activés à chaque ouverture de ces fichiers et
restent en mémoire, infectant les programmes qui sont exécutés ensuite. D’autres virus de fichiers sont eux
non-résidents et infectent un programme au hasard lorsqu’ils sont exécutés. Ce type de virus est plus
fréquent car il est plus simple à écrire.
- Les macrovirus représentent une grande partie des virus actuels. Écrits dans un langage beaucoup plus
simple que l’assembleur nécessaire aux virus cités précédemment, ils infectent les fichiers d'une application
particulière (doc, xls…) par l’intermédiaire des macros. Les fichiers infectés sont des fichiers de données et
non des exécutables. Leur échange fréquent dans le monde de l’entreprise rend leur propagation plus
aisée.

Figure 5 : Un programme infecté.

Page 32 sur 145

9.1.4.2 Infection d’un programme par un virus
Le fait qu’il existe plusieurs variantes d’un même virus le rend d’autant plus difficile à détecter. C’est pour
cette raison que certains créateurs de virus ont pensés à faire modifier l’apparence de leur code lors de leur
réplication. On appelle ces programmes infectants virus polymorphes. D’autres virus ont la propriété d’être
furtifs, c’est à dire qu’ils vont se cacher lorsqu’un antivirus tentera d’accéder à un fichier infecté,
présentant à celui-ci une version saine du fichier.
La prolifération des programmes contaminants s’accélère, la conception d’un virus n’étant plus seulement
accessible aux informaticiens particulièrement talentueux. En effet, en plus des nombreuses
documentations sur le sujet, des programmes de création de virus à la carte circulent sur internet,
permettant la naissance de nouveaux programmes infectants en quelques clics de souris. De plus, les virus
deviennent de plus en plus sophistiqués, rendant leur détection toujours plus complexe.

9.1.4.3 Les vers

Un ver est un programme capable de s’auto-répliquer et de se propager d’une machine à l’autre par
l’intermédiaire d’un réseau. Contrairement aux virus, ils n’ont pas forcément besoin d’une intervention
humaine et d’un support pour se propager (programme hôte, fichier, disquette…). Certains vers peuvent
nécessiter l’ouverture d’une pièce jointe de courrier électronique par exemple, mais d’autres ont des
fonctions de propagation indépendantes. Ils utilisent des aspects particuliers des systèmes d’exploitation et
s’exécutent automatiquement lorsqu’ils sont introduits dans un nouveau système.
La plupart des vers utilisent les logiciels de messagerie pour se propager, en récupérant les listes de
courrier électronique contenues dans le carnet d’adresse et en s’envoyant automatiquement à chacun de
ces contacts. Certains vers évolués récupèrent des fragments de fichiers sur le disque dur et les joignent au
mail afin de berner le destinataire. D’autres vers sont capables de se propager en utilisant des protocoles
en dehors de la messagerie, et peuvent ainsi se diffuser de poste à poste.
Les vers épuisent les ressources des machines infectées (mémoire vive, ressources réseau…), provoquant
des ralentissements ou même des blocages système. Ils peuvent comporter une charge malveillante à la
manière des virus, et peuvent donc également engendrer des pertes de données.

9.1.4.4 Les chevaux de Troie

On appelle cheval de Troie, un programme effectuant des opérations malicieuses à l’insu de l’utilisateur. Il
se cache en général sous la forme d’un programme banal (jeu, application…) qui réalise une fonction
cachée sur la machine sur laquelle il est exécuté.
Leur objectif premier est d’ouvrir une porte dérobée (« backdoor ») sur la machine sur laquelle ils sont
placés, permettant à une personne extérieure d’accéder à la cible et d’y effectuer des actions. Par exemple,
le cheval de Troie représente un moyen aisé de récupérer des mots de passe en simulant l’interface de
saisie de ceux-ci. Un attaquant peut également épier ou recueillir des données, certains chevaux de Troie
évolués représentant de véritables outils d’administration à distance.
À la différence des vers et des virus, les chevaux de Troie ne s'étendent pas sur d'autres machines. Ils
doivent tout d’abord être introduits à l’aide d’un programme hôte, puis ils se cachent dans le système qu’ils
modifient pour pouvoir se lancer en même temps que la machine. Ce sont des serveurs qui restent à
l’écoute de demandes de connexion en provenance d’un éventuel attaquant, afin de recevoir des
instructions.

9.1.4.5 Les bombes logiques

Les bogues informatiques constituent également une menace envers la sécurité des informations. Outre
l’agacement qu’ils provoquent chez l’utilisateur, ils entraînent des problèmes de confidentialité, d’intégrité

Page 33 sur 145

ou de disponibilité. Les bogues ne sont pas une volonté de nuire, mais il existe des morceaux de code
placés dans un programme dans le but de provoquer des effets néfastes. Ces codes, appelés bombes
logiques, sont généralement placés par des informaticiens se sentant menacés de licenciement et voulant
se venger. Leur exécution est déclenchée à une date précise et entraîne une destruction de données qui
peut se révéler très grave pour la société victime.

9.1.4.6 Les faux virus

De faux virus, ou canulars, se propagent également par courrier électronique, généralement sous la forme
d’alertes concernant de nouveaux virus très destructeurs, en provenance d’organismes renommés. Reçus
par des personnes mal informées et soucieuses de mettre au courant leurs correspondants d'un danger
potentiel, ces canulars sont transmis de boîte aux lettres en boîtes aux lettres. Entretenant la peur
engendrée par les faux courriers et facilitant la prolifération de ces virus psychologiques, ces personnes
provoquent également un ralentissement du réseau par l’envoi massif de ces lettres électroniques.

9.2 Les attaques externes aux entreprises et organismes

L'utilisation grandissante des réseaux et d'internet au sein des entreprises, si elle améliore grandement
l'efficacité et la productivité, est également une cause croissante de risques liés à l'attaque, l'intrusion et le
piratage informatique. Les conséquences d'une attaque d'un système d'information peuvent atteindre les
trois grandes familles de risques. Dans une entreprise, les problèmes encourus peuvent avoir de graves
conséquences :
 perte de confidentialité, la perte de confidentialité est effective lorsque le pirate a eu accès à des
ressources sensibles, telles que les bases de données clients par exemple ;
 non disponibilité des ressources, celle-ci se produit si le pirate réussit à mettre hors service
certaines fonctionnalités réseau de l'entreprise attaquée ;
 perte de l'intégrité des données, par exemple, l'attaquant peut modifier le contenu des pages
HTML du site de l'entreprise entraînant une altération de son image de marque. Mais les
problèmes de piratage ne sont pas réservés aux entreprises. Les particuliers aussi sont la cible des
pirates informatiques, ne disposant généralement pas de moyens de protection et laissant ainsi la
porte ouverte sur leurs documents personnels. Les motivations des pirates informatiques sont
variées (curiosité, défi, revente d’information, dévalorisation de l’image d’une entreprise…), tout
comme leur mode d’action.
 les agresseurs potentiels peuvent ainsi être catégorisés dans une des familles suivantes:
o les « Hackers »: initialement, personnes maitrisant parfaitement un système d’exploitation ou
une technologie, devenues par la suite programmeurs informatiques de génie capable de
pénétrer les systèmes informatiques à distance, pour lesquels seule la prouesse technique
compte ;
o les « Crashers »: pirates qui détruisent pour le plaisir ;
o les « Lamers »: pirates informatiques débutants ;
o les « Script Kiddies »: pirates informatiques utilisant des utilitaires déjà existants ;
o les « Nuckers »: pirates arrivant à déconnecter ou faire planter un ordinateur distant ;
o les « Crackers »: pirates cassant les codes de protection des logiciels utilisables avec une
licence ;
o les « Phreakers »: pirates spécialisés dans la fraude aux télécommunications

Page 34 sur 145

Les chevaux de Troie constituent pour les pirates un moyen pour s’infiltrer dans un ordinateur, mais ils
n'ont pas toujours besoin d'un logiciel espion. L’intrusion d’un système passe par une très bonne
connaissance des failles du système cible et une bonne préparation pour obtenir les données nécessaires.
Divers outils disponibles sur internet permettent de s'essayer au piratage sans grande connaissance
préalable, permettant à des amateurs de créer des dommages sur les systèmes sans protection. On y
trouve par exemple des outils permettant de déterminer les caractéristiques des systèmes cibles, de
rechercher des entrées possibles sur une machine ou d’essayer un grand nombre de mots de passe.

9.2.1 L’attaque des mots de passe

Posséder un mot de passe valide constitue le moyen le plus simple d’accéder à une machine.
Aucun mot de passe n’est infaillible, et le temps passé pour le casser dépend uniquement de sa complexité.
Pour obtenir un mot de passe, le pirate possède plusieurs méthodes :
 le dictionnaire, l’utilisation d’un dictionnaire consiste à essayer le plus grand nombre de mots de
passe possible. Pour cela, le pirate utilise un programme nécessitant un fichier de mots qui va
essayer chacun de ces termes jusqu’à obtenir une autorisation d’accès sur la machine visée ;
 la force brute, la force brute est généralement utilisée lorsque l’attaque par dictionnaire a échoué.
Elle se déroule comme la précédente, mais les mots de passe utilisés ici n’ont pas de sens. Ils sont
générés par le programme au fur et à mesure de la tentative de connexion ;
 le programme espion, plus subtile que les précédentes, cette technique nécessite la présence d’un
programme sur la machine cible. Celui-ci va capter les entrées clavier et ainsi permettre de
récupérer des mots de passe de manière indirecte (simulation d’écrans de connexion, faux
formulaires…) ;
 le renifleur ou « sniffer », les renifleurs sont des programmes permettant la capture d’information
transitant sur la machine sur laquelle ils se trouvent. Le pirate peut ainsi récupérer de précieuses
données, dont les mots de passe circulant en clair sur le réseau.

9.2.2 L’usurpation d’adresse

Le but principal de l'usurpation d'adresse, ou « spoofing », est de profiter d'une relation de confiance entre
deux machines. En effet, certaines applications se fient à l'adresse émettrice d'un message pour autoriser
ou non une connexion, il est alors possible d’exécuter des commandes à distance. Mais cette technique
peut également servir à priver une machine de communication, lui renvoyer de fausses données ou
masquer l’identité du pirate. Pour profiter de cette caractéristique, le pirate doit créer ses propres paquets
dans lesquels il aura modifié l'adresse source. Il ne pourra cependant pas avoir de réponse à ses paquets,
son adresse ne correspondant pas à celle de retour des messages.
Cette technique comprend :
 L’ARP spoofing, l’ARP spoofing est spécifique aux réseaux locaux et repose sur la falsification
d'adresses MAC. La trame modifiée contient l’adresse IP de la machine cible et une fausse adresse
MAC. La machine visée ne pourra plus recevoir de messages, les autres machines du réseau
envoyant des données à une fausse adresse MAC ;
 L’IP spoofing, cette technique consiste à forger des paquets IP contenant une fausse adresse
source afin d’établir une relation de confiance avec les machines du réseau visé.

Page 35 sur 145

 Figure 6 : L'usurpation d'adresse IP.

 l’email spoofing, le spoofing consiste à usurper l'adresse d'origine d'un courrier électronique. Cette
technique est particulièrement utile au pirate afin de cacher son identité lors d'une attaque de
type inondation ;
 le DNS spoofing, cette attaque consiste à altérer les tables de correspondance nom/adresse d'un
serveur DNS ;
 le Web spoofing, il s'agit d'une attaque du type homme du milieu (Man In The middle). Les
requêtes HTTP de la victime sont détournées et des informations erronées lui sont renvoyées.
Celle-ci navigue alors sur un faux site internet.

9.2.3 L’inondation

L’inondation, ou « flooding », consiste à envoyer très rapidement de gros paquets d'information à une
machine ou un réseau afin de saturer ses ressources et de le rendre indisponible. La forme la plus
commune de cette attaque est la consommation de la bande passante du réseau cible. Disposant de plus
de bande passante que la victime par regroupement ou détournement de machines, les pirates
parviennent à inonder sa connexion réseau. Le « smurf », par exemple, consiste à envoyer un PING
contenant l’adresse source de la cible vers une adresse de diffusion. Le PING sera transmis à toutes les
machines du réseau, qui répondront alors en direction de la cible. Un flot continu de PING vers cette
adresse de diffusion aura alors pour conséquence la congestion du réseau due à l’importance du trafic.
L’autre forme de l’attaque par inondation est l’épuisement des ressources. Elle se distingue de la
précédente dans la mesure où elle est axée sur un système et non sur un réseau. Un serveur ainsi attaqué
ne sera plus capable d’accepter de connexions et pourra même se bloquer.
Le « SYN flooding », par exemple, repose sur l'établissement de connexions TCP. Il consiste en l’envoi d’une
rafale de connexions TCP non finies, empêchant ainsi les connexions normales sur le serveur visé.

Page 36 sur 145

Cette attaque dirigée vers un serveur de courrier électronique est appelée « mail bombing ». Elle consiste à
saturer l’espace alloué au stockage des messages et à bloquer ainsi les nouvelles arrivées. Les pirates
réalisant une inondation prennent soin de masquer leur adresse à l’aide de la technique d’usurpation
d’adresse décrite précédemment.

9.2.4 Le refus de service

Une attaque de refus de service, ou déni de service, provoque un dérangement ou interrompt totalement
la fourniture de service à des utilisateurs ou des systèmes. Le refus de service peut être utile au pirate dans
le cas où il lui est nécessaire de redémarrer la machine sur laquelle il évolue. En effet Certaines
modifications ne sont appliquées qu’après un redémarrage, ce qui explique l’utilité de planter un système
pour forcer son utilisateur à le remettre en route. Malmener un système étant plus facile que d’en obtenir
l’accès, le pirate peut également utiliser le refus de service par dépit, repoussé par une politique de sécurité
efficace. De plus, l’objet d’une telle attaque ne nécessite en général que peu de compétences techniques,
les outils requis étant largement disponibles sur internet.
De nombreuses méthodes permettent d’aboutir à un refus de service. Parmi celles-ci on peut citer les
attaques par inondation citées précédemment, soit par consommation de bande passante, soit par
épuisement des ressources. Mais les attaques de refus de service peuvent également être menées par
l’intermédiaire de défauts de programmation. Liés à un système d’exploitation, ce sont les incapacités à
gérer des conditions exceptionnelles. L’envoi de longues chaînes de données peut provoquer un
débordement de tampon et bloquer l’application, ou pire, provoquer l’exécution de commandes
malveillantes.

Page 37 sur 145

9.3 Panorama d’attaques techniques
L’application sur laquelle porte l’analyse de risque qu’il nous est demandé de réaliser est hébergée par un
système d’information. Il est donc nécessaire de connaitre une vaste gamme d’attaque technique qui peut
être réalisées. Les sous-chapitres suivants présentent les attaques que j’ai gardées en mémoire au fur et à
mesure de la réalisation de ma mission.

9.3.1 Attaque sur les communications

Soit un flux normal, d’une source A vers une destination B. Cinq catégories d’attaques sur une
communication sont possibles.

 l’interception (impact sur l’intégrité et la confidentialité) ;

 l’usurpation (impact sur la confidentialité) ;
 la répétition (impact divers, mais notamment sur la disponibilité) ;
 l’injection (impact sur l’intégrité) ;
 l’interruption (impact sur la disponibilité).
Bien sûr, des mélanges d’attaques peuvent être envisagés.

9.3.2 Attaque dite de « l'homme du milieu »

Si l’attaquant intercepte la clé publique que A voulait envoyer à B et y substitue la sienne : il peut lire tous
les messages émis par B et se faire passer pour A auprès de B.
Remède : Pour qu'une clé publique soit fiable, elle doit être validée et protégée.

9.3.3 Attaque par force brute

Possible avec les algorithmes utilisant des clés trop petites, à partir d'un échantillon en clair et de sa valeur
chiffrée, l’attaquant tente toutes les clés possibles.
Remède : respecter les référentiels de sécurité, tels que le RGS, pour choisir les éléments secrets.

9.3.4 Attaque par répétition

L’attaquant envoie la copie d'un ancien bulletin avec son résumé…

Remède : apposez une estampille temporelle ou un numéro sur les messages

9.3.5 Attaque par imitation du condensé

Si L’attaquant peut produire un condensé équivalent à celui émis par Alice, il peut substituer le message
original.
Remède : d'où l'utilisation de codes MAC plutôt que MIC…

9.3.6 Vol de clés en mémoire

(Découverte par Shamir de « RSA »)

Les clés doivent être aussi aléatoires que possible : elles contiennent donc approximativement autant de 0
que de 1. Un examen attentif de la mémoire doit permettre de trouver la clé.

Page 38 sur 145

Remède : Il faut scinder les clés en mémoire en plus petits blocs possibles.

9.3.7 Attaque par "couper-coller"

L’attaquant insère des blocs de texte chiffré frauduleux en profitant des blocs de remplissage ajoutés par
les algorithmes de chiffrement.
Remède : Ajouter un résumé.

9.3.8 Attaque du texte clair choisi

Si L’attaquant suppose le contenu d'un message chiffré émis de A vers B et connait la clé publique de B, il
va tenter de reproduire le texte clair supposé, de le crypter avec la clé publique pour retrouver le message
chiffré.
Remède : Ajouter des caractères de remplissage pour ajouter du bruit.

9.3.9 Attaques des anniversaires

Sur des algorithmes de condensé, à résistance faible aux collisions :

Celui qui crée le message original peut créer, plus facilement que celui qui le reçoit, une paire de messages
différents qui produisent le même condensé.
L'analogie avec les anniversaires est la suivante :
Si B cherche quelqu'un qui est né le même jour que lui, il devra en moyenne demander à 180 personnes
avant d'en trouver une.
Par contre, si A cherche 2 personnes nées le même jour ! À partir de deux personnes qui ne correspondent
pas, la 3ième a 2 chances sur 365 de convenir, la 4ième, 3 chances sur 365 etc… La tâche de A est donc plus
facile.
Remède : quand on vous donne un document à signer, apportez-y préalablement une légère
modification.

9.3.10 Attaque de Bleichenbacher

Daniel Bleichenbacher, un cryptographe Suisse [19], a montré que l'algorithme de remplissage de PKCS#1
était attaquable. Un message pouvait être déchiffré si A répondait à 1.000.000 de messages tests émis par
L’attaquant (possible avec les automates). (Voir le journal Misc n°4)
Ainsi que les attaques "par effet de bord" (utilisation des messages d'erreur retournés en cas de padding
erroné).

9.3.11 Attaque de RSA [20]

Imaginons que B dispose d'un automate qui émette un reçu pour chaque message chiffré, authentifié et
réceptionné.
Si L’attaquant émet à B le message chiffré et signé que A a déjà émis à B :
B le déchiffre avec sa clé privée
B le vérifie avec la clé publique de L’attaquant : le résultat n'annule pas la signature de A mais l'automate
retournera l'accusé de réception, chiffré avec la clé privée de B et la clé publique de L’attaquant

Page 39 sur 145

L’attaquant peut connaitre alors le véritable message émis par A vers B, car il peut utiliser la clé publique de
A pour décoder le message.
Cette méthode ne fonctionne qu'avec les algorithmes dont les clés publiques et privées servent au
chiffrement ET au scellement (RSA).
Toujours modifier des données reçues avent de les renvoyer signées !
Remède : Ne jamais signer avec votre clé privée des messages de provenance inconnue.

Utilisez une méthode pour la confidentialité et une autre méthode pour signer.
Rôles et places des langages Java, JavaScript et PHP

9.3.12 Cross-Site Scripting (XSS et XSRF)

9.3.12.1 Cross-Site Request Forgery

Les attaques de type Cross-Site Request Forgery (abrégées CSRF prononcées sea-surfing ou parfois XSRF)
utilisent l'utilisateur comme déclencheur, celui-ci devient complice sans en être conscient. L'attaque étant
actionnée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés [21].

9.3.12.2 Cross-site Scripting

Le Cross-Site Scripting (abrégé XSS), est un type de faille de sécurité des sites web permettant d’injecter du
contenu dans une page, permettant ainsi de provoquer des actions sur les navigateurs web visitant la page.
Les possibilités des XSS sont très larges puisque l’attaquant peut utiliser tous les langages pris en charge par
le navigateur (JavaScript, Java, Flash…) et de nouvelles possibilités sont régulièrement découvertes
notamment avec l’arrivée de nouvelles technologies comme HTML5. Il est par exemple possible de rediriger
vers un autre site pour du hameçonnage ou encore de voler la session en récupérant les cookies [22].

Page 40 sur 145

9.3.13 Injection SQL

Une injection SQL est un type d'exploitation d'une faille de sécurité d'une application interagissant avec
une base de données, en injectant une requête SQL non prévue par le système et pouvant compromettre
sa sécurité [23].

9.4 Petit panorama d’attaques qui ont eu lieux

Nous avons vu que les risques encourus sont nombreux et variés. On peut les classer en deux
grandes catégories, les risques naturels et les risques spécifique.
Les risques naturels [24], tempêtes, inondations, séismes… ou provoqués - glissements,
tassements… ne sont pas les seuls éléments des risques « naturels ». Les conséquences de leurs
effets que l’on doit prévoir, telle qu’une coupure de courant accidentelle, sont des risques à traiter
(onduleur par exemple). Il faut garder à l’esprit qu’il sera possible de tenter de circonscrire un
départ de feu mais il sera impossible d’éviter un tremblement de terre ou encore une explosion à
proximité de notre système d’information.
En, ce qui concerne les risques spécifiques, voici quelques cas réels d’attaques connues, reprises
par le Clusif, qui éclairerons ce mémoire tout comme elles m’ont permises d’éclairer mes propos
auprès de mon client dans le cadre de ma mission. Leur diversité est impressionnante et présenter
un cas réel est toujours bien plus parlant aide à illustrer les propos et à prendre des décisions en
connaissance de cause.

9.4.1 Le problème des « Mules »

Une personne malveillante cherche à récupérer des fonds illégalement acquis par phishing
(Hameçonnage [25]), Cheval de Troie [26], keylogger (Enregistreur de frappe [27], etc. et va
recruter un internaute crédule en lui faisant miroiter un gain substantiel. Il servira alors
d’intermédiaire local pour transférer les fonds et sera le premier incriminé dans cette arnaque.

9.4.2 Le problème des SPIT (SPam over Internet Telephony [28])

Un automate lance des appels en grand nombre sur des numéros de téléphones GSM mais
interrompt la communication dès la première sonnerie. Il n’y a donc aucune facturation pour
l’émetteur des appels. La victime, voyant qu’elle a reçu un appel qui n’a pas abouti risque de
rappeler et le numéro rappelé est surtaxé.

9.4.3 La Manipulation des cours de bourse (Pump and dump [29])

L’attaquant parvient à convaincre un nombre important de personnes à acheter des actions de telle
ou telle entreprise après en avoir lui-même acheté une grande quantité à un cours en bourse bien
inférieur. Son but est de faire monter le cours de ces actions. Il les achète à prix bas et les revends à
prix forts.

9.4.4 L’escroquerie financière

Escroquerie aux placements financiers sur Internet. Un lycéen américain de 17 ans a organisé une
escroquerie aux placements financiers. L’escroquerie lui a rapporté plus d’un million d’euros. En un
mois et demi (entre le 1er novembre et le 15 décembre 2001), le jeune homme avait créé une
société d'investissements ("Invest Better 2001") avec pour vitrine, un site Web et un bulletin

Page 41 sur 145

 Internet. Appât : proposition de placements « garantis et sans risques » avec promesses de
rendement de 125 % à 2500 %. Plus de 1000 victimes se sont fait escroquer. Il est épinglé par la SEC
(Securities and Exchange Commission).

9.4.5 Le chantage

Août 2002 –JAPON. L’entreprise japonaise Fujitsu reconnaît avoir été victime d’un chantage. Des
Informations confidentielles liées au système informatique de la Défense ont été obtenues par un
programmeur sous-traitant pour Fujitsu. Preuve a été apportée par le maître-chanteur dans un
document imprimé de 10 pages : informations sur la manière dont sont reliés les ordinateurs de la
« Ground Self Defence Force » plus d’autres informations sur le système de Défense aérienne
comme les adresses IP des ordinateurs et des informations relatives au réseau les reliant. La
menace était de diffuser toutes ces informations à la Corée du Nord si Fujitsu ne versait pas une
certaine somme, ce qu’elle a refusé de faire.

9.4.6 Des unités chinoises de cyber-espionnage

Rapport du 18 février 2014 par la société américaine Mandiant. Spécialisée dans le conseil en
sécurité informatique. Spécialistes des attaques dites APT ("Advanced Persistent Threat"), les
experts en sécurité ont concentré leurs efforts sur l'analyse d'attaques émanant de groupes chinois.
Au fil de l'enquête il est apparu qu'un groupe, nommé APT1, concentrait à lui seul, pratiquement
150 victimes d'intrusion durant les 7 dernières années. Le rapport de la société Mandiant avance
même l'hypothèse d'un lien quasi-direct entre cette unité de cyber-espions et l'armée chinoise PLA
(People’s Liberation Army), précisant qu'un tel groupe ne peut se vanter de campagnes d'intrusions
aussi larges et longues sans que l'État Chinois n'en soit au courant, voire même sans qu'il n'y
apporte son soutien. 2014 [30, p. 1]

9.4.7 Les révélations d'Edward Snowden

Les révélations d'Edward Snowden commencent avec un important volume de documents (d'abord
estimé entre 15 et 20 000, chiffre ensuite constamment réévalué à la hausse pour atteindre 1,7
million en décembre 2013) transmis par Edward Snowden à deux journalistes, Glenn Greenwald et
Laura Poitras, et progressivement rendus publics à partir du 6 juin 2013 à travers plusieurs titres de
presse. Elles concernent la surveillance mondiale d'internet, mais aussi des téléphones portables et
autres moyens de communications, principalement par la National Security Agency américaine
(NSA). [31]

9.4.8 Les attaques «waterholing» (attaque du point d’eau [32])

Une méthode simple mais très efficace quand elle est bien ciblée. Piéger un site web visité par les
cibles puis, compromettre le site web, y déposer des pages et/ou du code malveillant, puis attendre
les visites et les infections des postes pour au final exploiter les données collectées. [33]

10 Préparer les métriques

Les sous-chapitres précédents m’ont permis de définir le cadre de la gestion des risques et le monde dans
lequel nous avons à opérer. Ce travail de recherche m’a été nécessaire afin de saisir le périmètre et
l’ampleur de la tâche qui m’a été confié et cette phase sera toujours nécessaire aux ingénieurs en amont de

Page 42 sur 145

la réalisation d’une analyse de risque pour qui souhaite pouvoir contextualiser sa mission et faire des
propositions les plus pertinentes.
À présent, je vais vous présenter la phase de préparation des métriques utilisées dans le cadre de l’analyse
de risque que j’ai réalisée. Ces métriques peuvent être adaptées en fonction de nombreux critères,
l’essentiel c’est de les valider avec le commanditaire de l’analyse de risque.

10.1 Les métriques utilisées

Les critères de sécurité retenus dans le cadre des analyses de risque seront toujours les critères de
Disponibilité, Intégrité, Confidentialité et au besoin de Trace/Preuve bien que l’on puisse imbriquer ces
critères au sein du critère d’intégrité de par une manipulation réfléchie lors de l’expression des besoins de
sécurité ce que j’ai réalisé dans le cadre de ma mission.
Afin d'exprimer ces besoins de sécurité, on retiendra toujours les critères de sécurité définis dans la PSSI de
l’entreprise ou de l’organisme qui s’applique à la situation. Dans le cas ou plusieurs PSSI sont applicables à
un même projet on retiendra alors la PSSI qui a été déclinée le plus finement vis-à-vis du périmètre de
l’analyse, cette dernière ne doit en toute logique pas contredire la politique mère à partir de laquelle elle a
été déclinée et est normalement plus détaillée que cette dernière.

10.1.1 Critères de sécurité

Afin de mener une étude la plus pertinente possible il est nécessaire de cadrer le plus possible cette étude
et les méthodes d’analyses de risque sont là pour nous y aider. À ce stade afin d’éviter toute ambiguïté il
faut définir finement des attendus.

Critères de sécurité Définitions

Disponibilité Propriété d'accessibilité au moment voulu des biens essentiels.

Intégrité Propriété d'exactitude et de complétude des biens essentiels.

Propriété des biens essentiels de n'être accessibles qu'aux utilisateurs

Confidentialité
autorisés.
Tableau 5 : Critères de sécurité retenus pour l’étude
Note Bene : Pour cette étude j’ai lié le critère de traçabilité au critère d’intégrité. La traçabilité correspond
à une contrainte légale, juridique et de sécurité au sens large plutôt qu’a un besoin spécifique.

Page 43 sur 145

10.1.2 Échelle de disponibilité

À gauche un niveau, au milieu une description détaillée de l’échelle plutôt générale est proposée et
contextualisée vis-à-vis du contexte client à droite. Les métriques ont été validées par le pôle de
compétence sécurité du client puis durant mes nombreux entretiens j’ai systématiquement représenté les
métriques utilisées à mes interlocuteurs.

Disponibilité
Niveaux de
Description détaillée de l'échelle Description orientée Entreprise/organisme utilisateur
l'échelle
Le service fournit dispose d'un délai maximal
Le bien essentiel a un délai
Aucun ou d’interruption tolérable pouvant aller d'une semaine à
maximal d’interruption autorisée
Faible (D1) un mois avant d'impacter plus ou moins faiblement un
entre une semaine et un mois.
service, une direction ou un organisme utilisateur.
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller de 3 à 5 jours
Le bien essentiel a un délai
consécutifs ouvrés avant d'impacter plus ou moins
Moyen (D2) maximal d’interruption autorisée
modérément un service, une direction ou un organisme
de 3 à 5 jours consécutifs ouvrés.
utilisateur avec a minima 1 type d'impact de gravité
"modérée".
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller de 1 à 2 jours
Le bien essentiel a un délai
consécutifs ouvrés avant d'impacter plus ou moins
Critique (D3) maximal d’interruption autorisée
significativement un service, une direction ou un
de 1 à 2 jours consécutifs ouvrés.
organisme utilisateur avec a minima 1 type d'impact de
gravité "significative".
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller jusqu'à une
Le bien essentiel a un délai
journée (8 heures) avant d'impacter plus ou moins
Majeur (D4) maximal d’interruption autorisée
gravement un service, une direction ou un organisme
d’une journée (8 heures).
utilisateur avec a minima 1 type d'impact de gravité
"grave".
Tableau 6 : Échelle de disponibilité retenue pour l’étude

Page 44 sur 145

10.1.3 Échelle d’intégrité

Le travail est le même pour l’échelle d’intégrité.

Intégrité
Niveaux de Description orientée Entreprise/organisme
Description détaillée de l'échelle
l'échelle utilisateur

Une perte ou modification non prévue, Une perte ou modification non prévue, volontaire
Aucun ou volontaire ou non volontaire, n’affecte ou involontaire, n’affecte en rien ou faiblement les
Faible (I1) en rien les activités d’un service, d’une activités d’un service, d’une direction ou d’un
direction ou d’un organisme utilisateur. organisme utilisateur.

Aucune modification non autorisée

n’est acceptée. L’exactitude des Aucune modification non autorisée n’est acceptée.
informations est avérée mais sans L’exactitude des informations doit être avérée mais
contrôle particulier. La modification sans contrôle particulier. Une modification non
illicite des informations traitées ne autorisée va impacter plus ou moins modérément
Moyen (I2)
provoque pas de gêne significative pour un service, une direction ou un organisme
un service ou direction ou un utilisateur avec un ou plusieurs types d'impact de
organisme utilisateur. Un contrôle à gravité "modérée". Un contrôle à posteriori est
posteriori est suffisant pour détecter suffisant pour détecter toute modification.
toute modification illicite.
Aucune modification non autorisée n’est acceptée
et toute modification autorisée doit être tracée.
Aucune modification non autorisée Une modification non autorisée et tracée va
Critique (I3) n’est acceptée et toute modification impacter plus ou moins significativement un
autorisée doit être tracée. service, une direction ou un organisme utilisateur
avec un ou plusieurs types d'impact de gravité
"significative".
Aucune modification non autorisée Aucune modification non autorisée n’est acceptée
n’est acceptée et toute modification et doit être détectée automatiquement le plus
autorisée doit être tracée de façon rapidement possible. Toute modification autorisée
sécurisée. L’exactitude des doit être tracée de façon sécurisée. L’exactitude
informations et l’authenticité des des informations et l’authenticité des transactions
Majeure (I4) transactions sont garanties par un sont garanties par un procédé technique
procédé technique difficilement difficilement contournable. Une modification non
contournable. La modification illicite autorisée et tracée va impacter plus ou moins
n’est pas tolérée et doit être détectée gravement un service, une direction ou un
automatiquement, le plus rapidement organisme utilisateur avec un ou plusieurs types
possible. d'impact de gravité "grave".

Tableau 7 : Échelle d’intégrité retenue pour l’étude

Page 45 sur 145

10.1.4 Échelle de confidentialité

Le travail est également le même pour l’échelle de confidentialité.

Confidentialité
Niveaux de Description détaillée de Description orientée Entreprise/organisme
l'échelle l'échelle utilisateur
La diffusion d’une
information dans le domaine La diffusion d’une information dans le domaine
public n’affecte en rien les public n’affecte en rien ou faiblement les activités
Aucun (C1)
activités d’un service, d’une d’un service, d’une direction ou d’un organisme
direction ou d’un organisme utilisateur.
utilisateur.
Ce niveau traduit que la Ce niveau traduit que la diffusion est seulement
diffusion est seulement possible en interne et au sein des organismes
possible en interne et au sein utilisateurs, ainsi qu’à l’ensemble de l’Administration
Non publique
des organismes utilisateurs, et de ses prestataires. Une divulgation non autorisée
(C2)
ainsi qu’à l’ensemble de va impacter plus ou moins modérément un service,
l’Administration et de ses une direction ou un organisme utilisateur avec un ou
prestataires. plusieurs types d'impacts de gravité "modérée".
Ce niveau restreint la diffusion d’information au
Ce niveau restreint la niveau d’une direction, d’un service, d’un projet
diffusion d’information au métier ou transverse. Une divulgation non autorisée
Confidentiel
niveau d’une direction, d’un va impacter plus ou moins significativement un
(C3)
service, d’un projet métier ou service, une direction ou un organisme utilisateur
transverse. avec un ou plusieurs types d'impact de gravité
"significative".
Ce niveau restreint la diffusion d’information à
Ce niveau restreint la
quelques agents, ou externes, nommément identifiés
Très diffusion d’information à
pour un sujet donné. Une divulgation non autorisée
confidentiel quelques agents, ou externes,
va impacter plus ou moins gravement un service, une
(C4) nommément identifiés pour
direction ou un organisme utilisateur avec un ou
un sujet donné.
plusieurs types d'impact de gravité "grave".
Tableau 8 : Échelle de confidentialité retenue pour l’étude

Page 46 sur 145

10.1.5 Échelle de gravité

L’échelle de gravité est très intéressante, il s’agit de faire exprimer aux responsables métier sur un
ensemble de thèmes retenus quel serait l’impact pressenti. Ainsi ce qui m’a étonné c’est que dans le
cadre de cette mission à propos de l’impact financier il n’y a pas de chiffre associé. En effet, on
pourrait associer un impact financier grave à une somme, par exemple 1 million d’euros, mais j’ai fait
le constat qu’il est très difficile de faire exprimer ce genre d’informations.
Impacts par type

Exemples d'événements
Description Financier Juridique Activité Image
redoutés
Indisponibilité limitée d'une
activité non critique (supportée
L'entreprise et par l'application étudiée) pour
Détérioration
l'ensemble un ou plusieurs organismes
modérée de
des utilisateurs.
la relation Mention
utilisateurs de Perte
avec un tiers négative
ses financière Altération partielle d'une base
1 – Faible Avertissement et/ou ponctuelle
applications faible ou de données non sensible pour
perturbation dans un
surmonteront nulle une application.
limitée de média
les impacts
l'activité de
sans aucune Consultation d'information non
l'organisme
difficulté. publiques mais non sensibles
par une personne hors de la
sphère prévue.

L'entreprise et Mention Indisponibilité temporaire

Détérioration
l'ensemble négative d'une activité importante
de la relation
des dans les (supportée par l'application
avec
utilisateurs de médias étudiée) pour un ou plusieurs
Perte plusieurs tiers
ses avec organismes utilisateurs.
2– financière significatifs
applications Amende atteinte à
Modéré jugée et/ou
surmonteront la Fuite d'informations non
modérée perturbation
les impacts réputation publiques ayant une sensibilité
moyenne de
malgré pour une limitée.
l'activité de
quelques ligne
l'organisme
difficultés. métier Fraude à l'impact modéré.

Indisponibilité prolongée d'une

Mention activité importante (supportée
L'entreprise et Perte de la
négative par l'application étudiée) pour
l'ensemble gestion d'un
dans les un ou plusieurs organismes
des SI pour
médias utilisateurs.
utilisateurs de l'entreprise /
Perte avec
ses Responsabilité incapacité à
3– financière atteinte à Base de données d'une
applications morale de la réaliser une
Significatif jugée la application importante critique
surmonteront personne activité
significative réputation altérée partiellement.
les impacts significative
de l'entité
avec de pour un
d'une Fraude à l'impact significatif.
sérieuses organisme
durée
difficultés. utilisateur
limitée Vol de données sensibles dans
une application.

Page 47 sur 145

 Impacts par type

Exemples d'événements
Description Financier Juridique Activité Image
redoutés
Indisponibilité prolongée d'une
Perte de la
activité critique (supportée par
gestion de
L'entreprise l'application étudiée) pour
l'ensemble Mention
ou certains plusieurs organismes
des SI sous négative
des utilisateurs.
Responsabilité responsabilité dans les
utilisateurs de
pénale du pour médias
ses Perte Bases de données d'une
Directeur / du l'entreprise / avec
applications financière application critique altérées et
4 – Grave Responsable incapacité à atteinte à
ne jugée inutilisables.
de réaliser ses la
surmonteront inacceptable
l'organisme activités réputation
pas les Fraude à l'impact très
utilisateur majeures de l'entité
impacts (leur important.
pour un ou de façon
survie est
plusieurs irréversible
menacée). Fuite d'informations classifiées
organismes
pouvant nuire aux intérêts de
utilisateurs
l’entreprise.

Tableau 9 : Échelle de gravité retenue pour l’étude

Page 48 sur 145

10.1.6 Échelle de vraisemblance générale

L’échelle de vraisemblance générale est à destination de la réflexion générale autour des scénarios de
menaces.
Niveau
Intérêt à réaliser le
d'exposition de
scénario de
Niveau de la vulnérabilité
Niveau de menace pour la Moyens
compétence (corrélé
Description Score source de menace nécessaires
vraisemblance nécessaire inversement aux
malveillante (malveillance)
(malveillance) moyens
(théorique &
nécessaires pour
historique)
l'exploiter)

1. Faiblement probable
ou nécessite des moyens
très importants et/ou des Cela ne devrait pas se
1 Expert Très limité Importants Très limité
connaissances très (re)produire.
élevées dans le domaine
considéré
2. Moyennement
probable (Modéré) ou
Cela pourrait se Solide
nécessite un certain 2 Moyen Conséquents Moyen
(re)produire. compétence
niveau d'expertise et/ou
du matériel spécifique
3. Probable ou réalisable
Cela devrait se Niveau
avec des moyens
(re)produire un jour ou 3 élémentaire Important Faibles Important
standards et/ou avec des l'autre. informatique
connaissances de base
Cela va certainement
4. Très probable (Presque Sans
se
certain) ou réalisable par 4 compétence Très Fort Aucun Très Fort
(re)produire
tout public spécifique
prochainement.

Tableau 10 : Échelle de vraisemblance retenue pour l’étude

Page 49 sur 145

10.1.7 Échelle de vraisemblance avec exemples

L’échelle de vraisemblance avec exemples est à destination de la réflexion contextualisée en fonction du

RETEX (Retour sur Exercice) de l’entreprise, c'est-à-dire de son passé, de son historique.
Probabilité d’apparition
(théorique & historique Entreprise)
Fréquence
d'apparition
Connaissances Exemples dans le monde
Exemples dans le
Niveau de vraisemblance Score du passé pour un organisme
Entreprise monde pour
Entreprise comparable
un organisme
comparable
Sinistre majeur :
1. Faiblement probable ou crash/détournement d'avion,
nécessite des moyens très Ne s'est jamais catastrophe naturelle, attaque
Rare ou ciblé par un code malveillant
importants et/ou des 1 produit à N/A
exceptionnel sophistiqué,
connaissances très élevées l'Entreprise incendie/inondation/destruction
dans le domaine considéré complète d'un Data centre ou
siège social, pandémie.

Violation
2. Moyennement probable majeure de la
(Modéré) ou nécessite un S'est déjà produit charte
Chantage, cyber attaque
certain niveau d'expertise 2 au moins une fois d'utilisation 1x par an
massive.
et/ou du matériel dans l’entreprise entrainant une
mesure
spécifique disciplinaire

Fraude interne, déni de service

3. Probable ou réalisable sur un site web, vol
Se produit au Panne matériel,
d'informations sensibles par un
avec des moyens standards défaillance
3 moins une fois
opérateur
1X par mois hacker ou un espion,
et/ou avec des par an défacement de site web,
télécom
connaissances de base infection virale d'un réseau
complet.

Réception de Réception de virus

4. Très probable (Presque Se produit au virus informatiques, erreurs de
certain) ou réalisable par 4 moins une fois informatiques, 1X par semaine manipulation, vol d'ordinateurs
tout public par trimestre erreur de portables, défaillances
manipulation techniques.

Page 50 sur 145

10.1.8 Les critères de gestion des risques

Ces critères de gestion explicitent la démarche proposée au client. Ainsi la méthode mise en œuvre afin de
réaliser l’analyse de risque est totalement traçable, étapes par étapes, via la colonne de droite.

Action Critère de gestion des risques (règle choisie pour réaliser l'action)

Les besoins de sécurité des biens essentiels sont exprimés à l'aide des
Expression des besoins de sécurité (module 2)
échelles correspondantes, selon le critère de sécurité étudié.

Les événements redoutés sont estimés en termes de gravité à l'aide de

Estimation des événements redoutés (module 2)
l'échelle définie à cet effet.

Évaluation des événements redoutés (module 2) Les événements redoutés sont classés par ordre décroissant de gravité.

Les scénarios de menaces sont estimés en termes de vraisemblance à l'aide

Estimation des scénarios de menaces (module 3)
de l'échelle définie à cet effet.

Les scénarios de menaces sont classés par ordre décroissant de

Évaluation des scénarios de menaces (module 3)
vraisemblance.

- La gravité d'un risque est égale à celle de l'événement redouté considéré.

Estimation des risques (module 4) - La vraisemblance d'un risque est égale à la vraisemblance maximale de tous
les scénarios de menaces liés à l'événement redouté considéré.

Évaluation des risques (module 4) cf. planche matrice de criticité

Choix de traitement des risques (module 4) cf. planche matrice de criticité

Le traitement des risques ne peut être validé que s'il est démontré que les
Homologation de sécurité (module 5)
risques résiduels sont acceptables.

Tableau 11 : Critères de gestion des risques retenus pour l’étude

10.1.9 Matrice de criticité des risques

Lorsque l’on fait se rejoindre vraisemblance et impact cela nous donne la criticité du risque qui a été
analysé.
Vraisemblance
1 2 3 4
4 4 8 12 16
3 3 6 9 12
Impact

2 2 4 6 8
1 1 2 3 4
Tableau 12 : Matrice de criticité des risques

Page 51 sur 145

10.1.10 Stratégie de gestion du risque

Il est nécessaire de définir avec le client une stratégie de gestion du risque. Le tableau ci-dessous présente
une stratégie mais c’est au client de valider cette dernière l’ingénieur est là pour l’accompagner et le
conseiller.
valeur du
Niveau du risque Stratégie de gestion du risque
risque
Risque mineur peut être accepté R<4
Risque moyen doit être réduit à un niveau acceptable 4≤R<7
Risque important doit être réduit à un niveau acceptable 8 ≤ R < 10
Risque majeur doit être réduit à un niveau acceptable R ≥ 12
Tableau 13 : Stratégie de gestion du risque
Les risques mineurs (verts) sont acceptables. Pour chacun des autres risques, au moins une solution de
traitement qui amène le risque à un niveau mineur doit être proposée par l’ingénieur. Dans le cas où la
solution proposée est complexe (durée ou coût important, ressources complexes à trouver…) des solutions
alternatives et moins complexes doivent être proposées pour le court terme (dans ce cas il peut être
acceptable que le niveau du risque résiduel après leur mise en place ne soit pas forcement mineur). Dans le
cas d’un choix multiple de solutions de traitement, ce sont la Direction de l’entreprise et éventuellement
des organismes comme la commission d’homologation RGS pour l’État qui arbitreront la décision finale.

11 Identifier les biens

L’objectif de ce chapitre est de référencer les fonctions et les données traitées dans l’application de notre
étude de cas. Les biens essentiels étudiés sont ceux pour lesquels un disfonctionnement aurait
présumément un impact fort sur l’activité des services utilisateurs et sur l’entreprise ou l’organisme
concerné. J’ai défini les besoins de sécurité des biens sur la base des critères de disponibilité, d’intégrité et
de confidentialité déjà présentés dans les parties précédente. J’ai ainsi décidé de procéder en plusieurs
phases. La définition de ces besoins a été réalisée tout d’abord avec les équipes fonctionnelles du projet
puis ils ont été validés avec les équipes fonctionnelles du client. Pour finir, ces besoins ont été présentés
aux RSSI du client puis à la direction.

Page 52 sur 145

11.1 Les biens essentiels
Les fonctions sont regroupées en processus dans un souci de clarté. La méthode que j’ai proposée veut
qu’après une revue documentaire du projet, les besoins en termes de DICP soient recueillis directement
auprès des représentants fonctionnels du métier lors d’entretiens, où les échelles et la méthode utilisée
pour l’analyse leur sont donc expliquées dans le détail.

ID Données Précisions D I C Commentaire

Les données personnelles
comportent des informations
nécessitant d'être intègres afin de
garantir la bonne marche de
Données à Données liées aux utilisateurs de
l'application. Une perte d'intégrité
BE_D1 caractère l’application ainsi qu’aux données 3 4
doit être détectée et corrigée.
personnel présentent au sein de l’application
Les données à caractère personnel
présentent par ailleurs un besoin
en confidentialité fort (dossier
CNIL…).
Les contrats comportent des
informations nécessitant d'être
Un contrat ne peut être signé
intègre afin de garantir la bonne
BE_D2 Contrats qu’entre deux partis (pas de 3 4
marche de l'application. Les
multipartis)
contrats comportent des
informations sensibles.

Les factures peuvent comporter

Les factures sont générées via
BE_D3 Factures 3 4 des informations sensibles (ex :
l’application
tiers nominatifs).

Des pièces jointes de type PDF sont Les utilisateurs pourront stocker
BE_D4 Pièces jointes 3 4
employés des pièces jointes.

Les traces techniques et

applicatives recueillies sont
Exemple : Démarrages et arrêts, garantes de la fiabilité de la piste
Traces techniques
BE_D11 ouvertures et fermetures de 3 2 d'audit. Leur besoin d'intégrité est
et applicatives
sessions, etc… fort.
Les traces ne comportent pas de
données sensibles.
Les traces métier recueillies sont
garantes de la fiabilité de la piste
d'audit. Leur besoin d'intégrité est
fort.
Exemple : création de contrat, Les traces ne comportent pas de
BE_D11 Traces métier 3 2
modification de contrat, etc… données sensibles. Par exemple,
pour les contrats, tout est tracé ;
pour certaines données, les traces
des dernières modifications sont
conservées
Tableau 14 : Liste des biens essentiels considérés pour l’étude

Page 53 sur 145

ID Processus Fonctions D I C Commentaire
Expression de
BE_F1 Gestion des demandes 2 2
demande
Passation de
BE_F2 Passation du contrat 3 3 Saisie dans l’application.
contrat
Gestion et suivi
BE_F3 Gestion des contrôles 2 2
de contrat
L'impossibilité d'accéder à cette
Calcul et
BE_F4 Gestion des règles de gestion 3 3 fonction devient problématique
facturation
au-delà de deux jours
L'impossibilité d'accéder à cette
BE_F6 Fin du contrat Fin du contrat 3 3 fonction devient problématique
au-delà de deux jours
Tableau 15 : Liste des biens essentiels considérés pour l’étude

11.2 Les biens supports

Les biens supports quant à eux sont classés selon la typologie suivante, proposée par EBIOS:2010 :

 SYS : Systèmes informatiques et de téléphonie

Ce type de biens supports est constitué de la combinaison de matériels (MAT), de logiciels (LOG) et de
canaux informatiques et de téléphonie (RSX) en interaction, organisés pour élaborer, traiter, stocker,
acheminer, présenter ou détruire tout ou partie des biens essentiels.
 SYS-MAT : Matériels
Ce type de biens supports est constitué de l’ensemble des éléments physiques d'un système informatique
(hardware et des supports de données électroniques) participant au stockage et au traitement de tout ou
partie des biens essentiels.
 SYS-LOG : Logiciels
Ce type de biens supports est constitué de l'ensemble des programmes participant au traitement de tout
ou partie des biens essentiels (software).
 SYS-RSX : Réseaux
Ce type de biens supports est constitué de l'ensemble des vecteurs physiques de communication et de
télécommunication qui transportent tout ou partie des biens essentiels.
 ORG : Organisations
Ce type de biens supports est constitué de la combinaison de personnes (PER), de supports papier (PAP) et
des canaux interpersonnels (CAN) en interaction, organisées pour satisfaire les objectifs d'un organisme (en
réalisant des activités métiers spécifiques) et manipulant tout ou partie des biens essentiels.
 ORG-PER : Personnes
Ce type de biens supports est constitué de l’ensemble des individus, catégories d'individus ou groupes
sociaux homogènes, qui ont accès à tout ou partie des biens essentiels.
 ORG-PAP : Supports papier
Ce type de biens supports est constitué de l’ensemble des supports statiques non électroniques contenant
des données.
 ORG-CAN : Canaux interpersonnels

Page 54 sur 145

Ce type de biens supports est constitué de l'ensemble des circuits organisationnels (canaux et processus
organisationnels) et des échanges verbaux en face à face, qui transportent tout ou partie des biens
essentiels.

 LOC : Locaux
Ce type de biens supports est constitué des infrastructures immobilières hébergeant, et nécessaires au bon
fonctionnement, des systèmes informatiques (SYS) et des organisations (ORG), dans lesquels sont utilisés
tout ou partie des biens essentiels.
Les biens supports intervenant dans les sous-processus considérés dans l’étude sont identifiés à partir
d’entretiens réalisés avec les membres de l’équipe SSI et des différents responsables de biens supports au
sein de l’entreprise ou de l’organisme commanditaire de l’étude et également à partir des dossiers de
sécurité initiaux et des documents d’architecture technique qui ont été collectés dans le cadre de
l’initialisation du référentiel documentaire de l’étude.
Ainsi, pour les biens supports de la présente étude, six catégories ont été retenues parmi celles définies
dans EBIOS:2010 :

 MAT : matériel ;
 LOG : logiciel ;
 RSX : réseaux ;
 LOC : locaux ;
 PAP ; Papier ;
 ORG : organisation.

Page 55 sur 145

Les biens supports suivants interviennent dans les macro-processus considérés dans l’étude présentée :

Bien Support Type EBIOS:2010 description

MAT_ESX MAT Serveurs de virtualisation
MAT_FW MAT Appliance Firewalls
MAT_RTR MAT Routeurs
MAT_SW MAT Switchs
MAT_POSTE_ADMIN MAT Postes de travail administrateurs / exploitants
MAT_LB MAT Appliance Load-Balancer
MAT_NTP MAT Appliance NTP
MAT_STO_SAN MAT Baies SAN
MAT_WAF MAT Web Application Firewall DenyAll
LOG_VCENTER LOG Serveur d’administration des VM Vcenter
LOG_ANN LOG Annuaires AD
LOG_AV LOG Agent anti-virus
LOG_DEV LOG Développement spécifique
LOG_SATELLITE LOG Serveur Satellite
LOG_METATIME LOG Horodatage
LOG_SAUVEGARDE LOG Sauvegarde
LOG_NTP LOG Serveur NTP
LOG_NAGIOS LOG Nagios : Supervision système
LOG_SRV_APP LOG Serveur applicatif Tomcat
LOG_SRV_WEB LOG Serveur Web Apache
LOG_BD_LOG LOG Base de données supportant les traces
LOG_OS_LINUX LOG OS : Red Hat 64-bit
LOG_OS_WIN LOG OS : Windows 64-bit
LOG_WSUS LOG Serveur WSUS
RSX_LAN-ADM RSX LAN utilisé pour les accès en administration
PAP_CONTRATS PAP Contrats signés version papier
LOC_PROD LOC Site de Production
LOC_DEV LOC Data centre
LOC_SEC LOC Site de Secours
ORG_PER ORG Personnel de l’entreprise / Prestataires
ORG_Entreprise ORG Organisation de l'entreprise
Tableau 16 : Liste des biens supports considérés pour l’étude

Page 56 sur 145

11.3 Présentation des mesures de sécurité déjà en place
Dans le cadre de ma mission une de mes tâches a été d’identifier les mesures de sécurité déjà en place car
elles participent de ce fait à la réduction du risque sans qu’un effort spécifique soit nécessaire. Ces mesures
sont décrites ci-dessous et sont donc celles déjà présentes et considérées comme efficaces à la mise en
production de la première version de l’application qui bénéficie donc des mesures de sécurité du SI de
l’entreprise.
Les mesures identifiées comme étant déjà en place sont donc les suivantes :

 mise en œuvre du principe de défense en profondeur. Utilisation de différentes technologies

positionnées comme autant de protections à franchir par un attaquant : 2 types de firewall, 1 HIDS
[34], 1 IPS [35], 2 types d’antivirus ;
 le respect des normes de développement de l’application permet la couverture des 10 risques
principaux du référentiel OWASP [36] ;
 la solution est protégée par 2 antivirus suivant 2 axes :
o 1 antivirus système pour Windows et Linux ;
o 1 antivirus pour contrôler les fichiers téléchargés.
 les habilitations des exploitants sont gérées suivant le principe du moindre privilège : les
administrateurs bénéficient de privilèges élevés sur leurs domaines d’affectation, le mainteneur de
droits en consultation.
 le processus de gestion des incidents déjà existant et fonctionnel sur le SI est étendu à
l’application.
 la solution bénéficie des infrastructures de serveur de temps, de supervision et de sauvegarde du
SI ;
 les acteurs sont sensibilisés à la sécurité ;
 les évolutions de la solution suivent le processus de gestion des changements, des incidents et des
problèmes suivant les principes ITIL. Tout changement suit un processus de recette/qualification
avant mise en production.
 l’entreprise a planifié un test d'intrusion et un audit de code en phase de recette sécurité pour
établir une mesure réaliste de l’efficacité des mesures de sécurité en place.

Page 57 sur 145

12 Apprécier les événements redoutés
Un événement redouté est un scénario générique représentant une situation crainte par l'organisme. Il
s'exprime par la combinaison des sources de menaces susceptibles d'en être à l'origine, d'un bien essentiel,
d'un critère de sécurité, du besoin de sécurité concerné et des impacts potentiels auxquels est associé un
niveau de gravité pour l’organisme.
Lors des entretiens réalisés avec les responsables fonctionnels de l’entreprise, les conséquences/impacts en
cas de non-respect des besoins de sécurité ont pu être identifiés pour chaque bien essentiel, ainsi que les
niveaux de gravité associés.
La gravité d’un événement redouté est obtenue en retenant le niveau de gravité associé à la conséquence
maximale en termes d’impacts survenant lorsque le besoin de sécurité n’est plus respecté.

Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Juridique : 3 (recours de la
Compromissi
CNIL, des partenaires)
Données à on de Interne / externe
Image de marque : 3
ER_C1 caractère données à C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
personnel caractère Code malveillant
l’Entreprise)
personnel
Impact pour l'utilisateur : 2
Juridique : 3 (recours de la
CNIL, des partenaires)
Compromissi Interne / externe
Contrats (PAB, Image de marque : 3
ER_C2
CDU, TO…)
on de C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
Contrats Code malveillant
l’Entreprise)
Impact pour l'utilisateur : 2
Juridique : 3 (recours de la
CNIL, des partenaires)
Compromissi Interne / externe
Image de marque : 3
ER_C3 Pièces jointes on de pièces C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
jointes Code malveillant
l’Entreprise)
Impact pour l'utilisateur : 2
Juridique : 3 (recours de la
Compromissi
Structures CNIL, des partenaires)
on des Interne / externe
organisationne Image de marque : 3
ER_C6
lles et
structures C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
organisation Code malveillant
habilitations l’Entreprise)
nelles
Impact pour l'utilisateur : 2
Juridique : 3 (recours de la
Compromissi CNIL, des partenaires)
Interne / externe
Données des on des Image de marque : 3
ER_C7
interfaces données des
C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
Code malveillant
interfaces l’Entreprise)
Impact pour l'utilisateur : 2
Juridique : 3 (recours de la
CNIL, des partenaires)
Compromissi Interne / externe
Image de marque : 3
ER_C8 Factures on de C 4 Accidentelle / délibérée
(perte de crédibilité pour 3
factures Code malveillant
l’Entreprise)
Impact pour l'utilisateur : 2

Page 58 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Compromissi
Image de marque : 3
on des Interne / externe
Suivi des (perte de crédibilité pour
ER_C9
incidents
données C 3 Accidentelle / délibérée
l’Entreprise) 3
liées aux Code malveillant
Impact pour l'utilisateur : 3
incidents

Compromissi Interne / externe Juridique : 2

ER_C1 Traces
0 applicatives
on de traces C 2 Accidentelle / délibérée Image de marque : 2 2
applicatives Code malveillant Impact pour l'utilisateur : 2

Interne / externe Activité : 1 (indisponibilité)

Indisponibilit
Accidentelle / délibérée Image de marque : 2
é du
Passation du Code malveillant (perte de confiance en la
ER_D1
contrat
processus de D 3 Phénomène naturel dématérialisation) 3
passation du
Évènement interne Financier
contrat
Catastrophe naturelle Impact pour l'utilisateur

Indisponibilit Interne / externe Activité : 3 (indisponibilité)

é du Accidentelle / délibérée Image de marque : 2
Gestion et
processus de Code malveillant (perte de confiance en la
ER_D2 suivi du
gestion et
D 3 Phénomène naturel dématérialisation) 3
contrat
suivi du Évènement interne Financier
contrat Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 3 (indisponibilité)

Indisponibilit
Accidentelle / délibérée Image de marque : 2
é du
Calcul et Code malveillant (perte de confiance en la
ER_D3
facturation
processus de D 3 Phénomène naturel dématérialisation) 3
calcul et
Évènement interne Financier
facturation
Catastrophe naturelle Impact pour l'utilisateur

Indisponibilit Interne / externe Activité : 3 (indisponibilité)

é du Accidentelle / délibérée Image de marque : 2
Paiement et processus de Code malveillant (perte de confiance en la
ER_D4
recouvrement paiement et
D 3 Phénomène naturel dématérialisation) 3
recouvremen Évènement interne Financier
t Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 3 (indisponibilité)

Indisponibilit Accidentelle / délibérée Image de marque : 2
é du Code malveillant (perte de confiance en la
ER_D5 Fin du contrat
processus de
D 3 Phénomène naturel dématérialisation) 3
fin de contrat Évènement interne Financier
Catastrophe naturelle Impact pour l'utilisateur

Page 59 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité

Interne / externe Activité : 3 (indisponibilité)

Indisponibilit Accidentelle / délibérée Image de marque : 2
é des Code malveillant (perte de confiance en la
ER_D6 Bureautique
fonctions de
D 3 Phénomène naturel dématérialisation) 3
bureautique Évènement interne Financier
Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 3 (indisponibilité)

Indisponibilit Accidentelle / délibérée Image de marque : 2
Activités de é des Code malveillant (perte de confiance en la
ER_D8
support fonctions de
D 3 Phénomène naturel dématérialisation) 3
support Évènement interne Financier
Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 3 (indisponibilité)

Indisponibilit Accidentelle / délibérée Image de marque : 2
é de la Code malveillant (perte de confiance en la
ER_D9 Archivage
fonction
D 3 Phénomène naturel dématérialisation) 3
d'archivage Évènement interne Financier
Catastrophe naturelle Impact pour l'utilisateur

Indisponibilit Interne / externe Activité : 1 (indisponibilité)

é du Accidentelle / délibérée Image de marque : 2
ER_D1 Expression de processus Code malveillant (perte de confiance en la
0 la demande d'expression
D 2 Phénomène naturel dématérialisation) 2
de la Évènement interne Financier
demande Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 2 (indisponibilité)

Indisponibilit Accidentelle / délibérée Image de marque : 2
ER_D1 Gestion des é de la Code malveillant (perte de confiance en la
1 utilisateurs gestion des
D 2 Phénomène naturel dématérialisation) 2
utilisateurs Évènement interne Financier
Catastrophe naturelle Impact pour l'utilisateur

Interne / externe Activité : 2 (indisponibilité)

Indisponibilit
Accidentelle / délibérée Image de marque : 2
é de
ER_D1 Administration Code malveillant (perte de confiance en la
2 fonctionnelle
l'administrati D 2 Phénomène naturel dématérialisation) 2
on
Évènement interne Financier
fonctionnelle
Catastrophe naturelle Impact pour l'utilisateur

Page 60 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Activité : 3 (retards de
paiement)
Juridique
Altération de
Données à Interne / externe Image de marque : 2
données à
ER_I1 caractère
caractère
I 3 Accidentelle / délibérée (perte de crédibilité pour 3
personnel Code malveillant l'Entreprise)
personnel
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 3 (retards de
paiement)
Juridique
Interne / externe Image de marque : 2
Contrats (PAB, Altération de
ER_I2
CDU, TO…) Contrats
I 3 Accidentelle / délibérée (perte de crédibilité pour 3
Code malveillant l'Entreprise)
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 3 (retards de
paiement)
Juridique
Altération de Interne / externe Image de marque : 2
ER_I3 Pièces jointes pièces I 3 Accidentelle / délibérée (perte de crédibilité pour 3
jointes Code malveillant l'Entreprise)
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 3 (retards de
paiement)
Juridique
Altération de
Interne / externe Image de marque : 2
Données liées données
ER_I5
aux tiers liées aux
I 3 Accidentelle / délibérée (perte de crédibilité pour 3
Code malveillant l'Entreprise)
tiers
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 3 (retards de
paiement)
Juridique
Structures Altération de
Interne / externe Image de marque : 2
organisationne structures
ER_I6
lles et organisation
I 3 Accidentelle / délibérée (perte de crédibilité pour 3
Code malveillant l'Entreprise)
habilitations nelles
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 3 (retards de
paiement)
Juridique
Interne / externe Image de marque : 3
Altération de
ER_I7 Factures
factures
I 3 Accidentelle / délibérée (perte de crédibilité pour 3
Code malveillant l'Entreprise)
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur

Juridique : 3 (incapacité de
Altération de Interne / externe construire une piste
Traces
ER_I8
applicatives
traces I 3 Accidentelle / délibérée d'audit) 3
applicatives Code malveillant Image de marque
Financier

Page 61 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Impact pour l'utilisateur

Activité : 2 (retards de
paiement)
Juridique
Altération de Interne / externe Image de marque : 2
ER_I1 Données des
0 interfaces
données des I 2 Accidentelle / délibérée (perte de crédibilité pour 2
interfaces Code malveillant l'Entreprise)
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Activité : 2 (retards de
paiement)
Juridique
Altération
Interne / externe Image de marque : 2
ER_I1 Suivi des des données
1 incidents liées aux
I 2 Accidentelle / délibérée (perte de crédibilité pour 2
Code malveillant l'Entreprise)
incidents
Financier : 2 (retards de
paiement)
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
investigation)
Répudiation
Interne / externe Activité : 3 (possibilité de
Gestion des sur la gestion
ER_T1
utilisateurs des
T 4 Accidentelle / délibérée fraude) 3
Code malveillant Image de marque
utilisateurs
Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur
Activité : 3 (possibilité de
fraude)
Répudiation Juridique : 2 (incapacité à
sur le Interne / externe répondre à une
Passation du
ER_T2
contrat
processus de T 3 Accidentelle / délibérée investigation) 3
passation du Code malveillant Image de marque
contrat Financier : 2 (possibilité de
fraude)
Impact pour l'utilisateur
Activité : 3 (possibilité de
fraude)
Répudiation
Juridique : 2 (incapacité à
sur le
Gestion et Interne / externe répondre à une
processus de
ER_T3 suivi du
gestion et
T 3 Accidentelle / délibérée investigation) 3
contrat Code malveillant Image de marque
suivi du
Financier : 2 (possibilité de
contrat
fraude)
Impact pour l'utilisateur
Financier : 4 (possibilité de
fraude)
Répudiation Activité : 3 (possibilité de
sur le Interne / externe fraude)
Calcul et
ER_T4
facturation
processus de T 3 Accidentelle / délibérée Juridique : 2 (incapacité à 3
calcul et Code malveillant répondre à une
facturation investigation)
Image de marque
Impact pour l'utilisateur

Page 62 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Financier : 4 (possibilité de
fraude)
Répudiation
Activité : 3 (possibilité de
sur le
Interne / externe fraude)
Paiement et processus de
ER_T5
recouvrement paiement et
T 3 Accidentelle / délibérée Juridique : 2 (incapacité à 3
Code malveillant répondre à une
recouvremen
investigation)
t
Image de marque
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
investigation)
Répudiation
Interne / externe Activité : 2 (possibilité de
sur le
ER_T6 Fin du contrat
processus de
T 3 Accidentelle / délibérée fraude) 3
Code malveillant Image de marque
fin de contrat
Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
investigation)
Répudiation
Interne / externe Activité : 2 (possibilité de
sur les
ER_T7 Bureautique
fonctions de
T 3 Accidentelle / délibérée fraude) 3
Code malveillant Image de marque
bureautique
Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
Répudiation investigation)
sur Interne / externe Activité : 2 (possibilité de
Administration
ER_T9
fonctionnelle
l'administrati T 3 Accidentelle / délibérée fraude) 3
on Code malveillant Image de marque
fonctionnelle Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
investigation)
Répudiation
Interne / externe Activité : 2 (possibilité de
ER_T1 Activités de sur les
0 support activités de
T 3 Accidentelle / délibérée fraude) 3
Code malveillant Image de marque
support
Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur
Juridique : 3 (incapacité à
répondre à une
investigation)
Répudiation
Interne / externe Activité : 2 (possibilité de
ER_T1 sur la
1
Archivage
fonction
T 3 Accidentelle / délibérée fraude) 3
Code malveillant Image de marque
d'archivage
Financier : 3 (possibilité de
fraude)
Impact pour l'utilisateur

Page 63 sur 145

 Évènement Besoin
Réf Bien essentiel Type Sources de menaces Impact Gravité
redouté sécurité
Juridique : 2 (incapacité à
répondre à une
Répudiation
investigation)
sur le
Interne / externe Activité : 2 (possibilité de
ER_T1 Expression de processus
2 la demande d'expression
T 2 Accidentelle / délibérée fraude) 2
Code malveillant Image de marque
de la
Financier : 2 (possibilité de
demande
fraude)
Impact pour l'utilisateur

Tableau 17 : Événements redoutés

Page 64 sur 145

 12.1 Événements redoutés par gravité
Gravité Réf Type Évènement redouté
ER_C1 C Compromission de données à caractère personnel
ER_C2 C Compromission de contrats
ER_C3 C Compromission de pièces jointes
ER_C6 C Compromission des structures organisationnelles
ER_C7 C Compromission des données des interfaces
ER_C8 C Compromission de factures
ER_T1 T Répudiation sur la gestion des utilisateurs
ER_C9 C Compromission des données liées aux incidents
ER_D1 D Indisponibilité du processus de passation du contrat
ER_D2 D Indisponibilité du processus de gestion et suivi du contrat
ER_D3 D Indisponibilité du processus de calcul et facturation
ER_D4 D Indisponibilité du processus de paiement et recouvrement
ER_D5 D Indisponibilité du processus de fin de contrat
ER_D6 D Indisponibilité des fonctions de bureautique
ER_D8 D Indisponibilité des fonctions de support
ER_D9 D Indisponibilité de la fonction d'archivage
Significatif
ER_I1 I Altération de données à caractère personnel
ER_I2 I Altération de contrats
ER_I3 I Altération de pièces jointes
ER_I5 I Altération de données liées aux tiers
ER_I6 I Altération de structures organisationnelles
ER_I7 I Altération de factures
ER_I8 I Altération de traces applicatives
ER_T2 T Répudiation sur le processus de passation du contrat
ER_T3 T Répudiation sur le processus de gestion et suivi du contrat
ER_T4 T Répudiation sur le processus de calcul et facturation
ER_T5 T Répudiation sur le processus de paiement et recouvrement
ER_T6 T Répudiation sur le processus de fin de contrat
ER_T7 T Répudiation sur les fonctions de bureautique
ER_T9 T Répudiation sur l'administration fonctionnelle
ER_T10 T Répudiation sur les activités de support
ER_T11 T Répudiation sur la fonction d'archivage
ER_C10 C Compromission de traces applicatives
ER_D10 D Indisponibilité du processus d'expression de la demande
ER_D11 D Indisponibilité de la gestion des utilisateurs
Modéré ER_D12 D Indisponibilité de l'administration fonctionnelle
ER_I10 I Altération de données des interfaces
ER_I11 I Altération des données liées aux incidents
ER_T12 T Répudiation sur le processus d'expression de la demande
Tableau 18 : Événements redoutés par gravité

Page 65 sur 145

 13 Apprécier les scénarios de menaces
J’ai construit les scénarios de menaces pesants sur les biens supports à partir : des menaces standards définies par la méthode EBIOS:2010 pour chaque type de
bien support, des vulnérabilités propres aux biens supports, ainsi que les sources de menaces susceptibles d’exploiter les vulnérabilités malgré les mesures de
sécurité en place.
Les vulnérabilités des biens supports et les mesures de sécurité en place ont essentiellement été identifiées lors des ateliers de conception et dans les documents
d’architecture.
La vraisemblance d’un scénario de menace est la probabilité que celui-ci se réalise. Pour un scénario précis, elle est obtenue en rapprochant les vulnérabilités du
bien support concerné, les mesures de sécurité dont bénéficient les bien supports, la capacité et la motivation d’une source de menace à vouloir exploiter les
vulnérabilités. Le niveau de vraisemblance le plus approprié est ainsi sélectionné sur l’échelle de vraisemblance
Le tableau ci-dessous présente les scénarios de menaces.

Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
Les mauvaises pratiques ont la
vie dure, malgré les
sensibilisations et les
politiques en place (clés USB
laissées sans surveillance,
Supervision Nagios et vCenter absence de chiffrement,
MAT_FW : Non-respect du processus WAF partage de mots de passe,
d'ajout/modification des règles Charte d'utilisation utilisation de comptes
Détournement
ORG_Entreprise : Mauvaises pratiques (utilisation Sessions de sensibilisation bi génériques, internet sur
MAT- de l'usage 1-11 Moyennement
MAT_FW D/I/C de comptes d'administration génériques, annuelles 2 postes admin…). Des mesures
USG prévu d'un 13 probable
échange de fichier…) Administration avec de sécurité sont mises en
matériel
RSX : Communication non sécurisée pour le authentification forte place par l’Entreprise pour
déploiement des fichiers d'installation (FTP) Durcissement des limiter l’apparition de ce type
configurations de scénarios de menaces, mais
comme elles ont souvent pour
cause racine des négligences
humaines leur niveau de
vraisemblance est non
négligeable.

Page 66 sur 145

 Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
Vu les mesures en place et les
MAT- difficultés à reconstituer des
Espionnage des MAT : Les disques durs qui partent en Mise au rebut sécurisée sous Faiblement
MAT_ESX ESP- C 1-11 1 données pertinentes via un
disques durs maintenance ne sont pas effacés. traitée probable
ESX unique disque, le scénario est
faiblement probable.
Redondance des
LOG_supervision : Absence de mise en infrastructures (sauf BD)
Dépassement corrélation des logs + traçabilité technique peu Infrastructures en partage de Le dimensionnement
MAT-
des limites de dissuasive (actions admin…) charge pour les plus sollicitées 1-11 Moyennement optimiste des liens et des
MAT_FW DEP- D 2
fonctionnement MAT_FW : Non-respect du processus Supervision Nagios et vCenter 13 probable matériels augmente la
FW
d'un firewall d'ajout/modification des règles Load balancer Netscaler vraisemblance du scénario.
LOG : Pas de contrôle des uploads des utilisateurs Administration avec
authentification forte
Redondance des
infrastructures
Dépassement Infrastructures en partage de
MAT- LOG: Pas de contrôle des uploads des utilisateurs
des limites de charge pour les plus sollicitées 1-11 Faiblement Faiblement probable au vue
MAT_ESX DEP- D RSX: Communication non sécurisée pour le 1
fonctionnement Supervision Nagios et vCenter 13 probable des mesures déjà en place
ESX déploiement des fichiers d'installation (FTP
d'un matériel Load balancer Netscaler
Administration avec
authentification forte
Faiblement probable en vue
Redondance de l'alimentation
des mesures en place.
Répartition de données en
Détérioration MAT_STO_SAN : Baie de stockage unique Cependant, il ne faut pas
MAT- Raid 5 1-11 Faiblement
MAT_STO_SAN D d'une baie de hébergeant tous les disques (SPOF) 1 négliger ce scénario pouvant
DET Site de secours à Toulouse 14-17 probable
stockage LOC : Datacenter en zone inondable se produire à tout moment
Contrôle d'accès physique du
même si peu probable (crue
Datacenter
de la Seine)
LOG_supervision : Surveillance administrateur Administration avec
Modification
MAT- pas de vue globale des actions administrateurs authentification forte 1-11 Faiblement Faiblement probable en vue
MAT_RSX_* D/I/C d'un matériel 1
MOD ORG_Entreprise : Utilisation de comptes Contrôle d'accès physique du 13 probable des mesures en place
réseau
d'administration génériques Datacenter

Page 67 sur 145

 Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
Les mauvaises pratiques ont la
vie dure, malgré les
sensibilisations et les
politiques en place (clés USB
laissées sans surveillance,
ORG_Entreprise : Gestion difficile des absence de chiffrement,
habilitations (non-respect de la procédure partage de mots de passe,
Détournement
Entreprise) Cellule dédiée à la gestion des utilisation de comptes
de l'usage
LOG- ORG_PER : Mauvais usage par les exploitants, habilitations génériques, internet sur
prévu d'un 1-11 Moyennement
LOG USG- D/I/C manque de sensibilisation Charte d'utilisation 2 postes admin…). Des mesures
logiciel par le 13 probable
PER ORG_Entreprise : Utilisation de comptes Sessions de sensibilisation bi de sécurité sont mises en
personnel
d'administration génériques annuelles place par l’Entreprise pour
interne
ORG : Politique de mot de passe Entreprise non limiter l’apparition de ce type
respectée de scénarios de menaces, mais
comme elles ont souvent pour
cause racine des négligences
humaines leur niveau de
vraisemblance est non
négligeable.
ORG_Entreprise : Authentification simple pour les Administration avec
Détournement
utilisateurs authentification forte
LOG- de l'usage 1-11 Moyennement
LOG D/I/C LOG : Vulnérabilités logicielles (failles XSS, Durcissement des 2
USG prévu d'un 13 probable
injection de code…) configurations
logiciel
LOG : Versions logicielles obsolètes Recette sécurité planifiée
LOG : Absence de chiffrement des métadonnées
et des pièces jointes en attente d'archivage (SMA
est un sas non chiffré également)
LOG : Absence de chiffrement des bases de Malgré les mesures en place,
Espionnage des
LOG_BD_DOC LOG- données 1-11 Moyennement ces attaques sont faciles à
C bases de 2
LOG_BD_LOG ESP LOG : Vulnérabilités logicielles (failles XSS, 13 probable mener par un administrateur
données
injection de code…) par exemple.
LOG : Versions logicielles obsolètes
ORG : Manipulation de données de production
par les équipes projet

Page 68 sur 145

 Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
Antivirus OS et flux
LOG : Vulnérabilités logicielles (failles XSS, IPS Une attaque virale demande
injection de code…) Durcissement des une grande connaissance du
LOG_OS_WIN LOG- Piégeage LOG : Versions logicielles obsolètes configurations Moyennement système mais peut être
D/I/C 13 2
LOG_OS_LINUX VIR logiciel ORG_Entreprise : Manque de sensibilisation, Recette sécurité planifiée probable facilement motivée, et
mauvaises pratiques Politique antivirale facilitée par le social
ORG_Entreprise : PSSI non appliquée Revue croisées engineering
Audits de code
LOG_BD : Les bases de données ne sont pas Les bases de données ne sont
Dépassement actif/passif, les restaurations se font pas redondées, ce qui rend
LOG-
LOG_BD_DOC des limites des manuellement. 1-11 Moyennement inévitable scénario dans lequel
DEP- D 2
LOG_BD_LOG bases de LOG : Absence de durcissement des 13 probable une défaillance d'une base de
BD
données configurations (paramétrages par défaut, ports données entraîne des
ouverts…) interruptions du service
LOG_supervision : Absence de mise en
corrélation des logs
LOG : Pas de contrôle des uploads des utilisateurs
RSX : Communication non sécurisée pour le Supervision applicative et
Dépassement déploiement des fichiers d'installation (FTP technique
LOG_SRV_APP LOG- 1-11 Moyennement
D des limites d'un LOG : Vulnérabilités logicielles (failles XSS, Postes d'administration 2
LOG_SRV_WEB DEP 13 probable
logiciel injection de code…) dédiés, avec authentification
LOG : Versions logicielles obsolètes forte
LOG : Absence de durcissement des
configurations (paramétrages par défaut, ports
ouverts…)
LOG : Vulnérabilités logicielles (failles XSS,
injection de code…) Supervision applicative et Malgré les mesures en place,
LOG- Modification LOG : Versions logicielles obsolètes technique 1-11 Moyennement ces attaques sont faciles à
LOG_OS_LINUX D/I/C 2
MOD d'un logiciel LOG : Absence de durcissement des Administration avec 13 probable mener par un administrateur
configurations (paramétrages par défaut, ports authentification forte par exemple.
ouverts…)

RSX : Communications non chiffrées sur Absence de chiffrement des

Attaque du l'infrastructure (en backend) flux mais environnement Malgré les mesures en place,
RSX- milieu sur un RSX : Communications non chiffrées lors du considéré comme maitrisé en 1-11 Moyennement ces attaques sont faciles à
RSX_CI D/I/C 2
MITM canal déploiement des fichiers d'installation (protocole backend 13 probable mener par un administrateur
informatique FTP) Supervision applicative et par exemple.
RSX : Communication non chiffrée entre le technique

Page 69 sur 145

 Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
Netscaler/Serveur web/ Application Web (en
frontend), utilisée pour le transport des jetons
d'authentification
RSX : Communication non sécurisée pour le
déploiement des fichiers d'installation (FTP)

RSX : Communications non chiffrées sur

l'infrastructure (en backend)
Absence de chiffrement des
RSX : Communications non chiffrées lors du
flux mais environnement Malgré les mesures en place,
déploiement des fichiers d'installation (protocole
RSX- Écoute passive considéré comme maitrisé en 1-11 Moyennement ces attaques sont faciles à
RSX_CI C FTP) 2
ESP sur l'interlan backend 13 probable mener par un administrateur
RSX : Communication non chiffrée entre le
Cloisonnement en VLAN, TLS par exemple.
Netscaler/Serveur web/ Application Web (en
jusqu'au Netscaler
frontend), utilisée pour le transport des jetons
d'authentification
Redondance des liens
Contrôle d'accès physique du
RSX- Saturation du 1-11 Faiblement Faiblement probable en vue
RSX_CI D RSX : Pas de contrôle des uploads des utilisateurs Datacenter 1
SAT canal internet 13 probable des mesures en place
Solution de DDoS de
l'opérateur télécom
Les mauvaises pratiques ont la
vie dure, malgré les
sensibilisations et les
politiques en place (clés USB
laissées sans surveillance,
absence de chiffrement,
partage de mots de passe,
ORG_Entreprise : Manque de sensibilisation, Sessions de sensibilisation bi utilisation de comptes
PER- Influence sur Moyennement génériques, internet sur
ORG_PER I/C mauvaises pratiques annuelles 1-11 2
INF une personne probable postes admin…). Des mesures
ORG_Entreprise : PSSI non appliquée Charte d'utilisation
de sécurité sont mises en
place par l’Entreprise pour
limiter l’apparition de ce type
de scénarios de menaces, mais
comme elles ont souvent pour
cause racine des négligences
humaines leur niveau de
vraisemblance est non

Page 70 sur 145

 Sources
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité de Vraisemblance Commentaire
menaces
négligeable.

La vraisemblance de ce
scénario reste mitigée du fait
ORG : Authentification simple pour les
PER- Usurpation de Moyennement que le service n'est pas exposé
ORG_FC C utilisateurs Accès par l'intranet 1-11 2
MOD droits probable sur internet. Cependant, celui-
ORG : Politique de mot de passe non respectée
ci reste hors de contrôle de
l’application
Clause de confidentialité
PER- Départ d'une Faiblement Faiblement probable en vue
ORG_PER D/C ORG_PER : Faible loyauté Redondance des postes 1-11 1
PTE personne probable des mesures en place
critiques

Tableau 19 : Scénarios de menaces

Page 71 sur 145

 14 Apprécier les risques
J’ai apprécié les risques pesants sur un bien essentiel particulier en réunissant les événements redoutés par bien essentiel, et les scénarios de menaces qui
touchent les biens supports dont dépend le bien essentiel.
Pour identifier les risques sur un bien essentiel, pour chaque événement redouté du bien essentiel, la méthode appliquée consiste à :
 retenir la gravité associée à l’événement redouté considéré ;
 identifier l’ensemble des scénarios de menaces pouvant affecter les biens supports dont dépend le bien essentiel ;
 retenir les scénarios de menaces de nature à affecter le critère de sécurité correspondant à l’événement redouté ;
 retenir le maximum de la vraisemblance de ces scénarios de menace.

La valeur du risque est obtenue en multipliant la valeur qualitative de la gravité retenue (cf. échelle de gravité), par la valeur qualitative de la vraisemblance
retenue (cf. échelle de vraisemblance).

réf Critère Évènements Scénarios Valeur du

Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

Données à caractère personnel

Contrats * Risque de compromission suite à une attaque
Factures virale
Pièces jointes Gravité 3 : Des hackers ayant de grandes capacités et
ER_C1/ER_C9
Données liées aux tiers connaissances, exploitent des failles des composants
RC1 C Structures organisationnelles et
LOG-VIR
logiciels pour accéder à des données sensibles. La 3 3 Important
Gravité 2 :
habilitations ER_C10 probabilité de l'attaque augmente avec les failles des
Données des interfaces composants, l'intérêt de l'attaque et la possibilité de
l'effectuer à l'aide de social engineering.
Suivi des incidents
Traces applicatives

Page 72 sur 145

 réf Critère Évènements Scénarios Valeur du
Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

Expression de la demande
Passation du contrat * Risque de d'indisponibilité suite à une attaque
Gestion et suivi du contrat virale
Paiement et recouvrement Gravité 3 : Des hackers ayant de grandes capacités et
ER_D1/ER_D9
Fin du contrat connaissances, exploitent des failles des composants
RD1 D Bureautique
LOG-VIR
logiciels pour rendre indisponible l'application. La 3 3 Important
Gravité 2 :
Gestion des utilisateurs ER_D10/ER_D12 probabilité de l'attaque augmente avec les failles des
Administration fonctionnelle composants, l'intérêt de l'attaque et la possibilité de
l'effectuer à l'aide de social engineering.
Activités de support
Archivage

Données à caractère personnel

* Risque de compromission par vol de crédentiels
Contrats L'authentification étant simple pour les utilisateurs,
Factures une personne malveillante installe un keylogger (les
Pièces jointes Gravité 3 : postes clients ne sont pas maîtrisés), tâche facilité
ER_C1/ER_C9 LOG-USG
Données liées aux tiers grâce à du social engineering ou tout simplement
RC2 C Structures organisationnelles et
PER-INF
observe la saisie du mot de passe de l'utilisateur 3 2 Moyen
Gravité 2 : PER-MOD
habilitations ER_C10 (shoulder surfing) afin d'accéder au compte. La
Données des interfaces solution ne pouvant garantir l'identité de l'utilisateur,
celui-ci peut accéder aux données sensibles. Cette
Suivi des incidents
attaque peut être motivée pour frauder par exemple.
Traces applicatives

Page 73 sur 145

 réf Critère Évènements Scénarios Valeur du
Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

Données à caractère personnel

Contrats * Risque de compromission de source interne
Factures Un administrateur interne malveillant profite d'une
Pièces jointes Gravité 3 : traçabilité des actions administrateur non dissuasive
ER_C1/ER_C9
Données liées aux tiers LOG-USG-PER (mauvaises pratiques, pas d'enregistrement des
RC3 C Structures organisationnelles et PER-INF actions des administrateurs…) pour accéder à des 3 2 Moyen
Gravité 2 :
habilitations ER_C10 données sensibles et les divulguer (motivation
Données des interfaces financière, politique…). Les bases chiffrées ne
permettent pas de se prévenir des attaques internes.
Suivi des incidents
Traces applicatives

Données à caractère personnel

Contrats
Factures * Risque de compromission par sniffing
Pièces jointes Gravité 3 : Un utilisateur du réseau interne sniffe les flux internes
ER_C1/ER_C9
Données liées aux tiers non chiffrés, ou accède au sas SMA afin d'accéder à
RC4 C Structures organisationnelles et
MAT-ESP-BD
des données sensibles de l'application. Cela peut être 3 2 Moyen
Gravité 2 :
habilitations ER_C10 sur sollicitation externe financée dans le but d'obtenir
Données des interfaces la nullité d'une procédure de justice par exemple.
Suivi des incidents
Traces applicatives

Page 74 sur 145

 réf Critère Évènements Scénarios Valeur du
Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

* Risque de compromission par rejeu

Données à caractère personnel L'authentification des utilisateurs s'effectue au niveau
Contrats du Netscaler, les informations d'identification (jeton)
peuvent être interceptées, modifiées et rejouées. Un
Factures
Gravité 3 :
attaquant peut profiter de l'absence de chiffrement
Pièces jointes sur le réseau interne (en particulier entre le Netscaler
ER_C1/ER_C9
Données liées aux tiers et le serveur application web, situé en front end) pour
RC5 C Structures organisationnelles et
RSX-MITM 3 2 Moyen
Gravité 2 : sniffer les paquets, usurper une identité, et ainsi
habilitations ER_C10 compromettre des données sensibles.
Données des interfaces
Suivi des incidents
Traces applicatives

Données à caractère personnel

Contrats
Factures
Pièces jointes Gravité 3 : * Risque d'altération suite à une erreur de
ER_I1/ER_I8 manipulation
Données liées aux tiers
RI1 I Structures organisationnelles et
LOG-USG-PER Une erreur humaine d'un administrateur ou d'un 3 2 Moyen
Gravité 2 : exploitant sur l'infrastructure de virtualisation
habilitations ER_I11 entraîne des pertes ou des altérations de données.
Données des interfaces
Suivi des incidents
Traces applicatives

Page 75 sur 145

 réf Critère Évènements Scénarios Valeur du
Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

Expression de la demande
Passation du contrat
Gestion et suivi du contrat * Risque d'altération des journaux constituant la
Paiement et recouvrement Gravité 3 : piste d'audit
LOG-USG-PER
ER_T1/ER_T11
Fin du contrat PER-INF Un attaquant interne profite d'une vulnérabilité
RI2 I Bureautique RSX-MITM logicielle ou applicative pour effacer ou modifier des 3 2 Moyen
Gravité 2 :
LOG-MOD traces à valeur probante dans la base de données
Gestion des utilisateurs ER_T12
Administration fonctionnelle dédiée. La piste d'audit est compromise.
Activités de support
Archivage

Données à caractère personnel

Contrats * Risque d'altération de données par interception et
Factures rejeu
Pièces jointes Gravité 3 : Un attaquant interne profite de l'absence de
ER_I1/ER_I8
Données liées aux tiers chiffrement des flux et de contrôle d'intégrité des
RI3 I Structures organisationnelles et
RSX-MITM
données jusqu'à l'archivage pour procéder à une 3 2 Moyen
Gravité 2 :
habilitations ER_I11 attaque Man in the Middle et rejouer des données
Données des interfaces altérées (modification des montants par exemple,
perte d'intégrité d'un contrat)
Suivi des incidents
Traces applicatives

Expression de la demande
Passation du contrat
Gestion et suivi du contrat * Risque de d'indisponibilité suite à un upload
Paiement et recouvrement Gravité 3 : malicieux
ER_D1/ER_D9 Un attaquant upload un fichier exécutable malicieux,
Fin du contrat
RD2 D Bureautique
LOG-VIR en l'absence de restriction sur les extensions de 3 2 Moyen
Gravité 2 : fichier, la surface d'attaque est augmentée malgré les
Gestion des utilisateurs ER_D10/ER_D12 contrôles antiviraux en place. Ce type d'attaque peut
Administration fonctionnelle aboutir à une indisponibilité du système.
Activités de support
Archivage

Page 76 sur 145

 réf Critère Évènements Scénarios Valeur du
Biens essentiels concernés Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
risque sécurité redoutés de menace risque

Données à caractère personnel

Contrats * Risque de compromission suite à la manipulation
Factures de données de production
Pièces jointes Gravité 3 : Lors de la phase de reprise de données, des données
ER_C1/ER_C9 de production sont manipulées par les équipes
Données liées aux tiers LOG-ESP
RC6 C Structures organisationnelles et RSX-MITM
projets. En l'absence de respect strict des règles de 3 2 Moyen
Gravité 2 : protection des données sensibles mises en place à
habilitations ER_C10 l'Entreprise (échange en clair par mail, utilisation sur
Données des interfaces un environnement non productif), ces données
Suivi des incidents peuvent être compromises.
Traces applicatives
Données à caractère personnel
Contrats * Risque de compromission suite à une usurpation
Factures d'identité
Pièces jointes Gravité 3 : Si la méthode de création de mot de passe n'est pas
ER_I1/ER_I8
Données liées aux tiers conforme à la politique de mot de passe en vigueur à
RI4 I Structures organisationnelles et
LOG-USG-PER
l'Entreprise, le risque d'usurpation est augmenté en 3 2 Moyen
Gravité 2 :
habilitations ER_I11 raison de l'utilisation de mots de passe
Données des interfaces potentiellement plus faibles. Des données sensibles
peuvent être indument modifiées.
Suivi des incidents
Traces applicatives
Expression de la demande
Passation du contrat
Gestion et suivi du contrat * Risque d'indisponibilité suite à une catastrophe
Paiement et recouvrement Gravité 3 : naturelle
ER_D1/ER_D9 Une crue centennale de la Seine rendrait indisponible
Fin du contrat
RD3 D Bureautique
MAT-DET la solution (coupure d'alimentation du Datacenter 3 1 Mineur
Gravité 2 : Vauban). Le PRA ne sera disponible et opérationnel
Gestion des utilisateurs ER_D10/ER_D12 qu'à compter du pilote. La source de menace est
Administration fonctionnelle environnementale.
Activités de support
Archivage

Tableau 20 : Risques

Page 77 sur 145

15 Identifier les objectifs de sécurité
L’objectif est de proposer des nouvelles mesures de sécurité, afin de permettre de ramener tous les
risques qui ont été identifiés comme intolérables (identifiés à l’étape 4.1 des activités EBIOS et présenter
ici au sein de ce mémoire au chapitre : « Apprécier les risques ») à un niveau définie avec le client comme
acceptable (niveau <= 3).
Pour cela, j’ai proposé des optimisations des mesures de sécurité existantes ou des mesures de sécurité
complémentaires afin de réduire les risques identifiés à un niveau acceptable. Ces mesures de sécurité
complémentaires s’attacheront à traiter les vulnérabilités identifiées pour chacun des risques concernés.
Les objectifs de sécurité au sens EBIOS:2010 (étape 4.2.1 EBIOS:2010) retenus sont donc la « réduction » de
tous les risques résiduels non acceptables (niveau > 3) identifiés à l’étape 4.1 de la méthode.
Cependant, lorsque l’objectif de réduction ne serait pas possible ou trop complexe, des mesures de
« partage » du risque pourraient être envisagées.
Les analyses précédentes m’ont permises d’élaborer une vue générale des risques encourus par
l’application, c’est l’objet de ma mission, mais l’analyse a également permis de savoir quels sont les risques
encourus par le système d’information de l’entreprise qui héberge l’application. Les coûts éventuels
engendrés par des incidents de sécurité sont maintenant connus par le client car nous les avons estimés via
les échelles des impacts, ceci aura de l’importance lorsque le client devra retenir ou nous les mesures de
sécurité.
Nous devons donc mettre en place des moyens permettant de prévenir ces risques, ou le cas échéant de
rétablir le système dans son état initial et à ce titre nous devons proposer des mesures de sécurité. La
détermination des solutions à apporter passe par l’analyse des points faibles du système. J’ai cherché des
parades pour chacune des failles rencontrées dans l’analyse des risques faite précédemment. Cela consiste
à établir un catalogue des actions à réaliser, des solutions à retenir et des règles à définir pour
l’administration et l’utilisation des systèmes.
Chacune des solutions proposées devra être chiffrée financièrement afin d’évaluer son coût de mise en
œuvre et d’exploitation et aider le client à prendre une décision. Il faut veiller à ce que les dépenses
engendrées pour protéger le système soient raisonnables, c’est à dire qu’il ne doit pas y avoir de
disproportion des moyens face aux menaces et que le coût de protection n’excède pas celui d’une
éventuelle reconstitution, à ce titre en tant qu’ingénieur nous de prenons pas la décision mais j’ai préparé
les éléments qui permettront aux décideurs de statuer en connaissance de cause.

Figure 7 : La portée de la sécurité VS Les ressources nécessaires.

Page 78 sur 145

Pour être efficace, j’ai dû rechercher des solutions, définir une stratégie de sécurité. Pour ce faire j’ai lié
mes propositions aux règles de sécurité imposées par mon client.

15.1 Les solutions

Que les risques que j’ai identifiés soient accidentels ou volontaires, les risques informatiques sont
nombreux et menacent les systèmes informatiques, pouvant avoir des conséquences dramatiques. Il est
donc nécessaire de mettre en place des systèmes de sécurité, tant au niveau de la prévention, pour limiter
les facteurs de risque, qu’au niveau de la protection, pour diminuer l’ampleur des dégâts lorsqu’un sinistre
se produit. Ainsi il existe des principes fondamentaux qu’il est obligatoire d’étudier avant de proposer des
solutions sous la forme de mesures de sécurité dans une analyse de risque.
J’ai synthétisé dans les sous-chapitres qui vont suivre tous les principes et les solutions que j’ai dû passer en
revue et m’approprier dans le cadre de ma mission, avant de sélectionner et de présenter celles qui seront
les plus pertinentes de proposer dans le contexte de mon client.
J’ai retenu ainsi de grands principes qui feront de bonnes mesures de sécurité à proposer tel que :

 celui du moindre privilège : tout ce qui n’est pas explicitement autorisé doit être interdit, on aura
remarqué que dans le cadre de notre étude ce principe fait partis des mesures de sécurité en
place comme plusieurs des mesures suivantes ;
 la défense par couche ou défense en profondeur, qui est une protection successive à tous les
niveaux ou il est possibles d’agir. Si une couche est corrompue, d’autres protections de nature
différentes se présenteront à l’attaquant ;
 la mise en place de tableau de bord et journalisation : contrôles de l’état du SI ;
 la mise en place de moyen de détection (Alerte) et de réaction.
 La sécurité absolue n’existe pas, les règles de sécurité doivent donc évoluer en permanence ;
 la sécurité d’une application doit être prise en compte au plus tôt dans son cycle de vie, dès la
rédaction du cahier des charges et des besoins non fonctionnels puis durant la conception, le
développement et doit se concrétiser par une surveillance régulière quand l’application est en
production ;
 la sécurité dès la conception c’est du bon sens, faire simple, éviter de faire de la sécurité par
l’obscurité et privilégier une stratégie de défense en profondeur.
 la sécurité durant le développement, c’est filtrer les données entrantes, faire attention aux
possibilités d’injection, les pièges des jeux de caractères, suivre les données, protéger les sorties et
auditer son code ;
 la sécurité d’une application au quotidien, c’est modérer son contenu, analyser régulièrement les
fichiers de « logs ». Se tenir continuellement informé. Tenir le socle physique et logique de ses SI à
jour. Un navigateur sur un poste client qui n’est pas à jour n’est pas sans risque ;
 prendre en compte les aspects légaux, même si ceux-ci demandent de plus en plus
d’investissement aux entreprises et même si l’entreprise n’arrive déjà pas à gouverner son
système d’information car elle n’arrivera pas à faire respecter les exigences légales qui lui
incombent.

« La force d’une chaine n’est égale qu’à celle de son plus faible maillon »

Page 79 sur 145

Jusqu’à la Renaissance et au-delà, on a toujours pensé que la fiabilité d’une chaîne reposait sur celle de son
maillon le plus faible. Ainsi, si R était la fonction de fiabilité (ou de survie), alors en fonction du temps, on
pensait pouvoir écrire : Rchaîne (t) = Min1 ≤ i ≤ nRi(t), où les items indexent les n maillons de la chaîne. Or, il
s'est avéré que, dans une chaîne, ce n’était pas systématiquement le maillon le plus faible qui se rompait en
premier. La fiabilité de la chaîne est alors devenue une certaine fonction de la fiabilité de ses maillons, les
plus faibles participant d’avantage que les plus solides à l’éventualité d’une rupture.
C’est Eric Pieruschka qui va finalement donner la formule de calcul de la fiabilité d’une chaîne :
Rchaîne (t) = P1 ≤ i ≤ nRi(t). La probabilité de survie d’une chaîne à une date t arbitraire est le produit des
probabilités de survie de chacun de ses composants à cette date, dans l’hypothèse où lesdits composants
sont indépendants les uns des autres.
Il faut donc « penser sécurité » globalement, pour chaque composants d’un système d’information : poste
client, pare-feu, routeur, sonde, serveur, applications…

15.1.1 Politique de sécurité

Il faut toujours garder à l'esprit que la sécurité à 100% n'existe pas et qu'il y a nécessairement un
compromis entre la valeur qui est protégée et son coût de protection. Une entreprise ou un organisme
possédant des ressources informatiques doit donc déterminer les biens à protéger et les moyens
raisonnables de protection à mettre en place il s’agit de la première mesure de prévention à prendre. Il
n'existe pas de solution générale adaptable pour tous les cas de figure. Chaque entreprise comporte un
scénario de risques particuliers et ne peut pas se voir attribuer une solution typique. C’est pour cette raison
qu’une importante étude doit être réalisée afin de définir les besoins en matière de sécurité.
Il convient au préalable d'identifier les ressources et les causes de vulnérabilité en fonctionnement normal,
c'est à dire de définir les points faibles du système. Une fois l'état des lieux réalisé, il faut effectuer un choix
des mesures à mettre en place, en tenant compte du coût de la menace si celle-ci se produit et de
l'évaluation du coût du système de protection c’est ce que j’ai tenté de réaliser jusque-là.
Ainsi, l'analyse plus générale et pas seulement orientée « analyse de risque » peut se résumer comme suit :

 identification des ressources ;

 établissement des scénarios des risques encourus ;
 calcul des pertes face à ces événements ;
 détermination des moyens de sécurité nécessaires ;
 évaluation des contraintes techniques et financières ;
 choix final des solutions.
La politique de sécurité de l'information est alors l’aboutissement de ces réflexions et notre client dispose
d‘une politique de sécurité. La méthode utilisée actuellement en France par les entreprises et les
organismes d’États afin d’y parvenir est la méthode EBIOS ou plutôt ses dérivés de la version 2010 comme
celle que nous avons adaptée pour notre mission. En effet, la méthode en elle-même est très axée sur la
forme et ne s’engage pas sur le fond et les mesures concrètes à mettre en œuvre, pour cela on doit se
reporter à des préconisations il m’a donc fallu élargir mon étude. Du côté de l’élaboration d’une PSSI c’est
la norme ISO 27001 et son annexe A constituée de 133 mesures de sécurité qui est la plus employée à la
création de PSSI c’est donc un référentiel à prendre en compte. L’annexe A de l’ISO 27001 à sa propre
norme, c’est l’ISO 27002. L’ISO 27002 est nouvelle version de l’ISO 17999 qui avait déjà eu beaucoup de
succès dans le passé, certains l’utilisent d’ailleurs encore aujourd’hui car la 17999 avait le mérite d’aller plus
loin que la 27002 en terme de conseil d’implémentation de mesure de sécurité, un peu comme ITIL V2 qui

Page 80 sur 145

traitait de l’implémentation concrète de bonnes pratiques alors que ITIL V3 ne traite plus de manière
détaillée l’implémentation des bonnes pratiques. Je me suis doc inspiré de ces référentiels que je
connaissais déjà de par mes expériences passées.

15.1.1.1 Le facteur humain

La sécurité informatique d'une entreprise est tout d'abord une affaire de direction, qui seule a les pouvoirs
d’ordonner la mise en œuvre effective des recommandations. Mais son élaboration et sa mise en pratique
ne doivent en aucun cas reposer sur une seule personne. Tout le monde est concerné et doit coopérer à sa
mise en place : les administrateurs qui ont la responsabilité du système, mais également les utilisateurs, qui
considèrent souvent à tort que les problèmes de sécurité ne les concernent pas. À cette fin, la politique de
sécurité ne doit pas être perçue comme une contrainte, mais plutôt comme un ensemble de règles
librement consenties. On peut multiplier les mesures de sécurité, mais si elles ne sont pas comprises, leur
utilité se réduit très vite. Les utilisateurs doivent donc être largement informés et sensibilisés sur les risques
encourus et leurs conséquences. J’ai donc fait participer mes collègues, aussi bien techniques que
fonctionnels, quand j’en suis arrivé à sélectionner les mesures que j’allais proposées

15.1.1.2 La détermination des risques

L’évaluation des conséquences financières d’un sinistre avec les équipes du client a été difficile. Lors du vol
d’un ordinateur par exemple, le coût immédiat est le remplacement de la machine. Mais il faut également
prendre en compte la perte des informations contenues sur le support et l’indisponibilité des ressources
dérobées. De même il faut compter les éventuelles pertes que l’utilisation de ces informations par des
entités externes peut entraîner. C’est pour cela qu’il est très important de bien identifier les ressources,
c’est à dire savoir ce qu’il faut protéger et à quel niveau. De même, les différentes structures n’ont pas le
même profil, des ressources critiques pour l’une pouvant être secondaires pour l’autre. Il est ensuite
nécessaire de déterminer les risques encourus pour les ressources définies précédemment. L’analyse des
risques peut être effectuée par audit et à l’aide d’outils spécifiques. Des sociétés externes sont également
spécialisées dans ce domaine et peuvent procurer des conseils ou établir un diagnostic.
Une fois les risques encourus déterminés, ce que nous avons fait de manière détaillée, il est intéressant de
se pencher sur leur probabilité d’apparition au moment où il faut proposer des mesures. Il s’agit ici de
déterminer la vraisemblance d’une menace déterminée à l’étape précédente. Le résultat de cette analyse a
permis d’aboutir à une hiérarchisation des risques et put nous aider à hiérarchiser les mesures proposées
également.
Pour chacune des ressources déterminées et des menaces qui la concernent, il convient de déterminer le
coût de l’éventualité d’une destruction totale, afin de pouvoir classifier l’importance du niveau de
protection à mettre en place. À ce niveau, il est possible également de se focaliser sur les ressources les
plus sensibles, tant en terme de coût de reconstitution que de probabilité de perte.

15.1.2 Moyens (non exhaustifs) de sécurisation

Nous avons dressé une liste de risques potentiels et ainsi de spécifier le « quoi » de notre réflexion. Nous
avons commencé à apporter quelques éléments de réponse concernant le « comment » en proposant
différentes mesures et dans le chapitre précédant des moyens de défense. Intéressons-nous à présent de
manière plus précise aux moyens de sécurisation qu’il m’a été possible de proposer.
Un principe, est aujourd’hui systématiquement évoqué, celui de la Défense en profondeur.
Dans une architecture interconnectée, quels sont les besoins courants ?
 connexion de l’entreprise à l’internet ;

Page 81 sur 145

  connexion de deux sites distants d’une même entreprise ;
 connexion d’un portable distant au réseau d’entreprise ;
 connexion d’un partenaire à l’entreprise ;
 mise à jour du public d’un moyen de paiement en ligne.
La Défense en profondeur concerne un ensemble de points que nous allons traiter successivement. C’est en
chainant les différents sujets et les moyens de protection que l’on arrive à réaliser ce que l’on appelle une
défense en profondeur.

15.1.2.1 La politique et la stratégie de défense

Il faut s’assurer des accès licites aux diverses ressources.
Moyens de défense :
 catégorisation des utilisateurs (administrateur, utilisateurs) ;
 habilitation ;
 identification et authentification ;
 révocation stricte et immédiate ;
 contrôles.

a) La confidentialité
De la même manière que les serveurs ne doivent être accessibles que par les administrateurs systèmes, les
postes de travail ne doivent pas être accessibles par tous les utilisateurs. Les bureaux doivent pouvoir être
fermés à clé et les postes de travail doivent comporter des mots de passe valides. Pour être efficaces, ceux-
ci doivent être choisis avec soin et respecter quelques règles de base :

 Ne jamais choisir un mot de passe du langage courant. Comme nous l’avons vu dans la partie
précédente, les pirates utilisent des dictionnaires pour venir à bout des mots de passe. S’il est
choisi parmi des termes usuels, ce type de protection à toutes les chances de ne pas résister
longtemps.
 Ne jamais choisir un mot proche de soi, tel que son nom, le prénom de ses enfants, sa date de
naissance, le nom du chien, le numéro de sa plaque d’immatriculation, son passe-temps favori…
N’importe qui connaissant suffisamment la personne aura tôt fait de trouver le mot de passe
choisi.
 Choisir un mot de passe long. Les logiciels de force brute arrivent aisément à décrypter les mots
comportant moins de 6 caractères dans un laps de temps raisonnable.
 Les bureaux en libre-service avec le mot de passe de la machine inscrit sur un papier collé à l’écran
sont évidemment à proscrire. N’importe quel pirate se faisant passer pour un technicien ou un
client extérieur à la société pourrait ainsi se procurer facilement des informations confidentielles.
 Le mieux est de prendre un mot de passe constitué de chiffres et de lettres, de majuscules et de
minuscules. Il est prudent d’y ajouter des caractères de ponctuation ou des caractères peu souvent
utilisés, ceci afin de compliquer le travail de décryptage.
 De nombreux procédés mnémotechniques permettent de se rappeler comment générer et surtout
retrouver ce type de mots de passe. Une fois un de ces procédés choisi, il est aisé de posséder un
mot de passe différent pour chaque application et d’en changer régulièrement.

Page 82 sur 145

Malgré ces quelques règles, les mots de passe utilisateur sont généralement simples et possèdent une
longue durée de vie. Pour éviter qu'un pirate s'empare du mot de passe et le réutilise pour se connecter, le
plus simple est d’en changer à chaque connexion. Les mots de passe à usage unique (OTP, One Time
Password) permettent à un client de se connecter avec un mot de passe différent grâce à un dialogue avec
la machine cible. Alors que la plupart des authentifications se font de manière simple (login / mot de
passe), les OTP se basent sur le couple challenge / réponse. Voici le déroulement d’une
authentification utilisant les OTP :
 le client fait une demande de connexion au serveur à distance (ftp, ssh, telnet, ...) ;
 le serveur envoie un challenge au client, composé d’un compteur (un nombre plus grand que 1) et
d’une graine (2 caractères suivis de 5 chiffres : aa11111) ;
 le client calcule alors le mot de passe jetable localement grâce à un programme, en entrant le
challenge et une phrase secrète qu’il a choisi auparavant. Une fois le mot de passe calculé, il est
envoyé au serveur ;
 le serveur vérifie que le mot de passe correspond bien au challenge envoyé crypté, et permet ou
non l’accès.
Le mot de passe jetable est généré en concaténant la graine et la phrase secrète, puis en appliquant une
fonction de hachage (exemple : MD4 ou MD5) autant de fois qu'indiqué par le compteur. Le résultat est
ensuite converti en six courts mots anglais qui constituent le mot de passe non réutilisable.
Le compteur est décrémenté à chaque connexion de l’utilisateur, et lorsque celui-ci arrive à 0, l’utilisateur
se voit demander la création d’une nouvelle phrase secrète et d’une nouvelle graine.
Comme tout système, les OTP possèdent des failles, cependant elles restent plus difficiles à exploiter
qu’avec l’utilisation de mots de passe classiques. Ces failles tournent essentiellement autour de
l’attaque brut ou par dictionnaire en récupérant le challenge puis la réponse, et en essayant de retrouver la
phrase secrète par exemple. L’utilisation d’un keylogger peut également servir à récupérer la phrase
secrète de l’utilisateur lorsqu’il utilise un outil pour générer le mot de passe jetable.

b) Audits et conformité
Les audits, inspections, diagnostics flash et autre appellations participent dans un cycle itératif
d’amélioration continu à l’amélioration générale de la sécurité de nos environnements. Les normes de
sécurité tel que l’ISO 27001 ont prises une grande place dans le domaine de la sécurité et les certifications
associés sont un bienfait pour toute la communauté. Les audits et la conformité dans son ensemble sont
des outils puissants et essentiels.

c) Supervision sécurité
Comment évoquer les moyens de supervision de sécurité sans parler de la gestion et de la corrélation des
logs. Très à la mode, les SIEM se multiplient mais très peu apportent une réelle différence. En effet, le
mode de fonctionnement ne change pas foncièrement d’un outil à un autre, pour mettre en œuvre ces
systèmes il faut administrer les logs du périmètre à auditer, les sélectionner ce qui est rarement fait et les
stocker. Des sources d’événements claires permettent une stratégie de lutte informatique défensive claire,
on parlera également de stratégie de surveillance. Dans ce mémoire, afin d’illustrer ces propos, un des
risques issus de notre cas de test est couvert par une mesure de traçabilité. Nous irons jusqu’à vérifier la
pertinence de la mesure dans un chapitre précédant nos conclusions.

d) La visibilité du système
Il faut être en mesure de pouvoir à tout moment identifier l’état de sécurisation du système.

Page 83 sur 145

Moyens de défense :

 tableau de bord de la sécurité (TDBSSI) ;

 veille technologique ;
 audit régulier (ISO 19001).

15.1.2.2 La protection physique

La protection de l’accès aux ressources informatiques est une des priorités des politiques de sécurité. Il
convient alors à nouveau de se poser plusieurs questions :

 les machines sont-elles en lieu sûr et inaccessibles par des personnes non autorisées ;
 certaines machines restent-elles connectées inutilement sans surveillance ;
 des sauvegardes de données sont-elles effectuées régulièrement ;
 les utilisateurs sont-ils des gens de confiance.

a) Les locaux
Il est indispensable de protéger physiquement les éléments critiques du système contre les risques
naturels, tels que la foudre, les coupures de courant, ou même les dégâts des eaux et les incendies.
Pour cela, il faut respecter quelques règles :
 protéger le matériel vital, comme les serveurs, par des onduleurs qui prennent le relais en cas de
défaillance du secteur, et qui offrent une protection vis à vis des surtensions ;
 placer ces systèmes dans des locaux protégés. Il faut leur réserver une pièce à l’abri des
inondations (éviter les sous-sols), exempte de poussière et climatisée. Le local doit être fermé à
clé, et pourra être couplé à des systèmes d’alarme ;
 les administrateurs systèmes devront au moins être deux, l’absence de la seule personne capable
de remettre le système en état (maladie, congé…) pouvant être aussi dramatique qu’un système
mal protégé ;
 les composants des ordinateurs et les supports de stockages sont sensibles aux effets
magnétiques. Il faut donc les tenir écartés des appareils source de magnétisme.
Quelles que soient les précautions prises pour garantir son bon fonctionnement, le matériel informatique
n’est pas à l’abri d’une panne. Tout matériel doit donc disposer d’une garantie solide, nécessitant le moins
d’immobilisation possible de la ressource, tant pour son remplacement que pour sa réparation.

b) La redondance
Certaines données conservées sur le système d'information d'une entreprise sont nécessaires à son
fonctionnement, elles ne doivent donc en aucun cas être perdues ou indisponibles. La redondance consiste
à introduire dans le système des éléments capables de prendre le relais, dans le cas où des organes vitaux
viendraient à être défaillants. Les disques durs peuvent être protégés physiquement à l’aide de la
technologie RAID (Redundant Array of Inexpensive Disks). Ce système offre une double utilité : accélérer les
accès disques et éviter les pertes de données. La technologie RAID 0 ne permet qu’une accélération,
écrivant les données entrelacées sur plusieurs disques à la fois. La technologie RAID 1, ou « mirroring »,
permet quant à elle l’écriture simultanée sur plusieurs unités. Les technologies suivantes combinent ces
deux systèmes : les ensembles sont composés de plusieurs disques, l’un d’entre eux contenant des données
de parité constituées à partir de chacun des autres. Il est ainsi possible de reconstruire un disque défaillant
à partir des autres disques du système. La dernière technologie RAID permet la dispersion des données de
parité sur chacun des disques. Un système de sécurité comme le RAID ne protège pas d'un effacement de

Page 84 sur 145

données ou d'un plantage du système, d’où l’importance d’effectuer des sauvegardes de ces supports
malgré la protection mise en place.

c) La gestion des sauvegardes

Une politique de sauvegarde rigoureuse est plus que nécessaire dans tout système d’information. Le
stockage des sauvegardes doit être sécurisé et des tests de restauration sont indispensables afin d’en
vérifier la pertinence.
Que la cause de la perte de données soit due à une panne matérielle ou à un acte malveillant, dans la
mesure ou la protection système n’a pas pu l’empêcher, il est nécessaire de pouvoir restaurer au plus vite
l’information. Seules les sauvegardes peuvent remédier à cette perte, c’est pour cela que ces solutions
doivent être mises en place au plus tôt.
Les sauvegardes sont des copies de fichiers permettant leur restauration lorsqu'un incident se produit. Leur
but est d'éviter une perte de temps et d'argent, et de se prémunir contre une situation catastrophe.
Plusieurs stratégies de sauvegarde sont possibles :

 la sauvegarde complète est longue mais facile à réaliser. De plus, l'utilisateur est certain que des
fichiers importants n'ont pas été oubliés ;
 la sauvegarde incrémentale consiste à réaliser une copie des fichiers qui ont été modifiés depuis la
dernière sauvegarde. La sauvegarde est plus rapide mais la restauration des fichiers s'en trouve
alourdie.
Des outils de sauvegarde automatique permettent de définir les paramètres d'archivage des fichiers à
sauvegarder. La relecture de certaines données peut nécessiter le programme spécifique qui a servi à les
créer, celui-ci devra donc également être sauvegardé. Il existe de nombreux périphériques et unités de
stockage permettant de réaliser ces copies. Leur choix s'effectue en fonction du budget, de l'importance
des copies et de leur nombre. Parmi ceux-ci, on peut citer, les disques comme les CD/DVD, les lecteurs de
bandes, les disques durs quel que soit leurs types et leur configuration y compris les supports SSD dit flash
et bien sûr les services du cloud, pour les plus couramment rencontrés.
L'utilisation de plusieurs supports est importante, pour éviter l'usure de ceux-ci, et ne pas courir le risque
de perdre toute la sauvegarde en cas de détérioration.
Il est également prudent de placer ces sauvegardes dans un endroit différent du système à sécuriser, ceci
afin d’éviter leur destruction simultanée dans le cas d’un incendie par exemple.
De plus, le lieu de stockage doit répondre à des critères de sécurité stricts : problèmes de confidentialité,
conditions de température et d’hygrométrie…
La sécurité physique fait appel à la notion de zonage d'un système d'information et une salle serveur devra
posséder ainsi à minima :

 un mécanisme d’authentification protégeant son accès ;

 des détecteurs d’incendie et d’humidité ;
 une journalisation des accès ;
 des procédures d’intervention (dépannage, personnel, extérieurs) ;
 un système de climatisation adapté ;
 des moyens de secours d’alimentation électrique ;
 Une protection des éléments actifs du réseau et des zones de sauvegarde.

Page 85 sur 145

15.1.2.3 La défense des installations
Premier pas, il faut sécuriser l’environnement physique des installations.
Moyens de défense :
 zonage ;
 accès réglementé ;
 rapport d’alarme (feu, inondation) ;
 cage de faraday, brouillage GSM ;
 caméra de surveillance ;
 drone de surveillance ;
 poste de sécurité.

15.1.2.4 La défense des réseaux

Second pas, sécuriser le réseau lui-même, mais aussi les interactions entre différents réseaux
Moyens de défense :
 sécuriser tous les éléments du réseau, même les plus secondaires et ceux d’une tierce partie ;
 séparer les réseaux de sensibilité différente ;
 penser au secours électrique ;
 penser à l’accessibilité des armoires électriques et des éléments isolés (commutateur…) ;
 avoir une documentation et un schéma global à jour ;
 appliquer le principe des flux directionnel de confiance : les flux réseaux d’un domaine de
confiance A, dit sure, vers un domaine de confiance B de confiance moindre et limiter au
maximum l’inverse ;
 contrôler les flux qui entrent ainsi que ceux qui sortent ;
 recourir à des ruptures de protocoles ;
 identifier et contrôler strictement les voies de communication (modem pirate) ;
 sécuriser le réseau à tous les niveaux (couche physique, réseau, transport) ;
 respecter la RFC 1918 pour les plans d’adressage ;
 avoir recours à la translation d’adresses.

a) Protocoles TLS, SSL et HTTPS

Transport Layer Security (TLS), et son prédécesseur Secure Sockets Layer (SSL), sont des protocoles de
sécurisation des échanges sur Internet. Le protocole SSL était développé à l'origine par Netscape. L'IETF en
a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS
pour désigner indifféremment SSL ou TLS.
TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité
suivants :
 l'authentification du serveur ;
 la confidentialité des données échangées (ou session chiffrée) ;
 l'intégrité des données échangées ;
 de manière optionnelle, l'authentification du client (mais dans la réalité celle-ci est souvent
assurée par le serveur).

Page 86 sur 145

Le protocole est très largement utilisé, sa mise en œuvre est facilitée du fait que les protocoles de la couche
application, comme HTTP, n'ont pas à être profondément modifiés pour utiliser une connexion sécurisée,
mais seulement implémentés au-dessus de SSL/TLS, ce qui pour HTTP a donné le protocole HTTPS.

b) Les réseaux privés virtuels (VPN) IPSEC

Un RVP (réseau virtuel privé) est un réseau dont l'accès est réservé à une certaine communauté. On utilise
un réseau WAN « public » : une infrastructure partagée mais qui garantit la confidentialité des données
échangées.
Le protocole IPSEC permet de sécuriser le trafic :
 entre deux stations ;
 entre une station et un routeur ;
 entre deux routeurs ;

Figure 8 : Tunnel IPSEC

Les réseaux privés virtuels (VPN, Virtual Private Network) permettent de réaliser une liaison sécurisée entre
deux réseaux distants à travers un réseau public. Ils sont généralement utilisés pour le télétravail,
permettant à des employés de se connecter à leur entreprise par l'intermédiaire d'internet via un chemin
virtuel sécurisé. Ils peuvent aussi permettre de relier deux sites d'une entreprise sans recourir à des lignes
spécialisées. Il existe donc deux utilisations principales de VPN :
 un réseau privé virtuel client-serveur, où un utilisateur distant se connecte au réseau local de son
entreprise ;
 un réseau privé virtuel de serveur à serveur, lorsque deux réseaux locaux sont connectés entre
eux.
Bien que les VPN nécessitent l'acquisition de produits matériels et logiciels supplémentaires, le coût des
communications est moindre, l'entreprise ne s'acquittant que d'un accès internet.
Un VPN nécessite :

 un serveur VPN pour accepter les connexions des clients VPN

 un client VPN
 un tunnel par lequel les données transitent
 une connexion VPN dans laquelle les données sont chiffrées et encapsulées
Cette technique fonctionne grâce à un principe de tunnel dont chaque extrémité est identifiée. Ensuite la
source chiffre les données, les encapsule et les achemine vers la destination. Cette technique met donc en
œuvre le chiffrement et l’authentification des données.

Page 87 sur 145

c) Relais SMTP ;
Un relai SMTP (Simple Mail Transfer Protocol) permet de recevoir les flux de messagerie venant d'Internet
sens qu'il va rentrer dans le système d'information ;
 il permet de dicter des règles d'anti Replay et d’anti spam ;
 il permet l'envoi de courriels du serveur de messagerie interne d'Internet ;
 il peut, en outre, vérifier l'identité des émetteurs autorisé.

Figure 9 : Relais SMTP

d) Les AP (Access point)

Ils permettent la connexion de nomades sur un système d'information ou sur internet. Les nombreuses
vulnérabilités du protocole 802.11g nécessitent la mise en place des éléments de filtrage et de détection
d'intrusion. Un bon AP doit répondre à minima aux critères suivants :
 Filtrage des adresses MAC ;
 Activation du WPA ;
 Paramétrage de la puissance d'émission ;
 Filtrage des flux à la ligne ;
 Filtrage des flux nappe ;
 Implémentation VPN IP Sec.

e) Les pare-feu
Un pare-feu est un matériel ou un logiciel qui permet de protéger un réseau des attaques extérieures,
effectuant un filtrage sur les communications entrantes et sortantes. Il empêche ainsi toute personne
d'accéder, de détruire ou de dérober des données du système informatique.
Le pare-feu :
 crée un fichier journal du trafic sur le réseau ;
 filtre les paquets entrants et sortants du réseau. C'est à dire qu'il les accepte ou les rejette suivant
une stratégie d'accès prédéfinie. (Adresse IP, protocole…) ;
 ferme l'accès aux ports ouverts par les ordinateurs du réseau ou les cache (ports furtifs)
 traduit les adresses IP utilisées sur internet en adresses différentes dans le réseau interne. La
machine sur laquelle le pare-feu est installé sera alors la seule machine du réseau accessible

Page 88 sur 145

 depuis l'extérieur. (technologie NAT, Network Address Translation, soit traduction des adresses sur
le réseau) ;
 prend en charge un ensemble d'applications et détecte les requêtes d'ouverture de session pour
déterminer celles qui n'ont pas lieu d'être.

Figure 10 : Le fonctionnement d'un pare-feu.

On distingue différents pare-feu :

 le logiciel pare-feu personnel s'exécute sur l'ordinateur qu'il protège. Il offre en général le filtrage
de la couche TCP/IP et des applications, c'est à dire qu'il arrête les intrus et fournit un bon niveau
de protection contre les attaques ;
 le pare-feu matériel se branche entre le réseau et la connexion extérieure. Appelés généralement
routeurs à large bande ou passerelles internet, ils proposent le blocage des ports et la traduction
des adresses du réseau (NAT). Lors d'une attaque, le réseau n'est pas affecté puisque le pare-feu
encaisse le choc en premier ;
 le pare-feu autonome est un ordinateur possédant deux cartes réseau, un système d'exploitation
de base et un logiciel pare-feu. C'est une solution bon marché qui nécessite une grande
compréhension dans la configuration des fonctionnalités du logiciel et du système d'exploitation.

f) Principes de la Zone démilitarisée (DMZ)

En informatique, une zone démilitarisée (ou DMZ, de l'anglais demilitarized zone) est un sous-réseau
séparé du réseau local et isolé de celui-ci et d'Internet par un pare-feu. Ce sous-réseau contient les
machines étant susceptibles d'être accédées depuis Internet. [37].
Le pare-feu bloquera donc les accès au réseau local pour garantir sa sécurité. Et les services susceptibles
d'être accédés depuis Internet seront situés en DMZ.
En cas de compromission d'un des services dans la DMZ, le pirate n'aura accès qu'aux machines de la DMZ
et non au réseau local.

15.1.2.5 La défense des interconnexions

Troisième pas, il faut sécuriser les moyens qui permettent des interactions entre deux réseaux différents
Moyens de défense :

 identifier et contrôler strictement les interconnexions (routeurs) ;

 identifier clairement les flux nécessaires (diagramme des flux) ;

Page 89 sur 145

  limiter les flux à ceux strictement nécessaires ;
 contrôler les flux par des éléments dédiés (sondes d’intrusion) ;
 veille technologique.

a) Les systèmes de détection/prévention d'intrusions

Un système de détection d'intrusions (IDS, Intrusion détection System) peut être assimilé à un renifleur
utilisé dans le sens de la protection réseau. Un IDS ne filtre pas les paquets à la manière d'un pare-feu, mais
il les capture et les inscrit dans un fichier. Il est aussi doté de fonctions spéciales, permettant entre autre de
détecter des activités anormales, de rechercher d'éventuelles faiblesses et de détecter des changements
dans le système de fichiers. Mais le système de détection d'intrusions sert avant tout à relever les
tentatives de sondage ou de connexion au système. Une utilité des IDS est de savoir ce que filtre
réellement le pare-feu. Pour cela il suffit d'en installer un avant et un autre après le dispositif et de
comparer les résultats de sortie.
En fait, Le système de détection d'intrusion complète efficacement une protection préventive comme celle
du pare-feu. Mais il n'existe pas de système infaillible, un comportement anormal étant difficile à définir.
Une configuration trop restrictive entraîne une succession de fausses alertes, alors qu'à l'inverse une
configuration trop lâche ne sert à rien. Il est alors plus intéressant de se concentrer sur des groupes
d'activités. Une heure tardive combinée à une commande inhabituelle attirera donc plus l'attention que
des commandes isolées. Les IPS (Systèmes de prévention d’intrusion) tentent quant à eux de bloquer
l’attaque en cours mais ils sont difficiles à paramétrer.

b) Routeur
Ils permettent de séparer deux réseaux sur un même site de relier deux sites distants. Il possède un « acces
list » qu'il convient de paramétrer correctement pour sécuriser le système d'information et économiser de
la bande passante.

c) Les serveurs proxy

Un proxy est un serveur, il va se substituer au client et effectuer les requêtes en son nom propre. Il permet
donc d’accéder à internet et va pouvoir contrôler le protocole au niveau applicatif. Il en existe différentes
sortes, http, ftp, smtp. Les proxys d’accès internet permettent d’identifier les clients et ils possèdent un
cache qui améliore les performances.
Un serveur proxy, permettant aux machines d’un réseau d’accéder à internet, peut combiner tout un
ensemble de solutions citées précédemment.
Un serveur proxy est un ordinateur comportant deux cartes réseau, un routeur de réseau, un pare-feu et
des logiciels de sécurisation :
 Cartes réseau : L'une des cartes réseau permet la connexion à internet, tandis que l'autre permet
de se connecter au réseau privé.
 Routeur: Le composant logiciel routeur de réseau permet à l'ordinateur de partager une connexion
entre les différents ordinateurs du réseau.
 Pare-feu : Dans la plupart des cas, il combine un pare-feu de niveau réseau et application pour
offrir une sécurité maximale.
 Antivirus: Il permet d'empêcher virus, vers et chevaux de Troie d'infecter le réseau et réduit la
nécessité d'installer un antivirus par poste.
 Filtrage: Le filtrage permet d'empêcher l'accès à Certains sites.

Page 90 sur 145

Le niveau de configuration offert par un proxy est donc très élevé. Il représente une bonne mesure de
protection de par la complémentarité de ses fonctions.
Quant à ce que l’on qualifie de « reverse proxy », il permet à une communauté internet d’accéder à un
serveur web d’une entreprise. Il effectue une coupure des flux entre internet et le serveur web. Il permet
un contrôle approfondi des requêtes émises d’internet vers le serveur web et ainsi de contrôler les
attaques.

d) Pot de miel ou Honeypots

Le concept est de mettre en place des systèmes volontairement vulnérables conçus pour être scannés,
attaqués et compromis. Le but est d'observer les comportements et de connaître les outils et les méthodes
d’attaques de pirates.

e) Principes des « Pots de miels » (Honeypots)

Dans le jargon de la sécurité informatique, un pot de miel, ou honeypot, est une méthode de défense active
qui consiste à attirer, sur des ressources (serveur, programme, service), des adversaires déclarés ou
potentiels afin de les identifier et éventuellement de les neutraliser.
Le terme désigne à l'origine des dispositifs informatiques spécialement conçus pour susciter des attaques
informatiques. [38]
Dans le cadre de la supervision en sécurité, le honeypot pourra être utilisé en tant que « sonde » faisant
partie intégrante du dispositif e surveillance. Le honeypot alors considéré doit alors faire l’objet d’une
étude d’intégration à la stratégie de surveillance globale du système d’information. L’objectif est de
dégager à partir de la sonde des événements unitaires ou corrélés pouvant donner lieu à des alertes de
sécurité.
Ce système est censé ne jamais être contacté. Tout contact avec la sonde est en soit une piste qui peut
amener à détecter une attaque ou un problème.

15.1.2.6 La défense des données

Identifier les moyens de stockages (disque dur, clé USB) et les transits (internet, intranet, extranet,
domiciles).
Moyens de défense : contrôler les accès aux informations (ACP). Chiffrement. Identification.
Authentification. Éducation des utilisateurs. Politique de sauvegarde. Différenciation du niveau de
sensibilité des données.

15.1.2.7 La défense des applications

Pensée dès le début du projet et en abstraction de la sécurité du système d’exploitation sur lequel elle
reposera.
Moyen de défense : développement selon l’état de l’art (OWASP), gestion des droits des applications dans
le contexte de la politique de gestion des mots de passe. Maintenance à jour de la version de l’application.
Audit du code. Documentation complète et explicite.

15.1.2.8 Cryptographie
Elle permet essentiellement de protéger des données. Elle permet également avec la signature
électronique d'assurer l'authentification d'une source. Elle est utilisée dans des protocoles tels qu’IPSEC,
HTTPS, SSH, par exemple pour sécuriser les échanges.

Page 91 sur 145

a) Cryptographie symétrique et asymétrique
Pour expliquer le concept penchons-nous sur la signature électronique avec un système asymétrique de
chiffrement.
 Alice et Bob utilisent un système à clé publique ;
 Alice chiffre une copie du document avec sa clé privée et la clé publique de Bob ;
 Alice transmet les deux documents à Bob ;
 Bob déchiffre le document chiffré avec la clé publique d’Alice et le compare à l’autre document ;
 s’ils sont identiques, seule Alice a pu signer le document ;
 Bob peut prouver à un tiers qu’Alice a signé le document original.
Si Ève est là et souhaite connaitre ce que se disent Alice et Bob, elle devra agir par cryptanalyse sur le texte
chiffré qu’elle aura préalablement récupéré en se plaçant au sein du crypto système.

 Alice crée un résumé, elle expédie le bulletin et le résumé non signé à Bob ;
 Bob extrait le bulletin d’Alice et calcule indépendamment un résumé de message ;
 Bob extrait le résumé de message qu’Alice lui a envoyé ;
Si les deux résumés correspondent alors Bob sait que le bulletin n’a pas été modifié depuis qu’Alice a créé
le résumé de son message.
Cas d’un résumé de message non signé.
Ève veut convaincre bob qu’il vient de recevoir le message d’Alice alors qu’il n’en est rien. Ève fait un faux
message et crée un résumé à partir de ce faux. Il intercepte le message d’Alice et le résumé associé puis
substitue son faux message avec son faux résumé ;

 Bob va calculer un résumé de message ;

 Bob va comparer les deux résumé et constater l’égalité, le bulletin étant non modifié pour Bob, si
le résumé avait été signé (déchiffré avec la clé public d’Alice) la supercherie aurait été détectable ;
Le système de chiffrement symétrique quant à lui se résume à une seule clé [39], la même clé est utilisée
pour coder et décoder et doit bien évidemment rester secrète.
La figure suivante illustre le principe du chiffrement symétrique.

Page 92 sur 145

 Figure 11 : Chiffrement symétrique

Je ne ferai pas dans ce mémoire la genèse de la cryptographie, de même que je ne balaierai pas tous les
moyens de chiffrement il s’agit comme expliqué de balayer les notions fondamentales qu’il est nécessaire
de développer dans une démarche orientée sur la sécurité.

b) Signatures et normes X509

X.509 est une norme de cryptographie de l'Union internationale des télécommunications pour les
infrastructures à clés publiques (PKI). X.509 établit entre autres un format standard de certificat
électronique et un algorithme pour la validation de chemin de certification. [40, p. 509]

c) Le chiffrement
Le chiffrement permet de transmettre un message ou de stocker une information dont le contenu n'est pas
lisible par quiconque tenterait de l'intercepter ou d’y accéder. Il répond ainsi à deux des problèmes
identifiés précédemment, c’est à dire la confidentialité et l’intégrité des données. Le chiffrement comprend
la présence de deux entités : un émetteur et un récepteur. Le premier va remplacer le message en clair par
un cryptogramme, à l’aide d’un algorithme et d’une clé, puis le transmettre au second qui devra le
déchiffrer. La sécurité d'un système de chiffrement repose donc sur la complexité des algorithmes définis,
la taille de la clé et la puissance de calcul disponible pour une attaque.
De nombreux algorithmes de chiffrement sont disponibles, regroupés sous deux grands principes :
 La cryptographie à clé secrète ;
 La cryptographie à clé publique.
Le système de chiffrement par clé symétrique, ou secrète, n'utilise qu'une seule clé. L’algorithme DES (Data
Encryption Standard) a été largement utilisé notamment dans les puces des cartes bleues et les téléphones
GSM, cet algorithme est obsolète depuis 2001. Utilisant une clé de 56 bits, son principe repose sur une
série de permutations et de tables de correspondances. Le DES a été remplacé par le triple DES puis l’AES
(Advanced Encryption Standard) qui sont plus sûr et ou la taille de clé évolue régulièrement depuis.
Le système de chiffrement par clé asymétrique utilise une clé publique et une clé privée. La clé publique est
connue de tout le monde, elle servira aux expéditeurs pour chiffrer le message que l'utilisateur recevra.

Page 93 sur 145

L’autre clé est conservée par son propriétaire et servira pour déchiffrer le message crypté par la première.
Les clés asymétriques font appel à des algorithmes très sophistiqués, ce qui implique que leur chiffrement
est plus efficace que celui des clés symétriques, mais qu’il est aussi plus long. L'algorithme de chiffrement
asymétrique le plus répandu est RSA, du nom de ses créateurs : Rivest, Shamir et Adleman.
RSA fait appel à des nombres premiers extrêmement grands pour garantir la sécurité du chiffrement.
Cependant ce système ne peut chiffrer que des messages de taille limité, le calcul devenant très complexe
pour de grandes données. RSA est souvent utilisé pour transmettre la clé de chiffrement DES, cette alliance
permettant un système de cryptage actuellement difficilement violable.
Un autre type de fonction couramment utilisée en cryptographie est le hachage à sens unique (One way
hash function). Elle consiste à réduire la taille des données à traiter par la fonction de hachage. Le condensé
obtenu est un paquet de taille déterminée qui ne permet pas de retrouver le texte original. Il est envoyé en
même temps que le texte d’origine et est utilisé pour l'identifier. Le récepteur peut alors hacher le fichier
reçu et le comparer au condensé. Les résultats obtenus doivent être identiques.

15.1.2.9 La défense des hôtes.

Installation des services à minima. Politique de mot de passe, identification/authentification. Mise à jour
régulière des correctifs du système d’exploitation. Niveau et mesures de sécurisation adaptés à chaque
hôte. Chiffrement maintenance. Sauvegarde régulière et automatisé. Partitionnement système
d’exploitation + applications + journaux. Secours électrique. Accessibilité. Antivirus mis à jour et
automatisé. Détection d’intrusion. Analyse et corrélation des fichiers de logs

a) L’antivirus
Loin d’être passés de mode, ils protègent le système d’information des virus, vers, et trojans. On peut les
classer en deux grandes catégories : les antivirus de passerelle, ils protègent le système d’information sur
les flux entrants (FTP, HTTP, IMAP, POP3, SMTP) et les antivirus qui protègent les serveurs, les postes des
utilisateurs et les serveurs de messagerie. Il est inutile de protéger le flux entrant et les postes
informatiques avec le même antivirus. De même, un antivirus qui n’est pas à jour ne protège plus grand-
chose. On recommande une administration centralisée de ces systèmes, meilleur moyen de s’assurer qu’ils
sont à jour et actifs.
Les virus constituent une grande menace envers les systèmes. Le risque encouru est d’autant plus grand
que la quantité d’information échangée est importante. La meilleure protection contre les infections reste
l'antivirus, bien que le nombre de virus augmente chaque jour et que les antivirus ne soient pas capables de
tous les détecter. Les antivirus doivent donc être mis à jour régulièrement afin de contenir le plus de
définitions de virus possible, ce qui peut s'effectuer de manière automatique.
La détection d’un virus s’effectue par la recherche de fragments de code malicieux, correspondant à sa
signature. Il se pose ici le problème des virus polymorphes, capables de modifier leur signature durant leur
réplication. C’est pour cela que les logiciels antivirus sont également capables de détecter des
comportements anormaux, mais cette détection difficile ne peut en aucun cas dispenser des mises à jour
fréquentes.
Deux techniques de protection sont offertes. La première est l'analyse automatique de tout fichier accédé
de la machine. La seconde consiste à lancer une analyse complète du système. Cette analyse nécessitant
beaucoup de ressources est donc réalisée ponctuellement.
Une conscience d'utilisation de la part des utilisateurs est également nécessaire. Ils doivent avoir
connaissance des menaces potentielles lorsqu'ils utilisent l'outil informatique. Les quelques mesures de
précaution suivantes permettent d'assurer une bonne sécurité vis à vis du code malveillant :

Page 94 sur 145

  utilisation d'un antivirus mis à jour régulièrement ;
 information des utilisateurs sur les risques encourus ;
 suppression du courrier électronique dont on ne connaît pas la provenance ;
 réglage des paramètres de courrier électronique pour désactiver l'ouverture automatique des
scripts joints au courrier ;
 désactivation des contrôles ActiveX et JavaScript dans le navigateur Web ;
 désactivation de l'exécution automatique des macros dans les applications bureautiques et
définition d'un niveau de sécurité ;
 ajout de sa propre adresse dans son carnet d'adresse pour détecter l'envoi automatique de
courrier électronique en cas de contamination ;

b) L’authentification
Il existe plusieurs façons d'identifier : login, mot de passe, biométrie, certificats, carte à puce. Utilisateurs
connus et associés à une matrice des droits d'accès aux ressources de l'entreprise. Tous les accès au réseau
(intranet) son authentifiés. Tous les accès distants au réseau sont fortement authentifiés. Aucune
connexion directe au réseau Internet n'est autorisée.
Protocole d'authentification. Il en existe plusieurs :
 OTP (One Time Password), un mot de passe différent est exigé à chaque nouvelle connexion ;
 Kerberos ;
 SRP (Secure Remote Passwords) ;
 Radius (Remote Authentication Dial-In User Service) ;
 LDAP (Lightweight Directory Access Protocol SSO) ;
 EAP (Extensible Authentification Protocol).
L’authentification est donc un aspect à ne pas négliger lors de la réalisation d’échanges et l’authentification
des correspondants, c’est à dire la vérification de l’identité des parties.
Dans un environnement à clé publique, il est essentiel de s’assurer que la clé utilisée appartient bien à la
personne à laquelle on destine les données. Cette fonction est assurée par les certificats numériques.
Un certificat est un document électronique qui atteste de l'identité de son détenteur, pour prévenir la
contrefaçon. Il contient des informations sur la clé publique d’une personne, afin de garantir son
authenticité.
Le certificat est constitué des champs suivants :
 la version ;
 l'algorithme de signature ;
 la clé publique ;
 la signature de la clé par une autorité de certification ;
 l’identité de l’autorité de certification ;
 un numéro de série ;
 le domaine d’application ;
 la période de validité.
Le certificat doit être généré par un tiers de confiance, c'est à dire un organisme indépendant qui contrôle
la véracité de ces informations. La mise en place d’une PKI nécessite une étude préalable. Elle permet une
sécurisation lors d’échanges de type e-commerce, notamment pour :

Page 95 sur 145

  les banques en ligne ;
 les impôts, TVA, les services du ministère des finances… en ligne ;
 les extranets sensibles.
La PKI (Public Key Infrastructure) regroupe tous les éléments requis par une autorité de certification
(Certifying Authority) pour l'émission et l'administration des certificats. Les certificats peuvent être déposés
et récupérés par l’intermédiaire d’une base de données appelée serveur de certificats.
La cryptographie à clé publique permet également l’utilisation des signatures numériques dont l’objectif est
de garantir l’authentification et l’intégrité des données. La signature s'effectue à l'aide de la clé privée pour
sa création et de la clé publique pour sa vérification. Une empreinte générée par hachage est codée à l'aide
de la clé privée, puis envoyée avec le certificat contenant la clé publique. Le destinataire vérifie la validité
du certificat en décodant la signature avec la clé publique et en le comparant à l'empreinte du message
reçu. A ce stade, le destinataire s'assure de l'identité de l'expéditeur et la non-modification du message.
Les évolutions du commerce électronique entraînent l'apparition de moyens de paiement sécurisé. C'est
notamment le cas de SSL (Secure Socket Layer) développé par Netscape. SSL est la plus répandue des
solutions de sécurisation de transaction. Intégrée dans tous les navigateurs du marché, son succès est dû
avant tout à simplicité d'utilisation. SSL assure l'authentification des parties et le cryptage des données.
Une session SSL démarre lorsqu'une adresse de type « https:// » est demandée. Le fondement de ce
protocole est l’algorithme de cryptage à clé publique RSA décrit précédemment. Toutes les données
transmises sont chiffrées, l'ensemble du processus étant totalement transparent pour l'utilisateur. Il existe
typiquement deux types de certificats : serveur et client. Les certificats serveur sont principalement utilisés
par SSL. Les certificats clients servent à identifier les utilisateurs individuels, et sont généralement utilisés
pour les logiciels de messagerie avec des systèmes comme PGP (Pretty Good Privacy). PGP est un logiciel de
protection des données, souvent utilisé pour le courrier électronique et très facile d'utilisation.

c) Suivie des patchs

La première protection d’un système d’information est la mise à jour des patchs publiés par l’éditeur. Afin
d’y arriver, une centralisation de mises à jour est indispensable pour une entreprise.

d) Configuration des ordinateurs

Les serveurs devront toujours être installés avec les seuls services nécessaires.

 Il est préférable de ne pas multiplier les services sur un même serveur, un service devrait être égal
à un serveur ou à une machine virtuelle ;
 le BIOS devra être protégé par mot de passe et ne jamais permettre de booter sur un support
extérieur ;
 les postes de travail doivent être inventoriés ;
 le strict nécessaire des logiciels doit être installé ;
 l’uniformité des logiciels est un atout dans la gestion des failles et de l’obsolescence.

e) Anti spyware
Les spywares sont devenus courant sur les ordinateurs naviguant sur internet. Il est recommandé de
posséder des logiciels antispyware afin de nettoyer les ordinateurs.

Page 96 sur 145

f) Filtrer, avec les expressions rationnelles, pour se protéger
Une expression rationnelle (ou expression régulière par traduction de l'anglais regular expression) est en
informatique une chaîne de caractères que l’on appelle parfois un motif et qui décrit un ensemble de
chaînes de caractères possibles selon une syntaxe précise.
Les expressions rationnelles sont issues des théories mathématiques des langages formels des années
1940. Leur puissance à décrire des ensembles réguliers explique qu’elles se retrouvent dans plusieurs
domaines scientifiques dans les années d’après-guerre et justifie leur adoption en informatique. Les
expressions rationnelles sont aujourd’hui utilisées par les informaticiens dans l’édition et le contrôle de
texte ainsi que dans la manipulation des langues formelles que sont les langages de l’informatique. [41]

g) Sécurisation des serveurs

Sécurité Web : serveur d’application
Une architecture Web est une architecture 3-tiers, elle est composée d’un client, d’un serveur d’application
et d’un serveur de données. Chacun de ces composants est vulnérable et donc attaquable. La force d’une
chaine n’est égale qu’à celle de son plus faible maillon.
 attaque coté client sur le navigateur (virus, trojan, cookies, cross site scripting,..) ;
 attaque coté serveur d’application (Apache, Tomcat) ;
 attaque coté serveur de données (MySQL) ;
 injection SQL, dénis de service, prise de main.

15.1.2.10 La veille technologique

Elle permet l’adaptation de la sécurité du système d’information en fonction de l’actualité.
Moyen de défense : Pour les administrations et les entreprises il s’agit de mettre en place des services.
 CERT-FR ;
 revues spécialisées, HSC, MISC, etc… ;
 listes de diffusion spécialisées ;
 offres de service CERT.

16 Formaliser les mesures de sécurité à mettre en œuvre

Alors que je m’apprête à proposer des mesures complémentaires de sécurité, je n’oublie pas les mesures
de sécurité déjà en place et liés à d’autres analyses de risques comme celle du data centre qui héberge
l’application et à ce titre de nombreuses mesures de sécurité tel qu’énumérées au chapitre suivant étaient
déjà en place chez mon client. En effet, ma mission porte sur l’analyse de risque de l’application et cette
dernière n’ira pas mettre en concurrence l’analyse de risque de l’infrastructure du SI par exemple, ceci ne
fait pas parti du périmètre de l’étude, tout comme je n’ai pas remis en cause les mesures de sécurité déjà
en place pour couvrir ces risques.

16.1 Mesures de sécurité complémentaires

Une mesure de sécurité peut avoir plusieurs états totalement indépendants du traitement du risque :

 Non retenue : exemple, la proposition est interdite par la PSSI de l’entreprise, ou l’entreprise à un
mauvais RETEX vis-à-vis de cette solution ;

Page 97 sur 145

  En étude : exemple, les équipes doivent vérifier que la solution est compatible avec l’application et
ne va pas empêcher son fonctionnement ;
 Proposée : cette mesure est officiellement proposée à l’arbitrage du commanditaire qui choisira
en fonction des risques qui lui sont liés, ainsi que de sa facilité de mise en œuvre, de la
sélectionner définitivement ou non.
 En place : exemple, l’équipe a été sensibilisée à la sécurité et utilise des méthodes de
développement sécurisé.
Ainsi vous allez retrouver ci-dessous les mesures de sécurité spécifiques que j’ai proposée suite à mon
étude à mon client dans le cadre de ma mission afin de couvrir les risques que j’avais précédemment
identifiés et qui n’étaient pas déjà couvert par des mesures de sécurité.

État
réf Vulnérabilité Risque
Titre de la mesure Description Responsable
mesure couverte impacté Non En En
Proposée
retenu étude place

* Vulnérabilités
logicielles (failles
Planifier des tests
XSS, injection de
d'intrusion avant et
code…)
après mise en
* Versions
production de RC1
logicielles obsolètes
MS_1 Tests d'intrusion l'applicatif et RD1 X Prestataire
* Absence de
proposer une RI2
durcissement des
trajectoire de
configurations
résolution des
(paramétrages par
anomalies
défaut, ports
ouverts…)
Mettre en place
des audits de code
(axés sur la
* Vulnérabilités
sécurité du code) RC1
logicielles (failles
MS_2 Audit de code itératifs et RD1 X Prestataire
XSS, injection de
proposer une RI2
code…)
trajectoire de
résolution des
anomalies
Utiliser un
* Communication
protocole sécurisé
non chiffrée entre le
(HTTPS) entre le
Netscaler/Serveur
Chiffrement de la Netscaler et le
web/ Application
MS_3 liaison Netscaler - serveur application RC5 X Prestataire
Web (en front end),
application web WEB, afin de
utilisée pour le
sécuriser l'échange
transport des jetons
du jeton
d'authentification
d'authentification.
S'assurer que la
gestion des actifs
et des
Intégration de la RC1
vulnérabilités sont * Versions
MS_4 gestion des actifs et RD1 X Prestataire
bien intégrés dans logicielles obsolètes
des vulnérabilités RI2
les processus mis
en place par le
groupement

Page 98 sur 145

 État
réf Vulnérabilité Risque
Titre de la mesure Description Responsable
mesure couverte impacté Non En En
Proposée
retenu étude place

En particulier, les
versions
applicatives des
serveurs web en
Montée de version zone frontale RC1
* Versions
MS_5 sur les serveurs (Apache) et les RD1 X Prestataire
logicielles obsolètes
web et applicatifs serveurs applicatifs RI2
(Tomcat) doivent
être exemptes de
vulnérabilités
connues.
Utiliser un
protocole sécurisé
* Communications
(SFTP) pour
SFTP pour le non chiffrées lors du
déployer les RC1
déploiement des déploiement des
MS_6 fichiers RD1 X Prestataire
fichiers fichiers
d'installation, afin RI2
d'installation d'installation
de garantir
(protocole FTP)
l'intégrité des
applicatifs installés.
Restreindre
l'utilisation de
l'outil d'extraction RC1
Restriction sur le de données aux RC2
MS_7 X Prestataire
requêteur SQL seuls RC3
administrateurs RC4
fonctionnels de la
solution
Analyser les
fichiers uploadés
par un antivirus * Pas de contrôle
Analyse antivirale
MS_8 avant tout des uploads des RD2 X Prestataire
des uploads
traitement, dans utilisateurs
un sas de
décontamination
S'assurer qu'un
mécanisme permet
Contrôle des de restreindre * Pas de contrôle
MS_9 extensions des l'upload de fichiers des uploads des RD2 X Prestataire
fichiers uploadés uniquement aux utilisateurs
formats prévus par
l'utilisation.
Les données de
production, en
particulier pendant * Manque de
Encadrer la phase de reprise sensibilisation,
l'utilisation des des données, mauvaises pratiques
Prestataire /
MS_10 données de doivent être * Manipulation de RC6 X
Entreprise
production par les manipulées dans le données de
équipes projet respect de la production par les
politique de équipes projet
protection des
données sensibles.
S'assurer de la
Respect des * Non-respect du RD1
MS_11 procédures bonne prise en X Prestataire
processus RD2
compte des
d'ajout/suppression d'ajout/modification
procédures d'ajout

Page 99 sur 145

 État
réf Vulnérabilité Risque
Titre de la mesure Description Responsable
mesure couverte impacté Non En En
Proposée
retenu étude place

de règles firewall et de suppression des règles

des règles de
filtrage
* Vulnérabilités
logicielles (failles
XSS, injection de
code…)
Les développeurs
* Absence de
doivent être
Sensibilisation des durcissement des RC1
sensibilisés à la
MS_12 développeurs à la configurations RD1 X Prestataire
sécurité des
sécurité (paramétrages par RI2
développements
défaut, ports
applicatifs
ouverts…)
* Manque de
sensibilisation,
mauvaises pratiques
Les utilisateurs de
l’application ayant
un profil
d'administration
fonctionnelle
(ajout suppression
d'utilisateurs,
accès aux requêtes
Authentification SQL…) doivent
forte par certificat s'authentifier à * Authentification
RI4
MS_13 pour les l'aide d'une simple pour les X Prestataire
RC2
administrateurs authentification utilisateurs
fonctionnels forte par certificat.
De manière
générale,
l'authentification
forte doit être
utilisée autant que
possible pour
l'ensemble des
utilisateurs.
Les applicatifs
apportés (Apache,
Tomcat…) doivent
être durcis selon
l'état de l'art en * Absence de
vigueur durcissement des
RC1
Durcissement des (suppression des configurations
MS_14 RD1 X Prestataire
configurations comptes (paramétrages par
RI2
génériques, défaut, ports
personnalisation ouverts…)
des erreurs,
fermetures des
ports non utilisés,
etc.)
La gestion des * Gestion difficile
Respect de la habilitations doit des habilitations
politique de revue être conforme à la RI4
MS_15 (non-respect de la X Prestataire
des droits propre à politique de revue RC2
procédure
l’application des droits mise en Entreprise)
place sur

Page 100 sur 145

 État
réf Vulnérabilité Risque
Titre de la mesure Description Responsable
mesure couverte impacté Non En En
Proposée
retenu étude place

l’application

Lors de la création
de compte
utilisateur ou lors
de changement de
mot de passe,
Respect de la * Politique de mot
l'utilisateur ne doit
politique de mot de de passe de
MS_16 pouvoir saisir RI4 X Prestataire
passe de l’entreprise non
qu'un mot de
l'entreprise respectée
passe conforme à
la politique de mot
de passe en
vigueur à
l'Entreprise
Chiffrer les flux
Chiffrement des * Communications RC4
internes à
MS_17 flux internes de non chiffrées sur RC5 X
l’application (TLS)
l’application l'infrastructure RI3
jusqu'à l'archivage.
Chiffrer les
informations
sensibles (champs
en base ou pièces
jointes) en base. RC1
Chiffrement des Chiffrer les * Données sensibles RC2
MS_18 données sensibles données suivantes non chiffrées en RC3 X Prestataire
en base : base RC4
- les informations à RI3
caractère
personnel
- les pièces
justificatives
Intégrer les
composants de
Plan de continuité
MS_19 l’application dans RD3 X Prestataire
d'activité
le PCA/PRA de
l’entreprise.
Les journaux
techniques et
applicatifs sont
remontés à la
solution de gestion
des logs de
l’entreprise (ELK).
* Surveillance
En particulier,
Gestion des traces administrateur : pas RI2
toutes les actions
MS_20 applicatives et de vue globale des RC3 X Prestataire
administrateurs,
techniques actions RC4
les accès aux bases
administrateurs
de données, les
authentifications
(succès + échec),
changements de
droits utilisateurs
doivent être
journalisés.

Page 101 sur 145

 État
réf Vulnérabilité Risque
Titre de la mesure Description Responsable
mesure couverte impacté Non En En
Proposée
retenu étude place

Former les
administrateurs
aux tâches et
nouvelles
Procédures
technologies
d'exploitation et * Erreurs de
MS_21 employées. RI1 X Prestataire
formation des manipulation
S'assurer que des
administrateurs
procédures
d'exploitation
existent pour ces
actions.

Tableau 21 : Mesures de sécurité complémentaires

Page 102 sur 145

 16.1.1 Calcul des risques résiduels

J’ai évalué les risques résiduels dans le tableau ci-dessous dans l’hypothèse où l’ensemble des mesures de sécurité que j’ai présenté dans la partie
précédente seraient retenues et correctement appliquées.
On identifiera en rouge les mesures qui ne sont pas retenues, la vraisemblance résiduelle en tiendra compte. Dans le cadre de ma mission deux mesures de
sécurité proposées n’ont pas été retenues. Cette décision a été prise par la direction de mon client en concertation avec ses équipes de sécurité pour une
question notamment de retour sur investissement face à l’effort requis. Dans le tableau ci-dessous les mesures non retenues ne sont pas mises en rouge et
présentées comme si elles avaient été retenues.

Vraisembl
Réf Critère Gravit Vraisem Risque
Exemple Scénarios de risque (SM X ER) Risque initial Mesure complémentaire ance
risque sécurité é blance résiduel
résiduelle

* Tests d'intrusion
* Audit de code
* Risque de compromission suite à une attaque
* Intégration de la gestion des actifs et des
virale
vulnérabilités
Des hackers ayant de grandes capacités et
* Montée de version sur les serveurs web et
connaissances, exploitent des failles des
applicatifs
RC1 C composants logiciels pour accéder à des données 3 3 Important * SFTP pour le déploiement des fichiers 1 Mineur
sensibles. La probabilité de l'attaque augmente avec
d'installation
les failles des composants, l'intérêt de l'attaque et
* Restriction sur le requêteur SQL
la possibilité de l'effectuer à l'aide de social
* Sensibilisation des développeurs à la sécurité
engineering.
* Durcissement des configurations
* Chiffrement des données sensibles en base

Page 103 sur 145

 Vraisembl
Réf Critère Gravit Vraisem Risque
Exemple Scénarios de risque (SM X ER) Risque initial Mesure complémentaire ance
risque sécurité é blance résiduel
résiduelle

* Tests d'intrusion
* Audit de code
* Risque de d'indisponibilité suite à une attaque
* Intégration de la gestion des actifs et des
virale
vulnérabilités
Des hackers ayant de grandes capacités et
* Montée de version sur les serveurs web et
connaissances, exploitent des failles des
applicatifs
RD1 D composants logiciels pour rendre indisponible 3 3 Important * SFTP pour le déploiement des fichiers 1 Mineur
l'application. La probabilité de l'attaque augmente
d'installation
avec les failles des composants, l'intérêt de
* Sensibilisation des développeurs à la sécurité
l'attaque et la possibilité de l'effectuer à l'aide de
* Durcissement des configurations
social engineering.
* Respect des procédures d'ajout/suppression de
règles firewall

* Risque de compromission par vol des crédentiels

L'authentification étant simple pour les utilisateurs,
une personne malveillante installe un keylogger (les
* Restriction sur le requêteur SQL
postes clients ne sont pas maîtrisés), tâche facilité
* Authentification forte par certificat pour les
grâce à du social engineering ou tout simplement
administrateurs fonctionnels
RC2 C observe la saisie du mot de passe de l'utilisateur 3 2 Moyen * Respect de la politique de revue des droits 1 Mineur
(shoulder surfing) afin d'accéder au compte. La
propre à l’application
solution ne pouvant garantir l'identité de
* Chiffrement des données sensibles en base
l'utilisateur, celui-ci peut accéder aux données
sensibles. Cette attaque peut être motivée pour
frauder par exemple.
* Risque de compromission de source interne
Un administrateur interne malveillant profite d'une
traçabilité des actions administrateur non
dissuasive (mauvaises pratiques, pas * Gestion des traces applicatives et techniques
RC3 C d'enregistrement des actions des administrateurs…) 3 2 Moyen * Chiffrement des données sensibles en base 1 Mineur
pour accéder à des données sensibles et les * Restriction sur le requêteur SQL
divulguer (motivation financière, politique…). Les
bases chiffrées ne permettent pas de se prévenir
des attaques internes.

Page 104 sur 145

 Vraisembl
Réf Critère Gravit Vraisem Risque
Exemple Scénarios de risque (SM X ER) Risque initial Mesure complémentaire ance
risque sécurité é blance résiduel
résiduelle

* Risque de compromission par sniffing

Un utilisateur du réseau interne sniffe les flux
* Chiffrement des flux internes L’application
internes non chiffrés, ou accède au sas SMA afin
* Chiffrement des données sensibles en base
RC4 C d'accéder à des données sensibles de l'application. 3 2 Moyen * Gestion des traces applicatives et techniques 1 Mineur
Cela peut être sur sollicitation externe financée
* Restriction sur le requêteur SQL
dans le but d'obtenir la nullité d'une procédure de
justice par exemple.
* Risque de compromission par rejeu
L'authentification des utilisateurs s'effectue au
niveau du Netscaler, les informations
d'identification (jeton) peuvent être interceptées,
* Chiffrement de la liaison Netscaler - application
modifiées et rejouées. Un attaquant peut profiter
RC5 C de l'absence de chiffrement sur le réseau interne 3 2 Moyen web 1 Mineur
* Chiffrement des flux internes L’application
(en particulier entre le Netscaler et le serveur
application web, situé en frontend) pour sniffer les
paquets, usurper une identité, et ainsi
compromettre des données sensibles.
* Risque d'altération suite à une erreur de
manipulation
* Procédures d'exploitation et formation des
RI1 I Une erreur humaine d'un administrateur ou d'un 3 2 Moyen administrateurs
1 Mineur
exploitant sur l'infrastructure de virtualisation
entraîne des pertes ou des altérations de données.
* Tests d'intrusion
* Audit de code
* Intégration de la gestion des actifs et des
* Risque d'altération des journaux constituant la
vulnérabilités
piste d'audit
* Montée de version sur les serveurs web et
Un attaquant interne profite d'une vulnérabilité
RI2 I logicielle ou applicative pour effacer ou modifier 3 2 Moyen applicatifs 1 Mineur
* SFTP pour le déploiement des fichiers
des traces à valeur probante dans la base de
d'installation
données dédiée. La piste d'audit est compromise.
* Sensibilisation des développeurs à la sécurité
* Durcissement des configurations
* Gestion des traces applicatives et techniques

Page 105 sur 145

 Vraisembl
Réf Critère Gravit Vraisem Risque
Exemple Scénarios de risque (SM X ER) Risque initial Mesure complémentaire ance
risque sécurité é blance résiduel
résiduelle

* Risque d'altération de données par interception

et rejeu
Un attaquant interne profite de l'absence de
* Chiffrement des données sensibles en base
chiffrement des flux et de contrôle d'intégrité des
RI3 I données jusqu'à l'archivage pour procéder à une 3 2 Moyen * Chiffrement des flux internes L’application 1 Mineur
* Gestion des traces applicatives et techniques
attaque Man in the Middle et rejouer des données
altérées (modification des montants par exemple,
perte d'intégrité d'un contrat)
* Risque de d'indisponibilité suite à un upload
malicieux
Un attaquant upload un fichier exécutable * Analyse antivirale des uploads
malicieux, en l'absence de restriction sur les * Contrôle des extensions des fichiers uploadés
RD2 D extensions de fichier, la surface d'attaque est 3 2 Moyen * Respect des procédures d'ajout/suppression de 1 Mineur
augmentée malgré les contrôles antiviraux en place. règles firewall
Ce type d'attaque peut aboutir à une indisponibilité
du système.
* Risque de compromission suite à la manipulation
de données de production
Lors de la phase de reprise de données, des
données de production sont manipulées par les
* Encadrer l'utilisation des données de production
RC6 C équipes projets. En l'absence de respect strict des 3 2 Moyen par les équipes projet 1 Mineur
règles de protection des données sensibles mises en
place à l'Entreprise (échange en clair par mail,
utilisation sur un environnement non productif), ces
données peuvent être compromises.
* Risque de compromission suite à une usurpation
d'identité * Authentification forte par certificat pour les
Si la méthode de création de mot de passe n'est pas administrateurs fonctionnels
conforme à la politique de mot de passe en vigueur * Respect de la politique de revue des droits
RI4 I dans l'Entreprise, le risque d'usurpation est 3 2 Moyen propre à L’application 1 Mineur
augmenté en raison de l'utilisation de mots de * Respect de la politique de mot de passe de
passe potentiellement plus faibles. Des données l'Entreprise
sensibles peuvent être indument modifiées.

Page 106 sur 145

 Vraisembl
Réf Critère Gravit Vraisem Risque
Exemple Scénarios de risque (SM X ER) Risque initial Mesure complémentaire ance
risque sécurité é blance résiduel
résiduelle

* Risque d'indisponibilité suite à une catastrophe

naturelle
Une crue centennale de la Seine rendrait
RD3 D indisponible la solution (coupure d'alimentation du 3 1 Mineur * Plan de continuité d'activité 1 Mineur
Datacenter Vauban). Le PRA ne sera disponible et
opérationnel qu'à compter du pilote. La source de
menace est environnementale.

Tableau 22 : Risques résiduels

Page 107 sur 145

 16.1.2 Matrice des risques bruts

Outil indispensable à plusieurs titres, la matrice de risque est le meilleur moyen de présenter à une
audience de manière synthétique les résultats obtenus.
On retiendra la matrice des risques bruts qui présente les résultats de l’analyse de risque avant leur
traitement. La matrice de risques résiduels qui présente les risques résiduels post traitement du
risque et la matrice de risque nette qui présente un état du risque accepté par le client c'est-à-dire
qui n’a plus vocation à évoluer et qui représente la réalité.

D3 C2 C3 C4 C5 C1 D1

D2 I4 I3 C6

I1 I2

Figure 12 : Matrice des risques bruts

Page 108 sur 145

16.1.3 Matrice des risques résiduels

C1 C2 C3 C4

C5 D1 D2 D3

I1 I2 I3 I4
C6

Figure 13 : Matrice des risques résiduels

Page 109 sur 145

17 Exemple de mise en œuvre d’une mesure de sécurité
dans le cadre de notre étude de cas
Durant notre étude de cas nous avons proposé précédemment, à la fin de notre processus d’analyse
de risque, plusieurs mesures de sécurité. Nous allons nous attarder sur l’une d’entre elles, la mesure
de sécurité complémentaire MS_20. Cette mesure est relative à la gestion des traces applicatives et
techniques, elle consiste à mettre en œuvre des moyens permettant d’assurer cette gestion, mais
comment procède-t-on afin d’aller au bout de la mission qui nous a été confiée ?
Après m’être concerté avec mon client nous avons décidé que les traces applicatives et techniques
devaient être remontées à une solution de gestion centralisée des logs. En l’occurrence, mon client
dispose déjà d’une solution de gestion centralisée des logs et il s’agit de s’interfacer à avec cette
solution. Elle est donc déjà en place au sein de l’entreprise et est maitrisée, mais encore faut-il savoir
ce que l’on souhaite superviser et comment y arriver.
Il est fortement recommandé à ce que, toutes les actions des administrateurs, tous les accès aux
bases de données, toutes les authentifications (succès + échec) ainsi que tous les changements de
droits utilisateurs soient journalisés j’ai découvert cela au cours de mes recherches sur le sujet. Ces
recommandations sont issues de retours d’expériences d’organismes privés et public disponibles sur
internet et de nombreuses publications sur le sujet. Le risques est de ne pas surveiller les
administrateurs et de ne pas disposer d’une vue globale des actions administrateurs soit les risques
RI2, RC3 et RC4 identifiés et présents au sein de l’analyse de risque que j’ai réalisé.
Cette mesure de sécurité est donc issue, mais participe également de ce fait, au respect des
recommandations de sécurité de l’ANSSI pour la mise en œuvre d’un système de journalisation
N°DAT-NT-012/ANSSI/SDE/NP [42]. Ce document constitue un référentiel de bonnes pratiques
incontournable mais non unique, j’ai ainsi isolé 24 recommandations que je vous propose en Annexe
1. D’autres organismes s’intéressent fortement à la question, ainsi, la NSA met également à notre
disposition un document de référence en ce qui concerne le log management [43], qui nous éclaire
également sur les moyens à mettre en œuvre dans le cadre de l’implémentation de cette mesure de
sécurité.
En effet, se limiter à vouloir appliquer au sens strict les préconisations ne suffira pas quand il s’agira
d’implémenter cette mesure. Dans notre exemple pour qu’il y ai une supervision des évènements de
sécurité comme demandés il faut s’assurer que l’on dispose bien des événements que l’on souhaite
superviser, d’un agent ou d’un service qui puisse les pousser de manière sécurisée à la solution de
supervision centrale et que personne ne puisse masquer ses actes. Il faut donc s’interroger sur la
manière la plus efficiente d’implémenter « une version » de la mesure qui a été retenue.
Donc, en réfléchissant il est peu probable que des journaux d’événements soient supprimés au cours
des opérations normales d’exploitation des systèmes. Il est donc certain dans ce cas, que l’acte est
délibéré. Si l’acte est délibéré il est vraisemblable qu'il s’agisse d’un utilisateur malveillant et ce
dernier peut vouloir couvrir ses traces en effaçant un journal d’événements. Quand un journal
d'événements est effacé, il est donc suspect. La collecte centralisée des événements a l'avantage de
rendre beaucoup plus difficile pour un attaquant de brouiller les pistes mais l’on surveillera donc en
priorité des événements relatifs à l’altération des traces en isolant par exemple sous Windows les
logs ci-dessous :

Page 110 sur 145

 ID Level Event Log Event Source
Event Log was Cleared 104 Informational System Microsoft-Windows-Eventlog
Audit Log was Cleared 1102 Informational Security Microsoft-Windows-Eventlog
Tableau 23 : Évènements Windows relatifs à l’effacement des logs

À présent, il s’agit de s’assurer que l’on dispose bien des évènements que l’on a identifiés comme
pertinents. Tracer les activités des comptes locaux peut notamment aider à détecter les PtH (Pass the
Hash activity) ainsi que d’autres activités illicites. Des informations additionnelles tel que les accès
distants, les ajouts de droits à des utilisateurs et les blocages de comptes peuvent être tracés. Les
élévations de privilèges devraient être tout particulièrement tracées afin de s’assurer du coté licite
de l’opération. L’élévation de droits d’un compte utilisateur normal pour un groupe à privilège peut
en effet, refléter une activité malicieuse. La liste d’événements Windows présentée ci-dessous est
donc proposée à la supervision, elle permet de concrétiser la mesure de sécurité si ce n’est dans son
ensemble du moins en partie.
ID Level Event Log Event Source
Account Lockouts 4740 Informational Security Microsoft-Windows-Security-Auditing
User Added to 4728, 4732,
Informational Security Microsoft-Windows-Security-Auditing
Privileged 4756
Group
Security-Enabled group
4735 Informational Security Microsoft-Windows-Security-Auditing
Modification
Successful
4624 Informational Security Microsoft-Windows-Security-Auditing
User Account
Login User
Failed
4625 Informational Security Microsoft-Windows-Security-Auditing
Account Login
Account Login
4648 Informational Security Microsoft-Windows-Security-Auditing
with Explicit
Credentials Tableau 24 : Évènements Windows relatifs à l’usage des comptes
Note : si l’on bloque un compte connecté au domaine une trace sera générée sur le contrôleur de
domaine, pour un compte local, une trace sera générée en local.
On procédera donc de la même manière afin de superviser tous les événements que l’on aura
sélectionnés et retenus et cela sur tous les biens support du périmètre concerné par les risques
identifiés durant l’analyse de risques. À l’issue, cette mesure peut être considérée comme
implémentée et elle suit alors son cycle de vie au même titre que le système d’information qui
l’héberge.

Page 111 sur 145

Bilan de la mission

Page 112 sur 145

 Bilan de la mission
Toute mission est censée se solder par un bilan de mission et celui de mon intervention fut jugé très
positivement par mes interlocuteurs au sein de mon entreprise et coté client.
Pour ce qu’il en est du projet en lui-même il est aux jours d’aujourd’hui suspendu pour une durée de
trois mois pour diverses raisons sans liens avec ma mission.
Quant à la fin de ma mission d’analyse de risque elle s’est terminée par la présentation des résultats
de l’analyse des risques à l’AQSSI (Autorité Qualifiée de Sécurité des Systèmes d'Information) de la
direction concernée. Les risques majeurs ont été mis en avant et associés à des mesures de sécurité
préconisés qui ont également été passé en revus. Suite à cette fin de mission qui a donc été
officialisée par le biais d’un comité sécurité, trois réunions ont été réalisées sous la forme de GT
(groupes de travail) afin d’aider à prendre une décision finale et à statuer sur l’éventualité de mettre
ou de ne pas mettre en œuvre ces mesures de sécurité. Ainsi, il a été passé en revue le cout de mise
en place de ces mesures ainsi que le cout de mise en œuvre des moyens et leur facilité
d’exploitation. L’ensemble a été mis en comparaison par rapport aux gains prévus en terme de
sécurité et surtout de réduction des risques censés être couvert par ces mesures.
Ainsi, après avoir présenté en §16.1.2 une matrice des risques bruts nous avions présenté en §16.1.3
une matrice des risques résiduels dans le cas où toutes les mesures de sécurité seraient mises en
œuvre. Hors dans le cas ou au final le choix est fait pour diverses raisons de ne pas mettre en œuvre
certaines mesures de sécurité proposées en fin d’analyse des risques ce que l’on appellera les risques
nets ne seront pas égaux aux risques résiduels présentés en fin d’analyse. Les risques qui se trouvent
alors non réduits ou « moins réduis » sont donc considérés comme acceptés par le commanditaire
qui prend cette responsabilité.
Dans le cadre de notre mission nous pouvons donc présenter ci-dessous §18 une matrice des risques
nets qui reflètent les choix faits par le client commanditaire de cette mission d’analyse des risques.
En choisissant de ne pas mettre en œuvre trois mesures techniques de sécurité proposées à l’issu de
l’analyse le commanditaire accepte les risques qui devaient être réduits par la mise en œuvre de ces
mesures de sécurité.
Il est important de savoir accepter ce genre de décision en fin de mission et ce n’est pas chose facile.
En effet, il peut être frustrant après avoir autant travaillé sur le sujet, de savoir qu’un risque de vol
d’information perdure et n’est pas couvert de manière optimale car il a été décidé, pour des
conditions notamment de performance et de délais de réalisation de l’étude d’impact, de ne pas
activer le chiffrement d’une base de donnée qui pourtant fournie ce service par défaut. Par ailleurs, il
est intéressant de savoir que d’un côté une mesure prévoyant des moyens technique
d’authentification forte à des fins d’imputabilité et de sécurisation des accès aux données était
préconisée pour les personnels interne à privilèges élevés et ne sera au final pas mis en œuvre car la
population n’étaient pas asse représentative. Alors que dans d’autres conditions ces moyens
d’authentification forte seront imposés à une population pourtant réduite en droits et à quinze
personnes, mais constitués de prestataires externes. De même, dans la continuité de ce cycle
décisionnel, il est simple de concevoir et d’accepter que l’on ne puisse pas demander à ce qu’une
application génère des traces applicatives métier si elle n’a pas été conçu pour ça eu départ et ne
dispose pas ainsi de capacité natives à générer des traces métiers car cela demanderai un effort
colossal de redéveloppement.

Page 113 sur 145

18 Matrice des risques nets

C1 C6 C2

C5 D1 D2 D3 C3

C4
I1 I2 I4
I3

Figure 14 : Matrice des risques nets

Page 114 sur 145

Conclusion

Page 115 sur 145

 Conclusion
Le système d’information d’une entreprise peut être vital à son fonctionnement. Il est donc
nécessaire d’assurer sa protection afin de lutter contre les menaces qui pèsent sur l’intégrité, la
confidentialité et la disponibilité des ressources de l’entreprise.
C’est un message qui a toujours été difficile à faire passer auprès des équipes. La sécurité et les
professionnels qui travaillent dans ce domaine sont vus comme des contraintes et non comme des
atouts, des apporteurs de valeur et de garantie des services.
Durant cette mission un des challenges majeurs que j’ai eu à relever aura donc été de réussir à
impliquer tous les membres du projet dans cette démarche de sécurité. Hors la malveillance humaine
est souvent à l’origine des menaces identifiées lors des analyses de risques, qu’il s’agisse de vol
d’information ou de sabotage, n’importe qui avec de la volonté peut s’improviser pirate informatique
avec des outils adaptés. Difficile doc de parler sécurité à des personnes dont on trouve tout à fait
vraissemblant leur possible défection, compromission ou tout simplement insouciance.
Une des autres tâches les plus ardus aura été de réussir à rassembler, à constituer et à maitriser un
référentiel de connaissance technique de sécurité le plus large possible, ce qui est pourtant essentiel
à la réalisation de la mission. En effet comment proposer à l’issue de l’analyse de risque des mesures
de sécurité organisationnelles et techniques sans passer par cette recherche. Si l’on n’est pas au fait
d’un large panel des possibilités aussi bien logicielles que physique il est difficile de proposer des
solutions au traitement des risques.
L’EICNAM m’aura préparé des années durant à la réalisation de ce type de mission, notamment en
me dotant d’une démarche pragmatique comme vu dans des unités d’enseignement tel que l’ENG
210 ou en me dotant des moyens nécessaires à la réalisation d’un travail de recherche.
L’EICNAM m’aura également armé de différentes méthodes (EBIOS2010, ISO 27005, MEHARI) et
d’outils (ISHIKAWA, SWOT, Rétro conception, Points de fonction, principes issues des unités
d’enseignement NFE209 et NFE210…) m’ayants permis d’ordonner ma mission, de formaliser des
objectifs et de satisfaire ainsi mon client en terme de qualité.
Beaucoup de compétences sont nécessaires pour assurer une sécurité optimale d’un système, d’une
entreprise, mais il est impossible de garantir la sécurité de l’information à 100%. Malgré tout, il existe
des moyens efficaces pour faire face à ces agressions. C’est pour cela qu’il est utile de bien savoir
gérer les ressources techniques, humaine et organisationnelles disponibles et ainsi comprendre les
risques liés à la sécurité informatique afin de pouvoir construire une politique de sécurité adaptée
aux besoins de la structure à protéger.
Il aura été essentiel pour moi de m’intégrer aux méthodes de mon client plutôt que d’imposer les
miennes. Une de mes forces aura été de systématiquement adapter mon travail aux différents
interlocuteurs et de réussir à les impliquer, même pour les plus récalcitrants.
Mon analyse de risque aura permis à mon client de maitriser les risques qui pèsent sur son entreprise
et d’avancer en toute connaissance de cause. Lui-même s’impose cette démarche de sécurité pour
tout nouveau projet, c’est un acte réflexe pour lui aujourd’hui qui ne soulève plus de questions en
interne car les collaborateurs en voient l’intérêt contrairement aux équipes projet de mon entreprise
qui n’étaient pas sensibilisés à la sécurité et qui ont dû être convaincus. J’ai joué un grand rôle à ce

Page 116 sur 145

titre et suite à ma mission l’équipe du projet est aujourd’hui sensibilisé et certains collaborateurs
sont même des acteurs de la sécurité auprès des nouveaux arrivants et sur leurs autres projets.
Une des difficultés que j’ai également dû surmonter vient du fait que je ne suis pas employé chez un
client unique. J’ai donc dû aménager ma mission sur la durée tout en en réalisant des missions
parfois sur d’autres comptes. Le défi était de continuer à entretenir le lien créé avec les équipes du
projet même à distance et si cela a été un succès c’est avant tout grâce au chef de projet qui a
continué de m’impliquer et de me tenir informer même quand j’étais en déplacement.
La mise en place d’un dispositif de sécurité efficace ne doit cependant jamais se passer d’une veille
régulière au bon fonctionnement du système. Ainsi même le travail réalisé doit être remis en cause.
Dans le cadre de ma mission j’ai ainsi prévu qu’une révision des patches de sécurité sera réalisée
avant le mise en production effective de l’application afin d’éviter du mieux possible la présence de
vulnérabilités sur le système.
Durant ce mémoire nous aurons parcourus toutes les phases qui m’ont été nécessaires durant ma
mission. De l’analyse des risques, à la sélection des mesures à mettre en œuvre et à
l’accompagnement de mon client. J’ai dû réaliser un travail de veille et de synthèse que je pense
adapter et qui pourra resservir.
Ce mémoire avait pour objectif de présenter de manière détaillée mon travail, la démarche que j’ai
préparée et mise en œuvre dans le cadre de ma mission et que j’ai basée sur les meilleures pratiques
et méthodes du domaine. J’ai la prétention d’avancer que ce mémoire peut permettre à n’importe
quel ingénieur de réaliser une mission d’analyse de risque et d’organiser ainsi ce que l’on pourra
qualifier comme une lutte informatique défensive.
Cette mission m’a permis de progresser en tant que consultant, de prendre de l’envergure dans la
position de RSSI qui était la mienne et de pouvoir sensibiliser toute une équipe projet à la sécurité
des systèmes d’information.
Face aux défis qui vont se présenter à nous dans le futur il est essentiel que nous soyons tous
sensibilisés et formés à la sécurité. Les ingénieurs auront de manière sûre un rôle majeur à jouer
dans les cyberguerres, seront nous alors les sauveurs ou causeront nous la perte du monde ultra
connecté de demain ? Face à ces dilemmes il faut savoir adopter une posture adéquate, faire face
avec pragmatisme et méthode. L’EICNAM et mon entreprise, m’auront permis de réaliser ma mission
et j’ai pu ainsi participer à la sécurisation d’une entreprise qui est en maitrise de ses risques.

Page 117 sur 145

Bibliographie

Page 118 sur 145

 Bibliographie

[1] « Direction des ressources humaines de l’Armée de terre — Wikipédia ». [En ligne]. Disponible
sur:
https://fr.wikipedia.org/wiki/Direction_des_ressources_humaines_de_l%27Arm%C3%A9e_de_
terre. [Consulté le: 26-déc-2016].
[2] « Infrastructure as a service — Wikipédia ». [En ligne]. Disponible sur:
https://fr.wikipedia.org/wiki/Infrastructure_as_a_service. [Consulté le: 26-déc-2016].
[3] « Platform as a service - Wikipedia ». [En ligne]. Disponible sur:
https://en.wikipedia.org/wiki/Platform_as_a_service. [Consulté le: 26-déc-2016].
[4] « Logiciel en tant que service — Wikipédia ». [En ligne]. Disponible sur:
https://fr.wikipedia.org/wiki/Logiciel_en_tant_que_service. [Consulté le: 26-déc-2016].
[5] ANSSI, « EBIOS — Expression des Besoins et Identification des Objectifs de Sécurité | Agence
nationale de la sécurité des systèmes d’information ». [En ligne]. Disponible sur:
http://www.ssi.gouv.fr/uploads/2011/10/EBIOS-1-GuideMethodologique-2010-01-25.pdf.
[Consulté le: 14-sept-2016].
[6] ANSSI, « Référentiel Général de Sécurité version 2.0 ». .
[7] ISO, « ISO/CEI 27002:2013(fr), Technologies de l’information — Techniques de sécurité — Code
de bonne pratique pour le management de la sécurité de l’information », Wikipédia. .
[8] Wikipédia, « Information Technology Infrastructure Library (ITIL) », Wikipédia. 06-sept-2016.
[9] CyberEdu, « Sensibilisation et initiation à la cybersécurité ».
[10] J. LaPiedra, « The Information Security Process Prevention, Detection and Response ». SANS
Institute, 2002-2000.
[11] Wikipédia, « Roue de Deming », Wikipédia. 07-sept-2016.
[12] ISO, « ISO 9001 », Wikipédia. 08-août-2016.
[13] ISO, « ISO/CEI 27001:2013(fr), Technologies de l’information — Techniques de sécurité —
Systèmes de management de la sécurité de l’information — Exigences », Wikipédia. .
[14] ISO, « ISO/CEI 20000 », Wikipédia. 12-août-2015.
[15] « Méthode harmonisée d’analyse des risques », Wikipédia. 10-sept-2014.
[16] ISO, « ISO/IEC 27005:2011 - Technologies de l’information -- Techniques de sécurité -- Gestion
des risques liés à la sécurité de l’information ». [En ligne]. Disponible sur:
http://www.iso.org/iso/fr/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=56742.
[Consulté le: 14-sept-2016].
[17] International Atomic Energy Agency, Computer security at nuclear facilities: reference manual.
Vienna: International Atomic Energy Agency, 2011.
[18] ISO, « ISO 19011:2011(fr), Lignes directrices pour l’audit des systèmes de management »,
Wikipédia. .
[19] « Daniel Bleichenbacher - Wikipedia ». [En ligne]. Disponible sur:
https://en.wikipedia.org/wiki/Daniel_Bleichenbacher. [Consulté le: 26-déc-2016].
[20] A. Nitaj, « CRYPTANALYSE DE RSA ». Laboratoire de Mathematiques Nicolas Oresme, 28-juin-
2009.
[21] « CSS - CSRF : Cross-Site Request Forgery », Wikipédia. 15-nov-2014.
[22] « CSS - XSS : Cross-site scripting », Wikipédia. 16-nov-2014.
[23] « Injection SQL », Wikipédia. 15-nov-2014.
[24] « Risque naturel », Wikipédia. 31-oct-2014.
[25] « Hameçonnage », Wikipédia. 31-oct-2014.
[26] « Cheval de Troie (informatique) », Wikipédia. 31-oct-2014.
[27] « keylogger : Enregistreur de frappe », Wikipédia. 23-oct-2014.
[28] « SPIT (informatique) : SPam over Internet Telephony », Wikipédia. 17-sept-2014.

Page 119 sur 145

[29] « Manipulation des cours de bourse : Pump and dump », Wikipedia, the free encyclopedia. 24-
oct-2014.
[30] « APT1 Exposing One of China’s Cyber Espionage Units », Mandiant. [En ligne]. Disponible sur:
http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf. [Consulté le: 31-oct-2014].
[31] « Révélations d’Edward Snowden », Wikipédia. 31-oct-2014.
[32] « Attaque de point d’eau », Wikipédia. 23-oct-2014.
[33] A. Sood et R. Enbody, Targeted Cyber Attacks: Multi-staged Attacks Driven by Exploits and
Malware. Syngress, 2014.
[34] « Host-based intrusion detection system - Wikipedia ». [En ligne]. Disponible sur:
https://en.wikipedia.org/wiki/Host-based_intrusion_detection_system. [Consulté le: 26-déc-
2016].
[35] « Système de prévention d’intrusion — Wikipédia ». [En ligne]. Disponible sur:
https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_pr%C3%A9vention_d’intrusion. [Consulté le:
26-déc-2016].
[36] « Open Web Application Security Project — Wikipédia ». [En ligne]. Disponible sur:
https://fr.wikipedia.org/wiki/Open_Web_Application_Security_Project. [Consulté le: 26-déc-
2016].
[37] « Zone démilitarisée (informatique) », Wikipédia. 15-nov-2014.
[38] « Pot de miel », Wikipédia. 15-nov-2014.
[39] « Les mécanismes de chiffrement ». [En ligne]. Disponible sur: http://www.linux-
france.org/prj/edu/archinet/systeme/ch23s02.html. [Consulté le: 18-juill-2016].
[40] « X.509 », Wikipédia. 07-nov-2014.
[41] « Expression rationnelle », Wikipédia. 15-nov-2014.
[42] ANSSI, « Recommandations de sécurité pour la mise en œuvre d’un système de
journalisation ». [En ligne]. Disponible sur:
http://www.ssi.gouv.fr/uploads/IMG/pdf/NP_Journalisation_NoteTech.pdf. [Consulté le: 25-
nov-2015].
[43] « Best Practices for Securing Active Directory ». [En ligne]. Disponible sur:
https://technet.microsoft.com/en-us/library/dn487446.aspx. [Consulté le: 04-juill-2016].

Page 120 sur 145

Glossaire

Page 121 sur 145

 Glossaire
 Appréciation des risques (risk assessment) : Sous-processus de la gestion des risques visant
à identifier, analyser et à évaluer les risques. (d'après [ISO Guide 73] – Appréciation du
risque : ensemble du processus d'identification des risques, d'analyse du risque et
d'évaluation du risque)

 Besoin de sécurité (sensitivity) : Définition précise et non ambiguë du niveau d'exigences

opérationnelles relatives à un bien essentiel pour un critère de sécurité donné (disponibilité,
confidentialité, intégrité…).
o Exemples :
 doit être disponible dans la journée ;
 ne doit être connu que du groupe projet ;
 peut ne pas être intègre dans la mesure où l'on peut le détecter et retrouver son
intégrité ;
 …

 Bien (asset) : Toute ressource qui a de la valeur pour l'organisme et qui est nécessaire à la
réalisation de ses objectifs. On distingue notamment les biens essentiels et les biens
supports. (d'après [ISO 27001] : tout élément représentant de la valeur pour l’organisme)
o Exemples :
 liste de noms ;
 requête de certification ;
 gestion de la facturation ;
 algorithme de chiffrement ;
 micro-ordinateur portable ;
 ethernet ;
 système d'exploitation ;
 …

 Bien essentiel (primary asset) : Information ou processus jugé comme important pour
l'organisme. On appréciera ses besoins de sécurité mais pas ses vulnérabilités.
o Exemples :
 une liste de noms ;
 passer une commande client ;
 gérer la facturation ;
 un algorithme de chiffrement ;
 …

Page 122 sur 145

 Bien support (supporting asset) : Bien sur lequel reposent des biens essentiels. On distingue
notamment les systèmes informatiques, les organisations et les locaux. On appréciera ses
vulnérabilités mais pas ses besoins de sécurité.
o Exemples :
 société d'infogérance ;
 locaux de l'organisme ;
 administrateur système ;
 micro-ordinateur portable ;
 Ethernet ;
 système d'exploitation ;
 portail de télé procédure ;
 …

 Confidentialité (confidentiality) : Propriété des biens essentiels de n'être accessibles qu'aux

personnes autorisés. (d'après [IGI 1300] : caractère réservé d'une information ou d’un
traitement dont l’accès est limité aux seules personnes admises à la (le) connaître pour les
besoins du service, ou aux entités ou processus autorisés)

 Critère de sécurité (security criteria) : Caractéristique d'un bien essentiel permettant

d'apprécier ses différents besoins de sécurité.
o Exemples :
 disponibilité,
 intégrité,
 confidentialité,
 -…

 Disponibilité (availability) : Propriété d'accessibilité au moment voulu des biens essentiels

par les personnes autorisées. (d'après [IGI 1300] : propriété d'une information ou d’un
traitement d'être, à la demande, utilisable par une personne ou un système)

 Établissement du contexte (context establishment) : Définition des paramètres externes et

internes à prendre en compte lors de la gestion des risques et définition du périmètre de
l'étude ainsi que des critères de gestion des risques. (d'après [ISO Guide 73] : définition des
paramètres externes et internes à prendre en compte lors du management du risque et
définition du domaine d'application ainsi que des critères de risque pour la politique de
management du risque)

 Événement lié à la sécurité de l’information (information security event) : occurrence

identifiée d’un état d’un système, d’un service ou d’un réseau, indiquant une brèche

Page 123 sur 145

 possible dans la politique de sécurité de l’information ou un échec des moyens de
protection, ou encore une situation inconnue jusqu’alors et pouvant relever de la sécurité
[ISO/CEI TR 18044:2004]

 Événement redouté (feared event) : Scénario générique représentant une situation crainte
par l'organisme. Il s'exprime par la combinaison des sources de menaces susceptibles d'en
être à l'origine, d'un bien essentiel, d'un critère de sécurité, du besoin de sécurité concerné
et des impacts potentiels.
o Exemples :
 une personne mal intentionnée (un journaliste, un concurrent…) parvient à obtenir le
budget prévisionnel de l'organisme, jugé confidentiel, et publie l'information dans les
médias ;
 …

 Gestion des risques (risk management) : Processus itératif de pilotage, visant à maintenir les
risques à un niveau acceptable pour l'organisme. La gestion des risques inclut typiquement
l'appréciation, le traitement, la validation du traitement et la communication relative aux
risques. (d'après [ISO Guide 73] – Processus de management du risque : application
systématique de politiques, procédures et pratiques de management aux activités de
communication, de concertation, d'établissement du contexte, ainsi qu'aux activités
d'identification, d'analyse, d'évaluation, de traitement, de surveillance et de revue des
risques)

 Gravité (consequences) : Estimation de la hauteur des effets d'un événement redouté ou

d'un risque. Elle représente ses conséquences. (d'après [ISO Guide 73] – Conséquence : effet
d'un événement affectant les objectifs)
o Exemples :
 négligeable : l'organisme surmontera les impacts sans aucune difficulté ;
 limitée : l'organisme surmontera les impacts malgré quelques difficultés ;
 importante : l'organisme surmontera les impacts avec de sérieuses difficultés ;
 critique : l'organisme ne surmontera pas les impacts (sa survie est menacée) ;
 …

 Impact (impact) : Conséquence directe ou indirecte de l'insatisfaction des besoins de

sécurité sur l'organisme et/ou sur son environnement.
o Exemples de types d'impacts :
 sur les missions ;
 sur la sécurité des personnes ;
 financiers ;

Page 124 sur 145

  juridiques ;
 sur l'image ;
 sur l'environnement ;
 …

 Incident lié à la sécurité de l’information (information security incident) : un incident lié à la

sécurité de l’information est indiqué par un ou plusieurs événement(s) de sécurité de
l’information indésirable(s) ou inattendu(s) présentant une probabilité forte de
compromettre les opérations liées à l’activité de l’organisme et de menacer la sécurité de
l’information [ISO/CEI TR 18044:2004]

 Information (information) : Tout renseignement ou tout élément de connaissance

susceptible d'être représenté sous une forme adaptée à une communication, un
enregistrement ou un traitement. [IGI 1300]
o Exemples :
 un message ;
 une liste de noms ;
 une requête de certification ;
 liste de révocation ;
 …

 Intégrité (integrity) : Propriété d'exactitude et de complétude des biens essentiels. (d'après

[IGI 1300] : propriété assurant qu’une information ou un traitement n'a pas été modifié ou
détruit de façon non autorisée)

 Menace (threat) : Moyen type utilisé par une source de menace.

o Exemples :
 vol de supports ou de documents ;
 piégeage du logiciel ;
 atteinte à la disponibilité du personnel ;
 écoute passive ;
 crue ;
 …

 Mesure de sécurité (control) : Moyen de traiter un risque de sécurité de l'information. La

nature et le niveau de détail de la description d'une mesure de sécurité peuvent être très
variables.

Page 125 sur 145

 Objectif de sécurité (security objective) : Expression de l'intention de contrer des menaces
ou des risques identifiés (selon le contexte) et/ou de satisfaire à des politiques de sécurité
organisationnelles et à des hypothèses ; un objectif peut porter sur le système-cible, sur son
environnement de développement ou sur son environnement opérationnel.
o Exemples :
 objectifs "ouverts" (grande marge de manœuvre pour couvrir l'objectif de sécurité) :
 les configurations des postes du réseau interne doivent être évolutives ;

 les locaux doivent être protégés contre la foudre ;

…

 objectifs "fermés" (faible marge de manœuvre pour couvrir l'objectif de sécurité) :

 le système doit identifier et authentifier de façon unique les utilisateurs, et ce, avant toute
interaction entre le système et l'utilisateur ;

 deux antivirus différents et compatibles doivent être mis en place et leurs bases de signatures
mises à jour toutes les deux semaines ;

…

 Organisme (organisation) : Ensemble d’installations et de personnes avec des

responsabilités, pouvoirs et relations. [ISO 9000]
o Exemples :
 entreprise ;
 département ministériel ;
 …

 Partie prenante (stakeholder) : Personne ou organisme susceptible d'affecter, d'être affecté

ou de se sentir lui-même affecté par une décision ou une activité. [ISO Guide 73]

 Prise de risques (risk retention) : Choix de traitement consistant à accepter les

conséquences de la réalisation de tout ou partie de risques, sans appliquer de mesure de
sécurité. (d'après [ISO Guide 73] – Prise de risque : acceptation de l'avantage potentiel d'un
gain ou de la charge potentielle d'une perte découlant d'un risque particulier)

 Processus de l'organisme (business process) : Ensemble organisé d’activités qui utilisent des
ressources pour transformer des entrées en sorties. [ISO 9000]

 Processus informationnel (information process) : Ensemble organisé de traitements qui

utilisent des biens supports pour transformer des informations d'entrées en informations de
sorties (d'après [ISO 9000]).

Page 126 sur 145

 Réduction de risques (risk reduction) : Choix de traitement consistant à appliquer des
mesures de sécurité destinées à réduire les risques.
o Exemples :
 élaborer une politique de sécurité de l'information ;
 mettre en œuvre un antivirus qui devra régulièrement être mis à jour ;
 sensibiliser les personnels aux risques ;
 …

 Refus de risques (risk avoidance) : Choix de traitement consistant à éviter les situations à
risque. (d'après [ISO Guide 73] – Refus du risque : décision argumentée de ne pas s'engager
dans une activité, ou de s'en retirer, afin de ne pas être exposé à un risque particulier)
o Exemples :
 changement de lieu d'implantation des locaux ;
 réduction des ambitions d'un projet ;
 arrêt d'un service ;
 …

 Risque résiduel (residual risk) : Risque subsistant après le traitement du risque. [ISO Guide
73]

 Risque de sécurité de l'information (information security risk) : Scénario, avec un niveau

donné, combinant un événement redouté et un ou plusieurs scénarios de menaces. Son
niveau correspond à l'estimation de sa gravité et de sa vraisemblance. (d'après [ISO Guide
73] : effet de l'incertitude sur l'atteinte des objectifs. […] NOTE 3 – Un risque est souvent
caractérisé en référence à des événements et des conséquences potentiels ou à une
combinaison des deux. NOTE 4 – Un risque est souvent exprimé en termes de combinaison
des conséquences d'un événement et de sa vraisemblance)

 Scénario de menace (vector) : Scénario, avec un niveau donné, décrivant des modes
opératoires. Il combine les sources de menaces susceptibles d'en être à l'origine, un bien
support, un critère de sécurité, des menaces et les vulnérabilités exploitables pour qu'elles
se réalisent. Son niveau correspond à l'estimation de sa vraisemblance.
o Exemples :
 vol de supports ou de documents du fait de la facilité de pénétrer dans les locaux ;
 piégeage du logiciel du fait de la naïveté des utilisateurs ;
 inondation due au fait que les bâtiments sont inondables ;
 …

Page 127 sur 145

 Sécurité de l'information (information security) : Satisfaction des besoins de sécurité des
biens essentiels par la protection de la confidentialité, de l’intégrité et de la disponibilité de
l’information; en outre, d’autres propriétés, telles que l’authenticité, l’imputabilité, la non-
répudiation et la fiabilité, peuvent également être concernées.

 Source de menace (threat source) : Chose ou personne à l'origine de menaces. Elle peut être
caractérisée par son type (humain ou environnemental), par sa cause (aCCIdentelle ou
délibérée) et selon le cas par ses ressources disponibles, son expertise, sa motivation…
(d'après [ISO Guide 73] – Source de risque : tout élément qui, seul ou combiné à d'autres,
présente un potentiel intrinsèque d'engendrer un risque)
o Exemples :
 ancien membre du personnel ayant peu de compétences techniques et de temps
mais susceptible d'avoir une forte motivation ;
 pirate avec de fortes compétences techniques, bien équipé et une forte motivation
liée à l'argent qu'il peut gagner ;
 climat très fortement pluvieux pendant trois mois par an ;
 virus ;
 utilisateurs ;
 …

 Système d'information (information system) : Ensemble des moyens humains et matériels

ayant pour finalité d'élaborer, traiter, stocker, acheminer, présenter ou détruire
l'information. [IGI 1300]

 Traitement des risques (risk treatment) : Sous-processus de la gestion des risques

permettant de choisir et de mettre en œuvre des mesures de sécurité visant à modifier les
risques de sécurité de l'information. (d'après [ISO Guide 73] – Traitement du risque :
processus destiné à modifier un risque)

 Transfert de risques (risk transfer) : Choix de traitement consistant à partager les pertes
consécutives à la réalisation de risques. (d'après [ISO Guide 73] – Partage du risque : forme
de traitement du risque impliquant la répartition consentie du risque avec d'autres parties)
o Exemples :
 recours à une assurance ;
 emploi de produits certifiés ;
 …

 Validation du traitement des risques (risk acceptance) : Sous-processus de la gestion des

risques visant à décider d'accepter la manière dont les risques ont été traités ainsi que les

Page 128 sur 145

 risques résiduels à l'issue du traitement des risques. (d'après [ISO Guide 73] – Acceptation
du risque : décision argumentée en faveur de la prise d'un risque particulier)

 Vraisemblance (likelihood) : Estimation de la possibilité qu'un scénario de menace ou un

risque, se produise. Elle représente sa force d'occurrence. (d'après [ISO Guide 73] :
possibilité que quelque chose se produise)
o Exemples :
 minime : cela ne devrait pas se (re)produire ;
 forte : cela pourrait se (re)produire ;
 significative : cela devrait se (re)produire un jour ou l'autre ;
 maximale : cela va certainement se (re)produire prochainement ;
 …

 Vulnérabilité (vulnerability) : Caractéristique d'un bien support qui peut constituer une
faiblesse ou une faille au regard de la sécurité des systèmes d'information. (d'après [ISO
Guide 73] : propriétés intrinsèques de quelque chose entraînant une sensibilité à une source
de risque pouvant induire une conséquence)
o Exemples :
 crédulité du personnel ;
 facilité de pénétrer sur un site ;
 possibilité de créer ou modifier des commandes systèmes ;
 …

Page 129 sur 145

Liste des abréviations

Page 130 sur 145

 Liste des abréviations

AC Autorité de Certification ou « Certifying Authority »

ANSSI Agence Nationale de la Sécurité des Systèmes d'Information
AP Access Point
AQSSI Autorité Qualifiée de Sécurité des Systèmes d'Information
ARP Address Resolution Protocol ou « Protocole de résolution d’adresse »
BIOS Basic Input Output System
BPS Business Process Services
CA Certifying Authority ou « Autorité de Certification»
CCTP Cahier des Clauses Techniques Particulières
CNAM Conservatoire National des Arts et Métiers
DLP Data Leakage Protection
DMZ DeMilitarized Zone
DNS Domain Name System ou « Système de noms de domaine »
DRHAT Direction des Ressources Humaines de l’Armée de Terre
EAP Extensible Authentification Protocol
EBIOS Expression des Besoins et Identification des Objectifs de Sécurité
EICNAM Ecole d’Ingénieur du CNAM
ESN Entreprise de Services Numériques
GED Gestion Électronique des Documents
GSM Global System for Mobile
GT Groupe de Travail
Host Intrusion Détection System ou « Système de détection d'intrusion
HIDS
machine »
HTTP HyperText Transfer Protocol
IaaS Infrastructure As A Service ou « Infrastructure en tant que service »
IAEA International Atomic Energy Agency
IAM Identity and Access Management
IDS, Intrusion détection System
IP Internet Protocol ou « protocole internet »
IPS Intrusion Prevention System ou « système de prévention d'intrusion »
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
LAB LABoratoire
LDAP Lightweight Directory Access Protocol SSO
LOC LOCaux
LOG LOGiciel
MAC Media Access Control ou « contrôle d'accès au support »
MAT MATériel
MCO Maintien en Condition Opérationnelle
MCS Maintien en Condition de Sécurité
MEHARI Méthode Harmonisée d'Analyse des RIsques
Misc Multi-System & Internet Security Cookbook
MOI Maitre d'Œuvre Industriel

Page 131 sur 145

NAT Network Address Translation,
NSA National Security Agency ou « Agence nationale de la sécurité » (US)
OIV Opérateurs d’Importance Vitale
ORG ORanisation
OTP One Time Password
OWASP Open Web Application Security Project
PaaS Platform As A Service ou « Plate-forme en tant que service »
PAP PAPier
PCA Plan de Continuité d’Activité
PGP Pretty Good Privacy
PKI Public Key Infrastructure
PKI Public Key Infrastructure
PRA Plan de Reprise d’Activité
PSSI Politique de Sécurité des systèmes d’Information
Radius Remote Authentication Dial-In User Service
RAID Redundant Array of Inexpensive Disks
RGS Référentiel Général de Sécurité
RSA Rivest, Shamir, Adleman
RSX RéSeauX
RVP Réseau Virtuel Privé ou « Virtual Private Network »
SaaS Software As A Service ou « Logiciel en tant que service »
SI Système d’Information
SIA Système d’Information des Armées
SIC Système d’Information et de Communication
SIEM Security Information and Event Management
SIOC SI Opérationnels et de Commandement
SMTP Simple Mail Transfer Protocol
SOC Security Operating Center
SPIT SPam over Internet Telephony
SQL Structured Query Language ou « langage de requête structurée »
SRP Secure Remote Passwords
SSD Solid-State Drive
SSI Sécurité des Systèmes d’Information
SSL Secure Sockets Layer
Transmission Control Protocol ou « protocole de contrôle de
TCP
transmissions »
TLS Transport Layer Security
VPN Virtual Private Network ou « Réseau Virtuel Privé »
WEB Le WEB s’emploie aujourd’hui lorsque l’on parle du WWW
WWW World Wide Web ou la « toile (d'araignée) mondiale »
XSS cross-site scripting

Page 132 sur 145

Table des annexes

Page 133 sur 145

 Table de annexes
Annexe 1 - Recommandations de sécurité pour la mise
en œuvre d’un système de journalisation N°DAT-NT-
012/ANSSI/SDE/NP
# Description originale
Utiliser des systèmes et des applicatifs disposants d’une fonctionnalité de journalisation est
R1 primordial. La prise en compte de cette fonction doit se faire lors de toute démarche de
conception et de développement.
L’horodatage doit être activé pour l’ensemble des événements afin de permettre une
R2
meilleure exploitation des journaux.
Les horloges des équipements doivent être synchronisées sur plusieurs sources de temps
R3 internes cohérentes entre elles. Ces sources pourront elles-mêmes être synchronisées sur
plusieurs sources fiables externes, sauf pour les réseaux isolés.
Lors du dimensionnement des équipements, l’estimation de l’espace de stockage nécessaire à
R4
la conservation locale des journaux est indispensable.
Les journaux doivent être automatiquement exportés sur une machine physique différente de
R5
celle qui les a générés.

Les journaux de l’ensemble des équipements du système d’information doivent être

R6
transférés su un ou plusieurs serveurs centraux dédiés.

Si le parc d’équipements qui génère des journaux est important, le serveur central devra être
R7
redondé afin d’accroitre la disponibilité du service de collecte de journaux.
Si la taille ou la typologie du système d’information le nécessite, une approche hiérarchique
R8
pour l’organisation des serveurs de collecte doit être retenue.
Si le contexte le permet, un transfert en temps réel des journaux sur les serveurs centraux soit
R9
être privilégié.
R10 Il est recommandé de ne pas effectuer de traitement sur les journaux avant leur transfert.
Il est recommandé d’utiliser des protocoles d’envoi de journaux basés sur TCP pour fiabiliser le
R11
transfert de données entre les machines émettrices et les serveurs centraux.
Il est recommandé d’utiliser des protocoles de transfert de journaux qui s’appuient sur des
R12 mécanismes cryptographiques robustes en particulier lorsque les données transitent sur des
réseaux non maitrisés.
Il est recommandé de bien contrôler la bande passante des flux réseau utilisée pour transférer
R13
les journaux d’événements.
Lorsque le besoin de sécurité pour le transfert des journaux est important, il doit se faire sur
R14
un réseau d’administration dédié.
S’il n’existe pas de réseaux d’administration dans l’architecture pour accueillir les serveurs de
R15 journalisation, ils doivent être placés dans une zone interne non exposée directement à des
réseaux qui ne sont pas de confiance (par exemple internet).

Page 134 sur 145

 # Description originale

Une partition disque doit être dédiée au stockage des journaux d’évènements sur les
R16
équipements qui les génèrent ou qui les centralisent.

R17 Il est recommandé d’adopter une arborescence pour le stockage des journaux d’événements.
Une politique de rotation des journaux d’événements doit être formalisée et mise en œuvre
R18
sur l’ensemble des équipements du système de journalisation.
La durée de conservation des fichiers de journaux étant soumises à des contraintes légales et
R19 réglementaires, il convient d’en prendre connaissance pour définir les moyens techniques
nécessaire à l’archivage des journaux.
L’accès aux journaux doit être limité en écriture à un nombre restreint de comptes ayant le
R20
besoin d’en connaitre.
Les processus de journalisation et de collecte doivent être exécutés par des comptes
R21
disposant de peu de privilèges.
Un outil spécifique doit être utilisé pour une meilleure exploration des journaux présents sur
R22
les serveurs centraux, la détection d’évènements anormaux en sera facilitée.
Les comptes ayant accès à l’outil de consultation centralisée des journaux doivent être
R23
associés à des rôles prédéterminés.
R24 L’espace disque des équipements qui génèrent et stockent les journaux doit être supervisé.

Page 135 sur 145

 Annexe 2 - Menaces standards EBIOS:2010

MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS

Copie d'informations sensibles sur des

supports amovibles (cf. clés USB, CD/DVD,
etc.) non prévus pour cet usage / utilisation
Mauvais usage (intentionnel
M1 MAT-USG de la puissance CPU d'un serveur pour casser
ou non) d'un matériel
des mots de passe / saturation d'un espace
de stockage par des fichiers à finalité non-
professionnelle (cf. DivX, MP3, etc.) / …
Observation d'un écran, analyse
d'émanations électromagnétiques telles que
des signaux parasites
compromettants issus de l'affichage ou des
touches du clavier, attaque par perturbation
telle qu'un changement rapide de la tension
d'alimentation ou au laser, géolocalisation
M2 MAT-ESP Espionnage d'un matériel d'un matériel (à partir de son adresse IP ou
par le réseau
téléphonique), extraction de données par
refroidissement brutal (cold boot),
interception de signaux
compromettants (via des tuyaux ou des
câbles de fourniture de ressources, en
utilisant une antenne d'interception…).
Déni de service (DoS/DDoS) sur interfaces
réseaux / surallocation de VM sur un ou
plusieurs serveurs de la ferme
Saturation des capacités de (RAM/CPU/Disques durs) / surutilisation
M3 MAT-DEP traitement/stockage/communi d'un serveur dédié (RAM/CPU/Disques durs)
cation d'un matériel / sous-capacité des bandes de sauvegarde
pour les données à sauvegarder / Coupure
d'alimentation électrique / dégradation de
l'environnement (cf. T° trop élevée, etc.) / …
Projections d'eau (cf. fuite de canalisation ou
de climatisation, système anti-incendie à
Panne ou destruction
eau, etc.) sur des composants électroniques
M4 MAT-DET (provoquée ou non) d'un
/ source de chaleur les faisant fondre (cf.
matériel
incendie) / vandalisme intentionnel ou non /
…
Installation d'équipements malicieux (cf.
Piégeage physique ou keylogger hardware, point d'accès réseau
M5 MAT-MOD évolution hardware non pirate) / installation licite de composants
maîtrisée d'un matériel incompatibles (cf. upgrade
RAM/CPU/contrôleurs stockage/etc.) / …

Page 136 sur 145

MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS

Perte d'un poste portable ou d'un support

amovible (cf. taxi, gares, aéroports,
restaurants, transports en commun, etc.) /
vol d'un poste portable ou d'un support
amovible (cf. lieux publics, transports en
M6 MAT-PTE Perte ou vol d'un matériel commun, etc.) / vol d'un matériel ou de
composants d'un matériel dans le Data
centre (cf. serveur, équipement réseau,
RAM, disque dur, etc.) / mise au rebut ou
don de matériel considéré comme obsolète /
…
Défiguration d'un site Web, copie
inappropriée de données sensibles (cf. base
de données, partage réseau, GED, etc.) /
modification ou suppression inappropriée de
données sensibles métiers (base de données,
partage réseau, etc.) ou de traces (base
Mauvais usage (intentionnel centralisée, répertoire local, etc.) / fuite de
M7 LOG-USG ou non) d'une application / données sensibles (cf. mail, Webmail, IM,
d'un service système ou réseau blog, peer2peer, ftp, etc.) / altération
accidentelle ou malicieuse de la
configuration d'une application ou d'un
système sur un serveur ou un équipement
réseau (cf. gestion des profils et des droits,
gestion des traces, gestion des
communications, etc.) / …
Analyse du code source d'une application
Analyse passive d'une pour identifier des vulnérabilités / scan
M8 LOG-ESP application / d'un service d'adresses IP pour cartographier un réseau /
système ou réseau scan de ports sur des serveurs pour identifier
les services actifs / …

DoS/DDoS au niveau applicatif / fuzzing (cf.

Saturation ou détournement
SQL injection, XSS ou Cross Site Scripting,
M9 LOG-DEP malicieux d'une application /
etc.) / buffer overflow / boucle infinie dans
d'un service système ou réseau
un programme / …

Effacement d'exécutables ou de librairies en

environnement de production / effacement
Suppression (intentionnelle ou
d'une version du code source de
M10 LOG-DET non, partielle ou complète)
programmes en environnement de
d'un logiciel
développement / …, que ce soit par erreur
ou non, par une action humaine ou non (cf.

Page 137 sur 145

MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS

virus, bombe logique, etc.)

Mise en œuvre en environnement de

production d'un patch, d'une mise à jour,
d'une règle sur le domaine, etc. malicieuse
ou buggée / piégeage logiciel d'un système
Modification (intentionnelle
(cf. keylogger, troyan, backdoor, etc.) / virus
M11 LOG-MOD ou non) d'une application /
ou vers se propageant à l'aide d'un logiciel
d'un service système ou réseau
tiers (cf. client mail, client web, IM, client ftp,
SGBD, etc.) ou se greffant à un fichier d'un
logiciel tiers (cf. mail, page web, document,
image, exécutable, etc.) / …
Expiration de licences d'utilisation (cf. OS,
Perte de propriété ou de droit middleware, outil de développement,
M12 LOG-PTE
d'usage d'un logiciel d'administration, de supervision, de
chiffrement, de signature, etc.)
attaque de type "Man in the Middle" par
interception des flux réseaux (avec
usurpation d'identité au niveau réseau /
redirection des flux par corruption de la
Attaque réseau active (par
M13 RSX-USG commutation, du routage, du service DNS,
usurpation ou détournement)
etc.) / attaque par rejeu de flux sur un
service réseau (cf. numéros de séquence
TCP, etc.) / connexion "pirate" sur un réseau
filaire ou non-filaire / …)
attaque par sniffing d'un brin réseau (cf.
Attaque par écoute passive du carte réseau en mode promiscuous) /
M14 RSX-ESP
réseau attaque par port-mirroring sur un
équipement réseau (cf. sonde réseau) / …
DoS/DDoS au niveau réseau / boucle
Saturation (intentionnelle ou
M15 RSX-DEP Ethernet ou boucle de routage / application
non) du réseau
de niveaux de QoS inadaptés / …
Sectionnement ou coupure accidentelle (cf.
Dégradation (intentionnelle ou "coup de pelleteuse" sur la voie publique)
M16 RSX-DET non) de l'infrastructure d'un câble réseau / torsion ou courbure trop
physique du réseau serrée d'une fibre optique / faux-contact
dans une paire torsadée à nu / …

Page 138 sur 145

MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS

Modification (intentionnelle
Câble de catégorie insuffisante pour la
M17 RSX-MOD ou non) de l'infrastructure
distance et/ou le débit utilisés / …
physique du réseau

Disparition d'un canal

M18 RSX-PTE Vol de câbles de transmission.
informatique ou de téléphonie
Les ressources de la personne sont
Entrave à l'activité employées à faire autre chose que ce qu'elle
M19 PER-USG professionnelle d'une devrait faire, sans la faire changer ni
personne l'affecter physiquement. Ses performances
peuvent ainsi être diminuées.
Observation ou écoute d'une personne, avec
ou sans équipement d'amplification
M20 PER-ESP Espionnage d'une personne sensorielle ou de capture, depuis l'intérieur
ou l'extérieur des locaux, sans être affectée
physiquement.
Les capacités (compétences, ressources,
capacités physiques ou psychologiques) de la
M21 PER-DEP Surmenage d'une personne personne sont dépassées. Elle peut ainsi ne
plus agir correctement et ses performances
peuvent diminuer.
La personne est affectée physiquement ou
psychologiquement, partiellement ou
totalement, temporairement ou
Atteinte à l'intégrité physique
M22 PER-DET définitivement, à l'intérieur ou à l'extérieur
d'une personne
des locaux. Elle peut ainsi exercer sa fonction
de manière moins performante, voire ne
plus pouvoir exercer sa fonction.
Les conditions d'exercice du libre arbitre de
la personne sont modifiées, à l'intérieur ou à
M23 PER-MOD Manipulation d'une personne l'extérieur des locaux. Elle peut ainsi être
amenée à agir de manière inopportune ou à
divulguer des informations.
La personne est perdue pour l'organisme,
sans être affectée. Son savoir et son savoir-
M24 PER-PTE Départ d'une personne
faire ne sont plus disponibles pour
l'organisme mais le deviennent pour autrui.
Détournement de l’usage
M25 PAP-USG Non retenue dans le cadre de la mission
prévu d'un support papier
Espionnage d'un support Non retenue dans le cadre de la mission
M26 PAP-ESP
papier

Page 139 sur 145

MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS

Détérioration d'un support Non retenue dans le cadre de la mission

M27 PAP-DET
papier
M28 PAP-PTE Perte d'un support papier Non retenue dans le cadre de la mission
Manipulation via un canal Non retenue dans le cadre de la mission
M29 CAN-USG
interpersonnel
Espionnage d'un canal Non retenue dans le cadre de la mission
M30 CAN-ESP
interpersonnel
Saturation d'un canal Non retenue dans le cadre de la mission
M31 CAN-DEP
interpersonnel
Dégradation d'un canal Non retenue dans le cadre de la mission
M32 CAN-DET
interpersonnel
Modification d'un canal Non retenue dans le cadre de la mission
M33 CAN-MOD
interpersonnel
Disparition d'un canal Non retenue dans le cadre de la mission
M34 CAN-PTE
interpersonnel

Page 140 sur 145

Liste des figures

Page 141 sur 145

 Liste des figures
Figure 1 : Part des offres dans le Chiffre d’Affaires Sopra Steria ............................................................ 8
Figure 2 : Répartition des activités du groupe dans les différents domaines du marché des ESN ......... 9
Figure 3 : Répartition des collaborateurs et du chiffre d’affaires sur le Monde ................................... 10
Figure 4 : Les trois grandes responsabilités du RSSI.............................................................................. 20
Figure 5 : Un programme infecté. ......................................................................................................... 32
Figure 6 : L'usurpation d'adresse IP....................................................................................................... 36
Figure 7 : La portée de la sécurité VS Les ressources nécessaires. ....................................................... 78
Figure 8 : Tunnel IPSEC .......................................................................................................................... 87
Figure 9 : Relais SMTP ........................................................................................................................... 88
Figure 10 : Le fonctionnement d'un pare-feu. ...................................................................................... 89
Figure 11 : Chiffrement symétrique ...................................................................................................... 93
Figure 12 : Matrice des risques bruts .................................................................................................. 108
Figure 13 : Matrice des risques résiduels ............................................................................................ 109
Figure 14 : Matrice des risques nets ................................................................................................... 114

Page 142 sur 145

Liste des tableaux

Page 143 sur 145

 Liste des tableaux
Tableau 1 : Construction du mémoire ................................................................................................... 12
Tableau 2 : RACI de l’analyse de risques ............................................................................................... 23
Tableau 3 : Typologie de l'attaquant..................................................................................................... 27
Tableau 4 : Sources de menaces considérées pour l’analyse de risque ................................................. 29
Tableau 5 : Critères de sécurité retenus pour l’étude ............................................................................ 43
Tableau 6 : Échelle de disponibilité retenue pour l’étude...................................................................... 44
Tableau 7 : Échelle d’intégrité retenue pour l’étude ............................................................................. 45
Tableau 8 : Échelle de confidentialité retenue pour l’étude .................................................................. 46
Tableau 9 : Échelle de gravité retenue pour l’étude .............................................................................. 48
Tableau 10 : Échelle de vraisemblance retenue pour l’étude ................................................................ 49
Tableau 11 : Critères de gestion des risques retenus pour l’étude ........................................................ 51
Tableau 12 : Matrice de criticité des risques ......................................................................................... 51
Tableau 13 : Stratégie de gestion du risque .......................................................................................... 52
Tableau 14 : Liste des biens essentiels considérés pour l’étude ............................................................ 53
Tableau 15 : Liste des biens essentiels considérés pour l’étude ............................................................ 54
Tableau 16 : Liste des biens supports considérés pour l’étude .............................................................. 56
Tableau 17 : Événements redoutés ....................................................................................................... 64
Tableau 18 : Événements redoutés par gravité ..................................................................................... 65
Tableau 19 : Scénarios de menaces ....................................................................................................... 71
Tableau 20 : Risques .............................................................................................................................. 77
Tableau 21 : Mesures de sécurité complémentaires ........................................................................... 102
Tableau 22 : Risques résiduels ............................................................................................................. 107
Tableau 23 : Évènements Windows relatifs à l’effacement des logs .................................................. 111
Tableau 24 : Évènements Windows relatifs à l’usage des comptes .................................................... 111

Page 144 sur 145

Mission d’analyse des risques, donner une vision globale des risques de sécurité pesant
sur une application et proposer des mesures de couvertures des risques identifiés.

Mémoire d'Ingénieur C.N.A.M., Paris 2017

_________________________________________________________________

RESUME

L’objectif de la mission est de réaliser l’analyse de risques d’un projet d’application de gestion de
Contrats Immobiliers, commandé par l’état français. Les informations sensibles ont été soit
modifiées, soit supprimées afin que le mémoire puisse être publié à la connaissance de tous.
L’objectif premier de l’étude est de donner une vision globale des risques de sécurité pesant sur
l’application et de proposer des mesures de couvertures pour les principaux risques identifiés.
L’analyse de risques a été réalisée en s’inspirant de la méthode d’analyse de risque de l’ANSSI
EBIOS:2010. Le second objectif de l’analyse de risque est de contribuer à l’homologation de
l’application suivant le RGS (Référentiel Général de Sécurité).

Mots clés : Sécurité, analyse de risques, menaces, cybersécurité, cyberdéfense, vulnérabilités,

management du risque, système de management de la sécurité.

_________________________________________________________________

SUMMARY

The objective of the mission is to carry out the risk analysis of a property management application
project commissioned by the French State. Sensitive information has been cleaned so it can be
published to everyone. The primary objective of the study is to provide a global view of the security
risks who threat the application and to propose hedging measures for the main identified risks. The
risk analysis was carried out on the basis of ANSSI's risk analysis methodology EBIOS: 2010. The
second objective of the risk analysis is to contribute to the registration of the application compliancy
to the French RGS (General Security Repository).

Key words : Security, risks analysis, threats, cybersecurity, cyberdefence, vulnerabilities, risk
management, information security management system.

Page 145 sur 145