By PCIGuru

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.


1439 Responses to “Miscellaneous Questions Page”


  1. February 3, 2017 at 6:26 AM

    Hello again Guru, apologies if this is the wrong topic to post this enquiry (regarding scoping) but thought the topics listed under scoping are more your topic posts than discussion posts. Anyway, i would like to query scenario 5 in the Open PCI Scoping Toolkit. I have a similar set up with a category 1a workstation and further workstations that are not used for processing CHD which may be segmented or not from each other. This is because the 1a work stations use a web application to process CHD, this application is hosted in a data centre provided by our ISP who provides an internet break out connection for general internet usage. The application in question is accessed via a URL just like customers who use our ecommerce websites (on the same platform). A firewall detects when 1a workstations are accessing the CDE application based on the URL and rather than sending them out on the internet to come back in to the application it routes the workstation directly onto the application. However there is nothing stopping any other workstation from accessing the URL via a web browser either. The application is accessed over an MPLS and uses TLS as standard, the application requires a log in with username and password, so even users who use the application for other purposes cannot access the CHD collection page (job role based access) but I cannot get my head around the fact that regardless of this the application is accessible to all internal staff who have internet access (we do not limit access via IP as we hot desk and repurpose desktops quite a bit). So my understanding would be that the desktops used to process CHD will be 1a while desktops segmented on our network that do not process CHD would be category 2b correct or would they also be 1a because they have the potential to connect? but not sure about any unsegmented desktops that are not used for CHD but can access the application, the operator would have to be using a user account that had access to the payment page and would have to have obtained CHD from somewhere else as we do not store CHD, you can only enter it into the application like a customer at home could using a shopping website. Would such workstations be 1a or 2b or other category?/ Thanks again for your insight.

    • February 11, 2017 at 10:02 AM

      If I understand your configuration correctly, you are using TLS to secure your Web site that accepts payments. Therefore the TLS connection is what “segments” your 1A workstation and would segment any other workstation regardless of internal or external access.

      Your risk to all workstations is that someone installs a keyboard logger or memory scraper to a workstation and obtains the CHD in that way. As long as you minimize that risk (AV alone in my opinion is NOT sufficient), you should be compliant.

  2. January 26, 2017 at 10:45 AM

    As a follow up to your comment “Also I have seen instances where manual data entry is through the thin client’s keyboard, not the POI which also brings the thin client into scope.”.

    In those instances where manual data entry of CHD is through a at-home/remote agent’s thin client’s keyboard, does this then bring the workstation, running the thin client, into scope for PCI requirement 11 (e.g., vulnerability scans, pen tests, etc.)?

    In addition, does this then bring the above workstation into scope for the credit card ccompany’s PCI requiremnts for an ASV vulnerability scan?

    Thanks,
    Charlie K

    • January 28, 2017 at 8:46 AM

      It depends on how that remote workstation is configured. Remember the Microsoft hack a number of years ago when the XP code base was released? That was through a remote contract worker’s home PC being used to access the Microsoft network. That is the risk. Now, how you implement controls and reduce that risk for your remote environment is up to you. This is why a lot of my clients supply their own workstation and firewall for remote access so that they control rules and hardening. But as to ASV scans and other controls, that will depend on how you have implemented your remote access.

      • 5 Nick
        February 8, 2017 at 11:46 PM

        Hi there. Long time reader, first time poster. We have a client that has a website taking payments. They have implemented an iframe (scope reduction not security improvement). Obviously SAQ A if it is done properly. The question comes in that they use a non-compliant Third Party Service Provider to conduct maintenance of the environment hosted in AWS. They also use a non-compliant Third Party Service Provider to conduct development of the website.

        My question is, do these Third Party Service Providers have any requirements in SAQ A. In my view, the maintenance company has no requirements as they have no access to the web config. The development company has no requirements as the payments are via an iframe.

        I would think the development company has some requirements as the iframe code could be altered to go to an evil iframe and nobody would know until the client is not being paid, however, there is nothing in SAQ A to state this.

        What are your thoughts? From a security perspective, proper patching management, FIM, logging etc, but from a PCI perspective, there are actually no requirements?

      • February 11, 2017 at 9:58 AM

        Any third party that has access to the merchant’s cardholder data environment (CDE) is in scope for PCI compliance. So your customer should be assessing their third parties as part of their own assessment if those third parties have not done their own assessments.

  3. 7 Javi
    January 24, 2017 at 9:32 AM

    Hi,
    I heard that for non-profit organizations, trustees or members of the audit committee can directly be held liable for the non-compliance of the organization. Is this true, and if so can you direct me to where I can find the information? I tried google searches, but it does nothing turn up. I thought I check with you before I close this question.

    • January 25, 2017 at 5:55 AM

      It would depend on the laws in which the non-profit is incorporated. That said, in most states, officers of any corporation can be held accountable for mismanagement. You need to consult with your legal counsel for advice on this matter.

    • 9 maxmgc
      February 14, 2017 at 6:25 AM

      Hi,
      Nick raised an interesting topic and I’d like to add to it and probe a couple of principles: the iframe approach allows the merchant to use SAQ A and takes the merchant’s web server out of scope. And when you look at the SAQ A questions there aren’t any requirements that deal with web development (in contrast to A-EP). And regarding 12.8.5, no requirements would be managed by the web developer but I feel that 12.8.2 would be relevant as the web developer could impact the security of cardholder data. Do you agree?

      If this was an on-site assessment of the merchant then would you use SAQ A as a guide to the ROC questions that would be applicable? That would mean that the (non-compliant) web developer’s processes would not be in scope for assessment. With the merchant’s web server out of scope the web developer does not have access to the CDE.

      Thinking again of the SAQ A vs A-EP debate, and compliance vs security, I expect that some merchants and their QSAs might want to go the extra step and use SAQ A-EP as a guide to the ROC questions that would be applicable, even though the iframe approach allows them to “do less”. If this was the approach, how would you handle push back from a web developer who expected their processes to be out of scope?

      Thanks

      • February 14, 2017 at 4:31 PM

        I agree with your assessment, but the Council and the card brands feel that it is an acceptable risk.

        We recommend that even in the iFrame and redirect scenarios that merchants at least monitor the object that invokes the iFrame/redirect for any changes and that any unapproved/unexpected changes stop their eCommerce until they determine it is safe. Full on compliance with all of A-EP is nice, but not required in all cases.

  4. 11 Scott
    January 24, 2017 at 7:47 AM

    I’ve been searching for an answer to this question. According to PCI DSS Requirement 10.5.3, it asks that you send logs to a centralized secure Internal Log server. Would we need to enable multi-factor auth into the internal Log server for audit reviews if the Log server is secured and segregated? Especially if we have firewalls only allowing pushes into the log server but no traffic is allow outside the Log server back the other way. Basically locking it down so you can get into any part of CDE from that Log server.

    Thanks for any help or Guidance on this

    • January 25, 2017 at 5:58 AM

      If the log server has access into and from the CDE, I would prefer it have MFA to access it. But in order to accurately answer such a question, I would have to conduct a review of network diagrams, firewall rules and other documentation before I could give you a definitive answer.

      • 13 Scott
        January 25, 2017 at 7:30 AM

        Thanks for your reply. if this helps the CDE pushes logs out to the Centralized Log Server (CLS). The CLS cannot access the CDE through FW rules, it is one way only traffic.

        Thanks again

      • January 28, 2017 at 8:51 AM

        Under the Council’s latest discussions on scope, your CLS would only have to be securely hardened to protect it from attacks where administrator credentials could be stolen as that would be the risk presented to that device.

  5. 15 Kevin
    January 23, 2017 at 11:28 AM

    Hello PCI Guru,

    I appreciate this website as an excellent resource for PCI news and answers. My question today is related to PCI and mobile applications. Is there a way to configure a mobile app to be able to accept credit card data for submission to a tokenization service provider while keeping the mobile app eligible for a SAQ A without having to use an iFrame?

    Thank you in advance for sharing your knowledge and expertise,
    Kevin

    • January 25, 2017 at 5:59 AM

      Not that I am aware. Only an iFrame keeps the Web site as SAQ A assessible.

  6. January 19, 2017 at 12:05 PM

    Hi PCIGuru,
    Can I use and process Virtual Credit Card in a non PCI environement ?

    • January 19, 2017 at 3:26 PM

      No.

  7. January 19, 2017 at 10:36 AM

    I have just come across the horrible Chrome autofill functionality. I was observing operators in our call centre taking orders and cards were being suggested for autofill. Panick!!!! well maybe not literally but needless to say the only solution was to stop all users using Chrome when working with our internal web application that processes orders. and to erase all cache and browser histories and to use a secure erasure tool to make sure it was all gone. I dare say we could set the advanced autofill settings to stop Chrome storing card details or we could try fooling Chrome by naming the card field to something Chrome wouldn’t recognise as a field for auto filling. Are there currently any solutions you know of for continuing to use chrome or is it a case of stop using it until Google sees fit to rectify the situation?

    • January 25, 2017 at 6:04 AM

      Chrome is insidious for more than just auto-fill. Most call centers do not use Chrome because it collects and sends usage and metadata information back to Google. As a result, if you are going to use a browser other than IE, use Firefox or Opera.

  8. 21 Tage Rasmussen
    January 7, 2017 at 7:49 AM

    Thanks for a very interesting and informative blog.

    I have a question regarding scoping and PCL compliance requirements for a specific scenario that I would like your view on as I do not think it is quite clear what the requirements are.

    Scenario :

    A Level 2-4 Merchant has a E-commerce solution using either a URL redirect or iFrame for the payment page to a PCI compliant PSP. The solution is hosted 100 % at a MSP.

    The MSP handles less than 300.000 transactions and is therefore a Level 2 service provider.

    In this scenario the PSP of course need to be full PCI compliant as they handle the CDE and the Merchant need to comply with SAQ-A.

    But what about the MSP that hosts the e-commerce solution in this scenario ?

    In PCI terms the MSP is a servcice provider and therefore need to adhere to “SAQ-D for service providers” but what is the PCI scope and are most controls not considered N/A as this environment does not have access to the CDE environment at the PSP ?

    Using the PCI scoping toolkit one could argue that the webserver hosting the redirect URL or iFrame to the payment page at the PSP is a category 2b system, but then again all internet connected systems has access to this payment page.

    The risk in this scenario is primarilly that the web server is compromized and the payment redirect URL/Iframe modified. But does this mean that all components of the e-commerce solution and the system used to mangage this are in scope for PCI DSS ?

    • February 18, 2017 at 3:45 PM

      Your customer in this scenario needs to comply with the requirements in SAQ A. I would argue that puts your organization as the MSP out of scope as you do not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD). However, I could see a bank arguing that you should also comply with the requirements in SAQ A. So you would then have an SAQ D that is full of a lot of Not Applicable responses.

      That said, if you know you have one customer that needs PCI compliance are they really the only one?

  9. 23 Marc Jones
    December 21, 2016 at 2:06 PM

    Can you recommend a free iptables audit tool?

    • December 22, 2016 at 8:27 AM

      I am not aware of any open source iptables audit tools.

  10. 25 Bruce LeBel
    December 21, 2016 at 1:17 PM

    I am posting a new question: Does PCI Scope allow a single device to change its state between Category 1 and 2 (reference PCI Scoping Toolkit) when the network it is connected to dynamically changes? E.g. A client machine uses an internal control to invoke the tokenization process at the proper time. This function first switches the web server connection from the routine business application server to a separate (by definition in-scope) firewalled and secure Payment Card Comm Server (“PCCS”), which is a Category 1 device. When the client is connected to the PCCS a hosted page from the CDE is used for tokenization of a new card. Following tokenization there are no other interactions between the client and the CDE. The client automatically disconnects from the PCCS and reconnects to the routine business application web server. It is never logged in at the same time to both the PCCS and the routine business application web server. If these were two different client machines with continuous connections to the respective web servers then one would be Category 1 (connected to the PCCS) and the other (connected to the routine business application server) would be Category 2 (possibly Category 3, out of scope). Given that this client machine is a single device that connects discretely between the two different web servers, does PCI scope allow this device to change its state (i.e. downgrade its Category) when it is connected uniquely to the routine business application web server vs the PCCS web server? (Note: We’re also seeking a QSA and I’m appreciative of your blog and site. How do I contact you?) Thanks for your help!

    • December 21, 2016 at 1:28 PM

      If a device ever processes, stores or transmits sensitive authentication data (SAD) and/or cardholder data (CHD) it is a Category 1 device regardless of other circumstances.

      If you think about it, how would you achieve Category 1 compliance and then back it off and then put it back into place dynamically?

  11. 27 James Glaves
    December 13, 2016 at 10:33 AM

    Hi PCI Guru, and everyone. Is anyone aware of any official guidance in regards to third-party cleaning/facilities staff accessing a physical cardholder area (such as a call centre). How should these be treated – as visitors, signing in, wearing an ID card and “escorted” throughout? Or should they be considered as contractors needing background screening, completion of security awareness training, etc? It’s a bit of a grey area for me – they don’t really fit into either category.

    As others have said – this is a fantastic resource. Thanks for putting in so much time to sharing your experiences and knowledge.

    James Glaves

    • December 13, 2016 at 12:58 PM

      I have some clients that provide supervision of such personnel when they are working. I have other clients that make sure such people have been vetted and background checked by their provider prior to being allowed into facilities. It all depends on the risk of coming across SAD/CHD during their work. In a call center, I would argue that since nothing is written down, the only risk would be any forms from mail orders, but those should be in locked shred bins at the end of the day. It is up to your organization to determine the best approach to ensure such contractors are not putting SAD/CHD at risk.

  12. 29 Bruce
    December 7, 2016 at 6:21 PM

    Thank you for your informative blog and for sharing your insights and opinions on this complex topic.

    My two questions:
    If a business’s website shopping cart opens a payment page that is a “hosted page” from their authorization provider, e.g. Chase Paymentech, for entry of the sensitive cardholder data, is the business’s web server still “in scope”, requiring a PCI DSS Audit even though there is never any sensitive cardholder data stored on, transmitted through or otherwise touching that web server?

    if the answer to the above is No, then if the same web server of that business performs the (tokenized) settlement transaction with their authorization provider (which is the cardholder data environment), does that fact of establishing the secure connection with the authorization provider for the settlement transaction place the web server “in scope”, requiring a PCI DSS Audit?

    Thank you for your opinion and insights on this “scope” question

    • December 8, 2016 at 6:40 AM

      If your Website uses a redirect or an iFrame (I’m assuming you are using a redirect), then your Web site is not required to be ASV scanned but it still is part of the transaction processing process and needs to be assessed against SAQ A’s requirements. See this post on SAQ A versus SAQ A-EP – https://pciguru.wordpress.com/2015/01/07/saq-a-and-saq-a-ep-clarification/

      Your second comment is somewhat problematic in that the server is both a shopping cart AND it does settlement. That may violate requirement 2.2.1 regarding a server providing more than one primary function depending on how the application is implemented. There is no CHD being processed as it is tokenized so that process would not be in scope. That said though, I would be concerned about security of the other information that could be involved and stored on or connected to that server.

  13. 31 DB
    December 1, 2016 at 3:35 PM

    Hi, Thank you for your blog – it is an awesome resource.

    So I have difficulty getting a clear answer to this because the requirements themselves seem to overlap and contradict themselves.

    I’ve heard two things that I would like a “definitive” answer on:

    1. If a merchant has a scan that they failed in the quarter and are about to remediate in the next quarter there seems to be a gray area there. i.e. they can use a solid business justification coupled with a strong vuln management process and change management process showing they are compliant “in spirit” and then pass the scan there.

    My initial thought was that this was wrong and that you absolutely need to have four passing scans within a year or else you were non compliant and thus this would put you immediately into arbitration with the acquirers/card brands etc

    Then I talked to another QSA who said that
    2. No, in fact you need all of what you said, but since 3.2 you only need to show you did 4 scans 90 days apart and have at least one passing scan during the year *and* have all the other stuff in place – solid vuln management process, review meetings, tickets etc etc

    What is the *actual* truth if a merchant is unable to get a scan passed within a quarter?

    • December 2, 2016 at 6:52 AM

      What? You MUST be able to produce four passing quarterly scans. However, it is how you get there that matters.

      First, this is why most organizations scan monthly rather than quarterly. They do their own scanning both externally and internally. That way they are able to stay on top of things and not have a huge surprise at the quarter. This is particularly important in Windows environments where 95%+ of all vulnerabilities patched carry a CVSS score of 4.0+ (i.e., they fail your scan).

      Even with that approach, there are situations where you will not always be able to patch due to compatibility issues or vendor issues. ON the vendor side, this is particularly true with solutions such as IBM’s Websphere and Oracle’s eCommerce solutions. IN both those instances, IBM and Oracle not only provide updates to their own application suite, but also the underlying operating systems. As a result, it is possible that OS patches are not included due to compatibility issues or timing of the release. The approach you need to take in both of these situations is to mitigate any remaining vulnerabilities while you wait for a patch that will work with the application.

      It is that mitigation effort that confuses a lot of QSAs as well as clients. But this is an essential part of any vulnerability management program. You are acknowledging the issue and developing ways to mitigate it and not just sweeping it under the rug.

      • 33 Gina Rogers
        January 27, 2017 at 10:08 AM

        I’m the ISA for my company, and as I’m sure you’ve experienced before, my IT team wants to do absolutely the minimum necessary for PCI. I’m currently receiving push-back on my advice that we need four passing quarterly scans that occurred AFTER our prior PCI submission date. We submitted our SAQ for the prior period on June 23, 2016. My team would like to use the last passing scan from that submission period (scan date of June 22, 2016) to count toward the current period. I am almost certain this is not allowed but I wanted to confirm this. Is there any way the fourth scan for the prior period can be used as the first scan for the current period using a compensating control?

        Thank you in advance for your input.

      • January 28, 2017 at 8:37 AM

        I would agree with you, but sometimes timing does not fall right when an assessment is being conducted. Therefore, sometimes we end up with the Q4 scan from the last assessment as the Q1 scan in the current assessment because of timing. I try to avoid it, but sometimes it cannot be avoided.

  14. 35 Alan Swan
    December 1, 2016 at 9:31 AM

    I have a question about an internal vulnerability scans. I have an issue with a high level vulnerability detection result. This is caused by an expired “SSL Certification Result”. This is a certificate connected to the Dell OpenManage Server Administration set-up/update. The update from 8.3 to 8.4 seems to have installed with an expired certificate. Anyway, my question is, as this is simply an internal scan and the certificate, although expired, isn’t customer facing. Would it really require the installation of a new certificate until I resolve the issues with the OpenManage or roll it back to 8.3? I understand the scan is simply looking at the certificate as it has expired.

    • December 2, 2016 at 6:59 AM

      Mitigate the risk and move on. You will likely have to have a compensating control worksheet (CCW) if this is a scan result that you will not remediate before your PCI assessment is due.

  15. 37 Erik
    December 1, 2016 at 6:38 AM

    Not Tested (revisited)

    Me an my fellow QSAs are debating how to deal with the AoC for assessments where some requirements are Not Tested.

    For example, PCI SCC informs us in an FAQ that we can base the scope of an assessment, and create a RoC, based SAQ A for redirected e-commerce solutions. In such cases, we are instructed to use Not Tested for requirements not included in SAQ A.

    Now, in the AoC (Part 3) we have to check either “Compliant” (full compliance with PCI DSS) or “Non-Compliant”.

    Somewhat contradictory, PCI SSC informs us in another FAQ that if there are Not Tested responses we are not allowed to state that the entity is fully compliant with all requirements. So, does this mean that we have to check the “Non-Compliant” checkbox in the AoC? In that case, the whole Not Tested concept is completely useless!

    What’s your opinion of this?

    • December 1, 2016 at 7:34 AM

      Your not the only one questioning the Council on this as they just discussed this in their latest Assessor Newsletter email. However, based on what they are saying in the December 2016 newsletter, organizations are Non-Compliant. I don’t agree with that but that is how the Council wants things answered.

      • 39 Erik
        December 1, 2016 at 8:00 AM

        I haven’t seen the latest newsletter (it’s not published on the QSA portal yet…).

        We’ve used Not Tested for some Merchant assessments and checked the “Compliant” checkbox in the AoC. The acquirers we’ve dealt with have accepted this approach without objections. It’s a great way to reduce unnecessary complexity for an assessment and the report, making PCI DSS validation easier and cheaper for the assessed entities.

        If you have to check Non-Compliant, then Not Tested is a useless concept that cannot be used in any assessment. No Merchant or Service Provider would ever accept that we present them with a Non-Compliant AoC even though they’ve implemented all relevant requirements.

      • December 2, 2016 at 6:59 AM

        No kidding it is a useless concept. The Council really needs to fix this situation.

  16. 41 LJ_180
    November 30, 2016 at 5:24 AM

    Even having read a lot of literature, I am still not 100% which SAQ I should be using and/or I should be using different SAQ’s for different payment channels.

    My organisation doesn’t sell services as such, but does have methods for customers to pay fees. We have standalone terminals where customers can come in and pay. We allow for customer not present payments over the phone, using the same standalone terminals. Finally, we have a page on our website that redirects to a payment service provider.

    I am thinking that we need to complete SAQ A-EP for the website payments and, also, SAQ B for the other channels. Is this correct?

    Thanks in advance.

    • December 1, 2016 at 7:38 AM

      First, only your acquiring bank can give you the final answer to your SAQ question. So everyone else, including the PCI Guru, will only be providing their opinion on the matter.

      If the point or interaction (POI), aka card terminals, are dial up, then you would follow SAQ B. Otherwise, if the POI are on your network, then you would use SAQ B-IP.

      If your Web site truly is a redirect, then you would follow SAQ A.

  17. 43 Shay
    November 28, 2016 at 7:05 AM

    Hi PCI Guru

    Firstly, your blog is a fantastic resource. Thanks for sharing your expertise with everyone.

    I have a question about transaction counts and Service Provider levels.

    Bit of background. We have a cloud-based SaaS solution, which we host on Amazon Web Services and provide web development or other technical services for our customers, all whom use IFRAMEs for accepting payments. Each customer uses their own Payment Processor Service (e.g. SagePay) with their own merchant account / identifiers. We’ve designed our solution so cardholder data or sensitive authentication data does not touch our web servers.

    Individually, each customer is classified as a Level 3/4 Merchant and annually attest PCI compliance using an SAQ A. As a Service Provider, we attest PCI compliance via self-assessment, and provide our customers with a compliance package to demonstrate this.

    However, now our customer transaction counts, combined, is over 300k; my question is do we *need* to perform an an onsite assessment in order to attest compliance for our solution going forward? Or can we continue to perform our own assessments internally? Are these transaction counts on our customers / payment service provider in this scenario, as long as our solution does not ‘store, process, and/or transmit cardholder data’?

    Thanks in advance.

    Shay

    • November 29, 2016 at 6:21 AM

      Thank you for your nice comments about my blog. I appreciate it.

      First, I am assuming that your organizations ensures that ALL of your customers are using iFrame payment solutions because your organization manages/develops every site. As a result, your organization is also responsible for meeting the requirements listed in SAQ A although, as a service provider, your organization needs to report its PCI compliance on the service provider SAQ D.

      Technically, your Web sites do NOT conduct the transactions because of the aforementioned use of iFrames. Therefore none of the transactions conducted are processed through any of your servers which is why I am sure you took the iFrame approach in the first place. As a result, your organization’s transaction count is technically zero and, as long as the rules stay the same, will always be zero. Therefore, you can continue to conduct your own self-assessment as long as your customers are willing to allow it.

      The only reason I can see that you might want to consider conducting a ROC would be to get your organization listed on the Visa and/or MasterCard Global Registry of Service Providers. Your sales/marketing folks would likely drive that move in an effort to boost merchants using your hosting services.

      • 45 Shay
        December 8, 2016 at 5:39 AM

        Thanks so much for your clear and considered response. Greatly appreciated!

  18. November 18, 2016 at 10:39 AM

    Hello,

    I have a use case I was hoping to get some advice on. We have a call center that takes card information, but because of our use of P2PE devices and tokenization, we have been able to keep CHD off of our endpoints.

    However, due to how orders are processed, gifts, etc… there are scenarios where 5 orders or more of different types may be submitted. Those orders can be within the same system, or several different systems. Basically, we end up asking customers 5 different times for their credit card information.

    The business is wanting our reps to write down the card number and shred after the call ends. I am looking for options to meet that need without writing down numbers.

    • November 20, 2016 at 4:09 PM

      Sorry to be a downer, but how about fixing your messed up order entry system? Seriously!

      Writing PANs down is a stupid idea and goes against not only the PCI DSS but most call center policies and procedures.

  19. November 17, 2016 at 11:19 AM

    Hi, following the reply number 21. I’m very interested on how PCI-DSS is affecting an eCommerce solution running in Kiosk, but where cardholder data is not keyed but readed using basic emv level 1 devices (not PCI-PTS, not PINPAD).
    For clarification; a mag reader in the kiosk gets the cardholder data from the card and sent it to a webservice of an eCommerce PCI gateway.

    many thanks!

    • November 20, 2016 at 4:21 PM

      It depends on whether or not the kiosk reader is using a P2PE or E2EE solution that takes the PC in the kiosk out of scope.

      • November 21, 2016 at 6:30 AM

        Hi, none, the kiosk reader is not using a P2PE or E2EE solution. It’s only an EMV level 2 reader. The point is that the transactions are processed as eCommerce (CNP) not as a card present ones.

      • November 21, 2016 at 7:38 AM

        What? Why bother to have a point of interaction (POI) aka card reader if you are doing card not present? Convenient for the customer because they do not have to key their information. But silly as a merchant because you are not getting the benefit of doing card present transactions.

        That said, your kiosk is in scope because it is processing and transmitting cardholder data (CHD). Since you did not implement P2PE or E2EE with the reader, then the kiosk is likely handling the CHD in some way.

    • 52 John
      January 24, 2017 at 1:32 PM

      So if you use a P2PE IP terminal then the switch that it connects to is not in scope? No firewall or acl is required?

      • January 25, 2017 at 5:54 AM

        You need to have a firewall to protect the P2PE terminal, but the data stream generated by that terminal is encrypted and only the endpoint it communicates with can decrypt that stream, so all devices inbetween the P2PE device and the decrypting endpoint are out of scope.

      • 54 John
        January 25, 2017 at 11:45 AM

        Ok. If you need a firewall, how come the P2PE SAQ doesn’t have a firewall section?

      • January 28, 2017 at 8:49 AM

        Good question. We are having a similar argument over SAQ A not requiring vulnerability scanning but yet banks required it when a redirect or iFrame is used on a merchant’s Web site.

        That said, you are still required to protect the point of interaction (POI) from the Internet sot hat hackers do not have unlimited access to it to attempt hacking it.

  20. 56 wafiy
    November 15, 2016 at 4:43 AM

    Hi PCI guru.

    regarding PCI req 2.2.1 : enable one primary function per server. I do know that the “Primary function per server is based on the security level” so my question if i have a server that act ac AV, patch and jump server. will it violates the requirement as it does not having storage or processing of card data and the connection if through and specific port only.

    • November 16, 2016 at 5:11 AM

      It’s not the anti-virus (AV) and patching functions that would make me nervous. It is the fact that it is also a “jump box” or out of band (OOB) box providing the gateway into your cardholder data environment (CDE). The reason is that a jump box typically is going to have a LOT of human use ports open in to/out of the CDE. That makes that device a huge attack point and you want to have only the jump box function on that device to truly minimize the risk. As a result, I would recommend setting up a separate jump box.

  21. 58 Dave
    November 8, 2016 at 3:48 PM

    In relation to the the use of SSL/early TLS, I have a question. Does the discontinuation of this type of communication by June 2018 apply to systems that only internally communication on a private network (i.e. not across public networks / Internet)? We have a few internal VMware (version 5.5) systems that communicate via TLS 1.1. In order to enforce only TLS 1.2, we’d have to upgrade to VM version 6.0 and that could be problematic.

    • November 16, 2016 at 5:19 AM

      Welcome to the club. I have a LOT of clients in the same boat.

      Yes. ALL SSL and early TLS are verboten – external and internal use. That said, TLS 1.1 can be configured securely according to NIST SP800-52. However, I am not sure if VMware ESX(i) would support that configuration.

      • 60 Jonatan
        November 16, 2016 at 5:32 AM

        Hi there! I’d like to raise my hand here and as a 2nd question. Since PCI does not require the usage of encrypted channels for CHD transimissions within non public networks, the usage of SSL or early TLS is not mandatory and even though its vulnerable it still better than plain text transmissions. I know an internal vuln scan wound find this but it would aso find a plain text transmissions… so my question is how would you consider this? It’s like “I’m not required to place a door here by I’ve still placed it anyway, it’s unlocked, yes, but whether its there and unlocked and it is not even there, I’m still in compliance to what the regulations says which is u don’t need to put a door”

        I just came up with this question while reading your reply and I’d like to get your opinnion since I consider you have lot of experiencia on several kinds of markets and infrastructure.

        At last, I was wondering for a while now, what’s your opinnion about this SSL and Early TLS requirements applicability to scenarios like AV web administration, Nagios web administration. They are nor used for transmission of CHD but they provide secure access to systems that actually provides security functions to CHDE. Even though the migration of SSL or early tLS within those platforms may require the migration of the tool itself, I tend to belive that SSL and early TLS within web administration interfaces is as critical as for CHD transfer cause if someone compromised such communications can lower the security level of the CHDE by modifying the systems that’s actually provigin security functions.

        Thanks a lot again in advance! I hope you have a nice day!

      • November 16, 2016 at 6:26 AM

        Ah, nice try. SSL and early TLS cannot be used either internally or externally, period. I understand your argument, but if you think about the SSL exploit POODLE, it is actually much, much easier to pull off internally than it is externally. That is why I would be more afraid of inside risks than outside risks.

        Your second example appears to be the old “connected to, connected to” argument and where do you draw the line. The Council has told organizations to draw that line based on your risk assessment. The bottom line is that if those systems/devices that are not directly connected are believed to still have influence on compromising the cardholder data environment (CDE), then they should be in-scope for assessment.

      • 62 Jonatan
        November 16, 2016 at 6:40 AM

        This is why I ask ur opinnion 🙂
        Yep, I’m aware about the explotability of POODLE and how easy would it be to exploit it from the internal network. I’m just playing the devil here by saying something that a customer might say. I’m thinking here that if I tell him to replace SSL or eTLS to TLS 1.2 they might end up telling me something like “ok, i will just remove the SSL/eTLS channel and work in plain text since this is an internal network and PCI does not require to encrypt transmission within the internal network”.
        I just feel like I’m lowering the security level if I put them in that kind of situation. I feel like when something is not mandatory required, I rather see something weak as an extra tweak on security than seeing nothing.
        I know PCI has a lot of situations like this. I’m not trying to challenge PCI regarding internal data transmissions but i do think this kind of situation should be taking into consideration, right? Thanks a lot for your comments! As i sais, they are really valuable due to ur knowledge and experience!

      • November 20, 2016 at 4:24 PM

        They would be well within their rights to just drop SSL/TLS and go back to clear text since it is an internal network. It is a tough thing to push on internal networks. If you are asking the question, then you know your client well and that they are not interested in security. They just want to punch that PCI compliant box and move on. If they really are that silly, I would let them do it and move on. I would also find a new security conscience client to replace them and then cut them loose.

      • 64 Jonatan
        November 21, 2016 at 6:11 AM

        Thanks a lot again for your feedback!!! As I said, it’s always great to get the opinion of someone with your knowledge and experience!

        Have a nice week!

  22. 65 Rich
    November 3, 2016 at 9:21 AM

    Would control 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 be applied to Wireless access points? Some AP’s provide WiFi and do rouge asset detection. Would this make sense?

    • November 4, 2016 at 3:29 PM

      Requirement 2.2.1 is for servers only, i.e., running Linux, Windows, UNIX, etc. It does not apply to appliances such as firewalls with IDS or layer 3 switches, etc. or even your wireless access points that are also acting as wireless sensors for rogue devices.

  23. October 31, 2016 at 2:30 AM

    Hi PCI Guru,

    Thank you so much for your knowledge and help!

    My company has 2 sites. Each site has a virtual desktop (a portal to be used for sales) issued by the vendor for card-present situations. Also at every site there’s a PCI-compliant POS which uses cellular connection (wholly outsourced). The credit card information does not get captured at all. Credit caress will only be inserted for using the chip. Which SAQ should we use and which overarching controls you think would apply to us? Thank you

    • November 8, 2016 at 3:36 PM

      Good question, but I have no idea because you have not supplied enough information for me to give a decent answer.

      That said, you cannot rely on my opinion to determine what SAQ you should use. What SAQ to use can only be determined by your acquiring bank. If the bank cannot give you an answer, then I suggest you find a new acquiring bank.

      That said, the first thing the bank will want to know is how many transactions you process both card present and card not present by card brand. Once you have that, then you can determine your merchant level. Next you need to determine if the card present transactions are encrypted at the swipe/dip or by the POS. How that happens will determine what SAQ you will use to report your compliance. Again, the only official decision on what SAQ to use can be given by your acquiring bank. Anyone else is just giving you their opinion.

  24. October 26, 2016 at 7:14 AM

    This miscellaneous questions page is a great resource but it is VERY big and takes quite a while to load (even with good bandwidth). Since the page has so much content, a “Find on this page” search is pretty much always needed but the lengthy download time means waiting what seems forever 🙂 to get started.

    Would you be able to break the page up, say by year, so the load would be faster?

    Thanks.

    • October 28, 2016 at 3:19 PM

      You are not the first one to complain about the Miscellaneous Questions page. I just need to set aside some time to break it up. Thanks.

  25. 71 Patrick
    October 20, 2016 at 1:38 AM

    Hi, I’ve got a question regarding PCI compliance and MS Active Directory. I’ve been asked to look at merging Active Directories between 2 companies. 1 of these companies is PCI compliant and one not. To start things off I’d like to create a domain trusts between the 2 companies, what’s the minimum I need to do to setup this trust without impacting the PCI compliance of the company?

    Thanks

    • October 23, 2016 at 7:11 AM

      Unless you are granting access to people from one domain to the other and they will have access to cardholder data (CHD) or the cardholder data environment (CDE), then I would not worry about things just yet. Once you start opening up the PCI compliant company’s network and CDE to the other, then you will start to have an impact.

      • 73 Patrick
        November 1, 2016 at 2:48 AM

        Brilliant, this was the answer I was hoping for. 🙂

  26. 74 ITProSec
    October 18, 2016 at 10:17 AM

    Are there any restrictions in the PCI DSS regarding storing, processing and or transmitting card data internationally (say, backups going offshore, or databases being housed offshore), as well as human operations (overseas customer service reps with access to CC data or taking verbal orders via CC)? I’ve search the PCI DSS document and online and thus far have come up short.

    • October 18, 2016 at 12:15 PM

      Other than protecting the data, the PCI DSS does not restrict the data in this regard. However, there could be legal or regulatory requirements that may get in the way.

  27. 76 Pete
    October 6, 2016 at 4:58 AM

    Hi – The company I work for has a retail chain of a few hundred stores. However they cannot stock every item we sell. Apart from the traditional chip and pin POS solution (we are in Europe) at our tills. We are also thinking on introducing a chrome book like device connected to a segmented (by firewall) public wifi we provide for our customers. This device would allow a customer to only browse our website and carry out a Card not present transaction via our SAQ A ecommerce compliant website (iFrame/Tokenised). For clarity the chrome book like device is standalone and only connected into the public wifi. In many ways it is a cybercafe with only one site to access.

    How does PCI apply to this scenario and indeed are there any card scheme rules that could also apply around CNP transactions in retail stores

    • October 6, 2016 at 3:10 PM

      PCI really does not apply in this situation. But common sense security measures do apply because, in the event of a breach, I would not want to be around your organization as an IT person responsible for these devices.

      I have a lot of organizations that have done just what you are considering. A very few have retained them, others bailed on them when it became obvious to management that they were not worth the effort required to keep them secure and available. Remember, it this age of smartphones, almost everyone has a computer in their pocket, so the need to provide a computer is not as necessary as it once was. Most of my clients have determined it is cheaper and better to develop a more usable mobile application or Web site to accomplish the same goal.

      As a point of clarification, I am assuming that this computer is on your public customer Wi-Fi (you said it was segmented, but I think you meant from your other networks). I would expect transactions will be conducted using HTTPS (required by PCI) which would also be considered segmentation.

      Your first consideration you need to acknowledge is that this device is your organization’s responsibility. As such, your organization is responsible for it’s security (physical and logical). After all, it will be your organization that is held responsible if it is found that any of these devices were responsible for a data breach. Your organization will need to ensure it is patched current, has anti-virus, has file integrity monitoring, log collection/monitoring and other controls to ensure that it remains logically secure for your customers’ use. The reason for these controls is that in the event of a compromise, you can take the affected units out of service as soon as possible. You will also want to have these systems under video surveillance to ensure they are not tampered with or stolen. I would also recommend that you put them in some sort of enclosure to ensure that anyone cannot walk up and insert/attach USB or other devices to these systems. Another option is to take a hot glue gun and fill the unused external ports with the glue.

      Some of these issues are relatively minor to accomplish but some like patching and logging can be difficult, particularly when on a public network.

      • 78 Pete
        October 7, 2016 at 3:38 AM

        Thanks. Agree with all the security points and we would use a supplier to provide a physically secure and lock the solution down.

        Just for my clarification even though it is our device in stores, PCI compliance only applies from an E-commerce perspective and does not change the stores separate F2F compliance submission?
        Is there any clarification or guidance notes from the payments council on this? It does seem a grey area?
        Are there any card brand rules that could impact on this?

        Very much appreciate any advice – we have reviewed a variety of implementations in various retail stores

      • October 8, 2016 at 5:31 AM

        There is no guidance in this area because the Council sees these PCs and kiosks as extensions to the PCI DSS not covering consumers’ home PCs and smartphones. All I can point you to is the legal risks presented should such a device become compromised and your customers’ card data are breached as a result of your negligence in maintaining and securing these systems.

  28. 80 Luigi Figueroa
    September 29, 2016 at 11:45 AM

    Is there a way to show companies, certificate-wise, that since there is no credit card data at all if the company is asking for PCI compliance? Reason I am asking is a company wants to do business with us and is asking for PCI compliance when in our environment, there is no credit card data at all.

    Thanks for your help!

    • September 29, 2016 at 5:38 PM

      The way I have dealt with this in the past is to hire an independent third party to conduct an engagement looking for sensitive information such as cardholder data (CHD) or personally identifiable information (PII) and then issue a report discussing the methodology used and that they did not find any such information.

  29. September 29, 2016 at 2:52 AM

    Dear PCI Guru,

    I am currently working on all assessments for our various brands. I have completed 1 SAQ already (SAQ B) for one brand wiht QSA approval. I have a query for a call centre I am looking at SAQ C-VT for. They currently use a PCI compliant payment portal to process all card payments taken over the telephone. They have automatic Pause and resume when entering the card number into the portal so they never record the card number. My question is around Network segmentation and Server hardening(req 1.2-1.4). Is this really applicable if they are entering the cards into the Hosted Payment page which is compliant and they do not enter the card numbers anywhere else? The Card data is also not stored anywhere as it is a token that is used if a refund to the customers card. We have secure firewalls around our network as a whole but this particular call centre is across them all and not segmented off. Is this absolutely required for SAQ C-VT? As it brings the PC’s into scope that the users are entering the card data (even if it is straight into a PCI-DSS accredited 3rd party payment page)

    • September 29, 2016 at 5:43 PM

      Remember, your call center operators are entering the cardholder data (CHD) through their PCs which means a keyboard logger or memory scraper could access that CHD even if using a PCI compliance, secured Web site. Anti-virus only addresses this situation, at best, 40% of the time. So those PCs should have something a bit more to ensure that such malware cannot end up on those systems such as critical file monitoring or white/black listing of applications. Then you want to have their event log or syslog data collected for analysis and alerting.

  30. September 27, 2016 at 3:18 AM

    Hi, we are just about there. thx for your help.

    We would like to use a virtual terminal which would be an Air-Gapped machine on a mobile internet connection or VLAN’d off on our network to new outbound iP solely for this use. Would this be compliant?

    Thanks,

    Taruna

    • September 29, 2016 at 5:52 PM

      Stop trying to get your organization out of scope because you never, ever will as long as you are considered a merchant by the card brands. The best you can do is to limit yourself to the requirements in SAQ A and it sounds to me like that is impossible for you to accomplish. Get over it and please move on.

      • October 3, 2016 at 5:09 AM

        Hi,

        Not trying to avoid compliance, all our other systems have been changed to comply. We need one PC to access a virtual terminal as we need to process certain payments in this manner. We are thinking of having a dedicated PC with its own internet connection and security to limit access and vulnerabilities. Any help appreciated.

        Taruna

      • October 3, 2016 at 7:06 AM

        If you feel the need to do that, that is up to you and your company. I would just make sure that all your PCs are properly security hardened, have anti-virus, and are always patched current. Most organizations already do this. But if your organization is not one of those that maintains their PCs religiously, then your approach might be the best way to go. The one additional control I would suggest is to install something like Bit9, Tripwire or similar to make sure that no new software can be installed on the PCs used to do data entry.

        The risk is that a memory scraper or keyboard logger gets installed on your PCs that do the data entry or cardholder data (CHD). As long as you do everything you can to minimize that risk, you should be fine.

  31. September 22, 2016 at 8:13 AM

    I don’t really have a PCI DSS question but last assessment the QSA asked why my client’s (I’m not a QSA but a security consulting) vulnerability management program was solely focused on the CDE. I took that as a nudge to expand the program. The CISO agreed but she left this summer for a position elsewhere ( doubled here salary). IT pushed back but I finally convinced interim management (yes the organisation is still searching for a CISO) to expand the program. The security analyst added 250 additional servers, ran the vulnerability scan and found all the servers with high to critical vulnerabilities. 20% have critical vulnerabilities that are 6 months old. These are scope category level 3 systems but … I so want them fixed.

    Sigh.

    • September 26, 2016 at 10:14 AM

      If the cardholder data environment (CDE) you describe included all of the “connected to” systems, then your client was following the PCI DSS to the letter of the law. However, where this goes awry is if those “connected to” systems are also on the same network segment or can be accessed by other network segments. This is typically true of Active Directory, DNS, DHCP, NTP and other common services. As a result, if an organization does not have a complete vulnerability management process for everything on their networks, those “connected to” systems can become a conduit to compromising the CDE from systems out of scope.

  32. 90 Suresh Kumar
    September 21, 2016 at 10:12 AM

    My client has a Mainframe card data environment. Backups are in unencrypted tapes but the client contends that Dara in the tapes is in non-readable format (i.e. Only read by Mainframe) and does not physically leave the data Centre. Is this on for PCI compliance? Thx

    • September 29, 2016 at 5:57 PM

      Dara? Not familiar with Dara and what that has to do with magnetic tape and readability of those tapes. Dara might be a potential control, but I would have to know a lot more about it. That said though, most mainframe backup utilities do not lend themselves to being security controls.

      PCI does not care if the cardholder data (CHD) never leaves a data center, it is still in scope for compliance. The fact that it is unencrypted just makes compliance all that much more difficult.

  33. 92 MikeAL
    September 19, 2016 at 6:54 PM

    I read a lot about how scope can be reduced by tokenization, P2PE, or PA-DSS, but I have not been able to find any specifics on the exact PCI DSS requirements that can be avoided by any of these methods.

    • September 19, 2016 at 7:06 PM

      Tokenization scope reduction depends on when the tokenization occurs. Tokenization typically occurs at the completion of the transaction, so as long as your process doesn’t store the PAN before the token is created, then tokenization keeps the PAN from being stored. There are some tokenization solutions that create the token at the swipe/dip of the card, so those can take your network and POS solution out of scope just as P2PE/E2EE can as long as the sensitive authentication data (SAD) is not also transmitted.

      P2PE or E2EE can also take your network and POS solution out of scope by encrypting the SAD at the point of interaction (POI) if the solution is managed by your trasnaction gateway or processor. However, P2PE/E2EE does not automatically mean you get tokenization even though a lot of transaction gateways/processors bundle it with P2PE/E2EE. So your application may still be storing the PAN even though you implement P2PE/E2EE.

      PA-DSS dos not reduce scope so much as it proves that the application was independently validated for securely processing, storing and/or transmitting SAD or CHD. A QSA/ISA still has to confirm that any PA-DSS was implemented according to its Implementation Guide (IG). Once that is proven, then the application can be considered secure and you can avoid the requirements in 6.3 and 6.5.

      • 94 MikeAL
        September 21, 2016 at 2:15 PM

        Lets assume an effective tokenization solution in which there is absolutely no CHD or SAD saved anywhere in a merchant’s network or premises. Are there any scenarios under which such a merchant can go from SAQ D, to either SAQ A or SAQ C?

      • September 26, 2016 at 10:15 AM

        Yes, if they meet the criteria of those SAQs.

  34. 96 Brad
    September 19, 2016 at 4:31 PM

    We are looking to implement an ecommerce site that utilizes integration with Zuora’s CORS REST APIs (https://knowledgecenter.zuora.com/DC_Developers/REST_API/A_REST_basics/G_CORS_REST). My question is what SAQ classification would this put my company? The number of annual CC transactions would be less than 20,000. Also as best I can tell unlike direct APIs, this process would send CHD directly back to Zuora not through our website.

    • September 19, 2016 at 7:11 PM

      While I can provide you my opinion on this, this is a question you need to ask your acquiring bank as only they can give you the official answer. That said, based on the vendor’s documentation, I would say you have reason to request using SAQ A as long as eCommerce is you only payment method.

  35. 98 CJ
    September 18, 2016 at 10:44 PM

    We are an organization with 3 small sites (geographically separated) with point to point connections between them. We struggle to figure out the following:

    1. The main site hosts cardholder data. The other two do not. However, the workstations from these two sites connect to the main site as they connect to the server that hosts the cardholder data. My first question is if we need to complete the SAQ for each site or just for the main site? At the end of the day we need all 3 sites to be compliant.

    2. We understand that workstations at those 2 sites are in scope, however, we struggle to understand if we just need to properly harden them, or if we need to go through each PCI requirement. The connection between the workstations and the server that hosts the cardholder data is encrypted.

    3. a. We understand that one of the requirements is a proper risk assessment. Since this is our first time going through the PCI, when do we need to conduct the risk assessment? Is it right after we define our scope and have up to date inventory of all devices or at some other point?

    b.Should we complete the SAQ before or after the risk assessment?

    We are using the PCI Scoping toolkit to help us with our segmentation.

    4. We will be using SAQ v3.2. Do we need to justify and document new requirements that are mandated by v3.2 only that we cannot implement at this time, but would definitely implement by 2018?

    Thank you so much for your help.

    CJ

    • September 30, 2016 at 5:30 AM

      As you have already determined, the answer to your questions lie in your scope.

      To answer your first question, unless the three sites belong to three separate legal entities with different merchant identifiers, you will fill out one SAQ for your entire organization. That said, it might be easier to assess each site separately based on their business processes and then combine the results, but that will depend on your own judgement.

      To your second question, the workstations need to be hardened to prevent being a point of compromise that can then allow the compromise of the cardholder data (CHD) that you store. It’s great that connectivity to the CHD is encrypted, but that does not protect the workstations being used to compromise your server that stores CHD.

      A risk assessment needs to be performed BEFORE you conduct your assessment. The reason is that you need the risk assessment to justify your rationale for the security measures (or lack thereof) you have implemented to protect the CHD you store, why or why not you have network segmentation, justify your server/workstation hardening standards, why you monitor what you monitor, etc. As you conduct your assessment, you will likely adjust your risk assessment as you discover new risks and/or realize that ratings of risks were wrong.

      At this late point in the game, you should use v3.2 of whatever you follow for your assessment. V3.2 goes into effect at the end of October 2016, so unless you think you can finish by then, you’ll need to use v3.2. Any requirements that do not go into effect until some later date are only suggestions. However you need to meet those future dates in order to be judged compliant.

      • 100 Jon
        September 30, 2016 at 5:42 AM

        Hi! I thought OCI 3.1 was gonna be acceptable till the end of September and all assesments completed from October and on should be PCI 3.2. Under October section, It says “at this time all assessments will need to use version 3.2”
        https://blog.pcisecuritystandards.org/preparing-for-pci-dss-key-dates

        Thanks!

      • September 30, 2016 at 5:53 AM

        The official, final version of PCI DSS v3.2 was released as I recall on April 28, 2016 with the retirement of v3.1 announced as 6 months following the release date of v3.2. If I do my math right, that would put v3.1 being retired on October 28, 2016.

  36. 102 Luigi Figueroa
    September 15, 2016 at 4:29 PM

    Hi PCI Guru,
    I have a scenario for you. Company A is asking for PCI Compliance from Company B. The scope is that Company A is just sending orders to Company to ship products for them. No credit card data is being sent or handled to Company B. Is Company B still need to produce an AOC? If so, would a SAQ D for Service Providers suffice even if there is no credit card data is being handled from Company B? Thanks for your help!

    • September 29, 2016 at 5:59 PM

      If Company B never receives or handles cardholder data (CHD) then there is no need for Company B to be or even prove they are PCI compliant.

  37. 104 Sean Giroux
    September 14, 2016 at 9:45 AM

    In regards to Processing Credit Cards over Wifi… Other requirements aside… With the new 802.11ac standard, do our WIPs (Airtight or Aerohive) need to be 802.11ac compatible or can we get by with 802.11n for PCI 3.1 and PCI 3.2 compliance?

    • September 29, 2016 at 6:05 PM

      If you are relying on your wireless intrusion protection (WIP) units to protect your Wi-Fi and that includes 802.11ac, then yes, your WIPs do have to be able to monitor that 802.11ac network. That said, 802.11ac is just faster 802.11a (i.e., it uses the same 5GHz channels as 802.11a), so I would check with your vendor to see if your WIPs already have the capability.

  38. 106 Scott
    September 13, 2016 at 2:03 PM

    I was wondering if anyone is using kerberos for SSO with a 2FA solution into their CDE for PCI DSS compliance. Also what does PCI DSS say about SSO once 2FA has occured through Raduis Server.

    Thanks for any suggestion or comments

    • September 29, 2016 at 6:10 PM

      Kerberos is only an authentication and communications security solution, so it’s marginally better than regular authentication. Add in two factor authentication (2FA) and you have a secure remote access solution as well (or an administrator access solution internally to comply with v3.2). PCI DSS does not specifically or explicitly deal with single sign on (SSO), but the requirements in section 8 would all be applicable to SSO as they would to non-SSO environments.

  39. September 7, 2016 at 2:17 PM

    PCI Guru… We met about 2-3 weeks ago when you came in to consult with us… as I start to move forward I have a couple of questions. 1st, regarding Internal\External Vulnerability Scans, should either be credentialed or not, is it required, Section 6 does not say one way or the other, furthermore how do I scan those systems if they’re separated from the rest of the network? Do I schedule time when those systems are not processing to allow inbound scanning? 2nd Question… regarding AV, if the Internal PCI space should be separate from non-PCI networks, to include the Internet, how do I keep the software updated and current?

    • September 10, 2016 at 6:35 AM

      Credentialed vulnerability scanning is not a requirement. External ASV scans will/should never be credentialed. However, internal vulnerability scanning typically is done credentialed to minimize false positive results. Using credentials allows most scanners to make a better determination on vulnerabilities.

      Logical and physical network segmentation can create issues when trying to vulnerability scan. In some cases you may have to temporarily open up all ports for the scanner to let it through. In other cases you may have to move the scanner to physically connect it to a particular network segment. Some clients have defined special VLANs for their scanners so that they can accomplish scanning. As to scheduling, that is up to your organization to determine. Some organizations do not restrict scanning to a particular time, others have outage concerns and only allow scanning during off or non-prime processing hours.

      Network segmentation is all in the paranoia of the implementer and organization. Some people and organizations can go overboard on segmentation to the detriment of properly managing and monitoring devices. You need to balance risk with properly managing devices. If you configure your network to only allow the AV, SIEM, AD, WSUS and other necessary services and servers to talk within your PCI zone, that is all is required by the PCI DSS. Where a lot of organizations go wrong though is that they do not restrict those services to only those servers that provide those services.

  40. 110 Sandun
    September 7, 2016 at 1:46 AM

    Noted that the Payment Applications listed in pcisecuritystandard.org have operating systems that the application was tested on. For example, “PaymentX version 3.2” application system is PA-DSS certified and tested on Solaris (Tested platform/ operating system). If the Vendor implement the same “PaymentX version 3.2” application on any other platform/ OS other than ‘Solaris’, will the same application (Same application and same version) be still compliant with PA-DSS?

    Note: Vendor may have other versions of the payment application tested and certified on other platforms/ OS. Example: PaymentX version 3.1 is also PA-DSS certified and tested on AIX (platform/ OS) but not on Solaris.

    In a nutshell, do we need to consider Payment Application version and the platform or other dependencies which the application was tested on at the time of PA-DSS certification and should we implement the application with the same ‘dependencies’. If ‘dependencies are changed at the time of implementation, will the implemented application be NON-complaint with PA-DSS?

    • September 7, 2016 at 6:48 AM

      Yes, the PA-DSS validation (it is NOT a certification) is OS specific and version specific. So if the application has been validated on Solaris v10 and Red Hat v5.5, but not any other UNIX variants, then only the Solaris v10 and Red Hat v5.5 OSes have been validated for that application.

  41. 112 Ray
    September 2, 2016 at 11:21 AM

    We give away free samples on our site. How can we prevent the PCI scan from generating a ton a free sample requests so that we are not allowing them. Our initial idea was to make note of the PCI scan IP address ranges and not let those sample requests go all the way through the pipeline. Not an ideal situation since that address range changes.

    • September 6, 2016 at 6:08 AM

      How would a PCI vulnerability scan generate sample requests? I think what you are arguing is that a PCI application vulnerability scan could generate sample requests. However, I would argue that such a scan would also not generate such a request unless you are telling the application scanner to fill out the sample request form. Even then, it would only generate a request to one address, not thousands.

  42. 114 Dayne
    August 25, 2016 at 2:10 PM

    I have a database for my point of sale system that currently stores encrypted credit card data (Not full PAN, and moving to tokens). We are in the process of putting an internal firewall up to segment of the back end of the POS system through an ACL. If the POS terminals are not in this segment does that mean that my whole network still needs to be PCI compliant. I know the terminals themselves are subjected to PCI compliance but is the back office computer that is on the same network subject to PCI compliance because it is on the same network? Just having a hard time figuring out my scope? Second if I am a level 2 merchant and doing a SAQ D do I still need a qsa to sign off on my network segmentation to reduce my scope?

    • August 30, 2016 at 7:39 AM

      First, the easy question. If you are a Level 2 merchant and you accept MasterCard credit cards, you are required to do either: (1) a self assessment questionnaire (SAQ) conducted by a PCI SSC certified Internal Security Assessor (ISA), OR (2) a Report On Compliance (ROC) conducted by a PCI SSC certified Qualified Security Assessor (QSA). See Note 4 on this Web page at MasterCard’s Web site for more information. https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html

      As to minimizing scope through the use of network segmentation. If the POS comes into contact with full PAN, then it is also part of your scope and needs to be logically or physically segmented from the rest of your network. It is not just the storage of PAN (encrypted or clear text), it is also the act of processing and/or transmitting sensitive authentication data (SAD) or cardholder data (CHD) that is also in scope.

      BTW I’m not sure what you meant by having encrypted card data but not full PAN. I’m assuming you meant that the POS solution encrypts the full PAN but also stores a truncated version (most likely the last four digits).

  43. 116 AL
    August 25, 2016 at 12:23 PM

    Question about SAQC applicability. We have a business using an SaaS solution. This SaaS offers a hosted payment page to process credit card transactions thru. Transactions can be key entered byt he business by pulling up the SaaS solution online. Thre is not any software installed the business computers.

    The SaaS has validated PCIDSS compliance as a Service Provider however there is a Magtek card reader attached to the business computer where face to face transactions are processed thru the SaaS. The SaaS is not validated as a payment application as they do not meet PADSS requirements. SAQC appears to want to confirm a validated payment application is used, but the SaaS is not validated to PADSS only PCIDSS. Could this apply to an SAQC scope?

    • August 30, 2016 at 7:41 AM

      What you need to do is to get from the SaaS vendor, the PA-DSS validation information of the payment page provider.

  44. 118 MS
    August 25, 2016 at 5:52 AM

    Hi PCI Guru ,

    I have a question on nested iframe solution used in mobile app. Company X has a PCI compliant mobile app solutions for its customers , this solution has processor iframe on payment page where customers enter credit card information. They are changing processors . New processor iframe is not compatible on mobile phone , but can work on a web server hosted in a Data Center inside company X. New Proposed solution is , adding another layer of iframe on mobile app payment page , this iframe will point to processor iframe hosted on a file server.
    Is this nested iframe solution supported by SAQ A ?

    • August 25, 2016 at 8:32 AM

      Good question. The only answer I can provide is that I would have to look at the server and see if any SAD/CHD ended up in memory on that server. I am betting there is, but you would have to conduct the necessary analysis to prove it one way or another.

  45. August 23, 2016 at 12:17 PM

    The Quest for SAQ A……
    Ok, I will try to be brief. 1 legal entity. A few hundred MIDs. Most thought to be considered a SAQ A for their use of API’s that land the customer on a 3rd Party Processor page to enter CHD. However, these MIDs also do MOTO and some reconciliation (no CHD on the back-outs, but yes on the MOTO). Those doing MOTO use a Citrix client that uses Citrix as a ‘jump point’ to the payment processor thereby allowing only 1 IP addy for the Processor to allow (Citrix is behind FW) from the company. Does this still qualify as a SAQ A? ……now let me spice this up a bit. The FW that sits in front of Citrix also acts as a VPN concentrator for a number of connections to POS environments, which may be for other MIDs. …..but wait, there’s more. The FW also sits in front of a server cluster that handles student ID card payments (not CC data, but like a personal account tied to an ID card) …..help?

    • August 25, 2016 at 8:27 AM

      In order to use SAQ A, everything MUST be outsourced including MOTO and your other payment channels.

      The student ID process is similar to a private label payment card, so PCI does not apply. That said though, I would secure it and process it as though it were in PCI scope just to be safe.

  46. 122 FDanforth
    August 22, 2016 at 4:29 PM

    Hi PCI Guru,

    thanks as always for your excellent guidance. Here’s my question:

    We just entered into a new contractual relationship. The company is PCI compliant (they provide online fundraising SaaS), and they connect directly with our PCI compliant gateway (BrainTree), so no data is flowing onto my networks.

    However, they are storing every single payment card in BrainTree’s vault, even when there are no recurring charges happening. We don’t need this data, we get charged for the storage, and it interferes with other business processes for true recurring payments.

    From my perspective, this is unnecessary storage. Is there anything directly applicable in the PCI DSS or PA-DSS that explicitly prohibits this unnecessary storage? Or other leverage you might suggest to strengthen our case for why they need to stop this behavior?

    Thanks much,
    Faith

    • August 25, 2016 at 8:49 AM

      It may be unnecessary to your business model, but this is how the processor (BrainTree) works. As long as you have a compliant AOC from BrainTree for the services they provide you, it’s their problem, not yours.

  47. August 12, 2016 at 9:21 AM

    PCI Soup

    This is a question that has many legs to it…I think.
    The first part deals with the relationship of Merchant ID’s (MIDs) versus the organization at large – that is, let’s say you have an institution of higher learning with a typical extended campus and literally a few hundred MIDs. The SAQ levels vary; let’s say most fit into the SAQ A with some B and maybe a few A-EP and one D variety. Are these MIDs all treated as separate companies? Do they ultimately tie back to the parent organization? If so, what effect does that have on all the other MIDs and their SAQ obligations?
    The second part deals with shared infrastructure. What effect does having a few hundred MIDs that at various points share infrastructure – whether it is web servers, networks, segregated Citrix gateway (used to segment a processor access gateway), etc. – yet, fill out and submit separate SAQ’s?
    Lastly, as you have noted in another post, what effect does a 3rd party (bookstore, cafe etc.) using the same – typically open, infrastructure have on all this?

    As I said. PCI Soup.

    Thanks
    Mayday

    • August 13, 2016 at 3:19 PM

      Organizations with multiple merchant identifiers (MID) but only one legal entity such as with higher education should be aggregating all of those MIDs together to determine their merchant level. However, it is up to your processor(s)/bank(s) to provide you guidance in this area just as they would provide you for which self-assessment questionnaires (SAQ) your organization should be using.

      The problem long ago was that MIDs that were with different processors/banks would not get aggregated. Some of the more unscrupulous merchants played a game to avoid doing a Report On Compliance (ROC) by having lots of MIDs with different processors/banks. However, most processors/banks got wise about this scam and now share transaction counts with one another for organizations so that it is tougher to get away with staying at an SAQ when the organization should be doing a ROC.

      The number of MIDs involved has nothing to do with the assessment of infrastructure other than from a scoping perspective.

      Finally, third parties using another organization’s infrastructure can put that infrastructure in scope depending on whether or not the third parties’ transactions are encrypted and the infrastructure can be shown that it cannot decrypt the data streams.

      • August 15, 2016 at 8:06 AM

        So – if I read you correctly, determining your SAQ level (apart from Merchant Level) should be driven by the legal entity versus the individual MID. (Understanding that acquiring banks can advise as they will.) Therefore, if you have 300 MIDs under 1 legal entity, you should have 1 SAQ…..correct?

      • August 16, 2016 at 7:14 AM

        You are correct.

        That said, for assessment purposes, it may be easier to do multiple assessments even though you are one legal entity. Whatever the plan, an organization needs to consult with their acquiring bank(s) and/or processor(s) to get approval for whatever approach they chose to take.

  48. 128 Bryan Carter
    August 8, 2016 at 2:51 PM

    We had a retail customer request that we not print their signature on the credit card transaction receipt. I have dealt a lot with all of the other CHD, but I have seen little discussion about the storage of signatures electronically or physically. Obviously if it is printed on a receipt and given to a customer it is their discretion as to what to do with it. I suspect the real concern is that we are storing it electronically as an image. I have advised that we eliminate that piece of data from the system because I feel it will simply cause more headaches, and provide minimal value. I would like your thoughts on best practice surrounding the signatures. Thanks!

    • August 13, 2016 at 3:45 PM

      While not part of PCI, as a security professional, I have a LOT of reservations about merchants that print my signature on receipts. I think it is a very bad practice from a personally identifiable identification (PII) perspective even if given back to the customer. There is just too much risk there that the receipt is thrown out or recycled and not securely shredded by the customer.

      That said, most states and countries with privacy laws consider signatures as PII, so you should be encrypting it and protecting it. I have a few clients that store the signature for transaction validation purposes for a period of 90 to 120 days when they securely erase it. In those cases, all of them have encrypted it because it is PII.

  49. August 8, 2016 at 9:35 AM

    Hi,

    We receive paper forms with cardholder data for supporters to make donations. Can we:
    – use a virtual terminal on the gateway providers web portal from one of our PC’s to enter CC data?
    – use an ipad (for example) with a 3g/4g connection – ideally banned from the wifi network as an alternate method?

    Would either of these methods comply with PCI? the paper forms are stored securely and then destroyed appropriately.

    Thanks,

    Taruna

    • August 13, 2016 at 3:55 PM

      Never, ever, ever use tablets or smartphones (Windows, iOS, Android, etc.) for manual data entry of sensitive authentication data (SAD) or cardholder data (CHD). The data manually entered will be stored by those devices from one month to six months or more depending on the device’s amount of memory and how much it is used. This is why the Council said years ago that such devices would never be PTS certified.

      I am assuming by your question that you are trying to get your organization out of scope. Forget it. The mere fact that you deal with SAD/CHD puts you in some amount of scope. So get rid of that idea right now.

      The minimum amount of scope is to use either a virtual terminal or a PC. However, whatever solution you use, that device is still in scope because the keyboard is being used and the SAD/CHD flows through the keyboard and device to the VDI or directly to the gateway. So it could be memory scraped or keyboard logged off of the input device. Not that you need to go overboard segmenting those devices away, the HTTPS does that. But you do need to manage the risk of the memory scraping or keyboard logging which can be accomplished with anti-virus and application whitelisting/blacklisting, file integrity monitoring or similar approaches.

      • 132 Scott Buchanan
        August 26, 2016 at 3:21 PM

        “The data manually entered will be stored by those devices from one month to six months or more depending on the device’s amount of memory and how much it is used.”

        While the compliance part of your answer is beyond my scope of expertise, this statement here is nonsense. Unless the payment application has functionality specifically written to store payment information on the device, the data is no more likely to be stored on a mobile device than on a PC.

      • August 30, 2016 at 7:29 AM

        Unfortunately, not true. Thanks to the way the operating systems for mobile devices are written, they store all manually entered data they come into contact whether that is the songs you play, what you searched for on the Internet and every manually entered credit card number. This is how iOS, Android, Windows and other mobile operating systems “learn” your likes and dislikes.

      • 134 Scott Buchanan
        August 30, 2016 at 8:04 AM

        I challenge you to provide a a citation for that claim (i.e., that mobile operating systems store “all manually entered data they come into contact” with). As a software engineer who works on mobile platforms, I can say with absolute certainty it’s not true. Some data may be stored, if the device is configured to allow it and if the application is built to allow it, but to say all (or even most) data is stored is vastly overstated.

        Just consider the ramifications if it were: mobile devices wouldn’t be allowed in any regulated environment, from health care (due to HIPAA) to corporations (due to internal data retention policies). Yet standard COTS mobile devices are used in all of these. Furthermore, if what you’re saying is true, then you have to be suggesting that every single e-commerce vendor with a mobile storefront/apps is flagrantly violating PCI rules: from Amazon to eBay to Walmart to Apple to Google, given that a customer manually enters their credit card information on all of these. That’s simply not believable.

      • September 6, 2016 at 9:27 AM

        Here are the two I’ve most seen referenced.

        http://securitywatch.pcmag.com/security-software/308519-rsa-your-smartphone-stores-every-keystroke-you-ever-typed

        http://gizmodo.com/5863849/your-android-phone-is-secretly-recording-everything-you-do

        But any forensic examiner worth their salt will tell you the same information, CarrierIQ or not. Smartphones and tablets are the most wonderful devices on the face of the Earth from the information the surreptitiously record all in the name of “improving the user experience”. Even Windows 10 has gotten into the act and is why a lot of companies demanded Microsoft remove that capability from the Enterprise version which they did. However, other Windows 10 version still record as does Windows 8 which is why a lot of corporations avoided it like the plague.

      • September 16, 2016 at 10:31 AM

        quick question on this. I have a client’s environment where MOTO transactions (CHD) are entered into a payment processor portal. For the purpose of locking down to a single IP, a Citrix ‘gateway’ is used. So – workstation with Citrix client. Citrix farm is behind FW on 1918 net that act as proxy out to payment processor portal. Oh, and the workstation has a real world IP addy with direct internet access. 2 questions. A. Is the workstation with the Citrix Client in scope? B. Is the Citrix farm required to be scanned/pen tested?

        Thx.

      • September 19, 2016 at 7:17 PM

        Yes, the workstation with the Citrix client is in-scope because its keyboard and memory still process/transmit the PAN. The risk is that a keyboard logger or memory scraper compromise those systems. As long as you minimize that risk, they should be able to coexist with other workstations on the same network segment. Solutions to minimize that risk are application white/black listing, critical file monitoring, etc. Since these systems have direct Internet access, you probably also want to control what these users can access on the Internet through a proxy or similar solution. However, you will also need to support your decisions on a risk assessment of your environment and those workstations. You will also what to periodically vulnerability scan and penetration test a sample of workstations (assuming they are all the same) just to ensure that they do not become more risky.

        Yes, your Citrix is in-scope as well and needs to be vulnerability scanned and penetration tested.

      • 138 Mike
        January 17, 2017 at 5:06 PM

        To emphasize what Scott Buchanan says, this is indeed not true. The two links provided by PCIGuru to support this claim are not exactly accurate. They refer to a specific software vulnerabilities discovered (still valid?) that have nothing to do with the overall mobile device OS architecture. Of course there are mistakes, bugs, vulnerabilities and so on but mobile device OS as with any software but the OS still designed with security in mind. If the OS are secure enough it is a matter of opinion, today they are trusted by all kind of security sensitive tasks so it is definitely not the common industry perception. Take the link referring to the database used for auto completion. This would be a problem using a naive implementation on an app by prompting the user to enter data with the default keyboard rather than a more secure keyboard implementation. Sure, the device OS could provide more security features out of the box but that doesn’t mean that mobile apps developed from security companies have the same design flaws.
        You can protect sensitive better with a mobile device than from a card in your wallet from an individual user’s perspective. Simply adding fingerprint verification makes stealing your phone compared to stealing your wallet that step harder. That been said, for a financial institution it is different, they care about risks involving mass theft of sensitive data due to some malware. The key point? Users will use mobile devices since it can secure their data and they typically don’t care if it adds risks in a more global level. Some companies, thus, will offer mobile solutions. Other companies will have to compete as apart from loss of fraud there is simpler risks of loss of business.

  50. 139 Ben
    August 5, 2016 at 6:14 PM

    If you are a merchant that has entirely outsourced your payment processing, but several employees have company credit cards, and the finance department stores the PANs for those cards in their financial software, does that make you subject to SAQ D since you are technically storing cardholder data?

    • August 13, 2016 at 4:03 PM

      No. Corporate credit cards are not part of a merchant’s PCI scope.

      That said, you should have an agreement between your employees and your organization that indicates that they are allowing you to store that information and use it only for approved purchases and that you, as their employer, agree to protect that information.

  51. 141 Tonny
    August 4, 2016 at 7:01 AM

    I have a question about 8.3.1 of PCI 3.2. Our company provides web applications for our client. The client could use the application to process Credit transaction for their user, and manage their user. My question is if the client’s administrator of the application must have used two-factor authentication (2FA) to obtain that application.

    • August 5, 2016 at 7:21 AM

      Yes, everyone needs to have two factor authentication if they are remotely accessing the application.

      • 143 Tonny
        August 5, 2016 at 9:16 AM

        Actually the administrator login to the application by web, juts like a normal user. Any difference?

      • August 5, 2016 at 3:52 PM

        Anyone with administrator privileges should have been using two factor for remote access from the get go. Its the normal business user that interacts with the application on behalf of their employer who has contracted with the service provider that is now being added. The idea is to minimize the risk presented should those users be phished and compromised.

  52. 145 Ryan S McLeod
    August 2, 2016 at 1:19 PM

    I’m curious what your take is on Credit Card Convince Checks. We image our checks and then send them to the bank. Would we have to report that we have check images with credit numbers on them? We don’t store anything with our merchant accounts and they are completely separate from this process.

    • August 3, 2016 at 3:41 PM

      The short answer is yes, those checks are in scope for PCI compliance because a primary account number (PAN) is a PAN as far as the card brands are concerned. It also sounds like you are a service provider running a lock box operation, so it’s an SAQ D although most of it will be marked Not Applicable (NA).

      You will not only need to securely store the physical paper, but also securely destroy them as well. Given they are checks, I would already assume you are doing that. However, the check images will also have to be encrypted wherever you are electronically storing those. You will also have to limit access to those checks and log whenever someone accesses those checks.

      • 147 Ryan
        August 4, 2016 at 1:35 PM

        Thanks you for your response on this. We are not a service provider providing a lock box. We are a merchant that accepts checks as a method of payment for goods and services. If we accept these checks that have credit card numbers on them we are in scope for PCI? If we didn’t have a merchant account how could this possibly be enforced?

      • August 5, 2016 at 7:16 AM

        If you do not accept payment cards for payment, why would someone write you a check and put their payment card primary account number (PAN) on it? Or have you instructed your sales people to get a PAN on any checks like some merchants do? Regardless, if a check has a PAN on it, it is now in scope for PCI and must be protected as such. Your organization may not have a merchant agreement, but if your organization becomes the source of a breach, it will still be held legally liable for the loss of that information.

  53. 149 Tim
    July 25, 2016 at 9:16 AM

    Thanks for your time answering these questions! I’ve now found that my PDQ device is covered by P2PE-HW and I don’t need to complete a SAQ B-IP. Could have saved myself quite a bit of time and money! On the flip side, I’ve a well documented system and controls in place.

  54. 150 Jon
    July 21, 2016 at 5:18 AM

    Hey there! I was wondering. In terms of VPN certificates, would you consider Internal CAs as valid for PCI Compliance or do you always ask for external CA? Thanks as usual for your really useful and experienced advice!

    • July 21, 2016 at 5:31 AM

      If you truly operate your own internal certificate of authority (CA), then that is acceptable. What is not acceptable is a self-signed certificate that generates an error because it was not issued by a CA. That creates a bad habit of people skipping by the error and potentially ending up somewhere they should not be and then compromising your operation.

      • 152 Jon
        July 21, 2016 at 5:37 AM

        Yes, indeed. And also, self signed certificate will show up in Vuln Scans which will also make req11 to be failed.
        Thanks a lot again for your thoughts sir! Let me tell you this resource you have here is amazing. I also use your Misc page as a continuos trainning since I receive all the updates from here and I try to answer them based on my knowledge and then validate it against your response. So this is kinda a conitnuos PCI course for me and I bet for lot of people who follows your blog.

        Have a nice day and thnaks again!

  55. 153 Bill
    July 20, 2016 at 7:51 AM

    Your advice is great! Very helpful! Another question around segmentation. I’m struggling with the idea of segmenting workstations that would be used to go out to a payment gateway’s website, and enter in payment information received say by regular postal mail or even over the phone. My initial thought is that these workstations are in scope, but do they need to be in a segmented CDE. The issue is that then this would mean that all other servers and applications within my environment that these users need to access that have nothing to do with taking payments or CHD would also be in scope. Is that correct? I understand that the risk are primarily around malware and keyloggers so antivirus is important, but does this really put all those other system in scope if all they are doing is entering information into a website?

    Thanks again for your advise!

    • July 26, 2016 at 8:01 AM

      A lot of my clients doing mail order/telephone order (MOTO) are moving to using secure card terminals such as those from MagTek, IDTech, Verifone and Ingenico. These are paired with some sort of P2PE/E2EE solution and therefore take everything else out of scope except the terminal. Returned to your systems is a token. Best way to reduce your scope to the absolute minimum. Talk to your transaction gateway or processor about what they can make work.

  56. July 20, 2016 at 4:59 AM

    Hi

    Can you advise – are CAF cards within the remit of pci compliance? they are not credit cards, just cards people can use to donate to charities. They don’t have an end date and have the same number format as credit cards – 16 digits.

    Thanks,

    Taruna

    • July 26, 2016 at 8:05 AM

      If a payment card does not carry the logo of a card brand (such as Visa, MasterCard, American Express, Discover or JCB), then it is a private label card and is not covered by PCI. However, that said, you would be foolish to not treat them any different because they do have a cash value to the customer and should therefore be treated with the same respect and security as a branded card.

  57. 157 Masa
    July 19, 2016 at 8:02 PM

    Hi PCI Guru

    We are outsourcing company planning to start a call center operation business. Agents will be handling credit card info of customer over the phone but CD will not be stored into our system.

    Since the project is starting out small, we are planning to have our call center agents placed in our current office where other employees (accountant, hr, etc) not associated with the call center operations.

    Can call center agents and these non associated employees share a room but still be PCI compliant?

    Thank you for your advice in advance!

    • July 26, 2016 at 8:11 AM

      Yes, the call center agents and others can share the same room. However I would highly recommend that everyone in the organization be trained to understand that the call center comes into contact with sensitive information that, if overheard, must be kept confidential and not communicated to anyone, internal or external to the organization.

      You also will need to segment your call center systems from the rest of your organization. I am assuming the agents will use HTTPS Web sites for data entry, so implementing a local firewall on their workstations will be sufficient to segment them, but your domain controllers and other shared systems will come into scope for PCI albeit somewhat reduced depending on the risks they present to the workstations. I would also recommend that any transactions your call center processes be done under your customers’ merchant identifiers and not your own. That way you will avoid being both a merchant and a service provider for your call center operation.

  58. 159 Masa
    July 19, 2016 at 7:49 PM

    Hi PCI Gru

    We are outsourcing company and theres a plan to start a call center business that will take a credit card payment over the phone.
    Since we are starting small with this project, we are planning our call center agents to be placed in our current office with other employees not associated with this call center project at all.
    I wasn’t sure if it is ok for our credit card processing agents to share a room with other (accountant, hr, etc) employee not associated with call center operations to be PCI compliant.

    • July 19, 2016 at 8:03 PM

      As long as all personnel in the room understand that they could overhear or see sensitive authentication data (SAD) and/or cardholder data (CHD), they understand the sensitivity of that data and that it must remain protected/secret, there is no reason they cannot be in the same room.

      • 161 Masa
        July 20, 2016 at 12:57 PM

        Thank you for the answer. I have one more question. Since we will be classified as a service provider, is annual onsite review by QSA required? According to this website ( http://www.pciassessment.org/pci-dss-framework/service-providers ) it seems so.

      • July 20, 2016 at 4:41 PM

        That depends on whose merchant identifier is used for the transactions. If the merchant IDs are your customers, then I would argue you are only providing people and equipment to take calls and the transaction counts are on your customers. If they are your merchant IDs, then that will depend on when you exceed 300K annual transactions. The other consideration though is if you want your company listed on the Visa or MasterCard service provider registries. If you do, then you will have to get a QSA and conduct an assessment that creates a Report On Compliance (ROC). Otherwise if your annual transaction count is less than 300K, then you can do a service provider SAQ D.

  59. July 19, 2016 at 8:08 AM

    Hi,

    Thanks for your advice up till now. I have another question. We are in the process of implementing a PCI compliant phone solution whereby the supporter would enter their CC details using their own telephone keypad for that section of the phone call – these would appear as asterisks on the agents screen. We have a large proportion of older supporters who are not comfortable using this process and would prefer the agent to enter the CC details for them. So the supporter would read the details out and the agent would enter them using their phone keypad. We have tested this out and the process works fine from our perspective. The agents are not writing any details down, the conversations are not recorded. I was wondering if the process we are proposing would be pci compliant?

    • July 19, 2016 at 8:23 AM

      There are a lot of other factors here than just telephony. Are we talking traditional PBX or VoIP (if VoIP, this opens a whole host of other questions/issues)? Is the IVR system in-house or outsourced? How is the IVR connected to the application? How does the card data get transmitted from the IVR or application to the processor? What, if anything, is returned from the processor? That is just the start.

      • July 20, 2016 at 5:04 AM

        Hi,

        the IVR system is outsourced – we open a web browser that links us to PCIPAL. We simply dial a number that securely connects us and the supporter. The supporter would then enter their CC details and we would hear the dtmf tones. the return is either success or fail and is displayed on the screen.

        Thanks

        Taruna

      • July 26, 2016 at 8:03 AM

        The fact that your operators can hear the DTMF is problematic because of the potential to record them for later playback and thus get the SAD/CHD. Most IVR systems I deal with do not let the operator hear those tones. I am betting that your outsourcer can shut those off and I would recommend that they take that action.

  60. July 19, 2016 at 5:44 AM

    Fedex recently lost a package of 300 paper credit card slips, pre-authorisation, including CVV, being shipped from our sales office to our processing office… We have no evidence that any card fraud has happened, and we have already contacted the individuals and offered support. What is my obligation to notify card brands or PSP’s ?

    • July 19, 2016 at 8:13 AM

      Under your merchant agreements with the card brands, you should have notified the brands immediately upon the loss. Notifying the payment service providers (PSP) would have done nothing and they should direct you to the brands. The brands control the compromised card processes.

  61. 169 Fouad
    July 9, 2016 at 12:24 PM

    Hi PCI Guru,

    We are a small company moving towards a medium size company, i have been given the responsibility a couple of years ago to bring our firm into compliance with PCI DSS.

    So far we have been audited by external potential clients who wish to do business with us, the audits were to provide assurance to them and their customers that their data will be secure on our end, the other day i asked myself if we (As in the company i work for) should start auditing the potential clients in return.

    So my question is; if we are PCI compliant, would we (for any reason relating to PCI or other compliance frameworks) need to audit any potential companies who wish to do business with us ? maybe if we experience a security breach as a result of the new company we can hold them accountable ? or is there no need for this ?

    Thanks in advance,
    An avid follower and subscriber!

    • July 13, 2016 at 5:36 AM

      From a PCI perspective, only third party service providers that; (1) process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD) , or (2) have access to systems that process, store or transmit SAD/CHD need to be assessed for PCI compliance. Assuming an organization processes, stores or transmits SAD/CHD, examples of each would be for (1) transaction gateways/processors and for (2) managed security services providers (MSSP) and log aggregation and analysis service providers. If a third party does not have access to SAD/CHD or does not process, store or transmit SAD/CHD, then they do not have to be assessed for PCI compliance.

      For any third party service provider that needs to be assessed for PCI compliance, they have two choices. The first and most common is that the service provider conducts their own PCI assessment of all services in-scope and provides the resulting Service Provider Attestation Of Compliance to their customers. The second and most intrusive is what you have been doing which is to have each customers’ QSA/ISA come through your organization and conduct their own assessment of the in-scope services your organization provides to their organization.

  62. 171 Luigi Figueroa
    June 29, 2016 at 3:29 PM

    Hi PCI Guru,
    Is there some kind of dialogue that can be used to tell customers that we are not going to store their credit card information? Before, we would store customers credit card info for the sake of convenience, but now that we are trying to narrow our scope, we don’t want to store any kind of credit card data. What is the best way to put it gently for customers?

    Thanks!

    • July 2, 2016 at 7:45 AM

      How about “We do not store your payment card information”?

  63. 173 Greg Crowe
    June 29, 2016 at 7:20 AM

    Hi,
    Wondering if you could provide your 2 cents on shared anti-DDoS platforms. a lot of companies offer them and are very apprehensive about giving information on how they work. Companies like CloudFlare say they are a level 1 service provider for their products but i don’t understand how they can provide a compliant solution. My understanding is that it works by decrypting traffic that passes through it to analyse its validity and then re-encrypting it, forwarding it on to its final destination. If this shared platform is decrypting CHD for not one but multiple unique clients it surely cant meet compliance as the potential disaster is huge (in terms of a breach) and risk unacceptable?
    would really appreciate getting your thoughts on this.
    Thanks,

    • July 2, 2016 at 7:53 AM

      This is where everyone’s differing levels of paranoia and risk acceptance come into play.

      You are right. The DDoS solution in question essentially proxies TLS connections by acting as an endpoint and a starting point. As a result, there is a risk that the DDoS solution is compromised and that the attacker gains access to the datastreams and collects cardholder data (CHD). That said, these solutions are not necessarily exclusively processing CHD datastreams. So the attacker would have to collect a LOT of packets and then sift through those terabytes to find the ones that contain CHD. Not that this sort of attack is not impossible, but what is the likelihood? In my experience, I would say that likelihood is fairly low. However, if successful, the rewards could be well worth the effort.

      And that is where every organization has to make a decision as to if they are willing to take that risk.

  64. 175 Kevin
    June 28, 2016 at 8:09 AM

    We have a call center that contains shred bins that are serviced by a third-party. In the call center, agents take orders by phone and enter cardholder data into a secure web page. There is also physical cardholder data for mail orders there. Because of that, I consider our call center to be a sensitive area for PCI purposes, and I require that our representative from the third party shredding company be escorted when he services the shred bins located in the call center (per PCI DSS 9.4.1). He thinks that because his company is fully certified that he should be able to have direct access to our call center with his vendor badge, but I have it currently set up that he has to knock to be let in. Do you I have it right?

    • June 28, 2016 at 10:42 AM

      I have clients that allow the third party vendor unescorted access and I have customers that escort them. Whatever you are comfortable with is up to you but escorting the vendor is not required by the PCI DSS.

    • 177 Sebastian Nielsen
      July 25, 2016 at 8:37 PM

      If you still want to go for the escort route, which in fact is a secure and good thing to do:

      I see a risk here: Theres a risk a unauthorized person could enter the facility by escort by pretending to be the vendor, and possible have a counterfeit badge. I would suggest you instead configure your access control system to generate a “secure knock” when the vendor scans his badge. Depending on which access control system is done, it can be done in multiple ways. If your door controller is supporting multiple door output, you can connect a “ding-dong” with a distict sound ouput, to the second door relay of the door controller. Then you add the vendor badge to only have access to the “second door” in the access control software.
      Another way if your access controller isn’t supporting multiple door outputs, if you don’t use the “duress function” of the access control system, is that you put his badge on “duress list”, configure the badge to not have access at all, and then wire the duress relay to a “ding-dong” with a distinct sound.
      Some access control system can pull a custom relay if a specific card is scanned, then you can use that function.

      The result is when your third-party vendor scans his badge, it will generate a distinct sound so you immediately know that its the vendor while the door still wont open. This increases security as you can ignore knocks from people if they don’t have a pre-booked appointment, while you still can let in the vendor at any time.

      This gives double security as the vendor is both physically and electronically verified as genuine.

  65. 178 Leland
    June 23, 2016 at 10:46 AM

    Hello,

    We are looking at section 8 in PCI 3.0, we are wondering how to address sections such as lockout duration, change password every 90 days, and submit a new password each time up to the last 4. Are these required on the servers our web app runs on and also the web application users sign into? For example I don’t remember having to change my password on Amazon every 90 days? Our web application accepts payment but only stores PII, it merely transmits the data to a vendor for processing and we store a token.

    Thanks for your help!

    • June 24, 2016 at 8:43 AM

      Not for customers. These are required for anyone that manages that environment such as administrators and internal/external personnel that manage content/sales on the Web site.

  66. June 23, 2016 at 4:56 AM

    Hi,

    Thanks for all the advice up till now – its been really useful in guiding us.

    I have another question… We are receiving calls from a Security Metrics that would like to scan our networks quarterly. But, our web donations are dealt with via Braintree . Our phone donations are in the process of being outsourced with PCIPAL and Cybersource who are both compliant. Both these mean we can self certify the SAQ. I cannot see any reason why we would need to sign another contract for scanning our networks – surely we could simply refer Security Metrics to our providers?

    Thanks,

    Taruna

    • June 23, 2016 at 5:02 AM

      As long as your Web site uses a redirect or iFrame to get to Braintree, then it does not need quarterly scanning. However, I believe some Braintree solutions put code on the merchant’s Web server which is why Security Metrics called because Braintree told them to call because you have a solution that requires scanning. You should contact Braintree to determine if your solution needs scanning.

  67. 182 Erik
    June 22, 2016 at 1:35 AM

    In the RoC Reporting Template for PCI DSS 3.2. There is a new section (1.5) where you state the overall compliance for each of the main requirements using checkboxes. You can check Compliant, Non Compliant or Not Applicable.

    Now, what do you do if a requirement is Not Tested?

    • June 22, 2016 at 10:29 AM

      Good question for the Council as I have no idea.

      • 184 Erik
        June 23, 2016 at 5:06 AM

        Yeah, we will put the question to the Council.

        It looks like the section was rushed because unlike all other sections of the RoC, there is no guidance whatsoever. I think it’s a bug. The rightmost column should probably be Not Tested rather than Not Applicable.

      • June 23, 2016 at 5:08 AM

        Or it needs another column added.

      • 186 Jon
        June 23, 2016 at 5:31 AM

        Point for QSA.
        QSA 15 – AQM 0
        QSA Serve =)

  68. 187 CJ
    June 17, 2016 at 8:07 AM

    Our organization is in process of determining if our PCI DSS scope is correct. We have done lots of research and read the Open PCI DSS Scoping Toolkit document. However, we still struggle to fully understand it.

    We have the CDE servers segregated on its own VLAN behind the internal firewalls. Only the CDE environment is behind these firewalls. We understand that all 12 requirements apply to this segment (1a devices).

    Q1. We have devices outside our PCI segment that provide services to PCI segment. This includes Active Directory, SIEM, and Anti-Virus. To us it seems these devices belong to “2a” category and are in scope. The toolkit states that all applicable PCI controls are required for Category 1 and 2a systems. Does that mean that we have to move all these devices behind the firewall into the CDE environment? Or can we leave it as is, and protect these servers with all applicable PCI controls (also introduce the hardening standards) and then document all required ports that are required to be opened on the firewall in order for these servers to provide required services to our CDE environment?

    Q2. One of our larger departments functions in a call center fashion. They take card data via phone and then enter it to software that is installed on their PC. This software connects to the server in CDE environment. Nothing is stored locally on the PC. Everything is submitted and stored on this one server in CDE environment. The connection between the PC and the server is encrypted. Additionally, after the data has been entered, if the center representative went back in to check the card number, they would be able to see only the last 4 digits for verification purposes. Our question is about these PCs (we understand they are in scope), but do we need to move them inside the CDE environment where the server is located or leave them where they are at, and apply all applicable PCI controls and host based hardening controls (FIM, SIEM, anti-virus, patching, access controls, monitoring, etc). There is only 1 port required for the PC (software on the PC) to communicate with the server within the CDE segment. That is the only port we allow through the firewall and we have it documented.

    Thank you so for your help.

    • June 17, 2016 at 7:05 PM

      A1: You should get a copy of the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/) and focus on “Connected To” systems, aka Category 2 systems. But the bottom line is that any systems that connect to systems in your cardholder data environment (CDE) are in-scope for PCI compliance. The question is how much in scope. Domain Controllers are typically much more of a threat/risk than a workstation that connects through HTTPS and a Web application.

      A2: The risk of your workstations is that they get a keyboard logger or a memory scraper installed. While they do not need to be inside the CDE, they do need to be appropriately security hardened and need something to address the aforementioned risks with a white listing solution, critical file monitoring or similar solution that minimizes those risks.

      • 189 CJ
        June 19, 2016 at 9:48 PM

        Thank you so much PCIGuru. Greatly appreciated. Just one follow up question…how about the other systems (out of scope systemss) that share the same domain controller and SIEM as systems in CDE?…(devices out of scope do not have direct access to CDE)

      • June 20, 2016 at 12:28 PM

        Other systems that might share those Category 2 systems should still be out of scope. However, that is all up to your willingness to accept the risk of those systems sharing those services. The bottom line in my opinion is, if your basic level of security is good enough at managing risk, then out of scope systems sharing services with AD, DNS, SIEM, etc. should be minimal risk. The key is that it is not easy for someone to compromise an out of scope system and then leverage that system to gain access to in scope systems.

      • 191 Erik
        June 22, 2016 at 8:27 AM

        If your Active Directory is outside the CDE and controls access to and inside the CDE, then your segmentation is probably incomplete. The segmentation should be strong enough that if your non-CDE systems are hacked, the security of the CDE should not be affected.

        Access controls and access management for the CDE should be completely separated from access controls and access management for your non-CDE systems.

      • June 22, 2016 at 10:36 AM

        This is where paranoia and security get messy. What is the point of implementing separate AD systems? Manually trying to keep them in synch is going to create more problems than it solves. Bizarre one way trusts also create more problems than they solve. At some point you need to be will to accept the risks of having a single directory solution. If not, then you need to accept the mess of having separate directories and that mess.

      • 193 Erik
        June 23, 2016 at 5:27 AM

        If hacking the non-CDE systems (and AD) can give you access to the CDE, then the segmentation is probably not sufficient. AFAIK, that’s what happened in some of the high-profile breaches in recent years.

        Many of my PCI customers keep a separate access control system for their CDE. Typically, only a very small group of people need access to it. This makes it easier for the customer to manage and makes the PCI DSS assessment much easier.

        Using the same access control system for CDE and non-CDE networks would be possible, but it would probably be much more difficult and expensive to build and maintain, and it would be significantly more work to verify the segmentation controls during the assessment.

      • June 24, 2016 at 8:50 AM

        Which is why in v3.2 the Council added two-factor authentication for anyone directly accessing the CDE. At the end of the day, it all comes down to how much risk is your organization willing to accept. There are risks with a common directory system and there are risks with separate directory systems. That said, properly implemented and managed, a common directory system can be secure and still provide a common directory platform.

      • 195 Brian
        July 21, 2016 at 4:12 PM

        Regarding Q2/A2: According to the scoping toolkit, the PC is a Category 1a system (a.k.a. CDE), because they process cardholder data (effectively SAQ C type environment). Any systems directly connected to them are Category 1b, and also part of the CDE. So they all need the requirements applied (hardening, logging, scans, fim, etc…).

      • July 26, 2016 at 7:54 AM

        Depends on the segmentation that is in place. Some of those connected systems may be of the 2a or 2b variety if segmentation is in place.

    • 197 CJ
      June 27, 2016 at 9:32 PM

      Thank you PCI Guru. This helps me a lot. Greatly appreciated!

  69. June 15, 2016 at 10:04 AM

    Our customers have been getting notices from their processors about the QIR requirement from Visa that is effective on Jan 31st, 2017. So I have 2 questions on that. First, we are not integrators or resellers as we are the software vendor so if our staff does install on -site do they need to be QIR certified? Second, QIR is for individuals installing PA-DSS validated payment applications, and our newest version is a P2Pe certified application. With the applicaiton out of scope, QIR certification does not make sense.

    Thoughts?

    • June 15, 2016 at 3:10 PM

      I am with you. The page on the Council’s Web site clearly states that the Qualified Integrators and Resellers (QIR) certification is for implementation of PA-DSS validated applications by third parties, not the implementation of P2PE solutions.

  70. 200 Mitch Bucannon
    June 8, 2016 at 2:14 PM

    I have a manage a small medical clinic and we using navicure and PayLeap usb card swippers. Our network is provided by a larger medical organization and is shared across different locations. They also provide Including our PCs. They said the PCs connected to the readers will only be used for swiping. Does my network provider need to be involved or informed? Is this a C-VT SAQ type, or something else?

    • June 8, 2016 at 3:50 PM

      If the PayLeap terminals are connected to PCs over USB, then the cardholder data (CHD) and/or sensitive authorization data (SAD) is likely flowing through the PC to an application or network. So you need to know more about those terminals and how the data moves from them to your transaction processor.

      That said, you are definitely not an SAQ C-VT because you have card terminals or point of interaction (POI). YOu need to more about how your applications work with the terminals to know what SAQ to use.

  71. 202 Brady
    June 2, 2016 at 6:03 PM

    PCI Guru: I floated this idea by Mozilla – https://bugzilla.mozilla.org/show_bug.cgi?id=1275967

    I have no idea what will come of it but it seemed like a way to reduce the influence a merchant site has over where the customer’s browser renders a payment provider iFrame from.

  72. 203 Gretchen
    June 2, 2016 at 11:21 AM

    I am a one-man shop and only process cards through a virtual terminal. I am not an IT person and have no idea what they are talking about with half of this stuff. What, for instance, is a demilitarized zone? If I only run cards when hooked up through an LAN and am not using wifi, and I’m not storing any cardholder information anywhere on the system, do I need to worry about all of these IT configurations? Because, if I do, offering credit card payments to my clients is quickly going to be not worth the time and expense because I’m going to have to hire an IT person to figure all this out.

    • June 2, 2016 at 11:41 AM

      You should be entering cardholder data (CHD) through a browser over HTTPS. The HTTPS session using TLS v1.2+ is what segments your workstations from the rest of your network devices and computers. Then it all comes down to keeping your workstations current on patches and have anti-virus on them.

      Your other option is to go to physical card terminals such as those from Verifone or Ingenico over dialup or your network. Your acquiring bank can set you up with terminals that will encrypt the CHD when it is entered into the terminal. Again, putting the rest of your network out of scope as well as taking all of your workstations out of scope as well.

      • 205 Bill
        July 12, 2016 at 10:45 AM

        Hoping you can help clarify, so a computing is being used to access a website over HTTPS TLS1.2 to enter CHD, the computer itself is in scope, but the computer does not need to be firewalled off from other computers or devices on the network? The TLS connection providing the segmentation isn’t clear to me.

        Thanks!

      • July 13, 2016 at 5:26 AM

        The TLS connection segments the computer from the network when the cardholder data (CHD) is transmitted. However, TLS does not segment that computer from the rest of the other computers on that network segment. That is where the firewall comes into play. That firewall can be software-based on the PC or a hardware firewall on the network.

      • 207 Bill
        July 22, 2016 at 1:00 PM

        So, if the only CHD a workstation handles is what’s being entered into a secure website accessed over TLS, does it need to be segmented via a firewall to keep all other workstations on that same network out of scope? If yes, I assume then that no matter what, any other system (Domain controller, print server, etc) that the workstation needs to be able to talk to would also be in scope?

        Thanks!

      • July 26, 2016 at 7:53 AM

        You can use the Windows Firewall as the firewall for the workstation. That and the TLS session will protect the CHD. Any supporting systems such as domain controller, AV central system, printers, etc. would all be in scope, but would only be assessed for PCI requirements that made sense based on the risks they present to the workstations. For example, domain controllers present a huge risk and would be assessed for all relevant requirements, but a printer might be considered a very low risk and could be assessed with just vulnerability scans.

  73. 209 Chin
    June 1, 2016 at 8:36 PM

    Hi PCI Guru:

    I read your post and I think you did a very great job! I have a question on requirement 8.2.2. What if the company is a small company and everyone know each other. What is your recommendation or suggestions to meet this requirement? Further do you have any good reference or link to test data?? Thanks!

    • June 6, 2016 at 9:47 AM

      You still need to do something to comply with 8.2.2 other than stating, “we are small and know each other.” The reason is that you may not always be small. Even if you put the last four characters of a person’s social security number, last four characters of a driver’s license number, etc. in your user’s help desk record. That would satisfy 8.2.2.

  74. 211 Christopher Kennedy
    May 24, 2016 at 5:20 AM

    When you log onto a an open, unsecured guest network like starbucks, and lets say you busy something online and enter CHD, how can Starbucks maintain PCI compliance if they are providing an unsecured access point to potentially allow individuals make credit card payments over their network. If they segment their CDE and isolate the guest wireless from their CDE, is that sufficient?

    • May 24, 2016 at 5:51 AM

      That wireless network is not on Starbuck’s network, it is a separate network owned and operated by AT&T. A lot of retailer’s open wireless is operated by third party carriers and never connect to the merchant’s network.

      That said, it is acceptable for a merchant to have a separate, secured VLAN for customer wireless that never comes into contact with the merchant’s CDE. You would have to monitor that network to ensure that it is not in contact, but it would be acceptable.

      • 213 Sebastian Nielsen
        July 25, 2016 at 9:18 PM

        I can clarify OP’s question:

        What he asked, is like this:
        If I, as a customer, go on Starbucks Wifi, and then navigate to a unsecured shopping site (that are not affliated with Starbucks), that are accepting credit card data without SSL, and this then results in CHD being transmitted over the unsecured Starbucks Guest Wifi from customer –> the unsecured shopping site, without encryption, and Starbucks’s out-of-scope network now, because of a customer and a non-compliant merchant site, did transmit cardholder data, what are the Starbucks PCI Compliance problems then.

        I would say none, because Starbucks PCI compliance is not affected because that transmission of cardholder data was not because a problem on Starbucks end, but a problem on the unsecured merchant’s problem, and Starbucks does not have any obligation to prevent this.

        Another comparision:
        Merchant A operates a CDE, and a isolated, separate guest Wifi, intended for customers. The guest Wifi is out of scope (Category 3).
        Merchant B, that is a neighbour to Merchant A, have on their own, without asking Merchant A, connected their wireless payment terminals to Merchant A’s guest Wifi.
        Even if Merchant A’s out of scope network transmits (unencrypted) cardholder data belongning to Merchant B, its not Merchant A’s problem, and thus does not bring Merchant A guest wifi into scope. Merchant B however, is going to lose their aquirer agreement pretty quick.

        A third comparision:
        A merchant uses Dropbox to store cardholder data, even tough dropbox’s storage servers are classified as out of scope on Dropbox’s end. Dropbox is not going to have any PCI compliance problems, even if they are affected by PCI DSS for accepting payments to increase storage space, but the merchant have big problems.

      • July 26, 2016 at 7:48 AM

        In the case of Starbucks and most merchants offering free Wi-Fi, those networks are not connected to the merchant in any way. In the case of Starbucks, Hard Rock Cafe and many others, AT&T or another carrier provides Wi-Fi independent of the merchants’ internal network. So it does not affect the merchant’s PCI compliance whatsoever.

        However, if the guest Wi-Fi is provided over the merchant’s infrastructure, it needs to be logically or physically separate from the rest of the merchant’s network(s) to be judged out of scope for PCI.

        Where we do run into problems is where a corporation provides cafeteria, coffee, parking, dry cleaning and other services that are operated by various third parties. Those third parties use their own POS solutions on the corporation’s network or private Wi-Fi and are not necessarily separated from the general corporate network. What we typically recommend, at a minimum, is that the corporation create a vendor VLAN that is separate from their corporate network and that the VLAN be encrypted. There are other solutions that can be implemented, but those can increase costs substantially and may result in the corporation being judged a service provider.

      • 215 Sebastian Nielsen
        July 26, 2016 at 8:47 PM

        Thats another thing if the merchants are related to each other via some sort of agreement.
        And the OP was just asking a general question about Guest Wifi’s in general. We know that Starbucks wifi are operated by a third party, now, lets assume its a general Guest Wifi operated by the merchant itself.

        What the OP was asking was basically this (reworded the question heavily):
        I think you are still not understanding the original OP’s question.

        ——–

        Merchant A does have a CDE, and a logically separated Guest Wifi, everything is separate and firewalled in multiple layers so the Guest Wifi and CDE is completely isolated from each other.

        No traffic ever can travel between these. Everything so far is good, and the Guest Wifi is out of scope.

        Lets assume that the Guest Wifi even have a separate WAN connection, so the CDE and Guest Wifi is really really separate from each other.

        ——

        Next door, there is a competitior, Merchant B. Merchant A and Merchant B is not related to each other in any way, and they don’t provide any services to each other in any way. They are completely foregin to each other, and are competitors.

        Now, Merchant B, don’t care about PCI DSS, and then Merchant B connects their CDE equipment (terminals etc) to Merchant A’s out-of-scope and unencrypted Guest Wifi, just because this Wifi happens to have the strongest signal, and then Merchant B configures their CDE to transmit cardholder data completely unencrypted, just because Merchant B don’t care a shit about security.

        Whats happening now, is that Merchant A’s out-of-scope Guest Wifi, is transmitting unencrypted cardholder data belongning to Merchant B, over the air, everything without any agreement or permission from Merchant A.

        Its clear that Merchant B is violating the PCI DSS on basically every point that can be found.

        What the OP is asking now, is:
        Does the action of Merchant B, cause Merchant A’s Guest Wifi to be bringed into scope from Merchant A’s point of view.
        Eg, will Merchant B’s PCI DSS violation, affect Merchant A in any way?

        And here, I would simply say no, as Merchant A cannot execise any form of control over Merchant B.

      • July 29, 2016 at 9:46 AM

        If Guest Wi-Fi is truly segmented, the merchant is not responsible for anyone that uses it foolishly for transmitting sensitive information such as SAD/CHD.

  75. 217 Bill
    May 20, 2016 at 10:40 AM

    Hello, would like your opinion about charged off/closed credit card accounts. If a debt purchasing company buys a portfolio of charged of credit card accounts, are those PANs still in scope of PCI?

    • May 20, 2016 at 1:06 PM

      Sorry, but the Council and the card brands will all tell you that PANs are PANs and need to be protected. Even PANs of closed accounts and those on “Hot Sheets” are still in scope. The reason is that those closed and Hot PANs can be put back active at a moment’s notice by the brands.

      The only PANs that have ever been officially designated out of scope are test PANs issued to payment application software developers, processors and merchants. Those have been officially assigned as test accounts and can never be used to make payments.

      • 219 Bill
        May 20, 2016 at 2:35 PM

        Thank you very much for the input. I’m curious on your thoughts about FAQ# 1038 regarding closed/inactive accounts. If the debt purchaser could get the seller to contractually attest that the PANs of the accounts being sold could never be reactivated, would that take them out of scope for the purchaser? Or is it not even possible for the seller to guarantee that?

        Thanks again for your insight!

      • May 20, 2016 at 2:48 PM

        Only the card brand that controls the PAN can provide such a statement and, I can tell you from experience with other organizations that tried the same tactic, that will never happen.

  76. 221 Chase
    May 18, 2016 at 1:14 PM

    In a PCI DSS 3.1 context, what is meant by ‘remote access’? Is this non-cde to cde? Access over public networks? Or access from a network not within the scope of the PCI assessment (even if it’s owned or managed by the assessed entity?) Or other?

    • May 19, 2016 at 6:26 AM

      “Remote Access” in requirement 8.3 in the v3.1 context is in reference to any user (employee, contractor, service provider, etc.) that is not on the organization’s internal network and is attempting to access the organization’s cardholder data environment (CDE).

      So for example, an employee is on a VPN connection from their home to perform some support task. In order to gain access to the CDE, that employee must have used two-factor authentication (2FA) to obtain that CDE access. 2FA could have occurred at the time of their VPN authentication or as part of their access to the CDE.

      This is the change that is coming with v3.2 (best practice until July 1, 2018). Under the v3.2 of the PCI DSS, requirement 8.3 will require organizations to implement 2FA at the entry to the CDE so that any user (internal or remote) will have to use 2FA to gain access to the CDE.

      • 223 Scott
        August 16, 2016 at 7:49 AM

        Hello, Isn’t this all in regards to Remote Access VPN? What about an Internal LAN (not DMZ) authenticated and authorized user (someone sitting at their office desk) having access through Site-to-Site VPN encrypted tunnel thru a Gateway to an segregated offsite CDE . Would this require 2FA or not, I am assuming that since the CDE is already segregated and has FW, AD, ACL, etc.. protecting it from unauthorized users, it should be treated as local access, correct?

        Here are two good articles on this subject. first a great explanation from CISCO on the definition of VPN and the two types: Remote access VPN vs Site-to-Site VPN gateways. the second article is from Secureworks on the same topic but from a PCI DSS perspective.

        http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14106-how-vpn-works.html

        https://www.secureworks.com/blog/general-pci-dss-two-factor-authentication – (see When is Two-Factor Authentication Required)

      • August 18, 2016 at 9:11 AM

        With v3.2 of the DSS, anyone with administrative privileges such as system administrators or DBAs, are required to access (local or remote) the cardholder data environment (CDE) using multi-factor authentication. I have also heard from some acquiring banks and processors that they also include users that have access to bulk cardholder data in this group of requiring multi-factor authentication to access the CDE. The reason for the change to the DSS is to reduce the ability of Target and Home Depot style breaches where administrators were socially engineered and their credentials used to access the CDE. With multi-factor required at all times to access the CDE, the attacker would also have to compromise the multi-factor solution in addition to having the administrator’s credentials.

  77. 225 Joyce
    May 12, 2016 at 8:22 PM

    Hi there – we are having a debate and our organization has not be asked to be PCI compliant by third parties as we store only PAN but that is it. Are we still required to be PCI compliant? If yes where does it state if we are not a merchant or service provider we need to be compliant?
    Thanks

    • May 13, 2016 at 5:06 AM

      Page 7 of the PCI DSS, second sentence states, “PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.” I would say that your organization would be included in “all other entities that store”.

  78. 227 Owen
    May 12, 2016 at 4:43 AM

    Hello.

    Just a quick question about penetration test reports….

    I’ve been asked to look at a penetration report to let management know whether the work that was conducted is thorough and adequate and that the action plan is complete.

    When i looked at it, the scope of the report covered everything i’d expect to see for example “password complexity/security” but because nothing was found to be wrong with the passwords, there is nothing written in the report about it as the report only lists problems…so now i can only draw two conclusions:

    1. There isn’t anything wrong with the passwords e.g. no defaults etc. although i have no evidence this is true.
    2. They didn’t do the work!

    I find reporting only on the negative strange as it never includes a “work done” section so nobody can see exactly what was examined or what methods were used.

    Is this a normal way to report and if so, how can you place reliance on it besides company reputation?

    Thanks,

    Owen

    • May 12, 2016 at 6:09 AM

      This is the way a penetration testing report is typically written. Only the issues found are reported. So if it is not documented in the findings, then you can assume it was tested and no issues were found.

  79. 229 Dan
    May 11, 2016 at 7:41 PM

    Great site! I am considering getting an ISA certification. I know QSAs are required to have liability insurance but do you recommend ISAs obtain liability insurance as well? Could an ISA be held personally liable, whether they perform a self-assessment or assist a QSA in their assessment, in the event the ISA’s organization’s CHD were breached?

    • May 12, 2016 at 6:11 AM

      As an employee you would be covered under your employer’s business liability insurance policy regardless of your role in the PCI assessment process.

  80. 231 Alm
    May 9, 2016 at 4:56 AM

    Hi thanks for the great resource.

    We fully outsource all cardholder operations to our processor and are in the process of completing the SAQ-A 3.2 document. We are a bit confused because the doc requests us to comply with Requirements 2, 8, 9 – but the way the questions are worded suggests that the scope of these requirements applies ONLY to the cardholder data environment, which wouldn’t apply to us. For example it says “Are all users assigned a unique ID before allowing them to access system components or cardholder data?”

    As I mentioned, we fully outsource everything and don’t see any card data. Should the answers to the questions be all marked as N/A ?

    • May 11, 2016 at 8:05 AM

      While you may fully outsource your environment, you are saying that none of your employees have any role in managing and maintaining that outsourced environment? Even if you are using PayPal, some of your employees will have access to the PayPal system for handling disputes and chargebacks. It is those accounts to outsourced applications that SAQ A applies.

      • 233 Alm
        May 11, 2016 at 10:52 AM

        Thanks,

        I agree with you BUT the outsourced card company tells us that the PAN information is NOT visible to any user of the chargeback or any other platform. Therefore, the employee is not exposed to Cardholder data…

      • May 12, 2016 at 6:13 AM

        If the full PAN is not available to the user of the application, then from your organization’s perspective, the application is not in scope.

      • 235 Bob P
        May 12, 2016 at 9:10 AM

        Hi Guru, do you not think these new requirements apply to the web server that is performing the redirect to the third party payment site? When I first read the changes, I assumed it was to further protect the web server redirect versus protecting the data stored on third party payment sites.

      • May 12, 2016 at 10:43 AM

        It applies to all PCI in-scope systems be they the Web server doing the redirect or for the merchant’s systems that access the third party applications that process payments.

  81. 237 Ryan S.
    May 6, 2016 at 1:55 PM

    I have been struggling with the concept of redirection and was wondering if you could provide some clarity. If I place a hyperlink on my public website to a 3rd party eCommerce site that collects user information and in turn redirects the user to a 3rd party payment site to enter and process the credit card transaction, is my public web server in scope as a redirection server? I guess it boils down to the question, “is a hyperlink a redirect?” The public website only provides general information and a link for customers to pay a fee.

    • May 8, 2016 at 8:47 AM

      A hyperlink to a payment page is a valid redirect. According to the PCI SCC, that means that your public Web site is out of scope.

      HOWEVER … While that is the PCI compliance side of the equation, it is not the information security answer. The risk is that if that hyperlink gets modified and starts sending your customers to a malicious payment page, who is at fault? The answer of course is your organization. So I tell my clients taking the redirect approach that they still need to vulnerability scan at least quarterly and penetration test at least annually. They also need to monitor the hyperlink so that if it ever changes, they get an alert of that change. They also need to collect log data from that server to monitor it as well.

  82. 239 Ash
    May 5, 2016 at 5:01 PM

    Hey mate,

    Quick question about requirement 11.5 and 11.5.1 – FIM!!

    If an organisation has their entire network in scope e.g. agent terminals, servers etc. etc. and they are not storing any card-holder data, do they still need FIM on all their end-points and in scope servers? to monitor critical OS files etc.

    Also, if not FIM what alternate automated / manual controls may suffice or is FIM mandatory?

    Appreciate your help.

    Cheers,
    Ash

    • May 8, 2016 at 8:57 AM

      You may not be storing cardholder data (CHD) but you are obviously processing and transmitting it if your network is in scope. So your systems have CHD in their memory and it traverses your network. File integrity monitoring (FIM) or similar solutions are used to minimize or stop unapproved changes to files or adding files to systems that are malicious but not stopped by anti-virus solutions. However you choose to implement such a capability, you need to generate alerts so that you can stop the malicious files before they do too much damage.

      • May 10, 2016 at 12:00 PM

        Hi PCIGuru

        We have an Android and Apple application which registers members into our loyalty system. Part of the process is to register their card information in order to track their transactions. This is done via a Spreedly solution. We are looking at utilising a USSD application (under scope at present) to do the same. We however need to find a solution to transmit their card pans via the USSD application to Spreedly in a PCI compliant manner. The company which will be handling the database is not PCI compliant, so we are looking for a solution to this. Any suggestions?

      • May 10, 2016 at 5:13 PM

        The problem you are going to have is the Windows/Android/iOS issue of keyboard logging. Any manual data entry into such mobile devices is going to be recorded by that device and stored in memory for a length of time until overwritten. As far as I am aware, there is no way for a developer to disable this feature on those mobile devices. Payment solutions such as those from Verifone, Square and the like avoid this by encrypting the cardholder data (CHD) at the swipe/dip of the card. However, even these solutions warn users that manual data entry of CHD will be recorded by their mobile device. This is why the PCI SSC has consistently stated that mobile devices will never be considered PCI compliant.

  83. May 5, 2016 at 8:55 AM

    Hi PCI Guru

    We are using company A (who have informed us that they are PCI compliant) to scan paper forms containing supporter details as well as CC numbers. They scan the forms and hide the middle 8 digits for us to then attach them to supporter records on our CRM. They then send back all the hardcopy forms with the full CC details still on the forms leaving us to manually remove them appropriately before placing into storage.

    Can you tell me if PCI compliance covers returning physical forms back to us? Should the CC number be redacted by Company A before returning (by post) to us for archiving?

    Thanks,

    Taruna

    • May 8, 2016 at 9:05 AM

      First, you need to get Company A’s PCI Attestation Of Compliance (AOC) to have absolute proof that they are PCI compliant. Having a third party tell you they are PCI compliant is not good enough.

      Paper forms are also in scope for PCI compliance. But redaction of sensitive authentication data (SAD) and cardholder data (CHD) from forms is not as simple as you may think. In order to securely redact SAD/CHD from forms, you must take a black Sharpie marker and black out the PAN to the first six and/or last four digits. Then you need to take a photocopy of the original form, retain the photocopy and securely destroy the original. If you do not do the photocopy, the redaction of the PAN can still be read by holding the original form up to a bright light.

      Whether you get the third party to do the secure redaction of the PAN your you do it is up to your organization to determine.

  84. 245 Jon
    May 2, 2016 at 10:25 AM

    Hello PCI Guru. I’d like to get your update regarding 2 entirely different things:

    1) What if an HSM which was certified in the past as an PCI Certified device is being used after the EOL was reached? It is not obviously certified and is also failling the requirement 6 of having systems constantly updated as vendor releases. How would be an acceptable solution for you in terms of migration plan ans PCI compliance?

    2) How do you manage companies that are not able to fulfill the quarterly pass scan from an ASV? I mean, somebody who don’t hae the 4 required scans but at the time of the certification, the last scan is OK.

    Thanks a lot for your opinnion on this!

    Have a nice day!

    • May 3, 2016 at 8:42 AM

      The Council has come back and said that out dated an unsupported software, hardware and appliances are acceptable but will required compensating controls to meet the PCI requirements. So that is how to deal with the HSM situation. That said, you can encounter situations such as with Windows 2000 Server where the compensating controls just cannot be put in place to address all of the issues with Windows 2000 Server.

      You would have to come up with compensating controls for the three quarterly scans that failed.

  85. 247 Bob P
    April 29, 2016 at 12:15 PM

    Hi Guru, I want to understand your opinion on network segmentation and SAQ A environments. Does the web server executing the redirect to a third party site – like Cybersource, payPal – have to be segmented/isolated? I know there are still risks so having controls that exceed SAQ A are recommended, but i am interested in the network segmentation approach for validation.

    thank you.

    • May 3, 2016 at 8:45 AM

      That would be an excellent idea, but it is not required with SAQ A. Even if you are in an SAQ A situation, in my very humble opinion, you should follow SAQ A-EP’s guidance to ensure security.

  86. 249 Greg Crowe
    April 29, 2016 at 8:54 AM

    HI PCI Guru, i am currently restructuring our PCI service provider support network and wondered if you could help me clarify something?
    We use McAfee AV and have agents on 20 servers and 100 workstations that send and receive information to the central McAfee ePolicy Orchestrator. This central server is not located on the PCI network, it is situated in a datacentre on its own network behind a firewall on a hardened server and it only sends and receives https traffic from the PCI network. Is the ePolicy Orchestrator in scope and does having it located outside of the network but my compliance in jeopardy?
    Any advice would be greatly appreciated!

    • April 29, 2016 at 9:52 AM

      Yes, your McAfee ePolicy server is in-scope for PCI because it connects to systems that are in your cardholder data environment (CDE). That said, do not despair. It is NOT the end of the world. It all comes down to how you are managing the risk of that McAfee server in regards to the CDE systems. You have a firewall that separates your McAfee system from the CDE systems. It sounds like the rules on the firewall sufficiently restrict traffic in/from the CDE. The question would be how/what you monitor on that firewall to ensure that the McAfee system does not contaminate any systems in the CDE should it become compromised.

      If that risk is unacceptable to your organization, then you will likely want to implement a separate ePolicy server inside your CDE.

  87. 251 David Grow
    April 26, 2016 at 7:52 AM

    I have a general question. I’m not sure if you have addressed this before. In the executive summary section of the ROC it asks for critical hardware and software. This seems to be an ambiguous request as what is deemed critical might differ from one person to the next. What is your opinion on what should be included?

    Thanks for any insight.

    DG

    • April 28, 2016 at 3:00 PM

      If the hardware and/or software was deemed in scope for assessing it, then it belongs in those lists.

      • 253 David Grow
        April 29, 2016 at 11:52 AM

        Isn’t that in essence the system inventory in 2.4?

  88. 254 Derek
    April 21, 2016 at 11:44 AM

    Hi PCI Guru, thanks for the updates on this website, as I can tell from the many comments you’re offering a great service to many.

    A comment around DUKPTs was made to me around PCI, and I haven’t been able to find a definitive answer and hoping you might have it.

    The comment was that although a lot of terminals can support multiple DUKPT keys for PIN encryption that PCI limits all terminals to use only one – do you know if this statement is indeed true?

    • April 25, 2016 at 8:33 AM

      Working on a DUKPT post as you are not the only one with questions. That said, multiple keys per merchant is a function of the transaction processor. So you will have to ask your processor if they support multiple keys. It is not a restriction of the protocol that I am aware.

      • 256 Derek
        April 26, 2016 at 11:16 AM

        Thanks for quick reply.

        If the merchant has multiple transaction processors, do you know if PCI limits to requiring only 1 DUKPT? or could we have a different DUKPT key for each processor loaded in a device?

      • April 28, 2016 at 2:54 PM

        You would have to have a different key for each processor and each processor would have to inject those devices before their use.

  89. 258 Bill LaFleur
    April 15, 2016 at 11:16 AM

    We are having a bit of an internal debate and I’m hoping you can help us decide either way. We have a service provider that is refusing to go through the effort of an assessment. So under 12.8 we feel it is necessary for us to invoke the audit clause of the contract and perform the assessment ourselves. The question that’s come up is are we allowed as ISA’s to go onsite and assess the service provider or must we pay for and bring in a QSA to perform the assessment? Some feel that technically as an ISA you can only assess your own company and therefore the Council would prevent one from looking at another company, even a service provider that has your data. What are your thoughts?

    • April 15, 2016 at 11:57 AM

      If you feel your ISAs have the skills necessary to assess the service provider, I would argue that you can do that assessment. Where I have seen QSAs used is when the service provider is using technology that the ISAs do not possess such as mainframe or UNIX for example. The Council does not required that a QSA assess third parties. The only requirement for using a QSA is if the service provider is looking to register with Visa or MasterCard on their Global Service Provider lists.

    • 260 PeCulIar DoSSier
      May 5, 2016 at 12:18 AM

      Are the requirements laid out in PCI DSS 3.1, control level requirements or policy level requirements?

      • May 8, 2016 at 9:06 AM

        Both. But it depends on the requirement and testing of the requirement.

  90. 262 JHP
    April 13, 2016 at 2:28 PM

    Hello, I am fairly new to the Payment Card Industry but I had a question in regards to PTS approved devices on the pcisecuritystandards.org website. How come some devices are listed as SRED CTLS while some devices are listed as SRED NonContactless? How would Contactless be handled in order for a Payment Terminal to become SRED Compliant? I believe there was a change from PCI PTS v3 to PCI PTS v4 but I am unable to track down reason.

    • April 15, 2016 at 12:02 PM

      My guess is that the difference is that the device manufacturer did not submit the contactless feature of device for PTS certification. I will contact my PTS expert to confirm that though.

    • April 16, 2016 at 7:25 AM

      Here is the “official” answer from Andrew Jamieson at UL that does PTS certifications.

      “Regarding your question, the answer is a bit complicated. SRED was introduced in PTS v3 but there was a ‘grandfather’ period for SRED on v2 devices for some time (about 1 year from memory). The specific requirements for contactless physical security were not enforced immediately and so there was a (very) small window when some devices were approved to SRED without the assessment of the contactless _physical_ security. Such devices may not be listed as having contactless SRED features.

      Additionally, the listing of the ‘functions provided’ was not something done until some way through v3, when a changenwas made to the webaite listings, and although the person in PCI responsible for sorting the listings out has done a stellar job going through all the old reports to figure out what does what there is the chance that some devices listed prior to this time may be listed incorrectly.

      Finally, and quite simply, not all devices provide contactless options, or (for reasons unknown) they may disable the contactless in their PCI approved firmware during submission. One of the most important changes in v4 of PTS (IMHO) is the Security Policy which helps to sort out a lot of these issues and make much clearer to the merchant / acquirer what exactly the sort device does and what was assessed.”

  91. 265 luc
    April 6, 2016 at 10:50 AM

    Thank you so much for having a very informative website. I’ve read through most of the questions others have posted, and your replies, but just wanted to double check.

    If our workstation which has a P2PE usb device for credit card swiping, where it sends the encrypted data directly to our processor (in other words, the workstation does not have access to the data) and our company does not have access to decrypt the keys, then would both our workstations and network be out of scope?

    In addition, would it be out of scope in that there is no need to monitor the logs daily, integrity of the systems, requirement of a penetration test?

    Thank you in advance for your help.

    • April 7, 2016 at 6:05 AM

      First, are you absolutely sure that your solution is point-to-point encryption (P2PE) validated? I cannot tell you how many times we talk to clients/prospects that tell us they have a P2PE solution only to determine that it is an end-to-end encryption (E2EE) solution. Do not feel bad as a lot of vendors’ sales people pawn off these wonderful P2PE white papers that confuse people into thinking the solution has been P2PE validated when in fact it has not been through the process. The bottom line is, if you cannot find your solution on the PCI SSC Web site (https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions), then it has not been P2PE validated. Not that it is the end of the world, it just means that you have some additional work to validate that your E2EE solution is acceptable and reduces scope.

      Assuming that you do have a P2PE validated solution. You need to prove that you implemented it exactly as documented in the solution’s Implementation Guide (IG). Assuming that you did the implementation properly, then only the point of interaction (POI), i.e., card terminal, is in scope. Everything else will be out of scope and the only requirements your organization needs to comply with are documented in SAQ P2PE-HW.

      If you review SAQ P2PE-HW, you will see that there are no requirements for vulnerability scanning or penetration testing of the POI.

      NOTE: All of this of course assumes that you have no other payment channels that would increase your scope outside of those requirements.

      • 267 luc
        April 7, 2016 at 10:44 AM

        Thank you very much for the reply, Actually it seems that one of our dept is using Shift4’s solution, which isn’t a validated P2PE. Shift4 isn’t on PCI SSC list, and they actually have some info on their list as why they are not, but I’ll have to look into that further. unfortunately, that dept already signed the contract with the company. On the bright side, we have another dept that will be using BlueFin’s solution, which is on the validated list.

        Thank you very much for clarifying the scoping information, and for the info on the SAQ. as you’ve said, it really reduces a lot of scope, and also, i’m hoping it reduces the risk as well.

        Cheers PCI Guru!

      • April 7, 2016 at 12:19 PM

        Full disclosure. Shift4 is a former client of my company and I have worked with them for a number of years. So I know quite a bit about their company as well as their solutions. In addition to the fact that I and others at my employer have implemented their E2EE solution.

        There is nothing at all wrong with the Shift4 solution as it is just as secure, if not more so, than some of those validated P2PE solutions. This is the reason why P2PE is a somewhat questionable and what I believe to be useless standard. There are plenty of E2EE solutions from major vendors such as Verifone, First Data and others that could be P2PE validated but are not because the vendors do not see the value provided to their customers for such an assessment. In the opinion of most QSAs, there is only slightly more additional work required with an E2EE solution to get the same scope reduction that you get with a P2PE validated solution.

  92. April 6, 2016 at 9:14 AM

    how to use workstations, compliantly …

    we host a page, that send cards to a PSP to be tokenised. That’s all good … We also have staff call our customers, then use our workstations to enter cards (on behalf of the customer) onto this same site. Less good.

    How can i minimise my scope in these areas, even remove the workstations and telephony all together (or at least keep them segregated from the broader network), when they depend on common systems like Active Directory, AV, patching, etc ?

    • April 7, 2016 at 6:08 AM

      Your only way to totally minimize your scope is to outsource your manual call center work to a third party call center. Otherwise, those workstations and the connected systems are all in scope.

  93. 271 Kevin
    March 31, 2016 at 10:02 PM

    I have question about “1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.”

    For e-commerce the solution is pretty clear. What about a sales person that uses their PC to research potential clients and take payments? The test criteria imply a route/firewall is doing the limiting authorizing, but could a A/V product with anti-phishing capability fill this role?

    • April 1, 2016 at 10:32 AM

      Only if the anti-virus solution provides a personal firewall capability as with Symantec, Trend Micro and the like. Anti-virus, anti-malware, anti-phishing solutions alone do not meet the requirements in 1.3.5.

  94. March 28, 2016 at 8:36 AM

    What is credit card “service code” under CHD? Not the CVC under SAD. Thanks.

    • March 28, 2016 at 9:26 AM

      Per the definition in the PCI Glossary, service code is defined as:

      “Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the track data. It is used for various things such as defining service attributes, differentiating between international and national interchange, or identifying usage restrictions.”

      This value is NOT the CVV/CVC/CID. It is an entirely different value used by the card brands, processors and banks. See https://en.wikipedia.org/wiki/Magnetic_stripe_card for the layout of the various track data that can be on a magnetic stripe. Also remember that EMV has its own rules but also stores the same track data for consistency with the magnetic stripe.

  95. 275 PeCulIar-DoSSier
    March 28, 2016 at 1:01 AM

    How are the big banks doing w.r.t PCI Compliance?

    • March 28, 2016 at 7:42 AM

      Huh? Sorry, couldn’t resist. Most banks are in denial regarding PCI compliance. I wish I had a dollar for every one of the banks I have dealt with that said PCI was for merchants only. Then you go through the PCI DSS and point out that it says:

      “PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Below is a high-level overview of the 12 PCI DSS requirements.”

      That said, banks (at least those in the US) are the least problem of the card brands for breaching of data. That is because the banks are under the scrutiny of the FDIC, OCC, NCUA and other regulatory agencies. All of these agencies focus heavily on the security of all financial data, not just cardholder data. As a result, the banks are much more rigorous in their security efforts than merchants and other service providers.

      However, the card brands have come around and are looking at PCI compliance within banks more and more. As a result, we are seeing more and more financial institutions requesting PCI gap assessments to determine their level of compliance.

      • 277 PeCulIar DoSSier
        March 30, 2016 at 5:06 AM

        Any Big Banks that are PCI DSS Certified?

      • March 30, 2016 at 5:12 AM

        No one is ever PCI DSS “certified” because the assessment process is not an audit. Anyone assessing themselves to the PCI DSS is judged “compliant” or “non-compliant”.

        I know of a number of regional banks that are PCI DSS compliant for their ATM networks, transaction processing and their card production operations. I also know that a lot of banks are going through PCI DSS compliance analyses to determine gaps and how to remediate those issues. Whether or not all of the banks in-scope operations have been assessed I have not seen or been privy to those efforts.

      • 279 PeCulIar DoSSier
        March 30, 2016 at 5:09 AM

        Are any of the BIG Banks PCI DSS Certified?

      • 280 PeCulIar DoSSier
        March 30, 2016 at 8:38 AM

        I think the biggest challenge for a PCI DSS Compliance exercise is scoping. If you have to start with say identifying all credit card data flows, this As-Is assessment itself could go on for ages. Also the organization’s card processing/storing/transmitting environment could be in a constant state of flux. So you are actually trying to get a hold on a “Moving Target”. How do you plan an “Identify all credit card data” exercise especially with a Big Bank?

      • March 30, 2016 at 11:49 AM

        You do the best you can knowing that issues will come out of the woodwork. I cannot tell you the number of times in very large organizations where towards the end of an assessment they acquire something or a new operation is found where cardholder data (CHD) is involved. All you can do is to draw a line and save the new stuff for the next assessment. Otherwise you will truly never finish.

  96. 282 Kevin Hinterberg
    March 21, 2016 at 1:25 PM

    Hi PCI Guru,

    Does PCI Requirement 8.2.4 “Change user passwords/passphrases at least once every 90 days.” apply to service accounts? I apologize if this is a stupid question, but I haven’t found any good information online. I would think it does since service accounts can pose a large security risk, but the requirement specifically says the word “user”. Your help is greatly appreciated, and I have been reading your site for a long time.

    • March 25, 2016 at 7:27 AM

      As long as those service accounts cannot be used by someone to logon, then they do not have to change unless the organization feels that those accounts might have been compromised.

  97. 284 RJSK
    March 16, 2016 at 10:50 AM

    Hi PCI Guru,

    Your website is excellent and extremely helpful.

    I’m querying cloud based software and Saas iPOS payment acceptances. Do they need to be PA-DSS approved? If the SAQ has been determined as an SAQ C, does a quarterly scan need to be scheduled with the business locations IP address and the software providers?
    Also would the Eligibility to complete the SAQ be affected because of this?

    Cloud computing is a bit out of my expertise and would like an opinion on the above if you can provide one.

    Kind regards,
    RJSK

    • March 21, 2016 at 7:19 AM

      Yes, any payment application that is hosted and sold as a service is required to be PA-DSS validated.

      SAQ C would require the quarterly external and internal vulnerability scanning of the external facing firewall and internal devices to ensure that they are patched and secure.

      I am not sure what you are asking me about “Eligibility to complete the SAQ” being affected by scanning. I would have to know much more about the environment.

      The Cloud can be PCI compliant, but it all depends on the configuration of that environment. No different than any other computing and networking environment.

  98. 286 Deli
    March 15, 2016 at 11:46 AM

    Hi Guru,
    first, thanks for this great blog! I know you have responded to questions about virtual terminals and payment portals in the past. My question is about acquirer or card brand subsidiary provided portals for chargebacks or fraud detection.
    These portals are the only means for our sales audit and loss prevention teams to view chargeback or fraud detection information. Access to these portals is controlled by the acquirer or the card brand subsidiary through issuing and revoking of IDs and passwords. Once logged in to the portals, a very limited number of our staff can display one transaction at a time with the cardholder name, address and full PAN. No SAD is displayed. These portals can be accessed from anywhere and any device provided one has the appropriate credentials. So, the question: as a merchant, are we required to attempt to secure any and all workstations/devices used to login to these portals or is it sufficient to have policies in place that govern the appropriate roles, responsibilities and use of these portals? I don’t know that we could possibly secure all devices anyway given an employee with portal credentials could login from home or any public computer available to them. Your guidance is appreciated.

    • March 29, 2016 at 5:45 AM

      These portals for dealing with chargebacks, settlement. fraud and other transaction issues are in scope for PCI compliance from the merchant side. However, all of these portals that I have encountered use HTTPS to secure their communications, so only the PC, thin client or device accessing the portal is in scope for PCI compliance as the encrypted communications segregate its network connectivity. Therefore, those devices that access these portals need to be securely configured, securely maintained, patched current, have anti-virus, and require individual logons. If the operator of the portal wants to control where users can access the portal, that is on them, not your organization.

  99. 288 Jonno
    March 15, 2016 at 9:28 AM

    Hi PCI Guru,

    I’ve been following your site for a number of years and have to commend you for the effort you put into this site.

    I have a question in relation to the SAQ A I was hoping you could assist with. I work for an organisation that is looking to introduce a hosted payment page via to a payment provider, but due to the complexity in the setup I’m not exactly sure who’d complete the questionnaire. They are looking to have an agency run the store, and therefore provide their own store equipment, and a supplier to build the website that will then feed into the Hosted Payment page of a Payment Provider.

    I’m assuming the Supplier of the site would need to complete the SAQ A, but would the Agency, running the store, need to complete the SAQ A too or would this be the organisation I work for? As obviously the organisation would be setup with an account through which Merchant ID’s are assigned. Or is another form required for completion?

    Thanks for your help in advance.

    • March 21, 2016 at 10:42 AM

      There are merchants and there are service providers. The question is, “Who is the merchant of record?”

      If your organization is the merchant of record (i.e., it is your organization’s merchant identifier that is used to conduct all transactions), then your organization will be the one filling out the SAQ A. You will need service provider Attestations Of Compliance (AOCs) from the organization operating the retail location and the service provider operating the eCommerce Web site.

      If your organization is not the merchant of record and you just receive a share of the proceeds from the sales, then your organization is not in scope for PCI compliance.

      • 290 Jonno
        March 22, 2016 at 8:48 AM

        Thank you for the response.

        I presume you mean the organisation that owns the Merchant Account? As the Retail stores within would consist of separate Merchant ID’s.
        Would the service provider and operator need to comply with all the requirements witihin the AOC? Or is this requirements 9 & 12 only? As they are within the SAQ A that the organisation would complete.

        I imagine this is the AOC form? https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwiet8flw9TLAhWCOhoKHZZ8ABkQFghBMAE&url=https%3A%2F%2Fwww.pcisecuritystandards.org%2Fdocuments%2FPCI_DSS_v3_AOC_ServiceProviders.docx&usg=AFQjCNHxMLIIsGjfzOJk5XIPe02sT9xbMQ

        Would they audit/assess themselves or does this need to be performed by a 3rd party?

      • March 25, 2016 at 7:20 AM

        Yes, I did mean the entity to which the merchant identifier is assigned. That said, retail locations do not need to have their own individual merchant identifiers. Most retailers operate under a single merchant identifier regardless of the number of physical locations.

        The Attestation Of Compliance (AOC) is only the attestation form. A service provider must conduct an assessment that results in either a Service Provider SAQ D (less than 300K transactions processed) or a Service Provider Report On Compliance (ROC) in addition to the AOC. Those are the only two reporting formats allowed for service providers. In your example where the service provider is only involved in requirements 9 and 12, they would mark all the other requirements as ‘Not Applicable’ and the reason.

        Most service providers conduct their own assessments to avoid having every customer disrupt their operations conducting their own individual PCI assessments.

      • 292 Jonno
        March 29, 2016 at 8:38 AM

        Thanks PCIGuru, that certainly helps a lot!

  100. 293 Brad
    March 11, 2016 at 2:42 PM

    My company is using a third party service provider to monitor our CDE via IDS appliances. Their product works very well. However, my question is regarding audit logging on their devices. What type of logs should I expect to be captured, stored and reviewed either by them or myself? Again…I’m not talking to logging generated from the IDS monitoring my CDE traffic. I’m referring to the OS logs being generated for the appliance itself. It is my understanding that the appliances are running hardened versions of Debian or CentOS.

    • March 15, 2016 at 5:18 AM

      Logging on appliances is problematic at best sometimes because the underlying OS may be configured such that log data is either not available or what is produced is worthless. That said, what the appliance OS should be providing is log data that would indicate that the underlying OS has been compromised.

  101. 295 Albert
    March 9, 2016 at 11:50 AM

    Hello,
    This is my first attempt to post a question. So pardon me if something is not done correct.
    If 200 internal users are using third party designed, developed and hosted application for processing, do we have to count those transactions towards our annual # of transactions?
    Regards

    • March 9, 2016 at 1:49 PM

      If those transactions are done under one of your merchant accounts, yes they count as your transactions. That said, even if you are processing those on behalf of another organization under that organization’s merchant account, they count for you as a service provider.

  102. 297 mhc123
    March 7, 2016 at 12:26 PM

    Great blog! My questions relate to a host I’m segmenting as part of our CVE. It is an Interactive Voice Response (IVR) server callers use their phone keypad to enter credit card numbers, expiry and CVV. There are additional communications this server establishes with other internal hosts for non-credit card related purposes. These communications support the IVR functionality of the host. To be PCI compliant should these communications, using FTP for example, be secured/encrypted as well? Furthermore, do these hosts become part of the CVE since they communicate with a host that processes credit cards data?

    Thanks very much!

    • March 15, 2016 at 5:24 AM

      Systems connected to systems that are directly involved in processing, storing or transmitting cardholder data (CHD) or sensitive authentication data (SAD) are in scope for PCI compliance. However, that compliance will be based on how those systems are connected to the cardholder data environment (CDE). Systems that provide critical services such as directory, DNS, DHCP, anti-virus, administrative access and the like are going to have a very high risk that, if compromised, they would compromise the CDE systems. Other systems that provide only outbound access to the CDE such as log data collectors might be much less risky and therefore not need to meet all of the PCI requirements. This is the point of the Category 2 systems from the Open PCI Scoping Toolkit. I would recommend that you get a copy and see how its framework is configured for systems that connect to the CDE.

  103. March 4, 2016 at 5:58 AM

    Hello PCI Guru, love this invaluable blog, many thanks for the effort you put in. This might be a question with an obvious answer but I keep coming back with different interpretations each time I think about it so clarification would help.

    So my organisation has websites on a hosted platform used by customers and a web application on the same platform used by call centre staff. So the systems on the hosted platform form our primary CDE naturally and then the Call Centre operators and their computers also fall into scope of PCI DSS. We have a pair of perimeter firewalls protecting the hosted platform controlling internet traffic in and out and also controlling traffic from our internal network coming through an MPLS.

    We also have 2 firewalls on our internal network (one at each facility we have). These segment groups of computers by department. As the call centre computers have access to network file storage drives am I correct in thinking that this will pull the file server into scope and also all other computers on our network which also have access to those file servers despite the firewall rules not allowing access between the end user computers?

    What I would like to be able to do is limit scope on our internal network to just the computers used by employees who process payment cards and the system components that then provide their access to the hosted platform, however because everything else on our network shares some components I can’t quite picture how we could ever reduce scope on our internal network side. Any thoughts?

    • March 29, 2016 at 5:50 AM

      Your question is the reason why the PCI DSS requires network diagrams and data flow diagrams. Without those to review along with your firewall configurations, it is almost impossible to answer your question definitively.

      That said, what I can tell you is that systems that connect to devices/systems in the cardholder data environment (CDE) are in scope for PCI compliance. Therefore, you must remove connectivity to the CDE for all systems you wish to exclude from PCI compliance. Connectivity can be controlled through firewalls or other network devices that have the capability of blocking network traffic.

  104. 301 Simon
    March 3, 2016 at 5:44 PM

    Hi, this is a great resource.

    We have a sales team who each need access to our internal computer network. And they also need to be able to take card payments over the phone. We’re planning on using a web based virtual terminal for this.

    If I don’t want the entire network to be in scope, would each person need two computers? (One for virtual terminal access and one for everything else).

    If so, would a KVM switch be allowed (meaning we don’t have to double up on keyboards, mice and monitors as well).

    Any practical ideas for a team of approx. 7 with limited desk space?

    Many thanks.

    • March 29, 2016 at 5:52 AM

      As long as the payment process is conducted over a secure communications channel such as an IPSec VPN or HTTPS and your PCs, thin clients, etc. using that secure communications channel are security hardened, patched current and have anti-virus, then you should be fine.

  105. 303 Bryan Carter
    March 3, 2016 at 1:24 PM

    How should I respond to someone that states they did not file an Attestation of Compliance because their acquirer did not ask for one? What can I reference to show that they need to file regardless.

    • March 9, 2016 at 7:46 AM

      Yes, banks are also clueless at times about their responsibilities as well when it comes to PCI. Merchants and service providers are all required to create and file Attestations Of Compliance (AOC) with their acquiring bank (merchants and service providers that process transactions) and their customers (service providers). That said, in Section 1 of the merchant AOC it says, “Contact your acquirer (merchant bank) or the payment brands for reporting and submission procedures.” Section 1 of the service provider AOC states, “Contact the requesting payment brand for reporting and submission procedures.” I do not know how much clearer that can be.

  106. February 29, 2016 at 1:51 PM

    Greetings,

    Despite not being required to have a QSA review my organization, I think it is important to have an outside review of security measures I put in place.

    To that end, I would like to pick your brain about the best way to find a QSA. I know that the PCI website has a feature for finding QSA companies, but for the United States there are 173 choices. To me, that feels like looking for a needle in a haystack especially when I’m hoping to find a company somewhat local to me.

    Any suggestions?

    • March 1, 2016 at 5:40 AM

      My employer would find me remiss if I didn’t say to contact them. LOL!!!

      Being an organization that is doing a self-assessment questionnaire, I would find a qualified security assessor company (QSAC) that has an office and/or QSA close to you so that you minimize the cost of engaging a QSA. The next attribute is to find a QSA that you can work with and one that offers valuable advice, not how to “check the box”. While compliance with the PCI DSS is the goal, the ultimate goal is to make your organization secure. There are security actions implied in the PCI DSS that a QSA can clarify and explain.

  107. 307 Orion
    February 24, 2016 at 7:36 AM

    I have a question. If there is a environment serving for one of the customer issued cards {branded with VISA/ MC}. Proxy IDs {similar to 16 digit Card number} are available and is mapped to the 16 digit PAN. Whenever a customer calls in, they have to pronounce the Proxy ID to the customer care centre. When the proxy id is keyed in the application, it reveals the customer details & only last 4 digits of PAN. First 12 digits are masked.

    The question is whether the proxy ID will be under PCI DSS scope or not.

    • February 26, 2016 at 7:04 AM

      If what you call a ‘Proxy ID’ is not branded with Visa, MasterCard, American Express, Discover or JCB logo, then it is not cardholder data and is not covered by the PCI DSS and is therefore not in scope.

      This is no different from private label cards which are cards issued by retailers that look like credit/debit cards, but do not carry a card brand logo. However, because private label cards are no different from branded cards, I highly recommend that merchants treat them no different from the branded cards. That said, if your Proxy IDs can be used to gain access to customer’s funds or result in charges, I would recommend that you protect those numbers as well just as you would credit/debit cards.

      • 309 Marcos M.
        September 22, 2016 at 2:43 PM

        We are having difficulty identifying proxy IDs as a false positive for DLP since Luhn’s algorithm matches it to a real credit card number. Have you seen this behavior before?

      • September 26, 2016 at 10:10 AM

        Yes, I have seen this before. Any 16 digits that start with 3, 4 or 5 can end up passing the Luhn check when it is just random digits therefore creating all sorts of false positive results. Gets even worse with binary data if you are looking for that as well. This is what makes finding PANs such a pain in stored data. The volume of false positive results that must be sifted through. That said, I also found thousands of TIFF images containing PANs on a repurposed facsimile server just by luck because of what I thought were false positive results due to looking for binary values.

  108. 311 John Traweek
    February 22, 2016 at 8:43 PM

    First, thank you for the time you invest in all of your thoughtful answers. I am going to try and explain this the best way possible. We have a public web application (DMZ) that connects to a DB server (Inside). The two are separated by a firewall and the DB server cannot directly access the web server. This DB stores configuration information and biographical information that the app reads and writes to. No CHD is ever transmitted to or stored in this DB. The web app does provide card processing through various gateways, ie Authorize.NET, CyberSource etc… So by definition the DB is still in scope, correct? 99% sure the answer is yes.

    We are wondering if we could essentially build out a new CDE with a web app that would be strictly for processing only. So the first web app, would use a process similar to Stripe that utilizes IFrame/JS to transfer transmital/processing of CHD to the new CDE. Thus essentially removing the first web app and the DB from scope.

    As you can tell, I really want to keep the DB out of scope! It drags too much other stuff in our environment into scope.

    Thanks again for your time.

    • February 24, 2016 at 6:46 AM

      As long as the DB server in question does not have a direct connection to the cardholder data environment (CDE), then it would be out of scope for PCI. That said, it all comes down to the execution, so until you have the solution in production, we are talking theory.

  109. 313 Ash
    February 20, 2016 at 2:45 PM

    Hi PCI Guru,

    Hope you are well and having a good weekend mate.

    A basic question:

    I recently heard two opinions around CDE definition.

    some say you only define a CDE if you store CHD, otherwise you have scope of compliance but not as such CDE. Some say, where card processing activity takes place would be classed as a CDE as well despite of CHD being stored or not.

    SSC itself has two definitions, the short one only says CDE is where card data is stored, transmitted or processed! then there is a detailed glossary (may be old) defining CDE where CHD is stored. Curious to get your thoughts on it.

    Also, do you know of any resource, publication comparing different type of payment solutions / methods something along the lines of gartner magic quadrants etc.?

    Many thanks,
    Ash

    • February 24, 2016 at 6:57 AM

      The cardholder data environment (CDE) is anywhere where cardholder data (CHD) and/or sensitive authentication data (SAD) are processed, stored or transmitted. The Council obviously missed an update somewhere along the line. 😉

      Other than Gartner, Forrester and the like, I am not aware of any other sources of payment solution comparisons.

  110. 315 Mark Jones
    February 18, 2016 at 6:02 PM

    Can you be a QSA for one company and an ISA for another? Is this a conflict of interest?

    • February 24, 2016 at 6:59 AM

      If you are a QSA, you are a QSA. If you are an ISA, you are an ISA. If you are a QSA and working for a client, you are still a QSA and must serve as such.

  111. 317 Keith
    February 16, 2016 at 8:54 AM

    Mobile payment applications are causing a bit of a problem for me. I am having difficulty understanding what requirements are applicable to mobile payment apps and what SAQ type is applicable to merchants using them.

    Mobile payment apps themselves cannot meet the criteria for PA-DSS validation so I would like some insight into what is the responsibility of the the merchant? And also what is the responsibility of the third party vendor providing and developing the payment app for compliance?

    There are certain merchants that will have a mobile payment app with a card swipe or PED attached that will encrypt the PIN at entry or the contents of the magnetic swipe. How should these solution be profiled? and what are the requirements that the merchant is responsible for fulfilling?

    There are also other solutions that can be downloaded from any app store that do not require a PED or swipe device. Cardholder data is entered directly into this third party app and sent for processing. Can a merchant using this type of solution become compliant, seeing as the data being entered into the application is not being encrypted??

    If either of these solutions are in use, but only being accessed through the cellular network, how exactly should the SAQ be completed? What requirements are applicable?

    Any help would be greatly apprciated as I have spoke to several QSA’s who admit that mobile payment applications are somewhat of a grey area when it comes to compliance.

    • March 1, 2016 at 5:59 AM

      The PCI Security Standards Council have come out and said that mobile payment applications used by merchants can never be PA-DSS validated because of the inherent limitations of securing mobile devices. As a result, it they have left things up to the card brands to determine if such applications can be used. That said, such solutions from Square, PayPal, Verifone and others use techniques to minimize the risk of mobile transactions, but use must be approved by the acquiring bank and/or the brands.

  112. 319 John
    February 16, 2016 at 1:34 AM

    Hi PCIGuru,

    Thank you for a great resource.

    We are moving from a PCI-compliant web host to hosting it ourselves. Our current web host is refusing to supply us with the encrypted customer passwords along with their salts(so we can import them into our new host) as they say it is not PCI compliant.

    However there must be some PCI compliant procedure for transferring such data in between two parties?

    • February 16, 2016 at 8:12 AM

      Is there any cardholder data involved? That would be the only PCI compliance issue.

      Your third party Web host should provide you with the credentials decrypted so that you can encrypt them with your own algorithm, not their algorithm

      That said, the only thing that uses a SALT is a hashing algorithm. As a result, I think your third party is hiding behind the fact that they cannot give you the passwords because they really don’t have them either since hashing is a one way process. I am afraid you will only be able to get user identifiers and then have to have your users go through the forgotten password process to reset their password which will allow you to then hash them with your own SALT value.

  113. February 15, 2016 at 5:26 PM

    What are your thoughts on turning off MS Windows UAC (user access control) inside the CDE? Would be an issue for 2.2 and 6.2?

    • February 26, 2016 at 7:05 AM

      Not that I am aware, but it could create issues with requirements in 7 and 8.

  114. 323 Country^Girl
    February 12, 2016 at 3:51 PM

    With the Visa Chip Card,,Can I get 2 pin’s?? 1 for online,, 1 for store

    • February 13, 2016 at 2:14 PM

      Current, the answer is no. However the EMV standard does provide for such capabilities. There are just no processors that have implemented those capabilities.

  115. 325 Ewan
    February 10, 2016 at 2:42 PM

    Hi,

    I provide and host online shopping cart software for local businesses. I was happy that I wasn’t within the PCI scope because the software only allows the use of PayPal and one or two other payment gateways.

    However, the businesses can put telephone orders in manually and I’ve recently discovered that a lot of them are typing card details into a free text field for notes about the order. Because I host their shopping carts, there are therefore card details on my server.

    Who is liable, from a PCI point of view, for these card details? Is it me because I’m hosting the servers, or the businesses for putting the card details into a insecure location?

    I’m of the feeling that I should delete these card details immediately, or at least tell the businesses to remove them themselves. It does make me nervous.

    Ewan

    • February 11, 2016 at 7:47 AM

      OOPS! Bad news for you on a couple of fronts.

      First, how did you think you were not in scope for PCI compliance? Even with your limited scope, you are a service provider under the PCI rules even if you were not actual processing the transactions, you are still part of the payment process. As a service provider, you need to perform an SAQ D for Service Providers and provide your customers a Service Provider AOC for the shopping cart service you provide them. You are also responsible for getting Service Provider AOCs from PayPal and your payment gateways. That said, because you use PayPal and, I am assuming, similar payment gateways, you will only be responsible for complying with the requirements in SAQ A.

      On the second front, you have now found out that your customers are entering sensitive authentication (SAD) and/or cardholder data (CHD) into your systems. Since you are a service provider to those merchants, you are the one responsible for securing and/or remediating this SAD/CHD even though it was not your intention to have it entered there. You have a couple of choices. Your first option is to remove the comment/memo field. Your second option is to encrypt the comment/memo field in your database(s) now that you know sensitive data is being entered into that field. Your final option is for you to go to your customers and instruct them to never enter SAD/CHD in the comment/memo field and also implement a scrubbing utility to remove it if it is entered.

      Regardless of the option you pick, you are going to have to do something about the SAD/CHD that is already in that field. The easiest option there is to run a query to delete anything in that field after you have notified your customers that will be deleting that information due to PCI compliance issues. However, if you chose to encrypt that field, that will also remediate the issue. However, implementing encryption will be complicated due to the need to use separate keys for each of your customers along with the necessary key management procedures mandated in requirements 3.5 and 3.6 in the PCI DSS.

      Even if you go back and tell your customers that you are not taking responsibility for their data entry of SAD/CHD in the comment/memo field, the “cat is out of the bag” so to speak and you have knowledge of what they are doing so you have a legal responsibility to protect that information or running a script nightly to delete it from your database(s).

    • 327 Jonatan
      February 11, 2016 at 3:44 PM

      This is just an approach but since Ewan is the owner of the online application, wouldn’t it be a good idea to let the customers know that credit card cannot be entered within the text field and include a coded validation within the test field in order to find PANs as the information is saved in the text field and truncate it?
      I mean, it’s actually really simple to identify a possible PAN since the code for such validation is available within public pages on internet.
      By setting such validation, he ensures that no Confidential CHD is stored in his DBs.
      I mean, the customer can actually include the PAN in any other field or also a combination of fields, that’s something nobody can prevent but this would be like a compensating control from the application side.

      Again, just a thought. You are the Guru here so I’ll let u burry my thought or give it a twist to help out Ewan haha

      • February 12, 2016 at 6:03 AM

        Reminding customers that they should not be entering cardholder data (CHD) into the comment/memo field is definitely a good idea. But that does nothing to ensure that the practice stops without your idea of looking for such data on entry.

        That identification process works great for the primary account number (PAN), but what about CVV/CVC/CID? But something you should also know about PANs is that not all of them meet the Luhn check any more. Seems Visa and MasterCard have quietly abandoned that for their branded gift cards and single use accounts (SUA). So all you can really rely upon is the fact that you are seeing a 15 to 16 digit number.

      • 329 Jonatan
        February 12, 2016 at 6:23 AM

        That’s why you are the Guru here haha
        Well, that’s actually true but it’s also true that customer bad habits leads to use applications fields in an incorrect way (ex. using text fields for PAN o even a combination of other fields like phone, SSN, etc).

        I mean, it is almost impossible (besides instructs the end users) to avoid having CHD included within the applications fields/records since you can perform fields validation in terms of kind of data used and struchture of each one but in the very end, the customer will load them with whatever they want.

        Here, it seems that as u pointed out, there is no way to ensure that CHD (both confidential and sensitive) wont be stored within the DB so the only solution here would be to encrypt the text field and manage the keys properly.

        I’d like to take this chance to ask you about your point of view of my first paragraph here. It is impossible to avoid a customer from entering CHD within the fields of an applications even though the application/fields are not intended to have such information. How would you manage these kind of situations? Is there any compensatory control you might consider or ust, as u said, encrypt the fields (cause instruct customer is not gonna work and we both know it haha)

        Thanks again for your thoughts ad help!

      • February 12, 2016 at 11:30 AM

        And that is the problem. There is nothing an organization can do to stop customers from doing stupid things such as sending sensitive authentication data (SAD) or cardholder data (CHD) via electronic mail, facsimile, instant message, texting it, etc. All an organization can do is securely deal with it when it occurs. Whether or not an organization chooses to process the transaction is a customer service issue. Some of my clients send a polite but firm message back to the customer stating they will not conduct transactions via the communication method used by the customer. Others will conduct the transaction but then remind the customer that the communication method was not secure. Behind the scenes, the people involved have to securely delete the original messages. If they process transactions, then they also print out the messages, process the transaction, redact the SAD/CHD from the message, copy the redacted message and securely destroy the original print out.

  116. 331 Erik
    February 10, 2016 at 12:40 PM

    Hi PCI Guru… Thank you for your excellent resources provided here, and the ability to ask you questions directly!

    Our company has a PCI-DMZ application in which we accept credit card data, and immediately tokenize. We also have an internal database which this application connects to. No PCI data is ever transmitted to this database (however customer information such as name and address are). Do the one-way connections from the PCI-DMZ application to this non-PCI internal database need to be encrypted? Managing this encryption has caused several issues, and I would like to avoid doing it if at all possible. Or, more generally, do one-way connections initiated from the PCI DMZ, to other private network zones, need to be encrypted if they don’t contain PCI data?

    Thank you!

    • February 11, 2016 at 7:52 AM

      From a PCI compliance perspective, if you are not transmitting cardholder data (CHD) to the database (or other non-PCI systems/devices), then those communications do not need to be encrypted.

      To be clear, any systems/devices that connect to the cardholder data environment (CDE), in your case your PCI-DMZ, are still in-scope for PCI compliance because they are connected to the CDE. Even if those connections are one way outbound. Any connectivity to the CDE is in-scope for PCI compliance. What does change is the risk that connectivity presents to the CDE. Outbound only connectivity obviously has lower risk than inbound connectivity or inbound and outbound connectivity.

  117. 333 Jane L
    January 29, 2016 at 11:54 AM

    First, thank you for your valuable insights. I come here often when I’m not sure about the intent of a requirement. I’ve read your responses to questions similar to the scenario I’m struggling with, so I’d like to get your thoughts. Merchant has two payment channels: in person via dial-up card terminal (SAQ B), e-Commerce with payment processing entirely outsourced to a third party (SAQ A). The merchant does not sell a product or service, but rather charges fees for filing certain documents via their Web application. The merchant uses the Trustwave portal for submitting their SAQ, which when using their wizard, ultimately puts them in SAQ B (which includes all of SAQ A). The merchant has also, as a courtesy, set up some “kiosks” (hardened PCs, with only whitelisted Web sites the customer can access) in their lobbies to allow their customers to log into the merchant’s Web application. For certain functions, the customer could make a payment using this PC (via the third party’s payment processing page). While I agree that the merchant, as a best practice/due diligence should make sure these “public” PCs should be hardened, monitored, etc., it is not clear whether they are actually in scope for PCI DSS and if they are, what SAQ would apply? SAQ C-VT applies to merchants that process CHD via virtual terminals – but it isn’t the merchant in this case that is really initiating the transaction – it is their customer who has decided, for convenience, to use the PC in the lobby vs. using a PC elsewhere to access the merchant’s Web application. These PCs are segregated from the other parts of the merchant’s network where their Web application servers reside, so technically they are not even “connected” to the CDE. Any thoughts?

    • February 1, 2016 at 9:43 AM

      In my very humble opinion, the kiosk PCs are out of scope for PCI compliance for the very reasons you state. That said, I would say that if the merchant does not maintain those they are being very foolish as their customers are relying on them to have them maintained and be secure.

      • 335 Jane L
        February 1, 2016 at 10:34 AM

        Thank you for your prompt response. Based on what I’ve been told, I believe the merchant is doing their due diligence with regards to these PCs. It doesn’t hurt to remind them that even if they are not in scope for PCI compliance, they should still be properly secured and maintained.

      • 336 Robert C
        December 9, 2016 at 3:56 PM

        Thanks for your insight on ‘kiosk’ type PC’s. I am trying research this topic but have not found the PCI SSC guidance or direction on this. Can you point to a reference from PCI SSC on this topic? Or other reference. I like your answer, just wanted to see if PCI SSC had a specific guidance on this. Thanks.

      • December 10, 2016 at 10:13 AM

        The only guidance the Council is going to provide you is related to any devices that process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD).

  118. 338 Taruna Robinson
    January 29, 2016 at 8:36 AM

    Hi,

    We’ve found a supplier that can provide a ‘virtual terminal’ for us to enter CC details. The terminal would be accessible from any PC and take us to the other organisations page where we can securely enter the CC data. Would this process take us outside of PCI?

    Thanks,

    Taruna.

    • January 29, 2016 at 9:34 AM

      This is the frustrating thing about a ‘virtual terminal’ and what people do not seem to understand. And that is that the PC used to access the virtual environment is still in scope because its keyboard, processor and memory are still involved in the processing and transmitting of cardholder data (CHD). Do not get me wrong, the risk presented should be fairly low as most organizations have decent security standards for configuring and maintain their PCs. But there is still a risk that a keyboard logger or a memory scraper gets installed on the PC that accesses the virtual terminal and results in exfiltration of CHD. That does not necessarily mean that all PCI requirements need to be applied to those PCs if their risk is properly managed, but they are still in scope for your PCI assessment.

      • February 11, 2016 at 8:01 AM

        Hi,

        We can limit this to 4 or 5 computers taking payments, so, would this be applicable to those computers or the whole network that those PCs were connected to.
        This is what we want to avoid – don’t mind scanning 5 PCs, but not 150.

        Thanks for your invaluable advice

        Taruna

      • February 12, 2016 at 6:11 AM

        This is what the very active discussion about whether or not computers that are used for secure data entry of cardholder data (CHD) can coexist on the same network segment as those computers that do not have anything to do with CHD.

        In my very humble opinion, if your computer hardening standards are strong and you feel that the risk of getting a keyboard logger or memory scraper is low, then I would say that those four or five systems that securely enter CHD can be on the same network as the other 150. Therefore, you would only scan the four or five and not the 150.

        That said, if your organization is truly looking to be secure, you really should be vulnerability scanning the other 150 computers as well.

  119. January 26, 2016 at 9:08 PM

    I have an application with workstations that have been declared in scope for PCI. I want to stand up a private VDI cloud with all the appropiate PCI monitoring, logging, patching, etc… on those VDI instances. I have a card reader on the in scope PC’s but i’m being told these violate the entire design. All processing happens on the VDI in a secured PCI Data Center.

    The option I’m being given is to replace the PC with a Zero OS device that MUST connect to the VDI instance for all activities. There will still be a card reader at this “net PC”. Is this a true PCI requirement or a security officer run amuck? I understand the Net PC may be a more complete solution but is it required to meet PCI?

    P.S. My company provided the PC originally, they are not customer owned PC’s.

    • January 27, 2016 at 2:05 PM

      It depends on how that card reader or point of interaction (POI) functions. If it is passing sensitive authentication data (SAD) or cardholder data (CHD) in clear text through the thin client to the VDI instance, then the thin client is in-scope as well as the POI and the VDI. If the SAD/CHD is encrypted upon swipe/dip and/or manual data entry through the POI, the the thin client will not be in-scope and only the POI and the VDI will bit in-scope. Where this can go sideways is when the thin client is the point of encryption and not the POI which is highly likely. Also I have seen instances where manual data entry is through the thin client’s keyboard, not the POI which also brings the thin client into scope.

  120. January 26, 2016 at 5:09 AM

    Hi PCI Guru was wandering about requirement 6.6. For all of our internally developed applications peer reviews take place within the development team with code developed within internal development areas. When specific code is then merged within the larger application it is reviewed and tested again within the development team. We will then upload the code to a repository where our hosting provider will update into a preproduction environment and we enter a UAT phase by the users of the system, once we are happy the host provider then moves the updated code into the LIVE environment. While our development team use various tools and a manual process for reviewing and checking code, could our ASV scanner be included in our process as independent tester of the code in the pre-prod environment to satisfy 6.6. We run our ASV scans weekly on the LIVE environment only. Thank you for your help.

    • January 28, 2016 at 10:11 AM

      While adding an ASV scan is great, it is not going to meet the requirement of 6.6 because it is, by its very nature, not an application scan. Yes, I know that some vulnerability scanners do a certain amount of application testing. It is not an application scan in the sense of what you get out of products such as Fortinet, AppScan and other purpose built application code scanners.

      In addition, in my experience, nothing comes close to best identifying issues as a good old fashioned manual code review. Automated scanners can help identify potential issues and “low hanging fruit”, but manual code reviews probably identify 95% more issues than the automated tools.

      • January 28, 2016 at 10:21 AM

        Thanks Guru, this is great news as I did forget to mention that manual code reviews do happen, however while the reviewer will not be the person who wrote the code it will be a colleague within the software development team and not someone who is organisationally independent, does this mean that would need to hire a third party code reviewer for example?

        Thanks again

      • January 28, 2016 at 10:31 AM

        As long as it is someone not involved in the writing of the code reviewed that is independent enough. However, that can be problematic at times in smaller organizations as the person reviewing the code originally wrote the code. That is why some small organizations do periodically (usually annually) have qualified, independent third parties come in and do reviews just to make sure their code has as few issues as possible.

  121. 348 Chris
    January 23, 2016 at 3:15 AM

    If we are taking credit card payments over the telephone (with pause and resume technology with recordings) and then entering them into NetSuite, and as they are entered the digits are hashed on display on screen one by one, and NetSuite provides an AOC certifying them. Are the desktops we use to key in the credit card information to the portal in scope, as the PAN is enter fully, but never displayed fully on screen?

    • January 25, 2016 at 9:00 AM

      Yes, those workstations are in scope because they are used to enter the data (processing and transmitting). The risk is that a keyboard logger, memory scraper or similar gets on the workstation and starts collecting cardholder data (CHD).

  122. 350 Al
    January 15, 2016 at 7:53 AM

    Hey PCI Guru!
    Currently our company processes and stores cardholder data, though we are considering moving to assume less risk. We are aiming to limit our scope by having payments processed by a third party though storing as much CHD as possible without falling into the SQA D category.

    If we were to store a truncated PAN (which we receive back from our PSP) with the cardholder name and expiration, would this be out of scope of PCI DSS?

    Thanks,
    Al

    • January 21, 2016 at 9:22 AM

      Cardholder data (CHD) is only CHD if it includes the PAN (either clear text or encrypted). If you mask the PAN to the first six and/or last four digits, that is no longer considered a PAN, i.e. 123456xxxxxx1234 or xxxxxxxxxxx1234. Same as if you truncate the PAN to only the first six and/or last four digits, i.e., 1234561234 or 1234.

  123. 352 Eamonn Evans
    January 11, 2016 at 6:21 AM

    Dear PCIGuru

    I am a small business owner who is considering launching an e-commerce website. I’ve become aware of a company which has an App that allows payment of a restaurant bill by scanning a QR code on a paper receipt (see name of this company at end of this post). Their website says that they can also allow a website to display a QR code on the checkout page of a shopping cart; when scanned by a mobile phone, payment is processed by them. This latter application is of interest to me.
    I have a number of questions about this and would very much appreciate your comments:

    1. If a developer designs a shopping cart/website which has this QR code as the ONLY payment method, could the developer avoid having to seek a PA-DSS certification for his code as the website never has credit card information entered into it at any stage?

    2. Could the merchant’s website be considered out-of-scope for PCI for the same reason?

    3. It seems to me from the information provided by the App company’s website that credit card details are stored on mobile phones ( albeit encrypted). I thought that this is never recommended. Does this have any bearing on questions 1 and 2 above? Could you comment on the safety of this from the point-of-view of a consumer?

    Many thanks for an extremely informative resource.

    Regards
    Eamonn Evans

    [App developer is Zapper.com -you can delete the reference from this post if you wish]

    • January 29, 2016 at 10:07 AM

      Here are my thoughts.

      1. The application that generates the QR Code needs to be PA-DSS assessed if it is sold by the developer as a service because it is still generating the method of payment. My rationale for this is that the risk is that the code that generates the QR Code is modified to send a customer to any malicious Web site for payment, that is controlled by the application, not the merchant. This process is really no different than applications that generate iFrames for payment that never process data.

      2. Merchants that have Web sites that use the QR Code approach would be out of scope just as when they use an iFrame. That said, while your Web site is out so scope for PCI compliance, you better be ensuring the security of your Web site because you are the one invoking the payment process.

      3. Smartphone security is the customer’s problem, not the merchant’s or service provider’s. This is why payment wallets and applications like Apple Pay, Google Pay and the like are not in scope or required to be PA-DSS validated.

  124. 354 Annie
    January 7, 2016 at 5:54 PM

    Hi,

    This seems like a simple question, but I can’t find the answer anywhere, and was hoping you could help. I was wondering if there is a fee schedule associated with submitting an SAQ? Could shady merchants submit the wrong SAQ to avoid paying a higher fee?

    • January 8, 2016 at 6:45 AM

      I do know that some acquiring banks do charge merchants and service providers a “filing fee”, “program fee” or similar to recover some of the costs incurred in the management of the required PCI compliance programs. However, I have not encountered a fee schedule based on the type of SAQ or a ROC. The programs I have seen charge a flat rate regardless of the type of SAQ.

  125. 356 Jared
    January 6, 2016 at 2:35 PM

    Hi,

    This a fairly straightforward question, that I can’t seem to find an answer to. As I understand it there are two ways to become PCI certified. You can certify an entire office, which would include the entire environment, or you can certify a process, which would only include in scope servers, networks, and workstations. Now for a multi-part question:

    If you certify an office, are you able to move new processes into that office and still be certified or do you have to go through a new audit every time you bring in new business?

    If you certify a process and then the process changes do you have to have the updated process audited and certified again?

    Thanks

    • January 7, 2016 at 8:28 AM

      There is no certification involved with PCI as there is for example with AICPA SSAE 16. PCI compliance is assessed as of the point in time of the assessment. There is no certification that the organization was compliant at any other time other than when the QSA was conducting the assessment.

      PCI assessments involve the assessing of an organization’s payment card processing. That assessment process typically involves all processes that involve card processing. However, it does not have to cover them all. For example, an organization could report separately on their outsourced eCommerce from mail order/telephone order and file separate SAQs for each process. That would have to be approved by the organization’s acquiring bank before you could follow through.

      I have also seen large organizations split up the PCI assessments of their individual business units. Again, that was pre-approved by their acquiring bank before they took that approach. However, I have never seen a particular facility assessed unless the process is contained only in that facility such as with a call center or an order processing center.

      All of that said, if the process changes, that is considered a “significant change” and does require that the new process be re-assessed for PCI compliance.

  126. 358 Mojo
    January 1, 2016 at 8:40 AM

    Firstly may I bid you a happy new year friend.

    We currently have PDQ terminals working off a dedicated phone line. Our payment provider offer IP PDQ terminals with end-to-end encryption, this would be a better option for us as we can have more terminals without needing more phone lines. However I’m struggling to find an answer as to whether the end-to-end encryption takes our IT setup out of the scope? At the moment all PC’s/Printers are connected to the same network, if I connect a PDQ today then that would become part of the same network and would be visible from the other devices.

    I have seen smaller businesses use these IP PDQ’s without any separation but as I’m dealing with a fairly large business I want to be sure.

    • January 1, 2016 at 10:53 AM

      Encryption can be used as a network segmentation technique as long as the devices between the endpoints cannot decrypt the datastream. See my post on how encryption reduces scope. https://pciguru.wordpress.com/2013/03/07/encrypted-cardholder-data-out-of-scope/

      The next thing you will need to do is determine if the encryption solution you will be implementing is a PCI Point-to-Point Encryption (P2PE) validated solution or is just an end-to-end encryption (E2EE) solution. The only real difference between the two solutions is that an E2EE solution needs to be assessed to ensure that it truly keeps everything encrypted from the IP PDQ terminal to the processor. Then that assessment needs to be documented and your acquiring bank needs to approve that the E2EE solution results in the scope reduction. If approved, then your E2EE solution will reduce your scope to only the IP PDQ terminals and the rest of your network will be out of scope.

      Best of luck.

  127. 360 Jason
    December 11, 2015 at 6:20 AM

    Hi,

    Great blog, managed to find plenty of good answers that I’ve been scratching my head over!

    I’ve been checking into the issue of having an “isolated computer” for processing payments and the fact that having a fully encrypted data stream is enough to be classed as “isolated” as per;

    https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-encrypted-cardholder-data-in-scope-for-PCI-DSS/?l=en_US&fs=Search&pn=1&top=1

    However we run a proxy which does HTTPS inspection via what amounts to a MITM attack, which means that we do technically decrpyt and re-encrypt every packet that enters the network.

    Any ideas on where we stand with this? Would simply adding a bypass to the proxy for our PSP be sufficient, or does the fact that we technically capable of this mean additional steps need to be taken?

    Every answer I find seems to unlock 5 more questions 😦

    Thanks in advance!

    • December 14, 2015 at 11:04 AM

      Proxying SSL and TLS is a problem because, as you correctly point out, you are decrypting and encrypting the stream at your Proxy. That said, proxying SSL/TLS technically just adds the Proxy to your list of in-scope PCI devices that must be assessed. While you could set up a rule to bypass the Proxy, do you really want to do that as it could create a number of other security as well as possibly PCI issues?

  128. 362 Jamy
    December 8, 2015 at 11:08 AM

    I see many mentions of Thin clients on this page, but nothing about windows updates on them. I have a customer buying HP T620 Thin Clients for their Store locations. These devices will have USB Magstripe readers attached to them to process payments through a virtual terminal session (encrypted). The Thin Clients will have internet access, but through a Firewall and Web filter to only approved sites. All other access is to be done through Citrix. A PCI compliance assessment was done and the consultant (not sure if QSA) stated that Windows updates must be done on these devices. We are finding that enormously difficult to do with the small amount of Disk space on the Thin Clients (Write Filters are enabled while operating) as well as having issues with the functionality of them once updates are applied. Of course, HP claims we are out of support, so they will not help. Is there some sort of guidance anywhere that exempts Windows Embedded 8 Operating System from regular (monthly, quarterly, etc.) Windows updates? HP claims that as long as we are on the latest posted version on their website (August 2014), we are good to go. Any help is appreciated!

    • February 7, 2016 at 5:06 PM

      Such is the problem with thin client solutions. If you are current, you are current. However current does not mean without vulnerabilities. If you are getting clean vulnerability scans then you are fine. But if you are not, then your only option is to mitigate any vulnerabilities through additional monitoring, further isolating the systems or other measures. I am writing a post right now about some of the myths of thin clients that will discuss what you face in more detail. Thank you for the idea.

  129. 364 Ben
    December 4, 2015 at 5:14 PM

    My company is trying to take ourselves out of scope for SAQ A-EP and go back to SAQ A. The payment page currently originates from our servers and is then submitted directly to our payment processor. Our payment processor doesn’t support any type of hosting of the payment page so we want to get another 3rd party to host it such that we could then load it in an iframe.

    Are there PCI DSS validated service providers that will host a single page without also doing the payment processing, and is this acceptable to use multiple 3rd party service providers for one checkout process? There are also a lot of hosting providers that claim to be PCI Compliant. As long as they are able to provide a copy of their certificate of validation, is that all we need satisfy what is necessary to take us out of scope for SAQ A-EP? Since the payment page would be provided to them by us, are they still able to attest to its compliance or would we need to also restrict our own access to it in some way?

    • December 7, 2015 at 6:41 AM

      The key to taking your Web site out of scope is to NOT be processing, storing or transmitting sensitive authentication (SAD) or cardholder data (CHD). The only PCI SSC and card brands approved ways that can occur is to either: (a) totally outsource your Web site to a third party such as Amazon, (b) use a redirect and send your customer to a third party such as PayPal, or (c) use an iFrame from a PCI compliance payment processor such as TrustCommerce.

      Your logic regarding putting your payment page at a third party would mean you would have to also turn over all of the related development activities for that page to a third party as well. If you retain the development responsibilities for that page, then your organization would still be responsible for requirements in section 6 regarding secure development practices, SDLC, etc.

      As to whether or not there are PCI compliant third parties willing to host a payment page, I have no idea. There may very well be, but I am not aware of who they would be.

      • 366 Ben
        December 7, 2015 at 1:12 PM

        What if we put the payment page on, say, AWS? We would still be in scope for A-EP, but would all the questions from SAQ A-EP only then be in the context of AWS? For example, would we no longer have to adhere to section 8.3 (two-factor authentication for VPN), or section 10.5.4 (logging for external-facing technologies) since VPN access and logging for our network have nothing to do with the payment page on AWS?

      • December 8, 2015 at 4:23 PM

        As long as your organization maintains the page, I don’t care where you store it, your development and maintenance of the page are still in scope. See my post on this whole subject. https://pciguru.wordpress.com/2015/01/07/saq-a-and-saq-a-ep-clarification/ The table in that post basically tells you the only way you can minimize scope is through the use of a redirect or an iFrame. Anything else doesn’t work.

  130. 368 Dave
    December 3, 2015 at 10:27 AM

    We’re trying to determine if we can follow SAQ-C with a fairly flat network if sufficient measures are taken to secure each device. Here’s the general configuration.

    We host a 3rd-party, PA-DSS compliant payment application on a dedicated server which handles tokenization of card data through an external payment processor. No CHD is permanently stored on any of our servers.

    Local users access our main application through terminal services, and the application opens an embedded browser window to access a data entry form on the payment application using HTTPS. Workstations are secured with anti-malware/virus software and are regularly patched via a local WSUS server (Windows updates). Web use is regulated by a proxy server. Log files are reviewed weekly.

    Remote users access the same application through SSL VPN connection and terminal services. Remote workstations that take CHD use a swipe machine with P2PE that tokenizes at the machine level, and are secured with anti-malware/virus/net nanny software and regularly patched. Log files are reviewed weekly.

    Customers can make payments on our locally hosted website over HTTPS, which transfers the data to the payment server over HTTPS.

    Our network contains servers for Exchange, Active Directory, WSUS, SharePoint, a file/print server, etc. Externally facing servers (web server, VPNs) are in a DMZ. All servers are involved with payment processing run Windows 2012 (TLS 1.2), log to a SIEM system, and we run regular penetration tests. All workstations involved with payment processing are running Windows 10 (TLS 1.2).

    Is SAQ-C a reasonable possibility?

    • December 7, 2015 at 8:33 AM

      SAQ C was primarily created for the franchise industry for their POS configurations, not for what you are describing. What you describe would be SAQ C-VT in my opinion, but that is just my opinion. Only your acquiring bank can officially tell you which SAQ you should be using for your organization’s PCI assessment. You need to talk to your acquiring bank and get them to tell you which SAQ you should use based on your description of transaction processing you provided me.

  131. 370 DS
    December 3, 2015 at 7:54 AM

    Hi,

    If company used to store card details in a database (inc the last xxxxxxxx1234 long number, but has since changed their processes so they no longer do that, is there a time limit around the details that already existed in the database with regards to if the database was breached? For example, if the data is 5 years old, does it make it null and void?

    Thanks,

    • December 4, 2015 at 9:43 AM

      Cardholder data (CHD) is cardholder data. There is no time limit placed on stored CHD when it is no longer considered CHD. The reason is that, in a lot of cases, you can add three years to the expiration date and the PAN is still good. So unless you securely purge that data from your database, it is still in scope.

      • 372 DS
        December 4, 2015 at 10:02 AM

        Perfect. Thanks for the clarification.

  132. 373 DS_180
    December 1, 2015 at 6:02 AM

    Hi,

    If a company takes payments in a number of different ways (POS, over the phone, via a website, etc) and each method uses a different workflow and even utilises different 3rd party payment gateways, can you fill in separate SAQ’s for each one? For example, the company might have a 10 merchant ID’s. Each merchant ID relates to a slightly different part of the business and they take payments in different ways. One of them may end up with the storage of cardholder data, but the others don’t. Or, do you have to complete a single SAQ taking into account the highest risk area?

    Thanks

    • December 1, 2015 at 8:19 AM

      At the 2014 PCI Community Meeting, the PCI SSC finally endorsed the use of multiple SAQs for merchants that have different payment channels. However, the caveat on that endorsement was that the merchant must get their acquiring bank(s) approval before following such an approach. In my experience with merchants that have multiple acquirers, each acquirer wants their own SAQ or SAQs that cover all the payment processes used for their merchant identifiers.

      • 375 Gopal
        February 15, 2016 at 6:32 AM

        Hi

        Continuing this discussion thread

        We have few merchants who have more than one DBA where some of them fall in the eCommerce section and some in the POS section.

        As per http://apps.usa.visa.com/clients-partners/acquirers/data-security/pci-dss-compliance.jsp

        In cases where a merchant corporation has more than one DBA, Visa merchant banks must consider the aggregate volume of transactions stored, processed or transmitted by the corporate entity to determine the validation level.

        If data is not aggregated, such that the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, merchant banks will continue to consider the DBA’s individual transaction volume to determine the validation level.

        What if the merchant is not storing, processing or transmitting the cardholder data in all cases?

        Should they file only SAQ A and B where they cross the limit for the particular DBA (merchant ID) where the cardholder data is stored or processed within their data center?

        After the Merchant submits the SAQ forms, should we follow-up and ensure that quarterly ASV scans are carried out ?

        What happens if they don’t comply with ASV scans? Do we report to PCI council or to our QSA?

        thanks

      • February 16, 2016 at 8:26 AM

        While you quote Visa’s official stance on this topic, it really comes down to the acquiring banks to enforce it. Even with one legal entity, I have seen organizations with multiple DBAs file separately for each DBA based on their payment processes because they went to their acquiring bank(s) and argued it was easier for them to do it that way. I have also seen the opposite where the acquiring bank(s) did not agree and the organization had to file one SAQ D for all their DBAs. All you can do is make a case to your acquiring bank(s) and let them decide.

        Getting aggregate transaction volumes is easy if the merchant processes through the same transaction processors and banks. It can get tricky though when transactions go through different processors/banks. As a result, banks will rely on merchants to accurately portray their transaction volumes.

        If a merchant accepts payment cards for payment, then the absolute minimum for their compliance is SAQ A which is only for totally outsourced eCommerce merchants. For brick and mortar merchants, the minimum would be SAQ B for a merchant that uses dial up card terminals.

        If you are serving as a merchant’s QSA and assisting with filling out their SAQ(s) and there are no quarterly ASV scans when there should be, then you should be refusing to sign their SAQ(s). If they still submit the SAQ(s) and they are fraudulent, then you should report that fact to their acquiring bank(s). You should then expect to not be invited back to provide them assistance with the next year’s SAQ(s).

  133. December 1, 2015 at 1:57 AM

    If my POS system crashes and I have no other way of tendering credit and debit cards from my guests other than to use the old fashioned “knuckle busters” temporarily, would that put the restaurant in jeopardy by breaking a PCI regulation of some sort? Please advise. Thank you.

    • December 1, 2015 at 8:23 AM

      In the event of an issue that requires the use of manual payment processing methods, you are not breaking any PCI rules/regulations. However, you do have to adjust your PCI compliance processes to address the fact that you now have physical paper receipts that contain the imprint of the card or written cardholder data on them (for non-embossed cards). So those paper receipts will have to be secured with access limited and when they are no longer needed they will have to be securely destroyed.

  134. November 30, 2015 at 1:50 PM

    Here is one requirement that has caused loss of sleep and become a topic of debate within our IT group.

    6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

    I have always interpreted that to mean that once the entity identities that a critical security patch is available, they have 30 days from learning about the patch in which to patch. But as I re-read the requirement I see that it actually says that the critical security patches must be installed within one month of RELEASE.

    If the entity becomes aware of a patch 5 days after the patch is released does that mean they only have 25 days remaining to meet the requirement? How should IT system admins or security analyst monitor for patches?

    Oracle has a quarterly patch release cycle, Microsoft has a monthly release cycle. IBM, Cisco etc. have no set patch release cycle. To me this makes it challenging for entities to comply. Should security administrators or systems administrators do a daily visit to vendor web sites looking for patches? Since these patches must be evaluated per requirement 6.1 , meeting these two requirements could become challenging.

    • November 30, 2015 at 3:52 PM

      Yes, your interpretation is correct. You have 30 days from RELEASE to apply critical patches. And to add insult to injury, all other vulnerabilities need to be put in place within a 60 to 90 day timeframe (see the Guidance column for 6.2, last sentence).

      However, before you get all upset about that, you need to know a secret. Not a deliberate secret, but if you have not been to a Community Meeting, you would not know. Participating Organizations (PO) complained about this years and years ago. The language in 6.2 is for dummies that need a deadlines.

      QSAs and ISAs were instructed probably six or more years ago to look at the entire vulnerability management processes. If a QSA/ISA can prove that the vulnerability management processes are functioning properly and that vulnerabilities do not fall through the cracks, then the 30 day “rule” does not apply. In most Fortune 500 companies, the fastest they can patch is around 60 to 70 days when you put testing and QA time as well as roll out time depending on the patch. The fastest I’ve ever heard of in such organization was 45 days. But this evaluation by the QSA/ISA is for ALL vulnerabilities, not just critical ones. The processes must be working for all vulnerabilities, not just critical vulnerabilities.

      As to IBM, Oracle and the like, you patch when they give you a patch but you should be subscribing to their RSS patch feed to monitor when those patches are available. The difficulty with those is that, for example IBM Websphere, IBM will not support you if you patch the underlying OS. As a result, it is possible to get an update for Websphere that does not include all of the patches for Windows or Linux because they were not compatible with Websphere and caused performance or stability issues or they missed the cutoff for IBM QA testing. That does not mean you are off the hook. You must put in place mitigating controls of those vulnerabilities such as additional monitoring, enhanced firewall or IDS/IPS rules or other controls to mitigate the risks the unpatched vulnerabilities present.

      I would recommend not messing with the CVSS scores as allowed in 6.1 unless you really have the time and staff to do the necessary documentation to support those changes. Just accept the CVSS score as is and move on. What you do want to do in 6.1 though is to document those patches that are not relevant to your environment and why. For example, if you only run IIS as your Web engine, you would not be applying Apache or Tomcat patches, so any of those would never be applied and you should document that fact.

  135. November 25, 2015 at 2:42 AM

    Hi PCI Guru great blog, what an invaluable resource. Could I have your take on the following please

    My company is thinking of making Call Centre Agents more like Teleworkers in as much as that in times of extreme weather or periods where call volumes are lower they can work from home. We can make the applications or their desktop environment available virtually and we are looking at telephony systems which would enable operators to take calls from home.

    My concerns are that while securing infrastructure, applications and network connections may be straightforward enough, I am thinking that our mobile policies and procedures will be more complex, how can we ensure compliance to PCI realistically for operators within their own home. It is not currently known whether we will provide the PC and telephony hardware or not.

    Thank you in advance

    • November 25, 2015 at 9:14 AM

      This is the dilemma organizations face as they allow people to telecommute. For example, what will you do to stop employees from doing their work from the local coffee house or other public venue that has Wi-Fi?

      I have a client that will not allow workers to telecommute until they have worked for them for a certain period of time, say a year, AND they have not had any infractions such as writing down PANs, not keeping a clean work area or miss hitting the no record button if they are relying on manual controls to not record cardholder data (CHD). This client also periodically performs surprise visits to worker’s homes to make sure that the rules are being obeyed.

      I have another client that allows telecommuting for its call center personnel, but does not allow them to take CHD over the phone. If they need to take CHD, the telecommuting call center personnel transfer the call to an IVR system that will process the CHD or the call is transferred to an employee in the actual call center for manual data entry.

      In the end, there is no right answer (there are however a LOT of wrong answers). It all comes down to what is your organization willing to assume in the way of risk and how you manage that risk.

      • November 25, 2015 at 9:23 AM

        Thank you for your response, I believe we are looking at a mix of DTMF and the phone provider passing CHD directly to our Payment Service Provider so this will prevent any operator handling CHD at all, however there is still customer PII to protect. Thanks again

  136. 384 Jonatan
    November 24, 2015 at 12:35 PM

    Hi Mr!
    I know this might sound idiot but it’s been a while since i’m trying to find the best way to add rows to the RoC without having to extract the content of the RoC template to another document cause the RoC is almost entirely blocked.
    Any advice that can make our life easier by the time we have to edit the RoC tables to add more rows?

    Thanks in advance again!

    • November 25, 2015 at 9:16 AM

      According to the PCI SSC, QSACs are not allowed to edit the Reporting Template other than to those cells that are unlocked.

  137. November 20, 2015 at 3:57 PM

    So we are in the process of migrating our CDE to TLS 1.2 — June 2016 is just a few months away — and the Windows server techs sent me a note trying to clarify the use of encryption.

    Here’s what was sent:

    > WSUS requires two ports for SSL: one port that uses HTTPS to send encrypted metadata, and one port that uses HTTP to send updates. When you configure WSUS to use SSL, consider the following:
    > * You cannot configure the whole WSUS website to require SSL because all traffic to the WSUS site would have to be encrypted. WSUS encrypts update metadata only. If a computer attempts to retrieve update files on the HTTPS port, the transfer will fail.

    See: https://technet.microsoft.com/en-us/library/hh852346.aspx#bkmk_3.5.ConfigSSL

    So … is encryption only required where CHD is being transmitted? The CDE severs are isolated from the WSUS network by two firewalls.

    > WSUS requires two ports for SSL: one port that uses HTTPS to send encrypted metadata, and one port that uses HTTP to send updates. When you configure WSUS to use SSL, consider the following:
    > * You cannot configure the whole WSUS website to require SSL because all traffic to the WSUS site would have to be encrypted. WSUS encrypts update metadata only. If a computer attempts to retrieve update files on the HTTPS port, the transfer will fail.

    See: https://technet.microsoft.com/en-us/library/hh852346.aspx#bkmk_3.5.ConfigSSL

    So … is encryption only required where CHD is being transmitted? The CDE severs are isolated from the WSUS network by two firewalls.

    • November 21, 2015 at 10:02 AM

      Kind of. Encryption is required for the transmission (all of requirement 4) and storage (all of requirement 3) of cardholder data (CHD) as well as the transmission of credentials that access CHD or access devices that have or could influence access to CHD (requirements 1.1.6, 2.2.3, 2.3 and 8.2.1).

  138. 388 Ash
    November 20, 2015 at 7:46 AM

    Hi PCI Guru,

    Hope you are well! A client of mine is using a P2PE solution. To become compliant, I know they’ll need to go through a QSA validation process etc. and have a RoC completed (as they are level 1).

    But to perform a gap analysis to ensure they have the right controls in place, can they use P2PE HW SAQ just as a reference, instead of going through the full blown PCI DSS standard and choosing which controls apply and which don’t?

    Cheers,
    Ash

    • November 21, 2015 at 8:13 AM

      That is the approach that the PCI SSC recommended at the 2014 Community Meeting in Orlando. However, you need to get your client’s acquiring bank to agree to that approach before adopting it. I think if you explain why you are using that approach, the bank should have no issues with that approach.

  139. November 18, 2015 at 6:38 PM

    Hello PCI Guru,
    I have a question regarding single use credit cards and if the company which is leveraging them are required to adhere to PCI-DSS standards? Also, can anyone speak to using an API which generates a single use card number for a specific purchase and if the application would be required to adhere to PA-DSS?

    Thanks,
    Patti

    • November 19, 2015 at 7:42 AM

      Single use accounts (SUA) is the latest and greatest thing from the card brands – namely Visa and MasterCard. You encounter them the most for insurance payments to health care providers and automotive repair facilities, however they are being used more and more for business-to-business payments.

      I’m in the process of writing a post on SUAs, so stay tuned for that post. However, you bring up a good point about applications that I need to add to the post.

      Thanks.

  140. 392 FDanforth
    November 16, 2015 at 2:04 PM

    Hi PCI Guru,

    thanks for the great info here!

    I’m looking for some guidance about a responsibility matrix or sample contract terms to address req 12.8.5 – can it be as broad as “Service provider is responsible for Req 1-12 of the PCI DSS for all cardholder data that it processes, transmits, stores or otherwise handles on behalf of the client.”?

    Thanks!

    • November 16, 2015 at 3:19 PM

      Going forward, the v3.1 service provider Attestation Of Compliance (AOC) has a table in it that says who is responsible for the gross requirements and comments for those requirements that have shared responsibilities or any special considerations. I also have a number of clients that are using Excel spreadsheets to track responsibilities by individual responsibility as well. I would use whatever you feel most comfortable doing in the way of tracking responsibilities.

      • 394 FDanforth
        November 16, 2015 at 3:27 PM

        Thanks! We’ve already got internal excel templates, so that and/or the AoC will be great.

  141. 395 SM
    November 13, 2015 at 5:43 PM

    Hi PCI Guru,
    We are using iframe solution in our applications , this application is used in our call centers (600 agents). We do not store CC data electronically or on paper and have cleaned up all historical data (backups , call recordings , paper , scans etc). We have implemented clean desk policy , no cell phone policy , DLP , Antivirus etc in our call centers . Call recordings have now pause and resume functionality so no CC number or 3 digit number is recorded . No CSR has access to change any settings or install anything on their desktops . Do we qualify for SAQ A or we qualify for SAQ C VT ?

    • November 14, 2015 at 7:30 AM

      First. Regardless of what I think or you think, it is only your acquiring bank that can give you the “official” answer to your question. You can make a case, but it is the acquiring bank that will decide.

      I have a couple of questions. Does your organization host the iFrame or is the iFrame provided by a third party? I am assuming from your statement about pausing call recordings, your operators manually key cardholder data (CHD) provided by callers. Is that accurate?

      If the answers to those questions are (1) third party and (2) Yes, then I would say you need to do an SAQ A and an SAQ C-VT. That said, if you look at the requirements covered by both SAQs you will find that the requirements in SAQ A are also covered in SAQ C-VT, so you should just be able to just use SAQ C-VT. But this is just MY opinion. You need to discuss this with your acquiring bank and get their approval.

      • 397 SM
        November 14, 2015 at 8:13 AM

        Yes , iframe solution is hosted by third party which is also our acquirer , but application is used in our call center and CSR manually key in CHD in iframe . CSR use desktops for emails and also for applications and desktops are connected to internet and internal network . So are we still eligible for SAQ C-VT ?

      • November 15, 2015 at 9:36 AM

        Yes, you should still be able to use SAQ C-VT. You will need to ensure that your customer service personnel’s PCs are properly secured and monitored. But I would argue that securing those PCs to basic security standards (i.e., security 101) that those systems are secured as best they can be.

  142. 399 Charles Y
    November 12, 2015 at 4:42 PM

    What are the activities and responsibilities of a customer who has its entire online shopping website to a hosted ecommerce platform suchas Demandware? Does this company need to submit a SAQ themselves or ask the provider to do so?

    • November 12, 2015 at 5:10 PM

      If you are truly outsourced, only eCommerce and you are a Level 3 or 4 merchant, you are required to submit an SAQ A. If you have any other payment channels such as mail order or telephone order (MOTO), brick & mortar retail or other channels, then you need to address those as well with other SAQs.

      Demandware should be providing your organization with their Attestation Of Compliance (AOC) that will cover their PCI compliance requirements. That said, you do need to ensure that all of the service Demandware provides your organization were assessed under that AOC. If not, then you will need to include those areas in your own assessment which will change what SAQ you can use to most likely an SAQ D.

      • 401 Tarek
        January 28, 2016 at 7:32 AM

        With regards to the “brick and mortar” component of this, what if all channels of payment processing are handled by a managed service provider? We have [unattended] kiosks that are owned and maintained by the MSP and are not connected to our organization’s networks in any way; they do use a merchant account tied to our organization for processing payments, though. Does the location of these kiosks change anything scope-wise (some are on public property, others may be considered on our premises)? We’ve been treating this as a situation where we require a AOC/ROC from the MSP, but I’m unsure if we’re choosing the right SAQ to go along with it.

      • January 28, 2016 at 9:58 AM

        You have outsourced those kiosks to a third party and you are relying on that third party to properly maintain and secure them regardless of their location. In my opinion from what you have shared, you have properly dealt with them by relying on the MSP’s AOC/ROC.

        As to what SAQ your organization should use, we have spoken a lot about a lot of things/situations and I’m really not sure as to how to advise you in that regard. I would recommend that you consult with your acquiring bank as they are the ones that will provide you with an official answer. All I can provide is my opinion.

  143. November 12, 2015 at 11:25 AM

    I know that the PCI DSS v3,1 requirements require the use of TLS 1.1/1.2 but … does this extend to all system components even if they are not storing process or transmitting credit card data? Does this mean that system management interfaces — e.g. Microsoft SUS or IBM NIM — for pushing patches etc. must also use TLS? What about the vulnerability scanner?

    The other issue I’m wrestling with is scoping. The 2012 Scoping Toolkit seems to imply that if a jump server is used to access a CHD component (with a firewall between them) then then not only is the jump server in scope (category 2), but so is the workstation connecting via that jump server (with a firewall between them). Is my understanding correct? What does that mean about how that workstation/

    • November 12, 2015 at 3:16 PM

      Any system that is in-scope for PCI compliance (i.e., category 1 and 2) is subject to the mitigation and remediation of SSL and early TLS and that includes any system management interfaces.

      The workstation that connects to the jump server is in scope, but what is the risk on that system? The risk is that a keyboard logger gets on it and obtains the credentials to the jump server. I would argue that as long as that workstation is properly security hardened with anti-virus (i.e., security 101) and you look at log files weekly or monthly, then it should be compliant. If you want to take that further with critical file monitoring and dumping it’s logs to your SIEM, that is up to you.

      • November 13, 2015 at 1:43 PM

        Thank you. This is what I had expected. I’m getting a lot of pushback from the IT organization (I report into information security) which I suspect is is not following internal policies and procedures. I’m contemplating how to tip off the QSA to “dig deeper”.

      • November 14, 2015 at 7:33 AM

        I would just be honest with the QSA and tell them that you have concerns regarding IT’s following of policies, standards and procedures when it comes to this situation. If you have specific examples of this problem, I would share that evidence with the QSA. Regardless, they will either find a problem or not, but at least you expressed your concerns.

  144. November 12, 2015 at 10:41 AM

    Concerning the prohibition of older versions of TLS. The 3.1 specification says that older versions of TLS cannot be used as a means to protect cardholder data after June 30th 2016.

    If our ecommerce website uses public key encryption of card data in the browser (using javascript), prior to it being transmitted over older versions of TLS, would that arrangement be non compliant?

    Assuming our ecommerce website does not have access to the private key to decrypt cards it still may be in PCI scope because it “affects” the the acceptance of card payments. But I see nothing in the spec which prohibits it from using older TLS as long as older TLS is not the method for protecting the card data.

    • November 12, 2015 at 3:21 PM

      The only potential flaw I see is how well do you keep your Javascript current? Everything sounds great until we get to that point. If your Javascript is not always kept current, then you will have to mitigate the security issues with using an older version of Javascript.

      In regards to the use of older TLS, you will have to essentially document a compensating control for the situation as your mitigation plan prior to the June 30, 2016 deadline. Once we pass the June 30, 2016 deadline, that compensating control will have to be included with your Self-Assessment Questionnaire (SAQ) or Report On Compliance (ROC) if you are still using the older TLS.

  145. November 12, 2015 at 8:29 AM

    My concern is compromise of customer credit card data, what if an associate posts the credit card data on a Ebay product review site. Am I wondering how could that be controlled.
    For malware we have layered approach of detection and control.

    • November 12, 2015 at 9:49 AM

      I am afraid that in all likelihood is a training issue if you do not have DLP in place.

  146. November 12, 2015 at 4:34 AM

    We have a situation wherein the PCI operational floor has associates, getting customer credit card data and processing purchase on behalf of them. But before they purchase they need to check the best prices and reviews on the internet and the sites could be anything (cannot be controlled or defined) could be given by the customer as well. Due to this, I am not able to put web filtering appropriately and lots of such sites are open wherein there are potential chances that adviser might put the customer’s credit card data on the sites (web) and can pull it and exploit when not at work.
    For example some sites where the user can update the reviews of the product, it could be anything from Amazon to Ebay to any product site.
    I have put most of the systems level controls like AV, DLP, port block right click block, run disabled, No MS office, no document to be saved locally, paperless environment etc.. but even though all of these controls are implement , there are chances that associate can steal the credit card data by posting it on web.
    Can this situation be controlled or will have to live with the risk due to the business requirement and keep spreading awareness?

    • November 12, 2015 at 5:47 AM

      I have dealt with a lot of call centers that have similar situations, but are able to control Web access because the operators are focused on a particular product/service such as health insurance or cell phones. As a result, Websense or similar can be configured to limit Web site access to those sites allowed for a given product/service.

      Based on your business model, what I would recommend is products such as FireEye, Bit9, Tripwire or similar that can provide protection beyond anti-virus, DLP, IDS/IPS and can tell you if a device is doing something unexpected.

      • November 12, 2015 at 7:43 AM

        Appreciate your response, however for example, in a situation where your organization is a retail company and lots of transaction happens where in the call center associate deal with CC data and customer shares the link from Amazon or Ebay, where there is prices comparison, reviews comments etc. Such a page/site is a business requirement to open but the associate can update the CC data as a product review or comment and access it later.
        Security product like Bit9 or Websense cannot technically control, is what I think as I have worked on them.
        Please advise if there is any product which can control this situation. or any other approach you think can work.

      • November 12, 2015 at 8:04 AM

        As I understand your risk, it is the risk that all of this uncontrolled Web access causes some sort of malware to end up on the POS or PC used for that access.

        Bit9, Tripwire and similar tools for example can be configured to ensure that anything attempting to change something on the device is not allowed and an alert generated. Websense and similar tools can watch for malware attempting to be downloaded from a Web site and generate an alert. FireEye and similar tools can be used to monitor network traffic and identify and alert on malware traffic (a last resort in my book). All of these sorts of solutions can be used in concert to minimize the threat that malware ends up on your devices. However, these tools only minimize the risk, they do not necessarily remove it in its entirety. But anyone taking this approach has probably done all that they can to reduce the risk to the lowest level possible.

  147. 415 AA
    November 10, 2015 at 3:35 PM

    In the context of Amazon EC2, is host based IDS/IPS sufficient to meet req 11.4? This requirement is looking for IDS/IPS at perimeter and critical points. If host based IDS/IPS at each ec2 instance is not sufficient, how can perimeter IDS/IPS be implemented in the cloud since there is no “virtual router”, etc. that can be managed through EC2 console? Thanks.

    • November 11, 2015 at 6:26 AM

      This is why a lot of QSAs get stumped when you bring in “The Cloud”. IDS/IPS capability needs to be present whether that is independent through some sort of purpose-built appliance or through host-based. Unfortunately, a lot of QSAs think that host-based firewalls and IDS/IPS are not as robust and proper as their appliance brethren. That said, when you do rely on host-based firewalls and IDS/IPS, you do need to ensure that should they ever become disabled or non-operational, you immediately know that fact and respond appropriately to protect your computing assets.

  148. 417 Moti Huberman
    November 9, 2015 at 8:53 AM

    Hi PCI Guru,
    When sending cardholder data to a payment vendor, is it enough to send it by using TLS,
    or does it also have to be encrypted before-hand, for example, like a password ?
    This is so that if a hacker mounts a Man-in-The-Middle attack, he/she will still get encrypted cardholder data, and not cardholder data in Clear Text.
    Does, for example, Pay-Pal request such an additional encryption in the API that it publishes ?
    Or does it accept only cardholder data sent as Clear Text (albeit over an encrypted TLS transport).

    • November 9, 2015 at 9:54 AM

      TLS alone is acceptable from a PCI compliance perspective, but some people feel that is not enough and therefore they encrypt the data as well. This is what end-to-end encryption (E2EE) solutions and the point-to-point encryption (P2PE) standard do which is to encrypt the payload independent of the transport.

      I do not believe PayPal or any other processors require encryption in their APIs nor is encryption of the payload necessarily supported in the APIs. All of the processors I am aware rely on TLS to secure communications.

  149. 419 Al
    November 8, 2015 at 8:49 AM

    We get a lot of school food orders at head office which we have to process.
    I have noticed that we have a paper folder with with school name and their credit card number written done. The person who places the order does not usually have the credit card so what they have done is they got the number once and passed it to us for future use. Only a couple of people have access to that folder to process payment.

    Our store terminal are provided by chase and they process all credit card payment so we do not need to be pci compliant.

    Is it ok for us to keep the credit card numbers on files on paper with limited access?

    • November 8, 2015 at 8:57 AM

      First, if you accept credit/debit cards for payment of goods and services, you are very much required to be PCI compliant. Re-read your merchant agreement with Chase as it will make that fact very clear.

      Yes, it is okay for your organization to keep primary account numbers (PAN) on file. That information needs to be protect and access to that information needs to be restricted. From your post, it sounds like you have restricted access, but you said nothing about how you secure that information. Ideally, dual control would be perfect where it takes two people to gain access to the card information such as a file drawer that requires two different keys to open or a dual combination safe. However, as long as you have locked up the information and only a few people have keys to the lock is okay.

  150. 421 Jas
    November 6, 2015 at 10:50 AM

    We have soda vending machines that take credit cards and have separate connections from our network. Would we really be in scope for the SAQ B-IP?

    • November 6, 2015 at 3:16 PM

      Are they your vending machines or are they something some third party installed and operates?

      If a third party is responsible for their ownership and management, then it is the third party’s responsibility to be PCI compliant. Otherwise, they are your problem and you are responsible for attesting to their PCI compliance.

      This is where a lot of companies end up in a jam. They have things such as corporate cafeterias, convenience stores, dry cleaners, etc. that are operated by third parties. However, those third parties have point of sale (POS) systems that take cards for payment. Those POS systems are on the corporate network, possibly on a separate VLAN, but most likely not. That turns the corporation into a service provider and makes for a mess when it comes to a PCI assessment.

      • 423 Jas
        November 8, 2015 at 9:27 AM

        Unfortunately they are our vending machines and not operated by a third party.

      • November 9, 2015 at 5:40 AM

        Then you will have to make a decision. Deal with their PCI compliance or get rid of them. I would contact the vendor to see if they have some sort of PCI assessment of their vending machines. A lot of times the vendor will have such a document, but not always. If they do not have such a PCI document, then you can assess them as part of your own assessment. Or, you can remove them.

        I had a client a while back where a few of their store managers installed knock-off Red Box solutions at their stores connected to the retailer’s network. We started up their assessment and found out about these gems. We contacted the vendor (a local company) and determined that they were a dispenser of DVDs with a PC inside that retained cardholder data (CHD). We told our client that they either got the vendor to make the devices PCI compliant or get rid of the devices. The vendor was very clear they had no interest in making their devices compliant, so the retailer removed them.

  151. 425 Dan
    November 4, 2015 at 9:46 AM

    Hi, I have a question around scoping. If a user enters credit cart information into an application through a browser, is the host system running the browser in scope?

    Thanks

    • November 4, 2015 at 1:12 PM

      It depends. If the Web site is doing a redirect or an iFrame, then the Web site is out of scope for PCI compliance. Anything else would put the Web site in-scope for PCI compliance. In either case, the merchant is not responsible for the customer’s PC being PCI compliant.

      • 427 Dan
        November 4, 2015 at 4:20 PM

        Thanks for the response. What if it is someone like a csr entering payment data on behalf of a customer? I’d think even if an iframe/redirect was employed the device the csr is using is in scope.

      • November 5, 2015 at 5:22 AM

        Yes it is in-scope, but what is the risk? The risk with a customer service representative (CSR) using a PC to do data entry into a Web site is that their PC ends up with malware that records their keystrokes, i.e., a keyboard logger. If that PC is securely configured, has anti-virus and is locked down so that no new software can be installed, then in my very humble opinion, you have done what you can to manage that risk.

        It is how you lock it down that is up to your judgement. I have some clients that just set up their group policy (GPO) to keep new software from being installed. I have other clients that are a bit more paranoid and they use things like Bit9 or even Tripwire to ensure that malware does not end up on those systems.

  152. 429 Jonatan
    November 2, 2015 at 12:10 PM

    Hi there Mr! I’d like to get your opinion about the requirement 3.5
    Such requirement clearly states how the encryption keys used to encrypt stored cardholder data must be protected.
    How those requirements applied to the encryption keys used to encrypt transmisions but not stored data?
    An example of these would be an Atalla appliance receiving transactions from a PCI PTS device, decripting the packages received, re-encrypting them with acquirers encryption keys and send it to a transactional server. The entire process is being hold in VRAM.

    It is clear that HSM is storing all encryption keys and no other system get access to the CHD which would means that requirement 3.5 would be not applicable.

    Anyway, I strongly believe that key management procedures required by 3.5 should still be applied to the Atalla key management process even though CHD is not being stored.

    What would you opinnion be about it?

    Thanks in advance!!

    • November 3, 2015 at 6:32 AM

      The key management requirements apply to any key management process including those implemented by a hardware security module (HSM). That said, an HSM has embedded in it all of the procedures required by 3.5 as well as 3.6 with the exception of key custodians. If an HSM does not have all those requirements embedded in it, then it is not an HSM.

      • 431 Jonatan
        November 3, 2015 at 6:59 AM

        Thank you so much for the quick reply.
        I believed what you said but the description of the main 3.5 requirement was the confussion trigger.
        So with the usage of an HSM the only thing they merchants have to have are the procedures defined and also the custodias definitions and acceptances.

        Thanks again!! Have a nice day sir!

      • November 3, 2015 at 7:13 AM

        Pretty much as the HSM’s embedded processes and procedures cover everything else regarding encryption key management and control. That is why an HSM is such a great appliance and a great investment. That said, that is also why when you have an HSM you must protect it like what it is, the manager and keeper of the keys to the kingdom.

  153. November 2, 2015 at 11:01 AM

    Dear PCIGuru,

    Thanks for the great blog. I see a number of other questions about Requirement 1.3 so I know I am in good company. We use a PA-DSS certified payment application to send encrypted credit card data to a payment service operated by the same company that wrote the application. The PAN is tokenized and the token rather than any CHD is stored on our database server. Does that mean the workstations running this payment application are in scope or out of scope for the Requirements 1.3 that are in SAQ-C? In other words, to be compliant do these workstations need to be prevented from general web surfing?

    Here is the payment application vendor’s description of what happens to cardholder data, in case that helps provide guidance for my question:

    “Neither the credit card nor the token is ever stored on any workstation or server for any length of time after the data entry has occurred. As the credit card number is entered into The Raiser’s Edge, depending on what workstation(s) the data is being entered on, that is where the credit card is encrypted and sent to Blackbaud Payment Service (BBPS) securely. The credit card numbers are temporarily stored in volatile RAM, only as they are being entered, and upon tabbing to the next field/row or saving the record (depending on where you are in the program), the card number is immediatel