It took a while, but here is some fun Q&A from that PCI DSS Myths and Misconceptions webinar we did a few moths ago.
- PCI Myths slides on Slideshare (teaser, full version)
- Audio recording of the presentation and Q&A with slides
- Select Q&A are below
Some questions are way too deep to be answered in a blog post; still, I hope the answers are useful to my readers.
Q: What about the organization that says "but we use authorize.net, PayPal, Google Checkout (or whoever) to process our card payments for items we sell on the web. We don't ever handle the card data ourselves, so we don't need to worry about PCI...do we?"
A: Indeed, outsourcing credit card data processing is a very good way of reducing the scope of your PCI compliant environment. However , it is not the same as “outsourcing PCI DSS” since it does not completely shield you from PCI DSS requirements. “Scope reduction” is NOT “PCI elimination.” There are still areas where you must make an effort to comply. However, PCI Qualified Security Assessor (QSA) is the authorized source of this information.
Q: What is the purpose of the Self Assessment Questionnaire and why do we need to complete one for each scan? Our credit card processing company requires us to complete a Self Assessment Questionnaire to accompany each scan.
A: SAQ purpose is to assess (well, “self-assess”) security posture of an organization, just as the name says. The SAQ is a way to review the security controls which are in place without the help of an auditor. There is no formal requirement to complete a self-assessment questionnaire after every quarterly scan. Scans must be performed once a quarter, while a self-assessment questionnaire must be completed once every year. However, your acquirer might have a different opinion and might prefers to collect more information about you on a more frequent basis. BTW, you are supposed to answer the SAQ honestly, to the best of your knowledge, and remediate the gaps found.
Q: Is a QSA the only authorized entity to run a scan or can I as the owner of our business run the scan myself?
A: This is a pure misconception; 100% false. As per PCI DSS requirement 11.2, an approved scanning vendor (PCI ASV vendor) must be used for external (=Internet-visible) scanning. Internal scanning can be performed by yourself or anybody else skilled in using a vulnerability scanner.
Q: Do we need to ensure that our third party fulfillment company is PCI DSS compliant as well (especially if they are taking credit card numbers for our customers)?
A: It is hard to say how the contracts are written in such case, but often the answer is indeed “yes.” Moreover, if they take credit cards they need to be compliant and protect the data regardless of their relationship with you. PCI QSA is the authorized source of this information.
Q: Is this [PCI] a US requirement only or do we need to ensure that our international offices are in compliance as well?
A: PCI DSS is most definitely not just US; it is a worldwide mandate by the global card brands: Visa, Mastercard, American Express, Diners Club, etc.
Q: I thought using PA-DSS application makes me PCI compliant, isn't that the purpose of the PA DSS?'
A: Not, it most certainly does NOT. PCI DSS and PA DSS are separate mandates; one applies to organizations, networks, systems [PCI DSS] while another [PA DSS] applies to payment applications only. This is actually a very common misconception. Using PA DSS-certified application certainly does not make you PCI DSS compliant!
Q: Is a fax with credit card information that arrives to organization’s fax server considered to be a digital copy of this data?
A: A digital fax containing a credit card number is likely in scope for PCI DSS. There is some debate about the “pre-authorization data”, but protecting credit card information applies to all types of information: print, files, databases, fax, email, logs, etc.
Q: What if this fax contains a CVV2?
A: In this case it cannot be stored and must be destroyed. I’d leave the debate about the temporary storage of CVV2 containing media to PCI QSAs and lawyers. PCI DSS states that you cannot store certain types of credit card data, such as CAV2/CVC2/CVV2/CID. Overall, you should also minimize all storage of card data; and this is exactly what card brands recommend (e.g. see Visa’s DropTheData site)
Q: What are the most common ways to steal data from merchants?
A: It is very hard to summarize as reliable statistics are not publicly available. Informally, SQL injection has been a very frequent route to steal such data and so did lack of data encryption on internal networks.
Q: What are the real costs of being not compliant?
A: The reliable cost estimates are not available in the public domain. Overall, the costs are not just in monetary fines, but also in lawsuits, breach disclosure costs, investigation costs, processing rate increases, contractual breach costs, cost of additional security measures, cost of credit monitoring as well as a cost to have a QSA assessment performed (if jacked up to Merchant Level 1 due to a breach)
Q: Is there some type of official timeframe that everyone needs to be compliant?
A: Official PCI DSS compliance deadlines have already passed back in 2006 and 2007. However, card brands such as Visa recently typically set their own dates (example from Visa).
Q: Just to summarize, PCI is about processes and how these processes filter to how actions, processes, security both physical and procedures/audits and networks are setup and managed?
A: That is correct. PCI DSS goes beyond information technology and covers, for example, paper records as well as other ways of storing credit card information. However, your PCI QSA is the authorized source of the information of what PCI should cover in your organization.
Q: What criterion do the ASV follow for the external PCI DSS scanning?
A: Brief answer here. Longer answer is here.
Q: If the deadline for compliance has past, what might be a more relevant question would be when will merchants be completely liable?
A: This is a very dangerous way to think about PCI DSS. This highlights the fact that the person asking the question is only thinking of PCI DSS because of penalties and not because of the requirements to protect credit card data. Please focus on securing the card data, not on “avoiding liability.” Here is some useful reading on the subject.
Q: For a small merchant that only processes a handful of transactions a month, are there alternatives to some of the expensive technology requirements (e.g. application firewalls, independent web/db servers, etc)?
A: Outsourcing credit card transactions is likely the right answer in such circumstances.
Q: Is PCI just a way to avoid paying heavy fines in case of fraud?
A: PCI DSS compliant status will likely not protect you from fines and other costs in case of a data theft. Ultimately, you must protect the data and not just be compliant. If you're compliant, but not secure, and then compromised and fraud is committed, your will probably be liable for losses.
Q: Does PCI only apply to digital data, what about credit card information on print outs?
A: PCI requirements do cover printed data as well. See example in PCI DSS guidance itself.
Finally, thanks again for attending the webcast!
Note: this is posted by a scheduler; I am away from computers for a few days.
No comments:
Post a Comment