If your organisation is compliant with PCI DSS, chances are you’re conducting penetration tests on an annual basis. This “ticks the box” from a PCI perspective, and your QSA will have no problems marking you as compliant – but is a box-ticking penetration test really enough?
The answer to this question really depends on your organisation’s ethos. Is “just enough” acceptable, or do you want real confidence that your crown jewels (in this case your customer’s cardholder data) are safe?
An annual penetration test will always have limited value in isolation, whether your motivation is PCI DSS or not. The test provides an excellent snapshot of your security posture, a point-in-time view of how secure you are, and an opportunity to identify vulnerabilities and then remediate them. The problem with a yearly testing schedule is that if you’re relying solely on penetration testing to highlight a vulnerability in your infrastructure – as is often the case – your organisation could be exposed to known vulnerabilities for a long period of time without ever knowing.
At the time of writing, there have been nearly six thousand new vulnerabilities disclosed already in 2018. That’s around forty-five per day, a slight increase on the forty-per-day average we saw in 2017. In practical terms, this means that within one month of a penetration test, almost fifteen hundred new vulnerabilities will have been disclosed, some of which may exist in your environment.
For this reason, an annual test should not be relied upon as the sole means by which you identify vulnerabilities that may be exploited by criminals. Regular testing can help address this, with the frequency determined by gaining a solid understanding of the threats to which you’re exposed. There should be a focus on critical assets and areas of your business that are more prone to attack, and more likely to be exploited. Additionally, this should be supplemented by more frequent, or even continuous, vulnerability scanning.
Compared to a penetration test, a vulnerability scan is more “light touch”, and is generally less invasive. Whilst vulnerability scanning doesn’t provide the same deep assessment as a penetration test, it provides a cost-effective way to get a view of the vulnerabilities you’re exposed to, and on a more regular basis. As a result, your organisation is able to remediate issues more quickly, and reduce the likelihood of a criminal finding and exploiting those vulnerabilities before you do.
PCI DSS requires you to penetration test annually, and run vulnerability scans quarterly. This can hardly be considered to be a gold standard, but as a minimum requirement is certainly a good place from which to start – but how can we improve on this, and why should we?
This is where “Red Teaming” comes in. Red Team exercises are traditionally mostly considered necessary by large organisations, or where an organisation is deemed to be especially at risk or could be targeted. Red teaming differs from penetration testing in many ways, from the length and scope of the engagement to the sophistication of the attack and the experience of the team conducting the test.
Penetration testing is generally performed based on a scope provided by the client, usually focussed around internet-facing services such as your corporate website. The test is conducted at a time agreed upon by and known to the target, and little effort is made to be discreet – the objective is simply to test the scope that has been agreed upon. Whilst the results can prove invaluable – do they actually provide us with adequate assurance that our customer data is protected?
A real-world attacker is unlikely simply to point their lasers at your organisation and hit the fire button. More likely, they’ll do their homework and look far beyond the scope defined in your annual penetration test. The attacker may expose weakness through social engineering, physical security, and your supply chain – and might not look to attack from where you expect. They might gain access to a less protected area of your organisation, where the threat is considered to be lower - and look to leverage this position to gain further access.
The real problem here is that a penetration test is inherently biased by an organisation’s assumption about where an attack could come from, and what it will look like. A red teaming approach is different, as it focuses more on the asset we’re trying to protect – in this case, credit card data.
An organisation that wants to gain real assurance that they’re protecting cardholder data should consider a red teaming exercise. The goal of the exercise is beautiful in its simplicity: gain access to cardholder data. By removing bias, and focusing your efforts on the goal, you may get surprising results. Simulating an attacker’s likely methodology can provide invaluable insight, and ultimately could prove to be the difference between being compliant, and being secure.
Does PCI DSS say you have to take this approach? No, absolutely not. Will you still need to conduct traditional penetration testing and vulnerability scanning? Yes, to maintain your compliance you’ll still need to do this. So why should you consider a red teaming approach to PCI DSS testing?
The answer is simple, and returning to my original point – it comes down to whether your organisation is content doing “just about enough”. A red teaming approach to penetration testing for PCI DSS won’t be for everyone, but for organisations that value their customer information, and want to actively demonstrate a commitment to protecting it – you should consider whether ticking the box is sufficient.
