Using Managed File Transfer w/ PCI cardholder data

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?