cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor I

PCI-DSS

Hello pals,

 

I'm using an e-commerce application which collects Credit card data and save in a database.

So far it's fully compliant and following PCI-DSS standards. 

 

But this credit card data is being sent from an internal app server to a third party payment processing company by calling 3rd Party REST API. There is no human interface.It happens internally.

currently the data is being passed in a plain text format, card number as is,  but the communications between my app server to 3rd party API is over https.

 

I'm thinking if  obfuscation/anonymization/tokenization/masking can be used. Not sure if really required as per PCI-DSS . Does it fall under PCI-DSS compliance ? What is best way to handover Credit card data to 3rd party in this scenario.

 

i'll be grateful for your suggestion

 

Thanks

 

 

 

Mouli, CISSP
1 Solution

Accepted Solutions
Newcomer I

Re: PCI-DSS

Hi Mouli,

 

If I understand this correctly, you have a payment system that handles payment cardholder data (CHD) including the primary account number (PAN) and some other elements of card account data. Your app server, on your internal network, connects to your processor's Internet-facing REST API over HTTPS with strong cryptography (TLS 1.2 or higher, with strong ciphers). 

 

Inslde the HTTPS tunnel, the CHD is plain text.

 

Your question is whether PCI DSS requires you to provide additional protection to the CHD via one of the methods you listed?

 

PCI DSS Requirement 4 requires that CHD be protected while in-transit via strong encryption, and that only trusted certificates be accepted. It is perfectly acceptable for you to send plaintext CHD over a strongly-encrypted tunnel, as long as you are also validating the TLS certificate being presented by the processor's API to confirm that you are actually connecting to the trusted site that you are expecting to.

 

Obfuscation is not a security control, and would not apply in any situation.

Anonymization, which could be accomplished via rendering the CHD unreadable via hashing with a strong cryptographic hashing algorithm (such as SHA-256) with a unique salt, would certainly protect the CHD, but would also render it unreadable by the processor.

Tokenization is not typically applicable in this context. Usually tokenization comes into play when you are looking for a way to simplify your PCI DSS compliance tasks by storing tokens instead of actually storing CHD. This works when the tokenization has been done by a third-party, for example, many processors will return a token in an authorization response that can be stored instead of the PAN. Then, when the merchant needs to process a recurring charge, they can submit the token instead of a PAN (the stored token is not considered to be CHD because the merchant does not have the means of de-tokenizing it.

Masking does not apply in this context. In PCI teminology, masking is a means of rendering CHD unreadable *when displayed or printed*. The term for removing digits other than displayed/printed is "truncation". Truncation, like masking, would not help in this case, as it would render the CHD unreadble by the processor.

 

I also wanted to make sure that you were aware that any system that stores CHD, such as a database, must not be directly connected to the Internet.

 

Jim

Jim Scardelis, CISA, CISSP, PCI 3DS, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, MCSE

Any views or opinions contained in this communication are solely those of the author, and do not necessarily represent those of any organizations or entities the author may be associated with.
2 Replies
Newcomer I

Re: PCI-DSS

Hi Mouli,

 

If I understand this correctly, you have a payment system that handles payment cardholder data (CHD) including the primary account number (PAN) and some other elements of card account data. Your app server, on your internal network, connects to your processor's Internet-facing REST API over HTTPS with strong cryptography (TLS 1.2 or higher, with strong ciphers). 

 

Inslde the HTTPS tunnel, the CHD is plain text.

 

Your question is whether PCI DSS requires you to provide additional protection to the CHD via one of the methods you listed?

 

PCI DSS Requirement 4 requires that CHD be protected while in-transit via strong encryption, and that only trusted certificates be accepted. It is perfectly acceptable for you to send plaintext CHD over a strongly-encrypted tunnel, as long as you are also validating the TLS certificate being presented by the processor's API to confirm that you are actually connecting to the trusted site that you are expecting to.

 

Obfuscation is not a security control, and would not apply in any situation.

Anonymization, which could be accomplished via rendering the CHD unreadable via hashing with a strong cryptographic hashing algorithm (such as SHA-256) with a unique salt, would certainly protect the CHD, but would also render it unreadable by the processor.

Tokenization is not typically applicable in this context. Usually tokenization comes into play when you are looking for a way to simplify your PCI DSS compliance tasks by storing tokens instead of actually storing CHD. This works when the tokenization has been done by a third-party, for example, many processors will return a token in an authorization response that can be stored instead of the PAN. Then, when the merchant needs to process a recurring charge, they can submit the token instead of a PAN (the stored token is not considered to be CHD because the merchant does not have the means of de-tokenizing it.

Masking does not apply in this context. In PCI teminology, masking is a means of rendering CHD unreadable *when displayed or printed*. The term for removing digits other than displayed/printed is "truncation". Truncation, like masking, would not help in this case, as it would render the CHD unreadble by the processor.

 

I also wanted to make sure that you were aware that any system that stores CHD, such as a database, must not be directly connected to the Internet.

 

Jim

Jim Scardelis, CISA, CISSP, PCI 3DS, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, MCSE

Any views or opinions contained in this communication are solely those of the author, and do not necessarily represent those of any organizations or entities the author may be associated with.
Contributor I

Re: PCI-DSS

Thank you Jim
Mouli, CISSP