mercredi 16 mai 2012

Evolution majeure du programme PCI PA-DSS

Le PCI (Payment Card Industry) SSC (Security Standard Council) a récemment publié la version 2.0 du guide PA-DSS qui présente une évolution majeur de la définition d'un changement mineur d’une application de paiement certifiée PA-DSS. Cette évolution est à l’image de la récente annonce du programme PCI PTS (Pin Transaction Security) et des évaluations d’écarts (Delta Evaluations) que le PCI SSC accorde à présent aux fournisseurs afin de s’aligner entre autre aux évolutions et mises à jour des composants certifiés PTS.

Dans la version antérieur du programme PA-DSS certains types de changements apportés à une application exigés une revalidation complète de l'application de paiement, en d’autre terme un audit PA-DSS complet. Pour éviter cela il était donc important de trouver une gestion de version de l’application appropriée à communiquer au PCI SSC afin d’être ou de rester éligible au programme.

Désormais lorsqu’une application de paiement a été modifiée, le PA-QSA (Payment Application Qualified Security Assessor) se limitera à l’évaluation du changement apporté sans revalidation complète de l’application. Le nouveau guide du programme PA-DSS fournit plus d’information à ce sujet et clarifie la notion de changement mineur qui est présenté selon les types de changements suivants :
  • Les changements sans impact : ce sont des changements mineurs apportés à une application certifiée qui n’ont aucun impact sur les exigences PA-DSS (exemples : changements apportées aux interfaces graphiques utilisateurs ou aux modules qui n’assurent pas de fonctions de paiements …),
  • Les changements avec un impact faible: ce sont des changements mineurs apportés à une application certifiée qui ont un impact limité sur les exigences PA-DSS. Le PCI SSC a listé ces changements avec impact faible qui sont au nombre de 6 :
    1. L'installation d’une mise à jour mineur ou d’un correctif de la version d’un système d’exploitation sur lequel l’application a été validée,
    2. L'installation d’une mise à jour mineure ou d’un correctif d’une base de données bases de données sur laquelle l’application a été validée,
    3. Mises à jour des modules ou des fonctions de « reporting » de l’application,
    4. L'installation d’une mise à jour mineures ou d’un correctif d’un « middlewre » sur lequel l’application a été validée,
    5. Recompilation du code inchangée soit avec le même compilateur ou en utilisant différents « flags » ou encore avec un compilateur complètement différent.
  • Les changements avec un impact élevé: ce sont les changements lourds liés au chiffrement, gestion des clés traitement, stockage des données porteurs.

Aucun commentaire:

Enregistrer un commentaire