Cardholder data is some of the most sensitive data around. Make sure you know the requirements you need to meet to ensure your file transfers are PCI-compliant.
In our prior blog post, we reviewed HIPAA regulations and how our file transfer software products, SFTP Gateway for AWS and SFTP Gateway for Azure, satisfies these requirements for healthcare companies who need to move their files to Amazon S3 and Azure Blob Storage.
Financial companies face similar regulatory requirements when handling customers’ payment data.
So we continue our regulatory theme and review what’s necessary to comply with the Payment Card Industry Data Security Standard (PCI DSS) and to whom these regulations apply. We’ll also go over how our SFTP Gateway products meet these requirements.
Ready to roll? Let’s go.
Overview of PCI DSS
Cardholder data – any personally identifiable information associated with a person who has a credit or debit card – is some of the most sensitive data around. If malicious actors get hold of your cardholder data, they can ruin your financial standing instantly.
That’s why PCI DSS was created. According to the PCI Security Standards Council, PCI DSS was developed to “encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally.”
PCI DSS provides a set of security requirements and assessment procedures whose purpose is to protect cardholder data. If you’d like some light reading, you can download all 139 pages of PCI DSS requirements here. It’s riveting stuff.
Who is impacted by PCI DSS?
PCI DSS applies to all entities involved in any way with payment card processing.
This can include:
- Merchants, like your local bagel store
- Payment processors, like the Square register your local bagel store uses to accept your credit card payment, or online payment processors like Stripe and PayPal
- Acquiring banks, banks that create and maintain merchants’ bank accounts, such as Bank of America or Chase
- Issuing banks, banks that offer credit cards to consumers, like Bank of America and Chase (these banks both issue and acquire)
- Service providers who control or could impact the security of cardholder data, which may include companies who provide managed firewalls, hosting providers, and other similar organizations
- All other entities that store, process or transmit cardholder data and/or sensitive authentication data
Basically, any company that comes remotely close to cardholder data needs to be cognizant of and adhere to PCI DSS.
Defining cardholder data and sensitive authentication data
What exactly is cardholder data and sensitive authentication data?
Cardholder data includes:
- Primary account number (PAN) for the credit or debit card
- Cardholder name
- Expiration date
- Service code (a three-digit number that identifies the types of services for which the cardholder can access with this card)
This cardholder data can be stored by your company or the third-party providers you work with, but the PAN must be rendered unreadable, similar to how only the last four digits of your credit card show up on a receipt.
Sensitive authentication data includes:
- Full track data – the data on your card’s magnetic stripe or chip
- CAV2/CVC2/CVV2/CID – the extra digits on your credit card that are used for additional authentication (three digits for Visa and Mastercard, four for American Express)
- Personal Identification Numbers (PINs)
You’re not allowed to store sensitive authentication data after authorization, even if it’s encrypted. You may be allowed to store this data prior to authorization, but you will have to check with your acquiring bank or payment brand (such as Visa or American Express) to better understand any requirements.
PCI DSS Requirements
PCI DSS has 12 primary requirements that you need to meet in order to be compliant, which are listed below and will be reviewed in more detail.
Under these 12 requirements are many sub-requirements. We won’t review all of these sub-requirements in detail; if we did, this blog post would be really, really, really, really, really long. But feel free to review them on pages 20-115 of this document (PDF).
1) Install and maintain a firewall configuration to protect cardholder data
Firewalls and routers are key components of your architecture that manage access into and out of your overall network and sensitive areas within your network (such as databases that contain cardholder data).
These components are your company’s first line of defense to intruders and are imperative in blocking unwanted access to your network. Establishment of configuration standards and procedures will help to ensure that the security of your customers’ payment data remains strong.
2) Do not use vendor-supplied defaults for system passwords and other security parameters
No kidding!
No matter what kind of software you use, you should always change vendor-supplied default credentials to secure usernames and passwords, or whenever possible, SSH keys. Default accounts should also be removed or disabled before systems or software are installed on your network.
Malicious individuals, whether they are external hackers or rogue internal employees, often use vendor default settings to access and compromise software systems. Thus, you need to be diligent in making sure that these default accounts and credentials are deleted or changed.
3) Protect stored cardholder data
Obviously, this is a big one.
The first thing you can do to protect cardholder data is to minimize the storage of it in your systems.
You can create policies that limit the amount of cardholder data stored and the time that it is retained to only what you need to meet business requirements. You can also create processes to securely delete data when it’s no longer needed.
For any cardholder data that needs to be stored, you should protect it with database encryption, proper cryptographic key management, and documentation of all security protocols.
4) Encrypt transmission of cardholder data across open, public networks
In addition to encrypting cardholder data in your internal networks, you have to make sure that this data is encrypted when traveling across public networks so malicious actors can’t intercept and tamper with the data.
Secure transmission of sensitive data requires a secure file transfer protocol, trusted keys and certificates, and applicable encryption strength.
FTP won’t cut it here. You’ll have to make sure you use SFTP or FTPS to transfer your files.
And you’ll need to verify that keys and certificates are trusted, stored, and managed properly.
5) Protect all systems against malware and regularly update anti-virus software or programs
Nasty viruses, worms, and other malware commonly enter IT systems via email, file transfers, and normal use of the internet on all devices. These viruses can wreak havoc on your IT systems, leading to security breaches, lost data, and decreased productivity.
Anti-virus software must be installed across all systems that are susceptible to malware, and updated frequently. Servers, desktops, laptops, and other devices must have anti-virus software to protect sensitive cardholder data.
For systems that may not be as susceptible to malware attacks, periodic evaluations should be performed to evaluate threats and see if any additional protections are necessary.
6) Develop and maintain secure systems and applications
Malicious actors won’t stop searching for vulnerabilities to attack, so security will always be an ongoing endeavor.
Therefore, you need to have a method of proactively monitoring the security of your systems and applications and evaluate vulnerabilities continuously. This will allow you to identify potential risks early and address them more quickly to avoid your cardholder data from being improperly accessed.
7) Restrict access to cardholder data by business “need-to-know”
While using technology such as firewalls and anti-virus software to protect cardholder data is very important, policies that restrict access to this data can be just as effective.
The more people who have access to sensitive data, the higher the risk that this data will be compromised. Thus, only those users who absolutely need access to sensitive data should be granted permission.
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on “need-to-know” and job responsibilities. “Need-to- know” is when access rights are granted to only the least amount of data needed to perform a job.
Roles and corresponding access rights need to be clearly defined, and many times access can be granted based on job title and function. If necessary, you can assign users access only to specific databases and directories to further protect sensitive data.
All of these access policies and information should be documented to avoid any confusion.
8) Identify and authenticate access to system components
Every user should be assigned their own user ID so you can review which users performed what actions during the time they were logged in. This allows you to see the audit trail in case any malicious activity occurs.
Username and passwords are the bare minimum. We prefer using SSH keys for authentication because they are much more secure.
User IDs should be kept up to date. Access should be revoked for terminated users, and those who have been inactive for an extended amount of time (e.g. 90 days) should be disabled.
And multi-factor authentication should be employed when accessing sensitive data from external networks.
Again, all of these authentication policies and information should be properly documented.
9) Restrict physical access to cardholder data
In addition to virtual access, physical access to sensitive data should be restricted appropriately.
Physical access to disks or other devices that house cardholder data can result in users removing or copying this data with malicious intent.
If you have on-premise servers, you should make sure that the data centers that house your database and storage servers are protected with badge systems and proper access rights. Onsite personnel and visitors should be properly authorized.
When working with a cloud service provider, you should inquire about their physical access policies to ensure that they are properly protecting sensitive data in their data centers.
Devices that interface with cardholder data should also be continuously monitored for tampering and unauthorized access.
10) Track and monitor all access to network resources and cardholder data
Working in accordance with requirement #8 (Identify and authenticate access to system components), all user activity should be tracked and logged in order to identify suspicious actions and trace it back to a specific user.
The minimum amount of information captured in these audit logs should include:
- User identification
- Type of event
- Date and time of event
- Origination of event
- Identity or name of affected data, system component, or resource
In turn, these audit logs need to be secured so they can’t be tampered with.
These logs should be reviewed periodically to identify malicious behavior, and these suspicious users should be dealt with accordingly.
11) Regularly test security systems and processes
Like mentioned earlier, security is a never-ending process, so your systems and processes should be frequently tested to ensure the highest level of security.
Wireless networks are some of the most insecure access points to your systems, so you should pay extra attention to ongoing monitoring and testing of these networks.
Vulnerability scans and penetration tests of internal and external networks should be performed frequently to identify any security weaknesses.
Hackers and other malicious actors are always finding new ways to breach systems, so you need to stay vigilant in ensuring the security of your cardholder data.
12) Maintain a policy that addresses information security for all personnel
A strong, crystal-clear security policy lets everyone know their role in securing sensitive cardholder data.
And this policy needs to be diligently applied to all personnel, which includes full-time, part-time and temporary employees, consultants, and contractors who are either physically on-site or have access to cardholder data.
Your security policy should include access and usage guidelines for all cardholder data-facing technologies and document all applicable devices, authorization mechanisms, acceptable uses of technology, a list of company-approved products, and more.
This policy should be reviewed and updated at least annually to keep current on new threats.
PCI compliance of SFTP Gateway
Our cloud file transfer products, SFTP Gateway for AWS and SFTP Gateway for Azure, are secure, pre-configured SFTP servers that use Amazon EC2 to save uploaded files to an S3 bucket, and Azure VMs to move files to Blob Storage, respectively. They are the easiest and most secure ways to transfer your files to the AWS and Azure clouds.
Let’s review each of the PCI DSS requirements to see how SFTP Gateway satisfies them.
1) Install and maintain a firewall configuration to protect cardholder data
AWS has EC2 security groups, which is a basic firewall that allows defined IP ranges access to specific ports. For SFTP Gateway for AWS, the current CloudFormation template lets you enter an IP address range that is allowed to communicate with the EC2 server. This protects you from port scans and brute force attacks from the internet at large. We also have documentation that shows you how to whitelist IP addresses for your EC2 security group.
(NEED INFO ON AZURE)
2) Do not use vendor-supplied defaults for system passwords and other security parameters
The way AWS and Azure handles access to their VMs is via an SSH (secure shell) key pair. So there is never a default password for first-time server login – you always use a key pair to access the server.
Thus, SFTP Gateway for AWS and Azure do not provide default credentials. Rather, the products require administrators to create SSH key pairs upon user creation. Creation of usernames and passwords can be done but we highly recommend SSH keys.
3) Protect stored cardholder data
When using SFTP Gateway, the type and amount of cardholder data that you transfer and store on S3 or Blob Storage is driven largely by your internal policies and security protocols.
But any data stored on S3 and Blob Storage is covered by the cloud provider’s PCI compliance and SSE encryption protocols. With SFTP Gateway, you can configure this option on a per-user basis, and all files uploaded by that user will be encrypted with SSE for both S3 and Blob Storage.
Cardholder data will be at rest on the Linux file system as well, and this needs to be encrypted. Unfortunately we can’t encrypt the root volume of the SFTP Gateway AMI because AWS does not allow this for AWS Marketplace products.
As a workaround, you can mount an encrypted EBS volume over your “/home” directory, and any files that users SFTP to the server will be stored at rest on the encrypted EBS volume. Click here to find out how to do this.
4) Encrypt transmission of cardholder data across open, public networks
Encryption in transit from your SFTP client (e.g. FileZilla) and SFTP Gateway is handled by the SFTP protocol. We use the default OpenSSH implementation for both the AWS and Azure products.
We disable passwords by default, since they are susceptible to brute force attacks. Instead, like mentioned earlier, SFTP Gateway lets you generate an SSH key pair when you create each user.
Uploading files from SFTP Gateway to S3 and Blob Storage is protected by HTTPS.
5) Protect all systems against malware and regularly update anti-virus software or programs
SFTP Gateway is built from Amazon Linux, so you have a good starting point for baseline security. We leverage the built-in OpenSSH and AWS SDK / CLI, so you can keep up with security with operating system updates.
But you still have to be vigilant on your end.
If you use Linux, you could run periodic Nessus scans to see if there are vulnerabilities or missing patches.
If you use Windows, be sure that your anti-virus and anti-malware software is up to date.
6) Develop and maintain secure systems and applications
We continually work to improve the security of SFTP Gateway, using the latest versions of OpenSSH and the AWS SDK / CLI. You can keep your SFTP Gateway instances recent via yum updates.
On your end, you can supply a CIDR range to limit who has access to your SFTP server.
And while S3 access is pretty open by default, you can use IAM to restrict access to your S3 buckets to improve your security posture.
Need to easily and securely transfer files to Amazon S3? Click here to check out SFTP Gateway on the AWS Marketplace!
7) Restrict access to cardholder data by business “need-to-know”
SFTP Gateway is an AMI product, so only the owner of that AWS account has access to the data. Thus, we can’t see any of your data! This is better than a shared hosting SFTP service, where you have to worry about the system administrators of that third-party service having access to your data.
SFTP Gateway users are local Linux accounts that leverage Linux home directories, therefore they do not have access to any files except the ones they upload themselves. For example, if you work with multiple partners who share files with you within a single SFTP Gateway instance, Partner A can’t see anything uploaded by Partner B.
Furthermore, these SFTP users no visibility into S3. SFTP Gateway denies SFTP users shell access, so they can’t query S3 from the CLI either.
8) Identify and authenticate access to system components
With SFTP Gateway, each SFTP user is provisioned their own user account and set of SSH keys by default, and password authorization is disabled.
Both SSH and SFTP attempts are logged to a file (/var/log/secure) so all access can be tracked and audited.
And we have a script, “deletesftpuser”, which de-provisions SFTP users.
Unfortunately, SFTP Gateway does not have multi-factor authentication at this time.
9) Restrict physical access to cardholder data
SFTP Gateway uses Amazon EC2 and S3, so any physical access to cardholder data falls under AWS’ shared responsibility model.
In this model, AWS takes care of all physical security, and it’s up to us to maintain security for the SFTP Gateway product, and you to secure your access points to the product.
10) Track and monitor all access to network resources and cardholder data
As mentioned above, both SSH and SFTP attempts are logged to a file (/var/log/secure) so all access can be tracked and audited.
This log file includes:
- The user name
- Timestamp
- Source IP address
- The action taken and the object taken action upon, such as changing a specific directory
Thus, the log file meets all necessary tracking and monitoring requirements of PCI DSS.
Additionally, in our upcoming version 2.0 release, the log files will be uploaded to CloudWatch to prevent tampering.
11) Regularly test security systems and processes
As mentioned in requirement 6 (Develop and maintain secure systems and applications), we use the latest versions of OpenSSH and the AWS SDK / CLI to ensure the most up-to-date security.
And while we don’t regularly run Nessus scans on our product, many of our customers do to ensure the highest level of security for their instances.
12) Maintain a policy that addresses information security for all personnel
Policies and procedures are really important in setting the security tone for your organization and ensuring that all employees and contractors understand their role in maintaining security of your cardholder data.
So while we can’t write these policies for you, we do provide tutorials, suggestions, and support to help you achieve the highest level of security for your SFTP Gateway instance.
Conclusion
There’s a lot that you have to do to be compliant with PCI DSS. And rightfully so, because cardholder data is some of the most sensitive data around.
With respect to file transfers, you need to ensure that cardholder data is protected at rest and during transfer. Encryption, secure access and authentication practices, and ongoing review of security policies and procedures are essential to protection of this sensitive data.
SFTP Gateway directly meets many of the PCI DSS requirements and also allows you to take necessary steps to achieve compliance for those requirements it doesn’t directly satisfy.
If you’re looking for an easy, secure way to transfer your files to Amazon S3, give SFTP Gateway a try.
Like this post? It likes you too. 🙂 Please share it using the share buttons to the left. Then join our mailing list below, follow us on Twitter @thorntech, and join our Facebook page for future updates.
