Raising the standard of PCI DSS
Raising the standard of PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is approaching its third iteration – and with it comes another chance to make the global standard fairer, more relevant and fit for purpose. By Phil Muncaster.
It's nearly seven years since the first version of the PCI DSS was launched, and the challenge, as always, is to stay on top of ongoing, rapid developments in technology while encouraging organisations to effectively secure cardholder data and not simply resorting to a check-box compliance mentality.
The PCI Security Standards Council (SSC) – originally set up by the card companies to develop the standard and create education and awareness around it – is currently determining what changes will go into v3.0 based on industry feedback. These expected changes will be shared this autumn before a final update is published on 7 November, according to the current timetable, although the final compliance deadline isn't until 31 December 2014. So what might be on the horizon with PCI DSS 3.0 and how will it affect UK businesses?
Although the core 12 areas of the standard won't be touched, there will be more changes than in version 2.0, mainly in the form of additional sub-requirements. “There will be improvements around clarification and improving the wording so people are clearer on what they have to do,” says Jeremy King, European director of SSC. “But there won't be that many changes and where there are they'll be related to how the criminals are attacking the merchants. Through community feedback we're helping to drive the development of the standard so it remains appropriate and applicable.”
The council is concentrating on three key areas in this update, he says: education, flexibility and “security as a shared responsibility”. On the first point this means ensuring merchants are better educated around password security and protecting their data against some of the most common malware-based attacks.
“Rather than make the requirements more prescriptive, we're trying to facilitate better implementation of the current requirements through improved validation methods (testing procedures), additional guidance and greater flexibility on ways to meet the requirements – for example, Requirement 11.5 using a change detection mechanism instead of specifying file integrity monitoring,” explains King. “We're also looking at updating the daily log review requirements (10.6) to help organisations focus on the logs/alerts that they need to be looking at on a daily basis in order to detect suspicious activity.”
Another change that will help with the education piece – for merchants and the qualified security assessor (QSA) – is a plan to include guidance and clarification on the intent of the requirements in an extra column alongside the requirements themselves, rather than in a separate supporting document, King adds.
SSC says it is also hoping to include guidance from its Special Interest Group on third-party service providers in Requirement 12.8, so merchants understand exactly where their responsibilities lie – ensuring that they can maintain a strong but flexible security architecture.
Mobile is another key area and a “huge challenge for the entire industry”, according to King. The new mobile payment acceptance technologies, such as Square and iZettle, coming onto the market won't directly change the PCI DSS, he says. However, the council is working with developers and merchants on upcoming guidelines and evaluation programmes to ensure, for example, that any data recorded by such systems is immediately encrypted.
The view from the ground
That's the view from the top, but what do the merchants who have to comply with PCI DSS want in the new standard? Rowenna Fielding, information security manager at the Alzheimer's Society, is currently managing a PCI change project at the charity, which is a ‘tier 4' merchant. She argues that because version 2.0 is worded too vaguely in parts, it becomes the individual QSA's job to interpret it.
“There are lots of interpretations and no definite answers,” she says. “Parts of PCI are extremely prescriptive and parts of it are very woolly, so consistency would be useful. You can be prescriptive about security without making it unduly difficult for organisations, because it's all good practice.”
The section on information security training and policy is well-written, but the part dealing with ‘network isolation' lacks enough definition around exactly what this should entail, she explains. Fielding also argues that there is not enough definition in v2.0 on what constitutes a breach, meaning acquirers could theoretically dictate and fine according to their own commercial interests, rather than whether or not a particular ‘breach' had actually put card details at risk.
“Our acquirer has been spectacularly unhelpful because as far as they're concerned, they can charge fees and levy fines, so if we have a breach they don't care,” she argues. “Putting the acquirers in control of the relationship between the acquirer and merchant has had unintended consequences. They can put whatever they like in their terms and conditions, which makes it something more to do for commercial gain than good information security practice.”
She claims that an independent Information Commissioner's Office-style body is needed to manage the relationship between acquirer and merchant so as to put an end to the influence of commercial interests.
However, not everyone agrees. Neira Jones, former head of payment security at Barclaycard and now partner at payments consultancy Accourt, says Fielding's experience is uncommon, as all acquirers should have a “duty of care” to look after the entire payment value chain.
“When I was at Barclaycard, I took the relationship with the merchant very seriously in terms of understanding what they were trying to achieve and the problems they were facing,” she says. “There should be an open, three-way relationship between QSA, acquirer and merchant, and if there's a difference of opinion, they should all be able to get together to resolve the issue.”
Jones says she would like to see v3.0 incorporate some of the guidelines on mobile payment security released last year, as well as more clarity around third-party management, and the inclusion of some specific controls relating to common security risks such as SQL injection attacks.
Like Fielding, she argues that because much of v2.0 is written as a mandatory set of rules, merchants and QSAs are often in danger of following a check-box approach to compliance that does little to improve security.
It would help if PCI DSS was crafted in a more risk-management-oriented manner to help companies slot it into their enterprise-wide risk programmes, she says.
“Increasingly, we're seeing QSAs looking at PCI pragmatically from a risk management point of view, so my advice would be to interview them and do due diligence first to see if they have this approach,” she adds. “Make sure they are ISO 27001 accredited and that they have a number of years' experience in your sector.”
Getting tough on testing
One of those QSAs is Trustwave. Its EMEA director of delivery, Michael Aminzade, agrees that QSA selection is key for merchants, who should be looking for whether Reports on Compliance have ever been rejected or prospective assessors have a legal department to review reports. “The way we deal with it is with an internal compliance review board. That's how we give consistency because it is a challenge for every organisation,” he says.
Aminzade wants a requirement for more frequent merchant risk assessments, possibly quarterly, tighter controls for service providers and third-party management, and more on point-of-sale security, especially mobile endpoints. “Mobile malware was up 400 per cent according to our pen tests, so cyber criminals are definitely targeting this area for personal and financial data,” he adds. Aminzade also agrees with the wider point that PCI DSS needs to move from a control-based to a risk-based approach, although he says the time scale should depend on the maturity of each market.
“The challenge is that some of the old controls might not be applicable in a risk-based approach, while other, new ones might appear, so there needs to be a way of dealing with that,” he argues.
From the SSC's point of view, however, there is already support for merchants and QSAs that want to take a risk management approach to the standard. The council has its prioritised approach – a set of separate risk assessment guidelines including ‘six security milestones' – specifically to help merchants address risks according to priority.
King explains that the SSC is constantly improving the quality of assessments through regular training of assessors, and encourages merchants to give feedback on poor service so QSAs can be remediated. QSAs can also expect more rigorous testing to clarify the level of validation the assessor is expected to perform in ensuring compliance with v3.0, according to the council.