Steve Sommers of Shift4 has posted an interesting take on the PCI DSS and its value to merchants and service providers, particularly in the wake of the Global Payments breach. Steve has asked me to comment on his post and here is my take.
This quote speaks to the frustration a lot of merchants and service providers feel.
“The only thing PCI did was round up a bunch of existing security best practices, compile them into lists, and publish these lists as “guidance” documents.”
No doubt about it, the PCI DSS is an amalgam of various security “best practices” bundled together and published by the PCI SSC. I remember back in 2003 when the PCI DSS was the Visa CISP, fresh off the presses as an Excel spreadsheet, still embedded with the review comments from Visa and the consultants that created the CISP.
But what are the card brands to do? Breaches are occurring all over the place when they start down this road. The media reports that so many Visa or MasterCard accounts are breached and then they talk about the merchant or service provider involved. Visa and MasterCard are trying to protect their brand names because studies show that the public remembers the card brand names, but quickly forget the names of the merchants or service providers breached. As a result, they feel the need to develop guidelines to protect cardholder data to minimize the number and sizes of breaches.
Was life better when Visa, MasterCard, American Express, Discover and JCB all had their own individual standards? You all complain now about one ROC or SAQ, how would you like to be filling out a different form for each card brand every year? I would guess your answer is a huge ‘No’.
But the bigger question is, if not the PCI DSS, then what standard? ISO 27002? FISMA? FFIEC? HIPAA HITECH? I have yet to find a security standard that everyone can agree on, let alone agree to follow. People complain about every one of the information security standards. And then there is that ugly mantra of “compliance is not security,” but I have already covered that ground. So see my posts on why I think that saying is just a dodge.
All security standards are just a starting point or ante into the game. A number of friends of mine have all remarked that their security programs only have to be a little bit better than everyone else’s to keep them off the target list. However, that is the key; you need to be better than the other guy. But will the other guy tell you what he is doing when he has the same strategy? Standards like the PCI DSS give you that benchmark to start from so you know where you need to be better than the rest.
But the biggest problem with standards all comes down to the fact that humans are really averse to being measured or assessed against a standard. Why? It makes people responsible and accountable for what they do and few people want that sort of accountability – we all much prefer “wiggle room” in how our jobs are assessed.
“Then the card brands attached fines and penalties to punish merchants if they failed to comply with PCI “guidance” 100% of the time.”
“To me, the issue is this: PCI SSC promotes their work as “best practices” or ”guidance”, and then the card brands turn around and flog merchants for not following them when they are breached.”
Steve is right on the mark with these statements. As he stated earlier in his post and what I frequently state here, security is not perfect. All security does is reduce the risk of a breach but does not remove that risk in its entirety. As a result, even with PCI DSS compliance, breaches will still occur, but the goal is to make them much less frequent and a number of orders of magnitude smaller in the amount of data released.
This brings us to the heavy handedness in how the card brands handle breaches. All I can say is that some of my friends in the forensics field are telling me that there are a number of breaches that they have investigated that were not the result of PCI non-compliance. So Visa and PCI SSC GM Russo need to back off on their statement that “No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach.” According to my sources, this is patently not true anymore and the card brands are not happy about that fact.
The card brands, in particular Visa, seem to refuse the premise that security is not perfect and keep pushing that the PCI DSS, if followed to the letter, is the solution to breaches. None of this is the truth and security professionals know those facts. As a result, we end up with media quotes from the card brands, PCI SSC representatives and security professionals that are at times out and out asinine. Until we can all come to grips with these facts, we will continue to be playing a game of spin. And spin get us nowhere.
“I personally believe that PCI is written in such a way – and interpretations among QSAs vary so much – as to make it impossible for anyone to be 100% compliant 100% of the time.”
The flexibility in the PCI DSS is there because security professionals and their employers would not have it any other way. Would you prefer a dictatorial standard that specifically calls out solutions and vendors? What would people be saying if only Cisco and Juniper firewalls, routers and switches were allowed? What would Microsoft say if Windows was not allowed? What would other vendors say if only MICROS POS solutions were approved? What if only VLANs with specific ACLs were the only allowed method of network segmentation? Can you say lawsuits?
The bigger problem that the PCI SSC needs to address is the QSA/ISA training. A lot of QSAs are great technologists, but would not know a good or bad control environment if it bit them in the posterior. Fewer QSAs and most ISAs know controls, but would not know a proper firewall or router configuration to save their lives. And finally, there are a very, very few QSAs and some ISAs that know the technology and controls. Unfortunately, the PCI SSC has not found the way to winnow out the QSAs and ISAs so that only the ones that know both technology and controls remain.
But even in such a perfect world, each QSAC has its own tolerance of risk. As a result, what is PCI DSS compliant to one QSAC is not necessarily going to be acceptable to another QSAC because of the risk they are being asked to accept. Firms like mine are fairly risk averse, so we are going to be more demanding when it comes to what is PCI compliant than other QSACs. But by the same token, I do not believe we are unreasonable in what we demand for PCI compliance.
At the end of the day, while the PCI DSS is not perfect, it does provide the following benefits to merchants and service providers.
- It provides a way to help everyone learn from the other guy’s mistakes. As attack tactics change, so do the PCI standards to address tactics that might not be covered.
- It gives everyone the baseline of what they need to execute 24x7x365 if they even think they have a better than average chance at security.
Prior to the PCI DSS, Visa CISP and the other standards, it was a crap shoot as to whether or not an organization’s security was going to be up to snuff. I do not think that is where anyone wants to go.
Steve, I understand your frustration and the frustration and pain of merchants and service providers. But if what I have stated here is not a net positive, I do not know what is. Is it perfect? Nothing in the world is perfect. But there are some changes that would improve the program and make it seem much less painful and frustrating. We just need to continue to work on the PCI SSC and the card brands to see the light and make the necessary changes.

Actually, you touched on one point that I forgot to mention: “It provides a way to help everyone learn from the other guy’s mistakes. As attack tactics change, so do the PCI standards to address tactics that might not be covered.” This brings up another beef I have with PCI that I will be writing on in the near future: PCI SSC does not share (at least not directly in real-time). Dave Oder, CEO of Shift4, posted on this topic not too long ago: http://www.shift4.com/blog/post.cfm/global-ramifications.
As a gateway provider, I would sleep better at night if I knew for certain that I was not vulnerable to the same attack vectors that were used against Global, or any other breach victim. Again, since PCI is not perfect, having real-time information on recent breaches may help patch areas that are weak. While PCI may share via updating the standard, they are still very weak in giving the “why” behind the rule changes. So, who decides whether a rule change will plug specific attack vector and why should we have to wait for the two-year PCI update window to plug a vector?
While I agree with your comment that the PCI SSC does not share in real time, I would argue that they do not have to nor is that their responsibility.
Requirement 6.2 in the PCI DSS requires merchants and service providers to have a security program in place that monitors for and ranks new vulnerabilities and attack tactics and to modify their security measures, as necessary, to those new threats. I think that about covers it and why the PCI DSS does not need to be changed every week/month/year.
I would also point out that not every new attack vector is going to mandate a change to the PCI DSS. Particularly when Verizon/TrustWave/et.al. all report year after year that the majority of breached organizations cannot execute the basic requirements in the PCI DSS adequately 24x7x365. Those breaches where merchants and service providers are not compliant are because they truly are not compliant, not some pissing match over fine points in the PCI DSS requirements. Those breached merchants and service providers might argue that “security is not perfect”, but at the end of the day, they couldn’t get the basics down, let alone keep themselves secure.
In certain cases, the card brands do share breach information if necessary, on the QT. It’s just that since you’re not a merchant or service provider that might be involved, you aren’t in that loop.
But the rub in that is that since each organization’s infrastructure, architecture, applications, etc. are all different, what worked at Global probably wouldn’t necessary work with the next victim. Yes, the initial social engineering that got them in probably works, but from there on out breaches are custom operations. Not that it necessarily slows down the attacker, but it’s not like you can have a canned script/program/etc. at the ready and just hit and run every target.
Thank you for taking the time to read on post your thoughts. You obviously are a much faster writer than I as I didn’t expect such a quick response. I’m in awe.
Anyway, the more conversations I have with people on this topic, the more I believe the solution lies in some safe harbor additions to the application of PCI DSS. At least make assessments worth something. Right now, if an organization is breached, assessed merchants and non-assessed merchants are treated the same and both will be found out-of-compliance and fined (among other penalties) — the only difference is that the assessed merchant paid more for the pleasure of being assessed.
I understand that PCI DSS is not perfect and I don’t expect it to be. But it’s wrong for the card brands to be expecting perfection from the entities trying to comply with a non-perfect program.
I represent a large Level 1 Service Provider. Until we started our PCI DSS journey in 2006 we had NO standard on which to benchmark our security. Yes, I think we would all agree that PCI DSS is not perfect. But what is?
The point about PCI is not about perfection, it is about instilling discipline, awareness, process, standards and accountability. Without these behaviors, adopting any standard is meaningless. If as an organisation you buy into the principles that PCI DSS is designed to instill, then you will be a damn sight better off than constantly nit-picking and harping on about trivial detail. After 6 years of experience we love and live PCI DSS, because without it we would be a poorer organisation (that is if we still existed!!!).
You make some very good points and imply one very big one. If anything, the PCI DSS got organizations thinking and talking about their information and what is important and needs protection. It essentially pulled security out of the IT backroom and into the forefront.
Thanks for bringing up this subject. Being a QSA myself, here is my personal opinion on the subject. I hope that at some point, more and more merchants will be able to fill in a simple SAQ A questionnaire. And for the level 1 merchant, that they will also be able to outsource their creditcard processing. The technology is there for making this happen – it is just a matter of time I guesss. For ecommerce merchants, this is rather simple. At the time of payment, make sure the user is redirected to a service provider that is PCI certified and you are done! For those merchants with POS systems, if the encryption of the creditcard information occurs within the PINpad terminal, your POS will be out of scope as it will never have access to the creditcard information. Unfortunately, your POS will need to support this new way of handling the transaction. Until then, your POS is in scope with all its consequences. When you talk to your vendor of POS, make sure that they are considering this new way of handling the transaction. This will be for the benefit of all!