Rational France - Livre blanc - La securite qui compte
1. Compagnie IBM France Rational
Livre blanc Thought Leadership
La sécurité qui compte
Nécessité d’un logiciel sécurisé pour les fournisseurs de services financiers
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 La sécurité qui compte
L’environnement réglementaire s’intensifie 1. Pour garantir la sécurité et la confidentialité des
L’intégrité et la confidentialité des informations financières ont enregistrements et des informations des clients ;
longtemps été une préoccupation pour les examinateurs des
organismes financiers depuis que les gouvernements ont res- 2. Pour protéger par anticipation des menaces et des risques
senti pour la première fois le besoin d’une législation de contre la sécurité et l’intégrité de tels enregistrements ; et
surveillance de l’industrie. Alors que la technologie a accru la
portée et les capacités des organismes financiers autour du 3. Pour protéger contre les accès non autorisés à de tels
monde, elle a augmenté exponentiellement les risques et enregistrements ou informations ou contre leur utilisation
l’exposition des données critiques. Les transmissions électro- qui pourraient résulter en une nuisance ou un inconvénient
niques 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 en
monde courageux a entraîné des réglementations nouvelles en œuvre la loi nécessitent le développement d’un programme de
constante é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 institutions
Loi 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, la
des protections administrative, technique et physique de cer- destruction ou d’autres compromissions de telles informations. » 2
taines 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 une
fé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 la
physique. sécurité des applications qui alimentent les activités de
l’industrie des services financiers.
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é des
Les 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 de
ments 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éduisent
Loi Sarbanes-Oxley à zéro la tolérance à l’erreur. »5
A 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 les
gation et comptabilité d’entreprise. La loi, tout en resserrant les contrôles de sécurité sont en place, y compris pour les systèmes
délais et instituant des exigences en terme de rapport et de div- internes. « Nous pensons obtenir une déconnexion de la part de
ulgation 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 les
lement la précision des rapports financiers de la société. Ces informations de CIO Insight. « Cela sera certainement une
exigences 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 ou
devenu de plus en plus clair depuis leur publication. Les infor- modifiée durant le trimestre. »6Les applications qui gèrent le
mations 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és
Le 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 prennent
sur elles de demander aux autres directeurs - y compris le
directeur informatique - de se porter garants de l’intégrité des
systèmes de la société. » 4
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 institutions
demander aux autres directeurs - y compris le non directement sujettes aux Accords en ressentiront probable-
ment l’impact car les exigences s’imposeront inévitablement
directeur informatique - de se porter garants dans l’environnement réglementaire intérieur. Les Accords
de 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 le
une préoccupation mondiale. Cette préoccupation se reflète marché financier mondial comprend le risque en constante
dans 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 le
le contrôle bancaire et actuellement sous révision par les gou- besoin urgent d’introduire de nouveaux processus et solutions
vernements et les institutions financières. Par cette structure, pour se protéger du risque d’une manière continue, mesurable
l’exposition aux risques de fonctionnement devient un facteur et gérable.
important dans le calcul des exigences en capital total pour les
banques de premier plan et peut donc avoir des conséquences Normes de sécurité des données de
préjudiciables sur les gains et la valeur actionnariale. l’industrie des cartes de paiement
L’augmentation alarmante des vols de données des titulaires de
Le 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 souvent
ou systèmes inadéquats ou défaillants ou d’événements leur utilisation à des fins illicites. L’impact sur les clients a eu
externes. »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 faille
Ce risque inclut les interruptions d’activité et les pannes de sys- et de pertes de données font face à de multiples conséquences
tè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 La sécurité qui compte
En conséquence, les Normes de sécurité des données de tition (race conditions), les injections SQL et le cross-site
l’industrie des cartes de paiement (PCI DSS) ont été dévelop- scripting mais aussi les infractions aux politiques telles que des
pées, cherchant à amener les organisations qui traitent les niveaux insuffisants de cryptage ou de contrôle d’accès créent
donné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 des
problèmes relatifs à la sécurité et à la confidentialité des don- Ces attaques continuent de prospérer malgré d’extraordinaires
nées des clients ; des exigences pour analyser le code source sont mesures de protection des réseaux et des applications, telles que
devenues 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 et
Les 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 mise
Ce centre d’attention réglementaire accru ainsi que
en évidence par les analyses informatiques effectués par les
l’augmentation de la demande des clients concernant l’intégrité
agences membres de la Federal Financial Institutions
et la confidentialité des données ont codifié la compréhension
Examination Council (FFIEC). « Les institutions financières
de l’industrie du fait que les logiciels, en tant que composants
peuvent implémenter les contrôles de sécurité approprié avec
critiques 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ès
confidentielles. 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 nouveau
d’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 du
ont 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 logiciels
de codage ne sont que la partie visible de l’iceberg de la sécurité achetés. » 8
de l’application. D’autres, telles que les situations de compé-
7. 7 La sécurité qui compte
La FFIEC décrit leurs attentes concernant les revues et les tests Bureau du contrôleur de la monnaie (Office of the Comptroller
du code source. « Le code source des applications et des système of the Currency, OCC) américain estime qu’environ 70 pourcents
d’exploitation peut avoir de nombreuses vulnérabilités dues aux des banques font confiance à des fournisseurs de service pour
erreurs de programmation et de configuration. Lorsque cela est effectuer des activités stratégiques. Les institutions financières
possible, les institutions financières doivent utiliser les logiciels doivent définir des critères et montrer des efforts continus pour
qui ont été soumis aux revues de sécurité indépendantes du code évaluer les normes de sécurité des fournisseurs externes et
source 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’institution
des 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 peuvent
implé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 de
avec 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ès
l’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 le
Exigences en termes de sécurité logiciel en production.
concernant l’externalisation
Ces exigences s’appliquent non seulement aux applications
développées en interne, mais sont parfois plus importantes dans
le domaine de plus en plus répandu de l’externalisation. Le
8. 8 La sécurité qui compte
Les résultats de la revue de code peuvent être Production
utilisés comme un autre élément des critères $100
$90
d’acceptation avec le vendeur externe. $80
$70
$60 Béta
$USD
$50
Répondre aux normes pour les applications sécurisées définies $40
$30
par 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 Codage
nologies de protection mentionnés précédemment, telles que $10 Conception
les firewalls réseau et applicatifs. Ils doivent également inclure $
des tests tardifs des applications pour découvrir les failles Etape de production
d’implémentation, telles que l’exposition au cross-site scripting. Source: Boehm et al, COCOMO II
Mais la solution la plus efficace et la plus rentable est probable- Fig. 1 : Coût de correction
ment basée sur la prévention, l’utilisation d’analyse de code
sécurisée, de revues et de correction de manière précoce et sou- Software Engineering de Californie du Sud ont montré qu’un
vent 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 la
Le besoin d’analyse des risques logiciels capacité à identifier et prioriser ces types de vulnérabilité de
Enfouies dans les milliers ou millions de lignes de code qui manière précoce demande une connaissance des applications
composent une application se trouvent les erreurs de codage, les elles-mêmes.
défauts de conception et les violations de politiques qui sont la
genè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’application
té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’application
Model, ou COCOMO II, par le Dr. Barry Boehm au Center for soit développée en interne ou par un prestataire.
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. +Une
tard : 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 pouvait
corriger 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éralement
analysée pour contrôler la sécurité de son implémentation, effectuée seulement une ou deux fois par an. Etant donné le
garantissant 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 revues
La méthode recommandée pour garantir que le code est de code manuelles ne peuvent, par leur nature, pas générer les
sécurisé est d’effectuer des revues de code source détaillées. Un informations recevables et répétitives nécessaires pour prendre
communiqué 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 ne
sé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 le
analyses et les améliorations sur les projets s’intègrent dans les logiciel ne soit entièrement déployé. Les revues de code source
socié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 La sécurité qui compte
Chaque version de maintenance et de correction de bug peut • Rational AppScan Source Edition for Developer : Module
potentiellement introduire de nouvelles vulnérabilités dans le intégré IDE incluant gratuitement des fonctionnalités de
logiciel qui peuvent ne pas être détectées avant la revue de code correction et la capacité de rechercher des failles dans le
suivante. 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 IBM
Rational AppScan Source Edition L’avantage de Rational AppScan Source
La technologie brevetée IBM Rational AppScan Source Edition
Edition d’analyse automatisée du code source fournit des détails Seule la solution Rational AppScan Source Edition a été conçue
pré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 besoin
ception et les violations de politiques. A l’aide de ces informations, pour gérer les risques des logiciels vulnérables. La solution
les directeurs, managers, auditeurs, analystes et développeurs d’analyse des risques logiciels brevetée IBM Rational AppScan
peuvent prendre en charge les efforts d’analyse des risques Source Edition peut vous aider à :
logiciels, gérer les risques des logiciels vulnérables et éliminer
les failles logicielles à la source. • Identifier rapidement les plus sérieux risques de sécurité : Les
fonctionnalités uniques d’analyse de Rational AppScan
La solution Rational AppScan Source Edition a été conçue pour Source Edition peuvent identifier les erreurs de codage et
apporter 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 La sécurité qui compte
Grâce à la solution Rational AppScan Source Edition, les Pour plus d’informations
organisations 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 AppScan
Source Edition supporte les initiatives d’analyse des risques ibm.com/rational/products/Rational AppScan
dans toute l’entreprise en fournissant des informations précises
concernant 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 un
Sécurité intégrée retour sur investissement améliorés. Nos Global Asset Recovery
L’environnement réglementaire, particulièrement à la suite des Services aident également à traiter les problèmes d’environnement
récents scandales comptables et pertes commerciales, continue grâce à de nouvelles solutions plus économes en énergie. Pour
de 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. En
tant qu’élément clé dans l’infrastructure informatique, les app- ibm.com/financing
lications doivent être développées de manière sécurisée dès le
dé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ûteuse
en argent et en temps, est devenu plus accessible avec l’arrivée
d’outils d’analyse automatisés tels que ceux fournis par Rational
AppScan Source Edition. En utilisant les analyses de code
source automatisées, les organisations ont non seulement la
possibilité de localiser, comprendre et éliminer les erreurs de
codage et les violations de politiques tout au long du cycle de
développement du logiciel, mais peuvent également disposer
des informations nécessaires sur lesquelles baser des décisions
d’allocation de ressources et de technologies pour réduire les
risques et apporter la preuve du respect des normes au fil du temps.
