De nombreux sites e-commerce ont compris le réel intérêt de ne plus traiter eux-même les données bancaires et de faire appel à un prestataire certifié PCI DSS.
Ainsi, si un site s’appuie sur un prestataire de paiement certifié PCI DSS, il entre dans la catégorie des marchands éligibles aux exigences du SAQ A et doit donc respecter une sous-partie du standard PCI DSS, soit 22 exigences.
A chaque analyse d’écart que nous réalisons, les mêmes questions reviennent. Essayons de répondre aux plus fréquemment rencontrées.
Qui est éligible au SAQ A ?
Le SAQ A est un questionnaire d’auto-certification défini par le PCI SSC donnant la possibilité aux marchands de se certifier PCI DSS eux-mêmes lorsqu’ils externalisent totalement les fonctions de paiement.
On retrouve notamment les marchands qui opèrent des sites e-commerce.
Cependant des conditions particulières s’appliquent aux sites e-commerce afin de pouvoir être éligibles au SAQ A.
En effet, l’intégration de la brique de paiement doit exclusivement se faire :
- par le biais d’une redirection : le site e-commerce redirige le client vers le formulaire de paiement du PSP.
- par la présence d’une iframe : la page de paiement du PSP est intégrée dans une iframe au sein de la page du site e-commerce.
Si vous respectez un des deux cas suivants, votre site est alors éligible aux exigences du SAQ A (dans le cas contraire, davantage d’exigences seront applicables au travers du SAQ A-EP ou du SAQ D).
Reste maintenant à déterminer, si vous pouvez vous auto-certifier ou devez faire appel à une société QSA…
Un QSA est-il nécessaire pour remplir un SAQ A ?
La réponse est non. Le questionnaire d’auto-évaluation SAQ A a été créé pour ça. Vous pouvez vous auto-évaluer sur les 22 exigences à condition que :
- Vous réalisiez moins de 6 millions de transactions par an.
- Vous n’ayez jamais fais face à une compromission.
- Votre banque d’acquisition ne vous impose pas de passer par une société QSA.
Si vous réalisez plus de 6 millions, alors vous êtes considéré comme un marchand de niveau 1 et donc dans ce cas précis, vous devez faire appel à une société QSA.
Le QSA devra alors rédiger un ROC et non un SAQ.
Cependant, de nombreux marchands de niveau 2 (de 6 millions à 1 million de transactions), niveau 3 (de 1 million à 20 000 transactions) ou niveau4 (moins de 20 000 transactions) préfèrent faire appel à une société QSA afin d’être assurés du respect du standard et de pouvoir montrer une “Attestation Of Compliance” qui peut avoir plus de valeur aux yeux de leurs banques, acquéreurs, partenaires ou clients.
Je réalise plus de 6 millions de transactions, je fais donc appel à un QSA, quelles exigences sont applicables ?
Peu importe le niveau de transactions réalisées, vous devrez respecter les exigences listées dans le SAQ A. Ce sera uniquement le rendu final qui changera (SAQ A ou ROC).
Dans le cas d’un ROC, le QSA ne remplira que les exigences listées dans le SAQ A et notera que toutes les autres exigences sont non-applicable car non imposées par le SAQ A.
A quel(s) équipement(s), serveur(s) s’appliquent les exigences du SAQ A ?
Le périmètre d’applicabilité de ces 22 exigences va être constitué de tous les équipements pouvant avoir un impact sur la sécurité de la page réalisant la redirection.
En d’autres termes, si nous avons une architecture relativement classique comme ci-dessous, seul le serveur hébergeant la page en charge de la redirection vers le prestataire de paiement sera considéré dans le “périmètre PCI DSS”.
Cependant, dans le cas d’architectures plus complexes, nous pourrons inclure, dans le périmètre de l’audit, une base de données (hébergeant du code HTML utilisé par la page réalisant la redirection ou l’intégration de l’iframe), une application back-office (permettant, par exemple de modifier le contenu de la page réalisant la redirection), un serveur de version (utilisé pour déployer automatiquement les sources de la page réalisant la redirection), etc.
Quelles sont les exigences applicables dans le cas d’un SAQ A ? (cas pratique)
Le tableau suivant résume toutes les exigences applicables.
Nous avons ajouté nos commentaires et contrôles réalisés afin de détailler le cas de l’architecture présentée ci-dessus dans le schéma.
| Exigences du SAQ A | Contrôles réalisés par XMCO |
| 2.1 – (a) Are vendor-supplied defaults always changed before installing a system on the network? (b) Are unnecessary default accounts removed or disabled before installing a system on the network? | Vérification sur le serveur qu’aucun compte/mot de passe par défaut n’est présent et désactivation des comptes inutilisés sur le serveur (Windows/Linux) et sur les applications éventuelles installées sur le serveur (Back-office, interface d’un CMS, etc) Vérification de la politique associée. |
| 6.2 – (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches? (b) Are critical security patches installed within one month of release? Vérification des versions utilisées du système d’exploitation, des paquets installés, des applications tierces (serveur web, CMS, etc) | Vérification de la politique associée. Vérification des preuves permettant d’indiquer que la procédure de patch a été suivie durant l’année (pour renouvellement de la certification). |
| 6.2 – (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches? (b) Are critical security patches installed within one month of release? | Vérification des versions utilisées du système d’exploitation, des paquets installés, des applications tierces (serveur web, CMS, etc) Vérification de la politique associée. Vérification des preuves permettant d’indiquer que la procédure de patch a été suivie durant l’année (pour renouvellement de la certification). |
| 8.1.1 – Are all users assigned a unique ID before allowing them to access system components or cardholder data | Vérification technique sur les composants (serveur, Back-office et interface d’administration du CMS) de l’absence de compte générique et de l’identification d’un utilisateur unique et nominatif par utilisateur. Vérification de la politique associée. |
| 8.1.3 – Is access for any terminated users immediately deactivated or removed? | Vérification de la procédure mise en oeuvre lors du départ d’un employé. Vérification de la liste des employés partis durant les 6 derniers mois et contrôle sur le serveur/CMS/Back-office de l’absence de ces comptes. Vérification de la politique associée. |
| 8.2 – In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users? Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric | Vérification de la politique de mot de passe mise en oeuvre sur toutes les briques de l’environnement (serveur, CMS, Back-office). Vérification de la politique associée. |
| 8.2.3 – Are user password parameters configured to require passwords/passphrases meet the following? A minimum password length of at least seven characters Contain both numeric and alphabetic characters | Vérification de la politique de mot de passe mise en oeuvre sur toutes les briques de l’environnement (serveur, CMS, Back-office). Vérification de la politique associée. |
| 8.5 – Are group, shared, or generic accounts, passwords, or other authentication methods prohibited as follows: Generic user IDs and accounts are disabled or removed; Shared user IDs for system administration activities and other critical functions do not exist; and Shared and generic user IDs are not used to administer any system components? | Vérification de l’absence de comptes génériques actifs. Si un compte générique est présent (compte root), confirmer que ce compte ne peut être utilisé (connaissance limitée du mot de passe par une population définie et documentée). Vérification de la politique associée. |
| 9.5 – Are all media physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes)? | Non applicable dans notre cas “ecommerce” |
| 9.6 – (a) Is strict control maintained over the internal or external distribution of any kind of media? | Non applicable dans notre cas “ecommerce” |
| 9.7 – Is strict control maintained over the storage and accessibility of media? | Non applicable dans notre cas “ecommerce” |
| 9.8 – (a) Is all media destroyed when it is no longer needed for business or legal reasons? (c) Is media destruction performed | Non applicable dans notre cas “ecommerce” |
| 9.8.1 – (a) Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed? (b) Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents? | Non applicable dans notre cas “ecommerce” |
| 12.8 – Are policies and procedures maintained and implemented to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data. | Vérification de la politique associée. |
| 12.8.1 – Is a list of service providers maintained, including a description of the service(s) provided? | Vérification de la liste des prestataires utilisés. |
| 12.8.2 – Is a written agreement maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment? | Vérification du contrat entre le prestataire de service et le marchand. Ce dernier doit spécifier que le prestataire s’engage à assurer la sécurité des données de cartes. |
| 12.8.3 – Is there an established process for engaging service providers, including proper due diligence prior to engagement? | Vérification de la politique associée. |
| 12.8.4 – Is a program maintained to monitor service providers’ PCI DSS compliance status at least annually? | Vérification de la politique associée. Vérification des actions réalisées lors de la dernière vérification. Vérification de l’AOC du prestataire certifié et de la validité de cette attestation (date, signée par un QSA). |
| 12.8.5 – Is information maintained about which PCI DSS requirements are managed by each service provider, and which are managed by the entity? | Dans le cas de l’utilisation d’un prestataire prenant en charge une partie des exigences applicables, vérifier le document qui précise qui est responsable de quelle exigence. |
| 12.10.1 – (a) Has an incident response plan been created to be implemented in the event of system breach? | Vérification de la politique associée. |
Les scans ASV sont-ils obligatoires ?
La question est assez controversée. En effet, aucune exigence du SAQ A n’impose des scans de vulnérabilité (11.3 du PCI DSS).
Cependant, de nombreuses banques préfèrent imposer les scans trimestriels validés par une société ASV.
Nous vous invitons donc à prendre contact avec votre banque (dans l’espoir où vous trouverez un interlocuteur capable de vous répondre…).
