I am starting to hear a troubling rationale regarding PCI compliance. It typically is expressed as a reluctance to comply with the complete PCI standards because the organization does not store cardholder data. You hear people questioning why they need to have anti-virus, log analysis, file monitoring and other security measures in place if they are not storing cardholder data.
Well, get a clue, your organization is just one of many in the systems that handle cardholder data. Your organization is just one part of the overall cardholder data flow. Cardholder data flows from the merchant to one or more gateways or processors to an acquirer and back. Each one of these entities is dependent on the security posture of the other to ensure that cardholder data is protected. If you are shortcutting security at your point in the process, you are creating a gap in everyone’s security.
If your organization is one of the lucky ones to have gotten cardholder data off of all of your systems, you still process and/or transmit cardholder data. People sometimes forget that the PCI standards are about the processing, storage or transmission of cardholder data. Just because you no longer store cardholder data, you still need to be concerned about securing the processing and transmission of cardholder data.
Securing the processing of cardholder data is typically the easier of the two to control. All you have to do is control the access to the device and make sure that users cannot access the memory of the device. However, with today’s development environments, security surrounding the processing of cardholder data is not as simple as it seems. Most developers have no idea as to how their programs physically work when it comes to memory management. As a result, we are seeing more and more instances of cardholder data being stored in the memory of all sorts of devices. In the best cases, the cardholder data in memory is cleared once the transaction has been approved or declined. However, in a lot of cases, the device memory contains every transaction that has been processed since the last run of end-of-day or similar process. And powering off a device is no guarantee that memory is purged. As a result, just because you only process cardholder data does not mean you are safe.
Then there is the more obvious security related to the transmission of cardholder data. End-to-end encryption is in the news ever since Robert Carr of Heartland Payment Systems made it all the rage. However, security of the transmission of cardholder data is also easier said than done. One of the biggest obstacles can be the processors, gateways and acquirers themselves. A lot of these organizations do not even support the secure transmission of cardholder data. While this situation is getting better every day, it still surprises me how many of these organizations are still transmitting cardholder data in an insecure manner. However, even with end-to-end encryption, there are still ways to compromise cardholder data. Yes, it is more difficult, but it is not impossible.
All of this discussion of securing memory and communications is moot if the PCI standards are not completely followed. If anyone is able to compromise the data flow at any point in the line, the flow is compromised. And once compromised, the data is for the taking. Therefore it is imperative that everyone in the data flow keep their guard up and ensure that their security measures are sufficient to protect the data flow. That means following the PCI standards to ensure security.
The other part of this troubling situation is that when all cardholder data gets removed from the merchant systems, it will be the processors, gateways and acquirers that will become the targets. Attackers will do whatever it takes to get into them for the data they hold. If organizations that connect to these entities are not doing everything they need to secure their environments, they will be used as the way into the processors, gateways and acquirers.
That is why everyone needs to stay on top of their game even when cardholder data is no longer stored.