card.io e PCI DSS v3.0

4

Ho svolto ricerche per un po 'di tempo, ma non riesco a trovare una risposta a questa domanda:

Se toccherò i dati del titolare della carta in qualsiasi modo, ho bisogno della certificazione PCI DSS v3.0 SAQ A-EP, che è abbastanza complessa da ottenere. Quindi l'alta popolarità delle pagine di pagamento ospitate: quando le utilizzo, ho solo bisogno di PCI DSS v3.0 SAQ A (senza EP). Per una rapida consultazione, vedi link

La popolare libreria card.io semplifica l'inserimento dei numeri delle carte di credito da parte dell'utente, ma lo farò sempre "touch" "i dati se utilizzo questa libreria, prima di inoltrarla a qualche servizio Web sicuro per la tokenizzazione.

Ora, a quanto mi risulta, ogni applicazione che utilizza card.io deve essere certificata PCI DSS 3 SAQ A-EP dal 1 ° gennaio 2015, quindi questo significa che molte applicazioni potrebbero non essere certificate altro se non sono stati aggiornati a ...- EP? O mi mancano informazioni importanti qui?

    
posta user37088 19.03.2015 - 14:52
fonte

1 risposta

7

If I touch card holder data in any way, I need PCI DSS v3.0 SAQ A-EP certification

No, non è vero . Se si toccano i dati del titolare della carta, è necessario SAQ B, C o D. Il SAQ A (e A-EP) è solo per i commercianti che "non toccano, elaborano o memorizzano i dati dei titolari di carta" come per il tuo link convenzionato .

The popular libary card.io makes it easy for the user to put in their credit card numbers, but I will always "touch" the data if I use this library

Una corretta. L'uso di card.io sembra non renderlo idoneo per SAQ A o A-EP.

Dico "appare" perché il sito di card.io dice "card.io non memorizza o trasmette numeri di carta di credito". Ma è una specie di crock: scattano una foto e la trasformano in dati PAN per la tua applicazione. Che l'applicazione deve archiviare o trasmettere, altrimenti non c'era motivo di scansionarla. Se si scannerizzava una card con card.io e si cancellavano immediatamente i dati dalla memoria senza leggerli, probabilmente si eseguiva ancora il controllo di PAN di 'elaborazione' dati ed essere soggetti al DSS.

Quindi è un po 'fuorviante dire che "non memorizzare o trasmettere numeri di carta di credito" senza dire "ma se ci usi, lo farai, punto".

Now, my understanding is that because of this, every application that uses card.io has to be certified PCI DSS 3 SAQ A-EP from 1st January, 2015

No, ogni commerciante che utilizza card.io dovrà essere certificato SAQ C o D, proprio come avrebbe dovuto fare in passato con DSS 2.0.

L'unica eccezione possibile potrebbe essere se hai scritto e distribuito un'applicazione di pagamento che ha utilizzato card.io e inviato i dati PAN direttamente al tuo processore su un iFrame ospitato da A-EP approvato. Grande! Puoi fare il SAQ A-EP! Ma probabilmente dovresti ottenere la certificazione PA-DSS per la tua applicazione per farlo funzionare. Non penso che sia un buon compromesso.

so does this mean that many applications out there may not be certified any more if they haven't upgraded to ...-EP?

Le applicazioni non certificano sotto i questionari SAQ, commercianti fanno. Qualsiasi commerciante che utilizza card.io in passato non si sarebbe qualificato per il SAQ A in passato, e non sarà idoneo per A o A-EP ora.

Il vero cambiamento che rappresenta A-EP è per i commercianti che, in DSS 2.0, si sono qualificati per SAQ A con soluzioni non-iFrame (Javascript o reindirizzamento trasparente). SAQ A-EP disegna una linea arbitraria e illogica e dice che iFrame è più sicuro di quei due. I commercianti che usano Javascript o reindirizzamento trasparente finiranno in un SAQ A-EP più grande (139 domande) mentre quelli che usano iFrame possono rimanere in SAQ A (14 domande). Detto questo, la linea che è stata tracciata è così illogica che mi aspetto di vedere la continua ridefinizione andare avanti.

    
risposta data 19.03.2015 - 15:32
fonte

Leggi altre domande sui tag