Here Comes PCI DSS 3.0 – But is it Enough?

New PCI Data Security Standards guidelines are about to hit the streets for financial institutions

We don’t know yet the full extent of what will be covered by PCI DSS 3.0, but the council has provided some highlights on how the guidance will be enforced on an ongoing basis.

I’d like to see the full 3.0 guidelines remove some of the last technical ambiguities — we saw similar updates in PCI DSS 2.0 when the Council tightened the technical requirements around the use of cryptographic-hashing methods to de-identify data. Many implementations were found to be poorly implemented, resulting in a real risk of data compromise. PCI DSS 3.0 may tighten similar ambiguities even further as well — indications are, for example, that endpoint authentication methods may be under the PCI microscope.

PCI DSS 2.0 had a number of controls around passwords and credentials management for authenticated access to sensitive data, including defining minimum strengths and the requirement to change end-user account passwords frequently. One thing that was still a problem, as witnessed in some breaches, was the scope and management of system-level passwords, which looks like it will be in consideration for change in 3.0. For example, database- or server-level protection, which protects only data at rest, may use a system-level account to unlock the key used to decrypt or detokenize data. So beyond the big problem that database- or server-level protection does very little to protect data other than when the system is powered off and at rest, a stolen credential of that type may give full access to any data in that database or server and thus represents a major risk and an attractive target for compromise.

Protection of data in memory environments that could be compromised is also on the agenda. This hasn’t been well-defined up to this point, and 3.0 is a great opportunity to do that. In particular, when sensitive authentication data is held prior to card-authorization processes, it’s still at risk of compromise unless it’s encrypted in such a way that an attacker cannot get the live data or the key to decrypt it. There have been breaches where POS systems have been attacked by malware leading to cardholder-data compromise because of this — the Dexter malware is an example.

PCI DSS has been a good standard overall — any guidance or standard that creates a path to apply consistent rules to protect sensitive data is really good thing for reducing risk, reducing the danger of breaches and reducing consumer pain. 

Now the guidelines need to follow where the market is going — we’re heading toward more adoption of cloud-type ecosystems especially in the area of mobile banking and e-commerce, and the new frontier of data analytics — Big Data. The PCI council has addressed some issues related to mobile devices and some aspects of cloud, but the market is moving so fast that we certainly need guidance in this area to stay at market pace. Big Data is where there are huge risks of a serious data breach: There are very weak security models in systems like Hadoop, and the platform can process more data than even large data warehouse systems. Hadoop presents both a hugely powerful tool for insight, but also a huge attack opportunity. The challenge is that many people rushing to implement Hadoop are hearing about PCI DSS for the first time, and thus potentially underestimating the risk and compliance challenge such an environment may present if it processes cardholder data.

The industry also needs to strengthen the rules around technologies like Tokenization — this was mentioned at last year’s PCI council meeting, and we look forward to seeing the results, especially as there’s a huge payoff to using Tokenization to reduce PCI scope. However, with so many different approaches available, independent security validation needs to be on the checklist of every merchant. If a solution is not based on a validated and proven approach, then it has to be assumed to be insecure and incapable of reducing PCI scope and risk. Focusing on ensuring that merchants use secure tokenization will not only protect them from attack but help to eliminate confusion in the marketplace around solutions that actually protect data for the long haul.