For more information, complete the form below and we'll get back to you straight away.
PCI Penetration Testing Policies. Just Like Buses
Posted by Jon Morris
… nothing for a few weeks and then three come at once.
Last Friday afternoon at the office turned into a somewhat sedate – and welcome – end to the working week. Until I took three sales calls one after each other.
Nothing notable about that.
What was significant was that all asked about how to create a PCI DSS penetration test policy.
Unusual.At last, after many years, PCI version 3 has people starting to think a little more clearly about how to perform penetration testing.
What targets need to be tested? Who should I chose to test? Segmentation? The questions were as varied as they were refreshing to hear.
… and the enquiries have continued into this week as well.
With this level of interest, I thought it would be worth outlining some thoughts for companies embarking on PCI penetration testing for the first time.
The PCI standard now expects that you write your approach down. Making sure that there is consistency and clarity. Developing a simple policy to detail your approach to testing.
Your PCI Penetration Testing Policy should include the following as a minimum:
What to test?
On the face of it – this sounds easy… Your cardholder data environment. The network that stores, processes or transmits payment card data.
Drill down though and a little more work is required.
You will need to perform testing against any external interfaces to your payment network. When we say external we mean ‘facing the Internet’. These will normally be the very same targets that you include for your ASV or PCI vulnerability scans. Remember to include any web applications and any administration tools or web pages.
The internal side of your payment network will also need to be included. This is often overlooked during testing. Possibly viewed as an unnecessary expense. If you have hived off your payment network from unrelated internal networks – then include the boundaries as targets (such as firewalls). Testing the controls to limit access to your payment network is very important.
And don’t forget the CDE itself. Include any wireless connections.
When to test?
PCI is pretty clear on how often penetration testing needs to happen. Either once a year or after a major system change.
So what is major?
There are no hard and fast rules to this. Think of it as a significant upgrade to an Ecommerce application – as in a new version release. A change that requires careful planning and testing.
In truth, most companies will simply test once a year – as required for PCI. Any major releases are simply overlooked when it comes to penetration testing. This is an unfortunate fact of life and can lead to major weaknesses and vulnerabilities being exposed.
Don’t rely on your quarterly ASV scans telling you what you need to know. These are a light touch and their effectiveness limited.
To perform PCI penetration testing you can use an external company or someone from within your own organisation. There are pros and cons to both approaches.
Using an external company
This can be more expensive and it can be difficult to find out how good the company actually is. I guess that this is no different from using any third party technical services company.
So, just to help guide you. Make sure that the company you chose has recognised credentials – such as CREST, CHECK or TIGER scheme. This should highlight that the testing is performed to a good standard and meets the basic requirements of PCI.
In terms of cost. You need not pay top dollar any more. The testing market is competitive. However, avoid rock bottom cheap as well. All you will be getting is a glorified ASV scan. Look for a company that tries to understand your requirements and can offer you basic advice on what is required as it schedules and costs the job.
Using your internal staff
Definitely cheaper! But is the testing as effective?
In some case, yes. In most cases, you are going to get someone running a scanning tool over the network. Consider this as no better than running your ASV scan. It could leave you wide open.
If you are going to use someone internally – make sure that that person is up to the job and can perform competently. Also – make sure that the person is not the developer or the network administrator that manages the network, as all independence is lost. Put bluntly, turkeys do not vote for Christmas.
So, lots covered and most definitely more to add.
The best piece of advice is to plan your testing. Identify who is going to test. Finalise what areas of your network are to be included.
Create a PCI DSS Penetration Test Policy that works for you.
For more information on creating a PCI DSS Penetration Test Policy