L’intégration du « Privacy by Design » et de la SSI dans la gestion de projets en mode V ou Agile

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines


Résumé

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.


Body

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.

schema

É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

[1] https://connect.ed-diamond.com/MISC/MISC-103/Comment-concevoir-son-referentiel-protection-de-la-vie-privee-en-coherence-avec-le-referentiel-SSI

 

Sur le même sujet

De l'utilisation d'une bibliothèque à l'exécution d'un code arbitraire

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Dans cet article, nous présentons une vulnérabilité de la version 3.1 de Commons Collections. Cette vulnérabilité, nommée « CommonsCollections1 », permet à un attaquant l’exécution d’un code arbitraire ou Remote Code Execution (RCE). Ce travail reprend certains concepts des deux articles publiés dans les versions précédentes de MISC en 2018 et 2019 [1,2].

Le principe de confiance minimale appliqué au Cloud Computing

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Avoir la capacité d’identifier des utilisateurs au-delà du système d’information et d’exposer des applications sans la nécessité de passer par un lien réseau de confiance sont deux éléments nécessaires d’une approche Zero-Trust, mais ce ne sont pas forcément des éléments suffisants. Ces applications reposent sur d’autres composants d’infrastructure (comme les serveurs et systèmes de stockage virtualisés) et il est possible d’appliquer une approche de confiance minimale dans ces éléments afin de renforcer la sécurité de ces applications.L’utilisation du Cloud Computing est un bon exemple, car son modèle de responsabilités partagées nécessite une forme de confiance mutuelle entre le fournisseur et l’utilisateur, nous allons donc voir dans cet article comment appliquer un principe de confiance minimale des couches logicielles aux couches matérielles.

Entretien avec Philippe Biondi, figure historique de la scène de la sécurité informatique francophone

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Philippe Biondi est un expert bien connu du monde de la sécurité informatique, notamment pour la création de l’outil réseau Scapy ainsi que ses divers travaux, comme ceux autour d’Active Directory. Il a accepté de répondre à nos questions afin de revenir sur un parcours de presque 20 ans aujourd’hui dans le secteur de la sécurité des systèmes d’information.

L’authentification par mot de passe unique

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Depuis quelques années, le vol de mot de passe est devenu une industrie. Pour lutter contre le piratage que cela induit, de grands acteurs d’Internet (Google, GitHub…) incitent à utiliser une double authentification : mot de passe classique plus un code temporaire, envoyé par SMS ou généré par une application. Voici comment faire la même chose sur vos machines.

Attaques par déni de service distribué (DDoS)

Magazine
Marque
MISC
HS n°
Numéro
21
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les attaques par déni de service ont été popularisées il y a déjà 20 ans, et sont aujourd’hui connues de (quasiment) tous. Malgré cela, il reste simple et efficace d’en réaliser une, parfois sans même à avoir à écrire la moindre ligne de code. Nous récapitulerons dans cet article les fondamentaux du déni de service, et quelques conseils pour y faire face.

Introduction à Zero Trust 

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

La sécurité informatique adore les modes. Le « Zero Trust » fait partie de ces concepts qui sont devenus populaires du jour au lendemain. Et comme le sexe chez les adolescents, « tout le monde en parle, personne ne sait réellement comment le faire, tout le monde pense que tous les autres le font, alors tout le monde prétend le faire* ».

Par le même auteur

Contrôles de suivi de la conformité RGPD et d’atteinte d’objectifs définis dans la politique de protection de la vie privée

Magazine
Marque
MISC
Numéro
110
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Afin de mettre en application les exigences de contrôle de conformité (article 24 du RGPD), les directions générales, qu’elles aient désigné ou non un Délégué à Protection des Données (DPD), doivent mettre en œuvre des contrôles concernant les répartitions de responsabilités entre les acteurs impliqués par le traitement et l’application de règles opposables, l’effectivité des droits des personnes concernées, la sécurité des traitements et la mise à disposition des éléments de preuve pour démontrer la conformité des traitements de données à caractère personnel.

ISO 27701 : le Système de Management des Informations Privées (SMIP)

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

L’article 32 du RGPD formalise clairement non seulement les exigences organisationnelles et techniques de sécurité à apporter aux traitements de données à caractère personnel afin de limiter les risques sur la vie privée pour les personnes concernées, mais aussi les exigences d’évaluation et d’amélioration continue permettant de tester et de contrôler régulièrement la conformité et l’efficacité des mesures juridiques et de sécurité. Nous nous intéresserons à synthétiser la nouvelle norme ISO 27701 (août) 2019) formalisant les exigences d’un Système de Management des Informations Privées (SMIP) dans un but d’amélioration continue des mesures organisationnelles et techniques pour assurer la sécurité des traitements de données à caractère personnel. Nous montrerons comment l’implémentation du SMIP permettra aux organismes d’assurer leurs devoirs de conformité au RGPD, d’amélioration continue voire de certification.

L’intégration du « Privacy by Design » et de la SSI dans la gestion de projets en mode V ou Agile

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

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.

Comment concevoir son référentiel « protection de la vie privée » en cohérence avec le référentiel SSI ?

Magazine
Marque
MISC
Numéro
103
|
Mois de parution
mai 2019
|
Domaines
Résumé

Le chapitre IV, section 1, article 24 et l’article 32 dans la section 2 du Règlement Général pour la Protection des Données, formalisent les obligations générales du responsable du traitement en matière de sécurité : la mise en œuvre de mesures techniques et organisationnelles appropriées, au regard des risques pour la vie privée des personnes concernées, la définition et l’application de politiques adaptées au contexte et surtout la capacité de démontrer que le traitement est effectué en conformité avec le Règlement. Le responsable du traitement doit mettre en œuvre des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité ainsi que la résilience constante des systèmes et des services de traitement. Nous nous attacherons ici à analyser comment le Délégué à la Protection des Données (DPD) doit concevoir l’ensemble des règles de protection de la vie privée et de sécurité des données à caractère personnel en interaction et en cohérence avec les exigences stratégiques, fonctionnelles, opérationnelles et techniques de la SSI.

Maturité d’entreprise et plan d’action pour la mise en conformité avec le GDPR

Magazine
Marque
MISC
Numéro
94
|
Mois de parution
novembre 2017
|
Domaines
Résumé
Les organismes et entreprises doivent être conformes aux exigences du Règlement (UE) 2016/679 du Parlement Européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données en mai 2018. À un an de l’échéance, un grand nombre d’organisations n’a pas formalisé de démarche, ni initialisé de plans d’action. Nous nous intéressons ici à la formalisation d’un plan d’action juridique, organisationnel et technique adapté en soulignant les difficultés inhérentes à un profil de maturité.

L’évolution de la fonction CIL vers la fonction DPO

Magazine
Marque
MISC
Numéro
90
|
Mois de parution
mars 2017
|
Domaines
Résumé
Le Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données définit dans la section 4, articles 37, 38 et 39 la désignation du Délégué à la Protection des Données, ses fonctions et ses missions. Le G29 a adopté le 13 décembre 2016 un « Guidelines on Data Protection Officers » afin d’aider les organismes à se mettre en conformité dans la désignation du DPO. Pourtant, un grand nombre d’organismes au sein de l’union se pose un grand nombre de questions dans l’interprétation de ces différents textes. Le DPO est-il simplement le nouveau nom du Correspondant à la Protection des données (CIL) pour la France ou s’agit-il d’une nouvelle fonction ? Comment intégrer la répartition des fonctions dans la gouvernance pour la sécurité des données à caractère personnel et la protection de la vie privée ?