La plaie du chiffrement

La complétude est tout sauf facile à obtenir : une pièce jointe suspecte peut en effet transiter dans un mail en document attaché, toujours dans un mail, mais avec un lien Web dans le corps du texte qui pointe vers un site, au sein d’une page Web accessible par un navigateur, etc. À ce jour, je n’ai vu aucune protection complète qui couvre tous les cas de figure ; dans un précédent article[1] j’avais décortiqué la feuille de route, bon courage m’sieurs dames.

Il reste un autre champ qui pose problème : les communications chiffrées. Côté navigation Web, on sait que de plus en plus de sites sont en https, et si la réglementation autorise le déchiffrement à la volée des flux chiffrés à des fins de maintenance technique, cela pose tout de même quelques soucis réglementaires (communications aux instances), éthiques (déchiffrement des flux vers les sites bancaires) et pratiques (interdiction de navigation vers des sites communautaires, par exemple). J’ai par ailleurs récemment découvert qu’à la suite du resserrement des filtres de messagerie (blocage des pièces jointes chiffrées car non analysables par un module AV) nous sommes en présence d’une recrudescence d’incidents utilisateurs, qui ne reçoivent plus de mails extérieurs, généralement en provenance de laboratoires de recherche.

Question : pourquoi chiffrer ces mails ? Soit ces mails contiennent des données médicales nominatives, auquel cas il faut privilégier le seul moyen légal et autorisé sur le territoire, à savoir la MSSanté (pour une fois, on ne dira pas que j’ai dit du mal du machin), soit ces mails ne contiennent pas de données nominatives (car anonymisées) ou de santé (si administratives), et dans ce cas le chiffrement est juste une précaution normale de l’émetteur : données sensibles, résultats de recherche, données financières, etc. Mais dans ce cas, je suis un peu sec : si l’organisme émetteur n’est pas éligible à la MSSanté (entité étrangère, administrative, etc.), je fais quoi ? 

Une solution pure « poste de travail » ne suffit pas : toute protection virale doit passer par un sas d’analyse en DMZ (avec les modules AV qui vont bien) avant d’être délivrée sur le PC utilisateur (avec une dernière analyse AV). Il est possible de suggérer aux interlocuteurs externes de passer par des sites d’échange de fichiers sécurisés (qui comportent quant à eux une analyse AV), mais cela ne couvre pas les cas des envois automatisés par des robots, cas d’usage courant dans le monde de la recherche. Sans parler du moment où nous devrons analyser les flux des outils de type Telegram…

Dans un monde parfait, la DSI devrait mettre à disposition une offre de services officielle et maîtrisée pour gérer ce besoin. Dans la réalité, ce n’est pas simple : certes il existe des technologies de type TLS pour sécuriser les flux Web, mais cela engendre une consommation de ressources de la DSI pour la maintenance et la gestion, suppose que les partenaires se plient à ce mode de communication, etc. Et rien n’est plus facile pour un émetteur que de chiffrer un document : le Web regorge d’outils à usage domestique et de bonne facture, mais inadaptés à un fonctionnement industriel contraint.

En écrivant qu’après le système Scada les prochaines sueurs froides des RSSI viendront du chiffrement des échanges, je ne demande qu’à avoir tort.

[1]   /article/2182/cryptolockers-etat-des-lieux-et-plans-de-protection.html