Overview
For the last couple of years, this is the first page you’d find when searching about PCI DSS compliant file transfers. Enough motivation for us to make sure this article stay as informative and as relevant as possible. So now that PCI DSS version 3.0 is out, we’ve made a few changes to get readers like you up to speed with the latest standard.
One of the key themes of PCI DSS (Payment Card Industry Data Security Standards) 3.0 is Education and Awareness. By improving education and awareness around payment security, the PCI Security Standards Council (PCI SSC) is hoping to enhance cardholder data security, facilitate broad adoption of consistent data security measures, and bring down the incidence of data security breaches. We’d like to do our little part in that regard.
We’ve framed this 3-part guide to help you:
- Understand and appreciate the importance of PCI DSS compliance in file/data transfer activities;
- Identify the specific PCI DSS requirements that affect data/file transfers; and
- Learn how to achieve PCI DSS compliance using JSCAPE MFT Server.
Whether you’re a merchant, processor, acquirer, issuer, service provider, or just about any entity involved in credit/debit card processing who transmits Account Data (defined below), you will find this guide a valuable resource for helping you achieve file transfer compliance with the Payment Card Industry Data Security Standard.
The need for PCI DSS compliant data transfers
Organizations who transmit certain kinds of credit/debit card data need to achieve PCI DSS compliant secure file transfers. And the reasons shouldn’t be purely for the sake of regulatory compliance.
While it’s true that penalties for noncompliance can be very costly especially in the event of a data breach (you’re looking at possible lawsuits, insurance claims, cancelled accounts, government fines, and payment issuer fines), there are other grave consequences that should also compel you to adopt a PCI DSS “mindset”. Allow us to elaborate.
PCI DSS compliance is really about securing credit/debit card information, a very valuable item in the cybercrime world. You see, identity thieves steal credit card data in order to carry out various fraudulent activities. Hence, these crooks will always have organizations who handle credit card data locked in their crosshairs. That can be a serious problem, as cyber attacks that compromise credit card data can in turn:
✘ Disrupt business operations (to give way to digital forensics and investigations);
✘ Result in possible lawsuits and fines;
✘ Destroy a company’s reputation;
✘ Erode customer confidence (if not customers themselves); and
✘ Drive potential customers away
By establishing a PCI DSS-compliant file transfer system, you can protect your data transmissions from those attacks and avoid the consequences that come with them.
How PCI DSS compliance protects your file transfers
File transfers are actually very common among certain organizations who handle credit card data. For instance, many retailers who accept credit cards not only store and process cardholder data. In most cases, those retailers also have to transmit the data either internally, among the company’s various departments, or externally, to merchant services, banking institutions, and payment processors, who may in turn need to exchange similar information among themselves.
Unfortunately, these data transfers are mostly carried out using totally insecure protocols (like FTP, Telnet, POP3, IMAP, or SNMP) and methods devoid of security elements (like encryption, strong passwords, authentication, anti-malware, etc.).
That’s where PCI DSS can help. By using PCI DSS requirements as guides, you can identify your vulnerabilities and know the remedies. Of course, the complete PCI DSS documentation is really designed for a comprehensive compliance activity that would typically encompass all of the system components in your organization.
What we’ve done in this article is zoom-in and tackle on the specific requirements that relate to data/file transfer systems. You should therefore use this article only as a supplement to your overall PCI DSS compliance activity.
What information does PCI DSS protect?
PCI DSS is aimed at protecting what the payment card industry calls account data.
The Account Data we are referring to consists of relevant payment card information such as the Primary Account Number (PAN); cardholder’s name; expiration date; service code; the full magnetic stripe data or its equivalent data on a chip; the Card Security Code (CSC) a.k.a. Card Verification Data (CVD), Card Verification Value (CVV or CVV2), Card Verification Value Code (CVVC), etc., which depends on the brand of the credit/debit card; and PIN/PIN block.
Information considered as Account Data can be grouped into two: Cardholder Data and Sensitive Authentication Data.
|
Cardholder Data |
Sensitive Authentication Data |
|
Primary Account Number (PAN) |
Full magnetic stripe data or equivalent data on a chip |
|
Cardholder Name |
CAV2/CVC2/CVV2/CID and so on |
|
Expiration Date |
PINs/PIN blocks |
|
Service Code |
|
Here’s where these information can be located on an actual card.
This image was taken from PCI-SSC’s document entitled “Payment Card Industry Data Security Standard – Navigating PCI DSS – Understanding the Intent of the Requirements“
The presence of PAN is crucial in determining whether cardholder data is subject to PCI DSS requirements. PCI DSS requirements apply whenever you store, process, or transmit PAN along with any (or all) other cardholder data (i.e., cardholder name, expiration date, and/or service code).
There are three main steps in achieving PCI DSS compliance. The PCI SSC (Security Standards Council) calls them Assess, Remediate, and Report.
Performing an assessment on your file transfer system entails identifying its vulnerabilities in relation to cardholder data; remediation refers to the risk mitigation activities that reduce or eliminate the risks associated with those vulnerabilities; and reporting involves compiling records required by PCI DSS and submitting them as compliance reports to the acquiring bank and all concerned global payment brands.
When to include your file transfer system in your scope of assessment for compliance
Before any effective assessment can be made regarding your compliance with PCI DSS requirements, you should first establish the scope of the assessment. That way, you’ll have an idea where the PCI DSS requirements should be applied. Narrowing down the focus of your compliance efforts will save you time, money and manpower not only during assessment but also during remediation and reporting.
To begin, all system components that belong to or are connected to your cardholder data environment (CDE) are covered by the PCI DSS requirements and hence should be part of your assessment. Your cardholder data environment consists of all people, processes and technology in your organization that store, process, or transmit cardholder data or sensitive authentication data.
System components, on the other hand, may refer to:
- Network components (firewalls, switches, routers, etc.)
- Servers (web servers, database servers, proxy servers, file transfer servers, etc.)
- Applications (all purchased and custom applications)
Thus if, after establishing your CDE based on what you have identified as the locations and flows of cardholder data under your care, you find that your file transfer system belongs to or connects to that CDE, then your file transfer system should be included in your scope of assessment.
∫
Even if your file transfer system isn’t normally used for transmitting cardholder data, that’s not reason enough for exempting it from your scope of assessment. For as long as your file transfer service is not isolated in a network segment separate from your CDE (through firewalls, routers, strong access control lists, etc.), there’s still a significant probability that cardholder data may be transmitted through it and hence it should still be included in your scope of assessment.
Note that virtualization components are also considered as system components. So if that particular file transfer system runs on a VM instead of a tangible server, PCI DSS requirements will still apply to it.
If the data you collect, store, process, and transmit are not just purely account data, then pinpointing the exact locations/flows of cardholder data and establishing your cardholder data environment can be time consuming. Later on in this article, we’ll share you a DLP feature that automates the process of locating cardholder data in a particular file transfer system.