Le déchiffrement HTTPS est nécessaire contre les malwares

Le problème : la très grande majorité des contrôles de sécurité des entreprises ne sont pas configurés pour inspecter ce trafic, les rendant ainsi incapables de détecter un volume conséquent de malwares.

Voici pourquoi déchiffrer le trafic HTTPS (TLS/SSL) au niveau du périmètre réseau est une étape désormais essentielle de la protection contre les menaces en ligne.

Une porte grande ouverte pour les cyberattaquants

Notre dernier rapport de la sécurité Internet du dernier trimestre 2022 soulignait une baisse du volume global de logiciels malveillants. Mais en examinant de plus près le trafic HTTPS déchiffré, nous avons pu observer que 93 % des logiciels malveillants - contre 82 % au trimestre précédent - se cachent derrière le chiffrement TLS/SSL.

Si une équipe de sécurité ne déchiffre pas ce trafic au niveau de la passerelle de sécurité réseau, elle ne voit rien de ce qu'il contient, ce qui crée un énorme angle mort. En outre, la création d'un site protégé par HTTPS n'a jamais été aussi simple grâce à des organisations comme Let's Encrypt, auxquelles les cybercriminels peuvent faire appel pour sécuriser leur trafic gratuitement.

Déchiffrer le trafic HTTPS est une contrainte nécessaire

En dépit de cette tendance, il est courant que les équipes n'activent pas le déchiffrement au niveau du firewall, en raison des complications possibles. Le processus requiert, en effet, des ressources pour déchiffrer et rechiffrer du trafic traversant une passerelle ainsi qu’une puissance de calcul importante, au niveau des firewalls de nouvelle génération (NGFW) ou des outils de gestion unifiée des menaces (UTM). Tout cela génère nécessairement un impact sur les performances du réseau.

Introduire le déchiffrement tout en gérant les performances d'autres outils de sécurité et leurs diverses utilisations peut également s'avérer complexe. Aujourd’hui, cependant, les solutions de type UTM/NGFW sont capables de lancer ce processus à la vitesse de la connexion WAN entrante. C’est pourquoi les principales objections des utilisateurs concernent à présent la configuration initiale du déchiffrement TLS/SSL et le besoin de prévoir des exceptions pour certaines applications.

Bien que pour les équipes IT et de sécurité à court de ressources, trouver le temps de configurer une politique plus complexe ne soit pas tâche aisée, le déchiffrement HTTPS est une pratique que les départements de sécurité ne peuvent plus négliger.

Bonnes pratiques pour configurer efficacement le déchiffrement HTTPS

Déchiffrer TLS/SSL sans rompre la chaîne de confiance des certificats numériques, nécessite d’ajouter un certificat racine personnalisé à ses navigateurs et appareils, de sorte qu'ils fassent confiance à celui-ci comme intermédiaire pour le trafic chiffré. C'est ce qui permet à votre appareil de rechiffrer le trafic, et à la chaîne de confiance de passer avec succès toutes les validations de certificats. Avec les produits de déchiffrement TLS, ces opérations peuvent être faites de deux façons : la manière forte et de la manière faible.

La manière forte consiste à utiliser un certificat d'autorité de certification racine personnalisé (ou un certificat d'autorité proxy) fourni avec les produits de déchiffrement TLS. Vous pouvez exporter ce certificat et l'importer sur tous les clients et appareils nécessitant un déchiffrement TLS/SSL. L'inconvénient est que vous devez obtenir ce certificat sur tous les appareils dont vous disposez, parfois à plusieurs endroits (comme c’est le cas pour les navigateurs web). Bien que la stratégie de groupe permette de pousser de nouveaux certificats vers de nombreux appareils, l'installation de ce certificat particulier sur un si grand nombre de périphériques et de navigateurs peut s’avérer une charge de travail importante.

Si, toutefois, vous utilisez Windows (ou Azure) Active Directory, vous disposez sûrement d'un certificat d'autorité de certification d'entreprise pour votre domaine. Plutôt que d'exporter le certificat du produit, et d'avoir le plus grand mal à le transmettre à plusieurs appareils, vous pouvez simplement importer ce certificat dans le produit auquel tous vos appareils font déjà confiance. Cette méthode plus aisée permet à la plupart des équipes de mettre en place le déchiffrement en quelques heures seulement, et en moins d'une journée si des tests sont effectués.

Cependant, d'autres complications peuvent survenir et nécessiter des exceptions. Cette méthode de déchiffrement TLS ne fonctionne que sur les appareils procurant un certain contrôle de leur magasin de certificats. Certains appareils IoT sur le réseau ne peuvent ne pas offrir ce contrôle ; ils doivent alors être ajoutés en tant qu'exceptions contournant l'inspection TLS/SSL. Les problèmes les plus courants concernent les sites web, les applications et les programmes qui exploitent des protections TLS/SSL supplémentaires visant à empêcher les attaques de type « man-in-the-middle » (MitM).

Les mécanismes comme HTTP Strict-Transport-Security (HSTS), l’épinglage des certificats ou les implémentations propres à un programme obligent votre navigateur ou votre appareil à n'accepter que le certificat d’origine du site ou du domaine, et non les certificats intermédiaires. Or, ceci a pour effet d’annuler la validité de la connexion lorsque celle-ci est déchiffrée. Par exemple, un site comme DropBox peut être correctement déchiffré lors d'une visite depuis un navigateur web, mais l'application DropBox elle-même ne fonctionnera que si elle peut visualiser le certificat requis. Au fil du temps, vous devrez ajouter des exceptions à vos politiques de déchiffrement HTTPS. Heureusement, des exceptions par défaut et des moyens simples de les ajouter sont proposés par la plupart des produits.

Intégrer le déchiffrement HTTPS n’est pas chose aisée. Cela nécessite des ressources certaines et induit quelques contraintes. Mais lorsque l’on sait que la sécurité est inopérante face à 93% de malwares, la question n’est plus de savoir si l’on doit déchiffrer le trafic mais plutôt comment s’y prendre ? En effet, ne pas déchiffrer ce trafic, et ne pas l'analyser au niveau réseau, limite de façon significative les options de défense en profondeur de l'équipe de sécurité, laissant l’entreprise avec une seule et dernière couche de défense pour protéger ces terminaux. Pour renforcer et maintenir cette protection, l’entreprise ne peut se retrouver dans cette position précaire qui l’expose à des risques accrus. Le temps est venu d'accroître, au contraire, la sécurité en déchiffrant le trafic HTTPS.