1

Faille dans le Cloud : à qui la faute ?

|

Jeudi dernier (26/08/2021) Microsoft a annoncé avoir corrigé une importante faille de sécurité dans son service Cloud Azure Cosmo DB. Cette vulnérabilité, découverte par des chercheurs de la société Wiz, permettait d’obtenir les clés d’accès aux bases Cosmo DB. Ainsi en l’exploitant, un attaquant aurait pu consulter, modifier ou même supprimer les données des clients de ce service SaaS entrainant ainsi une violation de données à caractère personnel.

Cette affaire pose la question de la responsabilité entre clients et fournisseurs. Dans le cas d’une violation de données à caractère personnel, suite à une faille de sécurité liée non pas à un mauvais paramétrage du client mais à une vulnérabilité critique du service SaaS : à qui incombe la responsabilité selon le RGPD ?

J’ai posé il y a quelques jours la question sur Linkedin et voici l’avis des 132 personnes qui ont bien voulu répondre à ma question :

La question me paraissait relativement facile mais visiblement, au vu des résultats très disparates, elle ne l’était pas. J’ai donc décidé de rédiger cet article pour donner la réponse et surtout pour l’expliquer…

Si nous étions avant le 25 mai 2018, date d’entrée en application du RGPD, la seule et unique bonne réponse aurait été le client (réponse n°2). En effet sous le régime juridique précédent, issu de la directive européenne 95/46/EC transposée en France en 2004, seul le responsable du traitement était responsable aux yeux de la CNIL même lorsque la faute incombait uniquement au fournisseur. La CNIL a par exemple sanctionné la société Hertz en 2017 pour une divulgation de données alors qu’il était clairement établit que c’était son sous-traitant qui avait commis l’erreur.

Oui mais voilà, comme le dit si bien la pub de Krys, ça c’était avant. L’entrée en application du règlement européen sur la protection des données (UE/2016/679) plus connu sous le sigle RGPD a véritablement changé la donne.

Contrairement à la loi I&L de 2004 qui ne mentionnait qu’une seule fois le terme de sous-traitant dans son article 35 et d’ailleurs juste pour le définir et non pas pour le responsabiliser, le RGPD au contraire implique systématiquement responsable du traitement (data controller) ET sous-traitant (data processor) dans ses exigences. Pour le démontrer, j’ai effectué une petite recherche dans le texte du règlement et j’ai trouvé 171 occurrences de la séquence « le responsable du traitement et/ou le sous-traitant ».

Et oui, la réponse à la question est « Aux deux », c’est-à-dire au client (agissant en tant que responsable du traitement) ET au fournisseur (agissant en tant que sous-traitant). Pourquoi ?

Et bien tout d’abord parce que le responsable du traitement et le sous-traitant ont tout deux une obligation de sécuriser les traitements. L’article 32 du RGPD précise en effet que « le responsable du traitement et le sous-traitant mettent en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. »

Alors vous allez me dire, oui mais dans notre cas (faille d’un service SaaS), c’est bien au fournisseur Cloud qu’il incombe de sécuriser le service, le client n’ayant pas la main sur l’infra technique. Oui mais c’est oublier un peu vite l’article 28 (consacré au sous-traitant ) qui stipule dès son premier paragraphe que le responsable du traitement doit faire uniquement appel à des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées.

En d’autres termes, même s’il parait évident qu’il appartient au fournisseur SaaS de sécuriser son service, s’il ne le fait pas, il faut que le client prouve à l’autorité de contrôle que ce fournisseur présentait pourtant toutes les garanties en matière de sécurité. Et c’est là que les choses se compliquent. Comment faire ? On regardera bien sûr le contrat et les engagements du fournisseur. Le client pourra également s’appuyer sur les garanties annoncées par le fournisseur comme l’adhésion à un code de conduite, un certificat ISO 27001 ou encore la qualification SecNumCloud. Grâce au Cyber Security act, il y aura même prochainement une certification européenne pour attester de la sécurité des fournisseurs Cloud (EUCS – Cloud Services Scheme).

Mais que valent ces garanties aux yeux d’une autorité de contrôle et surtout cela sera-t-il suffisant pour exonérer le client de toute responsabilité ? Rien n’est moins sûr et après investigation, l’autorité de contrôle pourra très bien sanctionner le client ou le sous-traitant ou les deux.

D’autre part, n’oublions pas que le RGPD (article 33) oblige les clients et les fournisseurs à notifier toute violation de données à caractère personnel.

Le client (data controller) doit notifier la violation à l’autorité de contrôle dans les 72 heures après en avoir pris connaissance. Et bien entendu, s’il ne le fait pas, il encourt une sanction administrative.

Le fournisseur (data processor) doit lui aussi notifier la violation de données mais non pas à l’autorité de contrôle mais au responsable du traitement, c’est-à-dire son client. Et, s’il ne le fait pas, il encourt lui aussi une sanction administrative. Dans le cas du fournisseur, le RGPD n’impose pas un délai maximum de 72h mais précise simplement (article 33 paragraphe 2)  « Le sous-traitant notifie au responsable du traitement toute violation de données à caractère personnel dans les meilleurs délais après en avoir pris connaissance. » On notera qu’il en est de même pour la notification par le responsable du traitement aux personnes physiques concernées par la violation de données. Quelle en est la raison ? Et bien le législateur européen a considéré (à juste titre) que le fait d’obliger le sous-traitant à informer ses clients sous 72h pourrait aggraver la situation en rendant publique une faille non encore totalement corrigée.

Pour conclure, on peut affirmer que dans le cas d’une violation de données à caractère personnel suite à une faille de sécurité d’un service Cloud, la responsabilité incombe à la fois au responsable du traitement (client) et au sous-traitant (fournisseur du service).

Pour les 3 infractions potentielles (insuffisance des clauses contractuelles relatives à la protection des données, violation des règles en matière de sécurité des traitements ou défaut de notification des violations de données), la sanction administrative encourue est de 10 M€ ou de 2% du CA. Pour Microsoft dont le CA worldwide est de 125 Milliards de dollars, cela porte le risque à une amende potentielle de 2,5 milliards de dollars, ce qui serait très largement supérieur à la sanction de 746 M€ infligée à Amazon par la CNPD (l’autorité de contrôle luxembourgeoise) le 16 juillet dernier.



Zoom sur la sécurité de Zoom !

|

Suite à son incroyable succès lié à la crise sanitaire, Zoom a fait l’objet d’une attention particulière des chercheurs en sécurité et leurs découvertes ont entrainé une avalanche de critiques. Alors qu’en est-il véritablement ? Peut-on raisonnablement utiliser Zoom dans un contexte professionnel ? C’est ce que nous allons voir dans cet article.

Préambule

Zoom est une solution de visioconférence basée sur un service Cloud en mode SaaS associé à un logiciel client disponible pour PC, Mac, Android et iOS. Avec la crise sanitaire du COVID-19 et la généralisation des réunions à distance, Zoom a vu son nombre d’utilisateurs passer de 10 millions à plus de 200 millions en quelques semaines. Derrière le produit, il y a la société Zoom Video Communications, société américaine basée à San Jose (Californie). En seulement un trimestre et alors que tous les marchés financiers se sont écroulés, sa capitalisation boursière au NASDAQ a plus que doublé avec une action valorisée à 146 $ au 31 mars 2020 (68 $ au 1er janvier). Alors bien évidemment, devant un tel succès et avec toutes les inquiétudes liées à la sécurité du télétravail, bon nombre de chercheurs en sécurité se sont lancés dans la recherche de vulnérabilités dans le produit star du moment.

Zoom est une solution technologique complexe et dans tout logiciel complexe, quand on cherche activement des failles et bien vous savez quoi ? On en trouve ! Et ce n’est certainement pas Microsoft, Google ou Apple qui vous diront le contraire. Il ne faut donc pas juger la sécurité d’une solution Cloud uniquement sur le nombre et la criticité de ses vulnérabilités car il faut également prendre en compte la capacité du fournisseur à réagir et à répondre rapidement et correctement aux problèmes de sécurité rencontrés. Mais soyons factuel et regardons les problèmes identifiés ces dernières semaines.

Fuite de données personnelles vers Facebook

Tout est parti d’un article de Joseph Cox qui dévoile le 26 mars 2020 que l’application Zoom envoie les données personnelles des utilisateurs à Facebook et ceci même si l’on ne dispose pas de compte Facebook.

Le problème était lié à une mauvaise utilisation du SDK Facebook sur les plateformes iOS et ne concernait donc que les clients Zoom sur iPhone et iPad. Les données personnelles divulguées étaient en fait des diagnostics de base des iPhone ou iPad (taille de l’écran, espace de stockage, …). Et contrairement à ce que j’ai pu lire un peu partout sur le Net et notamment dans les réseaux sociaux, il n’y avait aucune information sensible comme un nom d’utilisateur, un mot de passe, un numéro de téléphone ou encore le contenu des conversations.

Selon des informations disponibles sur son Blog, Zoom a découvert le problème le 25 mars et a publié un client Zoom corrigé pour iOS dès le 27 mars 2020. Deux jours pour corriger un bug de sécurité, j’aimerais bien que ce soit la règle chez tous les éditeurs. En tout cas, on ne peut pas reprocher à Zoom de ne pas avoir rapidement réagi sur ce problème qui est aujourd’hui définitivement réglé.

Problème du « Zoom Bombing »

Dans Zoom, il est possible d’accéder directement à une réunion privée (si le créateur de la session l’a autorisé) via un simple code (ID meeting) composé de 9 à 11 chiffres. Et bien entendu, il est possible avec un « bot » de trouver des codes de conférence valides et de s’introduire dans la conférence. On a également vu plusieurs cas où le code de conférence était publié ou divulgué et de nombreux intrus venaient perturber les conférences.

Pour la réponse aux attaques par un Bot, il s’agit ici d’un problème de conception et Zoom devra changer l’entropie de ses codes de conférence par quelque chose de beaucoup plus robuste. Un mécanisme anti brute force sur le service SaaS associé à un ID de conférence codé sur 12 caractères (alpha & num) devrait faire l’affaire. Mais sans attendre ces évolutions en matière de sécurité, on peut d’ores et déjà résoudre le problème du Zoom bombing par la mise en place d’un contrôle en amont. On peut en effet dans Zoom protéger l’accès à une conférence par exemple via une liste d’adresses e-mail autorisées. D’autre part, Zoom a ajouté récemment une fonctionnalité de salle d’attente. Ainsi les retardataires sont placés en liste d’attente afin de valider leur participation à la réunion. Zoom a également ajouté la possibilité de saisir un mot de passe pour entrer en conférence.

Zoom et le chiffrement de bout en bout

Ici tout est parti d’un article de Micah Lee et Yael Grauer le 31 mars qui dévoilait que, contrairement aux affirmations de Zoom, les réunions n’étaient pas chiffrées de bout en bout. Et effectivement, le chiffrement des conférences Zoom n’est pas un « vrai » chiffrement de bout en bout que l’on appelle E2E (End-to-End Encryption). Les conférences sont effectivement protégées par un chiffrement et pour cela Zoom utilise le protocole SRTP (Secure Real-time Transport Protocol) avec un chiffrement AES-128. Mais les clés de 128 bits utilisées sont générées par les serveurs Zoom et distribuées via TLS aux clients Zoom. Par conséquent, Zoom peut avoir accès à l’intégralité des données échangées entre les participants. Dans une véritable communication E2E, seuls les participants de la communication ont accès aux clés de chiffrement mais pas les intermédiaires qui relaient les communications. C’est par exemple le cas avec l’application Signal ou avec Face Time d’Apple. Mais dans les deux cas, ces solutions ne permettent pas une montée à l’échelle, c’est-à-dire une communication avec des centaines de participants.

D’autre part, des chercheurs du laboratoire Citizen Lab de l’université de Toronto ont publié le 3 avril un article sur les algorithmes cryptographiques utilisés par Zoom. Comme indiqué précédemment, la communication des vidéos est bien chiffrée en AES-128 mais Zoom utilise AES en mode ECB. Or ce mode de chiffrement a des faiblesses connues et le standard SRTP recommande d’utiliser AES avec d’autres modes comme CTR ou f8. En ce sens, on peut dire que Zoom n’est clairement pas à l’état de l’art en matière de cryptographie.

On pourrait synthétiser ce problème de chiffrement E2E sous forme de questions / réponses :

  • La solution actuelle de Zoom est-elle à l’état de l’art en matière de communication sécurisée ?
    • Non
  • Peut-il y avoir violation de la confidentialité des échanges ?
    • Oui selon 3 scénarii possibles : malveillance interne chez Zoom, faille de sécurité critique dans le service Zoom ou requête gouvernementale (mandat FISA, NSL Freedom act ou assignation CLOUD act.)
  • Peut-on techniquement réaliser une véritable solution multi-utilisateurs en E2E ?
    • Oui, mais c’est relativement difficile à faire.
  • Est-ce une fonctionnalité qui sera prochainement disponible dans Zoom ?
    • Peut-être à terme mais sans doute pas avant la disponibilité du vaccin contre le COVID-19…

Fuite de mots de passe et exécution de code via UNC

Ici tout commence le 31 mars 2020 avec un article de Lawrence Abrams. Dans Zoom les participants à une réunion peuvent communiquer entre eux en s’envoyant des messages texte via une interface de discussion. Et si un message échangé contient une URL alors celle-ci est automatiquement convertie en hyperlien afin que les autres membres puissent accéder à l’information via un simple clic. Le problème est qu’un chercheur en sécurité a découvert que le client Zoom convertissait également les chemins UNC en un lien cliquable dans les messages de discussion. Ainsi, si un utilisateur clique sur un lien de chemin UNC, Windows tentera de se connecter au site distant en utilisant le protocole de partage de fichiers SMB et ce faisant, Windows enverra par défaut le nom de connexion de l’utilisateur et le hash de son mot de passe NTLM. Et bien évidemment, si le mot de passe n’est pas robuste, un outil comme hascat associé à une puissante carte graphique pourra permettre de découvrir le mot de passe de l’utilisateur. Et puis au-delà de la fuite de l’identifiant et du hash du mot de passe, on découvre également un autre problème. En effet, en utilisant une UNC sur le localhost (127.0.0.1), on peut lancer l’exécution d’un programme sur l’ordinateur d’un participant.

En réponse à ces problèmes, Zoom a publié dès le 1er avril, la version 4.6.19253.0401 de son client qui empêche désormais tous les liens publiés, y compris les URL normales et les chemins UNC, d’être convertis en hyperliens cliquables. Alors là aussi, on pourrait demander de manière irréaliste à Zoom de délivrer un logiciel sans faille. Mais que demander de plus lorsqu’un problème de sécurité est identifié le 31 mars et que la solution est disponible dès le lendemain. Je le répète, j’aimerai bien que tous les éditeurs soient aussi réactifs et professionnels face à ces problématiques de sécurité.

Problèmes de sécurité dans OSX (Mac)

Le 30 mars, un chercheur en sécurité a découvert que Zoom utilisait une technique pas très «  catholique » pour installer son application cliente pour Mac. L’idée pour Zoom était de permettre une installation facile sans avoir le consentement de l’utilisateur final. Mais comme cette technique est généralement utilisée par les cybercriminels dans l’écriture de malwares pour OSX, la news publiée sur twitter a rapidement fait le buzz (8000 likes en moins d’une semaine pour un chercheur quasiment inconnu sur twitter le 29 mars).

Là aussi, Zoom a rapidement réagi et a proposé dès le 2 avril un client MacOS exempt des « hacks » d’installation incriminés.  Dans cette version pour OSX, Zoom a également corrigé deux autres vulnérabilités importantes. Une permettait une élévation de privilège et l’autre permettait à un code malveillant d’accéder au micro et à la caméra du Mac à l’insu de l’utilisateur. Des failles critiques, je vous l’accorde, mais voulez-vous que l’on parle du nombre de failles critiques découvertes chaque année dans Windows ? Et allez-vous pour autant passer sous Linux ? Tiens juste pour info, regardons le palmarès des vulnérabilités découvertes en 2019 (source : www.cvedetails.com) :

Damned, nos vidéos transitent par la Chine !

En fonctionnement normal, le client Zoom essaie de se connecter à un datacenter principal défini dans une liste de datacenters situés dans sa région géographique ou à proximité. Si ces multiples tentatives de connexion échouent en raison d’une congestion réseau ou d’un autre problème, le client essaie alors de se connecter à un datacenter secondaire défini dans une liste de secours. Mais en février, en raison de la crise COVID, Zoom a dû augmenter très rapidement sa capacité sur la région chinoise pour faire face à une augmentation massive de la demande. Et dans la précipitation, ils ont ajouté par erreur leurs deux datacenters chinois à des listes de secours. Cela signifie que certains clients non chinois ont pu voir leurs communications transiter par la Chine.

Zoom par la voix de son CEO Eric S. YUAN a indiqué avoir supprimé immédiatement ses deux centres de données chinois des listes de secours dès qu’ils ont eu connaissance du problème. Et cela explique certainement pourquoi les chercheurs de Citizen Lab ont vu des clés de chiffrement distribuées par des serveurs chinois à des clients Zoom situés hors de Chine.

Pour conclure

Alors après toutes ces révélations, est-il encore raisonnable d’utiliser Zoom ?

S’il s’agit d’organiser des conférences ou des réunions d’entreprise dans lesquelles aucune information particulièrement sensible n’est communiquée, la réponse est bien évidemment oui. Zoom est une solution performante, facile à utiliser et même gratuite jusqu’à 100 participants. C’est la raison de son succès et sur ce point, il n’y a tout simplement pas de concurrence. Par exemple, je vais prochainement animer en distanciel deux séminaires pour Orsys : Sécurité du Cloud (28-29 avril) et Cybersécurité (4-6 mai). Les sessions s’effectueront avec Zoom et pour cela, c’est vraiment l’application idéale.

Mais on a appris ces derniers jours que Zoom était également utilisé par les dirigeants de plusieurs pays (avec entre autres Emmanuel Macron, Boris Johnson et Vladimir Poutine). Alors peut-on utiliser Zoom pour des réunions gouvernementales ? La réponse est évidente, c’est clairement non. Sans tomber dans la paranoïa, on imagine bien l’attractivité que peut représenter une telle  plateforme pour des services de renseignement gouvernemen­taux. D’autant qu’il n’est pas toujours utile de travailler à la NSA pour accéder à ce type de réunion puisque que parfois c’est le 1er ministre (Boris Johnson) qui publie lui-même (certes accidentellement) l’identifiant secret de la réunion gouvernementale sur Twitter.

Alors en guise de conclusion, on peut dire qu’utilisée à bon es­cient et avec la prudence qui s’impose, Zoom est une solution adaptée aux circonstances excep­tionnelles liées à la crise sanitaire. Pour des réunions sensibles, il faudra sans doute se tourner vers des solutions (théoriquement) plus sûres et (certainement) plus chères. On peut par exemple citer la solution de visioconférence de la société Montpellieraine Tixeo qui est certifiée (CSPN) et qualifiée (niveau élémentaire) par l’ANSSI.



Formation CCSK / CCSP : retour d’expérience

|

Dans cet article, je vous propose un retour d’expérience sur une formation CCSK / CCSP que j’ai suivi en présentiel à Paris au mois de juin. Pour ceux qui souhaitent aller à l’essentiel, voici ici une synthèse de la formation et les enseignements à retenir.

CCSK-CCSP

Préambule

Comme certains d’entre vous le savent déjà, j’ai lancé récemment une nouvelle activité de formation en e-learning sur mes sujets de prédilection (Cybersécurité, sécurité Cloud, Blockchain, RGPD,…). Depuis le lancement de l’offre, j’ai reçu un nombre important de demandes pour des formations certifiantes du type CISSP ou Security+ et comme je m’intéresse depuis plusieurs années à la sécurité dans le Cloud, j’ai donc décidé de commencer par les certifications spécifiques à ce domaine à savoir le « Certificate of Cloud Security Knowledge » (CCSK) de la Cloud Security Alliance (CSA) et le « Certified Cloud Security Professional » (CCSP) de l’ISC2. J’ai commencé ma préparation par de nombreuses recherches sur le Net et j’ai acheté la quasi-totalité des livres qui traitent du sujet y compris bien sûr le guide officiel de préparation au CCSP de l’ISC2. J’ai également recherché les formations existantes en France dans le but d’analyser le marché et la concurrence. Je suis alors tombé sur une formation CCSK / CCSP sur 4 jours mais dont il est possible de suivre qu’une partie dite « avancée » qui se déroule sur 2 journées qui sont en fait les 2 derniers jours de la formation complète. Disposant d’un budget formation auprès de mon OPCO (FAFIEC), je me suis dit qu’il pouvait être intéressant de suivre cette formation avancée, d’une part pour compléter mes connaissances en la matière mais aussi et surtout pour me donner des idées sur l’approche pédagogique à utiliser pour enseigner la sécurité du Cloud dans une optique de certification. J’ai demandé un financement au FAFIEC qui a été accepté et j’ai donc suivi cette formation sur 2 jours à Paris en juin 2019 et c’est un retour d’expérience que je vous propose dans cet article. Comme l’expérience a été disons-le catastrophique, j’ai souhaité utiliser des noms d’emprunts pour les protagonistes. Ainsi la société de formation organisatrice s’appellera FORCLOUD et le formateur s’appellera Charlie. Précisons que Charlie est le patron de sa propre boîte et qu’il travaille en sous-traitance pour FORCLOUD.

Entrée en matière

En tout début de formation je demande s’il serait possible d’avoir une version électronique du support. Charlie me répond par la négative qu’il justifie pour des raisons de propriété intellectuelle (sic !) On reviendra plus loin sur ce support et cette fameuse propriété intellectuelle.  On fait ensuite un tour de table où les participants (nous étions 4) se présentent. Lorsque vient mon tour, je me présente de façon tout à fait transparente en tant qu’expert en cybersécurité et actuellement en cours de préparation de modules e-learning CCSP et CCSK et là Charlie me dit « Ah ouais d’accord, tu es venu pour me piquer mes slides… ». Curieuse réflexion pour un formateur qui traite carrément son client de voleur dès les premières minutes de la formation. J’étais d’autant plus surpris qu’en tant que formateur depuis plus de 20 ans, j’ai toujours considéré que le savoir ça ne se vole pas, ça se partage.

Durée de la formation

Cette formation était commercialisée à un tarif de 2 420 € HT
pour une durée de 14 heures. Lors du dépôt de mon dossier de financement, mon
conseiller FAFIEC m’avait fait remarquer que le tarif horaire était particulièrement
élevé (173 € HT / H). J’avais alors argumenté en lui disant qu’il s’agissait
d’une formation de haut niveau et que le tarif se justifiait. Mais quelle ne fut
pas ma surprise en constatant les horaires du 1er jour (9h30-12h et
14h-16h30) et du 2ème (9h30-12h et 14h-16h) le tout agrémenté
de 4 pauses de 15mn (une chaque matin et après-midi). En considérant le temps
réel passé en formation, la durée a donc été de 8H30 ce qui nous fait une
prestation de formation inter-entreprises à plus de 280 € HT / Heure. Alors à
ce tarif bien sûr, on s’attend à ce qui se fait de mieux en matière de sécurité
dans le cloud. Je précise qu’en fin de formation, j’ai rayé la mention 14h dans
la feuille d’émargement et indiqué à la place 9h30. Dès lors CLOUDFORM était
dans l’obligation de ne facturer qu’à hauteur de 67% du tarif (prorata-temporis
de 9,5h / 14h) conformément à l’article 
3 du contrat FAFIEC qui stipule : « Conformément
aux textes législatifs en vigueur, le FAFIEC ne règle qu’après exécution des
prestations de formation et sur présentation des justificatifs s’y rapportant
(Art. R6332-25 et Art. R6332-26 du code du travail). En conséquence, seules les
heures effectivement réalisées sont réglées. ».

Support de cours

Mais que contient donc ce fameux support de cours avec une telle
valeur en matière de propriété intellectuelle qu’il est impossible de le donner
en version électronique à des clients qui ont payé plus de 2 400 € leur
formation ?

Sur la forme, le support est au format papier A4 avec 90 slides imprimés en noir & blanc. 45 slides par jour, c’est 3 fois moins que ce qui se fait généralement pour ce genre de formation (hors stage pratique). Sur le fond, le contenu est d’une pauvreté affligeante (nous y reviendrons plus en détail un peu plus loin). Environ 50% du support est constitué d’une multitude de copie de textes, dessins ou schémas en anglais avec la plupart du temps aucune mention de la source. Charlie a-t-il obtenu l’autorisation de plagier tous ces documents sans même mentionner leur auteur ? Le support n’est pas du tout autoporteur ce qui signifie qu’aucun slide ne comporte de phrases ou d’explications écrites de sorte que l’apprenant ne pourra jamais sans servir pour comprendre quelque chose qui lui aurait échappé lors des explications orales du formateur. Encore faut-il qu’il y ait une explication orale puisque Charlie a purement et simplement « oublié » de traiter environ une dizaine de slides… Le support ne comprend strictement aucun lien hypertexte pour accéder à des ressources complémentaires ni aucune référence bibliographique, même pas un bouquin pour préparer le CCSP ou le CCSK, c’est juste incroyable ! Conclusion et c’est un point positif, je suis finalement très content de ne pas avoir en ma possession la version électronique du document.

Contenu pédagogique

Dès les premières minutes, Charlie nous fait une présentation de
la certification CCSK en indiquant les caractéristiques d’une version malheureusement
dépassée (v3) et remplacée depuis juillet 2017 par la v4. Ensuite, un stagiaire
lui demande le tarif de la certification et il ne connait pas la réponse qui
bien sûr n’est pas mentionnée dans son support. Je m’interroge ainsi dès le
début de la formation : « Comment peut-on prétendre préparer
sérieusement à une certification quand on n’en connait même pas les
caractéristiques les plus élémentaires ? »

Je ne vais pas ici rentrer dans le détail de la formation mais je
dirais que l’on a couvert que très partiellement le programme CCSK / CCSP (env.
10 %). Il faut dire aussi qu’avec 8h30 d’enseignement réel, on ne peut pas
aller bien loin. Chaque sujet a été abordé de façon totalement superficielle
avec aucun exemple pertinent dans un contexte de Cloud. Prenons un exemple concret
« la virtualisation des serveurs » : qu’avons-nous vu sur le
sujet ? RIEN ! Pas la moindre identification d’une attaque par le soft
(Hypervisor escape, VM hopping, VM sprawl,…) ou par le hard (Meltdown, spectre,
Zombieload,…) ni même les problématiques du contrôle antiviral pour éviter un
“AV Storm”. Aucun exemple de POC sur ces attaques pour démontrer à des fins
pédagogiques qu’elles ne sont pas que théoriques. Aucune recommandation en
matière de sécurité pour durcir un hyperviseur ou pour réduire la surface
d’attaque d’un environnement virtuel. Et puis bien sûr dans le support de
cours, aucune ressource pour sécuriser la virtualisation et dieu sait qu’elles
sont nombreuses (ANSSI-2013, CSA-2015, CIS-2015, ENISA-2017, NIST-2018,…) pour
ne citer que ces quelques exemples. Pour tout cela RIEN à l’oral et RIEN à
l’écrit. C’est ce que j’appelle une formation totalement creuse, où les sujets
sont traités de façon superficielle avec strictement aucun exemple pratique ou
cas d’usage réel. Charlie préfère visiblement parler pendant 30mn du
chiffrement homomorphique que personne ne verra en production dans un
datacenter avant 2040 (dans le meilleur des cas) plutôt que de parler de BYOK
avec synchro de HSMs en mode hybride tellement plus efficace pour sécuriser les
données dans le Cloud et opérationnel depuis déjà plusieurs années.

Au final dans ces 2 jours de formation, ma prise de notes s’est
résumée à noter les erreurs, inexactitudes ou omissions du formateur. Prenons
quelques exemples sur la conformité et les aspects juridiques :

  • Je demande au formateur de nous parler du type 1 / type 2 des attestations SSAE16 non pas pour le piéger mais parce ce que c’est au programme du CCSP et Charlie me réponds : « Non, on ne voit pas ça ici » Dommage car non seulement cette différence n’est pas un détail mais en plus elle apparaît souvent dans les QCM de préparation à la certification.
  • On aborde ensuite les certifications CSA, mais hélas ce que présente Charlie n’est plus du tout d’actualité et tout a changé depuis plusieurs mois pour intégrer la conformité RGPD et des options de certification continue mais Charlie n’est toujours pas au courant. OK je veux bien mais on est quand même à 100% dans le sujet de la formation et Charlie n’est pas « Up-to- date » dans une formation « avancée ». Avec un tarif horaire de 280 € HT, ça fait quand même cher l’information obsolète.
  • On aborde ensuite le RGPD et Charlie n’as visiblement jamais entendu parler de Code de Conduite pour les fournisseurs Cloud. Alors je lui en parle et il me répond que ce n’est pas opérationnel alors que le CdC de la CSA date d’août 2018 et celui de CISPE depuis 3 ans. Par exemple AWS a adhéré au CdC CISPE avec certification tierce depuis février 2017 (soit 28 mois avant la formation).
  • Charlies affirme qu’un audit sur site est obligatoire dans le cadre du RGPD. Je lui pose alors la question « Est-ce qu’un fournisseur qui refuse l’audit sur site à un client est en non-conformité avec le RGPD » et il répond sans la moindre hésitation : OUI. Alors voilà un nouveau Scoop, en juin 2019 (un an après l’entrée en application du règlement), Amazon, Micorosoft, Google, Salesforce, OVH et compagnie seraient toujours en non-conformité avec le RGPD. C’est bien évidemment tout à fait inexact. D’ailleurs voici, par exemple, ce qui est écrit dans ce qui se fait de mieux en matière de conformité RGPD dans le cloud à savoir le Code de conduite CISPE adopté par un centaine de fournisseurs IaaS dont AWS et OVH : Chapitre 4.6 (Demonstrating compliance) à la section b (Audit) : « The Code does not require the CISP to authorise the customer or any third party to conduct an on-site audit of the CISP’s premises or facilities. Cloud infrastructure services are multi-tenant environments. This means that the data of potentially all the CISP’s customers could be hosted in the same premises or facilities. Physical access to the CISP’s facilities by a single customer or third party introduces a potential security risk for all other customers of the CISP whose data is hosted within the same premises or facilities. This risk can be controlled if, instead of an on-site audit, customers use the information provided by the CISP to reasonably verify the CISP’s compliance with the security obligations in the Service Agreement. »
  • Charlie évoque succinctement le Patriot act, qui au passage n’existe plus, sans parler de son successeur le Freedom Act ni du mécanisme d’application d’une NSL aux US ou en Europe.
  • Rien non plus sur d’autres spécificités américaines comme FISA ou le « Privacy shield ».
  • Charlie évoque le Cloud Act en oubliant de parler des « executive agreements » qui sont les éléments clés de ce mécanisme juridique sans lesquels il n’est pas utilisable. Rien non plus sur le conflit potentiel entre Cloud Act et l’article 48 du RGPD.
  • Charlie évoques vaguement la notion de BCR pour finalement ne rien dire du tout sur les conditions imposées par le RGPD sur les transferts hors UE. Les stagiaires vont donc partir sans savoir qu’un stockage dans un cloud non approprié pourrait coûter à leur entreprise 4% de leur CA ou 20M€.
  • Mais pire que ça, le terme RGPD (ou GDPR) n’est même pas mentionné une seule fois dans le support de cours y compris dans la section juridique. C’est juste HALLUCINANT ! Pourtant, le GDPR est au programme CCSP et CCSK et Dieu sait qu’il y en a des choses à dire sur le sujet. Par exemple, dans ma formation sur la conformité RGPD dans le cloud computing, je délivre plus de six heures et demi de formation avec quelques 300 slides pour décrire tous les éléments de conformité. Comprenons-nous bien, je ne reproche pas à Charlie de ne rien m’avoir appris mais de ne pas avoir fait son boulot pour les 3 autres stagiaires.
  • On ne parle pas dans la formation de la transposition de la directive NIS de 2016 dont la deadline pour les 28 pays membres était fixée 31 mai 2018 et avec elle toutes les obligations que cela impose aux fournisseurs de Cloud (FSN). C’est vraiment dommage cet oubli parce que c’est le seul et unique texte règlementaire qui s’applique directement et explicitement aux CSP. Trop récent encore un texte de mai 2018 pour une formation de juin 2019 ?
  • Bien sûr on ne parle pas du tout des normes ISO/IEC spécifiques au Cloud dont la sortie date de 2014 (ISO 27018) et de 2015 (ISO 27017). Je n’attendais évidemment pas que Charlie nous explique les nouveautés de la 27018 dans sa révision de 2019.
  • Bien entendu, comme Charlie occulte déjà les aspects juridiques qui sont au programme du CCSK et du CCSP (exemple : HIPAA pour la santé), il ne faut compter sur lui pour nous parler des spécificités françaises comme par exemple la certification HDS.
  • Charlie n’aborde pas non plus le Cybersecurity Act dont le cadre de certification (en particulier le niveau substantiel) pourrait permettre de voir émerger les premières certifications européennes pour les fournisseurs Cloud dans l’UE.
  • Pour finir, un participant interroge Charlie sur la Cyber-assurance à laquelle il répond par un exemple de rançongiciel sans rapport avec le Cloud. Je me permet alors de compléter en expliquant le rôle d’une cyber-assurance dans le Cloud qui permet de couvrir certains risques comme par exemple une sanction administrative de la CNIL. Et là Charlie me rétorque que c’est faux car des gens de la CNIL lui ont dit. Il va falloir que quelqu’un dise à Charlie que pour savoir ce que peut prendre en charge un contrat de cyber-assurance, on ne le demande pas à la CNIL (ni aux cybercriminels…) mais plutôt à une compagnie d’assurance. Ça lui évitera de dire de grosses bêtises.

Exercices et QCM d’évaluation

Au cours de la formation, Charlie nous a proposé plusieurs exercices dénués de tout intérêt pédagogique et dont le seul objectif semblait être : « gagner du temps ». Par exemple, dans le dernier exercice, Charlie demande à chaque stagiaire de choisir une mesure de sécurité dans la Cloud Controls Matrix (CCM) et de la transformer en questions à poser à un fournisseur. Très bel exercice qui demande aux stagiaires de réinventer la roue, puisque ce travail a déjà été réalisé par la CSA (questionnaire CAIQ) et au passage cela permet à notre ami Charlie de se reposer un peu et de vaquer à ses occupations pendant plus de 20 minutes. Ah oui, j’oubliais les 8h30 de formation, c’est avec les 3 exercices et les 2 QCMs. Si l’on ne comptabilise que le temps où Charlie anime véritablement la formation, on tourne aux alentours de 7 heures (on passe maintenant à 345 € HT l’heure de formation).

Terminons ce débriefing de la formation de notre ami Charlie en
parlant du QCM proposé en fin de formation. Ça peut paraitre une bonne idée de
faire passer un QCM à des stagiaires qui préparent une certification basée
justement sur un QCM (Bien qu’il serait préférable que cela se fasse en dehors
du temps de formation). Le QCM que nous propose Charlie est constitué de 18
questions toutes intégralement copiées soit sur des ouvrages de préparation au
CCSP soit sur des sites Internet ce qui en fait une violation de propriété
intellectuelle. Charlie est tellement soucieux de protéger sa PI, qu’il ne
donne pas ses slides aux clients qui ont payé sa formation mais par contre il
n’hésite pas à copier (sans payer, ni même mentionner la source) des questions
qu’il utilise sans gêne dans une formation payante. Ce formateur ne manque visiblement
pas de cran ! Ensuite, on passe 30 minutes à répondre à 18 questions et
lors de la correction Charlie se contente de donner une rapide explication à
seulement 5 des 18 questions. Doit-on lui rappeler qu’à son tarif horaire, son
plagiat  de 18 questions revient à 150 € pour
chaque stagiaire. Charlie doit certainement savoir que pour 25€ sur Amazon, on
peut acheter le livre « CCSP Official ISC2 Practice
Tests » qui propose 1 000 questions avec 1 000 réponses explicatives
détaillées ? 55 fois plus de questions toutes corrigées pour un prix
divisé par 6, qui dit mieux ? Où est la valeur ajoutée de ce QCM pour
quelqu’un qui veut préparer la certification ? Dans cet exercice, mon
voisin de droite qui n’a eu que 40% de bonnes réponses. Mais avec seulement 5
réponses expliquées, qu’a-t-il vraiment appris avec ce QCM ?

Synthèse de cette formation CCSK / CCSP

  • 7h de formation effective pour une durée annoncée de 14h
  • Tarif exorbitant de 345 € HT / heure
  • Environ 10% du programme traité en distillant quelques informations sur le sujet qui seront au choix (non exclusif) : inexactes, dépassées, imprécises ou incomplètes
  • Support de cours d’une pauvreté affligeante avec aucune référence externe
  • Exercices dénués de tout intérêt pédagogique
  • Nombreux sujets importants non abordés : BYOK, SDN, GDPR, Fédération d’identité,…
  • Formation 100% théorique avec strictement aucune illustration pratique
  • QCM intégralement pompé sur Internet avec 5 questions corrigées sur 18.

Conclusion

Je n’aurai jamais imaginé en m’inscrivant à cette formation que son seul intérêt serait de me donner matière à écrire un article sur cette triste expérience. J’ai bien entendu fait part de mon mécontentement au formateur par un retour détaillé adressé par email dès le lendemain de la formation. J’ai aussi demandé et obtenu que l’organisme de formation ne facture pas cette formation au FAFIEC. Même si cela ne coûtait absolument rien à ma société puisque la prise en charge était de 100%, j’en ai fait une affaire de principe dont je tire les 2 enseignements suivants :

(1) Concernant les questions

La qualité des réponses aux questions ne dépend absolument pas du type de formation (présentiel vs distanciel) mais de la compétence et de la motivation du formateur. On dit souvent qu’un des gros avantages du présentiel par rapport au e-learning c’est que l’on peut poser des questions et avoir tout de suite des réponses. Dans la formation dont il est question ici, je n’ai finalement posé que 2 questions : La première portait sur les différences dans SSAE16 entre type 1 et type 2 et on m’a répondu que ce n’était pas au programme (ah bon ?) et la deuxième était sur la conformité RGPD et la réponse était inexacte. Alors, oui les stagiaires aiment bien avoir des réponses à leurs questions. Mais à votre avis que préfèrent-ils ? Qu’on ne leur réponde pas ou qu’on leur donne des mauvaises réponses ou au contraire qu’on leur réponde avec exactitude et précision même si la réponse n’arrive pas dans la minute ?

(2) Concernant le tarif

On le sait, le tarif d’un produit ou d’un service ne fait pas sa qualité. Mais ici, soyons factuels ! En partant des horaires on obtient 9h30 de présence mais en enlevant tous les moments où le formateur ne dit pas un mot (pauses, exercices et QCM), on arrive à 7 heures d’animation effective. Avec une formation tarifiée à 2 420 € HT, l’animation coûte donc (pour chaque participant) 345 € HT de l’heure. Tarif qu’il faut bien sûr remettre en perspective avec le programme traité superficiellement et saupoudré d’informations inexactes, dépassées, imprécises ou incomplètes. Pour information, au moment où j’écris ces lignes, je suis en train de réaliser pour VERISAFE une formation de préparation à la certification CCSK en E-learning dont les caractéristiques (non définitives) seront les suivantes : 12 heures de formation, 400 slides, 150 QCM.

En conclusion, je pense qu’il est impossible d’obtenir la
certification CCSK après avoir suivi cette formation en présentiel sur 2 jours
(et même en ayant suivi la session de 4 jours avec ce formateur) et je ne parle
même pas de la certification CCSP de l’ISC2 qui est encore plus
difficile à obtenir. En ce qui me concerne, cette expérience me motive encore
plus à vouloir produire des formations de qualité pour donner à chacun le maximum
de chance de réussir leur certification (CCSK, CCSP ou CISSP).



Les risques dans le Cloud (CESIN)

|

Afin de mieux cerner la perception de la cybersécurité et ses enjeux au sein des grandes entreprises françaises, le CESIN a publié en janvier la 4ème édition de son baromètre annuel. Dans ce sondage réalisé par OpinionWay, les membres de l’association ont répondu à des questions concernant les risques dans le Cloud dont je vous propose ci-dessous une petite synthèse en vidéo.

Cette vidéo est un court extrait (5mn) de notre formation Cybercurité Synthèse Technique désormais disponible en e-learning. Dans la formation, une cartographie plus complète des risques est abordée ainsi que les mesures adaptées pour les traiter.



Faut-il avoir peur du CLOUD Act ?

|

Précisons tout d’abord que le terme CLOUD Act est en fait l’acronyme de Clarifying Lawful Overseas Use of Data Act que l’on pourrait traduire par « Loi pour clarifier l’utilisation légale des données à l’étranger ». En pratique, il s’agit d’un (minuscule) texte de 32 pages glissé incognito dans les quelques 2 232 pages de la loi sur les dépenses 2018 des États-Unis. Ce texte, qui n’a fait l’objet d’aucun débat au Congrès, n’a été médiatisé qu’après sa promulgation par Donald Trump le 23 mars 2018 mettant ainsi l’Europe et le reste du monde devant le fait accompli.

Le CLOUD Act permet de lutter efficacement contre la criminalité au niveau mondial et s’applique dans le cadre d’une procédure pénale suite à un crime ou un délit. Comme toute requête ne doit cibler qu’une personne ou qu’un seul élément identifiant en particulier, le CLOUD Act ne peut (à priori) servir à la réalisation d’opération de surveillance massive comme celles de la NSA révélées par Edward Snowden.

Cette Loi vient combler le vide juridique du Stored Communication Act (SCA) mis en lumière par l’affaire qui opposait depuis 2013 Microsoft à la justice US pour l’accès aux mails d’un présumé trafiquant de drogue stockées en Irlande.

Le CLOUD Act prévoit que les gouvernements étrangers puissent s’engager avec le gouvernement américain par le biais d’accords bilatéraux (executive agreement) afin de « fluidifier » l’accès aux données. Grâce à ce mécanisme et sous réserve que la cible ne soit pas un citoyen américain, l’entraide judiciaire se substitue aux accords d’assistance mutuelle classiques MLAT (Mutual Legal Assistance Treaty) dont la lourdeur impose un délai de plusieurs mois pour pouvoir accéder à des données à l’étranger.

La Loi prévoit également qu’un fournisseur US puisse s’opposer dans un délai de 14 jours à une telle demande s’il pense que la personne visée n’est pas un ressortissant américain et que la divulgation l’obligerait à enfreindre la réglementation du pays hébergeant les données. Sa demande sera alors portée devant un tribunal américain qui devra statuer selon les arguments avancés par les deux parties (Police US / Fournisseur US).

Trois questions se posent alors :

  • Le CLOUD Act sera-t-il toujours utilisé exclusivement pour lutter contre la criminalité et en aucun cas pour de la surveillance à des fin politiques, stratégiques ou économiques ?
  • L’article 48 du RGPD, parfois appelé bouclier Anti NSA, sera-t-il suffisamment protecteur pour empêcher les services américains d’accéder librement aux données des fournisseurs américains situées au sein de l’UE ?
  • L’UE doit-elle s’engager dans ce processus en signant un « executive agreement » avec le gouvernement américain ?

Pour la dernière question, il semble évident que l’Union ne doit pas accepter de signer un accord au terme duquel les Etats-Unis, en raison principalement de l’hégémonie des GAFAM, auraient accès aux données des citoyens européens, quel que soit leur lieu de stockage, tandis que les autorités européennes pourraient seulement accéder à des données stockées aux Etats-Unis en excluant toute donnée concernant des citoyens américains.

La seule attitude possible pour l’Union européenne, dans un souci de réciprocité et de juste équilibre entre la nécessité de lutter contre la criminalité et la protection des citoyens européens, serait de négocier avec les Etats-Unis un accord par lequel les autorités de chaque pays auraient accès de manière fluide aux données nécessaires à la lutte contre la criminalité, et à elles seules uniquement, sans considération de  leur lieu de stockage et sans discrimination sur la nationalité des personnes ou des entreprises concernées.



Les points clés du RGPD

|

Le nouveau règlement européen pour la protection des données personnelles (RGPD) entrera en application le 25 mai 2018. Ce règlement concerne tous les organismes (publics ou privés) qui traitent des données à caractère personnel de citoyens européens même si le traitement ne s’opère pas sur le territoire de l’union. A moins de trois mois de la date fatidique, nous vous proposons une synthèse, en vidéo, des points essentiels à retenir de ce règlement.



Retour sur la cyberattaque Wannacry

|

Le 12 mai dernier, une cyberattaque dénommée « Wannacry » défrayait la chronique. Dans cette présentation vidéo, je vous décris le fonctionnement de Wannacry et vous explique le lien avec les failles de sécurité Windows et les outils de la NSA ainsi que le rôle joué par le groupe de hackers « The shadow brokers ».  Enfin, j’évoque quelques bonnes pratiques et les enseignements que l’on peut tirer de cette cyberattaque quelque peu surmédiatisée.



Le référentiel ANSSI SecNumCloud

|

Le référentiel de qualification des prestataires de services d’informatique en nuage (SecNumCloud) vient enfin d’être publié par l’ANSSI. Qu’apporte t-il par rapport à une certification ISO 27001 ? Donne t-il toutes les garanties de sécurité attendues par les clients ? Nous vous proposons une analyse détaillée de ce référentiel avec en particulier un focus sur 50 exigences. Au-delà de la qualification des prestataires, découvrez comment SecNumCloud peut vous permettre d’évaluer la sécurité de vos fournisseurs.

Sommaire de la présentation

  1. Historique du référentiel
    • De la version 1.3 à la version 3.0
  2. SecNumCloud v3.0 et les normes ISO relatives au cloud
    • Normes ISO/IEC : 17788, 17789, 27017 et 27018
  3. Focus sur 50 exigences pour les prestataires (CSP)
  4. Zoom sur 4 recommandations pour les commanditaires (clients)
    • + 2 recommandations importantes additionnelles
  5. Conclusion
    • Le référentiel SecNumCloud est-il pertinent ?
    • Quel usage peut-on en faire en tant que CSP ?
    • Quel usage peut-on en faire en tant que Client ?

La vidéo d’environ 45mn ainsi que les slides de la présentation sont réservés aux membres enregistrés sur le blog. N’hésitez pas à vous inscrire gratuitement ou utiliser votre compte LinkedIn, Google, Microsoft, Twitter ou Facebook pour pouvoir y accéder.
Pour les personnes non inscrites, un extrait de la présentation est disponible ici.

Les slides de la présentationBouton PDF



Privacy Shield : Bouclier ou passoire pour les données européennes ?

|

Suite à l’invalidation du Safe Harbor par la CJUE le 6 octobre 2015 (voir à ce sujet notre article La CJUE invalide le Safe Harbor), la Commission européenne a adopté le 12 juillet 2016 une décision d’adéquation visant à reconprivacy-shieldnaitre au mécanisme « EU-U.S. Privacy Shield » (bouclier de protection des données UE-États-unis) un niveau de protection « équivalent » aux exigences européennes. Ce nouvel accord a pour effet d’autoriser les transferts de données à caractère personnel depuis l’Union européenne vers les entreprises établies aux Etats-Unis utilisant ce dispositif.

Afin de garantir la conformité aux exigences de l’europe en matière de traitement des données, l’accord définit des « Privacy Shield Principles » auxquels les entreprises se doivent d’adhérer et de respecter. Toute entreprise qui viole ces principes peut être sanctionnée et doit mettre fin à l’utilisation des données collectées.

Le Privacy Shield constitue une réelle avancée dans la protection des données européennes en prenant en compte les recommandations formulées par la Commission européenne en novembre 2013 mais également certaines exigences énoncées par la CJUE dans son arrêt du 6 octobre 2015. Pour avoir une vue d’ensemble des principales nouveautés de ce dispositif, on pourra consulter la FAQ publiée par la Commission européenne le 12 juillet.

Selon Maximilien Schrems, citoyen européen à l’origine de l’invalidation du Safe Harbor, « le bouclier Vie privée est le produit de la pression des États-Unis et de l’industrie des technologies et non le fruit d’une démarche rationnelle ou de considérations raisonnables. Il est un peu plus qu’une petite mise à jour de Safe Harbor, mais non un nouvel accord ».

Voici les principaux reproches que l’on peut formuler à cette décision d’adéquation :

  • Tout comme le Safe Harbor, le principe de certification est déclaratif basé sur le principe de l’auto-régulation. En d’autres termes, pour collecter des données européennes, les entreprises américaines n’ont qu’à s’auto-proclamer « Privacy Shield Compliant ». Et bien évidemment la liste des entreprises certifiées est déja longue.
  • Le Privacy Shield n’interdit pas l’accès au contenu des communications par les services de renseignement américains. Bien sûr dans le texte, il n’est pas question de parler de « surveillance de masse » mais plutôt de « collecte ciblée ». Dans sa rédaction actuelle, le Privacy Shield ne semble pas respecter l’arrêt de la CJUE du 6 octobre 2015 considérant que la collecte effectuée par l’administration des États-Unis était contraire à la Charte des droits fondamentaux de l’Union européenne.
  • Pour répondre aux exigences de la CJUE et du G29, un médiateur (Ombudsman) est chargé de traiter les plaintes de tout citoyen européen qui conteste un traitement ou une surveillance illégale. Mais quelle peut-être l’indépendance de ce médiateur dès lors qu’il est nommé par le Secrétaire d’État américain ? D’autre part, le médiateur ne pourra ni confirmer ni infirmer que les États-Unis se sont livrés à une surveillance du plaignant. L’ombudsman devra conclure en disant si les lois américaines ont été respectées ou que le problème de non-conformité a bien été résolu. Naturellement, aucune institution européenne ne sera habilitée à inspecter les Datacenters ou les logiciels américains. Dans ces conditions, le plaignant n’aura strictement aucun regard possible sur la réalité de la surveillance effectuée.
  • Le Privacy Shield ne se substitue pas aux deux alternatives actuellement en vigueur que sont les clauses contractuelles types (EU model clauses) ou les règles internes d’entreprises (BCR). En conséquence, si une entreprise couverte par le Privacy Shield s’en fait exclure pour non-respect des obligations, elle pourra quand même continuer à traiter les données via l’un des deux mécanismes précédemment cités.
  • La conservation des données n’est pas limitée dans le temps. Les sociétés américaines peuvent donc utiliser les données aussi longtemps qu’elles le souhaitent tant que cela sert l’objectif pour lequel elles ont été initialement collectées ou ultérieurement autorisées.
  • Même si une révision annuelle est prévue, il parait surprenant que l’accord porte uniquement sur les exigences de la Directive 95/46/EC alors même qu’un nouveau règlement européen  plus contraignant entrera en vigueur le 25 mai 2018 et abrogera la directive de 1995. Pourquoi n’a t-on pas prévu une clause de suspension afin de prendre en compte les exigences du nouveau règlement dans un nouvel accord UE/US ? Pourquoi la Commission européenne veut-elle alourdir les contraintes réglementaires sur les entreprises européennes alors que dans le même temps elle semble se satisfaire des promesses des sociétés américaines ?

Compte tenu des réserves que nous venons d’évoquer, il n’est pas impossible de voir le Privacy Shield faire l’objet d’un recours devant la CJUE, seule compétente pour constater la validité d’un acte de l’union conformément à l’article 263 du Traité sur le fonctionnement de l’Union européenne (TFUE).



10 recommandations pour maîtriser les risques dans le Cloud

|

Le Cesin (Club des Experts de la Sécurité de l’Information et du Numérique) en collaboration avec la CNIL, l’ANSSI et des juristes spécialisés vient de publier 10 recommandations pour maîtriser les risques dans le Cloud computing. Chez Verisafe, nous travaillons sur la sécurité du Cloud depuis plus de 6 ans et nous avons créé la méthodologie EFICAS (Evaluation Formelle et Indépendante du Cloud pour l’Adopter en toute Sécurité) destinée justement à maîtriser les risques dans le Cloud. Il nous est donc apparu intéressant d’analyser et de commenter les 10 recommandations du Cesin et de faire le lien éventuel avec notre méthodologie EFICAS.

Recommandation 1 : Estimez la valeur des données que vous comptez externaliser ainsi que leur attractivité en termes de cybercriminalité.

Comment estimer la valeur de nos données ? Quel sont les critères de valorisation ? Il s’agit ici de classifier les données que l’on souhaite externaliser. En pratique, cette classification dépendra du type de données utilisées. Pour des données de bureautique, elle peut être relativement simple comme par exemple une classification sur 5 niveaux basée sur deux critères : confidentialité et conformité.

classif

Mais pour d’autres projets Cloud, ce type de classification peut s’avérer totalement inadapté. Par exemple, dans un projet IoT où les objets connectés remontent des informations dans le Cloud, les critères de disponibilité et d’intégrité seront sans doute plus pertinents. Prenons l’exemple de sondes thermiques qui remontent des valeurs de température dans le Cloud. Ces données ne sont à priori pas confidentielles ni réglementées mais leur altération ou leur indisponibilité pendant une longue durée  peut s’avérer critique. Dans la méthodologie EFICAS, nous préconisons de classifier toutes les données que l’on souhaite héberger dans le Cloud. Pour cela, nous avons développé une grille modulaire permettant de classifier facilement tout type de données qu’il s’agisse de données issues d’un SI classique, d’un réseau industriel ou du monde de l’Internet des objets.  Dans notre méthodologie, la classification des données n’est pas une étape strictement obligatoire mais elle permet, lorsqu’elle est réalisée, d’industrialiser le processus EFICAS pour un ensemble de projets.

Recommandation 2 : S’il s’agit de données sensibles voire stratégiques pour l’entreprise, faites valider par la DG le principe de leur externalisation

Sur le principe, cette recommandation tombe sous le bon sens mais en pratique, c’est quoi une donnée sensible ou une donnée stratégique ? Une DCP (Donnée à caractère personnel), c’est une donnée sensible ? La propriété intellectuelle dans le projet X c’est sensible ou stratégique ? Les données commerciales de l’agence Y, c’est sensible ? Au final, il sera difficile de savoir à quel moment et pour quel type de données, il convient d’obtenir une aval de la DG. Dans la méthodologie EFICAS, nous considérons qu’une validation par la DG est importante mais il ne s’agit en aucun cas de valider le principe de l’externalisation mais uniquement de valider les écarts entre risques tolérés par l’organisme et risques dans le Cloud après avoir epuiser tous les recours traditionnels de réduction des risques.

Concernant l’attractivité de vos données en termes de cybercriminalité, il s’agit effectivement d’un élément important qui permettra d’établir un niveau de menace sur vos données. Si vous stockez dans le Cloud des données sans aucun intérêt pour un concurrent, une agence de renseignement ou un cybercriminel, la faible attractivité de vos données entrainera un faible niveau de menace. Par contre, si vous stockez dans le Cloud des données de propriété intellectuelle stratégiques ou les numéros de carte bancaire de vos clients, l’attractivité sera radicalement différente et donc le niveau de menace bien plus élevé. Ce niveau de menace sera utile dans le processus d’analyse de risque lorsqu’il s’agira d’évaluer la probabilité d’occurrence des incidents de sécurité.

Recommandation 3 : Evaluez le niveau de protection de ces données en place avant externalisation.

C’est un élément également pris en compte dans la méthodologie EFICAS. En effet, le niveau de protection des données mis en œuvre dans l’organisme donne une première indication sur l’importance que l’entreprise accorde à ces données. Par exemple, le fait que les données soient stockées en clair (non chiffrées) et accessibles à un très grand nombre d’utilisateurs traduira sans doute une faible sensibilité de ces données en terme de confidentialité. Il s’agira alors de vérifier que dans le Cloud les données sont aussi bien, voire mieux protégées qu’en interne dans votre entreprise.

Recommandation 4 : Adaptez vos exigences de sécurité dans le cahier des charges de votre appel d’offre en fonction du résultat du point 1.

Les exigences de sécurité peuvent effectivement être définies selon la valorisation des données issues de l’étape 1 mais également de l’étape 3. Il est en effet assez courant d’être beaucoup plus exigeants sur le niveau de sécurité d’une prestation externalisée que sur le même type de prestation réalisée en interne. Reste à savoir si ces exigences plus fortes vis-à-vis du prestataire sont justifiées. Dans la méthodologie EFICAS, plutôt que de partir sur des exigences de sécurité souvent difficiles à établir et à valoriser, nous démarrons le processus sur la base d’une cartographie des risques établis spécifiquement pour le Cloud computing. L’étape initiale consiste pour l’organisme à définir son niveau de tolérance pour chaque risque identifié.

Recommandation 5 : Effectuez une analyse de risque du projet en considérant les risques inhérents au cloud comme la localisation des données, les sujets de conformité et de maintien de la conformité, la ségrégation ou l’isolement des environnements et des données par rapport aux autres clients, la perte des données liée aux incidents fournisseur, l’usurpation d’identité démultipliée du fait d’une accessibilité des informations via le web, la malveillance ou erreur dans l’utilisation, etc. Sans oublier les risques plus directement liés à la production informatique : la réversibilité de la solution et la dépendance technologique au fournisseur, la perte de maîtrise du système d’information et enfin l’accessibilité et la disponibilité du service directement lié au lien Internet avec l’entreprise.

Une analyse de risque constitue bien évidemment une approche pertinente mais ici le Cesin n’identifie qu’une dizaine de risques et ne donne aucune indication pour les traiter. La méthodologie EFICAS établit une cartographie exhaustive des risques dans le Cloud (42 risques) et propose un arsenal complet de mesures spécifiquement adaptées aux problématiques dans le Cloud (CCM v3 de la CSA, ISO 27017 de l’ISO, contrat de cyber-assurance, …).

Après avoir sélectionné les risques pertinents dans le catalogue, Il faut ensuite être en mesure d’évaluer son propre niveau de tolérance aux risques. Dans un deuxième temps, il faut évaluer le niveau réel des risques dans le projet Cloud envisagé. La méthodologie EFICAS fournit aux entreprises tous les livrables nécessaires à la réalisation de ces deux étapes particulièrement délicates.

Recommandation 6 : Outre ces sujets, exigez un droit d’audit ou de test d’intrusion de la solution proposée.

« Exigez », c’est vite dit ! Demandez donc à Amazon, Google ou Microsoft un audit de sécurité sur leur infrastructure Cloud public. La réponse sera toujours négative. Vos exigences n’étant pas acceptées, que faire maintenant ? En pratique, la recommandation du Cesin n’est quasiment jamais applicable dans le cas d’un Cloud public. C’est la raison pour laquelle la méthodologie EFICAS propose une approche radicalement différente pour évaluer le niveau de sécurité du prestataire.

Recommandation 7 : A la réception des offres analysez les écarts entre les réponses et vos exigences.

Comme on vient de le voir à l’instant, on ne peut que rarement recourir à l’audit dans un Cloud public. Pour l’organisme client, il sera  donc impossible de vérifier l’adéquation du niveau de sécurité du prestataire avec ses exigences. Comme indiqué lors de la recommandation (4), la méthodologie EFICAS permet d’établir une grille de tolérance aux risques plutôt qu’une liste d’exigences. Puisque l’audit n’est pas possible, EFICAS définit une liste d’évaluation des risques auquel l’organisme s’exposera dans le Cloud. Il suffira ensuite de contrôler les écarts entre risques tolérés par l’organisme et risque exposés dans le projet Cloud et de traiter les risques inacceptables avec les mesures spécifiquement adaptées au Cloud (CCM v3, ISO 27017, ISO 27018, assurance, …).

Recommandation 8 : Négociez, négociez.

Dans le Cloud et contrairement aux contrats d’infogérance classique les négociations avec le fournisseur sont assez limitées et parfois même inexistantes. On constate en effet aujourd’hui un déséquilibre de rapports de force entre les entreprises clientes et les fournisseurs. Ces derniers proposent le plus souvent des contrats standards non négociables. Pour bien comprendre cette difficulté, on peut citer l’expérience réelle d’une grande entreprise française du CAC 40 qui souhaitait négocier de nouvelles clauses de sécurité avec Google Inc. au lendemain des révélations d’Edward Snowden. Après de multiples tentatives y compris un rendez-vous avec la direction au siège social de Google France à Paris, le fournisseur américain a rejeté toutes les demandes du client et n’a en conséquence modifié aucune clause contractuelle. Face à Amazon, Google, Salesforce ou Microsoft, le rapport de force est souvent à l’avantage des fournisseurs américains même pour une grande entreprise cliente. Il va sans dire que les possibilités de négociation sont encore plus hypothétiques pour une PME ou une collectivité territoriale.

Recommandation 9 : Faites valider votre contrat par un juriste. Si vous êtes une entreprise française, ce contrat doit être rédigé en français et en droit français.

Cette recommandation ne pose généralement pas de problème aux fournisseurs. Attention cependant à ne pas tomber dans l’excès comme l’ANSSI l’a fait dans son référentiel de qualification de prestataires de services sécurisés d’informatique en nuage. Si l’on suit les exigences de l’agence (localisation  des données exclusivement sur le territoire français, support de premier niveau francophone localisé en France, contrat de droit français, tribunal compétent français), on risque fort de se retrouver devant une offre Cloud extrêmement limitée qui ne répondra pas aux attentes des métiers.

Recommandation 10 : Faites un audit ou un test d’intrusion avant démarrage du service (si cela est possible) et assurez-vous du maintien du niveau de sécurité de l’offre dans le temps.

On entre encore ici dans une difficulté particulière du Cloud, le contrôle de la sécurité. Comme le Cesin le sous entend en précisant « si cela est possible », les audits ne sont généralement pas admis sur une infrastructure Cloud public. Les fournisseurs acceptent plus souvent les tests d’intrusion (sur un périmètre précis) mais leur intérêt est extrêmement limité pour ne pas dire quasi nul. L’approche pragmatique de la méthodologie EFICAS permet de vérifier le niveau de sécurité du fournisseur même lorsqu’un audit n’est pas réalisable. La vérification est basée sur un questionnaire spécifique transmis au fournisseur. Elle est complétée par un contrôle approfondi des certificats de sécurité (ISO 27001, CSA STAR, ISAE3402, Privacy Shield, etc…).

D’autre part, la méthodologie EFICAS met l’accent sur le contrôle continu de la sécurité pendant toute la durée du contrat. Elle établit une liste de contrôles et une description détaillée de chaque paramètre de sécurité, ce qu’il faut mesurer et comment le mesurer. Parmi les paramètres de sécurité, on trouve par exemple la disponibilité du service, la réponse aux incidents, la gestion du cycle de vie des données, la conformité réglementaire, la gestion des vulnérabilités, le chiffrement des données, etc..