LA SOLUTION WAF DE DENY ALL OFFRE TOUTES LES FONCTIONNALITÉS RECOMMANDÉES PAR LE CONSORTIUM PCI DSS
Être conforme à toutes les exigences de la norme PCI DSS relatives aux composants du système au sein d'un environnement de données des cartes bancaires.
Réagir de manière appropriée (conformément à la politique ou aux règles en vigueur) aux menaces pesant sur les vulnérabilités telles qu'elles ont été identifiées, au moins dans le Top Ten de l'OWASP et/ou dans l'exigence 6.5 de la norme PCI DSS.
Inspecter les entrées des applications Web et réagir (autoriser, bloquer et/ou alerter) en fonction de la politique ou des règles en vigueur et consigner les mesures prises.
Prévenir la fuite de données, c'est-à-dire avoir la capacité d'inspecter les sorties des applications Web et réagir (autoriser, bloquer, masquer et/ou ou alerter) en fonction de la politique ou des règles en vigueur et consigner les mesures prises.
Appliquer des modèles de sécurité positive et négative. Le modèle de sécurité positive (« liste blanche ») définit le comportement, les entrées, les plages de données, etc. acceptables et autorisés, et refuse le reste. Le modèle de sécurité négative (« liste noire ») définit ce qui n'est PAS autorisé. Les messages correspondant à leurs signatures sont bloqués, et l'accès ne correspondant pas aux signatures (données ne figurant pas sur la « liste noire ») est autorisé.
Inspecter les messages de services web, si les services web sont exposés à l'internet public. En général, cela comprend le protocole SOAP et le langage XML, tous les modèles orientés document, et RPC, en plus du protocole HTTP.
Inspecter tout protocole (propriétaire ou normalisé) ou construction de données (propriétaires ou normalisées) utilisé pour transmettre des données en provenance ou à destination d'une application Web, lorsque ces protocoles ou ces données ne sont pas inspectés par ailleurs.
Se protéger contre des menaces visant le WAF lui-même.
Prendre en charge la terminaison SSL et/ou TLS, ou être positionné de sorte que les transmissions cryptées soient décryptées avant d'être inspectées par le WAF. Les flux de données cryptées ne peuvent être inspectés sauf si le protocole SSL se termine en amont de l'outil d'inspection.
FONCTIONNALITÉS SUPPLÉMENTAIRES RECOMMANDÉES POUR CERTAINS ENVIRONNEMENTS
Prévenir et/ou détecter la falsification de jetons de session, par exemple en chiffrant les cookies de session, les champs de formulaires masqués ou d'autres éléments de données servant à maintenir l'état de la session.
Recevoir et appliquer automatiquement les mises à jour de signatures dynamiques d'un fournisseur ou d'une autre source. Si cette fonctionnalité n'est pas disponible, il convient de mettre en place des procédures assurant une mise à jour fréquente des signatures WAF ou d'autres paramètres de configuration.
« Fail open » (un dispositif en panne permet au trafic de circuler sans inspection) ou « fail closed » (un dispositif en panne bloque tout trafic), en fonction de la politique en vigueur.
Dans certains environnements, le WAF devrait prendre en charge les certificats de clients SSL et l'authentification des clients utilisant des proxies par l'intermédiaire de certificats. De nombreuses applications web modernes utilisent les certificats de clients SSL pour identifier les utilisateurs finaux. Sans cette prise en charge, ces applications ne peuvent résider derrière un pare-feu applicatif. De nombreux pare-feux applicatifs actuels intègreront le protocole LDAP ou d'autres répertoires utilisateurs et pourront même exécuter une authentification initiale pour le compte de l'application sous-jacente.
Certaines applications pour le commerce électronique peuvent nécessiter un support de base de clés matérielles FIPS. Si cet élément doit être pris en compte dans votre environnement, assurez-vous que l'éditeur du pare-feu applicatif offre un système prenant en charge cette exigence et sachez que cette caractéristique peut augmenter considérablement le coût de la solution.