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.
I just heard that I will have to upgrade my ATM’s again to support PCI/EMV compliance, my understanding is that Windows XP will no longer be supported so I have to migrate to Windows 7. In order to support windows 7 I need a dual core processor. Does this make sense?
Thanks in advance
The upgrade to EMV should just be a reader swap and possibly a software upgrade. That said, I have not heard that Windows XP Embedded (what most ATMs run) is necessarily dead from a PCI compliance standpoint (although it is up to the QSA to determine if risks are mitigated). That said, I would guess that any ATM vendor would do a operating software upgrade at the same time they replaced the card reader. Windows 7 Embedded Enterprise comes in a 32-bit version, so I would guess that is what your ATMs would be running which should be no more processor intensive than XP Embedded. However, if you are pushing video out to the ATM, then 64-bit might be required and that definitely works best with multi-core processors.
Does a service provider’s level of compliance have any impact on the SAQ a merchant qualifies for?
No entity’s PCI level has any influence on another entity, UNLESS the entities are all legally related. For example, if Entity A is a service provider and is not legally related to Merchant B, the two organizations’ levels do not influence the others. On the other hand, if a holding company has merchants A, B and C, those entities could be considered by the card brands or their acquiring bank(s) as legally related and then their individual merchant levels could influence the others. I hope that answers your question.
I have a question: reading PCI, it referenced transmitting credit card information over VoIP systems, and suggested that clients should only use encrypted (or private) systems. There are lots of VoIP (Hosted) telephone systems that allow a client to accept calls in a call center, and talk to a purchaser, via Internet connections. Does the actual real-time verbal discussion of the credit card information in that conversation fall under the definition of “transmission across VoIP”, or does the PCI compliance directive only refer to transmitting recordings or records across a VoIP or Internet-based network unencrypted?
I think the directive only addresses recordings or credit card info records, not the actual live call that traverses a VoIP system, where the card holder speaks the info to the call center worker.
Plenty of call centers use Internet connections to add remote workers to call center queues. Clearly, there’s no way to encrypt a live voice conversation between a SOHO worker and a call center, as there would be with a data stream like IP-SEC/IP VPN/CITRIX- type transmissions, which are readily encrypted.
Is it permissable to accept credit card information over VoIP systems that use Internet to connect phones to Hosted PBX?
Thanks for your blog, I’m trying to get a hold of all this PCI compliance right now and some of your articles are a great help. I do have a question that I can’t seem to figure out, regarding scoping.
How would you handle a web server that takes in CC info, and then immediately transmits it to a payment processor? The web server only has the unencrypted data in RAM while it prepares to send it off, and then receives an approved/denied message.
Since this web server needs to be accessible, can it be PCI Compliant and still a web server? Or would I be forced to move the payment processing/transmission into an internal server on a DMZ? It will still need Internet access, though, to send the data to the processor.
Since it’s not ‘storing’ CHD, but just retransmits it, is it OK to have it publicly accessible?
Any advice or pointers to articles that can help me understand how to bring this into compliance would be great!
I recently requested troubleshooting credit card numbers from my processor, but was told that in a production environment, these non-functioning numbers shouldn’t be used; rather, we should use a live company card. I have always been under the impression that when troubleshooting a credit card transaction, it should be done with a test number. Anyone have similar experience?
Test numbers should only be used in a test environment as they will go to the processor over a known test connection and therefore be acknowledged as “valid”. When a test number is submitted through a production network, the processors will decline the transaction because it is a test account. If you want to debug in production, you do need to use a live card number.
Much appreciated!
Hi PCIGuru,
I have a query related to merchants required to fill up SAQ A and submit it to their acquiring banks. Do you have a list of Mail IDs of Acquiring banks where the filled-up and signed SAQs could be sent? Also, what if your acquirer bank doesn’t accept or know about PCI compliance and doesn’t have a Mail ID. Which is the best place/Mail ID to send such requests.
In the above scenario, I’m assuming that the merchant is well aware of the PCI-DSS standards and wants to be compliant and safeguard himself from legal liabilities, but the Acquiring bank is completely ignorant.
Also, can the Internal Auditor of the company or the Security Consultant of the company sign the SAQ A. As per your earlier posts, it appears that PCISSC has no say on this and wants Acquirer banks to take a call on this. What if the acquirer bank doesn’t take a call on this.
Below is the list of Acquirer banks for visa in South-east Asia. I was looking for something similar for all the banks across geographies (especially India).
http://www.visa-asia.com/ap/sa/merchants/gettingstarted/acquiringbanks.shtml
The answer to all of your questions is to ask your acquiring bank these questions.
In some cases, your completed SAQ will be sent to your banking contact at the acquiring bank. In other cases, they may have a PCI Compliance group that will receive your completed SAQ and review it. Unfortunately, you will find that every acquiring bank is different.
Who signs the SAQ is up to what your acquiring bank will allow. However, it has been my experience that most prefer that an official of the organization such as the Owner, Chief Executive Officer, President or Chief Financial Officer sign the SAQ.
I’m really not that surprised that a list of acquiring banks is available for Southeast Asia. Asia really does not get the security concerns of making such a list available to the public. As a result, you are not going to find such a list for any other regions because they do not want such information in the general public’s hands.
Hi PCI Guru
I don’t know if this has been dealt with over here, but here goes.
In the Process of 3D Secure for Card Not Present Transactions, it is mostly required for you to insert an OTP as a second layer of Authentication. If you intercepted this and pre-populated the 3D Secure page, it would negate the whole reason for the second layer of authentication. But in the situation where a Mobile phone is used for shopping, 3D secure is very difficult or almost impossible, as you have to leave your APP/Browser go to Message (basically remember or Copy your OTP) and then go back to APP etc. This is cumbersome and just plain not practical. Is there a way around this to shift the liability back to the Card Issuer and Not use or Automate the 3D Secure Authentication part?
I appreciate you knowledge on this subject.
Good question regarding 3D Secure.
While I understand the questions you pose, I’m not a developer of Web applications and definitely not a developer of mobile applications. My guess would be this is why “there’s an app for that” as that is the only work around I can think of for handling 3D Secure outside of through a browser. Windowing is NOT a phone’s or some tablet’s strong suit and most users do not understand it when it happens. Even I have screwed things up on my Android phone when it’s occurred.
That said, the card brands will never agree to shift the liability back to the issuer. They want as much of the liability out on the consumers, merchants, service providers and anyone else involved.
Thank you
So does a level 1 merchant or level 1 Services Provider (or level 2 if not performing a self assessment) are deemed to have non-compliance findings in the ROC, do they submit that ROC to their acquirer or payment brand or only the AOC with section 4 completed? Or both?
Thanks,
That depends. Each card brand or processor has their own rules as to what you need to submit to them, so you need to contact them to know.
Greetings Mr. PCI GURU:
Can firewalls terminate multiple areas of business as long as the interfaces connected to are dedicated?
For example let’s say we have a pair of firewalls that terminate corporate internet traffic, can we also terminate remote VPN connections/IP Sec tunnels on the same firewall along with vendors connections and card holder data traffic all to the same set of devices as long as they are segmented from each other using the shared firewall and vlan’s or do we need to plan for dedicated firewalls?
Depends on your level of paranoia. We have clients that do it both ways.
My only concern would be VPN processing on the same device. We have run into instances where too many VPN connections cause the firewall to drop into packet sampling mode so that the VPN connections don’t drop.
As long as you don’t mess up the logical separations of the VLANs and maintain strong ACLs for those VLANs, you should be fine. However, until a QSA can assess what you’ve done, this is all hypothetical.
Requirement 3.4 – correlation of Truncated PAN and Hashed PAN
Whilst I can see the point of requirement, I am struggling to see any practical method of squaring the circle, especially within a P2PE Validated Solution context, at least where that solution can be integrated with a POS.
The truncated PAN is always present outside of the P2PE as it is the POS that prints the receipt.
The hashed PAN is generally present outside of the P2PE so that the merchant can use it for fraud detection and other analysis purposes.
Both of these are widespread, legitimate business requirements.
However both pieces of information are now given in a correlated fashion to the POS, and therefore I cannot see how any solution that satisfies both business requirements can help in reducing the scope of PCI-DSS.
Tokenisation only helps if it totally replaces the hash, which in my experience is rarely the case; usually it is an additional piece of data, or I discover that the ‘off-line’ token is actually a hash.
As I understand it, the intent is to prevent a hacker from knowing which truncated PAN is associated with which hash to prevent/increase the cost of rainbow table or indeed brute force attacks.
Storing the data in locations that are securely distinct will either completely break the correlation, and thus the business requirement, or simply add complexity by providing indirect correlation e.g. each piece of data can be tied back to a third piece of data, usually the retail sales txn, but not directly to each other.
Frankly any hacker that has broken through sufficiently to grab the data from one database is unlikely to be phased by having to hack another database, so I am not in favour of security through obscurity.
So I am thinking that the only practical compensating control is to have a sufficiently large salt that the loss of entropy from revealing the truncated PAN is compensated by the entropy of the salt.
Would this work?
Any other ideas or comments?
This is one of the challenges going forward as organizations get rid of cardholder data and substitute hashed PANs, truncated PANs and tokens. You rightly point out all of the risks present by still having certain amounts of data in files and databases and how that could be correlated to break hashing and/or tokens.
Possibly the only reasonably secure approach to resolving this issue is to push it off to your processor(s). If processors use proper encryption keys and huge salt values, then the hash values and tokens will require the attacker to go after processors, not merchants.
A couple of years ago I wrote a post that discusses this very topic. I think the biggest shock will be that merchants still have skin in the game even though they are doing everything possible to totally get out of the PCI compliance process.
Question regarding QSA’s. I get that if there is a breach, the merchant could potentially be raised to level 1 status and be required to undergo an onsite QSA assessment and put through the whole ROC process. However, what would happen to the QSA, or the merchant, if the QSA didn’t perform the assessment to the appropriate standards? Understanding that the actual audit is a point in time and the merchant could change something in their environment causing or leading to a breach, but are QSA’s held accountable by the SSC? If a QSA does not perform to the standards that are expected of them, could they potentially lose their certification? I ask because I have worked with several QSA’s and some are understanding of how the environment is set up and others require the merchant to follow the letter of the law. I assume it’s so that they protect themselves and can prove that they performed the audit to the best of their ability.
Does this relate to the ROC QA process performed by the SSC? If the QSA documents a ROC and passes a merchant but the SSC reviews the ROC and identifies that the audit performed was not appropriate, can the QSA lose their status? If so, does the merchant lose their compliance status or do they maintain this and have to be reviewed by another QSA?
Hopefully the question is not too confusing.
Thanks,
Also, do all ROC’s undergo a QA review by the SSC? I believe that the QSAc must perform an internal review of all ROC’s but does the SSC perform this for all ROC’s or for only a sample?
Thanks!
The QSAC is required to have their own QA process. When the PCI SSC performs a QA review, they pick a time period and take all of the ROCs produced during that period for review.
That is a really good question.
First, only merchant levels 1 and 2 are required to conduct a ROC (as of July 2012 MasterCard requires a ROC for level 2 merchants). The remaining merchants would not likely have a QSA involved in an SAQ. As a result, any level 3/4 merchants would be the ones now required to do a ROC and there would be no QSA involved in their breach.
For those level 1/2 merchants that are breached, I would assume that the QSAC’s work papers would be put through the PCI SSC QA process to confirm that they had done what they said they had done in the ROC. If a critical or severe issue was found during that review, I would also assume that the PCI SSC would sanction the QSAC/QSA(s) involved. If the ROC is found to be inaccurate, then the merchant is deemed to be not in compliance. However, the forensic examination that is also performed could find that while the ROC might have been inaccurate, that the merchant is still complying with the PCI DSS.
As a result, it’s not a black and white decision. See my post ‘How To Be PCI Compliant And Still Be Breached‘ for how this can happen.
Thanks for that. So no real clear cut answer, yet. I assume the SSC will be looking further into this.
Just a quick clarification point. Level 3/4 merchants (level 2 service providers) also have to produce a ROC or only the applicable SAQ and AOC? Thanks!
It’s more like the PCI SSC and the card brands make up the rules as they go based on the situation.
Level 2 service providers produce a ROC if they want to be listed on Visa’s and MasterCard’s service provider lists. Otherwise they can do an SAQ D.
The only time Level 3/4 merchants are forced to produce a ROC is if they have suffered a breach. Level 3/4 merchants can go through the ROC process if they want and we have a few clients that do that as part of their security program. They issue an SAQ D to their processor(s), but they want all of the testing in the ROC assessed.
Hello there,
I was wondering what your opinion is on the below… I’m having a big debate as to whether or not, we should also enforce the same rules that apply for Production Cardholder Data, to Test Cardholder Data. I mean, as to whether or not we should enforce a policy that says that Test Cardholder Data, should be encrypted, one-way hashed or Masked/Truncated during transmission between our Employees in the Company and our Customers, Banks and so on. My opinion is that we should apply the exact same rules we have in our Production environment, also on our Test environment. The reasons why I believe we should do this are the following:
1. Practice makes best – Unless you apply the same rules over and over and over again, you might find yourself in a situation where you will not Mask/Truncate the PAN, even though it was a Production PAN, because different rules apply for Test/Production PAN and you just got confused or were too lazy to apply the same rules
2. A Test PAN can become a Production/LIVE PAN at any given moment. So you might find yourself exchanging am e-mail that contains a PAN, which when the e-mail chain started was TEST, but now it is Production
3. It is easier to configure your IPS/IDS/DLP or whatever this way, rather than keep a huge list of Test Card numbers out of the checks, so that no alerts are fired. This might lead to False-Negatives if the Test PAN becomes Production/LIVE PAN, to an unstable/heavy rule-base/policy which might include a gazillion Test Cards in it, not to mention the administrative headache because someone (the Security Team) will have to maintain this list, as everyone else is too lazy to do something
4. It keeps things simple – (KISS) [Keep It Simple Sam]. It is far simpler for Users and everyone for that matter, to have a single rule that having a what-if, then, else rule to follow throughout the day and during the interactions with our Customers and Banks
Those who “fight” the Policy keep saying that Test Cardholder Data are not Cardholder Data, as the PAN doesn’t belong to a Cardholder (so what…???).
I find this just an excuse so as to avoid asking the Customer or the Bank to send Test Cardholder Data Masked/Truncated, as it will be just easier for them to send everything in-the-clear.
What is your opinion on this?
I’m all for keeping it simple.
The key question to ask is did you get your test data from your processor or card brands? If you did get them from your processor or the card brands, then those accounts are truly test accounts and should NEVER become real accounts. Real test accounts are set aside by the processor/card brands as test accounts for the explicit purpose of testing and nothing else. Try and use them as a real credit/debit card and they will be declined.
Now, that said, your test environment that you use for ensuring your systems work properly should operate the same as in production. So if you are encrypting/truncating/tokenizing the cardholder data (CHD) in production, it should be encrypted/truncated/tokenized in the test environment as well. The good news about the test environment is that if you need to log the test PANs, there is no risk that if they get out in the wild that they can be used as a real credit/debit card as they are test accounts. That means your debug logs and other diagnostics do not have to be treated like state secrets.
Otherwise, if you did not get your test accounts from your processor/card brands, then I whole heartedly agree with your points and protections. But I would recommend that you contact your processor and get real test accounts.
Hi
Need some advice pls – looking at having a thin client solution for the areas of the business that process payments. HP t510 WES7. Image is locked down very tight, only necessary drivers are installed, USB ports are locked. Image is read only and is pushed to the thin client. Image is refreshed every time the device is restarted (daily). Only other access the user has is to an external site via HTTPS via IE9. the 2 external sites are hosted at a PCI DSS certified site.
What I am trying to establish is can I do without having AV installed on the Thin Clients as they are read only and every day the device is reimaged.
Image is pushed out by HP Device Manager.
Where the image is housed the box has AV on it. Connection to the external sites is through a firewall.
So is it necessary to have AV installed on the thin clients as I cannot see the benefit AV would give us as the devices are read only.
QSA is saying we need AV as a virus can write to memory.
I believe that we can do without AV.
Please advise.
Thanks in advance.
You are going to have to use a compensating control for these thin clients. We have a number of merchants that use thin client technology based on Windows Embedded and similar Linux versions, so your situation is not that unusual.
You have a lot of the compensating controls already documented in what you posted here.
However, one concern I have is that you allow them out to the Internet and your QSA is correct in pointing out that these thin clients could be infected as a result. You mention one or two external sites users access, but you did not explain how or if the thin client access to the rest of the Internet is restricted. Is it restricted by the IE configuration (I’d be concerned about relying on that), white list at a proxy, firewall rules, etc.? Do you monitor their access to the Internet and alert on if they try to go anywhere else? All of these would be additional proof of “above and beyond” the PCI DSS requirements.
Assuming we get the Internet access restriction issue resolved, is there anything that these PCI compliant sites do such as daily vulnerability scanning, critical file monitoring in real-time, AV or similar that you could rely on as well to show that the risk is minimal? Unfortunately, just because these sites are PCI compliant, they could be just doing the bare minimum and that would not necessarily reduce the risk to your users as they could easily become a carrier of viruses and malware.
HI
These sites are the only sites that the user can access as the user is locked down via whitelists. User goes out of the network via firewall. Firewall is locked down as well.
The external sites do FIM on a daily basis (I believe).
We do monitor ALL internet access.
Where can I view these compensating docs if possible?
The compensating control format is in Appendix C of the PCI DSS v2.0 PDF and the instructions are in Appendix B.
I would not worry about relying on the sites doing FIM on a daily basis as that will not assist in your cause.
Also see my post on compensating controls – http://pciguru.wordpress.com/2010/09/02/writing-a-compensating-control/
Hi,
I am severely struggling with our PCI at the moment and wondered if you could offer some advice.
I have a rather complex question regarding our current PCI situation within the group of companies I work for. We have 4 companies in our group who all reside in the same building. We all share the same physical network and internet connection however each company has its own windows domain, exchange email server and application servers. All files, folders etc are locked down to user/group permissions and we follow SAQ C for our entire environment at present across all companies regardless of if the company is SAQ C or less.
Company A and B use a standalone PDQ machine which runs over a telephone line. They are SAQ B and are compliant (we are compliant to SAQ C for them both).
Company C is our Ecommerce side of Company D. We have about 8 users who occasionally enter payment card information into our website in a browser and take payments over the phone. Our website is hosted elsewhere at a hosting provider in Manchester and the platform has been PA-DSS certified. The connection is secured using HTTPS.
Company D is a retailer and we have some POS tills that run POS ready 2009 in our shops. These tills are standalone units and operate on their own in the shops with their own internet connection which is firewalled. This company is SAQ level C however we do not hold any payment card information at our head office or out in the shops on the POS tills. We do however do 800,000 transactions which I believe is why we are SAQ C even though we hold no card data.
In essence we have a head office where companies A,B,C,D operate and we have our ecommerce website hosted elsewhere in Manchester. We do not store any credit card holder information in any of our systems. The only time we ever enter payment card information is when we have to take an over the phone payment in our Ecommerce call centre (in head office for company C) where it is entered in to the website in a browser. The number is not kept nor written down.
All our pc’s and servers/networks are at SAQ level C compliance at the moment because I believe that as all companies share the network we have to be (is this right?). Our current PCI configuration with our QSA has three separate company accounts (one for company A, one for company B and another which combines company C and D as one entity under SAQ C) and means that we scan all of our public ip address range at our head office even though we hold no card data here in any of the companies. However, like I said we do take payments and enter them in a browser in one of the companies at head office. We also scan our website ip address for the website in Manchester which is hosted by a large hosting provider who are PCI compliant.
We have recently been made aware that Windows XP goes end of life in April 2014 and therefore won’t be PCi compliant anymore I fear. My question therefore is, is our current PCi set up correct or should we change it? We really do not want to upgrade 170 workstations to Windows 7 especially as we don’t hold any card holder information and PCI DSS 6.1 requirement states that all operating systems must be up to date and we obviously won’t be able to do this is XP is end of life.
I wondered, if we split Company C and D and had a new separate account for our Ecommerce platform as PCI-DSS CVT and I logically separated them using a firewall between the rest of the network AND upgraded their pc;s to windows 7 would this address the issue or would company C still need to upgrade from windows xp to windows 7 or indeed would every computer in the entire network need to be upgraded to windows 7?
Sorry for the complicated question and many thanks for all your posts, i have read most of them and they are full of very good info!.
Paul
If I have a standalone (bluetooth) handset connected via my network to the internet & to my provider, using my router & static IP, that uses the same subnet as my single PC & Printer (that does not process any transactions) via a cable connection & I do a single cardholder not present over the phone once a year (not storing any details) do I go for SAQ C?, if I switch back to telephone connections do I do SAQ B? If I enable WiFi do I have to do it all again?
Im a 1 shop retailer with no support system, no time & no money, how the heck do they expect me to be able to fathom the details
Hi again,
First off, thank you very much for your response to my earlier question.
I’ve run across something else that I can’t seem to find the answer to, but is just nagging at me. There is this dandy section of the PCI-DSS called Section 10, and it is completely missing from the SAQ C document. The only reference to logging is that anti-virus software must maintain audit logs in accordance with section 10.7, which only says they have to be held for a year (and not even moved off to an external log host, since that’s in section 10.5).
I am supposed to interpret this as: “If I’m only subject to SAQ C, don’t worry about logging” anything other than AV?” I swear I wasn’t trying for a clever rhyme there…
Thanks again for your time and expertise!
-Tarek
This is where it gets messy/ugly with businesses that operate with different card processing models in different locations. Because you have other operations that require compliance with more requirements, you are aware of the additional requirements and then apply that knowledge across the board. Your options are: treat your SAQ C business unit(s) as a true SAQ C OR adopt a hybrid approach and implement additional controls that are not required in SAQ C.
My preference would be to take a hybrid approach because more security is usually not a bad thing. That said, the risk in an SAQ C environment is that a keyboard logger is installed and records card swipes and cardholder data manually keyed. Given the new threats with vSkimmer and similar malware, in addition to AV you may also want to consider critical file monitoring as well on these systems. Logging should be as much as you can keep at these locations with some sort of periodic monitoring and alerting for serious issues such as finding vSkimmer or similar on these systems or other suspicious activity.
This isn’t perfect, but nothing ever is.
HI,
I’ve been trying to wrap my head around determining two big questions regarding what we need to do for our PCI compliance efforts.
A) If we have multiple lines of business, can any of them be split off for us to be considered multiple “merchants”? (The goal would be to move from, say, level 1 to level 2 or 3.) Do you have any advice on what sort of business boundary would have to be in place to be able to have that split?
B) If we have different locations transacting business in different ways using different equipment and software, can we use different SAQs for each area, or do we have to use the highest level required from all of the different areas?
A smaller question, that I’ve been wondering about while I’ve read over your site, is whether or not you can point me to a source or a copy of the “PCI Standards Updates and Future Insights” presentation made by the PCI SSC. I only do PCI part time, so I don’t get to go to dedicated conferences like that.
Your insights will be much appreciated.
The rule about reporting is, if the entities are separately incorporated, then they can have separate ROCs. However, if you are going through this exercise to change your merchant level, that is not allowed by the card brands and will get you into a lot of trouble with the card brands if you do it. In the early days of the PCI DSS, there were some merchants that played games with multiple processors and other schemes to avoid being judged a Level 1 merchant. When the card brands found out, the merchants were supposedly treated very harshly by the card brands, but the actual punishments were never made public.
If you are not able to submit separate SAQs, then the organization reports all business lines on a single SAQ. What you may want to do is fill out separate SAQs based on each business line and then consolidate them into an SAQ D.
The presentations from any PCI Community Meeting are only distributed to the participants. I didn’t get to go to last year’s Community Meeting, but one of the people that did sent them out to the rest of the QSAs in the Firm that could not attend.
Quick follow-up: What level of SAQ has to be completed for each area? If I have an area that qualifies for SAQ C, and a separate CDE that is SAQ D, do they both have to be completed at the SAQ D level (the highest level that any place in the organization has), or can each CDE just meet its own requirements? I assume that if the different areas shared a common set of support servers (DCs, Patch management, etc.) that they would have to all meet the highest SAQ required for the organization.
You can have each business unit fill out whatever SAQ best fits their business model. Then you combine all of the results from those individual SAQs into a single SAQ D.
Yes, for shared elements, I would use the SAQ D as the template for assessing them.
However, before implementing this approach, you need to have a discussion of this approach with your acquiring bank so that you have their buy in. They are the only ones that can officially approve this approach. My guess is that they will not have an issue, but you need their formal (i.e., documented) approval just in case the card brands complain.
Couple of questions. Is it possible for CVV data to be found on Web servers or Kiosks or would it only be on authorization servers? Not saying that it should be allowed to be stored there, but should the assessor look there for those or is it a waste and only focus on auth servers? I’m guessing, look everywhere and anywhere to make sure. But I guess Track data wouldn’t be on a web server, or would it??
Also, are web servers always in scope for PCI DSS? If the web server does not store, process or transmit card data, or if web servers that do not handle card data are segmented from those that do, then the focus is only on those that do handle card data?
CVC/CVV/CID can end up anywhere it is entered manually or the card is swiped. Even if only transmitted, it always ends up in memory for some period of time. That is where the latest malware such as vSkimmer looks for cardholder data is in the memory of computers attached to card readers. However these malware solutions could be easily modified to look for cardholder data in the memory of Web servers.
You are correct. Track data and PIN blocks are not going to be found on any systems that are exclusively doing card-not-present transactions such as a Web shopping cart application.
Whether or not a Web server is in scope depends on the process,store or transmit cardholder data as you state, but also if it has access to the cardholder data environment. We have had a number of heated arguments about whether or not Web servers that pop a separate frame/window with a payment processor are in scope. The answer is that they are in scope because if someone hacks the Web server, they could change the screen pop to go wherever and capture cardholder data.
I do apologise ..i didnt see your post on service providers and pci process until id posted this – thanks
HI
I am the Security Rep for a small – mid sized ISP who intends to offer a rack to the PCI-DSS merchants who wish to host their servers. We have had some interest and now need to look firmly at the compliance issues; not least of which PCI.
I am labouring under the assumtion that we fall into SAQ – D but specifically the physical security issues (and therefore will seek to have much non-applicability clauses); is that anywhere near accurate?
I am aware that the key responsibility to our tenants will be to underpin their endeavours with PCI compliance.
I cannot find any relaible literature to assist in answering “What is the definitive responsibility of hosting dat-centers within PCI-DSS”
thanks
HI,
if we have the wireless network and have the ACL in Layer 3 switch is it good or any other segregation is required or firewall is compulsorily. we are planning to implement the Wireless for Board Rooms and segregate with ACL between PCI Scoped area and wireless network segments.
regards
Girisih
As long as the ACLs for the wireless networks does not allow access to any segments that have access to the cardholder data environment (CDE), i.e., wireless can only go straight out to the Internet, then you should be fine.
If that is not the case, depending on the switch used, it may have firewall features loaded or available as an option. Enable those for stateful inspection of the wireless traffic and set up appropriate monitoring of wireless traffic ports. In this situation, I would also recommend implementing 802.1X authentication for wireless users so that you are not relying on a pre-shared key (PSK) for security.
And regardless of all of the above, please make sure that only WPA2 encryption is used for all connections to the wireless.
Got another misc. question. Requirement 9.4 requires visitors to sign a visitor log when entering CDE environments. We also have a card access swipe for the door to the data center where the CDE Server and network equipment reside, along with a log inside for visitors. One of our managers thought it would be good to reconcile the card access swipe log with the visitor log, especially if the log is not completed properly. What’s your thoughts on this? What are other people doing to maintain visitor logs? What’s the best way to meet this requirement?
Manual visitor logs still seem to be the way most organizations deal with this issue in their data centers. Since most data centers are pretty much “dark” these days (unless you’re doing an equipment refresh), there really isn’t a whole lot of traffic other than for auditors and QSAs to see you have equipment, it’s secure, consoles are locked, etc.
Reconciling the visitor log to the automated access system log is a good best practice. However, just because Jane Doe swiped her card and entered the data center does not always imply she had a visitor (unless Jane is an internal auditor or is the IT person that always escorts auditors). So in that regard, unless you know a visitor entered with Jane or you also review your video log to confirm that fact, it’s hard to know whether there should be a visitor name signed in the manual log.
That said, most organizations alert their IT staff to when auditors are on site. So that should be a trigger to know that at some time during their visit they will visit the data center. Then you can periodically review the visitor log and make sure that entries get put into the log.
If you train your people well, they will enforce the visitor log being entered. Also, most auditors are looking for such an artifact and want their entry in the log for proof they visited the data center. So you have that working for you as well.
My question is about USB devices. Is there a requirement to block usb ports on card holder data servers. I know it is a good idea but is it a requirement?
There is no requirement to block USB ports on servers, desktops or notebooks. However, I would think that controlling USBs on servers in a secure data center would be a whole lot easier than desktops and notebooks where the real risk is located.
That said, the PCI DSS does call out in requirement 3.4 requires all media to protect the cardholder data with either encryption, hashing or truncation. That would apply to your USB drives.
But you are right, blocking/disabling USB ports is a best practice.
So if my company puts verbiage in to the security policy that says “don’t use unauthorized removable media on the card holder server”, and all data that goes on to our current usb hard drive is encrypted at rest. Then we meet the requirement of 3.4?
That would be correct as long as you also meet the relevant requirements in 3.5 and 3.6 regarding encryption key management.
I have a question about the PCI best practices when re-purposing Servers from a PCI Domain environment to standalone environment. We have a Server, call it Server A, that was in a Domain environment with access to the CDE servers (Servers B and C). We have removed Server A from the Domain and want to re-purpose it to a standalone environment (no longer connected to PCI Domain. Can you comment on the importance of securely wiping the Server A and reinstalling the OS on it before moving it into a different environment to ensure good PCI practice? We are preparing for our 1st PCI audit the end of this year. Thank you.
Take a look at requirements 9.8, 9.9 and 9.10.2 for your answer. When you re-purpose a server, these requirements need to be followed. The most important of which is 9.10.2 which says you need to render any cardholder data unrecoverable. Simply doing an OS delete does not accomplish this, you need to use a utility that will do at least seven passes of erasure to ensure that whatever data that was on the disks are unrecoverable. This can get a bit tricky in storage area network (SAN) environments where there are multiple levels of virtualization/abstraction. However most SAN vendors have such utilities available for this purpose.
There are a number of shareware utilities available such as Eraser (http://eraser.heidi.ie/) and Cipher (http://support.microsoft.com/kb/315672). Or just Google ‘DoD 5220-22-M’ for utilities that meet this US Department of Defense standard for electronic data destruction. There are utilities for Linux, Unix, MacOS and just about every other OS.
Hello, thanks for the great blog.
I got some troubles about the right SAQ choice. Scenario: the merchant has POS (dial-up), receive the reservations with credit card information through fax and uses a web based virtual terminal through a service providers; only some PC on the backoffice could connect to the web portal to retrieve and print cc data.
There is no data electronic data storage.
I got some questions:
1. The SAQ C-VT could be applicable, but the virtual terminal is not the only payment processing, the merchant got also POS and imprint data. So I think the merchant should fille the SAQ D using as reference the SAQ C-VT and SAQ B, and fill N/A for many requirements, could be correct?
2. If the merchant should fill the SAQ D, which requirements are compulsory?
3. the workstations in the backoffice, got antivirus, up to date with ms patches, but those systema are not dedicated to access the web based virtual terminal. Should be? Possible mitigations, to continue access to the portal using normal working PCs ?
Thanks very much
Your problem is the back office PCs that retrieve and print cardholder data (CHD). You say there is no storage of CHD, but have you assessed whether those PCs in the back office have CHD stored? Just based on how you wrote your description, I would bet they have CHD stored. Look at my post regarding PCI scoping for a list of utilities that you can use to determine if CHD is stored. If you find CHD on those back office PCs, you’ll have to remediate that issue and adjust procedures to avoid the problem in the future.
Based on that, I think your option #2 is the most viable. I would have agreed with option #1 but those back office PCs just do not fit that option. What requirements are compulsory will be determined by going through SAQ D and determining if the test fits the environment. My guess is that you will find most of the tests to be relevant.
Thanks very much for your quick reply.
If the previous scenario will change as the following:
* the merchant has POS (dial-up)
* the merchant receive the reservations with credit card information through fax
* uses a web based virtual terminal through a service providers; only one system isolated from the network could access to the web based service (whitelist restriction access only to the public web service provider)
Could be SAQ C-VT reasonable? Or do you think the SAQ D (using SAQ B and SAQ C-VT as reference) is a better choice? I’m afraid that multiple requirements (ICT, process) could impact, and not all requirements could be marked as N/A.
For example if the better choice is a SAQ D, the ASV scan must be performed on the front-end merchant router?
Thanks
How is the fax machine secured? Can anyone take a fax from the machine?
Are the card numbers on faxes redacted and then copied if they are retained? Are the original faxes securely shredded once they are processed?
When you say the POS is dial up, is this a dial up credit card terminal like Verifone or Ingenico or a PC?
I think using SAQ B and C-VT as the template might be reasonable depending on the answers to the earlier questions.
ASV scanning is only required if any of the cardholder data environment (CDE) is Internet facing such as a Web server or eCommerce server. Workstations behind a firewall are typically not considered Internet facing. Not that vulnerability scanning is a bad thing to do, but justifying for PCI compliance without anything Internet facing and in-scope is not required.
Ahoy PCI Guru,
At the company I work at we currently have an old, home-grown, multi-value database system which is accessed through a terminal emulator and is used for order entry, inventory, and just about everything. Because of design flaws in it, more than likely, it is impossible to make it compliant. Our current goal is to create a process that would make it so when an agent goes to enter credit card information into the terminal emulator window it will instead open a browser to a secure website. The agent will then enter the data into the website and submit it. Our webserver will then go out to a third-party who we have contracted for tokenization and all that will be returned to the multi-value database system is the token we receive. Does this sound like a plausible solution and in your opinion what does it leave in scope for PCI? Would our scope only consist of the workstations the agents are using and the secure webserver we use to transfer the cards or would other items such as our AD servers, anti-virus server, and other such servers the workstations rely on still be in scope and would our multi-value database system still be in scope in any way?
Thanks much for any insight you can give me!
Any infrastructure systems such as firewalls, AD servers, etc. are in scope if they have access to the cardholder data environment (CDE).
As long as your legacy database is not in the CDE then it would be out of scope as long as you securely delete any existing cardholder data (CHD) and you go to the tokenization solution.
See my post regarding the PCI SSC’s Scope Clarification for more information.
I’m a Information Security Consultant in a Merchant Company. We have an web based application for e-commerce, which is integrated with a PCI Compliant payment gateway. All the CHD is stored on the payment gateway’s customised forms. We don’t access any of the CHD. We have filled up SAQ A (All cardholder data functions outsourced. No Electronic Storage, Processing, or Transmission of Cardholder Data) and comply with all the requirements specified in the SAQ A. We have submitted this SAQ to our Acquirer Bank.
1) Is there a way by which we can mention that we comply with PCI-DSS requirements on our webpage? A disclaimer or seal or something similar to demonstrate our seriousness towards meeting PCI requirements?
Can only a QSA put a seal on our website?
2) Also, how can we be sure of meeting all the PCI requirements? Will the acquirer bank review our SAQ A and revert. Also, if the banks don’t revert, isn’t it their responsibility?
From the PCI SSC’s perspective, you can make whatever statements you like. However, there is no official seal or certification that a PCI assessment produces and the PCI SSC endorses. Those PCI compliance “seals” and statements made on other Web sites are just made up and are meaningless. Unlike the Verisign and WebTrust seals you see which means the merchant has gone through some sort of rigorous assessment and shown to be in compliance. See this post for more information – http://pciguru.wordpress.com/2012/02/29/pci-dss-compliance-certificates/
I’m not exactly sure what you are referring to with an acquiring bank “reverting”.
My larger concern is if you have documented your compliance with SAQ A. What have you done to ensure that cardholder data (CHD) does not exist in your environment? Have you used a utility to scan your internal PCs to make sure that there is no CHD on them? I’m not implying that you do not qualify for using SAQ A, I just want to ensure that you have taken the necessary steps to prove you can use SAQ A.
In addition, when you say that your e-Commerce solution uses the payment gateway’s “forms”, are those forms at all on your servers or do you redirect payments to the gateway’s server(s)? If you redirect, then you should document that fact as well. If the “forms” are on your servers, then your e-Commerce solution is not out of scope and SAQ D should be used, not SAQ A.
If you create all of this documentation regarding your justification for SAQ A, then I think you will have what you need to address your acquiring bank “reverting” question.
Thanks a lot for your valuable inputs. We redirect payments to PCI Compliant Payment Gateways. There are no forms on our end accepting CHD… Therefore, our servers, its RAM, Hard Disk, Network or Application never come in contact with CHD. Still, To verify it and be on safer side, we would run utilities to scan for CHD.
My concern w.r.t Acquiring / Merchant Banks is that they themselves are not sure about PCI requirements, but by submitting all the relevant documents with detailed justification, we will be in a better position to demonstrate our compliance with PCI requirements and safeguard ourselves from any kind of card fraud related liabilities. Please correct me if I”m wrong here…
Thanks again….
Regards,
Varun
Clueless acquiring banks, who would have guessed? LOL An unfortunate fact of life these days.
I would just have the documentation available so that if your acquiring bank questions you on what you did, you have the documentation ready to go. It’s more for insurance than to immediately turn over. Nine times out of ten, your acquiring bank will just take your SAQ and move on.
Dear Guru, i have a question and i hope you can answer it as it is very important for me. I work as a PCI consultant at Cybsec and i have been trying to found a program which can help me to found PANs all over the customer network. But i want some kind of partable program (not to install it on customer PC), for example, to keep it on an USB device and be available to use the program in different customers pcs. Could you please advise me about any program? i have been searching for them with no luck. Please help me!
Thank you very much!
Federico
See this post http://pciguru.wordpress.com/2012/05/19/more-on-pci-scoping/. It should point you to potential utilities.
Thanks for the answers to my other questions. I have another question that you can hopefully shed light on for me. When using a product such as Paymentech’s iTerminal (https://www.chasepaymentech.com/iterminal.html) or Virtual Terminal (http://www.chasepaymentech.com/virtual_terminal.html), is the PC you are using to access them in scope for PCI compliance?
Technically, yes, as these PCs are an endpoint. However, the risk here is that a keyboard logger gets installed on the system that accesses these sites. So, as long as these PCs are patched current, have current anti-virus/anti-malware, local firewall and their Internet access is restricted to these two sites, you should be fine.
This explanation is well accepted and justified. However, there are various scenarios where the memory and hard disk space of such virtual terminals is extremely low (64 MB to 128 MB). In such cases, installing AV and desktop firewalls might slow down the terminals or bring them down. Not sure, how to address those cases.
Thin-clients are an interesting issue. Those that run versions of Windows Embedded are not entirely safe from all Windows vulnerabilities. Even Linux-based thin-clients have their own potential issues as they typically are running a full version of Linux and can therefore be a bit more susceptible to issues. AV in the Windows Embedded may not be available or even work. Most times, ClamAV can be run on Linux-based thin-client, but not always.
The way to deal with all thin-clients is to lock them down, restrict what they can access and monitor the daylights out of them at your firewalls unless you can put an actual monitor on the thin-client.
I have a question regarding PCI-DSS Requirement 4.1. What is the exact definition of an “open, public network”? I have the book “PCI Compliance 3rd Edition” by Williams and Chuvakin, and it defines an “open, public” network as “essentially any network that contains a gateway to the Internet at large”. So, is the only way to create a network that is not an “open, public network” to lock the network down from any outside access? For example, a workstation in network that is not “open, public” would not be allowed to have access to the Internet or any other resources except through an encrypted, controlled connection?
I am looking at this correctly?
An ‘open, public network’ is essentially any network you do not absolutely control and cannot explicitly or implicitly trust. That includes not only the Internet, but any other network you do not completely control such as your business partners, card processors, etc. Hopefully this Fall with PCI DSS v3 the wording will be changed to reflect that revised definition that came out a couple of years ago at the QSA session at the annual PCI Community Meeting.
The rationale for this expansion is that you have no way to know if how your connection to a business partner or your processor keeps you away from the Internet, if it does at all. Nor do you know how well their network monitoring is working, firewalls, etc.
As a result, you need adopt a “trust no one other than yourself” approach to better ensure your own organization’s security.
Thanks for your quick reply! I have one followup question. Does a computer that is behind a firewall and an IPS but is able to connect to the Internet for legitimate, controlled purposes count as being on an “open, public network” ?
Of course it is on an ‘open, public network’.
That said, are your firewall and IDS/IPS are providing some controls as to what the PC in question can access or only controlling inbound traffic?
It may seem like a funny question to ask, but this is not for humor as this is where a lot of people get it wrong. It’s not good enough to only control the inbound side of the equation, you also need to control the outbound communications as well through black listing, white listing or both as well as limiting protocols that can be used.
Hello, thanks for the great blog.
I was wondering about the scope of card data without the PAN.
For example; A company makes use of a hosted 3rd party payment gateway that uses card tokenisation to facilitate subsequent billing.
If the company wished to submit the CVV along with the token for these transactions would asking the customer for this number bring them into scope given that from their perspective there is no accessible PAN associated with the CVV they have collected, just an arbitrary token value?
Another example would be collecting an expiry date on a shopping site then passing that to a hosted payment form for pre-filling.
I guess I’m trying to resolve the terminology (from PCI v2 p6):
“PCI DSS applies wherever account data is stored, processed or transmitted. Account Data consists of Cardholder Data plus Sensitive Authentication Data”
Which identifies CVV/Expiry as card holder data/sensitive data, and then the next paragraph:
The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed or transmitted, PCI DSS requirements do not apply.”
Which seems to explicitly state that PCI only applies if the PAN is present.
You are correct. Cardholder data is only cardholder data if and only if the PAN is present in clear text or encrypted and your organization manages the encryption keys.
With tokenization, you should not have to submit the CVV/CID/CVC with the transaction. The token itself should be more than adequate. If that is not the case, then you should find yourself a processor that does work that way.
Sensitive authentication data is the CVV/CID/CVC if manually keyed and track/chip data if the card is swiped through a magnetic stripe reader or inserted into a EMV terminal if an EMV card.
Where you need to be careful is in the transmission portion of the definition. Depending on how the third party gateway is implemented, a merchant’s Web site may be in-scope for transmitting cardholder data. We have a lot of merchants think they are out of scope only to find that because of how the third party’s Web page is accessed that their Web site is in-scope. I have documented this in the post ‘Of Redirects And Reports‘ (http://pciguru.wordpress.com/2011/11/12/of-redirects-and-reposts/)
Our IP terminals were out of action recently because the bank silently updated our terminals with new IP details. The firewall was locked down to only allow the terminal access to the IPs & ports that we originally obtained from the bank. Unfortunately it took far too long to track the cause down to a change in where the terminals needed to talk to. We were given no advanced notification of the change. Is it possible under the PCI guidelines to have broad rules that allow the terminals outbound access, irrespective of IP or port? Or at least allow to the service IP irrespective of port (they changed ports for one existing IP, and added in a new IP)?
Would the fact that we are not notified of such changes to the IP/Port configuration be “business justification” for rules that only restrict by local source IP and not by destination IP/port? Thanks!
I would get a hold of your account representative at the bank and read them the riot act over their approach to “maintenance.” I would get your CFO, CEO, etc. involved in this conversation so that the bank understands that their stupid maintenance approach seriously impacted your business. If the account representative is not responsive, then your senior management can take it up with the bank’s senior management.
However, no, I would NOT change your approach. Your approach is the way things should be done.
Talk to your bank and get them to behave properly. No outside third party should be making changes like this without notifying you first and enough in advance so that you can plan for such a change. If they refuse, I would seriously start looking for a bank or service provider that understands the implications of their procedures and works with their customers, not against them.
I apologize if this has been answered. I couldn’t find it.
I have an AV server that distributes AV updates, policies, and accepts AV log events from the CDE and out-of-scope environment. This one server host the same services for both in-scope and out-of-scope devices. The AV server is in-scope because it directly connects to systems in the CDE. Does that mean the out-of-scope clients that connect to the AV server are in-scope? Technically, these systems do have access to the AV server which could be used as a pivot point.
This is the issue with the “clarification” made at the 2012 Community Meetings.
In theory, you are correct based on the limited information you gave. However, I would argue that, if your AV server is properly hardened and the number of people with administrator access is limited and their actions for this server tracked, then I would draw the line at the AV server and the rest of your devices are out of scope. If you wanted to be more secure, you could put one AV server NIC in the CDE network segment and another NIC in the non-CDE segment. If you are totally paranoid, you put up two AV servers, one for the CDE and one for everything else.
At the end of the day, the PCI SSC has left this up to the QSA to determine. So what I say here may not pass with your QSA.
I’m currently working on a post regarding that “clarification” because, while it has been referenced on the Web, no one has actually posted what was presented and the discuss about it.
We are an events facility and occasionally host outside vendors who will bring in dial up credit card terminals. I haven’t been able to find this information anywhere, and based on your articles and replies I wanted to pose this here.
If I provide an analog phone line for someone to connect a credit card terminal to, could I be considered a service provider? I know if it was LAN based and the terminal didn’t encrypt it I would be, but does this also hold true for a POTS line? I’ve been doing some digging, but can’t find the answer, so I’m hoping you can clear this up for me.
Thanks in advance!
No, you are NOT a service provider for providing someone with a telephone line as long as it is only a circuit. You are no different than AT&T or Verizon.
Thanks for the prompt reply!
PCI GURU
What do I need to do be PCI compliant?
I have two questions, First – I am building a website where I will be selling etickets from company X. I have 0 sales as this time but could hit 15,000 transactions in a year ( I ope
). Users will provide their card information to me which will be transmitted onto a company X which is PCI compliant. They will process the card and deposit a percentage of the sale to my bank account. At present I have no sales, what I do I need to do to be pci compliant? . I don’t decide what cards to accepts this is all decided by Company X. Am I a level 4 merchant? should I fill SAQ-D? How do I find out?
My second question- later on I plan to sell tickets for my own which I will use Stripe. I am not sure you are familiar with them they are like paypal but they use client site scripting to send the card information directly to their site without hitting my servers. They tell me that my system is out of scope of PCI compliance because of that.
Could you advise?
For the first question. You are strictly an e-Commerce merchant. You will be considered a Level 4 merchant until you process more than 20,000 transactions annually. After you achieve that threshold, you will be considered a Level 3 merchant until you process more than 1 million transactions annually. Level 3 is reserved for e-Commerce merchants only. Again, all of this is predicated on Company X agreeing to those definitions.
Since your application and server(s) come into contact with cardholder data, you are going to have to do an SAQ D regardless of your current business model or your future business model. That is because you are in control of the code/configuration of the application and therefore you need to attest to your application development and change management controls. No other SAQ has requirement 6 except SAQ D. Not that requirement 6 is the only requirement you need to worry about, but it is the main driver that gets you to fill out an SAQ D.
Thanks for your help on this PCI Guru. If I complete a SAQ D where do I send it? Company X tells me they are a service provider. Also how much would you charge for consulting for me ? I am the owner, developer, for my startup LLC.
Company X is where you should send your SAQ D and AOC.
PCIGuru,
Do I need to be PCI compliant? My company supports and updates the configuration of networking devices for customers that fall under the PCI requirement umbrella. I have one customer asking for an Attestation of Compliance (AOC) since we VPN into this customer’s PCI environment and manage their networking devices. I understand their concerns and I do want to provide them with this AOC. However, which AOC do I need? There are A, B, C, D and E. We don’t process any credit cards but my customer’s do. Am I require to do whatever the level my customer’s fall under? So, if one of our customers fall under level D, do I just do the SAQ and AOC for level D and submit to my customer? Do I need a QSA to come onsite and validate my environment. This is so confusing. Thank you for your replies.
Yes, you do need to be PCI compliant. The reason is that your personnel have access into your customers’ cardholder data environments (CDE) and they could have access to cardholder data either being transmitted (network devices or servers) or stored (servers). I think I will write a blog entry on this as it is more complicated than I can document here, so watch this space for a posting soon.
That said, no you do NOT need a QSA to validate you. You do need to determine what services you offer need to be PCI compliant, then look at SAQ D and determine which of those tests are relevant to each of the services you are attesting to in your AOC. Your AOC will then list all of the services that you PCI certified as compliant.
Thank you so much. I look forward to your blog.
What are some of the biggest changes coming to PCI in 2013?
Good question. I have no idea what the PCI SSC and the card brands have cooked up for the coming PCI DSS refresh this Fall.
Everyone points to cloud computing and BYOD, but the PCI standards indirectly cover all of that. So unless they explicitly call those technologies out, I just don’t see those as a driver. The real struggle for most organizations at the moment is complying the existing PCI DSS as close to 100% of the time as possible. So raising the bar isn’t really going to make things any more secure when organizations cannot get to the existing bar.
You may have covered this already, and I missed the post. We have multiple sites in our environment. At each site, about 1/3 of the users (CSRs) take phone calls that require credit card information and they also have internet access on their machines. We have outsourced our processing to a 3rd party, so we don’t store data, but the server that connects with the 3rd party is at our central data center so data is flowing across the network.
My question is, how much segmentation do we need for those CSRs. Do we need all new routers and switches, can we just use firewall rules to not allow access to other machines in the environment, do we need to cut them off from the internet completely (we have email in the cloud), or can we white list some acceptable sites.
We are also trying to figure out which SAQ we would need to fill out. I believe from what all I’ve read on here that SAQ D would probably be our best option, but we wouldn’t have to worry too much about section 3.
First the easy question. You need to confirm with your acquiring bank as to which SAQ to use. Based on what little you describe, SAQ D seems reasonable.
If your intent is to reduce what is in scope for PCI compliance, you need to segment the CSR systems away from everything not needed to be in your cardholder data environment (CDE). You might even want to consider isolating your IT support personnel systems from the CDE by implementing a “Jump Box” which is nothing more than a PC that sits in the CDE but allows remote access to the CDE for monitoring and diagnosis. Some support systems such as Microsoft System Center and similar will have no choice but to exist in the CDE to manage the CSR systems.
We have a number of call center clients that need to have the CSRs with Internet access. The best way to control this is through white listing of what they can access and be VERY restrictive on that access. In addition, you need to monitor the daylights out of the CSR systems so that there is a minimal chance they could be compromised.
In regards to any other servers in your CDE, if they do not need to be in the CDE, then make sure they are not in the CDE nor do they have any access to the CDE. Any systems that have access to the CDE are in-scope for compliance regardless of whether they actually come into contact with any cardholder data. Therefore, you want to minimize what systems have access to the CDE so that you can minimize what is in scope. Having access does not imply that every requirement is relevant, but you do need to make sure they are secured and monitored so that if they become compromised they cannot be used to compromise systems that do come into contact with cardholder data.
PCIGuru,
I’d like to see a post on P2PE, if possible. I searched your blog and didn’t come up with much.
I work in the network security field and am curious as to the future of PCI when the large majority of Level 4 Merchants implement a P2PE function as their sole processing method. Food for thought.
Search on end to end encryption or E2EE which is the more accepted IT term. The PCI SSC did not like the E2EE moniker because they felt that it implied that the entire data path was encrypted from start to end which is not necessarily the case. As a result, they changed their terminology to point-to-point encryption or P2PE to better indicate that cardholder data is only encryption from one point to another point.
I have added a Point-To-Point Encryption area and links to the articles in my Post Series References page.
How service provider(SP) level is determined? Each card brand mentions the level is based on their card brands only. Does that mean SP level is determined per individual card brand transactions without combining all card brand transactions together? For example, if a SP carry transactions of master card 200 and VISA 200, yet the SP is considered as level 2. Correct?
For Visa and MasterCard there are two service provider levels, 1 and 2. Transaction volume determines what level. Level 1 service providers are those that process 300,000 transactions or more annually. For example, if you are a service provider and you process 400,000 Visa transactions annually and 250,000 MasterCard transactions annually, then you are a Level 1 Service provider for both Visa and MasterCard.
American Express and Discover are in the process of establishing service provider networks. We expect them to have the same rules as Visa and MasterCard for service providers.
Where things are different with service providers is that, if your organization wants to be listed on Visa’s Global Registry of Service Providers and you are a Level 2 service provider, you will need to comply with the Level 1 service provider rules. That means conducting a PCI Report On Compliance, not filing a self-assessment questionnaire (SAQ) D.
Dear Guru,
Thanks for the reply.
Let me phrase my question with more clarity. If a service provider handles both master card and Visa, does the service provider level is determined by the transactions volume of both master card and visa?
In service provider level criteria mentioned in master card website, they mention “All Data Storage Entities (DSEs) with more than 300,000 total combined MasterCard and Maestro transactions annually”
The service provider level is determined the same as merchant level, by annual transaction volumes with each card brand. The highest transaction volume with whatever card brand determines a service provider’s level. For example, if you do 350,000 transactions annually with Visa and 250,000 transactions annually with MasterCard, then you are a Level 1 service provider because of the Visa transaction level. As another example, if you do 280,000 annual transactions with Visa and 275,000 annual transactions with MasterCard, you are a Level 2 service provider because neither volume crosses the 300,000 mark.
However if a service provider wishes to be listed on Visa’s Global Service Provider List, they must consider themselves as a Level 1 service provider (regardless of annual transaction volume) and file accordingly with Visa.
I work for a Level 2 Merchant and I am unclear as to whether we need to have an ROC and AOC. According to Visa’s web site, it looks like we need: Annual SAQ, Quarterly network scan by ASV and AOC form. But, on the AOC form part 3 PCI DSS Validation and part 3a Confirmation of Compliant Status reference the ROC. How would we complete these sections if we don’t have an ROC?
Also, how do we know we are compliant or not? Is the AOC enough “proof” or do we need to be validated in some other way?
If you accept MasterCard as well as Visa, something I would assume is highly likely, then you need to be doing a Report On Compliance (ROC) as that is now required for Level 2 merchants by MasterCard. See my post titled ‘Are You A Level 2 Merchant?‘. Even if you do not meet the Level 2 transaction volume requirements for MasterCard transactions, if you are classified as a Level 2 merchant by Visa, you are a level 2 merchant for all card brands you accept for payment.
The Attestation Of Compliance (AOC) is signed by an officer of your organization and is considered proof of compliance by the card brands and processors – in most cases. Occasionally, a processor or the card brand(s) may ask for a merchant’s self-assessment questionnaire (SAQ) or ROC to review the answers to the tests. Some card brands require the ROC to be filed with the AOC, but they will tell you that before you file your paperwork.
Thanks for the quick reply. So, now that we need the ROC, I have a few questions: It sounds to me like we would have a QSA complete the report and this person indicates whether we are compliant or not on each of the PCI DSS Requirements. If we are not compliant on any of the requirements, would we still submit the ROC to our acquiring bank for acceptance or do we wait until we are compliant on all requirements? Would the ROC be considered “passing” or “failing” or neither because it’s just a summary of info collected? Do you have a ballpark figure as to how long the process takes to produce the ROC?
You have a choice of sending someone within your organization, but independent of the areas to be assessed, through PCI SSC Internal Security Assessor (ISA) training and certification OR you can use a QSA. Since most level 1 and 2 organizations do not want to put internal people through annual certification training, most merchants hire a QSA.
You should conduct a pre-assessment to find out where your organization’s PCI compliance gaps are located so you can determine the amount of effort to either close them or mitigate them. Once you have that information, you can then determine how to approach your acquiring bank and explain how your organization will respond. Your acquiring bank may want you to file the ROC as non-compliant and then monitor your efforts to remediate those items. Or, your acquiring bank may allow you to clean things up so that you file a compliant ROC. Most times, it depends on the amount of time required to remediate issues that will determine what your acquiring bank will allow.
There is nothing in the PCI DSS that says that a ROC must be compliant. It’s just that there is a lot less work for acquiring banks if the ROC is compliant. Non-compliant ROCs require that the acquiring bank monitor the organization’s progress on remediating non-compliant issues until everything is complete. Depending on how long it has been since the original ROC, the organization may have to go back through the complete ROC with the QSA to prove they are actually compliant. If remediation is less then three months, my Firm is usually willing to accept the previous work and just update those areas that needed remediation. Beyond that, changes have usually occurred in the environment that require the work effort to be re-performed to ensure the organization is compliant.
ROCs typically take around 10 to 16 weeks to complete given the complexity and size of the environment to be assessed, amount of documentation and observations required as well as gathering all of that evidence.
Hello PCI Guru & community:
I’ve been reading a great deal on what posts I can find here and elsewhere. My question is regarding RTP streams across provider clouds (MPLS & VRFs). When calls are initiated into our clients’ system, they are from insecure lines (cell phones, etc). My organization does not process cardholder information, but cardholders may pass their information through us.
My question is this: If cardholders (our clients’ customers) are calling in and being routed through our equipment to our customers and being routed through MPLS & VRFs, do we have a requirement to protect that RTP stream which is initiated and terminated in networks that we do not control?
Thank you for any thoughts and references in advance.
The PCI DSS Glossary states under ‘Service Providers’ that, “Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded” from complying with the PCI DSS. As long as your organization meets that definition, then you do not have to comply with the PCI DSS.
Where this typically runs into problems is when organizations provide additional services to their customers and do access the application layer such as with firewall and router management where the carrier is managing encryption keys for securing communications.
It is an astute observation…I know that I have other ‘in-scope’ services related to the services we provide, but I wanted to limit the scope of the question just to RTP stream. Thanks very much!
As long as your RTP services are never coupled with any other services that would be in-scope for PCI compliance, then the RTP service is out of scope.
I’m a QSA and while helping a client get setup with an ASV service I noticed something I’d like your thoughts on. I’ve noticed that most scanning vendors that service smaller merchants will require you to attest that you don’t use a load balancer or an IDS/IPS in order to use their scanning services. I realized, though, that in order for these companies to be PCI compliant, they have to use IDS/IPS as required by DSS 11.4.
Does this mean that you can’t use many ASV vendors if your company is actually following the DSS?
Remember, you can always use a compensating control for almost every requirement (the one exception is requirement 3.2) in the PCI DSS. So technically, you can comply with requirement 11.4 with a compensating control.
What these ASVs are doing is putting the legal liability on their clients to ensure that the vulnerability scanning results are accurate since encountering an IDS/IPS or load balancer could affect the results if they are not configured properly for the scanning. This is typically done because the ASV scanning is being performed through an automated appliance that schedules quarterly scans. Since there are no humans involved other than the client scheduling the service, these ASVs protect themselves with such legal protections should the client screw up and not disable the IDS/IPS and/or load balancers.
Being an ASV as well as a QSAC, we always work with out clients to make sure that our vulnerability scanning takes into account IDS/IPS and load balancers. We make sure that a client’s IDS/IPS and/or load balancers are configured to allow our scanning packets through regardless. We do this whether we are doing hands on scanning or automated scanning. However, to be safe, our scanning contract also has a statement that it is up to the client to inform us of any devices that could affect the results of the scanning.
Hi PCI guru,
We have an issue with FIM and PCI-DSS requirement 11.5. We did install it in all servers in the PCI scope. now we just heard that we must install it on each component inside card holder environment. (switches, workstations along with security appliances) . Could you confirm and provide me with examples of FIM tools for switches, routers? thanks in advance.
kmokrane
There is no such thing as a FIM for routers, firewalls, switches, etc.
However, there are network device management utilities that manage these devices’ configuration files and most will compare those to make sure that no changes occurred. If changes do occur, they will notify personnel via email that changes have occurred. That is how you meet the FIM requirement for firewalls, routers, switches, etc.
Take a look at SolarWinds, CiscoWorks, HP OpenView and similar utilities.
Hi PCI Guru and thanks for the fast response.
No the site isn’t going to be hosted on WordPress.com, we are just using the WordPress framework and themes to develop our own site, sitting on different servers.
My main concern is finding a secure PCI compliant form (I’m assuming one which encrypts prior to sending) for WordPress…
Thanks for the tips, Looks like I’ve got some PA-DSS guideline reading to do today!
J
Is there a way for you to avoid the WordPress environment and communicating directly with your service provider? That is, have a separate frame or page pop up that is the credit card processing process. That would be the best way to handle this. Otherwise, you will need to protect the information by following the DSS and PA-DSS.
Do you know of any issues with a WordPress designed site and PCI compliance?
The specific area would be in a form that contains credit card data.
The form will have additional fields to add data such as name, address, dates, length of stay etc. It will also have a section for adding card details.
At the bottom of this page there will a button “Send Inquiry”, after clicking on this button the inquiry will be added to the wordpress database, current whishlist will be cleared and customer will see message “Your inquiry was sent”.
All credit card information will be stored to the wordpress database. It will be visible only from admin area for store admin. The database will encrypt the data, it will be decripted only for admin. Information can only be deleted by admin.
An email will be generated and will be sent to admin. This email will be encrypted.
Thanks in advance.
J
The first question is, is this your organization’s implementation of WordPress or are you referring to the WordPress Web site? I’m assuming that you mean your own organization’s implementation of the WordPress solution, but I want to make sure.
If we are talking the WordPress Web site, the biggest problem you have is that you have no idea whether WordPress is PCI compliant or not. They are not listed on Visa’s Service Provider list, so one would assume that they are not PCI compliant or have not registered with Visa as a PCI compliant service provider. I would assume that WordPress’ environment is probably not configured for PCI compliance, so they would have to incur significant re-engineering and expenditures to become PCI compliant. The bottom line is that, in a WordPress hosted environment, your solution cannot be assessed as PCI compliant unless someone assesses the WordPress environment for PCI compliance. Since WordPress will likely balk at this, you’re probably not going to be able to be assessed PCI compliant.
If we are talking your own organization’s implementation of WordPress, then you need to follow the PCI DSS for its implementation. Any application development you do should adhere to the PA-DSS guidelines even though you will not be certifying this application. If you follow all of this, your resulting application should be PCI compliant.
That said, in this day and age, there should be no reason for your organization to store the primary account number (PAN), even encrypted. If you need it for future transactions, I would highly recommend finding a service provider that can provide that capability for your organziation so that your database only stores a truncated version of the PAN.
Hi PCI Guru..
We are making a PoS terminal, that will have facility for payment through Magnetic Swipe, ICC reader and NFC cards for the financial transactions.
Please clear my doubts, What mandatory certification I have to go for?
We wants to supports all types of cards of VISA, MasterCard, and Amex.
We are based in India
At a minimum, your POS terminal will have to go through the PCI PIN Transaction Security (PTS) certification process. Depending on other features you intend to support, you may have to go through a few other assessments.
If your POS terminal will support point-to-point encryption (P2PE), then you will have to have the POS terminal assessed against the PCI P2PE standard.
Finally, if your POS terminal will have application software, you will have to take the POS terminal software through the Payment Application Data Security Standard (PA-DSS) assessment process. The PA-DSS is not required for basic terminal software, but for applications such as a full point-of-sale (POS) suite (e.g., cash register, inventory management, etc.) of software that could run on the terminal.
Regardless of whether or not the PA-DSS applies, I cannot recommend strongly enough that you at least follow the PA-DSS for any software you or your business partners might develop that actually operates the POS terminal. In today’s world, terminals are no longer “dumb” devices. They are now based on Linux or Windows Embedded and all run a certain amount of software even for the basic functions of transmitting cardholder data for transaction authentication. As a result, that software should be developed such that it is as secure as possible and that is what the PA-DSS standard can assist you with. It is just a good checklist of best practices for developing secure software.
Thanks for replying..
My PoS is has Linux based kernal. We want to accepts all types of VISA, MasterCard and Amex.
we also support contact and contactless smart cards.
—–> Is PCI PTS POI mandatory?
—–> Whether I have to go for EMVCo also?
—–> Is PCI-PTS POI only requires? Or we also have to go for MasterCard and VISA separately?
Yes, PTS is mandatory for all terminals.
However, given your questions, I just want to confirm that our definition of a “terminal” is the same. My definition of a “terminal” is a device that has some sort of a display, card swipe and a PIN pad for the entry of a customer’s PIN similar to Verifone or Ingenico terminals. They may also have a receipt printer and, in Europe, have the ability to process EMV. If you are talking about something other than this, then we need to further clarify what you are talking about.
Complying with the PTS should also allow you to meet the EMVCo requirements as well.
The card brands (Visa, MasterCard, American Express, Discover and JCB) all accept the PCI standards. There are no card brand specific terminal standards at this time.
Hello PCIGuru
This has been a great site for some clarification into PCI.
I have a question. We are a national company in with many locations across the country. We just contracted out a third party to handle our credit card payments and processing. A staff person at a satellite location can use their workstation to log into the third party’s portal to enter the payment information of a client visiting the branch. We receive a transaction record (sans CHD) for our records. The workstations are on our WAN and have access to the internet obviously, and other company systems and applications and authenticate off our Active Directory. So that bumps us from SAQ C-VT to D. That is fair enough but there are many questions in the SAQ D that are not in scope. Some are obvious like most of Requirement 3 (CHD storage and key encryption) but I’m sure there are many more that are not in scope. If I look at Requirement 9, we no longer store CHD internally. So I would think most of those questions are out of scope. Some would argue that cardholder data is transmitted through our network but it is encrypted at the workstation and decrypted back at the third party. They control the encryption process. I did read here somewhere that networks/systems that transmit encrypted CHD would not be in scope.
We can not get a straight answer from a consulting QSA we had onsite recently. He just assumed if its in SAQ D that we need to do it. Can you shed any as to how companies in a similar situation approach this?
Thanks!
As more and more organizations get rid of cardholder data (CHD) from their environments, the complexity of what is in-scope for compliance can unnecessarily increase because the PCI Security Standards Council does not provide enough clear guidance. Based on what I’ve been through, here is my take on things and how I approach it with my clients. I have my clients always ask themselves, “Where is the risk?”
In your example, the technology risk is that the workstations used to access the third party’s portal could be compromised and leak data. Most likely, the workstations used to enter payment information. Now it becomes a question of what have you done to mitigate this technology risk? Typically you have a firewall in place and you have anti-virus and anti-malware installed on the workstations. That is a good start, but you also need to make sure they are physically or logically segregated from other systems and that you are monitoring them for any compromise. Depending on your AV/AM solution, you may already have a critical file monitoring capability, so that would be taken care of. Segregation may also be taken care of if the connection to the third party is over an encrypted link such as SSL/TLS or IPsec from the workstation to the third party. One final thing would be the monitoring of workstation logs and alerting on any activity that would indicate the possibility of a compromise such as network traffic to/from an unexpected source, account lockouts, privilege escalation, etc.
The other risk in your example is that a person that enters data or has access to the third party system will be the leak. To address the people aspect, you’ll need to have a security awareness program that periodically reminds users that credit card data needs to be carefully handled and not disseminated outside of the organization. You could also monitor what the workstations can access and restrict that access (i.e., no Internet access, limit access to only certain Web sites, etc.).
In regards to filling out the SAQ, you will find that certain requirements do not pertain to your environment such as in requirement 3. However, even when organizations outsource all processing of CHD as you have, you are still required to comply with requirements 1, 2, 4, 5, 6 (change control and patch management), 7, 8, 9, 10, 11 and 12. This is because you are still transmitting CHD and all of these requirements still come into play even though you no longer process or store CHD.
Thanks for the reply. I am just concerned that this project will be over-scoped. I just figured within Requirement 9 for example, there may be some individual requirements that would not be in scope such as “9.5 Store media back-ups in a secure location, preferably an off-site facility…”. I would think any requirement around media transport and destruction would not be in scope for us. I can see 9.10.1 around shredding being in scope. But looking over of Section 9 would appear most would not be in scope.
What is the definition of a Card Holder Data Environment? If we do not store card data, why would our data center be in scope? It would be in the middle of the transmission of the encrypted card data. Does that count? If it does, then does the network closet in a satellite office that has a router pointing to our private WAN connection count as part of the CHD environment? It is a part of the transmission. If so, then we need to monitor, log, lock down, track visitors in every network closet in the 50 satellite offices we have? That is just not practical.
I know you are in the PCI business so I understand if you can’t get into the details of my questions. But these examples are just a small number of questions that I am trying to figure out before we really dive into planning to be compliant.
Thanks again!
Unfortunately, the problem you face is that a lot of QSACs that either got dragged through the mud called the PCI SSC QA Review or are so concerned about the clarifications issued are now so gun shy, they refuse to budge on anything for fear of being told in their next review that they are again under ‘Remediation’. Then there is the group of QSACs that will accept almost anything as evidence and do the review over the telephone. Saves money, but you really have to wonder about the results.
Based on what you have explained, I would agree with your assessment of requirement 9. You need physical security and visitor control, but other than that you are likely fine.
You data center ends up in scope because I am assuming all of your switches, routers and firewalls are located there. While your data stream to the third party is encrypted, the workstations are on that network and could be compromised as a result via the network, that is why it is in scope. The way to reduce that is to segment those workstations away from the general network so they are on their own.
The term ‘visitor’ is too nebulous when it comes to the PCI DSS. We define visitor as someone that does not have a job function that requires access to a given area. Notice that I said ‘someone’, not employee. There is a reason why I deliberately used someone. It’s because in this day and age, it is not unusual to have contractors that maintain equipment and needing 24×365 access to a wiring closet or data center. Even if they pick up a badge at a desk after hours, they are still not a visitor. QSAs have been told this in training, yet we constantly encounter this issue with clients and prospects that had a QSA prior to us.
One final word of advice since you will likely be responding to a lot of the requirements as ‘Not Applicable’. When you state that something is ‘Not Applicable’ you need to not only explain why it’s not applicable, you also need to explain the procedures you used to confirm that a requirement is not applicable. For example, take your 9.5 example. You would say it is, “Not applicable because [company name] does not store cardholder data. We reviewed the cardholder data processing procedures and determined that no other systems come into contact with the cardholder data other than the workstations from which the cardholder data is entered into the [third party name]‘s system.”
We are in a similar situation where we will use our clients virtual merchant terminal thru Authorize.net to take customer orders. We have completed a SAQ-D with most N/A and a AOC. Do we need to complete a ROC? The workstations are locked down ,segmented on a Layer 2 connection to the clients network.
Unless your organization does more than 6 million card transactions with one of the card brands (i.e., you are classified as a Level 1 merchant) OR one of the card brands has arbitrarily designated your organization a Level 1 merchant OR you have suffered a breach of cardholder data, you only need to do your SAQ.
Hello, hoping you can clarify something for me. Does the use of E2EE / P2PE invalidate the need for network segmentation and firewalls? Do I need to worry about attackers attempting to disable the encryption by being able to access them over the local network?
As I like to say, “In theory, theory works.”
However, while the datastream is encrypted, the endpoints on the network segment are likely still attackable if you have not segmented them away from the rest of your network. That segmentation will require you to put ACLs in to limit access.
I am investigating making a purchase of Enterprise Recon (http://www.groundlabs.com/products) – a tool for scanning file systems on multiple endpoints across a company’s network for unencrypted credit card data as part of their PCI compliance project. Are any of you working with this tool? Can you share information on comparable products?
my company have recently set up an ebay shop alongside the several websites we maintin to sell our products. As Paypal is the only option for method of payment does this mean that the cardholder data stored/processed by them is their responsibility in terms of PCI compliance even though they are purchasing from us. Or because the consumer is buying from our ebay store do we have a duty of care in performing due dilligence when signing up with PayPal to ensure their compliance by asking them to fill out a questionnaire and provide a PCI certificate or AOC and so on? Would the method of interaction used have a bearing as we not only use paypal via ebay we also integrate them into our own websites. Thank you in advance for any enlightenment you are able to provide.
Does either SOX or PCI have any affect on Log In / Log Out process for POS systems?
We are implementing a new POS system at work, to be used in our Cafe – which is used by employees during lunch. The current process is for the cashier to ring up each employee in line, without logging out between transactions. We want to confirm there are not compliance issues with this.
Note: The POS app is PA-DSS Validated, and approved by PCI-SSC as a PCI compliant service provider.
Not sure where you go the idea that users need to log out and log back in between transactions as that is not specified anywhere in the PCI DSS.
The user identifier tests in the PCI DSS and other PCI standards are related to being able to properly identify users in the event of a breach. If a breach occurs, you want to be able to quickly narrow the scope of potential users to only those that were accessing CHD at the time of the breach. So, your POS solution needs to be able to have log data that will show when a cashier logged on and when they logged out as well as tying them to transactions conducted.
As long as your cashiers are not sharing a user ID, you are in compliance.
Are you suggesting that as long as users are not sharing an ID to log into the PCI application, that is in compliance? What about if they are using a shared ID to sign onto the windows terminal used to access the application? Can they use a shared ID to sign onto the workstation, then use a unique ID to actually access the application?
The risk with using shared or generic user identifiers is that users accessing cardholder data cannot be pinpointed should a breach occur. That is what the point of requirement 8.5.8 is all about.
But if you read the Reporting Instructions, you will see that 8.5.8 only applies to system administrators, network administrators, database administrators or users performing other “critical functions.” As it has been taught for years in the QSA training sessions, critical functions are any users that have access to bulk cardholder data such as accountants for disputes or chargeback resolution.
That is not to say that cashiers should not have unique identifiers, it is just not mandatory for PCI compliance that cashiers have unique user identifiers as they only come into contact with cardholder data one at a time, not in bulk. There are other operational reasons such as cash drawer management where unique cashier identifiers are needed.
Thanks for the quick response! I was looking at it more from 8.1 persepctive. A multiuser account is not “unique”. And we have determined the workstation to be in scope, so can we use a multiuser to logon as long as the PCI application uses unique logons? Thanks again!
A lot of QSAs get this wrong because if it’s not controlled by Active Directory or some other directory system, then it cannot be allowed and that is not accurate. As long as there is uniqueness somewhere that would allow for a rapid identification of the user(s) in the event of a breach, then you are complying with 8.1.
Again, from a PCI perspective, this uniqueness only truly applies to users that have access to bulk cardholder data, not users that come into contact with one account at a time such as cashiers or call center operators. Not that cashiers and operators should not have a unique account for other reasons, but from a PCI compliance perspective, a unique user identifier is not required.
We run into this situation a lot in restaurants and brick and mortar retailers where the physical device has a common, shared account, but in order to use the actual application each employee has a unique account that is used to allow them access. That uniqueness is what allows compliance with 8.1.
Sounds good, thanks again for the response!!
Hello,
I am wondering about a franchise environment.
I have 16 locations. I know that I can do one assessment for all (doing SAQ D), but are there any pro’s to doing 16 separate SAQ’s and placing the responsibility on each location?
Any con’s to sticking with just one assessment?
Thanks!
The PCI SSC and the card brands have stated that the number of SAQs or ROCs is driven by the legal structure. If the 16 locations are all under a single legal entity, then you perform one SAQ/ROC for the legal entity. However, if you negotiate with your acquiring bank, you can typically do whatever you want from a reporting standpoint.
That said, I would think doing one SAQ would be easier than multiples, particularly if they are all the same from a technological standpoint.
Does PCI-DSS proscribe the use of a Windows (OS based) workstation that is mainly used for payment processing (USB card swipe feeds credit card data into an web-based merchant terminal application) from also being used for recreational Internet use (Facebook, email, browsing, YouTube, etc.)? I believe that it does, but I am getting push back from others who do not want to have a dedicated processing station isolated from other general use systems.
You are probably thinking of requirement 2.2.1, “Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)” But that only concerns servers, not workstations.
Then there is requirement 1.2 about isolating the cardholder data environment (CDE) from untrusted public networks (i.e., the Internet or any other network you do not explicitly control). The question here is whether or not the Web-based merchant terminal is securely communicated to. One would assume it uses SSLv3 or TLSv1.x. If it is, then 1.2 is satisfied by the use of an encrypted connection.
There is also requirement 1.3 that states, “Prohibit direct public access between the Internet and any system component in the cardholder data environment.” This is probably what you are thinking of as, technically, the PC accessing the Web-based POS application is being used to directly access the Internet in addition to being a POS station.
Regardless of PCI compliance, it is just a good practice to avoid using a PC that processes cardholder data for Internet surfing. It is just too easy to pick something up that then compromises the POS functionality.
I agree with your last paragraph completely. This has always been a lengthy debate at companies I’ve worked with. The standpoint I have considered generally takes a risk-based approach:
1) How many credit card transactions are being processed from this workstation? If it is 2-3 per day, then the risk is different than a workstation processing 100-200 per day.
2) What is the approved usage of technology by the business (requirement 12.3)? If the business allows this functionality and there are appropriate safeguards in place (e.g., web proxy filtering/inspection for the direct access to Internet), then the risk is different than if the business has no clue what the appropriate usage is.
Other thoughts?
Just keep in mind that, while the PCI SSC and card brands espouse a “risk based” approach, they still seem to view one PAN breached or a billion PANs breached as the same thing.
So while I also agree with what you are saying, at the end of the day, it may not matter.
Hi there, our organization has started our road to PCI compliance as we just became a level 3 merchant. We take orders over the phone and had integrated to our merchant vendor’s api right into our order processing system that was previously a free service. A third party came in initially and said, if you guys removed the processes from your system and had the agents instead use the vendors website directly you’d be removing everything from scope. Something we were willing to do.
Then a few days later he followed up saying that his suggestion was wrong, the agent’s desktops are in scope. We then discussed the idea of segregating these machines. This was good for a while but now we have moved to everything is in scope. We (maybe just me) are chasing our tails trying to figure out what best defines ‘adjacent to’ these agent machines. If we put them in their own DMZ do the other networks get removed from scope? At what point after opening ports does the ‘adjacency’ flag? We want them to obviously have active directory server access to control accounts on the computers, etc, etc.
The third party started by saying, ‘it’s best to try to reduce your scope’. Now they are saying, ‘all companies find it too difficult to reduce scope and just end up going for full system and networks compliant’.
Any resources about about scope and adjacency would be so appreciated.
Thanks for your time and running this great site!
Hi,
We have folks completing SAQ A and are stating they do not process credit card information. However, they hold phone-a-thons and receive hard copy letters with credit card information, which they enter into a third party processors web site. To me, that sounds like they “process” the Credit Card information. Am I being too literal?
According to SAQ A, you can use it as long as:
- Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;
- Your company does not store, process, or transmit any cardholder data on your systems or premises, but relies entirely on third party service provider(s) to handle all these functions;
- Your company has confirmed that the third party(s) handling storage, processing, and/or transmission of cardholder data is PCI DSS compliant;
- Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and
- Your company does not store any cardholder data in electronic format.
Based on your description of what the organization is doing for “Phone-A-Thons” and the criteria for SAQ A, I don’t see any reason to say they need to do anything but SAQ A.
Comment on this. If they are entering the credit card details from their desktops through their corporate network on to the TPP, then I would say that they are, at a point in time, storing and transmitting card data through their corporate network. Which would bring the network into scope and remove the SAQ A. Thoughts?
I have assumed that the third party is also PCI compliant. That would then imply that the Web site is using SSL/TLS for communications. That would segregate the network by encrypting the connection.
Yes they are entering the data on their desktops, but it’s entered into a Web site, not into something on their computer. And yes, the browser can retain some residual data, but once that session is closed that data is gone.
Thanks for the response. The service you provide is greatly appreciated!
Just to clarify, while I think the College should still use SAQ A, I think the answer to the question on page two “Merchant does not store, process or transmit any cardholder data on merchant systems or premises but relies entirely on third party service provider(s) to handle these functions” needs to reflect the fact that the College DOES process credit card data for several departments. From there I think we can explain how the controls in PCI DSS requirements 9 are in place:
• Only hard copy media is involved,
• The hard copy CC information is protected in transport and destroyed after it’s no longer required to be retained,
• Access to the hardcopy is limited,
• The hard copy is properly secured, and
• Staff is trained on the CC handling procedures
I think the school will need to start completing page 4 of SAQ A differently, and reflect the controls mentioned above, as oppossed to just stating the controls do not apply.
Thank You Again!
Dan
Based on Dan’s initial explanation, isn’t the entity transmitting credit card information through a payment processor’s website, thus potentially requiring an SAQ C-VT?
You may be on to something.
The criteria for SAQ C-VT states that it should be used by merchants that:
- Your company’s only payment processing is done via a virtual terminal accessed by an Internet-connected web browser;
- Your company’s virtual terminal solution is provided and hosted by a PCI DSS validated third-party service provider;
- Your company accesses the PCI DSS compliant virtual terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems);
- Your company’s computer does not have software installed that causes cardholder data to be stored (for example, there is no software for batch processing or store-and-forward);
- Your company’s computer does not have any attached hardware devices that are used to capture or store cardholder data (for example, there are no card readers attached);
- Your company does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet);
- Your company retains only paper reports or paper copies of receipts; and
- Your company does not store cardholder data in electronic format.
The only problem I see is that the computers need to be dedicated to nothing BUT the processing of credit/debit cards through the third party. For most organizations, this is VERY unrealistic.
However, I could see SAQ C-VT as a better fit than SAQ A.
Hi,
This is good timing. I talked with an ISA just yesterday and he confirmed it was the C-VT we needed, so it’s nice to get this confirmation. Thank You!
Hello!
Thanks for your resource!
Two question’s:
1. Do you have an experience with 10.2 req. and linux systems? Maybe you have some remarks about this point ant this OS? Where system administrator that support this OS should add more attention?
2. It’s another question about 2FA on VPN solution. How you find the solution with pptp tunnel with auth via username and password as first and one time entered to PC certificate which used to open second tunnel over pptp tunnel to for example MS Terminal Server as second factor? Is this solution completely 2FA? Why I asking, because ane assessor says that it’s ok, another says that not ok, because cert is imported only once. But what you think about it?
Complying with requirement 10.2 under any OS is difficult, if not impossible. Depending on the version of Linux you are running will determine how much of this you can achieve.
That said, requirements 10.2.2, 10.2.4, 10.2.5, 10.2.6 and 10.2.7 should all be achievable with any type of OS. These are basic syslog settings that are available under Windows, UNIX, Linux and other OSes.
What you are likely having trouble with is requirements 10.2.1 and 10.2.3, which are troublesome for almost all OSes. Requirement 10.2.1 is more of an RDBMS issue than an OS issue. Even databases such as DB/2, Oracle and SQL Server cannot log individual accesses of cardholder data. There are third party logging solutions that can provide this functionality as well as you could develop your own logging solution. Requirement 10.2.3 can have a similar problem in that the syslog files are just files and are treated no differently than any other files. However, the solution here is to have a centralized logging solution that receives the log data as well as the local syslog file. The centralized logging solution can control and monitor access to the syslog data so that you comply with 10.2.3. YOur QSA would have to test this solution to ensure that there is no way that the syslog data could be changed in transit to the centralized syslog server(s).
In regards to your two-factor authentication solution. I am assuming that what you are describing is something similar to an SSL tunnel being created over the PPTP tunnel. If there is only one certificate in use and that is the certificate at the server, then that is NOT two-factor authentication because the end-user is NOT supplying something they have. In order for this to be considered two-factor authentication, the end user’s PC must supply the server a certificate as well as the server supplying a certificate that authenticates both devices in addition to their UID and PW.
Just looking at different methods of tokenisation and I’m slightly confused by format preserving tokens. PAN is tokenised and replaced by a number which preserves the format, is numeric and will pass a Luhn check. Surely this PAN format, luhn check passing, numeric token MAY be considered PAN. Although it may not be the same as the original customer’s PAN, it may well be considered PAN and in many cases actually will constitute someone else’s PAN.
I suspect that using format preserving tokens may make data discovery a real issue, as well as identifying whether you have a pollution incident caused by a tokenisation failure.
What you describe does not seem to meet the definition of tokenization. At least not as tokenization was defined to me a number of years ago.
There are a number of other tokenization techniques that keep the token to a 16 character length but gibberish that will NOT be confused as a valid PAN,let alone pass a Luhn check. I would stick to those approaches.
Thanks, I completely agree – however some vendors seem to offer this type of “tokenisation”, retaining PAN format and Luhn compatibility. My question was prompted by a webcast from a vendor who offer exactly this. To me this isn’t tokenisation at all and I’m amazed that PCI accepts this.
This is why merchants must conduct some amount of due diligence in reviewing and confirming vendor claims.
In your example, while technically the method is considered tokenization, a concern would be that the method results in a valid PAN. I would see this as being no different than using valid, but out of service, PANs for testing which a lot of organizations use. At any point in time, these test PANs could become valid again, resulting in the organization unknowingly testing with live data. Therefore, the organization needs to continuously check to ensure that the PANs they are using for testing have not been reactivated. This is why processors and acquiring banks maintain test PANs for the various card brands so that they never become active, but can be used for testing of the entire authentication process.
I have a question that I’ve been struggling with for a while, and I was wondering if you’d be willing to shed some light on it. I’ve been dealing with PCI DSS for a few years now and I’ve never been able to wrap my head around how to make a web server that accepts and posts credit cards compliant. Doesn’t prohibiting routes into the CDE and requiring public services be segregated make it impossible for a public facing server to handle credit cards in a compliant manner? I had handled this before by requiring our web guys to use redirects to service providers, but I’m getting more push back now about this policy.
This seems to be becoming more and more of an issue as analysis confirms that people see redirects as insecure when just the opposite is true. See my post on this topic at http://pciguru.wordpress.com/2011/11/12/of-redirects-and-reposts/
Let me preface this by saying, THERE HAS NEVER BEEN A BREACH! That being said, I’m, hoping you can help me to understand the culpability of this scenario…
1. A call center is hired by a merchant to solicit on their behalf . Caller ID displays the merchant’s name, with their knowledge.
2. The call center does not have a merchant account.
3. The call center faxes handwritten order info (including cc card #) to the merchant for authorization and processing,, as required per the merchant.
4. THE merchant NEVER discussed PCI compliance with the call center! (The call center only learned of it from a friend, who is a merchant.)
5. The merchant did requested the cardholder information be secured in a locked cabinet, to be shredded at a later date.
6. The call center does not have any agreements with PCI .
IS it incumbent upon the merchant to insure that the call center is in compliance, as they are acting on behalf of the merchant?
Does the call center have any culpability or vulnerability? regardless of a lack of breach.
Do you think the call center has an actionable cause against the merchant for making the call center vulnerable because of the merchant’s decision not to disclose any information regarding PCI compliance?
Also, isn’t the call center considered a “breach” of sorts, by virtue of the fact that no one has discussed the rules of compliance?
I am eager to hear your thoughts on the matter. Everything I’ve been able to find about third party involvement, referred to either processors or those companies which also authorize payments.
Thanks!
One would think, but this usually does not happen as the merchant assumes everyone is aware of PCI and their responsibilities for compliance.
The call center is required to comply with all relevant PCI standards related to their processing, storage and transmission of cardholder data regardless of whether that data is in digital or analog formats (i.e., paper).
That is for a lawyer to determine based on the contract between the two organizations.
There is only a breach if the cardholder data is no longer in control of the call center or the merchant. Based on your posting, I have not seen any evidence of that presented.
I am looking, but can’t find (probably with good reason) an acceptable network diagram for a network that does not have segmentation. As a QSA, have you come across any company that had such a diagram, which you regarded as acceptable? And if so, would you mind sharing the “sanitized” details?
Just so I understand, you want a network diagram that is NOT segmented? Any flat network would accomplish that.
Hello and thank you for your interesting post. I apologise if the following question is one you get asked all the time, however I have been unable to find clarity elsewhere – My company uses 2 payment processors, one of which is listed on the PCI SSC’s list of acredited vendors while the other is not. Upon visiting Visa’s website the opposite is true, our secondsary payment processor is listed but not the primary that is on the PCI SSC’s site, these are payment applications used by our websites to process online payments, any manual payments which you can count on 1 hand per month go via a PDQ terminal which is validated by othe PA DSS. Fortunately we are moving away from our secondary processor, however I am surprised at the difference in Visa’s and the PCI Councils lists, am I missunderstanding as many others are? Best regards M Parkes
You are talking two different things.
There are a couple of lists on the PCI SSC’s Web site that your one service provider could be listed. The first is for applications that have been validated for complying with the PA-DSS. The second, and most likely based on your comment about card terminals, is the PIN Transaction Security (PTS) validated site. The final site that could be relevant is the point-to-point encryption (P2PE) validated site.
The Visa site is for Service Providers that have paid Visa a fee AND supplied Visa with a copy of their fully compliant PCI Report On Compliance (ROC). So your other service provider has paid Visa their fee and has been through the PCI DSS assessment process and has been judged compliant. Just because a service provider is not on the Visa Web site is not a big deal as a lot of service providers do not want to pay Visa the fee to be listed.
Regardless of whether or not your vendor is listed on the Visa site, you should be obtaining a copy of their Attestation Of Compliance (AOC) to ensure that the services they are providing you comply with the PCI DSS. Just because a service provider is listed on Visa’s site does not mean that every service they offer that could come under compliance with the PCI standards was assessed for compliance. If they do not have an AOC or if the AOC does not list all of the service they provide your company, then you or your QSA will have to assess those services against all relevant requirements of the PCI DSS.
We have a service provider who host the card data network and all the physical servers. They monitor and maintain the hardware including servers, firewalls, load balancers, intrusion detection, etc. A subcontractor of the hosting company act as the system administrators of the servers. They support the software and applications on the server including the Operating System. They do monitoring and maintenance as needed. In the contract between our company and the hosting provider do we need to include PCI language as per control 12.8.2? The hosting company and their subcontractor do not need access to the card data instead they have access to the systems that handle card data.
Any person or organization that has the potential to come into contact with cardholder data (CHD) needs to comply with the requirements relevant to the services they provide. Your contracts with your hosting company should have language regarding PCI compliance. Your hosting company needs to have language in their contracts with any sub-contractors that come into contact with your systems regarding PCI compliance. Then, you need to make sure that the services you are being provided by any organization are complying with the PCI requirements based on the SAQ you use or ROC.
Hello, I was wondering if you have heard of the term “Voluntary Non-Compliance” ? We are an internal service provider for several merchants in the same organization. Since one of our merchants has a deadline for compliance this year and others in the next year, we’ve been told to take the stance of “Voluntary Non-Compliance” when filling out our AOC for the 1st merchant. Is there any information out there about this? I couldn’t find anything with Google search. Thanks very much !
Wow, that’s a new one to me. Never heard it used before until now.
I am guessing whomever is using that term is referring to the fact that an organization is allowed to file a non-compliant ROC, i.e., one or more requirements are defined as ‘Not In Place’. When requirements are flagged as Not In Place, the organization is required to document in the Comments section what they are doing to remediate the situation and when the remediation effort is expected to be completed. Then your acquiring bank/service provider is required to follow up on your remediation efforts until they are complete.
Dear PCI Guru,
I have a situation where my client does not want to invest in a solution for 2 factor authentication for authenticating OWA users access email server which has card information stored in form of emails.
Do we have a workaround for this situation?
Regards,
Unmesh
We are a call center who will be taking credit card information over the telephone for a client of ours. At the same time, we are in the process of opening a new call center, building it from the ground up. I have been given the task of providing advice on what to do with the physical call center. Do we need a “clean room?” The PCI standard 3.3 is not very clear on the subject in my opinion. Is it necessary for us to segregate our call center team responsible for taking credit card information? Are we required to have a paperless call center. We are thinking of a clean room concept where we would have lockers for call center staff to place their personal effects. We would ban cell phones, paper (perhaps using a white board etc.) Is this necessary? I know that there are system requirements. We must mask the PAN and not store or record the CVV/Security Code etc. Call recordings for quality purposes have PCI requirements and we feel confident that we understand the system requirements for PCI and are taking steps to ensure that we are secure however, parts of the standard seem to me very unclear. If would like some advice, guidance to try to understand what is needed.
Is the management and transmission of private label card credential data subject to PCI rules?
No. Private label cards are not covered by the PCI standards.
However, a number of our clients that do process, store and/or transmit private label card information do treat them the same as their credit/debit cards that are branded by Visa, MasterCard, etc. They do this to make their policies, standards and procedures consistent with their PCI compliant business.
Thanks PCI Guru
Hello PCIGuru!
Excellent resource you have built here! A huge thanks from those of us trying to understand the standard. I’m looking for clarification on a situation with 10.5.5 and 11.5 regarding File Integrity Management (FIM). Our QSA is indicating that it needs to be on all Servers within our CDE. Is this true or does it need to be on only those systems that store CHD?
Thanks!
It needs to be on all systems that have access to the CDE. Now, before you go off the wall, remember, most current AV solutions have a FIM component that you can rely upon for workstations. There are also compensating controls that can be used for workstations. However, for servers, I cannot recommend a purpose-built FIM enough.
That said, all of the log data from your FIM solutions needs to get back to your centralized logging solution so that you can analyze the file changes that are recorded.
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.
Thaks PCI Guru,
It is legal here to take a copy of the customer credit card and passport. The client’s legal team has designed this process to prevent fraud transactions from couple of countries identified as sensitive zones.
We are evaluating the following options :
Option 1:
1) Having email encryption in place (To encrypt email and attachments)
2) Creating a separate email id with 2 dedicated resources identified to look into the card details
3) Preventing data leakage by having this email ID under DLP monitoring
or,
Option 2:
1) Instead of taking the scan copy of the customer card, we can design a form that the customer needs to fill up with his card number (first 6 and last 4 digits, and rest all masked) and customer name along with a scanned copy of the passport.
Option 1 can be readily implemented since we have the resources and solutions in place to do the same. However, for option 2 we will have to design the form from scratch.
Which option do you suggest would be feasible.
Regards,
Unmesh
I always worry about solutions involving email as email makes the transfer of data too easy, even when DLP is in place. Then there is just the fact that it puts the entire email server into scope for PCI compliance. I have yet to run across an organization that wants to put their email system into scope for PCI compliance.
Either option is feasible. However, my choice would be option 2 as I am a very big fan of just not collecting cardholder data if I can avoid it.
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.
I too am enrolling for this and read through the material mentioned above. I am signed up for the e-learning course and just passed the fundamentals and on my way to the ISA preparation. Question for you. Is it beneficial or time well spent on memorizing all the controls for the ISA test? Or is it better to focus on the control structure, the intent of the control and how best to test it? I’ve been looking on lone to see if there was any insight as to the make-up of the test but can’t find too much information other than this blog (which is really helpful!). Any guidance on what to focus on? Should I be creating flashcards of all the controls and trying to memorize them or is it better to understand these at the level I mentioned above?
Any help would be greatly appreciated.
Thanks,
Good or bad, the PCI examinations are not anywhere like the ones for the CISSP or CISA certifications. I tell people to go out to the PCI SSC Web site and get copies of the ROC Reporting Instructions for PCI DSS v2.0, Glossary v2.0, PCI DSS Quick Reference Guide v2.0 and Navigating the PCI DSS v2.0.
You don’t have to memorize these, but they are the reference materials you need. Pay particular attention to the Glossary as there is a lot of information in there that is published no where else and it can explain quite a bit. The Quick Reference will give you a good overview of the payment card process and industry. The Navigating document explains all of the rationale behind the requirements and tests. The Report Instructions explains what evidence and how you will need to test.
If you already have a strong IT general controls audit background, you should find the ISA examine common sense. However, where a lot of ISAs run into trouble is they are great auditors but not technicians and a lot of the PCI DSS is technical in nature. I also see a lot of QSAs that are great technicians but don’t know how to audit and do a very poor job doing PCI assessments.
Best of luck on your ISA certification.
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.