At this year’s PCI Community Meeting, the push was to address the security issues faced by small and mid-sized businesses, otherwise referred to as SMB. However, in my opinion, the approaches being suggested are still too complex. Great security results from simplicity, not complexity. As a result, I propose the following approach for SMBs because SMB executives typically have little time to fully educate themselves in information security, let alone, PCI. And while I am of the opinion that executives should have such knowledge, it is just not happening.
There Are No “Silver Bullet” Solutions
First and foremost. There are no “silver bullet” solutions that will entirely remove your organization from PCI scope. Any vendor telling you that their solution removes your organization from PCI scope is lying to you. If you hear such a statement from a vendor, the vendor does not know what they are talking about and their statements regarding PCI should no longer be trusted. The bottom line is that, if your organization accepts credit/debit cards for payment for goods/services, the organization will always have some PCI scope. The least amount of scope an organization can achieve is complying with the requirements listed in the SAQ A. There is nothing less. Anyone telling you otherwise does not know what they are talking about.
DO NOT STORE CARDHOLDER DATA (CHD)
This is probably the biggest single thing an SMB can do. In this day and age, there is no reason that any organization needs to retain CHD. Period. The most common business justification is that the organization does recurring transactions and that is the reason to retain CHD. Processors have a solution for that situation and many others. So I say it again. There is no valid business reason for any organization to retain CHD. None. Nada. Zip.
The first question out of an SMB executive’s mouth to a payment solution vendor should be, “Does your solution store cardholder or sensitive authentication data?” If the answer is anything other than an immediate and definitive “NO”, the meeting or telephone call is over, done, complete. There is nothing more to discuss. SMBs must stop being an easy target for attacks. The easiest way to do that is not having the CHD in the first place.
The second question that a payment vendor should be asked is, “How does your solution minimize my organization’s PCI scope?” If the vendor cannot provide you with a whitepaper on this subject, run away. If the documentation provided by the vendor leaves you with more questions than answers for PCI compliance, you also need to run away. In all likelihood, if this is what you encounter, the vendor’s PCI compliance is questionable, complex or requires too much effort on your part to be PCI compliant. This question should result in a one to three page whitepaper on PCI and how the vendor’s solution minimizes your organization’s scope.
So what solutions reduce scope to the minimum?
If you are a traditional brick and mortar retailer, end-to-end encryption (E2EE) from the card terminal, also known as the point of interaction (POI), to the transaction processor. PCI has a validation program called point-to-point encryption (P2PE). P2PE solutions are independently validated to ensure that they are secure. Solutions such as Shift4’s Dollars on the Net, First Data’s TransArmor and Verifone’s VeriShield are E2EE solutions that could meet the P2PE standard, but for various reasons the providers chose not to validate them to the P2PE standard. The key capability for any such solution is that the solution encrypts the CHD/SAD immediately when it is read from the card and none of your organization’s technology can decrypt the information and therefore read it.
If your organization does eCommerce, then you want to use a redirect or iFrame to process transactions in order to reduce PCI scope. The best example of a redirect is when a merchant uses PayPal for processing payments. The merchant’s Web site has a PayPal button that sends the customer to PayPal who then processes the customer’s payment transaction. At no time does the sensitive authentication data (SAD) encounter the merchant’s Web site. One of the concerns from merchants about redirects is the myth that customers vacate their shopping carts because they are redirected to a different site for payment. While this was true in the early days of eCommerce, with the increased use of PayPal and similar payment services, customers seem to have gotten over that practice and vacated shopping carts are no longer an issue. But if this is still a concern, use this as a teaching moment and educate your customer base that you do the redirect to ensure the security of their SAD.
An iFrame is essentially a Web page within a Web page. But the key thing from a PCI compliance perspective is that the iFrame is produced and managed by a third party, not the merchant. An iFrame can be a Web page, but more often than not it is a series of fields that gather the SAD for conducting a payment transaction. As with the redirect, the SAD never comes into contact with the merchant’s Web site.
Both of these solutions take your organization’s Web site out of scope so you do not need external and internal vulnerability scans and penetration tests. However, just because your Web site does not have to go through the rigors of PCI compliance, you still need to ensure its security. See my post on SAQ A and SAQ A-EP for a more detailed discussion on this topic.
Tokenization
Tokenization is the act of encrypting or tokenizing the primary account number (PAN) so that when it is returned to the merchant for storage it has no value to anyone if it is disclosed. Tokenization can occur at the time a card is swiped or dipped at the terminal or it can be done by the transaction processor at the back end of the transaction. Regardless of where the tokenization occurs, paired with E2EE or P2PE, tokenization further minimizes PCI scope.
If your organization needs to perform recurring transactions such as with subscriptions or automatic reorders, tokens can be generated by the processor so that they can be used just like a PAN. While a token is not a PAN, in situations where they can be reused for future transactions, it is incumbent upon the merchant to protect access to the token so that it cannot be sent to the processor for fraudulent charges.
And that is it. Not storing CHD, E2EE/P2PE and tokenization will reduce an organization’s PCI compliance footprint to the absolute minimum. It really is that simple. However, finding the solutions that bring all of that to the table is where the work comes in. However, any SMB that asks the right questions of its vendors can put together a solution that minimizes their scope and provides protection for CHD/SAD as good as with the big boys.
PCI Guru 
Regarding your comment around iFrames:
An iFrame is essentially a Web page within a Web page. But the key thing from a PCI compliance perspective is that the iFrame is produced and managed by a third party, not the merchant. An iFrame can be a Web page, but more often than not it is a series of fields that gather the SAD for conducting a payment transaction. As with the redirect, the SAD never comes into contact with the merchant’s Web site.
Both of these solutions take your organization’s Web site out of scope so you do not need external and internal vulnerability scans and penetration tests. However, just because your Web site does not have to go through the rigors of PCI compliance, you still need to ensure its security. See my post on SAQ A and SAQ A-EP for a more detailed discussion on this topic
—
I would have to disagree with you regarding that iFrames remove the web site out of scope. Take a look at the PCI DSS E-commerce Guidlines – January 2013 (yes, it’s old, but that’s the council for you), on page 13. We have this comment:
PCI DSS Scoping Guidance: Merchants should understand that outsourcing to a third party via a shared-management implementation does not allow the merchant to outsource PCI DSS responsibility, regardless of whether a merchant is eligible to complete a self-assessment questionnaire (SAQ). With each of these shared-management implementations, there is still security risk for the merchant since weaknesses on the merchant’s website can lead to compromise of the payment card data during the transaction process. See “Security Considerations for Shared-Management E-commerce Implementations” on page 17 for risks specific to each implementation. Due to these risks to a merchant’s website and payment card data, even in outsourced scenarios, it is recommended that merchants implement applicable PCI DSS controls as needed to ensure the security of the website.
Looking on page 16-17, we have this:
iFrame Approach: With the iFrame approach, the iFrame must be configured and managed to prevent it from being modified to send cardholder data to an alternate and unauthorized source.
Finally, looking on page 22, we have this:
Merchant still has responsibility for PCI DSS requirements for some elements of the e-commerce infrastructure even though they have outsourced much PCI DSS responsibility for the storage, processing and transmission of cardholder data.
This is because compromise of the merchant’s website may result in a compromise of the iFrame, which could allow compromise of CHD.
Merchant is responsible for:
Managing website and servers (if self-hosted), including applicable PCI DSS requirements
If website/server hosting is outsourced, applicable PCI DSS requirements for management of third parties (e.g., Requirement 12.8)
Having written agreements with any third parties and ensuring that they protect cardholder data on behalf of the merchant, in accordance with PCI DSS
Securing the web page(s) containing the iFrame code.
Summing this all up, it looks like from a scope perspective, you can’t completely remove the webpage out of scope even though you use iframes.
Yes, I understand that there is a big disclaimer on every page saying “The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in the PCI Data Security Standard.”. But it’s all about scope. Straight from page 10 of the PCI DSS – Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE.
If the web servers that host the iFrame count as “impacting the security of” the CDE, and by the guidance given in the supplement, the merchant has responsibliy for managing the website, securing the web page that contains the iFrame code, and making sure that the iFrame must be configured and managed to prevent it from being modified to send cardholder data to a alternate and unauthorized source, I would argue that yes, the web server itself would be considered in scope for PCI, because if you compromise the merchant’s webpage, you could modify it to send cardholder data to a alternate and unauthorized service.
What are your thoughts on this, as well as your coworker’s thoughts?
Great synopsis. Thank you.
I think what you are tripping over is the difference between the service provider’s role in the iFrame and the merchant’s. The Council and the card brands have espoused that it is the service providers’ server(s) that serve up the iFrame that are in scope and that the merchant’s server that invokes the iFrame are not in scope. Not that I agree with that (for the very reasons you point out), but that is what we are told by the Council and the brands. As a result, the merchant supposedly has no scope if they use an iFrame or a redirect and therefore no cardholder data environment (CDE).
That said, we tell our clients using iFrames/redirects to vulnerability scan, penetration test and monitor the iFrame/redirect invocation code/script/executable to ensure they are securing that function.
If we use something like Verifone’s VeriShield, SAQ P2PE-HW is not possible (since the solution is not validated). However, it should still reduce the scope, if installed correctly? Which SAQ would be used at that point, since the merchant doesn’t have access to the encryption keys?
What you need to do is to validate that VeriShield does reduce your scope. You then submit that evidence to your acquiring bank and get their documented approval that scope is reduced by VeriShield. Then you need to get the bank’s approval to either submit an SAQ P2PE-HW under the scope reduction or use an SAQ D and only reply to the SAQ P2PE-HW requirements and mark all others as ‘Not Applicable’ because they are not in scope.
As a SMB at level 2 (1M – <6M annual transactions) and would like to use SAQ C/D, we have no ISA inside yet (although I'm in process to get ISA certified). I read about that MC requires either ISA for SAQ or external QSA for ROC. My questions is – can we still do SAQ C/D w/o ISA inside the company?
This is an old page and I don't know if MC is more flexible now –
https://www.pcicomplianceguide.org/level-2-merchants-beware-your-pci-validation-process-could-be-changing/
MasterCard has not changed their position and you must perform a Report On Compliance (ROC) as a Level 2 merchant. Without an ISA on staff, your only option is to hire a QSA to do your ROC. Good luck on your ISA training and certification.
Thanks for the confirmation. Our dilemma is should we sign a ROC service contract to start the process before I get ISA certified or wait till I get certificated (in about 2 mns)? I’m experienced in PCI compliance and can do SAQ.
It’s up to your organization as to whether or not they need to be listed on the Visa and/or MasterCard Service Provider Web sites. If they do, then you will need a QSA to conduct your assessment resulting in a ROC. Otherwise, you can do the SAQ D as the organization’s ISA.
“There is no valid business reason for any organization to retain CHD. None. Nada. Zip.”
Ok, clear as water.
But this means that there is allways an alternative.
What about when you store CHD just as a guarantee of payment. What is the alternative?
And what about single use cards, that a customer gives you today, but you can not do the charge until next week?
If there is an alternative for this situations, please tell me those alternatives, because I would like to NOT store CHD in our systems.
Thanks a lot in advance.
Sorry about the confusion. I should always qualify my comment about storing CHD with there is no reason to store it AFTER it has been processed as a transaction.
All of what you seem to be discussing/questioning are instances of pre-authorization. That is, instances where you, the merchant, are not running an actual transaction but are holding cardholder data (CHD) in anticipation of a transaction. This is no different than what happens when you make a hotel reservation or fill your vehicle with gasoline. For a period of time from minutes to months, these organizations securely store your CHD until the actual transaction is processed. You are allowed to store pre-authorization data, but you must protect pre-authorization data with the same voracity as post-authorization data. If in digital form, protections would include encrypting that data (at least the PAN and CVV/CVC/CID, if provided) and strictly limiting access. Once a transaction is processed, you then would need to securely destroy any hard copies or securely erase that data from your systems.
If you are using cards for a guarantee of payment do you issue a hold on the account for an amount or just store the CHD just in case? If you do issue a hold to the account, then you could always go back to your transaction processor to have them process an actual transaction if necessary. This would require you making arrangements with your processor for those times where you would need to go back to your processor for an actual transaction.
Most single use accounts (SUA) that I encounter are transmitted via facsimilie and end up on hard copy. Most of my clients log all those facsimiles so that they know the date and time they were received and from what organization. They are then securely stored in a locked cabinet with only certain people having keys and then processed as soon as they can be processed. Once processed, the documents are securely redacted or destroyed. Secure redaction would be taking a Sharpie or similar permanent marker and truncating the PAN to first six and/or last four digits and redacting any CVV/CVC/CID and then copying the original and securely destroying the original. Secure destruction would be putting the document in a commercial service’s secured shredding bin or being cross cut shredded right after processing. While MasterCard has told organizations that they do not consider SUAs as CHD once processed, the other card brands have issued no such guidance. As a result, I recommend secure redaction or secure destruction to be PCI compliant.
Thanks a lot for your reply. It helps me a lot.
Re iframes now being a “series of fields” rather than a traditional embedded page. At first I thought this was a clever solution but it breaks autofill on iOS, Android, Chrome, etc and increases abandonment. I wonder if we will see browsers update to work better with them (I doubt it) or if everyone will switch back to embedded pages.
I thought Chrome had been “fixed” to work right with iFrame “fields”. That said, I have not tried a Web site that I know uses an iFrame with Chrome lately.
Now that you bring up mobile, this may be why merchants are using redirects on their mobile sites instead of iFrames.
That said, while autofill for name and address is okay, I’m definitely do not like the concept of autofill for cardholder data (CHD). I have always told my browsers to never remember such information.
Chrome pulls your cards in from Google Wallet. So if you’ve bought stuff from Google Play or the Google Store they’ve already got your details.
When Safari on iOS sees a credit card form it also offers to open the camera and you can hold your card in front of the camera and it will scan in name and numbers.
Last time I checked all of these features were broken by iframe “fields”.
You would think a field is a field. I’m guessing it’s that the fields are not in the same URL as the rest of the page and the applications have no way to deal with two URLs simultaneously.
We had a battle with the Dev departement to push for tokenization, There are some legacy applications that are dated from the 70s but we did convince them with: The token will smell and feel as a PAN, the application won’t see the difference. Until the QSA came in to take a look and he pulled the last paper of best practices published by the PCI Council in April 2015. Based on that the token shouldn’t pass Luhn check as a PAN, so the token won’t smell and feel like a PAN, Yes it is just a best practice, but he recommends to follow even if it is not a requirement yet. Given that, there is a need to adjust and test. I am not sure how you could face the Dev Dept or the vendors and sell them the tokenization with the new guideline?
The Council’s information supplement titled ‘Tokenization Product Security Guidelines – Irreversible And Reversible Tokens’, dated April 2015, contains guidelines, not requirements or even best practices. The information supplements are the Council’s attempt to provide merchants and service providers with acceptable solutions to problems and what to look for in potential solutions. In the case of this information supplement, the guidelines relate to reversible and irreversible tokens. There was an earlier information supplement on tokenization issued in August 2011 that was not entirely superseded by the April 2015 document.
I’m not sure what your concern is regarding the April 2015 information supplement and issues your developers or and software vendor would have regarding tokenization.
Yes a good article. However the reality is many of us (merchants) are committed to using software systems from vendors that have little interest in implementing tokenization, and many of us require card data to be kept as part of the business operations model. More engagement between software vendors, merchants and the card brands is needed.
Tokenization is typically done by the processor, not the POS software. As a result, tokenization solutions are software vendor independent. Any software vendor telling you they do not support tokenization is looking at it from the perspective that it is their problem to solve.
Again, there is no business model I have encountered that requires the retention of cardholder data (CHD). The only reason I have ever encountered such an argument is because the business is not willing to pay their processor the extra cents per transaction to allow a token to be reused. If that is your rationale, then so be it. It’s your business that you are putting at risk.
I have to agree with the store no data component of this article. Two weeks ago I was with a new manager at one of our facilities and for /some/ reason they were storing the last four of the card and the ccv on paper forms. I saw this and asked them to remove it. It turned into quite the conversation with the manager’s supervisor going to our finance supervisor and telling her that I said to redact twenty-five years of records (didn’t say that at all). The funny part is that the finance supervisor wants her finance manager to do the paper inspection side of PCI, yet they haven’t asked for the regulations so they can put it into practice. She also tried to defend them keeping the last four and ccv. I told her they have no business case or reason for keeping the data, and she couldn’t say that they did and told me to pick my battles (her name isn’t on the compliance docs, mine are).
We recently had a discussion with a client that was storing CVV/CVC/CID in a database separate from other databases that stored encrypted PAN. Their argument was that the CVV/CVC/CID alone could not be used for fraud which we totally agreed. However as their QSA, we pointed out that there are no caveats in requirement 3.2 that allow storing SAD under certain conditions. Requirement 3.2 clearly states that storing SAD after a transaction is processed is prohibited. As a result, storing CVV/CVC/CID is not allowed under any conditions because it is SAD.
Storing the last four of the PAN is allowed, but the CVV/CVC/CID should have also been redacted on the paper forms. I am sure that the manager thought that if you were going to ask for redaction it would be for all forms stored. But that brings up a good question. What is the business, legal or regulatory reason for having 25 years of records stored? Unless they are related to active mortgage loan records, I cannot come up with a valid business, legal or regulatory reason for having 25 years of retained records. Therefore I think they will have to securely destroy those records to get down to something a bit more realistic for retention.
There was no payment information on the 25 years, but other compliance factors drive the retention of those specific records.
Not quite 25 years, but the EU requires data to be kept for 10 years for tax purposes. This applies especially to sales of digital goods as the BIN/IIN/first 6 can be used as part of geolocation and thus affects which tax rates are charged.
Legal and regulatory data retention requirements have always trumped the PCI DSS requirements.
I know that in certain EU countries for example, the only legal proof that a card transaction has occurred is the receipt from the card terminal and that receipt must contain the full PAN (the customer copy does not have the full PAN). As a result, I have merchant clients in Europe that have secure storage in warehouses just to store those receipts for the mandatory three years. I’m not sure if those laws have been changed or not.
In the US, some states have interesting data retention requirements as well. A certain Midwestern state required at one time that businesses retain 11 years of data on all transactions for tax record purposes. As a result, merchants were keeping copies of invoices, receipts, checks and card receipts with full PAN for 11 years. Thankfully that state got a clue and dropped that retention requirement down to a little more reasonable five years and dropped the need to retain copies of checks and the full PAN for card transactions.
Good post. This should be the approach to all organisations that take credit cards not just SMB. Very few retailers are built for PCI DSS. I would guess that Amazon, eBay would be the only ones that could be properly compliant to PCI. Everyone else should minimise scope.