Security Empowers Business

Security
Empowers
Business
Les solutions « Encrypted Traffic
Management » de Blue Coat permettent
aux organisations d’éliminer l’angle
mort et de déployer à leur rythme
une politique de sécurisation des flux
chiffrés conforme aux préconisations
de l’ANSSI et de la CNIL.
Les trafics chiffrés, un angle mort pour la sécurité
Les flux chiffrés traversant les infrastructures des entreprises peuvent
représenter jusqu’à 40 ou 50% du trafic. Cette proportion est en forte
croissance depuis déjà quelques mois. Si l’utilisation des flux chiffrés permet
d’augmenter la confidentialité des informations, elle représente également
un angle mort empêchant les solutions de sécurité d’assurer leur mission.
Ce manque de visibilité expose les organisations aux attaques telles que
Dyre ou Zeus comme à de l’exfiltration de données via les flux chiffrés.
C’est un phénomène qui ne peut plus rester ignoré par les entreprises. Si
l’utilisation des flux HTTPS reste nécessaire pour garantir la confidentialité
des échanges d’informations, cela ne peut plus se faire au détriment de la
sécurité. Les organisations doivent désormais mettre en place une politique
de déchiffrement et d’inspection du trafic au même titre qu’elles ont
déployé, il y a déjà quelques années, une politique d’accès à Internet.
L’agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)
a souligné l’importance de la visibilité et du contrôle des flux chiffrés
au travers d’une note technique décrivant les bonnes pratiques et les
recommandations de sécurité concernant l’analyse des flux HTTPS. Mais le
déchiffrement ne peut se faire que de manière contrôlée.
La Commission Nationale de l’Informatique et des Libertés (CNIL) a
confirmé le besoin et considère le déchiffrement des flux SSL pour assurer la
sécurité des systèmes d’information comme « une mesure légitime mais qui
doit être encadrée »
Les bonnes pratiques définies par l’ANSSI couvrent entre autres :
• La sécurité des certificats utilisés SSL/TLS et la gestion des clés.
• L’utilisation des algorithmes de chiffrement les plus évolués et les plus
standards
• La mise en place d’un politique de déchiffrement granulaire capable de
protéger le caractère privé de certains échanges
• La gestion des vulnérabilités SSL/TLS pour éliminer les failles de sécurité
L’Offre “Encrypted Traffic Management” de Blue Coat est disponible via
les technologies « ProxySG » et au travers de la solution dédiée « SSL
Visibility Appliance »
SOLUTION SUMMARY
MISE EN PLACE D’UNE POLITIQUE DE SECURISATION DES FLUX CHIFFRES
CONFORME AUX RECOMMANDATIONS DE L’ANSSI ET DE LA CNIL
BLUE COAT PROXYSG
BLUE COAT SSL VISIBILITY APPLIANCE
Blue Coat corrige l’intégralité des vulnérabilités
découvertes dans les librairies SSL/TLS.
Concernant le trafic, Le SSLVA utilise sa propre
bibliothèque SSL/TLS et n’est donc pas a priori
vulnérable aux failles des bibliothèques publiques. Le
SSLVA utilise uniquement OpenSSL sur son interface
de management, et Blue Coat corrige l’intégralité des
vulnérabilités découvertes dans cette librairie SSL/TLS.
R2. Les clés privées associées aux certificats doivent
être correctement protégées.
Les ProxySG stockent les clés privées de façon à les
rendre invisible dans la configuration. Les clés sont
stockées en format chiffré sur les disques. En parallèle,
les ProxySG sont compatibles avec des boitiers HSM
(Safenet).
Le SSLVA stocke les clés privés de façon à les rendre
inaccessibles depuis l’interface de configuration, même
en disposant d’un accès physique au boitier. De plus,
il est impossible d’accéder directement à l’OS (shell).
Les différents boitiers SSLVA sont certifiés FIPS140-2
level 2 ou en cours de certification. De plus, le SSLVA
est compatible avec des boitiers HSM (Safenet) qui
améliorent la sécurisation des clés.
R3. Quel que soit le contexte de mise en oeuvre de TLS,
des mécanismes de vérification automatiques doivent
être mis en place afin de s’assurer que les certificats
employés sont bien valides.
Les ProxySG supportent la vérification des CRL ainsi que Le SSLVA valide les certificats serveur en vérifiant
le protocole OCSP.
que l’AC fait bien partie des AC de confiance. La liste
des AC de confiance, modifiable, inclut par défaut
celles reconnues par IE/Firefox. Des CRL peut être
chargées manuellement sur le SSLVA. OCSP n’est pas
implémenté, néanmoins l’OCSP stapling est autorisé
entre le client et le serveur.
R4. Seule une AC non publique (dont la confiance n’est
pas reconnue au delà du système d’information) doit être
utilisée pour signer les certificats que le proxy présente à
ses clients.
Les ProxySG permettent d’importer un certificat
d’autorité de certification intérmédiaire d’une PKI interne
existante.
Le SSLVA permet soit la création d’AC auto-signées, soit
l’import d’AC, dont la vérification du caractère privé est
de la responsabilité de l’administrateur.
R5. La chaîne de confiance associée au certificat de
l’AC interne qui a signé les certificats présentés par le
proxy à ses clients doit être placée dans le magasin
des autorités de confiance utilisé par le navigateur des
clients. La confiance accordée à cette chaîne par le
navigateur doit être limitée à l’authentification des sites
web (si l’AC interne n’est utilisée que pour signer des
certificats serveurs).
L’AC interne importée sur le Proxy peut être poussée sur
les navigateurs via GPO Active Directory et permet ainsi
aux clients d’authentifier les sites web.
L’AC interne importée sur le SSLVA peut être poussée
sur les navigateurs via GPO Active Directory et permet
ainsi aux clients d’authentifier les sites web sans
intervention manuelle. Le SSLVA pouvant déchiffrer
d’autres flux que le HTTPS, il est du ressort de
l’administrateur d’utiliser éventuellement plusieurs AC en
fonction du type de trafic à déchiffrer.
R6. Une AC intermédiaire interne (sous-AC) doit être
dédiée à la signature des certificats présentés par le
proxy à ses clients.
L’AC importée sur le ProxySG pour signer les certificats
est paramétrable et peut être une PKI Interne.
Les clés privées associées aux certificats présentés aux
clients sont stockées en mémoire (et ne survivent pas à
un reboot).
L’AC importée sur le SSLVA pour signer les certificats
est paramétrable et peut tout à fait être une PKI
Interne. Il n’y a pas d’AC pré-configurée. Les clés
privées associées aux certificats présentés aux clients
sont stockées en mémoire (et ne survivent pas à un
redémarrage).
R7. Si la solution de proxy intégre nativement une AC
(pré-configurée en amont par l’éditeur ou initialisée à
l’installation), celle-ci ne doit pas être utilisée pour signer
de certificats. L’usage de ce type d’AC présente des
risques : autorité identique sur différents équipements,
utilisation de gabarits non appropriés, etc.
R8. Les clés privées associées aux certificats présentés
par le proxy à ses clients doivent être protégées par des
mécanismes adaptés.
SOLUTION SUMMARY
Security
Empowers
Business
ANSSI RECOMMANDATION
R1. Il est impératif d’appliquer rapidement les correctifs
de sécurité associés à une bibliothèque ou à un
applicatif TLS dès lors qu’ils corrigent des vulnérabilités
jugées importantes.
BLUE COAT PROXYSG
BLUE COAT SSL VISIBILITY APPLIANCE
Support de TLS 1.2. Perfect Forward Secrecy supporté
grâce à l’utilisation de cipher DHE ou ECDHE. Les
certificats émulés peuvent être utilisées avec des taille de
clés de 2048 bits et Hachage SHA256.
Le SSLVA n’intervient pas dans la négociation entre le
client et le serveur de la version de TLS ni des suites
de chiffrement. Le SSLVA supporte les versions de TLS
jusqu’à la 1.2.
R11. Le proxy ne doit offrir à ses clients que des suites
cryptographiques robustes.
Le ProxySG choisira systématiquement l’algorithme avec
le plus haut niveau de sécurité dans la liste des Cipher
que propose le client. Le Proxy peut en outre refuser
la connexion si celle-ci ne satisfait pas une sécurité
minimale en terme de chiffrement.
Le SSLVA n’intervient pas dans la négociation des suites
de chiffrement entre le client et le serveur.
R12. Les suites cryptographiques les plus robustes
offertes par le proxy doivent permettre la PFS.
Le ProxySG supporte le PFS au travers des cipher DHE
& ECDHE.
Le SSLVA permet le déchiffrement des flux utilisant la
PFS au travers des algorithmes DHE et ECDHE.
R13. La compression TLS doit être désactivée au niveau
du serveur TLS du proxy.
Le ProxySG ne supporte pas la compression TLS.
Le SSLVA n’intervient pas dans la négociation de la
compression TLS. Cependant il ne permet pas le
déchiffrement en cas de compression TLS.
R14. Si le proxy supporte la reprise des sessions
TLS, il est nécessaire de vérifier quels mécanismes il
implémente et comment ces derniers fonctionnent.
Le ProxySG supporte les renégociations sécurisées
comme décrites dans la RFC 5746. Le ProxySG peut
forcer les rénégociations sécurisées.
Le SSLVA supporte la reprise des sessions TLS. Il met
en cache les éléments de la négociation TLS et permet
ainsi le déchiffrement en cas de réutilisation du Session
ID ou du Session Ticket.
R15. Le comportement du proxy en tant que client
TLS doit être vérifié afin de s’assurer que celui-ci
n’introduise pas de faiblesses lors de l’établissement des
tunnels TLS. Il est par exemple nécessaire de valider le
fonctionnement du proxy lorsqu’un serveur lui présente
un certificat qui n’est plus valide.
Le ProxySG va valider les informations suivantes :
• Le CN du certificat match bien l’URL qu’a demandé
l’utilisateur
• La date de validité du certificat
• La CA qui a signé le certificat
• La révocation du certificat (CRL ou OCSP)
Il peut en outre bloquer la session si celle-ci ne présente
pas une force de chiffrement suffisante.
Le SSLVA va valider les informations suivantes :
• La date de validité du certificat
• La CA qui a signé le certificat
• La révocation du certificat (CRL)
R16. Le client TLS du proxy doit supporter TLS v1.1
et v1.2 afin de disposer du meilleur niveau de sécurité
lorsque les sites web visités supportent ces versions
récentes du protocole.
Le ProxySG supporte :
• le TLS 1.1 & 1.2
• Des algorithmes de chiffrement supportant le PFS
(DHE & ECDHE)
• Les renégociations sécurisées
Le SSLVA n’intervient pas dans la négociation TLS
entre le client et le serveur. Il permet notamment le
déchiffrement dans le cadre suivant :
• SSLv3, TLS 1.0 & 1.1 & 1.2
• Des algorithmes de chiffrement supportant le PFS
(DHE et ECDHE)
Les renégociations sécurisées (RFC 5746) ne sont
cependant pas supportées.
R10. Le proxy ne doit permettre l’établissement de
tunnels TLS qu’en utilisant les versions de TLS les plus
récentes supportées par les navigateurs web des clients.
R17. Les suites cryptographiques supportées par le
proxy doivent être proposées au serveur web selon un
ordre pré-établi. Les suites les plus robustes (incluant la
PFS) doivent être préférées.
R18. Si le client du proxy supporte la renégociation TLS,
celle-ci doit être sécurisée.
SOLUTION SUMMARY
Security
Empowers
Business
ANSSI RECOMMANDATION
R9. Les certificats présentés par le proxy à ses clients
doivent être générés en utilisant des gabarits qui
respectent les recommandations mentionnées dans les
annexes du RGS.
Blue Coat Systems Inc.
www.bluecoat.com
BLUE COAT PROXYSG
BLUE COAT SSL VISIBILITY APPLIANCE
Le ProxySG permet de refuser l’établissement d’une
sessions sécurisées si celle-ci ne présente pas
suffisamment de sécurité quant à la force de chiffrement.
Le SSLVA permet de refuser une session sécurisée si
celle-ci utilise une suite de chiffrement trop faible.
R20. La compression TLS doit être désactivée au niveau
du client TLS du proxy.
Le ProxySG ne supporte pas la compression TLS.
Le SSLVA n’intervient pas dans la négociation TLS. Si la
compression TLS est activée, le SSLVA ne pourra pas
déchiffrer le flux. Il est possible de configurer le SSLVA
pour qu’il bloque l’établissement de la session si la
compression TLS est activée.
R21. La liste des AC publiques de confiance intégrées à
la solution de proxy doit être vérifiée à l’installation et doit
être revue de façon régulière.
Le ProxySG met à jour régulièrement et
automatiquement ses certificats d’Autorité de
certification. Cette mise à jour peut être désactivées et
faite manuellement par un administrateur.
La liste des AC de confiance correspond par
défaut à celle de IE/Firefox. Elle est modifiable par
l’administrateur. A chaque montée de version, une mise
à jour de cette liste est mise à disposition par Blue Coat
si nécessaire.
R22. Ne pas procéder au déchiffrement de certains
types de sites web identifiés comme étant destinés à un
usage strictement personnel (certains sites bancaires par
exemple).
Le ProxySG permet d’exclure certains type de sites web
du déchiffrement SSL (sites particuliers, catégories de
sites…).
Le SSLVA permet nativement de lister des sites web qui
ne doivent pas être interceptés. De plus, il dispose en
option d’une fonctionnalité de catégorisation des sites
web qui permet de configurer le (non-)déchiffrement en
fonction de la catégorie (par exemple, Santé, Services
Financiers, etc.).
R23. La journalisation des flux déchiffrés doit être
équivalente à celle configurée pour les flux HTTP
standards traités par le proxy. Elle ne doit pas permettre
d’enregistrer davantage d’informations.
La journalisation des sessions SSL déchiffrées peut être
configurée à l’identique des sessions HTTP. La licence
Encrypted TAP permet de rediriger le trafic déchiffré à
destination de solution de sécurité tierces. Lors d’une
analyse antivirus (via une solution externe, Blue Coat
ou tierces) le Secure ICAP permet de ne pas rompre la
chaine de confidentialité en maintenant un chiffrement
lors des communications.
Le SSLVA ne journalise aucune information extraite du
trafic déchiffré. Le SSLVA recopie l’ensemble des flux
interceptés (déchiffrés & non chiffrés) sur des ports dits
« TAP » (sans adresse IP, et normalement directement
liés à un équipement d’écoute et d’analyse du trafic, car
non routables ni commutables). Il est de la responsabilité
de l’administrateur de s’assurer de la sécurité logique
et physique des câbles réseau et des équipements
d’écoute et d’analyse du trafic.
R24. Si le proxy transmet à d’autres équipements le
contenu déchiffré des flux HTTPS, les liens sur lesquels
transitent ces informations doivent être protégés
logiquement et physiquement pour éviter tout accès
illégitime aux données.
Corporate Headquarters
Sunnyvale, CA
+1.408.220.2200
EMEA Headquarters
Hampshire, UK
+44.1252.554600
APAC Headquarters
Singapore
+65.6826.7000
© 2015 Blue Coat Systems, Inc. All rights reserved. Blue Coat, the Blue Coat logos, ProxySG, PacketShaper, CacheFlow, IntelligenceCenter, CacheOS, CachePulse, Crossbeam, K9, the K9 logo, DRTR, MACH5, PacketWise, Policycenter, ProxyAV, ProxyClient, SGOS,
WebPulse, Solera Networks, the Solera Networks logos, DeepSee, “See Everything. Know Everything.”, “Security Empowers Business”, and BlueTouch are registered trademarks or trademarks of Blue Coat Systems, Inc. or its affiliates in the U.S. and certain other
countries. This list may not be complete, and the absence of a trademark from this list does not mean it is not a trademark of Blue Coat or that Blue Coat has stopped using the trademark. All other trademarks mentioned in this document owned by third parties are the
property of their respective owners. This document is for informational purposes only. Blue Coat makes no warranties, express, implied, or statutory, as to the information in this document. Blue Coat products, technical services, and any other technical data referenced
in this document are subject to U.S. export control and sanctions laws, regulations and requirements, and may be subject to export or import regulations in other countries. You agree to comply strictly with these laws, regulations and requirements, and acknowledge
that you have the responsibility to obtain any licenses, permits or other approvals that may be required in order to export, re-export, transfer in country or import after delivery to you. v.SS-ANSSI-CNIL-A4-EN-v1c-0915
SOLUTION SUMMARY
Security
Empowers
Business
ANSSI RECOMMANDATION
R19. Sauf à ce que ce soit expressément validé,
lorsqu’un serveur web sélectionne une suite
cryptographique qui n’est pas assez robuste, le proxy
doit refuser l’établissement du tunnel TLS. Le proxy peut
informer le client à l’origine de la demande et lui indiquer
que le site qu’il cherche à joindre ne fournit pas un
niveau de sécurité suffisant au regard des exigences qui
lui sont fixées.