Re: Faxing and PCI DSS compliance

["David M. Zendzian" <dmz () dmzs com>]

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
------------------------------------------------------------------------