The Green Sheet Online Edition
November 09, 2009 • Issue 09:11:01
Digging into PCI - Part 4:
Encrypt transmission of cardholder data across open, public networks
In this fourth part of a multipart series, we drill down on the fourth of the 12 sections of the Payment Card Industry (PCI) Data Security Standard (DSS). We will talk about what the issues are, where the greatest challenges will be in practice and what can be done about them.
This is, in many respects, one of the simplest sections of the PCI DSS, and one that often produces the fewest headaches and the least confusion.
That is not to say that compliance with this section is less important (and there have been significant security breaches caused by failure to meet the demands of Requirement 4), just that the barriers to success are lower.
What Requirement 4 is all about
Requirement 4 focuses on communications and the dangers that come with them. With modern card processing, most merchants have to communicate with a processor or gateway in order to get transactions approved and processed, and more and more this requires that cardholder data be sent over public networks.
(As a side note, data should be considered as passing over open or public networks, and Requirement 4 comes into play if at any point in transit the data passes over networks or through devices that are not under the direct control of the people doing the communicating.
This includes traffic that touches an Internet service provider or telecommunications company, the Internet, the Web or any form of wireless communications).
Communicating over public networks raises a raft of significant security issues, the most serious of which is simple eavesdropping, which in this context means thieves or hackers "listening in" on card processing traffic and harvesting cardholder data.
In most cases, this eavesdropping is silent and invisible, and merchants will have no idea it is happening. To counter this threat, it is critical that merchants do the right thing in advance, rather than try to react to some issue or event.
Requirement 4 lays out a few relatively simple steps for merchants to protect cardholder data as it's being communicated. The core of the requirements is encryption: using proper encryption to protect the data and making sure that the coverage is complete (i.e. that all the sensitive data is protected).
The challenges of Requirement 4
Fortunately, Requirement 4 is one of the less complex subsets of the PCI DSS. The technology requirements are relatively simple and nicely clean - in other words, self-contained in a way so that doing the right thing does not set off an avalanche of changes or problems to the rest of the network or the rest of a merchant's business.
What merchants need to do
For the earlier requirements discussed in this series, a strong emphasis was placed on avoiding challenges rather than defeating them. This strategy still has some relevance for Requirement 4, but in general it doesn't work very well here, and merchants need to focus on confronting the issue.
This is simply because most merchants can't avoid communications over public networks and so can't avoid the core of the requirement.
To handle Requirement 4, merchants should mentally separate all communications involving cardholder data into two categories:
- Network communications that are critical to real-time transaction processing
- All other communications involving cardholder data
The first category of communications should be the overwhelming majority of network communications involving cardholder data. And in most cases it can be handled easily by selecting and implementing a modern, certified payment application or POS device.
Such applications and devices were designed with Requirement 4 very much in mind, and compliance with the requirement is easy to achieve when merchants get such transaction-handling systems.
The second category of communications (for example, sharing cardholder data via e-mail for record-keeping or passing it on via instant message) typically won't be protected by the payment application or POS. These must be protected by encryption.
Merchants should endeavor to avoid or minimize these communications, or find another technology or solution to protect them. But while solutions exist that can help, they tend to be messier and more prone to problems, so the simplest and best approach is always to avoid, rather than protect, this sort of communication.
One important note about how technology is changing and how merchants must react to the changes: wireless communications between computers fall under Requirement 4, and can be protected by an encryption technology called Wired Equivalent Privacy (WEP). However, WEP is now known to be a terrible solution that is easily broken by hackers, and the PCI DSS now contains wording that merchants must not rely on WEP for encryption.
There are better replacements available (Wi-Fi Protected Access, 802.11i, or end-to-end encryption solutions like IPSec or Secure Sockets Layer/Transport Layer Security), and communications must either be avoided or protected by one of these solutions.
What to do for your merchants
Prior articles on earlier requirements made it clear that merchants would need significant highly technical and merchant-specific help, making those issues very tough for ISOs and others to address properly.
Requirement 4 is easier to handle, and most of the burden falls on others such as payment application vendors or POS providers. ISOs and other service providers should not ignore Requirement 4, but will almost certainly find that other parts of PCI demand far more attention and effort.
Remember, though, that even though Requirement 4 can be handled relatively simply and cleanly, there is one particular mistake many ISOs and merchants make. That mistake is to think that encryption is a silver bullet that makes most security issues go away.
Too many encryption vendors encourage this sort of thinking, but it is absolutely wrong and a merchant can easily pass Requirements 3 and 4 and still be horribly vulnerable to hackers.
At the end of the day, protecting a company against hackers is like making a boat sea-worthy: You can't fix a big hole in one part of the boat by being extra water-proofed elsewhere on the craft. Encryption is a critical part of the overall solution - but only a part.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at firstname.lastname@example.org or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.