The Problem with PCI
Uh oh, is he really going to go there?
No way... he can't go there!
YES! HE IS GOING THERE!
One thing that cracks me up about reading blogs on PCI is the massive amount of individuals who have no idea what they are talking about. Just like that vendor that you run into at RSA that says "I SOLVE ALL PCI PROBLEMS! I AM A SILVER BULLET," there are those out in the blogosphere that throw out claims without substance and pure drivel. Some even do it so well that the media will run with the claim. Like the so called "second processor breach" of last month. Actually, that makes me laugh more!
There have been people that argue that PCI is too strict and impossible to implement. Then you have those that argue that PCI is not strict enough, and encryption must be deployed everywhere. Then you have the folks that say that PCI is just plain wrong, and you should implement XYZ Standard or ABC Technology instead.
They are all wrong. PCI is neither too strict, nor too weak. It is not plain wrong, and it is probably better than XYZ Standard or ABC Technology when taken by itself.
The real problem with PCI is the lack of a feedback loop. Don't worry baby birds... I will feed you.
There are three public examples of companies validated as PCI Compliant by a QSA that have been subsequently breached. In two of the three cases, the timing suggests that the breach either occurred before or was happening while the assessors were on site!
The first thing we can do is blame the breached party. If you assume all PCI Assessments are equal and done according to the Council's standards (hint: they are not), then we assume that the only logical explanation is that the breached party changed something. QSAs should not have any blame if the company being assessed does something to change their compliance posture after an assessment. Assessments are essentially a rolling snapshot (for you camera buffs, think of it as a Vertical-travel Focal Plane Shutter operating at high speed... it's never fully open), and are only reliable past the initial review by a QSA if the controls are maintained.
But then you say, what about the QSA? We've been on record saying that we've never seen a PCI breach investigation that finds the entity compliant at the time of the breach. So if the entity was not compliant at the time of the breach, and the breach has either already happened, or happening while the QSA is on-site, why was it not found? Shouldn't the QSA be at fault?
Maybe. "But wait a tick Branden," you say, "if the QSA is at fault, why has the Council not taken action? Clearly QSAs are infallible since there has been no action by the Council!"
Here's where the feedback loop comes into play.
Investigations of breaches are handled by the card brands. Remember, there are three groups at the center of PCI. There is the PCI Council, charged with managing and interpreting the standard, training QSAs, and managing the QSA program; then we have the QSAs, charged with carrying out assessments; and finally the brands, charged with enforcement.
The brands deal with the investigation, work with law enforcement, and review the forensic report to determine how big the breach was, and how to assess fines to the breached entity. Notice I did not mention the Council in there. The Council never sees the forensic report! There is no feedback loop for the entity charged with training and administering the QSA program!
The Council can only rely on the sanitized ROC that is sent in by the QSA, which they may never receive as part of the normal Q/A process. It's then, and only then, where a potential action could come from the Council against the QSA. We've seen two QSAs put into remediation status so far this year, and neither of which were publicly associated with a company that was found to be compliant and then breached (to my knowledge).
In order for the Council to get a better picture of what happened after a breach, they must have access to the forensic examination, the original ROC, and the information used to generate that ROC. Short of sending someone to sit on-site during every assessment, I'm not sure of any other way to determine who went rogue--the QSA or the company being assessed. This is the real problem with PCI.
So, now that I have thrown that out to the masses, what are your thoughts out there in the tubes? Do you agree? Do you have another solution to the problem, or see it differently through your rose colored glasses? If you are one of the lucky ones to go to RSA this year, maybe this is one of the challenges that could be worked on at the Innovation Sandbox! We won't be able to solve the security breach problem, but maybe we can do something about the breach that isn't supposed to happen.
Comments
I agree that a feedback loop is the essential missing ingredient.
There’s one thing I see in articles and blogs regularly that I don't agree with. Most in the know (Including myself) are unwilling to come out and publicly state that there are a lot of validations (PCI DSS & PA-DSS) that are complete junk. The unwillingness to do so only helps criminals and hurts everyone else. Sure, PCI DSS is a point in time snapshot, but the clues dished out from validated businesses that got compromised make it seem as though there were several glaringly obvious oversights that lead to each breach.
Compromised companies are then in a position where they can easily spin the event into something that makes it sound like they performed an acceptable level of due-diligence. “We were compliant!” The PCI image unfairly suffers and additional spin in the form of red herrings results. Then there’s the plethora of Silver Bullet security vendors that will take advantage of the spotlighted scapegoat “problems.”
A perfect example is Hannaford and Heartland. The resulting current focus of their PR spin has been on end to end encryption. The thought of true end to end encryption is a wonderful thing, but it’s not going to happen any time soon. True end to end encryption would be from every device that card data is entered at all the way to the card-issuing banks. Unless I’m mistaken, the best that can happen now is encryption from card swiper at the merchant to payment processor. It doesn’t cover keyed transactions. It’s relatively proprietary with limited support since there’s no set standard endorsed by the financial industry. Hell, it wouldn’t have protected Heartland because they still would have had to pass back card data in plain text at the same network interface(s) that were compromised! Even if network level encryption like IPSec is used on those network interfaces, the card data still passes through the server in plain text at some point.
These red herring spin tactics distract from import components of the PCI DSS that can and should be done now by companies that most likely aren’t (See above examples). It distracts from protecting against application vulnerabilities like SQL injection. Then there’s Host and Network IDS. Proper network segmentation (At minimum the components required by PCI DSS, preferably the PCI DSS recommended). At least unencrypted or WEP protected WiFi got thrown into the spotlight. That’s one positive that’s come out of the mass media blitz.
In the end, criminals are probably laughing all the way to the bank as they compromise a server via SQL injection, spread like cancer inside the unsegmented network, and plant undetected malware on critical servers. They’ll then sniff cardholder data via memory or SQL debugging and ship it offsite directly or indirectly (eg. DNS tunneling). They won’t be stopped from spreading throughout compromised networks and they’ll be undetected. After that happens, there will be another round of red herrings and resulting silver bullets pushed by vendors. Repeat.
In my opinion, the PA-DSS QA program has the best chance for weeding out bad eggs. Many of those auditors also perform PCI DSS assessments. In the case of the PA-DSS, there’s very little wiggle room for the auditor. They validate a payment application version and that software version is static. A 3rd party can look at the system and know very easily if the auditor performed an acceptable level of work.
In the next year, we'll see just how effective the QSA QA program is. It won't be 100%, but if it places fires under butts that are currently not under pressure, it'll help out tremendously.
Posted by: Anonymous | March 6, 2009 10:09 AM