PCI DSS QSA vs ISA smack down

In his post “PCI’s Money Making Cash Cow“, Andrew Weidenhamer must have had a bad week of being challenged (or in his words, “bullied’) by an PCI DSS Internal Security Auditor (ISA). This is not acceptable, but QSA’s must accept that their advice is there to help the organization become compliant, not to provide a cash cow of their own nor to be unchallenged.

Not knowing the specifics of the background that led to this article, I have to assume that the ISA has pushed back on one or more of:

• Scope – this has traditionally been the QSA’s sole domain, and (uncharitably) they probably don’t want anyone else busting a move in their profitability zone.
• Interpretation of the meaning of various clauses. I wrote the OWASP Top 10 2007, which was incorporated in the PCI DSS. I find it highly amusing to hear some of the “meanings” attributed to what I wrote.
• Being forceful about adhering to the “intent” versus the “letter” of the PCI DSS. This is a problem where the standard has to be deliberately vague, but the Council should be open and honest about what they meant when they wrote it – do they mean a web app, or something else? The PCI DSS is highly focussed on web apps, not other apps. Trying to extend it is like extending a repair manual for a ship to a bus. They both have diesel engines, but you know it doesn’t work that way. Don’t force the issue if you don’t know.

Being in this space right now, I understand the issues here. There are several problems I hope the SSC will pick up and resolve in the next major overhaul of the standard.

• Make the meaning of “in scope” and “out of scope” a great deal more tightly defined. The biggest problem in my view is it’s far too easy to drag in unrelated systems in a cloud / virtualized / management environments. I’m all for a solid ring fence, but to think the only way to do it is by layer two firewalls is farcical at best and destructive of the Council’s reputation at worst. Firewalls have their place, but as part of a wider set of more than adequate other controls, such as strong authentication, authorization, auditing and escalation. Let’s put it this way, I do nearly all my penetration tests over SSL and through firewalls and in direct view of IDS’s, and I still manage to have a very, very good time. If firewalls are all you’ve got, we’ve got it very, very wrong.
• Leaving the QSA to determine the scope is inherently conflicted. They get a lot more money if they scope it conservatively (i.e as many of the requirements as possible, and as many systems as possible), and there’s a lot of risk if they scope it to be a minimal but to the letter of the standard. I strongly suggest SSC require tier one merchants hire two QSA’s, one to find the information out and set the scope, and one to assess the desired scope and systems. Or work just like the internal audit versus external audit functions in the financial world, where the ISA’s output is treated as trustworthy and evaluated from time to time. Is either method perfect? No, but it’s a lot less conflicted than the current situation.
• The glossary, the prioritized list, fact sheets, and PCI DSS for Dummes, what you heard on the community grapevine, or the guidelines ARE NOT the standard. They can be used to support an argument to do something in the spirit of the standard, but they are most certainly NOT the standard. QSA’s – please understand unless you demonstrate that your reason for a “not in place” actually is required by one of the in scope requirements, then it’s not required to be in place. Is it good idea? Almost certainly, but that’s a different standard.
• Many folks need and want an Attestation of Compliance … but at what cost? The process of working through not getting an AoC is almost completely off the reservation. Most folks don’t even think about this third way, but it’s actually fairly likely. If your activities are all about getting an AoC at all costs, PCI DSS has failed to achieve a good balance. There are places for a black and white compliance standard, and there are places for risk based assessments. If it’s going to cost you $25m to fix a $25 a year problem, that’s a terrible, terrible outcome. I hope the SSC addresses this in the future, as many folks going through PCI DSS compliance will need an AoC but can’t get one because their QSA has said no for the most minor of reasons.
• Make it easy for folks to ask questions directly to the council. Nearly all of the requirements are vague. One QSA might have been told one thing by the Council, and other has never come across it before, and you have two opinions, one right and one somewhat wrong. Too many times, an argument that goes on for weeks can be solved with a simple email to the Council. Channeling it through one side of the argument (the QSA) is inherently conflicted. Let’s be open and transparent in this process.

In my view, the best way to deal with a QSA is to be friendly, but make it known that you will challenge them in a collegiate way from time to time, and that there’s nothing personal about that challenge. The QSA may not understand the business or the technology, and they may have got it completely wrong.

On the other hand, you as an ISA or as a hiring company may not understand the intent or learnings of the Council, and need to get your house in order, which is far, far more likely.

PCI DSS does this in a very blunt, non risk assessed way. For the first time ever, someone with a bigger stick is holding you to account to do it the way you should have done it in the first place. There is simply NO EXCUSE for SQL injection or XSS in any app, let alone a payment app. However, so many of the requirements are vague and so open ended as to be nearly impossible to comply with unless you hoodwink the QSA. And that doesn’t serve the real purpose of this exercise.

QSA’s who fear going to every meeting with you are not going to offer good advice. They wont offer advice at all. It’s best to walk a very fine line between being friendly and learn all you can get from A to B in the best way possible that achieves credit card security, but don’t be so chummy that you find it hard to say “no” when you need to say “no”.

My rule of thumb is that if you’re having a difficult conversation with your acquirer when you should have been having a difficult conversation with your developers, your marketers, your business or the QSA, then you’ve done it wrong. PCI DSS is here to save your bacon, not be a speed bump. However, there is much to improve in the QSA engagement process, mainly in my view to advance true independence of QSAs.