01/06/2011

L'approche par priorité dans le PCI DSS 2.0

Le PCI Council vient de publier les exigences du standard 2.0 classées par priorité. 


Cette approche permet aux entreprises de savoir par où commencer dans leur projet de mise en conformité PCI DSS. Cependant, toutes les exigences restent obligatoires.


L'approche par prioritédéfinite 6 priorités ou "milestones" allant de 1 (prioritaire) à 6 (à faire en dernier).


Voici une synthèse de l'approche :



1 Remove sensitive authentication data and limit cardholder data retention

  •  Ne pas stocker les CVV2...
  •  Limiter les endroits où des PAN sont stockés involontairement
  •  Nettoyer les traces
  •  Analyse de risque

2 Protect the perimeter

  • Firewall, ACLs
  • Tests d'intrusion et scans de vulnérabilités
  • Chiffrement destransmissionsn (HTTPS)

3 Secure payment card applications

  • Développement sécurisé (Sql injection, OWASP..)
  • Patch management
  • Renforcement des configurations systèmes

4 Monitor and control access to your systems

  • Comptes et mots de passe 
  • Logs et IDS

5 Protect stored cardholder data

  • Chiffrement des PAN 
  • Gestion des clés de chiffrement

6 Finalize remaining compliance efforts

  • Rédaction des documentations et des procédures
  • Mise en place des process de maintien


On notera que l'analyse de risque (#12.1.2 "Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment"  est désormais placée en priorité n°1, c'est-à-dire que l'analyse de risque doit être faite au début du projet PCI DSS ; conjointement avec la politique de rétention des données de carte.

La question reste : quelle est la méthodologie d'analyse de risque qui doit être adoptée ? 


Je ne suis pas un adepte des méthodes lourdes comme MEHARI ou EBIOS, qui ne sont, selon moi, pas suffisamment basées sur l'expérience réelle des risques et des menaces informatiques d'aujourd'hui. Pour moi, une bonne analyse de risque doit tenir sur une page : une liste des véritables risques, conçue avec le métier et avec des vrais experts qui voient des attaques et des sinistres au quotidien. Pour chaque risque, l'entité doit statuer sur sa stratégie (acceptation, réduction ou externalisation) avec une évaluation probabilité/conséquences.


Exemple d'analyse du risque "attaque 0-days sur le serveur web avec backdoor sur le formulaire de paiement". Probabilité=probable, conséquences=dramatiques, stratégie=réduction du risque en utilisant un processus HTTP dans un chroot, un IPS ou un WAF pour bloquer les payloads connues, un contrôleur d'intégrité et des flux sortant bloqués.

Aucun commentaire:

Enregistrer un commentaire