File encryption solution.

[sergav]

I am looking for a solution for our system to satisfy PCIDSS 3.4


One of the problem identified is we use single files storage on Microsoft servers to store and exchange end-of-day files with our customers.
Files often contain some cardholder data.
Files are packed to either zip or arj archives. Where some of them encrypted somehow. (does not really matter how)
The daily number of files we exchange with customers is about 200+
We used to keep them for a year a least available at same location for dispute resolution.
Clients use FTP protocol to upload or download files
Also, file are available via MS network for our local offices in different countries.
We use home grown application to move the files between this storage and our processing host system which manages transfer and packaging on scheduled time.


I do not worry about file transmitting at this point. But more about how we store the data.

My first idea was to remove files within a "business day". But each file has it is own requirements to be available. And it becomes very difficult and expensive to setup such rules for all files. And then maintain it later on.

Then I come up with idea to encrypt all files on disk level on folder level and somehow to link ftp user id with user/password of this folder/disk encryption mechanism. This way some add-in embedded to FTP-server would decrypt a file on demand before download when a customer initiates file download. From customer side there will be no impact. And this is great benefit here! But I am not sure if I can do so and such. From another side I know the disk encryption does not really help here

Does someone has any better idea or solution for file/folder/disk encryption?

Another question is that I am not sure if accessing via MS netwrok should be logged according to Req. 10. If so there is another gap I need a solution for.

Thank you for any advice.

[jbhall56]

One of the problem identified is we use single files storage on Microsoft servers to store and exchange end-of-day files with our customers.
Files often contain some cardholder data.
Files are packed to either zip or arj archives. Where some of them encrypted somehow. (does not really matter how)
The daily number of files we exchange with customers is about 200+
We used to keep them for a year a least available at same location for dispute resolution.
Clients use FTP protocol to upload or download files
Also, file are available via MS network for our local offices in different countries.
We use home grown application to move the files between this storage and our processing host system which manages transfer and packaging on scheduled time.



First, let's talk about your existing processes.

On the good side, you are encrypting your archives that contain cardholder data (CHD). However, it is important to know how your archive files are encrypted. If they are encrypted with AES, you have key management procedures and keys are changed at least annually, then you will have met the encryption requirements. I would recommend that you encrypt ALL of your archives just so that you are consistent and can say that they are all encrypted.

If the files are encrypted, you can retain the files for however long your business cycle requires. However, justifying retention for a year because of disputes is not justification since disputes must be filed within 90 days to the merchant. I could see justification for 180 days of retention, but anything longer than that is not justified by disputes alone. We have clients that justify retentions for up to 11 years due to US regulatory requirements and US State laws, but most only have retentions for one to two years. I would recommend that you document all of your business reasons for retaining these files for one year. You will also have to consult your company's legal counsel to make sure your retention policies do not violate any laws in any other countries. This will not be an easy juggling act if you have to work between the US, EU, Asia, etc. as they all have different requirements.

On the bad side.

Your CHD does not appear to be encrypted during your daily processing cycles. This is where file/folder level encryption can be used. But be careful. If you encrypt the data using EFS or similar and all your users still have access to decrypt the files, then you have NOT created an acceptable encryption solution. You must somehow restrict access to decrypt CHD and restrict/monitor access to the CHD.

You appear to be using regular FTP for transmittal of files containing CHD. While you encrypt your files that are transmitted, it is not done consistently at the moment so it is possible that CHD is transmitted in 'clear text'. That said, your customers are uploading files that may or may not (most likely) be encrypted. So, you should implement some form of secure FTP just as added security for downloads and to ensure security for uploads.

In regards to your custom developed system that moves the files around. As long as it is not decrypting the data and cannot decrypt the data, it is of no concern. It needs to be validated to ensure it does not have access to decrypted CHD. If it does have access to decrypted CHD, isolate those modules from the rest of the application and restrict access to those modules both on the development and production side of your environment.

My first idea was to remove files within a "business day". But each file has it is own requirements to be available. And it becomes very difficult and expensive to setup such rules for all files. And then maintain it later on.

If may not be as expensive as you might think. I think you need to do more research on this as there are a number of storage management solutions that could be effective in your environment.

Then I come up with idea to encrypt all files on disk level on folder level and somehow to link ftp user id with user/password of this folder/disk encryption mechanism. This way some add-in embedded to FTP-server would decrypt a file on demand before download when a customer initiates file download. From customer side there will be no impact. And this is great benefit here! But I am not sure if I can do so and such. From another side I know the disk encryption does not really help here

As you point out, EFS at the disk level on a server is pointless as servers are always running, so an EFS volume is always decrypted. EFS at the disk level is only useful for portable systems such as notebooks or systems that are shutdown daily or more often.

Another question is that I am not sure if accessing via MS network should be logged according to Req. 10. If so there is another gap I need a solution for.

You are correct, you have a gap that needs to be addressed. Again, there are a number of solutions avialable that can help you meet this requirement.

[sergav]

Thank you very much Jeff. Your post covers most of my concerns with regards to this issue.

According to PCIDSS 3.4.1b the EFS data recovery keys should be stored securely. Best way is to store them on removable media. With the solution above I assume files to be decrypted on-fly, by FTP download request. Remote system will provide ftp user/password only to initiate the decryption. Can it be acceptable by PCIDSS?

[jbhall56]

You must ensure that the data stays encrypted during transmission. In order to accomplish that in your existing environment, you will need to use a secure FTP (SFTP) solution. The simplest solution is to use SSH to connect and provide a secure connection, then initiate FTP over the secure connection. Globalscape has a Secure FTP solution that is used by a number of organizations that we assess. It supports SFTP, HTTPS and SSH for securing transport.