One of my favorite cartoons of all time is from Calvin and Hobbes. Calvin rolls balls to make a snowman. Hobbes stands nearby. Calvin says “I’ve finally figured out the quickest path to success”. Hobbes asks “oh, what is that”. Calvin rolls one ball, then two and stacks the second on top of the first…then he stands back “lower your expectations! I think we’re done here”. Or something like that.

The cartoon comes to mind when I read a new PCI scoping article.

I personally prefer Spider from Cornell as I think it finds the fewest false positives of the three free utilities. However, none of these utilities can scan a database and find cardholder data stored in a database. And just so we are clear, all of these utilities are no absolute guarantee that an organization has truly found all cardholder data they may have stored on systems. But, it is better than have done nothing.

Hi, I’m a QSA and I disagree. Heard that before?

Anyone who tries to use Spider on large data systems knows that it takes forever, often crashes and produces clumsy and unverified (no Luhn algorithm check) output. It definitely is not suited for enterprise work and generates a lot of false positives. But other tools exist, as mentioned in the article, so the limitations of Spider are not my biggest concern. Regulated entities are free to choose whatever tool they prefer that can get the job done. They can even go roll their own and play with regex like this add in to Nessus or this validation sequence:

(5[1-5]\ d{ 14} )|(4\ d{ 12} (\ d{ 3} )?)|(3[47]\ d{ 13} )|(6011\ d{ 14} )|((30[0-5]|36\ d|38\ d)\ d{ 11} )

The biggest concern is that the article implies that a sufficient measure of effort is to have done more than nothing. That is very dangerous advice. Imagine if the requirement said “do more than nothing”. How easy would that be to achieve compliance?

A higher standard is obviously required by the Security Standards Council (SSC). Regardless of whether a tool is in use or not a regulated entity has to perform an exhaustive search. This means review of architecture, business processes, policies as well as systems, applications, logs and databases. A tool might find a system clean today, for example, but it won’t tell you that tomorrow is the end of month batch process that dumps track data on the system you just scanned. Scoping is about more than just what is present now, it also is about process and procedure.

Here’s another interesting part of the article:

At this year’s PCI Community Meeting, the question of MPLS networks being private was brought up and discussed. What the PCI SSC and the card brands told QSAs is that it is up to the QSAs to confirm that the networks are in fact private. That means that QSAs are going to have to examine the configuration of the endpoint routers to ensure that the MPLS network is in fact private.

I can tell you that this will put QSAs in a battle with a number of carriers who treat their MPLS networks and their configuration as intellectual property. I can tell you from personal experience that these battles to get carriers to reveal their configurations can become very contentious and downright ugly.

Ah, yes, I have faced MPLS providers since 1998, the days of assessing the security of Electronic Data Interchange (EDI). I’m obviously dating myself but I still have a CD with the details of flaws found. Providers were a real pain to work with back in those days. There was no prescriptive regulation like PCI DSS so it was literally you versus them, no standards council or regulatory authority to back you up. You want to talk about ugly? I remember when we audited up hill both ways, in the snow, without tools….

The MPLS debate was more than ten years old already when I sat through QSA certification exams in 2006 but by that time it was different. If I remember correctly the counter-argument from telecom giants was that they did not want to disagree with the regulators. They just wanted to say that if someone started saying MPLS had to be assessed everywhere then the whole Internet would come crashing down on everyone’s head from the weight of the cost of auditors sticking their smelly noses into every endpoint and link. Thus we were left with the watered-down approach — MPLS could be trusted but probably should be verified. Not what we were hoping for but compliance can obviously be a very political process and even a small step in the right direction is better than nothing. Heh.

But seriously, MPLS arguments today seem downright civil because providers have to answer to a very real threat that is in the news practically every day and breach laws force disclosure; we can draw from stuff like CVE-2011-3274 and TA05-026A:

The IOS implementation of Multi Protocol Label Switching (MPLS) contains a vulnerability that allows malformed MPLS packets to cause an affected device to reload

The fact is no technology is perfect, not even the biggest and most common virtual private networks. All are marred by simple and common errors like bugs, misconfiguration, weak endpoints and potential taps. More to the (end)point, technology falls into scope when it is relevant to the security of the cardholder data. The official line is to put something in scope that processes, stores or transmits but I find it even more helpful to walk regulated entities through a simple and honest attack tree and a risk assessment. Anything an attacker can breach in order to gain unauthorized access to cardholder data environment will be in scope.

Updated to add tool references:

Free

• Spider
• ccsrch
• senf

Commercial

• Nessus $1200
• CardRecon $40-50/machine
• Identity Finder $40-50/machine
• Encase $$$$