Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Faxing and PCI DSS compliance |
|---|---|
| Date: | Mon, 28 Jan 2008 15:57:21 -0500 |
On Jan 24, 2008 3:15 PM, jw <rx.jeff@yahoo.com> 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.
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.
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:
See abovecustomer 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 can control?
The requirement 3 is about "sending" PAN and not about receiving.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).
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 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: 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.
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:These things are required if at all you store the CC data. You cannotNext 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.
control the actions of others who decide to send you their CC numbers.
Your responsibility is to handle the data responsibility.
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 ------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: ESX Vmware Physically connected to different segments, David M. Zendzian |
|---|---|
| Next by Date: | Re: ESX Vmware Physically connected to different segments, Kurt Buff |
| Previous by Thread: | Re: Faxing and PCI DSS compliance, rajat swarup |
| Next by Thread: | Fwd: File Binders File Types & Microsoft Word., Vivek P |
| Indexes: | [Date] [Thread] [Top] [All Lists] |