Compagnie IBM France                                                            RationalLivre blanc Thought LeadershipLa s...
2 La sécurité qui compte   Table des matières                                             Synthèse   Synthèse             ...
3 La sécurité qui compteL’environnement réglementaire s’intensifie                           1. Pour garantir la sécurité ...
4 La sécurité qui compte                                                                      Le besoin de certification d...
5 La sécurité qui compte                                                                      Les Accords de Bâle II entra...
6 La sécurité qui compteEn conséquence, les Normes de sécurité des données de                 tition (race conditions), le...
7 La sécurité qui compteLa FFIEC décrit leurs attentes concernant les revues et les tests       Bureau du contrôleur de la...
8 La sécurité qui compteLes résultats de la revue de code peuvent être                                                    ...
9 La sécurité qui compte                                                                       Vigilance constante        ...
10 La sécurité qui compteChaque version de maintenance et de correction de bug peut               •	 Rational AppScan Sour...
11 La sécurité qui compteGrâce à la solution Rational AppScan Source Edition, les               Pour plus d’informationsor...
© Copyright IBM Corporation 2010     Route 100     Somers, NY 10589     U.S.A.     Produit aux Etats-Unis     Décembree 20...
Upcoming SlideShare
Loading in...5
×

Rational France - Livre blanc - La securite qui compte

609

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
609
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Rational France - Livre blanc - La securite qui compte"

  1. 1. Compagnie IBM France RationalLivre blanc Thought LeadershipLa sécurité qui compteNécessité d’un logiciel sécurisé pour les fournisseurs de services financiers
  2. 2. 2 La sécurité qui compte Table des matières Synthèse Synthèse Les établissements de santé se sont toujours donné beaucoup de L’environnement réglementaire s’intensifie mal pour protéger la confidentialité des informations médicales Loi Gramm-Leach-Bliley de leurs patients. Les avancées technologiques ont permis des Loi Sarbanes-Oxley alliances complexes entre les hôpitaux, les agences d’assurance, les chambres de compensation de facturation et les cabinets de Accords de Bâle II médecins pour fonctionner plus efficacement et fournir un Normes de sécurité des données de l’industrie des meilleur soin aux patients. cartes de paiement Se concentrer sur la sécurisation des logiciels L’industrie des services financiers possède les exigences les plus Exigences en termes de sécurité concernant l’externalisation strictes en matière de confidentialité des données et de confor- Le besoin d’analyse des risques logiciels mité à la législation. Non seulement les clients et les partenaires Vigilance constante font confiance à la confidentialité des données critiques, mais Analyse des risques logiciels et IBM Rational AppScan des exigences strictes en termes de sécurité des données impo- Source Edition sées aux institutions financières par divers organismes de L’avantage de Rational AppScan Source Edition réglementation et entreprises multinationales. Sécurité intégrée Pour plus d’informations Les dangers concernant la confidentialité et l’intégrité des don- nées provenant des services financiers étant de plus en plus évidents, les régulateurs du monde entier doivent se concentrer sur ce domaine critique. Ceci a abouti à des réglementations concernant la sécurité des informations d’une plus grande por- tée et plus spécifiques que jamais. Dans ce livre blanc IBM® Rational® AppScan® Source Edition, nous examinerons les diverses exigences réglementaires américaines et internation- ales concernant la protection des informations et la manière avec laquelle toute infrastructure d’informations d’assurance doit inclure une exigence d’assurance de sécurité logicielle, requérant la possibilité d’analyser les failles de sécurité des logiciels cruciaux et de signaler et atténuer ces risques avant qu’ils n’exposent l’organisation à une menace.
  3. 3. 3 La sécurité qui compteL’environnement réglementaire s’intensifie 1. Pour garantir la sécurité et la confidentialité desL’intégrité et la confidentialité des informations financières ont enregistrements et des informations des clients ;longtemps été une préoccupation pour les examinateurs desorganismes financiers depuis que les gouvernements ont res- 2. Pour protéger par anticipation des menaces et des risquessenti pour la première fois le besoin d’une législation de contre la sécurité et l’intégrité de tels enregistrements ; etsurveillance de l’industrie. Alors que la technologie a accru laportée et les capacités des organismes financiers autour du 3. Pour protéger contre les accès non autorisés à de telsmonde, elle a augmenté exponentiellement les risques et enregistrements ou informations ou contre leur utilisationl’exposition des données critiques. Les transmissions électro- qui pourraient résulter en une nuisance ou un inconvénientniques inter banques et intra banques ainsi que l’utilisation substantiel à tout client. »accrue du Web ont augmenté la vitesse, mais ont aussi amenédes vulnérabilités menaçant les données des clients. Ce nouveau Les directives émises par les diverses agences pour mettre enmonde courageux a entraîné des réglementations nouvelles en œuvre la loi nécessitent le développement d’un programme deconstante évolution gouvernant l’assurance et l’intégrité des sécurité de l’information exposant les protections administra-informations. tive, technique et physique adaptées à la taille et à la complexité de l’organisation. Les directives mandatent les institutionsLoi Gramm-Leach-Bliley financières pour « identifier les risques internes et externes rel-La loi Gramm-Leach-Bliley (Gramm-Leach-Bliley Act, GLBA), ativement proches pour la sécurité, la confidentialité et l’intégritésignée le 12 novembre 1999, inclut des fonctionsdestinées à des informations du client qui pourraient résulter de la divulga-« établir des normes pour les institutions financières traitant tion non autorisée, l’utilisation frauduleuse, la modification, lades protections administrative, technique et physique de cer- destruction ou d’autres compromissions de telles informations. » 2taines informations. » 1 Les règles nécessitent que l’évaluation des risques inclut la con-Le cœur de ces fonctions de la loi nécessite que chaque agence sidération du risque posé par chaque domaine concerné par unefédérale concernée, y compris la Federal Trade Commission opération, incluant en particulier « les systèmes d’information,(FTC) et la Securities and Exchange Commission (SEC), « y compris le réseau et la conception logicielle… »3établisse les normes appropriées pour les institutions finan-cières traitant des protections administrative, technique et Ces réglementations codifient le besoin pressant d’assurer laphysique. sécurité des applications qui alimentent les activités de l’industrie des services financiers.
  4. 4. 4 La sécurité qui compte Le besoin de certification des rapports financiers conduit inévi- tablement à une préoccupation concernant la sécurité desLes institutions financières doivent garantir… systèmes dont ces rapports dépendent. « Ceci met vraiment en« la sécurité et la confidentialité des enregistre- évidence l’inadéquation d’un grand nombre de systèmes existants, » déclare Brian Kinman, un partenaire en services dements et des informations des clients. » gestion des risques chez PriceWaterhouse-Coopers. « Les- Loi Gramm-Leach-Bliley sociétés peuvent-elles répondre à ces nouvelles exigences avec les systèmes existants ? Peut-être. Mais ces nouvelles exigences en termes de rapport resserrent fortement les délais et réduisentLoi Sarbanes-Oxley à zéro la tolérance à l’erreur. »5A la suite de scandales comptables aux Etats-Unis, la loi Sarbanes-Oxley a été votée pour mandater de nouvelles normes de divul- Les mandats du SEC mettent la pression pour garantir que lesgation et comptabilité d’entreprise. La loi, tout en resserrant les contrôles de sécurité sont en place, y compris pour les systèmesdélais et instituant des exigences en terme de rapport et de div- internes. « Nous pensons obtenir une déconnexion de la part deulgation plus strictes, demande également aux dirigeants notre directeur informatique, » déclare Randy Kercho,d’entreprises et aux dirigeants financiers de certifier personnel- Président Directeur Général adjoint de Fossil, Inc., selon leslement la précision des rapports financiers de la société. Ces informations de CIO Insight. « Cela sera certainement uneexigences sont mises en œuvre par des règles émises par le SEC. mesure supplémentaire de confort si le directeur informatique vérifiait qu’aucune brèche connue n’est identifiée dans le sys-L’impact de nouvelles règles sur les sociétés informatiques est tème et qu’aucune panne des contrôles n’est identifiée oudevenu de plus en plus clair depuis leur publication. Les infor- modifiée durant le trimestre. »6Les applications qui gèrent lemations financières d’entreprise doivent être complètes, processus de rapport financier doivent être évaluées continuel-disponibles à tout moment et leur intégrité doit être assurée. « lement pour contrôler leur état de sécurité et les vulnérabilitésLe PDG et le directeur financier doivent vérifier l’efficacité des doivent être identifiées et éliminées afin que le directeur infor-contrôles financiers qu’ils utilisent pour que les vérificateurs matique soit assuré de cette intégrité.restent à jour… En conséquence, certaines sociétés prennentsur elles de demander aux autres directeurs - y compris ledirecteur informatique - de se porter garants de l’intégrité dessystèmes de la société. » 4
  5. 5. 5 La sécurité qui compte Les Accords de Bâle II entraînent des implications conséquen- tes sur la stratégie et la mise en œuvre de la stratégie de gestion« Certaines sociétés prennent sur elles de des risques des institutions financières. Même les institutionsdemander aux autres directeurs - y compris le non directement sujettes aux Accords en ressentiront probable- ment l’impact car les exigences s’imposeront inévitablementdirecteur informatique - de se porter garants dans l’environnement réglementaire intérieur. Les Accordsde l’intégrité des systèmes de la société. » tiennent les conseils d’administration et les équipes dirigeantes- CIO Insight responsables du développement d’un environnement de gestion des risques adéquat ainsi que de l’identification, l’évaluation, la surveillance et l’atténuation des risques posés par les produits,Accords de Bâle II activités, processus et systèmes de l’institution.L’intégrité et la sécurité des données confidentielles et des sys-tèmes n’est pas seulement une préoccupation nationale ; c’est Il est évident à partir des exigences des Accords de Bâle II que leune préoccupation mondiale. Cette préoccupation se reflète marché financier mondial comprend le risque en constantedans les Accords de Bâle II, proposés par le Comité de Bâle sur mutation posé par les systèmes et logiciels non sécurisés et lele contrôle bancaire et actuellement sous révision par les gou- besoin urgent d’introduire de nouveaux processus et solutionsvernements et les institutions financières. Par cette structure, pour se protéger du risque d’une manière continue, mesurablel’exposition aux risques de fonctionnement devient un facteur et gérable.important dans le calcul des exigences en capital total pour lesbanques de premier plan et peut donc avoir des conséquences Normes de sécurité des données depréjudiciables sur les gains et la valeur actionnariale. l’industrie des cartes de paiement L’augmentation alarmante des vols de données des titulaires deLe risque de fonctionnement a été défini par le Comité comme carte et personnelles a entraîné le vol des informations person-« le risque de perte résultant des processus internes, personnes nelles de millions d’utilisateurs de cartes de crédit et souventou systèmes inadéquats ou défaillants ou d’événements leur utilisation à des fins illicites. L’impact sur les clients a euexternes. »7 pour conséquence une baisse de la confiance lors des achats en magasin ou sur internet ; les sociétés qui ont souffert d’une failleCe risque inclut les interruptions d’activité et les pannes de sys- et de pertes de données font face à de multiples conséquencestème causées par des pannes matérielles ou logicielles, ainsi que allant de reportages médiatisés à des coûts énormes pour noti-les fraudes résultant du piratage ou d’une mauvaise utilisation fier et apaiser les utilisateurs affectés.d’informations confidentielles du client.
  6. 6. 6 La sécurité qui compteEn conséquence, les Normes de sécurité des données de tition (race conditions), les injections SQL et le cross-sitel’industrie des cartes de paiement (PCI DSS) ont été dévelop- scripting mais aussi les infractions aux politiques telles que despées, cherchant à amener les organisations qui traitent les niveaux insuffisants de cryptage ou de contrôle d’accès créentdonnées des clients titulaires de cartes à se conformer aux direc- un risque identique si ce n’est supérieur pour les données confi-tives des normes de sécurité, y compris l’évaluation de leurs dentielles critiques des institutions financières.applications. Les exigences 3 et 6 traitent spécifiquement desproblèmes relatifs à la sécurité et à la confidentialité des don- Ces attaques continuent de prospérer malgré d’extraordinairesnées des clients ; des exigences pour analyser le code source sont mesures de protection des réseaux et des applications, telles quedevenues obligatoires le 30 juin 2008. les firewalls réseau et applicatifs. Elles aboutissent malgré des tests stricts de sécurité des applications grâce à l’utilisation d’outils d’injection. Il devient de plus en plus clair que de telles attaques aboutissent car le problème fondamental - découvrir etLes attaques exploitant les vulnérabilités des corriger les défauts dans le logiciel lui-même - n’est pas cor-logiciels représentent la majorité des attaques rectement abordé. Contrairement à la protection réactive des technologies de sécurité existantes, si la vulnérabilité est corri-sur les industries d’aujourd’hui. gée dans le code lui-même, alors le risque qui lui est associé est supprimé.Se concentrer sur la sécurisation des logiciels Cette approche préemptive et préventive de la sécurité est miseCe centre d’attention réglementaire accru ainsi que en évidence par les analyses informatiques effectués par lesl’augmentation de la demande des clients concernant l’intégrité agences membres de la Federal Financial Institutionset la confidentialité des données ont codifié la compréhension Examination Council (FFIEC). « Les institutions financièresde l’industrie du fait que les logiciels, en tant que composants peuvent implémenter les contrôles de sécurité approprié aveccritiques de l’infrastructure informatique, peuvent engendrer une meilleure rentabilité en les concevant dans le logiciel origi-un risque significatif et sont un point d’accès aux informations nal plutôt que d’effectuer des modifications conséquentes aprèsconfidentielles. Les attaques exploitant les vulnérabilités des l’implémentation, » déclare la FFIEC. « Les activités de dével-logiciels représentent la majorité des attaques sur les industries oppement et de maintenance doivent garantir que le nouveaud’aujourd’hui. logiciel et les modifications logicielles ne compromettent pas la sécurité. Les institutions financières doivent avoir une applica-De nombreuses attaques et vulnérabilités visibles et médiatisées tion efficace et le processus de contrôle de modification duont introduit le terme « débordement de tampon (buffer over- système pour développer, implémenter et tester les modifica-flow) » dans le langage commun ; cependant, ces types d’erreur tions des logiciels développés en internes et des logicielsde codage ne sont que la partie visible de l’iceberg de la sécurité achetés. » 8de l’application. D’autres, telles que les situations de compé-
  7. 7. 7 La sécurité qui compteLa FFIEC décrit leurs attentes concernant les revues et les tests Bureau du contrôleur de la monnaie (Office of the Comptrollerdu code source. « Le code source des applications et des système of the Currency, OCC) américain estime qu’environ 70 pourcentsd’exploitation peut avoir de nombreuses vulnérabilités dues aux des banques font confiance à des fournisseurs de service pourerreurs de programmation et de configuration. Lorsque cela est effectuer des activités stratégiques. Les institutions financièrespossible, les institutions financières doivent utiliser les logiciels doivent définir des critères et montrer des efforts continus pourqui ont été soumis aux revues de sécurité indépendantes du code évaluer les normes de sécurité des fournisseurs externes etsource particulièrement pour les systèmes exposés à Internet… l’implémentation afin de se conformer aux directives réglemen-Les revues de code source doivent être répétées après la création taires. Que le fournisseur développe le logiciel pour l’institutiondes modifications potentiellement importantes. »9 ou fournisse un service utilisant une application, il doit se tenir aux mêmes exigences de sécurité que pour une application ou un service interne. Le lien le plus faible représente la menace la plus importante.« Les institutions financières peuventimplémenter les contrôles de sécurité approprié Les examinateurs reconnaissent les risques posés par les projets et les services externalisés et demandent aux institutions deavec une meilleure rentabilité en les concevant mettre en place un programme de gestion de vendeur pour con-dans le logiciel original plutôt que d’effectuer trôler la sécurité de leurs applications externalisées, incluant:des modifications conséquentes aprèsl’implémentation » • Mettre en place des exigences en matière de sécurité, des critères d’acceptation et des plans de test.- FFIEC, IT Examination Handbook (manuel d’examen des TI) • Revoir et tester le code source pour découvrir des failles de sécurité. • Effectuer des tests de sécurité pour vérifier que les exigences en termes de sécurité sont respectées avant de mettre leExigences en termes de sécurité logiciel en production.concernant l’externalisationCes exigences s’appliquent non seulement aux applicationsdéveloppées en interne, mais sont parfois plus importantes dansle domaine de plus en plus répandu de l’externalisation. Le
  8. 8. 8 La sécurité qui compteLes résultats de la revue de code peuvent être Productionutilisés comme un autre élément des critères $100 $90d’acceptation avec le vendeur externe. $80 $70 $60 Béta $USD $50Répondre aux normes pour les applications sécurisées définies $40 $30par les organismes de réglementation, et les dépasser, est une $20 Qualitétache multi niveau et difficile. Tout effort doit inclure les tech- $20 Codagenologies de protection mentionnés précédemment, telles que $10 Conceptionles firewalls réseau et applicatifs. Ils doivent également inclure $des tests tardifs des applications pour découvrir les failles Etape de productiond’implémentation, telles que l’exposition au cross-site scripting. Source: Boehm et al, COCOMO IIMais la solution la plus efficace et la plus rentable est probable- Fig. 1 : Coût de correctionment basée sur la prévention, l’utilisation d’analyse de codesécurisée, de revues et de correction de manière précoce et sou- Software Engineering de Californie du Sud ont montré qu’unvent dans le processus de développement. bug qui coûte 1 $US à corriger dans la phase de conception coûte 100 $US à corriger une fois en production (Fig. 1), mais laLe besoin d’analyse des risques logiciels capacité à identifier et prioriser ces types de vulnérabilité deEnfouies dans les milliers ou millions de lignes de code qui manière précoce demande une connaissance des applicationscomposent une application se trouvent les erreurs de codage, les elles-mêmes.défauts de conception et les violations de politiques qui sont lagenèse de la vulnérabilité. Ces vulnérabilités coûtent aux socié- La découverte et l’atténuation des vulnérabilités de l’applicationtés plusieurs milliers de dollars chaque année, que ce soit en requièrent des informations précises et des conseils de correc-coût de nettoyage ou simplement à cause des correctifs apportés tion qui aident les directeurs de sécurité à prendre des décisionsà leurs applications. Les recherches sur le Constructive Cost d’atténuation des risques ciblées et délibérées, que l’applicationModel, ou COCOMO II, par le Dr. Barry Boehm au Center for soit développée en interne ou par un prestataire.
  9. 9. 9 La sécurité qui compte Vigilance constante Jusque récemment, il n’existait qu’une manière prouvée de véri-Corrigez-le maintenant, ou corrigez-le plus fier précisément le degré de sécurité d’une application. +Unetard : Un bug qui coûte 1 $US à corriger dans société devait mettre en place une équipe de revue de sécuritéla phase de conception coûte 100 $US à du code pour examiner manuellement le code, identifier les failles et demander un correctif au prestataire. Cette équipe pouvaitcorriger une fois en production. être une ressource interne, ou souvent être une société de ser-- COCOMO II vices extérieure possédant une expertise spécifique en sécurité. Même s’il s’agit d’une manière efficace d’évaluer le code source,Toute application, indépendamment de son origine, doit être elle est souvent coûteuse en argent et en temps, et généralementanalysée pour contrôler la sécurité de son implémentation, effectuée seulement une ou deux fois par an. Etant donné legarantissant qu’elle est écrite de la manière la plus sûre possible. facteur d’erreur humaine et le manque de répétabilité, les revuesLa méthode recommandée pour garantir que le code est de code manuelles ne peuvent, par leur nature, pas générer lessécurisé est d’effectuer des revues de code source détaillées. Un informations recevables et répétitives nécessaires pour prendrecommuniqué Microsoft l’a exprimé plus succinctement : « Une des décisions en terme de gestion de risques et de correction,revue de code conduite correctement peut en faire plus pour la traiter rapidement les problèmes de perte de données ; elles nesécurité du code que quasiment toute autre activité. »10 peuvent pas non plus suivre efficacement les progrès au fil du temps.Les résultats de la revue de code peuvent être utilisés comme un De plus, ce procédé ne peut, de par sa nature, pas être exécutéautre élément des critères d’acceptation ou des accords sur les pendant le cycle de développement du logiciel, limitant la possi-niveaux de service avec le vendeur externe. De cette manière, les bilité de traitement des failles par les développeurs avant que leanalyses et les améliorations sur les projets s’intègrent dans les logiciel ne soit entièrement déployé. Les revues de code sourcesociétés réalisant le développement. manuelles ne sont donc pas une garantie suffisante de connais- sance du niveau de sécurité d’une application.
  10. 10. 10 La sécurité qui compteChaque version de maintenance et de correction de bug peut • Rational AppScan Source Edition for Developer : Modulepotentiellement introduire de nouvelles vulnérabilités dans le intégré IDE incluant gratuitement des fonctionnalités delogiciel qui peuvent ne pas être détectées avant la revue de code correction et la capacité de rechercher des failles dans lesuivante. Une méthode plus rentable, complète et régulière code source.d’analyse de la sécurité du logiciel et de correction est donc • Rational AppScan Source Edition for Reporting Console :nécessaire. Un tableau de bord multi-application qui compare les applications et gère les risques au niveau de l’entreprise.Analyse des risques logiciels et IBMRational AppScan Source Edition L’avantage de Rational AppScan SourceLa technologie brevetée IBM Rational AppScan Source EditionEdition d’analyse automatisée du code source fournit des détails Seule la solution Rational AppScan Source Edition a été conçueprécis et des conseils de correction concernant les vulnérabilités « from scratch » pour aider à apporter à vos directeurs, ana-des logiciels, y compris les erreurs de codage, les défauts de con- lystes, développeurs et auditeurs les réponses dont ils ont besoinception et les violations de politiques. A l’aide de ces informations, pour gérer les risques des logiciels vulnérables. La solutionles directeurs, managers, auditeurs, analystes et développeurs d’analyse des risques logiciels brevetée IBM Rational AppScanpeuvent prendre en charge les efforts d’analyse des risques Source Edition peut vous aider à :logiciels, gérer les risques des logiciels vulnérables et éliminerles failles logicielles à la source. • Identifier rapidement les plus sérieux risques de sécurité : Les fonctionnalités uniques d’analyse de Rational AppScanLa solution Rational AppScan Source Edition a été conçue pour Source Edition peuvent identifier les erreurs de codage etapporter une valeur maximale à chaque utilisateur dans votre les défauts de conception les plus critiques.société ayant un rôle à jouer au niveau de la sécurité logicielle. • Optimiser l’efficacité de vos participants à la sécurité :La solution IBM Rational AppScan Source Edition inclut : Les meilleurs délais avant résultat rationalisent les efforts de sécurité tout au long du cycle de vie du développement• Rational AppScan Source Edition for Standard Core : Base de logiciel, pour tous les participants. connaissance de sécurité et base de données d’évaluation • Gérer les risques dans tout votre portefeuille d’entreprise : multi-application. Les tableaux de bord centralisés et les fonctionnalités de• Rational AppScan Source Edition for Security : Interface pour gestion de politiques permettent de disposer d’informations gérer les politiques de sécurité, configurer, examiner et instantanées de vos risques logiciels, ceci dans l’ensemble de traiter les vulnérabilités prioritaires. l’entreprise.• Rational AppScan Source Edition Remediation : Module intégré IDE pour comprendre et traiter les vulnérabilités critiques au niveau de la ligne de code. Elles sont fournies gratuitement.
  11. 11. 11 La sécurité qui compteGrâce à la solution Rational AppScan Source Edition, les Pour plus d’informationsorganisations financières peuvent non seulement satisfaire aux Pour en savoir plus sur IBM Rational AppScan Source Edition,normes des applications sécurisées mais aussi les dépasser en contactez votre représentant IBM ou votre partenaire commer-analysant les vulnérabilités des logiciels critiques tout au long cial IBM, ou visitez le site suivant :du cycle de développement. La solution Rational AppScanSource Edition supporte les initiatives d’analyse des risques ibm.com/rational/products/Rational AppScandans toute l’entreprise en fournissant des informations précisesconcernant les vulnérabilités des logiciels et en offrant des De plus, les solutions financières d’IBM Global Financing per-preuves de correction au fil du temps. mettent une gestion de trésorerie efficace, une protection contre l’obsolescence des technologies, un coût total d’exploitation et unSécurité intégrée retour sur investissement améliorés. Nos Global Asset RecoveryL’environnement réglementaire, particulièrement à la suite des Services aident également à traiter les problèmes d’environnementrécents scandales comptables et pertes commerciales, continue grâce à de nouvelles solutions plus économes en énergie. Pourde codifier les exigences pour les systèmes et processus sécuri- en savoir plus sur IBM Global Financing, consultez :sés et confidentiels dans l’industrie des services financiers. Entant qu’élément clé dans l’infrastructure informatique, les app- ibm.com/financinglications doivent être développées de manière sécurisée dès ledébut, tout en subissant une évaluation régulière de la sécuritéau cours de leur évolution.Ce processus, jusque maintenant une tache manuelle coûteuseen argent et en temps, est devenu plus accessible avec l’arrivéed’outils d’analyse automatisés tels que ceux fournis par RationalAppScan Source Edition. En utilisant les analyses de codesource automatisées, les organisations ont non seulement lapossibilité de localiser, comprendre et éliminer les erreurs decodage et les violations de politiques tout au long du cycle dedéveloppement du logiciel, mais peuvent également disposerdes informations nécessaires sur lesquelles baser des décisionsd’allocation de ressources et de technologies pour réduire lesrisques et apporter la preuve du respect des normes au fil du temps.
  12. 12. © Copyright IBM Corporation 2010 Route 100 Somers, NY 10589 U.S.A. Produit aux Etats-Unis Décembree 2010 Tous droits réservés IBM, le logo IBM, ibm.com, Rational AppScan et Rational sont des marques d’International Business Machines Corp., déposées dans de nombreuses juridictions réparties dans le monde entier. Les autres noms de produits et services peuvent être des marques d’IBM ou d’autres entreprises. La liste des marques IBM actualisée est disponible sur Internet, dans la rubrique con- sacrée au copyright et aux marques du site www.ibm.com. Microsoft est une marque de Microsoft Corporation aux Etats- Unis et/ou dans certains autres pays. 1 Gramm-Leach-Bliley Act, Loi publique 106-102, 12 novembre 12 1999, Section 501. 2 Federal Trade Commission, « Standards for Safeguarding Customer Information, Final Rule, » 16 CFR Part 314, 23 mai 2002. 3 Ibid. 4 « SEC Squeeze Play Puts Pressure on CIOs, » CIO Insight, 13 décembre 2002. 5 Ibid. 6 Ibid. 7 Comité de Bâle sur le contrôle bancaire, « Sound Practices for the Management and Supervision of Operational Risk, » février 2003. 8 Federal Financial Institutions Examination Council, « IT Examination Handbook, » décembre 2002, pg. 56-57. 9 Ibid., p. 57.10 J.D. Meier, et. al, « How to Perform a Security Code Review for Managed Code, » Microsoft Corporation, octobre 2005. Merci de recyclerFMW03008-USEN-00

×