Wait, Why Are We Still Talking about PCI?

Guest blogger: Derek Brink, Aberdeen Group

It’s hard to believe, but security professionals and solution providers have been talking about the need to protect cardholder data (i.e., payment card account numbers, cardholder names, expiration dates, and security-related information used to authenticate cardholders or authorize transactions)—wherever that data is stored, processed, and transmitted—since the 1990s.

Starting with the independently developed data protection initiatives of the major card brands (i.e., Visa, Mastercard, American Express, Discover, JCB), the industry standards and best practices for this nearly universal issue have continued to mature and evolve. From the version 1.0 release of the Payment Card Industry Data Security Standard (PCI DSS) in December 2004, to the  version 3.2.1 release in May 2018, one would think that everyone would have this problem fully solved by now, right?

Wrong.

Neither time (more than 15 years, and counting), nor carrots (positive impact on reputation and brand, reduced risk of a data breach), nor sticks (negative impact on reputation and brand, significant cost of a data breach, fines and penalties for non-compliance) have succeeded in getting all affected organizations to meet these minimum standards for protecting cardholder data. For example, in a recent Aberdeen study, out of 222 organizations who create, collect, integrate, process, store, or transmit cardholder data such that it is subject to PCI compliance requirements—just 135 (61 percent) said that they have currently achieved, report, and certify compliance.

To be fair, 6 out of 7 (86 percent) respondents have to deal with the complexity of multiple types of data and/or data-related processes subject to security and privacy compliance requirements—just one in 7 (14 percent) have the relative simplicity of having to deal with only one. If best-in-class data protection and compliance were easier and less expensive to implement, there would be far more companies doing it.

None of the above would matter if data breaches rarely occurred. Unfortunately, Aberdeen’s analysis of more than 3,200 public data breach disclosures from 2017-2018 shows that about 75 percent of all disclosed data breaches are the result of malicious intent (i.e., primarily from cybercriminals and other external threat actors), while the remaining 25 percent are self-inflicted (e.g., accidental loss of data and devices). If cybercrime didn’t pay, there would be far fewer cybercriminals.

Just where are these data breaches occurring? An analysis of empirical data for security incidents (i.e., any attempt to compromise the confidentiality, integrity, or availability of a data asset) and data breaches (i.e., the confirmed disclosure of a data asset to an unauthorized party) by the type of asset compromised shows that servers (e.g., back-end applications and databases) are much more frequently under attack. But endpoints (e.g., user devices, point of sale devices, other connected devices) have a much higher likelihood of being compromised. As shown in the following chart, for each of the past two years servers have been in the upper-right quadrant based on both number of investigated attempts and number of confirmed successes. But the effective success rate (breaches/incident) is much higher for endpoints (between 43-54 percent) than for servers (between 26-36 percent).

From a high-level perspective, this makes perfect sense. Back-end systems typically represent the large, concentrated repositories of structured data (i.e., databases)—the “crown jewels” of enterprise data assets, and a big prize for financially motivated attackers. In contrast, endpoints typically represent multi-sized, widely distributed instances of unstructured data (i.e., files)—which are often an integral, critical component of core business processes and workflows, with a much bigger and more complex attack surface.

What can be done to protect cardholder data more effectively in these unstructured, endpoint-oriented use cases?

Ancient and venerable best practices—such as “remove cardholder data from your environment”—are always a good place to start. This reduces the risk of a data breach, reduces the scope of compliance requirements, and as an extra bonus reduces the burden for ongoing auditing and reporting.

However, there’s an even more fundamental first step: Before cardholder data can be removed or protected, we first have to know where it is. In other words, discovery of cardholder data in your environment is also a critical technical capability.

One practical approach to addressing this problem—as exemplified by PKWARE’s solution for automating data redaction—is to move that data to a secure location, redact it, and automatically repeat this process over time, as updates to files involving cardholder data are made in the course of normal business activities.

And how awesome would it then be, to not still be talking about PCI?