L’analyse de l’actualité ne cesse de nous alerter sur la très faible prise en compte de la sécurité native dans un grand nombre de projets et plus particulièrement sur la sous-estimation de l’intégration des exigences de protection de la vie privée.
Les articles 25 du RGPD « Protection des données dès la conception et protection des données par défaut » et 32 « Sécurité du traitement », formalisent l’obligation pour le responsable du traitement de prendre en compte les exigences juridiques et techniques pendant toutes les phases des projets de la conception jusqu’à la fin de vie du système cible. Nous nous attacherons à identifier les principaux acteurs concernés et leurs modes de concertation dans les gestions de projets en V ou Agile. Nous chercherons à souligner les points d’attention et d’amélioration dans les deux méthodes.
1. La prise en compte des principes fondateurs de protection de la vie privée
Le RGPD impose l'intégration de mesures techniques et organisationnelles appropriées pour garantir la prise en compte des exigences de protection de la vie privée. Afin d'être en mesure d’en démontrer le respect, le responsable du traitement devrait adopter des règles internes et mettre en œuvre des mesures qui sont conformes aux principes de protection des données par défaut, et ce dès la conception.
Ces mesures consécutives et complémentaires aux principes fondateurs présentés dans l’article 5 (« Principes relatifs au traitement des données à caractère personnel ») doivent permettre de garantir la disponibilité, l’intégrité et confidentialité et le contrôle par la personne concernée des traitements de données ainsi que le respect de ces droits.
La mise en conformité de tout système d’information exige l’implication puis l’engagement du responsable du traitement pour prendre en compte nativement la sécurité du système d’information et la protection de la vie privée dans tout projet. Cet engagement de responsabilité se doit d’être décliné par tous les acteurs du projet et dans toutes ses étapes, de la conception à la fin de vie.
2. Les acteurs vie privée et SSI dans le projet
2.1 Le responsable de traitement pour les traitements de données à caractère personnel et l’autorité qualifiée pour la SSI
Conformément au RGPD, le « responsable du traitement », est la personne physique ou morale, l'autorité publique, le service ou un autre organisme qui, seul ou conjointement avec d'autres, détermine les finalités et les moyens du traitement. Il constitue l’acteur principal puisque c’est sur lui que porte la responsabilité de la validation et de l’acceptabilité du projet. Dans un contexte purement SSI, la cohérence est totale : il s’agit bien de la direction générale qui est aussi responsable de la conformité juridique des traitements et de la validation et de l’acceptabilité des risques résiduels pour l’organisme et pour la vie privée des personnes concernées.
2.1.1 Les métiers, le RSSI et le Délégué à la Protection des Données
Dans une approche mature de la sécurité et de la conformité, ils doivent conseiller le responsable du traitement sur les exigences juridiques et le système de gradation des besoins métiers. L’expression des besoins métiers relève, bien évidemment, des métiers. Les besoins sont classiquement évalués par les impacts des évènements redoutés. Le RSSI assiste les métiers et la direction générale pour l’identification des risques (opérationnels, voire juridiques hors RGPD) pour l’organisme. Le DPD assiste la direction générale et les directions métiers déléguées pour la mise en cohérence des besoins de protection de la vie privée en conformité avec le règlement et le système de gradation SSI.
Le RSSI est en charge de la formalisation des règles fonctionnelles SSI consécutives aux besoins et aux risques. Ces dernières doivent être intégrées par le chef de projet informatique dans l’architecture cible. Afin de respecter les exigences de séparation des pouvoirs, la mise en œuvre des règles dans le projet n’est pas du ressort du RSSI, mais bien de la maîtrise d’œuvre, classiquement représentée par le chef de projet informatique. Le contrôle de l’intégration des règles SSI dans le projet revient au RSSI. La validation des risques résiduels pour l’entreprise ou l’organisme reste bien sûr du ressort de la direction générale, responsable des traitements.
Le DPD assiste la direction métier ou sa maîtrise d'ouvrage ainsi que le maître d’œuvre afin de déterminer les événements redoutés, les principes du fondement juridique à identifier et respecter, les exigences de sécurité des données à caractère personnel et de protection de la vie privée. Il conseille le responsable du traitement sur la nécessité ou sur l’opportunité de conduire une Analyse d’Impact pour la Protection des Données (AIPD). La mise en place des traitements et donc la validation des risques pour la vie privée restent bien sûr sous l’autorité du responsable du traitement. Le DPD est donc chargé de contrôler la bonne conduite du volet « protection de la vie privée » dans le projet, afin d’être en mesure de démontrer la conformité du traitement et la protection de la vie privée de la personne concernée.
Ni le RSSI ni le DPD ne portent de responsabilité juridique pour la personne morale de l’organisme au regard d’une non-conformité juridique ou de dommages consécutifs à des risques SSI ou vie privée.
2.1.2 Les chefs de projet informatique
Le chef de projet informatique est en charge de prévoir la prise en compte de la sécurité dans un nouveau système d’information afin d’identifier et formaliser, sur indication de la direction métier ou de sa maîtrise d’ouvrage, les besoins et objectifs généraux de sécurité. Il doit alors affiner les objectifs de sécurité et identifier le niveau de risque maximum que la direction métier ou sa maîtrise d’ouvrage se déclare prête à accepter.
Lors de la réalisation du système, il doit décrire concrètement les mesures de sécurité et la manière de les appliquer dans l’environnement effectif d’utilisation.
À la fin de la phase de développement et au plus tard avant la phase d’exploitation, il fait prononcer la décision de validation et d’acceptation des risques résiduels. Le RSSI et le DPD donnent un avis : « favorable / favorable avec réserve / défavorable ». La décision finale relève de la direction générale.
Le chef de projet informatique, en collaboration avec la direction métier déléguée par la direction générale ou sa maîtrise d’ouvrage, constitue le dossier de sécurité du projet informatique qui sera soumis à la direction responsable permettant de valider les risques résiduels pour l’organisme et la personne concernée.
2.2 Le besoin de concertation entre les acteurs
Aucun acteur ne peut conduire à lui tout seul la démarche. L’expérience acquise depuis de nombreuses années pour l’expression des besoins fonctionnels, comme pour la réduction des risques opérationnels et juridiques pour l’organisme et la gestion des développements montre clairement la nécessité de structurer les étapes, la concertation des acteurs et leurs responsabilités.
Les deux grands types de méthode en V ou Agile ont pour objectif d’organiser cette concertation et les responsabilités.
Le choix de la méthode en V ou Agile apparaît comme une réponse pour pouvoir moduler les actions selon les enjeux réels (délais, coûts, niveaux d’impact des évènements redoutés) du système d’information vis-à-vis de l'organisme et pour la personne concernée.
3. Les méthodes en V et Agile pour l’intégration de la sécurité dans les projets
3.1 L’approche en V pour la SSI et la protection de la vie privée
L’approche en V d'intégration de la sécurité système d’information dans les projets présente une méthode structurée qui décrit l'ensemble des actions sécurité système d’information à mener depuis l'étude d'opportunité d'un projet jusqu'à la fin de vie du système.
Elle repose sur la proposition d'un cycle de vie et de rôles et responsabilités qu'il convient de transposer à son propre contexte.
La démarche doit donc mettre en évidence le rapprochement entre la gestion des risques sécurité pour l’organisme et pour la protection de la vie privée de la personne concernée.
Étape 1 : étude d'opportunité
L'étude d'opportunité vise à définir le cadre potentiel du projet et son intérêt pour l'organisme : analyse et hiérarchisation des enjeux, analyse des freins et des leviers (organisation, technologie, culture et motivation), identification et évaluation des ressources internes et externes à mettre en œuvre, estimation du retour sur investissement.
Dans le domaine de la sécurité comme pour le traitement des données à caractère personnel, cette étape est fondamentale, elle conditionne toute la suite du projet, car c'est à ce moment que sont évalués les grands enjeux relatifs à la sécurité du système d’information et au respect de la vie privée du projet et donc l'investissement consenti pour gérer les risques.
Pour la conformité au RGPD, cette étape doit permettre d’identifier si le projet vise à mettre en œuvre ou améliorer un traitement de données à caractère personnel. Il est important de souligner que la prise en compte de la vie privée ne doit pas être ressentie comme une contrainte freinant l’activité, mais au contraire comme un indicateur de qualité de service et de différentiation commerciale.
Dans le cas où le projet ne traite pas de données à caractère personnel, le chef de projet avec le RSSI suivent la méthode dans une approche « pure » SSI.
Dans le cas où le projet est soumis aux exigences du RGPD, il est obligatoire d’impliquer le DPD et le RSSI pour appliquer la démarche « Privacy By Design » dans le projet géré en V.
Étape 2 : étude de faisabilité
Elle vise à analyser la faisabilité économique, organisationnelle et technique du projet. On s'interrogera notamment sur la faisabilité du projet en termes de produits éprouvés, rendement, ressources, compétences, capacité, financement, pérennité et risques induits.
Elle permet de préciser les éléments stratégiques, les exigences juridiques, calendaires et financières.
Du point de vue des exigences du RGPD, il convient d’identifier si le traitement de données présente des risques élevés pour les droits et les libertés des personnes concernées. La CNIL a précisé dans une liste détaillée les principes du Comité Européen pour la Protection des Données.
Dans les cas où peu de risques élevés pour les personnes concernées sont identifiés, il convient d’appliquer les principes de « Privacy By Default » : la licéité et la finalité des traitements, le respect des droits des personnes, la purge de données, la limitation des données, la minimisation et la qualité des données, la sécurité « de base » des données notamment en matière d’habilitations, de moindres privilèges et de séparation des pouvoirs y compris pour les données à caractère personnel dites courantes. En effet, l’accès aux données courantes ne peut qu’être restreint aux strictes personnes en ayant besoin pour réaliser le traitement.
Les éléments nécessaires à l'expression des besoins de sécurité doivent être formalisés. Il convient notamment de déterminer les impacts redoutés par l'organisme ainsi que pour la personne concernée et une échelle de besoins (en termes de disponibilité, d'intégrité, de confidentialité…).
Dans le cas des traitements susceptibles de présenter des risques élevés pour les personnes concernées, il est obligatoire pour l’organisme, et en plus de l’analyse des risques de sécurité, de faire une Analyse d’Impact relative à la Protection des Données (AIPD).
Elle doit être réalisée de manière conjointe. Elle est menée à l'aide d'un entretien avec, si possible, le directeur de l'organisme, les directions métiers concernées, le RSSI et le DPD et le directeur système d’information. Cette analyse consiste à apprécier rapidement les risques SSI et juridiques au regard de la protection de la vie privée. Il convient de commencer à dresser une liste d’exigences générales pesant sur l'organisme et de références réglementaires qui lui sont applicables.
Étape 3 : conception générale
Lors de la conception générale, on s'attachera à affiner l'expression de besoins fonctionnels et de sécurité pour l’organisme ainsi que pour la protection de la vie privée sans rechercher les solutions techniques.
Il faut donc déterminer les meilleures pratiques de sécurité et de protection de la vie privée que devra mettre en œuvre l’architecture cible.
Les organismes confrontés à des enjeux très forts de sécurité sont habitués à formaliser un premier cahier des charges sous la forme d'une fiche d'expression d’objectifs. Les traitements de données à enjeux ou risques forts sujets à l’obligation d’AIPD devront faire preuve du même formalisme pour la réduction des risques pour la vie privée, l’effectivité des droits de la personne concernée et les exigences sécurité liées au traitement.
Pour les enjeux faibles pour l’organisme ou pour la personne concernée, les recommandations et règles CNIL, ANSSI ou normatives ne manquent pas.
Il convient de mener cette étape en fonction du contexte de l'organisme, des exigences réglementaires consécutives au fondement juridique du traitement, des fonctionnalités du système et des entités qui le composeront (logiciels, matériels, réseaux, organisations, personnels et locaux), des référentiels de l'organisme (notamment sa politique de sécurité et sa politique de protection de la vie privée à usage interne).
Nous attirons l’attention du lecteur sur le niveau de granularité pour l’identification des vulnérabilités des composants du système d’information et sur la nécessité d’avoir un référentiel de sécurité et de protection de la vie privée adapté aux enjeux et à la structure de l’organisme (lire l’article MISC, « Comment concevoir son référentiel vie privée en cohérence avec le référentiel SSI ? » [1]).
Une estimation de l'impact de l'application des meilleures pratiques de sécurité et de protection de la vie privée doit être réalisée.
Pour les enjeux plus importants, la description du système est affinée à mesure que sa conception se précise, les éléments essentiels sont parfaitement identifiés, leurs besoins de sécurité exprimés, les vulnérabilités sont étudiées. Si l'état d'avancement de la conception le permet, les menaces sont rédigées et les risques sont déterminés afin d'identifier les objectifs de sécurité. La CNIL et l’ANSSI fournissent de nombreux guides pour suivre la méthode et atteindre ces objectifs.
Étape 4 : conception détaillée
À cette étape, la maîtrise d'œuvre est choisie, le travail est donc réalisé conjointement entre la maîtrise d'ouvrage et le chef de projet informatique dans l'objectif de décrire finement l'engagement des deux parties en termes de réalisation. Cette étape permet d'aboutir au cahier des clauses techniques particulières (CCTP). Un plan d’assurance sécurité, ou un « clausier » doivent être annexés au contrat lors de l’utilisation de sous-traitants.
L'étude de sécurité réalisée lors de ce travail de concertation doit être affinée, suivie, contrôlée et validée. La démarche AIPD suit la même logique.
Dans le cas où les risques résiduels pour la vie privée sont faibles, les mesures de nature juridique et technique validées par le DPD et le RSSI devront être intégrées au CCTP.
Dans le cas où les risques résiduels pour la vie privée sont élevés, une demande d’autorisation à la CNIL devra être faite puis, en cas d’autorisation, les mesures de nature juridique et technique validées par le DPD et le RSSI devront être intégrées au CCTP.
Étape 5 : réalisation
Cette étape comprend la réalisation des composantes du système d'information, c'est-à-dire le développement, l'intégration, la qualification et la recette. Les trois premières sont de la responsabilité du chef de projet informatique, sous contrôle du maître d'ouvrage. En revanche, la recette qui est la vérification de la conformité du projet par rapport à la demande formulée dans le dossier validé de conception générale, est non seulement du ressort de la maîtrise d'ouvrage, mais aussi du DPD pour la protection de la vie privée.
Pour la SSI, comme pour la protection de la vie privée, cette étape permet au chef de projet informatique de constituer la cible de sécurité, c'est-à-dire d'affiner les exigences de sécurité et d'expliciter la façon dont ces exigences doivent être mises en œuvre.
Le RSSI réalise les tests et audits de sécurité, le DPD valide la mise en œuvre des mesures de nature juridique, notamment sur l’effectivité des droits des personnes concernées et le respect des exigences consécutives au fondement juridique du traitement.
Étape 6 : exploitation
Cette étape comprend l'homologation du système d'information pour la SSI et la validation du « Private Impact Assessment » consécutif à l’AIPD, son déploiement, sa mise en œuvre en situation opérationnelle, ainsi que sa maintenance jusqu'à sa fin de vie.
Dans le domaine de la SSI, comme pour celui de la protection de la vie privée, cette étape permet d’homologuer ou de valider le système à la vue du dossier de sécurité du système ou suite éventuellement, à un audit de sécurité. Par ailleurs, durant la phase d'exploitation, pour des systèmes requérant un haut niveau de maturité, les différents intervenants alimenteront des tableaux de bord dont les indicateurs sont issus des objectifs de sécurité du système d’information et de protection de la vie privée.
Après l’homologation/validation du « Private Impact Assessment » par le responsable du traitement, le DPD doit ensuite inscrire le traitement dans le registre idoine.
3.2 L’approche Agile pour la sécurité du système d’information et la protection de la vie privée
Dans la démarche en V, la direction métier exprime les besoins de sécurité et les exigences de protection de la vie privée et le chef de projet informatique, assisté du RSSI et du DPD, définit les façons d’y répondre dès la phase de conception ; les mesures de sécurité étant très souvent définies et mises en œuvre pour le périmètre final et son cas d’usage à la cible.
Elle nécessite une maturité assez forte des différents acteurs dans le formalisme des textes réalisés à chaque étape. Ce formalisme ainsi que les échanges de concertation nécessaires à chaque étape entraînent des temps de réflexion assez longs et sont souvent vécus comme difficiles et contraignants.
Dans une démarche Agile, l’équipe cherche à livrer très tôt de la valeur à un public donné avec un produit incomplet, tout en cherchant à susciter l’adhésion d’autres publics en étoffant ce produit.
Pour l’équipe projet dont l’objectif est de livrer rapidement de la valeur à ses utilisateurs, une évaluation pertinente du risque est donc obtenue en considérant simultanément le nombre d’usagers et le risque encouru par chacun, pour déterminer une exposition globale au risque.
La prise en compte des enjeux de sécurité par une équipe Agile se veut continue (tout au long de la construction et de l’amélioration du service) et pragmatique puisqu’elle priorise les efforts en fonction du risque réel et assume l’existence de risques résiduels.
Le pragmatisme de l’approche conduit à des ateliers de travail organisés à intervalles réguliers, pour discuter des risques numériques qui peuvent impacter les usagers de son service ou produit et décider de la meilleure manière de traiter ces risques.
Un atelier type d’analyse de risque se déroule classiquement en présence de toute l’équipe et sur des durées fixes et limitées.
4. Les besoins de concertation SSI et vie privée des deux méthodes
Les deux méthodes doivent donc faciliter le dialogue entre d’une part la direction métier déléguée par le responsable du traitement ou sa maîtrise d’ouvrage et d’autre part, la maîtrise d’œuvre et le chef de projet informatique. Ce dialogue doit être encadré par l’expertise conjointe du RSSI et du DPD.
Le succès des ateliers et plus particulièrement celui de l’analyse de risque nécessite une grande coopération entre le RSSI et le DPD, afin qu’ils réussissent à tirer de la concertation, notamment auprès des métiers, les éléments clés concernant les exigences réglementaires, les impacts des événements redoutés pour les deux parties (organisme et personne concernée), les menaces, les vulnérabilités, les échelles de gestion de risques, les mesures de protection et sans oublier de mettre en œuvre les dispositifs permettant de répondre aux droits des personnes concernées.
Ils doivent assumer un rôle particulièrement important pour s’assurer que la prise de parole est répartie de façon équilibrée entre les différents participants. Une animation efficace suppose donc de bien maîtriser la communication et le canevas d’analyse de risque sécurité du système d’information et protection de la vie privée.
Le choix de l’approche en V ou Agile répond plus au besoin d’adaptabilité du projet aux contraintes contextuelles de l’organisme qu’au souci d’atteinte d’une cible de sécurité ou de protection de la vie privée.
Les deux méthodes se doivent d’intégrer la protection de la vie privée au même titre que la sécurité du système d’information.
La méthode en V permet facilement la formalisation d’une table RACI adaptée à chaque fonction et pour toutes les étapes.
Elle devra faire l’objet du même formalisme et de la même rigueur pour la protection de la vie privée que pour la sécurité du système d’information.
La concertation Agile réalisée sous forme d’ateliers d’échanges, organisés régulièrement entre les acteurs projets, est vécue comme plus légère et pragmatique. Mais elle ne doit pas sous-estimer la nécessité de s’adapter aux enjeux et aux risques. Une trop faible prise en compte des aspects sécurité implique généralement des risques résiduels qui peuvent s'avérer inacceptables pour l'organisme ou pour la personne concernée.
Nous alertons le lecteur sur un piège à éviter dans le contexte Agile. Les projets à enjeux forts qui ont été traités en mode Agile, doivent aussi faire l’objet de tableaux de bord de suivi et contrôle. Le mode opératoire des ateliers n’est pas forcément adapté au formalisme nécessaire de la gestion de tableaux de bord de niveaux stratégique, pilotage et opérationnel.
Les approches sécurité et protection de la vie privée doivent être complémentaires et mises en cohérence dans les deux méthodes.
L’identification des vulnérabilités liées aux différentes ressources du système cible est très comparable pour la sécurité du système d’information et pour la protection de la vie privée. Les vulnérabilités de l’OWASP sont pertinentes dans les deux cas.
Les mesures pour la protection de la vie privée doivent être proactives et non réactives. L’assurance de la protection implicite de la vie privée (« Privacy by Defaut »), l’intégration de la protection de la vie privée dans la conception des systèmes et des pratiques, s’inscrivent bien dans la logique les démarches en V ou Agile.
Plus que la différence d’approche entre les méthodes de gestion de projet en V ou Agile, nous attirons l’attention du lecteur sur la nécessité de cohérence entre les systèmes de gradation de la vraisemblance, de la gravité et du niveau du risque pour l’organisme et pour la personne concernée. La gradation proposée par la CNIL, notamment pour la définition des risques acceptables ou non acceptables est rarement en cohérence avec les tables de gestion de risques sécurité du système d’information pour l’organisme.
Une différence reste importante entre la sécurité du système d’information et la protection de la vie privée. Elle concerne la recommandation du RGPD de demander aux personnes concernées si les risques sont acceptables ou non pour leur vie privée.
Conclusion
Les deux méthodes V et Agile suivent donc la même logique. Seul le mode opératoire change. Il est classiquement déterminé par la hauteur des enjeux, la taille du projet voire les délais.
La méthode en V est souvent utilisée par des maîtres d’œuvre très compétents techniquement accompagnés de RSSI très avancés qui se chargent par le formalisme des textes et des échanges d’obtenir des métiers les expressions de besoins, les impacts des évènements redoutés et les menaces identifiées. Ils sont à même de définir les objectifs de sécurité.
La méthode Agile se veut plus pragmatique et plus rapide, malheureusement c’est souvent lors des ateliers que les métiers découvrent les exigences sécurité et réglementaires.
En fonction des types de projets et des enjeux associés, les deux méthodes ont leurs intérêts (rigueur et exhaustivité espérées dans le formalisme en V, pragmatisme et fluidité des échanges en Agile) et leurs limites (lourdeur et lenteur pour l’approche en V, superficialité pour la méthode Agile).
Cependant, les deux nécessitent en tout premier lieu de former les acteurs concernés par les projets. À ce titre, il s’agit de ne pas reproduire les erreurs du passé dans la sécurité du système d’information où seuls, dans le meilleur des cas, les chefs de projets informatiques ont été formés à la réduction des risques.
Il est fondamental d’intégrer les directions métiers et leurs maîtrises d'ouvrage dans ces plans de formations.
Pour la méthode en V qui suppose a priori un plus grand niveau de maturité des acteurs, l’enjeu est donc d’intégrer les AIPD dans les étapes du projet, ce qui entraîne un besoin de formation important auprès des directions métiers concernant les exigences consécutives au RGPD.
Pour la méthode Agile, l’effort doit être double. La rapidité de développement, le souci de réactivité et de pragmatisme dans le projet ne doivent pas conduire à une sous-estimation des exigences de conformité réglementaire et de réduction des risques pour l’organisme et pour la personne concernée. L’effort de formation doit permettre à chaque acteur concerné par les ateliers d’avoir une vision globale de la double problématique : sécurité pour l’organisme et protection de la vie privée pour la personne concernée.
Pour les organismes qui utilisent les deux méthodes, il est important de souligner que le besoin de formation se renforce pour expliquer les modes opératoires des deux méthodes et leurs vocabulaires respectifs.
Référence
