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:
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.
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
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:).
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:).
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:
customer fax cc# --> 3rd party fax service --> to your
company in PDF via email
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).
So in essence, should your company be liable for
non-compliance even though this is not something you
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
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
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 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).
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
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.
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.
cwright () bdosyd com au wrote:
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.
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:
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
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.
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
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,
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!