- Le PFPDT clôt rapidement l’examen des faits concernant Xplain, fedpol et l’OFAC ; vaste exfiltration de données et publication constatées.
- Le rapport fédéral constate des lacunes dans les processus : surveillance insuffisante, absence de principe des quatre yeux et dépendance vis-à-vis de Xplain.
- Le PFPDT qualifie des rôles : Xplain en tant que sous-traitant et en partie responsable lui-même pour stockage illicite de données.
- Recommandations : TOM obligatoires, mise en place d’un ISMS, audits réguliers, concept d’effacement et précisions contractuelles jusqu’à fin 2024.
Le PFPDT a publié les rapports finaux de son examen des faits dans les affaires Xplain SA, fedpol et OFAC en date du 25 avril 2024. publiéLe PFPDT a reçu une réponse positive de la part de l’Office fédéral de la justice (OFJ), après un examen très rapide des faits, compte tenu de la situation du PFPDT.
Contexte
L’arrière-plan était le fameux “double extorsion”.Attaque de ransomware contre Xplain. Une description assez détaillée se trouve sur Inside ITainsi qu’un Entretien avec le CEO de Xplain de février 2024.
Les agresseurs, un groupe appelé JouerEn mai 2023, une grande quantité de données avait été dérobée. La situation était critique, car Xplain était depuis 2000 le principal fournisseur informatique de l’administration fédérale dans le domaine de la sécurité intérieure, par exemple pour l’OFAC (Office fédéral des douanes et de la sécurité des frontières). Les systèmes concernés – installations de référence, environnements de développement, de test, d’administration et de construction – contenaient apparemment environ 1,5 To de données, dont environ 600 Go ont été exfiltrés et – Xplain ayant renoncé au paiement d’une rançon – environ 430 Go (146 623 fichiers, dont une grande partie de doublons) ont été publiés, probablement sans que les pirates n’aient vérifié le contenu des données. Le NCSC, qui a dirigé la gestion de l’incident du côté de la Confédération, a rédigé un rapport sur les données concernées. et publié.
Les données concernées étaient principalement celles de Xplain, de fedpol, de l’OFJ et d’autres services rattachés au DFJP, ainsi que du DDPS, du Seco et d’autres autorités cantonales et fédérales. Les données contenaient également des données personnelles, en plus de certains objets de données classés comme internes ou confidentiels – mais pas secrets. Le PFPDT illustre l’incident de la manière suivante :
Enquête administrative du Conseil fédéral
Suite à cette attaque, outre le PFPDT, le Conseil fédéral avait fait mener par Oberson Abels une enquête administrative à partir de la fin août 2023, qui s’était soldée par un rapport daté du 28 mars 2024 (des procédures pénales du MPC sont encore en cours). L’enquête visait à déterminer comment Xplain a pu entrer en possession de données productives de l’administration fédérale, si un manque de TOM suffisants en était la cause et si l’administration fédérale avait manqué à ses obligations en matière de surveillance d’Xplain.
Le rapport a conclu qu’il existait des lacunes dans les processus du côté de la Confédération (par ex. absence du principe des quatre yeux lors de la transmission de données productives à Xplain), que Xplain n’avait pas été surveillé de manière appropriée et que la Confédération avait également violé des obligations en matière de protection des données dans ses relations avec Xplain en tant que sous-traitant. Il semble également qu’il y ait eu un manque de clarté concernant la dispersion des compétences au sein des différents services fédéraux impliqués. Une dépendance vis-à-vis d’Xplain a également été constatée.
Le Conseil fédéral a donc décidé, lors de sa séance du 1er mai 2024 a décidéIl a donc décidé de prendre des mesures. Il s’attend à ce que la situation s’améliore grâce à la nouvelle loi sur l’égalité des chances, entrée en vigueur le 1er janvier 2024. ISGLe Conseil fédéral a décidé de mettre en place des mesures supplémentaires, qui devront être appliquées d’ici fin 2024 :
- des objectifs de sécurité supplémentaires pour la collaboration avec les fournisseurs (établis d’ici fin 2024), afin de renforcer la capacité de contrôle et d’audit ;
- concept de formation lié à la fonction pour la formation et la sensibilisation des collaborateurs aux consignes de sécurité ;
- Aperçu des moyens de communication existants des autorités fédérales ;
En outre, le DDPS est chargé d’examiner la protection de base TIC de la Confédération d’ici fin 2024 et de proposer des adaptations le cas échéant. Le BACS doit en outre “montrer” comment se déroule la coordination en matière de gestion des cyberattaques entre la Confédération, les cantons et les fournisseurs et selon quels critères l’ampleur des cyberattaques doit être évaluée.
Rapport final dans l’affaire Xplain
Droit transitoire
Dans son rapport final sur Xplain, le PFPDT arrive à la conclusion que diverses recommandations doivent être formulées. Comme pour tous les examens de l’état de fait commencés sous l’ancien droit, le problème se pose toutefois qu’en vertu du droit transitoire (art. 70 LPD), ils devaient ou doivent être achevés formellement et matériellement selon l’ancienne LPD. Il en résulte que les résultats et, le cas échéant, les recommandations du PFPDT ont en fait un caractère historico-juridique, car contrairement au PFPDT lors de la réalisation de l’établissement des faits, les destinataires de l’établissement des faits sont soumis à la nouvelle LPD depuis le 1er septembre 2023. On peut donc se demander si les recommandations du PFPDT seraient également valables sous le nouveau droit. C’est pourquoi le PFPDT renvoie à plusieurs reprises au nouveau droit dans son rapport final, afin de donner un peu plus de poids à ses considérations ; il ne procède toutefois pas à un véritable examen de la mesure dans laquelle le nouveau droit correspond effectivement à l’ancienne LPD.
A cela s’ajoute le fait que l’art. 70 LPD ne prévoit le maintien de l’ancien droit que pour l’établissement des faits proprement dit. Etant donné qu’une éventuelle action devant le Tribunal administratif fédéral par le PFPDT ou le destinataire de l’enquête ouvrirait une nouvelle procédure propre – il ne s’agit pas d’une procédure de recours -, une réglementation transitoire spécifique serait nécessaire à cet effet. En l’absence d’une telle réglementation, ni le PFPDT ni le destinataire du rapport final ne peuvent probablement agir devant le Tribunal administratif fédéral (les destinataires disposaient d’un droit d’action en vertu de l’art. 35, let. b, LTAF, qui a toutefois été supprimé par la nouvelle LPD).
Dans la mesure où une recommandation est rejetée ou n’est pas mise en œuvre, le PFPDT n’aurait d’autre choix que d’enquêter conformément à la nouvelle LPD. Comme la PA n’a été appliquée que par analogie à l’établissement des faits, le PFPDT devrait alors établir à nouveau les faits selon les règles de la PA et les apprécier selon le nouveau droit. En d’autres termes, la réglementation transitoire de l’art. 70 LPD est erronée dans son principe, mais elle perd tout de même progressivement de son importance (de nombreuses enquêtes sur les faits ne sont plus pendantes).
Considérations juridiques
D’un point de vue juridique, le rapport final a deux thèmes principaux, d’une part le rôle d’Xplain et d’autre part le respect de la sécurité des données. A cet égard, le PFPDT s’appuie sur ses constatations factuelles, que Xplain avait toutefois qualifiées d’inexactes.
Du point de vue du PFPDT, Xplain a joué deux rôles :
- En tant que responsables dans le domaine de leurs propres traitements :
Xplain agit en tant que responsable dans la mesure où des données personnelles concernant des clients, des collaborateurs, etc. sont traitées. Ce faisant, Xplain doit respecter les principes fondamentaux de la loi sur la protection des données […].
- En tant que sous-traitant, dans la mesure où Xplain a développé des logiciels :
L’activité principale de Xplain est le développement de logiciels standard pour la sécurité intérieure […]. Dans le cadre de cette activité, des données personnelles du donneur d’ordre sont également transmises à Xplain, notamment dans le cadre de données de projet et de corrections d’erreurs […]. Il importe peu que la transmission de ces données ne soit qu’un effet secondaire de la tâche proprement dite de Xplain. Il importe peu également que ces traitements de données représentent un volume minime par rapport aux activités principales de Xplain. […] Comme le montrent les accords contractuels, le traitement de données personnelles est notamment inclus dans les services convenus avec Xplain […]. Dans cette constellation, Xplain doit être qualifié de sous-traitant au sens de l’art. 10a aLPD.
Le PFPDT ne s’attarde pas ici sur une analyse plus détaillée des rôles. Selon notamment de la BayLDAmais également représentés par l’EDSA et aussi reçues en Suisse „Théorie du centre de gravité“La question de savoir si le traitement de données personnelles est l’objet même de la prestation de services (traitement des commandes, par exemple dans le cas de services d’hébergement ou SaaS) ou s’il s’agit simplement d’un effet secondaire d’une prestation de services différente (activité en tant que responsable, par exemple services des professions libérales) serait déterminante.
C’est probablement dans l’intérêt des services fédéraux – dans la mesure où Xplain serait un responsable, la question se poserait de savoir si des données personnelles peuvent être mises à la disposition de Xplain, ce qui est beaucoup plus simple pour un mandataire. Il convient de noter qu’un responsable peut également être un auxiliaire au sens du droit du secret (de fonction) et qu’il peut être consulté en conséquence si lege artis soit désigné et impliqué.
Mais à cela s’ajoute un autre rôle de Xplain : celui de responsable, parce que les directives correspondantes n’ont pas été respectées dans le cadre d’un traitement de commande:
En tant que sous-traitant, Xplain doit traiter les données personnelles conformément aux instructions du responsable du traitement, en particulier conformément aux instructions contractuelles et dans le cadre de ce que le mandant pourrait faire lui-même (art. 10a, al. 1, let. a aLPD).
Dans la mesure où Xplain ne respecte pas ces directives, elle devient elle-même responsable de la protection des données.
Dans les faits, il s’avère qu’Xplain n’a pas effacé les données personnelles qui lui ont été transmises conformément au contrat […]. Xplain est responsable de la conservation de ces données personnelles – qui ont été publiées ultérieurement sur le Darknet.
Ce n’est ni tout à fait vrai ni tout à fait faux. Formulé de manière aussi absolue, il n’y aurait pas de sous-traitant défaillant, mais seulement le responsable présumé. La notion de responsable n’est toutefois pas aussi large – elle exige, comme on le sait, une influence suffisante sur les finalités et les moyens du traitement. Si un responsable du traitement des commandes enfreint une exigence de sécurité, il ne devient pas pour autant responsable. Un tel changement de rôle n’intervient que si le responsable procède à son propre traitement pour des motifs propres – finalité – ou met en place des moyens essentiels de traitement. Cela se produit toutefois en cas de stockage des données au-delà de ce qui est prévu par le contrat ; dans ce cas, le sous-traitant devient effectivement un responsable. Si cela n’est pas fait et que les données ne sont pas effacées après la fin du traitement du contrat, le sous-traitant est un responsable qui viole très probablement ses obligations (par exemple, l’information des personnes concernées).
Le PFPDT continue de soutenir
- Les services fédéraux mandataires pouvaient partir du principe que Xplain a mis en place des TOM adéquatesXplain, en tant que responsable, est soumis à l’aDSG et doit respecter l’article 7 de l’aDSG”. C’est une justification un peu étrange, mais il est en tout cas exact qu’un sous-traitant est également soumis aux principes de traitement, y compris à la sécurité des données, et qu’il a donc ses propres obligations, et que le responsable peut avoir une certaine confiance dans le respect des obligations correspondantes. Il n’est donc pas obligatoire de manière générale d’énumérer une liste de TOM dans un ADV, même si cela est fréquent (souvent toutefois avec des descriptions peu parlantes de TOM très génériques).
- Dans la mesure où le responsable des exigences de sécurité spécifiques il doit toutefois les lier par contrat. (En outre, le Protection de base TIC de l’administration fédérale établit que les prescriptions de sécurité TIC de la Confédération doivent être réglées de manière contraignante par contrat).
- Selon lui, le responsable doit vérifier la mise en œuvre et le respect des mesures de sécurité – ce qui n’est pas faux, mais ne peut pas être généralisé à tous les traitements de commandes :
Le site Le sous-traitant doit lui-même effectuer des audits et de signaler les incidents de sécurité inhabituels au responsable. Cela découle déjà des mesures de protection de base de l’article 7 aLPD et du principe de bonne foi. Le responsable peut se réserver un droit d’audit et se faire présenter également les rapports d’audit du sous-traitant.
- La conservation de données personnelles au-delà de ce qui est nécessaire viole le principe de la Proportionnalité.
- Xplain aurait négligé l’obligation de notifier la violation de la sécurité (il est vrai que sous l’aLPD, une telle obligation n’existait que sur une base contractuelle ou dans certaines constellations en tant qu’émanation du principe de sécurité) :
Immédiatement après l’incident du ransomware, Xplain a pris différentes mesures pour minimiser les dommages […]. Il est frappant de constater que Xplain n’était manifestement pas conscient de la gravité de l’incident et que les L’administration fédérale n’a été informée que dix jours après l’incidentLe délai de 24 heures pour ce type d’incident a été convenu.
Un autre point est intéressant : le PFPDT examine les Respect des exigences minimales en matière de sécurité des données par Xplain et constate des violations – mais ce, sans mentionner ou établir une règle abstraite pour déterminer le standard de protection minimal. Le PFPDT constate certes à juste titre qu’il ne faut pas déduire du fait d’un incident de sécurité que les TOM sont insuffisantes (une idée qui a été reprise dans Art. 4, al. 2, LRFP s’exprime particulièrement bien) :
Le simple fait que des données personnelles aient été publiées sur le darknet à partir du serveur de fichiers de Xplain ne permet pas de conclure que les mesures n’étaient pas appropriées. Un risque résiduel de violation de la protection des données subsiste lors de chaque traitement de données. Ce qui est déterminant, c’est de savoir si les mesures adéquates ont été prises en fonction du risque lié au traitement des données.
Il faudrait également y penser lors de la transmission de données personnelles à l’étranger. Mais le PFPDT procède de la manière suivante : il cite des mesures de sécurité qui n’ont pas été prises – par exemple l’exploitation d’un SOC ou la reproduction de directives contractuelles dans des processus propres – et en arrive à la conclusion que ces mesures ne sont pas nécessaires. a conclu directement qu’il y avait eu violation des exigences en matière de sécurité des données. Même si le résultat est évident et que le PFPDT se limite à des recommandations assez génériques, la procédure est en fait lacunaire d’un point de vue juridique. Le PFPDT aurait dû examiner les facteurs visés à l’art. 1 OLPD – ou plutôt aux art. 8 ss. et 20 ss. aLPDS -, c’est-à-dire qu’il aurait dû
- de la manière dont les risques pour les personnes concernées sont réduits. ex ante en tenant compte de la marge d’appréciation du responsable du traitement,
-
doivent évaluer l’état de la technique, et
-
le coût de la mise en œuvre d’autres mesures possibles, en tenant compte de l’efficacité des mesures possibles.
Ce que montre également la présente procédure :
- Dans un climat de confiance, les mesures de sécurité sont très souvent négligées et ne sont examinées de manière critique qu’en cas de violation. Cela prouve l’importance des contrôles externes (p. ex. pentests ou autres Security Reviews), en particulier dans le cadre d’une collaboration étroite et de longue durée.
- Il n’est pas interdit de confier au sous-traitant des obligations en matière de sécurité des données, c’est même la règle. Il est difficile de dire jusqu’où va la responsabilité du responsable et jusqu’où va celle du sous-traitant – mais une TOM centrale pour les deux parties consiste précisément à régler cette interface.
- La sécurité est aussi une question de processus. Les processus doivent exister et être rodés. Ils ne fonctionnent pas en cas d’urgence s’ils ne fonctionnent pas en mode standard.
- Les entreprises ont souvent un faux sentiment de sécurité lors de leurs propres traitements, probablement pour deux raisons : D’une part, les traitements internes ont l’impression de se dérouler dans un espace protégé – de ce point de vue, les défaillances des processus internes sont inesthétiques, mais inoffensives. D’autre part, on sait abstraitement combien les cyber-attaques sont devenues fréquentes, mais cela n’entraîne pas un sentiment de menace, à tort toutefois.
- La contamination des systèmes par des données personnelles ou d’autres données sensibles peut se retourner contre vous. Cela ne concerne pas seulement le stockage de données clients chez des prestataires de services informatiques, mais tout autant le fait de ne pas effacer ou anonymiser des données sur ses propres systèmes, qui peuvent être touchés par une brèche, ce qui peut entraîner une nécessité d’explication vis-à-vis des personnes concernées.
Recommandations
Le PFPDT recommande à Xplain de prendre les mesures suivantes :
En ce qui concerne la sécurité des données:
- Xplain prend des TOM appropriées conformément à la loi et aux directives contractuelles de l’administration fédérale, ceci en ce qui concerne
- le traitement de données personnelles sensibles dans le cadre de processus d’assistance et de maintenance,
- le traitement de données personnelles sous une protection qualifiée du secret
- le développement de logiciels dans le domaine sensible de la sécurité intérieure.
- Xplain démontre régulièrement ces TOM de l’administration fédérale en
- met en place un ISMS (sachant que celui-ci doit être certifié selon une norme internationalement reconnue tant que Xplain collabore avec l’administration fédérale dans le domaine de la sécurité intérieure) ;
- a établi une gestion des risques et
- Mesures évaluées en permanence ;
- Xplain “sensibilise” ses collaborateurs
- Xplain procède périodiquement à des audits internes et externes.
En référence à d’autres principes:
- Xplain intègre les obligations contractuelles dans ses propres processus, et
- met en œuvre un concept d’effacement conformément aux dispositions légales et contractuelles.
Publication du rapport final
Le litige portait sur la question de savoir si et comment le rapport final devait être publié. Xplain avait demandé sans succès de renoncer à une publication, apparemment parce que l’état des faits n’avait pas été établi correctement. Eventuellement, Xplain avait exigé des caviardages étendus, allant apparemment jusqu’à l’anonymisation du rapport final. Comme d’habitude, le PFPDT a certes procédé à certains caviardages, mais pas dans une mesure aussi large, notamment parce qu’une anonymisation n’aurait de fait pas été possible dans ce cas.
On peut toutefois effectivement se demander jusqu’où peut aller la pratique de publication du PFPDT. Selon l’ancienne comme la nouvelle LPD, le PFPDT peut informer le public des constatations et des décisions, donc aujourd’hui aussi des enquêtes et des décisions, mais uniquement “dans des cas d’intérêt général” (art. 57, al. 2, LPD ; art. 30, al. 2, aLPD). Cette formulation est ambiguë : dans de tels cas, le PFPDT ne peut pas informer de manière générale, mais uniquement dans la mesure où l’information présente concrètement un intérêt public. A cet égard, certains facteurs doivent être pris en compte :
- Tout intérêt du public n’est pas forcément un intérêt public – cela vaut pour les médias comme pour le PFPDT. Tout ce dont les médias veulent parler n’est pas forcément d’intérêt public. Le caractère public des médias ne justifie donc pas toutes les publications. Au contraire, elle peut même être une raison de renoncer à une publication.
- L’intérêt du public pour l’activité du PFPDT en général ne doit pas être satisfait par la publication d’un rapport final, mais par des rapports d’activité ou des communiqués de presse.
- L’intérêt du PFPDT à démontrer sa propre efficacité n’est pas un intérêt public.
- L’intérêt du public pour l’information n’exige pas une information détaillée. La durée d’attention du public est courte.
- L’intérêt à la formation du droit et à la connaissance de la pratique du PFPDT est un intérêt public. Il pourrait et devrait être satisfait par des guides et autres, et non par des rapports finaux dont la motivation juridique est souvent très superficielle.
Rapports finaux concernant fedpol et l’OFAC
Contrairement à Xplain, l’examen des faits concernant fedpol et l’OFAC n’a pas porté sur les processus internes d’Xplain, mais sur la procédure des autorités elles-mêmes. Sur le plan du contenu, les rapports finaux se recoupent toutefois.
Le PFPDT réaffirme toutefois clairement que le responsable peut avoir une certaine confiance de base dans le sous-traitant :
Le responsable doit donner des instructions claires au contractant concernant les mesures de sécurité et contrôler leur mise en œuvre et leur respect. Dans la mesure où le mandataire est lui-même soumis à l’aLPD, le responsable peut partir du principe que les mesures techniques et organisationnelles de sécurité des données (art. 7 aLPD) sont remplies de manière adéquate.
Le responsable du traitement peut néanmoins être amené à surveiller le sous-traitant :
Le responsable est donc tenu de choisir soigneusement le sous-traitant, de l’instruire et de le former. surveiller, si nécessaire.
Sur le fond, le PFPDT voit des lacunes notamment dans l’intégration contractuelle d’Xplain, dans la confiance accordée à un contrôle présumé par l’OFAC, qui utilisait déjà une application utilisée par fedpol, et dans l’absence de mesures de surveillance.
A cet égard, le PFPDT recommande à fedpol et à l’OFAC ce qui suit :
- Le traitement des données de commande n’était pas clairement réglementé. Le traitement des données de commande doit donc être concrétisé en ce sens que les parties doivent “prendre conscience” si et dans quelles conditions les données personnelles peuvent quitter les systèmes de la Confédération. Il recommande ce qui suit :
- Examiner quand il est nécessaire que les données personnelles quittent les systèmes de la Confédération dans le cadre de processus de soutien et soient enregistrées dans des systèmes d’Xplain ;
- de déterminer à chaque fois les TOM nécessaires et, en cas de stockage nécessaire chez Xplain, de garantir en particulier les principes de minimisation et de sécurité des données ;
- de fixer les transferts de données correspondants dans des accords clairs.
- Si fedpol devait continuer à collaborer avec Xplain (ce qui semble être le cas – la dépendance constatée par le rapport d’enquête persistera -), “les critères de protection des données doivent être pris en compte” . Les processus relevant du droit de la protection des données et leur respect doivent être régulièrement surveillés.
- Lors de la prochaine décision concernant la poursuite de la collaboration, fedpol devra contrôler l’existence d’un ISMS certifié.
- Les processus de protection des données et leur respect doivent être contrôlés régulièrement, par des contrôles internes ou externes ou par une autre preuve.
- En outre, les collaborateurs doivent être “sensibilisés” en permanence aux risques liés à la protection des données.
- Les contrats doivent être précisés et, le cas échéant, uniformisés dans le domaine de la sécurité des données.
Le PFPDT recommande en outre à fedpol, pour les applications utilisées par un autre office fédéral, d’avoir au moins sa propre SCHUBAN à effectuer.