By Tim Cranny
Panoptic Security Inc.
At the heart of the Payment Card Industry (PCI) Data Security Standard (DSS) are 12 requirements. All businesses that accept electronic payments must comply with them. In the first installment of a 12-part series that drills down on each requirement, I will discuss what issues merchants and their partners face, where the greatest challenges will be in practice and what can be done about them. ISOs, processors, acquirers and others need to deal with this level of detail either by partnering with a company that specializes in data security or by effectively becoming security experts themselves. Either way, the time has passed when a general, high-level understanding of the issues is enough.
Merchants are confronting specific (not to say complicated and confusing) issues, and are increasingly demanding equally specific assistance and service from their providers.
The first of the 12 requirements is titled "Install and maintain a firewall configuration to protect cardholder data," and is part of the section, "Build and Maintain a Secure Network." Unfortunately for many, this is one of the most technically complicated and demanding sections of the PCI DSS.
By the way, this isn't a failure of the Standard. Its complexity is a fundamental part of the issue being addressed, so there are really only two choices: to meet the complexity head-on or to get this whole section badly wrong.
There is absolutely no substitute for reading the PCI DSS, but the core of Requirement 1 is that cardholder data stored on computers is not safe if the computers themselves are not safe. Consequently, the first requirement mandates that merchants put a "wall" around their networks to keep hackers out.
This is done (in part) by using firewalls. To be effective, these firewalls must be positioned at all appropriate places throughout the network. Firewalls must be configured to block all the traffic that must be blocked (and allow all the traffic that must be allowed). Additionally, firewalls must be set up and managed in such a way that they continue to work in a proper and predictable manner.
A few minor extensions to the key message should be mentioned. For example, network-based firewalls do nothing to protect laptops taken out into the vulnerable world beyond a merchant's walls.
Thus, Requirement 1 also states that laptops need their own "built-in," personal firewalls to protect the data stored within them. But these extensions do not significantly distort the relatively "clean" message of Requirement 1.
"Clean", however, is often very different from "simple," as we'll see in the next section.
Unfortunately, while the core objectives of Requirement 1 are relatively clear, for many smaller merchants this is the first time they have ever been asked to tackle any sort of security requirement.
In fact, for many of them, this is the first time they have ever been asked anything about their network other than: Does it work? and Can you connect to your processor?
Many merchants have never given a second thought to firewalls, network segmentation, and so on, and the first challenge they face is simply that of understanding the requirement itself.
They will need assistance with the technical meaning of many words found in this section, such as "firewall," "router," "configuration," "DMZ," "internal network," "network diagram," "protocols," "ports," "hypertext," "HTTP," "SSL," "VPN," "stateful inspection," "TCP" and "IP."
It would be easy to double the size of that list, and many of these words defy quick and easy explanation. For example, I encourage any doubters to find a nontechnical family member and explain "internal IP addresses" to them over the phone. It is best to make sure it's someone with whom you have a strong relationship.
It is no use saying "these are simple terms" because that is only true for people who know networking. Direct experience with thousands of merchants has taught us that for many, many merchants, this is an entirely new world.
With complicated demands like those of Requirement 1, by far the best approach is to avoid the problems, rather than defeat them. To see how effective that tactic can be, you only need to look at how the different Self-Assessment Questionnaires (SAQs) handle Requirement 1.
The SAQ is the document that merchants are expected to complete each year. It is designed to help merchants identify where they fail to meet the requirements of the PCI DSS. There are now four different versions of the SAQ, with SAQ A being used for merchants with the simplest, least risky environments, through SAQ D for merchants with complicated networks or with the most data at risk.
Of course, merchants can avoid the challenges of Requirement 1 altogether. One only has to understand that SAQs A and B (for merchants who have no computer network, at least as far as PCI is concerned) have no questions in the Requirement 1 section.
SAQ C is for merchants with at least some limited exposure to the potentially dangerous world of the Internet. Therefore, they cannot completely avoid Requirement 1. But they only have to answer two relatively simple questions.
SAQ D is the most complicated and demanding of the questionnaires. Merchants who fall into this category have 18 questions to answer in Requirement 1.
Merchants should seriously consider a few useful, intermediate steps. For example, using wireless networking introduces a whole range of security concerns, and makes the entire compliance story more difficult.
Avoiding the use of wireless usually doesn't change the SAQ selection that applies, but it does go far in making merchants safer, and it makes PCI compliance simpler.
I am not saying that all merchants need to get rid of their computers, or even that they must stop storing cardholder data. What is needed, though, is for all merchants to know the huge advantages of stopping the practice of data storage and be able make informed decisions about the costs and benefits of doing so. For those merchants who have to face Requirement 1 head-on, there is simply no substitute for getting assistance from someone who understands computer network security. This is a complicated area that requires deep and specialized technical knowledge, and failing to get the right assistance will very likely lead to poor security and compliance failures.
This can get merchants "in trouble" with the PCI Security Standards Council (SSC). But the real problem is that it makes merchants more at risk of being breached and of their customers being hurt.
Unfortunately, we can't offer a single easy answer or one magic product that would make the firewall problem go away. It is also true that almost all merchants simply cannot do it themselves, since they don't have the expertise, time or resources. This means merchants are going to beg for (or demand) help from their ISOs, acquirers or processors.
The bottom line is that ISOs and others will, in practice, have no choice in the matter: They either need to become security experts themselves or partner with companies that specialize in data security. It may seem unfair, but it is the reality of the situation.
It is also critical to know that the solutions and partners you seek match the security issues of merchants in your portfolios. If you have a small number of merchants who are all high-transactional volume merchants (level 1), then the best solution might be to partner with a Qualified Security Assessor (QSA).
If you have a relatively large number of smaller merchants, QSAs are not the right solution, since small merchants will never be able to afford to pay for them. Instead, these merchants need a solution that is much lower-cost and more specific to their needs.
In Part 2 of this series, I will look at the next set of PCI requirements, what problems they cause for merchants and how ISOs can best help merchants achieve compliance with them.
The full PCI DSS is available at the PCI SSC's Web site at: www.pcisecuritystandards.org/security_standards/pci_dss.shtml
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 email@example.com or 801-599 3454.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next