Université AFCDP des CIL 2016 : Denis Virole anime l’atelier « L’homologation de la sécurité des traitements de données à caractère personnel »

p 0
L'homologation de la sécurité des données à caractère personnel
– V08.0 – 27/01/2016 / Reproduction interdite sans autorisation
L'homologation de la sécurité des traitements
de données à caractère personnel
Le processus d’homologation, méthodes, acteurs et responsabilités
Animateur: Denis Virole
http://www.ageris-group.com/
Vos contacts
M. Denis VIROLE
Directeur des Services
+33 (0) 6 11 37 47 56
denis.virole@ageris-group.com
M. Thierry RAMARD
Dirigeant
+33 (0) 6 17 64 90 72
thierry.ramard@ageris-group.com
Mme Caroline MEOT
Responsable Commerciale
+33 (0) 6 46 13 00 19
caroline.meot@ageris-group.com
L'homologationdelasécuritédesdonnéesàcaractèrepersonnel

p 1
Pour un certain nombre de systèmes, l’homologation est rendue obligatoire
par des textes, tels que:
• Instruction Générale Interministérielle N° 1300 sur LA PROTECTION DU SECRET DE LA DÉFENSE
NATIONALE;
• le Référentiel Général de Sécurité (RGS);
• la Politique de Sécurité des Systèmes d’Information de l’État (PSSI E);
• la PSSI –S (ASIP SANTE).
Il s’agit d’un processus d’information et de responsabilisation qui aboutit à une
décision, prise par le responsable de l’organisation.
Cette décision constitue un
acte formel par lequel il :
• atteste de sa connaissance du système d’information et des mesures de sécurité
(techniques, organisationnelles ou juridiques) mises en œuvre ;
• accepte les risques qui demeurent, qu’on appelle risques résiduels.
Le Processus d’Homologation de sécurité du SI
L’autorité d’homologation doit être désignée à un niveau hiérarchique suffisant pour assumer toutes
les responsabilités. Il est donc nécessaire que l’autorité d’homologation se situe à un niveau de
direction dans l’organisme.

p 2
Un « risque accepté » est caractérisé par la conjonction des 3 éléments suivants :
1. connaissance de l’existence d’un risque associé à une défaillance de sécurité par les décideurs
métiers;
2. mesure du risque par les intervenants autorisés, en fonction d’un référentiel (critères, calcul et
seuils d’impact, etc.) opposable ;
3. arbitrage et autorisation d’assumer les conséquences du risque, en tenant compte des mesures
de réduction, selon les principes de délégation en vigueur.
Afin d’assumer sa responsabilité la direction doit avoir conscience des
risques encourus et des risques résiduels.
L’instance de décision locale doit réunir toutes les parties prenantes (un représentant de la direction,
les représentants Métier ou leur maîtrise d’ouvrage, les dépositaires des ressources, les tiers
subissant des impacts collatéraux…) afin d’évaluer le risque dans son ensemble.
Le Comité d’homologation doit assurer cette mission
L’Homologation, l’application de la norme ISO 27005

p 3
LA DÉLÉGATION
ET
LA
RESPONSABILITE
DU
REPRESENTANT
DE
LA PERSONNE
MORALE
Transfert ascendant : la responsabilité du commettant
• L’employeur est responsable du fait de ses salariés sur le fondement de l’article 1384
alinéa 5 du Code civil.
• L’employeur ne peut pas s’exonérer de cette responsabilité en établissant qu’il n’a commis aucune
faute; par contre il le peut s’il établit que le salarié a agi en dehors du cadre de ses fonctions, sans
autorisation, et à des fins étrangères à ses attributions.
• En revanche le salarié qui agit sans excéder les limites de sa mission ne peut être déclaré
responsable du dommage qu’il cause à autrui sur le fondement de l’article 1382 du Code civil (en
d’autres termes, la responsabilité civile du commettant est exclusive de celle du salarié).
La responsabilité du « chef d’entreprise »
• Responsabilité de fonction: le chef d’entreprise assume en cette qualité une responsabilité pénale
spéciale; Il est tenu de veiller à l’application et au contrôle des lois et règlements au sein de sa société; à
défaut il répond de son fait et aussi de celui d’autrui.
PÉNALE
CIVILE
L’Homologation, l’application de la loi sur la responsabilité du représentant de la personne morale

p 4
Les systèmes d’information qui entrent dans le champ de l’ordonnance du 8 décembre 2005 doivent faire l’objet, avant
leur mise en service opérationnelle, d’une décision d’homologation de sécurité, (Le Référentiel général de sécurité
(RGS) est créé par l’article 9 de l’ordonnance n° 2005-1516 du 8 décembre 2005 relative aux échanges électroniques
entre les usagers et les autorités administratives et entre les autorités administratives.
.
Egalement dénommée « attestation formelle » (art. 5, al. 1 du décret RGS),
elle est prononcée par une autorité d’homologation, désignée par la ou les autorités administratives chargées du SI
La décision d’homologation atteste, au nom de l’autorité administrative, que le télé
service est protégé conformément aux objectifs de sécurité fixés et que les risques
résiduels sont acceptés.
La décision d’homologation s’appuie sur un dossier d’homologation.
Lorsqu'elle concerne un télé service, cette décision est rendue accessible aux
usagers.
Il est recommandé que les systèmes d’information homologués fassent l’objet d’une revue périodique.
Homologation de sécurité du système d’information
Le Processus d’Homologation de sécurité du SI / RGS

p 5
L’objectif majeur du RGS est de donner la confiance aux usagers
dans leurs échanges avec l’Administration
• Favoriser l’adoption des bonnes pratiques en matière de sécurité des SI ;
• Mettre en œuvre des mesures adaptées aux besoins de sécurité ;
• Offrir des labels de sécurité ;
• Respecter la règlementation et plus particulièrement la loi informatique et libertés.
Le RGS encourage les Administrations à adopter : Le RGS définit des exigences techniques en termes de
fonctions de sécurité et d’offres de services de
confiance.
• une approche globale de la SSI ;
• une démarche de gestion du
risque basée sur l’analyse des
enjeux ;
• une démarche d’amélioration
continue tendant à mettre en place
un système de management de la
sécurité de l’information.
Une autorité administrative :
• déterminera les fonctions de sécurité et le
niveau de sécurité que doit remplir un système
d’information
• sélectionnera en rapport les exigences
techniques définies dans le RGS
• attestera auprès de ses
utilisateurs (homologation)
Objectifs du RGS
L’homologation du télé service et la confiance des usagers

p 6
Objectifs
L’homologation :La confiance des usagers
L’objectif premier du Référentiel Général de Sécurité est de donner :
La confiance aux usagers dans leurs échanges avec l’administration
Condition du développement de la e-administration
Les administrations
Les AA
Les prestataires Les produits
Homologation Qualification Qualification
Confiance des usagers
Notamment pour le respect des données à caractère personnel

p 7
Administrations de l’État
Les Ministères
Collectivités territoriales
Établissements publics à caractère administratif
Établissements gérant des régimes de protection
sociale relevant du Code de la sécurité sociale et du
code rural
Établissements mentionnés aux articles L 223-16 et
L 351-21 du Code du travail
Organismes chargés de la gestion d’un service public
Les autorités administratives qui mettent en œuvre
des systèmes d’information susceptibles d’échanger des informations
avec d’autres autorités administratives ou avec des usagers
Les Autorités Administratives
visées par l’ordonnance RGS
Les acteurs
Les autorités administratives concernées par le RGS et l’homologation

p 8
La démarche de l’homologation dans le RGS
Vision globale de la mise en conformité
Afin de mettre leur système d’information en conformité avec le RGS, les autorités
administratives doivent adopter une démarche en cinq étapes, prévue par le décret n° 2010-112
du 2 février 2010 (décret RGS) :
1 Réalisation d’une analyse des risques (art. 3 al. 1) ;
2 Définition des objectifs de sécurité (art. 3 al. 2) ;
3 Choix et mise en œuvre des mesures appropriées de protection et de défense du SI (art. 3 al. 3) ;
4 Homologation de sécurité du système d’information (art. 5) ;
5 Suivi opérationnel de la sécurité du SI.

p 9
La démarche de l’homologation dans le RGS
Vision globale de la mise en conformité pour les SI déjà en service
Dans l’éventualité où le système d’information serait déjà en service sans avoir fait l’objet de
cette démarche, ou bien a été modifié, la procédure simplifiée suivante peut être mise en
œuvre :
1 Réalisation d’un audit de la sécurité du système d’information en interne ou externalisé auprès d’un
prestataire
2 Réalisation d’une analyse des risques simplifiée
3 Mise en œuvre des mesures correctives fixées dans le rapport d’audit ;
4 Décision d’homologation de sécurité du système d’information ;
5 Suivi opérationnel de la sécurité du SI.

p 10
Décisions de mener un PIA Modifications de contexte
1.Contexte
1.1 Présentation
1.2 Description
Présentation des finalités,
des enjeux, des DCP, des
supports, …
2.Mesures
2.1 Mesures juridiques
2.2 Mesures traitant les risques
Présentation des finalités,
des informations aux
personnes, des droits des
personnes
Actions sur les DCP,
impacts, sources, supports
3.Risques
3.1 Sources
3.2 Evènements (Gravité) 3.3 Menaces (Vraisemblance)
3.4 Risques
4. Décisions
4.1 Evaluation
Non Oui
4.2 Objectifs 4.3 Plan d’actions
4.4 Validation
Les EIVP recommandées par la CNIL doivent être intégrées dans l’approche RGS
/homologation

p 11
Etapes de la méthode EIVP Responsable
du traitement
Maîtrise
d’Ouvrage
Maîtrise
d’Œuvre
CIL RSSI
1.1. Description générale Approuve Consultée Informée Réalise Informé
1.2. Description détaillée Approuve Consultée Informée Réalise Informé
2.1. Mesures de nature juridique Approuve Consultée Consultée Réalise Informé
2.2. Mesures traitant les risques Approuve Consultée Consultée Informé Réalise
3.1. Sources de risques Approuve Consultée Informée Informé Réalise
3.2. Événements redoutés Approuve Consultée Informée Réalise Consulté
3.3. Menaces Approuve Informée Consultée Informé Réalise
3.4. Risques Approuve Informée Informée Réalise Consulté
4.1. Évaluation Approuve Informée Informée Réalise Consulté
4.2 Objectifs Approuve Consultée Consultée Réalise Informé
4.3 Plan d’actions Approuve Réalise Consultée Réalise Informé
4.4 Validation formelle Réalise Informée Informée Consulté Informé
Ces responsabilités peuvent être adaptées en fonction des contextes projet.
Le Processus d’Homologation de sécurité du SI traitant des
DCP / EIVP

p 12
Définition de la
stratégie
d’homologation
Étape n° 1 : Quel système d’information dois-je
homologuer et pourquoi ?
Définir le référentiel réglementaire applicable et délimiter le
périmètre du système à homologuer.
Étape n° 2 : Quel type de démarche dois-je mettre
en œuvre ?
Estimer les enjeux de sécurité du système et en déduire la
profondeur nécessaire de la démarche à mettre en œuvre.
Étape n° 3 : Qui contribue à la démarche ? Identifier les acteurs de l’homologation et leur rôle
(décisionnaire, assistance, expertise technique, etc.).
Étape n° 4 : Comment s’organise-t-on pour
recueillir et présenter les informations ?
Détailler le contenu du dossier d’homologation et définir le
planning.
Maîtrise des
risques
Étape n° 5 : Quels sont les risques pesant sur le
système ?
Analyser les risques pesant sur le système en fonction du
contexte et de la nature de l’organisme et fixer les objectifs
de sécurité.
Étape n° 6 : La réalité correspond-elle à l’analyse ? Mesurer l’écart entre les objectifs et la réalité.
Étape n° 7 : Quelles sont les mesures de sécurité
supplémentaires à mettre en œuvre pour couvrir
ces risques ?
Analyser et mettre en œuvre les mesures nécessaires à la
réduction des risques pesant sur le système d’information.
Identifier les risques résiduels.
Prise de
décision
Étape n° 8 : Comment réaliser la
décision d’homologation ?
Accepter les risques résiduels : l’autorité
d’homologation signe une attestation formelle
autorisant la mise en service du système
d’information, du point de vue de la sécurité.
Suivi a
posteriori
Étape n° 9 : Qu’est-il prévu pour maintenir la
sécurité et continuer de l’améliorer ?
Mettre en place une procédure de révision périodique de
l’homologation et un plan d’action pour traiter les risques
résiduels et les nouveaux risques qui apparaîtraient.

p 13
Dans tous les cas il y a plusieurs divergences d’analyse potentielles :
Les besoins d’arbitrage de suivi et de validation
L’arbitre ne pourra se prononcer avec raison que si les mesures peuvent être adossées à des
besoins, des enjeux ou a MINIMA À DES RISQUES METIERS « validés par
l’AH»
Exemples de Besoin d’arbitrage Arbitre
Divergence d’estimation sur les besoins de Disponibilité, Intégrité,
Confidentialité et Preuve
Comité de pilotage SSI / IL
Divergence d’estimation sur les conséquences des risques pour
les métiers
Entre la maîtrise d’ouvrage en charge du projet et la maîtrise
d’œuvre, voir la SSI sur les mesures ou les solutions techniques
Entre la MOA, la Maitrise d’œuvre d’une part et la SSI d’autre part
sur les mesures ou les solutions techniques
Entre SSI et DSI Comité de pilotage SSI /IL
Validation par la DG des risques résiduels AH

p 14
Le périmètre du système d’information à homologuer doit comporter tous les
éléments indispensables au fonctionnement du système.
La délimitation du périmètre ne doit comporter aucune ambiguïté, car elle permet de
déterminer et de caractériser précisément les systèmes qui seront homologués.
La description de ce périmètre comprend :
• des éléments fonctionnels et d’organisation : fonctionnalités du système, type d’utilisateurs,
contexte et règles d’emploi, procédures formalisées, conditions d’emploi des produits de sécurité, gestion des
droits, dispositifs de détection et de gestion des incidents ;
• des éléments techniques : architecture du système (en précisant notamment les interconnexions avec
d’autres systèmes), possibilité d’utilisation de supports amovibles, d’accès à distance ou de cloisonnement,
mécanismes de maintenance, d’exploitation ou de télégestion du système, notamment lorsque ces opérations
sont effectuées par des prestataires externes ;
• le périmètre géographique et physique : localisations géographiques et caractéristiques des
locaux.
Étape n° 1 : Quel système d’information dois-je homologuer et
pourquoi ?

p 15
Etude du contexte Question n° 1 : Votre système est-il important pour remplir vos missions ?
Classification de
la sensibilité des
DCP / Analyse des
besoins
Question n° 2 : Si un sinistre atteint votre SI, causant un dysfonctionnement ou une perte de données, les
conséquences en interne (pour vos services) seraient-elles graves ?
Question n° 3 : Si un sinistre touche la sécurité de votre système (il ne fonctionne plus ou pas bien, vol
d’informations…), les conséquences pour l’extérieur (pour vos usagers, administrés…) seraient-elles
graves ?
Question n° 4 : Le fait que les données de votre système soient inaccessibles est-il grave ?
Question n° 5 : Le fait que les données de votre système soient altérées est-il grave ?
Question n° 6 : Le fait que les données de votre système ne soient pas ou plus confidentielles est-il grave ?
Identification des
menaces types
Question n° 7 : Quel est le niveau de compétence maximal présumé de l’attaquant ou du groupe
d’attaquants susceptibles de porter atteinte au système ?
Question n° 8 : Quelle est la précision des attaques potentielles envers le SI ?
Question n° 9 : Quel est le niveau de sophistication des attaques potentielles contre le SI ?
Question n° 10 : Quelle est la visibilité des attaques potentielles contre le SI ?
Question n° 11 : Quelles sont la fréquence et la persistance des attaques potentielles contre le SI ?
Identification des
vulnérabilités
types
Question n° 12 : Quel est le niveau d’hétérogénéité du système ?
Question n° 13 : Quel est le degré d’ouverture/interconnexion du système ?
Question n° 14 : Le contexte dans lequel se trouve le SI et ses composants (matériels, logiciels, réseaux)
évolue-t-il régulièrement ?
Question n° 15 : Les composants du SI sont-ils mis régulièrement à jour ?
Étape n° 2 : Quel type de démarche dois-je mettre en œuvre ?

p 16
La démarche la plus adaptée à l’homologation du système doit être définie en fonction du contexte, du niveau de
complexité et de criticité du système, du niveau de sensibilité des données hébergées et du
niveau de maturité en matière de SSI de l’organisme qui met en œuvre l’homologation.
Types de DCP Catégories de DCP
DCP courantes Etat civil, identité, données d’identification
Vie personnelle (habitude de vie, situation familiale, hors données sensibles, très
sensibles ou dangereuses, …)
Informations d’ordre économique et financier (revenus, situation financière,
situation fiscale, ..)
Données de connexion (adresses IP, journaux d’évènements, …)
Données de localisation, (déplacements, données GPS ? GSM, …)
DCP sensibles Numéro de sécurité sociale (NIR)
Données biométriques
Données bancaires
DCP très sensibles au sens de la
loi
Opinions philosophiques, politiques, religieuses, syndicales, vie sexuelle,
données de santé, origine raciales ou ethniques, relatives à la santé ou la vie
sexuelle.

p 17
Besoin de sécurité / type d’approche
Faible Moyen Fort
Niveau SSI
de
l’organisme
Élémentaire Pianissimo : démarche
autonome a minima
Mezzo-Forte : démarche
assistée approfondie
Mezzo-Forte :
démarche assistée
approfondie
Moyen Pianissimo :
démarche autonome a
minima
Mezzo-Piano : démarche
autonome approfondie
Mezzo-Forte :
démarche assistée
approfondie
Avancé Pianissimo :
démarche autonome a
minima
Forte : Forte :

p 18
Étape n° 3 : Qui contribue à la démarche ?
L’autorité d’homologation (AH)
• L’autorité d’homologation est la personne physique qui, après instruction du dossier d’homologation,
prononce l’homologation de sécurité du SI c’est-à-dire prend la décision d’accepter les risques résiduels identifiés
sur le système.
• L’autorité d’homologation doit être désignée à un niveau hiérarchique suffisant pour assumer
toutes les responsabilités. Il est donc nécessaire que l’autorité d’homologation se situe à un
niveau de direction dans l’organisme.
• L’autorité d’homologation désigne un responsable du processus d’homologation, qui mènera le projet
d’homologation en son nom.
La commission d’homologation (CH)
La commission d’homologation assiste l’autorité d’homologation pour l’instruction de l’homologation et est chargée
de préparer la décision d’homologation.
Cette commission, réunit les responsables métier concernés par le service à homologuer et des experts techniques.
La commission d’homologation est chargée du suivi des plannings, de l’analyse de l’ensemble des documents
versés au dossier d’homologation. Elle se prononce sur la pertinence des livrables et peut les valider dans certains
cas.
MOA / RSSI / CIL / CPI / Responsable de l’exploitation / Prestataire

p 19
Étape n° 4 : Comment s’organise-t-on pour recueillir et présenter les
informations ?
Pianissimo Mezzo-Piano Mezzo Forte
Stratégie d’homologation Indispensable
Référentiel de sécurité Si existant
Document présentant les risques
identifiés et les objectifs de sécurité
Indispensable
Politique de sécurité des systèmes
d’information
Recommandé Fortement recommandé
Procédures d’exploitation sécurisée
du système
Indispensable
Journal de bord de l’homologation Recommandé Fortement recommandé
Certificats de qualification des
produits ou prestataires
Si existant
Résultats d’audits Si existant Recommandé Fortement recommandé
Liste des risques résiduels Indispensable
Décision d’homologation Indispensable

p 20
Étape n° 4 : Comment s’organise-t-on pour recueillir et présenter les
informations ?
Démarche
Pianissimo :
Tous les documents décrivant les procédures de sécurité en vigueur au sein de l’organisme
peuvent être intégrés au dossier, par exemple :
• la charte d’utilisation des postes informatiques ;
• les règles de contrôle d’accès physique et logique au système ;
• les clauses de sécurité des contrats de sous-traitance informatique.
Démarche
Mezzo-Piano
et Mezzo Forte
:
Les documents constitutifs du référentiel de sécurité de l’organisme peuvent être intégrés au
dossier. En particulier :
• la politique de sécurité des systèmes d’information (PSSI) de l’organisme ;
• la législation ou la réglementation particulière au contexte de l’organisme ;
• le dossier de sécurité des systèmes interconnectés au système à homologuer.
La PSSI, quand elle existe, est un document de référence pour l’homologation, car
elle contient des éléments stratégiques (périmètre du système, principaux besoins
de sécurité et origine des menaces), ainsi que les règles en vigueur au sein de
l’organisme.

p 21
Étape n° 5 : Quels sont les risques pesant sur le système ?
Démarche Pianissimo
Les enjeux de sécurité du système d’information sont limités et les besoins de sécurité sont faibles.
1. Partez de la liste des menaces courantes.
2. Écartez celles qui ne sont pas pertinentes dans le contexte du système d’information étudié ;
Pour chaque menace conservée, déterminez un ou plusieurs biens essentiels qui pourraient être
affectés.
3. Pour chaque lien identifié entre une menace et un bien essentiel, décrivez l’impact négatif sur la
disponibilité, l’intégrité ou la confidentialité de ce bien essentiel. Vous obtenez un scénario de
risque.
4. Hiérarchisez les scénarios de risque obtenus, en identifiant les plus probables et ceux dont
l’impact est le plus pénalisant.
5. Si un scénario de risque plausible aboutit à un impact très fort, cela signifie que le besoin de
sécurité évalué lors de la deuxième étape a été sous-évalué. Envisagez alors une démarche plus
complète, de type Mezzo-Piano ou Mezzo Forte.

p 22
Démarche Mezzo-Piano ou Mezzo-forte
Dans le cadre de la mise en œuvre d’une démarche Mezzo-Piano ou Mezzo- Forte, la mise en œuvre
d’une méthode d’analyse de risque éprouvée est très fortement recommandée. La méthode EBIOS
2010 est une méthode d’analyse de risque développée par l’ANSSI.
C’est la direction de l’entreprise ou l’autorité administrative, par exemple, qui
fournissent les informations sur les besoins de disponibilité ou de confidentialité du
système, ce qui permet d’identifier les objectifs de sécurité du système.
Pour la démarche Mezzo-Piano, le résultat de l’analyse (la FEROS) peut ensuite constituer un
élément du cahier des clauses techniques particulières d’un appel d’offres pour la réalisation ou la
mise en conformité du système à homologuer.
Les soumissionnaires doivent y répondre en indiquant de quelle manière ils proposent d’atteindre
les objectifs de sécurité identifiés par l’autorité d’homologation.

p 23
Identifier les mesures de sécurité
À l’issue de l’analyse de risque, il convient de définir les mesures de sécurité
permettant de couvrir les risques identifiés.
Ceux qui demeurent après l’application des mesures sont considérés comme des risques résiduels qui doivent
être acceptés dans le cadre de l’homologation.
Démarche
Pianissimo
Pour déterminer les mécanismes de sécurité à mettre en œuvre, vous pouvez également
vous référer à plusieurs documents publiés par l’ANSSI (sur http://www.ssi.gouv.fr) :
• le guide des 40 règles d’hygiène informatique ;
• le guide d’externalisation pour les systèmes d’information ;
• le guide sur la virtualisation ;
• les notes techniques, notamment celle sur la sécurité web.
Démarche Mezzo-
Piano et Mezzo-
Forte
Dans le cadre d’une démarche Mezzo-Piano et Mezzo Forte, les objectifs de
sécurité identifiés au cours de l’analyse de risque selon la méthode EBIOS
permettront de définir les mesures de sécurité destinées à couvrir les risques
considérés comme inacceptables.
Outre les documents présentés dans le paragraphe précédent, de nombreux référentiels
de sécurité proposent des catalogues de mesures.

p 24
Étape n° 6 : La réalité correspond-elle à l’analyse ?
Durant la sixième étape, vous devez mesurer l’écart entre les résultats de l’étude de risque et la
réalité, en réalisant un contrôle plus ou moins formalisé du système.
Ce contrôle peut intervenir à tout moment du cycle de vie du système : en amont, avant la mise en
service voir au cours de la conception, mais également en aval, si le système est déjà opérationnel.
Démarche
Pianissimo
Pour la démarche Pianissimo, un audit technique est optionnel.
Démarche Mezzo-
forte
Pour la démarche Mezzo-Forte, il est fortement recommandé
d’effectuer un audit technique du système d’information. Cet audit
permettra de mettre en évidence d’éventuelles failles et d’identifier
rapidement les risques encourus par l’organisme.
Conséquences de l’audit sur le dossier d’homologation
Le contrôle de sécurité doit faire l’objet d’une trace écrite. A fortiori, s’il s’agit d’un audit de
sécurité, celui-ci doit faire l’objet d’un rapport, qui doit faire apparaître :
• une évolution des menaces sur le système ;
• la découverte éventuelle de nouvelles vulnérabilités ;
• la préconisation de mesures correctrices, le cas échéant.
Le rapport d’audit est intégré au dossier d’homologation, qui doit être complété en
tenant compte des nouveaux risques mis en lumière.

p 25
Étape n° 7 : Quelles sont les mesures de sécurité supplémentaires
à mettre en œuvre pour couvrir ces risques ?
Le traitement du risque
Au vu des résultats de l’analyse de risques et du contrôle de sécurité, l’autorité d’homologation se prononce sur
l’ensemble des risques qui ne sont pas, à ce stade, complètement couverts par des mesures de sécurité. Il convient
ainsi, pour tout ou partie de chaque risque de choisir parmi les options suivantes :
• l’éviter : changer le contexte de telle sorte qu’on n’y soit plus exposé ;
• le réduire : prendre des mesures de sécurité pour diminuer l’impact et/ou la vraisemblance ;
• l’assumer : en supporter les conséquences éventuelles sans prendre de mesure de sécurité
supplémentaire ;
• le transférer : partager les pertes occasionnées par un sinistre ou faire assumer la responsabilité
à un tiers.
La mise en œuvre de mesures de sécurité
Les mesures de sécurité peuvent être de nature technique, organisationnelle ou juridique. Elles sont
décidées par l’autorité d’homologation sur proposition de la commission d’homologation.
Définition du plan d’action
Les risques résiduels identifiés lors du contrôle et de l’analyse de risques et qui ne peuvent pas être couverts par
des mesures techniques ou organisationnelles sont identifiés dans un plan d’action. Ce dernier indique les
vulnérabilités éventuelles, leur degré (critique, majeure, mineure…), l’action correctrice envisagée,
le pilote désigné, ainsi que l’échéance associée.

p 26
L’expression des objectifs de sécurité permet d’apprécier les fonctions de sécurité qui peuvent être mises en œuvre
pour les atteindre (art. 3, al. 3 du décret RGS).
Ces fonctions de sécurité sont matérialisées par le choix de moyens et de mesures de nature :
Choix et mise en œuvre des mesures de sécurité adaptées
Technique :
• produits de sécurité (matériels ou
• logiciels),
• prestations de services de confiance
informatiques ou autres
• dispositifs de sécurité (blindage,
détecteur d’intrusion...)
Organisationnelle :
• organisation des responsabilités
habilitation du personnel,
• contrôle des accès,
• protection physique des éléments
sensibles...),
• gestion des ressources humaines
(affectation d’agents responsables de la
gestion du système d’information,
• formation du personnel spécialisé,
sensibilisation des utilisateurs).
Ces mesures de sécurité peuvent être sélectionnées au sein des référentiels et normes existants.
Elles peuvent également en être adaptées ou bien être créées ex nihilo.

p 27
L’ISO 27001 dispose d’une annexe A listant les mesures
ISO 27001
Objectifs à atteindre
•Responsabilités du Management
•Audit Interne
•SMSI
•Action corrective et préventive
Annexe A
ISO 27002 : 2005
• Politique et Organisation
• Classification et ctl des ressources
• Gestion des personnes
• Sécurité physique du SI
• Gestion des communications et des opérations
• Contrôle d’accès
• Développement et maintenance des systèmes
• Gestion des incidents
• Continuité
• Conformité
ISO 27002: 2013
Politique de sécurité de l’information (5)
Organisation de la sécurité de l’information (6)
Sécurité liée aux Ressources Humaines (7)
Gestion des actifs (8)
Contrôle d’accès (9)
Cryptographie (10)
Sécurité Physique et environnementale (11)
Sécurité liée à l’exploitation (12)
Sécurité des communications (13)
Acquisition, développement et maintenance des systèmes (14)
Relations avec les fournisseurs (15)
Gestion des incidents liés à la sécurité de l’information (16)
Gestion du Plan de continuité d’activités (17)
Conformité (18)

p 28
Voie
Hiérarchique
Voies
Fonctionnelles
Sécurité SSI
Protection des
DCP
Managers
Direction Générale
RSSI - CIL
Comité de pilotage, arbitrage et
homologation
Relais SSI - CIL

p 29
Voie
Hiérarchique
LES BONNES PRATIQUES DE MANAGEMENT POUR LA SECURITE DES
TRAITEMENTS DE DCP
1. Identifier les obligations légales et les responsabilités
2. Faire classifier les biens informationnels
3. Identifier les menaces et les risques / traiter les risques / accepter les risques
résiduels
4. Demander du conseil pour arbitrage
5. Faire remonter les incidents
6. Participer à la gestion de crise et PCA
7. Respecter les pratiques de management pour la SSI
8. Participer au rappel des obligations, des règles et bonnes pratiques
9. Respecter les procédures demande de dérogation
10.Contrôler
Responsables
hiérarchiques
Métier

p 30
Mettre en œuvre les bonnes pratiques pour être en conformité avec la loi Informatique et libertés
Les mesures
2.Mesures sur les éléments à
contrôler
Essentiellement juridique
3.Mesures sur les sources de
risques
Limiter les menaces sources de
risques
4.Mesures sur les supports Limiter les vulnérabilités pouvant
être exploitées par les menaces
5.Mesures sur les impacts Réduire les dommages
1.
Actions
transverses
Organiser
Et formaliser

p 31
Au-delà des mesures techniques et organisationnelles, les autorités administratives doivent
veiller :
Aux clauses relatives à la sécurité des
contrats
qu’elles passent avec des prestataires chargés de
les assister dans leur démarche de sécurisation de
leurs systèmes.
Ces services peuvent être de nature intellectuelle
(audit de la sécurité du système d’information,
traitement d’incident de sécurité, notamment) ou
technique (mécanisme de détection,
externalisation, infogérance, mise dans le nuage de
tout ou partie du système d’information, tierce
maintenance applicative, etc.) ;
Au facteur humain : la sensibilisation du
personnel
aux questions de sécurité est primordiale, ainsi que
la formation de ceux qui interviennent plus
spécifiquement dans la mise en œuvre et le suivi
opérationnel de la sécurité du système
d’information (surveillance, détection, prévention).

p 32
Le respect d'un référentiel de sécurité sous la forme d’un PAS validé par la fonction SSI
L’application des obligations légales
L'auditabilité :
Le client doit pouvoir régulièrement réaliser des audits sur tout ou partie des éléments composant le service mis en
externalisation.
Ce droit de regard doit pouvoir être réalisé par la société cliente elle-même ou par un tiers désigné par le client.
La réversibilité :
En cas de fin de contrat, soit normale parce que le contrat est arrivé à terme, soit anticipée, parce que de graves
dysfonctionnements ont été constatés, une clause de réversibilité doit être établie pour la transmettre à un autre
prestataire.
Le maintien de la propriété du client sur :
- tous les logiciels ou matériels dont le client a payé les licences (hors cas de location des applications)
- tous les développements effectués spécifiquement pour le compte du client et qu’il a payé
- toutes les procédures manuelles ou électroniques liées à l'exécution du service
- toutes les documentations produites spécifiquement par le prestataire dans le cadre de l'exécution du service.

p 33
La protection contre les actions en contrefaçon
La formation à la sécurité du personnel du prestataire
La confidentialité du contrat et de ses annexes
et de tous les documents, informations et données, quel qu'en soit le support, que les parties échangent à
l'occasion de l'exécution du contrat.
Le suivi du contrat de service avec des indicateurs précis
L'obligation de conseil
d'information et de recommandation du prestataire en terme de qualité de service et mise à l'état de l'art, si elle
est prévue.

p 34
L’ensemble des agents d’une autorité administrative, et le cas échant les contractants et les utilisateurs tiers,
doivent suivre une formation adaptée sur la sensibilisation et recevoir régulièrement les mises à jour des politiques
et des procédures qui concernent leurs missions
Informer et sensibiliser la direction et le personnel
NE PAS CONFONDRE SENSIBILISATION / COMMUNICATION / FORMATION / CONTRÔLE
Tronc commun obligatoire et récurrent / Utilisateur et nomades
Comité de Direction
Directions métiers
Management intermédiaire
Acheteurs
Chefs de projet MOA Chefs de projet MOE
Administrateurs SI

p 35
Le premier risque n’est pas la malveillance, mais bien l’erreur, essentiellement causée par la
méconnaissance des règles. Les malveillants utilisent toujours la méconnaissance des victimes
La sécurité ne peut se résumer à la protection de la confidentialité.
La sécurité est avant tout liée au facteur humain et non pas à la technologie, (certes nécessaire).
Les équipes techniques et sécurité ne peuvent définir les besoins, elles ne peuvent que définir les
moyens et les règles.
Le contrôle n’est pas obligatoirement une atteinte aux libertés fondamentales.
La sécurité n’est pas une science exacte, elle est donc susceptible d’être arbitrée.
Le but de la sensibilisation / responsabilisation n’est pas d’éliminer tous les risques, mais de les
identifier et de rappeler les règles et bonnes pratiques recommandées par l’Etat et l’AA pour les limiter.
L’homologation
de la sécurité
La responsabilisation n’est pas mise en avant pour cacher un déficit de moyens technologiques.
Ce n’est pas la sécurité qui empêche de travailler, c’est l’absence de sécurité qui empêche de travailler

p 36
Les mesures de protection d’un système d’information doivent être accompagnées
d’un suivi opérationnel quotidien ainsi que de mesures de surveillance et de détection,
afin de réagir au plus vite aux incidents de sécurité et de les traiter au mieux.
Suivi opérationnel de la sécurité du système d’information
Le suivi opérationnel consiste à
• collecter
• analyser les journaux d’évènements et les alarmes,
• mener des audits réguliers,
• appliquer des mesures correctives après un audit ou un incident,
• mettre en œuvre une chaîne d’alerte en cas d’intrusion supposée ou avérée sur le système,
• gérer les droits d’accès des utilisateurs,
• assurer une veille sur les menaces et les vulnérabilités,
• entretenir des plans de continuité et de reprise d’activité,
• sensibiliser le personnel
• gérer les crises lorsqu’elles surviennent.

p 37
4. Maximal
3. Important
2. Limitée
1. Négligeable
Cartographie
des risques
1. Négligeable 2. Limitée 3. Important 4. Maximal
Accès
illégitime
aux DCP
Un schéma tel que ci-dessous peut être utilisé pour présenter la cartographie des risques
Accès
illégitime
aux DCP
Étape n° 8 : Comment réaliser la décision d’homologation ?

p 38
La décision d’homologation est l’acte par lequel le responsable de l’autorité administrative atteste de
l’existence d’une analyse de sécurité et de sa prise en compte.
Les conditions
accompagnant
l’homologation
L’autorité d’homologation peut, en fonction des risques résiduels identifiés,
assortir l’homologation de conditions d’exploitation ainsi que d’un plan d’action
visant à maintenir et à améliorer le niveau de sécurité du système dans le temps.
À chaque action, ce plan associe une personne pilote ainsi qu’une échéance.
La durée de
l’homologation L’homologation doit être décidée pour une durée maximale.
Pour un système bien maîtrisé, avec peu de risques résiduels et ne présentant pas
de difficultés particulières, il est recommandé de prononcer une homologation
d’une durée maximale de cinq (5) ans, avec revue annuelle.
Cette durée maximale doit être réduite à trois (3) ans pour un système
avec de nombreux risques résiduels ou
à un an (1) pour un système présentant de nombreux risques résiduels.

p 39
Conditions de suspension ou de retrait de l’homologation
L’homologation de sécurité ne demeure valide que tant que le système d’information est exploité dans le contexte
décrit dans le dossier d’homologation.
• raccordement d’un nouveau site sur le système d’information ;
• ajout d’une fonctionnalité majeure ;
• succession de modifications mineures ;
• réduction de l’effectif affecté à une tâche impactant la sécurité ;
• changement d’un ou de plusieurs prestataires ;
• prise de fonction d’une nouvelle autorité d’homologation ;
• non-respect d’au moins une des conditions de l’homologation ;
• changement du niveau de sensibilité des informations traitées et, plus généralement, du niveau du risque ;
• évolution du statut de l’homologation des systèmes interconnectés ;
• publication d’incidents de nature à remettre en cause les garanties recueillies dans le dossier de sécurité ;
• décision de l’autorité d’homologation.
À ce titre, il est recommandé que la commission d’homologation soit réunie
annuellement par l’autorité d’homologation, afin de procéder à une revue du
respect des conditions de l’homologation.

p 40
Étape n° 9 : Qu’est-il prévu pour maintenir la sécurité et continuer de
l’améliorer ?
Suivi de l’homologation
La commission d’homologation réalise annuellement un suivi de l’homologation. Elle doit donc rester simple et
se limiter à une mise à jour du dossier et à une analyse succincte des évolutions et des incidents intervenus au cours
de l’année, afin de juger de l’opportunité d’une révision plus approfondie de l’homologation.
Maintien en conditions de sécurité
Il est nécessaire que les conditions de l’homologation soient respectées dans le temps. À ce titre,
l’entité en charge du maintien du dossier d’homologation doit également assurer une veille
technologique.
Il est également nécessaire de vérifier :
• les clauses de sécurité et de maintien en conditions de sécurité du système,
• les capacités d’évolution et d’interopérabilité de son système, notamment au regard de ses
capacités de développement ou de ses contrats de prestations de service.

p 41
Organisation
• Lois
• Formations
• Méthodes
• Procédures
• Directives
• Contrôles
• Sanctions
• Technologies
Engagement de
responsabilité :
• Personne morale et PJR*
• Directions
• Chefs de services
• Administrateurs
• Personnels
• Partenaires
• Sous-traitants
Relativité des contextes
Valeurs et Enjeux
• Potentialités
• Impacts
• Relativité des règles
Conclusion
L’homologation nécessite l’appropriation par tous les acteurs concernés de trois idées piliers
*PJR personne Juridiquement Responsable

Université AFCDP des CIL 2016 : Denis Virole anime l’atelier « L’homologation de la sécurité des traitements de données à caractère personnel »

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Université AFCDP des CIL 2016 : Denis Virole anime l’atelier « L’homologation de la sécurité des traitements de données à caractère personnel »

Similaire à Université AFCDP des CIL 2016 : Denis Virole anime l’atelier « L’homologation de la sécurité des traitements de données à caractère personnel » (20)

Université AFCDP des CIL 2016 : Denis Virole anime l’atelier « L’homologation de la sécurité des traitements de données à caractère personnel »