université afcdp des cil 2016 : denis virole anime l’atelier « l’homologation de la sécurité...

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 [email protected]

M. Thierry RAMARD Dirigeant

+33 (0) 6 17 64 90 72 [email protected]

Mme Caroline MEOT Responsable Commerciale

+33 (0) 6 46 13 00 19 [email protected]

L'ho

mol

ogat

ion

de la

séc

urité

des

don

nées

à c

arac

tère

per

sonn

el

mailto:[email protected]







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.

http://fr.wikipedia.org/wiki/Fichier:Logo_de_la_R%C3%A9publique_fran%C3%A7aise_(1999).svg



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



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

Le Processus d’Homologation de sécurité du SI L’Homologation, l’application de la loi sur la responsabilité du représentant de la personne morale



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



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



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



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



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.



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.



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



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



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.




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




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 ?



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 ?





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.




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


Moyen Pianissimo : démarche autonome a minima

Mezzo-Piano : démarche autonome approfondie


Avancé Pianissimo : démarche autonome a minima

Forte : Forte :



É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




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




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.




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.




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.




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.



É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.




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.



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.




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)




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


http://www.ssi.gouv.fr/



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




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




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).




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.




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.




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


http://www.ssi.gouv.fr/



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




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.




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





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.



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.



É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.



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é...

Technology