Palo Lb Prochainfirewall 001

. Livre Blanc

10 choses

que votre prochain firewall doit faire.

avec

MIEL . LIVRE BLANC 2

et

vous proposent le pare-feu de nouvelle génération

Introduction

La question d‟apporter du contrôle et de la visibilité des applications dans la sécurité réseau

s‟est récemment beaucoup posée. La raison est évidente : les applications peuvent

facilement contourner les firewalls classiques basés sur les ports et les employés utilisent

toutes les applications possibles leur permettant d‟effectuer leur tâche. Ils sont de fait

souvent indifférents aux risques qu‟ils font prendre à l‟entreprise.

La grande majorité des éditeurs de sécurité réseau s‟accordent sur le fait que le contrôle des applications prend

une part centrale dans la sécurité. Alors que le firewall de nouvelle génération (Next Generation FireWall:

NGFW) est bien défini par Gartner comme un élément nouveau, concentré sur l‟entreprise et distinct du firewall

classique, de nombreux éditeurs de sécurité présentent le NGFW comme un sous-ensemble de fonctions qu‟ils

proposent déjà ( UTM, IPS). La plupart des vendeurs de sécurité réseau essaient de fournir de la visibilité et du

contrôle applicatifs en utilisant un nombre limité de signatures d‟applications supportées dans leur IPS ou dans

une base de données externe. La réalité derrière cette façade est que ces fonctions sont faiblement intégrées et

que leurs produits sont encore basés sur une technologie classique de blocage de port et non pas sur la

technologie NGFW.

Encore plus important, ces gens ratent l‟essentiel : il ne s‟agit pas de bloquer des applications, mais de sécuriser

leur utilisation. En fait, les produits proposés par les éditeurs traditionnels ignorent pour beaucoup ce que les

entreprises font aujourd‟hui des applications – elles sont là pour faire « tourner » l‟entreprise – et par conséquent,

les entreprises ont besoin de s‟assurer qu‟elles s‟exécutent en toute sécurité. Il est évident qu‟un firewall de

nouvelle génération représente une classe de produits différente et révolutionnaire, mais la demande venant des

entreprises pour ce type de produit est tellement forte que les acteurs traditionnels de la sécurité se servent de

cet intérêt et essaient de faire diversion en tentant de ressembler à un firewall de nouvelle génération.


et


Définition : Le firewall de nouvelle génération

Pour une entreprise à la recherche d‟un firewall nouvelle génération, la considération la plus

importante est : cette technologie permettra-t-elle aux administrateurs de sécuriser

l‟utilisation de toutes les applications de l‟entreprise ? Voici un florilège de questions clés à

se poser :

La visibilité et la compréhension des applications sera-t-elle supérieure ?

Les options de contrôle du trafic iront-elle au-delà du simplissime autoriser/bloquer ?

Les menaces seront-elles bloquées ?

Le compromis entre les performances et la sécurité sera-t-il enfin éliminé ?

Les coûts seront-ils réduits ?

La gestion des risques sera-t-elle simplifiée ?

Si les réponses aux questions ci dessus sont “oui” alors la transition vers un firewall nouvelle génération est

facile à justifier.

Il existe des différences substantielles ente des NGFWs et des produits de type UTM –en termes d‟entreprises

cibles, ainsi qu‟en termes d‟architecture et de modèle de sécurité. Ces différences ont un impact crucial sur les

propriétés, les fonctions, la production et les performances, comme nous le montrons dans la section suivante.

5 exigences (Définition du Gartner dans Defining The Next Generation Firewall)

Identifier les applications indépendamment du port, du protocole, du chiffrement SSL ou toute autre technique d'évasion

Identifier les utilisateurs indépendamment de leur adresse IP

Protéger en temps réel contre les menaces embarquées dans les applications

Visibilité et contrôle des règles granulaires sur l'accès aux applications et leurs fonctionnalités

Déploiement en ligne multi-gigabits, sans dégradation de performance


et


Architecture et modèle de sécurité : La meilleure classification du trafic se fait dans le firewall.

En concevant les “firewalls de nouvelle génération”, les éditeurs de sécurité ont forcément une des deux

approches suivantes:

Faire l‟identification des applications dans le firewall, qui devient alors le moteur primaire de

classification.

Ajouter des signatures d‟application à un IPS ou à un moteur de recherche de type IPS qui est ensuite

ajouté à un firewall basé sur les ports.

Les deux peuvent reconnaitre les applications –mais diffèrent beaucoup dans la qualité de

reconnaissance, la facilité d‟utilisation et la pertinence. Plus important : ces approches

architecturales imposent un modèle de sécurité spécifique concernant l‟application des

règles : Soit positif (bloquer par défaut), soit négatif (autoriser par défaut).

Les firewalls utilisent un modèle de sécurité positif. Un autre terme employé est « default deny » : blocage par

défaut. Ce qui signifie que les administrateurs écrivent des règles pour AUTORISER un trafic (id. autoriser

WebEx)… et tout le reste est alors refusé ou bloqué. Les règles négatives (id. Bloquer Limewire) peuvent être

utilisées dans ce modèle, mais le point le plus important est que la fin d‟une règle dans un modèle de sécurité

positif soit toujours : “refuser tout le reste”. Une implication clé de cette approche est que tout trafic doit être

classifié afin que l‟on soit certain d‟autoriser le bon trafic. Ainsi la visibilité du trafic est simple et complète. Les

règles activent les applications. Une conséquence fondamentale de cette approche est que tout trafic inconnu est

bloqué par défaut. En d‟autres termes, le meilleur firewall de nouvelle génération est un firewall...

Les IPS (Intrusion Prevention Systems) utilisent typiquement un modèle de sécurité négatif, qui autorise par

défaut. Ceci signifie que l‟IPS identifie et bloque un trafic spécifique (traditionnellement les menaces)… et tout le

reste passe. Les éditeurs de sécurité réseau traditionnels ajoutent des signatures d‟applications à un moteur de

style IPS et les mélangent à un firewall classique basé sur le port. Le résultat est un APS, « Application

Prevention System » : le contrôle de l‟application se fait sur un modèle de sécurité négatif –en d‟autres mots, ca

ne se passe pas dans le firewall. La conséquence ? On ne voit que le trafic qu‟on cherche expressément et le

trafic inconnu est autorisé par défaut.

Alors que ce document s‟attache aux 10 choses que votre prochain firewall doit faire, il est important d‟avoir en

tête les considérations d‟architecture et de modèle évoquées ci-dessus. Elles sont en effet nécessaires pour

comprendre les différentes fonctions des divers produits du marché et leur capacité à fournir ces fonctions.

Les « 10 choses » évoquées ci-dessous regroupent les besoins et exigences spécifiques de milliers d‟équipes de

sécurité avec lesquelles Palo Alto Networks a été en contact depuis 2007 au sujet des firewalls de nouvelle

génération. Il s‟agit d‟exemples du monde réel de besoins clients permettant de rendre la sécurisation des

réseaux plus pratique, plus efficace et plus simple. Rien à voir avec du buzz marketing.


et


Les 10 choses que votre prochain firewall (de nouvelle génération) doit faire

Il existe trois zones de réflexion: les fonctions de sécurité, l‟opérationnel, et la performance.

Les fonctions de sécurité correspondent à l‟efficacité des contrôles et à la capacité à gérer

les risques associés au trafic réseau. D‟un point de vue opérationnel, la grande question est

« où se passe l‟application des règles, et quel est le niveau de complexité de

l‟administration? ». La réflexion sur les performances est simple : le firewall est-il capable de

faire ce qu‟il est censé faire au débit où il est supposé le faire ? Les dix choses que votre

prochain firewall (de nouvelle génération) doit faire sont :

1

Cas Client : les développeurs de l‟entreprise ne travaillent plus sur le modèle standard port/protocole/application.

De plus en plus d‟applications sont capables d‟opérer sur des ports non standards ou peuvent changer

dynamiquement de port (id. la messagerie instantanée, le partage de fichiers peer-to-peer, ou la VoIP). De plus,

les utilisateurs sont aujourd‟hui de plus en plus capables d‟utiliser des méthodes pour forcer les applications à

fonctionner sur des ports non standards (id. MS RDP, SSH). Afin d‟appliquer des règles spécifiques aux

applications alors que les ports utilisés sont de moins en moins significatifs, vous devez supposer que n‟importe

quelles application peut utiliser n‟importe quel port. C‟est un de ces changements technologiques fondamentaux

qui ont fait du NGFW une absolue nécessité. C‟est aussi ce qui a rendu obsolète le contrôle positif basé sur les

ports des firewalls traditionnels. Ce point souligne également pourquoi un modèle de contrôle négatif ne peut pas

résoudre le problème. Si une application peut passer par n‟importe quel port, un produit basé sur un contrôle

négatif devra faire fonctionner toutes les signatures sur des dizaines de milliers de ports !

Besoin : Il est simple dans ce cas. Si n‟importe quelle application peut fonctionner sur n‟importe quel port, votre

prochain firewall doit classifier le trafic par application, sur tous les ports, tout le temps (voir points 4 et 7). Dans

le cas contraire, les contrôles de sécurité continueront à être trompés par les mêmes techniques qui ont eu cours

pendant des années.

Votre prochain firewall doit identifier et contrôler les applications sur n‟importe quel port, pas seulement les ports standard (y compris les applications utilisant http ou d‟autres protocoles).


et


2

Cas client : Toutes les sociétés ou presque ont une politique de sécurité et des contrôles mis en place pour

appliquer cette politique. Les applications qui rebondissent sur des proxys, les applications d‟accès distant, et

celles qui utilisent des tunnels chiffrés sont précisément utilisées pour contourner les points de contrôles que sont

les firewalls, le filtrage URL, les IPS et les passerelles web sécurisées. Sans la capacité à contrôler ces

techniques d‟évasion, les règles de sécurité ne peuvent être appliquées, et les sociétés s‟exposent à des risques

dont elles pensaient être à l‟abri. Plus précisément, ces applications ne sont pas toutes de même valeur : les

applications d‟accès distant ont des utilisations légitimes, tout comme certaines applications qui passent dans des

tunnels chiffrés. Par contre, les proxys anonymes externes qui communiquent avec SSL ou à travers des ports

choisis au hasard ainsi que des applications comme Ultrasurf ou Tor n‟ont qu‟un seul objectif : contourner les

contrôles de sécurité.

Besoins : Plusieurs types d‟applications de contournement sévissent, chacune utilisant des techniques

légèrement différentes. Il existe des proxys externes publics et privés. (Voir proxy.org pour une base élargie de

proxys publics). Ces proxys utilisent à la fois HTTP et HTTPS. Les proxys privés sont souvent installés avec des

adresses IP non classifiées (id. PC domestiques) et utilisent des applications comme PHProxy ou CGIProxy. Les

applications d‟accès distants comme MS RDP ou GoToMyPC peuvent avoir une utilisation légitime mais doivent

être gérés à cause des risques associés à leur utilisation. Les applications de masquage comme Ultrasurf, Tor

ou Hamachi, elles, n‟ont pas d‟utilisation professionnelle. Il y a aussi évidemment des applications de ce type qui

sont inconnues : voir la partie 6 plus bas dans ce cas. Quelle que soit la politique choisie, votre prochain firewall

doit avoir des techniques spécifiques pour gérer toute ces applications indépendamment du port, du protocole, du

chiffrement ou de toute autre technique d‟évasion. Une considération supplémentaire : ces applications sont

régulièrement mises à jour pour les rendre encore plus difficiles à détecter. C‟est pourquoi il est important de

comprendre que votre prochain firewall doit non seulement être capable d‟identifier ces applications mais aussi

que son intelligence applicative doit être constamment maintenue et mise à jour.

Votre prochain firewall doit identifier les techniques d‟évasion et les contournements : proxy, accès distant, applications dans un tunnel chiffré.


et


3

Cas client : Aujourd‟hui, plus de 15% du trafic réseau est chiffré par SSL (selon une étude effectuée sur des

échantillons de trafic réseau de plus de 2400 entreprises : voir le rapport intitulé « Palo Alto Networks‟ Application

Usage and Risk Report » pour plus de détails). Dans certains secteurs (la finance notamment), c‟est plus de 50%.

Etant donné l‟utilisation de plus en plus fréquente de HTTPS pour des applications à succès mais à hauts risque

comme Gmail ou Facebook , et la possibilité qu‟offre le chiffrement de forcer l‟accès à de nombreux sites web, les

équipes sécurité ont un angle mort qui s‟agrandira toujours plus si elles ne sont pas en mesure de déchiffrer,

classifier, contrôler et scanner le trafic SSL. Bien sûr, un NGFW doit être suffisamment flexible pour que certains

types de flux chiffrés par SSL ne soient pas traités. C‟est souvent le cas par exemple pour les services financiers

ou les organisations médicales. A l‟inverse, d‟autres types de flux comme du SSL sur des ports non standard ou

en provenance de sites web non classifiés en Europe de l‟est doivent être déchiffrés par des règles.

Besoins : la capacité à déchiffrer le trafic SSL sortant est un élément fondateur, non seulement parce que cela

représente une partie du trafic de plus en plus importante, mais aussi parce que c‟est nécessaire pour utiliser

d‟autres fonctions clés par la suite (Contrôler les contournements - n°2, contrôle des fonctions des applications -

n°4, scanner les applications autorisées - n°5, et contrôler des applications partageant la même connexion - n°7).

Il faut donc considérer un certain nombre d‟éléments clés : la reconnaissance et le déchiffrement de SSL sur

n‟importe quel port, le déchiffrement soumis à des règles, et les éléments matériels et logiciels nécessaires pour

déchiffrer des milliers de connexions SSL simultanément sans dégradation de performance à haut débit.

4

Cas client : De nombreuses applications ont en elles plusieurs fonctions nettement distinctes, qui de fait n‟ont pas

le même profil de risque ni la même valeur pour l‟activité de l‟entreprise. Citons entre autres exemples WebEx

face à WebEx Desktop Sharing, Yahoo Instant Messaging face à la fonction incluse de transfert de fichier, et

Gmail face à l‟envoi de pièces jointes. Dans les environnements régulés ou dans les sociétés dont l‟activité

repose sur la propriété intellectuelle, ce problème est significatif.

Besoins : une classification continue et une compréhension granulaire de chaque application. Votre prochain

firewall doit continuellement évaluer le trafic et scruter les changements –si une nouvelle fonction est introduite

pendant la session, le firewall doit noter le changement et effectuer une vérification de règle. Différencier les

différentes fonctions d‟une même application et les différents risques associés est tout aussi important.

Malheureusement, pour des raisons de performance, de nombreux firewalls classifie le trafic une fois au début de

la session, puis laisse passer tout le reste sans regarder à nouveau (on parle de “fast path”). Cette méthode date

d‟avant l‟avènement des applications modernes et empêche les firewalls classiques qui datent de la même

époque de répondre à ces besoins.

Votre prochain firewall doit déchiffrer les flux SSL sortants

Votre prochain firewall doit permettre un contrôle des différentes fonctions d‟une même application (ex. : SharePoint Admin face à SharePoint Docs)


et


5

Cas client : les entreprises optent de plus en plus pour des applications collaboratives hébergées à l‟extérieur de

leur emplacement physique. Que ce soient des applications hébergées comme SharePoint, Box.net, Google

Docs, ou Microsoft Office Live, ou une application extranet hébergée par un partenaire, de nombreuses

entreprises doivent utiliser une application qui partage des fichiers –ce qui représente un vecteur de menaces à

haut risque. De nombreux documents infectés se situent dans des applications collaboratives, et coexistent avec

des documents contenant des informations sensibles (id. des données personnelles clients). De plus, certaines

de ces applications comme SharePoint, par exemple, reposent sur des technologies qui sont des cibles

régulières d‟infections et d‟intrusions (IIS, SQL Server). Bloquer l‟application n‟est pas approprié, mais autoriser

une menace ne l‟est pas non plus.

Besoins : Une composante importante de la sécurisation des applications est d‟autoriser une application mais de

scanner la présence de menaces. Ces applications peuvent communiquer grâce à une combinaison diverse de

protocoles (id., SharePoint – HTTPS et CIFS, voir le cas n°3), et requièrent une règle beaucoup plus

sophistiquée que « bloquer l‟application ». La première étape est d‟identifier l‟application (indépendamment du

port ou du chiffrement), l‟autoriser, puis de scanner tout type de menace potentielle : vulnérabilités,

virus/malware, spyware ou même une donnée confidentielle sensible.

6

Cas client : Il y aura toujours un trafic qui n‟est pas connu et il représentera toujours un risque significatif pour

toute entreprise. Deux éléments principaux sont à considérer concernant le trafic inconnu : d‟abord le minimiser

en caractérisant les applications propriétaires de manière à ce qu‟elles deviennent connues, puis avoir une

visibilité et des règles de contrôle prévisibles sur le trafic qui reste inconnu.

Besoins : d‟abord, par défaut, votre prochain firewall doit essayer de classifier tout le trafic : sur ce point, la

discussion précédente sur l‟architecture et la sécurité prend tout son sens. Les modèles positifs (default deny)

classifient tout, les modèles négatifs (default allow) ne classifient que ce qu‟on leur demande de classifier.

Deuxièmement, concernant les applications propriétaires, il devrait toujours y avoir un moyen de développer un

identifiant sur mesure pour que le trafic soit comptabilisé comme « connu ». Troisièmement, le modèle de

sécurité change radicalement la donne : un modèle positif (default deny) peut refuser tout le trafic inconnu, et ce

que vous ne connaissez pas ne vous menace pas. Un modèle négatif (default allow) autorise tout le trafic

inconnu, et ce que vous ne connaissez pas peut vous menacer. Par exemple, de nombreux botnets vont utiliser

le port 53 (DNS) pour la communication retour vers leurs serveurs de contrôle. Si votre prochain firewall n‟a pas

la capacité à voir et contrôler le trafic inconnu, les bots pourront traverser librement.

Votre prochain firewall doit détecter les menaces dans les applications collaboratives autorisées (ex. : SharePoint, Box.net, MS Office Online...)

Votre prochain firewall doit gérer le trafic inconnu avec des règles et ne pas simplement les laisser passer


et


7

Cas client : les applications partagent les sessions. Pour s‟assurer que les utilisateurs utilisent en permanence

une « plateforme » applicative, que ce soit Google, Facebook, Microsoft, Salesforce, LinkedIn, ou Yahoo !, les

développeurs intègrent de nombreuses applications différentes qui ont des profils de risque différents et une

valeur différente pour l‟entreprise. Regardons notre exemple précédent de Gmail : cette application a la

possibilité de lancer une session Google Talk depuis l‟interface Gmail. Ces deux applications sont

fondamentalement différentes, et votre prochain firewall doit les distinguer pour appliquer à chacune la règle

appropriée.

Besoins : Une simple classification de la plateforme ou du site web ne fonctionne pas. En d‟autres termes, le

“fast path” n‟est pas une option : une classification “une fois pour toutes” ignore le fait que des applications

différentes peuvent partager une même session. Il faut en fait continuellement évaluer le trafic pour comprendre

l‟application et ses changements (voir n°5), détecter quand l‟utilisateur change d‟application dans sa session et

appliquer alors les contrôles appropriés. Regardons brièvement notre exemple Gmail/Google Talk : Gmail utilise

par défaut HTTPS (voir n°3). Donc la première étape est de déchiffrer, puis de détecter l‟application. Cependant

ce mécanisme doit être constant car à n‟importe quel moment, l‟utilisateur peut démarrer un chat qui est alors

classifié différemment et peut être soumis à une règle totalement différente.

8

Cas client: Les utilisateurs se trouvent de plus en plus hors des murs de l‟entreprise. Outre les nomades, une part

significative du personnel travaille à distance. Depuis un café, le domicile ou un site client, les utilisateurs

s‟attendent à pouvoir se connecter à leurs applications par Wifi, large bande ou tout autre moyen nécessaire.

Quel que soit l‟emplacement de l‟utilisateur ou même celui de l‟application qu‟ils utilisent, le même standard de

contrôle devrait s‟appliquer. Si votre prochain firewall permet la visibilité et le contrôle du trafic entre les 4 murs de

l‟entreprise, mais pas à l‟extérieur, il rate les flux parmi les plus générateurs de risques.

Besoins : conceptuellement, c‟est simple : votre prochain firewall doit avoir une visibilité et un contrôle constant

sur le trafic, que l‟utilisateur soit à l‟intérieur ou à l‟extérieur du réseau. Il ne s‟agit pas de dire que les entreprises

auront exactement les mêmes règles pour les 2 types d‟utilisateur. Certaines sociétés peuvent vouloir que leurs

employés utilisent Skype lorsqu‟ils sont en déplacement, mais pas à l‟intérieur du siège. En revanche d‟autres

pourraient avoir une règle qui dit que lorsque les utilisateurs sont hors réseau, ils ne peuvent télécharger les

documents de salesforce.com à moins que le chiffrement du disque dur soit activé. Bien sûr, votre prochain

firewall doit être capable de faire cela sans introduire de latence pour l‟utilisateur final, sans que l‟administrateur

soit inutilement ou trop sollicité et sans coût supplémentaire significatif.

Votre prochain firewall doit identifier et contrôler les applications partageant une même connexion

Votre prochain firewall doit disposer du même contrôle et de la même visibilité sur les utilisateurs distants que sur les utilisateurs internes


et


9

Cas client : de nombreuses entreprises luttent contre l‟ajout d‟informations, de règles et d‟interfaces

d‟administration pour des administrateurs et des processus de sécurité déjà totalement surchargés. Si les

équipes ne peuvent gérer ce qu‟elles ont déjà, ajouter des règles, des informations et de l‟administration n‟aidera

pas du tout. De plus, plus la rège est distribuée, plus elle est difficile à gérer (le firewall basé sur le port autorise le

port 80, l‟IPS regarde/bloque les menaces et les applications, la passerelle web sécurisée applique le filtrage

URL). Où les administrateurs doivent-ils aller pour autoriser Webex ? Comment gèrent-ils les conflits de règles à

travers ces différents matériels? Ceci étant dit, certaines installations de firewall basé sur le port comportent des

milliers de règles, ajoutant des milliers de signatures d‟application à chacun des dizaines de milliers de ports (voir

n°3 ci-dessus). Dans ce cas, la complexité est décuplée.

Besoins : la règle de firewall doit être basée sur l‟utilisateur et l‟application. L‟analyse de contenu qui en résulte

n‟est alors activée que pour le trafic autorisé. L‟effet de simplification peut être significatif. Une règle de firewall

basée sur le port et l‟adresse IP, suivi d‟une analyse pour comprendre l‟application, rend les choses nettement

plus compliquées qu‟elles ne le seraient au sein du firewall nouvelle génération.

10

Cas client : nombre d‟entreprises doivent faire un compromis insatisfaisant entre les performances et la sécurité.

Trop souvent, l‟activation de toutes les protections signifie un effondrement des performances. Si votre firewall de

nouvelle génération est conçu de la bonne manière, le compromis n‟est pas nécessaire.

Besoins : là aussi, l‟importance de l‟architecture est évidente, mais d‟une autre manière. Associer un firewall basé

sur les ports avec d‟autres fonctions de sécurité d‟origines technologiques différentes signifie qu‟il y aura

forcément des redondances dans les couches de traitement réseau, dans les moteurs de scan et dans les règles.

Les performances s‟en trouvent forcément fortement réduites. D‟un point de vue logiciel, le firewall de nouvelle

génération doit être conçu à la base pour ses fonctions. De plus, les tâches exigées comme par exemple

l‟identification des applications sont particulièrement consommatrices de ressources. Si on y ajoute le fait qu‟elles

doivent s‟effectuer sur des hauts débits et avec une faible tolérance à la latence, il apparait nécessaire que la

partie matérielle doive également être conçue spécifiquement dans cet objectif. La plateforme doit traiter

spécifiquement et de manière distincte le réseau, la sécurité (incluant la terminaison SSL- voir n°3) et le scanning

du contenu.

Votre prochain firewall doit simplifier la sécurité réseau. Pouvoir contrôler les applications ne doit pas ajouter de complexité.

Votre prochain firewall doit fournir le même débit et les mêmes performances malgré l'activation de tous les contrôles applicatifs


et


Conclusion : Votre prochain firewall doit sécuriser les applications –et l’entreprise.

Les utilisateurs adoptent continuellement de nouvelles applications et technologies, et les

menaces qui vont avec. Pour beaucoup d‟entreprises, restreindre l‟adoption de ces nouvelles

technologies freine leur développement. Pouvoir utiliser une application donnée est parfois

une nécessité pour effectuer une tâche ou gagner en productivité. La conséquence ? La

sécurisation des applications plutôt que leur blocage devient la bonne règle à appliquer. Mais

pour cela, les équipes de sécurité doivent mettre en place la structure qui va définir les

bonnes règles et les contrôles qui les activeront.

Les 10 choses décrites ci dessus sont les fonctions critiques permettant la mise en place des

contrôles nécessaires dans un environnement toujours plus riche en applications et en

menaces. Sans l‟infrastructure de sécurité capable de faire face à cette variété et cette

dynamique, il est impossible de sécuriser les applications nécessaires et de gérer les risques

pour l‟entreprise.

Les 10 choses

1•Identifier et contrôler les applications sur n'importe quel port

2•Identifier et contrôler les trafics d'évasion et de contournement

3•Déchiffrer le trafic SSL sortant

4•Fournir un contrôle des applications par fonction

5•Détecter les virus et les malwares dans les applications collaboratives autorisées

6•Gérer le trafic inconnu avec des règles

7•Identifier et contrôler les applications qui partagent la même connexion

8•Permettre la même visibilité et le même contrôle pour les utilisateurs distants

9•Simplifier l'infrastructure de sécurité. Que l'addition du contrôle des applications n'ajoute pas de complexité

10•Fournir le même débit et les mêmes performances malgré l'activation de tous les contrôles applicatifs


et


Traduit de l‟anglais. Avril 2011.

A propos de Palo Alto Networks

Palo Alto Networks a été fondée en 2005 par le visionnaire de la sécurité, Nir Zuk, avec pour mission de ré-

inventer le pare-feu afin qu¹il soit de nouveau l‟équipement le plus stratégique dans le dispositif de sécurité d‟un

réseau d'entreprise.

Son conseil d'administration et son équipe de direction sont constitués d„anciens dirigeants et/ou fondateurs

parmi les plus importantes sociétés de sécurité réseau et technologies connexes, incluant l'invention du Stateful

Inspection, les matériels de sécurité et de prévention d'intrusion.

Quant à son équipe de recherche et développement, elle a fait la preuve de ses compétences dans des fonctions

similaires dans des entreprises telles que Check Point, Cisco, NetScreen, McAfee, Juniper Networks et d'autres.

La société a commencé à distribuer sa famille de Nouvelle génération de pare-feu en 2007 et a installé cette

solution dans des centaines d'entreprises et organisations du monde entier, y compris de nombreuses entreprises

classées Fortune 500 et compte à ce jour plus de 1200 clients actifs dans le Monde.

Palo Alto Networks a ouvert des bureaux de vente répartis en Amérique du Nord, Europe, Asie-Pacifique, et au

Japon, et commercialise ses pare-feu par l'intermédiaire d'un réseau mondial de distributeurs et de revendeurs.

A propos de Miel

Depuis 1985, Miel découvre et distribue en France les nouvelles technologies pour l'informatique des entreprises

dans les domaines des réseaux, des systèmes, de la sécurité et de l'informatique industrielle. Ses ingénieurs

s'appuient sur un réseau de partenaires intégrateurs pour diffuser ces produits sur le marché.

APPELEZ LE 01 60 19 34 52

Palo Lb Prochainfirewall 001

Documents

Transcript of Palo Lb Prochainfirewall 001