conservatoire national des arts et metiers paris memoire
TRANSCRIPT
Page 1 sur 145
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 2 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 3 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 4 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 5 sur 145
Introduction
Page 6 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 7 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 8 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 9 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 10 sur 145
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.
Figure 3 : Répartition des collaborateurs et du chiffre d’affaires sur le Monde
Page 11 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 12 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 13 sur 145
Problématique générale
Page 14 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 15 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 16 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 17 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 18 sur 145
Analyse des besoins
Page 19 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 20 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.
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.
Prévention Détection Réaction
Page 21 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 22 sur 145
Réalisation de la mission
Page 23 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 :
Activités EBIOS
Le C
om
man
dit
aire
Le R
éal
isat
eu
r
Re
pré
sen
tan
ts
mé
tie
rs/u
tilis
ate
urs
Re
spo
nsa
ble
s b
ien
s
sup
po
rts/
me
sure
s d
e s
écu
rité
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
Activité 5.2 – Mettre en œuvre les mesures de sécurité Hors scope de l’analyse de risque mais un exemple est
donné en §17
Tableau 2 : RACI de l’analyse de risques
Page 24 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 25 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 26 sur 145
Attaquants Ressources Temps Outils Motivation
Tableau 1 Menaces internes
Agent secret
Dispose de ressources, élevées Pratique une ingénierie sociale facilitée A accès au système jusqu'à un certain niveau Dispose de la documentation du système et d'un centre d'expertise
Variable, mais généralement le temps consacré ne pourra pas se quantifier en heures
Dispose d'accès existants, à la connaissance des architectures, des programmes et du système Connaissance possible d'identifiants (Couple login / Mots de passe) A la possibilité d'insérer des portes dérobées et / ou des chevaux de Troie (spécifiquement conçus) A la possibilité de soutien de la part d'experts extérieurs
Le vol d'informations commerciales, de secrets de la technologie, d'informations sur le personnels Gain économique (informations à vendre à des concurrents) Chantage
Employé / Utilisateur mécontent
Dispose de ressources, moyennes à élevées A accès au système jusqu'à un certain niveau Dispose de la documentation du système et pour certains d'une expertise sur les affaires et les opérations systèmes
Variable, mais généralement le temps consacré ne pourra pas se quantifier en heures
Dispose d'accès existants, à la connaissance des architectures de programmation et du système Connaissance possible des mots de passe existant Possibilité d'insérer des outils ou scripts préconçus (potentiellement des outils plus élaborés si compétences informatique spécifiques)
Revanche, le chaos Le vol d'informations commerciales Embarrasser l'employeur / Embarrasser d'autres employés Dégrader l'image publique, altérer la confiance
Tableau 2 Menaces externes
Pirate récréatif
Compétences variables mais généralement limitées Peu de connaissance du système en dehors de l'information du public
Beaucoup de temps mais pas très patient Dispose généralement de scripts et d'outils Certains développent leurs propres outils
Un statut fun L'opportunité Des exploitations faciles
Militants divers
Les ressources sont limitées mais peuvent être soutenus financièrement par des canaux secrets Accès aux outils de la cybercommunauté Peu de connaissances du système en dehors de l'information du public
Les attaques peuvent être ciblées sur certains événements (fêtes, élections, déplacements de VIP, déplacements de matériaux…)
Les compétences informatiques sont disponibles Le soutien éventuel d'une communauté de pirates Ingénierie sociale
Pensent être chargés d'une mission dont la cause est supérieure Influencer l'opinion publique sur des questions spécifiques Entraver les opérations d'affaires
Page 27 sur 145
Attaquants Ressources Temps Outils Motivation
Ancien employé / Utilisateur
mécontents
Des ressources limitées si non engagé au sein d'un grand groupe de personnes Possède encore le système de documentation Peut utiliser son ancien accès si la gestion des habilitations est mal gérée
Variable et dépend d'une association à un groupe de personnes
La connaissance possible des mots de passe existant Peut utiliser d'anciens accès si la gestion des habilitations est mal gérée Peut avoir créé ou mis en place un système de porte dérobée Ingénierie sociale
Revanche, le chaos Le vol d'informations commerciales Embarrasser l'employeur / Embarrasser d'autres employés Dégrader l'image publique, altérer la confiance
Crime organisé
Ressources élevées Emploi d'experts
Variable mais principalement du court terme
Scripts, outils Peut employer des pirates Peut employer d'anciens / ou d'actuels employés Ingénierie sociale
Chantage, extorsion (gain financier), vol Joue sur les finances, la perception et les craintes dans les affaires Information pour la vente (techniques, commerciale ou personnelles)
États
Ressources élevées et expertise élevée Activités de collecte de renseignement Possibilité de formation / D'exploitation et expérience sur le système
Variable Des équipes formées, des cybers experts Des outils sophistiqués Peuvent employer d'anciens ou d'actuels salariés
La construction d'accès pour des actions ultérieures Vol de technologies
Terroristes Compétences variables Possibilité de formation / d'exploitation, expérience sur le système
Beaucoup de temps, très patient
Scripts, outils Peut employer des pirates informatique à louer Peut employer d'anciens / ou d'actuels employés Ingénierie sociale
La collecte du renseignement La construction d'accès pour des actions postérieures Chaos Vengeance Opinion publique d'impact (crainte)
Tableau 3 : Typologie de l'attaquant
Page 28 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
Humaines & malveillantes
1 Interne, malveillante, avec de faibles capacités
Oui Personnel interne avec des droits utilisateurs simples ou sans droits particuliers sur l’application, personnel du data centre sans droits physiques et logiques sur les équipements
2 Interne, malveillante, avec des capacités importantes
Oui
Exploitants, développeurs, personnel interne avec des droits élevés dans l'application, équipe support, personnel du data centre avec des droits physiques et /ou logiques sur les équipements, équipe interne support flux
3 Interne, malveillante, avec des capacités illimitées
Oui Administrateur technique interne
4 Externe, malveillante, avec de faibles capacités
Oui Utilisateurs de l’application avec des droits standards, autres utilisateurs du réseau, utilisateurs des applications satellites
5 Externe, malveillante, avec des capacités importantes
Oui Hackers, utilisateurs avec des droits élevés (ex : valideurs, …), concurrent d'un autre client du data centre.
6 Externe, malveillante, avec des capacités illimitées
Oui Gouvernement étranger, terroristes, groupes mafieux.
Humaines & accidentelles
7 Interne, sans intention de nuire, avec de faibles capacités
Oui Personnels du data centre non affectés à l'environnement L’application (intervention sur clim/courant secouru/arrivées télécom/…).
8 Interne, sans intention de nuire, avec des capacités importantes
Oui
Exploitants, développeurs, personnel interne avec des droits élevés dans l'application, équipe support, sous-traitant du data centre avec des droits physiques et ou logiques sur les équipements, équipe interne support flux, auditeurs commandités
9 Interne, sans intention de nuire, avec des capacités illimitées
Oui Administrateur technique
10 Externe, sans intention de nuire, avec de faibles capacités
Oui Utilisateurs de l’application avec des droits standards
11 Externe, sans intention de nuire, avec des capacités importantes
Oui Utilisateur de l’application avec des droits élevés, auditeurs tiers commandité, l'hébergeur (ex : entreprise réalisant des travaux dans la zone du data centre…).
Page 29 sur 145
Type N° Sources de menaces Sélection Dénomination / justification si non retenue
12 Externe, sans intention de nuire, avec des capacités illimitées
Non Non exposé à ce type de menace (activité industrielles susceptibles de provoquer des sinistres majeurs, explosions dans le voisinage…)
Non humaines
13 Code malveillant d'origine inconnue
Oui Malware non ciblé
14 Phénomène naturel Oui Usure naturelle, phénomènes météorologiques ou climatiques imprévisibles mais récurrents : foudre, canicule, tempête…
15 Catastrophe naturelle ou sanitaire
Oui Le data centre de Vauban est situé dans une zone inondable
16 Activité animale Non Non exposé à ce type de menace. (rongeurs, animaux dangereux pour l'homme)
17 Événement interne Oui Incendie, inondation due à une rupture de canalisation, problème de climatisation, grève, défaillance technique, accident d'une personne…
Tableau 4 : Sources de menaces considérées pour l’analyse de risque
Page 30 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 31 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 32 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 33 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 34 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 35 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 36 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 37 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 38 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 39 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 40 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 41 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 42 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 43 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.
Confidentialité Propriété des biens essentiels de n'être accessibles qu'aux utilisateurs
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 44 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
l'échelle Description détaillée de l'échelle Description orientée Entreprise/organisme utilisateur
Aucun ou
Faible (D1)
Le bien essentiel a un délai
maximal d’interruption autorisée
entre une semaine et un mois.
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller d'une semaine à
un mois avant d'impacter plus ou moins faiblement un
service, une direction ou un organisme utilisateur.
Moyen (D2)
Le bien essentiel a un délai
maximal d’interruption autorisée
de 3 à 5 jours consécutifs ouvrés.
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller de 3 à 5 jours
consécutifs ouvrés avant d'impacter plus ou moins
modérément un service, une direction ou un organisme
utilisateur avec a minima 1 type d'impact de gravité
"modérée".
Critique (D3)
Le bien essentiel a un délai
maximal d’interruption autorisée
de 1 à 2 jours consécutifs ouvrés.
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller de 1 à 2 jours
consécutifs ouvrés avant d'impacter plus ou moins
significativement un service, une direction ou un
organisme utilisateur avec a minima 1 type d'impact de
gravité "significative".
Majeur (D4)
Le bien essentiel a un délai
maximal d’interruption autorisée
d’une journée (8 heures).
Le service fournit dispose d'un délai maximal
d’interruption tolérable pouvant aller jusqu'à une
journée (8 heures) avant d'impacter plus ou moins
gravement un service, une direction ou un organisme
utilisateur avec a minima 1 type d'impact de gravité
"grave".
Tableau 6 : Échelle de disponibilité retenue pour l’étude
Page 45 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
l'échelle Description détaillée de l'échelle
Description orientée Entreprise/organisme
utilisateur
Aucun ou
Faible (I1)
Une perte ou modification non prévue,
volontaire ou non volontaire, n’affecte
en rien les activités d’un service, d’une
direction ou d’un organisme utilisateur.
Une perte ou modification non prévue, volontaire
ou involontaire, n’affecte en rien ou faiblement les
activités d’un service, d’une direction ou d’un
organisme utilisateur.
Moyen (I2)
Aucune modification non autorisée
n’est acceptée. L’exactitude des
informations est avérée mais sans
contrôle particulier. La modification
illicite des informations traitées ne
provoque pas de gêne significative pour
un service ou direction ou un
organisme utilisateur. Un contrôle à
posteriori est suffisant pour détecter
toute modification illicite.
Aucune modification non autorisée n’est acceptée.
L’exactitude des informations doit être avérée mais
sans contrôle particulier. Une modification non
autorisée va impacter plus ou moins modérément
un service, une direction ou un organisme
utilisateur avec un ou plusieurs types d'impact de
gravité "modérée". Un contrôle à posteriori est
suffisant pour détecter toute modification.
Critique (I3)
Aucune modification non autorisée
n’est acceptée et toute modification
autorisée doit être tracée.
Aucune modification non autorisée n’est acceptée
et toute modification autorisée doit être tracée.
Une modification non autorisée et tracée va
impacter plus ou moins significativement un
service, une direction ou un organisme utilisateur
avec un ou plusieurs types d'impact de gravité
"significative".
Majeure (I4)
Aucune modification non autorisée
n’est acceptée et toute modification
autorisée doit être tracée de façon
sécurisée. L’exactitude des
informations et l’authenticité des
transactions sont garanties par un
procédé technique difficilement
contournable. La modification illicite
n’est pas tolérée et doit être détectée
automatiquement, le plus rapidement
possible.
Aucune modification non autorisée n’est acceptée
et doit être détectée automatiquement le plus
rapidement possible. Toute modification autorisée
doit être tracée de façon sécurisée. L’exactitude
des informations et l’authenticité des transactions
sont garanties par un procédé technique
difficilement contournable. Une modification non
autorisée et tracée va impacter plus ou moins
gravement un service, une direction ou un
organisme utilisateur avec un ou plusieurs types
d'impact de gravité "grave".
Tableau 7 : Échelle d’intégrité retenue pour l’étude
Page 46 sur 145
10.1.4 Échelle de confidentialité
Le travail est également le même pour l’échelle de confidentialité.
Confidentialité
Niveaux de
l'échelle
Description détaillée de
l'échelle
Description orientée Entreprise/organisme
utilisateur
Aucun (C1)
La diffusion d’une
information dans le domaine
public n’affecte en rien les
activités d’un service, d’une
direction ou d’un organisme
utilisateur.
La diffusion d’une information dans le domaine
public n’affecte en rien ou faiblement les activités
d’un service, d’une direction ou d’un organisme
utilisateur.
Non publique
(C2)
Ce niveau traduit que la
diffusion est seulement
possible en interne et au sein
des organismes utilisateurs,
ainsi qu’à l’ensemble de
l’Administration et de ses
prestataires.
Ce niveau traduit que la diffusion est seulement
possible en interne et au sein des organismes
utilisateurs, ainsi qu’à l’ensemble de l’Administration
et de ses prestataires. Une divulgation non autorisée
va impacter plus ou moins modérément un service,
une direction ou un organisme utilisateur avec un ou
plusieurs types d'impacts de gravité "modérée".
Confidentiel
(C3)
Ce niveau restreint la
diffusion d’information au
niveau d’une direction, d’un
service, d’un projet métier ou
transverse.
Ce niveau restreint la diffusion d’information au
niveau d’une direction, d’un service, d’un projet
métier ou transverse. Une divulgation non autorisée
va impacter plus ou moins significativement un
service, une direction ou un organisme utilisateur
avec un ou plusieurs types d'impact de gravité
"significative".
Très
confidentiel
(C4)
Ce niveau restreint la
diffusion d’information à
quelques agents, ou externes,
nommément identifiés pour
un sujet donné.
Ce niveau restreint la diffusion d’information à
quelques agents, ou externes, nommément identifiés
pour un sujet donné. Une divulgation non autorisée
va impacter plus ou moins gravement un service, une
direction ou un organisme utilisateur avec un ou
plusieurs types d'impact de gravité "grave".
Tableau 8 : Échelle de confidentialité retenue pour l’étude
Page 47 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
Description Financier Juridique Activité Image
Exemples d'événements
redoutés
1 – Faible
L'entreprise et
l'ensemble
des
utilisateurs de
ses
applications
surmonteront
les impacts
sans aucune
difficulté.
Perte
financière
faible ou
nulle
Avertissement
Détérioration
modérée de
la relation
avec un tiers
et/ou
perturbation
limitée de
l'activité de
l'organisme
Mention
négative
ponctuelle
dans un
média
Indisponibilité limitée d'une
activité non critique (supportée
par l'application étudiée) pour
un ou plusieurs organismes
utilisateurs.
Altération partielle d'une base
de données non sensible pour
une application.
Consultation d'information non
publiques mais non sensibles
par une personne hors de la
sphère prévue.
2 –
Modéré
L'entreprise et
l'ensemble
des
utilisateurs de
ses
applications
surmonteront
les impacts
malgré
quelques
difficultés.
Perte
financière
jugée
modérée
Amende
Détérioration
de la relation
avec
plusieurs tiers
significatifs
et/ou
perturbation
moyenne de
l'activité de
l'organisme
Mention
négative
dans les
médias
avec
atteinte à
la
réputation
pour une
ligne
métier
Indisponibilité temporaire
d'une activité importante
(supportée par l'application
étudiée) pour un ou plusieurs
organismes utilisateurs.
Fuite d'informations non
publiques ayant une sensibilité
limitée.
Fraude à l'impact modéré.
3 –
Significatif
L'entreprise et
l'ensemble
des
utilisateurs de
ses
applications
surmonteront
les impacts
avec de
sérieuses
difficultés.
Perte
financière
jugée
significative
Responsabilité
morale de la
personne
Perte de la
gestion d'un
SI pour
l'entreprise /
incapacité à
réaliser une
activité
significative
pour un
organisme
utilisateur
Mention
négative
dans les
médias
avec
atteinte à
la
réputation
de l'entité
d'une
durée
limitée
Indisponibilité prolongée d'une
activité importante (supportée
par l'application étudiée) pour
un ou plusieurs organismes
utilisateurs.
Base de données d'une
application importante critique
altérée partiellement.
Fraude à l'impact significatif.
Vol de données sensibles dans
une application.
Page 48 sur 145
Impacts par type
Description Financier Juridique Activité Image
Exemples d'événements
redoutés
4 – Grave
L'entreprise
ou certains
des
utilisateurs de
ses
applications
ne
surmonteront
pas les
impacts (leur
survie est
menacée).
Perte
financière
jugée
inacceptable
Responsabilité
pénale du
Directeur / du
Responsable
de
l'organisme
utilisateur
Perte de la
gestion de
l'ensemble
des SI sous
responsabilité
pour
l'entreprise /
incapacité à
réaliser ses
activités
majeures
pour un ou
plusieurs
organismes
utilisateurs
Mention
négative
dans les
médias
avec
atteinte à
la
réputation
de l'entité
de façon
irréversible
Indisponibilité prolongée d'une
activité critique (supportée par
l'application étudiée) pour
plusieurs organismes
utilisateurs.
Bases de données d'une
application critique altérées et
inutilisables.
Fraude à l'impact très
important.
Fuite d'informations classifiées
pouvant nuire aux intérêts de
l’entreprise.
Tableau 9 : Échelle de gravité retenue pour l’étude
Page 49 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 de vraisemblance
Description Score
Niveau de compétence nécessaire
(malveillance)
Intérêt à réaliser le scénario de
menace pour la source de menace
malveillante (théorique & historique)
Moyens nécessaires
(malveillance)
Niveau d'exposition de la vulnérabilité
(corrélé inversement aux
moyens nécessaires pour
l'exploiter)
1. Faiblement probable ou nécessite des moyens très importants et/ou des connaissances très élevées dans le domaine considéré
Cela ne devrait pas se (re)produire.
1 Expert Très limité Importants Très limité
2. Moyennement probable (Modéré) ou nécessite un certain niveau d'expertise et/ou du matériel spécifique
Cela pourrait se (re)produire.
2 Solide
compétence Moyen Conséquents Moyen
3. Probable ou réalisable avec des moyens standards et/ou avec des connaissances de base
Cela devrait se (re)produire un jour ou l'autre.
3 Niveau
élémentaire informatique
Important Faibles Important
4. Très probable (Presque certain) ou réalisable par tout public
Cela va certainement se (re)produire prochainement.
4 Sans
compétence spécifique
Très Fort Aucun Très Fort
Tableau 10 : Échelle de vraisemblance retenue pour l’étude
Page 50 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)
Niveau de vraisemblance Score Connaissances
du passé Entreprise
Exemples Entreprise
Fréquence d'apparition
dans le monde pour
un organisme comparable
Exemples dans le monde pour un organisme
comparable
1. Faiblement probable ou nécessite des moyens très importants et/ou des connaissances très élevées dans le domaine considéré
1 Ne s'est jamais produit à l'Entreprise
N/A Rare ou exceptionnel
Sinistre majeur : crash/détournement d'avion, catastrophe naturelle, attaque ciblé par un code malveillant sophistiqué, incendie/inondation/destruction complète d'un Data centre ou siège social, pandémie.
2. Moyennement probable (Modéré) ou nécessite un certain niveau d'expertise et/ou du matériel spécifique
2 S'est déjà produit au moins une fois dans l’entreprise
Violation majeure de la charte d'utilisation entrainant une mesure disciplinaire
1x par an Chantage, cyber attaque massive.
3. Probable ou réalisable avec des moyens standards et/ou avec des connaissances de base
3 Se produit au moins une fois par an
Panne matériel, défaillance opérateur télécom
1X par mois
Fraude interne, déni de service sur un site web, vol d'informations sensibles par un hacker ou un espion, défacement de site web, infection virale d'un réseau complet.
4. Très probable (Presque certain) ou réalisable par tout public
4 Se produit au moins une fois par trimestre
Réception de virus informatiques, erreur de manipulation
1X par semaine
Réception de virus informatiques, erreurs de manipulation, vol d'ordinateurs portables, défaillances techniques.
Page 51 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)
Expression des besoins de sécurité (module 2) Les besoins de sécurité des biens essentiels sont exprimés à l'aide des
échelles correspondantes, selon le critère de sécurité étudié.
Estimation des événements redoutés (module 2) Les événements redoutés sont estimés en termes de gravité à l'aide de
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é.
Estimation des scénarios de menaces (module 3) Les scénarios de menaces sont estimés en termes de vraisemblance à l'aide
de l'échelle définie à cet effet.
Évaluation des scénarios de menaces (module 3) Les scénarios de menaces sont classés par ordre décroissant de
vraisemblance.
Estimation des risques (module 4)
- La gravité d'un risque est égale à celle de l'événement redouté considéré.
- 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é
Homologation de sécurité (module 5) Le traitement des risques ne peut être validé que s'il est démontré que les
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
Imp
act
4 4 8 12 16
3 3 6 9 12
2 2 4 6 8
1 1 2 3 4
Tableau 12 : Matrice de criticité des risques
Page 52 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.
Niveau du risque Stratégie de gestion du risque valeur du
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 53 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
BE_D1 Données à caractère personnel
Données liées aux utilisateurs de l’application ainsi qu’aux données présentent au sein de l’application
3 4
Les données personnelles comportent des informations nécessitant d'être intègres afin de garantir la bonne marche de l'application. Une perte d'intégrité doit être détectée et corrigée. Les données à caractère personnel présentent par ailleurs un besoin en confidentialité fort (dossier CNIL…).
BE_D2 Contrats Un contrat ne peut être signé qu’entre deux partis (pas de multipartis)
3 4
Les contrats comportent des informations nécessitant d'être intègre afin de garantir la bonne marche de l'application. Les contrats comportent des informations sensibles.
BE_D3 Factures Les factures sont générées via l’application
3 4 Les factures peuvent comporter des informations sensibles (ex : tiers nominatifs).
BE_D4 Pièces jointes Des pièces jointes de type PDF sont employés
3 4 Les utilisateurs pourront stocker des pièces jointes.
BE_D11 Traces techniques et applicatives
Exemple : Démarrages et arrêts, ouvertures et fermetures de sessions, etc…
3 2
Les traces techniques et applicatives recueillies sont garantes de la fiabilité de la piste d'audit. Leur besoin d'intégrité est fort. Les traces ne comportent pas de données sensibles.
BE_D11 Traces métier Exemple : création de contrat, modification de contrat, etc…
3 2
Les traces métier recueillies sont garantes de la fiabilité de la piste d'audit. Leur besoin d'intégrité est fort. Les traces ne comportent pas de 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 54 sur 145
ID Processus Fonctions D I C Commentaire
BE_F1 Expression de demande
Gestion des demandes 2 2
BE_F2 Passation de contrat
Passation du contrat 3 3 Saisie dans l’application.
BE_F3 Gestion et suivi de contrat
Gestion des contrôles 2 2
BE_F4 Calcul et facturation
Gestion des règles de gestion 3 3 L'impossibilité d'accéder à cette fonction devient problématique au-delà de deux jours
BE_F6 Fin du contrat Fin du contrat 3 3 L'impossibilité d'accéder à cette 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 55 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 56 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 57 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 58 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é.
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_C1 Données à caractère personnel
Compromission de
données à caractère personnel
C 4 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
ER_C2 Contrats (PAB, CDU, TO…)
Compromission de
Contrats C 4
Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
ER_C3 Pièces jointes Compromission de pièces
jointes C 4
Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
ER_C6
Structures organisationnelles et habilitations
Compromission des
structures organisation
nelles
C 4 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
ER_C7 Données des interfaces
Compromission des
données des interfaces
C 4 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
ER_C8 Factures Compromissi
on de factures
C 4 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (recours de la CNIL, des partenaires) Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 2
3
Page 59 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_C9 Suivi des incidents
Compromission des
données liées aux incidents
C 3 Interne / externe Accidentelle / délibérée Code malveillant
Image de marque : 3 (perte de crédibilité pour l’Entreprise) Impact pour l'utilisateur : 3
3
ER_C10
Traces applicatives
Compromission de traces applicatives
C 2 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 2 Image de marque : 2 Impact pour l'utilisateur : 2
2
ER_D1 Passation du contrat
Indisponibilité du
processus de passation du
contrat
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 1 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D2 Gestion et suivi du contrat
Indisponibilité du
processus de gestion et
suivi du contrat
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D3 Calcul et facturation
Indisponibilité du
processus de calcul et
facturation
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D4 Paiement et recouvrement
Indisponibilité du
processus de paiement et
recouvrement
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D5 Fin du contrat
Indisponibilité du
processus de fin de contrat
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
Page 60 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_D6 Bureautique
Indisponibilité des
fonctions de bureautique
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D8 Activités de support
Indisponibilité des
fonctions de support
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D9 Archivage
Indisponibilité de la
fonction d'archivage
D 3
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 3 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
3
ER_D10
Expression de la demande
Indisponibilité du
processus d'expression
de la demande
D 2
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 1 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
2
ER_D11
Gestion des utilisateurs
Indisponibilité de la
gestion des utilisateurs
D 2
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 2 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
2
ER_D12
Administration fonctionnelle
Indisponibilité de
l'administration
fonctionnelle
D 2
Interne / externe Accidentelle / délibérée Code malveillant Phénomène naturel Évènement interne Catastrophe naturelle
Activité : 2 (indisponibilité) Image de marque : 2 (perte de confiance en la dématérialisation) Financier Impact pour l'utilisateur
2
Page 61 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_I1 Données à caractère personnel
Altération de données à caractère personnel
I 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I2 Contrats (PAB, CDU, TO…)
Altération de Contrats
I 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I3 Pièces jointes Altération de
pièces jointes
I 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I5 Données liées aux tiers
Altération de données liées aux
tiers
I 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I6
Structures organisationnelles et habilitations
Altération de structures
organisationnelles
I 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I7 Factures Altération de
factures I 3
Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (retards de paiement) Juridique Image de marque : 3 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
3
ER_I8 Traces applicatives
Altération de traces
applicatives I 3
Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité de construire une piste d'audit) Image de marque Financier
3
Page 62 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
Impact pour l'utilisateur
ER_I10
Données des interfaces
Altération de données des
interfaces I 2
Interne / externe Accidentelle / délibérée Code malveillant
Activité : 2 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
2
ER_I11
Suivi des incidents
Altération des données
liées aux incidents
I 2 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 2 (retards de paiement) Juridique Image de marque : 2 (perte de crédibilité pour l'Entreprise) Financier : 2 (retards de paiement) Impact pour l'utilisateur
2
ER_T1 Gestion des utilisateurs
Répudiation sur la gestion
des utilisateurs
T 4 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 3 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T2 Passation du contrat
Répudiation sur le
processus de passation du
contrat
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (possibilité de fraude) Juridique : 2 (incapacité à répondre à une investigation) Image de marque Financier : 2 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T3 Gestion et suivi du contrat
Répudiation sur le
processus de gestion et
suivi du contrat
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Activité : 3 (possibilité de fraude) Juridique : 2 (incapacité à répondre à une investigation) Image de marque Financier : 2 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T4 Calcul et facturation
Répudiation sur le
processus de calcul et
facturation
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Financier : 4 (possibilité de fraude) Activité : 3 (possibilité de fraude) Juridique : 2 (incapacité à répondre à une investigation) Image de marque Impact pour l'utilisateur
3
Page 63 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_T5 Paiement et recouvrement
Répudiation sur le
processus de paiement et
recouvrement
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Financier : 4 (possibilité de fraude) Activité : 3 (possibilité de fraude) Juridique : 2 (incapacité à répondre à une investigation) Image de marque Impact pour l'utilisateur
3
ER_T6 Fin du contrat
Répudiation sur le
processus de fin de contrat
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T7 Bureautique
Répudiation sur les
fonctions de bureautique
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T9 Administration fonctionnelle
Répudiation sur
l'administration
fonctionnelle
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T10
Activités de support
Répudiation sur les
activités de support
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
ER_T11
Archivage
Répudiation sur la
fonction d'archivage
T 3 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 3 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 3 (possibilité de fraude) Impact pour l'utilisateur
3
Page 64 sur 145
Réf Bien essentiel Évènement
redouté Type
Besoin sécurité
Sources de menaces Impact Gravité
ER_T12
Expression de la demande
Répudiation sur le
processus d'expression
de la demande
T 2 Interne / externe Accidentelle / délibérée Code malveillant
Juridique : 2 (incapacité à répondre à une investigation) Activité : 2 (possibilité de fraude) Image de marque Financier : 2 (possibilité de fraude) Impact pour l'utilisateur
2
Tableau 17 : Événements redoutés
Page 65 sur 145
12.1 Événements redoutés par gravité
Gravité Réf Type Évènement redouté
Significatif
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
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
Modéré
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
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 66 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.
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
MAT_FW MAT-USG
D/I/C
Détournement de l'usage prévu d'un matériel
MAT_FW : Non-respect du processus d'ajout/modification des règles ORG_Entreprise : Mauvaises pratiques (utilisation de comptes d'administration génériques, échange de fichier…) RSX : Communication non sécurisée pour le déploiement des fichiers d'installation (FTP)
Supervision Nagios et vCenter WAF Charte d'utilisation Sessions de sensibilisation bi annuelles Administration avec authentification forte Durcissement des configurations
1-11 13
2 Moyennement probable
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, utilisation de comptes génériques, internet sur postes admin…). Des mesures 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 négligeable.
Page 67 sur 145
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
MAT_ESX MAT-ESP-ESX
C Espionnage des disques durs
MAT : Les disques durs qui partent en maintenance ne sont pas effacés.
Mise au rebut sécurisée sous traitée
1-11 1 Faiblement probable
Vu les mesures en place et les difficultés à reconstituer des données pertinentes via un unique disque, le scénario est faiblement probable.
MAT_FW MAT-DEP-FW
D
Dépassement des limites de fonctionnement d'un firewall
LOG_supervision : Absence de mise en corrélation des logs + traçabilité technique peu dissuasive (actions admin…) MAT_FW : Non-respect du processus d'ajout/modification des règles LOG : Pas de contrôle des uploads des utilisateurs
Redondance des infrastructures (sauf BD) Infrastructures en partage de charge pour les plus sollicitées Supervision Nagios et vCenter Load balancer Netscaler Administration avec authentification forte
1-11 13
2 Moyennement probable
Le dimensionnement optimiste des liens et des matériels augmente la vraisemblance du scénario.
MAT_ESX MAT-DEP-ESX
D
Dépassement des limites de fonctionnement d'un matériel
LOG: Pas de contrôle des uploads des utilisateurs RSX: Communication non sécurisée pour le déploiement des fichiers d'installation (FTP
Redondance des infrastructures Infrastructures en partage de charge pour les plus sollicitées Supervision Nagios et vCenter Load balancer Netscaler Administration avec authentification forte
1-11 13
1 Faiblement probable
Faiblement probable au vue des mesures déjà en place
MAT_STO_SAN MAT-DET
D Détérioration d'une baie de stockage
MAT_STO_SAN : Baie de stockage unique hébergeant tous les disques (SPOF) LOC : Datacenter en zone inondable
Redondance de l'alimentation Répartition de données en Raid 5 Site de secours à Toulouse Contrôle d'accès physique du Datacenter
1-11 14-17
1 Faiblement probable
Faiblement probable en vue des mesures en place. Cependant, il ne faut pas négliger ce scénario pouvant se produire à tout moment même si peu probable (crue de la Seine)
MAT_RSX_* MAT-MOD
D/I/C Modification d'un matériel réseau
LOG_supervision : Surveillance administrateur pas de vue globale des actions administrateurs ORG_Entreprise : Utilisation de comptes d'administration génériques
Administration avec authentification forte Contrôle d'accès physique du Datacenter
1-11 13
1 Faiblement probable
Faiblement probable en vue des mesures en place
Page 68 sur 145
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
LOG LOG-USG-PER
D/I/C
Détournement de l'usage prévu d'un logiciel par le personnel interne
ORG_Entreprise : Gestion difficile des habilitations (non-respect de la procédure Entreprise) ORG_PER : Mauvais usage par les exploitants, manque de sensibilisation ORG_Entreprise : Utilisation de comptes d'administration génériques ORG : Politique de mot de passe Entreprise non respectée
Cellule dédiée à la gestion des habilitations Charte d'utilisation Sessions de sensibilisation bi annuelles
1-11 13
2 Moyennement probable
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, utilisation de comptes génériques, internet sur postes admin…). Des mesures 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 négligeable.
LOG LOG-USG
D/I/C
Détournement de l'usage prévu d'un logiciel
ORG_Entreprise : Authentification simple pour les utilisateurs LOG : Vulnérabilités logicielles (failles XSS, injection de code…) LOG : Versions logicielles obsolètes
Administration avec authentification forte Durcissement des configurations Recette sécurité planifiée
1-11 13
2 Moyennement probable
LOG_BD_DOC LOG_BD_LOG
LOG-ESP
C Espionnage des bases de données
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 données LOG : Vulnérabilités logicielles (failles XSS, injection de code…) LOG : Versions logicielles obsolètes ORG : Manipulation de données de production par les équipes projet
1-11 13
2 Moyennement probable
Malgré les mesures en place, ces attaques sont faciles à mener par un administrateur par exemple.
Page 69 sur 145
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
LOG_OS_WIN LOG_OS_LINUX
LOG-VIR
D/I/C Piégeage logiciel
LOG : Vulnérabilités logicielles (failles XSS, injection de code…) LOG : Versions logicielles obsolètes ORG_Entreprise : Manque de sensibilisation, mauvaises pratiques ORG_Entreprise : PSSI non appliquée
Antivirus OS et flux IPS Durcissement des configurations Recette sécurité planifiée Politique antivirale Revue croisées Audits de code
13 2 Moyennement probable
Une attaque virale demande une grande connaissance du système mais peut être facilement motivée, et facilitée par le social engineering
LOG_BD_DOC LOG_BD_LOG
LOG-DEP-BD
D
Dépassement des limites des bases de données
LOG_BD : Les bases de données ne sont pas actif/passif, les restaurations se font manuellement. LOG : Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…)
1-11 13
2 Moyennement probable
Les bases de données ne sont pas redondées, ce qui rend inévitable scénario dans lequel une défaillance d'une base de données entraîne des interruptions du service
LOG_SRV_APP LOG_SRV_WEB
LOG-DEP
D Dépassement des limites d'un logiciel
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 déploiement des fichiers d'installation (FTP LOG : Vulnérabilités logicielles (failles XSS, injection de code…) LOG : Versions logicielles obsolètes LOG : Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…)
Supervision applicative et technique Postes d'administration dédiés, avec authentification forte
1-11 13
2 Moyennement probable
LOG_OS_LINUX LOG-MOD
D/I/C Modification d'un logiciel
LOG : Vulnérabilités logicielles (failles XSS, injection de code…) LOG : Versions logicielles obsolètes LOG : Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…)
Supervision applicative et technique Administration avec authentification forte
1-11 13
2 Moyennement probable
Malgré les mesures en place, ces attaques sont faciles à mener par un administrateur par exemple.
RSX_CI RSX-
MITM D/I/C
Attaque du milieu sur un canal informatique
RSX : Communications non chiffrées sur l'infrastructure (en backend) RSX : Communications non chiffrées lors du déploiement des fichiers d'installation (protocole FTP) RSX : Communication non chiffrée entre le
Absence de chiffrement des flux mais environnement considéré comme maitrisé en backend Supervision applicative et technique
1-11 13
2 Moyennement probable
Malgré les mesures en place, ces attaques sont faciles à mener par un administrateur par exemple.
Page 70 sur 145
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
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_CI RSX-ESP
C Écoute passive sur l'interlan
RSX : Communications non chiffrées sur l'infrastructure (en backend) RSX : Communications non chiffrées lors du déploiement des fichiers d'installation (protocole FTP) RSX : Communication non chiffrée entre le Netscaler/Serveur web/ Application Web (en frontend), utilisée pour le transport des jetons d'authentification
Absence de chiffrement des flux mais environnement considéré comme maitrisé en backend Cloisonnement en VLAN, TLS jusqu'au Netscaler
1-11 13
2 Moyennement probable
Malgré les mesures en place, ces attaques sont faciles à mener par un administrateur par exemple.
RSX_CI RSX-SAT
D Saturation du canal internet
RSX : Pas de contrôle des uploads des utilisateurs
Redondance des liens Contrôle d'accès physique du Datacenter Solution de DDoS de l'opérateur télécom
1-11 13
1 Faiblement probable
Faiblement probable en vue des mesures en place
ORG_PER PER-INF
I/C Influence sur une personne
ORG_Entreprise : Manque de sensibilisation, mauvaises pratiques ORG_Entreprise : PSSI non appliquée
Sessions de sensibilisation bi annuelles Charte d'utilisation
1-11 2 Moyennement probable
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, utilisation de comptes génériques, internet sur postes admin…). Des mesures 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 71 sur 145
Bien support Réf Critère Menace Vulnérabilités Mesures de sécurité Sources
de menaces
Vraisemblance Commentaire
négligeable.
ORG_FC PER-MOD
C Usurpation de droits
ORG : Authentification simple pour les utilisateurs ORG : Politique de mot de passe non respectée
Accès par l'intranet 1-11 2 Moyennement probable
La vraisemblance de ce scénario reste mitigée du fait que le service n'est pas exposé sur internet. Cependant, celui-ci reste hors de contrôle de l’application
ORG_PER PER-PTE
D/C Départ d'une personne
ORG_PER : Faible loyauté Clause de confidentialité Redondance des postes critiques
1-11 1 Faiblement probable
Faiblement probable en vue des mesures en place
Tableau 19 : Scénarios de menaces
Page 72 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 risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RC1 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
LOG-VIR
* Risque de compromission suite à une attaque virale Des hackers ayant de grandes capacités et connaissances, exploitent des failles des composants logiciels pour accéder à des données sensibles. La probabilité de l'attaque augmente avec les failles des composants, l'intérêt de l'attaque et la possibilité de l'effectuer à l'aide de social engineering.
3 3 Important
Page 73 sur 145
réf risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RD1 D
Expression de la demande Passation du contrat Gestion et suivi du contrat Paiement et recouvrement Fin du contrat Bureautique Gestion des utilisateurs Administration fonctionnelle Activités de support Archivage
Gravité 3 : ER_D1/ER_D9 Gravité 2 : ER_D10/ER_D12
LOG-VIR
* Risque de d'indisponibilité suite à une attaque virale Des hackers ayant de grandes capacités et connaissances, exploitent des failles des composants logiciels pour rendre indisponible l'application. La probabilité de l'attaque augmente avec les failles des composants, l'intérêt de l'attaque et la possibilité de l'effectuer à l'aide de social engineering.
3 3 Important
RC2 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
LOG-USG PER-INF PER-MOD
* Risque de compromission par vol de crédentiels L'authentification étant simple pour les utilisateurs, une personne malveillante installe un keylogger (les postes clients ne sont pas maîtrisés), tâche facilité grâce à du social engineering ou tout simplement observe la saisie du mot de passe de l'utilisateur (shoulder surfing) afin d'accéder au compte. La solution ne pouvant garantir l'identité de l'utilisateur, celui-ci peut accéder aux données sensibles. Cette attaque peut être motivée pour frauder par exemple.
3 2 Moyen
Page 74 sur 145
réf risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RC3 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
LOG-USG-PER PER-INF
* Risque de compromission de source interne Un administrateur interne malveillant profite d'une traçabilité des actions administrateur non dissuasive (mauvaises pratiques, pas d'enregistrement des actions des administrateurs…) pour accéder à des données sensibles et les divulguer (motivation financière, politique…). Les bases chiffrées ne permettent pas de se prévenir des attaques internes.
3 2 Moyen
RC4 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
MAT-ESP-BD
* Risque de compromission par sniffing Un utilisateur du réseau interne sniffe les flux internes non chiffrés, ou accède au sas SMA afin d'accéder à des données sensibles de l'application. Cela peut être sur sollicitation externe financée dans le but d'obtenir la nullité d'une procédure de justice par exemple.
3 2 Moyen
Page 75 sur 145
réf risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RC5 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
RSX-MITM
* Risque de compromission par rejeu L'authentification des utilisateurs s'effectue au niveau du Netscaler, les informations d'identification (jeton) peuvent être interceptées, modifiées et rejouées. Un attaquant peut profiter de l'absence de chiffrement sur le réseau interne (en particulier entre le Netscaler et le serveur application web, situé en front end) pour sniffer les paquets, usurper une identité, et ainsi compromettre des données sensibles.
3 2 Moyen
RI1 I
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_I1/ER_I8 Gravité 2 : ER_I11
LOG-USG-PER
* Risque d'altération suite à une erreur de manipulation Une erreur humaine d'un administrateur ou d'un exploitant sur l'infrastructure de virtualisation entraîne des pertes ou des altérations de données.
3 2 Moyen
Page 76 sur 145
réf risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RI2 I
Expression de la demande Passation du contrat Gestion et suivi du contrat Paiement et recouvrement Fin du contrat Bureautique Gestion des utilisateurs Administration fonctionnelle Activités de support Archivage
Gravité 3 : ER_T1/ER_T11 Gravité 2 : ER_T12
LOG-USG-PER PER-INF RSX-MITM LOG-MOD
* Risque d'altération des journaux constituant la piste d'audit Un attaquant interne profite d'une vulnérabilité logicielle ou applicative pour effacer ou modifier des traces à valeur probante dans la base de données dédiée. La piste d'audit est compromise.
3 2 Moyen
RI3 I
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_I1/ER_I8 Gravité 2 : ER_I11
RSX-MITM
* Risque d'altération de données par interception et rejeu Un attaquant interne profite de l'absence de chiffrement des flux et de contrôle d'intégrité des données jusqu'à l'archivage pour procéder à une 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)
3 2 Moyen
RD2 D
Expression de la demande Passation du contrat Gestion et suivi du contrat Paiement et recouvrement Fin du contrat Bureautique Gestion des utilisateurs Administration fonctionnelle Activités de support Archivage
Gravité 3 : ER_D1/ER_D9 Gravité 2 : ER_D10/ER_D12
LOG-VIR
* Risque de d'indisponibilité suite à un upload malicieux Un attaquant upload un fichier exécutable malicieux, en l'absence de restriction sur les extensions de fichier, la surface d'attaque est augmentée malgré les contrôles antiviraux en place. Ce type d'attaque peut aboutir à une indisponibilité du système.
3 2 Moyen
Page 77 sur 145
réf risque
Critère sécurité
Biens essentiels concernés Évènements
redoutés Scénarios
de menace Exemple Scénarios de risque (SM X ER) Gravité Vraisemblance
Valeur du risque
RC6 C
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_C1/ER_C9 Gravité 2 : ER_C10
LOG-ESP RSX-MITM
* 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 équipes projets. En l'absence de respect strict des 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.
3 2 Moyen
RI4 I
Données à caractère personnel Contrats Factures Pièces jointes Données liées aux tiers Structures organisationnelles et habilitations Données des interfaces Suivi des incidents Traces applicatives
Gravité 3 : ER_I1/ER_I8 Gravité 2 : ER_I11
LOG-USG-PER
* Risque de compromission suite à une usurpation d'identité Si la méthode de création de mot de passe n'est pas conforme à la politique de mot de passe en vigueur à l'Entreprise, le risque d'usurpation est augmenté en raison de l'utilisation de mots de passe potentiellement plus faibles. Des données sensibles peuvent être indument modifiées.
3 2 Moyen
RD3 D
Expression de la demande Passation du contrat Gestion et suivi du contrat Paiement et recouvrement Fin du contrat Bureautique Gestion des utilisateurs Administration fonctionnelle Activités de support Archivage
Gravité 3 : ER_D1/ER_D9 Gravité 2 : ER_D10/ER_D12
MAT-DET
* Risque d'indisponibilité suite à une catastrophe naturelle Une crue centennale de la Seine rendrait indisponible la solution (coupure d'alimentation du Datacenter Vauban). Le PRA ne sera disponible et opérationnel qu'à compter du pilote. La source de menace est environnementale.
3 1 Mineur
Tableau 20 : Risques
Page 78 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 79 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 80 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 81 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 82 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 83 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 84 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 85 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 86 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 87 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 88 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 89 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 90 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 91 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 92 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 93 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 94 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 95 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 96 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 97 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 98 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é.
réf mesure
Titre de la mesure Description Vulnérabilité
couverte Risque
impacté
État
Responsable Non
retenu En
étude Proposée
En place
MS_1 Tests d'intrusion
Planifier des tests d'intrusion avant et après mise en production de l'applicatif et proposer une trajectoire de résolution des anomalies
* Vulnérabilités logicielles (failles XSS, injection de code…) * Versions logicielles obsolètes * Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…)
RC1 RD1 RI2
X Prestataire
MS_2 Audit de code
Mettre en place des audits de code (axés sur la sécurité du code) itératifs et proposer une trajectoire de résolution des anomalies
* Vulnérabilités logicielles (failles XSS, injection de code…)
RC1 RD1 RI2
X Prestataire
MS_3 Chiffrement de la liaison Netscaler - application web
Utiliser un protocole sécurisé (HTTPS) entre le Netscaler et le serveur application WEB, afin de sécuriser l'échange du jeton d'authentification.
* Communication non chiffrée entre le Netscaler/Serveur web/ Application Web (en front end), utilisée pour le transport des jetons d'authentification
RC5 X Prestataire
MS_4 Intégration de la gestion des actifs et des vulnérabilités
S'assurer que la gestion des actifs et des vulnérabilités sont bien intégrés dans les processus mis en place par le groupement
* Versions logicielles obsolètes
RC1 RD1 RI2
X Prestataire
Page 99 sur 145
réf mesure
Titre de la mesure Description Vulnérabilité
couverte Risque
impacté
État
Responsable Non
retenu En
étude Proposée
En place
MS_5 Montée de version sur les serveurs web et applicatifs
En particulier, les versions applicatives des serveurs web en zone frontale (Apache) et les serveurs applicatifs (Tomcat) doivent être exemptes de vulnérabilités connues.
* Versions logicielles obsolètes
RC1 RD1 RI2
X Prestataire
MS_6
SFTP pour le déploiement des fichiers d'installation
Utiliser un protocole sécurisé (SFTP) pour déployer les fichiers d'installation, afin de garantir l'intégrité des applicatifs installés.
* Communications non chiffrées lors du déploiement des fichiers d'installation (protocole FTP)
RC1 RD1 RI2
X Prestataire
MS_7 Restriction sur le requêteur SQL
Restreindre l'utilisation de l'outil d'extraction de données aux seuls administrateurs fonctionnels de la solution
RC1 RC2 RC3 RC4
X
Prestataire
MS_8 Analyse antivirale des uploads
Analyser les fichiers uploadés par un antivirus avant tout traitement, dans un sas de décontamination
* Pas de contrôle des uploads des utilisateurs
RD2 X Prestataire
MS_9 Contrôle des extensions des fichiers uploadés
S'assurer qu'un mécanisme permet de restreindre l'upload de fichiers uniquement aux formats prévus par l'utilisation.
* Pas de contrôle des uploads des utilisateurs
RD2 X Prestataire
MS_10
Encadrer l'utilisation des données de production par les équipes projet
Les données de production, en particulier pendant la phase de reprise des données, doivent être manipulées dans le respect de la politique de protection des données sensibles.
* Manque de sensibilisation, mauvaises pratiques * Manipulation de données de production par les équipes projet
RC6 X Prestataire / Entreprise
MS_11 Respect des procédures d'ajout/suppression
S'assurer de la bonne prise en compte des procédures d'ajout
* Non-respect du processus d'ajout/modification
RD1 RD2
X Prestataire
Page 100 sur 145
réf mesure
Titre de la mesure Description Vulnérabilité
couverte Risque
impacté
État
Responsable Non
retenu En
étude Proposée
En place
de règles firewall et de suppression des règles de filtrage
des règles
MS_12 Sensibilisation des développeurs à la sécurité
Les développeurs doivent être sensibilisés à la sécurité des développements applicatifs
* Vulnérabilités logicielles (failles XSS, injection de code…) * Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…) * Manque de sensibilisation, mauvaises pratiques
RC1 RD1 RI2
X
Prestataire
MS_13
Authentification forte par certificat pour les administrateurs fonctionnels
Les utilisateurs de l’application ayant un profil d'administration fonctionnelle (ajout suppression d'utilisateurs, accès aux requêtes SQL…) doivent s'authentifier à l'aide d'une authentification forte par certificat. De manière générale, l'authentification forte doit être utilisée autant que possible pour l'ensemble des utilisateurs.
* Authentification simple pour les utilisateurs
RI4 RC2
X Prestataire
MS_14 Durcissement des configurations
Les applicatifs apportés (Apache, Tomcat…) doivent être durcis selon l'état de l'art en vigueur (suppression des comptes génériques, personnalisation des erreurs, fermetures des ports non utilisés, etc.)
* Absence de durcissement des configurations (paramétrages par défaut, ports ouverts…)
RC1 RD1 RI2
X Prestataire
MS_15
Respect de la politique de revue des droits propre à l’application
La gestion des habilitations doit être conforme à la politique de revue des droits mise en place sur
* Gestion difficile des habilitations (non-respect de la procédure Entreprise)
RI4 RC2
X Prestataire
Page 101 sur 145
réf mesure
Titre de la mesure Description Vulnérabilité
couverte Risque
impacté
État
Responsable Non
retenu En
étude Proposée
En place
l’application
MS_16
Respect de la politique de mot de passe de l'entreprise
Lors de la création de compte utilisateur ou lors de changement de mot de passe, l'utilisateur ne doit pouvoir saisir qu'un mot de passe conforme à la politique de mot de passe en vigueur à l'Entreprise
* Politique de mot de passe de l’entreprise non respectée
RI4 X Prestataire
MS_17 Chiffrement des flux internes de l’application
Chiffrer les flux internes à l’application (TLS) jusqu'à l'archivage.
* Communications non chiffrées sur l'infrastructure
RC4 RC5 RI3
X
MS_18 Chiffrement des données sensibles en base
Chiffrer les informations sensibles (champs en base ou pièces jointes) en base. Chiffrer les données suivantes : - les informations à caractère personnel - les pièces justificatives
* Données sensibles non chiffrées en base
RC1 RC2 RC3 RC4 RI3
X Prestataire
MS_19 Plan de continuité d'activité
Intégrer les composants de l’application dans le PCA/PRA de l’entreprise.
RD3 X Prestataire
MS_20 Gestion des traces applicatives et techniques
Les journaux techniques et applicatifs sont remontés à la solution de gestion des logs de l’entreprise (ELK). En particulier, toutes les actions administrateurs, les accès aux bases de données, les authentifications (succès + échec), changements de droits utilisateurs doivent être journalisés.
* Surveillance administrateur : pas de vue globale des actions administrateurs
RI2 RC3 RC4
X
Prestataire
Page 102 sur 145
réf mesure
Titre de la mesure Description Vulnérabilité
couverte Risque
impacté
État
Responsable Non
retenu En
étude Proposée
En place
MS_21
Procédures d'exploitation et formation des administrateurs
Former les administrateurs aux tâches et nouvelles technologies employées. S'assurer que des procédures d'exploitation existent pour ces actions.
* Erreurs de manipulation
RI1 X
Prestataire
Tableau 21 : Mesures de sécurité complémentaires
Page 103 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.
Réf risque
Critère sécurité
Exemple Scénarios de risque (SM X ER) Gravit
é Vraisemblance
Risque initial Mesure complémentaire Vraisembl
ance résiduelle
Risque résiduel
RC1 C
* Risque de compromission suite à une attaque virale Des hackers ayant de grandes capacités et connaissances, exploitent des failles des composants logiciels pour accéder à des données sensibles. La probabilité de l'attaque augmente avec les failles des composants, l'intérêt de l'attaque et la possibilité de l'effectuer à l'aide de social engineering.
3 3 Important
* Tests d'intrusion * Audit de code * Intégration de la gestion des actifs et des vulnérabilités * Montée de version sur les serveurs web et applicatifs * SFTP pour le déploiement des fichiers d'installation * Restriction sur le requêteur SQL * Sensibilisation des développeurs à la sécurité * Durcissement des configurations * Chiffrement des données sensibles en base
1 Mineur
Page 104 sur 145
Réf risque
Critère sécurité
Exemple Scénarios de risque (SM X ER) Gravit
é Vraisemblance
Risque initial Mesure complémentaire Vraisembl
ance résiduelle
Risque résiduel
RD1 D
* Risque de d'indisponibilité suite à une attaque virale Des hackers ayant de grandes capacités et connaissances, exploitent des failles des composants logiciels pour rendre indisponible l'application. La probabilité de l'attaque augmente avec les failles des composants, l'intérêt de l'attaque et la possibilité de l'effectuer à l'aide de social engineering.
3 3 Important
* Tests d'intrusion * Audit de code * Intégration de la gestion des actifs et des vulnérabilités * Montée de version sur les serveurs web et applicatifs * SFTP pour le déploiement des fichiers d'installation * Sensibilisation des développeurs à la sécurité * Durcissement des configurations * Respect des procédures d'ajout/suppression de règles firewall
1 Mineur
RC2 C
* Risque de compromission par vol des crédentiels L'authentification étant simple pour les utilisateurs, une personne malveillante installe un keylogger (les postes clients ne sont pas maîtrisés), tâche facilité grâce à du social engineering ou tout simplement observe la saisie du mot de passe de l'utilisateur (shoulder surfing) afin d'accéder au compte. La solution ne pouvant garantir l'identité de l'utilisateur, celui-ci peut accéder aux données sensibles. Cette attaque peut être motivée pour frauder par exemple.
3 2 Moyen
* Restriction sur le requêteur SQL * Authentification forte par certificat pour les administrateurs fonctionnels * Respect de la politique de revue des droits propre à l’application * Chiffrement des données sensibles en base
1 Mineur
RC3 C
* Risque de compromission de source interne Un administrateur interne malveillant profite d'une traçabilité des actions administrateur non dissuasive (mauvaises pratiques, pas d'enregistrement des actions des administrateurs…) pour accéder à des données sensibles et les divulguer (motivation financière, politique…). Les bases chiffrées ne permettent pas de se prévenir des attaques internes.
3 2 Moyen * Gestion des traces applicatives et techniques * Chiffrement des données sensibles en base * Restriction sur le requêteur SQL
1 Mineur
Page 105 sur 145
Réf risque
Critère sécurité
Exemple Scénarios de risque (SM X ER) Gravit
é Vraisemblance
Risque initial Mesure complémentaire Vraisembl
ance résiduelle
Risque résiduel
RC4 C
* Risque de compromission par sniffing Un utilisateur du réseau interne sniffe les flux internes non chiffrés, ou accède au sas SMA afin d'accéder à des données sensibles de l'application. Cela peut être sur sollicitation externe financée dans le but d'obtenir la nullité d'une procédure de justice par exemple.
3 2 Moyen
* Chiffrement des flux internes L’application * Chiffrement des données sensibles en base * Gestion des traces applicatives et techniques * Restriction sur le requêteur SQL
1 Mineur
RC5 C
* Risque de compromission par rejeu L'authentification des utilisateurs s'effectue au niveau du Netscaler, les informations d'identification (jeton) peuvent être interceptées, modifiées et rejouées. Un attaquant peut profiter de l'absence de chiffrement sur le réseau interne (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.
3 2 Moyen * Chiffrement de la liaison Netscaler - application web * Chiffrement des flux internes L’application
1 Mineur
RI1 I
* Risque d'altération suite à une erreur de manipulation Une erreur humaine d'un administrateur ou d'un exploitant sur l'infrastructure de virtualisation entraîne des pertes ou des altérations de données.
3 2 Moyen * Procédures d'exploitation et formation des administrateurs
1 Mineur
RI2 I
* Risque d'altération des journaux constituant la piste d'audit Un attaquant interne profite d'une vulnérabilité logicielle ou applicative pour effacer ou modifier des traces à valeur probante dans la base de données dédiée. La piste d'audit est compromise.
3 2 Moyen
* Tests d'intrusion * Audit de code * Intégration de la gestion des actifs et des vulnérabilités * Montée de version sur les serveurs web et applicatifs * SFTP pour le déploiement des fichiers d'installation * Sensibilisation des développeurs à la sécurité * Durcissement des configurations * Gestion des traces applicatives et techniques
1 Mineur
Page 106 sur 145
Réf risque
Critère sécurité
Exemple Scénarios de risque (SM X ER) Gravit
é Vraisemblance
Risque initial Mesure complémentaire Vraisembl
ance résiduelle
Risque résiduel
RI3 I
* Risque d'altération de données par interception et rejeu Un attaquant interne profite de l'absence de chiffrement des flux et de contrôle d'intégrité des données jusqu'à l'archivage pour procéder à une 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)
3 2 Moyen * Chiffrement des données sensibles en base * Chiffrement des flux internes L’application * Gestion des traces applicatives et techniques
1 Mineur
RD2 D
* Risque de d'indisponibilité suite à un upload malicieux Un attaquant upload un fichier exécutable malicieux, en l'absence de restriction sur les extensions de fichier, la surface d'attaque est augmentée malgré les contrôles antiviraux en place. Ce type d'attaque peut aboutir à une indisponibilité du système.
3 2 Moyen
* Analyse antivirale des uploads * Contrôle des extensions des fichiers uploadés * Respect des procédures d'ajout/suppression de règles firewall
1 Mineur
RC6 C
* 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 équipes projets. En l'absence de respect strict des 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.
3 2 Moyen * Encadrer l'utilisation des données de production par les équipes projet 1 Mineur
RI4 I
* Risque de compromission suite à une usurpation d'identité Si la méthode de création de mot de passe n'est pas conforme à la politique de mot de passe en vigueur dans l'Entreprise, le risque d'usurpation est augmenté en raison de l'utilisation de mots de passe potentiellement plus faibles. Des données sensibles peuvent être indument modifiées.
3 2 Moyen
* Authentification forte par certificat pour les administrateurs fonctionnels * Respect de la politique de revue des droits propre à L’application * Respect de la politique de mot de passe de l'Entreprise
1 Mineur
Page 107 sur 145
Réf risque
Critère sécurité
Exemple Scénarios de risque (SM X ER) Gravit
é Vraisemblance
Risque initial Mesure complémentaire Vraisembl
ance résiduelle
Risque résiduel
RD3 D
* Risque d'indisponibilité suite à une catastrophe naturelle Une crue centennale de la Seine rendrait indisponible la solution (coupure d'alimentation du Datacenter Vauban). Le PRA ne sera disponible et opérationnel qu'à compter du pilote. La source de menace est environnementale.
3 1 Mineur * Plan de continuité d'activité 1 Mineur
Tableau 22 : Risques résiduels
Page 108 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é.
Figure 12 : Matrice des risques bruts
C1 D1 D3 C2 C3 C4 C5
D2
I1 I2
I3 I4 C6
Page 109 sur 145
16.1.3 Matrice des risques résiduels
Figure 13 : Matrice des risques résiduels
C1 C2 C3 C4
C5 D1 D2 D3
I1 I2 I3 I4
C6
Page 110 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 111 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 Privileged Group
4728, 4732, 4756
Informational Security Microsoft-Windows-Security-Auditing
Security-Enabled group Modification
4735 Informational Security Microsoft-Windows-Security-Auditing
Successful User Account Login
4624 Informational Security Microsoft-Windows-Security-Auditing
Failed User Account Login
4625 Informational Security Microsoft-Windows-Security-Auditing
Account Login with Explicit Credentials
4648 Informational Security Microsoft-Windows-Security-Auditing
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 112 sur 145
Bilan de la mission
Page 113 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 114 sur 145
18 Matrice des risques nets
Figure 14 : Matrice des risques nets
C1 C2
C3
C4
C5 D1 D2 D3
I1 I2 I3
I4
C6
Page 115 sur 145
Conclusion
Page 116 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 117 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 118 sur 145
Bibliographie
Page 119 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 120 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 121 sur 145
Glossaire
Page 122 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 123 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 124 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 125 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 126 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 127 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 128 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 129 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 130 sur 145
Liste des abréviations
Page 131 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
HIDS Host Intrusion Détection System ou « Système de détection d'intrusion 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 132 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
TCP Transmission Control Protocol ou « protocole de contrôle de
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 133 sur 145
Table des annexes
Page 134 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
R1 Utiliser des systèmes et des applicatifs disposants d’une fonctionnalité de journalisation est primordial. La prise en compte de cette fonction doit se faire lors de toute démarche de conception et de développement.
R2 L’horodatage doit être activé pour l’ensemble des événements afin de permettre une meilleure exploitation des journaux.
R3 Les horloges des équipements doivent être synchronisées sur plusieurs sources de temps 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.
R4 Lors du dimensionnement des équipements, l’estimation de l’espace de stockage nécessaire à la conservation locale des journaux est indispensable.
R5 Les journaux doivent être automatiquement exportés sur une machine physique différente de celle qui les a générés.
R6 Les journaux de l’ensemble des équipements du système d’information doivent être transférés su un ou plusieurs serveurs centraux dédiés.
R7 Si le parc d’équipements qui génère des journaux est important, le serveur central devra être redondé afin d’accroitre la disponibilité du service de collecte de journaux.
R8 Si la taille ou la typologie du système d’information le nécessite, une approche hiérarchique pour l’organisation des serveurs de collecte doit être retenue.
R9 Si le contexte le permet, un transfert en temps réel des journaux sur les serveurs centraux soit être privilégié.
R10 Il est recommandé de ne pas effectuer de traitement sur les journaux avant leur transfert.
R11 Il est recommandé d’utiliser des protocoles d’envoi de journaux basés sur TCP pour fiabiliser le transfert de données entre les machines émettrices et les serveurs centraux.
R12 Il est recommandé d’utiliser des protocoles de transfert de journaux qui s’appuient sur des mécanismes cryptographiques robustes en particulier lorsque les données transitent sur des réseaux non maitrisés.
R13 Il est recommandé de bien contrôler la bande passante des flux réseau utilisée pour transférer les journaux d’événements.
R14 Lorsque le besoin de sécurité pour le transfert des journaux est important, il doit se faire sur un réseau d’administration dédié.
R15 S’il n’existe pas de réseaux d’administration dans l’architecture pour accueillir les serveurs de 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 135 sur 145
# Description originale
R16 Une partition disque doit être dédiée au stockage des journaux d’évènements sur les é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.
R18 Une politique de rotation des journaux d’événements doit être formalisée et mise en œuvre sur l’ensemble des équipements du système de journalisation.
R19 La durée de conservation des fichiers de journaux étant soumises à des contraintes légales et réglementaires, il convient d’en prendre connaissance pour définir les moyens techniques nécessaire à l’archivage des journaux.
R20 L’accès aux journaux doit être limité en écriture à un nombre restreint de comptes ayant le besoin d’en connaitre.
R21 Les processus de journalisation et de collecte doivent être exécutés par des comptes disposant de peu de privilèges.
R22 Un outil spécifique doit être utilisé pour une meilleure exploration des journaux présents sur les serveurs centraux, la détection d’évènements anormaux en sera facilitée.
R23 Les comptes ayant accès à l’outil de consultation centralisée des journaux doivent être 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 136 sur 145
Annexe 2 - Menaces standards EBIOS:2010
MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS
M1 MAT-USG Mauvais usage (intentionnel
ou non) d'un matériel
Copie d'informations sensibles sur des
supports amovibles (cf. clés USB, CD/DVD,
etc.) non prévus pour cet usage / utilisation
de la puissance CPU d'un serveur pour casser
des mots de passe / saturation d'un espace
de stockage par des fichiers à finalité non-
professionnelle (cf. DivX, MP3, etc.) / …
M2 MAT-ESP Espionnage d'un matériel
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 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…).
M3 MAT-DEP
Saturation des capacités de
traitement/stockage/communi
cation d'un matériel
Déni de service (DoS/DDoS) sur interfaces
réseaux / surallocation de VM sur un ou
plusieurs serveurs de la ferme
(RAM/CPU/Disques durs) / surutilisation
d'un serveur dédié (RAM/CPU/Disques durs)
/ 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.) / …
M4 MAT-DET
Panne ou destruction
(provoquée ou non) d'un
matériel
Projections d'eau (cf. fuite de canalisation ou
de climatisation, système anti-incendie à
eau, etc.) sur des composants électroniques
/ source de chaleur les faisant fondre (cf.
incendie) / vandalisme intentionnel ou non /
…
M5 MAT-MOD
Piégeage physique ou
évolution hardware non
maîtrisée d'un matériel
Installation d'équipements malicieux (cf.
keylogger hardware, point d'accès réseau
pirate) / installation licite de composants
incompatibles (cf. upgrade
RAM/CPU/contrôleurs stockage/etc.) / …
Page 137 sur 145
MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS
M6 MAT-PTE Perte ou vol d'un matériel
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
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 /
…
M7 LOG-USG
Mauvais usage (intentionnel
ou non) d'une application /
d'un service système ou réseau
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
centralisée, répertoire local, etc.) / fuite de
données sensibles (cf. mail, Webmail, IM,
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.) / …
M8 LOG-ESP
Analyse passive d'une
application / d'un service
système ou réseau
Analyse du code source d'une application
pour identifier des vulnérabilités / scan
d'adresses IP pour cartographier un réseau /
scan de ports sur des serveurs pour identifier
les services actifs / …
M9 LOG-DEP
Saturation ou détournement
malicieux d'une application /
d'un service système ou réseau
DoS/DDoS au niveau applicatif / fuzzing (cf.
SQL injection, XSS ou Cross Site Scripting,
etc.) / buffer overflow / boucle infinie dans
un programme / …
M10 LOG-DET
Suppression (intentionnelle ou
non, partielle ou complète)
d'un logiciel
Effacement d'exécutables ou de librairies en
environnement de production / effacement
d'une version du code source de
programmes en environnement de
développement / …, que ce soit par erreur
ou non, par une action humaine ou non (cf.
Page 138 sur 145
MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS
virus, bombe logique, etc.)
M11 LOG-MOD
Modification (intentionnelle
ou non) d'une application /
d'un service système ou réseau
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
(cf. keylogger, troyan, backdoor, etc.) / virus
ou vers se propageant à l'aide d'un logiciel
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.) / …
M12 LOG-PTE Perte de propriété ou de droit
d'usage d'un logiciel
Expiration de licences d'utilisation (cf. OS,
middleware, outil de développement,
d'administration, de supervision, de
chiffrement, de signature, etc.)
M13 RSX-USG Attaque réseau active (par
usurpation ou détournement)
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
commutation, du routage, du service DNS,
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 / …)
M14 RSX-ESP Attaque par écoute passive du
réseau
attaque par sniffing d'un brin réseau (cf.
carte réseau en mode promiscuous) /
attaque par port-mirroring sur un
équipement réseau (cf. sonde réseau) / …
M15 RSX-DEP Saturation (intentionnelle ou
non) du réseau
DoS/DDoS au niveau réseau / boucle
Ethernet ou boucle de routage / application
de niveaux de QoS inadaptés / …
M16 RSX-DET
Dégradation (intentionnelle ou
non) de l'infrastructure
physique du réseau
Sectionnement ou coupure accidentelle (cf.
"coup de pelleteuse" sur la voie publique)
d'un câble réseau / torsion ou courbure trop
serrée d'une fibre optique / faux-contact
dans une paire torsadée à nu / …
Page 139 sur 145
MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS
M17 RSX-MOD
Modification (intentionnelle
ou non) de l'infrastructure
physique du réseau
Câble de catégorie insuffisante pour la
distance et/ou le débit utilisés / …
M18 RSX-PTE Disparition d'un canal
informatique ou de téléphonie Vol de câbles de transmission.
M19 PER-USG
Entrave à l'activité
professionnelle d'une
personne
Les ressources de la personne sont
employées à faire autre chose que ce qu'elle
devrait faire, sans la faire changer ni
l'affecter physiquement. Ses performances
peuvent ainsi être diminuées.
M20 PER-ESP Espionnage d'une personne
Observation ou écoute d'une personne, avec
ou sans équipement d'amplification
sensorielle ou de capture, depuis l'intérieur
ou l'extérieur des locaux, sans être affectée
physiquement.
M21 PER-DEP Surmenage d'une personne
Les capacités (compétences, ressources,
capacités physiques ou psychologiques) de la
personne sont dépassées. Elle peut ainsi ne
plus agir correctement et ses performances
peuvent diminuer.
M22 PER-DET Atteinte à l'intégrité physique
d'une personne
La personne est affectée physiquement ou
psychologiquement, partiellement ou
totalement, temporairement ou
définitivement, à l'intérieur ou à l'extérieur
des locaux. Elle peut ainsi exercer sa fonction
de manière moins performante, voire ne
plus pouvoir exercer sa fonction.
M23 PER-MOD Manipulation d'une personne
Les conditions d'exercice du libre arbitre de
la personne sont modifiées, à l'intérieur ou à
l'extérieur des locaux. Elle peut ainsi être
amenée à agir de manière inopportune ou à
divulguer des informations.
M24 PER-PTE Départ d'une personne
La personne est perdue pour l'organisme,
sans être affectée. Son savoir et son savoir-
faire ne sont plus disponibles pour
l'organisme mais le deviennent pour autrui.
M25 PAP-USG Détournement de l’usage
prévu d'un support papier Non retenue dans le cadre de la mission
M26 PAP-ESP Espionnage d'un support
papier
Non retenue dans le cadre de la mission
Page 140 sur 145
MENACE EBIOS:2010 LIBELLE EXPLICITE ET ILLUSTRATIONS
M27 PAP-DET Détérioration d'un support
papier
Non retenue dans le cadre de la mission
M28 PAP-PTE Perte d'un support papier Non retenue dans le cadre de la mission
M29 CAN-USG Manipulation via un canal
interpersonnel
Non retenue dans le cadre de la mission
M30 CAN-ESP Espionnage d'un canal
interpersonnel
Non retenue dans le cadre de la mission
M31 CAN-DEP Saturation d'un canal
interpersonnel
Non retenue dans le cadre de la mission
M32 CAN-DET Dégradation d'un canal
interpersonnel
Non retenue dans le cadre de la mission
M33 CAN-MOD Modification d'un canal
interpersonnel
Non retenue dans le cadre de la mission
M34 CAN-PTE Disparition d'un canal
interpersonnel
Non retenue dans le cadre de la mission
Page 141 sur 145
Liste des figures
Page 142 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 143 sur 145
Liste des tableaux
Page 144 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 145 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.