A year out from PCI DSS 2.0

Credit: Flickr

At the start of 2012, version two of the Payment Card Industry Data Security Standard (PCI DSS) finally went live, after plans to update it were first announced back in August 2010.

At the end of 2010, and on the heels of that announcement, research by LogLogic found that only 14 per cent of respondents were ‘completely aware' of the upcoming changes to PCI DSS.

Early in 2012, the Verizon Data Breach Investigation Report found that 96 per cent of breach victims were not compliant as of their last assessment (or were never assessed/validated). The vast majority of organisations had failed to be rated as ‘good' – the highest percentage of non-compliance that the report has ever noted.

Speaking to SC, Laurie Coffin, vice president of marketing at Quarri, says that because PCI DSS “just has guidelines and you have to figure out what they mean”, its interpretative format differentiates it from the code of other regulatory bodies.

“It depends how you interpret it and what auditor you end up with; they could be checking boxes,” says Coffin. “The guidelines detail firewalls and encryption, but the rest is about best practice. It is not like other regulations – achieving compliance depends on your auditor.”

In short, PCI DSS 2.0 provides requirements and guidelines on how to store, process or transmit card data electronically.

The key changes include the requirement of merchants to carry out a risk-based vulnerability assessment, while applications involved with credit card data – such as card readers, online shopping baskets and mobile payment systems – must undergo a lengthy and complex code review to uncover any security issues.

Also added is the requirement for tokenisation, to include an extra layer of security. For merchants, this reduces the scope of the PCI DSS assessment, as it uses random numbers and letters instead of storing highly sensitive primary account numbers. Specifically, it minimises risks and decreases PCI audit costs, as tokens are only stored on one secure external server, rather than having multiple parts within the payment chain. 

Dell consultant Rafe Pilling

According to the National Retail Federation in the US, between 2004 and 2009, merchants collectively spent in excess of US$1 billion (A$951,752 million) on compliance, with PCI DSS part of their security programmes. 

Reports from 2012 claimed that the PCI Council is “considering updates to the standard for a potential release in 2013”, and in meetings held in October, on the agenda was clarification of how merchants, acquirers and others should comply.

The payment provider

Earlier this year, paythru, a British mobile payments provider, announced that it was one of the first mobile payments specialists to achieve Level 1 PCI DSS 2.0 compliance.

Paythru was more than ready for the challenge, says Russell Sheffield, director of innovation and development at the company, as it wanted to ensure its clients could reduce the risk of mobile payment fraud.

He explains: “In 2009, we launched a financial services product, and what we developed, no one else had.

“We achieved PCI Level 1, we created a platform and we now own our hosted platform. We are now at PCI Level 2. We first started looking at it 18 months ago and made sure we were aware of the requirements, such as tokenisation. When this was set out, we were ahead of the requirement.

“Tokenisation has always been a central part of our security. In fact, we have taken tokenisation one step further with technology that also verifies whether the person making the payment is the genuine cardholder.”

There is not a lot of difference between levels one and two of PCI DSS, and paythru offers a service that means users themselves do not have to worry about security, says Sheffield.

“We do it on their behalf. Our customers inherit our compliance. We have a fantastic relationship with our qualified security assessor (QSA) and we like that they are tough on us; we have kept in the loop with them and moved to a virtual platform and included the specification so we don't get any problems,” he says.

The managed security service provider

Keeping track of all of the latest industry regulations are managed security service providers (MSSPs) such as Dell SecureWorks, which provides information security services to help organisations protect their IT assets, comply with regulations and reduce security costs.

It recently launched a PCI Compliance Resource Center in the US, designed to help organisations meet and maintain compliance with PCI DSS. The centre offers a range of services, including consultancy. Customers can also access a wide selection of whitepapers, videos and webcasts to assist them in overcoming the common PCI challenges.

According to Rafe Pilling, principal consultant at Dell SecureWorks, PCI DSS 2.0 is a natural evolution and presents a more mature set of standards than the original, and includes only two new controls that must be put in place.

“The majority of the policy is merely clarifications on the previous requirements, which either result in small changes, or make the requirements more pragmatic and flexible,” he says. “This encourages organisations to take a risk-based approach, depending on their own organisation and field of work. Essentially, version 2.0 emphasises a ‘people, process, technology' approach to PCI compliance.”

As of 1 January 2012, it became mandatory to comply with version 2.0, and Pilling feels that generally, the move should be fairly straightforward. However, he warns against leaving it to the last minute and “playing catch-up”, as this would make the transition unnecessarily arduous.

“Organisations that have previously reached compliance by taking a tick-box approach or cutting corners may find that they struggle to meet all of the checks that a QSA must perform under a version 2.0 assessment. It is more comprehensive than version 1.0 and, therefore, doing the bare minimum will not stand up,” says Pilling.

He adds: “Additionally, throwing money at version 2.0 will not achieve compliance. Understanding and assessing vulnerability in relation to the context of an organisation is at the heart of the changes in version 2.0.

“Businesses need to proactively seek new information on vulnerabilities that affect their systems, expanding their view of the threat landscape. On top of this, and more importantly, organisations are expected to be able to determine the significance of these new vulnerabilities in relation to their environment, to rank them and take appropriate action.”

Pilling concludes by saying that only by taking a holistic approach to securing cardholder data can you build a sustainable and truly PCI-compliant environment, and that organisational change is the primary challenge of moving from PCI DSS version 1.0 to 2.0.

“If an organisation allows plenty of time to adopt the new standards and commits to investing in processes, people and technology, then the transition will be a smooth ride,” Pilling explains.

The consultant

Version 2.0's improvements include the standard clarified requirements in a number of areas, particularly with items such as intrusion detection being clarified to avoid a ‘shotgun' approach to deployment, according to Andrew Barratt, a security consultant at Pen Test Partners.

He explains that clarifications were added to assist with virtualised infrastructure and how to assess it, opening up a lot of possibilities for cloud computing vendors.

“The organisations that have achieved compliance under the original version have, for the most part, found moving to version 2.0 a relatively straightforward process,” he says.

“The one exception, and the area of PCI DSS that has confused people the most, is scope. The PCI DSS defines its scope as ‘any system component that stores, processes or transmits cardholder data, or any system component that is connected to them'.

“That scope can be huge, and the rules on how to determine scope can be quite subjective, based on differing views of acceptable ‘network segmentation'. The PCI Council indicated at an assessor meeting that it was aiming to release stronger guidance on this in the future, but it remains contentious between QSAs and their clients.”

Barratt adds that version 2.0 now contains specific requirements for scope to be formally verified, either with tools to scan for card data, or via manual review processes or an internal audit.

He explains: “This is a huge challenge for larger organisations. A multinational retailer may have to assess every location for card data. This could literally take the rest of time. If it's not done carefully, with sufficient expertise, card data repositories or transmission points can be missed, ultimately making the process ineffective.

“Larger organisations will look at the time/risk trade-off and take a sampling approach to this and integrate their QSA in the process, so that they feel comfortable with what is being done. Better up-front analysis of where card data should be helps, but the process should aim to validate that the data flow is correct.”

Risk management gets greater emphasis in version 2.0, says Barratt. It is now a requirement to assign risk rankings as part of vulnerability management processes. These processes must be consistent across both application development lifecycles and infrastructure management, and should also be kept consistent with any risk-based approach to patch management so that vulnerability windows are kept small.

The long-awaited Point-to-Point Encryption standards (PCI-P2PE) have been introduced to the new version. Barratt says the ‘hardware to hardware' approach is expected in future releases that support much more complex payment scenarios.

“Getting the PCI DSS scope wrong is a common source of breach, as organisations typically put less security effort around the ‘out of scope' systems than the ‘in scope' ones, leaving them vulnerable to compromise. If the insecure system still has some connectivity to the card data environment, it can be used to launch an attack and card data is at risk,” says Barratt.

The vendors

New Zealand based Mako Networks specialises in PCI DSS compliance solutions and assisting businesses in securing their networks.

It has completed the move to version 2.0, but it was a challenge, according to chief executive Bill Farmer. “We can only reflect on the extreme amount of work we did to make sure that we were compliant, but it is one challenge and it is a response to what is going on in the marketplace,” he explains.

“You have to start somewhere, so start with securing your environment. No one is going to do it in a week or a month, but if you show your QSA that you have got started, it is not all that hard.”

Chris Nation, the company's Europe commercial manager, believes that from a market point of view, the PCI DSS version is irrelevant – it is about looking at your setup and realising whether or not you have a lot of work to do.

“A lot of the market will say that they do not know a lot or they looked at it but it was too hard, so you get tick-box compliance,” he says.

Dwayne Melancon, CTO at IT security vendor Tripwire, says that from a product perspective, there were not a lot of additional requirements in version 2.0 that needed changes, other than some minor adjustments in policy and reports.

“We made the updated policy available to our customers so they can move to the new version as soon as they desire,” he says. “From the customers' perspective, they also needed to incorporate PCI DSS changes that relate to which assets and processes are ‘in scope' and ‘out of scope'. Version 2.0 provides additional guidance to companies that altered the scope to some degree, but it hasn't had a significant impact on how our customers use Tripwire products for PCI compliance.”

Melancon says that achieving Level 2 compliance did not require investment in new systems or technologies. “We updated our policies, compliance tests, dashboards and reports. These updates were immediately usable with the existing content engine within Tripwire's products,” he adds.

The penetration tester

From the testament of the penetration tester we spoke to, it seems that companies have had differing experiences in complying with the new version of PCI DSS. Amir Azam, a QSA at information security firm ProCheckUp, believes that the reason only a few companies have achieved version 2.0 compliance is that doing so is a lengthy process. The majority of businesses are still in the transition phase, he says.

“According to version 2.0 requirements, companies need to provide four to five types of evidence per individual question, and there are 255 questions. This takes a lot of time and resources to become fully compliant,” explains Azam.

He adds: “Currently, version 2.0 is a compulsory requirement which all companies need to work towards, in order to get on the ‘compliant suppliers' list. This is usually used as a great marketing tool, highlighting that customers can trust their secure payment systems.

“The main issue that companies are facing is a lack of resources – financial, manpower, knowledge and technology. Due to the current economic climate, most of the services are outsourced to PCI-approved third parties, but this makes it difficult to track how third parties are providing these services on behalf of their client.”

Azam concedes that for companies in control of their own resources, achieving Level 2 compliance requires investment in new systems and technologies, but this is not the case for those that outsource these to a third party that already meets the PCI standard.

The PCI Council

Jeremy King, European director of the PCI Security Standards Council, agrees with what experts in the industry are saying. “We reached out to thousands of customers for the move from version 1.0 to 2.0 and found that they were happy and didn't see that it needed massive changes,” he says. “We looked at improving the guidance and tidying things up, and added what was considered to be good practice. The changes didn't surprise anyone.”

King says the move has been well received by the industry and the council is now looking at version 3.0.

“At the beginning of 2012, we were reaching out, saying it was ‘time to talk again'. There was a little less feedback, but we feel that merchants are comfortable with the standard,” he says.

“I also work with the PCI merchant working group and they were all aware of the move from version 1.0 to version 2.0. Also, the attendance to this is going up, so we feel we have done some good work in helping merchants become more secure in receiving and handling cardholder data, and we are reaching down to smaller merchants and into e-commerce to make everyone aware of the benefits of using third parties. We see that as a big area.”

It pays to be ready

Businesses are aware of the need to be secure, but it is also important to be well informed about regulatory changes in order to understand what is required to remain secure.

The move from the original PCI DSS to version 2.0 should not have taken any merchant by surprise. Keeping compliant is a key factor of security, and with the council well on the way to introducing version 3.0, it will be a comfy ride for those who are ready.

This story first appeared on SC UK.