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.
To those of you that have issues with this page and it’s load time, blame WordPress. This is a “free” blog and to fix this issue would require a ‘Business’ subscription that would cost $300/year (2018) to access the necessary plugins to reorganize the comments to multiple pages. To afford that, I would have to charge a subscription fee to anyone reading the blog.
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.
PCI Guru 
Hello
Thank you for your advice and response to the community.
I would like to know if our company is using a P2PE solution do we need to have a P2PE assessor if we are providing network equipment only? And is this in scope if we are contracting operator services?
Thank you
No, you do not need to have a P2PE assessor. Any QSA can do your assessment.
P2PE solutions need to be assessed by a P2PE assessor to be on the P2PE solution list.
Hi PCIGuru – do you know of free cross-platform PAN search tools?
I know of nothing “free” or open source.
On a SAQ-D, do you need to list PA-DSS apps your third party service provider is using or just the ones you have a direct contract relationship with?
Also, with the transition away from PA-DSS, many previously validated are now expired and awaiting validation under the new standard. Any thoughts on handling this scenario too?
Thanks PCI Guru.
I am the ISA for a large Level 1 Merchant. Preparing for the assessment I collect and review over 1500 pieces of evidence and over 900 pieces go to the QSA. Up till now I haves a homemade Access Database linked to SharePoint to request and track evidence. As the environment continues to grow it is becoming more and more of a hassle to deal with this Access DB. What are other people using?
I am finding most tools are made for SOX or NIST and then just adjusted for PCI.
I am a big user and fan of Total Compliance Tracking (https://www.totalcompliancetracking.com) but there are also a number of other GRC tools that can assist. Another favorite of mine is Galvanize (https://www.wegalvanize.com/) as they can automagically gather a lot of your evidence out of the same systems you are gathering it from.
Hi PCI Guru – do you know anything about the new update to the PCI v.3.2.1 ROC template dated September 2022?
Yes, it was in the last Assessor Newsletter. The new ROC Reporting Template only adds UnionPay to the various areas where the card brands are called out. The AOC I would also assume is updated similarly.
Hi,
What’s your understanding of requirement 11.6.1 in the context of SAQ A?
The requirement applies to the payment page. FAQ1438 clarifies that for an iframe solution, the Merchant website is NOT part of the payment page. In addition, if any part of the payment page is delivered by the Merchant, they are not eligible for SAQ A.
However, SAQ A has an applicability note stating that 11.6.1 applies to Merchants with iframe solutions. It doesn’t say to what the requirement should be applied to though. By comparison, the SAQ A applicability note for 6.4.3 very clearly states that it applies to the Merchant website.
My interpretation is that although SAQ A says that 11.6.1 is in the Merchant’s scope, it would always be the responsibility of the PCI DSS certified payment processor providing the payment page. There would be no actions needed by the Merchant.
I find it very confusing when SAQs twist the applicability of requirements…
For v4, SAQ A is being changed to address the MageCart and similar attacks that are going on. Hence why 11.6.1 is there now as they are trying to reduce MageCart style attacks.
Can I do ASV scans as a pcip or do I need to work for an ASV company and be a QSA
You must work for an ASV Company AND you must be a certified ASV.
You can run scans yourself over your own environment without any qualification, but if you want to start a business providing ASV scans, then you will need to be an ASV company.
Hey PCI Guru-
My company utilizes corporate credit cards (Visa) for employee travel and expenses. CHD is stored within our network for reconciliation purposes. Would this fall into PCI DSS scope, or are corporate cards exempt?
Thanks in advance for your assistance.
While corporate cards are exempt from PCI compliance, I would highly recommend that they be secured according to the PCI standards just for safe keeping.
I also recommend that corporations have an agreement in place for employees that indicates why the information is stored and what the organization is allowed to do with the stored SAD/CHD.
Agreed. When a company obtains corporate credit cards, they are doing so under the terms and conditions of the cardholder agreement with the issuing bank, not the merchant agreement with the acquirer. Cardholders are still required to protect the card account number and report when it is stolen or compromised, thus requiring PCI-like controls on the information.
Are corporate credit cards in scope/ applicable to PCI DSS? I’ve seen conflicting information online. I found an article from 2009 that it depends on the card brand. Such as AMEX does not consider it in-scope but MasterCard does. We use Amex and Visa… if it is up the brand to determine the scope, is there an official published stance somewhere?
News to me that Mastercard considers corporate cards in scope, but that seems to change all of the time.
That said, I recommend to all my clients that SAD/CHD for corporate cards be secured according to the PCI standards regardless of the card brand rules.
I also recommend that the organization have an agreement in place with employees that have their SAD/CHD stored documenting why the organization has that data and for what purposes they are allowed to use the data (i.e., travel reservations, meeting reservations, meeting registrations, etc.).
Hi there I have a question about AWS lambda vulnerability scanning. Can we use Aqua to meet Req 11.2.1 (Internal Vulnerability scanning) for our entire environment?
Thanks!
I don’t see a problem with using Aqua as long as the reports generated by Aqua regarding Aqua’s analysis of your containers are available to prove your quarterly vulnerability scanning requirements. That may require some sort of scheduled quarterly analysis using Aqua to get that reporting.
Thank you PCI Guru; p.s. the environment also contains a Bastion and DB VM, would they need a true vulnerability scan because the are not Lambda (server less) systems?
Yes, they would need vulnerability scanning as well via a tradition scanner.
Have a great weekend – Thank you again 👍🏻
I apologize for leaving this out, they are a ticketing service platform and payment API processing tokenized cc data and do not have the ability to de-tokenize the the tokens.
No problem. I thought it was my misinterpretation of what you wrote. Regardless, if they are only seeing tokenized data and have no way to de-tokenize that data, they are not in scope.
Hi Guru – can a Level 1 Service Provider API processing over 300k tokenized credit cards complete a SAQ-D vs a Report of Compliance?
That depends on how many Visa, Mastercard or Discover transactions you process. The 300K limit is based on the card brand transaction count, not the aggregate. If any of those counts by brand are over 300K, then you are a Level 1 Service Provider.
If you are going to claim you are a Level 2, you better make sure you have accurate transaction counts to justify doing an SAQ D versus the ROC.
All of that said, if you are a service provider registered with Visa or Mastercard, then you MUST do a ROC.
So the challenge I have here is the service provider does not see the tokenized cc data as cc data –
Okay, there is a clarification. If they only see tokenized data, then it is NOT classified as cardholder data and therefore NOT in scope. Meaning they are NOT in scope. I read your original message as they were the tokenizer, not that they were only seeing tokenized data.
Can a SIEM be used in lieu of a FIM for satisfying the requirements?
If properly configured and can be shown to function in the same manner, yes, it can.
Hi PCI Guru,
Thanks so much for your site! It has very useful resources and information that I could not find anywhere else. With that being said, I have question regarding requirement 8. In the “overview” narrative for both v3.2.1 and v4.0, there is a statement that says these requirements do not apply to accounts used by consumers (cardholders). Does this mean the entirety of Requirement 8 does not apply to consumers? Not even password complexity requirements? On all systems or mobile apps that are customer facing?
Thank you in advance for your time and help to clarify this!
Sadly, yes, they do not apply. So you need to plan and design your solutions accordingly. If your organization chooses to follow the DSS guidance for consumer credentials, you can do that.
Hi PCI Guru
Whether Format-preserving encryption is certified by PCI authorities. Some links for reference:
https://en.wikipedia.org/wiki/Format-preserving_encryption#Acceptance_of_FPE_algorithms_by_standards_authorities
Publications by NIST:
https://www.nist.gov/publications/recommendation-block-cipher-modes-operation-methods-format-preserving-encryption
https://csrc.nist.gov/publications/detail/sp/800-38g/final
Question: Can a service provider change their PCI AOC due date because of a merger or acquisition with another company?
That is a discussion with the card brands (if registered on their sites), banks that are involved (if at all) and your customers. I have seen that happen, but not without discussions with all of those parties.
Hi PCIGuru,
I have observed full pan in the footers / remits of statements from several card issuers Chase, Wells etc. possessing. Understanding that they need this to process transactions whether internal/third party ( ex: MoneyGram etc.) for physical mailings, but finding it hard to understand how reference IDs/surrogate values are not required. I suspect they would say its the course of business, presents minimal fraud risk, and would be a lift on the backend core processing to correlate that surrogate to PAN, but PCI is clear that full pan needs to be masked/sanitized. Thoughts? Thx
The PCI DSS does allow for the display of full PAN when required by a business process. In this case the payment of a bill via snail mail.
I’m curious on your opinion of how the use of EMVCo tokens (and similar tokens) affect PCI DSS scope for a Merchant. PCI FAQ 1326 says that the token and cryptogram are not Account Data (not in scope). However, Mastercard MDES guidance states that storing the Token and Cryptogram is effectively equivalent to storing PAN and PCI DSS should apply.
Other industry sources I’ve looked at (e.g. Visa) provide no or very vague guidance.
What’s your take on this?
Regards,
-Erik
Another area where the Brands and Council are at odds. But in that case, the Brands win. I always advise clients to take the worst case, in this case Mastercard, and follow that guidance. If Mastercard says it is not allowed to be stored, then don’t store it.
Since this blog reaches such a large audience, I’m hoping that I can ask a question of the community.
Has anyone translated the PCI DSS v4.0 Standard into French? I’m hoping someone has already done this work.
Not that I am aware.
I’m trying to understand the impact of 8-digit BINs on PAN truncation. From the current version of PCI FAQ#1091, it seems storing the full 8 digit BIN + any other 4 digits is OK for all brands except Amex. Amex still accepts no more than First 6 + Last 4.
If I understand this correctly, it means that the truncation function needs to determine the card brand for each PAN and then apply different truncation methods (assuming you want to store the whole BIN).
Is that correct, or did I misunderstand something?
Nope. Your analysis appears correct. That said, this is where things will get messy and people will screw up. It will get even worse when multiple groups in the same organization use different truncation rules where it will get really messy and create the compliance issues.
Visa has muddied the waters here a bit recently. This Visa FAQ document states you would also need to encrypt, hash, or tokenize anything more than the first 6 and last 4.
Click to access visa.com-numerics-faq.pdf
“PCI-DSS allows exposure of the first six and any other four digits in a PAN as the only method
for protecting data at rest. If a merchant would like to expose the full eight-digit BIN as well as
the last four digits, they will need to add one or more of the other acceptable methods for data
protection, such as encryption, hashing or tokenization. Merchants should consult their Qualified
Security Assessor (QSA) prior to implementation”
Contradicting FAQ 1091 on the council’s website.
One thing I think will really mess things up is the difference between truncation and masking. Very few people I meet (even QSAs) understand the difference between truncation and masking. That used to be no big deal, because the rule was the same for both.
Now we have the new 8 digit BIN rules for truncation, while masking is still 6+4…
It’s a problem waiting to happen particularly in organizations with multiple teams and everyone picks their particular version of truncation. What could possibly go wrong? 😉
Hi Guru,
Kindly can you share or refer a link for PCI-DSS Network Pentesting checklist.
Thanks,
Deepak
Not a checklist, but guidance from the Council on the subject. https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
If an entity is using a SIEM with installed agents that report to a cloud instance of the SIEM, and that SIEM doesn’t have an AoC, and the QSA decides to assess the SIEM ad hoc for the current RoC, how rigorous, or which of the 12 sections would the QSA assess on that SIEM? (not meant to sound like a limerick)
All the requirements that apply which, sadly, is most of them.
Obviously section 10, but also section 1 (it has a network that connects the SIEM), section 2 (it’s some sort of HW/SW either real or virtual), section 3 (the QSA must prove that the SIEM does not store SAD/CHD), section 5, section 6 (vuln mgmt and change mgmt), potentially sections 7 and 8 (depending on how authentication and user management are performed), section 9 regarding the physical security of the hosting DC, section 11 (wifi at the DC and then vuln/pen testing), finally section 12 for the DC’s employees.
Hi,
I’m curious if you have any comments on the recent FBI investigation into Pax Technologies, as reported by Brian Krebs and others. Should merchants who have Pax terminals be worried?
From what I have read and in talking to others, the problem is NOT with exposure of SAD/CHD it is that these devices are being used to compromise networks. Also, it seems that the POI in question are wireless, not the wired POI. But time will tell if wired POI are also an issue.
That said, I have worked with a number of merchants that are using the PAX POI and I was always concerned with the fact that PAX had unfettered access to “monitor” and “update” those POI in a lot of cases even though the processors typically handle that task with Verifone and Ingenico POI. In one case, BoA required me to write a CCW for the PAX access because I brought up the fact that PAX was NOT PCI compliant and could not provide an AOC for their monitoring and updating.
It will be very interesting to see how this plays out.
Would you accept a self-signed AOC where the SAQ-D was dated 3-months prior to the officer’s signature?
Actually, it’s 4-months, not 3
Self-signed SAQs are always a concern, but given how the card brands treat them, they are legal representations by the person signing them that the organization is PCI compliant.
As with any executive, documents get “lost” in their inbox and they do not get signed in a timely manner. If it is signed, it is a legal representation that the organization is PCI compliant and should be treated accordingly. That said, it is up to the receiving organization as to whether or not they accept that representation. If you are uncomfortable with that time frame, it is within your rights to reach out to the organization with your concerns and talk through those.
We recently changed vendors/applications for our front desk and now all CC transactions are run through a 3rd party. If the old servers are still on, but are no longer processing CCs (haven’t been for 3 months) are they still in scope for this years audit?
If they still have card data on them, yes they are until you properly decommission and wipe them.
HI. Would this also be true for HSM hardware? If MFK and all keys are removed, reset to factory? I recall something regarding the chain of custody upon initial possession of the HW but can not find anything upon retiring the devices and if the HW must be sent back to the MFG or can be recycled.
Most HSMs have a factory reset or similar utility that will securely decommision the device which would remove all sensitive information in the HSM. Provided it has that capability, it should not matter whether you recycle it or send it back to the manufacturer. That said though, I would probably lean towards sending the device back to the manufacturer regardless.
I work for a company that sells products. We pay a third party company to handle our credit card transactions (we don’t store numbers, we take them over the phone and put them straight into this vendor’s website). As such, we might need an SAQ C-VT. However, the employees who are taking the numbers work for another third party and so does the building they work in and all the equipment. So company A is a subcontractor of ours and they run the entire call center that takes the numbers. Thus, our direct employees and our direct equipment do not ever touch credit card numbers. My question is whether we need to fill out the SAQ, or company A does, or both?
The answer is going to depend on whose merchant identifier (Merchant ID) is being used to conduct the card transactions.
If it is YOUR company’s merchant ID, then your company needs to fill out an SAQ A because everything is outsourced. However, for requirement 12.8, you will need PCI Attestation of Compliance (AOC) from your two outsourcers.
If the outsourcers are running the transactions through their merchant IDs and just sending your company a check, you should have their AOCs on file to prove annually that they are compliant but your company does not need to fill anything out.
Hi,
I’ve encountered a strange practice from an Asian processor/acquirer, where half the card PIN code (first 2 digits) is sent as part of authorisation for e-commerce payments.
They claim the half PIN code is not in scope for PCI DSS. As far as I know, there are no truncation rules for SAD. To make the PIN unreadable, you have to use cryptographic methods.
Protecting the transmission isn’t a problem, but would the half PIN code “contaminate” systems it passes through with PCI DSS requirements? I’m inclined to say YES.
How would you approach this?
I think you mean the card verification value (CVV) rather than the PIN. The PIN would only work in a card present transaction scenario and you are speaking about an eCommerce transaction.
CVV is considered sensitive authentication data (SAD) and is required to be protected at all times and cannot be saved once a transaction has been either approved or declined. Splitting the CVV is not going to remove any intermediate systems from scope, so there is no scope reduction in my view.
Besides, we are talking about a four digit number that can be easily guessed if you have half of it.
As far as I’ve been able to tell, it is actually the card PIN, not the CVV. I think it may be some kind of wierd effort to get better authentication of e-commerce transactions, without using proper 3DS.
Thanks for your input! It confirms my view that SAD cannot be made unreadable by truncation.
If it is the PIN, how do they compare it to the PIN block? That is how the whole thing works. Without the card and the PIN block, the transaction fails. This sounds like some sort of scheme to obtain people’s PINs, not a security measure.
As far as I’ve found out, it appears to be a standard practice in Korea to require CVV and half the PIN code for e-commerce authorisations. I have no idea of how they actually use it.
I’m still trying to verify if it is used for all cards, only for local non-branded cards, or just for cards issued by specific Korean issuers.
The acquirer has now changed their mind, and say the half PIN is indeed in scope for PCI DSS.
Strange case indeed…
Thanks for your input!
I have a couple of clients in South Korea and neither uses half the PIN with eCommerce. I have also checked with some colleagues that have clients in SK and none of them have encountered it there either. Granted, all clients are subsidiaries of US-based retailers, so that might have something to do with it. But this is the first time we have ever encountered it.
So, I got more clarification from a QSA colleague. They think you are referring to the South Korean MyPIN or iPIN which is a personal identification number of 13 digits and has nothing to do with a payment card PIN. The MyPIN was introduced to reduce online fraud.
Hi,
We did double-check several times with the Korean processor and they confirmed that it was indeed half the actual PIN code for the card. I guess it works because they are also Issuer/Acquirer and processor for these cards. The half-PIN was not used for cards from other issuers. The cards are PCI-branded (Mastercard or Visa I think), so they are in scope for PCI DSS.
Strange case. I guess when you don’t have proper solutions available (like 3D-Security), companies will come up with “home-made” solutions to solve problems.
Interesting, but you are probably right. When in a vacuum, nature finds a way to fill it.
Hello PCIGuru
I have question with regards to taking Credit Card Payments over the phone in the current corvid climate where people are asked to stay in. In a situation where you do not have a phone automated payment system are their any requirements to be compliant taking payment over the phone apart from the obvious once like not to write down Credit card numbers, do not repeat the number back etc..
Regarding automated payment system are there any exceptions/catering for visually impaired people?
I think you have the basics down. Where telephony payments get into trouble is over voice over IP (VoIP) because the Council considers that no different than transmission of CHD/SAD as digital data. There is an Information Supplement on Telephony Security on the PCI SSC Website that you should read concerning VoIP.
In regards to visually impaired, I am not aware of any exceptions offered for solutions that cater to them.
Can you shed some light on what constitutes a “shared hosting provider” Requirement 2.6?
For example, if I use AWS to host my web application for looking up credit bureau information, am I considered a shared hosting provider?
From the Guidance column of the PCI DSS v3.2.1.
“This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client’s data and thereby gain access to all other clients’ data. See Appendix A1 for details of requirements.”
Under this definition, the best example of a shared hosting provider would be one that hosts a single instance of a Web-based eCommerce application that multiple organizations all use. Each organization’s data and users are segregated from one another, but they use the same application instance.
If the merchant is using Non-VoIP based PRI (Primary Rate Interface) to transmit and collect CHD, would this bring the telephony infrastructure (SBC, PBX, etc.) in scope for PCI? or Can they be NA as it is not VoIP based.
No. You cannot mark them as “NA” because they do process and transmit CHD/SAD. You must acknowledge the risk (msall as it is) and what you do to mitigate or remove those risks.
My organisation uses gmail using SSO to access their customer care call management software. The call management software is cloud hosted and they are PCI compliant. My question is whether using free gmail accounts to access the call management software prevents us from becoming PCI DSS compliant?
I think what you mean is that your personnel access your hosted Call Management solution using their GSuite SSO. If that is true, GMail (or any of the other GSuite apps) has nothing to do with anything other than the SSO solution grants access to all applications covered by the SSO solution.
PCIGuru
quick question.
Is there any value to having a QSA assist with completing a SAQ-D over just paying for the ROC? The cost difference not being much different. What I am asking is, do you see a benefit of doing one over the other?
IMCHO, an SAQ D is more like a auditing an education class versus actually attending the class to get a grade (i.e., ROC). Both however result in an Attestation Of Compliance (AOC) which is what you turn over to a customer if you are a service provider.
The only difference would be with your acquiring bank who would likely prefer to see a ROC vs. an SAQ D, even when a QSA does an SAQ D. Sadly though, I know of firms that do not do much, if any, examination of evidence and just check the boxes, sign the AOC and move on. Which is why banks prefer the ROC over the SAQ.
Regarding Bearer Tokens:
One of my programmers recently asked me if there are any PCI DSS requirements regarding bearer tokens. Specifically, he is asking how often does PCI DSS recommends they be changed (rotated). I am unfamiliar with Bearer Tokens and have not been able to find any direct PCI DSS requirements that would influence the bearer tokens. I did find the RFC (https://tools.ietf.org/html/rfc6750), which has some recommendations regarding the rotation, but would like an expert’s opinion on how Bearer Tokens should be managed and secured in an environment that is within the scope of PCI DSS.
There is no guidance on this topic currently and I do not recall it being discussed in any of the v4 drafts, so I would expect no explicit guidance coming from the PCI DSS in the future. The Council may create an Information Supplement to discuss the topic, but that also is something for the future.
That said, section 5 of the RFC has a great discussion on threats and mitigations to protecting the bearer tokens and I would use that as your reference.
My guess would be you would want to rotate the token however often it makes sense based on the information being protected. General business information could have the token rotated annually or semi-annually. Payroll information might want a token rotated monthly.
Hi
Thanks for the excellent site. Really useful.
I have a question regarding devices from iZettle (and this probably refers to others such as Square).
I understand that in this case, iZettle is the merchant, and therefore responsible for PCI DSS compliance. If I want to use these devices on a corporate LAN, where do I stand? Do I need to implement a segregated network, and complete a SAQ? Or do I just take iZettle’s statement at face value, and do nothing special?
Good questions.
Unfortunately, we need more information to get you answers. I went out to the Zettle Web site and could not find any information on their POS solution. I assume it is end-to-end encrypted, but without explicit proof of that, I cannot say if you need to segment your network.
Technically, Zettle is your acquiring bank, so they would be the ones requiring your organization to file an SAQ with them. If they are not requesting one, then you do not have to do one. That said though, I would recommend doing an SAQ B-IP for this solution just to make sure that you have all of those requirements covered.
One other thing you need to do is to have an incident response plan in case the POS solution is tampered with or hacked. You will also need to have a procedure in place to examine the POS periodically to ensure that it has not been tampered with.
Hi Guru,
Our organization’s PCI program is maturing, and we are now expanding our requests for AoC’s beyond just those service providers who use our MIDs on our behalf. We’re now asking for AoCs from vendors who use their own MIDs, but may pose a risk to our “brand”.
For example, an outsourced foodservice vendor with their own MID, POS system, employees, and network connectivity, but operating on our premises, and handling credit card data of our customers and employees.
Because of the risk to our customers, employees, and our organization’s “brand” from a breach, we are requesting their AoC. In response to our request for an AoC, if a vendor asks “what does PCI AoC stand for?”, we believe we may have identified a credit card data risk that needs to be addressed.
Q1: What are your thoughts on this?
We asked the vendor whose name appears on the onsite vending machines (which accept credit card payments) for their AoC. They informed us that the vendor we contracted with for vending machine services actually subcontracted to them, and they in turn subcontracted to a third vendor. While we think we need an AoC from the party with whom we initially contracted, they would not be reasonably able to attest to what the 3rd subcontractor is doing.
Q2: Can we accept an AoC from this “3rd vendor / 2nd subcontractor”?
Q3: If this were an actual PCI-defined service provider, could we accept an AoC from a party we don’t directly contract with, or does that necessarily have to be attested to by the service provider we contracted with?
–I really hope that made sense!
And thanks, guru!
Pat
To your Q1, good luck with that. The vendor is technically correct in that it is whatever subcontractor that is responsible. That said, the vendor should have that AOC as part of their due diligence.
As to Q2, that is up to you. There is nothing in the PCI DSS that says otherwise.
For Q3, if you talk to your legal counsel, your organization has contracted through the legal process with the entity that is responsible. It is not direct, but all parties are legally bound, so technically there is accountability for compliance.
Hello guru
I have a question about searching credit card information on the Deepweb/Darkweb.
I enter my credit card number in the system of a service provider and he regularly searches for this number in the darknet, in various forums.
Do service providers who offer such services and store the credit card number in their systems have to be PCI-DSS certified and if so is a SAQ sufficient ?
thank you
Frank
They should be PCI compliant, but I am guessing you are pointing out a gap in PCI compliance that flies under the radar.
That said, an SAQ is fine as long as they do not handle more than 300K PANs. More than that and they should perform a Report On Compliance (ROC).
Hi Guru,
How can one provide evidence to the PCI auditor for requirement 4.1.c if the environment resides in AWS VPC and using wireshark is not possible?
4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.
Thanks
In this case you would have to rely on the configuration of the HTTPS and TLS certificate or whatever else is being used to encrypt the connection. You then say that you observed that HTTPS appeared in the browser or that you observed that the connection was encrypted.
Serverless, virtual networks, etc. create a number of issues that are not easily addressed in the current PCI DSS because it was written before such technologies exist. Not that they cannot be addressed, you just much be creative in getting your evidence.
Hi
I have a scenario where we have outsourced our online event ticketing to a compliant service provider. They handle all payment functions, using one of our merchant ids. My question is this. Where do we stand if we allow a member of the public to access the booking website to make their booking and pay for their tickets at one of our physical locations, using our PC, network etc.? I can’t decide if this will bring our network into scope or not.
If the payment is occurring on a device and network you own, yes, it will be in scope. That said, if you use a payment terminal (aka POI) that is a P2PE or E2EE device and you use tokenization, then only the POI is in scope.
Hello,
Question regarding segmentation and category 2/security impacting systems. Can you tell me, how is segmentation looked at from this perspective? More specifically, do these Cat 2 systems need to be in their own network segments and will the firewall rules that isolate them from the rest of the corporate network (not the CDE) also be in-scope for the firewall reviews? If for example a domain controller could connect both to the CDE and other non-CDE environments, would the assets in the non-CDE environment then be pulled into testing scope?
Is there any guidance the council has put forth that speaks to this specific use case?
Easiest question first. See the Information Supplement ‘Guidance for PCI DSS Scoping and Segmentation’ for reference. https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
As to your first question, you need firewalls to segment CDE, Connected To and not in scope network segments from one another. That does not necessarily mean separate firewalls (best approach), but separate network adapters on a single firewall with the appropriate rules. Connected To (Cat 2) systems are always in scope because they connect to systems that are directly in scope. Connected To systems are allowed to communicate to the CDE as well as out of scope systems but you must ensure that the out of scope systems cannot effect the security of Connected To systems that could then effect the security of the CDE.
How can organisations with their PCI-DSS assets in amazon cloud for example comply with requirement 1.1.7 that talks about firewall and router review every six months? knowing that they don’t have control over the firewall and routers
Pardon? This is a shared responsibility if you read the AWS responsibility matrix. AWS merely provides the capability, but your organization is responsible for establishing the firewall rules and network routes.
Made an error in my last post..:
Text contained in the major card brand program guides is somewhat confusing when it comes to deciphering franchisor/franchisee/TPSP PCI DSS accountability (think RACI model). American Express provides the clearest directive, as AMEX states that [remove all] “covered parties” are accountable for all entities associated with the entities’ Merchant Account.”
In most franchise arrangements, it is the franchisee that is on the hook for PCI DSS compliance. Where that can get messy though is with for example fast food where the franchisor may have connectivity into the franchisee’s systems for account, HR, inventory, ordering, monitoring, etc. In those cases, the Franchisor needs to be providing an AOC to the franchisee for those services they provide that could impact the security of CHD/SAD.
A prime example of this arrangement is Exxon/Mobil Speedpass. That program is managed/maintained by Exxon/Mobile on behalf of their participating franchisees. Exxon/Mobil originally stored the CHD information and all transactions flow through them thus making Exxon/Mobil a service provider to their franchisees. It is my understanding now that Exxon/Mobil only stored tokens which gets the CHD out of their systems but they are still a service provider to their franchisees.
Do you happen to know if there are any limitations around reporting entities for ASV scans vs. SAQ’s? For example, if an entity reported via multiple SAQ’s, can they all rely on the same ASV scan providing that the appropriate hosts are included in the ASV scan or do they need to be separated to align with the SAQ’s?
I would have to ask why there are multiple SAQs with only one set of ASV scans. I would assume that the ASV is scanning everything used by the organization but for whatever reason there is an SAQ for each business unit for example. When that happens, you need to call out what infrastructure belongs to what BU for their individual SAQ.
I work for an acquiring bank and can confirm that there is no limitation in the Card Brand rules that prevents an entity from reporting their compliance using multiple SAQs and a single all-encompassing ASV. The primary reason an entity will attempt to report using multiple short-form SAQs is to align their acceptance channels in their CDE to the chosen SAQs. So long as the ASV scan tests all external IPs, it shouldn’t be a problem for the acquirer and Card Brands to accept. As PCIguru points out, you have to call out the infrastructure that belongs to the particular acceptance channel / SAQ.
As an acquirer, we encourage merchants to aggregate multiple SAQs into one SAQ-D. They can validate using multiple SAQs if desired, but only one document should be submitted. This is easier for us, but moreover it ensures that the merchant has only one published compliance date in Section 3 of the AOC. Those merchants who report using multiple SAQs don’t always publish the same date on all SAQs making it more difficult for the acquirer to report compliance to the Card Brands.
I’ve chased leads for over a year now, and have found statements supporting every side of the argument. I understand it can be complex, but the basic question should have a definitive answer available somewhere without all the circle talk.
Scenario: I have a small office that takes card-present payments and is equipped with PCI-DSS approved P2PE hardware. The office is compliant and follows the P2PE requirements to a T.
Twist: This office has begun taking phone payments over a VOIP system and entering the CHD on the P2PE keypads on behalf of the user.
Question: Did this office’s SAQ qualification just change from a SAQ-P2PE to a SAQ-D by beginning to take phone payments over a VOIP system?
Bonus Points: Does a possibility exist that would enable the office practices to proceed while still qualifying for P2PE? (Segmentation?)
Yes, your scope now includes the VoIP solution because people speak CHD/SAD over the phone. As a result, you are never going to be just P2PE once you added in VoIP.
As to SAQ, yes you are probably going to have to use SAQ D to cover VoIP although a good portion will likely be marked as Not Applicable.
One option is to outsource your VoIP and do end-to-end encryption (E2EE) between handsets and the call manager and other VoIP servers. That leave only handsets in scope which is not a heavy lift.
Where organizations run into trouble is when they have softphones in use because softphones drag the workstations they run on into scope regardless of whether they discuss CHD/SAD via phone because they are directly connected to the CDE.
You need to read the Information Supplement on Telephony from the PCI SSC Web site.
Thanks a bunch for your insight.
After about 3 years on this project I still learn new things every day.
Our VOIP implementation is already a hosted setup although, we are exploring DTMF masking in order to potentially de-scope the phone payments back out of the equation and get back to the P2PE qualification we desired. Hopefully DTMF masking can help us accomplish this.
I have read the supplement you referenced, as well as every other resource I can possibly find regarding this subject. The answers are just not as clear as I would like. Your site has been one of the best resources of “plain talk” information I have found. Thanks a ton for that.
In regards to your statement regarding “a good portion will likely be marked as Not Applicable”, I have one other hypothetical question to ask, as this too has produced conflicting information.
Scenaro: If a company uses a flat network, but has two distinctively differing payment channels/processes, one meeting P2PE qualifications (branch office) and the other qualifying for SAQ-A (call center), I understand the proper way to accomplish this is by utilizing a SAQ-D to fulfill both channels.
Question: If utilizing the SAQ-D form, can the company complete ONLY the requirements that are required either on the SAQ-A or the SAQ-P2PE form and mark EVERY OTHER requirement on the SAQ-D form as N/A, with the explanaition that it doesn’t apply to the SAQ-A and SAQ-P2PE qualifications, also fully explaining the intent and reasoning in the Executive Summary on the SAQ-D form.
Thanks again for your insight. Your information provided at this site is awesome.
Whether or not DTMF masking reduces scope is dependent upon where it occurs. If it is before it hits the VoIP system, then it will reduce scope. If it occurs after (the most common implementation), the CHD is still going through the VoIP system and therefore it is not out of scope. It doesn’t matter that operators cannot hear the DTMF, its the fact that the call is still going through the VoIP call manager which is transmitting it to the DTMF masking solution.
The short answer to your question is Yes. However, given my previous clarification, you may want to reconsider whether SAQ A is realistic for your call center.
I have a question about MFA factors. Would a Kerberos token returned from a SAML call constitute a “Something you have” factor?
The Kerberos token is obtained by the user providing credentials. If the user’s credentials are compromised, anyone with those credentials can generate the Kerberos token so it is not MFA. The purpose of MFA is to not rely only on user credentials. You are relying on independent factors that cannot be derived from the other factors.
Thanks for those thoughts and I do agree with the position you’ve stated. The Kerberos token is obtained from a completely separate authentication environment from where the service is provided, and the user credentials which are associated with the service are validated in another separate authentication environment. So, the attacker would have to successfully compromise two disparate authentication environments to succeed with that attack. That situation does seem to fulfil the property of independence.
But is not the Kerberos token created as part of the authentication process using the user’s credentials to start the process? I would agree with you if the user must authenticate to LDAP for an example and then use different credentials to authenticate to Kerberos.
However, in all of the Kerberos implementations I have seen, it is the user’s single set of credentials that authenticate as well as generate a Kerberos token behind the scenes. That is not MFA as defined by the PCI DSS nor NIST. You need two independent factors used to qualify as two factor authentication. Hence the something you know and something you have or something you are. One factor cannot generate the second or third factors.
The entity is trying to access a TPSP portal. The entity has implemented the following process. The entity has their auth system, a federated login based around AD. The TPSP has their own independant auth system, in no way related to the entity’s AD. An end user must have credentials on both systems and both access provisioning processes are separate. Having any one set of credentials does not guarantee portal access.
The entity’s AD and federated login both need to be compromised to falsify a Kerberos token. The same assailant needs to compromise the TPSP’s AD to falsify the portal access. Both the entity’s token and the TPSP’s credentials are presented to the TPSP to get access. If access fails, it’s not possible to determine whether the token was bad or the TPSP credentials were bad.
I see two logons with different credentials. By definition that is NOT two factor authentication. See NIST SP800-63B for more information.
Hello Pciguru,
What is the short term solution to resolve application hosted in PCF to connect directly with applications hosted in pci zone?
PCF? I am assuming you mean applications in the “Connected To” segment/zone that connect to the cardholder data environment (CDE). This happens when an application such as Active Directory which has to communicate with PCI in-scope and not in scope devices. The Scoping and Network Segmentation information supplement is a mandatory read to understand this situation. Get your copy here https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf
Hi PCI Guru, thanks for your support.
I have a question on SAQ A.
While SAQ A doesn’t not mandate customers using iframe on their website to have requirement 5 ( Antivirus ) and FIM solution and tea 10- logging , is it fine to go ahead with compliance without these basic important security requirements.
The ecommerce guideline from PCI do recommend these in addition to SAQ A controls, but are these mandatory.
Can we go ahead with certification without AV, FIM and logging for a website using iframe and eligible for a SAQ A.
Thank you.
Remember, the Coucil always reminds people that the Information Supplements do NOT replace any requirements in the PCI DSS. They are written only to provide additional information on ways to approach compliance issues encountered when dealing with the PCI DSS.
That said, I always explain to my clients that just because you are PCI compliant, does not mean you are secure. When that SAQ A compliant Web site gets compromised, it will NOT be the acquiring bank that is on the legal hook for that mistake. It will be you Ms. Client that is legally on the hook, so please act accordingly.
If it is NOT in SAQ A then to be PCI compliant, it is not needed.
Thank you 👍
Hello Pci guru, thanks for all your insights.
I have a question on call centers.
If the call centers uses third party pci compliant call center soution that integrates with your calling soultion and makes uses of DTMF tones ( eg solutions from Secure co, semafone etc ) and thus call center agents do no see or hear card numbers or SAD, is the call center still is scope of pcidss.
If yes what controls are to be validated in the call center. Thanks.
The problem with DTMF solutions is it all depends on how they are implemented. While call center operators cannot hear the tones, the call may still be processing through your Call Manager or telephone system which means it is still in scope. This is why you really need to follow the call flow to make sure that when DTMF is used, that VoIP flow is not still within your telephone system.
Thanks for the insight .
Hi PCIguru,
Thank you for your work in maintaining this website. It has truly been informative and helpful.
I have a query with regards to an organisation that has remediated their environment, and now meet the criteria for an SAQ-A and SAQ P2PE, BUT…. they believe they have CHD stored within legacy backup tapes in the form of email, files (e.g. Excel), etc. It is not a trivial task to restore all backups, search for CHD and securely delete them, as the backup of the environment is spanned across multiple tapes per backup run. Additionally, some legacy backup tapes exist but the system to restore them have been replaced with newer technology. The tapes are kept offsite in a secure facility and will eventually be disposed of in a few years time, when the data retention requirements have been exceeded.
So, is there a way to ring fence these backup tapes, so that it does not contravene the SAQ requirement of legacy CHD Storage in the environment, and ultimately be assessed with an SAQ-A and SAQ P2PE.
Cheers,
Joe
Thank you for your question Joe.
This is not as unusual a problem as you think. A lot of organizations get caught in this dilemma as they dig ever deeper into their processes and procedures. It’s a lot like cleaning an attic. I am assuming by your “remediation” comment that they have cleaned up their act going forward and are now dealing with their sins from the past.
First thing they need to do is to determine secure methods of dealing with this situation. If there are tapes that cannot ever be used, those should be securely destroyed as soon as possible.
I am assuming that the remaining tapes are not encrypted so they must be accurately tracked and secured. Assuming those tapes are in a facility like Iron Mountain, that physical security should be sufficient. Then you will need to make sure that any request for these tapes being brought back is approved by at least two people, one being an executive (i.e., CFO, CIO). If brought back, the tape must be secured when not in use such as being stored in a safe or locking secure cabinet and any access to use the tapes are logged. Once done with their use, they should immediately be securely returned to the offsite storage facility.
Once you have those procedures documented and in place, the organization needs to talk to their acquiring bank about this situation and determine how the bank wishes to deal with it. The organization will explain their approach and get the bank’s approval to continue or will implement any changes.
You will also want to discuss how the bank wishes you to report the fact that there is storage of CHD until it is purged with the last tape that contains CHD. That will be a $64K question. I have had banks say to report it on an SAQ D (most of which is NA) to just notate that it exists in the company’s file and the date the condition will no longer exist. I cannot give you any guidance as to how the bank will approach that situation.
Good luck!
Thanks PCIGuru. That will be an interesting discussion with the banks. Cheers !
First, I thank you for your site and for your ask the PCI Dream Team web casts – they are a great resource! I would love to hear your thoughts on how much of SAQ A applies when the “redirect” is to a hosted form such as those offered by merchant payment gateways NelNet (QuikPay) and Authorize.net (Simple Checkout). Both of these large payment processors offer customized forms that are “linked” to via a custom URL. The merchant sets up a custom form on the payment gateway, then includes a custom URL on their web site that redirects the customer to the payment gateway/custom form to make the purchase. The US Treasury has something similar they offer on pay.gov. The URLs are also sometimes included on a printed form, or sent to the customer in an email. These custom forms are typically used for single purchases, like a electronic bill, vs. filling a shopping cart with items then making a payment. These methods fall under SAQ A, but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)? For example, many universities use QuikPay (a simple google search on “commerce_manager/payer.do?orderType=” will return many examples) and may have hundreds of such links on their Web sites (which may be hosted by many different internal and 3rd party organizations). These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A? How is this any different than just redirecting the user to another eCommerce site altogether (e.g., to ticketmaster.com)? In one of your responses to a comment on you “of redirects and reposts-updated” article, you stated “Just because a Web site sends a user to another Web site and that Web site is an eCommerce site, does not mean that the original Web site needs to be PCI compliant. That would mean that the entire Internet would need to be PCI compliant and we all know that will never happen.” I would appreciate any thought you might have.
“but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)?”
I would refer you to the SAQ A criteria documented on page iii. I would also refer you to the PCI SSC FAQs with a search for ‘SAQ A’. All of this information can answer your question.
“These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A?”
It all depends on how the redirect or iFrame are implemented. Again, some of the aforementioned FAQs on SAQ A address your question.
Your merchants my be correct about their scope regarding SAQ A but this is all contingent on how the data does or does not flow through their Web site. That said, as I have pointed out many times, while an organization complies with SAQ A, that does not ensure they are secure. Should a bad actor change the redirect or iFrame invocation, that error will be on the merchant, NOT the service provider or their bank. So people need to look beyond just being compliant because that does NOT remove or mitigate their risks.
Hey PCIGuru, first of thank you for this amazing page and thread. The info from your answers here are very helpful.
We have a web application that we are adding credit card payment functionality to with a partner who handles the full CC transaction. We don’t store or process anything but use Checkout.js to tokenize the transaction with our payment partner. We are under SAQ-A-EP.
I have a couple of questions regarding inactivity timeout (specifically 8.1.8) “If a session has been idle for more than 15 minutes, are users required to re-authenticate to re-activate the terminal or session”
Given the industry and the way our application is used we are trying to come with a different solution. One idea is rather then log the user out of the system completely after 15min, would be to make them authenticate again when accessing the CC payment/management area then log them out of that portion of the application that deals with CC payments after 15min of inactivity. Would that be acceptable or is there an easier method like a cookie timeout?
Second question, I’m a bit baffled that many SAAS admin consoles I use on a daily basis such as Office 365 and Atlassian don’t seem to log you out after 15min of inactivity, it made me question my interpretation and I was wondering how they get away with that?
Requirement 8.1.8 applies to people you control such as employees, contractors, third parties, etc. that have access to systems and devices in the CDE. Not consumers that are shopping on your site.
That said, if someone was paying for something and got side tracked and did not complete payment, I would like to think you or your processor would step in and deactivate the consumer’s session after 15 minutes or less.
thank you!