In late March 2015, the PCI-SSC released a document that detailed a guideline for Penetration Testing, specifically from the perspective of PCI-DSS Compliance. Penetration testing, especially after the PCI-DSS v 3.0 had become a major grey area for several companies. Personally, I had seen companies grapple with Penetration Testing issues, questions and clarifications that firmly fell within the “I’m not sure” quadrant, which is the worst place to be, with PCI-DSS compliance.I have gone through the guideline (available here) and I have identified some significant aspects of the Guideline that I would like to cover in this article.
An important question in most PCI Penetration Tests we do is “Should this be a black-box test?”. In several cases clients try and push for black-box tests hoping that they would yield less results, consequently ensure less issues that need to be fixed. In a blackbox assessment, the client offers no information related to the targets or the host(s). The Penetration Tester must “figure it out”, identify vulnerabilities and launch exploits against the applications or components on the network. The guideline identifies that Blackbox assessments don’t offer much value to PCI, as they are inefficient from a cost and time perspective. PCI requires that Penetration Testing be done with a white-box perspective or a grey-box perspective, where the client provides information relating to the targets (IP Addresses, Network Diagrams, dummy creds to applications, etc). White and Grey Box Assessments are definitely more effective and efficient. Remember, an attacker has all the time in the world, but a pentester has a specific cost and time goal that needs to be met. Good Move!
The PCI-SSC has specifically mentioned Authentication testing in custom applications. This should really be “Authorization” testing. The Guideline specifies that companies should test custom apps for multiple authentication roles. For instance, if your app has a super-user, admin, regular user, etc. roles, the Penetration Tester must specifically test all roles, especially for Elevation of Privileges. This is especially true in POS applications, where a restricted user (billing clerk) does not have access to cardholder data after the billing, but through specific attacks, if she can elevate privileges, then the application is vulnerable in a significant way. Another area where Authentication Testing is key is in multi-tenant environments. These are environments where multiple customers are hosted on the same server or application. Elevation of Privileges in such environments is critical and the penetration test must validate this possibility. This also means that the client must provide the pentester with credentials to multiple roles within the application in scope. This is a good move, but will significantly increase time taken to perform the test. As a Security Professional, completely agree with this requirement, but I can hear purse-strings tightening everywhere.
The PCI-SSC has clarified a critical stance on PA-DSS apps. Their view is as follows: “If its a PA-DSS validated app, don’t bother with the app, just test the OS and its services”, essentially reducing the PA-DSS app pen test to a network layer penetration test. Similarly, with Commercial Apps, PCI-DSS requires that the implementation of the app be tested, but not the app itself. I don’t agree with this stance. There are several times, we have found serious “application related” security issues in both cases. And while one may argue that this must be raised as a ticket with developer/company and that must be sorted out through a patch, several companies are notoriously lax in their security updates and patching process. This is a similar story with commercial apps. This would reduce security research and testing on these commercial apps significantly and would reduce the incentive for providers of these apps to improve their security programs. Bad move
This is a good move. To offset possibilities of disruptions to the production environment, the PCI-SSC has specified that penetration tests can be done on test environments. The findings from this assessment must be validated and deployed against production. While this move is fine, I feel that the implementation of this move in many companies is likely to be highly flawed.
This, I feel is a much needed and highly relevant aspect of penetration testing. Recent attacks have shown (Dyre wolf, Sony, etc) that Social Engineering is the start of most deep-rooted attacks and breaches. Therefore, not testing for social engineering is a serious shortcoming of any enterprise security program. Social Engineering is an essential area of penetration testing. we45 has been saying this all along. Great Move!
The new Guideline has mandated that the organization must monitor vulnerabilities over the last 12 months. Additionally, the Penetration Tester must also be exposed to the entity’s and the industry’s vulnerabilities for the last 12 months. This is a serious challenge for most companies as they use the “PDF and Excel” way of managing pen tests. This move necessitates for a solid Vulnerability Management Platform like we45’s VME and Leanbeast. Such solutions provide a clear, query-able view of vulnerabilities and exploits over the past 12 months.
