PCI Penetration Testing
Requirement 11
Requirement 11 of the PCI DSS standard for achieving PCI compliance mandates the need for internal and external penetration testing at least once a year and after any significant infrastructure, application upgrade or operating system change. The PCI DSS also requires regular quarterly internal and external vulnerability scanning. In addition to the quarterly vulnerability scans they should also be undertaken when there are any changes to the network or system components. The external vulnerability scanning must be undertaken by an approved scanning vendor (ASV). However, there is a great deal of confusion as to what the PCI DSS actually means by each term and what the essential differences are between PCI vulnerability scanning and PCI penetration testing. There is also a huge difference between the potential issues found during each type of PCI compliance test and generally a lack of understanding as to what ASV vulnerability scanning / penetration testing results actually mean.
This page is dedicated towards providing the answers to the above and towards giving pragmatic advice surrounding both ASV scanning and PCI penetration testing.
Limitations of ASV Scanning
ASV scanning is an excellent and critical tool in the auditing for security flaws. It gives excellent and important coverage and is cost effective allowing multiple tests to be executed and re-tested within any given period. It is however, limited in that certain flaws in infrastructure and particularly application security can only be located using manual PCI penetration testing executed by experienced penetration testing teams.
What is PCI Penetration Testing
PCI penetration testing is very different to PCI ASV scanning in that a full (rather than automated) PCI penetration test is undertaken. This should be overseen by penetration testing teams that are conversant with the PCI standard although in practice, this is not necessarily the case. …Read More
Engaging a PCI penetration testing firm
With the above in mind, 7Safe’s penetration testing team works very closely (also deliberatively being situated on the same floor) with our PCI QSA consulting team to ensure that our clients receive not only in-depth PCI penetration testing services, but that such testing is set in context of what the PCI DSS actually requires for a particular site. …Read More
PCI Penetration Testing – Case Study
The following case study is based on a real-life example, but details have been omitted to prevent risk to our client. The account is written by Dan Haagman, Director of Information Security Consulting (specifically for this example; PCI penetration testing) who led this particular client engagement.
PCI Penetration Testing – what can be missed…
7Safe relatively recently engaged with a major retail brand to undertake regular penetration testing activities as part of a level-1 PCI compliance programme. The organisation in question takes PCI compliance very seriously and engaged 7Safe to undertake QSA consultancy services, leading the client through the stages of remediation (following scoping and gap analysis exercises). Client A (to which they will be referred to) has extensive QSA experience onboard within the organisation to reflect the continued need and desire to become compliant and to maintain such compliance.
7Safe was then brought in as a PCI penetration testing supplier although ASV scanning services were sought and procured elsewhere for internal reasons to Client A. Client A ran such scans on a more frequent basis than required by the standard and each week reviewed the output for external ASV scanning testing. Initially such scan results yielded many security flaws but a systematic approach overtime towards PCI compliance drove such numbers down and eliminated all “high” and “medium” level issues. Client A was therefore and naturally confident that not only were they doing the right thing, but they were also relatively secure.
However, as part of the PCI compliance requirements and also for good practice, Client A requested 7Safe to undertake PCI penetration testing against their web application, specifically their online e-commerce application that was very customised and developed internally. Overall the security was indeed very good however, on the second day of testing our team discovered signs of a complex SQL injection. Upon further and extensive research into how this was occurring they discovered that the flaw did indeed exist and more importantly, that remote “root” access could potentially be executed. Extensive checking of our PCI penetration testing database and online sources (including the vendor or a third-party module) did not reveal any known issues so safe code was written to exploit the flaw with the client’s permission. This verified that indeed there was a very serious security flaw and that 7Safe had identified a very important “zero day” exploit – this is an exploitable security flaw that is not known by the general security or vendor community (or potentially by anyone). The flaw was importantly, by no means trivial and could only have been found by a target penetration test or malicious hacker, but was there none-the-less. Experience shows us sadly from our work in PCI breaches of security (please see 7Safe’s 2010 breaches report).
With Client A’s permission the vendor was notified and they responded very quickly when given the findings and guidance as to how to fix the issue. An interim, non-public patch was written within 2 days and implemented to close the flaw.
It was in this particular case that the following points were proven;
- ASV scan engines are very good, but they cannot replace the creativity of a very experience PCI penetration tester
- ASV engines are not creative application testers
- If a hacker were determined, they could have “owned” Client A’s infrastructure with greater permission that Client A themselves
- PCI penetration testing in this example, proved to not only satisfy the intent and requirements of the PCI DSS, but also improved security by finding an unknown flaw
- Standards in penetration testing firms vary considerably, especially when it comes to web application security as this relies more on testing experience and knowledge rather than the execution of penetration testing tools.
7Safe’s Penetration Testing Team
7Safe’s penetration testing team undertakes many PCI penetration testing engagements for clients with which we do and do not undertake QSA consultancy services for. The team is CREST accredited and speak on the global stage on application security testing. We also teach the subject in 7Safe’s University Accredited Training Programme;
Introductory hacking course, focussed on Infrastructure and Networks.
Builds on the CSTA introducing the concept of web application security.
