Remontée d’échantillons suspects : un recours massif au chiffrement

L’agence américaine du renseignement a été victime d’une fuite de données en 2015. Des pirates seraient parvenus à mettre la main sur des échantillons de outils de cyberdéfense offensive, par le biais d’un employé ayant fait l’erreur d’avoir ramené du travail à la maison. Son ordinateur domestique était équipé de l’antivirus de Kaspersky. Selon l’une des hypothèses plausibles, ce dernier aurait identifié les maliciels de la NSA. Se pose ainsi notamment la question de la manière dont l’antivirus – et d’autres également – communique avec l’infrastructure de son éditeur. Et si ces échanges sont susceptibles d’être interceptés. Plusieurs experts n’ont pas manqué de se pencher rapidement sur le sujet, avec des résultats susceptibles d’inquiéter. Mais les éditeurs de solutions de protection du poste de travail semblent majoritairement avoir mis en place plusieurs niveaux de contrôle.

Cylance rappelle ainsi qu’il est possible de désactiver la remontée d’échantillons exécutables et renvoie ainsi à sa politique de confidentialité. Celle-ci précise quelles données sont collectées. Et outre l’échantillon, cela recouvre aussi des informations telles qu’adresse MAC, caractéristiques de la machine, adresse IP ou encore localisation géographique. Las, il n’y a pas là de détail quant au chiffrement – en transit comme au repos –, ou la durée de rétention. L’éditeur peut être toutefois joint à une adresse e-mail dédiée pour toute demande d’accès, de correction ou de suppression. Il assure également « suivre les standards généralement acceptés pour protéger les informations personnelles » qui lui sont soumises, en transit comme au repos.

Le son de cloche est comparable chez F-Secure, qui explique en ligne que l’utilisateur « décide ce qu’il veut partager ». L’éditeur assure en outre protéger les données qu’il collecte contre les indiscrétions et s’appuyer sur des fournisseurs de confiance. Dans un courrier adressé à la rédaction, l’éditeur va plus loin, détaillant les données collectées lorsque « le client utilise nos solutions les plus modernes avec les réglages appropriés, pour retirer tous les bénéfices de la sécurité Cloud » : informations sur l’exécution de l’échantillon, son comportement et sa prévalence ; URL inconnues pouvant être malicieuses – sous forme d’empreinte, « donc nous ne savons pas ce que l’utilisateur consulte là » – ; ou encore fichiers inconnus envoyés pour analyse. A cela s’ajoutent des données dites de télémétrie sur le poste protégé. F-Secure précise que les données sont « protégées à la couche de transport, mais également chiffrées de sorte que nos serveurs frontaux ne transfèrent que des paquets chiffrés, qui sont ensuite chiffrés plus en profondeur dans notre infrastructure ». Et d’ajouter « éviter de collecter des informations personnelles, et même pour les informations que nous collectons, nous supprimons la source ».

Cisco nous a renvoyé à un document PDF exhaustif sur sa solution AMP. On apprend dans celui-ci que les composants locaux d’AMP communiquent d’une part avec le Cloud de la solution – avec SSL, pour comparer les signatures et fournir des données de télémétrie –, et de l’autre avec le Threat Grid Cloud de l’équipementier, là encore avec SSL, mais pour remonter seulement échantillons – ou journaux de proxy Web. Au total, ce service Cloud recevrait plus d’un million d’échantillons par jour. Selon Cisco, « aucun client n’a accès aux échantillons soumis » par un autre, à compter qu’ils soient marqués comme « privés ».

De son côté, Eset explique que, par défaut, ses solutions ne transmettent rien et fonctionnent par empreintes, à moins que l’utilisateur ne décide, volontairement, d’activer l’option permettant la remontée d’échantillons. Là encore, il faut compter avec des données de télémétrie et « toutes les informations traitées sont chiffrées ». Mais le détail s’arrêtera là.

De son côté, Kaspersky rappelle que les utilisateurs « contrôlent la quantité de données partagées », en particulier dans le cadre de son KSN. L’éditeur détaille en outre exhaustivement le type de données collectées, ses efforts d’anonymisation, ou encore le traitement réservé à ces données. Dans un courriel à la rédaction, Kaspersky explique chiffrer les transmissions en employant un protocole propriétaire « basé sur une cryptographie RSA2048/AES256 », en plus du chiffrement offert par le protocole TCP utilisé pour la transmission : « toutes les données transmises sont chiffrées, de même que le canal utilisé ».

Sophos précise lui-aussi que la remontée d’information peut être désactivée à tout moment par ses clients. Et de renvoyer également à sa politique de sécurité des données collectées, accessible publiquement. Les données en question peuvent être des échantillons, des empreintes ou encore des données de télémétrie. Elles sont transmises sur HTTPS – « et/ou lookup DNS chiffrés ». Au repos, les données sont protégées avec la technologie d’Utimaco, racheté en 2008.

Palo Alto Networks est sur une ligne comparable, soulignant que les remontées – vers Wildfire – ne surviennent qu’avec l’accord du client, et encore de manière très granulaire, selon les types de contenus à examiner. L’équipementier souligne en outre appliquer une politique « transparente, communiquée au client ». Les échanges se font sur un canal chiffré.

FireEye recourt lui-aussi largement au chiffrement. Les données collectées sont chiffrées sur l’appliance déployée en local avant d’être envoyées à son Cloud. Et là, « tout session Web et API se déroule sur HTTPS avec certificat signé par une autorité de confiance. Ce certificat utilise l’algorithme RSA avec une clé 2048 bits pour l’authentification et l’échange de clés nécessaire à l’établissement d’une clé de session 256 bits (pour AES) ». Au passage, FireEye précise que « toutes les appliances doivent valider le certificat afin d’interagir avec le serveur. Les authentifications au niveau du terminal et de l’utilisateur sont réalisées pour valider l’autorisation de l’appareil à recevoir des mises à jour et valider l’utilisateur si nécessaire ».

Chez Trend Micro, Loïc Guézo explique que les communications agent/serveur se font sur https : « les données transmises sont la configuration, le statut et les alertes. Ces données ne sont pas re-chiffrées à l’intérieur du canal de communication, qui est lui-même chiffré et authentifié, bien entendu ». C’est également le cas pour les échanges avec le Smart Protection Network de l’éditeur, auquel peuvent être transmis empreintes de fichiers à analyser, URLs à valider ou encore morceaux de code compilé « et tables d’importation des binaires pour l’apprentissage automatique ».

De son côté, Bitdefender nous indique que les informations transmises « varient d’un produit à l’autre », mais également selon la configuration locale. De manière générale, les données transmises « sont liées à la télémétrie, le nom des menaces détectées et les noms des pays dans lesquels ces menaces ont été détectées ». Ce sont « les deux des informations les plus fréquemment envoyées » et cela « nous aide à dresser une liste des principaux logiciels malveillants et à identifier les apparitions de logiciels malveillants dans des régions spécifiques ». L’éditeur précise que « cette information ne peut être corrélée à l'identité de l'utilisateur et n'a aucune valeur commerciale ». A cela s’ajoute sans surprise des marqueurs tels que « des fichiers et empreintes de trafic qui nous aident à détecter en temps réel si l'application ou le trafic concerné est potentiellement dangereux pour l'utilisateur ». Tous les échanges sont chiffrés avec TLS.

Enfin, SentinelOne explique utiliser lui aussi https pour les échanges « entre les agents et le serveur d’administration », lequel peut être « au choix dans le cloud (AWS) ou en local, chez le client ou un partenaire MSSP en cloud privé ». L’éditeur ne détaille pas le contenu des échanges ; il assure que les données au repos sont « protégées » dans son infrastructure, mais ne développe pas non plus.

La plupart de ces éditeurs étaient présents aux Assises de la Sécurité, à Monaco, la semaine passée, et beaucoup nous ont demandé un délai pour répondre à nos questions. C’était également le cas de Symantec qui, malgré un délai supplémentaire, n’a pas fait l’effort qu’ont consenti ses concurrents, évoquant « des agendas chargés ».