The Payment Card Industry (PCI) Security Standards Council (SSC), an open, global forum for the development of payment-card security standards, recently gave us a preview of its new PCI Data Security Standard (DSS) guidelines that will be published by the Council in November 2013. Referred to as PCI DSS 3.0, the revised guidelines are designed to help companies make PCI DSS part of their business-as-usual activities by introducing more flexibility and an increased focus on education, awareness and security as a shared responsibility.
PCI standards apply to every organization that touches credit card information — for example, banks that handle and process cards — and there are very few that don’t — are in scope of the PCI SSC. Even the humble bank branch may be treated as a merchant environment under PCI DSS, and so PCI DSS can have implications beyond the back office or transaction-processing systems in the data center. Previously, bank systems have been considered too complex for all the controls of PCI DSS to apply, but this is definitely not the case today — banks, along with other financial institutions, need to pay close attention. PCI DSS 3.0 starts to shift toward a more continuous approach to risk mitigation and compliance. Similarly, continuous risk-mitigation technologies for sophisticated organizations have evolved dramatically since PCI DSS’s first incarnation and can be easily applied to even the most complex data processes with dramatic cost-saving results.
So what do the new rules mean for banks?
A good place to start is to revisit how PCI DSS came about in the first place. PCI DSS 1.0 came out more than seven years ago as a new standard for addressing the emerging risks around payment data, merchants taking card payments, and the industries involved — including issuing banks and payment processors on the back end. But it really goes back even further than that. Visa, American Express, JCB, Discover and MasterCard earlier implemented Cardholder Information Security Programs (CISPs), for example, but compliance to those regulations varied. PCI DSS brought these loosely enforced mandates together and created a new level of harmony in the industry. To date, PCI DSS has made its biggest impact by requiring that organizations eliminate cardholder data where it’s not needed and limit exposure of cardholder data by protecting sensitive information. But as evidenced by serious and frequent breaches resulting in the exposure of millions of consumers’ credit card and other information, most of us agree that it hasn’t been enough.
So we now have PCI DSS 3.0, driven by the need for more continuous compliance postures in light of those breaches and the increasing sophistication of attacks. Not surprisingly, when assessors and investigators have reviewed many of the incidents, they find the merchants were not compliant at the time of the breach. PCI DSS 3.0 looks to tighten the areas where the most risk has been observed during the past few years, which is good news for data protection but also increases the PCI compliance burden for merchants with new, tighter assessment rules on the horizon.
However, it doesn’t matter if it’s PCI DSS 2.0 or 3.0 — the fact remains that while PCI DSS is an excellent standard to address a broad range of risks, any compliance assessment, no matter how frequent, measures risk only at a single point in time and provides no guarantee of protection.
Threats to data are continuous, as is the risk of a compromise. Vulnerabilities in the payment ecosystem cannot be eliminated if cardholder-data protection is not truly end-to-end. Any place or point in a payment-data process where live data is available and exploitable represents a continuous business risk. And it’s in those exploitable gaps that we see constant reports of insider attacks, malware-driven data compromise, and sophisticated directed attacks yielding cardholder data.
What’s Still Needed
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.
Future Impact on Banking and Finance
The true impact of the new guidelines on the banking and finance industries will be felt in 2015 when they officially go into effect and are enforced. I definitely advise merchants to carefully review the rules that come in version 3.0 as soon as is feasible, but in reality, some are still updating to current PCI DSS 2.0 rules, so there will be a lag. For those banks who don’t have a full cardholder-data scope reduction or protection strategy, 3.0 will no doubt help provide a framework and foundation to build one.
Reducing Risk Today — New, Proven Methods
There are already proven, validated technologies and solutions available today that completely remove cardholder data from high-risk, low-trust systems common in retail payment processing while preserving critical business functions. That includes everything from mainframe to mobile, from Big Data systems like Hadoop to cloud applications, and in e-commerce platforms and point-of-sale equipment. The leading merchants and payment processors are already ahead of the curve with a data centric approach to protection to deal with the risk more aggressively — with massive PCI-compliance cost savings as a result in some cases well over 90 percent compared with compensating controls or traditional storage and file encryption. If there’s no data to steal, then both the risk and the compliance burden are dramatically reduced.
The good news is that with the U.S. Government’s NIST recognition of new powerful data centric security methods such as AES FFX Format-Preserving Encryption (NIST 800-38G) to protect data easily and quickly, merchants, acquirers, card issuers and processors can choose proven approaches with the highest possible security stamp of approval. When blended with independently validated and proven techniques such as Secure Stateless Tokenization (SST) Technology, organizations have new, powerful and easy means to deploy weapons in reducing attack risks and compliance burdens. That’s critical in removing the doubts and risks that still prevail from so many proprietary and unproven solutions out there. PCI QSAs and risk assessors demand the highest levels of risk reduction through proofs of security, standards acceptance and independent validation of data-protection methods. And so they should — with anything else, it’s just a gamble on having a breach, and by then it’s all too late.
About the Author:
Mark Bower is a vice president at Voltage Security and has been involved in and contributed to many PCI SSC special interest groups, including the PCI SSC P2PE and Tokenization Special Interest Groups (SIGS). Voltage Security is a leading contributor to cryptography standards for data security for government, payments and the financial sector, including ANSI, the IEEE and NIST. For more information, see www.voltage.com
