By Tim Cranny
Panoptic Security Inc.
In the second part of this multipart series, we drill down on Requirement 2 of the Payment Card Industry (PCI) Data Security Standard (DSS) and discuss what issues merchants and their partners face, where the greatest challenges will be in practice and what can be done about them. The first point to make is that ISOs, processors and acquirers really do need to deal with this level of detail, either by partnering with a specialist security company or by becoming security experts themselves.
The time when a general, high-level understanding of the issues was enough has passed. Merchants are confronting specific (and confusing) issues and are increasingly demanding equally specific assistance from their service providers.
The second of the 12 PCI DSS requirements is titled "Do not use vendor-supplied defaults for system passwords and other security parameters." It is the second half of the section "Build and Maintain a Secure Network."
(The first half of the section is "Install and maintain a firewall configuration to protect cardholder data." For an explanation of Requirement 1, see "Digging into PCI: Part 1 - Securing the network," by Tim Cranny, The Green Sheet, Aug. 10, 2009, issue 09:08:01.)
The first two requirements belong together and complement each other because Requirement 1 is about using firewalls to make sure there are no unofficial or unauthorized "doors" into the network; Requirement 2 is about making sure the "official" doors used for installation, setup, management and proper operation of devices cannot be abused by hackers.
An analogy may help to understand the connection between Requirements 1 and 2. If you think of your network as a bank vault, Requirement 1 is about making sure the walls of the vault are thick and strong so thieves cannot break through to create an "unofficial door" into the network.
Requirement 2 is about making sure the "official door" is always shut and locked when not in use in addition to having a good lock on it to prevent it from being opened by thieves.
As with Requirement 1, Requirement 2 is one of the most technically complicated and demanding sections of the PCI DSS. This complexity is, unfortunately, a fundamental part of the issue being addressed, so assistance to merchants has to be at the expert level.
The core of Requirement 2 is this: By necessity, computers have many different ways of being accessed, ranging from ways built in by the manufacturer (so that the device can be set up and made to work when installed) to access methods that are a necessary part of the computer's operation. For example, a Web server has to be able to accept and respond to requests for Web pages from users trying to view pages hosted on that server.
But every access method is a mixed blessing. Without multiple access points, the computer simply does not work. But each access method is also a potential entry point for hackers. Therefore, Requirement 2 is all about closing off and locking down doors where and when they are not needed and controlling their use as much as possible where and when they are needed.
Another way to think about this: While Requirement 1 is more concerned with network traffic between computers and deciding which types of traffic should be allowed or banned, Requirement 2 is more concerned with defensive measures on the actual computers themselves.
Unfortunately, while it's easy to describe the objectives of Requirement 2, the actual details are confusing and alien to many merchants, particularly smaller ones. As with Requirement 1, the first challenge merchants face is simply in understanding the question, quickly followed by the challenge of how to actually find the answer to the question as it relates to their specific payment environments. To take one of the simpler examples, merchants are required to make sure they have eliminated all "unnecessary accounts" on all computers and devices under the scope of the PCI DSS. How is a merchant to check which accounts exist on a given computer? How are they to know if an account is unnecessary?
This highlights one issue pertaining to Requirement 2 that is particularly painful. Unlike other requirements of the PCI DSS, this one is swamped in product-specific detail. The answers to the questions just brought to light (and the process for finding them) differ completely, depending on a computer's operating system - not to mention the fact that the issues also apply to routers, switches, wireless access points, and so on, all with their own zoo of products and manufacturers. Another potential complication with Requirement 2 is that a significant number of merchants outsource some or all of the functions covered under this requirement to third parties, often making it harder to get quick answers from a single source.
As with Requirement 1, by far the best approach to Requirement 2 is to avoid these problems, rather than defeat them. To understand the effectiveness of this strategy, you only need to recognize how the different Self-Assessment Questionnaires handle the issue. In SAQs A and B (for merchants who have no computer network as far as the PCI DSS is concerned), there are no questions pertaining to Requirement 2 at all.
SAQ C is for merchants with at least some limited exposure to the dangerous world of the Internet, so it does not completely avoid Requirement 2, but it nevertheless avoids some of the most difficult questions found in SAQ D.
As always, merchants should consider intermediate steps, such as avoiding (or taking out of scope) wireless networking. Doing so usually doesn't change the SAQ designation for merchants' businesses, but it does do a lot to make merchants safer for a given level of effort; it also makes Requirement 2 easier to comply with.
For merchants who cannot avoid Requirement 2, there is simply no substitute for getting assistance from someone who understands computer host security. Failing to do so will very likely lead to poor security and compliance failures.
Since there is no substitute for expert assistance, the end result is that merchants are going to lean on their ISOs or service providers. These portfolio owners have little choice in the matter. They need to either become security experts to provide the high level of assistance required, or they need to partner with someone who is already a security expert. The solution needs to be put together with great care, though. The industry is already seeing several first-generation solutions suffering from scalability and quality issues, creating a backlash against the PCI DSS and the ISOs that are offering the services.
The right solution, however, can be a highly visible value-added service, simultaneously protecting merchants, their customers and ISO portfolios.
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 tim.cranny@panopticsecurity.com or 801-599 3454.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
