Rational France - Livre blanc - Construire la conformité de l’intérieur

Livre blanc Thought Leadership

Compagnie IBM France Rational

Construire la conformité de l’intérieurRespecter les nouvelles exigences de sécurité des applications PCI :

2 Building compliance in

« La sécurité des données de paiement des clients n’est pas seulement un problème des marques de paiement mais est également de la responsabilité de toutes les sociétés qui participent au processus de paiement. Les marques de paiement exigent de tous les marchands et fournisseurs de service qui stockent, traitent et transmettent des données de carte de paiement de respecter les Normes de sécurité des données de l’industrie des cartes de paiement – leurs clients comptent dessus et leurs réputations en dépendent. »

— PCI Security Standards Council1

Building compliance in 3

Depuis 2005, plus de 215 millions d’enregistrements de données ont été exposés aux conséquences de failles de sécurité.2

Des tollés dans la presse, des assemblées législatives mondiales et entre autres les clients ont amené les groupes industriels à travailler vers des réglementations et des bonnes pratiques dans le domaine la sécurité des données privées.

Le Payment Cards Industry (PCI) Security Standards Council a ouvert la voie en émettant les Normes de sécurité des données de l’industrie des cartes de paiement (PCI DSS) pour établir des exigences spécifiques pour la sécurité des comptes bancaires. A l’origine établi par les principales sociétés de cartes de crédit, le Conseil fournit un mécanisme pour le développement des normes de sécurité, des directives pour la mise en œuvre des normes et un programme de mise en conformité. Avec la publication des PCI DSS, les marchands utilisant les données bancaires sur le marché mondial disposent maintenant d’une feuille de route plus claire pour mettre en

place les contrôles adaptés et démontrer leur vigilance dans la manipulation des données des cartes de crédit de leurs clients. Par ces PCI DSS, il est demandé aux vendeurs de :

• Créer et maintenir un réseau sécurisé: – Exigence 1 : Installer et paramétrer des pare-feux pour protéger les données des titulaires de carte

– Exigence 2 : Ne pas utiliser les valeurs par défaut des fournisseurs pour les mots de passe système et autres

– Paramètres de sécurité• Protéger les données des titulaires de carte:

– Exigence 3 : Protéger les données stockées des titulaires de carte

– Exigence 4 : Crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts

• Maintenir un programme de gestion de la vulnérabilité: – Exigence 5 : Utiliser et mettre à jour régulièrement des logiciels anti-virus

– Exigence 6 : Développer et maintenir des systèmes et des applications sécurisés

• Mettre en œuvre des mesures strictes de contrôle des accès: – Exigence 7 : Restreindre l’accès aux données des titulaires de carte à des fins de « consultation primordiale »

– Exigence 8 : Attribuer un identifiant unique à chaque personne possédant un accès informatique

– Exigence 9 : Restreindre l’accès physique aux données des titulaires de carte

• Surveiller et tester régulièrement les réseaux: – Exigence 10 : Surveiller tous les accès aux ressources réseau et aux données des titulaires de carte

– Exigence 11 : Tester régulièrement la sécurité des systèmes et des processus

• Appliquer une politique de sécurité des informations: – Exigence 12 : Mettre en œuvre une politique de sécurité des informations3

Seuls 39 pourcents des européens respect-ent actuellement les normes de la PCI, contre 63 pourcents aux Etats-Unis. — Jericho Forum9


Chacune de ces normes globales possède un ensemble d’exigences spécifiques qui leurs sont associées et des directives sont fournies par le Security Standards Council pour aider les organisations à mettre en œuvre et à préparer leur mise en conformité.

Faibles taux de conformitéDe récentes études des marchands ont clairement montré que la conformité aux exigences des normes de la PCI est en retard malgré certains investissements significatifs. Visa USA, la seule marque de carte à nous transmettre leurs statistiques de conformité jusqu’à présent, a déclaré que les taux de confor-mité ne sont que de 36 pourcents parmi ses marchands de niveau un (ceux qui traitent plus de six millions de transactions par carte par an) et de 15 pourcents parmi ses marchands de niveau deux (ceux qui traitent entre un million et six millions de transactions par an). 4

Cependant, la plupart des compagnies interrogées par Forrester Research s’attendent à répondre aux exigences pour le milieu de l’année 2008.5

Les plus importants défis pour répondre aux exigences cités par Forrester incluent :

• Construire la sécurité de l’intérieur : Faire de la sécurité une partie intégrante du processus quotidien à travers l’organisation, dans les politiques et les processus

• Auditer et rapporter : Prouver la conformité peut être aussi difficile que l’atteindre

• Garantir la sécurité des partenaires : Obtenir la connaissance de la sécurité de ceux avec qui nous partageons les données6

Dans le développement d’applications personnalisées en particulier, les organisations luttent pour l’intégration de la sécurité dans chaque phase du cycle de développement et pour la production de rapports d’audit qui démontrent le degré de conformité à la PCI à la fois dans les systèmes internes et externes. Relever ces défis demandera une combinaison du bon processus, des bonnes compétences et des bons outils. Il est vital que les organisations soumises aux exigences de la PCI commencent à suivre cette initiative immédiatement. « La hausse rapide des menaces ciblées fait de l’augmentation de la sécurité des applications une chose sur laquelle les entreprises doivent se concentrer aujourd’hui. »7 déclare John Pescatore de Gartner.

Pour les sociétés développant leur propre logiciel, l’approche la plus efficace est d’intégrer des scanners de vulnérabilité du code source dans le développement, l’intégration et les tests de l’application. — Gartner Research16


Impact mondial de la PCILa pression sur les organisations pour se conformer aux normes de la PCI est ressentie partout dans le monde car les marchés et les transactions mondiaux prédominent et l’impact des failles de sécurité concernant les données dépasse les frontières nationales. Les marques de carte sont des entités mondiales et réalisent donc un déploiement mondial de la conformité aux normes de la PCI et des schémas de mise en œuvre. American Express, par exemple, prévoit de terminer son déploiement mondial en 2008, selon Gartner.8

Cette pression est ressentie par les dirigeants partout dans le monde. Une étude récente auprès des professionnels de la sécurité européens effectuée par Qualys et le Jericho Forum a montré que 74 pourcents des directeurs de la sécurité senior européens voient l’impact d’une perte de carte de paiement sur la réputation de la marque comme leur plus grosse préoccu-pation. La même étude a montré que les européens ont besoin de rattraper leur retard sur les sociétés des Etats-Unis dans le domaine de mise en conformité PCI. Seuls 39 pourcents des européens respectent actuellement les normes de la PCI, contre 63 pourcents aux Etats-Unis.9

Alors que les activités d’application des normes sont en retard hors de l’Amérique du Nord, les sociétés de cartes tournent clairement leur regard sur les marchés mondiaux en 2008 ; la législation, pays par pays, suivra probablement le modèle défini aux Etats-Unis et au Canada, rendant la divulgation obligatoire en cas de faille. Les propositions de divulgation des failles de sécurité étudiées par la communauté européenne incluent une exigence de notification des régulateurs quand une faille de sécurité est découverte.10

Conformité aux normes de la PCI : Ce n’est plus que pour les sociétés de carte de créditLes PCI DSS deviennent manifestement de fait une norme de vigilance pour toute organisation responsable de la confidentialité et de l’intégrité de données. En conséquence, les législateurs des états et fédéraux incorporent des normes similaires dans le développement des lois de confidentialité des données. La première étape pour de nombreux états a été d’exiger la divulgation en cas de faille, que ce soit un accès à des données ou une exposition potentiels, ou en cas d’exposition matérielle. La figure 1 indique la prépondérance des états disposant d’une sorte de réglementation se rapportant à la divulgation des failles.


Le risque de vol d’identité en fonction des états Depuis 2005, plus de 200 cas d’exposition d’enregistrements d’identification privée ont été remontés. A ce jour, 32 états ont émis des lois exigeant que les entreprises et dans certains cas les agences publiques signalent à leurs clients qu’ils ont été exposés à des risques de vol d’identité. Cas individuels de failles de sécurité par emplacement et nombre d’enregistrements personnels exposés Jusqu’à 50 000 personnes affectées Entre 50 000 et 250 000 Entre 250 000 et 500 000 Entre 500 000 et 2 000 000 Plus de 2 000 000 de personnes affectées Réponses des états Etats sans loi de notification de faille Etats avec lois de notification de faille s’appliquant à toute agence ou société Etats avec lois de notification de faille ne s’appliquant pas aux agences publiques Figure 1 : Lois de divulgation de faille état par état

Une législation sur les normes concernant la sécurité des données basée sur le modèle des normes de la PCI et de l’OWASP est également en développement, ainsi que des pénalités pour non-conformité et des récompenses pour conformité. Un exemple est l’état du Texas qui réfléchit à un projet de loi qui fournira une protection aux organisations qui prouvent la conformité vis-à-vis des PCI DSS et établira la responsabilité des frais de renouvellement des cartes à celles qui ne sont pas conformes.11

Les organisations en dehors des services financiers et commerce ressentent une pression accrue de la part des législateurs, des

actionnaires, de la presse et des clients pour prendre des mesures concrètes afin de protéger les données critiques de la fraude ou de la corruption. Les années à venir continueront probablement à voir la mise en place de normes de vigilance dans la confidentialité des données acceptées par tous.

La plupart des sociétés ont en place des équipements de sécurité assez complets, utilisant des firewalls, des VPN, des contrôles d’accès et du cryptage pour protéger leurs actifs de valeur. Les PCI DSS, cependant, regardent la sécurité de façon plus intégrée, comprenant que c’est uniquement grâce à un modèle de sécurité de défense en profondeur que les données peuvent être les plus en sécurité. Avec cette vue à l’esprit, la PCI est la première réglementation à exprimer le besoin d’une rigueur en terme de sécurité autour des applications elles-mêmes.

Applications : Une source potentielle de sécuritéL’attention accrue sur la sécurité des applications dans les dernières révisions des PCI DSS peuvent être reliées directement à de nombreuses failles médiatisées récentes, où les applications peu sûres ont montré qu’elles étaient le point d’accès de pirates et la source de pertes de données. Un article d’Information Week met en évidence la menace provenant des problèmes logiciels, montrant que « le flot constant de révélations de pertes ou de vols d’informations de clients par les détaillants a amené les experts de la sécurité à se concentrer sur deux domaines : les médiocres pratiques de sécurité par les détaillants eux-mêmes et la faiblesse du logiciel utilisé pour traiter les paiements par carte de crédit. »12

L’article rapporte que Polo Ralph Lauren Corp. a accusé un pépin logiciel d’une faille de sécurité qui a amené la HSBC


Amérique du Nord à notifier les détenteurs de leur Master-Card marquée General Motors que leurs informations per-sonnelles pouvaient avoir été volées.13

BJ’s Wholesale Club, dans un autre incident médiatisé, a été impliqué contre IBM, imputant à un logiciel défectueux fourni par la société une faille ayant exposé 40 millions de numéros de cartes de crédit ainsi que des dépenses de plus 13 millions de $US.14

Ces incidents, parmi d’autres, tracent une ligne directe entre le Conseil de la PCI directement vers les exigences relatives à la sécurité étendue des applications contenus dans la Version 1.1 des Normes de sécurité des données.

Concentration sur la sécurité des applica-tions : Exigence sixLa sécurité des applications représente un des domaines les plus difficiles pour les organisations soumises aux régle-mentations de la PCI. La plus récente version des PCI DSS, publiée en septembre 2006, reflète la compréhension gran-dissante de l’industrie en ce qui concerne l’impact des appli-cations non sécurisées sur la vie privée. L’ajout le plus signifi-catif aux Normes est l’intégration d’un nouveau mandat pour la sécurité des applications personnalisées codifiées dans l’Exigence 6 : Développer et maintenir la sécurité des systèmes et des applications. En particulier, l’Exigence 6.6 expose que le code de toutes les applications personnalisées doit être revu pour rechercher les vulnérabilités classiques par une organi-sation spécialisée dans la sécurité des applications ou qu’un firewall web applicatif doit être installé devant les applications exposées au web. Cette exigence sera considérée comme une « bonne pratique » jusqu’au 30 juin 2008 et deviendra ensuite une exigence.15

Cette exigence, associée aux autres exigences détaillées de la section, fait de la sécurité des applications une pierre angulaire des efforts de conformité à la PCI et le moyen de protéger les données des titulaires de cartes. Il est clairement reconnu qu’une vraie sécurité des données doit débuter à la source.

La conformité débute à la source Ces nouvelles exigences reconnaissent clairement que la sécurité des données débute par la sécurité du logiciel. C’est dans le code source que le cryptage est forcé, que la sécurité des communications réseau est établie, que le contrôle d’accès est défini. Ou non. Par conséquent, c’est dans le code source que les travaux de conformité avec les PCI DSS, ainsi que les efforts de sécurisation des données privées des titulaires de cartes, doivent débuter. Alors que les PCI DSS incluent l’analyse des applications web et les firewalls web comme faisant partie de la solution potentielle mise en place pour traiter ces problèmes, il est clair que les outils d’analyse du code source représentent la solution la plus efficace, rentable et complète pour identifier et traiter les vulnérabilités logicielles qui affectent la confidentialité des données. Comme les analystes de Gartner John Pescatore et Avivah Litan ont déclaré dans un récent rapport, « Pour les sociétés développant leur propre logiciel, l’approche la plus efficace est d’intégrer des scanners de vulnérabilité du code source dans le développement, l’intégration et les tests de l’application. »16

Construire la conformité à la PCI de l’intérieurL’attention assidue croissante sur la sécurité du code source provient du fait qu’il s’agit de l’emplacement central où les vulnérabilités concernant les données de cartes de crédit sont introduites. Cela peut également être l’endroit le moins


coûteux pour les traiter, car l’analyse du code source est effectuée au plus tôt dans le cycle de développement du logiciel. Pour les organisations soumises à la conformité à la PCI, cela constitue un sens à la fois fiscal et de gestion d’introduire une analyse du code source dans le cycle de développement pour le code personnalisé et externalisé. En laisser l’entière responsabilité à une organisation externe réduit l’avantage financier d’une découverte précoce des vulnér-*abilités et augmente la probabilité de retard et de risques pour le projet.

Les solutions d’analyse de code source de pointe utilisent une base de connaissance de vulnérabilité considérable alimentée par un moteur d’analyse capable d’analyser efficacement de grandes quantités de code source. La base de connaissance doit inclure non seulement les erreurs de codage classiques qui ouvrent les portes aux pirates, mais également l’identification des erreurs de conception et de politique qui exposent les données personnelles au plus grand danger.

Pour se conformer réellement aux exigences de la PCI, ainsi que pour se protéger totalement du risque de sécurité logiciel pour les informations de cartes de crédit, le scanner de code source doit rechercher les erreurs de codage ainsi que les violations de politiques et les défauts de conception.

Les outils IBM Rational® AppScan® Source Edition, par exemple, couvrent les deux types de problèmes et leur analyse inclut :

• Les vulnérabilités de codage: – Débordement de tampon – Vulnérabilités de formatage de chaînes de caractères – Situations de compétition – Fuite de ressource

– Validation des entrées/sorties et erreurs d’encodage:

˚ Injection SQL

˚ Cross-site scripting

˚ Injection système• Les défauts de conception et violations de politiques:

– Cryptographie – Vulnérabilités de communication réseau – Vulnérabilités de configuration de l’application – Contrôle d’accès – Utilisation de base de données et de système de fichiers – Code dynamique – Contrôle d’accès et erreurs d’authentification – Vulnérabilités de gestion des erreurs et de connexion:

˚ Gestion des erreurs non sécurisée

˚ Identification non sécurisée ou inadéquate

˚ Chargement de code natif

˚ Vulnérabilité de stockage de données – Composants non sécurisés:

˚ Programme malveillant

˚ Méthodes natives risquées

˚ Méthodes non supportées

˚ Cookies personnalisés / champs cachés

Quand le code source rencontre la confor-mité à la PCIComme toujours, le démon est dans les détails. Il existe plusieurs réglementations dans les PCI DSS impactées par la sécurité du code source. Il est vital que les organisations comprennent l’intersection entre le code source et chaque réglementation des applications pour garantir que la revue de conformité est complète. Cette section fournit une revue des réglementations de sécurité des applications applicables pour la PCI et la manière dont l’analyse du code source peut prendre en charge la mise en conformité.


Exigence trois : Protéger les données stock-ées des titulaires de carteIl n’existe pas d’exigence plus critique que le besoin de pro-téger les données des titulaires de carte au niveau de l’enregis-trement. Les applications jouent un rôle critique dans cette tache, particulièrement par l’implémentation correcte de contrôles d’accès et d’une cryptographie appropriés. La conformité avec cette exigence ne peut pas être assurée si les applications traitant et enregistrant les données n’ont pas été complètement revues.

Exigence six : Développer et maintenir des systèmes et des applications sécurisésCette exigence est la réglementation principale traitant du besoin de valider la sécurité des applications sensibles. Elle s’adresse directement au fondement des applications sécurisées : l’introduction de processus de sécurité et de revues tout au long du cycle de développement du logiciel. Planification, conception, développement et déploiement : toutes les étapes du cycle de vie doivent faire des considérations de sécurité une priorité principale pour rendre possible et démontrable la mise en conformité.

Exigence de la PCI Actions d’analyse de code source pour mise en conformité

3.2 Ne pas stocker de données d’authentification sensibles ultérieures à l’autorisation. 3.3 Masquer le Numéro de compte primaire (Primary Account Number, PAN) quand il est affiché. 3.4 Rendre au minimum le PAN illisible partout où il est enregistré. Utiliser des types de cryptage appropriés.

6.2 Etablir un processus d’identification des vulnérabilités de sécurité nouvellement découvertes. 6.3 Développer des applications logicielles à partir des bonnes pratiques de l’industrie et assurer la sécurité des informations tout au long du cycle de développement du logiciel. 6.4.1Documentation des impacts. 6.5 Développer toutes les applications web à partir des directives de codage sécurisées telles que les directives Open Web Application Security Project (OWASP). Revoir le code des applications personnalisées pour découvrir des vulnérabilités de codage. 6.6 S’assurer que toutes les applications exposées au web sont protégées contre les attaques connues.

• Identifier les pratiques de stockage de données des titulaires de cartes potentiellement vulnérables ou non conformes.

• Contrôler l’absence de pratiques de stockage de données des titulaires de cartes non sécurisées.

• Identifier tous les points de stockage du PAN et vérifier la cryptographie et la force cryptographique utilisées.

• Contrôler l’affichage et le masquage du PAN.• Fournir le support technologique pour permettre une évaluation cohérente et

mesurable du niveau de sécurité du code source, tout au long de la phase de développement:

– Base de connaissance de sécurité complète – Mesures précises – Interfaces et reporting basés sur les rôles et fournissant les informations

nécessaires de conformité à la PCI à tous les participants – Reporting en profondeur pour audit

• Produire des rapports spécifiques à la PCI pour fournir les données de gestion et les données techniques requises par les normes de la PCI:

– Reporting spécifique sur les impacts du code source sur les pertes de données – Reporting sur la conformité au Top Ten OWASP – Analyser l’historique pour démontrer les efforts de mise en conformité au fil

du temps – Reporting à la fois en résumé et en détail pour prendre en charge les corrections de

vulnérabilité spécifiques, les prises de décision de gestion et les exigences de reporting pour la mise en conformité


Prouver la conformitéDans toutes les exigences citées précédemment, le besoin de documenter les activités de mise en conformité est à la fois implicite et explicite. La documentation est nécessaire non seulement pour suivre les résultats, mais aussi pour prouver qu’un processus est en place, en démontrant la vigilance dans l’effort de mise en conformité et de protection des données. L’adage « vous ne pouvez pas gérer ce que vous ne pouvez pas mesurer » est particulièrement vrai dans le domaine de la sécurité des applications. La pierre angulaire de toute implé-mentation d’analyse du code source doit donc être la capacité à produire des rapports spécifiques et détaillés des résultats des analyses et de toutes les activités de correction qui en décou-lent. Chaque composant du processus de mise en conformité, des responsables aux développeurs, à la qualité et aux respon-sables de la mise en conformité, doit être capable d’en ressortir es données dont ils ont besoin pour jouer leur rôle dans le processus.

Analyse du code : Le fondement de la mise en conformité L’analyse du code source est la base d’une gamme d’options potentielles disponibles pour les organisations afin de gérer leur sécurité et le degré de conformité de leurs applications. Gartner reconnaît que l’analyse du code source est l’approche la plus efficace, comme cité précédemment. Mais la société de recherche continue d’affirmer que quand ce n’est « pas possible, les entreprises disposant d’une équipe de sécurité et de l’expertise suffisantes peuvent utiliser les produits d’analyse des applications web… pendant les tests terminaux d’assurance qualité du logiciel. »17

Il existe de nombreux avantages à l’analyse du code source, ce qui en fait le tout meilleur choix pour les organisations soucieuses de respecter les normes de vigilance en utilisant la

méthode la plus efficace et la plus rentable possible. Les avantages de l’analyse du code source en supplément des tests d’intrusion pour les applications personnalisées incluent :

Des coûts de correction faibles : Les tests d’intrusion ne peuvent pas être déployés tant que l’application n’est pas terminée. L’analyse du code source peut être utilisée le plus tôt possible dans la phase de Build du cycle de développement, réduisant considérablement le coût de correction des vulnér-abilités. Des études ont montré que corriger une vulnérabilité après la fin du développement peut coûter 100 fois plus que pendant la phase de développement.

Une couverture complète des risques de sécurité : Les tests d’intrusion couvrent un ensemble plus restreint des risques logiciels, en se concentrant sur les erreurs de codage sans être capables d’identifier les risques plus dangereux découlant des erreurs de conception et des violations de politiques. Ceux-ci peuvent inclure des menaces sur les données personnelles telles que l’absence de cryptage, l’utilisation de mots de passe codés en dur, l’utilisation inappropriée de l’e-mail ou l’enregistre-ment non sécurisé des données privées. Les scanners de code source sophistiqués peuvent fournir une couverture de cette plus large gamme de vulnérabilités pour détecter à la source les menaces sur la confidentialité et l’intégrité des données.

Une identification des vulnérabilités ligne par ligne : La connaissance de l’existence d’une vulnérabilité n’est pas suffisante. Les développeurs doivent savoir où aller dans le code pour corriger la vulnérabilité, et seule une analyse du code source peut fournir ce niveau de détail et de connaissance.

Une analyse de l’infrastructure logicielle dans son ensemble : Les tests d’intrusion sont conçus pour fonctionner exclusive-ment sur des applications web. Souvent, les menaces critiques sur les


données proviennent d’une application middleware ou back-end, hors d’atteinte du scanner d’application web. Seule une analyse du code source dans les systèmes interdépendants peut fournir une vue réellement complète des risques sur les données critiques.

Les PCI DSS permettent également l’utilisation de firewalls web applicatifs déployés devant les applications qui n’ont pas été testées. Ces produits peuvent être efficaces pour bloquer de nombreuses attaques contre les applications web classiques, mais ils nécessitent un réglage important et un support d’administration. Gartner recommande que « les entreprises utilisent des firewalls web applicatifs en dernier recours ou, quand le budget le permet, en tant que précaution de sécurité supplémentaire. »18

Même si les tests d’intrusion et les firewalls web applicatifs peuvent tous deux être des outils utiles juste avant ou après le déploiement, c’est l’analyse du code source qui représente la technologie de base la plus efficace et complète pour identifier et éliminer les vulnérabilités qui menacent la confidentialité des données et la conformité aux réglementations.

Conformité à la PCI et Rational AppScan Source EditionRational AppScan Source Edition a été l’une des solutions d’analyse de code source de pointe à fournir des fonctionnalités spécifiques à la PCI dans ses outils. Le produit utilise une « lentille » spécifique à la PCI pour voir les résultats de l’analyse du code source concernant les réglementations spécifiques à la PCI, y compris l’audit de conformité avec le Top Ten OWASP. Avec le rapport « SmartAudit » PCI d’IBM, les clients peuvent automatiser l’évaluation du degré de vulnérabilité de leurs applications critiques. La solution Rational AppScan Source

Edition a été conçue « from scratch » pour apporter à vos directeurs, analystes, développeurs et auditeurs les réponses dont ils ont besoin pour gérer les risques des logiciels vulnérables :

• Identifier rapidement les plus sérieux risques de sécurité : Les fonctionnalités uniques d’analyse de Rational AppScan Source Edition identifient les erreurs de codage et les défauts de conception les plus critiques.

• Optimiser l’efficacité de vos participants à la sécurité : Les meilleurs délais avant résultat rationalisent les efforts de sécurité tout au long du cycle de vie du développement logiciel, pour tous les participants.

• Gérer les risques dans tout votre portefeuille d’entreprise : Les tableaux de bord centralisés et les fonctionnalités de gestion de politiques permettent de disposer d’informations instantanées de vos risques logiciels, ceci dans l’ensemble de l’entreprise.

Avec une solution telle que Rational AppScan Source Edition, les organisations financières peuvent suivre une approche réellement systématique et mesurable de la mise en conformité avec la PCI en analysant les vulnérabilités des logiciels criti-ques tout au long du cycle de développement, en évaluant le travail des développeurs externes et en fournissant les résultats des efforts de mise en conformité aux dirigeants et aux régulateurs.

Pour plus d’informationsPour en savoir plus sur IBM Rational AppScan Source Edition, contactez votre représentant IBM ou visitez le site :ibm.com/rational/products/appscan/source

Please Recycle

© Copyright IBM Corporation 2010

IBM Global Services Route 100 Somers, NY 10589 U.S.A.

Produit aux Etats-Unis d’Amérique Novembre 2010 Tous droits réservés

IBM, le logo IBM et ibm.com sont des marques déposées d’International Business Machines Corporation aux Etats-Unis et/ou dans certains autres pays. Si ces marques et d’autres marques d’IBM sont accompagnées d’un symbole de marque (® ou ™), ces symboles signalent des marques d’IBM aux Etats-Unis à la date de publication de ce document. Ces marques peuvent également exister et éventuellement avoir été enregistrées dans d’autres pays. La liste des marques IBM actualisée est disponible sur Internet, dans la rubrique consacrée au copyright et aux marques du site ibm.com/legal/copytrade.shtml.

Les autres noms de société, de produit et de service peuvent appartenir à des tiers.

Dans cette publication, les références à des produits et des services IBM n’impliquent pas qu’IBM prévoie de les commercialiser dans tous les pays où IBM est implantée.

1 PCI Security Standards Council, Communiqué de presse, 18 janvier 2007.2 Privacy Rights Clearinghouse, www.privacyrights.org, 7 novembre 2007.3 Payment Card Industry Data Security Standard version 1.1, PCI Security Standards

Council, septembre 2006.4 «Visa USA Pledges $20 Million in Incentives to Protect Cardholder Data »,

Communiqué de presse Visa, 12 décembre 2006.5 Khalid Kark et Chris McClean, « The Top 10 Things You Should Know About PCI

Compliance, » Forrester Research, 23 mars 2007.6 Ibid.7 John Pescatore et Avivah Litan, « Answers to Common Questions about PCI

Compliance, » Gartner Research, 7 décembre 2006.8 John Pescatore et Avivah Litan, « PCI Questions are Often Clearer than their

Answers, » Gartner, 7 août 2007.9 Jericho Forum et Qualys, « 74% of Security Executives Concerned About Impact of

Payment Card Data Loss, » communiqué de presse, 26 avril 2007.10 Tom Espiner, « Encryption Market is Taking Off, » zdnet.co.uk, 29 septembre 2006.11 James DeLuccia IV, pcidss.wordpress.com, « Payment Card Security and IT Controls

Explained, » blog, 11 mai 2007, http://pcidss.wordpress.com/category/pci-dss/.12 Steven Marlin, « Customer Data Losses Blamed On Merchants And Software, »

InformationWeek, 28 avril 2005.13 Ibid.14 Shawna McAlearney, « BJ’s Settlement with FTC Bodes Ill for Others, » searchsecu-

rity.com juin 2005.15 Colleen Frye, «PCI Council Formed; Revised Standard Includes App Security

Requirement », searchsoftwarequality.com, 8 septembre 2006.16 John Pescatore et Avivah Litan, « Answers to Common Questions about PCI

Compliance, » Gartner Research, 7 décembre 2006.17 Ibid.18 Ibid.

WGW03001-USEN-00

Rational France - Livre blanc - Construire la conformité de l’intérieur

Documents

Transcript of Rational France - Livre blanc - Construire la conformité de l’intérieur