Supplément de renseignements : Examens d applications et pare-feux d applications web clarifiés Normes : Normes en matière de sécurité des données de

Transcription

1 Supplément de renseignements : Examens d applications et pare-feux d applications web clarifiés Normes : Normes en matière de sécurité des données de la PCI (PCI DSS) Version : 1.2 Date : Octobre 2008 Exigence : 6.6 Auteur : Conseil des normes de sécurité PCI 2 Renseignements d ordre général L exigence 6.6 des PCI DSS fournit deux options qui ont pour but d aborder les menaces communes aux titulaires de cartes et de s assurer que les données saisies dans les applications web exécutées des environnements non approuvés sont examinées «de haut en bas». Par «exécutées», nous voulons dire que l application a été déployée dans un environnement opérationnel, y compris les environnements de production, ou de test d acceptation/de pré-production avec des procédures associées de contrôle des changements solides. Les détails quant à la manière de satisfaire à cette exigence dépendront de l implémentation particulière supportant une application précise. Les analyses légales des incidents relatifs aux données du titulaire de carte ont montré que les applications Web sont fréquemment le point d attaque initial des données du titulaire de carte, par injection SQL en particulier. L objectif de l exigence 6.6 est de s assurer que les applications Web exposées à l Internet public sont protégées en permanence contre les sortes de menaces les plus communes lors de l exécution et la réception d entrées. De nombreux renseignements publics sont disponibles concernant les vulnérabilités des applications Web. Les vulnérabilités minimales à prendre en considération sont décrites dans l exigence 6.5. (Consulter la section «Sources de renseignements supplémentaires» pour obtenir d autres documents de référence sur les tests des applications Web.) La défense multi-couche idéale inclurait l implémentation adéquate des deux options énumérées dans l exigence 6.6. Cependant, le PCI SSC reconnaît que le coût et la complexité opérationnelle du déploiement des deux options peut le rendre irréalisable. En même temps, il devrait être possible d appliquer au moins une des alternatives décrites dans ce document, et une implémentation adéquate peut satisfaire l objectif de l exigence. Ce document fournit des directives pour aider à déterminer la meilleure option, qui peut varier en fonction des produits utilisés, de la manière par laquelle une société obtient ou développe ses applications Web, et d autres facteurs de l environnement.

2 Exigence 6.6, option 1 : Évaluation de la vulnérabilité de la sécurité des applications Web En gardant à l esprit que l objectif de l exigence 6.6 est de prévenir l exploitation des vulnérabilités communes, telles que celles qui sont énumérées dans l exigence 6.5, plusieurs solutions possibles peuvent être considérées. Elles sont dynamiques et proactives, exigeant la mise en place particulière d une procédure manuelle ou automatique. Correctement implémentées, ces alternatives peuvent satisfaire à l objectif de l exigence 6.6 et fournir le niveau de protection minimum contre les menaces aux applications Web communes : 1. Évaluation manuelle de la vulnérabilité de la sécurité des applications Web 2. Utilisation correcte des outils automatiques (d analyse) d évaluation de la vulnérabilité de la sécurité des applications Web Ceux-ci doivent être conçus pour tester la présence de vulnérabilités des applications Web tel qu indiqué dans la section «Renseignements d ordre général» ci-dessus. Veuillez remarquer qu une évaluation de vulnérabilité indique et signale simplement les vulnérabilités, alors qu un test d intrusion tente d exploiter les vulnérabilités afin de déterminer si un accès non autorisé ou une autre activité malveillante est possible. 3 Les évaluations peuvent être effectuées par une personne interne qualifiée ou par un tiers qualifié. Dans tous les cas, la ou les personnes doivent avoir les compétences et l expérience adéquates pour comprendre l application Web, le savoir-faire pour évaluer les vulnérabilités, et comprendre les résultats. Les personnes utilisant des outils automatiques doivent avoir les compétences et connaissances pour configurer correctement les outils et tester l environnement, utiliser l outil, et évaluer les résultats. Si des personnes internes sont utilisées, elles doivent être d une société autre que celle de la gestion de l application qui est testée. Par exemple, une équipe de développement qui écrit une application Web ne doit pas effectuer l évaluation de sécurité finale. Lorsqu elle est correctement effectuée, une évaluation de vulnérabilité d application Web peut fournir la même protection (voire une meilleure protection) que celle fournie par un pare-feu d application Web lorsque les vulnérabilités sont trouvées et corrigées avant d exposer l application à l Internet public. L évaluation peut utiliser une procédure manuelle ou des outils spécialisés pour tester la présence de vulnérabilités et défauts exposés dans une application Web exécutée. Cette approche implique la création et la soumission d entrées malveillantes ou non standard à l application, simulant ainsi une attaque. Les réponses à ces entrées sont examinées pour savoir si l application peut être vulnérable à certaines attaques. Évaluer une application dans un environnement de production fournit les meilleurs résultats, car c est l environnement qui est le plus susceptible d être attaqué. Cependant, effectuer ces évaluations sur un système de production peut introduire des risques opérationnels inacceptables. Les évaluations peuvent être incorporées dans le cycle de vie de la conception des logiciels (software development life cycle, SDLC) et effectuées avant que l application soit déployée dans un environnement de production, si

3 des politiques et procédures de contrôle des changements solides garantissent que l application exécutée évaluée dans l environnement de test d acceptation/de pré-production ne peut pas être différente de ce qui est déployé en production. Le SDLC doit intégrer la sécurité des renseignements partout, comme indiqué dans l exigence 6.3. Les procédures de contrôle des changements doivent garantir que les développeurs de logiciels ne peuvent pas contourner l étape d évaluation et déployer de nouveaux logiciels directement dans l environnement de production. Les procédures de contrôle des changements doivent aussi appliquer la correction et le retestage des vulnérabilités avant l implémentation. Tandis que la validation/approbation finale de l évaluation doit être donnée par une société indépendante interne ou un tiers, il est recommandé que des outils soient mis à la disposition des développeurs de logiciels et intégrés dans leurs suites logicielles autant que pratiquement possible. Cela permet de détecter et corriger les vulnérabilités aussi tôt que possible dans la procédure de développement. Il est important de confirmer la capacité d un outil à tester les vulnérabilités des applications Web communes avant de supposer qu il peut être utilisé pour satisfaire à l objectif de l exigence 6.6. De plus, pour faire face à des menaces nouvelles et émergentes, les outils doivent avoir la capacité d intégrer de nouvelles règles d analyse. Les personnes effectuant les évaluations doivent se tenir informées des tendances de l industrie pour s assurer que leurs compétences d évaluations ou de tests sont en mesure de traiter les nouvelles vulnérabilités. 4 Exigence 6.6, option 2 : Pare-feu des applications Web Un pare-feu d applications Web (web application firewall, WAF) est un point d application de politique de sécurité positionné entre une application Web et l extrémité du client. Cette fonctionnalité peut être implémentée dans un logiciel ou un matériel informatique, fonctionnant dans un dispositif serveur ou dans un serveur type exécutant un système d exploitation commun. Ce peut être un dispositif autonome ou intégré à d autres composants du réseau. Les pare-feu de réseaux types sont implémentés autour du réseau ou entre les segments (zones) du réseau, et fournissent la première ligne de défense contre de nombreuses sortes d attaques. Cependant, ils doivent permettre aux messages d atteindre les applications Web qu une société choisit d exposer à l Internet public. Les pare-feu de réseaux ne sont en principe pas conçus pour examiner, évaluer et réagir aux parties d un message IP (paquet) utilisé par des applications Web, et par conséquent les applications publiques reçoivent souvent des entrées non examinées. Par conséquent, un nouveau périmètre de sécurité logique est créé, l application Web elle-même, et les meilleures pratiques de sécurité font que les messages sont examinés quand ils arrivent d un environnement non approuvé vers un environnement approuvé. Il existe de nombreuses attaques

4 connues contre les applications Web et, comme nous le savons tous, les applications Web ne sont pas toujours conçues et écrites pour se défendre contre ces attaques. Ce qui rend le risque plus important est que ces applications sont virtuellement disponibles à toutes les personnes dotées d une connexion Internet. La structure d un paquet IP suit un modèle à couches, chaque couche contenant des renseignements définis sur lesquels des nœuds ou des composantes du réseau (physiques ou basés sur un logiciel) agissent, soutenant le flux de renseignements via Internet ou intranet. Le couche qui contient le contenu qui est traité par l application est appelée la «couche d application». Les WAF sont conçus pour examiner le contenu des couches d application d un paquet IP, ainsi que le contenu de toute autre couche qui pourrait être utilisée pour attaquer une application Web. Veuillez noter, cependant, que l exigence 6.6 n a pas pour but d introduire de contrôles redondants. Le contenu d un paquet IP adéquatement examiné (c est-à-dire fournissant une protection équivalente) par des pare-feu de réseau, des mandataires ou d autres composants, n a pas besoin d être réexaminé par un WAF. De plus en plus, la technologie WAF est intégrée dans des solutions qui comprennent d autres fonctions, telles que le filtrage de paquets, le mandatement, la terminaison SSL, la mise d objets en antémémoire, etc. Ces dispositifs sont commercialisés en tant que «pare-feu», «passerelles d application», «systèmes de livraison d application», «mandataires sécurisés» ou d autres descriptions. Il est important de comprendre pleinement les capacités d examen de données d un tel produit pour déterminer si le produit pourrait satisfaire à l objectif de l exigence 6.6. Veuillez noter que la conformité n est pas garantie simplement en implémentant un produit avec les capacités décrites dans ce document. Le positionnement, la configuration, l administration et la surveillance adéquats sont aussi des aspects clés d une solution conforme. Implémenter un WAF est une option pour satisfaire l exigence 6.6 et n élimine pas la nécessité d une procédure de développement de logiciel sécurisée (exigence 6.3). 5 Capacités recommandées Un pare-feu d application Web devrait pouvoir : Satisfaire à toutes les exigences PCI DSS applicables relatives aux composantes du système dans l environnement de données de titulaire de carte. Réagir de manière appropriée (tel que défini par la politique ou les règles en vigueur) aux menaces contre les vulnérabilités pertinentes telles qu elles sont identifiées, au minimum, dans le Top 10 de l OWASP et/ou l exigence 6.5 des PCI DSS. inspecter les entrées de l application Web et répondre (permettre, bloquer, et/ou alerter) en fonction des politiques ou règles en vigueur, et noter les actions prises.

5 Prévenir la fuite de données, ce qui signifie avoir la capacité d examiner les sorties de l application Web et répondre (permettre, bloquer, et/ou alerter) en fonction des politiques ou règles en vigueur, et noter les actions prises. Appliquer des modèles de sécurité positifs et négatifs. Le modèle positif («liste blanche») définit les comportements, entrées, gammes de données, etc. acceptables ou permises, et rejette tout le reste. Le modèle négatif («liste noire») définit ce qui n est PAS permis; les messages correspondant à ces signatures sont bloqués, et le trafic ne correspondant pas aux signatures (pas sur la «liste noire») est permis. Examiner le contenu des page Web, (tel que le langage HTML, le HTML dynamique (DHTML) et les feuilles de style en cascade (Cascading Style Sheets, CSS), ainsi que les protocoles sous-jacents qui fournissent du contenu, tels que les protocoles HTTP et HTTP par SSL (HTTPS). (En plus de SSL, HTTPS comprend le protocole HTTP sur TLS.) Examiner les messages de services Web, si les services Web sont exposés à l Internet public. D habitude, cela comprendrait le protocole SOAP et le langage XML, autant les modèles orientés vers les documents que ceux orientés vers les RPC, en plus du HTTP. Examiner tout protocole (propriétaire ou standardisé) ou toute structure de données (propriétaire ou standardisé) qui est utilisé pour transmettre des données vers une application Web, ou à partir de celle-ci, lorsque de tels protocoles ou données ne sont pas examinés à un autre endroit dans le flux du message. Remarque : les protocoles propriétaires représentent un défi aux produits de pare-feu d applications Web actuels et des modifications personnalisées peuvent être nécessaires. Si les messages d une application ne suivent pas des protocoles et des structures de données standard, il peut ne pas être raisonnable de demander qu un pare-feu d application Web examine ce flux de message particulier. Dans de tels cas, implémenter l option d évaluation de la vulnérabilité de l exigence 6.6 est sans doute le meilleur choix. Défendre contre les menaces qui ciblent le WAF lui-même. Soutenir SSL et/ou la terminaison TLS, ou être positionné de telle manière que les transmissions cryptées soient décryptées avant d être examinées par le WAF. Les flux de données cryptés ne peuvent pas être examinés à moins que le protocole SSL soit arrêté avant le moteur d examen. 6 Capacités recommandées supplémentaires pour certains environnements Prévenir et/ou détecter l altération de jeton de session, par exemple en cryptant les témoins de session, les champs de formulaires cachés ou autres éléments de données utilisés pour l état d entretien de la session. Automatiquement recevoir et appliquer des mises à jour de signatures dynamiques d un fournisseur ou d une autre source. En l absence de cette capacité, il devrait y avoir des procédures en place pour garantir des mises à jour fréquentes des signatures WAF ou d autres paramètres de configuration.

6 S ouvrir en cas d échec (un dispositif qui a échoué permet au trafic de passer sans être examiné) ou se fermer en cas d échec (un dispositif qui a échoué bloque tout trafic), selon la politique en vigueur. Remarque : permettre qu un WAF s ouvre en cas d échec doit être attentivement examiné quant aux risques d exposition des applications Web à l Internet public. Un mode de contournement, dans lequel absolument aucune modification n est faite au trafic y passant, peut être applicable dans certaines circonstances. (Même en mode «ouvert en cas d échec», certains WAF ajoutent des en-têtes de suivi, nettoient les éléments HTML qui selon eux transgressent les normes, ou effectuent d autres actions. Cela peut avoir un impact négatif sur les tentatives de dépannage.) Dans certains environnements, le WAF devrait soutenir les certificats de clients SSL et l authentification de clients de mandatement par des certificats. De nombreuses applications Web modernes utilisent des certificats de clients SSL pour identifier les utilisateurs finaux. Sans ce soutien, ces applications ne peuvent pas demeurer derrière un pare-feu d application Web. De nombreux pare-feu d applications Web modernes s intègrent avec le protocole LDAP ou d autres répertoires d utilisateurs, et peuvent même effectuer une authentification initiale de la part de l application sous-jacente. Certaines applications de commerce électronique exigent un soutien de stockage de clé de matériel informatique FIPS. S il s agit d une possibilité dans votre environnement, assurez-vous que le fournisseur WAF soutient cette exigence dans l un de ses systèmes et est au courant que cette fonctionnalité peut radicalement augmenter les coûts de la solution. Considérations supplémentaires Bien que les WAF peuvent protéger contre de nombreuses menaces de sécurité, ils peuvent aussi révéler des problèmes techniques au sein d une infrastructure. Soyez certains de rester attentifs aux problèmes suivants qui peuvent entraver un déploiement réussi : Les sites qui dépendent d en-têtes, d URL et de témoins inhabituels peuvent nécessiter un réglage particulier. Les WAF appliquent souvent des tailles maximales pour ces composants. De plus, les signatures qu ils cherchent peuvent exclure des chaînes considérées comme des «abus» qui peuvent en fait être parfaitement valides pour une application particulière. Le contenu non conforme aux RFC HTML/HTTP ou qui est autrement «inhabituel» peut aussi être bloqué si les filtres par défaut n ont pas été réglés. Cela peut comprendre tout un éventail de choses, des téléchargements de fichiers trop importants au contenu transmis en caractères ou langues étrangères. 7 Le DHTML, le JavaScript asynchrone et le XML (AJAX), ainsi que d autres technologies dynamiques, peuvent nécessiter des considérations, des tests et des réglages particuliers. Ces applications supposent parfois qu elles ont accès au site Web d une manière qui est perçue par un WAF comme étant malveillante. Les applications qui exigent des renseignements à propos de la session de réseau sousjacente, tels que l adresse IP du client peuvent nécessiter des modifications si le WAF agit en tant que mandataire inverse. En principe, ces WAF mettront des renseignements côté du client dans un en-tête

7 HTTP, ce à quoi les applications existantes peuvent ne pas s attendre. Considérations importantes Les évaluations de vulnérabilités d applications décrites dans ce document doivent être effectuées avant d implémenter l application en production. Si un WAF «échec ouvert» ou «mode de contournement» est considéré, des procédures et des critères particuliers définissant l utilisation de ces modes à risques plus élevés doivent être établis avant l implémentation. Les applications Web ne sont pas protégées tant que ces modes sont actifs, et de longues périodes d utilisation ne sont pas recommandées. L impact de modifications de pare-feu d applications Web doit être évalué quant à un impact possible sur les applications Web applicables, et vice-versa. Faites part du temps impliqué et de l étendue de production des modifications de pare-feu d applications Web à toutes les parties concernées dans toute la société. Adhérer à toutes les politiques et procédures, y compris le contrôle des changements, la continuité des affaires et la reprise sur sinistre. Les changements de l environnement de production doivent avoir lieu pendant une fenêtre d entretien surveillée. Sources de renseignements supplémentaires Cette liste est fournie comme point de départ pour obtenir plus de renseignements sur la sécurité des applications Web. Top 10 de l OWASP Référence de contremesures de l OWASP FAQ sur la sécurité des applications de l OWASP Build Security In (Département de sécurité du foyer national, Division nationale de cybersécurité) Scanneurs de vulnérabilités des applications Web (Institut national des normes et de la technologie) Critères d évaluation de pare-feu des applications Web (Consortium de sécurité des applications Web) 8 À propos du Conseil des normes de sécurité PCI La mission du Conseil des normes de sécurité PCI est d améliorer la sécurité des comptes de paiement en favorisant l éducation et la connaissance des normes de sécurité des données PCI et autres normes qui améliorent la sécurité des données de paiement. Le Conseil des normes de sécurité PCI a été fondé par les principales marques de cartes de paiement : American Express, Discover Financial Services, JCB International, MasterCard Worldwide, et Visa Inc. pour fournir un forum transparent dans lequel toutes les parties prenantes peuvent contribuer au développement, à l amélioration et la dissémination actuels des normes de sécurité des données (Data Security Standard, DSS), des exigences des dispositifs de saisie du NIP (Pin-Entry Device, PED), et les normes de sécurité des données des applications de paiement (Payment Application Data Security Standard, PA-DSS). Les commerçants, banques, processeurs, et fournisseurs de points de vente sont encouragés à s inscrire en tant que Sociétés participantes.