[cyber-sécurité] faille de sécurité-fuite de données : jurisprudence CNIL 2014 -> 2018

[27 février 2018] Il est des esprits sceptiques qui ne voient derrière la GDPR qu’une règlementation pour « tuer l’innovation » (ou – évidemment – pour nourrir les avocats en manque de travail…). Puisque les « fake news » et les complots en tout genre sont à la mode, je tiens beaucoup à faire progresser le débat (mondial) en vous livrant mon interprétation du problème. A titre personnel, je suis persuadé que « GDPR » signifie « Groupe de Destruction Politique des Reptiliens« … La prochaine entrée en vigueur du RGPD (« Reptilian Group for Power and Destruction » ?) fait peur… L’exemple de l’obligation de devoir remédier à toute « faille de sécurité-fuite de données » et d’en notifier l’occurence à une Autorité de contrôle en est un bon exemple. Remettons les choses en perspective.

Qui, il y a 20 ans, se souciait de sécuriser son système d’information, à part quelques grandes entreprises, les acteurs « coeur de réseau » et les militaires ? Pas grand monde. Et pourquoi ? Parce que la menace n’était pas (encore) réelle. Et en quoi le monde a changé, seriez vous, tenté de me demander ? Les réseaux de communications électroniques… Avec l’ouverture du protocole web au public en 1993, les premiers téléphones portables, le e-commerce… Les sociétés occidentales vivent aujourd’hui en réseau (pas seulement social). Plus on crée de passages et de portes entre les systèmes d’information, plus certaines serrures deviennent nécessaires. Car les vocations se développent chez les cambrioleurs. C’est une forme de loi du marché… Car « la nature est un grand vide qu’il convient de bien remplir‘ » (C’est de Napoléon avant que vous ne demandiez…). 

[mise à jour du 1er mars 2018 : et une belle fuite de données révélée par ZDNet : « Près de 700.000 données lecteurs de l’Express dans la nature » ou la reprise de cette information par Next INpact]

Depuis 1988 en France, le droit pénal dispose des incriminations pour réprimer « ceux qui attaquent ». Ce sont les délits autours des accès et des maintiens « frauduleux » dans les systèmes de traitement automatisés de données. Dans une large mesure, ces infractions répriment celles et ceux qui créent / exploitent / etc. une « faille de sécurité-fuite de données ».

faille de sécurité-fuite de données 01 00


La jurisprudence « Bluetouff » de 2014 est interessante en ce qu’elle fait le lien entre « celui qui rentre » dans un système d’information et « celui qui n’a pas bien sécurisé le système » en question.

Petite remarque sémantico-juridique : chez les juges, on ne dit pas « système d’information » (SI), on dit « Système de Traitement Automatisé de Données » (STAD)… ça change tout… A la question de mon ami Frans, je réponds : un téléphone portable est en lui-même un « STAD »…

faille de sécurité-fuite de données 01


Faille de sécurité-fuite de données : la définition légale de 2011

faille de sécurité-fuite de données 2


Il a fallu attendre 2011 et une obscure ordonnance relative aux communications électroniques(*) pour que voit le jour un délit spécifique réprimant la négligence dans la sécurisation des systèmes d’information C’est avec ce texte qu’apparait en France officiellement la notion de « violation de données« . Coup de bol, la définition légale bleu blanc rouge de la « faille de sécurité-fuite de données » est identique à celle retenue dans la GDPR votée le 27 avril 2016 et applicable dans quelques dizaines de jours dans l’Union Européenne.

Certes, depuis 2011, la répression pénale du défaut de sécurisation ayant conduit à une « violations de données » était cantonnée (je cite – accrochez-vous) à la « fourniture au public de services de communications électroniques sur les réseaux de communications électroniques ouverts au public ».

Faille de sécurité-fuite de données : une GDPR dans la continuité

Bref… retenez que la définition française de 2011 est adoptée à l’identique dans la GDPR pour les 27 états membres et surtout, dorénavant, concerne TOUTES les « violations de données (à caractère personnel) ».

faille de sécurité-fuite de données 3


Comme me le faisait justement remarquer un DSI récemment, « on ne va pas s’amuser à regarder si la faille de sécurité-fuite de données concerne ou non des données personnelles. On va réagir – à l’identique – dans tous les cas comme l’impose la loi« . Et c’est probablement un pari de l’UE en cours de réussite. Réglementer la sécurisation de la data par une législation commune aux 27 pays de l’UE, ça aurait été politiquement compliquée pour la Commission Européenne…. Alors que via les données personnelles, après les révélations de Snowden en juin 2013, comment dire « non » à de nouvelles obligations élémentaires ?

Il y a donc en février 2018 un intérêt certain à se pencher sur la jurisprudence de la CNIL qui sanctionne depuis 2014 chaque faille de sécurité-fuite de données. Enfin, celle dont le bruit remonte jusqu’à ses oreilles… Et manifestement, la délation, ça marche pas mal…

Faille de sécurité-fuite de données : en synthèse ?

faille de sécurité-fuite de données 4


« Orange » en 2014, « Hertz » en 2017 et « Darty » en 2018, Dans les 3 cas, ce sont des problèmes techniques avec les sous-traitants. Et que conclut à chaque fois la CNIL ? Fort logiquement que « le responsable du traitement » est « responsable » de ses sous-traitants. C’est pas une grande découverte juridique, ça… Précision pour les non juristes : le fait d’être responsable du travail délégué à ses sous-traitants, c’est juste un rappel du droit commun des contrats et du droit commun de la responsabilité.

Ce qui change le 25 mai 2018 ? Le niveau de sanction. Ne pas sécuriser son SI = ne pas notifier une faille-fuite à son autorité de contrôle = risque de « sanction administrative » à hauteur de 10 millions ou 2% du CA mondial, « le montant le plus élevé étant retenu ».

faille de sécurité-fuite de données 5


ça y est ? J’ai toute votre attention ? Le détail (croustillant…) est dans le slider ci-dessous.

Dernier rappel pratique : dans les 3 délibérations de la CNIL, la faille était aussi contractuelle. A bon entendeur pour les DSI et les DJ…



(*) pour les juristes les plus exigeants, l’ordonnance n°2011-1012 du 24 août 2011 a été ratifiée par l’article 18 I de la loi n°2014-1 du 2 janvier 2014 « habilitant le Gouvernement à simplifier et sécuriser la vie des entreprises ». L’entrée en vigueur de l’article 34 bis [nouveau] de la loi « Informatique et Libertés » date bien de janvier 2014. La notification par Orange date du 25 avril 2014. Ne cherchez plus pourquoi il n’y a aucune jurisprudence avant 2014…


P.S. : Cher Philippe, tu as raison, je devrais insister auprès des DSI / RSSI pour mieux définir ce que la loi (la GDPR) entend par « responsable de traitement » et par « sous-traitant« . Le « responsable du traitement » au sens de la loi CNIL, c’est celui/celle qui détermine les finalités de la collecte et du traitement des data perso. Le « responsable du traitement » définit les moyens de sa politique. Il décide des outils, du temps et de l’argent qu’il va engager pour ses data. Pour comprendre mieux encore, il faut aller  chercher dans le droit des bases de données. « On » a un droit « privatif » sur « des » data lorsque « on » peut prouver un « investissements humain, matériel ou financier » « qualitativement ou quantitativement substantiels« . Donc, le « responsable du traitement » s’occupe de « ses » data. Le « sous-traitant« , lui, traite les data de ses clients, celles qui ne sont pas à lui. Le sous-traitant n’a pas de droit propre sur les data qui lui sont confiées par son clients, ni sur le résultat des traitements d’ailleurs. Comment ? Où est ma présentation en ligne sur ce sujet ? Tu deviens exigeant… OK… c’est presque prêt…


Un merci tout particulier à Turf , scénariste et dessinateur de cette « Nef des Fous » et aux éditions Delcourt. Les cases de Turf (dit « le Génial ») se prêtent à merveille à l’illustration de tout sujet autours des failles de sécurité / fuites de données  et de la sécurité des systèmes d’information… Que de failles et de fuites à Eauxfolles… 


faille de sécurité-fuite de données 6


faille de sécurité-fuite de données 7


faille de sécurité-fuite de données 8 8


faille de sécurité-fuite de données 9