This is page 2 of:
Why Are You More Afraid Of A QSA Than A Cyberthief?
In another case, the client decided to scan user workstations for stored cardholder data. The finance director wanted her department’s computers to be scanned first. She wanted to communicate to the whole company that we were searching for rogue data. We were not looking to assign blame. She told me she hoped we would find some data that wasn’t supposed to be there so she could demonstrate that we were focused on going forward, not backward. She’s one of my PCI heroes.
We Are On The Same Side
At each PCI Community Meeting, there is a QSA-only session with the Council’s Technical Working Group, which represents the five card brands. These closed-door sessions can get pretty contentious, especially where DSS requirements are perceived to conflict with merchant and processor business realities. QSAs use these sessions to present the merchant’s perspective and argue for additional guidance or flexibility or changes to the Standard. It’s a shame merchants can’t attend to witness some of this stance.
Sometimes the QSA is in an untenable position. Take Requirement 11.2.b, which mandates four quarterly passing scans over the previous year. This requirement is sensible. But let’s say you, the merchant, missed a quarterly scan. Maybe there was staff turnover or you reorganized or somebody got hit by a beer truck. Whatever the reason, you missed a quarterly scan. And unless we can summon Dr. Who and his time-travel talents, you aren’t likely to be able to go back and fix it. The QSA is supposed to enforce the Requirement and, therefore, can’t sign-off on your being compliant. As a non-compliant merchant, you are in trouble with your boss and your acquirer. If you are a non-compliant processor, you go off Visa’s list of approved service providers and maybe out of business.
Trust me, QSAs do not enjoy these situations. QSAs have argued the case for some flexibility on this requirement, and recent guidance from the Council indicates there may be flexibility in some cases. If you end up benefitting from this or some similar situation, you might want to thank your QSA.
Please understand: Neither the Council nor the Standard is the common enemy. I am a fan of PCI as the best thing we have. It’s not perfect, but it has raised security awareness like nothing else before it. The Council is listening, and a lot of good people work there. I just want to share a dirty little secret with you: Sometimes your QSA actually is on your side.
Life Is Like Basketball
I feel that life is like the game of basketball: It’s all about whoever touches the ball last. If I buy a prepared meal and everybody likes it, I get the credit. If I open a bottle of wine and it’s corked, I get the criticism. In neither case did I really do anything. I was just the last one to touch the ball.
Many QSAs spend time describing the business needs and PCI challenges of retailers (and hotels and airlines and telecoms and universities) to the Council. QSAs go to the mat for their clients (I know I do) for a compensating control or a favorable interpretation of a requirement. Because they also get to deliver the bad news, though, QSAa are the bad guys.
At least for me, I refuse to be perceived as an adversary of either my clients or the Council. We are all in this together, and we can make it easier all around–and your environment a whole lot more secure–if we work together.
I’m interested to know what you think. Am I naïve? Am I too taken with the generosity of the holiday season? What am I missing? Are IT professionals–white hats and black hats–kindred spirits and QSAs the ones crashing the party? Leave a comment below or send me an E-mail at wconway@403labs.com.
-Marc
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.