PCI, QSAs, and the Audit-Industrial Complex

| 1 Comment

This post is derived from an interesting twitter exchange that I had with Branden Williams last week, and that resulted in his writing-up a couple related blog posts. You can read those posts here:
* "Myth Busting With Ben Tomhave"
* "Corporate Responsibility with Ben Tomhave"

The first issue was a simple question I asked about whether or not a QSA was still required if a business had an ISA. To my great surprise, Branden responded that not only was a QSA not required, but it never had been! His response even surprised a couple other QSAs. I'll go into this more below, but suffice to say that when you dig into each card brand's requirements, it turns out that self-certification is allowed with the signature of a company officer.

The second thread that came out of the original discussion revolved around the topics of businesses needing to become competent on PCI requirements (or, what's reasonable to expect), as well as a side-bar about whose risk is actually being managed. We'll discuss these topics as well.

No QSA Required

If you think a QSA is required to sign your RoC, then think again! It turns out that it's not a requirement, and never has been. However, the card brands, PCI Council, and what I'll call the "audit-industrial complex" have a lot to gain financially from your believing otherwise.

Branden lays this all out in his post, but just to reiterate for convenience:
* The PCI Council sets the requirements, but are not the enforcers.
* Each card brand sets its own enforcement rules.
* In general, you are not (and apparently have not) been required to use a QSA. Instead, you can use an internal auditor and then have a company officer sign the RoC. That said, the requirement may be shifting (e.g., see MasterCard's statement here) that you would at least need an ISA (Internal Security Assessor) rather than just using a non-certified auditor.

With me so far? So, if it's really true that a QSA has never been required, then why is it that companies almost universally believe that one is necessary? It may be because of a false belief that using a QSA transfers liability (or, risk) to a third party. Or, it may be because both the card brands and the "audit-industrial complex" wants you to believe that a QSA is needed. After all, both groups benefit financially from misunderstanding this requirement (or lack thereof).

Perhaps this sounds a bit conspiratorial, but it wouldn't be the first time that the audit industry behaved in this way. In fact, discussions seem to be popping up again about the proper role of auditors (internal and external), auditor independence, and even whether multi-year contracts with a single audit firm are sensible. The simple fact is that these companies stand to profit handsomely from the audit-industrial complex that's been built-up over the years, and I find it hard to believe that it's an accident that businesses have been led to believe that a QSA is a requirement.

A Flawed Approach

PCI and the card brands have been much maligned over the last several years. PCI DSS represents a set of requirements that are oftentimes unfathomable to the average person. To make matters worse, contracts are excessively complex, and leave businesses in a no-win scenario; either they accept the terms, or they lose customers due to a lack of support for payment cards. Especially for small business, which have particularly limited resources, it's simply unreasonable to expect them to somehow develop enough competency around security and compliance to understand all the details of contracts and standards like PCI DSS. Unfortunately, Branden seems to disagree, as he states in his "Corporate Responsibility" piece:

"Companies must make security and compliance a core part of their competency if they choose to operate in a manner that puts them in the cross-hairs of regulation."

I don't agree with this as a universal statement. If you're talking about enterprises with IT resources, then this is true. However, if you're talking about an independent restaurant with a point-of-sale system, then this is absolutely wrong (e.g., read about a lawsuit being brought against the card brands and PCI here and here). And, through additional conversation, he and I really do reach an agreement here, though we vary on the specifics; the proper solution for the restaurant is to outsource, truly transferring the risk out. Unfortunately, this belies some biases in the card industry, wherein they always hold the upper hand.

More to the point though, I question where or not it's really sound logic to think that merchants should be held to these standards. While it's true that they signed the contracts, one could potentially make the argument that PCI DSS and the payment card contracts are too complex for businesses to understand, not to mention that PCI DSS represents a moving target. Even Branden admits "Is it overly-complex? Definitely." Unfortunately, he goes on to an "ignorance is no defense" line of thinking that may not be sound logic, and once again belies the faulty thinking behind this program. In fact, he even goes on to say:

"Citizens of a civilized society are expected to follow the rules of that society. Ignorance is never a defense."

There are a couple interesting things here. First, while some States have adopted all or part of PCI DSS (which version?) as law, the fact remains that PCI DSS is not law. It's an industry-supported self-regulation regime. Second, in the case where the agreements are too complex, or potentially unfair or "unconscionable," it can (and has) been argued that the agreements may not be binding. Specifically, courts have established case law around "shrinkwrap" agreements that discuss key cases (see a nice analysis of ProCD here, and also see Wikipedia here for more links).

The long-n-short of it is this: PCI DSS itself is not a law. It's a convoluted mess that is rarely, if ever, presented clearly (e.g., we didn't even have an immediate agreement and consensus on the previous post about whether or not a QSA is required, with QSAs actually questioning the statement). If professionals working in the field are unclear on these things, how is it that we expect organizations (especially small businesses) to somehow be "expert" or even "adequately educated" on these requirements, especially when card processing and card security are merely an ancillary supporting function, not anything core to their business? Which leads to the last question...

Whose Risk?

Exactly whose risk are these merchants managing, anyway? In the case of PCI DSS, they are being asked to act on behalf of, and in the interest of, the card brands. PCI DSS is part of the card brands' risk management program, in which - really - the merchants are part of the threat community against which they (the card brands) are defending themselves. In this sense, PCI DSS represents the greatest coup of modern times in that the card brands have successfully pushed much of the responsibility for their security onto the shoulders of merchants and acquirers, whether they can afford it or not.

As such, when I hear arguments made that merchants should be taking a more active interest and role in "managing risk" related to things like payment cards, it makes me pause because this would be like petroleum companies holding mechanics liable for engine failures resulting from poor quality oil or fuel. Ultimately, the payment card architecture is inadequate from a security perspective, introducing a high potential for fraud losses for the card brands. Unfortunately, rather than addressing this core deficiency, the card brands are driving compensating controls that transfer that risk to the merchants (without the merchants really having much option to say no - more on this in a minute), and then reinforced further with a fine scheme that at times seems arbitrary and capricious.

So, why don't the merchants quit accepting payment cards? There are several reasons:
* Checks: There is considerable disincentive to take checks. Also, banks are decreasingly willing to accept them. Walmart, for example, scans the check and still requires you to enter your PIN to complete the transaction just as if you'd swiped a debit card.
* Cash-Only: While a compelling case could be made in some places favoring cash-only, there are a few contingencies that are necessary. Branden and I actually discussed at length before I wrote this piece. First, if you're cash-only, then an ATM needs to be available either on-site or in very close proximity (oh, and preferably with a truly reasonable fee structure). Second, there is likely a ticket size at which cash-only becomes less feasible (is it $20? $40? $50? I don't know.). If you're going to a fine dining restaurant and expecting a check over $100, would you not be surprised if they didn't take payment cards?
* Dropping Card Support: If your business has supported payment cards, then it will be very difficult to terminate support. Customers tend to feel very strongly about having services available, and tend to attract negatively when they go away, even if the true (vs perceived) impact is minimal.
* Social Pressure: Depending on your locale and primary demographic, there may be a very strong expectation by your customers to support payment cards (going forward, this may also include mobile payments support). If not having payments cards will drastically limit or decrease the willingness of your customers to purchase from you, then you're going to sign up for payment cards, no matter what the contract says.

Now, you might be reading and still thinking "So what? Why do they accept this risk? Why don't they transfer it?" And on that point we of course agree (Branden does, too!). I don't think there is really any disagreement on this point about outsourcing. However, I do disagree with how you define it. PA-DSS exists to certify point-of-sale (POS) systems. If, as a merchant, I buy a POS, then my expectation is that it's compliant. If it later turns out that the POS is not compliance, then don't fine me (the merchant), but instead fine the POS maker! From my perspective as a merchant, I transferred the compliance responsibilities to the POS maker when I bought their (regulated) product. Similarly, few merchants directly support their POS systems. Instead, many will leverage integrators who will provide direct POS product support, and may even lease the product to the merchant. In this case, also, as a merchant I would assume (right or wrong) that I've transferred my risk and do not have a responsibility to do anything further.

Unfortunately, there's no good consensus on these points today, and the PCI Council certainly hasn't done well to clear the muddied waters. Perhaps the restaurant lawsuit will help set a benchmark for responsibility, but it will likely be a while before we see resolution (assuming it's resolved in court at all, which is never a safe bet). Until we achieve better consensus, I will continue to maintain that PCI DSS represents a regulation regime that is strongly stacked against merchants, and serves to further grow the audit-industrial complex, which has been as much a negative as positive force in the industry. For every improvement we might be able to trace to PCI DSS implementation, there are increasing numbers of examples where security was not improved, or where confusion led to worse results that could have been addressed through more clear, more responsible behavior by all parties (including the card brands).

1 Comment

There is always the option for small businesses to modify their business processes to make compliance easier. There are tradeoffs. Who wants to use a swipe machine on a phone line when they can get a razzly-dazzly integrated POS system that will make their reconciliation and bookkeeping tasks a breeze? If it's a choice between validating with SAQ B rather than SAQ C or D, a few more minutes for reconciliation vs. tens of thousands of dollars for compliance sounds very attractive.

About this Entry

This page contains a single entry by Ben Tomhave published on January 19, 2012 10:00 AM.

The Gross Example of STRATFOR was the previous entry in this blog.

Bloggers Beware: InfoSec Island is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives


  • about
Powered by Movable Type 6.3.7