Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel

1,937 views

Published on

Lors d’un projet amenant à la certification PCI-­-DSS, comment comprendre les exigences de la norme et comment les traduire en action concrete sur le terrain, afin de démontrer à l’auditeur que le SDLC est maîtrisé.

Des mesures techniques sont exigées, mais une grande importance est donnée à la maîtrise du processus de développement.

Application Security Forum 2011
27.10.2011 - Yverdon-les-Bains (Switzerland)
Speaker: Christophe Nemeth

Published in: Technology

ASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel

  1. 1. PCI-DSS dans ledéveloppement applicatifChristophe NemethConsultantINOVEMENT Sàrl Application Security Forum Western Switzerland 27 octobre 2011 - HEIGVD Yverdon-les-Bains http://appsec-forum.ch
  2. 2. Agenda La norme PCI-DSS La norme PCI-DSS et le développement applicatif Points importants pour la conformité Conclusion 27.10.2011 Application Security Forum - Western Switzerland - 2011 2
  3. 3. PCI DSS – Définitions PCI – Payment Card Industy PCI SSC – Payment Card Industry Security Standards Council – Fondé par American Express, Discover Financial Services, JCB International, MasterCard Worldwide et Visa, Inc. PCI DSS – Payment Card Industry Data Security Standard – Guide comprenant 12 conditions aidant les entreprises émettrices de cartes de paiement à protéger leurs données et à prévenir les fraudes. 27.10.2011 Application Security Forum - Western Switzerland - 2011 3
  4. 4. PCI DSS – Les données Bande magnétique : Ne peut être conservé Nom du propriétaire en aucunes circon- PAN stances Date emission Date expiration CVC1Chip PAN CVC2 / CVV2 Date d‘expiration CAV2 / CID Peut être Peut être conservé mais conservé mais doit doit être chiffré si conservé être chiffré côte à côte avec le PAN 27.10.2011 Application Security Forum - Western Switzerland - 2011 4
  5. 5. PCI DSS – La norme 27.10.2011 Application Security Forum - Western Switzerland - 2011 5
  6. 6. PCI DSS – La norme 27.10.2011 Application Security Forum - Western Switzerland - 2011 6
  7. 7. PCI DSS et le développement 6.1 – Gestion des correctifs. 6.2 – Processus permettant d’assigner une catégorie de risque aux vulnérabilités permettant une priorisation de l’application des correctifs (obligatoire des le 30 juin 2012) 27.10.2011 Application Security Forum - Western Switzerland - 2011 7
  8. 8. PCI DSS et le développement 6.3 – Développer des applications logicielles conformément à la norme PCI DSS basées sur les meilleures pratiques du secteur. Intégrer la sécurité des informations à tout le cycle de vie du développement logiciel. 6.4 – Suivre les processus et procédures de contrôles des changements pour toutes les modifications apportées à des composants du système. 27.10.2011 Application Security Forum - Western Switzerland - 2011 8
  9. 9. PCI DSS et le développement 6.3 – Développer des applications logicielles conformément à la norme PCI DSS basées sur les meilleures pratiques du secteur. Intégrer la sécurité des informations à tout le cycle de vie du développement logiciel. 6.4 – Suivre les processus et procédures de contrôles des changements pour toutes les modifications apportées à des composants du système. 27.10.2011 Application Security Forum - Western Switzerland - 2011 9
  10. 10. PCI DSS et le développement 6.5 – Développer des applications basées sur les directives de codage sécurisé. Prévenir les vulnérabilités de codage courante dans les processus de développement de logiciel 6.6 – Pour les applications web orientées public, traiter les nouvelles menaces et vulnérabilités de manière régulière et veiller à ce que ces applications soient protégées contre les attaques connues. 27.10.2011 Application Security Forum - Western Switzerland - 2011 10
  11. 11. PCI DSS et le développement 6.5 – Développer des applications basées sur les directives de codage sécurisé. Prévenir les vulnérabilités de codage courante dans les processus de développement de logiciel 6.6 – Pour les applications web orientées public, traiter les nouvelles menaces et vulnérabilités de manière régulière et veiller à ce que ces applications soient protégées contre les attaques connues. 27.10.2011 Application Security Forum - Western Switzerland - 2011 11
  12. 12. PCI DSS 6.3 – SDLC Mgt Processus SDLC formalisé et documenté (6.3) 27.10.2011 Application Security Forum - Western Switzerland - 2011 12
  13. 13. PCI DSS 6.3 – SDLC Mgt Revue de code (6.3.2) – Par une tierce personne indépendante – Selon les bonnes pratiques (voir 6.5) • Implique la formation des développeurs – Les corrections sont apportées avant la mise en production – Le rapport de revue de code et approuvé 27.10.2011 Application Security Forum - Western Switzerland - 2011 13
  14. 14. PCI DSS 6.3 – SDLC Mgt Livrables – Processus de développement • Politique de développement • Procédure de développement – Revue de code – Rapport de revue de code – Preuve que les « bugs » sont gérés • Méthodologie de développement – Formation des développeurs – Plan de formation 27.10.2011 Application Security Forum - Western Switzerland - 2011 14
  15. 15. PCI DSS 6.4 – Change Mgt Séparation des environnements de production et de test avec contrôle d’accès approprié (6.4.1) Séparation des obligations entre les environnements de production et de test (6.4.2) Les données de production ne sont pas utilisées à des fins de test (6.4.3) – Utilisation de jeux de test 27.10.2011 Application Security Forum - Western Switzerland - 2011 15
  16. 16. PCI DSS 6.4 – Change Mgt Procédure de contrôle des modifications incluant (6.4.5) : – Documenter l’impact (6.4.5.1) – Documenter le changement approuvés par les responsables (6.4.5.2) – Tester le changement (6.4.5.3) – Existence d’une procédure de retour en arrière (6.4.5.4) 27.10.2011 Application Security Forum - Western Switzerland - 2011 16
  17. 17. PCI DSS 6.4 – Change Mgt Livrables – Matrice des rôles et responsabilités – Application de la politique de développement – Processus de gestion des changements • Politique de gestion des changements • Procédure de gestion des changements • Canevas divers comprenant les éléments demandés 27.10.2011 Application Security Forum - Western Switzerland - 2011 17
  18. 18. PCI DSS 6.5 – Bonne pratique Développer des applications basées sur les directives de codage sécurisé. Prévenir les vulnérabilités de codage courante dans les processus de développement de logiciel. – OWASP Top 10 – SANS Top 20 – CERT – … 27.10.2011 Application Security Forum - Western Switzerland - 2011 18
  19. 19. PCI DSS 6.5 – Bonnes pratiques Au minimum – OWASP Top 10 – Correction de toutes les vulnérabilités de niveau “élevé” identifiées dans le processus de gestion des vulnérabilités 27.10.2011 Application Security Forum - Western Switzerland - 2011 19
  20. 20. PCI DSS 6.5 – Bonnes pratiques Livrables – Procédure de développement sécurisé se référant à une bonne pratique. – Rapport de revue de code selon la bonne pratique – Procédure de gestion des correctifs – Rapport de scans propre (voire 6.6) 27.10.2011 Application Security Forum - Western Switzerland - 2011 20
  21. 21. PCI DSS 6.6 – Vulnerability Mgt Pour les application Web orientée public : – Test de vulnérabilité • Annuel ou après modification • Par une société spécialisée (interne ou externe, mais indépendante vis-à-vis du développement) • Toute les vulnérabilités sont corrigées • Test après correction – Pare-feu applicatif 27.10.2011 Application Security Forum - Western Switzerland - 2011 21
  22. 22. PCI DSS 6.6 – Vulnerability Mgt Livrables – Programme de gestion des vulnérabilités • Calendrier des scans interne et externe • Calendrier de test de pénétration • Rapport de scans et des tests (propre) • Liste des vulnérabilités découvertes et corrigées 27.10.2011 Application Security Forum - Western Switzerland - 2011 22
  23. 23. Conclusion Ne pas oublier l’aspect organisationnel, PCI DSS n’est pas que de la technique Nommer un chef de projet au métier – Chef de projet technique – Chef de projet gouvernance Ne pas oublier la gestion du changement – Les changements dans les procédures opérationnelles sont parfois difficiles à mettre en œuvre. Collaboration avec la société certificatrice 27.10.2011 Application Security Forum - Western Switzerland - 2011 23
  24. 24. © flickr.com/horiavarlan Vos questions ?27.10.2011 Application Security Forum - Western Switzerland - 2011 24
  25. 25. Merci! Christophe Nemeth cnemeth@inovement.com +41 79 47 50 23 SLIDES A TELECHARGER PROCHAINEMENT: http://slideshare.net/ASF-WS27.10.2011 Application Security Forum - Western Switzerland - 2011 25

×