Why is restricting access to cardholder data the biggest challenge of PCI DSS compliance?

Opinion by Dan Raywood

At the start of this week we covered a report by Thales and the Ponemon Institute on findings around Payment Card Industry Data Security Standard (PCI DSS) compliance audits by qualified security assessors (QSA).

At the start of this week we covered a report by Thales and the Ponemon Institute on findings around Payment Card Industry Data Security Standard (PCI DSS) compliance audits by qualified security assessors (QSA).

What interested me the most about this was the discussion on PCI requirement seven – ‘restricting access to cardholder data on a business-driven-need-to know-basis is the most difficult and most important requirement to meet'. Perhaps I was missing the point with this, but surely if you are going to be regulated for PCI compliance, then the transmission, handling and storage of card details are the most crucial?

The report claimed that QSAs believe that requirement is the most important part in achieving PCI DSS compliance. So with this in mind, are merchants really struggling to protect the credit card details of the consumer – me and you?

I spoke to Amichai Shulman, CTO of Imperva, about whether requirement seven should be the most important part of PCI DSS compliance. He commented that he believed that requirement seven is about two things: having a proper access control mechanism to protect cardholder data; and setting this mechanism up properly to actually protect the data.

He said: “The difficulty comes mainly from the second part – being able to define and implement a policy that protects the sensitive data while allowing business to go uninterrupted. It is indeed a tough challenge as the person responsible for this task is usually part of the security team while traditionally the mechanism that is used is within the database (controlled by DBA) or within the application (controlled by application admin).

“In the case of the database it gets even more complex as the knowledge of which module needs access to which tables and columns is further distributed among application developers. In addition most access control mechanisms within databases or in applications are very restricted in their ability to express complex conditions, for example a person can access specific data from within an internal network but not through VPN, or people are not allowed access to specific data outside working hours.”

He commented that there are solutions emerging in this area to allow organisations to get better visibility into existing access privileges, analysis of these against enterprise policies and even automatic deduction of access control patterns.

Richard Walters, a former QSA and now CTO at Overtis, believed that requirement seven is about only giving access to card data to those employees who need it in order to do their jobs.

He said: “Most credit card data is stored as ‘structured data', such as in databases. It should not be stored all over the estate in spreadsheets and word docs (unstructured data). Because credit card information is structured data, the standard mandates that it is encrypted at rest and that credit card numbers are truncated or masked when presented in database driven applications.

“The issue with requirement seven of PCI DSS is that it is not easily solved with technical controls alone – it requires close collaboration with the business (understanding workflow in detail) and the app piece that it necessitates for masking/truncating is potentially high cost as apps have to be upgraded/rewritten/replaced.”

So by this rational, it does strike me that there is a considerable risk in requirement seven not being adhered to correctly, specifically as PCI DSS requires that credit card information is encrypted when it is at rest, and if it is used it should be truncated or masked. So it is up to the company handling the data to be efficient in their best practice, and requires total efficiency.

In agreement was Jan Fry, head of PCI at ProCheckUp Labs, who believed that he saw two main reasons why requirement seven is seen as the most important/difficult requirement to meet, mainly because the requirement is interpreted as reducing scope and there is resistance from other ‘more important' (i.e. money generating) areas of a business to the de-scoping.

However Fry said that ‘de-scoping an organisation's cardholder environment is absolutely essential and can provide the greatest area for savings on overall compliance costs'.

He said: “The intent of the standard is to securely transmit, handle and store credit card data and forms the basis for the requirements themselves.”

Commenting on the report, Fry believed that becuase QSAs were asked which particular requirement is the most important or difficult, one of the 12 had to be picked rather than saying the ‘whole standard'. “Personally I think it is a bit of a moot point to suggest that one particular area is the most important - it will vary from company to company,” said Fry.

As with most compliance frameworks, it seems that there is no black and white answer to the question of protection. While there is appropriate identity and access solutions, as well as protection for data, teams have been reduced along with budgets, so could the hardware solution be even more of a challenge as the September deadline approaches?

We looked at PCI problems in another story following a report by Tripwire, where a third of respondents said that they did not know if they will be PCI compliant by the September deadline. With negativity and a general sense of the unknown around PCI, it could be said that the next few months will be spent with an element of concern.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events