Comme nous l’avons vu cette année, davantage de sites avec des publicités, qui ne sont pas hébergés ou contrôlés localement, servent à propager des malwares. Les hackers peuvent alors exploiter ces terminaux vulnérables. Avec l’intensification des sites web et des moteurs de recherche qui utilisent le chiffrement, il est possible que les utilisateurs qui visitent des sites légitimes ou qui font des recherches légitimes s’exposent à ces types d’attaques car le pare-feu de périphérie n’a pas les capacités de déchiffrer, d’analyser et de déterminer si du contenu malveillant est intégré dans la charge utile chiffrée.

Les recommandations de sécurité suivent l’évolution du paysage de l’Internet. Si votre appliance UTM ou votre pare-feu à état (Stateful Packet Inspection) est trop ancien pour pouvoir déchiffrer le trafic SSL, il est possible que votre réseau et vos utilisateurs soient exposés.

Voici quelques questions que les administrateurs devraient se poser au moment de choisir un produit avec technique de déchiffrement SSL à intégrer dans leur stratégie globale de sécurité.

• Mon pare-feu est-il capable de déchiffrer et d’analyser le trafic chiffré en SSL ?

Les capacités de déchiffrement SSL et d’inspection sont les aspects les plus importants d’une stratégie de renforcement de la sécurité du réseau. Les organisations qui n’inspectent pas le trafic SSL s’exposent à une part croissante du trafic qu’elles ne peuvent pas analyser. Et les attaques cachées dans des contenus chiffrés en SSL auront un taux de réussite de 100% dans ce type de scénario. Pour combattre ces attaques sophistiquées, les organisations doivent pouvoir inspecter l’ensemble du trafic sur chaque port, que ce trafic soit ou non chiffré en SSL. Un des enjeux réside dans le fait que la plupart des pare-feu NGFW disponibles actuellement offrent de piètres performances de déchiffrement et d’inspection du trafic SSL.

• Y a-t-il un risque de ralentissement des performances si je mets mon pare-feu actuel à jour de cette capacité ?

Les produits de sécurité traquent le trafic à un niveau granulaire pour lutter contre les attaques. Il est difficile d’évaluer précisément la baisse de performance, mais dès que des pare-feu opèrent une inspection en profondeur des paquets, un temps de latence supérieur s’en ressent au niveau du paquet. Il est recommandé d’interroger le fournisseur des pare-feu sur l’impact de ses produits sur les performances du réseau et de lui demander les résultats obtenus lors de bancs d’essais. Vous pouvez aussi effectuer vos propres tests A/B de vos produits de sécurité. Pour mesurer l’impact sur les performances, testez le fonctionnement avec les produits allumés puis avec les produits éteints. Retenez que les pare-feu NGFW sont ceux qui offrent le plus de sécurité puisqu’ils analysent le trafic de tous les ports, tous protocoles confondus. Pour maintenir des performances optimales et délivrer des services de DPI (Deep Packet Inspection) et de DPI SSL de très haut niveau, les meilleures solutions reposent sur des systems-on-a-chip (SoC) Cavium Octeon embarquant jusqu’à 32 cœurs individuels de type MIPS64.

• Le déchiffrement SSL s’applique-t-il aux connexions en sortie des terminaux uniquement ?

Il est important de déterminer si l’entreprise a besoin d’analyser le trafic sortant qui est chiffré. Dans ce cas, le pare-feu est-il capable d’analyser l’ensemble des flux sortants, ou uniquement ceux qui transitent via un terminal ?

• Existe-t-il des cas qui justifient l’utilité de déchiffrer le trafic SSL côté serveur ?

La majorité des infrastructures utilisent SSL côté serveur pour l’authentification du serveur auprès du navigateur (client), même si SSL peut authentifier le client si une précédente relation a eu lieu. Pour l’authentification SSL, chaque entité doit obtenir un certificat (et la clé privée associée) auprès d’un émetteur de confiance reconnu par le système. Sachez qu’il peut être dangereux d’autoriser la réception directe par vos serveurs du trafic SSL entrant. Les cybercriminels commencent à utiliser SSL pour masquer leurs attaques dans du trafic chiffré, si bien que le trafic SSL non inspecté pourrait présenter une menace. Comment alors inspecter ce trafic et garantir simultanément la confidentialité des données ? En utilisant un pare-feu au niveau applicatif.

• Quelles est la flexibilité de contrôle des sites qui ne sont pas soumis au déchiffrement SSL (ex. sites bancaires) ?

La solution que l’on vous propose est-elle assez flexible ? Idéalement l’entreprise doit pouvoir affiner les comportements du pare-feu et être en mesure de lui indiquer quels sont les flux qu’il doit décrypter pour être analysés et ceux qu’il ne doit pas décrypter. Cette flexibilité est un gage de performance.

• Existe-t-il un moyen simple de distribution des certificats à tous les types de terminaux et de systèmes d’exploitation ?

Lors du chiffrement, des certificats sont envoyés. Pour simplifier cette tâche, il est essentiel que l’administrateur IT dispose d’un moyen de distribuer facilement des certificats pour tous types d’équipements mobiles et de systèmes d’exploitation (AndrOïd, iOs, Windows etc).

Si vous n’avez pas encore inclus l’analyse du trafic SSL dans votre stratégie de sécurité informatique, il est plus que temps de le faire !

Avec l’intensification du trafic de données chiffrées en entrée et en sortie du réseau, le risque d’exposition à des menaces va croissant. Aujourd’hui, plus que jamais le choix judicieux et documenté d’un pare-feu de dernière génération s’inscrit dans le cadre de la stratégie globale de sécurité des entreprises.