It has been estimated that becoming fully PCI compliant gets you no more than 47% of the way towards a recognised industry standard for information security. In this case, ISO 27001:2013.
The chart below shows a comparison of how the PCI DSS requirements stack up to the ISO 27001 control objectives:
While this is a somewhat unfair comparison (PCI DSS is a collection of specific security controls while ISO 27001 is a controls framework), it is nevertheless clear that the PCI DSS does not include a significant number of controls that are required in ISO27001.
However, in PCI’s defence, it was never meant to. It was designed as a minimum set of security controls exclusively for the protection of cardholder data. Nothing more.
The problem since then unfortunately is that PCI compliance has been mistaken for broader information security and secondly that compliance was a goal in and of itself instead of what it is: just the beginning.
All security activities should start with a risk assessment and business impact analysis. However, PCI compliance is mandatory for anyone who accepts branded payments, no matter what the results of any risk assessment might say. The applying business has to comply with every requirement, with no allowance for any residual risk in sharp contrast to all (security) risk management frameworks.
We should remember that the controls within the PCI DSS are already the results ofa risk assessment, one conducted by the 5 principal card issuers (AmEx, Discovery, JCB, MasterCard & VISA) way back in 2004 prior to release of PCI DSS v1.0 on 18thDecember 2004. It was clear to many security professionals early in PCI DSS’s life cycle that the requirements should have been plugged into a more robust security framework. One that makes sense for the business as a whole, not just with respect to cardholder data.
Then, in a further effort to make the PCI standard look more beneficial to the applicant, a very brief nod was given to the area where most businesses actually care most – staying in business. A single bullet point in a single requirement (12.10.1.a) asks for “Business recovery and continuity procedures” – these are arguably the critical features of any security programme, not just a subset of Incident Response.
There are a number of opportunities to improve the PCI DSS coverage; these include:
- Payment cards are based on 50+ Year Old Technology: Why spend significant amounts of capital and resource on obtaining PCI compliance when businesses will soon (if not already) need new payment channels for mobile, cryptocurrencies, the Internet of Things, and whatever comes after next in the world of digital payments;
- Conflict of Interest: A single vendor can (for example) 1) sell you a firewall, 2) manage and maintain/monitor/test/assess it for compliance. All that is required is the vendor to declare these multiple interests; where is the segregation of duty?
- Governance: Interestingly, the word does not even appear in the PCI DSS. Risk assessment, control implementation in line with business continuity, change control, security strategy in-line with business goals and so on all require some form of governance;
- Weak Controls: From the continued use of the word ‘periodic’, to lack of a management systems framework, to logging and monitoring, the control requirements have always been less than comprehensive and in need of tightening;
- Validation & Sampling: Sampling of like systems makes sense but, when combined with the annual ‘point-in-time’ aspect of an assessment, this means that you can end up with evidence 364 days old taken from only a fraction of the production systems;
- Threat Landscape: With a 3-year revision life-cycle and an inability to change radically, the PCI DSS will always lag behind current, and especially zero-day, threats.
Each of the above, with the possible exception of the first, are fundamental aspects of a good security programme, as are every one of the PCI DSS’s controls.
Perhaps we should remind ourselves why it is that the PCI DSS exists.
The steep rise in the number of breaches and related losses to fraud in the early 2000s forced the issuing card brands to do something so radical that we are still talking it about 15 years later. They required every merchant and service provider who touched a branded card to become compliant with a security standard: on 18thDecember 2004, PCI DSS v1.0 was launched. It’s also worth remembering that the UK introduced Chip&Pin to safeguard all card payments on 14thFeb 2006 while the US only did the same as recently as 13thApr 2018. Interestingly, there remain a large number of organisations that are still not compliant with the bare minimum!
Take the phrase “cardholder data” out of the PCI DSS and replace it with “personal information about your family”; now name one control that you don’t want in place?
It has been said many times by many people: PCI DSS compliance should be the result of an information security programme done well. Moreover, the same should result from ISO 27001 certification, GDPR compliance (for the security of data only), and whatever information security compliance regime / standard / framework / regulation that comes next. Unfortunately, few organisations implement appropriate security just because it’s the right thing to do.
Until they get breached …..!
If you would like to learn more about our services, please click here or contact us at marketing@2-sec.com or call our office on 020 7877 0060.
Written by D. Froud.