“The service we received from Ambersail was first class, with clear advice and guidance which helped us to rapidly progress through compliance audits to achieve full Level 1 PCI DSS status. We found Ambersail flexible, approachable and easy to work with. Engaging with Ambersail was undoubtedly beneficial to meeting our PCI compliance goals.”
Director of Technical Services, PayWizard plc
What is PCI Penetration Testing?
If you are working towards PCI DSS compliance and have a Cardholder Data Environment (CDE) you will need to perform penetration testing.
See Section 11.3 of the PCI DSS here https://pcisecuritystandards.org.
PCI Penetration testing checks your CDE for security weaknesses. This will include interfaces with the public Internet, interfaces to unrelated internal networks and the components that sit in the CDE.
You will also need to consider critical systems. These sit in the CDE and are involved in the processing or protection of cardholder data. Examples are security systems, Internet-facing devices and databases. Indeed, any system that stores, processes, or transmits cardholder data.
For our penetration test team, common targets are web applications, firewalls (or VLAN ACLs), wireless devices and databases. You will find more details on what needs to be included in PCI DSS Requirement 6.1.
Penetration testing should be performed at least annually or after a major system change. It often coincides with completion of a ROC or the SAQ (Report on Compliance and Self-Assessment Questionnaire respectively).
The actual Penetration Testing requirement in PCI DSS 11.3 consists of:
11.3.1 Perform an external penetration testing on the CDE (reviewing the CDE from the Internet).
11.3.2 Perform internal penetration testing on the CDE (reviewing the CDE from the within the company network).
11.3.3 Any exploitable vulnerabilities found during penetration testing are corrected. Testing is then repeated to verify the corrections.
11.3.4 Segmentation testing performed to validate that the CDE is isolated from other networks that do not store, process and transmit cardholder data.
Affordable And Straightforward Penetration Testing
If you need high quality PCI Penetration Testing of your payment card network, you have come to the right place. Ambersail has been performing PCI penetration testing for many years. We specialise in scoping, testing and securing Cardholder Data Environments.
You can expect:
- Helping you understand what needs to be tested.
- Advising you on what to test for segmentation (for 11.3.4).
- Choose a company that delivers the right results and advice to get PCI DSS compliant. We have worked closely with the QSA and ASV programmes for over ten years.
- Very competitive prices for all our company services.
- We perform testing to meet your timescales.
- Our CREST team has tested large and small clients for over a decade.
- Easy to understand reports with clear advice.
Contact us to get started.
Need To Know More On PCI Penetration Testing?
How Often Should Testing Happen?
PCI DSS 11.3 is clear about this. Testing should be performed at least annually or after a major system change.
Ok, so what is a major system change? Well, this is something that many people get confused about. Examples are network or application upgrades. If you know that the change affects areas of the CDE that are high risk, then test.
The Devil Is In The Detail…
As with the much of the PCI DSS, you are going to have to create Policies and Procedures for your security testing. Make sure you include when you test, who performs the test and what needs to be tested.
If all this sounds a little daunting, do not worry. We have tried to be as helpful as we can and included a sample Penetration Testing Policy and Procedure to help you on your way!
PCI Penetration Testing Payment Applications.
Companies often take payments over the Internet using a bespoke web application. This is a critical target for PCI Penetration Testing as it provides a trusted communications route directly into a company’s CDE.
The PCI standard lists the types of vulnerability that should not exist on a web application. This is first introduced in Section 6 which deals with code development. These types range from 6.5.1 Injection Flaws to 6.5.10 Broken Authentication and Session Management.
This list comes direct from industry research to be found at OWASP (Top Ten): https://owasp.org/index.php/Category:OWASP_Top_Ten_Project and SANS (CWE Top 25): http://cwe.mitre.org/top25/
Both these sources offer best practice advice on common vulnerabilities and are extremely useful.
PCI Penetration Testing CDE Networks.
CDE networks are a prime focus for PCI Penetration Testing. As a tester, we look for poorly configured networks, insecure services running, old (and insecure) software running and poor password management.
Following on from application testing above, there are PCI requirements that help improve network security. So take a look at Section 2 of the PCI DSS and you will find details on system hardening . This applies to how networks are built. If you follow these guides you will remove well-known weaknesses with technology.
PA DSS and Off The Shelf Applications
When PCI Penetration Testing you may not need to include all applications. For example, if it is PA DSS Validated (See here: https://pcisecuritystandards.org/assessors_and_solutions/payment_applications) it will not need to have its functionality tested. Only the network that supports the application will need to be included. In other words, how the application is implemented.
Remember that PA DSS Validation works to specific versions of an application, so make sure you have the correct version listed on the PCI Standards Council’s site.
Certain off the shelf web applications can be treated in much the same way. Third parties develop and maintain these applications. Examples are web mail tools, document sharing and file transfer systems.
Again, you only need to include the supporting operating system and supporting network services in the penetration test.
Some Useful Links…
Contact Our PCI Team To Get Started.