6
èmeexigence : développer et gérer des applications et ses systèmes sécurisés
Il arrive que des individus peu scrupuleux utilisent les vulnérabilités en matière de sécurité pour accéder aux systèmes. Il est remédié à nombre de ces vulnérabilités par des correctifs de sécurité mises à disposition par le fournisseur. Tous les systèmes doivent être équipés des corrections d’erreur de logiciel appropriées les plus récentes, afin de les protéger des intrusions d'employés ou de pirates informatiques, ainsi que contre les virus. Remarque : les correctifs appropriés sont ceux qui ont été suffisamment évalués et testées pour déterminer qu'ils n’entrent pas en conflit avec les configurations de sécurité en place. En ce qui concerne les applications développées en interne, de nombreuses vulnérabilités peuvent être évitées par des processus de développement de système standard, ainsi que par des techniques de codage sécurisées.
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN
PLACE
DATE CIBLE/
COMMENTAIRES 6.1 S'assurer que toutes les
composantes de système et tous les logiciels du système disposent des correctifs de sécurité les plus récents mis à disposition par le fournisseur.
Installer les correctifs de sécurité dans un délai d’un mois suivant leur publication.
6.1.a Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, ainsi que des logiciels liés, comparer la liste des correctifs de sécurité installés sur chaque système à la plus récente liste des correctifs de sécurité du fournisseur, afin de vérifier que les correctifs existants du fournisseur sont bien installés.
6.1.b Étudier les politiques liées à l’installation de correctifs de sécurité, afin de vérifier qu’ils exigent l’installation de tous nouveaux correctifs d’erreurs pertinents dans le domaine de la sécurité dans un délai de 30 jours.
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN PLACE
DATE CIBLE/
COMMENTAIRES 6.2 Mettre en place un processus
destiné à identifier les vulnérabilités en matière de sécurité nouvellement identifiées (par exemple, souscrire un abonnement à des services d’alerte gratuit disponibles sur l'Internet).
Mettre les normes à jour afin de faire face aux nouveaux problèmes de vulnérabilité.
6.2.a Interroger des personnels responsables afin de vérifier que des processus sont mis en œuvre dans le but de repérer toutes nouvelles vulnérabilités en matière de sécurité.
6.2.b Vérifier que les processus d’identification de nouvelles vulnérabilités en matière de sécurité incluent l’utilisation de sources externes d’informations relatives aux vulnérabilités dans le domaine de la sécurité, ainsi que pour la mise à jour des normes de configuration examinées dans la 2ème Exigence, alors que de nouveaux problèmes de vulnérabilité sont découverts.
6.3 Développer des applications logicielles sur la base des meilleures pratiques sectorielles et intégrer la sécurité de l’information dans
l’ensemble du cycle de développement de logiciel.
6.3 Obtenir et étudier les processus écrits de
développement de logiciel, afin de vérifier qu’ils sont basés sur des normes sectorielles et que la sécurité est prise en compte tout au long du cycle de vie du produit.
À partir d’un examen des processus écrits de développement de logiciel, des entretiens avec des développeurs de logiciel, ainsi que de l'étude de données pertinentes (documents afférents à la configuration de réseau, données de production et de test, etc.), vérifier ce qui suit :
6.3.1 Tester tous les correctifs de sécurité, ainsi que toutes
modifications de configuration de système ou de logiciel avant déploiement.
6.3.1 que toutes modifications (y compris toutes
corrections d’erreur) sont testées avant d’être déployées au niveau de la production ;
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN PLACE
DATE CIBLE/
COMMENTAIRES 6.3.2 Séparer les environnements
de développement, de test et de production.
6.3.2 que les environnements de test/développement sont distincts de l’environnement de production, et qu’il existe un contrôle d’accès en place pour garantir la séparation ;
6.3.3 Séparation des obligations entre les environnements de développement, de test et de production.
6.3.3 qu'il existe une séparation entre les missions des collaborateurs affectés aux environnements de
développement/test et celles des personnels affectés à l'environnement de production ;
6.3.4 Les données de production (PAN actifs) ne sont pas utilisées aux fins de test ou de développement.
6.3.4 que les données de production (PAN actifs) ne sont pas utilisées aux fins de test ou de développement, ou sont expurgées avant usage ;
6.3.5 Suppression des données et comptes de tests avant que les systèmes de production ne deviennent actifs.
6.3.5 que les données de test et les comptes sont supprimés avant que le système de production ne devienne actif ;
6.3.6 Suppression des comptes d’application, noms d’utilisateur et mots de passe usuels avant que les applications ne deviennent actives ou ne soient mises à la disposition de clients.
6.3.6 que les comptes d’application personnalisés, noms d’utilisateur et/ou mots de passe sont supprimés avant que le système soit mis en production ou mis à la disposition des clients
6.3.7 Examen du code personnalisé avant de mettre à la disposition de la production ou de clients afin d’identifier toute vulnérabilité de cryptage éventuelle.
6.3.7.a Obtenir et étudier toutes politiques, écrites ou autres, pour confirmer que des examens du code sont exigés et doivent être exécutés par des personnes autres que l’auteur alors à l’origine du code
6.3.7.b Vérifier que des examens du code sont réalisés, en liaison avec un nouveau code et après des modifications du code
Remarque : Cette exigence s’applique aux examens de code pour le développement de logiciels personnalisés, dans le cadre du cycle de vie de développement de système (System Development Life Cycle, SDLC) ; ces analyses peuvent être réalisées par des personnels internes. Un code sur mesure pour les applications d’interface Internet sera soumis à des contrôles supplémentaires au 30 juin 2008 – pour de plus amples détails, voir l’exigence 6.6 des normes PCI DSS.
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN PLACE
DATE CIBLE/
COMMENTAIRES 6.4 Se conformer aux procédures
en matière de contrôle des changements pour toutes les
modifications apportées au système et au logiciel. Les procédures doivent inclurent les éléments suivants :
6.4.a Obtenir et examiner les procédures de contrôle du changement de la société liées à la mise en œuvre des correctifs de sécurité et des modifications de logiciel et vérifier que les procédures incluent les points 6.4.1 – 6.4.4 ci-après
6,4.b Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, examiner les trois changements les plus récents/correctifs de sécurité pour chaque composant du système et retracer ces modifications jusqu’aux documents liés dans le domaine du contrôle des changements. Vérifier que, pour chaque changement examiné, les éléments ci-après ont été consignés par écrit, conformément aux procédures de contrôle du changement :
6.4.1 consignation écrite de l’impact ;
6.4.1 Vérifier que la consignation écrite de l’impact sur le client figure dans les documents de contrôle des
changements pour chacune des modifications de l’échantillon.
6.4.2 approbation par signature de la direction par les parties
appropriées ;
6.4.2 Vérifier que l’approbation par la direction, par des parties appropriées, est présente pour chacune des modifications de l’échantillon.
6.4.3 vérification de la fonctionnalité opérationnelle ;
6.4.3 Vérifier que des tests de fonctionnalité opérationnelle ont été réalisés pour chacune des modifications de
l’échantillon.
6.4.4 procédures de sauvegarde. 6.4.4 Vérifier que des procédures de sauvegarde sont prêtes pour chacune des modifications de l’échantillon.
6.5 Développer toutes les applications Internet sur la base de principes directeurs en matière de codage sécurisé, tels que ceux de l'Open Web Application Security Project (OWASP). Étudier un code d’application personnalisé, afin d’identifier les vulnérabilités en matière de codage. Prévenir les vulnérabilités de codage courantes dans les processus de développement de logiciel, afin d’inclure les éléments suivants :
6.5.a Obtenir et étudier des processus de développement de logiciel pour toutes applications basées sur Internet. Vérifier que les processus prévoient une formation aux techniques de codage sécurisé pour les développeurs et qu’ils sont fondés sur des recommandations telles que les Principes directeurs de l’OWASP(http://www.owasp.org).
6.5.b En ce qui concerne les applications basées sur Internet, vérifier que des processus sont en place afin de confirmer que les applications Internet ne sont pas exposées aux risques suivants :
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN compromis (par exemple, une utilisation malveillante d’identités d’utilisateur) ;
6.5.2 l'utilisation malveillante d'identités d'utilisateurs ;
6.5.3 une authentification et une gestion de session compromises (l’utilisation d'éléments
d’authentification de compte et les cookies de session) ;
6.5.3 l'utilisation malveillante des éléments d’authentification de compte et cookies de session ;
6.5.4 les attaques par Cross-Site Scripting (XSS ou CSS) ;
6.5.4 les attaques par Cross-Site Scripting ;
6.5.5 les attaques par débordement de tampon ;
6.5.5 les attaques par débordement de tampon imputables à des entrées non validées et à d’autres causes ;
6.5.6 les attaques par injection (par exemple, une injection de
commandes SQL (Structured Query Language)) ;
6.5.6 les injections de commandes SQL et autres attaques par injection de commandes ;
6.5.7 une gestion d’erreur inadéquate ;
6.5.7 la gestion d’erreurs inadéquate ;
6.5.8 un stockage non sécurisé ; 6.5.8 un stockage non sécurisé ; 6.5.9 un refus de service ; 6.5.9 un refus de service ; 6.5.10 une gestion de configuration
non sécurisée.
6.5.10 une gestion de configuration non sécurisée.
6.6 Faire en sorte que toutes les applications d’interface Internet soient protégées contre les attaques connues grâce à l’une ou l’autre des méthodes suivantes :
• faire contrôler par une organisation spécialisée dans la sécurité des applications, tout code d'application personnalisé aux fins de détection des vulnérabilités courantes ;
• Installer un pare-feu de couche
6.6 En ce qui concerne les applications basées sur Internet, s’assurer que l’une ou l’autre des méthodes ci-après est en place :
• vérifier que le code application sur mesure est révisé périodiquement par une organisation spécialisée dans la sécurité des applications ; que toutes les
vulnérabilités en matière de codage ont été corrigées ; et que l’application a fait l’objet d’une nouvelle application après la mise en œuvre des corrections ;
• vérifier qu’il existe un pare-feu de couche application avant les applications d’interface Internet, afin de détecter et de prévenir les attaques basées sur
EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN PLACE
DATE CIBLE/
COMMENTAIRES application qui protège les
applications d’interface Internet.
Remarque : cette méthode est considérée comme une « meilleure pratique » jusqu’au 30 juin 2008, après quoi, elle devient obligatoire.
Internet.