Archives par mot-clé : tls

Base de données, Chiffrement, Cloud, Cybersécurité, Emploi, Entreprise, Fuite de données, Mise à jour, Patch

Les angles morts créés par le trafic chiffré SSL

Le chiffrement SSL/TLS est largement utilisé pour garantir la confidentialité des communications vers les serveurs internes et externes. Malheureusement, cette confidentialité s’applique également aux solutions de sécurité en les aveuglant et de ce fait en empêchant l’inspection du trafic réseau. Ce qui augmente les risques encourus. Le cabinet Gartner prévoit ainsi qu’en 2017, plus de la moitié des attaques réseau menées contre les entreprises utiliseront le trafic chiffré afin de contourner les mécanismes de contrôle.

Les flux chiffrés étant de plus en plus utilisé par les pirates informatiques, intéressons-nous aux cinq erreurs les plus fréquemment commises en matière d’inspection des communications réseau :

La négligence. Selon Gartner, les entreprises sont nombreuses à ignorer le manque d’efficacité de leurs systèmes de protection en profondeur. Ainsi, la plupart des organisations n’ont pas mis en place de politique formelle de sécurisation des flux chiffrés. Moins de 50% des entreprises équipées de passerelles Web sécurisées (SWG) s’en servent pour déchiffrer le trafic Web sortant. Enfin, moins de 20% des organisations équipées d’un pare-feu, d’un système de prévention des intrusions (IPS) ou d’une appliance de gestion unifiée des menaces (UTM) analysent le contenu des flux lorsqu’ils sont chiffrés.

Le manque de précision. Les entreprises gaspillent de l’argent dans toutes sortes de solutions : IDS/IPS (systèmes de détection/prévention d’intrusion), DLP (solutions de prévention contre la perte de données), pare-feu de nouvelle génération, outils d’analyse de logiciels malveillants, etc. Bien que ces solutions répondent à une variété de problématiques, l’inspection du trafic SSL n’y est tout au plus présente qu’en tant que fonctionnalité optionnelle, et se limite à fournir une visibilité sur les communications Web/HTTPS. De plus, ces fonctionnalités étant tellement consommatrice de ressources, les entreprises doivent déployer plusieurs appliances supplémentaires afin de prendre en charge l’inspection d’un trafic SSL. Cette méthode s’avère  couteuse, problématique sur le plan opérationnel et souvent incomplète.

Le manque de cohérence. Le manque de cohérence dans le déploiement des politiques de déchiffrement du trafic sur les différentes solutions de sécurité utilisées est souvent problématique pour les services chargés de la sécurité informatique. La complexité des réglementations en matière de confidentialité des données est généralement identifiée comme étant un obstacle aux prises de décisions par les départements juridiques, RH ou de conformité. En outre, le manque de communication avec les employés et souvent source de mécontentement (« Pourquoi mes flux sont-ils inspectés ? ») et annihile souvent l’aboutissement des efforts de déchiffrement de ce type.

S’appuyer sur une protection insuffisante. Les logiciels malveillants utilisent le trafic SSL pour commettre leurs méfaits. Ainsi, selon Gartner, l’omniprésent botnet Zeus utilise les communications SSL/TLS pour se mettre à jour après une première infection par e-mail. Par ailleurs, notre centre de recherche Blue Coat Research Labs a constaté que le cheval de Troie Dyre utilisait souvent des mécanismes de commande et de contrôle (C2C) malfaisants tels qu’Upatre pour communiquer secrètement avec ses serveurs de contrôle et de commandement.

Se laisser perturber par l’évolution de l’environnement. L’adoption rapide d’applications et de services cloud étend et complique considérablement les environnements informatiques, accélère le développement du trafic SSL/TLS chiffré, et augmente l’exposition aux risques de piratage. Les applications modernes telles que les médias sociaux, les solutions de stockage de fichier, les moteurs de recherche et les logiciels cloud s’appuient de plus en plus sur ces protocoles pour communiquer. Il est vivement recommandé de superviser et d’analyser ces applications et services, à la recherche de contenu et d’activité malveillants. La généralisation de l’utilisation de ces applications rend encore plus critique la mise en place d’une politique de déchiffrement permettant d’identifier ce qui peut l’être ou ce qui doit rester chiffré.

Voici quatre recommandations pour combler les lacunes vis-à-vis de la sécurité de votre réseau :

1.     Identifier la volumétrie et prévoir son augmentation : évaluez le pourcentage et le volume de trafic réseau chiffré par SSL dans votre organisation.

2.     Évaluez le risque que le trafic ne soit pas inspecté : partagez des informations et collaborez avec vos collègues en dehors des services informatiques (départements RH, juridiques, conformité) ; étudiez et affinez vos stratégies d’entreprise sur le plan de la confidentialité et de la conformité ; et créez un plan d’action commun afin de gérer toute vulnérabilité.

3.     Renforcez votre infrastructure de sécurité réseau en assurant une gestion complète du trafic chiffré : renforcez vos solutions existantes (pare-feu de nouvelle génération, IDS/IPS, antivirus, DLP, outils d’analyse de malware/sandbox et autres logiciels d’analyse de la sécurité) en leur donnant la possibilité de détecter toutes les menaces (même celles issues du trafic précédemment chiffré) et de les traiter comme il se doit.

4.     Supervisez, affinez et appliquez vos stratégies : supervisez, affinez et mettez en œuvre vos stratégies relatives aux applications et au trafic chiffrés entrant et sortant de votre réseau. (par Par Dominique Loiselet, Directeur Général de Blue Coat France)

Chiffrement, cryptage, Cybersécurité, Entreprise

Le modèle de maturité TLS

Dans le cadre de son activité SSL Labs,  Ivan Ristic du Qualys SSL Labs (Centre de recherches sur TLS et PKI qui fournit des outils de sécurité, de la documentation ainsi que des études sur les écosystèmes) passe beaucoup de temps à aider les autres à renforcer leur sécurité TLS. Soit directement ou en développant des outils et en rédigeant de la documentation. Avec le temps, il a remarqué que déployer TLS en toute fiabilité était de plus en plus compliqué alors que ce devrait être le contraire.

C’est pourquoi il présente dans DataSecurityBreach.fr  un modèle de maturité TLS, un modèle de déploiement conceptuel avec une feuille de route pour une sécurité TLS puissante. Ce modèle offre cinq niveaux de maturité.

Au Niveau 1 se trouve le chaos. Sans aucune politique ni règle associée à TLS, votre sécurité est aux mains du hasard (par exemple la configuration constructeur par défaut), d’individus ou plus généralement d’initiatives ad-hoc. Si bien que vous ne savez pas ce dont vous disposez ni quelle sera votre sécurité. Même si vos sites existants bénéficient d’une bonne sécurité, impossible de garantir que cela sera aussi le cas pour vos nouveaux projets. Tout le monde commence à ce niveau.

Le Niveau 2, celui de la configuration, ne concerne que la sécurité du protocole TLS et ignore les protocoles supérieurs. C’est de ce niveau dont nous parlons le plus, mais c’est généralement celui le plus facile à atteindre. Pour les systèmes modernes, il s’agit essentiellement d’un problème de reconfiguration des serveurs. Les systèmes plus anciens peuvent nécessiter une mise à niveau, ou, en dernier recours, un proxy plus sécurisé installé en frontal.

Le niveau 3, celui de la sécurité applicative, concerne la sécurisation de ces protocoles applicatifs supérieurs pour éviter des problèmes susceptibles de compromettre le chiffrement. Pour ce qui est des sites Web, ce niveau exige d’éviter de mélanger du texte en clair avec du contenu chiffré au sein de la même application ou sur la même page. Autrement dit, l’ensemble de la surface applicative doit être chiffrée. En outre, tous les cookies applicatifs doivent être bloqués et leur intégrité doit être vérifiée dès leur arrivée afin de se protéger contre des attaques à base d’injection de cookies.

Le Niveau 4, celui de l’engagement, a trait à l’engagement sur le long terme en matière de chiffrement. Concernant les sites Web, ce niveau est atteint en activant HTTP Strict Transport Security (HSTS), une norme relativement récente et prise en charge par les navigateurs modernes (par exemple supportée par IE sous Windows 10). HTTP Strict Transport Security applique un modèle de sécurité TLS plus strict pour mettre en échec les attaques visant à supprimer SSL ainsi que celles incitant les utilisateurs à cliquer sur les avertissements relatifs aux certificats.

Enfin, au niveau 5 se trouve une puissante sécurité. Vous définissez votre propre protection privée dans le Cloud PKI pour vous prémunir contre la plus importante faiblesse de l’infrastructure PKI, à savoir la possibilité pour une quelconque autorité de certification d’émettre un certificat pour un site Web sans la permission de son propriétaire. Pour ce faire, la technique d’« épinglage » des certificats (« public key pinning ») permet de restreindre le nombre d’autorités de certification susceptibles d’émettre des certificats pour vos sites Web. Il est également possible d’adopter une approche plus sécurisée en approuvant chaque certificat individuellement.

La simplicité conceptuelle du modèle de maturité de la sécurité TLS permet de savoir facilement où nous en sommes et ce qu’il reste à améliorer. Nous pourrons ainsi nous concentrer sur ce qui importe vraiment. Même s’il offre la meilleure sécurité, le niveau 5 nécessite beaucoup de travail et gère des risques inexistants pour la plupart des sites. Et s’il ne fait pas l’unanimité, le Niveau 4 reste le niveau minimum reconnu comme sécurisé et vers lequel devraient tendre la plupart des entreprises.

BYOD, Chiffrement, Cloud, cryptage, Cyber-attaque, Cybersécurité, Entreprise, Fuite de données, Leak, Piratage

Cyber-Attaques : 95% des sites Web et eCommerce démunis

Peu sensibilisées et mal protégées, les petites et moyennes entreprises représentent des cibles de choix pour les hackeurs et fraudeurs. La plupart se feront piratées sans même le savoir. Au menu : défiguration du site, indisponibilité du site, compromission du site, vol de données client et vol d’identité, sans parler des fraudes. Le sujet vital de la cybersécurité web est étrangement peu abordé dans les débats eBusiness & eCommerce. Face à ce constat, quelles sont les options qui s’offrent aux PME ? Guides de recommandations, achats de produits et technologies, prestations ou sous-traitance spécialisées ?

Régis Rocroy, fondateur d’OZON, une startup spécialisée en Cybersécurité Web & eCommerce, nous explique que  Depuis 3 ans, nous assistons à une recrudescence des cyber-attaques & fraudes sophistiquées qui représentent des menaces persistantes pour près de 95 % des sites eCommerce. Les mesures de sécurité d’autrefois (firewall réseau et SSL/TLS) ne sont plus suffisantes.

Malheureusement, il est parfois nécessaire d’attendre l’incident pour sensibiliser (cf 25.000 sites web piratés en Janvier 2015). « Nous avons conçu la solution OZON afin de permettre aux petites et moyennes entreprises du monde entier de développer leurs activités eBusiness & eCommerce à l’abri des cyber-attaques et fraudes sophistiquées. Une sorte d’assurance tout risque numérique web. Avec une solution SaaS clé-en-main, transparente et économique, OZON lève les barrières financières et techniques d’accès à des technologies de sécurité coûteuses et complexes.« 

Une récente étude dévoile d’ailleurs que le budget moyen alloué à la sécurité de l’information a baissé de plus de 4% depuis un an. Pourtant, le risque a doublé pour les entreprises par rapport à 2013 et le nombre de cyber-attaques recensées en 2014 est en hausse de 48 % dans le monde, atteignant un nombre total de 42,8 millions, soit l’équivalent de 117 339 attaques par jour pour un coût de 2,7 millions de dollars.

Cybersécurité, Logiciels, Red Hat

Faille pour la librairie GnuTLS

Une nouvelle vulnérabilité de sécurité majeure a été découverte dans la bibliothèque cryptographique populaire GnuTLS qui laisse penser que Linux serait vulnérable à la possibilité malveillante d’exécution, à distance, d’un code pirate.

GNUTLS est une bibliothèque libre qui exploite le SSL (Secure Socket Layer), le Transport Layer Security (TLS) et du Datagram Transport Layer Security (DTLS). Bref, des protocoles qui sont utilisés pour offrir aux utilisateurs des communications sécurisées, chiffrées, donc normalement illisible par un personne non autorisée. La faille se trouve dans la façon d’analyser les identifiants de session du serveur.

Red Hat apporte toutes les explications, et le correctif qui est obligatoire pour sécuriser ses communications. Un serveur malveillant pourrait exploiter cette vulnérabilité en envoyant une session ID tellement longue que la bibliothèque plante et permet, dans la foulée, l’exécution du code malveillant via un outil de connexion TLS/SSL.

En Mars dernier, une autre vulnérabilité avait été corrigée dans la bibliothèque GnuTLS bibliothèque. Elle permettait de créer un certificat spécialement conçu qui pouvait être ensuite accepté par GnuTLS via un site pirate.