John Pescatore

A member of the Gartner Blog Network

John Pescatore
VP Distinguished Analyst
11 years at Gartner
32 years IT industry

John Pescatore is a vice president and research fellow in Gartner Research. Mr. Pescatore has 32 years of experience in computer, network and information security. Prior to joining Gartner, Mr. Pescatore was senior consultant for Entrust Technologies and Trusted Information Systems… Read Full Bio

Coverage Areas:

Prioritizing PCI Requirements

by John Pescatore  |  March 12, 2009  |  2 Comments

The Payment Card Industry Security Standards Council recently published some guidelines for a sequential approach towards meeting the PCI Data Security Standard requirements. Essentially, they mapped the DSS requirements across six major milestones. This doesn’t mean they are opening the door towards making some requirements optional or even less important than others – but it is a nice, common sense approach to focusing first on reducing the exposure of customer information and then on reaching compliance with the PCI requirements.

The first milestone is the one I always emphasize with Gartner clients  - reduce the number of places you store or even process cardholder data. Minimizing this is the biggest bang for the buck move, both in reducing risk and in reducing the overall cost of proving compliance.  However, this often means changing business processes or modifying legacy applications. Both of those are often immovable objects but if you can summon an irresistible force, it is high payoff.

The second milestone is “Protect the perimeter, internal, and wireless networks.” I would have liked to see this be more focused on better definition of segmenting off PCI-relevant systems from the rest of the corporate network first. Then focus on application security (the third milestone) and then focus on external and wireless security. From a real risk point of view, in the e-commerce side of things, paths to internal systems and weak web application security are the highest risks, given the rampant botnet threats and web application exploitation.

The rest of the milestones are pretty straightforward. They also provide a simple spreadsheet for tracking. Since most larger merchants have gone through this process several times, all this is of very limited use for them. However, if you are just getting started on moving through the PCI process, take a look – but tweak those first few milestones a bit.

2 Comments »

Category: Uncategorized     Tags:

2 responses so far ↓

  • 1 Jeff   March 12, 2009 at 9:50 am

    John,

    I agree with your statement that “I would have liked to see this be more focused on better definition of segmenting off PCI-relevant systems from the rest of the corporate network first,” but the biggest challenge there is systems that are already in place and serving more than one function. We try and isolate as many PCI related systems as possible behind an internal firewall, but we’re limited to the number of servers we can move because of the POS system itself and how many other systems it talks to. We use the PIC firewalled zone in combo with other mitigating controls such as ACLs, access controls, etc., to help keep things tight.

  • 2 John Pescatore   March 13, 2009 at 9:23 am

    Yes, shared services is actually a risky practice when there is sensitive or restricted data in use. It can be done securely but in the past it was almost invariably less expensive to have physical separation. Now, either through encryption or virtualization, there are easier ways to do it securely but the QSAs haven’t been given strong guidance on this – impossible to predict what a QSA will say.

Leave a Comment