The Payment Card Industry Data Security Standard requirement 11.3 requires that you perform annual external and internal penetration testing that also includes application testing. Below is a guide on how to handle your testing requirements.
*Disclaimer* Every company and situation is different when it comes to PCI. Always communicate with QSA(s) when planning your testing to ensure that you are meeting all the needed requirements.
Scope –
First you have to decide how you are going to define the scope of what is going to be tested. This includes which networks and applications are to be tested. This scoping process may also include deciding what type of testing will be done such as black-box, white-box, goal based, etc… The PCI-DSS leaves this scope determination up to your company.
- Be completely transparent on the possible ingress and egress points to your PCI data.
- The goal is to find out your weak points, not to stump the penetration testers.
- If you are limited by cost on the number of IP’s that can be penetration tested, then I would ask if the testers could start with the 3 sets of information below and come up with their own limited list of IP’s to test, or do this yourself.
I’ll refer to these 3 sets of information below as the 3 core vulnerability information sources.
- Full vulnerability scan (unauthenticated or authenticated)
- Firewall rule exports
- Network diagrams
External Network –
- Start with the 3 core vulnerability information sources to determine your testing targets.
- Perform specific application testing on your sites that handle any type of PCI data.
Once your sites start coming up clean regularly, you should consider moving to authenticated testing if you aren’t already doing that type of testing.
Internal Network –
- Start with the 3 core vulnerability information sources to determine your testing targets.
- Hand over information on any specific solutions and dataflows that handle PCI data.
- Use those firewall rule exports so you don’t forget to test the servers that have connectivity into your PCI data network if it is separated from your other networks.
Applications
- Focus on any applications that handle PCI data.
- Do not limit testing to only PCI data handling applications. You should also do penetration testing on system management applications, software distribution applications etc..
- The best application penetration test is to do a source code review in coordination with functional testing.
Remediation
Once you have all the results back from the testing your real work begins.
- Take a risk based approach to determine what needs remediation.
- There is flexibility in your remediation under the PCI-DSS, so chose a logical and consistent manner in how you choose to remediate issues.
As always, it would be good to get your approach approved by a QSA if possible.
Final Thoughts…
The goal of penetration testing is to simulate a malicious (or curious) hacker’s attempt to access sensitive data or systems. You should view this as an opportunity to improve security and not a threat.
Be transparent, use good testers, and try to change your testers every couple of years. Penetration testing is often more of an art than a science, so different people will often find different holes.