Introduction SCC. LIVRE BLANC 2

(1)

(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.

(3)

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

(4)

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 fonctionnalités 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 fonctionnalités » é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.

(5)

Les 10 fonctionnalités 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 fonctionnalités 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).

(6)

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.

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 risques 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

Votre prochain firewall doit identifier les techniques d’évasion et les

contournements : proxy, accès distant, applications dans un tunnel chiffré.

Votre prochain firewall doit déchiffrer les flux SSL sortants

(7)

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.

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

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

Votre prochain firewall doit détecter les menaces dans les applications

collaboratives autorisées (ex. : SharePoint, Box.net, MS Office Online...)

(8)

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.

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.

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

Votre prochain firewall doit identifier et contrôler les applications partageant une

même connexion

(9)

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.

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

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

Votre prochain firewall doit simplifier la sécurité réseau. Pouvoir contrôler les

applications ne doit pas ajouter de complexité.

(10)

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 l’exploitation 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 fournir le même débit et les mêmes performances

malgré l'activation de tous les contrôles applicatifs

(11)

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 fonctionnalités 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 fonctionnalités

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

(12)

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 3500 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.

Contact SCC

Charles GENGEMBRE – Business Development Manager Sécurité APPELEZ-LE : 01 41 91 30 12 - 06 67 49 63 86

Email : cgengembre@fr.scc.com