Blog

Le traitement par les entreprises et les institutions des données personnelles de leurs collaborateurs, de leurs clients/des citoyens et de leurs sous-traitants est un sujet de longue date. Avec l’entrée en application en mai 2018 du Règlement Général sur la Protection des Données (RGPD), ces traitements sont devenus, au-delà d’un sujet d’entreprise, un sujet sociétal, sensibilisant le grand public. Cela a été confirmé récemment avec la mise à disposition de l’application StopCovid qui, du fait notamment de son traitement de données de positionnement et de données médicales, a mobilisée l’opinion publique. Cinq grandes questions sont régulièrement revenues :

• Quelles seront les données qui seront utilisées ?
• Sont-elles bien toutes indispensables ?
• Sont-elles suffisamment sécurisées ? Anonymisées ?
• Qui y aura accès ?
• L’utilisation affichée est-elle la seule utilisation qui en sera faite ?

Dans ce contexte, voici quelques bonnes pratiques de gouvernance de sécurité de l’information* qui devraient s’appliquer à tout projet de développement applicatif, en particulier lorsque des données personnelles dites sensibles sont concernées. L’application de ces bonnes pratiques à chacune des 5 phases du projet concerné (l’initialisation, le cadrage et la définition du besoin, le design et le développement de l’application, son test et son déploiement) permettra de clarifier les réponses aux questions posées ci-dessus.

Phase d’initialisation

Identification des données et des traitements associés

Pour s’assurer que tous les projets traitant des données personnelles dites sensibles sont effectivement identifiés comme tels, la phase d’initialisation des projets devrait, quel que soit le projet, inclure une évaluation dédiée. Celle-ci peut prendre la forme d’un questionnaire, plus ou moins détaillé en fonction des organisations. Dans l’optique d’identification des projets traitant de données personnelles, ce questionnaire devra permettre à minima de répondre aux questions suivantes :

• Des données personnelles seront-elles traitées via l’application ?
• Des données personnelles dites sensibles seront-elles traitées via l’application ?
• Quels traitements seront appliqués à ces données ?

En intégrant ces questions dès la phase d’initialisation, il sera ainsi possible :

• D’identifier dès les prémices du projet, les besoins de sécurité applicables et les éventuelles exigences de sécurité des données associées à la règlementation en vigueur ;
• D’initier les registres de traitement associés.

Equipe projet et comitologie projet

Dans le cas où le projet concernerait des données personnelles dites sensibles, les fonctions suivantes devraient être intégrées à l’équipe projet :

• Le DPO (Data Protection Officer)
• Le RSSI (Responsable de la Sécurité des Systèmes d’Information)

Le processus de gestion de projet devrait par ailleurs inclure, tout au long de la vie du projet, des étapes de coordination et de validation incluant ces fonctions.

Contractualisation en cas de sous-traitance

En cas de sous-traitance sur tout ou partie du projet, il convient de contractualiser avec le(s) sous-traitant(s) avant le début des travaux, en incluant notamment :

• Un accord de confidentialité (éventuellement renforcé s’agissant de données personnelles dites sensibles) ;
• La définition des rôles et responsabilités en termes de sécurité de l’information ;
• Les règles de développement sécurisées et les règles de remontée d’information à l’organisation en cas d’incident de sécurité touchant le sous-traitant.

Quelques ressources

• https://www.cnil.fr/fr/definition/donnee-sensible
• https://www.cnil.fr/fr/cnil-direct/question/une-donnee-sensible-cest-quoi
• https://www.cnil.fr/fr/rgpd-points-de-vigilance
• https://www.ssi.gouv.fr/administration/management-du-risque/la-methode-ebios-risk-manager/

Phase de cadrage et de définition du besoin

Analyse des risques liés à la sécurité de l’information

En amont du développement de l’application, il est important de réaliser une analyse des risques liés à la sécurité de l’information. L’objectif est d’identifier les impacts en cas de perte de Confidentialité, de perte d’Intégrité ou de perte de Disponibilité de la donnée traitée versus la probabilité de survenance de ces évènements du fait notamment du contexte d’utilisation de l’application et de ses caractéristiques propres (une application Web sera par exemple plus exposée qu’une application hébergée et accessible en local uniquement).

Cette analyse pourra être plus ou moins formalisée selon les organisations, mais ses résultats devraient dans tous les cas être communiqués et débattus avec le sponsor du projet afin de placer la sécurité de la donnée au cœur du projet.

Cette analyse sera aussi l’un des éléments sur lesquels l’équipe projet pourra s’appuyer pour réaliser l’analyse coût/bénéfice des mesures de sécurité à mettre en œuvre. Il conviendra bien entendu de faire évoluer cette analyse tout au long du projet, en particulier en cas d’évolutions majeures.

Identification des données et des fonctionnalités

Au-delà d’identifier si des données personnelles seront traitées, il est par ailleurs nécessaire, en particulier lorsqu’il est question de données personnelles dites sensibles, de s’assurer que seules les données nécessaires et suffisantes au projet seront récoltées, stockées et traitées (application du principe du need-to-use).

Pour ce faire, il conviendrait d’identifier avec précision, par exemple au cours d’ateliers dédiés :

• Le besoin des utilisateurs sous-jacent au projet nécessitant l’utilisation de données personnelles ;
• Les données personnelles qui seront nécessaires pour y répondre (toute donnée non indispensable devra être exclue du périmètre) ;
• Les traitements qui seront appliquées aux données personnelles pour répondre au besoin des utilisateurs.

Le principe étant que, lors de la structuration de la base de données, le stockage des données personnelles, et en particulier des données dites sensibles, soit limité aux seules données identifiées. Et que, lors de la définition et de l’implémentation des fonctionnalités dans l’outil, seules les fonctionnalités identifiées comme nécessaires soient déployées.

A noter qu’il faudra tout de même anticiper la possibilité que d’autres données/traitements puissent, en fonction de l’évolution des besoins des utilisateurs, être intégrés dans le futur. L’application devra donc être structurée de façon à permettre ces éventuelles évolutions (comme par exemple l’intégration de nouveaux champs dans les bases de données).

Identification des mesures de sécurité

Les mesures de sécurité préalablement identifiées devraient, afin d’assurer un suivi de leur implémentation, être intégrées dans la définition du besoin et par la suite dans le cahier des charges associé en tant que fonctions de sécurité. Cela permettra d’en assurer le suivi sur l’ensemble du projet (dont notamment la phase de test) et de contrôler qu’elles sont effectivement implémentées.

Il faut aussi s’assurer à cette étape que :

• Les mesures de sécurité applicables à la sauvegarde et à l’archivage des données sont définies
• Les fonctionnalités permettant l’application des droits des personnes (droit à l’information, droit à l’opposition, droits d’accès et de rectification) sont intégrées dans le cahier des charges de l’application

Quelques ressources

• https://www.ssi.gouv.fr/administration/bonnes-pratiques/
• https://www.ssi.gouv.fr/administration/reglementation/rgpd-renforcer-la-securite-des-donnees-a-caractere-personnel/

Phase de design et de développement

Formation des équipes

Afin d’assurer l’application des bonnes pratiques de sécurité tout au long de la phase de design et de développement, les équipes en charge du design et du développement doivent être formées à la sécurité de l‘information sur leurs domaines d’expertise.

Suivi de l’implémentation des mesures

Lors de cette phase, il convient par ailleurs de suivre la bonne implémentation des mesures de sécurité identifiées et de mettre à jour, en fonction des évolutions du projet, l’analyse de risques initiée en début de projet. En cas de difficulté de mise en œuvre d’une mesure de sécurité, une analyse coût/bénéfice doit être réalisée et, dans le cas où la mise en œuvre ne serait pas pertinente, les mesures de remplacement à mettre en place doivent être identifiées et intégrées au cahier des charges.

Afin d’anticiper les éventuelles failles de sécurité de l’application, les actions suivantes peuvent être réalisées en parallèle :

• Une revue du design de l’application par un sachant ;
• Un audit de code sécurité qui permettra d’identifier les vulnérabilités présentes dans le code source ;
• Un scan de vulnérabilités qui permettra de détecter les vulnérabilités de l’application de façon semi-automatisée/automatisée.

Ressources

• Sécurité applicative en général
  • https://cwe.mitre.org/
• Sécurité Web en général
  • https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Testing_Guide_v4.pdf
  • https://owasp.org/www-project-api-security/
• Sécurité des Applications mobiles
  • https://owasp.org/www-project-mobile-security/

Phase de test

Le temps nécessaire au test des mesures de sécurité mises en œuvre ne devrait pas être négligé, en particulier lorsqu’il est question de données personnelles dites sensibles.

Cahiers de test

Le test des fonctions de sécurité de l’outil par les utilisateurs et administrateurs devrait faire partie intégrante des cahiers de test fonctionnels et techniques de l’application (par exemple : test des paramétrages mis en œuvre pour forcer la complexité des mots de passe). Ce qui devrait être par défaut le cas à partir du moment où les fonctions de sécurité attendues auront été effectivement intégrées à la définition du besoin.

Il faut par ailleurs s’assurer que les membres de l’équipe de test ne soient pas ceux qui auront développé l’application. Cela permettra plus d’impartialité et une meilleure prise de recul.

Audits complémentaires

Plusieurs audits complémentaires peuvent aussi être mis en œuvre – en tout ou partie – :

• Un audit de code orienté sécurité qui permettra d’identifier les vulnérabilités présentes dans le code source ;
• Un scan de vulnérabilités qui permettra de détecter les vulnérabilités de l’application de façon semi-automatisée/automatisée ;
• Un audit d’architecture qui permettra d’évaluer la sécurité globale de l’infrastructure associée à l’application ;
• Un audit de configuration qui permettra de confirmer que le paramétrage des solutions techniques et/ou équipements associés sont adaptés ;
• Un test d’intrusion qui permettra de simuler « manuellement » une attaque et d’identifier ainsi les potentiels scénarios d’intrusion.

Si les ressources en interne ne disposent pas des compétences nécessaires pour réaliser ce type d’audits, il pourrait faire appel à des prestataires d’audit de la sécurité des Systèmes d’Information qualifiés (voir en ressource le lien vers la liste des prestataires qualifiés PASSI).

Anonymisation/pseudonymisation des données de test

A noter que, lors de la création des jeux de test, il conviendra d’anonymiser/pseudonymiser les données personnelles, a fortiori des données personnelles dites sensibles. Deux raisons à cela :

• Les environnements de test sont la plupart du temps moins protégés que les environnements de production ;
• Les données de test sont accessibles en direct par de nombreux contributeurs (développeurs, testeurs, utilisateurs en formation, …).

Quelques ressources

• https://www.cnil.fr/fr/identifier-les-donnees-personnelles
• https://www.cnil.fr/fr/lanonymisation-de-donnees-personnelles
• https://www.ssi.gouv.fr/uploads/liste-produits-et-services-qualifies.pdf

Phase de déploiement

Mise à jour du registre de traitements de l’entreprise

En parallèle de la mise en production, le registre de traitements de l’entreprise doit être mis à jour afin d’intégrer le nouveau traitement associé. Le DPO (Data Protection Officer) doit par ailleurs s’assurer que l’ensemble des processus et procédures nécessaires à l’application des droits des personnes soient mis à jour/rédigés pour intégrer cette nouvelle application.

Sensibilisation des utilisateurs et contractualisation

Il faudra s’assurer que les utilisateurs de l’application :

• Ont signé un accord de confidentialité (éventuellement renforcé s’agissant de données personnelles dites sensibles) ;
• Sont sensibilisés de façon régulière – a minima annuellement – à la protection des données personnelles, en particulier des données personnelles dites sensibles, et à leurs obligations dans le cadre du Règlement Général sur la Protection des Données/RGPD).

Suivi des vulnérabilités

Un plan de suivi des vulnérabilités devra être défini par le RSSI (Responsable de la Sécurité des Systèmes d’Information) pour l’application. Celui-ci devra inclure :

• Une veille sécurité (inscription aux bulletins de sécurité et autres news spécialisées relatives aux composants constituant l’application afin d’être informé rapidement lors de la publication d’une faille majeure) ;
• Des scans de vulnérabilité à fréquence très régulière ;
• Des tests d’intrusion à fréquence régulière.

Contractualisation en cas de sous-traitance

De la même façon que pour les sous-traitants susceptibles d’intervenir dans le cadre du projet, la relation avec les sous-traitants susceptibles d’intervenir sur l’application ou ses composants une fois celle-ci déployée (maintenance, maintien en condition opérationnelle, hébergement…) doit être contractualisée, en incluant notamment :

• Un accord de confidentialité (éventuellement renforcé s’agissant de données personnelles dites sensibles) ;
• La définition des rôles et responsabilités en termes de sécurité de l’information ;
• Les règles de remontée d’information à l’organisation en cas d’incident de sécurité touchant le sous-traitant ;
• Les règles de veille de sécurité sur les composants dont ils assurent le suivi.

Quelques ressources

• https://www.cert.ssi.gouv.fr/
• https://www.microsoft.com/en-us/msrc/technical-security-notifications?rtc=1
• https://www.cvedetails.com/
• https://www.cybermalveillance.gouv.fr/tous-nos-contenus/actualites/comment-proteger-vos-donnees-en-sensibilisant-vos-collaborateurs

Pour aller plus loin…

• https://www.ssi.gouv.fr/guide/gissip-guide-dintegration-de-la-securite-des-systemes-dinformation-dans-les-projets/
• https://www.cnil.fr/sites/default/files/atoms/files/cnil_guide_securite_personnelle.pdf