Vulnerability Scanning and Penetration Testing

For whatever reason, vulnerability scanning and penetration testing are areas that just seem to continue to confuse people, even information technology personnel.

Vulnerability scanning is the act of identifying potential vulnerabilities in network devices such as firewalls, routers, switches, servers and applications. The operative word is ‘potential’. Vulnerability scanners merely identify potential vulnerabilities; they do not always assess the ability to exploit the vulnerability. To conduct a vulnerability scan requires the use of a vulnerability scanning tool such as Qualys, Internet Scanner, SAINT or Nessus. Moreover, while almost anyone with networking experience can run a vulnerability scanner, it requires someone with significant networking and security experience to interpret the results from a vulnerability scanner.

External vulnerability scans are required quarterly or whenever significant changes are made to the network or applications and must be performed by an ASV against any PCI in-scope systems. Operative word, ‘in-scope’. We have seen many instances where an organization has no Internet presence what so ever and yet they are conducting external vulnerability scans. While not a bad practice, there is no PCI compliance reason to conduct external vulnerability scanning if the organization does not process, store or transmit cardholder data via the Internet. Internal vulnerability scans are also required quarterly or whenever significant changes are made to a network or applications. However, internal vulnerability scanning can be done by anyone that is deemed qualified. Results from vulnerability scanning are to be addressed as soon as possible. This used to be 30 days, but that was found to be a problem as a lot of organizations use off the shelf solutions that require vendors to modify their solutions and that typically does not occur in 30 days or less.

So, what then is penetration testing? Penetration testing takes the results of a vulnerability scan and then the penetration tester, using one or more tools, attempts to use the vulnerabilities identified to compromise the devices with the vulnerabilities. Penetration testing requires the use of tools, sometimes a lot of tools. But it also requires an extremely experienced person to conduct the penetration testing. And yes, penetration testing does have a higher than average chance of causing outages. However, the goal of vulnerability scanning and penetration testing should never be to deliberately put an organization’s online assets out of business.

Penetration testing tools include such software as Metasploit, Core Impact, SAINTexploit and Canvas. Penetration testing tools are much more sophisticated than vulnerability scanners and require a significant amount of experience to use effectively. Most require a good amount of knowledge regarding the exploits that will be used and the environment that they target. Some can directly input the vulnerability results to simplify their use. However, they still require a lot of experience to ensure that they do not create more problems than they solve. The reason? These tools are designed to compromise systems. Metasploit is open source and is used by penetration testers and hackers. For the most part, the exploits for Metasploit are the real McCoy, written by hackers and penetration testers alike. As a result, if you do not know what you are doing, you could leave behind software that keeps the system compromised. Commercial tools typically run ‘sanitized exploits’ that do not fully compromise the system, but they, too, can leave behind software that may also leave a system at high risk of compromise. It takes experience with the exploits, the operating systems and other relevant knowledge to clean up after these tools and ensure that a system will not suffer higher than expected risk to compromise.

For PCI compliance, external and internal penetration testing is required at least annually or whenever significant changes are made to a network or applications. Penetration testing can be performed by any qualified individual. As with vulnerability scanning, the results of penetration testing need to be addressed as soon as possible.

Hopefully, I have clarified what these two methodologies are and are not as well as improved your understanding as to the results they provide.


66 Responses to “Vulnerability Scanning and Penetration Testing”

  1. 1 Ayyan
    November 8, 2016 at 5:30 AM

    I have a very basic question. Let me briefly introduce our setup than I will ask my question
    Our application is hosted at couple of servers at amazon AWS (one Web and one Database). Where we process Card holder data. We access these server using Remote Desktop and upload latest versions using FTP which are being built at our offshore Office. Our main office (sales) is in US and dev/support office in a different country. Considering we don’t store card holder data at our sales or Dev Office
    Do we need to implement PCI DSS practices only on the servers which are hosted at Amazon ?
    Do we also need to implement PCI Practices at our Sales or Dev\support Offices too?

    • November 8, 2016 at 3:26 PM

      It all depends on your scope and how things are connected via your network. Read the Open PCI Scoping Toolkit (http://itrevolution.com/pci-scoping-toolkit/) to determine scope. If you still have questions, get back to me. I have also written a lot on the topic of scoping, so read my series on the topic. https://pciguru.wordpress.com/2014/07/27/the-dilemma-of-pci-scoping-part-1/

  2. 3 Mark
    September 7, 2016 at 9:05 AM

    Hi we support an internal PCI estate. Our client tells us what services are PCI and what is not. They wish to conduct external Vulnerability scan, where they own the external IP, but are demanding the NAT translation and IP of the internal devices. This seems wrong as our internal addressing is not in the public domain.

    • September 10, 2016 at 6:43 AM

      Is your client an ASV or are they contracting with an ASV to scan your environment? As a service provider, I would only allow an Approved Scanning Vendor (ASV) to scan my network, not any client.

      That said, no ASV would ever ask for internal network IP addresses other than to clarify results they are obtaining. ASVs only scan those devices that have an external presence (i.e., they can be reached from a public network). An ASV would request that any load balancers, firewalls or other devices that could influence the scanning results be “neutralized” for their scanner. But the ASV would not need to know the internal IP addresses for any servers for scanning.

  3. 5 JT
    February 28, 2015 at 12:00 AM

    Quick question re: multiple sites. I am interested in your thoughts on internal scans for multiple sites / retail locations that do not have site to site VPN tunnels to a central office that can be used. Do you visit all 50 or 100 sites quarterly to scan the 2 or 3 POS systems that are at each location or can you get away with sampling?

    • February 28, 2015 at 6:35 AM

      This comes down to a couple of key questions. How “cookie cutter” are your retail locations for infrastructure and applications? Do you have all of the same configurations at a POS testing lab? If you do not have POS and infrastructure that is standard at all locations, then I would say that the approach I am about to discuss is not going to be acceptable to any QSA. By this, I’m not saying that you cannot have two to four different configurations or version out in the field. But if there is more variation that that in your retail operations, it gets very difficult for anyone to justify my approach.

      I have clients with huge retail operations all over the US and the world. What they do is to vulnerability scan and penetration test in their POS lab at Corporate monthly or after all changes (they have four variations of POS at their retail locations). Out in the field, they vulnerability scan all locations at least once during the year to make sure that the results match the latest results from the lab. They select a sample of four locations for each of their different POS environments and penetration test those and compare results with the lab. Any deviations from the scans or pen tests are researched and explained as well as more field testing is conducted to ensure that the differences are not systemic.

      This also requires compensating control worksheets for requirements 11.2 and 11.3 that explain the constraints and the controls you have put into place that go above and beyond the requirements.

      The other option would be to temporarily connect to your locations and perform vulnerability scanning of all of your locations remotely. The vulnerability scanner will likely have to scan slowly and you may need multiple scanners as well. I have clients that take this approach and can scan a couple of thousand locations with your number of POS stations quarterly but it takes them almost all quarter to get the scanning done.

  4. 7 PH
    December 3, 2014 at 2:31 PM

    Hi – Thank you for your very helpful website!

    I have a question: Our public IP’s are usually scanned when we do the External Penetration Testing. Do they also have to be scanned when we do the Internal Penetration Testing as well?
    There is a Firewall/NAT.
    Thank you,

    • December 4, 2014 at 6:50 AM

      Internal vulnerability scanning and penetration testing is all about your internal network and internal IP address spaces.

      External vulnerability scanning and penetration testing is all about your externally facing devices. The difference for external, is the issue of network address translation (NAT) or other schemes that obscure devices actual IP addresses such as a firewall, load balancer, proxy, etc. As a result, on external scans, there may actually be some internal IP addresses involved as well as your registered external addresses.

  5. 9 Hunter
    November 7, 2014 at 8:37 AM

    Hi PCIGuru,

    I have a query with regards to performing vulnerability scans and penetration tests on ATM and POS systems. Does vulnerability scan (11.2) and penetration test (11.3) requirements apply to ATM and POS systems? If yes, how do we meet this requirement in a scenario where ATM and POS systems are hardened and whitelisted (allowing only the required services to be running) primarily for the reason that the base OS (i.e. XP) cannot be upgraded due to legacy constraints? And as windows XP is phased out, there will be no patch available to fix new vulnerabilities identified as part of vulnerability scanning and testing activity. Additionally, ATMs and POS systems process only one card at a time, full card numbers are not stored in the ATM/POS systems, transmission between ATM/POS and the central server/switch is encrypted and there are annual reviews performed on ATM and POS systems to ensure there are no gaps in hardening and whitelisting processes.

    • November 8, 2014 at 4:31 PM

      If you have a consistent configuration and that can be proved, you can test one of each type of ATM or POS.

      XP is a generic OS. One version of XP, XP Embedded is still supported until January, 2016 which may be running in your ATMs. POS typically ran XP just like a PC. That said, while not a good practice, the PCI DSS does not prohibit running unsupported OSes, it just requires you to put in place compensating controls to mitigate the risks of running unsupported OSes.

      • 11 Hunter
        November 8, 2014 at 10:55 PM

        Thanks PCIGuru. In agreement with you on unsupported Oses. In the scenario that I’m referring to, due to legacy constraints, Windows XP is being used on ATM/POS systems and compensating controls for requirement 6.1 (whitelisting, monitoring blocked/allowed services, segmentation of network with specific ACLs, disabling USB/CD/Floppy drives) are implemented due to the fact that patches are not available. In this case, adapting to sampling approach and performing vulnerability scans / penetration tests does not have any value add due to end of support from Microsoft for Windows XP OS. So, would implementing compensating controls same as what is implemented for patch requirement (6.1) meet PCI DSS compliance for requirement 11.2 and 11.3?

      • November 10, 2014 at 6:29 AM

        Your approach would have to be used for 11.2 and 11.3.

      • 13 Hunter
        November 10, 2014 at 9:20 AM

        Thanks for sharing your views PCIGuru. Appreciate your feedback and timely response.

  6. 14 Dave
    August 6, 2014 at 5:10 AM

    Quick question around internal scans

    Where do they need to run from? For instance a multi vLAN PCI environment do I run from inside each vLAN? Or do I run from the corporate network into the PCI environment?

    • August 6, 2014 at 2:24 PM

      You need to prove the segmentation in fact works and you need to run them inside the CDE.

      • 16 Bri
        November 6, 2015 at 7:57 AM

        Where does it say this in the standard?

      • November 6, 2015 at 3:20 PM

        See requirement 11.3, first column, fourth bullet which says, “Includes testing to validate any segmentation and scope-reduction controls”.

  7. May 15, 2014 at 8:11 AM

    Greeting PCI Guru. tnx for support. Have a question pertaining to external scans. Our business activities accept credit cards as part of their transactions. From the POS workstation have private IP (NAT) they are sent to the acquirer via encrypted (SSL). Router firewall has public IP. Transaction goes straight to acquirer. Does this situation constitute “internet presence” and is external scan required?

    The other situation is POS uses web to connect servers located in different state. Servers provide private IP to the firewall routers at the POS site. Thus firewall routers have private IP which NAT IPs for the POS workstations. Again the question is, is external scan required even though the POS site uses private IPs? Transaction goes from POS to server via web (IE) ssl then to acquirer.

    Hope I stated the situations correctly.. Again, tnx for all your support.

    • May 18, 2014 at 9:12 AM

      Yes, in all cases the firewalls and/or routers that face the Internet need to be externally scanned to ensure that they are properly configured and protecting your POS environments. NAT is no guarantee that the POS systems in question cannot be “seen” from the Internet.

      And just because the transaction is done over SSL, do the POS systems have Internet access to sites other than the acquirer/processor? If the answer is ‘Yes’, then you have a larger issue but not from externally scanning.

      • May 19, 2014 at 5:32 AM

        Tnx for your comments. How about the second part of my entry, do you have comments for that too?
        “The other situation is POS uses web to connect servers located in different state and POS app on servers. Servers provide private IP to the firewall routers at the POS site. Thus firewall routers have private IP which NAT IPs for the POS workstations. Again the question is, is external scan required even though the POS site uses private IPs? Transaction goes from POS to server via web (IE) ssl then to acquirer.”

        Tnx again for all the information provided. Helps a lot

      • May 23, 2014 at 11:46 AM

        The firewalls are acting as the external interface, so those must be vulnerability scanned and penetration tested. As long as the servers and POS do not have any Internet presence, then they would not have to be scanned.

  8. 22 Ernie
    March 11, 2014 at 1:48 PM

    It has been suggested by our previous QSA that even though we do not have an internet facing presence, that our hardware needs to have internal vulnerability scan perform. So I’ve done that and now management has asked a few questions. Do Potential vulnerabilities with CVSS scores above 4.0 need to be remediated? How and Why do Vul’s with CVSS scores below 4.0 get rated FAIL?
    Thaks, EGS

    • March 12, 2014 at 4:50 AM

      Requirement 6.2 specifically calls out CVSS scores of 4.0 or greater or a vendor patch rated as “critical” must be addressed within 30 days.

      Vulnerabilities with a CVSS below 4.0 cannot create a fail situation unless they were rated by the vendor as “critical”. These are typically rare and the CVSS score is usually adjusted accordingly after the fact.

      There are automatic fails which are for unsupported operating systems such as Windows 2000 and soon, Windows XP.

  9. December 11, 2013 at 2:08 AM


    We had our environment on Amazon assessed by a PCI partners, what I would like to know is they had found bunch of vulns that are categorized as NON PCI low vuln…

    Do we need to resolve them to get PCI or can we just ignore them

    • December 11, 2013 at 5:48 AM

      Vulnerabilities with a CVSS score of 4 or greater need to be patched within 30 days. Other vulnerabilities need to be patched, but there is time frame specified by the PCI DSS. That said, depending on the vulnerabilities, you may be highly at risk of compromise and ignoring that fact because they are “low” scored vulnerabilities. I have had too many experiences where I was able to compromise a network using their “low” vulnerabilities. A true vulnerability management program makes sure that everything gets patched in given time frames.

  10. 26 Hunter
    May 23, 2013 at 12:59 AM


    I have a query with regards to vulnerability scanning and penetration testing. How important is it to conduct PT if my scan results are clean?

    Where I’m coming from is, in my understanding, vulnerability scanning is one part of the PT activity, right? If so, I perform internal and external vulnerability scans for all my systems in scope of PCI and I maintain clean scan reports for these systems every 3 months, would I still have to conduct PT activity?

    • May 23, 2013 at 5:36 AM

      “Clean” scanning results are all in the eye of the beholder. 🙂

      When you indicate you have a clean scan, do you have NO vulnerabilities identified (my definition of “clean”)? Or, do you have vulnerabilities with a CVSS of less than 4 in your scanning reports? If you have vulnerabilities present in your reports, then it all depends on what those vulnerabilities are. I have been in situations where there were a lot of “low” rated vulnerabilities that allowed me using Metasploit to still penetration the systems.

      That said, I have seen instances where the remaining vulnerabilities could not result in a penetration and have agreed that penetration testing is not necessary. In those instances, we created a compensating control to comply with requirement 11.3.

      • 28 Bil
        June 18, 2013 at 4:29 AM

        A penetration tester should do more than just take the results of a vulnerability scan and work with vulnerabilities identified on that. They should also do information gathering, and look a each of the services exposed independent of the vulnerability scan. Scans can miss quite a lot, for example, blind SQL injection on websites, and very weak passwords such as the name of the organisation being tested.

        In terms of penetration testing not being necessary, I think it would be very difficult to assert this unless there are very few services exposed to the internet, and those services weren’t remote access services like SSH or RDP, and weren’t websites.

        I assume the instances you talk about here did only have very limited services exposed.

      • June 18, 2013 at 4:50 AM

        Yes, there is more to penetration testing than just using the vulnerability scan. Any good security testing methodology will be requiring information gathering throughout the process whether it is purely vulnerability scanning or also includes penetration testing.

        In some very rare cases, the cardholder data environment (CDE) is exclusively internal and compromised of only transaction switches behind numerous layers of firewalls. These switches are running something other than Windows and have only the ports open for processing transactions and those ports are not 80 or 443. Remote access for management of these switches is not allowed. As a result, there is not enough surface area to mount an attack.

  11. 30 Gene Shapiro
    January 10, 2013 at 12:14 PM

    Internal Vulnerability Scanning Requirements

    I am new to PCI and looking at what needs to be done to implement it. I have read the PCI 2 requirements and I see the need to do internal vulnerabilty scans per 11.2.1. My assumption is that this is a vulnerability scan from inside the organization thus internal. Is this correct? And when I do these vulnerability scans are they with authentication to the device or purely from an unauthenticated perspective of the internal network components involved with PCI?

    • January 10, 2013 at 1:47 PM

      Yes, internal vulnerability scanning is a vulnerability scan of the internal portion of the cardholder data environment (CDE). That would include infrastructure such as firewalls, routers, switches, load balancers, etc. that are on the inside as well as servers, workstations, etc. Essentially, any device that is in the CDE or has connectivity to the CDE needs to be vulnerability scanned at least quarterly. However, if you read the requirements, you must also re-scan if you have any critical (5), severe (4) or high (3) vulnerabilities found. In the end, the PCI DSS basically has you vulnerability scanning monthly to meet the requirements.

      Authenticated scans are perfect as they typically reduce the amount of false positive results, but they are not required by the PCI DSS.

      A key mistake that we see made is who does the vulnerability scanning in the organization. The PCI DSS requires that the person doing the vulnerability scanning is qualified (i.e., CISSP, CISM, CEH, etc.) and that they are segregated from the people/equipment they are testing (i.e., you cannot be testing your own work). Yet we still encounter network administrators scanning the equipment they maintain.

  12. December 19, 2012 at 6:59 AM

    Hi! I’ve been reading your website for a long time now and finally got the courage to go ahead and give you a shout out from Humble Tx! Just wanted to tell you keep up the excellent work!

  13. December 18, 2012 at 10:42 PM

    This particular posting Vulnerability Scanning and Penetration Testing PCI Guru, possesses truly
    great advice and I actually learned exactly what I was hoping for.

  14. 34 Akash
    January 9, 2012 at 4:00 PM

    Dear PCIGuru,

    Hope you are doing fine. I need a small clarification form you. It is with regards to defining the scope for PCI. As per my understanding, there are Four main things which we should consider while defining the scope for PCI:

    1) Any System, Device, Process or Technology including People that handle cardholder data or sensitive authentication data, comes under the Scope for PCI.

    2) All system components included in or connected to the cardholder data environment comes under the scope. This also applies on any system which is connected to Cardholder Environment regardless if it process any Cardholder data or not. However, it does not apply on the system/ components which are connected to that components. For example, Level A is Cardholder Environment comprise of number of Servers, Routers, and other devices. Level B has few Systems and Network Components, which does not process or store any Cardholder data but directly connected to Cardholder Environment. Level 3 has few other systems which are connected to Level 2 Systems and they also does not process any Cardholder Data. In this scenario, all system at Level 2, which are directly connected to Level 1 Systems, come under the scope but any system in Level 3 does not come under the scope.

    3) All Systems and devices involved in Managing security are in scope such as Authentication Server, Log Server, CCTV Cameras and CCTV Recorders, IDS, IPS etc all will come under the scope automatically.

    4) All systems involved in managing the security of other in-scope systems (i.e. Log Management Servers, IDS Management Consoles, or any device that is used to manage any security server, will come under the scope automatically.

    Please suggest if my understanding is correct or not. Thanks.


    • January 9, 2012 at 6:15 PM

      Be careful with your first point. You are correct as long as you include the statement that all of those have access to bulk, unencrypted cardholder data. For example, cashiers or call center personnel that come into contact with PANs one at a time need to be trained to keep cardholder data private and secure and acknowledge that fact, but that is the extent of their being in-scope. However, the same is not true for POS systems. If the POS only has one PAN at any point in time while the transaction is in-flight and you can prove that no more than one PAN is in the system at any point in time, I would still include that system in-scope because it is a gateway into the systems that do have the PAN stored. Also, a logger could be installed on the system to record all of the PANs the POS comes into contact which is also a threat.

      Again, with your second point, only devices that come into contact with the PAN in clear text or can decrypt the PAN are in-scope. If cardholder data is encrypted and the intermediate devices or cardholder data environment (CDE) connected devices cannot decrypt the cardholder data, then they are out of scope for PCI compliance. Where we need to be careful with this is, can these intermediate devices be used to gain access to encryption keys and therefore indirectly be used to decrypt the data? If they can, then I usually err on the side of safety and include them in the PCI scope. The best example of this is PCs that can conduct transactions, but do not come into contact with the cardholder data because it is encrypted at the swipe on the card terminal. If this PC could be leveraged through malware to gain access to the encrypted stream and also compromise the encryption keys, then in my humble opinion, it should be in-scope. If, on the other hand, there is no way the keys or the stream could be compromised, then the PC should be out of scope, but as a QSA, you need to document this fact.

      The rest of your points I would agree with.

      Let me know your thoughts.

  15. 36 Ranch
    November 16, 2011 at 9:12 AM


    I am trying to get a direct answer to vulnerability scanning for the internal LAN. If I am required to conduct internal scans, and I buy a third party software such as those mentioned in the original post; am I allowed to conduct the scans and submit the results as necessary, or does someone else have to come in and conduct a “qualified scan” every quarter? Is there something that can be done to make myself “qualified” for the scan submission?

    • November 16, 2011 at 8:36 PM

      An Approved Scanning Vendor (ASV) is only required for conducting the quarterly external vulnerability scanning. The only requirement for quarterly internal vulnerability scanning and external/internal penetration testing is that the person conducting them needs to be qualified to conduct them. By qualified, you know how to vulnerability scan beyond just running some tool. You also need the technical knowledge to interpret the results so that appropriate action plans can be developed to address any findings. That said, as long as your are competent at vulnerability scanning, then it does not matter what tool you use. If you are not comfortable with conducting the vulnerability scanning and interpreting the results, then you should hire an outside firm to do it for you.

    • 38 Ranch
      November 17, 2011 at 8:25 AM

      Thank you, in regard to internal scans, is there a requirement at all levels or is this just the highest level only with a C or a D SAQ? I am assuming it is for all since the Questionnaire has an item calling for it, but thought I would ask. ie if I am SAQ C with level 3, is it required to scan my internal network?

      • November 17, 2011 at 9:25 PM

        Organizations using SAQ A have outsourced everything, so by definition they have no technology to be scanned. In the case of organizations using SAQ B, there are only credit card terminals provided by the processor/acquiring bank or manual embossers (aka knucklebusters). In the case of the remaining SAQs (C, C-VT and D), there is some sort of Internet-facing technologies that need to be vulnerability scanned and penetration tested.

        In your case, if you are filing an SAQ C, then you must have technology used to process, store or transmit cardholder data over the Internet. As a result, you are required to conduct quarterly vulnerability scans and conduct at least one annual penetration test.

      • 40 NRS
        February 21, 2012 at 3:43 PM

        SAQ C does not require PEN testing – is that true?

      • February 21, 2012 at 4:33 PM

        You are correct. SAQ C and SAQ C-VT were developed primarily in response to the concerns of the fast food industry.

        Remember, under SAQ C you are not allowed to be storing cardholder data on any of your systems. Also, you cannot have any eCommerce capability, outsourced or otherwise. This is why you can only do vulnerability testing.

        As long as you can prove that your systems do not store cardholder data, you are all set.

      • 42 NRS
        February 22, 2012 at 10:06 AM

        The reason why we have selected SAQ C is because we obtain and transmit card holder data via web services. The card data never gets stored at rest. I see that as eCommerce. The primary web server where the web services reside and few other connected systems are segmented from rest of the network. So that being said, we selected SAQ C and are only complying with controls that are on SAQ C. When I look at the gap between SAQ C and SAQ D – some controls that we are not assessing and will keep me up at night are – Logging and Monitoring and Secure application coding, PEN testing. However, the cost difference for QSA to assess SAQ C and SAQ D is big. So in your opinion are we legally doing the right thing by focusing on only the controls that are part of SAQ C?

      • February 23, 2012 at 7:21 AM

        That is not my decision. That decision can only be made by your acquiring bank. I think you have a reasonable case for doing the SAQ C, but that is just my opinion.

      • 44 NRS
        March 13, 2012 at 2:14 PM

        Hello again. We just completed our external vulnerability scan. The question is – do we need to remediate vulnerability rated as a PCI failure under Potential Vulnerabilities section?

      • March 14, 2012 at 12:17 PM

        Yes, you have 30 days to remediate the failing vulnerabilities and then you must have your ASV perform a rescan proving that all of the failing vulnerabilities have been remediated. Since an amount of time will have passed since the original scan, it is possible that new failing vulnerabilities will creep into the rescan’s results. So be prepared to fix those new issues as well if they turn up.

      • 46 NRS
        March 22, 2012 at 1:42 PM

        Hi! we use corporate desktops / laptops as a virtual terminal to process exception based credit card data that we get over the phone. We have installed HIPS so logically separate them and to protect them against any future vulnerabilities. Now do we still need to scan them using the Qulays tool to identify existing vulnerabilities on the PC?

  16. 47 Akash
    November 4, 2011 at 10:26 AM

    Main confusion is that section 3.3 notes says:


    This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN.
    This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point-of-sale (POS) receipts.

    Now the question is that who will decide the employees and parties who has legitimate business need and who they will be? Does that mean that site admin can see (the person who will process the order or confirm the order) full CC number. Pls suggest, Thanks.

    • November 5, 2011 at 12:37 PM

      This is up to your business management to determine. Typically, the Chief Financial Officer or Controller is the most likely candidate because the majority of the people that do need full PAN access are accountants working on disputes and chargebacks. However, some organizations have fraud prevention departments that also want access to the full PAN. However, we have found ways to allow fraud prevention to still do their job and not have access to the full PAN.

  17. 49 Akash
    November 4, 2011 at 10:15 AM

    Hi PCIGuru. I have another question. It is related with Req. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

     This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN.
     This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, for point-of-sale (POS) receipts.

    In our case, the scenarios is that the application collects the credit card and keeps it in DB, later displays it to an admin from merchant side to bill amount on to it , admin can see the full credit card. I want to know if is it fine that the admin can see full credit card number on screen or he should also be able to see only last 4 digit of CC or some part. As Guidance also says

    “The display of full PAN on items such as computer screens, payment card receipts, faxes, or paper reports can result in this data being obtained by unauthorized individuals and used fraudulently. The PAN can be displayed in full form on the “merchant copy” receipts; however the paper receipts should adhere to
    the same security requirements as electronic copies and follow the guidelines of the PCI Data Security Standard, especially Requirement 9 regarding physical security. The full PAN can also be displayed for those with a legitimate business need to see the full PAN.

    This requirement relates to protection of PAN displayed on screens, paper receipts, etc., and is not to be confused with Requirement 3.4 for protection of PAN when stored in files, databases, etc.”

    Please advise. Thanks

    • November 5, 2011 at 4:59 PM

      In your example you say, “the application collects the credit card and keeps it in DB, later displays it to an admin from merchant side to bill amount on to it” which implies to me that the card has not yet been charge. That means that what your database contains is pre-authorization (pre-auth) data and not covered by the PCI DSS. Pre-auth data exists as long as the card has not been used to process a transaction. Once a transaction has been processed and the merchant has been given an approval or decline, then it is post-authorization (post-auth) data and is covered by the PCI DSS. The card brands have stated that pre-auth data should be protected with the same veracity as post-auth data, i.e., encrypted, restricted access, etc.

  18. 51 S
    November 4, 2011 at 4:15 AM

    Hi PciGuru !

    My question concerns requirement 11, or more specifically 11.4. We have to use IDS/IPS systems, but how can we monitor this if we are told to use strong cryptography and security protocols (req. 4.1) and protect the keys used (req. 3.5) and restrict access to them (req. 3.5.1)?

    Thanks for answering.

    • November 5, 2011 at 12:33 PM

      Hence why encrypted transmissions are considered out of scope. I would have to know quite a bit more detail about your situation and I really do not what that discussion to occur here in public for a variety of security reasons.

      What confuses me is your references to requirements 4.1, 3.5 and 3.5.1 in relation to requirement 11.4. The purpose of 11.4 is to ensure that inbound/outbound traffic from/to untrusted networks is inspected before being allowed into/out of the cardholder data environment (CDE). As such, there should not be any encrypted data streams at that point so that you IDS/IPS can inspect the traffic. So either your IDS/IPS is an encryption endpoint, or you put an encryption endpoint in front of it to accomplish this.

      • 53 S
        November 5, 2011 at 6:44 PM

        Actually, there’s no situation, I’m just studying the standard and trying to master it perfectly.
        I thought that requirement 11.4 and requirements 4.1, 3.5 and 3.5.1 were in relation since we have to encrypt all the CHD.

        Thanks your answer/time.

  19. 54 Akash
    November 4, 2011 at 3:05 AM

    Thnks PCIGuru. So key Management documents and copies of Certificates from CA should be fine. I also wanted to know if there is any document published by PCI Council that what is accepted and what is not accepted as Proof/ Evidence during the Audit. Or if you can please guide me towards some documents that can be used as baseline during Audit process in terms of Evidence or Process etc. Thanks a ton.

    • November 5, 2011 at 12:25 PM

      Unfortunately, the PCI SSC pretty much leaves what is acceptable documentation up to the QSA because of the wide variety of situations that can exist. The best reference I can point you to is the Report Instructions document that was just published in late September. While it does not explicitly call out specific types of documentation, it does explain what the QSA must attest to, so it indirectly points you to evidence needed to be collected to support meeting the requirement.

  20. 56 Akash
    November 3, 2011 at 3:44 AM

    Greetings PCIGuru,


    Can you please suggest what kind of evidence are accepted during PCI Audit. For example, for the req 4.1 (“Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.”), what evidence can be accepted. Is only Design Document should be fine or Auditor should visit the site and see if SSL is implemented or not? Please suggest. Ideally, I would prefer if you can share some document that gives information as what is accepted as an evidence for all the requirement. Thanks.

    • November 3, 2011 at 4:30 AM

      When it comes to documenting crypto methods, we ask for the following. The algorithm (i.e., RSA, AES, TwoFish, 3DES, etc.) and bit strength of the algorithm (i.e., 2048, 512-bit, 256-bit, 168-bit, etc.). For methods that require key management, we interview the custodians and review the key management documentation to satisfy ourselves that strong keys are used. In the case of SSL/TLS, we obtain copies of the certificates used and the review the properties of those certificates. That provides us with the algorithm, bit strength and the certificate authority that issued the certificate. The reason the certificate authority is important is that we still see a lot of self-signed certificates which can easily be spoofed or compromised.

  21. 58 Akash
    October 11, 2011 at 4:38 AM

    Hi PCIGuru,

    As I mentioned PCI Questionnaire from 3.6.4 to 3.6.8, I need to make a process which actually addresses these sections. For example, to address this, Process should include what kind of Cryptography Key can be used such as RSA 1024 (can we use this as RSA 1024 = AES 80 only)?
    2nd, when we should change the key. Time period and also if the person who knows the key, leave the job etc…

    So something like that we need to create. Can you please help me or point me towards some documents which address these sections. Thanks.

  22. 59 Akash
    October 10, 2011 at 6:14 AM

    Hi PCIGuru,

    I need some help in answering the PCI Questionnaire from 3.6.4 to 3.6.8. Can you please suggest if I need to answer these questionnaire, what will be my answer to the Audit team and also, if any process needs to be defined to answer these queries, how that will be? Questionnaires are below:

    3.6.4: Do cryptographic key procedures include cryptographic key changes for keys that have reached the end of their defined cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57)?

    (a) Do cryptographic key procedures include retirement or replacement (for example, archiving, destruction, and/or revocation) of cryptographic keys when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key)?
    (b) Do cryptographic key procedures include replacement of known or suspected compromised keys?
    (c) If retired or replaced cryptographic keys are retained, are these keys only used for decryption/verification purposes (not used for encryption operations)?

    3.6.6: Do cryptographic key procedures include split knowledge and dual control of cryptographic keys (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key), for manual clear-text key-management operations?
    Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and destruction.

    3.6.7: Do cryptographic key procedures include the prevention of unauthorized substitution of cryptographic keys?

    3.6.8: Are cryptographic key custodians required to formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities?

    Please suggest. Thanks.


    • October 23, 2011 at 8:57 AM

      3.6.4 – You are correct in your interpretation. If a key expires, then you need to make sure that you replace it on or before it expires.

      3.6.5 – This is required for public key infrastructure solutions where a shared PKI key exists or if you believe that any encryption keys have been compromised.

      3.6.6 – Split knowledge is typically only relevant to systems that generate keys such as with ATMs or credit card terminals using DUKPT or similar. Those solutions require a minimum of two person that each have half the key that is then used to generate the actual key.

      3.6.7 – You must have procedures or processes that alert you to the fact that keys were changed.

      3.6.8 – Anyone that serves as a key custodian, i.e., they have knowledge of keys – split or otherwise, are required to acknowledge their responsibilities to protect what they know.

      • 61 Akash
        October 27, 2011 at 9:18 AM

        Thanks PCIGuru. This will surely help to improve the document. I also have another query, is there any restriction on using Encryption Algorithm. I mean is it necessary to use Symmetric Key Encryption only or only Asymmetric Key Encryption. Can we use RSA 1024 bit to encrypt and decrypt the data as it is eqv. to 80-bit symmetric key. If so then why? Please advise.

      • October 27, 2011 at 8:35 PM

        The PCI DSS uses the term “strong encryption”. The PCI SSC defines “strong encryption” as “Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).” I hope that answers your question.

      • 63 Akash
        October 27, 2011 at 10:23 PM

        Thanks PCIGuru. In PCI 1.1, they mentioned that Encryption Key needs to be changed at least annually. But it seems in PCI v2 they have changed it to “that key changes are required when keys reach the end of their defined cryptoperiod, rather than “at least annually.”

        So does that mean that year concept is no longer valid. Now key needs to be changed when it is reaching its defined cryptoperiod. Am I right.


      • October 28, 2011 at 4:41 AM

        The problem a lot of large organizations ran into with annual key changes was that the re-key process was taking more than a year to decrypt and re-encrypt to change the keys. In one case, I knew of an organization that it took almost two years to encrypt the data in the first place, so re-encryption just was not on the table. In addition, the Council found that a lot of organizations were relying on compensating controls rather than meet the annual key change objective. As a result, the Participating Organizations successfully lobbied to get the key change requirement changed to what it is today. Their argument was that if strong encryption is used and the encryption keys are properly managed, why is there a requirement to change keys annually? The answer was that there was no good reason that keys had to change annually.

        However, not all encryption keys are created equally. RSA keys typically have an expiration date, so they must be replaced for time to time. PGP keys can also be set to expire, but most users do not set an expiration date. Other encryption schemes can also have expiration dates on their keys. So, depending on what encryption algorithm you use, you may or may not have a key expiration date.

        On the key changing front, I still have some clients that change their keys annually. They feel more secure by doing it annually. They feel it covers job changes and terminations of personnel that might have had access to the keys.

        And before we drop this topic. If an organization believes that any of their encryption keys have been compromised, then they are obligated to change the keys. That is why it is important to have critical file monitoring enabled to observe where you store your encryption keys to ensure that they are not compromised.

  23. 65 Akash
    September 22, 2011 at 2:37 AM


    I have a query regarding Vul Scanning of PCI Systems. Is there any guideline, or ideally Checklist, for this exercise regarding what is allowed and what is not allowed. Like running SSL v2 is not allowed for PCI Systems and even if SSL v2 is configured in most secured manner, it will fail PCI Audit. Similarly, I want to know if there is any checklist (Technical) which can say what is allowed (compliant) and what is not. I remember seen one long back but did not copy. Please suggest. Thanks.

    • September 22, 2011 at 6:09 AM

      I do not remember anything officially published by the PCI SSC that listed services, OSes or the like that were not allowed. I think that list was something supplied by a QSAC as a marketing piece.

      As you point out, insecure protocols are not allowed of which SSLv2 is one. Use of weak keys for encryption is also not allowed. While obsolete OSes such as Windows 2000 are also flagged as failing on a vulnerability scan, you can have a compensating control to allow them to be acceptable. However, for weak encryption keys and insecure protocols, there are no compensating controls that can address those issues.

      As a result, if you cannot construct an appropriate compensating control to address the shortcoming, then it is likely not allowed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


March 2009
« Feb   Apr »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,836 other followers

%d bloggers like this: