30/04/2011

Sony PSN était-il PCI DSS ?

Sony vient de subir un énorme piratage de cartes. C'est une vraie catastrophe pour la firme. Le coût de cette intrusion va être énorme et ils vont payer pendant plusieurs années cette erreur (pertes d'images, renforcement, obligation d'être PCI DSS,etc.).

Beaucoup se demandent si le Sony PlayStation Network (PSN) était certifié PCI DSS.

N'ayant aucune information en dehors des communiqués officiels de Sony, je vais faire quelques hypothèses.

Le Sony PSN est-il certifié PCI DSS ?
Le PSN étant, je suppose, un "Merchant Level-1", il n'est pas possible de répondre car il n'y a pas de liste pour les marchands, à l'instar des listes de Service Providers PCI que publient Visa ou MasterCard. Seule la banque d'acquisition de Sony doit aujourd'hui connaître le statut de conformité de Sony.

Quoi qu'il en soit, le QSA qui aurait certifié Sony ne va pas faire de la publicité! Enfin, si Sony était certifié, je suppose qu'ils auraient communiqué sur le sujet au moment de leur certification.

Pour moi, le sujet n'est pas de savoir si Sony était certifié, mais plutôt si Sony aurait dû être certifié. Et la réponse est simple : oui. Puisque des numéros de cartes sont transmis au travers du réseau Sony PSN, ils étaient éligibles à la mise en conformité PCI DSS et leur banque devait leur demander de l'être. Mais on en arrive à un problème de conflit d'intérêt et de gros sous : est-ce que la banque de Sony peut véritablement leur interdire de faire du business par carte sans certification ? La réponse est plus dure, mais je tenterais bien : non.

Tout cela m'amène à penser qu'ils devaient être "en cours de certification". 

Comment se sont-ils fait pirater ?
Voici mes hypothèses et ce que je peux imaginer d'après mes expériences :

Plusieurs éléments glanés sur cette attaque :
  • Sony stockait les numéros de cartes (PAN) dans une table chiffrée. (PCI DSS #3.4, #3.5)
  • Sony ne stockait pas les cryptogrammes CVx2 (PCI DSS #.3.2). Les pirates n'ont donc pas pu les voler.
  • L'attaque est la suite du hack des PlayStation permettant de contourner la restriction d'accès au réseau privé PSN (PCI DSS #1.3).
  • Les clients du PSN ont vu des tentatives de retrait frauduleux sur leur relevé de banque (quelques centimes en autorisation sur des sites web étrangers, juste pour tester que les cartes sont valides).
  • Un fichier avec des milliers de numéros de cartes serait en vente sur des forums spécialisés dans le carding.
Je pense que tout le problème commence avec la notion de réseau privé. Dans le cas d'un réseau privé, les mesures de protection PCI DSS ne sont pas les mêmes et la base de données n'a pas à être firewallée des serveurs de DMZ. Or, suite à un précédent hack, le réseau PSN n'était plus vraiment privé, puisque certains pouvaient y connecter des systèmes sans licence. Il est donc imaginable que certains aient réussi à y connecter des PC et à scanner l'adressage interne privé du PSN. A partir de là, et supposant que la plate-forme PSN est composée de très nombreux serveurs, les pirates ont pu trouvé une faille (ex: mdp faible sur une base de données), un exploit connu (overflow...) ou même un zero-days.

Mais la table des cartes était-elle chiffrée ? Oui, certainement, mais cela n'empêche pas forcément de voler les numéros. En effet, si c'est "la table" qui est chiffrée, cela protège juste contre le vol du fichier (le datafile), mais n'empêche pas des requêtes SQL légitimes de faire des SELECT. Dans une hypothèse où les numéros de cartes étaient chiffrés au niveau de la donnée, tout dépend alors de comment étaient protégées les clés de chiffrement. Si celles-ci étaient dans le code ou dans un fichier sur le système, il était facile de les retrouver...

Maintenant que les cartes sont dans la nature, il est certain qu'un grand nombre de comptes bancaires vont se faire dévaliser. Ce hack du PSN va forcément générer des retombées et des plaintes dans toutes les banques et bien sûr chez les banques françaises.

Pourquoi donc stockaient-ils les numéros de carte ?

Pour faire des paiements récurrents ! Mais Sony aurait pu externaliser le stockage des PAN chez un PSP et ne conserver que des tokens. Je pense que c'est ici un bon exemple de la sécurité qu'apporte la tokenisation.

Que faire ?

Sony devrait (ou l'a déjà fait) donner la liste des numéros de cartes volés aux banques et aux réseaux Visa/Mastercard/Amex pour que ces numéros rentrent dans les algorithmes anti-fraudes. Comme les CVx2 n'ont pas été dérobés, il suffit d'interdire, pour cette liste noire de PAN, toute autorisation sans CVx2.

De leur côté, les clients n'ont plus qu'à surveiller leurs relevés et à appeler leur banque !


Conclusion

Cette affaire ne fait qu'illustrer le fait que le coût de la sécurité informatique n'est rien par rapport au prix qu'un piratage massif peut coûter à une entreprise.

22/04/2011

La fin du Self-Assessment pour les marchands niveau 2 ?

Jusqu'ici, les marchands réalisant moins de 6 millions de transactions annuelles par cartes bancaires pouvaient s'abstenir de faire appel à un audit QSA pour être conformes au PCI DSS. Il suffisait de faire l'audit soi-même et de remplir le questionnaire SAQ.

Mastercard indique désormais aux banques d'acquisition qu'elles ne doivent plus accepter les self-assessment, sauf s'il est réalisé par un auditeur interne ayant passé la formation ISA (Internal Security Assessor).

En d'autres termes, les marchands niveau 2 doivent faire appel à un QSA. Il est donc très probable que les marchands français voient leur banque changer leur exigence de reporting PCI et demander la signature d'un QSA.

15/04/2011

Voler de l'argent avec un RIB ? Direct Debit !

Vous êtes-vous déjà demandé si, à partir de votre RIB, quelqu'un pouvait voler de l'argent sur votre compte en banque ? 

Si vous avez un compte dans une banque allemande ou anglaise, ce n'est pas impossible. Cela s'appelle le Direct Debit.

C'est très simple, lors d'un paiement sur un site web marchand, lorsque le site vous demande si vous souhaitez payer par PayPal, Visa, Mastercard ou autre, il peut y avoir le choix Direct Debit. Ce mécanisme est très utilisé en Allemagne. Vous saisissez vos coordonnées RIB ou IBAN et vous cliquez. Cela autorise la banque du marchand à venir débiter votre compte. C'est une autorisation de prélèvement en ligne, sans confirmation.

Niveau de sécurité ? Zéro. D'un côté, en France, on impose le 3D-Secure et de l'autre côté du Rhin, on se fait confiance (le consommateur peut simplement faire opposition).  L'intérêt pour le marchand est le contournement des frais des marques de cartes.  Le marchand prend simplement l'option Direct Debit de son PSP.


En France, pour faire un prélèvement depuis un RIB, il faut que le consommateur autorise par écrit sa banque. Cependant, il paraitrait que toutes les banques n'attendent pas l'autorisation...

Avec l'arrivée du SEPA (uniformisation des moyens de paiements en Europe), le Direct Debit (SDD) risque donc de créer de nouvelles fraudes. 


Un pirate d'Anonymous qui ne fait pas attention à son anonymat !

Franchement, celle-là est excellente ! Carl,  un apprenti pirate, c'est fait tracer par la police après son passage à télé.

A partir du reportage diffusé dans Complément d'enquête le 1er mars sur France 2, les enquêteurs français l'ont tracéLes enquêteurs ont découvert des cartes bancaires volées dans la machine du pirate. Ne chiffrait-il pas son disque dur ?

Ce qu'il faut savoir avec les "pirates", c'est qu'ils cherchent la reconnaissance. Ils sont ainsi facilement enclin à répondre aux journalistes...

11/04/2011

Le PCI DSS est-il une exigence légale en France ?

On me fait régulièrement la remarque que le standard PCI DSS n'est pas une exigence légale en France et qu'il n'est donc pas obligatoire pour l'entreprise de s'y soumettre.

Tout d'abord, dans les nombreux cas clients dans lesquels je suis amené à intervenir, l'exigence d'être PCI DSS provient d'un client/prospect important qui exige la conformité par une clause contractuelle. Même si ce n'est pas une exigence légale, les entreprises cherchent à être conformes pour gagner l'affaire.


La CNIL exige que :
  1. Les cryptogrammes visuels (CVV2) ne soient jamais stockés. Il s'agit de l'exigence PCI DSS #3.2.
  2. Les numéros de carte (PAN) doivent être chiffrés s'ils sont stockés dans la base de données. Il s'agit de l'exigence PCI DSS #3.4.
  3. Les données des titulaires de cartes doivent être conservées que le temps nécessaire. Il s'agit de l'exigence PCI DSS #3.1.
  4. La mise en place d'une politique de gestion stricte des habilitations du personnel ayant accès au numéro de carte bancaire. Il s'agit de l'exigence PCI DSS #7.1.
  5. L'utilisation exclusive de systèmes de paiement en ligne sécurisés. Il s'agit d'une façon de dire : soit vous utilisez une page de paiement d'un prestataire de paiement certifié ou soit vous sécurisez vos systèmes selon les meilleures pratiques en vigueur (c'est-à-dire isoler les systèmes, utiliser des logiciels de paiement certifiés PA DSS, appliquer les patchs de sécurité, développer selon l'OWASP, réaliser des audits de code, etc...Bref, le PCI DSS).
  6. Si les données de carte sont échangées avec un sous-traitant, l'entreprise doit choisir un sous-traitant qui apporte des garanties suffisantes au regard des mesures de sécurité. Il s'agit de l'exigence PCI DSS #12.8.

Si l'on rajoute à cela l'article 34 de la loi Informatique et Libertés relative à la mise en œuvre de "toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement" sous peine d'une amende  allant jusqu'à 300.000 euros (code pénal, Article 226-17), nous pouvons considérer que les exigences indiquées dans le PCI DSS sont des exigences légales et qu'il pourra être reproché à l'entreprise de ne pas les avoir mises en oeuvre dans d'une plainte suite à un cas d'une intrusion où le pirate aurait réussi à voler des numéros de carte stockés dans des systèmes non sécurisés.

Dès lors, il nous est facile de conclure que même si la loi française ne parle pas du standard PCI DSS, ses exigences principales sont quant à elles bien obligatoires.