Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Testing the security of applications and infrastructures for storing, processing or transmitting cardholder data has always been a requirement for Payment Card Industry Data Security Standards (PCI DSS) compliance.
However, the Payment Card Industry Security Standards Council (PCI SSC) has never outlined exactly what is expected of a pentest. This has led to some testing companies doing very basic security testing to simply check the box of requirement 11.3, which fails to provide real assurance that your applications and environment are not readily exploitable.
This because there is a whole world behind the definition of “Penetration Testing”.
We've said that pentesting is a vital part of becoming PCI compliant, but what exactly is this type of test?
Testing your eCommerce website, your payment page or your contact center applications and infrastructure simply means that you are attempting to discover your vulnerabilities before cyber criminals do.
Penetration testers are also known as ‘ethical hackers’ and their mission is to pit the company's systems up against the same means and methods cyber criminals would use to bypass a company’s security countermeasures and steal sensitive data such as intellectual property, payment cards and so on. This is why this type of testing is often referred to as 'ethical hacking'.
The PCI SSC’s first attempt of defining the basics was in 2008, when they produced and distributed an informational supplement called “Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 Penetration Testing”. Its aim was simple: to provide people with more information on pentesting so that they could follow the PCI DSS and become PCI compliant.
But seven long years have passed since that informational supplement was released. During these seven years the industry has observed many breaches and compromises, many of them would have been avoided if proper pentesting was conducted during the PCI DSS Validation process. To address the changes in the security landscape, just like the overall PCI DSS requirements (version 3.0 was released in November 2013), a new supplement on testing was produced.
In March 2015, the PCI Council released a new informational supplement (you can find a PDF of that here) which finally explains what a good penetration test in the PCI world should be like and it provides more details on the components of a pentest, the criteria of what makes a good penetration testing partner and the reporting guidelines of those tests too.
In our Security Blog we review these guidelines and in the present article we concentrate on the scope of penetration test. More will be written during the upcoming weeks about this PDF, in an attempt to make it easier for our readers to catch the sense of running tests and their requirements according to PCI DSS.
When attempting to achieve compliance, penetration tests are important because they represent the final, end of state check to make sure all of the security control required by the PCI DSS have been implemented correctly.
It is quite common that the vulnerabilities uncovered during a pentest are the result of incorrect implementation or the failure to implement requirements. For example, it may be possible to gain access to a system as the server has not been patched in a timely manner (Requirement 6 of PCI DSS v.3.0) or because the web server was incorrectly configured (Requirement 2 of PCI DSS v.3.0).
We all know that our IT infrastructure and applications are as dynamic as our businesses and that’s why in order to achieve and maintain PCI DSS compliance, a penetration test should be carried out at least annually and after every change that is defined as "significant", which may include upgrades to applications or infrastructure or the installation of new system components.
If you are unsure what a major change is ask yourself the question: does this change have the potential to impact on the security of the cardholder data? If the answer is yes, then you are likely to be making a significant change and would require a penetration test.
One of the most important clarifications in the new guidelines is about the scope of penetration testing, to help make sure penetration testers work on the entire PCI DSS environment: the entire cardholder data environment (CDE). The CDE represents the union of all the technology that can “store, process, or transmit cardholder data or sensitive authentication data” and any technology that can affect its security.
This includes both the external and internal perimeter of the CDE and any access points including those from public networks or individual external IP addresses.
As for PCI DSS compliance itself, it is vital that the scope of penetration test is thorough as failing to identify critical technology and then properly testing it may jeopardise your attempts in securing your sensitive data.
This is why the guidelines have properly described, as you can read below, what must be in the scope of a PCI DSS penetration test:
Under the requirements of the PCI DSS, penetration tests can be conducted either by an internal team or by a qualified third-party, as long as they weren't involved in the installation, support or maintenance of the system that will be tested and as long as they are "organizationally independent".
The Payment Card Industry also recommends that you employ a penetration test assessor that is not only experienced but also has certifications to back up their technological know-how.
Get in touch today and find out how we can help your business to achieve and maintain PCI Compliance.
I am the Founder of Advantio.
Technology has been my passion since I was a kid; when I first heard the handshake of an old 300bps modem I realised security would be key in an interconnected world. Since then it has become my passion and primary focus.
The reason why I've started my own business is to make IT Security simple.
Certifications: CISSP / CCSA (Checkpoint) / ITIL Foundations / ACSA (ArcSight)/ Linux+/ PCI-QSA / PA-QSA