[PCI-DSS] 4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.
[I]Examples of open, public networks that are in scope of the PCI DSS are:[/I]
[ul]
[li]The Internet,[/li][li]Wireless technologies,[/li][li]Global System for Mobile communications (GSM), and[/li][li]General Packet Radio Service (GPRS).[/li][/ul]
4.1.a Verify the use of encryption (for example, SSL/TLS or IPSEC) wherever cardholder data is transmitted or received over open, public networks
[ul]
[li]Verify that strong encryption is used during data transmission[/li][li]For SSL implementations:[/li][LIST]
[li]Verify that the server supports the latest patched versions.[/li][li]Verify that HTTPS appears as a part of the browser Universal Record Locator (URL).[/li][li]Verify that no cardholder data is required when HTTPS does not appear in the URL.[/li][/ul]
[li]Select a sample of transactions as they are received and observe transactions as they occur to verify that cardholder data is encrypted during transit.[/li][li]Verify that only trusted SSL/TLS keys/certificates are[/li][li]Verify that the proper encryption strength is implemented for the encryption methodology in use. (Check vendor recommendations/best practices.)[/li][/LIST]
Should the transmission of cardholder data in the local network be encrypted? Example DB<->application and application1<->application2.
Of course all applications and the DB are isolated with firewall from the internet. There is only limited access to the servers for some administrators over secure connection, and of course there is a web interface to the application server from Internet (through some kind of transparent proxy). The DB servers are not accessible from Internet directly.
The current standard does not specifically require encryption of local area network traffic containing sensitive card holder data. Right now only public network traffic (i.e., the Internet) and stored data must be encrypted. However, if you look at the last few compromises they have mostly been based on local area network sniffing of unencrypted traffic. Yes, malware was allowed in and, yes, data was allowed out - both of which are banned by PCI. In my opinion encrypting local area network traffic which includes sensitive card holder data should be a requirement.
Hello,
if the sensitive cardholder data which flows over the public network (eg. internet) is ENCRYPTED by means of strong cryptography, is it also necessary to apply req.4.1 ? and use SSL/TLS or IPSEC ???
Is there any deference in this scenario if the cryptogram contains of encrypted cardholder data (PANs, …) or contains of sensitive authentification data (PIN, CVC2,CVV2, …).
This is kind of a multi-faceted question regarding APIs: We plan to work with third party clients who would implement an API call we design and make available to them (practically, it would be used to interface with us so clients and their customers can browse inventory, make purchases, etc). In terms of the purchasing functionality of the API, it will obviously involve transmission of CHD. Aside from secure transmission of data over SSL (between the client machines and our side), do we need to address other areas like key encryption management (i.e. unique key for each client, etc)? Also, would these types of API calls put us in scope of PA-DSS? TIA!