If you have a PCI question that is not related to anything I have posted, you are welcome to post them here. I will do the best I can to respond to your questions. If other readers wish to weigh in on questions posted here, their comments are also welcome.
Remember though, I am a QSA and consultant. So I am not going to “give away the store” as I am in the business of selling my expertise.
Hi PCI Guru,
I have a situation where the client takes the front of the payment card and customer photo identity card as a scanned copy over email to confirm that he/she is the valid owner of the credit or debit card.
I am looking for an alternate option, if any, to complete the above process without the card scan copy being taken from the customer.
Incase you feel that we still need to take the scan copy fromt he customer, then do you feel that the below approach is acceptable to meet the PCI requirements :
1) Email encryption
2) Identifyng and restricting access to such emails for specified employees
3) Encrypted backup of the mail server
Plz suggest…
I have had a few clients that took photocopies of drivers license numbers and credit cards. But note, I used the past tense, not the present tense.
First, your client needs to consult with their legal counsel to make sure what they are doing is legal. In certain states in the United States and in some countries, copying a drivers license, official identification card or credit card is illegal. Then there is the credit card merchant agreement, most of which make taking a photocopy of a credit card as breaking the terms of the merchant agreement. It is this last item that will stop the photocopying of the credit card.
Assuming that everything is legal, I would recommend that the images be encrypted and access to the images is severely restricted. You might also want to consider putting them under dual control.
In an environment where multi-factor authentication is implemented, in this case RSA tokens, for remote access, is there a requirement to enforce some kind of dual control for the management/handling of tokens?
Unless RSA has radically changed its SecurID system since the hack, I’m confused as to why you would need dual control. Once an RSA token is issued, the value generated by the token cannot be obtained by anyone, even those with administrative privileges to the SecurID authentication server, other than the person with the token generator. The administrator can only reset the token requiring the token to be presented and re-synchronized with the server.
Dear PCI Guru,
Is it mandatory to mask the PAN printed in the monthly statements sent to the customer? Is there any bank / service provider who has got a compliant PCI ROC / AOC with the condition that they do not mask the PAN printed in the monthly statements?
I would argue that requirement 3.3 of the PCI DSS requires the masking of the PAN wherever displayed including statements. However as you point out most people’s credit/debit card statements contain the full PAN. However, this practice is slowly changing (my own bank just started truncating my debit card PAN on my statements) and I would expect in the next couple of years that people’s statements will not contain any sensitive information fully displayed, PAN checking/saving accounts or otherwise.
Dear PCI Guru,
I recently transitioned to a Security Administrator position at my company. Part of my duties include PCI compliance which I am new to; my career experience has been more on the network and systems side of MIS. They are sending me to ISA training this year. I have searched to see how difficult it is to pass the ISA exam at the end of the two day course from PCI DSS. I’m trying to get more prepared with self study, but cannot find many tips on what to exactly to study. The online PCI fundamentals is no longer available to me after passing as well.
Basically, in your opinion is the ISA exam difficult to pass with a two day course? Do you know of a pass/fail rate?
Thanks for your feedback
The best thing I can recommend is to download the documentation available on the PCI DSS from the PCI SSC Web site Documents Library (https://www.pcisecuritystandards.org/security_standards/documents.php).
Documents you will want to read and study include:
- PCI DSS v2.0
- Glossary v2.0
- Navigating the DSS v2.0
- PCI DSS Quick Reference Guide v2.0
- ROC Reporting Instructions
If you read and understand all of what is in these documents you will be more than prepared for the ISA examination.
Hello Mr. PCIGuru,
First of all thank you for posting such good posts on your blog it helped me understand PCI better than any other source of information thus far.
The PCI-SSC has been quite about mobile payment application requirements for a while but the public continues developing these solutions. Recently(17March2012) i read your opinion about the new payment solution “PayPal Here” and about the insecurity of the mobile operating systems ( specifically manual input).
What if no manual input was possible and thus only the reader connected to the mobile device would be used(Considering that the reader uses a strong form of encryption like AES256 and DUKPT as it’s key-management). And the data read from a credit-card would still be encrypted and sent securely to a remote server.
How much does this differ from a payment done through via a secure HTTP connection with my credit-card?(personally not much i would say)
Would the client application using only the reader still need to be PA-DSS Compliant (even if it’s a interface like a website)?(a mobile application cannot be PA-DSS complaint but it is advised to follow the PA-DSS requirements none the less)
What if Paypal or Square had made an offline solution making it more a terminal then a complete payment application? (see below)
[Client Application (Paypal Here, Square, etc..) ] [Local Server Application --> PA-DSS Compliant Application] —> Processor
i would like to hear your thoughts on this matter,
thank you in advance
Hello and thanks for this great site!
I was wondering if you’re familiar with the “Massachusetts Information Security Regulations”. If a merchant was to be PCI compliant, it seems (upon my quick looking) like this might cover what’s asked for in their State regulations as well. Have you (or anyone reading this) had any experience with this?
Cheers,
az
From a credit card standpoint, you are correct. However MISR has other requirements surrounding personnel records, financial records, etc. that are not covered by the PCI standards but still need to comply with MISR.
One thing the PCI DSS does not cover are corporate credit card numbers stored in a company’s systems. Those would be covered by MISR.
Figured as much. Since we are not a MA based company (and have no MA residents working here), we are really only concerned about the CC standpoint (i.e. from MA customers).
Thanks for the quick response! And keep up the good work, the amount of CLEAR info out there on the PCI world is limited…
First of all, thanks for all of the excellent information in your blog. You are really furthering the understanding of PCI DSS.
Mine must be a fairly common situation, but I don’t see much guidance on the web.
We are a Level 3 Merchant filling out the SAQ-C v2 form. We were previously v1 compliant.
Our CDE is hosted. No one on the corporate network ever connects to the hosted environment’s servers directly. They use the website just like other public users, but have some administrative functions that have nothing to do with credit card transactions.
We have a 3rd party development company that accesses the hosted environment’s servers using two-factor authentication.
We are working on Section 12.1 of SAQ-C which relates to security policies.
The question is: Since no one on the corporate network accesses the CDE, do the security policies have to “cover” them, or do they just have to cover the 3rd party development company who accesses the CDE?
Any other special issues I should look out for in our case?
Thanks!!
Your policies, standards and procedures need to cover all of the requirements in section 12. Just because you have outsourced a lot of your technology, your employees still need to have the guidance that all of documents in section 12 provide.
Got it!
Thank you!
Dear PCI Guru
If I had to develop a Mobile app to make payments online a merchant will be charged an
interchange rate of CARD NOT PRESENT, based on the risks involved.
However, If you do not store the data on the phone app, but with tokanization on the Server, switch through a
PCI complaint switch (Which holds the card data) and never store the CSV numbers.
Would the transaction then be deemed as CARD PRESENT ?
Thus the interchange rate be CARD PRESENT rates?
Thank you for your time.
Interchange rates are not something a QSA can determine. These are questions for your acquiring bank.
Thank you…
Dear Guru
the problem is that we are both issuer and acquirer in my country
as for direct specification we have not received any compliance directives about our self only for our merchants
we are performing a gap analisys with a QSA but is for internal use only.
I’m searched both MC and VISA sites for some kind of reference but without any luck.
I’m trying to convince my mangers that it will be wise to get and ISA personal
so we will be more ready , if in the future PCI compliance will be not just fore merchants but rather for the acquirers as well.
I found only few references in some ASV sites that state (http://www.gfi.com/security/pcifaqs.htm) “Acquirers are not currently mandated to carry out any specific PCI DSS validation or certification process”
Let me be VERY clear here. It is not a question of ‘IF’ you will need to comply, it is a question of ‘WHEN’. EVERYONE that processes, stores or transmits cardholder data MUST comply with the relevant PCI standards. Yes, the card brands my not be knocking on your door today about whether you are compliant, but they will at some point.
That said, you probably will not hear much out of the card brands. Their focus is on merchants and then service providers. Right or wrong, their assumption is that financial institutions are already secure because they are regulated by some entity. Depending on where you are in the world, it could be quite some time before you hear anything. Financial institutions in the US just started to get “pinged” over the last two years, but that was for their internally switched ATM networks. We have a number of other acquiring banks that are just now starting to inquire into their PCI compliance requirements, but none of these institutions are being pushed by the card brands. They just don’t want to end up behind the curve when the card brands begin mandating compliance.
As an issuer, you are required to maintain track data and that is allowed under the PCI DSS. However, you are required to encrypt it and severely restrict who has access to it.
As an acquiring bank, your transaction processing processes are the piece that will need to be compliant. If those processes are separate from the rest of your banking platforms, then you compliance should be fairly straightforward. You may have to increase segregation in spots to improve your ability to reduce the scope of the assessment. Where we have seen significant issues is when the acquiring bank is fully integrated on their platforms and it is near to impossible to separate out the transaction processing from everything else. Then you end up with essentially everything in scope which, for a financial institution, is a big scope. We have a couple of acquiring banks in that sort of situation and they are re-architecting their transaction processing platform so that it is separate from the rest of their banking systems.
Dear PCIGuru
First let me thanks you for being a Light Shining Through the Mist
now for the question:
I work in a IT department for an acquirer bank in my country, and we have an internal debate about PCI compliance ,
Have you encountered any directives from VISA or MC about acquirer to be PCI complaint and what level of compliance ?
should it have a ISA or depend on QSA ?
or just filling a SAQ D will be sufficient .
if yes please point me to those documents
your help is appreciated
First and foremost, any organization that processes, stores or transmits cardholder data is required to be PCI compliant. That includes not only merchants, but also processors, service providers and financial institutions.
Where this gets tricky is with financial institutions because in a lot of countries, particularly in the US, the acquiring bank is that in name only. The actual processing of transactions and issuing of cards is actually done by a subsidiary of the institution or is done by a third party such as First Data or another financial institution’s subsidiary. It is those institutions that need to be PCI compliant, not the bank. All of these organizations will be considered Level 1 service providers and will need to either have an ISA or QSA do their Report On Compliance (ROC).
However, a financial institution can still be in-scope for PCI compliance if they perform either of these services.
- If the institution switches its own ATM network and that ATM network accepts Visa and/or MasterCard credit/debit cards, then the ATM network is in-scope for PCI compliance.
- If the institution issues Visa or MasterCard branded debit cards, then the institution needs to store those debit PANs in their system(s) and those systems(s) and related networks are in-scope for PCI compliance.
Whether or not an SAQ is acceptable is up to the card brands. The financial institutions we have assisted have all been required to conduct a full ROC. However, given you are not in the US, I would ask the card brandds in your country/region as to what they would like you to do.
Mr. PCI Guru,
I have a question. On websites like Amazon, when you first purchase something your Security Code is required. I have them save my information so it is easy to order again. Do they save the Security Code (which is a violation 3.2.2) or how do they make additional purchases?
It depends on how Amazon does their transactions.
If Amazon is storing the cardholder data, then you are correct. They only use the CVC/CVV/CID at the time of the original purchase and the cardholder name, primary account number (PAN) and expiration date is all that they retain. On future transactions they only submit that information to their processor. They will have an agreement in place with their processor for conducting future recurring transactions without the CVV/CVC/CID. However, these future transactions may carry a higher interchange rate than the original.
If Amazon is using something like tokenization, then the organization that does the tokenization may be retaining the CVC/CVV/CID in addition to cardholder name, PAN and expiration date. But as a processor, they are allowed to do this, but they are required to secure that information. When Amazon sends through the token to process the next transaction, the processor substitutes the cardholder data including the CVC/CVV/CID to process the transaction. These future transactions are usually at the same interchange rate as the original.
Thank you so much. That makes complete sense.
Dear PCIGuru
Does POS printouts that are signed by the customer also need to be masked and display only the 4 digits ,
it creates a problem when a merchant has a problem transmiting the data and the only proof that he has for the purchase is the signed slip that he will send to the Aquirers for manual proccess .
Masking, even on a receipt, can be the first six digits and last four digits, however the most common masking on receipts you see is the last four digits.
There are some exceptions to this.
If you are in the US, under US federal law, the receipt can have the last five digits with the first digits masked.
In Europe, some countries require the original signed receipt to have the entire PAN printed on it because it is the only legally recognized copy that the transaction was conducted. Those receipts have to be securely stored and then destroyed. This is all similar to receipts that come out of embossing machines (aka knucklebusters).
All of these approaches are allowed under the PCI DSS as Requirement 3.3 has a note that states, “This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point-of-sale (POS) receipts.” While it discusses “stricter”, it has been explained that laws and regulations also supercede the PCI DSS.
Hello,
I have a question regarding network equipment in a specific situation situation is part of the CDE or not. We use Wyse P20 terminals for our call center employees that handle credit card information. As you probably know P20′s use PCoIP protocol to connect to a VMWare View 5.0 environment. The communication protocol itself is encrypted with AES128 and it is graphics/bitmaps in nature, and different to RDP in terms of the data stream; the transmitted information is more bitmap/pixel related in nature. Where I am going with this is that I don’t believe you can get a PAN out of the datastream even if you would be able to unencrypt it due to the nature of the protocol. These terminals connect to a VMWare View environment in the datacenter that host Windows 7 VM’s. The application where they enter the PAN uses tokenization with a PCI certified 3rd party and uses a VT type of technology where we send the PAN directly from the VT to the 3rd party, we get back the token and then that token gets written in the actual database. We don’t process or store the PAN, but there is transmission between the VT in the View virtual machine and the third party processor. So the datacenter segment where these View VM’s seem to be part of the CDE. My question is regarding the P20 terminal data path to the View environment. In your opinion, would the network switches that the P20 terminals connect to be considered part of the CDE? How about the rest of the data path? Arguably because of the protocol you are not transmitting PAN data from the P20 to the View environment. The P20s are completely dumb, zero client terminals, can’t put key loggers on them or anything like that, etc… These terminals are in a separate office that connect to the datacenter where the VMWare View environment is across a private MPLS network, so there is a LAN in the local site and then the MPLS WAN and then into the View environment in the datacenter. The View environment uses non-persistent virtual desktops where when an agent logs out of their terminal the virtual desktop goes away and they get a whole new one the next time they log in. Trying to determine if I can get all the local office and WAN out of the CDE.
Thank you for your time.
Juan
Without seeing the implementation and the configurations involved, I’m making a lot of assumptions based on your description.
That said, the PCoIP protocol appears to be secure as you describe, so only the endpoints (Wyse P20 and the virtual desktop server) are in-scope for PCI compliance. All of the infrastructure in between those endpoints should be out of scope.
The risk is at those endpoints. The risks to the Windows virtual desktop should be obvious, so I will not go into those. What I do not know is what OS is run on the Wyse P20. I’m guessing it runs some sort of embedded OS, but not what flavor. Wyse uses Windows CE, Windows Embedded and a compact Linux derivative that I am aware and they may use others. What I would worry about is a keyboard logger getting put on the Wyse P20s. Usually these can be locked down to prevent this from occurring, but I have no idea as to what you have done to lock down the Wyse thin clients.
Thank you for your opinion and your time, it is much appreciated. There is no OS in the Wyse P20, it is a zero client. Here is the description from the manufacturer:
“Based on a hardware PCoIP ® engine, this stateless zero client requires no local operating system.”
If you want to read about it for your own knowledge and projects:
http://www.wyse.com/fulfillment/downloads/Wyse-P20.pdf
It has basically a Teradici chip (maker of the PCoIP protocol) that has all the rendering functions built in hardware. We thought it was a pretty elegant way to make things go away on the client side of the house since there is no local OS and the protocol is very secure.
Yes, the Windows virtual desktop has all the controls necessary. Our objective here was to reduce the CDE to that infrastructure in the datacenter that is much easier to manage.
Thank you again!
Even with everything in Firmware, I would still monitor the Wyse datastream just to make sure that the thin clients are not trying to communicate somewhere other than the virtual desktop. Wyse and other vendors always paint a pretty picture on firmware, but this pretty picture is starting to get frayed as attackers figure out ways to compromise these systems. This is the mistake that people make in security. They assume that the thin device cannot be leveraged only to get burned down the road when some attacker takes the time to exploit the firmware. With proper monitoring, you should see any new datastream and have time to investigate it.
I have questions about the badge requirement in section 9.2. First, does PCI actually require employee badges if the company uses visitor badges? I’ve found discrepant information out there. If the answer is yes, I would imagine that many companies struggle to comply. Are there compensating controls that can be used?
Some QSAs say that badges need to be worn by everyone. However, what requirement 9.2 says is. “Develop procedures to easily distinguish between onsite personnel and visitors, especially in areas where cardholder data is accessible.” Now the tests imply that to do this you should issue everyone badges and that visitor badges need to standout. IMHO, as long as visitors stand out, I’m not as concerned about employees having badges as well. In most instances, the people with access to the cardholder data environment (CDE) have card keys that allow them to enter the CDE and visitors do not have card keys. The key here is, in the event of a breach, would it be possible to identify everyone involved quickly? If not, then everyone should have a badge.
Does an application that runs on a Kiosk using a hardware encrypted front end, and never actually has any ability to be able to decrypt credit card information (as the decryption key is stored at the processor) have to undergo PA-DSS validation. Essentially the application is only acting as a pass through as all the encryption is being performed at the swipe and can only be decrypted upon arrival at the processor.
I am assuming by the phrase “hardware encrypted front end” you mean that the “wedge” where you swipe the card creates an encrypted connection between itself and the processor. If that is the case, then you are correct that the kiosk is out of scope and the software on the kiosk does not need to be PA-DSS certified. However, that said, testing must still be performed to prove that fact. The PCI assessment process is all about “trust, but verify.”
In regards to PA-DSS certification. Applications that process, store or transmit cardholder data and are commercial developed and sold to merchants/processors are only recommended to be PA-DSS certified. This just saves a bit of effort on the QSA’s part when they assess the application. If the application is not PA-DSS certified, then a lot of that review process must be performed by every QSA assessing every merchant/processor that uses teh solution.
I have a question regarding cloud-based mobile payments. What you you consider to be the key payment industry requirements to keep in mind when designing a cloud-based mobile payment solution/platform? Clearly this is constantly evolving, but your high-level insights would be very helpful.
AO
I am on the Cloud SIG and we have defined the key attribute of the cloud as the ability to prove that the cloud is physically or logically segregated similar in concept to network segmentation. If that segregation cannot be proved, then PCI compliance becomes difficult, if not impossible.
We’re a small non-profit, I’m struggling to figure out if we fall into SAQ A or SAQ C.
This really comes down to one question – if a staff person takes a phone registration and enters the PAN into a web browser connected to a PS-DSS compliant third-party conference management tool, is the organization transmitting the PAN and this automatically bounces us at least to SAQ C.
My guess – is that:
1) we are transmitting the PAN, we are in SAQ C territory
2) these desktops are encryption endpoints, they are entirely within the CDE and must be on isolated network segments.
Thanks, by the way, this site has been a huge help!
It is up to your acquiring bank to confirm what SAQ you need to submit. They are the only ones that can make this determination. Unfortunately, a lot of acquiring banks have little knowledge regarding PCI, so they defer to QSAs and merchants for advice.
I have a non-profit client that is in the same situation where they have call centers that take donations but all credit card processing is outsourced. Their acquiring bank and processor were basically useless in helping with this decision. They fill out an SAQ C because, after discussions with management, they decided that their call center PCs fit the SAQ C model better than the totally outsourced SAQ A model. The deciding factor was that the call center PCs can provide a gateway to their processor and management wants to ensure that they allocate resources to ensure the security of those call center PCs. Management felt that without that determination, future management teams could skimp on security and cause a problem for the non-profit.
I know that might not what you want to hear, but that is my client’s rationale for SAQ C versus SAQ A. I hope this helps.
Thanks – very helpful – and good to know this is a grey area for more than just me. The decision to go with C makes a lot of sense, and it can be a helpful tool to ensure everyone is taking card security seriously.
I was wondering how different the implementation of PCI DSS would be different from server to cloud environment, what would be advantages & disadvantages of each one?
There really is no difference. What drives PCI compliance in the cloud is whether or not the cloud is physically or logically segregated from other clouds. I have a couple of posts on the cloud and PCI compliance.
http://pciguru.wordpress.com/2009/10/15/cloud-computing-and-pci-compliance/
http://pciguru.wordpress.com/2011/01/15/more-on-%E2%80%9Cthe-cloud%E2%80%9D-and-pci-compliance/
What are the criteria under which the PCI treats 3G network & which controls are applicable
Any 3G network that is used for the transmission of cardholder data is in-scope for PCI compliance. All the controls and conditions for any network are involved regardless of the transmission medium.
Hi PCI Guru !
What would you say the biggest changes between PCI v1.2 and pci v2 are?
The biggest issue we are currently dealing with is the requirement of the organization being assessed documenting and confirming the scope of the cardholder data environment (CDE). V2.0 of the PCI DSS requires the organization to document how they determined the CDE. The QSA is then responsible for confirming that the scope of the CDE as the qSA conducts their PCI assessment. A number of our clients are using their data loss prevention (DLP) solutions for this purpose. Although for most, this is the first time they are turning their DLP solutions loose on their entire network, so they are encountering problems. Where we are encountering the biggest issues are with clients that do not have a DLP, which are most of our clients. They are using open source solutions for finding cardholder data as well as commercial solutions to get this done.
I have asked several QSAs as well, and it appears to be a grey area overall. Thanks for the update and really appreciate your blog!
A question came up about RDP access into our PCI environment. Normally are SSL certificates required in that scenario? Would this be an adequate solution also: http://en.wikipedia.org/wiki/Network_Level_Authentication ?
If we are talking about accessing cardholder data environment (CDE) servers from another internal network segment, then SSL certificates are a nice enhancement, but I would not consider them required. What I do require is that RDP and Terminal Services are configured so that only high-encryption connections are allowed.
If you are talking about accessing the CDE from an external network (i.e., any network NOT under your direct control), then RDP is not acceptable for remote access.
I was on a call today with one of our Windows technicians and he told me that yes, you do need to have a certificate in order for the high encryption only option to work right. That certificate can be self signed as long as you are only talking internal use, but it is required. You really do learn something new every day.