Home page logo
/

pen-test logo Penetration Testing mailing list archives

Re: Faxing and PCI DSS compliance
From: "David M. Zendzian" <dmz () dmzs com>
Date: Mon, 28 Jan 2008 15:57:21 -0500

rajat swarup wrote:
On Jan 24, 2008 3:15 PM, jw <rx.jeff () yahoo com> wrote:
Well, let me be more specific.  Let's say your company
utilizes another company's service where you can
receive faxes via email in the form of PDF sent to
you.
This would fall under the section 12 requirement for contracts that require partners / service providers who handle card data for your company be PCI compliant and accept all PCI security requirements.

Which leads to the issue that card numbers are not to be emailed in clear-text. I.E. you can receive them via email, but only if encrypted. If they are put in PDF & emailed then both the service provider and the receiver are non-compliant (you can't say you didn't know, you signed up for the service knowing you were going to receive card #s:).
So let's say your customer faxes you full 16 digit cc#
with expiration on their regular fax machine.  What is
your company's PCI liability on this as that fax, with
cc info gets to you in the following manner:
A few things here. The fax needs to be classified as confidential and handled as your data retention policy dictates (assuming it is PCI compliant;). What this means is that it needs to be secured (clean desk / fax machine policy) and handled by those with appropriate job function to be able to see full card # (secured fax machine in accounting or other area set aside for receiving secure faxes). Plus it needs to be stored / archived properly and then when it is disposed of it needs to again follow your policy but it needs to be securely destroyed (cross cut / incenerate, whatever:).

customer fax cc# --> 3rd party fax service --> to your
company in PDF via email
See above
So in essence, should your company be liable for
non-compliance even though this is not something you
can control?

If your company is receiving card data on behalf of your customers, you are liable for all ways it gets to you. Claiming you didn't know or that it's out of your hands is not enough when there are secure solutions. ie don't use a fax service unless they can send PGP encrypted emails & securely purge the fax data when sent; otherwise get a real fax machine & secure it and instruct those who have access what it may contain and how to handle it appropriately (and yes training is a PCI requirement).

Plus, while a compromise might effect the fax service more in the press (unless your a bigger name than efax or whomever it is), it is your name in the press with the disclosure notice that will effect your relationship with your customers. You should always do your best to ensure everyone knows where card / financial / personal non-public information is within your company, how / where it is used and what risks there are for it (in fact PCI also requires an annual detailed risk assessment).

Good luck, but personally a phone line w/a $50 fax from staples is sometimes easier to deal with than trying to make some digital systems compliant.

David
The requirement 3 is about "sending" PAN and not about receiving.
Your responsibility would be to abide by all PCI requirements unless
you destroy the e-mails according to the PCI DSS requirements (i.e.,
military wiping stuff).
Requirement 3 deals with storage of card data, requirement 4 deals with the transmission of card data. Anywhere PAN is stored is required to be encrypted, and when transmitted across open-public networks it needs to be encrypted (ie web/email/db in internal network connections are not required to be encypted, web/email/db across internet/wireless/cell phone/etc are required to be encrypted).

The issue with storing card #s and section 3 with fax services is think about everywhere a fax is "stored" as it is received and processed digitally: inbound fax stored in queue to be processed into pdf (most are received as tiff and converted), 2 copies
      pdf is queued to email server - stored in mail queue
mail is send generally from internal relay -> internet relay (another storage point) mail is sent to your company MTA & internal relay/exchange server (2 more storage points) mail is received by internal email to be printed, cached by windows for email & acrobat / print spooler (2-3 more storage points)
      pdf is queued on windows print spooler (final storage point).

Each of those areas would need to be securely deleted. Which is why PCI requires any card numbers sent via email to be encrypted.

cwright () bdosyd com au wrote:
JW,
Your first problem will stem from having to encrypt
the numbers in transit. The fax to email gateway will
have to sign these emails.

A set of competating controls could be implemented for
this (protected network with firewalls, IDS etc which
could take the place of encrption, but this would be a
significant investment in itself. The PCI-DSS
requirement 3 states "not sending PAN in unencrypted
e-mails". 4.2 also specifically states "4.2 Never send
unencrypted PANs by e-mail".

So as I said, there are possible compensating
controls, but I believe that they are going to be far
more of an investment then encryption.
The only compensating controls I can think of would involve building an internal fax server, I can't think of any with a 3rd party fax service.

Next in this case the fax server and email system
would have to be on a firewalled segment and not (as
is common) on the same network as all the users.

With physical faxes, 9.6 applies "Physically secure
all paper and electronic media (including computers,
electronic media, networking and communications
hardware, telecommunication lines, paper receipts,
paper reports, and faxes) that contain cardholder
data."

You would have to have a minimum level of security on
the virtualised process as for paper handling. So this
would cover (as with the above) encryption,
destruction after use etc.

These things are required if at all you store the CC data.  You cannot
control the actions of others who decide to send you their CC numbers.
 Your responsibility is to handle the data responsibility.
Actually if you have a contract with a service provider who is storing/processing/transmitting card data on behalf of you for your customers they are required to:
12.8.1 Service providers must adhere to the PCI DSS requirements
12.8.2 Agreement that includes an acknowledgement that the service provider is responsible for the security of cardholder data the provider possesses

If you were to have a PCI audit, the auditor would check your contracts to be sure those items were in place with any service providers you work with who store/transmit/process card data.

Hope it helps,
Rajat.


------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault