Why Are You More Afraid Of A QSA Than A Cyberthief?
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
Do cybercriminals concern you? Are you afraid that you might lose cardholder data? Are you worried that your internal users are downloading malware from the Web? If you are like most IT executives, you will answer each question with a “yes.” So if that’s the case, I have one more question for you: Why are you more afraid of your QSA than you are of a cyberthief?
Let me give some real-life examples of what I mean.
- A merchant shows its QSA its Web application firewall (WAF) and asks the QSA to mark it compliant with PCI Requirement 6.6. But the QSA probes deeper, and he finds that the WAF is in “learning” mode, which means it is letting everything through. Indeed, the WAF has been in learning mode since it was installed after the last assessment a year ago, meaning it is pretty useless from a security point of view and definitely not meeting the intent of the requirement.
- You developed a set of security policies as part of your last assessment. Your QSA comes around the next year and asks to see them, but no one can even find a copy to give her. Clearly the policies–designed to protect you and your assets–haven’t been implemented—or maybe even read.
- You install an extensive and expensive logging system, but you only monitor and evaluate event reports when the QSA is on site.
In these cases, the merchants are spending the money–often lots of it–but getting no benefit. Each constructs a Potemkin Village of compliance for the QSA’s (and CIO’s?) benefit. It is as though they are more afraid of the QSA than the real bad guys trying to compromise their systems and steal their data.
Are Merchants And QSAs Destined To Do Battle?
I genuinely hope the answer to that question is “no.”
The “A” in QSA stands for “assessor.” It does not stand for “auditor,” and it’s definitely not “adversary.” (Editor’s Note: And, typically, it’s not the other word that starts the same as “assessor” but may veer into a different word–although you can sometimes understand the confusion.) As a QSA, my role is not to catch merchants in a false step so I can report them to their acquirer or the PCI Council. The QSA and the client are not competitors: We are partners. At least, we should be partners for compliance to work. I think of the QSA’s role as that of a guide through the compliance process. Maybe we ought to change the designation to QSG?
The relationship can work. I recently conducted a PCI gap analysis during which I asked one user how long he retained the cardholder data on his system. In front of the IT director and me, he replied: “We keep it forever,” in complete violation of the company’s data retention policy. He agreed to change the procedure to come into compliance, and we moved on. That was it. No public flogging, no blame and no reproach. I actually wanted to give him a gold star for being honest. We can deal with any problem so long as we know about it.
Pages: 1 2
-Dan Stiel
December 16th, 2009 at 4:59 pm
I work for Web Application Firewall (WAF) vendor Breach Security and I couldn’t agree with you more about the unfortunate *gotcha* related to merchants attempting to address Requirement 6.6 by deploying a WAF however they never move into an actual blocking configuration. The intent of 6.6 is Remediation and if you aren’t blocking with your WAF then you missed the point. Another interesting topic related to PCI and WAFs is how should a merchant configure their WAF to handle ASV traffic? Should they whitelist the ASV domain entirely? Should they do their normal blocking? Seems as though each QSA has a different view on this topic :) There are valid reasons for each camp.
December 18th, 2009 at 1:46 pm
I believe the issue is one of expense, the known absolute expense of addressing an assessor’s finding versus the unknown and possibly no expense if a breach does not occur.
What is the probability of being breached, therefore the cost versus the cost of implementing greater security that may or may not be breachable.
The fact that one is judged to be not in compliance by the mere fact that it is breached even after adhering to all the PCI requirements is another oxymoron.
PCI in my opinin is a fear tactic by the card associations to drive the small and medium size players from the acquiring business in an effort to reduce the number of members they must manage therefore dramatically reducing the association’s overhead.
December 21st, 2009 at 7:35 pm
Thanks for the comment, Biff. I do want to take issue a little with two points you make.
You imply that the cost of a breach is less than the cost of compliance. I disagree. While I agree that the probability of a breach may be low, it is growing, and with the high financial, legal, infrastructure, business interruption, and brand damage costs associated with a breach, the cost of compliance is lower. I really believe (and I’ll admit to some bias) that the cost of compliance is less than the cost of noncompliance, even if we adjust the cost of noncompliance by the probability of a breach, i.e., Pr (breach) * breach cost > compliance cost.
You mention that “one is judged to be not in compliance by the mere fact that it [the merchant] is breached even after adhering to all the PCI requirements.” I don’t think I can agree with you on that one, either. The Council and the brands have said that no merchant that suffered a data breach was ever found to be PCI compliant at the time of the breach. I am not a big fan of that statement, at least partly because it seems to taunt every bad guy out there. Nevertheless, their forensics bear them out. The statement about not being compliant is based on the forensic investigation identifying the source of the breach, not the sole fact that a breach occurred.
Besides, PCI is a data protection standard, not a security standard. I could argue that PCI assumes your systems will be breached, and that is why you need to protect the cardholder data you are storing.