SecurityInsider
Le blog des experts sécurité Wavestone

BYOI : Bring Your Own Illusion ou le mirage de la crypto dans le Cloud


Face à une migration plus ou moins forcée vers le Cloud Public, décision parfois prise au plus haut niveau, les équipes sécurité se retrouvent à devoir accompagner un changement qu’elles ne peuvent empêcher. Contraintes de devoir limiter les dégâts dans l’une des pires situations envisagées, l’envoi des données dans un Cloud « étranger », la cryptographie apparait comme l’un des meilleures options.

Si un système de chiffrement bien implémenté permet en effet de fortement réduire certains risques, de nombreux produits procurent plus une illusion de sécurité qu’un apport réel. Ce post explore quelques-uns de ces cas avant d’étudier les raisons de l’efficacité d’argumentaires basés sur la maîtrise des clefs et autres appuis sur des HSM ou des cartes à puces.

D’autre part, selon le niveau de sécurité il n’est pas illégitime, quoique généralement considéré comme politiquement incorrect, de poser cette question : in fine cette tendance n’aurait-elle pas un impact positif ? En effet selon le niveau de maturité de l’entreprise, il est parfois préférable de placer les données chez Google, Microsoft ou Amazon plutôt qu’en interne.

Modélisation des menaces

Avant de mettre en place des mesures, il convient d’évaluer le modèle de menace : contre qui et quoi l’entreprise doit elle se protéger et avec quels moyens ?

Agence de renseignement

L’une des demandes les plus fréquentes adressée lors d’analyse de risques est de savoir comment se protéger contre un accès aux données par une agence de renseignement étrangère (la plupart du temps l’hébergeur étant américain, la demande concerne la « NSA et le Patriot Act ») et surtout quels outils mettre en œuvre.

Avant d’aller plus loin, mis à part un nombre très réduit d’entreprises disposant d’un niveau particulièrement élevé de maturité et de l’appui d’un service de contre intelligence compétent, il est complètement illusoire de penser pouvoir se protéger d’une agence de renseignement de ce type en saupoudrant quelques systèmes cryptographiques accompagnés de quelques process.

Même le déploiement de plusieurs niveaux de chiffrement, y compris en utilisant des produits certifiés par une agence de sécurité hors monde anglo-saxon n’empêchera pas l’accès aux données, tout au plus compliquera-t-il la tâche :

  • La plupart des systèmes cryptographiques utilisés sont d’origine anglo-saxonne et sont potentiellement backdoorés. La NSA et le GCHQ ont des programmes entiers consacrés au sabotage de système cryptographiques (BULLRUN et EDGEHILL selon les documents d’E. Snowden). Voir une synthèse ici [OSS], ici [GUARDIAN], ici [PROPUBLICA] et ici [PARLEMENT EU]. 



  • Même en utilisant un produit souverain, hors cas très particuliers, celui-ci :





  • Le produit est très souvent mal implémenté ou mal utilisé
  • Au pire des cas il suffit de pénétrer l’entreprise par une attaque ciblée (technique ou par manipulation/pression sur des personnes clefs) 


  • Si on parle beaucoup du Patriot Act et autres outils juridiques américains, il est important de ne pas faire un focus obsessionnel sur ce seul cas et de rappeler que de nombreux autres pays disposent de lois similaires (et souvent avec un moindre niveau de rétrocontrôle parlementaire) donnant des accès encore plus larges et moins contrôlés qu’aux USA, y compris dans des pays européens [Hogan Lovells : « A Global Reality: Governmental Access to Data in the Cloud]. Notons en particulier que pour la plupart des cas étudiés l’accès aux données est bien évidement possible sur demande du gouvernement en question mais le provider Cloud peut être également contraint de ne pas notifier le client (et ce malgré toutes les clauses contraires qui auraient pu être ajoutées au contrat).

    Répétons-le encore une fois, mis à part quelques acteurs particulièrement matures (et encore des entreprises stratégiques ou des gouvernements n’y arrivent pas toujours, même sur des réseaux classifiés…), il ne faut pas non plus se faire d’illusions sur la capacité de l’entreprise à résister à une attaque d’une agence de renseignement : si une agence de premier rang veut accéder à son SI, elle accédera à son SI.

    Autant accepter et définir par qui les données seront lues et se concentrer dans un premier temps les efforts sur des mesures empêchant un attaquant de moindre niveau de compromettre le SI en quelques heures/jours avant de dépenser des moyens considérables sur un objectif aussi ambitieux.

    Ce qui ne veut pas dire que les acteurs pour qui ce type d’attaquant fait partie du modèle de menace ne doivent pas mettre en place des moyens importants ; ne serait-ce que pour complexifier suffisamment l’attaque, la rendre couteuse et augmenter les chances de détection.

    D’autre part même pour une entreprise ne pouvant espérer lutter efficacement contre ce type d’attaquant, l’usage d’un système de chiffrement même perfectible est un moyen d’augmenter le coût de l’attaque et de ne pas offrir sur un plateau d’argent les données (ex : PRISM) et au moins forcer l’attaquant à dépenser un peu de ressources pour une attaque un minimum ciblée.

    Dans tous les cas il est important de connaitre son modèle de menace et de ne pas se faire trop d’illusions sur le niveau de sécurité qu’une entreprise « normale » est capable d’atteindre.

    Opérateur Cloud

    Pour donner une vision terrain et souvent considérée comme politiquement incorrecte : aussi rassurant soit-il de penser que les données sont plus en sécurité car les serveurs sont « dans » l’entreprise, la réalité est qu’il serait parfois de loin préférable de les placer chez un opérateur de Cloud (même américain) compétent plutôt qu’en interne ou chez un prestataire « souverain » incompétent.

    Les données sont-elles plus en sécurité au sein d’une entreprise dont le SI s’est fait complètement compromettre en quelques jours lors du derniers test d’intrusion (qui de plus n’a pas été détecté par le couteux SOC mis en place) ou dans le SI d’un géant américain employant parmi les meilleurs experts et ayant un système de loin plus proche de l’état de l’art ?

    La réponse à cette question dépendra des données considérées et de la capacité de l’entreprise à créer un système sécurisé. Il n’y a pas de réponse universelle, mais le point mérite d’être soulevé et étudié.

    L’accès aux données par l’opérateur peut être cependant limité par la mise en place d’un système de chiffrement géré indépendamment par l’entreprise et permettant de dissocier l’accès aux données du medium de stockage au profit d’un bon chiffre.

    Autres acteurs

    La liste habituelle des autres menaces (attaquants externes, internes, administrateurs, etc) est bien sûr à considérer.

    Étude de quelques illusions

    Illusion 1 : « mon opérateur est français donc souverain et je suis protégé » 

    Il est souvent et malheureusement à tort considéré que parce qu’une entreprise est française quelle est automatiquement souveraine et que les données sont automatiquement protégées. Comme l’a très justement rappelé l’ANSSI lors de son intervention le mois passé à la JSSI, la nationalité d’un produit n’induit pas nécessairement la souveraineté.

    Dans un paradigme internet ou les frontières importent peu, en quoi le fait que les données sont stockées sur le sol français vont-elle apporter une protection particulière vis-à-vis d’une attaque du SI ? Tout au plus cela facilite une action légale et une saisie des serveurs par les autorités, mais le niveau de sécurité dépend in fine plus du niveau de compétence de l’opérateur et de l’attaquant considéré que de la nationalité.

    Illusion 2 : « j’ai chiffré ma base de donnée dans le Cloud, « on » ne peut pas accéder aux données »

    « L’inviolabilité du cryptement militaire AES-256 couplée à un mot de passe aléatoire de 22 caractères garanti la confidentialité des données, il faudrait des milliers d’années pour casser cette clef » fait partie (malheureusement) partie des arguments entendus en réunion.

    Il est primordial de définir ce qui est entendu par le « on » et surtout où est opéré le chiffrement des données.

    Le « on » signifie-t-il l’opérateur Cloud ? En ce cas la mesure est efficace, si outre une implémentation correcte, les opérations de chiffrement sont opérées en dehors du cloud. En effet si les opérations de chiffrement et déchiffrement ont lieu sur un serveur du Cloud cela signifie que la clef de chiffrement et les données en clair sont présentes à un moment donné, même de façon très brève en mémoire et que l’opérateur en maitrisant l’hyperviseur est mesure de contrôler la couche au-dessus (absence de Trusted Computing Base, la base minimum ici étant celle de l’opérateur). La confidentialité ne peut être garantie (note, le cas d’usage avec un HSM est traité après).

    Pour faire un parallèle avec un objet physique , c’est comme mettre un document sous clef dans un coffre chez un tiers que l’on ne considère pas de confiance et feuilleter le document page par page dans la pièce. Si celle-ci a été piégée (ex : caméra enregistrant les données ou la forme de la clef pour la reproduire), forcer le coffre n’est pas nécessaire.

    Illusion 3 : « j’ai chiffré mes mails, le risque d’atteinte à la confidentialité est traité »

    Le chiffrement est souvent vu à tort comme une solution magique permettant de résoudre tous les problèmes de confidentialité et d’intégrité.

    Si l’on passe outre les problèmes d’implémentation, que l’on considère uniquement un accès au niveau du cloud dans le modèle de menace et que l’on suppose que le chiffrement est opéré sur un système hors cloud (passerelle de chiffrement ou sur le terminal client), un risque de fuite d’information par les métadonnées est toujours présent. Dans le cas de GPG ou de S/MIME par exemple, si le corps du message est chiffré, il n’en va pas de même du sujet ni des destinataires, heure d’envoi et taille des messages.

    L’auteur a pu par exemple constater lors d’un audit que des avocats travaillant sur une opération d’acquisition avaient pris l’habitude de chatter en utilisant les sujets des mails (c’était « pratique, car le contenu apparaissait en bas à droite de l’écran et il n’était pas nécessaire de quitter word »).

    Dans d’autres cas le seul fait d’avoir la liste des destinataires et la fréquence de communication permet d’obtenir l’information souhaitée (il s’agit de l’équivalent des fadettes dans le mode de la téléphonie).

    Un exemple assez parlant de l’analyse de métadonnées peut être trouvé ici [IOACTIVE] (identification de la ville visitée avec google maps sur une connexion chiffrée en TLS).

    Enfin dans le cas où le chiffrement est optionnel, encore faut-il qu’il soit utilisé. Au-delà de l’aspect de sensibilisation, le produit doit encore être suffisamment facile d’usage. Parmi les éléments de réussite d’un tel projet, il est important qu’il soit possible de chiffrer et déchiffrer des messages sur smartphone, que la gestion des clefs soit intuitive et le logiciel fiable. Lors d’une réunion entre le RSSI d’un grand groupe, son équipe et l’auteur, aucune personne parmi la dizaine présents n’osait envoyer de mail chiffré de peur de faire planter son poste.

    Dans d’autre cas où l’approche par conteneur chiffré est sélectionnée (Zip chiffré, zed, etc) encore faut-il que l’utilisateur choisisse un mot de passe suffisamment solide et ne l’envoi pas en clair dans le mail suivant (dans un cas rencontré, le correspondant était allé jusqu’à écrire en noir sur fond noir et intituler le mail « message anodin »).

    Illusion 4 : « j’utilise un boitier de chiffrement Cloud, le gouvernement américain ne peut accéder à mes données » 

    Note : un boitier de chiffrement Cloud est défini ici comme étant un proxy chiffrant mis en coupure en sortie du SI de l’entreprise et effectuant à la volée le chiffrement/déchiffrement.

    L’idée est de pouvoir dissocier la souveraineté des données, de l’opérateur vers un système cryptographique maitrisé (du moins en théorie) par l’entreprise. « Même si le gouvernement américain émet une demande à l’opérateur Cloud, celui-ci ne pourra donner accès qu’aux données chiffrées par notre boitier, et donc complètement inexploitable » est un autre argument présenté par certains fabriquant de boitier de chiffrement Cloud. Dans ce cas, l’entreprise a cependant oublié de préciser qu’elle était basée dans le même pays que l’opérateur en question et donc elle-même soumise à la loi de ce pays. Le chiffrement peut alors être simplement contourné en faisant deux demandes : l’une à l’opérateur Cloud pour les données chiffrées et l’autre à l’éditeur du boitier pour disposer des clefs de chiffrement.

    Le contre argument avancé est bien souvent celui de l’hébergement du matériel : le boitier est hébergé au sein du SI de l’entreprise, celle-ci le contrôle complètement, le fournisseur n’a aucun accès. Si l’entreprise contrôle le matériel, est-elle certaine de contrôler la partie logicielle fournie souvent comme une boite noire ? Comment peut-elle s’assurer de l’absence de portes dérobées cryptographiques ? De canaux cachés faisant fuiter les données ? Comment peut-elle garantir qu’elle n’a pas reçu un ordre de la justice de son pays afin d’envoyer une mise à jour spécialement modifiée (voir le cas de Hushmail [HUSHMAIL]) ? Sans pour autant aller jusqu’à l’impact de projets comme BULLRUN, de nombreux constructeurs « oublient » parfois des clefs SSH communes ou des comptes cachés, qui s’ils sont découverts et rendus publiques permettent un accès aux systèmes [REF1, 2, 3].
    Si un boitier de chiffrement Cloud ne permet pas de se protéger d’une agence de renseignement de première catégorie, cette mesure peut s’avérer être efficace dans d’autres cas, comme par exemple :

    • Sous réserver d’être correctement implémentée, une couche de chiffrement opérée en dehors du périmètre de l’opérateur Cloud permet de limiter l’accès aux données de ce dernier et de limiter le risque de fuite d’information en cas de compromission de l’infrastructure.
    • Sous réserve d’effectuer une bonne séparation des responsabilités, un tel boitier peut être utile pour limiter le risque d’un accès aux données par un administrateur hyperviseur / système.
    • Sous réserve d’implémentation et d’usage correcte, cette couche de chiffrement peut compliquer (mais pas nécessairement empêcher) un accès par d’autres acteurs étatiques, selon leur niveau de compétence et le niveau de sécurité de l’entreprise. Même si de très nombreuses consultations ont lieu au sujet du gouvernement américain il ne faut pas pour autant négliger les autres acteurs, en particuliers lorsque l’infrastructure est hébergée dans un pays tiers. 
    • Sans oublier bien sur le cas de la compliance, où le but n’est pas tant d’avoir un chiffrement bien implémenté ou non que d’être conforme à un référentiel donné.
    Se pose alors la question de la qualité de l’implémentation du boitier : souvent il s’agit d’une appliance à base de linux avec un peu de scripting OpenSSL ou basé sur le Java Crypto Provider de base avec quelques modifications maisons. Dans certains cas rencontrés par l’auteur, afin de faciliter des recherches, un chiffrement en ECB avec la même clef pour toutes les données est mise en place, dans d’autre cas il s’agit de CBC mais avec un vecteur d’initialisation fixe, des implémentations vulnérables en particulier à certaines formes d’attaques statistiques. Dans d’autres cas le fichier est envoyé en clair sur le service Cloud, puis récupéré sur l’appliance, renvoyé chiffré sur le cloud puis la version en clair est effacé. Dans d’autre cas l’optimisation de la recherche conduit à déposer des métadonnées contenant des informations sensibles dans le Cloud (le fameux « compromis performance / sécurité »).

    Très peu de produits ayant fait l’objet d’un audit complet et sont développés par des personnes ayant le niveau de compétence suffisant, il convient de rester très prudent et procéder à une évaluation détaillée avant acquisition.

    Il faut également porter une grande méfiance envers les certifications des produits. Par exemple dans l’un des cas rencontrés, le constructeurs annonce un produit certifié FIPS (« même si vous n’avez pas confiance en nous, nous pouvons vous apporter une garantie de qualité par une certification extérieure »), or après étude du document de certification, seule une librairie (qui plus est peu utilisée) et non pas l’ensemble du système, en particulier la partie du code où sont générées les clefs, faisaient partie de la certification). Il s’agit d’un problème assez similaire à celui de la certification ISO 27001 où l’on entend souvent par abus commercial l’entreprise clamer qu’elle est certifiée, alors qu’en réalité seule une partie du SI et sur une cible très basique l’est.

    En supposant un chiffrement bien implémenté, le problème des fuites de données par étude des métadonnées reste entièrement présent (sur une approche similaire au cas des emails comme présenté ci-dessus).

    Et même en supposant un système cryptographique parfaitement conçu, l’usage de ces boitiers présente des risques inhérents à leur mode de fonctionnement, entre autre :

    • Création d’un Single Point Of Failure : non seulement la disponibilité de ces boîtiers devient primordiale, mais l’ensemble des données sensibles transitent par ces derniers. Plutôt que de tenter d’attaquer les serveurs de messagerie, mail, etc il est de loin préférable pour un attaquant de viser ces boitiers. D’autre part en cas de vulnérabilité (HeartBleed, Shellshock par exemple ou spécifique au produit) la compromission de ces boitiers peut entrainer la compromission de toutes les données ayant transité par ceux-ci.
    • La mise en place de ces boitiers peut impliquer un besoin de faire de l’interception SSL (en particulier lorsqu’un usage transparent, sans modification de la configuration client est visée). Ainsi la bi-clef relative à une autorité ou sous autorité doit être présente sur le système, en cas de compromission de ce dernier, l’attaquant dispose alors d’une arme particulièrement dangereuse. L’usage d’un HSM limite un peu le risque, mais il est souvent possible d’abuser du système en effectuant des fausses requêtes simulant l’accès à un autre service, très souvent le « vrai faux » certificat cible est automatiquement généré. L’usage de ce type de boitier dont la maturité est encore très limitée doit être fait avec prudence et uniquement après une modélisation précise du modèle de menace et d’une analyse de risques détaillée.

    Illusion 5 : « je contrôle les clefs et un j’utilise une carte à puce / HSM souverain »


    L’un des arguments souvent avancé est celui du contrôle des clefs : suite à certains évènements d’actualité, certains fournisseurs sont passés d’un discours « Notre Cloud est inviolable et même si le gouvernement demandait un accès, nous serions obligés contractuellement de vous avertir » à une approche « ne vous inquiétez pas, les données sont située dans un pays européen, il est protégé par la loi du pays en question » à finalement une approche « il est normal que vous vous préoccupiez de cette question et afin d’y répondre nous vous proposons de gérer vous-même vos clefs, auxquelles nous n’aurons jamais accès et qui plus est nous vous proposons d’utiliser un HSM ou une carte à puce, dont le niveau de sécurité est garanti par votre gouvernement ».

    Si cette approche est fort louable sur le principe, son efficacité sur le terrain est une autre chose. La vrai question est de savoir quelles clefs sont contrôlées par l’entreprise et où sont effectuées les opérations cryptographiques. Bien souvent ce contrôle ne concerne que la partie visible des opérations et « omet » certains détails techniques. C’est uniquement en creusent la façon dont le système est implémenté que l’illusion apparaît ; or entre temps le faux sentiment de sécurité entretenu a pu générer des risques non négligeables.

    Exemple : système de DRM

    Afin d’illustrer ce point, prenons l’exemple d’un système de DRM utilisé pour le contrôle de documents (l’auteur a combiné arbitrairement dans une implémentation fictive plusieurs systèmes rencontrés un afin d’illustrer le problème ; mais chacun des systèmes évalué était individuellement vulnérable). Ce fournisseur (fictif) de service Cloud propose un système type DRM pour chiffrer des documents. Le système est intégralement hébergé dans le Cloud, mais afin de rassurer ce dernier, il lui propose d’utiliser :

    • Des cartes à puce pour le stockage des bi-clefs utilisateur, les cartes en question ayant été qualifiées par l’agence de sécurité du pays en question (ANSSI en France, CESG au RU, BSI en Allemagne, etc)
    • Un HSM placé dans le Cloud, lui aussi qualifié par l’agence de sécurité du pays
    • Toutes les bi-clefs utilisées sur les cartes à puce et le HSM sont générées par la PKI de l’entreprise 
    Ainsi l’entreprise a non seulement un contrôle complet sur les clefs mais les opérations de chiffrement ont lieu sur des systèmes dont le niveau de sécurité est garanti par une agence réputée. L’entreprise a de quoi être rassurée, pour que l’opérateur Cloud accède à ses données, il lui faudrait soit casser des algorithmes de chiffrement à l’état de l’art soit réussir à extraire un secret d’un HSM ou d’une carte à puce ce (ce qui n’est pas non plus impossible, au passage voir les excellents travaux de Graham Steel sur les attaques sur PKCS, le tableau ci-après illustre quelques exemples à l’époque de sortie du paper).


    La réalité est cependant un peu plus complexe, le problème provient le plus souvent du fait que les clefs maîtrisées par l’entreprise ne concernent qu’une partie du périmètre.
    Alice souhaite envoyer un fichier à Bob :

    • Alice génère une clef symétrique AES aléatoire et spécifique pour ce fichier. Puis après s’être authentifiée au service avec sa carte à puce, elle envoi au serveur dans le Cloud :
      • Le fichier chiffré en AES avec la clef aléatoire
      • La clef AES aléatoire chiffrée avec la clef publique du service de licensing
        • Nous sommes dans un système de DRM, les droits pouvant être modifiés, Alice ne chiffre pas directement avec la clef de Bob mais utilise la clef publique du serveur de licensing, la partie privée étant stockée dans le HSM 
    • Lorsque Bob veut accéder au fichier
      • Il s’authentifie avec sa carte à puce auprès du serveur
      • Il demande au serveur de licensing un accès au fichier
      • Le serveur de licensing renvoi à Bob
        • Le fichier chiffré en AES avec la clef aléatoire
        • La clef AES chiffrée avec la clef publique de Bob o Bob déchiffre en local sur son poste et accès au fichier. 
    De prime abord, le système semble bien conçu, les clefs sont stockées sur des cartes à puce et la bi-clef du serveur de licensing sur un HSM.
    Cependant à la lumière d’une étude plus poussée du mécanisme, il apparait que :
    • Alice et Bob disposent en fait de deux bi-clefs :
      • Une bi-clef générée par la PKI de l’entreprise (K1) et stockée sur carte à puce
        • Celle-ci ne sert que pour l’authentification au service, elle ne sert pas pour le chiffrement ou déchiffrement des données
      • Une seconde bi-clef (K2), elle générée en local par le programme de DRM et stockée sur le disque dur
        • Celle-ci est utilisée pour les opérations de chiffrement déchiffrement
        • De plus une copie de cette seconde bi-clef est envoyée sur des serveurs de l’opérateur Cloud afin de permettre facilement d’accéder aux fichiers sur un autre poste, un téléphone, etc. Cette copie n’est pas chiffrée et la clef privée n’est pas non plus chiffrée avec une clef symétrique.
    • Lors de l’opération de transchiffrement de la clef aléatoire AES du fichier :
      • Le déchiffrement avec la partie privée de la bi-clef a lieu dans le HSM
      • Mais le chiffrement de la clef AES avec la clef publique de Bob K2 (celle qui n’est pas stockée sur carte à puce) n’a pas lieu dans le HSM, mais sur un serveur standard. 
    Si l’opérateur (ou un gouvernement ayant un moyen de pression) souhaite accéder aux données :

    • Il dispose de la version chiffrée du fichier et peut récupérer la clef symétrique AES en mémoire lors de l’opération de transchiffrement 
    • Même si toute l’opération avait lieu dans le HSM, il disposerait d’une copie de la bi-clef K2 et du message chiffré correspondant 
    Point intéressant, en évaluant les process en cas de refus de communication des clefs par l’un des employés ou en cas de décès (la clef sur carte à puce ne servant que pour l’authentification et non le chiffrement, le séquestre de l’entreprise est inutile), il est apparu qu’une fonction de recovery était en place et qu’elle permettait avec un simple mot de passe de déchiffrer n’importe quelle fichier…

    L’argument de l’opérateur proposant un niveau très élevé de traçabilité est également caduque, vu que celui-ci transmet lui-même les traces, celles-ci peuvent être falsifiées avant envoi.

    Exemple : chiffrement de message avec carte à puce 

    Dans un second exemple rencontré en mission par l’auteur, un système de chiffrement de message avait été implémenté par un fournisseur de service. Afin de rassurer le client, la bi-clef de chiffrement était stockée sur la carte à puce et seule des données chiffrées en local était envoyées sur le serveur.

    En pratique il s’est avéré que la partie chiffrement était opérée via une applet Java, ce qui outre le problème de manipulation de l’applet coté serveur pour exfiltrer les données ou la clef de chiffrement présentait un second problème d’implémentation. Si les opérations de chiffrement asymétriques étaient opérées sur la carte à puce, la génération de la clef symétrique AES pour chiffrer le message était effectuée en java sur le poste de travail de l’utilisateur, de même que l’opération de chiffrement symétrique. Ce complètement en dehors de la carte à puce et via une implémentation non évaluée, pouvant contenir par exemple une backdoor (dans le cas cité, le problème relevait plus d’incompétence que de backdoor, le développeur ayant choisi de générer sa clef en réinventant un PRNG maison basé sur Random et du code trouvé au petit bonheur sur internet).

    Exemple : boitier de chiffrement Cloud

    Dans le dernier exemple, le fabriquant de boitier de chiffrement Cloud proposait une option HSM afin de protéger les clefs. Suite à un accident lors d’un test (oubli de brancher l’alimentation du module HSM), l’un des administrateurs s’est rendu compte que si la partie web n’était plus accessible en HTTPS, la partie gestion des clefs en ligne de commande fonctionnait très bien. Après analyse il s’est avéré que si le HSM était bien utilisé pour la partie web (bi-clef sur HSM), les développeurs avaient oublié de configurer le bon crypto provider dans Java et le HSM n’était pas du tout utilisé pour cette partie…

    Synthèse

    Si le contrôle des clefs et l’usage d’un HSM ou d’une carte à puce est important pour sécuriser un système, il convient d’étudier en détail quelles clefs sont sous contrôle, où sont effectuées les opérations de chiffrement et surtout qui a écrit et vérifié le code. L’usage d’un HSM ou d’un carte à puce même souverain, couplée à une « maitrise » des clés n’est en rien en soit une garantie complète de sécurité.

    Conclusion

    Petit manuel de prestidigitation

    Au gré des exemples présentés dans ce post, il apparait que certains arguments, qui même s’ils ne tiennent pas face à une analyse approfondie, sont particulièrement efficaces.

    Des arguments comme « les clefs sont sous votre contrôle » ou « le système est hébergé par l’entreprise » font souvent mouche auprès des décideurs. Bien souvent cette argumentation n’est pas le fruit du hasard et a été savamment conçue afin de contourner une barrière que l’on pourrait qualifier de psychologique suite aux révélations de Snowden et la méfiance vis-à-vis de Cloud publics. L’auteur n’implique pas que tous les vendeurs procèdent de la sorte, mais que certains pourraient le faire, de manière volontaire ou involontaire.

    L’objectif du vendeur dans ces cas-là est d’activer certains mécanismes visant à pousser le mode de pensée du client vers une configuration la remise en cause de la sécurité est contraire à ses modes de pensée acquis. L’objectif étant de générer une dissonance cognitive de sorte à ce que l’individu tende à considérer la solution comme sécurisée afin de réduire l’ampleur et l’inconfort de cette dissonance.

    Le summum de l’art étant d’arriver au point où la remise en cause de la sécurité de la solution apparait comme impossible en combinant les aspects précédemment exposés et des failles inhérente au fonctionnement de l’entreprise. Par exemple dans certains cas où la culture d’entreprise est très hiérarchisée avec un DG/DSI à fort égo, convaincre celui-ci et réussir à lui faire internaliser les arguments peut permettre le lancement du projet sans même passer par l’étape sécurité. En effet si ce dernier a décidé que le produit était sécurisé, il passera outre la validation sécurité. Des tentatives allant à l’encontre du projet vont heurter la compréhension internalisée (bien que fausse) de la personne et seront perçues comme une attaque envers son égo et de fait non recevables. Revenons sur les axes évoqués :

    • Axe 1 : aspect possession/contrôle
      « Vous contrôlez la clef donc la situation, c’est votre clef ».
      L’objectif est ici de jouer sur la possession et le besoin d’être rassuré.
    • Axe 2 : inversion du rôle de fournisseur de confiance
      « Vous n’avez pas confiance en nous, vous avez raison, fournissez-vous la clef ».
      L’objectif est ici de poser le client en tant que garant de la sécurité (la distorsion est ici de faire croire que la sécurité dépend principalement de la clef en omettant le reste). Le client ne pouvant dire/admettre le plus souvent que la sécurité est mauvaise chez lui, la garantie de confiance lui revient.
    • Axe 3 : transfert de confiance et argument d’autorité
      « Ce n’est pas nous qui garantissions la sécurité, mais le fabriquant et l’autorité qui l’a certifié ».
       L’objectif ici est de transférer le garant de confiance (pour ce qui reste de doute suite à l’étape du contrôle des clefs) vers un tiers de confiance.
      Dans certains cas cette approche peut être combinée avec un argument d’autorité lorsque cela fonctionne « Vous n’allez tout de même pas remettre en cause l’avis des services du premier ministre » (notons au passage que si l’ANSSI, dans cet exemple, a qualifié un matériel, elle n’a nullement qualifié la solution utilisant ce matériel. Le biais est ici de jouer sur l’extension du périmètre garanti alors que ce n’est absolument pas le cas.
    • Axe 4 : réduction de la dissonance cognitive
      L’objectif ici est de donner des explications suffisamment simples pour que le client puisse se l’approprier (argument simple : « matériel souverain », « vous maîtrisez la clef ») en masquant une partie pourtant critique du raisonnement de sorte à ce que le client soit d’une part rassuré mais qu’il puisse lui-même internaliser l’explication et le réexpliquer à ses supérieurs et collègues. Ayant lui-même acquis et refait le raisonnement, il ne peut avoir des pensées de doutes ou allant contre sans générer une désagréable dissonance cognitive, qu’il cherchera automatiquement à réduire, ce qui renforcera l’argument initial.
      Une technique utile dans ces cas est de faire des parallèles simples mais partiels avec le monde physique, comme par exemple « notre solution est comme si nous utilisions des serrures certifiées par le gouvernement avec des clefs fournies par l’entreprise pour sécuriser les chambre d’une résidence, comment voudriez-vous que nous entrions ? » (et d’oublier de préciser qu’il y a une deuxième porte cachée dans la pièce) 
    Ces axes ne sont bien sûr que quelques exemples parmi tant d’autres.

    Que faire ?

    Dans certains cas le niveau de maturité de l’entreprise est tel qu’il est préférable de garder les données en interne, mais dans d’autres cas que l’auteur a pu rencontrer, les données de l’entreprise seraient de loin plus en sécurité sur un serveur de Google, Microsoft ou Amazon que sur des serveurs internes hébergés en France dans un SI qui a été compromis en moins d’une demi-journée par un pentesteur junior et ce sans même que le SOC ne relève une alerte.

    Dans le premier cas, compte tenu des mesures mises en place par ces opérateurs, les données sont certes accessibles par le gouvernement américain, l’opérateur lui-même et probablement quelques autres acteurs de premier rang ayant infiltré leur SI, mais cette situation est-elle pire que d’avoir les données hébergées dans un SI tellement vulnérable qu’il est non seulement facilement accessible par des acteurs de premier rang, mais également par toute une kyrielle d’autres acteurs de moindre niveau ?

    Que penser de l’argument « les données sont sous mon contrôle, en cas d’attaque je peux déconnecter les serveurs et couper les accès » quand on sait que la plupart des attaques ciblées sont détectées des mois voire des années après ? Et qu’entre temps les attaquants on peut tranquillement exfiltrer des gigas de données (ex : Sony) ? Si BAE, Belgacom ou la défense américaine n’y arrivent pas, qu’est-ce qui garantit que l’entreprise, elle, y arrivera mieux ?

    Les réponses à ces questions sont très dérangeantes, mais on est dans un cas quelque peu similaire à la peur de l’avion : de prime abord il semble beaucoup plus risqué que la voiture, en cas de problème il peut y avoir un dangereux crash. Or en se reposant sur une étude factuelle et non pas une approche émotionnelle, il s’avère que l’avion est un moyen de transport de loin plus sûr.

    Ainsi cette réponse doit être établie non pas sur des facteurs émotionnels mais sur une analyse de risque factuelle.

    Mis à part quelques acteurs particulièrement mature (et encore), il ne faut pas non plus se faire d’illusions sur la capacité de l’entreprise à résister à une attaque d’une agence de renseignement : si une agence de premier rang veut accéder à son SI, elle accédera à son SI. Autant accepter et définir par qui les données seront lues et se concentrer dans un premier temps les efforts sur des mesures empêchant un attaquant de moindre niveau de compromettre le SI en quelques heures/jours avant de dépenser des moyens considérables sur un objectif aussi ambitieux.

    Ce qui ne veut pas dire que les acteurs pour qui ce type d’attaquant fait partie du modèle de menace ne doivent pas mettre en place des moyens importants ; ne serait-ce que pour complexifier suffisamment l’attaque, la rendre couteuse et augmenter les chances de détection. D’autre part même pour une entreprise ne pouvant espérer lutter efficacement contre ce type d’attaquant, l’usage d’un système de chiffrement même perfectible est un moyen d’augmenter le coût de l’attaque et de ne pas offrir sur un plateau d’argent les données et au moins forcer l’attaquant à dépenser un peu de ressource pour une attaque un minimum ciblée. Il est également important de garder à l’esprit que la sécurité n’est pas un produit mais un processus : des systèmes de chiffrement aussi bien conçu soient-ils ne représentent pas une solution magique ; mais ils sont une partie importante de la solution.

    Il est nécessaire d’impliquer des experts dès la phase amont afin d’évaluer les bonne orientations. En pratique il convient de procéder à une analyse de risque complète et une modélisation du modèle de menace tout en gardant une approche orientée classification des données. En fonction des résultats de l’étude, il peut apparaitre que le Cloud est une solution plus sécurisée que le SI interne, que le SI interne l’est plus ou qu’une hybridation en fonction du niveau de sensibilité et la mise en place de process et outils (en particulier de chiffrement) permet le meilleur compromis cout / sécurité.

    Ary KOKOS

    4 commentaires:

    1. Votre article est très bien étayé mais un peu alarmiste. Il faut à mon avis séparer les différentes variables :
      - l'algorithme cryptographique et la qualité de son implémentation
      - la génération des secrets et leur gestion
      - l'environnement dans lequel les mécanismes cryptographiques sont utilisés
      Aujourd'hui, on sait sécuriser les 3 axes avec plus ou moins de succès mais la maîtrise est plus compliquée pour l'environnement du fait de la prédominance de solutions non maîtrisables.
      La situation n'est pas désespérée sur les axes 1 et 2. Cependant, si votre ennemi est la NSA ou le GCHQ, utiliser des solutions sur étagère n'est pas la solution.

      RépondreSupprimer
    2. Cela fait peur !Merci pour ces éclairages fondamentaux !!

      RépondreSupprimer
    3. Très bonne analyse Ary. Un poil longue mais comment faire autrement si on veut parler de tous les apects comme tu l'as fait.
      Merci

      RépondreSupprimer
    4. Excellent article. Je ne le qualifierais pas d'alarmiste, car il repose essentiellement sur des faits. Quand la réalité est sombre...
      Toutefois, il manque à mon avis un paramètre à l'argumentaire en faveur du Cloud dans le cas d'un niveau de maturité sécurité insuffisant de l'entreprise. Faire le choix du cloud dans ce contexte amènera presque immanquablement l'effet pervers suivant : "Nous sommes en sécurité grâce à notre cloud pas cher. Inutile d'élever notre niveau de maturité sécurité."
      Ce n'est pas une idée qui m'est venue dans le cadre de ma paranoïa habituelle, mais un cas réellement observé dans une entreprise mondialisée de taille intermédiaire.

      RépondreSupprimer