cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Using Managed File Transfer w/ PCI cardholder data

Level 10

The PCI Data Security Standards define the security practices and procedures that govern the systems, services, and networks that interact with cardholder or sensitive payment authentication data. The environment in which cardholder data flows is defined as the cardholder data environment (CDE) and comprises the “people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data”. 

While some PCI deployments are simple, such as a single Point of Sale terminal directly connected to a merchant authority, other deployments, whether interacting with older systems, or deployments that have store and forward needs, or use cases where an acquirer of cardholder data needs to transmit or share data with another service provider, are more complicated. You may find yourself needing a solution that allows you to transfer cardholder data while maintaining PCI compliance.

When you need to move PCI data, whether within the CDE or for further processing outside of the CDE, you can use a managed file transfer (MFT) solution to accomplish this task. In this situation, you need to ensure that the MFT complies with all aspects of PCI DSS.

The main requirement governing data transfer is Requirement 4, which states that cardholder data must be encrypted when transmitted across open, public networks. More specifically the encryption implementation must ensure:

1. Only trusted keys and certificates are accepted.

2. The protocol in use only supports secure versions and configurations.

3. The encryption strength is appropriate for the encryption methodology in use.

For file transfer, the usual transports are either FTP over SSL, which runs the traditional FTP protocol tunneled through an SSL session, or HTTP running over SSL/TLS. Occasionally SSH2 is needed and may be used in situations where it is not possible to set up bi-directional secure transfers, or when only an interim transfer is needed.

A properly configured managed file transfer solution will enable users to:

1. Automatically transfer cardholder data for further processing

2. Support ad hoc secure transfers

3. Generate onetime use secure transfer links

However, care must be taken to adhere to new PCI DSS 3.2 authentication and encryption requirements, as well as to ensure cardholder data is kept only for the time necessary to achieve the legitimate business need. We will address each of the new PCI requirements to ensure you can safely continue to use your managed file transfer solution.

Multifactor Authentication

PCI DSS 3.2 clarifies that any administrative, non-console access to the cardholder environment must support multi-factor authentication. This means multiple passwords or passwords plus security questions are no longer valid authentication protocols.

For years web application and even SSH access has relied upon simple security questions, or even just user ID and password, to properly identify themselves to systems. Unfortunately as seen in the recent Yahoo data breach disclosure , security questions may be kept in the clear, and such questions are often chosen from a standard list.

From a PCI managed file transfer authentication requirements perspective, 3.2 multifactor authentication only impacts user to server initiated transfers, or administrative access to a server located in the cardholder data environment. If you are currently using either of these two scenarios with only password authentication, should plan for migration by February 2018.  You can read more about new PCI authentication requirements the PCI 3.2 changes blog post here:

Encryption

The changes to PCI 3.2 regarding encryption are more extensive than the authentication requirements. The most common transport layer encryption used for managed file transfer will depend upon SSL/TLS protocols to deliver the security for data in motion. Early versions of SSL/TLS have known vulnerabilities that make them unsuitable for ongoing use in managed file transfer according to the new PCI standard. Although the 3.2 requirements permit the use of SSL/TLS if properly patched, configured, and managed there is no need to use these older versions of SSL/TLS in a managed file transfer environment as most systems and browsers have been updated to support TLS 1.2 for some time. That said even when configuring your server to accept the TLS 1.2 protocol and above is still the matter of which cipher suites to select. TLS 1.2 supports over 300 cipher suites and not all of them are acceptable for use with cardholder data.

PCI DSS 3.2 does not directly specify the cipher suites to use with TLS, leaving the implementer with the following requirement “The encryption strength is appropriate for the encryption methodology in use” . PCI does provide additional guidance and points to NIST publication 800-52, which was last updated in April 2014. However, since that publication date several critical vulnerabilities have been found in the implementations of certain cipher suites used by SSL/TLS and additional vulnerabilities have been found in OpenSSL, which is a commonly used library. These include:

- Freak , which forces a downgrade to an exploitable version of RSA

- Drown , which relies upon a server supporting SSLv2 to compromise a client using TLS

- Five critical vulnerabilities in the OpenSSL implementation reported September 16, 2016

From NIST 800-52 the following cipher suites for TLS 1.2 servers are recommended:

• TLS_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Care must be taken to ensure that null ciphers, and lower grade encryption ciphers are not configured by default, as these ciphers can be used in Man in the Middle Attacks. To mitigate this risk, OWASP  recommends using a whitelist approach, which means either limiting your server to only use certain ciphers, such as those specified above, or if you cannot whitelist your cipher suites, ensuring that you disable weak cipher suites .

The cipher suite is not the only cryptographic element of your managed file transfer solution. The SSL/TLS server also needs a private key. The private key should be generated by a known Certificate Authority, in an X.509 or PKI certificate. Furthermore, in order to be PCI compliant your certificate should meet NIST SP 800-57 key management requirements. From a practical perspective OWASP recommends server certificates should:

1. Use a key size of at least 2048 bits

2. Not use wild card certificates

3. Not use SHA-1

4. Not use self-signed certificates

5. Use only fully qualified DNS names

NIST 800-57 provides detailed guidance on protecting private keys and from a PCI perspective the important elements of key management are:

Ensuring the integrity of the private key from:

1. Accidental or intentional reuse, modification, compromise

2. Exceeding the relevant cryptographic period (how long a private is expected to be in use)

3. Incorrect configuration of a private key

It may seem like overkill to be so focused on encryption protocols, cipher suites and private keys, however if the private key is compromised, as it was with the Sony PlayStation 3 , your entire system is now vulnerable.

Storing Cardholder Data

While there are no changes to requirements around storing cardholder data in PCI 3.2, if you do use managed file transfer you are storing cardholder data. Along with the technical guidelines on storing cardholder data , consider how you are going to mitigate the risk of accidental disclosure by removing any files containing cardholder data as soon as possible after the business use is completed. Having a policy that establishes data retention, secure destruction, and logging the execution of these activities will ensure you maintain PCI compliance.

There are other requirements associated with any system or solution that operates under PCI but the new requirements for PCI 3.2 focus on authentication and encryption. By working with your IT staff in advance and detailing your PCI use cases and requirements with a focus on authentication and encryption you can confidently deploy managed file transfer in your PCI environment.

Do you use file transfer solutions today?  Are you comfortable with the security they provide for Personally Identifiable Information?

15 Comments
MVP
MVP

Good write up although it is out of my normal swimlane.   I will have to go back and re-read it a few times to better understand some of it.

But to answer the question at the end, Yes we do use file transfers today and from the info I have the security is there with encryption.

Good read, sometimes the details matter a great deal, and in this case I think they do. Don't just set it and forget it.

Do you use file transfer solutions today? 

     Yes, for both financial and health related information.

Are you comfortable with the security they provide for Personally Identifiable Information?

     Comfortable? Never. Even if its fine today it might need improvements tomorrow. We do audit it (and other things) both internally and using independent contractors to help us on a regular schedule, and I know that all concerns get addressed. So I know that we are giving it the attention it needs, but I never get comfortable.

Level 13

I wish there was an easy way to manage certificates and certificate servers...pain in the butt.

Level 13

I so agree about managing certifcates and certificate servers... such a great big headache!!!!!!!!!!!!!!!!!!!!!!!!!!!

This is an environment in which a licensed, auditable, ASP that is expert in PCI compliance, may represent a simpler and easier solution than building this from scratch internally.  We've built it, it's quite different from our traditional internal environment, and I miss some of my traditional management tools' view into it.

Built from scratch tools are tough to manage sometimes. We don't have many, but the ones we do I end up sitting down and explaining what I can and can't tell them. Then I explain that anything else that might be needed the developers and I will need to talk about how to accomplish. In the case of file transfer, I am glad we bought something.

Network Engineers are tasked with being expert at everything to do with networking, then they are given insufficient budget with which to stay current or become certified, and theirs is the first department to which complaints are delivered.

When engineers comment that this process is irrational, a common response is "That's why you get paid the big bucks."

Uffda!

Level 16

Best practice is to encrypt the PCI data at the card reader itself.

Level 13

That is an excellent option...

Level 21

We struggle with this on a constant basis.  We manage PCI environments for clients and the responsibility matrix we have puts some aspects of the responsibility on the client and educating them on these concepts and making sure they are being responsible can be a real challenge.

Level 20

Seems these business to business connections could be ripe for problems.

MVP
MVP

inconceivable !!

Level 20

I suppose in that kinda case it probably would make sense for smaller operations to just outsource the communication to some managed cloud service provider skilled in actually do all the pieces that need done.  Leave to some smaller in house operation and there are going to be problems.

Level 20

Data on the move and at rest should always be encrypted.  These days it really should be in memory as well.

Level 20

This is all about Byron's situation!  I can only imagine what this matrix looks like and the back and forth over who's responsibility is what.  PCI is big business though... a lot of PCI processing companies out there.  I'm sure it's a huge challenge.