In Guide to PCI DSS Compliant File Transfers - Part 1 you gained a basic understanding of PCI DSS, the data it is intended to protect and how to assess the scope of a PCI compliant implementation.
We're now ready to discuss the 12 general requirements comprising the Payment Card Industry Data Security Standard, particularly as they relate to file transfer systems. Because these are the requirements on which PCI DSS compliance assessments will be based on, your compliance activities will naturally be aimed at putting these requirements in place.
For a more detailed list of requirements along with the corresponding testing procedures assessors are supposed to follow in validating whether the requirements are in place, download the corresponding PCI DSS documents, Version 3.0.
1. Install and maintain a firewall configuration to protect cardholder data.
The purpose of a firewall is to control computer traffic going between your internal network and untrusted (external) networks as well as traffic going into and out of sensitive areas (e.g. the cardholder data environment) within your network. It should be able to block transmissions that don't meet specified security criteria.
Connections between networks that don't belong to your organization and the file transfer server in your CDE should be restricted. Only those inbound and outbound file transfers that are absolutely necessary for the CDE should be allowed.
In addition, there should be no public access between the Internet and any file transfer server in your CDE. This may entail setting up a DMZ.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
I'm sure you've installed enough software applications to know that many of these products come with default usernames and passwords which you normally use to gain initial access inside. These default passwords are mostly the same for all copies of the same product, so other users who may have tried them know what the default passwords are.
Some of these default usernames and passwords are even shared and listed in rogue forums frequented by cyber criminals and other malicious individuals.
Indeed, people who have malicious intentions can easily acquire default login credentials for your system components and try getting into your system with them. By changing default passwords before deploying your file transfer system into your network, you can prevent this kind of attack from succeeding.
3. Protect stored cardholder data.
To ensure the confidentiality and security of cardholder data, you need to employ a combination of security-motivated data storage policies and technologies. For instance, you can practice not storing cardholder data in your file transfer server at all unless absolutely necessary.
For those cardholder data that you really need to store, you can apply storage, retention and disposal policies that include:
imposing a maximum limit on the storage size and retention time that is consistent with legal, regulatory and business requirements;
a regular schedule for identifying cardholder data that exceed retention limits;
procedures for secure disposal; and
encryption with key management.
4. Encrypt transmission of cardholder data across open, public networks.
When transmitting sensitive information like cardholder data over the Internet, it is not safe to use plain FTP. FTP transmissions are in plain text, so data can be easily read by anyone with packet capturing capabilities. FTP is also susceptible to brute-force, spoofing, and bounce attacks. It is better to use secure file transfer protocols like FTPS or SFTP, which employ SSL or SSH and hence are able to encrypt data during file transfers.
5. Protect all systems against malware and regularly update anti-virus software or programs
Because a lot of users will be uploading new files to your file transfer server, perhaps on a daily (or even hourly) basis, it is going to be highly likely that some of those files will be infected with viruses. It is therefore imperative to scan your file transfer server regularly with an anti-virus software in order to avoid any virus-related incident. Viruses can corrupt files, rendering them unusable, or even compromise the security of files containing cardholder data.
New viruses are created everyday. Therefore, in addition to regular scans, your anti-virus database should also be updated regularly so that it can detect the latest virus signatures.
6. Develop and maintain secure systems and applications.
There is no such thing as a running, functioning system that is 100% secure. This applies to file transfer systems too. Malicious individuals always try to find weak points to exploit. That is why, for security-conscious software vendors, making security improvements to their products is a never-ending exercise.
However, if you don't implement the latest patches or upgrades released by your vendors, you won't be able to take advantage of the latest security enhancements to your system and it can remain exposed to old (and supposedly identified) vulnerabilities.
7. Restrict access to cardholder data by business need-to-know.
Users should be granted access rights based on the principle of "least privilege" and "need to know". In turn, assignment of those privileges should also be based on those users' job classification and function. This is known as role based access control (RBAC). In most cases, you first define what privileges - based on job classification and function - should be granted to certain roles. And then, once you start creating a new user, you can assign an appropriate role to that user.
If your file transfer server has to store cardholder data, it would be best to limit the storage of this information to certain directories. That way, you can then grant access to those directories only to those users whose roles include functions that would require them to handle cardholder data.
8. Identify and authenticate access to system components
When you assign a unique ID to each person who is granted access to your file transfer system, it ensures that users can be held individually accountable for their actions during the course of their login session. As a result, it would be easier for you to implement procedures that will enable you to trace and investigate activities of each person if ever a data incident occurs.
In addition to the assignment of unique IDs, the details of this requirement also require you to employ at least one authentication method for local access (this includes access from within your internal network) and two-factor authentication method for remote access (access from outside your internal network).
9. Restrict physical access to cardholder data.
The greater the number of individuals who have physical access to disks in your file transfer system, the higher the risks will be to cardholder data stored there. To mitigate those risks, you should have controls and policies that will limit and monitor physical access to your file transfer server. Video cameras, visitor logs, and door controls are just some of the security measures you can employ on-site.
10. Track and monitor all access to network resources and cardholder data.
Your file transfer system should have a logging mechanism that will enable you to track user activities. This will allow you to prevent, detect, or minimize the impact of a data compromise. Logs are more effective if the information they hold can be associated with individual users. That way, it would be possible to zoom in on a particular user and trace his/her previous activities in your file transfer system.
11. Regularly test security systems and processes.
New technologies sometimes bring in new threats to your file transfer system. What's more, malicious individuals constantly try to find existing but unidentified vulnerabilities they can exploit. To mitigate risks brought about by these constantly evolving threats and vulnerabilities, you need to monitor and conduct regular tests to your security systems and processes. Security systems and processes have to reflect the kind of threats present in your environment.
12. Maintain a policy that addresses information security for all personnel.
In any security endeavor, you shouldn't always rely solely on the security tools or technologies on hand. No matter how advanced your security tools are, if the people in your organization don't follow best practices that complement them, those tools won't be effective.
For example, even if you use the strongest encryption algorithm available to protect cardholder data, if your end users refuse to encrypt their files, you won't be able to achieve the level of security you want.
Sometimes, however, the reason why there are often disconnects between security policies, end users, and security tools, is because the security tools are not user friendly enough. If your file transfer system supports configurations that would ease the burden from your users or reduce the number of steps they'd have to perform to maintain your ideal level of security, then by all means, configure it that way.
That was the last requirement under PCI DSS. You must however note that each requirement actually has a number of items underneath it. In fact, taken together, there's quite a number of sub-requirements in there.
If the file transfer system you're currently using doesn't support enough features to help you meet the requirements specified in those items, you may be forced to bring in additional technologies or applications. That can complicate things because you'll then have to configure those applications individually to make sure they comply with PCI DSS requirements themselves.
Furthermore, you may have to conduct system integration in order to make those applications work together.
It would therefore be best to implement a file transfer system that already meets most if not all of the requirements. That way, you can minimize or eliminate complex system integration activities and simplify administration.
This is where JSCAPE MFT Server can help. In Part 3, we'll discuss the specific PCI DSS sub-requirements that affect data/file transfers and explain how JSCAPE MFT Server can be used to satisfy them. To read that, go to Guide to PCI DSS Compliant File Transfers - Part 3.